Sinds Broadcom VMware overnam, bestaan er geen eeuwigdurende licenties meer: alleen abonnementen, in bundels, afgerekend per core. Voor veel organisaties werd de verlenging daardoor fors duurder. Europese cloudproviders, verenigd in CISPE, melden stijgingen van 800 tot 1.500 procent en dienden in maart een klacht in bij de Europese Commissie (cloudmagazin). Proxmox VE is het alternatief waar de meeste beheerders als eerste naar kijken. Voor ons is het geen nieuw alternatief: wij draaien al sinds 2016 met plezier op Proxmox, en ook het cloudplatform dat we voor PlanetNode bouwden draait erop. Het misverstand is dat de overstap goedkoop is omdat Proxmox gratis is.
Gratis software, geen gratis overstap
Een massale uittocht bij VMware is uitgebleven. In een enquête die heise aanhaalt, noemen organisaties complexiteit en risico, onverwachte kosten en technische beperkingen als de grootste drempels. Dat past bij wat je in de praktijk ziet: de hypervisor vervangen is het kleinste deel van het werk. De kosten zitten in vier andere posten.
- Abonnementen — Proxmox VE draait zonder licentie, maar voor productie wil je de enterprise-repository met geteste updates. Dat kost volgens de prijslijst van Proxmox € 120 tot € 1.100 per bezette CPU-socket per jaar, afhankelijk van het supportniveau, en alle nodes in een cluster nemen hetzelfde niveau.
- Back-upintegratie — veel back-upsoftware praat rechtstreeks met de VMware-API's. Ondersteunt jouw pakket Proxmox niet of maar half, dan verander je ook van back-upoplossing, met eigen retentie, opslag en hersteltests. Het goede nieuws: de open-sourcecommunity heeft hier snel op gereageerd, met adapters en integraties die bekende back-upoplossingen met Proxmox laten praten, en Proxmox Backup Server is zelf open source. Kijk dus eerst of er voor jouw pakket al een koppeling bestaat.
- Processen en documentatie — runbooks, monitoringregels, scripts tegen de vSphere-API, de manier waarop een nieuwe VM wordt aangevraagd: alles wat naar VMware verwijst, moet opnieuw.
- Kennis — clustering, opslag en netwerk werken anders. Wie tien jaar vCenter heeft beheerd, moet een andere set reflexen opbouwen, en dat gaat het snelst op een testcluster, niet in productie.
Reken de overstap dus niet uit als "licentie min licentie". Zet de VMware-verlenging af tegen abonnementen plus de uren voor die vier posten. Voor de meeste omgevingen valt die som nog steeds gunstig uit, maar niet zo gunstig als de eerste blik doet denken.
De valkuilen die je kunt voorzien
Een paar dingen gaan bij vrijwel elke migratie mis als je er niet op let:
- Quorum — een Proxmox-cluster doet pas iets als een meerderheid van de nodes elkaar ziet. Met twee nodes heb je dus een extra stem nodig, een kleine externe QDevice, anders staat bij uitval van één node ook de andere stil.
- Gedeelde opslag — live migratie en HA hangen af van de opslag onder het cluster. Kies die vóór je de eerste VM verhuist; achteraf omzetten is een tweede migratie.
- Andere virtuele hardware — een geïmporteerde Linux-VM krijgt een andere netwerkkaart en schijfcontroller. De interfacenaam verandert, en een statische netwerkconfiguratie die naar de oude naam verwijst, brengt de machine zonder netwerk op. Dat kun je voorkomen: zet bij Linux-VM's vóór de migratie de interfacenaam vast op het MAC-adres, bijvoorbeeld met een systemd-
.link-bestand of een udev-regel, en neem in Proxmox het MAC-adres van de oude VM over. Dan heet de interface na de import nog precies hetzelfde. - Monitoring op het oude platform — draait je monitoring zelf op het VMware-cluster, dan verlies je het zicht precies tijdens de migratie. Zet hem eerst over of daarbuiten.
Een stappenplan in de juiste volgorde
De volgorde is die van elke infrastructuurverhuizing: netwerk, opslag, compute.
- Inventariseer — welke VM's, welke afhankelijkheden, welke koppelingen met back-up en monitoring, en wanneer loopt de VMware-licentie af. Die datum is je deadline.
- Ontwerp netwerk en opslag — VLAN's, bonding, het clusternetwerk apart van het verkeer van de VM's, en de opslagkeuze.
- Bouw het cluster naast het oude — als code, zodat een tweede node of een herinstallatie een herhaling is in plaats van handwerk.
- Regel back-ups voordat er productie op staat — en herstel een VM proef voordat je erop vertrouwt.
- Verhuis eerst wat weinig kwaad kan — een paar interne VM's, om de importfunctie, de netwerkconfiguratie en je runbooks te testen.
- Verhuis per applicatie — met een onderhoudsvenster en een terugweg zolang het oude platform er nog staat.
- Ruim op — documentatie bijwerken, scripts omzetten, en VMware pas afbouwen als de laatste afhankelijkheid weg is.
Hoe lang dat duurt, verschilt per omgeving. Drie hosts met een handvol VM's is iets anders dan meerdere clusters met honderden machines en een back-upketen die erop leunt.
Overstappen met hulp
Wij kennen Proxmox van ons eigen werk en helpen je met het ontwerp, de bouw als code en de migratie zelf. Daarna kun je het cluster zelf beheren of het met managed servers aan ons overlaten, waarbij root van jou blijft. Wil je de hardware in een Nederlands datacenter op ons eigen netwerk, kijk dan bij colocatie. Moeten er ook scripts en koppelingen tegen de vSphere-API mee, dan pakken we die op via software-ontwikkeling. Staat jouw VMware-verlenging op de agenda: neem contact op.