Azure Management mit Arc über Azure hinaus erweitern

Hey! Lass uns über eine Frage sprechen, die ich von Kunden oft höre, die erst zur Hälfte in Azure angekommen sind: Was macht man mit den Servern, die niemals umziehen? Der VMware-Cluster in der Fabrik, die SQL-Kiste im Colo mit noch drei Jahren Hardware-Laufzeit, der einzelne Hyper-V-Host, den irgendjemand noch am Leben hält. Du erkundest gerade Azure Policy, Defender for Cloud gefällt dir, und dann triffst du auf diese Maschine, und nichts davon greift, weil sie einfach nicht in Azure ist.

Genau diese Lücke schließt Arc. Nicht, indem die Maschine umzieht. Sondern indem sie als Ressource in Azure projiziert wird, sodass dieselbe Management-Ebene, die du schon für deine Cloud-VMs nutzt, auch Maschinen erreicht, die genau dort bleiben, wo sie sind.

Wie die Verbindung tatsächlich funktioniert

Das Herzstück von Arc ist der Connected Machine Agent, ein kleiner Dienst, den du auf dem On-Premises-Server oder der Maschine in einer anderen Cloud installierst. Sobald er mit Azure spricht, taucht dieser Server im Portal als reguläre Arc-fähige Server-Ressource auf, direkt neben deinen normalen VMs. Er bekommt eine Resource-ID, eine Resource Group, Tags, RBAC, das komplette Programm. Es fühlt sich wirklich an wie eine weitere VM in deiner Subscription, nur dass Azure die zugrunde liegende Rechenleistung nie anfasst.

Für alles über einzelne Maschinen hinaus gibt es die Azure Arc Resource Bridge, eine kleine Appliance (sie läuft selbst als VM), die in deiner VMware-, Hyper-V- oder SCVMM-Umgebung sitzt und die gesamte Virtualisierungsschicht nach Azure projiziert. Genau das erlaubt es, über Azure-APIs neue VMs auf VMware zu provisionieren, oder AKS auf eigener Hardware genauso zu verwalten wie AKS in der Cloud. Ich mag diesen Teil wirklich sehr, sobald die Bridge steht, ist diese ganze Umgebung für dein Azure-Tooling keine Blackbox mehr.

Es gibt auch Arc-fähigen SQL Server und Arc-fähiges Kubernetes, aber das Muster ist überall dasselbe: ein Agent oder eine Bridge, eine Ressourcen-Identität in Azure, und ab diesem Punkt verhält sich die Ressource für Management-Zwecke, als wäre sie Teil deines Azure-Bestands.

Was Arc kostet, und was nicht

Einen Server bei Arc zu registrieren ist kostenlos. Das überrascht Leute jedes Mal, wenn ich es erwähne. Bezahlt wird das, was du nach der Verbindung anbindest: der Server-Plan von Defender for Cloud, Azure-Monitor-Ingestion, wenn du Logs sendest, Update Manager, wenn du darüber patchst, Automanage, wenn du die Machine-Configuration-Baseline nutzt. Dasselbe Abrechnungsmodell, als würde dieser Workload nativ in Azure liegen.

Vor ein paar Monaten habe ich Arc über den kompletten Colo-Bestand eines Kunden ausgerollt, rein um Defender-for-Cloud-Abdeckung auf Servern zu bekommen, die Azure Security Center überhaupt nicht sehen konnte. Die Arc-Registrierung selbst hat die Rechnung nicht bewegt. Der Defender-Plan schon, aber das ist derselbe Preis, den sie für vergleichbaren Schutz auf einer Azure-VM gezahlt hätten, sie hatten die Option vorher nur nicht.

Der Ansatz, der tatsächlich funktioniert

Nicht versuchen, alles in einem Rutsch zu onboarden. Ich gehe Umgebung für Umgebung vor: einen Standort oder einen Cluster auswählen, Agenten oder Resource Bridge ausrollen, prüfen, dass die Ressourcen mit der richtigen Resource Group und den richtigen Tags in Azure landen, dann eine Policy und einen Defender-Scan gegen diese Umgebung validieren, bevor der nächste Standort drankommt. Skriptiert im großen Maßstab (Arc hat genau dafür ein Bulk-Onboarding-Skript) geht es schnell, sobald man dem Prozess vertraut, aber in der ersten Umgebung findet man die Firewall-Regel, die niemand dokumentiert hat, oder den Proxy, der eine Ausnahme für die ausgehenden Endpunkte des Agenten braucht.

Der Betrieb im Alltag

Das ist ehrlich gesagt der Teil, der den Aufwand rechtfertigt. Sobald die Maschinen verbunden sind:

• Azure Policy greift genauso wie bei nativen Azure-Ressourcen, inklusive Guest-Configuration-Policies, die Einstellungen innerhalb des Betriebssystems prüfen, nicht nur die Ressourcen-Metadaten.
• Update Manager liefert eine einzige Patch-Ansicht über Cloud und On-Premises hinweg, statt einer separaten WSUS- oder SCCM-Geschichte für die Server, die nicht in Azure sind.
• Run Command und Extensions erlauben es, Skripte zu pushen oder den Log-Analytics-Agenten, Antivirus oder Ähnliches zu installieren, aus demselben Portal-Blade, das man auch bei einer Cloud-VM nutzen würde.
• Azure Monitor und VM Insights sammeln dieselben Performance- und Log-Daten, die man nativ bekäme, sodass On-Premises nicht mehr die Stelle ist, an der die Dashboards still werden.

Der andere Grund, warum Leute das wirklich nutzen: ESU

Wenn du irgendwo noch Windows Server 2012 oder 2012 R2 laufen hast, ist das wahrscheinlich der Teil, der dich am meisten interessiert. Beide sind schon eine Weile aus dem Mainstream-Support raus, und eine ungepatchte Produktions-OS ist keine echte Option, aber diese Kiste unter Termindruck einfach zu ersetzen meistens auch nicht.

Extended Security Updates über Arc ist, wie ich diese Lücke inzwischen schließe. Man schreibt den Arc-fähigen Server direkt im Azure-Portal für ESU ein, abgerechnet pro Core, monatlich, über die Azure-Subscription, kein separater Volumenlizenzvertrag, kein Herumtelefonieren wegen einer speziellen SKU. Die Patches kommen dann über Update Manager, dasselbe Blade, das man für alles andere über Arc Verbundene ohnehin schon nutzt.

Der Teil, der wirklich Zeit spart: Man verwaltet keinen zweiten Patch-Prozess für die Maschinen, die ESU brauchen. Sie sind schon für Policy und Monitoring Arc-fähig, also ist ESU-Abdeckung einzuschalten nur eine weitere Sache auf einer Ressource, die man ohnehin schon im Blick hat, kein separates Projekt mit eigenem Tooling. Ich habe das genutzt, um einem Kunden ein weiteres Jahr für eine alte SQL-Server-2012-Kiste zu kaufen, während die eigentliche Migration sauber geplant wurde, statt sie in einen riskanten Cutover zu drängen, nur um gepatcht zu bleiben.

Der Trade-off dabei sollte auch klar benannt werden: ESU ist eine Brücke, kein Ziel. Es kauft Zeit, es kauft einen nicht davon frei, irgendwann von einer ausgemusterten OS wegzukommen. Aber wenn die eigentliche Migration auf 2012 R2 zwölf Monate entfernt ist, ist Arc-basiertes ESU der Unterschied zwischen gepatcht bleiben in diesem Fenster und stillschweigend hoffen, dass in der Zwischenzeit nichts ausgenutzt wird.

Governance, und warum das eigentlich der Punkt ist

Tags, RBAC und Azure Policy sind das, was aus einem Haufen verbundener Server etwas macht, das man tatsächlich steuern kann, nicht nur beobachten. Eine Policy, die einen Tag erzwingt oder Defender-Abdeckung verlangt, greift über den gesamten Bestand hinweg, Cloud und On-Premises, mit einer einzigen Zuweisung. Das ist ein einziges Governance-Modell statt zwei, und ehrlich gesagt, aus genau zwei Modellen entsteht der meiste Drift, den ich in hybriden Umgebungen sehe, ein Regelwerk für die Cloud-Ressourcen, an das alle denken, und was auch immer auf den On-Premises-Servern vor drei Jahren mal konfiguriert wurde.

Arc repariert deine Server nicht und dein Netzwerk auch nicht. Es ersetzt keine echte Migration, wenn Migration eigentlich das Ziel ist. Was es tut, ist jede Maschine, die dir gehört, in eine einzige konsistente Management-Oberfläche zu holen, sodass “die ist nicht in Azure” keine Ausrede mehr dafür ist, dass ein Server ungepatcht oder unüberwacht bleibt.

Wenn du Infrastruktur hast, die so bald nicht nach Azure zieht, registriere diese Woche einen Server bei Arc und schau ihm zu, wie er im Portal neben deinen Cloud-VMs auftaucht. Das ist beim ersten Mal ein wirklich befriedigender Moment. Happy coding!