Sicheres Deployment einer BI-Lösung mit Bordmitteln und OpenSource-Tools

Die Bereitstellung einer Business Intelligence Lösung erscheint im ersten Moment als eine triviale Angelegenheit. Wer jedoch eine mühevoll und aufwendig entwickelte BI-Lösung nach erfolgreichem Test und Abnahme auf ein Produktivsystem übertragen musste, der weiss, wie mühevoll und aufwendig dieses Unterfangen trotz aller anfänglichen Vermutung sein kann.
Neben den technischen Herausforderungen, die eine für den rauen Betriebsalltag konfigurierte Umgebung mit sich bringt, sind auch fachliche Schwierigkeiten zu meistern, insbesondere dann, wenn eine bereits im laufenden Betrieb befindliche Lösung abgelöst werden soll. Einerseits sollen produktive Daten natürlich nicht verloren gehen, andererseits gilt es, Strukturänderungen und Steuerdaten vollständig und unbeschadet in die Produktivumgebung zu bringen. Es existieren zahlreiche Dritthersteller-Werkzeuge, die dies mehr oder weniger automatisch auf Knopfdruck realisieren können, diese kosten jedoch oft mehr als den sprichwörtlichen schmalen Taler und können damit das Projektbudget in die Höhe schnellen lassen. Aus diesem Grund möchte ich im folgenden Beitrag Lösungswege aufzeigen, die sich auf die Benutzung von SQL Server Bordmitteln und kostenlos erhältlichen OpenSource-Werkzeugen beschränken. Voraussetzung für das nachfolgend beschriebene Szenario ist, dass die produktive Umgebung nicht direkt aus der Entwicklungsumgebung erreichbar ist und somit nicht einfach ein direktes Deployment von dort aus geschehen kann. Ein Umstand, der aufgrund von strikten Sicherheitsbestimmungen sehr oft im realen Projektgeschäft angetroffen wird.

Die Datenbank

Zunächst sollte Klarheit darüber herrschen, welche Datenbankobjekte übertragen werden müssen. Vorbildliche Naturen können diese Frage mit einem Blick in die Historie ihrer professionellen Versionsverwaltung (natürlich inklusive Application LifeCycle Management) sogar des Nächtens im Halbschlaf beanworten (vielleicht haben sie auch mit Zettel und Stift mitgeschrieben), aber auch wenn diese Professionalität des Vorgehens nicht erreicht werden kann oder soll, gibt es es nützliche Hilfsmittel, die uns auf unter die Arme greifen helfen. Das OpenSource-Tool OpenDBDiff bietet die Möglichkeit, zwei Datenbank-Stände miteinander zu vergleichen. Es entsteht dabei ein SQL-Skript, dass ausgeführt auf der Zieldatenbank die ausgewählten Objekte synchronisiert. Dabei sei angemerkt, dass hierbei eigentlich nur Tabellenobjekte kritisch sind, da sich alle anderen, wie Views, Stored Procedures und User-Defined Functions, auch durch Löschen und Neu-Anlegen auf den gleichen Stand bringen lassen. Aber wenn wir OpenDBDiff ohnehin gestartet haben, sparen wir uns die Mühe.

Der zweite Schritt besteht im Abgleich von Steuerdaten, die zumeist in Konfigurationstabellen schlummern. Dazu kann uns das Tool TableDiff dienen, mit dessen Hilfe Unterschiede in Tabellendaten abgeglichen werden, indem auch hier SQL-Skripte generiert werden. Das Tool ist Bestandteil der SQL Server Installation und lässt sich zumeist unter C:\Program Files\Microsoft SQL Server\100\COM finden und aufrufen, wobei der Pfad je nach SQL Server Version und dessen Installationsverzeichnis varieren kann. TableDiff geht dabei tabellenweise vor, weshalb es sich anbietet, eine Batchdatei zu programmieren, die den Aufruf pro Tabelle automatisiert.

rem Server festlegen

set sserver=localhost

set dserver=localhost

rem Datenbanken festlegen

set sdb=AdventureWorksDW

set ddb=AdventureWorksDW2008

rem Pfade definieren

set exepath=“C:\Program Files\Microsoft SQL Server\100\COM\tablediff.exe“

set destfolder=D:\SQL

rem Schema festlegen

set schema=dbo

for %%t in (dimCurrency dimScenario) do (

%exepath% /sourceserver %sserver% /sourcedatabase %sdb% /sourceschema %schema%   /sourcetable %%t /destinationserver %dserver% /destinationdatabase %ddb% /destinationschema %schema% /destinationtable %%t -f „%destFolder%\changeScript(%schema%_%%t).sql“

)

Wir haben nun eine Reihe von SQL-Skripten, die nur noch auf der Zieldaten ausgeführt werden müssen, um die Datenbankstruktur in einen identischen Zustand zu bringen.

SSIS-Pakete und Cube-Defintionen

Es gilt nun, sowohl SSIS-Pakete und Cube-Definitionen zu übertragen. Dies ist etwas einfacher, da sowohl für SSIS- als für SSAS-Projekte einen Deployment-Wizard existiert, der uns das Bereitstellen auf dem Zielsystem (fast) vollständig abnimmt. Im Falle von SSIS-Paketen besteht weiterhin die Möglichkeit, auf das Kommandozeilenwerkzeug dtutil zurückzugreifen, das, eingebettet in eine Batch-Datei, das Bereitstellen der Pakete nach einem Doppelklick automatisch übernehmen kann. Da wir selbst in kleineren Projekten intensiven Gebrauch von der SSIS-Paketkonfiguration machen, haben wir auch wenig Mühe damit, Informationen wie Server- oder Datenbanknamen zu aktualisieren. SSAS-Cubes   müssen nur noch verarbeitet werden und sind damit direkt bereit zum Einsatz. Aber auch hier gilt es, eine gewisse Vorsicht an den Tag zu legen, da doch der ein oder andere Fallstrick lauert. Einer dieser Fallstricke sind Cube-Rollen, die ohne weitere Konfiguration auf dem Zielserver überschrieben werden. Doch auch wenn wir dies explizit verhindern wollen (die entsprechende Option im Deployment Wizard heißt Retain Roles und Members), ist leider nicht immer gewährleistet, dass die bestehende Konfiguration erhalten bleibt. Hier hat sich der Workaround etabliert, die Rollendefinition auf dem Produktivserver zu sichern (Zu finden im entsprechenden Bereich in der XMLA-Datei, also der Datenbankdefinition, auf der SSAS-Datenbank) und nach dem Deployment zurückzuspielen.

Die Berichte

Für SSRS-Berichte hat sich ein ein Werkzeug bewährt, dass es uns ermöglicht, Berichte direkt vom (Test)Berichtsserver herunterzuladen und auf den (Produktiv)Berichtsserver zu übertragen. Dazu wird neben den Berichtsdefinitionen in Form von .rdl-Dateien eine Batchdatei generiert, in der nur noch die URL des Zielsystems hinterlegt werden muss. Nach einem Doppelklick können wir und zurücklehnen und die Deployment-Show genießen.

Fazit

Mit dem vorgestellen Vorgehen und Werkzeugen ist es uns, ein recht elegantes Deployment unserer BI-Solution auf entfernte Umgebungen vorzunehmen. Großer Vorteil dabei ist die Möglichkeit, weite Teile durch Batch-Dateien und Konfigurationen zu automatisieren und damit den Aufwand mehrmaliger Deployments zu merklich reduzieren.

2 Antworten auf „Sicheres Deployment einer BI-Lösung mit Bordmitteln und OpenSource-Tools“

Schreibe einen Kommentar