Hallo zusammen! Mit diesem Artikel eröffnet AERODISK einen Blog über Habré. Hurra, Kameraden!
In früheren Artikeln zu Habré wurden Fragen zur Architektur und Grundkonfiguration von Speichersystemen diskutiert. In diesem Artikel gehen wir auf eine Frage ein, die bisher nicht behandelt wurde, aber häufig gestellt wird: die Fehlertoleranz von AERODISK ENGINE-Speichersystemen. Unser Team wird alles dafür tun, dass das AERODISK-Speichersystem nicht mehr funktioniert, d. h. breche es.
So kam es, dass bei Habré bereits Artikel über die Geschichte unseres Unternehmens, über unsere Produkte sowie ein Beispiel für eine erfolgreiche Umsetzung hängen Vielen Dank an unsere Partner – die Unternehmen TS Solution und Softline.
Daher werde ich hier nicht die Fähigkeiten zum Kopieren und Einfügen schulen, sondern lediglich Links zu den Originalen dieser Artikel bereitstellen:
Ich möchte auch gute Neuigkeiten mitteilen. Aber ich fange natürlich mit dem Problem an. Als junger Anbieter sind wir neben anderen Kostenfaktoren immer wieder mit der Tatsache konfrontiert, dass viele Ingenieure und Administratoren einfach nicht wissen, wie sie unser Speichersystem richtig bedienen sollen.
Es ist klar, dass die Verwaltung der meisten Speichersysteme aus Administratorsicht ungefähr gleich aussieht, aber jeder Hersteller hat seine eigenen Besonderheiten. Und wir sind hier keine Ausnahme.
Um die Ausbildung von IT-Spezialisten zu vereinfachen, haben wir uns daher entschlossen, dieses Jahr der kostenlosen Ausbildung zu widmen. Zu diesem Zweck eröffnen wir in vielen Großstädten Russlands ein Netzwerk von AERODISK-Kompetenzzentren, in denen jeder interessierte Techniker völlig kostenlos einen Kurs absolvieren und ein Zertifikat in der Verwaltung von AERODISK ENGINE-Speichersystemen erhalten kann.
In jedem Kompetenzzentrum werden wir einen vollwertigen Demostand aus dem AERODISK-Speichersystem und einen physischen Server installieren, auf dem unser Lehrer Präsenzschulungen durchführen wird. Wir werden den Arbeitsplan der Kompetenzzentren bei ihrem Erscheinen veröffentlichen, aber wir haben bereits ein Zentrum in Nischni Nowgorod eröffnet und die Stadt Krasnodar ist als nächstes dran. Über die untenstehenden Links können Sie sich für die Schulung anmelden. Hier die aktuell bekannten Informationen zu Städten und Terminen:
- Nizhny Novgorod (BEREITS GEÖFFNET – hier können Sie sich anmelden );
Bis zum 16. April 2019 können Sie das Zentrum zu jeder Arbeitszeit besuchen und am 16. April 2019 findet eine große Schulung statt. - Krasnodar (BALD ERÖFFNET – hier können Sie sich anmelden );
Vom 9. bis 25. April 2019 können Sie das Zentrum zu jeder Arbeitszeit besuchen und am 25. April 2019 findet eine große Schulung statt. - Jekaterinburg (BALD ERÖFFNET, folgen Sie den Informationen auf unserer Website oder auf Habré);
Mai-Juni 2019. - Novosibirsk (folgen Sie den Informationen auf unserer Website oder auf Habré);
Oktober 2019 - Krasnoyarsk (folgen Sie den Informationen auf unserer Website oder auf Habré);
November 2019.
Und wenn Moskau nicht weit von Ihnen entfernt ist, können Sie natürlich jederzeit unser Büro in Moskau besuchen und eine ähnliche Schulung absolvieren.
Alle. Wir sind mit dem Marketing fertig, kommen wir zur Technologie!
Auf Habré veröffentlichen wir regelmäßig technische Artikel über unsere Produkte, Belastungstests, Vergleiche, Anwendungsmerkmale und interessante Implementierungen.
Crashtests des AERODISK ENGINE N2-Speichersystems, Festigkeitstest
ACHTUNG! Nachdem Sie den Artikel gelesen haben, können Sie sagen: Nun, natürlich wird der Verkäufer selbst überprüfen, ob alles „mit einem Knall“ funktioniert, Gewächshausbedingungen usw. Ich werde antworten: Nichts dergleichen! Im Gegensatz zu unseren ausländischen Konkurrenten sind wir hier, in Ihrer Nähe, und Sie können jederzeit zu uns kommen (in Moskau oder in ein beliebiges Zentralkomitee) und unser Speichersystem auf beliebige Weise testen. Daher macht es für uns wenig Sinn, die Ergebnisse an ein ideales Weltbild anzupassen, denn Wir sind sehr einfach zu überprüfen. Für diejenigen, die zu faul sind und keine Zeit haben, können wir Ferntests organisieren. Dafür haben wir ein spezielles Labor. Kontaktiere uns.
ACHTUNG-2! Dieser Test ist kein Belastungstest, weil Hier geht es uns nur um Fehlertoleranz. In ein paar Wochen werden wir einen leistungsstärkeren Stand vorbereiten und Belastungstests des Speichersystems durchführen und die Ergebnisse hier veröffentlichen (Anfragen für Tests werden übrigens entgegengenommen).
Also, lasst es uns kaputt machen.
Prüfstand
Unser Stand besteht aus folgender Hardware:
- 1 x Aerodisk Engine N2-Speichersystem (2 Controller, 64 GB Cache, 8xFC-Ports 8Gb/s, 4xEthernet-Ports 10Gb/s SFP+, 4xEthernet-Ports 1Gb/s); Im Speichersystem sind folgende Datenträger verbaut:
- 4 x SAS-SSD-Festplatten 900 GB;
- 12 x SAS 10k-Festplatten 1,2 TB;
- 1 x physischer Server mit Windows Server 2016 (2xXeon E5 2667 v3, 96 GB RAM, 2xFC-Ports 8 Gbit/s, 2xEthernet-Ports 10 Gbit/s SFP+);
- 2 x SAN 8G-Switch;
- 2 x LAN 10G-Switch;
Wir haben den Server über Switches sowohl über FC als auch über 10G-Ethernet mit dem Speichersystem verbunden. Das Standdiagramm finden Sie unten.
Die von uns benötigten Komponenten wie MPIO und iSCSI-Initiator werden auf Windows Server installiert.
Zonen werden auf den FC-Switches konfiguriert, die entsprechenden VLANs werden auf den LAN-Switches konfiguriert und MTU 9000 wird auf den Speicherports, Switches und dem Host installiert (wie das alles geht, ist in unserer Dokumentation beschrieben, daher gehen wir nicht weiter darauf ein). diesen Vorgang hier).
Testmethodik
Der Crashtestplan sieht wie folgt aus:
- Überprüfung des Ausfalls von FC- und Ethernet-Ports.
- Stromausfallprüfung.
- Controller-Fehlerprüfung.
- Überprüfung auf Festplattenfehler in einer Gruppe/einem Pool.
Alle Tests werden unter synthetischen Lastbedingungen durchgeführt, die wir mit dem IOMETER-Programm generieren. Parallel dazu werden wir die gleichen Tests durchführen, jedoch unter der Bedingung, dass große Dateien in das Speichersystem kopiert werden.
Die IOmeter-Konfiguration lautet wie folgt:
- Lesen/Schreiben – 70/30
- Block – 128k (wir haben uns entschieden, die Speichersysteme in großen Blöcken zu waschen)
- Anzahl der Threads – 128 (was der produktiven Last sehr ähnlich ist)
- Vollständig zufällig
- Anzahl der Worker – 4 (2 für FC, 2 für iSCSI)
Der Test hat folgende Ziele:
- Stellen Sie sicher, dass der synthetische Lade- und Kopiervorgang bei verschiedenen Fehlerszenarien nicht unterbrochen wird oder Fehler verursacht.
- Stellen Sie sicher, dass der Prozess des Wechsels von Ports, Controllern usw. ausreichend automatisiert ist und im Fehlerfall keine Administratoraktionen erfordert (d. h. bei Failovers sprechen wir natürlich nicht von Failbacks).
- Stellen Sie sicher, dass die Informationen in den Protokollen korrekt angezeigt werden.
Vorbereiten des Host- und Speichersystems
Wir haben den Blockzugriff auf das Speichersystem mithilfe von FC- und Ethernet-Ports (FC bzw. iSCSI) konfiguriert. Die Jungs von TS Solution haben in einem früheren Artikel ausführlich beschrieben, wie das geht (). Und natürlich hat niemand die Handbücher und Kurse abgesagt.
Wir haben eine Hybridgruppe aufgebaut, die alle Antriebe nutzte, die wir hatten. Dem Cache wurden 2 SSD-Festplatten hinzugefügt, 2 SSD-Festplatten wurden als zusätzliche Speicherebene (Online-Ebene) hinzugefügt. Wir haben 12 SAS10k-Laufwerke in RAID-60P (dreifache Parität) gruppiert, um den Ausfall von drei Laufwerken in der Gruppe gleichzeitig zu überprüfen. Eine Festplatte blieb für den automatischen Austausch übrig.
Wir haben zwei LUNs verbunden (eines über FC, eines über iSCSI).
Der Besitzer beider LUNs ist der Engine-0-Controller
Beginnen wir mit dem Test
Wir aktivieren IOMETER mit der obigen Konfiguration.
Wir verzeichnen einen Durchsatz von 1.8 GB/s und eine Latenz von 3 Millisekunden. Es liegen keine Fehler vor (Gesamtfehleranzahl).
Gleichzeitig beginnen wir vom lokalen Laufwerk „C“ unseres Hosts parallel mit dem Kopieren von zwei großen 100-GB-Dateien auf FC- und iSCSI-Speicher-LUNs (Laufwerke E und G in Windows) und verwenden dabei andere Schnittstellen.
Oben ist der Kopiervorgang zu LUN FC, unten zu iSCSI.
Test Nr. 1: I/O-Ports deaktivieren
Wir nähern uns dem Speichersystem von hinten))) und ziehen mit einer leichten Handbewegung alle FC- und Ethernet-10G-Kabel aus dem Engine-0-Controller heraus. Es ist, als würde eine Putzfrau mit einem Wischmopp vorbeigehen und beschließen, den Boden genau dort zu waschen, wo der Rotz und die Kabel liegen (d. h. der Controller funktioniert noch, aber die I/O-Ports sind tot).
Schauen wir uns IOMETER und das Kopieren von Dateien an. Der Durchsatz sank auf 0,5 GB/s, kehrte aber schnell wieder auf das vorherige Niveau zurück (in etwa 4–5 Sekunden). Es liegen keine Fehler vor.
Das Kopieren von Dateien wurde nicht gestoppt, es gibt einen Geschwindigkeitsabfall, der jedoch überhaupt nicht kritisch ist (von 840 MB/s ist er auf 720 MB/s gesunken). Der Kopiervorgang wurde nicht gestoppt.
Wir sehen uns die Protokolle des Speichersystems an und sehen eine Meldung über die Nichtverfügbarkeit von Ports und die automatische Verschiebung der Gruppe.
Das Informationspanel verrät uns auch, dass mit den FC-Ports nicht alles so gut läuft.
Das Speichersystem hat einen Ausfall der E/A-Ports überstanden erfolgreich.
Test Nr. 2. Deaktivieren des Speichercontrollers
Fast sofort (nachdem wir die Kabel wieder an das Speichersystem angeschlossen hatten) beschlossen wir, das Speichersystem fertigzustellen, indem wir den Controller aus dem Gehäuse herauszogen.
Wieder nähern wir uns dem Speichersystem von hinten (es hat uns gefallen))) und dieses Mal ziehen wir den Engine-1-Controller heraus, der in diesem Moment der Besitzer des RDG ist (zu dem die Gruppe umgezogen ist).
Die Situation in IOmeter ist wie folgt. Die E/A wurde für etwa 5 Sekunden angehalten. Fehler häufen sich nicht.
Nach 5 Sekunden wurde die E/A mit etwa dem gleichen Durchsatz wieder aufgenommen, jedoch mit Latenzen von 35 Millisekunden (Latenzen wurden nach etwa ein paar Minuten korrigiert). Wie aus den Screenshots hervorgeht, beträgt der Wert „Total error count“ 0, d. h. es gab keine Schreib- oder Lesefehler.
Schauen wir uns das Kopieren unserer Dateien an. Wie Sie sehen, gab es keine Unterbrechung, es gab einen leichten Leistungsabfall, aber im Großen und Ganzen war alles wieder bei etwa 800 MB/s.
Wir gehen zum Speichersystem und sehen im Informationsfeld einen Fluch, der besagt, dass der Engine-1-Controller nicht verfügbar ist (natürlich haben wir ihn getötet).
Wir sehen auch einen ähnlichen Eintrag in den Protokollen.
Auch der Speichercontroller hat einen Ausfall überstanden erfolgreich.
Test Nr. 3: Trennen der Stromversorgung.
Für alle Fälle haben wir erneut mit dem Kopieren von Dateien begonnen, IOMETER jedoch nicht gestoppt.
Wir ziehen das Netzteil.
Dem Speichersystem wurde im Informationsbereich eine weitere Warnung hinzugefügt.
Auch im Sensormenü sehen wir, dass die mit dem herausgezogenen Netzteil verbundenen Sensoren rot geworden sind.
Das Speichersystem funktioniert weiterhin. Der Ausfall des Netzteils hat keinerlei Auswirkungen auf den Betrieb des Speichersystems; aus Sicht des Hosts blieben die Kopiergeschwindigkeit und die IOMETER-Anzeigen unverändert.
Stromausfalltest bestanden erfolgreich.
Vor dem abschließenden Test beschlossen wir, das Speichersystem noch ein wenig zum Leben zu erwecken, den Controller und das Netzteil wieder einzubauen und auch die Kabel in Ordnung zu bringen, worüber uns das Speichersystem mit grünen Symbolen in seinem Gesundheitspanel freudig informierte .
Test Nr. 4. Ausfall von drei Festplatten in einer Gruppe
Vor diesem Test haben wir einen zusätzlichen Vorbereitungsschritt durchgeführt. Tatsache ist, dass das ENGINE-Speichersystem eine sehr nützliche Sache bietet – verschiedene Wiederherstellungsrichtlinien. TS Solution hat bereits über diese Funktion geschrieben, aber erinnern wir uns an das Wesentliche. Der Speicheradministrator kann die Priorität für die Ressourcenzuweisung während der Wiederherstellung festlegen. Entweder in Richtung der I/O-Leistung, d. h. der Neuaufbau dauert länger, es kommt jedoch zu keinem Leistungsabfall. Oder in Richtung Wiederherstellungsgeschwindigkeit, aber die Produktivität wird reduziert. Oder eine ausgewogene Option. Da die Speicherleistung während der Wiederherstellung von Festplattengruppen für Administratoren immer ein Problem darstellt, werden wir eine Richtlinie testen, die sich auf die E/A-Leistung konzentriert und auf Kosten der Wiederherstellungsgeschwindigkeit geht.
Lassen Sie uns nun nach einem Festplattenfehler suchen. Wir ermöglichen auch die Aufzeichnung auf LUNs (Dateien und IOMETER). Da wir über eine Gruppe mit dreifacher Parität (RAID-60P) verfügen, bedeutet dies, dass das System dem Ausfall von drei Festplatten standhalten muss und nach dem Ausfall die automatische Ersetzung funktionieren muss, eine Festplatte eine der ausgefallenen ersetzen muss im RDG, und der Wiederaufbau muss beginnen.
Beginnen. Markieren wir zunächst über die Speicherschnittstelle die Festplatten, die wir herausziehen möchten (um die automatische Wechselfestplatte nicht zu verpassen und herauszuziehen).
Wir prüfen die Angabe auf der Hardware. Alles ist in Ordnung, wir sehen drei hervorgehobene Festplatten.
Und wir ziehen diese drei Scheiben heraus.
Schauen wir uns an, was auf dem Host steht. Und da... ist nichts Besonderes passiert.
Die Kopierindikatoren (sie sind höher als am Anfang, weil der Cache aufgewärmt ist) und IOMETER ändern sich nicht wesentlich, wenn die Festplatten entfernt und der Neuaufbau gestartet wird (innerhalb von 5-10 %).
Schauen wir uns an, was sich auf dem Speichersystem befindet.
Am Status der Gruppe sehen wir, dass der Umstrukturierungsprozess begonnen hat und kurz vor dem Abschluss steht.
Im RDG-Skelett können Sie sehen, dass sich zwei Festplatten im roten Status befinden und eine bereits ausgetauscht wurde. Die automatische Ersatzfestplatte ist nicht mehr vorhanden; sie hat die dritte ausgefallene Festplatte ersetzt. Der Neuaufbau dauerte mehrere Minuten, das Schreiben von Dateien wurde nicht unterbrochen, als drei Festplatten ausfielen, und die E/A-Leistung änderte sich nicht wesentlich.
Der Festplattenfehlertest wurde definitiv bestanden erfolgreich.
Abschluss
An diesem Punkt haben wir beschlossen, der Gewalt gegen Speichersysteme ein Ende zu setzen. Fassen wir zusammen:
- FC-Port-Fehlerprüfung – erfolgreich
- Fehlerprüfung des Ethernet-Ports – erfolgreich
- Controller-Ausfallprüfung – erfolgreich
- Stromausfalltest – erfolgreich
- Überprüfung des Festplattenfehlers im Gruppenpool – erfolgreich
Keiner der Fehler stoppte die Aufzeichnung oder verursachte Fehler bei der synthetischen Last; natürlich gab es einen Leistungseinbruch (und wir wissen, wie wir ihn beheben können, was wir bald tun werden), aber wenn man bedenkt, dass es sich um Sekunden handelt, ist das durchaus akzeptabel. Fazit: Die Fehlertoleranz aller Komponenten des AERODISK-Speichersystems funktionierte auf dem Niveau, es gab keine Fehlerquellen.
Natürlich können wir in einem Artikel nicht alle Fehlerszenarien testen, aber wir haben versucht, die beliebtesten abzudecken. Schicken Sie uns daher bitte Ihre Kommentare, Anregungen für zukünftige Veröffentlichungen und natürlich auch entsprechende Kritik. Wir besprechen das gerne (oder noch besser: Kommen Sie zum Training, ich kopiere den Zeitplan für alle Fälle)! Bis zu neuen Tests!
- Nizhny Novgorod (BEREITS GEÖFFNET – hier können Sie sich anmelden );
Bis zum 16. April 2019 können Sie das Zentrum zu jeder Arbeitszeit besuchen und am 16. April 2019 findet eine große Schulung statt. - Krasnodar (BALD ERÖFFNET – hier können Sie sich anmelden );
Vom 9. bis 25. April 2019 können Sie das Zentrum zu jeder Arbeitszeit besuchen und am 25. April 2019 findet eine große Schulung statt. - Jekaterinburg (BALD ERÖFFNET, folgen Sie den Informationen auf unserer Website oder auf Habré);
Mai-Juni 2019. - Novosibirsk (folgen Sie den Informationen auf unserer Website oder auf Habré);
Oktober 2019 - Krasnoyarsk (folgen Sie den Informationen auf unserer Website oder auf Habré);
November 2019.
Source: habr.com