Eu desenvolvi uma WebAPI REST usando o módulo Serviços. Funciona bem. Eu tenho um cliente dessa API com uso projetado, exigindo que eu dimensione horizontalmente minha instância do Drupal. Observe que, devido à natureza da minha API, exigindo recursos significativos de CPU e GPU, não posso usar servidores em nuvem. Além disso, devido à natureza da minha API, as instâncias do Drupal precisam ser executadas no sistema operacional Windows. (Meu aplicativo requer software disponível apenas no Win64.) Agora, tenho um servidor bastante robusto em uma co-localização e, para esse cliente ambicioso, planejo dimensionar horizontalmente meu hardware da seguinte maneira:
- Um servidor CentOS executando o HaProxy como balanceador de carga de front-end,
- Dois para iniciar, com mais adicionados, conforme necessário, servidores Windows Server 2008 R2 que hospedam o Drupal,
- Um servidor de banco de dados do CentOS que fornece um único banco de dados para as várias instâncias do Drupal,
- Um servidor de banco de dados do CentOS em execução no modo de replicação, caso o servidor de banco de dados 1 morra.
Minhas perguntas têm a ver com o funcionamento do balanceador de carga HaProxy. Estou assumindo que os sessionIds criados pelas instâncias do Drupal serão únicos um do outro. O balanceador de carga examina o sessionId e roteia todas as solicitações para o mesmo servidor que produziu esse sessionId? Como uma comunicação RAP WebAPI funcionaria se o balanceamento de carga fizesse com que cada solicitação de API fosse para um servidor diferente? Todos e quaisquer dados referenciados pela WebAPI precisam ser armazenados no banco de dados porque não posso garantir que várias solicitações de API para o mesmo recurso sejam roteadas para a mesma instância do Drupal?
fonte
Respostas:
Ter vários servidores web atrás de um balanceador de carga / proxy reverso é bastante comum para o Drupal e é bem suportado. O verniz é normalmente usado no mundo Linux, porque essa coisa é incrivelmente rápida quando é possível usá-la, o que significa visitantes anônimos. O que obviamente não é o caso do seu site.
As sessões são armazenadas no banco de dados por padrão, portanto não há problema. A única outra coisa que precisa ser compartilhada em todos os servidores é o diretório de arquivos públicos e qualquer outro como os arquivos privados, se você estiver usando algo assim). Na maioria dos casos, um sistema de arquivos compartilhado / distribuído como o NFS é usado para isso, embora existam abordagens mais avançadas. Em um site em que estou envolvido, o sistema de arquivos fornecido por outro servidor que é montado em NFS nos servidores Drupal (para que o acesso seja lento) e esteja sendo distribuído em um domínio diferente pelo Lighthttpd. Mas, novamente, isso provavelmente não é tão relevante para você, pois você não vai servidor de muitas imagens e arquivos css, eu acho.
Como mencionado por rocketeerbkw, existem back-ends de cache para Memcache, Redis e outros. Até agora, usei apenas o Memcache, mas recentemente comecei a pesquisar no Redis e parece muito promissor, mas não tenho certeza se ele está disponível para Windows. No entanto, seria possível configurar um servidor Linux separado para ser usado no cache. O Drupal 7 depende muito de caches, poder tirá-los do banco de dados é muito importante por dois motivos:
Ferramentas como Redis e Memcache são projetadas para pesquisas rápidas baseadas em chaves e mantêm seus dados sempre na memória para fazer a pesquisa o mais rápido possível. Eles também criaram suporte para limpar automaticamente os dados antigos do cache se o limite configurado se aproximar.
Talvez ainda mais importante, isso ajuda a diminuir o carregamento do banco de dados. Depois de instalar a configuração básica, é fácil adicionar servidores da web adicionais. Quando você começa a atingir os limites de um único servidor de banco de dados, as coisas ficam muito mais complicadas e você precisa analisar coisas como replicação mestre / mestre (o Drupal 7 não ganha muito com os ambientes mestre / escravo).
Portanto, é basicamente apenas a sua própria API que você precisa cuidar. Se possível, você precisa garantir que tudo esteja sempre disponível em todos os servidores. Você pode usar o banco de dados, o sistema de arquivos ou outra coisa (o Drupal também pode usar o MongoDB para armazenar determinados dados, por exemplo, campos). Se isso não for uma opção, você precisará usar sessões persistentes para que os usuários sempre acabem na mesma instância. No entanto, você deve realmente tentar evitar isso, porque se um dos servidores falhar, todos os usuários que estavam nesse servidor precisarão se reconectar a outro servidor, possivelmente perdendo dados.
fonte
Por padrão, o PHP armazena sessões no disco. Se um usuário efetuar logon no servidor 1, em seguida, clicar no servidor 2, ele será desconectado. Existem algumas opções para corrigir isso:
Para implementar # 2 e responder às suas perguntas sobre HAProxy; Na configuração mais básica, você pode executá-lo no modo TCP e usar o algoritmo de balanceamento "origem" ( http://cbonte.github.com/haproxy-dconv/configuration-1.4.html#4-balance ) para garantir que os usuários acessem o mesmo servidor. Você deve ler os documentos para determinar se há alguma desvantagem para você usar essa abordagem.
Para o número 1, você pode usar um armazenamento de chave / valor como Redis ou Memecached ao qual todos os seus servidores se conectariam e recuperariam sessões. Isso faz com que as sessões sejam carregadas / salvas muito rapidamente e você também pode usar como um cache Drupal compartilhado.
fonte