O tempo limite padrão para discos scsi é de 30 segundos, mas você pode alterá-lo alterando / sys / block / disk / device / timeout por exemplo, usando echo 180 > / sys / block / disk / sda / timeout aumentará o tempo limite para 180 segundos.
Um sistema operacional é instalado em um ambiente de máquina virtual, como VMWare ou KVM. Um volume de disco compartilhado na rede (por exemplo, disco iSCSI) é usado como partição do sistema operacional. Tráfego pesado está sendo executado neste SO. Se o volume de disco compartilhado não puder ser acessado temporariamente por dois ou três minutos (devido a problemas de rede ou outros motivos) e estiver on-line novamente após esse curto período, o que acontecerá? O sistema operacional será travado ou continuará a ser executado sem corrupção de dados?
Eu testei meu caso com o sistema operacional Linux guest. Durante o período de não acesso, a área de trabalho do Linux trava e não consigo operá-lo. Mas quando o volume do sistema puder ser acessado novamente, poderei usar a área de trabalho novamente e descobrir que as tarefas anteriores continuam a ser executadas.
Embora meu teste pareça bem-sucedido, não posso ter certeza de que está tudo bem. Eu sei que o sistema operacional tentará novamente as IOs, então talvez não importe se o disco não retorna IO por um curto período. Mas o sistema operacional também usa a partição swap para trocar algumas páginas na memória. Se as operações de troca são pausadas por causa do disco, existem consequências sérias?
Se eu entendi corretamente, a partição do sistema operacional convidado é local do ponto de vista do sistema operacional, e é apenas remoto para VMWare?
Sem saber com certeza, minha experiência com o VMWare é que ele fará uma pausa na máquina virtual durante esse tempo. Na verdade, eu tive um problema com o VMWare ESXi, onde o armazenamento (contendo todas as máquinas virtuais, e era local!) Estava cheio ao aumentar o tamanho de uma partição que pode crescer. Todas as VMs foram pausadas. Eu tive que excluir um instantâneo para liberar algum espaço, embora eu não tenho certeza se eles continuaram a executar diretamente depois (ou depois de uma reinicialização). Não era um servidor crítico, e eu sou apenas um desenvolvedor, não um administrador do sistema:)
Se você perder o disco por 2-3 segundos, provavelmente estará ok e o sistema operacional continuará depois que ele estiver disponível novamente. Embora vá reclamar e gemer alto nos logs.
Se você perder o disco por alguns minutos, o sistema operacional pode ou não ser Kernel Panic / BSOD, mas a menos que você tenha muita sorte, perderá dados e o sistema WILL ficará muito instável.
Sim, o subsistema de E / S tentará novamente ... mas não tentará novamente por alguns minutos.
Eu imagino que isso vai depender bastante da camada de virtualização. FWIW, eu acabei de testar isso usando o VirtualBox e ele simplesmente congelou, o que, para todos os efeitos, pode ser uma falha. Eu não tenho outros sistemas para testar, nem acredito que esse comportamento seja consistente. Eu suspeito que vai depender um pouco do que o sistema operacional está realmente fazendo no momento em que a conexão quebrou.
Esta é uma questão bastante complexa, e a resposta depende da sua configuração de host. Em primeiro lugar, a camada iSCSI possui seus próprios períodos de tempo limite e novas tentativas. O mesmo vale para o device-mapper-multipath que controla os dispositivos de bloco e, acima disso, você tem a camada de disco do QEMU e o driver do controlador de disco no sistema operacional convidado.
Para não entrar em muitos detalhes, se você prevê o uso de armazenamento instável, é muito mais seguro manter os riscos ao mínimo. Isso pode ser feito desabilitando a função de cache de disco do QEMU ( cache=none na linha cmd) e usando werror=stop para fazer o convidado pausar sempre que ele atingir um erro de IO, em vez de tentar empurrar esse IO indefinidamente.
Se você não usá-los, com um armazenamento instável você está arriscando corrupção de imagem e perda de dados, embora em alguns casos, se o sistema operacional convidado detectar o erro IO (se você usar propagação por exemplo), ele pode simplesmente remontá-lo ao FS modo r / o.
Em qualquer caso, geralmente é melhor evitar os gargalos de acesso ao disco, especialmente quando as VMs estão envolvidas. Múltiplos caminhos e redes separadas para tráfego iSCSI são os meios comuns para se alcançar isso.
Depende de muitas configurações. O SO foi projetado para tentar novamente a E / S por um tempo. Por quanto tempo depende do sistema operacional e das configurações do subsistema de E / S e de todas as camadas abaixo dele.
Por exemplo, considere uma VM linux em execução no VMware ESXi. A VM Linux acha que está sendo executada em um disco SCSI, que na verdade é um arquivo VMDK em um sistema de arquivos VMFS gerenciado pelo VMware. O sistema de arquivos VMFS está localizado na rede em um LUN iSCSI em uma SAN. Muitas camadas, cada uma com suas próprias configurações e tempos limite. Nesse caso, você deve verificar os tempos limite no iniciador iSCSI do VMware e no subsistema SCSI do Linux.
Nesse sistema em camadas, é inteligente aumentar os tempos limites padrão, pois há uma chance maior de que algo falhe temporariamente. A VMware realmente cuida disso por si só. O iniciador iSCSI do software VMware tem tempos de espera razoavelmente longos, tanto quanto eu sei. Os tempos limite padrão do Linux são um pouco curtos:
$ cat /sys/block/sda/device/timeout
30
Depois de instalar as ferramentas VMware na VM, ele cuida de aumentar os tempos limite dos discos virtuais para um valor mais seguro de 180 segundos. Não tenho certeza de qual valor é definido para as VMs do Windows.
No entanto, um tempo limite maior não é garantia. Um sistema operacional convidado com alta atividade de E / S de disco pode não tolerar solicitações de leitura e / ou gravação sustentadas durante o tempo limite de tempo limite. Os convidados do Windows podem congelar ou BSOD. Os convidados do Linux podem ir somente para leitura em seus volumes raiz, o que requer uma reinicialização para corrigir.
Embora o sistema operacional possa sobreviver à interrupção de E / S do disco, os aplicativos em execução na plataforma do sistema operacional podem não funcionar. Os próprios aplicativos implementam valores de tempo limite de resposta que provavelmente serão codificados e não configuráveis por uma plataforma ou um administrador de virtualização no próprio aplicativo.
Uma experiência pessoal: uma vez atualizei meu firmware de SAN e reiniciei a SAN. Essa reinicialização é rápida o suficiente para estar dentro dos limites de tempo do VMware ESXi e das VMs do Linux e do Windows. Normalmente, todas as VMs continuam funcionando bem. No entanto, desta vez, uma única VM não gostou do atraso e caiu com força. Nenhuma resposta. Tão difícil que eu não consegui matar a VM e tive que reinicializar todo o host VMware.