我们正在寻找一种为ACS实例提供故障转移的方法，因此，如果一个数据中心脱机，则通过ACS进行身份验证会自动转移到另一个数据中心。如何在数据中心故障时故障转移Azure ACS
背景：
我们使用ACS改造由通过WS-Trust协议定制开发的STS提供的SAML令牌。 ACS用于撮合我们的STS和由第三方开发的一些依赖方之间的信任。信任方当前被配置为使用其DNS URL连接到特定的ACS实例。
我们已经调查了以下内容：
我不认为这里有一个现实和万无一失的解决方案。如上所述，您可以在其他数据中心中创建其他名称空间，并备份您的RP配置和转换规则。要恢复，您的客户需要重新配置他们的应用程序，以便在将备份还原到新的名称空间后使用新的名称空间。这可以在一些情况下工作（如谷歌和雅虎整合）。它甚至可以工作（我认为）用于Active Directory集成。然而，如果你不控制RP，这是非常有问题的。
这种方法的另一个阻塞问题（至少对我们来说）是它在Windows Live名称标识符声明中不起作用。我们为每个用户命名空间获得不同的名称空间。因此，即使我们恢复了其他数据中心的所有设置（并且我们也控制了RP！），我们的Windows Live用户将无法正确登录，因为他们的名称标识符将不再与新的名称空间相匹配。 Google和Yahoo!不会有这个问题，因为他们可以使用稳定的声明（如电子邮件）。
基本上，您看到的主要是数据中心操作团队的摆布，以便在数据中心丢失的情况下快速切换到次区域。
不知道这是否有帮助，但是您可能能够在ACS发生DC故障时执行一些定制的本地解决方案。将Windows Azure Cmdlet与RSS轮询一起使用到Service Bus仪表板可能会起作用。
见下面从MSFT指导有关这个主题的SB 2.0命名空间...
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
首先，没有ACS的备份解决方案存在于天青所以开发者和用户都开放创造最好的，他们能想出什么。根据我的理解，如果你想从一个ACS到另一个ACS，可以在您的信赖方应用程序（网站）完成了为应用程序创建一个故障切换场景的角色如下：
在您的Relying Party应用程序中，当登录到ACS失败时，ACS向依赖项提供JSON编码的HTTP URL参数错误详细信息第三方应用
2.1这是可能的错误是withing 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的开发。 –
如果您的ACS服务在此时出现故障，老实说，您可以在代码中执行很多操作。 – AvkashChauhan
关键问题不在于如何复制ACS功能，因为我们可以通过在2个数据中心中配置相同的名称空间来实现这一点。我们正试图找出如何更改依赖方指向的数据中心，而无需更改依赖方自己的代码。 –