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


9

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.

Réponses:


6

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.


1
J'ai eu le même problème avec mysql prod db assis sur le volume iscsi, avec les mêmes erreurs dans / var / log / messages et le système de fichiers étant en mode lecture seule. Cette astuce a résolu le problème.
RainDoctor

2

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.


Je pense que c'est exactement ce dont j'ai besoin.
Kamil Kisiel

0

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?


Mise à jour de la description originale avec des réponses à vos questions. Je suppose que je pourrais plutôt envisager le multichemin, mais le système est davantage adapté au basculement IP virtuel dans sa forme actuelle. Je ne sais pas comment la réplication au niveau du bloc interviendrait pour jouer avec le multichemin, d'autant plus que l'une des unités SAN doit être désignée comme maître. Merci de m'avoir indiqué la partie concernant le système de fichiers. Je pense que cela explique à peu près cela. Je suppose que je pourrais essayer de le faire passer en mode «continuer», ou peut-être envisager de changer le système de fichiers pour quelque chose de plus résilient comme XFS.
Kamil Kisiel

1
Il n'y a rien de intrinsèquement mauvais à propos d'ext3 - vous aurez des problèmes similaires avec XFS. Et je ne recommanderais pas d'utiliser onerror = continue - le système croira que le bloc est illisible et vous perdrez des données. Le multichemin n'est pas en miroir - vous n'avez pas à vous soucier de la réplication sur l'hôte. Vous vous connectez simplement via iSCSI aux cibles maître et secondaire et l'hôte sait que si le maître échoue, non pour transmettre une erreur dans la pile mais pour essayer la même commande dirigée vers la cible secondaire.
MikeyB

Mon commentaire sur la réplication concernait le fait que les deux serveurs SAN doivent synchroniser leurs données. En interne, je pense que le système fonctionne de manière similaire à drbd, l'une des unités (celle qui a actuellement le VIP) étant le maître. Cela peut fonctionner avec le multichemin, mais j'aimerais vraiment résoudre ce problème sans abandonner l'architecture actuelle. Il devrait y avoir un moyen de faire fonctionner cela autrement, mes systèmes qui montent directement des volumes iSCSI n'ont jamais de problème avec le volume en lecture seule.
Kamil Kisiel

-1

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.


2
Êtes-vous sûr de répondre à la bonne question?
Kamil Kisiel
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.