{"id":38542,"date":"2019-10-31T22:24:25","date_gmt":"2019-10-31T19:24:25","guid":{"rendered":"https:\/\/prohoster.info\/blog\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs\/"},"modified":"2019-10-31T22:24:25","modified_gmt":"2019-10-31T19:24:25","slug":"giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","title":{"rendered":"Hyperkonvergente L\u00f6sung AERODISK vAIR. Grundlage ist das Dateisystem ARDFS.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hyperkonvergente<\/p>\n

<\/p>\n

Hallo, Leser von Habr. Mit diesem Artikel beginnen wir eine Serie, die von unserem hyperkonvergenten System AERODISK vAIR erz\u00e4hlt. Urspr\u00fcnglich wollten wir in unserem ersten Artikel alles im Detail erkl\u00e4ren, doch das System ist recht komplex, daher werden wir den Elefanten St\u00fcck f\u00fcr St\u00fcck essen. <\/p>\n

<\/p>\n

Wir beginnen die Geschichte mit der Entstehung des Systems, vertiefen uns in das ARDFS-Dateisystem, das die Grundlage von vAIR bildet, und diskutieren auch kurz die Positionierung dieser L\u00f6sung auf dem russischen Markt. <\/p>\n

<\/p>\n

In den kommenden Artikeln werden wir ausf\u00fchrlicher \u00fcber die verschiedenen architektonischen Komponenten (Cluster, Hypervisor, Lastenausgleich, \u00dcberwachungssystem usw.), den Einrichtungsprozess berichten, Lizenzierungsfragen ansprechen, Crash-Tests separat pr\u00e4sentieren und nat\u00fcrlich \u00fcber Lasttests und Sizing schreiben. Zudem werden wir einen eigenen Artikel der Community-Version von vAIR widmen.<\/p>\n

<\/a><\/noindex><\/p>\n

AERODISK \u2013 ist das etwa eine Geschichte \u00fcber Speichersysteme? Oder warum haben wir \u00fcberhaupt mit hyperkonvergenten L\u00f6sungen begonnen?<\/h2>\n

<\/p>\n

Die urspr\u00fcngliche Idee, unsere eigene hyperkonvergente L\u00f6sung zu entwickeln, entstand etwa im Jahr 2010. Zu diesem Zeitpunkt gab es weder Aerodisk noch \u00e4hnliche L\u00f6sungen (kommerzielle, verpackte hyperkonvergente Systeme) auf dem Markt. Unsere Aufgabe war es, aus einer Gruppe von Servern mit lokalen Festplatten, die \u00fcber Ethernet-Protokoll miteinander verbunden waren, ein verteiltes Speicher-Array zu schaffen und darauf virtuelle Maschinen und ein Software-Netzwerk laufen zu lassen. All dies musste ohne ein SAN realisiert werden (da wir einfach kein Geld f\u00fcr ein SAN und dessen Anbindung hatten und unser eigenes SAN damals noch nicht erfunden war).<\/p>\n

<\/p>\n

Wir haben viele Open-Source-L\u00f6sungen ausprobiert und schlie\u00dflich diese Aufgabe gel\u00f6st, aber die L\u00f6sung war sehr komplex und schwer zu reproduzieren. Dar\u00fcber hinaus war diese L\u00f6sung mehr oder weniger ein \u201eEs funktioniert? Fass es nicht an!\u201c. Daher haben wir, nachdem wir diese Aufgabe gel\u00f6st hatten, die Idee, das Ergebnis unserer Arbeit in ein vollwertiges Produkt zu verwandeln, nicht weiter verfolgt. <\/p>\n

<\/p>\n

Nach diesem Vorfall haben wir von dieser Idee Abstand genommen, aber uns blieb das Gef\u00fchl, dass diese Aufgabe durchaus l\u00f6sbar ist und der Nutzen einer solchen L\u00f6sung mehr als offensichtlich ist. Sp\u00e4ter best\u00e4tigten die auf den Markt kommenden HCI-Produkte ausl\u00e4ndischer Unternehmen dieses Gef\u00fchl nur noch. <\/p>\n

<\/p>\n

Daher haben wir Mitte 2016 an dieser Aufgabe gearbeitet, um ein vollwertiges Produkt zu schaffen. Zu diesem Zeitpunkt hatten wir noch keine Beziehungen zu Investoren, weshalb wir den Entwicklungststand aus eigenen geringen Mitteln finanzieren mussten. Wir kauften gebrauchte Server und Switches \u00fcber Avito und legten los.<\/p>\n

<\/p>\n

\"Hyperkonvergente<\/p>\n

<\/p>\n

Die Hauptanfangsaufgabe bestand darin, ein einfaches, aber eigenes Dateisystem zu entwickeln, das Daten automatisch und gleichm\u00e4\u00dfig in Form von virtuellen Bl\u00f6cken auf einer beliebigen Anzahl von Knoten im Cluster verteilt, die \u00fcber Ethernet miteinander verbunden sind. Dabei sollte das Dateisystem gut und einfach skalierbar sein und unabh\u00e4ngig von benachbarten Systemen, d.h. von vAIR als blo\u00dfer Speicherl\u00f6sung abtrennbar sein.<\/p>\n

<\/p>\n

\"Hyperkonvergente<\/p>\n

<\/p>\n

Das erste Konzept von vAIR<\/p>\n

<\/p>\n

\"Hyperkonvergente<\/p>\n

<\/p>\n

Wir haben absichtlich darauf verzichtet, fertige Open-Source-L\u00f6sungen f\u00fcr den Aufbau eines verteilten Speichers (wie Ceph, Gluster, Lustre und \u00e4hnliches) zu verwenden, und stattdessen auf unsere eigene Entwicklung gesetzt, da wir bereits viel Projekterfahrung damit hatten. Diese L\u00f6sungen sind zweifellos an sich hervorragend, und wir haben vor der Arbeit an Aerodisc mehrere Integrationsprojekte damit umgesetzt. Aber es ist ein Unterschied, eine spezifische Aufgabe eines Kunden zu l\u00f6sen, das Personal zu schulen und m\u00f6glicherweise den Support eines gro\u00dfen Anbieters einzukaufen, und eine leicht reproduzierbare L\u00f6sung zu schaffen, die f\u00fcr verschiedene Aufgaben verwendet wird, von denen wir als Anbieter m\u00f6glicherweise nicht einmal Kenntnis haben. F\u00fcr dieses zweite Ziel waren bestehende Open-Source-Produkte f\u00fcr uns nicht geeignet, weshalb wir uns entschlossen haben, ein verteiltes Dateisystem selbst zu entwickeln.
\nNach zwei Jahren harter Arbeit mehrerer Entwickler (die die Arbeiten an vAIR mit der Entwicklung der klassischen Storage Engine kombinierten) wurden bestimmte Ergebnisse erzielt.<\/p>\n

<\/p>\n

Bis 2018 hatten wir ein einfaches Dateisystem entwickelt und mit den notwendigen Bindings erg\u00e4nzt. Das System verband \u00fcber interne Interconnects physische (lokale) Festplatten von verschiedenen Servern zu einem flachen Pool und \"schnitt\" sie in virtuelle Bl\u00f6cke, aus denen dann blockbasierte Ger\u00e4te mit unterschiedlich hohem Fehlerschutz erstellt wurden, auf denen mit dem Hypervisor KVM virtuelle Maschinen erstellt und betrieben wurden. <\/p>\n

<\/p>\n

Bei der Benennung des Dateisystems haben wir uns nicht gro\u00dfartig angestrengt und haben es schlicht ARDFS genannt (erraten Sie, wof\u00fcr das steht))<\/p>\n

<\/p>\n

Dieser Prototyp sah gut aus (nicht visuell, nat\u00fcrlich gab es damals noch keine visuelle Gestaltung) und zeigte eine gute Leistung sowie Skalierbarkeit. Nach den ersten realen Ergebnissen gaben wir diesem Projekt gr\u00fcnes Licht, organisierten eine vollwertige Entwicklungsumgebung und ein separates Team, das sich nur um vAIR k\u00fcmmerte.<\/p>\n

<\/p>\n

Zu dieser Zeit reifte die allgemeine Architektur der L\u00f6sung, die bis heute keine nennenswerten \u00c4nderungen erfahren hat.<\/p>\n

<\/p>\n

Lasst uns in das Dateisystem ARDFS eintauchen.<\/h2>\n

<\/p>\n

ARDFS ist die Grundlage von vAIR, das eine verteilte fehlertolerante Datenspeicherung f\u00fcr das gesamte Cluster bietet. Eines der (aber nicht das einzige) Unterscheidungsmerkmale von ARDFS ist, dass es keine zus\u00e4tzlichen dedizierte Server<\/a> Metadaten oder Verwaltung verwendet. Dies wurde urspr\u00fcnglich zur Vereinfachung der Konfiguration der L\u00f6sung und zur Zuverl\u00e4ssigkeit konzipiert. <\/p>\n

<\/p>\n

Speicherstruktur<\/h3>\n

<\/p>\n

Im Rahmen aller Knoten des Clusters organisiert ARDFS einen logischen Pool des gesamten verf\u00fcgbaren Speicherplatzes. Es ist wichtig zu verstehen, dass der Pool noch keine Daten und keinen formatierten Speicher darstellt, sondern lediglich eine Markierung. Das bedeutet, dass alle Knoten mit installiertem vAIR beim Hinzuf\u00fcgen zum Cluster automatisch zum gemeinsamen Pool von ARDFS hinzugef\u00fcgt werden und die Speicherkapazit\u00e4ten automatisch f\u00fcr das gesamte Cluster gemeinsam genutzt werden (und f\u00fcr die zuk\u00fcnftige Datenspeicherung verf\u00fcgbar sind). Dieser Ansatz erm\u00f6glicht es, Knoten im laufenden Betrieb ohne nennenswerte Auswirkungen auf das bereits laufende System hinzuzuf\u00fcgen oder zu entfernen. Das hei\u00dft, das System ist sehr einfach in \u201eZiegeln\u201c skalierbar, indem Knoten bei Bedarf zum Cluster hinzugef\u00fcgt oder entfernt werden.<\/p>\n

<\/p>\n

\u00dcber dem ARDFS-Pool werden virtuelle Festplatten (Speicherobjekte f\u00fcr virtuelle Maschinen) hinzugef\u00fcgt, die aus virtuellen Bl\u00f6cken mit einer Gr\u00f6\u00dfe von 4 Megabyte bestehen. Die Daten werden direkt auf den virtuellen Festplatten gespeichert. Auf der Ebene der virtuellen Festplatten wird auch das Konzept der Fehlertoleranz festgelegt. <\/p>\n

<\/p>\n

Wie bereits vermutet, verwenden wir f\u00fcr die Fehlertoleranz des Festplattensystems nicht das Konzept von RAID (Redundant Array of Independent Disks), sondern RAIN (Redundant Array of Independent Nodes). Das bedeutet, dass die Fehlertoleranz anhand der Knoten und nicht der Festplatten gemessen, automatisiert und verwaltet wird. Festplatten sind nat\u00fcrlich auch Speicherobjekte, sie werden wie alles andere \u00fcberwacht, und es k\u00f6nnen alle Standardoperationen durchgef\u00fchrt werden, einschlie\u00dflich der Erstellung eines lokalen Hardware-RAID, aber der Cluster operiert genau mit Knoten. <\/p>\n

<\/p>\n

In Situationen, in denen RAID sehr begehrt ist (zum Beispiel ein Szenario, das multiple Ausf\u00e4lle in kleinen Clustern unterst\u00fctzt), steht der Nutzung von lokalen RAID-Controllern nichts im Weg. Dar\u00fcber hinaus kann ein verteiltes Speicher- und RAIN-Architektur verwendet werden. Solche Szenarien sind durchaus praktikabel und werden von uns unterst\u00fctzt, weshalb wir in einem Artikel \u00fcber typische Anwendungsszenarien von vAIR dar\u00fcber berichten werden.<\/p>\n

<\/p>\n

Schemen der Ausfallsicherheit f\u00fcr Speicher<\/h3>\n

<\/p>\n

Es k\u00f6nnen zwei Schemen der Ausfallsicherheit virtueller Festplatten in vAIR vorkommen:<\/p>\n

<\/p>\n

1) Replikationsfaktor oder einfach Replikation \u2013 diese Methode der Ausfallsicherheit ist so einfach \"wie Stock und Schnur\". Es findet eine synchrone Replikation zwischen den Nodes mit einem Faktor von 2 (2 Kopien im Cluster) oder 3 (3 Kopien) statt. RF-2 erm\u00f6glicht es dem virtuellen Disk, den Ausfall eines Nodes im Cluster zu \u00fcberstehen, beansprucht jedoch die H\u00e4lfte des nutzbaren Volumens. RF-3 hingegen kann den Ausfall von 2 Nodes im Cluster \u00fcberstehen, reserviert jedoch 2\/3 des n\u00fctzlichen Volumens f\u00fcr sich selbst. Dieses Schema \u00e4hnelt stark RAID-1, was bedeutet, dass ein virtueller Disk, der auf RF-2 konfiguriert ist, gegen\u00fcber dem Ausfall eines beliebigen Nodes im Cluster resistent ist. In diesem Fall sind die Daten sicher, und auch der Ein- und Ausgang werden nicht gestoppt. Sobald der ausgefallene Node wieder online ist, beginnt die automatische Wiederherstellung\/Synchronisation der Daten. <\/p>\n

<\/p>\n

Im Folgenden sind Beispiele f\u00fcr die Verteilung von Daten in RF-2 und RF-3 sowohl im Normalbetrieb als auch im Falle von Ausf\u00e4llen aufgef\u00fchrt.<\/p>\n

<\/p>\n

Wir haben eine virtuelle Maschine mit 8 MB einzigartigen (n\u00fctzlichen) Daten, die auf 4 vAIR-Knoten l\u00e4uft. Es ist klar, dass in der Realit\u00e4t so wenig Speicher kaum vorkommen wird, aber f\u00fcr ein Schema, das die Funktionsweise von ARDFS widerspiegelt, ist dieses Beispiel am besten verst\u00e4ndlich. AB sind virtuelle Bl\u00f6cke mit je 4 MB, die einzigartige Daten der virtuellen Maschine enthalten. Bei RF-2 werden zwei Kopien dieser Bl\u00f6cke A1+A2 und B1+B2 erstellt. Diese Bl\u00f6cke werden auf die Knoten verteilt, um zu vermeiden, dass dieselben Daten auf einem Knoten liegen, d.h. die Kopie A1 wird nicht auf demselben Knoten wie die Kopie A2 sein. Das Gleiche gilt f\u00fcr B1 und B2.<\/p>\n

<\/p>\n

\"Hyperkonvergente<\/p>\n

<\/p>\n

Im Falle eines Ausfalls eines der Knoten (zum Beispiel Knoten Nr. 3, wo die Kopie B1 gespeichert ist), wird diese Kopie automatisch auf dem Knoten aktiviert, auf dem keine Kopie ihrer Kopie (d.h. der Kopie B2) vorhanden ist. <\/p>\n

<\/p>\n

\"Hyperkonvergente<\/p>\n

<\/p>\n

Somit \u00fcbersteht die virtuelle Festplatte (und die VM dementsprechend) den Ausfall eines Knotens im RF-2-Schema problemlos.<\/p>\n

<\/p>\n

Das Schema mit Replikation leidet trotz seiner Einfachheit und Zuverl\u00e4ssigkeit an demselben Problem wie RAID1 \u2013 es bietet wenig nutzbaren Speicherplatz.<\/p>\n

<\/p>\n

2) Erasure Coding oder L\u00f6schkodierung (auch bekannt als \u201eRedundanzkodierung\u201c, \u201el\u00f6schen Kodierung\u201c oder \u201eRedundanzcode\u201c) existiert genau zur L\u00f6sung des oben genannten Problems. EC ist ein Redundanzschema, das eine hohe Datenverf\u00fcgbarkeit bei geringeren Speicherplatzkosten im Vergleich zur Replikation gew\u00e4hrleistet. Das Funktionsprinzip dieses Mechanismus \u00e4hnelt RAID 5, 6, 6P. <\/p>\n

<\/p>\n

Bei der Kodierung teilt der EC-Prozess einen virtuellen Block (standardm\u00e4\u00dfig 4 MB) in mehrere kleinere \u201eDatenst\u00fccke\u201c auf, abh\u00e4ngig vom EC-Schema (zum Beispiel teilt das 2+1-Schema jeden 4 MB Block in 2 St\u00fccke von je 2 MB). Anschlie\u00dfend generiert dieser Prozess f\u00fcr die \u201eDatenst\u00fccke\u201c \u201eParit\u00e4tsst\u00fccke\u201c, die nicht gr\u00f6\u00dfer sind als eines der zuvor geteilten Teile. Bei der Dekodierung generiert EC die fehlenden St\u00fccke, indem es die \u201e\u00fcberlebenden\u201c Daten im gesamten Cluster liest. <\/p>\n

<\/p>\n

Zum Beispiel kann ein virtueller Datentr\u00e4ger mit dem EC-Schema 2 + 1, das auf 4 Knoten eines Clusters implementiert ist, den Ausfall eines Knotens im Cluster problemlos verkraften, genauso wie RF-2. Dabei sind die Kosten geringer, insbesondere liegt der Nutzungsgrad bei RF-2 bei 2, w\u00e4hrend er bei EC 2+1 bei 1,5 liegt. <\/p>\n

<\/p>\n

Einfacher ausgedr\u00fcckt, besteht das Prinzip darin, dass der virtuelle Block in 2 bis 8 (warum 2 bis 8, wird weiter unten erkl\u00e4rt) \"St\u00fccke\" unterteilt wird, f\u00fcr die Parit\u00e4tsst\u00fccke \u00e4hnlicher Gr\u00f6\u00dfe berechnet werden. <\/p>\n

<\/p>\n

Die Daten und die Parit\u00e4t werden gleichm\u00e4\u00dfig auf alle Knoten des Clusters verteilt. Dabei verteilt ARDFS die Daten automatisch auf die Knoten, \u00e4hnlich wie bei der Replikation, so dass identische Daten (Datenkopien und deren Parit\u00e4t) auf einem Knoten nicht gespeichert werden, um das Risiko zu vermeiden, Daten zu verlieren, weil sowohl die Daten als auch deren Parit\u00e4t unerwartet auf demselben Speicherknoten gespeichert werden, der ausf\u00e4llt. <\/p>\n

<\/p>\n

Im Folgenden ein Beispiel mit demselben Virtual Machine von 8 MB und 4 Knoten, jedoch bereits mit dem EC-Schema 2+1. <\/p>\n

<\/p>\n

Die Bl\u00f6cke A und B werden jeweils in zwei St\u00fccke zu je 2 MB unterteilt (in zwei, weil 2+1), also in A1+A2 und B1+B2. Im Gegensatz zu einer Replik ist A1 keine Kopie von A2, es handelt sich um einen virtuellen Block A, der in zwei Teile geteilt ist, ebenso bei Block B. Insgesamt erhalten wir zwei Sets zu 4 MB, von denen jedes aus zwei zwei-Megabyte-St\u00fccken besteht. Danach wird f\u00fcr jedes dieser Sets die Parit\u00e4t mit einer Gr\u00f6\u00dfe von nicht mehr als einem St\u00fcck (d.h. 2 MB) berechnet, was zus\u00e4tzlich + 2 Parit\u00e4tsst\u00fccke (A-P und B-P) ergibt. Insgesamt haben wir 4\u00d72 Daten + 2\u00d72 Parit\u00e4t.<\/p>\n

<\/p>\n

Die St\u00fccke werden dann so auf die Knoten verteilt, dass die Daten nicht mit ihrer Parit\u00e4t \u00fcberlappen. Das hei\u00dft, A1 und A2 werden nicht auf demselben Knoten mit A-P liegen.<\/p>\n

<\/p>\n

\"Hyperkonvergente<\/p>\n

<\/p>\n

Im Falle eines Ausfalls eines Knotens (nehmen wir an, des dritten) wird der ausgefallene Block B1 automatisch aus der Parit\u00e4t B-P wiederhergestellt, die auf Knoten Nr. 2 gespeichert ist, und auf dem Knoten aktiviert, wo es keine B-Parit\u00e4t, d.h. kein St\u00fcck B-P gibt. In diesem Beispiel ist das Knoten Nr. 1.<\/p>\n

<\/p>\n

\"Hyperkonvergente<\/p>\n

<\/p>\n

Ich bin mir sicher, dass der Leser die Frage hat:<\/p>\n

<\/p>\n

\u201eAlles, was Sie beschrieben haben, wurde bereits von Mitbewerbern und in Open-Source-L\u00f6sungen umgesetzt. Was unterscheidet Ihre Implementierung von EC in ARDFS?\u201c<\/p><\/blockquote>\n

Und nun werden interessante Funktionen von ARDFS folgen.<\/p>\n

<\/p>\n

Erasure Coding mit dem Fokus auf Flexibilit\u00e4t.<\/h3>\n

<\/p>\n

Urspr\u00fcnglich haben wir ein recht flexibles EC X+Y-Schema vorgesehen, wobei X eine Zahl von 2 bis 8 und Y eine Zahl von 1 bis 8 entspricht, jedoch stets kleiner oder gleich X ist. Dieses Schema ist f\u00fcr Flexibilit\u00e4t konzipiert. Die Erh\u00f6hung der Datenst\u00fcckzahlen (X), in die der virtuelle Block unterteilt wird, f\u00fchrt zu geringeren Overheadkosten, was bedeutet, dass der nutzbare Speicherplatz steigt.
\nDie Erh\u00f6hung der Parit\u00e4tsst\u00fcckzahlen (Y) verbessert die Zuverl\u00e4ssigkeit des virtuellen Laufwerks. Je h\u00f6her der Wert von Y ist, desto mehr Knoten im Cluster k\u00f6nnen ausfallen. Nat\u00fcrlich reduziert die Erh\u00f6hung des Parit\u00e4tsvolumens die nutzbare Kapazit\u00e4t, aber das ist der Preis f\u00fcr Zuverl\u00e4ssigkeit. <\/p>\n

<\/p>\n

Die Abh\u00e4ngigkeit der Leistung von den EC-Schemata ist fast linear: Je mehr \u201eSt\u00fccke\u201c vorhanden sind, desto niedriger ist die Leistung, hier ist ein ausgewogenes Urteil erforderlich. <\/p>\n

<\/p>\n

Dieser Ansatz erm\u00f6glicht es Administratoren, den verteilten Speicher maximal flexibel zu konfigurieren. Innerhalb des ARDFS-Pools k\u00f6nnen beliebige Hochverf\u00fcgbarkeits-Schemata und deren Kombinationen verwendet werden, was wir ebenfalls als sehr n\u00fctzlich erachten. <\/p>\n

<\/p>\n

Nachfolgend finden Sie eine Vergleichstabelle mehrerer (nicht aller m\u00f6glichen) RF- und EC-Schemata.<\/p>\n

<\/p>\n

\"Hyperkonvergente<\/p>\n

<\/p>\n

Die Tabelle zeigt, dass selbst die \"extremste\" Kombination EC 8+7, die den gleichzeitigen Verlust von bis zu 7 Knoten im Cluster zul\u00e4sst, weniger n\u00fctzlichen Raum beansprucht (1,875 gegen\u00fcber 2) als die Standardreplikation und gleichzeitig siebenmal besser sch\u00fctzt. Dies macht diesen Schutzmechanismus zwar komplexer, aber deutlich attraktiver in Situationen, in denen maximale Zuverl\u00e4ssigkeit bei begrenztem Speicherplatz erforderlich ist. Dabei ist zu beachten, dass jeder \u201ePluspunkt\u201c f\u00fcr X oder Y zus\u00e4tzliche Leistungskosten verursacht, sodass zwischen Zuverl\u00e4ssigkeit, Sparsamkeit und Leistung sehr sorgf\u00e4ltig abgewogen werden muss. Aus diesem Grund widmen wir einen separaten Artikel dem Sizing der L\u00f6schcodierung.<\/p>\n

<\/p>\n

\"Hyperkonvergente<\/p>\n

<\/p>\n

Zuverl\u00e4ssigkeit und Autonomie des Dateisystems<\/h3>\n

<\/p>\n

ARDFS wird lokal auf allen Knoten des Clusters gestartet und synchronisiert sie eigenst\u00e4ndig \u00fcber dedizierte Ethernet-Schnittstellen. Ein wichtiger Punkt ist, dass ARDFS nicht nur die Daten, sondern auch die Metadaten, die mit der Speicherung verbunden sind, selbstst\u00e4ndig synchronisiert. W\u00e4hrend der Entwicklung von ARDFS haben wir parallel eine Reihe bestehender L\u00f6sungen untersucht und festgestellt, dass viele die Synchronisierung der Metadaten des Dateisystems mithilfe externer verteilten Datenbankmanagementsysteme durchf\u00fchren. Diese verwenden wir ebenfalls f\u00fcr die Synchronisierung, aber nur f\u00fcr Konfigurationen und nicht f\u00fcr die Metadaten des Dateisystems (\u00fcber dieses und andere verwandte Subsysteme wird im n\u00e4chsten Artikel berichtet). <\/p>\n

<\/p>\n

Die Synchronisierung der Metadaten des Dateisystems mit einer externen Datenbankmanagementsystem ist selbstverst\u00e4ndlich eine funktionierende L\u00f6sung, jedoch w\u00fcrde dadurch die Konsistenz der auf ARDFS gespeicherten Daten von der externen Datenbank und ihrem Verhalten abh\u00e4ngen (und die ist, um es vorsichtig auszudr\u00fccken, eine launische Dame), was unserer Meinung nach schlecht ist. Warum? Wenn die Metadaten des Dateisystems besch\u00e4digt werden, k\u00f6nnen wir uns auch von den eigentlichen Daten des Dateisystems verabschieden. Deshalb haben wir uns entschieden, einen komplexeren, aber zuverl\u00e4ssigeren Weg zu gehen. <\/p>\n

<\/p>\n

Das Metadaten-Synchronisationssystem f\u00fcr ARDFS haben wir selbst entwickelt, und es funktioniert v\u00f6llig unabh\u00e4ngig von angrenzenden Subsystemen. Das hei\u00dft, kein anderes Subsystem kann die ARDFS-Daten gef\u00e4hrden. Nach unserer Ansicht ist dies der zuverl\u00e4ssigste und richtige Weg, ob es tats\u00e4chlich so ist, wird die Zukunft zeigen. Zus\u00e4tzlich bringt dieser Ansatz einen weiteren Vorteil mit sich. ARDFS kann unabh\u00e4ngig von vAIR verwendet werden, einfach als erweiterbarer Speicher, was wir definitiv in zuk\u00fcnftigen Produkten nutzen werden.<\/p>\n

<\/p>\n

Durch die Entwicklung von ARDFS haben wir ein flexibles und zuverl\u00e4ssiges Dateisystem geschaffen, das die Wahl bietet, ob man bei der Speicherkapazit\u00e4t sparen oder die gesamte Leistung aufdrehen m\u00f6chte, oder ein extrem zuverl\u00e4ssiges Speichermedium zu einem moderaten Preis anstreben kann, jedoch mit reduzierten Leistungsanforderungen. <\/p>\n

<\/p>\n

Zusammen mit einer einfachen Lizenzpolitik und einem flexiblen Bereitstellungsmodell (um es vorwegzunehmen, vAIR wird nach Knoten lizenziert und entweder als Software oder als PAK bereitgestellt) erm\u00f6glicht dies, die L\u00f6sung sehr genau auf die unterschiedlichsten Anforderungen der Kunden zuzuschneiden und dieses Gleichgewicht k\u00fcnftig leicht zu halten. <\/p>\n

<\/p>\n

Wer braucht dieses Wunder?<\/h2>\n

<\/p>\n

Einerseits kann man sagen, dass es auf dem Markt bereits Akteure gibt, die ernsthafte L\u00f6sungen im Bereich Hyperkonvergenz anbieten, und dass wir uns daher in einem wettbewerbsintensiven Umfeld bewegen. Diese Aussage scheint zutreffend zu sein, ABER\u2026<\/p>\n

<\/p>\n

Andererseits, wenn wir \u201eins Feld\u201c gehen und mit Kunden sprechen, sehen wir und unsere Partner, dass das ganz anders ist. Es gibt viele Aufgaben f\u00fcr Hyperkonvergenz, wobei manchen Menschen schlicht nicht bekannt ist, dass solche L\u00f6sungen existieren, andere glauben, dass sie zu teuer sind, wieder andere hatten negative Erfahrungen mit alternativen L\u00f6sungen, und in einigen F\u00e4llen sind K\u00e4ufe aufgrund von Sanktionen ganz verboten. Insgesamt stellte sich das Feld als ungenutzt heraus, weshalb wir uns entschieden haben, die Pionierarbeit zu leisten.) <\/p>\n

<\/p>\n

Wann ist eine SAN besser als eine HCI?<\/h3>\n

<\/p>\n

W\u00e4hrend unserer Arbeit mit dem Markt werden wir h\u00e4ufig gefragt, wann man das klassische SAN-Modell und wann die Hyperkonvergenz anwenden sollte. Viele Unternehmen, die HCI-Produkte herstellen (insbesondere diejenigen, die keine SAN-L\u00f6sungen im Portfolio haben), behaupten: \u201eSAN hat ausgedient, nur Hyperkonvergenz!\u201c. Diese gewagte Aussage spiegelt jedoch nicht ganz die Realit\u00e4t wider. <\/p>\n

<\/p>\n

Ehrlich gesagt, bewegt sich der SAN-Markt tats\u00e4chlich in Richtung Hyperkonvergenz und \u00e4hnlicher L\u00f6sungen, aber es gibt immer ein \u201eaber\u201c.<\/p>\n

<\/p>\n

Erstens lassen sich die aufgebauten Rechenzentren und IT-Infrastrukturen nach dem klassischen Schema mit SAN nicht einfach umstellen, deshalb ist die Modernisierung und der Ausbau solcher Infrastrukturen ein Erbe von etwa 5 bis 7 Jahren.<\/p>\n

<\/p>\n

Zweitens werden derzeit die meisten Infrastrukturen (gemeint ist Russland) nach dem klassischen Schema mit Einsatz von SAN gebaut, und nicht weil die Leute nichts von hyperkonvergenten L\u00f6sungen wissen, sondern weil der Markt f\u00fcr hyperkonvergente Systeme neu ist, die L\u00f6sungen und Standards noch nicht fest etabliert sind, IT-Fachleute noch nicht geschult sind und wenig Erfahrung vorhanden ist; Rechenzentren m\u00fcssen hier und jetzt gebaut werden. Dieser Trend wird noch 3 bis 5 Jahre anhalten (und danach bleibt erneut ein Erbe, siehe Punkt 1).<\/p>\n

<\/p>\n

Drittens gibt es rein technische Einschr\u00e4nkungen durch zus\u00e4tzliche kleine Latenzen von 2 Millisekunden beim Schreiben (ohne lokalen Cache, versteht sich), die den Preis f\u00fcr verteiltes Speichern darstellen. <\/p>\n

<\/p>\n

Und vergessen wir nicht den Einsatz gro\u00dfer physischer Server, die vertikale Skalierung des Speichersystems bevorzugen.<\/p>\n

<\/p>\n

Es gibt viele relevante und beliebte Aufgaben, in denen HCI besser funktioniert als die traditionelle Infrastruktur. Nat\u00fcrlich werden die Hersteller, die keine HCI in ihrem Produktportfolio haben, dem nicht zustimmen, aber wir sind bereit, dies fundiert zu diskutieren. Selbstverst\u00e4ndlich werden wir als Entwickler beider Produkte in einer zuk\u00fcnftigen Ver\u00f6ffentlichung einen Vergleich zwischen HCI und traditioneller Infrastruktur durchf\u00fchren, in dem wir anschaulich demonstrieren, unter welchen Bedingungen was besser ist.<\/p>\n

<\/p>\n

In welchen Bereichen werden hyperkonvergente L\u00f6sungen besser funktionieren als HCI?<\/h3>\n

<\/p>\n

Basierend auf den obigen Thesen lassen sich drei offensichtliche Schlussfolgerungen ziehen: <\/p>\n

<\/p>\n

    \n
  1. Dort, wo zus\u00e4tzliche 2 Millisekunden Schreibverz\u00f6gerung, die in jeder produktiven Umgebung konstant auftreten (hier geht es nicht um synthetische Tests, denn in synthetischen Tests k\u00f6nnen auch Nanosekunden gezeigt werden), nicht kritisch sind, ist HCI geeignet.<\/li>\n
  2. Dort, wo die Last von gro\u00dfen physischen Servern in viele kleine virtuelle Server umgewandelt und auf Knoten verteilt werden kann, funktioniert HCI ebenfalls gut.<\/li>\n
  3. Dort, wo horizontale Skalierung wichtiger ist als vertikale, wird HCI ebenfalls hervorragend eingesetzt.<\/li>\n<\/ol>\n

    <\/p>\n

    Was sind diese L\u00f6sungen?<\/h3>\n

    <\/p>\n

      \n
    1. Alle Standard-Infrastruktur-Dienste (Verzeichnisdienste, E-Mail, Dokumentenmanagement, Dateiserver, kleine oder mittlere ERP- und BI-Systeme usw.). Wir nennen das \"gemeinsame Berechnungen\". <\/li>\n
    2. Infrastruktur von Cloud-Anbietern, wo eine schnelle und standardisierte horizontale Skalierung erforderlich ist und eine gro\u00dfe Anzahl von virtuellen Maschinen f\u00fcr Kunden einfach \"bereitgestellt\" werden kann.<\/li>\n
    3. Infrastruktur virtuellen Arbeitsfl\u00e4chen<\/a> (VDI), wo viele kleine Benutzer-Virtualisierungen gestartet werden und ruhig innerhalb eines einheitlichen Clusters \"schwimmen\".<\/li>\n
    4. Filialnetzwerke, bei denen in jeder Filiale eine standardisierte, ausfallsichere, aber dennoch kosteng\u00fcnstige Infrastruktur aus 15-20 virtuellen Maschinen ben\u00f6tigt wird.<\/li>\n
    5. Alle verteilten Berechnungen (z. B. Big Data-Dienste). Dort, wo die Last nicht \"vertikal\", sondern \"horizontal\" geht. <\/li>\n
    6. Testumgebungen, in denen zus\u00e4tzliche kleine Verz\u00f6gerungen toleriert werden k\u00f6nnen, aber Budgetbeschr\u00e4nkungen bestehen, da es sich um Tests handelt.<\/li>\n<\/ol>\n

      <\/p>\n

      Aktuell haben wir AERODISK vAIR speziell f\u00fcr diese Aufgaben entwickelt und konzentrieren uns darauf (bislang erfolgreich). M\u00f6glicherweise wird sich das bald \u00e4ndern, da die Welt sich nicht stillsteht.<\/p>\n

      <\/p>\n

      Also\u2026<\/h3>\n

      <\/p>\n

      Der erste Teil des umfangreichen Artikelzyklus ist hiermit abgeschlossen. Im n\u00e4chsten Artikel werden wir \u00fcber die Architektur der L\u00f6sung und die verwendeten Komponenten berichten.<\/p>\n

      <\/p>\n

      Wir freuen uns \u00fcber Fragen, Vorschl\u00e4ge und konstruktive Diskussionen.<\/p>\n

      Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

      \u041f\u0440\u0438\u0432\u0435\u0442, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0425\u0430\u0431\u0440\u0430. \u042d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u043c\u044b \u043e\u0442\u043a\u0440\u044b\u0432\u0430\u0435\u043c \u0446\u0438\u043a\u043b, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0431\u0443\u0434\u0435\u0442 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0442\u044c \u043e \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043d\u043d\u043e\u0439 \u043d\u0430\u043c\u0438 \u0433\u0438\u043f\u0435\u0440\u043a\u043e\u043d\u0432\u0435\u0440\u0433\u0435\u043d\u0442\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u0435 AERODISK vAIR. \u0418\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043c\u044b \u0445\u043e\u0442\u0435\u043b\u0438 \u043f\u0435\u0440\u0432\u043e\u0439 \u0436\u0435 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u0432\u0441\u0451 \u043e\u0431\u043e \u0432\u0441\u0451\u043c, \u043d\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0441\u043b\u043e\u0436\u043d\u0430\u044f, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u0431\u0443\u0434\u0435\u043c \u0435\u0441\u0442\u044c \u0441\u043b\u043e\u043d\u0430 \u043f\u043e \u0447\u0430\u0441\u0442\u044f\u043c. \u041d\u0430\u0447\u043d\u0435\u043c \u0440\u0430\u0441\u0441\u043a\u0430\u0437 \u0441 \u0438\u0441\u0442\u043e\u0440\u0438\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u044b, \u0443\u0433\u043b\u0443\u0431\u0438\u043c\u0441\u044f \u0432 \u0444\u0430\u0439\u043b\u043e\u0432\u0443\u044e \u0441\u0438\u0441\u0442\u0435\u043c\u0443 ARDFS, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043e\u0439 vAIR, \u0430 \u0442\u0430\u043a\u0436\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28919,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38542","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Hypereingemachtes L\u00f6sung AERODISK vAIR. Grundlage \u2014 Dateisystem ARDFS | ProHoster","description":"Hallo, liebe Leser von Habr. Mit diesem Artikel er\u00f6ffnen wir einen Zyklus, der \u00fcber unser entwickeltes hypereingemachtes System AERODISK vAIR berichtet. Urspr\u00fcnglich wollten wir in diesem ersten Artikel alles \u00fcber alles erz\u00e4hlen, aber das System ist ziemlich komplex, daher werden wir den Elefanten in kleinen St\u00fcckchen essen. Wir beginnen mit der Entstehungsgeschichte des Systems, vertiefen uns in das Dateisystem ARDFS, das die Grundlage von vAIR bildet, sowie","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0413\u0438\u043f\u0435\u0440\u043a\u043e\u043d\u0432\u0435\u0440\u0433\u0435\u043d\u0442\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 AERODISK vAIR. \u041e\u0441\u043d\u043e\u0432\u0430 \u2014 \u0444\u0430\u0439\u043b\u043e\u0432\u0430\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u0430 ARDFS | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0447\u0438\u0442\u0430\u0442\u0435\u043b\u0438 \u0425\u0430\u0431\u0440\u0430. \u042d\u0442\u043e\u0439 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u043c\u044b \u043e\u0442\u043a\u0440\u044b\u0432\u0430\u0435\u043c \u0446\u0438\u043a\u043b, \u043a\u043e\u0442\u043e\u0440\u044b\u0439 \u0431\u0443\u0434\u0435\u0442 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0442\u044c \u043e \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043d\u043d\u043e\u0439 \u043d\u0430\u043c\u0438 \u0433\u0438\u043f\u0435\u0440\u043a\u043e\u043d\u0432\u0435\u0440\u0433\u0435\u043d\u0442\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u0435 AERODISK vAIR. \u0418\u0437\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043c\u044b \u0445\u043e\u0442\u0435\u043b\u0438 \u043f\u0435\u0440\u0432\u043e\u0439 \u0436\u0435 \u0441\u0442\u0430\u0442\u044c\u0435\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u0432\u0441\u0451 \u043e\u0431\u043e \u0432\u0441\u0451\u043c, \u043d\u043e \u0441\u0438\u0441\u0442\u0435\u043c\u0430 \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0441\u043b\u043e\u0436\u043d\u0430\u044f, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u0431\u0443\u0434\u0435\u043c \u0435\u0441\u0442\u044c \u0441\u043b\u043e\u043d\u0430 \u043f\u043e \u0447\u0430\u0441\u0442\u044f\u043c. \u041d\u0430\u0447\u043d\u0435\u043c \u0440\u0430\u0441\u0441\u043a\u0430\u0437 \u0441 \u0438\u0441\u0442\u043e\u0440\u0438\u0438 \u0441\u043e\u0437\u0434\u0430\u043d\u0438\u044f \u0441\u0438\u0441\u0442\u0435\u043c\u044b, \u0443\u0433\u043b\u0443\u0431\u0438\u043c\u0441\u044f \u0432 \u0444\u0430\u0439\u043b\u043e\u0432\u0443\u044e \u0441\u0438\u0441\u0442\u0435\u043c\u0443 ARDFS, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043e\u0439 vAIR, \u0430 \u0442\u0430\u043a\u0436\u0435","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/giperkonvergentnoe-reshenie-aerodisk-vair-osnova-fajlovaya-sistema-ardfs","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:24:25+00:00","article:modified_time":"2019-10-31T19:24:25+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38542","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-09 13:06:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:07:40","updated":"2026-02-09 13:06:19"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/38542","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=38542"}],"version-history":[{"count":2,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/38542\/revisions"}],"predecessor-version":[{"id":158207,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/38542\/revisions\/158207"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/28919"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=38542"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=38542"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=38542"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}