Situação:
Em um servidor All-In-One ESXi/ZFS-Storage integrado, onde a VM de armazenamento usa discos bare metal e exporta os sistemas de arquivos via NFS (ou iSCSI) de volta para o ESXi, que os usa como armazenamento de pool para as outras VMs, existe um problema quando chega a hora de atualizar a VM de armazenamento, porque várias VMs em execução dependem dela e expiram com NFS.AllPathsDownou causas semelhantes, o que equivale a puxar a unidade de um servidor normal sem desligá-la.
É claro que é possível desligar todas as VMs, mas isso consome muito tempo e também é tedioso (ou precisa ser programado). Mover as VMs para outro host pode ser possível, mas leva ainda mais tempo e pode não ser possível em configurações menores, onde uma única máquina é suficiente. Suspender as VMs pode funcionar, mas também é bastante lento (às vezes mais lento que o desligamento).
Soluções possíveis...
- Uma solução simples, porém eficiente, parece ser interromper os processos da VM por meio da CLI com
kill -STOP [pid]depois de localizá-la comps -c | grep -v grep | grep [vmname], atualizar/reiniciar a VM de armazenamento e continuar a execução dos processos da VM usandokill -CONT [pid]. - Uma solução semelhante pode ser a combinação de reinicialização rápida (disponível no Solaris/illumos via
reboot -fou no Linux viakexec-reboot), que leva segundos em vez de minutos, e o tempo limite do NFS no ESXi (na perda da conexão NFS, todas as E/S são suspensas, acho 120 segundos, até que seja assumido que o armazenamento está inativo permanentemente). Se o tempo de reinicialização estiver dentro da janela ESXi NFS, ele deve, em teoria, ser comparável a um disco que não responde por um minuto devido à correção de erros, mas retoma a operação normal.
... e problemas?
Agora, minhas perguntas são:
- Qual método é preferível ou eles são igualmente bons/ruins?
- Quais são os efeitos colaterais não intencionais em casos especiais, como bancos de dados, controladores do Active Directory, máquinas com usuários executando trabalhos, etc.?
- Onde se deve ter cuidado? Um comentário no blog vinculado menciona que problemas de cronometragem podem surgir quando a CPU está congelada, por exemplo.
Editar: Para esclarecer o escopo desta questão
Depois de receber as duas primeiras respostas, acho que minha pergunta não foi suficientemente clara ou deixei de fora muitas informações por uma questão de brevidade. Estou ciente do seguinte:
- Não é suportado pela VMware ou por qualquer outra pessoa, não faça isso! : Não mencionei isso porque o primeiro link já informa e também não teria perguntado se esta máquina era gerenciada pelo suporte VMware. É uma questão puramente técnica, o material de suporte está fora do escopo aqui.
- Se projetar um novo sistema hoje, algumas coisas poderiam ser feitas de outras maneiras : Correto, mas como o sistema está funcionando estável há alguns anos, prefiro não jogar fora o bebê com a água do banho e começar completamente novo, apresentando novos problemas.
- Compre hardware X e você não terá esse problema! É verdade que eu poderia comprar 2 ou 3 servidores adicionais com custo semelhante e ter uma configuração HA completa. Eu sei como isso é feito, não é tão difícil. Mas esta não é a situação aqui. Se esta fosse uma solução viável no meu caso, eu não teria feito a pergunta em primeiro lugar.
- Apenas aceite o atraso de desligamento e reinicialização : sei que essa é uma possibilidade, pois é o que estou fazendo atualmente. Eu fiz a pergunta para encontrar alternativas melhores dentro da configuração atual ou para aprender as razões técnicas fundamentadas de que alguns dos métodos descritos terão problemas - "é imprevisível" sem nenhuma explicação de por que não é uma resposta fundamentada em meu livro.
Portanto, para reformular as perguntas:
- Qual desses dois métodos é tecnicamente preferível e por quê, supondo que a configuração seja fixa e o objetivo seja reduzir o tempo de inatividade sem introduzir nenhum efeito colateral negativo na integridade dos dados?
- Quais são os efeitos colaterais não intencionais em casos especiais como
- bancos de dados ativos/inativos/quiescentes com usuários e/ou aplicativos acessando-os
- Controladores do Active Directory nesta máquina e/ou em outras máquinas (no mesmo domínio)
- máquinas de uso geral ociosas ou com usuários executando tarefas ou executando tarefas de manutenção automatizada, como backups
- aparelhos como monitoramento de rede ou roteadores
- tempo de rede com ou sem uso de NTP neste servidor ou em outro ou em vários servidores
- Em quais casos especiais é aconselhável não fazer isso, porque as desvantagens são maiores que as vantagens? Onde se deve ter cuidado? Um comentário no blog vinculado menciona que problemas de cronometragem podem surgir quando a CPU está congelada, por exemplo, mas não fornece nenhum raciocínio, prova ou resultado de teste.
- Quais são as diferenças factuais e técnicas entre essas duas soluções e
- Execução paralisada dos processos da VM devido à sobrecarga da CPU no host
- Aumento do tempo de espera na E/S do disco devido a discos ou controladores defeituosos, supondo que esteja abaixo do limite do NFS?
Boa pergunta...
Mas por que você precisa reiniciar o servidor NFS?
Os designs multifuncionais não são mais razoáveis. Como um experimento científico ou uma pequena situação de laboratório doméstico, com certeza. Mas, como qualquer solução, espere criar janelas de tempo de inatividade e manutenção quando necessário.
Então...
Se você não pode ter esse tipo de tempo de inatividade, não deve executar um armazenamento all-in-one e configuração de VM ou deve considerar o armazenamento SAN tradicional (ou uma versão de baixo custo) e vários hosts de VM.
Minha sugestão seria evitar esse problema completamente. Você mencionou que o aumento dos custos e uma nova arquitetura completa são obstáculos, mas o que você pode considerar nessa situação é ter duas VMs de armazenamento no host em um cluster de failover de dois nós. Isso permitiria corrigir qualquer um deles (mas não os dois ao mesmo tempo) sem afetar a disponibilidade do NFS ou iSCSI servido pelo cluster. Ainda não é uma solução suportada, mas pelo menos permite alguma flexibilidade na manutenção ao custo de maior sobrecarga de recursos (principalmente a quantidade de memória que você fornece para a segunda VM de armazenamento) para armazenamento.
Se alterar a arquitetura for totalmente inaceitável, a opção mais segura seria desligar as VMs.
A próxima melhor solução seria habilitar a hibernação em suas VMs. A hibernação garantiria que todos os sistemas de arquivos fossem desativados, ajudando a evitar possíveis danos.
Em seguida, você pode tirar um instantâneo da VM com o estado da memória, encerrar à força o processo da VM e, em seguida, reverter para o instantâneo quando terminar. Isso incorre em uma pequena janela de dados possivelmente perdidos, mas tenho certeza de que você nunca tentaria isso fora de uma janela de manutenção, onde qualquer perda de dados seria inaceitável, portanto, isso deve ser bastante inconseqüente. Essa solução é tão rápida quanto fazer um instantâneo, garante que as VMs não reclamem sobre discos perdidos, mas incorrem em possível perda de dados.
Por fim, se você deseja pausar os processos (e testou se realmente funciona), sugiro enfaticamente que você sincronize todos os discos no convidado primeiro (no Linux, isso seria feito com /bin/sync. Utilitário fornecido por SysInternals para Windows: http://technet.microsoft.com/en-us/sysinternals/bb897438.aspx ) e execute sua manutenção rapidamente para que os relógios não sejam atrasados demais.
Quanto aos possíveis efeitos colaterais, qualquer máquina conectada ao AD deve estar (por padrão) dentro de 5 minutos do tempo do DC. Portanto, após qualquer solução em que a VM não esteja continuamente disponível, exceto um desligamento normal, sugiro que você force o convidado retomado a atualizar seu relógio. Em servidores de banco de dados, não faça essas coisas quando o servidor estiver ocupado, pois isso aumenta as chances de corrupção do sistema de arquivos.
O principal risco em todas as opções além de um desligamento normal ou armazenamento altamente disponível é o da corrupção. Haverá potencialmente alguma E/S em um buffer que será descartado, o que o aplicativo pode erroneamente pensar que foi concluído com êxito. Pior ainda, as E/S podem ter sido reordenadas por uma camada inferior para um padrão de gravação mais otimizado. Isso pode permitir que os dados tenham sido parcialmente gravados fora de ordem. Talvez a contagem de linhas tenha sido incrementada antes que os dados de uma linha de banco de dados fossem gravados ou uma soma de verificação atualizada antes que os dados da soma de verificação fossem alterados fisicamente. Isso pode ser atenuado permitindo apenas gravações síncronas em seu armazenamento, mas ao custo do desempenho.
Nenhum.
Este é o custo de um design terrível, eu não pioraria essa situação fazendo nada além de desligar suas VMs, trabalhar na VM de armazenamento e reiniciar as outras VMs. Eu também pediria a alguém para redesenhar sua configuração usando uma arquitetura suportada/suportável.
É inerentemente imprevisível, o que pode acontecer desta vez pode não acontecer se você fizer isso de novo. É insuportável.
É difícil responder a isso de forma construtiva.