Wenn Sie ein Peer-VNet verwenden, empfiehlt es sich, die erforderlichen Subnetze vor der Bereitstellung des Pods zu erstellen, um sicherzustellen, dass Sie die Adressbereiche berücksichtigt haben, die Ihre Subnetze im VNet benötigen, bevor Sie den Bereitstellungsassistenten ausführen. Selbst wenn Ihr VNet nicht mit Peers verbunden ist, können Sie die erforderlichen Subnetze im Voraus in Ihrem VNet erstellen, anstatt sie durch den First-Gen-Pod-Bereitstellungsprozess erstellen zu lassen.
Wichtig: Diese Informationen gelten nur, wenn Sie auf eine First-Gen-Mandantenumgebung in der First-Gen-Steuerungsebene zugreifen können. Wie im KB-Artikel 92424 beschrieben, hat die First-Gen-Steuerungsebene das Ende der Verfügbarkeit (End of Availability, EOA) erreicht. Weitere Informationen finden Sie in diesem Artikel.
Wichtig: Ab der Pod-Manifestversion vom September 2019 muss das Pod-Management-Subnetz auch die Netzwerkkommunikation mit der Microsoft Azure-Datenbank des Pods für die PostgreSQL-Dienstressource unterstützen. Dies gilt sowohl für in dieser Manifestversion oder einer höheren Version neu bereitgestellte Pods als auch für Pods, die auf diese Version oder neuere Versionen aktualisiert wurden. Bevor Sie einen neuen Pod bereitstellen oder einen vorhandenen Pod aktualisieren, muss im von Ihnen erstellten Pod-Management-Subnetz der Microsoft.Sql-Dienst als Dienstendpunkt aufgeführt sein. Während des Bereitstellungs- oder Aktualisierungsvorgangs wird überprüft, ob das Subnetz über den Endpunkt verfügt. Wenn der Endpunkt nicht im Subnetz aktiviert ist, wird der Vorgang nicht fortgesetzt. Weitere Informationen finden Sie unter First-Gen-Mandanten – Bei Verwendung vorhandener Subnetze für einen Horizon Cloud-Pod in Microsoft Azure.
Wenn Sie die Subnetze im Voraus erstellen, müssen Sie sicherstellen, dass ihre Adressbereiche in CIDR-Notation (Classless Interdomain Routing) den Mindestanforderungen des Pod-Bereitstellungsassistenten entsprechen:
-
Für das Management-Subnetz ist ein CIDR von /27 oder höher erforderlich. Dieses Subnetz ist für IP-Adressen, die von den VMs verwendet werden, die an Verwaltungsaktivitäten des Pods selbst beteiligt sind.
-
Für das primäre VM-Subnetz – auch als Desktop- oder Mandantensubnetz bezeichnet – ist ein CIDR von /27 oder mehr erforderlich. Für Produktionsumgebungen wird ein CIDR von /24 bis /21 empfohlen (256 Adressen bis 2048 Adressen). Dieses Subnetz dient für IP-Adressen, die für die RDSH-Server-VMs und VDI-Desktop-VMs in diesem Subnetz verwendet werden. Die Pod-Manager-VM verwendet eine IP-Adresse aus diesem Subnetz. Wenn der Pod über eine interne Unified Access Gateway-Konfiguration verfügt, verwenden diese Unified Access Gateway-VMs auch IP-Adressen aus diesem Subnetz. Wenn der Pod über eine externe Gateway-Konfiguration verfügt, die mithilfe des VNet des Pods bereitgestellt wird, verwenden die Unified Access Gateway-VMs dieses externen Gateways auch IP-Adressen aus diesem Subnetz.
Wichtig: Die VMs für Ihre VDI-Desktops, die RDS-fähigen Images und alle RDSH-VMs in den Farmen des Pods nutzen diese IP-Adressen. Da dieses primäre VM-Subnetz nach der Bereitstellung des Pods nicht erweitert werden kann, stellen Sie sicher, dass der Bereich groß genug ist, um die Anzahl der Desktops aufzunehmen, die dieser Pod voraussichtlich bereitstellen soll. Wenn Sie beispielsweise planen, dass dieser Pod zukünftig über 1000 Desktops bereitstellen soll, stellen Sie sicher, dass dieser Bereich mehr als diese Anzahl an IP-Adressen bereitstellt. Ab der Version vom Juli 2020 können Sie mit einer neuen Funktion den Pod später bearbeiten und zusätzliche VM-Subnetze für die Verwendung durch Ihre Farm-VMs und VDI-Desktop-VMs hinzufügen. Diese neue Funktion bietet Ihnen die Flexibilität, im Laufe der Zeit VM-Subnetze hinzuzufügen, um dem Wachstum Ihrer Farmen und VDI-Desktop-Zuweisungen gerecht zu werden. Da das System standardmäßig dieses primäre VM-Subnetz verwendet, sofern Sie diese zusätzlichen Subnetze nicht ausdrücklich in den Definitionen Ihrer Farmen und VDI-Desktop-Zuweisungen angeben, empfiehlt es sich, sicherzustellen, dass der Bereich für dieses primäre VM-Subnetz groß genug ist, um die erwartete Anzahl an Farm-VMs und Desktops aufzunehmen.
-
Wenn Sie eine externe Unified Access Gateway-Konfiguration im VNet des Pods bereitstellen möchten, benötigen Sie ein DMZ-Subnetz mit einem CIDR von mindestens /28. Dieses Subnetz ist für IP-Adressen, die von den Netzwerkkarten der Unified Access Gateway-VMs verwendet werden, um mit dem Lastausgleichsdienst dieser externen Gateway-Konfiguration zu kommunizieren. Wenn Sie die Verwaltungs- und DMZ-Subnetzbereiche gemeinsam nutzen möchten, könnten Sie den Bereich des DMZ-Subnetzes ähnlich wie das Management-Subnetz mit einer angegebenen IP angeben. Wenn das Management-Subnetz beispielsweise 192.168.8.0/27 ist, wäre ein entsprechendes DMZ-Subnetz 192.168.8.32/27.
-
Wenn die Konfiguration des externen Unified Access Gateway in einem eigenen VNet bereitgestellt werden soll, das vom VNet des Pods getrennt ist, benötigt dieses VNet drei Subnetze:
- Ein Management-Subnetz mit einem CIDR von mindestens /27 ist erforderlich. Dieses Subnetz ist für IP-Adressen, die von den VMs verwendet werden, die an den Verwaltungsaktivitäten des externen Gateways insgesamt beteiligt sind, wie z. B. der Gateway Connector-VM.
- Ein Back-End-Subnetz mit einem CIDR von mindestens /27 ist erforderlich. Dieses Subnetz ist für IP-Adressen, die von den Netzwerkkarten der Unified Access Gateway-VMs verwendet werden, um mit den vom Pod bereitgestellten Farm- und Desktop-VMs über das mit Peers verbundene VNet mit dem VNet des Pods zu kommunizieren.
- Ein Front-End-Subnetz (DMZ-Subnetz) mit einem CIDR von mindestens /28. Dieses Subnetz ist für IP-Adressen, die von den Netzwerkkarten der Unified Access Gateway-VMs für die Kommunikation mit dem Lastausgleichsdienst des externen Gateways verwendet werden. Wenn Sie die Verwaltungs- und Front-End-Subnetzbereiche zusammen in diesem VNet unterbringen möchten, könnten Sie den Bereich des DMZ-Subnetzes ähnlich wie das Management-Subnetz mit einer angegebenen IP angeben. Wenn das Management-Subnetz beispielsweise 192.168.8.0/27 ist, wäre ein entsprechendes Front-End-Subnetz 192.168.8.32/27.
Wichtig: Stellen Sie für jedes CIDR sicher, dass jede Kombination aus Präfix und Bitmaske zu einem IP-Adressbereich mit dem Präfix als IP-Startadresse führt. Microsoft Azure erfordert, dass das CIDR-Präfix den Anfang des Bereichs darstellt. Beispielsweise würde das korrekte CIDR 192.168.182.48/28 zu einem IP-Bereich von 192.168.182.48 bis 192.168.182.63 führen, wobei das Präfix mit der IP-Startadresse (192.168.182.48) identisch ist. Das falsche CIDR 192.168.182.60/28 würde jedoch den IP-Bereich 192.168.182.48 bis 192.168.182.63 ergeben, in dem die IP-Startadresse nicht mit dem Präfix 192.168.182.60 identisch ist. Stellen Sie sicher, dass Ihre CIDRs IP-Adressbereiche ergeben, bei denen die IP-Startadresse mit dem CIDR-Präfix übereinstimmt.
Voraussetzungen
Stellen Sie sicher, dass Ihre Microsoft-Region über das VNet verfügt, das Sie für Ihren Pod verwenden möchten. Weitere Informationen zum Einrichten des VNet finden Sie im Horizon Cloud-Bereitstellungshandbuch.
Stellen Sie sicher, dass sich die Adressbereiche, die Sie für die Subnetze verwenden möchten, nicht überlappen. Der Pod-Bereitstellungsassistent zeigt einen Fehler an, wenn sich die Subnetzbereiche überlappen.
Vorgehensweise
-
Navigieren Sie im Microsoft Azure-Portal zu dem VNet, für das Sie die beschriebenen Subnetze erstellen müssen.
-
Klicken Sie auf Subnetze.
-
Klicken Sie auf + Subnetz.
Der Bildschirm Subnetz hinzufügen (Add subnet ) wird angezeigt.
-
Geben Sie die Informationen für die erforderlichen Felder ein.
Option Beschreibung Name Geben Sie einen Namen für das Subnetz an. Adressbereich (CIDR-Block) Geben Sie ein CIDR für das Subnetz ein. -
Wenn dieses Subnetz das Management-Subnetz sein soll, wählen Sie im Abschnitt Dienstendpunkte den Dienst Microsoft.Sql aus.
-
Klicken Sie auf OK.
Das Subnetz wird dem VNet hinzugefügt.
-
Wiederholen Sie die Schritte 3 bis 5, um die verbleibenden erforderlichen Subnetze hinzuzufügen.
-
Wenn Sie das externe Gateway in einem eigenen VNet bereitstellen möchten, wiederholen Sie die Schritte für die Subnetze dieses VNets.
Ergebnisse
VORSICHT:
Die Subnetze, die Sie in Ihrem VNet für die Pod-Bereitstellung manuell erstellen, müssen leer bleiben. Verwenden Sie keine vorhandenen Subnetze wieder, die bereits Elemente enthalten, die IP-Adressen in diesen Subnetzen verwenden. Wenn eine IP-Adresse bereits in den Subnetzen verwendet wird, treten mit hoher Wahrscheinlichkeit Probleme auf, wie z. B. das Fehlschlagen der Pod-Bereitstellung und andere IP-Konflikte im Nachhinein. Legen Sie keine Ressourcen in diesen Subnetzen ab und verwenden Sie keine der IP-Adressen an anderer Stelle. Dieser Warnhinweis gilt auch für Pods, die über Horizon Cloud bereitgestellt wurden – verwenden Sie keine Subnetze erneut, in denen Sie bereits einen Pod bereitgestellt haben.
Nächster Schritt
Stellen Sie für alle von Ihnen erstellten Management-Subnetze sicher, dass der Microsoft.Sql-Dienst als Dienstendpunkt aktiviert ist. Weitere Informationen finden Sie unter First-Gen-Mandanten – Bei Verwendung vorhandener Subnetze für einen Horizon Cloud-Pod in Microsoft Azure. Dieser Dienst muss im Management-Subnetz des Pods aktiviert sein, und wenn Sie das externe Gateway in einem eigenen VNet bereitstellen, muss der Dienst auch im Management-Subnetz dieses Gateways aktiviert sein.
War diese Seite hilfreich?