Speicheroptionen


Die Compute Engine bietet für Ihre VMs mehrere Speicheroptionen. Jede der folgenden Speicheroptionen hat eigene Preis- und Leistungsmerkmale:

  • Mit Hyperdisk-Speicherpools können Sie Speicherkapazität und -leistung als Ganzes erwerben und dann aus diesem Speicherpool Laufwerke für Ihre VMs erstellen.
  • Google Cloud-Hyperdisk-Volumes sind Netzwerkspeicher für Compute Engine mit konfigurierbarer Leistung und konfigurierbaren Volumes, deren Größe dynamisch angepasst werden kann. Sie bieten im Vergleich zu Persistent Disk eine deutlich höhere Leistung, Flexibilität und Effizienz.
  • Persistent Disk-Volumes bieten leistungsstarken und redundanten Netzwerkspeicher. Jedes Persistent Disk-Volume wird über Hunderte von physischen Laufwerken „gestriped”.
    • Standardmäßig verwenden VMs zonale Persistent Disk und speichern Ihre Daten auf Volumes, die sich innerhalb einer einzelnen Zone befinden, z. B. us-west1-c.
    • Sie können auch regionale Persistent Disk-Volumes erstellen, die Daten synchron zwischen Laufwerken replizieren, die sich in zwei Zonen befinden, und Schutz bieten, wenn eine Zone nicht mehr verfügbar ist.
  • Lokale SSD-Laufwerke sind physische Laufwerke, die direkt mit demselben Server wie Ihre VM verbunden sind. Sie bieten eine bessere Leistung, sind jedoch sitzungsspezifisch.
  • Cloud Storage-Buckets: Erschwinglicher Objektspeicher
  • Darüber hinaus können Sie Filestore mit Ihren VMs für Hochleistungs-Dateispeicher verwenden.

Jede Speicheroption hat besondere Preis- und Leistungsmerkmale. Kostenvergleiche finden Sie unter Laufwerkspreise. Die meisten Nutzer entscheiden sich dafür, ihrer VM ein Persistent Disk-Volume hinzuzufügen.

Einführung

Standardmäßig hat jede Compute Engine-VM ein einzelnes Bootlaufwerk, auf dem sich das Betriebssystem befindet. Die Bootlaufwerksdaten werden in der Regel auf einem Persistent Disk-Volume gespeichert. Wenn Ihre Anwendungen zusätzlichen Speicherplatz benötigen, können Sie ein oder mehrere der folgenden Speicher-Volumes für Ihre VM bereitstellen.

Weitere Informationen zu den einzelnen Speicheroptionen finden Sie in der folgenden Tabelle:

Abgestimmte
Persistent Disk
SSD-
Persistent Disk
Standard-
Persistent Disk
Extrem-
Persistent Disk
Hyperdisk abgestimmt Hyperdisk Extrem Hyperdisk Durchsatz Lokale SSDs Cloud Storage-Buckets
Speichertyp Kostengünstiger und zuverlässiger Blockspeicher Schneller, zuverlässiger Blockspeicher Effizienter, zuverlässiger Blockspeicher Höchste Leistung von Persistent Disk-Blockspeicher mit anpassbaren IOPS Hohe Leistung für anspruchsvolle Arbeitslasten zu geringeren Kosten Schnellste Blockspeicheroption mit anpassbaren IOPS Kostengünstiger und durchsatzorientierter Blockspeicher mit anpassbarem Durchsatz Lokaler Hochleistungs-Blockspeicher Günstiger Objektspeicher
Mindestkapazität pro Laufwerk Zonal: 10 GiB
Regional: 10 GiB
Zonal: 10 GiB
Regional: 10 GiB
Zonal: 10 GiB
Regional: 200 GiB
500 GiB 4 GiB 64 GiB 2 TiB 375 GiB, 3 TiB mit Z3
Maximale Kapazität pro Laufwerk 64 TiB 64 TiB 64 TiB 64 TiB 64 TiB 64 TiB 32 TiB 375 GiB,
3 TiB mit Z3
Kapazitätserhöhung 1 GiB 1 GiB 1 GiB 1 GiB 1 GiB 1 GiB 1 GiB Je nach Maschinentyp
Maximale Kapazität pro VM 257 TiB* 257 TiB* 257 TiB* 257 TiB* 512 TiB* 512 TiB* 512 TiB* 36 TiB Praktisch unbegrenzt
Umfang des Zugriffs Zone Zone Zone Zone Zone Zone Zone Instanz Global
Datenredundanz Zonal und multizonal Zonal und multizonal Zonal und multizonal Zonal Zonal Zonal Zonal Regional, dual-regional oder multiregional
Verschlüsselung inaktiver Daten Ja Ja Ja Ja Ja Ja Ja Ja Ja
Benutzerdefinierte Verschlüsselungsschlüssel Ja Ja Ja Ja Ja Ja Ja Nein Ja
Anleitung Extreme Persistent Disk hinzufügen Hyperdisk hinzufügen Lokale SSD hinzufügen Verbindung zu einem Bucket herstellen

* Wenn Sie ein logisches Volume erstellen möchten, das größer als die maximale Größe eines einzelnen Laufwerks ist, lesen Sie, wie dielogische Volume-Größe sich auf die Leistung auswirkt.

 Die Kapazitätserhöhung für lokale SSDs hängt von der Anzahl der zulässigen SSD-Laufwerke (Partitionen) pro VM ab. Diese variiert je nach Maschinentyp. Weitere Informationen finden Sie unter Gültige Anzahl lokaler SSDs auswählen.

Zusätzlich zu den Speicheroptionen von Google Cloud können Sie auf Ihren VMs alternative Speicherlösungen implementieren.

Blockspeicherressourcen haben unterschiedliche Leistungsmerkmale. Berücksichtigen Sie Ihre Anforderungen an Speichergröße und Leistung, wenn Sie den geeigneten Blockspeichertyp für Ihre VMs auswählen.

Informationen zu den Leistungsgrenzen für die einzelnen Laufwerkstypen finden Sie unter:

Persistent Disk-Volumes, die im Modus für mehrere Autoren erstellt werden, haben bestimmte IOPS- und Durchsatzlimits. Weitere Informationen finden Sie unter Leistung von Persistent Disk im Modus für mehrere Autoren.

Persistent Disk

Persistent Disk-Volumes sind langlebige Netzwerkspeichergeräte, auf die VM-Instanzen wie auf physische Laufwerke auf einem Desktop-Computer oder einem Server zugreifen können. Die Daten auf einem Persistent Disk-Volume sind auf mehrere physische Laufwerke verteilt. Compute Engine verwaltet die physischen Laufwerke und die Datenverteilung und sorgt damit automatisch für Redundanz und optimale Leistung.

Persistent Disk-Volumes sind unabhängig von Ihrer VM. Sie können sie deshalb trennen oder verschieben, wenn Sie Daten aufbewahren möchten, auch nachdem Sie die VMs gelöscht haben. Die Leistung von Persistent Disk hängt von der Volume-Größe ab. Sie können bestehende Persistent Disk-Volumes jederzeit ändern oder einer VM weitere Persistent Disk-Volumes hinzufügen, um die Leistungs- und Speicherplatzanforderungen zu erfüllen.

Persistent Disk-Typen

Wenn Sie einen nichtflüchtigen Speicher konfigurieren, können Sie einen der folgenden Laufwerkstypen auswählen.

  • Abgestimmter nichtflüchtiger Speicher (pd-balanced)
    • Eine Alternative zu leistungsstarkem nichtflüchtigem Speicher (pd-ssd)
    • Kompromiss zwischen Leistung und Kosten. Bei den meisten VM-Typen mit Ausnahme großer Datenmengen haben diese Laufwerke die gleiche maximale IOPS-Anzahl wie nichtflüchtige SSD-Speicher und eine niedrigere IOPS pro GiB. Dieser Laufwerkstyp bietet Leistungsebenen, die für die meisten allgemeinen Anwendungen geeignet sind. Die Kosten liegen dabei zwischen dem standardmäßigen nichtflüchtigen Standardspeicher und dem leistungsstarken nichtflüchtigen Speicher (pd-ssd).
    • Gesichert durch Solid-State-Laufwerke (SSD)
  • Leistungsstarker nichtflüchtiger SSD-Speicher (pd-ssd)
    • Geeignet für Unternehmensanwendungen und Hochleistungsdatenbanken, die eine geringere Latenz und mehr IOPS als nichtflüchtige Standardspeicher erfordern.
    • Für Latenzen im einstelligen Millisekundenbereich ausgelegt. Die tatsächliche Latenz ist anwendungsspezifisch.
    • Gesichert durch Solid-State-Laufwerke (SSD)
  • Nichtflüchtige Standardspeicher (pd-standard)
    • Geeignet für große Datenverarbeitungsarbeitslasten, die hauptsächlich sequenzielle E/A-Vorgänge verwenden.
    • Gesichert durch Standardfestplattenlaufwerke (HDD)
  • Extrem nichtflüchtiger Speicher (pd-extreme)
    • Einheitliche hohe Leistung sowohl für Arbeitslasten mit zufälligen Zugriffen als auch für Bulk-Durchsätze
    • Für High-End-Datenbankarbeitslasten konzipiert
    • Ermöglicht es, Ziel-IOPS bereitzustellen
    • Gesichert durch Solid-State-Laufwerke (SSD)
    • Verfügbar für eine begrenzte Anzahl von Maschinentypen.

Wenn Sie ein Laufwerk in der Google Cloud Console erstellen, ist der Standard-Laufwerktyp pd-balanced. Wenn Sie ein Laufwerk mit der gcloud CLI oder der Compute Engine API erstellen, ist der Standardlaufwerkstyp pd-standard.

Informationen zur Unterstützung von Maschinentypen finden Sie hier:

Langlebigkeit von Persistent Disk

Die Langlebigkeit des Laufwerks stellt die Wahrscheinlichkeit eines Datenverlusts für ein typisches Laufwerk in einem typischen Jahr unter Verwendung einer Reihe von Annahmen zu Hardwarefehlern, der Wahrscheinlichkeit katastrophaler Ereignisse, der Isolierungspraktiken und der Entwicklungsprozesse in Google-Rechenzentren und den internen Codierungen dar, die von den einzelnen Laufwerktypen verwendet werden. Datenverlustereignisse bei Persistent Disk sind extrem selten und waren in der Vergangenheit das Ergebnis koordinierter Hardwarefehler, Softwarefehler oder einer Kombination aus beidem. Google unternimmt außerdem zahlreiche Schritte, um das branchenweite Risiko der schleichenden Datenbeschädigung zu minimieren. Menschliche Fehler eines Google Cloud-Kunden, z. B. wenn ein Kunde versehentlich ein Laufwerk löscht, fallen nicht unter die Langlebigkeit von Persistent Disk.

Es besteht ein sehr geringes Risiko eines Datenverlusts bei einem regionalen nichtflüchtigen Speicher aufgrund der internen Datencodierungen und der Replikation. Regionale nichtflüchtige Speicher stellen doppelt so viele Replikate bereit wie zonale Persistent Disks, wobei ihre Replikate auf zwei Zonen in derselben Region verteilt sind. Dadurch bieten sie hohe Verfügbarkeit und können zur Notfallwiederherstellung verwendet werden, wenn ein ganzes Rechenzentrum verloren geht und nicht wiederhergestellt werden kann. Dies ist bisher jedoch noch nicht passiert. Auf die zusätzlichen Replikate in einer zweiten Zone kann sofort zugegriffen werden, wenn eine primäre Zone während eines langen Ausfalls nicht mehr verfügbar ist.

Die Langlebigkeit wird für jeden Laufwerktyp zusammengefasst und stellt kein finanziell abgesichertes Service Level Agreement (SLA) dar.

Die folgende Tabelle zeigt die Langlebigkeit für die einzelnen Laufwerkstypen. Eine Langlebigkeit von 99,999 % bedeutet, dass bei 1.000 Laufwerken wahrscheinlich 100 Jahre vergehen, ohne dass ein einzelnes Laufwerk verloren geht.

Zonale Standard-Persistent Disk Abgestimmte zonale Persistent Disk Zonale SSD-Persistent Disk Zonale extreme Persistent Disk Regionale Standard-Persistent Disk Regionale abgestimmte Persistent Disk Regionale SSD-Persistent Disk
Besser als 99,99 % Besser als 99,999 % Besser als 99,999 % Besser als Besser als 99,9999 % Besser als 99,999 % Besser als Besser als 99,9999 % Besser als Besser als 99,9999 %

Zonale Persistent Disk

Nutzerfreundlichkeit

Compute Engine übernimmt fast alle Laufwerksverwaltungsaufgaben, damit Sie sich nicht um Dinge wie Partitionierung, redundante Laufwerksarrays oder Subvolume-Verwaltung kümmern müssen. Es ist im Allgemeinen nicht notwendig, größere logische Volumes zu erstellen. Sie können aber die Kapazität der sekundären angehängten Persistent Disk auf 257 TB pro VM erhöhen und diese Vorgehensweisen für die Persistent Disk-Volumes anwenden. Sie sparen Zeit und erhalten eine optimale Leistung, wenn Sie die Persistent Disk-Volumes mit einem einzigen Dateisystem und ohne Partitionstabellen formatieren.

Falls Sie Ihre Daten auf mehrere Volumes aufteilen möchten, fügen Sie weitere Laufwerke hinzu, anstatt die vorhandenen in mehrere Partitionen zu unterteilen.

Wenn Sie zusätzlichen Speicherplatz für die Persistent Disk-Volumes benötigen, können Sie die Größe des Speichers anpassen und nicht neu partitionieren und formatieren.

Leistung

Die Leistung von Persistent Disk ist vorhersehbar und wird mit der bereitgestellten Kapazität linear skaliert, bis die Grenzen der bereitgestellten vCPUs einer VM erreicht sind. Weitere Informationen zu den Grenzen der Leistungsskalierung und zur Leistungsoptimierung finden Sie unter Laufwerke so konfigurieren, dass sie die Leistungsanforderungen erfüllen.

Standard-Persistent Disks bewältigen sequenzielle Lese-/Schreibvorgänge effizient und kostengünstig, eignen sich aber nicht für große Mengen zufälliger Ein-/Ausgabevorgänge pro Sekunde (Input/Output Operations Per Second, IOPS). Wenn Ihre Anwendungen zufällige IOPS in hoher Zahl erfordern, verwenden Sie nichtflüchtige SSD- oder extreme Persistent Disk. SSD-Persistent Disk ist für Latenzen im einstelligen Millisekundenbereich ausgelegt. Die beobachtete Latenz ist anwendungsspezifisch.

Compute Engine optimiert die Leistung und Skalierung von Persistent Disk-Volumes automatisch. Ein Striping mehrerer Laufwerke oder das Vorwärmen von Laufwerken ist nicht erforderlich. Wenn Sie mehr Speicherplatz oder eine bessere Leistung benötigen, passen Sie die Größe Ihrer Laufwerke an. Sie können auch weitere vCPUs hinzufügen, um mehr Speicherplatz, Durchsatz und IOPS zu erzielen. Die Leistung der Persistent Disk basiert auf der Gesamtkapazität für Persistent Disk, die einer Instanz zugewiesen ist, und auf der Anzahl der vCPUs, die die VM aufweist.

Bei Bootgeräten können Sie die Kosten senken, wenn Sie eine Standard-Persistent Disk verwenden. Kleine Persistent Disk-Volumes mit 10 GiB eignen sich für einfache Bootvorgänge und Anwendungsfälle in Verbindung mit der Paketverwaltung. Wenn Sie aber bei der allgemeineren Verwendung des Bootgeräts eine konsistente Leistung gewährleisten möchten, verwenden Sie eine abgestimmte Persistent Disk als Bootlaufwerk.

Jeder Persistent Disk-Schreibvorgang zählt zum kumulativen ausgehenden Netzwerk-Traffic der jeweiligen VM. Daher gilt für Persistent Disk-Schreibvorgänge eine Obergrenze für den ausgehenden Netzwerk-Traffic Ihrer VM.

Zuverlässigkeit

Persistent Disk ist von Haus aus redundant, um Ihre Daten vor Geräteausfällen zu schützen und ihre Verfügbarkeit auch bei Wartungsarbeiten im Rechenzentrum sicherzustellen. Für alle Vorgänge der Persistent Disk werden Prüfsummen berechnet, um sicherzustellen, dass die gelesenen Daten mit den geschriebenen übereinstimmen.

Außerdem können Sie Snapshots von Persistent Disk erstellen, um Datenverluste aufgrund von Nutzerfehlern zu verhindern. Snapshots werden inkrementell angelegt und dauern nur wenige Minuten, selbst wenn sie von Laufwerken erstellt werden, die an laufende VMs angehängt sind.

Modus für mehrere Autoren

Sie können eine SSD-Persistent Disk im Modus für mehrere Autoren gleichzeitig an zwei N2-VMs anhängen, damit beide VMs auf dem Laufwerk lesen und schreiben können.

Persistent Disk im Modus für mehrere Autoren bietet eine gemeinsame Blockspeicherfunktion und stellt eine infrastrukturelle Grundlage für das Erstellen hochverfügbarer freigegebener Dateisysteme und Datenbanken dar. Diese speziellen Dateisysteme und Datenbanken sollten für die Verwendung mit gemeinsam genutztem Blockspeicher entwickelt werden und die Cache-Kohäsion zwischen VMs mithilfe von Tools wie nichtflüchtigen SCSI-Reservierungen verarbeiten.

Persistent Disk mit einem Modus für mehrere Autoren sollte jedoch im Allgemeinen nicht direkt verwendet werden. Beachten Sie, dass viele Dateisysteme wie EXT4, XFS und NTFS nicht für die gemeinsame Nutzung von Blockspeicher ausgelegt sind. Weitere Informationen zu den Best Practices für die gemeinsame Nutzung von Persistent Disk zwischen VMs finden Sie unter Best Practices.

Wenn Sie einen vollständig verwalteten Dateispeicher benötigen, können Sie eine Filestore-Dateifreigabe auf Ihren Compute Engine-VMs bereitstellen.

Wenn Sie den Schreibmodus für mehrere Autoren für neue Persistent Disk-Volumes aktivieren möchten, erstellen Sie eine neue Persistent Disk und geben Sie das Flag --multi-writer in der gcloud-Befehlszeile oder das Attribut multiWriter in der Compute Engine-API an. Weitere Informationen finden Sie unter Volumes für Persistent Disk zwischen VMs freigeben.

Verschlüsselung von Persistent Disk

Compute Engine verschlüsselt Ihre Daten automatisch, bevor diese von der VM an Persistent Disk übertragen werden. Jede Persistent Disk wird entweder mit vom System definierten oder mit vom Kunden bereitgestellten Schlüsseln verschlüsselt. Nutzer haben keinen Einfluss auf die Art und Weise, in der Google die Persistent Disk-Daten über mehrere physische Laufwerke verteilt.

Wenn Sie eine Persistent Disk löschen, verwirft Google die Codierschlüssel und die Daten werden unwiederbringlich gelöscht. Dieser Vorgang kann nicht rückgängig gemacht werden.

Sie können aber Laufwerke mit eigenen Verschlüsselungsschlüsseln erstellen, um die Kontrolle über die Datenverschlüsselung zu behalten.

Einschränkungen

  • Sie können ein Persistent Disk-Volume nicht an eine VM in einem anderen Projekt anhängen.

  • Sie können eine abgestimmte Persistent Disk an maximal 10 VMs im schreibgeschützten Modus anhängen.

  • Wenn Sie benutzerdefinierte Maschinentypen oder vordefinierte Maschinentypen mit mindestens einer vCPU verwenden, können Sie bis zu 128 Persistent Disk-Volumes anhängen.

  • Jedes Persistent Disk-Volume kann bis zu 64 TiB groß sein. Es ist daher nicht nötig, aus Festplatten-Arrays große logische Volumes zu erstellen. Jede VM kann nur einen begrenzten Persistent Disk-Speicher und eine gewisse Anzahl Persistent Disk-Volumes haben. Für vordefinierte Maschinentypen und benutzerdefinierte Maschinentypen gelten dieselben Persistent Disk-Beschränkungen.

  • Die meisten VMs können bis zu 128 Persistent Disk-Volumes und bis zu 257 TiB Gesamtspeicherplatz haben. Der Gesamtspeicherplatz für eine VM enthält die Größe des Bootlaufwerks.

  • Maschinentypen mit gemeinsam genutztem Kern sind auf 16 Persistent Disk-Volumes und 3 TiB Persistent Disk-Speicher insgesamt beschränkt.

  • Wenn Sie logische Volumes mit einer Kapazität von mehr als 64 TiB erstellen möchten, ist unter Umständen besondere Aufmerksamkeit erforderlich. Weitere Informationen zur Leistung logischer Volumes finden Sie unter Logische Volume-Größe.

Regionaler nichtflüchtiger Speicher

Regionale Persistent Disk-Volumes haben Speicherqualitäten, die denen von zonalen Persistent Disks ähneln. Regionale Persistent Disk-Volumes bieten jedoch eine dauerhafte Speicherung und Replikation von Daten zwischen zwei Zonen in derselben Region.

Wenn Sie robuste Systeme oder Hochverfügbarkeitsdienste für Compute Engine konzipieren, sollten Sie regionale Persistent Disks mit anderen Best Practices kombinieren, z. B. mit der Sicherung Ihrer Daten mit Snapshots. Regionale Persistent Disk-Volumes funktionieren auch mit regional verwalteten Instanzgruppen.

Im unwahrscheinlichen Fall eines zonalen Ausfalls können Sie für Ihre Arbeitslast, die auf regionalen Persistent Disk-Volumes ausgeführt wird, mit dem Flag --force-attach einen Failover zu einer anderen Zone durchführen. Mit dem Flag --force-attach können Sie die regionale Persistent Disk an eine Standby-VM anhängen, auch wenn der Speicher aufgrund der Nichtverfügbarkeit der ursprünglichen VM nicht von dieser getrennt werden kann. Weitere Informationen finden Sie unter Failover für regionale Persistent Disk. Sie können das Anhängen einer zonalen Persistent Disk an eine VM nicht erzwingen.

Leistung

Regionale Persistent Disk-Volumes sind für Arbeitslasten vorgesehen, die im Vergleich zur Verwendung von Persistent Disk-Snapshots ein niedrigeres Recovery Point Objective (RPO) und ein niedrigeres Recovery Time Objective (RTO) erfordern.

Regionale Persistent Disk ist eine Option, wenn die Schreibleistung weniger kritisch ist als die Datenredundanz über mehrere Zonen hinweg.

Wie zonale Persistent Disk kann regionale Persistent Disk bei VMs mit einer größeren Anzahl von vCPUs eine höhere IOPS- und Durchsatzleistung erzielen. Weitere Informationen zu diesen und anderen Einschränkungen finden Sie unter Laufwerke so konfigurieren, dass sie die Leistungsanforderungen erfüllen.

Wenn Sie mehr Speicherplatz oder eine bessere Leistung benötigen, können Sie die Größe Ihrer regionalen Festplatten ändern, um mehr Speicherplatz, Durchsatz und IOPS hinzuzufügen.

Zuverlässigkeit

Compute Engine repliziert Daten Ihrer regionalen Persistent Disk in die Zonen, die Sie beim Erstellen Ihrer Festplatten ausgewählt haben. Die Daten jedes Replikats sind auf mehrere physische Maschinen innerhalb der Zone verteilt, um Redundanz zu gewährleisten.

Ähnlich wie bei zonaler Persistent Disk können Sie Persistent Disk-Snapshots erstellen, um Datenverluste aufgrund von Nutzerfehlern zu verhindern. Snapshots werden inkrementell angelegt und dauern nur wenige Minuten, selbst wenn sie von Laufwerken erstellt werden, die an laufende VMs angehängt sind.

Beschränkungen

  • Sie können regionalen nichtflüchtigen Speicher nur an VMs anhängen, die den Maschinentyp E2, N1, N2 oder N2D verwenden.
  • Sie können keinen regionalen nichtflüchtigen Speicher aus einem Image erstellen.
  • Im schreibgeschützten Modus können Sie einen regionalen abgestimmten nichtflüchtigen Speicher an maximal 10 VM-Instanzen anhängen.
  • Die Mindestgröße eines regionalen nichtflüchtigen Standardspeichers beträgt 200 GiB.
  • Sie können die Größe eines regionalen nichtflüchtigen Speicher-Volumes erhöhen, aber nicht verringern.
  • Regionale nichtflüchtige Speicher-Volumes haben unterschiedliche Leistungsmerkmale als zonale nichtflüchtige Speicher-Volumes. Weitere Informationen finden Sie unter Blockspeicherleistung.
  • Wenn Sie einen regionalen nichtflüchtigen Speicher durch Klonen eines zonalen Laufwerks erstellen, sind die beiden zonalen Replikate zum Zeitpunkt der Erstellung nicht komplett synchron. Nach der Erstellung können Sie den regionalen Laufwerkklon innerhalb von durchschnittlich 3 Minuten verwenden. Sie müssen jedoch möglicherweise einige Minuten warten, bevor das Laufwerk einen vollständig replizierten Zustand erreicht und das Recovery Point Objective (RPO) fast null ist. So prüfen Sie, ob Ihr regionaler nichtflüchtiger Speicher vollständig repliziert wurde

Google Cloud-Hyperdisk

Google Cloud Hyperdisk ist der Blockspeicher der nächsten Generation von Google. Durch die Auslagerung und dynamische Skalierung der Speicherverarbeitung wird die Speicherleistung vom VM-Typ und der Größe entkoppelt. Hyperdisk bietet eine deutlich höhere Leistung, Flexibilität und Effizienz.

  • Hyperdisk abgestimmt

    Hyperdisk Balanced für die Compute Engine eignet sich für eine Vielzahl von Anwendungsfällen, z. B. für LOB-Anwendungen (Line of Business), Webanwendungen und Datenbanken der mittleren Stufe, die nicht die Leistung von Hyperdisk Extreme erfordern.

    Mit Hyperdisk Balanced-Volumes können Sie die Kapazität, die IOPS und den Durchsatz für Ihre Arbeitslasten dynamisch optimieren.

  • Hyperdisk Extrem

    Hyperdisk Extreme bietet den schnellsten verfügbaren Blockspeicher. Sie eignet sich für High-End-Arbeitslasten, die den höchsten Durchsatz und die höchsten IOPS benötigen.

    Mit Hyperdisk Extreme-Volumes können Sie die Kapazität und IOPS für Ihre Arbeitslasten dynamisch optimieren.

  • Hyperdisk Durchsatz

    Hyperdisk Throughput eignet sich gut für Analysen mit horizontaler Skalierung, einschließlich Hadoop und Kafka, Datenlaufwerke für kostenempfindliche Anwendungen und kalter Speicher.

    Mit Hyperdisk Throughput-Volumes können Sie die Kapazität und den Durchsatz für Ihre Arbeitslasten dynamisch optimieren. Sie können das bereitgestellte Durchsatzniveau ohne Ausfallzeiten oder Unterbrechung Ihrer Arbeitslasten ändern.

Hyperdisk-Volumes werden wie Persistent Disk erstellt und verwaltet. Sie haben jedoch die Möglichkeit, die bereitgestellte IOPS oder den Durchsatz festzulegen und diesen Wert jederzeit zu ändern. Es gibt keinen direkten Migrationspfad von Persistent Disk zu Hyperdisk. Stattdessen können Sie einen Snapshot erstellen und den Snapshot auf einem neuen Hyperdisk-Volume wiederherstellen.

Weitere Informationen zu Hyperdisk finden Sie unter Informationen zu Hyperdisks.

Langlebigkeit von Hyperdisk

Die Langlebigkeit des Laufwerks stellt die Wahrscheinlichkeit eines Datenverlusts für ein typisches Laufwerk in einem typischen Jahr dar. Die Langlebigkeit wird anhand einer Reihe von Annahmen über Hardwarefehler berechnet, z. B.:

  • Wahrscheinlichkeit katastrophaler Ereignisse
  • Isolationspraktiken
  • Technische Prozesse in Google-Rechenzentren
  • Die internen Codierungen, die von den einzelnen Laufwerkstypen verwendet werden

Hyperdisk-Datenverlustereignisse sind extrem selten. Google unternimmt außerdem zahlreiche Schritte, um das branchenweite Risiko der schleichenden Datenbeschädigung zu minimieren.

Menschliche Fehler eines Google Cloud-Kunden, z. B. wenn ein Kunde versehentlich ein Laufwerk löscht, fallen nicht unter die Langlebigkeit von Hyperdisk.

Die folgende Tabelle zeigt die Langlebigkeit für die einzelnen Laufwerkstypen. Eine Langlebigkeit von 99,999 % bedeutet, dass bei 1.000 Laufwerken wahrscheinlich 100 Jahre vergehen, ohne dass ein einzelnes Laufwerk verloren geht.

Hyperdisk abgestimmt Hyperdisk Extrem Hyperdisk Durchsatz
Besser als 99,999 % Besser als Besser als 99,9999 % Besser als 99,999 %

Hyperdisk-Verschlüsselung

Compute Engine verschlüsselt Ihre Daten automatisch, wenn auf ein Hyperdisk-Volume geschrieben wird.

Hyperdisk-Speicherpools

Mit Hyperdisk-Speicherpools können Sie die Gesamtbetriebskosten (TCO) Ihres Blockspeichers senken und die Blockspeicherverwaltung vereinfachen. Mit Speicherpools können Sie einen Pool von datenreduzierter Kapazität mit Thin Provisioning auf maximal 1.000 Laufwerke in einem einzelnen Projekt teilen. Mit Speicherpools können Sie eine höhere Effizienz erreichen und die Migration Ihres lokalen SAN zur Cloud vereinfachen. Gleichzeitig können Sie Ihren Arbeitslasten die erforderliche Kapazität geben.

Sie erstellen einen Speicherpool mit der geschätzten Kapazität für alle Arbeitslasten in einem Projekt in einer bestimmten Zone. Anschließend erstellen Sie Laufwerke in diesem Speicherpool und hängen die Laufwerke an vorhandene VMs an. Sie können auch ein Laufwerk im Speicherpool als Teil einer neuen VM erstellen. Jeder Speicherpool enthält einen Laufwerkstyp, z. B. Hyperdisk Throughput. Es gibt zwei Arten von Hyperdisk-Speicherpools:

  • Hyperdisk Balanced-Speicherpool
  • Hyperdisk Throughput-Speicherpool

Kapazitätsbereitstellungsoptionen

Hyperdisk-Speicherpoolkapazität kann auf zwei Arten bereitgestellt werden:

Standardbereitstellung von Kapazitäten
Bei der Standardbereitstellung der Kapazität erstellen Sie Laufwerke im Speicherpool, bis die Gesamtgröße aller Laufwerke die bereitgestellte Kapazität des Speicherpools erreicht. Die Laufwerke in einem Speicherpool mit Standardbereitstellung für Kapazitäten verbrauchen ähnlich wie Nicht-Pool-Laufwerke Kapazitäten, bei denen beim Erstellen der Laufwerke Kapazität verbraucht wird.
Erweiterte Kapazitätsbereitstellung

Mit der erweiterten Kapazitätsbereitstellung können Sie einen Pool von Thin Provisioning und datenreduzierter Speicherkapazität für alle Laufwerke in einem Speicherpool gemeinsam nutzen. Ihnen wird die bereitgestellte Kapazität des Speicherpools in Rechnung gestellt.

Sie können bis zu 500% der bereitgestellten Kapazität des Speicherpools auf Laufwerken in einem Speicherpool mit erweiterter Kapazität bereitstellen. Nur die Datenmenge, die auf ein Laufwerk im Speicherpool geschrieben wird, verbraucht Speicherpoolkapazität. Die automatische Datenreduzierung kann den Verbrauch der Speicherpoolkapazität noch weiter reduzieren.

Wenn die Kapazitätsauslastung eines erweiterten Speicherpools 80% der bereitgestellten Kapazität erreicht, versuchen Hyperdisk-Speicherpools, automatisch Kapazität zum Speicherpool hinzuzufügen, um Fehler im Zusammenhang mit unzureichender Kapazität zu vermeiden.

Beispiel

Angenommen, Sie haben einen Speicherpool mit einer bereitgestellten Kapazität von 10 TiB.

Mit Standardbereitstellung der Kapazität:

  • Sie können bis zu 10 TiB Gesamt-Hyperdisk-Kapazität bereitstellen, wenn Sie Laufwerke im Speicherpool erstellen. Ihnen werden die 10 TiB an bereitgestellten Kapazität des Speicherpools in Rechnung gestellt.
  • Wenn Sie im Speicherpool ein einzelnes Laufwerk mit einer Größe von 5 TiB erstellen und 2 TiB auf das Laufwerk schreiben, beträgt die genutzte Kapazität des Speicherpools 5 TiB.

Mit erweiterter Kapazitätsbereitstellung:

  • Sie können bis zu 50 TiB Gesamt-Hyperdisk-Kapazität bereitstellen, wenn Sie Laufwerke im Speicherpool erstellen. Ihnen werden die 10 TiB an bereitgestellten Kapazität des Speicherpools in Rechnung gestellt.
  • Wenn Sie im Speicherpool ein einzelnes Laufwerk mit einer Größe von 5 TiB erstellen, schreiben Sie 3 TiB Daten auf das Laufwerk. Die Datenreduzierung reduziert die Menge der geschriebenen Daten auf 2 TiB, die verwendete Kapazität des Speicherpools beträgt 2 TiB.

Bereitgestellte Kapazität und Leistung des Hyperdisk-Speicherpools ändern

Sie können die bereitgestellte Kapazität, die IOPS und den Durchsatz für Ihren Speicherpool erhöhen oder verringern, wenn Ihre Arbeitslasten skaliert werden. Mit einem erweiterten Speicherpool steht jede zusätzliche Kapazität oder Leistung für alle vorhandenen und neuen Laufwerke im Speicherpool zur Verfügung. Wenn Ihr Speicherpool mit erweiterter Kapazität 80% der verwendeten Kapazität des Speicherpools erreicht, versuchen Hyperdisk-Speicherpools außerdem, automatisch weitere Kapazität hinzuzufügen.

Weitere Informationen zum Hyperdisk-Speicherpool

Informationen zur Verwendung von Hyperdisk-Speicherpools finden Sie unter den folgenden Links:

Lokale SSDs

Lokale SSD-Laufwerke sind direkt mit dem Server verbunden, auf dem Ihre VM gehostet wird. Sie haben einen höheren Durchsatz und eine geringere Latenz als Standard-Persistent Disk oder SSD-Persistent Disk. Die auf einer lokalen SSD abgelegten Daten sind nicht länger zugänglich, wenn die VM angehalten oder gelöscht wird. Sie können je nach Anzahl der vCPUs mehrere lokale SSD-Laufwerke an Ihre VM anhängen.

Die Größe jedes lokalen SSD-Laufwerks beträgt unveränderlich 375 GiB, mit Ausnahme von Z3-VMs, die ein lokales SSD-Laufwerk mit einer Größe von 3 TiB verwenden. Für mehr Speicherplatz fügen Sie der VM beim Erstellen der VM mehrere lokale SSD-Laufwerke hinzu. Die maximale Anzahl lokaler SSD-Laufwerke, die Sie an eine VM anhängen können, hängt vom Maschinentyp und der Anzahl der verwendeten vCPUs ab.

Datenpersistenz auf lokalen SSD-Laufwerken

Lesen Sie Persistenz lokaler SSD-Daten, um zu erfahren, welche Ereignisse dafür sorgen, dass Ihre Daten auf der lokalen SSD erhalten bleiben, und welche zur Folge haben, dass diese Daten unwiederbringlich verloren gehen.

Lokale SSDs und Maschinentypen

Sie können lokale SSD-Laufwerke an die meisten in Compute Engine verfügbaren Maschinentypen anhängen, wie in der Vergleichstabelle für Maschinenserien gezeigt. Je nach Maschinentyp bestehen jedoch Einschränkungen hinsichtlich der Anzahl der lokalen SSD-Laufwerke, die zugeordnet werden können: Weitere Informationen finden Sie unter Gültige Anzahl lokaler SSD-Laufwerke auswählen.

Kapazitätslimits mit lokalen SSD-Laufwerken

Die maximale Kapazität von lokalen SSD-Laufwerken, die für eine VM verfügbar ist, ist:

Maschinentyp Größe des lokalen SSD-Laufwerks Anzahl der Laufwerke Maximale Kapazität
Z3 3 TiB 12 36 TiB
c3d-standard-360-lssd 375 GiB 32 12 TiB
c3d-highmem-360-lssd 375 GiB 32 12 TiB
c3-standard-176-lssd 375 GiB 32 12 TiB
N1, N2 und N2D 375 GiB 24 9 TiB
N1, N2 und N2D 375 GiB 16 6 TiB
A3 375 GiB 16 6 TiB
C2, C2D, A2-Standard, M1 und M3 375 GiB 8 3 TiB
A2-Ultra 375 GiB 8 3 TiB

Einschränkungen lokaler SSD-Laufwerke

Für lokale SSDs gelten folgende Einschränkungen:

  • Verwenden Sie eine VM-Instanz mit 32 oder mehr vCPUs, um maximale IOPS-Werte zu erreichen.
  • Lokale SSD-Laufwerke können nicht an VMs mit Maschinentypen mit gemeinsam genutztem Kern angehängt werden.
  • Sie können keine lokalen SSD-Laufwerke an N4-, H3-, M2 E2- und Tau T2A-Maschinentypen anhängen.
  • Sie können keine vom Kunden bereitgestellten Verschlüsselungsschlüssel mit einem lokalen SSD-Laufwerk verwenden. Compute Engine verschlüsselt Ihre Daten automatisch, wenn diese auf eine lokale SSD geschrieben werden.

Leistung

Lokale SSD-Laufwerke bieten sehr hohe IOPS und eine niedrige Latenz. Im Gegensatz zu Persistent Disk müssen Sie das Striping auf lokalen SSD-Laufwerken selbst verwalten.

Die Leistung lokaler SSDs hängt von mehreren Faktoren ab. Weitere Informationen finden Sie unter Leistung lokaler SSDs und Leistung lokaler SSDs optimieren.

Cloud Storage-Buckets

Cloud Storage-Buckets sind die flexibelste, skalierbarste und langlebigste Speicheroption für VMs. Wenn Ihre Anwendungen die geringere Latenz des nichtflüchtigen Speichers und der lokalen SSDs nicht benötigen, können Sie Ihre Daten in einem Cloud Storage-Bucket speichern.

Verbinden Sie Ihre VM mit einem Cloud Storage-Bucket, wenn Latenz und Durchsatz keine hohe Priorität haben und es darum geht, Daten ohne viel Aufwand zwischen mehreren VMs oder Zonen freizugeben.

Attribute von Cloud Storage-Buckets

In den folgenden Abschnitten erhalten Sie Informationen zum Verhalten und zu den Eigenschaften von Cloud Storage-Buckets.

Leistung

Die Leistung der Cloud Storage-Buckets hängt von der gewählten Speicherklasse und der Zone des Buckets im Verhältnis zur VM ab.

Die Nutzung der Standard Storage-Klasse von Cloud Storage am selben Standort wie die VM erzielt eine Leistung, die mit Persistent Disk vergleichbar ist, jedoch mit höherer Latenz und weniger konsistenten Durchsatzmerkmalen. Mit der Standard Storage-Klasse in einer Dual-Region werden Ihre Daten redundant in zwei Regionen gespeichert. Für eine optimale Leistung bei Verwendung einer Dual-Region sollten sich Ihre VMs in einer der Regionen befinden, die Teil der Dual-Region ist.

Die Klassen Nearline Storage, Coldline Storage und Archive Storage eignen sich vor allem für die langfristige Datenarchivierung. Im Gegensatz zur Standard Storage-Klasse haben diese Klassen eine Mindestspeicherdauer und es fallen Kosten für den Datenabruf an. Daher sind sie für die langfristige Speicherung selten abgerufener Daten geeignet.

Zuverlässigkeit

Alle Cloud Storage-Buckets haben eine integrierte Redundanz, um ihre Daten vor Geräteausfällen zu schützen und die Verfügbarkeit der Daten während Wartungsarbeiten im Rechenzentrum aufrechtzuerhalten. Für alle Cloud Storage-Vorgänge werden Prüfsummen berechnet, um dafür zu sorgen, dass die gelesenen Daten mit den geschriebenen Daten übereinstimmen.

Flexibilität

Im Gegensatz zu Persistent Disk sind Cloud Storage-Buckets nicht auf die Zone beschränkt, in der sich Ihre VM befindet. Außerdem können Daten von mehreren VMs gleichzeitig auf einem Bucket gelesen und geschrieben werden. Konfigurieren Sie zum Beispiel VMs in mehreren Zonen so, dass sie Daten im selben Bucket lesen und schreiben, anstatt diese auf Persistent Disk in mehreren Zonen zu replizieren.

Cloud Storage-Verschlüsselung

Compute Engine verschlüsselt Ihre Daten automatisch, bevor diese von der VM an Cloud Storage-Buckets übertragen werden. Sie müssen Dateien auf Ihren VMs nicht verschlüsseln, bevor Sie sie in einen Bucket schreiben.

Buckets können Sie genauso wie Persistent Disk-Volumes mit eigenen Verschlüsselungsschlüsseln verschlüsseln.

Daten in Google Cloud Storage-Buckets schreiben und daraus lesen

Verwenden Sie zum Schreiben und Lesen von Dateien aus Cloud Storage-Buckets das gcloud storage-Befehlszeilentool oder eine Cloud Storage-Clientbibliothek.

gcloud-Speicher

Das gcloud storage-Befehlszeilentool ist standardmäßig auf den meisten VMs installiert, die öffentliche Images verwenden. Wenn Ihre VM nicht das gcloud storage-Befehlszeilentool hat, können Sie es installieren.

  1. Stellen Sie eine Verbindung zu Ihren Linux-VMs her oder stellen Sie eine Verbindung zu Ihren Windows-VMs her oder verwenden Sie SSH oder eine andere Verbindungsmethode.

    1. In the Google Cloud console, go to the VM instances page.

      Go to VM instances

    2. In the list of virtual machine instances, click SSH in the row of the instance that you want to connect to.

      SSH button next to instance name.

  2. Wenn Sie auf dieser VM noch nie gcloud storage genutzt haben, verwenden Sie die gcloud CLI, um die Anmeldedaten einzurichten.

    gcloud init

    Wenn die VM für die Verwendung eines Dienstkontos mit einem Cloud Storage-Bereich konfiguriert ist, können Sie diesen Schritt auch überspringen.

  3. Mit dem gcloud storage-Tool können Sie einen Bucket erstellen, Daten in Buckets schreiben und Daten aus diesen Buckets lesen. Wenn Sie Daten in einen bestimmten Bucket schreiben oder daraus lesen möchten, müssen Sie Zugriff auf den Bucket haben. Sie können Daten aus öffentlich zugänglichen Buckets lesen.

    Optional können Sie Daten auch zu Cloud Storage streamen.

Clientbibliothek

Wenn die VM für die Verwendung eines Dienstkontos mit einem Cloud Storage-Bereich konfiguriert ist, können Sie zum Lesen und Schreiben von Daten in Cloud Storage-Buckets die Cloud Storage API verwenden.

  1. Stellen Sie eine Verbindung zu einer VM her.

    1. In the Google Cloud console, go to the VM instances page.

      Go to VM instances

    2. In the list of virtual machine instances, click SSH in the row of the instance that you want to connect to.

      SSH button next to instance name.

  2. Installieren und konfigurieren Sie eine Clientbibliothek für Ihre bevorzugte Sprache.

  3. Folgen Sie bei Bedarf den Codebeispielen, um auf der VM einen Cloud Storage-Bucket zu erstellen.

  4. Verwenden Sie die Codebeispiele zum Schreiben von Daten und zum Lesen von Daten und fügen Sie Code in die Anwendung ein, mit dem eine Datei in einen Cloud Storage-Bucket geschrieben oder daraus gelesen wird.

Nächste Schritte