vCenter Server Appliance 5.5: Funktionen und Limitierungen

    vCenter Server ApplianceVMware positioniert das vCenter Server Appliance (vCSA) als kostengünstige und unkomplizierte Alternative zu einer herkömmlichen vCenter-Installation unter Windows. Auch wenn die Zielgruppe kleine und mittlere Unternehmen sind, so war das vCSA 5.1 selbst dafür in seinen Fähigkeiten allzu limitiert. In der Version 5.5 macht es aber erhebliche Fortschritte vor allem bei der Skalierbarkeit.

    Das vCenter Server Appliance ist eine vorkonfigurierte virtuelle Maschine auf Basis von Linux, die fast alle Komponenten eines vCenter-Servers enthält. Das Appliance-Konzept bietet gleich zwei Vorteile: Zum einen entfällt die relativ aufwändige Installation, weil sich die Inbetriebnahme auf den Import einer OVA-Datei und die Konfiguration mittels Web-Oberfläche beschränkt. Zum anderen sparen sich Anwender damit die Lizenzkosten für Windows Server und je nach Setup auch für SQL Server.

    Eingebettete Datenbank mit beschränkter Leistung

    Zum Lieferumfang des vCSA gehört nämlich die integrierte vPostgres-Datenbank, so dass die gesamte vSphere-Konfiguration innerhalb des Appliance gespeichert wird. Gleichzeitig ist die eingebettete Datenbank aber der Flaschenhals beim Management einer größeren Umgebung. Sie beschränkt die maximale Zahl der ESXi-Hosts auf 100 und jene der VMs auf 1000. Sie bedeutet im Vergleich zu den bisherigen Obergrenzen von 5 Hosts und 50 VMs jedoch einen großen Fortschritt.

    Das vCenter Server Appliance unterstützt derzeit neben der eingebetteten Datenbank nur Oracle.

    Das Appliance selbst erreicht die gleichen Maximalwerte wie eine vCenter-Installation auf Windows Server, wenn man eine externe Oracle-Datenbank verwendet. In dieser Konfiguration sind dann bis zu 1000 Hosts und 10.000 VMs möglich.

    Unvollständiger Funktionsumfang

    Auch wenn vCSA zusammen mit einer externen Datenbank gleich leistungsfähig ist wie vCenter unter Windows, so hinkt es beim Funktionsumfang noch hinterher. Die fehlenden Features werden in der Praxis häufig darüber entscheiden, ob das vCSA für eine bestimmte Umgebung geeignet ist.

    Nicht unterstützt werden:

    • vCenter Linked Mode: Dieser verbindet mehrere vCenter-Server, um ihnen den Austausch von Informationen zu erlauben. Auf diese Weise kann ein Administrator, der an einem vCenter Server angemeldet ist, sich mit einem weiteren verbinden und dessen Inventar verwalten. Linked Mode verwendet Active Directory Application Mode (ADAM) für die Synchronisierung der Daten. Es wird unter Windows zusammen mit vCenter installiert.
    • vCenter Heartbeat: Dabei handelt es sich um einen Windows-Service, der Hochverfügbarkeit und Disaster Recovery für vCenter gewährleisten soll. Er wird in LANs für HA und in WANs für DR konfiguriert, um vCenter Server, View Composer und MS SQL Server zu schützen.
      Update: VMware stellte die Entwicklung und den Verkauf von vCenter Heartbeat ein. Daher spielt dieses Feature künftig keine Rolle mehr bei der Entscheidung zwischen vCSA und vCenter unter Windows.
    • Security Support Provider Interface (SSPI): Es ist Teil von vCenter SSO und implementiert ein Windows-API, das für die Authentifizierung über Kerberos und NTLM benötigt wird.
    • VMware Update Manager (VUM) und View Composer: Sie lassen sich nicht im vCSA installieren und müssen separat auf einer (virtuellen) Maschine unter Windows Server eingerichtet werden. Für jeden vCenter Server ist eine eigene Instanz von VUM erforderlich, der obendrein SQL Server benötigt. Auf diesem Weg kommen die durch das vCSA vermiedenen Lizenzkosten für Microsoft doch wieder ins Spiel.
    • vCenter-Plugins von Drittanbietern: Möglicherweise sind einzelne von ihnen nicht mit dem vCSA kompatibel. Das muss im Einzelfall geprüft werden.
    • SQL Server: Als externe Datenbank kommt nur Oracle in Frage, der sonst von vCenter bevorzugte MS SQL Server wird vom vCSA nicht unterstützt.

    Mit der Version 5.5 des vCenter Server Appliance macht VMware einen großen Schritt in Richtung Unabhängigkeit der vSphere-Administration von Windows. Für (größere) Umgebungen wird es dann eine echte Alternative zum herkömmlichen vCenter Server, wenn VMware künftig auch den Linked Mode unterstützt und VUM auf Linux portiert.

    Aber selbst dann, wenn vCSA um diese Features ergänzt wird, kommt es für die meisten bestehenden vSphere-Umgebungen nicht in Frage. Der Grund dafür sind die fehlenden Migrationswerkzeuge, so dass Anwender die Konfiguration bestehender vCenter Server unter Windows manuell auf vCSA übertragen müssten.

    2 Kommentare

    Bild von Michael Jelinski
    9. März 2014 - 22:53

    Vielen Dank für diesen interessanten Artikel. Was ich dabei noch nicht verstanden habe: Ist es sinnvoll und sicher die Verwaltungssoftware für die VM Hosts in einer virtuellen Maschine auf den zu verwaltenden Hosts laufen zu lassen?

    Bild von Christoph Herdeg
    12. April 2014 - 11:22

    Hallo Herr Jelinski,

    Ja, das ist für vCenter genauso sinnvoll und sicher wie für alle anderen Server-Typen.

    HA, DRS, vMotion und viele andere Features, die den Server-Betrieb unter VMware "besser" machen als den physischer Buden, gelten für vCenter Server genau wie für alle anderen Dienste/Anwendungen. Also ich möchte keinen baugleichen vCenter Server "heiss" (und mit stundenaktuellem Datenbestand) vorhalten müssen, nur damit ich im Fall eines Hardwaredefekts des ersten ein Fallback habe. Ganz abgesehen davon ist vCenter ja wie Sie sagen, grundsätzlich eine Verwaltungssoftware. Die einzelnen Hosts sind auch in der Situation eines ausgefallenen vCenters eingeschränkt nutz- und managebar; der Betrieb von arbeitenden VMs läuft weiter, als wäre nichts passiert.

    Wenn man sich ein paar Scripte zurechtbaut, kann man bei Nutzung einer virtuellen Maschine als vCenter Server seine komplette Infrastruktur deckungsgleich und in wenigen Minuten auf einem komplett neuen vCenter einrichten - auf einer Hardware sehe ich das so nicht.

    Viele Grüße,
    Christoph Herdeg