Recomendação de arquitetura para o site ASP.NET balanceado de carga

Question

Atualização 2009-05-21

Eu tenho testado o método nº 2 de usar um único compartilhamento de rede. Está resultando em alguns problemas com o Windows Server 2003 sob carga:

http://support.microsoft.com/kb/810886

Atualização final

Recebi uma proposta de um site do ASP.NET que funciona da seguinte maneira:

Hardware Load -Balancer -> 4 IIS6 Web Servers -> SQL Server DB com cluster de failover

Aqui está o problema ...

Estamos escolhendo onde armazenar os arquivos da Web (ASPX, HTML, CSS, Imagens). Duas opções foram propostas:

1) Crie cópias idênticas dos arquivos da Web em cada um dos 4 servidores do IIS.

2) Coloque uma única cópia dos arquivos da Web em um compartilhamento de rede acessível pelos 4 servidores da Web. Os Webroots nos 4 servidores do IIS serão mapeados para o compartilhamento de rede única.

Qual é a melhor solução? A opção 2 obviamente é mais simples para implantações, pois exige que a cópia de arquivos para apenas um único local. No entanto, me pergunto se haverá problemas de escalabilidade, pois quatro servidores da Web estão acessando um único conjunto de arquivos. Iis cache esses arquivos localmente? Ele chegaria ao compartilhamento da rede em cada solicitação de cliente? Além disso, o acesso a um compartilhamento de rede sempre será mais lento do que obter um arquivo em um disco rígido local? A carga no compartilhamento da rede se torna substancialmente pior se mais servidores do IIS forem adicionados?

Para dar perspectiva, isso é para um site que atualmente recebe ~ 20 milhões de acertos por mês. No pico recente, estava recebendo cerca de 200 hits por segundo.

Informe -me se você tem uma experiência específica com essa configuração. Obrigado pela contribuição.

ATUALIZAÇÃO 2009-03-05

Para esclarecer minha situação - as "implantações" neste sistema são muito mais frequentes do que um aplicativo típico da Web. O site é o front -end para um CMS de back office. Cada vez que o conteúdo é publicado no CMS, novas páginas (ASPX, HTML, etc) são impulsionadas automaticamente para o site ao vivo. As implantações são basicamente "sob demanda". Teoricamente, esse impulso pode acontecer várias vezes em um minuto ou mais. Portanto, não tenho certeza se seria prático implantar um servidor da Web no momento. Pensamentos?

Answer 1

Eu compartilharia a carga entre os 4 servidores. Não é muitos.

Você não quer esse ponto único de discórdia ao implantar nem esse ponto único de falha na produção.

Ao implantar, você pode fazê -los 1 de cada vez. Suas ferramentas de implantação devem automatizar isso notificando o balanceador de carga de que o servidor não deve ser usado, implantando o código, qualquer trabalho de pré-compilação necessário e, finalmente, notificando o balanceador de carga de que o servidor está pronto.

Usamos essa estratégia em um fazendeiro de mais de 200 web e funcionou bem para implantar sem interrupção de serviço.

Answer 2

Se sua principal preocupação é o desempenho, o que presumo que seja, pois você está gastando todo esse dinheiro em hardware, não faz sentido compartilhar um sistema de arquivos de rede apenas por conveniência. Mesmo que as unidades de rede tenham um desempenho extremamente alto, elas não terão um desempenho tão bom quanto as unidades nativas.

A implantação de seus ativos da Web é automatizada de qualquer maneira (certo?) Então, fazê -lo em múltiplos não é realmente um inconveniente.

Se for mais complicado do que você está deixando transparecer, talvez algo como Deltacopy seja útil para manter esses discos em sincronia.

Answer 3

Uma das razões pelas quais o compartilhamento central é ruim é porque torna a NIC no servidor de compartilhamento o gargalo para toda a fazenda e cria um único ponto de falha.

Answer 4

Com o IIS6 e 7, o cenário de usar um compartilhamento único de rede nas máquinas N Web/App Server anexado é suportado explicitamente. A MS fez uma tonelada de testes de perfis para garantir que esse cenário funcione bem. Sim, o cache é usado. Com um servidor duplo-nic, um para a Internet pública e outra para a rede privada, você terá um bom desempenho. A implantação é à prova de balas.

Vale a pena dedicar um tempo para compará -lo.

Você também pode avaliar um provedor de caminho virtual do ASP.NET, que permitiria implantar um único arquivo zip para todo o aplicativo. Ou, com um CMS, você pode servir conteúdo de um banco de dados de conteúdo, em vez de um sistema de arquivos. Isso apresenta algumas opções realmente boas para versões.

VPP para ZIP via #ziplib.

VPP para ZIP via Dotnetzip.

Answer 5

Em uma situação ideal de alta disponibilidade, não deve haver um único ponto de falha.

Isso significa que uma única caixa com as páginas da web é um não-não. Tendo feito o trabalho de HA para uma grande empresa de telecomunicações, eu proponha inicialmente o seguinte:

• Cada um dos quatro servidores tem sua própria cópia dos dados.
• Em um horário tranquilo, traga dois servidores off-line (ou seja, modifique o balanceador de ha para removê-los).
• Atualize os dois servidores off-line.
• Modifique o Balancer HA para começar a usar os dois novos servidores e não os dois servidores antigos.
• Teste isso para garantir a correção.
• Atualize os outros dois servidores e trazem -os online.

É assim que você pode fazer isso sem hardware extra. No mundo anal-retentivo da empresa em que trabalhei, eis o que teríamos feito:

• Teríamos oito servidores (na época, tínhamos mais dinheiro do que você poderia cutucar um pau). Quando chegou a hora de transição, os quatro servidores offline seriam configurados com os novos dados.
• Em seguida, o HA Balancer seria modificado para usar os quatro novos servidores e parar de usar os servidores antigos. Isso fez com que a alternância (e, mais importante, se o switchback, se enchemos) um processo muito rápido e indolor.
• Somente quando os novos servidores estiverem em execução há um tempo, consideraríamos a próxima alternância. Até aquele momento, os quatro servidores antigos eram mantidos off-line, mas prontos, apenas por precaução.
• Para obter o mesmo efeito com menos gastos financeiros, você pode ter discos extras em vez de servidores extras inteiros. A recuperação não seria tão rápida, pois você teria que desligar um servidor para colocar o disco antigo de volta, mas ainda seria mais rápido que uma operação de restauração.

Answer 6

Eu estava encarregado do desenvolvimento de um site de jogo com 60 milhões de acertos por mês. A maneira como fizemos foi a opção nº 1. O usuário tinha a capacidade de fazer upload de imagens e essas foram colocadas em um NAS compartilhado entre os servidores. Funcionou muito bem. Suponho que você também esteja fazendo cache de páginas e assim por diante, no lado da aplicação da casa. Eu também implantaria sob demanda, as novas páginas para todos os servidores simultaneamente.

Answer 7

O que você ganha no NLB com o 4IIS, você o solta com o gargalo com o servidor de aplicativos.

Para escalabilidade, recomendarei os aplicativos nos servidores da Web frontal.

Aqui na minha empresa, estamos implementando essa solução. O aplicativo .NET nas extremidades frontais e um servidor de aplicativos para o cluster SharePoint + A SQL 2008.

Espero que ajude!

Saudações!

Answer 8

Temos uma situação semelhante a você e nossa solução é usar um modelo de editor/assinante. Nosso aplicativo CMS armazena os arquivos reais em um banco de dados e notifica um serviço de publicação quando um arquivo foi criado ou atualizado. Esta editora notifica todos os aplicativos da Web de assinatura e, em seguida, ele obtém o arquivo do banco de dados e o coloca em seus sistemas de arquivos.

Temos os assinantes definidos em um arquivo de configuração no editor, mas você pode ir para todo o porco e fazer com que o aplicativo da web faça a assinatura em si na inicialização do aplicativo para facilitar ainda mais o gerenciamento.

Você pode usar um UNC para o armazenamento, escolhemos um banco de dados para conveniência e portabilidade entre ou ambientes de produção e teste (simplesmente copiamos o banco de dados e temos todos os arquivos do site ao vivo e também os dados).

Answer 9

Um método muito simples de implantar para vários servidores (uma vez que os nós são configurados corretamente) é usar o robocopy.

De preferência, você teria um pequeno servidor de estadiamento para teste e, em seguida, 'Robocopy' para todos os servidores de implantação (em vez de usar um compartilhamento de rede).

Robocopy está incluído no MS ResourceKit - Use -o com o interruptor /miR.

Answer 10

Para lhe dar um pouco de comida para pensar que você poderia olhar para algo como Malha ao vivo da Microsoft. Não estou dizendo que é a resposta para você, mas o modelo de armazenamento que ele usa pode ser.

Com a malha, você baixará um pequeno serviço do Windows em cada máquina do Windows que deseja em sua malha e nomeia pastas no seu sistema que fazem parte da malha. Quando você copia um arquivo em uma pasta de malha ao vivo - que é exatamente a mesma operação que copiar para qualquer outro foler no seu sistema - o serviço cuida da sincronização desse arquivo com todos os seus outros dispositivos participantes.

Como exemplo, mantenho todos os meus arquivos de origem de código em uma pasta de malha e os sincronizem entre o trabalho e a casa. Não preciso fazer nada para mantê -los em sincronia a ação de salvar um arquivo no vs.net, no bloco de notas ou em qualquer outro aplicativo inicia a atualização.

Se você possui um site com arquivos com frequência que precisam ir para vários servidores e, presumivelmente, autores mutliple para essas alterações, você pode colocar o serviço de malha em cada servidor da web e, como autores adicionados, alterados ou removidos, as atualizações serão empurrado automaticamente. No que diz respeito aos autores, eles estariam salvando seus arquivos em uma pasta antiga normal no computador.

Answer 11

Use uma ferramenta de implantação, com um processo que implanta um de cada vez e o restante do sistema continua funcionando (como Mufaka disse). Este é um processo testado que funcionará com os arquivos de conteúdo e qualquer parte compilada do aplicativo (que a implantação causa uma reciclagem do processo ASP.NET).

Sobre a taxa de atualizações Isso é algo que você pode controlar. Peça às atualizações que passem por uma fila e tenha um único processo de implantação que controla quando implantar cada item. Observe que isso não significa que você processe cada atualização separadamente, pois pode pegar as atualizações atuais na fila e implantá -las juntas. Mais atualizações chegarão à fila e serão retiradas assim que o conjunto atual de atualizações terminar.

Atualizar: Sobre as perguntas no comentário. Esta é uma solução personalizada com base na minha experiência com processos pesados/longos que precisam de sua taxa de atualizações controladas. Não tive a necessidade de usar essa abordagem para cenários de implantação, pois para esse conteúdo dinâmico que costumo usar com uma combinação de banco de dados e cache em diferentes níveis.

A fila não precisa conter as informações completas, só precisa ter as informações apropriadas (IDs/Paths) que permitirão que seu processo passe as informações para iniciar o processo de publicação com uma ferramenta externa. Como é o código personalizado, você pode entrar nas informações a serem publicadas, para que você não precise lidar com isso no processo/ferramenta de publicação.

As alterações do banco de dados seriam feitas durante o processo de publicação; novamente, você só precisa saber onde é as informações para as alterações necessárias e permitir que o processo de publicação/ferramenta lida com isso. Em relação ao que usar para a fila, os principais que usei é o MSMQ e uma implementação personalizada com informações no SQL Server. A fila está lá apenas para controlar a taxa das atualizações, para que você não precise de nada direcionado para implantações.

Atualização 2: Verifique se as alterações do seu banco de dados são compatíveis com versões anteriores. Isso é realmente importante, quando você está pressionando as alterações ao vivo para diferentes servidores.

Answer 12

Supondo Replicação do DFS. Cada servidor tem sua própria cópia dos arquivos que elimina um gargalo de rede compartilhado, como muitos outros alertaram. A implantação é tão simples quanto copiar suas alterações em qualquer um dos servidores no grupo de replicação (assumindo uma topologia completa de malha). A replicação cuida do resto, incluindo o uso automaticamente do uso da compactação diferencial remota, para enviar apenas os deltas dos arquivos que foram alterados.

Answer 13

Estamos muito felizes usando 4 servidores da Web, cada um com uma cópia local das páginas e um servidor SQL com um cluster de falhas sobre.