Миграция из AWS Network Load Balancer в Azure Load Balancer

Если вы используете AWS Network Load Balancer (NLB) и переносите свою нагрузку в Azure, эта статья проведёт вас через процесс миграции — от отображения функций до пересечения трафика. В Azure Azure Load Balancer обеспечивает низкозадержную балансировку нагрузки уровня 4 для трафика TCP и UDP, чтобы ваша нагрузка сохраняла равную производительность и надёжность после перехода с AWS NLB.

Эта статья посвящена миграции на публичный стандарт Azure Load Balancer для сценариев TCP и UDP. Azure Load Balancer не завершает TLS, поэтому если ваша нагрузка зависит от завершения TLS на балансировщике нагрузки, используйте Шлюз приложений Azure.

На высоком уровне вы оцениваете свою среду AWS, готовите и внедряете эквивалентные ресурсы Azure, проверяете конфигурацию и переключаете трафик через DNS.

Необходимые условия

• Учетная запись Azure с активной подпиской. Создайте учетную запись бесплатно.
• Разрешения в Azure для создания ресурсов балансировщика нагрузки, общедоступного IP-адреса, виртуальной сети, группы безопасности сети, виртуальной машины или масштабируемого набора виртуальных машин.
• Доступ к вашей существующей среде AWS с разрешениями для чтения конфигураций NLB, слушателя и целевой группы (например, через AWS CLI для Elastic Load Balancing).
• Инвентаризация TCP и UDP-портов вашей нагрузки, настроек проверки состояния и требований по сохранению IP клиента.
• Контроль над DNS-записями, которые указывают на ваш балансировщик нагрузки, чтобы уменьшить TTL и переключить трафик.
• Azure CLI или инструментарий инфраструктуры как код для развертывания и настройки ресурсов Azure.

То, что вы делаете

Следуя этому руководству, вы получите следующее:

• Сопоставление функций Aws Network Load Balancer с возможностями Azure Load Balancer
• Подготовка сред к успешной миграции
• Планирование и выполнение миграции с минимальным временем простоя
• Проверка соответствия перенесенной рабочей нагрузки требованиям к производительности и надежности
• Узнайте, как итерировать архитектуру для будущих улучшений

В этой статье используется сценарий игровой платформы для демонстрации распространенных шаблонов, таких как балансировка нагрузки с несколькими протоколами, избыточность зоны и сохранение IP-адресов клиента, которые применяются ко многим высокопроизводительными рабочими нагрузками.

Пример сценария: миграция балансировки нагрузки на платформу Gaming с несколькими протоколами

В этом примере многопользовательская игровая платформа использует AWS Network Load Balancer (NLB) для одновременной обработки как TCP, так и UDP-трафика от игровых клиентов. Архитектура рабочей нагрузки включает сервисы управления сессиями, работающие на экземплярах EC2, обеспечивающие аутентификацию игроков и лобби через TCP на порте 7777, а также сервисы игровых данных в реальном времени, работающие на экземплярах EC2, обрабатывающие пакеты с низкой задержкой по UDP на порте 7778. NLB AWS предоставляет статические IP-адреса, балансировку нагрузки между зонами и сохранение IP-адресов клиента для аналитики игр и системы защиты от обмана. Эта конфигурация поддерживает основную функцию рабочей нагрузки — обработку многопользовательских игр в реальном времени с низкой задержкой, при этом сохраняя надёжность в нескольких зонах доступности.

Обзор архитектуры

Этот пример архитектуры демонстрирует общие функции балансировки сетевой нагрузки в AWS и Azure, включая поддержку нескольких протоколов, статические IP-адреса, межзональное распределение и сохранение IP-адресов клиента. Цель — перенести эту архитектуру из AWS Network Load Balancer в Azure Load Balancer, сохраняя эквивалентные функциональные возможности и производительность. В архитектурной диаграмме TCP-трафик представляет сервисы управления игровыми сессиями, а UDP-трафик — сервисы игровых данных в реальном времени.

Ниже приведена архитектура рабочей нагрузки в AWS:

Это архитектура для той же рабочей нагрузки игровой платформы, перенесенной в Azure:

Обе архитектуры предоставляют эквивалентные возможности:

• Развертывание с высоким уровнем доступности: ресурсы, распределенные между несколькими зонами доступности для отказоустойчивости
• Сетевая изоляция: виртуальная сеть с выделенными подсетями для подсистемы балансировки нагрузки и уровней приложений
• Поддержка нескольких протоколов: одновременная обработка трафика TCP и UDP с пулами серверной части для конкретного протокола
• Статические IP-адреса: согласованные внешние адреса конечных точек для клиентских подключений
• Балансировка нагрузки между зонами: распределение трафика на основе хэша между зонами доступности (распределение зависит от шаблонов подключения клиента и параметров сохраняемости сеансов)
• Сохранение IP-адресов клиента: исходные IP-адреса клиента, поддерживаемые для аналитики и защиты от обмана систем
• Низкая задержка: оптимизировано для сценариев с низкой задержкой с минимальными затратами на обработку; фактическая задержка зависит от топологии сети, производительности виртуальных машин, проектирования центра обработки данных и географического расположения
• Высокая пропускная способность: может поддерживать миллионы потоков для Load Balancer (цен. категория "Стандартный") с соответствующими размерами виртуальных машин (VM) и конфигурацией; фактические возможности зависят от SKU, сетевых ограничений VM и настроек.
• Расширенный мониторинг работоспособности: комплексные пробы работоспособности TCP и HTTP/HTTPS (для служб UDP требуется проверка работоспособности TCP или HTTP на альтернативных портах)
• Элементы управления безопасностью сети: группы безопасности и правила, управляющие потоком трафика между сетевыми уровнями
• Интеграция с автоматическим масштабированием: Интегрируется с Масштабируемые наборы виртуальных машин и правилами автомасштабирования для масштабирования экземпляров бэкенда в зависимости от спроса на трафик и использования ресурсов
• Комплексный мониторинг: подробные метрики, диагностика и мониторинг работоспособности для устранения неполадок и оптимизации

Рекомендации по рабочей среде

Эта миграция использует подход пересечения. Благодаря этому подходу вы создаете инфраструктуру Azure параллельно с существующей настройкой AWS. Этот подход сводит к минимуму сложность миграции пользователей в пакетах и обеспечивает быстрый откат при возникновении каких-либо проблем. В результате вы испытываете кратковременные простои во время перехода DNS, но общий процесс миграции минимизирует сбои в работе ваших сервисов.

Предполагаемое время простоя

• Время распространения DNS: 5–15 минут для 300-секундного TTL
• Нарушение сессий: Переключение может прервать существующие сессии
• Доступность службы: во время перехода службы недоступны, так как они зависят от разрешения DNS-имен. Отдельные сервисы по-прежнему доступны по IP-адресу, если вы не мигрируете их одновременно.

Рекомендуемое окно обслуживания

• Продолжительность: 1–2 часа в период малотрафика
• Буферное время: дополнительные 30 минут для непредвиденных проблем
• Время отката: 15–30 минут при необходимости

Оцените вашу среду AWS Network Load Balancer

Перед миграцией с AWS Network Load Balancer на Azure Load Balancer оцените существующую архитектуру и определите, какие возможности можно сопоставить или заменить. Эта оценка помогает обеспечить плавный процесс миграции и поддерживать функциональные возможности вашей игровой платформы.

Чтобы спланировать миграцию рабочей нагрузки AWS в Azure, см. раздел «Migrate networking from Amazon Web Services to Azure», где приведены примеры сценариев миграции, которые могут соответствовать вашему сценарию использования.

Сопоставление прямых возможностей

Возможности платформы сопоставляются между AWS NLB и Azure Load Balancer по четырём направлениям: обработка внутренних серверов и протоколов, распределение трафика и IP-адресация, масштабирование и схема балансировщика нагрузки, а также TLS, тайм-аут простоя и мониторинг.

Серверные пулы, протоколы и мониторинг состояния

В следующей таблице сопоставлены внутренние серверы, протоколы и возможности проверок работоспособности AWS NLB с внутренними пулами Azure Load Balancer, правилами балансировки нагрузки и пробами работоспособности:

Распределение трафика и IP-адресация

Следующая таблица сопоставляет возможности распределения трафика NLB AWS и IP-адресации с статическими публичными IP-адресами Azure Load Balancer, режимами избыточности зон и распределения:

Схема масштабирования и балансировки нагрузки

Следующая таблица сопоставляет возможности масштабирования и варианты развертывания AWS NLB с наборами масштабирования виртуальных машин Azure и конфигурациями Azure Load Balancer — общедоступными или внутренними:

TLS, тайм-аут в режиме простоя и мониторинг

Следующая таблица сопоставляет возможности AWS NLB в области TLS, тайм-аута простоя и мониторинга с соответствующими им аналогами в Azure Load Balancer, Шлюз приложений Azure и Azure Monitor:

Несоответствия возможностей и стратегий

Если ваша нагрузка использует возможности NLB, которые Azure Load Balancer не может напрямую реализовать, рассмотрите следующие стратегии для достижения аналогичного результата.

• Прямая функциональная замена с помощью другого сервиса Azure: заменить возможности AWS NLB на эквиваленты Azure Load Balancer при сохранении основной функциональности. Этот подход определяет минимальные нарушения и использует собственные интеграции Azure для обеспечения безопасности, мониторинга и оптимизации производительности.

• Подход к улучшению архитектуры: используйте миграцию в качестве возможности модернизации за пределами возможностей AWS NLB, включив API-интерфейсы Шлюза приложений Azure для HTTP(S), диспетчер трафика Azure для глобального распространения и защиту Azure Front Door для CDN и DDoS.

Решите, нужна ли функция AWS NLB, если нет прямого аналога Azure Load Balancer, и соответственно скорректируйте нагрузку.

Поддержка протокола прокси

Возможности NLB AWS: AWS NLB предоставляет поддержку прокси-протокола версии 2, где:

• Сохраняет IP-адрес клиента и передаёт её бэкенд-целям через заголовки протокола
• Обеспечивает видимость IP-адресов клиента, даже если сохранение IP-адресов прямого клиента недоступно
• Полезно для сценариев цепочки подсистем балансировки нагрузки и конкретных сетевых конфигураций

Подход Azure Load Balancer: Azure Load Balancer не поддерживает прямой прокси-протокол, но обеспечивает эквивалентную функциональность с помощью:

• Решения на уровне приложения: реализация пользовательских заголовков или логики приложения для отслеживания сведений о клиенте при необходимости
• Шлюз приложений Azure integration: Для API на основе HTTP используйте Application Gateway, который предоставляет X-Forwarded-For заголовки

Предыдущая поддержка протокола прокси иллюстрирует критическое несоответствие возможностей. Другие функции могут не иметь одиночных аналогов в Azure Load Balancer. Перед миграцией оцените функции, которые вы используете в AWS NLB, и определите, есть ли у них прямые аналоги или нужны альтернативные стратегии.

Подготовьте свои среды AWS и Azure

Подробная оценка может выявить возможности для настройки ресурсов в источнике, упрощая как процесс миграции, так и операции после миграции. На этом шаге основное внимание уделяется целевым корректировкам конфигураций NLB AWS и связанным службам, чтобы обеспечить совместимость и производительность в Azure для рабочих нагрузок.

Конфигурация исходной службы

Для успешной миграции требуется подробная документация по существующим конфигурациям NLB AWS и зависимым службам, чтобы обеспечить плавное переход в Azure Load Balancer.

Документация по правилу балансировки нагрузки для конкретного протокола

• Задокументируйте существующие конфигурации прослушивателя NLB AWS и параметры целевой группы, чтобы обеспечить эквивалентные правила Azure Load Balancer. Используйте команды AWS CLI для подсистем балансировки нагрузки для сбора подробных сведений о конфигурации для протоколов TCP и UDP.
• Экспортируйте все конфигурации маршрутизации, настройки проверки состояния и сохранения IP клиента, используя документацию целевой группы AWS NLB.
• Задокументируйте параметры балансировки нагрузки между зонами и статические IP-конфигурации, чтобы обеспечить эквивалентную избыточность зоны Azure и настройку статического общедоступного IP-адреса.

Сопоставление конфигурации проверки работоспособности

Сопоставьте конфигурации проверки состояния AWS NLB с эквивалентами Azure Load Balancer health probe, используя руководство по конфигурации Azure Load Balancer health probe. Такое отображение гарантирует, что мониторинг состояния TCP-сервисов продолжает работать корректно после миграции, а также чтобы вы реализовали соответствующие альтернативные стратегии проверки состояния для UDP-сервисов (используя TCP или HTTP-зонды на альтернативных портах) с соответствующими интервалами для ваших рабочих нагрузок.

Создание базовых показателей производительности

• Запись текущих метрик производительности, включая процентиль задержки (P50, P95, P99), одновременные подключения, пропускную способность и скорость потери пакетов
• Документируйте текущие шаблоны масштабирования и характеристики пиковой нагрузки
• Зафиксировать требования к сохранению IP-адресов клиента для систем аналитики и безопасности

Изменения зависимостей

Подготовьтесь к миграции, обновив зависимые службы и конфигурации, чтобы обеспечить совместимость с Azure Load Balancer.

Изменения приложения

• Настройте мониторинг состояния ваших сервисов через TCP, HTTP или HTTPS с помощью зондов Azure Load Balancer.
• Настройте интеграцию ведения журналов с Azure Monitor, используя метрики балансировщика нагрузки.

Изменения конфигурации DNS

• Уменьшите значения TTL DNS в записях домена до 300 секунд (или 60 секунд для минимальных требований к времени простоя) для ускорения перехода.
• Если вы планируете использовать Azure DNS, создайте записи A, указывающие на статические публичные IP-адреса Azure Load Balancer, используя руководство по конфигурации Azure DNS. Это изменение позволяет обеспечивать быстрое распространение DNS во время перехода на миграцию с минимальным воздействием на активные сессии.

Обновления серверного пула

• Настройка состава серверного пула в нескольких зонах доступности для TCP и UDP служб
• Использование масштабируемых наборов виртуальных машин Azure для служб с автоматическим масштабированием на основе метрик приложений
• Реализация стратегий распределения зон, которые поддерживают производительность во время сбоев зоны

Изменения окружающей среды

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

Подготовка ресурсов Azure

• Разверните Azure Load Balancer, виртуальные машины и масштабируемые наборы виртуальных машин, используя инфраструктуру как код до переключения, следуя руководствам по развертыванию балансировщика нагрузки.
• Настройте статические общедоступные IP-адреса и избыточность зоны перед переключением для обеспечения стабильности платформы.
• Обеспечить тщательное тестирование и валидацию в параллельной среде перед переходом к производству.

Настройка безопасности сети

• Настройте группы безопасности сети (NSG), соответствующие правилам группы безопасности AWS для ваших требований к трафику.
• Настройте защиту от DDoS для рабочих нагрузок с помощью Azure DDoS Protection.
• Поддерживайте уровень безопасности до, во время и после миграции.

Конфигурация мониторинга

• Настройте журналы событий работоспособности Azure Load Balancer в рамках базового мониторинга. В зависимости от плана миграции настройте дополнительный мониторинг по мере необходимости.
• Настройте дашборды и правила оповещения, включая мониторинг задержек, одновременные соединения и состояние состояния зонда, используя стандартную диагностику Azure Load Balancer.

Контрольный список перед миграцией

Выполните следующие задачи до дня миграции. Выполняйте их по порядку: последовательность важна, потому что каждая задача обеспечивает доступность зависимых сервисов до начала следующей, сохраняя функциональность на протяжении всей миграции. Общий процесс включает развертывание инфраструктуры, миграцию сервисов, а затем конфигурацию правил балансировки нагрузки, зондов здоровья и мониторинга.

Хотя конкретные задачи могут различаться в зависимости от вашей архитектуры, выполняйте их в следующем порядке:

1. Развертывание инфраструктуры Azure — сначала разверните балансировщик нагрузки со статическими IP-адресами и виртуальные машины, так как это необходимо для последующих шагов настройки.
2. Конфигурация зонда здоровья — Настройте зонды здоровья для обоих типов протоколов, соответствующие поведению проверки состояния AWS, используя руководство по зонду здоровья Load Balancer.
3. Конфигурация правил, специфичная для протокола — Настройте отдельные правила балансировки нагрузки для трафика TCP и UDP с соответствующими бэкэнд-пулами.
4. Подготовка DNS — Уменьшите значения TTL и подготовьте обновления DNS-записей для ваших доменов. Этот шаг критически важен для минимизации отключения пользователя во время переключения.
5. Миграция служб приложений—Перенесите службы на виртуальные машины Azure и в масштабируемые наборы виртуальных машин. Запускайте эту миграцию параллельно с развертыванием инфраструктуры Azure, чтобы сэкономить время.
6. Настройка мониторинга — Настройте панели управления Azure Monitor и оповещения для специфических для приложения метрик, включая задержку, соединения и состояние здоровья.

Убедитесь, что все задачи в этом чек-листе выполнены, прежде чем начать переход. Как правило, процесс миграции включает развертывание и настройку новой инфраструктуры подсистемы балансировки нагрузки, а затем миграцию служб приложений и настройку мониторинга.

Определить критерии валидации и методы тестирования

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

Критерии проверки

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

Определение критериев успешности

Установите критерии валидации на основе оригинальных возможностей AWS NLB, которые вы определили в разделе оценки:

Функциональные критерии

• Точность маршрутизации с несколькими протоколами: маршруты трафика TCP и UDP для исправления внутренних пулов на основе протокола и порта
• Работоспособность служб: все службы сообщают о работоспособном состоянии во всех зонах
• Распределение между несколькими зонами: трафик правильно распределяется с автоматическим переключением при отказе между зонами доступности
• Обработка подключений. Сеансы поддерживают подключение во время изменений инфраструктуры и масштабирования событий

Критерии производительности

• Базовые показатели задержки: время отклика в пределах 5% базовых показателей NLB AWS
• Емкость пропускной способности: обработка эквивалентных одновременных подключений и запросов в секунду с помощью NLB AWS
• Создание подключения: задержка создания нового сеанса соответствует требованиям
• Минимизация дрожания: обеспечение согласованного времени доставки пакетов для плавной работы

Критерии надежности

• Непрерывность сеансов. Сеансы обеспечивают непрерывность соединения во время отказов зоны и событий масштабирования
• Высокая доступность: Время бесперебойной работы соответствует требуемому SLA, а автоматическое переключение при сбое происходит в течение нескольких секунд.
• Соглашение об уровне обслуживания для конкретной платформы: соответствие требованиям конкретной платформы для взаимодействия с пользователем
• Функции безопасности: Функции отслеживания IP-адресов клиента работают корректно для систем выявления мошенничества

Методы проверки рабочей нагрузки

Определите методы для проверки критериев успеха, которые вы установили для своих рабочих нагрузок. Эти методы включают как автоматизированное, так и ручное тестирование для обеспечения полного покрытия всех возможностей.

Автоматическое тестирование

• Создайте комплексные автоматизированные тесты, охватывающие все возможности, включая:
  • Проверка балансировки нагрузки с несколькими протоколами для трафика TCP и UDP
  • Тестирование производительности и нагрузки по базовым метрикам с использованием соответствующих инструментов
  • Тестирование задержки и джиттера для требований в режиме реального времени
  • Тестирование отказоустойчивости подключения и сценариев масштабирования под нагрузкой

Контрольный список ручной проверки

• Тестирование клиентских подключений между службами TCP и UDP
• Проверка корректности потоков создания сеанса, выполнения операций и завершения
• Тестирование функций системы безопасности с сохранением IP-адресов клиента
• Проверка производительности в режиме реального времени в условиях пиковой нагрузки
• Проверка сохраняемости сеанса во время сбоев зоны и событий масштабирования
• Проверка сбора данных аналитики и мониторинга

Выполнить переключение миграции

После выполнения плана миграции и завершения подготовительных изменений вы можете перейти вперед. Следуйте этим шагам, чтобы выполнить миграцию в день миграции, минимизируя влияние на активные сессии.

Выполнение миграции

Выполнение миграции включает в себя ряд шагов, чтобы обеспечить плавный переход с AWS NLB на Azure Load Balancer. Этот процесс включает окончательную проверку, параллельное тестирование, переключение DNS, проверку после переключения и списание ресурсов AWS.

Окончательная проверка и тестирование

Перед переходом проверьте конфигурацию и работоспособность службы Azure Load Balancer:

• Тестирование конечных точек TCP и UDP с соответствующими клиентами
• Проверка маршрутизации нескольких протоколов для различных типов служб
• Подтверждение распределения серверного пула с несколькими зонами и переключения при отказе сервиса
• Проверка функциональности службы в нескольких зонах с помощью реалистичных сценариев
• Проведение тестов сценариев высокой доступности и зональной отработки отказов под нагрузкой
• Сравнение метрик производительности с базовыми показателями сетевого балансировщика нагрузки AWS, включая задержку и джиттер (jitter)
• Проверьте конфигурацию гостевой ОС с плавающим IP (DSR) и предварительные проверки сетевой безопасности (настройка loopback интерфейса, включение слабого хоста при необходимости и разрешение Load Balancer probe IP 168.63.129.16 в NSG/файрволах)

Выполнение переключения DNS

Выполните переключение DNS из AWS NLB в Azure Load Balancer. Обновите DNS-записи домена, чтобы указывать на статические публичные IP-адреса Azure Load Balancer и отслеживайте распространение DNS с помощью инструментов мониторинга DNS.

После проверки переключения

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

Функциональная проверка

• Проверьте правильность всех функций маршрутизации служб для обоих протоколов
• Проверка функций сохранения IP-адресов клиента для систем безопасности
• Потоки процессов создания, работы и завершения тестового сеанса
• Проверка поведения проб работоспособности для служб TCP и альтернативных методов проверки работоспособности для служб UDP

Проверка производительности

• Отслеживайте время отклика и задержку по сравнению с эталонными показателями AWS NLB
• Проверка того, что емкость пропускной способности соответствует требованиям одновременных сеансов
• Тестирование скорости дрожи и потери пакетов для качества в режиме реального времени

Списание ресурсов AWS

После успешной проверки выведите ресурсы AWS из эксплуатации:

• Отслеживайте Azure Load Balancer в течение 24–72 часов под рабочей нагрузкой, при необходимости увеличивая период наблюдения, чтобы охватить периоды пиковой нагрузки
• Убедитесь в отсутствии маршрутизации трафика на AWS NLB
• Создайте резервную копию конфигурации AWS NLB для возможности отката
• Завершите AWS NLB и связанные инфраструктурные ресурсы

В целом считайте миграцию успешной, если она стабильно соответствует всем критериям успеха в течение определенного вами периода мониторинга и не показывает снижения производительности по сравнению с базовым уровнем AWS NLB. Расширьте мониторинг, чтобы охватывать пиковые часы и трафик в выходные, по мере необходимости перед окончательным отключением.

План отката

Поскольку эта миграция выполняется по схеме cutover, при которой AWS и Azure работают параллельно, вы можете быстро выполнить откат, если проверка завершится неуспешно. Подготовьте план отката перед переключением, чтобы команда могла действовать без задержек.

Откатные триггеры

Откатывайте назад, если после пересечения возникает любое из следующих состояний, и вы не сможете быстро их решить:

• Функциональная валидация не проходит. Например, TCP или UDP-трафик не направляется в правильный бэкенд-пул, или сохранение IP клиента перестаёт работать для систем безопасности.
• Задержка, джиттер или потеря пакетов превышают базовый уровень AWS NLB более чем на согласованный порог.
• Проверки работоспособности сообщают, что экземпляры серверной части считаются неработоспособными во всех зонах доступности.
• Уровень ошибок или отключения сессий превышает допустимый уровень.

Реверсия DNS

• Верните A-записи домена так, чтобы они снова указывали на IP-адреса AWS NLB. Поскольку вы понизили TTL до перехода (300 секунд, или 60 секунд для более быстрого распространения), большинство резолверов фиксируют изменение за считанные минуты.
• Следите за распространением DNS и убедитесь, что клиенты снова разрешают доступ к NLB AWS.

Сохранение ресурсов AWS

• Оставляйте AWS NLB, целевые группы и внутренние экземпляры EC2 запущенными в течение всего периода мониторинга, чтобы откат можно было выполнить немедленно и без пересборки.
• Сохраняйте резервную конфигурацию AWS NLB до финальной валидации и вывода из эксплуатации ресурсов AWS.

Валидация после отката

• Проверьте, что трафик TCP и UDP правильно маршрутизируется через AWS NLB.
• Подтвердите сохранение IP-адреса клиента и поведение проверки работоспособности для обоих протоколов.
• Сравните производительность с базовым уровнем, чтобы убедиться, что нагрузка стабильна.

Ожидаемое время

• Возвращение DNS обычно занимает 15–30 минут, что соответствует времени отката в вашем окне обслуживания. Выявите и устраните первопричину, прежде чем снова пытаться выполнить переключение.

Итеративная оптимизация

После миграции оптимизируйте конфигурацию Azure Load Balancer и проверьте производительность, точность маршрутизации и высокую доступность. Этот итеративный процесс оптимизации гарантирует, что мигрированная рабочая нагрузка соответствует всем критериям успеха, установленным вами на этапе оценки, следуя сервисному руководству Azure Well-Architected Framework для Azure Load Balancer.

Итеративный процесс улучшения

Процесс миграции является итеративным. Корректируйте его на основе обратной связи и тестирования до тех пор, пока не достигнете критериев успеха:

Цикл оптимизации производительности

1. Базовое измерение. Сравнение метрик Azure Load Balancer с базовыми показателями AWS NLB, включая задержку, jitter и метрики подключения
2. Идентификация узких мест: выявление пробелов в производительности при маршрутизации, обработке протоколов или внутреннем взаимодействии
3. Настройка конфигурации: настройка параметров Load Balancer, интервалов внутренних проб, ограничений подключения и параметров для конкретного приложения
4. Проверочное тестирование: повторное тестирование производительности с имитируемыми нагрузками и измерение улучшений
5. Корректировка мониторинга. Обновление пороговых значений мониторинга и правил генерации оповещений для ключевых показателей эффективности для конкретных приложений

Уточнение точности маршрутизации

1. Анализ шаблонов трафика: мониторинг фактических шаблонов маршрутизации запросов и ожидаемых шаблонов для TCP и UDP
2. Оптимизация правил протокола. Уточнение правил маршрутизации TCP и UDP для обработки пограничных вариантов и шаблонов подключений
3. Анализ частоты ошибок: определение и исправление правил маршрутизации, вызывающих ошибки сеанса или отключения
4. Проверка взаимодействия с пользователем. Обеспечение эффективной работы сеансов между обоими типами служб

Проверка высокого уровня доступности

1. Проверка распределения трафика: убедитесь, что трафик распределяется правильно между зонами доступности для обоих протоколов.
2. Тестирование процесса переключения: проверка автоматического переключения между зонами во время пиковых нагрузок
3. Возможность восстановления. Тестирование быстрого восстановления из сбоев зоны при сохранении активных сеансов
4. Точность проверки работоспособности: Убедитесь, что проверки работоспособности правильно выявляют проблемы со службой и исключают ложные срабатывания.

Основные выводы

Миграция рабочей нагрузки, использующая AWS Network Load Balancer в Azure, требует тщательного планирования и систематического выполнения для получения эквивалентных функциональных возможностей и производительности для требований в режиме реального времени. К ключевым факторам успеха относятся следующие факторы:

Оценка и планирование. Сопоставление возможностей NLB AWS с эквивалентами Azure Load Balancer в начале процесса. Обратите особое внимание на поддержку нескольких протоколов, сохранение IP-адресов клиента и требования к низкой задержке для высокопроизводительных платформ.

Используйте интеграции Azure: воспользуйтесь статическими общедоступными IP-адресами Azure для согласованных конечных точек, Azure Monitor для наблюдения и масштабируемых наборов виртуальных машин для автомасштабирования служб для удовлетворения функциональных и нефункциональных требований в рабочей нагрузке.

Тщательно протестируйте перед переключение: используйте параллельное тестирование с инструментами моделирования для проверки всех функциональных возможностей. Установите базовые метрики из среды AWS и убедитесь, что Azure Load Balancer соответствует или превышает ожидания производительности, включая задержку, jitter и обработку подключений.

Планирование минимального простоя: сокращение значений TTL DNS заранее и подготовка всей инфраструктуры параллельно. Фактический переход включает изменения только в DNS, минимизируя нарушения сеанса и влияние на пользователя.

Мониторинг и оптимизация после миграции. Используйте итеративный процесс улучшения для точной настройки производительности, точности маршрутизации и высокой доступности. Azure Load Balancer предоставляет широкие возможности мониторинга для оптимизации конфигурации с помощью реальных шаблонов трафика.

Рекомендации для конкретной платформы: сосредоточьтесь на оптимизации с учетом задержки, обработке трафика с несколькими протоколами, сохранении IP-адресов клиента для систем безопасности и избыточности зоны для обеспечения высокой доступности. Azure Load Balancer обеспечивает надежность и производительность корпоративного уровня, необходимую для критически важных платформ, хотя фактическая производительность задержки зависит от проектирования центра обработки данных и топологии сети.

Troubleshooting

Используйте следующие рекомендации для решения распространённых проблем во время и после переключения.

После переключения трафик по-прежнему маршрутизируется через AWS NLB

Некоторые клиенты и рекурсивные резолверы продолжают разрешать данные в AWS NLB после перехода, потому что кэшируют DNS-записи. Уменьшите TTL (300 секунд, или 60 секунд для более быстрого распространения) перед переходом и держите AWS NLB включённым до тех пор, пока окно мониторинга не подтвердит, что трафик полностью переключён. Распространение зависит от upstream-резольверов, поэтому нельзя гарантировать это для каждого клиента.

Сервисы UDP отображаются как неработоспособные

Azure Load Balancer не поддерживает нативные UDP-зонды здоровья. Если UDP-бэкенды определяются как неработоспособные, настройте проверку работоспособности по TCP или HTTP/HTTPS на альтернативном порте, которая отражает работоспособность службы UDP, и убедитесь, что интервал проверки и порог перехода в состояние «неработоспособен» соответствуют требованиям вашей рабочей нагрузки.

Плавающие IP-соединения (DSR) выходят из строя

При включении плавающего IP (Direct Server Return) необходимо настроить гостевую ОС так, чтобы она принимала трафик. Настройте интерфейс обратной петли с IP-адресом внешнего интерфейса балансировщика нагрузки, включите слабую модель хоста там, где это необходимо, и убедитесь, что приложение прослушивает ожидаемый порт. Отсутствие конфигурации гостевой ОС — частая причина неудачных соединений с плавающими IP-правилами.

Проверки работоспособности завершаются сбоем и помечают все серверы серверной части как неработоспособные

Проверки работоспособности Azure Load Balancer выполняются с IP-адреса 168.63.129.16. Если проверки завершаются сбоем, убедитесь, что ваши группы безопасности сети и все брандмауэры узлов разрешают входящий трафик с 168.63.129.16 на порт проверки. Блокировка этого адреса обозначает все экземпляры бэкенда как нездоровые.

Следующий шаг