Desculpe por uma pergunta de tão alto nível. Entendo os fundamentos do balanceamento de carga de servidores, mas o conceito de gerenciamento de 30.000 servidores é um pouco estranho para mim. É realmente o mesmo conceito de equilibrar 2 ou 3 servidores ampliados 10.000 vezes?
Como isso se relaciona com coisas como memcached, sql/mysql, mecanismos de pesquisa, etc?
É um sistema de hierarquia com servidores 'controladores' e servidores escravos que entregam os dados com base nisso? Como a redundância é tratada?
Obrigado por qualquer informação ou orientação para um artigo sobre o assunto.
EDITARObrigado pelas respostas pessoal. Minha postagem foi encerrada, mas renovei o título, espero que seja reaberto, pois considero fascinante o processo de resolução de problemas envolvido com essas soluções de dados de alto nível, e atualmente estou construindo uma API que exigirá alguma carga básica equilíbrio, daí a questão.
Responder1
A maior parte da pilha de software que o Google usa em seus servidores foi desenvolvida internamente. Para diminuir os efeitos de falhas inevitáveis de hardware, o software é projetado para ser tolerante a falhas.
Fonte:Plataforma Google
Depois de ler o artigo, suponho que seja o mesmo conceito de equilibrar a carga entre poucos servidores dimensionados para mais de 1.000 servidores usando uma pilha de software interna desenvolvida internamente no Linux. por exemploGFS(Sistema de arquivos do Google),Mesa grande- Sistema de armazenamento estruturado baseado em GFS
Esselink descreve como eles equilibram a carga da rede.
Eles usamSwitches de balanceamento de cargapara distribuir a carga. Todas as solicitações do site chegam a uma máquina que então passa a solicitação para um dos servidores disponíveis. O switch pode descobrir nos servidores qual deles está menos carregado, de modo que todos eles façam a mesma quantidade de trabalho.
Topologia de rede do Googleé o seguinte:
Quando um computador cliente tenta se conectar ao Google, vários servidores DNS resolvem www.google.com em vários endereços IP por meio da política Round Robin. Além disso, atua como o primeiro nível de balanceamento de carga e direciona o cliente para diferentes clusters do Google. Um cluster do Google possui milhares de servidores e, uma vez que o cliente se conecta ao servidor, é feito um balanceamento de carga adicional para enviar as consultas ao servidor web menos carregado.
Responder2
A grande parte aqui é: se o software não foi projetado para ser dimensionado, como poderá? Por exemplo, uma das maiores restrições do Facebook no momento é a dependência do MySQL - eles conseguiram contornar o problema lançando mais e mais máquinas nele, masseu próprio engenheiro chama isso de "um destino pior que a morte".
Normalmente, você precisará ser capaz de balancear a carga de solicitações - e muitos projetos, de código aberto ou não, são projetados. Mas isso acarreta sobrecarga, incluindo gravação de logs, gravações atrasadas e arquiteturas "eventualmente consistentes". Em outras palavras, o dimensionamento não sai barato.
Portanto, coisas como servidores web, que servem conteúdo estático, podem ser facilmente paralelizadas. Memcached e outros sistemas de cache são facilmente balanceados em carga. Mas como você altera pontos únicos de falhas? Como seu banco de dados relacional único e grande é dimensionado? E quanto aos armazenamentos de arquivos? Em essência, este é todo um ramo de pesquisa... não algo que possa ser respondido por uma única pergunta.
Responder3
Acho que os mesmos conceitos deveriam ser os mesmos e o ponto crítico é como você distribui a carga e os dados entre os recursos disponíveis e como você localiza seus dados.
Uma maneira é a distribuição geográfica dos servidores. Cada usuário será direcionado para o servidor mais próximo.
Um serviço semelhante a um registro pode ser usado para pesquisar os dados solicitados.
Pense na implementação do serviço DNS. Ele contém um enorme banco de dados distribuído. Os nós raiz direcionam os usuários para outros nós de nível inferior e assim por diante até chegar ao nó responsável que pode responder à sua consulta.