No momento, gostaria de combinar meu SQL Server departamental em uma grande instância do SQL Server 2008 em dois servidores (por motivo de redundância).
Como e qual é a melhor maneira de abordar isso? é através dos recursos de clusterização ou Log shipping ou VMware (hypervisor) High Availability?
Observação: esse servidor de banco de dados não pode ser desativado, pois também hospeda o banco de dados do VCenter e também o banco de dados de monitoramento do servidor.
o SQL Server está espalhado por vários servidores menores 3-4 SQL Server 2000 e 2005 com o total de 70 DB dentro desses servidores, o que eu gostaria de fazer / construir é migrar todos eles para o SQL Server 2008 no qual Devo torná-lo redundante, de modo que, se um servidor falhou por qualquer motivo, a outra instância pode simplesmente buscá-lo imediatamente.
Assim, a partir de vários SQL Servers menores, quero consolidá-los em um SQL Server 2008 x64 mais poderoso. mas até agora não sei qual tecnologia é adequada para isso ou se é possível fazer no SQL Server 2008 Standard.
Qualquer sugestão e comentário seria muito apreciada.
is it through clustering or Log shipping or VMware (hypervisor) High Availability features ?
Não, não, não.
MIRRORING, 3 servidores (um pode ser um pequeno e gratuito, apenas decidindo que continua funcionando ativo).
O envio de logs está lento / atrasado, o clustering / vmware deixa um banco de dados como um ponto fraco que ainda pode ser corrompido.
A TomTom está correta, mas deixe-me expandir alguns pontos importantes:
O envio de log é ótimo para DR, não ótimo para dados atualizados. Seus dados são sempre antigos, digamos 15 minutos a 1 hora ou até mais antigos, dependendo das configurações. A re-conexão não é perfeita. Você precisa reconfigurar seu aplicativo para apontar para o novo sistema. Além disso, o segundo banco de dados não está on-line, geralmente está no modo de recuperação (para aplicar os logs), portanto, é necessário retirá-lo do modo de recuperação para usá-lo. É por isso que geralmente é usado apenas para recuperação de desastres.
O cluster não é o que você quer quando você está em um link com qualquer latência. Ele fornece uma interface SQL altamente disponível, mas não torna seus dados altamente disponíveis, a menos que sua SAN possa fazer isso por você. Eu nunca tentaria agrupar entre DC's.
Espelhamento. Neste caso, o espelhamento é seu amigo. O espelhamento possui dois modos básicos: síncrono ou síncrono. Comum a ambos os modos: Cada servidor SQL tem sua própria cópia local do banco de dados, mas apenas um servidor SQL pode "possuí-lo". Em outras palavras, mesmo que você tenha três servidores SQL, apenas um deles está realmente em uso. Os outros estão todos no modo de espera, esperando para serem ativados.
No modo Síncrono, quando uma transação de gravação é recebida, ela é executada por todos os servidores SQL ao mesmo tempo, e a próxima transação não é processada até que cada servidor SQL tenha relatado que está comprometendo a transação. Isso garante que todos os servidores SQL tenham dados completamente atualizados. Isso é ótimo para links de alta latência e baixa latência, não tão bons para links de alta latência, pois eles efetivamente reduzem a velocidade do seu banco de dados para a velocidade do parceiro mais lento.
No modo assíncrono, o SQL Server não aguarda que todos os outros parceiros SQL confirmem a transação. Apenas comete isso localmente e segue em frente. Cada outro servidor SQL pode ter algumas transações por trás, especialmente se os links entre eles estiverem carregados. Isso significa que você obtém acesso de velocidade total ao banco de dados ativo, mas corre o risco de perder alguns dados no caso de um failover. Além disso, esse modo só está disponível na edição do SQL Enterprise.
VMWare HA. Bem, esta é uma lata inteira de vermes. É bom, mas novamente você precisa compartilhar a mesma SAN para que ela funcione. Ou você está falando sobre o VMWare FT (tolerância a falhas)? Se você é, eu sugiro esquecer sobre FT para um servidor SQL no momento. O FT é ótimo na teoria, e eu estou usando até mesmo uma VM, mas para a maioria das implementações os sacrifícios que você precisa fazer são muito grandes. Além disso, como as VMs estão em confronto entre si, os problemas de largura de banda afetarão o desempenho.
Para gerenciar a capacidade de failover automagicamente, o Clustering fornece uma instância virtual à qual você se conecta e tudo é feito invisível para o usuário. Para o espelhamento, você pode conseguir isso facilmente com a função de Balanceamento de carga de rede em execução em :1433 , de modo que, quando o SQL Server sair da rede, a instância virtual alterne os outros nós. Como alternativa, dependendo do suporte do aplicativo, você pode especificar servidores espelho alternativos na cadeia de conexão SQL.
Você pode estar interessado na resposta que recebi da minha pergunta, SQL Server 2008 R2 100% de disponibilidade .