Plattenplatzbedarf in ASM und ACFS

von Sebastian Solbach

Der präferierte Storage für eine Oracle Datenbank ist das Automatic Storage Management (ASM) oder aber seit Oracle 12c auch das ASM Cluster Filesystem (ACFS) innerhalb von ASM. Optimale Performance, Clusterfähigkeit, Storage Konsolidierung, automatisches Striping und Mirroring sind nur einige der Eigenschaften, weshalb ASM bzw. ACFS häufig verwendet wird.

Beim Umgang mit ASM ist es - wie bei jedem anderen Dateisystem auch - wichtig zu wissen, wie viel Speicherplatz noch zur Verfügung steht. Bei einem ASM Einsatz gibt es hier schon das erste Verständnisproblem, da ASM zwischen freiem Speicherplatz, verwendbarem Speicherplatz und verfügbarem Speicherplatz unterscheidet. Wird ACFS mit der Möglichkeit seiner Copy on Write Snapshot Technology verwendet, erhält die Ermittlung des zur Verfügung stehenden Platzes nochmals einen weiteren Komplexitätsgrad.

So ist es nicht verwunderlich, dass der freie Speicherplatz in ASM häfig mit dem verfügbaren Platz in ACFS verwechselt wird.

Grundlegende ASM Funktionalitäten

Bei ASM bis zur Version 12.1 gibt es das Konstrukt von Diskgruppen. Eine Diskgruppe fasst dabei mehrere Platten oder LUNs zu einer Einheit zusammen. Mit 12.1 müssen alle Platten einer Diskgruppe dieselbe Größe besitzen und sollten dieselben Performanceeigenschaften haben. Bei der Erstellung der Diskgruppe wird auch die Spiegelung innerhalb der Diskgruppe mit angegeben. Diese reicht von EXTERNAL Redundancy (keine Spiegelung) über NORMAL Redundancy (einfache Spiegelung) bis zur HIGH Redundancy (jeder Extent wird 3x geschrieben).

Wenn gespiegelt wird, dann werden einzelne Platten/LUNs einer Diskgruppe in sogenannte "Failure Groups" aufgeteilt. Diese Failure Groups (kurz FG) geben dabei an, dass ein Extent (Speichergröße in ASM) einer FG immer auch in eine (normale Redundanz) bzw. zwei (hohe Redundanz) andere Failure Groups gespiegelt wird. Werden bei der Erstellung von ASM Diskgruppen die Failure Groups nicht explizit benannt, so erzeugt ASM für jede Platte eine eigenen Failure Group. Dies hat den Vorteil, dass der Plattenplatz optimal ausgenutzt wird, da die Daten einer Festplatte bei Ausfall leichter auf andere verteilt werden kann.

Hier ein Vergleich zwischen einer Diskgruppe mit normaler Redundanz mit 8 Platten a 8 Failure Groups und einer Diskgruppe mit 8 Platten in 2 Failure Groups:

ASMCMD> lsdg
State    Type    Rebal  Sector  Block       AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name
MOUNTED  NORMAL  N         512   4096  1048576      8192     7889             1024            3432              0             N  ASMNORM/
MOUNTED  NORMAL  N         512   4096  1048576      8192     7982             1024            3479              0             N  ASMNORM2FG/

Während die Diskgruppe mit nur 2 FGs (ASMNORM2FG) bei einer leeren Diskgruppe und intakten Platten noch einen kleinen Vorteil in Bezug auf Free und Usable_file_MB hat (was an der Verteilung von Metadaten liegt), so ist dies nach Ausfall von 2 Platten nicht mehr der Fall: Ein Tablespace der Größe 2 GB lässt sich dann im 2. Fall nicht mehr anlegen und folgende Fehlermeldung wird ausgegeben

ORA-15032: not all alterations performed
ORA-15041: diskgroup "ASMNORM2FG" space exhausted (DBD ERROR: OCIStmtExecute)

Leider ist dies anhand der Größeninformationen der Diskgruppe nicht direkt erkennbar, da die unterschiedliche Anzahl von Platten in Failure Groups nicht berücksichtigt wird:

ASMCMD> lsdg
State    Type    Rebal  Sector  Block       AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name

MOUNTED  NORMAL  N         512   4096  1048576      6144     5841             1024            2408              0             N  ASMNORM/
MOUNTED  NORMAL  N         512   4096  1048576      6144     5924             1024            2450              0             N  ASMNORM2FG/

Ein Grund mehr nicht nur gleich große sondern auch die gleiche Anzahl Platten pro Failure Group zu verwenden.

Wie ermittelt ASM nun aber die oben gelisteten Werte insbesondere den Wert für Usable_file_MB?

Speicherplatz verstehen bei ASM Diskgruppen

Bei der Berechnung des freien Speicherplatzes innerhalb ASM sind folgende Werte ausschlaggebend:

Total_MB: Der reine "RAW" Speicherplatz ohne Einberechnung von Redundanz
Free_MB: Der freie "RAW" Speicherplatz. Ebenfalls ohne Einberechnung der Redundanz
Req_mir_free_MB: Required Mirror free MB gibt das sogenannt Worst Case Szenario an, welches im Fehlerfall mit abgedeckt sein sollte. Diese Worst Case Szenarien werden nacher genauer beleuchtet, da diese sich je nach Redundanz und Anzahl Failure Groups unterscheiden.
Usable_file_MB: Der zur Verfügung stehende Plattenplatz abzüglich Worst Case geteilt durch die Spiegelung

Einfacher erkennt man die Unterschiede an konkreten Beispielen unterschiedlicher Diskgruppen in Oracle 12c. Jede Diskgruppe besteht dabei aus 8 Platten mit jeweils 1024MB Größe. In unserem Beispiel sind auf Grund der Übersichtlichkeit keine Daten enthalten.

ASMCMD> lsdg
State    Type    Rebal  Sector  Block       AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name
MOUNTED  EXTERN  N         512   4096  1048576      8192     8075                0            8075              0             N  ASMEXT/
MOUNTED  NORMAL  N         512   4096  1048576      8192     7966             1024            3471              0             N  ASMNORM2FG/
MOUNTED  NORMAL  N         512   4096  1048576      8192     7889             3072            2408              0             N  ASMNORM3FG/
MOUNTED  HIGH    N         512   4096  1048576      8192     7889             2048            1947              0             N  ASMHIGH3FG/
MOUNTED  HIGH    N         512   4096  1048576      8192     7889             3072            1605              0             N  ASMHIGH4FG/
MOUNTED  HIGH    N         512   4096  1048576      8192     7889             4096            1264              0             N  ASMHIGH5FG/

Wie oben schon erwähnt und nun deutlich sichtbar, hängt der verfügbare Plattenplatz (Usable_file_MB) stark von der Berechnung des sogenannten Worst Case ab. Was bedeutet aber nun dieser Worst Case? Das ist letztendlich das Ereignis, nachdem ASM seine Redundanz theoretisch wieder aufbauen kann.

Im Falle der Diskgruppe ASMEXT mit externer Redundanz gibt es demnach keinen Worst Case: Fällt hier eine Platte aus, ist die Diskgruppe nicht mehr benutzbar. ASM kann selbständig die Diskgruppe nicht wiederherstellen. Dafür hat man beinahe allen RAW Speicherplatz zur Verfügung - einzig ein paar Metadaten in der Diskgruppe verringern den verfügbaren Platz.

Bei den Diskgruppen ASMNORM2FG mit normaler Redundanz und 2 Failure Groups hingegen ist der Worst Case der Ausfall einer Platte, unabhängig davon wie viele Platten in einer Failure Group sich befinden. ASM berechnet diesen Wert so, dass ASM immer die einfache Spiegelung garantieren kann, auch nachdem bereits eine Platte ausgefallen ist. Interessant ist hierbei, dass bei mehreren Platten innerhalb einer FG dieser Wert immer "neu" berechnet wird. Im Ergebnis ändert sich der Wert für Req_mir_free_MB nach dem Ausfall einer Platte nicht und ASM wird auch nach dem Verlust wieder Platz für einen weiteren Verlust reservieren. Dies hat allerdings zur Folge dass der verfügbare Plattenplatz stetig fällt und insbesondere bei nur zwei Failure Groups mit 12c jegliche Operation unterbunden wird, durch die der Wert Usable_file_MB negativ werden würde.

Je nach Ausprägung der Diskgruppe unterscheidet sich also der Worst Case. Bei normaler Redundanz mit 3 oder mehr Failure Groups ist dies jeweils die größte verbleibende Failure Group. Bei hoher Redundanz mit 3 FGs sind es 2 Platten, bei 4 FGs 1 Failure Group + 1 Platte und bei 5 oder mehr FGs jeweils die 2 größten FGs. Auf der Exadata Plattform entspricht eine Zelle übrigens jeweils einer eigenen Failure Group. Zur besseren Übersicht hier das obige Beispiel in tabellarischer Form:

Name	Spiegelung	Anzahl FG	Platten in FG	Worst Case
ASMEXT	Extern	N/A	N/A	N/A
ASMNORM2FG	Einfach	2	5 / 5	Ausfall einer Platte
ASMNORM3FG	Einfache	3	3 / 3 / 2	Ausfall der größten FG (3 Platten)
ASMIGH3FG	Doppelt	3	3 / 3 / 2	Ausfall von 2 Platten
ASMNORM4FG	Doppelt	4	2 / 2 / 2 / 2	Ausfall der größten FG (2 Platten) + 1 Platte
ASMNORM5FG	Doppelt	5	2 / 2 / 2 / 1 / 1	Ausfall der 2 größten FGs (2x2 Platten)

Hinweis: In früheren Versionen wurde der Worst Case noch anders ermittelt, da auch Diskgruppen mit Platten unterschiedlicher Größe erlaubt waren.

Usable_File_MB berechnet sich also aus: (FREE_MB - REQUIRED_MIRROR_FREE_MB)/REDUNDANCY.

Sollte also der Worst Case größer sein, als der verfügbare freie Platz, so kann auch ein negativer Wert für Usable_File_MB entstehen. Was bedeutet aber nun ein negativer Wert in Usable_File_MB genau?
Letztendlich nur, dass nach dem Eintritt des Worst Cases die Redundanz nicht wieder hergestellt werden kann. Es bedeutet aber nicht, dass kein Platz mehr in der Diskgruppe ist. Auch hat dies keine Auswirkung auf die existierende Spiegelung. Erst wenn Platten ausfallen könnte der Spiegel "zerbrechen". Allerdings hat ein negativer Wert je nach Diskgruppen Ausprägung auf einige Befehle negativen Einfluss. So lässt sich unter Umständen kein weiterer Tablespace mehr anlegen oder ein ACFS Filesystem nicht mehr manuell erweitern.

In jedem Fall sollte bei einem negativen Wert möglichst bald über eine Storage Erweiterung nachgedacht werden. Wenn aber wie im Falle von Exadata der Worst Case ein ganzes Shelf mit 96TB Storage ist, bekommt das natürlich eine andere Dimension. Deshalb gibt es auch für Exadata eine andere Auswertung, die zwischen einem Ausfall einer kompletten Zelle und dem Ausfall einzelner Platten unterscheidet: Understanding ASM Capacity and Reservation of Free Space in Exadata (Doc ID 1551288.1)

Als letztes sei noch angemerkt, dass der freie Platz in ASM nichts mit dem verfügbaren Platz in Tablespaces zu tun hat. Eigentlich selbstverständlich für jeden Datenbank Administrator. Dies bedeutet aber auch, dass dies nichts mit dem verfügbaren Platz in ACFS zu tun hat. Denn im Grunde ist das dem ACFS Dateisystem zugrunde liegende ASM Dynamic Volume (ADVM) mit einem Tablespace vergleichbar.

Speicherplatz in ACFS

Für ein ACFS wird ein Volume in ASM benötigt. Dies kann über die GUI des ASMCA, der Kommandozeile von ASM 'asmcmd' oder auch über SQL angelegt werden. Wie ein Tablespace belegt dieses Volume direkt den Plattenplatz in ASM, wie hier am Beispiel zu sehen, in denen jeweils ein 2GB Volume erzeugt wurde:

       
ASMCMD> lsdg
State    Type    Rebal  Sector  Block       AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name
MOUNTED  EXTERN  N         512   4096  1048576      8192     6024                0            6024              0             N  ASMEXT/
MOUNTED  NORMAL  N         512   4096  1048576      8192     3834             1024            1405              0             N  ASMNORM2FG/
MOUNTED  NORMAL  N         512   4096  1048576      8192     3733             3072             330              0             N  ASMNORM3FG/
MOUNTED  HIGH    N         512   4096  1048576      8192     7883             2048            1945              0             N  ASMHIGH3FG/
MOUNTED  HIGH    N         512   4096  1048576      8192     1685             3072            -462              0             N  ASMHIGH4FG/
MOUNTED  HIGH    N         512   4096  1048576      8192     1685             4096            -803              0             N  ASMHIGH5FG/

Interessant ist der Umstand, dass sich das Volume nicht in der ASMNORM3FG anlegen ließ, während der gleiche Befehl bei anderen Diskgruppen mit hoher Redundanz dazu führte, dass Usable_File_MB negativ wurde. Obwohl ASM einen negativen Wert für Usable_file_MAB aufweist, sind die angelegten Volumes noch komplett leer. Dies kann man leicht erkennen, sobald ein ACFS Filesystem darauf angelegt wurde.

       
# df -h
/dev/asm/acfsn2fg-329     2.0G   81M  2.0G   4% /acfs/acfsn2fg
/dev/asm/acfsh4fg-306     2.0G   81M  2.0G   4% /acfs/acfsh4fg

Der freie Platz in ACFS hat somit nichts mit dem verfügbaren Platz in ASM zu tun. Insbesondere für einige ODA Kunden war dies nicht direkt ersichtlich, da die ODA mit der Einführung von ACFS automatisch 50% des ASM Speicherplatzes für das jeweilige ACFS Dateisystem reserviert hat. Hierdurch kam der fälsche Eindruck auf, dass der freie Platz in ASM gleich dem freien Platz in ACFS ist.

Zwar ist das Linux eigene Kommando "df" geeignet den freien Speicherplatz in in ACFS anzuzeigen, allerdings eignet sich der Befehl "du" weniger um die genaue Größe von Dateien zu ermitteln. Die Copy on Write Snapshot Technologie von ACFS verhindert dies. Wird ein "du" auf einem Snapshot ausgeführt, so wird der komplette Platz angezeigt, der beim Kopieren der Dateien in ein anderes Dateisystem benötigt würde. Intern nimmt der Snapshot jedoch sehr viel weniger Plattenplatz ein.

Deshalb sollte bei ACFS mit dem Befehl "acfsutil info fs" und "acfsutil snap info" gearbeitet werden, um den verwendeten Speicherplatz zu analysieren:

       
# acfsutil info fs /acfs/acfsh4fg
/acfs/acfsh4fg
    ACFS Version: 12.1.0.2.0
    on-disk version:       44.0
    flags:        MountPoint,Available
    mount time:   Thu Oct 27 01:23:18 2016
    allocation unit:       4096
    volumes:      1
    total size:   2147483648  (   2.00 GB )
    total free:   1995649024  (   1.85 GB )
    file entry table allocation: 49152
    primary volume: /dev/asm/acfsh4fg-306
        label:
        state:                 Available
        major, minor:          250, 156673
        size:                  2147483648  (   2.00 GB )
        free:                  1995649024  (   1.85 GB )
        ADVM diskgroup         ASMHIGH4FG
        ADVM resize increment: 67108864
        ADVM redundancy:       high
        ADVM stripe columns:   8
        ADVM stripe width:     1048576
    number of snapshots:  4
    snapshot space usage: 10854400  (  10.35 MB )
    replication status: DISABLED

# acfsutil snap info /acfs/acfsh4fg
snapshot name:               snap
snapshot location:           /acfs/acfsh4fg/.ACFS/snaps/snap
RO snapshot or RW snapshot:  RW
parent name:                 /acfs/acfsh4fg
snapshot creation time:      Thu Oct 27 01:32:09 2016

snapshot name:               snapchild1
snapshot location:           /acfs/acfsh4fg/.ACFS/snaps/snapchild1
RO snapshot or RW snapshot:  RW
parent name:                 snap
snapshot creation time:      Thu Oct 27 01:32:32 2016

snapshot name:               snapchild2
snapshot location:           /acfs/acfsh4fg/.ACFS/snaps/snapchild2
RO snapshot or RW snapshot:  RW
parent name:                 snap
snapshot creation time:      Thu Oct 27 01:32:36 2016

snapshot name:               snap2
snapshot location:           /acfs/acfsh4fg/.ACFS/snaps/snap2
RO snapshot or RW snapshot:  RW
parent name:                 /acfs/acfsh4fg
snapshot creation time:      Thu Oct 27 01:32:43 2016

    number of snapshots:  4
    snapshot space usage: 10854400  (  10.35 MB )

Hinweis: Mit 12.1 gibt es noch keine Möglichkeit die Größe einzelner ACFS Snapshots anzuzeigen. Hier ist eine Erweiterung mit 12.2 geplant.

Fazit

ACFS Filesysteme auf Basis der ADVM gleichen Tablespaces in ASM. Damit ist die die Anzeige des freien Speicherplatzes unabhängig von den Informationen in ASM. Deshalb bieten ACFS und ASM unterschiedliche Möglichkeiten, um den freien Speicherplatz zu ermitteln.

Dennoch ist der darunterliegende verfügbare Platz nicht unwichtig, da auch ACFS eine automatische Resize Funktion besitzt, ähnlich wie Tablespaces mit Autoextend. Diese Erweiterung kann aber selbstverständlich nur funktionieren, wenn in ASM genügend Platz vorhanden ist. Das bedeutet im Falle von ACFS, dass der Administrator sowohl den Speicherplatzbedarf in ACFS wie auch in ASM überwachen sollte.

Weitere Informationen

Zurück zum Anfang des Artikels

Zurück zur Community-Seite