Pilhas de IIS / MSSQL tolerantes a falhas de construção (Sql Clustering?)

Question

Tivemos uma falha de invasão ontem em um servidor que hospedava bancos de dados e IIS.

Estamos tentando determinar o melhor caminho a seguir em termos de nosso ambiente de hospedagem IIS e MSSQL.

Gostaríamos de redundância no lado do IIS e no lado do SQL.

Para algumas de nossas aplicações, estamos usando o pfSense para balancear a carga de dois servidores da web (sessões persistentes não funcionam bem, então passamos para o estado da sessão no banco de dados). Esses dois servidores web atingem uma única instância do MSSQL executando o SQL Express (grátis, nossos bancos de dados são muito pequenos, o maior é de 1 GB).

Sinto-me razoavelmente confiante em nosso balanceamento de carga do IIS, como quando executamos patches, "simplesmente funciona" e eu realmente não preciso fazer muita coisa.

No entanto, nossa infraestrutura do SQL Server me preocupa.

Qual é a melhor maneira de construir uma pilha sql tolerante a falhas?

Edit: agora que penso nisso, um cluster não teria necessariamente resolvido nosso problema. Nós tivemos dois drives falharem em um RAID5. Um 100% falhou, o outro ainda não morreu, mas marcado por falha com setores defeituosos. Tínhamos um banco de dados que estava nos clusters defeituosos que precisávamos restaurar de um backup. Um cluster teria quebrado ou colocado os dados incorretos em todo o cluster. Argh!

    

Answer 1

Embora esse não seja o foco da questão, quero salientar que você está incorrendo em uma penalidade de desempenho usando o estado da sessão no banco de dados. Existem alguns problemas desagradáveis (com algumas soluções alternativas) que ocorrem com esse modelo de armazenamento de sessão. Vale a pena o tempo para fazer com que as sessões persistentes funcionem corretamente para que você possa usar o armazenamento InProc - mesmo que isso signifique uma carga assimétrica nos front-ends da web.

Eu iria me aprofundar na replicação de mesclagem, particionamento, replicação transacional peer-to-peer e outras técnicas de dimensionamento / FT / HA com o SQL Server, mas isso parece um exagero para o seu ambiente - e requer SQL não-Express. Servidor. O clustering de failover do SQL Server com o MS Cluster Services, limitado como está, foi projetado para tolerância a falhas. No entanto, a configuração usual de único site depende do armazenamento compartilhado, o que não ajuda em nada.

Recomendarei que você se concentre em mais armazenamento de qualidade, usando uma SAN (ou até mesmo um NAS, dependendo da carga e do orçamento) com o RAID 10 (ou 6, se não puder pagar) com hot spares, backups freqüentes e, de preferência, em um dispositivo que procura ativamente por problemas de integridade - não apenas um monte de discos baratos. (Embora, você poderia fazer pior do que OpenFiler em hardware decente.)

Se você está limitado ao RAID 5 em HDDs nos servidores (sem armazenamento compartilhado), procure em cluster de failover "multi-site" usando a replicação , embora você possa encontrar o preço para implementar (o SQL Server Enterprise Edition é um requisito mínimo) muito proibitivo.