Как справиться с отказом сервера в многоуровневой архитектуре?

Представьте, что у меня есть n-уровневая архитектура в автоматически масштабируемой облачной среде, скажем:

балансировщик нагрузки в паре аварийного переключения
уровень обратного прокси
уровень веб-приложения
уровень БД

Каждый уровень должен подключаться к экземплярам на уровне ниже.

Каковы стандартные способы соединения уровней, чтобы сделать их устойчивыми к сбоям узлов на каждом уровне? то есть как каждый уровень получает IP-адреса каждого узла на уровне ниже?

Например, если все обратные прокси-серверы должны направлять трафик на все узлы веб-приложения, как их можно настроить так, чтобы они не отправляли трафик на мертвые узлы веб-приложения, и чтобы при подключении новых узлов веб-приложений они могли отправлять трафик к нему?

Я мог бы запустить агент, который обновлял бы все конфигурации всех узлов, но это кажется неэффективным.
Я мог бы поместить пару LB между каждым уровнем, так что уровень выше должен только подключаться к балансировщикам нагрузки, но как мне решить проблему смерти LB? Похоже, это просто смещает проблему уровня A, которому необходимо знать IP-адреса всех узлов на уровне B, на все узлы на уровне A, которым необходимо знать IP-адреса всех LB между уровнями A и B.

Для некоторых приложений они могут реализовать логику повторных попыток, если они связываются с узлом на уровне ниже, который не отвечает, но есть ли способ, которым некоторое промежуточное ПО могло направить трафик только на активные узлы на следующем уровне?

Если бы я размещал на AWS, я мог бы использовать ELB между уровнями, но я хочу знать, как я мог бы достичь той же функциональности сам.

Я прочитал (вкратце) о сердцебиении и keepalived - актуальны ли они здесь? О каких виртуальных IP-адресах они говорят и как ими управлять? Есть ли еще единичные точки отказа при их использовании?

high-availability infrastructure

Ваш вопрос How do I deal with failures?
Ответ Redundancy, или более конкретно

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

Вы можете сделать это с помощью Amazon ELB (если вы используете EC2), pf брандмауэр (или pfsense) с циклическим виртуальным IP-адресом или различными программными инструментами балансировки нагрузки, такими как haproxy (что, вероятно, является лучшим выбором, поскольку они обладают некоторыми приличными возможностями обнаружения сбоев, хотя для них требуется дополнительное оборудование).
Существуют также специализированные коммерческие решения для балансировки нагрузки, такие как Коммутаторы контента или модули переключения контента Cisco если у вас есть деньги.

Не забудьте смоделировать сбои в своей тестовой среде, чтобы убедиться, что все идет так, как вы ожидаете.

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

используя keepalived и heartbeat, вы можете иметь пару серверов haproxy. если один терпит неудачу, другой берет верх.

В качестве примера я использую haproxy, но почти все балансировщики нагрузки приложений (также известные как балансировщики нагрузки уровней 4/7) имеют эти характеристики.

LB должен отслеживать прокси-уровень и автоматически удалять пропавшие хосты (т. Е. Перенаправлять трафик на оставшиеся узлы).

Обратный прокси-сервер должен снова использовать LB, который отслеживает веб-приложения. Веб-приложения должны иметь возможность принимать сеансы от других узлов.

Веб-приложения должны подключаться через LB к db-серверам.