Как отказоустойчивый Azure ACS, если центр обработки данных опускается

Question

Мы ищем способ обеспечения отказоустойчивости для экземпляров ACS, поэтому, если один центр обработки данных отключен, аутентификация через ACS автоматически перейдет в другой центр обработки данных.

фон:

Мы используем ACS для преобразования SAML токены, которые предоставляются с помощью настраиваемой Развитой STS через протокол WS-Trust. ACS используется для брокерского доверия между нашей STS и рядом полагающихся сторон, которые разрабатываются третьими сторонами. В настоящее время полагающиеся стороны настроены на подключение к конкретному экземпляру ACS с использованием его URL-адреса DNS.

Мы смотрели на следующие:

1. Использование записи DNS CNAME для маскировки ACS URL - не работает, потому что новый DNS не будет соответствовать SSL сертификат на экземпляре, и мы можем» t контролирует сертификат SSL.
2. Использование прокси-сервера перед ACS для маршрутизации запросов к нему - не работает, поскольку адрес To и Realm в сообщениях не соответствуют пространству имен acs.
3. Диспетчер трафика не работает из-за как 1, так и 2, и потому что в настоящее время он не позволит вам напрямую загружать адрес, который не заканчивается на .cloudapp.net.

Answer 1

Я не думаю, что здесь есть реалистичное и надежное решение. Как уже отмечалось, вы можете создавать дополнительные пространства имен в других центрах обработки данных и делать резервные копии своих конфигураций и правил преобразования RP. Для восстановления ваши клиенты должны будут перенастроить свои приложения для использования нового пространства имен после восстановления резервной копии в новом пространстве имен. Это может работать в некоторых сценариях (например, интеграции Google и Yahoo!). Он может даже работать (я думаю) для интеграции Active Directory. Это очень проблематично, если вы не контролируете RP.

Другая проблема с блокировкой с этим подходом (по крайней мере для нас) заключается в том, что она не будет работать в случае имен идентификаторов имен Windows Live. Для наших пользователей мы используем другое пространство имен. Таким образом, даже если мы восстановили все наши настройки в другом центре обработки данных (и мы также контролируем RP!), Наши пользователи Windows Live не смогут правильно войти в систему, потому что их идентификаторы имен больше не будут соответствовать новому пространству имен. Google и Yahoo! не будет иметь этой проблемы, поскольку они могут использовать устойчивое требование (например, электронную почту).

В основном, похоже, что вы, главным образом, во власти команды операций центров обработки данных, быстро переходите на подрегион в случае полной потери центра обработки данных.

Answer 2

Не уверен, что это поможет, но вы можете выполнить какое-то обычное локальное решение в случае сбоя DC для ACS. Использование Командлетов Windows Azure вместе с опросом RSS на панели служебной шины может работать.

смотрите ниже по руководству от MSFT по данной теме для SB 2.0 пространств имен ...

ACS 2,0 Namespaces

ACS 2.0 требуется резервное копирование всех пространств имен один раз в день и сохраняет их в безопасном вне офиса местоположение. Когда персонал службы ACS определяет, что была потеря неустранимой информации на одном региональных центров обработки данных ACS, ACS может попытаться восстановить подписки клиентов на , восстанавливая самую последнюю резервную копию. Из-за частоты резервного копирования потеря данных до 24 часов может произойти .

ACS 2.0 клиенты обеспокоены потенциалом потери данных рекомендуется рассмотреть набор Windows Azure PowerShell командлетов доступный через Microsoft прошла Codeplex Open Source хранилище. Эти сценарии позволяют администраторам управлять своими пространствами имен и импортировать и извлекать все соответствующие данные. Благодаря использованию этих сценариев клиенты ACS имеют возможность создавать собственные решения для резервного копирования и восстановления для более высокого уровня согласованности данных, чем , предлагаемые в настоящее время ACS.

Уведомление В случае аварии, информация будет размещена на панели управления Windows Azure Service , описывающий текущее состояние всех служб Windows Azure во всем мире. Панель приборов будет регулярно обновляться с информацией о катастрофе. Если вы хотите получать уведомления об ошибках для любых служб, вы можете подписаться на RSS-канал службы на Сервисной панели .Кроме того, вы можете обратиться в службу поддержки, посетив параметры поддержки для веб-страницы Windows Azure и следуйте инструкциям, чтобы получить техническую поддержку для ваших услуг.

НТН

Answer 3

Прежде всего нет решения для резервного копирования ACS существует в Azure, так что разработчики и пользователи открыты для создания того, что в лучшем случае они могли придумать. Основываясь на моем понимании, если вы хотите создать сценарий отказоустойчивости для приложения к роли от одного ОКСА к другому ОКСУ, что может быть сделано в вашей полагающейся приложении партии (веб-сайте), как показано ниже:

1. У вас есть ACS1 и ACS2, где ACS2 является резервной. Оба ACS используют сконфигурированные для использования одного и того же приложения Relying Party с идентичным URL-адресом Realm и Return

2. В приложении вашей доверенной стороны, когда при входе в систему ACS не удается войти в систему, ACS предоставляет детали ошибки URL-адреса HTTP-JSON для использования применение партия

   2,1 Вполне возможно, что ошибка была жгутов ACS 2.2 возможно конечная точка ACS даже не нашел

3. в обоих случаях вы можете обрабатывать ошибки в коде и создать политику Retry, чтобы попытаться ACS2. Вы можете добавить код, чтобы попробовать, когда идти ACS2, и когда продолжать попытки ACS1 зависеть от того, как вы хотите.

Если вы в конечном итоге с 2 ACS конечную точку, просто пытаются держать их идентичными, так что вы не получите тот же результат, независимо от того, какой из них на самом деле проверить подлинность запроса приложения RP.

Если вы хотите сделать резервную копию ACS на уровне управления, взгляните на Windows Azure AppFabric Access Control Service (ACS) – Backup and Restore Resources, может потребоваться, чтобы вы были доступны в случае сбоя ACS, иначе вы можете автоматизировать его в своем приложении RP (большая работа).