Onderwerp
Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas
Live-migratie verplaatst een draaiende machine naar een ander werkerknooppunt zonder haar te stoppen. De werkervirtualisatie gebruikt dat bij gepland onderhoud: een knooppunt wordt leeggemaakt, de machines verhuizen over een eigen migratienetwerk, en de gedeelde virtuele schijven blijven bereikbaar. Zo gaan knooppunten één voor één in onderhoud en wordt de werkervirtualisatie bijgewerkt zonder uitval van werkers.
Verhuizen kan alleen als de schijven gedeeld zijn en het migratieverkeer het opslagverkeer niet verdringt; daarom zijn bandbreedte, gelijktijdigheid en duur expliciet begrensd, ook in de fabric. Een migratie zonder post-copy laat de machine bij een fout op haar bronserver, wat veiliger is dan een half verhuisde machine. Live-migratie is een beproefde eigenschap binnen die grenzen, geen belofte van nul onderbreking, en zij blijft binnen de cel.
De virtuele schijven van werkers en virtuele servers staan op gedeelde blokopslag van het opslagcluster van de cel, via Data Foundation in externe modus: blokopslag met gedeelde toegang, de voorwaarde om draaiende machines te verplaatsen. Virtuele schijven staan nooit op lokale opslag.
Alternatief: lokale opslag voor virtuele schijven. Dan kan een draaiende machine niet verhuizen. De leverancier moet de ondersteuning van de gekozen opslagklasse voor live-migratie bevestigen.
Live-migratie heeft een eigen netwerk (VLAN 630), met 10 Gb/s per migratie en ten hoogste twee uitgaande migraties tegelijk per werkerknooppunt, dus ten hoogste 20 Gb/s uitgaand. Zo verdringen migraties het opslagverkeer op de gedeelde bundel niet.
De fabric begrenst live-migratie ook zelf, tot 25 procent per poort, en garandeert opslag 40 procent van de bandbreedte; de 20 Gb/s blijft daaronder.
In het hele cluster lopen ten hoogste twee migraties tegelijk, dus één server tegelijk (parallelMigrationsPerCluster 2, parallelOutboundMigrationsPerNode 2). Een migratie mag 9 seconden per GiB duren (completionTimeoutPerGiB 9), zodat een machine van maat L binnen 10 minuten verhuist, bij bandwidthPerMigration 1250M, in bytes per seconde. Er is geen post-copy, zodat een afgebroken migratie de machine op haar bronserver laat.
Een machine die niet convergeert, is een bevinding. De waarden worden expliciet vastgelegd, omdat de standaardwaarden tussen documentatie en upstream verschillen.
Live-migratie onderbreekt een machine ten hoogste 2 seconden en duurt ten hoogste 10 minuten, bij 10 Gb/s per migratie en twee uitgaande migraties per werkerknooppunt. Een strengere eis uit de dienstbeschrijving gaat voor.
De onderbreking hangt ook af van processor, netwerk en hoe snel de machine haar geheugen wijzigt; de live-migratieproef meet haar onder belasting.
Bij gepland onderhoud verhuizen de machines live naar de andere werkerknooppunten. Live-migratie is een beproefde eigenschap onder voorwaarden, geen belofte van nul onderbreking.
| Stap | Van | Naar | Handeling |
|---|---|---|---|
| 1 | Platformbeheer | Werkerknooppunt | Maakt het knooppunt leeg voor onderhoud |
| 2 | Virtualisatie | Reservetoets | Controleert de doelcapaciteit en of iedere machine afzonderlijk past |
| 3 | Migratie | Ander werkerknooppunt | Verplaatst geheugen en toestand over het migratienetwerk; de gedeelde rootschijf blijft bereikbaar |
| 4 | Controle | Werklast | Meet de onderbreking onder belasting en geeft daarna het knooppunt vrij |
Mislukt een verhuizing tijdens het kopiëren, dan blijft de machine op de bronserver draaien. Valt de bronserver zelf uit, dan is dat geen migratie maar een herstart elders, na uitsluiting van die server.
Knooppunten gaan één voor één in onderhoud, na ontruiming en alleen bij een gezond cluster. Firmware en basislijn worden via het serverprofiel bijgewerkt, één server tegelijk en na een capaciteitscontrole.
Het onderhoud wordt ieder kwartaal uitgevoerd. De toets Gecontroleerd bijwerken per laag beproeft het.
Er is geen live-migratie tussen clusters: overname tussen cellen loopt via de dienst zelf, niet door machines te verhuizen. Een live-migratie tussen twee clusters binnen één cel, bijvoorbeeld bij vervanging van de werkervirtualisatie, kan alleen na een ontwerpbesluit.
Verhuizen tussen cellen zou de cellen tijdens gebruik van elkaar afhankelijk maken.
De werkervirtualisatie draait alleen ondersteunde combinaties, nooit een versie die een draaiend gastcluster niet ondersteunt. Een overgang start ten minste 3 maanden vóór het einde van de ondersteuning, en kwetsbaarheden worden verholpen binnen de termijnen die daarvoor gelden.
Het versieoverzicht toont de stand.
Een versieovergang gaat na de leeromgeving cel na cel in de vaste volgorde: het vlootcluster (multicluster engine en vlootbeheer), het basisdienstencluster, het clusterbeheer, de werkervirtualisatie en dan de gehoste clusters per uitrolgolf; het opslagcluster volgt zijn eigen ritme. Voor de werkervirtualisatie gaat vooraf een melding naar opslagbeheer, en gaan de knooppunten één voor één na ontruiming. Een mislukte update wordt volgens de procedure van de leverancier voltooid of hersteld, niet teruggedraaid; tot de werkervirtualisatie gezond is, worden geen gastclusters bijgewerkt.
OpenShift Virtualization gaat met de versie van OpenShift mee, en Data Foundation volgt de combinatie die opslagbeheer voor het opslagcluster bevestigt.
Een foutief sjabloon wordt via het versiebeheer teruggezet. Bestaande machines behouden hun instellingen tot hun volgende vervanging, tenzij de fout een eerdere vervanging vraagt.