replicação vSphere / SRM não respeitando os grupos prioritários

2

Estou no processo de demonstração do SRM da VMware.

A instalação é boa e posso executar facilmente uma restauração para uma única máquina.

Estou desenvolvendo um script de recuperação para um único aplicativo distribuído em cerca de 10 servidores, alguns servidores sql, alguns servidores de aplicativos, uma máquina de acesso de cliente entre alguns outros.

Os grupos de prioridades são definidos exatamente como deveriam e eu não preciso adicionar nenhuma definição de grupo interno.

Quando eu testo meu plano de recuperação, vejo as VMs de prioridade 1 dispararem primeiro, a prioridade 2 não, e algumas - cerca de metade - das três VMs de prioridade. Parece que as coisas acabam seguindo em frente, ainda usando essa estranha ordenação. O que diabos está acontecendo aqui? Está relacionado ao método que o SRM usa para alterar os endereços IP? Algo na versão de hardware e / ou nas ferramentas VMware?

Todos os hosts ESXi e vSphere são 5.5. Estou usando a replicação do vSphere e o SRM 5.8.1.

    
por Tim Brigham 18.02.2016 / 23:37

1 resposta

0

Depois de corrigir alguns problemas de tempo limite, consegui determinar o que está acontecendo aqui.

Parece que as etapas de preparação do SRM (configurar armazenamento, configurar rede de texto, inicialização de convidado, personalizar ip) são executadas começando pela prioridade 1 e passando pela prioridade 5 em grupos de aproximadamente 4 VMs por vez. Essas etapas são tratadas como independentes da inicialização de produção.

As caixas SQL sob prioridade 2 são grandes. Como resultado, é necessário um lote para que as caixas do meu grupo 2 cheguem até a inicialização do convidado. O SRM não espera que esse processo seja concluído nessas VMs e passa para o próximo grupo. Realmente faz sentido - todas as VMs são desligadas e aguardam para serem inicializadas na ordem correta assim que a reconfiguração for concluída.

    
por 22.02.2016 / 16:07