Google Cloud für Azure-Experten: Speicherung

Aktualisiert: 24. April 2019

In diesem Artikel finden Sie einen Vergleich zwischen den Speicherdiensten von Microsoft Azure und Google Cloud. Dabei werden folgende Diensttypen behandelt:

  • Verteilter Objektspeicher oder redundanter Speicher für Schlüssel/Wert-Paare zur Speicherung von Datenobjekten
  • Blockspeicher oder virtuelle Laufwerks-Volumes, die VM-Instanzen angehängt werden können
  • Dateispeicher oder dateiserverbasierter netzgebundener Speicher
  • Storage Area Networks oder Remotespeicher mit Speicherzugriff auf Blockebene
  • Kalter Datenspeicher oder Speicherdienste für Datensicherungen
  • Archivspeicher oder Speicherdienste zum Sichern von Archivdaten für Compliance- oder Analysezwecke

Datenbanken oder Nachrichtenwarteschlangen werden in diesem Artikel nicht behandelt.

Dienstmodelle im Vergleich

Microsoft Azure und Google Cloud verfolgen unterschiedliche Ansätze bei der allgemeinen Organisation und Konfiguration ihrer Speicherdienste. In der Praxis sind die Gemeinsamkeiten der Speicherdienste selbst jedoch oft größer als die Unterschiede.

Microsoft Azure

In Azure speichern Sie verschiedene Datentypen wie binäre Objekte (Blobs), Datenbanken und Nachrichtenwarteschlangen in spezifischen Diensten innerhalb eines Speicherkontos. Dabei müssen Sie den Kontotyp, Laufwerkstyp und Redundanztyp auf Speicherkontoebene definieren. Diese Attribute gelten dann für alle Speicherdienste in diesem Konto.

Es gibt drei Arten von Azure-Speicherkonten: allgemeine Konten der Version 1, Blob-spezifische Konten und allgemeine Konten der Version 2. Allgemeine Konten der Version 1 unterstützen alle standardmäßigen Speichertypen von Azure, während Blob-spezifische Konten auf die erweiterten Funktionen von Azure Blob Storage ausgelegt sind. Allgemeine Konten der Version 2 unterstützen die APIs und Funktionen der beiden anderen Kontotypen.

Blob-spezifische Konten werden ausschließlich auf Festplattenlaufwerken (HDDs) ausgeführt, während sich die beiden allgemeinen Kontotypen weiter unterteilen lassen und zwar in Standard-Speicherkonten, die auf HDDs ausgeführt werden, und Premium-Speicherkonten, die auf Solid-State-Laufwerken (SSDs) ausgeführt werden. Der letztere Kontotyp unterstützt derzeit nur Seiten-Blobs.

Wenn Sie ein neues Azure-Speicherkonto erstellen, wählen Sie auch die gewünschte Replikationsstufe aus. Azure bietet folgende Möglichkeiten:

  • Lokal redundanter Speicher (LRS), bei dem Ihre Daten lokal im Rechenzentrum repliziert werden, in dem sich Ihr Speicherkonto befindet. Die Daten werden dreimal repliziert.
  • Zonenredundanter Speicher (ZRS), bei dem Ihre Daten in ein oder zwei Regionen mit Eventual Consistency repliziert werden. Außerdem werden die Daten wie bei LRS dreimal lokal repliziert. ZRS ist in allgemeinen Speicherkonten auf Block-Blob-Speicher beschränkt.
  • Georedundanter Speicher (GRS), bei dem Ihre Daten in einer primären und einer sekundären Region, die mindestens 160 Kilometer entfernt ist, repliziert werden. Die Daten werden dreimal in der primären Region und dann asynchron dreimal in der sekundären Region repliziert.
  • Georedundanter Speicher mit Lesezugriff (RA-GRS), der mit GRS identisch ist, aber zusätzlich einen sekundären schreibgeschützten Endpunkt in der sekundären Region bietet.

Google Cloud

Wie Azure speichert auch Google Cloud jeden Datentyp in einem typspezifischen Dienst. In Google Cloud gibt es jedoch keine höhere Organisationsebene wie ein Speicherkonto. Stattdessen erstellen Sie Speicherressourcen und definieren Ressourcenattribute wie den Laufwerkstyp oder Redundanztyp auf Dienstebene.

Für verteilten Objektspeicher bietet Google Cloud den Cloud Storage-Dienst, der mit dem Block- und Anfüge-Blob-Speicher von Azure Blob Storage vergleichbar ist. Für Blockspeicher bietet Google Cloud nichtflüchtigen Compute Engine-Speicher, der Azure-VHDs entspricht.

Verteilter Objektspeicher

Für verteilten Objektspeicher stehen Ihnen Azure Blob Storage von Azure und Cloud Storage in Google Cloud zur Verfügung.

Azure Blob Storage und Cloud Storage haben viele Gemeinsamkeiten. In beiden Diensten speichern Sie binäre Objekte in einer benannten Speichereinheit. In Azure Blob Storage werden diese binären Objekte Blobs genannt und die Speichereinheit heißt Container. In Cloud Storage werden diese binären Objekte als Objekte und die Speichereinheit als Bucket bezeichnet.

In beiden Diensten wird jedes binäre Objekt innerhalb einer Speichereinheit durch einen eindeutigen Schlüssel innerhalb dieser Speichereinheit identifiziert und jedem Objekt ist ein Metadatenprotokoll zugeordnet. Dieses Metadatenprotokoll enthält Informationen wie die Objektgröße, das Datum der letzten Änderung und den Medientyp. Wenn Sie die entsprechenden Berechtigungen haben, können Sie einige dieser Metadaten anzeigen und ändern. Bei Bedarf können Sie auch benutzerdefinierte Metadaten hinzufügen.

Obwohl sowohl Container als auch Buckets Speicher für Schlüssel/Wert-Paare sind, lassen sich beide fast wie Dateisysteme nutzen. Objektschlüssel sind normalerweise Pfade wie "/foo/bar.txt" oder "/foo/subdir/baz.txt". Sowohl Azure als auch Cloud Storage bieten außerdem APIs, die Dateisystemen gleichen. Beispielsweise können Sie mit der Methode List Blobs in Azure Blob Storage bzw. mit list in Cloud Storage alle Objektschlüssel mit einem gemeinsamen Präfix auflisten, wie dies mit ls -R in einem Unix-artigen Dateisystem funktionieren würde.

Neben der offensichtlichsten Verwendung, dem verteilten Objektspeicher, können beide Dienste zum Hosten von statischen Webinhalten und Medien genutzt werden.

Die folgende Tabelle enthält eine Übersicht über die Funktionen und Begriffe von Azure Blob Storage und Cloud Storage:

Funktion Azure Blob Storage Cloud Storage
Bereitstellungseinheit Container Bucket
Bereitstellungskennung Eindeutiger Schlüssel auf Kontoebene Eindeutiger globaler Schlüssel
Nachbildung des Dateisystems Begrenzt Begrenzt
Objekttypen Block-Blobs, Anfüge-Blobs und Page-Blobs Objekte
Objektmetadaten Ja Ja
Objektversionierung Manuelles Erstellen objektspezifischer Snapshots Automatische Versionierung aller Objekte in einem Bucket (muss aktiviert sein)
Verwaltung des Objektlebenszyklus Ja (über Lebenszyklusregeln oder Azure-Automatisierung) Ja (nativ)
Benachrichtigungen über Objektänderungen Ja (über Azure Event Grid) Ja (über Pub/Sub)
Dienstklassen Redundanzstufen: LRS, ZRS, GRS, RA-GRS
Ebenen: Heiß, Kalt, Archiv
Standard, Nearline, Coldline, Archive
Ortsbezogenheit Zonal und regional Regional und Multiregional
Redundanz Ja Ja

Blob-Typen

In Azure Blob Storage werden Daten als Block-Blobs, Anfüge-Blobs oder Seiten-Blobs gespeichert. In Cloud Storage werden alle Daten als Objekte gespeichert, die Block-Blobs entsprechen. Google Cloud bietet keinen Dienst oder Objekttyp, der mit Anfüge-Blobs direkt vergleichbar ist. Mit der Funktion zum Zusammensetzen von Objekten und der Gleichzeitigkeitserkennung von Cloud Storage stehen Ihnen jedoch ähnliche Möglichkeiten wie bei Anfüge-Blobs zur Verfügung. Weitere Informationen finden Sie unter Zusammengesetzte Objekte und parallele Uploads.

Im Gegensatz zu Azure speichert Google Cloud Ihre Laufwerks-Volumes nicht als Seiten-Blobs im Objektspeicherdienst. Sie werden stattdessen in Compute Engine, dem Infrastructure-as-a-Service-Angebot von Google Cloud, gespeichert. Weitere Informationen finden Sie unter Blockspeicher.

Zugriffsebenen und Replikation

Wie flexibel Azure Blob Storage ist, hängt vom Typ des von Ihnen erstellten Speicherkontos und den Replikationsoptionen ab, die Sie für dieses Konto gewählt haben. Wenn Sie ein allgemeines Speicherkonto der Version 1 nutzen, steht Ihnen nur die Standardebene von Azure für Blob-Speicher zur Verfügung. Wenn Sie jedoch ein Blob-spezifisches oder allgemeines Speicherkonto der Version 2 verwenden, können Sie zwischen den Zugriffsebenen "Heiß", "Kalt" und "Archiv" für Azure Blob Storage wählen. Die Ebene "Heiß" ist für häufig aufgerufene Daten und die Ebene "Kalt" für selten aufgerufene Daten bestimmt. Die Ebene "Archiv" dient der Datenarchivierung. Die Replikationsstufe für Ihren Azure Blob Storage-Dienst richtet sich nach dem Replikationstyp des Speicherkontos.

Im Gegensatz dazu sind die Replikationstypen von Cloud Storage in die Dienstklassen integriert. Die folgende Tabelle enthält eine Übersicht über die Dienstklassen von Cloud Storage bzw. die Zugriffsebenen und Replikationstypen von Azure Blob Storage:

Konfiguration Azure Google Cloud
Häufig aufgerufene Daten mit Georedundanz Azure Blob Storage (allgemein oder Ebene "Heiß") mit GRS oder RA-GRS Standard Storage an einem Standort mit zwei oder mehr Regionen
Häufig aufgerufene Daten mit regionaler Redundanz Azure Blob Storage (allgemein) mit ZRS Standard Storage an einem Standort mit einer Region
Häufig aufgerufene Daten mit lokaler Redundanz (Rechenzentrum) Azure Blob Storage (allgemein oder Ebene "Heiß") mit LRS Standard Storage an einem Standort mit einer Region*
Selten aufgerufene Daten Azure Blob Storage (Ebene "Kalt") Cloud Storage Nearline und Cloud Storage Coldline
Archivdaten Azure Blob Storage (Ebene "Archiv") Cloud Storage Archive

* Regionale Redundanz ist die niedrigste Redundanzstufe, die in Google Cloud verfügbar ist.

Objektversionierung

Sie können sowohl mit Azure als auch Cloud Storage Ihre gespeicherten Objekte versionieren und verschiedene Versionen eines Objekts mit einem bestimmten Schlüssel unter verschiedenen Versions-IDs speichern. Diese Funktion wird jedoch unterschiedlich implementiert.

In Azure Blob Storage erfolgt die Versionierung, indem Sie schreibgeschützte Snapshots Ihrer Blobs erstellen. Wenn Sie Ihre Dateien programmatisch hochladen, können Sie vor jedem Upload einen neuen Snapshot erstellen. Mit Azure Blob Storage können Sie auch Zugriffsbedingungen festlegen, um unnötige Snapshot-Vorgänge zu vermeiden.

Im Gegensatz dazu können Sie in Cloud Storage die automatische Versionierung für alle Objekte in einem Bucket aktivieren. Wenn sie aktiviert ist, erstellt Cloud Storage bei jeder Änderung eines Objekts automatisch eine neue Version davon. Dieser Ansatz vereinfacht die Objektversionierung, ist jedoch etwas weniger flexibel als bei Azure. Jede Version eines Objekts vergrößert außerdem die Menge der gespeicherten Daten, was die Speicherkosten erhöhen kann. Dieses Problem können Sie mithilfe der Verwaltung des Objektlebenszyklus in Cloud Storage lösen.

Gleichzeitigkeitserkennung

Azure Blob Storage und Cloud Storage setzen standardmäßig eine Schreibstrategie ein, bei der der letzte Schreibvorgang vorrangig ist. Diese Strategie eignet sich gut für sequenzielle Schreibvorgänge, verursacht jedoch Race-Bedingungen, wenn Sie gleichzeitige Schreibvorgänge für dasselbe Objekt ausführen. Zur Behebung dieses Problems bieten beide Dienste Mechanismen zur Durchführung gleichzeitiger Schreibvorgänge.

In Azure können Sie gleichzeitige Schreibvorgänge optimistisch oder pessimistisch verwalten:

  • Optimistischer Ansatz: Sie rufen beim Ausführen eines GET-Vorgangs den ETag-Header eines Objekts ab und vergleichen ihn vor einem Schreibvorgang mit dem aktuellen ETag des Objekts. Wenn die Tags übereinstimmen, führen Sie den Schreibvorgang durch.
  • Pessimistischer Ansatz: Sie rufen das Zielobjekt ab und sperren es für eine bestimmte Zeit, während Sie den Schreibvorgang ausführen.

In Cloud Storage wird der optimistische Ansatz verwendet. Zur Verwaltung gleichzeitiger Schreibvorgänge rufen Sie die aktuelle Generierungsnummer eines bestimmten Objekts ab und prüfen sie vor einem Schreibvorgang durch Ihr Skript oder Ihre Anwendung. Wenn die Zahlen übereinstimmen, führen Sie den Schreibvorgang durch. Andernfalls brechen Sie die Transaktion ab und starten sie neu. Weitere Informationen finden Sie unter Objektversionierung und Gleichzeitigkeitserkennung.

Verwaltung des Objektlebenszyklus

Die Verwaltung des Azure Blob Storage-Lebenszyklus bietet regelbasierte Richtlinien für GPv2- und Blob-Speicherkonten. Sie können diese Richtlinien verwenden, um Ihre Daten an die entsprechenden Zugriffsebenen zu übertragen oder am Ende des Lebenszyklus der Daten ablaufen zu lassen. Verwaltungsregeln für den Lebenszyklus von Azure-Objekten unterstützen Szenarien wie das Archivieren oder Löschen von Daten anhand des Alters, das Archivieren von Daten bei der Aufnahme und das Löschen alter Snapshots.

Mit Cloud Storage können Sie das Löschen von Objekten gemäß nutzerspezifischen Lebenszyklusrichtlinien automatisieren. Weitere Informationen finden Sie unter Verwaltung des Objektlebenszyklus.

Azure Blob Storage bietet zwar keine native Funktion zur Lebenszyklusverwaltung, Sie können aber die Objektlöschung mithilfe von Azure Automation automatisieren.

Benachrichtigungen über Objektänderungen

Sowohl Azure als auch Google Cloud stellen ein Publish/Subscribe-Modell bereit, mit dem Sie Benachrichtigungen senden und empfangen können, wenn Objekte geändert werden. In Azure Blob Storage steht Ihnen Azure Event Grid zur Verfügung, um Blob Storage-Ereignisse nachzuverfolgen und sie an einen Webhook, eine Azure-Funktion oder einen anderen Endpunkt zu senden. Ähnlich bietet Google Cloud Pub/Sub-Benachrichtigungen, mit denen Sie Benachrichtigungen in einem Pub/Sub-Thema veröffentlichen können, wenn Objekte in einem Cloud Storage-Bucket erstellt, gelöscht oder aktualisiert werden. Damit Sie diese Benachrichtigungen erhalten, können Sie dieses Pub/Sub-Thema von anderen Anwendungen oder Diensten aus abonnieren.

Verschlüsselung

Azure unterstützt die Verschlüsselung inaktiver Daten über Azure Storage Service Encryption (SSE). Der gesamte Blob-basierte Speicher in Ihrem Speicherkonto wird während des eingehenden und ausgehenden Traffics mit AES-256 ver- bzw. entschlüsselt. Wenn Sie die Verschlüsselung für Ihr Konto aktivieren, nachdem Sie bereits Daten hochgeladen haben, werden diese Daten erst verschlüsselt, wenn sie neu geschrieben werden. Azure unterstützt auch vom Kunden verwaltete Verschlüsselungsschlüssel (Customer Managed Encryption Keys, CMEK) für die serverseitige Verschlüsselung (Server-Side Encryption, SSE). SSE für Azure Blob Storage und Azure Files ist in Azure Key Vault eingebunden, damit Sie Ihre Verschlüsselungsschlüssel mithilfe eines Key Vaults verwalten können.

In ähnlicher Weise werden alle Daten, die in den Speicherdiensten von Google Cloud (einschließlich Cloud Storage) gespeichert sind, im Ruhezustand automatisch entweder mit AES-256 oder AES-128 verschlüsselt. Bei Daten, bei denen Sie Ihren eigenen Verschlüsselungsschlüssel verwalten müssen, unterstützt Google Cloud auch CMEK mit dem Cloud Key Management Service und mit vom Kunden bereitgestellten Verschlüsselungsschlüsseln (Customer-Supplies Encryption Keys, CSEK). Weitere Informationen finden Sie unter Verschlüsselung inaktiver Daten auf der Google Cloud Platform.

Service Level Agreement

Microsoft und Google stellen Service Level Agreements (SLAs) bereit und haben Richtlinien für die Belastung von Kundenkonten, falls diese SLAs nicht eingehalten werden. Die Garantien und Richtlinien für Azure Blob Storage im SLA für Azure Storage von Microsoft festgelegt. Die Garantien und Richtlinien für Cloud Storage sind im Cloud Storage SLA von Google definiert.

Kosten

Azure Blob Storage

Die Preise für Azure Blob Storage richten sich nach der Menge der pro Monat gespeicherten Daten, dem Speicherkontotyp, dem Replikationstyp und dem ausgehenden Netzwerk-Traffic. Wenn Sie Objekt-Snapshots erstellen, werden diese zum selben Preis wie die Live-Version der Objekte abgerechnet. Azure Blob Storage stellt auch allgemeine API-Anfragen in Rechnung.

Cloud Storage Standard

Der Preis für Cloud Storage Standard richtet sich nach der pro Monat gespeicherten Datenmenge und dem ausgehenden Netzwerktraffic. Für Buckets mit aktivierter Objektversionierung wird jede archivierte Version eines Objekts mit dem gleichen Preis wie die Live-Version des Objekts abgerechnet. Cloud Storage Standard erhebt außerdem Gebühren für allgemeine API-Anfragen.

Blockspeicher

Sowohl in Google Cloud als auch in Azure stehen Blockspeicheroptionen zur Verfügung. Google Cloud bietet Blockspeicher in Form von nichtflüchtigem Speicher, der Teil von Compute Engine ist. Azure stellt Blockspeicher in Form von Seiten-Blobs bereit, die in einem Container in einem allgemeinen Speicherkonto gespeichert sind. Auf beiden Plattformen haben Nutzer die Möglichkeit, lokal angehängte SSDs zu verwenden.

Dienstmodelle im Vergleich

Abgesehen von der Art der Speicherung sind der nichtflüchtige Compute Engine-Speicher und die virtuellen Azure-Festplatten (VHDs) sehr ähnlich. In beiden Fällen sind die Laufwerks-Volumes mit dem Netzwerk verbunden. Allerdings bieten sowohl Compute Engine als auch Azure die Möglichkeit, ein Laufwerk gegebenenfalls lokal anzuhängen. Obwohl mit dem Netzwerk verbundene Laufwerke eine höhere operative Latenz und weniger Durchsatz als lokal angehängte Laufwerke aufweisen, haben sie auch viele Vorteile, darunter integrierte Redundanz, die Möglichkeit zum Erstellen von Snapshots und einfaches Anhängen und Trennen von Laufwerken.

Azure-VHDs

Azure speichert seine VHDs als Seiten-Blobs. Seiten-Blobs können bis zu 8 TB groß sein, VHDs bis zu 4 TB. Virtuelle Azure-Maschinen haben je nach Maschinentyp Beschränkungen, wie viele VHDs gleichzeitig angehängt werden können.

Jede VHD muss sich in einem Speicherkonto befinden, das in derselben Region ist wie die virtuelle Maschine, mit der die VHD verbunden ist. Die Latenz und der Durchsatz von VHDs hängen sowohl vom Speicherkontotyp als auch vom Maschinentyp der VM ab:

  • Azure-Standard-Speicherkonten werden auf Standard-HDDs ausgeführt und empfehlen sich für selten aufgerufene Daten oder Massenspeicher.
  • Azure-Premium-Speicherkonten werden auf SSD-Laufwerken ausgeführt und eignen sich für E-/A-intensive Vorgänge. Die Premium-Speicherebene unterstützt nur die LRS-Replikation. Da die Premium-Speicherebene nur für VHDs verfügbar ist, müssen Sie unter Umständen ein separates Speicherkonto speziell für Ihre VHDs mit SSD-Laufwerken erstellen, wenn Sie Ihre Laufwerke manuell verwalten und nicht von Azure verwalten lassen möchten. Einige Maschinen auf niedriger Ebene wie A0 unterstützen keine VHDs mit SSD-Laufwerken.

Verwaltete Azure-Laufwerke stellen eine Möglichkeit dar, VHDs mit Azure-VMs zu verwenden. Es ist eine Abstraktion von Seiten-Blobs, Blob-Containern und Speicherkonten. Es gibt vier Arten von verwalteten Laufwerken: Ultra SSD, Premium SSD, Standard SSD und Standard HDD.

Nichtflüchtige Compute Engine-Speicher

Google Cloud bietet Blockspeicher in Form von nichtflüchtigem Speicher, der sich in Compute Engine befindet. Bei den meisten Compute Engine-VM-Instanzen mit benutzerdefinierten Maschinentypen oder vordefinierten Maschinentypen können Sie bis zu 128 nichtflüchtige Speicher anhängen. Bei Maschinentypen-Instanzen mit gemeinsam genutztem Kern sind maximal 16 nichtflüchtige Speicher zulässig. Sie können pro VM-Instanz bis zu 257 TB an nichtflüchtigem Speicher anhängen und jeder nichtflüchtige Speicher kann eine Kapazität von bis zu 64 TB haben. Nichtflüchtiger Speicher kann in Form von HDDs oder SSDs eingesetzt werden. Wie bei Azure müssen Sie Ihr Laufwerks-Volume in derselben Zone erstellen wie die VM-Instanz, mit der das Laufwerk verbunden wird.

Die folgende Tabelle enthält eine Übersicht über nichtflüchtigen Compute Engine-Speicher und Azure-VHDs:

Funktion Azure-VHDs Nichtflüchtige Compute Engine-Speicher
Volume-Typen Standard-Speicher (HDD), Premium-Speicher (SSD) Nichtflüchtiger Standardspeicher (HDD), nichtflüchtiger SSD-Speicher
Verwaltungsschemas Nicht verwaltete Laufwerke, verwaltete Laufwerke – (auf Projektebene von Google Cloud verwaltet)
Volume-Anhang Können immer nur jeweils einer Instanz angehängt werden Volumes mit Lese-/Schreibzugriff: Können immer nur jeweils einer Instanz angehängt werden
Schreibgeschützte Volumes: Können mehreren Instanzen angehängt werden
Maximale Volume-Größe 4 TiB 64 TB
Redundanz Ja Ja
Erstellen von Snapshots Ja Ja
Laufwerksverschlüsselung Standardmäßig verschlüsselt Standardmäßig verschlüsselt

Die folgende Tabelle enthält eine Übersicht über die lokal angehängten Laufwerke von Compute Engine und von Azure:

Funktion Azure Compute Engine
Dienstname Lokale SSD Lokale SSD
Anhängen von Volumes An Instanztyp gebunden Kann jeder Instanz ohne gemeinsam genutzten Kern angehängt werden
Angehängte Volumes pro Instanz Variiert je nach Instanztyp Bis zu 8
Speicherkapazität Variiert je nach Instanztyp 375 GB pro Volume
Live-Migration Nein Ja
Redundanz Keine Keine

Replikation

Bei Azure Storage können Sie VHDs je nach Maschinentyp und Speicherkontotyp zu Redundanzzwecken replizieren. Sie können Ihre Daten folgendermaßen replizieren lassen: mit lokal redundantem Speicher (Locally Redundant-Storage, LRS) lokal in einer Speichermaßeinheit, mit zonenredundantem Speicher (Zone-Redundant-Storage, ZRS) über drei Verfügbarkeitszonen hinweg oder mit georedundantem Speicher (Geo-Redundant-Storage, GRS) über mehrere Regionen hinweg oder mit georedundantem Speicher mit Lesezugriff (Read-Access Geo-Redundant-Storage, RA-GRS).

Sie können nichtflüchtige Compute Engine-Speicher in einer einzelnen Compute Engine-Region replizieren. Wenn Sie in Compute Engine robuste Systeme konzipieren, sollten Sie sich für die Verwendung von regionalen nichtflüchtigen Speichern entscheiden, um eine hohe Verfügbarkeit für Ressourcen in mehreren Zonen zu gewährleisten. Regionale nichtflüchtige Speicher bieten eine synchrone Replikation für Arbeitslasten, die möglicherweise keine Replikation auf Anwendungsebene haben.

Beide Dienste bieten Replikationsoptionen für mehr Langlebigkeit. Diese schützen jedoch nicht vor Datenbeschädigung oder versehentlichem Löschen aufgrund von Nutzer- oder Anwendungsfehlern. Damit wichtige Daten geschützt sind, sollten Nutzer diese regelmäßig sichern und Snapshots der Laufwerke erstellen.

Volumes anhängen und trennen

Nach dem Erstellen eines Laufwerk-Volumes können Sie das Volume an eine VM anhängen. VM-Instanzen von Azure und von Compute Engine funktionieren ähnlich. Die VM-Instanz kann dann das Laufwerks-Volume wie jedes andere Blockgerät bereitstellen oder formatieren. Genauso können Sie ein Volume von einer Instanz trennen und es anderen Instanzen anhängen.

Eine Azure-VHD kann jeweils nur einer VM angehängt werden. Für nichtflüchtigen Compute Engine-Speicher im Lese-/Schreibmodus gelten dieselben Einschränkungen. Nichtflüchtiger Speicher im Lesemodus kann jedoch mehreren Instanzen gleichzeitig angehängt werden.

Volume-Sicherung

Sowohl mit Compute Engine als auch mit Azure können Nutzer Snapshots von Laufwerks-Volumes erstellen und speichern. Mit diesen Snapshots lassen sich später neue Volumes erstellen.

Nichtflüchtiger Compute Engine-Speicher und nicht verwaltete Azure-Laufwerke unterstützen beide differenzielle Snapshots. Beim ersten Snapshot wird eine vollständige Kopie des Volumes erstellt, während bei nachfolgenden Snapshots nur die Blöcke kopiert werden, die sich seit dem vorherigen Snapshot geändert haben. Nach einer Reihe differenzieller Snapshots wird wieder ein vollständiger Snapshot erstellt und der Zyklus wiederholt sich.

Verwaltete Azure-Laufwerke unterstützen derzeit keine differenziellen Snapshots. Stattdessen wird jeweils eine vollständige Kopie des Laufwerks-Volumes erstellt. Der API-Support erleichtert inkrementelle Snapshots. Inkrementelle Snapshots werden jedoch nicht standardmäßig bereitgestellt.

Azure bietet außerdem Azure Backup und den Azure-Wiederherstellungsdienst zur Automatisierung von Sicherungs- und Wiederherstellungsvorgängen. Google Cloud verfügt nicht über entsprechende Dienste.

Volume-Leistung

Sowohl beim nichtflüchtigen Compute Engine-Speicher als auch bei Azure-VHDs hängt die Laufwerksleistung von mehreren Faktoren ab:

  • Volume-Typ: Jeder Dienst bietet mehrere verschiedene Volume-Typen. Jeder hat seine eigenen Leistungseigenschaften und Limits.
  • Verfügbare Bandbreite: Der Durchsatz eines mit dem Netzwerk verbundenen Volumes hängt von der Netzwerkbandbreite ab, die der Compute Engine- oder Azure-VM zur Verfügung steht, der das Volume angehängt wurde.

Dieser Abschnitt behandelt zusätzliche Leistungsinformationen für jeden Dienst.

Azure-VHDs

Die Azure-VM-Typen variieren in Bezug auf die Netzwerkleistung stark. VM-Typen mit einer geringen Anzahl von Kernen haben möglicherweise nicht genug Netzwerkkapazität, um die angegebenen maximalen IOPs oder den Durchsatz für einen bestimmten VHD-Laufwerkstyp zu erreichen. Weitere Informationen finden Sie unter Storage Premium-Hochleistungsspeicher und verwaltete Datenträger für VMs.

Nichtflüchtige Compute Engine-Speicher

Compute Engine verteilt den Durchsatz pro Kern. Sie erhalten 2 Gbit/s ausgehenden Netzwerk-Traffic pro virtuellem CPU-Kern mit theoretisch maximal 16 Gbit/s für eine einzige VM-Instanz. Da Compute Engine einen Datenredundanzfaktor von 3,3 hat, erfordert jeder logische Schreibvorgang eine Netzwerkbandbreite, die 3,3 Schreibprozessen entspricht. Dementsprechend haben Maschinentypen mit einer geringen Anzahl von Kernen möglicherweise nicht genug Netzwerkkapazität, um die angegebenen maximalen IOPs oder den Durchsatz für einen bestimmten nichtflüchtigen Speichertyp zu erreichen. Weitere Informationen finden Sie unter Kapazität des ausgehenden Netzwerk-Traffics.

Bei jedem Compute Engine-Laufwerkstyp steht das gesamte verfügbare E/A-Volumen in Relation zur Gesamtgröße der Volumes, die mit einer bestimmten Instanz verbunden sind. Wenn Sie beispielsweise zwei standardmäßige nichtflüchtige Speicher von 2,5 TB haben, die mit einer Instanz verbunden sind, beträgt Ihr gesamtes verfügbares E/A-Volumen 3.000 Lese-IOPS und 7.500 Schreib-IOPS.

Lokal angehängte Laufwerke

Neben dem standardmäßigen, mit dem Netzwerk verbundenen Blockspeicher können Nutzer sowohl in Azure als auch in Compute Engine SSDs verwenden, die lokal an die physische Maschine angehängt sind, die die Instanz ausführt. In beiden Umgebungen heißen diese Laufwerke lokale SSDs. Lokale SSDs bieten wesentlich schnellere Übertragungsraten als ein mit dem Netzwerk verbundener Blockspeicher. Im Gegensatz zu einem mit dem Netzwerk verbundenen Blockspeicher garantieren sie jedoch keine Datenpersistenz und es können von ihnen keine differenziellen Snapshots mit nativen Funktionen erstellt werden.

In Azure hängen die Größe und Verfügbarkeit lokaler SSDs direkt vom Maschinentyp ab. Lokale SSDs können zwischen 16 GB und 6 TB groß sein. Einige Maschinentypen wie die A-Serie beinhalten keine lokalen SSDs.

In Compute Engine können lokale SSDs an fast jeden Maschinentyp angehängt werden, mit Ausnahme von Typen mit gemeinsam genutztem Kern wie f1-micro und g1-small. Lokale SSDs haben eine feste Größe von 375 GB pro Laufwerk. Sie können maximal 8 Laufwerke mit einer Gesamtkapazität von 3 TB an eine einzelne Instanz anhängen.

Compute Engine migriert lokale SSDs automatisch und nahtlos, bevor die Hostmaschinen für die Wartung heruntergefahren werden. Weitere Informationen finden Sie unter Live-Migration.

Kosten

In Azure werden die Laufwerks-Volumes pro GB und Monat abgerechnet. Die Kosten für lokale SSDs sind in den Kosten der virtuellen Maschine enthalten.

Die Preise für nichtflüchtigen Speicher und Laufwerks-Snapshots in Compute Engine werden auch pro GB und Monat berechnet. Lokale SSDs werden unabhängig von den Maschinenkosten in Rechnung gestellt. Weitere Informationen finden Sie unter Lokale SSDs – Preise.

Dateispeicher

Für dateiserverbasierte Arbeitslasten bietet Azure Azure Files, einen verteilten SMB-basierten Dateiserverdienst.

Google Cloud bietet Filestore, einen verwalteten Dateispeicherdienst für Anwendungen, die eine Dateisystemschnittstelle und ein gemeinsames Dateisystem für Daten benötigen. Filestore bietet Nutzern eine einfache, native Bereitstellung von verwaltetem Network Attached Storage (NAS) für ihre Compute Engine- und Google Kubernetes Engine-Instanzen (GKE).

Storage Area Network (SAN)

Für SAN-Arbeitslasten bietet Azure eine Verknüpfung mit StorSimple, der proprietären SAN-Appliance von Microsoft. Architektonisch umfasst StorSimple ein lokales StorSimple-SAN und eine virtuelle cloudbasierte Appliance, die das Verhalten des lokalen SAN repliziert.

In Google Cloud können Sie nichtflüchtige Speicher für Arbeitslasten verwenden, die SANs erwarten. In einem SAN-Kontext verwendeter nichtflüchtiger Speicher funktioniert analog zu den logischen Laufwerksvolumen, auf die Sie durch LUN-Geräte zugreifen würden, und kann auf ähnliche Art zugeteilt werden. Wie bei logischen Laufwerks-Volumes, die auf LUN (Logical Unit Number) basieren, können Sie mehrere nichtflüchtige Speichermedien in einer einzigen VM-Instanz bereitstellen. Außerdem besteht die Möglichkeit, einen einzelnen nichtflüchtigen Speicher mit Lesezugriff auf mehreren VM-Instanzen bereitzustellen. Weitere Informationen finden Sie unter Google Cloud Platform für Rechenzentrumsexperten: Speicherung.

Kalter Speicher

Sowohl Google Cloud als auch Azure bieten kalten Speicher als Option für Daten, auf die nicht regelmäßig zugegriffen werden muss. Cloud Storage hat dafür die zusätzlichen Klasse namens "Cloud Storage Nearline" und "Cloud Storage Coldline" und Azure Blob Storage die zusätzliche Ebene "Kalt".

Latenz

Bei beiden Diensten liegt die Zeit bis zum ersten Byte im Millisekundenbereich.

Replikation

Bei Verwendung der Ebene "Kalt" von Azure Blob Storage hängt die Replikation Ihrer Daten vom Replikationstyp Ihres Speicherkontos ab. Bei Verwendung von Cloud Storage Nearline oder Cloud Storage Coldline hängt die Replikation Ihrer Daten vom Typ des Speicherorts ab, in dem Sie die Daten speichern.

Speicherdauer

Wenn Sie ein Blob-spezifisches Speicherkonto verwenden, gibt es für die Ebene "Kalt" von Azure Blob Storage keine Mindestspeicherdauer. Bei allgemeinen Speicherkonten der Version 2 liegt die Mindestspeicherdauer der Ebene "Kalt" von Azure Blob Storage bei 30 Tagen pro Blob. Wenn Sie ein Blob vor Ablauf der Mindestspeicherdauer löschen oder überschreiben, entstehen zusätzliche Kosten.

Cloud Storage Nearline hat für jedes Datenobjekt eine Mindestspeicherdauer von 30 Tagen. Bei Cloud Storage Coldline hat jedes Datenobjekt eine Mindestspeicherdauer von 90 Tagen. Wie bei der Ebene "Kalt" von Azure Blob Storage und Verwendung eines allgemeinen Speicherkontos der Version 2 fallen auch hier zusätzliche Kosten an, wenn ein Datenobjekt vor Ablauf der Mindestspeicherdauer gelöscht oder überschrieben wird.

Kosten

Ebene "Kalt" von Azure Blob Storage

Bei der Ebene "Kalt" von Azure Blob Storage richtet sich der Preis nach der pro Monat gespeicherten Datenmenge, dem Speicherkontotyp, dem Replikationstyp und dem ausgehenden Netzwerk-Traffic. Außerdem werden bei der Ebene "Kalt" von Azure Blob Storage auch allgemeine API-Anfragen, Datenschreibvorgänge und der Datenabruf in Rechnung gestellt.

Cloud Storage Nearline und Cloud Storage Coldline

Bei Cloud Storage Nearline und Cloud Storage Coldline richtet sich der Preis nach der pro Monat gespeicherten Datenmenge und dem ausgehenden Netzwerktraffic. Wenn Sie Daten vor Ablauf der Mindestspeicherdauer löschen oder ändern, wird Ihnen die verbleibende Dauer berechnet. Falls Sie beispielsweise ein als Cloud Storage Nearline gespeichertes Objekt fünf Tage nach dem Speichern löschen, werden Ihnen die verbleibenden 25 Tage für die Speicherung dieses Objekts berechnet. Bei Cloud Storage Nearline und Cloud Storage Coldline werden außerdem auch allgemeine API-Anfragen und der Datenabruf in Rechnung gestellt.

Weitere Informationen zu den Preisen für Cloud Storage Nearline und Cloud Storage Coldline erhalten Sie unter Cloud Storage-Preise.

Archivspeicher

Sowohl die GCP als auch Azure bieten eine Archivspeicheroption. Cloud Storage hat dafür eine zusätzliche Klasse namens Cloud Storage Archive und Azure Blob Storage die zusätzliche Ebene "Archiv".

Latenz

Bei Cloud Storage Archive liegt die Zeit bis zum ersten Byte im Millisekundenbereich. Bei der Ebene "Archiv" von Azure Blob Storage beträgt die Zeit bis zum ersten Byte 15 Stunden oder weniger.

Replikation

Wenn Sie die Ebene "Archiv" von Azure Blob Storage verwenden, hängt die Replikation der Daten vom Replikationstyp Ihres Speicherkontos ab. Bei Verwendung von Cloud Storage Archive hängt die Replikation Ihrer Daten vom Typ des Speicherorts ab, in dem Sie die Daten speichern.

Speicherdauer

Die Ebene "Archiv" von Azure Blob Storage hat eine Mindestspeicherdauer von 180 Tagen pro Blob. Wenn Sie ein Blob vor Ablauf der Mindestspeicherdauer löschen oder überschreiben, entstehen zusätzliche Kosten.

Cloud Storage Archive hat für jedes Datenobjekt eine Mindestspeicherdauer von 365 Tagen. Wie bei der Ebene "Archiv" von Azure Blob Storage fallen auch hier zusätzliche Kosten an, wenn ein Datenobjekt vor Ablauf der Mindestspeicherdauer gelöscht oder überschrieben wird.

Kosten

Ebene "Archiv" von Azure Blob Storage

Bei der Ebene "Archiv" von Azure Blob Storage richtet sich der Preis nach der pro Monat gespeicherten Datenmenge, dem Speicherkontotyp, dem Replikationstyp und dem ausgehenden Netzwerk-Traffic. Wenn Sie Daten vor Ablauf der Mindestspeicherdauer löschen oder ändern, wird Ihnen die verbleibende Dauer berechnet. Falls Sie beispielsweise ein Blob fünf Tage nach der Speicherung löschen, werden Ihnen trotzdem die verbleibenden 175 Tage für die Speicherung dieses Blobs berechnet. Wenn Sie außerdem Blob-Snapshots erstellen, werden diese zum selben Preis wie die Live-Versionen der Blobs abgerechnet.

Die Ebene "Archiv" von Azure Blob Storage stellt auch allgemeine API-Anfragen in Rechnung.

Cloud Storage Archive

Der Preis für Cloud Storage Archive richtet sich nach der pro Monat gespeicherten Datenmenge und dem ausgehenden Netzwerktraffic. Wenn Sie Daten vor der Mindestdauer löschen oder bearbeiten, wird Ihnen die verbleibende Dauer berechnet. Falls Sie beispielsweise ein Objekt fünf Tage nach dem Speichern löschen, werden Ihnen die verbleibenden 360 Tage für die Speicherung dieses Objekts berechnet. Cloud Storage Archive erhebt außerdem Gebühren für allgemeine API-Anfragen und den Datenabruf.

Weitere Informationen zu den Preisen für Cloud Storage Archive finden Sie unter Cloud Storage-Preise.

Nächste Schritte

Weitere Artikel zu Google Cloud für Azure-Experten: