ORDIXnews - ORDIX AG
Werbung
www.ordix.de ORDIX news 01 2008 € 2,20 Das IT-Magazin der ORDIX AG Alles virtuell mit OpenVZ und Virtuozzo Nagios 3.0 Vererbungslehre für Administratoren IT-Projektmanagement S. 14 IBM Informix Dynamic Server 11 S. 32 Professionelle Projektinitialisierung und hilfreiche Checklisten für die effiziente Planung S. 38 Dynamisches Ressourcen Tuning Performante JEE-Anwendungen S. 44 Mit Lasttests im Kundenprojekt auf dem Weg zur robusten, performanten Anwendung S. 22 Veranstaltungen 2008 • „Informix Bestandsaufnahme und Erwartungshaltung“ 12.02.2008 IBM in München • „Informix aus Betreiber-Sicht“ 18.06.2008 IBM in Hamburg • „Informix Anwendung und Entwicklungswerkzeuge“ 12.11.2008 Mathematikmuseum in Gießen Informationen zu unseren Veranstaltungen finden Sie auf unserer Homepage. Wenn Sie einen Vortrag zu einem der Themen halten wollen, melden Sie sich bitte bei uns. Am Abend vor den Workshops trifft sich die IUG-Gemeinschaft zum Stammtisch. In angenehmer Atmosphäre haben Sie dort die Möglichkeit, Erfahrungen auszutauschen und Kontakte zu knüpfen. Als IUG-Mitglied ist die Teilnahme an unseren Workshops und Stammtischen kostenlos. Seit 15 Jahren sind wir ein eingetragener, unabhängiger Verein, dessen Aufgabe es ist, InformixAnwender und -Interessenten zusammenzubringen. Experten-Vorträge - Kontakt- und Netzwerkbildung www.iug.de - Hohe Besucherzahlen Für weitere Informationen melden Sie sich bitte bei: [email protected] Editorial Pimp your E-Mail Paderborn, März 2008 1985 begann für mich zaghaft das E-Mail-Zeitalter. Bekam oder schrieb man am Tag mehr als fünf bis sechs Mails, so war das schon viel. Als ich 1987 zu Nixdorf ging, musste ich in der Beziehung einen Rückschritt machen. IBM-orientiert, wie das Unternehmen war, waren TCP/IP-Netzwerke ebenso verpönt, wie Mails zu schreiben. Lediglich innerhalb der Entwicklung wurde ein internes Netz (NERVE) dafür genutzt. Da gab es viel Aufklärungsarbeit zu leisten. ORDIX hatte deshalb sehr schnell seine Domain und Mail-Adressen. Mich erreicht man deshalb auch schon fast 18 Jahre über die gleiche Mail-Adresse. Leider sind es inzwischen aber zu viele: Nachdem Ende der 90er Jahre das Marketing E-Mails als Medium für sich entdeckte, wuchs nicht nur der Umfang einer E-Mail um ein Vielfaches, sondern auch die Anzahl an Mails stieg ins Unermessliche. 1000 Mails pro Tag sind leider nichts Außergewöhnliches. SPAM lässt sich zwar inzwischen sehr leicht filtern, große Mails aber leider nicht. Liebend gerne werden Megabyte große Powerpoint Präsentationen verschickt, obwohl der Empfängerkreis viel zu groß ist und der tatsächliche Inhalt auch gut und gerne in eine 500 Byte große Mail gepasst hätte. Überflüssige Bilder, Formatierungen, die niemand braucht - je weniger Inhalt eine Mail hat, desto mehr wird sie durch Schnickschnack, Anhänge etc. aufgebläht. Und dann empfangen Sie mal so einen Unfug im Urlaub oder unterwegs bei einer zwischen UMTS und GPRS wechselnden Verbindung oder einer schmalbrüstigen WLAN-Internetanbindung. Da kam früher bei einem Akustikkoppler mit 120 Baud mehr über die Leitung - zumindest in Bezug auf echte Information. Je größer die Firmen und je nichtssagender die Nachricht, desto aufgemotzter die E-Mail. „Pimp your E-Mail“ fällt mir dazu ein. Aber vielleicht werde ich langsam zu alt. Auslaufmodell muss man mich nennen, der ich die Meinung verfechte, dass ein Datenbankserver, wenn er vernünftig eingestellt ist, nicht mehr als 1 GB Hauptspeicher braucht, um 100 - 150 Anwender schnell genug zu bedienen. Wo doch heute schon Notebooks mit 2 GB nicht ausreichen, damit Java- oder .NET-Entwickler simple Programme schreiben können. Und das nur, weil man niemandem mehr den VI zumuten möchte und Anwendungen nicht mehr durch analytisches Denken, sondern durch pures Zusammenklicken entwickelt werden. Besser werden sie dadurch definitiv nicht. Alles soll „automatisch“ gehen. Über nichts mehr nachzudenken ist „in“. Und wenn es dann doch schief läuft, wundern sich alle. Ich stelle mir das Jahr 2108 vor: Keiner diskutiert mehr das Nichtrauchergesetz. Es wird vielmehr darüber gestritten, warum NRW das europaweit geforderte MAG (Mausabschaffgesetz) nicht umsetzen möchte. Obwohl erwiesenermaßen Rückenbeschwerden, verstärktes Rheuma und Haltungsschäden bei Personen unter 19 darauf zurückzuführen sind. Von Lese- und Schreibschwächen ganz zu schweigen. Bis dahin ist es aber noch weit. Und Sie merken, ich werde alt. Ich habe das vor ein paar Wochen ebenfalls mit Erschrecken festgestellt. Da teilte mir mein Bankbetreuer mit, dass er in diesem Jahr in Altersteilzeit geht. Mit ihm habe ich schon Anfang der 80er Telefonbanking betrieben, als noch keiner wusste, was Telefonbanking ist. Bevor ich in Altersteilzeit gehe , werde ich Sie aber noch einige Male auf Inhalte der ORDIX News hinweisen: Dieses Mal gibt es viel zum Thema Virtualisierung (vielleicht werden auch irgend­ wann Mäuse virtualisiert ), wichtige Automatismen bei Datenbanken (Oracle, Informix und DB2, s. o.) und Interessantes zu Java Frameworks und APIs fehlt natürlich auch nicht. Jetzt rufe ich erst mal meine Mails ab und verschicke dieses Editorial - im Urlaub versteht sich. Viel Spaß beim Lesen wünscht Ihnen Wolfgang Kögler PS: Dieses Mal nichts Politisches, aber bei einem Wahlkampf à la Koch fällt selbst mir nichts mehr ein ... ORDIX News 1/2008 Inhalt Aktuell 34.....Larry Ratlos: Verflixte PHP 5 Arrays Standards 03.....Editorial 04.....Inhalt Betriebssysteme 35.....I/O-Multipathing mit Linux-Bordmitteln: Viele Wege führen zur LUN Implementierung des I/O-Multipathing auf Basis des Device-Mappers im Linux Kernel 2.6. 37.....Impressum Training 26.....Seminarübersicht: März bis Oktober 2008 09.....Seminar: Entwicklung mit Spring Open Source 14.....Alternative Virtualisierungslösungen: Alles virtuell mit OpenVZ und Virtuozzo Virtualisierungslösungen im Internetsektor: Die Open Source Virtualisierungslösung OpenVZ kommt vor allem beim Webhosting zum Einsatz. Das kommerzielle Produkt Virtuozzo baut darauf auf. 48.....Neue Features in OpenLDAP 2.3 (Teil II): Serverkonfiguration zur Laufzeit Dieser Artikel berichtet über die neue Möglichkeit der LDAP-Serverkonfiguration zur Laufzeit. Zudem wird am Beispiel der sudo-Konfiguration aufgezeigt, wie vielfältig sich OpenLDAP nutzen lässt. Java/JEE 05.....Spring Web Flow Kurze Einführung in die Ablaufsteuerung von Anwendungsfällen innerhalb von Java-basierten Web-Anwendungen mit dem Spring Web Flow Framework. 22.....Mit Lasttests zur performanten JEE-Anwendung Vorstellung der Erfahrungen mit Lasttests aus einem Kundenprojekt – insbesondere zur zeitlichen Einbettung von Lasttests in Projektplänen und zur Definition und Ermittlung von aussagekräftigen Antwortzeiten. 28.....JExcelAPI und Jakarta POI – David gegen Goliath? Vergleich des Jakarta-Projekts POI mit der JExcelAPI, insbesondere im Hinblick auf den Funktionsumfang und die Handhabung der Tools. Für einen schnellen Vergleich gibt es den Expertencheck. Projektmanagement 38.....IT-Projektmanagement: Aller Anfang ist schwer Über die Notwendigkeit einer durchdachten und präzisen Initialisierung von IT-Projekten mit Checklisten als Hilfestellung. ORDIX News 1/2008 51.....Seminar: OpenLDAP - Praxiseinsatz im Netzwerk Systemmanagement 32.....Nagios 3.0: Vererbungslehre für Administratoren Überblick über die Neuheiten der Version 3.0 der System Monitoring Software Nagios: Vorstellung der Möglichkeit, mehr als eine Vorlage in eine Objektdefinition einzubinden und somit komplexe Anforderungen besser umsetzen zu können. Datenbanken 10.....Oracle Database 11g Release 1 (Teil II): ADR - Automatic Diagnostic Repository Fehleranalysen unter Oracle mit dem neuen Advisory Framework Automatic Diagnostic Repository. 18.....IBM DB2 UDB 9.1 „Viper“ (Teil V): Automatisierung durch „dynamischen Speicher“ Vorstellung der neuen Automatisierungsfunktion „Automatic Storage“ der IBM DB2 Datenbank Version 9.1. 41.....Oracle Objekttypen von A - Z (Teil VI): Jobs und Libraries Diesmal stellen wir Ihnen die Objekttypen Job, Job Class, Programm, Schedule und Library vor. 44.....IBM IDS 11 (Teil II): Dynamisches Ressourcen Tuning Vorstellung der neuen Möglichkeiten im Bereich „Dynamisches Ressourcen Tuning mit der Informix Version 11“ und Erläuterung der hierfür wichtigsten Begriffe und Parameter. Java/JEE Ablaufsteuerung von Anwendungsfällen innerhalb von Java-basierten Web-Anwendungen Spring Web Flow Mit dem Spring Web Flow Framework sollen Probleme, die bei der Entwicklung von Java-basierten Web-Anwendungen auftreten können, wie z. B. fehlende Unterstützung der Browser-Funktionalitäten, der Vergangenheit angehören. Im folgenden Artikel wird Dieser Artikel richtet sich an Java-Entwickler und Architekten im Bereich Web-Anwendungen. eine kurze Einführung in das Framework gegeben und aufgezeigt, ob Spring Web Flow diesem ehrgeizigen Ziel gerecht wird. Was ist Spring Web Flow? Spring Web Flow ist ein Framework für die Ablaufsteuerung von Anwendungsfällen innerhalb von Web-Anwendungen. Ein erklärtes Ziel ist die Unterstützung der Browser-Navigation, die in der Web-Entwicklung immer wieder zu Problemen führt. Das Framework übernimmt dabei die Navigation zwischen den einzelnen Views und stellt darüber hinaus einen zusätzlichen Scope Container zur Verfügung. Spring Web Flow kann in den gängigsten WebFrameworks, wie Struts, JSF, Portlet MVC oder Spring MVC, integriert werden. Spring Web Flow implementiert im Kern einen finiten Zustandsautomaten, der auf definierte Anfangs- und Endzustände angewiesen ist. Der Einsatz von Spring Web Flow bietet sich daher für Anwendungsfälle an, in denen feste Abläufe existieren. Es sollte nicht in Bereichen eingesetzt werden, in denen der Benutzer frei navigieren kann. In diesem Fall sollte die Standardnavigation des überlagerten Web-Frame­ works eingesetzt werden. Spring Web Flow ersetzt somit nicht die vorhandene Navigation, sondern erweitert diese, indem es sich als zusätzlicher Controller in die bestehende Infrastruktur eingliedert. ORDIX News 1/2008 Java/JEE Um zu verhindern, dass ein Request durch einen Reload erneut gesendet wird, setzt Spring Web Flow das Post+Redirect+Get Pattern ein. Ein Redirect ist eine Weiterleitung auf eine andere Webseite, wobei der eigentliche Request/Response-Zyklus zweigeteilt wird. Nach dem POST Request wird durch den Redirect ein erneuter Browser Request via GET angestoßen. Somit erhält der Client eine stabile URL, die keinen erneuten Datenversand im Falle eines Reload durch den Browser ausführt. Flow Der Ablauf der logisch zusammenhängenden Views wird in einem so genannten Flow definiert. Ein Flow kann als XML-Datei oder wahlweise mittels der Java-API realisiert werden. Ein Flow besteht in der Regel aus mehreren Zuständen (innerhalb von Web Flow als States bezeichnet), die nacheinander und in Abhängigkeit von der jeweiligen Benutzerinteraktion durchlaufen werden. Ein Beispiel eines per XML definierten Flows ist in der Abbildung 1 genauer aufgezeigt. Innerhalb eines Flows stehen verschiedene States zur Verfügung. Zunächst muss jeder <flow xmlns="http://www.springframework.org/schema/webflow" .../> <start-state idref="startingState"/> <view-state id="startingState" view="/xyz.xhtml"> <transition on="submit" to="actionState"/> </view-state> <action-state id="actionState"> <bean-action bean="beanName" method="methodName"> <method-arguments> <argument expression="flowScope.expression"/> </method-arguments> </bean-action> <transition on="failure" to="startingState"/> <transition on="success" to="decisionState"/> </action-state> <decision-state id="decisionState"> <if test="${flowScope.bean.property}" then="endState" else="startingState"/> </decision-state> <end-state id="endState" view="/abc.xhtml" /> </flow> Abb. 1: Definition eines Flows per XML. ORDIX News 1/2008 Flow einen Start State und einen End State besitzen. Der Start State definiert den Einstiegspunkt und aktiviert den jeweiligen Flow. Dieser bleibt so lange aktiv, bis ein End State erreicht wird. Die Angabe eines End States ist zwar nicht zwingend erforderlich, ist aber dringend zu empfehlen, da die sonst entstehenden Endlos-Flows unnötig Hauptspeicher binden. Web Flow kennt 5 verschiedene Arten von States: • • • • • View State Action State Decision State Subflow State End State Ein View State definiert den Einstiegspunkt für den Benutzer und repräsentiert die eigent­ lichen JSP- bzw. XHTML-Dateien. Nur innerhalb eines View States wird der Flow angehalten und dabei auf ein Event vom Benutzer gewartet. Alle anderen States werden automatisch durchlaufen, wie z. B. die Action States, die für den Aufruf der Geschäftslogik zuständig sind. Auf die zugehörigen Action-Klassen gehen wir im späteren Verlauf noch ein. Auch Kontrollstrukturen können innerhalb eines Flows durch einen so genannten Decision State definiert werden. Dabei wird eine Vari­ able auf einen beliebigen Zustand abgefragt und entsprechend reagiert, d. h. auf den zugehörigen State verwiesen (siehe Abbildung 1). Durch einen Subflow besteht die Möglichkeit, andere Flow-Definitionen innerhalb des aktuellen Flows aufzurufen. Auf Subflows wird im Folgenden noch genauer eingegangen. Beim Erreichen des End States wird der aktive Flow beendet und alle zugehörigen Beans werden automatisch aus dem Speicher entfernt. Transition Der Übergang zwischen den einzelnen States wird durch so genannte Transitions realisiert. Eine Transition fängt den Event eines Views oder eines Action States ab und leitet auf den State weiter, der in dem to-Attribut angegeben wurde. Existiert innerhalb eines States keine passende Transition zu einem Event, so wird eine globale Transition gesucht und ausgeführt. Abbildung 1 stellt die Funktionsweise Java/JEE von Transitions schematisch dar. Hierbei fängt das Framework Events, die z. B. innerhalb eines Views oder Action States erzeugt wurden, ab und leitet durch die Transition auf den nächsten State weiter. Action Für die Implementierung von Action-Klassen, die u. a. dem Aufruf der Geschäftslogik die­ nen, stehen dem Entwickler bereits einige Klassen (z. B. FormAction, MultiAction usw.) zur Verfügung, von denen die eigentliche Action-Klasse abgeleitet werden kann. Alle diese Klassen implementieren das Interface org.springframework.webflow.execution.Action. Die Methoden liefern innerhalb einer Action ein Objekt vom Typ Event zurück. Dieses wird vom Framework abgefangen und eine passende Transition wird für dieses Event gesucht. Anschließend wird durch die Transition der nächste State ausgewählt. Nicht nur innerhalb eines Action States können Actions ausgeführt werden. Sie lassen sich auch als Entry oder End Action innerhalb eines beliebigen States oder z. B. als Render Action innerhalb eines View States einsetzen. Scope Wie bereits erwähnt, stellt Spring Web Flow einen eigenen Scope-Container zur Verfügung. Dieser erweitert die Web-Anwendung um die folgenden Scopes: • Flash: Gültig, solange der Flow aktiv ist, jedoch werden Flash Scope Beans nach jedem View State geleert und dienen somit dazu, zwischen zwei User Events Daten zu transferieren. • Flow: Steht über die gesamte Laufzeit des Flows zur Verfügung. • Conversation: Die Lebensdauer ist mit dem Flow Scope identisch, nur stehen Conversation Scope Beans auch in den zugehörigen Subflows zur Verfügung. Es besteht die Möglichkeit, auch weiterhin die bekannten Scopes einer Web-Anwendung, wie beispielsweise Request und Session, zu verwenden. Der Request Scope sollte aber mit Bedacht eingesetzt werden, da der Lebenszyklus der zugehörigen Beans für eine <subflow-state id="subflowState" flow="subflowID" > <attribute-mapper> <output-mapper> <output-attribute name="parameter1" scope="flow"/> <output-attribute name="parameter2" scope="flash"/> </output-mapper> </attribute-mapper> <transition on="success" to="stateX"/> </subflow-state> Abb. 2: Aufruf eines Subflows innerhalb eines anderen Flows. fehlerfreie Unterstützung der Browser-Navigation zu kurz ist. Der große Vorteil der neuen Scopes ist, dass diese nach Beendigung eines Flows automatisch gelöscht werden und nicht länger in der Session liegen. Subflows Auch die Modularisierung von Flows in kleine Einheiten ist durch so genannte Subflows bzw. Inline-Flows ohne Weiteres möglich. Ein Subflow wird zunächst wie jede andere FlowDefinition erstellt. Der Unterschied zu einem normalen Flow liegt lediglich darin, dass der Subflow innerhalb eines Subflow States (siehe Abbildung 2) aufgerufen wird. Eine FlowDefinition kann beliebig viele Subflows enthalten, welche wiederum weitere Subflows aufrufen können. Inline Flows werden im Gegensatz zu Subflows nicht in einer eigenen XML-Datei gekapselt, sondern direkt in dem Flow definiert, in dem sie aufgerufen werden. Dadurch ist dieser nur innerhalb des konkreten Flows sichtbar und wird nur dann eingesetzt, wenn der Flow zwingend zu dem Flow gehört, aus dem er aufgerufen wird, und nicht in einem anderen Flow verwendet werden darf. Für den Datenaustausch zwischen Flow und Subflow gibt es Input- und Output-Mapper. Parameter können durch einen Input-Mapper an den Subflow übergeben und durch einen Output-Mapper auch wieder zurückgegeben werden. Repository Wie bereits erwähnt, setzt sich Spring Web Flow das Ziel, die Browser-Funktionalitäten zu unterstützen. Um diese Funktionalität zu ge- ORDIX News 1/2008 Java/JEE währleisten, muss die Möglichkeit bestehen, den Zustand einer View zu speichern und wieder abzurufen. Hierfür steht ein so genanntes Repository zur Verfügung, welches die Zustände der einzelnen Views innerhalb eines Flows zwischenspeichert. Dadurch kann man den Zustand jeder View innerhalb eines Flows zu einem beliebigen Zeitpunkt reproduzieren. Nur durch so ein Repository ist es für Spring Web Flow möglich, die Browser-Navigation zu unterstützen. Spring Web Flow beinhaltet grundsätzlich die folgenden Reposi­tories: • • • Continuation Client Simple/Single-Key Die Repositories Continuation und Client enthalten die identische Funktionalität, nur mit dem Unterschied, dass bei einem Client Repository alle Informationen auf dem jeweiligen Client und nicht auf dem Server gehalten werden. Die Repositories Simple und Single-Key benötigen zwar weit weniger Ressourcen als die vorherigen, besitzen aber dadurch keinen Support der Browser Buttons mehr. Erst nach Erreichen des End States werden die zugehörigen Daten des Flows aus dem Repository wieder gelöscht. Demnach kann anschließend der Zustand einer View innerhalb des bereits beendeten Flows nicht mehr rekonstruiert werden. public class MeineTestKlasse extends AbstractXmlFlowExecutionTests { protected FlowDefinitionResource getFlowDefinitionResource(){ return createFlowDefinitionResource("/.../testflow-flow.xml"); } public void testStartFlow(){ ApplicationView view = applicationView(startFlow()); assertActiveFlowEquals("testflow-flow"); assertCurrentStateEquals("startingState"); assertModelAttributeNotNull("attributeName", view); assertViewNameEquals("/test.xhtml", view); } public void testStateX(){ testStartFlow(); assertCurrentStateEquals("testStateX"); MockParameterMap param = new MockParameterMap (); ApplicationView view=applicationView(signalEvent("submit", param)); assertFlowExecutionEnded(); } } Abb. 3: JUnit-Klasse zum Testen der Flow-Definition. ORDIX News 1/2008 Testen von Flows Auch das unter Entwicklern nicht sehr beliebte Testen der eigenen Anwendung wird innerhalb von Spring Web Flow durch die Integration von JUnit unterstützt. Als Beispiel wird ein JUnitTest in Abbildung 3 genauer aufgezeigt. Die JUnit-Tests werden dabei von der Klasse AbstractXmlFlowExecutionTests abge­ leitet. Innerhalb der abgeleiteten Testklasse stehen nun diverse Methoden zum Testen des Flows zur Verfügung. Mit der Methode assertCurrentStateEquals kann z. B. kontrol­liert werden, ob sich der Flow gerade in dem korrekten State befindet. Mit der Methode signalEvent wird ein User Event an den zu testenden Flow gesendet. Bei der Erstellung eines JUnit-Tests muss die Methode getFlowDefinitionResource über­schrieben werden. Innerhalb dieser Methode wird beispielsweise die konkrete FlowDefinition angegeben und es werden mögliche Subflows innerhalb des Tests registriert. Exception Handling Um Exceptions innerhalb eines Flows abzufangen, kann ein individueller Exception Handler entwickelt werden, der zwingend das Interface FlowExecutionExceptionHandler implementieren muss. Das Interface beinhaltet zwei Methoden, die vom Exception Handler imple­ men­tiert werden müssen. Ob die übergebene Exception vom Handler verarbeitet werden kann, liefert die Methode handles zurück. Die Methode handle bearbeitet die Exception und liefert gegebenenfalls ein entsprechendes ViewSelection-Objekt zurück, welches den Namen der anzuzeigenden Fehlerseite enthält. Dieser Exception Handler kann wahlweise direkt an ein View oder Action State gehängt oder global innerhalb eines Flows definiert werden. Er kann aber nur Exceptions behandeln, die innerhalb eines aktiven Flows aufgetreten sind. Alle anderen Exceptions werden durch Spring Web Flow an das darüber liegende MVCFrame­­work weitergeleitet. Zusammenspiel mit JSF Gerade bei der immer größer werdenden Beliebtheit von JSF ist der Einsatz von Spring Web Flow mit dieser Technologie interessant. Generell funktioniert die Zusammenarbeit wie bei den anderen MVC-Frameworks relativ einfach. Nur gibt es leider gerade in der Java/JEE Kombination mit JSF noch ein paar Schönheitsfehler. Wie zuvor erwähnt werden alle Exceptions, die nicht durch einen Exception Handler bearbeitet werden können, an das übergeordnete Framework weitergeleitet. Bei JSF besteht das Problem, dass es keine Möglichkeit gibt, solche Exceptions abzufangen. Daher werden diese Exceptions direkt auf der Oberfläche ausgegeben. Das ist gerade bei der häufig auftretenden NoSuchConversationException sehr störend. Sie tritt auf, wenn ein Event innerhalb eines bereits beendeten Flows ausgelöst wird. Glossar MVC JSF JSF Phase Listener JUnit Scope In diesem Fall könnte das Faces Servlet von JSF bei Bedarf erweitert werden. Inner­halb der Methode service könnte die Excep­tion abgefangen und entsprechend behandelt werden. Ein weiteres Problem ist, dass die Faces Messages durch die durchgeführten Redirects verloren gehen. Erst durch die Implementierung eines eigenen JSF-Phase-Listeners, der die Messages temporär in der Session zwischenspeichert, werden die Messages auf den jeweiligen Views wieder ausgegeben. Ausblick Mit Spring Web Flow 2.0, das im März 2008 veröffentlicht wird, werden einige neue Funktionalitäten den Weg ins Framework finden und einige bekannte „Macken“ ausgemerzt. Gerade die Integration in JSF soll durch das SpringFaces Projekt stark verbessert werden. Es soll unter anderem ein besseres Exception Handling besitzen. Auch das Vererben und Ableiten von Flow-Definitionen soll, genauso wie die Definition von Flows, in der neuen Version durch Annotations möglich sein. Fazit Der Einsatz von Spring Web Flow lohnt sich vornehmlich bei Web-Anwendungen mit logisch zusammenhängenden Dialogen, um eine Ablaufsteuerung der eigenen Anwendungsfälle zu erstellen. Für diesen Zweck stellt Spring dem Entwickler ein mächtiges Framework zur Seite, das sich sehr gut in die gängigsten WebFrameworks integrieren lässt. Nur in Kombination mit JSF sollte man ggf. auf das neue Release warten, da dieses höchstwahrscheinlich die Workarounds, die beim Exception Handling und den Faces Messages nötig sind, erspart. Model View Controller. MVC ist ein Paradigma für Benutzeroberflächen, das die getrennte Behandlung von Daten, deren Darstellung und die darauf wirkenden Benutzeraktivitäten propagiert. JavaServer Faces. JSF ist ein standardisiertes Framework zur Entwicklung von Web-Anwendungen. Ein Phase Listener klinkt sich in den JSF-Lebenszyklus ein und kann vor und nach jeder Phase innerhalb des Lebenszyklusses Logik ausführen. Ein Open Source Framework zur Durchführung von automatisierten Tests von Java-Programmen. Der Scope einer Bean definiert ihre Lebensdauer, d. h. wie lange die Bean im Speicher gehalten wird, bevor sie zur Garbage Collection freigegeben wird. Seminarempfehlung: Entwickeln mit dem Spring-Framework ► Internet: http://training.ordix.de/seminar.php?nr=643 Dieses Seminar stellt eine Einführung in das Spring-Framework dar. Spring ist ein weitverbreitetes Open-Source-Framework, das sowohl in Java Standard wie auch in Java Enterprise Projekten häufig zum Einsatz kommt. Es stellt Lösungen für die Infrastruktur der Software zur Verfügung. Spring-Anwendungen lassen sich unabhängig von der Zielarchitektur (J2SE, Web-Container, EJB-Container) entwickeln. Seminarinhalte: • • • • • • • Spring - ein Überblick Inversion of Control Container • Beans erzeugen: Bean Factories • Beans zur Verfügung stellen: Dependency Injection • Ressourcen verwalten: Application Context Möglichkeiten der aspektorientierten Programmierung • Was sind Aspekte? • Grundlegende Möglichkeiten Transaktionsmanagement Aufbau der Persistenzschicht Einbettung von Spring-Anwendungen in EJB Container Übungen Termine: 19.05.- 21.05.2008in Wiesbaden 25.08. - 27.08.2008 in Wiesbaden 27.10. - 29.10.2008 in Wiesbaden 08.12. - 10.12.2008 in Wiesbaden Seminar-ID: P-JEE-06 Dauer: 3 Tage Preis pro Teilnehmer: 1.090,00 € (zzgl. MwSt.) Christian Wiesing ([email protected]). ORDIX News 1/2008 Datenbanken Oracle Database 11g Release 1 (Teil II): ADR - Automatic Diagnostic Repository Diese Artikelreihe richtet sich an Datenbankadministratoren und -entwickler, die sich einen ersten Überblick über die wichtigsten neuen Funktionali­ täten der Version 11g Release 1 verschaffen möchten. Der erste Teil dieser Reihe hat einen Überblick über die wichtigsten Neuerungen in der Oracle Version 11g gegeben. Nun befassen wir uns mit dem neuen Advisory Frame­ work zur Fehlerdiagnose, dem Automatic Diagnostic Repository (ADR). In diesem Beitrag stellen wir die wichtigsten Bereiche dieses Tools vor. Überblick Mit Oracle 11g wird das Automatic Diagnostic Repository (ADR) neu eingeführt. Unter ADR ist ein zentrales, auf XML-Dateien basieren­ des Repository zu verstehen. Es liegt außer­ halb der Datenbank und setzt sich aus dia­gnostischen Daten zusammen. Diese Informa­ tionen musste der Administrator bisher aus vielen einzelnen Dateien zusammentragen. Zu solchen zählten zum Beispiel das Alert.log, Core Dumps, Dumps der Hintergrundprozes­se und User Trace Files. Durch das Zusammenfassen der Diagnoseinformationen, auch von mehreren Instanzen, wird dieses in Zukunft wesentlich einfacher werden. Nun können der Administrator sowie der Oracle Support leichter auf zusammenhängende Fehlerprotokolle zugreifen. Automatic Storage Management (ASM), Cluster Ready Service und andere Oracle Produkte und Komponenten speichern ihre Diagnoseinformationen ebenfalls im ADR. Jede Instanz erhält dafür ein eigenes ADRHomeverzeichnis. Alle Initialisierungsparameter, die mit „_DUMP_DEST“ enden, werden ab jetzt ignoriert. Durch den Parameter DIAGNOSTIC_DEST wird das ADR_BASEVerzeichnis gesetzt. Die­ses Verzeichnis ist das Wurzelverzeichnis des ADR. Unterhalb dieses Wurzelverzeichnisses erhält jede Instanz ein eigenes ADR-Homeverzeichnis, in dem sich dann die Verzeichnisse für Alert.log, Incident Reports, Problems usw. befinden (siehe Abbildung 1). 10 ORDIX News 1/2008 Das Alert.log Jeder, der zum ersten mal mit Oracle 11g zu tun hat, stolpert zwangsläufig über die Frage: „Wo ist das Alert.log?“ Bisher konnten wir das Alert.log in dem durch den Initialisierungsparameter BACKGROUND_DUMP_DEST festgelegten Verzeichnis finden. Dort suchen wir nun allerdings vergeblich. In Oracle 11g werden nun zwei Versionen des Alert.logs gepflegt. Zum einen existiert auch weiterhin eine in ASCI geschriebene Version. Zum anderen wird das Alert.log nun auch in der XML-Version geschrieben. Im Verzeichnis $ADR_HOME/alert finden wir nun die XML-Version des Alert.log, im Verzeichnis $ADR_HOME/trace wird es in der alten Version abgelegt. Das Alert.log in der XMLVersion kann nun bequem über den Enterprise Manager gelesen werden. Zudem gibt es die Möglichkeit, das Alert.log über den Command Interpreter des ADR (ADRCI) zu betrachten. Außerdem kann man das Alert.log auch in der alten Version wie gewohnt mit einem Texteditor der eigenen Wahl lesen. Die View V$DIAG_INFO Mit der View V$DIAG_INFO lassen sich in der Datenbank die Pfade zu den einzelnen Dateien abfragen (siehe Abbildung 2). Datenbanken • ADR_BASE: Pfad zum ADR-Wurzelverzeichnis • ADR_HOME: Pfad zum Homeverzeichnis der aktuellen Instanz • DIAG_Trace: Pfad zum textbasierten Alert.log File und den Trace-Dateien (foreground/background) • Diag Alert: Pfad zum XML Alert.log File • Default Trace File: Pfad zum trace File der aktuellen Session ADR base diag rdbms database name alert ADRCI Über das neue Kommandozeilenwerkzeug ADRCI werden die Diagnosedaten ausgelesen. Mit diesem sehr mächtigen Tool lassen sich außerdem viele diagnostische Aufgaben erledigen. Es können Diagnoseinformationen gelesen, ausgewertet oder zu einem Paket zusammengeschnürt werden. Diese Pakete können dann leicht an den Oracle Support weitergeleitet werden. Das ADRCI kann interaktiv aber auch in Skripten verwendet werden. Wie mächtig das Tool ist, möchten wir mit dem folgenden Beispiel verdeutlichen. Auswertung des Alert.logs im ADRCI Mit dem Tool ADRCI kann das Alert.log gelesen und geprüft werden. Vor dem Aufruf des ADRCI sollte geprüft werden, ob die Umgebungsvariablen richtig gesetzt sind. Mit HELP sehen Sie zunächst alle möglichen Befehle. Mit SHOW HOMES können alle ADRHomeverzeichnisse angezeigt werden. Mit SET HOMEPATH <PATH> kann das aktuelle ADR-Homeverzeichnis gesetzt werden. Mit SHOW ALERT wird das Alert.log angezeigt. Um die Anzeige auf die letzten Einträge zu beschränken, kann man mit der Option -tail arbeiten. Diese verhält sich genauso wie auch das tail unter Unix. Mit dem Schalter -f kann das „following“ eingeschaltet werden und das Alert.log live mitverfolgt werden. Mit dem Kommando SHOW ALERT –P MESSAGE_TEXT LIKE '%ORA-%' kann mit Hilfe des ADRCI nach bestimmten Begriffen gefiltert werden. In diesem Beispiel werden alle Einträge ausgegeben, die „ORA-“ beinhalten, also Fehlermeldungen. Die Ausgabe kann dann per Spool in eine Datei geschrieben werden (siehe Abbildung 3). SID ADR home cdump incident trace (andere) Abb. 1: ADR Verzeichnisstruktur. Problems und Incidents Durch den ADR werden zwei neue Konzepte eingeführt: Problems und Incidents. Problem Als Problem wird ein kritischer Fehler in einer Datenbankinstanz bezeichnet. Jedes Problem bekommt einen Problem Key, der das Problem beschreibt. Dieser beinhaltet den Fehlercode und manchmal einen oder mehrere Fehlerparameter. Mögliche Fehler in Oracle zeigt Abbildung 4. Incident Ein Incident ist das einmalige Auftreten eines Problems. Jeder Incident bekommt eine eindeutige, numerische Incident-ID. Sobald ein Incident auftritt, passiert Folgendes: Die Datenbank • schreibt einen Eintrag ins Alert.log • sendet einen alert an den Enterprise Manager • sammelt Diagnoseinformationen in Form eines Dumps • hängt dem Incident eine Dump-ID an • speichert den Incident in einem extra dafür angelegten Verzeichnis unterhalb des ADR ORDIX News 1/2008 11 Datenbanken Im ADR werden somit automatisch Incidents geschrieben. Wie lange ein Incident gespeichert werden soll, kann durch das Setzen einer Reten­tion Policy im ADRCI konfiguriert werden. Hierfür gibt es zwei Parameter, die getrennt voneinander gesetzt werden können: • • Der Status eines Incidents gibt seinen Zustand wieder. Ein Incident kann in einem der folgenden Stati sein: Die Metadata Retention Policy gibt an, wie lange Metadaten gespeichert werden. Diese wird per Default auf ein Jahr gesetzt. Die Files und Dumps Retention Policy gibt an, wie lange generierte Dump Files gespeichert werden. Hier ist der DefaultWert ein Monat. Incident Stati SQL> select name, value from v$diag_info; NAME VALUE -----------------------------------------------------------------------------------Diag EnabledTRUE ADR Base /oracle/11G ADR Home /oracle/11G/diag/rdbms/ora11g/ora11g Diag Trace /oracle/11G/diag/rdbms/ora11g/ora11g/trace Diag Alert /oracle/11G/diag/rdbms/ora11g/ora11g/alert Diag Incident /oracle/11G/diag/rdbms/ora11g/ora11g/incident Diag Cdump /tmp Health Monitor /oracle/11G/diag/rdbms/ora11g/ora11g/hm Default Trace File /oracle/11G/diag/rdbms/ora11g/ora11g/trace/ora11g_ora_3317.trc Active Problem Count 0 Active Incident Count0 Abb. 2: select * from v$DIAG_INFO. adrci> show alert -tail Completed: ALTER DATABASE OPEN 2007-10-27 21:32:54.417000 +02:00 Starting background process CJQ0 CJQ0 started with pid=29, OS id=3301 2007-10-27 21:32:59.125000 +02:00 Setting Resource Manager plan SCHEDULER[0x2C0E]:DEFAULT_MAINTENANCE_PLAN via scheduler window Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter 2007-10-27 21:33:41.629000 +02:00 Begin automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK" Sat Oct 27 21:33:42 2007 Logminer Bld: Lockdown Complete. DB_TXN_SCN is UnwindToSCN (LockdownSCN) is 951511 2007-10-27 21:34:14.682000 +02:00 End automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK" adrci> show alert -P "message_text like '%ORA-%'" ADR Home = /oracle/11G/diag/rdbms/ora11g/ora11g: ************************************************************************* Output the results to file: /tmp/alert_3474_30564_ora11g_1.ado adrci> Abb. 3: Alert.log im ADRCI. 12 ORDIX News 1/2008 Datenbanken • Collecting: Der Incident wurde soeben erzeugt und sammelt noch die Diagnoseinformationen. In diesem Zustand ist der Incident unvollständig und sollte nicht gepackt werden. • Ready: Das Sammeln der Diagnoseinformationen ist abgeschlossen und kann nun genutzt werden, um das Problem zu analysieren oder um ein Paket für den Oracle Support zu schnüren. • Tracking: Dieser Status zeigt an, dass ein Datenbankadministrator an diesem Problem arbeitet. Dieser Status muss manuell gesetzt werden. • Closed: Dieser Incident gilt als erledigt und kann vom ADR zum Löschen ausgewählt werden, sobald die Retention Policy greift. • Data Purged: Die betroffenen Dateien wurden vom Incident gelöscht. In den meisten Fällen können die Dateien auch nicht mehr genutzt werden, selbst wenn sie sich noch im File-System befinden. Fehler ORA-60X SEGV, SIGBUS Ora-4020 ORA-8103 ORA-1410 ORA-1578 ORA-29740 ORA-255 ORA-376 ORA-4030 ORA-4031 ORA-355 ORA356 ORA-353 ORA-7445 Beschreibung alle Internal Errors alle System Access Violations Deadlock on library object Object no longer exists invalid ROWID Data block corrupted Node eviction Database is not mounted File cannot be read at this time Out of memory Unable to allocate more bytes of shared memory The change numbers are out of order Inconsistent lengths in change description Log corruption Operating System exception Abb. 4: Übersicht möglicher Oracle Fehler. Glossar Der Status eines Incident kann direkt mit dem ADRCI geprüft werden: ADRCI>show incident –mode detail Incident Packaging Service (IPS) Mit IPS können Diagnoseinformationen sehr einfach und automatisch zu einem ZIP-File zusammengeschnürt werden. Dieses Paket kann dann an den Oracle Support übertragen werden. Da die Diagnoseinformationen, die zu einem kritischen Fehler gehören, mit einer ID getracked werden, müssen die Daten nicht mühsam von Hand zusammengesucht werden. Der IPS identifiziert anhand der ID die entsprechenden Informationen selbstständig und fügt diese zu einem Paket zusammen. XML Repository Core-Dump ASM CRS Extensible Markup Language. XML ist eine so genannte Metasprache zur Beschreibung von Dokumenten. Ein Vorteil von XML ist der vereinfachte Austausch von Daten, da XML-Formate in einer strengen Grammatik definiert werden können und so die Implementierung von zuverlässigen Schnittstellen erlauben. Datenbank zur Aufnahme von Metadaten über die Zielsysteme. Vorgang, bei dem nach einem ernsten Fehler der aktuelle Programmspeicher in eine Datei geschrieben wird. Automatic Storage Management. ASM ist ein im Oracle Kernel integrierter Volume Manager. Er ist ab Oracle 10g verfügbar und arbeitet nach dem SAME-Prinzip (stripe and mirror every­ thing). ASM kann als zentraler Speicher für RAC-Systeme verwendet werden. Cluster Ready Service. Eigenständige Oracle Cluster Ware, die seit Oracle 10g mitausgeliefert wird. Die Oracle Cluster Ware ist Voraussetzung für den Einsatz von Oracle RAC. Sie übernimmt die Verwaltung und die Überwachung aller beteilig­ ten Cluster-Knoten. Ab Oracle 10g wurde die CRS in Oracle Clusterware umbenannt. Seit Oracle 10gR2 ist CRS nur noch eine Teilkomponente der Oracle Clusterware. Fazit Mit ADR hat Oracle ein sehr sinnvolles Werkzeug zur Fehlersuche und -diagnose eingeführt. Viele Aufgaben, die bisher mühsam von Hand gelöst werden mussten, können nun mit geringem Aufwand ausgeführt werden. Selbst der Einsatz in vollautomatischen Skripten kann die Arbeit der Datenbankadministratoren wesentlich vereinfachen. Frank Späth ([email protected]). ORDIX News 1/2008 13 Open Source Alternative Virtualisierungslösungen: Alles virtuell mit OpenVZ und Virtuozzo Der Artikel richtet sich an System­administratoren, Anwender und Entscheider, die sich mit Virtualisierung beschäftigen und für neue Techniken/Alternativen interessieren. In vergangenen ORDIX News Artikeln haben wir schon des Öfteren über Themen aus den Bereichen der Virtualisierung berichtet. Hierbei wurden vor allem VMware und XEN, die wohl bekanntesten Virtualisierungslösungen, behandelt. In dieser Ausgabe berichten wir über OpenVZ und Virtuozzo, zwei Virtualisierungslösungen, die vor allem im Internetsektor inzwischen sehr stark verbreitet sind. OpenVZ, das Freie OpenVZ, die Open Source Virtualisierungslösung (siehe Abbildung 1), erstellt mehrere voneinander isolierte und sichere, virtuelle Umgebungen auf einem einzigen, physikalischen Linux-Server, die sich „Virtual Environment“ oder „Virtual Private Server“ (VPS) nennen. OpenVZ sorgt für eine bessere Ausnutzung der Hardware und stellt dabei sicher, dass ausgeführte Anwendungen nicht miteinander in Konflikt geraten. Jedes Virtual Environment arbeitet und verhält sich genau wie ein eigenständiger Server. Virtual Environments können unabhängig voneinander neu gestartet werden, haben einen eigenen root-Account 14 ORDIX News 1/2008 sowie eigene Benutzer, IP-Adressen, Speicher, Prozesse, Dateien, Programme, Systembibliotheken und Konfigurationsdateien. Die Prozesse eines Virtual Environments sind als Prozesse unter dem Hostsystem sichtbar und alle Prozessoren des Hostsystems können voll genutzt werden. Das Dateisystem eines Virtual Environments ist ein Unterverzeichnis auf dem Hostsystem, in dem ein komplettes Linux-Betriebssystem installiert ist. Beim Starten eines Virtual Environments wird mit dem Befehl chroot in das entsprechende Unterverzeichnis gewechselt und dort der normale init-Vorgang gestartet. Da das Hostbetriebssystem Zugriff auf alle Dateien Das Netzwerk wird durch OpenVZ weitestgehend virtualisiert. Jedes Virtual Environment kann mit einer oder mehreren IP-Adressen konfiguriert werden. Dabei sind die Virtual Environments voneinander und vom physikalischen Netzwerk isoliert. Dadurch entsteht Sicherheit, denn es ist z. B. nicht möglich, den Netzwerkverkehr eines anderen Environments oder des Hosts mit Sniffern mitzuhören. Innerhalb eines Virtual Environments ist es möglich, Routing, NAT und Firewall-Regeln einzurichten. OpenVZ unterstützt bis zu 8 CPUs mit 32 oder 64 Bit, 64 GB RAM und ein Maximum von 100 gleichzeitigen VPS-Instanzen. Dazu nutzt OpenVZ eine einzige Version des da­ runter liegenden Linux-Kernels für jede seiner VPS-Instanzen, wobei unterschiedliche Linux-Distributionen zeitgleich laufen können. Aus diesen Gründen ist OpenVZ ideal für Experimentierfreudige, IT-Integratoren und für kleinere IT-Unternehmen, in denen die Hardware möglichst gut ausgelastet sein soll und die ihre Server mit unterschiedlichen Distributionen betreiben möchten. OpenVZ ist unter der GPL Version 2 lizenziert. Das OpenVZ Softwarepaket besteht aus einem angepassten Kernel und Tools zur Verwaltung virtueller Maschinen. Ressourcenverwaltung Da alle Virtual Environments denselben Kernel nutzen, spielt die Ressourcenverwaltung eine wichtige Rolle. Jedes Virtual Environment darf nur im Rahmen seiner zugewiesenen Ressourcengrenzen bleiben und die anderen Environments nicht beeinflussen. Die Ressourcenverwaltung von OpenVZ besteht aus drei Teilsystemen: • • • Festplattenquota CPU-Scheduler User Beancounters Jede dieser Ressourcen lässt sich im laufenden Betrieb verändern. Es ist hierfür kein Neustart des Virtual Environments notwendig. Soll einem Virtual Environment beispielsweise mehr Arbeitsspeicher zugewiesen werden, root user user Application Software Virtual Private Server Virtual Private Server des Virtual Environments hat, ist der Austausch von Dateien zwischen Host und Gast leicht durchführbar. Der Austausch von Dateien zwischen den Virtual Environments wird ganz normal mit Netzwerkdiensten wie NFS, FTP, SCP etc. durchgeführt. Physical Server (Hardware Node) #1 Open Source root user user Application Software OpenVZ Templates OpenVZ Layer Host Operating System Hardware Network Abb. 1: Aufbau von Host und Virtual Environments. können die entsprechenden Parameter „on the fly“ geändert werden. Festplattenquota Da die Dateien des Virtual Environments unter dem Hostbetriebsystem komplett sichtbar sind, gibt es zwei Ebenen, auf denen der Festplattenplatz des Environments eingeschränkt werden kann. Die erste Ebene ist ein Festplattenquota pro Virtual Environment, welches auf dem Hostbetriebsystem definiert wird. Die zweite Ebene ist die standardmäßi­ge Unix-Festplattenquota pro Benutzer und pro Gruppe innerhalb eines Virtual Environments. Durch Vergrößern der entsprechenden Festplattenquota kann einem Virtual Environment, einem Benutzer oder einer Gruppe mehr Festplattenplatz zur Verfügung gestellt werden. CPU-Scheduler Auch der CPU-Scheduler in OpenVZ besitzt eine auf zwei Ebenen aufgeteilte Strategie. Auf der ersten Ebene entscheidet der Scheduler, welches Virtual Environment den CPUTakt erhält. Der Administrator kann mit dem Befehl vzctl --cpuunits unterschiedliche CPU-Scheduler Prioritäten an die Virtual Environments vergeben. Auf der zweiten Ebene entscheidet der standardmäßige LinuxScheduler, welcher Prozess im ausgewählten Virtual Environment den CPU-Takt bekommen soll. Dabei werden die Standard Linux Prioritäten (nice-Wert) von Prozessen benutzt. User Beancounters Die User Beancounters sind ein Satz von Ressourcenzählern, Limits und Garantien, die pro Virtual Environment definiert werden können. Es gibt circa 20 unterschiedliche Parameter, die vom Administrator sorgfältig ausgewählt ORDIX News 1/2008 15 Open Source werden müssen, um alle Aspekte der Virtual Environment Funktionalität zu berücksichti­ gen. Abbildung 2 zeigt eine Übersicht über mögliche User Beancounters. Zu den kontrollierten Ressourcen gehören der Arbeitsspeicher und verschiedene Kernel-Objekte, wie IPC Shared Memory Segments, NetzwerkBuffer etc. Die eingestellten Werte können unter /proc/user_beancounters innerhalb des Virtual Environments eingesehen werden. Das Feld uid in Abbildung 2 gibt die numeri­ sche Zuordnung des Virtual Environments an. uid resource held maxheld barrier limit failcnt 123:kmemsize 836919 1005343 2752512 2936012 0 lockedpages 0 0 32 32 0 privvmpages 4587 7289 49152 53575 0 shmpages 39 39 8192 8192 0 dummy 0 0 0 0 0 numproc 20 26 65 65 0 physpages 2267 2399 0 2147493647 0 vmguarpages 0 0 6144 2147493647 0 oomguarpages 2267 2399 6144 2147493647 0 numtcpsock 3 3 80 80 0 numflock 3 4 100 110 0 numpty 1 1 16 16 0 numsiginfo 0 1 256 256 0 tcpsndbuf 0 0 319488 524288 0 tcprcvbuf 0 0 319488 524288 0 othersockbuf 6684 7888 132096 336896 0 dgramrcvbuf 0 8372 132096 132096 0 numothersock 8 10 80 80 0 dcachesize 87672 92168 1048576 1097728 0 numfile 238 306 2048 2048 0 dummy 0 0 0 0 0 dummy 0 0 0 0 0 dummy 0 0 0 0 0 numiptent 10 16 128 128 0 Abb. 2: Übersicht über verfügbare User Beancounters. Weiterhin werden immer 5 Werte für jeden einzelnen Parameter angezeigt: • held: Wert der aktuellen Auslastung. • maxheld: Maximalwert der Auslastung, der während der Laufzeit des Environments erreicht wurde. • barrier: Soft-Limit. Wert für die garantiert zugesicherten Ressourcen. • limit: Hard-Limit. Ressourcenbeschränkung, die nicht überschritten werden darf. • failcnt: Der Fehlerzähler zeigt an, wie oft das Limit schon überschritten worden wäre, aber aufgrund der Beschränkung nicht überschritten werden konnte. Hier würde man sehen, ob gegebenenfalls das Limit zu gering gesetzt wurde. Die Bedeutungen von Soft-Limit und Hard-Limit unterscheiden sich von Parameter zu Parameter. Generell gilt: Wenn irgendeine Ressource das Soft-Limit überschreitet, wird der entsprechende Fehlerzähler erhöht. Wird das Hard-Limit erreicht, kann von der entsprechen­ den Ressource nicht mehr reserviert werden. Live-Migration Die Live-Migration ist eine Funktionalität von OpenVZ, die es ermöglicht, ein Virtual Environment von einem physikalischen Server auf einen anderen zu migrieren, ohne dabei das Virtual Environment komplett beenden zu müssen. Das Virtual Environment wird stattdessen eingefroren und alle Prozesse werden in einer Datei gespeichert. Dieser Vorgang des Einfrierens wird Checkpointing genannt. Anschließend wird die gespeicherte Datei auf eine andere Maschine übertragen und alle Prozesse werden wiederhergestellt. Die Übertragung des Virtual Environments auf ein anderes Hostsystem nimmt nur einige Sekunden in Anspruch, was vor allem vom gemeinsam genutzten Medium (SAN, NAS etc.) abhängig ist. Für den Benutzer äußert sich die Migration nur mit einer kleinen Verzögerung, verursacht aber keine Downtime. Die Tatsache, dass dabei der komplette Status des Virtual Environments gespeichert wird, wie zum Beispiel geöffnete Netzwerkverbindun­ gen, macht den ganzen Migrationsprozess für den Benutzer völlig transparent. Abb. 3: Administrationsmenü von Virtuozzo. 16 ORDIX News 1/2008 Einsatzgebiete der Live-Migration wären z. B. Software-Wartungsarbeiten oder ein Upgrade Open Source eines Servers, ohne alle Environments komplett beenden zu müssen. Wenn eine Datenbank oder eine andere Applikation in einem Virtual Environment mehr Arbeitsspeicher oder CPU-Ressourcen benötigt, das aktuelle Hostsystem aber keine Ressourcen mehr frei hat, kann das Virtual Environment auf ein leistungsstärkeres System „Live“ migriert werden. Dort können die entsprechenden Limits vergrößert werden. Virtuozzo, das Kommerzielle Virtuozzo ist das kommerzielle Produkt aus dem Hause SWsoft Inc., das auf Basis von OpenVZ entwickelt und weiterentwickelt wurde. Das Projekt OpenVZ wird von SWsoft unterstützt und vorangetrieben. Dabei nutzt SWsoft das Open Source Produkt als exzellente Testmöglichkeit für künftige Entwicklungen der kommerziellen, umfangreicheren Produktlinie. Die ur­sprünglichen Hauptziele bei der Entwicklung von Virtuozzo waren Leistungsfähigkeit, möglichst wenig Serverlast zu erzeugen und eine möglichst einfache Verwaltung der Gastsysteme. Im Gegensatz zu OpenVZ adressiert Virtuozzo (siehe Abbildung 3) produktive IT-Umgebungen und bietet eine höhere Skalierbarkeit, Performance sowie eine größere Vielfalt an Administrationswerkzeugen. Insgesamt gewähr­leistet Virtuozzo ein einfacheres Management und eine bessere Ausnutzung vorhandener Hardware. Außerdem läuft Virtuozzo auf Linux und auch auf Windows Servern. Auch die Einsatzszenarien sind bei Virtuozzo etwas breiter. Es werden bis zu 32 Prozesso­ ren unterstützt, die auf 32-Bit oder 64-Bit-Architektur laufen und Zigtausende an virtuellen Umgebungen erlauben. Während bei OpenVZ Administra­tion, Monitoring und Inbetriebnahme über die Kommandozeile gesteuert werden, beinhaltet Virtuozzo zusätzlich GUI- und Browser-basierte Managementwerkzeuge. Vergleich mit anderen Techniken Im Vergleich zu den Virtualisierungslösungen von VMware oder XEN bietet OpenVZ weniger Flexibilität bezüglich der Auswahl von Gast-Betriebssystemen. Sowohl als Gast- als auch als Host-Betriebssystem kann nur ein Linux-Derivat zum Einsatz kommen. Andererseits bietet die Technologie von OpenVZ bessere Leistungsfähigkeit, Skalierbarkeit, höhere Dichte, dynamische Ressourcenverwaltung und einfachere Administration. Laut Glossar Virtual Environment oder Virtual Private Server (VPS) Quota Bezeichnung der Gastsysteme unter OpenVZ, welche auf derselben Hardware ausgeführt werden. Mit Festplattenquotas kann bestimmt werden, wie viel Speicherplatz ein Benutzer oder eine Gruppe im Dateisystem belegen darf. den OpenVZ-Entwicklern verliert das System durch die Virtualisierung nur 1 - 3 Prozent der Leistung gegenüber einem System, das allein auf einer physikalischen Hardware läuft. Basierend auf seiner Architektur haben OpenVZ und Virtuozzo einen anderen Ansatz, Server zu virtualisieren als Konkurrenzprodukte, die auf Hardwareebene virtualisieren oder emulieren. Bei OpenVZ/Virtuozzo wird ein Betriebssystem gestartet, indem einfach nur weitere Prozesse gestartet werden. Das macht sich vor allem bei der Geschwindigkeit positiv bemerkbar, hat aber den Nachteil, dass Hostund Gastsystem gleich sein müssen. Manch andere Virtualisierungslösung hat hingegen den Nachteil, dass sie die einzelnen Instanzen noch zu wenig trennen kann, während die Technik von Virtuozzo ausschließt, dass durch den Absturz eines einzelnen Environments die anderen Instanzen beeinträchtigt werden. Fazit OpenVZ und Virtuozzo sind somit für Entwickler weniger geeignet, da diese meist Testumgebungen mit verschiedenen Betriebssystemen im Einsatz haben. Kommt man jedoch mit nur einem Betriebssystem aus, wie es häufig im Bereich Webhosting der Fall ist, ist man mit beiden Produkten gut beraten. Seit 2001 läuft Virtuozzo z. B. bei verschiedenen Providern mit hunderten von Virtual Environments. Dieser Erfolg spricht für sich. Ob man sich aber der Meinung von SWsoft anschließen möchte, die einfache Verwaltung und hohe Leistung insbesondere von Virtuozzo hebe die Einschränkung „nur ein Betriebssystem zu virtualisieren“ auf, da die meisten virtuellen Server sowieso unter dem gleichen Betriebssystem laufen, wie der Host selbst, bleibt natürlich jedem selbst überlassen. Christian Fertsch ([email protected]). ORDIX News 1/2008 17 Datenbanken IBM DB2 UDB 9.1 „Viper“ (Teil V): Automatisierung durch „dynamischen Speicher“ Dieser Artikel richtet sich an Datenbank- und Systemadministratoren, die sich mit den neuen Funktionen der DB2-Datenbank vertraut machen wollen. Wie in der letzten Ausgabe angekündigt, schauen wir uns in dieser ORDIX News die „dynamische Speicherung“ aus dem Bereich der automatischen Datenbankverwaltung an. Was in der deutschen Übersetzung oft als „dynamischer Speicher“ bezeichnet wird, ist in der DB2-Originaldokumentation als „Automatic Storage“ wiederzufinden. Diese Bezeichnung findet sich auch in der Syntax der verschiedenen DB2-Kommandos wieder. Wir verwenden im Folgenden den Begriff „dynamischer Speicher“. Rückblick Tablespaces Beim Anlegen einer Datenbank werden immer drei Default Tablespaces angelegt: SYSCATSPACE, TEMPSPACE und USERSPACE. Für alle weiteren Tablespaces, die nachträglich von Hand erstellt werden, müssen explizit Container mit der Klausel MANAGED BY SYS­TEM (SMS) oder MANAGED BY DATA­ BASE (DMS) des Kommandos CREATE TABLESPACE benannt werden. DMS DMS steht für „Database Managed Space“ und wird bei der Container-Definition durch die Klausel MANAGED BY DATABASE angegeben. Der Speicherplatz eines DMS-Bereichs wird vom Datenbankmanager verwaltet und sofort nach Anlegen eines Containers komplett reserviert. Dieser Speicherplatz steht dann ausschließlich der Datenbank zur Verfügung. Vom Datenbankadministrator kann für einen Container entweder eine Datei oder eine unformatierte Einheit (Raw Device) angegeben werden. SMS SMS steht für „System Managed Space“ und wird bei der Container-Definition durch die Klausel MANAGED BY SYSTEM an­gegeben. Der Speicherplatz eines SMS-Bereichs wird vom Betriebssystem verwaltet und nur so weit reserviert, wie er benötigt wird. Der Daten- 18 ORDIX News 1/2008 bankadministrator gibt lediglich das Verzeichnis für die Container vor. Welche Dateien dann letzten Endes unterhalb dieses Verzeichnisses angelegt werden, wird dem Datenbanksystem überlassen. Der Zugriff darauf erfolgt aber immer über das Betriebssystem. Wird beispielsweise eine Tabelle mit Daten befüllt, so wird auch erst zu diesem Zeitpunkt der Speicherplatz extern für Extent auf der Festplatte reserviert. Und dann auch nur in dem Maße, wie er für die neuen Daten tatsächlich benötigt wird. Datenbanken mit dynamischem Speicher Im Gegensatz zur festen Definition der Container eines Tablespace über die Syntaxklauseln MANAGED BY SYSTEM oder MANAGED BY DATABASE werden die Container beim Einsatz von dynamischem Speicher vom Daten­ bankmanager angelegt und verwaltet. Ob eine Datenbank mit dynamischem Speicher arbeitet oder nicht, wird beim Anlegen der Datenbank festgelegt. Eine nachträgliche Änderung, sowohl das Einschalten als auch das Ausschalten, ist nicht mehr möglich. Anstelle der Container bzw. der Pfade der Container werden bei der Verwendung von dynamischem Speicher nur Speicherpfade bzw. Gruppen von Speicherpfaden definiert. Datenbanken Dahinter verbirgt sich nichts anderes als Verzeichnisse im Dateisystem. Wird eine Datenbank mit dynamischem Speicher angelegt, werden die drei Default Tablespaces ebenfalls mit dynamischem Speicher angelegt. Ab der Version 9.1 ist die Verwendung von dynamischem Speicher beim Anlegen einer Datenbank Standard. Soll eine Datenbank ohne dynamischen Speicher angelegt werden, so muss man bei dem Kommando CREATE DATABASE die Syntaxerweiterung AUTO­MATIC STORAGE NO verwenden. Die Speicherpfade, die bei der Verwendung von dynamischem Speicher definiert werden können, sind der Datenbankpfad und der Speicherpfad. Die für den Datenbank- bzw. Speicherpfad angegebenen Verzeichnisse müssen vorhanden und vom Eigentümer der Instanz beschreibbar sein. Mit dem Kommando ALTER DATABASE ADD STORAGE kann der Speicherpfad um weitere Pfade erweitert werden. Datenbankpfad Im Datenbankpfad werden vom Datenbankmanager interne Verwaltungsinformationen für die Datenbank gespeichert. Wird beim Anlegen einer Datenbank der Datenbankpfad nicht definiert, so wird dafür der Standarddatenbankpfad (Datenbankmanager Konfigura­ tionsparameter DFTDBPATH) verwendet, der durch die Klausel DBPATH ON beim Anlegen einer Datenbank festgelegt wird. Wird beim Anlegen der Datenbank nur der Speicherpfad mit der Klausel ON definiert, so wird für den Datenbankpfad der erste Pfad des Speicherpfades verwendet. Speicherpfad Im Speicherpfad werden die eigentlichen Daten (Tabelleninhalte und Indizes) gespeichert. Auch für den Speicherpfad wird als Standard­ wert der Standarddatenbankpfad (Datenbankmanager Konfigurationsparameter DFTDBPATH) verwen­det. Die Abbildungen 1 - 4 zeigen verschiedene Beispiele zum Anlegen einer Datenbank mit dynamischem Speicher. Tablespaces mit dynamischem Speicher Bei Datenbanken ohne dynamischen Speicher müssen die Container den Tablespaces mit MANAGED BY SYSTEM (SMS) und MANAGED BY DATABASE (DMS) fest zugeordnet werden. Für dynamischen Speicher gibt es beim Kommando CREATE TABLESPACE die Syntaxerweiterung MANAGED BY AUTO- db2> db2> CREATE DATABASE MYDB1 db2> Abb. 1: Anlegen einer Datenbank ohne Definition von Datenbank- und Spei­ cher­pfad. Es wird der Wert des Konfigurationsparameters DFTDBPATH des Datenbankmanagers verwendet. db2> db2> CREATE DATABASE MYDB2 ON /db/pfad1 db2> Abb. 2: Anlegen einer Datenbank unter Angabe eines Speicherpfades (ON-Klausel). Dieser Wert gilt auch für den Datenbankpfad. db2> db2> CREATE DATABASE MYDB3 ON /db/pfad1, /db/pfad2 db2> Abb. 3: Anlegen einer Datenbank unter Angabe von zwei Pfaden für den Spei­ cherpfad (ON-Klausel). Als Datenbankpfad wird der erste Pfad verwendet. db2> db2> CREATE DATABASE MYDB4 ON /db/pfad1 DBPATH ON /db/pfad2 db2> Abb. 4: Anlegen einer Datenbank unter Angabe eines Speicherpfades mit der Klausel ON und Angabe eines Datenbankpfades mit der Klausel DBPATH ON. MATIC STORAGE. Es ist auch möglich, das Kommando ohne eine MANAGED BY Klausel zu verwenden. Dadurch wird für den neuen Tablespace implizit dynamischer Speicher verwendet. Die Abbildungen 5 - 8 zeigen verschiedene Beispiele zum Anlegen von Tablespaces mit dynamischem Speicher. Diese gelten allerdings nur für Datenbanken, die ebenfalls mit dynamischem Speicher angelegt wurden. Dynamischer Speicher - SMS oder DMS? Auch für den dynamischen Speicher gibt es die beiden Varianten SMS bzw. DMS. Allerdings ist die Verwendung fest vorgegeben. Reguläre und Large Tablespaces werden als DMS mit Datei-Containern angelegt. Dagegen werden Temporäre Tablespaces als SMS mit Verzeichnis-Containern angelegt. Diese Zuordnung gilt für die Version 9.1 und kann sich gemäß der ORDIX News 1/2008 19 Datenbanken IBM-Dokumentation in zukünftigen Versionen ändern. <ERW> kann sein: • Namen der Container TMP System-Tablespace für temporäre Tabellen • UTM Benutzer-Tablespace für temporäre Tabellen • • USR Benutzer oder reguläre Ausdrücke Die vom Datenbankmanager im Speicherpfad angelegten Container haben den Namen: <Speicherpfad>/<Instanz>/NODE####/ <Datenbank>/T#######/C#######.<ERW> Dabei ist: • • <Speicherpfad>Der Speicherpfad • <Instanz> Die Instanz, unter der die Datenbank angelegt ist. NODE#### Die Datenbankpartitions- nummer (z. B. NODE0000) <Datenbank> Der Name der Datenbank T####### Die Tablespace-ID C####### Die Container-ID <ERW> Der CAT-Systemkatalog • • • • LRG LOB Dynamischer Speicher RESTORE DATABASE Beim Restore einer Datenbank mit dynami­ schem Speicher können der Datenbankund der Speicherpfad neu definiert werden. Dies entspricht dem umgeleiteten Restore (Redirected Restore) einer Datenbank ohne dynamischen Speicher. Dazu gibt es beim RESTORE DATABASE die Klauseln TO, ON und DBPATH ON. Für den Datenbankpfad gilt dabei Folgendes: db2> db2> CREATE TABLESPACE MYTBS1 db2> db2> CREATE TABLESPACE MYTBS2 MANAGED BY AUTOMATIC STORAGE db2> Abb. 5: Die Tablespaces MYTBS1 und MYTBS2 werden mit dynamischem Speicher angelegt. db2> db2> CREATE TEMPORARY TABLESPACE TMPTBS db2> Abb. 6: Der system-temporäre Tablespace TMPTBS wird mit dynamischem Speicher angelegt. db2> db2> CREATE USER TEMPORARY TABLESPACE UTMPTBS MANAGED BY AUTOMATIC STORAGE db2> Abb. 7: Der benutzer-temporäre Tablespace UTMPTBS wird mit dynamischem Speicher angelegt. db2> db2> CREATE LONG TABLESPACE LONGTBS db2> Abb. 8: Der Large-Tablespace LONGTBS wird mit dynamischem Speicher angelegt. 20 ORDIX News 1/2008 Ist eine Datenbank mit dem gleichen Namen auf dem System schon vorhanden und soll durch Restore ersetzt bzw. überschrieben werden, kann der Datenbankpfad nicht geändert werden. Mit den Klauseln ON bezie­ hungsweise DBPATH ON wird der Datenbankpfad definiert, der für die wiederhergestellte Datenbank verwendet werden soll. Wird nur der Speicherpfad angegeben, so wird für den Datenbankpfad der erste Speicherpfad verwendet. Wird keine der Klauseln TO, ON oder DBPATH ON angegeben, wird für den Datenbankpfad der Wert des Parameters DFTDBPATH der Konfiguration des Datenbankmanagers verwendet. Für den Speicherpfad gibt es nur die beiden Varianten mit ON-Klausel und ohne ON-Klausel. Wird keine ON-Klausel verwendet, so werden die Speicherpfade des Backup Images verwendet. Durch Verwendung der ON-Klausel, werden die Speicherpfade für die wiederherzustellende Datenbank neu definiert. Ob eine gesicherte Datenbank mit oder ohne dynamischem Speicher gearbeitet hat und welche Speicherpfade gegebenenfalls verwendet wurden, kann mit dem Kommando db2ckbkp –s ermittelt werden. Dem Kommando wird neben der Option -s das Backup Image als Parameter übergeben. Die Ausgabe liefert unter anderem Informationen über die Speicherpfade und ob dynamischer Speicher verwendet wurde. Datenbanken Überwachung des Speicherplatzes Wie viel Speicherplatz durch den dynamischen Speicher belegt ist, ermittelt man mit einem Snapshot auf die Datenbank. Das Kommando GET SNAPSHOT FOR DATABASE ON <Datenbank> liefert die Anzahl der für den dynamischen Speicher definierten Pfade. Für jeden Pfad werden neben dem Namen eine Filesystem-ID und der freie Speicher in dem Speicherpfad ausgegeben. Zudem wird die Größe des Dateisystems ermittelt, in dem der Speicherpfad liegt und wie viel Speicher darin schon verwendet wird. Glossar Tablespace Logische Ebene zwischen der Datenbank und den Tabellen der Datenbank. Hinter einem Tablespace liegt die physikalische Zuordnung des Speicherplatzes. So erfolgt die Zuordnung des physikalischen Speicherplatzes einer Tabelle über das ihr zugeordnete Tablespace. Dabei gibt es drei verschiedene Arten von Tablespaces: • • • Container Reguläre Tablespaces dienen der Aufnahme von Daten, die nicht vom Typ LONG oder LOB sind (keine binären Objekte). Large Tablespaces dienen der Speicherung von binären Objekten in einer Datenbank (z. B. Videos oder Textdokumente). Temporäre Tablespaces dienen der Aufnahme von Daten, die nur temporär gespeichert werden müssen. Ein Container ist ein Begriff, der die Zuweisung von Plattenplatz zu einem Tabelspace beschreibt. Es gibt folgende Arten von Containern: • eine Datei im Filesystem • ein Verzeichnis im Filesystem • eine unformatierte Einheit (RAW Device) Einschränkungen Bei der Verwendung von dynamischem Speicher sind einige Einschränkungen zu beachten: • Ob dynamischer Speicher verwendet wird oder nicht, wird beim Anlegen der Datenbank festgelegt und kann nachträglich nicht mehr geändert werden. • Die verwendeten Speicherpfade müssen absolute Pfade sein. • Reguläre und LOB-Tablespaces werden bei der Verwendung von dynamischem Speicher immer als DMS angelegt. Einzelne Container können dabei nicht definiert werden. • Der Standardwert für die automatische Größenanpassung der Container ist ON. Somit ist die Größe der regulären und der LOB-Tablespaces nur durch das Dateisystem beschränkt. Die Startgröße für einen Container kann über die Klausel INITIALSIZE angegeben werden. Die Anfangsgröße für LOBS ist 32 MB. • Operationen, die auf DMS- oder SMS-Containern ausgeführt werden können, wie z. B. ALTER TABLESPACE (ADD, DROP, BEGIN NEW STRIPE SET usw.) sind bei der Verwendung von dynamischem Speicher nicht möglich. • Wie bereits beschrie­ben, können bei einem Restore nur der Datenbank- und der Speicherpfad geändert werden. Einzelne Container können nicht neu definiert werden. Somit ist der Befehl SET TABELSPACE CONTAINERS nicht möglich. Fazit Die „dynamische Speicherung“ gehört mit Sicherheit zu den interessantesten Neuerungen aus dem Bereich der automatischen Datenbankverwaltung. Sie bringt sowohl Vor- als auch Nachteile mit sich. So muss sich der Datenbankadministrator zum Beispiel nicht mehr um die Verwaltung der Container kümmern. Diese Aufgabe wird ihm vom Datenbanksys­ tem abgenommen. Auch ein umgeleiteter Restore ist um einiges einfacher und kann sogar in einem Schritt durchgeführt werden. Bei der Verwendung von dynamischem Speicher gibt der Datenbankadministrator jedoch die Möglichkeit aus der Hand, eine Zuordnung auf Ebene der physikalischen Platten vorzunehmen. Dies ist beim Einsatz von SAN kaum möglich. Die Verwendung von RAW Devices für die Container ist bei der dynamischen Speicherung nicht mehr möglich. Da die meisten Datenbankadministratoren dies bis jetzt auch nicht verwendet haben, ist das sicher kein großes Manko. Der freiwillige Verzicht auf bis zu 10 Prozent der I/O-Leistung sollte allerdings dabei bedacht werden. Haben Sie Fragen zu diesem Thema? Dann sprechen Sie uns an! Holger Demuth und Thorsten Schuhmacher ([email protected]). ORDIX News 1/2008 21 Java/JEE Mit Lasttests zur performanten JEE-Anwendung Dieser Artikel richtet sich sowohl an Entscheider als auch an Projektleiter, die größere JEE-Projekte planen und durchführen. Lasttests gehören zu jedem größeren Entwicklungsprojekt dazu, wie der TÜV zum Auto. Die Tests sind nicht gerade beliebt, aber unerlässlich, um zu alltagstauglichen, robusten und performanten Software-Anwendungen zu kommen - genauso wie zu verkehrssicheren Autos. Lasttests überprüfen die Einhaltung von zwei wichtigen Anforderungen an ein Software­system: Stabilität und Performanz. Dieser Artikel stellt anhand von Erfahrungen in einem Kundenprojekt grundlegende Aspekte und Untersuchungs­ methoden zu dieser Thematik vor. Das Kundenprojekt • Oracle als Datenbank In diesem Projekt wird eine JEE-Client-Server-Anwendung entwickelt, die aus einer Altanwendung entstanden ist und an vielen Stellen auf neuere Technologien aufsetzt, z. B.: • .Net und JScript für den Client-Anteil • • 22 ORDIX News 1/2008 JEE als Kerntechnologie mit allen Facetten (hieß zu Projektbeginn übrigens noch J2EE): ◦ WEB Container mit JSP/Servlets ◦ EJB Container mit EJB für die Business Logik ◦ Apache Webserver für das Loadbalan­ cing CORBA für die Anbindung von LegacySystemen Das komplexe Gesamtsystem hat inzwischen erfolgreich die Einführung in den Produktivbe­ trieb geschafft. Der mehrmonatige Betrieb ohne gravierende Performanzprobleme ist nicht zuletzt den umfangreichen und produktivbetriebsnahen Lasttests zu verdanken. Was sind eigentlich Lasttests? Für eine treffende Definition von Lasttests liefert uns Wikipedia eine aussagekräftige Beschreibung [1]: Java/JEE „Unter einem Lasttest versteht man einen Softwaretest, mit dem eine zu erwartende, auch extreme Last auf dem laufenden System erzeugt und das Verhalten desselbigen beobachtet und untersucht wird. Dazu kann eine Simulation eingesetzt werden. Ziel dabei ist es, 1. Fehler aufzudecken, die im funktional orientierten Systemtest/Integrationstest nicht gefunden wurden. 2. Erfüllung nichtfunktionaler Anforderungen, wie z. B. geforderte Antwortzeiten sowie Mengenverarbeitungen, für den Produktivbetrieb nachzuweisen.“ Zeitliche Einbettung in die Projektphase Es gibt eine prinzipielle Schwierigkeit, die Durchführung von Lasttests formal sauber und korrekt in den Terminplan von Entwicklungsprojekten zu platzieren. Denn eigentlich darf ein Lasttest erst dann durchgeführt werden, wenn die funktionale Korrektheit dokumentiert ist, d. h. die fachliche Abnahme der Anwendung vorliegt. Wenn dann Lasttests stattfinden, die ihrerseits Performanzschwachstellen aufdecken, geht es wieder zurück in die Entwicklung und das Prozedere „Fachliche Abnahme mit anschließen­ den Lasttests“ beginnt von vorn. In der Praxis findet deshalb häufig eine verzahnte bzw. überlappende Zeitplanung statt. So können Fehler aus den beiden Phasen „Abnahme“ und „Lasttest“ gesammelt und in einem Topf zusammengefasst werden. Diese Vorgehensweise spart Zeit in der Entwicklung bzw. Fehlerbehebung, da sich die Anzahl der Termine für Bereitstellung und Lieferung minimiert. So wurde es auch in dem von ORDIX unterstützten Kundenprojekt praktiziert. Den schematischen Zeitplan des Projekts mit den wichtigsten Phasen zeigt Abbildung 1. Performanz: Antwortzeiten und Durchsatz Die Performanz einer Anwendung kann man unter verschiedenen Gesichtspunkten betrachten. Da geht es zum einen um das Kriterium des Antwortzeitverhaltens in der Benutzer­ i­nteraktion. Dahinter steckt die Frage: „Wie lange muss der Benutzer einer Anwendung auf die Antwort einer von ihm angestoßenen Transaktion warten?“ Zum anderen ist Performanz aber auch häufig aus einer über­ geordneten Sichtweise mit der Frage­stellung assoziiert: „Wie viele Transaktionen pro Zeit- Abb. 1: Projektplan mit zeitlicher Einordnung der Lasttestphase. einheiten bewältigt das System?“ Diese Größe wird auch als Durchsatz bezeichnet. Beide Fragestellungen, die der individuellen Antwortzeit und die des globalen Durchsatzes, hängen eng miteinander zusammen. In unserem Kontext gelangte das Thema Performanz vorwiegend unter dem Aspekt Antwortzeitverhalten in die Untersuchung. Die zu testende Anwendung ist für die Servicemitarbeiter des Kunden konzipiert, die damit ihre Auftrags­vorbereitung und -abarbeitung sowie den Tagesabschluss und weitere Verwaltungsaufgaben, erledigen. Diese Geschäftsfälle und ihre zügige Abarbeitung sind für den Kunden natürlich von großem Interesse und somit standen sie während der Lasttests unter spezieller Beobachtung. Messung, Darstellung und Bewertung Die Lasttests wurden mit dem Tool JMeter [2] erstellt, einem Framework zur Erstellung von Simulatoren, die Client-Aktivitäten in sehr großem Umfang und hochparallelem Ablauf erlauben. JMeter gestattet es darüber hinaus, einzelne Client-Aktionen genau zu protokollieren und zu messen, so dass einer gezielten Analyse nichts im Wege steht [3]. Die Durchführung von einzelnen Lasttestläufen fand zu bestimmten Tageszeiten statt und ging meistens über einen Zeitraum von vier Stunden. Die Zeitdauer eines Geschäftsfalls, wie z. B. „Auftrag laden“, ist als einzelner Punkt in einem Diagramm eingetragen - an dem Zeitpunkt, als er ausgeführt wurde. Die Punktwolke setzt sich aus allen gemessenen Zeiten für diesen Geschäftsfall zusammen und die schwarze Linie stellt den gleitenden Durchschnitt dar. Die Zeitskala (8:00 - 12:00 h) gibt die Dauer dieses konkreten Lasttestlaufs an (siehe Abbildung 2). ORDIX News 1/2008 23 Java/JEE In Abbildung 3 sind die wichtigen Geschäftsfälle oder Client-Aktionen aufgelistet, die in den Lasttestläufen simuliert wurden. Typische Durchläufe dauerten jeweils vier Stunden und die Gesamtanzahl aller simulierten Geschäfts­ fälle pro Testlauf erreichte ca. 200.000. Von jedem einzelnen Geschäftsfall wurden die Dauer und der Zeitpunkt der Rückkehr gemessen. Die interessanten statistischen Größen sind der Mittelwert der Antwortzeiten pro Geschäftsfall in Sekunden und der Anteil der Geschäftsfälle, die eine vorgegebene Zeitdauer unterschreiten. Laufzeiten von GF 3: "Auftrag laden" Server Request Zeiten in Sekunden 50 45 40 35 30 25 20 15 10 5 0 8:00 8:20 8:40 9:00 9:20 9:40 10:00 10:20 10:40 11:00 11:20 11:40 12:00 Tageszeit Abb. 2: Punktwolke der Einzeldauern von konkreten Geschäftsfällen im Lasttest. Mittelwert (sec) Anteil <= X sec Gewichtung 1 Client: Anmelden m1 A1 (<= 5 sec) (1- A1) / 0,5 2 Edda: Liste laden m2 A2 (<= 10 sec) (1- A2) / 0,5 3 Client: Auftrag laden m3 A3 (<= 10 sec) (1- A3) / 0,5 4 Client: Auftrag abschließen m4 A4 (<= 10 sec) (1- A4) / 0,5 5 Client: Tagesabschluss m5 A5 (<= 5 sec) (1- A5) / 0,5 Abb. 3: Mittelwerte der Zeitdauern und Vorgaben, welche Antwortzeiten bei einzelnen Geschäfts­fällen einzuhalten sind. Die Spalte Gewichtung ist für die Bewertung der Testläufe von Bedeutung. CPU-Auslastung: Server 1 100 90 CPU in Prozent 80 %usr %sys 70 60 50 40 30 20 12:00 11:50 11:40 11:30 11:20 11:10 11:00 10:50 10:40 10:30 10:20 10:10 9:50 10:00 9:40 9:30 9:20 9:10 9:00 8:50 8:40 8:30 8:20 8:10 0 8:00 10 Abb. 4: CPU-Auslastung für einen Server im Zeitraum eines Lasttestlaufs. 24 ORDIX News 1/2008 Zusammen mit einem Netzplandiagramm wer­ den daraus die Kriterien für „erfolgreiche“ Lasttests abgeleitet. Aber dazu später mehr. Stabilität Mit Stabilität oder Robustheit ist die Ausfallwahrscheinlichkeit einer Anwendung gemeint. Ausfälle können durch eine Vielzahl von Gründen auftreten, häufig durch schiere Überlastung der Prozessoren. Daher stand die Überwachung der CPU-Auslastung in den verschiedenen Server­systemen bei unseren Lasttests im Vordergrund, von denen eine Auslastungskurve beispielhaft in Abbildung 4 zu sehen ist. Von Interesse in der hier zugrunde liegenden Gesamtanwendung sind vier unterschiedliche Server­systeme, die sich vom Typus her in jeweils zwei Application Server und zwei Datenbank Server aufteilen. Bei beiden Datenbank Servern und einem der Application Server handelt es sich um Mehr-CPU-Maschinen des Herstellers Fujitsu Siemens Computers mit dem Betriebssystem Sun Solaris 8. Hinter dem anderen Application Server verbirgt sich in Wirklichkeit eine Serverfarm, bestehend aus bis zu 40 Windows 2000 Servern. In der Lasttestumgebung kommt eine analoge Serverlandschaft zum Einsatz, die allerdings von der Ausstattung her „nur“ über ca. 20 Prozent der Hardware-Ressourcen des Produktivbetriebs verfügt. Auch diese Messergebnisse der CPU-Auslastungen von allen Servern müssen wieder zusammen­gefasst und verdichtet werden, was beispielhaft die Abbildung 5 für einen konkre­ ten Lasttestlauf zeigt. Für die CPU-Auslas­ tung sind als statistische Größen besonders der Mittel- und der Maximalwert, aber auch der prozentuale Anteil der Gesamtzeit interes­ sant, bei der die CPU-Auslastung mehr als 50 Prozent beträgt. Java/JEE Ergebnisse ins rechte Licht rücken Nachdem wir nun eine ganze Reihe von Mess­ ergebnissen und Zusammenfassungen ermittelt und statistische Aufbereitung betrieben haben, fehlt noch der letzte Schritt der Bewertung. Diese muss übersichtlich und vor allem aussagekräftig sein, da man in typischen Lasttestphasen mehrere Dutzend verschiedener Testläufe durchführt und diese eine rasche Einschätzung und Kategorisierung benötigen. Für diesen Schritt haben wir Netzplandiagramme aus MS Excel verwendet (siehe Abbildung 6). In dem Netzplandiagramm „Laufzeiten“ sind die Werte aus der Spalte Gewichtung aus Abbildung 3 eingetragen, die zwischen 0 und 1 liegen können. Das globale Kriterium dafür, ob ein Lasttestlauf in dieser Kategorie erfolgreich war oder nicht, lautet: „Es darf keine Ausreißer im Netzplan geben“. D. h. im Fall der Lauf­ zeiten: Kein Wert darf > 0,5 sein, was durch die rote Linie markiert ist. Bezogen auf den Geschäftsfall „1 Client: Anmelden“ aus Abbildung 3 bedeutet das z. B.: Nicht mehr als 25 Prozent aller Anmeldungen dürfen länger als 5 Sekunden dauern. Analog dürfen keine Ausreißer bei den CPUAuslastungen auftreten, deren Netzplandiagramm mit den Werten der Spalte Anteil > 50 % aus Abbildung 5 gefüllt ist. Im vorliegenden Fall wurde der konkrete Lasttest als gerade noch bestanden bewertet, obwohl es eine kleine Überschreitung der erlaubten Laufzeit in einem Geschäftsfall 1 gibt. So wurden etliche Runden gedreht - mit zum Teil auch schlechten Netzplandiagrammen und deutlichen Aus­reißern in mehreren Dimensionen. Aber gerade diese Aufbereitung und Darstellung der Messdaten hat wertvolle Dienste in der Fehlersuche und der Aufde­ ckung von Performanzschwächen geleis­tet. Am Ende der Lasttestphase lautete das Ergebnis der Lasttests schlicht: „Die Anwendung ist performant und stabil“. Fazit Lasttests gehören zu jedem größeren Softwareprojekt essentiell dazu und können nicht früh genug in die Planung einbezogen werden. Antwortzeitverhalten, CPU- und Hauptspeicherauslastung sowie deren statistische Auswertung und Bewertung haben sich als geeignete Analysemethoden herausgestellt. ORDIX hat viel Erfahrung in diesem Themenkomplex gesammelt und bringt auch Ihre An- CPU-Auslastung, Statistik Mittelwert Maxwert Anteil > 50 % 1 App Server AD 32,8 % 91,0 % 6,5 % 2 App Server CS 35,3 % 78,3 % 22,1 % 3 DB Server AD 7,3 % 71,0 % 0,4 % 4 DB Server CS 36,9 % 56,0 % 0,0 % Abb. 5: Messergebnisse der CPU-Auslastung aller beteiligten Serversysteme. Laufzeiten CPU Auslastung 1 6 1 2 4 5 2 3 3 4 Abb. 6: Netzplandiagramme für die Bewertung. Glossar Netzplandiagramm JMeter Flächenhafter Diagrammtyp in MS Excel, um zusammenhängende Größen anschaulich darzustellen. Die n-Achsen, an denen die Größen abgetragen werden, haben einen gemeinsamen Ursprung und spannen eine Art „Spinnennetz“ auf. Wird häufig im Projektmanagement eingesetzt, um z. B. kritische Abhängigkeiten zu zeigen. Open Source Framework in Java-Technologie zur Erstellung von Lasttest-Simulatoren (Sampler). JMeter verfügt in seiner aktuellen Version 2.3.1 über eine große Anzahl vorgefertigter Sampler. Links ► [1] Definition von Lasttests in Wikipedia: http://de.wikipedia.org/wiki/Lasttest_(Computer) ► [2] JMeter: http://jakarta.apache.org/jmeter/ ► [3] ORDIX News Artikel „Last- und Performancetests mit JMeter“: http://www.ordix.de/ORDIXNews/3_2004/jmeter.html wendung gerne durch belastende Tests zu Stabilität und Performanz. Dr. Hubert Austermeier ([email protected]). ORDIX News 1/2008 25 Seminartermine - heraustrennbare Übersicht - Datenbanken Datenbank-Hochverfügbarkeitslösungen für Entscheider Datenbank-Modellierung Oracle SQL Oracle SQL für Umsteiger Oracle SQL für Experten Oracle Datenbankprogrammierung mit PL/SQL Oracle PL/SQL Aufbau mit LOB Programmierung Oracle Datenbankadministration Grundlagen Oracle Datenbankadministration Aufbau Oracle Backup und Recovery Oracle Tuning und Monitoring Oracle Troubleshooting Workshop Oracle Real Application Cluster (RAC) Oracle 10g Neuheiten Oracle 11g Neuheiten Oracle Security Oracle Data Guard Oracle RMAN Oracle Grid Control Oracle Advanced Queuing Oracle Replication Informix SQL Informix Dynamic Server Administration Informix Tuning und Monitoring Informix Backup und Recovery mit ON-Bar Informix 11 Neuheiten Informix Hochverfügbarkeits-Technologien IBM DB2 für Linux/Unix/Windows SQL Grundlagen IBM DB2 für Linux/Unix/Windows Administration IBM DB2 für Linux/Unix/Windows Version 9.1 Neuheiten IBM DB2 für Linux/Unix/Windows Monitoring, Tuning und HV MySQL Administration Microsoft SQL Server Administration Microsoft SQL Server Hochverfügbarkeits-Workshop Programmierung Einführung in die objektorientierte Programmierung Perl Programmierung Grundlagen Perl Programmierung Aufbau Shell, Awk und Sed Awk Intensiv-Workshop Einführung in XML XML Programmierung unter Java mit DOM und SAX Oracle und XML PHP Programmierung Grundlagen PHP Programmierung Aufbau Java-JEE Java Programmierung Grundlagen Java Programmierung Aufbau Java GUI Entwicklung mit Swing JEE für Entscheider Einführung in JEE JSP und Servlet Programmierung EJB Programmierung Web-Anwendungen mit JavaServer Faces (JSF) Entwickeln mit dem Spring-Framework Java Web Services Entwicklung mit Hibernate Web- und Applikations-Server Apache Web-Server Installation und Administration Tomcat Konfiguration und Administration WebSphere Application Server Installation und Administration Administration und Konfiguration für JBoss Betriebssysteme Unix/Linux Grundlagen für Einsteiger Linux Systemadministration Linux Netzwerkadministration Server-Virtualisierung mit XEN Linux Hochverfügbarkeits-Cluster Unix/Linux Security OpenLDAP - Praxiseinsatz im Netzwerk Solaris Systemadministration Grundlagen Solaris Systemadministration Aufbau Solaris kompakt Solaris 10 für erfahrene Systemadministratoren Solaris Containers Zettabyte Filesystem (ZFS) Workshop AIX Systemadministration Grundlagen Multivendor-Systemadministration Systemmanagement Systemüberwachung mit Nagios BMC Performance Manager Basics BMC Performance Manager Advanced BMC Performance Manager Customizing and Development Projektmanagement IT-Projektmanagement Grundlagen des IT-Controlling Projektdefinition und -planung Projekte steuern und überwachen Wiesbaden Lippstadt 490,00 790,00 1.790,00 790,00 1.190,00 1.790,00 1.490,00 1.890,00 1.890,00 1.890,00 1.890,00 1.890,00 1.890,00 1.890,00 1.890,00 1.190,00 1.490,00 1.490,00 1.090,00 1.090,00 1.090,00 1.590,00 1.790,00 1.890,00 1.090,00 490,00 1.490,00 1.790,00 1.890,00 790,00 1.190,00 1.090,00 1.790,00 790,00 1.090,00 1.590,00 1.590,00 1.590,00 1.090,00 1.090,00 790,00 790,00 1.590,00 1.090,00 1.590,00 1.590,00 1.590,00 450,00 1.090,00 1.590,00 1.590,00 1.590,00 1.090,00 1.090,00 1.090,00 1.090,00 1.090,00 1.290,00 1.090,00 1.590,00 1.590,00 1.590,00 1.090,00 1.190,00 1.090,00 1.090,00 1.890,00 1.890,00 1.890,00 1.890,00 790,00 790,00 1.890,00 1.890,00 1.090,00 1.890,00 1.890,00 1.490,00 1.890,00 1.190,00 1.890,00 1.190,00 nächster Termin: 10.11.2008 - 14.11.2008 in WI *) Preise pro Seminar pro Teilnehmer in Euro. Alle Preise gelten zzgl. ges. MwSt. **) Inhousepreise auf Anfrage. Für Informationen und Fragen zu individuell zugeschnittenen Seminaren, Ausbildungsreihen oder Inhouse-Schulungen stehen wir jederzeit gerne zur Verfügung. Auf Wunsch senden wir Ihnen auch unser komplettes Seminarprogramm zu. 26 ORDIX News 1/2008 KW 26 KW 25 KW 24 KW 23 KW 22 Juni KW 21 KW 20 KW 19 KW 18 Mai KW 17 KW 16 KW 15 KW 14 April KW 13 KW 12 März KW 11 Preis in EURO*)**) http://training.ordix.de Online-Anmeldung und stets aktuelle Seminarinhalte und Termine! KW 42 KW 41 Okt. KW 40 KW 39 KW 38 KW 37 KW 36 September KW 35 KW 34 KW 33 KW 32 KW 31 August KW 30 KW 29 KW 28 KW 27 Juli März - Oktober 2008 Preis in EURO*)**) 490,00 790,00 1.790,00 790,00 1.190,00 1.790,00 1.490,00 1.890,00 1.890,00 1.890,00 1.890,00 1.890,00 1.890,00 1.890,00 1.890,00 1.190,00 1.490,00 1.490,00 1.090,00 1.090,00 1.090,00 1.590,00 1.790,00 1.890,00 1.090,00 490,00 1.490,00 1.790,00 1.890,00 790,00 1.190,00 1.090,00 1.790,00 790,00 1.090,00 1.590,00 1.590,00 1.590,00 1.090,00 1.090,00 790,00 790,00 1.590,00 1.090,00 1.590,00 1.590,00 1.590,00 450,00 1.090,00 1.590,00 1.590,00 1.590,00 1.090,00 1.090,00 1.090,00 1.090,00 1.090,00 1.290,00 1.090,00 1.590,00 1.590,00 1.590,00 1.090,00 1.190,00 1.090,00 1.090,00 1.890,00 1.890,00 1.890,00 1.890,00 790,00 790,00 1.890,00 1.890,00 1.090,00 1.890,00 1.890,00 1.490,00 Jetzt zum Frühbucherpreis von 1.701,00 €*) buchen! 1.890,00 1.190,00 1.890,00 1.190,00 Datenbanken Datenbank-Hochverfügbarkeitslösungen für Entscheider Datenbank-Modellierung Oracle SQL Oracle SQL für Umsteiger Oracle SQL für Experten Oracle Datenbankprogrammierung mit PL/SQL Oracle PL/SQL Aufbau mit LOB Programmierung Oracle Datenbankadministration Grundlagen Oracle Datenbankadministration Aufbau Oracle Backup und Recovery Oracle Tuning und Monitoring Oracle Troubleshooting Workshop Oracle Real Application Cluster (RAC) Oracle 10g Neuheiten Oracle 11g Neuheiten Oracle Security Oracle Data Guard Oracle RMAN Oracle Grid Control Oracle Advanced Queuing Oracle Replication Informix SQL Informix Dynamic Server Administration Informix Tuning und Monitoring Informix Backup und Recovery mit ON-Bar Informix 11 Neuheiten Informix Hochverfügbarkeits-Technologien IBM DB2 für Linux/Unix/Windows SQL Grundlagen IBM DB2 für Linux/Unix/Windows Administration IBM DB2 für Linux/Unix/Windows Version 9.1 Neuheiten IBM DB2 für Linux/Unix/Windows Monitoring, Tuning und HV MySQL Administration Microsoft SQL Server Administration Microsoft SQL Server Hochverfügbarkeits-Workshop Programmierung Einführung in die objektorientierte Programmierung Perl Programmierung Grundlagen Perl Programmierung Aufbau Shell, Awk und Sed Awk Intensiv-Workshop Einführung in XML XML Programmierung unter Java mit DOM und SAX Oracle und XML PHP Programmierung Grundlagen PHP Programmierung Aufbau Java-JEE Java Programmierung Grundlagen Java Programmierung Aufbau Java GUI Entwicklung mit Swing JEE für Entscheider Einführung in JEE JSP und Servlet Programmierung EJB Programmierung Web-Anwendungen mit JavaServer Faces (JSF) Entwickeln mit dem Spring-Framework Java Web Services Entwicklung mit Hibernate Web- und Applikations-Server Apache Web-Server Installation und Administration Tomcat Konfiguration und Administration WebSphere Application Server Installation und Administration Administration und Konfiguration für JBoss Betriebssysteme Unix/Linux Grundlagen für Einsteiger Linux Systemadministration Linux Netzwerkadministration Server-Virtualisierung mit XEN Linux Hochverfügbarkeits-Cluster Unix/Linux Security OpenLDAP - Praxiseinsatz im Netzwerk Solaris Systemadministration Grundlagen Solaris Systemadministration Aufbau Solaris kompakt Solaris 10 für erfahrene Systemadministratoren Solaris Containers Zettabyte Filesystem (ZFS) Workshop AIX Systemadministration Grundlagen Multivendor-Systemadministration Systemmanagement Systemüberwachung mit Nagios BMC Performance Manager Basics BMC Performance Manager Advanced BMC Performance Manager Customizing and Development Projektmanagement IT-Projektmanagement Grundlagen des IT-Controlling Projektdefinition und -planung Projekte steuern und überwachen Informationen und Anmeldung: ORDIX AG Westernmauer 12 - 16 33098 Paderborn Tel.: 05251 1063-0 ORDIX AG Kreuzberger Ring 13 65205 Wiesbaden Tel.: 0611 77840-00 zentrales Fax: bzw. E-Mail: Online-Anmeldung: 0180 1 ORDIX 0 0180 1 67349 0 [email protected] http://training.ordix.de ORDIX News 1/2008 27 Java/JEE Excel-Tools unter Java im Vergleich: JExcelAPI und Jakarta POI – David gegen Goliath? Dieser Artikel richtet sich vorwiegend an JavaEntwickler, die in ihren Projekten Excel-Dateien bearbeiten oder erstellen müssen. Das Jakarta-Projekt POI ist sicherlich die bekannteste Bibliothek, die in der Lage ist, Dateien von Microsoft Office unter Java zu bearbeiten. Es existieren jedoch eine Reihe weiterer Bibliotheken, die mit Excel-Dateien umgehen können. Für diesen Artikel wurden das POI-Projekt [1] und die Bibliothek JExcelAPI [2] „in den Ring geschickt“, um gegeneinander anzutreten und ihre Unterschiede im Umgang mit Excel-Dateien herauszustellen. In der rechten Ecke: Das JExcelAPI Der Herausforderer in Form des JExcelAPI existiert zwar schon einige Jahre, hat aber bis heute noch nicht den Verbreitungsgrad seines Kontrahenten, dem Jakarta-Projekt POI erreicht. Im Gegensatz zum POI-Projekt, das im Zeitraum von 2004 bis 2007 kaum weiterentwickelt wurde, wurde JExcel in dieser Zeit kontinuierlich verbessert und zunehmend aus­ gereifter. Mittlerweile bieten einige Projekte, die z. B. für einen Export bisher ausschließlich auf POI gesetzt haben, zusätzliche Schnittstellen für die JExcelAPI an. Als Beispiel sei hier JasperReport genannt, dessen Exportfunktion seit einiger Zeit nicht nur durch POI sondern auch durch JExcel realisiert werden kann. ORDIX News 1/2008 Daher ist es mit Hilfe der POI-Bibliothek auch möglich, Microsoft Word-, Powerpoint-, Outlook- und Visio-Dateien zu bearbeiten. Dieser Artikel beschränkt sich jedoch auf das Modul HSSF (Horrible Spreadsheet Format, zu deutsch in etwa „furchtbares Arbeitsblattformat“) für die Bearbeitung von Excel-Dateien. Die aktuellste stabile Version 3.0.1 ist Mitte 2007 erschienen [3]. Funktionen des JExcelAPI In der linken Ecke: Das Jakarta POI-Projekt JExcel kann alle Excel-Dateien von der Version 97 bis 2003 interpretieren und Dateien erzeugen, die zu diesen Versionen kompatibel sind. Von Excel 2007 erstellte *.xlsx-Dateien, die auf dem OOXML-Dateiformat basieren, können allerdings von der JExcelAPI nicht interpretiert werden. Nun schauen wir auf den „Altmeister“ und fragen uns, wie ein Entwicklungsteam auf die Idee kommen kann, sein Projekt „Poor Obfuscation Implementation“ (zu deutsch in etwa „armselige, verwirrende Implementierung“) zu benennen. Der Name ist jedoch nicht auf das Projekt Einfache Bestandteile eines Excel-Sheets, wie z. B. Grafiken, Kommentare, viele Formeln, verschiedenen Zellen oder auch Datums- und Nummernformatierung, stellen für JExcel kein Problem dar. Seine Schwächen offenbart das Archiv vor allem beim Auslesen Die Bibliothek steht aktuell in der im Oktober 2007 erschienenen Version 2.6.6 zur Verfügung [2]. 28 selbst, sondern vielmehr auf das den OfficeDateien zugrunde liegende OLE2-Dateiformat bezogen. POI stellt eine Java-Implementierung dieses von Microsoft definierten Formats dar und besteht aus mehreren Modulen. Java/JEE der Meta-Daten des OLE2-Dateiformates, sowie bei der Bearbeitung von Makros. Letztere kann JExcel zwar kopieren bzw. von einem in das andere Workbook-Objekt übertragen, erstellen oder bearbeiten kann es Makros jedoch nicht. Die Projektseite bietet zwar ein FAQ und ein kleines Tutorial an, es wird dabei aber bei Weitem nicht der ganze Funktionsumfang dieser Bibliothek behandelt. Im Allgemeinen ist die Verwendung der Funktionen sehr intuitiv, aber bei speziellen Problemen und Fragen, vor allem in der Einarbeitungszeit, ist gelegentlich doch etwas mehr Rechercheaufwand für die Problemlösung erforderlich. Funktionen des POI Das Apache-Projekt ist, genau wie JExcel, in der Lage, Dateien der Excel-Versionen 97 bis 2003 zu lesen und zu bearbeiten. Mit dem OOXML-Dateiformat der 2007er Version von Microsoft Excel kann jedoch das Jakarta POI ebenfalls nicht umgehen. Mit den allermeisten Funktionalitäten aus Excel kommt POI sehr gut zurecht. Neben einfachen Datums-, Nummern- und Fließkomma­zellen oder auch Grafiken, Charts und Kom­mentaren unterstützt das Archiv sehr viele Excel-Formeln, ist in der Lage die Meta-Daten der Datei auszulesen und kann auch mit Makros umgehen. Für einen umfangreichen Zugriff auf einzelne Elemente der Dateistruktur existiert ein Low Level-API, das einen sehr tiefgreifenden Einfluss auf die Datenstruktur erlaubt und vor allem für das Auslesen von Meta-Daten sehr hilfreich sein kann. Die meisten Funktionen des HSSF-Moduls sind sehr gut dokumentiert und die Projektseite der Apache-Group bietet viele Beispiele an. Dies hilft insbesondere in der Einarbeitungszeit, da manche Vorgehensweisen nicht sehr intuitiv sind. // Erstellen und parametrisieren des Settings-Objektes WorkbookSettings ws = new WorkbookSettings(); ws.setSuppressWarnings(false); ... ... // Erstellen des Workbooks und des Sheets WritableWorkbook workbook = Workbook.createWorkbook(new File(...)); WritableSheet sheet = workbook.createSheet("Name des Sheets", nSheetIndex); // Erstellen eines Zellenformats WritableFont fontUeberschrift = new WritableFont(WritableFont. ARIAL, 12, WritableFont.BOLD); WritableCellFormat formatUeberschrift = new WritableCellFormat (fontUeberschrift); // Erstellen einer Zelle sheet.addCell(new Label(0, 0, "Ueberschrift Spalte 1", format­ Ueberschrift)); ... // Daten rausschreiben workbook.write(); workbook.close(); Abb. 1: Erzeugen eines neuen Excel-Files mit dem JExcelAPI. // Erstellen eines neuen Workbooks und eines Sheets HSSFWorkbook workbook = new HSSFWorkbook(); HSSFSheet sheet = workbook.createSheet("Test-Sheet"); // Erstellen einer neuen Zeile HSSFRow row = sheet.createRow(0); // Erstellen eines neuen Zellenformates HSSFFont fontUeberschrift = workbook.createFont(); fontUeberschrift.setFontName(HSSFFont.FONT_ARIAL); HSSFCellStyle cellStyleUeberschrift = workbook.createCellStyle(); // Erstellen einer neuen Zelle Cell cell = row.createCell((short)0); cell.setCellValue(new HSSFRichTextString("Ueberschrift Spalte 1")); cell.setCellStyle(cellStyleUeberschrift); cellStyleUeberschrift.setFont(fontUeberschrift); // Erstellen des Outputs FileOutputStream out = new FileOutputStream(new File(....)); // Herausschreiben der Daten workbook.write(out); out.close(); Abb. 2: Erzeugen eines neuen Excel-Files mit der POI-Bibliothek. Erstellen von Dateien mit dem JExcelAPI Für das Erstellen einer Excel-Datei mit dem JExcelAPI wird zunächst ein WritableWorkbook-Objekt erstellt, das eine ExcelMappe repräsentiert. Einem Workbook wird im Konstruktor das Ausgabe-Objekt (z. B. ein Outputstream oder ein File-Objekt) übergeben. Das WritableWorkbook kann mit Hilfe des WorkbookSettings-Objekts konfiguriert werden (siehe Abbildung 1). Über eine createSheet-Methode können dann einzelne Arbeitsblätter (Sheets) erzeugt werden. Diesen wiederum kann man dann über die addCell-Methode beliebig viele Zellen hinzufügen. Der addCell-Methode wird hierfür ein Objekt des Interface-Typs Writ­ableCell übergeben, das Angaben über seine Position, seinen Inhalt und seine Formatierung enthält. ORDIX News 1/2008 29 Java/JEE Es existieren mehrere Implementierungen des Interfaces WritableCell. Die wichtigsten sind Boolean, Number, Label und Date­Time, die in der Lage sind, die entspre­ chenden Java-Datentypen in einer ExcelZelle darzustellen und gegebenenfalls Aus­ gabeformatierungen auf sie anzuwenden. Eine weitere, wichtige Implementierung dieses Interfaces ist die Klasse Formula, die es ermöglicht, eine Formelzelle zu definieren, in der eine Excel-Funktion enthalten ist [z. B. „Summe(A1:A8)“]. Die Formatierung der Zelle wird dabei über ein WritableCellFormat definiert. Da lediglich eine begrenzte Anzahl von Zellenformaten gleichzeitig verwaltet werden kann, kann es zu Problemen kommen, wenn innerhalb eines Dokuments zu viele WritableCellFormat-Objekte erstellt werden. In diesem Falle werden die Zellen, die nach Erreichen der Höchstzahl dargestellt werden, ohne Formatierung ausgegeben. Erstellen von Dateien mit der Jakarta POI Genau wie JExcel kennt auch POI ObjektRepräsentationen einer Excel-Mappe, eines Arbeitsblattes und einer Zelle in Form eines HSSFWorkbook-, eines HSSFSheet- und eines HSSFCell-Objektes (siehe Abbildung 2). Glossar API Bibliothek Meta-Daten OOXML Application Programming Interface. Ein API ist eine Sammlung von Klassen, welche eine Schnittstelle zu einer Hardware oder Anwendung definieren. Archiv mit einer Sammlung von Klassen, die bestimmte Funktionalitäten bereitstellen und in andere Projekte integriert werden können. Daten, die nicht zu den Nutzdaten gehören, sondern Informationen über die eigentlichen Nutzdaten beinhalten. Office Open XML. OOXML ist ein von der Firma Microsoft entwickeltes, auf XML basierendes Dateiformat für Office-Anwendungen. Links Im Gegensatz zum JExcelAPI besteht jedoch nicht die Möglichkeit, Zellen direkt einer Position im Sheet zuzuweisen. Für jede Zeile, die über eine oder mehrere Zellen verfügen soll, ist zunächst die Erzeugung eines HSSFRowObjektes notwendig. Dieses stellt wiederum Methoden bereit, um Zellen an einer bestimmten Spaltenposition der Zeile zu erstellen. Die Position, der Inhalt und die Formatierung der Zelle werden im Gegensatz zum JExcel API jedoch nicht in einem separaten Objekt gehalten, sondern direkt dem Cell-Objekt übergeben. Die Methode setCellValue kann dabei mit verschiedenen Übergabeparametern, z. B. einem boolean-Wert, einem double-Wert oder einem Date-Objekt aufgerufen werden. Um eine Formelzelle zu erzeugen, stellt das Cell-Objekt die Methode setCellFormula bereit. Einlesen von Dateien mit dem JExcelAPI Das Einlesen von bestehenden Excel-Dateien gestaltet sich mit Hilfe des JExcelAPI recht einfach. Neben dem WritableWorkbook stellt das Archiv auch ein einfaches Workbook-Objekt bereit, dessen Konstruktor einer bereits bestehenden Excel-Datei übergeben werden kann. Über entsprechende getter-Methoden kann man dann auf die einzelnen Elemente, bis hin zu den einzelnen Zellen, zugreifen und diese auslesen. Über die getType-Methode des Cell-Objektes lässt sich der Typ des Inhalts bestimmen und anschließend in den spezifischen Cell-Type umwandeln. Dieser stellt dann entsprechende Methoden bereit, um den Zelleninhalt auszulesen. Das Workbook kann entweder über eine statische Methode direkt erstellt oder über das WorkbookParser-Objekt geholt werden, das neben dem Workbook auch aus dem Dokument ausgelesene Meta-Informationen bereitstellt. Ein einfaches Beispiel für das Einlesen einer Excel-Datei mit Hilfe der JExcelAPI ist in dem Beispielprojekt zu diesem Artikel [5] enthalten. ► [1] Projektseite des Apache POI-Projektes: http://poi.apache.org/ ► [2] Projektseite der JExcelAPI: http://jexcelapi.sourceforge.net/ ► [3] Übersicht über das HSSF-Modul: http://poi.apache.org/hssf/index.html ► [4] Tutorial für JExcelAPI, leider nicht ganz aktuell: http://www.andykhan.com/jexcelapi/tutorial.html ► [5] Beispielprojekt zu diesem Artikel: ► Netbeans-Projekt: http://www.ordix.de/ORDIXNews/1_2008/example_netbeans.zip ► Eclipse-Projekt: http://www.ordix.de/ORDIXNews/1_2008/example_eclipse.zip ► [6] Weitere Java-Archive zur Bearbeitung von Excel: http://www.smartxls.com 30 ORDIX News 1/2008 Einlesen von Dateien mit dem POI-Archiv Das Lesen oder Bearbeiten von Excel-Dateien kann über das HSSF-Modul ähnlich umgesetzt werden wie mittels JExcel. Das UserAPI bietet auch hier über entsprechende getter-Methoden Zugriff auf die einzelnen Bestandteile, wie Sheets, Rows oder Cells. Diese kön­nen entfernt, geändert oder durch andere Objekte ersetzt werden. Java/JEE JExcelAPI und Jakarta POI im Expertencheck Jakarta POI JExcelAPI 1. Wie viel Handlungsfreiheit lässt die Lizenz? 2. Erlernbarkeit 3. Umfang der „lesen“-Funktion „Das JExcelAPI erlaubt den Umgang mit Excel-Dateien aus Java heraus mit minimalem Einarbeitungs-/Entwicklungsaufwand und ohne tiefergehende Kenntnisse über das Dateiformat. Das POI-Projekt bietet zusätzlichen Funktionsumfang und ermöglicht weitgehende Eingriffe in die Dateistruktur eines Excel-Dokuments. Mit diesen beiden Werkzeugen kann ich beliebige Excel-Dateien erstellen oder Daten daraus importieren. Beide Tools haben mir in verschiedenen Projekten das Leben leicht gemacht.“ 4. Umfang der „schreiben“-Funktion 5. Umfang der „ändern“-Funktion 6. Kompatibilität mit verschiedenen Excel-Versionen 7. Performance 8. Reifegrad der Software 9. Dokumentation 10. Support Alexander Zeller, ORDIX AG, Paderborn positiv: negativ: Für performanten Nur-Lesezugriff kann jedoch auch die EventAPI verwendet werden. Diese beinhaltet als zentrale Komponenten die HSSFEventFactory und das Interface HSSFListener. Die EventFactory durchläuft das Dokument und die Implementierung des HSSFListener wird während des Parsens über jeden neu gefundenen Eintrag informiert. Die EventFactory kann dann auf die verschiedenen Einträge entsprechend reagieren und sie auslesen. Ein einfaches Beispiel hierzu finden Sie unter [5]. Fazit Der Funktionsumfang des POI-Projektes ist deutlich größer als der der JExcelAPI. Aber auch die Möglichkeiten der JExcelAPI reichen für die Erstellung einfacher Excel-Mappen und das Auslesen von Daten aus einer Excel-Datei in aller Regel aus. Letztere zeichnet sich dafür zusätzlich durch eine sehr leichte Einarbeitung und eine sehr leicht nachvollziehbare Programmstruktur aus. Aus Programmierersicht lassen sich viele Anforderungen mit der JExcelAPI einfacher realisieren. Die Handhabung des POI-Projektes wirkt an manchen Stellen etwas altbacken, so z. B. die Verwendung von short- statt intWerten, was oftmals eine Datentypumwandlung selbst von Konstanten erfordert. Müssen jedoch Meta-Informationen ausgelesen oder sehr spezifische Anforderungen umgesetzt werden, ist man mit der POI-Bibliothek sicherlich besser bedient. Um einen kleinen Eindruck in die Arbeitsweise und den Umgang mit den beiden Archiven beim Lesen bzw. Schreiben von Excel-Dateien zu erhalten, finden Sie unter [5] ein kleines Beispielprojekt zum Herunterladen. Es steht als Netbeans- und als Eclipse-Projekt zur Verfügung. Es ist in der Lage, eine einfache Excel-Datei zu erzeugen und Daten einer einfachen Excel-Datei auszulesen. Beides wird jeweils mit den beiden vorgestellten Excel-Archiven umgesetzt. Alexander Zeller ([email protected]). ORDIX News 1/2008 31 Systemmanagement Erweiterte Optionen zur Konfiguration von Server- und Diensteobjekten Nagios 3.0: Vererbungslehre für Administratoren Dieser Artikel richtet sich an Nagios-Administratoren, die einen Einblick in die Neuerungen der Version 3.0 erhalten möchten. Bei der Open Source Monitoring Software Nagios steht ein großer Versionswechsel bevor: Der aktuellen Version 2.10 folgt die Version 3.0. Auch wenn die Entwicklung einer neuen Benutzeroberfläche auf die Version 4.0 verschoben wurde, so hat sich doch „unter der Haube“ einiges getan. Viele Erweiterungen werden den Administratoren die Arbeit erleichtern. Eine Auswahl stellen wir im Folgenden vor. Wer eine Vielzahl ähnlicher Server oder Dienste mit Nagios überwacht, nutzt sie bereits: Vorlagen oder auch Templates genannt. Vorlagen fassen eine Reihe von Einstellungen zusammen, die dann an die einzelnen Serveroder Diensteobjekte vererbt werden. Bisher konnte jedes Objekt nur die Einstellun­ gen einer einzigen Vorlage erben. Diese Einschränkung wurde aufgehoben. Mit der Version 3.0 können jetzt mehrere Vorlagen angegeben werden. define host{ name check_interval check_period ... register } web-server 10 7x24 0 Abb. 1: Definition einer Vorlage für Web-Server. define host{ name check_interval notification_options event_handler ... register } entwicklungs-server 15 d,u,r handle-host-event 0 Abb. 2: Definition einer Vorlage für Entwicklungs-Server. 32 ORDIX News 1/2008 Funktionsweise von Vorlagen Eine Vorlage nutzt die gleiche Struktur wie ein Server- oder Diensteobjekt. Damit Nagios die Definition als Vorlage erkennt, wird zusätzlich die Option register 0 verwendet (siehe Abbildungen 1 und 2). Dadurch wird verhindert, dass Nagios ein Objekt mit den angegebenen Eigenschaften anlegt. Bei der Definition der Server- oder Diensteobjekte können zusätzlich zu den direkt angegebenen Optionen die in einer Vorlage definierten Optionen eingebunden werden, indem die Option use angegeben wird (siehe Abbildung 3). Dabei werden nur diejenigen Optionen aus der Vorlage übernommen, die noch nicht direkt in der Objektdefinition angegeben wurden. Anders ausgedrückt überschreiben lokale Einstellungen die Einstellungen aus der Vorlage. So wird beim Web-Server web1 der Wert der Option check_interval aus der Vorlage web-server übernommen, aber der Wert der Option check_period direkt auf Basis der Objekt-Definition – also auf den Wert 5x8 – gesetzt. Mehr als eine Vorlage In großen Umgebungen mit vielen Servern oder Diensten kommt häufig der Wunsch auf, Optionen über Vorlagen nicht nur auf Basis der Server-Art (Web-Server, Datenbank-Server), sondern zusätzlich auch noch anhand Systemmanagement anderer Kriterien (Standort, Umgebung, Betriebssystem etc.) zu vererben. Bisher musste dafür eine Vielzahl an Vorlagen geschaffen werden (Web-Server-Wiesbaden, Web-Server-Paderborn, Datenbank-ServerWiesbaden, Datenbank-Server-Paderborn, ... Web-Server-Produktion, Web-Server-Entwicklung, ...). Mit der neuen Nagios-Version 3.0 kann nun ein Objekt die Optionen von mehr als einer Vorlage erben. Die Vorlagen werden dabei als mit Kommata getrennte Liste in der Option use angegeben (siehe Abbildung 4). Auch bei der Verwendung von mehreren Vorlagen werden nur diejenigen Optionen aus einer Vorlage verwendet, die nicht schon durch die Objektdefinition selbst oder eine in der Lis­ te weiter links stehende Vorlage festgelegt wurden. Die für den Entwicklungs-Web-Server devweb1 aktiven Optionen sind in Abbildung 5 dargestellt. Die Werte der Optionen check_ interval und check_period wurden aus der Vorlage web-server übernommen, der Wert der Option notification_options aus der Vorlage entwicklungs-server. Die Reihenfolge entscheidet Werden in den verschiedenen Vorlagen die gleichen Optionen mit unterschiedlichen Werten verwendet, so entscheidet die Reihenfolge innerhalb der Option use darüber, welche Werte aktiv werden. Da eine Vorlage selbst auch auf verschiedenen Vorlagen beruhen kann, ergeben sich un­ter Umständen komplexe Strukturen. Das Beispiel in den Abbildungen 6 und 7 ist der Dokumentation von Nagios 3.0 entnommen und zeigt eine solch komplexe Struktur. Dies ist bei der Planung und Implementierung zu berücksichtigen und am besten auch zu testen, um unerwünschte Effekte zu vermeiden. Vererbung unterbinden Neu in der Version 3.0 ist auch die Möglichkeit, nicht nur die Werte der vererbten Optionen zu verändern, sondern einzelne vererbte Optionen (derzeit Optionen mit Zeichenketten-Werten wie z. B. event_handler) aus der Objektdefinition zu löschen. Dazu werden die Optionen auf den Wert null gesetzt, wie in Abbildung 4 der Wert für die Option event_handler, die so define host{ use host_name check_period ... } web-server web1 5x8 Abb. 3: Definition eines Server-Objektes für einen Web-Server. define host{ use host_name event_handler ... } web-server, entwicklungs-server devweb2 null Abb. 4: Definition eines Server-Objektes für einen Entwicklungs-Web-Server. define host{ host_name check_interval check_period notification_options ... } devweb2 10 7x24 d,u,r Abb. 5: Aktive Einstellungen für den Entwicklungs-Web-Server aus Abb 4. define host{ use host_name ... } 1, 4, 8 devweb1 Abb. 6: Definition eines Server-Objektes mit mehreren Vorlagen. 1 2 3 6 devweb1 4 5 7 8 Precedence Order (Rangfolge) Inheritance (Vererbung) Abb. 7: Darstellung der Vererbung und Rangfolge für den Server aus Abb. 6. Quelle: http://nagios.sourceforge.net/docs/3_0/objectinheritance.html ORDIX News 1/2008 33 Systemmanagement Versionsinformation Die zum Redaktionsschluss neueste verfügbare Version ist 3.0rc2, also Release Candidate 2. Das ist noch keine stabile Version und sollte auch noch nicht in ProduktionsUmgebungen eingesetzt werden. Aktuell „stable“ ist nur die alte Version 2.10. Sowohl die stabile Version 2.10 als auch die aktuelle Version 3.0rc2 können auf der Nagios Webseite [1] heruntergeladen werden. Links ► [1] Nagios Webseite: http://www.nagios.org ► Seminarempfehlung: Systemüberwachung mit Nagios: http://training.ordix.de/seminar.php?nr=648 nicht mehr aus der Vorlage entwicklungsserver übernommen wird (zum Ergebnis der Einstellung siehe Abbildung 5). Fazit Die neue Version 3.0 bietet gerade in großen Nagios-Umgebungen Vorteile bei der jetzt viel flexibleren Verwendung von Vorlagen. Allerdings ist dennoch ein gut durchdachtes Konfigurationskonzept Basis für die Verwendung von Vorlagen, um unerwünschte Effekte zu vermeiden. Bei der Erstellung oder Anpassung dieser Konzepte unterstützen wir Sie gerne. Andreas Jordan ([email protected]). Larry Ratlos: Verflixte PHP 5 Arrays Jetzt ist Larry schon 5 Jahre bei ORDIX. Und seine Aufgaben sind so vielfältig, dass er trotzdem immer wieder vor neuen Problemen steht ... Larry hat vor einiger Zeit den ORDIX PHP 5 Kurs besucht und ist begeistert: Die Inhalte wurden sehr verständlich vermittelt. Aber jetzt, da er wieder in seinem Büro sitzt, versteht er die Welt nicht mehr. Er geht nochmal alle Themen durch und bleibt beim “Iterieren von Arrays unter PHP 5” hängen. Er versucht, sein eigenes Array auf verschiedene Weise zu durchlaufen, wozu er folgenden Code benutzt: <?php $arr=array("Larry","ist","ratlos"); foreach ($arr as &$wert) { } foreach ($arr as $wert) { } print_r($arr); ?> Nun ist er total verwundert über die Ausgabe des Aufrufs print_r(), die da lautet: Array ( [0] => Larry [1] => ist [2] => ist ) Warum ist denn nun das letzte Element ein „ist“ und nicht „ratlos“? Er hatte doch gelernt, dass man mit einem foreach($arr as $wert)Konstrukt ein Array Element für Element durch- 34 ORDIX News 1/2008 laufen kann und das Array beim Durchlaufen mit foreach($arr as &$wert) sogar direkt beim Durchlaufen verändern kann. Aber er ändert doch gar nichts an dem Array ... Können Sie Larrys Code möglichst einfach kor­ rigieren, so dass er das erwartete Ergebnis liefert? Dann senden Sie Ihre Lösung bitte bis zum 18. April 2008 an [email protected]. Lösung der Aufgabe aus 4/2007 Larry hatte kurz vor Weihnachten das Problem, dass er einem Kollegen, dessen Name aber unbekannt war, ein Paket überbringen lassen sollte. Er hat es nach einigem Knobeln dem Paderborner Kollegen mitgegeben, der es dann dem Java-Referenten übergeben hat. Viele Leser haben herausgefunden, dass das Paket nach Paderborn muss. Der schnellste war Herr Heimburger vom Statistischen Landesamt Sachsen, der sich daraufhin selbst über ein kleines Paket freuen durfte. Betriebssysteme I/O-Multipathing mit Linux-Bordmitteln: Viele Wege führen zur LUN Bereits seit der Linux-Kernelversion 2.6.12, also seit Juni 2005, besteht die Möglichkeit, Storage-Systeme mit Hilfe des Device Mappers Multipathing-I/O (DM-MPIO) über re­dundante, physikalische Pfade anzubinden. Vorher war dies nur mit kommerzieller Software (z. B. EMC PowerPath) möglich. Aufgrund fehlender Unterstützung der Hersteller werden allerdings nachwievor meist proprietäre Software-Lösungen verwendet. Seit einiger Zeit zertifizieren jedoch auch die großen Hersteller von Storage-Systemen den Einsatz der frei verfügbaren I/O-Multipathing-Lösung. Nachdem EMC bereits im Dieser Artikel richtet sich an Systemadministratoren, die einfach und kostengünstig Speicherbereiche aus dem SAN redundant an ihre LinuxSysteme anbinden möchten oder nach einer Alternative zu kostenpflichtigen Lösungen suchen. Jahr 2006 die Nutzung in Single-Server-Umgebungen freigegeben hat, wird seit Ende 2007 auch der Einsatz in Cluster-Umgebungen (z. B. mit OCFS) unterstützt. Dies möchten wir zum Anlass nehmen, Ihnen die wichtigsten Konzepte und Komponenten dieser frei verfügbaren Multipathing-Lösung einmal in kompakter Form vorzustellen. Wie funktioniert I/O-Multipathing? Der Device Mapper als Basis Wie der Name bereits sagt: Voraussetzung für I/O-Multipathing sind mehrere physikalische Pfade, die zu einem Storage Device führen. Fällt einer dieser Pfade aus, werden Schreibund Leseoperationen (I/O) über die verbliebenen Pfade ausgeführt. Zur Verbesserung der Performance können die Operationen zudem bei Bedarf auch im Normalbetrieb auf unterschiedliche Pfade verteilt werden. Der Device Mapper ist seit der Kernel-Version 2.6 eine zentrale Komponente des Storage Management auf Linux-Systemen. Mit seiner Hilfe werden virtuelle Block-Devices erstellt, deren Blöcke mittels Zuordnungstabellen, so genannten „maps“, auf beliebige existierende Block-Devices verteilt werden können. Die Art und Weise, wie die Blöcke verteilt werden, ist dabei flexibel (z. B. linear oder als Spiegel) und ORDIX News 1/2008 35 Betriebssysteme wird durch „targets“ definiert. Das Logical Volume Management basiert beispielsweise seit der Version 2 auf dem Device Mapper. Pfad 1 Anwendung /dev/mapper/oracle_mp /dev/sda HBA1 /dev/sdb HBA2 SP1 DeviceMapper SP2 LUN Pfad 2 Linux Server Storage Abb. 1: Device Mapper Multipathing-I/O im Überblick. # /sbin/scsi_id -g -u -s /block/sdc 360070590000280101094433030303439 # /sbin/scsi_id -g -u -s /block/sde 360070590000280101094433030303439 Abb. 2: Ermittlung einer eindeutigen ID mit scsi_id. Mit der Kernel-Version 2.6.12 wurde der Device Mapper um das Target „multipath“ erwei­ tert und bildet damit das Fundament des I/OMultipathing. Mit seiner Hilfe wird ein virtuelles Device generiert, hinter dem sich die verschiedenen Pfade zum eigentlichen Gerät verbergen. Die Aufgabe des Device Mappers ist so­wohl die Verteilung der Schreib- und Lese­ope­ra­ tionen als auch die Erkennung defekter Pfade und die entsprechende Umlenkung der Operationen auf die verbliebenen Pfade. Einen Überblick über den DM-MPIO gibt Abbildung 1. multipath configuration tool Um ein Multipathing Device anzulegen, sind folgende Schritte notwendig: # multipath –ll oracle_mp (360070590000280101094433030303439) dm-0 EMC,SYMMETRIX [size=100G][features=0][hwhandler=0] \_ round-robin 0 [prio=2][active] \_ 1:0:0:0 sdc 8:32 [active][ready] \_ 2:0:0:0 sde 8:64 [active][ready] Abb. 3: Anzeige der aktuellen Konfiguration mit dem Multipath Tool. # Welche Devices nicht pruefen? (z.B. nicht /dev/sda und /dev/sdb) blacklist { devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*" devnode "^hd[a-z][[0-9]*]" devnode "^sd[ab][0-9]*" } # Multipaths konfigurieren multipaths { multipath { wwid "360070590000280101094433030303439" alias "oracle_mp" path_grouping_policy multibus } } Abb. 4: Auszug aus der Konfigurationsdatei /etc/multipath.conf. • Suche nach Geräten mit identischer ID, aber unterschiedlichen Pfaden • Erstellung einer Map für den Device Mapper • Anlegen des Multipathing Devices mit dieser Map Die Schritte können prinzipiell auch manuell durchgeführt werden. In der Praxis werden sie allerdings vom Multipath Tool übernommen. Dieses kann automatisch bei der Erkennung neuer Block-Devices durch das Hotplug-Subsystem aufgerufen oder bei Bedarf auch manu­ ell ausgeführt werden. Das Werkzeug ermittelt mit Hilfe des Kommandos scsi_id über ein SCSI-Inquiry eine eindeutige Bezeichnung, die Worldwide-ID (WWID) eines SCSI-Devi­ ces, z. B. für /dev/sdc und /dev/sde (siehe Abbildung 2). Weisen mehrere SCSI-Devices die gleiche WWID auf, so wird davon ausgegangen, dass es sich um redundante Pfade zu demselben Gerät handelt und ein entsprechendes Multipath Device wird erzeugt (siehe Abbildung 3). Konfiguration # multipathd -k multipathd> list paths hcil dev dev_t pri dm_st chk_st next_check 1:0:0:0 sdc 8:32 1 [active][ready] XXXXXX.... 12/20 2:0:0:0 sde 8:64 1 [active][ready] XXXXXX.... 12/20 Abb. 5: Der interaktive Modus des Multipath-Dämons. 36 ORDIX News 1/2008 Die Konfiguration des Multipath Tools erfolgt in der Datei /etc/multipath.conf. In ihr wird unter anderem definiert, welche Devices wie auf redundante Pfade zu prüfen sind und welches Multipathing-Verfahren genutzt werden soll. Zudem können sprechende Namen für die zu erstellenden Multipathing Devices konfiguriert werden (siehe Abbildung 4). Betriebssysteme kpartx Glossar Das Multipath Tool legt lediglich Maps für komplette Block-Devices an. Sind diese jedoch partitioniert, wird für jede Partition eine separate Map benötigt. Diese Aufgabe übernimmt das Tool „kpartx“. Es untersucht ein gegebenes Meta-Device auf Partitionen und legt bei Bedarf entsprechend zusätzliche Meta-Devices an. Standardmäßig wird zu diesem Zweck die Endung -part<nr> an den Namen des Basis-Devices angehängt. D. h. die erste Partition des Multipath Devices /dev/mapper/ oracle_mp ist über den Pfad /dev/mapper/oracle_mp-part1 erreichbar usw. Der Multipath-Dämon Die Aufgabe des Multipath-Dämons multipathd ist die dynamische Rekonfiguration der Multipathing Devices bei Ausfall und Res­ taurierung von Pfaden. Des Weiteren liefert multipathd eine Kommandozeilenschnittstelle, die es dem Administrator ermöglicht, die aktuelle Konfiguration abzurufen bzw. zu verändern (siehe Abbildung 5). I/O-Multipathing Zugriff auf Blockgeräte über mehrere physikalische Pfade zur Steigerung von Verfügbarkeit und Performance. DM-MPIO Device Mapper Multipathing-I/O. DM-MPIO ist die native I/O-Multipathing-Lösung auf Linux-Systemen seit Kernel 2.6.12. LUN Logical Unit Number. LUN ist die Zuordnungsnummer für Geräte an einem SCSI-Bus (z. B. für virtuelle Festplatten eines Disk Arrays). SAN Storage Area Network. SAN ist ein Netzwerk zur Anbindung von Speicherressourcen an Serversysteme. OCFS Oracle Cluster Filesystem. Das OCFS ist ein frei verfügbares Cluster Filesystem von Oracle. WWID World Wide ID. WWID ist eine weltweit eindeutige Bezeichnung, z. B. als Adresse eines Gerätes im SAN. Fazit Das DM-MPIO stellt nicht nur eine kostenlose, sondern vor allem eine offene und sehr klar struk­ turierte Multipathing-Lösung für Linux-Sys­teme dar. Die zunehmende Unterstützung durch große Storage-Anbieter legt nahe, dass DM-MPIO in Zukunft vermehrt als Alternative zu traditionel­ ler Multipathing Software eingesetzt wird. Christof Amelunxen ([email protected]). Impressum Herausgeber: ORDIX AG Aktiengesellschaft für Software­ent­wick­lung, Beratung, Schulung und Systemintegration, Paderborn Redaktion: Helma Jenniches, Sascia Brinkmann V.i.S.d.P.: Benedikt Georgi, Wolfgang Kögler Anschrift der Redaktion: ORDIX AG Westernmauer 12 - 16 33098 Paderborn Tel.: 05251 1063-0 Fax: 0180 1673490 Gestaltung/Layout: Sascia Brinkmann Auflage: 9.300 Druck: Druckerei Reike GmbH, Paderborn Bildnachweis: pixelio.de © Nicole80; pixelio.de © hofschlaeger; pixelio.de © Multipla; pixelio.de © DominoXL; photocase.de © nild; photocase © Christian Kudler Autoren dieser Ausgabe: Christof Amelunxen, Dr. Hubert Austermeier, Holger Demuth, Christian Fertsch, Dirk Hansmeier, Andreas Jordan, Wolfgang Kögler, Lars Hendrik Korte, Rainer Restat, Thorsten Schuhmacher, Frank Späth, Manfred Stöb, Christian Wiesing, Alexander Zeller Copyright: ORDIX AG. Alle Rechte, auch die der Übersetzung, des Nachdrucks und der Vervielfältigung der Artikel oder von Teilen daraus, bleiben uns vorbehalten. Kein Teil der Artikel darf ohne unsere schriftliche Genehmigung in irgendeiner Form reproduziert, insbesondere unter Verwendung elektronischer Systeme verarbeitet, verbreitet, vervielfältigt oder zu öffentlichen Wiedergaben benutzt werden. Haftung: Eine Haftung für die Richtigkeit der Veröffentlichungen kann trotz sorgfältiger Prüfung durch die Redaktion vom Herausgeber nicht übernommen werden. Warenzeichen: Einige der aufgeführten Bezeichnungen sind eingetragene Warenzeichen ihrer jeweiligen Inhaber. Die Zeitschrift ORDIX News wird von der ORDIX AG an ausgesuchte Kunden verteilt und kann für 2,20 Euro bestellt werden. Sie finden sowohl die neueste Ausgabe als auch ältere Ausgaben im Archiv der ORDIX News im Internet unter: http://www.ordix.de. Schauen Sie mal rein! Der Kontakt zu unseren Lesern ist uns sehr wichtig. Für An­re­gungen, Kritik und Anmerkungen zu den Themen, aber auch für interessante Ideen sind wir immer offen und dankbar. Wir freuen uns auf Ihr Feedback an [email protected]. ORDIX News 1/2008 37 Projektmanagement IT-Projektmanagement: Aller Anfang ist schwer Dieser Artikel richtet sich an Projekt- und IT-Manager. Ein IT-Projekt zu beginnen, erscheint auf den ersten Blick einfach. Am Anfang steht eine Vorgabe oder eine Idee - sei es aufgrund einer gesetzlichen Vorschrift, einer strategischen Entscheidung oder einer technischen Notwendigkeit. Ein Team wird gebildet und ein Projektleiter ernannt. Projektstart! Aber ist das tatsächlich der Projektstart? Wann und wie startet ein Projekt wirklich? Was ist für einen erfolgreichen Projektstart notwendig? Im vorliegenden Artikel erörtern wir die wesentlichen Aspekte der ersten Phase eines Projektes, die Projektdefinition oder auch Projektinitialisierung genannt wird. „Sage mir, wie dein Projekt beginnt und ich sage Dir, wie es endet.“ Dieses Zitat bringt es auf den Punkt. Was oft als Projekt bezeichnet wird, ist in den meisten Fällen nur die Realisierungsphase eines Projektes. Wirklich entscheidend für den Erfolg eines Projektes ist jedoch die Projektdefinition. Man spricht in diesem Kontext auch von „formaler Autorisierung“ des Projektes. Wie ordnet sich die Projektdefinition als Phase in den gesamten Ablauf? Welches sind die Voraussetzungen für eine Projektdefinition und was ist das Ergebnis dieser Phase? Die Phasen eines Projektes Phasenmodelle bilden die Grundlage dafür, IT-Projekte so zu strukturieren, dass der gesamte Ablauf beherrschbar bleibt. Zwar haben sich in der Vergangenheit unterschiedliche Varianten entwickelt, die sich im Detail unterscheiden, allen gemeinsam ist jedoch die generelle Trennung zwischen Projektdefinition, Planung, Durchführung und Abnahme (siehe Abbildung 1). Während der Abwicklung von IT-Projekten sind eine Reihe wichtiger Aufgaben zu erledigen. Dies sind neben Konzeption und Entwicklung der Lösung vor allem Aufgaben in den Bereichen Anforderungsmanagement, Planung, Kommunikation und Projekt-Controlling. In der 38 ORDIX News 1/2008 Initialisierungsphase des Projektes müssen da­ für die Weichen gestellt werden. Wo beginnt der Weg zum Ziel? Welches sind die Voraussetzungen für eine Projektdefinition und was ist das Ergebnis dieser Phase? Die Projektdefinitionsphase beginnt mit der Idee und liefert als Ergebnis eine Entscheidungsvorlage, meist in Form des Projektantrags. Die eigentliche Projektdurchführung beginnt mit dem Kick-Off. Der richtige Werkzeugsatz IT-Projekte unterscheiden sich zum Teil erheblich voneinander, sodass man nicht mit einer „Standardmethode“ zum Ziel kommt. Das gilt vor allem auch für die Projektdefinition. Ein Projekt „richtig aufzusetzen“ hängt vom Ergebnis verschiedener Fragestellungen ab: • • • • • Was sind die wesentlichen Projekt­ziele? Wie umfangreich wird das Projekt? Um welchen Projekttyp (Software-Entwick­ lung, Migration, IT-Infrastruktur) handelt es sich? Welche Restriktionen/Risiken gibt es? Welche Rahmenbedingungen existieren? Es sind demnach zunächst die richtigen Voraussetzungen zu schaffen, damit ein Projekt erfolgreich sein kann. Viele Aspekte einer sol- Projektmanagement chen Projektdefinition findet man beispielsweise in einer Ausschreibung. Eine weitere, sinnvolle Variante ist die Anfertigung einer Studie, die je nach Größenordnung durchaus als eigenständiges Projekt gestaltet werden kann. Dabei stehen jedoch meist die technische Machbarkeit und die inhaltlichen Anforderungen im Vordergrund, während andere Aspekte, wie Organisation, Kennzahlen, Berichte und Dokumentationsstrukturen außen vor bleiben. Da während der Projektinitialisierung die Weichen für die späteren Phasen gestellt werden, müssen zu Beginn folgende Bereiche geklärt werden: • • • • • • Ziele und Inhalte Planung und Steuerung Beteiligte und Rollen Kommunikation Technologie Risiken und Qualität Mit Hilfe der folgenden Checklisten kann ein Projektleiter zu Beginn seines Projektes Vollständigkeitsprüfungen vornehmen oder bewusst auf Handlungsbedarf hinweisen. Dabei müssen in dieser Phase nicht alle genannten Punkte behandelt werden, sondern es müssen die Grundlagen für die Erreichung der Projektziele geschaffen werden. Umgekehrt erheben die Listen keinen Anspruch auf Vollständigkeit. Ziele und Inhalte Idee/Vorgabe Projektdefinition Strukturierung/ Planung Projektantrag Kick-Off Planung und Steuerung Projektplanung und effektives Projekt-Control­ ling sind für ein erfolgreiches Projekt unverzichtbar. Die folgenden, notwendigen Voraus­ set­zun­­gen sind hierfür zu schaffen: □ Es existiert eine Planbasis. □ Der Terminrahmen ist vorgegeben. □ Finanzielle Rahmenbedingungen sind bekannt. □ Was geplant werden muss, ist definiert. □ Wichtige Meilensteine sind festgelegt. □ Realistische Schätzungen liegen vor. □ Erste Kennzahlen für ein effektives Projekt-Controlling liegen vor. □ Es herrscht Klarheit über erforderliche Arbeitspakete zur Messung des Fertigstellungsgrads. □ Berichtswesen (Art und Umfang) ist defi- □ Anforderungen und Rahmenbedingungen Beteiligte und Rollen □ Auftraggeber und Auftragnehmer sind ein- Die Benennung der Personen und die Festlegung von Verantwortlichkeiten sind ein wesentlicher Erfolgsfaktor. Dazu gehört insbesondere die klare Definition und Zuordnung der Rollen im Projekt. deutig festgelegt. □ Über die Projektziele (und Nicht-Ziele) herrscht Klarheit und Einigkeit zwischen den Beteiligten. niert und kommuniziert. □ Spielräume und -regeln für Änderungen/ Erweiterungen sind festgelegt (ChangeManagement). □ Die Nutzen- bzw. die Wirtschaftlichkeitsbe- □ Die Projektorganisation ist definiert, die we- □ Qualitätsziele sind definiert. □ Das Team ist adäquat für das Projekt be- trachtung liegt vor. □ Die formalen Voraussetzungen für den Start sind erfüllt (meist Projektantrag). □ Alle Ziele und Inhalte sind kommuniziert. □ Das Kick-Off ist geplant, die Agenda liegt vor. Überprüfung/ Abnahme Abb. 1: Typischer Projektablauf. Eine klare Formulierung und Dokumentation der Ziele ist gemeinsam mit dem Auftraggeber des Projekts zu erstellen. Dabei können folgende Punkte als Leitlinie helfen. Die Ergebnisse sollten im Rahmen eines Kick-Offs öffentlich vorgestellt werden. sind definiert. Realisierung/ Durchführung sentlichen Positionen sind besetzt. setzt. □ Es gibt genügend Personal und es ist ausreichend qualifiziert. □ Rollen im Projekt sind ausreichend definiert und verteilt. ORDIX News 1/2008 39 Projektmanagement □ Der Nutzen für die Projektmitarbeiter ist dargestellt. □ Es ist ausreichend Projektmanagementund Führungserfahrung vorhanden. □ Die Kompetenzen des Projektleiters sind ausreichend. □ Die Eskalationswege sind definiert und kommuniziert. Kommunikation Kommunikation im Projekt ist ein immer wieder unterschätztes Thema. Dabei geht es weniger um eine hohe Anzahl an Meetings, sondern vielmehr um einen effektiven Informationsfluss zwischen allen Beteiligten. Projektmanagement ist auch Kommunikationsmanagement (siehe auch ORDIX News 2/2007 [1]): □ Es existiert ein Kommunikationskonzept (Art und Weise, wie mit Projektbeteiligten kommuniziert wird). □ Dokumentationsrichtlinien sind definiert. □ Alle vom Projekt direkt oder indirekt Betroffenen sind über die Ziele und den geplanten Ablauf informiert. □ Alle relevanten Interessensvertreter (z. B. Auftraggeber, Projektmitarbeiter, zukünftige Anwender, Betriebsrat etc.) sind bekannt, informiert und eingebunden. □ Die erste Planung (Schätzung) wurde abgestimmt. □ Grundlagen für ein Berichtswesen (Art und Umfang) sind geschaffen. Technologie Während der Projektdefinition stellt sich nicht nur die Frage nach den einzusetzenden Technologien, die in der Realisierung Anwendung finden, sondern vor allem nach Architekturvorgaben, Richtlinien und Vorgehensmodellen. In diesem Kontext sind auch Festlegungen be- Links ► ORDIX News Artikel „Kommunikation im Projektmanagement: ... und Reden ist Gold“: http://www.ordix.de/ORDIXNews/2_2007/Projektmanagement/kommunikation_ projektmanagement.html ► Seminarempfehlungen: ► Projektdefinition und -planung: http://training.ordix.de/seminar.php?nr=661 ► Projekte steuern und überwachen: http://training.ordix.de/seminar.php?nr=664 40 ORDIX News 1/2008 züglich Versions- und Konfigurationsmanagement zu treffen. Vor allem beim Einsatz neuer, bisher unbekannter Technologien ist sicherzustellen, dass ausreichendes Know-how verfügbar ist. □ Entwicklungsrichtlinien und Vorgehensmo­ delle sind berücksichtigt und sind verbind­ lich. □ Technologische Abhängigkeiten und Architekturvorgaben sind berücksichtigt. □ Die Tool-Umgebung ist verbindlich festgelegt. Risiken und Qualität Qualität ist planbar, wenn wesentliche Qualitätsziele frühzeitig festgelegt werden. Eine laufende Qualitätssicherung ist erst möglich, wenn im Vorfeld überprüfbare Kriterien definiert wurden. Dies gilt vor allem für das Testen, da Testfälle unmittelbar aus der Anforderungsdefinition abgeleitet werden. Gleiches gilt für mögliche Risiken. Sofern frühzeitig potenzielle Risiken beachtet werden, kann deren Eintrittswahrscheinlichkeit in den späteren Projektphasen besser beurteilt werden bzw. Risiken können in der Realisierung und Implementierung vermieden werden. Außerdem kann man deutlich effektiver reagieren, falls ein Risikofall tatsächlich eintritt. Erreichte Qualitätsziele und vermiedene Ri­ siken sind zusätzliche, aussagekräftige Kennzahlen des Projekt-Controllings und lassen neben dem Fertigstellungsgrad eine genauere und objektivere Beurteilung des Projektfortschritts zu. Fazit Je höher die Qualität der Initialisierung eines IT-Projektes, desto größer ist die Wahrscheinlichkeit, dass dieses Projekt erfolgreich im Sinne technischer, zeitlicher und monetärer Vorgaben abgeschlossen wird. Ein Projekt beginnt nicht mit einem Beschluss oder einer Idee. Ein Projekt beginnt dann, wenn es eine solide Basis für eine Entscheidung zur Durchführung gibt. Diese Entscheidung stützt sich auf Ergebnisse der Projektinitialisierung. Die Projektinitialisierung sollte immer von dem Projektleiter durchgeführt werden, der auch für die folgenden Phasen verantwortlich ist. Ansonsten wird es nicht gut enden ... Rainer Restat ([email protected]). Datenbanken Reihe Oracle Objekttypen von A - Z (Teil VI): Jobs und Libraries Im sechsten Teil der Reihe Objekttypen fahren wir mit „J“ wie Job fort. Dazu erläutern wir weitere Job-bezogene Objekttypen außerhalb der alphabetischen Reihenfolge. Anschließend geht es mit „L“ und dem Objekttyp Library und dessen Verwendung als Brücke zwischen PL/SQL und den Betriebssystemfunktionen weiter. Der DBMS_SCHEDULER Der Objekttyp Job und sieben weitere Objekttypen sind im Zusammenhang mit der Job-Verwaltung und dem Paket DBMS_SCHEDULER in Oracle 10g eingeführt worden. Ein Job kombiniert die Metadaten eines Programms mit einer Zeitdefinition. Sowohl das Datum der Ausführung als auch die damit verbundene Aktion kann direkt im Job oder auch indirekt über ein Schedule bzw. Programm erfolgen. Neben den Basiskomponenten des Pakets DBMS_SCHEDULER existieren weitere, optionale Komponenten. Den Schedule erweitert ein Zeitfenster (Window) um eine Laufzeit und eine optionale Verknüpfung mit einem Ressourcenplan. Mit einem Window Group lassen sich mehrere Zeitfenster zusammenfassen. Jobs können in Klassen gruppiert werden. Jobklassen sind die Verbindung zum Resource Manager der Datenbank. Mittels der Konsumentengruppen können Ressourcenzusagen für die jeweiligen Jobklassen gegeben werden. Oracle erstellt automatisch eine Jobklasse mit dem Namen AUTO_TASKS_JOB_CLASS und eine Konsumentengruppe mit dem Namen AUTO_TASKS_CONSUMER_GROUP. Die automatisch angelegten Komponenten werden von Oracle zur Aktualisierung der Tabellenstatistiken genutzt. Aus einer Abfolge von Programmen lassen sich zudem Ablaufketten (Chain) definieren. Ein Job kann eine solche Abfolge von Programmen anstoßen. Alle zuvor genannten Scheduler-Komponenten sind mit einem gleichnamigen Objekttyp Dieser Artikel wendet sich an Datenbankadministratoren und -entwickler, die einen Überblick über die Objekttypen von Oracle bekommen möchten. verbunden. In Abbildung 1 sind sämtliche Objekttypen, die im Zusammenhang mit der Jobverwaltung stehen, aufgeführt. Eine ausführliche Betrachtung des Themas DBMS_SCHEDULER finden Sie in der ORDIX News 1/2005 [1]. Beispiele Eine Job-Definition besteht, wie das Beispiel in der Abbildung 2 zeigt, mindestens aus einem Job, der Ausführungszeit, hier eine Referenz auf ein Schedule („Schedule1“), und einer Referenz auf ein auszuführendes Programm Scheduler Element JOB Object Typ JOB Beschreibung Kombination aus PROGRAM und WINDOW Objekt JOB CLASS JOB CLASS Gruppierung von Jobs zur Ressourcenzuordnung SCHEDULE SCHEDULE Zeitplan der Job-Ausführung PROGRAM PROGRAM Beschreibung der auszuführenden Aktion WINDOW WINDOW Zeitfenster für die Job-Ausführung WINDOW GROUP WINDOW GROUP Zusammenfassung mehrerer Zeitfenster CHAIN CHAIN Jobkette, Liste chronologisch ablaufender Jobs CREDENTIAL CREDENTIAL Berechtigung eines Jobs AGENT_REGISTRATION_ UNDEFINED Passwort zur Anmeldung des AgenPASSWORD ten zur Remote Job-Ausführung Abb. 1: Objekttypen im Scheduler-Umfeld. ORDIX News 1/2008 41 Datenbanken BEGIN SYS.DBMS_SCHEDULER.CREATE_JOB ( job_name => 'Jobtest1' ,schedule_name => 'Schedule1' ,program_name => 'Program1' ,job_class => 'ORDIX_JOB_CLASS' ); SYS.DBMS_SCHEDULER.ENABLE ( NAME => 'DH.Jobtest'); END; / Abb. 2: Beispiel für eine Job-Definition. SYS.DBMS_SCHEDULER.CREATE_JOB_CLASS ( job_class_name =>'ORDIX_JOB_CLASS' ,resource_consumer_group =>'LOW_GROUP' ,service =>NULL ,logging_level =>SYS.DBMS_SCHEDULER.LOGGING_FULL ,log_history =>30 ,comments =>NULL ); Abb. 3: Beispiel für eine Job-Class-Definition. CREATE OR REPLACE FUNCTION W2KWRAPP ( lpCmdLine IN VARCHAR2, uCmdShow IN PLS_INTEGER := 1 ) RETURN PLS_INTEGER IS EXTERNAL LIBRARY kernel32 NAME "WinExec" LANGUAGE C CALLING STANDARD PASCAL PARAMETERS ( lpCmdLine STRING, uCmdShow LONG, RETURN LONG ); / Abb. 4: Beispiel für die Definition einer Wrapper Funktion mit Zugriff auf ein dynamisches Library-Objekt. SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (SID_NAME = PLSExtProc) (ORACLE_HOME = C:\oracle\product\10.2.0\db_1) (PROGRAM = extproc) (ENVS = "EXTPROC_DLLS=ANY") ) ) Abb. 5: Beispiel für eine Listener.ora Konfiguration. 42 ORDIX News 1/2008 („Program1“). Ein Beispiel für die Definition eines Job Class Objektes ist in Abbildung 3 aufgelistet. Ausnahmen Folgende Scheduler-Komponenten erzeugen keine Objekte im Sinne von DBA_OBJECTS: • • • • • • • • • ANYDATA_ARGUMENT CHAIN_EVENT_STEP CHAIN_RULE CHAIN_STEP RUNNING_CHAINS METADATA_ARGUMENT PROGRAM_ARGUMENT GLOBAL_ATTRIBUTES JOB_LOG Bei der Scheduler-Komponente mit dem Namen AGENT_REGISTRATION_PASSWORD handelt es sich um ein Objekt im Sinne von DBA_OBJECTS, dessen Objekttyp aber nicht namentlich in der View DBA_OBJECTS definiert ist, sondern als Objekttyp UNDEFINED aufgeführt wird. Es handelt sich hierbei um das Passwort zur Anmeldung des Agenten zur Remote-Jobausführung, welcher mit der Version 11g eingeführt wird. Library Objekte Eine Library ist eine Sammlung von Funktionen, die über eine Schnittstelle der PL/SQLEngine zur Verfügung gestellt wird. Libraries können statisch oder dynamisch eingebunden werden. Eine statische Library liegt in Form von C-Byte Code in der Datenbank vor. Ein statisches Library-Objekt wird wie folgt definiert: CREATE OR REPLACE LIBRARY ORDIX_LIB TRUSTED AS STATIC Eine dynamische Library ist ein mit einer Datei verknüpftes Schemaobjekt. Über ein dynamisches Library-Objekt wird aus PL/SQL heraus auf externe Funktionen zugegriffen, die in einer externen Library-Datei implementiert sind. Seit Oracle 8 stehen diese Aufrufe (Callouts) aus PL/SQL heraus zur Verfügung. Eine typische Anwendung ist der Zugriff auf eine betriebssystemnahe Funktion. Diese liegt Datenbanken in der Form von Shared-Library-Dateien vor. Das folgende Beispiel erstellt ein LibraryObjekt auf die Betriebssystem-Shared-Li­bra­ ry-Datei „Kernel32.dll“ unter Windows, die sich im System32-Verzeichnis befindet. CREATE OR REPLACE LIBRARY kernel32 as 'C:\windows\system32\kernel32.dll'; Der Status VALID des Objektes in der View User_libraries besagt nicht unbedingt, dass die angegebene Datei im lokalen Filesystem tatsächlich existiert. Ein Library-Objekt kann natürlich auch auf einen Remote-Rechner verweisen. Sollte sich die Library-Datei nicht im angegebenen Pfad befinden, kommt es erst bei der Ausführung der Funktion zu einem Fehler: ORA-06520: PL/SQL: Fehler beim Laden der externen Bibliothek. Die Library kommt zum Einsatz Um eine externe Funktion aufrufen zu können, muss die aufrufende PL/SQL-Prozedur (siehe Abbildung 4) wissen, in welcher Datei sich diese Funktion befindet. Dazu wird in der Alias Library nach dem Dateinamen gesucht und anschließend via SQL-NET der Listener kontaktiert. Dieser startet den Oracle Agent EXTPROC-Prozess. Hierfür wird ein Eintrag, wie in den Abbildungen 5 und 6 gezeigt, in der Listener.ora und der Tnsnames.ora benötigt. Von nun an kommunizieren der EXTPROCProzess und die PL/SQL-Engine direkt miteinander. Der Prozess EXTPROC besteht für die Dauer der aufrufenden Session. Nach Beendigung der Session wird auch EXTPROC beendet. Für jede Session, die externe Funktionen verwendet, startet ein eigener EXTPROC-Prozess. Die PL/SQL-Engine übergibt den Namen der Shared Library-Datei an den EXTPROCProzess mit Hilfe des Library-Objektes und der PL/SQL Wrapper Function. Dieser bringt die Shared-Library-Funktion zur Ausführung und übergibt das Resultat der PL/SQL-Engine. Die erfolgreiche Ausführung der externen Funktion kann über den Rückgabewert (siehe Abbildung 7) kontrolliert werden. Ausblick In einer der nächsten ORDIX News setzen wir die Artikelreihe dann wieder alphabetisch fort. Dirk Hansmeier ([email protected]). EXTPROC_CONNECTION_DATA = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0)) ) (CONNECT_DATA = (SID = PLSExtProc) (PRESENTATION = RO) ) ) Abb. 6: Beispiel für eine Tnsnames.ora Konfiguration. SET SERVEROUTPUT ON DECLARE v_ret NUMBER; BEGIN v_ret := W2KWRAPP ('cmd /q /c mkdir c:\temp\test'); DBMS_OUTPUT.PUT_LINE ('1st command: v_ret=' || v_ret); END; / Abb. 7: Beispiel für den Aufruf einer Wrapper Funktion mit Zugriff auf ein dynamisches Library-Objekt. Referenzen Oracle Doku aus MetaLink: https://metalink.oracle.com (Zugriff nur für registrierte User) ► Note: 70678.1 PL/SQL Example: Bitwise Operations using External Procedures ► Note: 68061.1 Creating External Procedures on Windows NT ► Note: 99136.1 Calling Operating System Commands from PL/SQL using External Procedures Link ► [1] ORDIX News 1/2005, Artikel „Jobsteuerung mit dbms_scheduler“: http://www.ordix.de/ORDIXNews/1_2005/oracle_10g_jobsteuerung.html Glossar dbms_scheduler Oracle Komponenten zur Planung und Steuerung von daten­ bankabhängigen Aktionen, bestehend aus einer PL/SQLSchnitt­stelle, zugehörigen Hintergrundprozessen und einer Reihe von Data Dictionary Views. Resource Manager Tool zur Verwaltung von Ressourcen, wie CPU-Zeit, maximale Anzahl Sessions, Parallelitätsgrad etc. für Benutzergruppen in einem bestimmten Zeitraum. Resource Consumer Eine Gruppe von Oracle Benutzern mit gleicher Anforderung Group an die benötigten Ressourcen. Ressourcenplan Beschreibt die periodenabhängige Zuordnung von Ressourcen zu einer Resource Consumer Group. EXTPROC Eigenständiger Prozess auf Betriebssystemebene, der Library Dateien dynamisch einbindet, die entsprechenden Funktionen aufruft und deren Rückgabewerte an Oracle zurückgibt. Callouts Aufrufe von externen Funktionen, die in einer anderen Program­ miersprache implementiert sind, als die aufrufende Funktion. ORDIX News 1/2008 43 Datenbanken Tacho, der 560 km/h anzeigt aufgemotztes Auto IBM Informix Dynamic Server Version 11 (Teil II): Dynamisches Ressourcen Tuning Dieser Artikel richtet sich an Datenbank- und System­ administratoren, Entwickler und Entscheider im Datenbankumfeld. In der ORDIX News 3/2007 [1] stellten wir den neuen Informix Dynamic Server (IDS) Version 11 vor und gaben einen ersten Überblick über Neuerungen im neuen OLTPDatenbank-Flagschiff der IBM. Seit Mitte Juni 2007 ist nun der Informix Dynamic Server Version 11.10.(FU)C1 auf dem Markt erhältlich. Sehr viele neue Funktionen wurden in diese Version integriert. In diesem Teil der Reihe beleuchten wir das Thema „Dynamisches Ressourcen Tuning“. RTO-Policy Mit der IDS Version 11 kann sich der Datenbankadministrator das Leben etwas vereinfachen, z. B. mit der so genannten RTO-Policy. RTO steht für Recovery Time Objective und bedeutet soviel wie eine Vereinbarung einer Zielvorgabe für eine garantierte Wiederanlaufzeit (Recovery-Phase) nach einem Datenbankserverausfall. Die RTO-Policy wird über den neuen Konfi­gu­ rationsparameter RTO_SERVER_RESTART aktiviert. Mit der Angabe einer Zeitdauer in Sekunden wird festgelegt, wie lange eine Wiederanlaufzeit (Zeitspanne vom Beginn des Starts bis hin zum Zustand „Online“ des Datenbank- 44 ORDIX News 1/2008 servers) maximal sein darf. Der Wert kann im Bereich zwischen 60 und 1800 Sekunden liegen. Sobald dieser Konfigurationsparameter gesetzt ist, aktiviert er automatisch ein Monitoring des Datenbankservers, um die RTO-Richt­li­ nie einzuhalten. Unter der Vo­raussetzung, dass ein Physical Logfile mit einer Mindestgröße von 10 MB sowie ausreichend große Logical Logfiles zur Transaktionsprotokollierung zur Verfügung stehen, werden, abhängig von der Transaktionslast, Checkpoints durchgeführt, damit die Einhaltung der RTO-Policy garantiert werden kann. Bei aktivierter RTORichtlinie wird der Standardparameter für den Checkpoint Intervall CKTINTVL ignoriert. Datenbanken Die beiden zusätzlichen Konfigurationsparameter RAS_PLOG_SPEED und RAS_LLOG_ SPEED regeln die Lesegeschwindigkeit des Physical Logs und des Logical Logs. Beide Werte werden beim Starten vom Datenbankserver automatisch ermittelt und eingetragen. Eine Übersicht über die drei Konfigurationsparameter finden Sie in Abbildung 1. Zusätzlich zum automatischen Monitoring wird bei Aktivierung einer RTO-Policy auch das dynamische Ressourcen Tuning gestartet. Dabei überprüft der Datenbankserver im laufenden Betrieb ständig die beiden Parameter LRU_MIN_DIRTY und LRU_MAX_DIRTY und führt, je nach Lastsituation, auch selbstständig Anpassungen durch. Bei Bedarf werden durch den Datenbankserver im laufenden Betrieb weitere AIO_VPs (Informix Virtuelle Prozesse für das Schreiben und Lesen von Platte) und Page Cleaner Prozesse hinzugefügt, die für das Schreiben der geänderten Bufferpool Pages aus dem Shared Memory auf Platte (Synchronisation) verantwortlich sind. LRU-Optimierung Das Schreiben des Inhaltes eines Shared Memory Buffers auf die Platte (Synchronisation) wird im Englischen als „buffer flushing“ bezeichnet. Die automatische Ausführung dieser Aktion wird anhand der Schwellwerte der beiden LRU-Parameter LRU_MIN_DIRTY und LRU_MAX_DIRTY gesteuert. Bisher hatten diese beiden Schwellwerte eine feste Größe, die nicht dynamisch angepasst werden konnte. Zukünftig optimiert der Datenbankserver die Werte bei entsprechendem Lastverhalten automatisch. Voraussetzung dafür ist entweder, dass der neue Konfigurationsparameter AUTO_LRU_TUNING = 1 gesetzt ist oder, wie bereits oben erwähnt, der RTO_SERVER_RESTART aktiviert ist. Stellt der Datenbankserver Engpässe in der LRU-Queue Verwaltung fest, dann werden die beiden Schwellwerte der LRU-Parameter LRU_MAX_DIRTY und LRU_MIN_DIRTY automatisch um 1 Prozent nach unten korrigiert. Durch das Herabsetzen der beiden LRU-Schwellwerte werden die geänderten Pages/Datensätze aus dem Shared Memory häufiger auf Platte geschrieben. Diesen Vorgang nennt man auch Synchronisation oder LRU-Flushing. Die Überprüfung der beiden LRU-Parameter erfolgt bei jedem ausgelös­ ten Checkpoint (siehe Abbildung 2). KONFIGURATIONSPARAMETER Recovery Time Objective RTO_SERVER_RESTART ## (Angabe in Sekunden) # Zeit, die der Server für einen Recovery aus dem Offline # maximal benötigen darf. # 0=Off, die Angabe erfolgt in Sekunden im Bereich von 60-1800 # Dieser Wert beeinflusst u.a. das Checkpoint-Interval. RAS_PLOG_SPEED ### # Parameter für die Lesegeschwindigkeit des Physical Logs. # Dieser Wert wird vom DB-Server beim Starten automatisch # ermittelt und eingetragen. # Standardwert: 10240 pages/sec (20 Mb/sec) # Wert in pages written/second RAS_LLOG_SPEED ### # Parameter für die Lesegeschwindigkeit des Logical Logs # Dieser Wert wird vom DB-Server beim Starten automatisch # ermittelt und eingetragen. # Wird als 1/8 von RAS_PLOG_SPEED initialisiert. # Standardwert: 1280 pages/sec (2.5 Mb/sec) # Wert in pages written/second Abb. 1: Konfigurationsparameter der RTO-Policy. Automatische Anpassung von LRU_MIN_DIRTY und LRU_MAX_DIRTY 12:02:02 Adjusting LRU for bufferpool - id 0 size 2k 12:02:02 Old max 78.4 min 68.6 New max 77.6 min 67.9 Abb. 2: Beispieleintrag im Message Logfile nach dynamischer Anpassung beider LRU-Parameter durch den DB-Server. Die Standardeinstellungen für die Schwellwerte der beiden LRU-Parameter betragen 50 für LRU_MIN_DIRTY und 60 für LRU_MAX_ DIRTY. Bei aktivierter LRU-Optimierung können die Werte höher gesetzt werden. Eine Empfehlung lautet inzwischen, mit den Werten LRU_MIN_DIRTY = 70 und LRU_MAX_ DIRTY = 80 zu starten. Die Einstellungen der LRU-Schwellwerte regeln das Schreiben der geänderten Daten aus dem Shared Memory Buffer auf die Platte. Wird der Schwellwert von LRU_MAX_DIRTY überschritten, werden solange modifizierte Datenseiten auf die Platte geschrieben, bis der untere Schwellwert LRU_MIN_DIRTY erreicht ist. Achtung: Die automatischen LRU-Anpassungen sind nicht permanent und werden auch nicht in der ONCONFIG-Datei gespeichert. Falls keine manuelle Änderung der Konfigurationsparameter in der $ONCONFIG erfolgt, wird beim nächsten Neustart des Datenbank- ORDIX News 1/2008 45 Datenbanken servers wieder auf die ursprünglichen Konfigurationswerte, die in der ONCONFIG-Datei enthalten sind, zurückgegriffen. Nicht blockierende Checkpoints Mit der Version 11 wurde der bisherige Checkpoint-Algorithmus durch einen praktisch nicht blockierenden Checkpoint-Algorithmus ersetzt. Durch das optimierte LRU-Flushing werden die modifizierten Buffer Pages außerhalb der Checkpointphase auf Platte geschrieben. Das einzige, was den Datenbankserver noch für geringe Sekundenbruchteile blockiert, ist das Schreiben des Checkpoint-Eintrages in das Logical Logfile. Der Informix Dynamic Server überwacht die Auslastung und die bisherigen CheckpointZeiten und löst Checkpoints bei Bedarf häufiger aus, damit kritische Ressourcen, wie das physische oder das logische Logfile, nicht erschöpft werden. Damit wird sichergestellt, dass Transaktionen während eines Checkpoints nicht blockiert werden. Bei Anwendungen, die empfindlich auf Reaktionszeiten reagieren, kann die bisherige Methode geändert werden. Bei dieser wurde aggressives LRU-Flushing (Schreiben der Daten aus dem Shared Memory Bereich auf Voraussetzungen für nicht blockierende Checkpoints: • • Ausreichend groß dimensionierte Logfiles (Logical- und Physlog) Bei zu kleinen Logfiles wird eine Meldung zusammen mit einem Vorschlagswert in das Logfile mitprotokolliert. 16:05:17 Performance Advisory: Based on the current workload, the physical log might be too small to accommodate the time it takes to flush the bufferpool. 16:05:17 Results: The server might block transactions during checkpoints. 16:05:17 Action: If transactions are blocked during the checkpoint, increase the size of the physical log to at least 14000 KB. 16:05:17 Performance Advisory: Based on the current workload, the logical log space might be too small to accommodate the time it takes to flush the bufferpool. 16:05:17 Results: The server might block transactions during checkpoints. 16:05:17 Action: If transactions are blocked during the checkpoint, increase the size of the logical log space to at least 14000 KB. Abb. 3: Eintrag im Online Logfile bei zu kleinen Logfiles. 46 ORDIX News 1/2008 die Platte auf Basis von sehr niedrigen LRUParametereinstellungen) verwendet, um die Wartezeiten des Checkpoints zu verringern. Es ist allerdings darauf zu achten, dass sowohl das Physical Logfile als auch die Transaktionsprotokolle ausreichend groß angelegt sind. Falls dies nicht der Fall sein sollte, werden blockierende Checkpoints durchgeführt. Gleichzeitig wird ein Eintrag in das Message Logfile des Datenbankservers vorgenommen, der auch einen Hinweis mit Empfehlung einer Mindestgröße enthält (siehe Abbildung 3). Checkpoint Analyse DasneueKommandoonstat -g ckpbieteteine Möglichkeit, die aufgetretenen Checkpoints zu überwachen und zu analysieren. Es wird ausgegeben, ob die Funktion AUTO_CKPTS an- oder ausgeschaltet ist, welcher Wert für RTO_SERVER_RESTART eingestellt ist, sowie die aktuell erwartete Restart-Zeit beim Recovery (siehe Abbildung 4). Durch die Erweiterung der sysmaster Datenbank um die beiden Tabellen syscheckpoint und sysckptinfo kann man alternativ auch über ein selbst erstelltes SQL-Statement auf die gewünschten Informationen zugreifen. Im Folgenden werden nun die wichtigsten Aussagen des Kommandos onstat –g ckp beschrieben, wie in Abbildung 4 zu sehen ist: • Interval: fortlaufende Nummerierung der Checkpoints • Clock time: Zeitpunkt, wann der Checkpoint aufgetreten ist • Trigger: auslösender Grund eines Checkpoints • Admin: Das System hat einen Checkpoint ausgelöst. • RTO (Maximale Recovery Zeit): anhand des aktuellen Workload wurde ein automatischer Checkpoint angestoßen, um die RTO-Policy einzuhalten. • *Admin: Das System hat wegen Adminaufgaben einen Checkpoint ausgelöst, z. B. onparams, onspaces, onmode ... • • *User: Es wurde manuell der Befehl onmode -c abgesetzt. *Backup: Ein Archiv (ontape/onbar) hat den Checkpoint ausgelöst. Datenbanken mstoeb>onstat -g ckp IBM Informix Dynamic Server Version 11.10.FC1 AUTO_CKPTS=On RTO_SERVER_RESTART=60 seconds -- On-Line -- Up 04:18:43 -- 29696 Kbytes Estimated recovery time 24 seconds Critical Sections Clock TotalFlush Block # Ckpt Wait Long # Dirty IntervalTime Trigger LSN Time Time Time Waits Time Time Time Buffers 150 15:35:45 Backup 52:0x1314c 0.1 0.0 0.0 0 0.0 0.0 0.0 0 151 15:36:14 Admin 55:0x18 0.0 0.0 0.0 0 0.0 0.0 0.0 0 153 15:36:22 Admin 55:0x203c 0.0 0.0 0.0 0 0.0 0.0 0.0 0 154 15:36:26 Admin 55:0x303c 0.2 0.0 0.0 0 0.0 0.0 0.0 0 155 15:36:334 Admin 55:0x403c 0.0 0.0 0.0 0 0.0 0.0 0.0 0 167 15:38:19 Backup 55:0x1411c 0.1 0.0 0.0 0 0.0 0.0 0.0 0 168 15:45:02 RTO 57:0x29015c 4.5 4.2 0.0 1 0.0 0.2 0.2 558 169 15:56:14 RTO 58:0x90d618 7.2 5.9 0.0 1 0.1 1.2 1.2 539 219 11:33:33 *User 93:0x8c6018 0.1 0.1 0.0 1 0.0 0.1 0.1 3 220 13:04:23 *Backup 98:0x4f1018 1.6 1.3 0.0 0 0.0 0.0 0.0 140 221 13:04:24 Backup 98:0x4f211c 0.1 0.0 0.0 0 0.0 0.0 0.0 0 222 13:18:01 Plog 102:0x8f44b810.9 10.3 0.0 1 0.0 0.5 0.5 755 Max Plog pages/sec 200 Max Llog pages/sec 200 Max Dskflush Time 6 Avg Dskflush pages/sec 69 Avg Dirty pages/sec 0 Physical Log Dskflu TotalAvg /Sec Pages/Sec 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 131 2224 5 90 1602 2 3 20 0 110 2567 0 0 0 0 73 6647 8 Logical Total Pages 1 4 1 1 1 1 4570 4439 23 8519 1 11585 Log Avg /Sec 1 0 0 0 0 1 11 6 0 0 0 14 Blocked Time 0 Abb. 4: Beispielausgabe des Informix Kommandos onstat -g ckp. • • Llog: Der letzte Checkpoint wäre beim Logwechsel überschrieben worden. Daher musste ein Checkpoint ausgelöst werden. Glossar RTO • Plog: Der Füllgrad des Physical Logs hat 75 % erreicht. Daher musste ein Checkpoint ausgelöst werden. Recovery Time Objective. Zielvereinbarung in Sekunden, wie lange der DBServer nach einem Ausfall von der Startphase bis zum Zustand „Online“ benötigen darf. LRU Least Recently Used. Interne Verwaltung einer Pointer-Liste, die auf Daten im Shared Memory verweist. AIO-VP Informix Virtueller Prozess (Asynchronous I/O) für das Schreiben auf Platte. • CKPTINTVL: Auslöser ist das Checkpointinterval CKPTINTVL der ONCONFIG, wenn das AUTO_CKPT ausgeschaltet ist. Links LSN: Anzeige der Unique_ID und Page des Logical Logfile, in dem der Checkpoint gespeichert ist. Danach folgen einige statistische Werte, wie z. B. Dirty Buffers = Anzahl der Buffer Pages, die auf Platte geschrieben wurden oder Total Time = komplette Dauer eines Checkpoint Requests in Sekunden. Fazit IBM hat den Schwerpunkt der neuen Funktionen der Version 11 ganz gezielt auf Performance und Skalierbarkeit, Reduktion des Administrationsaufwands sowie auf Ausfallsicherheit gelegt. Dadurch kommen die langjährigen, bereits bekannten Stärken des IDS, die effiziente Administration, Zuverlässigkeit und hochskalierbare Architektur besonders den ► [1] ORDIX News Artikel „Cheetah - IBM’s neues Raubtier“: http://www.ordix.de/ORDIXNews/3_2007/Datenbanken/ibm_ids_teilI.html Unternehmen zu Gute, die einen 24x7-Betrieb auf höchstem Niveau benötigen. Alle hier vorgestellten Erweiterungen des Datenbankservers IDS 11 gehen einher mit einer Arbeitserleichterung für den Datenbankver­ ant­wortlichen. Damit ist ein weiterer Schritt in die von IBM propagierte „Administration Free Zone“ getan. In einer der kommenden Ausgaben beleuchten wir die neuen Hochverfügbarkeitslösungen, die unter dem Codenamen MACH11 in den Informix Dynamic Server 11 integriert wurden. Manfred Stöb ([email protected]). ORDIX News 1/2008 47 Open Source Neue Features in OpenLDAP 2.3 (Teil II): OpenLDAP – Serverkonfiguration zur Laufzeit Dieser Artikel richtet sich an erfahrene LDAP-Administratoren, die sich für neue Funktionen interessieren und die weitreichenden Möglichkeiten von OpenLDAP kennen lernen wollen. In der ORDIX News 4/2007 [1] haben wir bereits über neue Funktionen des OpenLDAP berichtet, die in der Version 2.3 Einzug gehalten haben. Hierbei kamen der neue Replikationsmechanismus syncrepl und die overlays zur Sprache. In diesem Artikel wird eine weitere, neue Funktion präsentiert: die LDAP-Serverkonfiguration ohne Neustart des Dienstes oder Neuladen der Konfigurationsdatei. Zudem wird am Beispiel sudo demonstriert, wie sich das vielfältige LDAP-Protokoll für andere Zwecke, fernab der Benutzerauthentifizierung, nutzen lässt. Konfiguration zur Laufzeit In der Praxis setzen die meisten Unternehmen aus Redundanz- und Lastverteilungsgründen mehrere LDAP-Server zur Authentifizierung und Namensauflösung ein. Selbst in mittelgroßen Unternehmen sind das schon mal schnell fünf bis acht LDAP-Server. In älteren OpenLDAP-Versionen musste der Dienst jedes Mal neu gestartet beziehungsweise die Konfigurationsdatei neu geladen werden, nachdem eine Änderung in der Konfigurationsdatei /etc/openldap/slapd.conf durchgeführt wurde. Da die Änderungen meistens auf allen LDAP-Servern durchgeführt werden sollten, musste dies für jeden Server separat durchgeführt werden. Seit der Version 2.3 des OpenLDAP-Servers kann die Konfiguration zur Laufzeit geändert werden. Für die Umsetzung wurde ein neues Datenbank-Backend namens ldif eingeführt, in dem die Konfigurationseinstellungen gespeichert werden. Die Konfigurationsdateien werden im LDIF-Format im Verzeichnis /etc/openldap/slapd.d erwartet. Das Ändern von Konfigurationseinstellungen erfolgt nun analog zum Hinzufügen von Benutzern oder Gruppen. Es wird eine LDIF-Da- 48 ORDIX News 1/2008 tei mit Konfigurationseinstellungen erstellt, die dann mit einem der beiden Befehle ldapadd oder ldapmodify auf die Datenbank angewendet werden. Der LDAP-Server erkennt die Konfigurationsänderungen und wendet sie so­ fort ohne Neustart an. Die bisherige Konfigurationsdatei kann zwar weiterhin genutzt und geändert werden, allerdings mit den bekannten Nachteilen des anschließenden Neustarts des LDAP-Dienstes. Von der Parallelnutzung beider Konfigurationsverfahren ist abzuraten, da kein automatischer Abgleich stattfindet und schnell die Übersicht verloren geht, wo welche Einstellung aktiviert wurde. Wir empfehlen deshalb, die bestehende Konfiguration in das neue Verfahren zu konvertieren und die alte Konfigurationsdatei anschließend zu löschen. Abbildung 1 zeigt die notwendigen Schritte zur Konvertierung. Es gilt dabei allerdings eine kleine Einschränkung zu beachten: Der alte Replikationsdaemon slurpd kann mit dem neuen Verfahren nicht umgehen und braucht zwingend eine slapd.conf. Dies stellt jedoch ein zu vernachlässigendes Problem dar, da der wesentlich flexiblere und auf Performance ausgelegte Open Source syncrepl-Mechanismus [1] von OpenLDAP Version 2.3 diese Einschränkung nicht besitzt. slapd.d Internals Der LDAP-Konfigurationsbaum unter /etc/ openldap/slapd.d ist nun folgendermaßen aufgebaut: Direkt im Konfigurationsverzeichnis befinden sich das Objekt cn=config und die Datei cn=config.ldif, in der globale Konfigurationsattribute wie z. B. PID, args, TLS, Threads oder der Pfad zum Konfigurationsverzeichnis gesetzt werden. Letztendlich entsprechen die Einstellungen den globalen Ein­ stellungen der alten Konfigurationsdatei. Die unterhalb von cn=config befindlichen Objekte, wie z. B. cn=schema beinhalten weitere Einstellungen zur Konfiguration: Das Objekt cn=schema ist für die Konfiguration der vom slapd verwendeten Standardschemata wie z. B. core, cosine und inetOrgPerson zuständig. Mit den in geschweiften Klammern bei 0 beginnenden Zahlen kann die Ladereihenfolge der Einträge bestimmt werden. Auch innerhalb der Schemadateien sind die Objekte nun im LDIF-Format und können zur Laufzeit durch importieren einer Datei im LDIF-Format geändert werden. Um adminis­ trativen Zugriff auf die Konfiguration zu erlan­ gen, muss nun in der Datei /etc/openldap/ slapd.d/cn=config/olcDatabase={0} config.ldif ein Kennwort für den schon ein­ getragenen Benutzer cn=config gesetzt werden. Der Eintrag in der Datei hat das Format {SSHA}0JAlK29Fna1PmJvjdch2SxidRUXhLKP7. Das gehashte Kennwort kann mit dem Befehl slappasswd -s <Kennwort> erzeugt werden und erlaubt anschließend den Zugriff auf die Konfiguration mit den normalen LDAP-Befehlen. Mit dem Befehl ldapsearch (siehe Abbildung 2) kann die Konfiguration innerhalb des LDAP-Verzeichnisses angesehen werden, während mit ldapmodify (siehe Abbildung 3) Werte zur Laufzeit verändert und aktiviert werden. LDAP als zentrales Konfigurationsdepot In großen Unix-Umgebungen kommt häufig das Produkt sudo zum Einsatz. Das Wort „sudo“ steht hier für „substitute user do“. Um nicht allen Benutzern eines Unix-Systems alle Berechtigungen zu geben, kann der Administrator mit sudo die Berechtigungen einschränken, indem nur bestimmte Kommandos erlaubt sind und festgelegt wird, auf welchem Server sie von wem und unter welcher Benut- /etc/init.d/ldap stop mkdir /etc/openldap/slapd.d /usr/lib/openldap/slapd -f /etc/openldap/slapd.conf \ -F /etc/openldap/slapd.d rm /etc/openldap/slapd.conf chown -R ldap:ldap /etc/openldap/slapd.d /etc/init.d/ldap start Abb. 1: Konvertierung einer bestehenden Konfiguration in das neue Verfahren. $> ldapsearch -LLL -x -D "cn=config" -W -b cn=config objectClass=* dn: cn=config objectClass: olcGlobal cn: config olcConfigDir: /etc/openldap/slapd.d/ olcArgsFile: /var/run/slapd/slapd.args ... olcThreads: 16 Abb. 2: Anzeige der Konfiguration. ldap1:/tmp # cat test.ldif dn: cn=config changetype: modify replace: olcThreads olcThreads: 4 ldap1:/tmp # ldapmodify -x -W -D "cn=config" -f test.ldif Abb. 3: Änderung des olcThreads-Attributs zur Laufzeit. zerkennung ausgeführt werden dürfen. Dafür schreibt der Benutzer den Befehl sudo vor den eigentlichen Befehl. Ein Beispiel wäre sudo useradd -m user1. Klassisch wird die Konfiguration in der Datei /etc/sudoers vorgenommen. Von der Herstellerseite ist die Datei zwar so aufgebaut, dass nur eine Datei für alle Systeme gepflegt werden muss. Diese muss aber nach einer Änderung auf die betroffenen Systeme verteilt werden, was vor allem in größeren Umgebungen einen erheblichen Pflegeaufwand verursacht. Dieser Pflegeaufwand wird mit Hilfe von NIS oder anderen Möglichkeiten reduziert. Hier möchten wir aufzeigen, welche Anwendungsmöglichkeiten LDAP bietet, indem wir die sudo-Konfigurationsdaten in unserem LDAP-Verzeichnisdienst pflegen. ORDIX News 1/2008 49 Open Source Vorteile der LDAP Integration Nachteile der LDAP Integration • Die sudo-Konfiguration kann zentral verwaltet werden und muss bei Änderungen nicht mehr auf die Server verteilt werden. • • Bei der sudo-Kommandoausführung muss nicht mehr die ganze sudoers-Datei aus­gewertet, sondern nur im LDAP nach be­ stimmten Einträgen gesucht werden. • Das Programm visudo wird nicht mehr zum Editieren der Konfiguration benötigt. Stattdessen wird der LDAP-seitige Objekt/ Attribut-Check genutzt. Die sudo-Konfiguration kann nicht vollständig im LDAP implementiert werden. So ist z. B. die Gruppierung von Befehlen (command aliase), Rechnern (host aliase) und Usern (user aliase) nur bedingt umsetzbar. Das ist aber keine bedeutende Einschränkung, da bei einem LDAP-Eintrag beliebig viele Kommandos, Rechner oder Benutzer/Gruppen angegeben werden können. • Es muss einmalig der Aufwand betrieben werden, ein LDAP-fähiges sudo auf die Server zu verteilen und eine Konfigurationsdatei anzupassen. • Falls kein Netzwerk zu Verfügung steht, kann die sudo-Konfiguration nicht geladen werden. Als Fallback kann aber eine lokale /etc/sudoers lokal abgelegt werden. dn: ou=SUDOers,dc=ordix,dc=de objectClass: top objectClass: organizationalUnit ou: SUDOers dn: cn=defaults,ou=SUDOers,dc=ordix,dc=de objectClass: top objectClass: sudoRole cn: defaults description: Standard sudo Optionen sudoOption: always_set_home sudoOption: env_reset sudoOption: log_host sudoOption: log_year sudoOption: logfile=/var/log/sudo.log dn: cn=%users,ou=SUDOers,dc=ordix,dc=de objectClass: top objectClass: sudoRole cn: %users sudoUser: %users sudoUser: !joe sudoHost: nameserver1 sudoHost: nameserver2 sudoCommand: /sbin/mount /cdrom sudoCommand: /sbin/umount /cdrom sudoCommand: /sbin/shutdown -[hr] now Abb. 4: LDIF-Datei mit der sudo-Konfiguration. uri sudoers_base sudo_debug ldap://ldap1.ordix.de ou=SUDOers,dc=ordix,dc=de 2 Abb. 5: Client-Konfiguration in der Datei /etc/ldap.conf. Link ► [1] ORDIX News Artikel „OpenLDAP - Alles in sync?“: http://www.ordix.de/ORDIXNews/4_2007/Open_Source/Open_LDAP_2_3.html 50 ORDIX News 1/2008 Vorbereitung des LDAP-Servers Um die sudo-spezifischen Objekte innerhalb des LDAP-Verzeichnisdienstes zu verwalten, muss eine Schemaerweiterung auf den LDAPServern vorgenommen werden. Dazu wird die Schemadatei sudo.schema benötigt, welche von der sudo-Webseite heruntergeladen werden kann. Zusätzlich muss die Schemadatei von OpenLDAP geladen werden. Dies kann entweder über den herkömmlichen Weg include/etc/openldap/schema/sudo. schema innerhalb der Konfigurationsdatei slapd.conf oder über das oben beschriebene Verfahren cn=config gelöst werden. Nachdem der LDAP-Server mit den Schema­ erweiterungen gestartet ist, können nun ers­te Einträge vorgenommen werden. Dies kann sowohl mit klassischen LDIF-Dateien geschehen, als auch mit Scripting-Verfahren, wie beispielsweise Perl oder einem grafischen LDAP-Browser wie phpLDAP­admin oder dem LDAP Account Manager (LAM). Auch die Konvertierung einer bestehenden sudo-Konfiguration ist leicht möglich. Mit den Kommandos export SUDOERS_BASE=ou=SUDOers,dc =ordix,dc=de sudoers2ldif /etc/ sudoers > /tmp/sudoers.ldif kann aus einer bestehenden Konfigurationsdatei eine LDIF-Datei erstellt werden, die dann in den LDAP-Verzeichnisbaum importiert werden Open Source kann. Abbildung 4 zeigt ein Beispiel für eine LDIF-basierte Konfiguration, die nun mit dem Kommando ldapadd importiert werden kann. In diesem Beispiel wird eine separate Organisationseinheit SUDOers angelegt, um die sudo-Konfiguration von anderen Einträgen getrennt zu verwalten. Mit dem Eintrag cn=defaults können globale sudo-Optionen konfiguriert werden, wie beispielsweise das logfile, indem lokal auf dem System die mit Hilfe von sudo ausgeführten Kommandos protokolliert werden. Mit dem Eintrag cn=%users wird allen Mitgliedern der Gruppe users - außer joe - auf den Servern nameserver1 und nameserver2 das Recht gegeben, das CD-ROMLaufwerk zu mounten bzw. zu unmounten und den Server herunter zu fahren bzw. neu zu starten. Anpassung der Clients Nun müssen die sudo-Clients von dem LDAP-Server erfahren. Hierzu wird auf dem Client lokal die Datei /etc/ldap.conf bearbeitet bzw. neu angelegt. sudo_debug ist bei der Fehlersuche hilfreich, sollte bei erfolgreichem Betrieb aber auf 0 gesetzt werden. Die Datei sollte dem Benutzer root gehören und auch nur für ihn Leserechte besitzen. Die alte Datei /etc/sudoers könnte jetzt vom System entfernt werden. Möchte man allerdings einen Fallback-Mechanismus realisieren, welcher bei Netzwerkausfall greift, lässt man sie lokal bestehen. Die Datei wird dann automatisch genutzt, falls der LDAP-Server nicht erreichbar sein sollte. Das Kommando sudo -l sollte nun die Kommandos anzeigen, die der aufrufende Benutzer ausführen darf. Glossar DatenbankBackend LDIF Eine Datenbank, die für die physikalische Speicherung der Daten genutzt wird. Diese kann textbasiert sein - aber auch eine SQL-Datenbank ist möglich. LDAP Data Interchange Format. LDIF ist ein ASCII-basiertes Dateiformat zur Darstellung von Informationen aus einem LDAP-Verzeichnis. Seminarempfehlung: OpenLDAP - Praxiseinsatz im Netzwerk ► Internet: http://training.ordix.de/seminar.php?nr=636 OpenLDAP, eine Implementation des LDAP als freie Software, ist Bestandteil der meisten, aktuellen Linux-Distributionen und läuft auch unter verschiedenen Unix-Derivaten. In diesem Workshop bekommt der Teilnehmer einen Überblick über die Funktionsweise und Administration von OpenLDAP. Seminarinhalte: • • • • • • • • • • • • • • • • Grundbegriffe der Protokolle LDAP und X500 Aufbau und Komponenten eines Verzeichnisdienstes LDAP-Utilities zum Bearbeiten des Verzeichnisses Graphische Tools für LDAP Zugriffe Aufbau Schema, Entwurf eigener Schemata Erweiterte Serverkonfiguration für multiple Baumstrukturen Debugging und Logging Anbindung von Overlays Replikation und Abgleich von Verzeichnisdaten Master/Slave-Konfiguration Zeitsynchronisation mit NTP Clientanbindung an LDAP Verzeichnisdienste Einsatz von ACL‘s zur Zugriffsbeschränkung Sicherheit mit SSL/TLS LDAP im Zusammenspiel mit Anwendungen Übungen Termine: 17.03.- 19.03.2008in Wiesbaden 23.06.- 25.06.2008 in Wiesbaden 15.09.- 17.09.2008 in Wiesbaden 10.11.- 12.11.2008in Wiesbaden Seminar-ID: BS-16 Dauer: 3 Tage Preis pro Teilnehmer: 1.090,00 € (zzgl. MwSt.) Resümee Wie in diesem und dem letzten ORDIX News Artikel berichtet, bietet OpenLDAP 2.3 einige neue Funktionen, die die Administration vor allem von größeren Netzwerken mit mehreren LDAP-Servern erleichtern. Die in der Ausgabe 4/2007 beschriebenen overlays bieten modulare Möglichkeiten, den LDAP-Server um Funktionen zu erweitern, ohne ihn neu zu kompilieren. Die hier beschriebene Konfiguration zur Laufzeit erweitert die Administration, ohne dass lästige Neustarts der Dienste erforderlich werden. Die Integration der sudo-Verwaltung ist nur ein Beispiel von vielen, wie man die Konfiguration zentral im LDAP verwaltet. Weitere Möglichkeiten sind zum Beispiel die Pflege der E-Mail-Adressen, die Verwaltung von Radiusbenutzern oder die Verwaltung der DHCP/ DNS-Daten innerhalb von LDAP. Christian Fertsch ([email protected]). ORDIX News 1/2008 51 Wir lieben Java! Ein starkes Team für individuelle Anwendungsentwicklung Die Struktur Ihres Unternehmens mit Ihrer Organisation und Ihren Abläufen ist einzigartig. Wir entwickeln für Sie Lösungen, so individuell wie Ihr Unternehmen! Wir bieten: • Konzeption und Implementierung von JEE-Projekten • Integration von Open Source Komponenten • • • • • (z. B. Hibernate, Struts, Seam und Spring) Application Server (z. B. JBoss, WebSphere) Web-basierte Anwendungen mit JSF, JSP, Servlets u. a. GUI-Entwicklung mit Swing Verteilte Anwendungen Seminare, Coaching ... für Ihre Geschäftsprozesse. Weitere Informationen finden Sie im Internet unter http://www.ordix.de. Für ein persönliches Gespräch wenden Sie sich an Frau Jana Kreschel: [email protected]
