Назад | Перейти на главную страницу

Высокая доступность балансировки нагрузки для холодного резервирования с автоматическим запуском службы

Я пытаюсь настроить кластер высокой доступности в AWS для приложения, которое я запускаю. Приложение находится в экземпляре EC2, который находится перед Oracle RDS. Если я использую традиционную балансировку нагрузки и два экземпляра работают одновременно, база данных становится поврежденной, потому что два экземпляра будут вносить изменения в базу данных, но не будут знать друг о друге, поэтому мне нужно выполнить активную / пассивную балансировку нагрузки. .

Проблема, с которой я столкнулся, заключается в том, что если пассивный экземпляр запускает приложение, даже если в него не поступает трафик, он, тем не менее, вносит изменения в базу данных примерно в 0,1% случаев. Это означает, что мне нужно убедиться, что служба приложения не работает на резервном узле, когда основной узел исправен.

Мой идеальный сценарий - иметь что-то, что запускает активное / пассивное аварийное переключение, которое может делать следующее:

  1. Проверьте работоспособность основного узла
  2. Если основной узел исправен, перенаправить трафик на основной узел.
  3. Если основной узел неисправен, запустите сценарий, который запускает службу, а затем перенаправляет трафик на дополнительный.

Я изучал HAProxy, но не видел способа заставить HAProxy запускать произвольный сценарий на резервном сервере в случае сбоя на основном узле.

Я видел некоторое обсуждение использования keepalived. Возможно ли то, что я предлагаю, в Keepalived? Есть еще что-нибудь, что может это сделать?

Вы можете запустить Active-Passive аварийное переключение с помощью Route53 (в отличие от балансировки нагрузки с ALB, которая будет распределять трафик равномерно, что вам не нужно).

С активным пассивным переключением при отказе у вас может быть основная активная служба с одной (или несколькими) вторичными службами в холодном резерве. Если проверка работоспособности на первичном сервере не удалась, он будет перенаправлен на вторичный, используя DNS. Это НЕ ОБЯЗАТЕЛЬНО даст вам надежность HAProxy, но он по существу достигнет того, что вам нужно (в зависимости от критичности и плавности задержки переключения при отказе), хотя у вас может быть более быстрый интервал проверки, который может снизить задержку переключения до, возможно, 60 секунд).

В этом руководстве AWS рассматривается аварийное переключение DNS Route53:

Активно-активный и активно-пассивный отказоустойчивый режим