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