Hyperkonvergente Lösung AERODISK vAIR. Basis ist das Dateisystem ARDFS

Hallo, Leser von Habr. Mit diesem Artikel eröffnen wir einen Zyklus, der über unser entwickeltes hyperkonvergentes System AERODISK vAIR berichten wird. Ursprünglich wollten wir in dem ersten Artikel alles über alles erzählen, aber das System ist recht komplex, also werden wir den Elefanten Stück für Stück essen.

Wir beginnen die Erzählung mit der Geschichte der Entstehung des Systems, vertiefen uns in das Dateisystem ARDFS, das die Grundlage von vAIR bildet, und philosophieren ein wenig über die Positionierung dieser Lösung auf dem russischen Markt.

In den weiteren Artikeln werden wir detaillierter über verschiedene architektonische Komponenten (Cluster, Hypervisor, Lastenausgleich, Überwachungssystem usw.) sprechen, den Einstellungsprozess behandeln, Lizenzfragen ansprechen, gesondert Crash-Tests zeigen und natürlich über Lasttests und Sizing schreiben. Ein separater Artikel wird der Community-Version von vAIR gewidmet sein.

Ist AERODISK eine Art Geschichte über Speichersysteme? Oder warum haben wir überhaupt mit hyperkonvergenten Systemen angefangen?

Ursprünglich kam uns die Idee, unser eigenes Hyperkonvergenzsystem zu schaffen, etwa im Jahr 2010. Damals gab es weder AERODISK noch ähnliche Lösungen (kommerzielle, stationäre hyperkonvergente Systeme) auf dem Markt. Unsere Aufgabe war folgende: Aus einer Gruppe von Servern mit lokalen Festplatten, die durch Ethernet-Interconnect verbunden sind, ein verteiltes Speichersystem zu schaffen und dort auch virtuelle Maschinen und ein Software-Netzwerk zu betreiben. Alles musste ohne Speichersysteme (da wir einfach kein Geld dafür hatten und unser eigenes Speichersystem damals noch nicht erfunden war) realisiert werden.

Wir haben viele Open-Source-Lösungen ausprobiert und haben das Problem letztendlich gelöst, aber die Lösung war sehr kompliziert und schwer zu reproduzieren. Darüber hinaus war diese Lösung aus der Kategorie „Läuft? Nicht anfassen!“. Daher haben wir, nachdem wir dieses Problem gelöst haben, die Idee verworfen, das Ergebnis unserer Arbeit in ein vollwertiges Produkt zu verwandeln.

Nach diesem Vorfall haben wir von dieser Idee Abstand genommen, aber das Gefühl, dass dieses Problem durchaus lösbar ist und der Nutzen einer solchen Lösung mehr als offensichtlich ist, ließ uns nicht los. In der Folge haben die auf den Markt gekommenen HCI-Produkte ausländischer Firmen dieses Gefühl nur bestätigt.

Deshalb haben wir Mitte 2016 diese Aufgabe im Rahmen der Entwicklung eines vollwertigen Produkts wieder aufgegriffen. Zu diesem Zeitpunkt hatten wir noch keine Beziehungen zu Investoren, weshalb wir den Entwicklungsstand für unser nicht ganz so großes Budget kaufen mussten. Wir haben auf Avito nach gebrauchten Servern und Switches gesucht und uns ans Werk gemacht.

Die Hauptanfangsaufgabe bestand darin, ein einfaches, eigenes Dateisystem zu schaffen, das in der Lage war, Daten automatisch und gleichmäßig in Form von virtuellen Blöcken auf einer beliebigen Anzahl von Knoten des Clusters zu verteilen, die über Ethernet verbunden sind. Dabei sollte das Dateisystem gut und einfach skalierbar sein und unabhängig von benachbarten Systemen existieren, d.h. es sollte als "einfacher Speicher" vom vAIR abtrennbar sein.

Das erste Konzept von vAIR

Wir haben bewusst darauf verzichtet, fertige Open-Source-Lösungen für die Organisation eines verteilten Speichers (Ceph, Gluster, Lustre und ähnliche) zu verwenden, und uns stattdessen für unsere eigene Entwicklung entschieden, da wir bereits viel Projekt-Erfahrung mit diesen Lösungen hatten. Diese Lösungen sind zweifellos hervorragend, und vor der Arbeit an Aerodisk haben wir zahlreiche Integrationsprojekte mit ihnen realisiert. Aber es ist etwas anderes, eine spezifische Aufgabe für einen Kunden umzusetzen, das Personal zu schulen und möglicherweise den Support eines großen Anbieters zu kaufen, und etwas ganz anderes, ein leicht reproduzierbares Produkt zu schaffen, das für unterschiedliche Aufgaben verwendet wird, die wir als Anbieter möglicherweise nicht einmal selbst kennen. Für diesen zweiten Zweck waren die bestehenden Open-Source-Produkte für uns nicht geeignet, weshalb wir beschlossen haben, das verteilte Dateisystem selbst zu entwickeln.
Nach zwei Jahren Arbeit von mehreren Entwicklern (die ihre Arbeit an vAIR mit der Arbeit an der klassischen Speicher-Engine kombinierten) erzielten wir bestimmte Ergebnisse.

Bis 2018 hatten wir ein einfaches Dateisystem geschrieben und es mit der notwendigen Anbindung ergänzt. Das System vereinte über interne Interconnects physische (lokale) Festplatten von verschiedenen Servern zu einem flachen Pool und "schnitt" sie in virtuelle Blöcke. Aus diesen virtuellen Blöcken wurden Blockgeräte mit unterschiedlichem Ausmaß an Fehlertoleranz erstellt, auf denen mithilfe des KVM-Hypervisors virtuelle Maschinen erstellt und ausgeführt wurden.

Wir haben uns nicht lange mit dem Namen des Dateisystems aufgehalten und es ARDFS genannt (raten Sie mal, wofür das steht))

Dieser Prototyp machte einen guten Eindruck (nicht visuell, natürlich, eine visuelle Gestaltung gab es damals noch nicht) und zeigte gute Ergebnisse in Bezug auf Leistung und Skalierbarkeit. Nach dem ersten realen Ergebnis haben wir diesem Projekt grünes Licht gegeben, eine vollständige Entwicklungsumgebung und ein eigenes Team einzurichten, das sich ausschließlich mit vAIR beschäftigt hat.

Zu diesem Zeitpunkt war die allgemeine Architektur der Lösung ausgereift, die bis heute keine wesentlichen Änderungen erfahren hat.

Wir tauchen in das Dateisystem ARDFS ein

ARDFS bildet die Grundlage von vAIR und sorgt für eine verteilte, ausfallsichere Speicherung der Daten des gesamten Clusters. Eine der (aber nicht die einzige) besonderen Eigenschaften von ARDFS ist, dass es keine zusätzlichen dedizierten Servern unter Metaund Verwaltung verwendet. Dies wurde ursprünglich zur Vereinfachung der Konfiguration der Lösung und für ihre Zuverlässigkeit vorgesehen.

Speicherstruktur

Im Rahmen aller Knoten des Clusters organisiert ARDFS einen logischen Pool aus dem gesamten verfügbaren Speicherplatz. Es ist wichtig zu verstehen, dass ein Pool noch keine Daten und keinen formatierten Speicher darstellt, sondern einfach eine Struktur ist, d. h. alle Knoten mit installiertem vAIR werden beim Hinzufügen zum Cluster automatisch zum gemeinsamen Pool von ARDFS hinzugefügt und die Speicherressourcen werden automatisch gemeinschaftlich für das gesamte Cluster verfügbar (und sind für zukünftige Datenspeicherungen zugänglich). Dieser Ansatz ermöglicht das Hinzufügen und Entfernen von Knoten im laufenden Betrieb, ohne ernsthafte Auswirkungen auf das bereits funktionierende System zu haben. Das heißt, das System ist sehr einfach mit „Bausteinen“ zu skalieren, indem Knoten im Cluster nach Bedarf hinzugefügt oder entfernt werden.

Über dem Pool von ARDFS werden virtuelle Festplatten (Speicherobjekte für virtuelle Maschinen) hinzugefügt, die aus virtuellen Blöcken mit einer Größe von 4 Megabyte aufgebaut sind. Auf den virtuellen Festplatten werden die Daten direkt gespeichert. Auf der Ebene der virtuellen Festplatten wird ebenfalls ein Schema zur Ausfallsicherheit festgelegt.

Wie bereits zu vermuten war, verwenden wir zur Ausfallsicherheit des Speichersystems nicht das Konzept RAID (Redundant Array of Independent Disks), sondern RAIN (Redundant Array of Independent Nodes). Das bedeutet, die Ausfallsicherheit wird anhand der Knoten und nicht der Festplatten gemessen, automatisiert und verwaltet. Festplatten sind selbstverständlich auch Objekte des Speichers, sie werden, wie alles andere auch, überwacht, und mit ihnen können alle Standardoperationen durchgeführt werden, einschließlich der Erstellung eines lokalen Hardware-RAID, aber das Cluster arbeitet ausschließlich mit Knoten.

In einer Situation, in der man sich sehr nach RAID sehnt (zum Beispiel in einem Szenario, das mehrere Ausfälle in kleinen Clustern unterstützt), steht es nichts im Wege, lokale RAID-Controller zu verwenden und darüber ein verteiltes Speicher- und RAIN-Architektur zu erstellen. Ein solches Szenario ist durchaus lebendig und wird von uns unterstützt, deshalb werden wir in dem Artikel über typische Anwendungsszenarien von vAIR darüber sprechen.

Schemas zur Ausfallsicherheit des Speichers

Es kann zwei Arten von Ausfallsicherheitsschemata für virtuelle Festplatten in vAIR geben:

1) Replikationsfaktor oder einfach Replikation – diese Methode der Ausfallsicherheit ist so einfach „wie ein Stock und ein Seil“. Es wird eine synchrone Replikation zwischen den Knoten mit einem Faktor von 2 (2 Kopien pro Cluster) oder 3 (3 Kopien entsprechend) durchgeführt. RF-2 ermöglicht es der virtuellen Festplatte, den Ausfall eines Knotens im Cluster zu überstehen, verbraucht aber die Hälfte des nützlichen Volumens, während RF-3 den Ausfall von 2 Knoten im Cluster übersteht, jedoch bereits 2/3 des nützlichen Volumens für sich reserviert. Dieses Schema erinnert stark an RAID-1, das heißt, eine virtuelle Festplatte, die in RF-2 konfiguriert ist, ist gegen den Ausfall eines beliebigen Knotens des Clusters resistent. In diesem Fall sind die Daten in Ordnung, und sogar die Ein- und Ausgabe wird nicht unterbrochen. Wenn der ausgefallene Knoten wieder in Betrieb ist, beginnt die automatische Wiederherstellung/Synchronisierung der Daten.

Nachfolgend sind Beispiele für die Verteilung von Daten in RF-2 und RF-3 im Normalbetrieb und im Falle von Ausfällen aufgeführt.

Wir haben eine virtuelle Maschine mit 8 MB einzigartiger (nützlicher) Daten, die auf 4 vAIR-Knoten läuft. Es ist klar, dass in der Realität wahrscheinlich nicht so wenig Speicherplatz vorhanden sein wird, aber für das Diagramm, das die Funktionsweise von ARDFS darstellt, ist dieses Beispiel am verständlichsten. AB sind virtuelle Blöcke von 4 MB, die einzigartige Daten der virtuellen Maschine enthalten. Bei RF-2 werden zwei Kopien dieser Blöcke A1+A2 und B1+B2 erstellt. Diese Blöcke werden auf den Knoten verteilt, wobei Überschneidungen derselben Daten auf einem Knoten vermieden werden, das heißt, die Kopie A1 wird nicht auf demselben Knoten wie die Kopie A2 sein. Bei B1 und B2 ist es ähnlich.

Im Falle eines Ausfalls eines der Knoten (zum Beispiel Knoten Nr. 3, auf dem sich die Kopie B1 befindet) wird diese Kopie automatisch auf dem Knoten aktiviert, auf dem keine Kopie ihrer Kopie vorhanden ist (also der Kopie B2).

Somit übersteht die virtuelle Festplatte (und die VM entsprechend) problemlos den Ausfall eines Knotens im RF-2-Schema.

Das Schema mit Replikation leidet bei seiner Einfachheit und Zuverlässigkeit unter demselben Problem wie RAID1 – es gibt wenig nutzbaren Speicherplatz.

2) Erasure Coding oder Löschkodierung (auch bekannt als ‚exzessive Kodierung‘, ‚löschende Kodierung‘ oder ‚Redundanzkode‘) existiert genau, um das oben genannte Problem zu lösen. EC ist ein Schema der Redundanz, das eine hohe Datenverfügbarkeit bei geringeren Kosten für Speicherplatz im Vergleich zur Replikation gewährleistet. Das Prinzip dieses Mechanismus ähnelt RAID 5, 6, 6P.

Beim Kodieren teilt der EC-Prozess den virtuellen Block (standardmäßig 4 MB) in mehrere kleinere ‚Datenstücke‘ je nach EC-Schema auf (zum Beispiel teilt das 2+1-Schema jeden 4 MB Block in 2 Stücke zu je 2 MB). Danach generiert dieser Prozess für die ‚Datenstücke‘ ‚Paritätsstücke‘ von nicht mehr als einem der zuvor geteilten Teile. Bei der Dekodierung generiert EC die fehlenden Stücke, indem es die ‚übrig gebliebenen‘ Daten über den gesamten Cluster liest.

Ein Beispiel ist eine virtuelle Festplatte mit dem EC-Schema 2 + 1, die auf 4 Knoten eines Clusters implementiert ist. Diese wird den Ausfall eines Knotens im Cluster ebenso gut überstehen wie RF-2. Dabei sind die Kosten geringer; insbesondere beträgt der Nutzkostenfaktor bei RF-2 2, während er bei EC 2+1 1,5 beträgt.

Einfacher ausgedrückt besteht der Kern darin, dass der virtuelle Block in 2-8 (warum von 2 bis 8, siehe unten) ‚Stücke‘ aufgeteilt wird, und für diese Stücke werden ‚Stücke‘ der Parität gleichen Volumens berechnet.

Letztendlich werden die Daten und ihre Parität gleichmäßig auf alle Knoten des Clusters verteilt. Dabei verteilt ARDFS, ähnlich wie bei der Replikation, die Daten automatisch auf die Knoten, um sicherzustellen, dass keine identischen Daten (Kopien der Daten und ihrer Parität) auf einem Knoten gespeichert werden, um das Risiko zu vermeiden, dass Daten verloren gehen, weil sowohl die Daten als auch ihre Parität plötzlich auf einem Knoten gespeichert sind, der ausfällt.

Unten ein Beispiel mit derselben virtuellen Maschine von 8 MB und 4 Knoten, jedoch bei einem EC-Schema von 2+1.

Die Blöcke A und B werden jeweils in zwei Stücke von 2 MB aufgeteilt (in zwei Teilen, weil 2+1), also in A1+A2 und B1+B2. Im Gegensatz zur Replikation ist A1 keine Kopie von A2; es handelt sich um einen virtuellen Block A, der in zwei Teile geteilt wurde, ebenso wie der Block B. Insgesamt erhalten wir zwei Sätze von je 4 MB, in denen jeweils zwei zwei-MB-Stücke enthalten sind. Für jeden dieser Sätze wird die Parität in einer Größe von nicht mehr als einem Stück (d.h. 2 MB) berechnet, sodass zusätzlich 2 Paritätsstücke (A-P und B-P) entstehen. Insgesamt haben wir 4×2 Daten + 2×2 Parität.

Die Stücke werden dann so auf die Knoten verteilt, dass die Daten nicht mit ihrer Parität überschneiden. Das heißt, A1 und A2 werden nicht auf demselben Knoten mit A-P liegen.

Im Falle eines Ausfalls eines Knotens (nehmen wir an, es ist auch der dritte) wird der ausgefallene Block B1 automatisch aus der Parität B-P, die auf Knoten Nr. 2 gespeichert ist, wiederhergestellt und wird auf dem Knoten aktiviert, auf dem keine B-Parität vorhanden ist, d.h. das Stück B-P. In diesem Beispiel ist das Knoten Nr. 1.

Ich bin sicher, der Leser stellt sich die Frage:

„Alles, was Sie beschrieben haben, wurde bereits von Wettbewerbern sowie in Open-Source-Lösungen umgesetzt; was unterscheidet Ihre EC-Implementierung in ARDFS?“

Und dann folgen interessante Funktionsweisen von ARDFS.

Erasure Coding mit Fokus auf Flexibilität

Ursprünglich haben wir ein ziemlich flexibles EC-Schema X+Y vorgesehen, wobei X von 2 bis 8 reicht und Y von 1 bis 8, jedoch immer kleiner oder gleich X. Dieses Schema ist für Flexibilität ausgelegt. Die Erhöhung der Anzahl der Datenstücke (X), in die ein virtueller Block geteilt wird, verringert die Overhead-Kosten, also erhöht den nutzbaren Speicherplatz.
Die Erhöhung der Anzahl der Paritätsstücke (Y) erhöht die Zuverlässigkeit der virtuellen Festplatte. Je höher der Wert von Y, desto mehr Knoten im Cluster können ausfallen. Natürlich verringert eine größere Parität den verfügbaren Speichervolumen, aber das ist der Preis für Zuverlässigkeit.

Die Abhängigkeit der Leistung von den EC-Schemata ist nahezu linear: Je mehr „Stücke“, desto niedriger die Leistung; dabei ist ein ausgewogener Blick notwendig.

Dieser Ansatz ermöglicht es den Administratoren, das verteilte Speichergebiet maximal flexibel zu konfigurieren. Innerhalb des ARDFS-Pools können beliebige Ausfallsicherheitsschemata und deren Kombinationen verwendet werden, was ebenfalls sehr nützlich ist.

Im Folgenden finden Sie eine Vergleichstabelle mehrerer (nicht aller möglichen) RF- und EC-Schemata.

Aus der Tabelle geht hervor, dass selbst die komplexeste Kombination EC 8+7, die den Verlust von bis zu 7 Knoten im Cluster zulässt, weniger nutzbaren Speicherplatz „verbraucht“ (1,875 gegenüber 2) als die Standardreplikation, während sie gleichzeitig 7-mal besser schützt. Dies macht diesen Schutzmechanismus zwar komplexer, aber deutlich attraktiver in Situationen, in denen maximale Zuverlässigkeit bei begrenztem Speicherplatz erforderlich ist. Dabei ist zu beachten, dass jeder „Pluspunkt“ zu X oder Y zusätzliche Leistungsüberhänge mit sich bringt, weshalb in dem Dreieck zwischen Zuverlässigkeit, Wirtschaftlichkeit und Leistung sehr sorgfältig gewählt werden muss. Aus diesem Grund widmen wir einen separaten Artikel dem Sizing der entfernten Kodierung.

Zuverlässigkeit und Autonomie des Dateisystems

ARDFS wird lokal auf allen Knoten des Clusters gestartet und synchronisiert sie über dedizierte Ethernet-Schnittstellen eigenständig. Ein wichtiger Punkt ist, dass ARDFS nicht nur Daten, sondern auch die Metadaten zum Speicher selbst synchronisiert. Während der Arbeit an ARDFS haben wir gleichzeitig verschiedene bestehende Lösungen untersucht und festgestellt, dass viele die Synchronisierung der Metadaten des Dateisystems mit einer externen verteilten Datenbank, die wir ebenfalls zur Synchronisierung verwenden, durchführen – jedoch nur für Konfigurationen und nicht für die Metadaten des Dateisystems (darüber und über andere verwandte Subsysteme wird im nächsten Artikel berichtet).

Die Synchronisierung der Metadaten des FS mithilfe einer externen DB ist natürlich eine funktionierende Lösung, aber dann würde die Konsistenz der auf ARDFS gespeicherten Daten von der externen DB und ihrem Verhalten abhängen (und sie ist, um ehrlich zu sein, eine launische Dame), was wir als schlecht erachten. Warum? Wenn die Metadaten des FS beschädigt werden, können auch die eigentlichen Daten des FS "Lebewohl" sagen, daher haben wir beschlossen, einen komplizierteren, aber zuverlässigeren Weg zu gehen.

Das Subsystem zur Synchronisierung der Metadaten für ARDFS haben wir selbst entwickelt, und es funktioniert völlig unabhängig von den angrenzenden Subsystemen. d.h. kein anderes Subsystem kann die Daten von ARDFS beschädigen. Unserer Meinung nach ist dies der zuverlässigste und richtige Weg, ob das tatsächlich so ist, wird die Zeit zeigen. Darüber hinaus bietet dieser Ansatz einen zusätzlichen Vorteil. ARDFS kann unabhängig von vAIR verwendet werden, einfach als erweitertes Speicher, was wir in zukünftigen Produkten sicherlich nutzen werden.

Insgesamt haben wir mit der Entwicklung von ARDFS ein flexibles und zuverlässiges Dateisystem erhalten, das die Wahl bietet, wo man bei der Kapazität sparen oder alles auf Leistung setzen kann, oder das Speicher extrem zuverlässig zu einem gemäßigten Preis machen kann, wodurch die Leistungsanforderungen gesenkt werden.

Gemeinsam mit einer einfachen Lizenzierungsrichtlinie und einem flexiblen Liefermodell (um vorzugreifen, vAIR wird pro Node lizenziert und entweder als Software oder als PAK geliefert) ermöglicht dies, die Lösung sehr präzise auf die unterschiedlichen Anforderungen der Kunden zuzuschneiden und diesen Ausgleich in Zukunft leicht aufrechtzuerhalten.

Für wen ist dieses Wunder nötig?

Einerseits könnte man sagen, dass es bereits Spieler auf dem Markt gibt, die ernsthafte Lösungen im Bereich Hyperkonvergenz haben, und wo wir eigentlich einsteigen. Diese Aussage scheint wahr zu sein, ABER...

Andererseits sehen wir, wenn wir "ins Feld" gehen und mit Kunden sprechen, dass dies überhaupt nicht der Fall ist. Es gibt viele Aufgaben für Hyperkonvergenz; an einigen Stellen wussten die Leute einfach nicht, dass es solche Lösungen gibt, woanders erschien es teuer, an anderen Orten gab es missratene Tests alternativer Lösungen, und woanders wird der Kauf ganz verboten, wegen der Sanktionen. Das Feld stellte sich als unbefestigt heraus, daher haben wir uns entschlossen, den Boden zu bestellen))).

Wann ist ein HDD besser als ein GK?

Im Verlauf der Arbeit mit dem Markt fragen uns viele oft, wann man am besten das klassische Schema mit einem SCSI-Array anwendet und wann eine hyperkonvergente Lösung? Viele Unternehmen — Hersteller von hyperkonvergenten Infrastrukturen (insbesondere solche, die kein SCSI-Array im Portfolio haben) sagen: „SCSI-Arrays haben ausgedient, nur hyperkonvergente Lösungen!“. Diese kühne Aussage spiegelt jedoch nicht ganz die Realität wider.

Ehrlich gesagt, der Markt für SCSI-Arrays wandert tatsächlich in Richtung hyperkonvergenter und ähnlicher Lösungen, aber es gibt immer ein 'aber'.

Erstens, die bereits gebauten Rechenzentren und IT-Infrastrukturen im klassischen SCSI-Array-Schema lassen sich nicht mal eben umstellen, daher ist die Modernisierung und der Ausbau solcher Infrastrukturen noch ein Erbe für die nächsten 5-7 Jahre.

Zweitens, die Infrastrukturen, die momentan in der Mehrheit (gemeint ist die Russische Föderation) gebaut werden, sind im klassischen Schema mit SCSI-Arrays und das nicht, weil die Leute nichts von hyperkonvergenten Lösungen wissen, sondern weil der Markt für hyperkonvergente Lösungen neu ist, die Lösungen und Standards noch nicht etabliert sind, die IT-Spezialisten noch nicht geschult sind, es wenig Erfahrung gibt, und man Rechenzentren hier und jetzt bauen muss. Diese Tendenz wird noch weitere 3-5 Jahre anhalten (und dann kommt noch das Erbe, siehe Punkt 1).

Drittens gibt es rein technisch gesehen, eine kleine Einschränkung durch zusätzliche Verzögerungen von 2 Millisekunden beim Schreiben (ohne Berücksichtigung des lokalen Caches, versteht sich), die für die verteilte Speicherung zu zahlen sind.

Und man sollte auch nicht die Verwendung großer physischer Server vergessen, die vertikale Skalierung der Speichersubsysteme bevorzugen.

Es gibt viele erforderliche und beliebte Aufgaben, bei denen SCSI-Arrays besser abschneiden als hyperkonvergente Lösungen. Natürlich werden die Hersteller, die kein SCSI-Array im Produktportfolio haben, dem nicht zustimmen, aber wir sind bereit, argumentiert zu streiten. Selbstverständlich werden wir als Entwickler beider Produkte in einer der kommenden Veröffentlichungen einen Vergleich zwischen SCSI-Arrays und hyperkonvergenten Lösungen durchführen, bei dem wir anschaulich zeigen, welche Lösung unter welchen Bedingungen besser geeignet ist.

Und wo werden hyperkonvergente Lösungen besser als SCSI-Arrays funktionieren?

Aus den obigen Thesen lassen sich drei offensichtliche Schlussfolgerungen ziehen:

1. Dort, wo zusätzliche 2 Millisekunden Verzögerung beim Schreiben, die konstant in jeder Produktivumgebung auftreten (es geht hier nicht um synthetische Tests, da kann man auch Nanosekunden zeigen), nicht kritisch sind, wird eine hyperkonvergente Lösung geeignet sein.
2. Dort, wo die Belastung großer physischer Server in viele kleine virtuelle Server umgewandelt und auf Knoten verteilt werden kann, wird auch hyperkonvergente Technologie gut ankommen.
3. Dort, wo horizontale Skalierung wichtiger ist als vertikale, wird auch hyperkonvergente Infrastruktur hervorragend funktionieren.

Was sind das für Lösungen?

1. Alle standardmäßigen Infrastrukturleistungen (Verzeichnisdienste, E-Mail, Dokumentenmanagement, Dateiserver, kleine oder mittlere ERP- und BI-Systeme usw.). Wir bezeichnen das als „gemeinsame Berechnungen“.
2. Die Infrastruktur von Cloud-Anbietern, wo es erforderlich ist, schnell und standardisiert horizontal zu skalieren und eine große Anzahl von virtuellen Maschinen für Kunden leicht „zuschneiden“ zu können.
3. Infrastruktur virtuellen Arbeitsplätzen (VDI), wo viele kleine Benutzer-VMs gestartet werden und ruhig innerhalb eines einheitlichen Clusters „schwimmen“.
4. Filialnetze, in denen jede Filiale eine standardisierte, ausfallsichere, aber gleichzeitig kostengünstige Infrastruktur aus 15-20 virtuellen Maschinen benötigt.
5. Irgendeine verteilte Berechnung (zum Beispiel Big Data-Dienste). Dort, wo die Belastung nicht „nach unten“, sondern „nach außen“ geht.
6. Testumgebungen, wo zusätzliche kleine Verzögerungen zulässig sind, aber Budgetbeschränkungen bestehen, weil es sich um Tests handelt.

Momentan haben wir AERODISK vAIR genau für diese Aufgaben entwickelt und fokussieren uns darauf (bislang erfolgreich). Vielleicht wird sich das bald ändern, da die Welt sich nicht stillsteht.

Also…

Damit ist der erste Teil eines großen Artikels abgeschlossen, im nächsten Artikel werden wir über die Architektur der Lösung und die verwendeten Komponenten berichten.

Wir freuen uns über Fragen, Vorschläge und konstruktive Diskussionen.

Quelle: habr.com