Mark Aslan Kuschels Blog

SQL Server, Azure, Business Intelligence, Smart Home

Einblick in die SQL Server Fast Track Architektur

Mit dem Release von SQL Server 2008 R2 hat Microsoft die Einsatzgebiete des SQL-Servers erweitert, indem neue Features und Editionen geschaffen wurden. Oftmals wird von SQL-Server Fast Track als eine neue Edition gesprochen. Doch dies ist nicht richtig, denn Fast Track liegt eine Enterprise Edition zugrunde – aber was ist Fast Track dann?

Ende 2009 veröffentlichte techconsult im Auftrag von Microsoft eine Studie, welche dem SQL-Server einen Anstieg des Marktanteils in Deutschland, gemessen an den verkauften Lizenzen, auf 26,1%. Damit wurde der Konkurrent Oracle (21,3%) erstmalig überholt, was vor allem auf die Lizenzpreise zurück geführt wurde.
Doch der Preis ist nicht immer das ausschlaggebende Argument für eine Lösung. Bei unternehmenskritischen Lösungen spielen Kriterien wie Stabilität und Performance möglicherweise eine deutlich größere Rolle. Und wer kennt diese Probleme im Software-Dschungel nicht. Das Beste Software-Produkt kann in verschiedenen Umgebungen sehr unterschiedliche Leistungswerte erreichen und auch mit der Stabilität ist es manchmal nicht weit her.
Hier lohnt sich ein Blick auf den Markt für SmartPhones. Mit Windows Mobile konnte Microsoft hier keinen Fuß fassen, dieses System ist zwar hochflexibel und anpassbar, doch genau dies führte zu einer Vielzahl von Installationen, wie sie unterschiedlicher nicht sein könnten. Viele Modelle frieren regelmäßig ein oder leiden unter geringer Geschwindigkeit – für manchen Technikfreak kein Problem, für die Allgemeinheit nervtötend. Apple war der erste Hersteller, der Software und Hardware bei Smartphones optimal aufeinander abstimmte und setzte damit einen neuen Trend, der einschlug wie eine Bombe.
Genau diese Idee liegt SQL Server Fast Track zu Grunde – Software und Hardware werden perfekt aufeinander abgestimmt. In der Praxis heißt das: bestimmte Hardware-Konfigurationen werden nach intensiven Tests als Fast Track-geeignet zertifiziert und mit dem hübschen Titel “Fast Track Referenz-Architektur” geschmückt.

Die Fast Track Architektur

Um eines vorweg zu nehmen: Fast Track eignet sich nicht für jedes Anwendungsszenario, genau genommen ist Fast Track speziell für Data Warehouses im Bereich von 4 bis 48TB Daten entwickelt worden.

Ein Fast Track-System besteht aus einem physischen Server, der über Fiber-Channel an mindestens eine SAN angeschlossen ist. Kleinere Fast Track-Systeme sind skalierbar und können durch das Einbauen von RAM sowie CPUs und Anschließen weiterer Storage-Einheiten weiter ausgebaut werden.
Das Fast Track-System beheimatet idealerweise das Data Warehouse sowie die Staging-Datenbanken, führt jedoch selbst keine ETL-Prozesse aus, beinhaltet keine Cubes, keine Data Marts und auch keine FrontEnd-Anwendungen.

Damit ist der Anwendungsbereich stark eingeschränkt. Wird dieser genauer betrachtet, ist dieses aber auch schlüssig. Data Warehouses werden klassischerweise mit großen Datenmengen aus den Vorsystemen gefüllt, daraus werden wieder große Datenmengen ausgelesen um Data Marts oder multidimensionale Datenbanken aufzubauen.
Für diese Szenarien ist mit einer Fast Track-Architektur ein signifikanter Performance-Vorteil möglich, da Hardware- und Softwarekonfiguration auf sequentielles Lesen und Schreiben optimiert sind, zufällige Lese- und Schreibvorgänge, und damit aufwändiges Neupositionieren der Schreib/Leseköpfe, werden vermieden. So ist es möglich, dass für diese Szenarien die Performance der Installation voraus berechnet werden kann bzw. die Dimensionierung des Servers berechnet werden kann, wenn die voraussichtlichen Workloads bekannt sind.

Technischer Einblick

Microsoft schreibt eine Reihe von Anforderungen an ein Fast Track System vor und stellt diese anhand eines Beispielsystems mit zwei AMD-Opteron Prozessoren und insgesamt acht CPU-Kernen vor. Um diesen Artikel allgemeiner zu halten werden basierend auf den AMD-Konfiguration folgende Variablen definiert und im weiteren Verlauf des Textes verwendet. Für Intel basierte Systeme ist das Verhältnis der CPU-Kerne pro CPU anders.

n  -  Anzahl SQL-Server Datenbanken (beliebig)
k  -  Anzahl CPU-Kerne
p  -  Anzahl verwendeter Prozessoren
s  -  Anzahl verwendeter Storage-Einheiten (SAN)
f  -  Anzahl verwendeter Festplatten insgesamt
r  -  Anzahl RAID-1-Paare je Storage-Einheit

  • Minimum 4 GB RAM je Kern
  • Lokal mindestens zwei Festplatten im RAID-1 für OS und SQL-Server Installation
  • Je physischer CPU wird in der Regel eine Speicher-Einheit zugeordnet, also s = p.
    Im Endeffekt wird je verfügbaren CPU-Kern ein Platten-Paar für Datenbankdateien sowie ein Platten-Paar je CPU-Sockel für Protokolldateien benötigt.
    f = 2*k + 2*p
  • Verbindung zum Speicher, in Form eines SANs, muss über Fiber Channel erfolgen
    Der Bereich im FC-Switch muss isoliert sein, ebenso muss Multipath I/O (MPIO) verwendet werden
  • Im SAN werden die Platten in RAID-1-Paaren à zwei Platten konfiguriert.
    Die Anzahl der RAID-1-Paare ist f / 2.
    Je Storage Einheit ergibt sich r = f / (2*s)
  • Jede LUN muss als separates Laufwerk in Windows erscheinen oder als separates Verzeichnis eingebunden werden

Damit dieses Kraftpaket seine Leistung auch wirklich entfalten kann, muss die Konfiguration der Datenbanken nach den üblichen Empfehlungen erfolgen, nur dass diese hier nicht auf Laufwerke, sondern LUNs zugeordnet werden.

  • Für die Datenbanken und TempDB werden paare aus zwei LUNs mit zwei Platten gebildet. In die ersten r Gruppen werden die Datenbanken gleichmäßig aufgeteilt, sie bestehen dann jeweils aus einer mdf- und r-1 ndf-Dateien
  • Die Protokolldateien werden auf einer LUN abgelegt, welche aus der verbleibenden RAID-1-Gruppe besteht. Es werden n+1 ldf-Dateien abgelegt.
    • Der Speicher der Datenbankdateien wird bereits im Dateisystem reserviert, das automatische Datenbankwachstum ist deaktiviert

Die folgende Grafik zeigt Beispielhaft die Dateistruktur im RAID auf einer Speichereinheit.

image

Benchmark-Ergebnisse

Der Erfolg oder Misserfolg einer Fast Track Konfiguration misst sich in der Maximum CPU Core Consumption Rate (MCR), wobei dies für die Datenmenge steht, die ein einzelner CPU Kern bei einer Standardabfrage verarbeiten kann, unter der Annahme, dass die Daten Seitenkomprimiert vorliegen.

Mit dem Referenzsystem bestehend aus 2x AMD Opteron CPUs mit je vier Kernen = 8 Kerne gesamt, 4x 8Gbps Fiber Channel HBA Anschlüsse auf zwei SANs wurde im Test bei Microsoft eine MCR von 200 MB/s erreicht, das sind also 1.600 MB/s Leistung des Gesamtsystems.
Ein Ergebnis, das sich sehen lassen kann.

Spielregeln bei Fast Track

Um den SQL-Server dazu zu bringen zufällige Schreib/Lesevorgänge zu vermeiden, muss das Datenbankdesign wohl durchdacht sein. Die Empfehlungen hierfür sind im Architektur-Referenz-Handbuch für Fast Track genau beschrieben und bestehen im wesentlichen aus folgenden Punkten:

  • Microsoft empfiehlt für Tabellen, die in der Regel komplett, oder zumindest zu einem großen Teil abgefragt werden, den Einsatz von Heap-Tabellen. Wobei hier gleich eine Einschränkung gesetzt wird, denn Heap-Tabellen erreichen ihren maximalen Datendurchsatz bei 32 Datenbankdateien, weshalb auf Data Warehouse-Ebene für Faktentabellen der Einsatz von Heap-Tabellen auf Fast Track Systemen nur bis 16 CPU-Kerne empfohlen wird.
    Ist dies der Fall sollte nach Art der Abfrage partitioniert werden, bei dem Aufbau von Cubes sollte sich die Partitionierung an der des Cubes ausrichten
  • Tabellen mit gruppierten Indexen werden logischerweise empfohlen, wenn erwartet wird, dass Abfragen häufig auf einen bestimmten Schlüssel erfolgen. Sinnvoll kann ein gruppierter Index auch sein, wenn nach Datum partitioniert wurde. Die Verwendung von gruppierten Indexen in anderen Fällen sollte genau überdacht werden, da der Index, und somit die Daten, möglicherweise fragmentiert, was zufällige Lese/Schreibvorgänge und somit starke Performanceeinbrüche zur Folge hätte.
    Auch hier ist das A und O wieder die gut überlegte Wahl der Partitionierung.
  • Nicht gruppierte Indexe sollten nach Möglichkeit vermieden und wirklich nur dann eingesetzt werden, wenn es Abfragen mit einer sehr kleinen Anzahl von Zeilen geben sollte
  • Um der Fragmentierung Herr zu werden sollten Indexe nicht reorganisiert, sondern neu aufgebaut werden. Bei dem Neuaufbau eines Index sollte SORT_IN_TEMPDB = True gesetzt sein, um eine Fragmentierung der Dateigruppe vorzubeugen

Diese Regeln sind im Bezug auf ein idealtypisches Data Warehouse schlüssig. Abweichende Anforderungen, durch Wünsche des Auftraggebers oder mangelndes Wissen des Architekten, können bei einem Fast Track-Projekt leicht zu einer Herausforderung werden. Die Beachtung dieser Regeln ist wärmstens zu empfehlen, um erfolgreich ein schnelles Fast Track Datawarehouse zu implementieren.

Weitere Informationen

Gibt es bei Microsoft.

Dieser Artikel wurde auch im Business Intelligence Blog der PTSGroup veröffentlicht