我们正在寻找一种为 ACS 实例提供故障转移的方法，因此如果一个数据中心脱机，通过 ACS 的身份验证会自动故障转移到另一个数据中心。
背景：
我们使用 ACS 转换由定制开发的 STS 通过 WS-Trust 协议提供的 SAML 令牌。 ACS 用于在我们的 STS 和由 3rd 方开发的许多依赖方之间建立信任。依赖方当前配置为使用其 DNS URL 连接到特定 ACS 实例。
我们研究了以下内容：
【问题讨论】：
标签： azure failover acs ws-trust
不确定这是否有帮助，但您也许可以在 ACS 发生 DC 崩溃时执行一些自定义的本地解决方案。使用 Windows Azure Cmdlet 以及对服务总线仪表板的 RSS 轮询可能会起作用。
请参阅下面有关 SB 2.0 命名空间主题的 MSFT 指南...
ACS 2.0 命名空间
ACS 2.0 每天对所有命名空间进行一次备份，并将它们存储在安全的异地 地点。当 ACS 操作人员确定存在不可恢复的数据丢失时 在 ACS 的区域数据中心中，ACS 可能会尝试通过以下方式恢复客户的订阅 恢复最近的备份。由于备份数据丢失长达 24 小时的频率可能 发生。
鼓励担心数据丢失可能性的 ACS 2.0 客户查看一组 可通过 Microsoft 托管的 Codeplex Open 获得 Windows Azure PowerShell Cmdlet 源存储库。这些脚本允许管理员管理他们的命名空间并导入 并提取所有相关数据。通过使用这些脚本，ACS 客户有能力 开发自定义备份和恢复解决方案，以实现更高级别的数据一致性 目前由 ACS 提供。
通知 如果发生灾难，信息将发布在 Windows Azure 服务仪表板上 描述全球所有 Windows Azure 服务的当前状态。仪表板将是 定期更新有关灾难的信息。如果您想收到通知 任何服务中断，您可以在服务上订阅服务的 RSS 提要 仪表板。此外，您可以通过访问支持选项联系客户支持 Windows Azure 网页并按照说明为您的服务获取技术支持。
HTH
【讨论】：
首先，Azure 中不存在 ACS 备份解决方案，因此开发人员和用户愿意创建他们可以提出的最佳方案。根据我的理解，如果您想为您的应用程序创建一个故障转移方案以从一个 ACS 转移到另一个 ACS，可以在您的依赖方应用程序（网站）中完成，如下所示：
在您的依赖方应用程序中，当登录 ACS 失败时，ACS 会向依赖方应用程序提供 JSON 编码的 HTTP URL 参数错误详细信息
2.1 ACS 可能出现错误 2.2 有可能甚至没有找到 ACS 端点
在这两种情况下，您都可以处理代码中的错误并创建重试策略来尝试 ACS2。您可以添加代码以尝试何时使用 ACS2 以及何时继续尝试 ACS1 取决于您想要的方式。
如果您最终拥有 2 个 ACS 端点，请尽量保持它们相同，这样无论哪一个实际对 RP 应用程序请求进行身份验证，您都会得到完全相同的结果。
如果您想在管理级别备份 ACS，请查看 Windows Azure AppFabric Access Control Service (ACS) – Backup and Restore Resources，它可能需要您在 ACS 故障时可用，否则，您可能希望在您的 RP 应用程序中自动化它（大工作）。
【讨论】：
我认为这里没有一个现实且万无一失的解决方案。如前所述，您可以在其他数据中心创建额外的命名空间并备份您的 RP 配置和转换规则。要恢复，您的客户需要在将备份恢复到新命名空间后重新配置其应用程序以使用新命名空间。这可以在某些情况下工作（如 Google 和 Yahoo! 集成）。它甚至可以（我认为）用于 Active Directory 集成。但是如果不控制RP就很成问题了。
这种方法的一个不同但阻塞的问题（至少对我们而言）是它在 Windows Live 名称标识符声明的情况下不起作用。我们为用户的每个命名空间获得一个不同的命名空间。因此，即使我们在另一个数据中心恢复了所有设置（并且我们也控制了 RP！），我们的 Windows Live 用户将无法正确登录，因为他们的名称标识符将不再与新命名空间匹配。谷歌和雅虎！不会有这个问题，因为他们可以使用稳定的声明（如电子邮件）。
基本上，在数据中心完全丢失的情况下，您似乎主要受数据中心运营团队的支配，以便快速故障转移到子区域。
【讨论】：