Извините за столь высокий вопрос. Я понимаю основы балансировки нагрузки на серверы, но концепция управления 30 000 серверов мне немного чужда. Неужели это та же самая концепция балансировки 2 или 3 серверов, увеличенная в 10 000 раз?
Как это относится к таким вещам, как memcached, sql / mysql, поисковые системы и т. Д.?
Является ли это иерархической системой с «контроллерами» и подчиненными серверами, которые доставляют данные на основе этого? Как обрабатывается избыточность?
Спасибо за любую информацию или направление к статье по этому вопросу.
РЕДАКТИРОВАТЬ Спасибо за ответы, ребята. Мой пост был закрыт, но я изменил заголовок, надеюсь, он будет открыт снова, поскольку я нахожу процесс решения проблем, связанный с этими решениями для обработки данных сверхвысокого уровня, увлекательным, и в настоящее время я создаю api, который потребует некоторой базовой загрузки балансировка, отсюда и вопрос.
Важная часть здесь в том, что если программное обеспечение не предназначено для масштабирования, как это возможно? Например, одно из самых больших ограничений Facebook прямо сейчас - это их зависимость от MySQL - они смогли обойти проблему, добавляя к ней все больше и больше машин, но их собственный инженер называет это «судьбой хуже смерти».
Как правило, вам необходимо иметь возможность выполнять запросы балансировки нагрузки - и многие проекты, как с открытым исходным кодом, так и другие, разработаны. Но это связано с накладными расходами, включая запись журналов, отложенную запись и «в конечном итоге согласованные» архитектуры. Другими словами, масштабирование обходится недешево.
Таким образом, такие вещи, как веб-серверы, обслуживающие статический контент, можно легко распараллелить. Memcached и другие системы кэширования легко балансируются по нагрузке. Но как изменить единые точки отказа? Как масштабируется ваша единая большая реляционная база данных? А как насчет файловых хранилищ? По сути, это целая ветвь исследований ... не то, на что можно ответить одним вопросом.
Большая часть программного стека, который Google использует на своих серверах, была разработана собственными силами. Чтобы уменьшить последствия неизбежного отказа оборудования, программное обеспечение разработано отказоустойчивым.
Источник: Платформа Google
После прочтения статьи я предполагаю, что это та же концепция, что и балансировка нагрузки между несколькими серверами, масштабируемыми до 1000+ серверов, с использованием собственного программного стека, разработанного собственными силами на базе Linux. например GFS(Файловая система Google), Большой стол - Структурированная система хранения на основе GFS
это ссылка описывает, как они балансируют сетевую нагрузку.
Они используют Переключатели балансировки нагрузки распределить нагрузку. Все запросы к веб-сайту поступают на машину, которая затем передает запрос на один из доступных серверов. Коммутатор может узнать по серверам, какой из них загружен меньше всего, поэтому все они выполняют равный объем работы.
Топология сети Google выглядит следующим образом:
Когда клиентский компьютер пытается подключиться к Google, несколько DNS-серверов преобразовывают www.google.com в несколько IP-адресов с помощью политики циклического перебора. Кроме того, это действует как первый уровень балансировки нагрузки и направляет клиента в разные кластеры Google. Кластер Google имеет тысячи серверов, и после подключения клиента к серверу выполняется дополнительная балансировка нагрузки для отправки запросов на наименее загруженный веб-сервер.
Я думаю, что одни и те же концепции должны быть одинаковыми, и критическим моментом является то, как вы распределяете нагрузку и данные между доступными ресурсами и как вы размещаете свои данные.
Один из способов - это географическое распределение серверов. Каждый пользователь будет перенаправлен на ближайший сервер.
Для поиска запрошенных данных можно использовать службу, подобную реестру.
Подумайте о реализации службы DNS. Он содержит очень большую распределенную базу данных. Корневые узлы направляют пользователей на другие узлы более низкого уровня и так далее, пока вы не достигнете ответственного узла, который сможет ответить на ваш запрос.