AWS クラスタで Confluence を実行する

Confluence Data Center をクラスタ環境でデプロイすることを決定した場合は、Amazon Web Services (AWS) の利用をご検討ください。AWS は、追加のノードをリサイズおよびすばやく起動することでデプロイメントを柔軟にスケーリングできる機能や、Confluence Data Center ですぐに動作する多数のマネージド サービスを提供します。こうしたサービスにより、ご利用のデプロイメントのクラスタ インフラストラクチャを簡単に構成、管理、保守できます。

Data Center のメリットの詳細について興味をお持ちの方は、Confluence Data Center の概要をご確認ください。

このページの内容

非クラスタ環境とクラスタ環境

クラスタ化を必要とする特定の機能 (例: 高可用性) を必要としない場合、"Small" または "Medium" サイズのデプロイでは単一ノードが適しています。 

既存の Server インストールがある場合は、Data Center にアップグレードする際にそのインフラストラクチャを引き続き使用できます。Data Center 専用の多くの機能 (SAML シングル サインオンレート制限によるシステムの保護CDN サポートなど) では、クラスタ インフラストラクチャは不要です。Server インストールのライセンスをアップグレードするだけで、Data Center のこれらの機能の使用を開始できます。
 
クラスタ化が必要かどうかの詳細については「アトラシアンの Data Center 製品のアーキテクチャとインフラストラクチャのオプション」をご参照ください。

AWS クイック スタートを使用したクラスタでの Confluence Data Center のデプロイ

AWS に Data Center クラスタ全体をデプロイする最も単純な方法は、Quick Start を使用することです。Quick Start は、AWS のセキュリティと可用性のためのベスト プラクティスを使用して、AWS 上に特定のワークロードをデプロイするのに必要な AWS コンピュータ、ネットワーク、ストレージ、およびその他のサービスを、起動、設定、および実行します。

Quickstart では 2 つのデプロイメント オプションが提供され、それぞれが独自のテンプレートを持ちます。1 つめのオプションは、Atlassian Standard Infrastructure (ASI) をデプロイし、この ASI に Confluence Data Center をプロビジョニングします。2 つめのオプションは、既存の ASI への Confluence Data Center のデプロイのみを行います。

Atlassian Standard Infrastructure (ASI)

ASI は、アトラシアンのすべての Data Center 製品で必要なコンポーネントを含む仮想プライベート クラウド (VPC) です。詳細については、「AWS の Atlassian Standard Infrastructure (ASI)」をご参照ください。


Confluence Data Center のクイックスタートのアーキテクチャの概要を以下に示します。

デプロイメントは、以下のコンポーネントで構成されています。

  • インスタンス / ノード。Confluence を実行している、クラスタ ノードとしての 1 つ以上の Amazon Elastic Cloud (EC2) インスタンス。
  • ロード バランサ: ロード バランサおよび SSL ターミネート リバース プロキシの両方として機能する Application Load Balancer (ALB)。
  • Amazon EFS : 複数の Confluence ノードにアクセス可能な共通の場所にアーティファクトを保存する、共有ファイル システム。クイック スタートのアーキテクチャでは、高可用性構成の Amazon Elastic File System (Amazon EFS) サービスを使用して、共有ファイル システムを実装します。
  • データベース: 選択した共有データベース インスタンス – Amazon RDS または Amazon Aurora。
  • Amazon CloudWatch: Amazon のネイティブ CloudWatch サービスによる基本的なモニタリングおよび中央ログ。

アーキテクチャ、コンポーネント、およびデプロイメント プロセスの詳細については、「Quick Start ガイド」を参照してください。 

Confluence では、EC2 インスタンスにインストールされている Java Runtime Engine (/usr/lib/jvm/jre/) ではなく、Confluence にバンドルされている JRE (/opt/atlassian/confluence/jre/) が使用されます。 


高度なカスタマイズ

迅速な実装のため、クイック スタートでは手動インストールと同じレベルのカスタマイズは提供していません。ただし、アトラシアンで使用している Ansible プレイブックの変数を通じてデプロイメントをさらにカスタマイズできます。

アトラシアンが提供しているすべての AWS クイック スタートでは、Ansible プレイブックを使用してデプロイメントの特定のコンポーネントを構成しています。これらのプレイブックは次のリポジトリで公開されています。

https://bitbucket.org/atlassian/dc-deployments-automation

Ansible 変数を使用してこれらの構成をオーバーライドできます。詳細は、リポジトリの README ファイルを参照してください。

自身の S3 バケットからのクイック スタートの起動 (推奨)

クイック スタートをもっとも素早く起動する方法は、AWS S3 バケットから直接起動することです。だだしこれを行った場合、アトラシアンでクイック スタート テンプレートに加えているすべての更新がデプロイメントに直接伝播されます。これらの更新には、テンプレートからのパラメーターの追加や削除が含まれる場合があります。これにより、デプロイメントに予期しない (および大幅な) 変更が発生する可能性があります。

本番環境の場合、クイック スタート テンプレートを自身の S3 バケットにコピーすることをおすすめします。次に、それらをそこから直接起動します。これにより、クイック スタートの更新をデプロイメントに伝播するタイミングを制御できるようになります。

  1. クイックスタート テンプレート (すべてのサブモジュールを含む) をローカル マシンにクローンします。コマンド ラインから、以下を実行します。

  2. (オプション) クイックスタート テンプレート リポジトリは、クイック スタート インターフェイスで必要となるディレクトリ構造を使用しています。必要に応じて (ストレージ コストを最小限に抑えたい場合など)、以下を除くすべてのファイルを削除できます。

    quickstart-atlassian-confluence 
    ├─ submodules 
    │ └─ quickstart-atlassian-services 
    │ └─ templates 
    │ └── quickstart-vpc-for-atlassian-services.yaml 
    └─ templates 
    ├── quickstart-confluence-master-with-vpc.template.yaml 
    └── quickstart-confluence-master.template.yaml

  3. AWS コマンド ライン インターフェイスをインストールしてセットアップします。これにより、S3 バケットを作成し、そこにコンテンツをアップロードすることができます。

  4. 自身のリージョンで S3 バケットを作成します。

    aws s3 mb s3://<bucket-name> --region <AWS_REGION>

この時点で、クイック スタート テンプレートを自身の S3 バケットにアップロードできるようになりました。これを行う前に、使用するクイック スタート テンプレートを選択する必要があります。

    • quickstart-confluence-master-with-vpc.template.yaml: 新しい ASI へのデプロイ (エンドツーエンドのデプロイメント) に使用します。

    • quickstart-confluence-master.template.yaml: 既存の ASI にデプロイする際に使用します。

  1. In the template you’ve chosen, the QSS3BucketName default value is set to aws-quickstart. Replace this default with the name of your S3 bucket.
  2. クイック スタート テンプレートのローカル クローンの親ディレクトリに移動します。ここから、ローカル クローン内のすべてのファイルを S3 バケットにアップロードします。

    aws s3 cp quickstart-atlassian-confluence s3://<bucket-name> --recursive --acl public-read

  3. すべてをアップロードしたら、S3 バケットから本番スタックをデプロイする準備が整いました。[Cloudformation] > [Create Stack] に移動します。テンプレートを指定する際は、使用するクイック スタート テンプレートのオブジェクト URL を貼り付けます。

高可用性のための Amazon Aurora データベース

クイックスタートによって、(RDS の代わりに) Amazon Aurora クラスタ データベースを使用して Confluence Data Center をデプロイすることもできます。 

クラスタは PostgreSQL 互換で、2 つのデータベース リーダーをレプリケートする、プライマリ データベース ライターを備えています。冗長性を向上させるため、異なるアベイラビリティ ゾーンにライターとリーダーをセットアップすることもできます。

ライターが失敗した場合、Aurora はリーダーの 1 つを自動的にプロモートしてライターにします。詳細は「Amazon Aurora の特徴: PostgreSQL 互換エディション」 を参照してください。

既存の Confluence Data Center インスタンスをセットアップして Amazon Aurora を使用する場合は追加の手順が必要となります。手順の詳細については「Amazon Aurora を使用するために Confluence Data Center を構成する」を参照してください。

Synchrony のセットアップ

Confluence Data Center ライセンスをお持ちの場合、Synchrony を実行するには 2 つのメソッドを使用できます。

  • Confluence で管理 (推奨)
    Confluence は同じノードで自動的に Synchrony プロセスを起動して管理します。手動による操作は不要です。 
  • スタンドアロンの Synchrony クラスタ (ユーザーによる管理)
    ユーザーはスタンドアロンな Synchrony を必要なノード数で、独自のクラスタでデプロイおよび管理します。大規模なセットアップが必要です。 

シンプルなセットアップを実現してメンテナンスの労力を極力減らしたい場合、Synchrony を Confluence で管理することをおすすめします。完全な制御を実現したい場合や、エディタの高い可用性の確保が必須である場合、独自のクラスタで Synchrony を管理することが、組織に最適なソリューションである可能性があります。 

デフォルトでは、クイック スタートは Confluence によって管理される Synchrony を構成します。ただし、クイック スタートを使用してスタンドアロンの Synchrony を構成することができます。これを行うと、クイック スタートは、Synchrony を実行するクラスタ ノードとして、1 つ以上の Amazon EC 2 インスタンスを含む Auto Scaling グループを作成します。 

Synchrony の構成の詳細については、「Confluence と Synchrony で利用可能な設定」を参照してください。

管理モードは、Confluence 6.12 以降でのみ使用できます。

6.12 より前のバージョンの Confluence Data Center をデプロイする場合、スタンドアロン モードのみを使用できます。つまり、クイック スタートでは Collaborative editing modesynchrony-separate-nodes. に設定する必要があります。

Amazon CloudWatch による基本的なモニタリングおよび中央ログ

また、クイック スタートでは、Amazon CloudWatch によるノード管理も提供されます。これにより、各ノードの CPU、ディスク、およびネットワーク アクティビティのすべてを、事前設定済みの CloudWatch ダッシュボードから追跡できます。ダッシュボードは、最新のログ出力を表示するように設定され、後で監視および指標を追加してカスタマイズできます。

既定では、Amazon CloudWatch は各ノードからログを収集し、単一の中央ソースに保存します。この中央ログにより、デプロイのログ データをより簡単かつ効果的に検索および分析できます。詳細については、「CloudWatch Logs Insights を使用したログ データの分析」および「フィルター パターンを使用したログ データ検索」を参照してください。

Amazon CloudWatch は基本的なロギングとモニタリングを提供しますが、コストもかかります。デプロイのコストを削減するために、デプロイ中にはログを無効にするか、Amazon CloudWatch 連携をオフにすることができます。

tip/resting Created with Sketch.

ログ データをダウンロードするには (AWS 以外の場所でアーカイブおよび分析する場合など)、データを最初に S3 にエクスポートする必要があります。そこからダウンロードできます。詳しくは、「Amazon S3 へのログ データのエクスポート」を参照してください。

オート スケーリング グループ

この Quick Start は Auto Scaling グループを使用しますが、これはクラスタ ノード数の静的制御のみを目的としています。Auto Scaling を使用してクラスタのサイズを動的に拡張することは推奨されません。アプリケーション ノードのクラスタへの追加には通常 20 分以上かかりますが、この速度では突然の負荷のスパイクに対処できません。

高負荷および低負荷の期間を特定できる場合、それに応じてアプリケーション ノード クラスターのスケールをスケジュールできます。詳細については、「Amazon EC2 Auto Scalingのための拡張スケジュール」を参照してください。 

組織の負荷の傾向を調査するには、デプロイのパフォーマンスを監視する必要があります。実施方法のヒントについては、「Confluence Data Center のサンプル デプロイメントおよび監視戦略」を参照してください。 

EC2 のサイジングに関する推奨事項

Large または XLarge のデプロイの場合は、アプリケーション、Synchrony、データベースのサイズ設定のアドバイスについて、「AWS インフラストラクチャの推奨事項」をご確認ください。小規模なデプロイの場合、Confluence のシステム要件を満たすインスタンスを使用できます。より小さなインスタンス タイプ (micro、small、medium) は一般に、Confluence の実行には不十分です。

AWS クイック スタートの CloudFormation テンプレートのカスタマイズ

迅速な実装のため、クイック スタートでは手動インストールと同じレベルのカスタマイズは提供していません。代わりに、クイック スタートで使用される CloudFormation テンプレートを必要に応じてカスタマイズできます。これらのテンプレートは以下のリポジトリで入手できます。

https://github.com/aws-quickstart/quickstart-atlassian-confluence

サポート対象の AWS リージョン

Confluence の実行に必要なサービスが提供されていない地域もあります。Amazon Elastic File System (EFS) をサポートするリージョンを選択する必要があります。現在、次のリージョンで Quick Start を使用して Confluence をデプロイできます。  

  • アメリカ
    • バージニア北部
    • オハイオ
    • オレゴン
    • 北カリフォルニア
    • モントリオール
  • ヨーロッパ / 中東 / アフリカ
    • アイルランド
    • フランクフルト
    • ロンドン
    • パリ
  • アジア太平洋
    • シンガポール
    • 東京
    • シドニー
    • ソウル
    • ムンバイ

この一覧は に更新されました。

各リージョンで提供されるサービスは随時変更される可能性があります。使用したいリージョンがこの一覧に含まれていない場合、そこが EFS をサポートしているかどうかを AWS ドキュメントの「リージョンごとの製品サービス」の表でご確認ください。 

AWS GovCloud は本番環境用ではありません

アトラシアンのクイック スタートは AWS GovCloud リージョンでも提供されますが、これはテスト目的にのみ利用できます。このクイック スタートで行われる GovCloud リージョンでのデプロイはサポートされません。

Confluence 6.3.1 以前をデプロイする場合....

6.3.2 より前の Confluence バージョンには、追加の依存関係があります。Synchrony (共同編集に必須) は、Amazon API の操作にサードパーティ ライブラリを使用しますが、リージョンによっては適切なエンドポイントを使用できない場合があります。これにより、次のリージョンで Synchrony を実行することができません。

  • 米国東部 (オハイオ)
  • EU (ロンドン)1
  • アジア パシフィック (ムンバイ) 1
  • アジア パシフィック (ソウル) 1
  • カナダ (中央) 1

1 本記事の作成時点で、これらのリージョンは EFS に未対応です。このため、これらのリージョンを Confluence の実行に使用することはできません。

Route53 プライベート ホステッド ゾーンを使用した内部ドメイン名ルーティング

Confluence サイトが AWS でホストされている場合も、内部のオンプレミス DNS サーバーがある場合はそこに Confluence サイトの DNS をリンクすることができます。これを行うには、Amazon Route53 を通じて、パブリック DNS と内部 DNS の間にリンクを作成します。これにより、わかりやすいドメイン名を使用してインフラストラクチャ リソース (データベース、共有ホームなど) に簡単にアクセスできるようになります。DNS 設定に応じて、これらのドメイン名を外部または内部からアクセスできるようにすることができます。

ステップ 1. 新しいホステッド ゾーンを作成する

[サービス] > [Route 53]プライベート ホステッド ゾーンを作成します。ドメイン名は任意のドメインに設定します。VPC の場合、既存の Atlassian Standard Infrastructure を使用します。

ステップ 2. ホステッド ゾーンを使用するようスタックを設定する

ご利用のデプロイメントのクイック スタート テンプレートを使用して、スタックが手順 1 のホステッド ゾーンをポイントするようにします。Confluence を初めてセットアップする場合、次のようにクイック スタート テンプレートに従います。

  1. [DNS (オプション)] の [Route 53 のホステッド ゾーン] フィールドに、自身のホステッド ゾーンの名前を入力します。

  2. [ホステッド ゾーンのサブドメイン] フィールドに希望するドメインのサブドメインを入力します。空のままにしておくと、スタック名がサブドメインとして使用されます。

  3. プロンプトに従ってスタックをデプロイします。

既存の Confluence サイトが既にある場合は、クイック スタート テンプレートでスタックを構成することもできます。このテンプレートにアクセスするには、次の手順に従います。

  1. AWS コンソールで [サービス] > [CloudFormation] に移動します。

  2. スタックを選択し、[スタックの更新] をクリックします。

  3. [DNS (オプション)] の [Route 53 のホステッド ゾーン] フィールドに、自身のホステッド ゾーンの名前を入力します。

  4. [ホステッド ゾーンのサブドメイン] フィールドに希望するドメインのサブドメインを入力します。空のままにしておくと、スタック名がサブドメインとして使用されます。

  5. プロンプトに従ってスタックを更新します。

いずれの場合も、AWS はロード バランサー、EFS、およびデータベース用の URL と Route 53 レコードを生成します。たとえば、ホステッド ゾーンが my.hostedzone.com でスタックの名前が mystack の場合、URL mystack.db.my.hostedzone.com からデータベースにアクセスできます。

ステップ 3. DNS サーバーを Confluence サイトの VPC にリンクする

AWS 外部の DNS サーバーを使用する場合、それをデプロイメントの VPC (この場合は Atlassian Standard Infrastructure) にリンクする必要があります。つまり、DNS サーバーは Route53 を使用して、ホステッド ゾーンで指定したドメイン (手順 1) へのすべてのクエリを解決する必要があります。

これをセットアップする方法の手順については、「VPC とネットワークとの間の DNS クエリの解決」を参照してください。

自身の DNS サーバーを使用して内部向けの Confluence サイトをデプロイする場合、Amazon Route 53 を使用してパブリック DNS と内部 DNS 間のリンクを作成することができます。 

  1. Route 53 で、プライベート ホステッド ゾーンを作成します。VPC については、既存の Atlassian Services VPC を使用できます。ドメイン名はお好みのドメインに設定します。
  2. すでに Confluence をセットアップしている場合、AWS コンソールで [サービス] > [CloudFormation] に移動してスタックを選択し、[スタックの更新] をクリックします (Confluence を初めてセットアップする場合、以降の Quick Start テンプレートに従います)。 
  3. [その他のパラメータ] の [Route 53 のホステッド ゾーン] フィールドに、自身のホステッド ゾーンの名前を入力します。 
  4. 任意のサブドメインを入力します。または、[ホステッド ゾーンのサブドメイン] フィールドを空のままにしておくと、スタック名がサブドメインとして使用されます。
  5. プロンプトに従ってスタックを更新します。ロード バランサおよび EFS URL が生成され、Route 53 にそれぞれのレコードが作成されます。 
  6. Confluence で、 > [一般設定]に移動し、Confluence のベース URL を Route 53 のドメインに更新します。 
  7. ご利用のオンプレミス ネットワークとプライベート ホステッド ゾーンに紐付いた VPC との間に DNS 解決をセットアップします。これを行うには、次の製品を使用します。
    1. Active Directory (Amazon Directory Service または Microsoft Active Directory)
    2. bind9 または Unbound を使用する、EC2 の DNS フォワーダ
  8. 最後に、Confluence と Synchrony の各ノードを終了して再度プロビジョニングし、変更を有効にします。
tip/resting Created with Sketch.

Confluence のベース URL の構成に関連する情報については、「サーバー ベース URL の設定」を参照してください。


スケーリング (拡張および縮小)

Confluence または Synchrony クラスタ ノードの数を増減させるには、次の手順を実行します。

  1. AWS マネジメント コンソールにサインインし、ナビゲーション バーのリージョン セレクタを使用してデプロイメントに対応した AWS リージョンを選択し、https://console.aws.amazon.com/cloudformation/ で AWS CloudFormation コンソールを開きます。
  2. デプロイメントの [Stack name] をクリックします。これにより、デプロイメントのスタック情報が表示されます。ここで、[Update] をクリックします。
  3. [Select Template] ページで [Use current template] を選択したままにし、[Next] を選択します。
  4. [Specify Details] ページで、[Parameters] セクションの [Cluster nodes] に移動します。ここで、次のパラメーターに対して希望する数のアプリケーション ノードを設定します。
    1. Minimum number of cluster nodes
    2. Maximum number of cluster nodes
  5.  クリックしてスタックを更新します。

Auto Scaling の無効化について

クラスタの最小ノード数と最大ノード数が同じであるため、Auto Scaling が事実上無効化されています。

クラスタ ノードの最小数と最大数に異なる値を設定すると、Auto Scaling が有効になります。これにより、システム負荷に基づいてクラスタのサイズが動的にスケーリングされます。

ただし、Auto Scaling は無効化したままにすることをおすすめします。現時点では、Auto Scaling はご利用のデプロイメントのシステム負荷の急激な変化に効果的に対処できません。つまり、負荷に応じてクラスタを手動で再スケーリングする必要があります。

垂直拡張と水平拡張の違い

特に負荷スパイクに対応する場合、新しいクラスタ ノードを追加することで、クラスタのキャパシティを一時的に増加させることができます。特定のしきい値を超えると、大量のクラスタ ノードの追加による効果は減少します。一般に、特にノード自体が小さい場合、各ノードのサイズを増加させる ("垂直" スケーリング) と、ノード数を増やす("水平" スケーリング) 場合よりも大きな持続的キャパシティを扱うことができます。詳細については、「AWS でのエンタープライズ Confluence インスタンスの推奨インフラストラクチャ」をご参照ください。

オートスケーリング グループの詳細については、AWS のドキュメントを参照してください。 

SSH 経由でノードに接続する

You can perform node-level configuration or maintenance tasks on your deployment through the AWS Systems Manager Sessions Manager. This browser-based terminal lets you access your nodes without any SSH Keys or a Bastion host. For more information, see Getting started with Session Manager.

Access via Bastion host

You can also access your nodes via a Bastion host (if you deployed one). To do this, you'll need your SSH private key file (the PEM file you specified for the Key Name parameter). Remember, this key can access all nodes in your deployment, so keep this key in a safe place.

The Bastion host acts as your "jump box" to any instance in your deployment's internal subnets. That is, access the Bastion host first, and from there access any instance in your deployment. 

The Bastion host's public IP is the BastionPubIp output of your deployment's ATL-BastionStack stack. This stack is nested in your deployment's Atlassian Standard Infrastructure (ASI). To access the Bastion host, use ec2-user as the user name, for example:

ssh -i keyfile.pem ec2-user@<BastionPubIp>

ec2-user は、 sudo アクセスを持ちます。root による SSH アクセスは許可されません。

アップグレード

Consider upgrading to a Long Term Support release (if you're not on one already). Enterprise releases get fixes for critical bugs and security issues throughout its two-year support window. This gives you the option to keep a slower upgrade cadence without sacrificing security or stability. Long Term Support releases are suitable for companies who can't keep up with the frequency at which we ship feature releases.

デプロイメントのアップグレードについて、次の点をご確認ください。

  1. Confluence Data Center の最新バージョンにアップグレードする前に、アプリにそのバージョンとの互換性があるかを確認します。必要に応じてアプリを更新します。アプリの管理の詳細については、「Universal Plugin Manager の使用」を参照してください。
  2. アップグレード中に Confluence Data Center を使用し続ける必要がある場合、サイト メンテナンス用の読み取り専用モードを使用することをおすすめします。ユーザーはページを閲覧することはできますが、作成したり変更したりすることはできません。
  3. 本番サイトをアップグレードする前に、ステージング環境でアップグレードを実施することを強くおすすめします。「Confluence のアップグレードのためのステージング環境の作成方法」には、これを行うための便利なヒントが記載されています。

デプロイメントをアップグレードするタイミングであることを判断したら、次の手順を実行します。

ステップ 1: 実行中のすべての Confluence Data Center アプリケーション ノードの終了

Confluence Data Center スタックで使用されるアプリケーション ノードの数を 0 に設定します。その後、スタックを更新します。

デプロイメントでスタンドアロンの Synchrony を使用している場合、同時に Synchrony ノードの数を 0 にスケール ダウンします。

クリックして詳しい手順を確認


  1. AWS コンソールで、[Services] > [CloudFormation] に移動します。デプロイメントのスタックを選択してスタックの詳細を表示します。

  2. スタックの詳細画面で、[Update Stack] をクリックします。

  3. [Select Template] 画面で、[Use current template] を選択してから、[Next] をクリックします。

  4. 実行中のすべてのノードを終了する必要があります。これを実行するには、次のパラメーターを 0 に設定します。

    1. Maximum number of cluster nodes

    2. Minimum number of cluster nodes

  5. [Next] をクリックします。以降のページをクリックして進み、[Update] ボタンを使用して変更を適用します。

  6. 更新が完了したら、すべての アプリケーション ノードが終了していることを確認します。



ステップ 2: Confluence Data Center スタックで使用されるバージョンの更新

Confluence Data Center で使用されるアプリケーション ノードの数を 1 に設定します。希望のバージョンを使用できるようにアプリケーション ノードを設定します。その後、スタックを再度更新します。

デプロイメントでスタンドアロンの Synchrony を使用している場合、同時に Synchrony ノードの数を 1 にスケール ダウンします。

クリックして詳しい手順を確認

  1. デプロイメントの [Stack Details] 画面で、[Update Stack] をもう一度クリックします。

  2. [Select Template] 画面で、[Use current template] を選択してから、[Next] をクリックします。

  3. Version パラメーターを、更新先のバージョンに設定します。

  4. 1 つのノードで使用するようにスタックを構成します。これを実行するには、次のパラメーターを 1 に設定します。

    1. Maximum number of cluster nodes

    2. Minimum number of cluster nodes

  5. [Next] をクリックします。以降のページをクリックして進み、[Update] ボタンを使用して変更を適用します。

ステップ 3: アプリケーション ノードの数の拡張

これで、デプロイメントをスケール アップしてアプリケーション ノードの数を元に戻せます。スタンドアロンの Synchrony がある場合は、Synchrony ノードでも同様に実行します。クラスタで使用されるノードの数の再構成方法の手順については、ステップ 1 を参照してください。

AWS の Confluence Data Center では現在、古いバージョンの最後のクラスタ ノードのシャットダウンと新しいバージョンの最初のクラスタ ノードの起動の間のダウンタイムが必須であり、インスタンスをダウンタイムなしでアップグレードすることはできません。新しいノードが新しいバージョンで起動する前に、既存のすべてのノードが終了していることを確認してください。 

 

バックアップ

AWS のネイティブ バックアップ機能を使用することをおすすめします。これは Confluence Data Center のバックアップにスナップショットを使用します。詳しくは、「AWS バックアップ」を参照してください。 

AWS への既存の Confluence サイトの移行

AWS で Confluence をデプロイしたあとに、古いデプロイメントをそこに移行することもできます。この操作を行うには、次の手順を実行します。

  1. 既存のサイトを、AWS にデプロイしたバージョン (Confluence 6.1 以降) にアップグレードします。
  2. (オプション) 古いデータベースが PostgreSQL でない場合、それを移行する必要があります。手順については、「別のデータベースへの移行」を参照してください。 
  3. PostgreSQL データベースと既存の <shared-home>/attachments ディレクトリをバックアップします。
  4. バックアップ ファイルを EC2 インスタンスの /media/atl/confluence/shared-home にコピーします。  
  5. pg_restore を使用して PostgreSQL のデータベース ダンプを RDS インスタンスにリストアします。
    この方法の詳細については、Amazon のドキュメントの「Importing Data into PostgreSQL on Amazon RDS」を参照してください。   


重要な注意事項

  • CloudFormation テンプレートを使用してクラスタを作成すると、データベース名は confluence になります。リストア時にはこのデータベース名を保持する必要があります。データベース名が保持されない場合、新しいノードのプロビジョニング時に問題が発生する可能性があります。この場合、新しいデータベースをドロップしてバックアップで置き換える必要があります。 
  • 既存のローカル ホームまたはインストール ディレクトリからインデックスなどをコピーする必要はありません。既存の共有ホーム ディレクトリからは attachments だけをコピーします。  
  • <shared-home>/config/cache-settings-overrides.properties ファイルを変更した場合、新しい環境で変更を再適用することをおすすめします。  
  • AWS ページ「Importing Data into PostgreSQL on Amazon RDS」に記載されている _copy メソッドは、Confluence の移行には推奨されません。
最終更新日 2020 年 4 月 5 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.