Red Hat Training

A Red Hat training course is available for RHEL 8

ストレージデバイスの管理

Red Hat Enterprise Linux 8

Red Hat Enterprise Linux 8 における単一ノードストレージの導入と設定

Red Hat Customer Content Services

概要

本書は、Red Hat Enterprise Linux 8 でストレージデバイスを効果的に管理する方法を説明します。

Red Hat ドキュメントへのフィードバック (英語のみ)

ご意見ご要望をお聞かせください。ドキュメントの改善点はございませんか。改善点を報告する場合は、以下のように行います。

  • 特定の文章に簡単なコメントを記入する場合は、以下の手順を行います。

    1. ドキュメントの表示が Multi-page HTML 形式になっていて、ドキュメントの右上端に Feedback ボタンがあることを確認してください。
    2. マウスカーソルで、コメントを追加する部分を強調表示します。
    3. そのテキストの下に表示される Add Feedback ポップアップをクリックします。
    4. 表示される手順に従ってください。
  • より詳細なフィードバックを行う場合は、Bugzilla のチケットを作成します。

    1. Bugzilla の Web サイトにアクセスします。
    2. Component で Documentation を選択します。
    3. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
    4. Submit Bug をクリックします。

第1章 利用可能なストレージオプションの概要

本章では、Red Hat Enterprise Linux 8 で利用可能なストレージの種類を説明します。Red Hat Enterprise Linux は、ローカルストレージの管理、およびリモートストレージへの接続に使用するさまざまなオプションを提供しています。図1.1「Red Hat Enterprise Linux ストレージダイアグラム (概要)」では、さまざまなストレージオプションを説明します。

図1.1 Red Hat Enterprise Linux ストレージダイアグラム (概要)

RHEL ストレージダイアグラム (概要)

1.1. ローカルストレージオプション

以下は、Red Hat Enterprise Linux 8 で利用可能なローカルストレージオプションです。

  • 基本的なディスク管理:

    parted と fdisk を使用して、パーティションの作成、修正、削除、表示を行うことができます。パーティショニングレイアウトの仕様は以下のようになります。

    • MBR (Master Boot Record) - BIOS ベースのコンピューターで使用されます。プライマリーパーティション、拡張パーティション、および論理パーティションを作成できます。
    • GPT (GUID Partition Table) - GUID (Globally Unique identifier) を使用し、一意のディスクおよびパーティション GUID を提供します。

      パーティションを暗号化するには、LUKS (Linux Unified Key Setup-on-disk-format) を使用します。パーティションを暗号化する場合は、インストール時にオプションを選択し、パスフレーズを入力させるプロンプトを表示します。このパスフレーズにより、暗号化キーのロックが解除されます。

  • ストレージ使用オプション:

    • NVDIMM (Non-Volatile Dual In-line Memory Modules) の管理 - メモリーとストレージの組み合わせです。システムに接続した NVDIMM デバイスで、さまざまな種類のストレージを有効にして管理できます。
    • ブロックストレージ管理 - 各ブロックに固有の識別子を持つブロックの形式でデータを保存します。
    • ファイルストレージ - データは、ローカルシステムのファイルレベルに保存されます。これらのデータは、XFS (デフォルト) または ext4 を使用してローカルでアクセスしたり、NFS と SMB を使用してネットワーク上でアクセスできます。
  • 論理ボリュームの設定および管理:

    • 論理ボリュームマネージャー (LVM) - 物理デバイスから論理ボリュームを作成します。論理ボリューム (LV) は、物理ボリューム (PV) とボリュームグループ (VG) の組み合わせです。LVM の設定には以下が含まれます。

      • ハードドライブから PV の作成
      • 物理ボリュームからボリュームグループの作成
      • ボリュームグループから論理ボリュームを作成すると、マウントポイントが論理ボリュームに割り当てられます。
    • Virtual Data Optimizer (VDO) - 重複排除、圧縮、およびシンプロビジョニングを使用して、データの削減に使用されます。VDO の下で論理ボリュームを使用すると、次のことができます。

      • VDO ボリュームの拡張
      • 複数のデバイスにまたがる VDO ボリューム
  • ローカルファイルシステム:

    • XFS
    • Ext4
    • Straits - テクノロジープレビューとして利用できます。Stratis は、高度なストレージ機能に対応する、ユーザーとカーネルのハイブリッドローカルストレージ管理システムです。

1.2. リモートストレージオプション

Red Hat Enterprise Linux 8 で利用可能なリモートストレージオプションは次のとおりです。

  • ストレージの接続オプション:

    • iSCSI - RHEL 8 は targetcli ツールを使用して、iSCSI ストレージの相互接続を追加、削除、表示、および監視します。
    • ファイバーチャネル (FC) - Red Hat Enterprise Linux 8 は、以下のネイティブファイバーチャネルドライバーを提供します。

      • lpfc
      • qla2xxx
      • Zfcp
    • NVMe (Non-volatile Memory Express) は、ホストソフトウェアユーティリティーがソリッドステートドライブと通信できるようにするインターフェースです。次の種類はファブリックトランスポートを使用して、NVMe over fabrics を設定します。

      • RDMA (Remote Direct Memory Access) を使用する NVMe over fabrics
      • ファイバーチャネル (FC) を使用した NVMe over fabrics
    • Device Mapper のマルチパス (DM Multipath) を使用すると、サーバーノードとストレージアレイとの間の複数の I/O パスを 1 つのデバイスに設定できます。これらの I/O パスは、個別のケーブル、スイッチ、コントローラーを含むことができる物理的な SAN 接続です。
  • ネットワークファイルシステム:

    • NFS
    • SMB

1.3. GFS2 ファイルシステムのクラスター化ソリューション

Red Hat Global File System 2 (GFS2) ファイルシステムは、64 ビットの対称クラスターファイルシステムで、共有名前空間を提供し、一般的なブロックデバイスを共有する複数のノード間の一貫性を管理します。GFS2 ファイルシステムは、ローカルファイルシステムに可能な限り近い機能セットを提供すると同時に、ノード間でクラスターの完全な整合性を強制することを目的としています。これを実現するため、ノードはファイルシステムリソースにクラスター全体のロックスキームを使用します。このロックスキームは、TCP/IP などの通信プロトコルを使用して、ロック情報を交換します。

場合によっては、Linux ファイルシステム API では、GFS2 のクラスター化された性質を完全に透過的にすることができません。たとえば、GFS2 で POSIX ロックを使用しているプログラムは、GETLK の使用を回避する必要があります。なぜなら、クラスター環境では、プロセス ID が、クラスター内の別のノードに対するものである可能性があるためです。ただし、ほとんどの場合、GFS2 ファイルシステムの機能は、ローカルファイルシステムのものと同じです。

Red Hat Enterprise Linux (RHEL) Resilient Storage Add-On は GFS2 を提供します。GFS2 が必要とするクラスター管理の提供は RHEL High Availability Add-On により提供されます。

gfs2.ko カーネルモジュールは GFS2 ファイルシステムを実装し、GFS2 クラスターノードに読み込まれます。

GFS2 環境を最大限に利用するためにも、基礎となる設計に起因するパフォーマンス事情を考慮することが重要です。GFS2 では、ローカルファイルシステムと同様、ページキャッシュで、頻繁に使用されるデータのローカルキャッシングを行ってパフォーマンスを向上します。クラスターのノード間で一貫性を維持するために、glock ステートマシンでキャッシュ制御が提供されます。

GFS2 ファイルシステムの詳細は、「GFS2 ファイルシステムの設定」を参照してください。

1.4. Gluster 設定されたソリューション

このセクションでは、Red Hat Gluster Storage (RHGS) または Red Hat Ceph Storage (RHCS) などの glustered オプションの概要を説明します。

1.4.1. Red Hat Gluster Storage オプション

Red Hat Gluster Storage (RHGS) は、ソフトウェアが定義されたストレージプラットフォームです。これは、複数のサーバーから単一のグローバル名前空間に、ディスクストレージリソースを統合します。GlusterFS はオープンソースの分散ファイルシステムです。これは、クラウドおよびハイブリッドのソリューションに適しています。

GlusterFS は、GlusterFS のベースとなる異なるタイプのボリュームで構成され、さまざまな要件を提供します。ボリュームは、ストレージ領域自体であるブリックのコレクションです。

GlusterFS ボリュームのタイプは次のとおりです。

  • 分散 GlusterFS ボリューム は、デフォルトのボリュームです。この場合、各ファイルは単一のブリックに格納され、異なるブリック間で共有できません。
  • レプリケートされた GlusterFS ボリューム タイプは、データのレプリカを維持します。この場合、ブリックが失敗しても、ユーザーはデータにアクセスできます。
  • 分散されレプリケートされた GlusterFS ボリューム は、多数のシステムにレプリカを分散するハイブリッドボリュームです。ストレージのスケーリングおよび信頼性の高さが重要な環境には適しています。

RHGS に関する詳細は、「Red Hat gluster ストレージ管理ガイド」を参照してください。

1.4.2. Red Hat Ceph Storage オプション

Red Hat Ceph Storage (RHCS) はスケーラブルでオープンなソフトウェア定義のストレージプラットフォームで、Ceph ストレージシステムの最も安定したバージョンと、Ceph 管理プラットフォーム、デプロイメントユーティリティー、サポートサービスを組み合わせたものです。

Red Hat Ceph Storage は、クラウドインフラストラクチャーおよび Web スケールオブジェクトストレージ用に設計されています。Red Hat Ceph Storage クラスターは、以下のタイプのノードで構成されます。

Red Hat Ceph Storage Ansible 管理ノード

このタイプのノードは、以前のバージョンの Red Hat Ceph Storage に行われた従来の Ceph 管理ノードとして機能します。このタイプのノードでは、以下の機能が提供されます。

  • ストレージクラスターの一元管理
  • Ceph 設定ファイルおよびキー
  • 必要に応じて、セキュリティー上の理由からインターネットにアクセスできないノードに Ceph をインストールするためのローカルリポジトリー
ノードの監視
各モニターノードは、クラスターマップのマスターコピーを維持する monitor デーモン (ceph-mon) を実行します。クラスターマップにはクラスタートポロジーが含まれます。Ceph クラスターに接続するクライアントは、モニターからクラスターマップの現在のコピーを取得します。これにより、クライアントがクラスターへのデータの読み取りおよび書き込みが可能になります。
重要

Ceph は 1 つのモニターで実行できますが、実稼働クラスターで高可用性を確保するためには、Red Hat は少なくとも 3 つのモニターノードを持つデプロイメントのみをサポートします。Red Hat は、750 個の OSD を超えるストレージクラスターに合計 5 つの Ceph Monitor をデプロイすることを推奨します。

OSD ノード
各 Object Storage Device (OSD) ノードは Ceph OSD デーモン (ceph-osd) を実行し、ノードに割り当てられている論理ディスクと相互作用します。Ceph は、この OSD ノードにデータを保存します。

Ceph は、非常に少数の OSD ノード (デフォルトは 3) で実行できますが、実稼働クラスターは、ストレージクラスターで中程度のスケール (たとえば OSD が 50 個) で始まります。理想的には、Ceph クラスターに複数の OSD ノードがあり、CRUSH マップを作成して分離された障害ドメインを許可します。

MDS ノード
各 Metadata Server (MDS) ノードは、Ceph ファイルシステム (CephFS) に保存されているファイルに関連する MDS デーモン (ceph-mds) を実行します。MDS デーモンは、共有クラスターへのアクセスも調整します。
Object Gateway ノード
Ceph Object Gateway ノードは、Ceph RADOS Gateway デーモン (ceph-radosgw) を実行し、Ceph Storage クラスターへの RESTful ゲートウェイを使用するアプリケーションを提供する librados 上に構築されたオブジェクトストレージインターフェースです。Ceph Object Gateway は、以下の 2 つのインターフェースをサポートします。
S3
Amazon S3 RESTful API の大規模なサブセットと互換性のあるインターフェースでオブジェクトストレージ機能を提供します。
Swift
OpenStack Swift API の大規模なサブセットと互換性のあるインターフェースでオブジェクトストレージ機能を提供します。

RHCS の詳細は、Red Hat Ceph Storage のドキュメントを参照してください。

第2章 パーティションの使用

システム管理者は、以下の手順に従ってさまざまな種類のディスクパーティションを作成、削除、および変更できます。

ブロックデバイスでパーティションを使用する長所と短所の概要は、ナレッジベースの記事「What are the advantages and disadvantages to using partitioning on LUNs, either directly or with LVM in between?」を参照してください。

2.1. パーティションテーブルの表示

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

2.1.1. parted でパーティションテーブルの表示

この手順では、parted ユーティリティーを使用してブロックデバイスのパーティションテーブルを表示する方法を説明します。

手順

  1. インタラクティブな parted シェルを起動します。

    # parted block-device
    • block-device を、調べるデバイスへのパス (例: /dev/sda) に置き換えます。
  2. パーティションテーブルを表示します。

    (parted) print
  3. 必要に応じて次のコマンドを使用して、次に調べるデバイスに切り替えることもできます。

    (parted) select block-device

関連情報

  • man ページの parted(8)

2.1.2. parted print の出力例

このセクションでは、parted シェルの print コマンドの出力例を示し、出力内のフィールドを説明します。

例2.1 print コマンドの出力

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

以下は、フィールドの説明です。

Model: ATA SAMSUNG MZNLN256 (scsi)
ディスクタイプ、製造元、モデル番号、およびインターフェース。
Disk /dev/sda: 256GB
ブロックデバイスへのファイルパスとストレージ容量。
Partition Table: msdos
ディスクラベルの種類。
Number
パーティション番号。たとえば、マイナー番号 1 のパーティションは、/dev/sda1 に対応します。
Start および End
デバイスにおけるパーティションの開始場所と終了場所。
Type
有効なタイプは、メタデータ、フリー、プライマリー、拡張、または論理です。
File system
ファイルシステムの種類。ファイルシステムの種類が不明な場合は、デバイスの File system フィールドに値が表示されません。parted ユーティリティーは、暗号化されたデバイスのファイルシステムを認識できません。
Flags
パーティションのフラグ設定一覧。利用可能なフラグは、bootrootswaphiddenraidlvm、または lba です。

2.2. ディスクへのパーティションテーブルの作成

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

警告

パーティションテーブルを使用してブロックデバイスをフォーマットすると、そのデバイスに保存されているすべてのデータが削除されます。

2.2.1. ディスクのパーティション変更前の留意事項

このセクションでは、パーティションの作成、削除、またはサイズ変更を行う前に考慮すべき重要な点を説明します。

注記

このセクションでは、IBM Z アーキテクチャーに固有の DASD パーティションテーブルを説明しません。DASD の情報は、以下を参照してください。

パーティションの最大数

デバイスで使用できるパーティションの数は、パーティションテーブルの種類によって異なります。

  • マスターブートレコード (MBR) パーティションテーブルでフォーマットされたデバイスでは、次のいずれかの数だけパーティションを設定できます。

    • 最大 4 つのプライマリーパーティション
    • 最大 3 つのプライマリーパーティション、および 1 つの拡張パーティション、ならびにその拡張内に複数の論理パーティション
  • GUID パーティションテーブル (GPT) でフォーマットしたデバイスにおけるパーティションの最大数は 128 個です。GPT 仕様により、パーティションテーブル用に確保するエリアを拡大することで、さらに多くのパーティションを作成できますが、parted ユーティリティーで用いられる一般的な方法で得られるエリアは 128 個に制限されます。
注記

Red Hat では、特に理由がない限り、少なくとも swap/boot/、および / (root) のパーティションを作成することが推奨されます。

パーティションの最大サイズ

デバイスのパーティションの最大サイズは、パーティションテーブルの種類により異なります。

  • マスターブートレコード (MBR) パーティションテーブルでフォーマットしたデバイスの最大サイズは 2TiB になります。
  • GUID パーティションテーブル (GPT) でフォーマットしたデバイスの最大サイズは 8ZiB になります。

2TiB を超えるパーティションを作成する場合は、ディスクを GPT でフォーマットする必要があります。

サイズ調整

parted ユーティリティーを使用した場合は、パーティションサイズを指定する際の接尾辞を選択できます。

MiB、GiB、または TiB

サイズは 2 のべき乗で表示されます。

  • パーティションの開始点は、サイズが指定する正確なセクターに調整されます。
  • 終了点は、指定されたサイズから 1 セクターを引いたサイズに調整されます。
MB、GB、または TB

サイズは 10 のべき乗で表示されます。

開始点と終了点は、指定された単位の半分以内に置かれます。たとえば、接尾辞 MB を使用する場合は ±500 KB です。

2.2.2. パーティションテーブルの種類の比較

このセクションでは、ブロックデバイスに作成できるさまざまな種類のパーティションテーブルのプロパティーを比較します。

表2.1 パーティションテーブルの種類

パーティションテーブルパーティションの最大数パーティションの最大サイズ

マスターブートレコード (MBR)

4 つのプライマリー。または 3 つのプライマリーと、拡張パーティション内に 12 の論理

2TiB

GUID パーティションテーブル (GPT)

128

8ZiB

2.2.3. parted でディスクにパーティションテーブルを作成

この手順では、parted ユーティリティーを使用するパーティションテーブルでブロックデバイスをフォーマットする方法を説明します。

手順

  1. インタラクティブな parted シェルを起動します。

    # parted block-device
    • block-device を、パーティションテーブルを作成するデバイスへのパス (例: /dev/sda) に置き換えます。
  2. デバイスにパーティションテーブルがあるかどうかを確認します。

    (parted) print

    デバイスにパーティションが含まれている場合は、次の手順でパーティションを削除します。

  3. 新しいパーティションテーブルを作成します。

    (parted) mklabel table-type
    • table-type を、使用するパーティションテーブルの種類に置き換えます。

      • msdo (MBR の場合)
      • gpt (GPT の場合)

    例2.2 GPT テーブルの作成

    たとえば、ディスクに GPT テーブルを作成するには、次のコマンドを使用します。

    (parted) mklabel gpt

    このコマンドを実行するとすぐに変更が行われるため、実行する前によく確認してください。

  4. パーティションテーブルを表示して、パーティションテーブルが存在することを確認します。

    (parted) print
  5. parted シェルを終了します。

    (parted) quit

関連情報

  • man ページの parted(8)

次のステップ

2.3. パーティションの作成

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

2.3.1. ディスクのパーティション変更前の留意事項

このセクションでは、パーティションの作成、削除、またはサイズ変更を行う前に考慮すべき重要な点を説明します。

注記

このセクションでは、IBM Z アーキテクチャーに固有の DASD パーティションテーブルを説明しません。DASD の情報は、以下を参照してください。

パーティションの最大数

デバイスで使用できるパーティションの数は、パーティションテーブルの種類によって異なります。

  • マスターブートレコード (MBR) パーティションテーブルでフォーマットされたデバイスでは、次のいずれかの数だけパーティションを設定できます。

    • 最大 4 つのプライマリーパーティション
    • 最大 3 つのプライマリーパーティション、および 1 つの拡張パーティション、ならびにその拡張内に複数の論理パーティション
  • GUID パーティションテーブル (GPT) でフォーマットしたデバイスにおけるパーティションの最大数は 128 個です。GPT 仕様により、パーティションテーブル用に確保するエリアを拡大することで、さらに多くのパーティションを作成できますが、parted ユーティリティーで用いられる一般的な方法で得られるエリアは 128 個に制限されます。
注記

Red Hat では、特に理由がない限り、少なくとも swap/boot/、および / (root) のパーティションを作成することが推奨されます。

パーティションの最大サイズ

デバイスのパーティションの最大サイズは、パーティションテーブルの種類により異なります。

  • マスターブートレコード (MBR) パーティションテーブルでフォーマットしたデバイスの最大サイズは 2TiB になります。
  • GUID パーティションテーブル (GPT) でフォーマットしたデバイスの最大サイズは 8ZiB になります。

2TiB を超えるパーティションを作成する場合は、ディスクを GPT でフォーマットする必要があります。

サイズ調整

parted ユーティリティーを使用した場合は、パーティションサイズを指定する際の接尾辞を選択できます。

MiB、GiB、または TiB

サイズは 2 のべき乗で表示されます。

  • パーティションの開始点は、サイズが指定する正確なセクターに調整されます。
  • 終了点は、指定されたサイズから 1 セクターを引いたサイズに調整されます。
MB、GB、または TB

サイズは 10 のべき乗で表示されます。

開始点と終了点は、指定された単位の半分以内に置かれます。たとえば、接尾辞 MB を使用する場合は ±500 KB です。

2.3.2. パーティションタイプ

このセクションでは、パーティションのタイプを指定するさまざまな属性を説明します。

パーティションタイプまたはフラグ

パーティションタイプ、またはフラグは、実行中のシステムではほとんど使用されません。ただし、パーティションタイプは、systemd-gpt-auto-generator など、デバイスを自動的に識別してマウントするためにパーティションタイプを使用するオンザフライジェネレーターにとって重要です。

  • parted ユーティリティーは、パーティションタイプを flags にマッピングすることでパーティションタイプを制御します。parted ユーティリティーが処理できるのは、特定のパーティションタイプ (LVM、swap、または RAID など) に限定されます。
  • fdisk ユーティリティーは、16 進数コードを指定することで、あらゆる種類のパーティションタイプに対応します。
パーティションファイルシステムのタイプ

parted ユーティリティーは、パーティションを作成するときにオプションでファイルシステムタイプ引数を受け付けます。値は以下の目的で使用されます。

  • MBR にパーティションフラグを設定します。
  • GPT にパーティションの UUID タイプを設定します。たとえば、ファイルシステムタイプの swapfat、または hfs には、異なる GUID が設定されます。デフォルト値は Linux Data GUID です。

引数によりパーティション上のファイルシステムが変更することはありません。サポートされているフラグまたは GUID を変更するだけです。

次のファイルシステムのタイプがサポートされています。

  • xfs
  • ext2
  • ext3
  • ext4
  • fat16
  • fat32
  • hfs
  • hfs+
  • linux-swap
  • ntfs
  • reiserfs

2.3.3. パーティション命名スキーム

Red Hat Enterprise Linux は、/dev/xxyN 形式のファイル名を持つファイルベースの命名スキームを使用します。

デバイスおよびパーティション名は、以下の構造で構成されています。

/dev/
これは、すべてのデバイスファイルが配置されているディレクトリーの名前です。パーティションはハードディスク上に配置され、ハードディスクはデバイスであるため、パーティションを表すすべてのファイルは /dev に配置されます。
xx
パーティション名の最初の 2 文字は、パーティションが存在するデバイスのタイプ (通常は sd) を示します。
y
この文字は、パーティションが存在するデバイスを示します。たとえば、/dev/sda は最初のハードディスク、/dev/sdb は 2 番目のハードディスク、などです。26 を超えるドライブが搭載されているシステムでは、より多くの文字を使用できます。たとえば、/dev/sdaa1 を使用します。
N
最後の文字は、パーティションを表す数字を示します。最初の 4 つのパーティション (プライマリーまたは拡張) のパーティションには、1 から 4 までの番号が付けられます。論理パーティションは 5 から始まります。たとえば、/dev/sda3 は 1 番目のハードディスクの 3 番目のプライマリーパーティションまたは拡張パーティションで、2 番目のハードディスク上の 2 番目の論理パーティション /dev/sdb6 です。ドライブのパーティション番号は、MBR パーティションテーブルにのみ適用されます。N は常にパーティションを意味するものではないことに注意してください。
注記

Red Hat Enterprise Linux が すべて のタイプのディスクパーティションを識別して参照できる場合でも、ファイルシステムを読み取れないため、すべてのパーティションタイプに保存されているデータにアクセスできます。ただし、多くの場合、別のオペレーティングシステム専用のパーティション上にあるデータには問題なくアクセスすることができます。

2.3.4. マウントポイントとディスクパーティション

Red Hat Enterprise Linux では、各パーティションは、ファイルおよびディレクトリーの単一セットをサポートするのに必要なストレージの一部を形成するために使用されます。これは、パーティションとディレクトリーを関連付ける マウント として知られるプロセスを使用して実行されます。パーティションをマウントすると、指定したディレクトリー (マウントポイント と呼ばれる) からそのストレージを利用できるようになります。

たとえば、パーティション /dev/sda5/usr// にマウントされている場合、/usr/ 下にあるすべてのファイルとディレクトリーは、物理的に dev/sda5 に配置されていることになります。そのため、/usr/share/doc/FAQ/txt/Linux-FAQ ファイルは /dev/sda5 に保存されますが、/etc/gdm/custom.conf ファイルは保存されません。

また、この例では、/usr/ 以下の 1 つ以上のディレクトリーが他のパーティションのマウントポイントになる可能性もあります。たとえば、パーティション /dev/sda7/usr/local にマウントできます。つまり、/usr/local/man/whatis は、/dev/sda5 ではなく /dev/sda7 上に存在することになります。

2.3.5. parted でパーティションの作成

この手順では、parted ユーティリティーを使用してブロックデバイスに新しいパーティションを作成する方法を説明します。

前提条件

  • ディスクにパーティションテーブルがある。ディスクのフォーマット方法の詳細は、「ディスクへのパーティションテーブルの作成」を参照してください。
  • 2TiB を超えるパーティションを作成する場合は、ディスクを GUID パーティションテーブル (GPT) でフォーマットしておく。

手順

  1. インタラクティブな parted シェルを起動します。

    # parted block-device
    • block-device を、パーティションを作成するデバイスへのパス (例: /dev/sda) に置き換えます。
  2. 現在のパーティションテーブルを表示し、十分な空き領域があるかどうかを確認します。

    (parted) print
    • 十分な空き容量がない場合は、既存のパーティションのサイズを変更できます。詳細は「パーティションのサイズ変更」を参照してください。
    • パーティションテーブルから、以下を確認します。

      • 新しいパーティションの開始点と終了点
      • MBR で、どのパーティションタイプにすべきか
  3. 新しいパーティションを作成します。

    (parted) mkpart part-type name fs-type start end
    • part-type を、パーティションテーブルに基づき primarylogical、または extended に置き換えます。これは MBR パーティションテーブルにのみ適用されます。
    • name を、任意のパーティション名に置き換えます。これは GPT パーティションテーブルに必要です。
    • fs-typexfsext2ext3ext4fat16fat32hfshfs+linux-swapntfs、または reiserfs のいずれかに置き換えます。fs-type パラメーターは任意です。parted は、パーティション上にファイルシステムを作成しません。
    • startend を、パーティションの開始点と終了点を決定するサイズに置き換えます (ディスクの開始からカウントします)。512MiB20GiB1.5TiB などのサイズサフィックスを使用できます。デフォルトサイズはメガバイトです。

    例2.3 小さなプライマリーパーティションの作成

    たとえば、MBR テーブルに 1024MiB から 2048MiB までのプライマリーパーティションを作成するには、次のコマンドを使用します。

    (parted) mkpart primary 1024MiB 2048MiB

    このコマンドを実行するとすぐに変更が行われるため、実行する前によく確認してください。

  4. パーティションテーブルを表示して、作成されたパーティションのパーティションタイプ、ファイルシステムタイプ、サイズが、パーティションテーブルに正しく表示されていることを確認します。

    (parted) print
  5. parted シェルを終了します。

    (parted) quit
  6. 次のコマンドを使用して、システムが新しいデバイスノードを登録するまで待機します。

    # udevadm settle
  7. カーネルが新しいパーティションを認識していることを確認します。

    # cat /proc/partitions

関連情報

  • man ページの parted(8)

2.3.6. fdisk でパーティションタイプの設定

この手順では、fdisk ユーティリティーを使用してパーティションタイプまたはフラグを設定する方法を説明します。

前提条件

  • ディスクにパーティションがある。

手順

  1. インタラクティブな fdisk シェルを起動します。

    # fdisk block-device
    • block-device を、パーティションタイプを設定するデバイスへのパスに置き換えます。たとえば、/dev/sda に置き換えます。
  2. 現在のパーティションテーブルを表示して、パーティションのマイナー番号を確認します。

    Command (m for help): print

    現在のパーティションタイプは Type 列で、それに対応するタイプ ID は Id 列で確認できます。

  3. パーティションタイプコマンドを入力し、マイナー番号を使用してパーティションを選択します。

    Command (m for help): type
    Partition number (1,2,3 default 3): 2
  4. 必要に応じて、利用可能な 16 進数コードを一覧表示します。

    Hex code (type L to list all codes): L
  5. パーティションタイプを設定します。

    Hex code (type L to list all codes): 8e
  6. 変更を書き込み、fdisk シェルを終了します。

    Command (m for help): write
    The partition table has been altered.
    Syncing disks.
  7. 変更を確認します。

    # fdisk --list block-device

2.4. パーティションの削除

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

警告

パーティションを削除すると、そのパーティションに保存されているすべてのデータが削除されます。

2.4.1. ディスクのパーティション変更前の留意事項

このセクションでは、パーティションの作成、削除、またはサイズ変更を行う前に考慮すべき重要な点を説明します。

注記

このセクションでは、IBM Z アーキテクチャーに固有の DASD パーティションテーブルを説明しません。DASD の情報は、以下を参照してください。

パーティションの最大数

デバイスで使用できるパーティションの数は、パーティションテーブルの種類によって異なります。

  • マスターブートレコード (MBR) パーティションテーブルでフォーマットされたデバイスでは、次のいずれかの数だけパーティションを設定できます。

    • 最大 4 つのプライマリーパーティション
    • 最大 3 つのプライマリーパーティション、および 1 つの拡張パーティション、ならびにその拡張内に複数の論理パーティション
  • GUID パーティションテーブル (GPT) でフォーマットしたデバイスにおけるパーティションの最大数は 128 個です。GPT 仕様により、パーティションテーブル用に確保するエリアを拡大することで、さらに多くのパーティションを作成できますが、parted ユーティリティーで用いられる一般的な方法で得られるエリアは 128 個に制限されます。
注記

Red Hat では、特に理由がない限り、少なくとも swap/boot/、および / (root) のパーティションを作成することが推奨されます。

パーティションの最大サイズ

デバイスのパーティションの最大サイズは、パーティションテーブルの種類により異なります。

  • マスターブートレコード (MBR) パーティションテーブルでフォーマットしたデバイスの最大サイズは 2TiB になります。
  • GUID パーティションテーブル (GPT) でフォーマットしたデバイスの最大サイズは 8ZiB になります。

2TiB を超えるパーティションを作成する場合は、ディスクを GPT でフォーマットする必要があります。

サイズ調整

parted ユーティリティーを使用した場合は、パーティションサイズを指定する際の接尾辞を選択できます。

MiB、GiB、または TiB

サイズは 2 のべき乗で表示されます。

  • パーティションの開始点は、サイズが指定する正確なセクターに調整されます。
  • 終了点は、指定されたサイズから 1 セクターを引いたサイズに調整されます。
MB、GB、または TB

サイズは 10 のべき乗で表示されます。

開始点と終了点は、指定された単位の半分以内に置かれます。たとえば、接尾辞 MB を使用する場合は ±500 KB です。

2.4.2. parted でパーティションの削除

この手順では、parted ユーティリティーを使用してディスクパーティションを削除する方法を説明します。

手順

  1. インタラクティブな parted シェルを起動します。

    # parted block-device
    • block-device を、パーティションを削除するデバイスへのパス (例: /dev/sda) に置き換えます。
  2. 現在のパーティションテーブルを表示して、削除するパーティションのマイナー番号を確認します。

    (parted) print
  3. パーティションを削除します。

    (parted) rm minor-number
    • minor-number を、削除するパーティションのマイナー番号 (例: 3) に置き換えます。

    このコマンドを実行するとすぐに変更が行われるため、実行する前によく確認してください。

  4. パーティションテーブルからパーティションが削除されたことを確認します。

    (parted) print
  5. parted シェルを終了します。

    (parted) quit
  6. パーティションが削除されたことをカーネルが認識していることを確認します。

    # cat /proc/partitions
  7. パーティションが存在する場合は、/etc/fstab ファイルからパーティションを削除します。削除したパーティションを宣言している行を見つけ、ファイルから削除します。
  8. システムが新しい /etc/fstab 設定を登録するように、マウントユニットを再生成します。

    # systemctl daemon-reload
  9. スワップパーティション、または LVM 部分を削除した場合は、/etc/default/grub ファイルのカーネルコマンドラインからパーティションへの参照をすべて削除して、GRUB 設定を再生成します。

    • BIOS ベースのシステムの場合:

      # grub2-mkconfig --output=/etc/grub2.cfg
    • UEFI ベースのシステムの場合:

      # grub2-mkconfig --output=/etc/grub2-efi.cfg
  10. アーリーブートシステムに変更を登録するには、initramfs ファイルシステムを再構築します。

    # dracut --force --verbose

関連情報

  • man ページの parted(8)

2.5. パーティションのサイズ変更

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

2.5.1. ディスクのパーティション変更前の留意事項

このセクションでは、パーティションの作成、削除、またはサイズ変更を行う前に考慮すべき重要な点を説明します。

注記

このセクションでは、IBM Z アーキテクチャーに固有の DASD パーティションテーブルを説明しません。DASD の情報は、以下を参照してください。

パーティションの最大数

デバイスで使用できるパーティションの数は、パーティションテーブルの種類によって異なります。

  • マスターブートレコード (MBR) パーティションテーブルでフォーマットされたデバイスでは、次のいずれかの数だけパーティションを設定できます。

    • 最大 4 つのプライマリーパーティション
    • 最大 3 つのプライマリーパーティション、および 1 つの拡張パーティション、ならびにその拡張内に複数の論理パーティション
  • GUID パーティションテーブル (GPT) でフォーマットしたデバイスにおけるパーティションの最大数は 128 個です。GPT 仕様により、パーティションテーブル用に確保するエリアを拡大することで、さらに多くのパーティションを作成できますが、parted ユーティリティーで用いられる一般的な方法で得られるエリアは 128 個に制限されます。
注記

Red Hat では、特に理由がない限り、少なくとも swap/boot/、および / (root) のパーティションを作成することが推奨されます。

パーティションの最大サイズ

デバイスのパーティションの最大サイズは、パーティションテーブルの種類により異なります。

  • マスターブートレコード (MBR) パーティションテーブルでフォーマットしたデバイスの最大サイズは 2TiB になります。
  • GUID パーティションテーブル (GPT) でフォーマットしたデバイスの最大サイズは 8ZiB になります。

2TiB を超えるパーティションを作成する場合は、ディスクを GPT でフォーマットする必要があります。

サイズ調整

parted ユーティリティーを使用した場合は、パーティションサイズを指定する際の接尾辞を選択できます。

MiB、GiB、または TiB

サイズは 2 のべき乗で表示されます。

  • パーティションの開始点は、サイズが指定する正確なセクターに調整されます。
  • 終了点は、指定されたサイズから 1 セクターを引いたサイズに調整されます。
MB、GB、または TB

サイズは 10 のべき乗で表示されます。

開始点と終了点は、指定された単位の半分以内に置かれます。たとえば、接尾辞 MB を使用する場合は ±500 KB です。

2.5.2. parted でパーティションのサイズ変更

この手順では、parted ユーティリティーを使用してディスクパーティションのサイズを変更する方法を説明します。

前提条件

  • パーティションを縮小する場合は、そこに格納されているデータのバックアップを作成する。

    警告

    パーティションを縮小すると、パーティションのデータが失われる可能性があります。

  • パーティションを 2TiB を超えるサイズに変更する場合は、ディスクを GUID パーティションテーブル (GPT) でフォーマットする必要があります。ディスクのフォーマット方法の詳細は、「ディスクへのパーティションテーブルの作成」を参照してください。

手順

  1. パーティションを縮小する場合は、サイズを変更したパーティションより大きくならないように、最初にファイルシステムを縮小してください。XFS は、縮小をサポートしていないことに注意してください。
  2. インタラクティブな parted シェルを起動します。

    # parted block-device
    • block-device を、パーティションのサイズ変更を行うデバイスへのパス (例: /dev/sda) に置き換えます。
  3. 現在のパーティションテーブルを表示します。

    (parted) print

    パーティションテーブルから、以下を確認します。

    • パーティションのマイナー番号
    • 既存のパーティションの位置とサイズ変更後の新しい終了点
  4. パーティションのサイズを変更します。

    (parted) resizepart minor-number new-end
    • minor-number を、サイズを変更するパーティションのマイナー番号 (例: 3) に置き換えます。
    • new-end を、サイズを変更するパーティションの新しい終了点を決定するサイズに置き換えます (ディスクの開始からカウントします)。512MiB20GiB1.5TiB などのサイズサフィックスを使用できます。デフォルトサイズはメガバイトです。

    例2.4 パーティションの拡張

    たとえば、ディスクの先頭にあるパーティションを 2GiB のサイズに拡張するには、次のコマンドを使用します。

    (parted) resizepart 1 2GiB

    このコマンドを実行するとすぐに変更が行われるため、実行する前によく確認してください。

  5. パーティションテーブルを表示して、サイズ変更したパーティションのサイズが、パーティションテーブルで正しく表示されていることを確認します。

    (parted) print
  6. parted シェルを終了します。

    (parted) quit
  7. カーネルが新しいパーティションを認識していることを確認します。

    # cat /proc/partitions
  8. パーティションを拡張した場合は、そこにあるファイルシステムも拡張します。詳細は (参考) を参照してください。

関連情報

  • man ページの parted(8)

第3章 永続的な命名属性の概要

システム管理者は、永続的な命名属性を使用してストレージボリュームを参照し、再起動を何度も行っても信頼できるストレージ設定を構築する必要があります。

3.1. 非永続的な命名属性のデメリット

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

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

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

  • システム起動プロセスの並列化により、システム起動ごとに異なる順序でストレージデバイスが検出された場合。
  • ディスクが起動しなかったり、SCSI コントローラーに応答しなかった場合。この場合は、通常のデバイスプローブにより検出されません。ディスクはシステムにアクセスできなくなり、後続のデバイスは関連する次の sd 名が含まれる、メジャー番号およびマイナー番号の範囲があります。たとえば、通常 sdb と呼ばれるディスクが検出されないと、sdc と呼ばれるディスクが sdb として代わりに表示されます。
  • SCSI コントローラー (ホストバスアダプターまたは HBA) が初期化に失敗し、その HBA に接続されているすべてのディスクが検出されなかった場合。後続のプローブされた HBA に接続しているディスクは、別のメジャー番号およびマイナー番号の範囲、および関連する別の sd 名が割り当てられます。
  • システムに異なるタイプの HBA が存在する場合は、ドライバー初期化の順序が変更する可能性があります。これにより、HBA に接続されているディスクが異なる順序で検出される可能性があります。また、HBA がシステムの他の PCI スロットに移動した場合でも発生する可能性があります。
  • ストレージアレイや干渉するスイッチの電源が切れた場合など、ストレージデバイスがプローブされたときに、ファイバーチャネル、iSCSI、または FCoE アダプターを持つシステムに接続されたディスクがアクセスできなくなる可能性があります。システムが起動するまでの時間よりもストレージアレイがオンラインになるまでの時間の方が長い場合に、電源の障害後にシステムが再起動すると、この問題が発生する可能性があります。一部のファイバーチャネルドライバーは WWPN マッピングへの永続 SCSI ターゲット ID を指定するメカニズムをサポートしますが、メジャー番号およびマイナー番号の範囲や関連する sd 名は予約されず、一貫性のある SCSI ターゲット ID 番号のみが提供されます。

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

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

3.2. ファイルシステムおよびデバイスの識別子

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

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

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

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

  • 一意の ID (UUID)
  • ラベル

デバイスの識別子

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

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

  • World Wide Identifier (WWID)
  • パーティション UUID
  • シリアル番号

推奨事項

  • 論理ボリュームなどの一部のファイルシステムは、複数のデバイスにまたがっています。Red Hat は、デバイスの識別子ではなくファイルシステムの識別子を使用してこのファイルシステムにアクセスすることをお勧めします。

3.3. /dev/disk/ にある udev メカニズムにより管理されるデバイス名

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

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

  • ストレージデバイスのコンテンツ
  • 一意の ID
  • シリアル番号

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

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

/dev/disk/by-uuid/ の UUID 属性

このディレクトリーのエントリーは、デバイスに格納されているコンテンツ (つまりデータ) 内の 一意の ID (UUID) によりストレージデバイスを参照するシンボリック名を提供します。以下に例を示します。

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

次の構文を使用することで、UUID を使用して /etc/fstab ファイルのデバイスを参照できます。

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

ファイルシステムを作成する際に UUID 属性を設定できます。後で変更することもできます。

/dev/disk/by-label/ のラベル属性

このディレクトリーのエントリーは、デバイスに格納されているコンテンツ (つまりデータ) 内の ラベル により、ストレージデバイスを参照するシンボリック名を提供します。

以下に例を示します。

/dev/disk/by-label/Boot

次の構文を使用することで、ラベルを使用して /etc/fstab ファイルのデバイスを参照できます。

LABEL=Boot

ファイルシステムを作成するときにラベル属性を設定できます。また、後で変更することもできます。

3.3.2. デバイスの識別子

/dev/disk/by-id/ の WWID 属性

World Wide Identifier (WWID) は永続的で、SCSI 規格によりすべての SCSI デバイスが必要とする システムに依存しない識別子 です。各ストレージデバイスの WWID 識別子は一意となることが保証され、デバイスのアクセスに使用されるパスに依存しません。この識別子はデバイスのプロパティですが、デバイスのコンテンツ (つまりデータ) には格納されません。

この識別子は、SCSI Inquiry を発行して Device Identification Vital Product Data (0x83 ページ) または Unit Serial Number (0x80 ページ) を取得することにより獲得できます。

Red Hat Enterprise Linux では、WWID ベースのデバイス名から、そのシステムの現在の /dev/sd 名への正しいマッピングを自動的に維持します。デバイスへのパスが変更したり、別のシステムからそのデバイスへのアクセスがあった場合にも、アプリケーションはディスク上のデータ参照に /dev/disk/by-id/ を使用できます。

例3.1 WWID マッピング

WWID シンボリックリンク非永続的なデバイス備考

/dev/disk/by-id/scsi-3600508b400105e210000900000490000

/dev/sda

ページ 0x83 の識別子を持つデバイス

/dev/disk/by-id/scsi-SSEAGATE_ST373453LW_3HW1RHM6

/dev/sdb

ページ 0x80 の識別子を持つデバイス

/dev/disk/by-id/ata-SAMSUNG_MZNLN256HMHQ-000L7_S2WDNX0J336519-part3

/dev/sdc3

ディスクパーティション

システムにより提供される永続的な名前のほかに、udev ルールを使用して独自の永続的な名前を実装し、ストレージの WWID にマップすることもできます。

/dev/disk/by-partuuid のパーティション UUID 属性

パーティション UUID (PARTUUID) 属性は、GPT パーティションテーブルにより定義されているパーティションを識別します。

例3.2 パーティション UUID のマッピング

PARTUUID シンボリックリンク非永続的なデバイス

/dev/disk/by-partuuid/4cd1448a-01

/dev/sda1

/dev/disk/by-partuuid/4cd1448a-02

/dev/sda2

/dev/disk/by-partuuid/4cd1448a-03

/dev/sda3

/dev/disk/by-path/ のパス属性

この属性は、デバイスへのアクセスに使用される ハードウェアパス がストレージデバイスを参照するシンボル名を提供します。

警告

パス属性は信頼性が低く、Red Hat では使用をお勧めしていません。

3.4. DM Multipath を使用した World Wide Identifier

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

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

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

  • Host:Channel:Target:LUN
  • /dev/sd
  • major:minor 数値

例3.3 マルチパス構成での WWID マッピング

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 名は、そのファイルが維持されている限り永続的です。

重要

user_friendly_names を使用する場合は、クラスター内で一貫した名前を取得するために追加の手順が必要です。

3.5. udev デバイス命名規則の制約

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

  • udev イベントに対して udev ルールが処理されるときに、udev メカニズムはストレージデバイスをクエリーする機能に依存する可能性があるため、クエリーの実行時にデバイスにアクセスできない可能性があります。これは、ファイバーチャネル、iSCSI、または FCoE ストレージデバイスといった、デバイスがサーバーシャーシにない場合に発生する可能性が高くなります。
  • カーネルは udev イベントをいつでも送信する可能性があるため、デバイスにアクセスできない場合に /dev/disk/by-*/ リンクが削除される可能性があります。
  • udev イベントが生成されそのイベントが処理されるまでに遅延が生じる場合があります (大量のデバイスが検出され、ユーザー空間の udev サービスによる各デバイスのルールを処理するのにある程度の時間がかかる場合など)。これにより、カーネルがデバイスを検出してから、/dev/disk/by-*/ の名前が利用できるようになるまでに遅延が生じる可能性があります。
  • ルールに呼び出される blkid などの外部プログラムによってデバイスが短期間開き、他の目的でデバイスにアクセスできなくなる可能性があります。

3.6. 永続的な命名属性の一覧表示

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

手順

  • UUID 属性とラベル属性を一覧表示するには、lsblk ユーティリティーを使用します。

    $ lsblk --fs storage-device

    以下に例を示します。

    例3.4 ファイルシステムの UUID とラベルの表示

    $ lsblk --fs /dev/sda1
    
    NAME FSTYPE LABEL UUID                                 MOUNTPOINT
    sda1 xfs    Boot  afa5d5e3-9050-48c3-acc1-bb30095f3dc4 /boot
  • PARTUUID 属性を一覧表示するには、--output +PARTUUID オプションを指定して lsblk ユーティリティーを使用します。

    $ lsblk --output +PARTUUID

    以下に例を示します。

    例3.5 パーティションの PARTUUID 属性の表示

    $ lsblk --output +PARTUUID /dev/sda1
    
    NAME MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT PARTUUID
    sda1   8:1    0  512M  0 part /boot      4cd1448a-01
  • WWID 属性を一覧表示するには、/dev/disk/by-id/ ディレクトリーのシンボリックリンクのターゲットを調べます。以下に例を示します。

    例3.6 システムにある全ストレージデバイスの WWID の表示

    $ file /dev/disk/by-id/*
    
    /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001
    symbolic link to ../../sda
    /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1
    symbolic link to ../../sda1
    /dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2
    symbolic link to ../../sda2
    /dev/disk/by-id/dm-name-rhel_rhel8-root
    symbolic link to ../../dm-0
    /dev/disk/by-id/dm-name-rhel_rhel8-swap
    symbolic link to ../../dm-1
    /dev/disk/by-id/dm-uuid-LVM-QIWtEHtXGobe5bewlIUDivKOz5ofkgFhP0RMFsNyySVihqEl2cWWbR7MjXJolD6g
    symbolic link to ../../dm-1
    /dev/disk/by-id/dm-uuid-LVM-QIWtEHtXGobe5bewlIUDivKOz5ofkgFhXqH2M45hD2H9nAf2qfWSrlRLhzfMyOKd
    symbolic link to ../../dm-0
    /dev/disk/by-id/lvm-pv-uuid-atlr2Y-vuMo-ueoH-CpMG-4JuH-AhEF-wu4QQm
    symbolic link to ../../sda2

3.7. 永続的な命名属性の変更

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

注記

udev 属性の変更はバックグラウンドで行われ、時間がかかる場合があります。udevadm settle コマンドは変更が完全に登録されるまで待機します。これにより、次のコマンドが新しい属性を正しく利用できるようになります。

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

  • new-uuid を、設定する UUID (例: 1cdfbc07-1c90-4984-b5ec-f61943f5ea50) に置き換えます。uuidgen コマンドを使用して UUID を生成できます。
  • new-label を、ラベル (例: backup_data) に置き換えます。

前提条件

  • XFS ファイルシステムをアンマウントしている (XFS ファイルシステムの属性を変更する場合)。

手順

  • XFS ファイルシステムの UUID またはラベル属性を変更するには、xfs_admin ユーティリティーを使用します。

    # xfs_admin -U new-uuid -L new-label storage-device
    # udevadm settle
  • ext4 ファイルシステム、ext3 ファイルシステム、ext2 ファイルシステムの UUID またはラベル属性を変更するには、tune2fs ユーティリティーを使用します。

    # tune2fs -U new-uuid -L new-label storage-device
    # udevadm settle
  • スワップボリュームの UUID またはラベル属性を変更するには、swaplabel ユーティリティーを使用します。

    # swaplabel --uuid new-uuid --label new-label swap-device
    # udevadm settle

第4章 NVDIMM 永続メモリーストレージの使用

システム管理者は、システムに接続した NVDIMM (Non-Volatile Dual In-line Memory Modules) デバイス上にあるさまざまなタイプのストレージの有効化および管理を行うことができます。

NVDIMM ストレージに Red Hat Enterprise Linux 8 をインストールする場合は、代わりに「NVDIMM デバイスへのインストール」を参照してください。

4.1. NVDIMM 永続メモリーテクノロジー

ストレージクラスメモリーまたは pmem と呼ばれる NVDIMM 永続メモリーは、メモリーとストレージを組み合わせたものになります。

NVDIMM は、ストレージの耐久性に加え、低アクセスレイテンシーと動的な DRAM の広帯域幅を採用しています。

  • NVDIMM ストレージはバイト単位でアドレスを指定できるため、CPU 読み込みおよびストア命令でアクセスできます。従来のブロックベースのストレージへのアクセスに必要なシステムコール read() および write() の他に、NVDIMM はダイレクトロードとストアプログラミングモデルにも対応しています。
  • NVDIMM のパフォーマンス特性は、アクセスレイテンシーが非常に低い DRAM と似ています。通常、数万 ~ 数十万ナノ秒です。
  • NVDIMM に格納されたデータは、ストレージのように電源がオフになった際に保持されます。
  • ダイレクトアクセス (DAX) テクノロジーでは、システムページキャッシュを介することなく、アプリケーションが直接ストレージをマッピングできるようになります。これにより、別の目的で DRAM を解放します。

NVDIMM は、次のようなユースケースでメリットがあります。

データベース
NVDIMM のストレージのアクセスのレイテンシーを削減すると、データベースのパフォーマンスが大幅に向上する可能性があります。
高速な再起動

高速な再起動は、ウォームキャッシュ効果とも呼ばれます。たとえば、ファイルサーバーは起動後、メモリー内にファイルコンテンツを持ちません。クライアントがデータを接続して読み書きすると、そのデータはページキャッシュにキャッシュされます。最終的に、キャッシュには、ほとんどのホットデータが含まれます。再起動後、システムは従来のストレージで再度プロセスを開始する必要があります。

NVDIMM により、アプリケーションが適切に設計されていれば、アプリケーションで再起動間のウォームキャッシュを維持できるようになります。この例には、ページキャッシュは含まれません。アプリケーションは、永続メモリーに直接データをキャッシュします。

高速書き込みキャッシュ
ファイルサーバーは多くの場合、耐久性のあるメディアにデータが存在するまで、クライアントの書き込み要求を承認しません。NVDIMM を高速書き込みキャッシュとして使用することで、ファイルサーバーは、低レイテンシーにより迅速に書き込み要求を確認できるようになります。

4.2. NVDIMM のインターリービングおよび地域

NVDIMM デバイスは、インターリーブリージョンへのグループ化に対応しています。

NVDIMM デバイスは、通常の DRAM と同じ方法でインターリーブセットにグループ化できます。インターリーブセットは、複数の DIMM にまたがる RAID 0 レベル (ストライプ) 設定と似ています。インターリーブセットは、リージョン とも呼ばれます。

インターリービングには、以下の利点があります。

  • NVDIMM は、インターリーブセットに設定するとパフォーマンスが向上します。
  • インターリービングは、複数の小さな NVDIMM デバイスを大きな論理デバイスに組み合わせます。

NVDIMM インターリーブセットは、システムの BIOS または UEFI ファームウェアで設定されます。

Red Hat Enterprise Linux は、各インターリーブセットにリージョンデバイスを作成します。

4.3. NVDIMM 名前空間

NVDIMM リージョンは複数の名前空間に分けられます。名前空間では、名前空間のタイプに基づいて、別の方法を使用してデバイスにアクセスできるようになります。

一部の NVDIMM デバイスは、任意のリージョンでの複数の名前空間に対応していません。

  • お使いの NVDIMM デバイスがラベルに対応している場合は、リージョンを名前空間に分割できます。
  • NVDIMM デバイスがラベルに対応していない場合は、リージョンに名前空間を 1 つだけ追加できます。この場合、Red Hat Enterprise Linux は、リージョン全体に対応するデフォルトの名前空間を作成します。

4.4. NVDIMM アクセスモード

NVDIMM 名前空間で、以下のいずれかのモードを使用するように設定できます。

sector

ストレージを高速ブロックデバイスとして示します。このモードは、NVDIMM ストレージを使用するように変更されていない従来のアプリケーションや、デバイスマッパーを含む完全な I/O スタックを利用するアプリケーションに役に立ちます。

セクター デバイスは、システム上のその他のブロックデバイスと同じ方法で使用できます。そこではパーティションやファイルシステムを作成し、ソフトウェア RAID セットの一部として作成したり、dm-cache のキャッシュデバイスとして使用できます

このモードのデバイスは、/dev/pmemNs で利用できます。名前空間の作成後に一覧表示される blockdev 値を参照してください。

devdax またはデバイスダイレクトアクセス (DAX)

「Storage Networking Industry Association (SNIA) 非揮発性メモリー (NVM) プログラミングモデル仕様」で説明されているように、NVDIMM デバイスがダイレクトアクセスプログラミングに対応します。このモードでは、I/O はカーネルのストレージスタックを回避します。したがって、デバイスマッパードライバーは使用できません。

デバイス DAX は、DAX キャラクターデバイスノードを使用して NVDIMM ストレージへの raw アクセスを提供します。CPU キャッシュのフラッシュ命令とフェンシング命令を使用して、devdax デバイスのデータを作成できます。特定のデータベースおよび仮想マシンのハイパーバイザーは、このモードの利点を得られます。devdax デバイスにファイルシステムを作成することはできません。

このモードのデバイスは、/dev/daxN.M で利用できます。名前空間の作成後に一覧表示される chardev 値を参照してください。

fsdax またはファイルシステムダイレクトアクセス (DAX)

「Storage Networking Industry Association (SNIA) 非揮発性メモリー (NVM) プログラミングモデル仕様」で説明されているように、NVDIMM デバイスがダイレクトアクセスプログラミングに対応します。このモードでは、I/O はカーネルのストレージスタックを回避するため、多くのデバイスマッパードライバーが使用できなくなります。

ファイルシステム DAX デバイスにファイルシステムを作成できます。

このモードのデバイスは、/dev/pmemN で利用できます。名前空間の作成後に一覧表示される blockdev 値を参照してください。

重要

ファイルシステムの DAX テクノロジーはテクノロジープレビューとしてのみ提供されるため、Red Hat では対応していません。

raw

DAX に対応していないメモリーディスクを示します。このモードでは、名前空間にいくつかの制限があるため、使用すべきではありません。

このモードのデバイスは、/dev/pmemN で利用できます。名前空間の作成後に一覧表示される blockdev 値を参照してください。

4.5. ブロックデバイスとして動作する NVDIMM 上のセクター名前空間の作成

従来のブロックベースのストレージをサポートするため、レガシーモード というセクターモードで NVDIMM デバイスを設定できます。

次のいずれかになります。

  • 既存の名前空間をセクターモードに再設定
  • 新規セクター名前空間を作成 (利用可能な領域がある場合)

前提条件

  • NVDIMM デバイスがシステムに接続されている。

4.5.1. ndctl のインストール

この手順では、NVDIMM デバイスの設定および監視に使用する ndctl ユーティリティーをインストールします。

手順

  • ndctl ユーティリティーをインストールするには、次のコマンドを使用します。

    # yum install ndctl

4.5.2. 既存の NVDIMM 名前空間のセクターモードへの再設定

この手順では、高速ブロックデバイスとして使用する NVDIMM 名前空間をセクターモードに再構成します。

警告

名前空間を再設定すると、名前空間に保存しておいたすべてのデータが削除されます。

前提条件

手順

  1. 選択した名前空間をセクターモードに再設定します。

    # ndctl create-namespace \
            --force \
            --reconfig=namespace-ID \
            --mode=sector

    例4.1 セクターモードでの namespace1.0 の再設定

    セクターモードを使用するために namespace1.0 名前空間を再設定するには、次のコマンドを実行します。

    # ndctl create-namespace \
            --force \
            --reconfig=namespace1.0 \
            --mode=sector
    
    {
      "dev":"namespace1.0",
      "mode":"sector",
      "size":"11.99 GiB (12.87 GB)",
      "uuid":"5805480e-90e6-407e-96a4-23e1cde2ed78",
      "raw_uuid":"879d9e9f-fd43-4ed5-b64f-3bcd0781391a",
      "sector_size":4096,
      "blockdev":"pmem1s",
      "numa_node":1
    }
  2. 再設定した名前空間は、/dev/pmemNs として /dev ディレクトリーで利用できるようになります。

関連情報

  • man ページの ndctl-create-namespace(1)

4.5.3. セクターモードでの新たな NVDIMM 名前空間の作成

以下の手順では、NVDIMM デバイスで新しいセクター名前空間を作成し、従来のブロックデバイスとして使用できるようにします。

前提条件

  • ndctl ユーティリティーがインストールされている。「ndctl のインストール」を参照してください。
  • NVDIMM デバイスがラベルに対応している。

手順

  1. 利用可能な領域があるシステムの pmem リージョンの一覧を表示します。以下の例では、region5 リージョンと region4 リージョンの領域が利用できます。

    # ndctl list --regions
    
    [
      {
        "dev":"region5",
        "size":270582939648,
        "available_size":270582939648,
        "type":"pmem",
        "iset_id":-7337419320239190016
      },
      {
        "dev":"region4",
        "size":270582939648,
        "available_size":270582939648,
        "type":"pmem",
        "iset_id":-137289417188962304
      }
    ]
  2. いずれのリージョンでも、複数の名前空間を割り当てます。

    # ndctl create-namespace \
            --mode=sector \
            --region=regionN \
            --size=namespace-size

    例4.2 リージョンへの名前空間の作成

    以下のコマンドは、region4 に 36 GiB セクターの名前空間を作成します。

    # ndctl create-namespace \
            --mode=sector \
            --region=region4 \
            --size=36G
  3. 新しい名前空間が、/dev ディレクトリー配下の /dev/pmemNs として利用できます。

関連情報

  • man ページの ndctl-create-namespace(1)

4.6. NVDIMM でのデバイス DAX 名前空間の作成

デバイスの DAX モードで NVDIMM デバイスを設定すると、ダイレクトアクセス機能を備えたキャラクターストレージに対応できます。

次のいずれかになります。

  • 既存の名前空間をデバイスの DAX モードに再設定
  • 利用可能な領域がある場合は、新しいデバイスの DAX 名前空間を作成

前提条件

  • NVDIMM デバイスがシステムに接続されている。

4.6.1. デバイスのダイレクトアクセスモードの NVDIMM

デバイスダイレクトアクセス (デバイス DAX である devdax) は、ファイルシステムの関与なしで、アプリケーションがストレージに直接アクセスできる手段を提供します。デバイス DAX の利点は、ndctl ユーティリティーの --align オプションを使用して設定できる、保証されたフォールトの粒度を提供することです。

Intel 64 アーキテクチャおよび AMD64 アーキテクチャでは、以下のフォールト粒度に対応しています。

  • 4 KiB
  • 2 MiB
  • 1 GiB

デバイス DAX ノードは、以下のシステム呼び出しにのみ対応しています。

  • open()
  • close()
  • mmap()

デバイス DAX のユースケースは永続メモリープログラミングに関連付けられているため、read() バリアントおよび write() バリアントには対応していません。

4.6.2. ndctl のインストール

この手順では、NVDIMM デバイスの設定および監視に使用する ndctl ユーティリティーをインストールします。

手順

  • ndctl ユーティリティーをインストールするには、次のコマンドを使用します。

    # yum install ndctl

4.6.3. 既存の NVDIMM 名前空間をデバイス DAX モードに再構成

以下の手順では、NVDIMM デバイスで名前空間を DAX モードに再構成し、名前空間にデータを保存できるようにします。

警告

名前空間を再設定すると、名前空間に保存しておいたすべてのデータが削除されます。

前提条件

手順

  1. システムにある名前空間の一覧を表示します。

    # ndctl list --namespaces --idle
    
    [
      {
        "dev":"namespace1.0",
        "mode":"raw",
        "size":34359738368,
        "state":"disabled",
        "numa_node":1
      },
      {
        "dev":"namespace0.0",
        "mode":"raw",
        "size":34359738368,
        "state":"disabled",
        "numa_node":0
      }
    ]
  2. 名前空間を再設定します。

    # ndctl create-namespace \
            --force \
            --mode=devdax \
            --reconfig=namespace-ID

    例4.3 名前空間をデバイス DAX として再設定

    次のコマンドは、DAX に対応するデータストレージ用に namespace0.0 を再設定します。オペレーティングシステムが一度に 2 MiB ページでフォールトされるように、2 MiB フォールトの粒度に合わせて調整されます。

    # ndctl create-namespace \
            --force \
            --mode=devdax \
            --align=2M \
            --reconfig=namespace0.0
  3. 名前空間は、/dev/daxN.M パスで利用できます。

関連情報

  • man ページの ndctl-create-namespace(1)

4.6.4. デバイス DAX モードでの新しい NVDIMM 名前空間の作成

以下の手順では、NVDIMM デバイスに新たなデバイス DAX 名前空間を作成し、この名前空間にデータを保存できるようにします。

前提条件

  • ndctl ユーティリティーがインストールされている。「ndctl のインストール」を参照してください。
  • NVDIMM デバイスがラベルに対応している。

手順

  1. 利用可能な領域があるシステムの pmem リージョンの一覧を表示します。以下の例では、region5 リージョンと region4 リージョンの領域が利用できます。

    # ndctl list --regions
    
    [
      {
        "dev":"region5",
        "size":270582939648,
        "available_size":270582939648,
        "type":"pmem",
        "iset_id":-7337419320239190016
      },
      {
        "dev":"region4",
        "size":270582939648,
        "available_size":270582939648,
        "type":"pmem",
        "iset_id":-137289417188962304
      }
    ]
  2. いずれのリージョンでも、複数の名前空間を割り当てます。

    # ndctl create-namespace \
            --mode=devdax \
            --region=regionN \
            --size=namespace-size

    例4.4 リージョンへの名前空間の作成

    次のコマンドは、region4 に 36-GiB のデバイス DAX 名前空間を作成します。オペレーティングシステムが一度に 2 MiB ページでフォールトされるように、2 MiB フォールトの粒度に合わせて調整されます。

    # ndctl create-namespace \
            --mode=devdax \
            --region=region4 \
            --align=2M \
            --size=36G
    
    {
      "dev":"namespace1.2",
      "mode":"devdax",
      "map":"dev",
      "size":"35.44 GiB (38.05 GB)",
      "uuid":"5ae01b9c-1ebf-4fb6-bc0c-6085f73d31ee",
      "raw_uuid":"4c8be2b0-0842-4bcb-8a26-4bbd3b44add2",
      "daxregion":{
        "id":1,
        "size":"35.44 GiB (38.05 GB)",
        "align":2097152,
        "devices":[
          {
            "chardev":"dax1.2",
            "size":"35.44 GiB (38.05 GB)"
          }
        ]
      },
      "numa_node":1
    }
  3. 名前空間は、/dev/daxN.M パスで利用できます。

関連情報

  • man ページの ndctl-create-namespace(1)

4.7. NVDIMM でのファイルシステム DAX 名前空間の作成

NVDIMM デバイスをファイルシステム DAX モードに設定し、ダイレクトアクセス機能を備えたファイルシステムに対応します。

次のいずれかになります。

  • ファイルシステムの DAX モードに既存の名前空間を再設定
  • 新しいファイルシステム DAX 名前空間を作成 (利用可能な領域がある場合)
重要

ファイルシステムの DAX テクノロジーはテクノロジープレビューとしてのみ提供されるため、Red Hat では対応していません。

前提条件

  • NVDIMM デバイスがシステムに接続されている。

4.7.1. ファイルシステムの直接アクセスモードの NVDIMM

NVDIMM デバイスがファイルシステムダイレクトアクセス (ファイルシステム DAX (fsdax)) モードで設定されている場合は、その上にファイルシステムを作成できます。

このファイルシステムのファイルで mmap() 操作を実行するアプリケーションは、ストレージに直接アクセスします。これにより、NVDIMM 上のプログラミングモデルに直接アクセスできます。直接マッピングを行うには、ファイルシステムは -o dax オプションでマウントする必要があります。

ページごとのメタデータ割り当て

このモードでは、システム DRAM または NVDIMM デバイス自体でページごとのメタデータを割り当てる必要があります。このデータ構造のオーバーヘッドは、4KiB ページにつき 64 バイトです。

  • 小さいデバイスでは、問題なく DRAM に収まるのに十分なオーバーヘッド量があります。たとえば、16 GiB の名前区間のページ構造に必要なのは 256 MiB だけです。NVDIMM デバイスは通常小さくて高価であるため、ページトラッキングデータ構造を DRAM に格納することが推奨されます。
  • テラバイト以上のサイズの NVDIMM デバイスの場合は、ページトラッキングデータ構造の格納に必要なメモリーの量がシステム内の DRAM の量を超える可能性があります。NVDIMM の 1 TiB に対して、ページ構造だけで 16 GiB が必要です。したがって、このような場合には、NVDIMM 自体にデータ構造を保存することが推奨されます。

名前空間の設定時に --map オプションを使用して、ページごとのメタデータを保存する場所を設定できます。

  • システム RAM に割り当てるには、--map=mem を使用します。
  • NVDIMM に割り当てるには、--map=dev を使用します。
fsdax 上のパーティションおよびファイルシステム

fsdax デバイスにパーティションを作成する場合、パーティションはページの境界に調整する必要があります。Intel 64 アーキテクチャーおよび AMD64 アーキテクチャーでは、パーティションの開始と終了に最低 4 KiB のアライメントが必要です。2 MiB が優先されるアライメントです。

Red Hat Enterprise Linux 8 では、テクノロジープレビューとして、XFS および ext4 ファイルシステムの両方を NVDIMM にできます。

4.7.2. ndctl のインストール

この手順では、NVDIMM デバイスの設定および監視に使用する ndctl ユーティリティーをインストールします。

手順

  • ndctl ユーティリティーをインストールするには、次のコマンドを使用します。

    # yum install ndctl

4.7.3. ファイルシステム DAX モードへの既存の NVDIMM 名前空間の再設定

以下の手順では、NVDIMM デバイスの名前空間をファイルシステム DAX モードに再構成し、ファイルを名前空間に格納できるようにします。

警告

名前空間を再設定すると、名前空間に保存しておいたすべてのデータが削除されます。

前提条件

手順

  1. システムにある名前空間の一覧を表示します。

    # ndctl list --namespaces --idle
    
    [
      {
        "dev":"namespace1.0",
        "mode":"raw",
        "size":34359738368,
        "state":"disabled",
        "numa_node":1
      },
      {
        "dev":"namespace0.0",
        "mode":"raw",
        "size":34359738368,
        "state":"disabled",
        "numa_node":0
      }
    ]
  2. 名前空間を再設定します。

    # ndctl create-namespace \
            --force \
            --mode=fsdax \
            --reconfig=namespace-ID

    例4.5 ファイルシステム DAX としての名前空間の再設定

    DAX に対応するファイルシステムに namespace0.0 を使用するには、次のコマンドを使用します。

    # ndctl create-namespace \
            --force \
            --mode=fsdax \
            --reconfig=namespace0.0
    
    {
      "dev":"namespace0.0",
      "mode":"fsdax",
      "size":"32.00 GiB (34.36 GB)",
      "uuid":"ab91cc8f-4c3e-482e-a86f-78d177ac655d",
      "blockdev":"pmem0",
      "numa_node":0
    }
  3. これで、名前空間が、/dev/pmemN パスで利用可能になります。

関連情報

  • man ページの ndctl-create-namespace(1)

4.7.4. ファイルシステム DAX モードで新しい NVDIMM 名前空間の作成

以下の手順では、NVDIMM デバイスに新たなファイルシステム DAX 名前空間を作成し、ファイルを名前空間に格納できるようにします。

前提条件

  • ndctl ユーティリティーがインストールされている。「ndctl のインストール」を参照してください。
  • NVDIMM デバイスがラベルに対応している。

手順

  1. 利用可能な領域があるシステムの pmem リージョンの一覧を表示します。以下の例では、region5 リージョンと region4 リージョンの領域が利用できます。

    # ndctl list --regions
    
    [
      {
        "dev":"region5",
        "size":270582939648,
        "available_size":270582939648,
        "type":"pmem",
        "iset_id":-7337419320239190016
      },
      {
        "dev":"region4",
        "size":270582939648,
        "available_size":270582939648,
        "type":"pmem",
        "iset_id":-137289417188962304
      }
    ]
  2. いずれのリージョンでも、複数の名前空間を割り当てます。

    # ndctl create-namespace \
            --mode=fsdax \
            --region=regionN \
            --size=namespace-size

    例4.6 リージョンへの名前空間の作成

    次のコマンドは、region4 で 36 GiB のファイルシステム DAX 名前空間を作成します。

    # ndctl create-namespace \
            --mode=fsdax \
            --region=region4 \
            --size=36G
    
    {
      "dev":"namespace4.0",
      "mode":"fsdax",
      "size":"35.44 GiB (38.05 GB)",
      "uuid":"9c5330b5-dc90-4f7a-bccd-5b558fa881fe",
      "blockdev":"pmem4",
      "numa_node":0
    }
  3. これで、名前空間が、/dev/pmemN パスで利用可能になります。

関連情報

  • man ページの ndctl-create-namespace(1)

4.7.5. ファイルシステム DAX デバイスでのファイルシステムの作成

この手順では、ファイルシステム DAX デバイスにファイルシステムを作成し、そのファイルシステムをマウントします。

手順

  1. 必要に応じて、ファイルシステム DAX デバイス上にパーティションを作成します。「パーティションの作成」を参照してください。

    parted ツールは、デフォルトでは 1 MiB の境界にパーティションをそろえます。最初のパーティションには、パーティションの開始部分として 2 MiB を指定します。パーティションのサイズが 2 MiB の倍数である場合は、他のすべてのパーティションもそろえられます。

  2. パーティションまたは NVDIMM デバイスに XFS または ext4 ファイルシステムを作成します。

    XFS の場合は、ファイルシステムの作成時に、共有コピーオンライトのデータエクステントを無効にします。

    # mkfs.xfs -m reflink=0 fsdax-partition-or-device
  3. -o fsdax マウントオプションでファイルシステムをマウントします。

    # mount -o fsdax fsdax-partition-or-device mount-point
  4. アプリケーションは永続メモリーを使用し、ファイルを mount-point ディレクトリーに作成し、ファイルを開いて、mmap 操作を使用して直接アクセス用にファイルをマッピングできるようになりました。

関連情報

  • man ページの mkfs.xfs(8)

4.8. NVDIMM 永続メモリーのトラブルシューティング

NVDIMM デバイスで、さまざまな種類のエラーの検出および修正を行うことができます。

前提条件

  • NVDIMM デバイスがシステムに接続され、設定されている。

4.8.1. ndctl のインストール

この手順では、NVDIMM デバイスの設定および監視に使用する ndctl ユーティリティーをインストールします。

手順

  • ndctl ユーティリティーをインストールするには、次のコマンドを使用します。

    # yum install ndctl

4.8.2. S.M.A.R.T. を使用した NVDIMM 正常性 (ヘルス) の監視

一部の NVDIMM デバイスは、正常性情報を取得する S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) インターフェースに対応しています。

重要

NVDIMM 正常性を定期的に監視して、データの損失を防ぎます。「破損した NVDIMM デバイスの検出と交換」で説明しているように、S.M.A.R.T. が NVDIMM デバイスのヘルス状態について問題を報告して、置き換えます。

前提条件

  • 一部のシステムでは、次のコマンドを使用して正常性情報を取得するために、acpi_ipmi ドライバーを読み込む必要があります。

    # modprobe acpi_ipmi

手順

  • 正常性情報にアクセスするには、次のコマンドを使用します。

    # ndctl list --dimms --health
    
    ...
        {
          "dev":"nmem0",
          "id":"802c-01-1513-b3009166",
          "handle":1,
          "phys_id":22,
          "health":
          {
            "health_state":"ok",
            "temperature_celsius":25.000000,
            "spares_percentage":99,
            "alarm_temperature":false,
            "alarm_spares":false,
            "temperature_threshold":50.000000,
            "spares_threshold":20,
            "life_used_percentage":1,
            "shutdown_state":"clean"
          }
         }
    ...

関連情報

  • man ページの ndctl-list(1)

4.8.3. 破損した NVDIMM デバイスの検出と交換

システムログまたは S.M.A.R.T. に NVDIMM 関連のエラーメッセージが記録される場合は、NVDIMM デバイスがエラーを起こしていることが考えられます。この場合は、以下を行う必要があります。

  1. NVDIMM デバイスがエラーしていることを検出
  2. そこに格納されているデータをバックアップ
  3. デバイスを物理的に交換

手順

  1. 破損したデバイスを検出するには、次のコマンドを使用します。

    # ndctl list --dimms --regions --health --media-errors --human

    badblocks フィールドは、NVDIMM が破損していることを示しています。dev フィールドに名前を書き留めます。

    例4.7 NVDIMM デバイスの正常性ステータス

    以下の例では、nmem0 という名前の NVDIMM が破損しています。

    # ndctl list --dimms --regions --health --media-errors --human
    
    ...
      "regions":[
        {
          "dev":"region0",
          "size":"250.00 GiB (268.44 GB)",
          "available_size":0,
          "type":"pmem",
          "numa_node":0,
          "iset_id":"0xXXXXXXXXXXXXXXXX",
          "mappings":[
            {
              "dimm":"nmem1",
              "offset":"0x10000000",
              "length":"0x1f40000000",
              "position":1
            },
            {
              "dimm":"nmem0",
              "offset":"0x10000000",
              "length":"0x1f40000000",
              "position":0
            }
          ],
          "badblock_count":1,
          "badblocks":[
            {
              "offset":65536,
              "length":1,
              "dimms":[
                "nmem0"
              ]
            }
          ],
          "persistence_domain":"memory_controller"
        }
      ]
    }
  2. 次のコマンドを使用して、破損した NVDIMM の phys_id 属性を確認します。

    # ndctl list --dimms --human

    前述の例では、nmem0 が破損した NVDIMM になります。したがって、nmem0phys_id 属性を確認します。

    例4.8 NVDIMMs の phys_id 属性

    以下の例では、phys_id0x10 です。

    # ndctl list --dimms --human
    
    [
      {
        "dev":"nmem1",
        "id":"XXXX-XX-XXXX-XXXXXXXX",
        "handle":"0x120",
        "phys_id":"0x1c"
      },
      {
        "dev":"nmem0",
        "id":"XXXX-XX-XXXX-XXXXXXXX",
        "handle":"0x20",
        "phys_id":"0x10",
        "flag_failed_flush":true,
        "flag_smart_event":true
      }
    ]
  3. 次のコマンドを使用して、破損した NVDIMM のメモリースロットを確認します。

    # dmidecode

    出力において、Handle 識別子が、破損した NVDIMM の phys_id 属性と一致するエントリーを確認します。Locator フィールドは、破損した NVDIMM が使用するメモリースロットの一覧を表示します。

    例4.9 NVDIMM メモリースロットリスティング

    以下の例では、nmem0 デバイスが 0x0010 の識別子に一致し、DIMM-XXX-YYYY メモリースロットを使用します。

    # dmidecode
    
    ...
    Handle 0x0010, DMI type 17, 40 bytes
    Memory Device
            Array Handle: 0x0004
            Error Information Handle: Not Provided
            Total Width: 72 bits
            Data Width: 64 bits
            Size: 125 GB
            Form Factor: DIMM
            Set: 1
            Locator: DIMM-XXX-YYYY
            Bank Locator: Bank0
            Type: Other
            Type Detail: Non-Volatile Registered (Buffered)
    ...
  4. NVDIMM 上の名前空間にある全データのバックアップを作成します。NVDIMM を交換する前にデータのバックアップを作成しないと、システムから NVDIMM を削除したときにデータが失われます。

    警告

    時折、NVDIMM が完全に破損すると、バックアップが失敗することがあります。

    これを回避するためにも、「S.M.A.R.T. を使用した NVDIMM 正常性 (ヘルス) の監視」で説明しているように、S.M.A.R.T. を使用して NVDIMM デバイスを定期的に監視して、破損する前にエラーを起こしている NVDIMM を交換してください。

    次のコマンドを使用して、NVDIMM の名前空間を一覧表示します。

    # ndctl list --namespaces --dimm=DIMM-ID-number

    例4.10 NVDIMM 名前空間の一覧表示

    以下の例では、nmem0 デバイスには、バックアップが必要な名前空間の namespace0.0namespace0.2 が含まれます。

    # ndctl list --namespaces --dimm=0
    
    [
      {
        "dev":"namespace0.2",
        "mode":"sector",
        "size":67042312192,
        "uuid":"XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
        "raw_uuid":"XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
        "sector_size":4096,
        "blockdev":"pmem0.2s",
        "numa_node":0
      },
      {
        "dev":"namespace0.0",
        "mode":"sector",
        "size":67042312192,
        "uuid":"XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
        "raw_uuid":"XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
        "sector_size":4096,
        "blockdev":"pmem0s",
        "numa_node":0
      }
    ]
  5. 破損した NVDIMM を物理的に交換します。

関連情報

  • man ページの ndctl-list(1)
  • man ページの dmidecode(8)

第5章 未使用ブロックの破棄

破棄操作に対応するブロックデバイスで破棄操作を実行するか、そのスケジュールを設定できます。

5.1. ブロックの破棄操作

ブロック破棄操作では、マウントされたファイルシステムで使用されていないブロックを破棄します。これは以下に役立ちます。

  • ソリッドステートドライブ (SSD)
  • シンプロビジョニングされたストレージ

要件

ファイルシステムの基礎となるブロックデバイスは、物理的な破棄操作に対応している必要があります。

/sys/block/device/queue/discard_max_bytes ファイルの値がゼロではない場合は、物理的な破棄操作に対応しています。

5.2. ブロック破棄操作のタイプ

以下のような、さまざまな方法で破棄操作を実行できます。

バッチ破棄
ユーザーが明示的に実行します。選択したファイルシステムのすべての未使用ブロックを破棄します。
オンライン破棄
マウント時に指定されます。ユーザーによる介入なしでリアルタイムで実行されます。オンライン破棄操作は、使用中から空きに移行しているブロックのみを破棄します。
定期的な破棄
systemd サービスが定期的に実行するバッチ操作です。

すべてのタイプは、XFS ファイルシステム、ext4 ファイルシステム、および VDO で対応されています。

推奨事項

Red Hat は、バッチ破棄または周期破棄を使用することを推奨します。

以下の場合にのみ、オンライン破棄を使用してください。

  • システムのワークロードでバッチ破棄が実行できない場合
  • パフォーマンス維持にオンライン破棄操作が必要な場合

5.3. バッチブロック破棄の実行

この手順では、バッチによるブロック破棄操作を実行し、マウントされたファイルシステムの未使用ブロックを破棄します。

前提条件

  • ファイルシステムがマウントされている。
  • ファイルシステムの基礎となるブロックデバイスが物理的な破棄操作に対応している。

手順

  • fstrim ユーティリティーを使用します。

    • 選択したファイルシステムでのみ破棄を実行するには、次のコマンドを使用します。

      # fstrim mount-point
    • マウントされているすべてのファイルシステムで破棄を実行するには、次のコマンドを使用します。

      # fstrim --all

fstrim コマンドを以下のいずれかで実行している場合は、

  • 破棄操作に対応していないデバイス
  • 複数のデバイスから構成され、そのデバイスの 1 つが破棄操作に対応していない論理デバイス (LVM または MD)

次のメッセージが表示されます。

# fstrim /mnt/non_discard

fstrim: /mnt/non_discard: the discard operation is not supported

関連情報

  • man ページの fstrim(8)

5.4. オンラインブロック破棄の有効化

この手順は、サポートされるすべてのファイルシステムで、未使用のブロックを自動的に破棄するオンラインブロック破棄操作を有効にします。

手順

  • マウント時のオンライン破棄を有効にします。

    • ファイルシステムを手動でマウントするには、-o discard マウントオプションを追加します。

      # mount -o discard device mount-point
    • ファイルシステムを永続的にマウントするには、/etc/fstab ファイルのマウントエントリーに discard オプションを追加します。

関連情報

  • man ページの mount(8)
  • man ページの fstab(5)

5.5. RHEL システムロールを使用したオンラインのブロック破棄の有効化

本セクションでは、storage ロールを使用してオンラインのブロック破棄を有効にする方法を説明します。

前提条件

  • storage ロールを含む Ansible Playbook がある。

このような Playbook を適用する方法は、「ロールの適用」を参照してください。

5.5.1. オンラインのブロック破棄を有効にする Ansible Playbook の例

本セクションでは、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

5.6. 定期的なブロック破棄の有効化

この手順では、対応するすべてのファイルシステムで、未使用のブロックを定期的に破棄する systemd タイマーを有効にします。

手順

  • systemd タイマーを有効にして起動します。

    # systemctl enable --now fstrim.timer

第6章 iSCSI の使用

Red Hat Enterprise Linux 8 では、targetcli シェルをコマンドラインインターフェースとして使用し、以下の操作を実行します。

  • iSCSI ハードウェアを使用できるように iSCSI ストレージ相互接続を追加、削除、表示、監視します。
  • ファイル、ボリューム、ローカル SCSI デバイス、またはリモートシステムへの RAM ディスクで対応しているローカルストレージリソースをエクスポートします。

targetcli ツールには、組み込みタブ補完、自動補完サポート、インラインドキュメントなどのツリーベースのレイアウトがあります。

6.1. iSCSI ターゲットの作成

システム管理者は、targetcli ツールを使用して iSCSI ターゲットを追加できます。

6.1.1. targetcli のインストール

targetcli ツールをインストールして、iSCSI ストレージの相互接続を追加、監視、削除します。

手順

  1. targetcli をインストールします。

    # yum install targetcli
  2. ターゲットサービスを起動します。

    # systemctl start target
  3. システムの起動時にターゲットサービスが起動するように設定するには、次のコマンドを実行します。

    # systemctl enable target
  4. ファイアウォールの 3260 ポートを開き、ファイアウォール設定を再読み込みします。

    # firewall-cmd --permanent --add-port=3260/tcp
    Success
    
    # firewall-cmd --reload
    Success
  5. targetcli レイアウトを表示します。

    # targetcli
    /> ls
    o- /........................................[...]
      o- backstores.............................[...]
      | o- block.................[Storage Objects: 0]
      | o- fileio................[Storage Objects: 0]
      | o- pscsi.................[Storage Objects: 0]
      | o- ramdisk...............[Storage Objects: 0]
      o- iscsi...........................[Targets: 0]
      o- loopback........................[Targets: 0]

関連情報

  • man ページの targetcli

6.1.2. iSCSI ターゲットの作成

iSCSI ターゲットを作成すると、クライアントの iSCSI イニシエーターが、サーバーのストレージデバイスにアクセスできるようになります。ターゲットとイニシエーターにはどちらも一意の識別名があります。

前提条件

手順

  1. iSCSI ディレクトリーに移動します。

    /> iscsi/
    注記

    cd コマンドは、ディレクトリーを変更したり、移動するパスの一覧を表示するために使用されます。

  2. iSCSI ターゲットを作成するには、以下のいずれかのオプションを使用します。

    1. デフォルトのターゲット名を使用した iSCSI ターゲットの作成:

      /iscsi> create
      
      Created target
      iqn.2003-01.org.linux-iscsi.hostname.x8664:sn.78b473f296ff
      Created TPG1
    2. 特定の名前を使用した iSCSI ターゲットの作成:

      /iscsi> create iqn.2006-04.com.example:444
      
      Created target iqn.2006-04.com.example:444
      Created TPG1
      Here iqn.2006-04.com.example:444 is target_iqn_name

      iqn.2006-04.com.example:444 を、特定のターゲット名に置き換えます。

  3. 新たに作成されたターゲットを確認します。

    /iscsi> ls
    
    o- iscsi.......................................[1 Target]
        o- iqn.2006-04.com.example:444................[1 TPG]
            o- tpg1...........................[enabled, auth]
               o- acls...............................[0 ACL]
                o- luns...............................[0 LUN]
               o- portals.........................[0 Portal]

関連情報

  • man ページの targetcli

6.1.3. iSCSI バックストア

iSCSI バックストアは、エクスポートした LUN のデータをローカルマシンに保存するさまざまな方法に対応します。ストレージオブジェクトを作成して、バックストアが使用するリソースを定義します。管理者は、LIO (Linux-IO) が対応する以下のバックストアデバイスのいずれかを選択できます。

  • fileio バックストア - ローカルファイルシステム上の通常のファイルをディスクイメージとして使用する場合は、fileio ストレージオブジェクトを作成します。fileio バックストアを作成する方法は、「fileio ストレージオブジェクトの作成」を参照してください。
  • block バックストア - ローカルのブロックデバイスおよび論理デバイスを使用している場合には、ブロック ストレージオブジェクトを作成します。ブロック バックストアを作成する方法は、「ブロックストレージオブジェクトの作成」を参照してください。
  • pscsi バックストア - ストレージ オブジェクトが SCSI コマンドの直接パススルーに対応している場合は、PSCSI ストレージオブジェクトを作成します。pscsi バックストアを作成する方法は、「pscsi ストレージオブジェクトの作成」を参照してください。
  • ramdisk バックストア - 一時的な RAM 対応デバイスを作成する場合は、ramdisk ストレージオブジェクトを作成します。ramdisk バックストアを作成する方法は、「メモリーコピーの RAM ディスクストレージオブジェクトの作成」を参照してください。

関連情報

  • man ページの targetcli

6.1.4. fileio ストレージオブジェクトの作成

fileio ストレージオブジェクトは、write_back 操作または write_ thru 操作のいずれかに対応します。write_back 操作では、ローカルファイルシステムキャッシュが有効になります。これにより、パフォーマンスが向上しますが、データの損失のリスクが高まります。write_thru 操作を優先させるために、write_back=false を使用して write_back 操作を無効にすることが推奨されます。

前提条件

手順

  1. バックストアディレクトリーへ移動します。

    /> backstores/
  2. fileio ストレージオブジェクトを作成します。

    /> backstores/fileio create file1 /tmp/disk1.img 200M write_back=false
    
    Created fileio file1 with size 209715200
  3. 作成された fileio ストレージオブジェクトを確認します。

    /backstores> ls

関連情報

  • man ページの targetcli

6.1.5. ブロックストレージオブジェクトの作成

ブロックドライバーを使用すると、/sys/block/ ディレクトリーにあるブロックデバイスを LIO (Linux-IO) で使用できます。これには物理デバイス (HDD、SSD、CD、DVD など) および論理デバイス (ソフトウェアまたはハードウェアの RAID ボリューム、LVM ボリュームなど) が含まれます。

前提条件

手順

  1. バックストアディレクトリーへ移動します。

    /> backstores/
  2. ブロック バックストアを作成します。

    /> backstores/block create name=block_backend dev=/dev/sdb
    
    Generating a wwn serial.
    Created block storage object block_backend using /dev/vdb.
  3. 作成された ブロック ストレージオブジェクトを確認します。

    /backstores> ls
    注記

    ブロックバックストアは、論理ボリュームにも作成できます。

関連情報

  • man ページの targetcli

6.1.6. pscsi ストレージオブジェクトの作成

SCSI エミュレーションなしで SCSI コマンドの直接パススルーに対応するストレージオブジェクト、および /proc/scsi/scsilsscsi とともに表示される基盤の SCSI デバイス (SAS ハードドライブなど) で SCSI コマンドの直接パススルーに対応するストレージオブジェクトは、バックストアとして設定できます。このサブシステムでは、SCSI-3 以降に対応しています。

警告

pscsi は、上級ユーザーのみが使用してください。非対称論理ユニット割り当て (ALUA) や永続予約 (VMware ESX や vSphere で使用される永続予約など) は、通常はデバイスのファームウェアに実装されず、誤作動やクラッシュが発生する原因となることがあります。確信が持てない場合は、実稼働の設定に ブロック バックストアを使用してください。

前提条件

手順

  1. バックストアディレクトリーへ移動します。

    /> backstores/
  2. この例では、/dev/sr0 を使用して物理 SCSI デバイスである TYPE_ROM デバイスの pscsi バックストアを作成します。

    /> backstores/pscsi/ create name=pscsi_backend dev=/dev/sr0
    
    Generating a wwn serial.
    Created pscsi storage object pscsi_backend using /dev/sr0
  3. 作成した pscsi ストレージオブジェクトを確認します。

    /backstores> ls

関連情報

  • man ページの targetcli

6.1.7. メモリーコピーの RAM ディスクストレージオブジェクトの作成

メモリーコピー RAM ディスク (ramdisk) は、完全な SCSI エミュレーションと、イニシエーターのメモリーコピーを使用した個別のメモリーマッピングが含まれる RAM ディスクを提供します。これにより、マルチセッションの機能を利用できます。これは、特に実稼働環境での高速で不揮発性の大容量ストレージで有用です。

前提条件

手順

  1. バックストアディレクトリーへ移動します。

    /> backstores/
  2. 1GB RAM ディスクバックストアを作成します。

    /> backstores/ramdisk/ create name=rd_backend size=1GB
    
    Generating a wwn serial.
    Created rd_mcp ramdisk rd_backend with size 1GB.
  3. 作成した ramdisk ストレージオブジェクトを確認します。

    /backstores> ls

関連情報

  • man ページの targetcli

6.1.8. iSCSI ポータルの作成

iSCSI ポータルを作成すると、ターゲットの有効性を維持するターゲットに IP アドレスとポートが追加されます。

前提条件

手順

  1. TPG ディレクトリーに移動します。

    /iscsi> iqn.2006-04.example:444/tpg1/
  2. iSCSI ポータルを作成するには、以下のいずれかのオプションを使用します。

    1. デフォルトポータルを作成するには、デフォルトの iSCSI ポート 3260 を使用し、ターゲットがそのポートのすべての IP アドレスをリッスンできるようにします。

      /iscsi/iqn.20...mple:444/tpg1> portals/ create
      
      Using default IP port 3260
      Binding to INADDR_Any (0.0.0.0)
      Created network portal 0.0.0.0:3260
      注記

      iSCSI ターゲットが作成されると、デフォルトのポータルも作成されます。このポータルは、デフォルトのポート番号 0.0.0.0:3260 ですべての IP アドレスをリッスンするように設定されます。

      デフォルトポータルを削除するには、次のコマンドを実行します。

      /iscsi/iqn-name/tpg1/portals delete ip_address=0.0.0.0 ip_port=3260

    2. 特定の IP アドレスを使用したポータルの作成:

      /iscsi/iqn.20...mple:444/tpg1> portals/ create 192.168.122.137
      
      Using default IP port 3260
      Created network portal 192.168.122.137:3260
  3. 新たに作成されたポータルを確認します。

    /iscsi/iqn.20...mple:444/tpg1> ls
    
    o- tpg.................................. [enambled, auth]
        o- acls ......................................[0 ACL]
        o- luns ......................................[0 LUN]
        o- portals ................................[1 Portal]
           o- 192.168.122.137:3260......................[OK]

関連情報

  • man ページの targetcli

6.1.9. iSCSI LUN の作成

論理ユニット番号 (LUN) は、iSCSI バックストアで対応している物理デバイスです。各 LUN には固有の番号があります。

前提条件

手順

  1. 作成したストレージオブジェクトの LUN を作成します。

    /iscsi/iqn.20...mple:444/tpg1> luns/ create /backstores/ramdisk/rd_backend
    Created LUN 0.
    
    /iscsi/iqn.20...mple:444/tpg1> luns/ create /backstores/block/block_backend
    Created LUN 1.
    
    /iscsi/iqn.20...mple:444/tpg1> luns/ create /backstores/fileio/file1
    Created LUN 2.
  2. 作成した LUN を確認します。

    /iscsi/iqn.20...mple:444/tpg1> ls
    
    o- tpg.................................. [enambled, auth]
        o- acls ......................................[0 ACL]
        o- luns .....................................[3 LUNs]
        |  o- lun0.........................[ramdisk/ramdisk1]
        |  o- lun1.................[block/block1 (/dev/vdb1)]
        |  o- lun2...................[fileio/file1 (/foo.img)]
        o- portals ................................[1 Portal]
            o- 192.168.122.137:3260......................[OK]

    デフォルトの LUN 名は 0 から始まります。

    重要

    デフォルトでは、読み書きパーミッションを持つ LUN が作成されます。ACL の作成後に新しい LUN が追加されると、LUN は自動的に利用可能なすべての ACL にマッピングされ、セキュリティー上のリスクが発生します。読み取り専用パーミッションで LUN を作成するには、「読み取り専用の iSCSI LUN の作成」を参照してください。

  3. ACL を設定します。詳細は「iSCSI ACL の作成」を参照してください。

関連情報

  • man ページの targetcli

6.1.10. 読み取り専用の iSCSI LUN の作成

デフォルトでは、読み書きパーミッションを持つ LUN が作成されます。この手順では、読み取り専用の LUN を作成する方法を説明します。

前提条件

手順

  1. 読み取り専用パーミッションを設定します。

    /> set global auto_add_mapped_luns=false
    
    Parameter auto_add_mapped_luns is now 'false'.

    これにより、LUN が既存の ACL へ自動的にマッピングされないようになり、LUN を手動でマッピングできるようになります。

  2. LUN を作成します。

    /> iscsi/target_iqn_name/tpg1/acls/initiator_iqn_name/ create mapped_lun=next_sequential_LUN_number tpg_lun_or_backstore=backstore write_protect=1

    例:

    /> iscsi/iqn.2006-04.example:444/tpg1/acls/2006-04.com.example.foo:888/ create mapped_lun=1 tpg_lun_or_backstore=/backstores/block/block2 write_protect=1
    
    Created LUN 1.
    Created Mapped LUN 1.
  3. 作成した LUN を確認します。

    /> ls
    
    o- / ...................................................... [...]
      o- backstores ........................................... [...]
      <snip>
      o- iscsi ......................................... [Targets: 1]
      | o- iqn.2006-04.example:444 .................. [TPGs: 1]
      |   o- tpg1 ............................ [no-gen-acls, no-auth]
      |     o- acls ....................................... [ACLs: 2]
      |     | o- 2006-04.com.example.foo:888 .. [Mapped LUNs: 2]
      |     | | o- mapped_lun0 .............. [lun0 block/disk1 (rw)]
      |     | | o- mapped_lun1 .............. [lun1 block/disk2 (ro)]
      |     o- luns ....................................... [LUNs: 2]
      |     | o- lun0 ...................... [block/disk1 (/dev/vdb)]
      |     | o- lun1 ...................... [block/disk2 (/dev/vdc)]
      <snip>

    (mapped_lun0 の (rw) とは異なり) mapped_lun1 行の最後に (ro) が表示されますが、これは、読み取り専用であることを表しています。

  4. ACL を設定します。詳細は「iSCSI ACL の作成」を参照してください。

関連情報

  • man ページの targetcli

6.1.11. iSCSI ACL の作成

targetcli では、アクセス制御リスト (ACL) は、アクセスルールの定義に使用され、各イニシエーターは LUN への排他的なアクセスを持ちます。ターゲットとイニシエーターにはどちらも一意の識別名があります。ACL を設定するには、イニシエーターの一意の名前を知っている必要があります。iSCSI イニシエーターは /etc/iscsi/initiatorname.iscsi ファイルで確認できます。

前提条件

手順

  1. acls ディレクトリーへ移動

    /iscsi/iqn.20...mple:444/tpg1> acls/
  2. ACL を作成するには、以下のいずれかのオプションを指定します。

    1. イニシエーターの /etc/iscsi/initiatorname.iscsi ファイルからのイニシエーター名の使用。
    2. 覚えやすい名前を使用します。ACL がイニシエーターと一致するようにするには、「iSCSI イニシエーターの作成」セクションを参照してください。

      /iscsi/iqn.20...444/tpg1/acls> create iqn.2006-04.com.example.foo:888
      
      Created Node ACL for iqn.2006-04.com.example.foo:888
      Created mapped LUN 2.
      Created mapped LUN 1.
      Created mapped LUN 0.
      注記

      前述の例で使用したグローバル設定の auto_add_mapped_luns は、作成した ACL に自動的にマッピングします。

      ターゲットサーバーの TPG ノードに、ユーザーが作成した ACL を設定します。

      /iscsi/iqn.20...scsi:444/tpg1> set attribute generate_node_acls=1
  3. 作成した ACL を確認します。

    /iscsi/iqn.20...444/tpg1/acls> ls
    
    o- acls .................................................[1 ACL]
        o- iqn.2006-04.com.example.foo:888 ....[3 Mapped LUNs, auth]
            o- mapped_lun0 .............[lun0 ramdisk/ramdisk1 (rw)]
            o- mapped_lun1 .................[lun1 block/block1 (rw)]
            o- mapped_lun2 .................[lun2 fileio/file1 (rw)]

関連情報

  • man ページの targetcli

6.1.12. iSCSI イニシエーターの作成

iSCSI イニシエーターは iSCSI ターゲットに接続するセッションを形成します。iSCSI ターゲットの詳細は、「iSCSI ターゲットの作成」を参照してください。デフォルトでは、iSCSI サービスは起動に 時間がかかりiscsiadm コマンドの実行後にサービスが起動します。root が iSCSI デバイスにない場合や、node.startup = automatic でマークされたノードがない場合は、iscsiadm コマンドが実行するまで iSCSI サービスが起動しなくなります。これには、カーネルモジュール iscsid または iscsi の起動が必要になります。

iscsid デーモンを強制的に実行して、iSCSI カーネルモジュールを読み込むには、次のコマンドを実行します。

# systemctl start iscsid.service

前提条件

手順

  1. クライアントマシンに iscsi-initiator-utils をインストールします。

    # yum install iscsi-initiator-utils
  2. イニシエーター名を確認します。

    # cat /etc/iscsi/initiatorname.iscsi
    
    InitiatorName=2006-04.com.example.foo:888
  3. 「iSCSI ACL の作成」の ACL にカスタム名を付けた場合は、それに応じて /etc/iscsi/initiatorname.iscsi ファイルを変更します。

    # vi /etc/iscsi/initiatorname.iscsi
  4. ターゲットを検出し、表示されたターゲット IQN でターゲットにログインします。

    # iscsiadm -m discovery -t st -p 10.64.24.179
        10.64.24.179:3260,1 iqn.2006-04.example:444
    
    # iscsiadm -m node -T iqn.2006-04.example:444 -l
        Logging in to [iface: default, target: iqn.2006-04.example:444, portal: 10.64.24.179,3260] (multiple)
        Login to [iface: default, target: iqn.2006-04.example:444, portal: 10.64.24.179,3260] successful.

    10.64.24.179 を、target-ip-address に置き換えます。

    この手順では、「iSCSI ACL の作成」の説明に従ってイニシエーター名を ACL に追加していけば、同じターゲットに接続しているイニシエーターをいくつでも作成できます。

  5. iSCSI ディスク名を確認して、この iSCSI ディスクにファイルシステムを作成します。

    # grep "Attached SCSI" /var/log/messages
    
    # mkfs.ext4 /dev/disk_name

    disk_name を、/var/log/messages ファイルに記載されている iSCSI ディスク名に置き換えます。

  6. ファイルシステムをマウントします。

    # mkdir /mount/point
    
    # mount /dev/disk_name /mount/point

    /mount/point を、パーティションのマウントポイントに置き換えます。

  7. システムの起動時にファイルシステムを自動的にマウントするように /etc/fstab を編集します。

    # vi /etc/fstab
    
    /dev/disk_name /mount/point ext4 _netdev 0 0

    disk_name を iSCSI ディスク名に置き換え、/mount/point を、パーティションのマウントポイントに置き換えます。

関連情報

  • man ページの targetcli
  • man ページの iscsiadm

6.1.13. ターゲットのチャレンジハンドシェイク認証プロトコルの設定

ユーザーは、チャレンジハンドシェイク認証プロトコル (CHAP) を使用して、パスワードでターゲットを保護できます。イニシエーターは、このパスワードでターゲットに接続できることを認識している必要があります。

前提条件

手順

  1. 属性認証を設定します。

    /iscsi/iqn.20...mple:444/tpg1> set attribute authentication=1
    
    Parameter authentication is now '1'.
  2. ユーザー IDパスワード を設定します。

    /tpg1> set auth userid=redhat
    Parameter userid is now 'redhat'.
    
    /iscsi/iqn.20...689dcbb3/tpg1> set auth password=redhat_passwd
    Parameter password is now 'redhat_passwd'.

関連情報

  • man ページの targetcli

6.1.14. イニシエーター用のチャレンジハンドシェイク認証プロトコルの設定

ユーザーは、チャレンジハンドシェイク認証プロトコル (CHAP) を使用して、パスワードでターゲットを保護できます。イニシエーターは、このパスワードでターゲットに接続できることを認識している必要があります。

前提条件

手順

  1. iscsid.conf ファイルで CHAP 認証を有効にします。

    # vi /etc/iscsi/iscsid.conf
    
    node.session.auth.authmethod = CHAP

    デフォルトでは、node.session.auth.authmethodNone に設定されています。

  2. ターゲットの ユーザー名パスワードiscsid.conf ファイルに追加します。

    node.session.auth.username = redhat
    node.session.auth.password = redhat_passwd
  3. iscsid デーモンを起動します。

    # systemctl start iscsid.service

関連情報

  • man ページの iscsiadm

6.2. iSCSI セッションの監視

システム管理者は、iscsiadm ユーティリティーを使用して iSCSI セッションを監視できます。

6.2.1. iscsiadm ユーティリティーで iSCSI セッションの監視

この手順では、iscsiadm ユーティリティーを使用して iscsi セッションを監視する方法を説明します。

デフォルトでは、iSCSI サービスは起動に 時間がかかりiscsiadm コマンドの実行後にサービスが起動します。root が iSCSI デバイスにない場合や、node.startup = automatic でマークされたノードがない場合は、iscsiadm コマンドが実行するまで iSCSI サービスが起動しなくなります。これには、カーネルモジュール iscsid または iscsi の起動が必要になります。

iscsid デーモンを強制的に実行して、iSCSI カーネルモジュールを読み込むには、次のコマンドを実行します。

# systemctl start iscsid.service

前提条件

  • クライアントマシンに iscsi-initiator-utils をインストールしている。

    yum install iscsi-initiator-utils

手順

  1. 実行中のセッションに関する情報を検索します。

    # iscsiadm -m session -P 3

    このコマンドは、セッションまたはデバイスの状態、セッション ID (sid)、いくつかのネゴシエートしたパラメーター、およびセッション経由でアクセス可能な SCSI デバイスを表示します。

    • より短い出力 (たとえば sid とノード 間のマッピングのみの表示) には、次のコマンドを実行します。

      # iscsiadm -m session -P 0
              or
      # iscsiadm -m session
      
      tcp [2] 10.15.84.19:3260,2 iqn.1992-08.com.netapp:sn.33615311
      tcp [3] 10.15.85.19:3260,3 iqn.1992-08.com.netapp:sn.33615311

      このコマンドは、driver [sid] target_ip:port,target_portal_group_tag proper_target_name の形式で実行中のセッションの一覧を表示します。

関連情報

  • /usr/share/doc/iscsi-initiator-utils-version/README ファイル
  • man ページの iscsiadm

6.3. iSCSI ターゲットの削除

システム管理者は、iSCSI ターゲットを削除できます。

6.3.1. targetcli ツールで iSCSI オブジェクトの削除

この手順では、targetcli ツールを使用して iSCSI オブジェクトを削除する方法を説明します。

手順

  1. ターゲットからログオフします。

    # iscsiadm -m node -T iqn.2006-04.example:444 -u

    ターゲットへのログイン方法は「iSCSI イニシエーターの作成」を参照してください。

  2. ACL、LUN、およびポータルのすべてを含め、ターゲット全体を削除します。

    /> iscsi/ delete iqn.2006-04.com.example:444

    iqn.2006-04.com.example:444 を target_iqn_name に置き換えます。

    • iSCSI バックストアを削除するには、次のコマンドを実行します。

      /> backstores/backstore-type/ delete block_backend
      • backstore-typefileioblockpscsi、または ramdisk に置き換えます。
      • block_backend を、削除する バックストア名 に置き換えます。
    • ACL などの iSCSI ターゲットの一部を削除するには、次のコマンドを実行します。

      /> /iscsi/iqn-name/tpg/acls/ delete iqn.2006-04.com.example:444
  3. 変更を表示します。

    /> iscsi/ ls

関連情報

  • man ページの targetcli

6.4. DM Multipath がデバイスタイムアウトの上書き

recovery_tmo sysfs オプションは、特定の iSCSI デバイスのタイムアウトを制御します。次のオプションは、システム全体の recovery_tmo 値を上書きします。

  • replacement_timeout 設定オプションは、システム全体で全 iSCSI デバイスの recovery_tmo 値を上書きします。
  • DM Multipath が管理するすべての iSCSI デバイスで、DM Multipath の fast_io_fail_tmo オプションは、システム全体の recovery_tmo 値を上書きします。

    DM Multipath の fast_io_fail_tmo オプションは、ファイバーチャネルデバイスの fast_io_fail_tmo オプションを上書きします。

DM Multipath の fast_io_fail_tmo オプションは replacement_timeout よりも優先します。Red Hatでは、replacement_timeout を使用して、DM Multipathが管理するデバイスの recovery_tmo を上書きすることは推奨しません。これは、multipathd サービスが再読み込みを行うと、DM Multipathが常に recovery_tmo をリセットするためです。

第7章 ファイバーチャネルデバイスの使用

RHEL 8 は、以下のネイティブファイバーチャネルドライバーを提供します。

  • lpfc
  • qla2xxx
  • zfcp

7.1. ファイバーチャネル論理ユニットのサイズ変更

システム管理者は、ファイバーチャネルの論理ユニットのサイズを変更できます。

手順

  1. multipath 論理ユニットのパスのデバイスを確認するには、次のコマンドを実行します。

    multipath -ll
  2. マルチパス機能を使用するシステムでファイバーチャネル論理ユニットを再スキャンするには、次のコマンドを実行します。

    $ echo 1 > /sys/block/sdX/device/rescan

関連情報

  • man ページの multipath

7.3. ファイバーチャンネル設定ファイル

以下は、ユーザー空間 API をファイバーチャネルに提供する /sys/class/ ディレクトリーの設定ファイルの一覧です。

項目は以下の変数を使用します。

H
ホスト番号
B
バス番号
T
ターゲット
L
論理ユニット (LUN)
-R
リモートポート番号
重要

マルチパスソフトウェアを使用している場合は、このセクションに記載される値のいずれかを変更する前に、ハードウェアベンダーにお問い合わせになることが推奨されます。

/sys/class/fc_transport/targetH:B:T/ のトランスポート設定

port_id
24 ビットのポート ID/アドレス
node_name
64 ビットのノード名
port_name
64 ビットのポート名

/sys/class/fc_remote_ports/rport-H:B-R/ のリモートポート設定

  • port_id
  • node_name
  • port_name
  • dev_loss_tmo

    scsi デバイスがシステムから削除されるタイミングを制御します。dev_loss_tmo がトリガーされると、scsi デバイスが削除されます。multipath.conf ファイルでは、dev_loss_tmoinfinity に設定できます。

    Red Hat Enterprise Linux 8 では、fast_io_fail_tmo オプションを設定しないと、dev_loss_tmo600 秒に制限されます。デフォルトでは、multipathd サービスが実行している場合は、Red Hat Enterprise Linux 8 で fast_io_fail_tmo5 秒に設定されています。それ以外の場合は off に設定されます。

  • fast_io_fail_tmo

    リンクに「bad」のマークが付くまでの待機秒数を指定します。リンクに「bad」のマークが付けられると、対応するパス上の既存の実行中の I/O または新しい I/O が失敗します。

    I/O がブロックされたキューに存在する場合は、dev_loss_tmo の期限が切れ、キューのブロックが解除されるまでエラーを起こしません。

    fast_io_fail_tmo を off 以外の値に設定すると、dev_loss_tmo は取得されません。fast_io_fail_tmo を off に設定すると、システムからデバイスが削除されるまで I/O は失敗します。fast_io_fail_tmo に数値を設定すると、fast_io_fail_tmo タイムアウトが発生するとすぐに I/O が失敗します。

/sys/class/fc_host/hostH/ のホスト設定

  • port_id
  • node_name
  • port_name
  • issue_lip

    リモートポートを再検出するようにドライバーに指示します。

7.4. DM Multipath がデバイスタイムアウトの上書き

recovery_tmo sysfs オプションは、特定の iSCSI デバイスのタイムアウトを制御します。次のオプションは、システム全体の recovery_tmo 値を上書きします。

  • replacement_timeout 設定オプションは、システム全体で全 iSCSI デバイスの recovery_tmo 値を上書きします。
  • DM Multipath が管理するすべての iSCSI デバイスで、DM Multipath の fast_io_fail_tmo オプションは、システム全体の recovery_tmo 値を上書きします。

    DM Multipath の fast_io_fail_tmo オプションは、ファイバーチャネルデバイスの fast_io_fail_tmo オプションを上書きします。

DM Multipath の fast_io_fail_tmo オプションは replacement_timeout よりも優先します。Red Hatでは、replacement_timeout を使用して、DM Multipathが管理するデバイスの recovery_tmo を上書きすることは推奨しません。これは、multipathd サービスが再読み込みを行うと、DM Multipathが常に recovery_tmo をリセットするためです。

第8章 イーサネットインターフェースを介したファイバチャネルの設定

Red Hat Enterprise Linux 8 には、以下のネイティブ FCoE ドライバーが同梱されます。

  • bnx2fc
  • fnic
  • qedf
  • lpfc

8.1. FCoE を使用するためにイーサネットインターフェースの設定

システム管理者は、bnx2fc ドライバーの FCoE を設定できます。

前提条件

  • FCoE インターフェースのセットアップとデプロイメントには、fcoe-utils パッケージが必要です。

    # yum install fcoe-utils

手順

  1. 新規の仮想 LAN (VLAN) を設定するために、既存のネットワークスクリプトのコピーを作成します。

    # cp /etc/fcoe/cfg-ethx /etc/fcoe/cfg-ethX

    /etc/fcoe/cfg-ethx を、ネットワークスクリプトに置き換え、/etc/fcoe/cfg-ethX を、FCoE 対応のイーサネットデバイスに置き換えます。

    必要に応じて cfg-ethX ファイルの内容を変更します。

  2. システムの起動時にデバイスが自動的に読み込むように設定するには、ifcfg-ethX ファイルに次のパラメーターを設定します。

    # vi /etc/sysconfig/network-scripts/ifcfg-ethX
    
    ONBOOT=yes

    たとえば、FCoE デバイスが eth2 の場合は、それに応じて /etc/sysconfig/network-scripts/ifcfg-eth2 ファイルを編集します。

  3. FCoE デバイスを読み込むには、次のコマンドを実行します。

    # ip link set dev ethX up
  4. FCoE を開始するには、次のコマンドを実行します。

    # systemctl start fcoe

    ファブリック上のその他の設定がすべて正しければ、FCoE デバイスが表示されます。

  5. 設定した FCoE デバイスを表示するには、次のコマンドを実行します。

    # fcoeadm -i
  6. Red Hat では、FCoE を使用するためにイーサネットインターフェースを正しく設定した場合に、FCoE サービスをシステムの起動時に実行するように設定することを推奨しています。

    # systemctl enable fcoe
注記

デーモンを停止するには、次のコマンドを実行します。

# systemctl stop fcoe

このデーモンを停止しても、FCoE インターフェースの設定はリセットされません。設定をリセットするには、次のコマンドを実行します。

# systemctl -s SIGHUP kill fcoe

関連情報

8.2. システムの起動時に FCoE インターフェースを自動マウントする設定

新しく検出されたディスクは、udev ルール、autofs、およびその他の同様の方法でマウントできます。サービスが、システムの起動時に FCoE ディスクのマウントを必要とする場合は、fcoe サービスが実行してすぐ、そして FCoE ディスクが必要になるサービスが開始する前に、FCoE ディスクをマウントする必要があります。FCoE マウントコードは、シンプルなフォーマットの FCoE ディスク、LVM、マルチパスデバイスノードなどのシステム設定によって異なる場合があります。

手順

  1. FCoE ディスクをシステムの起動時に自動マウントするように設定するには、fcoe サービスの起動スクリプトに適切な FCoE マウントコードを追加します。fcoe 起動スクリプトは、/lib/systemd/system/fcoe.service ファイル内にあります。

    例: FCoE マウントコード

    以下は、/etc/fstab ファイル内のワイルドカードで指定したファイルシステムをマウントする FCoE マウントコードのサンプルです。

    mount_fcoe_disks_from_fstab()
    {
      local timeout=20
    	local done=1
    	local fcoe_disks=($(egrep 'by-path\/fc-.*_netdev' /etc/fstab | cut -d ' ' -f1))
    
    	test -z $fcoe_disks && return 0
    
    	echo -n "Waiting for fcoe disks . "
      while [ $timeout -gt 0 ]; do
    	 for disk in ${fcoe_disks[*]}; do
        if ! test -b $disk; then
    		  done=0
    			break
        fi
    	done
    
    	test $done -eq 1 && break;
    	sleep 1
    	echo -n ". "
    	done=1
    	let timeout--
    	done
    
    	if test $timeout -eq 0; then
    	 echo "timeout!"
    	else
    	 echo "done!"
    	fi
    
    	# mount any newly discovered disk
    	mount -a 2>/dev/null
    	}
  2. FCoE を開始するには、次のコマンドを実行します。

    # systemctl start fcoe

    mount_fcoe_disks_from_fstab 関数は、fcoe サービススクリプトが fcoemond デーモンを起動した後に呼び出す必要があります。これにより、以下のようにパスが /etc/fstab ファイルに指定されている FCoE ディスクがマウントされます。

    /dev/disk/by-path/fc-0xXX:0xXX /mnt/fcoe-disk1 ext4  defaults,_netdev    0 0
    /dev/disk/by-path/fc-0xYY:0xYY /mnt/fcoe-disk2 ext3  defaults,_netdev    0 0

    部分文字列の fc- および _netdev が含まれるエントリーは、mount_fcoe_disks_from_fstab 関数が FCoE ディスクマウントエントリーを識別できるようにします。

注記

fcoe サービスは、FCoE ディスク検出のタイムアウトを実装しません。FCoE マウントコードは、独自のタイムアウト期間を実装する必要があります。

関連情報

  • man ページの fcoe
  • man ページの fstab
  • /usr/share/doc/fcoe-utils-version/README ファイル

第9章 eh_deadline を使用したストレージエラーからの回復における最大時間の設定

障害が発生した SCSI デバイスを復旧するのに許容できる最大時間を設定できます。この設定は、ストレージハードウェアが不具合により応答しなくなっても、I/O 応答時間を保証します。

9.1. eh_deadline パラメーター

SCSI エラー処理 (EH) メカニズムは、障害が発生した SCSI デバイスでエラーからの復旧の実行を試行します。SCSI ホストオブジェクト eh_deadline パラメーターでは、復旧時間の最大量を設定できます。設定した時間が過ぎると、SCSI EH は、ホストバスアダプター (HBA) 全体を停止してリセットします。

eh_deadline を使用すると、以下のいずれかの時間を短縮できます。

  • エラーのあるパスのシャットオフ
  • パスの切り替え
  • RAID スライスの無効化
警告

eh_deadline が過ぎると、SCSI EH は HBA をリセットします。これは、エラーが発生しているものだけでなく、HBA 上のすべてのターゲットパスに影響します。一部の冗長パスがその他の理由により利用できない場合は、I/O エラーが発生する可能性があります。eh_deadline は、すべてのターゲットに完全な冗長マルチパス設定がある場合にのみ有効にします。

eh_deadline が便利なシナリオ

多くの場合、eh_deadline を有効にする必要はありません。eh_dealine は、ファイバーチャンネル (FC) スイッチやターゲットポートでリンクの損失が発生した場合や、HBA が Registered State Change Notification (RSCN) を受信しない場合など、特定のシナリオで便利です。このような場合、I/O 要求やエラーからの復旧コマンドは、エラーに遭遇することなく、すべてタイムアウトになります。この環境で eh_deadline を設定すると、リカバリー時間に上限が課せられます。これにより、DM Multipath により、利用できる別のパスで不具合の発生した I/O の再試行が可能になります。

以下の条件では、eh_deadline 機能はこれ以上のメリットをもたらしません。その理由は、DM Multipath の再試行を可能にする I/O とエラー復旧コマンドがすぐに失敗するためです。

  • RSCN が有効になっている場合
  • HBA が利用できなくなっているリンクを登録しない場合

可能な値

eh_deadline の値は秒単位で指定されます。

デフォルト設定は off で、時間制限が無効になり、すべてのエラー復旧が行われるようになります。

9.2. eh_deadline パラメーターの設定

この手順では、SCSI を復旧する最大時間を制限する eh-daedline パラメーターの値を設定します。

手順

  • eh_deadline は、以下のいずれかの方法で設定できます。

    sysfs
    /sys/class/scsi_host/host*/eh_deadline ファイルに秒数を書き込みます。
    カーネルパラメーター
    すべての SCSI HBA のデフォルト値は scsi_mod.eh_deadline カーネルパラメーターを使用して設定します。

第10章 スワップの使用

このセクションでは、スワップ領域とその使用方法を説明します。

10.1. スワップ領域

Linux の スワップ領域 は、物理メモリー (RAM) が不足すると使用されます。システムに多くのメモリーリソースが必要で、RAM が不足すると、メモリーの非アクティブなページがスワップ領域に移動します。スワップ領域は、RAM が少ないマシンで役に立ちますが、RAM の代わりに使用しないようにしてください。スワップ領域はハードドライブにあり、そのアクセス速度は物理メモリーに比べると遅くなります。スワップ領域の構成は、専用のスワップパーティション (推奨)、スワップファイル、またはスワップパーティションとスワップファイルの組み合せが考えられます。

過去数年、推奨されるスワップ領域のサイズは、システムの RAM サイズに比例して増加していました。しかし、最近のシステムには通常、数百ギガバイトの RAM が含まれます。結果として、推奨されるスワップ領域は、システムのメモリーではなく、システムメモリーのワークロードの機能とみなされます。

「システムの推奨スワップ領域」では、システムの RAM の容量別に推奨されるスワップパーティションのサイズと、システムをハイバネートするのに十分なメモリーが必要かどうかを示しています。推奨されるスワップパーティションのサイズは、インストール時に自動的に確定されます。ハイバネートを可能にするには、カスタムのパーティション分割段階でスワップ領域を編集する必要があります。

「システムの推奨スワップ領域」の推奨では、メモリーが少ないシステム (1 GB 以下) で特に重要になります。このようなシステムで十分なスワップ領域を割り当てられないと、不安定になる問題が生じたり、インストールしたシステムが起動できなくなる可能性があります。

10.3. スワップ領域の追加

本セクションでは、インストール後にさらにスワップ領域を追加する方法を説明します。たとえば、システムの RAM 容量を 1 GB から 2 GB にアップグレードするときに、スワップ容量が 2 GB しかないとします。メモリーを大幅に消費する操作を実行している場合や、大量のメモリーを必要とするアプリケーションを実行する場合は、スワップ領域を 4 GB に増やすことが有益となる可能性があります。

この場合は、スワップパーティションを新規作成する、スワップファイル新規作成する、または既存の LVM2 論理ボリュームでスワップを拡張をする 3 つの方法が選択肢として考えられます。この中では、既存論理ボリュームを拡張することが推奨されます。

10.3.1. LVM2 論理ボリュームでのスワップ領域の拡張

この手順では、既存の LVM2 論理ボリュームでスワップ領域を拡張する方法を説明します。ここでは、/dev/VolGroup00/LogVol01 のボリュームを 2 GB 増やします。

前提条件

  • 十分なディスク領域

手順

  1. 関連付けられている論理ボリュームのスワップ機能を無効にします。

    # swapoff -v /dev/VolGroup00/LogVol01
  2. LVM2 論理ボリュームのサイズを 2 GB 増やします。

    # lvresize /dev/VolGroup00/LogVol01 -L +2G
  3. 新しいスワップ領域をフォーマットします。

    # mkswap /dev/VolGroup00/LogVol01
  4. 拡張論理ボリュームを有効にします。

    # swapon -v /dev/VolGroup00/LogVol01
  5. スワップの論理ボリュームの拡張に成功したかどうかをテストするには、アクティブなスワップ容量を調べます。

    $ cat /proc/swaps
    $ free -h

10.3.2. スワップの LVM2 論理ボリュームの作成

この手順では、スワップ用に LVM2 論理ボリュームを作成する方法を説明します。ここでは、スワップボリューム /dev/VolGroup00/LogVol02 を追加します。

前提条件

  • 十分なディスク領域

手順

  1. サイズが 2 GB の LVM2 論理ボリュームを作成します。

    # lvcreate VolGroup00 -n LogVol02 -L 2G
  2. 新しいスワップ領域をフォーマットします。

    # mkswap /dev/VolGroup00/LogVol02
  3. 次のエントリーを /etc/fstab ファイルに追加します。

    /dev/VolGroup00/LogVol02 swap swap defaults 0 0
  4. システムが新しい設定を登録するように、マウントユニットを再生成します。

    # systemctl daemon-reload
  5. 論理ボリュームでスワップをアクティブにします。

    # swapon -v /dev/VolGroup00/LogVol02
  6. スワップ論理ボリュームの作成に成功したかどうかをテストするには、アクティブなスワップ容量を調べます。

    $ cat /proc/swaps
    $ free -h

10.3.3. スワップファイルの作成

この手順では、スワップファイルの作成方法を説明します。

前提条件

  • 十分なディスク領域

手順

  1. 新しいスワップファイルのサイズをメガバイト単位で指定してから、そのサイズに 1024 をかけてブロック数を指定します。たとえばスワップファイルのサイズが 64 MB の場合は、ブロック数が 65536 になります。
  2. 空のファイルの作成:

    # dd if=/dev/zero of=/swapfile bs=1024 count=65536

    希望のブロックサイズと同等の値に count を置き換えます。

  3. 次のコマンドでスワップファイルをセットアップします。

    # mkswap /swapfile
  4. スワップファイルのセキュリティーを変更して、全ユーザーで読み込みができないようにします。

    # chmod 0600 /swapfile
  5. システムの起動時にスワップファイルを有効にするには、root で /etc/fstab に、次のエントリーを追加します。

    /swapfile swap swap defaults 0 0

    次にシステムが起動すると新しいスワップファイルが有効になります。

  6. システムが新しい /etc/fstab 設定を登録するように、マウントユニットを再生成します。

    # systemctl daemon-reload
  7. スワップファイルをすぐに有効にするには、次のコマンドを実行します。

    # swapon /swapfile
  8. 新しいスワップファイルを作成して有効にできたことをテストするには、アクティブなスワップ容量を調べます。

    $ cat /proc/swaps
    $ free -h

10.4. スワップ領域の削除

本セクションでは、インストール後にさらにスワップ領域を減らす方法を説明します。たとえば、システムの RAM 容量を 1 GB から 512 MB にダウングレードするとします。しかし、依然として 2 GB のスワップ容量が割り当てられています。ディスク領域が大きくなる (2 GB など) と無駄になる可能性があるため、スワップ領域を 1 GB に減らすことでメリットを得られることがあります。

必要に応じて、既存の LVM2 論理ボリューム上のスワップ領域を減らす、スワップに使用している LVM2 論理ボリュームを削除する、またはスワップファイルを削除する選択肢の中から 1 つ選択します。

10.4.1. LVM2 論理ボリュームでのスワップ領域の縮小

この手順では、LVM2 論理ボリュームでスワップを減らす方法を説明します。ここでは、縮小を行うボリュームを /dev/VolGroup00/LogVol01 とします。

手順

  1. 関連付けられている論理ボリュームのスワップ機能を無効にします。

    # swapoff -v /dev/VolGroup00/LogVol01
  2. LVM2 論理ボリュームのサイズを変更して 512 MB 削減します。

    # lvreduce /dev/VolGroup00/LogVol01 -L -512M
  3. 新しいスワップ領域をフォーマットします。

    # mkswap /dev/VolGroup00/LogVol01
  4. 論理ボリュームでスワップをアクティブにします。

    # swapon -v /dev/VolGroup00/LogVol01
  5. スワップ論理ボリュームの縮小に成功したかどうかをテストするには、アクティブなスワップ容量を調べます。

    $ cat /proc/swaps
    $ free -h

10.4.2. スワップの LVM2 論理ボリュームの削除

この手順では、スワップ用に LVM2 論理ボリュームを削除する方法を説明します。削除するスワップボリュームを /dev/VolGroup00/LogVol02 とします。

手順

  1. 関連付けられている論理ボリュームのスワップ機能を無効にします。

    # swapoff -v /dev/VolGroup00/LogVol02
  2. LVM2 論理ボリュームを削除します。

    # lvremove /dev/VolGroup00/LogVol02
  3. 次の関連エントリーを /etc/fstab ファイルから削除します。

    /dev/VolGroup00/LogVol02 swap swap defaults 0 0
  4. システムが新しい設定を登録するように、マウントユニットを再生成します。

    # systemctl daemon-reload
  5. 論理ボリュームの削除に成功したかどうかをテストするには、アクティブなスワップ容量を調べます。

    $ cat /proc/swaps
    $ free -h

10.4.3. スワップファイルの削除

この手順では、スワップファイルを削除する方法を説明します。

手順

  1. シェルプロンプトで次のコマンドを実行してスワップファイルを無効にします (スワップファイルの場所が /swapfile であるとします)。

    # swapoff -v /swapfile
  2. /etc/fstab ファイルからエントリーを削除します。
  3. システムが新しい設定を登録するように、マウントユニットを再生成します。

    # systemctl daemon-reload
  4. 実際のファイルを削除します。

    # rm /swapfile

第11章 スナップショットとしてのシステムアップグレードの管理

システム管理者は、Boom を使用してシステム状態の代替コピー用に起動エントリーを作成します。Boom は、システム更新の管理を簡素化します。

警告

本章で説明している手順は、システムツリー内の複数のファイルシステムには使えません。

11.1. Boom プロセスの概要

Boom により、GRUB 2 ブートローダーメニューからのアクセスおよび選択が可能な起動エントリーを作成できます。起動エントリーを作成すると、ロールバック可能なアップグレードの準備プロセスが簡素化されます。

ロールバック可能なアップグレードは、設定ファイルを編集せずに、以下のプロセスで実行します。

  1. root ファイルシステムのスナップショットまたはコピーを作成します。
  2. Boom を使用して、現在の (以前の) 環境用のブートエントリーを作成します。
  3. Red Hat Enterprise Linux システムをアップグレードします。
  4. システムを再起動し、使用するバージョンを選択します。

Boom を使用すると、システムのアップグレードに関連するリスクが減少し、またハードウェアのダウンタイムを短縮するのに役立ちます。

たとえば、元の Red Hat Enterprise Linux 7 環境を保持しつつ、Red Hat Enterprise Linux 7 システムを Red Hat Enterprise Linux 8 にアップグレードできます。アップグレードが完了したら、必要に応じて、古い Red Hat Enterprise Linux 7 環境と、新しい Red Hat Enterprise Linux 8 環境を切り換えることができます。

これは、環境間の切り替え機能により、以下が可能になります。

  • サイドバイサイド方式で両環境をすばやく比較し、最小オーバーヘッドで環境を切り替えます。
  • 古いファイルシステムのコンテンツを復元します。
  • アップグレードしたホストの実行中も古いシステムへのアクセスを継続します。
  • 更新自体が実行中でも、更新プロセスをいつでも中止して、元に戻します。

関連情報

  • man ページの boom

11.2. Boom で別のバージョンへのアップグレード

Boom に加え、以下の Red Hat Enterprise Linux コンポーネントが、このアップグレードプロセスで使用されます。

  • LVM
  • GRUB 2 ブートローダー
  • Leapp アップグレードツール

この手順では、boom パッケージを使用して、Red Hat Enterprise Linux 7 から Red Hat Enterprise Linux 8 にアップグレードする方法を説明します。

前提条件

  • boom パッケージをインストールします。

    # yum install lvm2-python-boom
  • スナップショットに十分な容量が割り当てられています。次のコマンドを使用して、ボリュームグループおよび論理ボリューム上の空き領域を検索します。

    # vgs
    VG  #PV  #LV  #SN  Attr  VSize    VFree
    rhel 4 2 0 wz--n- 103.89g 29.99g
    
    # lvs
    LV     VG    Attr     LSize  Pool Origin Data% Meta% Move Log Cpy%Sync Convert
    root rhel -wi-ao--- 68.88g
    swap rhel -wi-ao--- 5.98g

手順

  1. root 論理ボリュームのスナップショットを作成します。

    • root ファイルシステムがシンプロビジョニングを使用する場合は、シンスナップショットを作成します。

      シンスナップショットを作成している間は、スナップショットのサイズを定義することができません。スナップショットは、シンプールからも割り当てられます。

      # lvcreate -s -k n rhel/root -n root_snapshot_before_changes

      ここでは、以下のようになります。

      • -s は、スナップショットの作成に使用します。
      • RHEL/root は、論理ボリュームにコピーされるファイルシステムです。
      • -n root_snapshot_before_changes は、スナップショットの名前になります。
      • -k n は、シンスナップショットはデフォルトではアクティブにならないため、アクティブ化はスキップされません。
    • root ファイルシステムがシックプロビジョニングを使用する場合は、シックスナップショットを作成します。

      シックスナップショットを作成する際は、アップグレード中にすべての変更を保持できるスナップショットサイズを定義します。

      # lvcreate -s  rhel/root -n root_snapshot_before_changes -L 25g

      ここでは、以下のようになります。

      • -s は、スナップショットの作成に使用します。
      • RHEL/root は、コピーされるファイルシステムです。
      • -n root_snapshot_before_changes は、スナップショットの名前になります。
      • -L 25g は、アップグレード中にすべての変更を保持できるスナップショットサイズです。

        重要

        スナップショットを作成した後には、追加のシステム変更は含まれていません。

  2. プロファイルを作成します。

    # boom profile create --from-host --uname-pattern el8
  3. 新たなブートエントリーを作成します。

    # boom create --title "Root LV snapshot before changes" --rootlv rhel/root_snapshot_before_changes

    ここでは、以下のようになります。

    • --title Root LV snapshot before changes は、ブートエントリーの名前で、システムの起動時に一覧に表示されます。
    • --rootlv は、新しいブートエントリーに対応する root 論理ボリュームです。

      初めて boom create コマンドを実行すると、次のメッセージが表示されます。

      WARNING - Boom configuration not found in grub.cfg
      
      WARNING - Run 'grub2-mkconfig > /boot/grub2/grub.cfg' to enable

      GRUB 2 で Boom を有効にするには、次のコマンドを実行します。

      # grub2-mkconfig > /boot/grub2/grub.cfg
  4. Leapp を使用してアップグレードします。

    # leapp upgrade --reboot
    注記

    この reboot 引数は、アップグレードプロセス後に自動システムの再起動を開始します。

    再起動時に GRUB 2 画面が表示されます。

    GRUB2 display
  5. RHEL Upgrade initramfs エントリーを選択して、ENTER を押します。アップグレードが続行し、新しい Red Hat Enterprise Linux 8 RPM パッケージがインストールされます。アップグレードが完了すると、システムが自動的に再起動し、アップグレードして利用可能なシステムと古いバージョンで利用可能なシステムが GRUB 2 画面に表示されます。アップグレードされたシステムバージョンがデフォルトの選択です。

    新しいバージョンと古いバージョン間の切り替え

関連情報

11.3. Red Hat Enterprise Linux のバージョン間切り替え

この手順では、アップグレードの完了後に新しいバージョンと古いバージョンの Red Hat Enterprise Linux を切り替える手順を説明します。

前提条件

手順

  1. システムを再起動します。

    # reboot
  2. GRUB 2 ブートローダー画面で、該当する起動エントリーを選択します。

    新しいバージョンと古いバージョン間の切り替え
  3. 選択したブートボリュームが表示されていることを確認します。

    # boom list

関連情報

  • man ページの boom

11.4. スナップショットの削除

この手順では、スナップショットを削除する手順を説明します。

前提条件

手順

  1. GRUB 2 エントリーから Red Hat Enterprise Linux 8 を起動します。以下の出力で、新規スナップショットが選択されていることを確認します。

    # boom list
    BootID  Version                    Name                            RootDevice
    6d2ec72 3.10.0-957.21.3.el7.x86_64 Red Hat Enterprise Linux Server /dev/rhel/root_snapshot_before_changes
  2. BootID を使用して、Boom スナップショットエントリーを削除します。

    # boom delete --boot-id 6d2ec72

    これにより、GRUB 2 メニューからエントリーが削除されます。

  3. 論理ボリューム (LV) のスナップショットを削除します。

    # lvremove rhel/root_snapshot_before_changes
    Do you really want to remove active logical volume rhel/root_snapshot_before_changes? [y/n]: y
          Logical volume "root_snapshot_before_changes" successfully removed

    関連情報

    • man ページの boom

第12章 NVMe over fabric デバイスの概要

Non-volatile Memory Express (NVMe) は、ホストソフトウェアユーティリティーがソリッドステートドライブと通信できるようにするインターフェースです。

次の種類のファブリックトランスポートを使用して、NVMe over fabric デバイスを設定します。

FC および RDMA を使用する場合は、ソリッドステートドライブをシステムにローカルにする必要はありません。また、FC または RDMA コントローラーを介してリモートで設定できます。

12.1. RDMA を使用した NVMe over fabrics

NVMe/RDMA 設定では、NVMe ターゲットおよび NVMe イニシエーターが設定されます。

システム管理者は、次のセクションのタスクを、RDMA (NVMe/RDMA) を使用して NVMe over fabrics をデプロイします。

12.1.1. configfs で NVMe/RDMA ターゲットの設定

この手順に従って、configfs を使用して NVMe/RDMA ターゲットを設定します。

前提条件

  • nvmet サブシステムに割り当てるブロックデバイスがあることを確認します。

手順

  1. nvmet-rdma サブシステムを作成します。

    # modprobe nvmet-rdma
    
    # mkdir /sys/kernel/config/nvmet/subsystems/testnqn
    
    # cd /sys/kernel/config/nvmet/subsystems/testnqn

    testnqn を、サブシステム名に置き換えます。

  2. ホストがこのターゲットに接続することを許可します。

    # echo 1 > attr_allow_any_host
  3. namespace を設定します。

    # mkdir namespaces/10
    
    # cd namespaces/10

    10 を、namespace の数値に置き換えます。

  4. NVMe デバイスへのパスを設定します。

    #echo -n /dev/nvme0n1 > device_path
  5. namespace を有効にします。

    # echo 1 > enable
  6. NVMe ポートでディレクトリーを作成します。

    # mkdir /sys/kernel/config/nvmet/ports/1
    
    # cd /sys/kernel/config/nvmet/ports/1
  7. mlx5_ib0 の IP アドレスを表示します。

    # ip addr show mlx5_ib0
    
    8: mlx5_ib0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 4092 qdisc mq state UP group default qlen 256
        link/infiniband 00:00:06:2f:fe:80:00:00:00:00:00:00:e4:1d:2d:03:00:e7:0f:f6 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
        inet 172.31.0.202/24 brd 172.31.0.255 scope global noprefixroute mlx5_ib0
           valid_lft forever preferred_lft forever
        inet6 fe80::e61d:2d03:e7:ff6/64 scope link noprefixroute
           valid_lft forever preferred_lft forever
  8. ターゲットのトランスポートアドレスを設定します。

    # echo -n 172.31.0.202 > addr_traddr
  9. RDMA をトランスポートタイプとして設定します。

    # echo rdma > addr_trtype
    
    # echo 4420 > addr_trsvcid
  10. ポートのアドレスファミリーを設定します。

    # echo ipv4 > addr_adrfam
  11. ソフトリンクを作成します。

    # ln -s /sys/kernel/config/nvmet/subsystems/testnqn   /sys/kernel/config/nvmet/ports/1/subsystems/testnqn

検証手順

  • NVMe ターゲットが指定のポートでリッスンし、接続リクエストの準備ができていることを確認します。

    # dmesg | grep "enabling port"
    [ 1091.413648] nvmet_rdma: enabling port 1 (172.31.0.202:4420)

関連情報

  • man ページの nvme

12.1.2. nvmetcli を使用した NVMe/RDMA ターゲットの設定

nvmetcli を使用して、NVMe ターゲットの編集、表示、および起動を行います。nvmetcli は、コマンドラインとインタラクティブなシェルオプションを提供します。この手順を使用して、nvmetcli により NVMe/RDMA ターゲットを設定します。

前提条件

  • nvmet サブシステムに割り当てるブロックデバイスがあることを確認します。
  • nvmetcli 操作を root ユーザーとして実行します。

手順

  1. nvmetcli パッケージをインストールします。

    # yum install nvmetcli
  2. rdma.json ファイルをダウンロードします。

    # wget http://git.infradead.org/users/hch/nvmetcli.git/blob_plain/0a6b088db2dc2e5de11e6f23f1e890e4b54fee64:/rdma.json
  3. rdma.json ファイルを編集して、traddr の値を 172.31.0.202 に変更します。
  4. NVMe ターゲット設定ファイルを読み込んでターゲットを設定します。

    # nvmetcli restore rdma.json
注記

NVMe ターゲット設定ファイル名を指定しない場合は、nvmetcli/etc/nvmet/config.json ファイルを使用します。

検証手順

  • NVMe ターゲットが指定のポートでリッスンし、接続リクエストの準備ができていることを確認します。

    #dmesg | tail -1
    [ 4797.132647] nvmet_rdma: enabling port 2 (172.31.0.202:4420)
  • (必要に応じて) 現在の NVMe ターゲットを削除します。

    # nvmetcli clear

関連情報

  • man ページの nvmetcli
  • man ページの nvme

12.1.3. NVMe/RDMA クライアントの設定

この手順を使用して、NVMe 管理コマンドラインインターフェース (nvme-cli) ツールを使用して NVMe/RDMA クライアントを設定します。

手順

  1. nvme-cli ツールをインストールします。

    # yum install nvme-cli
  2. nvme-rdma モジュールが読み込まれていない場合は読み込みます。

    # modprobe nvme-rdma
  3. NVMe ターゲットで利用可能なサブシステムを検出します。

    # nvme discover -t rdma -a 172.31.0.202 -s 4420
    
    Discovery Log Number of Records 1, Generation counter 2
    =====Discovery Log Entry 0======
    trtype:  rdma
    adrfam:  ipv4
    subtype: nvme subsystem
    treq:    not specified, sq flow control disable supported
    portid:  1
    trsvcid: 4420
    subnqn:  testnqn
    traddr:  172.31.0.202
    rdma_prtype: not specified
    rdma_qptype: connected
    rdma_cms:    rdma-cm
    rdma_pkey: 0x0000
  4. 検出されたサブシステムに接続します。

    # nvme connect -t rdma -n testnqn -a 172.31.0.202 -s 4420
    
    # lsblk
    NAME                         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
    sda                            8:0    0 465.8G  0 disk
    ├─sda1                         8:1    0     1G  0 part /boot
    └─sda2                         8:2    0 464.8G  0 part
      ├─rhel_rdma--virt--03-root 253:0    0    50G  0 lvm  /
      ├─rhel_rdma--virt--03-swap 253:1    0     4G  0 lvm  [SWAP]
      └─rhel_rdma--virt--03-home 253:2    0 410.8G  0 lvm  /home
    nvme0n1
    
    #cat /sys/class/nvme/nvme0/transport
    rdma

    testnqn を、NVMe サブシステム名に置き換えます。

    172.31.0.202 を、ターゲットの IP アドレスに置き換えます。

    4420 を、ポート番号に置き換えます。

検証手順

  • 現在接続されている NVMe デバイスの一覧を表示します。

    # nvme list
  • (必要に応じて) ターゲットから切断します。

    # nvme disconnect -n testnqn
    NQN:testnqn disconnected 1 controller(s)
    
    # lsblk
    NAME                         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
    sda                            8:0    0 465.8G  0 disk
    ├─sda1                         8:1    0     1G  0 part /boot
    └─sda2                         8:2    0 464.8G  0 part
      ├─rhel_rdma--virt--03-root 253:0    0    50G  0 lvm  /
      ├─rhel_rdma--virt--03-swap 253:1    0     4G  0 lvm  [SWAP]
      └─rhel_rdma--virt--03-home 253:2    0 410.8G  0 lvm  /home

関連情報

12.2. FC を使用した NVMe over fabrics

NVMe over Fibre Channel (FC-NVMe) は、特定の Broadcom Emulex アダプターおよび Marvell Qlogic Fibre Channel アダプターとともに使用すると、イニシエーターモードで完全にサポートされてるようになります。システム管理者は、FC-NVMe をデプロイするために、以下のセクションのタスクを完了します。

12.2.1. Broadcom アダプターの NVMe イニシエーターの設定

この手順を使用して、NVMe 管理コマンドラインインターフェース (nvme-cli) ツールを使用して、Broadcom アダプタークライアントに NVMe イニシエーターを設定します。

手順

  1. nvme-cli ツールをインストールします。

    # yum install nvme-cli

    これにより、/etc/nvme/ ディレクトリーに hostnqn ファイルが作成されます。hostnqn ファイルは、NVMe ホストを識別します。

    新しい hostnqn を生成するには、次のコマンドを実行します。

    #nvme gen-hostnqn
  2. ローカルポートおよびリモートポートの WWNN および WWPN を見つけ、出力を使用してサブシステムの NQN を見つけます。

    # cat /sys/class/scsi_host/host*/nvme_info
    
    NVME Initiator Enabled
    XRI Dist lpfc0 Total 6144 IO 5894 ELS 250
    NVME LPORT lpfc0 WWPN x10000090fae0b5f5 WWNN x20000090fae0b5f5 DID x010f00 ONLINE
    NVME RPORT       WWPN x204700a098cbcac6 WWNN x204600a098cbcac6 DID x01050e TARGET DISCSRVC ONLINE
    
    NVME Statistics
    LS: Xmt 000000000e Cmpl 000000000e Abort 00000000
    LS XMIT: Err 00000000  CMPL: xb 00000000 Err 00000000
    Total FCP Cmpl 00000000000008ea Issue 00000000000008ec OutIO 0000000000000002
        abort 00000000 noxri 00000000 nondlp 00000000 qdepth 00000000 wqerr 00000000 err 00000000
    FCP CMPL: xb 00000000 Err 00000000
    # nvme discover --transport fc --traddr nn-0x204600a098cbcac6:pn-0x204700a098cbcac6 --host-traddr nn-0x20000090fae0b5f5:pn-0x10000090fae0b5f5
    
    Discovery Log Number of Records 2, Generation counter 49530
    =====Discovery Log Entry 0======
    trtype:  fc
    adrfam:  fibre-channel
    subtype: nvme subsystem
    treq:    not specified
    portid:  0
    trsvcid: none
    subnqn:  nqn.1992-08.com.netapp:sn.e18bfca87d5e11e98c0800a098cbcac6:subsystem.st14_nvme_ss_1_1
    traddr:  nn-0x204600a098cbcac6:pn-0x204700a098cbcac6

    nn-0x204600a098cbcac6:pn-0x204700a098cbcac6 を、traddr に置き換えます。

    nn-0x20000090fae0b5f5:pn-0x10000090fae0b5f5 を、host_traddr に置き換えます。

  3. nvme-cli を使用して NVMe ターゲットに接続します。

    # nvme connect --transport fc --traddr nn-0x204600a098cbcac6:pn-0x204700a098cbcac6 --host-traddr nn-0x20000090fae0b5f5:pn-0x10000090fae0b5f5 -n nqn.1992-08.com.netapp:sn.e18bfca87d5e11e98c0800a098cbcac6:subsystem.st14_nvme_ss_1_1

    nn-0x204600a098cbcac6:pn-0x204700a098cbcac6 を、traddr に置き換えます。

    nn-0x20000090fae0b5f5:pn-0x10000090fae0b5f5 を、host_traddr に置き換えます。

    nqn.1992-08.com.netapp:sn.e18bfca87d5e11e98c0800a098cbcac6:subsystem.st14_nvme_ss_1_1 を、subnqn に置き換えます。

検証手順

  • 現在接続されている NVMe デバイスの一覧を表示します。

    # nvme list
    Node             SN                   Model                                    Namespace Usage                      Format           FW Rev
    ---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
    /dev/nvme0n1     80BgLFM7xMJbAAAAAAAC NetApp ONTAP Controller                  1         107.37  GB / 107.37  GB      4 KiB +  0 B   FFFFFFFF
    # lsblk |grep nvme
    nvme0n1                     259:0    0   100G  0 disk

関連情報

12.2.2. QLogic アダプターの NVMe イニシエーターの設定

この手順を使用して、NVMe 管理コマンドラインインターフェース (nvme-cli) ツールを使用して、Qlogic アダプタークライアントの NVMe イニシエーターを設定します。

手順

  1. nvme-cli ツールをインストールします。

    # yum install nvme-cli

    これにより、/etc/nvme/ ディレクトリーに hostnqn ファイルが作成されます。hostnqn ファイルは、NVMe ホストを識別します。

    新しい hostnqn を生成するには、次のコマンドを実行します。

    #nvme gen-hostnqn
  2. qla2xxx モジュールを削除して再読み込みします。

    # rmmod qla2xxx
    # modprobe qla2xxx
  3. ローカルポートおよびリモートポートの WWNN および WWPN を検索します。

    # dmesg |grep traddr
    
    [    6.139862] qla2xxx [0000:04:00.0]-ffff:0: register_localport: host-traddr=nn-0x20000024ff19bb62:pn-0x21000024ff19bb62 on portID:10700
    [    6.241762] qla2xxx [0000:04:00.0]-2102:0: qla_nvme_register_remote: traddr=nn-0x203b00a098cbcac6:pn-0x203d00a098cbcac6 PortID:01050d

    この host-traddr および traddr を使用して、サブシステムの NQN を検索します。

    nvme discover --transport fc --traddr nn-0x203b00a098cbcac6:pn-0x203d00a098cbcac6 --host-traddr nn-0x20000024ff19bb62:pn-0x21000024ff19bb62
    
    Discovery Log Number of Records 2, Generation counter 49530
    =====Discovery Log Entry 0======
    trtype:  fc
    adrfam:  fibre-channel
    subtype: nvme subsystem
    treq:    not specified
    portid:  0
    trsvcid: none
    subnqn:  nqn.1992-08.com.netapp:sn.c9ecc9187b1111e98c0800a098cbcac6:subsystem.vs_nvme_multipath_1_subsystem_468
    traddr:  nn-0x203b00a098cbcac6:pn-0x203d00a098cbcac6

    nn-0x203b00a098cbcac6:pn-0x203d00a098cbcac6 を、traddr に置き換えます。

    nn-0x20000024ff19bb62:pn-0x21000024ff19bb62 を、host_traddr に置き換えます。

  4. nvme-cli ツールを使用して NVMe ターゲットに接続します。

    # nvme connect  --transport fc --traddr nn-0x203b00a098cbcac6:pn-0x203d00a098cbcac6 --host_traddr nn-0x20000024ff19bb62:pn-0x21000024ff19bb62 -n nqn.1992-08.com.netapp:sn.c9ecc9187b1111e98c0800a098cbcac6:subsystem.vs_nvme_multipath_1_subsystem_468

    nn-0x203b00a098cbcac6:pn-0x203d00a098cbcac6 を、traddr に置き換えます。

    nn-0x20000024ff19bb62:pn-0x21000024ff19bb62 を、host_traddr に置き換えます。

    nqn.1992-08.com.netapp:sn.c9ecc9187b1111e98c0800a098cbcac6:subsystem.vs_nvme_multipath_1_subsystem_468 を、subnqn に置き換えます。

検証手順

  • 現在接続されている NVMe デバイスの一覧を表示します。

    # nvme list
    Node             SN                   Model                                    Namespace Usage                      Format           FW Rev
    ---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
    /dev/nvme0n1     80BgLFM7xMJbAAAAAAAC NetApp ONTAP Controller                  1         107.37  GB / 107.37  GB      4 KiB +  0 B   FFFFFFFF
    
    # lsblk |grep nvme
    nvme0n1                     259:0    0   100G  0 disk

関連情報

第13章 ディスクスケジューラーの設定

ディスクスケジューラーは、ストレージデバイスに送信された I/O 要求を順序付けます。

スケジューラーは以下の複数の方法で設定できます。

13.1. RHEL 8 におけるディスクスケジューラーの変更

RHEL 8 では、ブロックデバイスはマルチキュースケジューリングのみに対応しています。これにより、高速ソリッドステートドライブ (SSD) およびマルチコアシステムのブロックレイヤーのパフォーマンスが向上します。

RHEL 7 以前のバージョンで利用できた従来のシングルキュースケジューラーが削除されました。

13.2. 利用可能なディスクスケジューラー

RHEL 8 では、以下のマルチキューディスクスケジューラーに対応しています。

ディスクスケジューラー

none
FIFO (First-in First-out) スケジューリングアルゴリズムを実装します。これにより、汎用のブロック層で単純な last-hit キャッシュを介して要求がマージされます。
mq-deadline

これにより、要求がスケジューラーに到達した時点からの要求のレイテンシーが保証されます。

mq-deadline スケジューラーは、キュー待ちの I/O リクエストを読み取りバッチまたは書き込みバッチに分類します。そして、論理ブロックアドレス (LBA) を増大順に実行するためのスケジュール設定を行います。デフォルトでは、アプリケーションは読み取り I/O 操作でブロックする可能性の方が高いため、読み取りバッチの方が書き込みバッチより優先されます。mq-deadline がバッチを処理すると、このプロセスは書き込み動作が待機している長さを確認して、次の読み取りバッチまたは書き込みバッチをスケジュールします。

このスケジューラーはほとんどのユースケースに適していますが、必要に応じて特に書き込み動作より読み取り動作の方が頻繁に起こるユースケースに適しています。

bfq

デスクトップシステムおよび対話式のタスクを対象とします。

bfq スケジューラーは、単一のアプリケーションがすべての帯域幅を使用しないようにします。これにより、ストレージデバイスがアイドル状態であるかのように常に応答できるようになります。大きなファイルをコピーしても、システムが応答しなくなることはありません。デフォルトの設定では、bfq は、最大スループットを実現するのではなく、レイテンシーを最小限に抑えることに焦点を合わせています。

bfqcfq コードに基づいています。固定タイムスライスについて、ディスクは各プロセスに付与されることはありませんが、セクター数を測定する budget をプロセスに割り当てます。

kyber
高速なデバイス用です。このスケジューラーは、レイテンシーゴールを達成するために自身を調整します。読み込み/同期書き込みリクエストにターゲットレイテンシーを設定できます。

13.4. デフォルトのディスクスケジューラー

ブロックデバイスは、別のスケジューラーを指定しない限り、デフォルトのディスクスケジューラーを使用します。

カーネルは、デバイスのタイプに基づいてデフォルトのディスクスケジューラーを選択します。自動的に選択されたスケジューラーは、通常、最適な設定です。別のスケジューラーが必要な場合、Red Hat は、udev ルールまたは Tuned アプリケーションを使用して設定することを推奨されます。選択したデバイスを一致させ、そのデバイスのスケジューラーのみを切り替えます。

13.5. アクティブなディスクスケジューラーの決定

この手順では、特定のブロックデバイスで現在アクティブなディスクスケジューラーを確認します。

手順

  • /sys/block/device/queue/scheduler ファイルの内容を読み取ります。

    # cat /sys/block/device/queue/scheduler
    
    [mq-deadline] kyber bfq none

    ファイル名の device を、sdc などのブロックデバイス名に置き換えます。

    アクティブなスケジューラーは、角括弧 ([ ]) に一覧表示されます。

13.6. Tuned でディスクスケジューラーの設定

この手順では、選択したブロックデバイスに対して特定のディスクスケジューラーを設定する Tuned プロファイルを作成し、有効にします。この設定は、システムを再起動しても持続します。

以下のコマンドと設定で、次の内容を置き換えます。

  • device を、ブロックデバイスの名前 (例: sdf) に置き換えます。
  • selected-scheduler を、デバイスに設定するディスクスケジューラー (例: bfq) に置き換えます。

前提条件

  • tuned サービスがインストールされており、有効になっている。

    詳細は「Tuned の使用」を参照してください。

手順

  1. 必要に応じて、プロファイルのベースとなる既存の Tuned プロファイルを選択します。利用可能なプロファイルの一覧は、「Tuned の使用」を参照してください。

    現在アクティブなプロファイルを確認するには、次のコマンドを実行します。

    $ tuned-adm active
  2. Tuned プロファイルを保存するディレクトリーを新たに作成します。

    # mkdir /etc/tuned/my-profile
  3. 選択したブロックデバイスの World Wide Name (WWN) 識別子を見つけます。

    $ udevadm info --query=property --name=/dev/device | grep WWN=
    
    ID_WWN=0x5002538d00000000
  4. /etc/tuned/my-profile/tuned.conf 設定ファイルを作成します。このファイルで、以下のオプションを設定します。

    • 必要に応じて、既存のプロファイルを追加します。

      [main]
      include=existing-profile
    • WWN 識別子に一致するデバイスに対して選択したディスクスケジューラーを設定します。

      [disk]
      devices_udev_regex=ID_WWN=0x5002538d00000000
      elevator=selected-scheduler

      devices_udev_regex オプションで複数のデバイスと一致させるには、識別子を括弧で囲み、垂直バーで区切ります。

      devices_udev_regex=(ID_WWN=0x5002538d00000000)|(ID_WWN=0x1234567800000000)
  5. プロファイルを有効にします。

    # tuned-adm profile my-profile
  6. Tuned プロファイルがアクティブで適用されていることを確認します。

    $ tuned-adm active
    
    Current active profile: my-profile
    $ tuned-adm verify
    
    Verification succeeded, current system settings match the preset profile.
    See tuned log file ('/var/log/tuned/tuned.log') for details.

関連情報

13.7. udev ルールでディスクスケジューラーの設定

この手順では、udev ルールを使用して、特定ブロックデバイスに、特定のディスクスケジューラーを設定します。この設定は、システムを再起動しても持続します。

以下のコマンドと設定で、次の内容を置き換えます。

  • device を、ブロックデバイスの名前 (例: sdf) に置き換えます。
  • selected-scheduler を、デバイスに設定するディスクスケジューラー (例: bfq) に置き換えます。

手順

  1. ブロックデバイスの World Wide Identifier (WWID) を見つけます。

    $ udevadm info --attribute-walk --name=/dev/device | grep wwid
    
        ATTRS{wwid}=="device WWID"

    デバイス WWID には、以下のような値があります。

    t10.ATA     SAMSUNG MZNLN256HMHQ-000L7              S2WDNX0J336519
  2. udev ルールを設定します。以下の内容で /etc/udev/rules.d/99-scheduler.rules ファイルを作成します。

    ACTION=="add|change", SUBSYSTEM=="block", ATTRS{wwid}=="device WWID", ATTR{queue/scheduler}="selected-scheduler"

    WWID を、前の手順で確認した WWID 値に置き換えます。

  3. udev ルールを再読み込みします。

    # udevadm control --reload-rules
  4. スケジューラー設定を適用します。

    # udevadm trigger --type=devices --action=change
  5. アクティブなスケジューラーを確認します。

    # cat /sys/block/device/queue/scheduler

13.8. 特定ディスクに任意のスケジューラーを一時的に設定

この手順では、特定のブロックデバイスに、特定のディスクスケジューラーを設定します。この設定は、システムを再起動すると元に戻ります。

手順

  • 選択したスケジューラーの名前を、/sys/block/device/queue/scheduler ファイルに書き込みます。

    # echo selected-scheduler > /sys/block/device/queue/scheduler

    ファイル名の device を、sdc などのブロックデバイス名に置き換えます。

検証手順

  • スケジューラーがデバイスでアクティブになっていることを確認します。

    # cat /sys/block/device/queue/scheduler

第14章 リモートディスクレスシステムの設定

次のセクションでは、ネットワーク環境にリモートディスクレスシステムをデプロイするのに必要な手順の概要を説明します。同じ設定で複数のクライアントが必要な場合は、このソリューションを実装すると便利です。また、クライアントの数だけハードドライブのコストを節約できます。Red Hat Enterprise Linux 8 オペレーティングシステムがインストールされていることを前提とします。

図14.1 リモートディスクレスシステム設定のダイアグラム

リモートディスクレスシステム設定のダイアグラム

ゲートウェイは別のサーバーに設定する可能性があることに注意してください。

14.1. リモートディスクレスシステム用環境の準備

この手順では、リモートディスクレスシステム用の環境の準備を説明します。

リモートディスクレスシステムを起動するには、tftp サービス (tftp-server が提供) および DHCP サービス (dhcp が提供) の両方が必要です。tftp サービスは、PXE ローダーを介してネットワーク経由でカーネルイメージと initrd を取得するために使用されます。

前提条件

  • 以下のパッケージをインストールしている。

    • tftp-server
    • xinetd
    • dhcp-server
    • syslinux
  • ネットワーク接続を設定している。

手順

  1. dracut-network パッケージをインストールします。

    # yum install dracut-network
  2. dracut-network パッケージをインストールしたら、以下の行を /etc/dracut.conf に追加します。

    add_dracutmodules+="nfs"
重要

一部の RPM パッケージは、ファイル機能 (setcapgetcap など) を使用して開始しました。ただし、現在 NFS ではこれらの機能に対応していないため、ファイル機能を使用するパッケージのインストールまたは更新に失敗します。

この時点で、リモートディスクレスシステムの実装を続行する準備が整ったサーバーを用意できます。

14.2. ディスクレスクライアントの tftp サービスの設定

この手順では、ディスクレスクライアントの tftp サービスを設定する方法を説明します。

前提条件

tftp を設定するには、以下を行います。

  1. ネットワーク上での PXE ブートを有効にします。

    # systemctl enable --now tftp
  2. tftp root ディレクトリー (chroot) は /var/lib/tftpboot にあります。/usr/share/syslinux/pxelinux.0/var/lib/tftpboot/ にコピーします。

    # cp /usr/share/syslinux/pxelinux.0 /var/lib/tftpboot/
  3. tftp の root ディレクトリーに pxelinux.cfg ディレクトリーを作成します。

    # mkdir -p /var/lib/tftpboot/pxelinux.cfg/
  4. ディスクレスクライアントの tftp を設定した後に、DHCP、NFS、エクスポートしたファイルシステムを適宜設定します。

14.3. ディスクレスクライアントの DHCP サーバーの設定

この手順では、ディスクレスシステムに DHCP を設定する方法を説明します。

前提条件

手順

  1. 以下の設定を /etc/dhcp/dhcpd.conf に追加して、DHCP サーバーを設定し、PXE ブートを有効にします。

    allow booting;
    allow bootp;
    subnet 192.168.205.0 netmask 255.255.255.0 {
      pool
      {
        range 192.168.205.10 192.168.205.25;
      }
    
      option subnet-mask 255.255.255.0;
      option routers 192.168.205.1;
    }
    class "pxeclients" {
       match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
       next-server server-ip;
       filename "pxelinux.0";
    }

    この設定は UEFI からは起動しません。「UEFI ベースのクライアント向けに TFTP サーバーの設定」を参照してください。また、/etc/dhcp/dhcpd.conf はサンプルファイルであることに注意してください。

    注記

    libvirt 仮想マシンがディスクレスクライアントとして使用されると、libvirt は DHCP サービスを提供し、スタンドアロン DHCP サーバーは使用されません。このような状況では、libvirt ネットワーク設定 virsh net-editbootp file='filename' オプションで、ネットワークブートを有効にする必要があります。

  2. 次のコマンドを実行して、dhcpd.service を有効にします。

    # systemctl enable --now dhcpd.service

14.4. ディスクレスクライアントのエクスポートしたファイルシステムの設定

この手順では、ディスクレスクライアントのエクスポートしたファイルシステムを設定する方法を説明します。

前提条件

手順

  1. /etc/exports にその root ディレクトリーを追加して、root ディレクトリーをエクスポートするように NFS サーバーを設定します。手順は、「NFS サーバーの設定」を参照してください。
  2. ディスクレスクライアントに完全に対応できるようにするには、root ディレクトリーには Red Hat Enterprise Linux の完全なインストールが含まれている必要があります。新しいベースシステムをインストールするか、または既存のインストールのクローンを作成できます。

    • Red Hat Enterprise Linux をエクスポートした場所にインストールするには、--installroot オプションを指定して yum ユーティリティーを使用します。

      # yum install @Base kernel dracut-network nfs-utils \
            --installroot=exported-root-directory --releasever=/
    • 実行中のシステムで同期するには、rsync ユーティリティーを使用します。

      # rsync -a -e ssh --exclude='/proc/' --exclude='/sys/' \
             example.com:/exported-root-directory
      • hostname.com を、rsync を介して同期する実行中のシステムのホスト名に置き換えます。
      • exported-root-directory を、エクスポートしたファイルシステムへのパスに置き換えます。

        このオプションには、実行中の別のシステムが必要です。これは、このコマンドでサーバーにクローンを作成します。

エクスポートするファイルシステムは、ディスクレスクライアントが使用できるようにする前に追加で設定する必要があります。空き領域が足りない場合は、次の手順を実行します。

ファイルシステムの設定

  1. ディスクレスクライアントが使用するカーネル (vmlinuz-kernel-version) を選択し、tftp の boot ディレクトリーにコピーします。

    # cp /exported-root-directory/boot/vmlinuz-kernel-version /var/lib/tftpboot/
  2. NFS サポートで initrd (つまり initramfs-kernel-version.img) を作成します。

    # dracut --add nfs initramfs-kernel-version.img kernel-version
  3. 次のコマンドで initrd のファイル権限を 644 に変更します。

    # chmod 644 /exported-root-directory/boot/initramfs-<kernel-version>.img
    警告

    initrd のファイルパーミッションを変更しないと、pxelinux.0 ブートローダーが「file not found」エラーで失敗します。

  4. 作成した initramfs-kernel-version.imgtftp の boot ディレクトリーにコピーします。

    # cp /exported-root-directory/boot/initramfs-kernel-version.img /var/lib/tftpboot/
  5. /var/lib/tftpboot/ ディレクトリーに initrd とカーネルを使用するように、デフォルトのブート設定を編集します。この設定は、エクスポートしたファイルシステム (/exported-root-directory) を読み書きとしてマウントするよう、ディスクレスクライアントの root に指示を出します。/var/lib/tftpboot/pxelinux.cfg/default ファイルに以下の設定を追加します。

    default rhel8
    
    label rhel8
      kernel vmlinuz-kernel-version
      append initrd=initramfs-kernel-version.img root=nfs:server-ip:/exported-root-directory rw

    server-ip を、tftp サービスと DHCP サービスが置かれているホストマシンの IP アドレスに置き換えます。

  6. NFS サーバーを再起動します。

これで、NFS 共有がディスクレスクライアントにエクスポートできるようになりました。これらのクライアントは、PXE 経由でネットワーク経由で起動できます。

14.5. リモートディスクレスシステムの再設定

場合によってはシステムの再設定が必要になる場合があります。以下の手順は、ユーザーがパスワードを変更する方法、システムにソフトウェアをインストールする方法、およびシステムを読み取り専用モードの /usr に分割する方法、読み取りと書き込みモードの /var に説明する方法を示しています。

前提条件

  • no_root_squash オプションは、エクスポートしたファイルシステムで有効にしている。

手順

  1. ユーザーパスワードを変更するには、以下の手順に従います。

    • コマンドラインを /exported/root/directory に変更します。

      # chroot /exported/root/directory /bin/bash
    • 必要なユーザーのパスワードを変更します。

      # passwd <username>

      <username> を、パスワードを変更する必要がある実際のユーザーに置き換えます。

    • コマンドラインを終了します。

      # exit
  2. リモートのディスクレスシステムにソフトウェアをインストールするには、次のコマンドを使用します。

    # yum install <package> --installroot=/exported/root/directory --releasever=/ --config /etc/dnf/dnf.conf --setopt=reposdir=/etc/yum.repos.d/

    <package> を、インストールする実際のパッケージに置き換えます。

  3. リモートディスクレスシステムを /usr および /var に分割し、別々のエクスポートを設定する必要があります。詳細は、「NFS サーバーの設定」を参照してください。

14.6. リモートディスクレスシステムの読み込みにおける最も一般的な問題

以下のセクションでは、ディスクレスクライアントでリモートディスクレスシステムの読み込み時の問題と、その解決可能な解決策を説明します。

14.6.1. クライアントが IP アドレスを取得しない

この問題のトラブルシューティングを行うには、次を行います。

  1. DHCP サービスがサーバーで有効になっているかどうかを確認します。

    • dhcp.service が実行しているかどうかを確認します。

      # systemctl status dhcpd.service
    • dhcp.service がアクティブでない場合は、有効にして起動する必要があります。

      # systemctl enable dhcpd.service
      # systemctl start dhcpd.service

      ディスクレスクライアントを再起動します。

  2. それでも問題が続く場合は、サーバーで DHCP 設定ファイル /etc/dhcp/dhcpd.conf を確認します。詳細は「ディスクレスクライアントの DHCP サーバーの設定」を参照してください。
  3. ファイアウォールポートが開いているかどうかを確認します。

    • tftp.service がアクティブなサービスに記載されているかどうかを確認します。

      # firewall-cmd --get-active-zones
      # firewall-cmd --info-zone=public
    • tftp.service がアクティブなサービスに記載されていない場合は、一覧に追加します。

      # firewall-cmd --add-service=tftp
    • nfs.service がアクティブなサービスに記載されているかどうかを確認します。

      # firewall-cmd --get-active-zones
      # firewall-cmd --info-zone=public
    • nfs.service がアクティブなサービスに記載されていない場合は、これを一覧に追加します。

      # firewall-cmd --add-service=nfs

14.6.2. リモートディスクレスシステムの起動時に、ファイルは使用できない

この問題を解決するには、以下を行います。

  1. ファイルが有効であるかどうかを確認します。サーバーの場所が /var/lib/tftpboot/ です。
  2. ファイルが導入される場合は、その権限を確認します。

    # chmod 644 pxelinux.0
  3. ファイアウォールポートが開いているかどうかを確認します。

14.6.3. カーネル/initrd の読み込み時に、システムの起動に失敗した

この問題を解決するには、以下を行います。

  1. サーバーで NFS サービスが有効になっているかどうかを確認します。

    • nfs.service が実行中かどうかを確認します。

      # systemctl status nfs.service
    • nfs.service が非アクティブの場合は、有効にして起動する必要があります。

      # systemctl enable nfs.service
      # systemctl start nfs.service
  2. pxelinux.cfg でパラメーターが正しいかどうかを確認します。詳細は「ディスクレスクライアントのエクスポートしたファイルシステムの設定」を参照してください。
  3. ファイアウォールポートが開いているかどうかを確認します。

第15章 RAID の管理

この章では、RAID (Redundant Array of Independent Disks) を説明します。ユーザーが RAID を使用して、複数のドライブにデータを保存できます。また、ドライブに障害が発生した場合にデータ損失を回避するのに役立ちます。

15.1. RAID (Redundant array of independent disks)

RAID の背後にある基本的な概念は、HDDSSDNVMe などの複数のデバイスをアレイに組み合わせて、1 つの大型で高価なドライブでは達成できないパフォーマンスまたは冗長性の目標を達成することです。このデバイスのアレイは、1 つの論理ストレージユニットまたはドライブとしてコンピューターに表示されます。

RAID により、情報を複数のデバイスに分散させることができます。RAID は、ディスクストライピング (RAID レベル 0)、ディスクミラーリング (RAID レベル 1)、および パリティーによるディスクストライピング (RAID レベル 4、5、および 6) などの技術を使用して冗長性を実現し、待ち時間を短縮し、帯域幅を最大化し、ハードディスクのクラッシュからの復旧能力を最大化します。

RAID は、データを一貫して使用するチャンク (通常は 256K または 512k、他の値は受け入れ可能) に分割することで、アレイ内の各デバイスにデータを分散します。各チャンクは、使用している RAID レベルに応じて、RAID アレイのハードドライブに書き込まれます。データが読み込まれると、プロセスは逆に終了し、アレイ内の複数のデバイスが実際には 1 つの大きなドライブであることを確認できます。

システム管理者や大容量のデータを管理しているユーザーは、RAID 技術を使用することでメリットが得られます。RAID をデプロイする主な理由を以下に示します。

  • 速度を高める
  • 1 台の仮想ディスクを使用してストレージ容量を増加する
  • ディスク障害によるデータ損失を最小限に抑える
  • RAID レイアウトおよびレベルオンライン変換

15.2. RAID のタイプ

考えられる RAID アプローチには、ファームウェア RAID、ハードウェア RAID、およびソフトウェア RAID の 3 つがあります。

ファームウェア RAID

ファームウェア RAID (ATARAID とも呼ばれる) とは、ソフトウェア RAID の種類で、ファームウェアベースのメニューを使用して RAID セットを設定できます。このタイプの RAID で使用されるファームウェアは BIOS にもフックされるため、その RAID セットから起動できます。異なるベンダーは、異なるオンディスクメタデータ形式を使用して、RAID セットのメンバーをマークします。Intel Matrix RAID は、ファームウェア RAID システムの一例を示しています。

ハードウェア RAID

ハードウェアベースのアレイは、RAID サブシステムをホストとは別に管理します。ホストに対して RAID アレイごとに複数のデバイスが表示される場合があります。

ハードウェア RAID デバイスは、システムの内部または外部になる場合があります。内部デバイスは、一般的には、RAID タスクをオペレーティングシステムに対して透過的に処理する専用のコントローラーカードで構成されています。外部デバイスは、一般的には SCSI、ファイバーチャネル、iSCSI、InfiniBand などの高速ネットワーク相互接続を介してシステムに接続し、システムへの論理ユニットなどのボリュームを提示します。

RAID コントローラーカードは、オペレーティングシステムへの SCSI コントローラーのように動作し、実際のドライブ通信をすべて処理します。ユーザーがドライブを RAID コントローラーに差し込み (通常の SCSI コントローラーと同様)、RAID コントローラーの設定に追加します。オペレーティングシステムはこの違いを認識できません。

ソフトウェア RAID

ソフトウェア RAID は、カーネルブロックデバイスコード内にさまざまな RAID レベルを実装します。高価ディスクコントローラーカードやホットスワップシャーシなど、最優先的な解決策を提供します。 [1] 必須ではありません。ソフトウェア RAID は、SATASCSINVMe などの Linux カーネルが対応しているブロックストレージでも機能します。現在高速 CPU では、ハイエンドのストレージデバイスを使用する場合以外は、ソフトウェア RAID は通常ハードウェア RAID の規模を上回します。

Linux カーネルには、RAID ソリューションは完全にハードウェアに依存しないようにする 複数のデバイス (MD) ドライバーが含まれています。ソフトウェアベースのアレイのパフォーマンスは、サーバーの CPU パフォーマンスと負荷によって異なります。

Linux ソフトウェア RAID スタックの主な機能:

  • マルチスレッド設計
  • 再構築なしで Linux マシン間でのアレイの移植性
  • アイドルシステムリソースを使用したバックグラウンドのアレイ再構築
  • ホットスワップ可能なドライブのサポート
  • CPU の自動検出は、ストリーミングの SIMD (Single Instruction Multiple Data) サポートの特定 CPU 機能を活用
  • アレイ内のディスク上にある不良セクターの自動修正
  • RAID データの整合性を定期的にチェックしアレイの健全性を確保
  • 重要なイベントで指定された電子メールアドレスに送信された電子メールアラートによるアレイのプロアクティブな監視
  • システムのクラッシュ後にアレイ全体を再同期する代わりに、ディスクのどの部分を再同期する必要があるかをカーネルが正確に把握できるようにすることで、再同期イベントの速度を大幅に向上させる書き込みが集中しているビットマップ

    再同期 は、冗長性を実現するために、既存の RAID のデバイスにデータを同期するプロセスである点に注意してください。

  • チェックポイントを再同期して、再同期中にコンピューターを再起動すると、起動時に再同期が中断したところから再開し、最初からやり直さないようにします。
  • インストール後にアレイのパラメーターを変更する機能は、再形成 と呼ばれます。たとえば、新しいデバイスを追加しても、4 つのディスクの RAID5 アレイを 5 つのディスク RAID5 アレイに増大させることができます。この拡張操作はライブで行うため、新しいアレイで再インストールする必要はありません。
  • 再成形は、RAID アルゴリズム、RAID アレイタイプのサイズ (RAID4、RAID5、RAID6、RAID10 など) の変更に対応しています。
  • テイクオーバーは、RAID0 ~ RAID6 などの RAID レベル変換を対応します。


[1] ホットスワップシャーシを使用すると、システムの電源を切らずにハードドライブを削除できます。

15.3. RAID レベルとリニアサポート

RAID は、レベル 0、1、4、5、6、10、リニアなどのさまざまな設定に対応します。これらの RAID タイプは以下のように定義されます。

レベル 0

RAID レベル 0 は、多くの場合「ストライプ化」と呼ばれていますが、パフォーマンス指向のストライプ化データマッピング技術です。これは、アレイに書き込まれるデータがストライプに分割され、アレイのメンバーディスク全体に書き込まれることを意味します。これにより低い固有コストで高い I/O パフォーマンスを実現できますが、冗長性は提供されません。

多くの RAID レベル 0 実装は、アレイ内の最小デバイスのサイズまで、メンバーデバイス全体にデータをストライプ化します。つまり、複数のデバイスのサイズが少し異なる場合、それぞれのデバイスは最小ドライブと同じサイズであるかのように処理されます。そのため、レベル 0 アレイの一般的なストレージ容量は、ハードウェア RAID 内の最小メンバーディスクの容量と同じか、アレイ内のディスク数またはパーティション数で乗算したソフトウェア RAID 内の最小メンバーパーティションの容量と同じになります。

レベル 1

RAID レベル 1 または「ミラーリング」は、他の RAID 形式よりも長く使用されています。レベル 1 は、アレイ内の各メンバーディスクに同一データを書き込むことで冗長性を提供し、各ディスクに対して「ミラーリング」コピーをそのまま残します。ミラーリングは、データの可用性の単純化と高レベルにより、いまでも人気があります。レベル 1 は 2 つ以上のディスクと連携して、非常に優れたデータ信頼性を提供し、読み取り集中型のアプリケーションに対してパフォーマンスが向上しますが、比較的コストが高くなります。[2]

レベル 1 アレイのストレージ容量は、ハードウェア RAID 内でミラーリングされている最小サイズのハードディスクの容量と同じか、ソフトウェア RAID 内でミラーリングされている最小のパーティションと同じ容量になります。レベル 1 の冗長性は、すべての RAID タイプの中で最も高いレベルであり、アレイは 1 つのディスクのみで動作できます。

レベル 4

レベル 4 でパリティーを使用 [3] データを保護するため、1 つのディスクドライブで連結します。専用パリティーディスクは RAID アレイへのすべての書き込みトランザクションに固有のボトルネックを表すため、レベル 4 は、ライトバックキャッシュなどの付随技術なしで、またはシステム管理者がこれを使用してソフトウェア RAID デバイスを意図的に設計する特定の状況で使用されることはほとんどありません。ボトルネック (配列にデータが入力されると、書き込みトランザクションがほとんどまたはまったくない配列など) を念頭に置いてください。RAID レベル 4 にはほとんど使用されないため、Anaconda ではこのオプションとしては使用できません。ただし、実際には必要な場合は、ユーザーが手動で作成できます。

ハードウェア RAID レベル 4 のストレージ容量は、最小メンバーパーティションの容量にパーティションの数を掛けて、-1 を引いたものになります。RAID レベル 4 アレイのパフォーマンスは常に非対称になります。つまり、読み込みは書き込みを上回ります。これは、パリティーを生成するときに書き込みが余分な CPU 帯域幅とメインメモリーの帯域幅を消費し、データだけでなくパリティーも書き込むため、実際のデータをディスクに書き込むときに余分なバス帯域幅も消費するためです。読み取りが必要なのは、アレイが劣化状態にない限り、パリティーではなくデータでを読み取るだけです。その結果、通常の動作条件下で同じ量のデータ転送を行う場合は、読み取りによってドライブへのトラフィック、またはコンピュータのバスを経由するトラフィックが少なくなります。

レベル 5

これは RAID の最も一般的なタイプです。RAID レベル 5 は、アレイのすべてのメンバーディスクドライブにパリティーを分散することにより、レベル 4 に固有の書き込みボトルネックを排除します。パリティー計算プロセス自体のみがパフォーマンスのボトルネックです。最新の CPU とソフトウェア RAID では、最近の CPU がパリティーが非常に高速になるため、通常はボトルネックではありません。ただし、ソフトウェア RAID5 アレイに多数のメンバーデバイスがあり、組み合わせたすべてのデバイス間のデータ転送速度が十分であれば、このボトルネックは再生できます。

レベル 4 と同様に、レベル 5 のパフォーマンスは非対称であり、読み取りは書き込みを大幅に上回ります。RAID レベル 5 のストレージ容量は、レベル 4 と同じです。

レベル 6

パフォーマンスではなくデータの冗長性と保存が最重要事項であるが、レベル 1 の領域の非効率性が許容できない場合は、これが RAID の一般的なレベルです。レベル 6 では、複雑なパリティースキームを使用して、アレイ内の 2 つのドライブから失われたドライブから復旧できます。複雑なパリティースキームにより、ソフトウェア RAID デバイスで CPU 幅が大幅に高くなり、書き込みトランザクションの際に増大度が高まります。したがって、レベル 6 はレベル 4 や 5 よりもパフォーマンスにおいて、非常に非対称です。

RAID レベル 6 アレイの合計容量は、RAID レベル 5 および 4 と同様に計算されますが、デバイス数から追加パリティーストレージ領域用に 2 つのデバイス (1 ではなく) を引きます。

レベル 10

この RAID レベルでは、レベル 0 のパフォーマンスとレベル 1 の冗長性を組み合わせます。また、2 を超えるデバイスを持つレベル 1 アレイで領域の一部を軽減するのに役立ちます。レベル 10 では、データごとに 2 つのコピーのみを格納するように設定された 3 ドライブアレイを作成することができます。これにより、全体用のアレイサイズを最小デバイスのみと同じサイズ (3 つのデバイス、レベル 1 アレイなど) ではなく、最小サイズのデバイスが 1.5 倍になります。これにより、CPU プロセスの使用量が RAID レベル 6 のようにパリティーを計算するのを防ぎますが、これは領域効率が悪くなります。

RAID レベル 10 の作成は、インストール時には対応していません。コマンドラインの mdadm ツールで手動で作成できます。オプションの詳細および各パフォーマンスに関するトレードオフは、man md を参照してください。

リニア RAID
リニア RAID は、より大きな仮想ドライブを作成するドライブのグループ化です。リニア RAID では、あるメンバードライブからチャンクが順次割り当てられます。最初のドライブが完全に満杯になったときにのみ次のドライブに移動します。これにより、メンバードライブ間の I/O 操作が分割される可能性はないため、パフォーマンスの向上は見られません。リニア RAID には冗長性がなく、信頼性は低下します。メンバードライブに障害が発生した場合は、アレイ全体を使用することはできません。容量はすべてのメンバーディスクの合計になります。


[2] RAID レベル 1 は、アレイ内のすべてのディスクに同じ情報を書き込むため、コストが高まり、データの信頼性を提供しますが、レベル 5 のようなパリティーベースの RAID レベルよりもはやくなり領域の効率が低くなります。ただし、この領域の非効率性にはパフォーマンス上の利点があります。パリティーベースの RAID レベルは、パリティーを生成するためにかなり多くの CPU 電力を消費しますが、RAID レベル 1 は単に同じデータを、CPU オーバーヘッドが非常に少ない複数の RAID メンバーに同じデータを複数回書き込むだけです。そのため、RAID レベル 1 は、ソフトウェア RAID が使用されているマシンや、マシンの CPU リソースが一貫して RAID アクティビティー以外の操作でアレイ化されます。
[3] パリティー情報は、アレイ内の残りのメンバーディスクのコンテンツに基づいて計算されます。この情報は、アレイ内のいずれかのディスクに障害が発生した場合にデータの再構築に使用できます。その後、再構築されたデータを使用して、交換前に失敗したディスクに I/O 要求に対応でき、交換後に失敗したディスクを接続します。

15.4. Linux RAID サブシステム

Linux では、以下のサブシステムで RAID を作成します。

15.4.1. Linux ハードウェア RAID のコントローラードライバー

Linux には、ハードウェア RAID コントローラーに固有の RAID サブシステムがありません。特殊な RAID チップセットを使用するため、ハードウェア RAID コントローラーには独自のドライバーが含まれます。これらのドライバーにより、システムは通常のディスクとして RAID セットを検出できるようになります。

15.4.2. mdraid

mdraid サブシステムは Linux 向けのソフトウェア RAID ソリューションとして設計されており、Linux 下のソフトウェア RAID に対する推奨ソリューションです。このサブシステムでは独自のメタデータ形式が使用され、通常はネイティブの MD メタデータと呼ばれます。

mdraid は外部メタデータとして知られる他のメタデータ形式にも対応しています。Red Hat Enterprise Linux 8 は、外部のメタデータで mdraid を使用して ISW/IMSM (Intel のファームウェア RAID) セットおよび SNIA DDF にアクセスします。mdraid セットは mdadm ユーティリティーで設定および制御を行います。

15.5. ソフトウェア RAID の作成

以下の手順に従って、RAID ( Redundant Arrays of Independent Disks) ディスクを作成します。RAID デバイスは、複数のストレージディスクで構成され、組み合わせてパフォーマンスを向上させます。また、一部の設定では、より高い耐障害性を得ることができます。

RAID デバイスの作成は 1 つのステップで終わり、必要に応じてディスクを追加または削除できます。システムでは、1 つの物理ディスクに 1 つの RAID パーティションが作成できるため、インストールプログラムで使用できるディスク数により、利用できる RAID デバイスのレベルが決定します。たとえば、システムにハードドライブが 2 つある場合は、RAID 10 デバイスを作成することはできません。少なくともディスクが 3 つ必要になるためです。

注記

IBM Z では、ストレージのサブシステムで RAID が透過的に使用されます。ソフトウェア RAID を手動で構成する必要はありません。

前提条件

  • RAID 設定オプションは、インストール用に複数のディスクを選択している場合にのみ表示される。RAID デバイスの作成には少なくともディスクが 2 つ必要になります。
  • マウントポイントを作成している。マウントポイントを設定して、RAID デバイスを設定します。
  • インストール先 画面で カスタム ラジオボタンを選択している。

手順

  1. 手動パーティション設定 画面の左側のペインで、必要なパーティションを選択します。
  2. デバイス セクションの下にある 修正 をクリックします。マウントポイントの設定 ダイアログボックスが開きます。
  3. RAID デバイスに追加するディスクを選択して、選択 をクリックします。
  4. デバイスタイプ ドロップダウンメニューをクリックして、RAID を選択します。
  5. ファイルシステム のドロップダウンメニューをクリックして、目的のファイルシステムタイプを選択します。
  6. RAID レベル ドロップダウンメニューをクリックして、目的の RAID レベルを選択します。
  7. 設定を更新 をクリックして、変更を保存します。
  8. 完了 をクリックして設定を適用し、インストール概要 画面に戻ります。

指定した RAID レベルでさらにディスクが必要な場合は、画面下部にメッセージが表示されます。

15.6. インストール後のソフトウェア RAID の作成

この手順では、mdadm ユーティリティーを使用して、既存のシステムにソフトウェアの RAID (Redundant Array of Independent Disks) を作成する方法を説明します。

前提条件

  • mdadm パッケージがインストールされている。
  • システムに複数のパーティションが存在している。詳細な手順は、「パーティションの作成」を参照してください。

手順

  1. /dev/sda1 および /dev/sdc1 という名前のブロックデバイスの RAID を作成するには、次のコマンドを使用します。

    # mdadm --create /dev/md0 --level=<level_value> --raid-devices=2 /dev/sda1 /dev/sdc1

    <level_value> を、RAID レベルオプションに置き換えます。詳細は、man ページの mdadm(8) を参照してください。

  2. 必要に応じて、RAID のステータスを確認するには、次のコマンドを実行します。

    # mdadm --detail /dev/md0
  3. 必要に応じて、各 RAID デバイスの詳細情報を確認するには、次のコマンドを実行します。

    # mdadm --examine /dev/sda1 /dev/sdc1
  4. RAID ドライブにファイルシステムを作成するには、次のコマンドを実行します。

    # mkfs -t <file-system-name> /dev/md0

    ここで、<file-system-name> は、ドライブのフォーマットを選択した特定のファイルシステムです。詳細は、man ページの mkfs を参照してください。

  5. RAID ドライブ用にマウントポイントを作成し、そのマウントポイントをマウントするには、次のコマンドを使用します。

    # mkdir /mnt/raid1
    # mount /dev/md0 /mnt/raid1

上記の手順を完了すると、RAID を使用する準備が整います。

15.7. RAID の再設定

次のセクションでは、既存の RAID を変更する方法を説明します。これを行うには、以下のいずれかの方法を選択します。

  • RAID 属性の変更 (RAID 再成形 とも呼ばれています)
  • RAID レベルの変換 (RAID テイクオーバー とも呼ばれています)

15.7.1. RAID の再成形

本章では、RAID を再成形する方法を説明します。RAID のサイズを変更する方法のいずれかを選択できます。

  • RAID の拡大 (拡張)。
  • RAID を縮小。

15.7.1.1. RAID のサイズ変更 (拡張)。

この手順では、RAID を拡大する方法を説明します。拡大する RAID が /dev/md0 であるとします。

前提条件

  • 十分なディスク領域
  • parted パッケージがインストールされている。

手順

  1. RAID パーティションを拡張します。これを行うには、「パーティションのサイズ変更」の指示に従ってください。
  2. パーティションの最大容量まで RAID を拡張するには、次のコマンドを使用します。

    # mdadm --grow --size=max /dev/md0

    特定のサイズを指定するには、(例: --size=524228) で --size パラメーター (kB) を書き込む必要があります。

  3. ファイルシステムのサイズを拡大します。詳細は、「ファイルシステムの管理」を参照してください。

15.7.1.2. RAID のサイズ変更 (縮小)

この手順では、RAID を縮小する方法を説明します。512 MB に縮小する RAID が /dev/md0 であるとします。

前提条件

  • parted パッケージがインストールされている。

手順

  1. ファイルシステムを縮小します。これを行うには、「ファイルシステムの管理」を参照してください。

    重要

    XFS ファイルシステムは縮小に対応していません。

  2. RAID のサイズを 512 MB に減らすには、次のコマンドを使用します。

    # mdadm --grow --size=524228 /dev/md0

    --size パラメーターを kB で書き込んでいなければならないことに注意してください。

  3. パーティションのサイズを、必要なサイズまで縮小します。これを行うには、「パーティションのサイズ変更」を行ってください。

15.7.2. RAID テイクオーバー

本章では、RAID で対応する変換と、この変換を行う手順を説明します。

15.7.2.1. サポート対象の RAID 変換

RAID レベルを別のレベルに変換することが可能です。本セクションでは、対応している RAID 変換の表を紹介します。

 RAID0RAID1RAID4RAID5RAID6RAID10

RAID0

RAID1

RAID4

RAID5

RAID6

RAID10

たとえば、RAID レベル 0 を RAID レベル 4、RAID レベル 5、および RAID レベル 10 に変換できます。

関連情報

  • RAID レベル変換の詳細は、man ページの mdadm を参照してください。

15.7.2.2. RAID レベルへの変換

この手順では、RAID を別の RAID レベルに変換する方法を説明します。RAID の /dev/md0 レベル 0 を RAID レベル 5 に変換し、ディスク /dev/sdd をアレイに追加します。

前提条件

  • 変換するのに十分なディスク。
  • mdadm パッケージがインストールされている。
  • 目的の変換が対応していることを確認してある。これを確認するには、「サポート対象の RAID 変換」の表を参照してください。

手順

  1. RAID /dev/md0 を RAID レベル 5 に変換するには、次のコマンドを実行します。

    # mdadm --grow --level=5 -n 3 /dev/md0 --force
  2. 新規ディスクをアレイに追加するには、次のコマンドを実行します。

    # mdadm --manage /dev/md0 --add /dev/sdd
  3. 変換したアレイの新規詳細を確認するには、次のコマンドを実行します。

    # mdadm --detail /dev/md0

関連情報

  • RAID レベル変換の詳細は、man ページの mdadm を参照してください。

15.8. インストール後の root ディスクの RAID1 への変換

本セクションでは、Red Hat Enterprise Linux 8 のインストール後に RAID 以外の root ディスクを RAID1 ミラーに変換する方法を説明します。

PowerPC (PPC) アーキテクチャーでは、以下の追加手順を行う必要があります。

前提条件

手順

  1. PowerPC Reference Platform (PReP) 起動パーティションの内容を /dev/sda1 から /dev/sdb1 にコピーします。

    # dd if=/dev/sda1 of=/dev/sdb1
  2. 両方のディスクの最初のパーティションで Prep フラグおよび boot フラグを更新します。

    $ parted /dev/sda set 1 prep on
    $ parted /dev/sda set 1 boot on
    
    $ parted /dev/sdb set 1 prep on
    $ parted /dev/sdb set 1 boot on
注記

PowerPC マシンでは grub2-install /dev/sda コマンドを実行しても動作せず、エラーが返されますが、システムは想定どおりに起動します。

15.9. 高度な RAID デバイスの作成

インストール完了後には作成できないアレイにオペレーティングシステムをインストールする場合があります。通常、/boot または root ファイルシステムのアレイは複雑な RAID デバイスに設定されます。このような場合は、Anaconda インストーラーで対応していないアレイオプションの使用が必要になる場合があります。これを回避するには、以下の手順を行います。

手順

  1. インストールディスクを挿入します。
  2. 最初の起動時に、インストール または アップグレード の代わりに レスキューモード を選択します。システムが レスキューモード で完全に起動すると、コマンドラインターミナルが表示されます。
  3. このターミナルで parted を使用し、目的のハードドライブに RAID パーティションを作成します。次に mdadm を使用して、使用できるすべての設定およびオプションを使用して、このパーティションから RAID アレイを手動で作成します。詳細は、man parted および man mdadm を参照してください。
  4. アレイを作成したら、必要に応じてアレイにファイルシステムを作成することもできます。
  5. コンピューターを再起動して、インストール または 更新 を選択して通常通りにインストールします。Anaconda インストーラーはシステム内のディスクを検索するため、既存の RAID デバイスが見つかります。
  6. システムのディスクの使い方を求められたら、カスタムレイアウト を選択して 次へ をクリックします。デバイス一覧に、既存の MD RAID デバイスが表示されます。
  7. RAID デバイスを選択し、編集 をクリックしてそのマウントポイントと (必要に応じて) 使用するファイルシステムのタイプを設定し、完了 をクリックします。Anaconda は、この既存の RAID デバイスにインストールを実行し、レスキューモード で作成したときに選択したカスタムオプションを保持します。
注記

インストーラーの制限された レスキューモード には man ページは含まれません。man mdadm および man md の両方には、カスタムの RAID アレイ作成に役立つ情報が含まれています。回避策全体にわたって必要になる場合があります。このため、man ページが含まれるマシンにアクセスできるようにしておくか、そのページを開いて、レスキューモード で起動してからカスタムアレイを作成しておくと便利です。

15.10. RAID の監視

このモジュールでは、mdadm ツールを使用して RAID 監視オプションを設定する方法を説明します。

前提条件

  • mdadm パッケージがインストールされている。
  • メールサービスが設定されている。

手順

  1. アレイのモニタリング用の設定ファイルを作成するには、詳細をスキャンし、結果を /etc/mdadm.conf ファイルに転送する必要があります。これを実行するには、次のコマンドを使用します。

    # mdadm --detail --scan >> /etc/mdadm.conf

    ARRAY および MAILADDR は必須の変数であることに注意してください。

  2. 設定ファイル /etc/mdadm.conf を任意のテキストエディターで開きます。
  3. 通知用のメールアドレスを使用して MAILADDR 変数を追加します。たとえば、次の行を追加します。

    MAILADDR <example@example.com>

    example@example.com は、アレイの監視からアラートを受信するメールアドレスです。

  4. /etc/mdadm.conf ファイルに変更を保存して、閉じます。

上記の手順を完了すると、監視システムは通知をメールアドレスに送信します。

関連情報

  • 詳細は、man ページの mdadm.conf 5 を参照してください。

15.11. RAID のメンテナンス

本セクションでは、RAID メンテナンスに関するさまざまな手順を説明します。

15.11.1. RAID で障害の発生したディスクの置き換え

この手順では、RAID (Redundant Array of Independent Disks) で障害のあるディスクを置き換える方法を説明します。ここでは、/dev/md0 RAID レベル 10 があるとします。このシナリオでは、/dev/sdg ディスクに問題があるため、新しいディスク /dev/sdh に置き換える必要があります。

前提条件

  • 追加のスペアディスク。
  • mdadm パッケージがインストールされている。
  • アレイ内のディスクに障害が発生していることの通知。アレイの監視を設定する場合は、「RAID の監視」を参照してください。

手順

  1. どのディスクが失敗しているかを確認してください。これを行うには、次のコマンドを実行します。

    # journalctl -k -f

    ディスクに障害が発生したことを示すメッセージが表示されます。

    md/raid:md0: Disk failure on sdg, disabling device.
    md/raid:md0: Operation continuing on 5 devices.
  2. キーボードの Ctrl+C を押して、journalctl プログラムを終了します。
  3. 新しいディスクをアレイに追加します。これを行うには、次のコマンドを実行します。

    # mdadm --manage /dev/md0 --add /dev/sdh
  4. 障害の発生したディスクに faulty のマークを付けます。これを行うには、次のコマンドを実行します。

    # mdadm --manage /dev/md0 --fail /dev/sdg
  5. 次のコマンドを実行して、障害の発生したディスクが正しくマスクされたかどうかを確認します。

    # mdadm --detail /dev/md0

    最後のコマンド出力の最後に、以下のような RAID ディスクに関する情報が表示されます。/dev/sdg ディスクには faulty があります。

        Number   Major   Minor   RaidDevice State
           0       8       16        0      active sync   /dev/sdb
           1       8       32        1      active sync   /dev/sdc
           2       8       48        2      active sync   /dev/sdd
           3       8       64        3      active sync   /dev/sde
           4       8       80        4      active sync   /dev/sdf
           6       8      112        5      active sync   /dev/sdh
    
           5       8       96        -      faulty   /dev/sdg
  6. 最後に、アレイから障害の発生したディスクを削除します。これを行うには、次のコマンドを実行します。

    # mdadm --manage /dev/md0 --remove /dev/sdg
  7. 次のコマンドを実行して RAID の詳細を確認します。

    # mdadm --detail /dev/md0

    最後のコマンドの出力の最後に、以下のような RAID ディスクに関する情報が表示されます。

        Number   Major   Minor   RaidDevice State
           0       8       16        0      active sync   /dev/sdb
           1       8       32        1      active sync   /dev/sdc
           2       8       48        2      active sync   /dev/sdd
           3       8       64        3      active sync   /dev/sde
           4       8       80        4      active sync   /dev/sdf
           6       8      112        5      active sync   /dev/sdh

上記の手順を完了すると、新しいディスク /dev/sdh で RAID /dev/md0 が実行されます。

15.11.2. アレイ内の破損したディスクの置き換え

この手順では、RAID (Redundant Array of Independent Disks) で破損したディスクを置き換える方法を説明します。ここでは、/dev/md0 RAID レベル 6 があるとします。このシナリオでは、/dev/sdb ディスクにハードウェアの問題があり、使用されなくなりました。新しいディスク /dev/sdi に置き換える必要があります。

前提条件

  • 代替となる新規ディスク。
  • mdadm パッケージがインストールされている。

手順

  1. 次のコマンドを使用してログメッセージを確認します。

    # journalctl -k -f

    ディスクに障害が発生したことを示すメッセージが表示されます。

    md/raid:md0: Disk failure on sdb, disabling device.
    md/raid:md0: Operation continuing on 5 devices.
  2. キーボードの Ctrl+C を押して、journalctl プログラムを終了します。
  3. 新規ディスクをスペアとしてアレイに追加します。これを行うには、次のコマンドを実行します。

    # mdadm --manage /dev/md0 --add /dev/sdi
  4. 破損したディスクに faulty のマークを付けます。これを行うには、次のコマンドを実行します。

    # mdadm --manage /dev/md0 --fail /dev/sdb
  5. 障害の発生したディスクをアレイから削除します。これを行うには、次のコマンドを実行します。

    # mdadm --manage /dev/md0 --remove /dev/sdb
  6. 次のコマンドを使用して、アレイのステータスを確認します。

    # mdadm --detail /dev/md0

    最後のコマンドの出力の最後に、以下のような RAID ディスクに関する情報が表示されます。

        Number   Major   Minor   RaidDevice State
           7       8      128        0      active sync   /dev/sdi
           1       8       32        1      active sync   /dev/sdc
           2       8       48        2      active sync   /dev/sdd
           3       8       64        3      active sync   /dev/sde
           4       8       80        4      active sync   /dev/sdf
           6       8      112        5      active sync   /dev/sdh

上記の手順を完了すると、新しいディスク /dev/sdi で RAID /dev/md0 が実行されます。

15.11.3. RAID ディスクの再同期

この手順では、RAID アレイでディスクを再同期する方法を説明します。ここでは、/dev/md0 RAID があるとします。

前提条件

  • mdadm パッケージがインストールされている。

手順

  1. 障害の発生したディスク動作のアレイを確認するには、次のコマンドを実行します。

    # echo check > /sys/block/md0/md/sync_action

    このアクションはアレイを確認し、結果を /sys/block/md0/md/sync_action ファイルに書き込みます。

  2. /sys/block/md0/md/sync_action ファイルを、選択したテキストエディターで開き、ディスク同期の失敗に関するメッセージがあるかどうかを確認します。
  3. アレイ内のディスクを再同期するには、次のコマンドを実行します。

    # echo repair > /sys/block/md0/md/sync_action

    このアクションは、アレイ内のディスクを再同期し、結果を /sys/block/md0/md/sync_action ファイルに書き込みます。

  4. 同期の進捗を表示するには、次のコマンドを実行します。

    # cat /proc/mdstat

第16章 LUKS を使用したブロックデバイスの暗号化

ディスクの暗号化は、それを暗号化することにより、ブロックデバイス上のデータを保護します。デバイスで復号したコンテンツにアクセスするには、パスフレーズまたは鍵を認証として提供する必要があります。これは、モバイルコンピューターや、リムーバブルメディアの場合に特に重要になります。これにより、デバイスをシステムから物理的に削除した場合でも、デバイスのコンテンツを保護するのに役立ちます。LUKS 形式は、RHEL におけるブロックデバイスの暗号化のデフォルト実装です。

16.1. LUKS ディスクの暗号化

LUKS (Linux Unified Key Setup-on-disk-format) は、ブロックデバイスを暗号化でき、暗号化したデバイスの管理を簡素化するツールセットを提供します。LUKS を使用すれば、複数のユーザー鍵が、パーティションのバルク暗号化に使用されるマスター鍵を複号できるようになります。

RHEL は、LUKS を使用してブロックデバイスの暗号化を行います。デフォルトではインストール時に、ブロックデバイスを暗号化するオプションが指定されていません。ディスクを暗号化するオプションを選択すると、コンピューターを起動するたびにパスフレーズの入力が求められます。このパスフレーズは、パーティションの複号に用いられるバルク暗号化鍵の「ロックを解除」します。デフォルトのパーティションテーブルの変更を選択すると、暗号化するパーティションを選択できます。この設定は、パーティションテーブル設定で行われます。

LUKS の機能

  • LUKS は、ブロックデバイス全体を暗号化するため、脱着可能なストレージメディアやノート PC のディスクドライブといった、モバイルデバイスのコンテンツを保護するのに適しています。
  • 暗号化されたブロックデバイスの基本的な内容は任意であり、スワップデバイスの暗号化に役立ちます。また、とりわけデータストレージ用にフォーマットしたブロックデバイスを使用する特定のデータベースに関しても有用です。
  • LUKS は、既存のデバイスマッパーのカーネルサブシステムを使用します。
  • LUKS は、パラフレーズの強化を提供し、辞書攻撃から保護します。
  • LUKS デバイスには複数のキースロットが含まれ、ユーザーはこれを使用してバックアップキーやパスフレーズを追加できます。

LUKS が 行わない こと

  • LUKS などのディスク暗号化ソリューションは、システムの停止時にしかデータを保護しません。システムの電源がオンになり、LUKS がディスクを復号すると、そのディスクのファイルは、通常、そのファイルにアクセスできるすべてのユーザーが使用できます。
  • LUKS は、多くのユーザーが、同じデバイスにアクセスする鍵をそれぞれ所有することが必要となるシナリオには適していません。LUKS1 形式は鍵スロットを 8 個提供し、LUKS2 形式は鍵スロットを最大 32 個提供します。
  • LUKS は、ファイルレベルの暗号化を必要とするアプリケーションには適していません。

暗号化

LUKS に使用されるデフォルトの暗号は aes-xts-plain64 です。LUKS のデフォルトの鍵サイズは 512 ビットです。Anaconda (XTS モード) を使用した LUKS のデフォルトの鍵サイズは 512 ビットです。利用可能な暗号は以下のとおりです。

  • AES (Advanced Encryption Standard) - FIPS PUB 197
  • Twofish (128 ビットブロック暗号)
  • Serpent

16.2. RHEL 8 の LUKS バージョン

RHEL 8 では、LUKS 暗号化のデフォルト形式は LUKS2 です。従来の LUKS1 形式は、完全にサポートされ、以前の RHEL リリースと互換性のある形式として提供されます。

LUKS2 形式は、今後も、バイナリー構造を変更することなく、さまざまな要素を更新できるように設計されています。LUKS2 は、内部的にメタデータに JSON テキスト形式を使用し、メタデータの冗長性を提供し、メタデータの破損を検出し、メタデータコピーからの自動修正を可能にします。

重要

LUKS1 にのみ対応する以前のシステムとの互換性を必要とするシステムでは、LUKS2 を使用しないでください。RHEL 7 は、バージョン 7.6 以降の LUKS2 形式に対応していることに注意してください。

警告

LUKS2 および LUKS1 は、異なるコマンドを使用してディスクを暗号化します。LUKS バージョンに誤ったコマンドを使用すると、データが失われる可能性があります。

LUKS バージョン暗号化コマンド

LUKS2

cryptsetup reencrypt

LUKS1

cryptsetup-reencrypt

オンラインの再暗号化

LUKS2 形式は、デバイスが使用中の間に、暗号化したデバイスの再暗号化に対応します。たとえば、以下のタスクを実行するにあたり、デバイスでファイルシステムをアンマウントする必要はありません。

  • ボリュームキーの変更
  • 暗号化アルゴリズムの変更

暗号化されていないデバイスを暗号化する場合は、ファイルシステムのマウントを解除する必要があります。暗号化の短い初期化後にファイルシステムを再マウントできます。

LUKS1 形式は、オンライン再暗号化に対応していません。

変換

LUKS2 形式は、LUKS1 により提供されます。特定の状況では、LUKS1 を LUKS2 に変換できます。具体的には、以下のシナリオでは変換ができません。

  • LUKS1 デバイスが、Policy-Based Decryption (PBD - Clevis) ソリューションにより使用されているとマークされている。cryptsetup ツールは、luksmeta メタデータが検出されると、そのデバイスを変換することを拒否します。
  • デバイスがアクティブになっている。デバイスが非アクティブ状態でなければ、変換することはできません。

16.3. LUKS2 再暗号化中のデータ保護のオプション

LUKS2 では、再暗号化プロセスで、パフォーマンスやデータ保護の優先度を設定する複数のオプションを選択できます。

checksum

これがデフォルトのモードです。データ保護とパフォーマンスのバランスを取ります。

このモードは、セクターの個々のチェックサムを再暗号化領域に保存するため、復旧プロセスでは、LUKS2 がすでに再暗号化しているセクターを検出できます。このモードでは、ブロックデバイスセクターの書き込みがアトミックである必要があります。

journal
このモードが最も安全ですが、最も遅くなります。このモードは、バイナリー領域の再暗号化領域をジャーナル化するため、LUKS2 はデータを 2 回書き込みます。
none
このモードはパフォーマンスを優先し、データ保護は提供しません。これは、SIGTERM シグナルや、Ctrl+C を押すユーザーなど、安全なプロセス終了からのみデータを保護します。予期しないシステムクラッシュやアプリケーションのクラッシュが発生すると、データが破損する可能性があります。

cryptsetup--resilience オプションを使用してモードを選択できます。

LUKS2 の再暗号化プロセスが強制的に突然終了した場合、LUKS2 は以下のいずれかの方法で復旧を実行できます。

  • 自動的に実行 (LUKS2 デバイスの次回のオープン動作時)。この動作は、cryptsetup open コマンドまたは systemd-cryptsetup でデバイスを割り当てると発生します。
  • LUKS2 デバイスで cryptsetup repair コマンドを使用して手動で実行。

16.4. LUKS2 を使用したブロックデバイスの既存データの暗号化

この手順では、LUKS2 形式を使用して、暗号化されていないデバイスの既存データを暗号化します。新しい LUKS ヘッダーは、デバイスのヘッドに保存されます。

前提条件

  • ブロックデバイスにファイルシステムが含まれている。
  • データのバックアップを作成している。

    警告

    ハードウェア、カーネル、または人的ミスにより、暗号化プロセス時にデータが失われる場合があります。データの暗号化を開始する前に、信頼性の高いバックアップを作成してください。

手順

  1. 暗号化するデバイスにあるファイルシステムのマウントをすべて解除します。以下に例を示します。

    # umount /dev/sdb1
  2. LUKS ヘッダーを保存するための空き容量を確認します。以下のいずれかのオプションを選択します。

    • 論理ボリュームを暗号化する場合は、以下のように、ファイルシステムのサイズを変更せずに、論理ボリュームを拡張できます。以下に例を示します。

      # lvextend -L+32M vg00/lv00
    • parted などのパーティション管理ツールを使用してパーティションを拡張します。
    • このデバイスのファイルシステムを縮小します。ext2、ext3、または ext4 のファイルシステムには resize2fs ユーティリティーを使用できます。XFS ファイルシステムは縮小できないことに注意してください。
  3. 暗号化を初期化します。以下に例を示します。

    # cryptsetup reencrypt \
                 --encrypt \
                 --init-only \
                 --reduce-device-size 32M \
                 /dev/sdb1 sdb1_encrypted

    このコマンドを実行するとパスフレーズの入力が求められ、暗号化プロセスが開始します。

  4. デバイスをマウントします。

    # mount /dev/mapper/sdb1_encrypted /mnt/sdb1_encrypted
  5. オンライン暗号化を開始します。

    # cryptsetup reencrypt --resume-only /dev/sdb1

関連情報

  • 詳細は、man ページの cryptsetup(8)lvextend(8)resize2fs(8)、および parted(8) を参照してください

16.5. 独立したヘッダーがある LUKS2 を使用してブロックデバイスの既存データの暗号化

この手順では、LUKS ヘッダーを保存するための空き領域を作成せずに、ブロックデバイスの既存データを暗号化します。ヘッダーは、追加のセキュリティー層としても使用できる、独立した場所に保存されます。この手順では、LUKS2 暗号化形式を使用します。

前提条件

  • ブロックデバイスにファイルシステムが含まれている。
  • データのバックアップを作成している。

    警告

    ハードウェア、カーネル、または人的ミスにより、暗号化プロセス時にデータが失われる場合があります。データの暗号化を開始する前に、信頼性の高いバックアップを作成してください。

手順

  1. プールにあるファイルシステムのマウントをすべて解除します。以下に例を示します。

    # umount /dev/sdb1
  2. 暗号化を初期化します。

    # cryptsetup reencrypt \
                 --encrypt \
                 --init-only \
                 --header /path/to/header \
                 /dev/sdb1 sdb1_encrypted

    /path/to/header を、独立した LUKS ヘッダーのあるファイルへのパスに置き換えます。暗号化したデバイスを後でアンロックできるように、接続解除した LUKS ヘッダーにアクセスできる必要があります。

    このコマンドを実行するとパスフレーズの入力が求められ、暗号化プロセスが開始します。

  3. デバイスをマウントします。

    # mount /dev/mapper/sdb1_encrypted /mnt/sdb1_encrypted
  4. オンライン暗号化を開始します。

    # cryptsetup reencrypt --resume-only --header /path/to/header /dev/sdb1

関連情報

  • 詳細は、man ページの cryptsetup(8) を参照してください。

第17章 Stratis で階層化ローカルストレージの管理

Stratis の高レベルシステムに統合されている複雑なストレージ設定を簡単に設定および管理できます。

重要

Straits がテクノロジープレビューとして利用可能にテクノロジープレビュー機能に対する Red Hat のサポート範囲の詳細は、「テクノロジプレビュー機能のサポート範囲」を参照してください。

Stratis をデプロイしているお客様は、Red Hat にフィードバックをお寄せください。

17.1. Stratis ファイルシステムの設定

システム管理者は、Stratis ボリューム管理ファイルシステムをシステム上で有効にしてセットアップし、階層化ストレージを簡単に管理できます。

17.1.1. Stratis の目的と機能

Stratis は、Linux 用のローカルストレージ管理ソリューションです。これは、シンプルさと使いやすさに力を入れており、高度なストレージ機能にアクセスできます。

Stratis を使用すると、以下の活動をより簡単に行うことができます。

  • ストレージの初期設定
  • その後の変更
  • 高度なストレージ機能の使用

Stratis は、高度なストレージ機能に対応する、ユーザーとカーネルのハイブリッドローカルストレージ管理システムです。Stratis は、ストレージ プール の概念を中心としています。このプールは 1 つ以上のローカルディスクまたはパーティションから作成され、ボリュームはプールから作成されます。

プールにより、次のような多くの便利な機能を使用できます。

  • ファイルシステムのスナップショット
  • シンプロビジョニング
  • 階層化

17.1.2. Stratis ボリュームの構成要素

外部的には、Stratis は、コマンドラインインターフェースおよび API に次のボリュームコンポーネントを表示します。

blockdev
ディスクやディスクパーティションなどのブロックデバイス。
pool

1 つ以上のブロックデバイスで構成されています。

プールの合計サイズは固定で、ブロックデバイスのサイズと同じです。

プールには、dm-cache ターゲットを使用した不揮発性データキャッシュなど、ほとんどの Stratis レイヤーが含まれています。

Stratis は、各プールの /stratis/my-pool/ ディレクトリーを作成します。このディレクトリーには、プール内の Stratis ファイルシステムを表すデバイスへのリンクが含まれています。

filesystem

各プールには、ファイルを格納する 1 つ以上のファイルシステムを含めることができます。

ファイルシステムはシンプロビジョニングされており、合計サイズは固定されていません。ファイルシステムの実際のサイズは、そこに格納されているデータとともに大きくなります。データのサイズがファイルシステムの仮想サイズに近づくと、Stratis はシンボリュームとファイルシステムを自動的に拡張します。

ファイルシステムは XFS でフォーマットされています。

重要

Stratis は、Stratis を使用して作成したファイルシステムに関する情報を追跡し、XFS はそれを認識しません。また、XFS を使用して変更を行っても、自動的に Stratisに更新を作成しません。ユーザーは、Stratis が管理する XFS ファイルシステムを再フォーマットまたは再構成しないでください。

Stratis は、パスが /stratis/my-pool/my-fs のファイルシステムへのリンクを作成します。

注記

Stratis は、dmsetup リストと /proc/partitions ファイルに表示される多くの Device Mapper デバイスを使用します。同様に、lsblk コマンドの出力は、Stratis の内部の仕組みとレイヤーを反映します。

17.1.3. Stratis で使用可能なブロックデバイス

本セクションでは、Stratis に使用できるストレージデバイスを一覧で紹介します。

対応デバイス

Stratis プールは、次の種類のブロックデバイスで動作するかどうかをテスト済みです。

  • LUKS
  • LVM 論理ボリューム
  • MD RAID
  • DM Multipath
  • iSCSI
  • HDD および SSD
  • NVMe デバイス
警告

Stratis は、現行バージョンでは、ハードドライブまたはその他のハードウェアの不具合に対応しません。複数のハードウェアデバイスに Stratis プールを作成すると、データにアクセスするために複数のデバイスが動作状態になっているため、データを損失するリスクが高まります。

対応していないデバイス

Stratis にはシンプロビジョニングレイヤーが含まれているため、Red Hat はすでにシンプロビジョニングされているブロックデバイスに Stratis プールを配置することを推奨しません。

関連情報

  • iSCSI や、ネットワークを必要とするその他のブロックデバイスの _netdev マウントオプションに関する情報は、man ページの systemd.mount(5) を参照してください。

17.1.4. Stratis のインストール

この手順では、Stratis の使用に必要なパッケージをすべてインストールします。

手順

  1. Stratis サービスとコマンドラインユーティリティーを提供するパッケージをインストールします。

    # yum install stratisd stratis-cli
  2. stratisd サービスが有効になっていることを確認してください。

    # systemctl enable --now stratisd

17.1.5. Stratis プールの作成

この手順では、1 つ以上のブロックデバイスから Stratis プールを作成します。

前提条件

  • Stratis がインストールされている。「Stratis のインストール」を参照してください。
  • stratisd サービスが実行している。
  • Stratis プールを作成するブロックデバイスは使用されておらず、マウントされていない。
  • Stratis プールを作成するブロックデバイスが、それぞれ 1 GiB 以上である。
  • IBM Z アーキテクチャーでは、/dev/dasd* ブロックデバイスをパーティションに分割している。Stratis プールでパーティションを使用します。

    DASD デバイスのパーティション設定には、「IBM Z への Linux インスタンスの設定」を参照してください。

手順

  1. 選択したブロックデバイスにファイルシステム、パーティションテーブル、または RAID 署名が含まれている場合は消去します。

    # wipefs --all block-device

    block-device を、ブロックデバイスへのパス (例: /dev/sdb) に置き換えます。

  2. ブロックデバイスに Stratis プールを作成するには、次のコマンドを実行します。

    # stratis pool create my-pool block-device
    • my-pool を、プールの任意の名前に置き換えます。
    • block-device を、空または消去したブロックデバイスへのパス (例: /dev/sdb) に置き換えます。

    複数のブロックデバイスからプールを作成するには、すべてのブロックデバイスをコマンドラインに追加します。

    # stratis pool create my-pool device-1 device-2 device-n
  3. 確認のために、システムにあるプールを一覧表示します。

    # stratis pool list

関連情報

  • man ページの stratis(8)

次のステップ

17.1.6. Stratis ファイルシステムの作成

この手順では、既存の Stratis プールに Stratis ファイルシステムを作成します。

前提条件

手順

  1. Stratis ファイルシステムをプールに作成するには、次のコマンドを実行します。

    # stratis fs create my-pool my-fs
    • my-pool を、既存の Stratis プールの名前に置き換えます。
    • my-fs を、ファイルシステムの任意の名前に置き換えます。
  2. 確認のために、プールにあるファイルシステムの一覧を表示します。

    # stratis fs list my-pool

関連情報

  • man ページの stratis(8)

次のステップ

17.1.7. Stratis ファイルシステムのマウント

この手順では、コンテンツにアクセスするために既存の Stratis ファイルシステムをマウントします。

前提条件

手順

  • ファイルシステムをマウントするには、/stratis/ ディレクトリーで Stratis が維持するエントリーを使用します。

    # mount /stratis/my-pool/my-fs mount-point

これでファイルシステムは mount-point ディレクトリーにマウントされ、使用できるようになりました。

関連情報

  • man ページの mount(8)

17.1.8. Stratis ファイルシステムを永続的に維持

この手順では、Stratis ファイルシステムを永続的にマウントして、システムが起動した後に自動的に利用できるようにします。

前提条件

手順

  1. ファイルシステムの UUID 属性を調べます。

    $ lsblk --output=UUID /stratis/my-pool/my-fs

    以下に例を示します。

    例17.1 Stratis ファイルシステムの UUID の表示

    $ lsblk --output=UUID /stratis/my-pool/fs1
    
    UUID
    a1f0b64a-4ebb-4d4e-9543-b1d79f600283
  2. このマウントポイントのディレクトリーがない場合は、作成します。

    # mkdir --parents mount-point
  3. root で /etc/fstab ファイルを編集し、ファイルシステムに行を追加します (UUID で識別されます)。xfs をファイルシステムのタイプとして使用し、x-systemd.requires=stratisd.service オプションを追加します。

    以下に例を示します。

    例17.2 /etc/fstab の /fs1 マウントポイント

    UUID=a1f0b64a-4ebb-4d4e-9543-b1d79f600283 /fs1 xfs defaults,x-systemd.requires=stratisd.service 0 0
  4. システムが新しい設定を登録するように、マウントユニットを再生成します。

    # systemctl daemon-reload
  5. ファイルシステムをマウントして、設定が機能することを確認します。

    # mount mount-point

17.2. 追加のブロックデバイスで Stratis ボリュームの拡張

Stratis ファイルシステムのストレージ容量を増やすために、追加のブロックデバイスを Stratis プールに追加できます。

17.2.1. Stratis ボリュームの構成要素

外部的には、Stratis は、コマンドラインインターフェースおよび API に次のボリュームコンポーネントを表示します。

blockdev
ディスクやディスクパーティションなどのブロックデバイス。
pool

1 つ以上のブロックデバイスで構成されています。

プールの合計サイズは固定で、ブロックデバイスのサイズと同じです。

プールには、dm-cache ターゲットを使用した不揮発性データキャッシュなど、ほとんどの Stratis レイヤーが含まれています。

Stratis は、各プールの /stratis/my-pool/ ディレクトリーを作成します。このディレクトリーには、プール内の Stratis ファイルシステムを表すデバイスへのリンクが含まれています。

filesystem

各プールには、ファイルを格納する 1 つ以上のファイルシステムを含めることができます。

ファイルシステムはシンプロビジョニングされており、合計サイズは固定されていません。ファイルシステムの実際のサイズは、そこに格納されているデータとともに大きくなります。データのサイズがファイルシステムの仮想サイズに近づくと、Stratis はシンボリュームとファイルシステムを自動的に拡張します。

ファイルシステムは XFS でフォーマットされています。

重要

Stratis は、Stratis を使用して作成したファイルシステムに関する情報を追跡し、XFS はそれを認識しません。また、XFS を使用して変更を行っても、自動的に Stratisに更新を作成しません。ユーザーは、Stratis が管理する XFS ファイルシステムを再フォーマットまたは再構成しないでください。

Stratis は、パスが /stratis/my-pool/my-fs のファイルシステムへのリンクを作成します。

注記

Stratis は、dmsetup リストと /proc/partitions ファイルに表示される多くの Device Mapper デバイスを使用します。同様に、lsblk コマンドの出力は、Stratis の内部の仕組みとレイヤーを反映します。

17.2.2. Stratis プールへのブロックデバイスの追加

この手順では、Stratis ファイルシステムで使用できるように、1 つ以上のブロックデバイスを Stratis プールに追加します。

前提条件

  • Stratis がインストールされている。「Stratis のインストール」を参照してください。
  • stratisd サービスが実行している。
  • Stratis プールに追加するブロックデバイスは使用されておらず、マウントされていない。
  • Stratis プールに追加するブロックデバイスは使用されておらず、それぞれ 1 GiB 以上である。

手順

  • 1 つ以上のブロックデバイスをプールに追加するには、以下を使用します。

    # stratis pool add-data my-pool device-1 device-2 device-n

関連情報

  • man ページの stratis(8)

17.3. Stratis ファイルシステムの監視

Stratis ユーザーは、システムにある Stratis ボリュームに関する情報を表示して、その状態と空き容量を監視できます。

17.3.1. さまざまなユーティリティーが報告する Stratis のサイズ

本セクションでは、df などの標準的なユーティリティーと、stratis ユーティリティーにより報告される Stratis サイズの相違点を説明します。

df などの標準的な Linux ユーティリティーは、Stratis 上の 1TiB の XFS ファイルシステムレイヤーのサイズを報告します。これは 1 TiB です。Stratis の実際のストレージ使用量は、シンプロビジョニングにより少なくなっており、また XFS レイヤーが満杯に近くなると Stratis が自動的にファイルシステムを拡張するため、これは特に有用な情報ではありません。

重要

Stratis ファイルシステムに書き込まれているデータ量を定期的に監視します。これは Total Physical Used の値として報告されます。これが Total Physical Size の値を超えていないことを確認してください。

関連情報

  • man ページの stratis(8)

17.3.2. Stratis ボリュームの情報表示

この手順では、Stratis ボリュームに関する合計サイズ、使用済みサイズ、空きサイズ、ファイルシステム、プールに属するブロックデバイスなどの統計情報を一覧表示します。

前提条件

手順

  • システムで Stratis に使用されているすべての ブロックデバイス に関する情報を表示する場合は、次のコマンドを実行します。

    # stratis blockdev
    
    Pool Name  Device Node    Physical Size   State  Tier
    my-pool    /dev/sdb            9.10 TiB  In-use  Data
  • システムにあるすべての Stratis プール に関する情報を表示するには、次のコマンドを実行します。

    # stratis pool
    
    Name    Total Physical Size  Total Physical Used
    my-pool            9.10 TiB              598 MiB
  • システムにあるすべての Stratis ファイルシステム に関する情報を表示するには、次のコマンドを実行します。

    # stratis filesystem
    
    Pool Name  Name  Used     Created            Device
    my-pool    my-fs 546 MiB  Nov 08 2018 08:03  /stratis/my-pool/my-fs

関連情報

  • man ページの stratis(8)

17.4. Stratis ファイルシステムでのスナップショットの使用

Stratis ファイルシステムのスナップショットを使用して、ファイルシステムの状態を任意の時点でキャプチャーし、後でそれを復元できます。

17.4.1. Stratis スナップショットの特徴

本セクションでは、Stratis ファイルシステムのスナップショットのプロパティーと制限事項を説明します。

Stratis では、スナップショットは、別の Stratis ファイルシステムのコピーとして作成した通常の Stratis ファイルシステムです。スナップショットには、元のファイルシステムと同じファイルの内容が含まれていますが、スナップショットが変更するときにファイル内容が変更する可能性があります。スナップショットにどんな変更を加えても、元のファイルシステムには反映されません。

Stratis の現在のスナップショット実装は、次のような特徴があります。

  • ファイルシステムのスナップショットは別のファイルシステムです。
  • スナップショットと元のファイルシステムのリンクは、有効期間中は行われません。スナップショットされたファイルシステムは、元のファイルシステムよりも長く存続します。
  • スナップショットを作成するためにファイルシステムをマウントする必要はありません。
  • 各スナップショットは、XFS ログに必要となる実際のバッキングストレージの約半分のギガバイトを使用します。

17.4.2. Stratis スナップショットの作成

この手順では、既存の Stratis ファイルシステムのスナップショットとして Stratis ファイルシステムを作成します。

前提条件

手順

  • Stratis スナップショットを作成するには、次のコマンドを実行します。

    # stratis fs snapshot my-pool my-fs my-fs-snapshot

関連情報

  • man ページの stratis(8)

17.4.3. Stratis スナップショットのコンテンツへのアクセス

この手順では、Stratis ファイルシステムのスナップショットをマウントして、読み書き操作にアクセスできるようにします。

前提条件

手順

  • スナップショットにアクセスするには、/stratis/my-pool/ ディレクトリーから通常のファイルシステムとしてマウントします。

    # mount /stratis/my-pool/my-fs-snapshot mount-point

関連情報

17.4.4. Stratis ファイルシステムを以前のスナップショットに戻す

この手順では、Stratis ファイルシステムの内容を、Stratis スナップショットでキャプチャーされた状態に戻します。

前提条件

手順

  1. 必要に応じて、後でそれにアクセスできるように、ファイルシステムの現在の状態のバックアップを作成します。

    # stratis filesystem snapshot my-pool my-fs my-fs-backup
  2. 元のファイルシステムをアンマウントして削除します。

    # umount /stratis/my-pool/my-fs
    # stratis filesystem destroy my-pool my-fs
  3. 元のファイルシステムの名前でスナップショットのコピーを作成します。

    # stratis filesystem snapshot my-pool my-fs-snapshot my-fs
  4. 元のファイルシステムと同じ名前でアクセスできるようになったスナップショットをマウントします。

    # mount /stratis/my-pool/my-fs mount-point

my-fs という名前のファイルシステムの内容は、スナップショット my-fs-snapshot と同じになりました。

関連情報

  • man ページの stratis(8)

17.4.5. Stratis スナップショットの削除

この手順では、Stratis スナップショットをプールから削除します。スナップショットのデータは失われます。

前提条件

手順

  1. スナップショットをアンマウントします。

    # umount /stratis/my-pool/my-fs-snapshot
  2. スナップショットを破棄します。

    # stratis filesystem destroy my-pool my-fs-snapshot

関連情報

  • man ページの stratis(8)

17.5. Stratis ファイルシステムの削除

既存の Stratis ファイルシステム、または Stratis プールを削除して、そこに含まれるデータを破棄できます。

17.5.1. Stratis ボリュームの構成要素

外部的には、Stratis は、コマンドラインインターフェースおよび API に次のボリュームコンポーネントを表示します。

blockdev
ディスクやディスクパーティションなどのブロックデバイス。
pool

1 つ以上のブロックデバイスで構成されています。

プールの合計サイズは固定で、ブロックデバイスのサイズと同じです。

プールには、dm-cache ターゲットを使用した不揮発性データキャッシュなど、ほとんどの Stratis レイヤーが含まれています。

Stratis は、各プールの /stratis/my-pool/ ディレクトリーを作成します。このディレクトリーには、プール内の Stratis ファイルシステムを表すデバイスへのリンクが含まれています。

filesystem

各プールには、ファイルを格納する 1 つ以上のファイルシステムを含めることができます。

ファイルシステムはシンプロビジョニングされており、合計サイズは固定されていません。ファイルシステムの実際のサイズは、そこに格納されているデータとともに大きくなります。データのサイズがファイルシステムの仮想サイズに近づくと、Stratis はシンボリュームとファイルシステムを自動的に拡張します。

ファイルシステムは XFS でフォーマットされています。

重要

Stratis は、Stratis を使用して作成したファイルシステムに関する情報を追跡し、XFS はそれを認識しません。また、XFS を使用して変更を行っても、自動的に Stratisに更新を作成しません。ユーザーは、Stratis が管理する XFS ファイルシステムを再フォーマットまたは再構成しないでください。

Stratis は、パスが /stratis/my-pool/my-fs のファイルシステムへのリンクを作成します。

注記

Stratis は、dmsetup リストと /proc/partitions ファイルに表示される多くの Device Mapper デバイスを使用します。同様に、lsblk コマンドの出力は、Stratis の内部の仕組みとレイヤーを反映します。

17.5.2. Stratis ファイルシステムの削除

この手順では、既存の Stratis ファイルシステムを削除します。そこに保存されているデータは失われます。

前提条件

手順

  1. ファイルシステムをアンマウントします。

    # umount /stratis/my-pool/my-fs
  2. ファイルシステムを破棄します。

    # stratis filesystem destroy my-pool my-fs
  3. ファイルシステムがもう存在しないことを確認します。

    # stratis filesystem list my-pool

関連情報

  • man ページの stratis(8)

17.5.3. Stratis プールの削除

この手順では、既存の Stratis プールを削除します。そこに保存されているデータは失われます。

前提条件

手順

  1. プールにあるファイルシステムの一覧を表示します。

    # stratis filesystem list my-pool
  2. プール上のすべてのファイルシステムをアンマウントします。

    # umount /stratis/my-pool/my-fs-1 \
             /stratis/my-pool/my-fs-2 \
             /stratis/my-pool/my-fs-n
  3. ファイルシステムを破棄します。

    # stratis filesystem destroy my-pool my-fs-1 my-fs-2
  4. プールを破棄します。

    # stratis pool destroy my-pool
  5. プールがなくなったことを確認します。

    # stratis pool list

関連情報

  • man ページの stratis(8)

法律上の通知

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.

このページには機械翻訳が使用されている場合があります (詳細はこちら)。