Configuração do cluster de servidor de dimensionamento

Question

Estou no meio da reconstrução de um site que atualmente recebe cerca de 4 milhões de visitantes por mês (e está indo bem ultimamente). No momento, ele está sendo executado e hospedado por uma empresa externa, mas estamos despejando-os, portanto, preciso projetar hospedagem.

Estou pensando em criar um pequeno cluster (provavelmente no Linode):

• Um Linode NodeBalancer para equilibrar a carga entre os servidores de aplicativos. Ele pode manter todo o tráfego de um cliente específico para um servidor de aplicativos, mas o WP lida com sessões por meio de cookies, o que não é tão importante.

• Dois (ou mais) servidores de aplicativos - Os VPS Linode (512?) estão executando o Debian6 / Apache2 / PHP5 / Wordpress, mas nginx para armazenamento em cache .

• Um MySQL (ou MariaDB?) servidor de banco de dados (novamente, um VPS) e talvez um escravo com HyperDB .

• O desenvolvimento é feito internamente em um antigo FBSD / Apache2 / MySQL / PHP5, a implementação apenas envia um novo código para todos os servidores de aplicativos, um de cada vez, e qualquer DB muda para os servidores de banco de dados.

• Os backups serão armazenados localmente. Poderíamos fazer backup de um servidor de aplicativos (eles devem ser idênticos?) Em um tempo de tráfego baixo para manter a carga baixa.

• O e-mail é tratado via MailChimp. Fácil.

O próprio WP está executando o W3 Total Cache com o Xcache, estou considerando um CDN para imagens e outros arquivos estáticos, os cabeçalhos de cache já estão sendo usados para esses arquivos estáticos ...

O plano é que à medida que expandimos, posso adicionar mais servidores de aplicativos e / ou de banco de dados, conforme necessário.

Resumindo: essa configuração funcionaria? Seria eficiente? Eu nunca construí algo assim antes, então eu gostaria de ter certeza de que não estou perdendo algo.

Apenas para referência: é um site de notícias. Nós publicamos artigos em várias seções, algumas mídias, e os visitantes podem comentar artigos, inscrever-se em nossa lista de e-mail, etc.

    

Answer 1

Estou no processo de criar algo semelhante ao seu com uma empresa diferente. Eu não posso necessariamente comentar como o Linode funciona, mas quero destacar algumas coisas que eu encontrei ao procurar no VPS:

• Eu não sei os custos dos balanceadores de carga do linode, mas descobri que gosto do controle sobre a configuração de um VPS geral executando HAProxy ou NGINX para balanceamento de carga (eu escolhi o HAproxy).

• Verifique se você tem RAM suficiente. Infelizmente as ofertas públicas que encontrei até agora não permitem que você ajuste a quantidade de RAM e HDD (eu preciso de mais memória RAM, mas não tanto HDD. Oh bem).

• Verifique se o seu VPS é persistente. Você não quer perder dados (especialmente para o MySQL) em execução em um VPS se houver um desligamento ou falha de hardware. Esta é a documentação do MySQL para o EC2 , mas algumas das mesmas conceitos se aplicam).

• Definitivamente, certifique-se de estar replicando o MySQl para um servidor diferente, ou mesmo para vários escravos. Não quer perder dados.

• Definitivamente, certifique-se de recuperar os backups para um servidor externo.

• Se você estiver implantando em vários servidores com balanceamento de carga (2 ou mais servidores de aplicativos), tenha um servidor 'mestre' do qual os backups façam rsync para atualizar o código. Isso simplifica seu processo de empurrar devagar (tire o mestre do esquema de balanceamento de carga, certifique-se de que os escravos não rsync do antigo mestre, empurre o código para o mestre, assegure-se de que tudo está funcionando como esperado, ligue novamente do mestre para os escravos, adicione master de volta ao esquema de loadbalance).

Tenho certeza de que há mais, mas a configuração descrita na pergunta parece boa.

    

Answer 2

Esta configuração é muito semelhante aos nossos clusters de servidores web que usamos. Usamos upgreams Nginx em nosso servidor "balance" para passar solicitações para nossos servidores web. Não vejo por que sua configuração acima não funcionaria e ela permitirá que você expanda horizontalmente conforme necessário.

• Eu também recomendaria o uso do Heartbeat for HA nos loadbalancers. aqui é uma boa referência

Você tem algum backup / armazenamento no momento ou está usando RAID para redundância? Você pode considerar um NAS para instantâneos / backups. Apenas um pensamento.

    

Answer 3

Certifique-se de que a criação do seu próprio haproxy em 2 clusters de linode falhará quando você decidir usar a rota keepalived. Multicasts não são suportados, tenho certeza. Há uma correção haproxy para usar unicasts, que dizem que funcionam nessas redes.

Mas perceba que provedores como rackspace / linode sabem que isso meio que atrapalha seus produtos de balanceamento de carga.

Dito isto, você PODE obter multicasts para funcionar através de um link openvpn (sugestão)

O

suporte a unicast para o haproxy limita-se a 2 nós, controlando 1 endereço VIP.

    

Answer 4

Eu tenho recomendações de Tow acima de tudo o que foi dito.

• Certifique-se de usar pelo menos dois LoadBalancers, usando um LoadBalancer é um ponto único de falha
• Use um sistema de arquivos em cluster (gfs / OCFS2) para ter certeza de que você tem uma única cópia / versão do código em execução no cluster, caso contrário, você precisará colocar seu site no modo de manutenção sempre que for necessário algum novo código ou fazer algumas atualizações até que as alterações sejam aplicadas a todos os nós do cluster (e ainda assim você pode esquecer de atualizar um deles)

Answer 5

Você está me fazendo pensar mais a fundo sobre isso, eu tenho várias máquinas Linode (e a Rackspace também) sob meu controle.

Meu site pessoal é executado como seu plano:

• W3TC plugin (com uma boa integração CDN, vejo de onde vem essa ideia)
• PHP / fpm
• NGINX (1.2)
• MariaDB 5.2

Eu tenho mais serviços nele não relacionados, tracd (edgewall) por trás do nginx como upstream e também uma instância dev do couchdb.

Tudo isso em um linode de 768Mb (o segundo mais baixo). Ele manipula até 50 conexões por segundo com memcached e cache de disco ativado (portanto, não há APC ou CDN). O plugin de cache faz com que ele passe de 5 / s para 50 / s (o maior pedaço sendo o MariaDB).

Tanto quanto HAPROXY eu tenho um daqueles rodando em um Linode também. BTW, Em encontrar rackspace para ser inferior ao Linode desde que você não pode escolher sua localização geográfica de dentro da mesma conta (você pode ter duas contas em nós en fora). Além disso, a interface deles não é tão simples quanto o Linode.

No que diz respeito ao escalonamento do MariaDB, não acho fácil rodar dois mestres como uma grande dor de cabeça, mantendo-os em sincronia. A rota clássica que eu tomaria é configurar um servidor mestre e vários escravos (por nó, talvez). Então, em haproxy, você os agrupa no modo TCP, mas entre o seu BD e o HAPROXY eu colocaria o mysql-proxy entre para garantir que as gravações estão sendo enviadas para o nó mestre correto, você pode programar isso no LUA. O benefício adicional é que a criação de conexões para o mysql é bastante reduzida. Um grande desempenho acabou, cada conexão mysql ocupa pelo menos 5Mb do que eu experimentei aqui.

Isso ainda lhe dá um único ponto de falha, sendo o servidor mestre mysql.

Para isso você pode fazer a abordagem mestre-mestre com o segundo mestre não usado em qualquer lugar diretamente, a menos que o primeiro desça. Eu acho que o Mysql DB é o maior fator limitante na configuração de grandes clusters redundantes. O couchDB é muito mais fácil nesse aspecto, mas é uma solução NOSQL ...

O maior ponto que gostaria de fazer é diferente: eu descartaria o Apache, você realmente não precisa dele, já que o PHP / fpm + nginx está lá. Então eu não usaria o nginx como cache, mas como o servidor frontend. O Apache vai comer o seu Linode no café da manhã, comparado ao que o nginx pode oferecer no Linode ...

Espero que isso tenha contribuído para o seu plano na marca. Como sempre, faça sua própria opinião e teste essas coisas primeiro. Seja dinâmico em suas soluções, elimine algo que não funciona antes de começar a usá-lo na produção, é muito mais trabalhoso definir as coisas mais tarde.