Monitoring einer Hochverfügbarkeitslösung

Transkript

1 Donnerstag, 10. November h00, Variohalle 5 Monitoring einer Hochverfügbarkeitslösung Ulrich Gerkmann-Bartels TEAM GmbH Schlüsselworte: OracleAS, Hochverfügbarkeit, Architektur, Cluster, Deployment, Installation,, Monitoring, Tools Einleitung Die Installation einer Hochverfügbarkeitslösung unter der Verwendung eines Application-Server stellt eine (kleine) Herausforderung dar. Eine solche Lösung lässt sich leider nicht mit dem Aufruf des Oracle Universal Installer alleine erledigen. Im Vorfeld sind wichtige Details abzuklären und sinnvolle einzuhalten, um eine erfolgreiche Installation und den weiteren Betrieb gewährleisten zu können. Dieser Vortrag gibt Erfahrungen, Anmerkungen und verwendete Tools aus verschiedenen Projekten wieder. Was ist Hochverfügbarkeit und wie sieht das aus? Abb.1 Ausfallzeiten (Quelle: ORACLE Deutschland GmbH) Im Klartext heißt dies, es bleibt nicht viel Zeit, in der die Maschinen wirklich stehen, bzw. alles steht. Bei dieser Frage sollte man immer betrachten, welche Faktoren es gibt, die zum Ausfall eines solchen Systems führen kann. Zu diesen zählen u. a. Systemfehler, Benutzerfehler, Deployment einer neuen Version und Patchen des Systems. Im Grunde kann ein Administrator nur dann sicher schlafen und seine Arbeit in Ruhe erledigen, ohne in Panik zu verfallen, wenn das System von Grund auf redundant ausgelegt ist. Dies ermöglicht den Ausfall eines Teils des Systems oder das Herausnehmen von einzelnen Komponenten / Hosts zu Wartungszwecken. Durch diese Entscheidung kann man im eigentlichen Sinne gleich hinter jedem Host eine mal zwei schreiben, und man erblickt den Aufwand, den es in Betrieb zu setzen gilt. Zu der eigentlichen Host für den Application-Server erscheinen in einer solchen Architektur meist auch weitere Hardware-Komponenten wie Filer, Firewall, Load Balancer oder SSL Accelerator. Innerhalb der Architektur müssen viele verschiedene Komponenten als Cluster ausgelegt werden, wie z.b. OracleAS Identity Management, OracleAS Reports Cluster, HTTP Cluster, Web Cache Cluster, OC4J Cluster,... Die Wahl der Komponenten bestimmt die Komplexität der OracleAS Farm. Abb. 2: HA Beispielarchitektur Es ist erfolgreicher, nur die Komponenten als Cluster zu konfigurieren, die auch wirklich benötigt werden.

2 18. Deutsche ORACLE-Anwenderkonferenz Keep it simple! Nur die Komponenten in die Architektur aufnehmen, die erforderlich sind Verwende File-based MR, wenn immer es geht Ist der Load Balancer von Oracle zertifiziert / geprüft? Auswahl des Betriebsystems In den verschiedenen Projekten wurden Erfahrungen auf verschiedenen Plattformen, wie zum Beispiel HP Cluster mit Tru64, SUSE SLES 8/9, AIX 5.2/5.3 oder Windows Server 2000, gemacht. Die hier aufgeführte Übersicht zeigt unsere Erfahrungen zum damaligen Zeitpunkt unter der Berücksichtigung des entsprechenden Software-Releases. Alle aufgeführten Systeme sind produktiv, bis auf eines: Windows Server System Version Einsatz Architektur Anmerkungen HP Tru64 Cluster J2EE Hardware Cluster Patchset erst zu OracleAS Portal Cold Failover einem späteren Zeitpunkt Cluster verfügbar nicht verfügbar Anpassung von Scripten Performance-Probleme mit dcmctl updateconfig AIX 5.2 ML J2EE Cluster OracleAS Cluster Einfache Architektur EJB State File based MR Replication AIX 5.3 ML OracleAS Portal IBM Virtual Server IBM Bug in AIX 5.3 ML1 OracleAS Forms Version war von Oracle zer- OracleAS Reports tifiziert für diese Plattform IBM HS 20 AS OracleAS Portal Active Failover Komplexe Architektur Blade Server DB OracleAS Reports Cluster Probleme mit OracleDB Rack Mounted IM CCD SUSE 9 RAC als MR-Store Ausfallzeiten beim Patchen des RAC Windows OCS 10g R1 OCS Cold Failover Nach Aufbau einer Server 2000 Cluster ersten Teststellung auf einer Maschine wurde die Plattform geändert Forms / J2 EE Aus den gesammelten Erfahrungen würde ich auf die Frage: Welches Betriebsystem bevorzugen Sie für die Installation einer Lösung im Umfeld des OracleAS? antworten: LINUX. In den Projekten, gerade im Umfeld mit der neuen Betriebssystemversion im Umfeld von AIX, haben wir die leidige Erfahrung gemacht, dass im Zweifel eine sehr lange Zeit vergehen kann, bis: 1. das Problem genau analysiert worden ist. 2. der wirkliche Verursacher gefunden ist. 3. der Verursacher ein entsprechendes Patch zu Verfügung stellt, das für den Produktiveneinsatz geeignet ist. 4. der Hersteller des Application-Server die entsprechende korrigierte Version wieder zertifiziert. Dies steht im Gegensatz zu Problemen bei der erstmaligen Verwendung von SUSE SLES 9 und OracleAS , die relativ zeitnah gelöst werden konnten. Des Weiteren ist die Verfügbarkeit von Patchsets und neuen Versionen des OracleAS für die Linux-Plattform erheblich schneller als für andere UNIX-Devirate. Auswahl der Version und Installation Steht ein neues Projekt an und die Plattform erlaubt es, eine nagelneue Version des OracleAS zu verwenden, stellt sich schnell die Frage, welche Version verwenden wir mit dem geringsten Risiko. Unsere Erfahrung in den einzelnen Projekt zeigte uns, dass die Wahl zum Zeitpunkt des Projektes, immer die neueste verfügbare Version des OracleAS zu verwenden, noch zu keinen erheblichen Mehraufwänden geführt hat. Im Gegenteil: der Einsatz der neueren Releases führte fast immer zu einer besseren Installation und Konfiguration vom Betrieb ganz zu schweigen als der Einsatz einesrhalben bis ein Jahr alten Version mit höchstwahrscheinlich zwei Patchsets und einzelnen Hotfixes, die bei der Installation zusätzlich installiert werden müssen.

3 Ein nicht erheblicher Teil der Probleme, die bei einer Installation in einer komplexen HA-Umgebung verursacht werden, besteht aus fehlerhafter oder unterbundener Kommunikation zwischen den einzelnen Elementen. Deshalb ist es überaus wichtig, sich im Klaren zu sein, welche Kommunikation von welchem Host zu welchem Host über welche Ports mit welchem virtuellen Namen erfolgen muss. Die Erfahrungen zeigen, dass es von Vorteil ist, die Netzwerkinfrastruktur sauber und hinreichend im Vorfeld zu konfigurieren und zu testen. Verwendung der höchst möglichen Version des Produktes READ THE FUCKING... Install Guide Release Guide Patchset Release Notes Surfen im Metalink zur Komponente und Plattform Alle Hosts sind gleich, keiner ist gleicher! Überprüfung der Netzwerkinfrastruktur auf ihre benötigte Funktionen: Namensauflösung (DNS) Routing (Firewall, Load Balancer) Ports (Firewall, Load Balancer, Host) Installiert wird die größte Installationsart (z. B. BI); konfiguriert werden nur die benötigten Komponenten. Netzwerkadministratoren für Load Balancer, Firewall und DNS sind im Zweifel verfügbar. Tools Beim Deployment und Betrieb in den verschiedenen Projekten hat sich gezeigt, dass es von Vorteil ist, wenn man eine Hand voll Tools zur Hand hat, die in dem einen oder anderen Fall zu Hilfe stehen. Unter anderem stellten wir fest, ist es besser, eine Sammlung von kleinen Tools im Zugriff zu haben als mächtige alles erledigende Tools für eine bestimmte Plattform. Zu diesen Tools sollten zählen: PuTTY WinSCP3 XDeep32 telnet Etheral vmstat <interval> top, topas dmstool ihat Freier SSH, Telnet Rlogin Client für 32-bit Windows MIT licence (compatible with the GNU GPL) Dateitransfer Tool über SSH GNU GPL X-Windows Client für Windows Freeware Zur einfachen Überprüfung von Ports Auf jeder Plattform verfügbar Network Protocol Analyzer Verfügbar auf den meisten Plattformen (Windows, Linux..) GNU GPL Metriken des Betriebsystems (Unix) Metriken des Betriebsystems (Unix, AIX) Metriken des OracleAS Monitoring OracleAS Komponenten

4 18. Deutsche ORACLE-Anwenderkonferenz Forms / J2 EE Abb. 3: Network Capturing einer SQL Net8 Verbindung Logging Eines der reichhaltigen Dinge, die der OracleAS auf jeder OracleAS-Instanz ausübt, ist Logging. Als erfolgreiche Praxis hat sich gezeigt, dass es ausreichend ist, das LogRotating zu konfigurieren und einen entsprechenden Job zu konfigurieren, der die entstehenden Logs in ein Archiv stellt, wenn diese aufbewahrt werden müssen. Ein zweiter Ansatz, der häufig angewandt wird, ist das regelmäßige Löschen von alten Log-Dateien. Beispiel: find /opt/oracle/product/9.0.4/mid01 name log*.xml mtime +2 exec rm f {}\; Für das Auffinden von Problemen kann es sehr hilfreich sein, Oracle Diagnostic Logging mit ECID (Execution Context ID) zu aktivieren. Mit dieser Option ist es möglich, anhand der ECID den Durchlauf eines Request durch alle Schichten des OracleAS (WebCache, OHS, OC4J) eindeutig nachzuvollziehen. Hat man ODL konfiguriert, so ist es möglich, alle Log-Dateien in diesem Format über den LogLoader des OracleAS in ein zentrales Repository, sprich an eine bestimmte Stelle, zu konsolidieren. Ab Version ist es möglich, diese Log-Dateien auch in einer Datenbank abzulegen. Konfiguration von LogRotating Konfiguration von ODL mit ECID Monitoring Die Frage, die sich in kleinen wie in großen Projekten zum Thema OracleAS gestellt hat, ist die Überwachung / Monitoring des OracleAS. Im Allgemeinen, wenn es keine Probleme mit den Antwortzeiten gibt, läuft der OracleAS in der Regel sehr stabil. In diesem Fall gibt es eigentlich, unserer Erfahrung nach, einige markante Punkte, die man bei Monitoring im Auge behalten muss, und diese sind u.a.: a.) Antwortzeiten des http-server werden zu nehmend schlechter b.) OC4J Instance läuft voll (JVM) c.) JDBC Connection Pool wird nicht abgebaut d.) Plattenplatz wird durch intensives Logging der Applikationen und des OracleAS knapp Oracle selbst bietet zu diesem Zweck ein Tool mit dem Namen ihat, das es ermöglicht, in relativer Echtzeit den Status des OracleAS einzusehen. Mit der Version des OracleAS gibt es jetzt auch eine Lösung integriert in die Console. Diese Tools haben aus unserer Sicht das Problem, dass der Administrator aktiv werden muss und nicht beim Überschreiten von Schwellwerten automatisch benachrichtigt wird. Für diesen Anwendungsfall sieht Oracle Grid Control vor. Unserer Erfahrung und Einschätzung nach ist die Einführung von Grid Control nur für die Überwachung und das Melden vom Überschreiten von Schwellwerten ein wenig übertrieben. Zudem muss man, nur um diese Funktion zu nutzen, eine weitere nicht gerade einfache Softwarekomponente installieren, warten und auch patchen. Ganz davon abgesehen, dass für diesen Fall eine neue Maschine zur Verfügung gestellt werden muss/sollte.

5 Abb. 4. Monitoring mit ihat Aus diesem Grund haben wir zwei Tools geschrieben, mit dem Ansatz, diese Aufgabe einmal dezentral und einmal zentral zu lösen, je nach Erfordernissen. Aufgabe war: a.) Metriken aus dem Betriebssystem und aus dem OracleAS-Umfeld auf Schwellwerte zu prüfen; diese, wenn gewünscht, in eine Datenbank zu schreiben und/oder eine Mail zu verschicken bzw. einen Web- Service in einem anderen System. Ausführung erfolgt auf dem entsprechenden Host. b.) Zentrale Abfrage der Metriken und Ablage in einer Datenbank der verschiedenen OracleAS-Instanzen von einem zentralen Host aus. Benachrichtigung erfolgt per Mail bzw. durch Aufruf eines Web-Services in einem anderen System. Technologische Grundlage für diese Tools ist das DMS-Framework des OracleAS (dmstool bzw. AggreSpy). Die gleiche Methodik bedient ihat und Oracle Grid Control. Verwendung von Tools, die Benachrichtigung von bestimmten Zuständen des OracleAS melden, ohne selber aktiv zu werden. Fazit Wenn man sich mit dem OracleAS beschäftigt, wird man schnell merken, dass es sich in seiner Gesamtheit um ein großes Packet von Komponenten und Abhängigkeiten handelt, die alle in der einen oder anderen Form konfiguriert und hochverfügbar gemacht werden wollen. Bei allen Dingen, die in diesem Vortrag genannt worden sind, ist die wichtigste Aussage von allen: KEEP IT (AS) SIMPLE (as you can!) Kontaktadresse: Ulrich Gerkmann-Bartels Hermann-Löns-Straße 88 D Paderborn Telefon: +49(0) Fax: +49(0) Internet: