Einheit 5.1: Block- und Dateispeicher

Einführung

Die Datenebene beginnt mit einer Entscheidung, die leicht falsch getroffen werden kann: Wer muss dieselben Bytes lesen und schreiben? Ein Block Storage Volume ist eine private Festplatte, die sich zu einem Zeitpunkt genau einem Server zuordnet. Sie ist die richtige Lösung für eine Boot-Disk oder die Daten einer einzelnen Anwendung, und Einheit 4.2 hat bereits das Anbinden eines solchen Volumes behandelt. Sobald zwei oder mehr Maschinen dieselben Dateien gleichzeitig sehen müssen, bricht dieses Modell zusammen, und die Plattform bietet stattdessen ein separates verwaltetes Produkt, Network File Storage, an, anstelle eines Tricks mit gemeinsam genutztem Block-Speicher. Diese Einheit zieht diese Grenze, macht eine Platzierungsasymmetrie deutlich, die Architekt:innen häufig überrascht, und baut anschließend den gemeinsamen Dateifreigabe, den die Anwendungsebene von FinCorp benötigt.

1. Block Storage für eine einzelne VM im Vergleich zu verwaltetem, gemeinsam genutztem Datei-Zugriff

Block Storage stellt einer virtuellen Maschine ein iSCSI-Blockgerät bereit. Sie hängen es an, das Gast-Betriebssystem formatiert es, und es verhält sich wie eine lokale Festplatte. Diese Festplatte ist an ihren Server gebunden: Es handelt sich nicht um ein Medium für gleichzeitigen Zugriff, und es überträgt keine Daten zwischen Maschinen. Für persistente Daten einer einzelnen Anwendung ist dies genau das Gewünschte, und hier befindet sich der Großteil der Kapazität der Daten-Ebene.

Network File Storage löst das andere Problem, bei dem ein Dateisystem gleichzeitig von vielen Clients eingebunden wird. Es handelt sich um ein verwaltetes Produkt: IONOS CLOUD betreibt einen Cluster aus zwei Storage-Servern in einer aktiv-passiven Hochverfügbarkeitsanordnung auf der Service-Ebene, exportiert die Daten über NFSv4.2, und Sie hängen es von Ihren VMs aus ein. Die Clients sehen ein gemeinsam genutztes POSIX-Dateisystem; die Datensicherheit, das Failover zwischen den beiden Servern und das zugrunde liegende ZFS-Dateisystem werden für Sie betrieben. NFSv3 wird nicht unterstützt, daher ist die Planung ausschließlich für NFSv4.2-Clients erforderlich.

Die beiden Produkte unterscheiden sich auch in der Leistungserbringung. Network File Storage basiert auf der Block Storage SSD Standard-Leistungsklasse, sodass ein Share SSD-typisches Verhalten erbt, aber sein Schreibpfad durch eine synchrone Schreiblatenz von etwa 20 ms begrenzt wird. Um hohe aggregierte Schreib-IOPS zu erreichen, sind daher viele gleichzeitige Schreiber erforderlich, und die Standard-NFS-Client-RPC-Slot-Tabelle eines einzelnen Mounts (typischerweise 64 bis 128) kann zur Obergrenze werden, bevor die Storage-Ebene dies tut. Die dokumentierte Empfehlung ist eindeutig, dass es nicht für synchrone Schreibworkloads mit engen Timeout-Anforderungen geeignet ist. Betrachten Sie es als Speicher für gemeinsame Dateien für Assets, Home-Verzeichnisse, Protokolle und Sicherungs-Zielbereiche, nicht als eine Transaktionsfestplatte mit niedriger Latenz. Ein weiteres strukturelles Faktum ist bei der Planung wichtig: Die Größe eines Clusters wird in TiB über einen Schieberegler gewählt, das Minimum beträgt 2 TiB, das Maximum 42 TiB, und die Größe kann nach der Bereitstellung nicht verkleinert werden, sodass es sich um eine einseitige, nur nach oben gerichtete Rastentechnik handelt.

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

Für FinCorp läuft die Anwendungsebene mit mehreren zustandslosen VMs hinter einem Load Balancer, und sie benötigen ein gemeinsames Verzeichnis für hochgeladene Dokumente und gemeinsame Vorlagen. Genau das ist die erste Zeile oben: ein einzelner Share, der von jedem Anwendungsknoten schreib- und lesbar eingebunden wird, anstatt eine Kopie der Assets in jedes VM-Image einzubauen.

1.1 Regionale und private Reichweite, und wo Object Storage übernimmt

Network File Storage ist regional und privat. Der Cluster ist mit einem Rechenzentrum-LAN verbunden und über eine private IPv4- oder IPv6-Adresse innerhalb dieses VDC erreichbar; es gibt keinen öffentlichen Endpunkt, und ein Share erstreckt sich nicht über Regionen hinweg. Clients binden es über das private LAN ein, wodurch der Verkehr vom Internet ferngehalten wird und die Datenübertragung zu Ihren VMs nicht berechnet wird. Der Kompromiss ist die Reichweite: Wenn FinCorp dieselben Daten in verschiedenen Regionen verfügbar haben oder sie mit S3-artigen Werkzeugen zugänglich machen muss, ist das gemeinsame Dateisystem die falsche Ebene. Für gemeinsame Daten über Regionen hinweg ist stattdessen Object Storage (Einheit 5.2) die richtige Wahl, das geographisch übergreifende, per API adressierbare Speichermedium der Plattform. 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, Skalierung oder programmatischer Zugriff im Vordergrund stehen.

Der Zugriff ist auch nur für Linux verfügbar und wird pro Share über Client-Gruppen gesteuert. Jede Client-Gruppe kombiniert eine IP Networks-Liste (die autorisierten privaten Netzwerke, in CIDR-Notation) mit einem Squash-Modus, der entfernte Root- und Benutzerkonten auf eine anonyme Identität abbildet. Die IP Networks-Einstellung überschreibt immer die Hosts-Liste, und die Dokumentation empfiehlt aus Sicherheitsgründen gegen die no-squash-Option. Dies ist das Äquivalent auf der Dateiebene der standardmäßig privaten Haltung, der der Rest der Architektur folgt.

2. Zuordnung der Ebene zum Zugriffsmuster und die Zonenasymmetrie

Die Entscheidung über die Ebene wird durch das Zugriffsmuster bestimmt, nicht durch die Größe. Eine persistente Platte mit einem einzelnen Schreibzugriff für eine VM ist Block Storage. Ein POSIX-Dateisystem mit vielen Lesern und vielen Schreibern innerhalb einer Region ist Network File Storage. Bulk- und Archivdaten, die sich über Regionen erstrecken und über die API adressierbar sind, gehören zu Object Storage. Innerhalb von Block Storage weisen die SSD-Ebenen eine Leistungsgrenze auf, die hier beachtet werden sollte, da sie sich über die gesamte Datenebene hinweg wiederholt: SSD-Volumes liefern die volle Leistung pro GiB erst ab 100 GiB. Ein kleines SSD-Volumen unterhalb dieser Schwelle erreicht daher nicht die Leistung seiner Ebene. Genau aus diesem Grund wird von der Verwendung zu kleiner SSD-Volumes für anspruchsvolle Workloads abgeraten, ein Punkt, auf den Einheit 5.3 im Kontext von Datenbanken zurückkommt.

Es gibt eine Platzierungsasymmetrie, die Architekten, die von anderen Plattformen kommen, überraschen kann. Verfügbarkeitszonen sind zwischen Compute und Block Storage nicht symmetrisch. Ein Block Storage-Volumen kann in Zone 1, Zone 2, Zone 3 oder Auto platziert werden. Compute bietet hingegen nur die Zonen 1, 2 und Auto: Es gibt keine Compute-Zone 3. Die praktische Konsequenz ist, dass ein Server nicht in einer „Zone 3" verankert werden kann, um ein Volumen in Zone 3 zu spiegeln, da keine solche Compute-Zone existiert. Wenn Sie ein redundantes Paar bewusst über Zonen verteilen, sollten Sie die Compute-Realität der Zonen 1 und 2 berücksichtigen und nicht davon ausgehen, dass die Platzierung eines Volumes in Zone 3 eine entsprechende Compute-Domäne bereitstellt. Behandeln Sie die Zonenauswahl für jedes redundante Paar als eine explizite Entscheidung, statt sie auf Auto zu belassen, da Auto Ressourcen zusammenführen kann, die Sie getrennt halten wollten.

DCD-Implementierung: Schritt-für-Schritt-Anleitung

In dieser Anleitung wird der gemeinsam genutzte Dateispeicher provisioniert, den die Anwendungsschicht von FinCorp benötigt: ein Network File Storage-Cluster im Anwendungslan, ein Share und das Mounten von mehreren Linux-Clients. Sie setzt die Entscheidung aus Abschnitt 1 um, eine einzige kanonische Kopie der gemeinsam genutzten Assets zu verwenden, anstatt sie pro VM zu duplizieren. Voraussetzung ist ein vorhandenes VDC mit einem privaten Anwendungslan (angelegt in Einheit 3.1) sowie das Berechtigungsfeld „Access and Manage Network File Storage“ in Ihrer Gruppe; ohne diese Berechtigung hat ein Benutzer nur Lesezugriff und kann keine Ressourcen provisionieren.

Bauziel: Gemeinsamen Dateispeicher provisionieren, der von mehreren Clients gemountet wird.

Schritte (im Data Center Designer):

1. Öffnen Sie im DCD das Menü > Storage & Backup > Network File Storage und wählen Sie dann Create Cluster.
2. Definieren Sie die Cluster-Eigenschaften: Geben Sie einen Cluster Name ein; wählen Sie die Location (den Serverstandort, an dem der Cluster betrieben wird); setzen Sie die Size in TiB über den Regler, wobei Sie das Minimum von 2 TiB beachten und dass die Größe später nicht verkleinert werden kann; lassen Sie File System Version auf dem Standardwert NFSv4.2.
3. Verknüpfen Sie den Cluster mit einem Rechenzentrum: Wählen Sie das Datacenter (die Auswahlmöglichkeiten hängen von der gewählten Location ab) und das Datacenter LAN, welches das private Anwendungslan sein muss. Geben Sie eine private IPv4- (oder IPv6-)Adresse mit CIDR für den Cluster ein und nutzen Sie das Panel „Finding your Private IP“ rechts, um eine freie Adresse auszuwählen, die nicht mit Ihrem DHCP-Bereich kollidiert.
4. Klicken Sie auf Save. Der Cluster wird erstellt und wechselt in den Zustand BUSY; warten Sie, bis er den Zustand AVAILABLE erreicht, bevor Sie Shares erstellen.
5. Wählen Sie in der Clusterliste Manage Shares aus der Spalte OPTIONS (oder öffnen Sie den Cluster und verwenden Sie den Tab Manage Shares) und wählen Sie dann Create Share.
6. Definieren Sie die Share-Eigenschaften: Geben Sie einen Directory Name 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 zugehörige Group Id und User Id, beide standardmäßig 65534.
7. Fügen Sie eine Client-Gruppe hinzu: Fügen Sie optional eine Description hinzu; wählen Sie einen NFS Squash Mode (das Abbilden von root auf anonym ist die empfohlene Grundlage; vermeiden Sie no-squash); fügen Sie unter IP Networks das autorisierte private Netzwerk in CIDR-Notation hinzu (zum Beispiel das Subnetz des Anwendungslans), damit nur diese Clients mounten können.
8. Klicken Sie auf Save, um den Share zu erstellen.
9. Mounten Sie auf jedem Linux-Client den Share mit der privaten IP des Clusters und der Share-UUID: mount -t nfs <cluster-ip>:<share-uuid> <local-mount-path>. Jede Anwendungs-VM, die dieselbe Cluster-IP und dieselbe UUID mountet, sieht nun dieselben Dateien.

Häufige Fehler:

• Überdimensionierung des Clusters am ersten Tag. Die Größe kann nur erhöht, nicht verkleinert werden; starten Sie daher mit dem tatsächlichen Bedarf über dem Minimum von 2 TiB und erweitern Sie bei Bedarf.
• Der Squash Mode bleibt auf None. Die Dokumentation rät davon ab; stattdessen root (oder alle Benutzer) auf die anonyme Identität abbilden.
• Vergessen, dass IP Networks die Hosts-Liste ersetzt. Wenn der Zugriff falsch ist, prüfen Sie zuerst die CIDR in IP Networks, da diese immer Vorrang hat.
• Annahme, dass NFSv3 funktioniert. Nur NFSv4.2 wird unterstützt; ältere Clients können nicht mounten.
• Erwartung von Zugriff über Regionen hinweg oder öffentlichem Zugriff. Der Share ist privat und regional; falls Sie eines davon benötigen, verwenden Sie Object Storage, nicht einen breiteren NFS-Export.
• Versuch, von Windows aus zu mounten. Die Client-Unterstützung ist nur für Linux verfügbar.
• Auswahl von Network File Storage für eine Workload mit engen Timeouts und synchronen Schreibvorgängen. Die Synchronschreiblatenz von ca. 20 ms und die RPC-Slot-Obergrenze pro Mount machen es ungeeignet; diese Daten gehören auf ein Block Storage-Volumen, das an die einzelne VM angehängt ist, die sie besitzt.

Zusammenfassung

Block Storage ist eine private, an eine einzelne VM angebundene iSCSI-Festplatte; Network File Storage ist ein verwaltetes, regionales, privates NFSv4.2-Dateisystem, das von vielen Linux-Clients gleichzeitig eingehängt wird; Object Storage ist der ortsübergreifende, per API adressierbare Speicher. Die Schichtwahl richtet sich nach dem Zugriffsmuster, nicht nach der Kapazität, und eine bewusste Zonenauswahl ist wichtig, da Block Storage Zone 3 bietet, während Compute dies nicht tut. Die zustandslose Anwendungsschicht von FinCorp erhält ein gemeinsames Share für ihre Assets, dimensioniert für Wachstum und auf das AnwendungslAN beschränkt.

Wichtige Punkte:

• Block Storage = eine VM, private Festplatte (Anbindung in 4.2 behandelt); Network File Storage = viele Linux-Clients, ein regionales privates Dateisystem; Object Storage = ortsübergreifend, per API adressierbar.
• Network File Storage unterstützt ausschließlich NFSv4.2 (kein NFSv3), ist nur für Linux verfügbar, basiert auf der SSD Standard-Klasse und hat einen Mindestwert von ca. 20 ms für synchrone Schreibvorgänge; es handelt sich nicht um eine Transaktionsfestplatte mit niedriger Latenz.
• Ein Cluster wird mit 2 bis 42 TiB dimensioniert und kann nach der Bereitstellung nicht verkleinert werden; der Zugriff wird durch Client-Gruppen gesteuert, wobei die Liste IP Networks die Liste Hosts immer überschreibt.
• Die Verfügbarkeitszonen für Block Storage sind 1, 2, 3 und Auto; die Zonen für Compute sind nur 1, 2 und Auto. Es gibt keine Compute-Zone 3, daher sollten für redundante Paare explizite Zonen festgelegt werden, anstatt sich auf Auto zu verlassen.

Wichtige Begriffe:

• Cluster (Network File Storage): die verwaltete, zweiköpfige, aktiv-passive Einheit, die in TiB provisioniert und dimensioniert wird; sie enthält ein oder mehrere Shares und ist an ein einzelnes Rechenzentrum-LAN angebunden.
• Share: ein einzelnes exportiertes Dateisystem innerhalb eines Clusters, mit eigener Quota, eigenen Owner-IDs und eigenen Client-Gruppen; mehrere Shares können in einem Cluster existieren.
• Squash-Modus: die Zuordnung des entfernten root-Benutzers oder aller Benutzer zu einer anonymen Identität (Standard-UID/GID 65534), die begrenzt, was ein einhängender Client als privilegierter Benutzer tun kann.