Balanceamento de carga com alta disponibilidade - SQL Server + IIS usando AWS

1

Este é meu primeiro balanceamento de carga com alta disponibilidade usando o Windows e o SQL Server. Procurando por alguma validação e entrada na minha configuração planejada.

Agora, normalmente, quando quero criar um site com balanceamento de carga de alta disponibilidade, separo o banco de dados em uma instância do Multi-AZ RDS e, em seguida, gero várias instâncias do Ec2 que apontam para o RDS. Isso sempre funcionou bem com o MySQL, mas o SQL Server RDS não suporta o Multi-AZ.

Eu li que o SQL Server pode ser configurado como uma testemunha, que (corrija-me se eu estiver errado) espelha um banco de dados em tempo real, a menos que não possa alcançar o banco de dados, ponto em que se torna o banco de dados primário. A configuração abaixo carregará adequadamente as solicitações de entrada ao usar os mesmos dados do banco de dados? Se a instância primária ficar inativa em algum momento e, em seguida, voltar, ela "rastreia" automaticamente os dados do servidor? Você faria isso de maneira diferente?

    
por Alec Sanger 18.02.2013 / 17:54

1 resposta

1

Com base no diagrama que você forneceu, você teria uma terceira caixa do SQL Server para permitir um failover automático do banco de dados espelhado. Consulte este link para obter uma descrição do espelhamento em uma configuração de alta disponibilidade - link .

Essa configuração funcionará, desde que você tenha a terceira instância do SQL Server para atuar como a função de testemunha. Isso funcionará um pouco como a maneira como o Windows Clustering funciona, onde você precisará ter a maioria dos servidores online para manter on-line o banco de dados espelhado. Se o seu servidor principal ficar offline, o servidor de espelhamento (secundário \ backup) assumirá a função principal. Quando o servidor voltar a ficar online, o banco de dados deverá se sincronizar.

Outra consideração também para essa configuração é que seu aplicativo depende apenas do banco de dados. Como o espelhamento é específico do banco de dados, e não específico do servidor, pode haver casos em que apenas um banco de dados seja "encaminhado" para o servidor secundário. Onde, se o aplicativo da Web for dependente de vários bancos de dados, será necessário dar uma consideração extra sobre como lidar com isso (isso é resolvido no SQL Server 2012 com grupos de disponibilidade)

    
por 18.02.2013 / 22:01