Nos próximos meses, pretendemos adicionar Failover e Load Balancing ao nosso ambiente. Teremos 2 servidores que são Hosts Hyper V. Queremos ter um servidor de aplicativo IIS e um servidor de banco de dados SQL em ambos os hosts. Dessa forma, se uma caixa falhar, a outra estará lá para ocupar o seu lugar. Agora minha confusão vem de algumas pesquisas no Google que venho fazendo. Pelo que posso dizer, parece haver clustering SQL/configuração de transação ponto a ponto, bem como clustering Hyper-V. Não tenho certeza do que funcionaria melhor nesta situação. Os hosts também terão outros servidores aleatórios, como o System Center, nosso servidor de tickets, o servidor Exchange Admin e vários outros divididos entre os dois. Portanto, não tenho certeza se agora o cluster Hyper-V será a pior opção.
Obrigado.
Responder1
Com o clustering Hyper-V, você tem um pool de servidores Hyper-V (2+), todos conectados ao mesmo conjunto de armazenamento de rede, para que os LUNS estejam disponíveis para todos os servidores no cluster Hyper-V. Você deve ter armazenamento de rede para esta configuração. Com a migração ao vivo do Hyper-V, você pode mover uma VM em execução de um host Hyper-V para outro. Isso permite que a carga de trabalho de um servidor seja transferida para outro se o servidor falhar. Isto proporciona redundância física se os servidores restantes forem capazes de lidar com a carga das VMs adicionais. Esta configuração não protege você contra corrupção do sistema operacional e dos próprios aplicativos da VM. (Verhttp://technet.microsoft.com/en-us/library/dd446679(WS.10).aspxpara obter detalhes sobre esta configuração.)
SQL tem sua própria redundância disponível com diversas opções de clustering diferentes. Você pode fazer clustering ativo/passivo tradicional, com um nó ativo e um ou mais nós passivos. Esta configuração requer um disco compartilhado entre os servidores e é montada apenas no nó ativo. SQL também oferece suporte a vários tipos de replicação que permitem vários nós ativos. Este método não requer armazenamento compartilhado e mantém uma cópia separada do banco de dados em cada servidor. (Verhttp://msdn.microsoft.com/en-us/library/ee523927(v=sql.100).aspxpara opções de alta disponibilidade do SQL 2008)
O clustering no nível SQL protege contra falha no sistema operacional ou aplicativo em um nó individual, permitindo failover automático nesse cenário. Se cada instância estiver em um servidor Hyper-V diferente, você também estará protegido contra falhas de hardware. Além disso, alguns dos métodos de cluster para SQL Server protegem contra corrupção do banco de dados em nós individuais. Usar um cluster Hyper-V e apenas uma única instância do servidor SQL não protege você contra falhas de sistema operacional/software na VM. Se o tempo de inatividade não for um grande problema, você poderá restaurar a partir de um snapshot da VM em um curto espaço de tempo.
Editar: Esqueci a parte do balanceamento de carga do IIS.
Para balanceamento de carga do IIS, você pode usar o Window Network Load Balancing, que cria um IP virtual que é compartilhado entre os dois hosts. (Verhttp://technet.microsoft.com/en-us/library/cc770689(v=ws.10).aspx)
As mesmas regras se aplicam ao servidor IIS e ao servidor SQL para saber se o clustering Hyper-V ou NLB é a opção certa. Além disso, para suas outras VMs, a menos que elas também estejam agrupadas/com balanceamento de carga, elas não estarão protegidas contra um problema com o host Hyper-V sem o clustering Hyper-V.
Responder2
Se você pretende espelhar convidados virtuais entre dois hosts, evite o clustering HyperV. Isso permite que os convidados virtuais sejam iniciados em outro host quando um deles falha e permite equilibrar cargas no nível do host.
Se você estiver fazendo clustering SQL, poderá realizar a etapa de backup do SQL muito mais rapidamente e começar a lidar com solicitações. E para balanceamento de carga da web, use o NLB (envolva o pessoal da rede para fazer isso da maneira certa, leia sobre NLB multicast). E use o clustering do Exchange entre dois virtuais do Exchange. Você será muito mais feliz.