Рекомендации по непрерывности бизнес-процессов и аварийному восстановлению (BCDR) с помощью Службы Azure OpenAI

Azure OpenAI доступен в нескольких регионах. При создании ресурса Azure OpenAI укажите регион. После этого ресурс и все его операции остаются связанными с этим регионом сервера Azure.

В редких случаях можно столкнуться с сетевой проблемой, которая затрагивает весь регион. Если служба должна всегда быть доступной, необходимо создать ее для отработки отказа в другой регион или разделить рабочую нагрузку между двумя или более регионами. Оба подхода требуют по крайней мере двух ресурсов Azure OpenAI в разных регионах. В этой статье приведены общие рекомендации по реализации непрерывности бизнес-процессов и аварийного восстановления (BCDR) для приложений Azure OpenAI.

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

стандартное развертывание

Примечание.

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

1. Для стандартных развертываний по умолчанию используется развертывание зоны данных (параметры США и ЕС).

2. Необходимо развернуть два ресурса службы Azure OpenAI в подписке Azure. Один ресурс должен быть развернут в предпочитаемом регионе, а другой — в дополнительном регионе или регионе отработки отказа. Служба Azure OpenAI выделяет квоту на уровне подписки и региона, чтобы они могли жить в той же подписке без влияния на квоту.

3. Для каждой модели должно быть развернуто одно развертывание для каждой модели, развернутой в ресурсе Службы Azure OpenAI в предпочитаемом регионе Azure, и следует дублировать эти развертывания модели в дополнительном регионе или регионе отработки отказа. Выделите полную квоту, доступную в развертывании "Стандартный" для каждой из этих конечных точек. Это обеспечивает максимальную скорость пропускной способности по сравнению с разделением квоты между несколькими развертываниями.

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

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

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

   • Так как основное и дополнительное развертывание являются развертываниями зоны, они используют один и тот же пул емкости зоны, который извлекает из всех доступных регионов в зоне. Дополнительное развертывание защищает от основной конечной точки Azure OpenAI, недоступной.
   • Используйте шлюз создания искусственного интеллекта, поддерживающий балансировку нагрузки и шаблон разбиения цепи, например Управление API перед конечными точками службы Azure OpenAI, поэтому прерывание во время регионального сбоя сводится к использованию приложений.
   • Если квота в данной подписке исчерпана, новая подписка может быть развернута таким же образом, как и выше, и ее конечная точка, развернутая за шлюзом создания искусственного интеллекта.

Подготовленные развертывания

Создание пула PTU enterprise

1. Для подготовленных развертываний рекомендуется использовать одно развертывание PTU зоны данных (доступно 12.04.2024), которое служит корпоративным пулом PTU. Вы можете использовать Управление API для управления трафиком из нескольких приложений, чтобы задать ограничения пропускной способности, ведение журнала, приоритет и логику отработки отказа.
   • Подумайте об этом пуле PTU enterprise как о ресурсе частной оплаты по мере использования, который защищает от шумной проблемы соседей, которая может возникнуть в стандартных развертываниях, когда спрос на обслуживание высок. Ваша организация будет иметь гарантированный выделенный доступ к пулу емкости, доступной только для вас, и поэтому независимо от пиков спроса от других клиентов.
   • Это позволяет управлять тем, какие приложения повышают задержку в первую очередь, что позволяет определять приоритет трафика в критически важных приложениях.
   • Подготовленные развертывания поддерживаются соглашениями об уровне обслуживания задержки, которые делают их предпочтительными для развертываний уровня "Стандартный" (с оплатой по мере использования) для конфиденциальных рабочих нагрузок с задержкой.
   • Развертывание корпоративного PTU также обеспечивает более высокую скорость использования, так как трафик сглаживается между рабочими нагрузками приложений, в то время как отдельные рабочие нагрузки, как правило, более склонны к пиковой нагрузке.
2. Основное развертывание PTU предприятия должно находиться в другом регионе, отличном от развертывания основной зоны "Стандартный". Это так, что при наличии регионального сбоя вы не теряете доступ к развертыванию PTU и развертыванию стандартной зоны одновременно.

Развертывание выделенной PTU рабочей нагрузки

1. Для некоторых рабочих нагрузок может потребоваться собственное выделенное развертывание. В этом случае можно создать выделенное развертывание PTU для этого приложения.
2. Развертывания рабочих нагрузок и пула PTU предприятия должны защищаться от региональных сбоев. Это можно сделать, разместив пул PTU рабочей нагрузки в регионе A и пулЕ PTU предприятия в регионе B.
3. Это развертывание сначала должно выполнить отработку отказа в пул PTU Enterprise, а затем в стандартное развертывание. Это означает, что при использовании развертывания PTU рабочей нагрузки превышает 100 %, запросы по-прежнему будут обслуживаться конечными точками PTU, что обеспечивает более высокую задержку обслуживания для этого приложения.

Дополнительное преимущество этой архитектуры заключается в том, что он позволяет стекать развертывания уровня "Стандартный" с подготовленными развертываниями, чтобы можно было использовать выбранный уровень производительности и устойчивости. Это позволяет использовать PTU для базового спроса на рабочие нагрузки и использовать оплату по мере использования для пиков трафика.

Поддержка инфраструктуры

Инфраструктура, поддерживающая архитектуру Azure OpenAI, должна рассматриваться в проектах. Компоненты инфраструктуры, участвующие в архитектуре, зависят от того, используют ли приложения службу Azure OpenAI через Интернет или через частную сеть. В архитектуре, описанной в этой статье, предполагается, что организация реализовала шлюз генерированного искусственного интеллекта. Организации с зрелым объемом ресурсов Azure и гибридным подключением должны использовать службу через частную сеть, а организации без гибридного подключения или с приложениями в другом облаке, например GCP или AWS, будут использовать службу через общедоступную магистраль Майкрософт.

Проектирование использования через общедоступную магистраль Майкрософт

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

1. Шлюз создания искусственного интеллекта должен быть развернут таким образом, чтобы он был доступен в случае регионального сбоя Azure. При использовании APIM (Azure Управление API), это можно сделать, развернув отдельные экземпляры APIM в нескольких регионах или используя функцию шлюза с несколькими регионами APIM.

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

Проектирование использования через частные сети

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

1. Гибридное подключение должно быть развернуто таким образом, чтобы оно защищено от сбоя региона Azure. Подчеркивающие компоненты, поддерживающие гибридное подключение, состоят из локальной сетевой инфраструктуры организации и Microsoft ExpressRoute или VPN.
2. Шлюз создания искусственного интеллекта должен быть развернут таким образом, чтобы он был доступен в случае регионального сбоя Azure. При использовании APIM (Azure Управление API), это можно сделать, развернув отдельные экземпляры APIM в нескольких регионах или используя функцию шлюза с несколькими регионами APIM.
3. Приватный канал Azure частные конечные точки следует развертывать для каждого экземпляра службы Azure OpenAI в каждом регионе Azure. Для Azure Частная зона DNS подход DNS с разделением мозга можно использовать, если все приложения получают доступ к службе Azure OpenAI через шлюз создания искусственного интеллекта, чтобы обеспечить дополнительную защиту от регионального сбоя. Если нет, Частная зона DNS записи должны быть вручную изменены в случае потери региона Azure.
4. Подсистема балансировки нагрузки частного глобального сервера должна использоваться для балансировки нагрузки в нескольких экземплярах шлюза искусственного интеллекта с активным или активным или пассивным способом. Azure не имеет собственной службы для глобальной подсистемы балансировки нагрузки сервера для рабочих нагрузок, требующих частного разрешения DNS. Дополнительные сведения об этом разделе см. в этом неофициальном руководстве: https://github.com/adstuart/azure-crossregion-private-lb Вместо глобальной подсистемы балансировки нагрузки сервера организации могут достичь активного или пассивного шаблона, переключив запись DNS для шлюза генерированных ИИ.