SI Datenbank im GI Cluster betreiben

Schützen von Oracle Single Instances Datenbanken in einer Oracle Grid Infrastructur mittels NetApp SnapCenter

Nachdem Oracle die Unterstützung von RAC für die Oracle Standard Edition mit der Version 19c gestrichen hat, bietet sich als Alternative an, eine Single Instance Datenbanken mittels Grid Infrastruktur-Funktionalität zu schützen. Fällt dann der Knoten mit der Single Instance Datenbank aus, wird diese auf einem anderen Knoten gestartet. Grundsätzlich ist der Ansatz auch für Applikationsdatenbanken interessant, bei denen der RAC Overhead zu groß ist und man daher lieber auf Single Instanz im Oracle Cluster setzt. Ebenfalls interessant ist diese Lösung auch aus Lizenzkostengründen, weil man dafür weder eine RAC- noch eine RAC-One Node Lizenz benötigt.

Wenn man eine solche Single Instance Datenbank jetzt mittels SnapCenter schützen (sichern) möchte, funktioniert das zwar problemlos, allerdings nur bis die Datenbank dann auf einmal auf einem anderen RAC Knoten läuft - SnapCenter kennt sich nicht mehr aus. Die vorhandenen Snapshots können zwar direkt auf der NetApp restored werden (nicht mit SnapCenter), nur neue Snapshot Backups sind nicht mehr möglich. Nun stellt sich die Frage: "Gibt es eine Lösung für das Problem?". Die Antwort ist erfreulicherweise: Ja, aber man muss einiges dafür machen. Dieser Artikel beschreibt die nötigen Schritte.

Architektur und Namensgebung für unser Beispiel

Für unser Beispiel nehmen wir an, dass wir eine Oracle 19c Grid Infrastruktur mit zwei Knoten mit den Nodenamen ol8gi19n1.example.com und ol8gi19n2.example.com und einem NFS Storage dbmdemodb01.example.com installiert haben. Grundsätzlich funktioniert diese Beschreibung 1:1 zumindest ab Oracle 12.1.

Auf diesen beiden Servern haben wir unter /u01/app/oracle/product/18.0.0/dbhome_SI_EE ein Single Instance Oracle Home mit einer Oracle 18c Datenbank Enterprise Edition installiert. Der Grund, warum wir keine Oracle 19c Datenbank genommen haben, ist, dass zum Zeitpunkt dieses Artikels Oracle 19c seitens NetApp SnapCenter noch nicht unterstützt wurde (und auch nicht funktioniert).

Die NFS Shares für die Datenbank SI18EE haben wir wie folgt angelegt:

volume create -vserver dbmdemodb01 -volume ol8gi19_SI18EE_data -aggregate aggr1_aff220a_naclu2 -size 64G -space-guarantee none -state online 
               -policy default -security-style unix -junction-path /ol8gi19_SI18EE_data -snapshot-policy none
volume create -vserver dbmdemodb01 -volume ol8gi19_SI18EE_olog -aggregate aggr1_aff220a_naclu2 -size 10G -space-guarantee none -state online 
               -policy default -security-style unix -junction-path /ol8gi19_SI18EE_olog -snapshot-policy none
volume create -vserver dbmdemodb01 -volume ol8gi19_SI18EE_arch -aggregate aggr1_aff220a_naclu2 -size 32G -space-guarantee none -state online 
               -policy default -security-style unix -junction-path /ol8gi19_SI18EE_arch -snapshot-policy none

Auf den beiden Knoten wurden die entsprechenden Verzeichnisse mittels des folgenden Befehls erzeugt:

mkdir -p /u01/app/oracle/oradata/SI18EE/{data,olog,arch}

Diese in die /etc/fstab eingetragen:

dbmdemodb01:/ol8gi19_SI18EE_data /u01/oradata/SI18EE/data nfs rw,bg,hard,nointr,rsize=32768,wsize=32768,tcp,vers=3,timeo=600,actimeo=0,noac 0 0
dbmdemodb01:/ol8gi19_SI18EE_olog /u01/oradata/SI18EE/olog nfs rw,bg,hard,nointr,rsize=32768,wsize=32768,tcp,vers=3,timeo=600,actimeo=0,noac 0 0
dbmdemodb01:/ol8gi19_SI18EE_arch /u01/oradata/SI18EE/arch nfs rw,bg,hard,nointr,rsize=32768,wsize=32768,tcp,vers=3,timeo=600,actimeo=0,noac 0 0

und letztendlich auf beiden Server gemounted:

mount -a
chown -R oracle:oinstall /u01/oradata/SI18EE

Wobei die zur Datenbank gehörenden Files wie folgt auf diese Verzeichnisse verteilt wurden:

data: Nur die Datenbank Files - keine TEMP Files!
olog: Online Logfiles, Control Files, Temp Files, SPFILE, ORAPW
arch: Archivelog Files

Selbstverständlich kann man auch zwei NFS Volums für olog nutzen und die Online Logfiles mit Oracle Mitteln spiegeln - für unseren Test war das aber nicht relevant.

Bitte sicherstellen, dass die Single Instance Datenbank SI18EE auf allen Rechnern in /etc/oratab eingetragen ist - das wird von SnapCenter benötigt.

Benötigte Cluster Ressourcen

Damit die Single Instance Database mittels Grid Infrastruktur geschützt werden kann, muss die entsprechende Cluster Ressourcen angelegt werden. Das ist schon seit Langem möglich mit benutzerdefinierten Ressourcen - wie wir es in diesem Beispiel zeigen, ab Oracle 19.7 Grid Infrastruktur gibt es aber auch direkte Unterstützung seitens Oracle mittels der Oracle Grid Infrastructure Standalone Agents for Oracle Clusterware 11g Rel. 2, 12c Rel. 1, 12c Rel. 2, 18c and 19c - aber das ist ein anderes Thema.

Für benutzerdefinierte Ressourcen benötigt man sogenannte Action Scripts - da diese stark von Ihrem System anhängen, haben wir hier bewusst kein Beispiel angeführt. Wenn Sie für die Action Scripts Unterstützung benötigen, helfen wir gerne.

Zuerst wird die Ressource für die Single Instance Datenbank als GRID Infrastruktur Owner (bei uns "oracle") angelegt:

/u01/app/grid/19.0.0/bin/crsctl add resource dbm_SI18EE_db -type cluster_resource -attr 
                  "ACTION_SCRIPT='/u01/app/grid/scripts/dbm_SI18EE_db.scr', PLACEMENT='restricted', 
                  HOSTING_MEMBERS='ol8gi19n1 ol8gi19n2', CHECK_INTERVAL='30', START_DEPENDENCIES='hard(ora.net1.network)', 
                  RESTART_ATTEMPTS='2', ACL='owner:oracle:rwx,pgrp:oinstall:rwx,other::r--'"

Theoretisch könnte man auch als erstes die Application VIP anlegen, nachdem diese aber erst nachträglich für SnapCenter benötigt wurde, haben wir sie erst danach angelegt. Den folgenden Befehl als Benutzer root ausführen:

/u01/app/grid/19.0.0/bin/appvipcfg create -network=1 -ip=10.46.2.85 -vipname=si18ee-vip -user=root
Using configuration parameter file: /u01/app/grid/19.0.0/crs/install/crsconfig_params
The log of current session can be found at:
/u01/app/oracle/crsdata/ol8gi19n1/scripts/appvipcfg.log

Im DNS muss diese VIP Adresse nun entsprechend eingetragen werden - beispielsweise:

si18ee-vip IN 1H A 10.46.2.85

Bitte den REVERSE LOOKUP Eintrag nicht vergessen!

Das Verknüpfen der Single Instance Datenbank Ressource mit der Application VIP muss ebenfalls als root erfolgen:

/u01/app/grid/19.0.0/bin/crsctl modify resource dbm_SI18EE_db -attr 
                   "ACTION_SCRIPT='/u01/app/grid/scripts/dbm_SI18EE_db.scr', PLACEMENT='restricted', 
                   HOSTING_MEMBERS='ol8gi19n1 ol8gi19n2', CHECK_INTERVAL='30', START_DEPENDENCIES=hard(si18ee-vip), 
                   STOP_DEPENDENCIES=hard(si18ee-vip), 
                   RESTART_ATTEMPTS='2',ACL='owner:oracle:rwx,pgrp:oinstall:rwx,other::r--'"

Grundsätzlich wäre die Konfiguration fertig, allerdings ist ein Verschieben der Ressourcen dann nur als root mit folgendem Befehl möglich:

/u01/app/grid/19.0.0/bin/crsctl relocate res dbm_SI18EE_db -f
	CRS-2673: Attempting to stop 'dbm_SI18EE_db' on 'ol8gi19n1'
	CRS-2677: Stop of 'dbm_SI18EE_db' on 'ol8gi19n1' succeeded
	CRS-2673: Attempting to stop 'si18ee-vip' on 'ol8gi19n1'
	CRS-2677: Stop of 'si18ee-vip' on 'ol8gi19n1' succeeded
	CRS-2672: Attempting to start 'si18ee-vip' on 'ol8gi19n2'
	CRS-2676: Start of 'si18ee-vip' on 'ol8gi19n2' succeeded
	CRS-2672: Attempting to start 'dbm_SI18EE_db' on 'ol8gi19n2'
	CRS-2676: Start of 'dbm_SI18EE_db' on 'ol8gi19n2' succeeded

Wir wollen aber auch als User oracle die Ressourcen verschieben können - ein Security Thema, nicht jeder DBA hat auch root Zugriff:

/u01/app/grid/19.0.0/bin/crsctl setperm resource si18ee-vip -g oinstall

Jetzt können die Ressourcen auch vom Betriebssystem-User oracle von einem Knoten auf den anderen verschoben werden.

Damit haben wir jetzt eine Oracle 18c Single Instance Datenbank mit eigener Application VIP in der Oracle 19c Grid Infrastruktur konfiguriert. Der nächste Schritt ist die Konfiguration von SnapCenter.

SnapCenter Konfiguration

Damit SnapCenter mit unserer SI18EE Datenbank korrekt arbeitet, sind mehrere Schritte nötig. Zuerst müssen die SnapCenter Agents für Linux und Oracle auf den beiden Grid Infrastruktur Knoten installieren und danach die Application VIP als "Alias" konfiguriert werden. Beginnen wir mit dem einfachen Teil: Installation der SnapCenter Agents.

Installation der SnapCenter Agents für Linux und Oracle

Dazu meldet man sich am SnapCenter mit einem entsprechend privilegierten Benutzer an und führt die folgenden Schritte aus:

Links im Menü auf HOSTS klicken.
Rechts oben im Menü auf ADD klicken.
Jetzt im Add Host Wizard als Host Type Linux auswählen, einen Hostnamen angeben und Credentials auswählen (oder anlegen) sowie bei den Plug-Ins die Oracle Datenbank auswählen.
Der Wizard braucht dann noch die Bestätigung der SSH Keys und erkennt dann, dass es sich um eine Grid Infrastruktur Installation handelt und beitet an auch gleich auf den anderen Host(s) zu installieren - bitte wählen Sie diese Option aus!

Nach einigen Minuten ist die Installation der Agents (scc und spl) auf beiden Hosts fertig. Klickt man jetzt auf Resources --> Oracle Database findet man die SI18EE auf beiden Knoten. Nur wissen wir ja, dass die Datenbank nur auf einen der beiden wirklich läuft. Würden wir jetzt auf diesem Knoten die Protection Policies definieren, würde alles solange perfekt funktionieren, bis die Datenbank Instanz auf den anderen Knoten verschoben wird und sich SnapCenter nicht mehr auskennt - sprich nichts funktioniert mehr...

Konfigurieren der Application VIP als Host ALIAS auf dem SnapCenter Server

Da die Oracle Single Instance Datenbank SI18EE ja immer dort läuft, wo auch die Application VIP si18ee-vip.example.com aktiv ist, müssen wir die Application VIP jetzt einfach als SnapCenter Host anlegen. Das geht am Besten in einer PowerShell am SnapCenter Windows Server. Starten Sie eine PowerShell und melden Sie sich am SnapCenter mit einem privilegierten Account an.

PS C:\Users\Administrator> Open-SmConnection
	
	cmdlet Open-SmConnection at command pipeline position 1
	Supply values for the following parameters:
	(Type !? for Help.)
	Credential

Dabei geht ein Fenster mit einem Login Dialog auf, in dem Sie den SnapCenter Benutzer und sein Passwort eingeben können./

Im nächste Schritt wird die Application IP als Host registriert - hier muss man auf die SnapCenter Version aufpassen, da gibt es verschiedene Syntax abhängig von der Version:

SnapCenter 4.1: PS> add-smhost -hostname "si18ee-vip.example.com" -OSType Linux -DiscoverPlugins -DoNotAddClusterNode -RunAsName root
SnapCenter 4.3: PS> add-smhost -hostname "si18ee-vip.example.com" -OSType Linux -DoNotAddClusterNode -RunAsName root

RunAsName ist der Name der Stored Credentials im SnapCenter, die genutzt werden sollen. Hier ein Beispieloutput für SnapCenter 4.3:

PS C:\Users\Administrator> add-smhost -hostname "si18ee-vip.example.com" -OSType Linux -DoNotAddClusterNode -RunAsName root
	WARNING: Security Alert ! It is recommended to configure Credential with non-root user accounts for Add-SmHost Operation. 
	Switch the existing SnapCenter plug-in Linux host from using the "root" Credential account to a non-root RunAs account and 
	delete the "root" Credential account from the SnapCenter Server.
	Do You want to continue with root user (yes/no)?: yes
	WARNING: Authenticity of the host si18ee-vip.example.com cannot be determined
	si18ee-vip.example.com ssh-rsa 3072 ED:38:18:0F:00:12:89:90:AE:D5:53:D7:0D:22:06:C5
	
	Do you trust the host (yes/no)?: yes
	
	OsInfo : SMCoreContracts.SmOperatingSystemInfo
	HostName : si18ee-vip.example.com
	IP : 10.46.2.85
	Description :
	HostId : 11
	DomainName : example.com
	Version :
	Port :
	ClusterHost : False
	ClusterName :
	Members : {}
	HostStatus : eHostUp
	HostPluginInfos : {, , }
	ColoHost : True
	HostConfiguration : SMCoreContracts.SmConfiguration
	DiscoverPlugin : False
	HostUUID :
	HostBIOSID :
	HostMaintenanceStatus : Production
	IsNLBEnabled : False
	VerificationServers :
	HypervisorType :
	IsHypervisorConfigured : False
	Preference : 0
	OverallStatus : SMCoreContracts.SmHostOverallStatusInfo
	IsCatalogHost : False
	Name :
	Type :
	Id :
	Host :
	UserName :
	Passphrase :
	Deleted : False
	Auth : SMCoreContracts.SmAuth
	IsClone : False
	CloneLevel : 0
	Hosts : {}
	StorageName :
	ResourceGroupNames :
	PolicyNames :
	Key : 0
	NsmObjectID : 0
	SizeOfSmObject :

Jetzt wechselt man zurück in die GUI und muss mit SnapCenter 4.3 den gerade angelegten Host noch refreshen. In älteren Versionen von Snapcenter - beispieleweise 4.1 - wurde dies durch die Option DiscoverPlugIn schon mit erledigt. Warum diese Option nicht mehr vorhanden ist, ist nicht ganz einsichtig.

Sobald durch das Refresh von si18ee-vip.example.com der Status auf "Running" steht, findet man die Datenbank SI18EE am Host si18ee-vip.example.com in den Oracle Datenbank Resourcen von SnapCenter.

Als letzten Schritt muss man jetzt die Protection Policy für die Datenbank SI18EE auf si18ee-vip.example.com konfigurieren und testen. Dazu sind folgende Schritte nötig:

Klicken Sie die Ziel mit der Datenbank auf dem "VIP" Hostnamen an
Sie sind jetzt im Add Protection Dialog. Wählen Sie die gewünschte Protection Policy und definieren Sie einen passenden Schedule und die weiteren Einstellungen wie Verification und Notification.
Testen Sie die Konfiguration durch das starten eines Backups mittels "Back up Now" rechts oben im Menü.

Wenn das Backup erfolgreich erzeugt wurde, sind Sie mit der Konfiguration fertig.

Hinweise, Bemerkungen und Einschränkungen

Hier haben wir noch einige Tipps für Sie gesammelt, die für den sicheren Betrieb dieser Konfiguration nötig sind.

Konfigurieren Sie niemals eine Policy für die Datenbanken direkt auf den Cluster Knoten

Nutzen Sie immer nur die Datenbank auf dem "VIP" Hostnamen, sonst laufen Sie in Probleme!

Datenbank Restore nur möglich, wenn man die Cluster Resourcen manuell vorbereitet.

Da SnapCenter im Fall eines Datenbank Restores die Datenbank Instanz stoppen muss, gibt es einen Konflikt mit der Grid Infrastruktur, die Ihrerseits die Datenbank Instanz sofort wieder starten wird. Die Lösung ist grundsätzlich einfach, man darf es nur noch vergessen:

Zuerst stoppen Sie die Grid Infrastruktur für die Datenbank Resource.

/u01/app/grid/19.0.0/bin/crsctl stop resource dbm_SI18EE_db -f

Bei Bedarf können Sie jetzt die Datenbank Instanz mittels SQLPLUS manuell starten, sollte dies für das Restore notwendig sein.
Jetzt im SnapCenter das Restore & Recovery der Datenbank durchführen.
Optional: Die Datenbank im SQLPLUS stoppen, sofern es ein Problem beim Starten der Grid Infrastruktur Resource gibt (siehe nächster Punkt).
Die Grid Infrastruktur Resource für die Datenbank wieder starten

/u01/app/grid/19.0.0/bin/crsctl start resource dbm_SI18EE_db -n ol8gi19n1

Probleme wenn VIP Resource nicht läuft

Für die Nutzung der Single Instance Datenbank selbst stellt es kein Problem dar, wenn die Application VIP aus irgend einem Grund nicht läuft, SnapCenter hat dann aber keine Möglichkeit mehr korrekt zu funktionieren. Es werden dann keine Snapshots mehr erzeugt, man kann nicht restoren, etc.

Sobald die VIP wieder aktiv ist, wird auch SnapCenter wieder problemlos funktionieren. Spannend ist es lediglich, wenn während eines SnapCenter Jobs die Datenbank inkl. VIP von einem Knoten auf den anderen Knoten verschoben wird. Im Fall eines Snapshot Backups wird dieses vermutlich ungültig sein (und sollte einfach wiederholt werden). Im Fall von Restore oder Clone muss man gegebenenfalls Fehler bereinigen und dann nochmals durchführen.

Breadcrumb