Das Problem Skalierbarkeit
Artikel erschienen in Swiss IT Magazine 2003/07
Es ist gerade mal gute 16 Jahre her, dass ich stolz meinen ersten PC mit damals tollen 640 Kilobyte Hauptspeicher - weniger als 1 Promille dessen, was heute in meinem Notebook installiert ist - erworben habe. Und auch die Festplatte hatte nicht einmal 1/1000 der Grösse meiner heutigen Festplatte. Ich kann mich auch noch gut an Diskussionen erinnern, wonach Windows NT mit 16 oder 32 MB Hauptspeicher doch eigentlich recht wenig leisten würde, wenn man es mit einem der damals gängigen Grossrechner vergleichen würde. Das ist gut zehn Jahre her. Und während 1992 ein 5-Prozessor-System von Sequent ein Riesengerät war und viel bestaunt wurde, sind heute Cluster aus 32-Wege-Systemen keineswegs exotisch - so wenig wie Serverfarmen mit Hunderten von Systemen.
Der Bedarf für immer mehr Rechenleistung ist offensichtlich, auch wenn er keineswegs in jedem Anwendungsbereich besteht. Wer einen einfachen File-Server betreibt, kann mit Windows NT 4.0, 128 MB Hauptspeicher und guten SCSI-Festplatten immer noch viel leisten.
Es gibt zwei Gründe für hoch skalierbare Systeme. Zum einen brauchen Anwendungen wie Datenbank-Server, Messaging-Systeme oder Business Intelligence sehr viel Rechenleistung. Zum anderen gibt es Fälle, in denen die Software zwar nicht extrem viel Power benötigt, aber viele Applikationen auf einem System konsolidiert werden sollen, um die Zahl der Server zu reduzieren.
Um eine hohe Skalierbarkeit zu erreichen, gibt es verschiedene Ansätze. SMP-Systeme, also Mehr-Wege-Rechner für das symmetrische Multiprocessing, sind ein Ansatz. Cluster sind ein zweiter, wobei hier zwischen einfachem Network Load Balancing und Server-Clustern unterschieden werden muss, bei denen die Kommunikation zwischen den Anwendungen auf den Knoten des Clusters erfolgt.
Ersteres wird beim Windows Server 2003 über den als Network Load Balancing (NLB) bezeichneten Dienst, letzteres über den Microsoft Cluster Service (MSCS) unterstützt. Das NLB ist primär für die Verteilung vieler kleiner Aufgaben auf zahlreiche schlanke Systeme geeignet und wird gern für Web-Server eingesetzt. Der MSCS findet sein Einsatzfeld bei Anwendungen wie dem SQL Server oder dem Exchange Server. Die Aufgaben sind dort nicht so autonom wie auf Web-Servern. Bei Web-Servern kann man die Site relativ einfach in immer der gleichen Form auf jeden Server spielen, der dann lokal arbeitet. Änderungen werden an andere Server übergeben, auf denen die Business-Logik der Anwendungen läuft. Bei einem SQL Server oder Exchange Server müssen dagegen alle Knoten im Cluster mehr oder minder auf die gleichen Daten zugreifen.
Betrachtet man die Entwicklung bei Windows Servern, dann ist die Steigerung von den 1992 offiziell bei Windows NT 3.1 unterstützten maximal 4 Prozessoren auf die nun bis zu 64 Prozessoren bei der Datacenter Edition keineswegs beachtlich. Folgt man Moore's Law und beobachtet man die Skalierung in anderen Bereichen, dann sollte man zumindest schon bei der Unterstützung für 128 Prozessoren sein. Und dass in Clustern auch Jahre nach der Einführung der Windows NT 4.0 Enterprise Edition mit einer Unterstützung von damals zwei Knoten pro Cluster nun "erst" acht Knoten unterstützt werden, erscheint auch nicht gerade als Meisterleistung. Beim NLB hat sich sogar überhaupt nichts getan - das Maximum unterstützter Server liegt hier auch weiterhin bei 32.
Diese "langsame" Entwicklung hat ihre Gründe. Das beginnt damit, dass eine Vergrösserung der Rechenleistung ohne entsprechende Skalierung bei anderen Ressourcen wenig Sinn macht. Der grösste Engpass ist hier der Hauptspeicher. 32-Bit-Betriebssysteme können maximal 232 Byte Hauptspeicher adressieren - also 4 GB. Bei Windows bleiben davon je nach Konfiguration 2 bis 3 GB für Anwendungen übrig, der Rest wird vom System reserviert. Schon bei Windows 2000 hat man diese Grenze etwas verschoben. Einige Intel-Prozessoren unterstützen einen als PAE (Physical Address Extension) bezeichneten Modus und adressieren Hauptspeicher mit 36 Bit - entsprechend können 236 oder 64 GB Hauptspeicher, wenn auch mit ein paar Einschränkungen, angesprochen werden. Erst mit den neuen 64-Bit-Versionen wird diese Grenze entscheidend verschoben. Dabei ist der Windows Server 2003 aber noch weit von der theoretischen Grenze von 17 TB entfernt. Das Maximum liegt bei 512 GB in der Windows Server 2003 Datacenter Edition.
Der Teufel steckt aber im Detail. Wie schon angesprochen, ist keineswegs jeder Cluster für jedes Problem geeignet. Wenn man mit einem einfachen NLB arbeitet, setzt das relativ autonome Systeme und für Änderungen eine mehrschichtige Architektur voraus. Änderungen müssen von Site-Management-Systemen auf Web-Server verteilt werden. Die Änderungen und dynamischen Abläufe werden wiederum von Clustern auf dem Middle Tier und dem Back-end mit Datenbanken abgewickelt.
Bei Anwendungen, die auf mehreren Knoten im Cluster laufen, geht es vor allem um die Verteilung von Last und den Fail-Over, wenn eines der Systeme ausfällt. Wenn sieben Server Änderungen vornehmen und einer als Stand-by-System bereitsteht, dann muss dieses jederzeit wissen, was alle anderen machen, um die Arbeit eines ausgefallenen Servers übernehmen zu können. Die Lösung dieser Aufgabe erfordert Anpassungen in Anwendungen sowie komplexe Algorithmen.
Auch bei SMP-Systemen ist eine weitere Skalierung nicht einfach. Die Probleme lassen sich gut mit einem Beispiel der SMP-Frühzeit illustrieren. Bei Windows NT 3.1 hat das System versucht, die Prozessoren gleichmässig auszulasten, was dazu geführt hat, dass Prozesse bei niedriger Last immer wieder von Prozessor zu Prozessor verschoben wurden - was wenig sinnvoll ist. Nicht umsonst gibt es mittlerweile etwa beim Datacenter Server die Möglichkeit, Anwendungen gezielt bestimmten Prozessoren zuzuweisen. Und dieses Beispiel streift nur die Komplexität, die sich bei der Verteilung von Last auf mehrere Prozessoren und Server stellen.
In Anbetracht dieser Umstände hat Microsoft einen durchaus guten Job bei der Skalierung gemacht, auch wenn man sich manchmal schnellere Fortschritte wünschen würde. Microsoft hat in den letzten Jahren immerhin gelernt, dass Fortschritte bei der Skalierbarkeit sehr hart erarbeitet werden müssen. Die Verteilung von Arbeit auf mehrere Prozessoren oder Server ist zweifelsohne eine der grössten Herausforderungen der IT.