Skip to content

Hinter Gittern

Posted by Bernd Eckenfels on
Computer sind kein Selbstzweck. Auch wenn diese aus den Geschäftsprozessen moderner Unternehmen und Organisationen nicht wegzuddenken sind, so ist die Hardware nur ein Betriebsmittel. Noch dazu ein Hilfsmittel das viele Kosten verursacht und Manpower bei der Wartung verschlingt. Dabei behindert das Thema Skalierbarkeit erheblich die Flexibilität eines Unternehmens. Rechner sind entweder überdimensioniert oder an den Kapazitätsgrenzen. Dabei wäre es ganz einfach, wenn man einen Pool von Ressourcen (Rechenzeit, Speicherplatz) hätte der alle IT-Systeme überspannt, dem man die Aufgaben flexibel zuweisen kann. Solche Ansätze kennt man aus den Storage Area Netzweren (SAN) mit entsprechenden Virtualisierungslösungen. Das Hinzufügen von Festplatten erweitert die Kapazität des Netzes, einzelne Anwendungen können den Platz dann dynamisch per Software hinzugefügt bekommen. Als vor 2 Jahren Oracle die erste Release ihrer Datenbank 10g angekündigt hat konnte noch nicht jeder etwas mit dem Begriff Grid anfangen. Im Moment bewirbt Oracle die Release 2 seiner Datenbank, und man kann sagen, dass sich der Begriff Enterprise Grid Computing deutlich weiter verbreitet hat. Nicht immer ist die Umsetzung von virtuellen Ressourcen zu physikalsichen so einfach wie bei einem SAN (und noch lange nicht jedes SAN ist so flexibel!). Im Bereich Rechenkapazität gibt es hier 3 Ansatzpukte:
  • Virtualisierung/Partitionierung
    Bei diesem Ansatz werden leistungsfähige Server in kleinere unterteilt. Die zugeteilten Ressourcen lassen sich dynamisch ändern. Alle Server und Betriebsystem Anbieter haben entsprechende Virtualisierungs und Partitionierungslösungen im Angebot. Interessant dabei ist auch, dass die virtuellen Instanzen meist Problemlos auf mehrere Rechner im Netzwerk verteilt werden können.
  • Verteilung/Multi-Tier
    Aus dem Bereich der technischen Forchung sind die Anwendungen bekannt, die numerische oder simmulations Probleme massiv Parallel auf einem Cluster von (Low Cost) Servern berechnen. Auch im Bereich der Enterprise Anwendungen gibt es Systeme die durch eine mehrschichtige Architektur sich einfach nach dem Scale-Out Ansatz installieren lassen. SAP nennt dies Agility Computing.
  • Netzwerktransparente Betriebsysteme
    Mit zunehmend schnelleren Netzwerkverbindungen und leistungsfähigeren Prozessor Interconnects (Hypertransport, etc) ist die Grenze zwischen vernetzten Rechnern und Multi-Prozessor Rechnern nicht mehr so strickt. Viele Betriebsysteme sind bereits darauf optimiert mit einer NUMA Architektur zurechtzukommen: dabei hat jeder Prozessor Hauptspeicher den er besonders schnell oder eher langsam erreichen kann. Entsprechend werden die Prozesse verteilt. Letzteres ist noch ein wenig die Domäne von Akademisch/Technischen Systemen.
Es gibt also sehr viele technische Faktoren die für den Erfolg des Grid Ansatzes verantwortlich sind. Vom SAN über die neuen CPU Generationen, neue Betriebsystem Fähigkeiten bis hin zu den Blade Servern. Der Grid Ansatz bringt aber auch eine Menge neuer Herausforderungen mit sich. Beim Scale-Out Ansatz nimmt die Anzahl der Systeme zu die pro Administrator gemanaged werden müssen, beim Scale-Up Ansatz nimmt die Anzahl der Anwendungen zu, deren Service Levels gemonitort und eingehalten werden müssen. Bei beiden Ansätzen wird es zunehmend schwieriger in den verteilten Systemen Fehler und deren Auswirkungen zu diagnostizieren. Daher ist es nicht verwunderlich dass Management Tools hier stark gefordert sind. Diese müssen mit der Hardware, dem Betriebsystem und vor allem den Anwendungen zusammenarbeiten. Das könnte man natürlich jetzt als ein rein technisches Problem der IT Abteilung und der Hardware Hersteller begreifen. Aber der Grund für eine Grid Architektur sind Anforderungen aus dem Business:
  • Enorme Nachfrage nach weiteren Kapazitäten (RFID, BI, E-Commerce. Der Storage Markt wächst jährlich zweistellig)
  • Verfügbarkeit (24/h, Globalisierung)
  • Alignment (schnelle Umsetzung von neuen Business Konzepten oder M&As)
. Dies ist auch der Grund für diesen Artikel: ich habe analysiert wie das Grid Computing die Geschäftsanwendungen und die Middleware verändert. Insbesondere welche Schritte Independent Software Vendors planen müssen um den Erwartungen Ihrer Kunden (getrieben durch den Trend) gerecht zu werden. Für den Anbieter von Software die in einem Enterprise Grid laufen soll bietet es sich an im Bereich Storage auf Datenbanken zu setzen, damit ist die Grid Umgebung schon erheblich abstrahiert. Man kann ja bei Oracle deutlich ablesen wie viel Aufwand hier notwendig ist. Im Bereich der Systemlandschaft ist es unabdingbar auf Netzwerktransparente Verteilung von Komponente zu setzen. Hier ist es sicherlich positiv, wenn man Architekturprinzipien wie SOA oder EDA umsetzt, oder auf Middleware wie ESB setzt. Grid Tools unterstützen das Monitoring, Exception Handling, Workload Management, Auditing, Security und die Software Verteilung. Leider gibt es hier aber keine einheitlichen Schnittstellen. Je komplexer die Anwendung ist, desto schwieriger wird es vorbereitet zu sein auf die Umgebung der potentiellen Kunden. Hier bietet sich eine zweigleisige Vorgehensweise an: zum einen die Infrastruktur der Anwendung vorbereiten auf eine verteilte Installation, die Management und Monitoring Schnittstellen ausbauen. Gleichzeitig bei der Umsetzung auf Grid Plattformen auf den Zuruf der Kunden warten. Ein Software System mit sauberer Architektur lässt sich unter Umständen auch von Beratern die sich mit dem Grid System auskennen selbst integrieren, ohne dass der Software Hersteller diese explizit unterstützen muss. Es erleichtert natürlich ungemein, wenn die Anwendung bereits auf einer Abstraktionsschicht aufsetzt die den Lifecycle abnimmt (z.B. das Deployment in Appservern). Nicht umsonst setzt SAP bei seinem Adaptiven Computing ganz auf die NetWeaver Plattform. Dass Microsoft in diesem Artikel bisher nicht genannt wude ist übrigens kein Zufall. Dies hängt aber weniger damit zusammen, dass Microsoft im Bereich Grid Computing nichts zu bieten hat, sondern eher damit dass man in Redmond etwas Scheu ist, und sich kein Label aufdrücken lässt. Alles im Bereich .NET und Nachfolger (Vista, Indigo, VirtualServer) geht in diese Richtung, man bleibt aber sehr stark im eigenen Öko-System. Bei Microsoft verstecken sich die Technologien hinter Begriffen wie High Performance- oder Distributed Computing. Und weil ich in dem Artikel auch nichts über on-Demand oder utility computing geschrieben habe, hier noch ein Artikel der all die Technolgien und Ansätze ins richtige Verhältniss setzt: The Different Faces of IT as Service Queue, July/August 2005, Dr. Ian Foster and Steve Tuecke. Zum Weiterlesen

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

No comments

Add Comment

BBCode format allowed
Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
To leave a comment you must approve it via e-mail, which will be sent to your address after submission.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA