Вопрос или проблема
Мне нужно перенести существующий SSH-сервис, установленный на 2 разных виртуальных машинах с статическим IP, на новую архитектуру с SSH-сервисом, установленным на AWS EC2-инстансах, сконфигурированных в автоскейлинге с сетевым балансировщиком нагрузки перед ними.
ТЕКУЩАЯ АРХИТЕКТУРА
НОВАЯ АРХИТЕКТУРА AWS
В текущей инфраструктуре агенты инициализируют SSH-соединение с конкретной виртуальной машиной с статическим IP. В новой архитектуре агенты будут обращаться к имени сетевого балансировщика нагрузки, и он будет перенаправлять трафик к EC2-инстансам с динамическим IP, на которых установлен SSH-сервис.
У меня есть 2 вопроса по новой архитектуре:
-
Если агент установил SSH-соединение с конкретным EC2-инстансом, сохраняет ли сетевой балансировщик нагрузки SSH-соединение конкретного агента всегда на конкретном EC2-инстансе, где было инициализировано соединение?
-
В случае уничтожения EC2-инстанса, где находится агент с установленным SSH-соединением, что произойдет с SSH-соединением агента?
- Включите стики-сессии в вашей целевой группе NLB.
- Я подозреваю, что после входа в систему, если EC2-инстанс будет остановлен, SSH-сессия, вероятно, также прервется. Вряд ли удастся установить новую сессию.
Великолепие облака заключается в том, как легко попробовать все это на практике. Это, вероятно, займет час и около $0.05 ресурсов, чтобы попробовать! 🙂
Ответ или решение
Для выполнения миграции SSH-сервиса с существующих виртуальных машин с статическими IP-адресами на новую архитектуру с использованием Amazon EC2 и Network Load Balancer (NLB) стоит внимательно изучить, какими образом распределяются соединения и как управлять сессиями. Давайте подробнее разберём каждый аспект вашей задачи с точки зрения теории, примеров и практического применения.
Теория
Network Load Balancer в AWS является инструментом для распределения входящего трафика между несколькими EC2-инстанциями. В отличие от классического Application Load Balancer, NLB работает на уровне транспорта (Layer 4), что делает его подходящим для обработки высокоскоростных и краткосрочных соединений, включая SSH.
Управление сессиями
-
Sticky Sessions (Стикость сессий): NLB может обеспечивать стабильность сессий путём использования закладок на уровне соединений. Такая конфигурация, известная как "сессии стикости", позволяет закреплять клиентский трафик за одним и тем же сервером в течение определённого времени. Каждая новая сессия требует отдельного выбора инстанса на основе стратегии балансировки (например, round-robin), однако однажды установленная сессия будет удерживаться непрерывно.
-
Текущие соединения: В момент установления SSH-соединения клиент соединяется с конкретным EC2-инстансом через NLB. Если сессия находится в активном состоянии, NLB будет продолжать пересылать пакеты на этот инстанс без перераспределения.
Управление отказами
-
Разрушение инстанса: В случае остановки или завершения инстанса, на который указана сессия, последняя будет прервана. SSH использует транспортный протокол TCP, который не восстанавливает сессионные данные автоматически. Таким образом, агент, поддерживающий сессию, обнаружит обрыв соединения и потребуется будет заново инициировать сессию через NLB.
-
Резервное копирование: В таких ситуациях рекомендуется иметь запасные процедуры восстановления. Это может быть сделано посредством скриптов автоматической переподключения или замены инстансов в парке EC2, а также через управление жизненным циклом автоматического масштабирования.
Примеры
Рассмотрим пример миграции с использованием AWS NLB и EC2 с включенным автоматическим масштабированием:
-
Автоматическое масштабирование: Позволяет динамически изменять количество инстансов в зависимости от нагрузки. Создавайте политики масштабирования (например, на основе среднего процента загрузки CPU), чтобы обеспечить доступность нужного количества серверов для обработки SSH трафика.
-
Использование зон доступности: Разместите EC2-инстансы в нескольких зонах доступности для обеспечения устойчивости к сбоям.
-
Мониторинг и логирование: Включение CloudWatch для мониторинга загрузки системы и журналов доступа поможет вовремя заметить проблемы и настроить соответствующие меры.
Приложение
Для успешного развёртывания новой архитектуры с использованием NLB и EC2 необходимо выполнить следующее:
-
Настройка NLB: Определить экстремальные условия, при которых следует использовать "sticky sessions" для минимизации перераспределений сессий клиентов.
-
Конфигурация EC2 и Auto Scaling: Создать запуск шаблонов инстансов с нужными настройками SSH и ключей доступа. Настроить группы автоматического масштабирования, чтобы обеспечить необходимое количество инстансов.
-
Высокая доступность и отказоустойчивость: Включить более одной зоны доступности. Это снизит риск полной недоступности сервиса в случае сбоя в одной из зон.
-
Планирование отказов и восстановление: Обеспечьте реализацию автоматических сценариев замещения инстансов и переподключения клиентов.
Исследование и тестирование предлагаемых решений в контролируемой среде AWS позволит выявить и решить возможные узкие места в новой архитектуре, сохраняя стабильность SSH-сервисов в условиях изменяющегося или масштабируемого окружения. Использование таких практик, как мониторинг в реальном времени и регулярные тесты аварийного восстановления, способствует увеличению надежности и доступности сервисов.