Поделиться через

Перемещение кластера Azure Service Fabric в новый регион

  • Статья

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

Действия, которые необходимо выполнить для миграции региона

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

Создание нового кластера

  1. Настройте кластер в новом регионе , перенастроив существующий шаблон ARM для топологии кластера и инфраструктуры. Если у вас нет шаблона ARM, описывающего кластер, рекомендуется получить текущий шаблон ARM из Azure Resource Explorer. Обозреватель ресурсов Azure поможет вам обнаружить текущие развернутые ресурсы и сведения о конфигурации, которые можно использовать для создания одного или нескольких шаблонов ARM, которые позволяют многократно развертывать клоны существующей среды. Проверьте и убедитесь, что у вас есть рабочие шаблоны ARM, которые могут развертывать клоны существующей среды на этом этапе, прежде чем продолжить.

Перемещение приложений и трафика

  1. Развертывание существующих приложений и служб с помощью ARM. Следите за сохранением всех параметров приложения или настроек конфигурации, которые вы выполнили. Например, если у приложения есть параметр count со значением по умолчанию 5, но в исходной среде вы обновили значение этого параметра до 7, необходимо убедиться, что развертывание приложения в новом регионе имеет значение 7. Если вы не используете ARM для управления экземплярами приложений и служб, вы несете ответственность за определение текущего набора приложений и служб, работающих в текущем регионе, их конфигурации и дублирования этих приложений и служб в новом регионе или кластере.

  2. Перенос служб

    • Для рабочих нагрузок с отслеживанием состояния:

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

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

    • Для бесcостоянственных служб:

      • Кроме развертывания служб в новом кластере, в идеале в рамках развертывания приложения ARM, выполняемого на шаге 2, не требуется дополнительная работа и обеспечение того, что они настроены так же, как и в исходном кластере.

    • Для всех услуг:

      • Убедитесь, что все этапы взаимодействия между клиентами и службами настроены аналогично исходному кластеру. Например, эта проверка может включать в себя обеспечение того, чтобы посредники, такие как Центры событий, сетевые подсистемы балансировки нагрузки, шлюзы приложений или управление API, были настроены с помощью правил, необходимых для передачи трафика в кластер.

  3. Перенаправьте трафик из старого региона в новый регион. Мы рекомендуем использовать диспетчер трафика Azure для миграции, так как он предлагает ряд методов маршрутизации. Как именно вы обновляете правила маршрутизации трафика, будет зависеть от того, хотите ли вы сохранить существующий регион или отказаться от него, а также от того, как трафик течет в вашем приложении. Возможно, потребуется изучить, можно ли перемещать частные и общедоступные IP-адреса или DNS-имена между различными ресурсами Azure в разных регионах. Service Fabric не знает об этой части вашей системы, поэтому изучите проблему и при необходимости обратитесь к командам Azure, которые работают с потоком трафика, особенно если ситуация более сложная или если ваша рабочая нагрузка критически чувствительна к задержкам. Для проверки могут быть полезны такие документы, как настройка личного домена, общедоступных IP-адресов и зон DNS и записей DNS . Ниже приведены два примера сценария, демонстрирующие способ обновления маршрутизации трафика:

    • Если вы не планируете сохранить существующий исходный регион и у вас есть DNS/CNAME, связанный с общедоступным IP-адресом сетевого балансировщика нагрузки, который направляет вызовы вашему исходному кластеру. Обновите DNS/CNAME, чтобы он был связан с новым общедоступным IP-адресом новой сетевой подсистемы балансировки нагрузки в новом регионе. Завершение этой передачи приведет к тому, что клиенты, использующие существующий кластер, переключятся на использование нового кластера.

    • Если вы планируете сохранить существующий исходный регион и у вас есть DNS/CNAME, связанный с общедоступным IP-адресом сетевого балансировщика нагрузки, который направлял вызовы к вашему исходному кластеру. Настройте экземпляр диспетчера трафика Azure, а затем свяжите DNS-имя с этим экземпляром диспетчера трафика Azure. Диспетчер трафика Azure можно настроить для последующего маршрутизации в отдельные подсистемы балансировки нагрузки сети в каждом регионе.

  4. Если вы планируете сохранить оба региона, то обычно у вас будет какая-то "обратная синхронизация", где источник истины хранится в удаленном хранилище, например в Azure SQL, Azure Cosmos DB или хранилище BLOB-объектов или файлов, который затем синхронизируется между регионами. Если это относится к рабочей нагрузке, рекомендуется убедиться, что данные передаются между регионами, как ожидалось.

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

  1. В качестве окончательной проверки убедитесь, что поток трафика идет как ожидается и что службы в новом регионе (и потенциально в старом регионе) работают как ожидается.

  2. Если вы не планируете сохранить исходный регион, то на этом этапе ресурсы в этом регионе можно удалить. Рекомендуется подождать некоторое время, прежде чем удалять ресурсы, в случае обнаружения проблемы, требующей восстановления исходного региона.

Дальнейшие шаги

Теперь, когда кластер и приложения перемещены в новый регион, необходимо проверить, настроены резервные копии для защиты всех необходимых данных.

Настройка резервных копий после миграции