Red Hat Enterprise Linux 8 は、さまざまなファイルシステム (FS) に対応します。さまざまな種類のファイルシステムがさまざまな問題を解決し、その使用はアプリケーションによって異なります。最も一般的なレベルでは、利用可能なファイルシステムを以下の主要なタイプにまとめることができます。

ローカルファイルシステムは、1 台のローカルサーバーで実行し、ストレージに直接接続されているファイルシステムです。

たとえば、ローカルファイルシステムは、内部 SATA ディスクまたは SAS ディスクにおける唯一の選択肢であり、ローカルドライブを備えた内蔵ハードウェア RAID コントローラーがサーバーにある場合に使用されます。ローカルファイルシステムは、SAN にエクスポートされたデバイスが共有されていない場合に、SAN が接続したストレージに最もよく使用されているファイルシステムです。

ローカルファイルシステムはすべて POSIX に準拠しており、サポートされているすべての Red Hat Enterprise Linux リリースと完全に互換性があります。POSIX 準拠のファイルシステムは、read()、write()、seek() など、明確に定義されたシステムコールのセットに対応します。

アプリケーションプログラマーの観点では、ローカルファイルシステム間の違いは比較的少なくなります。ユーザーの観点で最も重要な違いは、スケーラビリティーとパフォーマンスに関するものです。ファイルシステムの選択を検討する際に、ファイルシステムのサイズ、必要な固有の機能、実際のワークロードにおける実行方法を考慮してください。

XFSは、拡張性が高く、高性能で堅牢な、成熟した 64 ビットのジャーナリングファイルシステムで、1 台のホストで非常に大きなファイルおよびファイルシステムに対応します。これは、Red Hat Enterprise Linux 8 のデフォルトのファイルシステムです。XFS は、元々 1990 年代の前半に SGI により開発され、極めて大規模なサーバーおよびストレージアレイで実行されてきた長い歴史があります。

XFS の機能は次のとおりです。

XFS は、シングルスレッドで、メタデータ集約型のワークロードのパフォーマンスが比較的低くなります。たとえば、シングルスレッドで小さなファイルを多数作成し、削除するワークロードがこれに当てはまります。

ext4 ファイルシステムは、ext ファイルシステムファミリーの第 4 世代です。これは、Red Hat Enterprise Linux 6 でデフォルトのファイルシステムです。

ext4 ドライバーは、ext2 および ext3 のファイルシステムの読み取りと書き込みが可能ですが、ext4 ファイルシステムのフォーマットは、ext2 ドライバーおよび ext3 ドライバーと互換性がありません。

ext4 には、以下のような新機能、および改善された機能が追加されました。

エクステントベースのメタデータと遅延割り当て機能は、ファイルシステムで使用されている領域を追跡する、よりコンパクトで効率的な方法を提供します。このような機能により、ファイルシステムのパフォーマンスが向上し、メタデータが使用する領域が低減します。遅延割り当てにより、ファイルシステムは、データがディスクにフラッシュされるまで、新しく書き込まれたユーザーデータの永続的な場所の選択を保留できます。これにより、より大きく、より連続した割り当てが可能になり、より優れた情報に基づいてファイルシステムが決定を下すことができるため、パフォーマンスが向上します。

ext4 で fsck ユーティリティーを使用するファイルシステムの修復時間は、ext2 と ext3 よりも高速です。一部のファイルシステムの修復では、最大 6 倍のパフォーマンスの向上が実証されています。

XFS は、RHEL におけるデフォルトファイルシステムです。このセクションでは、XFS および ext4 の使用方法と機能を比較します。

アプリケーションの要件を満たすファイルシステムを選択するには、ファイルシステムをデプロイするターゲットシステムを理解する必要があります。以下の項目で、選択肢を確認できます。

サーバーとストレージデバイスの両方が大きい場合は、XFS が最適です。ストレージアレイが小さくても、XFS は、平均のファイルサイズが大きい場合 (たとえば、数百メガバイト) に、非常に優れたパフォーマンスを発揮します。

既存のワークロードが ext4 で良好に機能している場合は、ext4 を引き続き使用することで、ユーザーとアプリケーションに非常に馴染みのある環境を提供できます。

ext4 ファイルシステムは、I/O 機能が制限されているシステムでパフォーマンスが向上する傾向があります。限られた帯域幅 (200MB/s 未満) と、最大約 1000 の IOPS 機能でパフォーマンスが向上します。より高い機能を備えたものであれば、XFS はより高速になる傾向があります。

XFS は、ext4 と比較して、メタデータあたりの CPU の動作を約 2 倍消費します。そのため、同時に処理できることがほとんどない、CPU にバインドされたワークロードがあると、ext4 の方が高速になります。通常、アプリケーションが 1 つの読み取り/書き込みスレッドと小さなファイルを使用する場合は ext4 の方が優れていますが、アプリケーションが複数の読み取り/書き込みスレッドと大きなファイルを使用する場合は、XFS の方が優れています。

XFS ファイルシステムを縮小することはできません。ファイルシステムを縮小できるようにする必要がある場合は、オフライン縮小に対応する ext4 を使用することを検討してください。

通常、Red Hat は、ext4 に対する特別なユースケースがない限り、XFS を使用することを推奨します。また、ターゲットサーバーとストレージシステムで特定のアプリケーションのパフォーマンスを測定して、適切なタイプのファイルシステムを選択するようにしてください。

クライアント/サーバーファイルシステムとも呼ばれるネットワークファイルシステムにより、クライアントシステムは、共有サーバーに保存されているファイルにアクセスできます。これにより、複数のシステムの、複数のユーザーが、ファイルやストレージリソースを共有できます。

このようなファイルシステムは、ファイルシステムのセットを 1 つ以上のクライアントにエクスポートする、1 つ以上のサーバーから構築されます。クライアントノードは、基盤となるブロックストレージにアクセスできませんが、より良いアクセス制御を可能にするプロトコルを使用してストレージと対話します。

クラスターファイルシステムとも呼ばれる共有ストレージファイルシステムにより、クラスター内の各サーバーは、ローカルストレージエリアネットワーク (SAN) を介して共有ブロックデバイスに直接アクセスできます。

ネットワークと共有ストレージのファイルシステムのいずれかを選択する際は、以下の点を考慮してください。

Red Hat は、共有ストレージのファイルシステムに対する特別なユースケースがない限り、ネットワークのファイルシステムを使用することを推奨します。共有ストレージのファイルシステムは、主に、最小限のダウンタイムで高可用性サービスを提供する必要があり、サービスレベルの要件が厳しいデプロイメントに使用します。

ボリューム管理ファイルシステムは、簡素化とスタック内の最適化の目的で、ストレージスタック全体を統合します。

storage ロールは以下を管理できます。

storage ロールを使用すると、次のタスクを実行できます。

storage ロールの設定は、以下の変数に記載されているファイルシステム、ボリューム、およびプールにのみ影響します。

本セクションでは、Ansible Playbook の例を紹介します。この Playbook では、storage ロールを適用し、デフォルトパラメーターを使用してブロックデバイスに XFS ファイルシステムを作成します。

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: xfs
  roles:
    - rhel-system-roles.storage

本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage ロールをすぐに適用して、XFS ファイルシステムを永続的にマウントします。

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: xfs
        mount_point: /mnt/data
  roles:
    - rhel-system-roles.storage

本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage ロールを適用して、ボリュームグループに LVM 論理ボリュームを作成します。

- hosts: all
  vars:
    storage_pools:
      - name: myvg
        disks:
          - sda
          - sdb
          - sdc
        volumes:
          - name: mylv
            size: 2G
            fs_type: ext4
            mount_point: /mnt
  roles:
    - rhel-system-roles.storage

本セクションでは、Ansible Playbook の例を紹介します。この Playbook では、storage ロールを適用して、オンラインのブロック破棄を有効にして XFS ファイルシステムをマウントします。

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: xfs
        mount_point: /mnt/data
        mount_options: discard
  roles:
    - rhel-system-roles.storage

本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage ロールを適用して、Ext4 ファイルシステムを作成してマウントします。

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: ext4
        fs_label: label-name
        mount_point: /mnt/data
  roles:
    - rhel-system-roles.storage

本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage ロールを適用して、Ext3 ファイルシステムを作成してマウントします。

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: ext3
        fs_label: label-name
        mount_point: /mnt/data
  roles:
    - rhel-system-roles.storage

本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage ロールを適用して、ブロックデバイスにある既存の Ext4 または Ext3 ファイルシステムのサイズを変更します。

---
- name: Create a disk device mounted on /opt/barefs
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - /dev/sdb
	size: 12 GiB
        fs_type: ext4
        mount_point: /opt/barefs
  roles:
    - rhel-system-roles.storage

---
- name: Create a disk device mounted on /opt/barefs
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - /dev/sdb
	size: 10 GiB
        fs_type: ext4
        mount_point: /opt/barefs
  roles:
    - rhel-system-roles.storage

本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage RHEL システムロールを適用して、ファイルシステムで LVM 論理ボリュームのサイズを変更します。

---

- hosts: all
   vars:
    storage_pools:
      - name: myvg
        disks:
          - /dev/sda
          - /dev/sdb
          - /dev/sdc
        volumes:
            - name: mylv1

            size: 10 GiB
            fs_type: ext4
            mount_point: /opt/mount1
            - name: mylv2
            size: 50 GiB
            fs_type: ext4
            mount_point: /opt/mount2

- name: Create LVM pool over three disks
  incude_role:
    name: rhel-system-roles.storage

本セクションでは、Ansible Playbook の例を紹介します。この Playbook は storage ロールを適用し、デフォルトパラメーターを使用してブロックデバイスにスワップパーティションを作成するか (存在しない場合)、または swap パーティションを変更します (すでに存在する場合)。

---
- name: Create a disk device with swap
- hosts: all
  vars:
    storage_volumes:
      - name: swap_fs
        type: disk
        disks:
          - /dev/sdb
	size: 15 GiB
        fs_type: swap
  roles:
    - rhel-system-roles.storage

storage システムロールを使用すると、Red Hat Ansible Automation Platform を使用して RHEL に RAID ボリュームを設定できます。本セクションでは、要件に合わせて RAID ボリュームを設定するために、利用可能なパラメーターを使用して Ansible Playbook を設定する方法を説明します。

storage システムロールを使用すると、Red Hat Ansible Automation Platform を使用して RHEL に LVM pool with RAID を設定できます。本セクションでは、利用可能なパラメーターを使用して Ansible Playbook を設定し、LVM pool with RAID を設定する方法を説明します。

storage ロールを使用し、Ansible Playbook を実行して、LUKS で暗号化されたボリュームを作成および設定できます。

本セクションでは、NFS サービスの基本概念を説明します。

ネットワークファイルシステム (NFS) を利用すると、リモートのホストがネットワーク経由でファイルシステムをマウントし、そのファイルシステムを、ローカルにマウントしているファイルシステムと同じように操作できるようになります。また、リソースを、ネットワークの集中化サーバーに統合できるようになります。

NFS サーバーは、/etc/exports 設定ファイルを参照して、そのクライアントがエクスポート済みファイルシステムにアクセスできるかどうかを確認します。アクセスが可能なことが確認されると、そのユーザーは、ファイルおよびディレクトリーへの全操作を行えるようになります。

本セクションでは、Red Hat Enterprise Linux でサポートされている NFS のバージョンと、その機能の一覧を紹介します。

現在、Red Hat Enterprise Linux 8 は、以下の NFS のメジャーバージョンに対応しています。

NFS バージョン 2 (NFSv2) は、Red Hat のサポート対象外になりました。

デフォルトの NFS バージョン

Red Hat Enterprise Linux 8 のデフォルトの NFS バージョンは 4.2 です。NFS クライアントは、デフォルトで NFSv4.2 を使用してマウントを試行し、サーバーが NFSv4.2 に対応していない場合は NFSv4.1 にフォールバックします。マウントは後で NFSv4.0 に戻り、次に NFSv3 に戻ります。

NFS のマイナーバージョンの機能

以下は、Red Hat Enterprise Linux 8 における NFSv4.2 の機能です。

NFSv4.1 の機能は次のとおりです。

本セクションでは、NFS サーバーの実行または NFS 共有のマウントに必要なシステムサービスの一覧を紹介します。Red Hat Enterprise Linux は、このサービスを自動的に開始します。

Red Hat Enterprise Linux では、NFS ファイル共有を提供するのに、カーネルレベルのサポートとサービスのプロセスの組み合わせを使用します。NFS のすべてのバージョンは、クライアントとサーバーとの間の RPC (Remote Procedure Call) に依存します。NFS ファイルシステムの共有やマウントには、実装されている NFS のバージョンに応じて、次のようなサービスが連携して動作することになります。

NFSv4 を使用する RPC サービス

NFSv4 プロトコルには、マウントとロックのプロトコルが組み込まれています。サーバーは、既知の TCP ポート 2049 もリッスンします。そのため、NFSv4 は rpcbind サービス、lockd サービス、および rpc-statd サービスと対話する必要はありません。nfs-mountd サービスは、エクスポートを設定するために NFS サーバーで引き続き必要となりますが、ネットワーク上の操作には関与しません。

本セクションでは、NFS 共有をマウントまたはエクスポートするときにホストの指定に使用するさまざまな形式を説明します。

次の形式でホストを指定できます。

この手順では、NFS 共有のマウントまたはエクスポートに必要なすべてのパッケージをインストールします。

この手順では、特定の NFSv3 または NFSv4 サーバーがエクスポートしているファイルシステムを検出します。

NFSv4 と NFSv3 の両方に対応するサーバーでは、上記の方法はいずれも有効で、同じ結果となります。

この手順では、mount ユーティリティーを使用して、サーバーからエクスポートされた NFS 共有をマウントします。

本セクションでは、NFS 共有をマウントするときに一般的に使用されるオプションの一覧を紹介します。これらのオプションは、手動のマウントコマンド、/etc/fstab 設定、autofs と併用できます。

本セクションでは、NFS サービスの基本概念を説明します。

ネットワークファイルシステム (NFS) を利用すると、リモートのホストがネットワーク経由でファイルシステムをマウントし、そのファイルシステムを、ローカルにマウントしているファイルシステムと同じように操作できるようになります。また、リソースを、ネットワークの集中化サーバーに統合できるようになります。

NFS サーバーは、/etc/exports 設定ファイルを参照して、そのクライアントがエクスポート済みファイルシステムにアクセスできるかどうかを確認します。アクセスが可能なことが確認されると、そのユーザーは、ファイルおよびディレクトリーへの全操作を行えるようになります。

本セクションでは、Red Hat Enterprise Linux でサポートされている NFS のバージョンと、その機能の一覧を紹介します。

現在、Red Hat Enterprise Linux 8 は、以下の NFS のメジャーバージョンに対応しています。

NFS バージョン 2 (NFSv2) は、Red Hat のサポート対象外になりました。

デフォルトの NFS バージョン

Red Hat Enterprise Linux 8 のデフォルトの NFS バージョンは 4.2 です。NFS クライアントは、デフォルトで NFSv4.2 を使用してマウントを試行し、サーバーが NFSv4.2 に対応していない場合は NFSv4.1 にフォールバックします。マウントは後で NFSv4.0 に戻り、次に NFSv3 に戻ります。

NFS のマイナーバージョンの機能

以下は、Red Hat Enterprise Linux 8 における NFSv4.2 の機能です。

NFSv4.1 の機能は次のとおりです。

NFSv4 は、IP ネットワークで TCP (Transmission Control Protocol) の実行が必要です。

NFSv3 は、Red Hat Enterprise Linux の以前のバージョンで User Datagram Protocol (UDP) を使用することもできます。Red Hat Enterprise Linux 8 では、NFS over UDP に対応しなくなりました。デフォルトでは、UDP は、NFS サーバーで無効になります。

本セクションでは、NFS サーバーの実行または NFS 共有のマウントに必要なシステムサービスの一覧を紹介します。Red Hat Enterprise Linux は、このサービスを自動的に開始します。

Red Hat Enterprise Linux では、NFS ファイル共有を提供するのに、カーネルレベルのサポートとサービスのプロセスの組み合わせを使用します。NFS のすべてのバージョンは、クライアントとサーバーとの間の RPC (Remote Procedure Call) に依存します。NFS ファイルシステムの共有やマウントには、実装されている NFS のバージョンに応じて、次のようなサービスが連携して動作することになります。

NFSv4 を使用する RPC サービス

NFSv4 プロトコルには、マウントとロックのプロトコルが組み込まれています。サーバーは、既知の TCP ポート 2049 もリッスンします。そのため、NFSv4 は rpcbind サービス、lockd サービス、および rpc-statd サービスと対話する必要はありません。nfs-mountd サービスは、エクスポートを設定するために NFS サーバーで引き続き必要となりますが、ネットワーク上の操作には関与しません。

本セクションでは、NFS 共有をマウントまたはエクスポートするときにホストの指定に使用するさまざまな形式を説明します。

次の形式でホストを指定できます。

本セクションでは、NFS サーバーでエクスポートを構成する 2 種類の構文およびオプションを説明します。

export host(options)

export host1(options1) host2(options2) host3(options3)

/exported/directory bob.example.com

/home bob.example.com(rw)
/home bob.example.com (rw)

/another/exported/directory 192.168.0.3(rw,async)

本セクションでは、NFSv3 で必要とされる rpcbind サービスの目的を説明します。

rpcbind サービスは、RPC (Remote Procedure Call) サービスを、そのサービスがリッスンするポートにマッピングします。RPC のプロセスが開始すると、その開始が rpcbind に通知され、そのプロセスがリッスンしているポートと、そのプロセスが処理することが予想される RPC プログラム番号が登録されます。クライアントシステムは、特定の RPC プログラム番号でサーバーの rpcbind と通信します。rpcbind サービスは、クライアントを適切なポート番号にリダイレクトし、要求されたサービスと通信できるようにします。

RPC ベースのサービスは、rpcbind を使用して、クライアントの受信要求で接続を確立します。したがって、RPC ベースのサービスが起動する前に、rpcbind を利用可能な状態にする必要があります。

rpcbind のアクセス制御ルールは、すべての RPC ベースのサービスに影響します。あるいは、NFS RPC デーモンごとにアクセス制御ルールを指定することもできます。

この手順では、NFS 共有のマウントまたはエクスポートに必要なすべてのパッケージをインストールします。

この手順では、NFS 共有をエクスポートするために必要な NFS サーバーの起動方法を説明します。

rpcbind サービスでは通信に使用するポート番号と RPC サービス間の調整を行うため、トラブルシューティングを行う際は、rpcbind を使用して現在の RPC サービスの状態を表示させると便利です。rpcinfo ユーティリティーは、RPC ベースの各サービスとそのポート番号、RPC プログラム番号、バージョン番号、および IP プロトコルタイプ (TCP または UDP) が表示されます。

NFS には rpcbind サービスが必要です。このサービスは RPC サービスのポートを動的に割り当て、ファイアウォールルールの設定で問題が発生する可能性があります。この手順では、ファイアウォールの内側で機能するように NFS サーバーを設定する方法を説明します。

ディスククォータを使用するファイルシステムをエクスポートする場合は、クォータの RPC (Remote Procedure Call) サービスを使用して、NFS クライアントにディスククォータデータを提供できます。

Red Hat Enterprise Linux 8 では、RDMA に対応するハードウェアが存在すると、RDMA (remote direct memory access) サービスが自動的に有効になります。

NFS サーバー管理者は、NFSv4 にのみ対応するように NFS サーバーを設定できます。これにより、システムで開いているポートの数と実行中のサービスの数が最小限に抑えられます。

Requested NFS version or transport protocol is not supported.

NFS は、エクスポートしたファイルへのアクセスを制御するために、以下の従来のオプションを提供します。

潜在的なリスクを制限するため、多くの場合、管理者は、共通のユーザー ID およびグループ ID に対して、ユーザー権限を読み取り専用にするか、権限を下げてアクセスを制限します。ただし、このソリューションにより、NFS 共有が元々想定されている方法では使用されなくなります。

さらに、攻撃者が、NFS ファイルシステムをエクスポートするシステムが使用する DNS サーバーを制御できた場合は、特定のホスト名または完全修飾ドメイン名に関連付けられたシステムを、承認されていないマシンに指定できます。これで、認証されていないマシンは、NFS 共有のマウントを許可するシステムになります。これは、ユーザー名やパスワードの情報が交換されず、NFS マウントに追加のセキュリティーが提供されるためです。

NFS 経由でディレクトリーのエクスポートを行う際にワイルドカードを使用する場合は慎重に行ってください。ワイルドカードの対象が予定よりも広い範囲のシステムを対象とする可能性があります。

NFS の全バージョンは、RPCSEC_GSS および Kerberos のメカニズムに対応します。

AUTH_SYS とは異なり、RPCSEC_GSS Kerberos メカニズムでは、サーバーは、どのユーザーがそのファイルにアクセスしているかを正確に表すことをクライアントに依存しません。代わりに、暗号を使用してサーバーにユーザーを認証し、悪意のあるクライアントがそのユーザーの Kerberos 認証情報を持たずにユーザーになりすますことがないようにします。RPCSEC_GSS Kerberos メカニズムを使用することが、マウントを保護する最も簡単な方法になります。Kerberos の設定後は、追加の設定が不要になるためです。

Kerberos はネットワーク認証システムであり、対称暗号化と、信頼できるサードパーティー (KDC) を使用してクライアントとサーバーが相互に認証できるようにします。Red Hat では、Kerberos の設定に Identity Management (IdM) を使用することを推奨します。

NFSv4 には、Microsoft Windows NT モデルの機能や幅広い導入の経緯があるため、POSIX モデルではなく、Microsoft Windows NT モデルをベースとした ACL サポートが含まれます。

NFSv4 のもう 1 つの重要なセキュリティー機能は、ファイルシステムのマウントに MOUNT プロトコルを使用しなくなることです。MOUNT プロトコルは、プロトコルがファイルを処理する方法により、セキュリティー上のリスクが発生します。

リモートホストにより NFS ファイルシステムを読み取りまたは読み書きとしてマウントした場合は、パーティションが、各共有ファイルに対する唯一の保護となります。同じユーザー ID の値を共有する 2 つのユーザーが、異なるクライアントシステムに同じ NFS ファイルシステムをマウントすると、そのユーザーは互いのファイルを修正できるようになります。また、クライアントシステムで root としてログインした場合は、su - コマンドを使用して、NFS 共有が設定されたファイルにアクセスできます。

デフォルトでは、アクセス制御リスト (ACL) は、Red Hat Enterprise Linux では NFS が対応しています。Red Hat では、この機能を有効にしておくことを推奨します。

デフォルトでは、NFS がファイルシステムをエクスポートする際に、root squashing を使用します。これにより、NFS 共有にアクセスするユーザーのユーザー ID が、ローカルマシンの root ユーザーとして nobody に設定されます。root squashing は、デフォルトのオプション root_squash で制御されます。このオプションの詳細は、「NFS サーバーの設定」 を参照してください。

NFS 共有を読み取り専用としてエクスポートする場合は、all_squash オプションの使用を検討してください。このオプションでは、エクスポートしたファイルシステムにアクセスするすべてのユーザーが、nobody ユーザーのユーザー ID を取得します。

pNFS アーキテクチャーでは、NFS のスケーラビリティーが改善されます。サーバーに pNFS が実装されると、クライアントは複数のサーバーで同時にデータにアクセスできるようになります。これにより、パフォーマンスが向上します。

pNFS は、RHEL では以下のストレージプロトコルまたはレイアウトに対応しています。

SCSI レイアウトは、pNFS ブロックレイアウトの作業に基づいています。このレイアウトは、SCSI デバイス全体に定義されます。これには、SCSI 永続予約に対応する必要がある論理ユニット (lUS) として、固定サイズのブロックが連続的に含まれています。LU デバイスは、SCSI デバイスの識別子で識別されます。

pNFS SCSI は、ファイルへの長期接続のシングルクライアントアクセスのユースケースで適切に実行されます。例として、メールサーバーまたはクラスターを格納している仮想マシンなどが挙げられます。

クライアントとサーバーとの間の操作

NFS クライアントが、ファイルからの読み取り、またはファイルへの書き込みを行うと、クライアントは LAYOUTGET 操作を実行します。サーバーは、SCSI デバイスのファイルの場所に反応します。このクライアントは、使用する SCSI デバイスを判断するために、GETDEVICEINFO の追加操作が必要になる場合があります。正しく動作するのであれば、クライアントは、READ 操作および WRITE 操作をサーバーに送信する代わりに、SCSI デバイスに直接 I/O 要求を発行することができます。

クライアント間のエラーまたは競合により、サーバーがレイアウトを再び呼び出したり、クライアントにレイアウトを発行しなくなることがあります。この場合、クライアントは SCSI デバイスに I/O 要求を直接送信するのではなく、サーバーへの READ 操作および WRITE 操作の発行にフォールバックします。

操作を監視するには、「pNFS SCSI レイアウト機能の監視」 を参照してください。

デバイスの予約

pNFS SCSI は、予約の割り当てを通じてフェンシングを処理します。サーバーがレイアウトをクライアントに発行する前に、SCSI デバイスを予約して、登録したクライアントのみがデバイスにアクセスできるようにします。クライアントが、その SCSI デバイスに対してコマンドを実行できても、そのデバイスに登録されていない場合は、クライアントからの多くの操作が、そのデバイス上で失敗します。たとえば、サーバーが、そのデバイスのレイアウトをクライアントに送信していないと、クライアントの blkid コマンドは、XFS ファイルシステムの UUID を表示できません。

サーバーは、独自の永続予約を削除しません。これにより、クライアントやサーバーの再起動時に、デバイスのファイルシステム内のデータが保護されます。SCSI デバイスを他の目的で使用するには、NFS サーバーで、手動で永続予約を削除する必要があります。

この手順では、SCSI デバイスが pNFS SCSI レイアウトに対応しているかどうかを確認します。

この手順では、NFS サーバーが pNFS SCSI レイアウトをエクスポートするように設定します。

この手順では、pNFS SCSI レイアウトをマウントするように NFS クライアントを設定します。

この手順では、NFS サーバーが SCSI デバイスを維持している永続的な予約を解放します。これにより、pNFS SCSI をエクスポートする必要がなくなったら、SCSI デバイスを別の目的で使用できるようになります。

サーバーから予約を削除する必要があります。別の IT Nexus から削除することはできません。

pNFS クライアントとサーバーで、pNFS SCSI 操作が適切に行われることを犠牲にしているかどうか、または通常の NFS 操作にフォールバックするかどうかを監視できます。

以下の図は、FS-Cache の仕組みの概要を示しています。

図7.1 FS-Cache の概要

FS-Cache は、システムのユーザーおよび管理者が可能な限り透過的になるように設計されています。Solaris では cachefs とは異なり、サーバー上のファイルシステムは、オーバーマウントしたファイルシステムを作成せずに、クライアントのローカルキャッシュと直接対話できます。NFS では、マウントオプションにより、FS-cache が有効になっている NFS 共有をマウントするようにクライアントに指示します。マウントポイントにより、fscache と cachefiles の 2 つのカーネルモジュールの自動アップロードが実行します。cachefilesd デーモンは、カーネルモジュールと通信してキャッシュを実装します。

FS-Cache はネットワーク上で機能するファイルシステムの基本操作を変更せず、単にデータをキャッシュできる永続的な場所でファイルシステムを提供するだけです。たとえば、クライアントは FS-Cache が有効になっているかどうかに関わらず、NFS 共有をマウントできます。さらに、キャッシュされた NFS は、ファイルが部分的にキャッシュされ、事前完全に読み込む必要がないため、ファイル (個別または一括) に収まらないファイルを処理できます。また、FS-Cache は、クライアントファイルシステムドライバーからキャッシュで発生するすべての I/O エラーも非表示にします。

キャッシングサービスを提供するには、キャッシュバックエンド が必要です。キャッシュバックエンドは、cachefiles であるキャッシングサービスを提供するように設定されたストレージドライバーです。この場合、FS-Cache では、キャッシュバックエンドとして bmap および拡張属性 (ext3 など) に対応するブロックベースのファイルシステムをマウントする必要があります。

FS-Cache のキャッシュバックエンドで必要とされる機能に対応するファイルシステムには、以下のファイルシステムの Red Hat Enterprise Linux 8 実装が含まれます。

FS-Cache は、ネットワークを介するかどうかに関係なく、ファイルシステムを任意にキャッシュすることはできません。共有ファイルシステムのドライバーを変更して、FS-Cache、データストレージ/検索、メタデータのセットアップと検証を操作できるようにする必要があります。FS-Cache では、永続性に対応するためにキャッシュされたファイルシステムの インデックスキー と 一貫性データ が必要になります。インデックスキーはファイルシステムオブジェクトをキャッシュオブジェクトに一致させ、一貫性データを使用してキャッシュオブジェクトが有効のままかどうかを判断します。

FS-Cache は、パフォーマンスの向上を 保証しません。キャッシュを使用するとパフォーマンスが低下します。たとえば、キャッシュされた NFS 共有では、ネットワーク間のルックアップにディスクアクセスが追加されます。FS-Cache は可能な限り非同期となりますが、これができない同期パス (読み込みなど) があります。

たとえば、FS-Cache を使用して、通常は負荷のない GigE ネットワークを介して 2 台のコンピューター間の NFS 共有をキャッシュしても、ファイルアクセスのパフォーマンスは向上しない可能性があります。代わりに、NFS 要求はローカルディスクからではなく、サーバーメモリーより早く満たされます。

したがって、FS-Cacheの使用は、さまざまな要因における 妥協 です。たとえば、NFS トラフィックのキャッシュに FS-Cache を使用すると、クライアントは多少遅くなりますが、ネットワークの帯域幅を消費せずにローカルに読み取り要求を満たすことでネットワークおよびサーバーの読み込み負荷が大幅に削減されます。

現在、Red Hat Enterprise Linux 8 は cachefiles キャッシュバックエンドのみを提供します。cachefilesd デーモンは cachefiles を開始し、管理します。/etc/cachefilesd.conf ファイルは、cachefiles によるキャッシュサービスの提供方法を制御します。

キャッシュバックエンドは、キャッシュをホストしているパーティション上の一定の空き領域を維持することで動作します。空き領域を使用する他の要素に応じてキャッシュを増大および縮小し、root ファイルシステム (ラップトップなど) で安全に使用できるようにします。FS-Cache ではこの動作でデフォルト値を設定します。これは、キャッシュカリング制限 で設定できます。キャッシュカリング制限の設定に関する詳細は、「キャッシュカリング制限の設定」 を参照してください。

この手順では、キャッシュを設定する方法を説明します。

明示的に指示されない限り、NFS はキャッシュを使用しません。ここでは、FS-Cache を使用して NFS マウントを設定する方法を説明します。

NFS バージョン 3、4.0、4.1、および 4.2 はキャッシュに対応します。ただし、各バージョンはキャッシュに異なるブランチを使用します。

cachefilesd デーモンは、共有ファイルシステムからのリモートデータをキャッシュして、ディスクの空き領域を解放することで機能します。これにより、利用可能な空き領域がすべて消費される可能性があり、ディスクがルートパーティションも格納している場合は問題になる可能性があります。これを制御するために、cachefilesd は古いオブジェクト (つまり最近のアクセスが少ないオブジェクト) をキャッシュから破棄して、一定量の空き領域を維持しようとします。この動作は キャッシュカリング と呼ばれます。

キャッシュカリングは、基盤となるファイルシステムで使用可能なブロックのパーセンテージとファイルのパーセンテージに基づいて行われます。/etc/cachefilesd.conf には、6 つの制限を制御する設定が存在します。

各設定の N のデフォルト値は以下の通りです。

この設定を行う場合は、以下の条件を満たす必要があります。

これは、空き領域と利用可能なファイルの割合であり、100 から、df プログラムで表示される割合を引いたものではありません。

FS-Cache は一般的な統計情報も追跡します。以下の手順では、この情報を取得する方法を説明します。

FS-Cache の統計にはディシジョンポイントとオブジェクトカウンターに関する情報が含まれます。詳細は、以下のカーネルドキュメントを参照してください。

/usr/share/doc/kernel-doc-4.18.0/Documentation/filesystems/caching/fscache.txt

本セクションでは、FS-Cache の参考情報を詳細します。

cifs.ko カーネルモジュールは、以下の SMB プロトコルバージョンをサポートします。

Samba は、SMB プロトコルの CAP_UNIX 機能ビットを使用して UNIX 拡張機能を提供します。これらの拡張機能は、cifs.ko カーネルモジュールでも対応します。ただし、Samba とカーネルモジュールはいずれも、SMB 1 プロトコルでのみ UNIX 拡張機能に対応します。

UNIX 拡張機能を使用するには、以下の手順を実行します。

UNIX 拡張機能が有効になっているかどうかを確認するには、マウントされた共有のオプションを表示します。

# mount
...
//server/share on /mnt type cifs (...,unix,...)

マウントオプションの一覧に unix エントリーが表示されている場合は、UNIX 拡張機能が有効になっています。

SMB 共有のみを一時的にマウントする必要がある場合は、mount ユーティリティーを使用して手動でマウントできます。

# mount -t cifs -o username=user_name //server_name/share_name /mnt/
Password for user_name@//server_name/share_name:  password

-o パラメーターでは、共有のマウントに使用されるオプションを指定できます。詳細は、man ページの mount.cifs(8) の 「よく使用されるマウントオプション」 と OPTIONS セクションを参照してください。

# mount -t cifs -o username=DOMAIN\Administrator,seal,vers=3.0 //server/example /mnt/
Password for DOMAIN\Administrator@//server_name/share_name:  password

マウントされた SMB 共有へのアクセスがサーバー上で恒久的に必要とされる場合は、システムの起動時に共有を自動的にマウントします。

//server_name/share_name  /mnt  cifs  credentials=/root/smb.cred  0 0

/etc/fstab の行の 4 つ目のフィールドで、認証情報ファイルへのパスなど、マウントオプションを指定します。詳細は、man ページの mount.cifs(8) の 「よく使用されるマウントオプション」 と OPTIONS セクションを参照してください。

共有が正常にマウントされたことを確認する場合は、次のコマンドを実行します。

# mount /mnt/

特定の状況 (システムの起動時に共有を自動的にマウントする場合など) では、ユーザー名とパスワードを入力することなく共有がマウントされる必要があります。これを実装するには、認証情報ファイルを作成します。

mount ユーティリティーに credentials=file_name マウントオプションを渡すか、/etc/fstab ファイルでオプションを使用して、ユーザー名とパスワードの入力を求められずに共有をマウントできます。

共有をマウントするために指定した認証情報により、デフォルトでマウントポイントのアクセス権が決まります。たとえば、共有をマウントするときに DOMAIN\example ユーザーを使用した場合は、どのローカルユーザーが操作を実行しても、共有に対するすべての操作はこのユーザーとして実行されます。

ただし特定の状況では、システムの起動時に管理者が自動的に共有をマウントしたい場合でも、ユーザーは自分の認証情報を使用して共有のコンテンツに対して操作を実行する必要があります。このとき、multiuser マウントオプションを使用すると、このシナリオを設定できます。

root ユーザーは、multiuser オプションと、共有内のコンテンツへの最低限のアクセスを持つアカウントを使用して、共有をマウントします。通常のユーザーは、cifscreds ユーティリティーを使用して、現在のセッションのカーネルキーリングに、自身のユーザー名とパスワードを渡すことができます。マウントされた共有のコンテンツにユーザーがアクセスすると、カーネルは、共有のマウントに最初に使用されたものではなく、カーネルキーリングからの認証情報を使用します。

この機能の使用は、以下の手順で構成されます。

# mount
...
//server_name/share_name on /mnt type cifs (sec=ntlmssp,multiuser,...)

# cifscreds add -u SMB_user_name server_name
Password: password

SMB 共有をマウントすると、マウントオプションにより次のことが決まります。

/etc/fstab ファイルの 4 番目のフィールド、またはマウントコマンドの -o パラメーターで複数のオプションを設定するには、オプションをカンマで区切ります。たとえば、「multiuser オプションを使用した共有のマウント」 を参照してください。

次のリストは、よく使用されるマウントオプションを示しています。

完全なリストは、man ページの mount.cifs(8) の OPTIONS セクションを参照してください。

Red Hat Enterprise Linux では、ストレージデバイスを識別する方法が複数あります。特にドライブへのインストール時やドライブの再フォーマット時に誤ったデバイスにアクセスしないようにするため、適切なオプションを使用して各デバイスを識別することが重要になります。

従来、/dev/sd(メジャー番号)(マイナー番号) の形式の非永続的な名前は、ストレージデバイスを参照するために Linux 上で使用されます。メジャー番号とマイナー番号の範囲、および関連する sd 名は、検出されると各デバイスに割り当てられます。つまり、デバイスの検出順序が変わると、メジャー番号とマイナー番号の範囲、および関連する sd 名の関連付けが変わる可能性があります。

このような順序の変更は、以下の状況で発生する可能性があります。

そのため、/etc/fstab ファイルなどにあるデバイスを参照するときにメジャー番号およびマイナー番号の範囲や関連する sd 名を使用することは望ましくありません。誤ったデバイスがマウントされ、データが破損する可能性があります。

しかし、場合によっては他のメカニズムが使用される場合でも sd 名の参照が必要になる場合もあります (デバイスによりエラーが報告される場合など)。これは、Linux カーネルはデバイスに関するカーネルメッセージで sd 名 (および SCSI ホスト、チャネル、ターゲット、LUN タプル) を使用するためです。

このセクションでは、ファイルシステムおよびブロックデバイスを識別する永続的な属性の相違点を説明します。

ファイルシステムの識別子

ファイルシステムの識別子は、ブロックデバイス上に作成された特定のファイルシステムに関連付けられます。識別子はファイルシステムの一部としても格納されます。ファイルシステムを別のデバイスにコピーしても、ファイルシステム識別子は同じです。一方、mkfs ユーティリティーでフォーマットするなどしてデバイスを書き換えると、デバイスはその属性を失います。

ファイルシステムの識別子に含まれるものは、次のとおりです。

デバイスの識別子

デバイス識別子は、ブロックデバイス (ディスクやパーティションなど) に関連付けられます。mkfs ユーティリティーでフォーマットするなどしてデバイスを書き換えた場合、デバイスはファイルシステムに格納されていないため、属性を保持します。

デバイスの識別子に含まれるものは、次のとおりです。

推奨事項

このセクションでは、udev サービスが /dev/disk/ ディレクトリーで提供する、さまざまな種類の永続的な命名属性を説明します。

udev メカニズムは、ストレージデバイスだけでなく、Linux のすべてのタイプのデバイスに使用されます。ストレージデバイスの場合、Red Hat Enterprise Linux には /dev/disk/ ディレクトリーにシンボリックリンクを作成する udev ルールが含まれています。これにより、次の方法でストレージデバイスを参照できます。

udev の命名属性は永続的なものですが、システムを再起動しても自動的には変更されないため、設定可能なものもあります。

/dev/disk/by-uuid/3e6be9de-8139-11d1-9106-a43f08d823a6

UUID=3e6be9de-8139-11d1-9106-a43f08d823a6

/dev/disk/by-label/Boot

LABEL=Boot

このセクションでは、Device Mapper Multipath 構成における World Wide Identifier (WWID) と非永続的なデバイス名のマッピングを説明します。

システムからデバイスへのパスが複数ある場合、DM Multipath はこれを検出するために WWID を使用します。その後、DM Multipath は /dev/mapper/wwid ディレクトリー (例: /dev/mapper/3600508b400105df70000e00000ac0000) に単一の「疑似デバイス」を表示します。

コマンド multipath -l は、非永続的な識別子へのマッピングを示します。

3600508b400105df70000e00000ac0000 dm-2 vendor,product
[size=20G][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=0][active]
 \_ 5:0:1:1 sdc 8:32  [active][undef]
 \_ 6:0:1:1 sdg 8:96  [active][undef]
\_ round-robin 0 [prio=0][enabled]
 \_ 5:0:0:1 sdb 8:16  [active][undef]
 \_ 6:0:0:1 sdf 8:80  [active][undef]

DM Multipath は、各 WWID ベースのデバイス名から、システムで対応する /dev/sd 名への適切なマッピングを自動的に維持します。これらの名前は、パスが変更しても持続し、他のシステムからデバイスにアクセスする際に一貫性を保持します。

DM Multipath の user_friendly_names 機能を使用すると、WWID は /dev/mapper/mpathN 形式の名前にマップされます。デフォルトでは、このマッピングは /etc/multipath/bindings ファイルに保持されています。これらの mpathN 名は、そのファイルが維持されている限り永続的です。

udev 命名規則の制約の一部は次のとおりです。

この手順では、非永続的なストレージデバイスの永続命名属性を確認する方法を説明します。

この手順では、ファイルシステムの UUID またはラベルの永続的な命名属性を変更する方法を説明します。

以下のコマンドでは、次を行います。

システム管理者は、ブロックデバイスのパーティションテーブルを表示して、パーティションレイアウトと個々のパーティションに関する詳細を確認できます。

Model: ATA SAMSUNG MZNLN256 (scsi)
Disk /dev/sda: 256GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type      File system  Flags
 1      1049kB  269MB   268MB   primary   xfs          boot
 2      269MB   34.6GB  34.4GB  primary
 3      34.6GB  45.4GB  10.7GB  primary
 4      45.4GB  256GB   211GB   extended
 5      45.4GB  256GB   211GB   logical

システム管理者は、ブロックデバイスでパーティションを使用できるように、さまざまな種類のパーティションテーブルを使用してそのブロックデバイスをフォーマットできます。

10.2.3. MBR ディスクパーティション

本章の図では、パーティションテーブルが実際のディスクから分離されていることを示しています。ただし、これは完全に正確ではありません。実際には、パーティションテーブルは、ファイルシステムまたはユーザーデータの前のディスクの先頭に保管されますが、明確にするために以下の図で区切ります。

図10.1 MBR パーティションテーブルがあるディスク

上記の図で示したとおり、パーティションテーブルは 4 つのプライマリーパーティションの 4 つのセクションに分けられます。プライマリーパーティションは、論理ドライブ (またはセクション) を 1 つだけ含むことができるハードドライブのパーティションです。各セクションは、1 つのパーティションの定義に必要な情報を保持できます。つまり、パーティションテーブルでは 4 つのパーティションを定義できません。

各パーティションテーブルエントリーには、パーティションの重要な特徴がいくつか含まれています。

• パーティションが開始して終了するディスク上のポイント。
• パーティションが アクティブ であるかどうか。アクティブ としてフラグを付けることができるパーティションは 1 つだけです。
• パーティションのタイプ。

開始点と終了点は、パーティションのサイズとディスク上の場所を定義します。「active」フラグは、一部のオペレーティングシステムブートローダーで使用されます。つまり、「active」とマークされているパーティションのオペレーティングシステムが起動します。

タイプは、パーティションの想定される使用方法を特定する数字です。一部のオペレーティングシステムでは、パーティションの種類を使用して特定のファイルシステムの種類を示し、特定のオペレーティングシステムに関連付けられていることを示すフラグを付け、パーティションに起動可能なオペレーティングシステムが含まれていること、またはその 3 つの組み合わせを示します。

以下の図は、パーティションが 1 つあるドライブの例を示しています。

図10.2 1 つのパーティションを持つディスク

この例の 1 つのパーティションには、DOS というラベルが付けられています。このラベルはパーティションタイプを表示し、DOS は最も一般的なパーティションタイプです。

10.2.4. 拡張 MBR パーティション

4 つのパーティションがニーズに十分ではない場合は、拡張パーティションを使用して追加のパーティションを作成できます。これは、パーティションのタイプを「拡張」に設定することで実行できます。

拡張パーティションは、それ自体がディスクドライブのようなものです。拡張パーティション自体に完全に含まれる、1 つ以上のパーティション (4 つのプライマリパーティションではなく、現在は論理パーティションと呼ばれます) を指す独自のパーティションテーブルがあります。次の図は、1 つのプライマリパーティションと、2 つの論理パーティションを含む 1 つの拡張パーティション (およびいくつかの未パーティションの空き領域) を備えたディスクドライブを示しています。

図10.3 プライマリーパーティションと拡張 MBR パーティションの両方を備えたディスク

この図は示すように、プライマリーパーティションと論理パーティションには違いがあります。最大 4 つのプライマリーパーティションと拡張パーティションしか存在できませんが、存在できる論理パーティションの数には固定制限がありません。ただし、Linux でパーティションにアクセスする方法により、1 つのディスクドライブで 15 を超える論理パーティションを定義することはできません。

10.2.6. GUID パーティションテーブル

GUID パーティションテーブル (GPT) は、Globally Unique Identifier (GUID) を使用したパーティション設定スキームです。GPT は、特にディスクのアドレス可能な最大ストレージ容量に制限されている MBR パーティションテーブルの制限に対応するために開発されました。MBR とは異なり、2 TiB (約 2.2 TB に相当) を超えるストレージに対応できません。GPT はこれよりも大きなハードディスクで使用されます。アドレス可能な最大ディスクサイズは 2.2 ZiB です。また、デフォルトでは GPT は、最大 128 のプライマリーパーティションの作成に対応します。この数は、パーティションテーブルにより多くの領域を割り当てることで拡張できます。

注記

GPT には GUID に基づくパーティションタイプがあります。特定のパーティションには特定の GUID が必要なことに注意してください。たとえば、EFI ブートローダーのシステムパーティションには GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B が必要です。

GPT ディスクは論理ブロックアドレス設定 (LBA) を使用し、パーティションレイアウトは以下のようになります。

• MBR ディスクとの後方互換性を維持するために、GPT の最初のセクター (LBA 0) は MBR データ用に予約され、「保護 MBR」と呼ばれます。
• プライマリー GPT ヘッダーは、デバイスの 2 番目の論理ブロック (LBA 1) から開始します。ヘッダーには、ディスク GUID、プライマリーパーティションテーブルの場所、セカンダリ GPT ヘッダーの場所、および CRC32 チェックサム、およびプライマリーパーティションテーブルが含まれます。また、テーブルにあるパーティションエントリーの数も指定します。
• プライマリー GPT には、デフォルトの 128 パーティションエントリーがあり、それぞれエントリーサイズは 128 バイトで、パーティションタイプ GUID と一意のパーティション GUID が含まれます。
• セカンダリー GPT はプライマリー GPT と同じです。これは、プライマリーパーティションテーブルが破損した場合に、リカバリーのバックアップテーブルとして主に使用されます。
• セカンダリー GPT ヘッダーは、ディスクの最後の論理セクターにあり、プライマリーヘッダーが破損した場合に GPT 情報を復元するために使用できます。これには、ディスク GUID、セカンダリーパーティションテーブルとプライマリー GPT ヘッダーの場所、それ自体とセカンダリーパーティションテーブルの CRC32 チェックサム、および可能なパーティションエントリーの数が含まれています。

図10.4 GUID パーティションテーブルを含むディスク

重要

GPT (GUIDパーティションテーブル) を含むディスクにブートローダーを正常にインストールするには、BIOS ブートパーティションが必要です。これには、Anaconda によって初期化されるディスクが含まれます。ディスクに BIOS ブートパーティションがすでに含まれている場合は、再使用できます。

システム管理者は、ディスクに新しいパーティションを作成できます。

システム管理者は、ディスク領域を解放するのに使用されなくなったディスクパーティションを削除できます。

システム管理者は、パーティションを拡張して未使用のディスク容量を利用したり、パーティションを縮小して、作成した容量をさまざまな目的に使用できます。

ディスクを再パーティションする方法は複数あります。本セクションでは、以下のアプローチについて説明します。

本セクションでは、前述の概念について理論的にのみ説明し、ディスクのパーティションの再作成を段階的に実行する手順については説明しません。

10.6.1. パーティションが分割されていない空き領域の使用

このような場合、すでに定義されているパーティションはハードディスク全体にまたがらないため、定義されたパーティションには含まれない未割り当ての領域が残されます。次の図は、これがどのようになるかを示しています。

図10.5 パーティションが分割されていない空き領域があるディスク

上記の例では、最初の図は、1 つのプライマリーパーティションを持つディスクと、未割り当ての領域を持つ未定義のパーティションを表し、2 つ目の図は、領域が割り当てられた 2 つの定義されたパーティションを持つディスクを表します。

未使用のハードディスクもこのカテゴリーに分類されます。唯一の違いは、すべて の領域が定義されたパーティションの一部ではないことです。

いずれの場合も、未使用の領域から必要なパーティションを作成できます。このシナリオは、ほとんどの場合は新しいディスクに適しています。ほとんどのオペレーティングシステムは、ディスクドライブ上の利用可能な領域をすべて取得するように設定されています。

10.6.2. 未使用パーティションの領域の使用

この場合は、使用されなくなったパーティションを 1 つ以上設定できます。以下の図はこのような状況を示しています。

図10.6 未使用のパーティションがあるディスク

上記の例では、最初の図は未使用のパーティションを持つディスクを表し、2 番目の図は Linux 用の未使用パーティションの再割り当てを示しています。

このような場合は、未使用のパーティションに割り当てられる領域を使用できます。パーティションを削除してから、適切な Linux パーティションをその場所に作成する必要があります。未使用のパーティションを削除し、インストールプロセス時に新しいパーティションを手動で作成できます。

10.6.3. アクティブなパーティションの空き領域の使用

これは最も一般的な状況です。また、十分な空き領域がある場合でも、すでに使用中のパーティションに割り当てられるため、処理が困難になります。ソフトウェアがプリインストールされているコンピュータを購入した場合、ハードディスクには、オペレーティングシステムとデータを保持する1つの大きなパーティションがある可能性があります。

システムに新しいハードドライブを追加する以外に、破壊的な再構成と非破壊的な再構成を選択できます。

10.6.3.1. 破壊的な再構成

これにより、パーティションが削除され、小さいパーティションがいくつか作成されます。元のパーティションのデータは破棄されるため、完全バックアップを作成する必要があります。2 つのバックアップを作成し、検証 (バックアップソフトウェアで利用可能な場合) を使用し、パーティションを削除する 前 にバックアップからデータを読み込もうとします。

警告

オペレーティングシステムがそのパーティションにインストールされていて、そのシステムも使用する場合は、再インストールする必要があります。オペレーティングシステムがプリインストールされた状態で販売されている一部のコンピューターには、元のオペレーティングシステムを再インストールするためのインストールメディアが含まれていない場合があります。元のパーティションとそのオペレーティングシステムのインストールを破棄する 前 に、これがシステムに適用されるかどうかを確認してください。

既存のオペレーティングシステムに小規模なパーティションを作成したら、ソフトウェアを再インストールし、データを復元し、Red Hat Enterprise Linux のインストールを開始できます。

図10.7 ディスク上での破壊的な再パーティション処理

警告

元のパーティションに存在していたデータはすべて失われます。

10.6.3.2. 非破壊的な再パーティション

非破壊的なパーティション再分割では、大きなパーティションを小さくするプログラムを実行するため、そのパーティションに保存されているファイルを失うことはありません。通常、この方法は信頼性がありますが、大規模なドライブでは非常に時間がかかります。

非破壊的な再パーティション処理は分かりやすく、以下の 3 つの手順で構成されます。

1. 既存データの圧縮およびバックアップ
2. 既存パーティションのサイズ
3. 新しいパーティションの作成

各ステップについて詳細に説明します。

10.6.3.2.1. 既存データの圧縮

最初の手順では、既存のパーティションのデータを圧縮します。これを行う理由は、パーティションの「末尾」で使用可能な空き領域を最大化するために、データを再配置します。

図10.8 ディスクの圧縮

上記の例では、最初の図は圧縮前のディスクを表し、圧縮後の 2 つ目の図です。

このステップは重要です。データの場所を使用しないと、パーティションを希望のエクステントのサイズを変更できなくなる可能性があります。一部のデータは移動できないことに注意してください。この場合、新しいパーティションのサイズが厳しく制限され、ディスクを破壊的に再パーティション化する必要が生じる可能性があります。

10.6.3.2.2. 既存パーティションのサイズ変更

次の図は、実際のサイズ変更プロセスを示しています。サイズ変更操作の実際の結果は使用するソフトウェアによって異なりますが、ほとんどの場合、新しく解放された領域を使用して、元のパーティションと同じタイプのフォーマットされていないパーティションが作成されます。

図10.9 ディスク上でのパーティションのサイズ変更

上記の例では、最初の図はサイズ変更前のパーティションを表し、サイズ変更後の 2 番目の図を示しています。

使用するサイズ変更ソフトウェアが新しく解放された領域をどのように処理するかを理解して、適切な手順を実行できるようにすることが重要です。ここで説明する場合は、新しい DOS パーティションを削除して、適切な Linux パーティションまたはパーティションを作成することが推奨されます。

10.6.3.2.3. 新しいパーティションの作成

例の「既存パーティションのサイズ変更」で説明したように、新しいパーティションを作成する必要がなくなることがあります。ただし、サイズ変更ソフトウェアが Linux をインストールしたシステムに対応していない限り、サイズ変更プロセスで作成されたパーティションを削除する必要があります。

図10.10 最終パーティション構成のディスク

上記の例では、最初の図は構成前のディスクを表し、2 番目の図は構成後のディスクを表しています。

XFSは、拡張性が高く、高性能で堅牢な、成熟した 64 ビットのジャーナリングファイルシステムで、1 台のホストで非常に大きなファイルおよびファイルシステムに対応します。これは、Red Hat Enterprise Linux 8 のデフォルトのファイルシステムです。XFS は、元々 1990 年代の前半に SGI により開発され、極めて大規模なサーバーおよびストレージアレイで実行されてきた長い歴史があります。

XFS の機能は次のとおりです。

XFS は、シングルスレッドで、メタデータ集約型のワークロードのパフォーマンスが比較的低くなります。たとえば、シングルスレッドで小さなファイルを多数作成し、削除するワークロードがこれに当てはまります。

システム管理者は、ブロックデバイスに XFS ファイルシステムを作成して、ファイルやディレクトリーを格納できます。

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: xfs
  roles:
    - rhel-system-roles.storage

システム管理者は、xfsdump を使用して XFS ファイルシステムをファイルまたはテープにバックアップできます。これは、簡単なバックアップメカニズムを提供します。

システム管理者は、xfsrestore ユーティリティーを使用して、xfsdump ユーティリティーで作成され、ファイルまたはテープに保存されている XFS バックアップを復元できます。

xfsrestore: preparing drive
xfsrestore: examining media file 0
xfsrestore: inventory session uuid (8590224e-3c93-469c-a311-fc8f23029b2a) does not match the media header's session uuid (7eda9f86-f1e9-4dfd-b1d4-c50467912408)
xfsrestore: examining media file 1
xfsrestore: inventory session uuid (8590224e-3c93-469c-a311-fc8f23029b2a) does not match the media header's session uuid (7eda9f86-f1e9-4dfd-b1d4-c50467912408)
[...]

システム管理者は、XFS ファイルシステムのサイズを大きくして、より大きなストレージ容量を利用できます。

本セクションでは、ext4 ファイルシステムおよび XFS ファイルシステムで一般的なタスクを行うのに使用するツールを比較します。

XFS ファイルシステムは、I/O 操作中にエラーが発生すると、以下のいずれかの方法で応答します。

XFS が以下のエラー条件に反応する方法を設定できます。

最大再試行回数と、XFS がエラーを永続的と見なすまでの最大時間を秒単位で設定できます。XFS は、いずれかの制限に達すると操作の再試行を停止します。

また、ファイルシステムのマウントを解除するときに、他の設定に関係なく XFS が再試行を即座にキャンセルするように XFS を設定することもできます。この設定により、永続的なエラーを出しても、マウント解除操作は成功します。

以下のディレクトリーは、さまざまなエラー状態に対して XFS エラー動作を制御する設定ファイルを保存します。

各ディレクトリーには、再試行制限を設定するために以下の設定ファイルが含まれています。

この手順では、XFS が特定のエラー条件にどのように反応するかを設定します。

この手順では、XFS が、共通の設定を共有するすべての未定義のエラー条件に反応する方法を設定します。

この手順では、ファイルシステムのアンマウント時に XFS がエラー状態に対応するように設定します。

ファイルシステムに fail_at_unmount オプションを設定すると、マウント解除時にその他すべてのエラー設定が上書きされ、I/O 操作を再試行せずにすぐにファイルシステムをマウント解除します。これにより、永続的なエラーが発生した場合でも、マウント解除操作を成功できます。

以下のいずれかが発生した場合は、関連する fsck ツールを使用してシステムを確認できます。

ファイルシステムの不整合は、ハードウェアエラー、ストレージ管理エラー、ソフトウェアバグなどのさまざまな理由で発生する可能性があります。

ジャーナリングファイルシステムの場合、システムの起動時に通常必要なのは、必要に応じてジャーナルを再生することだけで、これは通常非常に短い操作になります。

ただし、ジャーナリングファイルシステムであっても、ファイルシステムの不整合や破損が発生した場合は、ファイルシステムチェッカーを使用してファイルシステムを修復する必要があります。

通常、ファイルシステムの確認および修復のツールを実行すると、検出された不整合の少なくとも一部が自動的に修復されることが期待できます。場合によっては、以下の問題が発生する場合があります。

予期しない変更や、望ましくない変更が永続的に行われないようにするには、この手順にまとめられている予防手順を行ってください。

本セクションでは、XFS がファイルシステム内のさまざまな種類のエラーを処理する方法を説明します。

不完全なアンマウント

ジャーナリングは、ファイルシステムで発生したメタデータの変更のトランザクション記録を保持します。

システムクラッシュ、電源障害、またはその他の不完全なアンマウントが発生した場合、XFS はジャーナル (ログとも呼ばれる) を使用してファイルシステムを復旧します。カーネルは XFS ファイルシステムをマウントするときにジャーナルの復旧を実行します。

破損

この文脈での 破損 は、次のような原因によるファイルシステムのエラーを意味します。

XFS は、ファイルシステムまたはファイルシステムメタデータの破損を検出すると、ファイルシステムをシャットダウンして、システムログにインシデントを報告することがあります。/var ディレクトリーが置かれているファイルシステムで破損が発生すると、このログは再起動後に利用できなくなります。

# dmesg --notime | tail -15

XFS (loop0): Mounting V5 Filesystem
XFS (loop0): Metadata CRC error detected at xfs_agi_read_verify+0xcb/0xf0 [xfs], xfs_agi block 0x2
XFS (loop0): Unmount and run xfs_repair
XFS (loop0): First 128 bytes of corrupted metadata buffer:
00000000027b3b56: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000005f9abc7a: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000005b0aef35: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000000da9d2ded: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000001e265b07: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000006a40df69: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000000000b272907: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000000e484aac5: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
XFS (loop0): metadata I/O error in "xfs_trans_read_buf_map" at daddr 0x2 len 1 error 74
XFS (loop0): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -117, agno 0
XFS (loop0): Failed to read root inode 0x80, error 11

ユーザー空間ユーティリティーは通常、破損した XFS ファイルシステムにアクセスしようとすると Input/output error メッセージを報告します。破損したログを使用して XFS ファイルシステムをマウントすると、マウントに失敗し、次のエラーメッセージが表示されます。

mount: /mount-point: mount(2) system call failed: Structure needs cleaning.

破損を修復するには、手動で xfs_repair ユーティリティーを使用する必要があります。

この手順では、xfs_repair ユーティリティーを使用して XFS ファイルシステムの読み取り専用の確認を実行します。破損を修復するには、手動で xfs_repair ユーティリティーを使用する必要があります。xfs_repair は、その他のファイルシステム修復ユーティリティーとは異なり、XFS ファイルシステムが正しくアンマウントされていなくても起動時には動作しません。不完全なアンマウントが発生した場合、XFS は単にマウント時にログを再生して、一貫したファイルシステムを確保します。xfs_repair は、最初にマウントし直さずに、ダーティーログがある XFS ファイルシステムを修復することはできません。

この手順では、xfs_repair ユーティリティーを使用して破損した XFS ファイルシステムを修復します。

ext2、ext3、および ext4 のファイルシステムは、e2fsck ユーティリティーを使用して、ファイルシステムの確認と修復を実行します。ファイル名の fsck.ext2、fsck.ext3、および fsck.ext4 は、e2fsck ユーティリティーへのハードリンクです。これらのバイナリーは、システムの起動時に自動的に実行し、その動作は確認されるファイルシステムと、そのファイルシステムの状態によって異なります。

完全なファイルシステムの確認および修復は、メタデータジャーナリングファイルシステムではない ext2 や、ジャーナルのない ext4 ファイルシステムに対して呼び出されます。

メタデータジャーナリング機能のある ext3 ファイルシステムおよび ext4 ファイルシステムの場合、ジャーナルはユーザー空間で再生され、ユーティリティーは終了します。これは、ジャーナルの再生によりクラッシュ後のファイルシステムの整合性が確保されるためのデフォルト動作になります。

このファイルシステムで、マウント中にメタデータの不整合が生じると、その事実がファイルシステムのスーパーブロックに記録されます。e2fsck が、このようなエラーでファイルシステムがマークされていることを検出すると、e2fsck はジャーナル (がある場合) の再生後にフルチェックを実行します。

この手順では、e2fsck ユーティリティーを使用して、ext2 ファイルシステム、ext3 ファイルシステム、または ext4 ファイルシステムを確認します。

この手順では、e2fsck ユーティリティーを使用して、破損した ext2、ext3、または ext 4 のファイルシステムを修復します。

本セクションでは、Linux でのファイルシステムのマウントに関する基本概念を説明します。

Linux、UNIX、および類似のオペレーティングシステムでは、さまざまなパーティションおよびリムーバブルデバイス (CD、DVD、USB フラッシュドライブなど) にあるファイルシステムをディレクトリーツリーの特定のポイント (マウントポイント) に接続して、再度切り離すことができます。ファイルシステムがディレクトリーにマウントされている間は、そのディレクトリーの元の内容にアクセスすることはできません。

Linux では、ファイルシステムがすでに接続されているディレクトリーにファイルシステムをマウントできます。

マウント時には、次の方法でデバイスを識別できます。

デバイス名、目的のディレクトリー、ファイルシステムタイプなど、必要な情報をすべて指定せずに mount コマンドを使用してファイルシステムをマウントすると、mount ユーティリティーは /etc/fstab ファイルの内容を読み取り、指定のファイルシステムが記載されているかどうかを確認します。/etc/fstab ファイルには、選択したファイルシステムがマウントされるデバイス名およびディレクトリーのリスト、ファイルシステムタイプ、およびマウントオプションが含まれます。そのため、/etc/fstab で指定されたファイルシステムをマウントする場合は、以下のコマンド構文で十分です。

この手順では、コマンドラインに、現在マウントされているファイルシステムの一覧を表示する方法を説明します。

この手順では、mount ユーティリティーを使用してファイルシステムをマウントする方法を説明します。

この手順では、マウントされたファイルシステムのマウントポイントを、別のディレクトリーに変更する方法を説明します。

この手順では、umount ユーティリティーを使用してファイルシステムをアンマウントする方法を説明します。

本セクションでは、mount ユーティリティーでよく使用されるオプションを示します。

オプションは、次の構文で使用できます。

# mount --options option1,option2,option3 device mount-point

使用できる共有マウントには複数のタイプがあります。共有マウントポイントの種類によって、マウントポイントに別のファイルシステムをマウントしたときに発生する内容がなります。共有マウントは、共有サブツリー 機能を使用して実装されます。

次のマウントタイプを使用できます。

この手順では、マウントポイントをプライベートマウントとして複製します。複製後に、複製または元のマウントポイントにマウントするファイルシステムは、他方のマウントポイントには反映されません。

この手順では、マウントポイントを共有マウントとして複製します。複製後に、元のディレクトリーまたは複製にマウントしたファイルシステムは、他方のマウントポイントに常に反映されます。

この手順では、マウントポイントを slave マウントタイプとして複製します。複製後に、元のマウントポイントにマウントしたファイルシステムは複製に反映されますが、その逆は反映されません。

この手順では、別のマウントポイントに複製されないように、マウントポイントをバインド不可としてマークします。

本セクションでは、ファイルシステムの永続的なマウントポイントを制御する /etc/fstab 設定ファイルを説明します。ファイルシステムを永続的にマウントするには、/etc/fstab を使用することが推奨されます。

/etc/fstab ファイルの各行は、ファイルシステムのマウントポイントを定義します。空白で区切られた 6 つのフィールドが含まれています。

systemd サービスは、/etc/fstab のエントリーからマウントユニットを自動的に生成します。

この手順では、/etc/fstab 設定ファイルでファイルシステムの永続マウントポイントを設定する方法を説明します。

本セクションでは、Ansible Playbook の例を紹介します。この Playbook は、storage ロールをすぐに適用して、XFS ファイルシステムを永続的にマウントします。

---
- hosts: all
  vars:
    storage_volumes:
      - name: barefs
        type: disk
        disks:
          - sdb
        fs_type: xfs
        mount_point: /mnt/data
  roles:
    - rhel-system-roles.storage

本セクションでは、ファイルシステムをオンデマンドでマウントするのに使用する autofs サービスの利点と基本概念を説明します。

/etc/fstab 設定を使用した永続的なマウントの欠点の 1 つは、マウントされたファイルシステムにユーザーがアクセスする頻度に関わらず、マウントされたファイルシステムを所定の場所で維持するために、システムがリソースを割り当てる必要があることです。これは、システムが一度に多数のシステムへの NFS マウントを維持している場合などに、システムのパフォーマンスに影響を与える可能性があります。

/etc/fstab に代わるのは、カーネルベースの autofs サービスの使用です。これは以下のコンポーネントで構成されています。

autofs サービスは、ファイルシステムの自動マウントおよび自動アンマウントが可能なため (オンデマンド)、システムのリソースを節約できます。このサービスは、NFS、AFS、SMBFS、CIFS、およびローカルなどのファイルシステムをマウントする場合にも使用できます。

本セクションでは、autofs サービスで使用される設定ファイルの使用方法と構文を説明します。

すべてのオンデマンドマウントポイントはマスターマップで設定する必要があります。マウントポイント、ホスト名、エクスポートされたディレクトリー、オプションはすべて、ホストごとに手動で設定するのではなく、一連のファイル (またはサポートされているその他のネットワークソース) で指定できます。

マスターマップファイルには、autofs により制御されるマウントポイントと、それに対応する設定ファイルまたは自動マウントマップと呼ばれるネットワークソースが一覧表示されます。マスターマップの形式は次のとおりです。

mount-point  map-name  options

この形式で使用されている変数を以下に示します。

/mnt/data  /etc/auto.data

ディレクトリーが存在しない場合、自動マウント機能はディレクトリーを作成します。ディレクトリーが存在している状況で自動マウント機能が起動した場合は、自動マウント機能の終了時にディレクトリーが削除されることはありません。タイムアウトを指定した場合は、タイムアウト期間中ディレクトリーにアクセスしないと、ディレクトリーが自動的にアンマウントされます。

マップの一般的な形式は、マスターマップに似ています。ただし、マスターマップでは、オプションフィールドはエントリーの末尾ではなく、マウントポイントと場所の間に表示されます。

mount-point  options  location

この形式で使用されている変数を以下に示します。

payroll  -fstype=nfs4  personnel:/dev/disk/by-uuid/52b94495-e106-4f29-b868-fe6f6c2789b1
sales    -fstype=xfs   :/dev/disk/by-uuid/5564ed00-6aac-4406-bfb4-c59bf5de48b5

ただし、Red Hat は、前述のセクションで説明した簡単な autofs 形式の使用を推奨しています。

この手順では、autofs サービスを使用してオンデマンドマウントポイントを設定する方法を説明します。

この手順では、ユーザーのホームディレクトリーを自動的にマウントするように autofs サービスを設定する方法を説明します。

クライアントシステムの特定のマウントポイントで、サイトのデフォルトを上書きすることが役に立つ場合があります。

この手順では、autofs マップファイルではなく、LDAP 設定で自動マウント機能マップを格納するように autofs を設定します。