Donnerstag, 10. November 2005 11h00, Stamitzsaal Grid Control Mit Netz und doppeltem Boden Jörn Lanzerath / Dr. Susanne Palm Deutsche Post ITSolutions GmbH, Darmstadt Schlüsselworte Oracle 10g, Grid Control, RAC, HA Einleitung Fast 2 Jahre ist es her, dass Oracle seine Grid-Software der Welt vorgestellt hat. Als erstes Unternehmen hat Oracle damit eine Grid-Software für Unternehmen auf den Markt gebracht. Laut einer Studie von Forrester Research aus dem Jahre 2002 liegt die Serverauslastung im Mittel weit unter 60%. Diese nur mittelmäßige Auslastung resultiert aus der am häufigsten anzutreffenden Infrastruktur innerhalb der Unternehmen, die wie folgt aussieht: Für jede Anwendung wird eine eigene Infrastruktur aufgebaut. Angefangen von eigenen Servern, über eigenen Storage bis hin zur eigenen Benutzerverwaltung. Natürlich muss jede Anwendungslandschaft so ausgelegt sein, dass sie auch zu Spitzenzeiten noch ausreichend schnell arbeiten kann. Dementsprechend liegen Ressourcen zeitweise brach, ohne Leistung zu erbringen. Ein entscheidener Nachteil dieser Struktur ist, dass wenn einer dieser Server ausfällt, damit auch die gesamte Anwendung zusammenbricht. Reichen die Hardware-Kapazitäten irgendwann nicht mehr aus, muss das System vertikal erweitert werden (witere CPUs oder Speicherbausteine). Dem entgegen steht die horizontale Erweiterung bei der weitere Server eingebunden werden. Damit war bisher aber ein hoher Aufwand verbunden. Die Philosophie von Oracle Grid Computing lautet, sämtliche Ressourcen zu bündeln und dynamisch verfügbar zu machen, ohne sich darüber klar werden zu müssen, wo diese herkommen. Aus Sicht der Firma Oracle sieht die ideale Infrastruktur eines Unternehmens wie in Abbildung 1 aus: Abbildung 1: neue Infrastruktur Laut den Marketing-Folien über Oracle 10g Grid Computing auf der Oracle-Homepage stellt jedes der zwei erwähnten Grids einen dynamischen Pool an Ressourcen dar. Wird ein Datenbank-Server gerade stark beansprucht, veranlasst das Grid Control, dass ein weiterer Server Aufgaben der ersten Servers übernimmt. Fällt ein Server aus, soll ein anderer dessen Aufgaben übernehmen. Reichen die Ressourcen eines Grids nicht mehr aus, kann das Grid einfach ( Plug-and-Play ) um weitere Server erweitert werden. Um die zwei Grids besser administrieren zu können, stellt Oracle mit der neuen Infrastruktur gleich das passende Tool zur Verfügung: das Grid Control.
18. Deutsche ORACLE-Anwenderkonferenz Oracle 10g Grid Control Die Software der Architektur Oracle 10g Grid Control baut sich aus vier Komponenten auf: Oracle Management Service (OMS) Grid-Steuerkonsole Oracle Management Repository (OMR) Oracle Management Agent (OMA) Der OMS kann als das Herzstück und Steuerzentrale betrachtet werden, die unter anderem sämtliche Prozesse, die von den einzelnen OMA übermittelt werden, verarbeitet. Außerdem speichert der OMS alle persistenten Daten im OMR ab. Über die Grid-Steuerkonsole lassen sich alle Ziele, auf denen sich Agents befinden, in ihrer Umgebung verwalten Interpretation Schaut man sich die Marketing-Unterlagen zu der Architektur Oracle 10g Grid Control auf der Homepage der Firma Oracle an, so kann man leicht den Eindruck gewinnen, dass man anhand dieser Software die einzelnen Server eines Unternehmens schnell und einfach zu einem Grid zusammenfassen kann. Zuerst installiert man auf einem Server den Oracle Managment Service und das Oracle Managment Repository. Dann versieht man jeden Server des Unternehmens, auf dem eine Datenbank installiert wurde, mit einem Oracle Managment Agent und schon steht das Grid. Sollen neue Server in das Grid eingebunden werden, braucht lediglich eine Datenbank und der Oracle Management Agent installiert zu werden. Das erinnert sehr an den Begriff Plug-and-Play. IT Experience Aber beschäftigt man sich ein bisschen mehr mit dieser Materie und liest auch Dokumente der unabhängigen Fachpresse, merkt man schnell, dass die Realisierung so einfach doch nicht ist. Es zeigt sich, dass die verwendete Software nicht vollständig die Funktionalität der dynamischen Ressourcenzuordnung und -verwaltung bereitstellen kann. Allein durch die Software Oracle 10g Grid Control kann einem belasteten Server nicht automatisch weitere Kapazitäten zugewiesen werden. Um dies zu realisieren, ist mehr notwendig. Der weitere Teil, um die dynamische Ressourcenzuordnung zu ermöglichen, findet sich in der Architektur Oracle 10g Real Application Cluster (RAC). Diese Architektur muss unterhalb der Grid-Control-Architektur implementiert werden. In den nachfolgenden Kapiteln wird gezeigt, leider sehr verkürzt, welche Schritte notwendig sind, um RAC zu implementieren und um nachfolgend Grid-Computing wirklich lauffähig zu machen. Real Application Cluster Oracle Real Application Cluster ist eine Parallel Cluster-Datenbank mit Shared Disk-Architektur. Also eine Datenbank, die auf einem Shared Storage Subsystem abgelegt wird und auf die von zwei oder mehr Knoten zugegriffen wird. Abbildung 2: RAC-Architektur Real Application Cluster hat unter anderem zwei Vorteile: Skalierbarkeit Hochverfügbarkeit.
Reicht die Kapazität der verwendeten Server nicht aus, so können dem Cluster ein oder mehrere Knoten hinzugefügt werden. Da die Knoten auch Kapazitäten verbrauchen, um untereinander zu kommunizieren, geht ein Anteil der Leistung des neuen Servers an die Kommunikation verloren. Durch die Redundanz an Servern wird sichergestellt, dass die Anwendung immer verfügbar ist, auch wenn einmal ein Knoten ausfällt. Struktur des Test-Grids Das Grid, das aufgebaut werden soll, besteht aus drei Knoten. Auf diesen drei Knoten wird zunächst die Architektur Real Application Server (RAC) implementiert. Anschließend wird auf einem anderen Server die Software Oracle Grid Control installiert und dann die Knoten des RAC mit den Oracle Management Agents bestückt. Hardware Zur Implementierung der RAC-Architektur (Knoten 1-3) wurden drei V20z Sunfire-Server verwendet. Der Server für das Grid Control ist ein SUN B100 SparcBlade. Bei der geteilten Speichereinheit handelt es sich um eine SUN StorEdge 3510. Knoten 1-3: Hostname (öffentlich): rac_node1 rac_node2 rac_node3 Hostname (privat): priv_node1 priv_node2 priv_node3 Hostname (viruell): viprac1 viprac2 viprac3 IP-Adresse (öffentlich): 88.0.0.1 88.0.0.2 88.0.0.3 IP-Adresse (privat): 192.168.48.70 192.168.48.71 192.168.48.72 IP-Adresse (virtuell): 88.0.0.11 88.0.0.12 88.0.0.13 Betriebssystem: Solaris 10 Plattform: x86 Arbeitsspeicher: 4032 MB CPU: 2* AMD Opteron Prozessor der 200er Serie 2,33 GHz Festplattenkapazität: 68 GB Geteilter Speicher: Festplattenkapazität: 144 GB Konfiguration der Knoten Bevor die RAC-Software installiert werden kann, müssen die Knoten, wie in der Installationsanweisung beschrieben, konfiguriert werden. Betriebssystem-Patchs Es ist sehr wichtig, dass auf dem Betriebssystem alle notwendigen Patchs installiert sind. SUN Microsystems wartet in seiner neuen Betriebssystems-Version Solaris 10 mit einem eigenen Patch-Manager auf. Dieser Manager analysiert die aktuelle Patch-Situation, lädt die fehlenden Patchs herunter und installiert sie. Benötigte Gruppen und User Es müssen die Betriebssystem-Gruppen dba, oinstall (und optional oper) und die User oracle und nobody angelegt werden. Netzwerk Für jeden Knoten muss eine private und eine öffentliche Netzwerkverbindung eingerichtet werden (um Hochverfügbarkeit zu gewährleisten, wären jeweils zwei Netzwerkverbindungen besser). Zusätzlich benötigt die RAC-Software für jeden Knoten eine virtuelle IP-Adresse, also eine Adresse, die keiner physischen Schnittstelle zugeordnet wird. Sämtliche Hostnamen und zugeordneten IP-Adressen müssen in der Datei /etc/hosts (bzw. per DNS) veröffentlicht werden. Die virtuellen IP-Adressen werden über die Cluster Ready Services eingerichtet und dienen als logische Adresse für den gesamten Cluster. Wichtig ist, dass die private Netzwerkschnittstelle das Attribut private erhält (Befehl: ifconfig <interface> private). Ansonsten würde der VIPCA (virtuell IP Configuration Assistant) während der Installation versuchen, die virtuellen IP-Adressen dem privaten Netzwerkschnittstellen zuzuordnen, was einen kompletten Systemabsturz der verwendeten Knoten zur Folge hatte.
18. Deutsche ORACLE-Anwenderkonferenz Im Folgenden der Inhalt der Datei /etc/hosts: Disk Storage Für die Datenbankdateien kann entweder ASM (Automatic Storage Management), ein Clusterfilesystem oder Raw Devices verwendet werden. Da Raw Devices schwer zu verwalten sind und kein Clusterfilesystem zur Verfügung stand, wurde in diesem Projekt die neue, von Oracle entwickelte Technik ASM verwendet. Es werden zwei Bereiche auf den Shared Disks benötigt, die nicht zusammen mit ASM genutzt werden können. Der erste Bereich, ca. 20 MB, für die Voting Disk, der zweite, ca. 100 MB, für Oracle Cluster Registry (OCR). IT Experience Vor der Installation muss sichergestellt werden, dass der Betriebssystem-User oracle Schreib-, Lese- und Zugriffsrechte auf den verwendeten OCR- und Voting-Disk-Partitionen hat. Benutzeräquivalenz Auf allen Knoten muss die Datei /etc/hosts.equiv angepasst werden. Alle von den darin aufgeführten Rechnern zugreifenden Benutzer haben dieselben Rechte wie der lokale Nutzer mit gleichem Benutzernamen. Diese Benutzer können ohne explizite Angabe eines Passwortes über entfernte Dienste auf den Rechner zugreifen. Voraussetzung ist die Existenz derselben Nutzerkennung auf dem Zielrechner. Konfiguration SSH Es muss gewährleistet sein, dass von jedem Knoten aus über Remote Copy (rcp) auf jeden Knoten zugegriffen werden kann. Anstatt rcp kann aber auch, so wie es hier, Secure Shell (ssh) verwendet werden. Um SSH einzurichten, muss als User oracle im Home-Verzeichnis das Verzeichnis.ssh angelegt und die Berechtigung 775 (chmod 775.ssh) vergeben werden, wodurch der User und Mitglieder der gleichen Gruppe sämtliche und andere nur eingeschränkte Rechte haben. In diesem Verzeichnis wird durch die Befehle /usr/bin/ssh-keygen -t rsa und /usr/bin/ssh-keygen -t dsa vier Dateien erstellt, id_rsa, id_rsa.pub, id_dsa und id_dsa.pub. Jetzt muss auf dem ersten Knoten der Inhalt der beiden Dateien id_rsa.pub und id_dsa.pub in die Datei authorized_keys kopiert werden. Dies geschieht durch den Befehl cat id_rsa.pub id_dsa.pub > authorized_keys. Die erzeugte Datei wird dann über FTP auf den nächsten Knoten verschoben. Dort werden wiederum die vier Dateien erzeugt und der Inhalt der zwei.pub-dateien in die Datei authorized_keys kopiert: cat id_rsa.pub id_dsa.pub >> authorized_keys. Das passiert auf jedem Knoten. Enthält die Datei alle Knoten-Inhalte, musste sie auf alle Knoten zurückkopiert werden.
Um die korrekte Konfiguration von SSH zu überprüfen, sollte von jedem Knoten aus der Befehl ssh node_name date ausgeführt werden. Bei der ersten Ausführung des Befehls, muss noch bestätigt werden, dass der entfernte Knoten persistent in die Liste akzeptierter Knoten eingetragen wird. Anschließend kann der Befehl ohne eine Bestätigung ausgeführt werden. Verwendete Verzeichnisse Es müssen zwei Verzeichnisse angelegt werden. Das erste ist das ORACLE_BASE-Verzeichnis, in dem die Oracle-Datenbank installiert wird. Das zweite Verzeichnis, CRS_HOME, wird die Dateien des Cluster Ready Services (CRS) beinhalten. ORACLE_BASE: CRS_HOME: /u01/app/oracle /u01/crs/oracle/product/10.1.0/crs_1 Der Betriebssystem-User oracle muss Eigentümer beider Verzeichnisse sein. Außerdem müssen beide Verzeichnisse als ORACLE_BASE und ORACLE_HOME-Variable veröffentlicht sein, wobei mit der ORACLE_HOME-Variable das CRS_HOME-Verzeichnis gemeint ist. Installation der Cluster Ready Services Die Installationsdateien müssen auf einem Knoten abgelegt und durch den User oracle gestartet werden. Fenster 2: Betiebssystem-User root muss das Shell-Skript orainstroot.sh auf dem Knoten ausführen, auf dem die Installation ausgeführt wird. Das Skript liegt im zuvor bestätigten Iventory-Verzeichnis. Durch das Skript werden einige benötigte Berechtigungen vergeben. Fenster 5: Angaben über die mit den privaten und öffentlichen Netzwerkverbindungen verknüpften Hostnamen der beteiligten Knoten. Es sollte immer der vollqualifizierte Name verwendet werden (also hostname.domänenname). öffentliche Netzwerkverbindung rac_node1.dp-itsolutions.de rac_node2.dp-itsolutions.de rac_node3.dp-itsolutions.de private Netzwerkverbindung priv_node1.dp-itsolutions.de priv_node2.dp-itsolutions.de priv_node3.dp-itsolutions.de Fenster 6: Aufteilung der gefundenen Netzwerkschnittstellen in öffentliche und private Schnittstellen. Schnittstelle Subnetz Schnittstellentyp bge0 88.0.0.0 Public bge1 10.195.168.0 Private Fenster 7 + 8: Pfad zur Partition, die für die a) OCR b) Voting-Disk vorgesehen ist. a) /dev/rdsk/c3t600c0ff00000000008539f44f3d81b04d0s0 b) /dev/rdsk/c3t600c0ff00000000008539f44f3d81b04d0s1 Fenster 11: Installation der RAC-Software auf allen Knoten Fenster 12: Nacheinander muss auf jedem Knoten das Skript root.sh im Verzeichnis CRS_HOME als User root ausgeführt werden. Dadurch wird automatisch das Oracle Cluster Registry Configuration Tool (ocrconfig) installiert, der unter anderem dafür zuständig ist, in regelmäßigen Abständen OCR-Backups zu erstellen. Anschließend startet das Cluster Configuration Tool (clscfg), das den Cluster konfiguriert und Keys in der OCR erstellt.
18. Deutsche ORACLE-Anwenderkonferenz Um die erfolgreiche Installation der Cluster Ready Services zu überprüfen, kann im CRS_HOME/bin-Verzeichnis der Befehl olsnodes eingegeben werden. Dadurch werden die Namen aller beteilgten Knoten ausgegeben. Außerdem müssen die Prozesse oprocd,evmd,ocssd und crsd laufen (Befehl: ps-ef grep crs) Installation Oracle DBMS Bevor das Oracle Datenbank-Managementsystem installiert werden kann, muss die Variable ORACLE_HOME auf das Verzeichnis zeigen, in die das Oracle DBMS installiert wird: ORACLE_HOME: /u01/app/oracle/product/10.1.0/db_1 Anschließend kann der Installationsassistent gestartet werden. Fenster 2: Auswahl der Cluster-Knoten rac_node1, rac_node2, rac_node3 Fenster 4: Auswahl der Datenbankkonfiguration Startdatenbank wird nicht angelegt Fenster 6: Installation der DBMS-Software auf allen Knoten Fenster 7: Nacheinander muss auf jedem Knoten das Skript root.sh im Verzeichnis ORACLE_HOME als User root ausgeführt werden. Während des Ablaufs des Sktipts erscheint auf dem Knoten auf dem das Skript als Erstes gestartet wird, der Virtuell IP Configuration Assistant (VIPCA), der die Verwendung der virtuellen IP-Adressen konfiguriert. Fenster A: Darstellung der gefundenen Netzwerkschnittstellen. An dieser Stelle sollte die private Netzwerkschnittstelle nicht erscheinen. Fenster B: Zuweisung einer virtuellen IP-Adresse zu jedem Knoten. IT Experience Knotenname IP-Alias-Name IP-Adresse Subnetzmaske rac_node1 racvip1.dp-itsolutions.de 10.195.33.68 255.255.255.0 rac_node2 racvip2.dp-itsolutions.de 10.195.33.69 255.255.255.0 rac_node3 racvip3.dp-itsolutions.de 10.195.33.76 255.255.255.0 Erstellung einer RAC-Datenbank In diesem Abschnitt werden die Instanzen einer Datenbank auf den beteiligten Knoten installiert. Auch dafür hat Oracle einen Assistenten zur Verfügung gestellt: den Database Configuration Assistant (DBCA). Anhand des DBCA kann eine Datenbank angelegt, konfiguriert oder gelöscht werden. Auch dieser Assistent befindet sich im Verzeichnis ORACLE_HOME/bin und wird durch Eingabe des Befehls dbca gestartet. Fenster 1: Auswahl des Datenbanktyps (Cluster- oder Single-Instance-Datenbank) Hier wird die Option Cluster-Datenbank ausgewählt. Fenster 5: Angabe des globalen Datenbanknamens und der SID Globaler Datenbankname: org SID: org Fenster 9: Auswahl des Typs der Parameter-Datei (PFILE, SPFILE). Gewählter Parameter-Datei-Typ: PFILE
Fenster 10: Bestätigung, dass der DBCA die ASM-Instanz anlegen wird. Fenster 11: Auswahl der Diskgroups Fenster 12: Installation der Datenbankinstanzen Der Real Application Cluster ist nun vollständig installiert. Die nächsten Schritte wären, auf einem Server den Oracle Management Service und das Oracle Management Repository zu installieren. Anschließend muss auf jedem RAC-Knoten der Oracle Management Agent installiert werden. Fazit: In den vorherigen Kapiteln wurde gezeigt, welche Schritte notwendig sind, um ein Real Application Cluster zu installieren. Darauf kann die Architektur Oracle 10g Grid Control aufgesetzt werden. Nur durch das Zusammenspiel beider Architekturen können Funktionalitäten wie dynamische Ressourcenverteilung und deren Konsolidierung in Anspruch genommen werden. Kontaktadressen: Jörn Lanzerath Dr. Susanne Palm Bolongarostr. 24 Deutsche Post ITSolutions GmbH D-65934 Frankfurt Hilpertstr. 31 D-64295 Darmstadt +49(0)69-65309475 +49(0)6151-4276 joern.lanzerath@web.de susannepalm@dp-itsolutions.de http://www.dp-itsolutions.de