F

Wie Sie die optimale LUN-Größe wählen

Eine Frage – drei Experten antworten und geben verschiedene Optionen, wie Sie am besten die optimale LUN-Größe für ihr Storage-System wählen.

Auf die Frage eines Lesers hin, wie er am besten die optimale LUN-Größe für seinen virtuellen Storage festlegt, entschloss sich das searchstorage-Team, nicht nur eine Antwort zu geben. Neben unserem Experten Brien Posey fanden sich auch unter unseren Lesern erfahrene IT-Verantwortliche, die ihr Wissen teilten. Damit erhalten Sie hier verschiedene Optionen, die LUN-Größe zu bestimmen, denn nicht immer ist nur eine Antwort die richtige.

Auf unserem IBM Shark-System kann ich eine LUN über ein ganzes RAID-Set hinweg anlegen, die sich dem Host dann als eine Disk präsentiert. Es lassen sich aber auch verschiedene kleine LUNs einrichten, die sich dem Host dann auch als verschiedene Disks darstellen. Welche Methode ist die bessere? Mir wurde gesagt, dass es besser sei, multiple kleinere LUNs zu konfigurieren als nur eine große. Die kleinen LUNs erlauben mehr gleichzeitige (concurrent) I/Os seitens des Betriebssystems. Das gilt auch für unsere EMC Symmetrix mit Meta-Volumes.

Ziggy S: Die Vor- und Nachteile kleiner LUNs

Der Vorteil kleiner LUNs ist, dass Sie diese über viele Array-Gruppen hinweg anlegen und dann Logical Volume Manager (LVM) nutzen können, um ihre Volume-Gruppen zu konfigurieren (im Verbund oder RAID 0). Das wird Ihnen die best mögliche Performance im Back-End geben. Trotzdem ist dies nicht die LUN-Größe. Vielmehr ist es die Möglichkeit, den I/O über viele Array-Gruppen zu verteilen. Bei einem Shark-System würde ich vorschlagen, dass eine Array-Gruppe nicht mehr als vier LUNs aus der gleichen RAID-0-Volume-Gruppe haben sollte.

Der Nachteil kleiner LUNs ist, dass Sie zahlreiche interne Adressen verbrauchen. Nutzen Sie eine LUN-Größe von 2 GByte, so ist die maximale Kapazität Ihres Shark-Systems acht TByte (4.096 x 2 GByte), egal wie groß die verwendeten physischen Medien sind.

Alan McLachlan: LUNS und Probleme mit der Workload des Applikationsservers

Wenn Sie dem Rat von Ziggy S. folgen, viele kleine LUNs zu generieren, so generieren Sie mehr Workload für den Applikationsserver. Ob nun eine große LUN oder mehrere kleinere LUNs der bessere Ansatz sind, hängt von einer Menge Faktoren ab. 

Dazu gehören unter anderem die Applikation selbst, die Serverkapazität, die Caching- und RAID-Performance des Subsystems sowie das File-System-Management des Host-Betriebssystems. Sie möchten ja nicht erreichen, dass Ihr Back-End potentiell optimiert wird, nur um dann festzustellen, dass es sein neues Maximum nie ausreizen kann, da der Host auf einmal die Dinge verlangsamt. Ich betone, dass diese Methode nicht falsch, sondern im Zweifelsfalle nicht so einfach ist.

Wenn Sie – aus welchem Grund auch immer – LVM einsetzen, so erzeugt dies mehr Prozesse für alle I/Os, also sollten Sie das Beste daraus machen. Letztlich kann ein Problem im File-System des Servers die Eigenschaften des Block-I/Os verderben, so dass ein wenig zusätzlicher Overhead auf Block-Ebene irrelevant wird.

Brien Posey: LUN-Größe den Anforderungen anpassen

Das Thema um der richtigen und passenden LUN-Größe wurde bereits oft und hitzig diskutiert. Lassen Sie mich gleich vorweg betonen, dass es die ideale LUN-Größe für jede Situation nicht gibt. Die Anforderungen der Anwender sind unterschiedlich und so ist es wichtig, eine LUN-Größe zu wählen, die Ihren eigenen, individuellen Anforderungen entsprechen als sich blindlings auf einen Standard zu verlassen.

Es gibt viele Faktoren, die man bei der Wahl der richtigen LUN-Größe berücksichtigen muss. Die hier angeführte Liste ist sicher nicht allumfassend, aber es gibt Ihnen eine gute Richtlinie.

Als erstes müssen Sie entscheiden, wie LUNs genutzt werden. Benötigen Sie beispielsweise viel Platz für File-Storage, dann könnte es ausreichend sein, eine LUN anzulegen. Ebenso gibt es Situationen, in denen das Storage-Array als eine LUN konfiguriert wird und dann als großes Cluster Shared Volume (CSV) agiert.

Im Zusammenhang wie die LUNs verwendet werden, lohnt es sich auch, die Best-Practices-Ratschläge von Software-Herstellern näher zu betrachten. Nehmen wir zum Beispiel an, Sie verwenden die LUN, um dort Virtual Hard Disks (VHDs) zu speichern. Einige Hypervisor-Anbieter empfehlen, nur eine begrenzte Zahl aktiver VHDs pro LUN einzurichten (nicht verwendete VHDs zählen nicht).

Eines der besten Argumente für den Einsatz kleinerer LUNs ist Backup und Recovery. Stellen Sie sich vor, es kommt bei einer LUN zu einem Problem und erfordert eine Wiederherstellung. Es ist natürlich völlig logisch, dass sich eine kleine LUN viel schneller wiederherstellen lässt als eine große – unter der Annahme, dass diese fast voll sind.

Ein weiterer Faktor ist das Load Balancing. Nehmen wir an, Sie möchten ein Array mit 32 TByte für die Speicherung virtueller Maschinen nutzen. Hier haben Sie zahlreiche Optionen, das Storage bereitzustellen. Sie könnten eine einzige LUN mit 32 TByte einrichten, oder zwei LUNs mit je 16 TByte oder vier LUNS mit je acht TByte. Sie könnten sogar 32 LUNs mit nur einem TByte konfigurieren.

Bei nur einer großen LUN kann es dazu kommen, dass die Storage-Performance abfällt, wenn mehr und mehr VMs angelegt werden. In VMware-Umgebungen können Sie Laod Balancing für die VM-Workload einsetzen, indem Sie Storage DRS verwenden.

Storage DRS benötigt Data-Stores mit multiplen Quellen. Je mehr Date-Stores sie verfügbar machen, desto mehr Optionen für das Load Balancing der Workload bietet Storage DRS. Trotzdem möchten Sie in dieser Situation sicher nicht 32 LUNs erstellen, da es recht schnell passieren kann, dass eine VM größer als ein TByte wird. Hier müssen Sie abwägen, wie wichtig das Load Balancing für die Größe der VMs ist.

Folgen Sie SearchStorage.de auch auf Twitter, Google+ und Facebook!

Artikel wurde zuletzt im Mai 2015 aktualisiert

Erfahren Sie mehr über Disk-Arrays

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close