3 votes

Ubuntu 14.04 avec Azure File Storage Le montage FSTAB tombe après un certain temps

J'ai un serveur Ubuntu 14.04 qui a un montage Azure File Storage qui se monte automatiquement au démarrage via un FSTAb. Pour créer cette configuration, J'ai suivi les instructions de cet article et cela fonctionne bien.

Le problème que j'ai est qu'après un certain temps, par intermittence, la monture tombe. Il ne semble pas que ce soit à un moment précis ou lors d'un événement particulier, la seule façon de savoir qu'il est parti est que les utilisateurs se plaignent qu'ils ne peuvent pas télécharger de fichiers (l'application persiste les fichiers sur le montage de fichiers Azure). Si j'essaie d'accéder au montage, ma console se bloque. Si j'essaie de faire un df -h pour tout lister, la console se bloque également. Le seul moyen de rétablir la situation est de redémarrer le serveur, après quoi tout rentre dans l'ordre.

Je soupçonne que la connexion au stockage de fichiers d'Azure s'interrompt et se rétablit par intermittence, mais peut-être que le serveur ne remonte pas les fichiers lorsqu'ils sont à nouveau disponibles ? J'ai quelques autres serveurs (Windows) connectés au même partage de fichiers et je n'ai pas rencontré ce problème, jusqu'à présent. Quelqu'un d'autre a-t-il rencontré ce problème, et y a-t-il une configuration que je puisse faire pour remonter automatiquement le partage s'il devient indisponible ?

Toute suggestion serait grandement appréciée !

0 votes

Les journaux de votre système devraient contenir des informations qui vous aideront à identifier la cause. Avez-vous vérifié ? Par ailleurs, qu'a dit le support Azure ?

0 votes

Merci, j'ai vérifié les journaux du système en essayant de trouver quelque chose qui se rapporte à mount ou quelque chose qui fait référence au chemin de la carte mais je n'ai rien trouvé. J'ai regardé dans /var/log/dmesg et /var/log/syslog En ce qui concerne Azure, je n'ai pas encore ouvert de ticket car je voulais voir si c'était quelque chose dont je pouvais m'occuper d'abord.

0 votes

@Sharbel avez-vous déjà trouvé une solution à ce problème ? Il semble que nous rencontrions la même chose :) thx

2voto

Daphna Shezaf Points 2124

Il me semble avoir résolu ce problème en utilisant AutoFS pour monter le partage au lieu de fstab. Après avoir effectué ce changement, nous n'avons plus rencontré le problème signalé à l'origine. Quelques jours après avoir effectué ce changement, j'ai reçu une réponse de Microsoft indiquant qu'il s'agissait d'un problème connu (voir le message ci-dessous). AutoFS ou la suggestion de Microsoft devrait être une solution de contournement viable pour ce problème.

Nos ingénieurs ont fourni les commentaires suivants pour vous :

Cette erreur se produit lorsque le pilote Linux se reconnecte à un partage lorsque le client est resté inactif pendant une longue période. Il se déconnecte et la connexion du client est interrompue.

-Le client est inactif pendant une longue période de temps. Le client Linux envoie périodiquement des commandes ECHO pour maintenir la connexion en vie. -La connexion TCP est déconnectée pour une raison quelconque (par exemple, le nœud fait l'objet d'un déploiement de logiciel). -Le client Linux établit une nouvelle connexion TCP au port 445 mais n'envoie rien sur cette connexion.
-Après 60 secondes d'inactivité, SLB interrompt la connexion TCP. -Après un certain temps, l'application Linux essaie d'accéder à un fichier et Linux envoie un paquet NEGOTIATE qui est bloqué par SLB. -Le client Linux attend 15 minutes pour le délai d'attente TCP.

Jusqu'à ce que nous obtenions un correctif de la part des développeurs Linux, la solution suggérée est d'accéder périodiquement au partage.

Solution de contournement : Conservez un fichier dans le partage de fichiers Azure dans lequel vous écrivez périodiquement pour maintenir la connexion et éviter de se retrouver dans un état d'inactivité. Il doit s'agir d'une opération d'écriture, telle que la réécriture de la date de création/modification du fichier, sinon vous risquez d'obtenir des résultats en cache et votre opération pourrait ne pas déclencher la connexion.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X