マルチデータセンターのアーキテクチャ
マルチデータセンターAccess Gatewayアーキテクチャは、高実績のフォ－ルトトレランスマルチデータセンター環境にAccess Gatewayをデプロイする際に必要なコンポーネントセットを示します。
通常このアーキテクチャでは、アクティブ-アクティブまたはアクティブ-ウォームスタンドバイデータセンターを必要としますが、このアーキテクチャでは複数のレベルでフェイルオーバーを提供できます。ここに示されるように、このアーキテクチャでは、各データセンターにフォ－ルトトレランスビルトインが組み込まれたアクティブ-アクティブ構成を表しています。このアーキテクチャは、アプリケーションが両方のデータセンターで同時に動作するように構成された高可用性アプリケーション向けです。
このアーキテクチャは、以下の要件を満たすよう設計されています。
- 外部インターネットからアクセスがあるアプリケーションセットに安全なアクセスを提供しますが、内部でのみアクセス可能なアプリケーションにも同様のアプローチを行うことができます。
- ロケーションまたはその他の基準で選択されたデータセンターによってユーザーアクセスをサポートすることによって、アクセス率を向上させます。
- 各データセンター内およびデータセンター全体の両方にフォ－ルトトレランスなロードバランサーを含め、高レベルなパフォーマンスを提供します（DC内で単一コンポーネントが1つでも損失した場合やDC全体が使用できない場合でも、アプリへのアクセスを維持します）
- 各データセンター内に高レベルなフォ－ルトトレランスを提供します：
- ロードバランサーレベル - Access Gatewayレベルおよび保護対象アプリケーションレベルで、データセンターごとに１つのローダーバランサー
- 単一管理者ノードで、データセンターごとにセグメント化されたAccess Gatewayワーカー
- データセンターレベルで複製された保護対象Webリソース
| 利点 | 欠点 |
|---|---|
|
|
アーキテクチャ
コンポーネント
| ロケーション | コンポーネント | 説明 |
|---|---|---|
| 外部インターネット | Webクライアント |
従来のクライアントブラウザで、[appN|consumer-app1].example.com URLとして認識されるAccess Gatewayにアクセスします。 |
| appN.example.com
URLは非表示 |
外部WebクライアントがAccess Gatewayによって保護対象アプリケーションの1つにアクセスするために入力するアプリケーションの1つを表すURL。通常、この性質のすべてのURLは、Access Gatewayインスタンスによってサービスされ、解決されます。 | |
| Okta org |
Okta orgは、アイデンティティサービスを提供しています。 |
|
| Okta org Universal Directory |
Okta orgでホスティングされるOkta Universal Directoryには、その他のLDAPまたはActive Directory実装の外部のユーザーが含まれます。通常、これにはその他のカスタマーアカウントやパートナーアカウントなどが含まれます。 |
|
|
ファイアウォール |
外部インターネットからDMZ |
外部インターネットとDMZホスティングAccess Gatewayの間の従来のファイアウォール。 |
| DMZ |
Access Gateway以前のロードバランサー |
DMZベースAccess Gatewayクラスターのロードバランサー。 |
| Access Gatewayワーカー | 両方のデータセンターに分配されるが、管理インスタンスを共有するAccess Gatewayインスタンス。 ワーカーはDNSを使用して、適切な保護対象Webリソースを選択します。 |
|
|
ファイアウォール |
DMZから内部ファイアウォール |
DMZと内部ネットワーク間の従来のファイアウォール。 |
| 内部ネットワーク | Access Gateway管理者 | 構成、構成バックアップ、ログ転送および類似のアクティビティを扱うデータセンター内のAccess Gateway管理者ノード。 内部ネットワーク内の管理者によるアクセス。 |
|
内部前Access Gatewayロードバランサー |
Access Gatewayと保護対象Webリソース間のロードバランサー。 |
|
|
保護済みのアプリケーション |
保護対象Webリソースのセットで、protd-N.internal-example.com URLを使用してアクセスされます。 |
その他の考慮事項
DNSラウンドロビンなどの地理的またはその他の負荷分散技術が、セッショントラフィックをさまざまなデータセンターにルーティングするためにデプロイされています。このデータセンターのルーティングは、「スティッキー」（セッションアフィィニティ）に行う必要があり、セッションの続く限りまたはデータセンターにアクセスできなくなるまでユーザーを同じデータセンターにルーティングする必要があります。
SSLは、ロードバランサーまたはAccess Gatewayサーバーそのもので終了することできます。SSLをロードバランサーで終了する場合、LBからOAGへの通信はSSLを経由する必要がありますが、Access Gatewayでは自己署名付き証明書が使用される場合があります。
ほとんどのアーキテクチャは、ログイベントを外部のsyslogコンポーネントに転送します。Oktaは、すべてのAccess Gateway環境にログサーバーを設定することを強く推奨します。詳しくは、「ログフォワーダーを構成する」を参照してください。