Bewährte Methoden für Enterprise-Klasse-Speicher

Bewährte Methoden für Enterprise-Klasse-Speicher

Eine Sache, die mich schon immer verwirrt hat, sind Best Practices für die Speicherung. Dateisysteme prahlen damit, dass sie Petabyte oder Exabyte groß sein können. Dennoch kenne ich nicht viele Systemadministratoren, die bereit sind, ein einzelnes Volume auf mehrere Terrabyte anwachsen zu lassen. Ich weiß, dass der Hauptgrund dafür die Zeit ist, die es dauern würde, das Array wiederherzustellen, wenn ein Laufwerk ausfällt. Je mehr Laufwerke sich in einem einzelnen LUN befinden, desto länger dauert dies und desto größer ist das Risiko, während der Wiederherstellung ein weiteres Laufwerk zu verlieren.

Dann gibt es noch Nutzungsgründe. Administratoren erstellen eine LUN basierend darauf, wie viel Speicherplatz ihrer Meinung nach dem Projekt zugewiesen werden muss. Mir scheint es praktischer, wenn die LUN ein großes Array ist und Kontingente verwendet werden. Ich verstehe, dass dies nicht alle Anforderungen erfüllen würde (iSCSI), aber ich sehe viele NAS-Systeme (NFS), die auf diese Weise verwaltet werden. Ich verstehe auch, dass die zugrunde liegenden Volumes ganz einfach nach Bedarf vergrößert/verkleinert werden können, aber wäre es nicht weniger „riskant“, Kontingente zu verwenden, als Volumes zu manipulieren und mögliche Datenverluste in die Gleichung einzubringen?

Es gibt vielleicht noch andere Gründe, die ich nicht kenne, also klären Sie mich bitte auf. Können wir nicht erwarten, dass Dateisysteme irgendwann so groß werden? Warten wir darauf, dass die Hardware schneller wird, um die Wiederherstellungszeiten zu verkürzen?

Antwort1

Die Spindeltrennung ist ein guter Grund, kein großes Volume zu haben. Wenn Sie Exchange, SQL Server und andere zufällige Dinge (vielleicht ESXi-Gäste) von einem einzigen NFS-Gerät aus ausführen, werden Sie sicherlich eine Spindeltrennung wünschen. Exchange-Daten und Longs sollten sich auf voneinander getrennten Spindeln befinden, ebenso wie SQL-Datenbanken und -Protokolle.

Antwort2

Der Wiederaufbau eines Laufwerks hängt nicht vom Dateisystem ab, sondern vom Laufwerk selbst. Wenn Sie 2-TB-Laufwerke verwendet haben, wird der Wiederaufbau sehr viel Zeit in Anspruch nehmen.
Der Wiederaufbau ist ein Problem von RAID 5. Dafür unterstützen viele Controller jetzt RAID 6 oder, noch besser, RAID 10 (wenn Sie die beste Leistung wollen). Das Exportieren eines LUN ist eine Aufgabe für ein SAN, das Exportieren eines Dateisystems ist eine Aufgabe für NAS.
Beide haben ihre Vor- und Nachteile (suchen Sie bei Google, es gibt Unmengen an Papier darüber). Das Erstellen vieler unabhängiger LUNs (oder Dateisysteme) hat den Vorteil von Snapshot-Backups.

Antwort3

Persönlich würde ich echten Unternehmensverkehr (Oracle, MSSQL, Production ESX) überhaupt nicht über iSCSI oder NFS laufen lassen – ich kenne und vertraue FC, sowohl hinsichtlich der allgemeinen Leistung als auch bei Fehlersituationen. Natürlich bedeutet das, dass ich nicht einfach riesige LUNs erstellen und unterteilen kann, und es schafft eine ganze Menge Komplexität/Arbeit, aber unsere Systemverfügbarkeit und die Endbenutzererfahrung waren besser und konsistenter als erhofft.

Was Ihre eigentliche Antwort betrifft – nun, Ihre Beiträge scheinen sehr NetApp/Filer-orientiert zu sein, daher mein letzter Absatz – aber Sie haben die Gründe selbst dargelegt. Die Festplattenschnittstellen sind deutlich hinter die Festplattenkapazität zurückgefallen – was bedeutet, dass die Wiederherstellungszeiten lächerlich lang sein können, insbesondere wenn Sie während einer Wiederherstellung Ihres bestehenden Datenverkehrs eine anständige Leistung erzielen möchten. Festplatten sterben ständig und die Idee, während einer Wiederherstellung die Leistung mehrerer Plattformen zu beeinträchtigen, um dem Administrator einfach das Leben zu erleichtern, wäre in der Tat eine kurzlebige Methode. Auch aus rein plattformbezogener Sicherheitsperspektive möchten Sie Ihre Systeme möglicherweise partitionieren und der „große LUN“-Ansatz funktioniert in diesem Szenario möglicherweise nicht (natürlich basierend auf der Hardware).

Letztendlich sind Enterprise-SANs von Natur aus geschäfts- oder unternehmenskritisch und stellen höhere Anforderungen an Verfügbarkeit und Konsistenz als an Kosten, einfache Verwaltung oder sogar ultimative Leistung.

verwandte Informationen