azure - 如果数据中心出现故障，如何故障转移 Azure ACS

我们正在寻找一种为 ACS 实例提供故障转移的方法，因此如果一个数据中心脱机，通过 ACS 的身份验证会自动故障转移到另一个数据中心。

背景:

我们使用 ACS 来转换由定制开发的 STS 通过 WS-Trust 协议(protocol)提供的 SAML token 。 ACS 用于在我们的 STS 和由 3rd 方开发的多个依赖方之间建立信任关系。依赖方当前配置为使用其 DNS URL 连接到特定的 ACS 实例。

我们研究了以下内容:

使用 DNS CName 条目来屏蔽 ACS url - 不起作用，因为新的 DNS 将与实例上的 SSL 证书不匹配，并且我们无法控制 SSL 证书。

在 ACS 前面使用代理将请求路由到它 - 不起作用，因为消息中的 To address 和 Realm 与 acs 命名空间不匹配。

流量管理器由于 1 和 2 而不起作用，并且因为它目前不允许您直接加载到不以 .cloudapp.net 结尾的地址。

最佳答案

我不认为这里有一个现实和万无一失的解决方案。如前所述，您可以在其他数据中心创建额外的命名空间，并备份您的 RP 配置和转换规则。要恢复，您的客户需要在您将备份恢复到新命名空间后重新配置他们的应用程序以使用新命名空间。这可以在某些情况下工作(例如 Google 和 Yahoo! 集成)。它甚至可以(我认为)用于 Active Directory 集成。但是，如果您不控制 RP，这是非常有问题的。

这种方法的一个不同但也存在阻塞问题(至少对我们而言)是它在 Windows Live 名称标识符声明的情况下不起作用。我们为用户的每个命名空间获得一个不同的命名空间。因此，即使我们在另一个数据中心恢复了所有设置(并且我们也控制了 RP!)，我们的 Windows Live 用户将无法正确登录，因为他们的名称标识符将不再与新命名空间匹配。谷歌和雅虎!不会有这个问题，因为他们可以使用稳定的声明(如电子邮件)。

基本上，您似乎主要受数据中心运营团队的支配，以便在数据中心完全丢失的情况下快速故障转移到子区域。

关于azure - 如果数据中心出现故障，如何故障转移 Azure ACS，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/11163647/