IBM Cloud Docs
故障转移选项

故障转移选项

了解可用于提高组织的 watsonx Assistant 可用性的选项。

简介

IBM® watsonx™ Assistant 实例部署在所有数据中心 (首尔，韩国除外) 的多专区区域 (MZR) 中，可以承受 MZR 中任何单个专区的损失。 但是，可能会发生区域中断，当 IBM 努力将中断保持在最低限度时，您可能需要考虑将流量移至业务关键型应用程序的其他区域。

您应该在不同的 MZR 中具有 watsonx Assistant 实例的副本 (例如，在美国东部和美国南部部署助手)。 您必须购买 watsonx Assistant的第二个服务实例，并且需要实例化必要的助手和技能的第二个实例。 您必须实施变更管理控制以同步两个区域之间的变更。 watsonx Assistant 和 Speech 服务具有可用于导出和导入定义的 API。

对于两个实例，请考虑两种拓扑:

  • 主动/主动: 这两个实例始终使用在这两个实例之间喷洒的负载来处理流量。
  • 主动/被动: 一个实例处于主动状态，仅当发生故障转移时，被动站点才会接收流量。

每种方法都有利有弊。 以下部分详细说明了特定于 watsonx Assistant 的注意事项。

注意事项

一个区域中的 IBM® watsonx™ Assistant 实例不知道第二个区域中的实例，这可能会影响 watsonx Assistant中的某些功能部件和功能。

分析

IBM® watsonx™ Assistant 分析提供有关与用户的交互次数和包含率的概述统计信息。 分析不会累积跨区域的统计信息。 通过主动/被动拓扑，这种分析方法就足够了。 但是，使用主动/主动拓扑可能要求您使用 webhook 来收集交互数据，并构建定制数据仓库和报告以了解总使用情况。

Web 聊天和 v2 API 的会话历史记录

会话历史记录允许您的 Web 交谈在用户刷新页面或更改到同一 Web 站点上的其他页面时维护对话历史记录和上下文。 此功能在实例之间不起作用，因此需要重新启动进行中的对话。

计费

IBM 根据 IBM Cloud 帐户计算帐单。IBM® watsonx™ Assistant 通过在特定服务实例中聚集来计算每月平均用户 (MAU) 度量，如下所示:

  • 在 同一 服务实例中的 2 不同助手资源中使用的相同 MAU 计为 1 MAU
  • 在 不同 服务实例中的 2 不同助手资源中使用的相同 MAU 计为 2 个 MAU

对于 主动/主动 拓扑，在最坏的情况下，MAU 计数最终可能会在计费周期内加倍。

电话集成

一个区域中的电话集成不知道另一个区域中的电话集成。 您需要确保助手在两个区域中配置相同。 您还需要依赖上游 SIP 中继提供者来检测和管理区域之间的故障转移。

Monitoring

可以将 SIP 中继提供者配置为主动运行状况-通过向区域中的每个区域发送定期 SIP OPTIONS 消息来检查 watsonx Assistant 会话边界控制器 (SBC)。 接收响应失败可用于提供故障通知以触发手动故障转移，或自动从路由列表中除去故障区域。

故障转移

SIP 中继提供者在检测和管理故障转移方面起着重要作用，尤其是在区域之间需要自动故障转移的情况下。 通常，应将 SIP 中继提供者配置为将区域中的每个区域视为主动/主动，并将助手配置为主动/被动的两个区域。 SIP 中继提供者应始终配置为在单个区域中的区域之间均衡负载和故障转移。

完全停运

电话集成故障有两种类型。 第一种类型是完全中断，其中所有 3 区域区域中的会话边界控制器变为不可访问。 这种类型的中断更易于检测和处理，因为 SIP 超时会立即通知 SIP 中继提供者呼叫失败，并且可以配置为自动故障转移，或者可以在 SIP 中继提供者处手动重新配置呼叫路由，以将来自失败区域的流量引导到被动备份区域。 如果自动执行故障转移并且启用了区域备份，那么始终最好先尝试其他区域，并且仅当在短时间内发生预先配置的失败次数时，才将流量重定向到被动备份区域。 如果仅发生短暂中断，那么这将防止区域之间发生不必要的故障转移。

IBM® watsonx™ Assistant 提供了包含区域中每个专区的 IP 地址的循环法标准域名 (FQDN)。 发生故障时，许多 SIP 中继提供者会自动重试 FQDN 中的每个 IP。 要支持灾难恢复，服务提供者可能需要配置两个单独的 SIP 干线 (每个区域一个)，并且仅当单个区域中的所有区域都失败时，才会将呼叫切换到备份区域。 请务必将 SIP 中继提供者的 SIP INVITE 故障超时设置得足够低，以避免发生故障转移时出现长时间的呼叫设置等待时间。

部分中断

第二类故障是区域内的部分服务中断。 部分中断很难检测和管理，因为在一个区域内可能会发生大量服务故障变化。 有时，小问题会影响调用的性能特征，但不会导致调用失败。

对于最终导致呼叫失败的问题，您的助手可以通过两种方法来处理呼叫。 首先是接受呼叫，然后将其传输到配置的缺省 SIP URI。 您可以在电话集成中配置此设置，也可用于中途呼叫故障。 缺省传输目标 SIP URI 是在电话集成配置的“高级”选项卡上的 呼叫失败时 SIP 目标 字段中定义的。

如果在呼叫设置期间检测到中断，而不是将呼叫转移到实时代理，那么还可以将电话集成配置为使用 SIP 500 (服务不可用) 消息响应 SIP INVITE。 然后，可以使用 SIP 500 将呼叫重定向到另一个区域，或者如果接收到许多 SIP 500s，那么可以将呼叫重定向到另一个区域。 使用 SIP 500 INVITE 错误是向上游 SIP 中继提供者发出故障信号的更好方法，因为它为提供者提供了重新路由呼叫的方法。 对于低呼叫量方案，仅使用缺省传输目标来处理呼叫失败是可以接受的，但是当助手处理更大的呼叫量时，可能会导致大量呼叫定向到客户联系中心。 要对特定实例启用此 500 错误响应功能，需要向 IBM发出请求。

您应该针对完全服务中断和部分服务中断进行规划。 最好先规划区域之间的手动故障转移，然后再启用自动化。 您需要两个区域中 watsonx Assistant 的完整副本，包括所有定制语音模型训练。 启用自动化后，最好从检测到完全区域中断时的被动备份区域的检测和故障转移策略入手。 实施后，制定应对部分中断的策略，该策略应涵盖电话集成部署可能发生的大部分故障情况。

Web 聊天

Monitoring

Web 聊天提供了 onError 侦听功能，允许主机页面检测特定类型的中断错误，特别是 INITIAL_CONFIG，OPEN_CONFIG 和 MESSAGE_COMMUNICATION 错误。

有关更多信息，请参阅 侦听错误。

故障转移

处理 Web 聊天的故障转移很简单，假定您在另一个区域中设置了额外的 Web 聊天集成。 需要手动触发故障转移时，请进行以下更改:

  • 需要更改或更新包含集成标识，区域，服务实例标识和预订标识 (如果适用) 的嵌入脚本，以将这些标识用于新的集成和区域。
  • 如果要使用 Salesforce 或 ZenDesk 集成来连接到人员代理程序，请更新这些系统中的配置，以确保它们可以与正确的集成进行通信。 遵循 Web 聊天配置中 实时代理程序 选项卡上的指示信息来设置这些系统。 仅当获取代理程序的对话历史记录时才需要此功能。
  • 如果您启用 Web 聊天安全性并且正在使用加密有效内容，那么用于加密的 IBM提供的公用密钥可能因区域而异。 如果是这样，您需要更新生成 JSON Web 令牌 (JWT) 的系统以使用正确的密钥。

您可以设置 Web 聊天的主动/主动配置，方法是在嵌入的脚本中使用不同的集成标识，并确保用户将 Web 聊天集成设置为“粘性”。 否则，如果用户故障转移到其他集成，那么对话历史记录可能会丢失。

个 API

Monitoring

捕获并监视 /message 调用的响应代码。 应该捕获并聚集实时 /message 流量的响应代码。

理想情况下，将响应代码统计信息保存在外部持久性存储中。 此共享存储器可以聚集来自应用程序的所有已部署实例的响应代码结果，并在确定是否应触发故障转移时提供最大的精确度。

或者，可以在内存中针对应用程序实例聚集和评估响应代码。 由于只有一小部分流量有助于故障转移决策，因此这可能会影响对故障转移决策执行的频率。

使用任一聚集方法，超过定义的阈值可能会触发故障转移。 确定故障转移的常见方法包括:

  • 基于百分比: 超过 X% 的请求返回 non-200 响应代码
  • 基于连续的 :X 调用在行中返回 non-200 响应代码
  • 基于限制 :X 调用在时间范围内返回 non-200 响应

要避免在区域之间进行不必要的故障转移，请确保在调用 /message 端点时存在强大的重试机制。

v1 和 v2 无状态 API 的故障转移

对于成功的故障转移:

  • 应跨区域同步训练数据更改。 避免在很大的时间窗口 (例如，天) 内推送延迟的更改，以降低由 watsonx Assistant 在要更新的区域之间部署的算法更改的风险。
  • 应该对跨区域的服务实例使用相同的 IBM Cloud 帐户，以维护服务的单一整体帐单。
  • 客户机应用程序应支持:
    • IBM® watsonx™ Assistant API 主机名
    • 服务实例凭证
    • v1: 工作空间标识
    • v2: assistant_id

虽然这不会影响调用 /message 的运行时流，但如果您使用的是使用 IBM Identity and Access Management (IAM) 的细颗粒度访问控制，请确保跨区域同步 IAM 策略。  IAM 是一项全局服务，但 watsonx Assistant 访问控制所使用的定制资源 (助手和技能) 意味着具有特定资源的每个区域都需要特定策略。

对于 主动/被动 拓扑，可以使用某种形式的 断路模式。 除非检测到错误，否则将专门使用区域中的单个服务实例。 此时，系统可以通过更新相关故障转移元数据来响应，以将流量路由到其他区域中的服务实例。 发生故障转移时，您可以决定继续使用新区域作为活动实例，或者如果要在初始区域稳定时继续使用该区域。

对于 主动/主动 拓扑，可以使用某种形式的负载均衡，其中不同区域中的两个或更多服务实例始终接收一定百分比的流量。 需要建立额外的逻辑来确定何时将区域从旋转中拉出。 此监视逻辑可能使用类似于主动/被动配置的 回路中断模式，或者依赖于用于确定区域运行状况的单独专用监视框架。 与主动/被动类似，还需要考虑确定何时重新插入一个区域。

v2 有状态 API 的故障转移

v2 有状态 API 的故障转移类似于无状态 API，需要考虑以下详细信息:

  • 对话状态由 watsonx Assistant 持久存储在与特定区域绑定的数据库中。 因此，有状态 v2 /message 的故障转移可能更具破坏性。
  • 对于 主动/被动 拓扑，您应该假定所有正在进行的对话都已结束。
  • 对于 主动/主动 拓扑，鉴于 v2 有状态 /message 体系结构的区域锁定持久性约束，对话 (会话) 的所有轮次 (/message API 调用) 都应该发生在同一区域中。