Ik heb een cluster gebouwd maar de machines verhuizen niet: wat ontbreekt is de opslag

Het cluster bouwen maakt machines nog niet verplaatsbaar. Wat verhuizing mogelijk maakt is niet het netwerk maar waar de schijf staat. En containers verhuizen niet zoals virtuele machines.

AtlasPVE ·

Dit artikel beantwoordt

  • proxmox migratie mislukt
  • proxmox live migration werkt niet
  • heeft proxmox gedeelde opslag nodig
  • proxmox lxc migratie
  • proxmox lokale opslag migreren
  • heeft proxmox gedeelde storage nodig
  • proxmox lokale storage migreren

Je hebt het cluster gebouwd, de knooppunten zien elkaar, in de schil staan ze allemaal naast elkaar. Dan wil je een machine naar een ander knooppunt verplaatsen en het lukt niet.

Wat ontbreekt is niet het cluster, het is de opslag.

Wat verhuist is niet de machine maar het werkgeheugen

Een draaiende virtuele machine verplaatsen betekent de toestand in haar werkgeheugen naar het andere knooppunt kopiëren. Dat gaat over het netwerk en het is snel.

Maar de schijf van de machine is ook nodig, en de schijf is vele malen groter dan het werkgeheugen. Staat de schijf alleen op de eigen schijf van het eerste knooppunt, dan komt het tweede knooppunt er niet bij. De verplaatsing begint dan óf helemaal niet, óf hij moet de schijf meekopiëren, en dan duurt het geen seconden meer maar minuten of zelfs uren.

Het antwoord past dus in één zin: de schijf moet vanaf beide knooppunten zichtbaar zijn.

Twee manieren om dat te regelen

Gedeelde opslag. De schijf staat op een gemeenschappelijke plek waarmee beide knooppunten verbinding maken: een netwerkopslag, een opslagserver of een verdeelde opslaglaag. Bij het verplaatsen wordt de schijf helemaal niet gekopieerd, want hij staat er al. Dit is de snelste en schoonste weg.

Kopiëren op schema. De schijf blijft lokaal maar wordt met vaste tussenpozen naar het andere knooppunt gekopieerd. Bij het verplaatsen wordt alleen verstuurd wat sinds de laatste kopie is veranderd, daarom gaat het snel. De prijs is deze: omdat de kopie volgens schema wordt gemaakt, kun je de laatste minuten kwijtraken. Bij een geplande verplaatsing is dat geen probleem, bij een plotselinge storing kan het dat wel zijn.

De vraag die bepaalt wat bij jou past luidt: als een knooppunt plotseling sterft, hoeveel minuten verlies accepteer je? Is het antwoord "nul", dan heb je gedeelde opslag nodig. Is het antwoord "een paar minuten mag", dan volstaat kopiëren op schema en is het veel goedkoper.

Containers verhuizen niet zoals virtuele machines

Hier worden bouwers van hun eerste cluster het vaakst verrast. Een virtuele machine kan draaiend verplaatst worden. Een container niet: die wordt afgesloten, verplaatst en opnieuw gestart.

Er bestaat voor je containers dus geen ononderbroken verplaatsing, ook niet met een cluster. Dat is geen tekortkoming maar de aard van een container: een virtuele machine draagt haar eigen kern mee, een container gebruikt die van de server, en die kern kan niet meereizen.

Praktisch gevolg: houd hier rekening mee bij het bepalen welk werk in een container en welk in een virtuele machine draait. Staat werk dat geen onderbreking verdraagt in een container, dan valt dat werk stil op onderhoudsnachten.

Leg de volgorde vooraf vast

De nacht waarin je een knooppunt bijwerkt, moeten de antwoorden op deze vragen al klaarliggen: hoeveel machines op dit knooppunt staan, hoeveel er verplaatst kunnen worden, hoeveel er afgesloten moeten worden en naar welk knooppunt de verplaatsbare gaan.

Dat op diezelfde nacht uitrekenen is een slecht idee. Schrijf het één keer op en leg het opzij.

Wat Atlas doet

Voordat een knooppunt wordt bijgewerkt, somt Atlas de machines op die erop draaien en stelt je een verplaatsingsvolgorde voor: welke machine naar welk knooppunt. Het voorstel verdeelt ze om de beurt over de beschikbare knooppunten.

Het onderscheid met containers wordt hier uitdrukkelijk gemaakt. Voor virtuele machines is de voorgestelde manier verplaatsen tijdens het draaien; voor containers de keten afsluiten, verplaatsen, starten. Het product biedt dit niet als keuze aan, het stelt vast dat een container niet anders verplaatst kan worden.

Machines die aan het hoge-beschikbaarheidsbeheer zijn overgelaten worden ook gemarkeerd, want ze met de hand verplaatsen en ze aan de eigen beslissing van dat beheer laten zijn twee verschillende dingen.

En het voorstel blijft een voorstel: de verplaatsopdracht draait niet vanzelf, jij drukt op de knop.

Een eerlijke grens: Atlas beschouwt vandaag elke draaiende virtuele machine als verplaatsbaar en controleert niet of haar schijf werkelijk vanaf het andere knooppunt zichtbaar is. Het product beantwoordt de opslagvraag hierboven dus niet namens jou, je moet hem één keer zelf beantwoorden. Lees het voorstel met dat in gedachten.

Bronnen

De eigen documentatie van Proxmox. In het Engels, en die heeft over dit onderwerp het laatste woord.

Verwante artikelen

Hoe ziet dit eruit in Atlas?

Naar de productpagina