(ASM) – wie
Werbung
58_73_214638_DOAG 26.07.2006 Datenbank 8:54 Uhr Seite 64 ASM Oracle Automatic Storage Management (ASM) – wie “automatisch” ist Automatic? Autor: Markus Michalewicz, ORACLE Deutschland GmbH Mit ASM hat Oracle bei der Datenbank 10g einen beachtenswerten Vorstoß in Richtung Speicherverwaltung unternommen. Offen blieben zwei Fragen: Wie kann ASM die gesamte Speicherverwaltung automatisieren? Und für wen eignet sich ASM? Beide Fragen lassen sich ca. zwei Jahre nach der Einführung von ASM klar beantworten: ASM automatisiert den Speicherbereich, der für die Datenbank-Dateien verwendet wird. Und ASM wendet sich aufgrund seiner SchnittstellenFunktion sowohl an DBAs als auch an System- bzw. Speicherverwaltungsadministratoren, die sich bei der Verwendung von ASM bereits im Vorfeld abgleichen sollten, wie bei [1] beschrieben. 64 News Q3-2006 Dieser Abgleich zwischen allen beteiligten Gruppen ist die Grundvoraussetzung, um mit ASM nicht nur eine hochverfügbare (im Sinne der Absicherung von Daten vor einem Disk-Ausfall) Speicherverwaltung zu schaffen, sondern auch eine performante (im Sinne guter I/O- und Durchsatzwerte). Gerade dieses Problem lässt sich gemäß [2] relativ leicht lösen, indem eine "geschickte Kombination" von ASM und Funktionen des Speicher-Subsystems (wie RAID- und Striping-Verfahren) gewählt wird. Um jedoch entscheiden zu können, was eine geschickte Kombination ist, müssen zunächst einmal die grundlegenden Eigenschaften sowie die Besonderheiten von ASM bekannt sein. Dennoch kann es keine allgemeine Empfehlung für das ideale Layout geben, da immer die jeweiligen Eigenschaften des Speicher-Subsystems und dessen Architektur zu berücksichtigen sind. www.doag.org 58_73_214638_DOAG 21.07.2006 9:45 Uhr Seite 65 ASM Grundlegende Eigenschaften von ASM Prinzipiell gilt: • Die kleinste, logische Einheit von ASM ist die ASMDisk, die wiederum in eine Disk-Gruppe aufgenommen werden kann. • Die Disk-Gruppe selbst beinhaltet [1..n] ASM-Disks, die mittels Failgroups weiter logisch unterteilt werden können. • Failgroups legen Beziehungen zwischen ASM-Disks hinsichtlich einer Ausfall-Toleranz fest. • Die Ausfall-Toleranz kann gesteigert werden, indem Spiegelungsmechanismen von ASM genutzt werden (ASM bietet keine paritätsbasierte Absicherung an). • Eine Spiegelung kann in der Stufung "External Redundancy" (keine Spiegelung von ASM, sondern extern), "Normal Redundancy" (einfache Spiegelung) oder "High Redundancy" (doppelte Spiegelung) vorgenommen werden. • Die Festlegung des Spiegelungsgrades wird für die Disk-Gruppe vorgenommen und ist danach bindend. Eine nachträgliche Änderung bedingt ein Neu-Anlegen der Disk-Gruppe. Datenbank Mirroring-Verfahren eingesetzt zu werden, das in Abbildung 1 angedeutet ist. An dieser Stelle sei ergänzend bemerkt, dass ein Host-Based-Mirroring auch auf Basis nur eines Servers aufgesetzt werden kann. Im Cluster-Verbund erscheint dieses Konstrukt jedoch häufiger. Grundlagen und Abhängigkeiten am Beispiel Host-Based-Mirroring mit ASM Aus diesen bereits oft zitierten Grundtechniken von ASM ergeben sich einige Abhängigkeiten, die auch heute noch besonderer Bemerkung bedürfen: • ASM verteilt alle Daten (Extents) über alle Disks in einer Disk-Gruppe. • Diese Verteilung von neu anzulegenden Extents (Striping) kann nicht abgeschaltet werden. Sind in einer Disk-Gruppe mehr als eine Disk enthalten, wird ASM die Daten über alle diese Disks verteilen. • Failgroups sind in diesem Zusammenhang abstrakt zu sehen. Es wird festgelegt, dass bei Ausfall aller Disks einer Failgroup und "Normal Redundancy" auf Basis einer weiteren Failgroup weitergearbeitet werden kann – jedoch nicht auf Basis welcher. • Eine Failgroup bedingt keine Festlegung, wo das so genannte Primär- und das Spiegel-Extent angelegt wird (keine typische Primär-/Sekundär-Spiegelung). • Kommt es zu einer lesenden Anfrage, wird immer von dem jeweiligen Primär-Extent gelesen (solange verfügbar). Besondere Relevanz kommt diesen Tatsachen immer dann zu, wenn ASM verwendet werden soll, um im Host-Based- www.doag.org Abbildung 1: Host-Based-Mirroring mit ASM Dieses Verfahren kann mit ASM deshalb relativ problemlos umgesetzt werden, da ASM im so genannten UserMode läuft und daher bei einer geeigneten Verbindung der Speicher-Subsysteme gar nicht erkennen kann, dass einige Disks aus dem einen, andere aber aus dem anderen Speicher-Subsystem kommen. Generell gilt: ASM kann als Disk nur das sehen, was ihm das unterliegende Betriebssystem anbietet. An dieser Stelle wird deutlich, dass die Grundüberlegungen zum Aufsetzen einer solchen Konstruktion von allen beteiligten Gruppen gemeinsam erfolgen müssen. So ist es sicherlich für den speicherverwaltenden Administrator problemlos möglich, eine LUN aus jedem der SpeicherSubsysteme bereitzustellen. Er sollte dabei allerdings wissen, dass diese LUNs auf einer höheren Ebene logisch zusammengefasst werden. Hieraus ergeben sich einige Abhängigkeiten, die unbedingt beachtet werden sollten – sowohl im Falle des HostBased-Mirroring-Verfahrens als auch generell: • In einer ASM-Disk-Gruppe sollten immer Disks bzw. LUNs derselben physischen Größe verwendet werden. • Nach Möglichkeit ist auf ein ähnliches bzw. gleiches I/O-Verhalten der LUNs zu achten. Aus beiden Aussagen geht hervor, dass beide SpeicherSubsysteme selbst ein ähnliches Verhalten bei deren Zugriff sicherstellen sollten. Dies bedeutet, dass etwa ein HostBased-Mirroring-Verfahren auf Basis unterschiedlicher Speicher-Subsystem-Arten (z.B. ein mit Fibre Channel angebundenes SAN und ein mittels Ethernet erreichbares NAS-System) eher als nicht ideal bezeichnet werden muss, News Q3-2006 65 58_73_214638_DOAG 21.07.2006 Datenbank 9:45 Uhr Seite 66 ASM obwohl es technisch durchaus möglich wäre. Hintergrund ist, dass in diesem Fall schon aufgrund der Zuleitung ein unterschiedliches I/O-Verhalten erwartet werden kann, was innerhalb einer Disk-Gruppe nicht erstrebenswert ist. In diesem Zusammenhang wird auch deutlich, dass eine zu starke räumliche Trennung eines der beiden SpeicherSubsysteme vom Server, der den I/O-absetzt, ebenfalls eine negative Auswirkung auf das I/O-Verhalten in dieser DiskGruppe haben kann. Entsprechende Tests und eventuelle Optimierungen sollten daher vor oder während der Installation vorgenommen werden. Aus demselben Grund sollte auch auf einer weiteren Ebene, nämlich der eigentlichen LUNs aus dem jeweiligen Speicher-Subsystem, auf ein ähnliches I/O-Verhalten geachtet werden. So kann, ohne an dieser Stelle eine Bewertung dieser Verfahren vornehmen zu wollen, generell davon ausgegangen werden, dass spiegelungsbasierte, lokale Absicherungsverfahren ein anderes Verhalten aufweisen als paritätsbasierte (RAID1- vs. RAID>2-Vergleich). Es empfiehlt sich daher, alle LUNs einer Disk-Gruppe sowohl in dem hier diskutierten Verfahren als auch generell immer gleichartig aufzusetzen. Abschließend sei zum Host-Based-Mirroring-Verfahren mit ASM noch erwähnt, dass ASM grundsätzlich nur einmal spiegeln kann. Hier spiegelt ASM indirekt zwischen den beiden Speicher-Subsystemen. Diese sollten selbst jedoch eine interne, lokale Datensicherung vorhalten. Zwar kann ein Ausfall einer einzelnen Disk auch mit ASM abgesichert werden, nur bedeutet dies beim Host-Based-Mirroring, dass indirekt wiederum eine Absicherung über die Speicher-Subsysteme erfolgt, was für die Sache selbst zu aufwändig sein dürfte. ASM-Metadaten Das Erstaunliche bei ASM ist, dass die Disk-Verwaltung selbst völlig ohne externe Datenhaltung erfolgt. Abgesehen von dem zum Starten der ASM-Instanz verwendeten PFILE bzw. der initASM.ora und dem eventuell separat vom Datenbank-Home erstellten ASMHome (ab 10gR2 eine mögliche Installationsvariante) benötigt ASM keinerlei Datenhaltung außerhalb dieser intern von ASM verwalteten Informationen. Die ASM-Metadaten werden im Header der ASM-Disk verwaltet. Dabei muss bedacht werden, was genau die ASM-Disk ist. In Frage kommen: • Die gesamte Disk – ein Block Device wird vollständig für ASM verwendet (10gR2) • Die gesamte Disk, aber ein RAW-Device • Eine partitionierte Disk – in der Regel ebenfalls als RAW-Device verwendet Der Header der ASM-Disk ist dabei immer relativ zu der vom Betriebssystem zur Verfügung gestellten Disk. Wird immer die gesamte Disk für ASM verwendet, bedeutet dies, dass der Anfang der betriebssystemseitigen Disk auch der Header der ASM-Disk ist. Wird die Disk auf BetriebssystemEbene partitioniert (Slices gebildet), verändert sich der ASM-Disk-Header in Relation zu dem Header der Betriebssystem-Disk (er "rutscht" nach hinten). 66 News Q3-2006 Wird zudem die Menge der Informationen berücksichtigt, die ASM in den Metadaten hinterlegen muss (z.B. Informationen darüber, welche Disk in welcher Failgroup eingebunden ist, oder welche Failgroups zu welcher Disk-Gruppe gehören), wird deutlich, dass die Pflege der Metadaten einen wichtigen Punkt bei den administrativen Aufgaben von ASM darstellt. Abbildung 2: ASM-Metadaten – stilisiert Für die Verwaltung der ASM-Metadaten gibt es allerdings keinen eigenen Prozess, und auch ein "Resilvering" dieser Daten ist derzeit leider nicht möglich. Die notwendigen Operationen (Updates der Metadaten z.B. durch Abhängigkeitsänderung beim Hinzufügen oder Entfernen von Disks) werden im Zuge eines so genannten Rebalancings vorgenommen. Einzig die Allokation von neuen Extents erfolgt ohne einen expliziten Rebalancing-Vorgang. Der typische "Praxis-Test" Ungeachtet eines fehlenden Resilverings für ASM-Metadaten erfolgt ein erster, "praxisnaher Ausfalltest" allerdings in einer Weise, in der ASM seine Stärken leider nicht ausspielen kann. Ein entsprechender – aber zu vermeidender – Misserfolg ist daher oft die Folge. Abbildung 3: Typische Test-Architektur Dabei geht die typische Test-Architektur oftmals von einer Disk-Gruppe mit 2 Failgroups (in Abbildung 3 rot und grün innerhalb der Disk-Gruppe markiert) aus. In den Failgroups selbst sind jeweils [1..n] Disks eingebunden und die DiskGruppe wurde mit "Normal Redundancy" angelegt. Die typische Testabfolge ist dann: 1. Gleichmäßige Disk-Auslastung generieren (in der Regel durch Datenbank-Erstellung) 2. Eine Disk/Alle Disks einer Failgroup plötzlich und ohne Vorwarnung entfernen 3. ASM-Verhalten beobachten – erwartet wird: a. Erkennung des Disk-Ausfalls www.doag.org 58_73_214638_DOAG 21.07.2006 9:45 Uhr Seite 67 ASM Datenbank ob alle Rebalancing- bzw. Disk-Gruppen-Operationen bereits abgeschlossen sind, sollte dabei nicht allein anhand einer Prozessauflistung (ps –ef |grep bal) auf BetriebssystemEbene erfolgen. Die Dauer des Rebalancings ist direkt abhängig von der Menge der zu verlagernden Daten innerhalb der DiskGruppe und dem Wert des Initialisierungsparameters ASM_POWER_LIMIT. Dieser kann die Werte 0 bis 11 annehmen, wobei "0" für "kein Rebalancing" steht und generell nicht empfohlen ist. Der Wert "11" hingegen gibt an, möglichst schnell das Rebalancing abschließen zu wollen, indem mehrere Prozesse zur Verlagerung der Daten gestartet werden. Dabei ist zu beachten, dass es sich um I/Oselect disk_number,failgroup,Mount_ status, Header_status,mode_status,stabezogene Prozesse handelt und nicht um eine Berücksichte,path tigung der CPU-Auslastung. from v$asm_disk; Ferner sei bemerkt, dass ein Wert über "5" für das asm_power_limit nur in wenigen Fällen eine deutliche Beschleunigung bewirken wird. Auch der Einsatz eines RACs kann diesen Vorgang bezogen auf eine einzelne Diskwird nach absehbarer Zeit der in Ausgabe 1 dargestellte AusGruppe nicht weiter verbessern, da ein Rebalancing zu gangszustand zurückerwartet: einem bestimmten Zeitpunkt für eine DISK_NUMBER FAILGROUP MOUNT_S HEADER_STATU MODE_ST STATE PATH Disk----------- ---------- ------- ------------ ------- -------- -------------- bestimmte Gruppe nur von --1 T3_2 CACHED MEMBER ONLINE NORMAL /dev/raw/raw8 einer Instanz durch0 T3_1 CACHED MEMBER ONLINE NORMAL /dev/raw/raw7 geführt werden kann. Ein Failover zu einer anderen Ausgabe 1: Disk-Normalzustand in der Test-Architektur ist zwar möglich, eine Parallelisierung DISK_NUMBER FAILGROUP MOUNT_S HEADER_STATU MODE_ST STATE PATH des Vorgangs über ----------- ---------- ------- ------------ ------- -------- ------------Instanzen hinweg -jedoch nicht. 1 CLOSED MEMBER ONLINE NORMAL /dev/raw/raw7 Zur Vermeidung 1 T3_2 CACHED MEMBER ONLINE NORMAL /dev/raw/raw8 0 MISSING CANDIDATE OFFLINE HUNG eines Zustands wie in Ausgabe 2 dargestellt, ist die MetaAusgabe 2: Hung-Status nach Schritt 4 des Testplans daten-Pflege von ASM bei Schritt 4 des Testplans zu berücksichtigen. Der in Ausgabe 1 dargestellte Normalzustand besagt, dass Die Besonderheit in Ausgabe 2 besteht im Status "OFFdie Disks /dev/raw/raw[7..8] in der Disk-Gruppe T3 sind LINE HUNG" für eine nicht weiter spezifizierte Disk. Nur und jeweils der Failgroup T3_1 und T3_2 zugewiesen wuraus der ersten Zeile ist zu erkennen, dass mit diesem Einden. trag die Disk /dev/raw/raw7 gemeint ist, da diese laut erster Oft kommt es aber dazu, dass dieses Verhalten nicht wie Zeile zwar ein Member ist, aber weder einer Failgroup noch gewünscht eintritt. Der Grund dafür liegt jedoch nicht alsonst wie zugewiesen werden konnte. lein bei ASM, zumindest nicht dann, wenn einige der beDer Grund für diese Ausgabe ist, dass hier Schritt 4 reits diskutierten ASM-Spezifika berücksichtigt werden. höchstwahrscheinlich vor Beendigung des RebalancingSo sollte zunächst sichergestellt werden, dass der Vorgangs durchgeführt wurde, ohne die Disk vorher komRebalancing-Vorgang, der sofort nach der Erkennung des plett gelöscht zu haben. Disk-Ausfalls gestartet wird, auch beendet wurde. Ein In diesem Fall sind noch Metadaten, die zuvor in dem Disk-Ausfall kann von ASM übrigens nur dann erkannt Disk-Header eingetragen wurden, auf der Disk enthalten. werden, wenn das Betriebssystem den Ausfall bereits erfasst Zudem wird die Disk /dev/raw/raw7 dem System wieder hat (zu prüfen in den System-Logs). Sollte also überhaupt unter demselben Namen zugeführt. Dies "verwirrt" ASM, kein Rebalancing einsetzen, kann dies eine mögliche das ja noch im Begriff ist, diese Disk einem Rebalancing zu Ursache sein. unterziehen. Mit anderen Worten, es wird dem System Ein einmal gestarteter Rebalancing-Vorgang kann zwar eine Disk hinzugefügt, die offiziell – und so sagen es auch im Notfall mit alter diskgroup <DG-Name> rebalandie Metadaten auf der Disk – ja noch Bestandteil des ce power 0; gestoppt werden. Dies sollte in der Regel aber Systems ist. nicht erforderlich sein. Zudem kann er erneut gestartet Eine präventive Maßnahme, die auch hier hilft, ist das werden mit alter diskgroup <DG-Name> rebalance; Löschen der Metadaten auf der Disk. Dazu reicht es aus, die und seine vermutliche Laufzeit über die View v$asm_opeersten 2 MB der ASM-Disk mittels DD zu löschen. Unter ration eingesehen werden. Eine Entscheidung darüber, b. Einsetzen des Rebalancings c. Sicherstellen einer reorganisierten Disk-Struktur bei durchgehender Zugriffsmöglichkeit auf die Daten 4. "Instandsetzen der Konfiguration" durch Hinzufügen der zuvor entfernten Disk Während die ersten drei Schritte kein Problem darstellen, tritt mit Schritt 4 des "Testplans" ein Verhalten ein, das von vielen Anwendern anders erwartet wird. Gemessen an dem Output eines www.doag.org News Q3-2006 67 58_73_214638_DOAG 21.07.2006 Datenbank 9:45 Uhr Seite 68 ASM Windows kann entweder das Oracle-Werkzeug logpartformat, ocopy oder ein frei verfügbares DD-Werkzeug für Windows verwendet werden. Wird der Disk-Header bereits vor der erneuten Zuführung der Disk zum System mit DD gelöscht, sollte der in Ausgabe 2 dargestellte Zustand erst gar nicht eintreten. Für eine Anwendung nach bereits eingetretenem "HUNG" empfiehlt sich ein DD, gefolgt von einem: alter diskgroup T3 add failgroup T3_1 disk '/dev/raw/raw7' force; Der Vorteil des sofortigen Absetzens der Erweiterung "force" besteht darin, dass eine unnötige Angabe dieses Parameters in der Regel sofort mit einer entsprechenden Meldung quittiert wird und danach ein Hinzufügen der Disk ohne "force" erfolgen kann. In jedem Fall sollte das Systemverhalten anschließend für eine "angemessene Zeitspanne" (v$asm_operation) beobachtet und das Ende des mit dem "add disk"-Befehl erneut gestarteten Rebalancings abgewartet werden. Ein unkontrolliertes oder mehrfaches Absetzen von "add disk"- und "drop disk"-Operationen, eventuell sogar mit dem Parameter "force", wird das Problem nicht lösen! dann, wenn nur noch eine Disk in der Disk-Gruppe enthalten ist – diese enthält ja auch Metadaten). ASM geht bei einem Ausfall der Disk von einem Verlust der Daten aus. Ist dies nicht der Fall, sollte der Administrator, wenn er diesen Ausfall willentlich herbeiführt, dafür Sorge tragen, dass ASM den Ausfall akzeptiert, z.B. durch ein vorheriges Dismount der Disk-Gruppe. Alternativ kann er auch durch einen präventiven DD oder einen DD, der im akuten Bedarfsfall abgesetzt wurde, zumindest den Verlust der im Header enthaltenen Metadaten forcieren. Der Rest erfolgt dann aber (voll-)automatisch. Literatur • [1] Michalewicz, M., Czarski, C.: Effektive Datenbankund Storage-Layouts (im Vergleich), Foliensatz, ORACLE Deutschland GmbH, 2005, www.oracle.com/ global/de/feedback/massendaten/Oracle_Effektive_ Datenbank_und_Storage-Layouts.pdf • [2] Shakian, A.: Take the Guesswork out of Database Layout and I/O Tuning with Automatic Storage Management, Oracle Corporation, December 2005, www.oracle.com/pls/wocprod/docs/page/ocom/tech nology/products/database/asm/pdf/take%20the%20 guesswork%20out%20of%20db%20tuning%2001 06.pdf Fazit Der hier dargestellte "Praxis-Test" ist allenfalls beispielhaft für kurzfristige Ausfälle. Diese gibt es für ASM nicht. Geht eine Disk verloren, werden sofort nach der Erkennung des Verlustes die dargestellten Operationen eingeleitet (auch Kontakt: Markus Michalewicz [email protected] DOAG-Schulungstag 17.11.2006 Unsere Schulungsthemen in diesem Jahr: • • • • • • • • Optimierte Datensicherung in Oracle 10g: Backup und Recovery schnell und sicher! MD Consulting & Informationsdienste GmbH Backup und Recovery mit dem Oracle Recovery Manager msg systems ag Datenbank Security MuniQSoft GmbH SQL Statement Tuning OPITZ CONSULTING GmbH Advanced PL/SQL ORDIX AG Entwurf wohlstrukturierter Prozesse und ihre Umsetzung mit BPEL PROMATIS software GmbH Power of OLAP TEAM GmbH High Availability and beyond Trivadis GmbH Anmeldung unter: www.doag.org/go/schulung 68 News Q3-2006 www.doag.org
