8 Minuten Lesezeit (1588 Worte)

Neuerungen in der Oracle Database 12.2 (Teil II): Real Application Clusters

Mittwoch, 15. August 2018

Im zweiten Artikel der Reihe stellen wir Ihnen die wesentlichen Neuerungen von Oracle 12.2 im Bereich Real Application Clusters vor. Wie auch in den vergangenen Releases hat Oracle die Architektur des Real Application Clusters weiterentwickelt und stellt ein neues Cluster-Konzept mit dem Namen „Oracle Cluster Domain" vor. Die Oracle Cluster Domain kann als eine Art private Datenbank-Cloud verstanden werden. In diesem Release wurden auch die Installation der Grid Infrastructure vereinfacht und viele weitere Neuerungen implementiert.

Oracle Cluster Domain

Die Oracle Cluster Domain kann einfach administriert und zentral verwaltet werden. In der Oracle Cluster Domain stellt der Oracle Domain Services Cluster (DSC) zentrale Services für die sogenannten Oracle Member Cluster bereit. Wurde die Basis, ein DSC zur Verfügung gestellt, können unterschiedliche Oracle Member Cluster erstellt werden. Alle Oracle Member Cluster verwenden die zentralen Services des DSC, z. B. den ASM Service. Weiterhin kann auch ein Standalone Cluster für die Installation und Konfiguration eines Real Application Clusters (RAC) ausgewählt werden. Diese Installationsart wird auch weiterhin den Standard für kleinere RAC-Umgebungen mit wenigen Cluster darstellen (siehe Abbildung 1).

Abb. 1: Oracle Cluster Domain

Domain Service Cluster (DSC) Komponenten

Ein Domain Service Cluster (DSC) ist das Herz der Oracle Cluster Domain und bildet die Voraussetzung für die Installation und Konfiguration von Oracle Member Cluster. Innerhalb der Oracle Cluster Domain ist das Grid Infrastructure Management Repository (GIMR) das zentrale Repository für die Speicherung von Diagnostic- und Health-Informationen für alle Member Cluster. Hier wird die Management Datenbank MGMTDB zentral vorgehalten. Auf die Informationen des GIMR greifen das Autonomous Health Framework (AHF), der Trace File Analyzer (TFA) und das Rapid Home Provisioning (RHP) zu.

Der IO-Service wird während der DSC-Installation konfiguriert. Der IO-Service stellt indirekt den Shared Storage für die Member Cluster über ein privates ASM Storage-Netzwerk bereit. Der wesentliche Vorteil ist, dass nun sehr einfach Oracle Member Cluster erstellt werden können, ohne ASM separat zu konfigurieren. Neuer Storage wird also im DSC konfiguriert und nicht auf dem Database Member Cluster.

Im DSC stellt Oracle optional einen Rapid Home Provisioning Server (RHP) bereit. Über diesen Server können die Oracle Datenbanken der Database Member Cluster und der Grid Infrastructure Software Stack gepatcht werden. Der RHP-Server standardisiert somit den Deployment–Prozess über die gesamte Oracle Cluster Domain.

Database Member Cluster

Ein Oracle Member Cluster kann für den Oracle Real Applikation Cluster (Oracle RAC) oder Oracle RAC One Node eingesetzt werden. Dieser Oracle Member Cluster registriert sich mit dem Management Repository Service und nutzt den zentralen TFA-Service. Database Member Cluster können mit lokalem ASM Storage oder mit dem Oracle ASM Storage Management Service des Domain Service Clusters konfiguriert werden. Ein Database Member Cluster muss immer das Grid Management Repository (GIMR) des Domain Service Cluster verwenden. In einem Database Member Cluster können nur Datenbanken > 12.1 erstellt werden.

Application Member Cluster

Innerhalb der Oracle Cluster Domain können normale Anwendungen hochverfügbar integriert werden. Ein Application Member Cluster benötigt eine Verbindung zu den Oracle Cluster Domain Services. Ebenfalls benötigt dieser Oracle Member keinen direkten Zugriff auf das Shared Storage, sondern greift remote auf das ASM-Storage über den IO-Service zu.

Oracle Flex Cluster

Bereits in Oracle 12cR1 führte Oracle eine weitere Variante für den Aufbau eines Clusters ein, das Flex Cluster. Im Oracle Flex Cluster werden zwei Typen von Knoten definiert. Zum einen die sogenannten Hub Nodes, Knoten mit Zugriff auf den Shared Storage, und zum anderen die sogenannten Leaf Nodes, ohne Zugriff auf den Shared Storage. Diese Variante eines Oracle Clusters als Plattform für flexible Cluster für verschiedene Applikationen neben den RAC-Datenbanken ist ab Oracle 12.2 die Standardkonfiguration, d. h. jedes Standalone Cluster wird als Flex Cluster mit Flex ASM (ebenfalls in Oracle 12cR1 eingeführt) angelegt (siehe hierzu Abbildung 2).

Abb. 2: Oracle Flex Cluster

Angedacht ist eine Verteilung der Anwendungen im Cluster, wobei Datenbanken auf den Hub Nodes laufen, andere Applikationen wie ApplicationServer auf den Leaf Nodes. Auf den Leaf Nodes stehen dann Mechanismen wie Ressourcenverwaltung, automatischer Start bzw. Restart von Ressourcen und Failover von Ressourcen auf andere Knoten zur Verfügung. Selbstverständlich können Standalone Cluster ganz klassisch nur bestehend aus Hub Nodes, d. h. für RAC- oder RAC-One-Node-Datenbanken, angelegt werden. Die Anzahl der Hub Nodes ist nun auf 64 Knoten beschränkt und theoretisch können beliebig viele Leaf Nodes an das Cluster gehängt werden.

Reader Nodes

In Oracle 12.2. ist es nun möglich, Read-Only-Workloads auf den Leaf Nodes in einer Flex-Cluster-Architektur laufen zu lassen, diese nennen sich Reader Nodes. Man kann maximal 64 Reader Nodes pro Hub Node erstellen. Auf den Reader Nodes kann ein lokales Temp-Tablespace erstellt werden und somit die Performance auf den ReaderNodes weiter erhöht werden. Außerdem können auf den Reader Nodes massiv parallele Abfragen ausgeführt werden. Voraussetzung für die Erstellung von Reader Nodes sind PolicyManagedDatenbanken, also keine „gepinnten" AdminManagedDatenbanken.

Grid Infrastructure Management Repository (GIMR)

In Oracle 12cR1 führte Oracle als zentrales Repository für die Daten des Cluster Health Monitors (ora.crf) eine neue Datenbank MGMTDB ein. Die Datenbank lag in der gleichen Lokation/Diskgruppe wie die Oracle Cluster Registry (OCR) und die Voting Disks. Die maximale Größe der Datenbank soll auf 2 GB beschränkt sein. In Oracle 12.2 kann nun eine separate Diskgruppe mit einer Kapazität von mindestens 37,6 GB in der Installationsart Standalone Cluster verwendet werden, alternativ zentral gespeichert im Domain Services Cluster für einen Database Member Cluster. Mit Oracle 12.2 wird deutlich mehr ASM-Kapazität für das Management Repository benötigt – dies muss bei der Planung neuer Cluster-Umgebungen berücksichtigt werden.

Installation und weitere Neuerungen

Die Installation der Grid Infrastructure wurde mit Oracle 12.2 vereinfacht und erfolgt nun als ImagebasedInstallation in drei Schritten:

• Download der ImageZipDateien

• Entpacken in das ORACLE_HOME auf dem ersten Knoten im Cluster

• Ausführen gridSetup.sh vom ersten Knoten

In der Funktionsweise der Grid Infrastructure wurden noch weitere Neuerungen implementiert. Unter dem Schlagwort Server Weight-based Node Eviction können nun über den neuen Parameter CSS_CRITICAL ein Knoten oder Ressourcen als kritisch eingestuft werden. Bei einem Heartbeat-Problem im RAC-Cluster können Knoten nicht mehr miteinander kommunizieren. Ein Knoten oder eine Knotengruppe muss gestoppt werden. Bei einem Split BrainProblem überlebt dann der Knoten oder die Knotengruppe mit der kritischen Ressource.

Automatic Storage Management (ASM)

Auch im Bereich Automatic Storage Management (ASM) gab es einige nennenswerte Änderungen. In früheren Versionen konnten in der Enterprise Edition die zentralen Cluster-Dateien Oracle Cluster Registry (OCR) und Voting Disk auf nicht-ASM-Storage gespeichert werden. Mit Oracle 12.2 müssen nun in allen Editionen die OCR und Voting Disk in einer ASM-Diskgruppe gespeichert werden.

FLEX Diskgruppe

Traditionell können ASM-Diskgruppen EXTERNAL (ungespiegelt), NORMAL (2-fach) oder HIGH (3-fach) redundant angelegt werden. In den Diskgruppen gibt es keine Unterscheidung pro Datenbank. Eine Diskgruppe definierte den Grad der Spiegelung und alle Dateien werden innerhalb der Diskgruppe gleich behandelt.

Mit Oracle 12.2 können Diskgruppen nun datenbankorientiert angelegt werden. Oracle hat einen neuen Diskgruppen-Typ FLEX Diskgroup eingeführt. Eine FLEX-Diskgruppe hat mindestens drei Fehlergruppen und kann auch aus einer NORMAL oder HIGH redundanten Diskgruppe in der RESTRICTED Mount-Phase konvertiert werden (siehe Abbildung 3).

Abb. 3: ASM Flex Diskgroup

In einer FLEX Diskgroup können nun pro Datenbank die Datenbankdateien verwaltet werden. In einer File Group können Dateien pro Datenbank gruppiert werden. Mit einer Quota Group kann der maximal belegbare Speicherplatz festgelegt werden. Dazu wird eine File Group in eine Quota Group verschoben. Das Vergeben von Quotas ermöglicht es, große konsolidierte Diskgruppen auf Datenbankebene zu verwalten.

Pro File Group ist auch eine individuelle Redundanz einstellbar: HIGH, MIRROR und UNPROTECED. Damit ist es möglich, „unwichtigeren" Datenbanken eine geringere Redundanz zu konfigurieren. In einer FLEX-Diskgruppe gibt nicht mehr die Diskgruppe, sondern die File Group die Redundanz vor. Dieser neue Aspekt ist in den Betriebskonzepten zu vermerken. Auf jeden Fall werden die Spalten REQUIRED_MIRROR_FREE_MB und USABLE_FILE_MB der View v$asm_diskgroup für FLEX-Diskgruppen nicht mehr aktualisiert. Auch dies muss in den Betriebskonzepten berücksichtigt werden. Historisch wurden Fehlergruppen zum Schutz vor Hardwarefehlern eingeführt. Mit einer FLEX-Diskgruppe kann die ASM-Redundanz auch für das schnelle Erstellen von Datenbank-Klonen verwendet werden. Dazu wird einfach eine redundante Kopie der File-Extents abgeteilt.

EXTENDED Diskgruppe

Mit Oracle 12.2 wird auch die ASM-Funktionalität für Extended RAC-Konfigurationen, d. h. über zwei Rechenzentren, erweitert. Bisher konnte eine Diskgruppe maximal zwei Fehlergruppen, jeweils eine pro Rechenzentrum, haben. Damit ergab sich ein guter Schutz gegen den Ausfall eines Rechenzentrums. Eine EXTENDED-Diskgruppe ist eine Erweiterung der FLEX Diskgruppe und erlaubt mehrere Fehlergruppen innerhalb einer Site (eines Rechenzentrums). Mit einer EXTENDED-Diskgruppe ist also eine Spiegelung innerhalb eines Rechenzentrums sowie über Rechenzentren hinweg möglich. Zusätzlich unterstützt eine EXTENDED-Diskgruppe nun ASM HIGH Redundanz, d. h. über drei Rechenzentren hinweg.

Fazit

Zusammenfassend kann gesagt werden, dass Oracle 12.2 einige interessante Erweiterungen im Bereich der Real Application Clusters hervorgebracht hat. Oracle hat ein komplett neues Cluster-Konzept mit dem Namen Oracle Cluster Domain vorgestellt. Sie kann als eine Art private Datenbank-Cloud verstanden werden und vereinfacht die Verwaltung großer Cluster-Umgebungen mit mehreren RAC-Umgebungen. Ein Oracle 12.2 RAC kann aber auch ganz klassisch als Standalone Cluster konfiguriert werden. Die in 12cR1 eingeführten Features Flex Cluster und Flex ASM sind nun die Standardkonfigurationen.

Auch im Bereich Automatic Storage Management gibt es Erweiterungen, die die Verwaltung großer Diskgruppen auf Datenbankebene ermöglichen sowie die Verfügbarkeit in Extended RAC-Konfigurationen erhöhen. Mit einer EXTENDED-Diskgruppe können nun auch Extended-RAC-Konfigurationen auf Exadata innerhalb der Limitierungen von InfiniBand implementiert werden.

Die in diesem Artikel vorgestellten Neuerungen der Grid Infrastructure behandeln nur die wesentlichen Aspekte der Oracle 12.2 Erweiterungen. Falls wir Ihr Interesse geweckt haben, dann empfehlen wir Ihnen die Seminare Oracle 12c Real Application Cluster (RAC) und Grid Infrastructure und Oracle ASM für Single Instance.