Data Center 移行ガイド
No organization is the same and neither is your migration journey. The key to any good migration is planning.
ガイド 4: クラスタ アーキテクチャでデプロイする
開始・計画ガイドをご覧いただいたので、クラスタ環境での Data Center のデプロイを開始していただけます。
クラスタに必要なインフラストラクチャを確保する
クラスタでの Data Center のデプロイには、以下のコンポーネントが有用です。
- データベース
- ロードバランサー
- アプリケーション ノード
- ファイル システム
- ElasticSearch ノード (Bitbucket)
ロードバランサー
ロード バランサーは、クラスタでデプロイする場合にユーザーの要求が最初に到達する部分です。要求がロード バランサーに到達すると、ロード バランサーは各要求をアプリケーション ノードに分散します。ハードウェアまたはソフトウェア ベースのロード バランサーを使用できます。ソフトウェアとハードウェアのどちらのソリューションでも、高速 LAN 接続を使用してロード バランサーをアプリケーション クラスタに接続し、広帯域幅と低レイテンシを確保する必要があります。すべてのソフトウェア ロード バランサーは専用のマシンで実行する必要があります。
Data Center 製品は、セッションの間、各ユーザーのリクエストが同じノードに送信されると想定しています。リクエストが別のノードに送信されると、ユーザーが予期せずログアウトしたり、セッション内で保存された情報が失われたりすることがあります。そのため、ロード バランサーでは Cookie ベースの 「スティッキー セッション」 (セッション アフィニティ) を有効にして、セッションを同一ノードにバインドする必要があります。Cookie ベースのスティッキー セッションを使用すると、製品で発行された Cookie を使用したり、ロード バランサーで生成された Cookie を使用したりすることができます。
ロード バランシング ソリューションに冗長性を加えて、保護レイヤーを追加し、ロード バランサーが単一障害点にならないようにします。そのためには、アクティブ/パッシブ構成内に 2 つのロード バランサーを設定します (両方のロード バランサーで 1 つの仮想 IP アドレスを使用)。アクティブ側のロード バランサーで障害が発生した場合は、パッシブ側のロード バランサーにフェイルオーバーします。
詳細については、ロード バランサー設定オプションを参照してください。
アプリケーション ノードとは何ですか?
アプリケーション ノードとは、実際に製品が稼働する場所です。レイテンシを最小限に抑えるため、Data Center クラスタ内の各ノードは、製品の同じバージョンで動作し、同じ場所に置かれる必要があります。ただし、地理的に分散したチームのパフォーマンスは、コンテンツ デリバリ ネットワーク (CDN) によってサポートできます。これらのノードは、ユーザーに製品を提供するため、1 つのクラスタにおいて 1 つのノードとして機能するように設定されます。クラスタ内のノードの数は、ニーズや、製品の構成方法によって異なります。通常、ほとんどのクラスタでは 2 - 4 ノードで十分ですが、適切な数を判断するためノード サイズ ガイドをご利用ください。
重要な注意: Bitbucket には、コード検索を可能にする ElasticSearch 専用の追加アプリケーション ノードが必要です。
ファイル システムはどのように機能しますか?
共有ファイル システムは、製品のすべての基礎が保存される場所です。そこでは、添付ファイル、アイコン、ユーザー情報、アプリ、ソース コードなどの要素が運用されます。
Data Center 環境では、共有ファイル システムを独自のノードとしてセットアップする必要があります。共有ファイル システム用の NFS ベース NAS または SAN プログラムを使用することもできますが、パフォーマンスを維持するため NFS3 を推奨します。DFS などの分散プロトコルはサポートされていないため、使用しないでください。
ステージング環境の作成
移行を成功させるため、本番環境での稼働前に、ステージング環境を作成して Data Center を試してみることを推奨します。
ステージング環境は、リバース プロキシ、SSL 設定、またはロード バランサー (Data Center の場合) を含めて、本番環境を厳密に複製する必要があります。異なる物理サーバーまたは仮想ソリューションを使用することもできます。重要なことは、本番環境に見合ったレプリカとすることです。
環境作成後、以下の手順を行う必要があります。
- データベースの複製
- 製品の複製
- ローカル ホーム ディレクトリを共有ホーム ディレクトリにコピー
- 外部ユーザー管理の複製 (オプション)
詳細については、以下を参照してください。
アプリの確認とアップグレード
非クラスタ Data Center をデプロイする前に、アプリを確認してください。可能であれば Data Center バージョンにアップグレードする必要があります。アプリをアップグレードする前に Data Center に移行すると、動作が停止する可能性があります。
Data Center のインストール
クラスタ アーキテクチャをセットアップできたので、Data Center 製品をインストールできます。
詳細な手順については、クラスタでの Data Center 製品のデプロイをサポートする当社のドキュメントをご確認ください。
| | | Confluence | Bitbucket | Crowd |
|---|---|---|---|---|
| ハードウェア | Jira Software Jira Service Desk | Confluence | Bitbucket | Crowd |
| AWS | Jira Software Jira Service Desk | Confluence | Bitbucket | Crowd |
| Azure | Jira Software Jira Service Desk | Confluence | Bitbucket | Crowd
|
予行演習
テスト フェーズは、Data Center のデプロイにおける基礎的な手順であり、多くの場合、移行プロセスで最も手間がかかる部分です。Data Center を自信を持って本番環境にデプロイするには、チームが機能テスト、統合テスト、パフォーマンステストを繰り返し実施し、Data Center インストールを徹底的に検証する必要があります。サーバーからの移行の場合、各テストは 1 - 2 週間かかります。
手間を惜しまないでください。テストフェーズを徹底することで、本番デプロイが成功しやすくなり、予期せぬ状況にも対応できるようになります。稼働を開始できるか確信が持てるまで、必要に応じて、ユーザー受け入れテスト (UAT) を複数回実施してください。
以下の Data Center 製品のパフォーマンスの詳細を参照してください。
カスタマー サクセス マネージャーがある場合、ヘルス チェックを実施して、特に構成、互換性、ドライバ バージョン、パフォーマンス状況、メモリ設定の既知の問題を確認してください。