stat res -t -init -w "NAME co crf" NAME

Transkript

1 Tipps & Tricks: Oktober 2013 Bereich: RAC Erstellung: 10/2013 KS Versionsinfo: 11.2 Letzte Überarbeitung: 10/2013 HW Als PDF Downloaden! Cluster Health Monitor 1. Allgemein Cluster Health Monitor (CHM) ist ab der Version (bei Linux) integraler Bestandteil der Grid Infrastruktur und dient dazu bei Cluster Problemen, wie z. B. plötzliches Stoppen eines Knotens oder Hänge-Situationen, detaillierte Informationen zur Verfügung zu stellen. CHM ermittelt Systemzustände pro Sekunde (bei alle 5 Sekunden) bezüglich Prozesse, Storage, Memory und Netzwerk und stellt diese im Rahmen von bewerteten Metriken zur Verfügung. Die Daten werden innerhalb des Filesystems in einem sogenannten CHM-Repository, dessen Größe angepasst werden kann, gesammelt. 2. Unterschied zu OS Watcher CHM läuft als OS API direkt im Grid-Infrastruktur-Stack und ermöglicht damit das Sammeln von Daten auch innerhalb eines stark ausgelasteten Cluster-Systems. Der OS Watcher benutzt Unix-Kommandos die das System stärker belasten und bei Engpäßen zu zusätzlichen Performance-Problemen führen können. Dennoch sollten beide Tools parallel laufen, da CHM bestimmte Funktionen des OS Watchers wie die UNIX-Tools netstat oder traceroute nicht unterstützt. 3. Verfügbarkeit von CHM CHM ist bei Linux ab , bei Windows ab verfügbar. Für GI-Versionen vor kann CHM für Linux via OTN heruntergeladen werden. Für Linux steht unter der gleichen URL eine graphische Oberfläche zur Verfügung. 4. Überprüfung von CHM Ist die Cluster-Ressource auf allen Knoten eines Clusters gestartet? [grid@s-sl-rac05a:~]>crsctl stat res -t -init -w "NAME co crf" NAME TARGET STATE SERVER STATE_DETAILS Cluster Resources ora.crf 1 ONLINE ONLINE s-sl-rac05a Seite 1 von 14

2 Die Cluster-Ressource ora.crf (auf allen Knoten verfügbar) besteht aus folgenden Komponenten: Cluster Logger Service System Monitor Service Der im Cluster Logger Service beinhaltete ologgerd-daemon ist für die Synchronisation der Systemstatistiken der einzelnen Knoten mit dem Master-Repository zuständig. Aufgabe des System Monitor Services ist das Sammeln von Systemdaten (bei jede Sekunde, bei alle 5 Sekunden) und das Übermitteln der Daten an das Master-Repository. 5. Verwaltung Repository CHM verwendet pro Knoten ein lokales Directory zum Sammeln der Daten. Wenn ein Knoten die Verbindung zum Master Cluster Logger Service verliert, können die Daten weiterhin gespeichert werden. Die CHM-Tools greifen aber auch auf Daten des zentralen Master-Repositories zu, welches auf einem einzelnen Knoten innerhalb des Clusters liegt. So erhalten die das aktuelle Repository-Verzeichnis: [grid@s-sl-rac05a:~]>oclumon manage -get reppath CHM Repository Path = /u01/app/11.2.0/grid/crf/db/s-sl-rac05a Done So erhalten Sie die aktuelle Retention-Time des Repositories (in Sekunden): [grid@s-sl-rac05a:~]>oclumon manage -get repsize CHM Repository Size = Done Die Standard Retention bei beträgt 3 Stunden, bei nur 1 Stunde. Empfehlung: Erhöhung auf 1 Tag (maximal 3 Tage möglich). Die Größe des Repositories beträgt ca. 1 GB/Knoten/Tag. Vergrößerung auf einen Tag (gilt für alle Knoten): [grid@s-sl-rac05a:~]>oclumon manage -repos resize Done [grid@s-sl-rac05a:~]>oclumon manage -get repsize CHM Repository Size = Seite 2 von 14

3 Done 6. Sammeln von Daten Für Service Requests über die My Oracle Support Webseite ist es manchmal notwendig, CHM Infos zu sammeln und hochzuladen. Deshalb sei hier das Sammeln der CHM Infos für die Version beispielhaft aufgezeigt: --collect --chmos --incidenttime "07/01/201310:00:00" --incidentduration 01:00 Production Copyright 2004, 2010, Oracle. All rights reserved Cluster Ready Services (CRS) diagnostic collection tool Cluster Health Monitor (OS) information has not been retrieved. Run diagcollection on s-tl-029 to collect CHM/OS information Collecting OS logs Collecting sysconfig data Die Daten werden aus dem Repository gelesen und als komprimierte Dateien im aktuellen Verzeichnis abgelegt: -l *s-tl-025** -rw-r--r-- 1 root root 375 Oct 9 00:16 osdata_s-tl-025_ _0016.tar.gz -rw-r--r-- 1 root root Oct 9 00:16 sysconfig_s-tl-025_ _0016.txt [root@s-tl-025:/home/grid]>tar -tvf osdata_s-tl-025_ _0016.tar.gz -rw root/root :02:02 var/log/messages -rw root/root :00:01 var/log/messages.1 -rw root/root :02:02 var/log/messages.2 -rw root/root :02:02 var/log/messages.3 -rw root/root :40:01 var/log/messages.4 Bei Version hatten wir dabei leider auch schon mal folgendes Problem gesehen: Seite 3 von 14

4 Hier hilft dann die folgende Alternative zum obigen Befehl für das Sammeln der CHM Infos weiter: dumpnodeview -allnodes -v -s " " -e " " > /tmp/chm.log /tmp/chm.log Node: s-sl-rac05b Clock: ' ' SerialNo: SYSTEM: #cpus: 2 cpu: 2.19 cpuq: 1 physmemfree: physmemtotal: mcache: swapfree: swaptotal: ior: 95 iow: 1 ios: 5 swpin: 0 swpout: 0 pgin: 95 pgout: 1 netr: netw: procs: 222 rtprocs: 11 #fds: 4514 #sysfdlimit: #disks: 16 #nics: 3 nicerrors: 0 P CONSUMERS: topcpu: 'orarootagent.bi(11688) 0.99' topprivmem: 'ologgerd(11347) 84380' topshm: 'ologgerd(11347) 61056' topfd: 'ocssd.bin(11278) 162' topthread: 'crsd.bin(11579) 44' PROCESSES: name: 'orarootagent.bi' pid: #procfdlimit: cpuusage: 0.99 privmem: shm: #fd: 11 #threads: 11 priority: 19 name: 'evmd.bin' pid: #procfdlimit: cpuusage: 0.99 privmem: shm: #fd: 76 #threads: 17 priority: 19 name: 'osysmond.bin' pid: #procfdlimit: cpuusage: 0.99 privmem: shm: #fd: 59 #threads: 10 priority: 139 [...] 7. Auswertungen Fragestellung: Welche Alerts liegen aktuell auf allen Knoten des Clusters vor? [grid@s-sl-rac05a:~]>oclumon dumpnodeview -allnodes -alert -cont -i Node: s-sl-rac05a Clock: ' ' SerialNo: Seite 4 von 14

5 SYSTEM: #cpus: 2 cpu: 4.0 cpuq: 1 physmemfree: physmemtotal: mcache: swapfree: swaptotal: ior: 239 iow: 176 ios: 44 swpin: 0 swpout: 0 pgin: 239 pgout: 176 netr: netw: procs: 283 rtprocs: 13 #fds: 7056 #sysfdlimit: #disks: 16 #nics: 3 nicerrors: 0 P CONSUMERS: topcpu: 'ologgerd(17175) 1.99' topprivmem: 'java(20903) ' topshm: 'ora_lms0_racdb1(3436) ' topfd: 'ocssd.bin(17133) 180' topthread: 'crsd.bin(17419) 48' Node: s-sl-rac05a Clock: ' ' SerialNo: SYSTEM: #cpus: 2 cpu: 3.48 cpuq: 1 physmemfree: physmemtotal: mcache: swapfree: swaptotal: ior: 127 iow: 295 ios: 62 swpin: 0 swpout: 0 pgin: 127 pgout: 263 netr: netw: procs: 282 rtprocs: 13 #fds: 6998 #sysfdlimit: #disks: 16 #nics: 3 nicerrors: 0 P CONSUMERS: topcpu: 'osysmond.bin(17134) 1.98' topprivmem: 'java(20903) ' topshm: 'ora_lms0_racdb1(3436) ' topfd: 'ocssd.bin(17133) 180' topthread: 'crsd.bin(17419) 48' [...] Fragestellung: Welche Alerts lagen im Zeitraum zwischen 10:15 Uhr und 10:30 Uhr auf allen Knoten vor? [grid@s-sl-rac05a:~]>oclumon dumpnodeview -allnodes -alert -s " " -e " " Node: s-sl-rac05b Clock: ' ' SerialNo: SYSTEM: #cpus: 2 cpu: 2.88 cpuq: 1 physmemfree: physmemtotal: mcache: swapfree: swaptotal: ior: 205 iow: 151 ios: 29 swpin: 0 swpout: 0 pgin: 205 pgout: 151 netr: netw: procs: 224 rtprocs: 11 #fds: 4579 #sysfdlimit: #disks: 16 #nics: 3 nicerrors: 0 P CONSUMERS: topcpu: 'orarootagent.bi(11688) 0.98' topprivmem: 'ologgerd(11347) 84380' topshm: 'ologgerd(11347) 61056' topfd: 'ocssd.bin(11278) 162' topthread: 'crsd.bin(11579) 44' Node: s-sl-rac05b Clock: ' ' SerialNo: SYSTEM: #cpus: 2 cpu: 3.22 cpuq: 4 physmemfree: physmemtotal: mcache: Seite 5 von 14

6 #cpus: 2 cpu: 3.22 cpuq: 4 physmemfree: physmemtotal: mcache: swapfree: swaptotal: ior: 127 iow: 173 ios: 49 swpin: 0 swpout: 0 pgin: 127 pgout: 172 netr: netw: procs: 222 rtprocs: 11 #fds: 4513 #sysfdlimit: #disks: 16 #nics: 3 nicerrors: 0 P CONSUMERS: topcpu: 'ocssd.bin(11278) 1.99' topprivmem: 'ologgerd(11347) 84380' topshm: 'ologgerd(11347) 61056' topfd: 'ocssd.bin(11278) 162' topthread: 'crsd.bin(11579) 44' End of data Weitere Fragestellungen könnten folgende Bereiche betreffen: Benutzerprozesse Systemprozesse Plattenaktivität Netzwerk Hinweis: Bei den Metriken werden (von Oracle) bewertete Schwellwerte (red, orange, yellow, green) anstatt absoluter Werte verwendet. Beispiel: Prozessauswertung [grid@s-sl-rac05a:~]>ps -ef grep "oracleracdb1" [...] oracle Sep18? 00:00:00 oracleracdb1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROCOL=beq))) [grid@s-sl-rac05a:~]>oclumon query> showtrail -n s-sl-rac05a -pid cputimepc memusage No time range specified, querying for last 30 mins... Parameter=CPU TIME PERCENT :13: :14: :14:43 [...] :15:15 query> showtrail -n s-sl-rac05a -pid cputimepc memusage -s "" -e "" Parameter=CPU TIME PERCENT Parameter=PRIVATE MEMORY USAGE Seite 6 von 14

7 Beispiel: Systemauswertung query> showtrail -n s-sl-rac05a -sys usagepc cpuqlen cpunumprocess openfds numrt numofiosps memfree -s "" -e "" Parameter=USAGE PERCENT :39: :39: :39:54 YELLOW :39:54 Parameter=CPU QUEUELENGTH :39: :39: :39:28 RED :39: :39: :39: :39:51 RED :39:51 Parameter=NUMBEROFPROCESSES Parameter=OPENFDS Parameter=# OF RT PROCESSES Seite 7 von 14

8 RED RED RED Parameter=IO OPERATIONS PER SEC Parameter=MEM FREE query> Beispiel: Plattenauswertung Die Platte /dev/sde1 ist Mitglied der ASM-Diskgruppe DATA (diese beinhaltet u. a. Datenbank-Dateien). query> showtrail -n s-sl-rac05a -diskid sde1 qlen totalwaittime -s " :39:00" -e "" Parameter=QUEUE LENGTH Parameter=TAL WAIT TIME :39: :39: :39:14 ORANGE query> Um nur die "Warnungen" anzuzeigen: query> showtrail -n s-sl-rac05a -diskid sde1 qlen totalwaittime -s " Seite 8 von 14

9 query> showtrail -n s-sl-rac05a -diskid sde1 qlen totalwaittime -s " :39:00" -e "" -c "red" "orange" "yellow" Parameter=QUEUE LENGTH Parameter=TAL WAIT TIME :39: :39:14 ORANGE Beispiel: NIC (Network Interface Card) Auswertung Fragestellung: Gab es Fehler auf dem Cluster-Interconnect Interface? query> showtrail -n allnodes -nicid eth1 effectivebw errors -s "" -e "" CRS-9104-No data available for the given nodes 8. Graphische Oberfläche CHMOSG Die graphische Oberfläche CHMOSG für Linux kann über OTN (Oracle Technet) heruntergeladen werden. Sie muss auf Systemen installiert werden, die entweder Oracle GI oder das zugehörige CHM aus dem OTN installiert haben. Hinweis: Eine Beschreibung der einzelnen Parameter befindet sich im Anhang A, die Installation der graphischen Oberfläche (GUI) in Anhang B. Seite 9 von 14

10 Mit etwas mehr Ressourcen Verbrauch: Problem: Bei einem überlasteten System macht es wenig Sinn zusätzlich die graphische Oberfläche laufen zu lassen. Entweder die graphische Oberfläche wird von einem Knoten innerhalb des Clusters gestartet, der nicht ausgelastet ist oder die graphische Oberfläche wird auf einem Leitstand-Rechner (zusammen mit dem CHM aus OTN) installiert. Alternativ bietet die graphische Oberfläche eine Aufzeichnungsfunktion an, d. h. nachdem z. B. die Hänge-Situation behoben ist, kann der Stand von vor z. B. 60 Minuten dargestellt werden: $./chmosg d 60 Seite 10 von 14

11 Zusätzlich mit Histogrammen für Top Resource Consumer und Cluster Statistiken: $./chmosg 1 d 110 Im Pin-Modus (Eingabe p ) kann ein Zustand in einer Zelle fixiert werden und die Werte aus den anderen Zellen korrespondieren mit dem Zeitpunkt des Pinnens. Um Statistiken ermitteln zu können, kann mit dem Maus-Zeiger auf den Knoten-Namen gegangen und der Wert s eingegeben werden: Seite 11 von 14

12 Start im interaktiven Modus: Seite 12 von 14

13 9. Fazit Der CHM ermöglicht das Sammeln von Cluster-relevanten Systemparametern und die Auswertung der gesammelten Daten. Durch den geringen Overhead ist das permanente Sammeln auch bei hoher Systemlast gewährleistet. Bei Problemen innerhalb des Clusters ermöglicht CHM eine Erstanalyse bzw. stellt Daten für den Oracle Support zur Verfügung. Leider veröffentlicht Oracle keine Übersicht über die vordefinierten Schwellwerte. Eine sehr nützliche Funktion ist die Replay-Funktionalität der graphischen Oberfläche, die eine nachträgliche Analyse des Cluster-Problems mit einer Vielzahl an Systemparametern ermöglicht. Im Zusammenspiel mit dem OS Watcher erhöht CHM die Verfügbarkeit eines Clustersystems. 10. Anhang A SYSTEM #cpus: number of CPU's cpu: percent of CPU utilization cpuq: CPU queue length physmemfree: free physical memory in KB mcache: memory cache in KB swapfree: free virtual memory ior: I/O reads in KB per second iow: I/O writes in KB per second ios: I/Os per second netr: network reads in KB per second netw: network writes in KB per second procs: number processes rtprocs: number of real time processes #fds: number file descriptors #sysfdlimit: system file descriptor limit #disks: number of disks Seite 13 von 14

14 #nics: number of NICs nicerrors: number of network card errors P CONSUMERS topcpu: name and PID of top CPU consuming process and percentage of usage topprivmem: name and PID of top memory consuming process and usage in KB topworkingset: name and PID of top working set process working set in KB topfd: name and PID of process that consumes most file descriptors and number of used descriptors topthread: name and PID of process with most threads and number of threads 11. Anhang B Die Installation der graphischen Oberfläche CHMOSG soll hier in aller Kürze beschrieben werden. Weitere Details finden Sie im README der Installationsdatei. Wir setzen voraus, dass CHM bereits installiert ist. CHMOSG (Zip-Datei) herunterladen über OTN: Die Zip-Datei bitte in einem neuen Verzeichnis entpacken, z. B. in /home/grid/ohm. Und danach folgendermaßen im Verzeichnis /home/grid/ohm_ui installieren: [grid@s-sl-rac05a:~]> cd /home/grid/ohm/install [grid@s-sl-rac05a:~/ohm/install]> export CRFPERLBIN=/usr/bin [grid@s-sl-rac05a:~/ohm/install]>./chminstall -i /home/grid/ohm_ui ORACLE_HOME found. Using Java at /u01/app/11.2.0/grid/jdk Installation completed sucessfully at /home/grid/ohm_ui... Aufrufen läßt sich die GUI dann mittels: [grid@s-sl-rac05a:~]> cd /home/grid/ohm_ui/bin [grid@s-sl-rac05a:~/ohm_ui/bin]>./chmosg Seite 14 von 14