Bachelorthesis Performanceoptimierung der Configuration Management Database des Open Source Service Management Systems OTRS unter Berücksichtigung von Indizierung und Partitionierung und Beibehaltung des Meta-DatenModells Vorgelegt am: 18.8.214 Von: Kaiser, Ricky Paul-Jäkel-Straße 2 9113 Chemnitz Studiengang: Studienrichtung: Wirtschaftsinformatik Wirtschaftsinformatik Seminargruppe: WI211 Matrikelnummer: 4246 Praxispartner: c.a.p.e IT GmbH Schönherrstraße 8 9113 Chemnitz Gutachter: Dipl.-Math. Rico Barth (c.a.p.e. IT) Prof. Dr. Wolfgang Oehme (Staatliche Studienakademie Glauchau)
Themenblatt Seite II
Inhaltsverzeichnis Inhaltsverzeichnis Inhaltsverzeichnis... III Abbildungsverzeichnis... V Tabellenverzeichnis... VI Abkürzungsverzeichnis... VII 1 Aufgabe und Ziel... 1 2 Framework und Komponenten... 2 2.1 OTRS... 2 2.2 KIX4OTRS... 3 2.3 Programmaufbau... 4 2.4 CMDB... 6 2.5 CMDB-Modul einer Standard-OTRS-Installation... 8 2.5.1 Datenbank... 8 2.5.2 Frontend- und Systemmodule... 11 2.5.3 Datenbankinteraktion mittels der Systemmodule... 13 3 Entwicklungsstadien von KIXOptimizedCMDB... 15 3.1 Erste Entwicklungsstufe - Beta 1... 15 3.1.1 Analyse und Optimierungsansätze... 15 3.1.2 Datenbankanpassungen... 16 3.1.3 Änderung und Erweiterung des Programmcodes... 17 3.1.3.1 Systemmodul-Erweiterung XML.pm... 17 3.1.3.2 Systemmodul XML.pm... 19 3.1.3.3 Module für Tabellenerstellung... 2 3.1.4 Test... 21 3.1.5 Auswertung... 24 3.2 Zweite Entwicklungsstufe - Beta 2... 26 3.2.1 Analyse und Optimierungsansätze... 26 3.2.2 Datenbankanpassungen... 26 3.2.3 Änderungen im Programmcode... 28 3.2.3.1 Systemmodul-Erweiterung XML.pm... 28 3.2.3.2 Systemmodul XML.pm... 29 3.2.3.3 Systemmodul ConfigItem.pm... 29 3.2.3.4 Systemmodul-Erweiterung Version.pm... 31 3.2.3.5 Änderungen der Tabellenerstellung... 33 3.2.4 Test und Auswertung... 33 3.3 Letzte Entwicklungsstufe - Beta 3... 34 3.3.1 Analyse und Optimierungsansätze... 34 3.3.2 Datenbankanpassungen... 34 Seite III
Inhaltsverzeichnis 3.3.3 Änderungen im Programmcode... 35 3.3.3.1 Systemmodul XML.pm... 35 3.3.3.2 Änderungen der Tabellenerstellung... 37 3.3.3.3 Test-Script... 37 3.3.4 Test und Auswertung... 38 4 Schlussbetrachtung und Ausblick... 39 Quellenverzeichnis... 4 Anhangsverzeichnis... 42 Seite IV
Abbildungsverzeichnis Abbildungsverzeichnis Abbildung 1 Abbildung 2 Abbildung 3 Abbildung 4 Abbildung 5 Abbildung 6 Abbildung 7 Abbildung 8 Abbildung 9 Abbildung 1 Abbildung 11 Abbildung 12 Abbildung 13 Abbildung 14 Abbildung 15 Abbildung 16 Abbildung 17 Abbildung 18 Abbildung 19 Abbildung 2 Abbildung 21 Übersicht des Agenten-Frontend in OTRS... 3 Erweiterung von OTRS durch mehrere Pakete... 4 Schematischer Aufbau von OTRS... 4 Entity-Relationship-Diagramm der OTRS-CMDB... 8 Aufteilung des Systemmoduls der CMDB... 11 Beispiel einer Select-Anweisung in OTRS... 13 Beispiele für Insert Into, Update und Delete -Anweisungen... 14 Erste Anpassung in der Methode _XMLHashSearch()... 17 Zweite Anpassung in der Methode _XMLHashSearch()... 18 Ausschnitt der Methode XMLHashAdd() des XML-Objektes... 19 Ausschnitt der Methode XMLHashGet() des XML-Objektes... 2 Konfigurationsschlüssel für den ereignisbasierten Modulaufruf... 21 Beispiel für die Verwendung des PerfLog-Moduls... 22 Auskommentierung der Komplett-Abfrage der Tabelle... 28 Komplett-Abfrage der Tabelle im Else-Zweig... 29 Bestimmung der Suche in der Versionstabelle... 3 Ordnerstruktur und Auswahl der Moduldatei... 31 Beispiel einer SQL-Anweisung auf die Versionstabelle... 32 Abfrageoptimierung der ConfigItem-Daten... 33 Klassen-Tabellenkonfiguration in Beta 3... 35 Ermittlung der ID des xml_content_value-wertes... 37 Seite V
Tabellenverzeichnis Tabellenverzeichnis Tabelle 1 Tabelle 2 Tabelle 3 Tabelle 4 Tabelle 5 Tabelle 6 Tabelle 7 Tabelle 8 Datenbankstruktur für das CMDB-Modul von OTRS... 9 Wichtige Systemmodul-Dateien... 12 XML-Datensatz 1... 15 XML-Datensatz 2... 15 Neue Struktur zur Speicherung der klassenspezifischen Attribute... 16 Anzahl der CIs und Versionen der Testdaten... 22 Tabellenstruktur der Versionstabelle in der Beta 2... 27 Vergleich Klassen-Tabellen von Beta 2 und Beta 3... 35 Seite VI
Abkürzungsverzeichnis Abkürzungsverzeichnis AGPL CI CMDB CSV DBMS DTL ERD GNU ITSM OTRS Affero General Public License Configuration Item Configuration Management Database Comma- oder Character-separated values (Dateiformat) Datenbank-Management-System Dynamic Template Language Entity-Relationship-Diagramm GNU s Not Unix IT-Service-Management Open Ticket Request System Seite VII
Aufgabe und Ziel 1 Aufgabe und Ziel Das Ziel dieser Arbeit war es die Performance der Configuration-ManagementDatabase (CMDB)1 des Open Source Ticketsystem OTRS (siehe folgendes Kapitel) erheblich zu steigern. Dadurch sollte vor allem die Suche nach Configuration Items (kurz als ConfigItem oder CI bezeichnet) in großen2 CMDB-Umgebungen verbessert werden. Um dies zu erreichen, mussten strukturelle und programmiertechnische Optimierungen der CMDB entwickelt und umgesetzt werden. Die Aufgabe bestand darin, die, in einer Standard-Installation von OTRS gegebene Datenbankstruktur und die Programmbestandteile für die CMDB zu analysieren. Daraus erkennbare Optimierungsmöglichkeiten der Datenbank und des Programmcodes umzusetzen und in OTRS zu implementieren. Die Verbesserung sollte als eigenständige Erweiterung (in OTRS als Paket bezeichnet) entwickelt, durch weitere Optimierungen weiterentwickelt und auf ihre Wirksamkeit mit Hilfe geeigneter Tests geprüft werden. Das Paket (in der nun finalen Version KIXOptimizedCMDB benannt) muss für den praktischen Einsatz sowohl mit einer Standard-Installation des OTRSFrameworks, also auch mit der Erweiterung KIX4OTRS3 sowie mit beliebigen Datenbanktypen kompatibel sein. Die Optimierungen beschränken sich bezogen auf die Datenbank aber nur auf Änderungen einzelner Tabellen und Einsatz geeigneter Indizes. Anpassungen von datenbankspezifischen Parametern oder Verbesserungen der Datenablage der Datenbankdateien werden nicht betrachtet. Änderungen an diesen Stellen können nicht durch ein in OTRS installierbares Paket vorgenommen werden, sondern müssen entsprechend den verwendeten Systemen vor Ort analysiert und angepasst werden. Im folgenden Kapitel werden das Framework OTRS und die umfangreiche Erweiterung KIX4OTRS erläutert. Dadurch sollen grundsätzliche Zusammenhänge geschaffen und das Verständnis nachfolgender Erklärungen vereinfacht werden. Im weiteren Rahmen dieser Bachelorthesis sind das CMDB-Modul mit seiner Datenbankstruktur und programmtechnische Anbindung einer Standard-OTRSInstallation beschrieben. Danach folgen die einzelnen Entwicklungsschritte der KIXOptimizedCMDB-Erweiterung mit ihren geplanten Optimierungsmöglichkeiten, deren Umsetzung, die Tests und deren Ergebnisse. 1 2 3 Siehe hierzu Kapitel 2.4 > 2. Configuration Items Näheres dazu im Kapitel 2.2 Seite 1
Framework und Komponenten 2 Framework und Komponenten 2.1 OTRS Das Open Ticket Request System (OTRS) ist ein Help Desk System4, das Kunden und Mitarbeitern (sogenannte Agenten) als zentrale Plattform zur Bearbeitung sowie Lösung von gemeldeten Störungen und Service- bzw. Informationsanfragen zur Verfügung steht. Als Open Source Ticketsystem unter der GNU Affero General Public License (AGPL) steht es kostenfrei zum Download bereit 5. OTRS kann unter Linux, Mac und Windows betrieben werden. Nach der Installation und Konfiguration von OTRS kann ein Client (der Benutzer; z.b. ein Servicemitarbeiter), unabhängig von seinem eigenen Betriebssystem, OTRS in jedem beliebigen modernen Webbrowser aufrufen und bedienen.6 OTRS ermöglicht eine strukturierte Erfassung, Einteilung und Weiterverarbeitung von Störungsmeldungen sowie Service- und Informationsanfragen. Solche Meldungen beziehungsweise Anfragen können als E-Mail oder Telefonanruf eingehen oder direkt im Kunden-Webfrontend von OTRS erstellt werden 7. Dabei erhalten diese eine individuelle Nummer und sind anschließend als sogenanntes Ticket im System hinterlegt. Aufgrund der eindeutigen Identifikationsnummer jedes Tickets können Nachrichten auch bei wechselnden E-Mail-Verkehr dem Ticket direkt zugeordnet werden. Damit ist ebenfalls jeder Bearbeitungsschritt (z.b. eine Antwort, eine Nachfrage oder eine firmeninterne Kommunikation zwischen zwei Agenten) dokumentiert.8 Dadurch ist es immer möglich, den aktuellen, als auch ältere Bearbeitungsstände des Tickets nachzuvollziehen. OTRS ist mehrsprachig und lässt sich einfach an ein Corporate Design anpassen sowie mit zusätzlichen Funktionen und Modulen (oft in Paketen zusammengefasst) erweitern.9 Abbildung 1 zeigt die Übersicht von OTRS, in welcher der Kopfbereich mit den verschiedenen Modulen, einigen Tickets in unterschiedlichen Kategorien und eine 7-Tage-Statistik dargestellt sind, aus Sicht des SuperUser-Agenten. 4 5 6 7 8 9 vereinfacht: Software, um Kundenanfragen zu klassifizieren, zu bearbeiten und zu beantworten online: The OTRS Open Source Community, 214 (3.7.214) vgl. OTRS 3.3 - Admin Manual, 213, S. 11/12 online: OTRS Help Desk Software Features, 213 (3.7.214) vgl. OTRS 3.3 - Admin Manual, 213, S. 1 online: Produkte::OTRS, 214 (3.7.214) Seite 2
Framework und Komponenten Abbildung 1 2.2 Übersicht des Agenten-Frontend in OTRS KIX4OTRS KIX4OTRS (vormals Customer Information and Communication System) ist nach OTRS::ITSM1 die zweitgrößte Erweiterung für OTRS. Es wird von der Firma c.a.p.e. IT GmbH mit Sitz in Chemnitz entwickelt und stetig verbessert. KIX4OTRS erweitert das OTRS-Framework um viele hilfreiche Funktionen und bietet für die wichtigsten Masken (die verschiedenen Oberflächen von OTRS) eine übersichtlichere beziehungsweise detailliertere Darstellung. Darüber hinaus stellt es Schnittstellen zu weiteren nützlichen Tools zu Verfügung und erweitert durch integrierte Zusatzmodule den Funktionsumfang gegenüber einer Standard-OTRSInstallation.11 Das Kernpaket von KIX4OTRS (KIXCore) ermöglicht es mehreren weiteren Paketen bestehende Funktionen von OTRS zu verändern, ohne dafür Dateien überschreiben zu müssen 12. Ohne KIXCore wäre dies lediglich für ein weiteres Paket möglich. Mit KIXCore werden durch Priorisierung die installierten Pakete in eine Hierarchie gebracht. Bei gleichnamigen Modulfunktionen nimmt OTRS nun die entsprechende Datei aus dem höchst-priorisierten Paket. Gibt es in diesem Paket die Datei nicht, weil dieses Paket diese Funktion nicht überschreibt, wird die Datei in dem nächst-niedriger-priorisiertem Paket gesucht. Dies geht solange, bis 1 11 12 OTRS IT-Service-Management Paket: beinhaltet unter anderem das CMDB-Modul online: Produkte::KIX4OTRS, 214 (3.7.214) vgl. KIXCore.pod, 213 Seite 3
Framework und Komponenten schließlich die Standardfunktion im OTRS-Ordner verwendet werden muss. Abbildung 2 zeigt eine schematische Darstellung dieses Ablaufs, bei dem beispielsweise die Modulfunktion A geladen werden soll. Dabei muss in den Paketen die selbe Ordnerstruktur enthalten sein (je nachdem welche Ordner benötigt werden) wie im Standard-OTRS-Ordner. KIXOptimizedCMDB nutzt die Funktionalität der Priorisierung und setzt dadurch die vorherige Installation des KIXCore-Paketes voraus. Abbildung 2 2.3 Erweiterung von OTRS durch mehrere Pakete Programmaufbau Der Aufbau jedes Paketes beziehungsweise der einzelnen Modulfunktionen in OTRS kann mit drei Komponenten beschrieben werden. Diese sind die Konfiguration (1), die Funktionen (2) und zusätzliche Bestandteile (3), zum Beispiel für die Darstellung. Abbildung 3 soll den Aufbau anhand einer vereinfachten schematischen Darstellung der Ordnerstruktur13 von OTRS für die nachfolgenden Erklärungen verständlicher gestalten. Abbildung 3 13 Schematischer Aufbau von OTRS Das Kernel-Verzeichnis und alle benötigten Unterordner mit den jeweilig zu ersetzenden Dateien müssen in Paketen, die mit KIXCore registriert sind, ebenfalls enthalten sein. Seite 4
Framework und Komponenten Der erste Teil ist die Konfiguration des jeweiligen Moduls. Diese wird durch mindestens eine XML-Datei, die sogenannte Schlüssel beinhaltet, beschrieben und während des Programmablaufs ausgewertet. Die Schlüssel beschreiben unter anderem die Registrierung des Moduls. Diese umfasst Angaben zu notwendigen Rechten des Benutzers und in welchen Oberflächen das Modul bzw. die Funktion(en) genutzt werden kann.14 In diesen Schlüsseln können darüber hinaus auch benötigte Komponenten, wie CSS- oder JavaScript-Dateien, für das jeweilige Modul angegeben sein. Weitere Schlüssel bestimmen zum Beispiel vordefinierte Parameter wie Größen von Dialogfenstern, anzuzeigende Bilder oder Schnittstellen für Programmanbindungen. Mit Hilfe der Systemkonfiguration (kurz: SysConfig) in der Admin-Oberfläche kann die Konfiguration bei Bedarf nachträglich angepasst werden15. Nicht jedes Paket benötigt SysConfig-Schlüssel um zu funktionieren. Zum Beispiel, wenn das Paket nur bestehende Funktionen erweitert oder verändert. Bei KIXOptimizedCMDB ist das der Fall. Dieses Paket hat lediglich einen Schlüssel, um auf einen bestimmten Auslöser zu reagieren und dafür entsprechende Funktionen auszuführen (näheres dazu in Kapitel 3.1.3.3). Die zweite Komponente eines Moduls 16 sind die Funktionen. Diese sind in der Programmiersprache Perl geschrieben. Perl, ursprünglich für Textverarbeitung entwickelt, ist heute in vielen Bereichen wie beispielsweise in der Systemadministration, Web- und Netzwerkprogrammierung in Gebrauch. Sie eignet sich sowohl für prozedurale, also auch objektorientierte Programmierung und ist dabei schnell, übersichtlich und effizient einsetzbar. 17 Die einzelnen Funktionen von OTRS sind als Perl-Module (Dateien mit der Endung.pm ) zusammengefasst und in verschiedenen Ordnern des Frameworks hinterlegt. Methoden, die nur das Modul selbst benötigt und Operationen, die den Funktionsumfang des Moduls beschreiben, sind im Ordner Module von OTRS enthalten. Diese Dateien werden als sogenannte Frontend-Module bezeichnet18. Auf diese Dateien greift OTRS zu, wenn das jeweilige Modul (zum Beispiel die Übersicht) durch einen Benutzer aufgerufen wird. Methoden, die hingegen systemspezifische Aufgaben, wie beispielsweise Datenbankabfragen durchführen, befinden sich im System -Ordner und werden als Systemmodule bezeichnet19. Auf die darin enthaltenen Funktionen können und müssen andere Module zugreifen, wenn sie modul-unabhängige oder systemweite Operationen ausführen wollen. Jedes Systemmodul wird dabei mittels des use-befehls mit 14 15 16 17 18 19 vgl. OTRS 3.3 - Developer Manual, 213, S. 3 vgl. OTRS 3.3 - Admin Manual, 213, S. 96 (31.7.214) zum Verständnis: Mit Modul kann eine einzelne Programmfunktion (z.b. die Übersicht) oder einzelne Frontend- bzw. Systemmodule (die Perl-Module) gemeint sein. vgl: KIRRILY, 213 (11.8.214) vgl. OTRS 3.3 - Developer Manual, 213, S. 5 / 31 vgl. OTRS 3.3 - Developer Manual, 213, S. 4 / 32 Seite 5
Framework und Komponenten Modulpfad und -name (z.b. use Kernel::System::DB) eingebunden und über seine jeweilige new() -Methode als Objekte instanziiert (z.b. DBObject oder ITSMConfigItemObject). Dadurch kann das Frontend-Modul auf die enthaltenen Funktion des System-Objektes zugreifen (in Form von Object->Funktion()). Dies entspricht dem objektorientierten Aufbau moderner Software. Die Systemmodule können durch zusätzliche Perl-Module erweitert werden, wenn diese sich in einem Ordner (unterhalb des System-Ordners) befinden, der die selbe Bezeichnung wie das Systemmodul besitzt. Dadurch gehören alle darin enthaltenen Dateien dem selben Namensraum des Systemmoduls an. Damit kann auf die Methoden dieser Dateien zugegriffen werden, als wenn diese im instanziierten Systemmodul enthalten wären. Da das Paket KIXOptimizedCMDB lediglich nur Systemfunktionen ersetzt, beinhaltet es keine eigenen Frontend-Module. Die dritte Komponente umfasst alle Bestandteile, die nicht zwingend in einem Modul beziehungsweise Paket enthalten sein müssen und sich fast ausschließlich mit dem Layout befassen. Zum Beispiel alle Oberflächen von OTRS werden mit Hilfe der OTRS-eigenen DTL-Dateien (Dynamic Template Language) erzeugt. Diese dienen als Vorlagen, die mit Daten aus den Frontend bzw. sogenannten Layout-Modulen gefüllt und beim Aufruf des Moduls in HTML-Seiten umgewandelt werden 2. Andere Bestandteile sind CSS-Dateien, für Layout-relevante Angaben, wie Farben und Größen definieren und die Javascript-Funktionen. Diese ermöglichen dynamisch die sichtbare Oberfläche des Moduls, also den Browserinhalt zu verändern, auszuwerten und gegebenenfalls an ein Frontend-Modul, mittels Ajax-Aufruf weiterzugeben. Ein weiteres Element sind alle Übersetzungen des Moduls. Diese werden im LanguageOrdner in einzelnen, nach Sprachen und Benutzer (Agent oder Kunde) separierten Perl-Modulen (z.b. de_agentmodulname.pm) hinterlegt 21. 2.4 CMDB Die CMDB in OTRS ermöglicht den Zugriff und die Verwaltung von Configuration Items. Als CI werden dabei im IT-Management sämtliche Betriebsmittel, wie zum Beispiel Computer, Telefone oder auch Standorte und Netzwerke bezeichnet, die an den Geschäftsprozessen der IT beteiligt sind.22 Das Modul besteht aus mehreren Frontend-Modulen, den dazugehörenden LayoutTemplates und einem Systemmodul, das auf mehrere Dateien aufgeteilt ist. Außerdem sind die Daten der gespeicherten Configuration Items auf mehreren Tabellen der von OTRS genutzten Datenbank verteilt. OTRS erlaubt die 2 21 22 vgl. OTRS 3.3 - Developer Manual, 213, S. 27 vgl. OTRS 3.3 - Developer Manual, 213, S. 37 vgl. KIX4OTRS Anwenderhandbuch, 214, S. 82 Seite 6
Framework und Komponenten Anbindungen an verschiedene relationale Datenbanksystemen, unter anderem zu MySQL, PostgreSQL, Oracle oder auch Microsoft SQL Server.23 Für die Test des KIXOptimizedCMDB-Paketes wurden bis jetzt nur die Datenbank-ManagementSysteme (DBMS) PostgreSQL und MySQL verwendet. Die CMDB, insbesondere das CMDB-Modul, ist keine Datenbank im technischen Sinne, sondern geht darüber hinaus24. Es dient nicht nur der einfachen Speicherung der Configuration Items, sondern bietet eine Übersicht über alle vorhanden CIs in der Web-Oberfläche und ermöglicht es neue CIs zu erstellen, zu bearbeiten und zu verknüpfen, um logische Zusammenhänge wie z.b. Netzwerke abbilden zu können. Dafür stellt OTRS vordefinierte CI-Klassen zur Verfügung. Es ist aber auch möglich weitere Klassen mit jeweils eigenen Attributen über die Admin-Oberfläche zu definieren25. Jede Änderung an einem CI wird als neue Version angelegt, dadurch können jederzeit auch ältere Konfigurationen des CIs eingesehen werden. Wie bei Tickets sind die einzelnen Bearbeitungsschritte zusätzlich in einer Historie dokumentiert.26 Jedes ConfigItem in OTRS hat bestimmte Pflichtattribute. Diese sind der Name, die Nummer (wird automatisch generiert), der Vorfall- und der Verwendungsstatus. Da die Pflichtattribute CI-Klassen-unabhängig sind, müssen diese nicht in der Klassendefinition beschrieben sein. Der Vorfallstatus kann vordefiniert beispielsweise die Werte Operativ, Warnung oder Vorfall annehmen. Dies zeigt an, ob mit dem jeweilige CI alles in Ordnung ist. Der Verwendungsstatus kann unter anderem die Werte Geplant, Produktiv, Abgelaufen oder In Reparatur annehmen und präzisiert dadurch den Status des CIs. Alle anderen Attribute wie zum Beispiel Typ, Seriennummer, Festplatte, IP, oder Telefonnummer sind klassenspezifisch und in der Klassendefinition konkretisiert. Das heißt, darin kann z.b. angegeben werden, durch welche Art von Eingabe- oder Auswahlfeld sie in einer Maske beschreibbar sind oder, ob nach diesen Attributen gesucht werden kann. In dem folgendem Kapitel wird das CMDB-Modul von OTRS, bezüglich Datenbankstruktur, Frontendmodule und programmiertechnisch Datenbankanbindung über die Systemmodule, genauer betrachtet. 23 24 25 26 online: OTRS::ITSM Features, 213 (31.7.214) vgl. OTRS 3.3 - ITSM Manual, 213, S.18 vgl. OTRS 3.3 - ITSM Manual, 213, S.64 vgl. KIX4OTRS Anwenderhandbuch, 214, S. 82-9 Seite 7
Framework und Komponenten 2.5 2.5.1 CMDB-Modul einer Standard-OTRS-Installation Datenbank An den Daten für ein CI sind insgesamt acht Tabellen beteiligt. Abbildung 4 zeigt ein Entity-Relationship-Diagramm (ERD)27 der acht Tabellen. Abbildung 4 Entity-Relationship-Diagramm der OTRS-CMDB Obwohl nicht alle acht Tabellen durch die Optimierung mit KIXOptimizedCMDB berührt werden, soll die folgende Tabelle 1 dennoch einen Gesamtüberblick der Tabellen mit ihrer jeweiligen Funktion und Inhalt geben, um einen Eindruck der Komplexität des CMDB-Moduls zu vermitteln. Dort, wo es für nachfolgende Kapitel relevant ist, sind die einzelnen Spalten der Tabelle unter den Erklärungen angegeben. Für die mit einem * versehenen Spalten existiert jeweils ein Index. Tabellenname Funktion / Inhalt configitem (nachfolgend als CI- bzw. ConfigItem-Tabelle bezeichnet) In dieser Tabelle sind die einzelnen CIs mit ihren klassenunabhängigen Attributen gespeichert. Dazu gehören ihre Nummer, die ID der jeweiligen Klasse (als Fremdschlüssel), die ID ihrer aktuellen Version und die IDs für ihre derzeitigen Verwendungs- und Vorfallstatus. Darüber hinaus ist enthalten, wer das CI erstellt beziehungsweise geändert hat (Agenten-ID) und wann dies geschehen ist. configitem_counter Diese Tabelle enthält die aktuelle Anzahl der ConfigItems pro Klasse als Integer. Das ist ein Datentyp, der vier Byte umfasst und nur ganze Zahlen bis fast 4,3 Mrd. (unsigned nur positive Werte) zulässt28. 27 28 erstellt mit PHPMyAdmin (Programm zu Datenbankverwaltung von MySQL im Browser) vgl. MySQL 5.7 Reference Manual, 214, S. 195 Seite 8
Framework und Komponenten Tabellenname Funktion / Inhalt configitem_definition In dieser Tabelle sind die Klassendefinitionen enthalten. configitem_history Hierin werden alle Änderungen an den einzelnen Configuration Items gespeichert. Diese Daten sind in der Historien-Funktion eines betrachteten CIs abrufbar. configitem_history_type Diese Tabelle enthält alle mögliche Typen, die einem neuen Historieneintrag zugewiesen werden können. Dies sind beispielsweise ConfigItemCreate, NameUpdate und LinkAdd. configitem_version (nachfolgend als Versionstabelle bezeichnet) Darin sind sämtliche Versionen aller ConfigItems enthalten. Eine Zuordnung zum jeweiligen CI ist über dessen ID als Fremdschlüssel gegeben. Die Spalten depl_state_id und inci_state_id speichern die, in dieser Version des ConfigItems, aktuellen Verwendungs- und Vorfallstatus. id*, configitem_id*, name, definition_id*, depl_state_id*, inci_state_id*, create_time, create_by* general_catalog Dies Tabelle enthält, ihrer Bezeichnung nach (dt. vereinfacht: allgemeiner Katalog ) neben den CMDBrelevanten Einträgen auch viele Daten für andere Bestandteile von OTRS. Für die CMDB werden hierin die Klassen selbst und spezielle Attribute der Klassen registriert und angegeben. Diese Attribute können darin mit vorgegeben Werte versehen werden (z.b. Typ eines Computer: Desktop, Server, ). xml_storage (nachfolgend als XMLTabelle bezeichnet) In dieser Tabelle werden alle CI-Klassen-spezifischen Attributwerte, die in der Definition angegeben sind gespeichert. Aber auch hier können Daten weiterer Module von OTRS enthalten sein. In der Spalte xml_type wird der Typ des Objektes gespeichert. Für ConfigItems kann dies zum Beispiel folgendermaßen aussehen: ITSM::ConfigItem::22 (die Zahl ist die KlassenIdentifikationsnummer). Die Spalte xml_key beinhalten die ID des Objektes. Bei CIs ist dies die Versions-ID. xml_type*, xml_key*, xml_content_key, xml_content_value Tabelle 1 Datenbankstruktur für das CMDB-Modul von OTRS Seite 9
Framework und Komponenten Die Klassendefinitionen ist als Kombinationen von Arrays und Hashes (ein sogenanntes Array of Hashes29) als Datentyp Varchar (variable character Zeichenfolgen unterschiedlicher Länge3) in der Datenbank gespeichert. Ein Array ist in Perl eine Variable, die eine Liste mit numerischen geordnete Indizes enthält 31. Ein Hash (in anderen Programmiersprachen auch als assoziatives Array oder einfach als Objekt bezeichnet) enthält ebenfalls eine Liste. Diese ist aber ungeordnet und die Indizes (Schlüssel) sind Strings, also Zeichenfolgen 32. Anhang 1 zeigt eine Klassendefinition anhand eines sehr einfachen Beispiels mit nur drei Attributbeschreibungen. Die Arrays sind darin Perl-typisch mit eckigen und die Hashes mit geschweiften Klammern dargestellt. Die Content-Daten in der xml_content_key-spalte der XML-Tabelle haben für ConfigItems am Beispiel des Attributs Type folgende Form: [1]{'Version'}[1]{'Type'}[1]{'Content'} Dieser Aufbau ist der Klassendefinition geschuldet. Dadurch ist es möglich das Array of Hashes ohne Umwege während des Programmablaufs aufzubauen. Dies vereinfacht anschließend eine Zuordnung zur Klassendefinition und damit eine weitere Verarbeitung. In einem Frontend-Modul (z.b. das um CIs anzuzeigen) wird dabei abgeglichen, ob die einzelnen Attribute der Definition (anhand des Key-Wertes) in den, aus der XML-Tabelle ausgelesenen Daten vorhanden sind. Gibt es für ein Attribut einen gespeicherten Wert, wird dieser entsprechend seines definierten Typs (Type in der Definition) ggf. aufbereitet. Dies ist zum Beispiel bei General-CatalogAttributen der Fall. In der Datenbank ist für dieses Attribut nur eine ID gespeichert und muss nach dem Auslesen in den anzuzeigenden Wert umgewandelt werden. Für das Attribut Type in der Beispiel-Klassendefinition im Anhang 1 ist beispielsweise eine 26 in der Datenbank hinterlegt. Diese Zahl ist wiederum eine ID eines GeneralCatalog-Elementes, welches anschließend in der Datenbank abgefragt wird und zum Beispiel das Wort Drucker an das Frontend-Modul zurückliefert. Dieser Wert kann dann der DTL-Datei übergeben werden, damit ein Benutzer nicht eine 26, sondern Drucker beim Betrachten eines ConfigItems sehen kann. 29 3 31 32 ein Array, das Hashes beinhaltet;...die in diesem Fall wieder ein Array beinhalten, usw. vgl. MySQL 5.7 Reference Manual, 214, S. 111 vgl. SCHWARTZ; PHOENIX, 24, S. 45 vgl. SCHWARTZ; PHOENIX, 24, S. 81 Seite 1
Framework und Komponenten 2.5.2 Frontend- und Systemmodule Das CMDB-Modul hat mehrere Frontend-Module, die unterschiedliche Funktionen erfüllen. Es gibt ein Modul, das ausschließlich die Klassendefinitionserstellung und -bearbeitung in der Admin-Oberfläche ermöglicht. Die weiteren Module erlauben es Agenten jeweils ConfigItems anzuzeigen, zu suchen, anzulegen, zu bearbeiten, deren Historie zu öffnen und die Daten einer oder aller Versionen des CI auszudrucken bzw. als PDF abzuspeichern. Darüber hinaus gibt es noch einige Layout-Module. Diese enthalten Funktionen, die die unterschiedlichen Eingabe- und Auswahlfelder in den Masken der Programmoberfläche entsprechend vorbereiten 33. Das CMDB-Systemmodul besteht aus einer Perl-Modul-Datei (ITSMConfigItem.pm), die direkt im System-Ordner liegt und mehreren weiteren Dateien, die sich in einem gleichnamigen Ordner (ITSMConfigItem/...) unterhalb des System-Ordners befinden. Für KIXOptimizedCMDB sind in der aktuellen Version aber nur die Hauptdatei und zwei Erweiterungsmodul-Dateien (Version.pm und XML.pm) relevant. Darüber hinaus ist für die Speicherung der klassenspezifischen Attribute der ConfigItems das XMLSystemmodul (XML.pm XML-Objekt) notwendig. Abbildung 9 stellt die Zusammensetzung des Systemmoduls schematisch dar. Darin ist zuerkennen, dass von der Hauptmodul-Datei (ITSMConfigItem.pm) alle weiteren Bestandteile angesprochen werden und diese anschließend mittels des DB-Systemmoduls (DB.pm DB-Objekt) mit der Datenbank interagieren können. Pfeile zu und von den drei Bestandteilen mit den grauen Erklärungen (der XML und... -Ordner und die... -Perl-Module) sind bewusst weggelassen worden, um die Übersichtlichkeit bewahren zu können. Abbildung 5 33 Aufteilung des Systemmoduls der CMDB z.b. vorgegebenen Werte für Dropdown-Menüs aus der general_catalog-tabelle laden und ggf. filtern und übersetzen. Seite 11
Framework und Komponenten Die folgende Tabelle beschreibt die drei relevanten Dateien des CMDB-Moduls und zusätzlich das XML-Modul (XML-Objekt) und fasst ihre jeweiligen Funktionen kurz zusammen. Alle anderen Dateien, die die Hauptdatei erweitern, sind darin nicht aufgeführt. Diese werden durch KIXOptimizedCMDB nicht verändert und sind deshalb für ein Verstehen nachfolgender Kapitel nicht notwendig. Datei Funktion ITSMConfigItem.pm Das ist das eigentliche Systemmodul. Hier sind die Datenbankzugriffe für das Anlegen und Bearbeiten sowie zum Laden und Suchen der CIs enthalten. Das Modul spricht aber selbst nur die CI-Tabelle, mit Hilfe des DB-Objektes (DB.pm) an. Wenn Interaktionen mit der Versionstabelle oder der XML-Tabelle notwendig sind, verweist das Modul auf eigene Methoden, die in den entsprechenden Erweiterungsmodulen enthalten sind. ITSMConfigItem/ Version.pm Dieses Modul enthält die Methoden, die mit der Versionstabelle interagieren müssen. ITSMConfigItem/ XML.pm In dieser Datei werden die Abfragen behandelt, die auf die klassenspezifischen Attribute abzielen. Da auf die XML-Tabelle auch andere Programmteile von OTRS zugreifen, nutzt dieses Modul abgesehen für die Suche (siehe Kapitel 3.1.3) die Funktionen des XMLModuls im System-Ordner. XML.pm Das ist das XML-Systemmodul (XML-Objekt). Darin sind die Methoden enthalten, die mit der XML-Tabelle interagieren und dadurch das Speichern und Auslesen von klassenspezifischen Attributen der ConfigItems ermöglichen. Tabelle 2 Wichtige Systemmodul-Dateien Seite 12
Framework und Komponenten 2.5.3 Datenbankinteraktion mittels der Systemmodule In OTRS werden alle Select-Anweisungen mit Hilfe zweier Funktionen des DBObjektes durchgeführt. Dieses wiederum verwendet für die Verbindung zur Datenbank und zur Vorbereitung und Ausführung eines SQL-Statements das PerlErweiterungsmodul DBI. Diese Erweiterung stellt Schnittstellen zu den meisten Datenbanken und Funktionen zur Interaktion mit den Datenbanken für PerlProgramme zur Verfügung34. Abbildung 6 Beispiel einer Select-Anweisung in OTRS Durch die erste Funktion (Prepare(), Zeile 2 in Abbildung 6) wird der übergebene SQL-String auf Fehler geprüft und entsprechend der angebundenen Datenbank aufbereitet (z.b. datenbankspezifische Positionen und Bezeichnungen von Parametern). Anschließend führt das DB-Objekt die Anfrage aus. Sind bei einem SQL-Statements zusätzlich Bedingungen (Where) zu prüfen, werden die Werte35 dafür mit einem Fragezeichen als Platzhalter im Statement ersetzt und mit dem Bind-Parameter als Referenz36 übergeben (siehe Zeilen 4). Durch Übergabe mittels Bind-Parameter müssen Werte bzw. enthaltene Zeichen nicht mehr zusätzlich maskiert werden.37 Die übergebenen Parameter können so auch nicht mehr als eigenes SQL-Statement von der Datenbank interpretiert werden, wodurch z.b. SQLInjection38 verhindert werden können39. Die zweite Funktion für Select-Statements ist FetchrowArray(). Diese Funktion liefert jeweils einen einzelnen Datensatz als Array (Liste der Inhalte der Spalten) der zuvor, mit Prepare() ausgeführten Abfrage zurück. Um sämtliche Datensätze zu erhalten, wird die Funktion innerhalb der Bedingung einer While-Schleife (Zeile 1) aufgerufen. Im Schleifeninhalt kann anschließend das übergebene Array ausgewertet werden. Im 34 35 36 37 38 39 vgl. CHRISTIANSEN; TORKINGTON, 26, S. 6-62 vor allem, wenn diese aus langen Zeichenfolgen bestehen nicht der Wert der Variable, sondern ein Verweis die Variable vgl. OTRS 3.3 - Developer Manual, 213, S. 11/12 Oftmals böswilliges Einbringen von zusätzlichen SQL-Statements, um Schaden anzurichten oder unerlaubt Kontrolle über die Datenbank oder Teile davon zu erhalten. online: DBI: Placeholders and Bind-Values, 214 (14.8.214) Seite 13
Framework und Komponenten Beispiel wird der Inhalt der SpalteA der Tabelle (z.b. die ID) zum Schlüssel des Hashs und der Inhalt der SpalteB zum Wert. Durch die Programmcode-Anweisung return if!$self... wird dem aufrufendem Modul kein Wert (undef 4) zurückgegeben, um dem Modul gegebenenfalls anzuzeigen, dass ein SQL-Statement nicht erfolgreich ausgeführt werden konnte. Das trifft aber nur zu, wenn es zu einem Fehler (beispielsweise existiert die Tabelle nicht) kam. Gibt es lediglich keinen passenden Datensatz, wird anschließend nur ein leerer Hash zurückgegeben. Die SQL-Anweisungen für Update, Insert Into und Delete werden, analog der Funktion Prepare(), mit Hilfe der Funktion Do() ausgeführt, siehe Abbildung 7. Abbildung 7 4 Beispiele für Insert Into, Update und Delete -Anweisungen undefiniert kein Rückgabewert, nichts Seite 14
Entwicklungsstadien von KIXOptimizedCMDB 3 Entwicklungsstadien von KIXOptimizedCMDB 3.1 Erste Entwicklungsstufe - Beta 1 3.1.1 Analyse und Optimierungsansätze Die erste Optimierung des CMDB-Moduls betrachtet nur die XML-Tabelle, da dort die meisten Daten eines CIs gespeichert werden. Zwar sind die Spalten xml_type und xml_key der Tabelle mit Indizes versehen, um Abfragen nach Typ (und bei CIs auch Klasse) und der Versions-ID zu beschleunigen. Dennoch ist dies bei sehr vielen Datensätzen nicht ausreichend, da der Suchraum dabei zu umfangreich ist. Eine Optimierungsmöglichkeit zielt deshalb darauf ab, die XML-Tabelle auf kleinere Tabellen aufzuteilen. Die Daten für die ConfigItems sollen dafür aus der XML-Tabelle herausgelöst und in jeweils eigene Tabellen hinterlegt werden. Dies verkleinert den zu durchsuchenden Raum und erlaubt dadurch eine effizientere Nutzung des Datenbank-Caches und verhindert gegebenenfalls Auslagerungen auf die Festplatte. Darüber hinaus sollen dabei auch die aktuellen Werte (Live-Daten) von den Daten vorheriger Versionen (Historien-Daten) getrennt werden, um die oft ausgeführten Suchen nach gegenwärtigen Versionen von CIs zusätzlich beschleunigen. Eine Analyse der gespeicherten Daten ergab zudem, dass diese inhaltlich redundant gespeichert sind. Das heißt, für eine Wertzuordnung werden jeweils zwei Datensätze benötigt, die nahezu identische Inhalte besitzen. Die folgenden zwei Tabellen zeigen den gespeicherten Typ eines Computers, bestehend aus zwei Datensätzen. Dabei sind die Spalten der XML-Tabelle als Zeilen angegeben, um es übersichtlicher darstellen zu können. xml_type ITSM::ConfigItem::22 xml_key 1 xml_content_key [1]{'Version'}[1]{'Type'}[1]{'TagKey'} xml_content_value [1]{'Version'}[1]{'Type'}[1] Tabelle 3 XML-Datensatz 1 xml_type ITSM::ConfigItem::22 xml_key 1 xml_content_key [1]{'Version'}[1]{'Type'}[1]{'Content'} xml_content_value 47 Tabelle 4 XML-Datensatz 2 An diesem Beispiel ist die inhaltliche Redundanz gut zu erkennen. Die zwei ContentSpalten des ersten und die content-key-spalte des zweiten Datensatzes sind nahezu gleich. Deshalb ließe sich der erste Eintrag anhand des Unterschieds im letzten Teil Seite 15
Entwicklungsstadien von KIXOptimizedCMDB (TagKey) herausfiltern und weglassen. Der zweite Datensatz muss dafür programmiertechnisch anders ausgewertet werden, um das Fehlen des ersten auszugleichen und dadurch nicht zu große Veränderung im Programmcode für die nachträgliche Auswertung vornehmen zu müssen. 3.1.2 Datenbankanpassungen Ausgehend von der beschriebenen Optimierungsmöglichkeit der Aufteilung der XMLTabelle wurden für jede CI-Klasse drei neue Tabellen definiert, die in Tabelle 5 beschreiben sind. Für die mit einem * versehenen Spalten existiert ein Index. Name Spalten Funktion ci_id_content dict_id* xml_key* xml_content_value Beinhaltet alle klassenspezifischen Attribute der aktuellen Version. ci_id_content_archive dict_id* xml_key* xml_content_value Beinhaltet alle klassenspezifischen Attribute der vorherigen Versionen. ci_id_dict id* xml_content_key* Beinhaltet alle klassenspezifischen Attributschlüssel. Tabelle 5 Neue Struktur zur Speicherung der klassenspezifischen Attribute Die Spalte dict_id der Content-Tabellen enthalten Werter der Spalte id der DictionaryTabelle41. Die Spalten fungieren also wie Fremdschlüssel, sind aber keine und haben dadurch nicht die entsprechende Nicht-Löschbar -Bedingung. Fremdschlüssel sind nicht notwendig, weil auf die Dictionary-Tabelle niemals löschend zugegriffen wird. Die Dictionary-Tabelle wurde eingeführt, weil die Werte für xml_content_key sich so gut wie nie ändern. Dies ist nur dann der Fall, wenn die Klassendefinition geändert wird. Zudem lassen sich dadurch die Indizes der Tabellen effizienter nutzen. Durch diese Aufteilung in die einzelne Tabellen pro Klasse ist die Spalte xml_type der Ausgangstabelle nun zu einem Tabellenkonstrukt geworden. Damit verringert sich der zu durchsuchende Raum für Abfragen erheblich und verbessert dadurch die Geschwindigkeit für Suchanfragen (siehe Tests in Kapitel 3.1.4). Für die Kombinationen der Dictionary-Tabelle und den Content-Tabellen existiert jeweils ein eigener View. Dadurch können die meisten Abfragen vom System nahezu unverändert bleiben, weil der View, bis auf die xml_type-spalte die selbe Struktur wie die XML-Tabelle nach außen zeigt. Dadurch muss sich das Modul nicht selbst mit komplizierten Tabellen-Joins42 beschäftigen, sondern kann den View wie eine 41 42 engl. Wörterbuch, Verzeichnis; Die Tabelle kann als Verzeichnis verstanden werden. Verbindung zweier Tabellen über ein bestimmtes Attribut Seite 16
Entwicklungsstadien von KIXOptimizedCMDB eigenständige Tabelle43 ansprechen.44 Da beim Öffnen eines CIs oder der Anzeige einer bestimmten Version alle Daten anhand der Versions-ID (= xml_key) geladen werden müssen, besitzt diese Spalte xml_key einen Index. Für die Zuordnung und damit schnelles Auffinden über xml_content_key-werte ist auch die dict_id-spalte mit einen Index versehen. Damit die Datenbankoptimierungen auch von OTRS verwendet werden können, war es notwendig eine Methode der CMDB-Systemmodul-Erweiterung XML.pm und mehrere Funktionen des XML-Objektes anzupassen. Im folgenden Kapitel sind einige der Änderungen an den Modulen detaillierter beschrieben. 3.1.3 3.1.3.1 Änderung und Erweiterung des Programmcodes Systemmodul-Erweiterung XML.pm Die Anpassungen in der Systemmodul-Erweiterung XML.pm betreffen ausschließlich die Methode _XMLHashSearch(). Diese Methode erzeugt für die Suche nach bestimmten Attributen aus den erhaltenen Parametern einen SQL-String. Sie kann dabei auch Vergleichsoperationen, wie beispielsweise kleiner, kleiner-gleich, nichtgleich oder zwischen auswerten und macht dadurch Bereichsabfragen möglich. Bereichsabfragen sind Select-Anweisungen mit Bedingungen, die Spalten z.b. nach von-bis oder alles-älter-als durchsuchen. Dadurch werden nur Datensätze bzw. Tupel45 zurück geliefert, deren zu betrachtendes Attribut nur innerhalb eines bestimmten Intervalls liegt46. Änderungen wurden an zwei Positionen der Funktion vorgenommen, die in den Abbildungen 8 und 9 dargestellt sind. Abbildung 8 43 44 45 46 Erste Anpassung in der Methode _XMLHashSearch() Views können als virtuelle (nicht physisch vorhandene) Tabelle verstanden werden. vgl. UNTERSTEIN; MATTHIESSEN, 212, S. 196 Synonym für Datensatz bzw. Ausschnitt eines Datensatzes vgl. HEUER; SAAKE, 2, S. 349 Seite 17
Entwicklungsstadien von KIXOptimizedCMDB Die Kommentare (Zeilen 622 und 637), die den Paketnamen (in Beta 1 noch CMDBSpeedup) enthalten, zeigen Programmierern, wo die Änderung durch die Optimierungen anfängt und endet (EO end of). Der große Block grau-gefärbter Zeilen (Zeilen 623 bis 626) ist auskommentiert und wird deshalb nicht ausgeführt. Diese Zeilen enthalten den ursprünglichen Programmcode von OTRS, während die farbigen Zeilen in der Abbildung den neu eingefügten Programmcode darstellen. Die Abbildung 9 zeigt eine Select-Anweisung, die alle xml_key-werte anhand des Typs47 ohne eingrenzende Bedingungen ermittelt. Im Standard-Programmcode wurde der Typ einfach als Parameter übergeben, um die XML-Tabelle entsprechend durchsuchen zu lassen. Durch die Optimierung wird aus dem Typ-Parameter mittels regulärem Ausdruck (Zeile 628) die Klassen-ID heraus gefiltert. Reguläre Ausdrücke (kurz: RegEx48) erlauben Mustererkennungen, bei der festgelegte Zeichen als Platzhalter (beispielsweise \w für alle alphanumerischen Zeichen und dem Unterstrich) angegeben werden49. Mit der Klassen-ID wird der Variable $ClassView die jeweilige View-Bezeichung der entsprechenden CI-Klasse zugewiesen. In den Zeilen 63 bis 632 überprüft erneut ein regulärer Ausdruck, ob gegebenenfalls nach älteren Versionen gesucht werden soll. Ist dies der Fall, bekommt die Variable $ClassView die der Klasse entsprechende Archiv-View-Bezeichnung zugewiesen. Abbildung 9 47 48 49 Zweite Anpassung in der Methode _XMLHashSearch() für ConfigItems in der Form ITSM::ConfigItem::Klassen-ID regular expression vgl. CHRISTIANSEN; TORKINGTON, 26, S. 19/198 Seite 18
Entwicklungsstadien von KIXOptimizedCMDB In Abbildung 9 werden nochmals alle xml_key-werte ausgelesen. Diesmal sind dem SQL-Statement aber Bedingungen angefügt, um nur bestimmte Datensätze zu erhalten. Durch die Optimierung wird dafür wieder der weiter oben festgelegte Klassen-View benutzt. Innerhalb der While-Schleife gleicht die Methode die ausgelesenen Daten mit den zuvor ermittelten Werten ab. Nur, wenn das Element auch in dem erst erzeugten Hash (%Hash) enthalten ist (Zeile 751), werden sie dem neuen Hash (%NewHash) hinzugefügt. Am Schluss gibt die Methode den Hash an das aufrufende Modul zurück. 3.1.3.2 Systemmodul XML.pm Programmcodeanpassungen des XML-Systemmoduls mussten in den Funktionen XMLHashAdd(), XMLHashGet(), XMLHashMove() und XMLHashList() vorgenommen werden. Auch hier beziehen sich die Änderungen darauf, dass die SQL-Anweisungen auf die neuen klassenbezogenen Tabellen bzw. Views zugreifen und nicht mehr die XML-Tabelle verwenden. Abbildung 1 zeigt eine zusätzliche Prüfung mittels RegEx (Zeile 156). Diese bestimmt, ob das XML-Objekt wirklich vom CMDB-Modul und nicht durch ein anderes OTRS-Modul aufgerufen wurde. Diese Abbildung stellt einen Ausschnitt der Methode XMLHashAdd() dar. Diese Funktion legt neue Datensätze (z.b. die Attribute einer neuen Version eines CIs) in der XML-Tabelle bzw. nach der Optimierung in den Klassen-Tabellen an. Die Zeilen 16 bis 162 enthalten die Filterung für die überflüssigen doppelten Datensätze (siehe Kapitel 3.1.1). Enthält ein zu speichernder Wert die Buchstabenfolge TagKey5, wird die Anweisung next; ausgeführt. Dadurch beendet die Methode den aktuellen Schleifendurchlauf und unterbindet damit eine Speicherung des Wertes. Ist ein Wert zulässig, wird versucht aus der Dictionary-Tabelle eine ID für den xml_content_key zu ermitteln (Zeilen 164 bis 167). Kann kein entsprechender Datensatz gefunden werden, legt die Methode einen neuen an und liest die neue ID dafür aus. Anschließend wird der xml_content_value-wert mit dazugehöriger ID des xml_content_key-wertes und dem xml_key-wert (aktuelle Versions-ID) in der Content-Tabelle gespeichert. Abbildung 1 5 Ausschnitt der Methode XMLHashAdd() des XML-Objektes Text, der in dem überflüssigen Datensatz enthalten ist, mittels RegEx geprüft Seite 19
Entwicklungsstadien von KIXOptimizedCMDB Diese Speicherung ist aber vorerst nur temporär. Das heißt, der xml_key-wert wird zu diesem Zeitpunkt zum Beispiel mit TMP-12345-32 51 gespeichert und erst nach korrekter Ausführung des gesamten Speichervorganges durch die Methode XMLHashMove() in den richtigen Eintrag geändert. Dabei wird die vorherige aktuelle Version aus der Content-Tabelle in die Content-Historie-Tabelle übertragen und anschließend aus der Ersteren entfernt. Der Umweg über das temporären Speichern ist notwendig, um unvollständige Daten zu verhindern 52. Dadurch behalten alle bisher angelegten Werte den temporären Eintrag und können so nicht verwendet werden. Dies zeigt dem Agenten, dass die Version nicht komplett erfolgreich gespeichert wurde und er eine neue Version anlegen muss. In Abbildung 11 ist ein Ausschnitt der Methode XMLHashGet() dargestellt. Diese Methode ließt die klassenspezifischen Attributwerte aus der Datenbank aus. In dem dargestellten Programmcode werden die vorher ausgefilterten doppelten SchlüsselWert-Paare (die TagKey enthielten) aus dem gespeicherten Datensatz erstellt und ebenfalls dem erzeugten Content-String angefügt. Weil diese durch das aufrufende Module benötigt und weiter verarbeitet werden (Aufbau des Array of Hashes). Abbildung 11 Ausschnitt der Methode XMLHashGet() des XML-Objektes Da alle weiteren Anpassungen in den anderen Methoden XMLHashMove() und XMLHashList() sehr ähnlichen Änderungen (Abfrage des Typs, Bestimmung der Tabelle bzw. des Views) unterlagen, ist es nicht notwendig diese für das Verstehen nachfolgender Kapitel gesondert aufzuführen. 3.1.3.3 Module für Tabellenerstellung Zwei weitere Module erzeugen die geplanten Tabellen pro Klasse. Nach erfolgreicher Installation des Pakets muss das Script CMDBSpeedup.RebuildCMDBStructure.pl53 in einer Kommandozeile ausgeführt werden. Das Script erstellt alle Tabellen für bestehende ConfigItem-Klassen, egal ob gültig oder nicht. Dass auch für ungültiggesetzte Klassen die Tabellen angelegt werden, ist notwendig, falls irgendwann solch eine Klasse wieder reaktiviert und weiter benutzt wird. Nachdem das Script die 51 52 53 Format: TMP zufällige Zahl, kleiner als eine Million Klassen-ID z.b. wenn die Datenbankverbindung unterbrochen ist und nicht alle Attribute gespeichert wurden ist namentlich ab Beta 2 angepasst: KIXOptimizedCMDB.RebuildCMDBStructure.pl Seite 2
Entwicklungsstadien von KIXOptimizedCMDB Klassen angelegt hat, kopiert es alle bestehenden Daten gespeicherter CIs in die neuen Tabellen. Das heißt, die bisher vorhandenen Daten bleiben in der XML-Tabelle erhaltenen und können bei einer Deinstallation des Paketes wieder verwendet werden. Alle ab diesem Zeitpunkt neu angelegten klassenspezifischen Daten werden aber nur in der neuen Struktur abgelegt und bei Deinstallation nicht in die XMLTabelle übertragen. Die neuen Daten wären dadurch nicht mehr zugänglich. Da die Optimierung für große CMDB-Umgebungen gedacht ist, würde ein entsprechender Übertragungsvorgang sehr viel Zeit in Anspruch nehmen und dadurch das System währenddessen unbenutzbar machen. Deshalb ist ein weiteres Script, um dies dennoch zu ermöglichen, nicht vorgesehen. Nach Erstellung der Tabellen definiert das Script die Indizes für die neuen Tabellen und legt die erwähnten Views an. Erst danach ist die Paket-Installation vollends abgeschlossen und OTRS kann wieder uneingeschränkt verwendet werden. Das Script nicht automatisch auszuführen, ist notwendig, weil bis zu diesem Punkt die Installation noch sehr einfach zu revidieren ist. Der Installierende soll sich bewusst sein, dass mit Ausführung des Scripts ein größerer Eingriff in die Datenbasis vorgenommen wird und alle neuen Daten davon betroffen sein werden. Das zweite Modul ist eine ereignisbasierte Funktion. Bei jedem Anlegen einer neuen Klassendefinition das Ereignis, auf das reagiert werden soll wird das, in dem Schlüssel in der Konfiguration (siehe Abbildung 12) angegebene Modul (Zeile 1) aufgerufen. Wenn es dabei die erste Klassendefinition einer Klasse ist, weiß das Modul, dass es sich um eine neue Klasse handeln muss und erstellt daraufhin die entsprechenden Tabellen, definiert die Indizes und legt die Views an. Abbildung 12 3.1.4 Konfigurationsschlüssel für den ereignisbasierten Modulaufruf Test Um die Performanceverbesserung von KIXOptimizedCMDB zu bestimmen, sind zwei verschiedene Tests durchgeführt worden, um die unterschiedlichen Verwendungsgebiete der CMDB abzudecken. Beide Test wurden mit einem Standard-OTRS und einem OTRS mit installierter Optimierung durchgeführt. Seite 21