Como recuperar de “Movimentação Inválida da Unidade” (HP SmartArray P411)

Question

Devido ao furacão Matthew, nossa empresa desligou todos os servidores por dois dias. Um dos servidores era um host ESXi com um HP StorageWorks MSA60 conectado.

Quando atualizamos as coisas hoje e acessamos o cliente vSphere, percebemos que nenhuma de nossas VMs convidadas está disponível (todas estão listadas como "inacessíveis"). E quando observo o status do hardware no vSphere, o controlador de matriz e todas as unidades anexadas aparecem como "Normal", mas todas as unidades aparecem como "disco não configurado".

Nós reinicializamos o servidor e tentamos acessar o utilitário de configuração do RAID para ver como as coisas são, mas recebemos a seguinte mensagem:

An invalid drive movement was reported during POST. Modifications to the array configuration following an invalid drive movement will result in loss of old configuration information and contents of the original logical drives

Escusadoserádizerqueestamosmuitoconfusoscomissoporquenadafoi"movido"; nada mudou. Nós simplesmente ligamos o MSA e o servidor, e temos tido esse problema desde então.

O MSA é conectado por meio de um único cabo SAS, e as unidades são rotuladas com adesivos, por isso sei que as unidades não foram movidas ou trocadas:

---------------------
| 01 | 04 | 07 | 10 |
---------------------
| 02 | 05 | 08 | 11 |
---------------------
| 03 | 06 | 09 | 12 |
---------------------

No momento, não sei o que fazer e modelar as unidades, mas são todas unidades SAS de 1 TB.

Eu tenho duas questões / preocupações principais:

1. Como não fizemos nada além de ligar e desligar os dispositivos, o que poderia ter causado isso? É claro que tenho a opção de reconstruir o array e começar de novo, mas estou desconfiado da possibilidade de isso acontecer novamente (especialmente porque não tenho ideia do que o causou).

2. Existe uma chance de bola de neve no inferno de poder recuperar nossas VMs de array e guest, em vez de ter que reconstruir tudo e restaurar nossos backups de VM?

Answer 1

Certo, esta é uma situação muito precária ...

Portanto, o controlador HP Smart Array pode manipular um determinado número de movimentos da unidade física antes de interromper a configuração da matriz. Lembre-se de que os metadados HP RAID residem nas unidades físicas e não no controlador ...

O MSA60 é um gabinete SAS JBOD de primeira geração com 3,5-baias de 3,5 ". Fechou o fim de sua vida útil em 2008/2009. Tem idade suficiente para não estar no caminho crítico de qualquer implantação do vSphere hoje.

Neste caso, o controlador P411 está tentando protegê-lo. Você pode ter sofrido uma condição de falha de múltipla unidade, atingiu um bug de firmware, perdeu uma das duas interfaces do controlador na parte traseira do MSA60 ou algum outro erro estranho.

Isso soa como uma configuração de servidor mais antiga também. Então, eu gostaria de saber o servidor envolvido e a revisão de firmware do Smart Array P411.

Sugiro remover a energia de todos os componentes. Esperando alguns minutos. Ligando ... e vendo os avisos do POST bem de perto.

Veja os detalhes na minha resposta aqui:
unidades lógicas no HP Smart Array P800 não reconhecidas após a reinicialização

Há may uma opção para reativar uma unidade lógica com falha anterior, com uma opção para pressionar F1 ou F2 . Se apresentado, tente F2 .

    

Answer 2

Vocês não vão acreditar nisso ...

Primeiro tentei uma inicialização a frio do MSA existente, esperei alguns minutos e depois liguei o host do ESXi, mas o problema permaneceu. Eu então desliguei o host e o MSA, movi as unidades para o nosso MSA sobressalente, liguei-o, esperei alguns minutos e liguei o host do ESXi; a questão ainda permaneceu.

Nesse ponto, percebi que estava praticamente ferrado, e não houve nada durante a inicialização do controlador RAID, em que tive a opção de reativar uma unidade lógica com falha. Então eu inicializei na configuração RAID, verifiquei novamente que não havia unidades lógicas presentes e criei uma nova unidade lógica (RAID 1 + 0 com duas unidades sobressalentes; o mesmo que fizemos há 2 anos quando instalamos este host pela primeira vez e armazenamento).

Depois deixo o servidor inicializar no vSphere e o acessei via vCenter. A primeira coisa que fiz foi remover o host do inventário e adicioná-lo novamente (esperava excluir todas as VMs convidadas inacessíveis dessa maneira, mas isso não as eliminou do inventário). Depois que o host voltou ao meu inventário, removi cada uma das VMs convidadas, uma de cada vez. Depois que o inventário foi limpo, verifiquei que não existia nenhum armazenamento de dados e que os discos estavam basicamente prontos e esperando como "discos de dados". Então eu fui em frente e criei um novo armazenamento de dados (novamente, o mesmo que fizemos alguns anos atrás, usando o VMFS). Fui solicitado a especificar uma opção de montagem e tive a opção de "manter a assinatura existente". Nesse momento, achei que valeria a pena tentar manter a assinatura - se as coisas não funcionassem, eu poderia sempre explodi-lo e recriar o armazenamento de dados novamente. Depois que eu terminei o processo de construir o armazenamento de dados com a opção keep signature, tentei navegar para o armazenamento de dados para ver se havia algo nele - parecia vazio. Só por curiosidade, eu SSH'd para o host e verifiquei de lá, e para minha surpresa, eu pude ver todos os meus dados antigos e todas as minhas antigas máquinas virtuais convidadas! Voltei para o vCenter e re-digitalizei o armazenamento e atualizei o console, e todas as nossas velhas VMs convidadas estavam lá! Eu registrei novamente cada VM e consegui recuperar tudo! Todas as nossas VMs convidadas estão de volta e se comunicam com sucesso na rede.

Acho que a maioria das pessoas na comunidade de TI concorda que as chances de que algo assim aconteça são extremamente baixas a impossíveis.

Tanto quanto eu estou preocupado, isso foi um milagre de Deus ...