Hohe Verfügbarkeit und Speicherausfallsicherheit
Ausfallsicherheit durch vorausschauende Planung
Verfügbarkeit bedeutet die Fähigkeit, einen Dienst aufrechtzuerhalten. Ausfallsicherheit bedeutet die Fähigkeit, Fehler zu absorbieren und sich zu erholen. Replikation, Snapshots und Backups schützen verschiedene Aspekte dieses Ziels – und keines davon ersetzt die anderen
Ein ausfallsicherer Speicherdienst benötigt vier Arbeitsschichten:
ANWENDUNGS- ODER BENUTZERDIENST
PFADENetzwerk und Initiatoren
STEUERUNGBesitz und Failover
DATENKopien und Integrität
WIEDERHERSTELLUNGVerlauf und Neustart
Der Dienst übersteht nur die Ausfälle, die das Gesamtdesign tolerieren kann
Failover ≠ BackupEin zweiter Controller bietet keine Wiederherstellung des Verlaufs
Replikation ≠ NullverlustRPO hängt vom synchronen oder asynchronen Verhalten ab
Quorum verhindert MehrdeutigkeitEine Partition darf nicht zwei unabhängige Eigentümer erzeugen
Tests beweisen das DesignWiederherstellungsziele sind Ansprüche, bis ein Fehler auftritt
Trennen Sie die Ziele
Vier Begriffe beschreiben vier verschiedene Verantwortlichkeiten
Eine klare Architektur beginnt mit der Definition dessen, was online bleiben muss, wie viele Daten verloren gehen dürfen und wie schnell ein nutzbarer Dienst wiederhergestellt sein muss
VERFÜGBARKEIT
Stellen Sie sicher, dass der Dienst erreichbar ist
Redundante Komponenten und kontrolliertes Failover reduzieren Unterbrechungen, wenn ein Pfad, Controller oder Knoten ausfälltAusfallsicherheit
Fehler absorbieren und beheben
Das System behält einen gültigen Zustand bei, isoliert Fehler und stellt den Schutz nach der Rückkehr oder dem Austausch von Komponenten wieder herDatenschutz
Wiederherstellbare Historie erhalten
Snapshots, Aufbewahrung und unabhängige Kopien bieten Ansatzpunkte zur Wiederherstellung nach Löschung, Beschädigung oder unerwünschter ÄnderungNotfallwiederherstellung
Wiederherstellung an einer anderen Grenze
Ein separates System oder ein separater Standort, ein Betriebsablauf und verifizierte Abhängigkeiten ermöglichen die Wiederherstellung des Dienstes nach einem umfassenderen Ereignis
Hohe Verfügbarkeit schützt in der Regel vor Ausfallzeiten, nicht vor fehlerhaften Schreibvorgängen Die synchrone Replikation kann versehentliches Löschen oder Beschädigen von Daten sofort kopieren. Historische und unabhängige Wiederherstellungspunkte sind weiterhin erforderlich
Geschäftsziele
RPO und RTO wandeln Risiko in Architektur um
Wiederherstellungspunktziel (RPO) beschreibt die akzeptable Datenlücke nach der Wiederherstellung Wiederherstellungszeitziel (RTO) beschreibt die Zielzeit für die Wiederherstellung eines nutzbaren Dienstes
- Ein RPO-Wert nahe Null erfordert im Allgemeinen, dass bestätigte Schreibvorgänge mehr als eine Fehlerdomäne erreichen
- Eine asynchrone Replik hat einen RPO-Wert, der durch Zeitplan, Verzögerung und die letzte erfolgreiche Übertragung bestimmt wird
- RTO umfasst Erkennung, Besitzverwaltung, Dienststart, Validierung und Anwendungswiederherstellung
- Unterschiedliche Workloads auf derselben Plattform können unterschiedliche Ziele erfordern
RPO
RTO
Kürzere Ziele erfordern in der Regel eine engere Kopplung, redundantere Infrastruktur und häufigere Tests. Die Grafik ist konzeptionell; die tatsächlichen Werte sind in der Servicebeschreibung des Kunden enthalten
Architekturmuster
Wählen Sie das Ausfallmodell vor der Produktauswahl
Jedes Muster schützt eine andere Grenze und erzeugt unterschiedliche Abhängigkeiten
MUSTER 1
Standalone-Speicher plus asynchrone Replik
Primärer Speicher
und aktive Dienste
→
Asynchrone
Replik und Snapshots
- Erstellt kein automatisches Failover des lokalen Controllers
- RPO folgt dem letzten abgeschlossenen Replikationspunkt
- Aktivierung, Netzwerk- und Anwendungsabhängigkeiten erfordern ein Runbook
MUSTER 2
Synchrones Spiegeln mit zwei Knoten
Knoten A
Aktiver Dienst
⇄
Knoten B
Synchrones Spiegeln
- Ausgelegt für eine sehr geringe Datenlücke bei bestätigten Schreibvorgängen
- Die Latenz zwischen den Knoten beeinflusst den synchronen Schreibpfad
- Quorum, Fencing und Netzwerktrennung müssen ein Split-Brain-Szenario verhindern
Muster 3
Gemeinsamer Speicher mit zwei Controllern
Controller A
Dienstinhaber
⇄
Controller B
Gemeinsame Datenpfade
- Controller-Redundanz und Speicherpfad-Redundanz sind getrennt
- Das gemeinsame Gehäuse, die Verkabelung und die Stromversorgung bleiben kritisch
- Die Wiederherstellung historischer Daten erfordert weiterhin Snapshots oder separate Kopien
MUSTER 4
Verteilter Ceph-Speicher
Clients und
Service-Endpunkte
→
Verteilte Knoten
und Ausfalldomänen
- Keine feste Zwei-Knoten-Grenze
- Verfügbarkeit hängt von Quorum und ausreichend Datenfragmenten ab
- Wiederherstellung und Lastausgleich beanspruchen Netzwerk- und Geräteressourcen
Vergleichsmatrix
Verfügbarkeitsmodelle wägen Kopplung, Wiederherstellung und Skalierung ab
| Architektur | Automatisches lokales Failover | Typischer Datenpunkt | Wiederherstellungsverhalten | Primäre Abhängigkeit | Bester Startpunkt |
|---|---|---|---|---|---|
| Standalone + asynchrone Replik | Nein – nicht allein durch Replikation | Letzter abgeschlossener Snapshot oder Replikationszyklus | Sekundären Dienst aktivieren und Abhängigkeiten prüfen | Replikationszeitplan, Zielintegrität und Runbook | Kostenbewusste Notfallwiederherstellung und Standorttrennung |
| Synchrones Spiegeln auf zwei Knoten | Ja, mit einem korrekt konzipierten Cluster | Abgeschlossene Schreibvorgänge werden auf beiden Knoten gespeichert | Dienstverantwortung wird an den überlebenden Knoten übertragen | Latenz zwischen Knoten, Quorum, Fencing und redundante Netzwerke | Kompakte HA mit unabhängigem Serverspeicher |
| Gemeinsamer Speicher mit zwei Controllern | Ja | Beide Controller adressieren dieselben gemeinsam genutzten Daten | Dienstverantwortung wird übertragen, solange die gemeinsam genutzte Kapazität verfügbar bleibt | Gemeinsames Gehäuse, redundante Pfade, Verkabelung und Stromversorgung | Traditionelle Speicherarchitektur mit zwei Controllern |
| Verteiltes Ceph | Der Dienst bleibt verfügbar, solange Quorum- und Schutzregeln erfüllt sind | Zugesicherte Daten werden gemäß der Poolrichtlinie verteilt | Der Clusterbetrieb wird fortgesetzt und der Schutz wird wiederhergestellt oder neu ausbalanciert | Knotenanzahl, Ausfallbereichsdesign, Quorum, Netzwerk und freie Kapazität | Scale-out-Dienste und größere Ausfallbereiche |
| Backup oder unveränderliche Kopie | Nein | Ausgewählter historischer Wiederherstellungspunkt | Daten wiederherstellen und anschließend den Anwendungsdienst wiederherstellen | Kopieunabhängigkeit, Aufbewahrung, Anmeldeinformationen und getestete Wiederherstellung | Wiederherstellung nach Löschung, Beschädigung und Ransomware |
Dies sind architektonische Merkmale, keine garantierten Zeitangaben. RPO und RTO müssen für das gesamte Kundendesign, einschließlich Hosts, Netzwerke, Anwendungen und Betriebsreaktion, gemessen werden
Netzwerkpartitionen
Split Brain ist ein Entscheidungsfehler – nicht nur ein Verbindungsabbruch
Wenn zwei Knoten die Kommunikation verlieren, aber beide aktiv bleiben, könnte jeder fälschlicherweise annehmen, er sei für den Dienst zuständig. Ein Cluster benötigt daher einen autoritativen EntscheidungsmechanismusKNOTEN ODER STANDORT A
QUORUM · ZEUGEN · FENCING
KNOTEN ODER STANDORT B
- Das Quorum bestimmt, welche Seite fortfahren darf
- Der Zeuge oder Tiebreaker kann eine zusätzliche Stimme abgeben, wenn die Architektur dies erfordert
- Fencing verhindert, dass ein ausgefallener Knoten weiterhin auf geschützte Ressourcen zugreift
Die Implementierung variiert je nach Plattform. Validieren Sie die unterstützte Topologie, anstatt einen improvisierten Zeugen hinzuzufügen oder Sicherheitsmechanismen zu deaktivieren
Ausfallbereiche
Redundanz muss die Grenze überschreiten, die ausfallen kann
Eine zweite Festplatte im selben Gehäuse schützt nicht vor Gehäuseausfall. Ein zweiter Knoten am selben Switch schützt nicht vor Switch-Ausfall. Platzierung und Abhängigkeiten müssen dem Geschäftsbedrohungsmodell entsprechen
GERÄT
Laufwerk, HBA, NIC oder Kabel
KNOTEN
Controller oder vollständiger Server
RACK / POWER
Gemeinsamer Switch, PDU oder Kühlung
STANDORT
Gebäude-, Verbindungs- oder regionales Ereignis
Betriebsnachweis
Testausfälle auf Serviceebene
Ein grünes Dashboard beweist nicht, dass Anwendungen weiterhin funktionieren. Testen Sie das Ereignis, beobachten Sie den Client und validieren Sie die Daten nach der Wiederherstellung
Pfadausfall
Trennen Sie einen zugelassenen Netzwerk- oder Speicherpfad und überprüfen Sie das Clientverhalten, die Latenz und die Wiederherstellung
Controller- oder Knotenausfall
Validieren Sie Eigentumsübertragung, Dienststart, Mount-Persistenz und Anwendungs-E/A
Netzwerkpartitionierung
Stellen Sie sicher, dass nur die autorisierte Seite weiterläuft und die betroffene Seite sicher isoliert ist
Neustart des vollständigen Dienstes
Überprüfen Sie Abhängigkeiten wie DNS, Verzeichnisdienste, Zertifikate, Lizenzen und Routing
Replikataktivierung
Messen Sie den tatsächlichen Datenpunkt, den Aktivierungsvorgang und die Zeit bis zur Einsatzbereitschaft der Anwendungen
Historische Wiederherstellung
Stellen Sie Dateien oder Anwendungsdaten von einem bekannten Zeitpunkt wieder her und überprüfen Sie die Konsistenz – nicht nur die Lesbarkeit
Implementierungsbeispiele
Die Plattformen euroNAS decken unterschiedliche Resilienzgrenzen ab
Die Produkte sind Beispiele für die oben genannten Architekturmuster. Die Auswahl sollte sich nach der erforderlichen Ausfalldomäne, den Wiederherstellungszielen und dem Betriebsmodell richten
| Plattform | Primäres Betriebsmodell | Verfügbarkeits- und Schutzfunktion | Skalierungsgrenze | Wichtige Unterscheidung |
|---|---|---|---|---|
| euroNAS Premium | Eigenständiges Speicherbetriebssystem für einen Server, einschließlich Virtual Storage Appliance-Bereitstellung | Snapshots und asynchrone Replikation können Wiederherstellungspunkte und eine separate DR-Kopie bereitstellen | Skalierung innerhalb des ausgewählten Servers | Replikation allein macht den Standalone-Server nicht automatisch zu einem lokalen HA-Paar |
| euroNAS HA Cluster | Zwei-Knoten-Speicherarchitektur | Automatisches Service-Failover mittels synchronem Mirroring oder eines Shared-Storage-Modells | Skalierung innerhalb des Zwei-Knoten-HA-Designs | Asynchrone Replikation bleibt eine separate DR-Option, nicht das synchrone Mirroring |
| eEKAS | Verteilter Ceph Scale-Out-Speicher | Datenschutz und Dienstverfügbarkeit über mehrere Knoten hinweg unter Verwendung der ausgewählten Pool- und Ausfalldomänenrichtlinie | Hinzufügen qualifizierter Speicherknoten ohne feste Beschränkung auf zwei Knoten | Quorum, Netzwerkdesign, freie Kapazität und das Schutzprofil bestimmen tolerierte Ausfälle |
| eEVOS | Virtualisierungsplattform | Compute und VM-Verfügbarkeit plus integriertes Backup & Disaster Recovery, einschließlich Instant-Recovery-Workflows | Hinzufügen von Rechenknoten und Verwendung von internem oder qualifiziertem externem Speicher gemäß der Architektur | VM-Verfügbarkeit und historische VM-Wiederherstellung sind separate Ziele und müssen beide getestet werden |
STANDALONE + DR
euroNAS Premium
Eigenständiger Speicher mit Snapshots und asynchronen Replikationsoptionen Premium-Details →Zwei-Knoten-HA
HA Cluster
Synchrone Spiegelung oder gemeinsam genutzte Speicherarchitektur mit automatischem Service-Failover HA Cluster Details →Scale-Out
eEKAS
Verteilter Ceph-Speicher mit definierten Schutzprofilen und Ausfalldomänen eEKAS Details →VM-Verfügbarkeit + Wiederherstellung
eEVOS
Virtualisierung mit integriertem Backup & Disaster Recovery und Instant Recovery Details zu eEVOS →Architektur weiterentwickeln
Ausfallsicherheit mit Speicher- und Virtualisierungsdesign verknüpfen
Primäre Referenzen
Technische Hinweise zu Wiederherstellung und verteiltem Speicher
Produktunterstützung, Betriebsverhalten und empfohlene Topologien können sich im Laufe der Zeit ändern. Validieren Sie das gesamte Design anhand der aktuellen Dokumentation