Horizon auf Azure VMware Solution bereitstellen
- 09/29/2020
- 11 Minuten zu lesen
-
s -
t
Hinweis
Dieses Dokument konzentriert sich auf das Produkt VMware Horizon, das früher als Horizon 7 bekannt war. Horizon ist eine andere Lösung als Horizon Cloud auf Azure, obwohl es einige gemeinsame Komponenten gibt. Zu den wichtigsten Vorteilen der VMware-Lösung auf Azure gehören sowohl eine einfachere Größenbestimmung als auch die Integration des VMware Cloud Foundation-Managements in das Azure-Portal.
VMware Horizon®, eine Plattform für virtuelle Desktops und Anwendungen, wird im Rechenzentrum ausgeführt und bietet ein einfaches und zentralisiertes Management. Sie stellt virtuelle Desktops und Anwendungen auf jedem Gerät und überall zur Verfügung. Mit Horizon können Sie Verbindungen zu virtuellen Windows- und Linux-Desktops, von Remote Desktop Server (RDS) gehosteten Anwendungen, Desktops und physischen Maschinen erstellen und vermitteln.
Hier konzentrieren wir uns speziell auf die Bereitstellung von Horizon auf Azure VMware Solution. Allgemeine Informationen zu VMware Horizon finden Sie in der Horizon-Produktionsdokumentation:
-
Was ist VMware Horizon?
-
Erfahren Sie mehr über VMware Horizon
-
Horizon Referenzarchitektur
Mit der Einführung von Horizon auf der Azure VMware Solution gibt es nun zwei Virtual Desktop Infrastructure (VDI) Lösungen auf der Azure Plattform. Das folgende Diagramm fasst die wichtigsten Unterschiede auf hohem Niveau zusammen.
Horizon 2006 und spätere Versionen der Horizon 8 Release Line unterstützen sowohl die Bereitstellung vor Ort als auch die Bereitstellung von Azure VMware Solution. Es gibt einige Horizon-Funktionen, die vor Ort unterstützt werden, aber nicht in Azure VMware Solution. Weitere Produkte aus dem Horizon-Ökosystem werden ebenfalls unterstützt. Weitere Informationen finden Sie unter Funktionsparität und Interoperabilität.
Bereitstellen von Horizon in einer Hybrid-Cloud
Sie können Horizon in einer Hybrid-Cloud-Umgebung bereitstellen, wenn Sie die Horizon Cloud Pod Architecture (CPA) verwenden, um lokale und Azure-Rechenzentren miteinander zu verbinden. CPA skaliert Ihre Bereitstellung, baut eine hybride Cloud auf und bietet Redundanz für Business Continuity und Disaster Recovery. Weitere Informationen finden Sie unter Erweitern bestehender Horizon 7-Umgebungen.
Wichtig
CPA ist keine gestreckte Bereitstellung; jeder Horizon-Pod ist eigenständig, und alle Verbindungsserver, die zu den einzelnen Pods gehören, müssen sich an einem einzigen Standort befinden und aus der Netzwerkperspektive in der gleichen Broadcast-Domäne ausgeführt werden.
Wie vor Ort oder in einem privaten Rechenzentrum kann Horizon in einer Azure VMware Solution Private Cloud bereitgestellt werden. In den folgenden Abschnitten werden die wichtigsten Unterschiede bei der Bereitstellung von Horizon vor Ort und in Azure VMware Solution erörtert.
Die Azure Private Cloud ist konzeptionell dasselbe wie das VMware SDDC, ein Begriff, der in der Regel in der Horizon-Dokumentation verwendet wird. Im Rest dieses Dokuments werden die Begriffe Azure Private Cloud und VMware SDDC austauschbar verwendet.
Der Horizon Cloud Connector ist für Horizon on Azure VMware Solution erforderlich, um Abonnementlizenzen zu verwalten. Cloud Connector kann im Azure Virtual Network neben Horizon Connection Servern bereitgestellt werden.
Wichtig
Die Unterstützung der Horizon Control Plane für Horizon on Azure VMware Solution ist noch nicht verfügbar. Stellen Sie sicher, dass Sie die VHD-Version von Horizon Cloud Connector herunterladen.
vCenter-Cloud-Admin-Rolle
Da Azure VMware Solution ein SDDC-Service ist und Azure den Lebenszyklus des SDDC auf Azure VMware Solution verwaltet, ist das vCenter-Berechtigungsmodell auf Azure VMware Solution von vornherein begrenzt.
Kunden müssen die Cloud-Admin-Rolle verwenden, die einen begrenzten Satz an vCenter-Berechtigungen hat. Das Horizon-Produkt wurde so geändert, dass es mit der Cloud-Admin-Rolle auf Azure VMware Solution funktioniert, insbesondere:
-
Die sofortige Klonbereitstellung wurde so geändert, dass sie auf Azure VMware Solution ausgeführt werden kann.
-
Eine spezifische vSAN-Richtlinie (VMware_Horizon) wurde auf Azure VMware Solution erstellt, um mit Horizon zu arbeiten, die in den für Horizon bereitgestellten SDDCs verfügbar sein und verwendet werden muss.
-
vSphere Content-Based Read Cache (CBRC), auch bekannt als View Storage Accelerator, ist deaktiviert, wenn es auf Azure VMware Solution ausgeführt wird.
Wichtig
CBRC darf nicht wieder aktiviert werden.
Hinweis
Die Azure VMware Solution konfiguriert automatisch bestimmte Horizon-Einstellungen, sofern Sie Horizon 2006 (auch bekannt als Horizon 8) und höher im Horizon 8-Zweig bereitstellen und die Azure-Option im Horizon Connection Server-Installationsprogramm auswählen.
Horizon auf Azure VMware Solution-Bereitstellungsarchitektur
Ein typisches Horizon-Architekturdesign verwendet eine Pod- und Blockstrategie. Ein Block ist ein einzelnes vCenter, während mehrere Blöcke zusammen einen Pod bilden. Ein Horizon-Pod ist eine Organisationseinheit, die durch die Skalierbarkeitsgrenzen von Horizon bestimmt wird. Jeder Horizon-Pod verfügt über ein separates Management-Portal, so dass eine Standard-Design-Praxis darin besteht, die Anzahl der Pods zu minimieren.
Jede Cloud hat ihr eigenes Netzwerk-Konnektivitätsschema. In Kombination mit VMware SDDC-Netzwerken / NSX Edge stellt die Netzwerkkonnektivität der Azure VMware Solution einzigartige Anforderungen für die Bereitstellung von Horizon, die sich von denen vor Ort unterscheiden.
Jede Azure Private Cloud und jedes SDDC kann 4.000 Desktop- oder Anwendungssitzungen verarbeiten, vorausgesetzt:
-
Der Workload-Verkehr entspricht dem LoginVSI Task Worker-Profil.
-
Nur Protokollverkehr wird berücksichtigt, keine Benutzerdaten.
-
NSX Edge ist groß konfiguriert.
Hinweis
Ihr Workload-Profil und Ihre Anforderungen können unterschiedlich sein, daher können die Ergebnisse je nach Anwendungsfall abweichen. Benutzerdatenvolumina können die Skalierungsgrenzen im Zusammenhang mit Ihrer Arbeitslast senken. Dimensionieren und planen Sie Ihre Bereitstellung entsprechend. Weitere Informationen finden Sie in den Größenrichtlinien im Abschnitt Größe der Azure VMware Solution Hosts für Horizon-Bereitstellungen.
Angesichts der maximalen Azure Private Cloud- und SDDC-Grenze empfehlen wir eine Bereitstellungsarchitektur, bei der die Horizon Connection Server und VMware Unified Access Gateways (UAGs) innerhalb des Azure Virtual Network ausgeführt werden. Dadurch wird jede Azure Private Cloud und jedes SDDC effektiv zu einem Block. Dies wiederum maximiert die Skalierbarkeit von Horizon auf Azure VMware Solution.
Die Verbindung vom Azure Virtual Network zu den Azure Private Clouds / SDDCs sollte mit ExpressRoute FastPath konfiguriert werden. Das folgende Diagramm zeigt eine grundlegende Horizon-Pod-Bereitstellung.
Netzwerkkonnektivität zur Skalierung von Horizon auf Azure VMware Solution
In diesem Abschnitt wird die Netzwerkarchitektur auf einer hohen Ebene mit einigen allgemeinen Bereitstellungsbeispielen dargestellt, die Ihnen bei der Skalierung von Horizon auf Azure VMware Solution helfen. Der Schwerpunkt liegt speziell auf kritischen Netzwerkelementen.
Ein einzelner Horizon-Pod auf Azure VMware Solution
Ein einzelner Horizon-Pod ist das einfachste Bereitstellungsszenario, da Sie nur einen Horizon-Pod in der Region US East bereitstellen. Da jede private Cloud und jedes SDDC schätzungsweise 4.000 Desktop-Sitzungen verarbeiten kann, stellen Sie die maximale Horizon-Pod-Größe bereit. Sie können die Bereitstellung von bis zu drei Private Clouds/SDDCs planen.
Mit den virtuellen Maschinen (VMs) der Horizon-Infrastruktur, die im Azure Virtual Network bereitgestellt werden, können Sie die 12.000 Sitzungen pro Horizon-Pod erreichen. Die Verbindung zwischen jeder privaten Cloud und jedem SDDC zum Azure Virtual Network ist ExpressRoute Fast Path. Es ist kein Ost-West-Verkehr zwischen privaten Clouds erforderlich.
Zu den wichtigsten Annahmen für dieses grundlegende Bereitstellungsbeispiel gehört, dass:
-
Sie keinen lokalen Horizon-Pod haben, den Sie über die Cloud-Pod-Architektur (CPA) mit diesem neuen Pod verbinden möchten.
-
Endbenutzer stellen über das Internet eine Verbindung zu ihren virtuellen Desktops her (vs.
Sie verbinden Ihren AD-Domänencontroller in Azure Virtual Network mit Ihrem lokalen AD über VPN oder ExpressRoute-Schaltung.
Eine Variation des Basisbeispiels könnte darin bestehen, Konnektivität für lokale Ressourcen zu unterstützen. Beispielsweise greifen Benutzer auf Desktops zu und erzeugen virtuellen Desktop-Anwendungsdatenverkehr oder stellen eine Verbindung zu einem lokalen Horizon-Pod über CPA her.
Das Diagramm zeigt, wie die Konnektivität für lokale Ressourcen unterstützt wird. Um Ihr Unternehmensnetzwerk mit dem Azure Virtual Network zu verbinden, benötigen Sie eine ExpressRoute-Verbindung. Außerdem müssen Sie Ihr Unternehmensnetzwerk mit jeder privaten Cloud und jedem SDDC über ExpressRoute Global Reach verbinden. Es ermöglicht die Konnektivität vom SDDC zur ExpressRoute-Schaltung und den lokalen Ressourcen.
Mehrere Horizon-Pods auf Azure VMware Solution über mehrere Regionen
Ein weiteres Szenario ist die Skalierung von Horizon über mehrere Pods. In diesem Szenario stellen Sie zwei Horizon-Pods in zwei verschiedenen Regionen bereit und föderieren sie mit CPA. Es ähnelt der Netzwerkkonfiguration im vorherigen Beispiel, jedoch mit einigen zusätzlichen regionsübergreifenden Verbindungen.
Sie verbinden das Azure Virtual Network in jeder Region mit den privaten Clouds/SDDCs in der anderen Region. Dadurch können Horizon-Verbindungsserver, die Teil des CPA-Verbunds sind, eine Verbindung zu allen verwalteten Desktops herstellen. Durch Hinzufügen zusätzlicher privater Clouds/SDDCs zu dieser Konfiguration könnten Sie auf insgesamt 24.000 Sitzungen skalieren.
Die gleichen Prinzipien gelten, wenn Sie zwei Horizon-Pods in der gleichen Region bereitstellen. Stellen Sie sicher, dass Sie den zweiten Horizon-Pod in einem separaten virtuellen Azure-Netzwerk bereitstellen. Genau wie beim Beispiel für einen einzelnen Pod können Sie Ihr Unternehmensnetzwerk und Ihren lokalen Pod mit diesem Beispiel für mehrere Pods/Regionen mithilfe von ExpressRoute und Global Reach verbinden.
Größenbestimmung von Azure VMware Solution-Hosts für Horizon-Bereitstellungen
Die Größenbestimmung von Horizon auf einem Host, der in Azure VMware Solution läuft, ist einfacher als bei Horizon vor Ort. Das liegt daran, dass der Azure VMware Solution-Host standardisiert ist. Die exakte Dimensionierung des Hosts hilft bei der Bestimmung der Anzahl der Hosts, die zur Unterstützung Ihrer VDI-Anforderungen erforderlich sind. Sie ist von zentraler Bedeutung für die Bestimmung der Kosten pro Desktop.
Größentabellen
Die spezifischen vCPU/vRAM-Anforderungen für virtuelle Horizon-Desktops hängen vom spezifischen Workload-Profil des Kunden ab. Wenden Sie sich an Ihr MSFT- und VMware-Vertriebsteam, um Ihre vCPU/vRAM-Anforderungen für Ihre virtuellen Desktops zu ermitteln.
| vCPU pro VM | vRAM pro VM (GB) | Instanz | 100 VMs | 200 VMs | 300 VMs | 400 VMs | 500 VMs | 600 VMs | 700 VMs | 800 VMs | 900 VMs | 1000 VMs | 2000 VMs | 3000 VMs | 4000 VMs | 5000 VMs | 6000 VMs | 6400 VMs |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2 | 3.5 | AVS | 3 | 3 | 4 | 4 | 5 | 6 | 6 | 7 | 8 | 9 | 17 | 25 | 33 | 41 | 49 | 53 |
| 2 | 4 | AVS | 3 | 3 | 4 | 5 | 6 | 6 | 7 | 8 | 9 | 9 | 18 | 26 | 34 | 42 | 51 | 54 |
| 2 | 6 | AVS | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 12 | 13 | 26 | 38 | 51 | 62 | 75 | 79 |
| 2 | 8 | AVS | 3 | 5 | 6 | 8 | 9 | 11 | 12 | 14 | 16 | 18 | 34 | 51 | 67 | 84 | 100 | 106 |
| 2 | 12 | AVS | 4 | 6 | 9 | 11 | 13 | 16 | 19 | 21 | 23 | 26 | 51 | 75 | 100 | 124 | 149 | 158 |
| 2 | 16 | AVS | 5 | 8 | 11 | 14 | 18 | 21 | 24 | 27 | 30 | 34 | 67 | 100 | 133 | 165 | 198 | 211 |
| 4 | 3.5 | AVS | 3 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 22 | 33 | 44 | 55 | 66 | 70 |
| 4 | 4 | AVS | 3 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 22 | 33 | 44 | 55 | 66 | 70 |
| 4 | 6 | AVS | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 12 | 13 | 26 | 38 | 51 | 62 | 75 | 79 |
| 4 | 8 | AVS | 3 | 5 | 6 | 8 | 9 | 11 | 12 | 14 | 16 | 18 | 34 | 51 | 67 | 84 | 100 | 106 |
| 4 | 12 | AVS | 4 | 6 | 9 | 11 | 13 | 16 | 19 | 21 | 23 | 26 | 51 | 75 | 100 | 124 | 149 | 158 |
| 4 | 16 | AVS | 5 | 8 | 11 | 14 | 18 | 21 | 24 | 27 | 30 | 34 | 67 | 100 | 133 | 165 | 198 | 211 |
| 6 | 3.5 | AVS | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 13 | 14 | 27 | 41 | 54 | 68 | 81 | 86 |
| 6 | 4 | AVS | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 13 | 14 | 27 | 41 | 54 | 68 | 81 | 86 |
| 6 | 6 | AVS | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 13 | 14 | 27 | 41 | 54 | 68 | 81 | 86 |
| 6 | 8 | AVS | 3 | 5 | 6 | 8 | 9 | 11 | 12 | 14 | 16 | 18 | 34 | 51 | 67 | 84 | 100 | 106 |
| 6 | 12 | AVS | 4 | 6 | 9 | 11 | 13 | 16 | 19 | 21 | 23 | 26 | 51 | 75 | 100 | 124 | 149 | 158 |
| 6 | 16 | AVS | 5 | 8 | 11 | 14 | 18 | 21 | 24 | 27 | 30 | 34 | 67 | 100 | 133 | 165 | 198 | 211 |
| 8 | 3.5 | AVS | 3 | 4 | 6 | 7 | 9 | 10 | 12 | 14 | 15 | 17 | 33 | 49 | 66 | 82 | 98 | 105 |
| 8 | 4 | AVS | 3 | 4 | 6 | 7 | 9 | 10 | 12 | 14 | 15 | 17 | 33 | 49 | 66 | 82 | 98 | 105 |
| 8 | 6 | AVS | 3 | 4 | 6 | 7 | 9 | 10 | 12 | 14 | 15 | 17 | 33 | 49 | 66 | 82 | 98 | 105 |
| 8 | 8 | AVS | 3 | 5 | 6 | 8 | 9 | 11 | 12 | 14 | 16 | 18 | 34 | 51 | 67 | 84 | 100 | 106 |
| 8 | 12 | AVS | 4 | 6 | 9 | 11 | 13 | 16 | 19 | 21 | 23 | 26 | 51 | 75 | 100 | 124 | 149 | 158 |
| 8 | 16 | AVS | 5 | 8 | 11 | 14 | 18 | 21 | 24 | 27 | 30 | 34 | 67 | 100 | 133 | 165 | 198 | 211 |
Horizon Sizing Inputs
Das sind die Daten, die du für deine geplante Arbeitsbelastung sammeln musst:
-
Anzahl der gleichzeitigen Desktops
-
Bedarf an vCPU pro Desktop
-
Bedarf an vRAM pro Desktop
-
Bedarf an Speicherplatz pro Desktop
Im Allgemeinen sind VDI-Bereitstellungen entweder CPU- oder RAM-beschränkt, was die Hostgröße bestimmt. Nehmen wir das folgende Beispiel für eine LoginVSI Knowledge Worker-Arbeitslast, die mit Leistungstests validiert wurde:
-
2.000 gleichzeitige Desktop-Bereitstellungen
-
2vCPU pro Desktop.
-
4-GB vRAM pro Desktop.
-
50 GB Speicher pro Desktop
Für dieses Beispiel beträgt die Gesamtzahl der Hosts 18, was eine VM-pro-Host-Dichte von 111 ergibt.
Wichtig
Die Workloads der Kunden werden von diesem Beispiel eines LoginVSI Knowledge Workers abweichen. Arbeiten Sie bei der Planung Ihrer Bereitstellung mit Ihren VMware EUC SEs zusammen, um Ihre spezifischen Größen- und Leistungsanforderungen zu ermitteln. Stellen Sie sicher, dass Sie Ihre eigenen Leistungstests mit der tatsächlichen, geplanten Arbeitslast durchführen, bevor Sie die Hostgröße endgültig festlegen und entsprechend anpassen.
Lizenzierung von Horizon auf Azure VMware Solution
Die Gesamtkosten für den Betrieb von Horizon auf Azure VMware Solution setzen sich aus vier Komponenten zusammen.
Kosten für die Kapazität der Azure VMware Solution
Informationen zu den Preisen finden Sie auf der Seite mit den Preisen für die Azure VMware Solution
Kosten für die Horizon-Lizenzierung
Es gibt zwei verfügbare Lizenzen für die Verwendung mit der Azure VMware Solution, die entweder Concurrent User (CCU) oder Named User (NU) sein können:
-
Horizon-Abonnementlizenz
-
Horizon-Universal-Abonnementlizenz
Wenn Sie Horizon nur in absehbarer Zukunft auf der Azure VMware Solution einsetzen, sollten Sie die Horizon-Abonnementlizenz verwenden, da diese kostengünstiger ist.
Wenn Sie Horizon auf Azure VMware Solution und vor Ort bereitstellen, z. B. in einem Disaster Recovery-Anwendungsfall, wählen Sie die Horizon Universal Subscription License. Sie umfasst eine vSphere-Lizenz für die Bereitstellung vor Ort und ist daher teurer.
Ermitteln Sie gemeinsam mit Ihrem VMware EUC-Vertriebsteam die Kosten für die Horizon-Lizenzierung auf der Grundlage Ihrer Anforderungen.
Azure-Instanztypen
Um die Größen der virtuellen Azure-Maschinen zu verstehen, die für die Horizon-Infrastruktur benötigt werden, lesen Sie bitte die Richtlinien von VMware, die Sie hier finden.