Почему большие сайты используют несколько серверов вместо одного сервера с лучшими характеристиками?

Я читал, что Stack Overflow использует 10 или более серверов для обслуживания сайта Stack Overflow. Разные серверы имеют разные функции, такие как обратный прокси-сервер, сервер базы данных или HTTP-сервер.

Я видел мощный отдельный сервер с такими характеристиками:

• 2 x Xeon E5-2630v2 при 2,60 ГГц, всего 12 ядер, 24 потока; 30 МБ
• 64 GB ECC Reg. до 768 ГБ DDR3 на частоте 1600 МГц
• Серия Intel 520/530 4 x 120 ГБ (80 тыс. Случайных операций ввода-вывода в секунду, ~ 550 МБ / с)
• HP iLo4 Advanced с выделенным портом управления Ethernet.

Почему бы не использовать один сервер с более высокими характеристиками, такими как 768 ГБ ОЗУ, 20 ТБ + жесткий диск, 4+ Xeon? Каковы преимущества использования многих серверов или недостатки использования одного сервера высокой спецификации?

Один мощный сервер может быть обновлен только до сих пор. Если у вас есть самый мощный из доступных серверов, ваш сайт не сможет расти больше, не разделив его между серверами или не сделав его более эффективным.

Существует также фактор стоимости. Один сверхмощный сервер может стоить в десять раз дороже двух серверов, которые вдвое мощнее. Вы хотите иметь возможность покупать свое оборудование по самой низкой цене и не привязываться к более высокой цене, потому что это единственное, что будет работать.

Время работы и надежность также входят в игру. С двумя или более серверами один может выйти из строя или быть отключен для обслуживания, и сайт может оставаться в рабочем состоянии. Вы не можете сделать это с одним сервером.

Большинство крупных сайтов используют балансировщики нагрузки и несколько серверов. Раньше я работал на TripAdvisor. Они опубликовали отличную статью об архитектуре TripAdvisor и о том, как они делают ее легко масштабируемой на нескольких серверах.

Это можно запустить продвинутую службу на одном сервере. Один из известных мне примеров - Mailinator. Автор опубликовал статью об архитектуре Mailinator . Он стремится сделать свой код более эффективным, чем покупать новые серверы. Это в конечном итоге является ограничением, которое диктует, как работает его служба. Он сохраняет почту всего за несколько часов до того, как отдельный компьютер удалит ее, чтобы освободить место для большего количества.

Обновление одного сервера называется масштабированием по вертикали . Добавление большего количества серверов называется горизонтальным масштабированием . Для получения дополнительной информации по этой теме, вот несколько статей, которые сравнивают два:

• Википедия: горизонтальное и вертикальное масштабирование
• IBM мысли о облаке: как объяснить вертикальное и горизонтальное масштабирование в облаке
• Internap видео: вертикальное и горизонтальное масштабирование

От контр-адмирала Грейс Хоппер:

О создании больших компьютеров: «В первые дни они использовали волов для тяжелой тяги, а когда один бык не мог сдвинуть с места бревно, они не пытались вырастить более крупного быка. Мы не должны пытаться делать большие компьютеры, но для большего количества систем компьютеров. "

источник

Стивен объясняет главное соображение при выборе архитектуры системы: компромисс в вертикальном и горизонтальном масштабировании. Я добавлю несколько других соображений:

• Разделение проблем: вы упомянули несколько радикально разных систем: обратные прокси-серверы, БД, контент-серверы и т. Д. С точки зрения обслуживания и безопасности явно выгодно распределить эти обязанности по разным системам, чтобы они могли работать с другой ОС (версия). при необходимости может обновляться отдельно и не затрагивать другие службы при взломе.
• Доставка контента: это конечная цель веб-сервера, и она хорошо поддается модели распространения. Системы могут быть продублированы и распределены географически, так что задержка междугородных соединений сведена к минимуму. Это также учитывает избыточность . Большие веб-сайты используют балансировщики нагрузки (еще один набор серверов!), Чтобы обеспечить автоматическое переключение при сбое, чтобы постоянно поддерживать службу.

На самом деле существует целый класс серверов, который переводит вертикальное масштабирование на другой уровень: мэйнфреймы. У них есть ряд преимуществ (скорость, надежность) и недостатки (стоимость), но в целом они обычно используются, когда огромные объемы данных должны обрабатываться посредством обработки ввода-вывода в том, что мы называем обработкой транзакций (например, покупки с помощью кредитных карт, банковские операции). , данные о выборах и переписи). Например, банки обслуживают сайты с вертикально масштабированных веб-серверов, в то время как серверная часть будет обрабатывать транзакции через мэйнфрейм.

Интересно, что такие компании, как Paypal и Visa, переходят от мэйнфреймов к кластерным системам тысяч горизонтально масштабируемых систем. В быстро развивающемся цифровом мире даже мэйнфреймы достигают потолка горизонтального масштабирования:

«Учитывая все требования к доступности и производительности, мы не могли продолжать обработку платежей на мэйнфреймах,

Источник: Адам Бэнкс, в ComputerWorldUK

• Ограничение по размеру. Нам нравится делать вид, что одна коробка с несколькими процессорами, чипами памяти и дисками одинакова. Это не совсем верно, но это достаточно верно, если ваши цифры не становятся слишком большими. Существуют технические ограничения для тепла, энергии, близости и т. Д., Что означает, что всегда будет практический предел того, насколько большим может быть один сервер.

• Масштабируемость - существует огромная разница между системой с одним сервером, использующей общую память для IPC, и системой с несколькими серверами, которая использует сеть или кластеризацию. Однако разница между двумя серверами и 200 значительно меньше - если вы построили систему, которая масштабируется, вы можете масштабировать ее НАМНОГО больше, прежде чем возникнет проблема ... и если у вас есть, то на самом деле нет необходимости в огромном отдельном сервере в первую очередь.

• Устойчивость - один сервер - это место, которое один администратор может «упс». Или есть физическая проблема, которая означает, что обслуживание всего этого кусочка олова прерывается. (Утечка воды из центра обработки данных, кто-то врезается в стойку и опрокидывает ее, такого рода вещи). Несколько серверов могут быть распределены в центре обработки данных или, что еще лучше, распределены географически. И если вы уже распространяете свое приложение, масштабирование на компьютерах «среднего» размера почти всегда дешевле, чем тот же объем ЦП / памяти / ввода-вывода на меньшем количестве больших машин.

• Обновления - если я исправлю сервер, это может сделать службу нестабильной, потребовать перезагрузки или иным образом потребовать некоторого простоя. Если у меня 4 сервера, на которых запущено одно и то же, я могу на время отключить один из них. И оставьте его в нерабочем состоянии, если цикл исправления / обновления пойдет не так.

Давайте рассмотрим проблему в небольших масштабах. Крошечный офис с одним сервером, на котором работает почта, ActiveDirectory, общий файловый ресурс и веб-сайт компании.

Хакеры бьют по нему, и вам приходится перезагружаться, потому что IIS не работает. Или Exchange нуждается в обновлении и перезагрузке. Или Active Directory поврежден.

Любая из этих изолированных проблем "одна служба не работает" затрагивает весь сервер, поэтому все, что происходит на этом сервере, повлияет на них в силу необходимости перезагрузки или чего-либо еще.

Как только настоящий ИТ-специалист обнаружит и увидит этот сервер, он порекомендует разделить их на отдельные серверы (и иметь резервный сервер контроллера домена).

Это старая поговорка «не кладите все яйца в одну корзину»

Теперь эта философия применяется к веб-серверам. Если у меня есть только один веб-сервер, и я публикую свое веб-приложение (новое MyFaceLink.com), и оно становится действительно популярным, у меня возникают новые проблемы. Я не могу отключить сайт для обслуживания, пока на нем есть пользователи. И если он выходит из строя или я получаю слишком много пользователей, мне не хватает. Даже самый большой в мире сервер будет перегружен 1 миллиардом конвертируемых FB.

Итак, балансировка нагрузки вступает в игру по той же причине «яйца в корзине». Распределите сайт по 3 серверам, и если один из них выйдет из строя, оставшиеся 2 будут управлять емкостью. Если мне нужно сделать патчи, я просто делаю по одному, и никто не замечает.

Проще говоря, речь идет не о цене мегасервера или о том, действительно ли он может справиться с нагрузкой (хотя это может быть). Это о единой точке отказа. Когда бизнес достаточно занят и происходит круглосуточно, а не для 5 пользователей, работающих 8-5, простои не допускаются. Запланированные отключения сложнее планировать. Итак, вы распределяете нагрузку.

Если кто-то пытается заставить одну машину выполнять работу двух, некоторые части машины должны быть больше, но работать с одинаковой скоростью, некоторые могут оставаться того же размера, но должны работать быстрее, а некоторые должны быть больше. и быстрее. Степень, в которой имеет смысл объединить роли небольших машин в более крупные или разделить роли более крупных машин на более мелкие, во многом зависит от того, какой тип масштабирования будет применяться к наиболее дорогим частям машин. Если рабочие нагрузки слишком большого количества машин будут объединены в один огромный колосс, тогда в затратах будут доминировать вещи, которые должны были бы увеличиться ибыстрее справляться с повышенными нагрузками. Даже если бы стоимость таких вещей была линейной по скорости и размеру, удвоение рабочей нагрузки более чем удвоило бы стоимость машины для ее обработки. Тот факт, что скорость превышает определенную точку, приводит к (значительно) увеличению стоимости, превышающему линейное, усиливает эффект.

На самом деле не существует фиксированной точки, где практичность побуждает подразделение труда; в зависимости от типа выполняемой работы машина, сочетающая в себе две рабочие нагрузки, может обойтись менее чем вдвое большим объемом памяти или работать с удвоенной скоростью. С другой стороны, чем больше задач выполняет машина, тем больше степень линейного масштабирования требований к памяти и скорости в зависимости от рабочей нагрузки. Чем дальше от этого, тем больше увеличение относительных затрат на каждое удвоение рабочей нагрузки.