Serverpartitionierung

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Die Serverpartitionierung bezeichnet eine logische (softwareseitige) oder physische (hardwareseitige) Abtrennung eines Computersystems, in dem eine oder mehrere autonome Betriebssysteminstanzen mit ihren Anwendungen betrieben werden können. Die Partitionierung umfasst die Trennung von CPUs, Speicher, Adapterkarten und anderen Komponenten, aber auch das Hosten der Systeme selbst.

Die zunehmende Leistungsfähigkeit der Hardware legt die Zusammenfassung vieler (Betriebs-)Systeme mit geringem Ressourcenbedarf auf wenigen Servern nahe. Damit einher geht die Reduzierung des Platzbedarfs im Rechenzentrum und die Konsolidierung sich zahlreich wiederholender technischer Komponenten (Netzteile, Gehäuse, Mainboards, Adapterkarten usw.).

Im Einsatz sind alternative Ansätze, die diesen Gedanken mehr oder weniger konsequent umsetzen.

Noch keine Partitionierung im engeren Sinn, jedoch sind bereits Netzteile, Netzwerk- und Storage-Area-Network-Technik in einem besonderen Chassis untergebracht (Bladeserver), während die sehr kompakt gebauten Rest-Server im Wesentlichen auf CPUs, Hauptspeicher und ggf. Festplatten reduziert sind und in das Chassis eingeschoben werden. Die einzelnen Blades können dabei unterschiedlich ausgestattet und leistungsfähig sein. Teilweise können auch verschiedene Bauformen kombiniert werden, in der Regel sind 10–20 Blades pro Chassis möglich.

Feste Partitionen (Hardware Partitions)

[Bearbeiten | Quelltext bearbeiten]

In entsprechenden Rechnern mit mehreren System-Boards kann jedes Board einer Partition zugeordnet werden. So entstehen maximal so viele Partitionen, wie Boards vorhanden sind. Die Partitionen können dabei unterschiedlich leistungsfähig sein. Der Server kann umkonfiguriert werden, um eine veränderte Aufteilung zu erhalten.

Dynamische Partitionen (Software Partitions)

[Bearbeiten | Quelltext bearbeiten]

Eine Softwareschicht (Hypervisor) regelt den Zugriff der Partitionen auf die Hardwarekomponenten. Diese können prinzipiell im laufenden Betrieb umverteilt werden. Während die Hinzunahme von Komponenten in der Regel unproblematisch ist, muss die Wegnahme von dem betroffenen Betriebssystem und der aktiven Anwendungssoftware verkraftet werden, was unter Umständen nicht nur im Betriebssystem, sondern auch in den Anwendungsprogrammen Anpassungen erfordert. Betriebssysteme, die dynamische Partitionen nicht unterstützen, können in der Regel dennoch betrieben werden, allerdings erkennt das System die neue Konfiguration unter Umständen erst nach einem Neustart der Partition.

Virtuelle Partitionen (Virtual Partitions)

[Bearbeiten | Quelltext bearbeiten]

Der Hypervisor spiegelt den Betriebssystemen virtuelle CPUs und Adapterkarten vor und leitet Ressourcenbedarfe zur Laufzeit auf die physischen Komponenten weiter. Somit teilen sich mehrere oder alle Partitionen dieselben physischen CPUs und Adapter. Dabei können einzelnen Partitionen Mindest-CPU-Ressourcen garantiert werden. CPU-Ressourcen, die keiner Partition garantiert sind bzw. zu einem Zeitpunkt nicht benutzt werden, werden durch den Hypervisor bei Bedarf sehr schnell einer beliebigen Partition zur Verfügung gestellt.

Dynamische und Virtuelle Partitionen werden auch als Logische Partitionen (LPAR) bezeichnet.

Virtualisierung

[Bearbeiten | Quelltext bearbeiten]

Unter Virtualisierung versteht man unter anderem eine Technologie, bei der eine Betriebssysteminstanz nicht unmittelbar auf einem Server installiert ist, sondern auf der Hardware über einer Zwischenschicht, die von der Hardware abstrahiert, oder aber in einem Gastgeber-Betriebssystem mittels Virtualisierungssoftware.

Die Technik mit der Zwischenschicht entspricht im Wesentlichen der dynamischen bzw. virtuellen Partitionierung (siehe Hypervisor). Zur Unterscheidung von der nachfolgend dargestellten Software-Virtualisierung wird die Zwischenschicht „Typ-1-Hypervisor“ genannt.

Bei der Software-Virtualisierung ist eine gewisse logische Abschottung voneinander gegeben. Das Duplizieren bzw. Erstellen als Kopie von einem Master wird unterstützt. Störungen des Gesamtsystems durch den Ressourcenverbrauch einer einzelnen Virtualisierung sind nicht ausgeschlossen. Da die Virtualisierungssoftware auf einem Gastgeber-Betriebssystem wie Linux oder Windows läuft, ist sie selbst relativ hardwareunabhängig, kann aber im Gegenzug die Hardware-Gegebenheiten nicht immer optimal ausnutzen. Diese Art von Virtualisierungssoftware wird als Typ-2-Hypervisor bezeichnet.

Wie bei den virtuellen Partitionen müssen Gast-Betriebssysteme für die Software-Virtualisierung geeignet sein. Problematisch können spezielle Prozessorbefehle sein, die auf virtualisierten Systemen dem Hypervisor bzw. Gastgeber-Betriebssystem vorbehalten sein sollten, weil sie uneingeschränkten Zugriff auf den gesamten Speicher der Maschine erlauben. Unvirtualisierte Betriebssysteme benötigen dieses technische Mittel selbst. Daher kommt es zu Konflikten, wenn ein solches Betriebssystem sich einem Hypervisor oder Gastgeber-Betriebssystem unterordnen soll, denn prinzipiell könnte nun jedes Gast-Betriebssystem einem anderen den Speicher überschreiben. In der Regel wird das Problem gelöst, indem das Gast-Betriebssystem seine Kernel-Routinen in einem weniger privilegierten Ring ausführt (z. B. Ring 1). Eine andere Frage ist noch, wie sämtliche Anwendungsprogramme inklusive möglicher Schadcodes sicher vom Ring 0 ferngehalten werden können.

Ein weiteres Problem stellt die Darstellung von eindeutigen, unveränderlichen Hardwarekennungen pro Partition dar, die unter Umständen für eine Lizenz-Selbstüberprüfung gebraucht werden.

Bladeserver sind vergleichsweise preisgünstig und bieten sich an, wo eine größere Anzahl von Systemen mit ähnlichen Anforderungen benötigt werden. Für den Systemadministrator besonders vorteilhaft weil einfach ist der Fall, dass alle Blades baugleich sind. Beispiel: Webserver-Farm.

Echte Partitionen kommen ins Spiel, wo mehr Flexibilität benötigt wird: Unterschiedliche und wechselnd große Partitionen. Partitionierte Server sind typischerweise große Server, mit denen (auch) besonders leistungsfähige Systeme betrieben werden können. Besonders vorteilhaft sind die virtuellen Partitionen, weil sie besonders flexibel auf veränderliche Lasten reagieren und in vielen Anwendungsfällen (z. B. mehrere OLTP-Partitionen) die Server deutlich kleiner ausgelegt werden können als die Summe der Einzelbedarfe.

Die Software-Virtualisierung eignet sich besonders, wenn zahlreiche, jeweils wenig leistungshungrige Betriebssysteminstanzen auf einem Server konsolidiert werden sollen, und wenn neue Instanzen rasch erstellt und aktiviert werden sollen. Sie kann bei moderaten Anforderungen an Performance und Verfügbarkeit auch auf preisgünstiger Hardware betrieben werden und erfordert ggf. auch vergleichsweise wenige zusätzliche Kenntnisse.

Partitionierung und Software-Lizenzmodelle

[Bearbeiten | Quelltext bearbeiten]

Softwareprodukte werden häufig nach Anzahl verwendeter CPUs lizenziert. Dies trifft beispielsweise auf viele Datenbanksysteme zu, auf Software zur Datensicherung usw. Zumeist muss für sämtliche physisch in der Maschine vorhandene CPUs eine Lizenz erworben werden. Dabei sind noch Besonderheiten bei Chips mit mehreren Prozessorkernen zu beachten: Wird eine Lizenz pro Chip (Sockel) oder eine pro Kern benötigt?

Dieses Lizenzmodell ist ungünstig, wenn die Software nur auf einer oder wenigen Partitionen eines Servers benötigt wird, weil dann mehr CPUs lizenziert werden müssen, als eigentlich verwendet werden. Eine Bladeserver-Architektur vermeidet dieses Problem.

Daneben gibt es Lizenzmodelle, die die Partitionierung berücksichtigen, z. B. „subcapacity licensing“, ein Modell, das IBM für einen Teil seiner Software anbietet. Hier wird lediglich verlangt, dass virtuelle Partitionen in ihrer Leistung begrenzt („capped“) werden. Es werden dann nur Lizenzen gemäß der tatsächlich abrufbaren Leistung benötigt.

Partitionierung bei unternehmenskritischen Anwendungen

[Bearbeiten | Quelltext bearbeiten]

Der Komplexität einer solchen Lösung geschuldet sind gewisse Verschlechterungen bei Performance, Verfügbarkeit und Kompatibilität mit spezieller Hardware (Adapter usw.). Hinzu kommt zu Anfang die mangelnde Erfahrung bei den Systemadministratoren, was Sizing, Aufbau und Betrieb solcher Architekturen betrifft. Es empfiehlt sich wie zumeist, klein zu beginnen und dann mit wachsender Erfahrung auch an unternehmenskritische Abläufe heranzugehen. Technologisch ist ein guter Reifegrad erreicht, mit dem auch unternehmenskritische Anwendungen auf partitionierten Servern gefahren werden können.