AERODISK vAIR hyperkonvergente Lösung. Grundlage ist das ARDFS-Dateisystem

Hallo, Habr-Leser. Mit diesem Artikel eröffnen wir eine Reihe, in der es um das von uns entwickelte hyperkonvergente System AERODISK vAIR geht. Ursprünglich wollten wir im ersten Artikel alles über alles erzählen, aber das System ist ziemlich komplex, deshalb werden wir den Elefanten in Teilen essen.

Beginnen wir die Geschichte mit der Entstehungsgeschichte des Systems, tauchen wir ein in das ARDFS-Dateisystem, das die Grundlage von vAIR bildet, und sprechen wir auch ein wenig über die Positionierung dieser Lösung auf dem russischen Markt.

In zukünftigen Artikeln werden wir ausführlicher über verschiedene Architekturkomponenten (Cluster, Hypervisor, Load Balancer, Überwachungssystem usw.), den Konfigurationsprozess sprechen, Lizenzprobleme ansprechen, Crashtests separat zeigen und natürlich über Lasttests schreiben und Größe. Auch der Community-Version von vAIR werden wir einen eigenen Artikel widmen.

Ist Aerodisk eine Geschichte über Speichersysteme? Oder warum haben wir überhaupt mit der Hyperkonvergenz begonnen?

Die Idee, eine eigene Hyperkonvergenz zu schaffen, kam uns erstmals etwa im Jahr 2010. Zu diesem Zeitpunkt gab es weder Aerodisk noch ähnliche Lösungen (kommerzielle hyperkonvergente Box-Systeme) auf dem Markt. Unsere Aufgabe war folgende: Aus einer Reihe von Servern mit lokalen Festplatten, die durch eine Verbindung über das Ethernet-Protokoll verbunden sind, musste ein erweiterter Speicher erstellt und dort virtuelle Maschinen und ein Softwarenetzwerk gestartet werden. All dies musste ohne Speichersysteme umgesetzt werden (denn für Speichersysteme und deren Hardware fehlte einfach das Geld und wir hatten noch keine eigenen Speichersysteme erfunden).

Wir haben viele Open-Source-Lösungen ausprobiert und dieses Problem schließlich gelöst, aber die Lösung war sehr komplex und schwer zu wiederholen. Außerdem war diese Lösung in der Kategorie „Funktioniert es?“ Nicht anfassen! Nachdem wir dieses Problem gelöst hatten, haben wir die Idee, das Ergebnis unserer Arbeit in ein vollwertiges Produkt umzuwandeln, nicht weiterentwickelt.

Nach diesem Vorfall haben wir uns von dieser Idee entfernt, aber wir hatten immer noch das Gefühl, dass dieses Problem vollständig lösbar war und die Vorteile einer solchen Lösung mehr als offensichtlich waren. Anschließend bestätigten die veröffentlichten HCI-Produkte ausländischer Unternehmen dieses Gefühl nur.

Deshalb haben wir uns Mitte 2016 dieser Aufgabe im Rahmen der Entwicklung eines vollwertigen Produkts wieder angenommen. Zu diesem Zeitpunkt hatten wir noch keine Beziehungen zu Investoren, daher mussten wir für unser eigenes nicht sehr großes Geld einen Entwicklungsstand kaufen. Nachdem wir gebrauchte Server und Switches auf Avito gesammelt hatten, machten wir uns an die Arbeit.

Die Hauptaufgabe bestand zunächst darin, ein eigenes, wenn auch einfaches, aber eigenes Dateisystem zu erstellen, das Daten in Form von virtuellen Blöcken automatisch und gleichmäßig auf die n-te Anzahl von Clusterknoten verteilen konnte, die durch eine Verbindung über Ethernet verbunden sind. Gleichzeitig soll das FS gut und einfach skalierbar und unabhängig von Nachbarsystemen sein, d.h. von vAIR in Form von „nur einer Lagereinrichtung“ entfremdet werden.

Erstes vAIR-Konzept

Wir haben bewusst auf den Einsatz vorgefertigter Open-Source-Lösungen zur Organisation von Stretched Storage (Ceph, Gluster, Lustre und dergleichen) zugunsten einer eigenen Entwicklung verzichtet, da wir damit bereits viel Projekterfahrung hatten. Natürlich sind diese Lösungen selbst hervorragend, und bevor wir an Aerodisk arbeiteten, haben wir mehr als ein Integrationsprojekt mit ihnen umgesetzt. Aber es ist eine Sache, eine bestimmte Aufgabe für einen Kunden umzusetzen, Mitarbeiter zu schulen und vielleicht die Unterstützung eines großen Anbieters zu kaufen, und eine ganz andere Sache, ein leicht replizierbares Produkt zu erstellen, das für verschiedene Aufgaben verwendet wird, die wir als Verkäufer, vielleicht wissen wir nicht einmal etwas über uns selbst. Für den zweiten Zweck waren bestehende Open-Source-Produkte für uns nicht geeignet, sodass wir beschlossen, selbst ein verteiltes Dateisystem zu erstellen.
Zwei Jahre später erzielten mehrere Entwickler (die die Arbeit an vAIR mit der Arbeit am klassischen Engine-Speichersystem kombinierten) ein bestimmtes Ergebnis.

Bis 2018 hatten wir ein einfaches Dateisystem geschrieben und es mit der notwendigen Hardware ergänzt. Das System kombinierte physische (lokale) Festplatten verschiedener Server über eine interne Verbindung zu einem flachen Pool und „zerschnitt“ sie in virtuelle Blöcke. Anschließend wurden aus den virtuellen Blöcken Blockgeräte mit unterschiedlichem Grad an Fehlertoleranz erstellt, auf denen virtuelle Blöcke erstellt wurden und mithilfe der KVM-Hypervisor-Autos ausgeführt.

Wir haben uns nicht allzu sehr um den Namen des Dateisystems gekümmert und es kurz und bündig ARDFS genannt (raten Sie mal, wofür es steht).

Dieser Prototyp sah gut aus (natürlich nicht optisch, es gab noch kein visuelles Design) und zeigte gute Ergebnisse in Bezug auf Leistung und Skalierung. Nach dem ersten echten Ergebnis setzten wir dieses Projekt in Gang und organisierten eine vollwertige Entwicklungsumgebung und ein separates Team, das sich nur mit vAIR befasste.

Zu diesem Zeitpunkt war die allgemeine Architektur der Lösung bereits ausgereift und hatte noch keine wesentlichen Änderungen erfahren.

Eintauchen in das ARDFS-Dateisystem

ARDFS ist die Grundlage von vAIR, das eine verteilte, fehlertolerante Datenspeicherung im gesamten Cluster bereitstellt. Eine der (aber nicht die einzigen) Besonderheiten von ARDFS besteht darin, dass keine zusätzlichen dedizierten Server für Metadaten und Verwaltung verwendet werden. Dies war ursprünglich dazu gedacht, die Konfiguration der Lösung zu vereinfachen und ihre Zuverlässigkeit zu gewährleisten.

Lagerstruktur

Innerhalb aller Knoten des Clusters organisiert ARDFS einen logischen Pool aus dem gesamten verfügbaren Speicherplatz. Es ist wichtig zu verstehen, dass es sich bei einem Pool noch nicht um Daten oder formatierten Speicherplatz handelt, sondern lediglich um Markup, d. h. Alle Knoten mit installiertem vAIR werden beim Hinzufügen zum Cluster automatisch zum gemeinsam genutzten ARDFS-Pool hinzugefügt und Festplattenressourcen werden automatisch im gesamten Cluster gemeinsam genutzt (und stehen für die zukünftige Datenspeicherung zur Verfügung). Mit diesem Ansatz können Sie Knoten im Handumdrehen hinzufügen und entfernen, ohne dass dies schwerwiegende Auswirkungen auf das bereits laufende System hat. Diese. Das System lässt sich sehr einfach „in Bausteinen“ skalieren, indem bei Bedarf Knoten im Cluster hinzugefügt oder entfernt werden.

Dem ARDFS-Pool werden virtuelle Festplatten (Speicherobjekte für virtuelle Maschinen) hinzugefügt, die aus virtuellen Blöcken mit einer Größe von 4 Megabyte aufgebaut sind. Virtuelle Festplatten speichern Daten direkt. Das Fehlertoleranzschema wird auch auf der Ebene der virtuellen Festplatte festgelegt.

Wie Sie vielleicht schon vermutet haben, verwenden wir zur Fehlertoleranz des Festplattensubsystems nicht das Konzept von RAID (Redundant Array of Independent Disks), sondern RAIN (Redundant Array of Independent Nodes). Diese. Die Fehlertoleranz wird basierend auf den Knoten und nicht auf den Festplatten gemessen, automatisiert und verwaltet. Festplatten sind natürlich auch ein Speicherobjekt, sie werden wie alles andere überwacht, man kann mit ihnen alle Standardoperationen durchführen, einschließlich des Aufbaus eines lokalen Hardware-RAID, aber der Cluster arbeitet speziell auf Knoten.

In einer Situation, in der Sie wirklich RAID benötigen (z. B. ein Szenario, das mehrere Ausfälle in kleinen Clustern unterstützt), hindert Sie nichts daran, lokale RAID-Controller zu verwenden und darauf Stretched Storage und eine RAIN-Architektur aufzubauen. Dieses Szenario ist ziemlich real und wird von uns unterstützt, daher werden wir in einem Artikel über typische Szenarien für die Verwendung von vAIR darüber sprechen.

Speicherfehlertoleranzschemata

In vAIR kann es zwei Fehlertoleranzschemata für virtuelle Festplatten geben:

1) Replikationsfaktor oder einfach Replikation – diese Methode der Fehlertoleranz ist so einfach wie ein Stock und ein Seil. Die synchrone Replikation erfolgt zwischen Knoten mit einem Faktor von 2 (2 Kopien pro Cluster) oder 3 (jeweils 3 Kopien). RF-2 ermöglicht es einer virtuellen Festplatte, dem Ausfall eines Knotens im Cluster standzuhalten, „frisst“ aber die Hälfte des nutzbaren Volumens, und RF-3 hält dem Ausfall von 2 Knoten im Cluster stand, reserviert aber 2/3 davon nützliches Volumen für seine Bedürfnisse. Dieses Schema ist RAID-1 sehr ähnlich, d. h. eine in RF-2 konfigurierte virtuelle Festplatte ist resistent gegen den Ausfall eines beliebigen Knotens im Cluster. In diesem Fall ist mit den Daten alles in Ordnung und selbst die E/A wird nicht gestoppt. Wenn der ausgefallene Knoten wieder in Betrieb genommen wird, beginnt die automatische Datenwiederherstellung/-synchronisierung.

Nachfolgend finden Sie Beispiele für die Verteilung von RF-2- und RF-3-Daten im Normalmodus und in einer Fehlersituation.

Wir verfügen über eine virtuelle Maschine mit einer Kapazität von 8 MB einzigartiger (nützlicher) Daten, die auf 4 vAIR-Knoten läuft. Es ist klar, dass es in Wirklichkeit unwahrscheinlich ist, dass es ein so kleines Volumen geben wird, aber für ein Schema, das die Logik des ARDFS-Betriebs widerspiegelt, ist dieses Beispiel am verständlichsten. AB sind 4 MB große virtuelle Blöcke, die eindeutige Daten der virtuellen Maschine enthalten. RF-2 erstellt zwei Kopien dieser Blöcke A1+A2 bzw. B1+B2. Diese Blöcke sind knotenübergreifend „angeordnet“, wodurch vermieden wird, dass sich dieselben Daten auf demselben Knoten überschneiden, d. h. Kopie A1 befindet sich nicht auf demselben Knoten wie Kopie A2. Das Gleiche gilt für B1 und B2.

Wenn einer der Knoten ausfällt (z. B. Knoten Nr. 3, der eine Kopie von B1 enthält), wird diese Kopie automatisch auf dem Knoten aktiviert, auf dem keine Kopie seiner Kopie vorhanden ist (d. h. eine Kopie von B2).

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

Das Replikationsschema ist zwar einfach und zuverlässig, weist jedoch das gleiche Problem wie RAID1 auf: nicht genügend nutzbarer Speicherplatz.

2) Es gibt Erasure Coding oder Erasure Coding (auch bekannt als „redundante Codierung“, „Erasure Coding“ oder „Redundanzcode“), um das oben genannte Problem zu lösen. EC ist ein Redundanzschema, das im Vergleich zur Replikation eine hohe Datenverfügbarkeit bei geringerem Speicherplatzaufwand bietet. Das Funktionsprinzip dieses Mechanismus ähnelt RAID 5, 6, 6P.

Bei der Kodierung teilt der EC-Prozess einen virtuellen Block (standardmäßig 4 MB) in mehrere kleinere „Datenblöcke“ auf, je nach EC-Schema (z. B. teilt ein 2+1-Schema jeden 4-MB-Block in 2 2-MB-Blöcke). Als nächstes generiert dieser Prozess „Paritätsblöcke“ für die „Datenblöcke“, die nicht größer als einer der zuvor geteilten Teile sind. Bei der Dekodierung generiert EC die fehlenden Blöcke, indem es die „überlebenden“ Daten im gesamten Cluster liest.

Beispielsweise kann eine virtuelle Festplatte mit einem 2 + 1 EC-Schema, das auf 4 Cluster-Knoten implementiert ist, den Ausfall eines Knotens im Cluster genauso problemlos überstehen wie RF-2. In diesem Fall sind die Gemeinkosten geringer, insbesondere beträgt der Nutzkapazitätskoeffizient für RF-2 2 und für EC 2+1 1,5.

Einfacher ausgedrückt besteht das Wesentliche darin, dass der virtuelle Block in 2-8 (warum von 2 bis 8, siehe unten) „Stücke“ unterteilt wird und für diese Stücke „Stücke“ mit Parität und ähnlichem Volumen berechnet werden.

Dadurch werden Daten und Parität gleichmäßig auf alle Knoten des Clusters verteilt. Gleichzeitig verteilt ARDFS, wie bei der Replikation, Daten automatisch auf Knoten, sodass verhindert wird, dass identische Daten (Kopien von Daten und deren Parität) auf demselben Knoten gespeichert werden, um das Risiko eines Datenverlusts auszuschließen Dies führt dazu, dass die Daten und ihre Parität plötzlich auf einem Speicherknoten landen, der ausfällt.

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

Die Blöcke A und B sind in zwei Teile zu je 2 MB unterteilt (zwei, weil 2+1), also A1+A2 und B1+B2. Im Gegensatz zu einer Replik ist A1 keine Kopie von A2, sondern ein virtueller Block A, der wie Block B in zwei Teile geteilt ist. Insgesamt erhalten wir zwei Sätze von 4 MB, von denen jeder zwei 2-MB-Teile enthält. Als nächstes wird für jeden dieser Sätze die Parität mit einem Volumen von nicht mehr als einem Stück (d. h. 2 MB) berechnet, wir erhalten zusätzlich + 4 Paritätsstücke (AP und BP). Insgesamt haben wir 2×2 Daten + 2×XNUMX Parität.

Als nächstes werden die Teile zwischen den Knoten „angeordnet“, damit sich die Daten nicht mit ihrer Parität überschneiden. Diese. A1 und A2 befinden sich nicht auf demselben Knoten wie AP.

Bei Ausfall eines Knotens (zum Beispiel auch des dritten) wird der ausgefallene Block B1 automatisch aus der BP-Parität, die auf Knoten Nr. 2 gespeichert ist, wiederhergestellt und auf dem Knoten aktiviert, auf dem er sich befindet keine B-Parität, d.h. Stück BP. In diesem Beispiel ist dies Knoten Nr. 1

Ich bin sicher, der Leser hat eine Frage:

„Alles, was Sie beschrieben haben, wurde schon lange sowohl von Wettbewerbern als auch in Open-Source-Lösungen implementiert. Was ist der Unterschied zwischen Ihrer Implementierung von EC in ARDFS?“

Und dann wird es noch interessante Features von ARDFS geben.

Erasure Coding mit Fokus auf Flexibilität

Zunächst haben wir ein ziemlich flexibles EC-X+Y-Schema bereitgestellt, bei dem X einer Zahl von 2 bis 8 und Y einer Zahl von 1 bis 8 entspricht, jedoch immer kleiner oder gleich X. Dieses Schema wird bereitgestellt für Flexibilität. Durch Erhöhen der Anzahl der Datenstücke (X), in die der virtuelle Block unterteilt wird, können die Gemeinkosten gesenkt, d. h. der nutzbare Platz vergrößert werden.
Durch Erhöhen der Anzahl der Paritätsblöcke (Y) wird die Zuverlässigkeit der virtuellen Festplatte erhöht. Je größer der Y-Wert ist, desto mehr Knoten im Cluster können ausfallen. Natürlich verringert die Erhöhung des Paritätsvolumens die Menge der nutzbaren Kapazität, aber das ist ein Preis, der für die Zuverlässigkeit zu zahlen ist.

Die Abhängigkeit der Leistung von EC-Schaltungen ist nahezu direkt: Je mehr „Stücke“, desto geringer die Leistung; hier ist natürlich eine ausgewogene Betrachtung erforderlich.

Dieser Ansatz ermöglicht es Administratoren, Stretched Storage mit maximaler Flexibilität zu konfigurieren. Innerhalb des ARDFS-Pools können Sie beliebige Fehlertoleranzschemata und deren Kombinationen verwenden, was unserer Meinung nach auch sehr nützlich ist.

Nachfolgend finden Sie eine Tabelle, in der mehrere (nicht alle möglichen) RF- und EC-Systeme verglichen werden.

Die Tabelle zeigt, dass selbst die „frotteeste“ Kombination EC 8+7, die den gleichzeitigen Verlust von bis zu 7 Knoten in einem Cluster ermöglicht, weniger nutzbaren Speicherplatz „frisst“ (1,875 gegenüber 2) als die Standardreplikation und siebenmal besser schützt , was diesen Schutzmechanismus zwar komplexer, aber in Situationen, in denen maximale Zuverlässigkeit bei begrenztem Speicherplatz gewährleistet werden muss, viel attraktiver macht. Gleichzeitig müssen Sie verstehen, dass jedes „Plus“ gegenüber X oder Y einen zusätzlichen Leistungsaufwand bedeutet. Daher müssen Sie im Dreieck zwischen Zuverlässigkeit, Einsparungen und Leistung sehr sorgfältig auswählen. Aus diesem Grund widmen wir der Erasure-Coding-Größe einen separaten Artikel.

Zuverlässigkeit und Autonomie des Dateisystems

ARDFS läuft lokal auf allen Knoten des Clusters und synchronisiert diese auf eigene Faust über dedizierte Ethernet-Schnittstellen. Der wichtige Punkt ist, dass ARDFS nicht nur die Daten, sondern auch die speicherbezogenen Metadaten unabhängig synchronisiert. Während der Arbeit an ARDFS haben wir gleichzeitig eine Reihe bestehender Lösungen untersucht und festgestellt, dass viele die Metadaten des Dateisystems mithilfe eines externen verteilten DBMS synchronisieren, das wir auch für die Synchronisierung verwenden, jedoch nur für Konfigurationen, nicht für FS-Metadaten (über dieses und andere verwandte Subsysteme). im nächsten Artikel).

Die Synchronisierung von FS-Metadaten mit einem externen DBMS ist natürlich eine funktionierende Lösung, aber dann würde die Konsistenz der auf ARDFS gespeicherten Daten vom externen DBMS und seinem Verhalten abhängen (und, ehrlich gesagt, es ist eine launische Dame), was in Unsere Meinung ist schlecht. Warum? Wenn die FS-Metadaten beschädigt werden, können auch die FS-Daten selbst „auf Wiedersehen“ gesagt werden. Deshalb haben wir uns für einen komplexeren, aber zuverlässigeren Weg entschieden.

Wir haben das Metadaten-Synchronisierungs-Subsystem für ARDFS selbst erstellt und es lebt völlig unabhängig von benachbarten Subsystemen. Diese. Kein anderes Subsystem kann ARDFS-Daten beschädigen. Unserer Meinung nach ist dies der zuverlässigste und korrekteste Weg, aber ob das tatsächlich so ist, wird die Zeit zeigen. Darüber hinaus bietet dieser Ansatz einen weiteren Vorteil. ARDFS kann unabhängig von vAIR verwendet werden, ebenso wie Stretched Storage, was wir sicherlich in zukünftigen Produkten verwenden werden.

Als Ergebnis haben wir durch die Entwicklung von ARDFS ein flexibles und zuverlässiges Dateisystem erhalten, das Ihnen die Wahl lässt, Kapazität zu sparen oder bei der Leistung alles aufzugeben oder einen äußerst zuverlässigen Speicher zu angemessenen Kosten zu erstellen, aber die Leistungsanforderungen zu reduzieren.

Zusammen mit einer einfachen Lizenzierungsrichtlinie und einem flexiblen Bereitstellungsmodell (künftig wird vAIR pro Knoten lizenziert und entweder als Software oder als Softwarepaket geliefert) ermöglicht dies eine sehr genaue Anpassung der Lösung an eine Vielzahl von Kundenanforderungen und -anforderungen Dann halten Sie dieses Gleichgewicht problemlos aufrecht.

Wer braucht dieses Wunder?

Einerseits können wir sagen, dass es bereits Player auf dem Markt gibt, die ernsthafte Lösungen im Bereich Hyperkonvergenz haben, und in diese Richtung gehen wir tatsächlich. Es scheint, dass diese Aussage wahr ist, ABER...

Wenn wir hingegen auf die Felder gehen und mit Kunden kommunizieren, stellen wir und unsere Partner fest, dass dies überhaupt nicht der Fall ist. Es gibt viele Aufgaben für Hyperkonvergenz, an manchen Orten wussten die Leute einfach nicht, dass es solche Lösungen gibt, an anderen schien es teuer, an anderen gab es erfolglose Tests alternativer Lösungen und an anderen verbot man den Kauf aufgrund von Sanktionen überhaupt. Im Allgemeinen stellte sich heraus, dass das Feld ungepflügt war, also gingen wir los, um Neuland anzubauen))).

Wann ist das Speichersystem besser als GKS?

Während wir mit dem Markt arbeiten, werden wir oft gefragt, wann es besser ist, ein klassisches Schema mit Speichersystemen zu verwenden, und wann hyperkonvergent? Viele Unternehmen, die GCS produzieren (insbesondere solche, die keine Speichersysteme in ihrem Portfolio haben) sagen: „Speichersysteme werden veraltet, nur noch hyperkonvergent!“ Dies ist eine kühne Aussage, die jedoch nicht ganz die Realität widerspiegelt.

Tatsächlich bewegt sich der Speichermarkt in Richtung Hyperkonvergenz und ähnlichen Lösungen, aber es gibt immer ein „Aber“.

Erstens können Rechenzentren und IT-Infrastrukturen, die nach dem klassischen Schema mit Speichersystemen gebaut wurden, nicht einfach wieder aufgebaut werden, so dass die Modernisierung und Fertigstellung solcher Infrastrukturen noch 5-7 Jahre lang eine Altlast bleibt.

Zweitens wird die Infrastruktur, die derzeit zum größten Teil aufgebaut wird (also die Russische Föderation), nach dem klassischen Schema unter Verwendung von Speichersystemen aufgebaut, und zwar nicht, weil die Leute nichts über Hyperkonvergenz wissen, sondern weil der Hyperkonvergenzmarkt neu ist, Lösungen und Standards sind noch nicht etabliert, IT-Mitarbeiter sind noch nicht ausgebildet, sie haben wenig Erfahrung, aber sie müssen hier und jetzt Rechenzentren bauen. Und dieser Trend wird noch 3-5 Jahre anhalten (und dann ein weiteres Vermächtnis, siehe Punkt 1).

Drittens gibt es eine rein technische Einschränkung durch zusätzliche kleine Verzögerungen von 2 Millisekunden pro Schreibvorgang (natürlich mit Ausnahme des lokalen Caches), die den Kosten für verteilten Speicher entsprechen.

Vergessen wir nicht die Verwendung großer physischer Server, die die vertikale Skalierung des Festplattensubsystems lieben.

Es gibt viele notwendige und beliebte Aufgaben, bei denen sich Speichersysteme besser verhalten als GCS. Hier werden uns natürlich diejenigen Hersteller nicht zustimmen, die keine Speichersysteme in ihrem Produktportfolio haben, aber wir sind bereit, vernünftig zu argumentieren. Natürlich werden wir als Entwickler beider Produkte in einer unserer zukünftigen Veröffentlichungen auf jeden Fall Speichersysteme und GCS vergleichen und anschaulich zeigen, was unter welchen Bedingungen besser ist.

Und wo funktionieren hyperkonvergente Lösungen besser als Speichersysteme?

Aus den oben genannten Punkten lassen sich drei offensichtliche Schlussfolgerungen ziehen:

1. Wo eine zusätzliche Latenzzeit von 2 Millisekunden für die Aufzeichnung, die bei jedem Produkt durchweg auftritt (jetzt sprechen wir nicht von Kunststoffen, Nanosekunden können auf Kunststoffen angezeigt werden), unkritisch sind, eignet sich Hyperkonvergenz.
2. Wo die Last großer physischer Server in viele kleine virtuelle Server umgewandelt und auf Knoten verteilt werden kann, funktioniert Hyperkonvergenz auch dort gut.
3. Wo die horizontale Skalierung eine höhere Priorität hat als die vertikale Skalierung, ist GCS auch dort gut geeignet.

Was sind diese Lösungen?

1. Alle Standard-Infrastrukturdienste (Verzeichnisdienst, Mail, EDMS, Dateiserver, kleine oder mittlere ERP- und BI-Systeme usw.). Wir nennen dies „allgemeines Rechnen“.
2. Die Infrastruktur von Cloud-Anbietern, bei der es notwendig ist, eine große Anzahl virtueller Maschinen für Kunden schnell und standardisiert horizontal zu erweitern und einfach zu „schneiden“.
3. Virtuelle Desktop-Infrastruktur (VDI), in der viele kleine virtuelle Benutzermaschinen ausgeführt werden und in einem einheitlichen Cluster stillschweigend „schweben“.
4. Zweigstellennetzwerke, bei denen jede Zweigstelle eine standardmäßige, fehlertolerante, aber kostengünstige Infrastruktur mit 15 bis 20 virtuellen Maschinen benötigt.
5. Jedes verteilte Computing (z. B. Big-Data-Dienste). Wobei die Belastung nicht „in die Tiefe“, sondern „in die Breite“ geht.
6. Testumgebungen, in denen zusätzliche kleine Verzögerungen akzeptabel sind, es jedoch Budgetbeschränkungen gibt, da es sich um Tests handelt.

Für diese Aufgaben haben wir derzeit AERODISK vAIR entwickelt und auf sie konzentrieren wir uns (bisher mit Erfolg). Vielleicht ändert sich das bald, denn... Die Welt steht nicht still.

So ...

Damit ist der erste Teil einer großen Artikelserie abgeschlossen; im nächsten Artikel werden wir über die Architektur der Lösung und die verwendeten Komponenten sprechen.

Wir freuen uns über Fragen, Anregungen und konstruktive Auseinandersetzungen.

Source: habr.com