Sie tauchen immer wieder auf – pauschale Hardwareempfehlungen, meist für kleine, mittlere, große Systeme und gar sehr große Systeme. Sie sind als Anhaltspunkt gedacht. Was aber, wenn wir konkret gefragt werden, was denn nun für Kunde X in Situation Y genau das Richtige ist?

Auch wir bei Bissantz verfügen über ein Dokument, das Hardwareempfehlungen auflistet. Dabei fällt auf, dass ein großes System einen Server beinhaltet, der beispielsweise 4-8 Prozessorkerne haben soll, ein sehr großes System sollte mittels SAN angebunden sein. Warum? Ist ein SAN automatisch schneller als ein RAID? Warum nur ein Server?

Microsoft beispielsweise spricht für den SQL Server 2008 von 4GB Arbeitsspeicher pro Kern, d.h. bei 12 Prozessorkernen benötigen wir 48GB Arbeitsspeicher – eine heutzutage durchaus machbare Konfiguration, aber auch sinnvoll und richtig?

In diesem Blogbeitrag soll aufgezeigt werden, wie schwierig die Frage nach der richtigen Hardware zu beantworten ist, was man dabei beachten sollte und wie man dennoch zu Aussagen kommen kann.
Die Frage nach der „richtigen“ Hardware ist oft zu Beginn eines Projekts ein Thema oder stellt sich allgemein in folgenden Situationen:

• Wenn die Abfrageperformance einer BI-Anwendung als langsam empfunden wird, rückt oft die eingesetzte Hardware in den Fokus. Man stellt sich die Frage, ob die Leistung der eingesetzten Hardware verbessert werden kann.
• Eine bestehende BI-Landschaft soll um weitere Themen erweitert werden. Genügt die eingesetzte Hardware hierfür noch?
• Eine BI-Anwendung soll neu erstellt und eingeführt werden. Am Anfang taucht schnell die Frage auf, welche Hardware angeschafft werden soll, beispielsweise durch den eigenen Vertrieb oder den Kunden selbst.

Eine gute Hardwareausstattung löst keine Implementierungsfehler

Eine konkrete Hardwareempfehlung vor allem zum Beginn eines Projekts oder während des Vertriebsprozesses erfolgt im Grunde zu früh. Für eine Empfehlung müsste die Anwendung oder Erweiterung zumindest in einem Umfang bereits fertig sein, der eine hinreichend genaue Aussage zulässt, welche Hardwarekomponenten in welchem Umfang benötigt werden.

Für die Neueinführung einer BI-Anwendung kann es sinnvoll sein, zunächst einen bestehenden Server zu verwenden (sofern möglich), der zumindest etwas mehr als die Mindestvoraussetzungen des Microsoft SQL Servers und der Analysis Services bietet. Dann wird mit der Entwicklung eines repräsentativen Prototyps begonnen, der nähere Aussagen zu den Anforderungen der zukünftigen Anwendung zulässt.

Eine bereits bestehende Anwendung sollte zuerst mit den zur Verfügung stehenden Möglichkeiten bzgl. der Abfrageperformance optimiert werden, um die Abfragezeiten der Anwendung zu verbessern. Denn erst dann ist der Punkt erreicht, an dem bessere Hardware vielleicht die ggf. immer noch bestehenden Performanceprobleme lösen kann.

Eine schnellere Hardware löst jedoch keine Fehler in der Implementierung von schlechtem SQL-Code, falsch eingestellten Serverkonfigurationen (SQL Server/SSAS), falschem Design, fehlenden/zu vieler Indizes und Statistiken usw. Ein schneller Rechner hilft nur dabei, dass solche Fehler lediglich in deren Auswirkung vermindert werden.

Man kann aber auch umgekehrt argumentieren: Wenn bereits die bestmögliche (?) Hardware zur Verfügung steht, die Anwendung aber noch immer schlecht läuft, dann hat man auf der Hardwareseite zumindest keinen Fehler gemacht (nur ggf. zu viel Geld ausgegeben?).

Wie kommt man also zu einer besseren Aussage in Bezug auf die „richtige“ Hardware?

Für die Beantwortung sind mehrere Aspekte wichtig.

• Zu betrachten ist, wie eine typische Bissantz BI-Anwendung funktioniert. Wir haben es zumeist mit dem Microsoft SQL Server und den Microsoft Analysis Services (SSAS) und damit mit deren spezifischer Architektur zu tun, die als Datenbasis von DeltaMaster mehr oder weniger intensiv abgefragt werden. Die jeweiligen Softwarekomponenten decken spezifische Aufgaben ab, bspw. der SSAS für die Bedienung der Anwender, der SQL Server zumeist zur Aufbereitung der (Roh-)Daten. Die eingesetzte Hardware stammt aus dem PC-Bereich, das Betriebssystem ist Microsoft Windows.
• Ein Verständnis für die Arbeitsweise von Hardwarekomponenten ist notwendig, um zu beurteilen, welche davon in welcher Situation welchen Anteil/Einfluss haben.
• Wichtig ist die Frage nach den Datenmengen und der Komplexität, die verarbeitet werden muss. Hierbei rückt in den Vordergrund, ob wir es mit komplexen Berechnungen oder bspw. stattdessen einfachen Abbildungen von Daten, jedoch mit riesigen Mengen davon zu tun haben.

Die ersten beiden Aspekte werden im Folgenden behandelt, der dritte Aspekt anschließend im Rahmen der Beispielszenarien.

Die spezifische Bissantz-BI-Architektur

Wir erstellen typischerweise eine relationale Grundlage auf Basis einer Staging Area und erzeugen daraus ein Data Warehouse, das einem gemischten Ansatz aus Star- und Snowflake-Schema folgt.
In der Praxis haben wir es mit folgenden Prozessen zu tun:

• Datentransformierung und Prozessierung (Datenaufbereitung)
• Datenabfrage und Rückschreiben mittels DeltaMaster (Betrieb)
• Automatisierte massenhafte Datenabfrage für die automatisierte Berichtsverteilung mittels dem Berichtsserver

Einfluss relevanter Hardware-Komponenten auf die Server-Performance

Prozessoren

• Anzahl Prozessorkerne – je mehr Kerne, desto mehr Abfragen, aufgelöst in Threads können parallel bearbeitet werden.
• Leistungsfähigkeit pro Prozessorkern: Je leistungsfähiger, umso schneller sind Berechnungen durchgeführt. Die Leistungsfähigkeit eines Prozessors und dessen Kerne werden über dessen internes Design bestimmt, bspw. Anzahl Integer/FP-Units, Größe des First-/Second-/Third-Level-Cache, interne Taktfrequenz usw.

Arbeitsspeicher

• Die Größe des Arbeitsspeichers ist für BI-Anwendungen auf Basis SQL Server/SSAS entscheidend, beide sind allgemein speicherhungrig.
• Die Geschwindigkeit (Taktfrequenz) von Speichermodulen. Auf ein Gesamtsystem hat die Auswahl eines schnellen gegenüber langsamen Arbeitsspeichertyps jedoch keinen großen Einfluss, d.h. ein bspw. um 30% schnelleres High-End-Modul gegenüber einem durchschnittlichen Speichermodul wirkt sich in der Performance des Gesamtsystems allgemein nur geringfügig aus.

Speichersystem

Festplattentypen

• Herkömmliche Magnetische Festplatten – billiger, große Kapazitäten, ggf. langsam
• SSD-Festplatten arbeiten ähnlich wie Speichersticks auf Basis von NAND-FLASH und verwandten elektronischen Bausteinen, die einen deutlich schnelleren Zugriff als herkömmliche Platten zulassen. Sie sind kleiner in der Kapazität und deutlich teurer (gemessen in Preis pro Gigabyte) als herkömmliche magnetische Festplatten. SSD-Platten sind ggf. als Ergänzung herkömmlicher Platten sinnvoll.

Eine Festplatte wird grob durch zwei Parameter bestimmt: Mittlere Zugriffszeit und Lese-/Schreib-durchsatz:

• Zugriffszeit: Ist die Zeit, die benötigt wird, bis die Festplattenköpfe die benötigten Sektoren gefunden haben. Bei Zugriffen, bei denen viele verschiedene Blöcke gelesen werden müssen, ist dieser Faktor wichtig. Bzgl. SQL Server werden Datenbanken als Dateien abgelegt, aus denen viele Teile gelesen werden müssen. Bei SSD-Festplatten spielt die Zugriffszeit praktisch keine Rolle, da Daten praktisch sofort gefunden werden.
• Lese-/Schreibdurchsatz: Gibt den Wert in Megabyte an, den eine Festplatte pro Sekunde lesen/schreiben kann, wobei im Praxisbetrieb immer niedrigere Raten erreicht werden aufgrund von Overhead des Betriebssystems und anderer Wartezeiten.
• Cache – interner schneller Speicher, der versucht, bereits gelesene Daten bei wiederholtem Zugriff aus diesem Puffer zu liefern – bei SSD-Festplatten irrelevant.

Festplattenzusammenstellungen

• Raid (Redundant Array of Independent Disks): ein Raid verfolgt zwei teilweise kombinierte Ziele: Erreichen höchstmöglicher Performance, indem Daten auf mehrere Festplatten aufgeteilt werden oder erreichen höchstmöglicher Sicherheit gegen Ausfall und Datenverlust sowie Kombinationen hiervon.

Typische Raid-Konfigurationen:

RAID 0 – Striping: Zur Erzielung von maximalem Datendurchsatz/maximaler Geschwindigkeit. Daten werden auf bspw. zwei Festplatten geteilt geschrieben und wieder gelesen. Dies erhöht den Durchsatz, der Raid-Controller muss den maximalen Durchsatz jedoch unterstützen. Der Ausfall einer Festplatte bedeutet Totalverlust der Daten.

RAID 1 – Mirroring: Für hohe Sicherheit. Daten werden parallel auf zwei Festplatten geschrieben. Fällt eine davon aus, ist das System weiterhin vollständig betriebsfähig.

RAID 5 – Sicherheit + Leistung: mindestens drei Festplatten sind nötig, es wird parallel auf zwei Festplatten geschrieben, die dritte Festplatte enthält Korrekturinformationen, sodass beim Ausfall einer Festplatte alle Daten wieder rekonstruiert werden können.

RAID 10: Ist ein RAID, das auf einem RAID aufbaut und benötigt mindestens vier Festplatten, d.h. ein RAID 0 wird über ein oder mehrere RAID 1-Systeme geschaltet.

Daneben gibt es eine Vielzahl weiterer RAID-Kombinationen.

• SAN – steht für Storage Area Network und ist eine Erweiterung von DAS (Direct Attached Storage). Es geht hier um das Ziel, möglichst keine Server und/oder lokale Arbeitsplatzrechner mehr mit lokalen Festplatten auszustatten, die separat gesichert werden müssen. Stattdessen werden durch das SAN flexibel Servern und auch Arbeitsplatzrechnern Festplattenkapazität zugeordnet. Das SAN selbst kann jederzeit im laufenden Betrieb (Hot Swap) durch Hinzufügen von Festplatten in der Kapazität erweitert werden. Der Zugriff auf das SAN wird durch den zugreifenden Rechner gesteuert (!) im Gegensatz zu NAS-Systemen (Network Attached Storage), die weniger Flexibilität bieten, da der Datenverkehr über ein dezidiertes System erfolgt bzw. kanalisiert wird anstelle des direkten Zugriffs lediglich über Switches.

„SANs werden heute meistens über Glasfaserkabel gebildet; das dabei eingesetzte System wird als Fibre Channel bezeichnet. Ein einfaches SAN besteht aus einem Fibre-Channel-Switch, einem oder mehreren Festplattensubsystemen und den Servern, die über so genannte Host Bus Adapter, kurz HBA, mit dem Fibre-Channel-Switch verbunden werden.
Sie arbeiten heute mit Übertragungsraten von bis zu 16 GBit/s. Da sie ein spezielles, an die Anforderung der Massenspeichernutzung angepasstes Protokoll verwenden, sind Übertragungsraten von theoretisch 1,6 GB/s möglich. Hinzu kommt das Konzept des Multi-Pathing, das im SAN konsequent verfolgt wird.“
Quelle: Wikipedia

SANs sind nicht automatisch schneller als lokale Festplatten. In großen Umgebungen sind sie jedoch potentiell schneller als lokale magnetische Festplatten.
Wenn auf ein flexibles SAN-Volume (Laufwerk) zu viele Anwendungen parallel zugreifen, sind schnell Szenarien erreicht, bei denen sich Abfragen in Warteschlangen einreihen, bis sie zum Zuge kommen.
Ein erster Hinweis, dass das SAN zu langsam ist, ergibt sich, wenn Abfragen lange dauern, die CPU-Kern-Belastung dabei jedoch recht gering erscheint. Eine Messung des I/O-Durchsatzes ist hier angebracht.

Netzwerk

Das Netzwerk selbst wird nur dann zum Flaschenhals, wenn Hardwarekomponenten Daten zwischen Servern oder Clients mit einer höheren Durchsatzrate austauschen könnten, als das Netzwerk erlaubt. Ein Unternehmensnetzwerk mit 1GB Übertragungsrate ist zum Austausch zwischen Servern – und Client-Rechnern normalerweise geeignet, wenn nicht viele parallellaufende Datenpakete die Übertragungskapazität des Netzwerks reduzieren. Zwischen Servern ist jedoch generell aufgrund leistungsfähigerer Komponenten ein höherer Durchsatz von min. 10GBit/s angebracht.

Virtualisierte Hardware bspw. VMWARE führt nach eigenen Messungen zu einer Reduktion der Abfragezeiten von 30%-100%, was sich nahezu gleichmäßig auf alle beteiligten Hardwarekomponenten bezieht. Eine Hilfe ist es hier, die Festplatten nicht zu virtualisieren, sondern den direkten Durchgriff für virtuelle Server zu erlauben. Wenn jedoch ohnehin schon Performanceprobleme zu befürchten sind, ist ein virtualisierter Server sicherlich der flache Ansatz.

Die richtigen Fragestellungen, die zur konkreten Auswahl von Hardwarekomponenten führen

Wichtige Fragen hierbei sind:

• Wurde denn ausreichend berücksichtigt, um welche inhaltlichen Themen es geht? Was plant der Kunde zukünftig?

Es macht einen bedeutenden Unterschied, ob man bspw. Vertriebs- oder CRM-Daten abbilden wird, die in großen Mengen anfallen, dabei jedoch unter Umständen wenig komplex aufbereitet werden müssen oder aber man es bspw. mit Liquiditätsberechnungen oder Preiskalkulationen zu tun hat, die ggf. wenig Basisdaten heranziehen, jedoch mehrstufige rechenintensive Schritte beinhalten. Werden große Dimensionen mit vielen Hierarchiestufen modelliert werden?

• Fragestellungen zur Intensität der Anwendungsnutzung?

Wie viele Anwender werden mit der Anwendung zukünftig arbeiten? Wie viele davon parallel? Wie viele davon online?

• Fragestellungen zum Datenbankdesign/Verarbeitungsprozess und Optimierung der Umgebung

Gibt es spezielle Anforderungen wie beispielsweise verteilte Systeme?

Ein paar Beispielszenarios sollen zeigen, auf was man achten sollte:

Szenario a) Tagesbetrieb, es finden reine Datenabfragen statt, im Fokus steht der Microsoft SSAS

Oft getroffene Aussage des Kunden: Wir haben 50 Anwender, die mit DeltaMaster auf den Server zugreifen werden.

=>Diese Aussage sagt uns nichts Konkretes (!) – denn wir wissen nicht, wie viele Anwender parallel arbeiten werden, d.h. genau zeitgleich oder zumindest in Abschnitten zeitlich überdeckende Abfragen an den Server stellen werden. Wenn jeder Anwender brav nacheinander Abfragen ausführen würde und wartet, bis sein Vorgänger fertig ist, genügt uns (vielleicht) ein einziger Prozessorkern.

=> Die Frage muss daher lauten: Wie viele Anwender werden überdeckende, d.h. parallele Abfragen an die Datenbank richten? Dies spielt umso mehr eine Rolle als im BI-Bereich umfangreichere Abfragen von Massendaten im Vordergrund stehen, im Gegensatz zu Einzeldatensätzen bei OLTP-Systemen.

Man stellt oft fest, dass wenn man eine Momentaufnahme von wenigen Minuten vornimmt, selten mehr als zwei bis drei Anwender überhaupt Abfragen ausführen – oft ist es kein Einziger, auch wenn dutzende Abfragen dies potentiell tun könnten. Es sei denn man schaut am Monatsanfang – dort ist auf einmal deutlich mehr zu sehen, da bspw. neue Zahlen im System sind.

=> Hieraus ergibt sich somit der Nutzungs-„Peak“, der unbedingt ermittelt werden sollte, im Zweifelsfall durch Untersuchung des Anwenderverhaltens, durch Nachfragen oder Beobachtung der bisherigen Arbeitsweise oder aber idealerweise mittels einer Protokollierung. Ansonsten muss eine Faustformel genügen. Da hierzu Werte schwer zu ermitteln sind, gehen wir aus unserer eigenen Erfahrung von ggf. hochgegriffenen 15% wirklich parallel laufender Abfragen aller „online“ arbeitenden Anwender aus, die zum Zeitpunkt eines Peaks entstehen, wenn Daten neu bereit stehen.

Damit ergibt sich eine Aussage darüber, wie viele Kerne ein Server benötigt. Im Fall unserer 50 Anwender wären wir dann bei ca. 8 Kernen, was ein Server mit bspw. 2 Vierkern-CPUs liefern kann. Damit wäre sichergestellt, dass für die zu erwartende Anzahl von Anfragen ausreichend Kerne zur Verfügung stehen.

Diese Annahme geht jedoch vereinfacht davon aus, dass eine Abfrage genau einen CPU-Kern auslastet bzw. genau einen Anwender bedient. Tatsächlich können Anfragen multithreaded ausgeführt werden, d.h. in Teilen auf mehreren Kernen verteilt. Speziell bei Intel-Prozessoren kommt das sogenannte Hyperthreading hinzu, so dass durch bessere Ausnutzung der Kerne eine kleinere Anzahl davon genügen kann. Entscheidend jedoch ist zunächst, dass Kerne zur Verfügung stehen, ansonsten landen weitere Anwender unweigerlich in einer Warteschlange.

Im Weiteren hängt die Art und Anzahl Prozessoren davon ab, ob Abfragen lange laufen, d.h. rechenintensiv sind (also nicht ob eine Warteschlange entsteht und wie lang diese wird, sondern wie lange die Bedienung am Schalter dauert…).

Dauern Abfragen lange, d.h. sind rechenintensiv, steigt die Wahrscheinlichkeit, dass nachfolgende Abfragen keinen freien Prozessorkern mehr vorfinden und warten müssen. Und je länger ein Anwender auf seine Abfrage warten muss, umso wahrscheinlicher wird es sein, dass sein Kollege in dieser Zeit ebenfalls eine Abfrage startet. Die Abfrageüberdeckungszeiten und deren Anzahl steigt, d.h. wir benötigen in diesem Szenario dann wieder tatsächlich mehr freie Prozessorkerne, ansonsten kann sich dies bis zum gefühlten Systemstillstand entwickeln. Ein solches Szenario zeigt sich bereits durch Überprüfung mit dem einfach gestrickten Task-Manager auf einer bestehenden Anwendung. Sind alle verfügbaren Prozessoren hoch ausgelastet, d.h. nahe bei 100%, scheint die Anzahl CPU-Kerne ggf. nicht auszureichen. Eine höhere Anzahl Kerne würde helfen, mehr Threads zu verteilen oder vereinfacht mehr Anwender parallel oder schneller zu bedienen. Allerdings ist es immerhin positiv zu sehen, wenn ein Prozessor mit 100% optimal ausgelastet ist, da dies bedeutet, dass dessen Kerne selbst nicht auf andere Hardwarekomponenten warten müssen.

Die nötige Leistungsfähigkeit eines Kerns selbst hängt von der Komplexität der Abfrage ab und muss nicht unbedingt hoch sein. Wenn wir es mit einer Anwendung zu tun haben, bei der der Microsoft SSAS nahezu ausschließlich mit Basismeasures arbeitet, d.h. keine umfangreichen Berechnungen/Scopes und Create-Member-Anweisungen auftreten, beschäftigt sich der SSAS im anspruchsvollsten Fall mit dem Verdichten von Daten und Füllen des Abfragecaches. Im Idealfall sind diese Caches aber nach der ersten Anforderung von Daten bereits gefüllt, dann sind die Aufgaben für die Prozessorkerne „überschaubar“. Dies bezeichnen wir als das typische Szenario von Vertriebsanwendungen (kann man natürlich diskutieren).

Im anderen Fall jedoch spielt die Leistungsfähigkeit der Prozessorkerne eine größere Rolle, da umfangreiche Berechnungen im Cube selbst rechenintensiv sind. Wenn also eine CPU aufgrund intensiver Berechnungen optimal ausgelastet läuft, so kann die Bearbeitung eines Threads nur dann noch beschleunigt werden, wenn die Leistungsfähigkeit des einzelnen CPU-Kerns möglichst hoch angesetzt ist. Die Leistungsfähigkeit eines Kerns hängt stark von seiner Taktfrequenz, internem Design (bspw. Anzahl paralleler Integer/Floating-Units) sowie der Größe und Geschwindigkeit des First-/Second- und ggf. Third-Level Caches ab.

Arbeitsspeicher und Festplattenperformance sind in diesem Szenario zusammen zu betrachten. Je mehr Arbeitsspeicher – hier vornehmlich dem SSAS – zur Verfügung steht, desto stärker wird das Risiko vermindert, dass der SSAS auf die Festplatte ausweicht, da er seine Caching-Möglichkeiten besser ausnutzen kann. Einen geeigneten Wert kann man hier jedoch eigentlich nur empirisch ermitteln.
Daher ein „grobes“ Beispiel: Eine SSAS-OLAP-Datenbank mit Vertriebsdaten ist ca. 10GB groß. Wenn theoretisch alle Daten angefordert würden, benötigen wir 10GB RAM zzgl. Verwaltungsoverhead sowie weiteren Speicher für zusätzliche Caches. In der Praxis ist der Anteil Daten jedoch deutlich geringer, der angefordert wird. Seitens des OLAP-Designs empfiehlt es sich hier dennoch über Partitionierung nachzudenken, um selten benötigte Daten auf eigene Partitionen zu legen, da Anwendungen wachsen werden.

Ein Rechner mit 16GB RAM dürfte hier in jedem Fall ausreichen, sollte jedoch ausbaufähig sein, falls die Datenmenge steigt. Selbst bei einer höheren Anzahl Anwender wird ein weiterer Speicherausbau jedoch (vorerst) nicht viel bewirken, da im Extremfall der größte Teil der Daten bereits im Speicher vorliegt. Ist also genügend Speicher vorhanden, hat die Performance der Festplatte nur beim ersten Zugriff einen größeren Einfluss, da zu diesem Zeitpunkt Daten in den Speicher geladen werden. Hier helfen dann jedoch Mechanismen wie das Cache-Warming, da gerade das Laden großer Dimensionen mit großer Tiefe intensive Lesevorgänge auf der Festplatte erfordert.

Fazit: Es sollte ein Blick auf die Anzahl gleichzeitig arbeitender Anwender geworfen werden sowie auf die Art der Berechnungen, die ggf. im Cubescript ausgeführt werden. Der Fokus liegt auf der Anzahl Prozessoren und der Menge des Arbeitsspeichers, oft weniger auf der Leistungsfähigkeit der einzelnen Komponenten – Ausnahme: rechenintensive Cubescripte.

Szenario b) Datenaufbereitung

Die Datenaufbereitung und Würfelprozessierung laufen oft über Nacht. Die Anzahl Prozessoren, die benötigt werden, ist normalerweise geringer, d.h. ein für viele Anwender ausgelegtes System ist hier voraussichtlich nicht in gleichem Maße ausgelastet. Der Einfluss des Festplattensystems ist hier entscheidend, da bei der Datenaufbereitung viele Lese- und Schreibvorgänge ablaufen.
Die Leistung der Prozessorkerne hat jedoch einen starken Einfluss, da der Transform-Prozess der Daten des Data Warehouse ggf. komplexe Basis-Fakten-Views materialisiert.
Als komplexe SQL-Abfragen gelten beispielsweise in Views vorhandene aufeinander aufbauende verschachtelte SQL-Joins.

Die Prozessorenauswahl einer Neuanschaffung, die für die Abarbeitung bspw. nur 25% der Zeit im Vergleich zur bspw. inzwischen vier Jahre alte verfügbaren Hardware benötigt, ist hier sicherlich ein gutes Argument, Geld in die Hand zu nehmen.

Der benötigte Arbeitsspeicher des SQL Server dagegen ist schwer zu schätzen, daher sollte dieser von vornherein ausbaubar sein, am besten in den Bereich bis 128GB. Erfahrungswette zeigen, dass SQL-Server-Datenbanken mit wenigen Gigabyte Größe mit 16GB Arbeitsspeicher erfahrungsgemäß völlig ausreichend bedient sind, im hohen zweistelligen Größenbereich der Datenbanken wird man mit 32GB beginnen und weiteren Ausbau vorsehen.

Eine gute Möglichkeit ist es, das Verhalten der TEMP-DB des SQL Server im Auge zu behalten. Wird diese intensiv genutzt und wächst stark an, fehlt dem SQL Server Speicher zur Verarbeitung seiner Prozesse. Dann ist der Speicherbedarf weiter zu erhöhen (sowie ggf. der pro Task zugesicherte Speicher in der SQL-Server-Konfiguration). Als Anhaltspunkt gelten Umgebungen unserer größeren Kunden mit Datenbanken bis in den dreistelligen GB-Bereich, die quasi als Minimum Systeme mit 64GB RAM einsetzen.

Fazit: Für die nächtliche Verarbeitung ist ggf. mehr Wert auf die Leistungsfähigkeit der einzelnen Kerne, statt deren Anzahl zu legen, es sei denn, ein Server ist nicht nur dezidiert für eine einzelne Anwendung zuständig, sondern führt parallel weitere Aufgaben durch. Entscheidend ist die Leistungsfähigkeit des Festplattenspeichers, da dieser in diesem Szenario intensiv durch Lese- und Schreibvorgänge belastet wird. Ist eine nachträgliche Verarbeitung unter Tags aufgrund eines fehlgeschlagenen Nachtlaufs nötig, wird es rasch eng, da das I/O-System ggf. nicht mehr exklusiv zur Verfügung steht.

Daraus ergibt sich die Empfehlung, den SQL Server für die Datenaufbereitung getrennt vom Anwendersystem zu halten, d.h. der SQL Server sollte getrennt vom SSAS auf einer eigenen Umgebung idealerweise mit exklusivem Zugriff auf das Speichersystem betrieben werden.

Szenario c) Planungsanwendungen

Ein Spezialfall ist Schreiben von Daten bspw. in Planungsanwendungen. Hier helfen uns viele Prozessoren kaum weiter, da Schreibvorgänge häufig Blockaden im Dateisystem/auf Tabellenebene bedeuten, die zu Wartezeiten führen. Das Erhöhen der Anzahl Prozessorkerne im Planungsfall ist selten hilfreich, denn die Wahrscheinlichkeit steigt, dass lesende Anwender versuchen auf blockierte Objekte zuzugreifen und warten müssen. Schreibende Anwender, die die gleichen Objekte gleichzeitig beschreiben wollen, müssen sich ebenfalls in einer Warteschlange anstellen. Beim SQL Server werden beim Schreiben Tabellen blockiert – man kann hier ggf. mit Snapshots gegensteuern. Beim SSAS werden jedoch unter Umständen große Teile eines Würfels beim Schreibvorgang gesperrt, so dass keine parallele Verarbeitung bis zum Ausführen des Commits der Schreibaktion mehr stattfinden und alle nachfolgenden Lese-/Schreibvorgänge sich dahinter einreihen müssen. Gesperrte Objekte können bspw. ganze Measuregroups sein bis hin zu kompletten Würfeln. Partitionierung kann hier ggf. helfen. Ein Erhöhen der Anzahl verfügbarer Prozessoren, um das Problem zu lösen wäre reine Verschwendung.

Man kann in diesem Szenario bereits im einfach gestrickten Windows Task-Manager feststellen, dass beim Planen oft keine gute Auslastung der Prozessoren vorliegt oder diese nur zeitweise stärker ausgelastet werden, bspw. wenn geschriebene Daten neu aggregiert/berechnet werden und zudem zurückgesetzte Datencaches des SSAS erneut gefüllt werden. Eine genauere Auskunft über die tatsächlich stattfindenden Blockaden gibt der SQL Server Profiler.

Eine Verbesserung der Verarbeitungsgeschwindigkeit kann erreicht werden, indem beim Festplattensystem auf eine besonders hohe Schreibperformance wert gelegt wird und die Leistungsfähigkeit von Prozessoren hoch ist, da nach einem Schreibvorgang punktuell die Neuberechnung von Daten ansteht, die nun erst wieder in die Caches des SSAS geschrieben werden müssen, bspw. Aggregationen. Die Anzahl Prozessoren spielt hier nur eine untergeordnete Rolle, es sei denn Schreibvorgänge kommen nur sporadisch vor, was dann aber kein typisches Planungssystem wäre.

Wenn möglich, sollte man daher Planungsanwendungen, in denen intensiv Schreibvorgänge stattfinden, von überwiegend reinen Leseanwendungen trennen – am besten auch auf Seiten der Hardware. Daraus würde sich von Seiten der Hardware ggf. ein eigener Planungsserver anbieten, der mit wenigen aber leistungsfähigen Prozessorkernen und einer ggf. kapazitätsmäßig überschaubaren Festplattengröße hoher Schreibperformance auskommt wie bspw. einer SSD-Festplatte.

Sinnvoll wäre es zumindest Schreibpartitionen des SSAS auf eine schnelle SSD-Platte zu legen, um Schreibzugriffe zu verkürzen.

Szenario d) Berichtsserveraufbereitung

Der DeltaMaster-Berichtsserver arbeitet quasi wie ein Anwender, d.h. für ihn gelten die Szenarien des normalen Anwenderbetriebs. Er ist maßgeblich von der Performance des SSAS abhängig, liest jedoch nur Daten, d.h. für ihn sind Schreibvorgänge kein Thema. Im Unterschied dazu muss er jedoch in einer vorgegebenen Zeit, oft im Nachtlauf mit seinen Aufbereitungen fertig sein, und seine Ergebnisse abzuspeichern. Daher ist es sinnvoll, Berichtsserverjobs auf einem Server-Rechner zu betreiben, auf dem auch der Analysis-Server selbst läuft, und die Speichermenge dieses Servers zu erhöhen. Der Speicherverbrauch des Berichtsservers bewegt sich im Rahmen des DeltaMasters. 32bit können nicht mehr als 2GB RAM verwendet werden, unter 64bit ist die Grenze nach oben quasi offen, wobei DeltaMaster-Analysesitzungen selten mehr als 4GB RAM benötigen dürften. Größere Analyseseitzungen würde man voraussichtlich ohnehin aufteilen, sofern diese auch von Anwendern im Tagesbetrieb verwendet werden. Auf einem Client-PC wäre ein Speicherverbrauch von mehr als 4GB RAM alleine für DeltaMaster neben anderen Anwendungen ggf. nicht machbar.

Schlussfolgerung

In „kleinen“ Umgebungen sind Empfehlungen für Einzelserver sinnvoll. Relativ sicher gilt dies, wenn SQL-Datenbanken sowie OLAP-Datenbanken nur wenige GB groß sind und die Anzahl parallel arbeitender Anwender im einstelligen Bereich liegt. Dann sind allgemeine Empfehlungen normalerweise unkritisch, da für solche Umgebungen durchschnittliche Hardware üblicherweise immer ausreicht und man bereits in den Basiskonfigurationen eines Servers oft eine bessere Ausstattung angeboten bekommt, als benötigt wird.

Für größere Umgebungen sollte man jedoch ähnlich den beschriebenen Beispielszenarien genau untersuchen, was eine konkrete Anwendung benötigt oder benötigen wird, anstelle einer pauschalen Empfehlung zu folgen. Eine bestehende Umgebung kann vor einer Entscheidung genau auf Engpässe analysiert werden. Eine neue, noch unbekannte Umgebung sollte zumindest bzgl. der voraussichtlichen Einsatzbedingungen analysiert und konzipiert werden.

Eine Empfehlung, SSAS und SQL Server zu trennen,s ist in größeren Umgebungen immer eine Überlegung wert, da beide Server im Grunde verschiedene Aufgaben erfüllen müssen, die zwei optimierte und getrennt voneinander betriebene Server ggf. besser bedienen können als ein Allround-High-End-System, das auch entsprechend das Budget belasten könnte.