Hallo Habr!

Es ist kein Geheimnis, dass riesige Datenmengen in die Arbeit moderner Anwendungen involviert sind und ihr Fluss ständig wächst. Diese Daten müssen gespeichert und verarbeitet werden, häufig von einer großen Anzahl von Maschinen, und dies ist keine leichte Aufgabe. Um dies zu lösen, gibt es Cloud-Objektspeicher. In der Regel handelt es sich um eine Implementierung der Software Defined Storage-Technologie.

Anfang 2018 haben wir unseren eigenen 100% S3-kompatiblen Speicher basierend auf Cloudian HyperStore gestartet (und gestartet!). Wie sich herausstellte, gibt es im Netzwerk nur sehr wenige russischsprachige Veröffentlichungen über Cloudian selbst und noch weniger über die tatsächliche Anwendung dieser Lösung.

Basierend auf den Erfahrungen von DataLine werde ich Ihnen heute die Architektur und die interne Struktur der Cloudian-Software erläutern, einschließlich der Cloudian SDS-Implementierung, die auf einer Reihe von Apache Cassandra-Architekturlösungen basiert. Unabhängig davon betrachten wir das interessanteste in jedem SDS-Speicher - die Logik der Gewährleistung der Fehlertoleranz und der Verteilung von Objekten.

Wenn Sie Ihren S3-Speicher erstellen oder gerade warten, ist dieser Artikel hilfreich für Sie.

Zunächst werde ich erklären, warum unsere Wahl auf Cloudian fiel. Es ist ganz einfach: In dieser Nische gibt es nur sehr wenige würdige Optionen. Zum Beispiel gab es vor ein paar Jahren, als wir nur daran dachten zu bauen, nur drei Möglichkeiten:

• CEHP + RADOS Gateway;
  
• Minio
  
• Cloudian HyperStore.
  

Für uns als Dienstleister waren die entscheidenden Faktoren: eine hohe Korrespondenz zwischen der Speicher-API und dem ursprünglichen Amazon S3, die Verfügbarkeit einer integrierten Abrechnung, Skalierbarkeit mit Unterstützung für mehrere Regionen und das Vorhandensein einer dritten Reihe von Anbietersupport. Cloudian hat das alles.

Und ja, das Wichtigste (sicherlich!) Ist, dass DataLine und Cloudian ähnliche Unternehmensfarben haben. Sie müssen zugeben, dass wir einer solchen Schönheit nicht widerstehen konnten.



Leider ist Cloudian nicht die am häufigsten verwendete Software, und in RuNet gibt es praktisch keine Informationen dazu. Heute werden wir diese Ungerechtigkeit korrigieren und mit Ihnen über die Funktionen der HyperStore-Architektur sprechen, ihre wichtigsten Komponenten untersuchen und uns mit den wichtigsten architektonischen Nuancen befassen. Beginnen wir mit dem Grundlegendsten: Was ist Cloudian unter der Haube?

Funktionsweise von Cloudian HyperStore Storage

Schauen wir uns das Diagramm an und sehen, wie die Cloudian-Lösung funktioniert.


Das Hauptkomponenten-Speicherschema.

Wie wir sehen können, besteht das System aus mehreren Hauptkomponenten:

• Cloudian Management Control - Verwaltungskonsole ;
• Admin Service - internes Verwaltungsmodul ;
• S3 Service - das Modul, das für die Unterstützung des S3-Protokolls verantwortlich ist ;
• HyperStore-Dienst - der eigentliche Speicherdienst ;
• Apache Cassandra - ein zentrales Repository für Servicedaten ;
• Redis - für die am häufigsten gelesenen Daten .

Von größtem Interesse für uns wird die Arbeit der Hauptdienste S3 Service und HyperStore Service sein, dann werden wir ihre Arbeit sorgfältig prüfen. Zunächst ist es jedoch sinnvoll herauszufinden, wie die Verteilung der Dienste im Cluster angeordnet ist und wie die Fehlertoleranz und Zuverlässigkeit der Datenspeicherung dieser Lösung insgesamt ist.




Mit allgemeinen Diensten in der obigen Abbildung meinen wir die Dienste S3, HyperStore, CMC und Apache Cassandra . Auf den ersten Blick ist alles schön und ordentlich. Bei näherer Betrachtung stellt sich jedoch heraus, dass nur ein einziger Knotenfehler effektiv behoben wird. Der gleichzeitige Verlust von zwei Knoten gleichzeitig kann für die Clusterverfügbarkeit schwerwiegend sein. Redis QoS (auf Knoten 2) verfügt nur über 1 Slave (auf Knoten 3). Das gleiche Bild mit dem Risiko eines Verlusts der Clusterverwaltung - Puppet Server befindet sich nur auf zwei Knoten (1 und 2). Die Wahrscheinlichkeit eines Ausfalls von zwei Knoten gleichzeitig ist jedoch sehr gering, und Sie können damit leben.

Um die Zuverlässigkeit des Speichers zu erhöhen, verwenden wir jedoch 4 Knoten in der DataLine anstelle der mindestens drei. Die folgende Ressourcenverteilung wird erhalten:



Eine weitere Nuance fällt sofort auf - Redis-Anmeldeinformationen werden nicht auf jedem Knoten platziert (wie aus dem obigen offiziellen Schema hervorgeht), sondern nur auf drei von ihnen. In diesem Fall werden Redis-Anmeldeinformationen für jede eingehende Anforderung verwendet. Es stellt sich heraus, dass aufgrund der Notwendigkeit, zu den Redis eines anderen zu gehen, ein gewisses Ungleichgewicht in der Leistung des vierten Knotens besteht.

Für uns ist dies noch nicht von Bedeutung. Während Stresstests wurden keine signifikanten Abweichungen in der Antwortgeschwindigkeit der Knoten festgestellt, aber bei großen Clustern von Dutzenden von Arbeitsknoten ist es sinnvoll, diese Nuance zu korrigieren.

So sieht das Migrationsschema auf 6 Knoten aus:



Das Diagramm zeigt, wie die Dienstmigration bei einem Knotenausfall implementiert wird. Es wird nur der Ausfall eines Servers jeder Rolle berücksichtigt. Wenn beide Server ausfallen, ist ein manueller Eingriff erforderlich.

Auch hier war das Geschäft nicht ohne Feinheiten. Die Rollenmigration verwendet Puppet. Wenn Sie es verlieren oder versehentlich beschädigen, funktioniert das automatische Failover möglicherweise nicht. Aus dem gleichen Grund sollten Sie das Manifest der integrierten Puppe nicht manuell bearbeiten. Dies ist nicht ganz sicher, Änderungen können plötzlich ausgefranst sein, da Manifeste über das Cluster-Admin-Panel bearbeitet werden.

Aus Sicht der Datensicherheit ist alles viel interessanter. Objektmetadaten werden in Apache Cassandra gespeichert und jeder Datensatz wird auf 3 von 4 Knoten repliziert. Replikationsfaktor 3 wird auch zum Speichern von Daten verwendet, Sie können jedoch einen größeren konfigurieren. Dies gewährleistet die Datensicherheit auch bei gleichzeitigem Ausfall von 2 von 4 Knoten. Und wenn Sie Zeit haben, den Cluster neu auszugleichen, können Sie mit einem verbleibenden Knoten nichts verlieren. Die Hauptsache ist, genügend Platz zu haben.



Dies passiert, wenn zwei Knoten ausfallen. Das Diagramm zeigt deutlich, dass die Daten auch in dieser Situation sicher bleiben

Gleichzeitig hängt die Verfügbarkeit von Daten und Speicher von der Strategie zur Gewährleistung der Konsistenz ab. Für Daten, Metadaten, Lesen und Schreiben wird es separat konfiguriert.

Gültige Optionen sind mindestens ein Knoten, ein Quorum oder alle Knoten.
Diese Einstellung bestimmt, wie viele Knoten das Schreiben / Lesen bestätigen müssen, damit die Anforderung als erfolgreich angesehen wird. Wir verwenden das Quorum als angemessenen Kompromiss zwischen der Zeit, die für die Bearbeitung einer Anfrage benötigt wird, und der Zuverlässigkeit des Schreibens / der Inkonsistenz des Lesens. Das heißt, von den drei an der Operation beteiligten Knoten reicht es für eine fehlerfreie Operation aus, eine konsistente Antwort von 2 zu erhalten. Dementsprechend müssen Sie zu einer einzelnen Schreib- / Lesestrategie wechseln, um im Falle eines Ausfalls von mehr als einem Knoten über Wasser zu bleiben.

Abfrageverarbeitung in Cloudian

Im Folgenden werden zwei Schemata für die Verarbeitung eingehender Anforderungen in Cloudian HyperStore betrachtet: PUT und GET. Dies ist die Hauptaufgabe für S3 Service und HyperStore.

Beginnen wir mit der Verarbeitung der Schreibanforderung:



Sicherlich haben Sie festgestellt, dass jede Anforderung viele Überprüfungen und Datenabrufe generiert, mindestens 6 Treffer von Komponente zu Komponente. Von hier aus treten bei der Arbeit mit kleinen Dateien Verzögerungen bei der Aufzeichnung und ein hoher CPU-Zeitverbrauch auf.

Große Dateien werden von Chunks übertragen. Separate Chunks werden nicht als separate Anforderungen betrachtet und einige Überprüfungen werden nicht durchgeführt.

Der Knoten, der die anfängliche Anforderung erhalten hat, bestimmt ferner unabhängig, wo und was geschrieben werden soll, auch wenn er nicht direkt darauf geschrieben wird. Auf diese Weise können Sie die interne Organisation des Clusters vor dem Endclient verbergen und externe Load Balancer verwenden. All dies wirkt sich positiv auf die Wartungsfreundlichkeit und Fehlertoleranz des Speichers aus.



Wie Sie sehen können, unterscheidet sich die Leselogik nicht zu stark vom Schreiben. Darin wird die gleiche hohe Empfindlichkeit der Leistung gegenüber der Größe der verarbeiteten Objekte beobachtet. Aufgrund erheblicher Einsparungen beim Arbeiten mit Metadaten ist es daher viel einfacher, ein fein gehacktes Objekt zu extrahieren als viele separate Objekte mit demselben Gesamtvolumen.

Datenspeicherung und Vervielfältigung

Wie Sie den obigen Diagrammen entnehmen können, unterstützt Cloudian verschiedene Datenspeicherungs- und Duplizierungsschemata:

Replikation - Mithilfe der Replikation ist es möglich, eine benutzerdefinierte Anzahl von Kopien jedes Datenobjekts im System zu verwalten und jede Kopie auf verschiedenen Knoten zu speichern. Bei Verwendung der 3X-Replikation werden beispielsweise 3 Kopien jedes Objekts erstellt, und jede Kopie „liegt“ auf einem eigenen Knoten.

Löschcodierung - Bei der Löschcodierung wird jedes Objekt in eine benutzerdefinierte Menge (als K-Nummer bezeichnet) von Datenfragmenten plus eine benutzerdefinierte Menge an Redundanzcode (M-Nummer) codiert. Jedes K + M-Fragment eines Objekts ist einzigartig und jedes Fragment wird auf einem eigenen Knoten gespeichert. Ein Objekt kann mit beliebigen K-Fragmenten dekodiert werden. Mit anderen Worten, das Objekt bleibt lesbar, auch wenn auf M Knoten nicht zugegriffen werden kann.

Beispielsweise wird bei der Löschcodierung gemäß der 4 + 2-Formel (4 Datenfragmente plus 2 Redundanzcodefragmente) jedes Objekt in 6 eindeutige Fragmente aufgeteilt, die auf sechs verschiedenen Knoten gespeichert sind, und dieses Objekt kann wiederhergestellt und gelesen werden, wenn 4 von 6 Fragmenten verfügbar sind .

Der Vorteil der Löschcodierung gegenüber der Replikation besteht darin, Platz zu sparen, allerdings auf Kosten einer signifikanten Erhöhung der Prozessorlast, einer Verschlechterung der Antwortgeschwindigkeit und der Notwendigkeit von Hintergrundprozeduren zur Steuerung der Konsistenz von Objekten. In jedem Fall werden Metadaten getrennt von den Daten gespeichert (in Apache Cassandra), was die Flexibilität und Zuverlässigkeit der Lösung erhöht.

Kurz über andere Funktionen von HyperStore

Wie ich am Anfang dieses Artikels geschrieben habe, sind mehrere nützliche Tools in HyperStore integriert. Unter ihnen:

• Flexible Abrechnung mit Unterstützung für die Änderung des Preises einer Ressource in Abhängigkeit von Volumen und Tarifplan;
  
• Eingebaute Überwachung
  
• Die Möglichkeit, die Verwendung von Ressourcen für Benutzer und Benutzergruppen einzuschränken.
  
• QoS-Einstellungen und integrierte Verfahren zum Ausgleichen der Ressourcennutzung zwischen Knoten sowie reguläre Verfahren zum Ausgleichen zwischen Knoten und Festplatten auf Knoten oder beim Eingeben neuer Knoten in einen Cluster.
  

Cloudian HyperStore ist jedoch immer noch nicht perfekt. Aus irgendeinem Grund können Sie beispielsweise kein vorhandenes Konto auf eine andere Gruppe übertragen oder einem Datensatz mehrere Gruppen zuweisen. Es ist nicht möglich, Zwischenabrechnungsberichte zu erstellen. Sie erhalten alle Berichte erst nach Abschluss des Berichtszeitraums. Daher können weder Kunden noch wir in Echtzeit herausfinden, wie stark das Konto gewachsen ist.

Cloudian HyperStore-Logik

Jetzt werden wir noch tiefer eintauchen und uns das Interessanteste in jedem SDS-Speicher ansehen - die Logik der Verteilung von Objekten nach Knoten. Beim Cloudian-Speicher werden Metadaten getrennt von den Daten selbst gespeichert. Für Metadaten wird Cassandra verwendet, für Daten die proprietäre HyperStore-Lösung.

Leider gibt es bisher keine offizielle Übersetzung der Cloudian-Dokumentation ins Russische im Internet. Daher werde ich unten meine Übersetzung der interessantesten Teile dieser Dokumentation veröffentlichen.

Die Rolle von Apache Cassandra im HyperStore

In HyperStore wird Cassandra zum Speichern von Objektmetadaten, Benutzerkontoinformationen und Dienstnutzungsdaten verwendet. In einer typischen Bereitstellung in jedem HyperStore werden Cassandra-Daten auf demselben Laufwerk wie das Betriebssystem gespeichert. Das System unterstützt auch Cassandra-Daten auf einem dedizierten Laufwerk auf jedem Knoten. Cassandra-Daten werden nicht auf HyperStore-Datenträgern gespeichert. Wenn dem Host vNodes zugewiesen sind, werden sie nur an die HyperStore-Speicherknoten verteilt. vNodes werden nicht dem Laufwerk zugewiesen, auf dem Cassandra-Daten gespeichert sind.
Innerhalb des Clusters werden Metadaten in Cassandra gemäß der Richtlinie (Strategie) Ihres Repositorys repliziert. Cassandra Data Replication verwendet vNodes folgendermaßen:

• Beim Erstellen eines neuen Cassandra-Objekts (Primärschlüssel und seine entsprechenden Werte) wird es gehasht, und der Hash wird verwendet, um das Objekt einem bestimmten vNode zuzuordnen. Das System prüft, welchem ​​Host dieser vNode zugewiesen ist, und dann wird das erste Replikat des Cassandra-Objekts auf dem Cassandra-Laufwerk auf diesem Host gespeichert.
  
• Angenommen, einem Host werden 96 vNodes zugewiesen, die auf mehrere HyperStore-Datenfestplatten verteilt sind. Cassandra-Objekte, deren Hash-Werte in den Token-Bereich eines dieser 96 vNodes fallen, werden auf diesem Host auf das Cassandra-Laufwerk geschrieben.
  
• Zusätzliche Replikate des Cassandra-Objekts (die Anzahl der Replikate hängt von Ihrer Konfiguration ab) werden vNodes mit der folgenden Sequenznummer zugeordnet und auf dem Knoten gespeichert, dem diese vNodes zugewiesen sind, sofern vNodes bei Bedarf übersprungen werden, sodass jedes Replikat des Cassandra-Objekts auf einem anderen gespeichert wird Host-Maschine.
  

Funktionsweise von HyperStore Storage

Die Platzierung und Replikation von S3-Objekten in einem HyperStore-Cluster basiert auf einem konsistenten Caching-Schema, das Ganzzahl-Token-Speicherplatz im Bereich von 0 bis 2 ¹²⁷ -1 verwendet. Ganzzahlige Token werden HyperStore-Knoten zugewiesen. Für jedes S3-Objekt wird ein Hash berechnet, wenn er in den Speicher geladen wird. Das Objekt wird in dem Knoten gespeichert, dem der niedrigste Wert des Tokens zugewiesen wurde, der größer oder gleich dem Hashwert des Objekts ist. Die Replikation wird auch implementiert, indem das Objekt auf den Knoten gespeichert wird, denen Token zugewiesen wurden, die einen Mindestwert haben.

In einem „klassischen“ konsistenten Hash-basierten Speicher wird einem physischen Knoten ein Token zugewiesen. Das Cloudian HyperStore-System verwendet und erweitert die Funktionalität des in Cassandra in Version 1.2 eingeführten „virtuellen Knotens“ (vNode). Jedem physischen Host wird eine große Anzahl von Token zugewiesen (maximal 256). Tatsächlich besteht der Speichercluster aus einer sehr großen Anzahl von "virtuellen Knoten" mit einer großen Anzahl von virtuellen Knoten (Token) auf jedem physischen Host.

Das HyperStore-System weist jeder Festplatte auf jedem physischen Host einen separaten Satz von Token (virtuellen Knoten) zu. Jede Festplatte auf dem Host ist für ihre eigenen Replikate von Objekten verantwortlich. Ein Festplattenfehler betrifft nur Replikate von Objekten, die sich darauf befinden. Andere Laufwerke auf dem Host werden weiterhin betrieben und erfüllen ihre Aufgaben zur Datenspeicherung.

Wir geben ein Beispiel und betrachten einen Cluster von 6 HyperStore-Hosts, von denen jeder 4 S3-Speicherplatten hat. Angenommen, jedem physischen Host sind 32 Token zugewiesen, und es gibt einen vereinfachten Token-Speicherplatz von 0 bis 960, und der Wert von 192 Token in diesem System (6 Hosts mit 32 Token) beträgt 0, 5, 10, 15, 20 usw. bis zu 955.

Das folgende Diagramm zeigt eine mögliche Verteilung von Token im gesamten Cluster. 32 Token jedes Hosts sind gleichmäßig auf 4 Festplatten verteilt (8 Token pro Festplatte), und die Token selbst sind zufällig über den Cluster verteilt.



Angenommen, Sie haben HyperStore so konfiguriert, dass S3-Objekte 3X repliziert werden. Lassen Sie uns zustimmen, dass das S3-Objekt in das System geladen wird und der auf seinen Namen angewendete Hash-Algorithmus den 322-Hash-Wert (in diesem vereinfachten Hash-Bereich) ergibt. Das folgende Diagramm zeigt, wie drei Instanzen oder Replikate eines Objekts in einem Cluster gespeichert werden:

• Mit dem Hashwert 322 wird das erste Replikat des Objekts auf dem 325-Token gespeichert, weil Dies ist der kleinste Token-Wert, der größer oder gleich dem Hash-Wert des Objekts ist. 325 Token (im Diagramm rot hervorgehoben) sind hyperstore2: Disk2 zugeordnet. Dementsprechend wird dort die erste Replik des Objekts gespeichert.
  

• Das zweite Replikat wird auf der Festplatte gespeichert, der das nächste Token zugewiesen ist (330, orange hervorgehoben), dh auf Hyperstore4: Disk2.
  
• Das dritte Replikat wird auf der Festplatte gespeichert, der nach 330 - 335 (gelb) das nächste Token im Hyperstore3 zugewiesen wird: Disk3.
  

Ich möchte einen Kommentar hinzufügen: Aus praktischer Sicht ist diese Optimierung (die Verteilung von Token nicht nur auf physische Knoten, sondern auch zwischen einzelnen Datenträgern) nicht nur erforderlich, um die Zugänglichkeit sicherzustellen, sondern auch um eine gleichmäßige Verteilung der Daten zwischen den Datenträgern sicherzustellen. In diesem Fall wird das RAID-Array nicht verwendet. Die gesamte Logik der Datenzuweisung auf Festplatten wird vom HyperStore selbst gesteuert. Einerseits ist es bequem und kontrolliert, wenn eine Festplatte verloren geht, wird alles von selbst neu ausgeglichen. Andererseits vertraue ich persönlich mehr guten RAID-Controllern - schließlich ist ihre Logik seit vielen Jahren optimiert. Aber dies sind alles meine persönlichen Vorlieben. Bei echten Problemen und Problemen haben wir HyperStore nie entdeckt, wenn wir bei der Installation von Software auf physischen Servern den Empfehlungen des Anbieters folgen. Der Versuch, Virtualisierung und virtuelle Festplatten auf demselben Speicher des Speichersystems zu verwenden, schlug jedoch fehl. Als das Speichersystem während des Auslastungstests überlastet wurde, wurde HyperStore verrückt und verteilte Daten völlig ungleichmäßig, wodurch einige Festplatten verstopft und andere nicht berührt wurden.

Laufwerkgerät in einem Cluster

Denken Sie daran, dass jeder Host über 32 Token verfügt und die Token jedes Hosts gleichmäßig auf seine Festplatten verteilt sind. Schauen wir uns hyperstore2: Disk2 genauer an (siehe Abbildung unten). Wir sehen, dass dieser Platte Token 325, 425, 370 usw. zugewiesen sind.

Da der Cluster für die 3X-Replikation konfiguriert ist, wird Folgendes im Hyperstore2 gespeichert: Disk2:

In Übereinstimmung mit 325 Disk Token:

• Die ersten Repliken von Objekten mit einem Hashwert von 320 (ausschließlich) bis 325 (einschließlich);
• Zweite Repliken von Objekten mit einem Hashwert von 315 (ausschließlich) bis 320 (einschließlich);
• Dritte Replikate von Objekten mit einem Hashwert von 310 (ausschließlich) bis 315 (einschließlich).

Laut 425 Disk Token:

• Die ersten Repliken von Objekten mit einem Hashwert von 420 (ausschließlich) bis 425 (einschließlich);
• Zweite Repliken von Objekten mit einem Hashwert von 415 (ausschließlich) bis 420 (einschließlich);
• Dritte Replikate von Objekten mit einem Hashwert von 410 (ausschließlich) bis 415 (einschließlich).

Usw.

, HyperStore , . hyperstore2:disk2 .



2 1, 3 4 , 2 , .. .

: , / HyperStore Cassandra. , , , , «» . . . , : , , .

, HyperStore . - . . () , .
, , , «Multi-Data Center Deployments».

HyperStore -. DC1 DC2. - 3 . , , 32 (vNodes), 0 960. -, 192 — 32 6 . .

, S3 -.

, S3 942 2 -:

• vNode 945 ( ), DC2, hyperstore5:Disk3.
  
• vNode 950 ( ) DC2, hyperstore6:Disk4.
  
• vNode 955 DC2, , vNode .
  
• vNode 0 () — DC1, hyperstore2:Disk3. , (955) (0).
  
• vNode (5) DC2, , vNode .
  
• vNode 10 () — DC1, hyperstore3:Disk3.
  

: , , , , . , .

Cloudian. , , . , , , , .
S3 DataLine, , !