Freigeben über

Was ist Azure Resource Manager?

  • Artikel

Azure Resource Manager ist der Bereitstellungs- und Verwaltungsdienst für Azure. Er bietet eine Verwaltungsebene, die Sie beim Erstellen, Aktualisieren und Löschen von Ressourcen in Ihrem Azure-Konto unterstützt. Sie verwenden Verwaltungsfeatures wie Zugriffssteuerung, Sperren und Tags, um Ihre Ressourcen nach der Bereitstellung zu schützen und zu organisieren.

Das folgende Video behandelt grundlegende Resource Manager-Konzepte:

Einheitliche Verwaltungsebene

Wenn Sie eine Anforderung über eine der APIs, über eines der Azure-Tools oder über eines der SDKs sendet, wird diese von Resource Manager empfangen. Sie authentifiziert und autorisiert die Anforderung, bevor sie an den entsprechenden Azure-Dienst weitergeleitet wird. Da alle Anforderungen von der gleichen API verarbeitet werden, stehen in allen Tools konsistente Ergebnisse und Funktionen zur Verfügung.

Die folgende Abbildung veranschaulicht die Rolle von Resource Manager bei Azure-Anforderungen:

Diagramm: Rolle von Resource Manager bei Azure-Anforderungen

Alle Funktionen, die im Azure-Portal verfügbar sind, sind auch über PowerShell, die Azure CLI, REST-APIs und Client-SDKs verfügbar. Wenn APIs neue Funktionen einführen, spiegelt sich dies innerhalb von 180 Tagen nach der ersten Veröffentlichung im Portal wider.

Wichtig

Die Unterstützung von Protokollen, die älter als TLS 1.2 sind, durch Resource Manager wird am 1. März 2025 eingestellt. Weitere Informationen finden Sie unter Migrieren zu TLS 1.2 für Azure Resource Manager.

Terminologie

Wenn Sie mit Resource Manager noch nicht vertraut sind, kennen Sie unter Umständen die folgenden Begriffe noch nicht:

  • Ressource: Ein verwaltbares Element, das in Azure verfügbar ist. VMs, Speicherkonten, Web-Apps, Datenbanken und virtuelle Netzwerke sind Beispiele für Ressourcen. Ressourcengruppen, Abonnements, Verwaltungsgruppen und Tags sind ebenfalls Ressourcen.

  • Ressourcengruppe : Ein Container, der verwandte Ressourcen für eine Azure-Lösung enthält. Die Ressourcengruppe enthält die Ressourcen, die Sie als Gruppe verwalten möchten. Sie entscheiden in Abhängigkeit davon, was für Ihre Organisation am sinnvollsten ist, welche Ressourcen in eine Ressourcengruppen gehören. Weitere Informationen finden Sie unter Was ist eine Ressourcengruppe?.

  • Ressourcenanbieter: Ein Dienst, der Azure-Ressourcen bereitstellt. Ein gängiger Ressourcenanbieter, von dem die VM-Ressource bereitgestellt wird, ist beispielsweise Microsoft.Compute. Microsoft.Storage ist ein weiterer gängiger Ressourcenanbieter. Weitere Informationen finden Sie unter Azure-Ressourcenanbieter und -typen.

  • Deklarative Syntax: Bei dieser Syntax können Sie beispielsweise „Here is what I intend to create“ (Dies möchte ich erstellen.) eingeben, ohne dafür die Abfolge der Programmierbefehle für die Erstellung schreiben zu müssen. ARM-Vorlagen und Bicep-Dateien sind Beispiele für deklarative Syntax. In diesen Dateien definieren Sie die Eigenschaften für die Infrastruktur zum Bereitstellen für Azure.

  • ARM-Vorlage: Eine JSON-Datei (JavaScript Object Notation), mit der eine oder mehrere Ressourcen zum Bereitstellen einer Ressourcengruppe, eines Abonnements, einer Verwaltungsgruppe oder eines Mandanten definiert werden. Sie können die Vorlage zum konsistenten und wiederholten Bereitstellen der Ressourcen verwenden. Eine Übersicht über das Bereitstellen von Vorlagen finden Sie unter Was sind ARM-Vorlagen?.

  • Bicep-Datei: Eine Datei für die deklarative Bereitstellung von Azure-Ressourcen. Bicep ist eine Sprache, die entwickelt wurde, um die beste Benutzeroberfläche für die Erstellung für Infrastructure-as-Code-Lösungen in Azure zu bieten. Weitere Informationen zu Bicep finden Sie unter Was ist Bicep?.

  • Erweiterungsressource: Eine Ressource, die einer anderen Ressource Funktionen hinzufügt. Eine Rollenzuweisung ist beispielsweise eine Erweiterungsressource. Sie wenden eine Rollenzuweisung auf eine beliebige andere Ressource an, um den Zugriff anzugeben. Siehe Erweiterungsressourcen.

Weitere Azure-Terminologiedefinitionen finden Sie unter Grundlegende Konzepte in Azure.

Vorteile der Verwendung des Ressourcen-Managers

Resource Manager ermöglicht Folgendes:

  • Verwalten Ihrer Infrastruktur über deklarative Vorlagen (anstelle von Skripts)

  • Bereitstellen, Verwalten und Überwachen aller Ressourcen für Ihre Lösung als Gruppe, anstatt diese Ressourcen einzeln zu behandeln

  • Wiederholtes Bereitstellen Ihrer Lösung während des gesamten Entwicklungslebenszyklus mit der Gewissheit, dass Ihre Ressourcen konsistent bereitgestellt werden

  • Definieren der Abhängigkeiten zwischen Ressourcen, sodass diese in der korrekten Reihenfolge bereitgestellt werden

  • Anwenden der Zugriffssteuerung auf alle Dienste, da die rollenbasierte Zugriffssteuerung von Azure (Azure Role-Based Access Control, Azure RBAC) nativ in die Verwaltungsplattform integriert ist

  • Anwenden von Tags auf Ressourcen, um alle Ressourcen in Ihrem Abonnement logisch zu organisieren

  • Sie können genauere Informationen zur Abrechnung Ihrer Organisation erhalten, indem Sie die Kosten für eine Gruppe von Ressourcen anzeigen, die über dasselbe Tag verfügen.

Der Bereich

Azure bietet vier Verwaltungsebenen: Verwaltungsgruppen, Abonnements, Ressourcengruppen und Ressourcen. Das folgende Diagramm visualisiert diese Ebenen:

Diagramm, das die vier Bereichsebenen in Azure zeigt: Verwaltungsgruppen, Abonnements, Ressourcengruppen und Ressourcen.

Sie wenden die Verwaltungseinstellungen auf einer dieser Bereichsebenen an. Die von Ihnen ausgewählte Ebene bestimmt, wie umfassend die Einstellung angewendet wird. Niedrigere Ebenen erben die Einstellungen von höheren Ebenen. Wenn Sie also beispielsweise eine Richtlinie auf das Abonnement anwenden, gilt diese für alle Ressourcengruppen und Ressourcen in Ihrem Abonnement. Wenn Sie eine Richtlinie auf die Ressourcengruppe anwenden, gilt diese für die Ressourcengruppe und alle dazugehörigen Ressourcen. Andere Ressourcengruppen sind von der Richtlinienzuweisung dagegen nicht betroffen.

Informationen zum Verwalten von Identitäten und Zugriff in Azure finden Sie unter Was ist Microsoft Entra ID?.

Sie können Vorlagen für Mandanten, Verwaltungsgruppen, Abonnements oder Ressourcengruppen bereitstellen.

Was ist eine Ressourcengruppe?

Eine Ressourcengruppe ist ein Container zum Verwalten verwandter Ressourcen für eine Azure-Lösung. Mithilfe einer Ressourcengruppe können Sie Änderungen zwischen Ressourcen koordinieren, die miteinander in Beziehung stehen. Sie können beispielsweise ein Update für die Ressourcengruppe bereitstellen und darauf vertrauen, dass die Ressourcen in einem koordinierten Vorgang aktualisiert werden. Wenn Sie mit der Lösung fertig sind, können Sie auch die Ressourcengruppe löschen und sicher sein, dass alle Ressourcen gelöscht wurden.

Beim Definieren der Ressourcengruppe sind einige wichtige Faktoren zu beachten:

  • Alle Ressourcen einer Ressourcengruppe sollten über den gleichen Lebenszyklus verfügen. Sie werden von Ihnen zusammen bereitgestellt, aktualisiert und gelöscht. Beispielsweise ist ein Server eine Ressource. Falls er in einem anderen Entwicklungszyklus vorhanden sein muss, sollte er in einer anderen Ressourcengruppe enthalten sein.

  • Jede Ressource kann nur in einer Ressourcengruppe vorhanden sein.

  • Sie können eine Ressource einer Ressourcengruppe jederzeit hinzufügen bzw. die Ressource daraus entfernen.

  • Sie können eine Ressource aus einer Ressourcengruppe in eine andere Gruppe verschieben. Weitere Informationen finden Sie unter Verschieben von Azure-Ressourcen in eine neue Ressourcengruppe oder ein neues Abonnement.

  • Die Ressourcen in einer Ressourcengruppe können sich in verschiedenen Regionen als der Ressourcengruppe befinden, es wird jedoch empfohlen, denselben Speicherort zu verwenden. Weitere Informationen finden Sie unter Welchen Standort soll ich für meine Ressourcengruppe verwenden?.

  • Eine Ressourcengruppe kann zum Festlegen der Zugriffssteuerung für administrative Aktionen verwendet werden. Zum Verwalten einer Ressourcengruppe können Sie Azure-Richtlinien, Rollen oder Ressourcensperren verwenden.

  • Sie können auf eine Ressourcengruppe Tags anwenden. Die Ressourcen in der Ressourcengruppe erben diese Tags nicht.

  • Eine Ressource kann eine Verbindung mit Ressourcen in anderen Ressourcengruppen herstellen. Dieses Szenario kommt häufig vor, wenn die beiden Ressourcen zusammengehören, aber nicht denselben Lebenszyklus aufweisen. Beispielsweise können Sie über eine Web-App verfügen, die eine Verbindung mit einer Datenbank in einer anderen Ressourcengruppe herstellt.

  • Wenn Sie eine Ressourcengruppe löschen, werden alle Ressourcen darin ebenfalls gelöscht. Weitere Informationen dazu, wie Resource Manager diese Löschungen orchestriert, finden Sie unter Löschen von Ressourcengruppen und Ressourcen mit Azure Resource Manager.

  • Sie können bis zu 800 Instanzen eines Ressourcentyps in jeder Ressourcengruppe bereitstellen. Einige Ressourcentypen sind von der Beschränkung auf 800 Instanzen ausgenommen. Weitere Informationen finden Sie unter Grenzwerte für Ressourcengruppen.

  • Einige Ressourcen können außerhalb einer Ressourcengruppe vorhanden sein. Diese Ressourcen werden im Abonnement, in der Verwaltungsgruppe oder im Mandanten bereitgestellt. In diesen Bereichen werden nur bestimmte Ressourcentypen unterstützt.

  • Zum Erstellen einer Ressourcengruppe können Sie das Azure-Portal, PowerShell, die Azure-Befehlszeilenschnittstelle oder eine ARM-Vorlage verwenden.

Welchen Standort soll ich für meine Ressourcengruppe verwenden?

Beim Erstellen einer Ressourcengruppe müssen Sie einen Standort für diese Ressourcengruppe angeben.

Möglicherweise fragen Sie sich, warum eine Ressourcengruppe einen Standort benötigt und warum der Standort der Ressourcengruppe wichtig ist, wenn für Ressourcen Standorte außerhalb einer Ressourcengruppe festgelegt werden können.

In der Ressourcengruppe werden Metadaten zu Ressourcen gespeichert. Wenn Sie einen Standort für die Ressourcengruppe angeben, legen Sie auch fest, wo die Metadaten gespeichert werden. Aus Compliancegründen müssen Sie unter Umständen sicherstellen, dass Ihre Daten in einer bestimmten Region gespeichert werden.

Das Routing von Steuerungsebenenvorgänge über den Standort der Ressourcengruppe kann zur Aufrechterhaltung eines konsistenten Zustands der Ressourcengruppe beitragen. Bei der Auswahl eines Ressourcengruppenstandorts empfiehlt es sich, einen Standort in der Nähe des Ursprungs Ihrer Steuerungsvorgänge auszuwählen. In der Regel ist dieser Standort der am nächsten gelegene. Diese Routinganforderung gilt nur für Vorgänge auf Steuerungsebene für die Ressourcengruppe. Sie sich nicht auf Anforderungen aus, die an Ihre Anwendungen gesendet werden.

Ist die Region einer Ressourcengruppe vorübergehend nicht verfügbar, können Sie unter Umständen keine Ressourcen in der Ressourcengruppe aktualisieren, da die Metadaten nicht verfügbar sind. Die Ressourcen in anderen Regionen funktionieren weiterhin wie erwartet, doch können Sie diese unter Umständen nicht aktualisieren. Diese Bedingung gilt möglicherweise auch für globale Ressourcen wie Azure DNS, private Azure DNS-Zonen, Azure Traffic Manager und Azure Front Door. Sehen Sie sich die Liste unter Referenz zu Azure Resource Graph-Tabellen und Ressourcentypen an, um die Ressourcen und Metadaten anzuzeigen, die Resource Manager verwaltet.

Wenn die Region der Ressourcengruppe nicht verfügbar ist, kann Resource Manager die Metadaten Ihrer Ressource nicht aktualisieren und blockiert Ihre Schreibaufrufe. Um die Auswirkungen regionaler Ausfälle zu verringern, empfiehlt es sich, Ressourcen und Ressourcengruppen in derselben Region zu platzieren. Dadurch wird die Wahrscheinlichkeit reduziert, dass eine Region nicht verfügbar ist, da Ihre Ressourcen und Metadaten in einer Region und nicht in mehreren Regionen vorhanden sind.

Weitere Informationen zum Erstellen zuverlässiger Anwendungen finden Sie unter Checkliste für Resilienz für bestimmte Azure-Dienste.

Resilienz von Resource Manager

Resource Manager ist auf Resilienz und fortlaufende Verfügbarkeit ausgelegt. Resource Manager-Vorgänge und Vorgänge auf Steuerungsebene (an management.azure.com gesendete Anforderungen) in der REST-API haben folgende Eigenschaften:

  • Sie sind regionsübergreifend verteilt. Resource Manager verfügt in jeder Azure-Region über eine separate Instanz. Das bedeutet, dass ein Ausfall einer Resource Manager-Instanz in einer Region die Verfügbarkeit des Diensts in einer anderen Region nicht beeinträchtigt. Dies gilt auch für andere Azure-Dienste. Obwohl Resource Manager regionsübergreifend verteilt wird, sind einige Dienste regional. Diese Unterscheidung bedeutet, dass die anfängliche Behandlung des Vorgangs auf Steuerungsebene zwar resilient ist, die Anforderung aber für regionale Ausfälle anfällig sein kann, wenn sie an den Dienst weitergeleitet wird.

  • Sie sind an Standorten mit mehreren Verfügbarkeitszonen über diese Verfügbarkeitszonen (und Regionen) verteilt. Diese Verteilung stellt sicher, dass Resource Manager entweder ein Failover auf eine andere Zone oder Region ausführen kann, wenn in einer Region eine oder mehrere Zonen ausfallen. So werden weiterhin Funktionen auf Steuerungsebene für die Ressourcen bereitgestellt.

  • Sie sind nicht von einem logischen Rechenzentrum abhängig.

  • Sie werden nicht für Wartungsaktivitäten außer Betrieb genommen.

Diese Resilienz gilt für Dienste, die Anforderungen über Resource Manager empfangen. Azure Key Vault ist ein Dienst, der von dieser Konsistenz profitiert.

Auflösen von parallelen Vorgängen

Gleichzeitige Ressourcenaktualisierungen können zu unerwarteten Ergebnissen führen. Wenn mehrere Vorgänge gleichzeitig versuchen, dieselbe Ressource zu aktualisieren, erkennt Resource Manager den Konflikt, lässt nur für einen Vorgang den erfolgreichen Abschluss zu, blockiert die anderen Vorgänge und gibt einen Fehler zurück. Diese Lösung stellt sicher, dass Ihre Updates schlüssig und zuverlässig sind. Sie kennen den Status Ihrer Ressourcen und vermeiden Inkonsistenzen oder Datenverluste.

Wenn Sie beispielsweise zwei Anforderungen (A und B) haben, die versuchen, dieselbe Ressource zur gleichen Zeit zu aktualisieren und Anforderung A vor Anforderung B abgeschlossen wird, ist Anforderung A erfolgreich, und bei Anforderung B tritt ein Fehler auf. Anforderung B gibt den Fehler 409 zurück. Nach dem Erhalt dieses Fehlercodes können Sie den aktualisierten Status der Ressource abrufen und ermitteln, ob Sie Anforderung B erneut senden möchten.

Nächste Schritte