Re: Shutdown-Reihenfolge
Am 7. September 2011 10:49 schrieb Michael Weber
<michael.weber@fh-stralsund.de>:
> Guten Morgen Matthias,
Hallo Michael,
> zunächst einmal herzlichen Dank für deine Antwort. Ich war so frei und habe
> deine Ausführungen getestet und bin an der Stelle leider in eine Menge
> Fehler gerasselt.
>
> Das System wurde in den Urzustand zurück gesetzt und dein Hinweis in die
> besagte Datei eingetragen.
>
>> # Required-Start: mountkernfs open-iscsi
>> # Required-Stop: mountkernfs open-iscsi
>
> Folglich ist durch Anwendung von insserv die Reihenfolge komplett geändert
> worden. Sieht soweit auch gut aus.
>
> Aber und jetzt kommts. Ich möchte, dass für das Raid ein Filesystemcheck
> gemacht wird. Grund hierfür ist einfach, dass darauf brisante Daten liegen.
> Dummerweise wird der Filesystemcheck (ich vermute mal checkfs.sh) vor dem
> Laden von open-iscsi gemacht. Ich muss dazu sagen, dass ich in der Datei
> fstab den Mounteintrag gemacht habe.
>
> Ich war so frei und habe für die Datei checkfs.sh ein Override angelegt und
> gesagt, dass vor dem Check mdadm-raid gestartet sein soll. Diesem Wunsch
> wurde jedoch nicht entsprochen und die Fehlermeldung erscheint, dass dadurch
> mehrere Loops erzeugt werden.
Der Loop ensteht durch meine vorgeschlagene Änderung für das Starten
von mdadm-raid als abhängig von open-iscsi und durch die von Dir mit
den overrides eingestellte Abhängigkeit:
checkfs -> mdam-raid -> iscsi|open-iscsi -> $remote_fs -> $local_fs ->
mountall -> checkfs
> Neben diesem kleinen Problem kann der Mount des Raids auch nicht klappen,
> weil die Reihenfolge nicht bedacht wurde. Ich vermute mal, dass mountall.sh
> das übernimmt. Zumindest startet dieses Skript bedeutend früher als
> mdadm.raid, wodurch dummerweise für den Mount kein Raid vorhanden ist.
> Lösung von mir wäre eine ganz einfache. Ich habe einfach den Mount aus der
> fstab raus genommen und in rc.local eingetragen. Dem schließt sich sogleich
> noch der manuelle Start von Postgres danach an (auch in der rc.local). Oder
> man schraubt den LSB-Header richtig.
Da finde ich die Lösung mit /etc/rc.local ganz gut, denn wenn man
mountall als abhängig von mdadm-raid einträgt und meine Änderung
(mdam-raid -> iscsi|open-iscsi) bestehen lässt, dann entsteht auch
bloß wieder ein Loop:
mdam-raid -> iscsi|open-iscsi -> $remote_fs -> $local_fs -> mountall
-> mdadm-raid
Wenn man mountall als abhängig von mdadm-raid einträgt und meine
Änderung (mdam-raid -> iscsi|open-iscsi) entfernt, dann entsteht zwar
kein Loop
mountall -> mdadm-raid -> udev -> mountkernfs
aber open-iscsi wird erst nach mountall gestartet, denn die
Abhängigkeiten sind so:
iscsi|open-iscsi -> $remote_fs -> $local_fs -> mountall
Geht also auch nicht.
> Weiterhin besteht das Problem beim Start, dass das Raid gelegentlich mal vom
> Zustand her "resync=pending" ist. Dann muss man manuell ein "readwrite"
> darauf loslassen und folglich wird das Raid von neuem gesynct. Wenn ich dann
> darüber nachdenke, dass darauf das Datenverzeichnis von PostgreSQL ist, werd
> ich ein wenig nervös.
Idee:
Wenn das RAID eine Sonderbehandlung benötigt, dann definiere Dir doch
ein init-script, welches beim Starten:
- diese Sonderbehandlung des RAIDs durchführt
- evtl. einen fsck durchführt
- das RAID-Device mounted
- und letztendlich die Datenbank startet
Die von mir vorgeschlagene Abhängigkeit (mdam-raid ->
iscsi|open-iscsi) bleibt und dieses Script wird für den Start abhängig
von mdadm-raid.
> Weiterhin besteht das Problem beim Stop bzw. Neustart, dass unter deiner
> Konstellation die Reihenfolge zwar richtig ist. Jedoch erfolgt der Unmount
> vom Raid unter umountfs (wenn ich die Fehlermeldung richtig deute) und
> zusätzlich dazu gibts ne hässliche Fehlermeldung, dass ein logischer Block
> vom Raid defekt ist. Dummerweise ist zu diesem Zeitpunkt aber schon das Raid
> gestoppt (zumindest versucht, klappt aber nicht, weil es gemountet ist) und
> leider schon die LUNs entzogen, weil open-iscsi schon beendet wurde. In der
> Hoffnung, es richtig zu deuten, versucht das System etwas zu unmounten, was
> faktisch eigentlich gar nicht mehr existent ist.
> Und wenn man dann das System wieder startet, muss das Raid abermals gesynct
> werden und die Fehlermeldung "resync=pending" besteht (siehe oben).
>
> Daher müsste man an dieser Stelle aus meiner Sicht noch ein Unmount speziell
> für das Raid machen und dann deine Reihenfolge belassen. Zudem wäre es
> ratsam, eine Pause zwischen mdadm-raid und open-iscsi einzulegen. Ich hatte
> halt das Problem, dass das erste von beiden zu langsam ist.
Das selbe script führt beim Stoppen aus:
- Datenbank beenden
- das RAID-Device unmounten
- Pause einlegen
Dieses Script wird auch für den Stop abhängig von mdadm-raid.
Die LSB Init Info könnte also so aussehen:
## BEGIN INIT INFO
# Provides: mount-md-iscsi
# Required-Start: mdadm-raid
# Required-Stop: mdadm-raid
# Default-Start: S
# Default-Stop: 0 6
# Short-Description: Startet und stoppt die Datenbank und hängt das
md-Device (iscsi) entsprechend ein und aus
### END INIT INFO
Dieses neu zu erstellende init-script hätte den Vorteil, dass es beim
Booten und beim Shutdown/Reboot entsprechend den Angaben in der LSB
Init Info ausgeführt wird, während /etc/rc.local nur beim Starten des
Rechners ausgeführt wird.
> Alles in allem behaupte ich jetzt einfach mal, dass einige Abhängigkeiten
> nicht sauber durchdacht sind und wir wirklich nen Bug-Report machen sollten.
Hmm, ich warte mal noch. Da ich keine iSCSI-Targets habe, kann ich das
Verhalten nicht nachstellen. Alles hier empfohlene ist blanke Theorie.
Wenn es eine Lösung gibt, die beinhaltet, dass die LSB Init Info in
einem Paket angepasst werden solllte, dann erst würde ich einen
Bugreport schreiben.
> Zumindest habe ich die zuvor beschriebenen Sachen live erlebt und erlebe sie
> aktuell gerade wieder. Oder ich raff es einfach nicht mehr :-).
Ich bin mir auch nicht sicher, ob dieser ganze Aufwand wirklich
notwendig ist, oder ob es nicht vielleicht schon eine fertige, eine
"debianisierte", Lösung gibt. Denn das ist mir schon öfter so
gegangen, dass ich ein Problem mit eigenen Scripten lösen wollte, was
aber die Debian-Entwickler auf ihre, teilweise nicht unkomplexe Art
;-) , gelöst hatten.
Und was mir nicht in den Kopf will: Ein Dateisystem auf einem md auf
iSCSI-initiatoren ist doch nun wirklich nichts exotisches!?
Hat das einer von euch im Einsatz?
Wenn ja: wie ist bei euch der Ablauf?
> Gruß
> Michael
>
> @Matthias: Ich bin jetzt einfach mal frech und frage ob Du aus der Region
> UER stammst? Weil eine Person mit deinem Namen in meine Klasse ging.
Nein, ich habe nichts mit UER zu tun, nicht mal Verwandschaft dort.
Und mein Nachname ist nicht so selten, und mein Vorname doch auch nicht....
Gruß!
Matthias
Reply to: