Abrechnung in Euro aus Deutschland. Weitere Sprachen und Währungen sind derzeit nicht verfügbar.
Private Cloud · Verwaltetes vSphere
Dedizierte Hosts unter einem vCenter, das Ihnen allein gehört — vCenter ist die Verwaltungsinstanz von vSphere. Fällt ein Host aus, startet HA die betroffenen Gäste neu. DRS verteilt die Last im laufenden Betrieb, vMotion räumt einen Host vor der Wartung leer. Der Preis gilt je Host — und vSphere setzt 2 davon voraus.
Der Einstiegspreis ist ein Hostpreis, kein Clusterpreis. PC-S32 ist unter vSphere nicht freigegeben: Die Klasse hat keine getrennte Speicher-Fabric und damit keinen geteilten Datastore. Ohne den startet HA nichts neu.
Eckdaten
Dieselben vier Fragen beantworten die Seiten zur Hyperkonvergenz und zu den Datenspeichern an derselben Stelle. Die Antworten fallen unterschiedlich aus — vor allem die zweite.
Preis- und Lizenzmodell
Ein verwalteter Host kostet das Blech plus den Plattformbetrieb. Die vSphere-Lizenz steckt bewusst nicht darin: Sie hängt am Stack, nicht am Host, und wird je Kern und Monat berechnet.
Der Einstieg liegt bei 937,82 € — und das ist der Preis eines Hosts der Klasse PC-M64i, nicht der eines Clusters. vSphere setzt 2 Hosts voraus, weil HA sonst niemanden hat, auf den es einen ausgefallenen Gast neu starten könnte. Der kleinste zulässige Cluster kostet damit 1.875,64 € netto im Monat, noch ohne Datastore.
Die Lizenz kostet 9,90 € je Kern und Monat, mit einer Mindestabnahme von 16 Kernen je Sockel. Auf PC-M64 sind das 48 Kerne und damit 475,20 € je Host und Monat. Die Mindestabnahme greift im heutigen Katalog auf keiner freigegebenen Klasse — die kleinste hat 32 Kerne je Sockel. Sie ist eine Zusicherung für den Fall, dass eine kleinere Klasse nachrückt, kein versteckter Aufschlag.
Abrechnung nach Kernen heißt: Verdichtung spart nichts an der Lizenz. 96 Kerne kosten dasselbe, ob sie in einem oder in zwei Sockeln stecken. Was sich unterscheidet, ist der Betrieb — zwei Hosts erfüllen die Mindestclustergröße, einer nicht.
Der Lizenzanteil an der Plattform liegt im Einstiegscluster bei 34 %. Das ist die Zahl, die den Unterschied zu einem offenen Hypervisor ausmacht — nicht der Hostpreis, der ist in beiden Fällen derselbe.
2 × PC-M64i mit einem gemeinsamen Datastore NVMe Standard über 4 TB — die kleinste Zusammenstellung, in der HA tatsächlich etwas bewirkt.
Beide Stacks laufen auf demselben Blech. Der Unterschied liegt nicht in der Hardware, sondern in dem, was die Verwaltungsebene im Betrieb selbst tut — und darin, was das je Kern kostet. Auf PC-M64 stehen 49,00 € gegen 475,20 € im Monat.
| Merkmal | ENTRONYX KVM PlatformOffene Plattform | ENTRONYX Managed vSphereDieser Stack |
|---|---|---|
| Lizenzmodell | je Sockel und Monat | je Kern und Monat |
| Lizenzsatz | 49,00 € | 9,90 € |
| Lizenz auf PC-M641 Sockel, 48 Kerne | 49,00 € | 475,20 € |
| Cluster von … bis | 1 – 16 Hosts | 2 – 32 Hosts |
| Freigegebene Host-Klassen | 5 | 4 |
| Laufende Lastverteilung im BetriebDRS verschiebt Gäste, ohne dass jemand eingreift | ||
| HA-Neustart nach Hostausfall | ||
| Live-Migration in einer CPU-Generation | ||
| Eigene Verwaltungsinstanz je Mandant | ||
| Synchrone Metro-Spiegelung buchbarRPO 0 Minuten | ||
| Wartungsfenster | Di und Do 02:00–05:00 MEZ, Ankündigung 10 Kalendertage vorher | Mi 02:00–06:00 MEZ, rollierend Host für Host, Ankündigung 14 Tage vorher |
Wer heute vCenter fährt, bringt Vorlagen, Rollen, Portgruppen und Betriebsverfahren mit. Der Umzug ist eine Verlagerung, keine Neuentwicklung: Export und Import im offenen Austauschformat OVF führen zum selben Objektbaum.
Datenbanken, die nach physischen Kernen lizenziert werden, brauchen eine harte Zuordnung von Gast zu Host. Affinitätsregeln am Cluster halten die betroffenen Gäste auf benannten Hosts, statt sie über den ganzen Cluster wandern zu lassen.
Eigenes vCenter, eigener Distributed Switch, eigene Datastores: Die Trennung liegt in getrennten Objekten, nicht in einer Rechteregel auf gemeinsamen. Das lässt sich in einer Prüfung zeigen.
Für einen einzelnen Host, für Entwicklungsumgebungen ohne Verfügbarkeitsanspruch und für Lasten, die ohnehin containerisiert laufen, ist die Lizenz je Kern der teuerste Weg zum Ziel. Dort ist die KVM-Plattform oder verwaltetes Kubernetes richtig.
Host-Klassen
Jede Klasse ist ein dediziertes Blech mit einem festen Schnitt aus Kernen, Arbeitsspeicher, lokaler NVMe und Anbindung. Die Summe nennt Host und Lizenz zusammen — der Betrag, der je Host und Monat auf der Rechnung steht.
Host-Klassen unter ENTRONYX Managed vSphere mit CPU, zuweisbarem Arbeitsspeicher, lokaler NVMe, Anbindung, vCPU-Obergrenze, Lizenz und Monatspreis je Host — alle Beträge netto.
EPYC 9454P2,75 – 3,80 GHz · 1 Sockel
Xeon 6731P2,50 – 4,10 GHz · 1 Sockel
EPYC 95543,10 – 3,75 GHz · 1 Sockel
2× EPYC 99652,25 – 3,70 GHz · 2 Sockel
| Klasse | Prozessor | Kerne / Threads | RAM zuweisbar | Lokale NVMe | Anbindung | vCPU-Deckel | Lizenz / Monat | Summe / Monat |
|---|---|---|---|---|---|---|---|---|
| PC-M64PC-M | EPYC 9454P2,75 – 3,80 GHz · 1 Sockel | 48 / 96 | 232 GB | 7,68 TB | 1 Gbit/s | 288(6:1) | 475,20 € | 1.431,22 € |
| PC-M64iEinstiegPC-M | Xeon 6731P2,50 – 4,10 GHz · 1 Sockel | 32 / 64 | 232 GB | 3,84 TB | 1 Gbit/s | 192(6:1) | 316,80 € | 937,82 € |
| PC-L128PC-L | EPYC 95543,10 – 3,75 GHz · 1 Sockel | 64 / 128 | 472 GB | 7,68 TB | 10 Gbit/s | 256(4:1) | 633,60 € | 2.061,09 € |
| PC-X256PC-X | 2× EPYC 99652,25 – 3,70 GHz · 2 Sockel | 384 / 768 | 960 GB | 7,68 TB | 25 Gbit/s | 1.536(4:1) | 3.801,60 € | 7.726,68 € |
Der zuweisbare Arbeitsspeicher ist die Bestückung abzüglich der Reservierung für den Hypervisor — auf PC-M64i sind das 24 GB von 256 GB. Der Anteil sinkt mit wachsender Bestückung: PC-X256 behält 64 GB von 1 TB zurück.
Cluster konfigurierenEine Klasse ohne genannte Grenze ist eine Klasse, deren Grenze noch niemand gesucht hat. Hier steht sie für jede der vier.
Ein Sockel, ein NUMA-Knoten: VMs über 232 GB RAM passen nicht mehr auf diese Klasse. Für breitere Einzel-VMs ist PC-L128 oder PC-X256 der richtige Schnitt.
Live-Migration ist nur zwischen Hosts derselben CPU-Generation zugesichert. Ein gemischter Cluster aus PC-M64 (AMD) und PC-M64i (Intel) migriert nicht im laufenden Betrieb.
Der Boost endet bei 3,75 GHz. Lasten, die an einzelnen Threads hängen, laufen auf PC-M64i mit 4,1 GHz schneller — die Klasse gewinnt über Breite, nicht über Takt.
Zwei Sockel bedeuten zwei NUMA-Knoten. VMs über 480 GB RAM oder über 192 vCPU überschreiten einen Knoten und verlieren rund 12 % Speicherbandbreite — bei Lizenzen je Kern zahlt dieser Host außerdem 384 Kerne.
Die Klassen unterscheiden sich in der Verfügbarkeit. PC-M64i steht an 3 Standorten, PC-X256 an 3. Ein Cluster liegt immer vollständig an einem Standort — verteilte Cluster über zwei Regionen entstehen erst über die Wiederherstellungsstufen.
Verfügbar für PC-M64i 3
Overcommit
Jede Host-Klasse trägt eine zugesicherte Obergrenze an vCPU je physischem Kern. Darüber wird nicht platziert — auch nicht kurzzeitig, auch nicht während einer Evakuierung.
Das Verhältnis wird strenger, je dichter die Klasse bestückt ist. Auf PC-M64i sind 6 vCPU je Kern zugesichert, auf PC-X256 nur noch 4. Der Grund liegt nicht in der Rechenleistung, sondern in der Speicherbandbreite: Sie wächst mit der Kernzahl nicht mit, und ein überbuchter Kern wartet dann auf Daten statt auf Rechenzeit.
Unter vSphere liegt die zulässige Speicherüberbuchung auf 0 % — auf allen freigegebenen Klassen. Was Sie einem Gast zuweisen, ist physisch vorhanden. Ballooning — der Hypervisor holt sich ungenutzten Speicher aus einem Gast zurück — und Speicherverdichtung bleiben als Notmechanismen aktiv. Bestandteil der Kapazitätsplanung sind sie nicht: Der Latenzverlust unter Last kostet mehr, als der gewonnene Speicher wert ist.
In der Praxis ist deshalb der Arbeitsspeicher die bindende Grenze, nicht die Kernzahl. Gäste mit 2 vCPU und 4 GB füllen PC-M64i nach 58 Gästen — belegt sind dann 116 der 192 zulässigen vCPU.
Die dritte Grenze ist die Zahl der Gäste selbst. Sie hängt nicht an Rechenleistung oder Speicher, sondern an dem, was jeder laufende Gast dauerhaft an Verwaltung kostet: Überwachungspfade, Netzports auf dem Distributed Switch, Warteschlangen am Datastore. Ein Cluster aus 32 Hosts der Klasse PC-X256 trägt rechnerisch 20.480 Gäste — die praktische Grenze setzt vorher der Datastore.
Zuweisbar, nicht empfohlen. Wer eine Verfügbarkeitszusage einhalten will, plant den Ausfall eines Hosts mit ein und bleibt darunter.
Verwaltungsebene
Dediziertes vCenter je Kunde, API-Zugang, SSO gegen Ihr Verzeichnis
Ihre Umgebung hängt an einer eigenen vCenter-Instanz, nicht an einer geteilten mit Mandantenfiltern. Sie sehen Ihre Cluster, Ihre Datastores und Ihre Aufgabenliste — nicht die von jemand anderem, auch nicht gefiltert.
Fällt ein Host aus, startet vSphere HA die betroffenen Gäste auf den verbleibenden Hosts neu. Das ist ein Neustart, keine unterbrechungsfreie Übernahme: Der Gast verliert seinen Arbeitsspeicherzustand und fährt aus seinem Dateisystem wieder hoch.
DRS verschiebt laufende Gäste per vMotion zwischen Hosts, wenn die Verteilung auseinanderläuft. Dieselbe Mechanik evakuiert einen Host vor der Wartung: Der Wartungsmodus schiebt jede laufende VM weg, bevor der Host neu startet.
Das Netz wird einmal am Cluster konfiguriert, nicht Host für Host. Jedes Projekt bekommt seine eigene Portgruppe mit eigenem VLAN; ein neuer Host übernimmt die Konfiguration beim Beitritt, ohne dass Sie ihn nachziehen.
Die Grenze zwischen Ihrer und unserer Zuständigkeit liegt an der Host-Oberkante: Hypervisor, Firmware, Fabric und Speicher-Controller pflegen wir. Alles ab dem Gastsystem bleibt bei Ihnen — sofern Sie keine höhere Betriebsstufe buchen. Das vCenter selbst bedienen beide Seiten; Ihre Rollen sind dieselben, die Sie aus einer eigenen Installation kennen.
Wartungsfenster
Mi 02:00–06:00 MEZ, rollierend Host für Host, Ankündigung 14 Tage vorher. Kein Fenster nimmt den Cluster außer Betrieb — es nimmt jeweils einen Host heraus. Was das kostet, steht in der Kapazität: Solange ein Host fehlt, muss der Rest die volle Last tragen.
Sie erhalten Fenster, Umfang und die Liste der betroffenen Hosts. Ein Fenster ohne Änderung an Ihrem Cluster wird abgesagt, nicht stillschweigend leer durchlaufen.
Vom Cluster wird rechnerisch ein Host abgezogen. Passt die laufende Last nicht auf die verbleibenden Hosts, verschieben wir das Fenster — statt es zu beginnen und in der Mitte festzustellen, dass die Evakuierung nicht durchläuft.
Der Host geht in den Wartungsmodus, DRS verschiebt jede laufende VM per vMotion auf einen anderen Host. Die Gäste laufen währenddessen weiter; die Dauer hängt am belegten Arbeitsspeicher, nicht an der Zahl der Gäste.
BIOS, Speicher-Controller, Netzkarten und der ESXi-Build werden auf den Zielstand gehoben. Danach startet der Host neu und meldet sich am vCenter zurück.
Erst wenn ein Host wieder im Cluster steht und DRS die Last zurückverteilt hat, beginnt der nächste. Deshalb dauert das Fenster mit der Clustergröße länger — und deshalb bleibt der Cluster durchgehend verfügbar.
Ein Host fällt aus oder wird evakuiert — in beiden Fällen muss die Last auf die verbleibenden passen. Daraus folgt eine harte Obergrenze für die Belegung, und sie ist bei kleinen Clustern unbequem.
Der Wert ist die Belegung, bei der der Ausfall genau eines Hosts noch aufgefangen wird. Wer zwei gleichzeitige Ausfälle abdecken will, rechnet mit zwei fehlenden Hosts — bei 2 Hosts ist das nicht möglich.
Datastore und Wiederherstellung
Ohne gemeinsamen Speicher gibt es weder HA-Neustart noch vMotion noch eine wartungsfreie Evakuierung. Der Datastore wird deshalb zusammen mit dem Cluster bestellt, nicht danach.
Abgerechnet wird je Gigabyte und Monat, mit einer Mindestabnahme je Klasse. Die Zusage an IOPS — Ein- und Ausgabevorgängen je Sekunde — gilt je Datastore, nicht je Gast. Größere Umgebungen werden deshalb auf mehrere Datastores geschnitten statt auf einen großen.
NVMe over TCP für Datenbanken, die an der Schreiblatenz hängen.
Einschränkung: Die IOPS-Zusage gilt je Datastore, nicht je VM. Ein einzelner Gast erreicht sie erst mit mindestens vier parallelen Warteschlangen; mit einer Warteschlange bleiben rund 28.000 IOPS übrig.
Der Regelfall: NVMe-Backend über NFS oder iSCSI, für gemischte Gastlasten.
Einschränkung: Ab 24 gleichzeitig aktiven VMs auf einem Datastore fällt die zugesicherte Latenz von 0,9 ms auf 1,4 ms. Größere Umgebungen werden deshalb auf mehrere Datastores geschnitten.
NVMe-Cache vor HDD-Kapazität — für Dateidienste und ruhige Volumes.
Einschränkung: Der NVMe-Cache umfasst 8 % der Datastore-Größe. Arbeitsmengen darüber laufen auf die HDD-Ebene durch; die Latenzzusage von 4 ms gilt dann nicht mehr.
Unter ENTRONYX Managed vSphere stehen alle 4 Stufen offen — einschließlich der synchronen Spiegelung, die andere Stacks nicht bekommen. Jede Stufe nennt ihr RPO, den höchstens verlorenen Zeitraum, und ihr RTO, die höchstens nötige Anlaufzeit. Sie kostet einen Sockelbetrag je geschützter Umgebung plus einen Satz auf die geschützte Kapazität.
Nächtliche Sicherung in eine zweite EU-Region, Wiederanlauf auf Abruf.
Einschränkung: Der Wiederanlauf nutzt freie Kapazität der Zielregion. Ohne gebuchte Kapazitätsreservierung gilt die RTO-Zusage nur Mo–Fr 08:00–18:00; außerhalb dieser Zeit gibt es keinen zugesicherten Anlauftermin.
Ein vorgehaltener Host in der Zielregion, Replikation alle vier Stunden.
Einschränkung: In der Zielregion läuft ein einzelner Host mit rund 25 % der Produktivkapazität. Voller Durchsatz steht erst nach dem Zuschalten weiterer Hosts bereit — Vorlauf bis zu 90 Minuten.
Viertelstündliche Blockreplikation in eine Region desselben Rechtsraums.
Einschränkung: Das RPO von 15 Minuten gilt bis zu einer Änderungsrate von 40 MB/s je Datastore. Darüber wächst der Replikationsrückstand, und der tatsächliche Wiederherstellungspunkt liegt weiter zurück als zugesichert.
Kein Datenverlust: Jeder Schreibvorgang wird an beiden Standorten quittiert.
Einschränkung: Nur zwischen fra1 und fra2 verfügbar. Jeder Schreibvorgang kostet rund 0,3 ms zusätzlich, und logische Fehler werden synchron mitgespiegelt — die Stufe ersetzt kein Backup, sie ergänzt es.
Betrieb und Wartung
Der Plattformbetrieb steckt im Hostpreis und ist nicht abwählbar. Er endet an einer scharfen Kante: unterhalb des Gastsystems arbeiten wir, oberhalb arbeiten Sie.
Firmware-Wartung setzt eine Host-Evakuierung voraus. Ohne zweiten Host im Cluster bedeutet das eine Ausfallzeit von bis zu 45 Minuten je Wartungsfenster.
Wer auch das Gastsystem abgeben will, bucht eine höhere Betriebsstufe. Die Grenzen der Stufen stehen auf der Seite zu den verwalteten Hosts.
Der Einstiegscluster aus 2 × PC-M64i ist damit rechnerisch ein Ein-Host-Cluster: Was auf dem zweiten läuft, muss der erste im Wartungsfenster mittragen.
Nächster Schritt
Host-Klasse, Anzahl, Datastore, Wiederherstellungsstufe und Betriebsstufe stehen im Konfigurator nebeneinander. Die Summe rechnet mit denselben Sätzen, die auf dieser Seite stehen — es gibt keinen zweiten Preis hinter dem Angebot.
