Schlüsseltechnologien für die Zukunft unserer IT-Infrastrukturen: SSD und HTML5

Kommentieren Drucken

Zur Zeit wird viel über Veränderungen in unseren IT-Architekturen diskutiert. Das beginnt mit einfachen Konzepten wie Virtualisierung und endet mit sehr komplexen Themen wie den Private Clouds. Dabei wird gerne übersehen, dass die Entwicklung hin zu neuen Architekturen häufig von wenigen Schlüssel-Technologien abhängt. Ohne diese Technologien sind Teile der Architektur-Veränderungen nicht realisierbar. Dabei kann man mindestens zwischen Verhinderungs- und Meilenstein-Technologien unterscheiden. Eine Verhinderungs-Technologie hat das Potenzial, technologische Veränderungen komplett zu blockieren. Eine Meilenstein-Technologie verändert die Rahmenbedingungen so stark, dass sich völlig neue Architektur-Ansätze ergeben können. An dieser Stelle wollen wir deshalb HTML5 als Verhinderungs-Technologie und SSD als Meilenstein-Technologie diskutieren.

Beginnen wir mit den Solid State Drives (SSD), die in immer größerer Kapazität, mit immer mehr Leistung und mit weiter sinkenden Preisen auf den Markt kommen. Entsprechend der zunehmenden Bedeutung von SSDs wird auch über optimierte Schnittstellen zur Integration in die System-Architektur diskutiert, um das volle Leistungsniveau ausnutzen zu können. SATA und SCSI blockieren diese Technologie auf Dauer. Mit neuen Schnittstellen wird noch einmal ein Sprung in der erreichbaren Leistung kommen. Naturgemäß wird dem Hersteller Intel bei der Entwicklung dieser Schnittstellen eine große Marktbedeutung zukommen. Auf Dauer wird sich die Frage stellen, ob diese Schnittstellen in das CPU-Design integriert werden müssen (siehe die diversen Kommunikations-Schnittstellen des Nehalem). Aber auch die anderen SSD-Hersteller wie OCZ puschen zurzeit aktiv diese Technologien (OCZ nennt seine Technik HSDL, dahinter verbirgt sich eine Multilane PCIe-Variante). Schnittstellen-Datenraten von bis zu 40 Gigabit/s müssen jeden Infrastruktur-Verantwortlichen sofort aufhorchen lassen. Was ist, wenn diese Datenrate so wie bisher bei SATA und FC über ein Datennetzwerk übertragen werden muss? HSDL over Ethernet?

Was sind SSDs?
SSDs ist ein Massenspeicher-Typ, der in direkter Konkurrenz zu Festplatten steht, aber im Gegensatz zu diesen komplett auf Chips basiert. Im Prinzip ist diese Art von Speicher aus den iPods und iPhones gut bekannt. Der Verzicht auf bewegliche Teile und die Möglichkeit der direkten Adressierung des kompletten Inhalts ohne die Bewegung eines Lese-/Schreibkopfes bringt ein völlig neues Niveau von Durchsatz und auch Zugriffszeiten. Gute SSD-Lösungen bringen Durchsatzraten im Lesen und im Schreiben von über 250 MB/s und I/O-Raten von mehr als 50000 IOPS. Zugriffszeiten auf Datenblöcke liegen im 0,1 ms-Bereich und besser. Parallelisiert man SSD-Chips so wie es in einigen PCI-basierten Lösungen erfolgt, werden auch Durchsatzraten von 500 MB/s mit bisheriger Technik erreicht. Dabei sinkt aber durch die Parallelschaltung naturgemäß die Verfügbarkeit im Sinne der MTBF-Rate. Die Verfügbarkeit hängt dabei allgemein vom verwendeten Chiptyp ab. Wir unterscheiden dabei SLC und MLC. SLC-Chips sind deutlich hochwertiger (und teurer) und erreichen 10 Millionen Stunden MTBF. MLC liegen häufig nur zwischen 1 und 2 Millionen Stunden, sind also nur geringfügig besser als sehr gute Enterprise-Festplatten. SSDs haben System-bedingte Einschränkungen, die aber in diesem Zusammenhang keine Rolle spielen und im Wesentlichen die Preisdifferenzen zwischen den Produkten begründen.

Warum interessiert das überhaupt?
Seit den ersten Grundzügen von PC-Netzen mit Client-Server-Lösungen gibt es die Grundregel, dass jede Verlagerung von Plattenspeicher in einen Server aus einem Client die Leistung des Clients nicht mindern darf. Genauso gilt die Regel, dass die Verlagerung von Festplatten aus einem Server zu einem SAN den Server nicht langsamer machen darf. Nur unter dieser Rahmenbedingung werden die Verantwortlichen für Clients, Server oder bestimmte Applikationen einer Auslagerung von Daten zustimmen. Und dies hat bisher auch gut und mit erstaunlich hoher Leistung funktioniert. Auch alle Lösungsansätze zur Virtualisierung von Servern basieren auf dieser Idee. Hier haben wir gerade erst den Zustand erreicht, dass auch Hochleistungsserver mit 10 Gigabit-Ethernet ohne Probleme auf einer SAN-Lösung aufsetzen können, ohne dabei signifikante Leistungsverluste zu haben.

SSDs stellen dieses Grundprinzip von Client-Server- und Server-SAN-Architekturen in Frage! Mit einer SSD-Lösung werden Clients und auch Server in sich so schnell, dass der Zugriff auf externe Daten im Vergleich dazu zu einem Problem wird. Für Performance-Interessierte sei auf folgenden Link verwiesen: http://www.tomshardware.com/reviews/ocz-ibis-hsdl-high-speed-data-link,2754-6.html,

Ist dieses Problem unlösbar?
Nein. Man kann die Zugriffszeiten und Durchsatzraten von SSDs natürlich genau analysieren und dann fragen, mit welcher Netzwerk und SAN-Lösung eine vergleichbare Lösung gefunden werden kann (ich verweise auf die Artikel von Dr. Kauffels, die im letzten Jahr im Insider erschienen sind). Und zumindest für das Rechenzentrum ist die Lösung mit den neuen und modernen Switch-Generationen möglich. Ältere Switch-Generationen wie der Catalyst 6500 kommen hier tatsächlich an ihre Grenzen. Die Folgegenerationen wie der Nexus bei Cisco, aber auch die vergleichbaren Switch-Systeme bei den anderen Anbietern, sind viel mehr als bisher auf Latency optimiert. Tatsächlich kann bei gleichzeitigem Einsatz neuer Netzwerk-Architekturen wie Trill und in Kombination mit neuen Verfahren wie DCB eine kontrollierbare Leistung im Netzwerk erreicht werden, die auch ein SSD-Niveau mit Bezug auf Datenraten und Latency ohne Probleme erreicht. Tatsächlich verschiebt sich das Problem damit zum SAN selber, da auch hier entsprechende Optimierungs-Aufgaben anstehen. Vermutlich werden die SAN-Hersteller warten, bis eine neue Schnittstelle zur SSD-Integration in die SAN-Architektur standardisiert ist.

Nicht so gut lösbar ist das Verhältnis zwischen Client und Server. Hier wird eine SSD-Leistung durch die Anzahl der dazwischen liegenden Switch-Systeme und den Wechsel zwischen Layer 2 und Layer 3 nur bedingt erreicht werden können. Nun fahren nur sehr wenige Client-Systeme lokale Datenbank-Anwendungen, die von den niedrigen Zugriffszeiten einer SSD profitieren würden. Solange also nur normale Office-Anwendungen weiterhin lokal installiert sind, wird sich kein Leistungsnachteil ergeben (gefühlt schon, da die Anwendungen schneller reagieren, aber das ist im Sinne der Unternehmensziele ein verzichtbarer Zugewinn).

Damit sind wir bei der zweiten Schlüsseltechnologie: HTML5. HTML5 müsste eigentlich in den Unternehmen im Mittelpunkt einer heißen und intensiven Diskussion stehen. Umso mehr ist es verwunderlich, dass es zwar auf Experten-Ebene diskutiert wird, aber nicht auf der Führungsebene. Dabei gilt:

  • Private Clouds ohne HTML5 sind nicht glaubwürdig
  • HTML5 macht Desktop-Virtualisierung überflüssig, jeder Schritt in diese Richtung ist pure Geldverschwendung
  • Browser erreichen erst mit HTML5 einen gewissen Grad an Interoperabilität

Worum geht es?
Wir haben einen Trend hin zu Web-Applikationen. Dabei läuft die eigentliche Applikation in einer komplexen Server-Architektur (die häufig fahrlässig unterschätzt wird) und der Client basiert komplett auf einem Browser wie Firefox oder auch Internet Explorer. (siehe Abbildung 1)

Nun sind Browser bisher keine tragfähige Basis für komplexere Anwendungen. Die Weiterentwicklung von HTML und CSS hat sich über Jahre verzögert. Der schon peinliche und bisher grottenschlechte Internet Explorer hat jede Umsetzung erfolgreicher Client-Lösungen verhindert (ein Schelm, wer Böses dabei denkt). Microsoft ist es damit über mehr als 10 Jahre gelungen, diese wichtige Entwicklung zu beeinträchtigen. Allerdings um den Preis eines stark gesunkenen Marktanteils des Internet Explorers. Erst der Einstieg von Google in diesen Markt hat offenbar ein Umdenken auf der Microsoft-Seite bewirkt.

Mit HTML5 wird fast alles anders!
Mit HTML5 entsteht zum ersten Mal eine Situation im Browser-Markt, bei der die Leistungen der einzelnen Browser sehr nahe zusammen liegt. Alle Hersteller, also auch Microsoft, konzentrieren sich viel mehr als bisher auf Interoperabilitäts-Gesichtspunkte. Gerade Microsoft hat mit dem Internet Explorer 9 einen großen Schritt nach vorne gemacht. Damit entsteht endlich die Basis, die alten IE6 und IE7-Varianten, die Generationen von Web-Entwicklern in die pure Verzweiflung getrieben haben, aus den Clients zu entfernen. Der Update auf Internet Explorer 9 sollte für alle Kunden eine hohe Priorität haben (das Video Webtechnologien bei ComConsult-Study.tv zeigt Beispiele zu Unterschieden der Umsetzung von CSS-Kommandos mit IE6 und IE7 im Vergleich zu einem Standard-konformen Browser wie Firefox oder Safari).

Gleichzeitig beinhaltet HTML5 endlich die Funktionsbereiche, mit der eine Client-Lösung so programmiert werden kann, dass sie einer lokal installierten Lösung sehr nahe kommt. Wichtig dabei sind:

  • 2D-Grafik
  • Video und Sprach-Integration
  • Lokale Speicherung von Daten bis hin zur Offline-Nutzung

Teile davon waren bisher schon durch Nutzung von Plugins möglich. So hat Adobe mit Flash speziell bedingt durch den Mangel innerhalb von HTML und durch die großen Unterschiede zwischen den Browsern seinen 98%-Marktanteil auf den Clients erreicht. Microsoft hat mit Silverlight nachgezogen und stellt sich in der aktuellen Version auch der sehr kontrovers zu diskutierenden Frage des Zugriffs auf lokale Ressourcen (was für wichtige Anwendungen wie IP-Telefonie und Videokonferenz mit Web-Clienten eine elementare Voraussetzung ist).

Wie hoch ist der Stellenwert für unsere Infrastrukturen?
Wie schon zuvor erwähnt, machen Desktop-Virtualisierung und die Einführung von Web-Applikationen als Teil von Private Clouds ohne HTML5 eigentlich keinen Sinn. Hinter Desktop-Virtualisierung steht ja die Grundidee der traditionellen Applikation, deren Installationsort nur per Virtualisierung zum Server verschoben wird. Die Wirtschaftlichkeit dieses Konzeptes an sich muss für viele Installationen (nicht für alle) tatsächlich in Frage gestellt werden. Mit einem stufenweisen Wechsel auf Webapplikationen in den nächsten Jahren stellt sich Desktop-Virtualisierung dann auch schnell als Sackgasse und Geldverschwendung heraus (Ausnahme sind möglich zum Beispiel im Bereich einfacher Anwendungen wie sie typisch für Banken und Versicherungen sind). Wer an Web-Applikationen glaubt, für den muss Desktop-Virtualisierung eine No-Go-Zone sein.

Setzen sich Web-Applikationen wirklich durch?
Das hängt von der Applikation ab. Tatsächlich aber gibt es auf der Seite der Applikationsentwickler erhebliche Vorteile beim Umstieg auf Web-Applikationen:

  • Keine Pflege verschiedener Versionen mehr
  • Keine Probleme mit Installationen und Kundenspezifischen-Umgebungen
  • Stark vereinfachte Lizenz-Modelle

Betrachtet man diese Vorteile, dann wird auch klar, dass der Anwender in Zukunft von einer stark steigenden Zahl von Web-Applikationen ausgehen muss. Die Entwickler der entsprechenden Applikationen werden den Markt im Endeffekt auf diesen Weg zwingen. Wir sprechen hier von einem Prozess, der leicht 5 weitere Jahre erfordern wird. Das bedeutet nicht, dass das auch für den Anwender generell gut ist. Im Gegenteil gibt es bisher noch eine ganze Reihe großer Stolpersteine, ein typisches Beispiel ist die Benutzerverwaltung über mehrere Web-Applikationen hinweg.
Warum gerade jetzt?

Jeder, der in der Vergangenheit Web-Applikationen entwickeln wollte, stieß auf eine erhebliche Technologie-Unsicherheit. Jede Entscheidung für eine Entwicklungs-Umgebung war mit dem Risiko behaftet, dass die jeweilige Technologie schon nach kurzer Zeit wieder vom Markt verschwindet. Parallel war der Aufwand in der Entwicklung von Web-Applikationen zum Teil astronomisch. Fehlende Funktionen und die dramatischen Unterschiede zischen den Browsern in Kombination mit Web-Verhinderungs-Browsern wie IE6 und IE7 haben diesen Zug sehr lange aufgehalten.

Doch das ist jetzt zu einem großen Teil vorbei. Zwar bleibt noch genügend Tool-Unsicherheit übrig (welches Content-Management-System wird überleben, welche Objekt-Architektur setzt sich durch, welcher Browser wird konkret welche Objektbereiche von HTML5 wie unterstützen, …), doch wesentliche Probleme sind mit HTML5 und der breiten Unterstützung durch alle Hersteller aus dem Wege geschafft.

Was bedeutet das für unsere Infrastrukturen?

Vereinfacht ausgedrückt erleben wir damit eine weitere Zentralisierungs-Welle weg von den Clients und hin zu den Servern. Im Endeffekt findet jetzt eine Entwicklung statt, die SUN vor 10 Jahren angestrebt hatte. Parallel sind „normale“ Server mit diesen Lösungen überfordert. Web-Applikationen basieren auf Web-Architekturen. Diese wiederum auf vielen kleinen verteilten virtuellen Maschinen, die intensiv untereinander kommunizieren.

Damit ist klar:

  • HTML5 legt die Basis für Web-Applikationen
  • Diese machen Desktop-Virtualisierung überflüssig
  • Damit verschiebt sich die ganze Komplexität ins Rechenzentrum
  • Dort bekommt das Netzwerk Systembus-Charakter, da Inter-Prozess-Kommunikation über das Datennetzwerk hinweg stattfinden muss
  • Der traditionelle Backbone wird gleichzeitig zumindest in diesem Bereich entlastet
  • Parallel entstehen durch die starke Zentralisierung neue Anforderungen an Standort-Absicherung und Desaster Recovery. Damit entstehen neue Anforderungen an den Backbone

Fasst man diese Entwicklungen zusammen, dann ergeben sich auf der Netzwerk-Ebene folgende Herausforderungen:

  • Low Latency-Netzwerke im Rechenzentrum müssen in den nächsten 5 Jahren kommen
  • Es kommen definitiv neue Anforderungen an Speicher-Systeme mit Durchsatzraten jenseits von 10 Gbit/s pro „Platte“
  • 10/40/100 Gigabit-Ethernet, Trill/SPB, DCB und Low-Latency-Switches werden KO-Kriterien für die Komponenten-Auswahl. Tatsächlich wird es eine Nutzung von mehr als 10 Gbit/s im Rechenzentrum geben
  • Es entsteht eine neue Diskussion um Layer-3 im Backbone. Welchen Sinn macht das überhaupt noch, wenn immer mehr Anwendungen zentralisiert werden und gleichzeitig traditionelle Risiko-Bereiche verschwinden? Dies wird flankiert von den aktuellen Änderungen im Layer-2-Bereich. TRILL/SPB und DCB sind sehr leistungsfähige Technologien. Der gute alte Spanning Tree sieht im Vergleich dazu aus wie ein blattgefederter LKW mit 50 PS Leistung im Vergleich zu einem modernen Audi, BMW, Porsche, VW (was immer Sie bevorzugen). Übrigens führt auch die Diskussion über die Migration zu IPv6 zwangsläufig zu dieser Frage

Was ist das Fazit?
Das Fazit ist, dass viele der aktuellen Diskussionen viel zu abgehoben und abstrakt erfolgen. Typische Beispiele sind Private Clouds und Virtualisierung. Dabei wird sehr häufig einfach übersehen, dass die Weiterentwicklung unserer IT-Architekturen von wenigen, aber entscheidenden Schlüssel-Technologien abhängt. Diese wiederum haben erhebliche Rückwirkungen auf unsere Infrastrukturen. Dieser Zusammenhang muss viel stärker als bisher berücksichtigt werden.

zugeordnete Kategorien: LAN, Web-Techniken
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.

*

.