Der wachsende Bedarf an Rechenleistung kann nur durch leistungsstarke Server, skalierbare Softwareprodukte und parallele Datenbanken gedeckt werden. Doch welche Hardwarearchitektur eignet sich am besten für den Einsatz im BI-Umfeld? Sind es symmetrische Multiprozessor-Systeme (SMP-Server), Cluster-Lösungen oder massiv-parallele Systeme (MPP-Server) mit einer Vielzahl von Knoten, die mit ihrer Leistungsfähigkeit IT- und Fachabteilungen das Management riesiger Datenmengen erleichtern sollen? Im Wesentlichen kommt es dabei auf das Einsatzgebiet des jeweiligen Servers an, sprich: ob er als Datenbankserver, als Server für Online Analytic Processing (Olap) oder im Bereich des Reporting und Data Mining genutzt wird. Eine Entscheidung für eine bestimmte Architektur auf Basis des zu bearbeitenden Datenvolumens ist heute aufgrund der unterschiedlichen Datenmodelle, komplexer Abfragen und Einsatzmöglichkeiten der Server nicht mehr sinnvoll. Bei der Frage, welche Vor- und Nachteile die einzelnen Hardwarearchitekturen für den Einsatz von BI-Lösungen haben, gilt es viele Faktoren zu berücksichtigen: Einerseits kann bei ständig wachsenden Datenvolumina weder auf hohe Flexibilität noch Skalierbarkeit verzichtet werden, andererseits spielen Verfügbarkeit sowie die Systemadministration der einzelnen Server eine wichtige Rolle.
In einem SMP-Server greifen alle Prozessoren gleichberechtigt auf den gemeinsamen Hauptspeicher zu. Durch leistungsfähige interne Verbindungen wird eine hohe Bandbreite zwischen den einzelnen Prozessoren, dem Hauptspeicher und den I/O-Kanälen erreicht. Während SMP-Server heute eine sehr gute interne Skalierbarkeit aufweisen, liegt der Haupteinsatzpunkt klassischer SMP-Systeme meist bei einer Datenbankgröße von ein bis zwei Terabyte.
Für Olap-Anwendungen sind SMP-Server mit großem Hauptspeicher und hoher I/O-Bandbreite sehr gut geeignet, denn die Erstellung der Würfel spielt sich zum großen Teil im gemeinsam genutzten Speicher (Shared Memory) ab. Relationale Datenbanken sind heute für den Einsatz auf SMP-Servern so weit optimiert, dass sie sowohl den großen Hauptspeicher als auch die Parallelität der vielen Prozessoren (Multi-Threading) und I/O-Kanäle effizient ausnutzen.
In einem klassischen SMP-System sind die Datenbank-Partitionen nicht an physikalische Grenzen gebunden; es besteht zudem eine enge Lokalität der Datenbankpartitionen zu den I/O-Kanälen. So verhält sich eine parallele, partitionierbare Datenbank auf einem SMP-Server genauso wie auf mehreren SMP-Systemen im Cluster oder auf vielen Knoten eines MPP-Servers. Die Kommunikation der Datenbank-Partitionen untereinander erfolgt in einem SMP-Server über den Shared Memory, bei einer Cluster-Lösung sowie einer MPP-Architektur über ein externes LAN. Um eine parallele Datenbank mit mehreren Partitionen auf einem SMP-Server mit guter Performance zu betreiben, muss eine möglichst symmetrische Aufteilung der einzelnen Server-Komponenten (Prozessoren, Hauptspeicher, I/O-Kanäle) gegeben sein.
SMP-Server: Nur begrenzt skalierbarDie Vorteile der SMP-Server bestehen in ihrer einfacheren, internen Ausbaufähigkeit sowie darin, dass sie sich wie ein einzelnes System administrieren lassen. Ihr Nachteil liegt meist in der Leistungsfähigkeit bei komplexen Abfragen von Data-Warehouse-Datenbanken. Ab einer bestimmten Größe sind sie in ihrer Skalierbarkeit limitiert, da das Betriebssystem in den einzelnen Systembereichen wie Hauptspeicher, I/O und Netzwerkverwaltung in Sachen Optimierung das Ende der Fahnenstange erreicht hat.
Die nächste Skalierungsstufe für große Datenbanken ist eine Cluster-Lösung, bestehend aus wenigen, sehr leistungsfähigen SMP-Server-Knoten. Die einzelnen SMP-Server sind über ein redundant ausgelegtes Gigabit-Ethernet-Netzwerk und über Fiber Channel (SAN) zu einem Cluster verbunden. Eine Cluster-Lösung ist im Vergleich zu einem einzigen SMP-Server nicht nur leistungsfähiger, sondern bietet auch höhere Verfügbarkeit durch vollständig redundante Hardware (hier greift das "No-Single-Point-of-Failure"-Konzept, um höchste Verfügbarkeit zu erreichen).
Und mit der heutigen Fiber-Channel-(FC-)Technologie spielt die geografische Trennung von Cluster-Servern und Festplatten für den Desaster-Fall mittlerweile eine wichtige Rolle bei der Entscheidung für eine Architektur. Hochverfügbarkeits-Produkte wie IBMs "High Availability Cluster Multi-Processing" (HACMP) sorgen für eine schnelle Übernahme von Datenbankdaten auf einen anderen Server im - geografisch getrennten - Cluster-Verbund.
In besonderen Konfigurationen ist eine Übernahme der Daten auf einen anderen Server aufgrund der gleichzeitigen Zugriffe der Datenbank auf die gemeinsam genutzten I/O-Subsysteme nicht notwendig - wie bei "Oracle Parallel Server" im Concurrent Access Mode oder generell bei Standby-Datenbanken.
Besondere Aufmerksamkeit bei der Planung eines SMP-Clusters erfordert die Auslegung der I/O- und Netzwerk-Adapter. Je besser die Ausstattung und je höher die Leistung eines Cluster-Knotens, desto mehr Datenbank-Partitionen lassen sich auf diesem Knoten definieren: Bei einer "Shared-Disk"-Architektur wie dem Oracle Parallel Server muss der lokale Zugriff auf alle Platten für alle Knoten gewährleistet sein - eine echte Herausforderung für die Planung der I/O-Adapter und Festplatten im Hinblick auf Limitierungen durch den konkurrierenden Zugriff auf gemeinsam genutzte Plattensubsysteme. Bei der Inter-Partition-Kommunikation der einzelnen Server und Datenbankteile untereinander - wie bei IBMs paralleler, partitionierbarer Datenbank "DB2 UDB EEE" - über ein TCP/IP-LAN kann es bei komplexen Datenbankoperationen zu Engpässen in der Netzwerkkommunikation kommen, da etwa Ethernet-Netzwerke eine wesentlich höhere Latenzzeit haben als spezielle Switching-Technologien.
Um genau diese Einschränkung zu umgehen, besteht für IBM-SMP-Server im Cluster die Anschlussmöglichkeit an den "SP"-Switch. Der Switch wird auf MPP-Servern und in Cluster-Lösungen eingesetzt, um eine Vielzahl von Knoten untereinander mit hoher Netzwerk-Performance zu verbinden.
MPP-Systeme für die Analyse enormer DatenmengenMassiv-parallele Systeme als Datenbank-Server sind hauptsächlich ab einer Datenbankgröße von mehreren Terabyte anzufinden. Die nahezu unbegrenzte Erweiterbarkeit der MPP-Systeme im Zusammenspiel mit einem leistungsfähigen Switch bilden die Hardwaregrundlage für die Speicherung von großen Datenmengen eines Terabyte-Data-Warehouse - etwa der Analyse von Milliarden von Call-Detail-Records (CDRs) im Telekommunikations-Umfeld oder die Kassenbeleg-Analyse im Handel. Eine MPP-Architektur ist eine enge Kopplung von vielen, möglichst baugleichen Server-Knoten, die je eine eigene Kopie des Betriebssystems besitzen. Jeder Knoten, genannt Building Block, ist mit einer für die MPP-Arbeitsweise optimalen Anzahl von Prozessoren, Hauptspeicher, I/O-Kanälen sowie einer direkten Verbindung zum (SP)-Switch konfiguriert. Bei parallelen Datenbanken verbindet Letzterer die einzelnen MPP-Knoten und Datenbankteile untereinander (beispielsweise über TCP/IP) mit einer bidirektionalen Bandbreite von zirka 500 Megabyte pro Sekunde. Die Inter-Node-Kommunikation wird im Gegensatz zu einer Cluster-Lösung mit Ethernet nicht zum limitierenden Faktor.
Der große Vorteil einer MPP-Architektur liegt in der hohen Ausbaufähigkeit des Gesamtsystems aufgrund der speziellen Konfiguration der Knoten, vor allem aber in einer partitionierten Datenbank. Durch die Verwendung einfach gestalteter Komponenten wie den Building Blocks (Knoten) hat sich der MPP-Server zu einer attraktiven Alternative in Sachen Preis und Leistung entwickelt.
Die Basis der Erweiterbarkeit liegt in der "Shared-Nothing"-Arbeitsweise der einzelnen Komponenten. Bei diesem Konzept bearbeitet jeder Knoten seinen eigenen Datenanteil, auf den allein er Zugriff hat, und muss sich - im Gegensatz zu SMP-Servern oder einem Cluster mit Shared-Disk-Architektur - nichts mit anderen Prozessen teilen. Im Gegensatz zu herkömmlichen, parallelen Programmiermodellen auf MPP-Systemen, die auf einer Prozess-zu-Prozess-Kommunikation über "Message Passing" basieren, sind die parallelen Operationen etwa bei DB2 UDB EEE bereits in der Datenbanksoftware implementiert. Jedoch nicht alle Datenbankoperationen (je nach Datenmodell und Partitionierungs-Schema) sind vollständig parallelisierbar, so dass diese den maximalen Speed-Up nicht erreichen.
MPP-Systeme zeichnen sich besonders durch die hohe I/O-Leistung aus. Die gesamte I/O-Leistung, mit der die Knoten parallel auf die partitionierten Daten zugreifen, übertrifft die I/O-Performance von SMP-Servern und Cluster-Lösungen um ein Vielfaches. Durch spezielle Partitionierungsverfahren der Datenbank wie dem "Hash Partitioning" werden die Tabellen auf die einzelnen Knoten ideal verteilt, und jeder Knoten bearbeitet den Teil einer Abfrage, auf dessen Daten er lokal Zugriff hat. Das Gesamtergebnis wird dann von einem Koordinator-Knoten, auf dem die Abfrage gestartet wurde, wieder zusammengefasst.
Trotz des höheren Administrationsaufwandes vieler Knoten wird eine MPP-Architektur vorgezogen, um eine sehr große, parallele Datenbank über viele Server-Knoten aufzubauen. Dabei spielt der Aspekt der Hochverfügbarkeit eine geringere Rolle - viel wichtiger ist der Bedarf an Performance und Skalierbarkeit bei stark anwachsenden Geschäftsdatenvolumen. Nicht parallelisierbare Anwendungen wie Olap hingegen, die nur in einem Adressraum (Shared Memory) auf einem SMP-Server laufen, sind für eine Cluster-Lösung oder gar eine MPP-Architektur ungeeignet, da der gesamte reale Hauptspeicher über die einzelnen Knoten verteilt ist und die Daten in einem parallelen Dateisystem vorgehalten werden müssen.
Viele Vorteile für den Einsatz im BI-Umfeld bieten SMP-Server mit logischer Partitionierung (LPAR), bei denen die logische Partitionierung nicht an physikalische Grenzen der Hardware gebunden ist wie etwa bei Cluster- oder MPP-Lösungen.
LPARs ermöglichen es nicht nur, heterogene BI-Softwareumgebungen auf einem einzigen SMP-Server zu betreiben, sondern den jeweiligen Applikationen auch die benötigten Systemressourcen wie CPU, Memory und I/O-Adapter je nach Bedarf für einen gewissen Zeitraum zuzuweisen, ohne dass hier physikalisch Hardwarekomponenten wie ganze Systemboards exklusiv allokiert oder gar umgebaut werden müssten.
LPARs: DynamischeRessourcenzuteilungZeitkritische BI-Prozesse wie Olap-Würfelberechnungen am Monatsanfang oder das Laden riesiger Datenmengen am Wochenende erhalten temporär mehr Ressourcen in einer LPAR zugewiesen, die dann später anderen Bereichen - beispielsweise Datenbankabfragen - für das Tagesgeschäft unter der Woche wieder neu zugeteilt werden.
Ein weiterer Vorteil des LPAR-Konzepts ist die softwareseitige Trennung verschiedener Applikationen. Da sich in einer typischen BI-Installation die Gesamtumgebung zum Beispiel aus Kerndatenbank, Anwendungen für die Datenaufbereitung (Extraktions-, Transformations- und Ladetools) und Olap-Applikationen zusammensetzt, kommen hier mehrere LPARs mit einer eigenen Kopie des Betriebssystems und der jeweiligen Anwendung zum Einsatz. Die effiziente Ausnutzung der vorhandenen Server-Ressourcen und die damit verbundene, längerfristig niedrige "Cost of Ownership" machen die Vorteile des LPAR-Konzeptes deutlich - und das nicht nur für BI-Anwendungen.
*Georg Ember ist E-Server-Architekt bei der IBM Enterprise Systems Group.
Die Stärken und Schwächen
SMP / Cluster / MPP
Skalierbarkeit / limitiert / geeignet / hervorragend
Hochverfügbarkeit / bedingt / sehr gut / herausfordernd
Systemadministration / einfach / geringer Aufwand / hoher Aufwand
I/O-Leistung / limitiert / flexibel skalierbar / extrem skalierbar
Interne Datenbank-Kommunikation / sehr schnell / limitiert / gut
Art der Partitionierung / logisch / logisch und phyisch / nur physisch
Anzahl verfügbarer BI-Anwendungen / sehr hoch / gering / nur parallele DB
Eignung als BI-Datenbank-Server / Single Instance DB und parallele DB / Parallele DB und Standby-DB / nur parallele DB
Eignung als OLAP-Server / sehr gut / bedingt geeignet / ungeeignet
Abb: Logische Partitionierung von BI-Anwendungen
LPAR-fähige SMP-Server erlauben es, einzelnen Applikationen temporär mehr Systemressourcen zuzuweisen - ohne physikalischen Hardwareumbau. Quelle: IBM