„Verrückte Hände“ oder Wie wir Aufbewahrungssysteme aus Streichhölzern und Eicheln blendeten / Sudo Null IT News

In der aktuellen Realität mit den Schwierigkeiten beim Kauf neuer Arrays erinnerte ich mich an eine Geschichte, die vor fünf Jahren passierte. Es wurde fast vergessen, aber jetzt scheint es für sich selbst ziemlich relevant zu sein. Einmal kam ein Kunde zu uns, der Lagersysteme wollte. Es war unrealistisch, ein fertiges Speichersystem zu kaufen, das in sein Budget passte, aber es musste nicht nur billig und fröhlich, sondern billig und normal sein. Also beschlossen wir, kreativ zu werden. Glücklicherweise hatte der Kunde eine gewisse Phasenentwicklung, und wir hatten genug Zeit, um das Speichervolumen schrittweise zu erhöhen.

Erste Stufe

Das erste Volumen wurde dann auf den „guten alten“ Arrays des Anbieters N realisiert. Es ist wichtig, dass der Kunde einen Ort brauchte, um viele Ordner zu speichern, in denen sich Dateien im Videoformat befinden würden (das Unternehmen arbeitet in den Medien aufstellen). Daher war es notwendig, einen „kalten“ Speicher zu bauen, der keine besondere Leistung erfordert.

Als nächstes haben wir eine Lösung basierend auf der Open-Source-Software GlusterFS Version 3.8 entworfen und uns auch für die Ausrüstung entschieden, in die wir viele erschwingliche Festplatten „gesteckt“ haben. Die Lösung könnte horizontal skaliert und für die Bedürfnisse anderer verwendet werden.

Wir haben diese Option erfolgreich implementiert und waren zuversichtlich, dass die Lösung gut funktionieren würde. Als wir es mit dem Kunden getestet haben, stellte sich jedoch heraus, dass das Öffnen jedes Ordners mindestens 20 Sekunden dauert. Und wenn zwei Benutzer gleichzeitig denselben Ordner öffnen, wird diese Zeit verdoppelt.

Langsam und traurig

Lange Zeit konnten wir nicht verstehen, warum eine so niedrige Geschwindigkeit angeschlossen war. Bei den Vortests war schließlich alles in Ordnung! Als sie anfingen, tiefer zu graben, stellten sie fest, dass das Problem nicht mit dem Betrieb des Clusters zusammenhing. Und es erschien sogar lokal – auf einem Knoten.

Gleichzeitig war mit den Festplatten alles in Ordnung – sie waren nicht voll geladen, und wir konnten uns nicht an ihrer maximalen Leistung ausruhen. Der Hinterhalt wartete dort auf uns, wo wir es am wenigsten erwartet hatten – das XFS-Dateisystem selbst funktioniert nicht sehr gut mit einer großen Anzahl von Dateien.

Wir haben einen synthetischen Test durchgeführt: Wir haben einen Ordner mit einem Skript erstellt, in dem 10.000 Ordner gespeichert waren, und in jedem dieser Ordner befanden sich eine Million kleine Dateien. Alles – das System legte sich sofort hin, selbst das Anzeigen der Liste mit 10.000 Ordnern war unanständig langsam.

Hier stießen wir auf eine weitere Einschränkung – Gluster erlaubte damals keine Verwendung eines anderen Dateisystems außer XFS. Und wir haben bereits ein fertiges Projekt zur Hand. Alles ist verloren!

Zweiter Versuch

Ich musste ganz von vorne anfangen und Experten aus einer benachbarten Einheit anwerben. Für einen x86-Server ist die Auswahl an Dateisystemen gering: Linux und darauf basierende Lösungen. Außer uns hat sich wirklich niemand auf dem Markt einer solchen Aufgabe gestellt?

Wir fanden eine kostengünstige kommerzielle Lösung und begannen, in verschiedenen Foren und in den IT-Communities nach weiteren Informationen darüber zu suchen. Es ging um das ZFS-Dateisystem, das für das Solaris-Betriebssystem erstellt wurde.

Die Laufzeiten des Projekts liefen bereits konkret ab, und für Tests blieb praktisch keine Zeit. Wir fanden heraus, dass ZFS bereits auf Linux portiert wurde, und beschlossen, diese Option und einen der Solaris-Forks parallel zu testen.

Unter Linux ist nichts Gutes passiert – genauso wie es war. Auf dem Solar-Fork mit Treibern für die oVirt-Virtualisierung funktionierte das System nach mehreren Versuchen. Wir haben eine Reihe wiederholter Tests an unseren synthetischen Tests durchgeführt – es funktioniert gut, es gibt keine Beschwerden. Dateien werden sofort geöffnet.

Allgemeine Architektur einer ZFS-basierten SDS-LösungAllgemeine Architektur einer ZFS-basierten SDS-Lösung

Das Projekt musste natürlich umgeschrieben werden. Das Backend wurde auf iSCSI blocky, die Redundanz auf Serverebene blieb erhalten. Die Hauptaufgabe war damit gelöst – wir haben die erforderliche Menge für das Speichersystem mit der erforderlichen Leistung erhalten und gleichzeitig die Rechenressourcen der Server für die Virtualisierung genutzt.

Für das System wurde eine detaillierte Betriebsdokumentation entwickelt, die vom Betriebsdienst zur Durchführung von Routineverfahren und zur Wiederherstellung nach typischen Ausfällen verwendet wird.

Der Kunde war zufrieden ☺ Der von uns erstellte Speicher funktioniert seit vielen Jahren und funktioniert einwandfrei, ohne Verfügbarkeitsverluste und Leistungseinbußen. Gleichzeitig wurde die Kapazität der Anlage um das Anderthalbfache erhöht. Rechnen wir die Einsparungen durch, dann haben wir im Vergleich zu Speichersystemen eines namhaften Herstellers 40 % gewonnen.

Obwohl die Geschichte uralt ist, verliert sie gerade unter den neuen Bedingungen nicht an Aktualität, wenn Unternehmen nicht so sehr vor der Aufgabe stehen, das IT-Budget zu optimieren, sondern zumindest eine bezahlbare und funktionierende Lösung zu finden. So kommt man mit IT-Ingenieuität aus fast jeder, auch scheinbar aussichtslosen Situation heraus. Haben Sie etwas Ähnliches getan? Erzähl in den Kommentaren.

Similar Posts

Leave a Reply

Your email address will not be published.