Unter den Self-Service Businness Intelligence Systemen ist MicroStrategy seit Jahren ein Big Player und wird trotz konsolidierender Marktvorherrschaft seitens Microsofts immer noch von vielen Unternehmen verwendet und teilweise auch neu eingeführt. Eine gute Integration in Microsoft Office, Mobile Apps und Plattformunabhängigkeit sind einige der Gründe, warum viele Kunden die Plattform schätzen. Während die Software durch die Ausführung im Browser grundsätzlich auf jedem Betriebssystem genutzt werden kann, ergeben sich bei der Administration erhebliche Unterschiede je nachdem welches Betriebssystem auf den MicroStrategy Servern läuft.
Ausgangslage
Die BI-Plattform lässt sich sowohl auf Windows als auch auf Linux einrichten, allerdings wird schnell klar, dass MicroStrategy von Haus aus ein Windows System ist. Auf Windows Systemen stehen für die verschiedenen Administrationsaufgaben diverse GUI-basierte Tools zur Verfügung, teils ist sogar ein Trend der Aufgabenbündelung in der relativ neuen MicroStrategy Workstation zu beobachten. All diese Tools stehen auf Linux nicht, oder nur sehr eingeschränkt als X11 GUIs zur Verfügung. Viele der Funktionen lassen sich nur durch Aufruf von Shell Skripten benutzen, was viele Nachteile bezüglich Zentralität, Logging und Überwachung bedeutet. Um eine bessere, effizientere Administration unter Linux zu ermöglichen, wurde ein Steuerframework in Python entwickelt, welches hier nun vorgestellt werden soll.
Auf der anderen Seite ist Linux aufgrund seiner hohen Stabilität und einfach Wartung insbesondere in großen Systemen auf Unternehmensebene nach wie vor sehr beliebt. Der Kunde kann dabei sowohl auf kostenlose Distributionen wie OpenSUSE oder Fedora zugreifen oder deren proprietären Varianten SUSE Linux Enterprise Server und Red Hat Enterprise Linux mit Enterprise-Level- und Long-Term-Support nutzen. Letzteres ist im Allgemeinen die Regel. Daher ergibt sich das fundamentale Problem ein hauptsächlich für Windows gewartetes Produkt auf Linux Systemen effizient zu betreiben. Bevor auf die dabei aufkommenden zentralen Probleme näher eingegangen wird, soll zunächst ein grober Überblick über den Aufbau einer MicroStrategy Umgebung gegeben werden, um die Prozesse besser verstehen zu können.
Übersicht MicroStrategy Umgebung
Ein klassisches Setup für MicroStrategy im 3‑Tier Betrieb stellt sich wie folgt dar: Im Zentrum aller Operationen steht der Intelligence Server, er verarbeitet die über das Frontend abgesetzten Anfragen in SQL-Queries für das angeschlossene Datawarehouse (DWH) und liefert die Ergebnisse zurück. Die gesamte Modellierung der Daten, d.h. die Verknüpfung der Datenbanktabellen mit Attributen, Metriken, usw. findet hier statt. Nutzerverwaltung, ACL, Migrationspakete und Nutzerstatistiken liegen neben vielen weiteren Aufgaben ebenso im Leistungsspektrum des Intelligence Servers. Die gesamten Daten hierzu speichern MicroStrategy in verschiedenen Meta Datenbanken (i.d.R. seperater Server) in Form einer relationalen Datenbank (z.B. Postgres). Der Nutzer kommuniziert nicht direkt mit dem Intelligence Server, sondern über den MicroStrategy Web Server. Dieser stellt mittels Apache Tomcat für die Client Rechner eine Weboberfläche als Frontend bereit, auf welcher die Nutzer ihre BI Analysen machen. Die drei Ebenen der 3‑Tier Umgebung setzten sich also zusammen aus Datenbanken (Meta +DWH), Intelligence Server, Web Server. Für den ordnungsgemäßen Betrieb müssen, je nachdem welche Services gefordert sind, verschiedene Dienste insbesondere auf dem Intelligence Server und Web Server laufen und überwacht werden. Das Setup für das diese Python Lösung entwickelt wurde hat hier beispielsweise neun, bzw. fünf Dienste Auf dem Intelligence und Webserver. Während diese Architektur auf Windows und Linux Systemen identisch ist, kommen wir nun zu den Linux-spezifischen Besonderheiten und Problemen.
Problemstellung
In Linux Serverumgebungen steht in der Regel nur die Kommandozeile per SSH zur Verfügung, oft über mehrere Tunnel was die Performance von X11 Protokollen erheblich einschränkt. Wie eingangs erwähnt, stellt MicroStrategy Shell Skripte zur Verfügung, um diese Dienste zu starten und zu stoppen. Diese müssen alle einzeln in der richtigen Reihenfolge ausgeführt werden, um das System insbesondere im Rahmen von Wartungsarbeiten hoch und runterzufahren. Um den Status dieser Dienste abzufragen, gibt es entweder manuell auszuführende Shell Skripte oder man muss sogar mühsam mittels Prozessliste herausfinden, ob die Anwendung läuft. Dabei ist anzumerken, dass die Skripte keiner einheitlichen Ausgabe folgen und teilweise auch nur unzureichend mittels Prozessliste überprüfen. Ein Beispiel in diesem Zusammenhang ist Tomcat, wo ein laufender Prozess noch nicht garantiert, dass der Webserver ordnungsgemäß funktioniert. Ebenso gibt es keine zentrale Logdatei die allumfassenden Informationen dazu zur Verfügung stellt, bzw. die Logdatei ist so granular aufgebaut, dass eine schnelle Überprüfung unmöglich ist. Hinzu kommen sich ständig wandelnde Anforderungen, weil MicroStrategy im Rahmen von Updates Dienste anders strukturiert, entfernt neue hinzufügt. Beispiele sind die Einführung von Platforms Analytics und Apache Kafka als Streamhandler für Echtzeitdaten. Zusätzlich muss auch bedacht werden, dass in der Regel nicht eine, sondern mindestens drei solcher 3‑Tier Umgebungen parallel laufen (Entwicklung, Test, Produktion). Die oben genannten Probleme münden also in folgende Anforderungen an eine Steuersoftware:
- SSH freundlich, ressourcenschonend
- Zentrales Logging
- Erweiterbarkeit und Anpassungsfähigkeit
- Serverüberwachung, sichere Überprüfungen
Umsetzung mit Python
Aufbau
Um die oben genannten Anforderungen zu erfüllen, wurde ein vielschichtiges, mittels Objektorientierung abstrahiertes Framework in Python geschaffen. In Abb. 1 ist der Aufbau auf Klassenebene skizziert. Die für die individuellen Services sehr unterschiedlichen Steuerroutinen sind auf unterster Ebene (Services) positioniert, kommunizieren aber über ein standardisiertes Protokoll mit den darüber liegenden Ebenen. Dadurch können Veränderungen in den Anforderungen schnell und einfach umgesetzt werden. Um mehrere Aufgaben in Joblisten zu bündeln, wurde eine standardisierte Dispatcher Klasse implementiert. Um das Framework schnell und einfach in verschiedenen Umgebungen zur Verfügung zu stellen sind alle Konfigurationen in JSON Dateien gespeichert.
Versionierung
Zur Versionierung und für das Rollout auf den einzelnen Servern kommt Gitlab zum Einsatz, ein einfaches „Standard“ Git oder ähnliches System würde sich aber genauso eignen. Selbstverständlich sind Konfiguration und Source Code in unterschiedlichen Repositorien untergebracht. Beim Roll-Out kommt außerdem eine Setup Routine zum Einsatz, sodass sich das Framework innerhalb weniger Minuten bereitstellen lässt. Die Bildschirmausgabe erfolgt über das Control-Modul. Als Beispiel ist in Abb. 2 die Statusausgabe eines Intelligence Servers abgebildet. Um üblichen Standards gerecht zu werden und möglichst wenig 3rd-Party Software zu verwenden wurde wenn möglich nur mit den Klassen der Standard Python Library gearbeitet. Dies garantiert niedrige Anforderungen an das Zielsystem und einfache Einbettung von Code in bestehende Projekte und Umgebungen. Sämtliche Vorgänge werden zentral geloggt und das Logging lässt sich in Bezug auf Granularität und Erscheinungsbild individuell mittels JSON konfigurieren.
Um die ordnungsgemäße Funktion der Dienste zu überwachen werden die Statuskontrollen regelmäßig durchgeführt und eventuelle Veränderungen sofort per Mail an den Administrator weitergeleitet. Mittels SMS Dienst können diese auch wahlweise über das Mobilfunknetz zur Verfügung gestellt werden. So kann der Systemadministrator schnell reagieren, wenn es zu unvorhergesehen Problemen kommen sollte. Als weitere Neuerung gegenüber den Hersteller Tools ist noch die automatische Erstellung von Backups der diversen Meta Datenbanken in MicroStrategy zu erwähnen.
Ausblick und Weiterentwicklung
Aufgrund von Fallspezifischen Anforderungen arbeitetet das Framework zurzeit weitgehend getrennt auf Web- und Intelligence Server, eine zentrale Steuerung wäre aber mittels SSH auch ohne Probleme realisierbar. Des weiteren wird gerade an der Einbettung des neuen von MicroStrategy bereitgestellten Python Paket mstrio-py gearbeitet. Neben dem Import und Export von Daten für Datascience Anwendungen erlaubt es auch administrative Manipulationen wie Nutzerverwaltung und die Übernahme der Command Manager Funktionalität. Die automatische Deaktivierung von Nutzern anhand bestimmter Kriterien ist beispielweise ein neues Feature dieser Implementierung. Zusammen mit der bisherigen Funktionalität des eher im low-level Bereich angesiedelten Frameworks wird das Projekt so immer weiter zu einer allumfassenden, automatisierten Administrationslösung für MicroStrategy entwickelt.
Fazit
Kunden werden weiterhin Linux und MicroStrategy zusammen nutzen. Mit von Version zu Version wachsender Komplexität des MicroStrategy Systems werden die Anforderungen und der Aufwand den Systemadministrator immer größer, die Parallelität mehrerer Umgebungen verschärft das Problem. Hier bietet das Steuerframework in Python eine elegante Möglichkeit, standardisierte Prozesse mit wenig Aufwand durchzuführen, seine Systeme immer im Blick zu haben und dem Kunden auf diese Weise einen sowohl leistungs- als auch kostenorientierten Service zur Verfügung zu stellen.
