desenv-web-rp.com

Quais problemas potenciais eu preciso conhecer em um ambiente com vários servidores / cluster?

Estou trabalhando em um site com um cliente há algum tempo e o site em si cresceu enormemente em popularidade. Agora estamos no estágio em que a única máquina que hospedamos o site está lutando para manter as solicitações e otimizamos o próprio site o máximo possível (cache, etc.).

Agora, estamos no estágio em que precisamos adicionar outro servidor para lidar com a tensão extra que leva à minha pergunta - quais possíveis armadilhas e advertências eu preciso estar ciente ou testar o site ao migrar para um web farm ou hospedagem em cluster meio Ambiente?

3
Wolfwyrd

Existem várias advertências possíveis:

Sessões

Se as sessões estiverem armazenadas no lado do servidor (ou seja, PHP), , os dois servidores precisarão acessar um caminho de armazenamento de sessão compartilhada. Caso contrário, você perderá sessões à medida que o balanceador de carga envia uma solicitação de um servidor para outro ou, possivelmente (gasp), tem um usuário com duas sessões únicas. Isso pode ser particularmente frustrante com o AJAX. Sessões 'aderentes' também podem ser possíveis, dependendo do seu balanceador de carga.

arquivos temporários

Ambos os servidores devem compartilhar o mesmo diretório/tmp, se você realmente usar qualquer tipo de arquivo temporário enquanto trabalha para atender solicitações. Pode ser um arquivo temporário compactado para download, um banco de dados de arquivo simples que rastreia alguma coisa, qualquer que seja.

Bloqueio de SQLite

Se você usa o SQLite3, poderá observar algumas peculiaridades que nunca apareceram antes, especialmente se estiver usando algo como o NFS para compartilhar os arquivos de banco de dados entre os servidores. NFS é lento com isso, então eu recomendo usar outra coisa. Sistemas de arquivos distribuídos como o Luster são fáceis de configurar ou você pode usar o GFS/OCFS2.

SSL

Você provavelmente deseja que o balanceador de carga seja o que manipula o handshake SSL, que faz a solicitação aos servidores de back-end usando qualquer certificado autoassinado antigo.

Algumas notas gerais:

  • Como observado, use um sistema de arquivos de alto desempenho para compartilhar diretórios. Todos os arquivos compartilhados devem residir no armazenamento em rede, não em um dos servidores da web. Caso contrário, se alguém cair, ambos serão inúteis, meio que derrotam o objetivo.

  • Se o site usa um RDBMS, você tem duas opções. Execute-o nos dois nós e use uma sincronização master-master ou coloque o servidor DB em sua própria casa. Eu recomendo o segundo porque isso dá aos servidores da Web muito mais espaço para operar.

  • Os balanceadores de carga também precisam de redundância.

Na maioria dos casos, você pode ir de um único servidor para um farm com balanceamento de carga, com poucas ou nenhuma alteração no site/aplicativo real, mas precisará garantir que todos os nós possam ler e gravar nos mesmos arquivos. Isso pode exigir que você adicione alguma lógica para bloquear o próprio aplicativo.

1
Tim Post

O estado da sessão (se for um problema) é um problema em potencial. A maioria dos dispositivos de balanceamento de carga pode usar sessões persistentes, o que significa que um usuário que terminar no SERVER1 para iniciar permanecerá no SERVER1, geralmente através do uso de um cookie armazenado na memória do navegador. A única ressalva disso é que, quando o SERVER1 ficar offline, por qualquer motivo, esse usuário precisará fazer login novamente em outro servidor.

Comecei a ignorar isso nos meus aplicativos (eles são aplicativos de CF) compartilhando sessões no farm de servidores. Portanto, uma máquina desligada não afetará a experiência do usuário.

O único outro desafio que enfrentei ao replicar o conteúdo corretamente para todos os servidores do farm. Existem softwares disponíveis para fazer isso (robocopy, Fling do NCH são dois que eu usei), mas ainda tive casos em que a sincronização não funcionava 100% do tempo.

0
Milner

Seu aplicativo se preocupa com o estado? Se um usuário tem uma solicitação atendida por uma máquina e outra atendida por outra, isso importa? Se você precisar persistir em alguma forma de estado entre solicitações, tudo ficará mais complicado e haverá várias maneiras de lidar com o problema.

Se você não precisa se preocupar com o estado, é um bom trabalho criar seu site, e você deve estar relativamente bem com um proxy e alguns servidores back-end.

Se você precisar persistir, existem várias maneiras de criar uma sessão persistente por meio do proxy, para que o mesmo servidor back-end lide com todas as solicitações de um único usuário, mas também existem muitas coisas que dificultam a manutenção dessas sessões. .

Você também pode persistir o estado em uma mídia comum no back-end, para que cada servidor carregue o mesmo estado para o mesmo usuário. Você pode fazer isso com um banco de dados (talvez muito lento) ou algo como memcached .

Você está aumentando o número de servidores de banco de dados também? Isso trará outro monte de problemas para se preocupar.

Alguns dos problemas da sessão são discutidos no Podcast Stack Overflow número 6

Para o teste, certifique-se de atingir um cluster de teste semelhante com força, para poder ver como suas solicitações são direcionadas em vários servidores, porque muitas solicitações do mesmo cliente para back-end diferente é onde você provavelmente terá problemas, portanto, verifique se algo em seu plano de teste faz com que isso ocorra.

Você também pode ler sobre o Stack Overflow configuração da rede

0
danivovich