4

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

背景:

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

我们研究了以下内容:

  1. 使用 DNS CName 条目来屏蔽 ACS url - 不起作用,因为新 DNS 与实例上的 SSL 证书不匹配,我们无法控制 SSL 证书。
  2. 在 ACS 前面使用代理将请求路由到它 - 不起作用,因为消息中的 To address 和 Realm 与 acs 命名空间不匹配。
  3. 由于 1 和 2,流量管理器不起作用,并且因为它当前不允许您将负载直接加载到不以 .cloudapp.net 结尾的地址。
4

3 回答 3

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 开源存储库获得的 Windows Azure PowerShell Cmdlet。这些脚本允许管理员管理他们的命名空间并导入和提取所有相关数据。通过使用这些脚本,ACS 客户能够开发自定义备份和恢复解决方案,以实现比 ACS 目前提供的更高级别的数据一致性。

通知 如果发生灾难,信息将发布在 Windows Azure 服务仪表板上,描述全球所有 Windows Azure 服务的当前状态。仪表板将定期更新有关灾难的信息。如果您想接收任何服务中断的通知,您可以在服务仪表板上订阅服务的 RSS 源。此外,您可以通过访问 Windows Azure 网页的支持选项联系客户支持,并按照说明为您的服务获取技术支持。

高温高压

于 2012-06-23T02:10:35.837 回答
1

首先,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 应用程序(大工作)。

于 2012-06-23T02:14:46.770 回答
0

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

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

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

于 2012-06-28T16:07:46.723 回答