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
を使用して、他のデバイスと同様にファイルシステムの作成を処理します。
(データ損失の可能性を回避するために、TPAは有効なファイルシステムが既に含まれているデバイスでのLUKS暗号化の設定を拒否します。)
LUKSで暗号化されたvolume_for: postgres_data
を作成すると、TPAはブート時に自動的に起動しないように構成します。
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が必要とするディレクトリに適切な所有権と権限があることを（別に）保証するため、自分で行う必要はありません。
