Automation: Übersicht über Hybrid Runbook Worker

Wichtig

Der Azure Automation Agent-basierte Benutzer-Hybrid Runbook Worker (Windows und Linux) wurde am 31. August 2024 eingestellt und wird nicht mehr unterstützt. Befolgen Sie die Richtlinien zum Migrieren von einem vorhandenen Agent-basierten Benutzer für Hybrid Runbook Worker zu erweiterungsbasierten Hybrid-Workern.

Runbooks in Azure Automation haben möglicherweise keinen Zugriff auf Ressourcen in anderen Clouds oder in Ihrer lokalen Umgebung, da sie auf der Azure-Cloudplattform ausgeführt werden. Sie können Runbooks mit dem Azure Automation-Feature „Hybrid Runbook Worker“ direkt auf dem Computer, der die Rolle hostet, und für Ressourcen in der Umgebung ausführen, um diese lokalen Ressourcen zu verwalten. Runbooks werden in Azure Automation gespeichert und verwaltet und an einzelne oder mehrere zugewiesene Computer übermittelt.

Azure Automation bietet eine native Integration der Hybrid Runbook Worker-Rolle über das Erweiterungsframework für Azure-VMs. Der Azure-VM-Agent ist für die Verwaltung der Erweiterung auf Azure-VMs mit Windows und Linux-VMs verantwortlich und der Azure Connected Machine-Agent auf Nicht-Azure-Computern, einschließlich Servern mit Azure Arc-Unterstützung und VMware vSphere mit Azure Arc-Unterstützung (Vorschau). Es gibt nun zwei Hybrid Runbook Worker-Installationsplattformen, die von Azure Automation unterstützt werden.

Plattform Beschreibung
Erweiterungsbasiert (V2) Die Installation erfolgt mithilfe der Hybrid Runbook Worker-VM-Erweiterung. Sie ist nicht davon abhängig, ob der Log Analytics-Agent Berichte an einen Log Analytics-Arbeitsbereich in Azure Monitor übermittelt. Dies ist die empfohlene Plattform.
Agent-basiert (V1) Die Installation erfolgt, nachdem der Log Analytics-Agent Meldungen an einen Log Analytics-Arbeitsbereich von Azure Monitor gesendet hat.

Screenshot der Hybrid Worker-Gruppe mit dem Feld „Plattform“.

Bei Hybrid Runbook Worker-Vorgängen nach der Installation ist der Prozess der Ausführung von Runbooks auf Hybrid Runbook Workern identisch. Der erweiterungsbasierte Ansatz dient dazu, die Installation und Verwaltung der Hybrid Runbook Worker-Rolle zu vereinfachen und die Komplexität gegenüber der Arbeit mit der Agent-basierten Version zu verringern. Die neue erweiterungsbasierte Installation wirkt sich nicht auf die Installation oder Verwaltung einer Agent-basierten Hybrid Runbook Worker-Rolle aus. Beide Typen von Hybrid Runbook Workern können auf demselben Computer gleichzeitig vorhanden sein.

Erweiterungsbasierte Hybrid Runbook Worker unterstützen nur den benutzerbasierten Hybrid Runbook Worker-Typ und enthalten nicht den System-Hybrid Runbook Worker, der für die Updateverwaltung erforderlich ist.

Vorteile von erweiterungsbasierten Benutzer-Hybrid Workern

Der erweiterungsbasierte Ansatz vereinfacht die Installation und Verwaltung des Benutzer-Hybrid Runbook Workers erheblich und beseitigt dabei die Komplexität des Arbeitens mit dem Agent-basierten Ansatz. Im Folgenden finden Sie einige wichtige Vorteile:

  • Nahtloses Onboarding: Der Agent-basierte Ansatz für das Onboarding von Hybrid Runbook Workern hängt vom Log Analytics-Agent ab, bei dem es sich um einen mehrstufigen, zeitaufwändigen und fehleranfälligen Prozess handelt. Der erweiterungsbasierte Ansatz ist nicht mehr vom Log Analytics-Agent abhängig.
  • Einfache Verwaltbarkeit: Bietet native Integration in die ARM-Identität für Hybrid Runbook Worker sowie die Flexibilität für Governance im großen Stil mittels Richtlinien und Vorlagen.
  • Microsoft Entra ID-basierte Authentifizierung: Verwendet eine systemseitig zugewiesene verwaltete VM-Identität, die von Microsoft Entra ID bereitgestellt wird. Damit wird die Steuerung und Verwaltung von Identitäten und Ressourcenanmeldeinformationen zentralisiert.
  • Einheitliche Benutzeroberfläche: Bietet eine identische Erfahrung für die Verwaltung von Azure-Computern sowie von Nicht-Azure-Computern mit Arc-Unterstützung.
  • Mehrere Onboardingkanäle: Sie können sich entschließen, das Onboarding erweiterungsbasierter Worker über das Azure-Portal, mit PowerShell-Cmdlets, mittels Bicep, ARM-Vorlagen, REST-API oder Azure CLI durchzuführen und sie zu verwalten. Sie können die Erweiterung auch auf einer vorhandenen Azure-VM oder einem Server mit Arc-Unterstützung innerhalb der Azure-Portal-Erfahrung dieses Computers auf dem Blatt „Erweiterungen“ installieren.
  • Standardmäßiges automatisches Upgrade: Bietet standardmäßig ein automatisches Upgrade von Nebenversionen, wodurch der Verwaltungsaufwand, um auf die neueste Version aktualisiert zu bleiben, erheblich verringert wird. Es wird empfohlen, automatische Upgrades zu aktivieren, um ohne den manuellen Aufwand von allen Sicherheits- oder Featureupdates zu profitieren. Sie können automatische Upgrades auch jederzeit kündigen. Hauptversionsupgrades werden derzeit nicht unterstützt und sollten manuell verwaltet werden.

Runbook Worker-Typen

Es gibt zwei Arten von Runbook Workern – System und Benutzer. In der folgenden Tabelle sind die Unterschiede zwischen diesen beschrieben.

type Beschreibung
System Unterstützt einen Satz ausgeblendeter Runbooks, die von der Updateverwaltungsfunktion verwendet werden, die für die Installation von benutzerdefinierten Updates auf Windows- und Linux-Computern vorgesehen sind.
Dieser Typ von Hybrid Runbook Workern ist kein Mitglied einer Hybrid Runbook Worker-Gruppe und führt daher keine Runbooks aus, die auf eine Runbook Worker-Gruppe abzielen.
Benutzer Unterstützt benutzerdefinierte Runbooks, die direkt auf dem Windows- und Linux-Computer ausgeführt werden sollen.

Agent-basierte (V1) Hybrid Runbook Worker erfordern den Log Analytics-Agent, der Meldungen an einen Log Analytics-Arbeitsbereich in Azure Monitor sendet. Der Arbeitsbereich kann nicht nur Überwachungsdaten vom Computer sammeln, sondern auch die Komponenten herunterladen, die für die Installation des agentenbasierten Hybrid Runbook Workers benötigt werden.

Wenn die Azure Automation-Updateverwaltung aktiviert ist, werden alle mit dem Log Analytics-Arbeitsbereich verbundenen Computer automatisch als System-Hybrid Runbook Worker konfiguriert. Informationen zur Konfiguration als benutzerbasierter Windows-Hybrid Runbook Worker finden Sie unter Bereitstellen eines Agent-basierten Windows-Hybrid Runbook Workers und für Linux unter Bereitstellen eines Agent-basierten Linux-Hybrid Runbook Workers.

Grenzwerte für Runbook Worker

Die folgende Tabelle zeigt die maximale Anzahl hybrider Runbook Worker für Systeme und Benutzer in einem Automation-Konto an. Wenn Sie mehr als 4.000 Computer verwalten müssen, empfiehlt es sich, ein weiteres Automation-Konto zu erstellen.

Workertyp Maximal unterstützte Anzahl pro Automation-Konto
System 4000
Benutzer 4000

Wie funktioniert dies?

Jeder Benutzer-Hybrid Runbook Worker ist Mitglied einer Hybrid Runbook Worker-Gruppe, die Sie beim Installieren des Workers angeben. Eine Gruppe kann einen einzelnen Worker umfassen, aber für Hochverfügbarkeit können Sie mehrere Worker in eine Gruppe aufnehmen. Jeder Computer kann eine Hybrid Runbook Worker-Berichterstellung für ein Automation-Konto hosten. Sie können den Hybrid Worker nicht bei mehreren Automation-Konten registrieren. Ein Hybrid Worker kann nur auf Aufträge eines einzelnen Automation-Kontos lauschen.

Technisches Diagramm eines Hybrid Runbook Workers für Benutzer

Computer, auf denen der von der Updateverwaltung verwaltete System-Hybrid Runbook Worker gehostet wird, können einer Hybrid Runbook Worker-Gruppe hinzugefügt werden. Sie müssen aber für die Updateverwaltung und die Mitgliedschaft in der Hybrid Runbook Worker-Gruppe dasselbe Automation-Konto verwenden.

Technisches Diagramm eines Hybrid Runbook Workers für Systeme

Eine Hybrid Worker-Gruppe mit Hybrid Runbook Workern ist auf Hochverfügbarkeit und Lastenausgleich ausgelegt, indem Aufträge auf mehrere Worker verteilt werden. Damit Runbooks erfolgreich ausgeführt werden können, müssen Hybrid Worker fehlerfrei sein und einen Heartbeat liefern. Der Hybrid Worker arbeitet an einem Abfragemechanismus, um Aufträge aufzunehmen. Wenn keiner der Worker innerhalb der Hybrid Worker-Gruppe den Automation-Dienst in den letzten 30 Minuten angepingt hat, bedeutet dies, dass die Gruppe keine aktiven Worker hatte. In diesem Szenario werden Aufträge nach drei Wiederholungsversuchen angehalten.

Wenn Sie ein Runbook für einen Benutzer-Hybrid-Runbook-Worker starten, geben Sie die Gruppe an, auf der es ausgeführt wird, und können keinen bestimmten Worker angeben. Jeder aktive Hybrid Worker in der Gruppe fragt alle 30 Sekunden nach Aufträgen ab, um zu ermitteln, ob welche verfügbar sind. Der Worker wählt Aufträge auf der Grundlage von „First Come, First Served“ aus. Je nachdem, wann ein Auftrag gepusht wurde, übernimmt der Hybrid Worker innerhalb der Hybrid Worker-Gruppe den Auftrag, der den Automation-Dienst zuerst angepingt hat. Die Verarbeitungszeit der Auftragswarteschlange hängt auch vom Hybrid Worker-Hardwareprofil und der Auslastung ab.

Ein einzelner Hybrid Worker kann generell vier Aufträge pro Ping abrufen (d. h. alle 30 Sekunden). Wenn Die Anzahl der Pushaufträge höher als 4 pro 30 Sekunden ist und kein anderer Worker den Auftrag abnimmt, wird der Auftrag möglicherweise mit einem Fehler angehalten.

Ein Hybrid Runbook Worker weist viele der Ressourceneinschränkungen einer Azure-Sandbox hinsichtlich Datenträgerplatz, Arbeitsspeicher oder Netzwerksockets nicht auf. Die Grenzwerte eines Hybrid Worker werden nur durch die eigenen Ressourcen des Workers bestimmt und sind nicht durch die Zeitbeschränkung durch die gleichmäßige Verteilung eingeschränkt, die für Azure-Sandboxes gilt.

Um die Verteilung von Runbooks auf Hybrid Runbook Worker zu steuern, und wann oder wie die Aufträge ausgelöst werden, können Sie den Hybrid Worker für verschiedene Hybrid Runbook Worker-Gruppen innerhalb Ihres Automation-Kontos registrieren. Richten Sie die Aufträge auf die jeweilige Gruppe oder die Gruppen aus, um Ihre Ausführungsanordnung zu unterstützen.

Häufige Szenarien für Benutzer-Hybrid Runbook Worker

  • Zum Ausführen von Azure Automation-Runbooks für die Verwaltung auf Gast-VMs direkt auf einem vorhandenen virtuellen Azure-Computer (VM) und einem Nicht-Azure-Server mit Arc-Unterstützung, der als Server mit Azure Arc-Unterstützung oder als VMware-VM mit Azure Arc-Unterstützung (Vorschau) registriert ist. Server mit Azure Arc-Unterstützung können physische Server und virtuelle Computer unter Windows und Linux sein, die außerhalb von Azure, in Ihrem Unternehmensnetzwerk oder bei anderen Cloudanbietern gehostet werden.
  • Zum Umgehen der Einschränkungen einer Azure Automation-Sandbox umfassen die gängigen Szenarien das Ausführen zeitintensiver Vorgängen über die Drei-Stunden-Grenze hinaus für Cloudaufträge, das Ausführen ressourcenintensiver Automatisierungsvorgänge, die Interaktion mit lokalen Diensten, die lokal oder in einer Hybridumgebung ausgeführt werden, sowie das Ausführen von Skripts, die erhöhte Berechtigungen erfordern.
  • Zum Umgehen von Einschränkungen der Organisation beim Beibehalten von Daten in Azure aus Governance- und Sicherheitsgründen können Sie Automation-Aufträge nicht in der Cloud ausführen, sondern müssen sie auf einem lokalen Computer ausführen, der als Benutzer-Hybrid Runbook Worker integriert ist.
  • Zum Automatisieren von Vorgängen auf mehrere Nicht-Azure-Ressourcen, die lokal, hybrid oder in Multicloud-Umgebungen ausgeführt werden. Sie können das Onboarding eines dieser Computer als Benutzer-Hybrid Runbook Worker durchführen und die Automatisierung auf die verbleibenden Computer in der lokalen Umgebung ausrichten.
  • Zum privaten Zugreifen auf andere Dienste aus dem Azure-VNet, ohne eine ausgehende Internetverbindung herzustellen, können Sie Runbooks auf einem Hybrid Worker ausführen, der mit dem Azure-VNet verbunden ist.

Installation von Hybrid Runbook Workern

Der Vorgang zum Installieren eines Benutzer-Hybrid Runbook Workers ist vom Betriebssystem abhängig. In der folgenden Tabelle sind die Bereitstellungstypen definiert.

Betriebssystem Bereitstellungstypen
Windows Automatisiert
Manuell.
Linux Manuell
Sowohl als auch Informationen zu benutzerbasierten Hybrid Runbook Workern finden Sie unter Bereitstellen von erweiterungsbasierten Windows- oder Linux-Hybrid Runbook Workern in Automation. Dies ist die empfohlene Methode.

Hinweis

Hybrid Runbook Worker wird derzeit nicht für VM Scale Sets unterstützt.

Netzwerkplanung

Überprüfen Sie die Azure Automation-Netzwerkkonfiguration, um ausführliche Informationen zu den Ports, URLs und anderen Netzwerkdetails zu erhalten, die für Hybrid Runbook Worker erforderlich sind.

Verwenden von Proxyservern

Wenn Sie einen Proxyserver für die Kommunikation zwischen Azure Automation und den Computern verwenden, auf denen der Log Analytics-Agent ausgeführt wird, müssen Sie sicherstellen, dass auf die entsprechenden Ressourcen zugegriffen werden kann. Das Zeitlimit für Anforderungen vom Hybrid Runbook Worker und von den Automation-Diensten beträgt 30 Sekunden. Nach drei Versuchen tritt bei einer Anforderung ein Fehler auf.

Verwenden von Firewalls

Wenn Sie eine Firewall verwenden, um den Zugriff auf das Internet einzuschränken, müssen Sie die Firewall so konfigurieren, dass der Zugriff möglich ist. Wenn Sie das Log Analytics-Gateway als Proxy verwenden, achten Sie darauf, dass es für Hybrid Runbook Worker konfiguriert ist. Weitere Informationen finden Sie unter Konfigurieren des Log Analytics-Gateways für Automation Hybrid Runbook Worker.

Diensttags

Azure Automation unterstützt Diensttags für virtuelle Azure-Netzwerke, die mit dem Diensttag GuestAndHybridManagement beginnen. Sie können Diensttags verwenden, um Netzwerkzugriffssteuerungen in Netzwerksicherheitsgruppen oder in der Azure Firewall zu definieren. Diensttags können anstelle von spezifischen IP-Adressen verwendet werden, wenn Sie Sicherheitsregeln erstellen. Indem Sie den Diensttagnamen GuestAndHybridManagement im entsprechenden Quell- oder Zielfeld einer Regel angeben, können Sie den Datenverkehr für den Automation-Dienst zulassen oder verweigern. Dieses Diensttag weist keine Unterstützung für das Zulassen einer präziseren Steuerung durch das Einschränken von IP-Adressbereichen auf eine bestimmte Region auf.

Über das Diensttag für den Azure Automation-Dienst werden nur IP-Adressen für die folgenden Szenarien bereitgestellt:

  • Auslösen von Webhooks aus Ihrem virtuellen Netzwerk
  • Zulassen der Kommunikation mit dem Automation-Dienst für Hybrid Runbook Workers oder State Configuration-Agents in Ihrem VNET

Hinweis

Das Diensttag GuestAndHybridManagement verfügt derzeit nicht über Unterstützung für die Ausführung von Runbookaufträgen in einer Azure-Sandbox, sondern nur direkt auf einem Hybrid Runbook Worker.

Unterstützungs für Auswirkungsstufe 5 (Impact Level, IL5)

Azure Automation Hybrid Runbook Worker kann in Azure Government verwendet werden, um Auswirkungsstufe 5-Workloads in einer der zwei folgenden Konfigurationen zu unterstützen:

  • Isolierter virtueller Computer. Bei der Bereitstellung wird der gesamte physische Host für diesen Computer verwendet, wodurch die Isolationsstufe bereitgestellt wird, die für die Unterstützung von IL5-Workloads erforderlich ist.

  • Azure Dedicated Host, der physische Server bereitstellt, die einen oder mehrere virtuelle Computer hosten können und ausschließlich für ein Azure-Abonnement reserviert sind.

Hinweis

Die Computeisolation durch die Hybrid Runbook Worker-Rolle ist für Azure Commercial- und US Government-Clouds verfügbar.

Updateverwaltung-Adressen für Hybrid Runbook Worker

Zusätzlich zu den Standardadressen und -ports, die für Hybrid Runbook Worker erforderlich sind, verfügt Updateverwaltung über weitere Anforderungen an die Netzwerkkonfiguration, die im Abschnitt Netzwerkplanung beschrieben werden.

Azure Automation State Configuration auf einem Hybrid Runbook Worker

Sie können Azure Automation State Configuration auf einem Hybrid Runbook Worker ausführen. Um die Konfiguration von Servern zu verwalten, die den Hybrid Runbook Worker unterstützen, müssen Sie die Server als DSC-Knoten hinzufügen. Weitere Informationen finden Sie unter Aktivieren von Computern zur Verwaltung durch Azure Automation State Configuration.

Runbooks auf einem Hybrid Runbook Worker

Unter Umständen verfügen Sie über Runbooks, die Ressourcen auf dem lokalen Computer verwalten oder für Ressourcen in der lokalen Umgebung ausgeführt werden, in der ein Benutzer-Hybrid Runbook Worker bereitgestellt wurde. In diesem Fall können Sie sich entscheiden, Ihre Runbooks auf dem Hybrid Worker statt in einem Automation-Konto auszuführen. Runbooks, die auf einem Hybrid Runbook Worker ausgeführt werden, sind strukturell identisch mit denen, die Sie im Automation-Konto ausführen. Weitere Informationen finden Sie unter Ausführen von Runbooks auf einem Hybrid Runbook Worker.

Hybrid-Runbook-Worker-Aufträge

Hybrid Runbook Worker-Aufträge werden unter Windows unter dem lokalen Konto System und unter Linux unter dem Konto nxautomation ausgeführt. Azure Automation behandelt Aufträge in Hybrid Runbook Workern anders als Aufträge, die in Azure-Sandboxes ausgeführt werden. Weitere Informationen finden Sie unter Ausführungsumgebung für Runbooks.

Wenn der Hostcomputer des Hybrid Runbook Workers neu gestartet wird, werden alle ausgeführten Runbookaufträge von vorn oder – im Fall von PowerShell-Workflow-Runbooks – beim letzten Prüfpunkt neu gestartet. Nachdem ein Runbookauftrag mehr als dreimal neu gestartet wurde, wird er angehalten.

Runbook-Berechtigungen für einen Hybrid Runbook Worker

Da sie auf Nicht-Azure-Ressourcen zugreifen, können Runbooks, die auf einem Benutzer-Hybrid Runbook Worker laufen, nicht den Authentifizierungsmechanismus verwenden, der normalerweise von Runbooks zur Authentifizierung bei Azure-Ressourcen verwendet wird. Ein Runbook stellt entweder eine eigene Authentifizierung für lokale Ressourcen bereit oder konfiguriert die Authentifizierung mithilfe von verwalteten Identitäten für Azure-Ressourcen. Alternativ hierzu können Sie auch ein ausführendes Konto angeben, um einen Benutzerkontext für alle Runbooks bereitzustellen.

Anzeigen von System-Hybrid Runbook Workern

Nachdem die Updateverwaltungsfunktion auf Windows- oder Linux-Computern aktiviert wurde, können Sie mithilfe der Liste der Hybrid Runbook Worker-Systemgruppe im Azure-Portal einen Bestand erstellen. Sie können im Portal bis zu 2.000 Worker anzeigen, indem Sie im linken Bereich für das ausgewählte Automation-Konto unter Hybrid worker groups (Hybrid Worker-Gruppen) die Registerkarte System hybrid worker groups (Hybrid Worker-Systemgruppen) auswählen.

Seite „System hybrid worker groups“ (Hybrid Worker-Systemgruppen) für ein Automation-Konto

Wenn Sie über mehr als 2.000 Hybrid Worker verfügen und eine vollständige Liste abrufen möchten, können Sie das folgende PowerShell-Skript ausführen:

Get-AzSubscription -SubscriptionName "<subscriptionName>" | Set-AzContext
$workersList = (Get-AzAutomationHybridWorkerGroup -ResourceGroupName "<resourceGroupName>" -AutomationAccountName "<automationAccountName>").Runbookworker
$workersList | export-csv -Path "<Path>\output.csv" -NoClobber -NoTypeInformation

Nächste Schritte