Filesystem configuration#

TPAでは、各インスタンスにアタッチされるvolumes のリストを定義できます。

このリストは、プロビジョニング中に使用されるプラットフォーム固有の設定と、展開中に使用されるファイルシステムレベルの設定の両方で構成されています。

最初に、tpaexec provision は、情報を使用してボリュームを作成し、インスタンスに接続します該当する場合。詳細については、以下のプラットフォーム固有のセクションを参照してください。次に、ボリュームの単純化されたリストプラットフォーム固有ではない設定のみを含むをインスタンスのホスト変数として書き込みます。最後に、tpaexec deploy は、単純化されたリストに基づいて動作し、必要に応じてファイルシステムをセットアップおよびマウントします。

次に、AWSクラスターからの適度に複雑な例を示します。

instances:

- Name: one
  …
  volumes:
  - device_name: root
    volume_type: gp2
    volume_size: 32
  - device_name: /dev/xvdf
    volume_type: io2
    volume_size: 64
    iops: 5000
    vars:
      volume_for: postgres_data
      encryption: luks
  - device_name: /dev/xvdb
    ephemeral: ephemeral0
    vars:
      mountpoint: /mnt/scratch

この例では、EC2インスタンスは、32GB EBSルートボリューム、/opt/postgres/dataとしてマウントされた64GB io2ボリュームprovisioned-iops EBSボリューム、およびインスタンスストアによって提供される/tmp/scratchファイルシステムになります。「エフェメラル」ボリューム。その数とサイズは、インスタンスタイプによって決まります。

詳細は以下のAWSに関するセクションに記載されていますが、 volume_type やvolume_size のような設定はプロビジョニング中に使用され、 volume_for やmountpoint などのvars の下の設定は、展開中に使用するためにインベントリに書き込まれます。

default_volumes#

ボリュームはインスタンスのプロパティです。プラットフォーム固有の設定が含まれるため、cluster_vars では設定できません。

instance_defaults

このメカニズムでは、ボリューム定義に特別な考慮事項を作成します。大規模なクラスター内のボリューム定義は非常に反復的な場合があるため、特にクラスター内のインスタンスを可能な限り互いに近づけて構成することをお勧めしますので、ここに示すように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 は同じルートボリュームがありますが、代わりに64GBになるように/dev/xvdf をオーバーライドし、さらに別の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 に設定して、アタッチされたインスタンスが終了したときにボリュームが破壊されないようにします。これがデフォルトの動作です。

物理的に接続された instance store volume 、以前はエフェメラルボリュームと呼ばれていたを使用するようにephemeral: ephemeralN を設定します。使用可能なインスタンスストアボリュームの数、タイプ、およびサイズは、インスタンスタイプによって異なります。すべてのインスタンスにインスタンスストアボリュームがあるわけではありません。インスタンスストアボリュームはテストまたは一時データにのみ使用し、EBSボリュームは重要なデータに使用します。

EBSボリュームの場合、既存のスナップショットからボリュームを接続するようにsnapshot: snap-xxxxxxxx を設定することもできます。十分なデータがS3から読み込まれローカルにキャッシュされるまで、スナップショットから復元されたボリュームは非常に遅くなる場合があります。 (特に、スナップショットからPGDATA を使用して新しいインスタンスをスピンアップできますが、完全なロードを処理する準備が整うまでに数時間かかることが予想されます。

ボリュームにattach_existing: yes を設定し、名前/タイプ/サイズ/iopsと一致する既存の未接続のEBSボリュームが存在する場合、インスタンスの起動時に新しいボリュームは作成されませんが、代わりに既存のボリュームがインスタンスにアタッチされます初めて始まります。再接続されたEBSボリュームは、スナップショットから作成されたボリュームのパフォーマンス制限の影響を受けません。

プラットフォームベア#

TPAは、事前にプロビジョニングされたbare インスタンスにどのボリュームを接続できるかを制御できませんが、適切なdevice_name でvolumes を定義すると、必要に応じてデバイスのmkfs およびmount を処理します。

Platform 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 0のみがAmazonによって推奨されています。同様のコマンドでRAIDボリュームを作成できます。

sudo mdadm --create --verbose /dev/md0 --level=0 --name=MY_RAID --raid-devices=number_of_volumes device_name1 device_name2

この例では、 /dev/md0 という名前のブロックデバイスを接続します。導入中のvolume_for またはmountpoint の処理は、他のボリュームの場合と同じように発生します。 TPAは、mkfs およびmount を処理します。

- Name: one
  …
  volumes:
  - device_name: /dev/md0
    vars:
      volume_for: postgres_data

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デフォルトnoneに渡されるfsopts 、および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が必要とするディレクトリに適切な所有権と権限があることを別途に保証するため、自分で行う必要はありません。

Filesystem configuration

目次