Wenn Sie ein Peer-VNet verwenden, empfiehlt es sich, vor der Bereitstellung des Pods die erforderlichen Subnetze zu erstellen, damit die von den Subnetzen im VNet benötigten Adressbereiche vor der Ausführung des Bereitstellungsassistenten berücksichtigt werden. Selbst wenn das VNet nicht mit Peers verbunden ist, können Sie die erforderlichen Subnetze im Voraus im VNet und nicht erst während der Bereitstellung des First-Gen-Pods erstellen.

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 der Microsoft.Sql-Dienst im von Ihnen erstellte Pod-Management-Subnetz als Dienst-Endpoint 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 – 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) die Mindestanforderungen des Pod-Bereitstellungsassistenten erfüllen:

  • Für das Management-Subnetz ist ein CIDR von /27 oder höher erforderlich. Dieses Subnetz dient für IP-Adressen, die von den virtuellen Maschinen genutzt werden, die an Verwaltungsaktivitäten des Pods selbst beteiligt sind.
  • Für das primäre VM-Subnetz – das auch als Desktop- oder Mandanten-Subnetz bezeichnet wird – 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 genutzt werden. Die Pod-Manager-VM verwendet eine IP-Adresse aus diesem Subnetz. Wenn der Pod eine interne Unified Access Gateway-Konfiguration besitzt, verwenden diese Unified Access Gateway-VMs ebenfalls IP-Adressen aus diesem Subnetz. Wenn der Pod über eine Konfiguration eines externen Gateways verfügt, das mithilfe des VNet des Pods bereitgestellt wird, verwenden die Unified Access Gateway-VMs des externen Gateways ebenfalls 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 Pod-Bereitstellung nicht erweitert werden kann, stellen Sie sicher, dass der Bereich für die Anzahl der Desktops, die dieser Pod voraussichtlich bereitstellen soll, groß genug ist. Wenn Sie beispielsweise planen, dass der Pod zukünftig über 1000 Desktops bereitstellen soll, legen Sie einen Bereich fest, der mehr als diese Anzahl an IP-Adressen bereitstellt. Ab der Version von Juli 2020 können Sie über eine neue Funktion den Pod später bearbeiten und zusätzliche VM-Subnetze hinzufügen, die von Ihren Farm-VMs und VDI-Desktop-VMs verwendet werden. Diese neue Funktion bietet Ihnen die Flexibilität, im Laufe der Zeit VM-Subnetze hinzuzufügen, um das Anwachsen Ihrer Farmen und VDI-Desktop-Zuweisungen zu berücksichtigen. Da das System standardmäßig dieses primäre VM-Subnetz verwendet, sofern Sie nicht in den Definitionen Ihrer Farmen und VDI-Desktop-Zuweisungen explizit zusätzliche Subnetze festlegen, ist es eine bewährte Vorgehensweise, den Bereich für das primäre VM-Subnetz ausreichend groß zu konfigurieren, um die erwartete Anzahl an Farm-VMs und Desktops zu bewältigen.
  • Wenn Sie möchten, dass die Konfiguration eines externen Unified Access Gateway im VNet des Pods bereitgestellt wird, 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 für die Kommunikation mit dem Lastausgleichsdienst dieser Konfiguration des externen Gateways verwendet werden. Wenn Sie die Verwaltungs- und DMZ-Subnetz-Bereiche gemeinsam nutzen möchten, könnten Sie den Bereich des DMZ-Subnetzes ähnlich wie das Management-Subnetz mit einer spezifizierten 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 Gateways in einem eigenen VNet bereitgestellt werden soll, das vom VNet des Pods getrennt ist, benötigt jenes VNet drei Subnetze:
    • Ein Verwaltungssubnetz mit einem CIDR von mindestens /27 ist erforderlich. Dieses Subnetz ist für IP-Adressen, die von den VMs verwendet werden, die allgemein an den Verwaltungsaktivitäten des externen Gateways beteiligt sind, wie z. B. von 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 über das Peer-VNet mit den vom Pod bereitgestellten Farm- und Desktop-VMs im 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 Verwaltungssubnetz mit einer speziellen IP angeben. Wenn die IP des Verwaltungssubnetzes beispielsweise 192.168.8.0/27 lautet, hätte ein entsprechendes Front-End-Subnetz die IP 192.168.8.32/27.
Wichtig: Stellen Sie bei jedem CIDR sicher, dass jede Kombination aus Präfix und Bit-Maske einen IP-Adressbereich mit dem Präfix als IP-Startadresse ergibt. Microsoft Azure erfordert, dass das CIDR-Präfix den Anfang des Bereichs darstellt. Das korrekte CIDR 192.168.182.48/28 würde beispielsweise den IP-Bereich 192.168.182.48 bis 192.168.182.63 ergeben. Dabei ist das Präfix mit der IP-Startadresse (192.168.182.48) identisch. 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 das Präfix 192.168.182.60 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 das VNet verwendet, das Sie für den Pod verwenden möchten. Siehe First-Gen-Horizon Cloud – Konfigurieren des erforderlichen virtuellen Netzwerks in Microsoft Azure.

Stellen Sie sicher, dass sich die gewünschten Adressbereiche für die Subnetze nicht überschneiden. Der Assistent zur Pod-Bereitstellung zeigt einen Fehler an, wenn die Subnetzbereiche sich überlappen.

Prozedur

  1. Navigieren Sie im Microsoft Azure-Portal zu dem VNet, für das Sie die beschriebenen Subnetze erstellen müssen.
  2. Klicken Sie auf Subnetze.
  3. Klicken Sie auf + Subnetz.
    Der Bildschirm Subnetz hinzufügen wird angezeigt.
  4. Geben Sie die Informationen für die Pflichtfelder 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.
  5. Wenn es sich bei diesem Subnetz um das Verwaltungssubnetz handelt, wählen Sie im Abschnitt Dienstendpunkte den Dienst Microsoft.Sql aus.
  6. Klicken Sie auf OK.
    Das Subnetz wird dem VNet hinzugefügt.
  7. Wiederholen Sie die Schritte 3 bis 5, um die verbleibenden erforderlichen Subnetze hinzuzufügen.
  8. Wenn Sie das externe Gateway in einem eigenen VNet bereitstellen möchten, wiederholen Sie die Schritte für die Subnetze dieses VNet.

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, die bereits Elemente enthalten, die IP-Adressen in diesen Subnetzen verwenden. Wenn eine IP-Adresse bereits in den Subnetzen verwendet wird, treten sehr wahrscheinlich Probleme auf, z. B. Fehler bei der Pod-Bereitstellung und andere IP-Konfliktprobleme im Nachhinein. Sie dürfen weder Ressourcen in diese Subnetze einbinden noch eine der IP-Adressen an anderer Stelle verwenden. Diese Warnung umfasst Pods, die von Horizon Cloud bereitgestellt werden – verwenden Sie keine Subnetze erneut, auf denen Sie bereits einen Pod bereitgestellt haben.

Nächste Maßnahme

Stellen Sie für die von Ihnen erstellten Management-Subnetze sicher, dass der Dienst Microsoft.Sql als Dienstendpunkt aktiviert ist. Siehe First-Gen-Mandanten – Verwendung vorhandener Subnetze für einen Horizon Cloud-Pod in Microsoft Azure. Dieser Dienst muss im Verwaltungssubnetz des Pods aktiviert sein, und wenn Sie das externe Gateway in einem eigenen VNet bereitstellen, muss der Dienst auch auf dem Verwaltungssubnetz dieses Gateways aktiviert sein.