So funktioniert der S3 DataLine-Speicher



    Hallo habr

    Es ist kein Geheimnis, dass große Datenmengen in die Arbeit moderner Anwendungen einbezogen werden 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. Zur Lösung 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 auf Basis von Cloudian HyperStore eingeführt (und eingeführt!). Wie sich herausstellte, gibt es im Netzwerk nur sehr wenige russischsprachige Veröffentlichungen zu Cloudian selbst und noch weniger zur tatsächlichen Anwendung dieser Lösung.

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

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

    Zunächst erkläre ich, warum wir uns für Cloudian entschieden haben. Es ist ganz einfach: In dieser Nische gibt es nur sehr wenige Optionen, die es wert sind. Zum Beispiel gab es vor ein paar Jahren, als wir gerade über das Bauen nachdachten, nur drei Möglichkeiten:

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

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

    Und ja, das (mit Sicherheit!) Wichtigste 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 es gibt praktisch keine Informationen dazu in RuNet. Heute werden wir diese Ungerechtigkeit korrigieren und mit Ihnen über die Funktionen der HyperStore-Architektur sprechen, die wichtigsten Komponenten untersuchen und die wichtigsten architektonischen Nuancen behandeln. Beginnen wir mit dem grundlegendsten, nämlich - was ist Cloudian unter der Haube?

    Funktionsweise von Cloudian HyperStore Storage


    Werfen wir einen Blick auf das Diagramm 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-Dienst - das Modul, das für die Unterstützung des S3-Protokolls verantwortlich ist ;
    • HyperStore Service - 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 ist die Arbeit der Hauptdienste S3 Service und HyperStore Service, 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 hoch die Fehlertoleranz und Zuverlässigkeit der Datenspeicherung dieser Lösung insgesamt ist.




    Mit allgemeinen Diensten im obigen Diagramm sind die Dienste S3, HyperStore, CMC und Apache Cassandra gemeint. 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 werden kann. Der gleichzeitige Verlust von zwei Knoten kann für die Clusterverfügbarkeit fatal sein - Redis QoS (auf Knoten 2) hat nur einen Slave (auf Knoten 3). Das gleiche Bild mit dem Risiko, die Clusterverwaltung zu verlieren - Puppet Server befindet sich nur auf zwei Knoten (1 und 2). Die Ausfallwahrscheinlichkeit von zwei Knoten auf einmal ist jedoch sehr gering und Sie können damit leben.

    Um die Zuverlässigkeit des Speichers zu erhöhen, verwenden wir in DataLine 4 statt der mindestens drei Knoten. Die folgende Verteilung der Ressourcen stellt sich heraus:   



    Eine weitere Nuance ist sofort ersichtlich - Redis CredentialsEs wird nicht auf jedem Knoten platziert (wie aus dem obigen offiziellen Schema angenommen werden könnte), sondern nur auf drei von ihnen. In diesem Fall werden die Redis-Anmeldeinformationen für jede eingehende Anforderung verwendet. Es stellt sich heraus, dass die Leistung des vierten Knotens aufgrund der Notwendigkeit, zum Redis eines anderen Benutzers zu wechseln, ein gewisses Ungleichgewicht aufweist.

    Für uns ist dies noch nicht von Bedeutung. Während des Stresstests wurden keine signifikanten Abweichungen in der Reaktionsgeschwindigkeit der Knoten festgestellt. Bei großen Gruppen von Dutzenden von Arbeitsknoten ist es jedoch 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 verlief 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 eingebetteten Marionette nicht manuell bearbeiten. Dies ist nicht ganz sicher, da Änderungen plötzlich ausgefranst werden können, da Manifeste über das Cluster-Verwaltungsfenster 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 garantiert 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. Hauptsache, man hat genug Platz.



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

    gleichzeitig die Verfügbarkeit und Speicherung von Daten von der Strategie der Konsistenzsicherung abhängt. 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 legt fest, 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 Verarbeitung einer Anfrage benötigt wird, und der Zuverlässigkeit von Inkonsistenzen beim Schreiben / Lesen. Das heißt, von den drei an der Operation beteiligten Knoten ist es für eine fehlerfreie Operation ausreichend, eine konsistente Antwort von 2 zu erhalten. Dementsprechend müssen Sie zu einer einzelnen Schreib- / Lesestrategie wechseln, um über Wasser zu bleiben, wenn mehr als ein Knoten ausfällt.

    Abfrageverarbeitung in Cloudian


    Im Folgenden werden zwei Schemata für die Verarbeitung eingehender Anforderungen in Cloudian HyperStore, PUT und GET, betrachtet. 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 sechs Aufrufe von Komponente zu Komponente. Ab hier treten bei der Arbeit mit kleinen Dateien Aufzeichnungsverzögerungen und ein hoher CPU-Zeitverbrauch auf.

    Große Dateien werden von Blöcken übertragen. Separate Chunks gelten nicht als separate Anforderungen und ein Teil der Prüfungen wird nicht durchgeführt.

    Der Knoten, der die ursprüngliche Anforderung empfangen 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, unterscheidet sich die Leselogik nicht zu stark vom Schreiben. Dabei wird die gleiche hohe Empfindlichkeit der Leistung gegenüber der Größe der bearbeiteten Objekte beobachtet. Aufgrund der erheblichen Einsparungen bei der Arbeit mit Metadaten ist es daher viel einfacher, ein fein zerkleinertes Objekt zu extrahieren, als viele separate Objekte mit demselben Gesamtvolumen.

    Datenspeicherung und Vervielfältigung


    Wie Sie aus den obigen Diagrammen ersehen können, unterstützt Cloudian verschiedene Schemata zum Speichern und Duplizieren von Daten:  

    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 (bekannt als K-Nummer) von Datenfragmenten plus eine benutzerdefinierte Menge an Redundanzcode (M-Nummer) codiert. Jedes K + M-Fragment des Objekts ist eindeutig, und jedes Fragment wird auf seinem 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 von Erasure Coding gegenüber der Replikation besteht darin, dass Platz gespart wird, obwohl dies zu Lasten einer erheblichen Erhöhung der Prozessorlast, einer Verschlechterung der Antwortgeschwindigkeit und der Notwendigkeit von Hintergrundprozeduren zur Kontrolle der Objektkonsistenz geht. 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 des 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 regelmäßige Verfahren zum erneuten Ausgleichen zwischen Knoten und Datenträgern auf Knoten oder beim Eingeben neuer Knoten in einen Cluster.

    Cloudian HyperStore ist jedoch immer noch nicht perfekt. Beispielsweise können Sie aus irgendeinem Grund ein vorhandenes Konto nicht auf eine andere Gruppe übertragen oder einem Datensatz mehrere Gruppen zuweisen. Zwischenabrechnungsberichte können nicht erstellt werden. Sie erhalten alle Berichte erst nach Abschluss des Berichtszeitraums. Daher können weder Kunden noch wir herausfinden, um wie viel das Konto in Echtzeit gewachsen ist.   

    Cloudian HyperStore Logic


    Jetzt werden wir noch tiefer eintauchen und uns die interessantesten Aspekte eines SDS-Speichers 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 im Folgenden meine Übersetzung der interessantesten Teile dieser Dokumentation veröffentlichen.

    Die Rolle von Apache Cassandra in HyperStore


    In HyperStore wird Cassandra zum Speichern von Objektmetadaten, Benutzerkontoinformationen und Dienstnutzungsdaten verwendet. In einer typischen Bereitstellung auf 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 sind nicht dem Laufwerk zugeordnet, auf dem Cassandra-Daten gespeichert sind.
    Innerhalb des Clusters werden Metadaten in Cassandra gemäß der Richtlinie (Strategie) Ihres Repositorys repliziert. Bei der Cassandra-Datenreplikation werden vNodes folgendermaßen verwendet:

    • Beim Erstellen eines neuen Cassandra-Objekts (Primärschlüssel und zugehörige Werte) wird es gehasht und der Hash wird verwendet, um das Objekt einem bestimmten vNode zuzuordnen. Das System überprüft, welchem ​​Host dieser vNode zugewiesen ist, und speichert dann die erste Replik des Cassandra-Objekts auf dem Cassandra-Laufwerk dieses Hosts.
    • Angenommen, einem Host sind 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 das Cassandra-Laufwerk dieses Hosts 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 einen Integer-Token-Bereich im Bereich von 0 bis 2 127 -1 verwendet. Ganzzahlige Token werden HyperStore-Knoten zugewiesen. Für jedes S3-Objekt wird ein Hash berechnet, während es 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" Speicher, der auf konsistentem Hashing basiert, wird einem physischen Knoten ein Token zugewiesen. Das Cloudian HyperStore-System nutzt und erweitert die Funktionalität des in Version 1.2 von Cassandra eingeführten „virtuellen Knotens“ (vNode) - jedem physischen Host wird eine große Anzahl von Tokens zugewiesen (maximal 256). Tatsächlich besteht der Speichercluster aus einer sehr großen Anzahl „virtueller Knoten“ mit einer großen Anzahl virtueller 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 einen eigenen Satz von Replikaten von Objekten verantwortlich. Ein Datenträgerfehler betrifft nur Replikate von Objekten, die sich auf dem Datenträger befinden. Andere Laufwerke auf dem Host werden weiterhin betrieben und sind für die Datenspeicherung verantwortlich.

    Lassen Sie uns ein Beispiel geben und einen Cluster von 6 HyperStore-Hosts betrachten, 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 jeweils 32 Token) beträgt 0, 5, 10, 15, 20 usw. bis zu 955.

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



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

    • Mit dem Hash-Wert des Namens 322 wird das erste Replikat des Objekts auf dem Token 325 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) werden hyperstore2: Disk2 zugewiesen. Dementsprechend wird die erste Kopie des Objekts dort gespeichert.

    • Das zweite Replikat wird auf dem Datenträger gespeichert, dem das nächste Token zugewiesen ist (330, orange hervorgehoben), d. H. Auf hyperstore4: Datenträger2.
    • Das dritte Replikat wird auf dem Datenträger gespeichert, dem das nächste Token nach 330 - 335 (gelb) im HyperStore3: Datenträger3 zugewiesen ist.


    Kommentar hinzufügen:Aus praktischer Sicht ist diese Optimierung (die Verteilung von Tokens nicht nur zwischen physischen Knoten, sondern auch zwischen einzelnen Platten) nicht nur zur Gewährleistung der Zugänglichkeit, sondern auch zur Gewährleistung einer gleichmäßigen Verteilung von Daten zwischen Platten erforderlich. In diesem Fall wird das RAID-Array nicht verwendet. Die gesamte Logik der Datenplatzierung auf Datenträgern wird von HyperStore selbst gesteuert. Einerseits ist es bequem und kontrolliert: Wenn eine Festplatte verloren geht, gleicht sich alles von alleine aus. Andererseits vertraue ich persönlich mehr guten RAID-Controllern - schließlich wurde deren Logik seit vielen Jahren optimiert. Dies sind jedoch alle meine persönlichen Vorlieben. Wir haben HyperStore in Bezug auf reale Schulen und Probleme nie entdeckt, wenn wir bei der Installation von Software auf physischen Servern die Empfehlungen des Herstellers befolgen. Der Versuch, Virtualisierung und virtuelle Festplatten auf demselben Mond im Speichersystem zu verwenden, schlug jedoch fehl.

    Laufwerk innerhalb eines Clusters


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

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

    Laut 325-Datenträgertoken:
    • Die ersten Replikate von Objekten mit einem Hash-Wert von 320 (ausschließlich) bis 325 (einschließlich);
    • Zweite Replikate von Objekten mit einem Hash-Wert von 315 (ausschließlich) bis 320 (einschließlich);
    • Dritte Replikate von Objekten mit einem Hash-Wert von 310 (ausschließlich) bis 315 (einschließlich).

    Laut 425 Disk Token:
    • Die ersten Replikate von Objekten mit einem Hash-Wert von 420 (ausschließlich) bis 425 (einschließlich);
    • Zweite Replikate von Objekten mit einem Hash-Wert von 415 (ausschließlich) bis 420 (einschließlich);
    • Dritte Replikate von Objekten mit einem Hash-Wert von 410 (ausschließlich) bis 415 (einschließlich).

    Usw.

    Wie bereits erwähnt, übergibt HyperStore beim Platzieren eines zweiten und dritten Replikats möglicherweise Token, um nicht mehr als eine Kopie des Objekts auf einem physischen Knoten zu speichern. Dadurch entfällt die Verwendung von hyperstore2: disk2 als Speicher für zweite oder dritte Replikate desselben Objekts.



    Wenn Datenträger 2 auf den Datenträgern 1, 3 und 4 abstürzt, werden die Daten weiterhin gespeichert, und Objekte auf Datenträger 2 werden im Cluster gespeichert, weil wurden auf andere Hosts repliziert.
    Anmerkung: Daher basiert die Verteilung von Repliken und / oder Fragmenten von Objekten im HyperStore-Cluster auf dem Design von Cassandra, das für die Anforderungen der Dateispeicherung entwickelt wurde. Um zu verstehen, wo das Objekt physisch platziert werden soll, wird ein bestimmter Hash in seinem Namen verwendet und in Abhängigkeit von seinem Wert werden nummerierte "Token" zur Platzierung ausgewählt. Die Token werden im Voraus zufällig im Cluster verteilt, um die Last auszugleichen. Bei der Auswahl einer Token-Nummer für die Platzierung werden Einschränkungen bei der Platzierung von Replikaten und Teilen des Objekts auf denselben physischen Knoten berücksichtigt. Leider hat dieses Design einen Nebeneffekt: Wenn Sie einen Knoten im Cluster hinzufügen oder entfernen müssen, müssen Sie die Daten neu mischen. Dies ist ein ziemlich ressourcenintensiver Prozess.

    Einzelne Speicherung in mehreren Rechenzentren


    Lassen Sie uns nun sehen, wie die Geoverteilung in HyperStore in mehreren Rechenzentren und Regionen funktioniert. In unserem Fall unterscheidet sich der Multi-DPC-Modus vom Multi-Regional-Modus durch die Verwendung eines oder mehrerer Token-Leerzeichen. Im ersten Fall ist der Token-Raum einheitlich. Im zweiten Schritt verfügt jede Region über einen unabhängigen Token-Bereich mit (möglicherweise) eigenen Einstellungen für die Konsistenz-, Kapazitäts- und Speicherkonfigurationen.
    Um zu verstehen, wie dies funktioniert, wenden wir uns noch einmal der Übersetzung der Dokumentation im Abschnitt „Multi-Data Center-Bereitstellungen“ zu.

    Erwägen Sie die Bereitstellung von HyperStore in zwei Rechenzentren. Nennen Sie sie DC1 und DC2. Jedes Rechenzentrum verfügt über 3 physische Knoten. Wie in unseren vorherigen Beispielen verfügt jeder physische Knoten über vier Festplatten, 32 Token (vNodes) sind jedem Host zugewiesen, und wir gehen von einem vereinfachten Tokenbereich von 0 bis 960 aus. In diesem Szenario mit mehreren Rechenzentren ist der Tokenbereich in 192 Token unterteilt. 32 Token für jeden der 6 physischen Hosts. Token werden von Hosts absolut zufällig verteilt.

    Nehmen Sie außerdem an, dass die Replikation von S3-Objekten in diesem Fall auf zwei Replikaten in jedem Rechenzentrum konfiguriert ist.

    Sehen wir uns an, wie ein hypothetisches S3-Objekt mit einem Hash-Wert von 942 in zwei Rechenzentren repliziert wird:

    • Das erste Replikat wird in vNode 945 (in der folgenden Abbildung in rot angegeben) gespeichert, der sich in DC2 auf hyperstore5: Disk3 befindet.
    • Das zweite Replikat ist in vNode 950 (orangefarben) DC2 auf hyperstore6: Disk4 gespeichert.
    • Der nächste vNode 955 befindet sich in DC2, wo die angegebene Replikationsstufe bereits erreicht wurde, sodass dieser vNode übersprungen wird.
    • Das dritte Replikat befindet sich in vNode 0 (gelb) - in DC1, hyperstore2: Disk3. Bitte beachten Sie, dass nach dem Token mit der höchsten Nummer (955) das Token mit der niedrigsten Nummer (0) folgt.
    • Der nächste vNode (5) befindet sich in DC2, wo die angegebene Replikationsstufe bereits erreicht wurde. Daher überspringen wir diesen vNode.
    • Das vierte und letzte Replikat wird in vNode 10 (grün) gespeichert - in DC1, hyperstore3: Disk3.


    Anmerkung: Eine weitere Eigenschaft des obigen Schemas ist, dass für den normalen Betrieb von Speicherrichtlinien, die beide Rechenzentren betreffen, der Speicherplatz, die Anzahl der Knoten und Festplatten auf einem Knoten in beiden Rechenzentren übereinstimmen müssen. Wie ich bereits sagte, unterliegt ein multiregionales System keiner solchen Einschränkung.
    Dies schließt unseren Überblick über die Cloudian-Architektur und die wichtigsten Funktionen ab. In jedem Fall ist dieses Thema zu ernst und zu umfangreich, um das ausführliche Handbuch in einem Artikel über Habré aufzunehmen. Wenn Sie an den von mir ausgelassenen Details interessiert sind, Fragen oder Vorschläge zur Präsentation des Materials in zukünftigen Artikeln haben, werde ich Sie daher gerne in den Kommentaren kontaktieren.
    Im nächsten Artikel werden wir uns mit der Implementierung des S3-Speichers in DataLine befassen, die verwendeten Infrastruktur- und Netzfehlertoleranztechnologien im Detail erläutern und Ihnen als Bonus die Geschichte ihres Aufbaus erzählen!

    Jetzt auch beliebt: