如果数据中心出现故障，如何对Azure ACS进行故障转移

Question

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

背景

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

我们调查了以下内容：

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

Answer 1

不确定这是否有帮助，但您可以在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

Answer 2

首先，Azure中不存在ACS备份解决方案，因此开发人员和用户可以创建最好的解决方案。根据我的理解，如果您想为应用程序创建一个故障转移场景，从一个ACS到另一个ACS的角色，可以在您的依赖方应用程序（网站）中完成，如下所示：

1. 您配置ACS1和ACS2，其中ACS2是备份。两个ACS都使用配置为使用具有相同领域和返回URL的相同依赖方应用程序

2. 在您的依赖方应用程序中，当无法登录ACS时，ACS会向依赖方应用程序提供JSON编码的HTTP URL参数错误详细信息

   2.1错误可能与ACS有关 2.2甚至找不到ACS端点

3. 在这两种情况下，您都可以处理代码中的错误并创建重试策略以尝试ACS2。您可以添加代码以尝试何时进入ACS2以及何时继续尝试ACS1取决于您的需求。

如果您最终拥有2个ACS端点，只需尝试保持它们相同，这样无论哪个实际验证RP应用程序请求，您都将获得完全相同的结果。

如果要在管理级别备份ACS，请查看Windows Azure AppFabric Access Control Service (ACS) – Backup and Restore Resources，否则可能需要您在ACS发生故障时可用，否则，您可能希望在RP应用程序中自动执行它（大工作） 。

Answer 3

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

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

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