Aufgebaut wurde das System, um einige Tools zu testen, so z.B. das neue Oracle Cloud Control 12c, Toad for Oracle und Spotlight von Quest mit ihren RAC Komponenten sowie das HLMM (Herrmann & Lenz Monitoring Module). Dabei kam es nicht auf „zertifizierte“ Konfigurationen oder gar den Aufbau einer produktiven Umgebung an, sondern darauf, mit minimalem Aufwand eine RAC-Datenbank aufzubauen.
Eingesetzte Software:
- VMware ESXi 5.0
- Oracle Enterprise Linux 6 Update 1 (OEL 6U1)
- Oracle Database und Grid Infrastructure 11.2.0.3
Als shared Storage wurde einfach der VMware ESXi selbst genommen, wie das geht beschreibe ich etwas später.
Zunächst einmal wird eine virtuelle Maschine (Asterix) mit 4 GB Hauptspeicher, zwei Netzwerkadaptern und 40 GB Disk aufgebaut und Oracle Enterprise Linux 6 Update 1 installiert (30 GB hätten es sicherlich auch getan, aber für spätere Updates und den Enterprise Cloud Control Agenten sollte man durchaus Platz vorsehen). Dann wird diese virtuelle Maschine als Obelix „gecloned“.
Nachdem jetzt Asterix und Obelix als Linux Systeme funktionieren und die Netzwerke (eines als Public und eines als Private) konfiguriert wurden, ist es an der Zeit den Shared Storage zu definieren. Vorher sollten jedoch SELINUX und die Firewall ausgeschaltet werden.
Konfiguration des Shared Storage
Auf Asterix werden jetzt zwei zusätzliche virtuelle Festplatten angelegt (je 20 GB). Dabei muss auf folgendes geachtet werden:
- Die Disks müssen als „Thick-Provision Eager-Zeroed“ angelegt werden. Geschieht dies nicht, beschwert sich später der SCSI-Controller, dass ein Sharing nicht möglich ist.
- Es muss ein eigenes SCSI-Controller gewählt werden => SCSI (1:0) und SCSI (1:1)
- Der Modus für Snapshots muss „Dauerhaft Unabhängig“ sein
- Mit der Definition der ersten der neuen virtuellen Festplatte taucht jetzt ein neuer SCSI-Controller auf. Dieser muss noch auf „Virtuell“ eingestellt werden. (In der Beschreibung wird deutlich, dass dann mehrere virtuelle Maschinen auf dem gleichen Server die virtuelle Festplatte gemeinsam nutzen können).
- Jetzt werden die Festplatten erzeugt, was einige Zeit dauert, da sie ja vollständig angelegt und vorformatiert werden müssen.
Das gleiche wird auch auf Obelix durchgeführt, hier allerdings für SCSI (2:0) und SCSI (2:1). Dannach gibt es also je virtueller Maschine zwei Festplatten mit je 20 GB, die geshared werden können.
Es bleibt noch, die virtuellen Disks bei der jeweils anderen Maschine bekannt zu machen (natürlich hätte man auch alle Disks auf einer virtuellen Maschine erstellen und dann nur auf der anderen bekannt machen können, aber so ging es schneller).
Für Obelix bedeutet dies, dass jetzt zusätzlich zwei virtuelle Festplatten hinzugefügt werden, allerdings nicht über „Neue virtuelle Festplatte erstellen“ sondern „Vorhandene virtuelle Festplatte verwenden“. Dabei werden die Festplatten asterix_1.vmdk und asterix_2.vmdk ausgewählt. Wichtig ist, dass wiederum ein neuer SCSI Controller (in diesem Fall SCSI(1:0) und SCSI (1:1) gewählt wird und der SCSCI-Bus auf „Virtuell“ eingestellt wird.
Wenn Sie alles richtig gemacht haben, sollten beide virtuelle Maschinen jetzt sauber hochfahren und dann können Sie mit „fdisk -l“ auf beiden Maschinen die Festplatten sdb, sdc, sdd und sde erkennen.
Installation und Konfiguration ASM
Bevor ASM konfiguriert werden kann, muss der „Besitzer“ der ASM Disks festgelegt werden. Es ist zwar möglich, dass alle Oracle Komponenten unter dem „Oracle“ Owner installiert werden, besser ist es jedoch, die Grid-Infrastruktur von der Datenbank zu trennen, daher werden zwei Linux User (oracle und oragrid) sowie drei Gruppen (oinstall, dba und griddba) angelegt.
Es gibt zwei Methoden, ASM zu konfiguieren, einmal über die asmlib und zum anderen über die Verwendung der Linux udev Definition. Da ich in der Vergangenheit immer gute Erfahrungen mit asmlib gemacht habe, bin ich dabei geblieben. Daher habe ich das entsprechende Paket auf OTN heruntergeladen und installiert (rpm -Uvh oracleasmlib-2.0.4-1.el5.x86_64.rpm. Außerdem muss noch das ASM-Support Paket installiert werden. Das finden Sie auf der OEL 6U1 DVD (oracleasm-support-2.1.5-1.el6.x86_64.rpm).
Jetzt werden zunächst mit fdisk auf einem Rechner (!) die Partitionen angelegt (je Disk eine Partition), so dass fdisk -l später dieses Ergebnis liefert:
Device Boot Start End Blocks Id System /dev/sda1 * 1 64 512000 83 Linux Partition 1 does not end on cylinder boundary. /dev/sda2 64 5222 41430016 8e Linux LVM Disk /dev/sdb: 21.5 GB, 21474836480 bytes 255 heads, 63 sectors/track, 2610 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x54a3d8c5 Device Boot Start End Blocks Id System /dev/sdb1 1 2610 20964793+ 83 Linux ... Device Boot Start End Blocks Id System /dev/sdc1 1 2610 20964793+ 83 Linux ... Device Boot Start End Blocks Id System /dev/sdd1 1 2610 20964793+ 83 Linux ... Device Boot Start End Blocks Id System /dev/sde1 1 2610 20964793+ 83 Linux
Als nächstes wird ASM auf beiden Systemen konfiguriert:
# service oracleasm configure Configuring the Oracle ASM library driver. This will configure the on-boot properties of the Oracle ASM library driver. The following questions will determine whether the driver is loaded on boot and what permissions it will have. The current values will be shown in brackets ('[]'). Hitting without typing an answer will keep that current value. Ctrl-C will abort. Default user to own the driver interface []: oragrid Default group to own the driver interface []: griddba Start Oracle ASM library driver on boot (y/n) [n]: y Scan for Oracle ASM disks on boot (y/n) [n]: y ...
Jetzt können die ASM Disks angelegt werden (nur auf einem System, z.B. Asterix)
# service oracleasm createdisk ASM1 /dev/sdb1 # service oracleasm createdisk ASM2 /dev/sdc1 # service oracleasm createdisk ASM3 /dev/sdd1 # service oracleasm createdisk ASM4 /dev/sde1
Auf dem anderen System wird jetzt die ASM-Konfiguration eingelesen:
# service oracleasm scandisks
Danach sind die ASM-Disks auf beiden System sichtbar und können für die Grid Infrastruktur verwendet werden.
Installation Grid Infrastruktur
Die Installation der Grid Infrastruktur ist eigentlich ganz einfach. Hilfreich ist, dass Oracle seit Version 11.2.0 einen „Out-Of-Place“ Upgrade bei Patchsets erlaubt bzw. verlangt. Das bedeutet, dass das Patchset 11.2.0.3 als ganz normales Release installiert werden kann und nicht, wie früher, zunächst das Basisrelease installiert werden muss.
Die Grid-Infrastruktur befindet sich auf dem dritten Teil des Patchsets (p10404530_112030_Linux-x86-64_3of7.zip).
Bevor der Universal Installer aufgerufen wird, müssen noch ein paar Konfigurationen für das Netzwerk vorgenommen werden. Am einfachsten und von Oracle empfohlen ist die Benutzung eines Namesservers, da nur so mehrere SCAN (Single Client Access Names) definiert werden können. Da es sich bei meinem System, wie bereits erwähnt, um eine Testkonfiguration handelt, habe ich mir die Mühe nicht gemacht, sondern einfach die entsprechenden Einträge in der Host-Datei vorgenommen. Das heißt:
- Je eine „Public“ IP-Adresse (asterix und obelix)
- Je eine „Private“ IP-Adresse (asterix-priv und obelix-priv)
- Je eine „Virtual“ IP-Adresse (asterix-vip und obelix-vip)
- eine SCAN IP-Adresse für den gesamten Cluster (gallier)
Außerdem muss es möglich sein, dass beide Systeme ohne Passwortabfrage mit einander kommunizieren können. Dafür muss das ssh für „oragrid“ und „oracle“ entsprechend aufgesetzt werden:
Asterix: $ ssh-keygen -t rsa Obelix: $ ssh-keygen -t rsa $ cd .ssh $ cp rsa.pub authorized_keys $ scp authorized_keys asterix:.ssh Asterix: $ cd .ssh $ cat rsa.pub >> authorized_keys $ scp authorized_keys obelix:.ssh $ ssh asterix date $ ssh obelix date Obelix: $ ssh asterix date $ ssh obelix date
Jetzt sollten keine Abfragen nach Passworten mehr zwischen den Systemen stattfinden und die Installation der Grid Infrastruktur kann durchgeführt werden.
Die Installation unter dem Benutzer „oragrid“ gestaltet sich im weiteren ganz einfach, wenn man beachtet, welches Netzwerk „Public“ und welches „Private“ ist. Die Cluster Registry Dateien können seit Oracle 11 Release 2 auch ins ASM gelegt werden, so dass separate disks hierfür nicht notwendig sind. Wenn Sie die entsprechende Option auswählen werden als nächstes die „Candidate Disks“ fürs ASM angezeigt und die Dateien können angelegt werden. Das Passwort des ASM Users muss eine gewisse Komplexität aufweisen (manager als Passwort ist nicht mehr möglich
Am Schluss müssen wie üblich die root.sh aufgerufen werden. Hierbei ist darauf zu achten, dass sie nacheinander und nicht gleichzeitig ausgeführt werden, d.h. etwas warten ist angesagt.
Gleiches gilt für die Installation der Datenbank-Software (unter dem Benutzer „oracle“). Hat man vorher einen Fehler gemacht oder wurde die Installation der Grid-Infrastruktur nicht ordentlich beendet dann bekommt man beim Aufruf des Universal Installers unter Oracle den Menüpunkt „Grid Installation Options“ nicht angezeigt. Hier kann ausgewählt werden, ob eine Single-Instance Installation, eine RAC-Installation oder eine RAC-Single Node Installation durchgeführt werden soll.
Fazit
Die Installation von Oracle RAC in dieser Umgebung gestaltete sich wirklich einfach und ist ausreichend für Testzwecke. Vielleicht wundern sich einige, dass ich nicht auf die Kernel-Paramter etc. eingegangen bin. Der Grund ist ganz einfach: seit Oracle 11g Release 2 hilft die Installation sich quasi selbst. Wenn Voraussetzungen nicht erfüllt sind, die sich mit einfachen Änderungen an Limits oder am Kernel (z.B. sysctl.conf) beheben lassen, wird je Rechner ein Skript „runfixup.sh“ im Verzeichnis /tmp/CVU__ erstellt. Dieses führt man einfach aus (natürlich als Root-User) und danach sind die Parameter richtig gesetzt.
Was die notwendigen Pakete angeht, ist immer noch Handarbeit angesagt, aber bis auf die bereits beschriebene asmlib befinden sich alle notwendigen Pakete auf der OEL6U1 CD.
Über ein Feedback zu diesem Block wäre ich sehr interessiert und gebe auch gerne weitere Informationen über meine Tests mit Oracle RAC weiter.