Suggested ou Best practices for network architecture para o aplicativo da Web do asp.net

Question

Atualmente, tenho um servidor que executa um aplicativo da Web ASP.net (no IIS) e também está executando um banco de dados do SQL Server .

Estou obtendo mais e mais tráfego e, em breve, precisarei aumentar a quantidade de tráfego com que posso lidar para que a experiência do usuário não seja comprometida. Eu não estou falando sobre o tipo de tráfego do Google ou Amazon.

A minha pergunta é: o que é uma rede realista e um layout de servidor para me proporcionar um desempenho melhor e uma vantagem razoável sobre redundância sem esperar pagar quantias enormes de dinheiro.

Eu gostaria de manter o tempo no mínimo razoável, mas não estou esperando uma solução 100% disponível o tempo todo.

Eu estava considerando algo como um firewall, loadbalancer, dois servidores Web que executam o IIS e um SQL Server com uma especificação razoável (talvez um Dell R710 com 16 GB ou mais de RAM) e possivelmente um segundo servidor SQL que podemos agrupar no outro.

Gostaria que o sistema fosse dimensionável de tal forma que, se em um ou dois anos aumentássemos drasticamente nosso tráfego, poderíamos adicionar servidores adicionais para atender ao aumento do tráfego sem a reconstrução de todo o sistema.

Todas as sugestões ou links que me apontam na direção certa são perfeitas.

Nota: Eu tenho passado por highscalability.com mas a maioria desses estudos de caso e artigos estão se referindo a mega sites como o StackOverflow, Amazon e outros sites super enormes com volumes gigantes de tráfego. Eu não estou naquele barco ainda.

    

Answer 1

O problema clássico em que esse tipo de arquitetura é executado é que os servidores da Web são muito fáceis de dimensionar, enquanto os bancos de dados são muito mais fáceis de ampliar.

O que você sugeriu é um bom começo. Eu tive uma experiência semelhante e estou no ponto em que tenho:

• 2x servidores web IIS 7.5 com configuração compartilhada do IIS e DFS-R replicando os diretórios de conteúdo da Web.
• 2 bancos de dados do SQL 2008 R2 em um cluster do MSCS
• 2x servidores AD / DNS para suportar o cluster
• 2x Balanceadores de carga HaProxy na frente dos servidores da Web

Obviamente, você pode se safar sem o AD e com um único servidor SQL se não se importar muito com a disponibilidade.

Quando o SQL se torna o gargalo, eu vou (depois de eliminar problemas no aplicativo) obter um hardware maior para os servidores SQL. Quando o IIS se torna o gargalo, eu posso simplesmente comprar mais caixas do IIS e jogá-las dentro. Não é incomum ver aplicativos com algumas grandes caixas de banco de dados na parte de trás com massas de servidores da Web na frente.

A outra questão principal é o custo de licenciamento. Em muitos casos, o custo do hardware torna-se irrelevante, porque as licenças de software que você precisa para executar isso se tornam muito maiores. Para agrupar o servidor SQL, acredito que você precise do SQL Server Enterprise e do Windows Enterprise Edition - são muito mais do que as versões Standard.

Por fim, você precisa decidir com o que mais se importa: baixo custo, desempenho ou disponibilidade. A disponibilidade é, na minha experiência, muito cara.