Xen DomU-Root-Dateisysteme werden beim virtuellen IP-Failover von iSCSI schreibgeschützt

Meine Xen-Server sind openSUSE 11.1 mit open-iscsi für unseren iSCSI-SAN-Cluster. Die SAN-Module befinden sich in einer IP-Failover-Gruppe hinter einer virtuellen IP, mit der die Initiatoren eine Verbindung herstellen.

Für den Fall, dass der primäre SAN-Server ausfällt, übernimmt der sekundäre Server die Rolle des Ziels. Dies alles wird von der LeftHand SAN / iQ-Software erledigt und funktioniert in den meisten Situationen gut.

Das Problem, das ich habe, ist, dass gelegentlich bei einigen meiner Xen-DomUs das Root-Dateisystem nach einem IP-Failover schreibgeschützt ist. Es ist nicht konsistent und passiert bei jedem Failover mit einer anderen Teilmenge. Sie führen alle dasselbe openSUSE 11.1-Software-Image aus.

Die Root-Dateisysteme für jede DomU werden von open-iscsi in Dom0 bereitgestellt, und Xen verwendet den Standard-Blockgerätetreiber, um sie für die DomU verfügbar zu machen.

Das genaue Symptom ist, dass als Root beim Ausführen touch /testder Fehler "Nur-Lese-Dateisystem" zurückgegeben wird. Die Ausgabe von mountzeigt es jedoch als gemountet mit Lese- / Schreibzugriff an. Natürlich fallen zu diesem Zeitpunkt auch alle anderen E / A auf der domU aus, sodass die Maschine schwer ausfällt. xmWenn Sie es einfach von Dom0 aus neu starten, ohne die iSCSI-Sitzung erneut zu verbinden, funktioniert alles wieder.

Auf der Dom0-Seite sind die Syslog-Nachrichten während des Failovers ungefähr wie folgt:

kernel: connection1:0: iscsi: detected conn error (1011)
iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
iscsid: connection1:0 is operational after recovery (1 attempts) 

Es fällt mir schwer herauszufinden, auf welcher Ebene dieses Problem behoben werden kann. Ist es etwas im DomU-Kernel? oder auf Dom0- oder Xen-Ebene? Ich denke, es gibt wahrscheinlich irgendwo einen Parameter, der angepasst werden muss, um eine Zeitüberschreitung zu erhöhen, aber ich bin mir nicht sicher, wo ich suchen soll.

Ich denke nicht wirklich, dass es ein Problem mit open-iscsi ist, nur weil das angeschlossene Blockgerät immer noch vom Dom0 aus lesbar und beschreibbar ist.

Ich habe dieses Problem schließlich mithilfe der folgenden Ratschläge und Einstellungen aus der open-iscsi-Dokumentation gelöst:

8.2 iSCSI settings for iSCSI root
---------------------------------

When accessing the root parition directly through a iSCSI disk, the
iSCSI timers should be set so that iSCSI layer has several chances to try to
re-establish a session and so that commands are not quickly requeued to
the SCSI layer. Basically you want the opposite of when using dm-multipath.

For this setup, you can turn off iSCSI pings by setting:

node.conn[0].timeo.noop_out_interval = 0
node.conn[0].timeo.noop_out_timeout = 0

And you can turn the replacement_timer to a very long value:

node.session.timeo.replacement_timeout = 86400

Nach dem Einrichten der Verbindung zu jeder LUN wie oben beschrieben funktioniert das Failover wie ein Zauber, selbst wenn es einige Minuten dauert.

Dies klingt nach einem Problem mit dem iSCSI-Initiator, der auf dom0 ausgeführt wird. Der Initiator sollte SCSI-Fehler nicht so schnell über den Stapel senden. Möglicherweise möchten Sie ConnFailTimeout in iscsi.conf festlegen. Diese Einstellung bestimmt, wie lange es dauert, bis ein Verbindungsfehler als Fehler betrachtet wird, und sendet diesen Fehler an den SCSI-Stapel.

Ich würde auch untersuchen, wie lange das Failover tatsächlich dauert. Es kann länger dauern, als Sie erwarten. In diesem Fall dauert das VIP-Failover aufgrund von ARP-Problemen möglicherweise zu lange.

Gibt es in dom0 Meldungen, die auf Lese- / Schreibfehler oder SCSI-Fehler zum Zeitpunkt des Failovers hinweisen? Wenn ja, sieht es so aus, als würde dieser Schreibfehler an die domU übergeben. Die domU "weiß" nicht, dass es sich um ein iSCSI-Gerät handelt, und verhält sich daher so, als ob die zugrunde liegende Festplatte verschwunden wäre und das schreibgeschützte Dateisystem erneut bereitgestellt würde (siehe Manpage mount (1) - errors=continue / errors=remount-ro / errors=panic).

Aus der Sicht von dom0 wird es nicht in schreibgeschützt geändert - dieses schreibgeschützte Verhalten ist eine Dateisystemsemantik, keine Blockgerätsemantik.

Sie erwähnen, dass derzeit "alle anderen E / A fehlschlagen" - meinen Sie die domU oder dom0?

Normalerweise verwende ich beim Einrichten einer HA-iSCSI-Lösung Multipathing anstelle einer virtuellen IP-Übernahme - dies ermöglicht eine bessere Sichtbarkeit für den Host und Sie haben keine iSCSI-Sitzung, die plötzlich verschwindet und neu gestartet werden muss - es ist immer da, es gibt nur zwei davon . Ist dies eine Option in dieser Umgebung?

Ähm ... Ein Teil des Problems ist auch, dass Sie nicht / als RO laufen. Aus Sicherheitsgründen sollten Sie "/" ro gemountet haben und alle Dateisysteme, die rw benötigen, separat mounten (dh / var und / tmp). Wenn sich unter / etc Verzeichnisse befinden, in die geschrieben werden muss, sollten diese nach / var / etc / path verschoben und mit / etc verknüpft werden.

"/" sollte nur im Einzelbenutzermodus RW montiert werden.

Eine Einrichtung auf diese Weise könnte den Segfault in der obigen Situation verhindern, wenn er mit den anderen Vorschlägen kombiniert wird.