Filesystem configuration¶
TPAを使用すると、各インスタンスに添付されたvolumes
のリストを定義できます。
このリストには、プロビジョニング中に使用されるプラットフォーム固有の設定と、展開中に使用されるファイルシステムレベルの設定の両方が含まれています。
まず、 tpaexec provision
は情報を使用してボリュームを作成し、インスタンスにアタッチします（該当する場合。詳細については、以下のプラットフォーム固有のセクションを参照）。次に、ボリュームの単純化されたリスト（非プラットフォーム固有の設定のみを含む）をインスタンスのホスト変数として書き込みます。最後に、
tpaexec deploy
は、必要に応じて、単純化されたリストに基づいて動作し、ファイルシステムをセットアップおよびマウントします。
AWSクラスターからの適度に複雑な例を次に示します。
instances:
- Name: one
…
volumes:
- device_name: root
volume_type: gp2
volume_size: 32
- raid_device: /dev/md0
device_name: /dev/xvdf
volume_type: io2
volume_size: 64
raid_units: 2
raid_level: 1
iops: 5000
vars:
volume_for: postgres_data
encryption: luks
- raid_device: /dev/md1
device_name: /dev/xvdh
ephemeral: ephemeral0
raid_units: all
vars:
mountpoint: /mnt/scratch
この例では、EC2インスタンスは32GB EBSルートボリューム、/opt/postgres/dataとしてマウントされた2つのプロビジョンドiops EBSボリュームで構成される64GB RAID-1ボリューム、および使用可能なすべてのインスタンスで構成される/tmp/scratchファイルシステムになります。 -ストア（「エフェメラル」）ボリューム、その数とサイズはインスタンスタイプによって決まります。
詳細は以下のAWSのセクションに記載されていますが、 volume_type
およびvolume_size のような設定はプロビジョニング中に使用され、
volume_for またはmountpoint のようなvars
の下の設定は展開中に使用するためにインベントリに書き込まれます。
default_volumes¶
ボリュームはインスタンスのプロパティです。プラットフォーム固有の設定が含まれているため、cluster_vars
で設定することはできません。
メカニズムは、ボリューム定義を特別に許可します。大規模なクラスターでのボリューム定義は非常に反復的である可能性があるため（特に、クラスター内のインスタンスをできるだけ近くに構成することをお勧めするため、ここに示すようにdefault_volumes
を指定できます。
instance_defaults:
default_volumes:
- device_name: root
volume_type: gp2
volume_size: 32
- device_name: /dev/xvdf
volume_size: 100
instances:
- Name: one
…
- Name: two
volumes:
- device_name: /dev/xvdf
volume_size: 64
- device_name: /dev/xvdg
volume_size: 64
…
- Name: three
volumes:
- device_name: /dev/xvdf
volume_type: none
- Name: four
volumes: []
ここで、すべてのインスタンスには、デフォルトで32GBのルートボリュームと100GBの追加ボリュームがあります（インスタンスone
の場合と同様、別のものを指定しません）。インスタンスtwo
は同じルートボリュームを持ちますが、 /dev/xvdf
をオーバーライドして代わりに64GBになり、さらに別の64GBボリュームがあります。インスタンスthree
には同じルートボリュームがありますが、デフォルトの/dev/xvdf
にvolume_type: none
を設定するため、追加のボリュームはありません。インスタンスfour
にはボリュームがまったくありません。
インスタンスはdefault_volumes
で指定されたもので始まり、そのvolumes
エントリは同じdevice_name
でデフォルトのエントリをオーバーライドしたり、 volume_type
をnone
に設定してボリュームを削除したり、異なる名前で新しいボリュームを追加したり、デフォルトを完全に拒否したりできます。
（2つのリストをマージするこの動作は、default_volumes
に固有です。instance_defaults とinstances
の両方で他のリストを設定すると、後者は前者を完全にオーバーライドします。）
プラットフォームAWS¶
AWS EC2インスタンスでは、EBSボリュームをアタッチできます。
instances:
- Name: one
…
volumes:
- device_name: root
volume_type: gp2
volume_size: 32
encrypted: yes
…
- device_name: /dev/xvdf
volume_type: io1
volume_size: 32
iops: 10000
delete_on_termination: false
…
- device_name: /dev/xvdg
ephemeral: ephemeral0
…
TPAは、 root のdevice_name
をインスタンスタイプに基づいて/dev/sda または/dev/xvda
に変換するため、どちらを使用するかを覚え（または変更）する必要はありません。
volume_type は、EBSボリュームタイプを指定します。例、 gp2
（「汎用」EBSボリュームの場合）、プロビジョンドIOPSボリュームのio1
（この場合、 iops: 5000 も設定する必要があります）など。
volume_size は、ボリュームのサイズをギガバイト単位で指定します。
encrypted: yes を設定して、保存時のEBS暗号化を有効にします。
（これはAWSの機能であり、新しく生成されたTPA構成でデフォルトで有効になっており、以下で説明する
LUKS暗号化 とは異なります。）
delete_on_termination をfalse
に設定して、アタッチされたインスタンスが終了したときにボリュームが破棄されないようにします（これがデフォルトの動作です）。
ephemeral: ephemeralN
を設定して、以前はエフェメラルボリュームと呼ばれていた、物理的に接続された
を使用します。利用可能なインスタンスストアボリュームの数、タイプ、およびサイズは、インスタンスタイプによって異なります。すべてのインスタンスにインスタンスストアボリュームがあるわけではありません。インスタンスストアボリュームはテストまたは一時データにのみ使用し、EBSボリュームは気になるデータに使用します。
EBSボリュームの場合、 snapshot: snap-xxxxxxxx
を設定して、既存のスナップショットからボリュームをアタッチすることもできます。スナップショットから復元されたボリュームは、S3から十分なデータが読み取られてローカルにキャッシュされるまで、非常に遅い場合があります。
（特に、スナップショットからPGDATA
を使用して新しいインスタンスをスピンアップできますが、全負荷を処理する準備が整うまでに数時間かかることが予想されます。）
ボリュームのattach_existing: yes
を設定し、名前/タイプ/サイズ/iopsが一致する既存の接続されていないEBSボリュームがある場合、インスタンスの起動時に新しいボリュームは作成されませんが、代わりに既存のボリュームがインスタンスに接続されますはじめて始まります。再アタッチされたEBSボリュームは、スナップショットから作成されたボリュームのパフォーマンス制限の影響を受けません。
プラットフォームベア¶
TPAは、事前にプロビジョニングされたbare
インスタンスに接続できるボリュームを制御できませんが、適切なdevice_name
でvolumes を定義すると、必要に応じてデバイスのmkfs
およびmount を処理します。
プラットフォームDocker¶
Dockerコンテナにはボリュームをアタッチできますが、それらはバインドマウントされたディレクトリであり、通常のブロックデバイスではありません。個別に初期化またはマウントする必要はありません。このように、構成はかなり異なって見えます。
instances:
- Name: one
platform: docker
…
volumes:
- /host/path/to/dir:/tmp/container/path:ro
- named_volume:/mnt/somevol:rw
これらのボリューム指定は、docker run -v
への引数として認識される場合があります。
ボリュームはコンテナーの作成時にアタッチされ、展開中にそれ以上のアクションはありません。
RAIDアレイ¶
AWS EC2インスタンスでは、RAIDボリュームを定義できます。
instances:
- Name: one
…
volumes:
- raid_device: /dev/md0
device_name: /dev/xvdf
raid_units: 2
raid_level: 1
volume_type: gp2
volume_size: 100
vars:
volume_for: postgres_data
この例では、4×100GB EBS gp2ボリューム（/dev/xvd[f-i]
）をアタッチし、それらを/dev/md0
という名前のRAID-1ボリュームにアセンブルします。展開中のvolume_for
またはmountpoint の処理は、他のボリュームと同様に発生します。
TPAは現在、他のプラットフォームでのRAIDアレイの作成とアセンブリをサポートしていませんが、
device_name: /dev/md0 または/dev/mapper/xyz
でボリュームにエントリを追加することにより、既存のアレイを使用できます。
TPAは、他のブロックデバイスと同様にmkfs およびmount
を処理します。
LUKS暗号化¶
TPAはLUKSで暗号化されたデバイスをセットアップできます。
instances:
- Name: one
…
volumes:
- device_name: /dev/xyz
vars:
encryption: luks
luks_volume: mappedname
volume_for: …
encryption: luks
が設定されたボリュームがまだ初期化されていない場合、TPAはcryptsetup
を使用して最初にluksFormat 、次にluksOpen
を使用して、他のデバイスと同様にファイルシステムの作成を処理する前に/dev/mapper/mappedname
の下にマップします。
(データ損失の可能性を回避するために、TPAは有効なファイルシステムが既に含まれているデバイスでのLUKS暗号化のセットアップを拒否します。)
LUKSで暗号化されたvolume_for: postgres_data
を作成すると、TPAはPostgresをブート時に自動的に起動しないように構成します。
tpaexec start-postgres clustername
を使用してボリュームをマウントし、Postgresを起動できます（およびstop-postgres
を使用してPostgresを停止し、ボリュームのマップを解除します）。
LUKSパスフレーズはローカルで生成され、ボールトに保存されます。
ファイルシステムの作成とマウント¶
device に有効なファイルシステムが含まれていない場合、mkfs
で初期化されます。
instances:
- Name: one
…
volumes:
- device_name: /dev/xyz
vars:
volume_for: …
fstype: ext4
fsopts:
- -cc
- -m 2
mountopts: defaults,relatime,nosuid
readahead: 65536
owner: root
group: root
mode: 0755
fstype （デフォルト：ext4）、mkfsに渡すfsopts
（デフォルト：none）、およびmountに渡してfstabに書き込むmountopts
を指定できます（下記参照）。
TPAは、デバイスの先読みをデフォルトで16MBに設定します（そして値をリブートしても持続します）が、上記のようにボリュームに別の値を指定できます。
ボリュームがマウントされている場所を判断する方法は2つあります。
mountpoint を明示的に指定するか、 volume_for
をpostgres_data 、postgres_wal 、postgres_tablespace
、またはbarman_data
に設定でき、TPAは設定をシステムの適切なマウントポイントに変換します。
mountpoint が決定されると、 device は指定されたmountopts
（デフォルト：defaults,noatime ）でそこにマウントされます。
/etc/fstab のファイルシステムのエントリーも作成されます。
オプションで、ボリュームにowner 、group 、またはmode
を指定でき、これらの属性はmountpoint
で設定されます。デプロイメントのこの非常に早い段階では、 postgres
ユーザーが存在するとは当てにできないことに注意してください。いずれにせよ、TPAは（個別に）Postgresが必要とするディレクトリに適切な所有権と権限があることを保証するため、自分で行う必要はありません。
