Bevor Sie versuchen, viele virtuelle Maschinen mit einer einzigen vCenter Server-Instanz zu verwalten, müssen Sie die folgenden Aspekte berücksichtigen:
- Dauer der Wartungsfenster in Ihrem Unternehmen
- Toleranz von VMware Horizon-Komponentenausfällen
- Häufigkeit von Betriebs-, Bereitstellungs- und Neuanpassungsvorgängen
- Einfachheit der Infrastruktur
Dauer von Wartungsfenstern
Die Einstellungen für parallele Betriebs-, Bereitstellungs- und Neuanpassungsvorgänge für virtuelle Maschinen werden pro vCenter Server-Instanz festgelegt.
| Pod-Entwürfe mit einer vCenter Server-Instanz | Die Einstellungen für parallele Vorgänge bestimmen, wie viele Vorgänge zu einem bestimmten Zeitpunkt für einen ganzen Horizon 8-Pod in einer Warteschlange platziert werden können. Wenn Sie z. B. eine maximale Anzahl von 20 parallelen Bereitstellungsvorgängen festlegen und in einem Pod über nur eine vCenter Server-Instanz verfügen, werden die Bereitstellungsvorgänge bei einem Desktop-Pool mit mehr als 20 virtuellen Maschinen serialisiert. Nachdem 20 gleichzeitige Vorgänge in der Warteschlange platziert wurden, muss je ein Vorgang abgeschlossen werden, bevor mit dem nächsten Vorgang begonnen wird. In großen VMware Horizon-Bereitstellungen kann dieser Bereitstellungsvorgang viel Zeit in Anspruch nehmen. |
| Pod-Entwürfe mit mehreren vCenter Server-Instanzen | Jede Instanz kann gleichzeitig 20 virtuelle Maschinen bereitstellen. |
Um sicherzustellen, dass innerhalb eines Wartungsfensters mehr Vorgänge gleichzeitig ausgeführt werden können, können Sie Ihrem Pod mehrere vCenter Server-Instanzen (bis zu fünf) hinzufügen und mehrere Desktop-Pools in vSphere-Clustern bereitstellen, die von verschiedenen vCenter Server-Instanzen verwaltet werden. Ein vSphere-Cluster kann jeweils nur von einer vCenter Server-Instanz verwaltet werden. Um Parallelität über mehrere vCenter Server-Instanzen hinweg zu erreichen, müssen Sie Ihre Desktop-Pools entsprechend bereitstellen.
Toleranz von Komponentenausfällen
vCenter Server wird in Horizon 8-Pods für Betriebs-, Bereitstellungs- und Neuanpassungsvorgänge (Aktualisierung, Neuzusammenstellung und Neuverteilung) eingesetzt. Nachdem ein Desktop auf einer virtuellen Maschine bereitgestellt und eingeschaltet wurde, hängt VMware Horizon bei der Ausführung normaler Vorgänge nicht von vCenter Server ab.
Da jeder vSphere-Cluster von einer einzelnen vCenter Server-Instanz verwaltet werden muss, stellt dieser Server in jedem VMware Horizon-Entwurf eine einzelne Fehlerstelle dar.
Zusätzlich zu diesen automatisierten Optionen für das vCenter Server-Failover können Sie den ausgefallenen Server auch auf einer neuen virtuellen Maschine oder auf einem neuen physischen Server neu erstellen. Die meisten wichtigen Informationen werden in der vCenter Server-Datenbank gespeichert.
Die Risikotoleranz ist ein wichtiger Faktor bei der Entscheidung, ob in Ihrem Pod-Entwurf eine oder mehrere vCenter Server-Instanzen eingesetzt werden sollen. Wenn es erforderlich ist, Desktop-Verwaltungsaufgaben wie Betriebs- und Neuanpassungsvorgänge für alle Desktops gleichzeitig auszuführen, sollten Sie die Auswirkungen eines Ausfalls jeweils auf eine geringere Anzahl von Desktops beschränken, indem Sie mehrere vCenter Server-Instanzen bereitstellen. Wenn es tolerierbar ist, dass Ihre Desktop-Umgebung für eine längere Zeit nicht verfügbar ist, um Verwaltungs- oder Bereitstellungsvorgänge auszuführen, oder wenn Sie sich für einen manuellen Vorgang für die Wiederherstellung entscheiden, können Sie eine einzelne vCenter Server-Instanz für Ihren Pod bereitstellen.
Häufigkeit von Betriebs-, Bereitstellungs- und Neuanpassungsvorgängen
Bestimmte Betriebs-, Bereitstellungs- und Neuanpassungsvorgänge für Desktops auf virtuellen Maschinen können ausschließlich durch Administratoraktionen initiiert werden, sind üblicherweise vorhersehbar und steuerbar und können auf festgelegte Wartungsfenster beschränkt werden. Andere Betriebs- und Neuanpassungsvorgänge für Desktops auf virtuellen Maschinen werden durch Benutzerverhalten ausgelöst. Dazu zählen u. a. die Verwendung der Einstellungen „Bei Abmeldung aktualisieren“ oder „Bei Abmeldung anhalten“ sowie Skriptaktionen wie die Verwendung von Distributed Power Management (DPM) bei einer längeren Zeit der Benutzerinaktivität, um nicht genutzte ESXi-Hosts auszuschalten.
Wenn für Ihren VMware Horizon-Entwurf keine von Benutzern ausgelösten Betriebs- und Neuanpassungsvorgänge erforderlich sind, ist eine einzelne vCenter Server-Instanz wahrscheinlich ausreichend, um Ihre Anforderungen zu erfüllen. Wenn von Benutzern ausgelöste Betriebs- und Neuanpassungsvorgänge nur selten vorkommen, entstehen keine langen Warteschlangen. Folglich kommt es für den Verbindungs-Broker auch nicht zu Zeitüberschreitungen, wenn er darauf wartet, dass vCenter Server die angeforderten Vorgänge innerhalb der definierten Grenzwerte für parallele Vorgänge ausführt.
Viele Kunden entscheiden sich für die Bereitstellung von dynamischen Pools und die Verwendung der Einstellung „Bei Abmeldung aktualisieren“ für eine einheitliche Bereitstellung von Desktops ohne veraltete Daten aus früheren Sitzungen. Zu veralteten Daten zählen z. B. nicht zurückgeforderte Seiten in pagefile.sys oder in Windows-temp-Dateien. Mit dynamischen Pools lassen sich außerdem die Auswirkungen von schädlicher Software reduzieren, indem Desktops häufig auf einen bekannten „sauberen“ Zustand zurückgesetzt werden.
Einige Kunden senken den Energieverbrauch, indem VMware Horizon so konfiguriert wird, dass nicht verwendete Desktops ausgeschaltet werden. Dadurch kann vSphere DRS (Distributed Resources Scheduler) die ausgeführten virtuellen Maschinen auf einer möglichst geringen Anzahl von ESXi-Hosts konsolidieren. Die nicht genutzten Hosts werden anschließend von VMware Distributed Power Management ausgeschaltet. In solchen Szenarien kann der größeren Anzahl von Betriebs- und Neuanpassungsvorgängen besser Rechnung getragen werden, indem mehrere vCenter Server-Instanzen eingesetzt werden. Denn mit einer solchen Konfiguration werden Zeitüberschreitungen bei der Ausführung der Vorgänge verhindert.
Einfachheit der Infrastruktur
Der Einsatz einer einzelnen vCenter Server-Instanz in einem großen VMware Horizon-Entwurf bietet offenkundige Vorteile, wie z. B. eine zentrale Verwaltung von Golden Image-VMs, eine einzige vCenter Server-Ansicht, die auf die Konsolenansicht abgestimmt ist, sowie eine geringere Anzahl von Back-End-Produktionsdatenbanken und Datenbankservern. Auch die Disaster Recovery-Planung ist bei einer vCenter Server-Instanz einfacher als bei mehreren Instanzen. Sie sollten die Vorteile beim Einsatz mehrerer vCenter Server-Instanzen (z. B. die Dauer von Wartungsfenstern und die Häufigkeit von Betriebs- und Neuanpassungsvorgängen) sorgfältig gegen die Nachteile (z. B. der zusätzliche Aufwand für die Verwaltung der Images von Golden Image-VM und die höhere Anzahl von erforderlichen Infrastrukturkomponenten) abwägen.
Möglicherweise ist ein kombinierter Ansatz für Ihren Entwurf die beste Lösung. Sie können sich für sehr große und relativ statische Pools entscheiden, die von einer vCenter Server-Instanz verwaltet werden, und gleichzeitig mehrere kleinere, dynamischere Desktop-Pools bereitstellen, die von mehreren vCenter Server-Instanzen verwaltet werden. Die beste Strategie für die Aktualisierung vorhandener großer Strukturen besteht darin, zunächst die VMware-Softwarekomponenten Ihrer vorhandenen Struktur zu aktualisieren. Bevor Sie Ihren Pod-Entwurf ändern, sollten Sie die Auswirkungen der Verbesserungen bei den Betriebs-, Bereitstellungs- und Neuanpassungsvorgängen in der neuesten Version auswerten und anschließend mit einer Erweiterung Ihrer Desktop-Pools experimentieren, um das ideale Verhältnis einer höheren Anzahl von großen Desktop-Pools zu ermitteln, die über eine geringere Anzahl von vCenter Server-Instanzen verwaltet werden.
