Verwenden Sie die Cloud-Pod-Architektur-Funktion, um mehrere Pods zu verbinden, sodass eine einzelne große Umgebung für das Brokering und die Verwaltung von Desktops und Anwendungen entsteht.
Ein Pod besteht aus mehreren Verbindungsserver-Instanzen, einem gemeinsamen Speicher, einem Datenbankserver sowie den vSphere- und Netzwerkinfrastrukturen, die erforderlich sind, um Desktop- und Anwendungspools zu hosten. In einer herkömmlichen Horizon 8-Implementierung werden die einzelnen Pods unabhängig voneinander verwaltet. Mit der Cloud-Pod-Architektur-Funktion können Sie mehrere Pods in einer einzelnen Horizon 8-Implementierung verbinden, die als Pod-Verbund bezeichnet wird.
Ein Pod-Verbund kann sich über mehrere Sites und Rechenzentren erstrecken und gleichzeitig die Verwaltung von großen Horizon 8-Bereitstellungen vereinfachen.
Das folgende Diagramm ist ein Beispiel einer einfachen Cloud-Pod-Architektur-Topologie.
In der Beispieltopologie werden zwei zuvor eigenständige Pods in verschiedenen Rechenzentren zu einem Pod-Verbund kombiniert. Ein Endbenutzer kann in dieser Umgebung eine Verbindung mit einem Pod in New York herstellen und einen Desktop oder eine Anwendung in einem der Pods erhalten.
Wenn Sie Cloud-Pod-Architektur mit Unified Access Gateway-Appliances verwenden, muss jede Appliance mit einem einzelnen Pod verknüpft sein.
Schlüsselkomponenten der Cloud-Pod-Architektur
Die Cloud-Pod-Architektur besteht aus einer kleinen Anzahl von Komponenten, die zusammenarbeiten, damit sich viele unabhängige Pods wie ein System verhalten.
| Komponente | Worum es bei ihr geht | Wofür sie zuständig ist |
|---|---|---|
| Pod | Mehrere Verbindungsserver-Instanzen, ein gemeinsamer Speicher, ein Datenbankserver sowie die vSphere-/Netzwerkinfrastruktur, die erforderlich ist, um Desktop- und Anwendungspools zu hosten. | Hosting und Brokering von Desktops und Anwendungen für die damit verbundenen Benutzer. |
| Pod-Verbund | Zwei oder mehr Pods, die mithilfe der Cloud-Pod-Architektur-Funktion miteinander verbunden werden. | Die verbundenen Pods werden als eine einzelne logische Brokering-Umgebung dargestellt. |
| Globale Datenschicht | Eine zweite, replizierte LDAP-Instanz, die auf jeder Verbindungsserver-Instanz im Pod-Verbund ausgeführt wird. | Speichern und Replizieren von Topologien, globalen Berechtigungen, Start-Sites, Verbundzugriffsgruppen und Richtlinien für den gesamten Pod-Verbund. |
| VIPA (View InterPod API) | Ein HTTPS-basierter Kommunikationskanal zwischen Pods. | Pod-zu-Pod-Kommunikation in Echtzeit: Starten von Sitzungen auf einem Remote-Pod, Suchen nach vorhandenen Sitzungen und Austauschen des Integritätsstatus. |
| Site | Eine Sammlung von gut verbundenen Pods, in der Regel in einem Rechenzentrum, die von der Cloud-Pod-Architektur als gleichwertig behandelt werden. | Modellierung der Netzwerklokalität, damit das Brokering Ressourcen in der Nähe gegenüber Ressourcen bevorzugen kann, die über eine langsamere WAN-Verbindung erreicht werden. |
| Globale Berechtigung | Ein benanntes Objekt, das Benutzer oder Gruppen an beliebiger Stelle im Verbund mit Desktop- oder Anwendungspools verbindet, sowie die Richtlinien, die steuern, wie Ressourcen gefunden und zugeteilt werden. | Was ein Benutzer tatsächlich in Horizon Client sieht und auswählt. |
| Start-Site | Eine optionale Beziehung zwischen einem Benutzer oder einer Gruppe (oder einem Benutzer/einer Gruppe und einer bestimmten globalen Berechtigung) und einer Site. | Verankerung, wo die Suche nach einer Ressource beginnt, unabhängig davon, über welchen Pod der Benutzer eine Verbindung herstellt. |
Unterschiede der Cloud-Pod-Architektur von einer herkömmlichen Horizon 8-Bereitstellung
In einer herkömmlichen, nicht im Verbund befindlichen Horizon 8-Bereitstellung ist jeder Pod eine in sich geschlossene Insel: Er verfügt über eigene Verbindungsserver-Instanzen, eigene lokale Berechtigungen und hat keine Kenntnis von anderen Pods. Einem Benutzer, der eine Verbindung zu Pod A herstellt, kann nur ein Desktop oder eine Anwendung vermittelt werden, der bzw. die physisch in Pod A vorhanden ist.
Mit der Cloud-Pod-Architektur ändert sich dies auf drei Arten:
- Berechtigungen werden zu globalen statt zu lokalen Berechtigungen. Sie berechtigen einen Benutzer oder eine Gruppe zu einer globalen Berechtigung, die durch Pools in einem beliebigen Pod des Verbunds gestützt werden kann, anstatt einen Pool auf einer bestimmten Verbindungsserver-Instanz zu verwenden.
- Das Brokering erfolgt nun auf Verbundebene statt auf Pod-Ebene. Die Verbindungsserver-Instanz, mit der sich ein Benutzer verbindet (der Verbindungs-Pod, auch als Brokering-Pod bezeichnet), kann mithilfe von VIPA andere Pods fragen, ob sie über eine übereinstimmende Ressource verfügen, und zwar in einer Reihenfolge, die von der Geltungsbereichsrichtlinie der globalen Berechtigung und der Start-Site des Benutzers gesteuert wird.
- Konfiguration und Status werden nicht isoliert, sondern gemeinsam genutzt. Topologie, Berechtigungen und Start-Sites befinden sich in der globalen Datenschicht und sind von jedem Pod aus sichtbar. Sitzungs- und Zustandsinformationen sind ebenfalls im gesamten Pod-Verbund in Horizon Console sichtbar. (Ausnahme: Horizon 8-Ereignisdatenbanken werden nicht von mehreren Pods gemeinsam genutzt.)
Was sich nicht ändert: Jeder Desktop- oder Anwendungspool ist physisch in genau einem Pod vorhanden, und jeder Pod bleibt vollständig in der Lage, eigenständig zu arbeiten. Die Cloud-Pod-Architektur ist eine Brokering- und Verwaltungsschicht über Ihren vorhandenen Pods, kein Ersatz für diese.
War diese Seite hilfreich?