Horizontales Skalieren einer Analysis Services-Projektmappe
Oftmals gibt es Situationen, in denen ein Analysis Services-Datenbankadministrator (DBA) die Abfrageantwortzeit für eine steigende Zahl von Endbenutzern verbessern möchte. Zum Erreichen dieses Ziels gibt es zwei Möglichkeiten: Sie fügen dem vorhandenen Server mehr Leistung hinzu (zentrales Skalieren), oder Sie verteilen die Last auf mehrere kleine Server (horizontales Skalieren).
Das zentrale Skalieren einer Projektmappe endet in der Regel da, wo die vorhandene Hardware nicht mehr erweitert oder aktualisiert werden kann. Möglicherweise ist das vorhandene Motherboard nicht auf eine neue CPU-Version ausgelegt, oder der physische Adressraum für Arbeitsspeicher ist erschöpft. Das horizontale Skalieren einer Projektmappe hingegen bietet mehr Flexibilität, und Einschränkungen können viel einfacher überwunden werden. Wenn im Netzwerklastenausgleich (Network Load Balancer, NLB) keine Server mehr hinzugefügt werden können, kann der Projektmappe ein weiterer NLB hinzugefügt werden, und die Server können auf die verschiedenen NLBs verteilt werden.
In diesem Dokument wird eine theoretische Architektur für das horizontale Skalieren einer Analysis Services-Projektmappe beschrieben.
Szenario
Ein Analysis Services-Datenbankadministrator muss für die Endbenutzer einer Analysis Services-Projektmappe eine schnellere Abfrageantwortzeit erzielen, wobei allerdings das tägliche Downtimefenster für die Datenaktualisierung möglichst gering gehalten werden soll. Die ursprüngliche Anzahl von 80 Benutzern hat sich im vergangenen Monat verdoppelt, und es wird davon ausgegangen, dass sich die Anzahl in den kommenden sechs Monaten noch einmal verdoppeln wird. Ab dem siebten Monat wird mit einer Zunahme der Benutzeranzahl um monatlich vier Prozent gerechnet. Die Größe der Analysis Services-Datenbank beträgt derzeit 80 GB, und sie wächst jeden Monat um 6 GB. In der Datenbank sind zurzeit die Daten der letzten 12 Monate gespeichert. Zusätzlich soll in ihr der Verlauf der letzten drei Geschäftsjahre und auch des aktuellen Geschäftsjahrs verwaltet werden. Die durchschnittliche Verarbeitungszeit beträgt 2,5 Stunden, das Downtimefenster ist auf 0,5 Stunden beschränkt.
Alternativen
Nachdem Sie das Szenario durchgesehen haben, sind Sie vielleicht der Meinung, dass eine zentrale Skalierung des Servers die einzige Lösung ist. So kann zwar ein Dienst ohne Downtime bereitgestellt werden, bei der Verarbeitung käme es jedoch zu Leistungseinbußen. Zudem liegt die Anzahl von Benutzern derzeit bei 160, in sechs Monaten werden es aber 320 sein. Danach wird die Anzahl von Benutzern auf unbestimmte Zeit monatlich um 13 bis 16 Benutzer zunehmen. Ausgehend von diesen Zahlen ist damit zu rechnen, dass sich die Anzahl von Benutzern bei stabilem Wachstum zwischen dem 18. und 19. Monat noch einmal verdoppelt haben wird. In dieser Situation ist es problematisch, die geeignete Hardware zu bestimmen und ein Budget für Geräte zu rechtfertigen, die in den nächsten 12 Monaten nicht einmal zu 50 Prozent genutzt werden.
Glücklicherweise kann in SQL Server 2008 Analysis Services mithilfe der Funktion für schreibgeschützte Datenbanken eine horizontale Skalierung für die Projektmappe ausgeführt werden.
Architektur für horizontales Skalieren
Diese Architektur weist zwei Elemente auf:
ein physisches Layout, mit dem eine Maximierung des Durchsatzes von Endbenutzern erzielt werden soll
ein Operations Framework, mit dem eine Minimierung der Downtime erzielt werden soll
Physisches Layout
Die Lösung besteht aus drei Hauptkomponenten:
der Verarbeitungsumgebung
dem Storage Area Network (SAN)
der Datenzugriffsumgebung
In der ersten Komponente, der Verarbeitungsumgebung, findet unter Verwendung eines SAN-Segments die Aktualisierung und die Verarbeitung der Daten statt. In der zweiten Komponente, dem SAN, werden die Daten für die Verarbeitungs- und die Datenzugriffsumgebung aufbewahrt. In der dritten Komponente, der Datenzugriffsumgebung, werden die Daten für die Endbenutzer verfügbar gemacht.
Verarbeitungsumgebung
Die Verarbeitungsumgebung besteht aus einem Server, einer Verbindung mit dem SAN und einem logischen SAN-Volume, auf dem sich die Analysis Services-Daten befinden.
Storage Area Network (SAN)
Diese Lösung besteht aus zwei unabhängigen 'logischen SAN-Volumes': einem für die Verarbeitungsumgebung und einem weiteren für die Datenzugriffsumgebung.
Das SAN ist die Gruppe von Geräten, die den physischen Speicher für die mehrdimensionalen Datenbanken bereitstellen. Es ermöglicht sehr schnelle Verbindungen zwischen den Servern und dem Speicher, zu dem freigegebener Speicher, Cluster und Mechanismen für die Datenwiederherstellung gehören.
In diesem Dokument wird als 'logisches SAN-Volume' die Speichereinheit definiert, die vom Betriebssystem als ein physisches Laufwerk erkannt wird.
Datenzugriffsumgebung
Die Datenzugriffsumgebung besteht aus mehreren Servern, in der Regel zunächst aus drei Servern, die ein logisches SAN-Volume gemeinsam nutzen. Der Zugriff auf die Datenzugriffsserver erfolgt mithilfe eines NLB-Geräts, das alle eingehenden Anforderungen mithilfe eines Algorithmus für den Lastenausgleich weiterleitet.
Varianten des physischen Layouts
Sofern erforderlich, können Sie die folgenden Varianten verwenden, um die Leistung für die Projektmappe zu erhöhen.
Verarbeitungsumgebung
Unter Umständen können Sie zwei Server für die Verarbeitung verwenden, und zwar einen für die relationalen Datenbanken und einen zum Speichern der Analysis Services-Datenbanken.
Des Weiteren können Sie mehrere logische Volumes definieren, um die relationalen Datenbanken und die mehrdimensionalen Datenbank im SAN unabhängig voneinander zu speichern.
Datenzugriffsumgebung
Als Teil der Projektmappe werden mindestens zwei NLBs mit mindestens drei Datenzugriffsservern pro NLB-Gerät definiert.
Operations Framework
Der Betrieb der Lösung ist in drei Phasen unterteilt:
Datenverarbeitung
Downtimefenster
Zurücksetzen der Datenverarbeitung
Datenverarbeitung
In dieser Phase wird die mehrdimensionale Datenbank aktualisiert und verarbeitet. Sobald dieser Vorgang abgeschlossen ist, kann der Inhalt der mehrdimensionalen Datenbank gesendet werden, und die Daten werden in der Datenzugriffsumgebung für die Übertragung verarbeitet. Dieser Vorgang umfasst die folgenden Schritte:
Die Analysis Services-Datenbank wird vom Server für die Datenverarbeitung getrennt.
Das logische SAN-Volume mit der Analysis Services-Datenbank wird offline geschaltet.
Downtimefenster
In dieser Phase wird der Inhalt der aktualisierten Datenbank gegen den Inhalt der ursprünglichen Datenbank ausgetauscht.
Legen Sie die NLBs so fest, dass eingehende Anforderungen abgelehnt werden.
Trennen Sie die Analysis Services-Datenbanken von den einzelnen Datenzugriffsservern.
Schalten Sie das logische SAN-Volume, auf dem die Analysis Services-Datenbank für die einzelnen Datenzugriffsserver gespeichert ist, offline.
Tauschen Sie mithilfe von SAN-Befehlen die logischen SAN-Volumes zwischen Verarbeitungsumgebung und Datenzugriffsumgebung.
Schalten Sie das logische SAN-Volume, auf dem die Analysis Services-Datenbank für die einzelnen Datenzugriffsserver gespeichert ist, als schreibgeschütztes Gerät online.
Fügen Sie die Analysis Services-Datenbank im ReadOnly-Modus an die einzelnen Datenzugriffsserver an.
Legen Sie die NLBs so fest, dass eingehende Anforderungen akzeptiert werden.
Zurücksetzen der Datenverarbeitung
In dieser Phase wird der Inhalt des alten logischen SAN-Volumes aktualisiert und in der Verarbeitungsumgebung online geschaltet.
Spiegeln Sie mithilfe von SAN-Befehlen das logische SAN-Volume in der Datenzugriffsumgebung auf das logische SAN-Volume in der Verarbeitungsumgebung.
Schalten Sie das logische SAN-Volume, auf dem die Analysis Services-Datenbank für die Verarbeitungsumgebung gespeichert ist, als Gerät mit Lese-/Schreibzugriff online.
Fügen Sie die Analysis Services-Datenbank im ReadWrite-Modus an den Server in der Verarbeitungsumgebung an.