11.06.2007 | Autor / Redakteur: Alan Radding und Achim Karpf / Nico Litzel
Der Prozess des Storage Provisioning ist noch immer kompliziert und aufwendig. Jeder Hersteller bietet seine proprietären Tools an und empfiehlt einen eigenen Ansatz. Welche Möglichkeiten Administratoren haben, das Speicher-Provisioning zu vereinfachen und was bei der Wahl der LUN-Größe (Logical Unit Number) zu beachten ist, zeigt der folgende Beitrag.
Storage Provisioning, zu Deutsch „Speicher-Bevorratung“, wird der Prozess genannt, in dem physischer Speicher in logischen aufgeteilt wird, um so den Bedarf von Unternehmen nach Speicherkapazität, Leistung, Sicherheit und Effizienz zu decken. Er umfasst die Zuordnung von Servern/Hosts zu entsprechenden Speicherressourcen, gibt Netzpfade zwischen Hosts und Storage an, maskiert Server und teilt das Netz in Zonen auf, sodass die richtigen Server zugreifen können. Der gesamte Provisioning-Prozess besteht aus Dutzenden von einzelnen Schritten.
Wenn diese Schritte optimal abgearbeitet werden, funktioniert das Speicher-Provisioning reibungslos und vor allem unterbrechungsfrei. Werden sie aber fehlerhaft ausgeführt, so lässt die Leistung der Anwendungen nach. Ebenso sind die Sicherheit der Systeme und die Skalierbarkeit eingeschränkt und die Kapazitätsauslastung niedrig. Dadurch kann Speicherplatz verschwendet werden.
Um Storage Provisioning besser in den Griff zu bekommen, sollten Sie zunächst herausfinden und festlegen, wer eigentlich die Verantwortung für das Provisioning im Unternehmen innehat. „Beim Provisioning gibt es eine Vielzahl von Schnittstellen”, sagt Robert Stevenson, Managing Director für Storage-Lösungen bei TheInfoPro, einem New Yorker Marktforschungsunternehmen. Stevenson war früher Storage-Manager bei der Nielsen-Medienforschung und war dort für über 1.000 LUNs (Logical Unit Number, Zuordnung für die Ansteuerung von Geräten im SCSI-Bus) zuständig.
Den Provisioning-Prozess hat Stevenson bei Nielsen mit einem intensiven Austausch mit dem Datenbank-Administrator begonnen, da dessen System den Speicher benötigt hat. Bevor das Provisioning-Projekt umgesetzt werden konnte, musste sich Stevenson noch mit dem Storage-Team und mit dem System- und Netzwerk-Administrator zusammensetzen.
Der Datenbank-Administrator kennt die Leistungs- und Kapazitätsanforderungen, während der Systemadministrator sich vergewissern kann, dass die Hosts den frisch bereitgestellten Speicherplatz auch finden. Das Netzwerk-Team kümmert sich um die Zoneneinteilung, während das Storage-Team das eigentliche Aufrüsten der Speicherkapazität vornimmt.
Sogar innerhalb des Storage-Teams können verschiedene Gruppen in den Prozess involviert sein. „Die Techniker erweitern die Festplatten-Arrays. Die Operations-Gruppe regelt die Maskierung und das Mapping der LUNs”, erklärt Dan Weinstein, Senior-Berater des Marktforschungs- und Beratungsunternehmens GlassHouse Technologies.
„Das Erste, was Sie erledigen müssen, bevor Sie mit Storage Provisioning beginnen können, ist herauszufinden, was erforderlich ist”, sagt Dan Weinstein von GlassHouse. Das bedeutet, die Service-Level-Anforderungen der Anwendungen in Bezug auf Storage-Kapazität, Schutz, Performance und Ressourcen-Management zu definieren. Ohne diese Informationen können Administratoren keine Provisioning-Entscheidungen treffen, die in der Regel sofort abgefragt werden.
Die Anforderungen müssen dann in Storage-Bedingungen übersetzt werden: Welche Storage-Arrays und Platten, welche Storage-Ebene und welcher RAID-Level sind notwendig? „Sobald Sie diese Informationen zusammengestellt haben, können Sie passende physikalische Speicher auswählen, bevor Sie beginnen, sie logisch aufzuteilen”, sagt Weinstein.
Stevenson von InfoPros würde den Provisioning-Prozess mit einem Meeting beginnen, an dem der Storage-Administrator und der Datenbank-Manager teilnehmen. Mithilfe einer Tabellenkalkulation würden sie die Anwendungskapazität und den Wartungsaufwand in eine Liste möglicher LUNs und ihrer entsprechenden Ein/Ausgabe-Leistung übersetzen. „Das ist viel leichter für vorhandene Anwendungen zu realisieren, die mehr Speicherkapazitäten brauchen und deren Anforderungen man bereits kennt”, erklärt Stevenson. Bei einer neuen Anwendung könnte das Team nur eine möglichst gute Schätzung erstellen, die auf ähnlichen Anwendungen basiert. Die Informationen in der Tabelle werden dann zur Richtlinie, sobald mit dem Storage Provisioning begonnen wird.
Sie sollten auch „die Kriterien und den Prozess kennen, die für eine Aufstockung des Speichers ausschlaggebend waren und zu einer Freigabe führten”, mahnt Tim Arland, Principal Consultant beim unabhängigem Storage-Integrator Forsythe Solutions. Ohne konkrete Kriterien und einen ordentlichen Prozess endet Storage Provisioning schnell in einem Chaos, in dem LUNs hier und da verteilt werden, wo es scheinbare physikalische Kapazitäten gibt. Dabei wird dann vielfach keine Rücksicht auf die Leistungsmerkmale des Storage-Systems oder des Storage-Wartungsaufwands der Anwendungen genommen.
Administratoren müssen an zahlreichen Stellen im Prozess des Storage Provisioning Entscheidungen treffen. Diese betreffen Themen wie den spezifischen RAID-Level, die Größe der LUNs ebenso wie die Zoneneinteilung, das Maskieren, das Strippen und das Verketten der LUNs. Wenn zum Beispiel eine Anwendung zum Schutz der Daten eine Spiegelung erfordert, müssen Sie die doppelte Speicherkapazität beim Provisioning einkalkulieren, um die notwendigen Pfade einrichten und bereitstellen zu können.
Im Allgemeinen empfehlen Experten, die Kapazität der LUNs um mindestens 30 bis 50 Prozent höher anzusetzen, als die erwartete Größe. „Das ist keine vergeudete Kapazität”, erklärt Jerry Namery, Chief Technology Officer von Winchester Systems in Burlington. „Besonders wenn Sie den Speicher für Datenbankanwendungen einrichten, ermöglicht dies eine höhere Flexibilität bei der Verteilung, ohne gleich an Grenzen zu stoßen.”
Je nach Hersteller haben Sie mehr oder weniger Wahlmöglichkeiten. Als Beispiel kann man die LUN-Dimensionierung heranziehen, die ein wesentlicher Faktor für einen Storage-Administrator sind. Idealerweise wollen Administratoren die LUN aufgrund von Leistungsanforderungen, effizienter Kapazitätsausnützung oder Schutz dimensionieren. Um etwa mehr Leistung bereitzustellen, müssen Sie LUNs einrichten, um mehr Spindeln nutzen zu können.
Arland von Forsythe Solution empfiehlt zum Beispiel, für Datenbankanwendungen in einem Midrange-Array 100-GByte-LUNs zu verwenden. Aber er würde diese 100 GByte über eine komplette 16- bis 24-Disk-RAID-Gruppe strippen, die eine Vielzahl von Spindeln für eine optimale Leistung bereitstellen. „Für höhere Leistung sollten Sie kleinere Laufwerke und mehr Spindeln in Ihrer RAID-Gruppe verwenden”, schlägt er vor.
„Andererseits würde ich große LUNs – 200 GByte und mehr – für Anwendungen mit geringen Leistungsanforderungen und Archivierungsaufgaben mit weniger Spindeln reservieren”, fügt Arland hinzu. In diesem Fall könnte die RAID-Gruppe aus nur vier bis acht Laufwerken bestehen.
„Das Ziel einer optimalen Dimensionierung ist zweigeteilt: So muss man die richtige Menge an Speicher bereitstellen, ohne mit kleinen Fragmenten dazustehen und damit die Leistungsfähigkeit und den Betrieb einzuschränken”, argumentiert Namery von Winchester Systems. Das Kunststück dabei ist, kleinere LUNs zu verwenden, die Ihnen mehr Flexibilität bieten. Zerstückelte Speicherbereiche treten überraschenderweise oft auf, in der Regel dann, wenn jemand mit Storage Provisioning beginnt, ohne die Struktur vorher geplant und dokumentiert zu haben.
LUN-Dimensionierung unterscheidet sich auch von Hersteller zu Hersteller. Es hilft zu wissen, welches Array Sie verwenden möchten. Einige Enterprise-Storage-Systeme bieten weniger Wahlmöglichkeiten, die LUN-Größe einzustellen als Midrange-Arrays.
Die größten Unternehmens-Arrays, ursprünglich für den Einsatz in Mainframe-Umgebungen entwickelt, werden oft mit vielen kleinen LUNs vorkonfiguriert, etwa 8 bis 9 GByte groß. „Die High-End-Arrays wie die Symmetrix DMX von EMC wurden so entwickelt, dass sie optimal mit kleinen 8,4-Gbyte-LUNs arbeiten“, erläutert Weinstein von GlassHouse. „Das ist im Design und im Mikrocode des Arrays verankert. Der beste Ansatz ist dann, das ganze Array von Anfang an mit vielen kleinen LUNs zu konfigurieren.”
„Diese kleinen LUNs können zu größeren LUNs verkettet werden“, fügt Arland von Forsythe Solutions hinzu. „Dagegen bieten Hersteller von Midrange-Arrays oft Arrays an, die in große LUNs aufgeteilt sind, oft 200 GByte groß.
„Bei Midrange-Arrays ist es oft am besten, eine ganze Reihe (row) oder ein ganzes Regal (shelf) von Laufwerken auf einmal zu konfigurieren und die LUNs über mehrere Spindeln zu strippen“, erklärt Weinstein. Aber fühlen Sie sich nicht auf kleine LUNs beschränkt. Zum Schluss „hat Leistung weniger mit der Größe der LUNs zu tun, als mit der Anzahl der Platten, über die sie sich verteilen“, folgert er.
Sie müssen sich auch schon ziemlich früh zu Beginn der Planung Gedanken über die Replikation machen. „Wenn es um das Provisioning von Replikationen geht, haben Sie zwei Optionen – vieles hängt jedoch vom Hersteller ab”, erklärt Arland. Sie können die Replikation während des Erst-Provisionings definieren, wenn Sie Laufwerkspaare für diese Funktion bilden. Einige Midrange-Arrays bieten zur höheren Flexibilität die Möglichkeit, die Replikation zu einem späteren Zeitpunkt einzurichten. „Die beste Lösung wäre jedoch auf alle Fälle, die Replikation schon während der Anfangs-Provisionierung einzurichten”, fügt er hinzu.
Weinstein von GlassHouse empfiehlt, dass Snapshot und Replikation sogar noch früher entschieden werden müssen – bereits in der Planungsphase sollten diese Punkte integriert werden. „Es stehen nur begrenzte Ressourcen für interne Snapshots zur Verfügung, sodass Sie sich schon während der Entwurfsphase darüber Gedanken machen müssen”, führt er aus.
Zonen einzurichten und das Maskieren benötigen dagegen nicht viel Planung. Das Aufteilen in Zonen und das Maskieren kann vor oder nach dem Provisioning beziehungsweise parallel dazu erfolgen. Die einzige Entscheidung besteht darin, eine harte oder weiche Zoneneinteilung durchzuführen. Harte Zoneneinteilungen verwendet den physikalischen Port auf dem Switch. Weiche Zoneneinteilung basiert auf dem weltweiten Namen des Geräts, einer Zeichenkette mit 16 Zeichen. Der Trend heute ist, den Namen zu verwenden. Management-Tools und Hersteller von Switches bevorzugen eine weltweite Zoneneinteilung auf Namensebene.
Erst nachdem die Storage-Service-Anforderungen ermittelt sind, beginnen Profis, die physikalischen Arrays in logische Speicherstücke aufzuteilen. Dazu muss der Element-Manager gestartet werden, ein Low-Level-Tool des Storage-Array-Herstellers.
In der Vergangenheit wurde Provisioning ausschließlich über das Command Line Interface (CLI) durchgeführt. Wer es beherrschte, dem stellte das CLI schnell eine äußerst granulare Kontrolle über das System zur Verfügung. In den letzten Jahren bieten die Hersteller verstärkt GUI-Element-Manager an, die mit dem CLI konkurrieren. Tools von Drittanbietern sind ebenfalls aufgetaucht, konnten aber bislang noch nicht so stark Fuß fassen.
GUI-basierende Element-Manager sind einfacher zu bedienen. „Das ist noch Neuland für uns. Wir haben Anfang des Jahres ein neues Array installiert, also verwenden wir das GUI”, erklärt Anthony Bergen, Server Manager bei The North West Company, einem Distributor und Großhändler in Winnipeg. Das Unternehmen benutzt den Navisphere Element-Manager, der zusammen mit ihrem Dell/EMC-Array geliefert wurde.
Bergen stützte sich auf die Berater von Dell, um das Anfangs-Provisioning des neuen Arrays für The North West Company einzurichten. Die Berater konfigurierten das Storage-System in gestrippte Meta-LUNs, mit einer Größe von 300 GByte. Meta-LUNs werden durch Strippen über multiple Storage-Volumes erzeugt, um neue, größere Volumes zu ermöglichen. Im Falle der The North West Company wurden die Meta-LUNs aus 50-GBytes-LUNs gebildet. „Meta-LUNs erlauben es uns, unser Speichersystem leicht zu erweitern”, erläutert Bergen.
Meta-LUNs sind vergleichbar mit verketteten LUNs. In beiden Fällen werden multiple, kleinere LUNs zusammengefügt, um eine große zu erzeugen. Meta-LUNs werden jedoch über die Spindeln aller konstituierenden LUNs hinweg gestriped, wodurch die Leistung erheblich verbessert wird. Mit verketteten LUNs werden Daten auf jedes LUN sequenziell geschrieben, wobei das konstituierende LUN gefüllt wird, bevor man zum nächsten wechselt. Meta LUNs und verkettete LUNs sind besonders nützlich, wenn ein Unternehmen vorhandene Volumes im laufenden Betrieb erweitern muss.
Der letzte Provisionierungs-Schritt beinhaltet das Maskieren, um sicherzustellen, dass nur die richtigen Server die frisch provisionierten LUNs sehen. Systemadministratoren können dann den Volume-Manager auf den Servern benutzen, um die Speicherbereiche zu finden.
Software-Hersteller preisen automatisierte Provisioning-Tools an, die in der Regel als Teil eines größeren Resource-Management-Paketes geliefert werden. Aber viele Provisioning-Tools funktionieren nicht mit Produkten unterschiedlicher Hersteller.
Die größte Herausforderung, der die automatisierten Provisioning-Tools gegenüberstehen, ist die Vielfalt von Arrays, die jeweils auf der untersten, nativen Ebene angesprochen werden müssen.
Automatisiertes Provisioning ist, wie sich sehr schnell herausstellte, ganz und gar nicht automatisiert. „Die Werkzeuge verwenden im Grunde genommen Arbeitsabläufe, um Teile des manuellen Provisionierungs-Prozesses zu automatisieren. Einige Dinge fehlen dabei aber immer, wie Änderungsverwaltung, Freigaben oder die Serverseite”, sagt Robert Passmore, Vizepräsident Forschung des Marktforschungsunternehmens. Sie greifen auch nicht tief in die Storage-Struktur ein. „Die Tools laufen auf einer oberen Ebene, nachdem etwa die RAID-Sets schon erstellt worden sind”, erläutert er weiter. „Sie können die ganze Basisarbeit nicht leisten. Dafür benötigen Sie jeweils das Tool des Array-Herstellers. Aber irgendwann wird es auch dafür automatisierte Tools geben.”
Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 2005352)
