Über unsMediaKontaktImpressum
Rolf Abramowski 06. Oktober 2014

Oracle 12c RAC auf IBM Power8 Plattform

Mit New Power Systems built with POWER8 architecture and processor liefert IBM die neueste Generation ihrer Power Platform aus. Rolf Abramowski hat Oracle 12c Real Application Clusters (RAC) auf dem neuen Power8 getestet.

Ausgelegt für Big Data, Analytics und Cloud Computing, optimiert im Bereich CPU, Memory und I/O, zudem laut Hersteller sowohl horizontal als auch vertikal extrem skalierbar: Mit dem POWER8-Prozessor und der entsprechenden Architektur will IBM einen neuen Standard im Bereich Unix Server setzen. Dabei sollen auch Applikationen wie beispielsweise SAP von der neuen Leistungsbandbreite profitieren. 

Anwendungen können mit dem Power8-Prozessor durch SMT8 bis zu 8 Hardware Threads pro Prozessorkern nutzen. Hardwareunterstützung zur Optimierung von Java-Code wird ebenso geliefert wie eine effiziente Energieverwaltung, neue PCI Gen3 Devices und On-Chip/In-Core-Verschlüsselung. Das Coherent Accelerator Processor Interface (CAPI) Protokoll ermöglicht eine schnelle Bereitstellung von Informationen.

Der Power8-Prozessor ist der erste Prozessor, der Little-Endian und Big-Endian gleichwertig unterstützt. Little-Endian (LE) Betriebssysteme können als PowerKVM-Gast eingesetzt werden – mit der Einschränkung, dass alle PowerKVM-Gäste im selben Modus laufen müssen. Hier ist allerdings eine gleichzeitige Unterstützung von LB und BE ebenso geplant wie der Support für LE auf PowerVM. Damit wird es aber möglich, auf demselben physikalischen Server LE sowie BE Betriebssysteme in getrennten LPARs (Logical Partitions) zu fahren.

Wir testen eine Oracle 12c Grid Installation mit ASM auf zwei AIX LPAR’s unter einem IBM Power System S824. Auf beiden LPARs ist der neuste AIX Fixstand installiert: 7100-03-03-1415. Beide Cluster-Knoten laufen als uncapped Shared SMT8 mit einem Entitlement von 1.00 und 60 GB Memory.

Mit smtctl kann der aktuelle SMT Status angezeigt werden und ebenso dynamisch geändert werden (Ausschnitt):

Eine Änderung kann im laufenden Betrieb erfolgen, so dass entsprechende Performance Tests schnell durchgeführt werden können:

Die Installation der Oracle Grid Infrastructure und von Oracle Real Application Clusters (RAC) mit der Version 12c lässt sich ohne weitere Oracle Patches problemlos ausführen. Der Oracle Universal Installer prüft die Installationsvoraussetzungen und kann fehlende Einstellungen nachholen. So benötigt die Oracle Cluster-Installation eine SSH-Verbindung zwischen den einzelnen Clusterknoten. Der Oracle Installer unterstützt hier beispielsweise die Konfiguration.

Oracles Scripte verwenden im Hintergrund die Bash als auszuführende Shell. Diese ist standardmäßig unter AIX nicht installiert; die Korn Shell ist hier der Standard. Vor der Installation der Oracle-Software sollte man daher die Bash installieren. Alternativ muss man die erforderlichen Einstellungen manuell durchführen.

Oracle Database 12c bietet eine neue Option: Oracle Multitenant. Sie soll die Konsolidierung von Datenbanken vereinfachen, ohne dass Änderungen an bestehenden Anwendungen erforderlich sind. In dieser neuen Architektur können in einer Multi-Tenant-Containerdatenbank mehrere austauschbare Datenbanken, die Pluggable Databases (PDBs), gehostet werden. Schon bei der Installation der Datenbank oder auch später im Nachgang der Installation kann man diese PDBs erzeugen. 

Storage im Oracle Real Application Cluster

Oracle-Datenbanken bringen mit Automatic Storage Management (ASM) einen eigenen Volumemanager und ein Dateisystem für Datenbanken mit, das im Cluster von allen Knoten gemeinsam genutzt werden kann. Basis ist ein gemeinsamer Storage, beispielsweise im SAN, auf den alle Clusterknoten zugreifen können. ASM erlaubt Stripping und Mirroring. Es wurde für Datenbankzugriffe optimiert.

Unter AIX gibt es zwei interessante Möglichkeiten, die für ASM benötigte Disk eindeutig zu kennzeichnen und zu schützen. Zuerst muss beachtet werden, dass die Namen der shared Disk auf den beteiligten Knoten nicht identisch sein müssen. Plattennamen werden unter AIX lediglich im ODM (Object Data Manager) geschrieben und nicht hart codiert auf den Platten selbst.

Um die eindeutige Zuordnung der Platten zu gewährleisten, könnte man sich der PVID bedienen, die mit dem chdev-Kommando gesetzt werden kann und im Offset 80 der Platte geschrieben steht. lspv –u ist hier eine bessere Möglickeit, da eindeutige Merkmale wie UUID und WW Name angezeigt werden, die auf allen beteiligten Knoten identisch sind:

Mit rndev und lkdev stehen uns zwei weitere Kommandos zur Verfügung. Durch rndev können Geräte umbenannt werden. Aber Achtung: Das muss auf allen beteiligten Knoten durchgeführt werden. Interessanter ist aber lkdev: Hiermit kann die ASM Disk vor Veränderungen durch die Befehle chdev, chpath, rmdev und rmpath geschützt werden. Außerdem kann man einen Text zur Kennzeichnung mitgeben:

FlexASM

FlexASM ist eine neue Funktionalität im Oracle-Cluster, die jedoch nur für Oracle 12c-Datenbank-Instanzen nutzbar ist. Mit FlexASM ist keine lokale ASM-Instanz mehr erforderlich. Damit ist ASM auf dem lokalen Knoten auch kein “Single-Point-of-Failure” (SPOF) mehr. Gibt es eine lokale ASM-Instanz, nutzt die Oracle-Instanz diese, ansonsten verbindet sie sich mit einer ASM-Instanz auf einem anderen Knoten. Mit Oracle 12c führt ASM auch neue Cluster-Ressourcen ein: Das ASM-Netzwerk, den ASM-Listener und den ADVM-Proxy.

Bei der Installation der Grid Infrastructure wählen wir das mit Oracle 12c neu eingeführte Feature „Use Oracle Flex ASM for storage“ (Oracle Flex ASM). Es werden nun statt 63 bis zu 511 ASM Disk Groups unterstützt und die LUN Größe für Oracle Database 12c Clients kann bis zu 32PB betragen.

Nun können die entsprechenden Diskgroups erstellt werden (hier die Diskgroup für die Votingfiles):

Mit Oracle 12c muss nicht mehr - wie in früheren Oracle-Releases - jeder Cluster Node eine eigene gestartete ASM Instanz vorhalten. Weitere Konfigurationen sind nicht nötig, können aber auch später noch ausgeführt werden. So kann beispielsweise die Anzahl der verwendeten ASM-Instanzen konfiguriert werden. Fällt eine ASM Instanz aus, so startet Oracle Clusterware automatisch eine Instanz auf einem anderen Node. Die Datenbankinstanz verbindet sich dann auf eine andere ASM-Instanz auf einem weiteren Server. Die Default ASM cardinality ist 3. Sie kann über Befehle der Clusterware geändert werden.

Der Parameter "ASM instance count" ist auch nach der Installation der Grid Infrastruktur mit ASMCA, ASMCMD oder SQLPLUS modifizierbar. Der graphische Assistent startet mit dem Kommando asmca (siehe Abb. 12). Auf Kommandozeile kann man beispielsweise mit dem Befehl srvctl modify asm -count 4 den Wert ändern.
Die Option "Redundancy" erlaubt die Konfiguration der Datenspiegelung.
  • Normal: 2-Wege-Spiegel in ASM
  • High: 3-Weg-Spiegel in ASM
  • External: Keine Spiegelung mit ASM
Durch Bestätigung wird die ASM Diskgroup erstellt. Abbildung 15 zeigt das Ergebnis.
Bei der Installation der Datenbank wird wieder Oracle ASM ausgewählt, um die Oracle Datenbankfiles dort zu speichern:
In unserem 2 Node Cluster zeigt sich diese Konfiguration wie folgt:
Mit folgenden Kommandos sehen wir, auf welcher Instanz ASM ausgeführt wird:
Auf beiden Nodes läuft die Datenbank Instanz:
Hier die Sicht des Oracle Users:

JFS2 Storage

Natürlich lässt sich im Oracle 12c RAC Cluster auch der AIX eigene Logical Volume Manager mit seiner Flexibilität nutzen. In diesem Fall werden die AIX-eigenen Volumegroups, Logical Volumes und das jfs2 Filesystem als Speicherort genutzt. Zu empfehlen ist der Einsatz von Scalable Volume Groups die pro VG bis zu 1024 Disk enthalten können. Auch hier lässt sich der genutzte Speicherbereich als Raid 0, 1 oder 10 mit optional bis zu 3 Kopien zur Verfügung stellen. Raid 5 kann man mit einem entsprechenden Hardwarecontroller realisieren. Die Filesysteme lassen sich dynamisch vergrößern und bei Bedarf auch wieder verkleinern. Damit ist eine hohe Flexibilität und Skalierbarkeit gewährleistet. Hier bedarf es root-Berechtigungen, um Änderungen vorzunehmen. Alternativ kann dem Oracle-Administrator über RBAC (Role Based Access Control) die Möglichkeit gegeben werden, die entsprechenden Filesysteme auch ohne root-Berechtigungen zu administrieren.

Netzwerkadressierung im Oracle12c RAC

Das mit Oracle Real Application Clusters (RAC) 11g Release 2 eingeführte Oracle Single Client Access Name (SCAN) Feature erfährt in Oracle RAC 12c einige Erweiterungen. SCAN ermöglicht Clients durch einen einzelnen Namen auf den Oracle Cluster zuzugreifen. Damit ergibt sich die Möglichkeit, innerhalb des Clusters Knoten hinzuzufügen oder zu entfernen, ohne in den Verbindungskonfigurationen der Clients Änderungen vornehmen zu müssen. Clients können mit Hilfe von EZConnect oder einer einfachen JDBC thin URL auf jede Datenbank im Cluster zugreifen, unabhängig davon, auf welchem Server die Datenbank aktiv ist. Dabei bietet die Installation von Oracle Grid zwei Möglichkeiten: SCAN kann innerhalb der unternehmenseigenen DNS Infrastruktur benutzt werden oder mit Hilfe von Oracle Grid Naming Services (GNS). Im ersten Fall werden über DNS dem eindeutigen Namen 3 IP-Adressen zugeordnet, die im round-robin Verfahren an die Clients weitergegeben werden und so eine Lastverteilung ermöglichen. Clients ab der Version Oracle 11g Release 2 können diesen Mechanismus auch im Failover-Fall ohne spezielle Konfiguration nutzen. Wird Oracle Grid Naming Service (GNS) benutzt, werden für den Cluster Service 3 IP-Adressen vom DHCP-Server bezogen oder über „Stateless Address AutoConfiguration“ (SLAAC) im Falle von IPv6 um die benötigten Adressen für SCAN im öffentlichen Netz zur Verfügung zu stellen. Mit Oracle Grid Infrastructure 12c Release 1 werden folgende Erweiterungen zur Verfügung gestellt:
  1. SCAN und Oracle Clusterware managed VIPs unterstützen IPv6 Adressen
  2. SCAN registriert standardmäßig nur noch Services, die von Cluster Knoten kommen
  3. SCAN bietet Unterstützung für verschiedene Subnets im Cluster (ein SCAN per Subnet)
Dabei kann während der Installation nur ein IP-Netz erstellt werden, weitere müssen nach der Installation konfiguriert werden. Dazu sind folgende Schritte nötig:
  1. Erstellen zusätzlicher Subnetze als public network.
  2. Erstellen der Knoten-VIPs in den Subnetzen.
  3. Es werden die Knoten-Listener erstellt
  4. Es wird ein SCAN mit den obigen Optionen erstellt
Mithilfe der Kommandos oifcfg und srvctl lassen sich diese Tasks auf der CLI ausführen.
Die Unterstützung mehrerer Subnets im Cluster und ebenso der IPv6-Support zusammen mit einem sicheren Weg der Registrierung für die im Cluster angebotenen Services bieten eine flexible Lösung zur Unterstüzung moderner DBAs oder privater Database Cloud-Szenarien.

Netzwerkoptionen

Oracle gibt Vorgaben für die Netzwerkoptionen unter AIX und empfiehlt, dass die entsprechenden Parameter über das no-Kommando zu setzen sind. Dabei ist zu beachten, dass einige dieser Optionen als sogenannte use_isno-Optionen gesetzt sind, was nichts anderes besagt, als dass hier die Einstellungen des Interfaces selbst zählen und nicht die Einstellungen in den no-Optionen!
Ein Ausschalten von use_isno wird nur zu Debug-Zwecken unterstützt. Die Werte für tcp_recvspace und tcp_sendspace werden am Interface selber gesetzt und überschreiben die no-Werte.
Diese Werte sind temporär mit ifconfig zu ändern, bootresistent mit dem chdev-Kommando. Die Default-Werte übertreffen in der Regel aber schon die von Oracle geforderten Minimal-Werte:

CRSCTL

Das Oracle Clusterware Control Utility (CRSCTL) ist das Interface zur Kommunikation mit den Oracle Clusterware-Objekten. Mit Hilfe von CRSCTL können verschiedene Operationen auf der Oracle Clusterware ausgeführt werden:
  • Starten und Stoppen der Oracle Clusterware Ressourcen
  • Starten und Stoppen der Oracle Clusterware Daemons
  • Health Check auf dem Cluster
  • Ressourcen, die third-party-Applikationen repräsentieren, steuern
  • Integrating Intelligent Platform Management Interface (IPMI)
  • Debuggen von Oracle Clusterware Komponeneten
Das Utility befindet sich in $ORACLE_HOME/bin der Grid Installation. Hier einige Beispiele:
Check der aktiven Version:
Health Check des Clusters:
Stoppen der Oracle Clusterware auf einem Node (Screenshot zeigt nur einen Ausschnitt):
Starten der Oracle Clusterware:
Cluster Status anzeigen:
Die Möglichkeit, Filter zu benutzen, erleichtert die Arbeit. Unterstützte Filter-Operatoren sind: =
>
<
!=
co: Contains
st: Starts with
en: Ends with Ein Beispiel:
Mit der Option eval kann die Ausführung eines Kommandos simuliert werden ohne Änderungen vorzunehmen:
Beispiele zur Konfigurations-Änderung:
Das Handling der Votingfiles kann auch über CRSCTL erfolgen:
Mit crsctl {replace|delete|add} lässt sich der Speicherort der Votingfiles manipulieren. In dem Falle ist aber ein Stop und Start der Clusterware nötig.
Zur Zeit verfügbar sind die Systeme Power S812L und Power S822L (PowerLinux Systems®). Als Betriebssysteme stehen Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise Server (SLES) oder Ubuntu Server zur Verfügung. PowerVM® und PowerKVM™ können als Virtualisierungslösung genutzt werden. Für die Systeme Power S822, S814 und S824 sind neben Linux on Power noch AIX und IBM i als Betriebssysteme eine weitere Option. Power VM Virtualisierung mit SR-IOV erlaubt erweiterte I/O-Virtualisierungsoptionen auf den neuen Systemen.

Fazit

Die neue Power8-Generation bietet für Oracle-Datenbanken eine hochperformante, leistungsstarke und flexible Architektur. Mit Cluster Aware AIX (CAA) steht neben Linux für Power ein ebenso leistungsstarkes wie einfach zu administrierendes Betriebssystem zur Verfügung, das alle Vorteile der Power-Architektur zu nutzen weiß. Die Verbindung von hochskalierbarer Hardware, Virtualisierungslösungen und Betriebssystem mit der neuesten Datenbank-Version Oracle 12c weist den Weg in die Zukunft.

Autor

Rolf Abramowski

Rolf Abramowski beschäftigt sich bei der Firma sysd@ne vor allem mit PoC´s (Proof of Concepts) u.a. mit dem Deployment Oracle® 12cR1 inkl. RAC auf der IBM® Power8 S824 (8286-42A) Plattform und ist verantwortlich für Stresstests…
>> Weiterlesen
Kommentare (0)

Neuen Kommentar schreiben