tpaexec rehydrate#

tpaexec rehydrate コマンドは、更新されたマシンイメージAMIでAWS EC2インスタンスを再構築し、TPAによって管理されるクラスターにセキュリティパッチとOSアップグレードを迅速に展開できます。

必要な変更をすべて備えた新しいAMIが与えられると、このコマンドはインスタンスを終了し、新しいイメージを使用する新しくプロビジョニングされたインスタンスに置き換え、サーバーの構成を正確に再作成する前に古いインスタンスからデータボリュームを接続しますconfig.yml )。

最新のイメージを公開し、定期的なスケジュールでサーバーをスクラッチから再構築することは、サーバーフリートに個々のセキュリティ更新を自分自身でダウンロードしてインストールできるようにするための代替手段です。これにより、各サーバーの状態を一目で追跡することが簡単になり、個々のサーバーへの手動変更を防ぎますインスタンスの置換中に一掃されます。

TPAを使用すると、リハイドレーション中にクラスター全体の中断を最小限に抑えることが簡単になりますが、プロセスには、個々のサーバーが終了および置き換えられるときに必然的にダウンタイムが含まれる必要があります。 M1 では、最初にレプリカをrehydrateから、 tpaexec switchover を使用できます

リハイドレートする前にプライマリをレプリカに変換します。 BDR-Always-ON では、リハイドレートする前に BDR/HAProxy server pool management を実行し、後で追加して戻すことができます。

Postgresおよび関連コンポーネントのマイナーバージョンの更新をインストールするだけの場合は、代わりに Upgrading your cluster コマンドを使用できます。

前提条件#

インスタンスをrehydrateできるようにするには、 config.yml のデータボリュームごとにdelete_on_termination: no およびattach_existing: yes を指定する必要があります。新しいインスタンスには、必ず新しいEBSルートボリュームがあります。

デフォルトでは、EC2インスタンスを終了すると、それにアタッチされているEBSボリュームも終了します。この場合、新しいインスタンスに再アタッチしたいため、delete_on_termination を無効にする必要があります。 attach_existing 設定により、TPAは、新しいインスタンスをプロビジョニングするときに古いボリュームを検索し、見つかった場合は、実行後にインスタンスにアタッチします。

古いインスタンスを手動で停止または終了しないでください。 tpaexec rehydrate コマンドは、インスタンスを安全にリハイドレートできることを確認した後にこれを実行します。

例#

~/clusters/night にAWSクラスター構成があると仮定します。

構成を変更する#

最初に、config.yml を編集し、新しいAMIを指定する必要があります。例

ec2_ami:
  Name: RHEL-8.3_HVM-20210209-x86_64-0-Hourly2-GP2
  Owner: 309956199498

各データボリュームでdelete_on_termination が無効になっていることを確認します。パラメーターが存在しない場合、AWS EC2管理コンソールからその値を確認できます。 ’Instances’をクリックし、インスタンスを選択してから、[Description]タブを開き、[Block devices]までスクロールし、EBSボリュームをクリックします。 “Delete on termination”フラグがtrueに設定されている場合、付録ことができます。また、 attach_existing を確認し、まだ設定されていない場合はyes に設定します。

次に、両方の属性が正しく設定された例を示します。

instances:

- node: 1
  Name: vlad
  subnet: 10.33.14.0/24
  role: primary
  volumes:
  - device_name: /dev/xvdf
    volume_type: gp2
    volume_size: 16
    attach_existing: yes
    delete_on_termination: false
    vars:
      volume_for: postgres_data
      mountpoint: /var/lib/pgsql

ボリュームパラメーターはinstance_defaults および特定のインスタンスで設定できることに注意してください。 volumes: を検索し、関連するすべてのボリュームにこれらの2つの属性が設定されていることを確認します。

rehydrationを開始します#

次に、 rehydrateコマンドの構文を示します。

tpaexec rehydrate ~/clusters/night instancename

単一のインスタンス名またはインスタンス名のコンマ区切りリストを指定できますが、クラスター内のすべてのインスタンスを一度にrehydrateことはできません。

このコマンドは、リハイドレートされるインスタンスに接続されているすべての非ルートEBSボリュームのdelete_on_termination フラグがfalseに設定されていることを確認します。これに当てはまらない場合、インスタンスが終了する前にエラーで停止します。

ボリューム属性が正しく設定されている場合、コマンドは最初に各インスタンスを終了し、次にプロビジョニングと展開を実行して、新しいAMIを使用する新しいインスタンスに置き換えます。

段階的にrehydrationする#

クラスターの継続性を維持するために、クラスターを段階的にリハイドレートすることをお勧めします。

たとえば、プライマリインスタンス、2つのレプリカ、およびBarmanバックアップサーバーを備えた M1 では、最初にBarmanインスタンスと1つのレプリカをrehydrate、次に別のレプリカをリハイドレートし、次に tpaexec switchover プライマリからリハイドレートしたレプリカのいずれかに、前者をrehydrateプライマリ、およびオプションで元のプライマリにスイッチオーバーします。このシーケンスにより、1つのプライマリと1つのレプリカが常に利用できるようになります。

付録#

awscliを使用してボリューム属性を変更する#

最初に、AWS管理コンソールでインスタンスとEBSボリュームを見つけます。 ’Instances’をクリックしてインスタンスを選択し、[Description]タブを開いて[Block devices]までスクロールし、EBSボリュームを選択します。 delete_on_termination を無効にするには、 --region 、--instance-id 、およびブロックデバイス名を正しい値に置き換えた後、次のコマンドを実行します。

aws ec2 modify-instance-attribute \
    --region eu-west-1 --instance-id i-XXXXXXXXXXXXXXXXX \
    --block-device-mappings \
      [{"DeviceName": "/dev/xvdf", "Ebs": {"DeleteOnTermination": false}}]

インスタンスのデータボリュームごとにこれを行います。少し遅延すると、管理コンソールに変更が表示されます。tpaexec rehydrate は、インスタンスを安全にリハイドレートできることも検出します。

tpaexec rehydrate

目次