|
Clusterware Installation Linux (OEL5, RHEL5, SLES10): Multipathing und UDEV
von Sebastian Solbach, ORACLE Deutschland GmbH
Ausschlaggebend für die Verfügbarkeit einer Applikation, sowie einer erfolgreichen Oracle Clusterware Installation ist
eine funktionierende Konfiguration des Storagezugriffs.
Seit Linux Kernel Version 2.6 ist der Device Mapper für generisches Volume Management und Udev, der Device Manager, für das dynamische
erstellen und löschen von Gerätedateien unter /dev zuständig. Udev bietet zudem die Möglichkeit persistente Device Namen mit zugehörigen
Rechten abzubilden. Der Device Mapper unterstützt durch Multipathing die redundante Anbindung eines Storage Systems über mehrere Pfade.
Mit Oracle Enterprise Linux 5 (OEL5) bzw. RHEL5 und SLES10 haben sich einige Technologien zur Anbindung von Shared Storage geändert.
Die Oracle Dokumentation konzentriert sich bei der Beschreibung der Konfiguration dieser Komponenten auf die wichtigsten Bestandteile.
Eine ganzheitliche Übersicht über das Zusammenspiel dieser Komponenten fehlt jedoch und ist teilweise über viele Metalink Notes
und Whitepaper verstreut.
Gerade beim Setzen der Berechtigungen verwenden die Notes, z.B. für OEL und RH, ein root Skript (rc.local). Dies ist zwar funktionell,
hat aber die Einschränkung nur beim Serverreboot zu greifen. Sollten dynamisch Multipathing Devices hinzugefügt werden
(z.B. über multipath -v2), so greift das rc.local Skript nicht und die Berechtigungen müssen manuell vergeben werden.
Eleganter geht dies unter der Verwendung der UDEV Regeln.
Der folgende Tipp führt diese Informationen zusammen und zeigt die UDEV Regeln anhand einer Beispielkonfiguration:
Ausgangssituation
Es gibt viele gute Metalink Notes zu RAW Devices, Multipathing Konfiguration und UDEV, diese befinden sich unter den
Links am Ende des Tipps. Da aber sowohl 10g (ab 10.2.0.2) als auch 11g
unter Linux keine Charakter Devices (RAW) mehr benötigen und direkt auf Block Devices zugreifen können,
beschränkt sich der Tipp auf diese Anbindung.
Die Beispielkonfiguration greift auf 7 Platten zu:
| Anzahl | Multipath Alias | Enthält | WWID |
| 1x | ocr | 2 Partitionen: OCR + 1st Voting Disk | 3600c0ff000d5948967a4804801000000 |
| 1x | ocrmirror | 2 Partitionen: OCRMIRROR + 2nd Voting Disk | 3600c0ff000d5948982a4804801000000 |
| 1x | vote | 1 Partition: 3rd Voting Disk | 3600c0ff000d59489bba4804801000000 |
| 4x | asm* | 1 Partition: ASM | 3600c0ff000d59489f1a5804801000000 3600c0ff000d5948965a6804801000000 3600c0ff000d59489d0a6804801000000 3600c0ff000d59489e2a6804801000000 |
Multipathing
Das Einrichten des Device Mappers und die Konfiguration von Multipathing wird in den folgenden 2 Metalink Notes beschrieben:
Unter Einbeziehung meiner Erfahrungen beim Testen von Multipathing ergibt sich für die Beispielkonfiguration folgende Konfiguration in
/etc/multipath.conf:
Der Device Mapper legt nun mit Hilfe der Konfiguration /etc/multipath.conf und den UDEV Regeln folgende Devices an:
Unter /dev/mapper:
Unter /dev/dm-* :
,sowie symbolische Links auf die dm-* Devices unter /dev/mpath:
Allerdings wie hier zu sehen, haben die Devices die falsche Berechtigung.
Es ist auch zu beachten, dass die dm-* Devices nach einem Reboot durchaus eine andere Reihenfolge haben können.
UDEV Regeln
Setzt man nun die Berechtigungen über das rc.local Skript, so passiert dies nur während des Bootvorgangs.
Die elegantere Variante ist nun die Berechtigungen über die UDEV Regeln zu vergeben.
Allerdings gibt es hier die Herausforderung, dass nur die symbolischen Links von UDEV erstellt werden, die
Devices unter /dev/mapper aber vom Device Mapper. Diese Devices sind daher nur indirekt über UDEV zu verändern
Eine Möglichkeit dies zu bewerkstelligen ist, dass man die udev Regeln, die zum Zeitpunkt der Erstellung der dm-* Devices
aktiv sind abändert.
Dies geschieht normalerweise in /etc/udev/rules.d/40-multipath.rules.
Da man aber die Default udev Regeln nicht ändern sollte, empfiehlt es sich diese in 39-oraclemultipath.rules zu kopieren:
Original 40-multipath.rules:
Geänderte 39-oraclemultipath.rules (Änderungen Hervorgehoben):
Hierbei wird der Name aus der multipath.conf verglichen mit dem RESULT.
GROUP, OWNER und MODE setzen die Berechtigungen auf das dm-* Device (über den symbolischen Link).
Die /dev/mapper Devices werden mit Hilfe des chown und chmod im RUN+ Block angepasst.
Damit die udev Regeln nun auf die Devices angewendet werden, müssen diese nun nur noch neu geladen werden.
Danach funktionieren die Regeln, sobald die multipath Devices erstellt oder verändert werden (hier zum testen):
Anmerkung Verwendung von ASMLIB:
Sollte die ASMLIB zur Verwendung kommen, brauchen die Berechtigungen für die Devices von ASM nicht angepasst werden und man kann daher auf das
RESULT=="asm*p1", ... verzichten.
Allerdings sollte man bei Verwendung von ASMLIB nicht die /dev/mapper Devices, sondern ausschließlich die Symlinks
aus /dev/mpath bzw. die dm-* Devices verwenden und in /etc/sysconfig/oracleasm die ORACLEASM_SCANORDER="dm" setzen.
Siehe hierzu Note 602952.1 How To Setup ASM & ASMLIB On Native Linux Multipath Mapper disks?
Nützliche Links und Referenzen
Note 357472.1 Configuring device-mapper for CRS/ASM
Note 414897.1 How to Setup UDEV Rules for RAC OCR & Voting devices on SLES10, RHEL5, OEL5
Note 465001.1 Configuring raw devices (singlepath) for Oracle Clusterware 10g Release 2 (10.2.0) on RHEL5/OEL5
Note 564580.1 Configuring raw devices (multipath) for Oracle Clusterware 10g Release 2 (10.2.0) on RHEL5/OEL5
Note 605828.1 Configuring non-raw multipath devices for Oracle Clusterware 11g (11.1.0) on RHEL5/OEL5
Note 602952.1 How To Setup ASM & ASMLIB On Native Linux Multipath Mapper disks?
Zurück zur Community-Seite
|