150 TB und Wachstum, aber wie wachsen?

Meine Gruppe hat derzeit zwei große Speicherserver, beide NAS, auf denen Debian Linux läuft. Der erste ist ein mehrere Jahre alter All-in-One-Server mit 24 Festplatten (SATA). Wir haben zwei Hardware-RAIDS darauf eingerichtet, über die LVM verfügt. Der zweite Server besteht aus 64 Festplatten, die auf 4 Gehäuse verteilt sind, von denen jedes ein Hardware-RAID 6 ist und über eine externe SAS verbunden sind. Darüber hinaus verwenden wir XFS mit LVM, um 100 TB nutzbaren Speicher zu erstellen. All dies funktioniert ziemlich gut, aber wir sind diesen Systemen entwachsen. Nachdem wir zwei solcher Server gebaut haben und noch wachsen, möchten wir etwas bauen, das uns mehr Flexibilität im Hinblick auf zukünftiges Wachstum und Sicherungsoptionen ermöglicht, das sich bei Festplattenausfällen besser verhält (das Überprüfen des größeren Dateisystems kann einen Tag oder länger dauern) und Bestand hat in einer stark parallelen Umgebung (denken Sie an kleine Computercluster). Wir haben keine Unterstützung für die Systemadministration.

Was wir also suchen, ist eine relativ kostengünstige, akzeptable Performance-Speicherlösung, die zukünftiges Wachstum und eine flexible Konfiguration ermöglicht (denken Sie an ZFS mit unterschiedlichen Pools mit unterschiedlichen Betriebseigenschaften). Wir befinden uns wahrscheinlich außerhalb des Bereichs eines einzelnen NAS. Wir haben über eine Kombination von ZFS (zum Beispiel auf openindiana) oder btrfs pro Server nachgedacht, auf der glusterfs ausgeführt wird, wenn wir es selbst tun. Was wir dagegen abwägen, ist einfach die Kugel zu beißen und in Isilon- oder 3Par-Speicherlösungen zu investieren.

Anregungen oder Erfahrungen sind willkommen.

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

3Par / Isilon

Wenn Sie eine feste Anzahl von Arbeitsstunden für jemanden festlegen können und wollen, der die Rolle des SAN-Administrators übernimmt und ein schmerzloses Leben mit Nachtschlaf anstelle von Nachtarbeit führen möchte, dann ist dies der richtige Weg.

Mit einem SAN können Sie alle Aufgaben erledigen, bei denen ein einziger "Speicher" Sie einschränken würde (z. B. ein reines Flash-Array und ein großes 3-Par-Sata-Monster an denselben Server anschließen). Sie müssen jedoch auch dafür bezahlen und alles in gutem Zustand halten die Zeit, wenn Sie die Flexibilität nutzen wollen.

Alternativen

Amplidata

Vorteile: Scale-out, günstig, mit einem ansprechenden Konzept und dedizierten Lese- / Schreib-Cache-Layern. Dies könnte tatsächlich das Beste für Sie sein.

RisingTideOS

Die Zielsoftware wird derzeit in fast allen Linux-Speichern verwendet und ermöglicht ein etwas besseres Management als normale Linux- / Gluster-Anwendungen. (Imho) Die kommerzielle Version könnte einen Blick wert sein.

Glanz / Btrfs

PRO: Skaliert und "Bricks" geben Ihnen eine Abstraktionsschicht, die für das Management sehr gut ist.

CON: Das erste war für mich eine totale PITA. Es war nicht robust, und Ausfälle konnten entweder nur einen Stein betreffen oder alles aus dem Weg räumen. Jetzt, wo RedHat die Kontrolle hat, könnte es tatsächlich zu etwas Funktionierendem werden, und ich habe sogar Leute getroffen, die es zähmen können, so dass es jahrelang funktioniert. Und die zweite ist noch halb experimentell. Normalerweise braucht ein FS 3-4 Jahre, nachdem er "fertig" ist, bis er sich bewährt und robust ist. Wenn Sie sich für die Daten interessieren, warum würden Sie das jemals in Betracht ziehen? Apropos experimenteller, kommerzieller Ceph-Support ist fast erschienen, aber Sie müssen sich an die "RBD" -Schicht halten, die FS ist nur noch nicht ausreichend getestet. Ich möchte klarstellen, dass Ceph auf lange Sicht viel attraktiver ist. :)

ZFS

Pro: Features, die definitiv einen Nagel in den Sarg anderer Sachen stecken. Diese Funktionen sind gut gestaltet (denken Sie an L2ARC) und Komprimierung / Deduplizierung macht Spaß. Weitere "Speichercluster", dh nur kleine Ausfälle anstelle eines großen konsolidierten Booms

Con: Wartung vieler kleiner Software-Boxen anstelle eines echten Speichers. Müssen sie integrieren und $$$ Stunden verbringen, um ein robustes Setup zu haben.

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, da Sie mehr wachsen müssen, stehen Ihnen einige weitere Optionen zur Verfügung.

Wie Sie wissen, haben die großen Hardwarehersteller NAS-Köpfe für ihren Speicher. Dies würde Ihnen in der Tat einen einzigen Anbieter geben, mit dem Sie zusammenarbeiten können, um alles zu ermöglichen, und es würde ziemlich gut funktionieren. Es sind einfache Lösungen (im Vergleich zu Heimwerker), und ihre Wartbarkeit ist geringer. Aber sie kosten ziemlich viel. Einerseits verfügen Sie über mehr technische Ressourcen zur Lösung Ihrer Hauptprobleme als über Infrastrukturprobleme. Auf der anderen Seite, wenn Sie wie die meisten Universitätsfakultäten sind, von denen ich weiß, dass Arbeitskräfte im Vergleich zum Bezahlen von Bargeld für Dinge wirklich günstig sind.

Wenn Sie den DIY-Weg gehen, haben Sie bereits ein gutes Verständnis für die DIY-Optionen, die Ihnen zur Verfügung stehen. ZFS / BTRFS sind der offensichtliche Upgrade-Pfad von XFS + LVM für skalierten Speicher. Ich würde BTRFS meiden, bis es im Linux-Kernel als "stabil" deklariert wird. Dies dürfte bald der Fall sein, da einige der großen kostenlosen Distributionen es als Standarddateisystem verwenden. Für ZFS empfehle ich die Verwendung einer BSD-Basis anstelle von OpenIndiana, da diese bereits länger besteht und die Probleme (mehr) behoben wurden.

Gluster wurde für den hier beschriebenen Anwendungsfall entwickelt. Es kann sowohl replizieren als auch einen einzelnen virtuellen Server mit viel Speicherplatz bereitstellen. Ihre Distributed Volumes sind genau das, wonach Sie suchen, da sie die Dateien auf alle Speicherserver auf dem angegebenen Volume verteilen. Sie können weiterhin separate Speicherserver hinzufügen, um das sichtbare Volume weiter zu erweitern. Einzelner Namensraum!

Das Problem mit Gluster ist, dass es am besten funktioniert, wenn Ihre Kunden den Gluster-Client verwenden können, um auf das System zuzugreifen, anstatt auf die CIFS- oder NFS-Optionen. Da Sie einen kleinen Cluster-Compute-Cluster ausführen, können Sie möglicherweise nur den GlusterFS-Client verwenden.

Sie sind hier auf dem richtigen Weg.

Soweit ich weiß, können Sie eine SAN-Lösung verwenden, die auf Linux SCST + FibreChannel oder Infiniband basiert. Als Basis für die LUNs können Sie LVM zusätzlich zu Hardware-RAIDs verwenden und Snapshots / Replikationen (als Beispiel DRBD) unterhalb der Dateisystemebene ausführen. Als Dateisystem kenne ich keine gute Lösung für Concurency, da ich ESXi auf die Knoten lege, sodass die Datenspeicher von ESX Concurrent FS verwaltet werden. Ich denke, GFS2 könnte mit dieser Umgebung funktionieren, aber ich bin nicht 100% sicher, da Sie Ihre genauen Anforderungen überprüfen sollten. Sobald Sie ein robustes SAN unter Ihren Knoten haben, ist es ziemlich einfach, die Dinge zu erledigen.