Von: Philipp von Wallenberg
Der Trend des Web Enabling führt dazu, dass die Content-Anbieter immer mehr IT-Systeme miteinander verbinden. Gehen sie dabei planlos vor, können sie ihrer Systeme langfristig weder betreiben noch erweitern. Sie stellen eine ständig wachsende Zahl unternehmenskritischer Prozesse auf zunehmend instabile Füße und erzeugen damit ein inakzeptables technisches und kaufmännisches Risiko. Modulares IT-Design ist ein Ansatz, der die Unternehmen die Vorteile des Web Enabling ohne Gefahr nutzen lässt.
In vielen technischen Bereichen steht ein modulares Vorgehen beim Entwurf, der Implementierung, dem Betrieb und der Erweiterung von Lösungen außer Frage. Auch in der IT sind häufig modulare Ansätze zu finden, wenn es um das Software- oder Hardwaredesign geht. Das Zusammenspiel komplexer Applikationen mit verschiedenen Betriebssystemen, die auf unterschiedlichen Rechnern laufen, wäre ohne eine strenge Zerlegung in Komponenten kaum denkbar. Der Sinn von Modulen ist offensichtlich: Die einzelnen Teile lassen sich im Idealfall einzeln implementieren und ändern, ohne dass das Gesamtsystem davon betroffen ist.
Aktuelle IT-Strukturen dagegen verwenden zwar Module. Jedoch sind diese oft herstellerspezifisch und gegenüber den anderen Teilen einer IT-Infrastruktur isoliert. Bausteine mit gleichen Funktionen wie zum Beispiel Datenspeicher sind mehrfach implementiert, was den Betrieb und Erweiterungen erschwert. Diese Art von Systemen konnte aus zwei Gründen entstehen:
- Bis vor kurzem war es nicht erforderlich, IT-Systeme aus verschiedenen Bereichen funktional miteinander zu verknüpfen. Sie standen isoliert nebeneinander, ohne dass das eine System einen nativen Zugriff auf die Daten des anderen hatte;
- eine IT-Struktur bestand aus zwei Arten von Komponenten, nämlich aus Clients und Servern. Die Verbindung zwischen den beiden stellten Administratoren mithilfe von Produkten jeweils eines Anbieters her. Damit versuchten sie Kompatibilitätsprobleme zu vermeiden.
Klassische Architektur stößt an Grenzen
Im Umfeld des Client-/Server-Computing gibt es keinen Zwang zu einem modularen IT-Design. Allerdings birgt die klassische Architekturvariante zwei grundlegende Nachteile. Erstens kann ein Service keine Daten eines anderen benutzen, um sie mit seinen eigenen Daten zu kombinieren. Die Grenzen der Automation treten hier deutlich zu Tage. Das Zusammenführen der Daten geschieht meistens erst manuell auf dem Client, beispielsweise wenn die Marketingabteilung Daten aus einer Host-Emulation einführt, um sie anschließend in ein Serienfax zu übertragen.
Zweitens benötigen die Clients eine spezielle Software. Diese steht selten für jede Geräteart zur Verfügung. Insbesondere in einer heterogenen Umgebung aus Unix-Maschinen, PCs, Handheld Devices und Hand-scannern oder Lagerverwaltungs-Terminals wird die Suche nach einer passenden Clientsoftware zum Problem. Zudem können Clientprogramme die Stabilität von Rechnern beeinträchtigen.
Diese beiden Probleme, die mangelnde Integration der Services und die Abhängigkeit von spezieller Clientsoftware, führen zum verstärkten Einsatz von Webtechniken im Firmennetz; ein folgerichtiger Schritt, weil das Web beide Probleme des Client-/Server-Computings löst. Ein Portal kann Daten aus verschiedenen Quellen zusammenführen. Und die Webclients, die über offene Protokolle wie HTTP auf das Portal zugreifen, funktionieren auf allen Plattformen.
Anstelle der gelösten Probleme tauchen nun aber zwei neue Hürden auf, die nicht sofort ins Auge stechen. Zum einen sind mehr Hersteller in der IT-Infrastruktur vertreten als zuvor. Zum andern sind die Systeme voneinander abhängig, weil Teile von ihnen in Reihe geschaltet sind. Webapplikationen greifen gleichzeitig auf mehrere Datenquellen zu.
Damit also das Marketing aus der Kundenliste ihrer Host-Applikationen ein Serienfax generieren kann, müssen der Webserver, der Application-Server, der Host und der Faxserver gleichzeitig verfügbar sein. Fällt eine Komponente aus, unterbricht sie den Service.
Viele Betreiber setzen zusätzliche Techniken ein, damit sie derartige Ausfälle verhindern und die Performance des gesamten Systems steigern. Diese fügen sie zwischen die einzelnen Komponenten ihrer Lösung ein, und zwar so, dass sie aus Sicht der Applikationen transparent sind. Dennoch greifen die Erweiterungen auf der Anwendungsebene in das Geschehen ein. Das bedeutet, dass das Zusammenspiel zwischen den unsichtbaren Zusätzen und den Applikationen auf allen Maschinen funktionieren muss. Fatale Auswirkungen hat beispielsweise ein Objekt, das als "cacheable" markiert ist, obwohl es dynamische Daten enthält, die der Content Switch zur Lastverteilung benötigt.
Das Resultat der Erweiterung ist eine Reihenschaltung aus applikationssensitiven Komponenten, die transparente und nicht transparente Komponenten verschiedener Hersteller miteinander mischt und offene mit proprietären Protokollen kombiniert. Auch wirken darin Standardprogramme und eigene Applikationen zusammen.
Webanwendungen brauchen Module
Wer komplexe Systementwicklung im Bereich des Webcomputing betreibt, sollte die bewährten modularen Vorgehensweisen aus anderen Bereichen übernehmen. Zunächst sollte der Entwickler klären, welche Schnittstellen zwischen den einzelnen Funktionsblöcken liegen sollen. Ideal sind Applikationsprotokolle, wie sie in den RFC-Standards (Request for Comment) festgelegt sind. Ihre Datenpakete lassen sich ohne Systemeingriff mit Netzwerk-Sniffern analysieren. Die Normen sind nicht an bestimmte Maschinentypen gebunden und ermöglichen es dem Programmierer, einzelne Module auf verschiedene Rechner zu verteilen.
Auch die Netzwerk- und Security-Verantwortlichen sollten beim Design eine zentrale Rolle übernehmen. Nur eine wohl überlegte Auswahl möglichst offener Applikationsprotokolle nutzt die Vorteile der Modularität einer IT-Architektur wirklich aus. Es bleibt noch die Frage nach dem Ablauf des Design-prozesses eines in Komponenten zerlegten Systems. Dieser läuft immer immer in drei Phasen ab. Am Anfang steht die Analyse, danach folgen die Synthese und die Skalierung.
In der Analyse teilt der Planer die Gesamtfunktionalität in unabhängige funktionale Blöcke auf. Dabei sollte er sich hinsichtlich der Art und des Umfangs der Komponenten an vorhandenen Produktkategorien oder Lösungen orientieren, ohne schon konkret ein bestimmtes Produkt ins Auge zu fassen. Andernfalls erhält er eine zu grobe oder zu feine Modularisierung, die er nicht verwenden kann. Das Projektteam evaluiert, welche Verbindungsmöglichkeiten zwischen den einzelnen Teilen denkbar sind. Es muss darauf achten, möglichst verfügbare Lösungen, offene Standards und gut dokumentierte Schnittstellen zu wählen. Sonst steigt der Aufwand für die Implementierung und spätere Änderungen. Im ersten Schritt werden die Blöcke bereits in der gewünschten Weise angeordnet und miteinander verbunden.
Während der Synthesephase ersetzen die Konstrukteure die abstrakten Funktionsblöcke durch reale Produkte. Dazu erstellen sie zunächst für jede Funktion eine Liste der verfügbaren Produkte. Diese verfügen im Gegensatz zu ihren theoretischen Vorläufern nicht über alle erdenklichen Verbindungsmöglichkeiten, sondern nur über eine Untermenge, die der Hersteller implementiert hat. Durch Einsetzen dieser "realen" Funktionsblöcke ist ersichtlich, ob ein durchgängiger Datenzugriff vom Frontend bis ins Backend möglich ist.
Zudem kann es in dieser Phase passieren, dass der Planer angrenzende Funktionsblöcke vereinigt und damit die Modularität wieder verringert. Dieser Schritt ist nur dann möglich, wenn die entsprechenden Produkte vom gleichen Hersteller stammen oder die Funktion beider Blöcke durch ein Produkt umgesetzt werden.
Die dritte Phase der Skalierung dient dazu, das Ergebnis der Planung in einem dynamischen Funktions- und Lasttest zu prüfen. Dabei untersuchen die Tester, ob der Datentransport zwischen dem Frontend und dem Backend schnell genug erfolgt. Auch die Leistungsfähigkeit der einzelnen Komponenten wird unter die Lupe genommen. Mithilfe der Leistungsdaten legen die Planer die Größe der einzelnen Maschinen und ihre Skalierungsmethodik fest. Dabei ziehen sie auch die Ausfallsicherheit ins Kalkül.
Lastenausgleich erhöht Flexibilität
In Webarchitekturen garantieren zwischengeschaltete Load-Balancer die Skalierbarkeit von Durchgangskomponenten wie Webservern oder SSL-Beschleunigern. Sie legen den Ort und die Implementierungsart der Teile nicht fest und erlauben auch Mischformen. Diese Technik bietet im Gegensatz zum Clustering die Möglichkeit, nicht nur die Rechenleistung, sondern auch die Netzwerkbandbreite des Services nahezu beliebig zu steigern. Die Load-Balancer selbst können wiederum wie Funktionsmodule behandelt werden. Mehrere Instanzen lassen sich zu einer einzigen vereinigen.
Bei terminierenden Komponenten wie Storage-Systemen oder Datenbanken nutzt man hingegen Cluster-Techniken. An dieser Stelle sind Migrationen unwahrscheinlich. Finden sie dennoch statt, müssen sie meistens auch das verbindende Protokoll durch ein neues ersetzen. Eine Virtualisierung durch Load-Balancing ist daher sinnlos. Zudem geht es bei diesen Endpunkten vor allem um die Skalierung von Rechenleistung und Plattenplatz. Die Netzwerkbandbreite - im Backend ohnehin geringer - spielt hier kaum eine Rolle. Weil Clustertechniken keine separaten Funktionen sind, sondern immer an die jeweiligen Server gebunden bleiben, stellen sie keine eigenen Funktionsblöcke dar und lassen sich nicht vereinigen.
Das Ergebnis dieser Designmethode und der Skalierungstechniken ist ein System, das sowohl qualitativ als auch quantitativ in Komponenten aufgeteilt ist. Es ist qualitativ modular, weil die einzelnen Funktionen in separaten Blöcken implementiert sind und nur über standardisierte oder gut bekannte Protokolle miteinander kommunizieren. So können die Entwickler einzelne Funktionsblöcke jederzeit ändern oder erweitern, ohne dass sie an anderen Stellen eingreifen müssen. Die Load-Balancing-Komponenten leiten dabei Anfragen anhand des verwendeten Protokolls oder des Inhalts der Anfrage an die neuen Funktionsblöcke weiter.
Die Funktionsblöcke sind zudem quantitativ modular, weil durch Load-Balancing und Clustering eine Skalierung außerhalb der Box möglich ist. Wer die Leistung steigern will, braucht dem Funktionsblock nur weitere Maschinen hinzuzufügen. Es bleibt ihm erspart, bestehende Rechner vor der Abschreibung zu ersetzen oder von vornherein teure, in sich erweiterbare Maschinen zu kaufen. Somit garantiert das modulare Konzept die Skalierbarkeit jedes einzelnen Funktionsblocks. Damit stimmt nicht nur die Performance. Auch die Ausfallsicherheit der Systeme ist damit gewährleistet. (kpl)
Zur Person
Philipp von Wallenberg
studierte Nachrichtentechnik an der TU Hannover. Als Mitarbeiter der Firma CC Compunet entwickelt er seit zwei Jahren Produkte im Bereich Business Development für Web Computing.