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

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

Фон:

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

Мы изучили следующее:

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

3 ответа

Решение

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

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

По сути, кажется, что вы в большей степени зависите от оперативной группы центра обработки данных, чтобы быстро переключаться на субрегион в случае полной потери центра обработки данных.

Источник

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

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

Пространства имен ACS 2.0

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

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

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

НТН

Источник

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

  1. Вы настроили ACS1 и ACS2, где ACS2 является резервной копией. Оба ACS используют настроенное для использования одно и то же приложение проверяющей стороны с одинаковыми областью и обратным URL.

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

    2.1 Возможно, что ошибка была с ACS 2.2 Возможно, конечная точка ACS даже не была найдена

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

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

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

Источник
Другие вопросы по тегам