Jag byggde ett kluster men maskinerna flyttar inte: det som saknas är lagringen

Du byggde klustret, noderna ser varandra, i gränssnittet står de alla sida vid sida. Sedan vill du flytta en maskin till en annan nod och det går inte.

Det som saknas är inte klustret, det är lagringen.

Det som flyttar är inte maskinen utan arbetsminnet

Att flytta en virtuell maskin som kör betyder att kopiera tillståndet i dess arbetsminne till den andra noden. Det går över nätet och är snabbt.

Men maskinens disk behövs också, och disken är många gånger större än arbetsminnet. Ligger disken bara på den första nodens egen enhet, når den andra noden inte fram. Flytten börjar antingen aldrig, eller så måste den kopiera disken också, och då handlar det inte längre om sekunder utan om minuter eller till och med timmar.

Svaret ryms alltså i en mening: disken måste vara synlig från båda noderna.

Två sätt att ordna det

Delad lagring. Disken ligger på en gemensam plats som båda noderna ansluter till: ett nätverkslager, en lagringstjänare eller ett utspritt lagringslager. Vid flytten kopieras disken inte alls, eftersom den redan finns där. Detta är den snabbaste och renaste vägen.

Kopiering enligt schema. Disken stannar lokalt men kopieras till den andra noden med jämna mellanrum. Vid flytten skickas bara det som ändrats sedan senaste kopian, därför går det snabbt. Priset är detta: eftersom kopian tas enligt schema kan du förlora de sista minuterna. Vid en planerad flytt är det inget problem, vid ett plötsligt fel kan det vara det.

Frågan som avgör vilket som passar dig lyder: om en nod dör plötsligt, hur många minuters förlust accepterar du? Är svaret "noll" behöver du delad lagring. Är svaret "några minuter går bra" räcker kopiering enligt schema och är långt billigare.

Behållare flyttar inte som virtuella maskiner

Här blir de som bygger sitt första kluster oftast överraskade. En virtuell maskin går att flytta medan den kör. En behållare gör det inte: den stängs av, flyttas och startas igen.

För dina behållare finns alltså ingen avbrottsfri flytt, inte ens med kluster. Det är ingen brist utan behållarens natur: en virtuell maskin bär sin egen kärna, en behållare använder tjänarens, och den kärnan kan inte resa med.

Praktisk följd: ta med det i beräkningen när du avgör vilket arbete som ska ligga i en behållare och vilket i en virtuell maskin. Ligger arbete som inte tål avbrott i en behållare, kommer det arbetet att stanna under underhållsnätter.

Lägg ordningen i förväg

Natten du uppdaterar en nod ska svaren på dessa frågor redan ligga färdiga: hur många maskiner som finns på noden, hur många som kan flyttas, hur många som måste stängas av och vilken nod de flyttbara går till.

Att räkna ut det samma natt är en dålig idé. Skriv ner det en gång och lägg det åt sidan.

Vad Atlas gör

Innan en nod uppdateras listar Atlas de maskiner som kör på den och föreslår dig en flyttordning: vilken maskin till vilken nod. Förslaget fördelar dem i tur och ordning över de tillgängliga noderna.

Skillnaden för behållare görs här uttryckligen. För virtuella maskiner är den föreslagna metoden flytt medan de kör; för behållare kedjan stäng av, flytta, starta. Produkten erbjuder inte detta som ett val, den konstaterar att en behållare inte kan flyttas på annat sätt.

Maskiner som lämnats till hanteringen för hög tillgänglighet märks också, eftersom att flytta dem för hand och att lämna dem till hanterarens eget beslut är två skilda saker.

Och förslaget förblir ett förslag: flyttkommandot körs inte av sig självt, du trycker på knappen.

En ärlig gräns: i dag betraktar Atlas varje körande virtuell maskin som flyttbar och kontrollerar inte om dess disk verkligen syns från den andra noden. Produkten svarar alltså inte på lagringsfrågan ovan åt dig, du måste besvara den en gång själv. Läs förslaget med det i minnet.