Vom RAM-Baustein zum All-Flash-Array Der

Storage
h Heise
Sonderbeilage von Heise Medien
Vom RAM-Baustein zum All-Flash-Array
Welche Lösungen der Markt hergibt
Der unsichtbare Hypervisor
Was komplexe Architekturen einfacher macht
Die Speicherinfrastruktur
von morgen ist softwaredefiniert
Wann sich Software-defined Storage lohnt
Jede Kopie kostet
Wo Copy Data Virtualization für Klarheit sorgt
Snapshots, Backup, Replikate –
was, wann, wie?
Wann virtualiserte Systeme richtig gesichert sind
Kapazitätsplanung für Serviceprovider
Wie All-Flash im Scale-out-Design funktioniert
Editorial
Was Flash verspricht, muss der Hypervisor halten
Die Rechenzentren beginnen zu rechnen: Wie viel Effizienz gewinnen
wir – wie viel Energie sparen wir mit Flash Storage? Denn so
verlockend die extrem hohe Performance nicht flüchtiger Speicher
auch ist – klar ist ebenso, dass die extrem hohe Performance
momentan noch ihren Preis hat. Dennoch boomt der Markt:
All-Flash-Arrays werden laut IDC noch 2016 einen Weltumsatz von
1,6 Milliarden US$ erreichen – und das bei sinkenden Preisen. Wohin
die Entwicklung geht, welche Lösungen es gibt und wo genau die
Vor- und Nachteile liegen, erläutert Doris Piepenbrink in ihrem
Grundlagenbeitrag ab Seite 12. Mara McMahon widmet sich dann
konkret dem All-Flash-Bedarf von Serviceprovidern und vergleicht
Scale-up- mit Scale-out-Designs (Seite 18).
Während die Anschaffungskosten für Flash weiter fallen, spitzen die
Speicherverantwortlichen den Bleistift und setzen ein sauberes
Storage Management auf, das häufig benötigte Daten auf flotte
Medien packt und selten gefragte Informationen zum Beispiel mit
preisgünstigen Bändern archiviert. So weit, so gut. Aber leider schießt
ausgerechnet ein paralleles Effizienzprojekt quer: der Trend zur
Virtualisierung. Damit wachsen nämlich die Dubletten nur so auf der
flachen Hand, wenn die Admins nicht aufpassen.
Das wiederum, warnt Thorsten Eckert, treibt die Speicherkosten
wieder in die Höhe und ist obendrein ein gefährlicher Risikofaktor.
Wie man in dieser Situation Compliance-sicher bleibt und eine
saubere Zugriffskontrolle gewährleistet, erklärt sein Beitrag ab Seite 6.
Dazu setzt Alexander Thoma auseinander, was die jüngste Generation
von Hypervisoren in (fast) virtualisierten Rechenwelten dazu
beitragen kann, dass RZ-Architektur kontrollierbar bleibt – auch dann,
wenn die Speicherlösung selbst gar nicht für den VM-Betrieb
ausgelegt ist (Seite 14). Einen wichtigen Hinweis gibt außerdem
Simon Köhl: „Snapshots sind keine Backups!“, ruft er. Missbraucht man
sie zur regulären VM-Datensicherung bläht das den Speicherbedarf
gigantisch auf. Sein Beitrag auf Seite 16 erklärt genau die praktischen
Unterschiede zwischen Snapshots, Backups und Replikaten.
Die radikale Lösung beim Speichermanagement besteht in
der vollständigen Virtualisierung. Das Stichwort dazu heißt
Software-defined Storage. Die Argumente, die Michael Hohl auf den
Tisch legt (Seite 10), sind nicht uncharmant: Praktische Lösungen
sind mittlerweile so weit ausgereift, dass eine Migration selbst von
400-TByte-Beständen im Live-Betrieb machbar ist. Ein solches System
ist dann umstandslos und nahezu beliebig skalierbar, lässt sich
sparsam zentral verwalten und arbeitet unabhängig von bestimmten
Hardware-Herstellern. Ob mit oder ohne Flash.
Thomas Jannot
STORAGE
3
Inhalt, Impressum, Inserentenverzeichnis
JEDE KOPIE KOSTET
DER UNSICHTBARE HYPERVISOR
Copy Data Virtualization bekommt den
Dubletten-Wildwuchs in den Griff
Virtualisierung schafft neue Komplexität –
und liefert die Lösung dazu.
Seite 6
Seite 14
DIE SPEICHERINFRASTRUKTUR VON
MORGEN IST SOFTWAREDEFINIERT
SNAPSHOTS, BACKUP, REPLIKATE –
WAS, WANN, WIE?
Software-defined Storage ist mittlerweile
einfach und schnell aufzusetzen.
Disaster Recovery funktioniert erst mit einer
sauberen Datensicherung.
Seite 10
Seite 16
VOM RAM-BAUSTEIN
ZUM ALL-FLASH-ARRAY
KAPAZITÄTSPLANUNG
FÜR SERVICEPROVIDER
Moderne Architekturen platzieren
die Steuerung direkt am Hypervisor.
Bei All-Flash-Speicherlösungen sind
Scale-out-Designs besser geeignet.
Seite 12
Seite 18
Impressum
Storage
Redaktion
Verlag
just 4 business GmbH
Kranzhornstr. 4b
83043 Bad Aibling
Telefon: 0 80 61/348 111 00
Telefax: 0 80 61/348 111 09
E-Mail: [email protected]
Heise Medien GmbH & Co. KG
Postfach 61 04 07, 30604 Hannover
Karl-Wiechert-Allee 10, 30625 Hannover
Telefon: 05 11/53 52-0
Telefax: 05 11/53 52-129
Internet: www.heise.de
Leserbriefe und Fragen zur Beilage:
[email protected]
Verantwortliche Redakteure: Thomas Jannot (V. i. S. d. P.),
Ralph Novak; Florian Eichberger (Lektorat)
Herausgeber: Christian Heise, Ansgar Heise,
Christian Persson
Autoren dieser Ausgabe: Thorsten Eckert, Michael Hohl,
Simon Köhl, Mara McMahon, Doris Piepenbrink, Alexander
Thoma
Geschäftsführer: Ansgar Heise, Dr. Alfons Schräder
DTP-Produktion: Wolfgang Otto (Ltg.), Jörg Gottschalk
Anzeigen: Simon Tiebel (-890)
(verantwortlich für den Anzeigenteil)
Titelbild: karelnoppe, Fotolia
Bildmaterial: Fotolia.com
Mitglied der Geschäftsleitung: Beate Gerold, Jörg Mühle
Verlagsleiter: Dr. Alfons Schräder
Druck: Dierichs Druck + Media GmbH & Co. KG,
Frankfurter Straße 168, 34121 Kassel
Sonderbeilage von Heise Medien
Eine Haftung für die Richtigkeit der Veröffentlichungen kann
trotz sorgfältiger Prüfung durch die Redaktion vom Herausgeber nicht übernommen werden. Kein Teil dieser Publikation
darf ohne ausdrückliche schriftliche Genehmigung des Verlags
in irgendeiner Form reproduziert oder unter Verwendung
elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden. Die Nutzung der Programme, Schaltpläne und
gedruckten Schaltungen ist nur zum Zweck der Fortbildung
und zum persönlichen Gebrauch des Lesers gestattet.
Für unverlangt eingesandte Manuskripte kann keine Haftung
übernommen werden. Mit Übergabe der Manuskripte und
Bilder an die Redaktion erteilt der Verfasser dem Verlag das
Exklusivrecht zur Veröffentlichung. Honorierte Arbeiten gehen
in das Verfügungsrecht des Verlages über. Sämtliche Veröffentlichungen erfolgen ohne Berücksichtigung eines
eventuellen Patentschutzes.
Warennamen werden ohne Gewährleistung einer freien
Verwendung benutzt.
Printed in Germany. Alle Rechte vorbehalten.
Gedruckt auf chlorfreiem Papier.
© Copyright 2016 by Heise Medien GmbH & Co. KG
Inserentenverzeichnis
4
DataCore Software GmbH, Unterföhring................................................................................ 17
Red Hat GmbH, Grasbrunn........................................................................................................... 11
ico innnovative Computer GmbH, Diez................................................................................... 13
SAMSUNG Electronics GmbH, Schwalbach................................................................... 8, 9, 20
STORAGE
Bild: sheelamohanachandran – Fotolia.com
COPY DATA MANAGEMENT | Virtualisierung
Thorsten Eckert, Sales Director DACH bei Actifio
JEDE KOPIE KOSTET
Angesichts des rasanten Wachstums von Produktionsdaten wird der Balanceakt
zwischen einfachem Zugriff und nachweisbarer Datensicherheit immer
schwieriger. Copy Data Virtualization kann Wildwuchs verhindern, die StorageKosten senken und eine effiziente Zugriffskontrolle ermöglichen.
B
emüht, absolute Datensicherheit zu gewährleisten, erstellen IT-Abteilungen
zahlreiche Kopien strukturierter und unstrukturierter Daten. Das geschieht durch Snapshots, Spiegelung und verschiedene Replikationsmethoden (lokal und remote) sowie als
Teil der Backup-und-Recovery-Prozesse. Jede
dieser Techniken hilft zwar den Unternehmen, verschiedene Quellen von möglichem
Datenverlust zu adressieren. Doch die herkömmliche Datensicherung in Kombination
mit separaten Datenkopiesilos für typische
Einsatzzwecke wie Analyse, Backup, Entwicklung, Tests etc. birgt erhebliche Risiken. Ein
Ergebnis ist nämlich die ungewollte und unkontrollierte Verbreitung von inoffiziellen,
oft mehrfach redundanten Kopien sensibler
6
STORAGE
Daten. Und diese Schatten-IT ist schwer zu
kontrollieren, geschweige denn zu schützen.
Mehr Speicherorte,
mehr Dubletten
Laut der IDC-Studie „Common Gaps in Data
Control“ (10/2015) hält ein durchschnittliches
Unternehmen 375 Kopien einzelner Datensätze
an verschiedenen Speicherorten vor – und jede
dieser Kopien enthält sensible Informationen.
Dadurch vergrößert sich die Angriffsfläche für
Cybergefahren und bösartige Datenzugriffe.
Ebenso erhöht sich das Risiko von Datenlecks,
etwa weil Mitarbeiter – egal ob vorsätzlich
oder unbeabsichtigt – auf sensible Daten
zugreifen oder diese in Umlauf bringen.
Angesichts dieser Schwachstellen der traditionellen Datenverwaltung erscheint es
dringend geboten, dass Unternehmen formalisierte Verfahren und Best Practices anwenden, um das Risiko zu reduzieren. Sicherheitsmaßnahmen wie Verschlüsselung und
Authentifizierung mit zentraler Zugriffsverwaltung und Sicherheitsprüfungen sollten
durch Datenkontrolle bzw. -überwachung
(Data Control) ergänzt werden. Dabei haben
Unternehmen ihre Daten mittlerweile vielfach verteilt, z.B. auf Private und Public
Clouds, via Backups auf Band oder per Backup und Disaster Recovery as a Service. Die
Komplexität der Kombination verschiedener
Speicherorte ist inzwischen zu groß, als dass
IT-Administratoren den innerhalb und außerhalb des Unternehmens verteilten Datenbestand lückenlos verwalten könnten.
Das traditionelle Konglomerat aus Datenbanken und Standorten sowie Richtlinien
und Verfahren für die Zugriffskontrolle
macht die Datenverwaltung zu einer komplexen Matrix mit Dutzenden von Möglichkeiten. So erweist es sich früher oder später
als unpraktisch, wenn nicht gar unmöglich,
den Überblick zu behalten. Bei Unternehmen, die sich auf manuelle Prozesse für die
Datenkontrolle verlassen, ist es unwahrscheinlich, dass sie diese auf Best-PracticeNiveau umsetzen können, da moderne ITUmgebungen und Anforderungen einfach
zu dynamisch sind. Unternehmen riskieren
bei Datenpannen egal welcher Art regulatorische Sanktionen und nicht zuletzt ihren
guten Ruf. Um Datenkontrolle nach BestPractice-Prinzipien konsequent umzusetzen,
sollten Unternehmen deshalb besser auf
automatisierte Methoden zurückgreifen.
Hausgemachte Probleme
Hinzu kommt, dass Unternehmen und einzelne Nutzer, die mit der Reaktionsfähigkeit
ihrer IT unzufrieden sind, zur Ausbildung
einer Schatten-IT neigen und inoffizielle Datenkopien anlegen. Doch jede neue physische Kopie erhöht die Angriffsfläche. Dieses
Problem besteht bei der überwiegenden
Mehrheit der Unternehmen, denn trotz häufiger Berichte über spektakuläre Sicherheitslücken und Datenpannen bleibt ein sichtbarer
Lerneffekt offenbar aus.
Die IDC-Umfrage bestätigt diesen Befund:
So scheitern zwei Drittel der Unternehmen
und Institutionen daran, Best-Practice-Standards der Datenkontrolle gerecht zu werden,
und nur wenige agieren konsistent über das
gesamte Spektrum ihrer Datensicherheitspolitik hinweg. Die Ergebnisse der IDC-Studie
zeigen, dass Unternehmen im Durchschnitt
13 Kopien einzelner Datenablagen (Repositories) vorhalten, die allesamt sensible Daten
enthalten können. 13 % der befragten Unternehmen hatten sogar mehr als 15 Kopien
solcher Datenablagen, und 77 % nehmen
COPY DATA MANAGEMENT | Virtualisierung
keine Maskierung ihrer sensiblen Daten während der Test- und Entwicklungsphase vor,
was die Gefahr von Pannen zusätzlich erhöht.
Unternehmen und öffentliche Einrichtungen benötigen daher Lösungen, um das
Copy Data Management zu automatisieren
und sowohl das Risiko als auch die Kosten zu
reduzieren. Kopien sind für IT-Abteilungen
unumgänglich, um den Geschäftsbetrieb zu
unterstützen und potenziellem Datenverlust
vorzubeugen. Sie werden jedoch zum Problem, wenn ihre Menge ausufert. Die Analysten von IDC schätzen, dass Datenkopien die
Unternehmen bis zum Jahr 2018 weltweit
50,63 Mrd. US$ kosten werden. Aktuell nehmen Datenkopien bis zu 60 % des Budgets
für IT-Storage-Hardware und -Infrastruktur in
Anspruch.
Zusätzlich sind Dubletten ein unnötiges
Risiko. Wenn Kopien angelegt werden, müssen sie nicht nur die Sicherheitseinstellungen
der Primärdaten übernehmen, sondern auch
auf sensible Informationen überprüft werden. Während der Test/Dev-Prozesse ziehen
es IT-Abteilungen vor, reale Daten zu verwenden. Allerdings sind die Entwickler nur
selten berechtigt, sensible Informationen
einzusehen. Um dies zu vermeiden, sorgt
Data-Scrubbing dafür, dass sensible Daten
entweder durcheinandergewürfelt oder so
maskiert werden, dass sie nicht sichtbar sind.
Datenverwaltung, sondern löst auch die Herausforderungen eines flexiblen, aber kontrollierten Zugriffs auf Datenkopien. Unternehmen können damit Daten direkt von Produktionsanwendungen erfassen und eine
einzige „goldene“ Masterkopie in einer sicheren Umgebung verwalten. Indem virtuelle
Kopien der Daten zur Verfügung stehen, sind
sowohl die einfache Zugänglichkeit als auch
eine optimale Kontrolle über die Daten gewährleistet.
Die Virtualisierung von Datenkopien stellt
ein zentrales System zur Verfügung, um stets
die Kontrolle über Sekundärdaten zu behalten und unterstützt Unternehmen bei der
Verwaltung und Überwachung ihrer Daten
durch
–ˇdie Absicherung vor geschäftskritischen
Risiken,
–ˇeine zentrale Steuerung sowie sichere und
stabile Operationen,
–ˇeinen regelkonformen schnellen Datenzugriff,
–ˇPrüfbarkeit und intelligente Bedrohungswarnungen,
–ˇdie Maskierung sensibler Daten,
–ˇSpeichereinsparungen dank globaler Deduplizierung der Masterkopie und virtueller
Datenkopien sowie
–ˇdie Vermeidung von Geschäftsunterbrechung durch unmittelbare Wiederherstellungsoptionen.
Copy Data Virtualization
Best Practices
für die Datenhaltung
Die meisten Unternehmen haben keine Ahnung, wie viele Kopien eines bestimmten
Datensatzes in ihrer Infrastruktur oder in der
Cloud in Umlauf sind. Doch wer nicht weiß,
wie viele Kopien existieren und wo sie sich
befinden, kann auch nicht sagen, wer darauf
Zugriff hat. Eine Virtualisierung der Datenkopien (Copy Data Virtualization) hilft Unternehmen dabei, typische Schwachstellen bei
der Überwachung geschäftskritischer Daten
zu identifizieren und zu beseitigen. Insbesondere für Prozesse bei der Datensicherung
und Anwendungsentwicklung entsprechend
dem DevOps-Ansatz bietet diese Technologie entscheidende Vorteile.
Die Verwendung einer zentralen CopyData-Management-Plattform zur Virtualisierung von Datenkopien verhindert vor allem
die unkontrollierte Verbreitung und Verfügbarkeit von physischen Datenkopien. Dies
gilt sowohl für Daten im Ruhezustand als
auch für Daten in Bewegung, etwa zwischen
Produktions- und Nichtproduktionsumgebungen, verschiedenen Hardware-Generationen oder zwischen Rechenzentren und
der Cloud-Infrastruktur. Am wichtigsten ist
dabei, dass die Virtualisierung die Anzahl der
Ziele reduziert, die schädlichen Aktivitäten
ausgesetzt sein könnten.
Doch die Copy-Data-Virtualisierung bietet
nicht nur einen ganzheitlichen Ansatz für die
IDC hat einige Best-Practice-Richtlinien zusammengestellt, die zeigen, wie sich die
Menge an Datenkopien und der Zugriff darauf im Rahmen traditioneller Datenverwaltung in den Griff bekommen lassen: Unternehmen müssen erstens verstehen und
quantifizieren, welche Kopien wie oft und
wozu erstellt werden. Datenkopien vorzuhalten ist in Ordnung und ein notwendiges Vorgehen für die Aufrechterhaltung geschäftskritischer Abläufe. Allerdings sollten Kopien
bewusst und nur im Rahmen der Geschäftsanforderungen erstellt werden. Ein Unternehmen sollte also nur so viele Kopien vorhalten, wie es für den Geschäftsbetrieb
braucht, und nicht mehr.
Daten sollten zweitens standardmäßig
verschlüsselt werden, im Ruhezustand und
ebenso, wenn sie in Umlauf sind. Die Verschlüsselung erfordert zwar Verarbeitungsaufwand, was aber ein kleiner Preis ist im
Vergleich mit den Kosten, die entstehen können, wenn sensible Daten ungeschützt bleiben. Da die Hardware-Leistung stetig zunimmt, sinken im Lauf der Zeit auch die Kosten für die Verschlüsselung.
Ein Scrubbing von Datenkopien, die sensible Informationen enthalten, sollte regelmäßig erfolgen. Dabei müssen die Nutzer
der Daten begründen, warum für bestimmte
Daten kein Scrubbing erforderlich ist, nicht
umgekehrt.
Ferner sollten Datensicherheitsrichtlinien
automatisch und systematisch bei der Repository-Erstellung angewandt werden. Ad-hocoder Von-Fall-zu-Fall-Regelungen sind zwar
ein Weg, den Datenzugriff zu optimieren, aber
solche Praktiken führen zu Sicherheitslücken,
beispielsweise durch einen versehentlichen
Verlust der Kontrolle über die Daten. Darauf
zu warten, bis Zugriffsrichtlinien in bestimmten Phasen angewandt werden, etwa während der Anwendungsbereitstellung oder in
der Test- und Entwicklungsphase, macht die
Daten zwischenzeitlich anfällig.
Nicht zuletzt sollten alle Daten auf Band
ebenfalls verschlüsselt werden, denn auch
sie können nach außen gelangen. Wenn ein
Band, das eigentlich im Rechenzentrum
bleiben sollte, unerwartet aus dem sicheren
Bereich verschwindet, ist es zu spät, um die
Informationen zu verschlüsseln.
Alle IT-Abteilungen sind gut damit beraten, diese Best Practices umzusetzen. Dies ist
zwar theoretisch auch ohne einen automatisierten Ansatz möglich, aber der Aufwand ist
in der Praxis viel zu groß. Es wäre schwierig,
die Ressourcen und das Investment für diese
Vorgehensweise über längere Zeit aufrechtzuerhalten. Dagegen macht es eine automatisierte und zentrale Datenverwaltung auf
einer Copy-Data-Management-Plattform sehr
viel leichter, konsistente Prozesse langfristig
konsequent umzusetzen.
Speicherkosten und Compliance
IT-Manager müssen also zwei entscheidende
Aspekte berücksichtigen: das generelle Problem des Kopierens von Daten und die nicht
minder große Herausforderung eines einfachen und dennoch sicheren Zugriffs auf
Datenkopien. Die Verwaltung physischer
Datenkopien ist nicht nur risikobehaftet,
sondern auch teuer. Zwar ist es nicht möglich,
auf Datenkopien vollständig zu verzichten,
aber jede inkrementelle Reduzierung bedeutet bares Geld für das IT-Budget.
Die Storage-Kosten sind die eine Sache,
die Überwachung des Zugriffs stellt jedoch
eine noch größere Herausforderung dar. Die
rechtlichen und regulatorischen Vorgaben
werden immer strenger, nicht zuletzt aufgrund des jüngsten Engagements der EU.
Die Offenlegung von vertraulichen Daten,
selbst unbeabsichtigt oder in gutartiger Absicht, kann zu empfindlichen Sanktionen und
Geldstrafen führen. Da die IT-Abteilungen im
Durchschnitt mehrere Hundert Datenkopien
vorhalten, stellt sich nicht mehr die Frage,
ob, sondern wann und wie sinnvolle Maßnahmen eingeleitet werden. Es steht also
einiges auf dem Spiel. Mithilfe automatisierter
Systeme können IT-Manager aber sowohl
die Storage-Kosten als auch die Schatten-IT
in den Griff bekommen.
STORAGE
7
SOFTWARE-DEFINED STORAGE | Infrastruktur
Michael Hohl, Head of PreSales & Consulting transtec AG, Reutlingen
DIE SPEICHERINFRASTRUKTUR VON
MORGEN IST SOFTWAREDEFINIERT
In vielen Unternehmen sind die Speicherinfrastrukturen in die Jahre gekommen und oft
nur mit hohem Aufwand zu managen. Das muss nicht sein. Software-defined Storage ist
ein Lösungsansatz, der sich schnell umsetzen lässt und die Systeme zukunftssicher macht –
sogar unter Verwendung der vorhandenen Hardware.
ypisch für viele IT-Landschaften bei Unternehmen jeder
Größe sind heterogene Speicherinfrastrukturen mit verteilten
Systemen, dezentralen Verwaltungstools und hohen Betriebsund Administrationskosten. Nach
der Konsolidierung und Virtualisierung der Server rücken heute
die Speichersysteme in den
Fokus, denn die dort aufbewahrten Daten sind ein wichtiger Teil
des Unternehmenskapitals; sie
sind unabdingbar für reibungslos
ablaufende kritische Geschäftsprozesse. Sind Daten nicht verfügbar, stockt die Fertigung, das
Unternehmen kann Liefertermine
nicht einhalten und erleidet Umsatzeinbußen.
Im Hinblick auf die Konsolidierung von Speicherlandschaften
sind heute vor allem zwei Konzepte an Bedeutung: Virtualisierungstechnologien und SDS-Ansätze (Software-defined Storage).
Bislang gibt es allerdings keine
einheitliche SDS-Definition, manche Anbieter setzen den Begriff
sogar mit der reinen Storage-Virtualisierung gleich. Der gemeinsame Nenner aller SDS-Ansätze
ist aber, dass es dabei um eine
strikte Trennung von Speichersoftware und Speicherhardware
geht und dass im Gegensatz zu
traditionellen Speichersystemen
die Storage-Services im Vordergrund stehen.
Multifunktionalität für
alle Anforderungen
Die heutigen SDS-Lösungen sind
in der Regel ausgereift und können ohne größere Einschränkungen im Produktivbetrieb eingesetzt werden. Das liegt auch
daran, dass solche Lösungen bei
10
STORAGE
großen Herstellern bereits seit
Längerem zum Portfolio gehören – schon vor dem allgemeinen Hype um „Software-defined
Everything“.
Hinsichtlich der Anwendungsszenarien gibt es generell eigentlich keinen Bereich, der nicht für
SDS geeignet wäre. Wichtig ist
nur, die passende Lösung zu den
konkreten Einsatzgebieten im
Unternehmen zu finden. Hat man
beispielsweise in der Vergangenheit schon sehr viele Skripts und
Tools verwendet, die im Hinblick
auf die Lösungen eines bestimmten Herstellers konzipiert und optimiert sind, so sollte sicherlich
dieser Hersteller die erste Wahl
sein. Bei einem Großteil der Unternehmen und IT-Umgebungen
ist dies aber nicht der Fall. Das
bedeutet, dass man den Weg der
offenen Plattformen gehen und
je nach Anforderung die optimale Speicherhardware auswählen
kann. In Bereichen, in denen es
um eine hohe Performance und
Verfügbarkeit geht, bieten sich
dann Flash-basierte Lösungen an,
zum Beispiel auch NVMe-SSDs,
die sich durch eine geringe
Latenz, eine hohe I/O-Leistung
und niedrigen Energieverbrauch
auszeichnen. Für reine Archivierungsdaten hingegen sind wesentlich kostengünstigere NL-SAS
durchaus ausreichend.
Wenn es prinzipiell keine Einschränkung hinsichtlich der Einsatzszenarien gibt, so gilt das
künftig auch im Hinblick auf das
SDS-Know-how im jeweiligen Unternehmen. Ein Grundproblem
der Vergangenheit, nämlich dass
die SDS-Lösungen recht komplex
waren und vielfach den Einsatz
zertifizierter Experten erforderten, besteht heute nicht mehr.
Auch kleinere und mittelständische Unternehmen ohne Zugriff
auf großartige Expertise können
inzwischen SDS-Lösungen nutzen. Auf dem Markt gibt es für
diese Zwecke schlüsselfertige
Plug-and-Play-Systeme. Solche
Lösungen bieten alle erforderlichen Funktionalitäten für die Umsetzung einer softwaredefinierten Speicherinfrastruktur, zum
Beispiel mit automatischem Storage Tiering, Thin Provisoning,
Speicher-Pooling, Snapshots, synchroner Spiegelung oder einem
zentralisierten Management.
Live-Migration
ohne Zeitverlust
Der Hauptvorteil ist, dass Unternehmen sich mit Software-defined Storage in Sachen Hardware
herstellerunabhängig machen.
Das war bisher im Speicherumfeld keineswegs zwangsläufig
gegeben. Unternehmen können
dadurch die Hardware-Auswahl
auch nach dem Kriterium „bestes
Preis-Leistungs-Verhältnis“ vornehmen. Zudem lässt sich mit
einem SDS-Ansatz die Komplexität wie Speicherinfrastruktur
durch Zusammenfassen physischer Strukturen drastisch reduzieren.
Dass es möglich ist, vorhandene Speicherlösungen in das SDSKonzept einzubinden, ist ein
weiterer Vorteil. Je nach SDS-Variante ist unter Umständen sogar
eine Live-Migration möglich, das
heißt, dass die bisherige Speicherinfrastruktur im laufenden Betrieb an die neue Lösung angebunden und im Hintergrund migriert werden kann. Mehrere erfolgreich durchgeführte Projekte
haben bewiesen, dass sich zum
Beispiel auf Basis der IBM-Lösungen SAN Volume Controller
(SVC) beziehungsweise Spectrum Virtualize auch größere
Storage-Umgebungen mit mehr
als 400 TByte an Daten ohne
aufwendige Wochenend- oder
Bild: shock – Fotolia.com
T
SOFTWARE-DEFINED STORAGE | Infrastruktur
SOFTWARE-DEFINED STORAGE :
VORTEILE IM ÜBERBLICK
Herstellerunabhängigkeit:
Unterstützung von Hardware
beliebiger Hersteller
Unbegrenzte Skalierbarkeit:
Einfache Erweiterung der
Umgebung im Hinblick auf
Kapazität und Performance
Kosteneffizienz: Reduzierung
des Managementaufwands
Nachtaktionen im laufenden
Betrieb migrieren lassen.
Als Nachteil ist sicherlich anzusehen, dass mit SDS ein konzeptionelles Umdenken einhergehen
muss, sonst sind die neuen Möglichkeiten nicht sinnvoll zu nutzen. Der Grund hierfür ist, dass
mit dem Einsatz einer SDSLösung in der Regel eine Neuorganisation der IT-Prozesse notwendig wird, da die klassischen
Grenzen beispielsweise zwischen
den Administratoren der Bereiche
Storage, Virtualisierung und Netzwerk immer mehr verschwimmen. Nicht zuletzt ist zu berücksichtigen, dass es im Live-Betrieb
auch zu geringfügigen Einschränkungen kommen kann, wenn bestimmte proprietäre Funktionen
oder Plug-ins eines Herstellers
durch die SDS-Software nicht
mehr unterstützt werden beziehungsweise nicht mehr ganau so
funktionieren wie zuvor.
SDS und offene
Plattformen
Wie in vielen IT-Bereichen wird
auch im Storage-Umfeld der
Trend in Richtung offener Plattformen und weg von einer SingleVendor-Strategie gehen, hin zu
einer Infrastruktur, die sich
schnell und dynamisch anpassen
kann, wenn sich die Unternehmensanforderungen ändern.
Das führt natürlich zwangsläufig
auch zur Diskussion um eine
flexible Ressourcennutzung in
der Public Cloud. Zurzeit ist das
Thema Cloud in Deutschland
zwar aufgrund der NSA-Affäre
und datenschutzrechtlicher Bedenken noch immer eher negativ belastet, aber mittel- und
langfristig wird die Auslagerung
durch Integration vorhandener
Hardware-Komponenten
Virtualisierung: Zentrales Management von Einzelsystemen
Hoher Automatisierungsgrad: Effizienzsteigerung
durch Reduzierung manueller
Tätigkeiten
von Daten allein schon zur Reduzierung des Kosten- und Administrationsaufwands ein wesentlicher Bestandteil von StorageGesamtlösungen sein.
Vertrauliche Daten werden mit
Sicherheit auch weiterhin im Unternehmen verbleiben. Zu erwarten ist hier eine Zunahme der
Speicherung auf Bändern, auf die
über das Linear Tape File System
(LTFS) zugegriffen wird. Der Vorteil liegt hier in den geringeren
laufenden Kosten, da Einsparungen sowohl bei der Energieversorgung als auch bei der Kühlung
realisiert werden können. Zudem
ist unter Sicherheitsaspekten
auch eine räumliche Auslagerung
der Bänder problemlos möglich.
Generell wird das Thema SDS
im Speichermarkt immer wichtiger werden. Alle großen Hersteller investieren massiv in diesen
Bereich. IBM beispielsweise hat
Anfang des Jahres angekündigt,
in den nächsten fünf Jahren rund
1 Milliarde US-$ in sein StorageSoftware-Portfolio zu investieren.
Dass das Marktsegment SDS ein
dynamisches Wachstum verzeichnen wird, prognostizieren
auch Marktforscher und Branchenanalysten. Gartner etwa geht
davon aus, dass 2020 zwischen
70 und 80 % aller unstrukturierten Daten auf kostengünstigen
Speichermedien durch SDSLösungen verwaltet werden.
Modernen Speicherlösungen
wie SDS gehört eindeutig die Zukunft. Sie ermöglichen eine dauerhafte Überwindung der heutigen Komplexität. Zudem überzeugen sie durch geringere Speicherkosten sowie eine höhere
Leistung und bessere Kapazitätsauslastung als herkömmliche
Storage-Lösungen.
STORAGE
11
Bild: deninismagilov – Fotolia.com
ALL FLASH | Marktentwicklung
Dipl.-Ing. Doris Piepenbrink, freie Journalistin, München
VOM RAM-BAUSTEIN
ZUM ALL-FLASH-ARRAY
Noch ist die Flash-Technik teuer. Darum wird sie derzeit nur für
hochperformante Daten eingesetzt. Das aber kompromisslos:
verlustfrei direkt am Server, mit einer Steuerung, die direkt auf dem
Hypervisor aufsetzt. Doch die Systeme sind skalierbar bis hin zu All Flash.
M
it zunehmender Verbreitung von Datenbankanwendungen und insbesondere der Server-Virtualisierung kam Decoupled Storage auf, das den Datenstrom in
zwei bis drei Speicherkategorien aufteilt: Der
Performance-Tier enthält „heiße“, hochperformante Daten, wie sie vor allem in Netzen
mit großen Datenbanken und/oder in Virtual-Desktop-Umgebungen vorkommen. Der
Kapazitäts-Tier speichert die „kalten“ Daten.
Er hat eine deutlich größere Kapazität bei
niedrigen Zugriffsraten. In der Regel sind
12
STORAGE
etwa 80 % der Daten diese zeitlich unkritischen Daten. Es ist sinnvoll, diese auch weiterhin auf herkömmlichen Medien abzuspeichern. Der dritte Tier umfasst die langfristige
Archivierung der Daten.
Schnelle Operations,
geringe Latenzzeiten
Der Performance-Tier entspricht in etwa dem
Arbeitsspeicher. Hier werden alle Datenzugriffe auf Anwendungen unmittelbar
zwischengespeichert. Herausfordernd sind
Situationen, in denen viele Anwender gleichzeitig auf einen Server zugreifen, etwa beim
morgendlichen Einloggen. Für solche Fälle
sind die schnellen Flash-Speicherbausteine
prädestiniert.
Die Hersteller von neueren Flash-SSDs erreichen für ihre Komponenten IOPS-Werte
(Input/Output Operations Per Second), die
bis zu mehreren Zehnerpotenzen über
denen von Festplatten liegen können – mit
entsprechend niedrigen Latenzzeiten. Allerdings ist die Speicherkapazität begrenzt, bei
RAM-Bausteinen sind es derzeit 10 TByte. Appliances, wie sie zum Beispiel Atlantis anbietet, erreichen 25 TByte. Außerdem haben
Flash-Komponenten eine geringere Lebensdauer als Festplatten und sind erheblich teurer, auch wenn sich das mit zunehmender
Verbreitung verbessern wird.
Aufgrund der hohen Kosten setzen viele
Netzbetreiber auf hybride Decoupled-Storage-Lösungen. Bei einem SAN entscheidet oft
noch ein Storage-Controller, welche Daten
über den Performance-Tier gespeichert werden und welche im SAN. Doch allein der mit
der Einbindung in das SAN verbundene Protokoll-Overhead kostet Zeit. Zudem sitzt der
SAN-Controller bei den Speicherkomponenten und nicht in Servernähe. Auch das kostet
Zeit. Insgesamt sind hier Latenzzeiten von 1
bis 2 ms üblich. Aus diesem Grund haben
sich in virtuellen Server-Umgebungen Lösungen durchgesetzt, die den Flash-Speicher
möglichst nahe an den Server-CPUs platzieren und das Speicher-Controlling auf dem
Hypervisor aufsetzen. Ein zusätzlicher SANController ist damit unnötig.
3D XPoint und NAND in CPU-Nähe
Damit beim Speichern der Daten keine Zeit
verloren geht, sollten Performance-Daten
möglichst unmittelbar im Server gespeichert
werden. Es gibt Lösungen, bei denen der
Flash über PCIe oder RAM-DIMM-Slots direkt
an die Server-CPU angebunden ist. Auf diese
Weise sind Latenzzeiten von 60 μs erreichbar.
Und EMC2 zum Beispiel kaufte 2014 das
Start-up-Unternehmen DSSD, das Techniken
entwickelt, mit denen sich Flash-RAMBausteine für High-Perfomance-Computing
bündeln lassen, um die Speicherkapazität zu
erweitern. Die Daten werden parallel und als
Objekte aufgezeichnet, sodass man noch
schnellere IOPS-Werte erzielt und Datenverluste vermeiden kann.
2016 will Intel mit Micron die 3D-XPointEntwicklung auf den Markt bringen. Diese
nichtflüchtige Speichertechnik basiert auf unterschiedlichen Widerständen und nicht auf
Spannungsunterschieden wie NAND. Die
Daten werden in mehreren Ebenen abgespeichert. Der Flash-Speicher soll tausendmal
schneller sein als die heute für Speicherkarten
und Solid State Drives verwendete NAND-
Bild: PernixData
ALL FLASH | Marktentwicklung
Storage-Management per
Hypervisor mit der Software
FVP 3.0 von PernixData.
Technik. Außerdem soll sie langlebiger sein
und eine bis zu zehnmal höhere Dichte aufweisen. Die ersten 3D-Xpoint-Speicher werden laut Ankündigung vom Sommer 2015
eine Kapazität von 128 GByte pro Die haben.
3D-NAND-Chips des gleichen Herstellerduos
erreichen maximal 48 GByte pro Die. Intels
Datacenter-Chefin Diane Bryant versprach
auf dem Intel Developer Forum im Sommer
2015, dass 3D-XPoint-Flash-Technik zudem
nur halb so viel kosten werde wie DDR4.
Einbindung in den Hypervisor
Bei virtuellen Server-Umgebungen sind
hochperformante I/O-Prozesse keine Seltenheit. Deshalb bieten sich hier möglichst CPUnahe Flash-Speicher an. Und wenn der Controller auf dem Hypervisor aufsetzt, kann er
Anwendungsdaten aus dem Hypervisor für
Analysen heranziehen und noch schneller
und eindeutiger festlegen, ob Prozesse in
den Performance- oder den Kapazitäts-Tier
gehören. Um Datenverluste durch Komponentenfehler zu vermeiden, werden die
Daten einer Virtual Machine wie bei RAIDSystemen parallel auf mehrere Server im Hypervisor-Cluster abgespeichert.
Der Administrator arbeitet laut Angaben
der Hersteller in einer auf den Hypervisor angepassten Oberfläche und hat wenig Konfigurationsaufwand. Jedem Server ist ein Flash
zugeordnet, der mit der Serverzahl linear
mitwachsen kann. Die Speicherkapazitäten
werden im Pool über die virtuelle Oberfläche
verwaltet, sodass das System die volle Kapazität der angeschlossenen Speicherlösungen
ausnutzen kann.
Lösungen auf dem Markt
Es gibt mittlerweile eine Reihe von Lösungen
auf dem Markt: Die Speichersoftware FVP 3.0
von PernixData ist eine der bekanntesten; sie
unterstützt vSphere 6. FVP ist auf VMwareUmgebungen zugeschnitten und kann nach
PernixData-Angaben ohne Einschränkung
mit allen VMware-Funktionen zusammen genutzt werden. Der Hersteller bietet auch eine
freie Version seiner Software an.
Die Software USX von Atlantis hat Deduplizierung und Kompression der Daten integriert und lässt sich laut Hersteller in vSphere
6 und den Citrix XenServer einbinden. Der
Hersteller hat auch All-Flash-Arrays als Appliance im Programm. Die 19-Zoll-Einschübe
können in zentralen Switchen CPU-nah das
komplette Storage übernehmen.
EMC2 bietet verschiedene Software- und
Appliances auf Flash-Basis an, für Flash-Server-, Hybrid-Array- und All-Flash-Array-Lösungen. Die Software läuft ebenfalls unter
dem Hypervisor (VMware oder Citrix). Die
Brick-basierte SAN-Lösung EMC XtremIO AllFlash Scale-out Array arbeitet mit 25 SSDDrives pro Brick, wobei die Storage-Appliance
bis zu acht Bricks im Cluster verwalten kann.
Ein Brick fasst je nach Ausführung zwischen
5 und 40 TByte. Die Lösung ist skalierbar auf
bis zu 320 TByte.
Software und Storage
schaukeln sich hoch
Die Lösung ist nicht billig, und die Lebensdauer erreicht mit NAND-Flash wahrscheinlich nicht die von Festplatten. Doch mit neuer
Flash-Technik und sinkenden Preisen wird
klar, wohin die Reise geht. Derzeit erscheint
das noch sehr überdimensioniert: Welcher
Server hat heute ein derart hohes performantes I/O-Datenaufkommen, dass ein FlashArray erforderlich wäre? Aber mit der zunehmenden Etablierung von Flash-Speicher im
Storage ändern sich auch die Anwendungen,
weil Entwickler keine Rücksicht mehr nehmen müssen. Das wiederum hat Auswirkungen auf die gesamte Netzwerkstruktur, die
dann in Sachen Performance mitziehen muss.
In diesem Szenario sind Fibre Channel und
Festplatten Auslaufmodelle.
INTEGRATION | Hyperkonvergenz
Alexander Thoma, Senior Solutions and Performance Engineer Nutanix
DER UNSICHTBARE HYPERVISOR
Komplexität ist eines der größten Probleme im Rechenzentrum. Zwar hat Virtualisierung die Flexibilität
erhöht und viele Fragen gelöst. Mit der Zeit aber hat sie die Komplexität weiter erhöht. Schuld daran sind
meist traditionelle Speichersysteme (SAN/NAS), doch immer mehr die Management-Komponenten.
E
inige der Komplexitäten und Kostentreiber traditioneller Hypervisoren rühren
daher, dass sie von externen Komponenten
wie Datenbankplattformen und einer Vielzahl
von Managementkomponenten abhängig
sind. In der Regel erfordert jede dieser Komponenten zu Beginn ein Design und eine Dimensionierung auf Expertenniveau; danach
muss manuell skaliert werden, wenn die Umgebung wächst. Diese Datenbank- und Managementkomponenten nehmen einen beträchtlichen Teil der Zeit in Anspruch, die das
Betriebsteam für die Administration aufwendet. Am Ende führen diese Komplexitäten zu
steigenden Kosten (sowohl Betriebs- als auch
Investitionskosten) sowie Risiken, die wiederum in vielen Fällen die Verfügbarkeit und
Leistung beeinträchtigen.
Überkomplexe RZ-Architekturen
Traditionelle Hypervisoren sollen einen
immer größeren Mix an Rechen- und Speicherkomponenten unterstützen. Hier liegt
die Ursache für Probleme bei der Leistung,
Zuverlässigkeit und Interoperabilität. Angesichts der zahllosen Kombinationen und
Konfigurationen ist die Qualitätssicherung
(QS) einer sehr großen Anzahl von Komponenten schlicht unrealistisch. In klassischen
Szenarien bleiben Kompatibilitätsfragen ein
Risiko, im Design und während der gesamten Lebensdauer der Infrastruktur.
Viele Funktionalitäten klassischer Hypervisoren wurden dafür konzipiert, Herausforderungen wie die Verwaltung von Kapazitäten
und Leistung oder Noisy-Neighbor-Probleme zu meistern. Das ist das Resultat einer
einfachen Tatsache: Traditionelle Three-TierSpeicherarchitekturen wurden nie für eine
virtualisierte Welt gebaut. Solche Funktionalitäten versuchen zum Beispiel, die Schwierigkeiten zu umgehen, die entstehen, wenn
die Kapazität via Multiple Datastores (LUNs)
an den Hypervisor gemeldet wird. Andere
14
STORAGE
Mechanismen sorgen für einen fairen Ausgleich beim Speicherzugriff virtueller Maschinen untereinander, falls in der begrenzten Warteschlangentiefe für einen einzelnen
Datastore Konflikte auftreten.
Diese Schwierigkeiten und Konflikte zwingen Systemarchitekten dazu, zusätzliche
Funktionen zu nutzen und immer häufiger
komplexe Architekturentscheidungen schon
in der Designphase zu treffen. Zahlreiche
Storage-Anbieter wiederum haben in ihrem
Bemühen, die sprichwörtliche Quadratur des
Kreises zu erreichen und das SAN doch noch
passend für die Virtualisierung zu machen,
Multipathing-Treiber entwickelt; einige verlangen dafür auch Lizenzgebühren.
All diese Faktoren verteuern das Projekt
und machen es komplexer. Die Folge: Die
Zeit bis zum Abschluss der Implementierung
und zur Betriebsabnahme der Infrastruktur
verlängert sich.
Abstraktion von der
Virtualisierungsebene
Darum ist die Zeit überreif für eine neue Generation von Hypervisoren, um die Virtualisierungsschicht zu vereinfachen. Die Möglichkeiten und Merkmale – Hochverfügbarkeit, VMMobilität, Analytics etc. –, die Unternehmen
mittlerweile erwarten, müssen dieselben bleiben. Aber sie müssen verständlicher und
leichter zu nutzen sein. Hypervisoren der
nächsten Generation zeichnen sich durch integrierte und hochskalierbare Managementschichten aus, und zwar ohne Abhängigkeiten von Datenbankplattformen Dritter. Das
spart Lizenzkosten und vereinfacht die Architektur. Die Implementierung der verschiedenen Managementkomponenten entfällt ganz.
Außerdem sinkt der Aufwand im laufenden
Betrieb ebenso wie die Komplexität bei der
Administration von Drittkomponenten.
Dennoch reicht ein integriertes und
skalierbares Management allein nicht aus.
Der Clou eines Next-Generation-Hypervisors
besteht darin, dass sämtliche Komponenten
hochverfügbar und mit Selbstheilungsmechanismen ausgestattet sind. Die Managementkomponenten sollten dementsprechend auf jeder einzelnen CVM (Controller
Virtual Machine) laufen. Dadurch können die
Aufgaben gleichmäßig über den gesamten
Cluster verteilt werden. Sollte eine CVM offline
gehen, arbeiten die übrigen CVMs deren
Aufgaben automatisch ab.
Außerdem müssen Hypervisoren der
nächsten Generation über integrierte Analysefunktionen verfügen. Diese müssen zudem
hochverfügbar sein und mit dem wachsenden Cluster skalieren. Zu diesem Zweck werden die Analysekomponenten und Statistikfunktionen gleichmäßig über die Knoten im
Cluster verteilt. Das sichert gleich bleibende
Leistung und Funktionalität, unabhängig
von der Größe der Umgebung. Anders als bei
traditionellen Hypervisoren müssen dann
keine Analysekomponenten entworfen, installiert und konfiguriert werden, die später
eine eigene Managementaufgabe sind und
nicht selten das Risiko eines Single Points of
Failure bergen.
Die integrierten Analysefunktionen müssen sowohl Echtzeit- als auch historische
Daten liefern, und zwar nicht nur über die virtuellen Maschinen und den Hypervisor, sondern auch über die zugrunde liegende Infrastruktur, die Hardware und die verteilte Speicherstruktur. Es ist wichtig, durch eingebaute
Tools zur Bedarfsermittlung einen Pool an
verfügbaren Ressourcen (Kapazitäten etc.)
bereitzustellen. Mit solchen Werkzeugen können Administratoren den Kauf zusätzlicher
Knoten je nach Bedarf planen; sie vermeiden
eine Anschaffung auf Vorrat und dadurch
überhöhte oder unnötige Investitionen.
Beim Skalieren traditioneller Hypervisoren
und Speicher müssen Kapazitätsanpassungen sowohl auf der Ebene der Rechenressourcen als auch des Speichers stattfinden.
INTEGRATION | Hyperkonvergenz
Bild: kentoh – Fotolia.com
Dabei ist keineswegs garantiert, dass sich mit
der Skalierung eine höhere Leistung erreichen lässt. In einem Hypervisor der nächsten
Generation hingegen werden Anpassungen
der Rechen- und Speicherressourcen an
einem einzigen Ort vorgenommen – über
die Managementoberfläche (am besten auf
HTML5-Basis). Solche fortgeschrittenen Hypervisoren können sogar die Zeit abschätzen, wann eine oder mehrere Ressourcen zur
Neige gehen, und Vorschläge unterbreiten,
was für eine Art Knoten angeschafft werden
sollte, um die Leistungs- und Kapazitätsgrenzen zu beseitigen.
Integrationstiefe und
Hochverfügbarkeit
Es gibt jedoch noch weitere Anforderungen
an moderne Hypervisoren. So müssen sie mit
gemeinsam genutztem Scale-out Storage,
also der zugrunde liegenden verteilten Speicherstruktur, tief integriert sein. Nur dadurch
lassen sich Komplexitäten wie Multipathing,
LUNs oder RAID beseitigen. Andererseits müssen der Hypervisor und die verteilte StorageStruktur Dinge ermöglichen wie voneinander
unabhängige Software-Upgrades. Das ist die
Voraussetzung dafür, betriebsbedingte Komplexitäten zu reduzieren und ein Maximum an
Stabilität zu erreichen. Dazu müssen die verteilte Storage-Struktur und andere Managementkomponenten in einer CVM laufen, die
auf dem Hypervisor aufsetzt. Ein weiterer
Vorteil dabei ist, dass die verteilte StorageStruktur dadurch Hypervisor-agnostisch wird.
Darüber hinaus kann die Integration mit
der Speicherstruktur ein granulares Kapazitätsmanagement überflüssig machen, gleichzeitig aber die Daten lokal bei der darauf zugreifenden virtuellen Maschine halten und
dadurch die Leistung erhöhen. Bei einem
Hypervisor der nächsten Generation sollte es
Konzepte wie Mounts oder Datastores gar
nicht geben. Stattdessen werden hier dlockStorage-Geräte (vDisks) von einem einzigen
Storage-Pool aus via iSCSI direkt den verschiedenen VMs präsentiert, sodass die
Kapazitäten nicht mehr an verschiedenen
Orten verwaltet werden müssen.
Ferner bietet ein Hypervisor der nächsten
Generation intelligentere Funktionalitäten
für Hochverfügbarkeit. Diese starten VMs auf
dem Knoten neu und schaffen dadurch bei
einem Ausfall am schnellsten Abhilfe. Durch
die Integration mit der verteilten Speicherstruktur ist der Hypervisor in der Lage, zu
ermitteln, wo sich die aktivsten Daten für die
jeweilige VM befinden. Ferner können moderne Hypervisoren die Auslastung von CPU
und Arbeitsspeicher analysieren, bevor virtuelle Maschinen auf dem für sie optimalen
Knoten hochgefahren werden. Im Ergebnis
verringern Hypervisoren mit eingebauter
Hochverfügbarkeit den Zeitaufwand für die
Wiederherstellung von virtuellen Maschinen
und die Rückkehr zur normalen Betriebsgeschwindigkeit.
Die Unabhängigkeit moderner Hypervisoren von der Version des zugrunde liegenden Software-gesteuerten Speichers ist
ein weiterer wichtiger Punkt. Müssen Hypervisoren und Speicher gleichzeitig einem
Upgrade unterzogen werden, steigen die
Komplexität und die Dauer der UpgradePhase. Dies führt unter Umständen zu Problemen bei der Interoperabilität mit anderen
Komponenten. Unternehmen könnten deshalb versucht sein, ältere Versionen länger
als geboten zu verwenden und sich mit
einem geringeren Nutzen der eigenen
Infrastruktur zufriedenzugeben.
Sicherheit, Automation,
Selbstheilung
Viele Unternehmen setzen auf sogenannte
Security Technical Implementation Guides
(STIGs), also standardisierte Methoden zur sicheren Installierung und Wartung von Softund Hardware. Darum benötigen moderne
Hypervisoren eingebaute Funktionalitäten
für Eigen-Audits und automatische Reparatur, um die STIG-Vorgaben zu erfüllen. Wenn
der Hypervisor zum Beispiel von Haus aus
gehärtet ist, ohne dass Administratoren
Empfehlungen wie das Entfernen überflüssiger Software, das Vorschreiben von Passwortlänge und -aufbau oder das Schließen
nicht benötigter Ports anwenden müssen,
reduziert sich die Angriffsfläche.
Wachsende Anforderungen machen es
unumgänglich, dass moderne Hypervisoren
mit vollautomatischen Selbstheilungsmechanismen für die Hardware und die
Managementkomponenten ausgestattet
sind. Dies zeigt sich etwa im UpgradeProzess, in dem automatisch die korrekten
Aktualisierungen heruntergeladen und installiert, zuvor jedoch automatisch auf Stabilität, Konnektivität und Funktionalität überprüft werden. Intelligentes Umleiten und
Lastverteilen des Storage-Traffics über alle
Knoten innerhalb eines Clusters hinweg
verhindert Unterbrechungen bei der Aktualisierung der Controller VM. Dazu werden die
auf dem Knoten betriebenen VMs automatisch auf andere Knoten migriert und
nach Abschluss des Upgrades zurückgespielt.
Der Grad an Datenlokalität und folglich die
erzielte Leistung bleiben dadurch auf
maximalem Niveau.
Bei diesem Automatisierungsgrad sind
Upgrades mit einem einzigen Klick möglich
und lassen sich ohne spürbare Leistungseinbußen auch während der Geschäftszeiten
vornehmen. Gleichzeitig wird das Risiko fehlerhafter Upgrades auf ein Minimum reduziert und betrifft im schlimmsten Fall einen
einzigen Knoten.
Zusätzlich sollte die Managementplattform eines modernen Hypervisors in der gleichen Weise – also unterbrechungsfrei und
mit nur einem Klick – in der Lage sein, die zugrunde liegenden Speicher und HardwareKomponenten zu aktualisieren. Das Ziel der
Automatisierung besteht ja darin, die Infrastruktur so unsichtbar wie möglich zu machen, damit das IT-Team sich um die wirklich
wertschöpfenden Aufgaben kümmern kann.
Sollte dennoch ein Ausfall auftreten, muss
die Plattform in der Lage sein, die Hypervisoren, die Management-Komponenten und die
Speicherstruktur eigenständig zu reparieren,
noch bevor die Hardware ausgetauscht wird.
Mit einem modernen Hypervisor gelingt dies
dadurch, dass die Management-Funktionen
der Controller VM vollständig verteilt und
redundant ausgeführt sind.
Solche Selbstheilungsmechanismen senken nicht nur das Risiko weiterer Ausfälle,
sondern sind eine Voraussetzung der Erfüllung immer anspruchsvollerer SLAs. Denn
selbst Standards wie der Hardware-Austausch vor Ort innerhalb von vier Stunden
genügen nicht, um eine Verfügbarkeit zu gewährleisten, die über 99,95 % liegen soll.
Konzentriertes RZ-Management
Mithilfe eines Hypervisors der nächsten Generation lassen sich zahlreiche Komplexitäten beim Management von Rechenzentrumsinfrastrukturen minimieren und oft sogar
beseitigen. Die Infrastruktur wird dadurch
gleichsam unsichtbar. Die wichtigste Folge
davon ist, dass die IT-Teams sich weniger
darum kümmern müssen, den laufenden
Betrieb zu gewährleisten, und stattdessen
mehr Zeit für die geschäftlichen Ziele ihrer
Unternehmen aufwenden können.
STORAGE
15
VM-DATENSICHERUNG | Disaster Recovery
SNAPSHOTS, BACKUP, REPLIKATE –
WAS, WANN, WIE?
Datensicherung und Disaster Recovery sind in virtualisierten Umgebungen doppelt wichtig.
Seitdem schlagen sich die Rechenzentren mit enormen Datenmengen herum,
die entsprechend viel Speicherplatz kosten. Unklar ist oft die Funktion von Snapshots.
Richtig ist, dass Snapshots die Basis solider Backups sind.
V
irtualisierungstechnologien sind aus der
Unternehmens-IT kaum noch wegzudenken. Auch für kleine und mittlere Unternehmen haben virtuelle Umgebungen Potenzial,
spätestens seit Microsofts Entscheidung, den
hauseigenen Hypervisor Hyper-V kostenlos
auszuliefern. Hyper-V ist bislang allerdings
nur sporadisch vertreten. VMware hat mit
seinen ESX- und vSphere-Lösungen die Nase
deutlich vorn. Unklar ist in vielen Anwenderunternehmen aber eine entscheidende
Frage: Wie wird ein virtueller ESX-Server
eigentlich am besten gesichert?
Grundsätzlich gilt: Nur gesicherte Daten
und Systeme können verlässlich und nachhaltig den laufenden Geschäftsbetrieb
garantieren.
Snapshots sind keine Backups
Dass ein Snapshot einer virtuellen Maschine
ein Backup ersetzt bzw. als solches genutzt
werden kann, ist ein weitverbreitetes Missverständnis. Obwohl Snapshots und Backups einige Berührungspunkte haben, ist der jeweilige Einsatzzweck deutlich zu unterscheiden.
Ein paar Fakten: Ein Snapshot ist die Aufzeichnung des Zustands der virtuellen Maschine zu einem bestimmten Zeitpunkt. Ein
Snapshot ist aber keine vollständige Kopie
der virtuellen Festplatte, sondern eine DeltaDatei oder, anders gesagt, eine Art Changelog. Der aktuelle Zustand der virtuellen
Maschine ist eine Kombination originaler
Datenträger und ihrer Snapshots.
ESX-/vSphere-Snapshots werden in direkter Nachbarschaft des Originals abgelegt. Sie
wachsen in 16 MByte großen Inkrementen
und können daher die Größe des originalen
Datenträgers erreichen oder sogar übertreffen. Handelt es sich bei der virtuellen
Maschine beispielsweise um einen Mail-,
Datenbankserver oder um ein anderes
System mit hohen Änderungsraten, erreicht
die Größe des Snapshots recht schnell
die Größe des Ausgangsdatenträgers.
VMware-Snapshots sind immer vom Typ Thin
16
STORAGE
Provisioned und haben daher eine nachteilige Wirkung auf die Performance von
Produktivumgebungen.
Obwohl es theoretisch möglich ist, eine
Kette von bis zu 32 Snapshots aufzubauen,
empfiehlt VMware maximal zwei bis drei
Elemente in einer Snapshot-Kette. Die
Datensicherheit und die Performance sind
bei einer höheren Anzahl unter Umständen
nicht mehr gesichert. Ein einzelner Snapshot
sollte in der Regel maximal 72 Stunden
abdecken. Andernfalls wird er so groß,
dass das Rückspielen auf die originale Festplatte unverhältnismäßig viel Zeit benötigen
würde.
Snapshots von virtuellen Maschinen wurden vor allem zu Testzwecken entwickelt. Sie
eignen sich hervorragend, um kürzlich geänderte Konfigurationen ungeschehen zu machen oder um Probleme durch fehlerhaft
aufgespielte Software zu beheben. Wenn
man Snapshots allerdings anstelle von Backups verwendet, dann wird das erstens die
Performance der virtuellen Maschine negativ
beeinflussen, und man riskiert darüber
hinaus auch den Verlust von Daten.
Snapshots haben eine Reihe nützlicher Eigenschaften und sind vorzüglich geeignet,
um ein System temporär zu sichern, beispielsweise während die virtuelle Maschine
aktualisiert wird. Sollte dabei ein Problem
auftreten, lässt sich das System wieder in den
Ausgangszustand zurücksetzen – und das im
Handumdrehen. Das Löschen des Snapshots
reicht, und schon sind die fehlerhaften Modifikationen Geschichte. Ist hingegen alles
o.ˇk., werden die Änderungen einfach auf die
originale virtuelle Festplatte angewendet.
Das ist praktisch und in vielen Situationen
äußerst hilfreich, aber eben kein ausreichender Ersatz für ein richtiges Backup.
Backups sind keine Snapshots
Das Erstellen eines VM-Backups ist ein vielschichtiger Prozess. Dabei wird beispielsweise eine exakte und vollständige Kopie der
virtuellen Maschine erstellt, diese Kopie an
einen neuen Speicherort verschoben und
dabei im Normalfall komprimiert. Je nachdem, welche Art Backup-Lösung man einsetzt, und je nach persönlichem Setup,
geschieht das Komprimieren entweder vor
oder nach dem Verschieben auf den Zielspeicher. Beide Varianten haben Vor-und Nachteile und sollten daher mit Bezug auf den
Einsatzzweck ausgewählt werden. Die Komprimierung auf dem Ursprungssystem beeinträchtigt die Rechenleistung dieses Systems,
ermöglicht aber eine deutlich effizientere
Netzwerkübertragung.
Der weitaus wichtigste Part ist allerdings
das Erstellen einer konsistenten Kopie
der virtuellen Maschine. Und obwohl ein
Snapshot als eigentliche Backup-Lösung
nicht infrage kommen sollte, ist er integraler
Bestandteil des tatsächlichen BackupProzesses. Die meisten Backup-Lösungen
für ESX-/vSphere-Umgebungen basieren auf
VMware-nativen Snapshot-Technologien.
Man kann einen Snapshot auch als eine „eingefrorene“ Version der virtuellen Maschine
beschreiben – und nur in einem solchen
Zustand kann eine konsistente Kopie der
VM erstellt werden. Wäre das Dateisystem
während des Kopiervorgangs nicht „eingefroren“, dann würden sich die zu kopierenden .vmdk- (virtuelle VMware-Festplatte)
und .vmx-Dateien (Einstellungsdatei einer
VMware-Maschine) während des Kopiervorgangs mit hoher Wahrscheinlichkeit verändern. Die erstellte Kopie wäre damit zu
keinem Zeitpunkt konsistent.
Ein Snapshot macht also allein noch kein
Backup, ist für das Anfertigen von VMBackups aber notwendig. Abgesehen von
den nativen Lösungen der Hersteller von
Virtualisierungslösungen gibt es eine Reihe
von weiteren Angeboten am Markt. Diverse
Hersteller bieten Backup-Produkte für VMwareInfrastrukturen an, und obwohl sich diese
Angebote konzeptuell zum Teil deutlich unterscheiden, basieren nahezu alle Lösungen
auf der Snapshot-Technologie.
Bild: viperagp – Fotolia.com
Simon Köhl, Paragon Technologie GmbH
VM-DATENSICHERUNG | Disaster Recovery
Einsatz- und Restore-Szenarien
Hat eine Backup-Software Zugriff auf die
per Snapshot bereitgestellten Dateien der
virtuellen Maschine, unterscheidet sich das
Vorgehen beim eigentlichen Backup von
Hersteller zu Hersteller. Verschiedene Speicherorte, redundante Backup-Optionen, verschiedene Methoden der Komprimierung
und Datendeduplikation, inkrementelle Ansätze und selbstverständlich auch unzählige
Wiederherstellungsmöglichkeiten, sind nur
einige der möglichen Auswahlkriterien. Die
eine und einzige richtige Backup-Lösung
kann und wird es nicht geben. Vielmehr sollte man je nach Einsatzszenario sorgfältig
auswählen.
Das hauptsächlich realistische Wiederherstellungsszenario ist ein nicht minder wichtiger Selektor. Manche Lösungen sind besser
geeignet, wenn die Maschine an ihrem
Ursprungsort wiederhergestellt werden soll,
andere können einen virtuellen Server dafür
direkt aus dem Backup heraus starten.
Ein weiterer kritischer Teil des Backup-Prozesses ist die Entfernung des Snapshots. Ist
die Sicherung erfolgreich verlaufen, wird der
Snapshot nicht länger benötigt, sondern
kann im Gegenteil sogar störend wirken. Einbußen bei der VM-Performance und unnötig
belegter Speicherplatz wurden ja bereits
angesprochen. Im Normalfall sendet das
Backup-System daher eine Löschinstruktion
an die ESX- oder vSphere-Umgebung und
veranlasst die Entfernung des Snapshots.
Sollte es hierbei zu Kommunikationsproblemen kommen, kann dies zu „verwaisten“
Snapshots und damit zu den angesprochenen Nachteilen führen. Eine gute BackupLösung wird dies allerdings spätestens beim
nächsten Run überprüfen und das Remanent
entfernen.
Je nach Backup-Konzept und eingesetzter
Lösung kümmert sich die Software außerdem um die Archivierung der Backups, verschiebt ältere Backup-Images auf SecondTier-Speicher und dedupliziert die zu archivierenden Daten.
Replikation und
Hochverfügbarkeit
Replikate von virtuellen Maschinen sind eine
dritte Möglichkeit der Sicherung. Virtuelle
Server, die First-Tier-Anwendungen bereitstellen und daher hochverfügbar sein müssen,
werden am besten mittels VM-Replikation
gesichert. Die Replikation bietet mit Abstand
den besten RTO (Recovery Time Objective),
da VM-Replikate nicht komprimiert und
konzeptbedingt nahe der Originalmaschine
und in ihrem Ursprungsformat vorgehalten
werden. Replikate können im Ernstfall sofort
und ohne zusätzlichen Konfigurationsaufwand in Betrieb genommen werden. Viele
Backup-Lösungen stellen übrigens auch
Methoden zur VM-Replikation bereit und
können sogar inkrementelle Ketten anlegen.
Hierfür braucht es also nicht unbedingt eine
zusätzliche Lösung, was im Zweifel sowohl
den Aufwand reduziert als auch den Geldbeutel schont.
Wie sich denken lässt, ist VM-Replikation
die bessere Version des VM-Snapshots. Datenkorruption, völliger Verlust der Originaldaten oder Performance-Einbrüche der originären Virtual Machine sind mit Replikationen
nicht zu befürchten, da sie anders als der
Snapshot auf einem anderen physischen
Speicherort liegen und erst im Notfall zum
Einsatz kommen. Da Replikate aber konzeptbedingt auf First-Tier-Datenspeichern
vorgehalten werden, sind sie je nach Größe
der virtuellen Infrastruktur merkliche Kostenfaktoren. Für Systeme, die keine Hochverfügbarkeit benötigen, sind VM-Replikationen
daher nicht unbedingt das richtige Konzept.
Will man also Daten und virtuelle Umgebungen effektiv sichern, ist eine dedizierte
Backup-Lösung das Mittel der Wahl. Bei kurzfristigen Wartungsarbeiten kann die Snapshot-Technologie punkten, und für optimale
RTOs ist VM-Replikation das richtige Mittel.
SCALE-OUT | All-Flash
Mara McMahon, Segment Director SolidFire
KAPAZITÄTSPLANUNG
FÜR SERVICEPROVIDER
Die Planung der Storage-Kapazität im Rechenzentrum ist eine
komplizierte Sache, zumal wenn Serviceprovider auf die
falsche Architektur setzen. In einem Scale-out-Modell lassen
sich Kapazitätserweiterungen bei garantierter Performance
flexibel und ohne Betriebsunterbrechungen vornehmen.
D
ie richtige Planung der Storage-Kapazität
ist für alle Cloud- und Hosting-Serviceprovider ein kritisches Thema, denn Planungsfehler können erhebliche Auswirkungen auf die Profitabilität haben. Um einerseits
den Anforderungen Performance-kritischer
Workloads gerecht zu werden und um andererseits eine breite Palette von BusinessAnwendungen in mandantenfähigen Multitenant-Umgebungen zu unterstützen, setzen
Serviceprovider heute verstärkt auf All-FlashArrays. Aber bei der Mehrzahl der Lösungen,
die auf dem Markt verfügbar sind, stellt
die Skalierung der Kapazität ein Risiko dar: Da
die meisten All-Flash-Speicherlösungen auf
einem Scale-up-Modell basieren, müssen die
Rechenzentren mit hohen Kosten und Ausfallzeiten aufgrund von Datenmigration und
der damit verbundenen Wartungsarbeiten
rechnen.
Scale-up mit Hindernissen
Generell ist es so, dass wegen der hohen
Performance von All-Flash-Arrays die meisten Systeme viel früher an Kapazitäts- als
an Leistungsgrenzen stoßen. In einem Scaleup-Modell erhält man mehr Kapazität,
indem man neue Speichersysteme hinzufügt, also durch neue Controller plus Laufwerke. Damit sind nicht nur erhebliche
Kosten verbunden; in der Regel heißt das
auch, dass Daten migriert werden müssen,
was wiederum mit dem Risiko von Datenverlusten verbunden ist. Und es entstehen
regelmäßig Storage-Inseln, separate, siloartige Systeme mit einer bestimmten, nicht
austauschbaren Technologie, die einen
hohen Verwaltungsaufwand mit sich
bringen. Da in einem Scale-up-Modell Performance und Kapazität voneinander abhängen, verteilt sich die Controller-Leistung
des Systems bei zusätzlichen Kapazitäten
auf mehr Daten und Anwendungen. Dadurch werden Scale-up-Designs anfällig für
das Noisy-Neighbor-Problem: Eine kleine
Zahl Performance-hungriger Anwendungen
18
STORAGE
monopolisiert die Controller-Ressourcen
und beeinträchtigt damit die Leistung aller
anderen Anwendungen innerhalb des
Arrays.
Dagegen erlaubt es eine Scale-out-Architektur, die Kapazität nach oben oder unten
zu skalieren, indem man einfach Knoten hinzufügt oder entfernt. Ein gut organisiertes
System benötigt dabei keine Datenmigration
und auch keinen zusätzlichen Verwaltungsaufwand. Um das Noisy-Neighbor-Problem
aus der Welt zu schaffen, stellt ein Scale-outDesign seine Kapazitäten unabhängig von
der Performance zur Verfügung. Quality of
Service verschafft jeder Anwendung eine
garantierte Performance. Der Serviceprovider
muss also nicht (ungenutzte) Kapazitäten
hinzufügen, um mögliche PerformanceProbleme im Vorfeld abzufangen.
Scale-out-Designs müssen deshalb in der
Lage sein, für die Leistung ein Minimum-,
Maximum- und Burst-Level zu definieren,
wobei das Minimum-Level am wichtigsten
ist, da es für jede Anwendung eine
feste Basis bestimmt, also eine bestimmte
garantierte Leistung.
Scale-out mit neuen Nodes
Ein weiteres Storage-Risiko für Serviceprovider stellen End-of-Life-Upgrades dar. In einer
Scale-up-Architektur sind die üblichen Servicezyklen, die sich über drei bis fünf Jahre
erstrecken, der Fluch der Administratoren.
Planung, Prüfung und Realisierung erstrecken sich oft über Monate, darüber hinaus
sind teure professionelle Services nötig und
muss man die Kunden mit Downtime konfrontieren.
Mit einer Scale-out-Architektur, die es erlaubt, verschiedene Hardware-Generationen
zu mischen, werden Hardware-Upgrades zu
einem eher trivialen Prozess. Serviceprovider
können einfach Knoten zum Cluster hinzufügen oder entfernen – ohne Ausfallzeiten,
ohne Rebalancing, ohne Restriping, ohne ReAllokation von Volumes. Außerdem sind Serviceprovider damit in der Lage, Kapazität und
Knoten zwischen ihren Rechenzentren auszutauschen. Wenn ein Rechenzentrum über ungenutzte Kapazitäten verfügt, während ein
anderes Datacenter mehr benötigt, können
sie einen Knoten ohne Betriebsunterbrechung von einem zum anderen bewegen.
Ohne die richtige Technologie stellt das
Upgrading von Kapazität oder Performance
ein echtes Problem dar: Wenn ein Provider
sich bei der Kapazitätsplanung nicht absolut
sicher ist, ist er schon zum Upgrade gezwungen. Das bedeutet aber immer auch
Betriebsunterbrechungen: Services müssen
offline gehen, wofür entsprechende Wartungsintervalle einzuplanen sind. Nur mit einem
Scale-out-Ansatz in einer robusten Architektur,
die einfach zu verwalten ist, können
Serviceprovider zuverlässig planen und ihre
Kapazität ohne Risiko skalieren.
OBJECT STORAGE UND BLOCK STORAGE
Object Storage und Block Storage sind
die beiden häufigsten Methoden in Scaleout-Storage-Umgebungen auf Basis von
OpenStack. Dabei hat jede Methode spezifische Vorteile. Optimale Ergebnisse lassen
sich erzielen, wenn man beide Methoden
einsetzt.
Object Storage mit Swift: Swift kann Scaleout-Storage auf Standardhardware zur Verfügung stellen. Es ist eine Option für externe Speicherlösungen wie SAN-Umgebungen und damit für Anwendungen, bei
denen es auf geringe Kosten ankommt,
während die Performance weniger wichtig
ist – beispielsweise in der Archivierung.
Swift eignet sich für umfangreiche statische
Datenmengen, bei denen sequenzielle
Lese- und Schreibzugriffe erfolgen und ein
niedriger IOPS-Wert ausreichend ist.
Block Storage mit Cinder: Klassische Anwendungsfälle für diese Architektur sind
vor allem Performance-kritische Primärspeicher-Workloads, beispielsweise SQLoder NoSQL-Datenbanken oder Anwendungen in Bereichen wie Datenanalyse
oder Transaktionsverarbeitung. Cinder eignet sich für Daten, die häufig geändert werden, für Random-Lese- und -Schreibvorgänge sowie für Workloads, bei denen eine
hohe I/O-Performance benötigt wird.

Download Report