Duplicando um host ESXi para outro host ESXi como uma solução de backup

Question

Eu tenho um host ESXi com as seguintes máquinas virtuais:

1 x servidor do Active Directory

1 x servidor de serviços de área de trabalho remota

1 x servidor de banco de dados SQL

1 x Servidor de aplicativos de software de contabilidade

Eu tenho um segundo host ESXi "em branco / vazio".

Em teoria, o que eu queria fazer era simplesmente programar as VMs para serem clonadas no segundo host como backup. Se algo acontecer ao primeiro servidor, eu poderia simplesmente inicializar as VMs na segunda máquina e retomar como se a primeira nunca tivesse ocorrido.

Na prática, parece muito menos prático ter feito algumas pesquisas aqui no SF.

A minha principal preocupação é a integridade e consistência do banco de dados SQL ... Esta estratégia de backup não parece ser recomendada para servidores SQL devido a dados não gravados que residem na memória. Eu suponho que eu poderia desligar o servidor, cloná-lo e reiniciá-lo, mas no meu mundo perfeito, eu gostaria de duplicar essas VMs pelo menos uma vez durante a noite.

Qual seria a melhor estratégia de backup para replicar esses tipos específicos de servidores para um segundo host ESXi todas as noites enquanto eles ainda estiverem ativos? Considere opções separadas para um orçamento de US $ 1.000 e um orçamento de US $ 10.000.

Existe uma estratégia de backup melhor possível como um todo?

    

Answer 1

Embora não caiba em um orçamento de US $ 10.000, a opção final é ter duas SANs e ter os dados replicados em tempo real entre as duas SANs e, em seguida, usar o VMWare SRM para inicializar as VMs do outro lado. o evento de uma falha.

Para um orçamento de US $ 10.000, você deve conseguir um único array SAN e usar a função High Availability do VMWare, o que significa que no caso de uma falha de um host, todas as suas VMs são inicializadas imediatamente em outros hosts. Isso torna a SAN um ponto único de falha e você precisa garantir que ela seja rápida o suficiente para não se tornar um gargalo que afeta seu trabalho diário.

Para um orçamento de US $ 1.000, sugiro um NAS "barato" (como uma série QNap 4xx) e exponho o armazenamento compartilhado por meio do iSCSI. Eles só expõem interfaces de 1GbE, o que seria bom executar coisas como um controlador de domínio, mas não muito mais (eu tentei isso, nós temos um qnap 6Tb aqui e não é apenas para o trabalho de carga pesada iSCSI).

Pessoalmente, o que eu sugiro, se você puder pagar pelo tempo de inatividade, é ter um segundo servidor SQL instalado no Host B e enviar o log de transações para ele. Talvez você nem precise comprar hardware adicional para isso e verifique com seu representante da microsoft, mas talvez nem precise licencia-lo. Portanto, mantenha-os ativos e, em seguida, aponte seus aplicativos para o segundo servidor SQL quando o host ficar off-line.

Além disso, desaconselho strongmente clonar seu controlador de domínio, pois há problemas em retroceder após uma restauração (ou um instantâneo). Eu sugeriria novamente ter dois controladores de domínio, um em cada host, e permitir que sua própria replicação (DFS) lidasse com isso.

Para sua contabilidade e servidores RDS, sua solução de clonagem deve funcionar bem. Eu não sei o que você está executando no seu RDS, mas decidimos que podemos perder até 24 horas de dados sem repercussões sérias, então se você fosse apenas cloná-lo durante a noite você pode estar bem com isso.

    

Answer 2

Procure no VMware vSphere 5.0 com VSA (Virtual Storage Appliance). Isso permitirá que você execute um cluster nas duas máquinas e replicará automaticamente as VMs entre as duas máquinas em tempo real.

Os dados no SQL Server não são considerados aceitos até serem gravados no log de transações. Uma vez que tenha sido gravado no disco, o aplicativo cliente receberá o aviso de que a gravação foi concluída. Mesmo se as páginas que foram alteradas ainda estiverem contidas na memória e não gravadas no disco, as gravações no registro serão concluídas. Quando o banco de dados ficar online no novo host, as transações marcadas como concluídas no log serão lidas no log e aplicadas antes que os usuários possam efetuar login no sistema.

Nesta configuração, você deve estar executando dois controladores de domínio com um de cada servidor (as regras podem ajudar a garantir que isso aconteça) para que, quando o host ficar inativo, um controlador de domínio ainda esteja on-line. OSs convidados voltam on-line.