O Ubuntu 14.04 com a montagem FSTAB do armazenamento de arquivos do Azure cai após algum tempo

Question

Eu tenho um servidor Ubuntu 14.04 que possui uma montagem de armazenamento de arquivos do Azure que é montada automaticamente na inicialização por meio de um FSTAb. Para criar essa configuração, segui as instruções neste documento artigo e funciona bem.

A questão que estou tendo é depois de um tempo, intermitentemente, a montagem cai. Não parece ser em nenhum momento específico, ou evento, a única maneira que eu sei que se foi é a reclamação do usuário de que eles não podem fazer upload de arquivos (o aplicativo persiste os arquivos na montagem de arquivos do Azure). Se eu tentar cd para o mount, meu console simplesmente trava .. se eu tentar fazer um df -h listar tudo, o console também trava. A única maneira de fazer as coisas voltarem ao normal é se eu reiniciar o servidor e tudo correr bem novamente.

Suspeito que a conexão com o armazenamento de arquivos do Azure pode estar caindo e voltando de forma intermitente, mas talvez o servidor simplesmente não esteja remontando quando estiver disponível novamente? Eu tenho alguns outros servidores (Windows) conectados ao mesmo compartilhamento de arquivos e eu não tenho esse problema, até agora. Alguém mais passou por isso, e há talvez uma configuração que eu possa fazer para remontar o compartilhamento automaticamente se ele ficar indisponível?

Qualquer sugestão seria muito apreciada!

    

Answer 1

Parece que resolvi esse problema usando o AutoFS para montar o compartilhamento em vez de fstab. Depois de fazer a alteração, não encontramos o problema originalmente relatado. Alguns dias depois que fizemos a alteração, recebi uma resposta da Microsoft afirmando que esse é um problema conhecido (c / p da mensagem abaixo). A sugestão do AutoFS ou da Microsoft deve ser uma solução viável para esse problema.

Our engineers have provided the following feedback for you:

This error occurs with the Linux driver re-connects to a share when the client has been idle for an extended period of time. It disconnects and the client connection times out.

•Client is idle for an extended period of time. The Linux client sends ECHO commands periodically to keep the connection alive. •The TCP connection gets disconnected for some reason (e.g. node goes for software roll out). •The Linux client makes a new TCP connection to port 445 but sends nothing on that connection.
•After 60 seconds of idle time, SLB drops the TCP connection. •After some time, the Linux app tries to access a file and Linux sends NEGOTIATE packet which is black-holed by SLB. •The Linux client waits for 15 minutes for the TCP timeout.

Until we get a fix for this from the Linux developers the suggested workaround is to periodically access the share.

Workaround: Keep a file in the Azure File share that you write to periodically to sustain the connection and avoid getting into an idle state. This has to be write operation such as, rewriting the created/modified date on the file, otherwise you might get cached results and your operation might not trigger the connection.