01 Spring AOP
Werbung
www.ordix.de news Spring AOP 2009 € 2,20 Kundenservice groß geschrieben: Einführung in die aspektorientierte Programmierung mit Spring S. 12 Ein Data Warehouse für den Admin Open Source Reporting mit BIRT Backup und Recovery mit NIM Mit „screen“ zur Schirmherrschaft Mit „Datenauflistung“ beim MS SQL Server 2008 Perfomance-Indikatoren sammeln S. 06 IBM AIX NIM kann mehr als nur installieren 01 S. 38 Das kostenlose Tool ist eine empfehlenswerte Alternative zu kommerziellen Produkten S. 18 Tipps und Tricks aus der Unix-Welt S. 44 Save the Date DOAG Logistik & SCM 2009 12. Mai 2009 im DHL Innovation Center, Troisdorf X Erleben Sie die neuesten Innovationen und globale Logistiklösungen in einer einzigartigen Location X Informieren Sie sich über die neuesten Strategien und Entwicklungen aus diesem Bereich X Tauschen Sie sich mit Entscheidern der unterschiedlichen Branchen über aktuelle Best Practices aus X Erweitern Sie Ihr Know-how und Ihr Netzwerk für den Themenbereich Logistik & SCM X Diskutieren Sie mit Oracle Experten und Führungskräften über neue und innovative Ideen für Ihre Projekte X Alle Infos und Anmeldung unter www.doag.org/go/logistik Editorial Nullen oder Einsen Paderborn, März 2009 Die Informatik ist eigentlich ganz einfach und klar: Sie besteht nur aus 0 oder 1. Deswegen sollten Sie in der IT-Branche auch richtig schnell zu klaren, eindeutigen Aussagen und Ergebnissen kommen. Stimmt es? Nein? Ach, geht es Ihnen auch so, dass sich Ihre IT-Spezialisten bei irgendeinem Phänomen oder Fehler schlimmer winden als ein Aal an Land, um wieder ins Wasser zu gelangen? Anstatt klare Aussagen zu einem Fehler oder einem Termin bekommen Sie eine Anhäufung von Entschuldigungen, Allgemeinplätzen und Konjunktiven? Viele IT-Spezialisten verhalten sich also fast wie Politiker im Wahljahr - bloß keine Entscheidung treffen, sich ja nicht festlegen. Wahlen sind übrigens jedes Jahr und auch bei Politikern gibt es Nullen oder Einsen, aber meist mehr Nullen als Einsen. Nehmen wir unseren alten und neuen Wirtschaftsminister: Der alte wollte eigentlich nie Wirtschaftsminister sein (Zitat: „Ich hoffe, dass es meinem Land nie so dreckig geht, dass es auf Leute wie mich zurückgreifen muss“), konnte das aber erst nach knapp dreieinhalb Jahren klar sagen. Der neue kennt Wirtschaft vermutlich nur vom Besuch einer solchen (für Nicht-Bayern oder Franken: Wer dort in die Wirtschaft geht, will meist nur ein Bier trinken). Aber als smarter Politiker mit dem richtigen Parteibuch zum richtigen Zeitpunkt kann man halt alles werden. Übrigens, nicht Merkel sondern Seehofer machte ihn zum Wirtschaftsminister. Seine Begründung sind das „beneidenswerte Auftreten“ und die Fremdsprachenkenntnisse zu Guttenbergs. - Naja, wenn man damit Wirtschaftsminister werden kann ... Schade, dass Nikolaus Bollmann (siehe Editorial der letzten ORDIX News) kein solches Auftreten hat. Sein Vorschlag führte zumindest zur Abwrackprämie im Konjunkturpaket II. Das meist verkaufte Auto war dann bisher der VW Fox. Der wird übrigens in Brasilien gebaut. Aber Opel bleibt zumindest von der Insolvenz so lange verschont, wie der sogenannte1) Wirtschaftsspezialist Rüttgers dem amerikanischen Pleiteunternehmen GM Hilfen verspricht, die aber angeblich nur in Deutschland bleiben. Erstaunlicherweise ging die GM Tochter Saab sofort Pleite, als der schwedische Staat genau solche Hilfen versagte und GM den Geldhahn zudrehte. Wenigstens kann Saab jetzt aus der Insolvenz heraus saniert und von der kranken Mutter GM losgelöst werden. Manche Aussagen habe ich wieder via Google zusammengesucht. Ich hoffe, ich liege dieses Mal nicht so falsch wie mit Kurt Tucholsky und „Wenn die Börsenkurse fallen“. Danke denen, die meinen Aufsichtsrat und mich korrigiert haben. Schön und treffend fand ich das Gedicht dennoch. Dieser Tage wäre auch Heinz Erhardt 100 Jahre alt geworden, der Meister des Vierzeilers: In nur vier Zeilen was zu sagen Erscheint zwar leicht, doch ist es schwer! Man braucht ja nur mal nachzuschlagen; Die meisten Dichter brauchen mehr. Mehr Zeilen brauchten auch die Autoren der Artikel dieser ORDIX News. Schließlich braucht die Beschreibung eines Clusters, von BIRT oder Oracle Grid Control mehr als nur smartes Auftreten. Keinen Sinn macht es, meine Editorials mit Versionskontrolle in Subversion anzulegen, obwohl ich dieses Mal sehr viel Bezug auf die letzte Version genommen habe. Aber vielleicht sollte ich auch mal ein Recovery alter Editorials wagen. Ob das mit NIM klappt, erfahren Sie ab Seite 38. Sollten Sie demnächst mal Aal essen, denken Sie nicht an Ihren IT-Spezialisten, aber versuchen Sie, diesen immer wieder mal festzunageln. Manchen empfehle ich auch, Logfiles nicht nur auf den letzten Zeilen zu lesen, denn oft steht bereits am Anfang, warum es am Ende nicht geklappt hat. In diesem Sinne ein schönes Frühjahr im Wahl- und Krisenjahr 2009. Lassen Sie sich nicht mürbe machen durch Pessimismus à la Merkels Neujahrsrede. Es kommen (hoffentlich) auch wieder optimistischere Politiker, egal ob Nullen oder Einsen: die Nullen dienen den Kabarettisten und dem Lachen, die Einsen der Politik und dem Fortschritt. Wolfgang Kögler 1) Habe ich aus der FAS geklaut . ORDIX News 1/2009 3 Inhalt Ein Data Warehouse für den Administrator Seite 06 Open Source 08 Hochverfügbarkeit mit Heartbeat-Version 2 (Teil II): Immer noch verfügbar, Administrator? Bericht über die Implementierung von Heartbeat Clustern in einem Kundenprojekt. Es wird gezeigt, wie flexibel das Verhalten der Cluster-Lösung an die Gegebenheiten des Unternehmens angepasst werden kann. 18 Open Source Reporting mit BIRT Das Reporting mit BIRT ist als kostenlose Alternative zu kommerziellen Produkten von IBM, SAP oder Oracle auch besonders für mittelständische Unternehmen geeignet. 21 BIRT im Expertencheck 29 Flexible Versionskontrolle mit Subversion (SVN) Beschreibung der grundsätzlichen Funktionsweise sowie der administrativen Konfigurationsmöglichkeiten des Versionskontrollsystems Subversion. 44 Tipps und Tricks aus der Unix-Welt: Mit „screen“ zur Schirmherrschaft Vorstellung des sehr nützlichen und vielfältigen GNU-Tools „screen“, das als freie Software eine effektivere Arbeit mit der Shell ermöglicht. IT-Strategie 26 Reihe SOA (Teil III): RESTful Web Services RESTful Web Services werden als Alternative zu den klassischen, auf SOAP basierenden Web Services, vorgestellt. Bei Spring AOP wird Kundenservice groß geschrieben Seite 12 Datenbanken 06 MS SQL Server 2008 New Features (Teil II): Datenauflistung - Ein Data Warehouse für den Administrator Mit der neuen Funktion „Datenauflistung“ können Performance-Indikatoren von SQLServer-Instanzen in einem zentralen Data Warehouse gesammelt und ausgewertet werden. 22 Oracle Objekttypen von A - Z (Teil IX): Ressourcen und andere Objekte In diesem Teil der Reihe stellen wir den Resource Manager sowie die Objekttypen Sequenz, Snapshot, Synonym, Tabelle und Trigger vor. 34 Oracle Enterprise Manager Grid Control (Teil VI): Standardisieren Sie Ihre individuelle Überwachung! Durch das Customizing von Standardmetriken reduzieren Sie die Alert-Flut auf für Sie interessante Meldungen. Java/JEE 12 Machen oder machen lassen, das ist hier die Frage: Bei Spring AOP wird Kundenservice groß geschrieben Einführung in die aspektorientierte Programmierung (AOP) unter Verwendung des Spring-Frameworks. 43 Eclipse-Kurzreferenz 4 ORDIX News 1/2009 Inhalt Reihe SOA (Teil III): RESTful Web Services Seite 26 Backup und Recovery mit NIM Seite 38 Betriebssysteme Aktuell 38 NIM, ein Tool zur Installation von Software, birgt einen unerwarteten Schatz: Backup und Recovery mit NIM Vorstellung der Eigenschaften des IBM AIX Network Installation Management (NIM) als Installations- und Backup-Lösung. Dabei werden die Aspekte von NIM als Installationswerkzeug für Betriebssysteme und Software beleuchtet und die Möglichkeiten für Backup und Recovery vorgestellt. Impressum Herausgeber: ORDIX AG Aktiengesellschaft für Softwareentwicklung, Beratung, Schulung und Systemintegration, Paderborn Redaktion: Sascia Brinkmann ViSdP: 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.800 Druck: Media-Print Informationstechnologie GmbH, Paderborn Bildnachweis: aboutpixel.de / Aral © snygo; flickr.com © Kyle Pearce; aboutpixel.de / 10 auf 79 © Arnim Schindler; flickr.com © skyseeker 17 Larry Ratlos: Datenselektion mit Hindernissen 46 DOAG Aktivitäten Konferenz und Schulungstag 2008 sowie Regionalgruppenleitung Rhein/Main Standards 03 Editorial 04 Inhalt 05 Impressum 24 Seminarübersicht: März bis Oktober 2009 Autoren dieser Ausgabe: Christof Amelunxen, Dr. Uwe Bechthold, Christian Fertsch, Stefanie Heither, Martin Hoermann, Andreas Jordan, Wolfgang Kögler, Roger Niemeyer, Ulf Papenfuß, Thomas Rohde, Michael Skowasch, Jens Stahl, 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. ORDIX® ist registrierte Marke der ORDIX AG. Die Zeitschrift ORDIX News wird von der ORDIX AG an ausgewählte 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://wwwordixde Schauen Sie mal rein! Der Kontakt zu unseren Lesern ist uns sehr wichtig. Für Anregungen, 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 redaktion@ordixde. ORDIX News 1/2009 5 Datenbanken MS SQL Server 2008 New Features (Teil II): Datenauflistung Ein Data Warehouse für den Administrator Dieser Artikel richtet sich an Administratoren von MS SQL Servern, die sich einen Überblick über die hinzugekommenen Funktionalitäten der neuen Version verschaffen möchten. Wie hat sich die CPU-Auslastung in der letzten Woche entwickelt? Welche Abfragen belasten den Server besonders? Diese typischen Fragen würde jeder Administrator gerne mit einem kurzen Blick auf seine Verwaltungsoberfläche beantworten können. Mit der neuen Funktion „Datenauflistung“ des SQL Servers 2008 ist dies nun möglich. Überblick Der Datenauflister Die Funktion „Datenauflistung“ (Data Collection) besteht im Wesentlichen aus den folgenden drei Komponenten: Der Datenauflister nutzt verschiedene Datenquellen, um die zu sammelnden Daten auf der lokalen SQL-Server-Instanz zu ermitteln. Als Datenquellen sind derzeit implementiert: • • • Dem Datenauflister (Data Collector), der die gewünschten Daten ermittelt. Dem Management Data Warehouse, das die gesammelten Daten speichert. Den Berichten, die die Daten übersichtlich und interaktiv anzeigen. Datenauflister und Data Warehouse können dabei auf getrennten Instanzen liegen, so dass alle Instanzen im Unternehmen ein zentrales Data Warehouse nutzen können. Die Einrichtung und Konfiguration erfolgt im SQL Server Management Studio im Unterpunkt „Verwaltung“ (siehe Abbildung 1). 6 ORDIX News 1/2009 • • • • T-SQL-Abfragen SQL-Ablaufverfolgung Abfrageaktivität Leistungsindikatoren Aus diesen Datenquellen können die zu sammelnden Informationen in einem Auflistsatz zusammengestellt werden. Dazu ist die Verwendung von T-SQL-Statements notwendig, da es hierfür aktuell keinen Assistenten im Management Studio gibt. Allerdings werden drei vorkonfigurierte Auflistsätze mitgeliefert, die mit einem Assistenten Datenbanken installiert werden können und die wichtigsten Performance-Daten des Servers sammeln: • • • Abfragestatistik: Hier werden Abfragen mit hohem Ressourcenverbrauch gesammelt, dazu Detailinformationen bis hin zu den genutzten Ausführungsplänen. Datenträgerverwendung: Hier werden für jede Datenbank die Größe und Verwendung der Daten- und Transaktionsprotokoll-Dateien gesammelt. Serveraktivität: Hier werden zum einen generelle Systemparameter, wie CPU- und Arbeitsspeicherauslastung, zum anderen spezielle SQL-Server-Parameter, wie die Anzahl und Verteilung von Wartevorgängen, gesammelt. Abb. 1: Die Funktion „Datenauflistung“ wird mit dem Management Studio verwaltet. Das Intervall der Datensammlung ist einstellbar. Gesteuert wird sie durch Aufträge im SQL-Server-Agenten. Das Management Data Warehouse Das Management Data Warehouse ist eine „normale“ relationale Datenbank, die auf einer beliebigen Instanz des SQL Server 2008 liegt. Alle für dieses Data Warehouse konfigurierten Datenauflister speichern dort die gesammelten Daten. Die Einrichtung kann ebenfalls mit einem Assistenten erfolgen. Die Berichte Für die drei vorkonfigurierten Auflistsätze werden interaktive Berichte im Stil der klassischen SQL-Server-Berichte im Management Studio, wie z. B. das Server-Dashboard, mitgeliefert. Abbildung 2 zeigt die Einstiegsseite des Berichts über die Serveraktivität. Mit einem Klick auf die einzelnen Grafiken können zusätzliche Details angezeigt werden. Natürlich sind alle Daten des Data Warehouse auch über SQL-Statements abrufbar. Die Tabellen mit den gesammelten Werten liegen im Schema snapshots. Fazit Die Funktion „Datenauflistung“ bietet eine einfach einzurichtende Möglichkeit, wichtige Performance-Daten zentral zu sammeln und so einen langfristigen Überblick über die Auslastung des Servers zu gewinnen. Abb. 2: Interaktive Berichte dienen als Einstiegspunkt zu den gesammelten Informationen, wie hier mit allgemeinen Informationen zur Serveraktivität. Link ►► [1] Film, in dem die Data Collection Funktionalität vorgestellt wird: http://edge.technet.com/Media/SQL-Server-2008-Data-Collection/ Andreas Jordan ([email protected]). ORDIX News 1/2009 7 Open Source Hochverfügbarkeit mit Heartbeat-Version 2 (Teil II) Immer noch verfügbar, Administrator? Dieser Artikel wendet sich an erfahrene Linux/Unix-Administratoren, die sich mit ClusterLösungen auseinander setzen oder einen kurzen Überblick über die Heartbeat-Implementierung bekommen möchten. Hochverfügbarkeit ist eines der häufig verwendeten Schlagwörter im Wortschatz von ORDIX und unserer Kunden. In der ORDIX News 2/2008 [1] haben wir bereits ein Kundenprojekt vorgestellt, in dem insgesamt drei Heartbeat Cluster für einen 7x24-Stunden-Betrieb einzurichten waren. Im ersten Teil berichteten wir über die zwei Cluster, auf denen verschiedene Web-Dienste hochverfügbar eingerichtet wurden. In diesem Teil geht es um den dritten Cluster, der vorwiegend als Hostsystem für VMware-Gäste und MySQL-Datenbanken verwendet wird. Administrator, was soll ich tun? Der dritte Cluster besteht aus insgesamt drei Cluster-Knoten, auf denen jeweils SuSE Linux Enterprise Server 10 SP1 mit Heartbeat in der Version 2.0.8 installiert ist. Heartbeat wurde in der Version 2 konfiguriert, denn nur hiermit ist es möglich, einen Cluster mit mehr als zwei Knoten zu erstellen. Die hochverfügbar ausgelegten Dienste auf diesem System sind MySQL, Samba und VMware-Gäste. Als gemeinsamer Speicher wurde für jede Ressource ein DRBD-Device erstellt (siehe ORDIX News 4/2008 [2]), so dass die Ressourcen unabhängig voneinander kontrolliert werden konnten. Die Nutzung von DRBD führte aber auch dazu, dass die Ressourcen immer nur auf 2 der 3 Knoten lauffähig waren. So mussten für jede Ressource Abhängigkeiten erstellt werden, wo definiert wird, auf welchem System die Ressource laufen darf. Die Konfiguration der Ressourcen wurde jeweils in XML-Dateien geschrieben und mit Kommandozeilenbefehlen auf den Cluster angewendet. Abbildung 1 bildet ein Beispiel für eine der verwendeten Abhängigkeiten ab. CIB, das Herz von Heartbeat 2 Richtet man Heartbeat in der Version 2 ein, werden alle Ressourcen mit Hilfe von XMLDateien konfiguriert. Der größte Vorteil gegenüber der alten Konfiguration ist, dass die 8 ORDIX News 1/2009 Änderungen auf jedem Knoten nach dem Einlesen der XML-Datei in den Cluster sofort zur Verfügung stehen. Ein Verteilen der Konfiguration und Neustarten der Dienste, wie es noch in Version 1 notwendig war, entfällt. Es gibt aber auch weiterhin die Konfigurationsdatei /etc/ha.d/ha.cf, in der die Konfiguration des Cluster Interconnect stattfindet. Hier ist nach Änderungen weiterhin ein Neustart der Dienste notwendig. Die in Abbildung 1 dargestellte Konfiguration zeigt, dass die Ressource Vmware1 nur auf den Knoten sles1 und sles2 laufen darf. Der Cluster wurde so konfiguriert, dass nur Ressourcen gestartet werden, solange zwei Knoten verfügbar sind und für die Ressource eine Location angegeben wurde. Dieses wurde mit den globalen Einstellungen name="symmetric-cluster" value="false" und name="no-quorumpolicy" value="stop" in der CIB festgelegt. Die Datei in Abbildung 1 wurde mit dem Befehl cibadmin -C -o constraints -x datei.xml auf die CIB angewendet. VMware - die Gäste treffen ein Um möglichst flexibel zu sein, wurde für jeden VMware-Gast ein eigenes DRBD-Device eingerichtet, so dass die Gäste auf unterschiedlichen Knoten laufen können. Die VMwareDienste /etc/init.d/vmware starten beim Booten der Cluster-Knoten automatisch. Nun Open Source musste eine Möglichkeit gefunden werden, wie die VMware-Gäste durch den Heartbeat Cluster gestartet, überwacht und gestoppt werden können. Dies wurde mit einem eigenen OCF-Skript namens vmware-gast rea­ lisiert. Diesem Skript werden vom Cluster die Argumente start, stop und monitor übergeben. Der VMware-Gastname wird mit Hilfe einer Umgebungsvariablen übergeben, so dass es nur ein Skript für alle Gäste gibt. Die Variable selbst wird durch den Cluster gesetzt. Mit Hilfe des Monitoring kann der Status des Gastes abgefragt werden. Mit den anderen beiden Parametern wird er vom Cluster gestartet bzw. gestoppt. In Abbildung 2 sind die verwendeten VMware-Befehle aus dem Skript dargestellt. Datenspeicherung mit DRBD Um bei einem Umzug der Ressourcen auf einen anderen Knoten die Daten sofort verfügbar zu haben, wurde die Open Source Software DRBD gewählt. Somit konnte auf teure Lösungen wie SAN oder Infiniband verzichtet werden. Da hier sehr viele DRBD-Devices gleichzeitig eingesetzt wurden, musste gewährleistet werden, dass die Netzwerkkarte nicht zum Flaschenhals wird. Um dies zu vermeiden, sind die Cluster-Systeme mit ausreichend Netzwerkkarten bestückt und die DRBD-Verbindungen auf die Karten verteilt. In den Cluster sind die DRBD-Devices als Master/Slave-Ressource eingebunden. Die auch als Multi-State bezeichneten Ressourcen sind Ressourcen, die entweder den Status Master oder Slave haben. Ein Master/Master-Status, wie es z. B. bei Cluster-Dateisystemen benötigt wird, ist in der aktuellen Heartbeat-Version noch nicht berücksichtigt. In Abbildung 3 ist die XML-Konfiguration einer DRBD-Master/Slave-Ressource dargestellt. Nach dieser Konfiguration läuft eine Master/ Slave-Ressource auf mehreren Knoten gleichzeitig (name="clone_max" value="2"). Auf jedem System läuft die Ressource maximal 1 Mal (name="clone_node_max" value="1") und es gibt nur einen Master (name="master_node_max" value="1"). Der Name des DRBD-Devices ist vmware1 und wird in der DRBD-Konfigura­tionsdatei /etc/drbd.conf festgelegt. Leider hat die Konfiguration der Master/Slave-Ressourcen auch einen Nachteil: Sie lassen sich nicht in einer Cluster-Ressourcengruppe anwenden, sondern können immer nur als „native“ Ressource konfiguriert werden. Während bei einer Ressourcengruppe eine implizite Reihenfolge beim Starten bzw. Stoppen der Ressourcen <constraints> <rsc_location id="location_Vmware1" rsc="resource_Vmware1"> <rule id="prefered_location_Vmware1" score="100" boolean_op="or"> <expression attribute="#uname" operation="eq" value="sles1"/> <expression attribute="#uname" operation="eq" value="sles2"/> </rule> </rsc_location> </constraints> Abb. 1: Abhängigkeit, die Ressourcen nur auf einem bestimmten Knoten starten lässt. starten: /usr/bin/vmware-cmd /vmware/configs/Vmware1.vmx start stoppen: /usr/bin/vmware-cmd /vmware/configs/Vmware1.vmx stop monitor: /usr/bin/vmware-cmd /vmware/configs/Vmware1.vmx getstate Abb. 2: Befehle aus dem OCF-Startskript, um VMware-Gäste zu starten, zu stoppen und zu überwachen. <master_slave id="DRBD1"> <meta_attributes id="DRBD1_meta_attrs"> <attributes> <nvpair id="DRBD1_metaattr_clone_max" name="clone_max" value="2"/> <nvpair id="DRBD1_metaattr_clone_node_max" name="clone_node_max" value="1"/> <nvpair id="DRBD1_metaattr_master_max" name="master_max" value="1"/> <nvpair id="DRBD1_metaattr_master_node_max" name="master_node_max" value="1"/> <nvpair id="DRBD1_metaattr_notify" name="notify" value="true"/> <nvpair id="DRBD1_metaattr_globally_unique" name="globally_unique" value="false"/> </attributes> </meta_attributes> <primitive id="DRBD_CLONE1" class="ocf" type="drbd" provider="heartbeat"> <instance_attributes id="DRBD_CLONE1_instance_attrs"> <attributes> <nvpair name="drbd_resource" value="vmware1"/> </attributes> </instance_attributes> <meta_attributes id="DRBD_CLONE1:0_meta_attrs"> <attributes> <nvpair id="DRBD_CLONE1:0_metaattr_target_role" name="target_role" value="started"/> </attributes> </meta_attributes> </primitive> </master_slave> Abb. 3: Aufbau einer Master/Slave-Ressource. besteht, müsste diese bei nativen Ressourcen explizit angegeben werden, was bei einem größeren Cluster zu zusätzlichen Konfiguratio­ nen von Abhängigkeiten führt. ORDIX News 1/2009 9 Open Source STONITH Da bei diesem VMware-Cluster sehr viel mit gesharten Dateisystemen gearbeitet wird, be­­steht immer die Gefahr von Korruption bei einem Split-Brain-Zustand. Hier bieten ClusterHersteller unterschiedliche Arten des Korruptionsschutzes an. Unter Linux gibt es das so genannte STONITH (Shot the other node in the head). Hierzu werden schaltbare Steckdo- <clone id="STONITH_SLES1"> <instance_attributes> <attributes> <nvpair name="clone_max" value="2"/> <nvpair name="clone_node_max" value="1"/> </attributes> </instance_attributes> <primitive id="child_do_fencing_sles1" class="stonith" type="apcmaster"> <operations> <op name="monitor" interval="10s" timeout="30s" prereq="nothing"/> <op name="start" timeout="20s" prereq="nothing"/> </operations> <instance_attributes> <attributes> <nvpair id="STONITH_ip_SLES1" name="ipaddr" value="10.10.10.10"/> <nvpair id="STONITH_user_SLES1" name="login" value="sles1"/> <nvpair id="STONITH_pass_SLES1" name="passwd" value="sles1pw"/> </attributes> </instance_attributes> </primitive> </clone> Abb. 4: XML-Datei für ein STONITH Device. MEM_FREE=$(grep MemFree /proc/meminfo | awk ‚{ print $2 }‘); /usr/sbin/attrd_updater -n mem_free -v ${MEM_FREE} Abb. 5: Cron-Job, der den freien Arbeitsspeicher alle 5 Minuten ausliest und in die CIB schreibt. <constraints> <rsc_location id="location_Vmware1" rsc="resource_Vmware1"> <rule id="prefered_location_Vmware1" score="100"> <expression attribute="mem_free" operation="gte" value="2000000" type="number"/> </rule> </rsc_location> </constraints> Abb. 6: Starten einer Ressource nur auf einem Knoten mit genug freiem Arbeitsspeicher. 10 ORDIX News 1/2009 senleisten angeschlossen, mit deren Hilfe der eine Cluster-Knoten in einer Split-Brain-Situation den anderen stromlos schalten kann. Unter Heartbeat Version 2 kann die STONITH-Konfiguration auf zwei Arten gelöst werden: 1. Wie in der Version 1 üblich, über einen Eintrag in der Datei /etc/ha.d/ha.cf. 2. Mit Hilfe der XML-Konfiguration. Hier wurde die modernere Variante gewählt, in der die Ressource als so genannter „Clone“ konfiguriert wird. Ein Clone ist eine Ressource, die n-Mal innerhalb des Clusters läuft. Voraussetzung ist, dass in den globalen Einstellungen der Schalter name="stonith-enabled" value="true" aktiviert wurde. Auch ein Clone hat den Nachteil, dass er nicht innerhalb einer Ressourcengruppe konfiguriert werden kann. In Abbildung 4 ist die Konfiguration des STONITH Clones dargestellt. Aber bitte nicht den Cluster lahm legen Lässt man den Cluster beim Starten der VMware-Gäste entscheiden, auf welchem Knoten der Gast gestartet wird, ist dies vergleichbar mit Russischem Roulette. Normalerweise verteilt der Cluster die Ressourcen gleichmäßig auf die Cluster-Knoten. Dies wäre bei einer Apache- oder FTP-Ressource kein Problem, da diese normalerweise sowieso nur 1-mal auf einem Knoten laufen. Bei diesem Cluster ist es aber gewünscht, dass auch mehrere VMwareGäste auf demselben Knoten laufen. Da diesen aber unterschiedliche Mengen an Arbeitsspeicher zugewiesen werden, besteht die Gefahr, dass die VMware-Gäste einen Cluster-Knoten lahm legen. Hier bietet Heartbeat die Möglichkeit, dynamisch zu entscheiden, auf welchem Knoten eine Ressource gestartet werden soll. Dies kann z. B. mit Hilfe der mitgelieferten Ressource „SysInfo“ geschehen. SysInfo wird als Clone auf allen beteiligten Knoten gestartet und schreibt regelmäßig die aktuellen Werte von Arbeitsspeicherauslastung, SwapAuslastung etc. in die CIB. Leider waren die übermittelten Werte in der eingesetzten Heartbeat-Version nicht sehr zuverlässig, so dass auf dieses Verfahren verzichtet wurde. Heartbeat bietet aber auch die Möglichkeit, eigene Daten in die CIB zu schreiben. Mit Hilfe des in Abbildung 5 gezeigten Cron-Jobs wurde der aktuelle freie Arbeitsspeicher alle 5 Minuten ausgelesen und in die CIB eingetragen. Die Information findet sich dann in den Statusinformationen des entsprechenden Hosts. Open Source Abbildung 6 zeigt, wie die geschriebenen Informationen dann ausgewertet werden. In diesem Beispiel wird Vmware1 auf einem Knoten gestartet, der mindestens 2 GB Arbeitsspeicher frei hat. Bei der hier beschriebenen Implementierung wurde der Arbeitsspeicherverbrauch des Gastes vor dessen Starten per Skript aus der VMware-Konfigurationsdatei ausgelesen und dynamisch in value eingetragen. <cluster_property_set id="every_sunday" score="100"> <rule id="my_vmware1:failover" boolean_op="and"> <date_expression id="my_vmware1:days" operation="date_spec"> <date_spec id="my_vmware1:days" weekdays="7"/> </date_expression> </rule> </cluster_property_set> Abb. 7: Regeln, um Ressourcen an bestimmten Tagen auf einen Knoten zu schalten. Immer wieder sonntags Während der Implementierungsphase des Clusters kam der Wunsch des Kunden auf, zu bestimmen, dass eine Ressource sonntags immer auf einem bestimmten Cluster-Knoten laufen soll. Auch dies ist mit Heartbeat ClusterBordmitteln durchführbar. Zum einen gibt es die Möglichkeit, eine Ressource per CronJob auf einen bestimmten Knoten zu switchen (crm_resource -M -r Vmware1 -f -H sles1). Heartbeat bietet aber auch selbst die Möglichkeit, per Location-Regel zeitbasierte Regeln festzulegen. In Abbildung 7 ist ein Beispiel der eingesetzten Regeln abgebildet. Zu beachten ist hierbei, dass die zeitbasierten Regeln nicht mit jeder Heartbeat-Version funktio­ nieren. Glossar CIB Cluster Information Base. XML Cluster-Konfiguration, die automatisch auf alle Cluster-Knoten repliziert wird. OCF Open Cluster Framework. Definition von Standardzugriffschnittstellen des Heartbeat Cluster. Split-Brain Zustand, bei dem alle Verbindungsleitungen zwischen den ClusterKnoten unterbrochen sind. Heartbeat Name einer Hochverfügbarkeitslösung aus dem Open Source Umfeld, aber auch Bezeichnung für eine private Leitung zwischen Cluster-Knoten, mit deren Hilfe geprüft wird, ob die anderen Knoten noch „leben“. STONITH Kurz für „Shoot the other node in the head“. Eine Möglichkeit, mit der man verhindert, dass zwei oder mehr Systeme schreibend auf ein Dateisystem oder auch eine Datenbank zugreifen. Fencing (abzäunen, ausgrenzen) Falls der Cluster keine Informationen mehr über seine Partnerknoten bekommt, also z. B. die Heartbeat-Leitungen zerstört sind, tritt das Fencing ein. Es eröffnet verschiedene Lösungen, um mögliche Schäden zu verhindern wie z. B. STONITH, Self-Fencing RAID Controller, Abschalten des FibreChannel Ports und SCSI3 Reservierungen. MySQL und Samba Die Konfiguration der Ressourcen MySQL und Samba wurde im Verhältnis zur VMwareKonfiguration zur Nebensache. Die MySQLDatenbanken wurden auf ein DRBD-Device verlagert. Dessen Dateisystem wird auf einem Knoten eingebunden und danach der MySQLDienst gestartet. Bei Samba wurde ähnlich vorgegangen, mit dem kleinen Unterschied, dass hierbei während der Laufzeit Statusinformationen anfallen, z. B. welche Clients gerade mit einem Share verbunden sind. Hier wurde dafür gesorgt, dass die Statusinformationen auf dem DRBD-Device abgelegt werden und auf den Cluster-Knoten jeweils per symbolischen Links auf das DRBD-Device verwiesen wird. Alternativ gibt es hier auch wieder eine Open Source Software-Lösung namens drbdlinks, die für eine dynamische Verlinkung beim Aktivieren der Ressourcen sorgt. Fazit Während dieses Kundenprojektes hat sich wieder einmal gezeigt, wie flexibel sich die Heartbeat-Cluster-Lösung einsetzen lässt. Wird mal ein Skript nicht mitgeliefert, kann sehr schnell ein eigenes Skript eingebunden Links ►► [1] ORDIX News Artikel „Sind wir verfügbar, Administrator?“ http://www.ordix.de/ORDIXNews/2_2008/Open_Source/heartbeat2.html ►► [2] ORDIX News Artikel „Keine Angst vor Split-Brain!“ http://www.ordix.de/ORDIXNews/4_2008/Betriebssysteme/OCFS_DRBD.html ►► [3] Homepage des Heartbeat Projektes: http://www.linux-ha.org/ ►► [4] Homepage des DRBD Projektes: http://www.drbd.org/ werden. Auch die Zusammenarbeit mit anderen Open Source Tools ist beliebig kombinierbar. In neueren Versionen hat sich auch der SysInfo-Ressourcenagent als zuverlässiger erwiesen. Und in zukünftigen Versionen werden uns die Heartbeat-Entwickler bestimmt mit weiteren, neuen Funktionen überraschen. Schon in einer der nächsten ORDIX News möchten wir von fortgeschrittenen HeartbeatEigenschaften berichten, wie z. B. dem Aufbau von OCF-Ressourcenskripten oder die ScoreBerechnung innerhalb des Cluster. Christian Fertsch ([email protected]). ORDIX News 1/2009 11 Java/JEE Machen oder machen lassen, das ist hier die Frage Bei Spring AOP wird Kundenservice groß geschrieben Dieser Artikel richtet sich an Java-Entwickler und Architekten, die einen schnellen Einstieg in die aspektorientierte Programmierung mit dem SpringFramework erhalten möchten. Die Verbreitung des Spring-Frameworks ist mittlerweile stark fortgeschritten Neben der Dependency Injection (DI) stellt das aspektorientierte Programmiermodell (AOP) eine fundamentale Säule dar, deren Funktionsprinzip und Einsatzmöglichkeiten in diesem Artikel näher vorgestellt werden Einleitung Die wesentliche Aufgabe der Softwareentwicklung besteht in der Umsetzung der Geschäftslogik. Leider ist es damit nicht getan. Als Entwickler muss man sich natürlich auch um Dinge wie Logging, Security und Transaktionsmanagement kümmern. 12 ORDIX News 1/2009 Hier wurde man bei der Entwicklung bisher dazu gezwungen, in seine wunderschön implementierte Geschäftslogik solche technischen Aspekte (auch: Cross Cutting Concerns – CCC) einzubauen. Diese Aspekte wiederholen sich nicht nur ständig, sondern blähen auch den mühevoll geschriebenen Quellcode Ihrer Geschäftslogik ganz schön auf. Java/JEE Wäre es da nicht viel angenehmer, man könnte diese Aufgaben von einer anderen, unabhängigen Komponente erledigen lassen, die speziell dafür entwickelt wurde, die­ se beiden Bereiche sauber voneinander zu trennen? public class Auto { private int tankinhalt = 50; public void fahren() { this.tankinhalt -= 40; System.out.println("Auto faehrt"); } public void oeffneTankdeckel() { System.out.println(" - Tankdeckel oeffnen"); } public void schliesseTankdeckel() { System.out.println(" - Tankdeckel schliessen"); } public void betanken(int fuellmenge) { this.tankinhalt += fuellmenge; System.out.println(" - Auto wird betankt"); } public int getTankinhalt() { return this.tankinhalt; } } Tankstelle mit Kundeservice Stellen Sie sich vor, Sie sind mit Ihrem Auto unterwegs und fahren zum Tanken an die Tankstelle. Bevor Sie das Auto betanken können, müssen Sie den Tankdeckel öffnen. Ansonsten geht der ganze teure Treibstoff daneben. Nach dem Tankvorgang muss der Tankdeckel wieder geschlossen werden. Abbildung 1 zeigt eine Klasse Auto. Es kann fahren, betankt werden und bietet Funktionalitäten zum Öffnen und Schließen des Tankdeckels. Abb. 1: Die Klasse Auto kann fahren, betankt werden und bietet Funktionalität für den Tankdeckel. Die Tankstelle ist in Abbildung 2 dargestellt. Sie kann das Auto mit der angegebenen Füllmenge betanken. Was jetzt noch fehlt, ist das Öffnen und Schließen des Tankdeckels. Bisher müssen sie das selbst tun. public class Tankstelle { Wäre es aber nicht sehr praktisch, wenn man sich um diese technischen Dinge gar nicht selbst kümmern müsste? Wie würde es Ihnen gefallen, wenn Sie an die Zapfsäule fahren und der Tankwart für Sie diese Aufgabe übernimmt? (Wer hat eigentlich das SB-Tanken erfunden? ☺) Auch in Ihrer Software brauchen Sie sich zukünftig nicht mehr um das Öffnen und Schließen des Tankdeckels kümmern. Mit AOP können Sie diese Aufgabe auch an einen Tankwart delegieren. Dazu brauchen Sie nur noch jemanden, der diesen darüber in Kenntnis setzt, dass Sie gerade an einer Zapfsäule vorgefahren sind. public void autoBetanken(Auto auto, int fuellmenge) { auto.betanken(fuellmenge); } } Abb. 2: Die Tankstelle kann ein Auto betanken, indem der Treibstoff eingefüllt wird. • Joinpoint Ein Joinpoint ist im Wesentlichen keine technische Komponente, sondern definiert einen Punkt im gewöhnlichen Programm­ ablauf, an dem ein Aspekt eingebunden werden kann, wie z. B. das Vorfahren mit dem PKW an eine Zapfsäule. • Pointcut Ein Pointcut ist derjenige, der die Anwendung kontrolliert und überwacht, wann ein Advice aufgerufen werden soll. Normalerweise wird dies über den Namen von Methoden und Klassen realisiert, die mit Hilfe von regulären Ausdrücken definiert werden. Der Kassierer ist in diesem Fall der Pointcut. Er würde dem Tankwart Bescheid geben, sobald Sie vorgefahren sind. Begriffsdefinitionen In der Welt von AOP haben sich einige Begriffe etabliert, deren Bedeutung wir unbedingt klären müssen, bevor wir richtig loslegen können: • Advice Ein Advice ist der konkrete Tankwart, der gerufen wird, wenn Sie vorfahren. Er weiß genau, was zu tun ist und wann es zu tun ist. Also vor und/oder nach dem Ausführen der eigentlichen Zielmethode. Z. B. kann er den Tankdeckel öffnen und schließen. ORDIX News 1/2009 13 Java/JEE • Advisor Ein Advisor ist diejenige Komponente, die alles zusammenbringt. Sie verknüpft einen Advice und einen Pointcut miteinander, um den entsprechenden Aspekt ausführen zu können. • Weaving Als Weaving bezeichnet man das Herstellen der Verbindung zwischen einem Aspekt und der eigentlichen Zielmethode. Spring realisiert das „Einweben“ zur Laufzeit durch die Generierung eines dynamischen Proxy­Objekts. Es ist daher weder ein Weaving Compiler noch ein spezieller Classloader erforderlich. Advices auf dem Prüfstand public class Tankwart implements MethodInterceptor { @Override public Object invoke(MethodInvocation invocation) throws Throwable { Spring AOP liefert für unterschiedliche Anforderungen verschiedene Advices. Schauen wir uns die wichtigsten an: • MethodBeforeAdvice Ein MethodBeforeAdvive wird aufgerufen, bevor die eigentliche Zielmethode ausgeführt wird. Mit diesem Advice können Sie den Tankdeckel öffnen lassen. Für das Schließen sind Sie dann aber selbst zuständig. • AfterReturningAdvice Ein AfterReturningAdvice leistet seine Dienste, nachdem der Aufruf der Zielmethode beendet ist. Er kann also nur den Tankdeckel schließen. Abb. 3: Der Tankwart ist ein MethodInterceptor und implementiert die InvokeMethode. • ThrowsAdvice Ein ThrowsAdvice wird aufgerufen, nachdem die Zielmethode eine Ausnahme ausgelöst hat, z. B. wenn während des Tankens der Treibstofftank der Tankstelle leer geworden ist oder Sie Benzin anstelle von Diesel tanken wollen. ApplicationContext appCtx = new ClassPathXmlApplicationContext("applicationContext.xml"); • MethodInterceptor Etwas allgemeingültiger ist die Implementierung des MethodInterceptor-Interfaces der AOP-Alliance: Der AroundAdvice. Dieser wird zunächst vor dem Aufruf der Zielmethode aufgerufen und ist dann für die Ausführung der Zielmethode zuständig. Damit können zusätzliche Funktionalitäten sowohl vor als auch nach dem Zielmethodenaufruf eingebunden werden. Für unser Tankstellen-Szenario wäre das die passende Lösung. Object result = null; System.out.println(" Tankwart tritt heran"); Auto auto = (Auto) invocation.getThis(); auto.oeffneTankdeckel(); result = invocation.proceed(); auto.schliesseTankdeckel(); System.out.println(" Tankwart ist fertig"); return result; } } Auto auto = (Auto) appCtx.getBean("auto"); Tankstelle tankstelle = (Tankstelle) appCtx.getBean("tankstelle"); System.out.println("Tankinhalt: " + auto.getTankinhalt() + " l"); auto.fahren(); System.out.println("Tankinhalt: " + auto.getTankinhalt() + " l"); // auto.oeffneTankdeckel(); mit AOP nicht erforderlich tankstelle.autoBetanken(auto, 40); // auto.schliesseTankdeckel(); mit AOP nicht erforderlich System.out.println("Tankinhalt: " + auto.getTankinhalt() + " l"); auto.fahren(); Abb. 4: Der Aufruf im Programm geschieht über den ApplicationContext. 14 ORDIX News 1/2009 Sehen Sie sich in der Abbildung 3 den Tankwart an. Er implementiert das Interface MethodInterceptor. Die Invoke-Methode wird aufgerufen, wenn Sie an der Tankstelle vorfahren. Über den Parameter vom Typ Method­ Invocation haben Sie alle Informationen, die für die Zielmethode relevant sind. Über Java/JEE invocation.getThis() holen wir uns zunächst das Objekt Auto, das betankt werden soll. Nun wird der Tankdeckel geöffnet und danach die Zielmethode mit invocation. proceed() aufgerufen. Nun kann der Tankdeckel wieder geschlossen werden und der Tankwart verabschiedet sich von Ihnen. Mit invocation.getArguments() könnten Sie an dieser Stelle auch auf die Übergabeparameter der Zielmethode zugreifen und diese bei Bedarf sogar vorher verändern. Pointcuts Stellen Sie sich einen Pointcut als Kassierer vor, der einen Überblick über die Tankstelle hat. Allerdings ist die Tankstelle in zwei Bereiche geteilt. Einen SB-Tankbereich, den braucht der Kassierer nicht einsehen und einen Servicebereich, wo Sie von einem Tankwart bedient werden. Fahren Sie nun mit Ihrem PKW im Servicebereich an einer Zapfsäule vor, gibt er einem Tankwart Bescheid, dass dieser Sie bedienen kann. Fahren Sie im SB-Bereich vor, geschieht nichts. Sie sehen also, dass so ein Pointcut eine wesentliche Aufgabe hat. Bei Spring sorgt er dafür, dass ein Tankwart überhaupt etwas zu tun bekommt. Dieser wird in der Spring-Konfiguration definiert. Man arbeitet hier im Wesentlichen mit regulären Ausdrücken, die auf den Aufruf bestimmter Klassen und Methoden zugeschnitten werden. Abbildung 4 zeigt die gesamte Spring-Konfiguration. Dort finden Sie neben dem Tankwart, der hier zunächst eine ganz gewöhnliche Spring-Bean ist, auch den Kassierer-Pointcut. Er überwacht die Ausführung der Methode betanken() der Klasse Auto. Der Advisor darunter fügt nun beide Elemente zusammen und verknüpft sie fest miteinander. Damit weiß der Poincut, (im übertragenen Sinne) wem er Bescheid geben soll, wenn Sie an der Zapfsäule vorfahren. Den gesamten Programmaufruf zeigt Abbildung 5. Zunächst wird mit dem Auto gefahren. Jede Fahrt benötigt hier 40 Liter Kraftstoff. Danach wird der Tankinhalt ausgegeben und das Auto wird an der Tankstelle betankt. Ohne den Einsatz von AOP müssten Sie nun zunächst den Tankdeckel öffnen und nachher wieder schließen (siehe Kommentare im Code). <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/ spring-beans-2.0.xsd"> <bean id="auto" class="de.ordix.on.spring.aop.Auto" /> <bean id="tankstelle" class="de.ordix.on.spring.aop. Tankstelle" /> <!-- Advice --> <bean id="tankwart" class="de.ordix.on.spring.aop. Tankwart" /> <!-- Poincut --> <bean id="kassiererPointcut" class="org.springframework. aop.aspectj.AspectJExpressionPointcut"> <property name="expression" value="execution(* de.ordix.on.spring.aop.Auto.betanken(..))" /> </bean> <!-- Advisor --> <bean name="advisor" class="org.springframework.aop. support.DefaultPointcutAdvisor"> <property name="advice" ref="tankwart"/> <property name="pointcut" ref="kassiererPointcut"/> </bean> <!-- Proxy-Generator --> <bean class="org.springframework.aop.framework.autoproxy. DefaultAdvisorAutoProxyCreator" /> </beans> Abb. 5: In der Spring-Konfiguration werden Poincut und Advice konfiguriert. AOP via Proxy In Spring wird AOP via Proxies realisiert. Das bedeutet, dass bei der Erstellung der SpringBeans, zu denen ein Aspekt konfiguriert ist, eine Subklasse der Zielklasse erzeugt wird. Das geschieht entweder über die Klasse java.lang.reflect.Proxy des JDK oder mittels der Library CGLIB. Der Proxy kapselt damit den Aufruf der Zielmethode und schaltet sich vor deren Aufruf ein. Somit besteht die Möglichkeit, jeweils vor und/oder nach Aufruf des Ziels weiteren Programmcode auszuführen. Der AOP-Namespace von Spring Damit das Konfigurieren der Aspekte in Spring nicht zur Lebensaufgabe wird, stellt das Spring-Framwork einen speziellen XML- ORDIX News 1/2009 15 Java/JEE <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop" xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/ spring-beans-2.0.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/ spring-aop-2.0.xsd"> <!-- --> Auto, Tankstelle und Tankwart werden wie vorher auch konfiguriert (Fehlt in dieser verkürzten Darstellung) <!-- Pointcut und Advisor zusammen --> <aop:config> <aop:pointcut id="tankPoincut" type="aspectj" expression="execution(* de.ordix.on.spring.aop.Tankstelle.betanken(..))"/> <aop:advisor pointcut-ref="tankPoincut" advice-ref="tankwart"/> </aop:config> </beans> Abb. 6: Mit dem AOP-Namespace wird es schon gleich viel übersichtlicher. Glossar Aspektorientierte Programmierung (AOP) AOP ist ein Programmiermodell zur Ausführung von Programmcode unter Verwendung konfigurierbarer Aspekte, die sich in den „normalen“ Programmcode einbinden lassen. Dependency Injection (DI) Dependency Injection bezeichnet die Möglichkeit, Abhängigkeiten von Beans zu anderen Beans zu injizieren. Bei Spring geschieht dies über eine konfigurierbare Bean Factory. Cross Cutting Concerns (CCC) Funktionen, die sich über mehrere Punkte der Anwendung erstrecken. AOP-Alliance Die AOP-Alliance beschäftigt sich mit der Vereinfachung und der Entwicklung von Standards im AOP-Umfeld. Links ►► [1] Entwicklung und Host des Spring-Frameworks: http://www.springsource.com ►► [2] AOP-Alliance: http://aopalliance.sourceforge.net ►► [3] Download Tankstellen-Beispiel: Namespace für AOP bereit. Dieser muss natürlich zunächst im Header der XML-Konfiguration eingebunden werden. Danach kann er verwendet werden. Abbildung 6 zeigt, wie die gleiche Konfiguration mit diesem Namespace verwendet werden kann. Ihnen wird direkt auffallen, dass wir nun viel weniger überflüssigen Code haben und das Ganze ein wenig übersichtlicher aussieht. Hier können Sie direkt den Pointcut und den Advisor in einem einzigen XML-Tag definieren und auch den DefaultAdvisorAutoProxyCreator müssen Sie nicht mehr einbinden (siehe Abbildung 5). Einsatzbereiche Aus Sicht Ihrer Anwendung werden Sie wahrscheinlich nicht häufig das Bedürfnis haben, ein Auto zu betanken. Das sollte hier auch nur als Beispiel dienen. In der Praxis werden Sie über AOP wahrscheinlich eher technische Dinge abwickeln, wie beispielsweise Logging, Security oder Tranksaktionsmanagement. Auch ist es hierdurch relativ einfach, eine Software hinsichtlich ihrer Performance zu untersuchen. Sie könnten sich dafür einen Performance-Monitor bauen, der vor dem Aufruf einer Methode, die vielleicht eine komplexe Datenbankabfrage durchführt, die Zeit festhält und anschließend die Dauer des Zielmethodenaufrufs berechnet. Damit ist es ohne Quellcodeänderungen möglich, für Performance-Tests einfach eine entsprechende Spring-Konfiguration zu verwenden und Performance-Daten zu sammeln. Diese können im Anschluss ausgewertet werden. Fazit Neben der Dependency Injection ist das AOPFramework eine wesentliche Komponente von Spring. Es besteht nicht nur die Möglichkeit, AOP für seine eigenen Zwecke zu verwenden, sondern die umfangreiche APIAbstraktion (z. B. für JDBC, Hibernate, Transaktionsmanagement etc.) basiert ebenfalls auf diesem Prinzip und lässt sich daher sehr komfortabel in den bestehenden Programmcode integrieren. Das Tankstellen-Beispiel können Sie übrigens im Internet [3] herunterladen. http://www.ordix.de/ORDIXNews/1_2009/Java_JEE/tankstellenbeispiel.zip Thomas Rohde ([email protected]). 16 ORDIX News 1/2009 Aktuell Larry Ratlos: Datenselektion mit Hindernissen Larry Ratlos versteht die Welt nicht mehr Da steht er vor einer seiner alltäglichen Aufgaben und plötzlich funktioniert der Select, den er bisher immer erfolgreich verwendet hat, nicht mehr Und es ist nicht der 1 April, so dass er davon ausgehen kann, dass es nicht am Humor der Datenbank oder eines Kollegen liegen kann Auf einer DB-Instanz schlägt folgender select fehl: SQL> select * from tab_xy where col_z=12345; select * from tab_xy where col_z=12345 * FEHLER in Zeile 1: ORA-01722: invalid number Die Spalte ist vom Typ varchar2(30): SQL> desc tab_xy Name Null? Typ ------------------ --------- --------------------------KV_ID_EXT NOT NULL VARCHAR2(30) ... Können Sie Larry helfen? Larry ist ratlos, weil diese Abfrage bisher immer funktionierte. Und die Informationen, die er über die Datenbank bekommt, helfen ihm so zunächst auch nicht weiter. Was kann der Grund sein, dass die Abfrage zu einem Fehler führt? Und was ist zu tun, damit Larry doch das gewünschte Ergebnis bekommt? Schicken Sie Ihren Lösungsvorschlag und Ihre Begründung bis zum 9 April 2009 an kniffel@ordixde. Lösung der Aufgabe aus 4/2008 In der letzten ORDIX News hatte Larry Probleme mit der Dateisystemerweiterung in Solaris 10. Das bestehende 984 GB große Dateisystem sollte um zusätzliche 400 GB erweitert werden. Bei dem Versuch bekam Larry aber immer eine Fehlermeldung. Wie sich herausstellte, war Larrys Fehler folgender: Wenn beim Erstellen des Dateisystems die Standardoptionen beim newfs-Befehl verwendet werden, kann das Dateisystem nur 1 Terabyte groß werden. Wichtig wäre schon beim Anlegen die Option -T, also newfs -T gewesen. Nur so können Dateisysteme größer als 1 Terabyte werden. Auf einen Nachteil bei diesem Vorgehen ist Larry aber auch gestoßen: Wenn man jetzt nur sehr kleine Dateien auf dem Dateisystem anlegt, gehen schnell die Inodes aus, da bei der Option -T für jedes Megabyte ein Inode reserviert wird. ORDIX News 1/2009 17 Open Source Open Source Reporting mit BIRT Dieser Artikel richtet sich an Entscheider und Entwickler, die ein kostenloses Werkzeug zur Erstellung von Berichten suchen. Die Datenmenge steigt in vielen Unternehmen stetig an. Die Daten werden zwar archiviert und verwaltet, doch fällt es Unternehmen oft schwer, aus dieser Datenflut wertvolle Informationen zu gewinnen, um die Entscheidungsprozesse im Unternehmen zu unterstützen. Damit entgeht vielen Unternehmen ein entscheidender Wettbewerbsvorteil gegenüber der Konkurrenz. BIRT ist ein kostenloses Open Source Tool, das dieses Problem lösen soll und für Unternehmen eine Alternative zu kommerziellen Produkten von SAP, IBM oder Oracle bietet. Da auch die ORDIX AG seit einiger Zeit BIRT als Werkzeug für interne Berichte nutzt, ist es an der Zeit, Ihnen BIRT vorzustellen. Was ist BIRT? BIRT steht für Business Intelligence and Reporting Tools. Es ist ein von Actuate initiiertes Subprojekt von Eclipse, mit dem sich Berichte (Reports) in den Formaten HTML, PDF, XLS und CSV erstellen lassen. BIRT steht unter der Eclipse Public License. Die aktuelle Version ist 2.3.1. Um einen Report zu erstellen, muss zunächst eine Verbindung zu einer Datenquelle, z. B. zu einem Data Warehouse, hergestellt werden. Danach kann der Report mit Hilfe des BIRT Report Designers erstellt werden. Der fertige Report lässt sich in alle gängigen Servlet Engines integrieren. Datenquellen Als Datenquellen unterstützt BIRT sämtliche Datenbanken, die sich mit JDBC anbinden lassen, sowie XML-Dateien, Web Services, JavaBeans und eine große Auswahl an Flachdateien (z. B. CSV). Außer der Möglichkeit, SQL-Abfragen einzugeben, unterstützt BIRT auch Stored Procedures. BIRT kann innerhalb eines Reports mit beliebig vielen Datenquellen arbeiten. Den Abfragen lassen sich Parameter hinzufügen, was auch dynamische Abfragen ermöglicht. Die Datenbankverbindungen lassen sich zur Wiederverwendung zentral in einer Bibliothek speichern und für weitere Reports importieren. Seit kurzem un- 18 ORDIX News 1/2009 terstützt BIRT auch die Erstellung von OLAPCubes. Berichtsgestaltung Als Tool zur Gestaltung von Berichten stellt BIRT einen Report Designer zur Verfügung. Der Report Designer (siehe Abbildung 1) ist ein WYSIWYG-Editor, mit dessen Hilfe sich Report-Elemente per Drag&Drop auf einer Arbeitsfläche positionieren lassen. Die Po­ si­tionierung erfolgt mittels Tabellen (Grids), was eine pixelgenaue Darstellung sehr umständlich macht. Allerdings unterstützt BIRT ein sehr genaues Seitenumbruchverhalten. Für die Formatierung der Berichte können in BIRT eigene Stile angelegt werden und sogar komplette CSS-Dateien importiert werden. Die verschiedenen Stile können wie die Datenbankverbindungen in eine Bibliothek exportiert werden und sind somit auch für andere Reports nutzbar. Charts Die Erstellung von Diagrammen erfolgt mit Hilfe des BIRT Chart Designers (siehe Abbildung 2). Der Chart Designer ist dank seiner Drag&Drop-Unterstützung und Wizzard sehr leicht zu bedienen. Zur Zeit unterstützt BIRT 13 verschiedene Diagrammtypen z. B. Open Source Balken-, Linien- und Tortendiagramme. Die Daten können innerhalb der Grafik nochmals gefiltert, sortiert und gruppiert werden. Außerdem unterstützt BIRT eine Live-Ansicht des Diagramms während der Report-Erstellung. Dynamische Elemente Oft kann es nützlich sein, dass ein Report je nach gelieferten Werten seine Formatierung dynamisch ändert, z. B. um Umsatzgewinne und Umsatzverluste farblich zu unterscheiden oder um das Seitenumbruchverhalten dynamisch zu steuern. Für die Generierung von dynamischen Elementen setzt BIRT ein eigenes Event-Modell ein. Mit Hilfe der Scriptsprache Mozilla RhinoScript oder der Programmiersprache Java lassen sich eigene Event­handler schreiben (siehe Abbildung 3). Integration Abb. 1: Der Report Designer. Die mit dem BIRT Report Designer erzeugten Beichte lassen sich in alle gängigen ServletEngines (z. B. Apache Tomcat) integrieren. Um einen Report in den Apache Tomcat zu integrieren, muss nur der BIRT Viewer in den Webapps-Ordner des Tomcat kopiert werden. Anschließend kopiert man die Report-Datei (*.rptdesign) in den BIRT Viewer. Danach ist der Report über die entsprechende URL aufrufbar. Eine genauere Anleitung zur Integration von Berichten finden Sie unter [1]. Dokumentation Die Dokumentation von BIRT ist mittlerweile recht gut. Neben der Homepage [2] und den beiden Fachbüchern „BIRT - A Field Guide for Reporting“ [3] und „Integrating and Extending BIRT“ [4] ist besonders die Webseite der BIRT-Community [5] sehr empfehlenswert. Hier gibt es eine große Anzahl von Tutorials, Flash Demos, ein Wiki und ein eigenes Forum. Abb. 2: Der Chart Designer. import org.eclipse.birt.report.engine.api.script.* Die vier Ebenen eines Reports Jeder mit BIRT erstellte Report verfügt über einen bestimmten Aufbau, der auf 4 Ebenen erfolgt: • Auf Ebene 1 müssen für den Report Daten zur Verfügung gestellt werden. Als Datenquelle kann jede Datenbank genutzt werden, für die es einen JDBC-Treiber gibt. public class Event extends LabelEventAdapter { public void onPrepare(ILabel arg0, IReportContext arg1) { try { arg0.getStyle().setBackgroundColor("red"); } catch (Exception e) { } } } Abb. 3: Einfacher Eventhandler, der die Hintergrundfarbe auf rot setzt. ORDIX News 1/2009 19 Open Source Außerdem können XML-Dateien, WebServices und Flachdateien (CSV) als Datenquelle genutzt werden. • Report Designer Eclipse Report Designer Eclipse DTP, WTP, ... Chart Designer Custom Designer • Report Design Engine XML Report Design Data Report Document Report Engine Data Transform. Services Charting Engine Generation Services Presentation Services HTML PDF Excel Word Powerpoint PostScript ... Abb. 4: So funktioniert BIRT. Glossar 20 • Auf Ebene 2 erfolgt die Datentransformation. Darunter versteht man die Gruppierung oder die Filterung von Daten. Diese Datentransformation kann direkt in der SQL-Abfrage erfolgen (group by, where-Klausel), aber auch später im Report Designer. Auf Ebene 3 erfolgt das Hinzufügen der Geschäftslogik. Dies kann in BIRT sowohl mit Java als auch mit JavaScript erfolgen. Auf Ebene 4 erfolgt die Präsentation, also die Ausgabe des Reports, als HTML oder PDF. Funktionalität BIRT besteht im Wesentlichen aus zwei Hauptkomponenten, dem Report Designer und der Report Engine (siehe Abbildung 4). Wie die Namen schon verraten, dient der Report Designer zum Erstellen des Layouts und die Report Engine zur Erstellung des Berichts selbst. Der Report Designer Der Report Designer besteht aus den Komponenten Eclipse Report Designer, dem Chart Designer, der Report Design Engine und zusätzlichen Eclipse Plugins wie DTP (Data Tools Platform) und WTP (Web Tools Platform). Einfache Reports wie Tabellen und Listen werden mit dem Eclipse Report Designer erstellt, Charts wie Balken- oder Tortendiagramme mit dem Chart Designer. Die Report Design Engine wandelt den Report in eine XML-Datei mit der Endung *.rptdesign um. Die XML-Datei enthält alle Informationen zum Layout, zur Formatierung und zu den Datenquellen, die der Report nutzt. BI Business Intelligence - IT-basierter Gesamtansatz zur betrieblichen Entscheidungsunterstützung. BIRT Business Intelligence and Reporting Tools. BIRT ist ein BI-Tool der Eclipse Foundation, das auf Java-Technologien basiert. Eclipse Eine Open Source Entwicklungsumgebung, mit offener, pluginbasierter Struktur unter der Verwaltung der Eclipse Foundation. Die Report Engine JavaScript Von Netscape entwickelte client-seitige Skriptsprache zur Erstellung dynamischer Webseiten. JDBC Standard für den Zugriff auf relationale Datenbanken mit Java. Open Source Quelloffen - Quellcode ist einsehbar und darf verändert werden. Reporting Berichtswesen - Erstellung, Verteilung und Speicherung von statischen und dynamischen Berichten. Tomcat Servlet Container und HTTP-Server der Firma Apache. XML Extensible Markup Language (XML). 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 erlaubt. Die Report Engine ist die Laufzeitumgebung und ermöglicht es, aus der XML-Report-Design-Datei einen fertigen Report in unterschiedlichen Ausgabeformaten zu erstellen. Im ersten Schritt wird mit Hilfe der Generation Services die XML-Datei um die entsprechenden Daten angereichert. Bei Bedarf können diese Daten dann über die Data Transformation Services noch transformiert werden. Danach wird von den Generation Services eine temporäre Datei, das so genannte Report Document erzeugt. Das Report Document ist die XML-Datei, erweitert um die transformierten Daten. Je nach gewähl- ORDIX News 1/2009 Open Source tem Ausgabeformat können die Presentation Services aus dem Report Document einen fertigen Report in der gewünschten Ausgabe generieren. Für die Berichte, in denen Diagramme vorkommen, werden die Presentation Services von der Chart Engine unterstützt. Links ► [1] Anleitung zur Integration von Reports: http://www.eclipse.org/birt/phoenix/deploy/viewerSetup.php ► [2] Die Eclipse BIRT Homepage: http://www.eclipse.org/birt/phoenix/ ► [3] Buchtipp: „BIRT - A Field Guide for Reporting“, ISBN-10: 0321580273, ISBN-13: 978- Fazit Das Open Source Tool BIRT macht mittlerweile einen recht ausgereiften Eindruck. Eine der großen Stärken von BIRT ist die Benutzerfreundlichkeit. Wenn Sie bereits mit Eclipse gearbeitet haben und über etwas SQL-Grundlagenwissen verfügen, werden Sie schnell in der Lage sein, einen einfachen Report zu erstellen. Haben Sie darüber hinaus auch noch Java- oder JavaScript-Kenntnisse, sind mit BIRT auch komplexere Reports möglich. Wer also ein Tool sucht, das in der Lage ist, dynamische Reports in HTML oder PDF zu erzeugen, ist mit BIRT gut beraten. Negativ zu bewerten ist lediglich die Ausgabe von Reports als Excel-Dokument, die bei unseren Tests nur funktionierte, wenn der Report aus einfachen 0321580276 ► [4] Buchtipp: „Integrating and Extending BIRT“, ISBN-10: 0321443853, ISBN-13: 9780321443854 ► [5] Die BIRT Community mit vielen Tutorials und Beispielen: http://www.birt-exchange.com/ ► [6] Blog mit guten Code-Beispielen: http://birtworld.blogspot.com/ ► [7] Die Actuate Homepage : http://www.actuate.com/home/index.asp Tabellen bestand. Sobald der Report auch eine Grafik enthält, ist das Excel-Dokument unbrauchbar. Ob sich das in Zukunft ändert, ist fraglich, da Actuate mit dem Spreadsheet Designer ein kommerzielles Tool anbietet, das speziell diese Aufgabe erfüllt. Ulf Papenfuß ([email protected]). BIRT im Expertencheck 1. Installationsaufwand 2. Datenquellenanbindung 3. Formatunterstützung 4. IDE 5. Report-Generierung 6. Chart-Generierung 7. Integration in Servlet Engines 8. Benutzerfreundlichkeit 9. Dokumentation 10. Entwicklungspotential 11. Gesamteindruck positiv: negativ: „Der Einstieg in BIRT ist dank einfacher Installation und einer guten Dokumentation nicht schwierig. Besonders erwähnenswert ist die Generierung von Charts in BIRT. Diese ist aufgrund des Wizzards nicht nur sehr benutzerfreundlich, sondern bietet auch einen guten Funktionsumfang. Auch die Datenquellenanbindung ist für ein Reporting Tool mehr als ausreichend. Schwächen zeigt BIRT jedoch in der Unterstützung des Excel-Formats. Mein Fazit: BIRT hat einen guten Start hingelegt und hat aufgrund der großen Community und der Unterstützung der Eclipse Foundation ein großes Entwicklungspotential. Wer ein kostenloses Tool für die Erstellung von Reports in PDF und HTML sucht, für den ist BIRT die richtige Wahl.“ Ulf Papenfuß ORDIX AG, Paderborn ORDIX News 1/2009 21 Datenbanken Reihe Oracle Objekttypen von A - Z (Teil IX): Ressourcen und andere Objekte Die Reihe ist für alle Datenbankadministratoren und Entwickler, die einen Überblick über die Oracle Objekttypen bekommen wollen. In diesem Teil der Reihe Objekttypen von A - Z beginnen wir mit dem Resource Manager und kommen über Sequenzen, Snapshots und Synonymen zum Datenbankobjekt Tabelle. Mit dem Objekt Trigger beenden wir den neunten Teil dieser Reihe. Resource Manager Der Resource Manager ist ein Werkzeug zur Verwaltung von System-Ressourcen wie z. B. der CPU-Zeit, der Anzahl paralleler Prozesse und der Größe des Undo-Bereichs. Normalerweise kann ein Oracle-Benutzer beliebig viele Hardware-Ressourcen verwenden und so andere Benutzer oder Programme bei der Arbeit empfindlich stören. Mit Hilfe des Resource Managers lassen sich Ressourcenpläne definieren, die einerseits die Ressourcen auf bestimmte Gruppen aufteilen und andererseits Oracle-Benutzer diesen Gruppen zuordnen. Die Ressourcenpläne werden mit dem PL/SQL-Paket DBMS_RESOURCE_MANAGER angelegt und verwaltet und stellen eigene Datenbankobjekte dar. Die Verwaltung der CPUZeit in den Ressourcenplänen erfolgt über so genannte Consumer Groups, die ebenfalls eigene Datenbankobjekte darstellen. ORDIX News 1/2009 Abbildung 1 zeigt die Syntax zum Anlegen einer Sequenz und zur Erzeugung einer Sequenznummer. Snapshot Das Datenbankobjekt Snapshot gibt es nur noch aus Gründen der Kompatibilität mit früheren Versionen. Der Nachfolger von Snapshot heißt Materialized View. Diesem Datenbankobjekt haben wir uns in der Ausgabe 3/2008 [1] gewidmet. Sequenz Synonym Die Sequenz ist ein Datenbankobjekt zur Generierung von Integer-Zahlen. Häufig wird die Sequenz zur Befüllung eines künstlichen Primärschlüssels verwendet. Beim Anlegen der Sequenz können der Startwert, ein maximaler Wert und die Eigenschaft CYCLE angegeben werden. Die CYCLE-Eigenschaft besagt, dass bei Erreichung des maximalen Werts wieder beim Startwert begonnen wird. Ein Synonym ist ein Alias auf ein Datenbankobjekt. Das Datenbankobjekt kann dabei sowohl vom Typ Tabelle, View, Sequenz, Stored Procedure, Funktion, Paket, Materialized View oder Java-Klasse sein, als auch ein benutzerdefinierter Typ oder ein Synonym selbst. Eine weitere Eigenschaft ist die Sortierung. Diese stellt sicher, dass Sequenznummern zeitlich streng monoton aufsteigend vergeben werden. Während bei Single-Instance- 22 Datenbanken diese Eigenschaft zwingend ist, kann die Sortierung in RAC-Konfigurationen zu erheb­lichen Performance-Problemen führen. Der Vermeidung von Performance-Problemen dient der Parameter CACHE. Dieser legt fest, wie viele Sequenznummern im Speicher vorgehalten werden. Ein Synonym ist beispielsweise hilfreich, um eine Referenz auf ein Objekt in einem anderen Schema oder einer entfernten Datenbank zu verwenden, ohne das Schema bzw. den Datenbank-Link selbst im Programmcode festzuschreiben. Abbildung 2 zeigt, wie ein Synonym angelegt wird. Nach dem Anlegen Datenbanken des Objekts kann die entfernte Tabelle einfach über den Namen des Synonyms (hier kunde) angesprochen werden. Tabelle / Tabellen-Partition / Tabellen-Subpartition Die Tabelle ist wohl das bekannteste Datenbankobjekt. Sie dient der Aufnahme der Daten einer Anwendung, findet aber auch im Data Dictionary selbst vielfach Verwendung. Die Standardtabelle wird auch als so genannte Heap-Tabelle bezeichnet. Damit wird kenntlich gemacht, dass die Daten in der Tabelle in der Regel nicht sortiert sind, es handelt sich lediglich um einen „Haufen“ von Daten. CREATE SEQUENCE pk_id; SELECT pk_id.nextval FROM dual; Abb. 1: Verwendung von Sequenzen. CREATE SYNONYM kunde FOR sap.kunde; Abb. 2: Erstellung eines Synonyms. Links ►► [1] ORDIX News Artikel „LOB, LOB Partition, LOB Subpartition, Materialized Neben der Heap-Tabelle gibt es weitere Speicherstrukturen. Eine Index-Organized-Table (IOT) ist eine Tabelle, in der die Daten physikalisch nach dem Primary Key der Tabelle sortiert sind. Mit dem Anlegen einer IOT entstehen immer zwingend zwei Datenbankobjekte, die Tabelle und der Primary Key. Allerdings ist lediglich der Primary Key ein Segment. Views, Operator“: http://www.ordix.de/ORDIXNews/3_2008/Datenbanken/Oracle_Objekttypen_teil7.html ►► [2] ORDIX News Artikel „PL/SQL-Objekte und -Indizes“: http://www.ordix.de/ORDIXNews/3_2007/Datenbanken/oracle_objekttypen_teilIV.html ►► [3] ORDIX News Artikel „Oracle Objekttypen – Von Cluster bis XML“: http://www.ordix.de/ORDIXNews/3_2006/Datenbanken/oracle_objekttypen.html ►► [4] Übersicht ORDIX News Artikelreihe Oracle Objekttypen: http://www.ordix.de/ORDIXNews/artikelreihen.html#oracle_objekttypen Das Datenbankobjekt Index wurde bereits in der ORDIX News 3/2007 [2] behandelt. Eine weitere Speicherstruktur für Tabellen ist der Cluster, über den wir bereits in der ORDIX News 3/2006 [3] berichteten. Der Cluster verbindet mehrere Tabellen über einen Cluster-Index und speichert die zugehörigen Daten aller Tabellen physikalisch gemeinsam ab. Auch mit der Erstellung eines Clusters werden mehrere Datenbankobjekte erzeugt, jeweils ein Objekt für jede Tabelle und ein weiteres für den Cluster sowie den Cluster-Index. Hierbei sind nur die beiden letztgenannten auch Segmente. Eine weitere Möglichkeit der physikalischen Strukturierung stellt die Partitionierung dar. Mit deren Hilfe wird eine logische Tabelle nach einem bestimmten Kriterium (partition key) in mehrere kleinere Einheiten zerlegt. Diese Einheiten heißen Partitionen. Die Partitionen selbst können wiederum noch einmal in so genannte Subpartitionen partitioniert werden. Alle Partitionen und Subpartitionen sind, zusätzlich zur Tabelle selbst, eigenständige Objekte. Alle Eigenschaften des Datenbankobjektes Tabelle vorzustellen, würde den Rahmen dieser Ausarbeitung deutlich sprengen. In der Oracle 10.2 Dokumentation nimmt der Befehl CREATE TABLE bereits beeindruckende 55 Seiten ein! Trigger Ein Trigger ist ein Datenbankobjekt zum Auslösen bestimmter Aktionen beim Eintreffen eines Ereignisses. Bekannt sind sicherlich Trigger auf Tabellen, welche auf die DMLKommandos INSERT, UPDATE und DELETE reagieren. Daneben existieren aber auch Trigger auf Views. Diese Instead-Of-Trigger interpretieren DML-Kommandos auf Views frei nach den Wünschen des Anwendungsentwicklers. Die dritte Variante sind Trigger, die auf Datenbankereignisse reagieren. Diese Trigger können auf die Datenbank oder auf ein Schema angelegt werden. Das Triggerereignis kann beispielsweise der Start der Datenbank, das Anmelden eines Benutzers oder die Erstellung eines Objektes sein. Ausblick In der nächsten Ausgabe der ORDIX News schließen wir die Reihe der Objekttypen nach mehr als zwei Jahren und ca. 50 unterschiedlichen Objekttypen ab. Martin Hoermann ([email protected]). ORDIX News 1/2009 23 24 ORDIX News 1/2009 KW 14 KW 15 KW 16 KW 17 KW 18 KW 19 KW 20 KW 21 KW 22 KW 23 KW 24 KW 25 KW 15 KW 16 KW 17 KW 18 KW 19 KW 20 KW 21 KW 22 KW 23 KW 24 KW 25 Juni KW 14 Mai KW 13 April KW 13 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 Grundlagen Oracle Datenbankprogrammierung mit PL/SQL Aufbau Oracle Datenbankadministration Grundlagen Oracle Datenbankadministration Aufbau Oracle Backup und Recovery Oracle Tuning und Monitoring Oracle Troubleshooting Workshop Oracle Real Application Cluster (RAC) Oracle 11g Neuheiten Oracle Security Oracle Data Guard Oracle RMAN Oracle Grid Control Oracle Streams Advanced Queuing Oracle Replikation IBM Informix SQL IBM Informix Dynamic Server Administration IBM Informix Dynamic Server Tuning und Monitoring IBM Informix Dynamic Server Backup und Recovery IBM Informix Dynamic Server 11 Neuheiten IBM Informix Dynamic Server Hochverfügbarkeits-Technologien unter Unix IBM DB2 für Linux/Unix/Windows SQL Grundlagen IBM DB2 für Linux/Unix/Windows Administration IBM DB2 für Linux/Unix/Windows Monitoring, Tuning und Hochverfügbarkeit MySQL Administration Microsoft SQL Server Administration Microsoft SQL Server Hochverfügbarkeits-Workshop Programmierung PHP Programmierung Grundlagen PHP Programmierung Aufbau 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 Java-JEE Einführung in die objektorientierte Programmierung 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 Hibernate und die Java Persistence API Java Performance Tuning Java Memory und Garbage Collection - Theorie und Praxis 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 Networking für Unix-Systemadministratoren Server-Virtualisierung mit XEN Linux Hochverfügbarkeits-Cluster OpenLDAP - Praxiseinsatz im Netzwerk Solaris Systemadministration Grundlagen Solaris Systemadministration Aufbau Solaris kompakt für erfahrene Unix-Administratoren Solaris 10 für erfahrene Systemadministratoren Solaris Containers Zettabyte Filesystem (ZFS) Workshop AIX Systemadministration Grundlagen Multivendor-Systemadministration IPv6 für Entscheider IPv6 für Systemadministratoren Systemmanagement Systemüberwachung mit Nagios Grundlagen Systemüberwachung mit Nagios Aufbau Projektmanagement IT-Projektmanagement IT-Controlling Grundlagen IT-Projektcontrolling in der Praxis März KW 12 März - Oktober 2009 Preis in Euro *)**) KW 12 Seminartermine 550,00 € 890,00 € 1.890,00 € 890,00 € 1.290,00 € 1.890,00 € 1.890,00 € 1.990,00 € 1.990,00 € 1.990,00 € 1.990,00 € 1.990,00 € 1.990,00 € 1.990,00 € 1.290,00 € 1.590,00 € 1.590,00 € 1.290,00 € 1.290,00 € 1.290,00 € 1.790,00 € 1.990,00 € 1.990,00 € 1.290,00 € 590,00 € 1.590,00 € 1.890,00 € 1.990,00 € 1.290,00 € 1.190,00 € 1.790,00 € 790,00 € 1.690,00 € 1.190,00 € 1.690,00 € 1.690,00 € 1.690,00 € 1.190,00 € 1.190,00 € 890,00 € 1.190,00 € 1.190,00 € 1.690,00 € 1.690,00 € 1.690,00 € 590,00 € 1.290,00 € 1.590,00 € 1.590,00 € 1.590,00 € 1.190,00 € 1.190,00 € 1.690,00 € 1.290,00 € 690,00 € 1.190,00 € 1.190,00 € 1.390,00 € 1.190,00 € 1.690,00 € 1.690,00 € 1.690,00 € 1.190,00 € 1.290,00 € 1.490,00 € 1.990,00 € 1.990,00 € 1.990,00 € 1.990,00 € 1.290,00 € 890,00 € 1.990,00 € 1.990,00 € 590,00 € 1.190,00 € 1.190,00 € 890,00 € 1.990,00 € 1.290,00 € 1.290,00 € Seminartermine KW 43 KW 42 KW 41 Oktober 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 KW 26 Juli März - Oktober 2009 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: 0180 1 ORDIX 0 bzw. 0180 1 67349 0 E-Mail: [email protected] Online-Anmeldung: http://training.ordix.de Für Informationen und Fragen zu individuell zugeschnittenen Seminaren, Ausbildungsreihen oder Inhouse-Schulungen stehen wir Ihnen gerne zur Verfügung. Auf Wunsch senden wir Ihnen auch unser komplettes Seminarprogramm zu. http://training.ordix.de Online-Anmeldung und stets aktuelle Seminarinhalte und Termine! KW 43 KW 42 KW 41 KW 40 KW 39 KW 38 KW 37 KW 36 KW 35 KW 34 KW 33 KW 32 KW 31 KW 30 KW 29 KW 28 KW 27 KW 26 Seminartermin in Wiesbaden *) Preise pro Seminar pro Teilnehmer in Euro. Alle Preise gelten zzgl. ges MwSt. **) Inhousepreise auf Anfrage. ORDIX News 1/2009 25 IT-Strategie Reihe SOA (Teil III): RESTful Web Services Dieser Artikel richtet sich an Architekten und Entwickler, die eine einfache und performante Technologie zur Implementierung von Web Services suchen. Die Vorteile von serviceorientierten Architekturen (SOA) liegen auf der Hand: Geschäftsvorfälle werden über Services abgebildet, wodurch die Komplexität verringert und die Wiederverwendbarkeit bestehender Services ermöglicht wird. SOA macht keine Vorschriften über konkrete zu verwendende Technologien. Um Services zu realisieren, wird häufig auf Web Services, die auf SOAP basieren, zurückgegriffen. Da Web Services jedoch recht komplex sind, kann sich ein Blick auf die sehr einfache REST-Architektur lohnen. Roy Fielding, der auch an der Spezifikation des HTTP-Protokolls beteiligt war, prägte in seiner Doktorarbeit den Begriff REST (Representational State Transfer). REST ist ein Architekturvorschlag für die Implementierung verteilter Softwaresysteme. Das World Wide Web ist das wohl bekannteste Beispiel eines REST-Systems. Daher lassen 26 ORDIX News 1/2009 sich die grundlegenden Eigenschaften von REST auch im Web wiederfinden. Eigenschaften von REST-Systemen • Die Kommunikation verläuft bei REST nach dem Request-Response Paradigma. Der Client fordert Informationen vom Server an, der eine entsprechende Antwort zurückgibt. IT-Strategie • • • • Die Kommunikation erfolgt zustandslos. Sämtliche relevanten Informationen müssen über einen Request gesendet werden, eine Session ist nicht vorhanden. Die gewünschte Ressource ist über eine URI erreichbar. Die Anfragen erfolgen über bestimmte Operationen, zum Beispiel im HTTP: GET (Lesen), POST (Aktualisieren), PUT (Anlegen), DELETE (Löschen). @Path @GET @Produces @Consume @QueryParam Pfad, über den die Ressource zu erreichen ist. Analog zu den HTTP-Methoden GET, POST, PUT, DELETE und HEAD gibt es entsprechende Annotations, um Methoden einer Ressourcen-Klasse zu kennzeichnen. Diese werden dann entsprechend der HTTP-Anfrage aufgerufen. Gibt den MIME-Type der Antwort an den Client an. Gibt an, in welchem MIME-Type die Anfragen des Clients vorliegen. (In Kombination mit der Annotation @Post) Auslesen von Request Parametern Abb. 1: Auswahl an Jersey Annotations. Die Antworten können aus einem Cache geladen werden, um die Netzwerkeffi­zienz zu erhöhen. package de.ordix; Werden diese Eigenschaften bei der Entwicklung von Services beachtet, spricht man von „RESTful Services“. Bei der Implementierung dieser Services sollten folgende Prinzipien angewendet werden. Prinzipien bei der Entwicklung von RESTful Services • • • • Für jede über einen Service erreichbare Ressource wird eine eigene URI bereitgestellt, z. B. für ein Seminar mit der ID 4711: http://www.ordix.de/seminare/4711 Anfragen des Clients per GET-Methode dürfen keine Seiteneffekte haben. Der Server liefert die angeforderte Ressource zurück, führt aber keinerlei Änderungen durch. Der Server sollte als Antwort zusätzliche Hyperlinks zur Verfügung stellen, anhand derer der Client weitere Informationen zu der Ressource beschaffen kann. Services sollten per WSDL oder über ein einfaches HTML-Dokument beschrieben werden. Dies ist besonders wichtig, falls auch Operationen wie POST oder PUT möglich sind. Die Referenzimplementierung Jersey Wenn nun die Entscheidung für RESTful Services getroffen ist, wird eine konkrete Tech­ nologie zur Implementierung benötigt. An dieser Stelle lohnt sich ein Blick auf den von SUN verabschiedeten Java Specification Request Nummer 311. Dahinter verbirgt sich die „Java-API für RESTful Web Services“, die so genannte JAX-RS. Die Referenzimplementierung heißt Jersey und lässt sich in der aktuellen Version 1.0 beziehen [1]. Im Folgenden import javax.ws.rs.*; @Path("/seminare/{seminarname}") public class SeminarRessource{ @GET @Produces("text/plain") public String getSeminar(@PathParam("seminarname") String seminar) { return "Danke für Ihr Interesse an dem Seminar: "+seminar; } } Abb. 2: Ein einfacher RESTful Web Service. wird ein einfacher REST-Service mit Hilfe von Jersey implementiert. Beispielservice mit Jersey Die Funktionalität von Jersey lässt sich über eine einfache Servlet-Anwendung demonstrieren. Im Deployment Deskriptor der Anwendung (web.xml) wird der Jersey Servlet Container registriert. Dieser verarbeitet die eingehenden Anfragen und führt entsprechende Methoden aus. Die eigentliche Verarbeitung der REST-Anfragen findet in so genannten RessourcenKlassen statt. Diese sind einfache POJOS, die bestimmte Annotations verwenden. Einige Beispiele finden Sie in Abbildung 1. Abbildung 2 zeigt eine einfache RessourcenKlasse, die eine HTTP-GET Anfrage entgegennimmt und eine Nachricht im Textfor­ mat an den Client zurücksendet. Es wird ein URI-Template verwendet ({seminarname}), welches in der Methode getSeminar ausge- ORDIX News 1/2009 27 IT-Strategie wertet wird. Aufgerufen wird dieser Service wie folgt: Glossar REST Representational State Transfer. Architekturkonzept für verteilte Softwaresysteme, bei dem jede Ressource über eine eigene URI ansprechbar ist. SOA Serviceorientierte Architektur. Ist ein Systemarchitekturkonzept, das die Bereitstellung fachlicher Dienste und Funktionalitäten in Form von Diensten (Services) vorsieht. Ein Dienst ist in diesem Kontext eine Funktionalität, die über eine standardisierte Schnittstelle in Anspruch genommen werden kann. Häufig werden solche Dienste als Web Services realisiert. Simple Object Access Protocol. SOAP ist ein Protokoll, mit dessen Hilfe Daten zwischen Systemen ausgetauscht und Remote Procedure Calls durchgeführt werden können. Hypertext Transfer Protocol (Hypertext-Übertragungsprotokoll). HTTP ist ein Protokoll zur Übertragung von Daten über ein Netzwerk. Es wird hauptsächlich eingesetzt, um Webseiten und andere Daten aus dem Internet in einen Webbrowser zu laden. Uniform Resource Identifier. (Einheitlicher Bezeichner für Ressourcen). Zeichenfolge zur eindeutigen Identifizierung einer Ressource (z. B. Webseite). Java Specification Request. JSR kennzeichnet eine Anforderung für eine Änderung der Programmiersprache Java, die vom Standardisierungskomitee, dem Java Community Process, eingebracht wird. SOAP HTTP URI JSR POJO Plain Old Java Object. Dabei handelt es sich um ein normales Objekt in der Programmiersprache Java. Annotations Anmerkungen im Java Source Code, die zur Laufzeit des Programms ausgewertet werden können. Annotations sind seit Java 5 Bestandteil von Java. Als geistigen Vater dieser Annotations kann man das Open Source Projekt XDoclet ansehen. XDoclet erlaubte es, auch schon in früheren Java- Versionen mit Annotations zu programmieren. Links ►► [1] Jersey Download: https://jersey.dev.java.net/ ►► [2] ORDIX News Reihe SOA (Teil I) „Was ist SOA?“: http://www.ordix.de/ORDIXNews/3_2008/IT-Strategie/Ueberblick_SOA.html ►► [3] ORDIX News Reihe SOA (Teil II) „SOA-Governance - Braucht SOA eine neue Regierung?“: http://www.ordix.de/ORDIXNews/4_2008/IT-Strategie/SOA_Governance.html http://beispiel.de:8080/restWebAnwendung/seminare/Java Die Ausgabe lautet dann: „Danke für Ihr Interesse an dem Seminar: Java“. Vorteile von RESTful Services Das Beispiel in Abbildung 2 macht deutlich, dass es mit relativ wenig Aufwand möglich ist, Web Services mit Hilfe von REST zu implementieren. Auch lässt sich Jersey leicht in bestehende Anwendungen integrieren: Entsprechende Methoden müssen lediglich mit den passenden Annotations versehen werden. Die Daten werden über das HTTP-Protokoll übertragen. Daher entfällt der XML-Overhead, den das SOAP-Protokoll mitbringt. Bestehende Caching-Mechanismen im Web, z. B. von Web-Servern oder Proxy-Servern, können ausgenutzt werden. Auch lässt sich der REST-Ansatz leicht mit Ajax Frameworks kombinieren, da diese auf einer HTTP-Kommunikation basieren. Fazit RESTful Web Services können eine durchaus sinnvolle Alternative zu den Web Services auf Basis von SOAP sein. Sie sind einfach zu implementieren und performant. Die Referenzimplementierung Jersey bietet mit Annotations die Möglichkeit, Services einfach und übersichtlich zu entwickeln. Spielen allerdings komplexe Workflows, Security und Transaktionsmanagement eine Rolle, stoßen RESTful Services an ihre Grenzen. Jens Stahl ([email protected]). Seminarempfehlung: Java Web Services ►► Informationen/Online-Anmeldung: http://training.ordix.de/seminar.php?nr=266 In diesem Seminar werden Sie mit der Erstellung der innovativen WebServices im Java-Umfeld auf Basis von JAX-WS und Axis2 vertraut gemacht. Alle zugehörigen Technologien und Realisierungsstrategien werden praxisnah betrachtet, so dass Sie nach dem Seminar in der Lage sind, auf den gängigen Plattformen WebServices zu implementieren. Seminar-ID: INT-05 Dauer: 3 Tage Preis pro Teilnehmer: 1.190,00 € (zzgl. MwSt.) Frühbucherpreis: 1.071,00 € (zzgl. MwSt.) 28 ORDIX News 1/2009 Termine 15.06.- 17.06.2009 in Wiesbaden 03.08.- 05.08.2009 in Wiesbaden 12.10.- 14.10.2009 in Wiesbaden Wir führen unsere Seminare auch jederzeit an einem geeigneten Ort Ihrer Wahl durch und bringen, wenn nötig, auch das entsprechende Equipment mit. Informieren Sie sich am besten im Internet über unsere Inhouse-Seminare und die mobilen Schulungen: http://training.ordix.de. Open Source Flexible Versionskontrolle mit Subversion (SVN) Größere Entwicklungsprojekte bestehen mitunter aus tausenden Dateien. Diese werden zudem von mehreren Entwicklern zum Teil parallel bearbeitet. Ohne den Einsatz von speziellen Tools ist es nicht möglich, dabei die Übersicht zu behalten. Mit Subversion (SVN) wird in diesem Artikel das derzeit aktuellste Versionskontrollsystem aus dem Open-Source-Bereich vorgestellt. Die Entstehung Versionskontrollsysteme gibt es bereits seit geraumer Zeit, sowohl im kommerziellen als auch im Open-Source-Bereich. Lange Zeit galt im Open-Source-Bereich das Tool CVS (Concurrent Version System) als erste Wahl. In vielen Entwicklungsprojekten stellte sich jedoch heraus, dass das System in einigen Belangen zu unflexibel und der Funktionsumfang nicht immer ausreichend war. Die Intention für die Entwicklung des Versionskontrollsystems Subversion bestand da­ rin, die Einschränkungen und Unzulänglich­ keiten von CVS auszuräumen und dem An­wender so viel Flexibilität wie möglich zur Verfügung zu stellen. Aktuell steht Subversion in der Version 1.5.5 zur Verfügung. Einsatzgebiete Grundsätzlich lassen sich alle Arten von Dateien mit SVN verwalten. So kommt Subversion durchaus auch für die Verwaltung von Binärdateien, z. B. Office-Dokumenten oder Bildern, zum Einsatz. Wichtige Funktionalitäten, wie zum Beispiel der Vergleich verschiedener Dateiversionen oder das automatische Zusammenführen von verschiedenen Bearbeitungsständen, funktionieren jedoch nur mit textbasierten Dateien. Für den Dateivergleich von Office-Dateien existieren zwar teilweise externe Tools, die verwendet werden können, das Haupteinsatzgebiet für Subversion stellt Dieser Artikel richtet sich an Entwickler und Architekten, die in ihren Projekten ein Versionskontrollsystem benötigen sowie an Administratoren, die ein solches System betreuen. jedoch ganz klar die Softwareentwicklung bzw. die Verwaltung von Quellcodedateien dar. Grundsätzliche Funktionsweise Die grundsätzliche Funktionsweise eines jeden Versionskontrollsystems ist im Prinzip immer gleich. Die verwalteten Daten liegen an einer zentralen Stelle in einem Repository, auf das die beteiligten Entwickler von ihren lokalen Rechnern aus zugreifen können. Die Bearbeitung einer Datei wird dann lokal durchgeführt und Änderungen oder neu erstellte Dateien werden anschließend in das Repository übertragen, so dass sie den anderen Entwicklern zur Verfügung stehen. Das Repository Das Repository kann auf dem SubversionServer entweder im Filesystem des Servers oder als BerkleyDB-Datenbank angelegt werden. Beide Alternativen unterstützen Transaktionen, so dass Änderungen immer atomar durchgeführt werden. Eine Netzwerkunterbrechung oder ein ähnliches Problem, das während der Übertragung zwischen Working­copy und Repository auftreten kann, führt demnach nicht zu einem inkonsistenten Datenbestand, da nur ein Teil der Dateien übertragen wurde. Obwohl die Struktur des Repositories völlig frei wählbar ist, wird ein Repository in der Regel immer nach dem gleichen Schema auf- ORDIX News 1/2009 29 Open Source gebaut (siehe Abbildung 1). Es wird also zwischen der Hauptentwicklungslinie (trunk), den Nebenentwicklungslinien (branches) und gegebenenfalls den Lieferständen (tags) unterschieden. Mehr dazu finden Sie im Abschnitt „Branches und Merges“. Die einzelnen Arbeitsversionen werden innerhalb des Repository mit einer Revisionsnummer gekennzeichnet. Jede Änderung, die per Commit-Befehl aus einer lokalen Workingcopy in das Repository gespielt wurde, führt dazu, dass die Revisionsnummer des gesamten Repository hochgezählt wird. Dabei spielt es keine Rolle, ob eine Datei im Trunk oder in einem Branch geändert wurde. Die Revisionsnummer bezieht sich immer auf das gesamte Repository. Die Workingcopy Um die verwalteten Dateien bearbeiten zu können, müssen die Entwickler zunächst eine Workingcopy des Repository-Standes auf ihrem lokalen Rechner erstellen. In dieser können dann die Änderungen vorgenommen werden. Dieser Checkout wird in der Regel nur ein einziges Mal vorgenommen. Anschließend werden nur noch die Unterschiede zwischen der Workingcopy und dem Repository (Commit) und umgekehrt (Update) übertragen. In jedem Ordner der Workingcopy wird ein verstecktes Verzeichnis mit dem Namen .svn angelegt. Darin befinden sich alle Informationen über die Datei, wie zum Beispiel der Dateipfad innerhalb des Repository, der Dateistatus oder die Revisionsnummer. Des Weiteren befindet sich innerhalb des Verzeichnisses .svn auch eine Kopie der Dateiversion zum Zeitpunkt des Checkouts bzw. des letzten Updates. Dies ermöglicht es dem SVN-Client zum einen, alle lokal vorgenommenen Änderungen rückgängig zu machen (Revert). Zum anderen kann der Client auch feststellen, ob eine Datei lokal verändert wurde oder nicht. Beides ist möglich, ohne sich mit dem Repository verbinden zu müssen. Durch die Sicherung der ausgecheckten Version verbraucht die Workingcopy immer ungefähr doppelt so viel Speicherplatz wie der Repository-Stand. Verschiedene Dateistatus Eine Datei innerhalb einer Workingcopy kann verschiedene Status haben: • Normal: Datei, die seit dem letzten Update nicht verändert wurde. • Modified: Datei, die seit dem letzten Update geändert wurde. • Conflicted: Datei, die sowohl in der lokalen Workingcopy als auch im Repository verändert wurde. • Deleted bzw. added: Datei, die in der lokalen Workingcopy gelöscht oder hinzugefügt wurde. Die Änderungen in der Workingcopy werden erst durch ein Commit zum SVN-Server wirksam. Weitere Status sind „locked“, „readonly“ und „ignored“: • trunk • Projektname tags • branches Abb. 1: Aufbau des Repository. 30 ORDIX News 1/2009 Locked: Eine Datei kann durch einen Anwender für andere Benutzer gesperrt werden, um eine Bearbeitung zu unterbinden. Sie erhält dann den Status „locked“. Readonly: Dateien, die manuell mit einem Schreibschutz versehen sind, werden als „readonly“ verwaltet. Ignored: Auch der Status „ignored“ wird manuell gesetzt. Dies ist nützlich für Dateien, die zwar bei einem Checkout aus dem Repository in die lokale Working­copy übernommen, deren Änderungen jedoch nicht ins Repository zurückgespielt werden sollen. Verwendet wird dieser Mechanismus beispielsweise für lokal unterschiedliche Konfigurationsdateien. Open Source Das Copy-Modify-Merge-Prinzip 1. Um die parallele Bearbeitung einer Datei zu ermöglichen, greift SVN auf das so genannte Copy-Modify-Merge-Prinzip zurück (siehe Abbildung 2). Im Gegensatz zu vielen anderen Versionskontrollsystemen, wird eine Datei, die sich in Bearbeitung befindet, nicht für die Bearbeitung durch andere Benutzer gesperrt. Das Lesen und Bearbeiten ist also für jeden Nutzer zu jeder Zeit möglich (siehe Schritt 1). Ein Benutzer kann eine lokal geänderte Datei nicht in das Repository spielen, wenn diese in der Zwischenzeit bereits von einem anderen Anwender geändert wurde (siehe Schritt 2). Die Datei erhält den Status „conflicted“. Er muss zunächst ein Update vornehmen und die beiden geänderten Versionen innerhalb seiner Workingcopy zusammenfügen (siehe Schritt 3). Wenn sich die vorgenommenen Änderungen nicht wiedersprechen, wird dieser Vorgang bei textbasierten Dateien automatisch vorgenommen. Dieser Mechanismus arbeitet zeilenbasiert, d. h. Dateien, in denen Änderungen von unterschiedlichen Benutzern in derselben Zeile vorgenommen wurden, können nicht automatisch bearbeitet werden. In diesem Fall muss der Benutzer die Dateiversionen manuell zusammenfügen. Die meisten SVN-Clients bieten aber auch hier Unterstützung an. Nachdem die beiden Versionsstände zusammengeführt wurden, kann der Dateistatus auf „modified“ gesetzt und die Datei anschießend über ein Commit in das Repository gespielt werden (siehe Schritt 4). Branches und Merges Um den Entwicklungszweig (trunk) zu duplizieren, bietet Subversion, wie auch die meisten anderen Versionskontrollsysteme, die Möglichkeit an, einen so genannten Branch (zu Deutsch: Ableger) zu erstellen. Technisch gesehen stellt ein Branch lediglich eine Kopie dar. Die im Branch vorgenommenen Änderungen können in die Hauptentwicklungslinie übernommen werden und umgekehrt. Das Übernehmen der gesamten Änderungen oder Teilen davon in eine andere Entwicklungslinie bezeichnet man als „Merge“. Für die Erstellung eines Branches kann es mehrere Gründe geben. Bug-Fix-Branch Am häufigsten wird ein so genannter Bug-FixBranch angelegt. Dies geschieht immer dann, 2. Repository Read Repository Read Write 1 3. Write 2 4. Repository Repository Read Write Merge Abb. 2: Copy-Modify-Merge-Prinzip. wenn ein bestimmter Verionsstand erreicht ist, der in den Test- oder Produktionsbetrieb geht. Somit kann in der Hauptentwicklungslinie die Entwicklung des nächsten Release beginnen und im Branch können Fehler behoben oder Änderungen vorgenommen werden, die während des Test- oder Produktionsbetriebs aufgefallen sind. Diese Änderungen können aus dem Branch in den Trunk übernommen werden. Aus dem Branch kann dann zu jeder Zeit ein Programmstand erzeugt werden, der zwar die Fehlerkorrekturen, nicht jedoch die neuen Funktionen für das nächste Release enthält. Entwicklungs-Branch Wenn für eine Entwicklung einer bestimmten Funktionalität oder eines bestimmten Moduls sehr weitreichende Änderungen an der Software vorgenommen werden müssen, kann dies die Arbeit anderer Entwickler beeinträchtigen. In diesem Falle kann es sinnvoll sein, für diese Entwicklung einen eigenen Branch anzulegen. Änderungen aus der Hauptentwicklungslinie würde man regelmäßig in den Branch übernehmen. Wenn die Entwicklung des Moduls abgeschlossen ist, übernimmt man diese dann wieder in den Trunk. Sonderversions-Branch Wenn neben der Standardversion einer Software eine oder mehrere Sonder- oder Spezialversionen existieren, kann es sinnvoll sein, auch hierfür einen separaten Branch zu er- ORDIX News 1/2009 31 Open Source Datei svnserve.conf -------------------[general] anon-access = read auth-access = write password-db = passwd authz-db = authz realm = Repositoryname [sasl] # use-sasl = true Datei users ------------------[users] user1 = Passwort1 user2 = Passwort2 Datei authz -----------------[/Repository Pfad] user1 = rw user2 = rw * = r Abb. 3: Konfigurationsdateien für den SVN-Zugriff. stellen. In diesen können dann alle Erweiterungen und Bugfixes aus dem Trunk bzw. anderen Branches übernommen werden. Die spezifischen Sonderfunktionen können jedoch in dem Branch separat verwaltet werden. Administratives Der Zugriff auf das Repository kann auf vielerlei Arten und über verschiedene Protokolle realisiert werden. Der gängigste Weg ist die Verwendung eines Apache Webservers, über den dann auch die Authentifizierung stattfindet. Als Protokoll kommt in diesem Fall http/https zum Einsatz. Der Webserver muss um 2 Moduldateien für die Einbindung von WebDAV und den SVNZugriff erweitert werden. In der Datei httpd.conf des Servers kann dann die Authentifizierungsmethode festgelegt und konfiguriert werden. Die Authentifizierung lässt sich dabei beispielsweise über einen LDAP, eine Datenbank oder die Kombination einer Passwort- und Berechtigungsdatei realisieren. Durch die Verwendung des WebDAV-Protokolls können die RepositoryInformationen auch in einem ganz normalen Browser angezeigt werden. Alternativ kann auch der SVN eigene Server „svnserv“ verwendet werden. Dieser kommuniziert über ein eigenes Protokoll namens „svn“ mit dem Client. Für die Authentifizierung und Autorisierung werden die Dateien svnserve.conf, users und authz im Verzeichnis conf des Repositories angelegt (sie­ he Abbildung 3). In der Datei svnserve.conf wird zunächst festgelegt, welche Berechtigungen ein authentifizierter Benutzer hat (Wert des Parameters auth-access) und welche Rechte ein nicht-authentifizierter Benutzer hat (Wert des Parameters anon-access). Die Werte für die Parameter password-db und auth-db verweisen auf die Dateien, in denen die UserPasswort-Kombinationen (password-db) bzw. die Berechtigungen der User (auth-db) hinterlegt sind. Es können lediglich die Werte r für lesenden und rw für lesenden und schreibenden Zugriff vergeben werden. SASL Abb. 4: Vergleich zweier Source-Dateien in NetBeans. 32 ORDIX News 1/2009 Seit der Version 1.5 unterstützt SVN auch die Verwendung einer SASL-Bibliothek. SASL ist ein Standard, der verschiedene Authentifizie- Open Source rungsmechanismen für unterschiedliche Protokolle zur Verfügung stellt. Der Einsatz von SASL in Verbindung mit Subversion ermöglicht beispielsweise die Verwendung einer Verschlüsselung bei der Authentifizierung oder die Anbindung eines LDAP, ohne dafür einen Apache Webserver installieren und einrichten zu müssen. Sinnvoll ist der Einsatz also vor allem dann, wenn kein Apache installiert werden kann/soll, oder wenn WebDAV-Kommandos nicht akzeptiert werden. Glossar SVN Abkürzung für Subversion. SVN ist eine Open Source Software zur Versionsverwaltung von Dateien und Verzeichnissen. CVS Concurrent Version System. Ein CVS ist ein Open Source Versionskontrollsystem. IDE Integrated Development Environment. Eine IDE ist eine grafische Oberfläche für eine komfortable Softwareentwicklung. Eclipse ist z. B. eine JavaIDE. LDAP Lightweight Directory Access Protocol. LDAP ist ein Protokoll zur Abfrage von Verzeichnisdiensten. LDAP setzt auf den heute als Standard anzusehenden Netzwerkprotokollen TCP/IP auf. SASL Simple Authentication and Security Layer. SASL ist ein Standard, der verschiedene Authentifizierungsmechanismen für unterschiedliche Protokolle zur Verfügung stellt. Verschiedene SVN-Clients Für alle gängigen Betriebssysteme existiert ein Commandline Client, über die SVN-Befehle direkt an den SVN-Server abgeschickt werden können. Mit einem Commandline Client lassen sich zwar sämtliche Funktionen von SVN nutzen, der Komfort eines Kommandozeilen-Tools ist aber in der Regel nicht sehr hoch. Vor allem der Vergleich von verschiedenen Dateiversionen lässt sich in einer Kommandozeile nur sehr spartanisch darstellen. Aus diesem Grunde gibt es eine ganze Reihe von Tools oder grafischen Benutzeroberflächen, die das Arbeiten mit Subversion deutlich erleichtern. Teilweise verwenden diese Tools einen Commandline Client als Grundlage, teilweise beinhalten sie die Funktion auch selbst. Das wahrscheinlich bekannteste Tool für Windows-Umgebungen ist das Programm „Tortoise“. Dieses integriert sich direkt in den Windows Explorer und erlaubt das Arbeiten daraus. Integration in IDEs Zwar lassen sich mit Subversion prinzipiell alle Arten von Dateien verwalten, der Hauptanwendungszweck ist jedoch sicherlich die Softwareentwicklung und die Verwaltung und Versionierung von Quellcode-Dateien. Ein wichtiger Aspekt bei der Auswahl eines Ver­ sionskontrollsystems ist also die Kompatibilität bzw. die Integration in die Entwicklungsumgebung, mit der gearbeitet wird. Für alle gängigen IDEs wie Netbeans, Eclipse, IntelliJ oder Visual Studio existieren Plugins, die den Zugriff auf ein SVN-Repository direkt aus der Entwicklungsumgebung heraus ermöglichen. Die meisten Plugins bieten neben den Grundfunktionen auch weitere Funktionalitäten an, wie zum Beispiel die Überprüfung von im Repository geänderten Dateien WebDAV Web-based Distributed Authoring and Versioning. WebDAV ist ein Standard, der den Zugriff auf ein Dateisystem über das Internet ermöglicht. Links ►► [1] Download des Tortoise Client: http://subversion.tigris.org/ ►► [2] HTML- und PDF-Dokumentationen zu SVN: http://svnbook.red-bean.com/ oder den kompletten Abgleich der lokalen Workingcopy mit dem Repository-Stand. Besonders nützlich ist auch der Vergleich zweier Versionsstände einer Datei. Hier bieten die meisten IDE-Integrationen grafische Übersichten an, in denen geänderte, gelöschte und neu hinzugefügte Dateifragmente farbig unterschiedlich dargestellt werden (siehe Abbildung 4). Dadurch können Unterschiede auf einen Blick erkannt und Änderungen über mehrere Versionen hinweg schnell und einfach nachverfolgt werden. Fazit Subversion überzeugt mit durchdachten Konzepten und einer ausgereiften Umsetzung. Nicht zuletzt sind auch die zahlreichen Tools und grafischen Bedienoberflächen sowie die sehr gute Integration in verschiedene Entwicklungsumgebungen ein Grund dafür, dass sich SVN zum meistgenutzten Versionskontrollsystem entwickelt hat. Subversion lässt kaum Wünsche offen und erleichtert die tägliche Arbeit in großen und kleinen Software-Projekten erheblich. Alexander Zeller ([email protected]). ORDIX News 1/2009 33 Datenbanken Oracle Enterprise Manager Grid Control (Teil VI): Standardisieren Sie Ihre individuelle Überwachung! Dieser Artikel richtet sich an Datenbankadministratoren, die ihre Zielüberwachung mit EM Grid Control optimal anpassen und standardisieren möchten. Mit EM Grid Control lässt sich eine sehr ausführliche Überwachung verschiedener Ziele realisieren. Jedoch führt diese Vielzahl an Überwachungsmöglichkeiten auch häufig zu einer wahren Flut an Alert-Meldungen. Um dieser Herr zu werden, können die Metriken der jeweiligen Ziele individuell angepasst und in eigenen Überwachungsvorlagen gespeichert werden. Wir zeigen Ihnen, wie Sie die Überwachung der Ziele mit EM Grid Control optimal auf Ihr Unternehmen abstimmen und standardisieren können. Allgemeines Auf der Startseite von EM Grid Control gibt der Menüpunkt Alerts einen Überblick über die Alerts der überwachten Ziele. Die überwachten Ziele können u. a. Datenbanken, Server, Listener oder auch Agenten sein. Im Einzelnen werden folgende Kategorien unterschieden: • • • • • • Heruntergefahrene Ziele Kritisch Warnung Fehler Blackout aktiv Unbekannte Verfügbarkeit Metriken Seit Oracle 10g gibt es innerhalb der Datenbank so genannte Metriken. Metriken erheben Statistikdaten von aktuellen oder historischen Daten nach einem voreingestellten oder individuell eingestellten Zeitintervall. Diese Statistikdaten werden im Automatic Workload Repository (AWR) innerhalb der Datenbank gespeichert. In Oracle 11g existieren über 180 Metriken in der Datenbank. Mit EM Grid Control lassen sich die Metriken individuell einstellen. 34 ORDIX News 1/2009 Beispiel: Die Metrik „Tablespace Used“ ermittelt alle 15 Minuten den Füllgrad aller Tablespaces der Datenbank. Diese Metrik generiert ab einem Füllgrad von 85 % eine Warnung und ab 97 % Füllgrad einen kritischen Alert. Auf der Datenbank Homepage vom EM Grid Control können Sie sich unter „Alle Metriken“ einen Überblick über alle vorhandenen Daten­ bankmetriken verschaffen. Benutzerdefinierte Metriken Die vorhandenen Metriken können durch benutzerdefinierte Metriken erweitert werden. Auf der Homepage des jeweiligen Ziels können Sie benutzerdefinierte Metriken erstellen. Je nach Zieltyp können für Server OperatingSystem-Based-Metriken und für Datenbanken SQL-Based-Metriken erstellt werden. Customizing der Metriken Damit Sie in EM Grid Control nicht mit den voreingestellten Standardmetriken mit Alert-Meldungen überflutet werden und den Überblick verlieren, können Sie die Metriken in Ihrem Unternehmen individuell anpassen. Erstellen Sie dazu Standard-Überwachungsvorlagen und kopieren Sie diese in die gewünschten Ziele. Datenbanken Mit einer Überwachungsvorlage in EM Grid Control können Sie voreingestellte Schwellwerte (Vergleichsoperatoren der Metriken) ändern oder fehlerbehebende Maßnahmen in den Metriken erstellen. Das Zeitintervall für jede Metrik kann ebenfalls individuell eingestellt werden. Die erstellte Überwachungsvorlage können Sie auf ein oder mehrere Ziele anwenden. Überwachungsvorlage erstellen Eine Überwachungsvorlage können Sie über den Menüpunkt „Überwachungsvorlagen“ im Setup-Überblick von EM Grid Control erstellen (siehe Abbildung 1). Schritt 1: Wählen Sie ein repräsentatives Ziel aus, z. B. ein Datenbankziel (siehe Abbildung 2) und geben Sie einen Namen für die Überwachungsvorlage an (siehe Abbildung 3). Abb. 1: Schritt 1 - Überwachungsvorlage erstellen. Schritt 2: Bearbeiten Sie nun die Metriken, ändern Sie Schwellwerte, den Ausführungsplan und geben Sie für Metriken gegebenenfalls fehlerbehebende Maßnahmen an (siehe Abbildung 4). Mit einer fehlerbehebenden Maßnahme kann z. B. mit einem Skript als Reaktion auf eine Warnung oder kritischen Alert reagiert werden. Bestätigen Sie die Änderungen und speichern Sie die Überwachungsvorlage (siehe Abbildung 5). Überwachungsvorlage anwenden Abb. 2: Zieleinstellungen kopieren. Die erstellte Überwachungsvorlage kann nun auf die gewünschten Ziele oder Gruppen angewendet werden (siehe Abbildung 6). Sie können mit der Option „Metriken mit mehreren Schwell­werteinstellungen“ entweder a) die vorhandenen Metrikeinstellungen der Ziele vollständig ersetzen oder b) die Metrikeinstellungen der Überwachungs­ vorlage zusätzlich zu den bereits vorhandenen Metriken in die Ziele integrieren. Die geänderten Metrikeinstellungen können Sie nun auf die gewünschten Ziele kopieren. Es werden nur die Metrikeinstellungen auf die Ziele übertragen, die in der Überwachungsvorlage definiert wurden. Alle anderen Metrik­ einstellungen der Ziele bleiben unberührt. Unter „Vergangene Anwendervorgänge“ können Abb. 3: Schritt 2 - Überwachungsvorlage erstellen. ORDIX News 1/2009 35 Datenbanken Sie sich über den Status des Vorgangs informieren. So können Sie schnell und effektiv eine Überwachungsvorlage auf ein oder mehrere Ziele anwenden und somit die Überwachung in Ihrem Unternehmen standardisieren. Wenn Sie die erstellten Überwachungsvorlagen aus EM Grid Control löschen, bleiben die geänderten Metrikeinstellungen auf den Zielen davon unberührt. Alerts versenden Sie können Alert-Meldungen, die durch Metriken generiert werden, z. B. per Mail versenden bzw. an Third-Party-Überwachungstools wie z. B. HP OpenView weiterleiten. Abb. 4: Metrikeinstellungen ändern. Auf der EM Grid Control Homepage können Sie unter „Voreinstellungen“ Regeln definieren und verschiedene Metriken in diese Regel mit aufnehmen. In dieser Regel können Sie als Methode „E-Mail senden“ aktivieren. Somit wird eine E-Mail an die abonnierten Benutzer der Regel versendet. Voraussetzung ist, dass unter „Benachrichtigungsmethoden“ der Mail-Server konfiguriert und für die Benutzer in EM Grid Control unter „Voreinstellungen – Allgemein“ eine gültige E-Mail-Adresse eingetragen wurde. Mit jeder Regel können Sie mit einer vorher definierten Methode auch Alert-Meldungen an Third-­Party-Produkte senden und Skripte auf dem Oracle Management Server (OMS) ausführen. Löschen von Alerts Abb. 5: Überwachungsvorlage erfolgreich erstellt. Glossar Blackout Mit Blackouts können Ziele aus dem EM Grid Control für einen definierten Zeitraum herausgenommen werden. WAR Automatic Workload Repository. Das AWR besteht aus Tabellen im Schema SYS, in denen laufend Performance-Informationen zur Datenbank und dessen Server zentral gespeichert werden. Diese Funktionalität steht ab Oracle 10g EE zur Verfügung. OMS Oracle Management Server. Software von Oracle zur zentralen Administration mehrerer Oracle Datenbanken. 36 ORDIX News 1/2009 In EM Grid Control werden die Alert-Meldungen automatisiert gelöscht, sobald die Schwellwerte der Metriken wieder unterschritten werden und die Probleme behoben sind. Auf der EM Grid Control Homepage unter Diagnostic Summary werden alle Alerts aufgelistet. Von dort gelangt man zu den einzelnen Alert-Meldungen. Jede Alert-Meldung kann so manuell gelöscht werden. Werden historische Alert-Meldungen auf der EM Grid Control Homepage unter Alerts nicht automatisiert gelöscht, empfiehlt sich folgende Vorgehensweise zur Löschung dieser Alert-Meldungen: Synchronisieren Sie mit <AGENT_HOME>/bin/emctl clearstate agent die Alert-Meldungen zwischen Daten­ bank und Agent. Ein weiteres Problem kann Datenbanken durch eine Inkonsistenz zwischen Alert Log Errors und Alert History auftreten. Oracle empfiehlt hier, Patchset 10.2.0.3 – Patch 3731593 und 5019532 einzuspielen [1] oder direkt auf 10.2.0.4 zu patchen. Fazit In großen Datenbank-Umgebungen werden viele Alert-Meldungen aus den voreingestellten Metriken generiert. Mit dem EM Grid Control können Sie diese voreingestellten Standardmetriken effektiv an Ihre Bedürfnisse anpassen. Mit diesem Überblick sind Sie nun in der Lage, die Überwachung von Oracle Datenbanken in Ihrem Unternehmen durch die Erstellung von Überwachungsvorlagen zu standardisieren. Abb. 6: Überwachungsvorlage anwenden: Ziele auswählen. Links ►► [1] Oracle Doku aus Metalink (Zugriff nur für registrierte User): https://metalink.oracle.com/ Metalink Note 431297.1 ►► [2] Seminarempfehlung „Oracle Grid Control“: http://training.ordix.de/seminar.php?nr=552 ►► [3] Oracle Enterprise Manager Advanced Configuration Guide: http://download.oracle.com/docs/cd/B16240_01/doc/nav/portal_booklist.htm Michael Skowasch ([email protected]). Seminarempfehlung: Oracle Grid Control ►► Informationen/Online-Anmeldung: http://training.ordix.de/seminar.php?nr=552 In diesem sehr übungsintensiven Workshop lernen Sie, mit Oracle Grid Control zu arbeiten und umzugehen. Sie erhalten einen Überblick über die Oberfläche und die Installation der Agenten. Nach dem Seminar sind Sie in der Lage, Oracle Datenbanken über die GUI-Oberfläche zu verwalten und zu administrieren. Seminarinhalte • • • • • • • • • • • Überblick über die Oberfläche Installation Grid Control Migration von OMS zu Grid Installation der Agenten unter Oracle 8i, 9i, 10g Administration Alerts Metriken Jobs Advisor Framework ADDM Vertiefung der Theorie durch praktische Übungen und Beispiele Termine 06.04.- 08.04.2009 in Wiesbaden 06.07.- 08.07.2009 in Wiesbaden 14.09.- 16.09.2009 in Wiesbaden 16.11. - 18.11.2009 in Wiesbaden Seminar-ID: DB-ORA-35 Dauer: 3 Tage Preis pro Teilnehmer: 1.290,00 € (zzgl. MwSt.) Frühbucherpreis: 1.161,00 € (zzgl. MwSt.) Wir führen unsere Seminare auch jederzeit an einem geeigneten Ort Ihrer Wahl durch und bringen, wenn nötig, auch das entsprechende Equipment mit. Informieren Sie sich am besten im Internet über unsere Inhouse-Seminare und die mobilen Schulungen: http://training.ordix.de. ORDIX News 1/2009 37 Betriebssysteme NIM, ein Tool zur Installation von Software, birgt einen unerwarteten Schatz: Backup und Recovery mit NIM Dieser Artikel richtet sich an Systemadministratoren, die sich mit einer flexiblen und kostengünstigen Lösung im Bereich System-Backup bei AIX beschäftigen Ein häufig unterschätztes Werkzeug, das im Umfeld von IBM AIX-Servern zum Backup eingesetzt werden kann, ist das Network Installation Management (NIM) NIM ist ein Server-Client-basiertes Tool Es dient der Installation von Software-Quellen auf AIXSystemen. Diese Quellen können zum einen aus den bekannten AIX-Software-Paketen gebildet werden und Updates, wie Technologie-Level und Service Packs, beinhalten Zum anderen können die Quellen aber auch aus System-Backups (mksysb) oder vollständigen, installierbaren LPP-Sourcen bestehen. Mit ihnen ist es möglich, ein System komplett neu aufzubauen oder wiederherzustellen Die NIM-Architektur NIM-Operationen können zentral vom Master aus angestoßen (Push-Modus mit dem Befehl nim) oder vom einzelnen Client aus angefordert werden (Pull-Modus mit dem Befehl nimclient). Der Benutzer root des ClientSystems kann somit auch ohne administrativen Zugriff auf den NIM-Master Software-Installationen auf dem eigenen System auslösen. Die NIM-Landschaft besteht mindestens aus einem Master und einem Client. Die NIM-Umgebung definiert sich über das Netzwerk, in 38 ORDIX News 1/2009 dem sich die verwalteten Maschinen befinden. Ein physisches Netzwerk kann allerdings von mehreren NIM-Umgebungen verwendet werden, ebenso wie ein NIM-Master mehrere Netzwerke bedienen kann, sofern eine Route zu ihnen existiert. Eine spezifische Maschine ist jedoch immer nur Mitglied einer NIM-Umgebung. NIM-Klassen Die einzelnen Bestandteile von NIM werden innerhalb einer objektorientierten Technolo- Betriebssysteme gie verwaltet und wie viele andere Konfigurationsdaten von AIX in der ODM abgelegt. Die NIM-Objekte unterteilen sich in vier Klassen: • • • • Maschinen Netzwerke Ressourcen Gruppen In der Klasse der Maschinen sind die Objekte Master und Standalone interessant. Während das Objekt Master selbsterklärend ist, repräsentiert Standalone die Objekte der NIM-Clients als Rechner, die über eigene Speichersysteme verfügen und ein Betriebssystem hochfahren können. Das einzelne Objekt dieser Klasse ist der NIMClient mit seinen Eigenschaften wie Hostname, Typ, Kommunikationsweg, CPUID und verschiedenen Zustandsdaten. In der Klasse der Netzwerke werden diese nach ihrer physischen Ausprägung als Ethernet, Token Ring oder anderen unterschieden. Als Eigenschaften dieses Objektes gelten die Netz­ adresse, die Netzmaske und Gateways in das betreffende Netz. In der Klasse der Gruppen können Maschinen oder Ressourcen zusammengefasst werden. NIM-Ressourcen Die wichtigste Klasse ist die der Ressourcen, da sie die Gesamtheit der installierbaren Software, Hilfsmittel und Steuerungsskripte enthält. Ein zentrales Objekt ist das der LPP-Sourcen. Eine LPP-Source ist ein Depot von AIXFilesets, z. B. den Installations-Filesets im backup file format (bff), die beispielsweise aus dem Inhalt einer AIX-Installations-DVD gebildet werden können. Natürlich kann Software weggelassen (Sprachunterstützungen etc.) oder hinzugefügt (weitere Treiber) werden. Diese Software kann ein System komplett installieren und besitzt somit das simages-Flag. Mit den zur Aktualisierung des Betriebssys­ temstands bei IBM herunterladbaren Technologie-Leveln und Service Packs werden zwar auch LPP-Sourcen gebildet, sie besitzen jedoch nicht das simages-Flag. Insofern ist es mit ihnen nicht möglich, ein System neu aufzusetzen. Besitzt eine LPP-Source das simages-Flag, wird aus ihr eine nächste Ressourcenart, der SPOT, gebildet. Dieser „shared object product nim –o define –t mksysb –a server=master –a location=/export/ images/mksysb_testclient –a source=testclient -a mk_image=yes mksysb_testclient Abb. 1: Definition einer mksysb-Ressource auf dem NIM-Server. ... CONSOLE = /dev/lft0 INSTALL_METHOD = overwrite PROMPT = no BOSINST_LANG = en_US CULTURAL_CONVENTION = en_US MESSAGES = en_US KEYBOARD = en_US HDISKNAME = hdisk0 ... Abb. 2: Minimalausstattung für eine nicht-interaktive Software-Installation. tree“ ist vereinfacht ausgedrückt ein /usrDateisystem. Bei der Betriebsysteminstalla­ tion wird es per NFS bereitgestellt und auf dem Client eingehängt. Daraus bedient er sich der benötigten Programme, Treiber, Libraries und Skripte. Bei der Bildung eines SPOT werden die bff-Dateien aus der LPP-Source in das /usr-Verzeichnis des SPOT installiert. Der SPOT hat dadurch die Eigenschaft, dass er einem Betriebssystemstand entspricht. Dieser kann aber jederzeit durch Einspielen von Technologie-Leveln und Service Packs aktualisiert werden. Wird ein System gemeinsam mit SPOT und LPP-Source neu installiert, muss der SPOT eine mindestens ebenso hohe Version aufweisen, wie die dazugehörigen LPP-Sourcen. Allgemeiner gilt auch, dass der Software-Stand des Betriebsystems des NIM-Masters höher oder gleich der von ihm verwalteten Ressourcen sein muss. Das mksysb als Backup-Medium Um nun der Funktion eines Backup-Servers näher zu kommen, gibt es die Ressource mksysb. In ihr sind die rootvg-Backups einzelner Clients zusammengefasst, die mit dem Befehl mksysb angelegt wurden. Da es sich um mksysb auf einem nicht startbaren Medium handelt, besitzen sie kein Boot Image. Als ersten Schritt in einem Backup-Konzept gilt es nun, regelmäßig ein mksysb eines ORDIX News 1/2009 39 Betriebssysteme NIM-Clients zu erstellen und auf dem NIMServer zu speichern. Dies kann natürlich vom NIM-Master aus gesteuert geschehen, z. B. per NFS. In einem Kundenprojekt wurde hierzu der nicht-berechtigte Benutzer nimadm auf den Master und alle Clients verteilt. Dieser ruft über sudo das Backup-Skript auf, in dem das Backup-Verzeichnis des NIM-Master per NFS eingehängt wird, ein neues mksysb geschrieben und bei Erfolg das alte gelöscht wird. Eine entsprechende Protokollierung und Benachrichtigung beendet das Skript. Die mksysb-Datei ist jetzt aber noch kein NIM-Objekt. Um zu vermeiden, aus jeder Datei ein neues Objekt anzulegen, wird an dieser Stelle mit symbolischen Links gearbeitet. Der Link wird als Ressource definiert und verweist auf die jeweils zu verwendende mksysb-Datei. Eine mksysb-Ressource kann auch direkt auf dem NIM-Server definiert werden (siehe Abbildung 1). Smitty ausdrücklich erlaubt Eine mksysb-Datei mit dem Namen mksysb_ testclient würde damit unter dem Verzeichnis /export/images vom Client testclient gezogen und unter dem Namen mksysb_testclient als Ressource definiert werden. Hier wird ein Grundmuster von NIM deutlich, Objekte unter einem Namen (und nie direkt) anzusprechen. Aufgrund der allgemein sehr langen Kommandos kann auch der Smitty benutzt werden. Mit smitty nim Perform NIM administration Tasks Manage Resources Define a resource: „mksysb“ (smitty fast /export/aix53/lppsource /export/aix53/spot /export/images /tftpboot für die Software-Quellen für den Spot für die Backups für die Boot Images Abb. 3: Speicherorte bei AIX 5.3. nim –o bos_inst -t mksysb –a source=master -a spot=Spotname -a lppsource=Lppsourcename -a mksysb=mksysbname -a bosinst_data=bosinst_dataname -a accept_licenses=yes -a no_nim_client=no –a set_bootlist=no Clientname Abb. 4: Die vorhandenen Ressourcen werden allokiert. 40 ORDIX News 1/2009 path: smitty nim_mkres mksysb) wird die Eingabemaske für die Parameter erreicht. bosinst_data ist eine weitere NIM-Ressource. Sie ist eine Konfigurationsdatei, die bei der Installation des Basisbetriebssystems benutzt werden kann. Ein Template für diese Datei ist auf jedem Server vorhanden. Die Minimalausstattung für eine nichtinteraktive Ins­ tallation von Software zeigt Abbildung 2. Die hier verwendeten Steueranweisungen besagen: löse eine Neuinstallation aus (überschreibe), frage nicht nach (kein Prompt) und installiere die Software auf hdisk0. Natürlich gibt es noch weitere NIM-Ressourcen, die aber nicht notwendig für das weitere Verständnis sind. Vorraussetzungen auf dem NIM-Master Zum Aufbau des NIM-Masters wird das Paket bos.sysmgt.nim.master auf dem ausgesuchten System installiert. Die Vorraussetzungen sind genügend Speicherplatz und eine gute Netzwerkanbindung. Die SoftwareQuellen benötigen pro unterstützter AIX-Version in der Regel zwar nicht mehr als 12 GB. Sollen aber die Backups der Clients gesichert werden, so ist pro Client mit weiteren 5 GB zu rechnen. Für die Speicherorte (hier für das Beispiel AIX 5.3) sind eigene, logische Datenträger anzulegen (siehe Abbildung 3). Für jede Plattform gibt es eigene Boot Images, die im Schnitt 10 – 12 MB groß sind. Da sie ansonsten in „/“ aufbewahrt würden, gibt es für sie einen eigenen logischen Datenträger. Sind die Laufwerke eingerichtet, kann der NIM-Server mit nimconfig initialisiert und erste Software-Quellen als NIM-Objekte eingerichtet werden. Aufgrund des singulären Charakters kann dies auch über den Smitty geschehen (smitty nimconfig oder auch smitty nim_mkres_inst). Hier müssen die AIX-Installationsmedien griffbereit liegen. Ist der Master mit LPP-Source und SPOT ausgestattet, wird noch die Definition eines Netzwerks (smitty nim_mknet) und der Clients (smitty nim_mkmac) benötigt. Anhand der Definitionen des Clients wird später entschieden, welcher Kernel beim Hochfahren über das Netzwerk Verwendung findet. Vorraussetzungen auf den NIM-Clients Um vom NIM-Master eine Operation auf dem Client auslösen zu können, muss die- Betriebssysteme ser in die Umgebung integriert und das Paket bos.sysmgt.nim.client installiert sein. Das Client-Paket muss in der Version gleich oder niedriger als das Master-Paket sein. Mit niminit –a name=Clientname –a master=Mastername –a platform=chrp -a pif_name =en0 –a connect=nimsh (oder smitty niminit) wird der Client in der Datei /etc/niminfo konfiguriert und beim Master angemeldet. Dieser Schritt entfällt, wenn der Server über NIM komplett neu installiert wird. Ab diesem Zeitpunkt sind Push- oder PullOperationen möglich. Die Kommunikation läuft hierbei über den NIM-Service Handler (nimsh), der eine „leichte“ Verschlüsselung und Authentifizierung über System-IDs bietet. Ansonsten bleiben als Alternativen, entweder das unsichere Protokoll rsh zu benutzen oder nimsh in Kerberos einzubinden. Ablauf einer Rücksicherung Alle Zutaten zu einer Rücksicherung sind nun vorhanden: ein NIM-Master mit den bereitliegenden Backups, Ressourcen und Definitionen. Was muss im Fall einer Rücksicherung getan werden? Wir setzen voraus, dass das System nicht mehr starttbar ist, die Platten aus der rootvg defekt waren und ausgetauscht wurden. Zuerst gilt es, die vorhandenen Ressourcen dem Client zur Verfügung zu stellen (zu „allokieren“). Den recht komplexen Befehl hierfür zeigt Abbildung 4. Mit smitty nim_bosinst:"mksysb" wird innerhalb des Managementwerkzeugs die Eingabemaske für alle Parameter erreicht. Damit werden die Ressourcen zur Benutzung durch den Client freigeschaltet und die entsprechenden NFS-Freigaben eingerichtet. Im Verzeichnis /tftpboot wird der entsprechende Boot Kernel bereitgelegt und der bootp-Daemon so konfiguriert, dass er den Kernel bei Anfrage durch den Client über das tftp-Protokoll überträgt. Der Client muss jetzt nur noch diesen Request aussenden. Im Fall einer laufenden Maschine würde einfach die Boot-Liste mit dem Befehl bootlist zum Hochfahren über Netzwerk konfiguriert und ein Reboot ausgeführt. Das System ist aber nach dem Ausfall nicht erreichbar. Wir benötigen einen Zugang zur Systemkonsole. Das Client-System wird in das SMS-Menü gebootet. Im RIPL-Menü werden, falls nicht schon vorhanden, die Netzwerkparameter, die eigene IP-Adresse, die NIM-Master-IP, die NIM bietet folgende Vorteile: ►► ►► ►► ►► ►► ►► Software und Verwaltung werden zentral auf einem Server gehalten. Es sind mehrere Installationen zur selben Zeit möglich. Eine Installation kann zeitlich gesteuert werden. Eine Installation kann nicht-interaktiv und automatisiert erfolgen. Eine Vorortanwesenheit (CD-Wechseln) ist nicht erforderlich. Die Installation ist üblicherweise schneller als über CD oder Band. Netzwerkmaske und das Gateway eingetragen. Im SMS werden unter Punkt 5 das Boot Device und das Netzwerk ausgewählt. Der NIM-Client schickt anschließend einen Boot Request zum NIM-Master, der mit Rücksendung eines Kernels beantwortet wird. Der Kernel startet und hängt über NFS den SPOT nach /usr. Die Prozesse zur Neueinrichtung der rootvg und das Zurückspielen des Backup beginnen. Nach dem abschließen­den Reboot steht der Client wieder zur Verfügung. Diese Prozedur kann nicht nur zur Rücksicherung von NIM-Clients benutzt werden, sondern auch zum Klonen. Eine aufwändige Konfiguration des Clients wird hier vereinfacht. Weitere Möglichkeiten des Backups Eine weitere, sehr bequeme Backup-Methode stellt der Befehl alt_disk_install (seit AIX 5.3 alt_disk_copy) dar, der im Paket bos.alt_disk_install.rte enthalten ist. Hierzu wird die doppelte Anzahl der vorhandenen Boot-Platten benötigt. Liegt die rootvg auf hdisk0 und hdisk1 und hat die freien Platten hdisk2 und hdisk3 zur Verfügung, lässt sich die rootvg mit dem Befehl alt_disk_install –C –B -n hdisk2 hdisk3 online auf diese Platten klonen. Die Option –C erstellt den Klon, -B verhindert die automatische Umsetzung der Boot-Liste und –n belässt das „neue“ System als NIMClient. Während des Kopiervorgangs ist diese Datenträgergruppe namens altinst_rootvg mit ihren Dateisystemen online, wird danach aber geschlossen. Der Befehl bootlist –m normal hdisk2 hdisk3 und ein anschließender Reboot können diese Platten als rootvg aktivieren. Die alte rootvg steht dann noch unter dem Namen old_rootvg (offline) zur Verfügung, kann allerdings auch wieder aktiviert werden. Ein Backup-Konzept ORDIX News 1/2009 41 Betriebssysteme auf diese Weise umschließt demnach eine regelmäßige Löschung der altinst_rootvg (alt_disk_install –X) mit anschließen­ der Neuerstellung auf nächtlicher oder wöchentlicher Basis. Der Vorteil ist, dass das Betriebsystem nach dem Reboot sofort zur Verfügung steht und nicht zeitaufwändig restauriert werden muss. Vereinfachung von Betriebssystem­ migrationen und -updates Eine Verbindung der Technologien von NIM und alt_inst_install bietet der Befehl nimadm (NIM Alternate Disk Manager). Während alt_disk_install dafür sorgt, dass die Daten von der rootvg auf die altinst_ rootvg transferiert werden, kann NIM gleichGlossar zeitig die Software aktualisieren, d. h. ein Update oder eine Migration durchführen. Das System bleibt dabei online. Die aktualisierte altinst_rootvg kann dann zu einem späteren Zeitpunkt hochgefahren werden. Das Altsystem steht danach noch als Fallback zur Verfügung. Die Downtime wird so auf die Reboot-Dauer minimiert. Das sind bei den Partitionen auf POWER5/6-Systemen nur noch wenige Minuten. Im Falle einer gespiegelten rootvg ist dabei nicht das Vorhandensein von 4 Platten notwendig. Da IBM noch immer keine Migrationen von gespiegelten rootvgs unterstützt, kann der Spiegel aufgebrochen und die freiwerdende Platte als altinst_rootvg benutzt werden. Voraussetzung für den Aufbau einer alternativen rootvg ist jedoch, dass der Client in eine funktionsfähige NIM-Umgebung eingebunden ist. NIM Network Installation Manager. NIM ist ein in AIX enthaltenes Softwaretool. Fazit smitty ASCII-basiertes, menü-gesteuertes Verwaltungswerkzeug für AIX. smitty fast path Smitty-Untermenüs können durch Angabe des Fast Path direkt erreicht werden. rootvg Die Datenträgergruppe mit den AIX-Systemdateien. LPP Source Licensed Program Products, installierbare Programmpakete. RIPL-Menü Remote Initial Program Load, ein Teil des System Management Service (SMS). SMS System Management Service, Boot-Konfigurationsmenü, kurzzeitig während des Boot-Vorgangs über die Konsole erreichbar. ODM Object Data Manager. Das ist die binäre Konfigurationsverwaltung von AIX. IBM AIX bietet seit vielen Jahren innerhalb seines Standardinstallationsumfangs ohne Extrakosten einige Schätze in punkto System­ installation, -backup und -recovery, die noch nicht überall „geborgen“ wurden. Zwar erhöht sich durch die Einführung von NIM der Verwaltungsaufwand, jedoch bringt die erhöhte Flexibilität und die Fähigkeit der Automation von Prozessen eine Erhöhung der Effizienz in der Installation schon ab wenigen angeschlossenen Client-Systemen. Dr. Uwe Bechthold ([email protected]). Seminarempfehlung: AIX Systemadministration Grundlagen ►► Informationen/Online-Anmeldung: http://training.ordix.de/seminar.php?nr=557 In diesem Seminar lernen Sie das System Management und die Systemadministration eines AIX-Betriebssystems kennen. Von der Betriebssysteminstallation über die Benutzer- und Festplattenverwaltung bis hin zur Datensicherung werden Grundlagen der Administration eines AIX-Systems erarbeitet. Sie sind nach dem Seminar in der Lage, ein AIX-System aufzusetzen und beherrschen die grundlegenden Systemadministrations­ tätigkeiten. Termine 25.05.- 29.05.2009 in Wiesbaden 24.08.- 28.08.2009 in Wiesbaden 02.11. - 06.11.2009 in Wiesbaden Seminar-ID: BS-12 Dauer: 5 Tage Preis pro Teilnehmer: 1.990,00 € (zzgl. MwSt.) Frühbucherpreis: 1.791,00 € (zzgl. MwSt.) Wir führen unsere Seminare auch jederzeit an einem geeigneten Ort Ihrer Wahl durch und bringen, wenn nötig, auch das entsprechende Equipment mit. Informieren Sie sich am besten im Internet über unsere Inhouse-Seminare und die mobilen Schulungen: http://training.ordix.de. 42 ORDIX News 1/2009 Java/JEE Eclipse-Kurzreferenz Navigation im Editor Öffnen, Speichern, Schließen Alt + bzw. Alt + Navigation in der History zum letzten/nächsten Registerblatt Strg + S Speichern Strg + Shift + S Alles speichern Cursor springt zur zugehörigen Klammer Strg + Shift + R Öffnen einer Ressource Strg + Shift + T Öffnen einer Klasse Strg + Shift + F4 Schließen aller Tabs Strg + F4 Schließen des aktuellen Tabs Strg + Shift + P Strg + Shift + Up bzw. Cursor springt zwischen MethoStrg + Shift + Down den und Membern Strg + L n Cursor springt zur Zeile n Strg + , bzw. Strg + . Cursor springt zum vorherigen bzw. nächsten Fehler Strg + E Editor-Tab wechseln über Auswahlbox Strg + M Maximieren/Minimieren des aktuellen Editor-Tabs F3 Zur Deklaration einer Methode oder eines Objektes springen F4 Zur „Hierarchy“ einer Methode oder eines Objektes springen Strg + Alt + H Anzeige aller Methoden, die die aktuelle Methode aufrufen (call hierarchy) Strg + T Anzeige der Klassen bzw. Methoden, die ein Objekt defi­nieren bzw. implementieren Manipulation von Quellcode im Editor Strg + Space Content Assist für den aktuellen Befehl aktivieren Alt + Shift + M Extract Method: Markierten Bereich einer Methode in eine neue Methode extrahieren Alt + Shift + R Refactoring des aktuell ausgewählten Elements Strg + 7 Auswahl ein- bzw. auskommentieren Strg + Shift + M Fehlende Imports ergänzen (Add Imports) Strg + Shift + O Fehlende Imports ergänzen und überflüssige Imports löschen (Organize Imports) Alt + Shift + J Javadoc-Kommentar vor Klassen/Methoden einfügen Einfügen, Löschen, Verschieben, Suchen Run und Debug Alt + bzw. Alt + Verschieben der markierten Zeilen im Dokument Strg + F11 Ausführen (run) eines aktiven Editor-Tabs bzw. einer ausgewählten Ressource Strg + Alt + bzw. Strg + Alt + Aktuelle bzw. markierte Zeilen nach oben/unten duplizieren F11 Debugging eines aktiven Editor-Tabs bzw. einer ausgewählten Ressource Strg + C Markierten Inhalt kopieren F5 Gehe in die Methode (während des Debugging) Strg + V Markierten Inhalt einfügen F6 Strg + X Markierten Inhalt ausschneiden Die aktuelle Methode überspringen (während des Debugging) Strg + D Aktuelle bzw. markierte Zeilen löschen F7 Gehe einen Schritt zurück (während des Debugging) Strg + F2 Abbrechen (Terminate) des Debugging Strg + Entf Nachfolgendes Wort löschen Strg + Backspace Vorheriges Wort löschen Strg + Shift + Entf Den Rest der Zeile ab der aktuellen Position löschen Strg + F Suchen und Ersetzen (im Editor) Strg + K Suche nächsten Treffer mit markiertem Text (im Editor) Strg + Shift + K Suche vorherigen Treffer mit markiertem Text (im Editor) Xms Strg + H Search-Dialog zum Durchsuchen von Dateien, Projekten etc. öffnen Initiale Arbeitsspeicherzuteilung für die Anwendung (Standard 64 MB) Xmx Strg + Shift + G Suche Referenzen auf markiertes Objekt im Workspace Maximale Arbeitsspeicherzuteilung für die Anwendung (bei Eclipse standardmäßig 256 MB) XX:PermSize Arbeitsspeicher für den Classloader (Standard 64 MB), Erhöhung, wenn die Anwendung einen „permanent generation memory error“ meldet OutOfMemoryErrors Aufrufparameter für die Anpassung der Speicherzuteilung einer Java-Anwendung Beispiel: eclipse.exe -vmargs –Xms512m -Xmx512m -XX:PermSize=128m ORDIX News 1/2009 43 Open Source Tipps und Tricks aus der Unix-Welt Mit “screen” zur Schirmherrschaft Dieser Artikel richtet sich an Unix-Systemadministratoren, die die Arbeit mit der Shell effektiver gestalten möchten. Wer Zeuge oder Teilnehmer eines Telefongesprächs zwischen zwei Systemadministratoren ist, die gleichzeitig auf einem Unix-System eingeloggt sind, der fühlt sich nicht selten in die längst vergangen geglaubte Zeit der Akustikkoppler zurückversetzt. Befehle und Terminalausgaben werden mit beeindruckend kleiner Baudrate und einer erstaunlich hohen Zahl an Übertragungsfehlern hin- und hergesendet und der DuplexModus führt im schlimmsten Fall zum Verbindungsabbruch. In diesem Artikel stellen wir Ihnen die freie Software „screen“ vor, welche uns neben vielen weiteren sehr nützlichen Funktionalitäten die Möglichkeit gibt, diese Telefonate deutlich effektiver zu gestalten. Was ist „screen“? Mehrere Sitzungen in einem Fenster Das Programm screen ist ein Terminal-Multiplexer, der es dem Anwender ermöglicht, in einer Terminal-Sitzung (z. B. „putty“-Fenster) eine oder mehrere virtuelle Terminal-Sitzungen zu starten. Diese virtuellen Sitzungen können anschließend u. a. mit beliebigen weiteren Benutzern parallel genutzt werden. Um eine virtuelle Sitzung zu starten ruft der Anwender lediglich das Kommando screen auf. Nun befindet er sich in einem ersten virtuellen Terminal. Jedes dieser Terminals erhält eine Nummer beginnend mit 0 und optional einen sprechenderen Namen. Zusätzlich lassen sich die Sitzungen auch jederzeit unterbrechen und zu einem späteren Zeitpunkt wieder aufnehmen. Aber dazu später mehr. Beim screen handelt es sich um GNU-Software der Free Software Foundation. Das Tool kann kostenlos genutzt werden. Auf LinuxSys­temen ist es häufig bereits standardmäßig installiert. Auf allen anderen Unix-Derivaten kann es problemlos nachinstalliert werden. 44 ORDIX News 1/2009 Screen-Kommandos lassen sich innerhalb einer solchen Sitzung mit der Tastenkombination STRG-a aufrufen (im weiteren Verlauf mit C-a gekennzeichnet). Mit C-a c (d. h. STRG-a und dann c drücken) lassen sich nun beliebig viele weitere Terminals erstellen. Mit C-a n lässt sich anschließend zwischen den Terminals hin- und herschalten. Zur besseren Übersicht lassen sich die verschiedenen Terminals mit der Kombination C-a A auch mit einem sprechenden Namen versehen. Open Source Sitzungen unterbrechen und fortsetzen C-a C-a C-a C-a C-a C-a C-a C-a C-a Der vielleicht größte Nutzen des screen wird jedoch deutlich, wenn der Benutzer bewusst oder unabsichtlich das Terminalfenster schließt oder die Netzwerkverbindung zum Server abbricht. Normalerweise wird die Sitzung in einem solchen Fall abgebrochen und alle noch von ihr gestarteten Programme sind beendet. Dies ist z. B. bei einem noch nicht beendeten Kopiervorgang oder einer nicht gespeicherten Editiersitzung mit dem vi sehr ärgerlich. Ein screen-Terminal hingegen bleibt solange aktiv, bis es explizit geschlossen wird. Um eine alte screen-Sitzung nach abgebrochener Ver­bindung und erneutem Login wieder aufzunehmen, reicht das Kommando screen –r. Das Terminal befindet sich nun wieder im gleichen Zustand wie zum Zeitpunkt vor dem Verbindungsabbruch. Eventuell vorher gestartete Programme sind zwischenzeitlich weitergelaufen bzw. weiterhin aktiv. Mit der Kombination C-a d ist es zudem auch möglich, eine screen-Sitzung bewusst zu verlassen, um sie später wieder aufzunehmen. Der Aufruf screen –ls listet die derzeit existierenden screen-Sitzungen eines Benutzers auf. Mit der Kombination C-a x ist es möglich, eine aktuell laufende screen-Sitzung zu sperren, so dass sie nur mit Passworteingabe wieder aufgenommen werden kann. Mehrbenutzermodus Eine weitere Stärke des screen ist der Mehrbenutzermodus. Arbeiten zwei Benutzer unter der gleichen Kennung auf dem System (z. B. root), so kann sich einer der Benutzer mittels screen –x zu einer laufenden screen-Sitzung hinzuschalten. Die Administratoren sind anschließend in der Lage, parallel an dieser Sitzung zu arbeiten. Normalerweise wird dies hauptsächlich dazu genutzt, um einem anderen Administrator sein eigenes Terminal zu zeigen – er kann jedoch auch jederzeit selbst Kommandos eingeben. Es ist natürlich auch möglich, einem anderen Unix-Benutzer Zugriff auf die eigene screenSitzung zu erlauben. Zu diesem Zweck wird mittels C-a : in den Kommando-Modus gewechselt (ähnlich dem Last-Line-Modus des vi) und mit folgenden Kommandos der Zugang z. B. für den Benutzer user01 freigeschaltet: multiuser on acladd user01 Der Benutzer user01 kann sich nun mit dem Kommando screen –c root/ zur screen- c k n p " d r x H Neues Terminal erzeugen (create) Terminal schließen (kill) Zum nächsten Terminal wechseln (next) Zum vorherigen Terminal wechseln (previous) Liste der Terminals zur Auswahl anzeigen Terminal verlassen, ohne es zu beenden (detach) Sitzung wieder aufnehmen (recover) Sitzung sperren Logging starten/stoppen Abb. 1: Wichtige Tastenkürzel des screen. Link ►► [1] Screen-Projekthomepage: http://www.gnu.org/software/screen/ Sitzung des Benutzers root verbinden. Für diese Funktionalität muss jedoch das s-Bit für screen gesetzt sein, was nicht immer standardmäßig der Fall ist. Screen konfigurieren screen beinhaltet eine Reihe von Konfigurationsparametern, die wahlweise im laufenden Betrieb im Last-Line-Modus mit C-a : interaktiv eingegeben oder in der Konfigurationsdatei $HOME/.screenrc eingetragen werden können. Die Manpage screen(1) zeigt eine beeindruckend lange Liste aller Parameter und deren Auswirkungen. Weitere Funktionalitäten Nun haben wir zwar die wichtigsten, aber bei weitem nicht alle Features des screen vorgestellt. Weitere Funktionen sind u. a.: • • • • Logging von Terminal-Output mit C-a H (analog script) Terminalausgabenüberwachung mit C-a M Interaktive Programme analog nohup starten Geteilte Terminalfenster (zwei Terminals in einem Fenster anzeigen) Fazit screen ist ein sehr nützliches Werkzeug, das dem Unix-Anwender, der häufig auf der Shell arbeitet, das Leben an sehr vielen Stellen erheblich erleichtern kann. Probieren Sie es aus! Christof Amelunxen ([email protected]). ORDIX News 1/2009 45 Aktuell Rückblick DOAG Konferenz und Schulungstag 2008 Das ORDIX Six-Pack überzeugt Seit 20 Jahren ist die Deutsche Oracle Anwenderkonferenz die Know-how-Plattform der deutschsprachigen Oracle Community. Mit neuem Namen und neuem Konzept startete die „DOAG Konferenz + Ausstellung 2008“ im Dezember in Nürnberg nun erstmalig 3-tägig durch. Auch ORDIX schickte wieder einige Oracle-Spezialisten ins Rennen. einfach. gut. informiert. einfach. gut. geschult. ORDIX stellte in 5 hochkarätigen Vorträgen und auf der begleitenden DOAG Ausstellung seine Leistungen im Oracle-Umfeld vor. Direkt im Anschluss an die Konferenz bot die DOAG am 4. Dezember 2008 den DOAG Schulungstag an. In diesem Rahmen präsentierte Andreas Kother das Seminar „Hochverfügbarkeit mit Physical Data Guard“ als Kompaktkurs. In diesem Tagesseminar ging es um die Hochverfügbarkeit von Daten. Diese wird heute zunehmend wichtiger, während die Forderung nach 7x24 Stunden Verfügbarkeit steigt. Seit der Version 7.3 bietet Oracle die physikalische Standby-Datenbank an, die mit Oracle 9 zu Data Guard weiterentwickelt wurde. • • • • • Compression - Anwendungsmöglichkeiten und Praxiseinsatz Referent: Klaus Reimers SQL Performance auf RAC - Piraten des Interconnects Referent: Martin Hoermann Oracle Audit Vault - das zentrale Data Warehouse für Audit Daten Referent: Kathleen Hock PL/SQL Web-Services mit Oracle 11g Referent: Markus Fiegler Der RAC „Overhead“ - Möglichkeiten und Grenzen Referent: Guido Saxler Dabei fand der Vortrag „PL/SQL Werbservices mit Oracle 11g“ so großen Anklang, dass die Besucher sogar im Stehen zuhörten und Fiegler seinen Vortrag ein zweites Mal präsentieren durfte. 46 ORDIX News 1/2009 einfach. gut. kommuniziert. Neben den Möglichkeiten, sich per Vortragsoder Schulungstagsteilnahme über die neuesten Oracle Features zu informieren, bot auch das Rahmenprogramm die Chance auf kommunikatives Fachsimpeln. Am DOAG Gala Abend sorgten eine Jazz- und eine Rockband für eine angenehme Atmosphäre, um neue Kontakte zu knüpfen und die Oracle Themen weiter zu diskutieren. Aktuell Weitere Informationen und Vortragsunterlagen Bandbreite an Oracle Seminaren im ORDIX Trainingsshop unter http://training.ordix.de. Wer sich für weiterführende Inhalte zu den Vortrags- oder den Schulungsthemen interessiert, für den lohnt sich ein Blick auf unsere Internetseiten unter http://www.ordix.de und die Gerne können Sie uns auch direkt ansprechen und die Vortragsunterlagen anfordern: Stefanie Heither ([email protected]). ORDIX Engagement bei DOAG Regionalgruppe Rhein-Main Im Mai 2008 haben die ORDIX Datenbankspezialisten Andreas Kother und Klaus Günther die Leitung der DOAG Regionalgruppe Osnabrück/Bielefeld/Münster übernommen Hinzu kommt nun die Leitung der Regionalgruppe Rhein-Main durch Kathleen Hock, die sich die Funktion zukünftig mit Thomas Tretter teilen wird Ein starkes Duo Die Leitung einer Regionalgruppe beinhaltet die Planung, Organisation und Durchführung sowie die Vor- und Nachbereitung der Regionaltreffen. Die Auswahl der Referenten und der Veranstaltungsorte erfordern ein ausgedehntes Kontaktnetzwerk und zusätzlichen zeitlichen Aufwand, da die Leitungsaufgaben zumeist neben dem eigentlichen Berufsalltag erledigt werden. Um das bestehende Netzwerk etwas aufzurüsten und das Wissensspektrum zu erweitern, wird Kathleen Hock, Oracle Consultant der ORDIX AG, den vormals alleinigen Regionalleiter Thomas Tretter unterstützen. Gemeinsam werden sie fortan das Ziel verfolgen, den Teilnehmern Oracle-Know-how auf hohem Qualitätsniveau zu vermitteln und einen optimalen Mix aus qualifizierten Referenten und spannenden Themen anzubieten. Kathleen Hock zu ihrer neuen Funktion „Ich selbst habe bereits Vorträge beim Regionaltreffen Rhein-Main sowie auf der DOAG Konferenz 2008 gehalten. Bei diesen Veran- Kathleen Hock, die sich seit Februar 2009 die Leitung der DOAG Regionalgruppe Rhein-Main mit Thomas Tretter teilt staltungen lernte ich das DOAG Umfeld und das DOAG Team intensiver kennen und schätzen, so dass ich mich heute gern weiter engagieren möchte. Mir geht es vor allem darum, zusammen mit Herrn Tretter wichtige Oracle Themen bei den Anwendern zu adressieren und zu platzieren, um so zu einem konstruktiven Informationsaustausch beizutragen.“ Stefanie Heither ([email protected]). ORDIX News 1/2009 47 IT-Management & Consulting Ganzheitliches IT-Management löst IT-Aufgaben über und unter der Oberfläche! Meist geht es in IT-Landschaften in erster Linie darum, technische Probleme zu lösen. Doch die technischen Probleme sind oft nur die Spitze des Eisbergs – häufig ist ein Blick unter die Oberfläche nötig. Wir unterstützen Sie dabei mit Beratung, Schulung, Coaching und coniatos™ Checks zu den Themen: • IT-Strategie Entwicklung und Umsetzung • IT-Management Aufgaben und Frameworks (COBIT, ITIL, PRINCE2) • Krisenmanagement in IT-Projekten • Effizientes Projektmanagement • Entwicklung erfolgreicher Teams • Zielorientierte Durchführung von Meetings Coniatos hilft Ihnen, Ihre IT ganzheitlich zu optimieren: auf der fachlichen Ebene bei IT-Architektur und Technik, auf der Prozessebene z. B. im Projektmanagement und auf der sozialen Ebene z. B. bei der Verbesserung der Kommunikation und des Konfliktmanagements. coniatos AG Kreuzberger Ring 13 65205 Wiesbaden Tel: 0611 77840-00 E-Mail: [email protected] Internet: www.coniatos.de
