Les systèmes de fichiers racine Xen DomU deviennent en lecture seule lors du basculement IP virtuel iSCSI

Mes serveurs Xen sont openSUSE 11.1 avec open-iscsi pour notre cluster SAN iSCSI. Les modules SAN se trouvent dans un groupe de basculement IP derrière une adresse IP virtuelle à laquelle les initiateurs se connectent.

Dans le cas où le serveur SAN principal tombe en panne, le secondaire prend le rôle de servir de cible. Tout cela est géré par le logiciel LeftHand SAN / iQ et fonctionne bien dans la plupart des situations.

Le problème que j'ai est que parfois certains de mes DomU Xen verront leur système de fichiers racine passer en lecture seule après un basculement IP. Ce n'est pas cohérent et arrive à un sous-ensemble différent chaque fois qu'un basculement se produit. Ils exécutent tous la même image logicielle openSUSE 11.1.

Les systèmes de fichiers racine pour chaque DomU sont montés par open-iscsi dans le Dom0, puis Xen utilise le pilote de périphérique de bloc standard pour l'exposer à la DomU.

Le symptôme exact est qu'en tant que root en cours d'exécution touch /testrenvoie l'erreur "système de fichiers en lecture seule". Cependant, la sortie de mountmontre qu'il est monté en lecture-écriture. Bien sûr, toutes les autres E / S sur le domU échouent également en ce moment, donc la machine tombe en panne. Le redémarrage simple avec à xmpartir du Dom0 sans même reconnecter la session iSCSI fait tout fonctionner à nouveau.

Du côté Dom0, les messages syslog pendant le basculement sont quelque chose comme ceci:

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) 

J'ai du mal à déterminer à quelle couche déboguer ce problème, est-ce quelque chose dans le noyau DomU? ou au niveau Dom0 ou Xen? Je pense qu'il y a probablement un paramètre quelque part qui a besoin d'être modifié pour augmenter une sorte de délai d'attente, mais je ne sais pas où chercher.

Je ne pense pas vraiment que ce soit un problème avec open-iscsi simplement parce que le périphérique de bloc connecté est toujours lisible et inscriptible depuis le Dom0.

J'ai finalement résolu ce problème en utilisant les conseils et paramètres suivants de la documentation open-iscsi:

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

Après avoir configuré la connexion à chaque LUN comme décrit ci-dessus, le basculement fonctionne comme un charme, même si cela prend plusieurs minutes.

Cela ressemble à un problème avec l'initiateur iSCSI exécuté sur le dom0. L'initiateur ne doit pas envoyer des échecs SCSI dans la pile aussi rapidement. Vous voudrez probablement définir ConnFailTimeout dans iscsi.conf, c'est le paramètre qui détermine combien de temps avant qu'il ne considère une défaillance de connexion comme une erreur et envoie cette erreur dans la pile SCSI.

Je voudrais également savoir combien de temps prend réellement ce basculement, il peut prendre plus de temps que prévu. Si c'est le cas, le basculement VIP prend peut-être trop de temps en raison de problèmes liés à ARP.

Y a-t-il des messages dans dom0 indiquant des erreurs de lecture / écriture ou des erreurs scsi au moment du basculement? Si c'est le cas, il semble que cette erreur d'écriture soit transmise au domU. Le domU ne "sait" pas qu'il s'agit d'un périphérique iSCSI, il se comporte donc comme si le disque sous-jacent avait disparu et remonte le système de fichiers en lecture seule (voir la page de manuel mount (1) - errors=continue / errors=remount-ro / errors=panic)

Du point de vue de dom0, il ne sera pas modifié en lecture seule - ce comportement en lecture seule est une sémantique de système de fichiers, pas une sémantique de périphérique de bloc.

Vous mentionnez que "toutes les autres E / S échouent" en ce moment - voulez-vous dire le domU ou le dom0?

Habituellement, lors de la configuration d'une solution HA iSCSI, j'utilise le multichemin plutôt que la prise de contrôle IP virtuelle - cela permet une plus grande visibilité à l'hôte et vous n'avez pas de session iSCSI disparaître soudainement alors qu'il faut la redémarrer - elle est toujours là, il n'y en a que deux . Est-ce une option dans cet environnement?

Um ... Une partie du problème est aussi que vous ne courez pas / en tant que RO. Les meilleures pratiques en matière de sécurité indiquent que vous devez avoir monté "/" ro, et que tous les systèmes de fichiers qui ont besoin de rw doivent être montés séparément, (par exemple, / var et / tmp). S'il y a des répertoires sous / etc qui nécessitent une écriture, ils doivent être déplacés vers / var / etc / path et liés par un lien symbolique vers / etc.

"/" ne doit être monté RW qu'en mode mono-utilisateur.

Une configuration de cette manière pourrait empêcher le défaut de configuration dans la situation ci-dessus lorsqu'elle est combinée avec les autres suggestions.