Besturingssysteem-onderhoud en onderhoudsmodus
Je servers installeren elke nacht hun beveiligingsupdates. Twee dingen die daarbij horen kan een server niet zelf regelen: dat het alarm even stil is terwijl je aan hem werkt, en in welke volgorde de vloot naar beneden gaat als er herstart
Geschreven voor: Beheerder
Je servers installeren elke nacht hun beveiligingsupdates. Twee dingen die daarbij horen kan een server niet zelf regelen: dat het alarm even stil is terwijl je aan hem werkt, en in welke volgorde de vloot naar beneden gaat als er herstart moet worden. Daar gaat dit artikel over.
Een server in onderhoudsmodus zetten
Ga naar Servers → Onderhoud, of open de server zelf. Zet je een server in onderhoudsmodus, dan gebeuren er drie dingen:
- er wordt eerst een herstelpunt gemaakt — een momentopname van de bestanden van de server plus een dump van zijn databases. Dat is hetzelfde herstelpunt dat de nachtelijke back-up maakt, alleen nu meteen;
- de meldingen over die server zijn stil. Valt hij weg, dan wordt er niemand gebeld en komt er geen pushbericht. In het logboek staat het wel;
- er komen geen nieuwe klanten meer op. Wat er al op staat blijft gewoon bediend — precies zoals bij een server die je leegmaakt.
Je geeft er altijd een reden bij. Dat is wat jij (of je collega) over een week terugleest als je je afvraagt waarom die server 's nachts stil was.
Als het herstelpunt niet gemaakt kán worden, gaat de onderhoudsmodus niet aan. Stil worden zonder vangnet is erger dan allebei niet: eerst repareren, en pas als je bewust dat risico neemt kun je het forceren. Heeft de server helemaal geen back-updoel, dan is er niets om te mislukken — dat staat er dan bij en de modus gaat gewoon aan.
Er weer uit
Als je de server uit de onderhoudsmodus haalt, controleert hij zichzelf: de volledige doctor-controle plus een echte aanvraag naar elke website op die machine. De uitkomst staat in het antwoord.
De server komt altijd terug uit de onderhoudsmodus, ook als die controle iets vindt. Dat is met opzet: een server die stil blijft omdat een controle bleef hangen is precies de storing die niemand opmerkt.
Is de server op dat moment onbereikbaar, dan zet het paneel zijn eigen administratie goed — het alarm gaat weer aan — en zegt erbij dat de machine zelf nog denkt dat hij in onderhoud is. Herhaal het zodra hij weer antwoordt, of doe het op de machine zelf.
Diensten die nog oude code draaien
Een update vervangt een gedeelde bibliotheek op schijf. Programma's die de oude versie al open hadden, draaien daar gewoon mee door. Je server kan dus volledig bijgewerkt zijn en tóch nog het lek bedienen dat je net dichtte.
CoreCP vraagt needrestart welke diensten dat zijn en herstart precies díe. Drie diensten nooit: de agent, het paneel en ssh — dat zijn de drie manieren om kwijt te raken waar je mee aan het werk bent. Die worden als uitgesteld gemeld, met de reden erbij, zodat je ziet wat er nog openstaat.
Is er een nieuwe kernel geïnstalleerd, dan staat dat er apart bij. Een herstarte dienst repareert geen kernel.
Het herstartplan
Servers → Onderhoud heeft onderaan het herstartplan: welke servers samen naar beneden gaan, en in welke volgorde. Alles in één vak gaat tegelijk; de vakken gaan op volgorde. Een vak kan op een latere nacht vallen — zo schrijf je op dat de ene groep een dag vóór de andere gaat.
Drie dingen weigert het paneel, met de reden erbij:
- alle naamservers van een set tegelijk. Die set beantwoordt de domeinen die eraan hangen;
- een primaire zone samen met zijn eigen secundaire. Dan is er geen bron meer én geen kopie die het overneemt;
- de machine waar dit paneel op draait, tenzij je daar expliciet akkoord op geeft. Tijdens die herstart is er geen paneel — ook niet voor de servers die je er net vóór hebt uitgezet.
Je krijgt álle punten tegelijk te zien, niet één voor één. En het akkoord voor het paneel hoort bij dít plan: haal je de machine uit het plan, dan verdwijnt het vinkje mee.
Updates in golven
Staging en productie draaien allebei elke nacht om drie uur. Het verschil zit niet in het tijdstip maar in wát ze aangeboden krijgen: de spiegel zet de momentopname van vandaag klaar voor staging, en pas als die een etmaal oud is gaat productie eroverheen. Een slecht pakket heeft dan een dag op een omgeving zonder klanten gestaan voor het bij de klanten komt.
Je hoeft daar niets voor in te stellen. Wat je wél moet weten: een fix die je vandaag op staging ziet, staat morgen pas op productie.
De samenvatting per mail
De ochtend na een onderhoudsronde krijg je op het alarmadres één bericht met per server wat er gebeurd is: hoeveel pakketten, hoeveel diensten herstart, en of de server bijgewerkt, herstart, nog wachtend of mislukt is.
Elke server staat erin, ook de servers waar niets te doen was — anders kun je "niets te doen" niet onderscheiden van "nooit gevraagd". Een server die niet bereikbaar was staat er ook in, met die uitkomst.
Vanaf de terminal
root@p1:~# corecp-panel maintenance mode on w1.example.net --reason "kernel 7.0.0-31"
root@p1:~# corecp-panel maintenance mode
root@p1:~# corecp-panel maintenance mode off w1.example.net
root@p1:~# corecp-panel maintenance reboot-plan
root@p1:~# corecp-panel maintenance reboot-plan --check /tmp/plan.json
root@p1:~# corecp-panel maintenance summary --sendOp de server zelf:
root@w1:~# corectl node maintenance-mode status
root@w1:~# corectl node restart-services --dry-run
root@w1:~# corectl node restart-services