Кластерная инфраструктура на VPS
Я хочу построить кластерную инфраструктуру. Единственный вариант, который у меня есть, - это VPS в контейнере. Ниже показано, как должна выглядеть инфраструктура. 
Весь входящий трафик поступает на Fw1. Прокси перенаправляет запрос на AppServerX. Базы данных находятся в другой подсети. Доступ в Безопасную зону осуществляется по Fw2. Монитор машины контролирует состояние всех остальных машин, а также брандмауэры. Как видите, серверы приложений и серверы баз данных сгруппированы для высокой доступности. Также для обеспечения высокой доступности брандмауэры должны быть объединены в кластер. Соединения между машинами должны быть через VPN. Теоретически все звучит хорошо, но практически у меня проблемы. В качестве VPN я планирую использовать серверно-клиентскую архитектуру OpenVPN и межсайтовую связь между зонами. Но у меня проблема, так как я не понимаю, как сделать кластерный брандмауэр. И контролируйте все машины, а также брандмауэры, находящиеся в ведомом режиме. Может архитектура неправильная. Вот почему приветствуются любые предложения. Также напишите о лучших практиках.
Спасибо.
Во-первых, для достижения высокой доступности в кластере брандмауэров есть два способа: первый, который вы используете, заключается в наличии внешнего монитора, который будет постоянно проверять работоспособность всех серверов и брандмауэров посредством пульса. В случае аварийного переключения другой брандмауэр из кластера будет нести ответственность за маршрутизацию и управление подключениями.Другой способ — позволить кластеру самому определить отказоустойчивость , после чего один из подчиненных брандмауэров из кластера станет ведущим. Все состояния соединений будут изящно обработаны новым мастером.
Во-вторых, вы должны решить, хотите ли вы активную -резервную копию или активную -активную конфигурацию для ваших кластеров, соответственно сложность будет различаться. В активном -резервном копировании только один из ваших брандмауэров будет активным (Master ), а другие будут затенены (Slave ). В то время как в случае активного -активный мастер и ведомые будут в рабочем режиме.
Теперь, когда вы решите, как вы хотите обеспечить высокую доступность для своего кластера брандмауэров, вам потребуется либо Heartbeat, либо Keepalived для обслуживания кластера высокой доступности. подчиненных узлах, всякий раз, когда на главном узле происходит аварийное переключение, новый ведущий выбирается путем обмена данными внутри кластера. Для репликации брандмауэра или синхронизации состояний соединения между кластером можно использовать Conntrackd . Это всегда будет держать узлы кластера готовыми изящно взять на себя ответственность мастера, не будучи замеченными сетью.
Концепция виртуальных IP-адресов используется для переключения на один из подчиненных узлов в сценариях аварийного переключения.
Таким образом, я предполагаю, что ваша текущая конструкция хорошо работает без кластера высокой доступности, поэтому вы можете продолжить использовать текущую архитектуру и встроить высокую доступность с помощью этого программного обеспечения в свой кластер.
Важно понимать, чего вы хотите добиться от своего кластера высокой доступности, и, соответственно, продвигаться вперед в реализации. Надеюсь, это поможет.