In diesem Leitfaden wird gezeigt, wie Sie die Speicheranforderungen Ihrer Cloud-Arbeitslast ermitteln, wie die verfügbaren Speicheroptionen in Google Cloud genutzt werden können und wie Sie eine Speicherstrategie für einen optimalen Geschäftswert entwickeln.
Eine visuelle Zusammenfassung der wichtigsten Designempfehlungen finden Sie im Entscheidungsbaumdiagramm.
Wenn Sie diesen Leitfaden bereits gelesen haben und eine Zusammenfassung der Änderungen benötigen, finden Sie weitere Informationen im Abschnitt Änderungslog.
Übersicht über den Designprozess
Wenn Sie als Cloud-Architekt den Speicher für eine Cloud-Arbeitslast planen, müssen Sie als Erstes die funktionalen Eigenschaften der Arbeitslast, Sicherheitsbeschränkungen, Anforderungen für die Ausfallsicherheit sowie Leistungs- und Kostenziele ermitteln. Danach prüfen Sie die verfügbaren Speicherdienste und Features in Google Cloud. Schließlich wählen Sie je nach Ihren Anforderungen und den verfügbaren Optionen die benötigten Speicherdienste und -Features aus.
Das folgende Diagramm zeigt diesen dreistufigen Prozess:
Anforderungen definieren
Verwenden Sie die Fragebögen in diesem Abschnitt, um die zentralen Speicheranforderungen der Arbeitslast zu definieren, die Sie in Google Cloud bereitstellen möchten.
Richtlinien für das Definieren von Speicheranforderungen
Beim Beantworten der Fragebögen sind folgende Leitlinien zu beachten:
Anforderungen detailliert definieren
Wenn Ihre Anwendung beispielsweise Dateispeicher des Netzwerkdateisystems (NFS) benötigt, ermitteln Sie die erforderliche NFS-Version.
Künftige Anforderungen berücksichtigen
Beispielsweise kann es sein, dass eine aktuelle Bereitstellung für Nutzer in asiatischen Ländern später auf Unternehmen anderer Kontinente ausgeweitet werden soll. In diesem Fall sollten Sie bereits alle speicherbezogenen behördlichen Anforderungen der neuen Geschäftsgebiete berücksichtigen.
Cloudspezifische Möglichkeiten und Anforderungen berücksichtigen
Nutzen Sie die cloudspezifischen Möglichkeiten.
Zur Optimierung der Speicherkosten für in Cloud Storage gespeicherte Daten können Sie beispielsweise die Speicherdauer mithilfe von Datenaufbewahrungsrichtlinien und Lebenszykluskonfigurationen steuern.
Berücksichtigen Sie cloudspezifische Anforderungen.
Wenn beispielsweise die lokalen Daten in einem einzigen Rechenzentrum gespeichert sind, müssen Sie eventuell die migrierten Daten für eine Redundanz auf zwei Google Cloud-Standorte replizieren.
Fragebögen
Die folgenden Fragebögen sind nicht als fertige Checklisten für die Planung zu verstehen. Verwenden Sie sie als Ausgangspunkt, um alle Speicheranforderungen der Arbeitslast, die Sie in Google Cloud bereitstellen möchten, systematisch zu analysieren.
Eigenschaften der Arbeitslast bewerten
Welche Art von Daten müssen Sie speichern?
Beispiele
- Inhalt der statischen Website
- Sicherungen und Archive zur Notfallwiederherstellung
- Audit-Logs für die Compliance
- Große Datenobjekte, die Nutzer direkt herunterladen
- Transaktionsdaten
- Unstrukturierte und heterogene Daten
Wie viel Kapazität benötigen Sie? Berücksichtigen Sie Ihre aktuellen und zukünftigen Anforderungen.
Soll die Kapazität mit der Nutzung automatisch skaliert werden?
Welche Zugriffsanforderungen gelten? Sollen die Daten beispielsweise außerhalb von Google Cloud zugänglich sein?
Was sind die erwarteten Lese-/Schreibmuster?
Beispiele
- Häufige Schreib- und Lesevorgänge
- Häufige Schreibvorgänge, aber gelegentliche Lesevorgänge
- Gelegentliche Schreib- und Lesevorgänge
- Gelegentliche Schreibvorgänge, aber häufige Lesevorgänge
Erfordert die Arbeitslast dateibasierten Zugriff, zum Beispiel mit NFS?
Sollen mehrere Clients gleichzeitig Daten lesen oder schreiben?
Sicherheitsbeschränkungen ermitteln
Welche Anforderungen gelten für die Datenverschlüsselung? Verwenden Sie beispielsweise Schlüssel, die Sie selbst steuern?
Gibt es Anforderungen an die Datenausfallsicherheit?
Anforderungen an die Datenausfallsicherheit definieren
- Benötigt Ihre Arbeitslast Caching oder temporären Speicher mit niedriger Latenz?
- Müssen Sie die Daten in der Cloud aus Gründen der Redundanz replizieren?
- Benötigen Sie strikte Lese-/Schreibkonsistenz für replizierte Datasets?
Leistungserwartungen festlegen
Wie hoch ist der erforderliche E/A-Rate?
Welchen Grad an Lese- und Schreibdurchsatz benötigt Ihre Anwendung?
Für welche Umgebungen ist Speicher erforderlich? Für eine bestimmte Arbeitslast benötigen Sie möglicherweise einen Hochleistungsspeicher für die Produktionsumgebung, können aber für die Nicht-Produktionsumgebung eine Option mit geringerer Leistung auswählen.
Speicheroptionen prüfen
Google Cloud bietet Speicherdienste für alle wichtigen Speicherformate: Block, Datei und Objekt. Prüfen Sie die Features, Designoptionen und relativen Vorteile der Dienste für jedes Speicherformat und evaluieren Sie sie.
Übersicht
Blockspeicher
Die Daten, die Sie im Blockspeicher speichern, werden in Einheiten unterteilt, die als jeweils separater Block mit einer eindeutigen Adresse gespeichert werden. Anwendungen greifen dann auf Daten durch Verweis auf die entsprechenden Blockadressen zu. Der Blockspeicher ist für Arbeitslasten mit hoher IOPS-Anzahl, z. B. für die Transaktionsverarbeitung, optimiert. Er ist mit dem lokalen Storage Area Network (SAN) und DAS-Systemen (Directly Attached Storage) vergleichbar.
Die Blockspeicheroptionen in Google Cloud sind Teil des Compute Engine-Dienstes.
| Wahltaste | Überblick |
|---|---|
| Persistent Disk | Dedizierte Festplattenlaufwerke (HDDs) und Solid-State-Laufwerke (SSDs) für Unternehmens- und Datenbankanwendungen, die in Compute Engine-VMs und Google Kubernetes Engine-Clustern (GKE) bereitgestellt werden. |
| Google Cloud-Hyperdisk | Schneller und redundanter Netzwerkspeicher für Compute Engine-VMs mit konfigurierbarer Leistung und konfigurierbaren Volumes, deren Größe dynamisch angepasst werden kann. |
| Local SSD | Sitzungsspezifischer, lokal angehängter Blockspeicher für Hochleistungsanwendungen. |
Dateispeicher
Daten werden wie bei einem lokalen NAS-Speicher (Network Attached Storage) in einer Hierarchie von Dateien organisiert und dargestellt. Dateisysteme können auf Clients mit Protokollen wie NFS und Server Message Block (SMB) bereitgestellt werden. Anwendungen greifen dabei über den entsprechenden Dateinamen und den Verzeichnispfad auf Daten zu.
Google Cloud bietet eine Reihe von vollständig verwalteten Lösungen sowie Lösungen von Drittanbietern zum Speichern von Dateien.
| Lösung | Überblick |
|---|---|
| Google Cloud Filestore |
NFSv3-Dateiserver für Compute Engine-VMs und Google Kubernetes Engine-Cluster. Sie können eine Dienststufe (Basic, High Scale oder Enterprise) auswählen, die zu Ihrem Anwendungsfall passt. |
| Google Cloud NetApp Volumes | Dateibasierter Speicher mit NFSv3, NFSv4.1 oder SMB. |
| Weitere Optionen | Informationen dazu finden Sie unter Zusammenfassung der Dateiserveroptionen. |
Objektspeicher
Die Daten werden als Objekte in einer flachen Hierarchie von Buckets gespeichert. Jedem Objekt wird eine global eindeutige ID zugewiesen. Objekte können vom System zugewiesene sowie benutzerdefinierte Metadaten haben, mit denen sich Daten organisieren und verwalten lassen. Anwendungen greifen auf Daten mithilfe von REST APIs oder Clientbibliotheken über den Verweis auf Objekt-IDs zu. Der Objektspeicher ist mit dem lokalen SAN in Bezug auf die Skalierbarkeit vergleichbar. Er ist aber einfacher zu verwalten und günstiger.
Cloud Storage bietet einen kostengünstigen, langlebigen und unbegrenzten Objektspeicher für verschiedene Datentypen. Die in Cloud Storage gespeicherten Daten können von jedem Standort innerhalb und außerhalb von Google Cloud aufgerufen werden. Optionale Redundanz in allen Regionen bietet maximale Zuverlässigkeit. Sie können die Speicherklasse auswählen, die Ihren Anforderungen an die Datenaufbewahrung und die Zugriffshäufigkeit entspricht.
Vergleichsanalyse
Die folgende Tabelle bietet eine Vergleichsanalyse der wichtigsten Funktionen der Speicherdienste in Google Cloud.
| Persistent Disk | Hyperdisk | Lokale SSD | Filestore | Google Cloud NetApp Volumes | Cloud Storage | |
|---|---|---|---|---|---|---|
| Kapazität |
10 GiB bis 64 TiB pro Laufwerk 257 TiB pro VM |
4 GiB bis 64 TiB pro Laufwerk 512 TiB pro VM |
375 GiB pro Laufwerk 12 TiB pro VM |
1–100 TiB pro Filestore-Instanz (die minimale und maximale Kapazität und die Skalierungsschritte variieren je nach Dienststufe) | 2–500 TiB pro Speicherpool 100 GiB bis 100 TiB pro Volume |
Keine Unter- oder Obergrenze |
|
Skalierung |
|
Leistung und Kapazität dynamisch skalieren | Nicht skalierbar |
|
Hoch- und Herunterskalieren | Automatische Skalierung nach Nutzung |
| Freigabe |
Eingeschränkte Freigabe
|
Kann nicht freigegeben werden | Kann nicht freigegeben werden | Kann auf mehreren Compute Engine-VMs, Remote-Clients und GKE-Clustern bereitgestellt werden | Kann auf mehreren Compute Engine-VMs und in mehreren GKE-Clustern bereitgestellt werden |
|
| Verschlüsselungsschlüssel |
Von Google verwaltete, vom Kunden verwaltete oder vom Kunden bereitgestellte Schlüssel | Von Google verwaltete, vom Kunden verwaltete oder vom Kunden bereitgestellte Schlüssel | Von Google verwaltete Schlüssel |
|
Von Google oder vom Kunden verwaltete Schlüssel | Von Google verwaltete, vom Kunden verwaltete oder vom Kunden bereitgestellte Schlüssel |
| Persistenz |
Lebensdauer des Laufwerks | Lebensdauer des Laufwerks | Sitzungsspezifisch (Daten bleiben erhalten, bis die VM beendet oder gelöscht wird) | Lebensdauer der Filestore-Instanz | Lebensdauer des Volumes | Lebensdauer des Buckets |
| Verfügbarkeit |
|
Zonal | Zonal |
|
| |
| Leistung |
Lineare Skalierung einer hohen Leistung anhand der Laufwerksgröße und der CPU-Anzahl | Dynamisch skalierbarer, nichtflüchtiger Hochleistungsspeicher | Scratch-Hochleistungsspeicher | Skalierbare Leistung Erwartungen hängen vom Service Level ab |
Lese-/Schreibraten automatisch skalieren und dynamische Lastumverteilung | |
| Verwaltung |
Manuell formatieren und bereitstellen | Manuell formatieren und bereitstellen | Manuell formatieren, streifen und bereitstellen | Vollständig verwaltet | Vollständig verwaltet | Vollständig verwaltet |
| Arbeitslasten |
|
|
|
|
|
|
Speicheroption auswählen
Für das Auswählen einer Speicheroption sind zwei Schritte erforderlich:
- Sie ermitteln, welche Speicherdienste Sie benötigen.
- Sie wählen die erforderlichen Features und Designoptionen in einem bestimmten Dienst aus.
Beispiele für dienstspezifische Features und Designoptionen
Persistent Disk
- Region und Zone der Bereitstellung
- Regionale Replikation
- Typ, Größe und IOPS des Laufwerks (für extrem nichtflüchtige Speicher)
- Verschlüsselungsschlüssel: von Google oder vom Kunden verwaltet bzw. vom Kunden bereitgestellt
- Zeitplan für Snapshots
Hyperdisk
- Bereitstellungszone
- Typ, Größe und IOPS des Laufwerks
- Verschlüsselungsschlüssel: von Google oder vom Kunden verwaltet bzw. vom Kunden bereitgestellt
- Zeitplan für Snapshots
Filestore
- Region und Zone der Bereitstellung
- Instanzstufe
- Kapazität
- IP-Bereich: automatisch zugewiesen oder benutzerdefiniert
- Zugriffssteuerung
NetApp-Volumes
- Bereitstellungsregion
- Service Level für den Speicherpool
- Pool- und Volume-Kapazität
- Volume-Protokoll
- Regeln für den Volume-Export
Cloud Storage
- Standort: multiregional, Dual-Region, einzelne Region
- Speicherklasse: Standard, Nearline, Coldline, Archive
- Zugriffssteuerung: einheitlich oder detailliert
- Verschlüsselungsschlüssel: von Google oder vom Kunden verwaltet bzw. vom Kunden bereitgestellt
- Aufbewahrungsrichtlinien
Speicherempfehlungen
Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt für die Auswahl der Speicherdienste und Features, die Ihren Anforderungen entsprechen. Diese Empfehlungen werden weiter unten in diesem Dokument auch als Entscheidungsbaum dargestellt.
Wählen Sie für Anwendungen, die dateibasierten Zugriff benötigen, basierend auf Ihren Anforderungen für Zugriffsprotokoll, Verfügbarkeit und Leistung einen geeigneten Dateispeicherdienst aus.
Zugriffsprotokoll Empfehlung NFSv3 - Wenn Sie regionale Verfügbarkeit benötigen, verwenden Sie Filestore Enterprise.
- Wenn zonale Verfügbarkeit ausreicht, Sie aber eine hohe Leistung benötigen, verwenden Sie Filestore Zonal.
- Verwenden Sie andernfalls entweder Filestore Basic oder NetApp Volumes.
Weitere Informationen zu den Unterschieden zwischen den Filestore-Dienststufen finden Sie unter Dienststufen.
SMB oder NFSv4.1 Verwenden Sie NetApp Volumes. Verwenden Sie für Arbeitslasten, die primären Speicher mit hoher Leistung benötigen, je nach Ihren Anforderungen lokale SSDs, nichtflüchtige Speicher oder Hyperdisks.
Anforderung Empfehlung Schnelle Scratch Disk oder Cache Verwenden Sie lokale SSD-Laufwerke (sitzungsspezifisch).
Sequenzielle IOPS Verwenden Sie nichtflüchtige Speicher mit dem Laufwerkstyp pd-standard.IOPS-intensive Arbeitslast Verwenden Sie nichtflüchtige Speicher mit dem Laufwerkstyp pd-extremeoderpd-ssd.Ausgewogenheit zwischen Leistung und Kosten Verwenden Sie nichtflüchtige Speicher mit dem Laufwerkstyp pd-balanced.Skalierbare Leistung und Kapazität (dynamisch) Verwenden Sie eine Hyperdisk.
Wählen Sie einen geeigneten Hyperdisk-Typ aus:
- Hyperdisk Throughput wird für Analysen mit Hochskalierung, Datenlaufwerke für kostenempfindliche Anwendungen und kalten Datenspeicher empfohlen.
- Hyperdisk Extreme wird für Arbeitslasten empfohlen, die einen hohen E/A-Wert erfordern, z. B. Hochleistungs-Datenbanken.
- Wählen Sie je nach Redundanzanforderungen zwischen zonalen und regionalen Laufwerken aus.
Eine detaillierte Vergleichsanalyse finden Sie unter Optionen für nichtflüchtigen Speicher.Anforderung Empfehlung Redundanz innerhalb einer einzelnen Zone in einer Region Verwenden Sie zonale nichtflüchtige Speicher oder Hyperdisks. Redundanz für mehrere Zonen innerhalb einer Region Verwenden Sie regionale nichtflüchtige Speicher.
Verwenden Sie Cloud Storage, wenn Sie einen unbegrenzt skalierbaren, global verfügbaren Speicher benötigen.
Wählen Sie je nach Datenzugriffshäufigkeit und Speicherdauer eine geeignete Cloud Storage-Klasse aus.
Anforderung Empfehlung Die Zugriffshäufigkeit variiert oder die Datenaufbewahrungsdauer ist unbekannt oder ist nicht vorhersehbar. Verwenden Sie das Feature Autoclass, um Objekte in einem Bucket basierend auf dem Zugriffsmuster jedes Objekts automatisch auf die entsprechenden Speicherklassen zu übertragen. Speicher für Daten, auf die häufig zugegriffen wird, z. B. für Datenanalysen mit hohem Durchsatz, Data Lakes, Websites, gestreamte Videos und mobile Apps. Verwenden Sie die Speicherklasse Standard.
Verwenden Sie Cloud CDN, um häufig aufgerufene Daten im Cache zu speichern und von Standorten aus bereitzustellen, die sich in der Nähe der Clients befinden.
Kostengünstiger Speicher für selten aufgerufene Daten, die mindestens 30 Tage gespeichert werden können, z. B. Sicherungen und Longtail-Multimedia-Inhalte. Verwenden Sie die Speicherklasse Nearline. Kostengünstiger Speicher für selten aufgerufene Daten, die mindestens 90 Tage gespeichert werden können, z. B. für die Notfallwiederherstellung. Verwenden Sie die Speicherklasse Coldline. Kostengünstigster Speicher für selten aufgerufene Daten, die mindestens 365 Tage gespeichert werden können, z. B. für zur Einhaltung behördlicher Auflagen angelegte Archive. Verwenden Sie die Speicherklasse Archive. Eine detaillierte Vergleichsanalyse finden Sie unter Cloud Storage-Klassen.
Datenübertragungsoptionen
Nachdem Sie die entsprechenden Google Cloud-Speicherdienste ausgewählt haben, müssen Sie zum Bereitstellen und Ausführen von Arbeitslasten Ihre Daten in Google Cloud übertragen. Die Daten, die Sie übertragen müssen, können lokal oder auf anderen Cloud-Plattformen gespeichert sein.
Mit den folgenden Methoden können Sie Daten an Google Cloud übertragen:
- Daten online übertragen mit Storage Transfer Service: Automatisieren Sie die Übertragung großer Datenmengen zwischen Objekt- und Dateispeichersystemen, einschließlich Cloud Storage, Amazon S3, Azure-Speicherdiensten und lokalen Datenquellen.
- Daten mit Transfer Appliance offline übertragen: Übertragen und laden Sie große Datenmengen offline in Google Cloud, wenn Netzwerkverbindung und Bandbreite nicht verfügbar, begrenzt oder teuer sind.
- Daten in Cloud Storage hochladen: Laden Sie Daten mithilfe der Google Cloud Console, der gcloud CLI, Cloud Storage APIs oder Clientbibliotheken online in Cloud Storage-Buckets hoch.
Berücksichtigen Sie bei der Auswahl einer Datenübertragungsmethode Faktoren wie Datengröße, Zeitbeschränkungen, Bandbreitenverfügbarkeit, Kostenziele sowie Sicherheits- und Compliance-Anforderungen. Weitere Informationen zum Planen und Implementieren von Datenübertragungen zu Google Cloud finden Sie unter Zu Google Cloud migrieren: Große Datasets übertragen.
Entscheidungsbaum für Speicheroptionen
Das folgende Entscheidungsbaumdiagramm führt Sie durch die zuvor beschriebenen Google Cloud-Speicherempfehlungen:
Nächste Schritte
- Berechnen Sie eine Schätzung der Speicherkosten mit dem Google Cloud-Preisrechner.
- Erfahren Sie mehr über Best Practices zum Erstellen einer Cloud-Topologie, die für Sicherheit, Robustheit, Kosten und Leistung optimiert ist.
- Erfahren Sie mehr über die Unterschiede zwischen Objekt-, Block- und Dateispeicher in Google Cloud (Video)
- Parallele Dateisysteme wie Lustre für HPC-Arbeitslasten verwenden
Änderungsprotokoll
In diesem Abschnitt werden die wichtigsten technischen Änderungen in diesem Leitfaden zusammengefasst.
| Datum | Beschreibung der Änderungen |
|---|---|
| 14. März 2024 | Der Abschnitt Datenübertragungsoptionen wurde hinzugefügt. |
| 08. Dezember 2023 | Die Kapazitätsnummern für Hyperdisk und lokale SSD wurden aktualisiert. |
| 17. Oktober 2023 | Die Speicherempfehlungen und das Entscheidungsbaumdiagramm wurden aktualisiert, um Google Cloud NetApp Volumes als Option für die NFSv3-Dateispeicherung aufzunehmen. |
| 25. August 2023 |
|
| 6. Oktober 2021 | Anleitung für Filestore Enterprise hinzugefügt. |
| 20. August 2021 | Erste Veröffentlichung. |
Beitragende
Autor: Kumar Dhanagopal | Cross-product Solution Developer
Weitere Beitragende:
- Brennan Doyle | Solutions Architect
- Dean Hildebrand Technical Director, Office of the CTO
- Geoffrey Noer | Group Product Manager
- Jack Zhou | Technical Writer
- Jason Wu | Director, Product Management
- Jeff Allen | Solutions Architect
- Sean Derrington | Group Outbound Product Manager, Speicher