Como balancear o SQL Server 2008 para aplicativos ASP.NET de alto uso?

Imagine que você tenha um aplicativo Web bem-sucedido que usa ASP.NET e IIS 7. Ele gera muitas chamadas para um banco de dados SQL Server 2008 e espera-se que esteja disponível ao público com 99,9% de tempo de atividade (tempo de inatividade de 8 horas, 45 minutos por ano).

Nossos objetivos são:

• Instale as atualizações do Windows no servidor sem causar tempo de inatividade para nossos clientes
• Impedir que falhas de hardware no servidor reduzam a velocidade dos aplicativos ASP.NET devido a tempos limite

Diferente do balanceamento de carga de um aplicativo ASP.NET, o SQL de balanceamento de carga parece ser muito mais difícil. Quais são as práticas recomendadas para configurar um cluster simples do SQL Server 2008 R2 com balanceamento de carga para um Micro-ISV que usa a pilha da Microsoft?

Se você precisar de alta disponibilidade, o Windows / SQL Server Clustering ou o SQL Server Database Mirroring oferecem soluções. O armazenamento em cluster exige muito planejamento e familiarização, se você nunca fez isso antes, mas será transparente para o aplicativo.

O balanceamento de carga é possível com o SQL Server, mas não é para os fracos de coração. É uma solução que usa o Windows Network Load Balancing (NLB) na frente dos servidores SQL. Os próprios servidores SQL no NLB são mais fáceis de gerenciar se forem somente leitura, mas podem ser de leitura e gravação se você usar a replicação transacional com assinantes atualizáveis. Esse tipo de replicação está marcado para descontinuação em uma versão futura.

Uma possibilidade final são os bancos de dados compartilhados escaláveis, mas eles são definitivamente somente leitura.

Mais leitura:

Veja os livros de Allan Hirt's Apress sobre alta disponibilidade do SQL Server 2005 e a replicação Pro SQL Server 2005/2008 do Apress.

Bancos de dados compartilhados escaláveis: http://technet.microsoft.com/en-us/library/ms345392.aspx

Os sistemas de banco de dados relacional raramente têm balanceamento de carga da mesma maneira que os servidores da web. O problema com a abordagem clássica do balanceamento de carga é que todos os seus bancos de dados precisam estar em constante sincronização. O modelo relacional é inútil se dois servidores não tiverem estado idêntico em nenhum momento.

Da sua pergunta, não parece que você esteja tentando realizar o balanceamento de carga, que é principalmente uma medida de desempenho para garantir que apenas o número de usuários atinja cada servidor que ele possa suportar. Parece que você deseja uma configuração de alta disponibilidade . Como você diz que está usando o SQL Server, eu analisaria os failovers. Isso significa que, se o banco de dados primário não estiver disponível, os clientes tentarão acessar os servidores de failover. O SQL Server lida com a sincronização da instância principal e de cada failover, além de sincronizar novamente a instância primária com o failover quando o primário volta a ficar offline.

OK, vamos lá. NÃO PODE SER FEITO. Não sem alterações no aplicativo.

• Instale atualizações - use clustering ou espelhamento para garantir que você tenha DOIS bancos de dados que funcionem ou possam fazer failover para outro computador mais rapidamente. Espelhamento fortemente preferido.
• Reescreva o aplicativo para lidar com isso (ou seja, as conexões falham, precisa ser reconectado de forma transparente para que ele se conecte a uma cópia).

Perceba que você ainda precisa desativar o aplicativo para manutenção ao implantar uma nova cópia / fazer alterações no esquema db.

Uma resposta econômica aqui é frequentemente proteger o banco de dados com uma camada de servidor barata e equilibrada que hospeda serviços de aplicativos que fornecem processamento lógico e armazenamento de dados que, de outra forma, estariam amarrando recursos do banco de dados. Obviamente, isso exige alguma reflexão sobre a volatilidade dos dados e estratégias de armazenamento em cache.

Deixe-me dar uma resposta jurássica. Se seus objetivos incluem "instalar atualizações do Windows", você está além do resgate.

Estou com barba grisalha e me lembro de uma época em que um aplicativo poderia ser executado 10 anos sem sofrer "atualizações do sistema operacional". A vida útil de um aplicativo foi medida em décadas, não em anos.

Portanto, meu conselho é o seguinte: estabeleça uma versão funcional do banco de dados do SQL Server + aplicativo e isole o servidor de banco de dados das atualizações da Microsoft. Se não estiver quebrado, não conserte.

Use discos RAID com troca a quente.

Tenha um servidor de banco de dados de imagens espelhadas (por sugestão da TomTom) em mãos, caso o seu hardware exija.