Filesystem configuration
========================

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

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

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

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

.. code:: yaml

   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``
の下の設定は、展開中に使用するためにインベントリに書き込まれます。

..  NOTE ephemeral0 instance store::
   現在、内部ストレージの大部分はNVMeであり、ボリュームがAWSによって自動的に列挙され、デバイス名が割り当てられます。したがって、config.ymlの`device_name` をプロビジョニングフェーズ後に指定されたものに変更する必要がある場合があります。

default_volumes
---------------

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

:ref:`instance_defaults <instance_defaults>` 

このメカニズムでは、ボリューム定義に特別な考慮事項を作成します。大規模なクラスター内のボリューム定義は非常に反復的な場合があるため、特にクラスター内のインスタンスを可能な限り互いに近づけて構成することをお勧めしますので、ここに示すように\ ``default_volumes``
を指定できます。

.. code:: yaml

   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ボリュームをアタッチできます。

.. code:: yaml

   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構成でデフォルトで有効になり、以下で説明する
:ref:`LUKS暗号化 <LUKS暗号化>`  とは異なります。

``delete_on_termination`` を\ ``false``
に設定して、アタッチされたインスタンスが終了したときにボリュームが破壊されないようにします。これがデフォルトの動作です。

物理的に接続された `instance store volume <https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html>`_ 、以前はエフェメラルボリュームと呼ばれていたを使用するように\ ``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コンテナにはボリュームを接続できますが、それらはバインドマウントされたディレクトリであり、通常のブロックデバイスではありません。個別に初期化またはマウントする必要はありません。そのため、構成はかなり異なって見えます。

.. code:: yaml

   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ボリュームを作成できます。

.. code:: shell

   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`` を処理します。

.. code:: yaml


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

LUKS暗号化
----------

TPAは、LUKSで暗号化されたデバイスをセットアップできます。

.. code:: yaml

   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``
で初期化されます。

.. code:: yaml

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