Que considerações sobre hardware e software um grande site requer para gerenciar adequadamente mais de 1000 servidores? [fechadas]

Question

Desculpe por essa pergunta de alto nível. Eu entendo as noções básicas de balanceamento de carga do servidor, mas o conceito de gerenciar 30.000 servidores é um pouco estranho para mim. É realmente apenas o mesmo conceito de balanceamento de 2 ou 3 servidores ampliado 10.000 vezes?

Como isso se relaciona com coisas como memcached, sql / mysql, mecanismos de busca, etc?

É um sistema de heirarquia de ter servidores 'controladores' e servidores escravos que fornecem os dados com base nisso? Como a redundância é tratada?

Obrigado por qualquer informação ou direção para um artigo sobre o assunto.

EDIT Obrigado pelas respostas. Meu post foi encerrado, mas eu renovei o título, espero que seja reaberto, pois acho que o processo de solução de problemas envolvido com essas soluções de dados de alto nível é fascinante, e atualmente estou construindo uma API que vai exigir alguma carga básica balanceamento, daí a questão.

    

Answer 1

A maior parte da pilha de software que o Google usa em seus servidores foi desenvolvida internamente. Para diminuir os efeitos de uma falha de hardware inevitável, o software foi projetado para ser tolerante a falhas.

Fonte: Google Platform

Depois de ler o artigo, acredito que seja o mesmo conceito de equilibrar a carga entre alguns servidores dimensionados para mais de 1.000 servidores, usando a pilha interna de software desenvolvida internamente no Linux. Por exemplo, GFS (sistema de arquivos do Google), BigTable - Sistema de armazenamento estruturado com base no GFS

Este link descreve como eles equilibram a carga de rede.

Eles usam Interruptores de balanceamento de carga para distribuir a carga. Todas as solicitações para o site chegam a uma máquina que passa a solicitação para um dos servidores disponíveis. O switch pode descobrir a partir dos servidores qual deles é o menos carregado, portanto, todos eles estão fazendo uma quantidade igual de trabalho.

A topologia de rede do Google é a 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, isso funciona como o primeiro nível de balanceamento de carga e direciona o cliente para diferentes clusters do Google. Um cluster do Google tem milhares de servidores e, depois que o cliente se conecta ao servidor, é feito um balanceamento de carga adicional para enviar as consultas ao servidor da Web menos carregado.

    

Answer 2

A grande parte aqui é, se o software não é projetado para escalar, como pode? Por exemplo, uma das maiores restrições do Facebook agora é a confiança no MySQL - eles conseguiram contornar o problema jogando mais e mais máquinas nele, mas

Normalmente, você precisa conseguir fazer o balanceamento de carga de solicitações - e muitos projetos, de código aberto ou não, são criados. Mas isso vem com sobrecarga, incluindo registros de gravação, gravações atrasadas e arquiteturas "eventualmente consistentes". Em outras palavras, o dimensionamento não é barato.

Assim, coisas como servidores da Web, que estão servindo conteúdo estático, podem ser facilmente paralelizados. Memcached e outros sistemas de cache são facilmente balanceados por carga. Mas como você muda pontos únicos de falhas? Como sua única escala de banco de dados relacional grande? E quanto às lojas de arquivos? Em essência, este é um ramo inteiro de pesquisa ... não é algo que possa ser respondido por uma única pergunta.

    

Answer 3

Acho que os mesmos conceitos devem 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 procurar os dados solicitados.

Pense na implementação do serviço DNS. Ele possui um banco de dados distribuído muito grande. Os nós raiz direcionam os usuários para outros nós de nível inferior, e assim por diante, até que você atinja o nó responsável, que pode responder à sua consulta.