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

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. Liegt darin die Zukunft oder ist es ein Irrweg?

Anbieter zum Thema

AixpertSoft GmbH

Fujitsu Technology Solutions GmbH

FNT GmbH

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 relevanten Fragen sind also:
Können wir das wirtschaftliche Erfolgs-Rezept der Cloud-Provider auf ein normales Rechenzentrum übertragen und von den tiefgehenden Technologie-Entwicklungen der Cloud-Provider profitieren und wo liegen die Potenziale, die Einsparungen von 30 bis 50% realistisch erlauben?

Die wirtschaftlichen Vorteile verteilen sich dabei auf ganz verschiedene Kostenbereiche, als da wären: Die Senkung der Betriebskosten im Sinne von Personalkosten, die Optimierung der Leistung genau auf den Bedarf und den Bedarfszeitpunkt zugeschnitten, die Senkung des Energieverbrauchs durch eine maximale oder effiziente Nutzung der Ressourcen, die Optimierung des Server und Speichereinsatzes im Sinne der Vermeidung unnötiger Überkapazitäten und last but not least: Die Schaffung von Spitzenlastkapazitäten, die sich über die diversen Anwendungen ausgleichen.

Der lange technische Weg wird oft vernebelt

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.

Die Migration erfordert mindestens drei bis fünf Jahre

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.

Der Teufel steckt im Detail

Jedoch: 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 Technologie-Hürden machen RZ-Automatisierungen zum jetzigen Zeitpunkt nicht nur aufwendig 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.

(ID:42367468)