MelaWe Photocase.com

Für ihre Genügsamkeit, kompakte Bauform und komfortable Handhabung wurden Bladesysteme die Lieblinge des IT-Krisenjahres 2009. Sie sind aber nicht in allen Fällen die geeignete Hardware, sodass traditionelle Rackserver im Rennen bleiben. Die Post-Blade-Generation ist inzwischen auch am Start.

Die Idee, Boards zuhauf vor eine Mittelplatine (Midplane) zu stecken und ihnen von der anderen Seite I/O-Module gemeinsam zur Verfügung zu stellen, setzt elektronisch auf die VME-Bus-Architektur [1] von Anfang der 1980er Jahre auf. Das US-Patent 6411506 “High density web server chassis system” aus dem Jahr 2002 [2] beschreibt die eigentliche Blade-Idee. Sie bezog sich ursprünglich auf Webserver und das Problem, dass die damaligen Serversysteme für kleine Webservice-Anbieter zu aufwändig schienen.

Das Patent weist die Firma Rocketlogix als Antragsteller aus. Als Erfinder sind Christopher Hipp und David Kirkeby eingetragen. Hipp, der Mitte 2009 im Alter von 47 Jahren starb und den manche den “Vater der Blade-Technologie” nennen, war Mitgründer dieses Unternehmens, das 2001 unter dem neuen Namen RLX Technologies mit dem ersten Bladesystem in die Geschichte einging. Darauf lief übrigens ein Debian 2.2 [3].

IBM alias Big Blue sprang im gleichen Jahr auf den Zug auf, indem es RLX-Blades verkaufte und in die Firma investierte. Jedoch IBMs heute im Servermarkt stärkster Konkurrent Hewlett-Packard übernahm vier Jahre später die Firma RLX Technologies und kaufte sich damit sein Linux-Know-how für Bladesysteme ein. Heute liegt HP in diesem Segment weit vor IBM. Linux ist auf nahezu allen Systemen eine Option, mindestens in Form von SLES und RHEL.

Krisenerprobt

Laut den Statistiken von Servermarkt-Beobachtern konnten die Bladeserver nach starkem Wachstum 2007 und Anfang 2008 auch im schwierigen Jahr nach der Finanzkrise noch glänzen. Ähnlich glimpflich wie im ersten Quartal ging es auch im zweiten weiter, speziell für Europa, den Nahen Osten und Afrika (EMEA): Während insgesamt fast 30 Prozent weniger Server den Besitzer wechselten, waren es bei den Blades nur 20 Prozent weniger, errechnete IDC. Beim Umsatz sieht es bei den Blades mit minus 12 Prozent gegenüber minus 30 Prozent insgesamt sogar noch besser aus. Gegen Ende 2009, im dritten Quartal, lagen Bladesysteme mit einem Prozent Wachstum sogar einsam an der Spitze, wohingegen der Gesamtmarkt nach wie vor schrumpfte.

Abbildung 1: Statt pro Server ein Netz- und ein Stromkabel zu legen, erlauben Bladegehäuse mehrere Server pro Kabel, so wie bei dem abgebildeten Chassis mit zwei verbauten Fibrechannel-Extendern und zwei externen Switches mit bis zu 20 Ports.

Schnittig und praktisch

Ihre zunehmende Beliebtheit verdanken die schlanken, traditionell hochkant verbauten Serverscheiben im Wesentlichen der dank gemeinsam genutzter Ressourcen eingesparten Energie [4]. So arbeiten zum Beispiel für 16 Bladeserver nur vier Netzteile und Lüfter – inklusive Redundanz. Immerhin bräuchten 16 Rackserver herkömmlicherweise jeweils ein eigenes Netzteil und in der Regel auch eigene Lüfter und weitere redundante Komponenten. Hinzu kommt, dass Anbieter oft für ihre Bladegehäuse effiziente Lüfter und Netzteile selbst entwerfen, weil die Gehäuseform ein besonderes Lüftungsdesign oder eigene Energiesensoren ermöglicht (siehe auch Kasten “Blade-Technologie – Full House”).

Zudem nehmen Bladesysteme weniger Platz weg. 16 Rackserver belegen mindestens 16 Höheneinheiten, während beispielsweise 16 halbhohe Bladeserver inklusive Gehäuse nur zehn Höheneinheiten messen. Ein wichtiges Argument ist neben dem Platz auch die Kabelage: Die gemeinsame Strom- und Netzwerkanbindung reduziert das Kabelaufkommen (Abbildung 1), was der Betriebssicherheit zugute kommt. Das ebenfalls dem speziellen Gehäuse geschuldete Software-seitige Betriebskonzept gerät zum Pro-Argument: In das Gehäuse integriert jeder Hersteller eine allen Servern gemeinsame Managementkonsole und KVM-Funktionen für den lokalen Zugriff. Das ermöglicht automatische Installationen, intelligente Verwaltung und den einheitlichen Zugriff sowohl auf das Gesamtsystem als auch auf Einzelserver über ein gemeinsames GUI.

Begrenzt und speziell

Bladesysteme erreichen also eine höhere Packungsdichten pro Höheneinheit und lassen sich gleichzeitig Hardware- und Software-seitig besser handhaben. Allerdings haben sie auch Nachteile: Oft setzen die Hersteller auf eigene Gehäuseformen, Mainboards in Spezialformaten, teilweise auf niedrige Speichermodule (Low-Profile-Bauform) und auf im Haus entworfene Module statt auf Standardkomponenten.

Der ACTA-Standard [5] definiert zwar seit 2002 unter anderem Gehäusemaße für Blades. Doch Hersteller halten sich oft nicht an alle Spezifikationen des Standards, um kundenorientiert vorzugehen oder eigene Techniken umzusetzen. Beim Kauf eines Bladesystems kann es also passieren, dass man sich für einen erheblichen Zeitabschnitt auf einen Hersteller festlegt – zumindest für dieses Set.

Neben der Herstellerabhängigkeit sind die begrenzten Ressourcen pro Server das zweite große Problem bei Blade-Lösungen. Viele Bladeserver verfügen lediglich über ein oder zwei Prozessorsockel, ein Dutzend DIMM-Steckplätze und die on Board integrierten Netzwerkoptionen Gigabit-Ethernet, Fibrechannel und/oder Infiniband. Für mehr ist schlicht kein Platz. Entsprechend finden zum Beispiel Rechenoperationen, die viel Arbeitsspeicher brauchen, hier suboptimale Bedingungen vor.

Blades bieten durch die Enge und durch die herstellerspezifische Bauweise oft auch nur wenige Schnittstellen (siehe Kasten “Vorsicht, Falle!”). VGA- oder USB-Ausgänge findet man zuweilen nur in Form eines vorn eingesteckten und nicht für den dauerhaften Betrieb gedachten Peitschen-Dongle.

Anwendungsszenarien

Bladesysteme spielen ihre Stärken aus, wenn es darum geht, die unternehmensspezifischen Anwendungen von mehreren Einzelservern zu konsolidieren. Systemadministratoren können sich dann auf eine Hardwareplattform konzentrieren und müssen nicht vielen verschiedenen Herstellern nachjagen. Auf diese Weise lassen sich ein Datei- und Mailserver, die CRM-Anwendung und der eigene Webauftritt in einem Gehäuse unterbringen, betreiben und überwachen. Dieses Szenario liegt nahe, wenn sich der Systemverantwortliche nicht auf die Herstellerversprechungen für virtuelle Umgebungen verlassen möchte. Denn eine Alternative mittels Virtualisierung sähe so aus, alle Anwendungen als eigene virtuelle Maschinen auf zwei leistungsstarke Rechner zu verteilen, die hochverfügbar zu halten sind.

Ein Anwendungsszenario, das noch nicht sehr lange auf den Tischen von Entscheidern hin und her geschoben wird, ist die Desktop-Virtualisierung. Was ein Arbeitsplatzrechner an Arbeitsspeicher und CPU-Leistung braucht, lässt sich relativ gut vorhersagen und auf die Blades verteilen. Eignen könnte sich ein kompaktes Arbeitssystem auch für Server-based Computing und Thin Clients. Hier könnte das Bladesystem mit einem zusätzlichen Load Balancer die Funktion einer Terminalserver-Farm erfüllen.

Kommen beispielsweise neue Mitarbeiter hinzu, erweitert der Admin die Rechenkapazität einfach durch Hinzufügen weiterer Servermodule. Genauso unkompliziert ist das Austauschen von defekten Komponenten oder das Aufrüsten etwas leistungsfähigerer Module. Rackserver schneiden hier durch die fehlende Modularität schlechter ab.

Auf kaputte Netzteile, Lüfter oder RAM-Steckplätze weist das integrierte Blade-Verwaltungssystem nicht nur hin, ohne dass der Admin tagelange Integrations- und Monitoringsoftware konfigurieren muss. Er darf die Teile im Bladesystem im Bedarfsfall auch im laufenden Betrieb austauschen, zumal die quantitative Erweiterbarkeit der Server Redundanz vereinfacht. Hotplug-fähige Komponenten bieten zwar auch viele Rackserver. Diese zu überwachen ist jedoch aufwändiger.

Blade-Technologie – Full House

Modularität und Kompaktheit sind die entscheidenden Stichworte. Auf den Boards der einzelnen Bladeserver sitzen neben Controllern CPU-Sockel, RAM-Steckplätze und Netzwerkchips. An Festplatten verbauen die Hersteller zwischen null und acht im Bladeserver selbst oder in einem eigenen Modul, oft 2,5-Zöller. Storage ist der Idee nach durch eine externe Appliance realisiert. Ein Blade nimmt ein bis zwei Karten für Ethernet, Fibrechannel oder Infiniband auf. Eine Mittelplatine bündelt die Datenübertragung und leitet sie zu einem oder mehreren Switches (Abbildung 2). In der Regel besitzen die Server ein oder zwei CPU-Sockel, in die Vierkern- oder Achtkernprozessoren passen. Wie viel RAM und Festplattenplatz in einem einzelnen Blade zur Verfügung stehen, hängt wegen des Platzes vor allem von der Anzahl der Sockel ab. Die Gehäusetechnik ermöglicht es, alle Blades einheitlich über herstellerspezifische Software zu verwalten. Über sie greift der Admin auf das einzelne Chassis-System sowie auf einzelne Blades zu. Oft integriert die Software bereits vorhandene Server, auch herkömmliche – zumindest dann, wenn sie von demselben Hersteller stammen. Die Gehäusebauform ermöglicht den Herstellern außerdem eine spezielle Luftführung, die den eng verbauten Komponenten mit einem gehäuseweiten Lüftungsdesign beikommt. Gezielt platzierte Temperatursensoren regeln schließlich die Netzteile und Lüfter automatisch herunter und herauf. Unterschiedliche Bladesysteme und ihre Verwaltungssoftware als Querschnitt durch den Markt zeigt ein weiterer Artikel in diesem Heft. Abbildung 2: Bei diesem halb gefüllten Primery BX900 von Fujitsu Technology Solutions ist in der unteren Hälfte die Midplane zu sehen, über die alle Blades eines Chassis’ ihren In- und Output abwickeln. Copyright: Cisco Systems 2009

Grenzfälle

Bei den Einsatzszenarien ist die begrenzte Prozessorzahl in Bladeservern zu berücksichtigen. Unter Performance-Aspekten liegt als Daumenregel [6] bei Maschinen mit bis zu zwei CPUs der optimale Wert ihrer Auslastung bei 70 Prozent (Ausnahme: Batch-Workloads), damit sie zeitweilige Spitzenwerte abfangen können. Anders sieht das bei Systemen mit mehr als vier CPUs aus. Hier wartet ein Prozess im Durchschnitt kürzer, bis er eine CPU zugeteilt bekommt, und die Auslastung ist bei 80 Prozent am besten [8].

Die Kapazitätsplanung sollte berücksichtigen, dass sich die Leistungsspitzen eines Systems über den Tag verteilen (im Normalfall vormittags und nachmittags, wenn die meisten Anwender arbeiten, sowie im Batch-Betrieb nachts). Ein Mittelwert des Bedarfs führt daher in die Irre – die Leistungsspitzen sind relevant. Virtualisierung behebt das Dilemma, Rechenkapazitäten außerhalb von Spitzenzeiten brachliegen zu lassen. Bladesysteme für Virtualisierung heranziehen bedeutete jedoch, pro Blade eben nur wenige Prozessoren als Host für virtuelle Maschinen zur Verfügung zu haben sowie entsprechend wenig RAM.

En vogue ist derzeit, die räumlich begrenzten Erweiterungsmöglichkeiten zumindest für Arbeitsspeicher und Storage auszutricksen und Blade-Arrangements auch für Datenbanksysteme fit zu machen. HP beispielsweise brachte im Mai 2009 einen Verbund aus Proliant-Blades und einer Storage-Appliance auf den Markt [9]. Das Gespann ist für die Verarbeitung von SAP-Netweaver-Daten gedacht: Auf den Servern läuft SLES 10, auf der Appliance der SAP Accelerator.

Dieser ersetzt das SLES-Dateisystem und erlaubt es, bis zu 40 Blades zusammenzuschalten statt nur 16, wenn das SLES-eigene Oracle-Cluster-Filesystem zur Anwendung käme. Bei einer Ausstattung von 16 Blades, 16 GByte RAM pro CPU und 1,2 TByte Plattenplatz betrug der Kaufpreis bei Markteinführung etwa 400 000 Euro plus Lizenzgebühren an SAP. Die zu verarbeitende SAP-Datenbank wäre in diesem Fall etwa 8 TByte groß.

Vorsicht, Falle!

Es ist entschieden: Ein Blade-Lösung soll her. Laut Plan sollen innerhalb von fünf Jahren zwei bis drei Gehäuse in Betrieb gehen. An die folgenden Punkte denkt der Entscheider vielleicht nicht gleich. Er sollte sie beim Verkäufer seines Vertrauens abklopfen – vor allem, wenn es sich um Blade-Installationen von mehr als zwei Gehäusen mit starker Auslastung handelt. Wenig Erweiterungen Ein Bladesystem mit der Büro-IT, den Serverdiensten der Thin Clients oder mit einem HPC-Cluster für die Strömungssimulation ist genau das – und nicht mehr: Die Erweiterungsmöglichkeiten von Blades sind beschränkt. Außer der Netzwerkübertragung und der Rechenleistung von oft maximal zwei Prozessorsockeln kann der durchschnittliche Bladeserver nichts. Hersteller wie Sun benutzen Steckkarten wie PCI-Express Expressmodule [7], die zwar standardkonform sind, jedoch umgebaute Stecker besitzen, damit die Karte optimal in das eigene Gehäuse passt. Der Blade-Besitzer kann stets nur bestimmte Karten – wenn sie überhaupt einem Standard entsprechen – in seinem System verwenden: Die einfache Handhabung der Hardware und Software erkauft er sich mit der Festlegung auf bestimmte Anwendungsfälle. Starkstrom Bladesysteme rentieren sich umso mehr, je ausgelasteter sie sind. Ein voll besetztes Bladecenter zieht jedoch durch die zusammengelegten Netzteile kräftig Strom. Die Betreiber von Rechenzentren großer Unternehmen wissen das – ein kleines oder mittleres Unternehmen rechnet jedoch nicht unbedingt damit, dass der im Alltag gebräuchliche C13/C14-Stecker, der bis zu 10 Ampere Stromstärke verträgt, unter Umständen nicht ausreicht. Stattdessen führen Hersteller den auf wenige Netzteile verteilten Strom für ihr Bladegehäuse vielleicht über C19/C20-Stecker aus (Abbildung 3), die bis zu 16 Ampere Strom aushalten: Der glückliche Käufer stellt dann auf einmal fest, dass die falsche Steckdose in seiner Wand sitzt. Unter Volllast kann ein gefülltes Bladegehäuse zudem auch bis rund 30 Ampere schlucken. Der Serverbetreiber müsste in diesem Fall dafür sorgen, dass für den Betrieb mindestens zwei 16-Ampere-Stromkreise zur Verfügung stehen, oder über Drehstrom nachdenken. Wärmeentwicklung Die Abluft kann zu einer weiteren unvorhergesehenen Falle führen. Bei einem Bladesystem ist sie wärmer als bei einem Rackserver, da das Kühlsystem mehr Hitze pro Rückenfläche rausbläst, die aus der hohen Rechenleistung auf kleinem Raum resultiert. Nun ist der typische Serverraum eines Unternehmen mit 150 Mitarbeitern aber vielleicht nur eine zum Maschinenraum umdeklarierte Abstellkammer. Die zusätzlichen Bladesysteme mögen kompakt und harmlos aussehen, doch wenn sie ihre konzentrierte Wärme dazugeben, ist vielleicht eine zusätzliche Klimaanlage fällig. Stecken Rack- und Bladegehäuse in einem Regal, gehören die Blades nach oben. Bei größeren Installationen kommen Kühltüren oder -schränke in Betracht, die sich speziell der Bladeserver annehmen, die zudem vielleicht in einem eigenen Teil des Raums besser aufgehoben sind. Die Einheit, mit der Fachleute die erforderliche Kühlleitung bezeichnen, ist BTU (British Thermal Unit). Der Blade-Verkäufer sollte mit dieser Einheit zumindest etwas anzufangen wissen. Gewicht Ein voll bepackter Rackserver, das wissen Rechenzentrumsmitarbeiter, wiegt zwischen einer halben und einer Tonne. Pro voll bepacktem Bladechassis fallen zwischen 200 und 300 Kilogramm an. Bei vier vollen Chassis wächst die Bodenbelastung unter Umständen also auf mehr als eine Tonne. Dem modernen Betonboden in der Abstellkammer mag das egal sein, aber wer sich zum Beispiel Doppelböden zur besseren Kühlung und sauberen Kabelführung einziehen ließ, könnte sich mit einem Gewichtsproblem konfrontiert sehen. (Beratender Experte: Wolfgang Stief, Senior Systemingenieur bei der Best Systeme GmbH und Vorsitzender der German Unix User Group) Abbildung 3: Systemverantwortliche achten nicht immer auf die Leistungsaufnahme ihrer Bladecenter. Viele Gehäuse verlangen zum Beispiel nach dem C19/C20-Stecker für 16 Ampere Stromstärke, der am anderem Ende in den abgebildeten P+N+6h-Stecker mündet. Quelle: Wikipedia

Blade-Stopper

Als Daumenregel sind Bladeserver für Anwendungsfälle ungeeignet, die mehr brauchen als Rechenleistung und Netzwerk. Die Telefonanlage eines großen Callcenters beispielsweise benötigt möglichweise mehr Bandbreite und Durchsatz, als die zwei Kartensteckplätze pro Blade zulassen – von Spezialhardware wie ISDN-Karten einmal ganz abgesehen. Bei geschäftskritischen Anwendungen, wozu bei Callcentern die Kommunikationsanlage gehört, bei Onlinehändlern die Shopsoftware oder bei Bezahldiensten die Internet-Erreichbarkeit, ist ein einzelnes Bladechassis wegen der fehlenden physischen Trennung seiner Server ebenfalls nicht die richtige Lösung.

Auch Energiesparwille kann teuer werden. Wegen ihrer Energie- und Ressourceneffizienz auf Bladesysteme zu setzen, lohnt sich beispielsweise nicht, wenn der auf fünf Jahre absehbare Workload die Kapazität dreier Server nicht überschreitet. Das kann in dem spezifischen Anwendungsfall begründet sein, aber auch in der Personalsituation – die Belegschaft einer öffentlichen Einrichtung etwa vergrößert sich in der Regel langsam.

Ebenso wenig wird eine soziale Einrichtung mit fantastischen Margen und frei werdenden Investitionsgeldern für innovative Geschäftsfelder rechnen können (leider). Der Investitions-Sockelbetrag ist wegen der erforderlichen Einzelmodule (Gehäuse, Netzteile, Switches) höher als bei einem Einzelserver und lohnt sich erst ab einer gewissen Anzahl Server.

Blades inkognito

Nachdem die Produktklasse “Blade” im Markt angekommen ist, möchten neue Marktteilnehmer mit bedeutungsähnlichen Produktnamen und leicht variierten Konzepten ein Schnittchen vom Kuchen abhaben. Cisco hat beispielsweise im März 2009 ein neues Produkt namens Unified Computing System (UCS) vorgestellt. An ihm zeigt sich beispielhaft, dass die Hochkant-Bauweise nicht das entscheidende Merkmal von Bladesystemen ist, denn hier stecken die Einschübe quer im Gehäuse (Abbildung 4).

“Per bladem definitionem” wiederum switcht im UCS-Chassis eine zentrale Netzwerkanbindung alle Einzel-Ethernets der Server. Die Cisco-Blades sollen sich auch für Virtualisierung eignen, indem sie mittels eines selbst entwickelten Chips, der die Speicheranbindung der Prozessoren vervielfacht, mehr RAM erlauben als die Konkurrenz (Extended Memory Technology, [10]). Hier sind dann 48 statt 8 Steckplätze mit theoretisch bis zu 384 GByte Arbeitsspeicher pro Server möglich – ein Totschlagargument für Datenbank-auf-Blade-Skeptiker.

Neben der höheren Packungsdichte versuchen Hersteller auch die Ressourcen in einem System gemeinsam zu nutzen. Bei Intels Modular Server [11] fällt an keiner Stelle das Wort Blade (Abbildung 5). Das seit 2008 als “Business in a box” vermarktete Produkt hat kleinere Servermodule als Blades, die sich ihr Zuhause mit integriertem Storage teilen: Nur sechs Server passen in ein Gehäuse.

Intel bewirbt diese Server damit, dass sie Rechenleistung, Storage und Netzwerkfunktionen in einem (modularen) Stück integrieren. Diese Server richten sich nach Standards der Server Systems Infrastructure (SSI, [12]), im Gegensatz zu ATCA also nach nicht offenen Standards, denen auch wieder mehrere Blade-Spezifikationen zugehören. Unter den Mitgliedern befinden sich weder IBM noch Dell oder Sun.

Und es geht noch kleiner. Auf dem Intel Developer Forum 2009 stellte Intel den Prototyp einer abgespeckten Quasi-Blade-Variante vor, die aus einem Gehäuse mit bis zu 16 so genannten Micro Servern und vier RAM-Steckplätzen für bis zu 32 GByte Arbeitsspeicher besteht.

Neue Wege

Wer sich für die kompakte Bauform begeistert, aber Standards bevorzugt, für den erhöhen Hersteller die Packungsdichte konventioneller Server. So hat 2009 der amerikanische Rackserver-Hersteller Rackable Systems, der im April den insolventen Veteranen Silicon Graphics International (SGI) übernahm und seitdem unter diesem Namen firmiert, die Microslice-Architektur aus der Rackserver-Familie Cloudrack vorgestellt [13].

Abbildung 5: Modular und kompakt ohne Blades: Das 2008 von Intel eingeführte Modular-Server-System sieht genauso aus wie ein (quergelegtes) Bladesystem mit integriertem Mini-Storage.

Abbildung 4: Nur die Chassis-Architektur macht den Unterschied: In seinem 2009 auf den Markt gebrachte Unified Computing System (UCS) verbaut das auf Netzwerk-Hardware spezialisierte Unternehmen Cisco die Blades quer.

Hier stecken bis zu sechs Mikro-ITX-Boards samt CPUs, RAM und Festplatten in einer Höheneinheit. Anders als bei den Blades ist hier das Motiv, leistungsschwache Desktop-Prozessoren zu verbauen, die einen günstigen Preis pro Server ermöglichen. Die Idee zeigt, dass es noch mehr gibt als monolithische Rack- und modulare Blade-Lösungen.