Azure für Google Cloud-Experten

Dieser Artikel hilft Google Cloud-Experten dabei, die Grundlagen von Microsoft Azure Konten, Diensten und Ressourcen zu verstehen. Zudem werden die wichtigsten Gemeinsamkeiten und Unterschiede zwischen der Google Cloud- und der Azure-Plattform erläutert.

Hinweis

Google Cloud wurde zuvor als Google Cloud Platform (GCP) bezeichnet.

In diesem Artikel erfahren Sie:

  • Organisation der Konten und Ressourcen in Azure
  • Struktur der verfügbaren Lösungen in Azure
  • Unterschiede zwischen den wichtigsten Azure- und Google Cloud-Diensten

Azure und Google Cloud haben ihre Funktionen im Laufe der Zeit unabhängig aufgebaut, sodass sie erhebliche Implementierungs- und Designunterschiede aufweisen.

Ähnlichkeiten zwischen Azure und Google Cloud

Wie Google Cloud basiert auch Microsoft Azure auf einer zentralen Gruppe von Compute-, Speicher-, Datenbank- und Netzwerkdiensten. In vielen Fällen bieten beide Plattformen vergleichbare Funktionen und unterstützen hoch verfügbare Lösungen auf Linux- oder Windows-Hosts. Wenn Sie an die Entwicklung mit Linux und Open-Source-Software gewöhnt sind, können beide Plattformen diese Aufgabe erfüllen.

Obwohl die Plattformen ähnliche Funktionen nutzen, sind die Ressourcen, die diese Funktionen bereitstellen, häufig unterschiedlich organisiert. Direkte Dienst-zu-Dienst-Zuordnungen sind nicht immer klar, und einige Dienste sind nur auf einer Plattform verfügbar.

Verwalten von Konten und Abonnements

Azure bietet eine Hierarchie von Verwaltungsgruppen, Abonnements und Ressourcengruppen, die Ihnen dabei helfen, Ressourcen effektiv zu verwalten. Diese Hierarchie ähnelt den Ordnern und der Projektstruktur für Ressourcen in Google Cloud. Das folgende Diagramm zeigt die Hierarchie des Verwaltungsbereichs in Azure:

Diagramm, das eine Struktur mit Verwaltungsgruppen als Stamm, dann Abonnements und dann Ressourcengruppen als Blattknoten zeigt.

Das Baumdiagramm zeigt die vierstufige Azure-Verwaltungshierarchie. Oben befindet sich eine einzige Verwaltungsgruppe mit der Bezeichnung "Unternehmens-IT". Direkt unterhalb der Unternehmens-IT verzweigen sich drei untergeordnete Verwaltungsgruppen horizontal von links nach rechts: Produktion, Entwicklung und Qualitätssicherung (QA). Verbindungslinien geben an, dass Richtlinien und Zugriffssteuerungen, die auf der IT-Ebene des Unternehmens definiert sind, von allen drei geerbt werden. Unter der Produktionsverwaltungsgruppe werden drei Abonnements von links nach rechts angeordnet: unternehmenskritische, geschützte Daten, andere Produktion. Unter der Verwaltungsgruppe für die Entwicklung gibt es ein einziges Abonnement mit der Bezeichnung „Nichtproduktion“. Unterhalb der QA-Verwaltungsgruppe befindet sich ein einzelnes Abonnement mit der Bezeichnung „staging“. Auf der unteren Ebene enthalten Ressourcengruppen Anwendungsressourcen.

  • Verwaltungsgruppen: Diese Gruppen sind Container, mit denen Sie Zugriff, Richtlinien und Konformität für mehrere Abonnements verwalten können. Alle Abonnements in einer Verwaltungsgruppe erben automatisch die auf die Verwaltungsgruppe angewendeten Bedingungen.

  • Abonnements: Ein Abonnement ordnet Benutzerkonten und die Ressourcen, die diese Benutzerkonten erstellen, logisch zu. Jedes Abonnement verfügt über Grenzwerte oder Kontingente für die Anzahl der Ressourcen, die Sie erstellen und verwenden können. Organisationen können Abonnements verwenden, um Kosten und die Ressourcen zu verwalten, die Benutzer, Teams oder Projekte erstellen.

    Sie können eine unbegrenzte Anzahl von Azure Abonnements erstellen. Jedes Abonnement verweist auf einen einzelnen Microsoft Entra Mandanten (ein Konto in Google Cloud-Bedingungen). Ein Mandant kann eine unbegrenzte Anzahl von Abonnements enthalten, während Google Cloud über ein standardmäßiges weiches Limit verfügt, das je Konto variiert und über eine Anforderung erhöht werden kann.

    Ein Google Cloud-Projekt ähnelt im Hinblick auf Abrechnung, Kontingente und Grenzwerte konzeptionell dem Azure-Abonnement. In der Funktion ähnelt ein Google Cloud-Projekt jedoch einer Azure Ressourcengruppe – einem logischen Container, in dem Cloudressourcen bereitgestellt werden.

  • Ressourcengruppen: Eine Ressourcengruppe ist ein logischer Container, in dem Sie Azure Ressourcen wie Web-Apps, Datenbanken und Speicherkonten bereitstellen und verwalten.

  • Ressourcen: Ressourcen sind Instanzen von Diensten, die Sie erstellen, z. B. virtuelle Computer (VMs), Speicher oder SQL-Datenbanken.

Azure bietet verschiedene Einkaufsoptionen für Organisationen unterschiedlicher Größen und Bedürfnisse. Weitere Informationen finden Sie in der Preisübersicht.

Sie verwalten den Zugriff auf Azure Ressourcen über Azure rollenbasierte Zugriffssteuerung (Azure RBAC), die mehr als 100 integrierte Rollen umfasst. Sie können auch eigene benutzerdefinierte Rollen erstellen.

Jedes Abonnement verfügt auch über einen Kontoadministrator, der den Abonnementbesitzer und das Konto darstellt, das für die im Abonnement verwendeten Ressourcen in Rechnung gestellt wird. Sie können den Kontoadministrator nur ändern, indem Sie den Besitz des Abonnements übertragen.

Unter der Abonnementebene können Sie Benutzerrollen und individuelle Berechtigungen bestimmten Ressourcen zuweisen. In Azure sind alle Benutzerkonten entweder mit einem Microsoft-Konto oder einem Organisationskonto (einem mit Microsoft Entra ID verwalteten Konto) verknüpft.

Für Abonnements gelten standardmäßige Dienstkontingente und -einschränkungen. Eine vollständige Liste zu diesen Einschränkungen finden Sie unter Einschränkungen für Azure-Abonnements und Dienste, Kontingente und Einschränkungen. Sie können einige dieser Grenzwerte erhöhen, indem Sie eine Supportanfrage im Verwaltungsportal einreichen.

Weitere Informationen zum Verwalten von Konten und Abonnements finden Sie in den folgenden Ressourcen:

Ressourcenverwaltung

In Azure ist eine Ressource jede Computeinstanz, ein Speicherobjekt, ein Netzwerkgerät oder eine andere Entität, die Sie innerhalb der Plattform erstellen oder konfigurieren können.

Sie können Azure Ressourcen mithilfe von Azure Resource Manager bereitstellen und verwalten.

Ressourcengruppen

Azure stellt auch Ressourcengruppen bereit, die Ressourcen wie VMs, Speicher und virtuelle Netzwerkgeräte organisieren. Sie ordnen immer eine Azure Ressource einer Ressourcengruppe zu. Sie können eine Ressource aus einer Ressourcengruppe in eine andere verschieben, aber sie kann sich nur jeweils in einer Ressourcengruppe befinden. Weitere Informationen finden Sie unter Verschieben von Azure-Ressourcen in eine neue Ressourcengruppe oder ein neues Abonnement. Azure Resource Manager verwendet Ressourcengruppen als grundlegende Gruppierung.

Sie können Ressourcen auch mithilfe von Tags organisieren. Tags sind Schlüsselwertpaare, mit denen Sie Ressourcen unabhängig von der Ressourcengruppenmitgliedschaft in Ihrem Abonnement gruppieren können.

Verwaltungsoberflächen

Azure bietet verschiedene Möglichkeiten zur Verwaltung Ihrer Ressourcen:

  • Azure Portal: Das Azure-Portal bietet eine vollständige webbasierte Verwaltungsschnittstelle für Azure Ressourcen.
  • REST-API: Die Azure Resource Manager REST-API bietet programmgesteuerten Zugriff auf die meisten features, die im Azure-Portal verfügbar sind.
  • Befehlszeile: Die Azure CLI bietet eine Befehlszeilenschnittstelle, die Azure Ressourcen erstellen und verwalten kann. Die Azure CLI ist für Windows, Linux und macOS verfügbar.
  • PowerShell: Sie können die Azure Module für PowerShell verwenden, um automatisierte Verwaltungsaufgaben mithilfe eines Skripts auszuführen. PowerShell ist für Windows, Linux und macOS verfügbar.
  • Vorlagen: Azure Resource Manager Vorlagen bieten vorlagenbasierte Ressourcenverwaltungsfunktionen. Diese Vorlagen werden in der Regel in Bicep oder Terraform geschrieben.
  • Azure SDKs: Die SDKs sind eine Sammlung von Bibliotheken, die Sie zum programmgesteuerten Verwalten und Interagieren mit Azure-Diensten verwenden können.

Über alle diese Schnittstellen hinweg ist die Ressourcengruppe für das Erstellen, Bereitstellen und Verwalten von Azure Ressourcen zentral.

Darüber hinaus stehen viele nicht Microsoft Management-Tools wie HashiCorps Terraform und Spinnaker auf Azure zur Verfügung.

Regionen und Verfügbarkeitszonen

Cloudfehler variieren in Umfang und Schweregrad stark. Lokalisierte Hardwarefehler oder Konfigurationsprobleme können sich auf einzelne Ressourcen oder Ressourcengruppen in einer Workload auswirken. Weniger häufig treten Fehler auf, die zu Störungen für ein gesamtes Rechenzentrum führen, z.B. zu einem Stromausfall im Rechenzentrum. In seltenen Situationen kann eine ganze Region nicht mehr verfügbar sein.

Eines der wichtigsten Verfahren, mit dem für eine Anwendung die Resilienz sichergestellt werden kann, ist die Redundanz. Sie müssen diese Redundanz aber beim Entwerfen der Anwendung einplanen. Außerdem hängt das erforderliche Maß an Redundanz von Ihren Geschäftsanforderungen ab. Nicht jede Anwendung erfordert regionsübergreifende Redundanz zum Schutz vor regionalen Ausfällen. In der Regel muss ein Kompromiss zwischen höherer Redundanz und Zuverlässigkeit und einer höheren Kostensumme und Komplexität gefunden werden.

In Google Cloud verfügt eine Region über zwei oder mehr Verfügbarkeitszonen. Eine Verfügbarkeitszone entspricht einem physisch isolierten Rechenzentrum in der geografischen Region. Azure verfügt über zahlreiche Features für die Bereitstellung von Anwendungsredundanz auf jeder Ebene potenzieller Fehler, einschließlich verfügbarkeitszonen und paired Regions.

Die einzelnen Optionen sind in der folgenden Tabelle zusammengefasst:

Aspect Verfügbarkeitszone Regionspaar
Fehlerumfang Rechenzentrum Region
Routinganforderung zonenübergreifender Azure Load Balancer Azure Traffic Manager
Netzwerklatenz Niedrig Mittel bis hoch
Virtuelle Netzwerke Virtuelles Netzwerk Regionsübergreifendes Peering virtueller Netzwerke

Verfügbarkeitszonen

Wie Google Cloud können Azure Regionen Verfügbarkeitszonen aufweisen, die physisch getrennte Zonen innerhalb einer Azure Region sind. Jede Verfügbarkeitszone verfügt über eine unterschiedliche Stromversorgung, ein Netzwerk und eine Kühlung. Das Bereitstellen von virtuellen Computern über Verfügbarkeitszonen hinweg trägt zum Schutz einer Anwendung vor rechenzentrumsweiten Fehlern bei.

Diagramm, das eine zonenredundante Bereitstellung virtueller Computer in drei Verfügbarkeitszonen innerhalb einer einzelnen Azure Region zeigt.

Diagramm, das eine zonenredundante Bereitstellung virtueller Computer innerhalb einer einzelnen Azure Region zeigt. Ein großer äußerer Rechtecksbereich mit Beschriftung enthält das gesamte Layout. Innerhalb des Bereichs werden drei horizontale rechteckige Zonen vertikal von oben nach unten gestapelt, mit der Bezeichnung "Zone 1", "Zone 2" und "Zone 3" gekennzeichnet. Jede Zone enthält einen virtuellen Computer. Ein vertikales gestricheltes Rechteck überlagert die virtuellen Computer in allen drei Zonen. Dieses gestrichelte Rechteck stellt ein einzelnes Subnetz dar, das alle drei Verfügbarkeitszonen gleichzeitig umfasst. Die Bezeichnung „subnet“ erscheint an der unteren Kante des gestrichelten Rechtecks. Das Layout veranschaulicht, dass die Bereitstellung virtueller Computer in jeder Zone, die über ein freigegebenes Subnetz verbunden ist, Redundanz im Falle eines Ausfalls in einer Zone bietet.

Weitere Informationen zu Verfügbarkeitszonen und Regionen finden Sie unter Verwenden von Verfügbarkeitszonen und Regionen.

Gepaarte Regionen

Um eine Anwendung vor einem regionalen Ausfall zu schützen, stellen Sie die Anwendung in mehreren Regionen bereit und verwenden Azure Traffic Manager, um Internetdatenverkehr an verschiedene Regionen zu verteilen. Jede Azure-Region ist mit einer anderen Region gepaart. Zusammen bilden diese Bereiche ein Bereichspaar. Mit Ausnahme von Brasilien Süd befinden sich Regionspaare innerhalb derselben Geografie, um die Anforderungen an die Datenhaltung für Steuer- und Strafverfolgungszwecke zu erfüllen.

Im Gegensatz zu Verfügbarkeitszonen, die physisch getrennte Rechenzentren sind, sich aber in relativ nahe gelegenen geografischen Gebieten befinden, werden gekoppelte Regionen in der Regel durch mindestens 300 Meilen voneinander getrennt. Durch dieses Design wird sichergestellt, dass sich größere Katastrophen nur auf eine der Regionen eines Paars auswirken. Sie können benachbarte Paare festlegen, um Datenbank- und Speicherdienstdaten zu synchronisieren. Sie sind so konfiguriert, dass Plattformupdates jeweils nur für eine Region im Paar bereitgestellt werden.

Azure geo-redundanter Speicher sichert Daten automatisch in der entsprechenden gepaarten Region. Für alle anderen Ressourcen müssen Sie eine vollständige Kopie Ihrer Lösung in jeder Region bereitstellen, um vollständige Redundanz zu erzielen.

Diagramm, das die geschachtelte Eindämmungsbeziehung zwischen einer Geografie, einem Regionspaar, zwei Regionen und ihren Rechenzentren zeigt.

Diagramm, das die Hierarchie der Verschachtelung von Azure-Regionspaaren zeigt. Das äußerste Rechteck stellt eine Geografie dar. Innerhalb der Geografie ist ein Regionenpaar verschachtelt. Innerhalb des Bereichspaars befinden sich zwei Regionen nebeneinander. Innerhalb jeder Region handelt es sich um ein Rechenzentrum. Die Schachtelung der Shapes veranschaulicht die Eindämmungsbeziehungen: Rechenzentren befinden sich physisch innerhalb von Regionen, zwei Regionen bilden zusammen ein Bereichspaar, und ein Regionspaar gehört zu einer einzelnen Geografie.

Zuverlässigkeitsleitfäden nach Dienst

Informationen zu Zuverlässigkeitsempfehlungen für jeden Azure Dienst finden Sie in den Zuverlässigkeitsleitfäden nach Dienst.

Weitere Informationen hierzu finden Sie in den folgenden Ressourcen:

Dienste

Informationen dazu, wie Google-Cloud-Dienste ihren Azure-Entsprechungen zugeordnet sind, finden Sie unter Vergleich von Google-Cloud- und Azure-Diensten.

Es sind nicht alle Azure-Produkte und -Dienste in allen Regionen verfügbar. Weitere Informationen finden Sie unter "Produkte nach Region". Sie finden die Verfügbarkeitsgarantien und Ausfallkreditrichtlinien für jedes Azure Produkt oder jede Dienstleistung in den Vereinbarungen auf Serviceebene für Onlinedienste Dokument.

Nächster Schritt