Dieser Artikel wurde verfasst, um Ihnen bei der Auswahl einer geeigneten Lösung zu helfen und die Unterschiede zwischen SDS-Systemen wie Gluster, Ceph und Vstorage (Virtuozzo) zu erläutern.
Im Text sind Verweise auf Artikel enthalten, die bestimmte Probleme detaillierter behandeln. Daher werden die Beschreibungen so kurz wie möglich gehalten, wobei die wesentlichen Punkte ohne unnötige Informationen dargestellt werden. Zusätzliche Informationen können Sie bei Bedarf im Internet selbst recherchieren.
Tatsächlich erfordern die angesprochenen Themen eine angemessene Texttiefe, jedoch neigen immer mehr Menschen dazu, weniger zu lesen. Daher kann man die Texte schnell überfliegen und eine Entscheidung treffen. Bei Unklarheiten kann man die Links verfolgen oder unklare Begriffe googeln. Dieser Artikel dient als transparente Hülle für diese tiefgründigen Themen und zeigt die Hauptpunkte jeder Lösung.
Gluster
Beginnend mit Gluster, das häufig von Herstellern hyperkonvergenter Plattformen mit auf Open Source basierendem SDS für virtuelle Umgebungen verwendet wird. Es ist auf der Website von RedHat im Bereich Storage zu finden, wo Sie zwischen zwei SDS-Optionen wählen können: Gluster oder Ceph.
Gluster besteht aus einem Stapel von Übersetzungsdiensten, die alle Aufgaben der Dateiverteilung und mehr erledigen. Brick ist ein Dienst, der einen einzelnen Datenträger verwaltet, während Volume – ein Pool – diese Bricks zusammenfasst. Anschließend folgt der Dienst zur Dateiverteilung über Gruppen mittels der DHT-Funktion (Distributed Hash Table). Die Sharding-Dienste werden hier nicht beschrieben, da die nachfolgenden Links Probleme im Zusammenhang mit ihnen erläutern.
Beim Schreiben wird die Datei vollständig in einen Brick geschrieben, und eine Kopie wird gleichzeitig auf einen Brick auf dem zweiten Server geschrieben. Anschließend wird die zweite Datei in die zweite Gruppe von zwei Brick (oder mehr) auf verschiedenen Servern geschrieben.
Wenn die Dateien ungefähr gleich groß sind und der Pool nur aus einer Gruppe besteht, ist alles in Ordnung. Bei anderen Bedingungen können jedoch die folgenden Probleme auftreten:
- Der Platz in den Gruppen wird ungleichmäßig genutzt, was von den Dateigrößen abhängt. Wenn in der Gruppe nicht genug Platz für die Datei ist, erhalten Sie einen Fehler, die Datei wird nicht geschrieben und auch nicht in eine andere Gruppe umverteilt.
- Beim Schreiben einer Datei erfolgt der IO nur auf eine Gruppe, während die anderen inaktiv bleiben.
- Es ist nicht möglich, die IO des gesamten Volumes beim Schreiben einer einzelnen Datei zu erhalten;
- und das Gesamtkonzept erscheint weniger leistungsfähig, da es an der Verteilung der Daten über Blöcke fehlt, wo eine bessere Balance erreicht werden kann, um das Problem einer gleichmäßigen Verteilung zu lösen, anstatt dass die Datei jetzt ganz in einen Brick gelegt wird.
Aus der offiziellen Beschreibung kommt auch unweigerlich das Verständnis, dass Gluster als Dateispeicher über herkömmlichem Hardware-RAID funktioniert. Es gab Versuche, Dateien in Blöcke zu zerschneiden (Sharding), aber all dies ist eine Ergänzung, die die Leistung des bereits bestehenden architektonischen Ansatzes beeinträchtigt, plus die Verwendung solcher frei verfügbaren Komponenten mit Leistungsgrenzen wie Fuse. Es gibt keine Metadatenservices, was die Möglichkeiten der Leistung und der Ausfallsicherheit des Speichers bei der Verteilung von Dateien auf Blöcke einschränkt. Bessere Leistungswerte können bei der Konfiguration „Distributed Replicated“ beobachtet werden, und die Anzahl der Knoten sollte mindestens 6 betragen, um eine zuverlässige Replikation von 3 mit optimaler Lastverteilung zu organisieren.
Diese Erkenntnisse stehen auch im Zusammenhang mit der Beschreibung der Benutzererfahrung. und im Vergleich mit , außerdem gibt es eine Beschreibung der Erfahrung beim Verständnis dieser leistungsfähigeren und zuverlässigen Konfiguration.
Das Bild zeigt die Lastverteilung beim Schreiben von zwei Dateien, wobei Kopien der ersten Datei auf den ersten drei Servern, die zur Gruppe volume 0 gehören, verteilt werden und drei Kopien der zweiten Datei auf der zweiten Gruppe volume 1 aus drei Servern liegen. Jeder Server hat eine Festplatte.
Die allgemeine Erkenntnis ist, dass Gluster verwendet werden kann, jedoch mit dem Bewusstsein, dass Einschränkungen in der Leistung und Fehlertoleranz bestehen, die unter bestimmten Bedingungen einer hyperkonvergenten Lösung Schwierigkeiten bereiten können, wo Ressourcen auch für die Rechenlasten virtueller Umgebungen benötigt werden.
Es gibt auch einige Leistungskennzahlen von Gluster, die unter bestimmten Bedingungen erreicht werden können, indem man sich auf
Ceph
Nun betrachten wir Ceph anhand der Architekturbeschreibungen, die ich finden konnte. Es gibt auch einen Vergleich zwischen , wo man sofort erkennen kann, dass Ceph idealerweise auf separaten Servern bereitgestellt werden sollte, da seine Dienste alle Hardware-Ressourcen unter Last benötigen.
Architektur von ist komplexer als Gluster und umfasst Dienste wie Metadaten-Dienste, aber der gesamte Komponenten-Stack ist recht kompliziert und nicht sehr flexibel für den Einsatz in Virtualisierungs-Lösungen. Die Daten werden in Blöcken gespeichert, was effizienter aussieht, jedoch gibt es in der Hierarchie aller Dienste (Komponenten) Verluste und Latenzzeiten unter bestimmten Lastbedingungen und in Notfallsituationen, als Beispiel die folgende
Aus der Beschreibung der Architektur geht hervor, dass das Herzstück CRUSH ist, das bestimmt, wo die Daten platziert werden. Dann folgt PG – dies ist die komplexeste Abstraktion (logische Gruppe) zum Verständnis. PG sind nötig, damit CRUSH effizienter arbeitet. Der Hauptzweck von PG ist die Gruppierung von Objekten zur Reduzierung des Ressourcenverbrauchs, zur Leistungssteigerung und zur Skalierbarkeit. Die direkte Adressierung von Objekten einzeln, ohne sie in PG zusammenzufassen, wäre sehr kostspielig. OSD ist der Dienst für jede einzelne Festplatte.
Ein Cluster kann einen oder mehrere Pools mit unterschiedlichen Zwecken und Einstellungen haben. Diese Pools werden in Platzierungsgruppen unterteilt. In den Platzierungsgruppen werden Objekte gespeichert, auf die Kunden zugreifen. An dieser Stelle endet die logische Ebene und die physische beginnt, da jeder Platzierungsgruppe eine Hauptdisk und mehrere Replikat-Disk zugewiesen sind (die genaue Anzahl hängt vom Replikationsfaktor des Pools ab). Anders ausgedrückt, auf der logischen Ebene wird das Objekt in einer bestimmten Platzierungsgruppe gespeichert, während es auf der physischen Ebene auf den daran angeschlossenen Disks aufbewahrt wird. Die Disks können sich dabei physisch auf verschiedenen Knoten oder sogar in unterschiedlichen Rechenzentren befinden.
In diesem Schema erscheinen Placement-Gruppen als notwendige Ebene für die Flexibilität der gesamten Lösung, stellen jedoch gleichzeitig ein zusätzliches Glied in dieser Kette dar, was unweigerlich zu Bedenken hinsichtlich der möglichen Leistungseinbußen führt. Bei der Datenspeicherung beispielsweise muss das System diese Daten in Gruppen aufteilen und dann auf physikalischer Ebene auf die Hauptfestplatte sowie auf die Festplatten für Replikate schreiben. Das bedeutet, dass die Hash-Funktion beim Suchen und Einfügen eines Objekts arbeitet, aber es gibt einen Nebeneffekt – enorme Kosten und Einschränkungen bei der Neuorganisation des Hashs (beim Hinzufügen oder Entfernen einer Festplatte). Ein weiteres Problem der Hash-Funktion ist die starr definierte Anordnung der Daten, die nicht geändert werden kann. Wenn eine Festplatte also überlastet ist, hat das System keine Möglichkeit, alternativ auf eine andere Festplatte zu schreiben, da die Hash-Funktion die Anordnung der Daten gemäß einer Regel vorschreibt, unabhängig davon, wie schlecht es der Festplatte geht. Daher benötigt Ceph viel Speicher bei der Neugestaltung der PG im Fall von Self-Healing oder bei Erweiterung des Speichers. Die Schlussfolgerung ist, dass Ceph gut funktioniert (wenn auch langsam), jedoch nur, wenn es keine Skalierung, Notfälle oder Aktualisierungen gibt.
Natürlich gibt es Möglichkeiten zur Leistungssteigerung durch Caching und Cache-Tiering, jedoch ist dafür eine gute Hardware erforderlich, und es werden dennoch Verluste auftreten. Insgesamt erscheint Ceph jedoch vielversprechender als Gluster für Produktiveinsätze. Bei der Verwendung dieser Produkte muss zudem ein wichtiger Aspekt berücksichtigt werden – nämlich ein hohes Maß an Kompetenz, Erfahrung und Professionalität mit einem starken Fokus auf Linux, da es entscheidend ist, alles richtig zu implementieren, zu konfigurieren und zu warten. Dies bedeutet eine erhöhte Verantwortung und Belastung für den Administrator.
Vstorage
Die Architektur von , die zusammen mit dem Hypervisor auf denselben Knoten, auf derselben , verwendet werden kann, wirkt ebenfalls äußerst interessant. Es ist jedoch sehr wichtig, alles korrekt zu konfigurieren, um eine gute Leistungsfähigkeit zu erreichen. Das bedeutet, dass das Produkt einfach nach der Standardkonfiguration bereitgestellt werden kann, ohne die Empfehlungen gemäß der Architektur zu beachten, was leicht ist, aber nicht leistungsstark.
Was kann neben den KVM-QEMU-Hypervisor-Diensten coexistieren? Hier handelt es sich um einige Komponenten, die eine kompakte, optimale Hierarchie bilden: ein über FUSE gemounteter Kundendienst (modifiziert, nicht Open Source), der Metadatenservice MDS, der Chunk-Service zur Datenblockverarbeitung, bei dem es sich physisch um eine einzige Festplatte handelt. Optimalerweise sollte man bei der Geschwindigkeit eine Fehlertoleranzkonfiguration mit zwei Replikaten verwenden. Wenn jedoch Caching und SSD-Logs eingesetzt werden, kann das fehlertolerante Kodieren (Erase Coding oder RAID6) auf einem hybriden System oder sogar auf einer rein Flash-basierten Lösung erheblich beschleunigt werden. Mit EC (Erase Coding) gibt es jedoch einen Nachteil: Bei der Änderung eines Datenblocks müssen die Paritätswerte neu berechnet werden. Um die Verluste bei diesem Vorgang zu umgehen, schreibt Ceph in EC verzögert, was zu Leistungseinbußen bei bestimmten Anfragen führen kann, wenn beispielsweise alle Blöcke berücksichtigt werden müssen. Im Vergleich dazu erfolgt die Speicherung der geänderten Blöcke bei Virtuozzo Storage über einen Ansatz, der das „log-structured file system“ verwendet, was die Rechenkosten für die Paritätsberechnung minimiert. Um die Optionen zur Beschleunigung der Arbeitsweise mit und ohne EC grob abzuschätzen, gibt es: Die genannten Zahlen können nur annähernd sein und hängen vom Genauigkeitsfaktor des Herstellers ab, aber die Berechnungsergebnisse helfen gut bei der Planung der Konfiguration.
Eine einfache Schema der Speicherkomponenten bedeutet nicht, dass diese Komponenten keine Ressourcen benötigen, Es gibt einen Vergleichsplan des Ressourcenverbrauchs der Ceph- und Virtuozzo-Storage-Dienste.
Früher konnte man Gluster und Ceph anhand alter Artikel vergleichen, indem man die wichtigsten Zeilen daraus verwendete, aber mit Virtuozzo ist es schwieriger. Es gibt nicht viele Artikel zu diesem Produkt, und Informationen können nur aus der Dokumentation auf
oder auf Russisch entnommen werden, wenn man Vstorage als Speicher betrachtet, der in einigen hyperkonvergenten Lösungen verwendet wird, in Unternehmen wie Rosplataforma и Акронис.
Ich werde versuchen, diese Architektur zu beschreiben, weshalb der Text etwas ausführlicher wird. Um die Dokumentation vollständig zu verstehen, benötigt man viel Zeit, und die vorhandene Dokumentation kann nur als Nachschlagewerk genutzt werden, indem man das Inhaltsverzeichnis durchgeht oder nach Schlüsselwörtern sucht.
Betrachten wir den Aufzeichnungsprozess in einer hybriden Konfiguration mit den oben beschriebenen Komponenten: Die Aufzeichnung beginnt an dem Knoten, von dem der Kunde sie initiiert hat (FUSE-Mount-Point-Service). Der Master-Dienst für Metadaten (MDS) leitet den Kunden jedoch direkt an den entsprechenden Chunk-Service (Block Storage Service) weiter. Das bedeutet, dass der MDS nicht am Schreibprozess beteiligt ist, sondern lediglich an den benötigten Chunk-Service verweist. Man kann die Aufzeichnung auch mit dem Fließen von Wasser in Fässern vergleichen. Jedes Fass entspricht einem Datenblock von 256 MB.
Das bedeutet, dass eine Festplatte eine bestimmte Anzahl solcher Fässer darstellt, wobei das Volumen der Festplatte durch 256 MB geteilt wird. Jede Kopie wird auf einen Knoten verteilt, die zweite nahezu parallel auf einen anderen Knoten usw. Wenn wir drei Replikate haben und SSD-Festplatten für den Cache (zum Lesen und für Schreibprotokolle) verwenden, erfolgt die Bestätigung der Speicherung nach dem Schreiben des Protokolls auf der SSD. Währenddessen wird der parallele Speicherablauf von der SSD auf die HDD im Hintergrund fortgesetzt. Bei drei Replikaten erfolgt das Commit der Speicherung nach der Bestätigung von der SSD des dritten Knotens. Es könnte den Anschein haben, dass die Schreibgeschwindigkeit der drei SSDs durch drei teilbar ist und wir die Schreibgeschwindigkeit eines Replikats erhalten, jedoch erfolgt die Erstellung der Kopien parallel, und die Netzwerk-Latenz ist in der Regel höher als die einer SSD, sodass die Schreibleistung letztlich vom Netzwerk abhängt. Daher ist es wichtig, das gesamte Vstorage entsprechend der , das heißt, eine echte Last zu testen und nicht den Speicher und den Cache, wobei die richtige Blockgröße, die Anzahl der Threads usw. berücksichtigt werden müssen.
Das zuvor erwähnte SSD-Protokoll funktioniert so, dass, sobald Daten eingehen, diese sofort von einem Dienst gelesen und auf HDD geschrieben werden. Im Cluster gibt es mehrere Metadaten-Dienste (MDS), deren Anzahl durch ein Quorum bestimmt wird, das nach dem Paxos-Algorithmus arbeitet. Aus Sicht des Kunden ist der FUSE-Mount-Punkt ein Ordner im Cluster-Speicher, der allen Knoten des Clusters gleichzeitig sichtbar ist. Jeder Knoten hat einen montierten Client, der nach diesem Prinzip funktioniert, sodass jedem Knoten dieser Speicher zur Verfügung steht.
Für die Leistung eines der oben beschriebenen Konzepte ist es entscheidend, bereits in der Planungs- und Implementierungsphase das Netzwerk korrekt einzurichten, in dem die Lasten durch Aggregation ausgeglichen werden, und die Bandbreite des Netzwerkkanals optimal auszuwählen. Bei der Aggregation ist es wichtig, den Hashing-Modus und die Frame-Größen richtig anzupassen. Ein wesentliches Merkmal, das sich von den zuvor genannten SDS unterscheidet, ist das Fuse mit der Fast-Path-Technologie in Virtuozzo Storage. Dieses verbessert nicht nur das moderne Fuse im Vergleich zu anderen Open-Source-Lösungen erheblich, sondern steigert auch die IOPS und ermöglicht es, nicht nur auf horizontale oder vertikale Skalierung beschränkt zu sein. Im Vergleich zu den genannten Architekturen wirkt diese deutlich leistungsfähiger, wobei für dieses Vergnügen selbstverständlich Lizenzen erworben werden müssen, im Gegensatz zu Ceph und Gluster.
Zusammenfassend lässt sich feststellen, dass die Top-Drei in Bezug auf Leistung und Zuverlässigkeit folgendermaßen aussehen: An erster Stelle steht Virtuozzo Storage, gefolgt von Ceph auf dem zweiten Platz und Gluster auf dem dritten.
Die Kriterien für die Auswahl von Virtuozzo Storage umfassen ein optimales Set an Architekturkomponenten, das für diesen Fuse-Ansatz mit Fast Path optimiert wurde, eine flexible Hardwarekonfiguration, geringeren Ressourcenverbrauch und die Möglichkeit der gemeinsamen Nutzung mit Compute (Berechnungen/Virtualisierung), was es ideal für hyperkonvergente Lösungen macht, zu denen es gehört. Auf dem zweiten Platz steht Ceph, da es eine leistungsfähigere Architektur im Vergleich zu Gluster besitzt, da es blockbasiert arbeitet und flexiblere Szenarien sowie die Möglichkeit der Nutzung in größeren Clustern bietet.
Es ist geplant, einen Vergleich zwischen vSAN, Space Direct Storage, Vstorage und Nutanix Storage zu schreiben sowie Vstorage auf HPE- und Huawei-Hardware zu testen und Integrationsszenarien von Vstorage mit externen Hardware-Storage Systemen zu untersuchen. Wenn Ihnen der Artikel gefallen hat, wäre es hilfreich, von Ihnen Rückmeldungen zu erhalten, die die Motivation für neue Artikel unter Berücksichtigung Ihrer Anmerkungen und Wünsche steigern könnten.
Quelle: habr.com
