TechWiese Blog
Azure Arc for Servers: Hybrid-Management aus der Cloud
12. November 2019
Thomas Büdenbender
Dieser Blogbeitrag ist ein Repost und stammt im Original aus dem Tech-Blog von TechWiese, der in diesen Blog integriert wurde.
Auf der diesjährigen Ignite, die in der ersten November-Woche in Orlando stattfand, wurden wieder zahlreiche Neuerungen vorgestellt. Eine dieser Neuerungen ist Azure Arc. Was hinter diesem Service und genauer hinter „Azure Arc for Servers“ steckt, werde ich in diesem Blogbeitrag näher erklären.
Die offizielle Erklärung von Azure Arc lautet:
„Für Kunden, die komplexe und verteilte Umgebungen über Standorte, Edge und Multi-Cloud hinweg vereinfachen möchten, ermöglicht Azure Arc die Bereitstellung von Azure-Diensten an jedem beliebigen Ort und erweitert das Azure-Management auf jede Infrastruktur.“
Im Kern trifft diese Aussage schon ziemlich ins Schwarze. Die Aussage, dass die Zukunft der Cloud eine hybride ist, wird mit Azure Arc deutlich untermauert. Erstmals ist es möglich über die Grenzen von Azure hinweg, Workloads in anderen Umgebungen zu managen. Dazu gehören nicht nur Microsoft-eigene Technologien wie z.B. Azure Stack Hub (aka Azure Stack), sondern insbesondere On-Premises Umgebungen der Kunden und, was viele überrascht hat, auch andere Cloud-Umgebungen. So kann man mit Azure Arc tatsächlich Umgebungen auf AWS oder Google Cloud managen. Azure Arc gliedert sich somit optimal in Hybrid-Story von Microsoft ein.
Aber wie genau funktioniert Azure Arc? Zuerst muss man wissen, dass Azure Arc ein Begriff für mehrere hybride Management-Lösungen ist. So gehören heute insgesamt drei Lösungen zur Azure Arc-Familie.
Dieser Blogartikel widmet sich der ersten Implementierung: Azure Arc for Servers. Azure Arc for Servers ermöglicht ein hybrides Management von Servern, die nicht auf Azure betrieben werden. Dabei ist es unerheblich, wo sich die Server befinden, die verwaltet werden sollen. Server in einem On-Premises Datacenter können ebenso über Azure Arc verwaltet werden, wie Server in Cloud-Umgebungen anderer Anbieter. So können ebenfalls Windows und Linux Server unter AWS oder Google Cloud von Azure aus verwaltet werden.
Gerade das übergreifende Management bietet enorm viele Vorteile. So können z.B. über die Funktionalität der Guest-Configuration-Policies Richtlinien auch auf Servern außerhalb von Azure angewendet werden. Ob diese Server den Vorgaben entsprechen compliant sind, ist anschließend einfach über das Azure Portal einsehbar. Auch Berechtigungen gemäß den RBAC-Vorgaben sind so auf Servern außerhalb von Azure anwendbar.
Somit besteht erstmals die Möglichkeit, Maschinen auf Azure und in On-Premises-Umgebungen z.B. mit gleichen Governance- und Security-Richtlinien zu versorgen. Welche Managementfunktionen über Azure Arc for Servers zur Verfügung stehen, ist in der folgenden Grafik zu sehen:
Wie funktioniert die Verknüpfung zwischen Azure und nicht-Azure-VMs?
Virtuelle Maschinen innerhalb von Azure basieren auf dem Azure Ressource Manager (ARM). Über diese Schnittstelle kann mit den Ressourcen kommuniziert werden. Auch Azure Arc for Servers setzt auf ARM auf. VMs, die z.B. On-Premises laufen, werden durch einen Onboarding-Prozess an ARM gemeldet. Dies erfolgt durch die Anlage eines sog. Avatars (auch Digital Twin genannt) auf Azure. Im folgenden Schaubild ist zu erkennen, wie sich Azure Arc for Servers die Möglichkeiten von ARM nutzt:
Das Onboarding der VMs in Arc basiert auf einem Agent. Genau wie VMs innerhalb von Azure mit einem Guest Agent versorgt werden, um mit Azure kommunizieren zu können, benötigen auch VMs außerhalb von Azure einen entsprechenden Agenten – den Azure Connect Machine Agent. Dieser Agent wird während des Onboardings der VM installiert.
Wie läuft der Onboarding Prozess?"
Das Onboarding der VMs ist denkbar einfach. Nachfolgend sind ein paar Screenshots zu sehen, die diesen Prozess beschreiben. Azure Arc ist momentan in einer Public Preview und somit für jeden verfügbar. Einfach im Portal unter der Suche „Arc“ eingeben und „Azure Arc“ aus der Liste auswählen.
Als erstes kommt man zu dem Punkt, an dem man den entsprechenden Azure Arc Service auswählen kann. Wir entscheiden uns für den ersten Punk „Azure Arc for Servers“.
Wie auf dem Screenshot zu sehen ist, sind noch keine Server zu Azure Arc verfügbar. Durch den „+ Add“-Button starten wir den Onboarding-Prozess.
Es werden zwei Möglichkeiten angeboten, um Server aufzunehmen. Der erste Punkt ist für einzelne Server gedacht. Das Massen-Onboarding mehrerer Server wird über „Add machines at scale“ realisiert. Der Unterschied ist, dass beim ersten Punkt während des Onboardings eine User-ID und ein Passwort eingegeben werden muss, um den Avatar auf Azure anlegen zu können.
Beim Onboarding „At Scale“ wird dies über einen Service Principal geregelt, der für den Prozess angelegt werden muss. Der Service Principal wird lediglich für diesen Prozess benötigt und kann nach dem erfolgreichen Onboarding wieder gelöscht werden.
Dieses Beispiel beschäftigt sich mit dem ersten Punkt. Gestartet wird mit einem Klick auf „Generate Script“.
Nach der Auswahl der Subscription, der Resource Group und der Region besteht noch die Möglichkeit zwischen Windows- und Linux-Systemen zu unterscheiden.
An dieser Stelle möchte ich kurz auf die Kommunikation der On-Premises-Server mit Azure Arc eingehen: Es muss sichergestellt sein, dass eine ausgehende Kommunikation über SSL Port 443 möglich ist. Eingehende Kommunikation in das On-Premises-Datacenter ist nicht notwendig, es müssen somit keine Ports nach außen geöffnet werden. Selbstverständlich kann die Kommunikation bei Bedarf eingeschränkt werden. Lediglich die beiden Service Tags
- AzureActiveDirectory
- AzureTrafficManager
müssen erreichbar sein. Welche IP.Adressen hinter den Services stecken, ist einzusehen in Azure IP Ranges and Service Tags – Public Cloud.
Da gerade in großen Enterprise-Umgebungen keine direkte Kommunikation der Server mit dem Internet erwünscht ist, gibt es die Möglichkeit, die Kommunikation über einen HTTPS-Proxyserver laufen zu lassen. Die entsprechenden Daten des Proxyservers sind in der o.a. Maske einzugeben.
An dieser Stelle kann direkt ein Tag für den Avatar mitgegeben werden.
Auf der letzten Seite wird nun das Script angezeigt, welches auf der On-Premises-VM ausgeführt werden muss. Dies bewirkt, dass der Agent heruntergeladen und installiert und der Avatar in der entsprechenden Subscription erzeugt wird.
Nach dem erfolgreichen Onboarding sind die VMs unter Azure Arc sichtbar. Das es sich nicht um normale Azure VMs handelt, sieht man unter „Type“: Dort steht „Machine – Azure Arc“. Von nun an sind die Avatare auf Azure angelegt und können im Management benutzt werden. Die Kommunikation der VM On-Premises erfolgt über den installierten und konfigurierten Agent.
Zum Abschluss möchte ich noch gerne die verschiedenen Varianten erwähnen, über die ein Onboarding machbar ist. Wie im folgenden zu sehen, ist das Onboarding neben den bereits erwähnten zwei Wegen auch noch über das Windows Admin Center, den Azure Automation Service sowie den On-Premises System Center-Komponenten SCCM und SCVMM möglich.
Onboarding
- Agent deployment
-
Deployment at scale
- Create a service principle
- Using least permission (Assign RBAC role "Azure Connected Machine Onboarding")
-
Onboarding through other applications
- Windows Admin Center (available now)
- Azure automation service
- System Center Configration Manager (SCCM)
- System Center Virtual Machine Manager (SCVMM)
Wie schon weiter oben erwähnt, ist Azure Arc for Servers momentan in einer Public Preview verfügbar und kann von jedem genutzt werden. Es ist keine besondere Registrierung für die Preview erforderlich. Um noch tiefer in Azure Arc eintauchen zu können, möchte ich noch ein paar Link-Empfehlungen geben:
Wer sich den Content der Ignite zum Thema ansehen möchte, dem kann ich die folgenden Sessions empfehlen: