11 Min. Lesezeit

Lernziele

Am Ende dieses Moduls werden Sie in der Lage sein:

  • Einzelne VM Block Storage von gemanagtem gemeinsamem Dateizugriff zu unterscheiden und zwischen ihnen aufgrund des Zugriffsmusters und nicht der Kapazität zu wählen
  • Eine Speicherebene ihrer Workload zuzuordnen und über die Asymmetrie zwischen Speicherzone und Rechenzone als Platzierungsbeschränkung nachzudenken
  • Eine Network File Storage Cluster und einen gemeinsamen Speicherplatz im Data Center Designer bereitzustellen und diesen von mehreren Linux-Clients aus zu mounten
  • Zu erkennen, wo der gemeinsame Dateispeicher endet (regional, privat, Linux-only) und wo Object Storage die Funktion übernimmt

Einheit 5.1: Block- und Dateispeicher

Einführung

Die Datenebene beginnt mit einer Entscheidung, die leicht falsch interpretiert werden kann: Wer benötigt Lese- und Schreibzugriff auf die gleichen Bytes. Ein Block Storage Volume ist eine private Festplatte, die genau einem Server zur gleichen Zeit gehört; es ist die richtige Antwort für eine Boot-Festplatte oder die Daten einer einzelnen Anwendung, und Einheit 4.2 hat bereits die Anbindung einer solchen Festplatte behandelt. Im Moment, an dem zwei oder mehr Maschinen die gleichen Dateien gleichzeitig sehen müssen, bricht dieses Modell zusammen, und die Plattform bietet stattdessen ein separates gemanagtes Produkt, Network File Storage, anstelle eines Shared-Block-Tricks. Diese Einheit zieht diese Grenze, bringt eine Platzierungsasymmetrie ans Licht, die Architekten aus dem Konzept bringt, und baut dann den gemeinsamen Dateifreigabe-Server, den die Anwendungsebene von FinCorp benötigt.

1. Einzelnes VM Block Storage im Vergleich zu gemanagtem Shared-File-Zugriff

Block Storage stellt ein iSCSI-Blockgerät für eine virtuelle Maschine bereit. Sie binden es, das Gast-Betriebssystem formatiert es und es verhält sich wie eine lokale Festplatte. Diese Festplatte ist an ihren Server gebunden: sie ist kein Medium für gleichzeitigen Zugriff und es werden keine Bytes zwischen Maschinen übertragen. Für die persistente Daten eines einzelnen Anwendungsprogramms ist dies genau das, was Sie wollen, und es ist der Ort, an dem die meisten Kapazitäten der Datenebene leben.

Network File Storage löst das andere Problem eines Dateisystems, das von vielen Clients gleichzeitig gemountet wird. Es ist ein gemanagtes Produkt: IONOS betreibt ein Cluster von zwei Speicher-Servern in einer aktiven-passiven Hochverfügbarkeitsanordnung auf der Diensteschicht, exportiert die Daten über NFSv4.2 und Sie mounten es von Ihren virtuellen Maschinen. Die Clients sehen ein gemeinsames POSIX-Dateisystem; die Zuverlässigkeit, der Failover zwischen den beiden Servern und das zugrunde liegende ZFS-Dateisystem werden für Sie betrieben. NFSv3 wird nicht unterstützt, also planen Sie für NFSv4.2-Clients.

Die beiden Produkte unterscheiden sich auch in der Leistungsabgabe. Network File Storage basiert auf der Block Storage SSD-Standardleistungsklasse, sodass ein Share das Verhalten der SSD-Klasse erbt, aber sein Schreibpfad durch die synchrone Schreibverzögerung von etwa 20 ms begrenzt wird. Um eine hohe aggregierte Schreib-IOPS zu erreichen, sind daher viele gleichzeitige Schreiber erforderlich und die Standard-NFS-Client-RPC-Slot-Tabelle (typischerweise 64 bis 128) kann zur Decke werden, bevor der Speicher erreicht wird. Die dokumentierte Anleitung ist ausdrücklich, dass es nicht für synchrone Schreibworkloads mit engen Zeitlimiten geeignet ist. Lesen Sie es als gemeinsames Dateispeicher für Assets, Benutzerverzeichnisse, Protokolle und Sicherungszonen, nicht als niedriglatente Transaktionsfestplatte. Ein weiterer struktureller Faktor ist wichtig bei der Entwurfszeit: die Größe eines Cluster wird in TiB mit einem Slider gewählt, das Minimum beträgt 2 TiB, das Maximum 42 TiB und die Größe kann nach der Bereitstellung nicht verringert werden, sodass es ein einwegiger Ratchets nach oben ist.

Die folgende Tabelle aus der Produkt-Dokumentation listet die Anwendungsfälle auf, für die Network File Storage entwickelt wurde:

Anwendungsfall Was es abdeckt
Gemeinsame Konfigurationsdateien, Vorlagen und statische Assets über mehrere virtuelle Maschinen in einem VDC Eine kanonische Kopie anstelle von Duplikationen pro Instanz
Medien-Server / Content-Delivery-Ursprung Bilder, Videos und Medien, die ohne Duplikation pro Instanz bereitgestellt werden
Sicherungsziel für Datenbanken, Anwendungsdaten und VM-Sicherungen Ein gemeinsames Zielverzeichnis mit Verschlüsselung auf REST-Ebene
Protokoll-Aggregation von mehreren virtuellen Maschinen in ein einzelnes gemeinsames Verzeichnis Zentrale Protokolle von vielen Maschinen
Kubernetes ReadWriteMany (RWX) persistente Volumes Gemeinsame Volumes für Container-Workloads

Für FinCorp läuft die Anwendungsebene mehrere zustandslose virtuelle Maschinen hinter einem Load Balancer und sie benötigen ein gemeinsames Verzeichnis für hochgeladene Dokumente und gemeinsame Vorlagen. Das ist genau die erste Zeile oben: ein einzelnes Share, das von jedem Anwendungs-Node les- und schreibbar gemountet wird, anstelle einer Kopie der Assets, die in jedes VM-Bild gebacken wird.

1.1 Regionale und private Reichweite und wo Object Storage die Kontrolle übernimmt

Network File Storage ist regional und privat. Der Cluster ist mit einem Rechenzentrum LAN verbunden und erreichbar über eine private IPv4- oder IPv6-Adresse innerhalb dieses VDC; es gibt keinen öffentlichen Endpunkt und ein Share umfasst nicht mehrere Regionen. Clients mounten es über das private LAN, was den Datenverkehr vom Internet fernhält und bedeutet, dass der Datentransfer zu Ihren virtuellen Maschinen nicht berechnet wird. Der Kompromiss ist die Reichweite: wenn FinCorp die gleichen Daten in verschiedenen Regionen benötigt oder sie über S3-ähnliche Tools zugreifen möchte, ist das gemeinsame Dateisystem die falsche Ebene. Für gemeinsame Daten in verschiedenen Regionen greifen Sie besser auf Object Storage zurück (Einheit 5.2), das die geo-übergreifende, API-adressierbare Speicherung der Plattform ist. Wählen Sie Network File Storage, wenn viele Maschinen in einer Region ein aktives POSIX-Dateisystem benötigen; wählen Sie Object Storage, wenn Reichweite, Skalierbarkeit oder programmatischer Zugriff dominieren.

Der Zugriff ist auch Linux-nur und wird pro Share durch Client-Gruppen gesteuert. Jede Client-Gruppe verbindet eine IP-Netzwerksliste (die autorisierten privaten Netzwerke in CIDR-Notation) mit einem Squash-Modus, der remote-Root- und Benutzer auf eine anonyme Identität abbildet. Die IP-Netzwerkeinstellung hat immer Vorrang vor der Hosts-Liste und die Dokumentation empfiehlt aus Sicherheitsgründen gegen die no-squash-Option. Dies ist die Datei-Ebene-Äquivalent der privat-per-Default-Haltung, die die REST-Ebene der Architektur verfolgt.

2. Anpassung der Tier an das Zugriffsmuster und die Zonen-Asymmetrie

Die Entscheidung für eine Tier wird durch das Zugriffsmuster und nicht durch die Größe bestimmt. Eine Single-Writer-Persistenz-Disk für ein VM ist Block Storage. Ein Many-Reader-, Many-Writer-POSIX-Dateisystem innerhalb einer Region ist Network File Storage. Ein geo-übergreifendes, API-adressierbares Bulk- und Archiv ist Object Storage. Innerhalb von Block Storage tragen die SSD-Tiers eine Leistungsuntergrenze, die hier im Auge behalten werden sollte, da sie sich über die Datentier wiederholt: SSD-Volumen liefern erst ab 100 GiB und darüber volle Leistung pro GiB, so dass ein kleines SSD-Volume-Volumen unter seiner Tier-Leistung liegt. Diese Untergrundgrenze ist der Grund, warum zu kleine SSD-Volumen für anspruchsvolle Workloads nicht empfohlen werden, ein Punkt, zu dem Einheit 5.3 für Datenbanken zurückkehrt.

Es gibt eine Platzierungs-Asymmetrie, die Architekten, die von anderen Plattformen kommen, überrascht. Verfügbarkeitszonen sind nicht symmetrisch zwischen Rechenressourcen und Block Storage. Ein Block Storage-Volume kann in Zone 1, Zone 2, Zone 3 oder Auto platziert werden. Rechenressourcen bieten jedoch nur Zonen 1, 2 und Auto an: Es gibt keine Rechenzone 3. Die praktische Konsequenz ist, dass Sie keinen Server in eine "Zone 3" festlegen können, um eine Zone-3-Volume-Platzierung zu entsprechen, da keine solche Rechenzone existiert. Wenn Sie ein redundantes Paar absichtlich über Zonen verteilen, entwerfen Sie es um die Rechenrealität der Zonen 1 und 2 herum und nehmen Sie nicht an, dass eine Zone-3-Platzierung eines Volume Ihnen ein entsprechendes Rechen-Domäne kauft. Behandeln Sie die Zonen-Auswahl als eine explizite Entscheidung für jedes redundante Paar, anstatt es auf Auto zu setzen, was Ressourcen, die Sie trennen wollten, gemeinsam nutzen kann.

DCD Implementierung Schritt-für-Schritt

Diese Implementierung stellt die gemeinsame Dateispeicherung bereit, die die Anwendungsebene von FinCorp benötigt: ein Network File Storage Cluster auf der Anwendungs-LAN, ein Share und der Mount von mehreren Linux-Clients. Sie realisiert die Entscheidung aus Abschnitt 1, eine einzelne kanonische Kopie von gemeinsamen Assets beizubehalten, anstatt sie pro VM zu duplizieren. Die Voraussetzung ist ein bestehendes virtuelles Rechenzentrum mit einer privaten Anwendungs-LAN (erstellt in Einheit 3.1) und dem Zugriff und der Verwaltung von Network File Storage auf Ihre Gruppe; ohne dieses Privileg hat ein Benutzer nur Lesezugriff und kann keine Bereitstellung durchführen.

Ziel: Bereitstellung von gemeinsamer Dateispeicherung, die von mehreren Clients gemountet wird.

Schritte (im Data Center Designer):

  1. Im DCD öffnen Sie Menü > Speicher & Sicherung > Network File Storage, dann wählen Sie Cluster erstellen.
  2. Definieren Sie die Eigenschaften von Cluster: Geben Sie einen Namen für Cluster ein; wählen Sie den Standort (den Serverstandort, an dem Cluster gespeichert wird); setzen Sie die Größe in TiB mit dem Slider, wobei Sie sich an die Mindestgröße von 2 TiB erinnern und dass die Größe später nicht reduziert werden kann; lassen Sie die Dateisystemversion auf dem Standardwert NFSv4.2.
  3. Ordnen Sie Cluster einem Rechenzentrum zu: Wählen Sie das Rechenzentrum (die Auswahlmöglichkeiten hängen von dem gewählten Standort ab) und die Anwendungs-LAN des Rechenzentrums, die die private Anwendungs-LAN sein muss. Geben Sie eine private IPv4- (oder IPv6-) Adresse mit CIDR für Cluster ein, indem Sie das Panel "Ihre private IP finden" auf der rechten Seite verwenden, um eine kostenlose Adresse zu wählen, die nicht mit Ihrem DHCP-Bereich kollidiert.
  4. Klicken Sie auf Speichern. Cluster wird erstellt und wechselt in den Zustand "BUSY"; warten Sie, bis es "VERFÜGBAR" wird, bevor Sie Shares erstellen.
  5. Aus der Liste von Cluster wählen Sie "Shares verwalten" aus der Spalte "OPTIONEN" (oder öffnen Sie Cluster und verwenden Sie die Registerkarte "Shares verwalten"), dann wählen Sie "Share erstellen".
  6. Definieren Sie die Eigenschaften des Shares: Geben Sie einen Verzeichnisnamen ein; setzen Sie optional eine Quota in MiB, um den Share zu begrenzen (setzen Sie Null, um die Quota zu deaktivieren); setzen Sie optional die Gruppen-ID und die Benutzer-ID, die beide standardmäßig auf 65534 gesetzt sind.
  7. Fügen Sie eine Client-Gruppe hinzu: Geben Sie optional eine Beschreibung ein; wählen Sie einen NFS-Squash-Modus (die empfohlene Grundkonfiguration ist die Zuordnung von Root zu anonym; vermeiden Sie "kein Squash"); unter IP-Netzwerken fügen Sie das autorisierte private Netzwerk in CIDR-Notation hinzu (z. B. das Subnetz der Anwendungs-LAN), damit nur diese Clients den Share mounten können.
  8. Klicken Sie auf Speichern, um den Share zu erstellen.
  9. Auf jedem Linux-Client mounten Sie den Share mithilfe der privaten IP von Cluster und der Share-UUID: mount -t nfs <cluster-ip>:<share-uuid> <local-mount-path>. Jede Anwendungs-VM, die den gleichen Cluster-IP und die UUID mountet, sieht nun die gleichen Dateien.

Häufige Fehler:

  • Überdimensionierung von Cluster am ersten Tag. Die Größe kann nur erhöht werden; Sie können sie nicht reduzieren, also beginnen Sie mit der tatsächlichen Anforderung über der Mindestgröße von 2 TiB und erhöhen Sie sie bei Bedarf.
  • Das Squash-Modus auf "Kein Squash" setzen. Die Dokumentation rät davon ab; ordnen Sie stattdessen Root (oder alle Benutzer) der anonymen Identität zu.
  • Vergessen, dass IP-Netzwerke die Hosts-Liste ersetzen. Wenn der Zugriff falsch ist, überprüfen Sie zuerst die IP-Netzwerke CIDR, da diese immer Vorrang haben.
  • Annahme, dass NFSv3 funktioniert. Nur NFSv4.2 wird unterstützt; ältere Clients können den Share nicht mounten.
  • Erwartung, dass der Share über Regionen oder öffentlich zugänglich ist. Der Share ist privat und regional; wenn Sie eines dieser beiden benötigen, verwenden Sie Object Storage und nicht einen breiteren NFS-Export.
  • Versuch, von Windows aus zu mounten. Die Client-Unterstützung ist auf Linux-Only beschränkt.
  • Auswahl von Network File Storage für eine synchronisierte Schreiboperation mit kurzer Zeit. Die Latenz von etwa 20 ms für synchronisierte Schreiboperationen und die pro-Mount-RPC-Slot-Decke machen es ungeeignet; diese Daten gehören auf ein Block Storage Volume, das an die einzelne VM angehängt ist, die es besitzt.

Zusammenfassung

Block Storage ist eine private, einzelne VM iSCSI-Disk; Network File Storage ist ein gemanagtes, regionales, privates NFSv4.2-Dateisystem, das viele Linux-Clients gleichzeitig mounten; Object Storage ist der geo-übergreifende, API-adressierbare Speicher. Die Ebene folgt dem Zugriffsmuster, nicht der Kapazität, und eine bewusste Zonenwahl ist wichtig, da Block Storage Zone 3 bietet, während der Compute-Bereich dies nicht tut. Die stateless-Anwendungsebene von FinCorp erhält einen gemeinsamen Share für ihre Assets, der für das Wachstum dimensioniert und auf die Anwendung LAN beschränkt ist.

Wichtige Punkte:

  • Block Storage = eine VM, private Disk (Anbindung in 4.2 behandelt); Network File Storage = viele Linux-Clients, ein regionales privates Dateisystem; Object Storage = cross-region, API-adressierbar.
  • Network File Storage ist nur NFSv4.2 (kein NFSv3), Linux-only, basierend auf der SSD-Standardklasse, mit einer ~20 ms synchronen Schreibfläche; es ist keine low-latency-Transaktionsdisk.
  • Ein Cluster ist zwischen 2 und 42 TiB groß und kann nach der Bereitstellung nicht verkleinert werden; der Zugriff wird durch Client-Gruppen gesteuert, bei denen die IP-Netzwerke-Liste immer der Hosts-Liste vorgezogen wird.
  • Die Verfügbarkeitszonen von Block Storage sind 1, 2, 3 und Auto; die Compute-Zonen sind nur 1, 2 und Auto. Es gibt keine Compute-Zone 3, daher sollten für jedes redundante Paar explizite Zonen festgelegt werden, anstatt auf Auto zu vertrauen.

Wichtige Begriffe:

  • Cluster (Network File Storage): die gemanagte, zweiserverige, aktive-passive Einheit, die Sie bereitstellen und in TiB dimensionieren; sie enthält einen oder mehrere Shares und bindet an einen einzelnen Rechenzentrum LAN.
  • Share: ein einzelnes exportiertes Dateisystem innerhalb eines Cluster, mit seinem eigenen Kontingent, Besitzer-IDs und Client-Gruppen; mehrere Shares können in einem Cluster leben.
  • Squash-Modus: die Zuordnung von Remote-Root oder allen Benutzern zu einer anonymen Identität (Standard-UID/GID 65534), die einschränkt, was ein mountender Client als privilegierter Benutzer tun kann.