Für eine erfolgreiche End-to-End-Nutzung der Dienstfunktionen müssen Sie sicherstellen, dass die in diesem Dokumentationsartikel beschriebenen DNS-Namen (Domain Name Service) auflösbar und über das Verwaltungs- und Mandantensubnetz mithilfe bestimmter Ports und Protokolle, die in den Tabellen dieses Artikels angegeben werden, erreichbar sind. Der Pod-Bereitstellungsprozess, der einen pod-manager-basierten Pod in einem Microsoft Azure-Abonnement instanziiert, erfordert, dass die bereitstellerbezogenen Appliances über Ihr ausgewähltes VNet auf bestimmte DNS-Namen zugreifen können. Nachdem der Pod in Ihrem Abonnement erfolgreich instanziiert wurde und die pod-bezogenen Appliances ausgeführt werden, benötigen verschiedene täglich durchgeführte Dienstvorgänge Netzwerkzugriff auf bestimmte DNS-Namen sowie auf den Pod-Update-Vorgang zum Aktualisieren der Pod-Software, sobald VMware die neue Software zur Verfügung stellt. In diesem Artikel werden diese DNS-Anforderungen beschrieben.

Einige allgemeine Hauptpunkte

Info zu diesen benötigten DNS-Namen
Der Bereitsteller des Horizon Cloud-Pods, der den Prozess zum Instanziieren pod-manager-basierter Pods und der zugehörigen Gateways in Ihren Microsoft Azure-Abonnements automatisiert, benötigt Netzwerkzugriff auf bestimmte DNS-Adressen über die VNets dieser Abonnements. Damit der Pod-Bereitsteller die Pod-Komponenten in Ihrem Abonnement erfolgreich instanziieren kann, müssen Sie Ihre Firewalls so konfigurieren, dass den wichtigen bereitstellerbezogenen Appliances der Netzwerkzugriff gewährt wird, den sie für den Zugriff auf diese DNS-Adressen benötigen. Der Zweck der jeweiligen DNS-Adresse wird in den folgenden Tabellen angegeben. Die DNS-Konfiguration muss nicht nur die Netzwerkkommunikation mit diesen DNS-Adressen erlauben, sondern auch bestimmte Namen auflösen (Beschreibung in diesem Artikel). Wenn Sie die Option zum Bereitstellen des externen Gateways im eigenen vom VNet des Pod-Managers getrennten VNet auswählen, muss das Subnetz dieses VNets dieselben DNS-Anforderungen erfüllen wie das Verwaltungssubnetz des Pod-Manager-VNets.

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.

Neben dem Pod-Bereitsteller und seinen Workflows benötigen verschiedene Dienstfunktionen Zugriff auf bestimmte DNS-Adressen, damit diese Funktionen durchgängig funktionieren. Diese DNS-Namen werden auch in den folgenden Tabellen bereitgestellt.

Einige dieser DNS-Namen verfügen über ein regionales Element.

Durch die Aktivierung von Horizon-Infrastrukturüberwachung auf einem Pod wird die Virtuelle Horizon Edge-Appliance im VNet des Pod-Managers und im Verwaltungssubnetz automatisch instanziiert. Für Virtuelle Horizon Edge-Appliance gelten eigene DNS-Namensanforderungen. Deshalb müssen Sie vor dem Aktivieren von Horizon-Infrastrukturüberwachung auf einem Pod sicherstellen, dass die DNS-Anforderungen der Virtuelle Horizon Edge-Appliance erfüllt werden, die in den folgenden Tabellen angegeben werden.

Gemäß der Beschreibung in Enge Integration in das VMware-Ökosystem können Sie Horizon Cloud mit anderen Produkten aus dem VMware-Ökosystem verwenden. Für diese anderen Produkte gelten möglicherweise zusätzliche DNS-Anforderungen. Solche zusätzlichen DNS-Anforderungen werden hier nicht ausführlich beschrieben. Informationen zu solchen DNS-Anforderungen finden Sie im Dokumentationssatz für die spezifischen Produkte, die Sie in Ihren Pod integrieren werden.

Informationen zu Ports und Protokollen nach der Bereitstellung eines Pods für laufende dienstbezogene Vorgänge
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-Namen der regionalen Steuerungsebene

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
Japan cloud-jp.horizon.vmware.com
UK cloud-uk.horizon.vmware.com
Europe-3 cloud-de.horizon.vmware.com

Für die regionalen DNS-Adressen, die in den folgenden Tabellen für die Virtuelle Horizon Edge-Appliance aufgelistet werden, verwenden diese Adressen dieselben Regionen wie die DNS-Namen der regionalen Steuerungsebene.

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

Für eine erfolgreiche End-to-End-Nutzung der Dienstfunktionen müssen Sie sicherstellen, dass die folgenden DNS-Namen auflösbar und über das Verwaltungs- und Mandantensubnetz mithilfe bestimmter Ports und Protokolle, die in den Tabellen dieses Artikels angegeben werden, erreichbar sind. Zu den Dienstfunktionen, die die Fähigkeit zum Erreichen bestimmter DNS-Namen benötigen, gehören:

  • Der Pod-Bereitsteller, der einen pod-manager-basierten Horizon-Pod automatisch in Ihrem Microsoft Azure-Abonnement bereitstellt
  • Die Pod-Aktualisierungsfunktion zum Aktualisieren der Pod-Software auf eine aktuelle Version
  • Der Prozess zum Importieren von Images, der den Assistenten „Aus Marketplace importieren“ verwendet
  • Die agent-bezogenen Funktionen, wie z. B. automatische Agent-Aktualisierung (AAU)
  • Universal Broker
  • Horizon-Infrastrukturüberwachung und die zugehörige Virtuelle Horizon Edge-Appliance
  • Funktionen mit Bezug auf den Cloud Management Service (CMS)
Vor allem bei Pod-Bereitstellungen, Pod-Aktualisierungen und beim Aktivieren von Horizon-Infrastrukturüberwachung auf einem Pod
Sie müssen sicherstellen, dass die folgenden DNS-Namen aus den Verwaltungs- und Mandantensubnetzen unter Verwendung der in den folgenden Tabellen angegebenen spezifischen Ports und Protokolle auflösbar und erreichbar sind. Die in diesen Workflows verwendeten Appliances nutzen bestimmte ausgehende Ports, um die von diesen Prozessen benötigte Software sicher in die Azure-Umgebung herunterzuladen. Diese DNS-Namen werden auch verwendet, damit die entsprechenden workflow-bezogenen Appliances mit der Steuerungsebene der Cloud kommunizieren können.

Für neue Pod-Bereitstellungen müssen Sie die Netzwerk-Firewall, NSG-Regeln (Network Security Group) und Proxyserver konfigurieren, damit die bereitstellungsbezogenen Haupt-Appliances Kontakt zu den DNS-Adressen auf den von ihnen benötigten Ports herstellen können. Andernfalls schlägt der Pod-Bereitstellungsprozess fehl.

Durch Aktivierung von Horizon-Infrastrukturüberwachung auf einem Pod wird die Virtuelle Horizon Edge-Appliance im selben VNet- und Verwaltungsnetzwerk wie die Pod-Manager-Appliances des Pods instanziiert. Sie müssen sicherstellen, dass die Virtuelle Horizon Edge-Appliance mittels Konfiguration der Netzwerk-Firewall sowie der NSG-Regeln und Proxy-Server Kontakt zu den DNS-Adressen auf den von ihr benötigten Ports herstellen kann. Ansonsten schlägt die Bereitstellung dieser Appliance fehl.

Wenn Sie die Funktion verwenden, um das externe Gateway im eigenen VNet bereitzustellen
Das Verwaltungssubnetz in diesem VNet muss dieselben DNS-Anforderungen erfüllen, die in der folgenden Tabelle für das Verwaltungssubnetz im VNet des Pods angegeben werden. 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 mit beiden bereitstellen
Sie müssen 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.

DNS-Anforderungen für die Bereitstellung neuer Pods, Pod-Updates und Dienstvorgänge, die mandantenübergreifend angewendet werden

In der folgenden Tabelle werden die DNS-Anforderungen für die Bereitstellung neuer Pods, Pod-Updates und Dienstvorgänge beschrieben, die mandantenübergreifend gelten. Informationen zur Aktivierung von Horizon-Infrastrukturüberwachung und den DNS-Anforderungen der Virtuelle Horizon Edge-Appliance finden Sie im folgenden Abschnitt. Da die Funktion Horizon-Infrastrukturüberwachung pro Pod aktiviert wird, müssen die DNS-Anforderungen in einer eigenen Tabelle beschrieben werden.

Achtung: Ab Anfang 2021 ist der DNS-Name d1mes20qfad06k.cloudfront.net aufgrund eines Upgrades auf die regionalen Steuerungsebeneninstanzen des Diensts für keine der regionalen Steuerungsebeneninstanzen mehr erforderlich. Alle Instanzen der regionalen Steuerungsebene verwenden jetzt den DNS-Namen hydra-softwarelib-cdn.azureedge.net. Der Inhalt der folgenden Tabelle ist auf diese aktuelle Situation abgestimmt.
Tabelle 2. DNS-Anforderungen für die Bereitstellung neuer Pods, Pod-Updates und Dienstvorgänge, die mandantenübergreifend angewendet werden
Subnetz-Quelle Ziel (DNS-Name) Port Protokoll Zweck
Management Einer der folgenden Namen – je nachdem, welche regionale Steuerungsebeneninstanz in Ihrem Horizon Cloud-Mandantenkonto festgelegt ist. Die regionale Instanz wird beim Erstellen des Kontos festgelegt, wie unter Bereitstellung und Onboarding in Horizon Cloud für Microsoft Azure- und Horizon-Pods 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
  • cloud-jp.horizon.vmware.com
  • cloud-uk.horizon.vmware.com
  • cloud-de.horizon.vmware.com
443 TCP Regionale 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
  • Japan: cloud-jp.horizon.vmware.com
  • Großbritannien: cloud-uk.horizon.vmware.com
  • Deutschland: cloud-de.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 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.)
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 esm.ubuntu.com 80 TCP Ubuntu-Softwarepaketserver. Wird von den Linux-basierten VMs des Pods für die Verfolgung von Sicherheits-Updates für hohe und kritische CVEs (Common Vulnerabilities and Exposures) im Ubuntu-Basisbetriebssystem und in der Infrastruktur für die horizontale Skalierung 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 Steuerungsebeneninstanz in Ihrem Horizon Cloud-Mandantenkonto festgelegt ist. Die regionale Instanz wird beim Erstellen des Kontos festgelegt, wie unter Bereitstellung und Onboarding in Horizon Cloud für Microsoft Azure- und Horizon-Pods beschrieben.
  • connector-azure-us.vmwarehorizon.com
  • connector-azure-eu.vmwarehorizon.com
  • connector-azure-aus.vmwarehorizon.com
  • connector-azure-jp.vmwarehorizon.com
  • connector-azure-uk.vmwarehorizon.com
  • connector-azure-de.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
  • Japan: connector-azure-jp.vmwarehorizon.com
  • Großbritannien: connector-azure-uk.vmwarehorizon.com
  • Deutschland: connector-azure-de.vmwarehorizon.com
Management Abhängig von der regionalen Steuerungsebene, die für Ihr Horizon Cloud-Konto gilt:
  • Nordamerika: kinesis.us-east-1.amazonaws.com
  • Europa, Deutschland: kinesis.eu-central-1.amazonaws.com
  • Australien: kinesis.ap-southeast-2.amazonaws.com
  • Japan: kinesis.ap-northeast-1.amazonaws.com
  • Großbritannien: kinesis.eu-west-2.amazonaws.com
443 TCP Cloud Monitoring Service (CMS)
Mandant hydra-softwarelib-cdn.azureedge.net 443 TCP Horizon Cloud-Inhaltsbereitstellungsserver. Im Mandantensubnetz wird diese Site von verschiedenen imagebezogenen Prozessen des Systems verwendet, einschließlich Prozessen, die am automatischen Workflow „Image aus Marketplace importieren“ und am Workflow „Agenten-Paarbildung“ des Systems beteiligt sind.

Virtuelle Horizon Edge-Appliance-DNS-Anforderungen

Durch Aktivierung von Horizon-Infrastrukturüberwachung auf einem Pod wird die Linux-basierte Virtuelle Horizon Edge-Appliance in Ihrem Microsoft Azure-Abonnement instanziiert. Die Virtuelle Horizon Edge-Appliance wird im Abonnement des Pods mit einer Netzwerkkarte im Verwaltungssubnetz des Pods bereitgestellt – demselben Verwaltungssubnetz wie die Pod-Manager-Appliances dieses Pods. In der folgenden Tabelle sind die aufgelisteten Zwecke im Zusammenhang mit dieser virtuellen Appliance aufgeführt.

Hinweis: In dieser Tabelle sind im Gegensatz zur vorherigen Tabelle keine DNS-Namen mit uk enthalten. Wie in den Versionshinweisen angegeben, steht diese Horizon-Infrastrukturüberwachung-Funktion derzeit nur eingeschränkt zur Verfügung.
Tabelle 3. DNS-Anforderungen für Horizon Infrastructure Monitoring
Subnetz-Quelle Ziel (DNS-Name) Port/Protokoll Zweck
Management
  • azure.archive.ubuntu.com
  • archive.ubuntu.com
  • changelogs.ubuntu.com
  • security.ubuntu.com
80 und 443/TCP Ubuntu-Softwarepaketserver. Wird von der Linux-basierten Appliance für Ubuntu-Betriebssystem-Updates verwendet.
Management esm.ubuntu.com 80/TCP Ubuntu-Softwarepaketserver. Wird von der Linux-basierten Appliance für die Verfolgung von Sicherheits-Updates für hohe und kritische CVEs (Common Vulnerabilities and Exposures) im Ubuntu-Basisbetriebssystem und in der Infrastruktur für die horizontale Skalierung verwendet.
Management
  • *.blob.core.windows.net
  • horizonedgeprod.azurecr.io
443/TCP Wird für den programmgesteuerten Zugriff auf Azure Blob Storage verwendet.

Wird zum Herunterladen der Docker-Images aus den DNS-Adressen verwendet, die vom Modul der Appliance benötigt werden.

Management

*.azure-devices.net oder einer der folgenden regionsspezifischen Namen, je nachdem, welche regionale Steuerungsebene für Ihr Mandantenkonto gilt:

Nordamerika:

  • edgehubprodna.azure-devices.net

Europa:

  • edgehubprodeu.azure-devices.net

Australien:

  • edgehubprodap.azure-devices.net

Japan:

  • edgehubprodjp.azure-devices.net
443/TCP Wird zum Verbinden der Appliance mit der Horizon Cloud-Steuerungsebene, zum Herunterladen von Konfigurationen für das Appliance-Modul und zum Aktualisieren des Laufzeitstatus des Appliance-Moduls verwendet.
Management
  • *.docker.com
  • *.docker.io
  • docker.io
  • cloud.google.com
  • gcr.io
  • dl.k8s.io
  • k8s.gcr.io
  • storage.googleapis.com
  • cloud.weave.works
  • packages.cloud.google.com
  • apt.kubernetes.io
443/TCP Wird zum Herunterladen von Docker- und Kubernetes-Binärdateien verwendet, die von der Appliance benötigt werden.
Management Abhängig von der regionalen Steuerungsebene, die für Ihr Mandantenkonto gilt:

Nordamerika:

  • kinesis.us-east-1.amazonaws.com
  • sauron.horizon.vmware.com

Europa:

  • kinesis.eu-central-1.amazonaws.com
  • sauron-eu.horizon.vmware.com

Australien:

  • kinesis.ap-southeast-2.amazonaws.com
  • sauron-ap.horizon.vmware.com

Japan:

  • kinesis.ap-northeast-1.amazonaws.com
  • sauron-jp.horizon.vmware.com
443/TCP Wird zum Senden der von der Appliance erfassten Pod-Überwachungsdaten an die Horizon Cloud-Steuerungsebene verwendet.

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

Gemäß der Beschreibung unter Microsoft Azure-VM-Anforderungen für einen Horizon Cloud-Pod 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 unter Microsoft Azure-VM-Anforderungen für einen Horizon Cloud-Pod wird eine Jumpbox-VM bei der ersten Erstellung des externen Gateways in seinem eigenen VNet und bei nachfolgenden Software-Updates auf diesem Gateway 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.