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

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

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

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

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

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

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

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

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

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

Источник

3 ответа

Решение

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

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

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

Источник

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

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

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

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

Источник

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

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

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

Источник
Другие вопросы по тегам