Discussion :

[jhfra]

Hello,

J'ai une petite question sur SLES11 (car je sais qu'en SLES10, c'est sans appel).

Admettons que j'ai une petite lun (en iscsi) derrière mon serveur, que, par erreur, j'arrache ma lun (considérons par exemple que j'arrête mon serveur de stockage) sans au préalable supprimer proprement la visibilité de la lun d'un point de vue système.

Que va-t-il se passer ? J'aurai plein d'i/o error, car mon OS cherchera à joindre un disque qui n'existe plus, le multipathing râlera tout ce qu'il peut etc..

La seule solution que je vois à un retour à la normale, c'est la suppression du lun via une commande multipath :
multipathd -k'rem map 3 <monlunid>'

Mais la plupart du temps, cette commande me renvoie un beau "failed", je suis donc bon pour redémarrer mon serveur..

Comme pourrais-je faire pour éviter ce reboot en nettoyant correctement toutes traces de ce disque précédemment arraché ?

[frp31]

Sur le principe (ne connaissant plus trop SUSE)...

Tu vas avoir un certains nombre de processus qui vont continuer de tenter de lire/écrire sur les médias concernés.

Ceux ci seront facile à identifier et donc tu pourras les ralentir en priorité, ce qui laisse le système ne plus les utiliser ou presque le temps ainsi gagné au profit des processus qui fonctionnent, limitent donc les I/O errors qui vont effectivement se produire.

Pourquoi ralentir ces processus ? pour avoir du temps actif sur les autres processus, pour ne pas saturer les CPU et la RAM à gerer de l'I/Oerror... et donc ne pas ralentir et meme faire planter les processus qui fonctionnent... Ca permet de gagner du temps sur la progressive saturation disque par les logs d'erreur par exemple....

Tout ça permet donc de gerer l'incident... et d'avoir le temps de stopper proprement les processus, de manager les disques, eventuellement si les disques sont utilisés par des services, dans une prod par exemple, ça permet de programmer une commande d'extraction des LUN concernés pendant la sauvegarde à froid de la nuit par exemple... ou de prendre toute autre décision de correction ne demandant pas un reboot immédiat du serveur....

typiquement, la methode est donc
-analyse
-assurer que les logs d'I/O erreurs vont pas saturer des disques...
-ralentir les processus ou les tuer proprement, et stopper les services connus pour utiliser les volumes qui posent problème...
-prevenir le downtime du service si des utilisateurs sont derriere... ou plus propre encore le planifier à plus tard....pour qu'eux s'organisent et ne pas donc perturber la prod...
-mesures préventives (desactivation soft etc...) contournements software du probleme comme un script qui va intercepter les acces disques (fake partitions avec des liens par exemple)
desactiver les medias en erreur... tout ca peut se faire dans la periode de downtime plannifie, mais aussi en avance de phase selon la configuration de ton systeme
-demarrer tout ce qui peu l'etre (si le probleme est bien etudié en principe tout)
-plannifier le prochain reboot (pas forcement dans le semestre...)
selon les effets de bords... aucun effet de bords = attendre...effets de bords qui ont un cout humain/financier/chronophage/etc.... = court terme

-------------

bref reste dans ton cas, le problème de ta commande qui fail...à part corriger le bug en avance de phase et la lancer et plannfier le reboot pour passer d'un mode degradé à un mode normal.... rien à faire ...

il faut que tu trouves pourquoi ta suppression échoue... peut être d'ailleurs que c'est une erreur de méthode genre il faut passer une autre commande pour FLAGguer le statut comme dégradé pour avoir le droit de supprimer... ou une connerie du genre...

[jhfra]

Merci pour ta réponse

Je vais faire plusieurs tests sur un hyperviseur de test, déjà en baissant la priorité de ces process (et voire au préalable pour les identifier).

Je reviendrai faire un petit compte rendu !