web farm do IIS7 - conteúdo local ou compartilhado?

5

Estamos configurando um farm da web do IIS7 com dois servidores. Cada servidor deve ter sua própria cópia local do conteúdo ou deve extrair conteúdo diretamente de um compartilhamento UNC? Quais são os prós e contras de cada abordagem?


Atualmente, temos um único servidor WEB1, com conteúdo armazenado localmente em uma partição separada. Um job sincroniza periodicamente o WEB1 com um servidor em espera WEB2, usando robocopy para conteúdo e msdeploy para config. Se o WEB1 ficar inoperante, o Nagios nos notifica e nós manualmente executamos um script para mover os endereços IP para a interface de rede do WEB2. Ambos os servidores são na verdade VMs em execução em hosts separados do VMWare ESX 4. Os servidores são associados ao domínio.

Temos cerca de 50 a 60 sites ao vivo no WEB1 - principalmente ASP.NET, com alguns que são apenas HTML estático. A maioria são microsites de baixo tráfego. Alguns têm tráfego moderado, mas nenhum é enorme.


Gostaríamos de alterar isso para que o WEB1 e o WEB2 estejam atendendo ativamente o conteúdo. Isto é principalmente para confiabilidade - se WEB1 cair, não queremos ter que intervir manualmente para falhar. Espalhar a carga também é bom, mas a carga não é alta o suficiente agora para nós precisarmos disso.

Estamos planejando configurar nosso firewall para equilibrar o tráfego entre os dois servidores. Ele detectará quando um servidor cair e enviará todo o tráfego para o servidor ativo restante. Estamos planejando usar sessões fixas por enquanto ... eventualmente, podemos passar para o estado de sessão do SQL Server e balanceamento de carga sem estado.

Mas precisamos de uma maneira para os servidores compartilharem conteúdo. Estávamos originalmente planejando mover todo o conteúdo para um compartilhamento UNC. Nosso provedor de armazenamento diz que eles podem configurar um compartilhamento SMB altamente disponível para nós. Então, se formos a rota UNC, o armazenamento não deve ser um ponto único de falha. Mas estamos nos perguntando sobre as desvantagens dessa abordagem:

  • Precisamos alterar os caminhos físicos de cada site e diretório virtual. Existem também alguns projetos que possuem caminhos absolutos em seus arquivos web.config - também teremos que atualizá-los.

  • Precisamos criar um usuário de domínio para os servidores da Web acessarem o compartilhamento e conceder a ele as permissões apropriadas. Ainda não analisei isso - não tenho certeza se a identidade do pool de aplicativos precisa ser alterada para esse usuário ou se há outra maneira de informar ao IIS para usar essa conta ao se conectar ao compartilhamento.

  • Os sites não poderão mais acessar seu conteúdo se houver algum problema no Active Directory.

  • Em geral, parece muito mais complicado, com mais partes móveis que podem quebrar. Nosso provedor de armazenamento criaria um volume para nós em sua SAN redundante. Se bem entendi, esse volume de SAN seria montado em uma VM em execução no ambiente VMWare redundante; essa VM, então, expõe o compartilhamento SMB aos nossos servidores da Web.


Por outro lado, um benefício da abordagem de conteúdo compartilhado é que só precisamos implantar código em um lugar e nunca haveria uma inconsistência temporária entre várias cópias do conteúdo.

Este tópico é muito interessante, embora algumas dessas pessoas trabalhem em uma escala muito maior.

Acabei de discutir conteúdo até agora, mas também precisamos pensar em configuração. Eu não sei se podemos usar apenas a replicação DFS para o applicationHost.config e outros arquivos, ou se é melhor usar o configuração compartilhada com a configuração em um compartilhamento UNC.

O que você acha?

    
por Richard Beier 24.03.2010 / 00:24

4 respostas

4

Suas preocupações são válidas e, ao final do dia, você terá que avaliar cada prêmio com seus riscos herdados.

O conteúdo compartilhado é ótimo; mas como você apontou, você tem uma dependência em um host remoto e as tecnologias de armazenamento em cluster não são baratas ou simples. Esse tipo de configuração tem seu lugar e, considerando sua solução atual, presumo que você não esteja procurando uma solução de tempo de atividade de 99,999%.

Você pensou em estender seu script para desabilitar os nós com balanceamento de carga (no firewall) durante os períodos em que você sincroniza o conteúdo da Web1 > Web2?

O

Shared Config é ótimo, e usa uma cópia de cache local se o seu compartilhamento UNC não estiver disponível, e é uma ótima maneira de garantir que os aplicativos da web tenham a configuração correta.

Meus 2c's

    
por 24.03.2010 / 05:51
1

O disco compartilhado em uma SAN é a melhor solução - mas apenas um pouco mais realista do que voar em uma vassoura. Alguns fornecedores como o Melio oferecem isso - mas algumas desvantagens (caro, precisa de um SAN, se o VMware perde a capacidade de snapshot com o controlador compartilhado)

    
por 22.06.2011 / 23:51
1

Temos usado compartilhamentos UNC para servir webheads em cluster (NLB) por algum tempo e recentemente mudamos para o sistema operacional de 64 bits Win 2008R2, a diferença é enorme, não há mais preocupações sobre a exaustão de conexões SMB. Existem limites, mas eles são altos. Acabei de adicionar o DFS à mistura com outro servidor de arquivos, mas ainda não consigo falar em confiabilidade.

    
por 07.07.2011 / 16:29
0

Use o iSCSI em um sistema de arquivos de disco compartilhado ... Os compartilhamentos UNC são muito lentos

    
por 19.05.2010 / 23:46