• Artigo

Análise das opções de disponibilidade e de recuperação para proteger o banco de dados do VMM

 

Publicado: julho de 2016

Aplicável a: System Center 2012 SP1 - Virtual Machine Manager, System Center 2012 R2 Virtual Machine Manager, System Center 2012 - Virtual Machine Manager

Ao escolher entre as opções de proteção do banco de dados do VMM, seja no contexto da disponibilidade ou da recuperação de desastres, é boa ideia examinar o que pode acontecer se o banco de dados do VMM precisar ser colocado "de volta no tempo" devido a uma situação de falha. Isso pode ser necessário com algumas opções de backup e recuperação e algumas opções de disponibilidade. Por exemplo, usar os Grupos de Disponibilidade do SQL Server no modo de disponibilidade de confirmação assíncrona pode exigir que você execute um failover que coloca o banco de dados "de volta no tempo".

Situações de failover ou recuperação de banco de dados que podem exigir uma restauração do tipo "de volta no tempo"

Assim como qualquer banco de dados, se ocorrerem falhas de hardware ou outros problemas, alterações recentes no banco de dados do VMM poderão ser perdidas. Dependendo das opções de disponibilidade e recuperação em vigor, o banco de dados do VMM pode precisar passar por um failover ou restauração de backup, quando a única versão do banco de dados do VMM que permanece disponível está um pouco desatualizada. Isso às vezes é chamado de "voltar no tempo" para um banco de dados.

Os administradores de banco de dados analisam cuidadosamente as opções de disponibilidade e recuperação e de como o banco de dados pode ser restaurado – ou seja, com que proximidade ele pode voltar no tempo em caso de falha. Este tópico não tentará descrever todos os prós e contras das várias opções de disponibilidade ou recuperação, mas há duas escolhas que vale destacar com relação ao banco de dados do VMM:

  • Se Grupos de Disponibilidade AlwaysOn do SQL Server forem usados com o modo de confirmação assíncrona, um failover forçado poderá ser necessário. O modo de confirmação assíncrona significa que qualquer réplica secundária do banco de dados pode atrasar com relação à réplica primária a qualquer momento. No momento de um failover forçado, se for necessário executar o failover para uma réplica secundária que ficou ultrapassada, isso levará o banco de dados do VMM de volta no tempo. O modo de confirmação assíncrona é descrito mais detalhadamente nos tópicos a seguir:

  • Para a recuperação de desastres, pode ser necessário restaurar de um backup feito pouco antes do momento da falha. Isso certamente depende o intervalo entre os backups do banco de dados do VMM (incluindo backups externos). Se for necessário restaurar de um backup feito antes do ponto de falha, o banco de dados do VMM "será colocado "de volta no tempo".

Informações que podem ser afetadas se o banco de dados do VMM precisar ser colocado de volta no tempo

Pode ser útil rever os possíveis efeitos que podem surgir se o banco de dados do VMM precisar ser colocado de volta no tempo. Os exemplos incluem:

  • Permissões que foram alteradas logo antes de falha podem ser revertidas após o failover do banco de dados do VMM ou restauradas.

  • Acesso que foi removido logo antes de falha pode estar disponível novamente depois que o banco de dados do VMM passar pelo failover ou restauração.

    Por exemplo, o acesso ao conteúdo de um VHD pode ser disponibilizado a usuários que outra forma não teriam acesso.

  • Redes VM que foram removidas logo antes de falha podem estar disponíveis novamente depois que o banco de dados do VMM passar pelo failover ou restauração.

Ao escolher entre as opções de disponibilidade e recuperação para proteger o banco de dados do VMM, pode ser útil rever a lista anterior em relação ao seu ambiente e requisitos específicos.

Consulte também

Preparando seu ambiente do System Center 2012 R2 Virtual Machine Manager
Requisitos do sistema: Banco de dados do VMM no System Center 2012 e no System Center 2012 SP1