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...

1. 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 com ps -c | grep -v grep | grep [vmname], atualizar/reiniciar a VM de armazenamento e continuar a execução dos processos da VM usando kill -CONT [pid].
2. Uma solução semelhante pode ser a combinação de reinicialização rápida (disponível no Solaris/illumos via reboot -fou no Linux via kexec-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:

1. Qual método é preferível ou eles são igualmente bons/ruins?
2. 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.?
3. 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:

1. 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?
2. 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
3. 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.
4. Quais são as diferenças factuais e técnicas entre essas duas soluções e
   1. Execução paralisada dos processos da VM devido à sobrecarga da CPU no host
   2. Aumento do tempo de espera na E/S do disco devido a discos ou controladores defeituosos, supondo que esteja abaixo do limite do NFS?

Situação:

O seguinte problema estranho ocorreu em um único servidor de arquivos executando o OmniOS r151018 (95eaa7e) que atende arquivos por SMB para Windows e OS X convidados.

Salvar determinados arquivos (.docx, .xlsx, algumas imagens) por meio da janela de diálogo "Salvar como..." em um compartilhamento SMB resulta em um atraso de cerca de 3 a 5 segundos, em que o aplicativo não responde. arquivo é salvo normalmente.

O problema ocorreu "durante a noite", sem fazer nada para o servidor, mas é difícil precisar a data exata, pois as reclamações dos usuários só chegaram algum tempo depois da primeira ocorrência. Após uma reinicialização do servidor, um vdev do pool raiz espelhado não estava disponível, mas uma inspeção mais detalhada não encontrou nenhuma falha no dispositivo e ele foi reanexado ao pool. O problema ainda persiste.

Algumas observações:

• Acontece em todos os clientes do Windows 7
• Isso acontece para todos os tamanhos de arquivo
• Acontece em todos os compartilhamentos desta máquina, independentemente das permissões
• Isso acontece para armazenamento mais rápido importado no host por iSCSI de outro servidor
• A velocidade normal de cópia é de 110 MB/s em GBit Ethernet
• Os dados e o pool raiz parecem estar bem
• Isso não acontece em outros servidores de arquivos
• Isso não acontece quando o arquivo é salvo localmente e depois copiado pelo explorer
• Não acontece no OS X (só poderia testar com o OpenOffice)
• dmesgmostra várias contagens NOTICE: bge0: interrupt: flags 0x0 - not updated?com vários valores, mas também era o caso antes e não prejudicou

Outras ideias/planos:

Como não há uma mensagem de erro clara a ser encontrada, talvez seja necessário fazer algumas tentativas e erros para procurar a causa. Algumas coisas que considerarei ( os resultados estão em itálico ):

• Substitua a placa de rede Broadcom por uma placa Intel => não fez diferença
• Substitua o pool raiz por SSDs SATA (atualmente pendrives de memória SLC que funcionaram bem por mais de 3 anos) => não fez diferença
• Verifique a rede intermediária (hardware, por conexão direta ao servidor)
• Captura de tráfego com WireShark: difícil se você não sabe exatamente o que está procurando
• Reverta para um ambiente/versão de inicialização anterior do OmniOS para descartar conflitos de software => não fez diferença
• Reverta as atualizações do Windows/Office para descartar bugs

• Remover arquivos com :(dois pontos) em nomes de arquivos de instantâneos, sugestão de txgsync no tópico do reddit criado por ewwhite => não fez diferença

  Eu vi algo semelhante a isso quando o recurso "versões anteriores" do Windows é ativado com instantâneos automáticos que incluem um caractere ":". Apenas tiro ao vento com isso, mas pode valer a pena dar uma olhada, pois o caractere ":" não é permitido nos nomes de arquivo do Windows.

• Monitoramento de acesso a arquivos: conforme sugerido por shodanshok, usei DTracee este script para monitorar o acesso a arquivos. Usei-o enquanto salvava o arquivo já aberto, removi saídas não relacionadas e informações pessoais, e o resultado gira em torno de três arquivos:

  CPU ID       FUNCTION:NAME
  1   18753    fop_open:entry Open: Workbook
  0   18181 fop_create:return Create: temp_1
  0   18753    fop_open:entry Open: temp_1
  0   18753    fop_open:entry Open: Workbook
  0   18753    fop_open:entry Open: Workbook
  0   18753    fop_open:entry Open: temp_1
  0   18888  fop_rename:entry Rename: Workbook -> temp_2
  0   18888  fop_rename:entry Rename: temp_1 -> Workbook
  0   18753    fop_open:entry Open: Workbook
  0   18753    fop_open:entry Open: temp_2
  0   18892  fop_remove:entry Remove: temp_2
  0   18753    fop_open:entry Open: Workbook
  0   18753    fop_open:entry Open: Workbook
  

  O mesmo procedimento em outro servidor onde o problema não ocorre produz um resultado semelhante:

  CPU ID       FUNCTION:NAME
  1   25182 fop_create:return Create: temp_1
  1   25750    fop_open:entry Open: temp_1
  1   25750    fop_open:entry Open: Workbook
  1   25750    fop_open:entry Open: temp_1
  1   25750    fop_open:entry Open: Workbook
  1   25750    fop_open:entry Open: temp_1
  1   25889  fop_rename:entry Rename: Workbook -> temp_2
  1   25889  fop_rename:entry Rename: temp_1 -> Workbook
  1   25750    fop_open:entry Open: Workbook
  1   25750    fop_open:entry Open: temp_2
  1   25893  fop_remove:entry Remove: temp_2
  1   25750    fop_open:entry Open: Workbook
  1   25750    fop_open:entry Open: Workbook
  1   25750    fop_open:entry Open: Workbook
  

  Também adicionei timestamps ( walltimestamp) ao script, mas em ambos os casos todas as operações de arquivo ocorrem no mesmo segundo. => não fez diferença

• Importar discos em outro host para verificar se a fragmentação do pool ou os discos estão com defeito => não fez diferença
• Mova os dados e o pool raiz para uma máquina idêntica para descartar cabeamento, placa principal etc. => o problema persiste, então deve ser o pool raiz (software) ou um hardware específico que é incompatível com o software (ou se tornou incompatível repentinamente. ..)

Você poderia sugerir mais alguma coisa que seja a causa desse comportamento? Ou você experimentou algo semelhante? como não consegui encontrar nada útil online, suspeito que seja um problema estranho de hardware (porque está limitado a uma máquina) ou um problema com o Windows/Office.

Eu tenho um NAS rodando em OpenSolaris/illumos/OmniOS com vários sistemas de arquivos ZFS compartilhados onde os autosnaps estão ativos para preservar um histórico (mantenha 4 snaps de 15 minutos, snaps de 24 horas, 7 snaps diários e assim por diante). Posso acessar os instantâneos com a janela Versões anteriores do Windows Explorer e restaurar versões mais antigas de arquivos ou arquivos excluídos, o que funciona bem.

Os problemas que tenho aparecem ao renomear ou mover arquivos:

• Se eu criá Draft1.txt-lo e modificá-lo ao longo de um dia, o histórico será preservado. Quando termino o rascunho e o renomeio para qualquer outra coisa, digamos Letter.txtou mesmo Draft2.txt, as versões desaparecem (elas só podem ser acessadas via diretório ao saber o nome do arquivo antigo ou ao renomear o arquivo para o nome antigo).
• Se eu criar e modificar Draft1.txte depois salvar outra cópia da versão finalizada Letter.txt(agora com dois arquivos), o primeiro tem o histórico e o segundo não (tudo bem). Se eu deletar Draft1.txte depois quiser restaurá-lo, posso encontrá-lo no diretório, mas a versão restaurada agora perdeu seu histórico.
• Se eu mover um arquivo para outro subdiretório, o histórico será perdido.
• Se eu (acidentalmente) renomear um arquivo, o histórico é perdido.

Portanto, se eu quiser preservar todo o poder das versões anteriores, tenho que pensar em várias coisas ao trabalhar com o compartilhamento:

1. Nunca renomeie arquivos, o primeiro nome escolhido deve permanecer para sempre
2. Nunca mova ou reorganize arquivos, exceto no primeiro dia (caso contrário, as alterações perdidas seriam muito grandes)
3. Nunca salve um arquivo com um novo nome após as alterações terem sido feitas (salvar primeiro é OK)
4. Nunca mescle ou divida diretórios, porque todo o conteúdo perde todo o seu histórico, mesmo que os blocos físicos não mudem.

Há algo que eu possa fazer sobre isso, exceto viver com isso? Parece estranho que o ZFS funcione em blocos na maioria das coisas (copiar na gravação, enviar/receber, zvols, instantâneos), mas funciona em arquivos neste caso. Ou isso é uma limitação do subsistema SMB/CIFS em vez do sistema de arquivos?

Eu tenho uma configuração de teste contendo:

• 3 controladores de domínio AD (configurados para replicar entre eles), todos executando o Samba 4.3 no Univention Corporate Server 4.1
• 1 cliente Windows 7 SP1 associado ao domínio
• 1 servidor de arquivos OmniOS r151018 executando napp-it 16.02f associado ao domínio com compartilhamentos SMB/CIFS configurados para alguns usuários de teste de domínio

O domínio funciona como eu esperava, o login do Windows funciona, o acesso ao servidor de arquivos funciona, o DNS e as conexões IP diretas funcionam, até o failover ao desligar um DC funciona.

A única coisa que não funciona é que não consigo ver a máquina OmniOS no navegador de rede/vizinhança de rede na máquina com Windows 7 . Posso encontrá-lo em "Pesquisar no Active Directory" ao pesquisar todos os computadores e também conectar-me a ele usando \\hostname(ou IP) sem problemas ou atrasos. Ele simplesmente não parece anunciar-se corretamente. Os outros 3 servidores e a própria máquina Windows estão lá como seria de esperar e só desaparecem se as máquinas forem desligadas.

Ao procurar soluções, encontrei a sugestão de definir a smbpropriedade system_comment, mas parece não fazer nada, mesmo após uma reinicialização.

Por outro lado, também notei que com a atualização para OmniOS r151016 e r151018 a descoberta direta usual no modo Workgroup não funcionou mais em comparação com r151012 (o acesso só é possível por IP). Isso pode ou não estar relacionado ao meu problema, não consegui encontrar nenhuma informação mais detalhada além de "múltiplas alterações no suporte SMB" para os lançamentos ilumos que foram incorporados a essas versões do OmniOS.

Qual pode ser a causa desse problema/inconveniência e como posso corrigi-lo? Como solução alternativa, o mapeamento direto das unidades de rede funcionaria, mas isso pode se tornar problemático se o número de compartilhamentos aumentar.

Eu tenho o compartilhamento de arquivos SMB/CIFS configurado em um servidor OmniOS com o módulo de kernel Solaris que usa ACLs NFSv4 que devem funcionar corretamente com clientes Windows.

Quero criar um diretório compartilhado com os seguintes objetivos: um usuário (digamos alice) deve ser capaz de criar e modificar arquivos, mas não excluí-los. Também a criação de subdiretórios deve ser evitada. O acesso de leitura deve ser permitido.

Eu tentei a seguinte ACL, que basicamente funciona:

/usr/bin/chmod A=\
user:root:rwxpdDaARWcCos:fd-----:allow,\    # root has full access
user:alice:rwx---a-R-c--s:-------:allow,\   # dir: create files, read everything
user:alice:rwxp--aARWc--s:f-i----:allow \   # files: wpAW is needed for full file write access, everything is only inherited to files
/pool/share

Mas se alicevisualizar a guia Segurança dos arquivos recém-adicionados no Windows Explorer, ela poderá conceder a si mesma direitos de acesso total e excluir o arquivo posteriormente, mesmo que não tenha Codireitos.

Como explicar esse comportamento? E como posso alterá-lo para que as ACLs não possam ser modificadas?

Edit: A saída de lsparece ser normal:

# /usr/bin/ls -v
total 1
-rwx------+  1 alice staff          3 2016-03-21 test.txt
    0:user:root:read_data/write_data/append_data/read_xattr/write_xattr
        /execute/delete_child/read_attributes/write_attributes/delete
        /read_acl/write_acl/write_owner/synchronize:inherited:allow
    1:user:alice:read_data/write_data/append_data/read_xattr
        /write_xattr/execute/read_attributes/write_attributes/read_acl
        /synchronize:inherited:allow

# /usr/bin/ls -V
total 1
-rwx------+  1 alice staff          3 2016-03-21 test.txt
    user:root:rwxpdDaARWcCos:------I:allow
    user:alice:rwxp--aARWc--s:------I:allow

Saída lspara o próprio diretório:

# /usr/bin/ls -Vd
drwx------+  3 root     root           4 2016-03-21 .
 user:root:rwxpdDaARWcCos:fd-----:allow
user:alice:rwx---a-R-c--s:-------:allow
user:alice:rwxp--aARWc--s:f-i----:allow

# /usr/bin/ls -vd
drwx------+  3 root     root           4 2016-03-21 .
    0:user:root:list_directory/read_data/add_file/write_data
        /add_subdirectory/append_data/read_xattr/write_xattr/execute
        /delete_child/read_attributes/write_attributes/delete/read_acl
        /write_acl/write_owner/synchronize:file_inherit/dir_inherit:allow
    1:user:alice:list_directory/read_data/add_file/write_data
        /read_xattr/execute/read_attributes/read_acl/synchronize:allow
    2:user:alice:list_directory/read_data/add_file/write_data
        /add_subdirectory/append_data/read_xattr/write_xattr/execute
        /read_attributes/write_attributes/read_acl/synchronize
        :file_inherit/inherit_only:allow

O sistema de arquivos do compartilhamento é ZFS. As propriedades não padrão mais interessantes são as seguintes:

NAME        PROPERTY        VALUE          SOURCE
pool/share  type            filesystem     -
pool/share  compression     lz4            inherited from pool
pool/share  atime           off            local
pool/share  aclmode         restricted     local
pool/share  aclinherit      passthrough    local
pool/share  version         5              -
pool/share  utf8only        on             -
pool/share  normalization   formD          -
pool/share  casesensitivity insensitive    -
pool/share  nbmand          on             local
pool/share  sharesmb        name=testshare local

As permissões de compartilhamento CIFS são definidas para permitir acesso total a todos, portanto, apenas a permissão de arquivo deve ser aplicada.

Atualizar:

Este tópico é muito semelhante ao meu problema, embora a solução de reduzir as ACLs /pool/share/.zfs/shares/testsharepara modify_settodos (ou negar permissões de exclusão específicas aos usuários) não pareça funcionar no meu caso e não sei por quê.

Meu objetivo é automatizar uma rotina de backup em um pequeno NAS OpenSolaris (executando OmniOS + napp-it em um HP Microserver N54L) em combinação com discos SATA.

Fundo:

Eu instalei uma daquelas bandejas de HDD sem portadora de 5,25" -> 3,5" que contêm um backplane SATA ou SAS/SATA simples com uma porta, um botão liga/desliga e alguns LEDs (energia e atividade do HDD). Para fazer backup de vários HDDs (um a cada semana em rotação, armazenado fora do local), escrevi um script que usa zfs send/recvpara despejar o pool principal completo, incluindo todos os instantâneos (atualizando apenas novos blocos). Este script funciona bem quando eu o inicio manualmente.

Eu gostaria de automatizar ainda mais esse processo, porque o NAS não tem VGA direto ou console serial conectado e é tedioso inserir o disco, voltar para o sistema de desktop, fazer login na interface da web ou SSH e iniciar o script manualmente . O início cronometrado via cron job não é uma opção, pois os dias de backup podem variar um pouco (esqueci o disco, feriados, etc.). Portanto, o backup deve começar logo após a inserção do disco.

Problema:

No script que uso cfgadmpara conectar + configurar e depois desconfigurar + desconectar os discos. Se eu apenas inserir o disco e ele girar, não tenho como saber que o disco está lá. Possíveis soluções que já considerei:

1. Sondagem de um novo disco e zpool a cada x minutos continuamente usando cfgadm -f -c connecte verificando resultados de erro. Não muito elegante.
2. Verificando /var/adm/messagesa cada x minutos e procurando o caminho do dispositivo ou AHCI. Não é possível, pois as mensagens só são gravadas se o dispositivo for conectado manualmente.
3. Usando iostat -En. Exibe os discos, mas preciso obter os números de série exatos, porque não lista as informações da porta. Também precisa ser feito a cada x minutos.
4. Usando cfgadmcom a sintaxe SELECT para filtrar o status do receptáculo. Não funciona, porque a inserção não aciona nada (talvez o backplane seja muito barato para isso).
5. Reconhecendo o ligar/desligar do gabinete. Estaria tudo bem, mas eu não conseguia descobrir como fazer isso.
6. Remapear o botão liga/desliga ou adicionar outro botão à máquina. Poderia funcionar, mas também não sei como fazer isso.

Acho que precisaria de duas coisas:

• uma maneira confiável de identificar o status do disco e da porta em combinação (para que apenas o disco correto no slot correto seja detectado)
• uma maneira de registrar essa detecção e acionar um evento (iniciar shell script)

Isso é possível? Se não, o que você sugeriria como alternativas?

Solução final (atualizada em 26/01/2015):

Para qualquer pessoa com problemas semelhantes no futuro:

1. Habilite o hotswap AHCI no OmniOS conforme detalhado na resposta aceita por gea.
2. Use syseventadmconforme detalhado em minha própria resposta para acionar o script de backup quando o disco ficar online.
3. Certifique-se de que seus cabos, controlador e discos estejam livres de falhas e funcionem bem juntos (tive problemas com os discos WD SE 4TB e o controlador AHCI SATA integrado, o que resultou em WARNING: ahci0: ahci_port_reset port 5 the device hardware has been initialized and the power-up diagnostics failedmensagens aleatórias nos logs do sistema).