Dieser Artikel soll Ihnen dabei helfen, die richtige Lösung für sich auszuwählen und die Unterschiede zwischen SDS wie Gluster, Ceph und Vstorage (Virtuozzo) zu verstehen.
Der Text verwendet Links zu Artikeln mit einer detaillierteren Offenlegung bestimmter Probleme, sodass die Beschreibungen so kurz wie möglich sind und wichtige Punkte ohne unnötige Floskeln sowie einführende Informationen verwendet werden, die Sie auf Wunsch unabhängig im Internet abrufen können.
Tatsächlich erfordern die angesprochenen Themen natürlich die Töne des Textes, aber in der modernen Welt lesen immer mehr Menschen nicht gerne viel))), sodass Sie schnell lesen und eine Auswahl treffen können, und wenn etwas ist nicht klar, folgen Sie den Links oder googeln Sie unklare Wörter))), und dieser Artikel ist wie eine transparente Hülle für diese tiefgreifenden Themen und zeigt die Füllung – die wichtigsten Schlüsselpunkte jeder Entscheidung.
Glanz
Beginnen wir mit Gluster, das von Herstellern hyperkonvergenter Plattformen mit SDS auf Open-Source-Basis für virtuelle Umgebungen aktiv genutzt wird und auf der RedHat-Website im Speicherbereich zu finden ist, wo Sie aus zwei SDS-Optionen wählen können: Gluster oder Ceph.
Gluster besteht aus einer Reihe von Übersetzern – Diensten, die die gesamte Arbeit der Dateiverteilung usw. erledigen. Brick ist ein Dienst, der eine Festplatte bedient, Volume ist ein Volume (Pool), das diese Bricks vereint. Als nächstes kommt der Dienst zum Verteilen von Dateien in Gruppen mithilfe der DHT-Funktion (Distributed Hash Table). Wir werden den Sharding-Dienst nicht in die Beschreibung aufnehmen, da die folgenden Links die damit verbundenen Probleme beschreiben.
Beim Schreiben wird die gesamte Datei im Brick gespeichert und ihre Kopie gleichzeitig auf den Brick auf dem zweiten Server geschrieben. Als nächstes wird die zweite Datei in die zweite Gruppe von zwei Bausteinen (oder mehr) auf verschiedenen Servern geschrieben.
Wenn die Dateien ungefähr gleich groß sind und das Volume nur aus einer Gruppe besteht, ist alles in Ordnung, aber unter anderen Bedingungen ergeben sich aus den Beschreibungen folgende Probleme:
- Der Speicherplatz in Gruppen wird ungleichmäßig genutzt. Dies hängt von der Größe der Dateien ab. Wenn in der Gruppe nicht genügend Speicherplatz zum Schreiben einer Datei vorhanden ist, erhalten Sie eine Fehlermeldung. Die Datei wird nicht geschrieben und nicht an eine andere Gruppe weitergegeben ;
- Beim Schreiben einer Datei geht IO nur an eine Gruppe, der Rest ist inaktiv;
- Sie können beim Schreiben einer Datei keine E/A des gesamten Volumes erhalten.
- und das allgemeine Konzept sieht aufgrund der fehlenden Datenverteilung in Blöcken weniger produktiv aus, wo es einfacher ist, das Problem der gleichmäßigen Verteilung auszubalancieren und zu lösen, und nicht wie jetzt die gesamte Datei in einen Block geht.
Aus der offiziellen Beschreibung Wir kommen auch unwillkürlich zu der Erkenntnis, dass Gluster als Dateispeicher auf dem klassischen Hardware-RAID funktioniert. Es gab Entwicklungsversuche, Dateien in Blöcke zu zerlegen (Sharding), aber all dies ist eine Ergänzung, die Leistungseinbußen für den bereits bestehenden Architekturansatz mit sich bringt, sowie die Verwendung frei verteilter Komponenten mit Leistungseinschränkungen wie Fuse. Es gibt keine Metadatendienste, was die Leistung und Fehlertoleranz des Speichers bei der Verteilung von Dateien in Blöcken einschränkt. Mit der Konfiguration „Distributed Replicated“ sind bessere Leistungsindikatoren zu beobachten und die Anzahl der Knoten sollte mindestens 6 betragen, um ein zuverlässiges Replikat 3 mit optimaler Lastverteilung zu organisieren.
Diese Erkenntnisse hängen auch mit der Beschreibung der Benutzererfahrung zusammen und im Vergleich mit Außerdem gibt es eine Beschreibung der Erfahrungen, die zum Verständnis dieser produktiveren und zuverlässigeren Konfiguration geführt haben
Das Bild zeigt die Lastverteilung beim Schreiben von zwei Dateien, wobei Kopien der ersten Datei auf die ersten drei Server verteilt werden, die in der Gruppe Volume 0 zusammengefasst werden, und drei Kopien der zweiten Datei auf der zweiten Gruppe Volume1 von drei platziert werden Server. Jeder Server verfügt über eine Festplatte.
Die allgemeine Schlussfolgerung ist, dass Sie Gluster verwenden können, allerdings mit der Maßgabe, dass es Einschränkungen in der Leistung und Fehlertoleranz geben wird, die unter bestimmten Bedingungen einer hyperkonvergenten Lösung, bei der auch Ressourcen für die Rechenlast virtueller Umgebungen benötigt werden, zu Schwierigkeiten führen.
Es gibt auch einige Gluster-Leistungsindikatoren, die unter bestimmten Bedingungen erreicht werden können
Ceph
Schauen wir uns nun Ceph anhand der Architekturbeschreibungen an, die mir möglich waren Es gibt auch einen Vergleich zwischen , wo Sie sofort verstehen können, dass es ratsam ist, Ceph auf separaten Servern bereitzustellen, da seine Dienste alle Hardwareressourcen unter Last benötigen.
Architektur komplexer als Gluster und es gibt Dienste wie Metadatendienste, aber der gesamte Komponentenstapel ist recht komplex und nicht sehr flexibel für den Einsatz in einer Virtualisierungslösung. Die Daten werden in Blöcken gespeichert, was produktiver aussieht, aber in der Hierarchie aller Dienste (Komponenten) kommt es unter bestimmten Lasten und Notfallbedingungen zu Verlusten und Latenzzeiten, zum Beispiel den folgenden
Aus der Beschreibung der Architektur geht hervor, dass CRUSH das Herzstück ist, dank dessen der Ort zum Speichern von Daten ausgewählt wird. Als nächstes kommt PG – dies ist die am schwierigsten zu verstehende Abstraktion (logische Gruppe). PGs werden benötigt, um CRUSH effektiver zu machen. Der Hauptzweck von PG besteht darin, Objekte zu gruppieren, um den Ressourcenverbrauch zu reduzieren und die Leistung und Skalierbarkeit zu erhöhen. Es wäre sehr aufwendig, Objekte einzeln und direkt anzusprechen, ohne sie zu einem PG zusammenzufassen. OSD ist ein Dienst für jede einzelne Festplatte.
Ein Cluster kann über einen oder mehrere Datenpools für unterschiedliche Zwecke und mit unterschiedlichen Einstellungen verfügen. Pools sind in Platzierungsgruppen unterteilt. Platzierungsgruppen speichern Objekte, auf die Clients zugreifen. Hier endet die logische Ebene und die physische Ebene beginnt, da jeder Platzierungsgruppe eine Hauptfestplatte und mehrere Replikatfestplatten zugewiesen sind (wie viele genau es sind, hängt vom Replikationsfaktor des Pools ab). Mit anderen Worten: Auf der logischen Ebene wird das Objekt in einer bestimmten Platzierungsgruppe und auf der physischen Ebene auf den ihm zugewiesenen Festplatten gespeichert. In diesem Fall können sich die Festplatten physisch auf verschiedenen Knoten oder sogar in verschiedenen Rechenzentren befinden.
In diesem Schema erscheinen Platzierungsgruppen als notwendige Ebene für die Flexibilität der gesamten Lösung, gleichzeitig aber auch als zusätzliches Glied in dieser Kette, was unfreiwillig einen Produktivitätsverlust nahelegt. Wenn beispielsweise Daten geschrieben werden, muss das System diese in diese Gruppen und dann auf der physischen Ebene in die Hauptfestplatte und Festplatten für Replikate aufteilen. Das heißt, die Hash-Funktion funktioniert beim Suchen und Einfügen eines Objekts, es gibt jedoch einen Nebeneffekt: Es entstehen sehr hohe Kosten und Einschränkungen beim Wiederherstellen des Hashs (beim Hinzufügen oder Entfernen einer Festplatte). Ein weiteres Hash-Problem ist der eindeutig festgelegte Speicherort von Daten, der nicht geändert werden kann. Das heißt, wenn die Festplatte irgendwie einer erhöhten Belastung ausgesetzt ist, hat das System keine Möglichkeit, nicht darauf zu schreiben (durch Auswahl einer anderen Festplatte). Die Hash-Funktion zwingt die Daten dazu, gemäß der Regel lokalisiert zu werden, egal wie schlecht sie sind Die Festplatte ist es, daher verbraucht Ceph viel Speicher, wenn das PG im Falle einer Selbstheilung oder einer Speichererweiterung neu erstellt wird. Die Schlussfolgerung ist, dass Ceph gut funktioniert (wenn auch langsam), aber nur, wenn es keine Skalierung, Notsituationen oder Aktualisierungen gibt.
Natürlich gibt es Möglichkeiten, die Leistung durch Caching und Cache-Sharing zu steigern, aber dafür ist eine gute Hardware erforderlich und es wird trotzdem zu Einbußen kommen. Aber insgesamt scheint Ceph hinsichtlich der Produktivität verlockender zu sein als Gluster. Bei der Verwendung dieser Produkte muss außerdem ein wichtiger Faktor berücksichtigt werden: ein hohes Maß an Kompetenz, Erfahrung und Professionalität mit einem großen Schwerpunkt auf Linux, da es sehr wichtig ist, alles richtig bereitzustellen, zu konfigurieren und zu unterstützen. was dem Administrator noch mehr Verantwortung und Belastung auferlegt.
Vstorage
Die Architektur sieht noch interessanter aus , das in Verbindung mit einem Hypervisor auf denselben Knoten auf demselben verwendet werden kann , aber es ist sehr wichtig, alles richtig zu konfigurieren, um eine gute Leistung zu erzielen. Das heißt, die Bereitstellung eines solchen Produkts aus der Box in einer beliebigen Konfiguration ohne Berücksichtigung der Empfehlungen gemäß der Architektur ist zwar sehr einfach, aber nicht produktiv.
Was kann für die Speicherung neben den Diensten des kvm-qemu-Hypervisors koexistieren, und dies sind nur einige Dienste, bei denen eine kompakte optimale Hierarchie von Komponenten gefunden wurde: Client-Dienst, der über FUSE bereitgestellt wird (modifiziert, nicht Open Source), MDS-Metadatendienst (Metadatendienst), Dienst-Chunk-Dienstdatenblöcke, die auf der physischen Ebene einer Festplatte entsprechen und das ist alles. In Bezug auf die Geschwindigkeit ist es natürlich optimal, ein fehlertolerantes Schema mit zwei Replikaten zu verwenden, aber wenn Sie Caching und Protokolle auf SSD-Laufwerken verwenden, kann die fehlertolerante Codierung (Erase Coding oder Raid6) auf einem ordentlich übertaktet werden Hybrid-Schema oder noch besser auf All-Flash. Bei EC (Erase Coding) gibt es einige Nachteile: Bei der Änderung eines Datenblocks ist eine Neuberechnung der Paritätsbeträge erforderlich. Um die mit diesem Vorgang verbundenen Verluste zu umgehen, schreibt Ceph verzögert in EC, und während einer bestimmten Anfrage können Leistungsprobleme auftreten, wenn beispielsweise alle Blöcke gelesen werden müssen und im Fall von Virtuozzo Storage geänderte Blöcke geschrieben werden müssen wird mithilfe des „log-structured file system“-Ansatzes durchgeführt, der die Kosten für die Paritätsberechnung minimiert. Um ungefähr abzuschätzen, welche Möglichkeiten es gibt, die Arbeit mit und ohne EC zu beschleunigen, gibt es – Abhängig vom Genauigkeitskoeffizienten des Geräteherstellers können die Zahlen Näherungswerte sein, das Ergebnis der Berechnungen ist jedoch eine gute Hilfe bei der Planung der Konfiguration.
Ein einfaches Diagramm der Speicherkomponenten bedeutet nicht, dass diese Komponenten nicht absorbieren Aber wenn Sie alle Kosten im Voraus kalkulieren, können Sie mit der Zusammenarbeit neben dem Hypervisor rechnen.
Es gibt ein Schema zum Vergleich des Verbrauchs von Hardwareressourcen durch die Speicherdienste Ceph und Virtuozzo.
War es bisher möglich, Gluster und Ceph anhand alter Artikel und der wichtigsten Zeilen daraus zu vergleichen, ist dies bei Virtuozzo schwieriger. Es gibt nicht viele Artikel zu diesem Produkt und Informationen können nur der Dokumentation entnommen werden oder auf Russisch, wenn wir Vstorage als Speicher betrachten, der in einigen hyperkonvergenten Lösungen in Unternehmen wie verwendet wird und Acronis.
Ich werde versuchen, mit einer Beschreibung dieser Architektur zu helfen, daher wird es etwas mehr Text geben, aber es nimmt viel Zeit in Anspruch, die Dokumentation selbst zu verstehen, und die vorhandene Dokumentation kann nur durch Überarbeitung der Tabelle als Referenz verwendet werden von Inhalten oder die Suche nach Schlüsselwörtern.
Betrachten wir den Aufzeichnungsprozess in einer Hybrid-Hardwarekonfiguration mit den oben beschriebenen Komponenten: Die Aufzeichnung beginnt an dem Knoten zu gehen, von dem aus der Client sie initiiert hat (dem FUSE-Mount-Point-Dienst), aber die Master-Komponente des Metadata Service (MDS) wird dies natürlich tun Leiten Sie den Client direkt an den gewünschten Chunk-Dienst (CS-Blöcke des Speicherdienstes), d. h. MDS beteiligt sich nicht am Aufzeichnungsprozess, sondern leitet den Dienst einfach an den erforderlichen Chunk weiter. Im Allgemeinen können wir eine Analogie zur Aufnahme mit dem Gießen von Wasser in Fässer anführen. Jedes Barrel ist ein 256 MB großer Datenblock.
Das heißt, eine Festplatte besteht aus einer bestimmten Anzahl solcher Fässer, also dem Festplattenvolumen geteilt durch 256 MB. Jede Kopie wird an einen Knoten verteilt, die zweite fast parallel an einen anderen Knoten usw. Wenn wir drei Replikate haben und SSD-Festplatten für den Cache (zum Lesen und Schreiben von Protokollen) vorhanden sind, erfolgt nach dem Schreiben eine Bestätigung des Schreibvorgangs Das Protokoll wird auf die SSD übertragen und das parallele Zurücksetzen von der SSD wird auf der Festplatte wie im Hintergrund fortgesetzt. Bei drei Replikaten wird der Datensatz nach Bestätigung durch die SSD des dritten Knotens festgeschrieben. Es mag den Anschein haben, dass die Summe der Schreibgeschwindigkeiten von drei SSDs durch drei geteilt werden kann und wir die Schreibgeschwindigkeit einer Replik erhalten, aber die Kopien werden parallel geschrieben und die Netzwerklatenzgeschwindigkeit ist normalerweise höher als die der SSD. und tatsächlich hängt die Schreibleistung vom Netzwerk ab. Um echte IOPS zu sehen, müssen Sie in diesem Zusammenhang den gesamten Vstorage korrekt laden , das heißt, das Testen der tatsächlichen Last und nicht des Speichers und des Caches, bei dem die richtige Datenblockgröße, Anzahl der Threads usw. berücksichtigt werden muss.
Das oben erwähnte Aufzeichnungsprotokoll auf der SSD funktioniert so, dass, sobald Daten darauf eingehen, diese sofort vom Dienst gelesen und auf die Festplatte geschrieben werden. Pro Cluster gibt es mehrere Metadatendienste (MDS), deren Anzahl durch ein Quorum bestimmt wird, das nach dem Paxos-Algorithmus funktioniert. Aus Sicht des Clients ist der FUSE-Mount-Punkt ein Cluster-Speicherordner, der für alle Knoten im Cluster gleichzeitig sichtbar ist. Nach diesem Prinzip verfügt jeder Knoten über einen gemounteten Client, sodass dieser Speicher jedem Knoten zur Verfügung steht.
Für die Leistung eines der oben beschriebenen Ansätze ist es in der Planungs- und Bereitstellungsphase sehr wichtig, das Netzwerk korrekt zu konfigurieren, wobei aufgrund der Aggregation und der korrekt ausgewählten Netzwerkkanalbandbreite ein Ausgleich erfolgt. Bei der Aggregation ist es wichtig, den richtigen Hashing-Modus und die richtigen Frame-Größen auszuwählen. Es gibt auch einen sehr großen Unterschied zum oben beschriebenen SDS, nämlich die Sicherung mit der Fast-Path-Technologie in Virtuozzo Storage. Was neben der modernisierten Sicherung im Gegensatz zu anderen Open-Source-Lösungen die IOPS deutlich erhöht und es Ihnen ermöglicht, nicht durch horizontale oder vertikale Skalierung eingeschränkt zu werden. Im Allgemeinen sieht diese im Vergleich zu den oben beschriebenen Architekturen leistungsfähiger aus, aber für ein solches Vergnügen müssen Sie im Gegensatz zu Ceph und Gluster natürlich Lizenzen kaufen.
Zusammenfassend können wir den Spitzenreiter hervorheben: Virtuozzo Storage belegt den ersten Platz in Bezug auf Leistung und Zuverlässigkeit der Architektur, Ceph den zweiten Platz und Gluster den dritten Platz.
Die Kriterien, nach denen Virtuozzo Storage ausgewählt wurde: Es handelt sich um einen optimalen Satz architektonischer Komponenten, modernisiert für diesen Fuse-Ansatz mit schnellem Pfad, einem flexiblen Satz Hardwarekonfigurationen, geringerem Ressourcenverbrauch und der Möglichkeit zur gemeinsamen Nutzung mit Computern (Computing/Virtualisierung). das heißt, es ist vollständig für eine hyperkonvergente Lösung geeignet, zu der er gehört. Den zweiten Platz belegt Ceph, da es sich im Vergleich zu Gluster um eine produktivere Architektur handelt, da es in Blöcken arbeitet, flexiblere Szenarien bietet und in größeren Clustern arbeiten kann.
Es ist geplant, einen Vergleich zwischen vSAN, Space Direct Storage, Vstorage und Nutanix Storage zu schreiben, Vstorage auf HPE- und Huawei-Geräten zu testen und Szenarien für die Integration von Vstorage mit externen Hardware-Speichersystemen zu erstellen. Wenn Ihnen der Artikel also gefallen hat, dann wäre er dabei schön, von Ihnen Feedback zu bekommen, das unter Berücksichtigung Ihrer Kommentare und Wünsche die Motivation für neue Artikel steigern könnte.
Source: habr.com