ORDIX News. 15 Jahre ORDIX oder Wenn einer eine Reise tut... S. 27. Application Server im Vergleich BEA WebLogic Server S. 12

Transkript

1 ORDIX News Das IT-Magazin der ORDIX AG Ausgabe 2/2005 2,20 15 Jahre ORDIX oder Wenn einer eine Reise tut... S. 27 Application Server im Vergleich BEA WebLogic Server S. 12 Partnerschaft ORDIX und VMware ORDIX ist zertifizierter VMware VIP Enterprise Partner S. 21 Backup und Recovery mit Oracle 10g Näher am Original: Data Guard S. 44 HP OpenView Performance Insight Vom Netzwerk-Tool zum strategischen ITIL Reporting S. 34

2 Editorial Paderborn, Juni 2005 Was nun? 15 Jahre ORDIX, knapp 40 mal habe ich mich auf diese Art an Sie, unsere Kunden und Leser gewandt. Eigentlich sollte ich dieses Mal nur etwas über diese 15 Jahre schreiben. Aber dann kam die Wahl in NRW ( Nordrhein-Westfalen für die Bayern, Baden-Württemberger...); der Kanzler, genauer: der SPD Vorsitzende Münti, proklamiert Neuwahlen. Da werfe ich doch alles in den Papierkorb (und weg ist bei mir weg, also nichts von wegen wieder holen aus dem Trash ) und fange mit dem Editorial ein weiteres, inzwischen fünftes Mal von neuem an. Wird jetzt nach der Wahl alles besser oder anders? Eine Woche später gab es erste Meldungen zum Konzept sofern man von einem solchen sprechen kann. Mehrwertsteuer rauf, Pendlerpauschale und Eigenheimzulage runter. Hatten die das nicht vor ein paar Monaten noch blockiert? Die FDP ist sowieso gegen alle (Steuer-)Pläne der CDU. Aber natürlich gibt es trotzdem eine klare Koalitionsaussage. Die anderen zoffen sich (Koalitionskrise genannt), ob überhaupt und wenn, wie wird der Bundestag aufgelöst. Also weiterhin Kasperltheater in Berlin. Die Aufbruchstimmung dürfte sich spätestens nach dem jetzt noch kommenden Sommertheater wieder auf ein Normalmaß reduziert haben. Schade. Also schreibe ich doch noch etwas über 15 Jahre ORDIX. Hier bleibt nicht nur die Regierung stabil. Was bedeuten 15 Jahre? Der Mensch an sich befindet sich in diesem Alter mehr oder weniger intensiv in der Pubertät. Ein Unternehmen liegt damit laut Wirtschaftswoche 20/2005 knapp unter dem Durchschnittsalter von 18 Jahren. Ich dachte bis dato immer, dass ich ein alter Vorstand eines jungen Unternehmens in einer relativ jungen Branche bin. Ich scheine aber, ein nicht mehr ganz junger Vorstand in einem relativ alten Unternehmen einer nicht genau zu taxierenden Branche zu sein. Einiges hat sich getan in dieser Zeit: Angefangen vom Programmstarter Windows 2.1 (notwendiger Hauptspeicher: 16 MB) bis hin zum Programmstarter Windows 2003 bzw. XP (notwendiger Hauptspeicher: mindestens 512 MB). Gott sei Dank sind die Preise für Hauptspeicher gesunken. Das World Wide Web hat sich gigantisch entwickelt. Mit Java und J2EE sind neue Technologien entstanden. Aber vielleicht greift man irgendwann auch mal wieder auf C-Programmierer zurück, wie im Jahr 1999, als plötzlich COBOL-, PL1- und andere Programmierer alter Sprachen gesucht wurden. Viele Unternehmen, die 1990 noch existierten, sind verschwunden (Nixdorf, SNI, SCS, Sequent, Pyramid, Compaq, DEC, Tandem...). Einige davon habe ich relativ aktiv in den letzten 25 Jahren miterlebt (siehe Interview Seite 30). In dieser Ausgabe finden Sie einiges zu diesen vergangenen 15 Jahren. Sie werden daneben auch erkennen, dass wir weiterhin an unseren Tugenden feilen. Z. B. Konstanz: 12 Jahre ORDIX Open, das Schachturnier für den Breitensport mit hochkarätigen Topspielern. Z. B. fachliches Know-how rund um Oracle (Optimizer, Backup und Recovery), DB2 (es wurde wieder was von Informix eingebaut) und Informix (auch hier heißt die Version nun 10). Mit BPEL wagen wir uns in ein neues Terrain. Daneben gibt es aus dem System Management Bereich Interessantes über HP Open View. Einmal mehr schicke ich Sie auch nach 15 Jahren mit einer interessanten ORDIX News in die Sommerpause. Und wenn ich mir den Müll ansehe, der da in den nächsten Monaten in Berlin produziert wird, vielleicht hätte ich doch noch mal in meinem elektronischen Papierkorb nachsehen sollen... Wolfgang Kögler 3

3 Inhaltsverzeichnis Unix/Linux/Open Source Standards 40...TYPO3 (Teil II): Content. Einfach. Vielfältig. Wir beschreiben die In stal la tion und Einrichtung des CMS unter Berücksichtigung eines eigenen Templates Editorial 04...Inhalt 24...Seminarübersicht: Preise, Termine... bis Dezember Impressum System Management Java/XML Titelthema 34...HP OpenView Performance Insight: Vom Netzwerk-Tool zum strategischen ITIL Reporting Eine Kurzvor stellung des Reportingtools HP OpenView Performance Insight und dessen Wandlung vom Netzwerk Performancetool zum strategischen Bestandteil der HP OpenView Familie Application Server im Vergleich (Teil IV): BEA WebLogic Server Wir stellen den Application Server von BEA WebLogic vor, listen seine Kompatibilität gegenüber den von SUN erstellten Standards auf und sprechen Möglichkeiten der automatischen Konfiguration und Administration an. Titelthema Datenbanken Aktuell 05...DB2 HADR (Teil I): High Availability Disaster Recovery Bei steigender Datenmenge entsteht das Problem eines schnellen Recoverys. Der Artikel beschreibt die Funktionsweise von DB2 High Availability Disaster Recovery Open Source für den Mittelstand 10 Jahre erfolgreiche Partnerschaft: KARRENA und ORDIX AG 08...Verlagerung von Java-Anwendungen in die Datenbank (Teil I) Beispielhaft stellen wir das Ausführen der Anwendungen innerhalb der Datenbank vor und erläutern ein Sicherheitskonzept sowie die Anwendungsmöglichkeiten von Java Stored Pro cedures Business Process Execution Language (BPEL), Teil I: Web Services im Takt Die Integration von Web Services, um Geschäftsprozesse abzubilden, braucht Standards. BPEL stellt einen Standard als Plattform, auf der Geschäftsprozesse technisch abgebildet, modelliert und kontrolliert ausgeführt werden können IBM Informix Dynamic Server 10.00: The next Generation... Ein erster, allgemeiner Überblick über die Neuerungen des aktuellen IBM Informix Release Oracle 10g (Teil V): dbms_stats Mit 10g liefert Oracle durch das erweiterte Paket dbms_stats eine gute Möglichkeit, auch schwierige Statistikprobleme zu lösen. Hier erhalten Sie einen ersten Einstieg Backup und Recovery mit Oracle 10g (Teil III): Näher am Original: Data Guard Titelthema Lesen Sie über die Neuerungen bei Data Guard mit 10g. Einen Schwerpunkt bildet die Flashback Integration Partnerschaft ORDIX und VMware: ORDIX ist zertifi zierter VMware VIP Enterprise Partner Larry Ratlos Rätsel Widerspenstiges Oracle Jahre ORDIX oder Wenn einer eine Reise tut... ORDIX feiert sein Jubiläum und zieht über die Zusammenarbeit mit seinen Kunden das Fazit: Vertrauen war und ist die Basis für den gemeinsamen Erfolg Sind 15 Jahre im Zeitalter der IT jung oder alt? Interview mit Wolfgang Kögler. Titelthema 33...Chess Classic Mainz 2005 Rätseln Sie mit und spielen Sie im August gegen die Schach-Könige! 47...Einladung zum 3. ORDIX Fachtreff in 2005 VMware Serverkonsolidierung und Ressourcenoptimierung leichter gemacht. Titelthema 4

4 Datenbanken DB2 HADR (Teil I) High Availability Disaster Recovery Die von Informix unter dem Namen High Availability Data Replication bekannte Replikation ist ab der Version 8.2 von DB2 unter dem Namen HADR verfügbar. Im ersten Teil dieses Artikels wollen wir die generelle Funktionsweise vorstellen. Der zweite Teil beschäftigt sich dann mit der praktischen Umsetzung. Übersicht HADR ist eine Datenbankreplikation, die vor dem Ausfall eines Datenbankservers schützt. Abbildung 1 zeigt die generelle Arbeitsweise einer HADR. Die Datenbank wird dabei den Clients innerhalb sehr kurzer Zeit ohne Datenverlust auf einem anderen Server zur Verfügung gestellt. Dafür werden zwei Server mit gleicher Hardund Softwareausstattung benötigt. Auf beiden Servern wird eine Datenbank erzeugt. Die Datenbank, mit der im normalen Betrieb gearbeitet wird, ist die Primärdatenbank. Die andere, die für den Fehlerfall verwendet wird, die Bereitschafts- oder Standby-Datenbank. Der Anwender greift immer auf die Primärdatenbank zu. Die Änderungen auf der Primärdatenbank werden auf der Standby-Datenbank nachgefahren. Dazu werden die Protokolldateien von der Primärdatenbank zur Standby- Datenbank übertragen und dort nachgefahren. Die Standby-Datenbank befindet sich permanent im Status Aktualisierende Wiederherstellung wird ausgeführt. Wenn die primäre Datenbank ausfällt, übernimmt die Standby-Datenbank die Funktion der Primärdatenbank. Über die automatische Client-Weiterleitung kann dies für die Clients transparent erfolgen. Systemvoraussetzungen Die Rechner, auf denen die Primärdatenbank und die Standby-Datenbank laufen, müssen auf der gleichen Hard- und Software aufgebaut sein. Insbesondere, da die Standby-Datenbank nach der Übernahme zur Primärdatenbank wird. Bei der Hardware müssen Produkte des gleichen Herstellers mit der gleichen Architektur verwendet werden. Die Versionen und Korrekturstände des Betriebsystems müssen dieselben sein. Zwischen beiden Rechnern wird eine schnelle TCP-IP Netzwerkverbindung benötigt. HADR unterstützt nur das Netzwerkprotokoll TCP/IP. Der Artikel richtet sich an Rechenzentrumsleiter und DB2 Administratoren, die die Funktionsweise von HADR verstehen und durch den Einsatz von HADR die Recovery-Zeiten bei einem Systemausfall minimieren wollen. DB2 Voraussetzungen Auf beiden Rechnern muss dieselbe DB2 Version mit gleichem Stand der Fix Packs installiert sein. Ein Mischen z. B. von 32 und 64 Bit Versionen ist nicht möglich. Tablespaces und Container müssen identisch im Bezug auf Typ (DMS oder SMS), Größe, Pfad und Dateityp angelegt werden. Durch die Verwendung von virtuellen Pfaden ist es möglich, auf beiden Maschinen auch unterschiedliche physikalische Pfade zu verwenden. Übersichtlicher ist es aber auf jeden Fall, beide Maschinen auch physikalisch identisch aufzubauen. Da alle Operationen sowohl im Bufferpool der Primärdatenbank als auch im Bufferpool der Standby-Datenbank wiederholt werden, müssen die Bufferpools auf beiden Maschinen dieselbe Größe haben. Einschränkungen HADR wird nur von der DB2 UDB Enterprise Server Edition (ESE) unterstützt. Die Datenbanksysteme dürfen nicht partitioniert sein. Da sich die Standby-Datenbank immer im Status Aktualisierende Wiederherstellung wird ausgeführt befindet, können Clients nur auf die Primärdatenbank zugreifen. Daher ist es nicht möglich, eine DB2 Agent Tabellen Indizes HADR Log-Writer TCP/IP HADR Log-Writer Logdateien Logpuffer Logdateien Parallel Log Replay Tabellen Indizes Abb. 1: Die Arbeitsweise des High Availability Disaster Recoverys. 5

5 Datenbanken HADR_LOCAL_HOST HADR_LOCAL_SVC HADR_REMOTE_HOST HADR_REMOTE_SVC HADR_REMOTE_INST HADR_TIMEOUT HADR_SYNCMODE Ist der lokale Rechnername, auf dem die Datenbank läuft. Ist der lokale Servicename oder die lokale Portnummer, über die HADR kommunizieren soll. Ist der Rechnername des anderen Rechners. Ist der Servicename oder die Portnummer, über die die HADR-Prozesse auf der Remote-Datenbank kommunizieren. Ist der Name der Instanz, unter der die Remote-Datenbank läuft. Ist die Zeit in Sekunden, die HADR beim Aufbau der Verbindung wartet, bevor es diese abbricht. Ist der von HADR verwendete Synchronisationsmodus. Abb. 2: Zu setzende Parameter in der Datenbankkonfiguration. Online-Sicherung der Standby-Datenbank und ihrer Protokolldateien zu erstellen. Start der Datenbank Änderungen, die an der Datenbankmanager- bzw. Datenbankkonfiguration vorgenommen werden, werden nicht repliziert und müssen manuell auf beiden Systemen vorgenommen werden. Datenbankkonfiguration Lokales Catch-up Fernes Catch-up anstehend Die Datenbankkonfigurationsparameter auf der Primärdatenbank und der Standby-Datenbank müssen identisch sein. Ansonsten kann es beim Nachfahren der Protokolldateien auf der Standby- Datenbank zu Fehlern kommen. Verbindung verloren Verbunden Fernes Catch-up Verbindung verloren Änderungen an den Konfigurationsparametern müssen manuell auf beiden Datenbanken vorgenommen werden. Bei dynamischen Parametern ist kein Neustart der Datenbank erforderlich. Bei nicht dynamischen Parametern muss die Datenbank neu gestartet werden. Durch ein schrittweises Upgrade ist es möglich, auch dies ohne große Ausfallzeit durchzuführen. Die Standby-Datenbank empfängt alle Protokolldateien in ihrem Log Receive Buffer. Die Standardeinstellung für die Größe des Puffers ist die doppelte Größe von LOGBUFSZ. Um an dieser Stelle Engpässe zu vermeiden, ist es sinnvoll, die Größe des Log Receive Buffers zu erhöhen. Dies wird über die Variable DB2_HADR_BUF_SIZE der DB2 Profile Registry vorgenommen. Konfigurationsparameter Für HADR gibt es spezielle Parameter in der Datenbankkonfiguration. Durch das Setzen der Parameter wird eine Datenbank aber noch nicht zu einer HADR-Datenbank. Dies muss mit den entsprechenden Kommandos (HADR START und HADR STOP) vorgenommen werden. Die zu setzenden Parameter sind in Abbildung 2 beschrieben. Status der Standby-Datenbank Nach dem Starten der Standby-Datenbank durchläuft die Datenbank die in Abbildung 3 dargestellten Modi. Peerstatus Abb. 3: Status der Standby-Datenbank. Lokales Catch-up Nach dem Starten der Datenbank versucht diese, die Protokolldateien in ihrem lokalen Protokollverzeichnis zu lesen und nachzufahren. Dazu ist keine Verbindung zur Primärdatenbank erforderlich. Ein Zugriff auf die Datenbank ist in diesem Modus nicht möglich. Sind alle Protokolle nachgefahren und ist keine Verbindung zur Primärdatenbank vorhanden, wechselt die Standby-Datenbank in den Status Fernes Catch-up anstehend. Sobald eine Verbindung zur Primärdatenbank vorhanden ist, wechselt sie in den Status Fernes Catch-up. Fernes Catch-up Die Primärdatenbank liest ihre Protokolldateien und überträgt diese zur Standby-Datenbank. Die Standby-Datenbank fährt die Protokolle nach. Wenn alle Protokolle übertragen und nachgefahren sind, wechseln beide Datenbanken in den Peerstatus. Peerstatus Im Peerstatus überträgt die Primärdatenbank, sobald eine Protokoll-Page auf die Platte geschrieben wird, diese an die Standby-Datenbank. Die Standby-Datenbank schreibt die 6

6 Datenbanken Protokoll-Pages in ihre Protokolldateien. Dadurch ist sichergestellt, dass die Reihenfolge der Protokolleinträge in beiden Datenbanken identisch sind. Danach werden die Transaktionen aus den Protokollen in der Standby-Datenbank nachgefahren. Der Status der Datenbank kann mit folgendem Kommando ermittelt werden: db2 get snapshot for database on sample Synchronisationsmodi Über den Konfigurationsparameter HADR_ SYNCMODE kann der Modus der Replikation eingestellt werden. Über den Modus wird festgelegt, wann eine Transaktion auf der Primärdatenbank nach einem COMMIT die Bestätigung erhält, dass die Transaktion festgeschrieben wurde. Durch den Modus wird zum einen die Transaktionsantwortzeit und zum anderen die Sicherheit beeinflusst. Wobei mit besserer Transaktionsantwortzeit die Sicherheit abnimmt. Im einzelnen gibt es die drei folgenden Synchronisationsmodi: SYNC (synchron) Der Synchronisationsmodus SYNC bietet die höchste Sicherheit gegen Datenverlust, hat aber die längsten Transaktionsantwortzeiten. Eine Transaktion auf dem Primärrechner wird erst dann als festgeschrieben betrachtet, wenn die Protokolleinträge auf dem Primärrechner in die Protokolldatei geschrieben wurden, die Protokolleinträge zur Standby-Datenbank übertragen wurden und auch dort in die Protokolldatei geschrieben wurden. Dadurch wird sichergestellt, dass Protokolleinträge einer festgeschriebenen Transaktion auf beiden Datenbanken vorhanden sind. NEARSYNC (fast synchron) Der Synchronisationsmodus NEARSYNC hat etwas kürzere Transaktionsantwortzeiten aber auch weniger Sicherheit. Eine Transaktion auf dem Primärrechner wird erst dann als festgeschrieben betrachtet, wenn die Protokolleinträge auf dem Primärrechner in die Protokolldatei geschrieben wurden, die Protokolleinträge zur Standby-Datenbank übertragen wurden und dort im Hauptspeicher angekommen sind. Glossar HADR High Availability Disaster Recovery DMS Database Managed Space. Plattenplatz, der vom DB-System verwaltet wird. SMS System Managed Space. Plattenplatz, der vom Betriebsystem verwaltet wird. Partitionierte DB Datenbank, die auf mehrere Rechner verteilt ist. Bei einem gleichzeitigen Ausfall der Systeme, kann es vorkommen, dass Protokolleinträge verloren gehen, wenn danach nur noch die Standby-Datenbank zur Verfügung steht. ASYNC (asynchron) Der Synchronisationsmodus ASYNC bietet die kürzesten Transaktionsantwortzeiten, aber auch die geringste Sicherheit. Eine Transaktion auf dem Primärrechner wird erst dann als festgeschrieben betrachtet, wenn die Protokolleinträge auf dem Primärrechner in die Protokolldatei geschrieben wurden und an die TCP-Schicht des Rechners übergeben wurden. Auch hier ist es möglich, dass Protokolldateien verloren gehen. Das Hauptproblem beim Verlust von Protokolldateien ist, dass die ursprüngliche Primärdatenbank, nicht mehr als Standby-Datenbank verwendet werden kann. In ihr sind Transaktionen festgeschrieben, die auf der ursprünglichen Standby-Datenbank nicht festgeschrieben waren, als diese die Funktion der Primärdatenbank übernommen hat. Um die ursprüngliche Primärdatenbank wieder als Standby-Datenbank zu verwenden, ist es notwendig, einen kompletten Restore durchzuführen. Automatische Client-Weiterleitung Bei der Funktionsübernahme verlieren die Clients die Verbindung zur Datenbank. Bei einem Zugriff auf die Datenbank kommt es zu einer Fehlermeldung. Dies kann mit der automatischen Client- Weiterleitung verhindert werden. Auch hier geht die aktuelle Verarbeitung verloren, nur der Verbindungsaufbau zur Standby-Datenbank erfolgt automatisch. Auf der Primärdatenbank kann ein alternativer Server für eine Datenbank hinterlegt werden. Die wird mit dem Kommando UPDATE ALTERNATE SERVER FOR DATABASE vorgenommen. Im folgenden Beispiel wird für die Datenbank sample der Rechner rechner2 und der Netzwerkport als Alternative eingetragen: db2 update alternate server for database sample using hostname rechner2 port Der Client bekommt diese Information dann beim Verbindungsaufbau zur Datenbank mitgeteilt. Ausblick Der zweite Teil des Artikels zeigt an einem kleinen Beispiel, wie HADR aufzusetzen und zu konfigurieren ist. Holger Demuth 7

7 Datenbanken Verlagerung von Java-Anwendungen in die Datenbank (Teil I) Erschienen in der DOAG News Q2/2005 Oracle stellt seit der Oracle-Datenbankversion eine Java Virtual Machine (OracleJVM) zur Verfügung. Mit Hilfe von OracleJVM besteht die Möglichkeit, Java-Anwendungen innerhalb der Datenbank ausführen zu lassen. Dieser Beitrag zeigt anhand von Beispielen, wie Java-Anwendungen in eine Oracle 10g Datenbank geladen und ausgeführt werden können. Dabei werden ein Sicherheitskonzept in Bezug auf die Java-Klassen und die Anwendungsmöglichkeiten von Java Stored Procedures erläutert. Im ersten Teil dieser Reihe werden die Java Stored Procedures vorgestellt und die Besonderheiten bei der Entwicklung von Java-Anwendungen für die OracleJVM skizziert. Im zweiten Teil gehen wir dann auf das Resolving-Konzept zum Auffinden aller von einer Klasse benötigten Klassen innerhalb der Datenbank sowie einige Anwendungsmöglichkeiten von Java Stored Procedures ein. Dieser Artikel richtet sich an Datenbank-Anwendungsentwickler, die sich zusätzlich zum PL/SQL auch für Java als serverseitige Datenbankprogrammiersprache entscheiden können. Einsatz von Java Stored Procedures In den meisten Fällen wird die Geschäftslogik sowohl von einer Datenbankanwendung als auch von Batchprogrammen aufgerufen. Mit Hilfe von Stored Procedures kann die Funktionalität zentral in der Datenbank abgelegt werden und sowohl von einer Dialog-Anwendung als auch von einem Batchprogramm verwendet werden. Durch die Nutzung von Stored Procedures lässt sich somit die Wiederverwendbarkeit der einzelnen Anwendungskomponenten steigern und die Komplexität der Anwendungen deutlich reduzieren. Da die Stored Procedures vorkompiliert in der Datenbank aufbewahrt werden, ist außerdem eine schnelle Ausführung und ein direkter Datenzugriff möglich. Dies stellt eine gute Performance sicher. Ein großer Nachteil von Stored Procedures ist jedoch die Datenbankabhängigkeit. Die meisten Datenbankhersteller stellen eine eigene Datenbankprogrammiersprache zur Verfügung, mit der Stored Procedures erstellt werden können. Stored Procedures lassen sich nur mit hohem Aufwand von einem Datenbanksystem auf ein anderes Datenbanksystem migrieren. Um das Problem der Datenbankabhängigkeit zu lösen, kann man auf die sogenannten Java Stored Procedures zurückgreifen. Die Java Stored Procedures werden in der Programmiersprache Java erstellt. Sie können auf jedem Rechnersystem mit Hilfe einer Java Virtual Machine (JVM) interpretiert und ausgeführt werden. Außerdem wird der Datenbankzugriff einer Java Stored Procedure mit einem JDBC-Datenbanktreiber sichergestellt, der für alle herkömmlichen Datenbanksysteme verfügbar ist. OracleJVM OracleJVM ist eine in den Kernel von Oracle implementierte Java Virtual Machine. Ab der Oracle Version 10g stehen J2SE 1.4 (Java 2 Standard Edition) und der Datenbanktreiber JDBC 3.0 in der Datenbank zur Verfügung. Somit können Java-Programme, die in einer OracleJVM Version 10g ablaufen, den vollen Umfang der Java-Funktionsbibliotheken von J2SE 1.4 nutzen. Die Java-Funktionsbibliotheken von J2SE befi nden sich auf dem Datenbankrechner in einem $ORACLE_HOME/javavm/admin Verzeichnis. Da der vom Java-Compiler erstellte Java-Bytecode zur Laufzeit vom Interpreter (OracleJVM) interpretiert und ausgeführt wird, entstehen Ineffizienzen bei der Programmausführung. Um diesen Engpass zu beseitigen, sind alle Java-Funktionsbibliotheken mit einem betriebssystemabhängigen Native Compiler übersetzt. Ein Native Compiler übersetzt den Java-Bytecode einer Java-Klasse in einen betriebssystem abhängigen Programmcode und senkt damit deutlich die Ausführungsgeschwindigkeit von Java-Programmen, die innerhalb von OracleJVM ablaufen. Oracle bietet auch die Möglichkeit, selbst entwickelte Java-Klassen mit einem Native Compiler zu übersetzen. 8

8 Datenbanken import java.sql.*; import oracle.sql.*; import oracle.jdbc.driver.*; public class Mitarbeiter extends Object { public static void setgehalt(int ma_nr, int gehalt) { try { DriverManager.registerDriver(new oracle.jdbc.driver.oracledriver()); Connection conn = DriverManager.getConnection( "jdbc:oracle:thin:@localhost:1521:orcl10","mf","mf"); String sqlupdate = "UPDATE ma SET gehalt =? WHERE ma_nr =?"; PreparedStatement pstmt = conn.preparestatement(sqlupdate); pstmt.setint(1, gehalt); pstmt.setint(2, ma_nr); pstmt.executeupdate(); conn.close(); pstmt.close(); } catch(exception e) { e.printstacktrace(); } } public static void main(string[] args) { setgehalt(1, 900); } } Abb. 1: Eine typische Client/Server Java-Datenbankanwendung. Besonderheiten bei der Entwicklung von Java-Anwendungen für die OracleJVM Bei der Entwicklung von Java-Anwendungen für die OracleJVM muss man auf folgende Besonderheiten achten: Jede statische Methode kann als Programmeinstiegspunkt verwendet werden. Es gibt keine Unterstützung für GUI-Komponenten wie AWT und Swing. Multithreading wird nicht unterstützt. Es muss der serverseitige JDBC-Treiber verwendet werden. Programmeinstiegspunkt In einer herkömmlichen JVM-Umgebung stellt die main-methode einer Java-Klasse den Einstiegspunkt eines Programms dar. Beim Starten einer Klasse mit dem Kommando java wird die main-methode dieser Klasse aufgerufen. Der Einstiegspunkt einer in der Datenbank gespeicherten Java-Klasse kann eine beliebige, statische Methode dieser Klasse sein. Keine Unterstützung für GUI-Komponenten wie AWT und Swing Da es sich bei den Java-Anwendungen, die innerhalb einer OracleJVM ablaufen, um serverseitige Anwendungen handelt, ist die Verwendung von grafischen Komponenten (GUI) nicht sinnvoll. Daher wird die Erzeugung von Instanzen der GUI-Objekte wie z. B. AWT und Swing nicht unterstützt. Allerdings kann eine GUI-Funktionalität, wie z. B. die Erstellung und Manipulation von Bildern, verwendet werden, solange die erstellten bzw. veränderten Bilder nicht angezeigt werden. Fehlende Unterstützung für Multithreading-Verfahren Eine weitere Besonderheit bei der Entwicklung von Java-Anwendungen für die OracleJVM ist die fehlende Unterstützung für das Multithreading-Verfahren. In einer OracleJVM werden alle Threads nacheinander anstatt gleichzeitig ausgeführt. Java-Anwendungen müssen allerdings wegen dieser Besonderheit nicht extra angepasst werden. Sie können unverändert in der serverseitigen OracleJVM ausgeführt werden. Serverseitige JDBC-Treiber Beim Zugriff von Java Stored Procedures auf die Datenbankinhalte muss ein serverseitiger JDBC-Treiber verwendet werden. Bei der Verwendung dieses datenbankinternen JDBC-Treibers sind folgende Punkte zu berücksichtigen: Der serverseitige JDBC-Treiber muss im Programm nicht registriert werden, da dieser bereits im Oracle Server integriert ist. Die Datenbankverbindung kann nicht physisch geschlossen werden. Die Verwendung von Auto-Commits wird nicht unterstützt. Eine Verbindung zu einer entfernten Datenbank ist mit dem serverseitigen JDBC-Treiber nicht möglich. Die JDBC-Datenbankverbindung wird mit der Zeichenkette jdbc:default:connection: ermittelt, z. B. DriverManager. getconnection("jdbc:default:connection:"). Java-Klassen ohne Datenbankzugriff Die o. g. Besonderheiten bei der Entwicklung von Java-Anwendungen für die OracleJVM beziehen sich auf Java-Klassen, die einen Datenbankzugriff enthalten. Java-Klassen, die über keinen Datenbankzugriff verfügen, müssen nicht angepasst werden. Sie können ohne Änderungen in der OracleJVM-Umgebung verwendet werden. 9

9 Datenbanken import java.sql.*; import oracle.sql.*; import oracle.jdbc.driver.*; public class Mitarbeiter extends Object { public static void setgehalt(int ma_nr, int gehalt) { try { //DriverManager.registerDriver(new oracle.jdbc.driver.oracledriver()); Connection conn = DriverManager.getConnection( "jdbc:default:connection:"); String sqlupdate = "UPDATE ma SET gehalt =? WHERE ma_nr =?"; PreparedStatement pstmt = conn.preparestatement(sqlupdate); pstmt.setint(1, gehalt); pstmt.setint(2, ma_nr); pstmt.executeupdate(); //conn.close(); pstmt.close(); } catch(exception e) { e.printstacktrace(); } } } Abb. 2: Für die Ausführung in der Datenbank veränderte Klasse Mitarbeiter. loadjava -user mf/mf@orcl10 -resolve -verbose C:\java\Jora.class Abb. 3: Die Klasse Jora wird in das Datenbankschema MF geladen. exec dbms_java.loadjava( '-user mf/mf@orcl10 -resolve -verbose C:\java\Jora.class') Abb. 4: Kommando, mit dem die Jora Klasse in das Datenbankschema MF der ORCL10 Datenbank geladen wird. exec dbms_java.grant_permission( 'MF','java.io.FilePermission','C:\java\*','read') Abb. 5: Der Benutzer MF erhält ein Leserecht auf alle Dateien im Verzeichnis C:\java. Erstellung von Java-Klassen Java-Klassen, die aus einer Java Stored Procedure aufgerufen werden, können mit Hilfe einer beliebigen Java-Entwicklungsumgebung wie z. B. JDeveloper erstellt, kompiliert und getestet werden. Der Quellcode in Abbildung 1 stellt eine typische Client/Server Java-Datenbankanwendung dar, die auf einem Client mit einer Java Virtual Machine lokal aufgerufen wird. Um das in Abbildung 1 dargestellte Programm in eine Oracle Datenbank zu verlagern, müssen die zuvor dargestellten Besonderheiten bei der Entwicklung von Java-Anwendungen für die OracleJVM berücksichtigt werden. Der Quellcode in Abbildung 2 zeigt die bereits für die Ausführung in der Datenbank veränderte Klasse Mitarbeiter. In der Klasse Mitarbeiter sind zum einen die Registrierung des JDBC-Treibers entfernt und die Ermittlung der serverseitigen Datenbankanbindung verändert worden. Zum anderen wurde die close Anweisung zum Schließen der Datenbankanbindung entfernt. Laden der Java-Klassen in die Datenbank Um eine Java-Klasse in einer OracleJVM-Umgebung zu starten, muss diese zunächst in ein Datenbankschema geladen werden. Dabei akzeptiert ein Datenbankschema folgende Dateiarten: Java-Sourcecode-Datei (*.java) Java-Class-Datei (*.class) Java-Ressource-Datei (*.jar bzw. *.zip) Wird eine Java-Sourcecode-Datei in ein Datenbankschema geladen, so wird diese implizit mit dem in der Datenbank verfügbaren Java- Compiler in eine Java-Class-Datei übersetzt. Mit der Anweisung in Abbildung 3 wird eine Java-Klasse Jora in ein Datenbankschema MF geladen. 10

10 Datenbanken Glossar RMI RPC Multithreading RMI bedeutet Remote Method Invocation. Mit RMI besteht die Möglichkeit, innerhalb einer JVM, Methoden von Objekten aufzurufen, die sich in einer anderen JVM befinden. Remote Procedure Call (RPC) ist ein Protokoll für die Implementierung verteilter Anwendungen. Multithreading bedeutet, dass Programme parallel verarbeitet werden können. Literaturhinweise Abb. 6: Laden von Java-Klassen in eine Oracle Datenbank. Oracle und Java, Datenbankentwicklung für E-Commerce-Anwendungen, Elion Bonazzi, Glenn Stokol, Markt+Technik Verlag, 2002 Unleash the Power of Java Stored Procedures, Oracle Corporation, Simplify with Java Stored Procedures, Oracle Corporation, Oracle10g, Java Developer's Guide Release 1 (10.1), Oracle Corporation, 2004 dropjava -user mf/mf@orcl10 -verbose Jora oder exec dbms_java.dropjava('-user mf/mf@orcl10 -verbose Jora') Abb. 7: Zwei alternative Kommandos, die die Jora Klasse aus der ORCL10 Datenbank entfernen. Das Setzen der Option resolve des Kommandos loadjava legt fest, dass nach dem Laden und Kompilieren von Java-Klassen die Verfügbarkeit der abhängigen Java- Klassen überprüft werden soll. Die Option verbose aktiviert die Ausgabe der Meldungen auf dem Bildschirm, während die Klassen in die Datenbank hochgeladen werden. Alternativ zum loadjava Kommando lässt sich das DBMS_JAVA Paket verwenden. Dieses Paket verfügt über Prozeduren, mit denen unter anderem Java-Klassen in die Datenbank geladen und aus der Datenbank entfernt werden können. Mit dem in Abbildung 4 gezeigten Kommando wird eine Jora Klasse in das Datenbankschema MF der ORCL10 Datenbank geladen. Voraussetzung für den Ladevorgang mit dem DBMS_JAVA Paket ist allerdings das Leserecht des Datenbankbenutzers auf die zu ladende Datei. In der OracleJVM-Umgebung wird der Zugriff auf Ressourcen mit einer sogenannten Java-Policy Tabelle sichergestellt. Diese Tabelle gehört dem Benutzer SYS und kann über die Views DBA_JAVA_POLICY und USER_JAVA_POLICY abgefragt werden. Mit dem Kommando in Abbildung 5 wird dem Benutzer MF ein Leserecht auf alle in dem Verzeichnis C:\java vorhandenen Dateien erteilt. Bei der Angabe des Verzeichnisses kann mit der Syntax C:\java\- festgelegt werden, dass das Leserecht auch noch für die im Verzeichnis vorhandenen Unterverzeichnisse gelten soll. Abbildung 6 veranschaulicht das Laden von Java-Klassen in eine Oracle Datenbank. Java-Klassen aus der Datenbank entfernen Wird eine Java-Klasse in der Datenbank nicht mehr benötigt, so kann diese mit dem dropjava Kommando aus der Datenbank entfernt werden. Die beiden in Abbildung 7 aufgeführten Kommandos entfernen die Jora Klasse aus der ORCL10 Datenbank. Ausblick In der nächsten Ausgabe erläutern wir unter anderem das Resolving-Konzept und die Veröffentlichung von Java-Klassen in der Datenbank. Außerdem stellen wir einige Anwendungsmöglichkeiten von Java Stored Procedures vor. Markus Fiegler (info@ordix.de). 11

11 Java/XML Titelthema Application Server Application Server im Vergleich (Teil IV): BEA WebLogic Server Der in diesem Artikel vorgestellte Application Server ist einer der meistverwendeten Application Server im kommerziellen Bereich. Nachdem BEA unangefochten die Führung bei den Produktumsätzen von Application Servern innehatte, muss BEA inzwischen die Spitzenposition mit dem Application Server von IBM teilen. Der Artikel wendet sich gleichermaßen an Entwickler und Entscheider von J2EE Projekten. Plattformen Der Application Server von BEA, als BEA WebLogic Server bezeichnet, basiert ausschließlich auf Java. Diesbezüglich kann er auf allen Betriebssystemen eingesetzt werden, auf denen auch Java zur Verfügung steht. Eine Unterstützung gewährleistet BEA allerdings nur für ca. 35 Betriebssysteme. Bei dieser Auswahl sind die gängigen Server-Betriebssysteme wie Solaris, HP-UX, AIX, Microsoft Windows (2000/XP) sowie Linux von Novell SuSE oder RedHat vertreten. Für die auf Intel-Prozessoren basierenden Betriebssysteme bringt BEA eine eigene Virtuelle Maschine für Java (JRockit) mit! Diese unterstützt sowohl den 32-Bit- wie auch den 64-Bit-Prozessor von Intel. Spezifikation/ Standard WebSphere 5 JBoss 4.0 Borland ES (Stand 05/04) (Stand 11/04) CORBA X v2.3.1 v2.6 X EJB v2.0 v2.1 v2.1 v2.0 IIOP X durch CORBA X X J2EE v1.3 v1.4 v1.3 v1.3 JAAS v1.0 v1.0 X X JAF 1.2 v1.0 X X JAXP 1.1 v1.2 X X JAXR X v1.0 v1.0 - JAX-RPC 1.0 v1.1 v1.0 v1.0 JCA v1.0 v1.5 X v1.3 JCE X durch J2SE 1.4 X X JDBC v2.0 durch J2SE 1.4 v2.0 v3.0 BEA Weblogic JMS v1.0 v1.1 v v.1.0.2b JMX X v1.2 X v.1.0 JNDI X v1.2.1 X X JSP v1.2 v2.0 v1.2 v.1.2 JSSE X X X X JTA v1.0 v1.0.1b X v.1.0.1a LDAP X durch jndi X X RMI X X X X Java Servlets v.2.3 v2.4 v2.3 v.2.3 Java Mail 1.2 v1.3 X v SAAJ 1.1 v1.2 v1.1 X SOAP 1.1 v1.1 v1.1 v.1.2 UDDI 2.0 v2 X v.2.0 WSDL 1.0 v1.1 X v.1.1 X.509 X durch JAAS X X XML X X X X Oracle AS Abb. 1: Überblick über unterstützte Spezifikationen und Standards bei IBM WebSphere, JBoss, Borland Enterprise Server und BEA Weblogic. Der Oracle Application Server wird im nächsten und damit letzten Teil dieser Reihe analysiert. J2EE Die Kompatibilität des WebLogic Servers mit dem von Sun spezifizierten Standard ist der Abbildung 1 zu entnehmen. Mit dem WebLogic Server können J2EE-Anwendungen nach dem derzeitigen Stand der Technik realisiert werden. Standardwerkzeuge, wie z. B. Struts als Framework zur Entwicklung von Web-basierten Benutzeroberflächen oder ant, werden mitgeliefert und unterstützt. Umfassende Beispiel- Anwendungen für die unterschiedlichen J2EE- Themen wie Web-Services, den Einsatz von Enterprise Java Beans oder Servlets vermitteln die Grundlagen zu den Techniken; die Dokumentation gibt ausführliche Informationen. Darüber hinaus bietet BEA zur Vereinfachung der Entwicklung das Produkt WebLogic Workshop an, das die Entwicklung von J2EE durch Kapselung vereinfachen soll (siehe Abbildung 2). Darauf aufbauend wird WebLogic Portal für die Erstellung von Internet-Portalen angeboten. Von der Performance und der Stabilität des Web- Logic Servers konnte sich die ORDIX AG in diversen Entwicklungsprojekten überzeugen, in denen Enterprise Java Beans und der Java Message Server zum Einsatz kamen. System Management Standardmäßig wird die betriebliche Administration über eine grafische Benutzeroberfläche ermöglicht. Diese stellt eine reine Web- Anwendung dar, der Administrator muss da- Integrated Development Environment WebLogic Workshop User Integration WebLogic Portal Application, Process, B2B Integration WebLogic Integration Application Framework WebLogic Workshop Application Server WebLogic Server JVM JRockit Abb. 2: Software-Komponenten zum WebLogic Server. 12

12 Java/XML - <project name="ordixdomain" default="ordix.config"> <taskdef name="wlconfig" classname="weblogic.ant.taskdefs.management.wlconfig" /> <property name="user" value="user" /> <property name="password" value="password" /> <property name="adminurl" value="t3://localhost:7000" /> <property name="server.name" value="ordixserver" /> <property name="server.domain" value="ordixdomain" /> - <target name="ordix.config"> <mkdir dir="${server.domain}" /> <wlserver username="${user}" password="${password}" servername="${server.name}" domainname="${server. domain}" dir="${server.domain}" port="7000" generateconfig="true" beahome="d:\bea" /> </target> </project> Abb. 3: ant-skript zur Erstellung einer Domain. her keine eigenen Software-Komponenten installieren. Eine Fernadministration ist problemlos möglich. Erwähnenswert ist aber auch, dass die wesentlichen Administrationsaufgaben mit Hilfe von Erweiterungen von ant ausgeführt werden können, dazu gehören beispielsweise: Die Einrichtung einer Application Server Domain Die Konfiguration von Datenbank Connections Das Starten und Stoppen Der Prozess des Deployments Das ist einerseits während des Entwicklungsprozesses äußerst hilfreich, wo der Prozess des Deployments häufig vorkommt und durch ant automatisiert werden kann. Auch die Betriebsintegration wird dadurch erheblich erleichtert. In Abbildung 3 ist ein ant-skript zur Erstellung einer neuen Application Server Domain dargestellt. Verfügbarkeit und Skalierung Die durch die J2EE Spezifikation angegebenen Möglichkeiten der Ausfallsicherheit und der Lastverteilung sind im WebLogic Server realisiert. Es gibt einige Beispiele großer Unternehmen, die ihre Web-Portale sowie die damit verbundenen Kundendienstleistungen auf Grundlage des WebLogic Servers betreiben. Lizenzen Zum Zwecke der Entwicklung kann die Software für den WebLogic Server kostenfrei aus dem Internet geladen werden. Diese Lizenz ist ohne zeitliche Beschränkung nutzbar. Preise für die Verwendung des WebLogic Servers sind stark von der Konfiguration abhängig. Standard-Preislisten werden nicht veröffentlicht. Glossar Struts Struts ist ein Open Source Framework für die Präsentationsschicht von Java-Web-Anwendungen. ant ant ist ein in Java geschriebenes Werkzeug zum automatisierten Erzeugen von Programmen aus Quell-Code. Application Server Ein Application Server ist eine Middleware- Komponente. Hier wird die Geschäftslogik implementiert. Enterprise Java Bean Java-Komponente eines Application Servers. Die Methoden eines Enterprise Java Beans werden von der Client-Anwendung aufgerufen. Servlet Java-Komponente eines Application Servers. Ein Servlet wird durch ein HTTP-Request aufgerufen; es generiert die HTTP-Response. Java Message Server Nimmt eingehende Java Messages entgegen und vermittelt diese an Message Driven Beans. Die Bearbeitung der Java Messages erfolgt asynchron. Deployment Installation einer Application Server-Anwendung auf einem Application Server. Links Fazit Der WebLogic Server ist ein erprobter Application Server, der den derzeitigen Ansprüchen der J2EE Entwicklung genügt. Der Einstieg in die Entwicklung mit dem WebLogic Server ist durch den kostenfreien Download und die umfangreichen Dokumentationen erleichtert. Die Möglichkeiten der Automatisierung im administrativen Bereich ist für die Entwicklung und die Betriebsintegration von Vorteil. Aufgrund seiner weiten Verbreitung finden sich zusätzlich zur offiziellen Dokumentation zu vielen Fragen Lösungshinweise im Internet. Stefan Koch (info@ordix.de). 13

13 Datenbanken Business Process Execution Language (BPEL), Teil I: Web Services im Takt Die technische Umsetzung von geschäftlichen Aktivitäten eines Unternehmens in Web Services hat in den letzten Jahren große Fortschritte gemacht. Jetzt steht die umfassende Vernetzung der verschiedenen Web Services zu Geschäftsprozessen an, die überschaubar sein sollen, leicht zu erstellen und zu verwalten sind und dabei möglichst einem allgemeingültigen Standard folgen. Dieser Aufgabe hat sich das Business Process Management (BPM) verschrieben, dem mit der Business Process Execution Language (BPEL) ein Standard für die Prozessintegration zur Verfügung steht. Oracle bietet mit dem BPEL Process Manager eine Lösung für diesen Bereich an. Dieser Artikel richtet sich an Verantwortliche und Architekten für die Umsetzung des Business Prozess Managements auf technischer Ebene. Gewachsene Vielfalt Die schnelle Umsetzung aller Arten von geschäftlichen Aktivitäten der Unternehmen in Web Services und deren starke Verbreitung und große Vielfalt führten zu einer Vielzahl verschiedenster Möglichkeiten, solche Dienste bereitzustellen und zu verwalten. Im Laufe dieser Entwicklung wurden dazu verschiedene Plattformen geschaffen. Vielen Plattformen ist der Zeitdruck der Entwicklungen anzumerken. Änderungen und Erweiterungen waren zum Teil langfristig geplant, oft aber schnelle Reaktion auf aktuelle Anforderungen. Folglich haben wir heute eine unüberschaubare Anzahl an Sprachen und Spezifikationen zur Implementierung von Web Services. Ein erster Schritt zur Standardisierung: SOAP Die Sprache XML (extensible Markup Language) wurde zwar bereits vor einigen Jahren eingeführt und standardisiert, es dauerte allerdings relativ lange, bis sie als universelles Format für den Datenaustausch zwischen Web Services akzeptiert wurde. Immer noch operieren viele angebotene Dienste mit eigenen, spezifischen Datenformaten und Protokollen. Sollen verschiedene Web Services zusammenarbeiten, um gemeinsam nicht nur eine einzelne Aktivität, sondern einen kompletten Geschäftsprozess technisch abzubilden und zu realisieren, muss die Kommunikation durch interpretierende Instanzen und zu erstellende Schnittstellen unterstützt werden, die die XML-Daten in die proprietären Formate und zurück umwandeln. Das hat selbstverständlich Auswirkungen auf die Transparenz, Entwicklungszeiten und Fehlersuche. Zusammenstellung von Prozessen Discovery Beschreibung von Web Services XML messaging Transport-Protokolle BPEL UDDI WSDL SOAP, XML HTTP, SMTP, FTP Abb. 1: Standards für die Implementierung von Geschäftsprozessen. Das SOAP-Protokoll (Simple Object Access Protocol) bildet die Basis für die Kommunikation mit unterschiedlichen Diensten, welche ihre Funktionalität und Schnittstellen in XML dokumentieren und elektronisch anbieten. Zusammen mit Web Service Definition Language (WSDL) und Universal Description, Discovery and Integration Protocol (UDDI) hat sich SOAP heute als ein wichtiger Quasi-Standard zum Datenaustausch und zur Beschreibung webbasierter Dienste etabliert. BPEL: Plattform für die Zusammenarbeit von Web Services Wichtig wäre eine verbindliche Beschreibung einer Plattform, die mit diesen Standards zusammenarbeitet. Bislang existieren hier unterschiedliche Ansätze, von denen sich keiner eindeutig durchsetzen konnte. Eine breite Basis hat die Sprache Business Process Execution Language (BPEL): BPEL wurde von IBM, Microsoft, Sun, Oracle, BEA Systems, SAP und Siebel gemeinsam entwickelt und wird auch häufig BPEL4WS genannt (4WS steht für for Web Services ), oder auch WS- BPEL genannt. Inzwischen wurde die Spezifikation zur Weiterentwicklung dem Standardisierungsgremium OASIS übergeben. BPEL: Sprache für Service Orientierte Architekturen BPEL ist als Plattform für die Bereiche gedacht, in denen mit einer Service Orientierten Architektur (SOA) gearbeitet wird. Merkmale einer SOA sind: In einer SOA stehen Geschäftsprozesse im Vordergrund und nicht Applikationen. Diese Geschäftsprozesse werden in einer SOA durch die Zusammenstellung von Services implementiert. Die Zusammenstellung von Geschäftsprozessen und deren Verwaltung wird Business Process Management genannt (BPM). Das Vorhandensein einer SOA ist also zwingende Voraussetzung für BPM. BPM hat das Ziel, die derzeit in Software eingebetteten und quasi unsichtbaren Geschäftsprozesse aus der Ebene der Applikationen herauszuholen. Sie sol- 14

14 Datenbanken len an einer zentralen Stelle sichtbar gemacht werden, dort modelliert, zusammengestellt oder gegebenenfalls geändert werden. Bei BPM stehen Geschäftsprozesse im Vordergrund. Auch wenn die Abbildung der Geschäftsprozesse auf der technischen Ebene in XML-Dokumenten stattfindet, sollen die BPM- Verantwortlichen ohne XML-Kenntnisse Geschäftsprozesse analysieren und modellieren können. Deshalb wurde für die grafische Darstellung von den zuvor genannten Firmen ein Standard entwickelt: die Management Initiative Business Process Modeling Notation (BPMN). Dieser Standard setzt auf BPEL auf, die modellierten Prozesse werden mit BPEL auf der Ebene der Kommunikation zwischen den Web Services realisiert. In BPEL definierte, verschieden granulare Services können, einmal erstellt, immer wieder zu neuen Geschäftsprozessen zusammengestellt werden. Wie in einem Baukasten stehen die Services zur Verfügung und können schnell für andere Zwecke zusammengestellt werden, ohne dass die Ebene des Austauschs von Daten und Messages, der Aufruf von Funktionen etc. in den Blick genommen werden muss. Das trägt wesentlich zur Flexibilisierung der Geschäftsprozesse bei. BPEL: Orchestrierung von Web Services Mit BPEL lässt sich ein Prozess beschreiben, der in der Lage ist, verschiedene Dienste zu einer Gesamtanwendung zu verknüpfen BPEL orchestriert die Zusammenarbeit von Web Services. Im Bereich des BPM werden zwei verschiedene Kopplungsmechanismen zwischen Services unterschieden, die Choreographie und die Orchestrierung. Von einer Choreographie spricht man, wenn die Koordination einzelner unabhängiger Services durch einen Nachrichtenaustausch realisiert wird. Bei einer Orchestrierung gibt es eine kontrollierende Instanz, die die einzelnen Services steuert, anspricht und wie ein Dirigent den Einsatz gibt. Orchestrierung bedeutet das Zusammenspiel verschiedener Dienste, Applikationen oder Web Services, die mit Hilfe einer BPEL-basierten Prozessbeschreibung einen bestimmten Geschäftsprozess abbilden und technisch ermöglichen. Die Interaktion der verschiedenen Komponenten, die Abfrage von Daten, das Aufrufen von Funktionen und die Reaktion auf verschiedene Rückgabewerte, geschieht über die BPEL- Laufzeitumgebung. Struktur von BPEL Bei BPEL handelt es sich um eine erst kürzlich entwickelte und (noch) nicht intensiv genutzte Sprache: Daher existieren unterschiedliche Spezifikationen zur Syntax der Sprache, abhängig davon, ob die Oracle BPEL-Engine oder die IBM-Engine verwendet wird. Wenn plattformübergreifend gearbeitet werden soll, müssen einige Befehle abgewandelt werden. Die BPEL-Syntax ist stark an XML orientiert. Wer in diesem Bereich mit den dort verwendeten Sprachen XML und WSDL arbeitet, bewegt sich auch bei BPEL im muttersprachlichen Bereich. Für jeden definierten BPEL-Prozess wird ein WSDL-Dokument erstellt, in dem der genutzte Web Service definiert wird. Will ein anderer Benutzer diesen Web Service nutzen, steht ihm bereits dessen Bedienungsanleitung zur Verfügung. Diese Definition enthält die Partner, mit denen der Prozess kommuniziert (partnerlink), deren Kommunikationskanäle und die diesem Partner möglichen Operationen. Jedes BPEL-Dokument besteht aus einem Definitionsteil und einem Teil, der den Ablauf des Prozesses beschreibt. Konkret geschieht die Definition eines Geschäftsprozesses in drei Sektionen des BPEL Dokuments: Partnerlinks: Hier werden die Services aufgelistet, die am Geschäftsprozess beteiligt sind. Variables: Listet die Nachrichten-Typen auf, die zwischen den Services und deren Aktivitäten ausgetauscht werden. Der Typ ist immer ein XML-Schema-basiertes Element oder ein WS- DL-Nachrichtentyp. Orchestration Logic: Dieser Ablaufteil beschreibt die Abfolge der Aktivitäten, die die Services leisten sollen, um einen Geschäftsprozess abzubilden. In diesem Teil liegt also die Prozesslogik. Die verschiedenen Aktivitäten können aufeinander folgen oder parallel ablaufen. Für die Ablaufsequenzen können auch Fehlerbehandlungen und Entscheidungsbäume basierend auf Rückgabewerten aufgebaut werden. Die Grundstruktur eines Prozesses zeigt Abbildung 2. <process name= HelloWorld > <! - Prozess --> <partnerlinks> <! - Dienste --> </partnerlinks> <variables> <! - Daten --> </variables> <sequence name = main > <! - Ablaufsequenz --> <receive> <assign> <! - Aktivitäten --> <reply> </sequence> </process> Abb. 2: Grundstruktur eines Prozesses in BPEL. Schnittstellenbeschreibung unter BPEL Für die im BPEL-Dokument aufgeführten Services gibt es eine WSDL- Schnittstellenbeschreibung. Dieses WSDL-Dokument enthält die folgenden (optionalen) Sektionen: 15

15 Datenbanken Type Definition: Die Definition der benötigten Datenstrukturen (XML-Elemente). Message Type Definition: Definition der Nachrichtentypen, die zwischen den Services ausgetauscht werden. Port Type Definition: Hier werden zusammengehörende Arbeitsschritte gruppiert und als ein spezifischer Port Type definiert. Binding: Definition von konkreten Protokollen und Datenformaten für die Operationen und Messages eines Port Types. Service: Gruppierung von Port Types. <process> Umschließt den ganzen Prozess. <assign> Kopiert Daten von einer Variablen zu einer anderen. So wird das Ergebnis eines Services an den nächsten übergeben. <invoke> Prozesse eines Services können aufgerufen werden. <receive> Spezifiziert den Service, von dem eine Variable empfangen werden soll. Mit <receive> kann auch eine Prozessinstanz aktiviert werden. <reply> Versendet eine Antwort als Folge auf eine <receive>- Aktion. Ein <reply> bezieht sich immer auf einen bestimmten Partnerlink und eine bestimmte Variable. <throw> Beschreibt mögliche Fehlerfälle. <terminate> Beendet explizit den Prozess. <sequence> Definiert für verschiedene Aktivitäten die Reihenfolge, in der sie abgearbeitet werden sollen. <pick> Versetzt den Prozess sozusagen in eine Endlosschleife und wartet auf ein Ereignis, etwa die Antwort eines Partnerlinks, um dann mit dem Prozessfluss fortzufahren. <flow> Erlaubt das parallele Abarbeiten von Aktivitäten. <switch> und Ermöglichen fallbasierte Verzweigungen, z. B. aufgrund bestimmter Attribute der Rückgabewerte ei- <case> ner vorangehenden Aktivität. <correlation> Bietet die Möglichkeit, auf bestimmte Inhalte einer Rückgabe mit korrelierenden Nachrichten zu reagieren. Abb. 3: Diese Operationen können mit BPEL ausgeführt werden. Beispielprozess unter BPEL Abbildung 5 zeigt, wie ein Beispiel-Prozess in BPEL abgebildet wird: Für den Aufruf dieser Aktionen wird jeweils der entsprechende Partner, der Kommunikationskanal, die auszuführende Operation und welche Variable für diese Kommunikation verwendet werden soll, angegeben. Die so definierten Nachrichten werden im WSDL-Dokument als message definiert, entsprechen also SOAP-Nachrichten. BPEL: SQL für Prozesse Mit BPEL steht jetzt eine standardisierte, ablauffähige Sprache zur Beschreibung von Prozessen zur Verfügung, die von einer Reihe namhafter Unternehmen unterstützt wird. Für den Bereich des BPM gilt BPEL als SQL im Kontext von Web Services und eröffnet, wie die Einführung von SQL vor 25 Jahren, Möglichkeiten, die einen Produktivitäts- und Innovationsschub erwarten lassen. Die Prozesslogik wird auf einer eigenen Ebene bearbeitet, die unabhängig ist von den technischen Gegebenheiten der zu integrierenden Dienste. Die Möglichkeiten der Services sind transparent und können, wenn sie einmal definiert sind, schnell und flexibel genutzt werden. Definierte Dienste können neu zusammengestellt werden und so andere Prozesse abbilden. Das erlaubt eine effiziente Implementierung eines Geschäftsprozesses nach SOA-Prinzipien und gege- Abb. 4: BPEL Console. benenfalls die flexible Anpassung des Prozessverlaufs an neue Gegebenheiten. Damit können sich Unternehmen schneller als bisher Marktveränderungen anpassen. Jeder einmal mit BPEL definierte Prozess kann in anderen Kontexten weiterverwendet werden. Die benötigten Ressourcen für Projekte der Prozess-Integration können durch BPEL stark reduziert werden. BPEL produktiv nutzen: Oracle BPEL Process Manager Um BPEL produktiv nutzen zu können, sind eine stabile und performante Laufzeitumgebung, Designwerkzeuge sowie eine Konsole für die Verwaltung und das Monitoring der erstellten Prozesse nötig. Die an der Erstellung des BPEL-Standards beteiligten Firmen bieten Lösungen zur Implementierung von BPEL an oder arbeiten an solchen. Oracle konnte sich durch die Übernahme von Collaxa eine bereits weit entwickelte BPEL-Engine sichern, die jetzt als Oracle BPEL Process Manager weiterentwickelt wurde und zur Verfügung steht (siehe Abbildung 4). Der Oracle BPEL Process Manager unterstützt die Implementierung und das Arbeiten unter BPEL sowohl in der Entwicklung als auch in der Ausführung. Der Oracle BPEL Process Manager enthält die folgenden Elemente: Den BPEL Designer: Mit der graphischen Umgebung können die BPEL-Prozesse modelliert werden. Die BPEL Console, unter der die Prozess-Instanzen verwaltet und überwacht werden. 16

16 Datenbanken <! HelloWorld BPEL Process [Generated mit ORACLE BPEL Designer] --> <process name= "HelloWorld"> targetnamespace=" suppressjoinfailure="yes" xmlns:tns=" xmlns=" xmlns:bpelx=" xmlns:ora=" <! ===================================================== --> <! PARTNER LINKS --> <! List of services participating in this BPEL process --> <! ===================================================== --> <partnerlinks> <! Die 'client'-rolle repräsentiert den, der diesen Service anfragt --> <partnerlink names>= "client" partnerlinktype="tns:helloworld" myrole="helloworldprovider"/> </partnerlinks> <! ===================================================================== --> <! VARIABLES --> <! Liste der Services und XML-Messages innerhalb dieses BPEL-Prozesses --> <! ===================================================================== --> <variables> <! Referenz auf die Message, die als Input diesen Prozess initiiert --> <variable name=»input» MessageType="tns:HelloWorldRequestMessage"> <! Referenz auf die Message, die dem Anfragenden gentwortet wird --> <variable name=»output» MessageType="tns:HelloWorldResponseMessage"> </variables> <! ===================================================================== --> <! ORCHESTRATION LOGIC --> <! Aktivitäten zum Koordinieren des Flusses der Messages zwischen den Services --> <! - innerhalb dieses BPEL-Prozesses --> <! ===================================================================== --> <sequence name = "main"> <! Input vom client empfangen. Eintrag verweist auf in HelloWorld.wdsl definierte Operationen --> <receive name="receiveinput" partnerlink= "client" porttype="tns:helloworld" operation="process" variable="input" createinstance="yes"/> <! Antwort generieren --> <assign name="verknüpfung"> Abb. 5: Beispielprozess in BPEL abgebildet. Die BPEL Engine, die Laufzeitumgebung als J2EE-Container realisiert. Eine ORACLE Datenbank, in der langlaufende Prozesse persistent gehalten werden. Über die Anforderungen hinaus, die der BPEL- Standard stellt, kann über Erweiterungen Java-Code direkt in Dokumente eingebettet werden, nicht SOAP-basierte Web Services können über das Web Services Invocation Framework in eine Prozess-Definition eingebunden werden. Damit können Dienste auch über andere Schnittstellen, Protokolle und Sprachen als im Standard BPEL vorgesehen genutzt werden, etwa Java, JCA oder . Ausblick Nach dieser Einordnung von BPEL und der Beschreibung seiner Möglichkeiten folgt im zweiten Teil eine ausführliche Darstellung, wie sich die Prozess-Modellierung mit dem Oracle BPEL Process Manager realisieren lässt. Uwe Rübesamen (info@ordix.de). Glossar BPM Mit Business Process Management (BPM) lassen sich Geschäftsprozesse in einem dynamischen IT-Umfeld formen und weiter entwickeln. So können Applikationen zu adaptiven Prozessen verknüpft werden, die die komplette Wertschöpfungskette umfassen. SOA Service-orientierte Architektur (engl. Service Oriented Architecture) in der Softwarearchitektur. SOAP Simple Object Access Protocol. SOAP ist der heutige Standard für Web Services Messages. SOAP definiert für Messages, die mittels XML übermittelt werden, einheitliche Formate der Adressierung und Inhaltsbeschreibung. WSDL Web Service Definition Language. WSDL gibt das Format für eine einheitliche Beschreibung eines Web Services vor, anhand derer ein solcher Service angefragt und dessen Funktionen abgerufen werden können. UDDI Universal Description, Discovery and Integration protocol. UDDI spezifiziert ein universelles Format zur Verwaltung von Informationsverzeichnissen, Adressen etc. eines Web Services. OASIS Organization for the Advancement of Structured Information Standards. OASIS ist eine nicht-kommerzielle Organisation, die sich um die Standardisierung von Formaten für Web Services auf der Basis von XML kümmert. 17

17 Aktuell Open Source für den Mittelstand 10 Jahre erfolgreiche Partnerschaft: KARRENA und ORDIX Als das Ratinger Industrie-Unternehmen KARRENA Teile seiner Computersysteme auf Unix Systeme umstellte, bestand für einige Bereiche entsprechender Beratungs- und Unterstützungsbedarf. Aus einer lockeren Unterstützung, die der damalige ORDIX Geschäftsführer und heutige Vorstand Kögler geleistet hatte, entwickelten sich verschiedene Aufträge für das Paderborner Software-Unternehmen. Daneben wurden auch Schulungen bei ORDIX gebucht. Jüngst unterstützte ORDIX die KARRENA Gruppe bei der Umstellung der Linux Server auf Linux Cluster Server. Der Artikel wendet sich an Entscheider und Systemadministratoren, die sich mit Unix, Linux, Samba, Mail, CUPS, Backup und Recovery beschäftigen. Von Unix zu Linux Neben dem ursprünglich eingesetzten HP Server deckte KARRE- NA den Ende der neunziger Jahre entstandenen Bedarf durch Linux Rechner ab. Als Vorreiter für Open Source stand ORDIX den IT-Mitarbeitern von KARRENA dabei zur Seite. Im Jahr 2004 kam das EDV Team von KARRENA zu dem Schluss, dass dem Themenschwerpunkt Verfügbarkeit mehr Bedeutung beigemessen werden müsse. Obwohl die Daten schon damals auf drei verschiedene Server verteilt waren (je einer für die zentrale Datenbank, CAD- und Windows Dokumente), hätte der Ausfall einer dieser Maschinen zu nicht tolerablen Verzögerungen in den Arbeitsabläufen geführt. Auf dem ORDIX Fachtreff zum Thema Open Source Software technische und kostensenkende Alternative erfuhr KARRENA, dass es im Bereich Linux Cluster und Verfügbarkeit inzwischen technologisch sehr gute Lösungen zu akzeptablen Preisen gibt. Vom Linux Server zum Linux Cluster Mit dem Wissen aus dem Fachtreff schmiedeten EDV-Leiter Dr. Lütcke und seine Mitarbeiter Thomas Sprenger und Christoph Schulz ein Konzept, wie die hausinterne IT mit zwei leistungsfähigen und mit genügend Festplattenplatz ausgestatteten Linux Servern neu zu gestalten sei. Der Linux Heartbeat Cluster wurde favorisiert, weil zusätzlich zu der gewährleisteten Hochverfügbarkeit im Normalfall zwei Server bereitstehen, auf die die verschiedenen Dienste verteilt werden können, um so exzellente Response-Zeiten zu erhalten. In der Vergangenheit stets gut beraten, wendeten sich die KARRE- NA Mitarbeiter für die Detailplanung auch dieses Mal vertrauensvoll an ORDIX. Ein Termin mit ORDIX reichte für die Prüfung des Konzeptes aus, wobei es nur an wenigen Stellen ergänzt werden musste. Das ORDIX Wissen um zusätzliche, kleine und zugleich wichtige Aspekte, wie z. B. Steckerleisten, Backupgeräte und die Trennung der Server durch feuerfeste Wände, rundete die Vorstellungen der Ratinger ab. Abb. 1: EDV-Leiter Dr. Helmut Lütcke (Mitte) mit seinen beiden Mitarbeitern Thomas Sprenger (links) und Christoph Schulz (rechts). Mit den Informationen aus diesem Beratungstag erstellte das KARRENA EDV-Team eine Vorlage für die Geschäftsleitung, die schnell abgesegnet war. Nur wenige Wochen nach dem ersten Beratungstermin wurden die Cluster zusammen mit ORDIX aufgebaut, Software installiert und die Systeme konfiguriert. Sämtliche Ausfallszenarien wurden erfolgreich durchgespielt. Jetzt wartet das Gesamtsystem darauf, entgültig in Betrieb genommen zu werden. Auch dabei wird ORDIX bei Bedarf wieder unterstützend tätig werden. Welche Vorteile bringt KARRENA die Zusammenarbeit mit ORDIX? Auf die Frage, warum KARRENA die Zusammenarbeit mit ORDIX schätzt, antwortet Herr Sprenger: Ich kenne Herrn Kögler schon seit mehr als 20 Jahren. Was die Beratungs- oder 18

18 Aktuell LAN Virtuelle IP-Adressen Die Hauptaktivitäten der KARRENA Gruppe liegen in der Auskleidung feuerfester Industrieanlagen und im Bau von Industrieschornsteinen. (4) Schreibvorgang Heartbeat über Nullmodemkabel Heartbeat über Kreuzkabel/UDP (1) Schreibe Daten! (3) OK: Daten sind geschrieben! (2) Schreibvorgang Seit der Gründung im Jahr 1914 ist die KARRE- NA inzwischen zu einer weltweit operierenden Unternehmensgruppe mit Vertretungen in mehr als 20 Ländern herangewachsen. Im Jahr 2000 erhielt KARRENA den größten Montageauftrag ihrer Firmengeschichte: Den Neubau von zwei Koksofenbatterien für die neue Kokerei in Duisburg Schwelgern. Nach den Ofenkammerdimensionen ist dies die größte Kokerei der Welt. Zu den Referenzen der KARRENA gehören ferner die Feuerfestauskleidung des größten Hochofens Europas und der größten zirkulierenden Wirbelschichtanlage in Europa, ebenso der mit 360 m höchste Schornstein Westeuropas. Tausende von Referenzanlagen stehen heute in mehr als 100 Ländern der Welt. Internet: info@karrena.de Unterstützungsleistung betrifft, sind wir von ORDIX nie enttäuscht worden. ORDIX hatte für uns jederzeit das notwendige und richtige Know-how zur Verfügung. Und er erklärt weiter: Die Berater sind kompetent und es herrscht Beständigkeit: Selbst der erste Berater, der 1995 bei uns war, steht uns heute noch bei Bedarf zur Verfügung. Wo finden Sie sonst solche Konstanz und Kompetenz? EDV-Leiter Dr. Lütcke ergänzt: Für ein Unternehmen wie KARRENA, das nicht von der IT lebt, sondern diese nur als Mittel zum Zweck nutzt, ist es gerade im Bereich Open Source wichtig, auf jemanden zurückgreifen zu können, dem man vertraut und der einem sofort und unkompliziert helfen kann. Das alles finden wir bei ORDIX. Beim jüngsten Projekt hat ORDIX, wie bereits erwähnt, zwei Linux Server als Cluster aufgebaut, was im Weiteren beschrieben wird. So (einfach) entsteht ein Linux Cluster System Master Primärer Datenbestand Abb. 2: Gemeinsame Datenhaltung mit DRBD. Bei der technischen Umsetzung des Clusters wurde die zum Distributionsumfang des SU- SE Linux Enterprise Server 9 gehörende Software des Linux High Availability Project eingesetzt. Die beiden Knoten überwachen sich gegenseitig mittels einer separaten IP-Verbindung über ein gekreuztes Netzwerkkabel sowie über ein an die seriellen Schnittstellen angeschlossenes Nullmodemkabel. Im Normalfall läuft auf einem der Knoten ( lina ) das RDBMS Universe und auf dem zweiten ( linb ) der Samba Fileserver. Fällt ein Knoten aus, übernimmt das übriggebliebene System die zu dem jeweiligen Dienst gehörende IP-Adresse und startet die notwendigen Skripte zur Übernahme des Dienstes. Konfiguration des Clusters Realtime Datensynchronisation mittels DRBD Die Basiskonfiguration der Clustersoftware erfolgt in der Datei /etc/ha.d/ha.cf: # Heartbeat Meldungen alle 2 Sekunden senden keepalive 2 # Nach 10 Sekunden Partner für tot erklären deadtime 10 # Heartbeat über die serielle Schnittstelle baud serial /dev/ttys0 # UDP Heartbeat über die Netzwerkschnittstelle eth1 udpport 694 bcast eth1 # Die Namen der Knoten node lina node linb Gemeinsame Datenhaltung mit DRBD Sekundärer Datenbestand Backup Zur gemeinsamen Datenhaltung zwischen den Knoten wird die ebenfalls zum Distributionsumfang gehörende Distributed Replicated Block Device (DRBD) Software eingesetzt. Mittels DRBD lassen sich virtuelle Blockdevices generieren, die dafür sorgen, dass Schreibvorgänge auf beiden Knoten simultan erfolgen (siehe Abbildung 2). Der Datentransfer erfolgt über die auch zur gegenseitigen Überwachung genutzte Gigabit Ethernet Verbindung zwischen den Knoten. Für den Cluster wurden zwei dieser DRBD Devices erzeugt, welche die für jeweils einen Dienst benötigten Daten enthalten. Die Konfiguration der Geräte erfolgt innerhalb der Datei /etc/drbd.conf (siehe Abbildung 3). Die Clustersoftware entscheidet im laufenden Betrieb, welcher der beiden Knoten auf ein DRBD Device aktiv zugreifen darf (Primary) und welcher Knoten lediglich Daten empfängt (Secondary). Die 19

19 Aktuell resource drbd0 { on lina { device /dev/drbd0; disk /dev/sda7; address :7788; meta-disk internal; } } on linb { device /dev/drbd0; disk /dev/sda7; address :7788; meta-disk internal; } Abb. 3: Auszug aus der DRBD Konfiguration /etc/drbd.conf. lina drbddisk::drbd0 LVM2::universe \ Filesystem::/dev/universe/ibm::/usr/ibm::reiserfs \ Filesystem::/dev/universe/dd51::/dd51::reiserfs \ Filesystem::/dev/universe/dd52::/dd52::reiserfs \ Filesystem::/dev/universe/dd53::/dd53::reiserfs \ universe MailTo::admin1,admin2::Universe-Dienst Abb. 4: Auszug aus der /etc/ha.d/haresources. # Der APC-Switch ist das STONITH Device stonith_host lina apcmastersnmp geheim stonith_host linb apcmastersnmp geheim Abb. 5: Konfigurationseinstellung in der Datei /etc/ha.d/ha.cf. Änderung des Status erfolgt über das zur Clustersoftware gehörende Skript /etc/ha.d/resource.d/drbddisk. LVM2 auf DRBD Die DRBD Devices selbst wurden wiederum als Physical Volumes für das Logical Volume Management markiert: pvcreate /dev/drbd0 pvcreate /dev/drbd1 Um sie anschließend einer Volume Group zuteilen zu können, musste dafür gesorgt werden, dass die unter dem DRBD Device liegenden physikalischen Partitionen /dev/sda7 und /dev/sda8 nicht vom LVM als Physical Volume erkannt werden, sondern lediglich das darauf befindliche DRBD Device. Mit dem neuen Logical Volume Manager in der Version 2 lassen sich zu diesem Zweck Filterregeln in Form logischer Ausdrücke definieren: /etc/lvm/lvm.conf: filter = [ "r /dev/sda[7-8]$ " ] Im Anschluss daran konnten Volume Groups und Logical Volumes für die beiden Dienste erstellt werden: vgcreate universe /dev/drbd0 vgcreate samba /dev/drbd1 lvcreate L6.5GB n ibm universe... Die Aktivierung einer Volume Group bzw. der darin enthaltenen Logical Volumes erfolgt wiederum bei der Übernahme des Dienstes durch das von ORDIX für den LVM2 angepasste Skript /etc/ha.d/resource.d/lvm2. Konfiguration der Clusterdienste Mit der Datei /etc/ha.d/haresources wird letztendlich definiert, welche Skripte bei der Übernahme eines Dienstes gestartet werden sowie welcher Knoten diesen Dienst standardmäßig aktivieren soll (siehe Abbildung 4). Beim Start des Dienstes Universe DBMS werden demnach folgende Aktionen von der Clustersoftware ausgeführt: Aktivierung der IP Adresse Status Primary setzen für DRBD Device drbd0 Volume Group universe auf drbd0 aktivieren Logical Volumes ibm, dd51, dd52, dd53 in den Dateibaum einhängen Universe DBMS starten Hinweis über die Übernahme per Mail an die Benutzer admin1 und admin2 versenden Ein Stopp des Dienstes sorgt für die Deaktivierung der genannten Komponenten in umgekehrter Reihenfolge. Das Start/Stop Skript /etc/ ha.d/resource.d/universe musste zu diesem Zweck zunächst von der ORDIX AG erstellt werden. Die Universe Software selbst liegt auf dem Logical Volume ibm und wird bei der Aktivierung des Dienstes unter /usr/ibm eingehängt. STONITH Ein zentrales Problem beim Aufbau eines Clusters stellt die Split Brain Situation dar. Diese bezeichnet eine kritische Situation, die beim Ausfall der Kommunikationsleitungen zwischen den Knoten entsteht. In diesem Fall erhalten die Knoten keine Information über den Status des Partners und gehen demzufolge fälschlicherweise davon aus, dass dieser nicht mehr lebt. Wenn nun beide Knoten den Dienst übernehmen wollen, kann es zu Datenkorruption und IP-Konflikten im Netzwerk kommen. Um dies auszuschließen, verwendet die Clustersoftware das STONITH Verfahren ( Shoot the other node in the head ). Beim Ausfall der Heartbeat Leitungen bzw. sobald sich die Knoten nicht mehr erreichen, versuchen beide Knoten über eine schaltbare Stromleiste (APC Masterswitch), den Partner abzuschalten. Dazu ist die in Abbildung 5 gezeigte Konfigurationseinstellung in der Datei /etc/ha.d/ha.cf getätigt worden. Will z. B. der Rechner lina den Rechner linb ausschalten, so verbindet er sich per SNMP mit dem APC Masterswitch mit der IP-Adresse auf dem Port 161 und mit dem 20

20 Aktuell Passwort geheim. Anschließend wird die Steckdose mit der Bezeichnung linb abgeschaltet. Dies bedingt die vorherige Zuweisung dieser Bezeichnung über die Administrationsoberfläche des Masterswitches. Fazit Bei der Installation des Clusters wurde ausschließlich Software aus dem Distributionsumfang des SUSE Linux Enterprise Server 9 verwendet. Auch für die Knoten wurden keine teuren Serversysteme eingesetzt, sondern übliche PC Hardware. Zudem konnte durch den Einsatz von DRBD auf kostenintensive, externe Storagesysteme zur gemeinsamen Datenhaltung verzichtet werden. Dennoch verfügt KARRENA nun über ein hochgradig ausfallsicheres System, welches Schutz gegen jeden denkbaren Einzelfehler der Hardwarekomponenten bietet. Dies wurde im Rahmen der Abnahme in Form eines ausführlichen Testkatalogs verifiziert. Planen auch Sie den Einsatz eines Linux Clusters? Dann fordern Sie uns! Christof Amelunxen (info@ordix.de). Glossar Cluster CUPS DRBD Heartbeat LVM Physical Volume Samba Zusammenfassung von zwei oder mehr Rechnern (Knoten) zu einem logischen System, mit dem Ziel der Verbesserung von Performance oder Verfügbarkeit. Common Unix Printing System das Standard Drucksystem auf Linux Servern. Distributed Replicated Block Device. Ermöglicht die gemeinsame Datenhaltung zwischen zwei Knoten eines Clusters durch Spiegelung eines Blockdevices über ein IP Netzwerk. Schreibvorgänge auf ein mit DRBD verwaltetes Device erfolgen auf beiden Knoten simultan. Die zwischen den Knoten im Cluster ausgetauschten Statusmeldungen. Gleichzeitig Name der Clustersoftware des Linux High Availability Projects. Logical Volume Manager. Ein beliebiges, blockorientiert angesprochenes Gerät, welches einer Volume Group zugeteilt wird. Ein frei verfügbarer Fileserver für Windows Clients. Split Brain Kritischer Fall innerhalb eines Clusters, der beim Ausfall sämtlicher Kommunikationsleitungen zwischen den Knoten auftritt. In diesem Szenario kann keiner der Knoten eindeutige Aussagen über den Status des Partners machen. STONITH Shoot the other node in the head -Verfahren, welches beim Split Brain -Problem Datenkorruption durch Ausschalten des Partnerknoten mittels schaltbarer Stromleisten verhindert. Volume Group Eine Menge von 1-n blockorientiert angesprochener Geräte (Physical Volumes), aus der wiederum 1-n Logical Volumes erzeugt werden können. Titelthema Partnerschaft ORDIX und VMware ORDIX ist zertifizierter VMware VIP Enterprise Partner Seit mehreren Jahren unterstützt ORDIX seine Kunden bereits in VMware-Projekten unter anderem im Zuge der Serverkonsolidierung. Im Frühjahr 2005 wurde die erfolgreiche Zusammenarbeit zwischen VMware und ORDIX auf eine neue Basis gestellt: Ab sofort steht ORDIX Ihnen als zertifizierter VMware VIP Enterprise Partner zur Verfügung. Verschiedene Betriebssysteme auf Intel Servern und Workstations einsetzen Mit der Technologie von VMware können verschiedene Betriebssysteme wie MS Windows, Linux und NetWare gleichzeitig und unabhängig voneinander auf Intel-basierten Servern und Workstations eingesetzt werden. Mit Hilfe der VMware Produkte ist es möglich, auch Live-Applikationen während des Betriebs im System zu verschieben. Globale Verwaltung wird dynamisch Diese virtuellen Systeme fügen sich nahtlos in physikalische Infrastrukturen und Verwaltungsumgebungen ein. Nutzer verfügen somit über dediziert zugewiesene Systemressourcen, während Administratoren die IT-Infrastruktur global verwalten und dynamisch an die wechselnden Bedürfnisse im Unternehmen anpassen. ORDIX Leistungen Zertifizierte VMware Mitarbeiter der ORDIX AG unterstützen Sie von der Planung über die Konzeption bis hin zur Realisierung Ihrer VMware Projekte. Dies kann sowohl im Umfeld der Serverkonsolidierung als auch beim Einsatz von Test- oder Schulungssystemen sein. Vielleicht... haben Sie in der ORDIX News schon den einen oder anderen Artikel über VMware gelesen? Für weitere Informationen stehen wir Ihnen selbstverständlich gerne zur Verfügung. Sprechen Sie uns an: info@ordix.de. 21