Minha experiência com o ZFS geralmente tem sido essasimplesmente funciona, então espero que a resposta seja: não é um problema - mas tenho um conjunto de dados que arruinará meu janeiro se falhar, então quero verificar novamente.
Esta é uma questão que poderia surgir em duas situações diferentes envolvendo um conjunto de dados separado. No momento estou lidando com o primeiro, mas também me perguntei sobre o segundo:
- O armazenamento do disco do sistema (ou seja, aquele que contém
rpool) falha, mas o armazenamento do pool de dados está bom, então você deseja restaurar o disco do sistema a partir de backups, mas apenas continuar com o armazenamento ativo do pool de dados. - Você tem o Solaris em execução em uma VM e deseja reverter para um instantâneo obtido pelo hipervisor (nãoum instantâneo ZFS de
rpool), mas o pool de dados é armazenado em discos que estão no modo “independente”, RDMs, etc., portanto, não será revertido.
Em ambas as situações, quando o Solaris for reinicializado, ele verá um conjunto de dados que conhece, mas que está em um estado em que nunca (até onde se lembra) o colocou.
Estou principalmente preocupado apenas com o caso em que o sistema foi desligado corretamente antes do disco do sistema ser rebobinado e onde o sistema foi desligado corretamente antes da imagem para a qual está sendo rebobinado. Eu esperaria que alternar entre estados de execução fosse um pouco mais complicado.
Observe também que, no meu caso específico, a geometria de armazenamento do pool e os caminhos para o armazenamento não foram alterados. Novamente, eu esperaria que isso fosse mais complicado se tivessem.
Eu nem estaria perguntando isso com Windows e NTFS porque é um sistema desacoplado comparativamente simplista, então é difícil entender por que issonão iriatrabalhar. No entanto, parece que o Solaris mantém algum tipo de metadados de poolfora da banda, conforme evidenciado pelo fato de que você deveria zpool exporte zpool importquando move pools entre sistemas (algo que nunca fiz dessa maneira graças ao VMware). Meu conhecimento desses metadados e de sua finalidade é limitado, por isso é difícil raciocinar sobre o impacto nesta situação. (Uma explicação disso seria ótimo!)
Na verdade, ainda tenho acesso ao sistema de pré-reversão. Ele está em um armazenamento de dados VMFS apoiado por um HP SmartArray que emitiu um aviso 1716 POST após uma malfadada alteração de disco de manutenção preventiva (que perdeu dados porque o SmartArray é mais burro que o ZFS). Todas as VMs importantes ainda parecem boas e as varreduras de seus sistemas de arquivos não encontraram erros, mas pretendo restaurar o array a partir de um backup muito recente de qualquer maneira, porque tenho motivos para suspeitar que o ESXizera silenciosamente setores defeituosos em vez de passar os erros para os convidados, então não quero arriscar que algum setor zerado esteja escondido em algum lugar para me morder na bunda mais tarde.
Para a VM Solaris, não preciso me preocupar com setores zerados, porque o ZFS detectaria isso, mas a maioria das outras VMs usa sistemas de arquivos burros. O backup é uma imagem de todo o armazenamento de dados VMware, portanto, corrigi-los também reverterá a VM Solaris. Na verdade, eu fiz uma limpeza nesta rpoolVM e ela não encontrou erros, então, se eu quisesse, poderia simplesmente esconder seu VMDK em outro lugar e copiá-lo de volta após a reversão, e então toda essa questão seria discutível. Acho que é isso que farei se ninguém responder, haha. Mas é algo que me pergunto há algum tempo, então ainda vou perguntar.
Então, a questão é:posso simplesmente reverter o armazenamento do disco do sistema e terminar com isso? Ou eu teria que exportar o pool do sistema de pré-reversão, reverter, excluir o pool antes de anexar seu armazenamento e, em seguida, anexar o armazenamento e importar o pool? Não gosto dos sons deste último, em parte porque há CIFS e iSCSI sendo servidos nesse pool e não me lembro de imediato como os configurei ou mesmo como fazê-lo, então, se eles quebrarem, eu ' vou ficar bravo. (Você pode dizer que não temos um administrador de sistema em tempo integral? haha)
A VM está executando uma versão mais antiga, Solaris 11.0.
(Aliás, é mais antigo em parte por causa da mesma pergunta. Eu queria tirar um instantâneo da VM antes de tentar uma atualização, caso eu a interrompesse, mas fiquei preocupado com a forma como um sistema revertido poderia reagir ao pool independente, então apenas deixei como está. E sim, sei que também poderia capturar o rpool, mas isso não oferece o mesmo nível de conforto para alguém que não trabalha com o Solaris diariamente.)
Responder1
Este é um daqueles tipos de respostas do tipo "zfs simplesmente funciona" ...
Os metadados do pool são, na verdade, armazenados no pool, e não no sistema operacional local. Assim, por exemplo, se um sistema travar e não for desligado corretamente, os metadados dentro do pool saberão que o pool não foi “exportado” de forma limpa. Se você tentasse importar esse pool para um novo sistema, receberia reclamações sobre ele não ter sido exportado e pertencer a outro sistema. Nesse ponto, você faria apenas um zpool import -f (force) e ele ficaria limpo.
Portanto, especificamente para o seu pool de dados, os dados nele contidos estarão seguros, não importa quando/onde você tente importar o pool novamente. Se você inicializasse em um rpool "restaurado", o sistema operacional nesse rpool saberia sobre os pools que deveria importar e simplesmente importaria o pool de dados. Ele não controla se um pool foi exportado ou não, a não ser o fato de que, uma vez exportado um pool, o sistema operacional não o acompanha mais.
Agora, com relação à questão do rpool. Restaurá-lo a partir de um instantâneo de VM, backup em fita, o que quer que seja, não mudará a maneira como ele lida com o pool de dados, a menos que o backup tenha sido feito antes de o pool de dados ser criado ou importado inicialmente. Se fosse esse o caso, você simplesmente importaria o pool assim que o sistema operacional fosse restaurado. Os dados no datapool estarão seguros, independentemente da condição do rpool.
Espero que isso ajude.
Além disso, você mencionou sua relutância em atualizar o Solaris porque não tinha certeza de como ele reagiria ao pool de dados. Não se preocupe com isso. Uma atualização preservará os pools conhecidos e os importará conforme necessário.
Observe também que as atualizações do Solaris OS são independentes em "ambientes de inicialização (BE)" individuais. Então, quando você faz uma atualização do sistema operacional, ele cria uma instalação de sistema operacional completamente independente contendo a nova versão... tudo isso enquanto seu sistema operacional ainda está instalado e funcionando. Então, quando você reiniciar, ele aparecerá no novo sistema operacional. Se houver problemas com o novo sistema operacional – ou seja. alterações nas bibliotecas, etc. que você não esperava - você pode simplesmente reiniciar novamente e acessar a versão 11.0 original e ela estará exatamente no mesmo estado que estava antes da atualização. É uma maneira incrível de fazer atualizações de sistema operacional!