Kritik am Software Defined Data Center: Was ist das Ziel?

Kommentieren Drucken

Von der RZ-Konsolidierung zum Software Defined Data Center (SDDC): Was ist das Ziel? Sind wir auf einem Irrweg?

Auf den Marketing-Folien sieht das alles gut aus, wir marschieren Schritt für Schritt von den optimierten Servern über den Speicher und die Applikationen zum automatisierten Rechenzentrum der Zukunft. Das Software Defined Data Center legt die Basis für eine völlig neue Architektur von Rechenzentrum: 30 bis 50% weniger Kosten, hohe Flexibilität, schnelle Reaktion und zufriedene Anwender sind eine Mischung, der man sich wohl kaum entziehen kann. Oder doch?

Im Kern verfolgt das Software Defined Data Center Konzepte, die sich bei Cloud-Providern bewährt haben und diesen einen im direkten Vergleich mit dem traditionellen Rechenzentrum extrem wirtschaftlichen Betrieb erlauben. Die Fragen sind also:

  • Können wir das wirtschaftliche Erfolgsrezept der Cloud-Provider auf ein normales Rechenzentrum übertragen und von den tiefgehenden Technologie-Entwicklungen der Cloud-Provider profitieren?
  • Wo liegen die Potenziale, die Einsparungen von 30 bis 50 % realistisch erlauben?

Die wirtschaftlichen Vorteile verteilen sich dabei auf ganz verschiedene Kostenbereiche:

  • Senkung der Betriebskosten im Sinne von Personalkosten,
  • Optimierung der Leistung genau auf den Bedarf und den Bedarfszeitpunkt zugeschnitten,
  • Senkung des Energieverbrauchs durch eine maximal effiziente Nutzung der Ressourcen,
  • Optimierung des Server- und Speichereinsatzes im Sinne der Vermeidung unnötiger Überkapazitäten,
  • Schaffung von Spitzenlastkapazitäten, die sich über die verschiedenen Anwendungen ausgleichen.

Die erreichbaren Vorteile sind in der Tat beeindruckend. Sie vernebeln aber den langen technologischen Weg, der erforderlich ist. Tatsächlich müssen traditionelle Rechenzentren eine stufenweise Migration durchlaufen, die alle eingesetzten Technologien umfasst, bevor im letzten Schritt die angepriesenen Ziele erreicht werden können.

Der erste Schritt der Aufsetzung der Basis-Infrastrukturen ist bereits gewaltig, da er die Ablösung von Alttechnologien und den Einstieg in konsolidierte Server- und Speicherlösungen umfasst. Beispiele für Maßnahmen aus diesem Bereich sind:

  • Server-Konsolidierung durch Virtualisierung und gemeinsamer Nutzung von Ressourcen
  • Speicher-Konsolidierung durch Zentralisierung auf SAN und NAS unter Ausnutzung von Kapazitätsoptimierung durch Thin-Provisioning und Deduplizierung
  • Netzwerk-Konsolidierung durch Low-Lantency-Netzwerke zwischen Servern und Speichern (das sogenannte West-Ost-Netzwerk) mit hoher Bandbreite und unter Vermeidung jedmöglicher Engpässe

Die nächste Stufe der Basis-Automatisierung geht davon aus, dass Applikationen automatisch den Ressourcen zugeordnet werden und im laufenden Betrieb auch migriert werden können. Die erste Stufe ist dabei das Anlegen von weitgehenden Templates für die Applikations-Generierung und die Nutzung von wandernden virtuellen Maschinen. Schon in dieser Stufe stoßen wir auf eine ganze Reihe von Herausforderungen, da zum Beispiel traditionelle Netzwerke nur bedingt wandernde virtuelle Maschinen unter Beibehaltung von deren IP-Adressen über Layer-3-Grenzen unterstützen können.

Und so geht es weiter, bevor dann mit Open Stack endlich die Plattform umgesetzt wird, die wir als Cloud-Nutzer alle von Amazon oder Rackspace kennen. Wir erreichen Self-Service-Lösungen, bei denen Kunden im Sinne der Abteilungen im Unternehmen nur noch auf einen Knopf drücken und wenige Minuten später stehen die Infrastrukturen bereit und die jeweilige Applikation kann genutzt werden.

Der Zeitrahmen für eine derartige Migration wird mindestens drei bis fünf Jahre umfassen. Der Personal- und Kapitalaufwand wird dabei erheblich sein, da im Prinzip alle existierenden Anwendungen und Technologien angefasst und angepasst werden müssen.

Also alles ganz toll?

Nun, schon die technische Migration ist eine enorme Herausforderung. Unsere traditionellen RZ-Technologien sind auf eine solche Service-Architektur nicht ausgelegt und wir brauchen die stufenweise Umsetzung einer Orchestrierung, also eine Automatisierungsebene, die uns alle komplexen Schritte abnimmt und dabei auch Fehler in der Konfiguration vermeidet. Basis für diese Orchestrierung sind Software Defined Infrastructures (SDI), bei denen jede Form von Ressourcen auf Software-Basis konfiguriert und einem Dienst zugewiesen werden kann.

So einfach es sich anhört, so groß sind die Tücken im Detail. Zum Beispiel wird zur mandantenfähigen Nutzung von Hauptspeicher über verschiedene virtuelle Server hinweg Hardware-Unterstützung notwendig. Die üblichen Anbieter brauchen also eine entsprechende Chip-Architektur, die in der Regel von den CPU-Herstellern kommen wird. Intel hat diese auf dem gerade abgelaufenen IDF 2013 an einem Beispiel gezeigt, wir sind aber weit davon entfernt, dass dies als Massentechnologie vorliegt. Gleiches gilt für Software Defined Networks, bei denen wir noch mindestens drei bis fünf Jahre von dem Reifegrad entfernt sind, den wir wirklich brauchen.

Die bestehenden Technologiehürden machen RZ-Automatisierungen zum jetzigen Zeitpunkt nicht nur aufwändig und teuer, sie werfen auch die Frage auf, ob wir zum jetzigen Zeitpunkt zuverlässig auf zukunftsorientierte Technologien setzen können oder ob wir Gefahr laufen, in technologischen Sackgassen zu enden.

Mögliche Sackgassen sind aus heutiger Sicht:

  • Fehlende Kompatibilität der Lösungen zwischen Herstellern
  • Die notwendige Infrastruktur erreicht nicht den notwendigen Reifegrad..
  • Die Technologien erweisen sich als zu komplex für eine Massennutzung.
  • Die Orchestrierungs-Ebene kann so nicht umgesetzt werden.

Die technologischen Risiken sind also signifikant, alles andere wäre auch verwunderlich. Einsparungen in der angesprochenen Dimension fallen eben nicht als Wunder vom Himmel.

Aber das ist gar nicht das dominierende Problem!

Das zentrale Problem liegt in der Frage, ob die Unternehmen ein service-orientiertes Rechenzentrum wirklich wollen und wenn sie wollen, ob sie es auch umsetzen können. Diese Diskussion gibt es seit mindestens 20 Jahren und in dieser Zeit ist realistisch gesehen jeder weitergehende Ansatz gescheitert. Wir hatten zum Beispiel die Diskussion um die bei Harvard entwickelte Balanced Scorecard in den 90er Jahren. Die hat sich im großen Stil nie durchgesetzt. Dabei ist sie im Kern unverzichtbar für jede Service-Organisation. Man mag ihr einen anderen Namen geben, aber inhaltlich wird man große Teile umsetzen müssen, auch wenn das Abstraktionsniveau auf den ersten Blick abschreckend ist.

Die Kernfragen sind:

  • Sind unsere Rechenzentren wirklich organisatorisch so weit, dass sie ihre Leistungen in Form eines Service-Katalogs anbieten können?
  • Ist es gewünscht, dass Kunden aus den Abteilungen sich selber ihre Ressourcen Applikationen auswählen und starten?
  • Ist ein Rechenzentrum wirklich in der Lage, einen Preise für alle diese Services zu nennen und auch verbrauchsabhängig zu berechnen?
  • Ist der Kunde gewillt, eine Trennung zwischen Preis und Ressource zu akzeptieren?
Kritik am Software Defined Data Center: Was ist das Ziel?

Laufzeit des Originalvideos: 37:21

Ausschnitt aus dem Video: Service-Spezifikation

Die Service-Spezifikation ist das Fundament jeder erfolgreichen Service-Erbringung. Dieses Video erklärt wie eine Service-Spezifikation entsteht und wie sie stufenweise die Basis für alle Bausteine eines erfolgreichen Service-Betriebs legt.

Abonnenten von ComConsult-Study.tv können dort das vollständige Video in HD-Qualität sehen.

Das Dilemma des Kunden darf dabei nicht unterschätzt werden. Dabei geht es gar nicht um die wenigen großen Anwendungen eines Unternehmens wie SAP oder E-Mail. Es geht um die manchmal Tausenden von kleinen Spezialanwendungen, die auch im Kern das eigentliche Problem sind. Kaum ein Unternehmen hat Probleme damit, Exchange effizient zu betreiben (oder sollte es Probleme damit haben, dann ist das schnell lösbar). Was passiert mit der Vielzahl der kleineren Applikationen? Ein Beispiel aus der Vergangenheit: Eine Abteilung hat Geld für ein Projekt und sagt dem RZ, kauf mal einen Server und Speicher für diese Applikation und bring sie zum Laufen. In Zukunft müsste kein Server mehr gekauft werden, sondern ein Template müsste aufgesetzt werden, damit der Kunde seine Applikation eigenständig aktivieren, starten, optimieren und terminieren kann. Der Kunde bezahlt einen Preis für eine Leistung, die er nun nicht mehr bildlich greifen kann.

Damit ist eine Reihe von Fragen verbunden:

  • Werden gerade bei den vielen projektbasierenden Server-Installationen die Kunden bereit sein, auf „ihren“ Server, also speziell auf den Nachweis einer von ihrem Geld gekauften Ressource zu verzichten?
  • Lohnt sich der Aufwand der Automatisierung und Template-Erzeugung wirklich für jede kleine Applikation?
  • Wer berechnet eigentlich den Preis und wie erfolgt die Abrechnung?

Neben den technischen Hürden hat das Software Defined Data Center eine hohe technologische Hürde. Die ist nicht unlösbar, aber wie gesagt, dieses Problem der Schaffung und Umsetzung von Service-Katalogen ist nicht neu. Und bisher hat es kaum funktioniert. In diesem Sinne wird es Zeit, sich von der Technikdiskussion zu lösen und eine Service-Diskussion zu starten.

Bitte verstehen Sie mich nicht falsch: Die verfügbaren und kommenden Technologien liefern einen massiven Mehrwert. Und ich bin überzeugt davon, dass dieser Weg richtig ist. Aber ein Unternehmen, das in diese Technologien einsteigt, muss ein langfristiges und realistisches Ziel definieren. Und dabei steht die Frage, wollen wir ein service-orientiertes Rechenzentrum im Mittelpunkt. Wer diese Frage mit ja beantwortet, der kann diesen Weg jetzt starten. Wer die Antwort nicht weiß oder nein sagt, der muss Baustein für Baustein prüfen, welche der neuen Technologien für ihn Sinn machen oder nicht.

Damit kommen wir auch zum Fazit und den Empfehlungen von ComConsult Research:

  • Die Technologien, die sich um den Begriff „Software Defined Data Center“ ranken, werden in Stufen relevant für den Markt werden. Im Moment gehen wir von einem Zeitrahmen von drei bis fünf Jahren aus.
  • Gerade zu Beginn dieser Phase werden Projekte je nach Ziel aufwändiger und kostenintensiver sein als später mit einem höheren Reifegrad der Produkte.
  • Ein Einstieg in die Technik ohne die Festlegung eines langfristigen Zieles wird aller Voraussicht nach scheitern. Das Software Defined Data Center unterstellt implizit eine komplette Service-Orientierung der IT-Infrastruktur. Mit der Service-Orientierung sind eine ganze Reihe sehr komplexer Fragen verbunden.
  • Konsequenterweise startet dann auch der Einstieg in das Software Defined Data Center nicht mit der Technik sondern mit den organisatorischen Zielsetzungen: Wie stellt man sich das Rechenzentrum in fünf Jahren vor?

Wir diskutieren Technik und Services mit Ihnen auf unserem ComConsult Rechenzentrum Infrastruktur-Redesign Forum 2013.

zugeordnete Kategorien: Data Center, IT-Management, LAN
zugeordnete Tags: , , , , , , , ,

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.