Azure AI Foundry 模型中 Azure OpenAI 的业务连续性和灾难恢复（BCDR）注意事项

Azure OpenAI 在多个区域中提供。 创建 Azure OpenAI 资源时，指定一个区域。 然后，你的资源及其所有操作都将与该 Azure 服务器区域保持关联。

有时我们会遇到影响整个区域的网络问题，这种情况比较罕见，但也不是没有可能。 如果你的服务需要始终保持可用，则应将其设计为可故障转移到另一区域，或者将工作负载分散到两个或更多个区域。 这两种方法都至少需要两个不同区域中的 Azure OpenAI 资源。 本文提供有关如何为 Azure OpenAI 应用程序实现业务连续性和灾难恢复 (BCDR) 的一般建议。

默认情况下，Azure OpenAI 提供 默认 SLA。 尽管默认复原能力可能足以满足许多应用程序的需求，但需要高度复原和业务连续性的应用程序应采取其他步骤来进一步加强其模型基础结构。

标准部署

1. 对于标准部署，默认为数据区域部署（美国/欧盟选项）。

2. 应在 Azure 订阅中部署两个 Azure OpenAI 资源。 一个资源应部署在你的首选区域中，另一个资源应部署在辅助/故障转移区域中。 Azure OpenAI 在订阅 + 区域级别分配配额，因此它们可以位于同一订阅中，而不会影响配额。

3. 对于计划使用的每个模型，都应有一个部署到你的首选 Azure 区域中的 Azure OpenAI 资源的部署，并且应在辅助/故障转移区域中复制这些模型部署。 将标准部署中可用的完整配额分配给其中每个终结点。 与在多个部署间拆分配额相比，这可提供最高的吞吐量速率。

4. 根据网络拓扑选择部署区域。 可以将 Azure OpenAI 资源部署到任何受支持的区域，然后在首选区域中为该资源创建专用终结点。

   • 在 Azure OpenAI 边界内，Azure OpenAI 可以优化数据区域中可用计算的路由和处理。
   • 使用数据区域比跨多个区域部署进行自管理负载均衡更高效、更简单。

5. 如果发生区域性中断，而部署处于不可用状态，则可以在同一订阅中的辅助/被动区域中使用其他部署。

   • 由于主要部署和辅助部署都是区域部署，因此它们从同一区域容量池中获取资源，而后者从该区域中的所有可用 Azure 区域中获取资源。 辅助部署正在防范主要 Azure OpenAI 终结点无法访问。
   • 使用支持负载均衡和断路器模式的生成式 AI 网关（例如位于 Azure OpenAI 终结点前的 API 管理），以便在发生区域性故障时，将对使用应用程序的中断影响降到最低。
   • 如果给定订阅中的配额已用尽，则可以采用与上面相同的方式部署新订阅，其终结点部署在生成式 AI 网关后面。

预配部署

创建企业 PTU 池

1. 对于预配的部署，我们建议使用单个数据区域 PTU 部署（2024/12/04 可用）作为 PTU 的企业池。 可以使用 API 管理来管理来自多个应用程序的流量，以设置吞吐量限制、日志记录、优先级和故障转移逻辑。
   • 将此企业 PTU 池视为“专用标准部署”资源，可防止在服务需求较高时标准部署上可能出现的邻居干扰问题。 你的组织将获得对一个容量池的有保证、专用的访问，该池仅供你们使用，因此独立于其他客户的需求高峰。
   • 这样，你就可以控制哪些应用程序先经历延迟增加，从而确定到任务关键型应用程序的流量的优先级。
   • 预配的部署由于具有延迟 SLA 的支持，因此在处理延迟敏感的工作负载时，比标准部署更具优势。
   • 企业 PTU 部署还可实现更高的利用率，因为流量会在应用程序工作负载之间平滑分配，而单个工作负载往往更容易出现峰值。
2. 你的主要企业 PTU 部署应位于不同于你的主要标准区域部署的 Azure 区域。 因此，如果发生区域性服务中断，你不会同时失去对 PTU 部署和标准区域部署的访问权限。

工作负载专用 PTU 部署

1. 某些工作负载可能需要有自己的专用预配部署。 如果是这样，你可以为该应用程序创建专用的 PTU 部署。
2. 工作负载和企业 PTU 池部署应防范区域故障。 为此，可将工作负载 PTU 池放置在区域 A 中，并将企业 PTU 池放置在区域 B 中。
3. 此部署应先故障转移到企业 PTU 池，然后再故障转移到标准部署。 这意味着，当工作负载 PTU 部署使用率超过 100% 时，PTU 终结点仍会为请求提供服务，从而为该应用程序实现更高的延迟 SLA。

此体系结构的另一个好处是，它允许使用预配部署来堆叠标准部署，以便你可以调配你偏好的性能和复原能力级别。 这样，就可以跨工作负载使用 PTU 满足基线需求，并利用标准部署来应对流量峰值。

支持基础结构

需要在设计中考虑支持 Azure OpenAI 体系结构的基础结构。 体系结构中涉及的基础结构组件因应用程序是否通过 Internet 或专用网络使用 Azure OpenAI 而异。 本文中讨论的体系结构假定组织已实现生成式 AI 网关。 具有成熟 Azure 足迹和混合连接的组织应通过专用网络使用该服务，而没有混合连接的组织，或者使用其他云（如 GCP 或 AWS）中的应用程序的组织，将通过 Microsoft 公共主干来使用该服务。

为通过 Microsoft 公共主干的使用进行设计

通过 Microsoft 公共主干使用服务的组织应考虑以下设计元素：

1. 部署生成式 AI 网关的方式应确保它在发生 Azure 区域性服务中断时可用。 如果使用 APIM（Azure API 管理），则可以通过在多个区域中部署单独的 APIM 实例或使用 APIM 的多区域网关功能来完成此操作。

2. 公共全局服务器负载均衡器应用于以主动/主动或主动/被动方式跨多个生成式 AI 网关实例进行负载均衡。 Azure FrontDoor 可用于满足此角色，具体取决于组织的要求。

为通过专用网络的使用进行设计

通过专用网络使用服务的组织应考虑以下设计元素：

1. 混合连接的部署方式应防范 Azure 区域故障。 支持混合连接的基础组件包括组织的本地网络基础结构和 Microsoft ExpressRoute 或 VPN。
2. 部署生成式 AI 网关的方式应确保它在发生 Azure 区域性服务中断时可用。 如果使用 APIM（Azure API 管理），则可以通过在多个区域中部署单独的 APIM 实例或使用 APIM 的多区域网关功能来完成此操作。
3. 应为每个 Azure 区域中的每个 Azure OpenAI 实例部署 Azure 专用链接专用终结点。 对于 Azure 专用 DNS，当所有应用程序对 Azure OpenAI 的访问均通过生成式 AI 网关进行时，可以使用分脑 DNS 方法，以提供针对区域性故障的额外保护。 否则，在 Azure 区域丢失时，需要手动修改专用 DNS 记录。
4. 专用全局服务器负载均衡器应用于以主动/主动或主动/被动方式跨多个生成式 AI 网关实例进行负载均衡。 对于需要专用 DNS 解析的工作负载，Azure 没有用于全局服务器负载均衡器的本机服务。 有关本主题的其他背景信息，可参阅此非官方指南：https://github.com/adstuart/azure-crossregion-private-lb。作为对全局服务器负载均衡器的替代，组织可以通过切换生成式 AI 网关的 DNS 记录来实现主动/被动模式。