19.2. ブリック設定

以下の設定を使用してブリックをフォーマットし、パフォーマンスを向上させる。

手順19.1 ブリック設定

  1. LVM レイヤー

    物理デバイスからブリックを作成する手順を以下に示します。物理デバイスで複数のブリックを作成する手順の概要を「『例: 以下の物理デバイスに複数のブリックを作成する』」を参照してください。
    • 物理ボリュームの作成
      pvcreate コマンドは、物理ボリュームの作成に使用されます。論理ボリュームマネージャーは、残りのデータをデータ部分として使用する一方で、その物理ボリュームの一部を使用できます。物理ボリュームの作成時に --dataalignment オプションを使用して、論理ボリュームマネージャー (LVM) 層で I/O を調整します。
      コマンドは、以下の形式で使用されます。
      # pvcreate --dataalignment alignment_value disk
      JBOD の場合は、256K の調整の値を使用します。
      ハードウェア RAID の場合は、RAID ストライプユニットのサイズをデータディスクの数で乗算して、調整値を取得する必要があります。RAID 6 設定で 12 個のディスクを使用すると、データディスクの数は 10 になります。その一方で、RAID 10 設定に 12 個ディスクを使用する場合は、データディスクの数は 6 になります。
      たとえば、以下のコマンドは、ストライプユニットサイズが 128 KiB の RAID 6 設定の 12 個のディスクに適しています。
      # pvcreate --dataalignment 1280k disk
      以下のコマンドは、ストライプユニットサイズが 256 KiB の RAID 10 設定の 12 個のディスクに適しています。
      # pvcreate --dataalignment 1536k disk
      --dataalignment に以前に設定した物理ボリューム設定を表示するには、以下のコマンドを実行します。
      # pvs -o +pe_start /dev/sdb
        PV         VG   Fmt  Attr PSize PFree 1st PE
        /dev/sdb        lvm2 a--  9.09t 9.09t   1.25m
    • ボリュームグループの作成
      ボリュームグループは、vgcreate コマンドを使用して作成されます。
      ハードウェア RAID では、ボリュームグループで作成した論理ボリュームが基礎となる RAID ジオメトリーに合わせて確認するには、-- pysicalextentsize オプションを指定することが重要です。以下の形式で vgcreate コマンドを実行します。
      # vgcreate --physicalextentsize extent_size VOLGROUP physical_volume
      extent_size は、RAID ストライプユニットのサイズをデータディスクの数で乗算して取得する必要があります。RAID 6 設定で 12 個のディスクを使用すると、データディスクの数は 10 になります。その一方で、RAID 10 設定に 12 個ディスクを使用する場合は、データディスクの数は 6 になります。
      たとえば、ストライプユニットサイズが 128 KB で、12 のディスク (10 データディスク) で、RAID-6 ストレージに以下のコマンドを実行します。
      # vgcreate --physicalextentsize 1280k VOLGROUP physical_volume
      JBOD の場合は、以下の形式で vgcreate コマンドを使用します。
      # vgcreate VOLGROUP physical_volume
    • シンプールの作成
      シンプールは、シン論理ボリューム (LV) とそのスナップショットボリューム (存在する場合) 用のストレージの共通のプールを提供します。
      以下のコマンドを実行して、特定のサイズのシンプールを作成します。
      # lvcreate --thin VOLGROUP/POOLNAME --size POOLSIZE --chunksize CHUNKSIZE --poolmetadatasize METASIZE --zero n
      以下のコマンドを実行して、デバイスの最大サイズのシンプールを作成することもできます。
      # lvcreate --thin VOLGROUP/POOLNAME --extents 100%FREE --chunksize CHUNKSIZE --poolmetadatasize METASIZE --zero n

      シンプール作成で推奨されるパラメーター値

      poolmetadatasize
      内部的には、シンプールには、シン LV およびスナップショットの (動的) 割り当てた領域を追跡するために使用される個別のメタデータデバイスが含まれています。上記のコマンドの poolmetadatasize オプションは、プールメタデータデバイスのサイズを示しています。
      メタデータ LV の最大許容サイズは 16 GiB です。Red Hat Gluster Storage は、サポートされている最大サイズのメタデータデバイスを作成することを推奨します。領域が懸念される場合は、最大数未満を割り当てることができますが、この場合はプールサイズの最小 0.5% を割り当てる必要があります。
      警告
      メタデータプールの容量が不足すると、データを作成できません。これには、メタデータプールのサイズを増やすか、メタデータ領域が不足しているボリュームからデータを移行するために必要なデータが含まれます。lvs -o+metadata_percent コマンドを使用してメタデータプールを監視し、領域が不足しないようにします。
      chunksize
      シンプールの作成時に指定する重要なパラメーターはチャンクサイズです。これは、割り当て単位です。優れたパフォーマンスを得るには、シンプールのチャンクサイズと、ベースとなるハードウェア RAID ストレージのパラメーターを選択し、連携するようにする必要があります。
      JBOD には、シンプールチャンクサイズ 256 KiB を使用します。
      RAID 6 ストレージでは、ストライプサイズ (stripe_unit サイズ * データディスク数 * データディスク数) が 1 MiB から 2 MiB までの値になるよう、ストライピングパラメーターを選択する必要があります。RAID 6 の完全なストライプサイズと一致するように、シンプールチャンクサイズを選択する必要があります。チャンクサイズを完全なストライプサイズに一致させると、シンプールの割り当てが RAID 6 のストライプと調整されるため、パフォーマンスが向上します。チャンクサイズを 2 MiB 未満に制限すると、スナップショットが使用される場合に過剰なコピーオン書き込みが行われるため、パフォーマンスの問題が発生する可能性が低減します。
      たとえば、ディスクが 12 個 (10 データディスク) ある RAID 6 の場合は、ストライプユニットサイズを 128 KiB として選択する必要があります。これにより、1280 KiB (1.25 MiB) のストライプサイズになります。次に、シンプールは、チャンクサイズ 1280 KiB で作成する必要があります。
      RAID 10 ストレージでは、推奨されるストライプユニットサイズは 256 KiB です。これは、シンプールのチャンクサイズとしても機能します。ワークロードでファイル書き込みまたは無作為な書き込みが使用される場合は、RAID 10 が推奨されます。この場合、スナップショットでコピーオンライトのオーバーヘッドを減らすため、シンプールのチャンクサイズはより適しています。
      デバイスのアドレス可能なストレージがデバイス自体よりも小さい場合は、推奨されるチャンクサイズを調整する必要があります。次の式を使用して調整係数を計算します。
      adjustment_factor = device_size_in_tb / (preferred_chunk_size_in_kb * 4 / 64 )
      調整係数を丸めます。次に、以下のコマンドを使用して新しいチャンクサイズを計算します。
      chunk_size = preferred_chunk_size * rounded_adjustment_factor
      ブロックのゼロ設定
      デフォルトでは、異なるブロックデバイス間のデータ漏えいを防ぐために、シンプールで新たにプロビジョニングされたチャンクはゼロになります。ファイルシステムでデータにアクセスしている Red Hat Gluster Storage の場合、--zero n オプションでパフォーマンスを向上させるために、このオプションをオフにすることができます。n を置き換える必要がないことに注意してください。
      以下の例は、シンプールを作成する方法を示しています。
      # lvcreate --thin VOLGROUP/thin_pool --size 2T --chunksize 1280k --poolmetadatasize 16G --zero n
      --extents 100%FREE を使用して、メタデータプールの作成後にシンプールが利用可能な領域をすべて取得するようにすることもできます。
      # lvcreate --thin VOLGROUP/thin_pool --extents 100%FREE --chunksize 1280k --poolmetadatasize 16G --zero n
      以下の例は、2 TB シンプールを作成する方法を示しています。
      # lvcreate --thin VOLGROUP/thin_pool --size 2T --chunksize 1280k --poolmetadatasize 16G --zero n
      以下の例では、メタデータプールの作成後に残りの領域をすべて使用するシンプールを作成します。
      # lvcreate --thin VOLGROUP/thin_pool --extents 100%FREE --chunksize 1280k --poolmetadatasize 16G --zero n
    • シン論理ボリュームの作成
      上記のようにシンプールを作成したら、シンプールにシンプロビジョニングされた論理ボリュームを作成し、Red Hat Gluster Storage ボリュームのブリック用のストレージとして機能します。
      # lvcreate --thin --name LV_name --virtualsize LV_size VOLGROUP/thin_pool
    • 例: 物理デバイスに複数のブリックを作成する
      上記のステップ (LVM レイヤー) は、物理デバイスに単一のブリックが作成されるケースを説明します。この例は、物理デバイスに複数のブリックを作成する必要がある場合に、この手順を調整する方法を示しています。
      注記
      以下の手順で、以下を前提としています。
      • 同じ物理デバイスに 2 つのブリックを作成する必要があります。
      • 1 つのブリックのサイズは 4 TiB で、もう 1 つは 2 TiB です。
      • デバイスは /dev/sdb で、12 ディスクを持つ RAID-6 デバイスです。
      • 12 ディスクの RAID-6 デバイスが、本章の推奨事項に従って作成されました。つまり、ストライプユニットサイズが 128 KiB になります。
      1. pvcreate を使用した 1 つの物理ボリュームの作成
        # pvcreate --dataalignment 1280k /dev/sdb
      2. デバイスに 1 つのボリュームグループを作成します。
        # vgcreate --physicalextentsize 1280k vg1 /dev/sdb
      3. 以下のコマンドを使用して、ブリックごとに個別のシンプールを作成します。
        # lvcreate --thin vg1/thin_pool_1 --size 4T --chunksize 1280K --poolmetadatasize 16G --zero n
        # lvcreate --thin vg1/thin_pool_2 --size 2T --chunksize 1280K --poolmetadatasize 16G --zero n
        上記の例では、各シンプールのサイズは、そのサイズで作成されたブリックのサイズと同じになるよう選択されます。シンプロビジョニングでは、スペースを管理する方法が多数あり、本章ではこれらのオプションについては説明していません。
      4. 各ブリック用にシン論理ボリュームを作成する
        # lvcreate --thin --name lv1 --virtualsize 4T vg1/thin_pool_1
        # lvcreate --thin --name lv2 --virtualsize 2T vg1/thin_pool_2
      5. 本章の 『XFS Recommendations』 (次のステップ) に従って、各シン論理ボリュームにファイルシステムを作成してマウントします。
        # mkfs.xfs options /dev/vg1/lv1
        # mkfs.xfs options /dev/vg1/lv2
        # mount options /dev/vg1/lv1 mount_point_1
        # mount options /dev/vg1/lv2 mount_point_2
  2. XFS の推奨事項

    • XFS Inode サイズ
      Red Hat Gluster Storage は拡張属性を多用するので、512 バイトの XFS inode サイズは、デフォルトの XFS inode サイズ 256 バイトよりも適切に機能します。したがって、Red Hat Gluster Storage ブリックをフォーマットする際に、XFS の inode サイズは 512 バイトに設定する必要があります。inode サイズを設定するには、以下の 『Logical Block Size for the Directory』 ディレクトリーの論理ブロックサイズセクションに示されるように、mkfs.xfs コマンドで -i size オプションを使用する必要があ ます。
    • XFS RAID アライメント
      XFS ファイルシステムを作成する場合は、以下の形式で、基礎となるストレージのストライピングパラメーターを明示的に指定できます。
      # mkfs.xfs other_options -d su=stripe_unit_size,sw=stripe_width_in_number_of_disks device
      RAID 6 の場合は、ストライピングパラメーターを指定して、I/O がファイルシステムレイヤーに置かれていることを確認します。ディスクが 12 個ある RAID 6 ストレージの場合は、上記の推奨事項に従う必要があります。
      # mkfs.xfs other_options -d su=128k,sw=10 device
      RAID 10 および JBOD の場合、-d su=<>,sw=<> オプションは省略できます。デフォルトでは、XFS はシン p チャンクサイズおよびその他のパラメーターを使用してレイアウトの決定を行います。
    • ディレクトリーの論理ブロックサイズ
      XFS ファイルシステムでは、ファイルシステムの論理ブロックサイズよりも大きいファイルシステムのディレクトリーの論理ブロックサイズを選択できます。デフォルトの 4 K からディレクトリーの論理ブロックサイズを増やすと、ディレクトリー I/O が減少し、ディレクトリー操作のパフォーマンスが改善されます。ブロックサイズを設定するには、以下の出力例のように、-n size コマンドで mkfs.xfs オプションを使用する必要があります。
      以下は、inode およびブロックサイズのオプションに加えて、RAID 6 設定の出力例です。
      # mkfs.xfs -f -i size=512 -n size=8192 -d su=128k,sw=10 logical volume
      meta-data=/dev/mapper/gluster-brick1 isize=512    agcount=32, agsize=37748736 blks
               =    sectsz=512   attr=2, projid32bit=0
      data     =     bsize=4096   blocks=1207959552, imaxpct=5
               =    sunit=32     swidth=320 blks
      naming   = version 2   bsize=8192   ascii-ci=0
      log      =internal log   bsize=4096   blocks=521728, version=2
               =    sectsz=512   sunit=32 blks, lazy-count=1
      realtime =none    extsz=4096   blocks=0, rtextents=0
    • 割り当てストラテジー
      inode32 および inode64 は、XFS の一般的な割り当てストラテジーです。inode32 割り当てストラテジーを使用すると、XFS はすべての inode をディスクの最初の 1 TiB に配置します。ディスクが大きい場合、すべての inode は最初の 1 TiB で停止します。inode32 の割り当てストラテジーはデフォルトで使用されます。
      inode64 マウントオプションでは、inode は、ディスクシークを最小限に抑えるデータ付近に置き換わります。
      ファイルシステムのマウント時に割り当てストラテジーを inode64 に設定するには、以下の Access Time セクションに示されるように、mount コマンドで -o inode64 オプションを使用する必要があります。
    • Access Time
      アプリケーションがファイルのアクセス時間を更新する必要がない場合は、ファイルシステムを常に noatime マウントオプションでマウントする必要があります。以下は例になります。
      # mount -t xfs -o inode64,noatime <logical volume> <mount point>
      この最適化により、ファイルの読み取り時に XFS inode の更新を避けることで、小規模ファイルの読み取りパフォーマンスが向上します。
      /etc/fstab entry for option E + F
       <logical volume> <mount point>xfs     inode64,noatime   0 0
    • 割り当てグループ
      各 XFS ファイルシステムは、割り当てグループと呼ばれるリージョンに分割されます。割り当てグループは ext3 のブロックグループと似ていますが、割り当てグループはブロックグループよりもはるかに大きく、ディスク局所性ではなくスケーラビリティーと並列処理に使用されます。割り当てグループのデフォルト割り当ては 1 TiB です。
      割り当てグループ数は、同時割り当てワークロードを維持するために十分な大きさである必要があります。mkfs.xfs コマンドで選択したケース割り当てグループの数のほとんどは、最適なパフォーマンスを提供します。ファイルシステムのフォーマット時に mkfs.xfs で選択した割り当てグループ数を変更しないでください。
    • inode への領域割り当てのパーセンテージ
      ワークロードが非常に小さいファイル(ファイルサイズが 10 KB 未満)である場合は、ファイルシステムのフォーマット時に maxpct の値を 10 に設定することが推奨されます。また、arbiter ブリックに必要な場合は maxpct 値を 100 に設定できます。
  3. Red Hat Gluster Storage のパフォーマンスチューニングオプション

    tuned プロファイルは、システムパラメーターを適切に調整することで、特定のユースケースのパフォーマンスを改善するために設計されています。Red Hat Gluster Storage には、ワークロードに適した tuned プロファイルが含まれています。これらのプロファイルは、Red Hat Enterprise Linux 6 および Red Hat Enterprise Linux 7 で利用できます。

    表19.1 異なるワークロードで推奨されるプロファイル

    ワークロードプロファイル名
    大規模なファイル、順次 I/O ワークロード rhgs-sequential-io
    小さなファイルワークロード rhgs-random-io
    ランダム I/O ワークロード rhgs-random-io
    以前のバージョンの Red Hat Gluster Storage は、推奨される Red Hat Enterprise Linux 6 の tuned プロファイル rhs-high-throughput および rhs-virtualization でした。これらのプロファイルは、引き続き Red Hat Enterprise Linux 6 で利用できます。ただし、新規プロファイルへの切り替えが推奨されます。
    重要
    Red Hat Gluster Storage は 3.5 Batch Update 1 以降では、Red Hat Enterprise Linux 6 (RHEL 6) でサポートされません。インストールガイドの『バージョンの詳細』表および『Red Hat Gluster Storage ソフトウェアコンポーネントおよびバージョン』 を参照してください。
    tuned プロファイルに含まれるチューニングを適用するには、Red Hat Gluster Storage ボリュームの作成後に以下のコマンドを実行します。
    # tuned-adm profile profile-name
    以下に例を示します。
    # tuned-adm profile rhgs-sequential-io
  4. ライトバックキャッシング

    小規模なファイルおよび無作為な書き込みパフォーマンスについては、ストレージコントローラー内の不揮発性乱数アクセスメモリー (NVRAM) のライトバックキャッシュを強く推奨します。たとえば、通常の Dell および HP ストレージコントローラーにはこれがあります。NVRAM が有効になっていることを確認します。つまり、バッテリーが機能していることを確認します。NVRAM の有効化に関する詳細は、ハードウェアのドキュメントを参照してください。
    ディスクドライブでライトバックキャッシュを有効にしないでください。これは、書き込みが実際に書き込みを行う前に、ディスクドライブが書き込みが完了したと判断するポリシーです。その結果、電源障害時やメタデータの失われた際に、ディスクの書き込みキャッシュがそのデータが失われると、ファイルシステムの破損につながる可能性があります。

19.2.1. ノードごとに多数のブログ

デフォルトでは、Red Hat Gluster Storage サーバーノードに設定されたすべてのブリックに対して、1 つのプロセスが作成され、1 つのポートが使用されます。1 つのサーバーに多数のブリックが設定されている場合は、ブリックマルチプレッシングを有効にすると、互換性のあるブリックが同じプロセスおよびポートを使用できるようにすることで、ポートおよびメモリー消費が削減されます。Red Hat は、ブリックマルチプレッシングを有効または無効にすると、すべてのボリュームを再起動することを推奨します。
Red Hat Gluster Storage 3.4 の時点で、brick の多重化は OpenShift Container Storage のユースケースでのみサポートされています。

ブログ多重化の設定

  1. cluster.brick-multiplexon に設定します。このオプションは、すべてのボリュームに影響します。
    # gluster volume set all cluster.brick-multiplex on
  2. ブリックマルチプレッシングを有効にするためにすべてのボリュームを再起動します。
    # gluster volume stop VOLNAME
    # gluster volume start VOLNAME
重要
ブリック互換性は、ボリュームの起動時に決定し、ブリック間で共有されるボリュームオプションにより異なります。ブリック多重化が有効な場合は、単一プロセスでグループ化されたブリックの互換性を維持するために、ボリューム設定の詳細が変更されるたびにボリュームを再起動することが推奨されます。