ASM Cluster Filesystem - General Purpose vs. Oracle Home File System

DBA Community - Mai 2013

von Sebastian Solbach ORACLE Deutschland B.V. & Co.KG

Mit Oracle 11.2 führte Oracle ein allgemeines Cluster Filesystem auf Basis von ASM ein - das ASM Cluster Filesystem kurz ACFS. Es steht als Standard Posix konformes Filesystem für jegliche Applikation zur Verfügung, und ist deshalbt nicht nur im Zusammenhang mit Real Application Clusters interessant. Da geplant ist, das "reine ACFS" ohne Zusatzfunktionen, wie Read/Write Snapshots, erweiterte Sicherheit und Filesystemverschlüsselung, kostenfrei zur Verfügung zu stellen, ist ACFS eine eine echte Alternative zu anderen teuren Clusterfilesystemen - auch wenn keine Oracle Datenbank auf dem System installiert ist. In der Lizenzierung wird dieses Filesystem auch als "Oracle Cloud Filesystem" ausgewiesen. Dahinter verbirgt sich technisch das ACFS, lizenzrechtlich beinhaltet das Cloud Filesystem aber alle notwendigen Bestandteile, um mit ACFS zu arbeiten: Die Grid Infrastruktur, das Automatic Storage Management sowie die ASM dynamic Volumes (ADVM).

Legt man zum ersten Mal ein ACFS Filesystem über den ASM Configuration Assistant (kurz ASMCA) an, so wird wird man gefragt, ob das Filesystem für ein Oracle Home verwendet wird oder ein "General Purpose File System" ist. Was aber ist da genau der Unterschied und für welche Anwendungsfälle eignet sich das "Database Home Filesystem"?

Anlegen des ACFS Filesystems

Das Anlegen des ACFS über die GUI des ASMCA bietet viele Vorteile. So kann der ASMCA das benötigte dynamische Volume in ASM, welches für das ACFS verwendet wird, gleich mit anlegen. Natürlich funktioniert das Anlegen des Volumes auch über die ASM Command Line (auch asmcmd) bzw. SQL*Plus und das darauffolgende Anlegen des ACFS dann über die Standard Betriebssystem Kommandos zum Erstellen eines Filesystems (zum Beispiel der Linux Befehl mkfs). Allerdings wird man bei der manuellen Methode nicht gleich auf die unterschiedlichen Verwendungszwecke des ACFS hingewiesen und die damit zusammenhängende andere Vorgehensweise beim Anlegen des ACFS. Der ASMCA zeigt optional die notwendigen Befehle dazu an, so dass man sehen kann, welche Unterschiede sich je nach Verwendungszweck ergeben.

Anlegen eines "General Purpose File Systems"

Create ACFS Command:
/sbin/mkfs -t acfs /dev/asm/acfs2-64

Register Mount Point Command:
/sbin/acfsutil registry -a -f /dev/asm/acfs2-64 /mnt/acfs2

Das Anlegen eines "General Purpose File System" besteht aus dem Formatieren des Volumes mit ACFS Informationen und der anschließenden Registrierung des ACFS in der ACFS Registry. Die ACFS Registry kann man zum Beispiel mit der betriebssystemeigenen Konfiguration in der Datei /etc/fstab verglichen werden, da in der Registry festgehalten wird, welches Filesystem automatisch mit welchen Optionen auf den jeweiligen Knoten des Clusters gemountet wird. Die Verwendung der betriebssystemeigenen Registry (fstab) hierfür ist nicht möglich, da diese Informationen abgearbeitet werden, lange bevor die Clusterware gestartet ist. Ein Mount über die fstab beim Betriebssystemstart würde deswegen fehlschlagen. Außerdem funktioniert die fstab nicht clusterübergreifend, was die ACFS eigene Registry in der Oracle Clusterware eben erlaubt.

Ein Mounten des Filesystems nur auf bestimmten Knoten bzw. mit unterschiedlichen Mountpoints ist ebenfalls möglich, wenn man diese Informationen dem Registry Command mitgibt.

# acfsutil registry -a -f -n node1 /dev/asm/acfs1-64 /mnt/acfs1

Der Befehl mountet das Filesystem dann automatisch nur auf dem Knoten "node1".

Anmerkung: Die ACFS Registry ist zwar auch bei einer Oracle Restart Umgebung vorhanden, allerdings unterstützt Oracle Restart nicht das automatische Mounten der ACFS Filesysteme. Die MOS Note 886407.1: "ACFS/ADVM is NOT started automatically after node reboot or after CRS is restarted in non-RAC environment" bietet aber einen passablen Workaround an.

Anlegen eines "Database Home File Systems"

Create ACFS Command:
/sbin/mkfs -t acfs /dev/asm/acfs1-64

Following commands should be run as privileged user :
/opt/11.2.0.2/grid/bin/srvctl add filesystem -d /dev/asm/acfs1-64 -g FRA -v ACFS1 -m /mnt/acfs1 -u oracle
/opt/11.2.0.2/grid/bin/srvctl start filesystem -d /dev/asm/acfs1-64
chown oracle:oinstall /mnt/acfs1
chmod 775 /mnt/acfs1

Die Formatierung des "Database Home File Systems" unterscheidet sich nicht von der eines "General Purpose File System". Der Unterschied liegt in der Verwaltung des Filesystems. Denn das "Database Home File System" wird in der Clusterware als eigene "Filesystem Resource" registriert, und der Status kann über die Clusterware eigenen Verwaltungswerkzeugen (crsctl bzw. srvctl) abgefragt und gemountet (srvctl) werden.

Normalerweise darf ein Filesystem nur von einem Benutzer mit "root" Rechten gemountet werden. Damit dies aber in Zukunft auch der normale "Home" Benutzer ausführen darf, wird der Filesystemressource über das Flag -u die ausführenden Benutzer mitgegeben, wie in diesem Falle der Benutzer "oracle". Damit kann "oracle" nun das Filesystem über den Befehl srvctl start filesystem bzw. srvctl stop filesystem mounten bzw. unmounten. Hiermit ist es auch möglich ein Filesystem nur auf bestimmten Knoten zu mounten, da die Clusterware sich den Status merkt. Somit wird das Filesystem immer nur dort gemountet, wo es als letztes auch aktiv war. Dies ist notwendig, da das Filesystem nicht in der ACFS Registry auftaucht, wo die Informationen für ein "General Purpose Filesystem" stehen.

Anmerkung: Ein Filesystem, welches in der Clusterware registriert wurde, darf nicht zusätzlich in der ACFS Registry erscheinen.

Verwendungszwecke

Diese unterschiedliche Art der Verwaltung/Registrierung gibt auch die verschiedenen Verwendungszwecke vor. Wenn innerhalb der Clusterware die Notwendigkeit besteht, eine Abhängigkeit zwischen dem Filesystem und einer anderen Clusterwareressource zu definieren, so muss für das Filesystem ebenfalls eine Clusterwareressource vorhanden sein. Am leichtesten versteht man dies mit Hilfe der Datenbank. Hat man zum Beispiel das Wallet für eine Funktion der Datenbank (Transparent Data Encryption oder Netzwerkverschlüsselung) auf ACFS abgelegt, so kann die Datenbank erst gestartet werden, wenn das Filesystem gemountet ist. Zu diesem Zweck bietet der Befehl srvctl modify database die Möglichkeit, diese Abhängigkeit zu definieren.

$ srvctl modify database -h
Modifies the configuration for the database.

Usage: srvctl modify database -d  ...
...
    -j ""    Comma separated list of ACFS paths where database's dependency will be set
...

$ srvctl modify database -d buvmrac -j "/mnt/acfs1"

$ crsctl stat res ora.buvmrac.db -p |grep acfs1
START_DEPENDENCIES=hard(ora.INFRA.dg,ora.FRA.dg,ora.fra.acfs1.acfs) 
  weak(type:ora.listener.type,global:type:ora.scan_listener.type,uniform:ora.ons,global:ora.gns) 
  pullup(ora.INFRA.dg,ora.FRA.dg)
STOP_DEPENDENCIES=hard(intermediate:ora.asm,shutdown:ora.INFRA.dg,shutdown:ora.FRA.dg,shutdown:ora.fra.acfs1.acfs)

Der srvctl Befehl trägt dazu in die START_DEPENDENCIES und STOP_DEPENDENCIES die Abhängigkeit zum ACFS ein, so dass die Datenbank nur dann startet, wenn das Filesystem gemountet wurde. Diese Abhängigkeiten können natürlich über den Befehl crsctl für eigene Clusterressourcen (nicht ora.* Ressourcen) eingetragen werden, wenn diese auf das ACFS angewiesen sind. Bei einem "General Purpose File System" gibt es keine automatische Möglichkeit, diese Abhängigkeiten zu hinterlegen.

Weitere Unterschiede und Gemeinsamkeiten

Die unterschiedliche Art der Filesysteme ist im ACFS selber nicht erkennbar. So ist die Ausgabe von acfsutil info fs für beide Filesysteme gleich.

# acfsutil info fs
/mnt/acfs2
    ACFS Version: 11.2.0.2.0
    flags:        MountPoint,Available
    mount time:   Thu May 16 15:32:26 2013
    volumes:      1
    total size:   536870912
    total free:   423358464
    primary volume: /dev/asm/acfs2-64
        label:
        flags:                 Primary,Available,ADVM
        on-disk version:       39.0
        allocation unit:       4096
        major, minor:          252, 32770
        size:                  536870912
        free:                  423358464
        ADVM diskgroup         FRA
        ADVM resize increment: 268435456
        ADVM redundancy:       mirror
        ADVM stripe columns:   4
        ADVM stripe width:     131072
    number of snapshots:  0
    snapshot space usage: 0

/mnt/acfs1
    ACFS Version: 11.2.0.2.0
    flags:        MountPoint,Available
    mount time:   Thu May 16 15:53:25 2013
    volumes:      1
    total size:   536870912
    total free:   419172352
    primary volume: /dev/asm/acfs1-64
        label:
        flags:                 Primary,Available,ADVM
        on-disk version:       39.0
        allocation unit:       4096
        major, minor:          252, 32769
        size:                  536870912
        free:                  419172352
        ADVM diskgroup         FRA
        ADVM resize increment: 268435456
        ADVM redundancy:       mirror
        ADVM stripe columns:   4
        ADVM stripe width:     131072
    number of snapshots:  0
    snapshot space usage: 0

Möchte man nachträglich wissen, wie das Filesystem angelegt wurde, so ist dies über die ACFS Registry bzw. den Befehl crsctl möglich.

# acfsutil registry -l
Device : /dev/asm/acfs2-64 : Mount Point : /mnt/acfs2 : Options : none : 
Nodes : all : Disk Group : FRA : Volume : ACFS2

# crsctl stat res -w "TYPE = ora.acfs.type" -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.fra.acfs1.acfs
               ONLINE  ONLINE       bumucsvm1
               ONLINE  ONLINE       bumucsvm2
               ONLINE  ONLINE       bumucsvm3

Wechsel zwischen den Varianten

Hat man versehentlich die falsche Option im ASMCA gewählt, kann die Art der Registrierung durch ein paar einfache Kommandos gewechselt werden. Es ist also nicht notwendig das Filesystem zu löschen oder neu anzulegen! Hier die Variante von "General Purpose" nach "Oracle Home":

# acfsutil registry -d /mnt/acfs2
acfsutil registry: successfully removed ACFS mount point /mnt/acfs2 from Oracle Registry

# srvctl add filesystem -d /dev/asm/acfs2-64 -g FRA -v ACFS2 -m /mnt/acfs2 -u oracle
# srvctl start filesystem -d /dev/asm/acfs2-64

Zwischen den Schritten ist bei dieser Umwandlung kein Unmount notwendig. Der Start wird lediglich zum Anzeigen des richtigen Status in der Clusterware benötigt.

Damit der Unmount auch bei der Änderung zur General Purpose Variante nicht notwendig ist, wird mit der Option Force (-f) beim Befehl srvctl verwendet:

# srvctl remove filesystem -d /dev/asm/acfs2-64 -f

# acfsutil registry -a -f /dev/asm/acfs2-64 /mnt/acfs2
acfsutil registry: mount point /mnt/acfs2 successfully added to Oracle Registry

Fazit

Der Unterschied zwischen "General Purpose File System" und "Oracle Home File System" liegt also in der Art der Registrierung und ob Cluster Abhängigkeiten auf das Filesystem benötigt werden oder nicht, wie eben für eine Datenbank, die erst starten darf, wenn das ACFS Filesystem gemountet ist. Ob das Filesystem für Oracle Software bzw. ein Oracle Home verwendet wird, ist eher zweitrangig.

Nützliche Links und Referenzen

Oracle Automatic Storage Management Administrator's Guide 11g Release 2 (11.2) - 5 Introduction to Oracle ACFS

Oracle Automatic Storage Management Administrator's Guide 11g Release 2 (11.2) - acfsutil registry

Oracle ACFS and Oracle Restart

ACFS/ADVM is NOT started automatically after node reboot or after CRS is restarted in non-RAC environment [ID 886407.1]

Zurück zur Community-Seite