Dokumentation von Nils Goroll (MCS Cityline GmbH) - MKS 2 - Desy

¢¡¤£¦¥¨§©:Zugriff auf nicht cluster–tauglicheshared SCSI storage unter Sun 3.0 ClusterNils Goroll slink@cityline.netMCS Cityline GmbHEssener Straße 9922419 Hamburg4. April 20021 EinleitungIm Rahmen der Inbetriebnahme eines Sun Cluster 3.0 für die Kryogenik–Gruppe desDeutsches Elektronen Synchrotrons (DESY) unter Leitung von Herrn Matthias Clausenbestand die Aufgabe, ein vorhandenes Compaq SCSI RAID–Systems in den Sun Clustereinzubinden, so dass dort eingerichtete Volumes im Cluster verfügbar sind.2 Technischer HintergrundDie Einbindung des vorhandenen RAID Systems konnte hierbei nicht wie in Sun Cluster3.0 vorgesehen erfolgen, da alle Volumes des Compaq RAID Systems mit identischemSCSI–2 Vendor String und identischer SCSI–2 Seriennummer zur Verfügung gestelltwerden. Hierdurch werden alle Volumes vom Device ID Pseudo–Treiber (DID) fälschlicherweiseals unterschiedliche pysikalische Pfade zu einem Volume interpretiert.Da keine Möglichkeit bestand, das Compaq RAID System derart zu konfigurieren,dass alle Volumes mit unterschiedlichen SCSI–Seriennummern zur Verfügung gestelltwerden, um disjunkte Disk IDs sicherzustellen, musste eine vom DID Treiber unabhängigeLösung gefunden werden.Id: DESYkrym.tex,v 1.2 2002/04/04 20:26:06 slink Exp1

2.1 Failover von Volumes à la Sun Cluster 2.2Die Grundidee des Dataservice ! basiert darauf, vom Cluster benötigte Volumeswie bei Sun Cluster 2.2 zu jedem Zeitpunkt auf nur einem Clusterknoten aktivzu mounten und bei einem Clusterswitch explizit auf dem zu evakuierenden Knoten zuunmounten.Aufgrund der Inkompatibilität mit dem DID driver müssen hierzu lokale Gerätepfadewie "$#&%('"#)*"+,.-/#/)10 verwendet werden. Es wird also zwingend vorausgesetzt, dassdie verwendeten Gerätepfade zu jeder Zeit auf beiden Clusterknoten identisch sind.3 FunktionsweiseDer Dataservice ! stellt wie jeder andere Dataservice vereinfacht dargestelltnur drei Methoden zur Verfügung: Eine Start–Methode zum Starten des Dienstes (hierim Wesentlichen: mounten der Filesysteme), eine Stop–Methode zum Stoppen diesDienstes (hier: unmount) und eine Monitoring–Methode, die vom Cluster–Frameworkzur Überprüfung der korrekten Funktion des Dienstes aufgerufen wird.Wichtig ist im aktuellen Kontext, dass die wesentlichen Start– und Stop–Funktionenim prenet–start und postnet–stop script ausgeführt werden, um sicherzustellen, dassdie mounts/unmounts vor bzw. nach allen anderen Clusteroperationen stattfinden.3.1 243546728497:;4=@?BAC2EDCFHGC2=@?BACIE5>=KJBG7J6CI>LH6CME=B6NO

3.3 MonitoringDie Monitoring–Funktionen sind in "h(p-"1W !E".dBjli"1 !THjli%1-#HT.!h1iHT)*'H+qr)ls implementiert.Für alle Filesysteme in "1efh1dcf"(ib)"c(#1!Ej.ig".1tk 1!E"1'bE)l-c1d wird überprüft,ob sie gemountet sind und ob ein Testfile angelegt werden kann.Um ein korrektes Monitoring zu gewährleisten, muss der für die entsprechende resourcegroup jeweils nicht aktive Knoten die Funktion des aktiven Knotens überprüfenkönnen. Somit muss die Monitoring–Funtkionalität über TCP/IP anzusprechen sein.über einen zusätzlichenProzess realisiert, der das oben beschriebene j.ig%(-H#Monitoring–ScriptDer Einfachheit halber ist dies beim Dataservice Wtu W!(die „probe“) auf Port 9999/tcp zur Verfügung stellt. Im Service–Startscript"h1p-g"( !"1dj.ig". 1!BT).'g+T).-Hc1-tu).s wird ein inetd mit der1 entsprechenden Konfiguration("(efh(dgcf"1ibE)W"c$#1!Ej*iH"(Htk 1!B"vpgh(d%Crj*i%(-#wO+h1ib ) mittels der processmonitoring facility (pmf) gestartet.Während des stabilen Betriebs der resource group erfolgt ein periodischer Aufrufvon "h(p-"(HW W!"(dj*i". 1!ET.ph.d%Tj.i-g%(icfx)*s . Mittels dieses scripts wird geprüft,ob das script !BTj.ig%(-#&T.!h(igT).'H+Cr)ls auf dem aktiven Knoten alle Tests erfolgreichdurchgeführt hat.Bei einem cluster switch wird der inetd prozess durch"h1p-g"( !"1dj.ig". 1!BT).'g+T).-Hh1pyB)ls gestoppt.4 Implementation des Dataservice z|{~}€‚1ƒ…„…†t‡Der Dataservice wurde unter Zuhilfenahme der Standard–Entwicklungsumgebung()+#)+1%c(-H% , )+$#g)+h(ib ) implementiert. Es wurde hierbei auf separate Start–, Stop–und Monitoring–Scripts verzichtet und sämtliche Funktionalität wurde direkt in die templatesintegiert.Alle Sourcen befinden sich unter "h(p-g".!B+) auf node–a. Der Dataservice wurde alsSolaris–Package installiert.ẑ {~}€‚(ƒ‰„…†t‡ 5 Integration des Dataservice in Sun Cluster3.0Neben der standardmäßigen Integration des Dataservice in den Cluster (Installieren desPackages, Registrieren und Aktivieren des Dataservice) sind noch einige Besonderheitenzu beachten.Um den für die Implementation notwendigen Zeitaufwand in vernünftigen Grenzenzu halten, wurde auf einige Automatisierungen bei der Installation verzichtet.Im folgenden wird von dem resource group pathprefix "1efh1dcf"(ib)"c#1!Ej.i und der3

ŠŠŠŠ W! )*-%c.! -+1p ih(‘gcj*- hh1-“’#H%H).1!E"1dj.i". !BTj.i%.-H#T.!Bh.iT)l'g+qO)*s ’"h1p-"1————————Installation des Dataservice Packages unter "h1p- ausgegangen. Werden andere directoriesgewählt, sind die nachfolgend genannten Pfade entsprechend anzupassen.Vor Aktivierung des Dataservice sind folgende Arbeiten durchzuführen:Auf beiden Knoten muss die folgende Zeile zu "%(-g+"H)%('j+%) hinzugefügt werden: #H%H). W!o‹‹‹‹"(-g+(pŠ 'bE)*-c(d Wtu W!"h(p-g"(H W!E"%(-H+"('bB).-Hc(dyŒ#j)*-1!B".'bB)l-c(d "(egfh(dgcf"(ib)W"c$#$!Ej.i".HkDie für die resource muss erstellt und angepasstwerden. Hierzu muss nachcopiert und editiert werden.Die dataservicespezifische j*i%(-H#y +h(ib muss manuell angepasst werden. In dervorliegenden Konfiguration sollte sie wie folgt aufgebaut sein (nachfolgend ist dieeinzige Zeile des Files der besseren Lesbarkeit halber durch backslashes ( Ž )aufgetrennt): !ETHj.ig%(-#T*!h(igT).'+x”)ls•"1efh(dcf"1ibE)"c#1!Ej*iH"(Wtk !E".'bE)l-gc.dEin template für dieses File befindet sich in"h1p-"1 1!E"%.-+".pHh(dg%xrj.iH%1-#y +h(ibyŒ#j)*- .Die H ! resource muss bei Clusterrekonfigurationen der resource group unbedingtvor bzw. nach anderen resourcen, die die zur Verfügung gestellten mountpointsverwenden, gestartet bzw. gestoppt werden.Es muss daher sichergestellt sein, dass für alle anderen Resourcen der Gruppe,die auf die entsprechenden Filesysteme zugreifen, (direkte oder indirekte) starkeAbhängigkeiten zu der ! resource bestehen.Hier beispielhaft die entsprechende Ausgabe von )W+(ec$#$! n*p'' für eine resourceibE)n*e vom Typ W^`–tibE) wobei als Name für die tu ! resource!Eh1mi-Bn. ibB)n.g%) gewählt wurde:ibE)n.eE˜R%)šigc.!B%q›ibE)n.g%)ibB)n*et›uibB)n.%)˜R%H)œRgT$#H%H)+1Ej.p-Bjh.i›(`^žžgŸibB)n*et›uibB)n.%)˜R%H)œg%)h1mg+%v- p%C›^`–tuibE)ibB)n*et›uibB)n.%)˜R%H)œg%)h1mg+%veh(mp ic*!E%q› ibE)n.eibB)n*et›uibB)n.%)˜R%H) %1ic(dgf%#y› Xmg%ibB)n*et›uibB)n.%)˜R%H)š!Bh(iEj*-h1•%1ic(dgf%#y›Xmg%ibB)n*et›uibB)n.%)˜R%H)•)*-h1ie #H%1p%(iH#H%1i+j1%H)x› !Eh(mi-Bn. ibB)n.%)Bei der Registrierung der Resource muss als benutzte network–resource‹‹‹‹"1-+1p angegeben werden.ibB)n*et›uibB)n.%)˜R%H)œ‘g%c(•#&%(pg%(i#&%(ig+j%)>›(`^žžgŸ4

ŠŠŠJegliche Änderungen an "%(-g+"(pgc(-sT.-hTj.i)*-6 Wichtige Hinweise1. Da kein DID Treiber verwendet werden kann, muss unbedingt sichergestellt werden,dass die Hardwarekonfiguration beider Clusterknoten zu jeder Zeit identischist und weder durch Änderungen der Hardware noch durch sonstige Änderungendie logischen Devicepfade beider Knoten divergieren.Insbesondere die folgenden Situationen sollten unbedingt vermieden werden:Rekonfiguration mittels dhh(- n* nach Entfernen eines SCSI–Controllers odereinem DefektNeuaufsetzen eines Clusterknotens auf einer anderen Hardwareplattform2. Es besteht keinerlei Absicherung gegen versehentliches gleichzeitiges Mountenvon shares devices auf dem Compaq RAID von beiden Clusterknoten.Read/Write – mounts der entsprechenden Devices sollten also stets mit grösstmöglicherVorsicht vorgenommen werden, da es bei gleichzeigen Schreibzugriffenvon beiden Knoten mit großer Wahrscheinlichkeit zu Datenverlusten oder ungewolltenDatenmodifikationen kommt.5