Private Cloud dagelijks draaien: nodes, failover en updates

Wat dit artikel behandelt

Private Cloud vs. Flexible VPS legt uit wanneer je Private Cloud kiest boven gedeelde infrastructuur. Dit artikel gaat een niveau dieper: de operationele mechanica van het dagelijks draaien van een hyperconverged cluster, ongeacht of dat cluster het VMware-platform is onder Worldstream's eigen Flexible Cloud-product, Private Cloud's eigen infrastructuur, of een stack die je zelf bouwt op Bare Metal Compute. De mechanica hieronder geldt voor hyperconverged infrastructuur in het algemeen: met hoeveel nodes je begint, wat er gebeurt als er één uitvalt, hoe updates worden toegepast en hoe disaster recovery tussen locaties werkt.

Klein beginnen: twee nodes en een witness voor quorum

Je hebt geen groot cluster nodig om te beginnen. Sommige HCI-platforms, waaronder Proxmox en StarWind, ondersteunen clusters van twee nodes door een lichtgewicht witness node toe te voegen die alleen de doorslaggevende stem voor quorum vasthoudt: het mechanisme dat bepaalt welke kant van het cluster leidend is als de nodes het contact met elkaar verliezen.

De prijs die je daarvoor betaalt is redundantie. Een cluster van twee nodes geeft je geen volledige redundantie: valt een van de twee datanodes uit, dan draai je tot reparatie op verminderde capaciteit. Voor productieworkloads is drie nodes het betere startpunt, want dan heeft elke node ergens naartoe om over te failoveren, zonder dat het cluster op één overgebleven node moet draaien.

Als ruwe richtlijn voor sizing: twee tot drie nodes past bij kleine implementaties of een remote/branch-office, drie tot vijf nodes is gebruikelijk voor algemeen zakelijk gebruik, en vanaf vijf nodes begint erasure coding (hieronder toegelicht) zich uit te betalen voor prestatiegevoelige workloads. Een oneven aantal nodes maakt quorumbeslissingen bovendien eenduidiger.

Wat er gebeurt bij een node-uitval

Hoe het cluster zich gedraagt bij een node-uitval hangt af van hoe data over de nodes wordt gerepliceerd:

• Two-way replicatie: je VM's blijven draaien op de overgebleven nodes, en het cluster begint automatisch de verloren replica's te herbouwen op vrije capaciteit elders in het cluster.
• Three-way replicatie: het cluster overleeft het zelfs als twee nodes tegelijk uitvallen. Workloads blijven draaien op de gezonde nodes, terwijl ontbrekende replica's automatisch op de achtergrond worden herbouwd.

Hoe dan ook: het punt van replicatie is dat één hardwarestoring een operationele gebeurtenis is die het cluster zelf opvangt, geen incident dat workloads offline haalt. Voor bescherming op langere termijn, verder dan replicatie op nodeniveau, geven snapshots je een snel terugvalpunt en geven off-site backups je herstel als er iets misgaat met het hele cluster, niet alleen met één node. Regelmatig restoreprocedures testen is wat die bescherming van theoretisch naar betrouwbaar tilt.

Het cluster patchen: rolling updates zonder volledige downtime

De meeste HCI-platforms ondersteunen rolling updates: nodes worden één voor één geüpgraded, met upgrade domains die quorum en databescherming steeds intact houden, terwijl de VM's die op de node in onderhoud draaiden eerst naar de andere nodes migreren. Het cluster als geheel blijft beschikbaar, ook al doorlopen de afzonderlijke nodes na elkaar onderhoud.

In de praktijk betekent dat: updates plannen in een vast onderhoudsvenster, de clusterhealth controleren voordat je begint, en, als je een dev/test-cluster hebt, de update daar eerst testen. Firmware-updates op de onderliggende hardware volgen hetzelfde rolling patroon: de firmware van één node wordt bijgewerkt en gevalideerd voordat je naar de volgende gaat, in plaats van het hele cluster in één keer plat te leggen.

Het cluster uitbreiden werkt op dezelfde manier, maar dan omgekeerd: door nodes toe te voegen kan het cluster data automatisch herverdelen over de nieuwe capaciteit, en die herverdeling gebeurt, net als onderhoud, zonder workloads offline te halen.

Disaster recovery tussen locaties: het latency-budget

Een cluster beschermen tegen de uitval van een hele locatie, niet alleen van een node, betekent dat je data naar een tweede locatie moet krijgen. Het gebruikelijke patroon is asynchrone replicatie: snapshots en backups worden volgens een schema gerepliceerd naar een secundaire locatie, zodat de tweede locatie altijd iets achterloopt, maar nooit afhankelijk is van real-time connectiviteit tussen de twee.

Een stretched cluster, waarbij nodes op twee locaties als één synchroon cluster fungeren, biedt sterkere bescherming, maar werkt alleen binnen een strak latency-budget tussen de twee locaties, doorgaans genoemd als een round-trip time onder de 5ms. Buiten dat budget wordt synchroon schrijven over de verbinding het knelpunt, en is asynchrone replicatie de realistischere optie. Je disaster recovery-plan testen is net zo belangrijk als het ontwerpen ervan: een node- of locatie-uitval simuleren, een echte failover uitvoeren en controleren of de data intact terugkomt, dat is wat bevestigt dat het plan werkt voordat je het echt nodig hebt. Veel HCI-platforms hebben ingebouwde DR-tests die productie niet raken terwijl je ze uitvoert.

De onderliggende stack kiezen, of overnemen

Worldstream's eigen Flexible Cloud-product draait op VMware, specifiek VMware Cloud Foundation met vSAN als storagelaag, met all-flash NVMe onder de motorkap. Zie Je Flexible Cloud-omgeving beheren via VMware Cloud Director voor hoe die stack is opgebouwd en beheerd. Private Cloud is dedicated, niet-gedeelde infrastructuur op het eigen netwerk van Worldstream. Wil je weten wie de hypervisor- en HCI-laag draait in een specifieke Private Cloud-omgeving, vraag dat dan na bij Worldstream.

Bouw je in plaats daarvan zelf een hyperconverged cluster op Bare Metal Compute, dan levert Worldstream de fysieke servers en netwerk, en kies je zelf de HCI-software. Die keuze komt neer op een echte afweging:

Er is geen universeel juist antwoord: het hangt af van je bestaande stack, hoe comfortabel je team is met het zelf beheren van het platform, en je budget voor licenties versus support van de leverancier.

Een woord over HCI vs. software-defined storage (SDS)

Deze twee worden vaak door elkaar gehaald omdat ze overlappende problemen oplossen. SDS bundelt storage over nodes heen, maar leunt nog altijd op aparte compute-nodes elders in de architectuur. HCI bundelt compute en storage op dezelfde nodes, wat het dagelijks beheer vereenvoudigt, maar ook betekent dat een node-uitval zowel compute- als storagecapaciteit tegelijk raakt, omdat de twee failure domains gekoppeld zijn in plaats van gescheiden.