Situation horrible - systèmes de fichiers montés simultanément par plusieurs instances de système d'exploitation indépendantes


14

Comment sortir de cette situation en toute sécurité?

Les détails sont les suivants:

Un serveur xen a des périphériques de bloc alloués aux machines virtuelles. Mais ces appareils ont également été montés à l'intérieur de Xen.

En fait, 44 de ces dispositifs à blocs ont été montés comme ceci. Pour aggraver les choses, chaque périphérique physique est vu sur 4 chemins et chacun d'entre eux est monté sur un point de montage séparé. En d'autres termes, les appareils sont en fait montés 5 fois chacun.

Le système d'exploitation invité VM voit le chemin via un pseudo périphérique PowerPath (alloué en tant que périphérique phy: block au domU)

Certains appareils sont formatés en ext2 et reiserfs.

Pas besoin de m'expliquer les risques de corruption du système de fichiers impliqués ici.

Je crains que même le simple démontage des systèmes de fichiers puisse entraîner une corruption et je pense qu'à ce stade, couper l'alimentation de l'hôte est l'option la plus sûre .

Notez que les applications, les bases de données Oracle pour la plupart, dans toutes les machines virtuelles sont toujours en cours d'exécution et en cours d'utilisation.

J'ai découvert cela en étudiant une utilisation élevée du processeur sur le dom0. Il existe un processus de "recherche" impossible à éliminer, avec cwd -> / media / disk-12 qui est monté à partir de / dev / sdf1, qui appartient à / dev / emcpowerr

Avant que quiconque ne le demande, la seule fois où j'ai vu des processus ne peut pas être tué et continuer à utiliser le CPU et la RAM (contrairement à un processus défunt / zombie), c'est quand il y a des E / S validées en attente, par exemple une synchronisation retournée mais pas encore physiquement sur le disque . Le plus souvent, cela se produit sur les E / S de bande.

Suggestions!?

PS Je me serais attendu à ce que les appareils soient "réservés" une fois montés, pour éviter ce genre de chose? Ou n'est-ce pas possible sous Linux?

EDIT: Tout d'abord, je suis convaincu que KDE au sein de l'hyperviseur) est le coupable. Il semble que KDE monte les périphériques qu'il peut lors de la journalisation pour créer des icônes de bureau. La même chose ne se produit cependant pas sur les autres serveurs Xen, mais tous les autres serveurs exécutent une version beaucoup plus ancienne de SLES et KDE ... V4 semble être la version incriminée, la 3.4 se comportant mieux).

De plus, deux machines virtuelles non critiques ont été bloquées. Après les avoir arrêtés, ils ne redémarreraient pas en raison d'une corruption du système de fichiers. La machine virtuelle principale / de production est toujours en cours d'exécution et la base de données sur elle fonctionne toujours, mais il s'agit clairement d'une bombe à retardement. Le client tente de reconstruire l'environnement sur une autre machine virtuelle sur un autre serveur mais est bloqué par des problèmes de configuration de certains composants, nous attendons donc ...

En tout cas, j'estime qu'aucune des réponses n'a jusqu'à présent été plus que "les meilleures pratiques sont toujours fermées gracieusement" et j'espère obtenir quelque chose de plus concret ... En tout cas, j'estime que cette situation mérite une attention en pensant. L'arrêt entraînera-t-il la synchronisation des E / S en cours, en particulier les mises à jour des métadonnées du système de fichiers de l'hyperviseur, et entraînera-t-il une corruption potentiellement majeure du système de fichiers?


1
Et en ce moment, toutes les sauvegardes effectuées avant «l'arrêt» peuvent simplement sauvegarder des données corrompues, bien que dans cette situation, il est plus probable que les métadonnées du système de fichiers soient corrompues, plutôt que le contenu du fichier.
Johan

Je crains que vous ne perdiez au moins une partie des données de toute façon. La désactivation physique de l'hôte ou l'arrêt forcé des machines virtuelles peut avoir pour conséquence indésirable de tout gâcher (c'est-à-dire même les systèmes de fichiers qui ne sont montés qu'une seule fois). J'essaierais probablement de tout terminer aussi proprement que possible pour minimiser les pertes. Et bien sûr, s'assurer que cela ne se reproduise plus.
peterph

Quant à l'empêcher, IIUC vous pouvez essayer de définir des autorisations sur le périphérique dans dom0 une fois qu'il est ouvert par l'invité, mais comme les autorisations fs (sur les fichiers du périphérique) peuvent être croisées par root (sauf si vous avez un noyau patché), cela peut pas besoin d'aider.
peterph

1
Concernant votre post-script: si les périphériques sont visibles via plusieurs chemins, le noyau ne sait probablement même pas qu'ils sont tous le même périphérique, alors comment pourrait-il le "réserver"? Quant à l'exportation d'un périphérique de dom0 vers plusieurs domU, il vous permet de le faire car vous voudrez peut-être le faire exprès (par exemple avec un système de fichiers qui le prend en charge, ou monté en lecture seule partout).
Celada

@Celada J'ai pensé éviter cela, mais il existe des moyens de "verrouiller" les périphériques: PowerPath devrait (fait dans le cas de Solaris) réserver tous les chemins parent d'un périphérique (au moment de son initialisation). De plus, les commandes de «réserve» SCSI sont gérées par le périphérique cible. Ainsi, une fois qu'une cible est réservée, elle doit refuser d'autoriser une réserve sur l'un des chemins de ce périphérique. C'est du moins ma compréhension limitée.
Johan

Réponses:


2

Si les disques sont en cours d'écriture à partir d'un seul point de montage, aucun dommage n'est fait. Faites un arrêt propre, (sauvegardez-le de l'état suspendu si vous voulez) réparez les supports. N'exécutez rien d'autre que les applications nues nécessaires sur le Dom0. Si, OTOH, les partitions sont écrites à partir de plusieurs chemins, c'est MAUVAIS et empire par la seconde. Débrancher.


0

Je n'ai aucune raison concrète mais mon intuition me dit que ce qui suit peut être la meilleure approche:

  1. Fermez les applications.
  2. Copiez toutes les données de la machine virtuelle via le réseau vers un emplacement de sauvegarde.
  3. Démontez les systèmes de fichiers depuis la machine virtuelle.
  4. Arrêtez la machine virtuelle. (Il n'y a qu'une seule machine virtuelle en cours d'exécution sur cet hôte maintenant).
  5. Assurez-vous qu'aucun domU n'est configuré pour démarrer automatiquement.
  6. Coupez l'alimentation de l'hôte pour empêcher l'hyperviseur d'effectuer des actions de «fermeture», de synchronisation des E / S en attente, etc.
  7. Démarrez la machine virtuelle, en espérant que l'hyperviseur lui-même ait survécu au coup sec.
  8. En cas d'échec, reconstruisez l'environnement. (Les disques de démarrage des VM sont basés sur des fichiers, mais les points de montage des données résident sur un disque externe alloué en tant que périphériques de bloc)
  9. Vérifiez si l'hyperviseur monte des systèmes de fichiers appartenant aux domU. Démontez-les avant de démarrer les domU)
  10. Désactivez le montage automatique de KDE.
  11. Démarrez la machine virtuelle et forcez une vérification FS complète.

Alternative à 11: démarrez la machine virtuelle et montez les systèmes de fichiers sans fsck complet.

Le raisonnement est que je ne veux pas que l'hyperviseur Xen ait plus de chance qu'absolument nécessaire pour provoquer la corruption sur les systèmes de fichiers domU.


0

Je ne suis pas un expert Xen et je n'avais encore aucune expérience avec cela. Mais mon approche si j'étais à votre place serait: d'abord je sais que je pourrais perdre des données (peut-être même toutes); Deuxièmement, j'essayais de créer des instantanés, puis de suspendre les machines virtuelles, en les restaurant dans un environnement différent et sûr.
Je ne veux pas vous donner de faux espoirs, mais je pense que vous aurez de la chance si vous pouvez récupérer quoi que ce soit.

Attention : suivre ces conseils pourrait vous faire perdre toutes les données. C'est à vous de voir si cela vaut le risque ou non.

Avec beaucoup de chance, vos applications fonctionnent toujours car les données qu'elles utilisent sont toutes en mémoire volatile. Vous devriez essayer de tirer parti de cette situation (essayez d'évaluer si cela pourrait être le cas par application) et d'exporter les données en direct vers un partage réseau si les applications offrent une telle fonctionnalité. Si des données se trouvent sur le disque, cette fonction d'exportation peut être "verrouillée" un peu comme votre findinstruction ou planter (et planter l'application ou le système d'exploitation) en raison des données de disque modifiées / corrompues.

Ensuite, vous pouvez essayer de créer un instantané en direct, selon les instructions de l'article suivant: Création d'instantanés dans Xen . J'irais pour l'instantané octet par octet, bien qu'il puisse se coincer un peu comme votre findcommande ... Cependant, je ne donnerais pas autant d'espoir.

Avant d'exécuter la commande précédente, vous devez lire ce document de Citrix qui vous aide à comprendre les instantanés dans Xen (PDF) .

Je te souhaite bonne chance.


Je vous remercie. Le client a une exportation de la base de données. Je pense qu'ils ont juste utilisé FTP pour le retirer de la machine virtuelle, mais il est possible de monter un partage réseau et d'exporter directement vers cela.
Johan

J'ai joué avec l'idée de suspendre la machine virtuelle, puis de prendre une copie complète sur un autre hôte, puis d'essayer de a) la reprendre à partir du sommeil, ou b) la démarrer, suivie d'un redémarrage et de fsck. L'idée est que puisque j'ai toujours la VM suspendue sur l'hôte d'origine, je pourrai peut-être reprendre celle-ci si la copie ne fonctionne pas sur l'autre hôte.
Johan

De plus, le problème avec le retour à une sauvegarde est que l'on craint que toutes les sauvegardes effectuées au cours des deux derniers mois soient corrompues.
Johan

@Johan c'est plus que probablement vrai, la plupart sinon toutes les sauvegardes (puisque le problème est survenu) sont probablement corrompues. La même chose peut être vraie pour l'exportation de la base de données. Bonne chance encore, vous en aurez besoin!
Huygens
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.