Frage 150 TB und wachsen, aber wie man wächst?


Meine Gruppe hat derzeit zwei große Storage-Server, beide NAS debian Linux. Der erste ist ein All-in-One-24-Festplatten (SATA) -Server, der mehrere Jahre alt ist. Wir haben zwei Hardware-RAIDS mit LVM darauf eingerichtet. Der zweite Server besteht aus 64 Festplatten, die auf 4 Gehäuse verteilt sind, jeweils ein Hardware-RAID 6, das über eine externe SAS verbunden ist. Wir verwenden XFS mit LVM, um 100 TB verwendbaren Speicher zu erstellen. All das funktioniert ziemlich gut, aber wir sind diesen Systemen entwachsen. Nachdem wir zwei solche Server gebaut haben und immer noch wachsen, wollen wir etwas bauen, das uns mehr Flexibilität in Bezug auf zukünftiges Wachstum ermöglicht, Backup-Optionen, die sich besser unter Festplattenfehlern verhalten (die Überprüfung des größeren Dateisystems kann einen Tag oder länger dauern) und kann bestehen in einer stark gleichzeitigen Umgebung (denke kleinen Computer-Cluster). Wir haben keine Systemadministrationsunterstützung, also verwalten wir all das selbst (wir sind ein Genomiklabor).

Was wir also suchen, ist eine relativ kostengünstige, akzeptable Performance-Speicherlösung, die zukünftiges Wachstum und flexible Konfiguration ermöglicht (denke ZFS mit unterschiedlichen Pools mit unterschiedlichen Betriebseigenschaften). Wir sind wahrscheinlich außerhalb des Bereichs eines einzelnen NAS. Wir haben über eine Kombination von ZFS (auf openindiana zum Beispiel) oder btrfs pro Server nachgedacht, wobei glusterfs darüber läuft, wenn wir es selbst machen. Womit wir dagegen abwiegen, steckt einfach in die Kugel und investiert in Isilon- oder 3Par-Speicherlösungen.

Irgendwelche Vorschläge oder Erfahrungen werden geschätzt.


18
2018-03-25 12:47


Ursprung




Antworten:


Ich hoffe, das wird ein wenig helfen. Ich habe versucht, es nicht zu einer vollen Textwand werden zu lassen. :)

3Par / Isilon

Wenn Sie jemandem, der die Rolle des SAN-Administrators übernimmt und ein schmerzloses Leben mit Nachtschlaf anstelle von Nachtarbeit genießen möchte, eine bestimmte Anzahl an Arbeitsstunden widmen können, dann würde ich so vorgehen.

Mit einem SAN kannst du all die Dinge tun, bei denen ein einziger "Speicher" dich limitieren würde (dh du verbindest ein reines Speicher-Flash-Array und ein großes 3-teiliges Sata-Monster mit demselben Server), aber du musst auch dafür bezahlen und alles gut erhalten die Zeit, wenn Sie die Flexibilität nutzen wollen.

Alternativen

Amplidata

Vorteile: Scale out, billig, mit einem schönen Konzept und dedizierten Lese- / Schreib-Cache-Schichten. Dies könnte tatsächlich das Beste für dich sein.

SteigendesTIDEOS

Ihre Ziel-Software wird jetzt in fast allen Linux-Speichern verwendet und erlaubt ein etwas besseres Management, als es einfache Linux / Gluster-Sachen können. (Meiner bescheidenen Meinung nach) Die kommerzielle Version könnte einen Blick wert sein.

Glanz / btrfs

PRO: Scales out und "Bricks" geben dir eine Abstraktionsebene, die sehr gut für das Management ist.

CON: Die erste war eine totale PITA für mich. Es war nicht robust und Fehler konnten entweder lokal zu einem Ziegelstein sein oder alles herausnehmen. Jetzt, mit RedHat in der Kontrolle, könnte es tatsächlich etwas funktionieren und ich habe sogar Leute getroffen, die können zähmen Sie es so, dass es jahrelang funktioniert. Und die zweite ist noch halb experimentell. Normalerweise braucht ein FS 3-4 Jahre, nachdem es "fertig" ist, bis es bewiesen und robust ist. Wenn Sie sich für die Daten interessieren, warum sollten Sie jemals darüber nachdenken? Apropos experimentell, die kommerzielle Unterstützung von Ceph ist jetzt fast out, aber Sie müssen sich an die "RBD" Schicht halten, der FS ist noch nicht ausreichend getestet. Ich möchte jedoch klarstellen, dass Ceph auf lange Sicht viel attraktiver ist. :)

ZFS

Pro: Features, die den Sarg eines anderen Stopfers definitiv in den Sand setzen. Diese Funktionen sind gut entworfen (denke L2ARC) und Komprimierung / Deduplizierung macht Spaß. Haben Sie mehr "Speichercluster", was bedeutet, dass Sie auch nur kleine Fehler anstelle von einem großen konsolidierten haben Boom

Con: Wartung vieler kleiner Software-Boxen anstelle eines realen Speichers. Müssen Sie integrieren und verbringen Sie $$$ Stunden, um eine robuste Einrichtung zu haben.


16
2018-03-25 13:22



+1. Ich hoffe es macht dir nichts aus, dass ich es ein bisschen weniger wall-y gemacht habe. - Kyle Smith
@ florian-heigl Könnten wir ein paar Links folgen, da ich kein Glück habe, einige der von Ihnen erwähnten Lösungen zu finden (z. B. 3Par, Isilon, RisingTideOS). TIA. - ossandcad


Die XFS + LVM-Route ist in der Tat eine der besten Optionen für eine skalierte reine Linux-Speicherlösung in den letzten Jahren. Ich bin ermutigt, dass du schon da bist. Jetzt, wo Sie mehr wachsen müssen, stehen Ihnen noch einige weitere Optionen zur Verfügung.

Wie Sie wissen, haben die großen Hardware-Anbieter da NAS-Köpfe für ihren Speicher. Dies würde Ihnen in der Tat einen einzigen Anbieter zur Verfügung stellen, mit dem Sie alles schaffen können, und es würde ziemlich gut funktionieren. Sie sind einfache Lösungen (im Vergleich zu DIY) und ihre Wartbarkeit ist geringer. Aber sie kosten ziemlich viel. Auf der einen Seite haben Sie mehr technische Ressourcen zur Lösung Ihrer Hauptprobleme als Infrastrukturprobleme. Auf der anderen Seite, wenn Sie wie die meisten Universitätsabteilungen sind, habe ich gewusst, dass Macht im Vergleich zu Bargeld für Dinge wirklich billig ist.

Auf der DIY-Route haben Sie bereits ein gutes Verständnis für die Ihnen zur Verfügung stehenden Heimwerker-Optionen. ZFS / BTRFS ist der offensichtliche Upgrade-Pfad von XFS + LVM für skalierten Speicher. Ich würde BTRFS meiden, bis es im Linux-Mainline-Kernel als 'stable' deklariert wird, was ziemlich bald sein sollte, da einige der großen freien Distributionen es als Standard-Dateisystem verwenden. Für ZFS würde ich empfehlen, eine BSD-Basis anstelle von OpenIndiana zu verwenden, einfach weil es länger herum ist und die Knicke (mehr) ausgearbeitet hat.

Gluster wurde für den hier beschriebenen Anwendungsfall entwickelt. Es kann sowohl Replikation ausführen als auch einen einzelnen virtuellen Server mit viel Speicher bereitstellen. Ihr Verteilte Volumes Sound genau das, was Sie suchen, da sie die Dateien über alle Storage-Server auf dem deklarierten Volume verbreiten. Sie können weiterhin separate Speicherserver hinzufügen, um das sichtbare Volumen weiterhin zu erweitern. Einzelner Namensraum!

Das Problem mit Gluster besteht darin, dass es am besten funktioniert, wenn Ihre Kunden den Gluster-Client für den Zugriff auf das System anstelle der CIFS- oder NFS-Optionen verwenden können. Da Sie einen kleinen Cluster-Computing-Cluster ausführen, können Sie möglicherweise nur den GlusterFS-Client verwenden.

Du bist hier auf der richtigen Spur.


7
2018-03-25 13:03



Eine Do-it-yourself-Lösung bedeutet, dass wenn Sie es selbst brechen, Sie es selbst reparieren müssen. Dies wird teuer, wenn Sie über die Grenzen einiger Server hinauswachsen. Wenn es irgendeinen geschäftlichen Druck gibt, diesen Speicher hoch verfügbar zu machen, werden Sie weniger Geld ausgeben, als ein Rad selbst zu erfinden. Speicher-Software, die auf Servern läuft, kann dazu gebracht werden, alles zu tun, was echter Speicher kann, aber nicht billiger. - Basil


Soweit ich weiß, könnte man eine SAN-Lösung verwenden, die auf dem Linux SCST + FibreChannel oder Infiniband basiert, was gerade im Aufbau ist. Als Basis für die LUNs könnten Sie LVM zusätzlich zu Hardware-RAIDs verwenden und Snapshots / Replikation (nehmen Sie DRBD als Beispiel) unterhalb der Dateisystemebene durchführen. Als Dateisystem ist mir keine gute Lösung für die Konsistenz bekannt, da ich ESXi auf die Knoten lege, so dass die Datenspeicher von ESX concurrent FS verwaltet werden. Ich denke, GFS2 könnte mit dieser Umgebung arbeiten, aber ich bin nicht 100% sicher, da Sie Ihre genauen Anforderungen überprüfen sollten. Sobald Sie jedoch ein robustes SAN unter Ihren Knoten haben, ist es ziemlich einfach, Dinge zu erledigen.


1
2018-03-25 15:44