Damit der Pod-Bereitstellungsprozess Ihren Pod in Microsoft Azure erfolgreich bereitstellen kann, müssen Sie Ihre Firewalls so konfigurieren, dass sie dem aktiven Pod-Manager den Zugriff auf die benötigten DNS-Adressen (Domain Name Service) zulassen. Außerdem muss Ihr DNS bestimmte Namen auflösen, wie in diesem Thema beschrieben. Wenn Sie das externe Gateway zusätzlich zur Haupt-Pod-Bereitstellung in einem eigenen VNet bereitstellen, muss das Subnetz dieses VNet dieselben DNS-Anforderungen erfüllen wie das Verwaltungssubnetz des eigenen VNet des Pods, wie in diesem Thema beschrieben.

Wichtig:

Der Pod-Bereitstellungsprozess verwendet eine Jump-Box-VM. Diese Jump Box-VM enthält Ports und Protokollanforderungen für den Bereitstellungsvorgang des Pods sowie für die Konfiguration der Einstellungen für die Unified Access Gateway-VMs des Pods, wenn Sie eine Unified Access Gateway-Konfiguration für den Pod bereitstellen. Siehe Ports und Protokolle, die bei Pod-Bereitstellungen und -Aktualisierungen für die Pod-Jumpbox erforderlich sind.

Die Bereitstellung des externen Gateways in einem eigenen VNet verwendet auch eine eigene Jumpbox-VM, die sich von der des Pods unterscheidet. Diese Jumpbox-VM verfügt über eigene Port- und Protokollanforderungen für den Gateway-Bereitstellungsprozess. Siehe Wenn das externe Gateway in einem eigenen VNet bereitgestellt wird: Ports und Protokolle, die bei Gateway-Bereitstellungen und -Aktualisierungen für die Jumpbox der Konfiguration des externen Gateways erforderlich sind.

Nachdem ein Pod erfolgreich bereitgestellt wurde, sind spezifische Ports und Protokolle für den laufenden Horizon Cloud-Betrieb erforderlich. Welche Ports und Protokolle erforderlich sind, hängt davon ab, ob sich der Pod auf der Manifestversion, die der Version von September 2019 entspricht, oder auf einer früheren Manifestversion befindet.

DNS-Anforderungen für den Gesamtprozess für die Pod-Bereitstellung, Pod-Updates und den laufenden Betrieb

Sie müssen sicherstellen, dass die folgenden DNS-Namen aus den Verwaltungs- und Mandantensubnetzen unter Verwendung der in der folgenden Tabelle angegebenen spezifischen Ports und Protokolle auflösbar und erreichbar sind. Horizon Cloud verwendet bestimmte ausgehende Ports, um die Pod-Software sicher in Ihre Microsoft Azure-Umgebung herunterzuladen, sodass sich der Pod wieder mit der Horizon Cloud-Steuerungsebene verbinden kann. Sie müssen die Regeln für Ihre Netzwerkfirewall, Netzwerksicherheitsgruppe (NSG) und Proxyserver konfigurieren, damit der aktive Pod-Manager die DNS-Adressen über die von ihm benötigten Ports erreichen kann. Andernfalls schlägt der Pod-Bereitstellungsprozess fehl.

Wichtig:
  • Wenn Sie die Funktion zum Bereitstellen des externen Gateways in einem eigenen VNet verwenden, muss das Verwaltungssubnetz in diesem VNet dieselben DNS-Anforderungen erfüllen, wie in der folgenden Tabelle für das Verwaltungssubnetz im VNet des Pods angegeben. Für das Back-End-Subnetz und das DMZ-Subnetz des VNet des externen Gateways gelten keine spezifischen DNS-Anforderungen.
  • Wenn Sie den Pod entweder mit einem externen Gateway, einem internen Gateway oder beiden bereitstellen, müssen Sie ein Zertifikat hochladen, das der Pod-Bereitsteller in diesen Gateway-Konfigurationen konfiguriert. Wenn das Zertifikat oder die Zertifikate, die Sie für diesen Zweck bereitstellen, CRLs (Zertifikatsperrlisten) oder OCSP (Online Certificate Status Protocol)-Einstellungen verwenden, die sich auf bestimmte DNS-Namen beziehen, müssen Sie sicherstellen, dass der ausgehende Internetzugriff aus dem VNet diese DNS-Server auflösen und erreichen kann. Während der Konfiguration Ihres bereitgestellten Zertifikats in der Unified Access Gateway-Gateway-Konfiguration greift die Unified Access Gateway-Software auf diese DNS-Namen zu, um den Sperrstatus des Zertifikats zu überprüfen. Wenn diese DNS-Namen nicht erreichbar sind, schlägt die Bereitstellung des Pods während der Phase Verbindung fehl. Diese Namen sind in hohem Maße von der Zertifizierungsstelle abhängig, die Sie zum Abrufen der Zertifikate verwendet haben. Sie unterliegen daher nicht der Kontrolle von VMware.

In Ihrer Begrüßungs-E-Mail für den Horizon Service wird angegeben, in welcher regionalen Steuerungsebeneninstanz Ihr Mandantenkonto erstellt wurde. Aufgrund eines bekannten Problems, das aufgetreten ist, als Ihnen die Begrüßungs-E-Mail gesendet wurde, werden in der von Ihnen empfangenen E-Mail möglicherweise die Namen der Systemzeichenfolge für die Regionen anstelle benutzerfreundlicher Namen angezeigt. Wenn Sie einen Systemzeichennamen in Ihrer Begrüßungs-E-Mail sehen, können Sie die folgende Tabelle verwenden, um zu erfahren, was in Ihrer E-Mail mit den DNS-Namen der regionalen Steuerungsebene angezeigt wird.

Tabelle 1. Regionen in ihrer Begrüßungs-E-Mail, die den DNS-Namen der regionalen Steuerungsebene zugeordnet sind
Ihre Begrüßungs-E-Mail lautet: Regionaler DNS-Name
USA cloud.horizon.vmware.com
EU_CENTRAL_1 oder Europe cloud-eu-central-1.horizon.vmware.com
AP_SOUTHEAST_2 oder Australia cloud-ap-southeast-2.horizon.vmware.com
PROD1_NORTHCENTRALUS2_CP1 oder USA-2 cloud-us-2.horizon.vmware.com
PROD1_NORTHEUROPE_CP1 oder Europe-2 cloud-eu-2.horizon.vmware.com
PROD1_AUSTRALIAEAST_CP1 oder Australia-2 cloud-ap-2.horizon.vmware.com
Tabelle 2. DNS-Anforderungen für die Bereitstellung und den Betrieb von Pods
Subnetz-Quelle Ziel (DNS-Name) Port Protokoll Zweck
Management Einer der folgenden Namen – je nachdem, welche regionale Horizon Cloud-Steuerungsebeneninstanz in Ihrem Horizon Cloud-Mandantenkonto angegeben ist. Die regionale Instanz wird beim Erstellen des Kontos festgelegt, wie unter Onboarding für Horizon Cloud für Microsoft Azure, Horizon On-Premises und Horizon für VMware Cloud on AWS beschrieben.
  • cloud.horizon.vmware.com
  • cloud-us-2.horizon.vmware.com
  • cloud-eu-central-1.horizon.vmware.com
  • cloud-eu-2.horizon.vmware.com
  • cloud-ap-southeast-2.horizon.vmware.com
  • cloud-ap-2.horizon.vmware.com
443 TCP Regionale Horizon Cloud-Steuerungsebeneninstanz
  • USA: cloud.horizon.vmware.com, cloud-us-2.horizon.vmware.com
  • Europa: cloud-eu-central-1.horizon.vmware.com, cloud-eu-2.horizon.vmware.com
  • Asien-Pazifik: cloud-ap-southeast-2.horizon.vmware.com, cloud-ap-2.horizon.vmware.com
Management softwareupdate.vmware.com 443 TCP VMware-Softwarepaketserver. Dient zum Herunterladen von Updates der Agent-bezogenen Software, die bei den Image-bezogenen Vorgängen des Systems verwendet wird.
Management Einer der folgenden Namen – je nachdem, welche der regionalen DNS-Namen auf Ihr Konto zutreffen.
  • d1mes20qfad06k.cloudfront.net
  • hydra-softwarelib-cdn.azureedge.net
443 TCP Horizon Cloud-Inhaltsbereitstellungsserver. Im Verwaltungssubnetz wird diese Site zum Download der VHDs (virtuellen Festplatten) für die Pod-Manager- und Unified Access Gateway-VMs verwendet. Wird auch für die VHD für die Gateway-Connector-VM verwendet, sofern sich das externe Gateway in seinem eigenen VNet befindet.)

d1mes20qfad06k.cloudfront.net entspricht regionalen Instanzen für cloud.horizon.vmware.com, cloud-eu-central-1.horizon.vmware.com, cloud-ap-southeast-2.horizon.vmware.com.

hydra-softwarelib-cdn.azureedge.net entspricht regionalen Instanzen für cloud-us-2.horizon.vmware.com, cloud-eu-2.horizon.vmware.com, cloud-ap-2.horizon.vmware.com

Management packages.microsoft.com 443 und 11371 TCP Microsoft Softwarepaketserver. Zum sicheren Herunterladen der Microsoft Azure Command Line Interface-(CLI)-Software.
Management azure.archive.ubuntu.com 80 TCP Ubuntu-Softwarepaketserver. Wird von den Pod-bezogenen Linux-basierten VMs für Aktualisierungen des Ubuntu-Betriebssystems verwendet.
Management api.snapcraft.io 443 TCP Ubuntu-Softwarepaketserver. Wird von den Linux-basierten VMs des Pods für Ubuntu-Betriebssystem-Updates verwendet.
Management archive.ubuntu.com 80 TCP Ubuntu-Softwarepaketserver. Wird von den Linux-basierten VMs des Pods für Ubuntu-Betriebssystem-Updates verwendet.
Management changelogs.ubuntu.com 80 TCP Ubuntu-Softwarepaketserver. Wird von den Linux-basierten VMs des Pods zur Verfolgung von Ubuntu-Betriebssystem-Updates verwendet.
Management security.ubuntu.com 80 TCP Ubuntu-Softwarepaketserver. Wird von den Linux-basierten VMs des Pods für sicherheitsrelevante Ubuntu-Betriebssystem-Updates verwendet.
Management Eine der folgenden Optionen, je nachdem, in welcher Microsoft Azure-Cloud Sie Ihren Pod bereitstellen:
  • Microsoft Azure (global): login.microsoftonline.com
  • Microsoft Azure Deutschland: login.microsoftonline.de
  • Microsoft Azure China: login.chinacloudapi.cn
  • Microsoft Azure US-Regierung: login.microsoftonline.us
443 TCP Diese Webadresse wird in der Regel von Anwendungen zur Authentifizierung bei Microsoft Azure-Diensten verwendet. Einige Beschreibungen in der Dokumentation zu Microsoft Azure finden Sie unter OAuth 2.0-Autorisierungscode-Fluss, Azure Active Directory v2.0 und das OpenID Connect-Protokoll und Nationale Clouds. Unter dem Thema Nationale Clouds werden die verschiedenen Azure AD-Authentifizierungs-Endpoints für die einzelnen nationalen Microsoft Azure-Clouds beschrieben.
Management Eine der folgenden Optionen, je nachdem, in welcher Microsoft Azure-Cloud Sie Ihren Pod bereitstellen:
  • Microsoft Azure (global): management.azure.com
  • Microsoft Azure Deutschland: management.microsoftazure.de
  • Microsoft Azure China: management.chinacloudapi.cn
  • Microsoft Azure US-Regierung: management.usgovcloudapi.net
443 TCP Wird für Anforderungen der Pod-API an die Microsoft Azure-Ressourcenmanager-Endpoints zur Verwendung von Microsoft Azure-Ressourcenmanager-Diensten verwendet. Microsoft Azure Resource Manager stellt eine konsistente Verwaltungsebene zum Ausführen von Aufgaben über Azure PowerShell, Azure CLI, Azure-Portal, REST-API und Client SDKs bereit.
Management Eine der folgenden Optionen, je nachdem, in welcher Microsoft Azure-Cloud Sie Ihren Pod bereitstellen:
  • Microsoft Azure (global): graph.windows.net
  • Microsoft Azure Deutschland: graph.cloudapi.de
  • Microsoft Azure China: graph.chinacloudapi.cn
  • Microsoft Azure US-Regierung: graph.windows.net
443 TCP Der Zugriff auf die Azure Active Directory (Azure AD) Graph-API, die für den programmgesteuerten Zugriff des Pods auf Azure Active Directory (Azure AD) über OData REST API-Endpoints verwendet wird.
Management Eine der folgenden Optionen, je nachdem, in welcher Microsoft Azure-Cloud Sie Ihren Pod bereitgestellt haben:
  • Microsoft Azure (global): *.blob.core.windows.net
  • Microsoft Azure Deutschland: *.blob.core.cloudapi.de
  • Microsoft Azure China: *.blob.core.chinacloudapi.cn
  • Microsoft Azure US-Regierung: *.blob.core.usgovcloudapi.net
443 TCP Wird für den programmgesteuerten Zugriff des Pods auf den Azure-Blobspeicher verwendet. Der Azure-Blobspeicher ist ein Dienst zum Speichern umfangreicher nicht strukturierter Objektdaten, z. B. Text oder binäre Daten.
Management Eine der folgenden Optionen, je nachdem, in welcher Microsoft Azure-Cloud Sie Ihren Pod bereitgestellt haben:
  • Microsoft Azure (global): *.vault.azure.net
  • Microsoft Azure Deutschland: *.vault.microsoftazure.de
  • Microsoft Azure China: *.vault.azure.cn
  • Microsoft Azure US-Regierung: *.vault.usgovcloudapi.net
443 TCP Wird für die Möglichkeit des Pods verwendet, programmgesteuert mit dem Azure Key Vault-Cloud-Dienst zu arbeiten. Azure Key Vault ist ein Cloud-Dienst, der einen sicheren Speicher für vertrauliche Daten bereitstellt.
Management Wenn Ihre Firewall oder Netzwerksicherheitsgruppe (NSG) die Verwendung von Diensttags unterstützt, ist eine der folgenden Optionen zulässig:
  • Globaler Azure-SQL-Diensttag: Sql
  • Regionsspezifischer SQL-Diensttag für die Azure-Region, in der der Pod bereitgestellt wird: Sql. Region , z. B. Sql.WestUS.

Wenn Ihre Firewall oder Netzwerksicherheitsgruppe (NSG) die Verwendung von Diensttags nicht unterstützt, können Sie den Hostnamen der Datenbank verwenden. Dieser Name folgt dem Muster *.postgres.database.azure.com.

5432 TCP Wird für die Pod-Kommunikation mit dem Microsoft Azure-PostgreSQL-Datenbankserver verwendet. Ab der Version von September 2019 werden Pods, die nach diesem Veröffentlichungsdatum neu bereitgestellt wurden, und Pod, die auf die Manifestversion dieser Version aktualisiert wurden, mit einem Microsoft Azure-PostgreSQL-Datenbankserver konfiguriert.

Informationen zu Diensttags in Sicherheitsgruppen finden Sie im Microsoft Azure-Dokumentationsthema zu Diensttags.

Management Einer der folgenden Namen – je nachdem, welche regionale Horizon Cloud-Steuerungsebeneninstanz in Ihrem Horizon Cloud-Mandantenkonto angegeben ist. Die regionale Instanz wird beim Erstellen des Kontos festgelegt, wie unter Onboarding für Horizon Cloud für Microsoft Azure, Horizon On-Premises und Horizon für VMware Cloud on AWS beschrieben.
  • connector-azure-us.vmwarehorizon.com
  • connector-azure-eu.vmwarehorizon.com
  • connector-azure-aus.vmwarehorizon.com
443 TCP Regionale Instanz des Universal Broker-Dienstes
  • Vereinigte Staaten: connector-azure-us.vmwarehorizon.com
  • Europa: connector-azure-eu.vmwarehorizon.com
  • Australien: connector-azure-aus.vmwarehorizon.com
Mandant Einer der folgenden Namen – je nachdem, welche der regionalen DNS-Namen auf Ihr Konto zutreffen.
  • d1mes20qfad06k.cloudfront.net
  • hydra-softwarelib-cdn.azureedge.net
443 TCP Horizon Cloud-Inhaltsbereitstellungsserver. Auf dem Mandanten-Subnetz wird diese Seite vom automatisierten Import-Image-Prozess des Systems verwendet, um das Installationsprogramm für die Agent-bezogene Software herunterzuladen.

d1mes20qfad06k.cloudfront.net entspricht regionalen Instanzen für cloud.horizon.vmware.com, cloud-eu-central-1.horizon.vmware.com, cloud-ap-southeast-2.horizon.vmware.com.

hydra-softwarelib-cdn.azureedge.net entspricht regionalen Instanzen für cloud-us-2.horizon.vmware.com, cloud-eu-2.horizon.vmware.com, cloud-ap-2.horizon.vmware.com

Mandant Abhängig von der regionalen Horizon Cloud-Steuerungsebene, die in Ihrem Horizon Cloud-Konto angegeben ist:

Nordamerika:

  • kinesis.us-east-1.amazonaws.com
  • query-prod-us-east-1.cms.vmware.com

Europa:

  • kinesis.eu-central-1.amazonaws.com
  • query-prod-eu-central-1.cms.vmware.com

Australien:

  • kinesis.ap-southeast-2.amazonaws.com
  • query-prod-ap-southeast-2.cms.vmware.com
443 TCP Cloud Monitoring Service (CMS)

Ports und Protokolle, die bei Pod-Bereitstellungen und -Aktualisierungen für die Pod-Jumpbox erforderlich sind

Gemäß der Beschreibung unter Bereitstellungshandbuch für Horizon Cloud wird eine Jumpbox-VM bei der ersten Erstellung eines Pods und bei nachfolgenden Software-Updates in der Umgebung des Pods verwendet. Nach der Erstellung eines Pods wird die Jumpbox-VM gelöscht. Anschließend wird die Jumpbox-VM beim Aktualisieren eines Pods neu erstellt, um diesen Aktualisierungsvorgang auszuführen. Wenn die Aktualisierung abgeschlossen ist, wird sie gelöscht. Zu diesen Aktualisierungen zählen auch Situationen, in denen ein Pod bearbeitet wird, um eine Unified Access Gateway-Konfiguration hinzuzufügen.

Hinweis: Ein Pod, der entweder ab der Version von September 2019 neu in Microsoft Azure bereitgestellt wird oder auf die der Version von September 2019 entsprechende Manifestebene aktualisiert wird, und für den die Hochverfügbarkeit aktiviert ist, verfügt über zwei Manager-VMs. Die folgenden Absätze verwenden den Plural „VMs“, um anzugeben, dass die Jump-Box-VM mit allen Pod-Manager-VMs kommunizieren muss, unabhängig davon, ob der Pod über eine oder zwei Manager-VMs verfügt.

Während dieser Prozesse kommuniziert die Jump Box-VM mit:

  • Den Manager-VMs des Pods unter Verwendung von SSH mit dem Port 22 der Manager-VMs. Infolgedessen muss während des Pods-Bereitstellungs- und Pod-Aktualisierungsvorgangs die Anforderung bezüglich der Kommunikation zwischen der Jumpbox-VM und Port 22 der Manager-VMs erfüllt sein. Port 22 der Manager-VMs muss zwischen Jump Box-VM als Quelle und Manager-VMs als Ziel zugelassen werden.
  • Den Unified Access Gateway-VMs mit HTTPS und Port 9443 für diese VMs, wenn ein Pod mit Unified Access Gateway-Konfiguration bereitgestellt oder bearbeitet wird, um eine solche Konfiguration hinzuzufügen. Infolgedessen muss während des Pod-Bereitstellungs- und Pod-Aktualisierungsvorgangs die Anforderung bezüglich der Kommunikation zwischen der Jump Box-VM und Port 9443 der Unified Access Gateway-VMs erfüllt sein, wenn die Pod-Konfiguration Unified Access Gateway beinhaltet. Port 9443 der Unified Access Gateway-VMs muss zwischen Jump Box-VM als Quelle und Unified Access Gateway-VMs als Ziel zugelassen werden.

Da diesen VMs dynamisch IP-Adressen zugewiesen werden, sollte für die Netzwerkregeln, die diese Kommunikation ermöglichen, Folgendes verwendet werden:

  • Das Management-Subnetz CIDR als Quelle und Ziel, mit Zielport 22, Quellport beliebig und Protokoll TCP.
  • Das Management-Subnetz CIDR als Quelle und Ziel, mit Zielport 9443, Quellport beliebig und Protokoll TCP, wenn eine Unified Access Gateway-Konfiguration involviert ist.
Hinweis: Für laufende Pod-Vorgänge muss Port 22 auf den Pod-Manager-VMs nicht verfügbar sein. Wenn Sie jedoch eine Support-Anfrage an VMware stellen und das Supportteam zum Debuggen dieser Anfrage eine Jumpbox-VM für die SSH-Kommunikation mit den Pod-Manager-VMs bereitstellt, müssen Sie diese Portanforderung erfüllen, während das VMware-Supportteam den Port zum Debuggen Ihres Problems benötigt. Dase VMware Support-Team informiert Sie in jeder Support-Situation über sämtliche Anforderungen.

Wenn das externe Gateway in einem eigenen VNet bereitgestellt wird: Ports und Protokolle, die bei Gateway-Bereitstellungen und -Aktualisierungen für die Jumpbox der Konfiguration des externen Gateways erforderlich sind

Gemäß der Beschreibung im Bereitstellungshandbuch für Horizon Cloud wird eine Jumpbox-VM bei der ersten Erstellung des externen Gateways und bei nachfolgenden Software-Updates auf dem Gateway im eigenen VNet verwendet. Nachdem das externe Gateway in einem eigenen VNet erstellt wurde, wird die Jumpbox-VM gelöscht. Anschließend wird die Jumpbox-VM beim Aktualisieren dieses externen Gateways neu erstellt, um diesen Aktualisierungsvorgang auszuführen. Wenn die Aktualisierung abgeschlossen ist, wird sie gelöscht. Zu solchen Aktualisierungen gehören auch diejenigen, bei denen ein Pod so bearbeitet wird, dass ein externes Gateway in einem eigenen VNet hinzugefügt wird.

Während dieser Prozesse kommuniziert die Jump Box-VM mit:

  • Während dieser Vorgänge kommuniziert diese Jumpbox-VM mit der Connector-VM des Gateways über SSH an den Port 22 dieser Connector-VM. Infolgedessen muss während des Gateway-Bereitstellungs- und -Aktualisierungsvorgangs die Anforderung bezüglich der Kommunikation zwischen der Jumpbox-VM und Port 22 der Connector-VMs erfüllt sein. Port 22 der Connector-VMs muss zwischen der Jumpbox-VM als Quelle und den Connector-VMs als Ziel zugelassen werden.
  • Den Unified Access Gateway-VMs mit HTTPS und Port 9443 dieser VMs. Infolgedessen muss während des Pod-Bereitstellungs- und Pod-Aktualisierungsvorgangs die Anforderung bezüglich der Kommunikation zwischen der Jump Box-VM und Port 9443 der Unified Access Gateway-VMs erfüllt sein, wenn die Pod-Konfiguration Unified Access Gateway beinhaltet. Port 9443 der Unified Access Gateway-VMs muss zwischen Jump Box-VM als Quelle und Unified Access Gateway-VMs als Ziel zugelassen werden.

Da diesen VMs dynamisch IP-Adressen zugewiesen werden, sollte für die Netzwerkregeln, die diese Kommunikation ermöglichen, Folgendes verwendet werden:

  • Das Management-Subnetz CIDR als Quelle und Ziel, mit Zielport 22, Quellport beliebig und Protokoll TCP.
  • Das Management-Subnetz CIDR als Quelle und Ziel, mit Zielport 9443, Quellport beliebig und Protokoll TCP.
Hinweis: Für laufende Pod-Vorgänge muss Port 22 auf der Connector-VM des Gateways nicht verfügbar sein. Wenn Sie jedoch eine Support-Anfrage an VMware stellen und das Supportteam zum Debuggen dieser Anfrage eine Jumpbox-VM für die SSH-Kommunikation mit der Connector-VM des Gateways bereitstellt, müssen Sie diese Portanforderung erfüllen, während das VMware-Supportteam den Port zum Debuggen Ihres Problems benötigt. Dase VMware Support-Team informiert Sie in jeder Support-Situation über sämtliche Anforderungen.