Por que sites grandes usam vários servidores em vez de um servidor com melhores especificações?

Li que o Stack Overflow usa 10 ou mais servidores para servir o site Stack Overflow. Servidores diferentes têm funções diferentes, como proxy reverso, servidor de banco de dados ou servidor HTTP.

Eu vi um servidor único e poderoso autônomo com estas especificações:

• 2 x Xeon E5-2630v2 a 2,60 GHz, total de 12 núcleos, 24 threads; 30 MB
• Registo ECC de 64 GB até 768 GB DDR3 a 1600 MHz
• 4 x 120 GB Intel 520/530 Series (IOPS aleatório de 80k, ~ 550 MB / s)
• HP iLo4 Advanced com porta de gerenciamento Ethernet dedicada.

Por que não usar um único servidor com especificações mais altas, como 768 GB de RAM, 20 TB + HDD, 4 ou mais x Xeon? Quais são os benefícios do uso de muitos servidores ou as desvantagens do uso de um único servidor de alta especificação?

Um único servidor poderoso só pode ser atualizado até o momento. Depois de ter o servidor mais poderoso disponível, seu site não poderá crescer mais sem dividi-lo entre servidores ou torná-lo mais eficiente.

Há também o fator de custo. Um único servidor super poderoso pode custar dez vezes mais do que dois servidores com a metade do poder. Você deseja comprar seu hardware pelo preço mais barato e não ficar preso a um preço mais alto, porque é a única coisa que funcionará.

Tempo de atividade e confiabilidade também entram em jogo. Com dois ou mais servidores, um pode falhar ou ser desconectado para manutenção e o site pode permanecer ativo. Você não pode fazer isso com um único servidor.

A maioria dos sites grandes usa balanceadores de carga e vários servidores. Eu trabalhava no TripAdvisor. Eles publicaram um ótimo artigo sobre a arquitetura do TripAdvisor e como eles a tornam altamente escalável com vários servidores.

É possível executar um serviço avançado em um único servidor. Um exemplo que eu conheço é o Mailinator. O autor publicou um artigo sobre a arquitetura do Mailinator . Ele se concentra em tornar seu código mais eficiente, em vez de comprar novos servidores. Isso acaba sendo uma limitação que determina como seu serviço funciona. Ele mantém o correio apenas algumas horas antes que a única máquina o exclua para abrir espaço para mais.

A atualização de um único servidor é conhecida como dimensionamento vertical . A adição de mais servidores é conhecida como dimensionamento horizontal . Para mais informações sobre este tópico, aqui estão alguns artigos que comparam os dois:

• Wikipedia: Dimensionamento horizontal e vertical
• Pensamentos da IBM sobre nuvem: como explicar o dimensionamento vertical e horizontal na nuvem
• Internap video: escala vertical versus horizontal

Do contra-almirante Grace Hopper:

Na construção de computadores maiores: "Nos dias de pioneiro, eles usavam bois para puxar pesado, e quando um boi não conseguia mexer em um tronco, eles não tentavam cultivar um boi maior. Não deveríamos tentar computadores maiores, mas para mais sistemas de computadores ".

fonte

Stephen explica a principal consideração a ser tomada ao decidir sobre uma arquitetura de sistemas: a troca no dimensionamento vertical e horizontal. Vou adicionar algumas outras considerações:

• Separação de preocupações: você menciona vários sistemas radicalmente diferentes: proxies reversos, banco de dados, servidores de conteúdo etc. Do ponto de vista de manutenção e segurança, é claramente vantajoso manter essas responsabilidades espalhadas por diferentes sistemas para que eles possam executar um sistema operacional diferente (versão) se necessário, pode ser atualizado separadamente e não afeta outros serviços quando comprometido.
• Entrega de conteúdo: esse é o objetivo final de um servidor da Web e se presta bem a um modelo de distribuição. Os sistemas podem ser duplicados e espalhados geograficamente, de modo a minimizar a latência das conexões de longa distância. Também permite redundância . Sites grandes usam balanceadores de carga (mais um conjunto de servidores!) Para permitir o failover automático para manter o serviço sempre ativo.

Na verdade, existe uma classe de servidor inteira que leva a escala vertical para outro nível: mainframes. Eles têm uma variedade de vantagens (velocidade, confiabilidade) e desvantagens (custo), mas geralmente são usados ​​quando enormes volumes de dados precisam ser tratados por meio do processamento de entrada e saída no que chamamos de processamento de transações (pense em compras com cartão de crédito, serviços bancários). , eleição e dados do censo). Os bancos, por exemplo, atendem sites de servidores da Web em escala vertical, enquanto o back-end acabaria processando transações por meio do mainframe.

Curiosamente, empresas como Paypal e Visa estão se afastando do mainframe para sistemas agrupados de milhares de sistemas em escala horizontal. No mundo digital em rápida evolução, mesmo os mainframes estão atingindo o teto de escala horizontal:

“Com todos os requisitos de disponibilidade e desempenho, não podíamos continuar processando pagamentos em mainframes,

Fonte: Adam Banks, no ComputerWorldUK

• Limite de tamanho. Gostamos de fingir que uma única caixa com vários processadores, chips de memória e discos é uniforme. Isso não é inteiramente verdade, mas é verdade o suficiente se seus números não forem muito grandes. Existem limites técnicos de calor, energia, proximidade etc., o que significa que sempre haverá um limite prático para o tamanho de um único servidor.

• Escalabilidade - há uma grande diferença entre um sistema de servidor único, usando memória compartilhada para IPC e um sistema de vários servidores que usa rede ou cluster. No entanto, a diferença entre dois servidores e 200 é consideravelmente menor - se você construiu um sistema escalável, pode escalá-lo MUITO maior antes que haja um problema ... e se você tiver, não há realmente a necessidade de um servidor único enorme em primeiro lugar.

• Resiliência - Um servidor é um local que um administrador pode "opar". Ou há um problema físico que significa que o serviço para todo esse pedaço de lata é interrompido. (Vazamento de água no datacenter, alguém colidindo com um rack e derrubando-o, esse tipo de coisa). Vários servidores podem ser distribuídos em um datacenter ou, melhor ainda, distribuídos geograficamente. E se você já está distribuindo seu aplicativo, o dimensionamento em máquinas de 'tamanho médio' é quase sempre mais barato que a mesma quantidade de CPU / memória / IO em um número menor de máquinas maiores.

• Atualizações - Se eu corrigir um servidor, isso pode tornar um serviço instável, exigir uma reinicialização ou exigir algum tempo de inatividade. Se eu tiver 4 servidores executando a mesma coisa, posso ficar fora de serviço por um tempo para fazer isso. E deixe de fora de serviço se o ciclo de correção / atualização der errado.

Vamos pegar o problema em pequena escala. Um pequeno escritório com um servidor executando correio, ActiveDirectory, compartilhamento de arquivos e o site da empresa.

Os hackers acertam e você precisa reiniciar porque o IIS está bagunçado. Ou o Exchange precisa de uma atualização e uma reinicialização. Ou o Active Directory foi corrompido.

Qualquer um desses problemas isolados de "um serviço está inativo" afeta o servidor inteiro; portanto, qualquer compartilhamento nesse servidor os afetará em virtude de ter que reiniciar ou qualquer outra coisa.

Depois que um verdadeiro cara de TI aparecer e ver esse servidor, ele recomendará dividi-los em servidores separados (e ter um servidor de controlador de domínio de backup).

É o velho ditado de "não coloque todos os seus ovos em uma cesta"

Agora que a filosofia é aplicada aos servidores web. Se eu tiver apenas um servidor Web e publicar meu aplicativo Web (o novo MyFaceLink.com) e ele se tornar realmente popular, tenho novos problemas. Não posso desativar o site para fazer manutenção enquanto os usuários estiverem nele. E se ele travar ou eu tiver muitos usuários, eu vou de mangueira. Até o maior servidor único do mundo ficará sobrecarregado com 1 bilhão de conversões de FB chegando.

Portanto, o balanceamento de carga entra em ação, pelo mesmo motivo "ovos na cesta". Espalhe o site por três servidores e, se um deles cair, os 2 restantes lidam com a capacidade. Se eu precisar fazer patches, eu apenas faço um de cada vez, e ninguém percebe.

No mais simples, não se trata do preço do mega-servidor ou se ele pode realmente lidar com a carga (embora possa ser). É sobre um único ponto de falha. Quando os negócios estão ocupados o suficiente e acontecem 24 horas por dia, 7 dias por semana, em vez de para 5 usuários trabalhando de 8 a 5, o tempo de inatividade não é aceitável. Interrupções programadas são mais difíceis de agendar. Então, você espalha a carga.

Se alguém tentar fazer com que uma máquina faça o trabalho de duas, algumas partes da máquina precisarão ser maiores, mas rodarão na mesma velocidade, outras poderão permanecer do mesmo tamanho, mas precisarão ser executadas mais rapidamente e outras precisarão ser maiores e mais rápido. A extensão em que faz sentido combinar as funções de máquinas menores em uma maior ou dividir as funções de máquinas maiores em máquinas menores depende em grande parte de que tipo de escala se aplicaria às partes mais caras das máquinas. Se as cargas de trabalho de muitas máquinas forem combinadas em um enorme colosso, os custos serão dominados por coisas que precisariam ser maiores emais rápido para lidar com maiores cargas de trabalho. Mesmo se os custos de tais coisas fossem lineares em relação à velocidade e tamanho, dobrar a carga de trabalho mais que dobraria o custo de uma máquina para processá-la. O fato de a velocidade aumentar além de um certo ponto resulta em um aumento de custo (muito) maior que o linear, ampliando o efeito.

Não existe realmente um ponto fixo em que a praticidade obriga à subdivisão do trabalho; dependendo do tipo de trabalho a ser realizado, uma máquina que combina as cargas de trabalho de duas pessoas pode se dar bem com menos do dobro da memória ou com menos do dobro da velocidade. Por outro lado, quanto mais tarefas uma máquina receber, maior será a extensão em que os requisitos de memória e velocidade começam a ser dimensionados linearmente com a carga de trabalho. Quanto mais além disso, maior o aumento no custo relativo para cada duplicação de carga de trabalho.