Qual é o tempo razoável de failover de armazenamento que a maioria do sistema operacional (VM) pode tolerar?

Question

Eu tenho uma configuração de réplica do GlusterFS 2 node 2. Estou planejando usá-lo como o armazenamento de instâncias do OpenStack, no qual a imagem de disco da VM é armazenada.

Em meus testes, se o nó do GlusterFS no qual o hipervisor atualmente é instalado falhar (usando as configurações padrão do GlusterFS), ele leva cerca de 45 segundos para a conexão expirar e o cliente glusterfs faz o failover para o outro nó. Durante esse período de 45 segundos, as operações de E / S serão interrompidas, do ponto de vista da VM, o que significa que o disco não responde.

Sei que para o Linux, se o disco não responder, após algum tempo (não sei quanto tempo) o kernel irá remontar o sistema de arquivos como somente leitura.

Eu também posso diminuir o valor do network.ping-timeout do volume do GlusterFS, o que reduzirá o tempo de failover.

Minha pergunta é, quanto devo definir esse valor para que a maioria dos sistemas operacionais possa tolerar o tempo sem resposta do disco virtual sem efeitos colaterais?

Para ser mais preciso, gostaria de saber o tempo de não resposta do disco que o Windows NTFS, o FreeBSD UFS / ZFS e o Linux ext4 podem tolerar. Quais são os parâmetros envolvidos? (por exemplo, /sys/block/sda/device/timeout no Linux)

informações relacionadas:

• Como menor Gluster FS down peer timeout / reduzir o impacto dos pares?

• link

Atualização: @ the-wabbit respondeu sobre Linux e Windows, eu também gostaria de saber o caso do FreeBSD

    

Answer 1

O driver de disco normalmente esperará até que um tempo limite configurável seja excedido antes mesmo de relatar um erro para a operação solicitada.

Como você descobriu, isso é /sys/block/<devicename>/device/timeout no Linux e o padrão é 60 30 segundos.

O Windows está armazenando essa configuração como configuração global TimeoutValue (REG_DWORD) em HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\ com um padrão de 60 segundos.

Contanto que nenhum erro seja relatado pelo usuário, você não verá nenhuma ação imediata (como uma remontagem do FS), mesmo depois que o tempo limite acabar, você normalmente verá mais ação do manipulador de erros (criação de log, redefinição do dispositivo, etc. .) antes de um erro ser passado de volta para a camada superior.

Mas esteja ciente de que haverá outras implicações que afetam a disponibilidade geral.

• aplicativos ou serviços do sistema podem implementar tempos de espera próprios e lançar exceções na expiração
• em servidores com uma alta taxa de pedidos, você verá o preenchimento de filas e a exaustão de memória à medida que novos clientes continuarem enviando novas solicitações com as solicitações antigas que ainda aguardam a resposta do armazenamento.
• se acontecer de você ter espaço de troca no dispositivo com falha, todas as solicitações de entrada / saída da página ficarão paralisadas, bloqueando efetivamente os processos que funcionam nessas páginas de memória.

Em geral, você desejará manter o tempo de failover o mais baixo possível enquanto ainda estiver operando sem failovers prematuros devido a picos ocasionais de carga ou falhas na rede. Determinar o valor correto para seu caso específico de uso é muito trabalho de tentativa e erro durante um período prolongado de operação. Para VMs de servidor de uso geral, eu teria como objetivo algo na magnitude de 10 segundos, se viável e suportado por sua infraestrutura.

    

Answer 2

O FreeBSD tem o geom_mountver ( link ), que pode ser usado para fazer com que ele tolere qualquer tempo de failover . Se você estiver usando o ZFS, talvez seja necessário desativar o timer inoperante; ele entrará em pânico na caixa se um IO não completar em 15 minutos (IIRC).