freshidea - Fotolia

Wie man Missmanagement von Speicherkapazitäten vermeidet

Verschwendung von Speicherkapazitäten ist weit verbreitet. Nur durch eine abgestimmte Planung verschiedener Maßnahmen lässt sich das Problem lösen.

Die Nachfrage nach immer größeren Speicherkapazitäten gehört heute zum alltäglichen IT-Leben und ist ein Fakt. Ebenso Fakt ist es, dass aufgrund von Designfehlern und Missmanagement jede Menge an Kapazität verschwendet wird.

Einige der Faktoren bei der Nachfrage an Kapazität – neben dem reinen Datenwachstum – werden von zahlreichen Studien belegt: Diese zeigen, dass bis zu 70 Prozent der Kapazität jedes unserer Flash- oder Disk-Drives dadurch verschwendet werden, indem eine atemberaubende Anzahl von Kopien der gleichen Datei gespeichert wird. Und dabei handelt es sich um Daten, auf die nie mehr zugegriffen wird, oder um Daten von Usern, die das Unternehmen längst verlassen haben.

Vom Design-Standpunkt aus betrachtet, entsteht Kapazitätsverschwendung, weil oft Strategien für Software-defined Storage (SDS) zum Einsatz kommen, die ein Minimum an drei Speicherknoten erfordern: Alle Daten werden dabei gegenseitig über sämtliche Knoten repliziert. Oder es werden bei SDS antiquierte File-Systeme verwendet, die Platz beanspruchen – sogar bei jenen, die keine Bits eines Objekts abspeichern. Außerdem verschwenden Anwender einfach Kapazitäten, wenn sie Speicherplatz in fehlerhafter Art zuweisen. So etwas passiert zum Beispiel bei der bekannten Praxis, einem Server-Administrator Speicherkapazität zuzuweisen und ihn dann selbst entscheiden zu lassen, sie für ein File-System und entsprechende Dateien zu verwenden. Der gleiche Fehler passiert, wenn der Administrator diesen Speicherplatz verschwinden lässt – ihn zum Beispiel für einen zukünftigen Notfall aufhebt oder – noch wahrscheinlicher – ihn einfach vergisst.

Speicherkapazität ist nicht nur ein User-Problem

Die Speicherindustrie hat seit Jahren zwei Dinge geliefert: reine Wunder an technologischen Erfindungen und Monumente der Habgier in der Form von Produkten für die Storage-Infrastruktur. Seit den 80er Jahren des letzten Jahrhunderts bis vor kurzem hat sich die Plattenkapazität etwa alle 18 Monate verdoppelt, während die Kosten der Festplatten etwa alle 12 Monate um die Hälfte gesunken sind – ein technologisches Wunder mit ökonomischen Vorteilen. Aber der Preis eines Platten-Arrays – einer Ansammlung von Commodity-Speicherkomponenten in einem Commodity-Rack, das so etwas wie ein Server-Motherboard als Controller benutzt – ist in Wahrheit um satte 120 Prozent pro Jahr nach oben geschnellt.

Ein guter Anteil dieser Kosten geht zurück auf Value-added Software, die die Hersteller ihren proprietären Speicher-Arrays hinzugefügt haben, um sich auf dem Markt hervorzuheben und Kunden an ihre Marke anzubinden. SDS kann zum Teil als der Versuch beschrieben werden, Arrays in ihren Commodity-Zustand zurückzuversetzen, indem die ganze Value-added Software in einen eigenen Layer für Software-Services, der sich auf einem Server befindet, umgewandelt wird. Hersteller bezeichnen diese Entwicklung als „revolutionär“, aber ich sehe sie als eine Rückkehr zu etwas ähnlichem wie ein Mainframe-Management für Speicher, das einen Haufen von Direct-Attached Speichergeräten kontrolliert.

Es bleibt offen, ob diese Strategie wirklich die Speicherkosten senken wird, besonders wenn man die SDS-Ansätze der führenden Anbieter von Server-Hypervisoren berücksichtigt, die von der Architektur her genauso restriktiv und geschlossen sind wie die SAN- und NAS-Systeme, die sie angeblich ersetzen wollten. Wegen der Art und Weise, wie Storage verpackt und verkauft wird, sind die Kapitalkosten (Capex) enorm. Die Speicherkosten machen heute 33 bis 70 Prozent aller Ausgaben für IT-Hardware aus, wobei wir selbst dann von viel Geld sprechen, wenn wir sie aufteilen für die reine Hardware selbst, für Garantie- und Wartungsverträge sowie für die Software-Lizenzen und wenn wir sie auf eine bestimmte Anzahl von Jahren für die Service-Leistungen umlegen. Die Kosten für Speicher bleiben auf jeden Fall hoch.

Die wirklichen „Cost of Ownership“ herausfinden

Aber die Capex- oder Akquisitionskosten sind nur ein Teil der Speichergleichung. Um die wirklichen (Gesamt-)Kosten oder die „Cost of Ownership“ zu ermitteln, muss man auch einen Blick auf die Betriebsausgaben (Opex = Operating Expense) werfen – eine Zahl, die in den meisten Unternehmen nicht einmal annährend verfügbar ist. Laut Gartner sind die jährlichen Betriebsausgaben (Opex) für Speicher in etwa vier- bis fünfmal so hoch wie die auf ein Jahr umgelegten Kapitalkosten (Capex).

Die Betriebsausgaben umfassen Backup und Recovery, geplantes Herunterfahren der Systeme, Management und Verwaltung sowie Gebäudeausgaben (Platz im Rechenzentrum, Energie und Kühlung). Diese Kosten verschwinden gewöhnlich in irgendwelchen Unterlagen, anstatt nachhaltige Handlungsanweisungen hervorzurufen. Weil es nicht immer gelingt, die Speicherinfrastruktur effizient zu verwalten, wissen wir, dass echte Opex-Kosten gut zu Buche schlagen können.

Warum gelingt es uns nicht, Storage gut zu verwalten? Wir tendieren dazu, meistens Tier-1-Speicher zu kaufen, der aus geringen Kapazitäten und hoher Performance zusammengesetzt ist, um neuen Applikationen nach Möglichkeit einen perfekten Start noch am Tag ihrer Installation zu ermöglichen – egal, ob es sich um geschäftskritische Anwendungen handelt oder nicht. Aber ich behaupte, das ist von Anfang an falsch.

Storage gibt es traditionell aus guten Gründen in verschiedenen Geschmacksrichtungen. Einige Varianten sind daraufhin optimiert, schnell wachsende Daten mit ausreichender Geschwindigkeit zu speichern, um den Performance-Anforderungen von Transaktionssystemen zu entsprechen. Andere Ausführungen sind entwickelt worden, um große Datenvolumina zu speichern, die nur routinemäßig oder gelegentlich aufgefrischt oder geändert werden. Und weitere Systeme sind für langfristigen Massenspeicher entwickelt worden, auf den nur gelegentlich und mit extrem niedrigen Änderungsraten zugegriffen wird. In gut verwalteten Umgebungen werden die Daten von Tier zu Tier bewegt, entsprechend einer automatisierten Policy auf Basis von hierarchischem Speichermanagement oder von Archivierungs-Software. Das ist so ungefähr der einzige Weg, auf dem wir die Speicherkosten eindämmen können.

Damit Tiering wirklich funktioniert, braucht man leider eine integrierte Infrastruktur oder zumindest ein gemeinsames Management-Schema. In einigen Fällen liegt es absichtsvoll an den Herstellern, wenn ihre Produkte nicht mit denen eines Konkurrenten zusammenarbeiten. Value-added Software – also Programme, die mit neuen Features vollgepackt werden – kann dazu benutzt werden, gemeinsame Management-Anstrengungen zu unterlaufen, und in einigen Arrays sind vorsätzlich proprietäre File-Systeme untergebracht worden, um den Austausch von Daten zwischen heterogenen Plattformen auszuschließen.

Und das zuletzt genannte Problem tritt nicht nur bei klassischen proprietären Arrays auf. Anbieter von Hypervisoren implementieren ihre eigenen SDS-Stacks auf eine Art und Weise, die es verhindert, dass ihre Storage-Ressourcen mit anderen Daten-Workloads geteilt werden – schließen also virtualisierte Daten aus, die das SDS-Modell eines konkurrierenden Hypervisors verwenden.

Wenn Sie sich fragen, wie „Ihr“ Storage zu „ihrem“ Storage wurde, dann sind Sie nicht allein. Diese proprietären Barrieren verringern unsere Fähigkeit, das Verschieben von Daten über mehrere Speicher-Tiers hinweg zu automatisieren. Diese Situation ist ein Nebenprodukt der Art und Weise, in der sich SDS Hyper-Cluster vom Supercomputing mit seiner hohen Performance borgt – ein Gebiet, von dem die SDS-Anbieter viele ihrer Topologiekonzepte zu beziehen scheinen. Die Stoßrichtung vieler SDS-Architekturen besteht darin, eine flache Speicherinfrastruktur aufzubauen, die hinter jedem virtuellen Server in identischer Weise konfiguriert und installiert wird. Diese Infrastruktur wird aus einzelnen Bausteinen gebildet – einer hyper-converged Infrastruktur aus Server-Knoten, Storage und SDS-Middleware, die man aus einem Vorratslager zusammensetzen und schnell installieren kann, um den Ansprüchen der Business-Manager und ihrer wechselnden Geschäftsprozesse zu genügen. Sie brauchen weitere 50 ERP-Arbeitsplätze? Dazu muss man nur drei weitere Bausteine für entsprechende Compute-, Netzwerk- und Speicherkapazitäten ausrollen.

Dies könnte sich wie der ideale Pfad zu echter Mobilität anhören, wenn da nicht der kleine Unterschied wäre, dass diese Art von Infrastruktur von Natur aus flach ist. Es gibt keinen Storage-Layer, der teuer ist und über wenig Kapazität verfügt, für die ganz wichtigen Daten. Und es gibt keinen nicht ganz so teuren Layer mit großer Kapazität für aktive, aber nicht so häufig gebrauchte Daten, und auch keinen billigen Layer mit noch größerer Kapazität für kaum gebrauchte und archivierte Daten. Der Wegfall eines Storage-Layers und das Management von Daten über alle Layer hinweg stellen darüber hinaus gewaltige Kostentreiber dar.

Überlegungen rund um SDS und Speicherkapazitäten

Mit Software-defined Storage (SDS) kann man Speicher-Services auf einem Software-Layer in einem Server konsolidieren. Dies ist eine gute Sache, weil es sie von den Array-Controllern abzieht, wo ihre Funktionalität begrenzt ist und ihre Vorteile nur für einen Knoten gelten. Es macht wenig Sinn, Deduplizierung oder Thin Provisioning auf eine Plattengruppe zu beschränken, anstatt sie als Dienstleistung über alle Speicherplattformen auszudehnen.

Es stimmt aber nicht, dass die Konsolidierung dieser Value-added Software-Funktionen in einer Speicher-Software-Schicht auf einem Server das Allheilmittel für Speicher-Management ist. Das ist es nicht.

Zusätzlich zu den Storage-Services bringt Speicher-Management die Verwaltung der Storage-Ressourcen mit sich: der physischen Infrastruktur, ihrem jeweiligen Betriebsstatus und ihrer Zuweisung und Freigabe für Workloads. Sich auf das Management von Replikation zu beschränken hilft wenig, wenn die Spiegelung nicht funktioniert, weil eine Festplatte oder ein Flash-Laufwerk auf einem Speicherknoten ausgefallen ist und es niemand bemerkt hat. Außerdem trägt es wenig zur gewünschten Mobilität bei, wenn man die Speicherkomponenten nicht beliebig miteinander mischen und anpassen kann, um sämtliche Applikations-Anforderungen zu erfüllen.

Der einzige Grund, warum das Management von Speicherressourcen nicht Teil des von Hypervisor-Anbietern bevorzugten SDS-Layers ist, besteht wohl in den Beziehungen, die einige von ihnen mit den Herstellern der Speicherhardware haben. Wenn man die Speicherinfrastruktur virtualisiert und dabei nicht nur von den Value-added Software-Services, sondern auch vom Kapazitäts-Management abstrahiert, können diese Speicherressourcen genauso „Software-defined“ werden wie die Speicherservices – und lassen sich so viel leichter als bisher zuweisen, zurücknehmen und bestimmten Layern zuordnen.

Speicher-Virtualisierung ist nichts Neues. DataCore Software bietet diese Technologie seit mehr als einem Jahrzehnt an, und IBMs SAN Volume Controller unternimmt einen Vorstoß in dieses Territorium. Aber die wichtigen Hypervisor-Player von heute scheinen nicht daran interessiert zu sein, eine Speicherressource so verfügbar zu machen, dass sie zusammen mit SDS eingesetzt werden kann, um Daten zu den jeweils geeigneten Speicher- und Servicearten zuzuweisen. So ließen sich sowohl Datenanwendung als auch Speicherkosten optimieren.

Wer hofft, SDS werde das Monster der Speicherkosten zähmen, muss einsehen, dass Software-defined Storage, hyper-converged Infrastruktur und die altmodischen proprietären Storage-Arrays und -Netze keine Allheilmittel sind. Man sollte die Speicherkapazitäten virtualisieren und gleichzeitig die Speicher-Services zentralisieren. Nur so kann man seine Tiering-Strategie aufrechterhalten und nur so lassen sich Speicherkapazität und -Services effizient für den kompletten Datenbestand einsetzen.

Über den Autor:
Jon William Toigo blickt auf 30 Jahre Erfahrung im IT-Bereich zurück. Er ist CEO und Managing Principal von Toigo Partners International sowie Vorsitzender des Data Management Institute.

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

Artikel wurde zuletzt im November 2015 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Data-Center-Storage

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