Допустим, у нас есть десять серверов, на каждом из которых есть копия приложения без сохранения состояния.
как это решено? виртуальный ip? какие-то другие механизмы? пожалуйста, дайте мне несколько ссылок или хотя бы несколько модных словечек, чтобы я мог узнать об этом больше
РЕДАКТИРОВАТЬ: хорошо, я знаю, что у нас должен быть какой-то балансировщик нагрузки перед кластером, но тогда проблема перемещается на один уровень дальше: как обеспечить высокую доступность этого балансировщика нагрузки? в конце концов, это может упасть
Вы путаете DNS и высокую доступность. Повторяйте за мной: DNS не является отказоустойчивым. DNS не является отказоустойчивым. DNS не является отказоустойчивым.
Если вы хотите обеспечить высокую доступность и балансировку нагрузки, вам понадобится обратный прокси-сервер, который специализируется на этом. Самый известный из них - haproxy..
Для меня одним из наиболее очевидных решений обеспечения высокой доступности для более чем двух хостов является балансировка нагрузки, хотя название не предполагает высокой доступности.
Какой тип LB больше всего подходит для вашего варианта использования, действительно зависит от типа клиента и приложения, но от трех наиболее распространенных вариантов.
Балансировка нагрузки L7. У вас есть прокси, который понимает используемый протокол. Таких прокси для HTTP много. Он знает, как проверить, живы ли серверные серверы. А с некоторыми даже легко справиться с неверным ответом (500). Прокси-сервер хранит список всех серверов и список работающих и исправных серверов. Как только запрос поступает, он пересылает его на один из этих бэкэнд-серверов OK. (Это может работать с HTTPS, если также есть разгрузка SSL.)
Балансировка нагрузки L4 работает примерно так же, но вместо того, чтобы смотреть на каждый запрос, она смотрит на каждое соединение. Он не понимает протокол. Так что обычно это работает, даже если вы используете что-то эфемерное или зашифрованное, например HTTPS.
Балансировка нагрузки L3 принимает хэш исходного IP-адреса (и, возможно, порта) и на основе этого хэша перенаправляет соединение на один из серверов. Будет работать даже для протоколов UDP с отслеживанием состояния.
Есть и другие способы добиться этого. Но я бы сказал, что это самые простые.
Конечно, теперь у вас есть еще один SPOF - балансировщик нагрузки. Но поскольку все три этих метода (без SSL) не очень ресурсоемки, целесообразно иметь конфигурацию Acitve / Passive с использованием чего-то вроде VRRP для переключения при отказе в случае проблем.
L7 для HTTP может быть реализован с помощью программного обеспечения, такого как Varnish (отличное решение для кеширования и LB, насколько я знаю), HAProxy, nginx, Apache httpd и т. Д., Большинство веб-серверов / прокси могут это сделать. Для других протоколов вы должны использовать прокси, специфичный для протокола.
L4 может выполняться с помощью HAProxy и подобного программного обеспечения или через брандмауэр (хотя вам необходимо реализовать проверку статуса).
L3 выполняется на маршрутизаторе и / или в брандмауэре. Вероятно, вы могли бы сделать это с помощью Linux и iptables (IPVS) или какого-либо коммерческого программного обеспечения.
HA - довольно широкая тема с точки зрения конкретных объектов, для которых вы хотите включить HA. Например, веб-сервер, сетевые устройства, базы данных и т. Д. Общая идея состоит в том, чтобы избежать единой точки отказа.
В вашем случае вы хотите включить HA на веб-сервере, и на данный момент я могу придумать два подхода: активный / активный и активный / пассивный (эти две концепции можно обобщить
Активный / Активный: в этом сценарии у вас есть обратный прокси (haproxy или Nginx), расположенный перед вашими фактическими веб-серверами. По сути, он пересылает запросы и ответы. Он знает список доступных веб-серверов и обычно распределяет входящие запросы между ними. Пользователь всегда будет получать доступ к одному и тому же IP-адресу, предоставленному этим прокси, и решать, на какой веб-сервер перенаправлять запросы, решать прокси. В этом случае, если один из веб-серверов выйдет из строя, прокси просто перестанет над ним работать.
Активный / Пассивный Более интересная настройка - Активный / Пассивный, при которой один сервер выполняет фактическую работу, а все остальные находятся в режиме ожидания. Например, у вас есть два веб-сервера, A и B. Оба имеют IP-адрес 1.1.1.1, хотя только A отвечает на запрос ARP. Следовательно, ваш кластер будет наблюдать только за сервером A, который выполняет фактическую работу. На данный момент B - это просто сервер-призрак, готовый взять на себя управление в случае сбоя. Между А и Б будет какой-то протокол сердцебиения для проверки работоспособности. Когда A выходит из строя, B узнает об этом с определенной задержкой и вступает во владение.
В облаке практически все элементы готовы к HA, включая сеть, вычислительные ресурсы и контроллер. Так должны быть ваши услуги. И есть другие инструменты, такие как Pacemaker и Corosync, поддерживающие активность для достижения этой цели.
Я не мог дать никаких хороших ссылок прямо сейчас, поскольку тема, которую вы рассматриваете, очень обширна, но я рекомендую вам использовать Google для определенных случаев использования, чтобы понять более глубокое понимание.
Ура, J