Crowd Data Center の FAQ

Crowd Data Center と Crowd Server の詳細な比較については、「Crowd Server と Data Center の機能の比較」を参照してください。

移行プロセスの詳細な説明については、Crowd ドキュメントを参照してください。

ホット フェイルオーバーを実現するには、最低 2 台のクラスタ ノードを用意することをおすすめします。ノードを追加すると、ノードで不具合が発生した場合の可用性が向上します。また、一部の操作でのスループットが向上する可能性もあります (特に、Crowd がアプリケーションの認証を処理する場合の認証リクエスト)。

Crowd Data Center は完全なアクティブ - アクティブなクラスタリングを提供しているため、ノードがダウンした場合のフェイルオーバーは数秒で実施できます。すべてのデータの一貫したレプリケートや、トラフィックのリダイレクトを DNS で伝播するために、"コールド スタンバイ"の起動を待つ必要はありません。これらはすべて、Crowd Data Center とロード バランサによって自動的およびシームレスに処理され、システム管理者による介入は不要です。

Crowd Data Center では、ユーザー セッションはデータベース内に保存され、ユーザー セッションに関連するすべての操作をクラスタ内のすべてのノードが処理できます。ノードが失敗した場合、ロード バランサがトラフィックを別のノードに転送するため、ユーザーは機能が失われたことに気付くことはありません。これは、Crowd の Web インターフェイスのセッションにも同様に適用されます (新しいアプリケーションの構成などの複数の手順が必要な操作を実行していた場合、そのプロセスの再起動が必要になる場合があります)。

以下をサポートしているものであれば、お好みのロード バランサを選択できます。

• cookie ベースのセッション アフィニティ ("スティッキー セッション")
• ヘルスチェック URL に基づいてノードの可用性を判断する
• HTTPS 暗号化および復号化をオフロードする SSL 終端

ロード バランサの選定に特定の要件がない場合、「Crowd Data Center のロード バランサの構成例」ページで Apache および HAProxy の手順を確認できます。

いいえ、Crowd Data Center では、同じクラスタ内で混合したバージョンのクラスタ ノードを持つことはできません。一度に 1 つのノードをアップグレードする場合でも、古いバージョンと新しいバージョンの間に常にダウンタイム期間が必要です。

ただし、適切に管理すれば、Crowd Data Center インスタンスのアップグレードのダウンタイムを、同等の Crowd Server インスタンスと同じ程度にしたり、それよりも大幅に削減したりすることができます。Crowd Data Center では、ノードを 1 つずつオフラインにしてアップグレードを実行し、古いバージョンの最後のノードのシャットダウン時刻と新しいバージョンの最初のノードの起動時刻の間の時間のみをダウンタイム期間にすることができます。Crowd Server インスタンスの場合、これはまったく同一のバックアップ サーバーをプロビジョニングした場合のみ可能です。