Высокая доступность и AWS VPN

У меня есть вопрос о достижении высокой доступности через AWS VPN.

Контекст:

У меня есть требование установить VPN-соединение "сайт-сайт" между моим AWS VPC и крупной корпорацией. Этот VPN-канал необходим для поддержки входящих http-подключений к приложению в моем AWS VPC. По разным причинам большая корпоративная сеть, к которой я подключаюсь, не выделит мне для использования неконфликтующую частную (RFC1918) подсеть. Вместо этого они требуют, чтобы я использовал NAT для предоставления моих услуг через VPN на публичном IP-адресе по моему выбору (тот, который я зарезервирую). Я считаю, что мне удалось успешно настроить это (при условии тестирования) с правильной комбинацией правил маршрутизации, следуя этому руководству (без отдельного прокси-сервера), однако я могу направлять входящие соединения только на один IP-адрес.

Вопрос:

Мне интересно, есть ли способ, с помощью которого я могу вместо этого направлять соединения на высокодоступный балансировщик нагрузки? Это позволило бы улучшить масштабируемость и высокую доступность. Вещи, которые я рассмотрел:

  • Использование внешнего ELB AWS:
    • У них нет надежных IP-адресов или достаточно узкого диапазона. Я не смог бы добавить такой диапазон в правила маршрутизации справа, так как такой диапазон может конфликтовать с любым другим сервисом, размещенным на AWS.
  • Использование внутреннего ELB AWS:
    • У них есть открытая запись DNS и предсказуемый диапазон, однако они находятся в диапазонах частных IP-адресов и поэтому не могут использоваться клиентской системой, поскольку им разрешено создавать только статические маршруты для открытых IP-адресов не RFC1918.
  • Реализация собственного балансировщика нагрузки, такого как HAproxy:
    • Это решило бы проблему масштабируемости, но все равно оставило бы единственную точку отказа в системе (сам узел HA).
    • Кроме того, это еще одна машина, которую я должен обслуживать.

Кто-нибудь знает, есть ли способ ссылаться на ELB в таблицах маршрутизации VPC? Или есть какие-то другие предложения о том, как этого добиться?

Спасибо

Источник

1 ответ

Машина, завершающая туннель, уже является единственной точкой отказа, не так ли? Если так, то запуск HAProxy тут же кажется идеальным (и я не просто так говорю, потому что так я это делаю, даже если это так).

Я могу сосчитать производственные сбои, вызванные haproxy на одной руке, без использования пальцев (или большого пальца). Асинхронный DNS в версии 1.6 (все еще находящийся в стадии разработки на момент написания этой статьи) позволил бы вам использовать внутренний ELB в качестве бэк-энда для haproxy, позволяя вам в значительной степени установить, забыть и использовать существующие интеграции ELB/EC2 для фактического масштабирования емкости.,

Типы экземпляров C3, C4, M3, R3 и T2 также поддерживают относительно новую функцию восстановления экземпляров, которая останавливает, воссоздает и перезапускает ваш экземпляр на другом оборудовании, но с тем же идентификатором экземпляра, эластичным IP-адресом и томами EBS, если он перестает отвечать на запросы. благоприятно для проверки здоровья экземпляра.

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