AlwaysOn SQL Server 2012 - alguma opção para true ativo / ativo?

Question

Estou prestes a atualizar e consolidar um grupo do SQL Server 2008R2 em um único SQL Server 2012. Eu quero ter alta disponibilidade e procurando as diferentes opções. O número de bancos de dados é razoavelmente alto (150+), então o DBMirroring está fora de questão.

Agora estou vendo "AlwaysOn Availability Group" e "AlwaysOn failover cluster" e não consigo descobrir o caminho a seguir ..... talvez ainda mais opções estejam disponíveis.

O armazenamento em cluster pode ser uma boa maneira de fazer as coisas, mas é realmente irritante ter um grande servidor de energia sem fazer nada, mas esperando que o servidor principal falhe.

Existe alguma maneira de fazer um cluster ativo / ativo real no SQL Server (balanceamento de carga real)?

    

Answer 1

O Microsoft SQL Server não suporta um esquema de balanceamento de carga 'real' fora da caixa. AFAIK, isso ainda é verdade com o SQL Server 2012. (Alguém vai me esclarecer se eu estiver errado.) Não importa se estamos falando de espelhamento de banco de dados ou AlwaysOn ou clusters.

(A fim de martelar esse ponto em casa, a MS parece chamar clusters do SQL Server "clusters de failover do SQL Server" ultimamente. Pedantics.)

Se você quiser balancear a carga dos seus bancos de dados, você mesmo terá que fazer o trabalho pesado com algum tipo de fragmentação, federação ou replicação. (Observe que a federação (por visualizações) está no produto desde o SQL Server 2000, mas não era muito popular.) E, é claro, isso significaria modificar seus bancos de dados ou os próprios aplicativos, o que é quase sempre também muito trabalho ou viola seus contratos com fornecedores. Com 150 bancos de dados, é muito mais intransponível.

Você pode ter um cluster ativo-ativo, mas o importante é ter que distribuir cuidadosamente seus bancos de dados em seus nós para dividir a carga. Com 150 bancos de dados, isso pode ser mais granular do que se você tivesse apenas cinco bancos de dados, mas se tiver um banco de dados com uma tonelada de carga e 149 que sejam leves ou raramente usados, ainda poderá encontrar uma máquina atolada e outro não é. E, alguns bancos de dados estão ocupados às vezes e dificilmente ocupados em outros momentos. O que significa que tudo pode acontecer quando um usuário decide executar algum processo pesado.

É claro que você deve ser capaz de suportar toda essa carga em um único nó quando fizer o failover, por qualquer motivo, mesmo que seja algo mundano, como consertar o Windows. Se você só corrige durante períodos de tráfego lento conhecidos, isso é ótimo. Se você não tiver períodos lentos, ou se o failover ocorrer porque o hardware realmente tem uma falha, o outro nó pode não aguentar a carga e seus usuários ficarão sem sorte. Se você pensar assim, ter a segunda máquina "sem fazer nada" não é tão irritante. Pelo menos você sabe que vai demorar todo o tráfego que o primário costuma fazer.

    

Answer 2

Os grupos AlwaysOn Availability também suportam réplicas somente leitura - isso permitiria o balanceamento de carga de leituras e, até onde eu saiba, é a primeira vez que tal coisa foi disponibilizada com o SQL Server 2012.

2012 também suporta o cluster clássico ativo / ativo que é frequentemente referido (o que acontece se você adicionar mais de 2 nós, ativo / ativo / ativo yuck!), mas tenha em mente que tem limitações em que está fornecendo 2 instâncias e assim que um desce, o outro servidor restante fica potencialmente batido com o dobro da carga ou mais.

Além das réplicas somente leitura com balanceamento de carga, os Grupos de Disponibilidade oferecem muito mais flexibilidade, especialmente com um terceiro servidor testemunha assíncrono que pode estar em um site de DR remoto.

    

Answer 3

Outra coisa que você poderia fazer é configurar várias instâncias do servidor sql em cada nó e agrupar cada instância. Divida seus bancos de dados em cada instância. Cada instância em si é ativa / passiva, mas se você executar cada instância em um nó separado, distribuirá efetivamente a carga. Você ainda precisa garantir que, se falhar, um único nó pode suportar o recurso