Php + Apache + Mysql + [qualquer coisa] Cluster de servidores - armadilhas, dicas e roteiros para eficiência

Question

Surgiu a necessidade de uma configuração de servidor em cluster (é como isso é chamado?) na minha empresa. Temos nossa hospedagem alugada no exterior e, como tal, temos acesso limitado ao hardware real, mas temos liberdade total e não somos restringidos por recursos financeiros (desde que evitemos exageros, é claro - não há necessidade de 300 servidores se 3 puderem lidar com as coisas) .

Somos uma editora on-line internacional que oferece gratuitamente livros legíveis on-line. Isso significa que temos uma tonelada de conteúdo estático - basicamente muitos gigabytes de documentos em flash. Recentemente, atualizamos o sistema operacional do servidor para o CentOS x64 e alteramos o software do servidor do Apache para o Nginx (para conteúdo estático) + Apache. Houve alguns problemas, no entanto, e enfrentamos um tempo de inatividade inesperado, que nos prejudicou bastante, mesmo que tenha sido por apenas algumas horas.

Meus pensamentos sobre uma configuração de cluster foram os seguintes: - servidor 1: nosso banco de dados MySQL atual.
- servidor 2, servidor 3, servidor 4: nossa aplicação, ou seja, nosso código PHP no Apache Review - servidor 4: somente conteúdo estático (imagens de 5kb a 3mb, PDFs de 5mb a 100MB, arquivos flash de 200kb a 20MB, etc.) com tecnologia Cherokee

Acredito que essa configuração nos ajudaria a evitar o tempo de indisponibilidade caso um dos três servidores de aplicativos falhasse, além de compartilhar a carga entre três servidores, diferente de agora, quando tudo (estático + DB + aplicativo) estava em uma máquina.

O que eu gostaria de você veteranos é alguns links úteis sobre compartilhamento de carga do servidor, dicas e sugestões sobre este problema e minha proposta de configuração acima .. Eu tenho experiência limitada com Apache como desenvolvedor PHP, e não muito mais, então se qualquer um pode oferecer informações valiosas sobre suas configurações ou experiências com hardware / software diferentes, eu ficaria muito grato.

Além disso, qual é a terminologia correta? Nuvem? Grupo? Quaisquer outros termos que eu deveria estar ciente. Por favor, seja gentil, estou apenas começando a entrar no mundo dos servidores.

Obrigado

Editar: o novo plano é o seguinte, por favor, deixe-me saber o que você pensa:

Cluster de aplicativos :

• 3 servidores executando Nginx (ou Cherokee) e Apache com PHP. O Nginx lidaria com solicitações de conteúdo estático no mesmo servidor (CSS, JS, miniaturas, sprites, imagens)
• Como atualmente temos dois sites com um tráfego bastante grande (um alto nas atualizações de banco de dados, o outro com alta disponibilidade de conteúdo estático), estávamos pensando em colocar ambos neste servidor de aplicativos.
• Os dois aplicativos teriam dois balanceadores de carga para distribuir o tráfego entre os três servidores. Os servidores seriam clones idênticos e facilmente escaláveis posteriormente.

Cluster de banco de dados

• Dois servidores executando o MySQL, clones. Balanceador de carga. Os backups seriam feitos em si mesmos, pois é altamente improvável que ambos morressem ao mesmo tempo. Os dois aplicativos no cluster de aplicativos usarão esse cluster - um executará uma carga média de leitura, o outro um alto carregamento de leitura e gravação.

Cluster estático

• Dois servidores com conteúdo estático exclusivo, basicamente apenas armazenamento para milhares de PDFs, Zips e arquivos Flash. Sem backup, impossível de executar de forma eficiente. Servidores são backups uns dos outros. Esse cluster estático servirá um conteúdo estático maior para os dois aplicativos no cluster de aplicativos.

Isso é realista? O que você aconselharia contra, se alguma coisa? O que você adicionaria?

    

Answer 1

Algumas coisas gerais que aprendi ao longo dos anos:

• Consulte esta pergunta para saber lista de bons livros sobre o assunto de sites de desempenho, dimensionamento e alta disponibilidade.
• "Cluster" é o termo correto. Você está usando várias máquinas para veicular um site na tentativa de aumentar a disponibilidade. Você também pode usar o cluster para fazer referência a partes específicas da sua configuração: por exemplo, os servidores 2 + 3 + 4 seriam o seu cluster de aplicativos.
• Existe alguma razão pela qual você só tem redundância no nível do aplicativo? E quanto ao MySQL e conteúdo estático? Especialmente desde que o seu conteúdo estático é relativamente grande, veja quanta largura de banda você pode servir para N usuários simultâneos, se necessário. O que acontece se o servidor MySQL falhar ou se o servidor nº 4 tiver um disco danificado?
• Se você está mudando tudo de uma máquina, comece pequeno, a menos que não se importe de gastar mais do que o necessário. Por exemplo, descobri um ganho de desempenho maior que o esperado em uma situação semelhante, passando de 1 para 3 servidores. Depois de dividir em vários servidores, você pode descobrir que o novo afunilamento está em uma área diferente.
• Ao planejar o dimensionamento agora, não esqueça completamente de possível dimensionamento futuro. Um pouco de pensamento e design avançado agora pode economizar seu tempo no futuro. Por exemplo, você tem um servidor estático agora, mas o que você quer múltiplos em um ano, ou vários servidores espalhados geograficamente.
• Considere a possibilidade de criar scripts para ajudar a configurar tipos específicos de servidores ... fazendo isso manualmente, cada um fica velho e você sempre esquece um passo. Eu fiz isso recentemente e gostaria de tê-lo feito desde o início. A execução de um script que executa 50 etapas de instalação automaticamente em poucos minutos economiza muito tempo a longo prazo.
• À medida que você obtém mais servidores, a probabilidade de experimentar algum tipo de falha de hardware torna-se maior. Planeje isso e jogue o jogo what-if: E se o disco rígido falhou no servidor X? O que nós perderíamos? Por quanto tempo o site estaria fora? Quanto tempo levaria para consertá-lo? etc ...

Answer 2

Eu acho que a uesp cobriu muito bem o material geral. Para decidir o que você vai fazer pelo seu caso, há algumas coisas que você precisa sentar e pensar:

1. Qual é a carga atual em cada um desses componentes? Qual é a carga futura projetada?
2. Quais são os cenários de falha com os quais você deseja lidar? O que causou seu último fracasso?

As primeiras perguntas informam o número mínimo de servidores que você precisará em cada nível para ter um site em execução.

A segunda pergunta mostra quanto hardware você realmente deseja ter para garantir que seu site continue funcionando. Conforme você expõe os modos de falha, descobrirá que precisará considerar mais do que apenas servidores: firewalls, conexões de Internet de fluxo ascendente, geradores, locais físicos e muito mais. Você também precisará abordar coisas como ter administradores em chamada para lidar com servidores que falham às 3h e o monitoramento necessário para ativar o administrador e informá-los que algo falhou. Se sua falha antes foi devido a um erro de configuração ou programação, considere um ambiente de preparação entre desenvolvimento e produção para que o teste ocorra depois que os programadores terminarem com suas mudanças e antes que as mudanças sejam ativadas.