VMware vSphere zu Proxmox VE für Service Provider Hosting

[fastpath]

Liebe Community,

leider sind auch wir bekannter weise von der Kündigungswelle unter VMware betroffen. Es ist schon erschreckend was dort aktuell abgeht, aber das ist ein anderes Thema.

Ursprünglich wollten wir unsere Hosting Farm bestehend aus 6x nagelneue DELL R760 Servern (HCI) sowie 12x DELL R740 Servern (Computing) auf Basis von vSphere 8 aufbauen. Als Storage Virtualisierungsprodukt sollte StarWind VSAN zum Einsatz kommen. Wir haben sehr viel Erfahrung mit beiden Produkten und konnten in Vergangenen Projekten mühelos 300.000 IOPS (4k) und einen Streaming Speed von 8 GB/s (lesend) innerhalb von VM's erzielen.

Da aber das Zeitalter VMware aufgrund verschiedener Dinge für uns zu kippen droht, sind wir bei der Suche nach Alternativen auf Proxmox gestoßen. Proxmox ist uns nicht ganz unbekannt, da schon kleinere Projekte umgesetzt wurden.

Wir überlegen nun, ein reines Proxmox Datacenter mit Ceph aufzubauen. Da die 6x R760 Server noch nicht in Betrieb sind, können wir das gefahrlos machen. Müssen aber dann im Nachgang ca. 95 TB an VM von VMware zu Proxmox migrieren . Danach die Computing nodes.

Die Server haben folgende Specs:
DELL R760
2x Intel Xeon Gold 3,6 GHz
1TB Memory DDR5
1x DELL Boss Card mit 2x m.2 SATA SSD (raid-1)
14x 3,84 TB SAS SSD
1x Perc H755 RAID Controller
4x Mellanox Connectx-6 25 Gbit Dual Port cards

Gibt es hier Community Member die in ähnlicher Größe bereits Proxmox mit ceph betreiben ? Könnt ihr ein paar Empfehlungen hinsichtlich der Einstellungen geben ?

Die Umgebung soll an mehrere Redundante Cisco Nexus Leaf Switche angebunden werden. Alles mit 25 GBit/s.

 

[Falk R.]

Hi, das Hardwaresetup klingt schon ganz gut, aber Ceph ist ein wenig Netzwerk Bandbreitenhungrig (So wie S2D oder vSAN).
Wenn das ganze für eine Streamingplatform ist, habt ihr ja hauptsächlich Read, da ist Ceph ganz gut unterwegs und sollte eure gewünschten Werte locker schaffen. Ich Persönlich baue größere Cluster lieber mit 100G Netzwerk für Ceph auf, aber wenn ihr 4 Dual Karten habt, kann man für Ceph mit einem LACP über 4 Ports auch richtig was rausholen.
Wenn ihr bisher mit Starwind die Performance raus bekommen habt, dann steht dem Projekt ja nix im Wege.

Die Migration von vSphere zu PVE ist auch nicht schwer und lässt sich mit minimaler Downtime bewerkstelligen.

P.S. bei der Kilux wurde mein Vortrag über Migration zu Proxmox aufgezeichnet und ist z.B. bei Youtube zu finden.

 

[fastpath]

Erstmal herzlichen Dank für die Antworten.

Schaue mir gerade den Vortrag an. Sehr sehr informativ und echt Klasse. Weiter so

Leider können wir an der Netzwerksituation nichts weiter ändern, da unsere Netzwerkabteilung in diesem Bereich alles erneuert hat. Lediglich an der Konfiguration auf Server Seiten haben wir viel Spielraum. Daher finde ich die Idee mit 4x 25 GBit/s im LACP echt gut. Aktuell sieht die Situation so aus, das wir uns 3x Nodes zum testen geschnappt haben und mit denen einen CEPH Cluster aufgebaut haben. Die restlichen 3x sind noch im vCenter vorhanden. Die Systeme sind mit jeweils 2x 25Gbit/s im LACP für Ceph angebunden. Die ersten Tests sahen eigentlich ganz gut aus, jedoch sind wir da an der Stelle noch weit entfernt von den 300.000 IOPS 4k die bisher mit StarWind VSAN im ISCSI Bereich über 2 Pärchen mit Multipathing in den VM´s geliefert werden können. Ich habe gestern einmal getestet, wie die Performance sich verhält, wenn wir ohne LACP im Ceph arbeiten und konnte leider keinen aktuellen Benefit feststellen. Aktuell liefert die Konfiguration im Diskspd in einer Test VM ca. 170.000 IOPS 4K. Habe dazu mal einen Screenshot angehangen. Darunter zu finden den gleichen Test auf Basis von StarWind VSAN mit ISCSI. StarWind kann man auch unter Proxmox nutzen, jedoch wäre es natürlich Klasse, wenn wir uns die Lizenzkosten dafür sparen können um den gleichen Benefit mit Ceph zu erzielen.

Wir haben allerdings auch noch nichts weiter an den Ceph Einstellungen optimiert. Lediglich Jumbo Packets wurden auf den Netzwerkkarten aktiviert.

 

[Falk R.]

Hi,
brauchst du die Performance auf einer VM oder einer vDisk? Dann ist Ceph natürlich nicht so optimal, da Ceph seine Stärken in der Skalierung hat und mit verteiltem Workload erst richtig gut performt.
Benchmarks sind auch nur ein Hinweis was kommen kann, weißt du welche I/O Größen ihr bei eurer Anwendung habt?
Teste mal mit dem Ceph 16k I/O. Meiner Erfahrung nach performt das deutlich besser. Am besten macht man Benchmarks mit der echt genutzten Blocksize, da kann man die Realworld Performance besser vergleichen. 4k wird ja immer nur genommen, weil da die Werte schön hoch ausfallen und viele Hersteller tunen für 4k, obwohl das im Reallife eher weniger vorkommt.
Die ganze alten Oracle Installationen, welche ich kenne, produzieren hauptsächlich 8k IO und die aktuellen MS SQL machen zum Großteil 64k IO.

Ein großer Unterschied zu Starwind ist, da machst du einen einfachen Mirror zwischen 2 Instanzen, 1x Frontend IO = 1x Mirror IO. Bei Ceph geht der IO an ein OSD und der verteilt bei der klassischen 3x Replikation die Daten an zwei weitere OSD. Damit erhöht sich natürlich der Traffic. Bei Read ist der Traffic vergleichbar, aber da man immer gemixten Workload hat, muss das eingeplant werden.

PVE mit Ceph kann bei den großen Benchmarks wie zum Beispiel VM Fleet (VMware Massen VM Benchmark) auch richtig punkten, da sich die gute Skalierung dann positiv auswirkt.

 

[sb-jw]

Ich hatte hier schon mal ein paar Basics zu CEPH erwähnt: https://forum.proxmox.com/threads/i...ist-extrem-schlecht.134760/page-2#post-622831

Schaut doch mal über die Liste drüber, ob ihr davon noch etwas adaptieren könnt und damit womöglich noch etwas mehr rausholen könnt.

 

[fastpath]

Besten Dank, sehr informativ

Den Workload kennen wir leider nicht genau, das wir in diesem Bereich Kunden VM´s hosten welche natürlich verschiedene Charakteristika haben. Der Workload ist also eher Random IO. Aber die Tipps sind schon sehr gut. Ich schaue mir das mal in Ruhe an.

 

[Falk R.]

Besten Dank, sehr informativ

Den Workload kennen wir leider nicht genau, das wir in diesem Bereich Kunden VM´s hosten welche natürlich verschiedene Charakteristika haben. Der Workload ist also eher Random IO. Aber die Tipps sind schon sehr gut. Ich schaue mir das mal in Ruhe an.

Wenn das viele verschiedene Kundensysteme sind, habt ihr vernünftig verteilten Workload und da kommt bei Ceph in Summe garantiert mehr raus als bei Starwind. Bei Starwind ist das pro System ein Prozess, der den I/O verarbeiten muss. Bei den OSD stehr das D einmal für Disk aber auch für Deamon. Du hast also bei Ceph pro Disk einen Deamon der den Workload verarbeitet, deshalb kann Ceph so gut skalieren und wird auch oft in ganz großen Umgebungen eingesetzt.
Für einen Objektiven Vergleich muss man natürlich echten Workload zugrunde legen und keinen synthetischen Benchmark.

 

[fastpath]

Also wir haben unseren Test inkl. Proxmox Backupserver fast abgeschlossen und müssen sagen das viele Dinge wirklich gut sind, jedoch einige Sachen im Vergleich zu VMware vSphere jedoch fehlen. Auch haben wir eine Aufwandsabschätzung betrieben wie wir wechseln können und sind zu dem aktuellen Entschluss gekommen, das es unmöglich ist in kurzer Zeit zu wechseln. Geschweige denn unsere Kundenverträge und SLA nicht zu erfüllen. Wir hosten knapp 750 VMs auf unseren Systemen über viele Kunden hinweg und müssten faktisch jede VM einmal anpacken. Da sind teilweise Fileserver, Exchange Server, SQL usw. dabei die riesig sind und nicht mal eben mit einer langen Downtime versehen werden können. Bzw. in Kundenverantwortung liegen. Die Kunden müssten dies für Ihre Geschäftsfelder und deren eigenen Kunden einplanen. Das ist ein wirklich schwieriges Unterfangen. Wir nutzen seit 15 Jahren vSphere und hätten nicht gedacht das wir mal in diese Situation kommen. Hätten wir jedoch eine grüne Wiese, würden wir definitiv zu Proxmox wechseln da viele aus meinem Technikerteam begeistert sind. Wird noch spannend werden die nächsten Monate.

 

[Falk R.]

Also ohne Downtime geht es nicht. Man muss natürlich auch jede VM anfassen.
Aber die Downtime beträgt pro VM ca. 5 Minuten (je nach Bootdauer) und wenn man so viele VMs innerhalb einer Umgebung bewegen muss, lohnt es sich auch dies zu scripten. Ich durfte vor ein paar Jahren eine Migration von ca. 3000 VMs von vSphere nach RHEV begleiten, damals als Unterstützung für die vSphere Themen. Dort wurde keine VM manuell migriert sondern alle per Script.

Wie habt ihr denn bei eurem POC die VMs migriert?

 

[fastpath]

Ich wäre auch gerne so optimistisch und lobe bin auch für jeden Tipp dankbar, allerdings gibt es hier mehrere Probleme.

1. Wir haben teilweise keinerlei Administrative Rechte innerhalb der VMs. Da diese in Kundenverantwortung liegen und wir als Hoster agieren. Somit muss das von all den betroffenen Kunden selbständig erledigt werden.

2. Nach erfolgreicher Migration muss in den VMs der passende VirtIO Treiber installiert werden, Laufwerksbuchstaben wieder korrekt zugeordnet werden und selbe IP wie vorher konfiguriert werden. Bei Systemen wie AD, gar nicht mal so einfach wenn die Vertrauensstellung nicht mehr geht und kein Lokaler Admin vorhanden ist und somit die Anmeldung nicht geht. Hilft nur ein erreichbarer DHCP mit Reservierung. Haben selbiges schon mehrfach bei V2V von VMware zu Hyper-V gehabt.

3. Da der Proxmox Backup Server im Imagelevel Backup Bereich keine Application Awareness unterstützt, können keine Anwendungsdaten wie AD,Exchange und SQL wiederhergestellt werden. Kunden zahlen allerdings dafür,da wir auch beim Veeam das Serviceprovider Modell nutzen und dieses Feature gewünscht wurde. Inkl. Transaktions Log Backups.

Bei den Test Migrationen haben wir uns den Mitteln aus deinem Video bedient. NFS mount, Storage vMotion und dann VM neu erstellen und anpassen.

 

[Falk R.]

Ich wäre auch gerne so optimistisch und lobe bin auch für jeden Tipp dankbar, allerdings gibt es hier mehrere Probleme.

1. Wir haben teilweise keinerlei Administrative Rechte innerhalb der VMs. Da diese in Kundenverantwortung liegen und wir als Hoster agieren. Somit muss das von all den betroffenen Kunden selbständig erledigt werden.

Das lässt sich lösen.

2. Nach erfolgreicher Migration muss in den VMs der passende VirtIO Treiber installiert werden, Laufwerksbuchstaben wieder korrekt zugeordnet werden und selbe IP wie vorher konfiguriert werden. Bei Systemen wie AD, gar nicht mal so einfach wenn die Vertrauensstellung nicht mehr geht und kein Lokaler Admin vorhanden ist und somit die Anmeldung nicht geht. Hilft nur ein erreichbarer DHCP mit Reservierung. Haben selbiges schon mehrfach bei V2V von VMware zu Hyper-V gehabt.

Das wird tatsächlich schon schwieriger und bedarf einigen manuellen Eingriffen.

3. Da der Proxmox Backup Server im Imagelevel Backup Bereich keine Application Awareness unterstützt, können keine Anwendungsdaten wie AD,Exchange und SQL wiederhergestellt werden. Kunden zahlen allerdings dafür,da wir auch beim Veeam das Serviceprovider Modell nutzen und dieses Feature gewünscht wurde. Inkl. Transaktions Log Backups.

Konsistente Sicherungen sind da, aber die Recovery Tools für die Applikationen sind tatsächlich ein echtes Problem. Ich löse das bei meinen Kunden mit dem Veeam Agent, aber als Provider bekommst du bestimmt nicht genug Rechte.
Ich bin gespannt wie euer Vertragswerk aussieht, wenn ihr einen solchen Service anbietet und über den Restore vollen Zugriff auf die Kundendaten habt.

Bei den Test Migrationen haben wir uns den Mitteln aus deinem Video bedient. NFS mount, Storage vMotion und dann VM neu erstellen und anpassen.

 

[fastpath]

Danke für die Antwort Da ich Techniker bin, kenne ich die genauen Verträge dahinter nicht. Allerdings verwenden wir die Veeam Service Provider Komponenten, Cloud Connect und mehr inkl. Tenant Verwaltung. Die Kunden haben jeweils Zugriff darauf. Es gibt abgespeckte Rechte von unserer Seite und nur authorisiertes Personal hat Zugriff.

Das geht allerdings schon zu weit. Veeam Agent war aus Sicht unserer Netzwerk und Security Abteilung erstmal vom Tisch, da die Veeam Server faktisch die Ports des Agenten in den Systemen erreichen müssen. Aktuell läuft das Backup via SAN Transport Modus und VIX per Application Aware über spezielle Logon Server. Somit auf der Seite so wenig Erreichbarkeit wie möglich. Hier ist alles ziemlich gehärtet und wurde jüngst wieder extern auditiert. Wie gesagt, wir sind (waren) VMware Cloud Provider.

Verstehe allerdings die Bemerkung hinsichtlich der Verträge nicht. Beim Proxmox Backup Server erhält man doch genauso volle Rechte auf die Daten, da dort ja auch ein Restore von einzelnen Files möglich ist.

 

[Falk R.]

Naja Filerestores gehen ja immer, aber Application Aware (Mails oder Datenbanktabellen) ist noch eine Stufe mehr.

Aber wenn das alles sauber Auditiert ist, hat sich wohl jemand gut Gedanken gemacht. Habe ich leider auch schon anders gesehen.

Dann wäre für euere Konzept mit Veeam maximal noch Microsoft Azure Stack HCI, eine Option.