Как добиться высокой доступности активно-активного сервера приложений?
Мне нужно настроить мое приложение таким образом, чтобы время простоя было почти нулевым. Один из моих центров обработки данных находится в Техасе, а другой - в Вегасе. Теперь, если мой сервер в TX, который считается PR, выйдет из строя, весь трафик будет перенаправлен на сервер Vegas, который в моем случае является DR (аварийное восстановление).
Если мы будем использовать программный балансировщик нагрузки, такой как HAProxy или NginX, используя Keepalived (для проверки пульса между балансировщиком нагрузки сайта DR и балансировщиком нагрузки сайта PR), мы получим настройку балансировки нагрузки Active-Passive для преодоления аварийного переключения. Здесь наше приложение будет в режиме Active-Active.
На приведенной выше диаграмме показано, что весь входящий трафик будет достигать виртуального IP-адреса балансировщиков нагрузки (активный балансировщик нагрузки PR и пассивный балансировщик нагрузки DR, между ними включен тактовый сигнал). Если балансировщик нагрузки сайта PR активен, он направит нагрузку на экземпляры приложения портала сайта PR, а также экземпляры портала сайта аварийного восстановления (поскольку оба сайта активны), в это время балансировщик нагрузки сайта аварийного восстановления будет бездействовать и будет постоянно контролировать производительность Активный балансировщик нагрузки. Если сайт PR выходит из строя, то сайт аварийного восстановления становится активным и автоматически указывает на экземпляры приложения портала сайта аварийного восстановления.
Но я слышал, что проблема с настройкой балансировщика нагрузки Active-Passive с Keepalived заключается в том, что он работает в локальной сети, но не работает в настройке WAN. Как и в нашем случае, балансировщик нагрузки Active PR будет в TX, а балансировщик нагрузки Passive DR будет в Вегасе.
Итак, чтобы достичь высокой доступности с настройкой аварийного переключения, как я могу использовать программный балансировщик нагрузки?
Вы не сможете этого сделать. Причина, по которой он работает в одной локальной сети, - это общий IP-адрес, который передается между ними. Вам нужно будет выполнить сложную маршрутизацию BPG и владеть своим IP-пространством.
Вы слишком сильно пытаетесь все усложнить. Лучше сделать все как можно проще и быстро выйти из строя и не беспокоиться о нулевом времени простоя.
Что вам следует делать, так это использовать службу DNS для управления трафиком. У вас есть DNS-сервис, например route53, от AWS или от dyn.com для проверки работоспособности. Поэтому они всегда проверяют оба сайта с помощью проверки работоспособности, чтобы убедиться, что они работают. Он отправляет весь трафик на основной. После сбоя проверки работоспособности на основном сервере он начнет давать ответы DNS для отказоустойчивого сайта.
Это также не очень просто, потому что вам нужно поддерживать активный сайт аварийного переключения, пока вы не убедитесь, что основной полностью синхронизирован с аварийным переключением.
Возможно использование Nginx Plus с его модулем проверки работоспособности. Имейте за собой пул адресов, таких как прокси / балансировщик нагрузки, и он будет проверять, активны ли они, и должен направлять конечных пользователей на. Вы также можете использовать определенные API DNS, которые предоставляют AWS или Azure, например, которые работают с Keepalived, поэтому в случае сбоя он обновит запись DNS на новый LB-сервер.