Dieser Artikel wurde verfasst, um Ihnen bei der Auswahl der passenden Lösung zu helfen und die Unterschiede zwischen SDS wie Gluster, Ceph und Vstorage (Virtuozzo) zu verstehen.
Im Text finden Sie Links zu Artikeln, die bestimmte Probleme detaillierter behandeln, weshalb die Beschreibungen so kurz wie möglich gehalten werden, wobei die Schlüsselpunkte ohne überflüssige Informationen präsentiert werden. Diese Informationen können Sie sich bei Bedarf selbst im Internet holen.
Tatsächlich erfordern die behandelten Themen einen bestimmten Ton, aber in unserer modernen Welt lesen immer mehr Menschen nicht gerne viel))), daher kann man alles schnell überfliegen und eine Entscheidung treffen. Wenn etwas unklar ist, können Sie die Links besuchen oder nach den unbekannten Wörtern suchen))), und dieser Artikel fungiert als transparente Hülle für diese tiefgehenden Themen, die die Hauptpunkte jeder Lösung zeigt.
Gluster
Beginnen wir mit Gluster, das häufig von Herstellern hyperkonvergenter Plattformen mit SDS auf Open-Source-Basis in virtuellen Umgebungen verwendet wird. Es finden Sie auf der RedHat-Website im Bereich Storage, wo Sie zwischen zwei SDS-Optionen wählen können: Gluster oder Ceph.
Gluster besteht aus einem Stapel von Translatore – Diensten, die alle Arbeiten zur Verteilung von Dateien usw. erledigen. Brick – ist ein Dienst, der eine Festplatte verwaltet, Volume – ein Pool, der diese Bricks vereint. Dann folgt der Dienst zur Verteilung von Dateien in Gruppen mittels der Funktion DHT (Distributed Hash Table). Wir werden die Sharding-Funktion in der Beschreibung nicht behandeln, da in den weiter unten aufgeführten Links Probleme beschrieben werden, die mit ihr zusammenhängen.
Beim Schreiben wird die Datei vollständig im Brick abgelegt, und eine Kopie wird parallel auf einen Brick auf dem zweiten Server geschrieben. Die zweite Datei wird dann in die zweite Gruppe von zwei Bricks (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 treten die folgenden Probleme auf:
- Der Platz in den Gruppen wird ungleichmäßig genutzt, was von den Dateigrößen abhängt. Wenn in der Gruppe nicht genügend Platz zum Speichern der Datei vorhanden ist, erhalten Sie einen Fehler; die Datei wird nicht gespeichert und nicht in eine andere Gruppe umverteilt.
- Beim Schreiben einer Datei erfolgt IO nur auf einer Gruppe, die anderen stehen still;
- Es ist nicht möglich, IO für das gesamte Volume beim Schreiben einer Datei zu erhalten.
- Die allgemeine Konzeption erscheint weniger leistungsfähig aufgrund der fehlenden Datenverteilung über Blöcke, wo eine einfachere Lastverteilung und Lösung des Problems der gleichmäßigen Verteilung möglich sind, anstatt dass die Datei jetzt komplett in einem Block liegt.
Aus der offiziellen Beschreibung entsteht auch unweigerlich das Verständnis, dass Gluster wie ein Dateispeicher über klassischem Hardware-RAID funktioniert. Es gab Versuche, Dateien in Blöcke zu schneiden (Sharding), aber all dies ist ein Zusatz, der die Leistung des bereits bestehenden architektonischen Ansatzes beeinträchtigt, plus die Nutzung solcher frei verfügbaren Komponenten mit Leistungsbeschränkungen wie Fuse. Es gibt keine Metadaten-Services, was die Leistungsfähigkeit und Fehlertoleranz des Speichers beim Verteilen von Dateien auf Blöcke einschränkt. Bessere Leistungswerte können bei der Konfiguration „Distributed Replicated“ beobachtet werden, wobei die Anzahl der Knoten mindestens 6 betragen sollte, um eine zuverlässige 3-fache Replikation mit optimierter Lastverteilung zu organisieren.
Diese Erkenntnisse sind auch mit der Beschreibung der Nutzungserfahrungen und dem Vergleich mit , sowie der Beschreibung der Erfahrungen klar zu erkennen, wie man zu dieser leistungsfähigeren und zuverlässigeren Konfiguration gelangt
Die Abbildung zeigt die Lastverteilung beim Schreiben von zwei Dateien, wobei die Kopien der ersten Datei auf die ersten drei Server verteilt werden, die in die Gruppe Volume 0 integriert sind, und drei Kopien der zweiten Datei auf die zweite Gruppe Volume 1 aus drei Servern gelegt werden. Jeder Server hat eine Festplatte.
Die allgemeine Schlussfolgerung ist, dass Gluster verwendet werden kann, aber mit dem Verständnis, dass es Einschränkungen hinsichtlich der Leistung und Fehlertoleranz geben wird, die bei bestimmten Bedingungen einer hyperkonvergenten Lösung Probleme verursachen, da Ressourcen auch für die Rechenlasten virtueller Umgebungen benötigt werden.
Es gibt auch einige Leistungsindikatoren von Gluster, die unter bestimmten Bedingungen erreicht werden können, wobei man sich in
Ceph
Schauen wir uns nun Ceph anhand der Architekturbeschreibungen an, die ich finden konnte. Glusterfs und Ceph , где можно сразу понять что Ceph желательно разворачивать на отдельных серверах, так как его сервисам необходимы все ресурсы железа при нагрузках.
Architektur ist komplizierter als Gluster und es gibt Dienste wie Metadaten-Dienste, aber der gesamte Komponentenstack ist ziemlich komplex und nicht sehr flexibel für den Einsatz in Virtualisierungslösungen. Die Daten werden in Blöcken gespeichert, was produktiver aussieht, aber es gibt in der Hierarchie aller Dienste (Komponenten) Verluste und Latenzen unter bestimmten Lasten und in Notfallsituationen, als Beispiel das Folgende.
Aus der Beschreibung der Architektur ergibt sich, dass das Herzstück CRUSH ist, das den Speicherort der Daten auswählt. Dann kommt PG - dies ist die komplexeste Abstraktion (logische Gruppe) zu verstehen. PGs sind notwendig, damit CRUSH effektiver ist. Die Hauptaufgabe von PGs ist die Gruppierung von Objekten zur Reduzierung des Ressourcenverbrauchs, zur Erhöhung der Leistung und zur Skalierbarkeit. Die Adressierung von Objekten direkt, einzeln, ohne sie in PGs zusammenzufassen, wäre sehr ineffizient. OSD ist der Dienst für jede einzelne Festplatte.
Ein Cluster kann einen oder mehrere Pools für unterschiedliche Zwecke und mit unterschiedlichen Einstellungen haben. Die Pools werden in Placement-Gruppen unterteilt. In den Placement-Gruppen werden Objekte gespeichert, auf die die Clients zugreifen. Auf dieser logischen Ebene endet die Struktur und die physische Ebene beginnt, da jeder Placement-Gruppe eine Hauptfestplatte und mehrere Replikatspeicher zugeordnet sind (wie viele hängt vom Replikationsfaktor des Pools ab). Mit anderen Worten, auf der logischen Ebene wird ein Objekt in einer bestimmten Placement-Gruppe gespeichert, auf der physischen Ebene jedoch auf den Festplatten, die ihr zugeordnet sind. Dabei können die Festplatten physisch an verschiedenen Knoten oder sogar in verschiedenen Rechenzentren stehen.
In diesem Schema sehen Placement-Gruppen aus wie ein notwendiges Element für die Flexibilität der gesamten Lösung, sind aber gleichzeitig ein überflüssiges Glied in dieser Kette, was unweigerlich Gedanken über den Verlust an Leistung aufwirft. Beispielsweise muss das System beim Schreiben von Daten diese in Gruppen aufteilen und dann auf physischer Ebene auf das Hauptlaufwerk und auf die Laufwerke für Replikate verteilen. Das bedeutet, dass die Hash-Funktion beim Suchen und Einfügen von Objekten funktioniert, aber es gibt einen Nebeneffekt – sehr hohe Kosten und Einschränkungen beim Neuaufbau des Hashes (beim Hinzufügen oder Entfernen eines Laufwerks). Ein weiteres Problem der Hash-Funktion ist die festgelegte Position der Daten, die nicht verändert werden kann. Wenn also ein Laufwerk übermäßig belastet wird, hat das System nicht die Möglichkeit, nicht auf dieses zu schreiben (ein anderes Laufwerk auszuwählen), die Hash-Funktion zwingt dazu, die Daten nach einer Regel zu platzieren, unabhängig davon, wie schlecht es dem Laufwerk geht. Daher verbraucht Ceph viel Speicher beim Neuaufbau von PG im Falle von Self-Healing oder bei der Erweiterung des Speichers. Das Fazit ist, dass Ceph gut (wenn auch langsam) funktioniert, aber nur solange kein Skalierungsbedarf, Notfälle oder Updates vorliegen.
Es gibt natürlich Möglichkeiten zur Leistungssteigerung durch Caching und Cache-Tiering, aber dafür ist eine gute Hardware erforderlich und es wird dennoch Verluste geben. Insgesamt sieht Ceph jedoch für produktive Umgebungen attraktiver aus als Gluster. Bei der Verwendung dieser Produkte muss auch ein nicht unwesentlicher Faktor berücksichtigt werden – das hohe Niveau an Kompetenzen, Erfahrung und Professionalität mit einem großen Fokus auf Linux, da es entscheidend ist, alles korrekt bereitzustellen, zu konfigurieren und zu warten, was noch mehr Verantwortung und Belastung für den Administrator mit sich bringt.
Vstorage
Die Architektur von , die zusammen mit dem Hypervisor auf denselben Knoten und derselben , ist noch interessanter, aber es ist sehr wichtig, alles richtig zu konfigurieren, um eine gute Leistung zu erzielen. Es ist also sehr einfach, ein solches Produkt ohne Berücksichtigung der Empfehlungen gemäß der Architektur aus der Box auf irgendeiner Konfiguration bereitzustellen, aber es wird nicht leistungsfähig sein.
Was kann neben den Hypervisor-Diensten kvm-qemu coexistieren? Es handelt sich nur um einige Dienste, wo eine kompakte, optimale Hierarchie von Komponenten gefunden wurde: der über FUSE montierte Client-Service (modifiziert, nicht Open Source), der Metadaten-Service MDS (Metadata Service), der Chunk Service, der auf physikalischer Ebene einer Festplatte entspricht, und das war's auch schon. In Bezug auf die Geschwindigkeit ist es natürlich optimal, ein ausfallsicheres Schema mit zwei Replikaten zu verwenden, aber wenn Caching und Journale auf SSDs eingesetzt werden, kann die fehlertolerante Kodierung (Erasure Coding oder RAID 6) auf einem hybriden Schema oder sogar besser auf All-Flash-Systemen ordentlich beschleunigt werden. Mit EC (Erasure Coding) gibt es jedoch einen Nachteil: Bei der Änderung eines Datenblocks müssen die Paritätsbeträge neu berechnet werden. Um Verzögerungen bei diesem Vorgang zu vermeiden, schreibt Ceph in EC verzögert und es kann zu Leistungsproblemen bei bestimmten Anfragen kommen, wenn beispielsweise alle Blöcke gelesen werden müssen. Im Gegensatz dazu erfolgt die Aufzeichnung geänderter Blöcke in Virtuozzo Storage unter Verwendung des „log-structured file system“-Ansatzes, was die Berechnungskosten für die Parität minimiert. Um ungefähr Optionen mit Beschleunigung der Arbeit bei EC und ohne zu bewerten, gibt es – die Zahlen können ungefähr sein, abhängig vom Genauigkeitsfaktor des Geräteherstellers, aber die Ergebnisse der Berechnungen helfen gut bei der Planung der Konfiguration.
Ein einfaches Speicherkonzeptschema bedeutet nicht, dass diese Komponenten keine aber wenn man alle Ausgaben im Voraus berechnet, kann man mit der gemeinsamen Arbeit neben dem Hypervisor rechnen.
Es gibt ein Schema zum Vergleich des Ressourcenverbrauchs von Ceph-Diensten und Virtuozzo Storage.
Früher war es einfacher, Gluster und Ceph anhand alter Artikel zu vergleichen, indem man die wichtigsten Zeilen daraus verwendete, aber mit Virtuozzo ist es komplizierter. Es gibt nicht viele Artikel zu diesem Produkt, und Informationen können nur aus der Dokumentation auf oder auf Russisch bezogen werden, wenn wir Vstorage als Speicher betrachten, der in einigen hyperkonvergenten Lösungen in Unternehmen wie und Acronis verwendet wird.
Ich werde versuchen, die Beschreibung dieser Architektur zu helfen, daher wird der Text etwas länger sein, aber um die Dokumentation selbst zu verstehen, benötigt man viel Zeit, und die vorhandene Dokumentation kann nur als Nachschlagewerk durch das Durchsehen des Inhaltsverzeichnisses oder durch die Suche nach Stichwörtern verwendet werden.
Betrachten wir den Prozess der Aufzeichnung in einer hybriden Hardware-Konfiguration mit den oben beschriebenen Komponenten: Die Aufzeichnung beginnt auf dem Knoten, von dem der Kunde sie initiiert hat (Dienstpunkt FUSE), aber der Master-Dienst des Metadaten-Dienstes (MDS) wird den Kunden natürlich direkt zum benötigten Chunk-Service (Block Storage Service) leiten, das heißt, MDS ist nicht am Schreibprozess beteiligt, sondern leitet einfach zum notwendigen Chunk-Service. Man kann das Schreibverfahren mit dem Ausgießen von Wasser in Fässern vergleichen. Jedes Fass ist ein Datenblock von 256 MB.
Das bedeutet, dass eine Festplatte eine bestimmte Anzahl solcher Fässer ist, d.h. das Volumen der Festplatte geteilt durch 256 MB. Jede Kopie wird auf einen Knoten verteilt, die zweite fast parallel auf einen anderen Knoten usw. Wenn wir drei Repliken haben und SSDs für den Cache (zum Lesen und für das Schreibprotokoll) vorhanden sind, dann wird die Bestätigung der Aufzeichnung nach dem Schreiben des Protokolls in die SSD erfolgen, während die parallele Übertragung von der SSD auf die HDD im Hintergrund weiterläuft. Bei drei Repliken erfolgt das Commit der Aufzeichnung nach der Bestätigung von der SSD des dritten Knotens. Es könnte scheinen, dass die Gesamtgeschwindigkeit des Schreibens von drei SSDs durch drei geteilt werden kann und wir die Schreibgeschwindigkeit einer Replik erhalten, aber das Schreiben der Kopien erfolgt parallel, und die Latenzgeschwindigkeit des Netzwerks ist in der Regel höher als die der SSD, und im Wesentlichen wird die Schreibleistung vom Netzwerk abhängen. Aus diesem Grund ist es notwendig, die gesamte Vstorage gemäß , also die tatsächliche Last zu testen, nicht den Speicher und den Cache, wobei die richtige Blockgröße, die Anzahl der Streams usw. berücksichtigt werden müssen.
Das oben erwähnte Protokoll auf SSD funktioniert so, dass, sobald Daten eingehen, diese sofort von einem Dienst gelesen und auf die HDD geschrieben werden. Es gibt mehrere Metadaten-Dienste (MDS) pro Cluster, und deren Anzahl wird durch ein Quorum bestimmt, das nach dem Paxos-Algorithmus arbeitet. Aus der Sicht des Clients ist der FUSE-Mountpunkt ein Ordner des Cluster-Speichers, der für alle Knoten des Clusters gleichzeitig sichtbar ist. Jeder Knoten hat einen Mount-Client nach diesem Prinzip, sodass jeder Knoten auf diesen Speicher zugreifen kann.
Für die Leistungsfähigkeit eines der oben beschriebenen Ansätze ist es sehr wichtig, im Planungs- und Bereitstellungsprozess das Netzwerk korrekt zu konfigurieren, in dem das Lastenausgleich durch Aggregation und die richtig ausgewählte Bandbreite des NetzwerkkChannels erfolgt. Bei der Aggregation ist es wichtig, den Hashing-Modus und die Frame-Größen richtig auszuwählen. Es gibt auch einen sehr starken Unterschied zu den oben beschriebenen SDS, nämlich den FUSE mit der Fast-Path-Technologie in Virtuozzo Storage. Dieser bringt, im Gegensatz zu anderen Open-Source-Lösungen, erheblich mehr IOPS und ermöglicht eine unbegrenzte horizontale oder vertikale Skalierung. Im Vergleich zu den oben beschriebenen Architekturen sieht diese leistungsfähiger aus, jedoch müssen für diesen Komfort Lizenzen erworben werden, im Gegensatz zu Ceph und Gluster.
Zusammenfassend lässt sich sagen, dass die Top drei nach Leistung und Zuverlässigkeit in der Architektur wie folgt aussehen: An erster Stelle steht Virtuozzo Storage, gefolgt von Ceph auf dem zweiten Platz und Gluster auf dem dritten Platz.
Kriterien, nach denen Virtuozzo Storage gewählt wurde: ein optimales Set an Architekturkomponenten, ein verbessertes FUSE mit Fast-Path-Technologie, ein flexibler Hardware-Konfigurationssatz, geringerer Ressourcenverbrauch und die Möglichkeit der gemeinsamen Nutzung mit Compute (Berechnungen/Virtualisierung), was es vollständig für eine hyperkonvergente Lösung geeignet macht, zu der es gehört. Der zweite Platz geht an Ceph, da es eine leistungsfähigere Architektur im Vergleich zu Gluster ist, basierend auf Blockoperationen sowie flexibleren Szenarien und der Möglichkeit, in größeren Clustern zu arbeiten.
In den Plänen besteht der Wunsch, einen Vergleich zwischen vSAN, Space Direct Storage, Vstorage und Nutanix Storage zu erstellen, Vstorage auf HPE- und Huawei-Hardware zu testen sowie Integrationsszenarien von Vstorage mit externen Hardware-SANs zu untersuchen. Daher wäre es schön, von Ihnen Feedback zu erhalten, wenn Ihnen der Artikel gefallen hat, um die Motivation für neue Artikel unter Berücksichtigung Ihrer Anmerkungen und Wünsche zu stärken.
Quelle: habr.com
