Konnektivitätsmodi und -anforderungen
In diesem Artikel werden die Konnektivitätsmodi beschrieben, die für Azure Arc-fähige Datendienste und ihre jeweiligen Anforderungen verfügbar sind.
Konnektivitätsmodi
Es gibt mehrere Optionen für den Grad der Konnektivität zwischen Ihrer Azure Arc-fähigen Datendienstumgebung und Azure. Da Ihre Anforderungen abhängig von der Geschäftsrichtlinie, behördlichen Regelungen oder der Verfügbarkeit von Netzwerkverbindungen mit Azure variieren, können Sie zwischen den folgenden Konnektivitätsmodi wählen.
Azure Arc-fähige Datendienste bieten Ihnen die Möglichkeit, in zwei verschiedenen Konnektivitätsmodi eine Verbindung mit Azure herzustellen:
- Direkt verbunden
- Indirekt verbunden
Dieser Konnektivitätsmodus bietet Ihnen die Flexibilität zu entscheiden, wie viele Daten an Azure gesendet werden und wie Benutzer mit dem Arc-Datencontroller interagieren. Abhängig vom ausgewählten Konnektivitätsmodus können einige Funktionen der Azure Arc-fähigen Datendiensten verfügbar bzw. nicht verfügbar sein.
Wichtig: Wenn die Azure Arc-fähigen Datendienste direkt mit Azure verbunden sind, können Benutzer die Azure Resource Manager-APIs, die Azure CLI und das Azure-Portal verwenden, um die Azure Arc-Datendienste zu betreiben. Das Verhalten im direkt verbundenen Modus ist ähnlich wie bei der Verwendung eines beliebigen anderen Azure-Diensts mit Bereitstellung/Aufhebung der Bereitstellung, Skalierung, Konfiguration usw. im Azure-Portal. Wenn die Azure Arc-fähigen Datendienste indirekt mit Azure verbunden sind, zeigt das Azure-Portal eine schreibgeschützte Ansicht an. Sie können den von Ihnen bereitgestellten Bestand an verwalteten SQL-Instanzen und PostgreSQL-Servern sowie die zugehörigen Details zwar anzeigen, aber nicht in diese im Azure-Portal eingreifen. Im indirekt verbundenen Modus müssen alle Aktionen lokal mithilfe von Azure Data Studio, der geeigneten CLI oder nativen Kubernetes-Tools wie kubectl ausgeführt werden.
Darüber hinaus kann die Microsoft Entra ID und rollenbasierte Azure-Zugriffssteuerung nur im Modus „Direkt verbunden“ verwendet werden, da die Bereitstellung dieser Funktionalität von einer kontinuierlichen und direkten Verbindung mit Azure abhängt.
Einige an Azure angefügte Dienste sind nur verfügbar, wenn sie direkt erreichbar sind (z. B. Container Insights) und Sicherungen in Blob Storage gespeichert werden.
| Indirekt verbunden | Direkt verbunden | Nie verbunden | |
|---|---|---|---|
| Beschreibung | Der Modus „Indirekt verbunden“ bietet die meisten Verwaltungsdienste lokal in Ihrer Umgebung ohne direkte Verbindung mit Azure. Eine minimale Datenmenge muss nur zu Inventur- und Abrechnungszwecken an Azure gesendet werden. Sie wird in eine Datei exportiert und mindestens ein Mal pro Monat in Azure hochgeladen. Es ist keine direkte oder kontinuierliche Verbindung mit Azure erforderlich. Einige Features und Dienste, die eine Verbindung mit Azure erfordern, sind nicht verfügbar. | Der Modus „Direkt verbunden“bietet alle verfügbaren Dienste, wenn eine direkte Verbindung mit Azure hergestellt werden kann. Verbindungen werden stets aus Ihrer Umgebung mit Azure initiiert und verwenden Standardports und -protokolle, z. B. HTTPS/443. | Es können keine Daten an oder aus Azure gesendet werden. |
| Aktuelle Verfügbarkeit | Verfügbar | Verfügbar | Wird derzeit nicht unterstützt. |
| Typische Anwendungsfälle | Lokale Rechenzentren, die aufgrund von Geschäfts- oder gesetzlichen Compliancerichtlinien oder aufgrund von Bedenken hinsichtlich externer Angriffe oder Datenexfiltration keine Konnektivität in die oder aus der Datenregion des Rechenzentrums zulassen. Typische Beispiele: Finanzinstitute, Gesundheitsversorgung, Regierung. Edge-Standorte, an denen der Edge-Standort in der Regel über keine Verbindung mit dem Internet verfügt. Typische Beispiele: Öl-/Gas- oder militärische Anwendungen. Edge-Standorte, die über zeitweilig auftretende Verbindungen mit langen Ausfallzeiten verfügen. Typische Beispiele: Stadien, Kreuzfahrtschiffe. |
Organisationen, die öffentliche Clouds verwenden. Typische Beispiele: Azure, AWS oder Google Cloud. Edge-Standorte, an denen eine Internetverbindung normalerweise vorhanden und zulässig ist. Typische Beispiele: Einzelhandelsgeschäfte, Produktion. Unternehmensrechenzentren mit restriktiveren Richtlinien für die Konnektivität in die bzw. aus der Datenregion des Rechenzentrums mit dem Internet. Typische Beispiele: nicht lizenzierte, kleine oder mittlere Unternehmen |
Wirklich „luftdichte“ Umgebungen, in denen unter keinen Umständen Daten aus der Datenumgebung gesendet oder in sie eingehen dürfen. Typische Beispiele: streng geheime Regierungseinrichtungen. |
| Senden von Daten an Azure | Es gibt drei Möglichkeiten, wie die Abrechnungs- und Inventardaten an Azure gesendet werden können: 1) Daten werden durch einen automatisierten Prozess, der sowohl mit der sicheren Datenregion als auch mit Azure verbunden ist, aus der Datenregion exportiert. 2) Daten werden durch einen automatisierten Prozess innerhalb der Datenregion aus der Datenregion exportiert, automatisch in eine weniger sichere Region kopiert, und ein automatisierter Prozess in der weniger sicheren Region lädt die Daten in Azure hoch. 3) Daten werden von einem Benutzer innerhalb der sicheren Region manuell exportiert, manuell aus der sicheren Region herausgebracht und manuell in Azure hochgeladen. Bei den ersten beiden Optionen handelt es sich um einen automatisierten kontinuierlichen Prozess, der so geplant werden kann, dass er häufig ausgeführt wird, sodass es nur minimale Verzögerungen bei der Datenübertragung an Azure gibt, abhängig ausschließlich von der verfügbaren Konnektivität mit Azure. |
Daten werden automatisch und kontinuierlich an Azure gesendet. | Daten werden nie an Azure gesendet. |
Funktionsverfügbarkeit nach Konnektivitätsmodus
| Feature | Indirekt verbunden | Direkt verbunden |
|---|---|---|
| Automatische Hochverfügbarkeit | Unterstützt | Unterstützt |
| Self-Service-Bereitstellung | Unterstützt Verwenden Sie Azure Data Studio, die richtigen CLI-Befehle oder kubernetesnative Tools wie Helm, kubectl oder oc. Sie können auch die GitOps- Bereitstellung für Azure Arc-fähiges Kubernetes verwenden. |
Unterstützt Neben den Erstellungsoptionen im Modus „Indirekt verbunden“ können Sie zum Erstellen auch das Azure-Portal, Azure Resource Manager-APIs, die Azure CLI oder ARM-Vorlagen verwenden. |
| Elastische Skalierbarkeit | Unterstützt | Unterstützt |
| Abrechnung | Unterstützt Abrechnungsdaten werden in regelmäßigen Abständen exportiert und an Azure gesendet. |
Unterstützt Abrechnungsdaten werden automatisch und kontinuierlich an Azure gesendet und in nahezu Echtzeit angezeigt. |
| Lagerverwaltung | Unterstützt Inventardaten werden in regelmäßigen Abständen exportiert und an Azure gesendet. Verwenden Sie Clienttools wie Azure Data Studio, Azure Data CLI oder kubectl, um den Bestand lokal anzuzeigen und zu verwalten. |
Unterstützt Inventardaten werden automatisch und kontinuierlich an Azure gesendet und in nahezu Echtzeit angezeigt. Sie können so den Bestand direkt im Azure-Portal verwalten. |
| Automatische Upgrades und Patches | Unterstützt Der Datencontroller muss entweder direkt auf Microsoft Container Registry (MCR) zugreifen können, oder die Containerimages müssen aus MCR gepullt und in eine lokale private Containerregistrierung gepusht werden, auf die der Datencontroller Zugriff besitzt. |
Unterstützt |
| Regelmäßige Sicherung und Wiederherstellung | Unterstützt Automatische lokale Sicherung und Wiederherstellung. |
Unterstützt Zusätzlich zur automatisierten lokalen Sicherung und Wiederherstellung können Sie optional Sicherungen für die langfristige Aufbewahrung außerhalb des Standorts an Azure Blob Storage senden. |
| Überwachung | Unterstützt Lokale Überwachung mit Grafana- und Kibana-Dashboards. |
Unterstützt Zusätzlich zu den lokalen Überwachungsdashboards können Sie optional Überwachungsdaten und Protokolle an Azure Monitor senden, um mehrere Standorte an einem Ort angemessen zu überwachen. |
| Authentifizierung | Verwenden Sie einen lokalen Benutzernamen bzw. ein lokales Kennwort für die Datencontroller- und Dashboardauthentifizierung. Verwenden Sie SQL- und Postgres-Anmeldungen oder Active Directory (AD wird zurzeit nicht unterstützt) für Verbindungen mit Datenbankinstanzen. Verwenden Sie Kubernetes-Authentifizierungsanbieter für die Authentifizierung bei der Kubernetes-API. | Zusätzlich zu oder anstelle der Authentifizierungsmethoden für den Modus „Indirekt verbunden“ können Sie optional die Microsoft Entra ID verwenden. |
| Rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) | Verwenden Sie Kubernetes RBAC mit der Kubernetes-API. Verwenden Sie SQL und Postgres RBAC für Datenbankinstanzen. | Sie können Microsoft Entra ID und Azure RBAC verwenden. |
Konnektivitätsanforderungen
Für einige Funktionen ist eine Verbindung mit Azure erforderlich.
Die gesamte Kommunikation mit Azure wird immer aus Ihrer Umgebung initiiert. Dies gilt auch für Vorgänge, die von einem Benutzer im Azure-Portal initiiert werden. In diesem Fall gibt es einen Task, der in Azure in die Warteschlange eingereiht wird. Ein Agent in Ihrer Umgebung initiiert die Kommunikation mit Azure, um zu ermitteln, welche Tasks in der Warteschlange enthalten sind, führt die Tasks aus und meldet den Status/Abschluss/Fehler an Azure.
| Datentyp | Richtung | Erforderlich/optional | Zusätzliche Kosten | Erforderlicher Modus | Hinweise |
|---|---|---|---|---|---|
| Containerimages | Microsoft Container Registry > Kunde | Erforderlich | Nein | Indirekt oder direkt | Containerimages stellen die Methode zum Verteilen der Software dar. In einer Umgebung, die eine Verbindung mit Microsoft Container Registry (MCR) über das Internet herstellen kann, können die Containerimages direkt aus MCR gepullt werden. Wenn die Bereitstellungsumgebung über keine direkte Verbindung verfügt, können Sie die Images aus MCR pullen und in eine private Containerregistrierung in der Bereitstellungsumgebung pushen. Zum Zeitpunkt der Erstellung können Sie den Erstellungsprozess so konfigurieren, dass der Pullvorgang aus der privaten Containerregistrierung anstatt aus MCR erfolgt. Dies gilt auch für automatisierte Updates. |
| Ressourceninventar | Kundenumgebung > Azure | Erforderlich | Nein | Indirekt oder direkt | Ein Inventar von Datencontrollern und Datenbankinstanzen (PostgreSQL und SQL) wird in Azure für Abrechnungszwecke und auch zu Zwecken der Erstellung eines Inventars aller Datencontroller und Datenbankinstanzen an einem Ort verwaltet, was besonders nützlich ist, wenn Sie mehrere Umgebungen mit Azure Arc-Datendiensten nutzen. Wenn Instanzen bereitgestellt werden bzw. ihre Bereitstellung aufgehoben wird, sie horizontal hoch- und herunterskaliert oder zentral hoch- oder herunterskaliert werden, wird das Inventar in Azure aktualisiert. |
| Abrechnungstelemetriedaten | Kundenumgebung > Azure | Erforderlich | Nein | Indirekt oder direkt | Die Nutzung von Datenbankinstanzen muss zu Abrechnungszwecken an Azure gesendet werden. |
| Überwachungsdaten und -protokolle | Kundenumgebung > Azure | Optional | Möglicherweise abhängig von der Datenmenge (siehe Azure Monitor-Preise) | Indirekt oder direkt | Vielleicht möchten Sie die lokal erfassten Überwachungsdaten und -protokolle an Azure Monitor senden, um Daten aus mehreren Umgebungen an einem Ort zu aggregieren und auch Azure Monitor-Dienste wie Warnungen zu nutzen, die Daten in Azure Machine Learning zu verwenden usw. |
| Rollenbasierte Zugriffssteuerung in Azure (Azure Role-Based Access Control, Azure RBAC) | Kundenumgebung > Azure > Kundenumgebung | Optional | Nein | Nur direkt | Wenn Sie Azure RBAC verwenden möchten, muss die Konnektivität mit Azure jederzeit hergestellt werden. Wenn Sie Azure RBAC nicht verwenden möchten, können Sie die lokale Kubernetes-RBAC verwenden. |
| Microsoft Entra ID (Future) | Kundenumgebung > Azure > Kundenumgebung | Optional | Möglicherweise zahlen Sie für die Microsoft Entra-ID bereits jetzt. | Nur direkt | Wenn Sie Microsoft Entra ID für die Authentifizierung verwenden möchten, muss Konnektivität mit Azure jederzeit hergestellt werden. Wenn Sie Microsoft Entra ID für die Authentifizierung nicht verwenden möchten, können Sie die Active Directory Federation Services (ADFS) über Active Directory verwenden. Ausstehende Verfügbarkeit des direkten Konnektivitätsmodus |
| Sichern und Wiederherstellen | Kundenumgebung > Kundenumgebung | Erforderlich | Nein | Indirekt oder direkt | Der Sicherungs- und Wiederherstellungsdienst kann so konfiguriert werden, dass er auf lokale Speicherklassen verweist. |
| Azure Backup: langfristige Aufbewahrung (Zukünftig) | Kundenumgebung > Azure | Optional | Ja, für Azure Storage | Nur direkt | Möglicherweise möchten Sie Sicherungen, die lokal erstellt wurden, an Azure Backup für die langfristige, externe Aufbewahrung von Sicherungen senden und sie zur Wiederherstellung in die lokale Umgebung zurückholen. |
| Bereitstellungs- und Konfigurationsänderungen aus dem Azure-Portal | Kundenumgebung > Azure > Kundenumgebung | Optional | Nein | Nur direkt | Bereitstellungs- und Konfigurationsänderungen können lokal mithilfe von Azure Data Studio oder der geeigneten CLI erfolgen. Im Modus „Direkt verbunden“ können Sie auch Konfigurationsänderungen im Azure-Portal bereitstellen und vornehmen. |
Details zu Internetadressen, Ports, Verschlüsselung und Proxyserverunterstützung
| Dienst | Port | URL | Richtung | Hinweise |
|---|---|---|---|---|
| Helm-Chart (nur direkt verbundener Modus) | 443 | arcdataservicesrow1.azurecr.io |
Ausgehend | Stellt den Azure Arc-Datencontroller-Bootstrapper und der Objekte auf Clusterebene bereit, z. B. benutzerdefinierte Ressourcendefinitionen, Clusterrollen und Clusterrollenbindungen, abgerufen per Pull aus einer Azure Container Registry. |
| Azure Monitor-APIs 1 | 443 | *.ods.opinsights.azure.com*.oms.opinsights.azure.com*.monitoring.azure.com |
Ausgehend | Azure Data Studio und die Azure CLI stellen eine Verbindung mit den Azure Resource Manager-APIs her, um für einige Funktionen Daten an Azure zu und aus Azure abzurufen. Siehe Azure Monitor APIs. |
| Azure Arc-Datenverarbeitungsdienst 1 | 443 | *.<region>.arcdataservices.com 2 |
Ausgehend |
1 Die Anforderung hängt vom Bereitstellungsmodus ab:
- Für den direkten Modus muss der Controller-Pod im Kubernetes-Cluster über ausgehende Verbindungen mit den Endpunkten verfügen, um die Protokolle, Metriken, Bestands- und Abrechnungsinformationen an Azure Monitor/Data Processing Service zu senden.
- Für den indirekten Modus muss der Computer, wo
az arcdata dc uploadausgeführt wird, über die ausgehende Verbindung zum Azure Monitor- und Datenverarbeitungsdienst verfügen.
2 Für Erweiterungsversionen bis einschließlich 13. Februar 2024 verwenden Sie san-af-<region>-prod.azurewebsites.net.
Azure Monitor-APIs
Verbindungen aus Azure Data Studio mit dem Kubernetes-API-Server verwenden die von Ihnen eingerichtete Kubernetes-Authentifizierung und -Verschlüsselung. Jeder Benutzer, der Azure Data Studio oder die CLI verwendet, muss über eine authentifizierte Verbindung mit der Kubernetes-API verfügen, um viele der Aktionen im Zusammenhang mit Azure Arc-fähigen Datendiensten ausführen zu können.
Zusätzliche Netzwerkanforderungen
Darüber hinaus erfordert die Ressourcenbrücke Arc-fähige Kubernetes-Endpunkte.