Normal Redundancy: 2-Wege Spiegelung High Redundancy: 3-Wege Spiegelung External Redundancy: keine Spiegelung durch ASM

Transkript

1 Projekt ASM Storagemigration Ein Erfahrungsbericht Andreas Karlin Senior Consultant

2 Oracle Datenbankprodukte sind bei vielen Firmen ein fester Bestandteil ihrer Infrastruktur. Die Produkte, hierzu zählen z.b. die Datenbank selbst oder Automatic Storage Management, sind universell einsetzbar und bieten viele interessante und nützliche Features. So umfangreich die Features sind, so komplex ist auch deren Pflege und Wartung. Die administrativen Aufgaben werden immer komplexer, und nicht alltägliche Aufgaben sind ohne Experten schwer durchführbar. Zu solchen Aufgaben gehört beispielsweise ein Umzug der Daten auf ein neues Storagesystem. Was muss hierbei beachtet werden? Und welche Fallstricke erwarten uns hierbei? Dieser Artikel beschreibt das Vorgehen und liefert Erfahrungswerte, welche in einem realen Projekt gesammelt wurden. 1. Die Geschichte Das bei einem Kunden eingesetzte zentrale Datenspeichersystem wird für Oracle Datenbanken, sowie deren zugehörige Applikationen, eingesetzt. Der Herstellersupport des Storage-Systems läuft Ende Februar 2013 aus. Die Speicherkapazität des Storages ist ausgereizt, eine Erweiterung ist ausgeschlossen. Aus Supportgründen und auch wegen des inzwischen höheren Speicherbedarfs, wird ein neues Storage-Subsystem zum Einsatz kommen. Die neue Storage-Lösung ist so konzipiert, dass die Daten immer redundant auf zwei separaten Storage-Einheiten vorgehalten werden. Da es sich bei den Oracle Datenbankservern um Risikosysteme handelt, muss der Umzug im Vorfeld sorgfältig konzipiert werden. Ziel ist es diesen Infrastrukturumzug so zu planen und durchzuführen, dass ein potentielles Ausfallrisiko so weit wie möglich minimiert werden kann. Im Rahmen dieses Projektes wurde auch eine Testmigration durchgeführt. Diese Testmigration diente dazu, zum einen zur Bestimmung des genauen Umzugsaufwandes und zum anderen zur reibungslosen Planung des eigentlichen Umzugs-Prozedere. Info-Tel Datum Seite 2 / 16

3 2. ASM Was ist das? Die Oracle Datenbanken werden mit Hilfe einer speziellen Oracle Speicherumgebung verwaltet. Diese Umgebung trägt den Namen Automatic Storage Management, kurz ASM. Die Daten in ASM sind via Betriebssystem nicht sichtbar oder veränderbar. ASM dient als spezieller Volume Manager für Oracle Datenbanken. Jedoch können administrative Tätigkeiten nur mit Oracle eigenen Utilities durchgeführt werden. Mit ASM kann der DBA die Kontrolle über nahezu alle speicherrelevanten Konfigurationen der Datenbanken übernehmen, die normalerweise in der Hand von System- oder Storage- Administratoren liegen. Dazu zählen z. B. folgende Details, die komplett mit Hilfe des ASM konfiguriert beziehungsweise verwaltet werden können: Striping, I/O-Performance Tuning Automatische Vergabe von Dateinamen Gruppierung von physischen Platten und Verteilung der Daten auf Platten Überwachung von Dateisystemen Datenspiegelung (Mirroring) Realisiert wird ASM als eine spezielle Form einer Datenbankinstanz, die ausschließlich der Konfiguration und dem Management des datenbankrelevanten Speichers dient. Diese Instanz hat, genau wie eine normale Datenbankinstanz, verschiedene Hintergrundprozesse und eine SGA. ASM stellt eine vereinfachte Schnittstelle für das Management von Plattenspeichern zur Verfügung. Dabei verbindet es Funktionalitäten eines Cluster-Dateisystems mit denen eines logischen Volumes. ASM kann ein softwareseitiges Spiegeln der Daten übernehmen. Bei der Erstellung einer Disk- Gruppe kann der Administrator die Redundanz konfigurieren: Normal Redundancy: 2-Wege Spiegelung High Redundancy: 3-Wege Spiegelung External Redundancy: keine Spiegelung durch ASM Info-Tel Datum Seite 3 / 16

4 Soll ASM die Spiegelung tatsächlich verwalten, müssen die Platten einer Plattengruppe innerhalb dieser Spiegelung in so genannte Failure-Gruppen entsprechend dem eingestellten Redundanztyp aufgeteilt werden. Dabei spiegelt ASM nicht den kompletten Bereich der Platten als Ganzes, sondern spiegelt einzelne Extents der angelegten Dateien auf verschiedenen Platten. Grundsätzlich gelten für ASM folgende Regeln:. Immer Disks mit der gleichen Grösse in eine Diskgruppe nehmen. Immer Disks mit gleicher Geschwindigkeit in eine Diskgruppe nehmen. Eine Disk Gruppe für die Datendateien, eine Diskgruppe für die Archivelogdateien. 3. Den Umzug machen wir Online Zuerst wurde ein Onlineumzug der Daten präferiert. Mit ASM lässt sich eine solche Migration durchführen, wenn bestimmte Kriterien erfüllt sind. Das alte und neue Storage müssen parallel den Servern präsentiert werden. Die LUN s des neuen SAN s müssen identisch oder grösser sein als die alten LUN s. Da die LUN s der alten Umgebungen sehr groß sind (grösser als 600 Gbyte), müssten auch auf der neuen SAN die LUN s entsprechend eingerichtet werden. Dies würde eine Verschwendung des Plattenplatzes bedeuten da diese lediglich zur Hälfte genutzt werden. Um diese Problematik zu umgehen, werden neue Diskgruppen erstellt. Die Daten müssen beim Umzug auf diese neuen Diskgruppen kopiert werden. Dies ist nicht online möglich und muss während zuvor definierten Downtimes geschehen. info@trivadis.com. Info-Tel Datum Seite 4 / 16

5 4. Test der Storagemigration 4.1 Vorgehensweise Um Seiteneffekte für die Produktionsumgebungen zu vermeiden, wurde eine Testumgebung installiert und konfiguriert. Die Testumgebung, sowohl auf Linux-, als auf Datenbankebene, wurden identisch zu der Produktion installiert und konfiguriert. Somit ist gewährleistet, dass die Ergebnisse der Tests aussagekräftige Erfahrungen für die produktive Migration liefern können. Die Testmigration wurde auf Basis des Oracle Support Dokuments How To Move The Database To Different Diskgroup (Change Diskgroup Redundancy) [ID ] konzipiert. Gemäß den Anforderungen und Gegebenheiten der Umgebung, wurde die Vorgehensweise entsprechend abgewandelt. Zusammenfassend wurden die folgenden Migrationsschritte erarbeitet und getestet: Vorbereitung des neuen Storages Vorbereitung der Server Entfernen der Standby-Konfiguration Umzug der Datenbank Änderung relevanter Scripte Umzug der Clusterinternen Dateien Diverse kleinere Nacharbeiten auf den Servern Die Migrationsschritte wurden zuerst an einer Testdatenbank durchgeführt. Nachdem einige Punkte optimiert wurden, wurden die restlichen Testdatenbanken migriert. 4.2 Ergebnis Die Testmigration konnte ohne grössere Probleme durchgeführt werden. Die potentiell auftretenden Risiken wurden erkannt, bewertet und entsprechend gelöst. Daraus resultierend wurden folgende Punkte erarbeitet: Dauer des Umzugs Downtimes Storagelayout Arbeitsschritte des Umzuges Prüfmechanismen nach dem Umzug Resultierend aus der Testmigration wurde eine Migrationsanleitung erstellt. Diese Anleitung wurde für den produktiven Umzug verwendet. Info-Tel Datum Seite 5 / 16

6 Wie in den vorherigen Kapiteln beschrieben, wurde das Diskgruppen-Layout während des Umzuges geändert. Dies konnte im Rahmen der Testmigration erfolgreich umgesetzt werden. Die folgende Tabelle Zeigt beispielhaft das neue Layout eines von dem Umzug betroffenen Real Application Clusters. Grösse LUN# in Gbyte Name der Diskgruppe Name der Disk Zweck U310 U310D001 DB 1 Daten U310 U310D002 DB 1 Daten U310 U310D003 DB 1 Daten 4 50 U311 U311D001 DB 1 Archive U320 U320D001 DB 2 Daten U320 U320D002 DB 2 Daten U320 U320D003 DB 2 Daten 8 50 U321 U321D001 DB 2 Archive 9 50 U330 U330D001 DB 3 Daten U330 U330D002 DB 3 Daten U330 U330D003 DB 3 Daten U331 U331D001 DB 3 Archive 13 1 U300 U300D001F1 Cluster Disks 14 1 U300 U300D002F2 Cluster Disks 15 1 U300 U300D003F3 Cluster Disks 16 1 U300 U300D004F4 Cluster Disks 17 1 U300 U300D005F5 Cluster Disks Abbildung 1: ASM Diskgruppenlayout Testumgebung Diskgruppe Speicherplatz in Gbyte Erläuterung der Tabelle: Pro Datenbank werden zwei Diskgruppen genutzt. Eine Diskgruppe besteht aus mehreren Disks (LUN s). Je Datenbank existiert eine Diskgruppe für die eigentlichen Daten. Die zweite Diskgruppe beherbergt die Archivierten Logdateien, sowie Redolog- und Controlfilemirror. Die rot hinterlegten LUN s beherbergen Clusterinterne Dateien. info@trivadis.com. Info-Tel Datum Seite 6 / 16

7 Die Dauer der Migration konnte durch die Tests spezifiziert werden. Nachfolgende Tabelle zeigt die Migrationsdauer eines vom Umzug betroffenen Real Application Clusters. Zeit Netto / min Zeit Brutto / min Vorbereitung DB1 DB2 DB3 DB4 DB5 DB Cluster Intern Gesamt Abbildung 2: Migrationsdauer pro Datenbank Erläuterung der Tabelle: Die jeweils farblich identischen Datenbanken wurden parallel umgezogen. Die Nettozeit ist die reine Durchführungszeit ohne Berücksichtigung nicht beeinflussbarer Faktoren. Die Bruttozeit ist die Zeit inklusive der nicht beeinflussbaren Faktoren wie Netzwerkgeschwindigkeit und Menschliche Fehler. Die Bruttozeit ist als die tatsächliche Migrationszeit zu betrachten. info@trivadis.com. Info-Tel Datum Seite 7 / 16

8 5. Nun zu den Erfahrungen. Insgesamt lässt sich festhalten, daß der Test ohne relevante Schwierigkeiten durchgeführt werden konnte. Es gab während der Testmigration zwei nennenswerte Probleme. Auf beide Probleme werde ich genauer eingehen. 5.1 Unzureichende ASM Standardwerte Das Automatic Storage Management meldete während der Erstellung der Diskgruppen ein Speicherproblem. Folgendes Bild zeigt den Fehler zur Zeit der Diskgruppenerstellung: Abbildung 3: Fehler während der Erstellung der 14. Diskgruppe Der Fehler deutet darauf hin, dass die Speicherparameter der ASM Instanz zu gering sind. Offenbar reichen die Standardparameter ab einer gewissen Anzahl von Diskgruppen nicht aus. Der Fehler ist ab der Erstellung der 14. Diskgruppe eines Clusters aufgetreten. Info-Tel Datum Seite 8 / 16

9 Die nachfolgenden Befehle erhöhen die Speicherparameter von der ASM Instanz. Die Befehle müssen auf allen ASM Instanzen abgesetzt werden. Danach ist ein Neustart der Clusterware erforderlich. SQL> show parameter memory NAME TYPE VALUE memory_max_target big integer 272M memory_target big integer 272M SQL> alter system set memory_max_target=4096m scope=spfile; System altered. SQL> alter system set memory_target=1536m scope=spfile; System altered. SQL> exit Abbildung 4: Ändern der Speicherparameter der ASM Instanzen Nach einer Erhöhung der Hauptspeicherparameter, konnten die Diskgruppen angelegt und gestartet werden. Die Parameteroptimierung wurde als Task für den Umzug in der Migrationsanleitung definiert. Info-Tel Datum Seite 9 / 16

10 5.2 SAN Failover Wie bereits in den Vergangenen Kapitel erwähnt, besteht die neue Storage-Lösung aus zwei Speichereinheiten. Die Daten werden auf den Einheiten gespiegelt vorgehalten. Beide Einheiten sind für die angeschlossenen Systeme transparent, d.h., die Maschinen sehen nur ein Storage. Die gesamte Oracle Landschaft besteht aus Oracle Linux 5.x Servern. Laut der Dokumentation des neuen Storages wird die sog. Multipath-Problematik (Eine LUN erscheint mehr als einmal als eigenständiges Device) durch das Linuxinterne Device Mapping gelöst. Die empfohlene Devicekonfiguration des Herstellers wird in die Datei /etc/multipath.conf eingetragen. Eine solche Devicekonfiguration sieht wie im folgenden Beispiel aus. defaults { } polling_interval 60 device { vendor product "DataCore" "Virtual Disk" path_grouping_policy failover path_checker tur failback 10 prio alua rr_min_io 100 } Abbildung 5: Konfiguration der multipath.conf Soweit, so gut! Die Konfiguration wurde wie angefordert eingetragen. Im Normalbetrieb konnten keine Probleme verzeichnet werden. info@trivadis.com. Info-Tel Datum Seite 10 / 16

11 5.2.1 Der Failovertest Fibrechannel plugout Der Output des Tools multipath verzeichnete vor dem Test zwei Pfade zu den LUN s (hier rot und blau gekennzeichnet). [root@node1 backup]# multipath -ll U170D003 (360030d905a5cba003a78b1439bffa153) dm-37 DataCore,Virtual Disk size=50g features='0' hwhandler='0' wp=rw -+- policy='round-robin 0' prio=1 status=active `- 0:0:0:30 sdae 65:224 active ready running `-+- policy='round-robin 0' prio=1 status=enabled `- 1:0:2:30 sdcx 70:80 active ready running Abbildung 6: Ausgabe der verfügbaren Pfade vor Test Um den Failover physikalisch zu testen, wurden die FC Kabel abwechselnd von den FC Karten der Server getrennt. Wurde einer der FC-Verbindungen manuell getrennt, wurde auf Serverseite nur ein Pfad gesehen. [root@node1 backup]# multipath -ll U100D004F4 (360030d908a65c300f5750a3e38c00f45) dm-10 DataCore,Virtual Disk size=1.0g features='0' hwhandler='0' wp=rw `-+- policy='round-robin 0' prio=1 status=enabled `- 1:0:2:3 sdbw 68:160 active ready running Abbildung 7: Ausgabe der verfügbaren Pfade nach Test Wird anschließend die FC-Verbindung manuell hergestellt, werden an den Servern beide Pfade angezeigt. Dies stellt ein korrektes Verhalten dar. Halten wir also fest: Das trennen der FC-Verbindung an den Servern funktioniert wie erwartet. info@trivadis.com. Info-Tel Datum Seite 11 / 16

12 5.2.2 Wartungsmodus Spezial Ein weiterer Test bestand aus einer Simulation der Durchführung einer Wartung an den Storage-Einheiten. Hierzu wurden beide Storage-Einheiten nacheinander heruntergefahren und hochgefahren, sodass jederzeit eine Storage-Einheit aktiv war. Erfolgt das Herunterfahren einer Storage-Einheit in den Wartungszustand, wird der betroffene Pfad auf Serverebene entfernt. Hierbei konnten keine Probleme festgestellt werden. Der Output des Tools Multipath zeige wie erwartet einen Pfad an. U110D002 (360030d90c b5f866211a) dm-16 DataCore,Virtual Disk size=100g features='0' hwhandler='0' wp=rw `-+- policy='round-robin 0' prio=1 status=enabled `- 1:0:2:6 sdbz 68:208 active ready running Abbildung 8: Ausgabe der verfügbaren Pfade während Wartungszustand eines Storages Wird die betroffene Storage-Einheit nach der Wartung gestartet, wurde dies von den Servern nicht erkannt. Multipath zeigte weiterhin nur einen Pfad an. Was passiert wenn ich die zweite Storage-Einheit in den Wartungsmodus schalte? Folgender Output zeigt das Desaster. U110D002 (360030d90c b5f866211a) dm-16 DataCore,Virtual Disk size=100g features='0' hwhandler='0' wp=rw -+- policy='round-robin 0' prio=0 status=enabled `- 1:0:2:6 sdbz 68:208 failed faulty running Abbildung 9: Ausgabe der verfügbaren Pfade während Wartungszustand beider Storages Wie in vorangehenden Abbildung sichtbar, verabschiedete sich der letzte vorhandene Pfad. Die Server verloren die Verbindung zum Storage. Die Systeme waren außer Gefecht gesetzt. Info-Tel Datum Seite 12 / 16

13 5.2.3 Der erste Supportfall... Wir öffneten nach diesem Vorfall einen Service Request an den Storage-Hersteller. Nach einigen Tagen wurde uns angeraten, einen weiteren Parameter in die /etc/multipath.conf zu integrieren. Die Konfigurationsdatei wurde wie im nächsten Beispiel entsprechend erweitert. defaults { } polling_interval 60 device { vendor product "DataCore" "Virtual Disk" path_grouping_policy failover path_checker tur failback 10 prio alua rr_min_io 100 dev_loss_tmo } Abbildung 10: Konfiguration der multipath.conf nach Service Request an den Storage- Hersteller Der Parameter dev_loss_tmo gibt in Sekunden an, wie lange nach einem Fiber-Channel- Kanal-Fehler gewartet werden soll, bis der Kanal auf O/S Ebene entfernt wird. Übersetzt heisst dies, daß nach einem Storagefehler der Kanal dennoch sichtbar ist, aber als fehlerhaft erkannt wird und nicht wie in den Tests zuvor dann entfernt wird. Wie zu erkennen ist, steht der Zähler sehr hoch und damit ist die Zeitspanne sehr groß. Somit ist auszuschliessen, dass ein defekter Kanal niemals entfernt wird. Abgesehen davon, dass der Storage-Hersteller dies nicht in den Standarddokumenten verzeichnete, hatten wir ein weiteres Problem zu lösen. Der Parameter zieht erst ab der Oracle Linux Version 5.7. Wir hatten jedoch auf den betroffenen Systemen die Versionen 5.4 und 5.6 installiert. Diverse Tests bestätigen dies. Somit blieb uns nichts anderes übrig, zusätzlich zur Storage-Migration, auch das Betriebssystem zu aktualisieren. info@trivadis.com. Info-Tel Datum Seite 13 / 16

14 5.2.4 Vom hundertstel und tausendstel oder der zweite Supportfall Wir aktualisierten also auf unserer Testumgebung die Systeme von OEL 5.6 auf OEL 5.9 und versuchten die Tests erneut. Leider konnten wir keine Entwarnung geben. Das Problem war nach wie vor Präsent. Der Support des Storage-Herstellers konnte uns keine weiteren Informationen geben. Also öffneten wir einen Service Request bei Oracle. Der Oracle Support gab indes zu, dass der Parameter dev_loss_tmo nicht wie erwartet funktionieren würde. Nach einigen Tagen schlug er uns vor, einen zusätzlichen Parameter einzusetzen offensichtlich muss dieser gesetzt sein, da dies im Quellcode vernachlässigt wurde! Die Konfigurationsdatei wurde wie im nächsten Beispiel entsprechend erweitert. defaults { } polling_interval 60 device { vendor product "DataCore" "Virtual Disk" path_grouping_policy failover path_checker tur failback 10 prio alua rr_min_io 100 dev_loss_tmo fast_io_fail_tmo 5 } Abbildung 10: Konfiguration der multipath.conf nach Service Request bei Oracle Der Parameter fast_io_fail_tmo gibt in Sekunden an, wie lange IO auf seine Ausführung warten muss, wenn ein Fiber-Channel-Kanal fehlerhaft ist. Zusammen mit diesem Parametern und OEL 5.9 wurden erneut die Tests durchgeführt. Mit der oben genannten Konfiguration und OEL 5.9 konnten die Tests des Wartungsmodus erfolgreich durchgeführt werden. info@trivadis.com. Info-Tel Datum Seite 14 / 16

15 6. Fazit Die Testmigration konnte, abgesehen von den beiden zuvor genannten Problemen, erfolgreich durchgeführt werden. Alle Produktiven Systeme konnten mit Hilfe der dokumentierten Vorgehensweise reibungslos umgezogen werden. Durch das Problem des Storage-Wartungsmodus, mussten die Migrationstermine mehrmals verschoben werden - insgesamt um drei Monate. Für die nächsten Projekte ist es wichtig, das neue Storagesystem im Vorfeld zu kennen und für solche Tests einen größeren Zeitrahmen einzuplanen. Es hat sich gezeigt, wie wichtig eine Zusammenarbeit zwischen O/S-, DBA und Storage-Team ist. So kritisch die Infos aus dem letzten Absatz sein mögen: Die Testphase vor der eigentlichen Migration war das Geld auf jeden Fall wert. Hätte man ohne diese Testphase einen Umzug durchgeführt, hätte man dies spätestens bei der ersten Storage-Wartung bereut. Die Migration selbst konnte deutlich beschleunigt werden, da durch die Testphase ein HowTo inklusive Checkliste zur Verfügung stand. Und sollte wieder eine Migration anstehen, so kann nun auf die aus diesem Projekt gewonnenen Erfahrungswerte zurückgegriffen werden. Schlussendlich die Kernaussage: Umso Komplexer die Aufgabenstellung ist, umso wichtiger wird eine ausgiebige Testphase! Viel Erfolg beim Einsatz von Trivadis-Know-how wünscht Ihnen Andreas Karlin Trivadis GmbH Industriestrasse 4 Tel: DE Stuttgart Fax: Internet: Mail: andreas.karlin@trivadis.com info@trivadis.com. Info-Tel Datum Seite 15 / 16

16 7. Literatur und Links Oracle Support Portal Storage Support Portal Note : How To Move The Database To Different Diskgroup (Change Diskgroup Redundancy) ftp://support.datacore.com/psp/tbs/tbulletin2a_otherlinux.pdf: Bulletin der Linux Konfiguration für Multipathing Info-Tel Datum Seite 16 / 16