{"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. Basis 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 er\u00f6ffnen wir einen Zyklus, der \u00fcber unser entwickeltes hyperkonvergentes System AERODISK vAIR berichten wird. Urspr\u00fcnglich wollten wir in dem ersten Artikel alles \u00fcber alles erz\u00e4hlen, aber das System ist recht komplex, also werden wir den Elefanten St\u00fcck f\u00fcr St\u00fcck essen. <\/p>\n

<\/p>\n

Wir beginnen die Erz\u00e4hlung mit der Geschichte der Entstehung des Systems, vertiefen uns in das Dateisystem ARDFS, das die Grundlage von vAIR bildet, und philosophieren ein wenig \u00fcber die Positionierung dieser L\u00f6sung auf dem russischen Markt. <\/p>\n

<\/p>\n

In den weiteren Artikeln werden wir detaillierter \u00fcber verschiedene architektonische Komponenten (Cluster, Hypervisor, Lastenausgleich, \u00dcberwachungssystem usw.) sprechen, den Einstellungsprozess behandeln, Lizenzfragen ansprechen, gesondert Crash-Tests zeigen und nat\u00fcrlich \u00fcber Lasttests und Sizing schreiben. Ein separater Artikel wird der Community-Version von vAIR gewidmet sein.<\/p>\n

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

Ist AERODISK eine Art Geschichte \u00fcber Speichersysteme? Oder warum haben wir \u00fcberhaupt mit hyperkonvergenten Systemen angefangen?<\/h2>\n

<\/p>\n

Urspr\u00fcnglich kam uns die Idee, unser eigenes Hyperkonvergenzsystem zu schaffen, etwa im Jahr 2010. Damals gab es weder AERODISK noch \u00e4hnliche L\u00f6sungen (kommerzielle, station\u00e4re 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\u00fcr hatten und unser eigenes Speichersystem damals noch nicht erfunden war) realisiert werden.<\/p>\n

<\/p>\n

Wir haben viele Open-Source-L\u00f6sungen ausprobiert und haben das Problem letztendlich gel\u00f6st, aber die L\u00f6sung war sehr kompliziert und schwer zu reproduzieren. Dar\u00fcber hinaus war diese L\u00f6sung aus der Kategorie \u201eL\u00e4uft? Nicht anfassen!\u201c. Daher haben wir, nachdem wir dieses Problem gel\u00f6st haben, die Idee verworfen, das Ergebnis unserer Arbeit in ein vollwertiges Produkt zu verwandeln. <\/p>\n

<\/p>\n

Nach diesem Vorfall haben wir von dieser Idee Abstand genommen, aber das Gef\u00fchl, dass dieses Problem durchaus l\u00f6sbar ist und der Nutzen einer solchen L\u00f6sung mehr als offensichtlich ist, lie\u00df uns nicht los. In der Folge haben die auf den Markt gekommenen HCI-Produkte ausl\u00e4ndischer Firmen dieses Gef\u00fchl nur best\u00e4tigt. <\/p>\n

<\/p>\n

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\u00fcr unser nicht ganz so gro\u00dfes Budget kaufen mussten. Wir haben auf Avito nach gebrauchten Servern und Switches gesucht und uns ans Werk gemacht.<\/p>\n

<\/p>\n

\"Hyperkonvergente<\/p>\n

<\/p>\n

Die Hauptanfangsaufgabe bestand darin, ein einfaches, eigenes Dateisystem zu schaffen, das in der Lage war, Daten automatisch und gleichm\u00e4\u00dfig in Form von virtuellen Bl\u00f6cken auf einer beliebigen Anzahl von Knoten des Clusters zu verteilen, die \u00fcber Ethernet verbunden sind. Dabei sollte das Dateisystem gut und einfach skalierbar sein und unabh\u00e4ngig von benachbarten Systemen existieren, d.h. es sollte als \"einfacher Speicher\" vom vAIR 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 bewusst darauf verzichtet, fertige Open-Source-L\u00f6sungen f\u00fcr die Organisation eines verteilten Speichers (Ceph, Gluster, Lustre und \u00e4hnliche) zu verwenden, und uns stattdessen f\u00fcr unsere eigene Entwicklung entschieden, da wir bereits viel Projekt-Erfahrung mit diesen L\u00f6sungen hatten. Diese L\u00f6sungen 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\u00fcr einen Kunden umzusetzen, das Personal zu schulen und m\u00f6glicherweise den Support eines gro\u00dfen Anbieters zu kaufen, und etwas ganz anderes, ein leicht reproduzierbares Produkt zu schaffen, das f\u00fcr unterschiedliche Aufgaben verwendet wird, die wir als Anbieter m\u00f6glicherweise nicht einmal selbst kennen. F\u00fcr diesen zweiten Zweck waren die bestehenden Open-Source-Produkte f\u00fcr uns nicht geeignet, weshalb wir beschlossen haben, das verteilte Dateisystem selbst zu entwickeln.
\nNach zwei Jahren Arbeit von mehreren Entwicklern (die ihre Arbeit an vAIR mit der Arbeit an der klassischen Speicher-Engine kombinierten) erzielten wir bestimmte Ergebnisse.<\/p>\n

<\/p>\n

Bis 2018 hatten wir ein einfaches Dateisystem geschrieben und es mit der notwendigen Anbindung erg\u00e4nzt. Das System vereinte \u00fcber interne Interconnects physische (lokale) Festplatten von verschiedenen Servern zu einem flachen Pool und \"schnitt\" sie in virtuelle Bl\u00f6cke. Aus diesen virtuellen Bl\u00f6cken wurden Blockger\u00e4te mit unterschiedlichem Ausma\u00df an Fehlertoleranz erstellt, auf denen mithilfe des KVM-Hypervisors virtuelle Maschinen erstellt und ausgef\u00fchrt wurden. <\/p>\n

<\/p>\n

Wir haben uns nicht lange mit dem Namen des Dateisystems aufgehalten und es ARDFS genannt (raten Sie mal, wof\u00fcr das steht))<\/p>\n

<\/p>\n

Dieser Prototyp machte einen guten Eindruck (nicht visuell, nat\u00fcrlich, 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\u00fcnes Licht gegeben, eine vollst\u00e4ndige Entwicklungsumgebung und ein eigenes Team einzurichten, das sich ausschlie\u00dflich mit vAIR besch\u00e4ftigt hat.<\/p>\n

<\/p>\n

Zu diesem Zeitpunkt war die allgemeine Architektur der L\u00f6sung ausgereift, die bis heute keine wesentlichen \u00c4nderungen erfahren hat.<\/p>\n

<\/p>\n

Wir tauchen in das Dateisystem ARDFS ein<\/h2>\n

<\/p>\n

ARDFS bildet die Grundlage von vAIR und sorgt f\u00fcr eine verteilte, ausfallsichere Speicherung der Daten des gesamten Clusters. Eine der (aber nicht die einzige) besonderen Eigenschaften von ARDFS ist, dass es keine zus\u00e4tzlichen dedizierten Servern<\/a> unter Metaund Verwaltung verwendet. Dies wurde urspr\u00fcnglich zur Vereinfachung der Konfiguration der L\u00f6sung und f\u00fcr ihre Zuverl\u00e4ssigkeit vorgesehen. <\/p>\n

<\/p>\n

Speicherstruktur<\/h3>\n

<\/p>\n

Im Rahmen aller Knoten des Clusters organisiert ARDFS einen logischen Pool aus dem gesamten verf\u00fcgbaren 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\u00fcgen zum Cluster automatisch zum gemeinsamen Pool von ARDFS hinzugef\u00fcgt und die Speicherressourcen werden automatisch gemeinschaftlich f\u00fcr das gesamte Cluster verf\u00fcgbar (und sind f\u00fcr zuk\u00fcnftige Datenspeicherungen zug\u00e4nglich). Dieser Ansatz erm\u00f6glicht das Hinzuf\u00fcgen und Entfernen von Knoten im laufenden Betrieb, ohne ernsthafte Auswirkungen auf das bereits funktionierende System zu haben. Das hei\u00dft, das System ist sehr einfach mit \u201eBausteinen\u201c zu skalieren, indem Knoten im Cluster nach Bedarf hinzugef\u00fcgt oder entfernt werden.<\/p>\n

<\/p>\n

\u00dcber dem Pool von ARDFS werden virtuelle Festplatten (Speicherobjekte f\u00fcr virtuelle Maschinen) hinzugef\u00fcgt, die aus virtuellen Bl\u00f6cken mit einer Gr\u00f6\u00dfe 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. <\/p>\n

<\/p>\n

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\u00e4ndlich auch Objekte des Speichers, sie werden, wie alles andere auch, \u00fcberwacht, und mit ihnen k\u00f6nnen alle Standardoperationen durchgef\u00fchrt werden, einschlie\u00dflich der Erstellung eines lokalen Hardware-RAID, aber das Cluster arbeitet ausschlie\u00dflich mit Knoten. <\/p>\n

<\/p>\n

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

<\/p>\n

Schemas zur Ausfallsicherheit des Speichers<\/h3>\n

<\/p>\n

Es kann zwei Arten von Ausfallsicherheitsschemata f\u00fcr virtuelle Festplatten in vAIR geben:<\/p>\n

<\/p>\n

1) Replikationsfaktor oder einfach Replikation \u2013 diese Methode der Ausfallsicherheit ist so einfach \u201ewie ein Stock und ein Seil\u201c. Es wird eine synchrone Replikation zwischen den Knoten mit einem Faktor von 2 (2 Kopien pro Cluster) oder 3 (3 Kopien entsprechend) durchgef\u00fchrt. RF-2 erm\u00f6glicht es der virtuellen Festplatte, den Ausfall eines Knotens im Cluster zu \u00fcberstehen, verbraucht aber die H\u00e4lfte des n\u00fctzlichen Volumens, w\u00e4hrend RF-3 den Ausfall von 2 Knoten im Cluster \u00fcbersteht, jedoch bereits 2\/3 des n\u00fctzlichen Volumens f\u00fcr sich reserviert. Dieses Schema erinnert stark an RAID-1, das hei\u00dft, 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. <\/p>\n

<\/p>\n

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

<\/p>\n

Wir haben eine virtuelle Maschine mit 8 MB einzigartiger (n\u00fctzlicher) Daten, die auf 4 vAIR-Knoten l\u00e4uft. Es ist klar, dass in der Realit\u00e4t wahrscheinlich nicht so wenig Speicherplatz vorhanden sein wird, aber f\u00fcr das Diagramm, das die Funktionsweise von ARDFS darstellt, ist dieses Beispiel am verst\u00e4ndlichsten. AB sind virtuelle Bl\u00f6cke von 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 den Knoten verteilt, wobei \u00dcberschneidungen derselben Daten auf einem Knoten vermieden werden, das hei\u00dft, die Kopie A1 wird nicht auf demselben Knoten wie die Kopie A2 sein. Bei B1 und B2 ist es \u00e4hnlich.<\/p>\n

<\/p>\n

\"Hyperkonvergente<\/p>\n

<\/p>\n

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). <\/p>\n

<\/p>\n

\"Hyperkonvergente<\/p>\n

<\/p>\n

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

<\/p>\n

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

<\/p>\n

2) Erasure Coding oder L\u00f6schkodierung (auch bekannt als \u201aexzessive Kodierung\u2018, \u201al\u00f6schende Kodierung\u2018 oder \u201aRedundanzkode\u2018) existiert genau, um das oben genannte Problem zu l\u00f6sen. EC ist ein Schema der Redundanz, das eine hohe Datenverf\u00fcgbarkeit bei geringeren Kosten f\u00fcr Speicherplatz im Vergleich zur Replikation gew\u00e4hrleistet. Das Prinzip dieses Mechanismus \u00e4hnelt RAID 5, 6, 6P. <\/p>\n

<\/p>\n

Beim Kodieren teilt der EC-Prozess den virtuellen Block (standardm\u00e4\u00dfig 4 MB) in mehrere kleinere \u201aDatenst\u00fccke\u2018 je nach EC-Schema auf (zum Beispiel teilt das 2+1-Schema jeden 4 MB Block in 2 St\u00fccke zu je 2 MB). Danach generiert dieser Prozess f\u00fcr die \u201aDatenst\u00fccke\u2018 \u201aParit\u00e4tsst\u00fccke\u2018 von nicht mehr als einem der zuvor geteilten Teile. Bei der Dekodierung generiert EC die fehlenden St\u00fccke, indem es die \u201a\u00fcbrig gebliebenen\u2018 Daten \u00fcber den gesamten Cluster liest. <\/p>\n

<\/p>\n

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 \u00fcberstehen wie RF-2. Dabei sind die Kosten geringer; insbesondere betr\u00e4gt der Nutzkostenfaktor bei RF-2 2, w\u00e4hrend er bei EC 2+1 1,5 betr\u00e4gt. <\/p>\n

<\/p>\n

Einfacher ausgedr\u00fcckt besteht der Kern darin, dass der virtuelle Block in 2-8 (warum von 2 bis 8, siehe unten) \u201aSt\u00fccke\u2018 aufgeteilt wird, und f\u00fcr diese St\u00fccke werden \u201aSt\u00fccke\u2018 der Parit\u00e4t gleichen Volumens berechnet. <\/p>\n

<\/p>\n

Letztendlich werden die Daten und ihre Parit\u00e4t gleichm\u00e4\u00dfig auf alle Knoten des Clusters verteilt. Dabei verteilt ARDFS, \u00e4hnlich wie bei der Replikation, die Daten automatisch auf die Knoten, um sicherzustellen, dass keine identischen Daten (Kopien der Daten und ihrer Parit\u00e4t) auf einem Knoten gespeichert werden, um das Risiko zu vermeiden, dass Daten verloren gehen, weil sowohl die Daten als auch ihre Parit\u00e4t pl\u00f6tzlich auf einem Knoten gespeichert sind, der ausf\u00e4llt. <\/p>\n

<\/p>\n

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

<\/p>\n

Die Bl\u00f6cke A und B werden jeweils in zwei Teile von 2 MB unterteilt (in zwei, weil 2+1), das hei\u00dft 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 aufgeteilt ist, ebenso wie Block B. Insgesamt erhalten wir zwei S\u00e4tze von 4 MB, in denen jeweils zwei St\u00fccke von zwei Megabyte enthalten sind. F\u00fcr jeden dieser S\u00e4tze wird die Parit\u00e4t von maximal einem St\u00fcck (d.h. 2 MB) berechnet, somit erhalten wir zus\u00e4tzlich + 2 Parit\u00e4tsst\u00fccke (A-P und B-P). 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 \u00fcberschneiden. 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, es ist auch der dritte) wird der ausgefallene Block B1 automatisch aus der Parit\u00e4t B-P, die auf Knoten Nr. 2 gespeichert ist, wiederhergestellt und wird auf dem Knoten aktiviert, auf dem keine B-Parit\u00e4t vorhanden ist, d.h. das St\u00fcck B-P. In diesem Beispiel ist das Knoten Nr. 1.<\/p>\n

<\/p>\n

\"Hyperkonvergente<\/p>\n

<\/p>\n

Ich bin sicher, der Leser stellt sich die Frage:<\/p>\n

<\/p>\n

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

Und dann folgen interessante Funktionsweisen von ARDFS.<\/p>\n

<\/p>\n

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

<\/p>\n

Urspr\u00fcnglich 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\u00fcr Flexibilit\u00e4t ausgelegt. Die Erh\u00f6hung der Anzahl der Datenst\u00fccke (X), in die ein virtueller Block geteilt wird, verringert die Overhead-Kosten, also erh\u00f6ht den nutzbaren Speicherplatz.
\nDie Erh\u00f6hung der Anzahl der Parit\u00e4tsst\u00fccke (Y) erh\u00f6ht die Zuverl\u00e4ssigkeit der virtuellen Festplatte. Je h\u00f6her der Wert von Y, desto mehr Knoten im Cluster k\u00f6nnen ausfallen. Nat\u00fcrlich verringert eine gr\u00f6\u00dfere Parit\u00e4t den verf\u00fcgbaren Speichervolumen, aber das ist der Preis f\u00fcr Zuverl\u00e4ssigkeit. <\/p>\n

<\/p>\n

Die Abh\u00e4ngigkeit der Leistung von den EC-Schemata ist nahezu linear: Je mehr \u201eSt\u00fccke\u201c, desto niedriger die Leistung; dabei ist ein ausgewogener Blick notwendig. <\/p>\n

<\/p>\n

Dieser Ansatz erm\u00f6glicht es den Administratoren, das verteilte Speichergebiet maximal flexibel zu konfigurieren. Innerhalb des ARDFS-Pools k\u00f6nnen beliebige Ausfallsicherheitsschemata und deren Kombinationen verwendet werden, was ebenfalls sehr n\u00fctzlich ist. <\/p>\n

<\/p>\n

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

<\/p>\n

\"Hyperkonvergente<\/p>\n

<\/p>\n

Aus der Tabelle geht hervor, dass selbst die komplexeste Kombination EC 8+7, die den Verlust von bis zu 7 Knoten im Cluster zul\u00e4sst, weniger nutzbaren Speicherplatz \u201everbraucht\u201c (1,875 gegen\u00fcber 2) als die Standardreplikation, w\u00e4hrend sie gleichzeitig 7-mal 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 zu X oder Y zus\u00e4tzliche Leistungs\u00fcberh\u00e4nge mit sich bringt, weshalb in dem Dreieck zwischen Zuverl\u00e4ssigkeit, Wirtschaftlichkeit und Leistung sehr sorgf\u00e4ltig gew\u00e4hlt werden muss. Aus diesem Grund widmen wir einen separaten Artikel dem Sizing der entfernten Kodierung.<\/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 \u00fcber dedizierte Ethernet-Schnittstellen eigenst\u00e4ndig. Ein wichtiger Punkt ist, dass ARDFS nicht nur Daten, sondern auch die Metadaten zum Speicher selbst synchronisiert. W\u00e4hrend der Arbeit an ARDFS haben wir gleichzeitig verschiedene bestehende L\u00f6sungen untersucht und festgestellt, dass viele die Synchronisierung der Metadaten des Dateisystems mit einer externen verteilten Datenbank, die wir ebenfalls zur Synchronisierung verwenden, durchf\u00fchren \u2013 jedoch nur f\u00fcr Konfigurationen und nicht f\u00fcr die Metadaten des Dateisystems (dar\u00fcber und \u00fcber andere verwandte Subsysteme wird im n\u00e4chsten Artikel berichtet). <\/p>\n

<\/p>\n

Die Synchronisierung der Metadaten des FS mithilfe einer externen DB ist nat\u00fcrlich eine funktionierende L\u00f6sung, aber dann w\u00fcrde die Konsistenz der auf ARDFS gespeicherten Daten von der externen DB und ihrem Verhalten abh\u00e4ngen (und sie ist, um ehrlich zu sein, eine launische Dame), was wir als schlecht erachten. Warum? Wenn die Metadaten des FS besch\u00e4digt werden, k\u00f6nnen auch die eigentlichen Daten des FS \"Lebewohl\" sagen, daher haben wir beschlossen, einen komplizierteren, aber zuverl\u00e4ssigeren Weg zu gehen. <\/p>\n

<\/p>\n

Das Subsystem zur Synchronisierung der Metadaten f\u00fcr ARDFS haben wir selbst entwickelt, und es funktioniert v\u00f6llig unabh\u00e4ngig von den angrenzenden Subsystemen. d.h. kein anderes Subsystem kann die Daten von ARDFS besch\u00e4digen. Unserer Meinung nach ist dies der zuverl\u00e4ssigste und richtige Weg, ob das tats\u00e4chlich so ist, wird die Zeit zeigen. Dar\u00fcber hinaus bietet dieser Ansatz einen zus\u00e4tzlichen Vorteil. ARDFS kann unabh\u00e4ngig von vAIR verwendet werden, einfach als erweitertes Speicher, was wir in zuk\u00fcnftigen Produkten sicherlich nutzen werden.<\/p>\n

<\/p>\n

Insgesamt haben wir mit der Entwicklung von ARDFS ein flexibles und zuverl\u00e4ssiges Dateisystem erhalten, das die Wahl bietet, wo man bei der Kapazit\u00e4t sparen oder alles auf Leistung setzen kann, oder das Speicher extrem zuverl\u00e4ssig zu einem gem\u00e4\u00dfigten Preis machen kann, wodurch die Leistungsanforderungen gesenkt werden. <\/p>\n

<\/p>\n

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\u00f6glicht dies, die L\u00f6sung sehr pr\u00e4zise auf die unterschiedlichen Anforderungen der Kunden zuzuschneiden und diesen Ausgleich in Zukunft leicht aufrechtzuerhalten. <\/p>\n

<\/p>\n

F\u00fcr wen ist dieses Wunder n\u00f6tig?<\/h2>\n

<\/p>\n

Einerseits k\u00f6nnte man sagen, dass es bereits Spieler auf dem Markt gibt, die ernsthafte L\u00f6sungen im Bereich Hyperkonvergenz haben, und wo wir eigentlich einsteigen. Diese Aussage scheint wahr zu sein, ABER...<\/p>\n

<\/p>\n

Andererseits sehen wir, wenn wir \"ins Feld\" gehen und mit Kunden sprechen, dass dies \u00fcberhaupt nicht der Fall ist. Es gibt viele Aufgaben f\u00fcr Hyperkonvergenz; an einigen Stellen wussten die Leute einfach nicht, dass es solche L\u00f6sungen gibt, woanders erschien es teuer, an anderen Orten gab es missratene Tests alternativer L\u00f6sungen, 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))). <\/p>\n

<\/p>\n

Wann ist ein HDD besser als ein GK?<\/h3>\n

<\/p>\n

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\u00f6sung? Viele Unternehmen \u2014 Hersteller von hyperkonvergenten Infrastrukturen (insbesondere solche, die kein SCSI-Array im Portfolio haben) sagen: \u201eSCSI-Arrays haben ausgedient, nur hyperkonvergente L\u00f6sungen!\u201c. Diese k\u00fchne Aussage spiegelt jedoch nicht ganz die Realit\u00e4t wider. <\/p>\n

<\/p>\n

Ehrlich gesagt, der Markt f\u00fcr SCSI-Arrays wandert tats\u00e4chlich in Richtung hyperkonvergenter und \u00e4hnlicher L\u00f6sungen, aber es gibt immer ein 'aber'.<\/p>\n

<\/p>\n

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\u00fcr die n\u00e4chsten 5-7 Jahre.<\/p>\n

<\/p>\n

Zweitens, die Infrastrukturen, die momentan in der Mehrheit (gemeint ist die Russische F\u00f6deration) gebaut werden, sind im klassischen Schema mit SCSI-Arrays und das nicht, weil die Leute nichts von hyperkonvergenten L\u00f6sungen wissen, sondern weil der Markt f\u00fcr hyperkonvergente L\u00f6sungen neu ist, die L\u00f6sungen 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).<\/p>\n

<\/p>\n

Drittens gibt es rein technisch gesehen, eine kleine Einschr\u00e4nkung durch zus\u00e4tzliche Verz\u00f6gerungen von 2 Millisekunden beim Schreiben (ohne Ber\u00fccksichtigung des lokalen Caches, versteht sich), die f\u00fcr die verteilte Speicherung zu zahlen sind. <\/p>\n

<\/p>\n

Und man sollte auch nicht die Verwendung gro\u00dfer physischer Server vergessen, die vertikale Skalierung der Speichersubsysteme bevorzugen.<\/p>\n

<\/p>\n

Es gibt viele erforderliche und beliebte Aufgaben, bei denen SCSI-Arrays besser abschneiden als hyperkonvergente L\u00f6sungen. Nat\u00fcrlich werden die Hersteller, die kein SCSI-Array im Produktportfolio haben, dem nicht zustimmen, aber wir sind bereit, argumentiert zu streiten. Selbstverst\u00e4ndlich werden wir als Entwickler beider Produkte in einer der kommenden Ver\u00f6ffentlichungen einen Vergleich zwischen SCSI-Arrays und hyperkonvergenten L\u00f6sungen durchf\u00fchren, bei dem wir anschaulich zeigen, welche L\u00f6sung unter welchen Bedingungen besser geeignet ist.<\/p>\n

<\/p>\n

Und wo werden hyperkonvergente L\u00f6sungen besser als SCSI-Arrays funktionieren?<\/h3>\n

<\/p>\n

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

<\/p>\n

    \n
  1. Dort, wo zus\u00e4tzliche 2 Millisekunden Verz\u00f6gerung 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\u00f6sung geeignet sein.<\/li>\n
  2. Dort, wo die Belastung gro\u00dfer physischer Server in viele kleine virtuelle Server umgewandelt und auf Knoten verteilt werden kann, wird auch hyperkonvergente Technologie gut ankommen.<\/li>\n
  3. Dort, wo horizontale Skalierung wichtiger ist als vertikale, wird auch hyperkonvergente Infrastruktur hervorragend funktionieren.<\/li>\n<\/ol>\n

    <\/p>\n

    Was sind das f\u00fcr L\u00f6sungen?<\/h3>\n

    <\/p>\n

      \n
    1. Alle standardm\u00e4\u00dfigen Infrastrukturleistungen (Verzeichnisdienste, E-Mail, Dokumentenmanagement, Dateiserver, kleine oder mittlere ERP- und BI-Systeme usw.). Wir bezeichnen das als \u201egemeinsame Berechnungen\u201c. <\/li>\n
    2. Die Infrastruktur von Cloud-Anbietern, wo es erforderlich ist, schnell und standardisiert horizontal zu skalieren und eine gro\u00dfe Anzahl von virtuellen Maschinen f\u00fcr Kunden leicht \u201ezuschneiden\u201c zu k\u00f6nnen.<\/li>\n
    3. Infrastruktur virtuellen Arbeitspl\u00e4tzen<\/a> (VDI), wo viele kleine Benutzer-VMs gestartet werden und ruhig innerhalb eines einheitlichen Clusters \u201eschwimmen\u201c.<\/li>\n
    4. Filialnetze, in denen jede Filiale eine standardisierte, ausfallsichere, aber gleichzeitig kosteng\u00fcnstige Infrastruktur aus 15-20 virtuellen Maschinen ben\u00f6tigt.<\/li>\n
    5. Irgendeine verteilte Berechnung (zum Beispiel Big Data-Dienste). Dort, wo die Belastung nicht \u201enach unten\u201c, sondern \u201enach au\u00dfen\u201c geht. <\/li>\n
    6. Testumgebungen, wo zus\u00e4tzliche kleine Verz\u00f6gerungen zul\u00e4ssig sind, aber Budgetbeschr\u00e4nkungen bestehen, weil es sich um Tests handelt.<\/li>\n<\/ol>\n

      <\/p>\n

      Momentan haben wir AERODISK vAIR genau f\u00fcr diese Aufgaben entwickelt und fokussieren uns darauf (bislang erfolgreich). Vielleicht wird sich das bald \u00e4ndern, da die Welt sich nicht stillsteht.<\/p>\n

      <\/p>\n

      Also\u2026<\/h3>\n

      <\/p>\n

      Damit ist der erste Teil eines gro\u00dfen Artikels 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\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\udd47Hyperkonvergente L\u00f6sung AERODISK vAIR. Grundlage \u2013 das Dateisystem ARDFS | ProHoster","description":"","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: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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}