3 Oracle LinuxでのOracle Cluster File System Version 2の管理

この章では、Oracle Linux 8でのOracle Cluster File System Version 2 (OCFS2)の管理について説明します。OCFS2を構成、管理およびトラブルシューティングするためのタスクが含まれています。

Oracle Linux 8では、Oracle Cluster File Ssystem Version 2 (OCFS2)はUnbreakable Enterprise Kernelリリース6 (UEK R6)以降のUnbreakable Enterprise Kernel (UEK)リリースでのみサポートされています。

Oracle Linuxでのローカル・ファイル・システムの管理の詳細は、『Oracle Linux 8 ローカル・ファイル・システムの管理』を参照してください。

OCFS2について

OCFS2 (Oracle Cluster File System Version 2)はクラスタで使用する汎用共有ディスク・ファイル・システムです。OCFS2では、高いパフォーマンスと可用性が提供されます。オプションで、OCFS2ボリュームを、クラスタ化されていないスタンドアロン・システムにマウントすることもできます。

OCFS2を使用すると、次のような利点があります。

  • OCFS2とともにreflinkコマンドを使用すると、個々のファイルのコピーオンライト・クローンを作成できます。cp --reflinkコマンドは、Btrfsファイル・システムの場合と同様の方法で使用することもできます。通常、このようなクローンによって、仮想マシン(VM)イメージやLinuxコンテナなどの非常によく似たファイルの複数のコピーを格納する場合に、ディスク領域を節約できます。

    reflinkコマンドを使用すると、生成されるファイル・システムは元のファイル・システムのクローンのように動作します。つまり、それらのUUIDは同一です。reflinkコマンドを使用してクローンを作成する場合は、tunefs.ocfs2コマンドを使用してUUIDを変更する必要があります。ボリューム・パラメータの問合せおよび変更を参照してください。

  • ローカルOCFS2ファイル・システムをマウントすると、後でそのファイル・システムを、変換せずにクラスタ・ファイル・システムに移行できます。
  • OCFS2では、ローカル・ファイル・システムのセマンティクスが提供されます。したがって、ほぼすべてのアプリケーションでOCFS2を使用できます。クラスタ対応のアプリケーションは、複数のクラスタ・ノードからのキャッシュ一貫性のあるパラレルI/Oを使用してクラスタ全体でアクティビティを調整することや、ノード障害の発生時に利用可能なファイル・システム機能を使用し、フェイルオーバーを実行して別のノードで稼働することができます。

OCFS2のユース・ケース

OCFS2の典型的なユース・ケースを次に示します。

ロード・バランシングのユース・ケース

OCFS2ノードを使用して、クライアント・システム間でリソースを共有できます。たとえば、ノードでは、SambaまたはNFSを使用して共有ファイル・システムをエクスポートできます。ノード間にサービス・リクエストを分散するには、ラウンドロビンDNSやネットワーク・ロード・バランサを使用できます。または、クライアントごとに使用するノードを指定できます。

Oracle Real Application Clusterのユース・ケース

Oracle Real Application Cluster (RAC)では、独自のクラスタ・スタックであるクラスタ同期化サービス(CSS)を使用します。O2CBはCSSと組み合せて使用できますが、各スタックはタイムアウト、ノードおよび他のクラスタ設定に関して個別に構成できます。OCFS2を使用して投票ディスク・ファイルおよびOracle Cluster Registry (OCR)をホストすることはできますが、各ノードのローカル・ファイル・システムに存在する必要のあるグリッド・インフラストラクチャ・ユーザーのホームはホストできません。

CSSとO2CBは、両方とも定数の計算でタイ・ブレーカとして最も小さいノード番号を使用するため、ノード番号が両方のクラスタで同じであることを確認してください。必要に応じて、O2CB構成ファイル/etc/ocfs2/cluster.confを編集し、ノード番号に一貫性を確保します。次に、このファイルをすべてのノードで更新します。クラスタを再起動すると変更が有効になります。

Oracle Databaseのユース・ケース

Oracleデータファイル、制御ファイル、REDOログ、投票ディスクおよびOCRをホストするボリュームをマウントする場合、noatimeオプションを指定します。noatimeオプションによって、inodeのアクセス時間の不要な更新が無効になります。

nointrマウント・オプションを指定すると、シグナルによる進行中のI/Oトランザクションへの割込みを防ぐことができます。

デフォルトでは、init.oraパラメータのfilesystemio_optionsによって、Oracleデータファイル、制御ファイルおよびREDOログへの直接I/Oを実行するようにデータベースに指示します。また、投票ディスクおよびOCRを含むボリュームに対してdatavolumeマウント・オプションを指定する必要もあります。このオプションは、Oracleユーザーのホーム・ディレクトリまたはOracle E-Business Suiteをホストするボリュームには指定しないでください。

ディスク全体でデータベース・ブロックが断片化されないようにするには、ファイル・システムのクラスタ・サイズがデータベース・ブロック・サイズ(通常は8KB)以上である必要があります。mkfs.ocfs2コマンドの使用時にファイル・システムの用途タイプをdatafilesとして指定すると、ファイル・システムのクラスタ・サイズは128KBに設定されます。

Oracleデータファイルにデータを同時にストリーミングすることによって複数のノードでスループットを最大化するため、OCFS2はPOSIX標準とは異なっており、非拡張型の直接I/O書込みを実行する場合にディスクの変更時刻(mtime)を更新しません。mtimeの値はメモリー内で更新されます。ただし、アプリケーションがファイルを拡張または切り捨てたり、touchコマンドを使用するなど、ファイル・メタデータを変更する操作を実行しないかぎり、OCFS2は値をディスクに書き込みません。この動作の結果として、同じファイルについて異なるタイムスタンプをレポートする異なるノードが出現します。次のコマンドを使用して、ファイルのディスク上のタイムスタンプを表示します。

sudo debugfs.ocfs2 -R "stat /file_path" device | grep "mtime:"

OCFS2クラスタの設定

クラスタは、ノードと呼ばれる複数のメンバーからなります。最高のパフォーマンスを得るには、クラスタ内の各ノードに2つ以上のネットワーク・インタフェースが存在する必要があります。最初のインタフェースはパブリック・ネットワークに接続され、システムへの一般的なアクセスが可能になりますが、2番目インタフェースはノードとクラスタのハートビート間のプライベート接続に使用されます。この2番目インタフェースは、クラスタ・ノードが共有リソースへのアクセスを調整する方法と、クラスタ・ノードが互いの状態を監視する方法を決定します。

重要:

いずれのネットワーク・インタフェースも、ネットワーク・スイッチ経由で接続する必要があります。また、クラスタを構成する前に、すべてのネットワーク・インタフェースが構成され、機能していることを確認する必要があります。

OCFS2クラスタの計画

適切な機器を設定することに加え、クラスタ用に次を準備します。

  • 指定されたクラスタ・メンバー。具体的には、それらのホスト名および対応するIPアドレス。
  • クラスタで使用するハートビート・モード。

クラスタ構成では、小さいパケットが、特定のUDPポートを介してセットアップ全体を通過します(クラスタ用に構成されたすべてのネットワークを含む)。これらのパケットが、クラスタ・ノード間のルートを確立し、クラスタ・ネットワークが稼働中か停止中かを示すインジケータとなります。基本的に、それらのパケットが、クラスタの状態を判断するための手段となります。このため、これらのパケットはハートビートとも呼ばれます。

クラスタは、次のいずれかのハートビート・モードで実行するように構成できます。

  • 共有デバイスごとのローカル・ハートビート・スレッド(デフォルトのハートビート・モード)。

    この構成では、ノードは、OCFS2ボリュームのマウント時にハートビート・スレッドを開始し、そのボリュームのマウント解除時にそのスレッドを停止します。多数のOCFS2ボリュームをマウントするノードでは、各マウントで別々のハートビート・スレッドが必要になるためCPUオーバーヘッドが大きくなります。同様に、マウント数が多いと、1つのマウントでのハートビートI/Oタイムアウトが原因で、ノードがクラスタから分離される(フェンシングとも呼ばれる)リスクが高まります。

  • 特定の共有デバイスでのグローバル・ハートビート。

    このモードでは、パーティションではなくディスク・デバイス全体を占有するOCFS2ボリュームを、グローバル・ハートビート・デバイスとして構成できます。このモードでは、クラスタがオンラインになるとそのデバイスに対するハートビートが開始し、クラスタがオフラインになるとハートビートが停止します。多くのOCFS2ボリュームをマウントするクラスタでは、このモードをお薦めします。グローバル・ハートビート・デバイスの半分以上でハートビートI/Oタイムアウトが発生した場合、ノードはクラスタから自身をフェンシングします。1つのデバイスの障害に対する冗長性を確保するために、少なくとも3つのグローバル・ハートビート・デバイスを構成する必要があります。

次の図は、ネットワーク・スイッチを使用してLANおよびネットワーク・ストレージ・サーバーに接続された4ノードのクラスタを示しています。ノードとストレージ・サーバーは、スイッチを使用して、ローカル・クラスタのハートビートに使用されるプライベート・ネットワークにも接続されます。

図3-1 プライベート・ネットワークを使用したクラスタ構成


この図は、ネットワーク・スイッチを使用してLANおよびネットワーク・ストレージ・サーバーに接続された4ノードのクラスタを示しています。また、ノードとストレージ・サーバーは、スイッチを使用してプライベート・ネットワークに接続され、クラスタのハートビートに使用されます。

プライベート・ネットワークを使用せずにOCFS2を構成および使用することもできますが、このような構成では、I/Oハートビート・タイムアウトが原因でクラスタからのノード・フェンシングが発生する可能性が高まります。

次の表に、ファイル・システムのサイズ範囲ごとの最小クラスタ・サイズ設定に関する推奨事項を示します。

ファイル・システムのサイズ 推奨される最小クラスタ・サイズ

1 GB - 10 GB

8K

10GB - 100 GB

16K

100 GB - 1 TB

32K

1 TB - 10 TB

64K

10 TB - 16 TB

128K

クラスタ・ソフトウェアのインストール

OCFS2とUEKソフトウェアの様々なバージョンを使用する複数のノードが含まれているクラスタを構成できます。この構成は、クラスタのローリング更新を実行している状況のためにサポートされています。このような場合は、最も低いバージョンのソフトウェアを実行しているクラスタ・ノードによって、使用可能な機能のセットが決定されます。ただし、クラスタ操作の効率性を確保するために、クラスタのすべてのノードで、同じバージョンのOCFS2ソフトウェア、および互換性のあるUEKリリースを使用することをお薦めします。

OCFS2の構成方法のチュートリアルは、Oracle Cloud InfrastructureでのOracle Cloud Cluster File Systemツールの使用を参照してください。

重要:

指定された各ノードで次の手順を実行します。
  1. 指定されたノードのカーネル・バージョンを表示します。
    sudo uname -r

    すべてのノードでの出力に、同じバージョン(5.4.17-2136.302.7.2.1.el8uek.x86_64など)が表示される必要があります。必要に応じて、各ノードを更新して、必ずすべてのノードで同じカーネル・バージョンが実行されるようにします。

  2. OCFS2パッケージをインストールします。
    sudo dnf install -y ocfs2-tools

    ノート:

    グローバル・ハートビート機能を使用する場合は、さらに、ocfs2-tools-1.8.0-11以降のパッケージをインストールします。

  3. プライベート・クラスタ通信のためにそのクラスタで使用されるインタフェースでのアクセスを可能にするように、ファイアウォールを構成します。

    デフォルトでは、クラスタはポート7777を通じてTCPとUDPの両方を使用します。

    sudo firewall-cmd --permanent --add-port=7777/tcp --add-port=7777/udp
  4. SELinuxを無効にします。

    テキスト・エディタで、/etc/selinux/configファイルを開き、この例で太字で示しているように、そのファイル内の適切な行エントリでSELinuxを無効にします。

    # This file controls the state of SELinux on the system.
    # SELINUX= can take one of these three values:
    #     enforcing - SELinux security policy is enforced.
    #     permissive - SELinux prints warnings instead of enforcing.
    #     disabled - No SELinux policy is loaded.
    SELINUX=disabled

クラスタ・レイアウトの構成

  1. 指定されたクラスタ・メンバーのいずれかで、クラスタ定義を作成します。

    sudo o2cb add-cluster cluster-name
  2. 現在のシステム、および指定されているその他のノードすべてをクラスタに追加します。

    sudo o2cb add-node cluster-name hostname --ip ip_address

    このIPアドレスは、クラスタでのプライベート通信のためにそのノードによって使用されるIPアドレスである必要があります。

    ホスト名で特定されている次のシステムからクラスタmyclusterを作成するとします。さらに、ol-sys1を使用してこの構成を完了します。

    • ol-sys0: 10.1.0.100
    • ol-sys1: 10.1.0.110
    • ol-sys2: 10.1.0.120

    myclusterにノードを追加するには、ol-sys1で次のコマンドを入力します。

    sudo o2cb add-node mycluster ol-sys0 --ip 10.1.0.100
    sudo ol2cb add-node mycluster ol-sys1 --ip 10.1.0.110
    sudo ol2cb add-node mycluster ol-sys2 --ip 10.1.0.120

    ノート:

    OCFS2はIPv4アドレスのみをサポートします。

  3. クラスタをグローバル・ハートビート・モードで実行する場合は、次の手順を実行します。

    1. すべてのクラスタ・デバイスで次のコマンドを実行します。
      sudo o2cb add-heartbeat cluster-name device-name

      たとえば、myclusterの場合は、次のように/dev/sdd/dev/sdgおよび/dev/sdjでクラスタ・ハートビートを設定します。

      sudo o2cb add-heartbeat mycluster /dev/sdd
      sudo o2cb add-heartbeat mycluster /dev/sdg
      sudo o2cb add-heartbeat mycluster /dev/sdj
    2. クラスタのハートビート・モードを「global」に設定します。
      sudo o2cb heartbeat-mode cluster-name global

    重要:

    ディスク・デバイス全体を使用するように、グローバル・ハートビート機能を構成する必要があります。ディスク・パーティション上のグローバル・ハートビート・デバイスはサポートされていません。

  4. クラスタ/etc/ocfs2/cluster.confファイルをクラスタ内の各ノードにコピーします。

  5. (オプション)そのクラスタに関する情報を表示します。
    sudo o2cb list-cluster cluster-name

    ローカル・ハートビートが設定された、ノードが3つあるクラスタmyclusterには、次のような情報が表示されます。

    node:
    	name = ol-sys0
    	cluster = mycluster
    	number = 0
    	ip_address = 10.1.0.100
    	ip_port = 7777
    
    node:
            name = ol-sys1
            cluster = mycluster
            number = 1
            ip_address = 10.1.0.110
            ip_port = 7777
    
    node:
            name = ol-sys2
            cluster = mycluster
            number = 2
            ip_address = 10.1.0.120
            ip_port = 7777
    
    cluster:
            name = mycluster
            heartbeat_mode = local
            node_count = 3

    同じクラスタだがグローバル・ハートビートが設定されている場合は、次の情報が含まれます。

    node:
            name = ol-sys0
            cluster = mycluster
            number = 0
            ip_address = 10.1.0.100
            ip_port = 7777
    
    node:
            name = ol-sys1
            cluster = mycluster
            number = 1
            ip_address = 10.1.0.110
            ip_port = 7777
    
    node:
            name = ol-sys2
            cluster = mycluster
            number = 2
            ip_address = 10.1.0.120
            ip_port = 7777
    
    cluster:
            name = mycluster
            heartbeat_mode = global
            node_count = 3
    
    heartbeat:
            cluster = mycluster
            region = 7DA5015346C245E6A41AA85E2E7EA3CF
    
    heartbeat:
            cluster = mycluster
            region = 4F9FBB0D9B6341729F21A8891B9A05BD
    
    heartbeat:
            cluster = mycluster
            region = B423C7EEE9FC426790FC411972C91CC3

    ハートビートのリージョンは、それらのブロック・デバイスのUUIDによって表されます。

O2CBクラスタ・スタックの構成および起動

重要:

指定された各ノードで次の手順を実行します。
  1. ノードを構成します。

    sudo /sbin/o2cb.init configure

    構成プロセスによって、追加情報の入力を求められます。設定する必要があるパラメータの一部を次に示します。

    • ブート時にO2CBドライバをロードする: yまたはn (デフォルト設定)を指定します。
    • ブート時に起動するクラスタ: クラスタの名前を指定します。この名前は、/etc/ocfs2/cluster.confファイル内の名前と一致する必要があります。
    • 情報の入力を求められる残りのパラメータについては、通常は、デフォルト設定で十分です。ただし、必要に応じて、デフォルト以外の値を指定できます。
  2. クラスタ・スタックの設定を確認します。

    sudo /sbin/o2cb.init status

    ローカル・ハートビート・モードを使用するクラスタでは、次のような情報が表示されます。

    Driver for "configfs": Loaded
    Filesystem "configfs": Mounted
    Stack glue driver: Loaded
    Stack plugin "o2cb": Loaded
    Driver for "ocfs2_dlmfs": Loaded
    Filesystem "ocfs2_dlmfs": Mounted
    Checking O2CB cluster "mycluster": Online
      Heartbeat dead threshold: 61
      Network idle timeout: 30000
      Network keepalive delay: 2000
      Network reconnect delay: 2000
      Heartbeat mode: Local
    Checking O2CB heartbeat: Active

    グローバル・ハートビート・モードを使用するクラスタでは、次のような情報が表示されます。

    Driver for "configfs": Loaded
    Filesystem "configfs": Mounted
    Stack glue driver: Loaded
    Stack plugin "o2cb": Loaded
    Driver for "ocfs2_dlmfs": Loaded
    Filesystem "ocfs2_dlmfs": Mounted
    Checking O2CB cluster "mycluster": Online
      Heartbeat dead threshold: 61
      Network idle timeout: 30000
      Network keepalive delay: 2000
      Network reconnect delay: 2000
      Heartbeat mode: Global
    Checking O2CB heartbeat: Active
      7DA5015346C245E6A41AA85E2E7EA3CF /dev/sdd
      4F9FBB0D9B6341729F21A8891B9A05BD /dev/sdg
      B423C7EEE9FC426790FC411972C91CC3 /dev/sdj
  3. o2cbおよびocfs2サービスを有効にして、ネットワーキングが有効になった後のブート時にそれらが開始されるようにします。

    sudo systemctl enable o2cb
    sudo systemctl enable ocfs2
  4. テキスト・エディタを使用して、/etc/sysctl.d/99-sysctl.confファイル内で、クラスタ操作について次のカーネル設定を指定します。
    • kernel.panic = 30

      この設定により、パニック後にシステムが自動的に自己リセットするまでの秒数を指定します。デフォルト値は0です。つまり、パニック後にシステムがハングします。ゼロ以外の値を指定すると、システムが自動リセットされるようになります。システムがハングする前にメモリー・イメージが作成されるようにする必要がある場合は、より高い値を割り当てます。

    • kernel.panic_on_oops = 1

      この設定では、カーネルのoopsが発生した場合にシステムでパニックが発生します。したがって、クラスタ操作に必要なカーネル・スレッドがクラッシュした場合、システムは自己リセットします。そうしないと、他のノードが、あるノードで応答が遅くなっているのか応答できなくなっているのかを区別できず、結果としてすべてのクラスタ操作がハングする可能性があります。

  5. 次のコマンドを実行して構成を適用します。
    sudo sysctl -p

o2cb.initコマンドでは、次のような、クラスタを管理できる他のサブコマンドを使用できます。

  • /sbin/o2cb.init status: クラスタ・スタックのステータスを確認します。
  • /sbin/o2cb.init online: クラスタ・スタックを停止します。
  • /sbin/o2cb.init offline: クラスタ・スタックを起動します。
  • /sbin/o2cb.init unload: クラスタ・スタックをアンロードします。

使用可能なその他のサブコマンドを確認するには、コマンドo2cb.initを単独で入力します。

OCFS2ボリュームの使用

OCFS2ボリュームを構成するには、メイン・コマンドとしてmkfs.OCFS2を使用します。特定の要件に従ってボリュームを作成できるように、このコマンドでは、次のような様々なオプションおよび引数を指定できます。

-b blocksize、--block-size blocksize

ファイル・システムを対象とするI/Oトランザクションの単位サイズと、inodeおよびエクステント・ブロックのサイズを指定します。サポートされるブロック・サイズは、512 (512バイト)、1K、2Kおよび4Kです。デフォルトおよび推奨ブロック・サイズは、4K (4KB)です。

-C clustersize、--cluster-size clustersize

ファイル・データを割り当てるために使用する領域の単位サイズを指定します。サポートされるクラスタ・サイズは、4K、8K、16K、32K、64K、128K、256K、512Kおよび1M (1MB)です。デフォルトのクラスタ・サイズは、4K (4KB)です。

--fs-feature-level=feature-level
ファイルシステム機能のセットを次の選択肢から指定できます。
  • default: スパース・ファイル、未書込みエクステントおよびインライン・データ機能のサポートを有効にします。
  • max-compat: OCFS2の旧バージョンによって認識される機能のみを有効にします。
  • max-features:

    OCFS2によって現在サポートされているすべての機能を有効にします。

--fs_features=feature

スパース・ファイル、未書込みエクステント、バックアップ・スーパーブロックのサポートなどの個々の機能を有効化または無効化できます。詳細は、mkfs.ocfs2(8)マニュアル・ページを参照してください。

-J journalsize、--journal-size journalsize

先行書込みジャーナルのサイズを指定します。指定されていない場合、サイズは-Tオプションに指定するファイル・システムの用途タイプから決定され、それ以外の場合はボリューム・サイズから決定されます。ジャーナルのデフォルト・サイズは、datafilesの場合は64M (64MB)、mailの場合は256M (256MB)およびvmstoreの場合は128M (128MB)です。

-L label、--label label

異なるクラスタ・ノードで簡単に識別できるわかりやすいボリュームの名前を指定します。

-N number-of-slots、--node-slots number-of-slots

ボリュームに同時にアクセスできるノードの最大数を指定します(これは、ファイル・システム・ジャーナルなどのシステム・ファイルではノード・スロットの数によって制限されます)。最高のパフォーマンスを得るには、ノード・スロットの数をノード数の2倍以上に設定します。後でノード・スロットの数を増加すると、ジャーナルはディスク・プラッタの外縁部に隣接して配置されなくなるため、パフォーマンスが低下する可能性があります。

-T file-system-usage-type

ファイル・システムの使用方法のタイプとして、次の3つのオプションのいずれかを指定します。

  • datafiles: データベース・ファイルの場合は、通常、数はわずかで、完全に割り当てられ、比較的大きいサイズです。このようなファイルでは、メタデータの変更はほとんど必要なく、大規模なジャーナルを保持する利点はありません。
  • mail: メール・サーバー・ファイルの場合は、通常、数が多く、比較的小さいサイズです。このようなファイルでは、メタデータの変更が多く、大規模なジャーナルを保持する利点があります。
  • vmstore: 仮想マシン・イメージ・ファイルの場合は、通常、数はわずかで、まばらに割り当てられ、比較的大きいサイズです。このようなファイルでは、メタデータの変更数は中程度であり、中規模のサイズのジャーナルが必要です。

OCFS2ボリュームの作成およびマウント

OCFS2ボリュームの作成時には、次の追加ポイントに注意してください。

  • LVMはクラスタ対応ではないため、LVM論理ボリュームにOCFS2ボリュームを作成しないでください。

  • OCFS2ボリュームを作成した後は、そのボリュームのブロックおよびクラスタのサイズを変更できません。tunefs.ocfs2コマンドを使用すると、一定の制限付きでファイル・システムの他の設定を変更できます。詳細は、tunefs.ocfs2(8)マニュアル・ページを参照してください。

  • ボリュームでデータベース・ファイルを格納する場合、データベースのブロック・サイズより小さいクラスタ・サイズを指定しないでください。

  • ファイル・システムの大きさが数GBを超える場合、デフォルトのクラスタ・サイズ4KBでは不適切です。

  1. OCFS2ボリュームを作成します。
    sudo mkfs.ocfs2 -L "myvol" /dev/sdc1

    このコマンドでは、指定されたデバイスに、ラベル付きでボリュームが作成されます。追加でオプションや引数を指定しない場合は、そのプロパティのいくつかにデフォルト値が使用されてボリュームが作成されます(ブロックおよびクラスタのサイズは4 KB、ノード・スロットは8つ、ジャーナルは256 MB、デフォルトのファイル・システム機能のサポートなど)。デフォルト設定が使用されたこのボリュームは、数GB以下のファイル・システムに適しています。

    ヒント:

    ボリュームのマウント時にラベルを参照できるように、デバイスがパーティションと対応していることを確認します。

    mkfs.ocfs2コマンドで使用するオプションによって、作成するボリュームが決まります。次の例を参考にしてください。

    • データベースとして使用する、ラベル付きボリュームを作成します。
      sudo mkfs.ocfs2 -L "dbvol" -T datafiles /dev/sdd2

      この場合、クラスタ・サイズは128KBに、ジャーナル・サイズは32MBに設定されます。

    • 特定のプロパティ設定でボリュームを作成します。
      sudo mkfs.ocfs2 -C 16K -J size=128M -N 16 --fs-feature-level=max-features --fs-features=norefcount /dev/sde1

      この場合は、クラスタ・サイズとジャーナル・サイズ、およびノード・スロット数が指定されています。また、norefcountツリーを除く、サポートされているすべての機能が有効になっています。

  2. 各クラスタ・メンバーで、作成したボリュームをマウントします。
    1. マウント・ポイントを作成します。
      sudo mkdir /u01
    2. そのボリュームをマウントします。
      sudo mount -L myvol /u01
    3. ハートビート・モードのステータスを確認します。
      sudo o2cb.init status

      ボリュームがマウントされるとハートビートがアクティブになります。

オプションで、/etc/fstabにエントリを追加することで、マウント操作を自動化できます。次に例を示します。

myvol  /u01   ocfs2     _netdev,defaults  0 0

このエントリでは、_netdevにより、ネットワークの起動後のみブート時にOCFS2ボリュームをマウントするようシステムに通知されます。また、ネットワークの停止前にシステムによってファイル・システムがアンマウントされる必要があります。

ボリューム・パラメータの問合せおよび変更

tunefs.ocfs2コマンドを使用して、ボリューム・パラメータの問合せおよび変更します。

たとえば、ボリュームのラベル、UUID、およびノード・スロットの数を調べるには、次のコマンドを使用します。

sudo tunefs.ocfs2 -Q "Label = %V\nUUID = %U\nNumSlots =%N\n" /dev/sdb
Label = myvol
UUID = CBB8D5E0C169497C8B52A0FD555C7A3E
NumSlots = 4

ボリュームの新しいUUIDを生成するには、次のコマンドを使用します。

sudo tunefs.ocfs2 -U /dev/sda
sudo tunefs.ocfs2 -Q "Label = %V\nUUID = %U\nNumSlots =%N\n" /dev/sdb
Label = myvol
UUID = 48E56A2BBAB34A9EB1BE832B3C36AB5C
NumSlots = 4

ローカルOCFS2ファイル・システムの作成

次の手順では、クラスタに関連付けられていない、ローカルにマウントされるOCFS2ファイル・システムを作成する方法について説明します。

ローカルにマウントされるOCFS2ファイル・システムを作成するには、次のコマンド構文を使用します。

sudo mkfs.ocfs2 -M local --fs-features=local -N 1 [options] device

次の例を考えてみましょう。次のように、ノード・スロットが1つでラベルがlocalvolの、ローカルにマウント可能なOCFS2ボリュームを/dev/sdc1に作成するとします。

sudo mkfs.ocfs2 -M local --fs-features=local -N 1 -L "localvol" /dev/sdc1

このコマンドでは、localvolというラベルと1つのノード・スロットがある、ローカルにマウント可能なボリュームが作成されます。

ローカルOCTFS2ファイル・システムをクラスタ用途に変換するには、次のようにtunefs.ocfs2ユーティリティを使用します。

sudo umount /dev/sdc1
sudo tunefs.ocfs2 -M cluster --fs-features=clusterinfo -N 8 /dev/sdc1

前述の例では、ノード・スロットの数も1から8に増やしているため、最大8個のノードによるファイル・システムをマウントが可能になります。

OCFS2の問題のトラブルシューティング

OCFS2の管理時に発生する可能性のある問題の解決方法を調べる場合は、次の情報を参照してください。

推奨されるデバッグ・ツールとプラクティス

OCFS2の問題をトラブルシューティングするには、次のツールを使用します。

  • ノードでnetconsoleを設定して、oopsトレースをキャプチャすることをお薦めします。

  • tcpdumpコマンドを使用して、ノード間のDLMのネットワーク・トラフィックをキャプチャします。たとえば、プライベート・ネットワーク・インタフェースem2のポート7777でTCPトラフィックをキャプチャするには、次のコマンドを使用します。

    sudo tcpdump -i em2 -C 10 -W 15 -s 10000 -Sw /tmp/`hostname -s`_tcpdump.log \
    -ttt 'port 7777' &
  • debugfs.OCFS2コマンドを使用して、OCFS2ドライバでのイベントのトレース、ロック・ステータスの判別、ディレクトリ構造の調査、inodeの調査などを行います。このコマンドの動作は、ext3ファイル・システムで使用されるdebugfsコマンドと類似しています。

    詳細は、debugfs.ocfs2(8)マニュアル・ページを参照してください。

  • o2imageコマンドを使用して、inode、ファイル名およびディレクトリ名の情報を含むOCFS2ファイル・システムのメタデータを別のファイル・システムのイメージ・ファイルに保存できます。イメージ・ファイルはメタデータのみを格納するため、元のファイル・システムよりずっと小さくなります。debugfs.ocfs2を使用してイメージ・ファイルを開き、ファイル・システムのレイアウトを分析してファイル・システムの破損またはパフォーマンス問題の原因を特定できます。

    たとえば、デバイス/dev/sda2のOCFS2ファイル・システムからイメージ/tmp/sda2.imgを作成するには、次のコマンドを使用します。
    sudo o2image /dev/sda2 /tmp/sda2.img

    詳細は、o2image(8)マニュアル・ページを参照してください。

debugfsファイル・システムのマウント

OCFS2はdebugfsファイル・システムを使用して、ユーザー空間でカーネル内の状態に関する情報にアクセスできるようにします。debugfs.ocfs2コマンドを使用するには、debugfsファイル・システムをマウントする必要があります。

たとえば、debugfsファイル・システムをマウントするには、次の行を/etc/fstabファイルに追加します。

debugfs    /sys/kernel/debug      debugfs  defaults  0 0

次に、mount -aコマンドを実行します。

OCFS2トレースの構成

次のコマンドとメソッドを使用して、OCFS2の問題をトレースできます。

OCFS2の問題をトレースするコマンド

次のリストでは、問題のトレースに役立ついくつかのコマンドを示します。

debugfs.ocfs2 -l

すべてのトレース・ビットとそれらのステータスをリストします。

debugfs.ocfs2 -l SUPER allow|off|deny

スーパーブロックのトレースを有効化、無効化、または拒否します。denyを指定した場合、トレースは、別のトレース・モード設定で暗黙的に許可されているとしても、許可されません。

debugfs.ocfs2 -l HEARTBEAT ENTRY EXIT allow

ハートビート・トレースを有効にします。

debugfs.ocfs2 -l HEARTBEAT off ENTRY EXIT deny

ハートビート・トレースを無効にします。ENTRYおよびEXITパラメータは、すべてのトレース・パスに存在するため、denyに設定されます。

debugfs.ocfs2 -l ENTRY EXIT NAMEI INODE allow

ファイル・システムのトレースを有効にします。

debugfs.ocfs2 -l ENTRY EXIT deny NAMEI INODE allow

ファイル・システムのトレースを無効にします。

debugfs.ocfs2 -l ENTRY EXIT DLM DLM_THREAD allow

DLMのトレースを有効にします。

debugfs.ocfs2 -l ENTRY EXIT deny DLM DLM_THREAD allow

DLMのトレースを無効にします。

OCFS2トレース・メソッドおよび例

トレースの取得に使用できる方法の1つは、まずトレースを有効にし、しばらくの間スリープして、その後トレースを無効にすることです。次の例に示すように、不要な出力を避けるには、トレースの終了後にトレース・ビットをデフォルト設定にリセットする必要があります。

sudo debugfs.ocfs2 -l ENTRY EXIT NAMEI INODE allow && sleep 10 &&
sudo debugfs.ocfs2 -l ENTRY EXIT deny NAMEI INODE off 

表示される情報の量を制限するには、問題の診断に関連するトレース・ビットのみを有効にします。

mvなどの特定のファイル・システム・コマンドによってエラーが発生した場合は、次の例に示すコマンドを使用して、エラーをトレースできます。

sudo debugfs.ocfs2 -l ENTRY EXIT NAMEI INODE allow
mv source destination & CMD_PID=$(jobs -p %-)
echo $CMD_PID
sudo debugfs.ocfs2 -l ENTRY EXIT deny NAMEI INODE off 

トレースは、マウントされたすべてのOCFS2ボリュームに対して有効になるため、適切なプロセスIDを把握することが、トレースの解釈に役立ちます。

詳細は、debugfs.ocfs2(8)マニュアル・ページを参照してください。

ファイル・システム・ロックのデバッグ

OCFS2ボリュームがハングした場合は、次の手順を使用して、ビジー状態にあるロックと、ロックを保持している可能性の高いプロセスを判断できます。

次の手順では、Lockres値はDLMで使用されるロック名を参照します。これは、ロックタイプ識別子、inode番号、および世代番号の組合せです。次の表に、様々なロックタイプと関連する識別子を示します。

表3-1 DLMロック・タイプ

識別子 ロック・タイプ

D

ファイル・データ

M

メタデータ

R

名前変更

S

スーパーブロック

W

読取り/書込み

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

    sudo mount -t debugfs debugfs /sys/kernel/debug
  2. ファイル・システム・デバイス(次の例では/dev/sdx1)のロック・ステータスをダンプします。

    echo "fs_locks" | sudo debugfs.ocfs2 /dev/sdx1 | sudo tee /tmp/fslocks
    Lockres: M00000000000006672078b84822 Mode: Protected Read
    ...
  3. 前の出力からのLockres値を使用して、ロックのinode番号および世代番号を取得します。

    sudo echo "stat lockres-value" | sudo debugfs.ocfs2 -n /dev/sdx1

    たとえば、前のステップでのLocresM00000000000006672078b84822の場合、コマンド出力は次のようになります。

    Inode: 419616   Mode: 0666   Generation: 2025343010 (0x78b84822)
    ... 
  4. 前の出力でのinode番号が関連付けられている、ファイル・システム・オブジェクトを特定します。

    sudo echo "locate inode" | sudo debugfs.ocfs2 -n /dev/sdx1

    たとえば、前のステップでのInode419616の場合、コマンド出力は次のようになります。

    419616 /linux-2.6.15/arch/i386/kernel/semaphore.c
  5. ファイル・システム・オブジェクトに関連付けられているロック名を取得します。これは、前のステップの出力では/linux-2.6.15/arch/i386/kernel/semaphore.cです。したがって、次のように入力します。

    sudo echo "encode /linux-2.6.15/arch/i386/kernel/semaphore.c" | sudo debugfs.ocfs2 -n /dev/sdx1
    M00000000000006672078b84822 D00000000000006672078b84822 W00000000000006672078b84822  

    前述の例では、ファイル・システム・オブジェクトにメタデータ・ロック、ファイル・データ・ロックおよび読取り/書込みロックが関連付けられています。

  6. 次のコマンドを実行して、ファイル・システムのDLMドメインを特定します。

    sudo echo "stats" | sudo debugfs.ocfs2 -n /dev/sdX1 | grep UUID: | while read a b ; do echo $b ; done
    82DA8137A49A47E4B187F74E09FBBB4B  
  7. DLMドメインの値とDLMのデバッグを有効にするロック名を使用して、次のコマンドを実行します。

    sudo echo R 82DA8137A49A47E4B187F74E09FBBB4B M00000000000006672078b84822 | sudo tee /proc/fs/ocfs2_dlm/debug
  8. dmesg | tailコマンドを使用してデバッグ・メッセージを調べます。次に例を示します。

    struct dlm_ctxt: 82DA8137A49A47E4B187F74E09FBBB4B, node=3, key=965960985
      lockres: M00000000000006672078b84822, owner=1, state=0 last used: 0, 
      on purge list: no granted queue:
          type=3, conv=-1, node=3, cookie=11673330234144325711, ast=(empty=y,pend=n), 
          bast=(empty=y,pend=n) 
        converting queue:
        blocked queue:  

    DLMでは、ロックなし(type=0)、保護読取り(type=3)および排他(type=5)という3つのロック・モードがサポートされます。前述の例では、ロックはノード1 (owner=1)によって所有されており、ノード3にはファイルシステム・リソースに対する保護読取りロックが付与されています。

  9. 次のコマンドを使用して、STAT列のDフラグによって示される、中断不可能なスリープ状態にあるプロセスを検索します。

    ps -e -o pid,stat,comm,wchan=WIDE-WCHAN-COLUMN

    中断不可能なスリープ状態にある1つ以上のプロセスが、他のノードでのハングに対応します。

プロセスがI/Oの完了を待機している場合、ブロック・デバイス・レイヤーからドライバ、ディスク・アレイまで、I/Oサブシステム内のすべての場所で問題が発生する可能性があります。ハングがユーザー・ロック(flock())に影響する場合、問題はアプリケーションに存在する可能性があります。可能であれば、ロックの所有者を強制終了します。ハングの原因がメモリーの不足またはメモリーの断片化にある場合、重要でないプロセスを強制終了してメモリーを解放できます。最も迅速な解決策は、ロックを保持しているノードをリセットすることです。DLMリカバリ・プロセスでは、デッド・ノードが所有するロックをすべてクリアできます。これにより、クラスタの動作を継続できます。

Kdumpを使用したフェンシングされたノードの動作の構成

ハートビート・メカニズムで、マウントされたOCFS2ボリュームがあるノードがその他のクラスタ・ノードとの接続を失ったことが検出された場合、そのノードは、フェンシングと呼ばれるプロセスでクラスタから削除されます。フェンシングによって、他のノードが、フェンシングされたノードで保持されているリソースにアクセスしようとしてハングすることを回避できます。デフォルトでは、フェンシングされたノードは、クラスタにすばやく再参加できるように自動的に再起動されます。

ただし、状況によっては、このデフォルト動作が望ましくない場合があります。たとえば、明らかな理由もなくノードが頻繁に再起動される場合は、その問題をトラブルシューティングできるようにするために、再起動ではなくノードにパニックを発生させることをお薦めします。そのノードでKdumpを有効にすることで、フェンシングされたノードからvmcoreクラッシュ・ダンプを取得できます。これを分析して、頻繁にノードが再起動される原因を診断できます。

次のフェンシングでパニックが発生するようにノードを構成するには、クラスタの起動後にそのノードで次のコマンドを実行することで、fence_methodpanicに設定します。

echo "panic" | sudo tee /sys/kernel/config/cluster/cluster-name/fence_method

システムの再起動後に毎回その値を設定するには、/etc/rc.localファイルに同じ行を追加します。

デフォルト動作に戻すには、fence_methodの値をresetに変更します。

echo "reset" | sudo tee /sys/kernel/config/cluster/cluster-name/fence_method

また、/etc/rc.localファイル内にpanic行が存在する場合は、そのファイルからその行を削除します。