4

ACS インスタンスにフェールオーバーを提供する方法を探しています。そのため、1 つのデータ センターがオフラインになると、ACS を介した認証が自動的に別のデータ センターにフェールオーバーします。

バックグラウンド：

ACS を使用して、WS-Trust プロトコルを介してカスタム開発された STS によって提供される SAML トークンを変換します。ACS は、当社の STS と、サード パーティによって開発された多くの依存者との間の信頼を仲介するために使用されます。証明書利用者は現在、DNS URL を使用して特定の ACS インスタンスに接続するように設定されています。

私たちは次のことを調べました。

  1. DNS CName エントリを使用して ACS url をマスクする - 新しい DNS がインスタンスの SSL 証明書と一致せず、SSL 証明書を制御できないため、機能しません。
  2. ACS の前でプロキシを使用して要求をルーティングする - メッセージの To アドレスとレルムが acs 名前空間と一致しないため、機能しません。
  3. 1 と 2 の両方が原因で、Traffic Manager は機能しません。また、現時点では、.cloudapp.net で終わらないアドレスに直接負荷をかけることができないためです。
4

3 に答える 3

1

まず第一に、Azure には ACS バックアップ ソリューションが存在しないため、開発者とユーザーは、思いつく限り最高のものを自由に作成できます。アプリケーションがある ACS から別の ACS にロールオーバーするためのフェールオーバー シナリオを作成する場合の私の理解に基づいて、以下のように証明書利用者アプリケーション (Web サイト) で実行できます。

  1. ACS1 と ACS2 が構成されており、ACS2 はバックアップです。両方の ACS は、同一のレルムとリターン URL を持つ同じ依拠当事者アプリケーションを使用するように設定された を使用します。

  2. Relying Party アプリケーションで ACS へのログインに失敗した場合、ACS は JSON エンコードされた HTTP URL パラメータ エラーの詳細を Relying Party アプリケーションに提供します。

    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 に答える
1

これが役立つかどうかはわかりませんが、ACS の DC がクラッシュした場合に、カスタム オンプレミス ソリューションを実行できる可能性があります。サービス バス ダッシュボードへの RSS ポーリングと共に Windows Azure コマンドレットを使用すると、うまくいく場合があります。

SB 2.0 名前空間のこのトピックに関する MSFT からのガイダンスについては、以下を参照してください...

ACS 2.0 ネームスペース

ACS 2.0 は、すべての名前空間のバックアップを 1 日に 1 回作成し、安全なオフサイトの場所に保存します。ACS の運用スタッフが、ACS の地域データ センターの 1 つで回復不能なデータ損失が発生したと判断した場合、ACS は最新のバックアップを復元することにより、顧客のサブスクリプションの回復を試みる場合があります。バックアップの頻度により、最大 24 時間のデータ損失が発生する可能性があります。

データ損失の可能性を懸念している ACS 2.0 のお客様は、Microsoft がホストする Codeplex オープン ソース リポジトリから入手できる一連の Windows Azure PowerShell コマンドレットを確認することをお勧めします。これらのスクリプトにより、管理者は名前空間を管理し、すべての関連データをインポートおよび抽出できます。これらのスクリプトを使用することで、ACS のお客様は、ACS が現在提供しているよりも高いレベルのデータ整合性を実現するカスタム バックアップおよび復元ソリューションを開発できます。

通知 災害が発生した場合、Windows Azure サービス ダッシュボードに情報が掲載され、世界中のすべての Windows Azure サービスの現在のステータスが示されます。ダッシュボードは、災害に関する情報で定期的に更新されます。サービスの中断に関する通知を受け取りたい場合は、サービス ダッシュボードでサービスの RSS フィードを購読できます。さらに、Windows Azure Web ページのサポート オプションにアクセスしてカスタマー サポートに連絡し、指示に従ってサービスのテクニカル サポートを受けることができます。

HTH

于 2012-06-23T02:10:35.837 に答える
0

ここに現実的で誰にでもできる解決策はないと思います。前述のように、他のデータセンターに追加の名前空間を作成し、RP 構成と変換ルールのバックアップを取ることができます。回復するには、バックアップを新しい名前空間に復元した後、新しい名前空間を使用するようにクライアントを再構成する必要があります。これは、いくつかのシナリオ (Google と Yahoo! の統合など) で機能します。Active Directory 統合でも機能する可能性があります (と思います)。ただし、RP を制御しないと非常に問題になります。

別の、しかしこのアプローチのブロックの問題は (少なくとも私たちにとって)、Windows Live の名前識別子要求の場合には機能しないことです。ユーザーの名前空間ごとに異なるものを取得します。したがって、すべての設定を別のデータセンターに復元したとしても (そして RP も制御します!)、Windows Live ユーザーは名前識別子が新しい名前空間と一致しなくなるため、正しくログインできなくなります。グーグルとヤフー！安定したクレーム (電子メールなど) を使用できるため、この問題は発生しません。

基本的に、データセンターが完全に失われた場合にサブリージョンに迅速にフェイルオーバーするために、ほとんどの場合、データセンター運用チームに翻弄されているようです。

于 2012-06-28T16:07:46.723 に答える