Azure Arc: Hybride Ressourcen verwalten

Die meisten Organisationen arbeiten in einer hybriden Umgebung: Einige Workloads laufen in Azure, andere auf lokalen Servern und wieder andere bei verschiedenen Cloudanbietern. Die Verwaltung dieser unterschiedlichen Umgebungen mit separaten Tools führt zu betrieblichen Silos – mit unterschiedlichen Richtlinien, Überwachungsmechanismen und Zugriffssteuerungen. Azure Arc löst dieses Problem, indem es die Azure-Verwaltungsebene auf beliebige Infrastrukturen erweitert. So können Sie lokale Ressourcen und Multi-Cloud-Ressourcen über dasselbe Azure-Portal, dieselbe CLI, dieselben Richtlinien und dasselbe RBAC verwalten, die Sie auch für native Azure-Ressourcen verwenden.

Azure Arc ist eine Sammlung von Technologien, die Nicht-Azure-Ressourcen in Azure Resource Manager (ARM) abbildet, sodass sie als Azure-Ressourcen mit Ressourcen-IDs angezeigt werden. Derzeit unterstützt Arc: Server (Windows-/Linux-VMs lokal oder in anderen Clouds), Kubernetes-Cluster (beliebige CNCF-konforme Kubernetes-Cluster), SQL Server-Instanzen, Azure-Datendienste (SQL Managed Instance und PostgreSQL auf Arc) sowie virtuelle Computer in VMware vSphere und Azure Stack HCI.

Um einen Windows- oder Linux-Server in Arc zu integrieren, installieren Sie den Azure Connected Machine-Agent auf dem Server. Der Agent registriert den Computer bei ARM und hält eine dauerhafte ausgehende Verbindung zu Azure aufrecht (eingehende Ports sind nicht erforderlich). Nach der Registrierung wird der Server im Azure-Portal unter Azure Arc > Servers mit einer vollständigen ARM-Ressourcen-ID angezeigt. Über das Portal können Sie ein interaktives oder automatisiertes Integrationsskript generieren, das Ihre Abonnement- und Ressourcengruppendetails enthält.

Sobald ein Server für Arc aktiviert ist, können Sie ihm Azure Policy-Definitionen genauso zuweisen wie einer nativen Azure-VM. Sie können beispielsweise überprüfen, ob der Log Analytics-Agent installiert ist, die Anwendung bestimmter Windows-Sicherheitsbaseline erzwingen oder den Defender for Cloud-Agent automatisch bereitstellen. Richtlinienzuweisungen auf Verwaltungsgruppen- oder Abonnementebene bewerten automatisch alle für Arc aktivierten Server in diesem Bereich. So erhalten Sie eine einheitliche Compliance-Ansicht über lokale und Cloudumgebungen hinweg.

Für Arc aktivierte Server können mithilfe des Azure Monitor Agent (AMA) Protokolle und Metriken an Azure Monitor senden. Sie erstellen eine Data Collection Rule (DCR), in der Sie festlegen, welche Leistungsindikatoren und Ereignisprotokolle erfasst und an welchen Log Analytics-Arbeitsbereich sie gesendet werden sollen. Dieselbe DCR kann sowohl auf für Arc aktivierte Server als auch auf native Azure-VMs angewendet werden und ermöglicht so eine einheitliche Überwachungskonfiguration. Sobald Daten übertragen werden, funktionieren dieselben KQL-Abfragen und Warnungsregeln, die Sie für Azure-VMs verwenden, auch für Arc-Server.

Wenn Sie Microsoft Defender for Servers auf einem für Arc aktivierten Server aktivieren, wird der Defender for Endpoint-Agent installiert. Dadurch erhalten Sie denselben Bedrohungsschutz, dieselbe Sicherheitsrisikoanalyse und dieselben Sicherheitsempfehlungen wie für Cloud-VMs. Dies ist besonders wertvoll für lokale Windows Server 2012- und 2019-Computer, die ohne Arc keine cloudnativen Sicherheitsprodukte verwenden können. Der Sicherheitsstatuswert in Defender for Cloud berücksichtigt alle Ressourcen – sowohl Azure- als auch Arc-verwaltete Ressourcen – und bietet Ihnen dadurch eine einheitliche Ansicht.

Azure Arc-enabled Kubernetes integriert beliebige CNCF-konforme Kubernetes-Cluster (lokal, GKE, EKS oder Rancher) in Azure. Sie installieren die Arc-Agents über ein Helm-Chart, woraufhin der Cluster in ARM angezeigt wird. Von Azure aus können Sie Anwendungen mithilfe von GitOps (von Azure verwaltetes Flux oder Argo CD) bereitstellen, Azure Policy für Kubernetes (OPA Gatekeeper) anwenden und den Clusterzustand in Azure Monitor anzeigen. Die Steuerungsebene wird auf dem Cluster selbst ausgeführt – Azure empfängt lediglich Statusinformationen und Telemetriedaten, nicht den vollständigen Zugriff auf den API-Server.

GitOps ist ein Bereitstellungsmuster, bei dem der gewünschte Zustand Ihrer Kubernetes-Workloads in einem Git-Repository definiert wird. Ein Agent auf dem Cluster gleicht den Clusterzustand kontinuierlich mit dem Repository ab. Bei Arc-fähigem Kubernetes konfigurieren Sie in Azure eine FluxConfiguration-Ressource, die auf Ihr Git-Repository verweist. Der Flux-Operator auf dem Cluster ruft Manifeste aus dem Repository ab und wendet sie an. Dadurch wird eine deklarative, prüfbare und automatisierte Anwendungsbereitstellung über beliebig viele Cluster hinweg aus einer einzigen vertrauenswürdigen Git-Quelle ermöglicht.

Azure Arc-enabled SQL Server integriert lokale SQL Server-Instanzen (2012–2022) in ARM. Zu den Vorteilen gehören: Azure Extended Security Updates (ESU) kostenlos bei bestehender Arc-Verbindung (für SQL Server 2012/2014, deren Mainstream-Support abgelaufen ist), die Bedrohungserkennung durch Microsoft Defender for SQL, Entra ID-Authentifizierung für lokale SQL Server sowie die Azure Monitor-Integration für Datenbankleistungsmetriken. Arc ändert nicht die Funktionsweise von SQL Server, sondern ergänzt lediglich Verwaltungsfunktionen.

Azure Arc resource bridge ist eine schlanke virtuelle Appliance, die in einer VMware-vSphere- oder Azure-Stack-HCI-Umgebung bereitgestellt wird. Sie stellt eine Verwaltungsverbindung her, über die Sie VMware-VMs im Azure-Portal anzeigen, starten, beenden und ihre Größe ändern können, ohne sie zu migrieren. Dies ist besonders nützlich für Organisationen am Anfang ihrer Cloudreise, die ihre Verwaltungswerkzeuge auf Azure standardisieren möchten, während sie VMs lokal ausführen. Über die Resource-Bridge-Verbindung können Sie außerdem Arc-Richtlinien auf diese VMs anwenden und sie mit Azure Monitor überwachen.

Der Azure Connected Machine-Agent und die Kubernetes-Arc-Integration sind kostenlos. Gebühren fallen für bestimmte Zusatzdienste an: Defender for Servers, die Datenerfassung durch den Azure Monitor-Agent und Arc-fähige Datendienste (SQL Managed Instance, PostgreSQL). Die einzigen Voraussetzungen für die Serverintegration sind: Der Server muss über ausgehenden HTTPS-Zugriff auf Azure-Endpunkte verfügen (oder einen Proxy verwenden), ein unterstütztes Betriebssystem ausführen (Windows Server 2008 R2 oder höher bzw. viele Linux-Distributionen) und über ein Azure-Abonnement verfügen, in dem der Ressourcenanbieter Microsoft.HybridCompute registriert ist.

Testen Sie Ihr Verständnis der Konzepte aus Microsoft Azure Fundamentals (AZ-900), die in dieser Lektion behandelt wurden.

In dieser Lektion haben Sie gelernt: Azure Arc erweitert die Azure-Verwaltungsebene auf lokale Server, Kubernetes-Cluster und SQL Server-Instanzen, indem diese in ARM abgebildet werden, der Azure Connected Machine-Agent integriert Server mit ausschließlich ausgehender HTTPS-Konnektivität, und GitOps mit Flux ermöglicht die deklarative Anwendungsbereitstellung über Arc-fähige Kubernetes-Cluster hinweg. Als Nächstes sehen wir uns Azure ExpressRoute und VPN Gateway für private Verbindungen zwischen lokalen Umgebungen und Azure an.