| orm@doc-tcpip.org | Erstellt: Februar 2005 - Letzte Modifikation: März 2006 |
Man hat eine AIX Maschine oder eine LPAR, die über zwei Fiber-Channel Adapter verfügen und über diese an eine ESS angebunden sind. Auf der ESS sind Platten definiert, die per Zoning den WWPN der FC-Adapter der Maschine bzw. LPAR zugeordnet sind:
----------------- -----------
| | ESS |
FC 1 |-------------------------| |
WWPN A | | LUN xyz |
| | |
HOST | | LUN abc |
FC 2 |-------------------------| |
WWPN B | |-----------|
| (beide LUN für WWPN A und B)
-----------------|
Das Problem ist jetzt: Wie zeige ich dem System die Platten auf
der ESS? Wie verteile ich den I/O? Wie stelle ich fest, ob die Verbindung noch steht?
Es gibt zur Zeit 2 Varianten, diese Dinge zu adressieren. Diese Methoden sind von der Bedienung her sehr unterschiedlich und auch nicht nebeneinander einsetzbar.
Das Betriebssystem sieht jede "Platte", also jede LUN auf der ESS über beide Pfade, also über beide Fiber-Channel Adapter. Es legt pro Pfad ein "normales" hdisk-Device an; diese Devices werden dann logisch zu einem sogenannten vpath zusammengefasst:
ESSx ------------------ FC1 -- hdisk3 ------
| \ vpath0
| /
------------------ FC2 -- hdisk5 -----/
ESSy ------------------ FC1 -- hdisk4 ------
| \ vpath1
| /
------------------ FC2 -- hdisk6 -----/
Der vpath entspricht also dem, was man so als physikalische Platte kennt.
Nur das er halt redundant über verschiedene Verbindungen angebunden ist.
Ich sehe auf desem System so die doppelte Anzahl an Platten, als auf
der ESS zur Verfügung gestellt wurden. Die Zahl der vpath entspricht
dieser Zahl.
Es sind pro physikalische Platte (LUN) bis zu 32 Pfade möglich, also eine physikalische Platte würde zu 32 Hdisk-Devices und einem vpath führen. Mit den vpath wird umgegangen wie mit Hdisk-Devices (open, close, dd, fsck). Wichtig ist, daß die PVID in so einer Umgebung immer auf dem vpath sitzen muß; nur wenn man den vpath anspricht, funktionieren Load-Balancing, Failover etc.
Diese Software wurde eingeführt, um ESS (Shark) an AIX Hosts anzuschliessen. Es wird dem "normalen" Betriebsystem ein zusätzlicher Treiber übergestülpt, der als Schnittstelle zur ESS dient.
Ist vom Konzept her ganz anders und in der Nutzung deutlich leichter. Es wird pro LUN/Platte ein hdisk-Device angelegt; man "sieht" also wirklich seine Platten.
ESSx -------- hdisk3
........
ESSy --------
........ hdisk4
Die Software (also der Fiber Channel Device Treiber) weiss also,
das sich hinter dem hdisk-Device zwei Pfade verbergen zur ESS
verbergen. Die Software ist auch in der Lage, die Last über die
Verbindungen zu verteilen.
Diese Software ist die "Weiterentwicklung" des SDD. Der Service ist jetzt voll integriert und in eine offene Architektur eingepasst.
SDD und SDDPCM schliessen sich gegenseitig aus. Konfiguriert man die Platten (LUNs auf der Storage Box) nicht als MPIO fähig, dann legt das AIX System pro Pfad über einen Adapter zu einer physikalischen Platte/LUN ein logisches hdisk-Device an und man braucht SDD, um über verschiedene Pfade darauf zugreifen zu können.
Wie Platten in einer Storage Box angesprochen werden, hängt von den lokal installieren Treibern ab: Installiert man z.B. für eine ESS das Fileset ibm2105.rte, ist man auf SDD und vpath festgelegt. Installiert man device.fcp.disk.ibm.mpio.rte und devices.common.IBM.mpio.rte, werden die Platten auf der selben ESS als MPIO fähig angesprochen und man nutzt SDDPCM.
Wichtig ist auch noch: SDDPCM unterstützt ESS- und DS8000-Einheiten als SAN Boot-Devices.
In einem SAN Umfeld hat man ein Problem mit der Reservierung von Platten bzw. Devices nach dem SCSI 2 Standard. Diese Reservierungen gehen nach einem Reset des SCSI Buses verloren. Weiterhin konnte ein Device nur von einem Initiator und einen Pfad reserviert werden. Daher war es nötig, eine Methode zur Persistenten Reservierung zu finden.
Dabei generiert jede Maschine (der Initiator bei SCSI) einen Key, den Persisten Reservation Key (PR Key). Mit den Befehlen des SCSI 3 Standards registriert sich so jeder Initiator bei einem Device, er wird Mitglied einer Membership Group. Das Device speichert alle Keys. Jeder registrierte Initiator kann dann ein Device für sich reservieren. Es wird quasi ein vorhandener Key aktiviert. Die Reservierung bleibt auch über einen Reset des Buses bestehen - ist also persistent.
Es gibt eine Reihe weiterer Mechanismen, um Reservierungen zwischen Devices zu überführen und zu beenden.
Das sieht unter AIX 5.3 so aus:
0:root@testy:/ # lquerypr -Vh /dev/hdisk12
connection type: fscsi1
open dev: /dev/hdisk12
Attempt to read reservation key...
Attempt to read registration keys...
Read Keys parameter
Generation : 52
Additional Length: 32
Key0 : c8ca9d09
Key1 : c8ca9d09
Key2 : c8cabd09
Key3 : c8cabd09
Reserve Key provided by current host = c8cabd09
Not reserved.
Diese Platte gegenüber haben sich 2 Maschinen über je zwei Pfade
registriert. Eine dieser Maschinen hat jetzt den Status abgefragt;
jedoch ist die Platte nicht reserviert.
0:root@testy2:/ # lquerypr -Vh /dev/hdisk8
connection type: fscsi0
open dev: /dev/hdisk8
Attempt to read reservation key...
Attempt to read registration keys...
Read Keys parameter
Generation : 188
Additional Length: 32
Key0 : c8cabd0a
Key1 : c8cabd0a
Key2 : c8ca9d0a
Key3 : c8ca9d0a
Reserve Key provided by current host = c8cabd0a
Reserve Key on the device: c8ca9d0a
Diese Platte ist von einem anderen Host reserviert. Es wird der aktuelle
Key auf dem Device angezeigt, sowie alle Mitglieder der Gruppe, die sich
für dieses Device registriert haben.
Je nach AIX-Version müßen folgende Filesets installiert werden: devices.sdd.52 bzw. devices.sdd.53. Es wird ein zusätzlicher Device-Treiber für das Storage Subsystem installiert. Der Protokoll-Stack wird also etwas erweitert:
Protocol Stack: raw IO, LVM device manager SDD Subsystem Device Driver (Das ist die Ebene der vpath Devices) AIX SCSI oder FCP disk driver (Das ist die Ebene der hdisk Devices) SCSI oder FCP adapter driverZusätzlich werden noch eine Reihe Services und Programme zur Konfiguration und Betrieb der externen Platten installiert. Bilder Redbook Seite 6,7
Hier gibt es einen Serverdeamon: sddsrv. Dieser Deamon wird automatisch gestartet (/etc/inittab). Der Deamon läuft immer, und scannt regelmäßig alle Pfade, um Ausfälle zu identifizieren.
Path Reclamation:
Es werden alle ausgefallenen Pfade getestet.
Das passiert alle 3 Minuten.
Status der Pfade: Invalid, close_dead, dead.
Ist der Pfad wieder verfügbar, so wird er neu initilisiert und der
Status entsprechend angepasst. Das richtet sich nach dem Status des
entsprechenden vpath Devices.
Path Probing:
Hier werden alle Pfade im Status CLOSE und alle
unbenutzten Pfade im Status OPEN
regelmäßig überprüft - mit Intervallen
von einer Minute.
Je nach Zustand der Verbindung und des entsprechenden
vpath Devices wird der Status des Pfades modifiziert:
Der sddsrv-Deamon kann über ein Konfigurationsfile angepasst werden (/etc/sddsrv.conf). Bei Problemen kann mit Hilfe des trace-Befehls ein Trace vom Server Prozess (sddsrv) sowie vom SDD Treiber erzeugt werden. Die Files werden per Default nach /var/adm/ras gelegt. Die Files heissen sddsrv.log und sdd.log.
Die Hauptaufgaben sind:
Je nach Version kann AIX verschieden viele Devices unterstützen. Ist eine multipath Umgebung konfiguriert, so generiert AIX für jeden Pfad zu einer physikalischen Platte (in den Storage Boxen sind das LUN, Logical Unit Numbers, wie man es von SCSI kennt) ein eigenes hdisk-Device.
Pro physikalische Platte kann man teilweise bis zu 32 Pfade definieren - das ist natürlich nicht unbedingt sinnvoll; in speziellen Fällen kann man mit mehr parallelen Pfaden den Durchsatz verbessern. In der Regel sind zwei, maximal vier Pfade zu einer LUN, einer physikalischen Platte, sinnvoll.
Bei 4 Pfaden pro Platte ergibt sich ab AIX 5.2 eine Zahl von 1200 physikalischen Platten, wenn diese auf einem Storage Device wie einer ESS liegen. Setzt man Virtualisierungsprodukte ein, so halbiert sich diese Zahl, da ja diese Platten schon doppelt angebunden sind.
Es gibt ein ODM Attribut, mit der dieser Parameter angepasst werden kann. Per Default liegt er bei der Hälfte des möglichen Wertes. Die Attribute sind Enterpr_maxlun und Virtual_maxlun. So ist es möglich, einer Maschine Pools für die beiden Arten an LUNs zuzuteilen.
Die Attribute beziehen sich auf das Pseudo Device dpo (Data Path Optimizer). Dieses Device dient zur Verwaltung der später anzulegenden virtuellen Pfade, den vpath:
0:root@testy:/ # lsdev -Cl dpo dpo Available Data Path Optimizer Parent 0:root@testy:/ # lsattr -El dpo Enterpr_maxlun 600 Maximum LUNS allowed for Enterprise Products True ==> Wieviele ESS, DS8000, DS6000 LUNs kann ich anschliessen? Virtual_maxlun 512 Maximum LUNS allowed for Virtualization Products False ==> Wieviele SAN Volume Controller LUNS kann ich anschliessen? persistent_resv yes Subsystem Supports Persistent Reserve Command False qdepth_enable no Queue Depth Control TrueDas kann man entsprechend anpassen: chdev -l dpo -a Enterpr_maxlun=zzz.
Der SDD Treiber setzt verschiedene Algorithmen zur Verteilung des I/O auf die vorhandenen Pfade ein. Dieses lassen sich mit dem datapath-Kommando setzten.
Die aktuelle Policy eines vpath findet sich in der Ausgabe des lsattr-Kommandos (oder in der Ausgabe von datapath query device:
0:root@testy:/root # lsattr -El vpath5 active_hdisk hdisk7/00C27913/fscsi0 Active hdisk False active_hdisk hdisk17/00C27913/fscsi1 Active hdisk False policy df Scheduling Policy True pvid 00c8ca9d7853d4340000000000000000 Physical volume identifier False serial_number 00C27913 LUN serial number FalseDer vpath5 zeigt also über die (virtuellen) Platten hdisk7 und hdisk17 und die beiden Fiber-Channel Adapter fscsi0 und fscsi1 auf die ESS C27913. Die Policy steht auf Default, als wird die Last über Load Balancing verteilt. Die Policy kann man verändern mit den datapath-Kommando:
0:root@testy:/root # datapath query device
Total Devices : 10
....
DEV#: 5 DEVICE NAME: vpath5 TYPE: 2105800 POLICY: Optimized
SERIAL: 00C27913
==========================================================================
Path# Adapter/Hard Disk State Mode Select Errors
0 fscsi0/hdisk7 CLOSE NORMAL 3345 0
1 fscsi1/hdisk17 CLOSE NORMAL 3417 0
....
0:root@testy:/root # datapath set device 5 policy rr
DEV#: 5 DEVICE NAME: vpath5 TYPE: 2105800 POLICY: Round Robin
SERIAL: 00C27913
==========================================================================
Path# Adapter/Hard Disk State Mode Select Errors
0 fscsi0/hdisk7 CLOSE NORMAL 3345 0
1 fscsi1/hdisk17 CLOSE NORMAL 3417 0
Es ist dabei egal, ob das Device OPEN oder CLOSE ist.
Eine Auswahl der Dienstprogramme, die mit dem SDD Fileset installiert werden. Die Befehle sind teilweise sehr wichtig:
Dazu dient das Kommando lsvpcfg:
0:root@testy2:/root # lsvpcfg vpath0 (Avail pv testy_vg) 00427298 = hdisk2 (Avail ) hdisk12 (Avail ) vpath1 (Avail ) 10427298 = hdisk3 (Avail ) hdisk13 (Avail ) vpath2 (Avail ) 30427298 = hdisk4 (Avail ) hdisk14 (Avail ) vpath3 (Avail pv hbb_vg) 30627298 = hdisk5 (Avail ) hdisk15 (Avail ) vpath4 (Avail ) 50427298 = hdisk6 (Avail ) hdisk16 (Avail ) vpath5 (Avail pv testy_vg) 00C27913 = hdisk7 (Avail ) hdisk17 (Avail ) vpath6 (Avail pv hbb_vg) 00D27913 = hdisk8 (Avail ) hdisk18 (Avail ) vpath7 (Avail pv ) 10727913 = hdisk9 (Avail ) hdisk19 (Avail ) vpath8 (Avail ) 20327913 = hdisk10 (Avail ) hdisk20 (Avail ) vpath9 (Avail ) 30227913 = hdisk11 (Avail ) hdisk21 (Avail )Hier ist jeder vpath mit den zugeordneten Platten gezeigt. Platte hdisk2 und hdisk12 sind also "virtuelle" Platten auf der lokalen Maschine, die über zwei verschiedene Fiber-Channel Adapter auf diesselbe, physikalische Platte in einer Storage Box zeigen - das ist der vpath.
Wichtig ist, daß pro vpath mindestens 2 Platten im Zustand "Available" stehen. Das Attribut pv (AIX sieht dieses Device als physikalisches Volume) darf nur dem vpath zugeordnet sein. Taucht es bei hdisk-Devices auf, so muß das mit dem dpovgfix Kommando korriert werden.
Man kann die Ausgabe auf einzelne Typen von Storage Boxen oder Virtualisierungs Einheiten beschränken, z.B. lsvpcfg -d 2105.
Ist eine Administrations-Konsole, mit der man Parameter auslesen und Setzen sowie Pfade öffnen und schliessen kann. Dazu dienen entsprechende Subkommandos. Nützlich sind folgende Kommandos zum Auslesen von Information:
Beim Kommando cfgmgr ist zu beachten, daß er bei Platten, die schon eine PVID haben, pro Fiber-Channel Adapter einmal ausgeführt werden muß. (cfgmgr findet die PVID, trägt sie in die ODM ein und setzt das Device in den Status "defined". Findet er diese PVID dann nochmal über den anderen Adapter, macht er nichts mehr. Ruft man cfgmgr nochmal auf, ist die Platte im Zustand "Available" und wird nochmal eingerichtet).
Beim Kommando chdev gegen eine der hdisk wird die PVID der Platte ausgelesen und von der chdev-Methode in die ODM eingetragen. Das hat zur Folge, das sowohl für das vpath Device wie für eine der "virtuellen" hdisk eine PVID existiert und AIX davon ausgeht, daß es sich um physikalische Devices handelt. Dieser Fehler taucht in der Ausgabe des lsvpcfg-Kommandos auf (Attribut "pv" einer hdisk zugeordnet) sowie in der Ausgabe des lsvg -p-Kommandos (statt eines vpath erscheint eine hdisk). Dieses Problem muß mit dem dpovgfix-Kommando behoben werden, da sonst ein vpath verloren geht. Die VG muß varyon sein, aber die Filesysteme sollten nicht gemountet sein.
Anlegen von Volume Groups mit SDD Platten erfordert bestimmte Kommandos, die "normalen" LVM Kommandos reichen nicht aus. Es gibt für alle SMIT Fenster und Kommandozeilen Befehle spezielle Versionen für vpath Devices: mkvg4vp, extendvg4vp, savevg4vp. Weitere Befehle sind zugleich auch SMIT Fenster und spezifisch für vpath Devices: lsvpcfg, cfallvpath, addpaths.
Es werden eine Reihe Nachrichten zu vpath-Devices und sddsrv (errpt -a |grep VPATH bzw. SDD). Das ist teilweise nützlich, wenn man mit gelockten Devices kämpft.
Welche Devices sind an meine Maschine angeschlossen?
0:root@testy:/ # lsdev -C -t 2105 hdisk2 Available 05-08-01 IBM FC 2105 hdisk3 Available 05-08-01 IBM FC 2105 hdisk4 Available 05-08-01 IBM FC 2105 hdisk5 Available 05-08-01 IBM FC 2105 hdisk6 Available 05-08-01 IBM FC 2105 hdisk7 Available 05-08-01 IBM FC 2105 hdisk8 Available 05-08-01 IBM FC 2105 hdisk9 Available 05-08-01 IBM FC 2105 2105 ==> ESS (mit FC ==> Fiber Channel connected, sonst SCSI) 2107 ==> DS8000 1750 ==> DS6000 2145 ==> SAN Volume Controller Device 2062 ==> SAN Volume Controller for Cisco MDS 9000
Wie sehe ich den all die Sachen, die ich für meine Pfade definiert habe?
Mit lsattr -El vpathX und lsattr -El hdiskX.
0:root@testy:/ # lsattr -El vpath0 active_hdisk hdisk2/00427298/fscsi0 Active hdisk False active_hdisk hdisk12/00427298/fscsi1 Active hdisk False policy df Scheduling Policy True pvid 00c8ca9d7853d69c0000000000000000 Physical volume identifier False serial_number 00427298 LUN serial number False 0:root@testy:/ # lsattr -El hdisk2 PR_key_value none Reserve Key True location Location Label True lun_id 0x5004000000000000 Logical Unit Number ID True lun_reset_spt yes Support SCSI LUN reset True max_transfer 0x40000 N/A True node_name 0x5005076300c0a83a FC Node Name False pvid none Physical volume identifier False q_type simple Queuing TYPE True qfull_dly 20 delay in seconds for SCSI TASK SET FULL True queue_depth 20 Queue DEPTH True reserve_policy single_path Reserve Policy True rw_timeout 60 READ/WRITE time out value True scbsy_dly 20 delay in seconds for SCSI BUSY True scsi_id 0x30600 SCSI ID True start_timeout 180 START unit time out value True ww_name 0x5005076300cba83a FC World Wide Name FalseHilfreich ist auch das lspath-Kommando.
Gibt es ein Debug- oder Testtool in der Art des AIX diag?
Das Kommando heisst /usr/sbin/pathtest.
Kann ich auf einen Blick meine Platten, die LUN, Art der Platte, Größe sehen?
Das geht z.B. mit dem lsess-Kommando. Das nimmt die Daten, die der cfgmgr
in das File /var/adm/essmap.out geschrieben hat, generiert /var/adm/lsess.out, was
dann ausgegeben wird.
Welche Platten unterstützt mein System den als MPIO fähig?
Mit dem Kommando odmget -q DvDr=aixdiskpcmke PdDv |more.
Die Installation sowie weitere Information zu MPIO findet sich auf der IBM Webseite. Da dort sehr oft die Links gewechselt werden, hier den Namen der Dokumentation: Multipath Subsystem Device Driver User's Guide, Dokument Nummer SC30-4096-01. Der Name des Dokuments war dieser: f2bsdu05_English_version.pdf.
Praktisch ist es, vor der Installation mit dem lvmrecover-Kommando die LVM Konfiguration zu sichern. Falls man dann hinfällt, kann man leicht wieder den Ausgangszustand wiederherstellen.
Um von normalem LVM auf SDD bzw. bei Updates von SDD zu SDD zu konvertieren, gibt es die Skripte vp2hd und hd2vp.
Im HACMP Umfeld hat man in der Regel gemeinsam genutzte Volume Groups, shared Volume Groups. Diese VG werden nicht automatisch varyon genommen, dafür sorgt die HACMP Software. Bootet (ohne ordentliches umount und varyoff der VG) man nun eine Seite, so wird die persistente Reservierung nicht freigegeben. Beim Varyon auf dem anderen Knoten wird versucht, eine SCSI-3 Reservierung zu machen - das stößt auf einen Konflikt, da die Platte ja noch gesperrt ist, mit einem Lock versehen. Das bedeutet, daß auf der Platte ein Key, eine Signatur mit einem entsprechenden SCSI-2 oder 3 Zugriff abgespeichert worden ist. Man kann nun mit dem lquerypr-Kommando nach Locks auf den Platten sehen, und auch entfernen.
Es ist dabei sehr wichtig, daß man weiß, was man tut. Entfernt man Locks von einer Platte, die eine andere Maschine im Zugriff hat, so werden auch sämtliche laufenden I/O Operationen beendet.
Normalzustand sollte so sein:
Knoten 1 hat die VG und somit den vpath im Zugriff:
0:root@testy1:/root # lquerypr -Vh /dev/vpath5
open device /dev/vpath5
setkey.compcode = 1
setkey.returncode = 3
==> Return Code der Shell:
0 Keine Reservierung auf dem Device oder reserviert vom lokalen Host
1 Reservierungscode auf dem Device ist anders als der des lokalen Host
2 Kommando hat nicht funktioniert
3 Device ist vom lokalen Host geöffnet (varyon)
Knoten 2 findet den Reservierungskey und vergleicht mit seinem eigenen
Reservierungskey:
0:root@testy2:/root # lquerypr -Vh /dev/vpath5
open device /dev/vpath5
setkey.compcode = 0
setkey.returncode = 1
c8ca9d0a
Reserved with different key c8ca9d0a, current host key c8cabd0a
==> Returncode 1, der Key ist also unterschiedlich. Der Key wird
angezeigt, dann kommt eine Zeile mit einem Vergleich Device-Key
und Host-Key
Nach einem unglücklichen Boot ist es eventuell nötig, ein Lock auf
den Platten zu entfernen. Man erhält die Ausgabe wie bei Knoten 2
und setzt dann das Kommando lquerypr -Vrh /dev/vpath5 ab.
Das Lock wird dann von der Platte gelöscht und man kann die Platte
varyon nehmen.
Je nach AIX Version braucht man ein passendes Fileset devices.sddpcm.52.rte bzw. devices.sddpcm.53.rte. Zusätzlich ist eine "host attachment package" zu installieren device.fcp.disk.ibm.mpio.rte und device.fcp.disk.ibm.mpio.rte.
SDDPCM ist eine Kernelextension, die dann angezogen wird, wenn Platten (hdisk-Devices) als MPIO (Multipath I/O) Devices konfiguriert sind. Die Kernel-Extension hängt sich dann in den Device Treiber für das Fiber-Channel Protokoll ein.
Raw I/O LVM
| |
| AIX MPIO FCP Disk Device Treiber |
------------------------------------ (Das ist die Ebene des hdisk-Device)
| SDDPCM | AIX PCM | Andere PCM |
|
|
FCP Adapter Treiber
|
|
ESS, DS8000, EMC etc.
Die I/O Anfrage wird also an den Treiber der Platte geschickt, und dort durch das SDD-Path Control Modul entsprechend auf die verschiedenen Pfade verteilt.
Hier gibt es einen Serverdeamon pcmsrv sowie ein Path Control Module, eine Kernel-Extension. Dieser Deamon wird automatisch gestartet (/etc/inittab). Der Deamon läuft immer, und scannt regelmäßig alle Pfade, um Ausfälle zu identifizieren. Allerdings startet der Dämon nur, wenn die Kernel-Extension geladen ist - was nur passiert, wenn MPIO Devices definiert sind.
Der pcmsrv führt allerdings nur das Path Recalamation durch. Er testet also alle nicht verfügbaren Pfade jede Minute. Dabei wird der Status folgendermassen geändert:
Der pcmsrv-Deamon kann über ein Konfigurationsfile angepasst werden (/etc/pcmsrv.conf). Bei Problemen kann mit Hilfe des trace-Befehls ein Trace vom Server Prozess (pcmsrv) erzeugt werden. Das File wird per Default nach /var/adm/ras gelegt. Es heisst pcmsrv.log. Der entsprechende Trace-Hook ist 5A7.
Pro hdisk Device gibt es 3 Attribute, die man einstellen kann: Das ist einmal die Reservierungs-Policy (Reserve Policy), der Algorithmus zur Auswahl des Pfades (Path Selection) und die Art, in der die Pfade geprüft werden (Healthcheck).
Unter "Policy" wird die Methode verstanden, mit der der Plattenzugriff kontrolliert wird. Die Methode, die hier definiert wird, wird also gesetzt, wenn die LUN/Platte vom AIX geöffnet wird. Ab dann erfolgt die Reservierung bzw. der Zugriff nach einer bestimmten Regel.
Die Policy wird pro LUN/hdisk festgelegt. Folgende Policies kann man wählen:
0:root@testy:/ # lsattr -l hdisk0 -a reserve_policy -R no_reserve single_path PR_exclusive PR_shared
Die Policies werden folgendermassen gesetzt:
chdev -l hdisk0 -a reserve_policy=PR_exclusive
chdev -l hdisk0 -a PR_key_value=0x1234 -a
Zusätzlich zur Policy ist es im Fall des Zugriffes über mehrere Wege nötig, einen Algorithmus zu definieren, der bestimmt, wie auf die verschiedenen Pfade zugegriffen werden soll. Das ist die Aufgabe des PCM, des Path Control Modules. Folgende Algorithmen stehen zur Verfügung:
0:root@testy:/ # lsattr -l hdisk1 -a algorithm -R fail_over round_robin load_balance
Es gibt 3 mögliche Modi:
0:root@test:/ # lsattr -l hdisk0 -a hcheck_mode -R enabled failed nonactiveDas Healthcheck-Kommando prüft nur Pfade im Status OPEN. Pfade, die im Zustand CLOSE_FAILED sind, werden vom sddpcm-Server geprüft. Ist Health-Checking abgeschaltet, so übernimmt der Server-Deamon auch die Pfade im Status OPEN.
Eine Auswahl der Dienstprogramme, die mit dem SDDPCM Fileset installiert werden. Die Befehle sind teilweise sehr wichtig:
Analog zum lquerypr-Kommando. Erlaubt das Auslesen, Löschen, Modifizieren und Beenden der Persisten Reserve Keys bzw. der Reservierung. Das Kommando implementiert eine Reihe von SCSI-3 Kommandos. Genau wie bei dem SDD Pendant lquerypr ist zu Beachten, daß eine Beendigung einer Reservierung auch noch laufende I/Os abbricht.
0:root@testy:/ # pcmquerypr -Vh /dev/hdisk1
connection type: fscsi1
open dev: /dev/hdisk1
Attempt to read reservation key...
Attempt to read registration keys...
Read Keys parameter
Generation : 0
Additional Length: 0
resrvpolicy= no_reserve
Reserve Key provided by current host = none (hex)c8ca9d10
Not reserved.
Ist eine Administrations-Konsole, mit der man Parameter auslesen und Setzen sowie Pfade öffnen und schliessen kann. Dazu dienen entsprechende Subkommandos. Nützlich sind folgende Kommandos zum Auslesen von Information:
Einen weiteren Pfad einer LUN zuordnen:
mkpath -l hdisk0 -p fcsi1
$ lspath -l hdisk0
Enabled hdisk0 fscsi0
Enabled hdisk0 fscsi1
0:root@gsnpap1:/root # pcmpath query device 0
DEV#: 0 DEVICE NAME: hdisk0 TYPE: 2105800 ALGORITHM: Load Balance
SERIAL: 30F27298
==========================================================================
Path# Adapter/Path Name State Mode Select Errors
0 fscsi0/path0 OPEN NORMAL 1365 0
1 fscsi1/path1 OPEN NORMAL 1301 0
[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]
Copyright 2001-2021 by Orm Hager - Es gilt die GPL