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

背景：

我们使用ACS来转换由定制开发的STS通过WS-Trust协议提供的SAML令牌. ACS用于在我们的STS与由第三方开发的许多依赖方之间建立信任.依赖方当前配置为使用其DNS URL连接到特定ACS实例.

我们调查了以下内容：

>使用DNS CName条目来屏蔽ACS URL – 不起作用,因为新DNS与实例上的SSL证书不匹配,我们无法控制SSL证书.
>使用ACS前面的代理将请求路由到它 – 不起作用,因为消息中的To address和Realm与acs名称空间不匹配.
> Traffic Manager因为1和2都不起作用,因为它目前不允许您直接加载到不以.cloudapp.net结尾的地址.

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

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

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