Configuração dos servidores para melhorar o desempenho e oferecer redundância para o site ASP.NET com o SQL Server

Question

Estou administrando um site razoavelmente grande (atualmente cerca de 300 mil visualizações de páginas por dia), que deve crescer rapidamente. Atualmente, tanto o IIS quanto o SQL Server estão sendo executados em um servidor quad core, com discos rígidos SAS RAID 10 e 32 GB de RAM. Um servidor menos potente é configurado como backup a frio. Bancos de dados são sincronizados diariamente e também os arquivos do site são movidos para o servidor de backup diariamente. Caso o servidor principal fique inativo, o site pode voltar a funcionar em poucas horas, mas isso não é o ideal. Estou procurando uma solução que ofereça:

• melhor desempenho. No futuro, será necessário criar um web farm para lidar com as solicitações, portanto, preciso planejar isso.
• redundância. Se um servidor ficar inativo, o site não deve ficar inativo.
• backup. Os dados são críticos, portanto a configuração do SQL Server deve ser de tal forma que não percamos dados com mais de 1 dia (não é grande problema se os dados do último dia forem perdidos)

Além disso, a solução deve incluir recuperação de desastres. Se o data center ficar em chamas, precisaremos de uma solução para ficar on-line em menos de um dia (estamos pensando em manter uma cópia dos dados e do site em nossos servidores locais, mas precisaremos de uma maneira de ter o processo o mais automático possível. O servidor primário está hospedado em um data center na Alemanha).

O banco de dados é de 50 GB +, enquanto o aplicativo da Web é pequeno.

    

Answer 1

Isso tudo parece bastante normal. Vou assumir o SQL Server 2008 R2 ou o SQL Server 2012 aqui para a parte do banco de dados.

A primeira coisa que você precisa fazer é obter o IIS do SQL Server e colocá-lo em sua própria máquina. Você também precisará obter algum tipo de balanceador de carga para colocar na frente do farm da web. Eu recomendaria algo como um F5 ou Cisco, embora você pudesse usar um balanceador de carga baseado em Linux se tiver uma pessoa Linux em casa. Uma vez que você tenha o balanceador de carga no lugar, você precisa aumentar o farm da web fazendo isso é muito fácil. Você acabou de comprar outro servidor, configurá-lo como normal e adicioná-lo ao farm no balanceador de carga.

Quanto ao SQL HA, provavelmente você desejará observar o espelhamento de banco de dados do SQL Server. Isso fornecerá a você dois servidores no data center local (embora você possa colocá-los em diferentes data centers) com failover automático se você tiver o Enterprise Edition do SQL Server.

Configurar os backups para copiar do datacenter para o seu escritório não é tão difícil. Basta configurar um site para o site VPN e copiar os arquivos pela rede. A largura de banda e a latência se tornam o único problema nesse ponto.

Seu requisito de DR vai ser a parte mais difícil. Ter um requisito de que você volte a funcionar em menos de um dia significa que você precisa ter um contrato com outro datacenter e que precisa ter servidores já nesse datacenter. Sem ter este equipamento já em funcionamento, você nunca atingirá o objetivo de recuperar o funcionamento do site dentro de um dia, já que obter novos servidores pode levar semanas (ou mais, dependendo do tamanho do desastre, pois você não será o único pessoas tentando comprar novos servidores).

No site do servidor da Web, o DR é fácil. Simplesmente aponte os servidores DNS para o IP público no site de DR.

Para o lado do SQL Server, você provavelmente desejará examinar o envio de logs de transações do site primário para o site de DR. Se você quiser uma configuração mais fácil, consulte os Grupos de Disponibilidade AlwaysOn do SQL Server 2012. Eles farão failover automático, sincronização e replicação de dados assíncrona, etc. Os Grupos de Disponibilidade AlwaysOn exigem um domínio do Active Directory, portanto, é necessário verificar essa configuração primeiro.

Se você ainda não percebeu, o DR não é barato ou fácil.

    

Answer 2

Mais sobre o SQL Server:

A MS publicou muitos livros gratuitos, um dos quais é chamado de Guia de Soluções AlwaysOn do Microsoft SQL Server para Alta Disponibilidade e Recuperação de Desastres .

Você encontrará mais orientação técnica aqui .

Acontece que o backup no do Windows não é tão fácil como no Linux .

Alta disponibilidade

Em geral, você pode fazer essas coisas pelos sites:

• Deixe suas teias sem estado; eles não devem usar o estado da sessão nem visualizar o estado - isso complica a escalabilidade. Em vez disso, deixe o URL decidir o que é exibido; evitando o estado compartilhado, você pode usar caches efetivamente, como o NGINX na frente, que fala HTTP de plataforma cruzada:
• Fazer cache usando HTTP - NÃO usando 'memcached', 'verniz' ou 'MS Velocity' - porque você não quer um cache de aplicativo se puder evitá-lo - é uma muleta. No entanto, para armazenar corretamente usando HTTP você precisa de ETags ou cabeçalhos Last-Modified, e você precisa corrigir para que o ASP.Net retorne 304 Not Changed para páginas dinâmicas que realmente não foram alteradas - isso pode envolver alguma programação corretiva .
• Se você precisar do estado por motivos legados ou qualquer outra coisa, considere escrever um provedor de estado personalizado . Posso recomendar ter um armazenamento de valor de chave NoSQL como backend que suporte tanto a falha de failover / nó quanto a expiração de chave. Eu recomendo o excelente Riak com recursos como isto . Se você adicionar mais aplicativos que não falam Microsoft, ainda poderá usar as interfaces HTTP do Riak. Lembre-se de serializar com algo universalmente conhecido, como BSON ou MessagePack. Ao fazer o estado compartilhado dessa maneira, você ainda pode dimensionar seus sites enquanto mantém todo o estado da sessão distribuído.

Em geral, você pode fazer essas coisas por dados:

• Comece a separar aplicativos grandes e monolíticos em aplicativos únicos com armazenamentos individuais. Com isso, você pode fazer escolhas mais conscientes sobre como mover esses dados para centros de dados ou servidores de redundância.
• Você pode adaptar um modo de programação muito facilmente distribuído, como usar o estilo CQRS de gravar lógica de domínio com eventos e fornecimento de evento de entidades. Isso requer alguns dos seus programadores.
• Comece com a replicação assíncrona (consulte a seção superior) nesta resposta.
• Comece a escrever Sagas para lidar com inconsistências decorrentes de várias fontes de verdade (por exemplo, no caso de uma divisão de rede ou leituras separadas na mesma linha de versão em um banco de dados)
• Comece a migrar para um armazenamento de dados que realize com mais facilidade o HA - por exemplo, Riak ou Cassandra.

Boa sorte!