Das Problem Skalierbarkeit

ITMAGAZINE
Das Problem Skalierbarkeit
8. April 2003 - In Sachen Skalierbarkeit geht der Fortschritt deutlich langsamer voran als in anderen Bereichen. Lesen Sie,
weshalb das so ist und wie Windows Server 2003 die Skalierbarkeit verbessert. 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.
Zwei Varianten für Clustering
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.
Historische Einschränkungen
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.
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. Copyright by Swiss IT Media 2017