シンプロビジョニングされた共有GFS2ブロックストレージ

最終公開日 : Oct 07, 2026
シンプロビジョニングは、VDIの仮想サイズ全体を事前に割り当てるのではなく、仮想ディスクにデータが書き込まれるときにVDIにディスクストレージ領域を割り当てることで、利用可能なストレージをより有効に活用します。シンプロビジョニングにより、共有ストレージアレイで必要となるスペースの量を大幅に削減でき、それに伴い総所有コスト (TCO) も削減できます。
警告:
GFS2にはいくつかの制限と複雑さがあり、続行する前に慎重に検討する必要があります。多くの場合、代替のストレージ戦略が適切です。
GFS2の制限事項は次のとおりです。
  • 完全な機能を備えていません (DRのサポートなし、ストレージ移行のサポートなし、プールサイズは16に制限)
  • パフォーマンスの制限があり、大規模なI/O集中型ワークロードには不向きです
  • クラスターサービスが必要であり、これにより安定性の問題が発生する可能性があります
  • 理解するのがより複雑で、その結果、設定ミスやエラーが増加します
これらの制限と複雑さを理解した上で、要件を満たす代替手段がない場合にのみGFS2を使用することをお勧めします。GFS2が適切である可能性のあるシナリオは次のとおりです。
  • シンプロビジョニングが必要だが、SANによって提供されていない場合。 推奨されるのは、シンプロビジョニングの要件を満たすSANでLVMストレージを使用することです。これが不可能な場合は、GFS2を検討できます。
  • >2TiBディスクのサポート。 GFS2は最大16TBのディスクをサポートします。>2TiBディスクが必要な場合、GFS2を検討できます。お客様は、環境が負荷およびパフォーマンス要件を満たせることを確認するためにテストを実施する必要があります。
SANがシンプロビジョニングをサポートしている場合、2TiBを超えるVMディスクが必要な場合を除き、GFS2よりもLVMと組み合わせてこれを使用することをお勧めします。2TiBを超えるVMディスクが必要な場合は、LVMで複数のディスクを使用してこれを実現することを検討してください。
共有GFS2タイプは、iSCSIまたはHBA LUN上に作成されたファイルシステムとしてディスクを表します。GFS2 SRに保存されたVDIは、QCOW2イメージ形式で保存されます。
この記事では、xe CLIを使用してGFS2環境をセットアップする方法について説明します。XenCenterを使用してGFS2環境をセットアップするには、XenCenter製品ドキュメントを参照してください。
Related information
ストレージリポジトリを作成する

1. GFS2環境を計画する

データ損失のリスクなしに共有ブロックストレージでシンプロビジョニングの利点を提供するには、プールが高いレベルの信頼性と接続性を提供する必要があります。GFS2を使用するリソースプール内のホストが互いに確実に通信できることが重要です。これを確実にするために、XenServer®はGFS2 SRでクラスター化されたプールを使用することを要求します。また、可能な限り多くの復元力と冗長性を提供するように環境を設計し、XenServer機能を構成することをお勧めします。
GFS2 SRで動作するようにXenServerプールを設定する前に、理想的なGFS2環境に関する以下の要件と推奨事項を確認してください。
GFS2 SRを持つクラスター化されたプールは、他の種類のプールおよびSRとは動作にいくつかの違いがあります。詳細については、制限事項を参照してください。

2. 冗長なネットワークインフラストラクチャを構成する

ボンディングネットワークは、2つ以上のNICを結合して、ネットワークトラフィック用の単一チャネルを作成します。クラスター化されたプールのトラフィックにはボンディングネットワークを使用することをお勧めします。ただし、ボンディングネットワークを設定する前に、ネットワークハードウェア構成がボンディングネットワークの冗長性を促進することを確認してください。組織と環境にとって実現可能な限り、これらの推奨事項を多く実装することを検討してください。
以下のベストプラクティスは、ネットワークスイッチに影響を与える可能性のあるソフトウェア、ハードウェア、または電源の障害に対する復元力を高めます。
  • ボンディングネットワークで使用するために、同じスイッチ上のポートだけでなく、個別の物理ネットワークスイッチが利用可能であることを確認してください。
  • 個別のスイッチが、異なる独立した配電ユニット（PDU）から電源を供給されることを確認してください。
  • データセンターで可能であれば、PDUを電源供給の異なるフェーズ、あるいは異なる電力会社が提供する電源に配置してください。
  • 停電時にネットワークスイッチとサーバーが機能し続けたり、正常にシャットダウンしたりできるように、無停電電源装置の使用を検討してください。

3. 専用のボンディングネットワークを作成する

クラスター化されたプール内のホストが互いに確実に通信できることを確認することが重要です。このプールトラフィック用にボンディングネットワークを作成すると、クラスター化されたプールの回復性が向上します。
注:
クラスターネットワークは、非管理VLAN上に配置できません。
ボンディングネットワークは、2つ以上のNIC間に結合を作成し、クラスター化されたプールがクラスターハートビートトラフィックに使用できる単一の高性能チャネルを作成します。このボンディングネットワークを他のトラフィックに使用しないことを強くお勧めします。管理トラフィックに使用するプール用に別のネットワークを作成してください。
警告:
この推奨事項に従わない場合、クラスター管理ネットワークパケットを失うリスクが高まります。クラスター管理ネットワークパケットの損失は、クラスター化されたプールがクォーラムを失い、プール内の一部のホストまたはすべてのホストが自己フェンスする原因となる可能性があります。
この非推奨の構成でクラスターがフェンシングしている、または問題に直面している場合、XenServerサポートは調査中に推奨される構成で同じ問題を再現するよう求めることがあります。
GFS2クラスターネットワークとして使用するボンディングネットワークを作成するには:
  1. プール内のホスト間にファイアウォールがある場合は、ホストが以下のポートを使用してクラスターネットワーク上で通信できることを確認してください。
    • TCP: 8892, 8896, 21064
    • UDP: 5404, 5405
    詳細については、「XenServerが使用する通信ポート」を参照してください。
  2. プールコーディネーターとして機能させたいXenServerホストでコンソールを開きます。
  3. 以下のコマンドを使用して、ボンディングされたNICで使用するネットワークを作成します。
    xe network-create name-label=bond0
    新しいネットワークのUUIDが返されます。
  4. 以下のコマンドを使用して、ボンドで使用するPIFのUUIDを見つけます。
    xe pif-list
  5. アクティブ-アクティブモード、アクティブ-パッシブモード、またはLACPボンドモードのいずれかでボンディングされたネットワークを作成します。使用したいボンドモードに応じて、以下のいずれかのアクションを実行してください。
    • ボンドをアクティブ-アクティブモード（デフォルト）で構成するには、bond-create コマンドを使用してボンドを作成します。パラメータをコンマで区切り、新しく作成されたネットワークのUUIDと、ボンディングするPIFのUUIDを指定します。
      xe bond-create network-uuid=<network_uuid> /
          pif-uuids=<pif_uuid_1>,<pif_uuid_2>,<pif_uuid_3>,<pif_uuid_4>
      2つのNICをボンディングする場合は2つのUUIDを、4つのNICをボンディングする場合は4つのUUIDを入力します。コマンドの実行後、ボンドのUUIDが返されます。
    • ボンドをアクティブ-パッシブモードまたはLACPボンドモードで構成するには、同じ構文を使用し、オプションの mode パラメータを追加して、lacp または active-backup を指定します。
      xe bond-create network-uuid=<network_uuid> /
          pif-uuids=<pif_uuid_1>,<pif_uuid_2>,<pif_uuid_3>,<pif_uuid_4> /
          mode=balance-slb | active-backup | lacp
プールコーディネーターでボンディングされたネットワークを作成した後、他のXenServerホストをプールに参加させると、ネットワークとボンドの情報は参加するサーバーに自動的に複製されます。
詳細については、ネットワーキング を参照してください。
注:
  • XenCenter® を使用してクラスターネットワークのIPアドレスを変更するには、クラスタリングとGFS2を一時的に無効にする必要があります。
  • クラスターが稼働中でVMが実行されている間は、クラスターネットワークのボンディングを変更しないでください。この操作により、クラスター内のホストが強制的に再起動（フェンス）される可能性があります。
  • クラスタリングが有効になっている少なくとも1つのホストを含むクラスターネットワークでIPアドレスの競合（複数のホストが同じIPアドレスを持つ）がある場合、クラスターは正しく形成されず、ホストは必要に応じてフェンスできません。この問題を解決するには、IPアドレスの競合を解消してください。
プールのクラスタータイムアウト値は、クラスター内のホスト数によって異なります。プールに対する token-timeout の値を秒単位で見つけるには、次のコマンドを実行します。
xe cluster-param-get uuid=&lt;cluster_uuid> param-name=token-timeout
ネットワークボンドのフェイルオーバー時間がタイムアウト値よりも長くなる可能性がある場合、ネットワークインフラストラクチャと構成は、クラスター化されたプールをサポートするのに十分な信頼性がない可能性があります。

4. クラスター化されたプールをセットアップする

共有GFS2ストレージを使用するには、XenServerリソースプールがクラスター化されたプールである必要があります。GFS2 SRを作成する前に、プールでクラスタリングを有効にしてください。
クラスター化されたプールは、非クラスター化されたプール内のホストよりも密接に接続され、連携しているXenServerホストのプールです。クラスター内のホストは、選択されたネットワーク上で互いに常に通信を維持します。クラスター内のすべてのホストは、クラスター内のすべてのホストの状態を認識しています。このホスト連携により、クラスターはGFS2 SRのコンテンツへのアクセスを制御できます。クラスター化されたプールが常に通信状態を維持するように、クラスター内の各ホストは、クラスター内のホストの少なくとも半分（自身を含む）と常に通信している必要があります。この状態は、ホストがクォーラムを持っているとして知られています。ホストがクォーラムを持っていない場合、ハード再起動してクラスターから自身を削除します。このアクションは「フェンシング」と呼ばれます。
詳細については、クラスター化されたプールを参照してください。
クラスター化されたプールのセットアップを開始する前に、以下の前提条件が満たされていることを確認してください。
  • 3～16台のホストで構成されるプールを作成する計画を立ててください。
    可能な場合は、クラスター化されたプールで奇数台のホストを使用してください。これにより、ホストが常にクォーラムを持っているかどうかを判断できるようになります。2台のホストのプールはプール全体が自己フェンシングする可能性が高いため、クラスタリングは少なくとも3台のホストを含むプールでのみ使用することをお勧めします。
    クラスター化されたプールは、プールあたり最大16台のホストのみをサポートします。
  • クラスター化されたプール内のすべてのXenServerホストは、少なくとも2 GiBのコントロールドメインメモリを持っている必要があります。
  • クラスター内のすべてのホストは、クラスターネットワークに静的IPアドレスを使用する必要があります。
  • 既存のプールをクラスタリングする場合は、高可用性が無効になっていることを確認してください。クラスタリングが有効になった後で、高可用性を再度有効にすることができます。
xe CLIを使用してクラスター化されたプールを作成するには：
  1. 少なくとも3台のXenServerホストで構成されるリソースプールを作成します。
    プールコーディネーターではない参加する各XenServerホストで、以下の手順を繰り返します。
    1. XenServer ホストでコンソールを開きます。
    2. プールコーディネーター上で、以下のコマンドを使用して XenServer ホストをプールに参加させます。
      xe pool-join master-address=<master_address> /
          master-username=<administrators_username> /
          master-password=<password>
      master-address パラメーターの値は、プールコーディネーターである XenServer ホストの完全修飾ドメイン名に設定する必要があります。password は、プールコーディネーターのインストール時に設定された管理者パスワードである必要があります。
    詳細については、「ホストとリソースプール」を参照してください。
  2. このネットワークに属するすべての PIF について、disallow-unplug=true を設定します。
    1. 以下のコマンドを使用して、ネットワークに属する PIF の UUID を見つけます。
      xe pif-list
    2. リソースプール内の XenServer ホストで以下のコマンドを実行します。
      xe pif-param-set disallow-unplug=true uuid=<pif_uuid>
  3. プールでクラスタリングを有効にします。リソースプール内の XenServer ホストで以下のコマンドを実行します。
    xe cluster-pool-create network-uuid=<network_uuid>
    前の手順で作成したボンディングされたネットワークの UUID を指定します。

5. コントロールドメインメモリを増やす

ホストのコントロールドメインメモリが不足している場合、プールでネットワークの不安定性が発生する可能性があります。ネットワークの不安定性は、GFS2 SR を持つクラスター化されたプールに問題を引き起こす可能性があります。
クラスター化されたプールに適切な量のコントロールドメインメモリがあることを確認することが重要です。コントロールドメインメモリの量の変更とメモリ動作の監視については、「メモリ使用量」を参照してください。

6. ストレージマルチパスを構成する

クラスター化されたプールと GFS2 SR の間でストレージマルチパスが設定されていることを確認してください。
マルチパスは、冗長性のために複数のパスを介してストレージトラフィックをストレージデバイスにルーティングします。すべてのルートは、通常の操作中にアクティブなトラフィックを持つことができ、これによりスループットが向上します。
マルチパスを有効にする前に、以下の記述が真であることを確認してください。
  • イーサネットまたはファイバースイッチが、ストレージサーバー上で複数のターゲットを利用できるように構成されていること。
    例えば、特定のポータルで sendtargets を照会したiSCSIストレージバックエンドは、以下の例のように複数のターゲットを返します。
    iscsiadm -m discovery --type sendtargets --portal 192.168.0.161
    192.168.0.161:3260,1 iqn.strawberry:litchie
    192.168.0.204:3260,2 iqn.strawberry:litchie
    ただし、単一のターゲットのみを公開するアレイに対してiSCSIマルチパスを有効にするための追加設定を行うことができます。詳細については、「単一のターゲットのみを公開するアレイのiSCSIマルチパス」を参照してください。
  • iSCSIの場合のみ、コントロール ドメイン (dom0) が、マルチパスストレージで使用される各サブネット上にIPアドレスを持っていること。
    ストレージへの各パスに対してNICがあり、各NICにIPアドレスが構成されていることを確認してください。例えば、ストレージへのパスを4つにしたい場合、それぞれIPアドレスが構成された4つのNICが必要です。
  • iSCSIの場合のみ、すべてのiSCSIターゲットとイニシエーターが固有のIQNを持っていること。
  • iSCSIの場合のみ、iSCSIターゲットポートがポータルモードで動作していること。
  • HBAの場合のみ、複数のHBAがスイッチファブリックに接続されていること。
  • 可能であれば、複数の冗長スイッチを使用してください。

xe CLIを使用してマルチパスを有効にするには

SRを作成する前に、プール内のすべてのホストでマルチパスを有効にすることをお勧めします。マルチパスを有効にする前にSRを作成した場合、マルチパスを有効にするにはホストをメンテナンスモードにする必要があります。
  1. XenServerホストでコンソールを開きます。
  2. 次のコマンドを使用して、ホスト上のすべてのPBDをプラグ解除します。
    xe pbd-unplug uuid=<pbd_uuid>
    コマンド xe pbd-list を使用して、PBDのUUIDを見つけることができます。
  3. multipathing パラメーターの値を true に設定するには、次のコマンドを使用します。
    xe host-param-set uuid=<host uuid> multipathing=true
  4. マルチパスを持つシングルパスモードで実行されているホスト上に既存のSRがある場合：
    • 影響を受けるSR内の仮想ディスクを持つ実行中のゲストを移行または一時停止します。
    • 影響を受けるSRのPBDを再接続して、マルチパスを使用して再接続します。
      xe pbd-plug uuid=<pbd_uuid>
  5. これらの手順を繰り返し、プール内のすべてのホストでマルチパスを有効にします。
プール内のすべてのホストでマルチパスを有効にしてください。すべてのケーブル接続、およびiSCSIの場合、サブネット構成は各ホストの対応するNICと一致している必要があります。
詳細については、「ストレージマルチパス」を参照してください。

7. GFS2 SRを作成する

リソースプール内のすべてのXenServerホストから見えるiSCSIまたはHBA LUN上に共有GFS2 SRを作成します。GFS2でシンプロビジョニングされたLUNを使用することはお勧めしません。ただし、この構成を選択する場合は、XenServerが書き込みできるように、LUNに常に十分なスペースがあることを確認する必要があります。
クラスター化されたプールには、最大62個のGFS2 SRを追加できます。
以前にLVMでシックプロビジョニングのためにブロックベースのストレージデバイスを使用していた場合、これはXenServerによって検出されます。XenCenterは、既存のLVMパーティションを使用するか、ディスクをフォーマットしてGFS2パーティションを設定する機会を提供します。

iSCSI SRを介した共有GFS2の作成

xe CLIを使用して、iSCSI SRを介したGFS2を作成できます。
GFS2 SRのデバイス構成パラメーター：
パラメーター名 説明 必須？
provider ブロックプロバイダーの実装。この場合、iscsi。 はい
target ホストするiSCSIファイラーのIPアドレスまたはホスト名 はい
targetIQN SRをホストするiSCSIファイラーのIQNターゲット はい
SCSIid デバイスSCSI ID はい
これらのパラメーターに使用する値は、xe sr-probe-ext コマンドを使用して見つけることができます。
xe sr-probe-ext type=<type> host-uuid=<host_uuid> device-config:=<config> sm-config:=<sm_config>
  1. 以下のコマンドを実行して開始します。
    xe sr-probe-ext type=gfs2 device-config:provider=iscsi
    コマンドの出力は、追加のパラメータの入力を促し、各ステップで可能な値のリストを提供します。
  2. コマンドを繰り返し実行し、毎回新しいパラメータを追加します。
  3. コマンド出力が Found the following complete configurations that can be used to create SRs: で始まる場合、指定した xe sr-create コマンドと device-config パラメータを使用して SR を見つけることができます。
    出力例:
    Found the following complete configurations that can be used to create SRs:
    Configuration 0:
      SCSIid       : 36001405852f77532a064687aea8a5b3f
          targetIQN: iqn.2009-01.example.com:iscsi192a25d6
             target: 198.51.100.27
           provider: iscsi


    Configuration 0 extra information:
iSCSIターゲットの特定のLUN上に共有GFS2 SRを作成するには、クラスタープール内のサーバーで以下のコマンドを実行します。
xe sr-create type=gfs2 name-label="Example GFS2 SR" --shared \
   device-config:provider=iscsi device-config:targetIQN=<target_iqns> \
   device-config:target=<portal_address> device-config:SCSIid=<scsci_id>
GFS2ファイルシステムがマウントされている間にiSCSIターゲットに到達できない場合、クラスタープール内の一部のホストがハードリスタート（フェンス）する可能性があります。
iSCSI SR の操作に関する詳細については、ソフトウェア iSCSI ストレージ を参照してください。

HBA経由で共有GFS2 SRを作成する

xe CLI を使用して、HBA 経由で GFS2 SR を作成できます。
GFS2 SR のデバイス設定パラメータ:
パラメータ名 説明 必須？
provider ブロックプロバイダーの実装。この場合、hba。 はい
SCSIid デバイスSCSI ID はい
SCSIid パラメーターに使用する値は、xe sr-probe-ext コマンドを使用して見つけることができます。
xe sr-probe-ext type=<type> host-uuid=<host_uuid> device-config:=<config> sm-config:=<sm_config>
  1. まず、次のコマンドを実行します。
    xe sr-probe-ext type=gfs2 device-config:provider=hba
    コマンドの出力は、追加のパラメーターを指定するように促し、各ステップで可能な値のリストを提供します。
  2. コマンドを繰り返し、毎回新しいパラメーターを追加します。
  3. コマンド出力が Found the following complete configurations that can be used to create SRs: で始まる場合、指定した device-config パラメーターと xe sr-create コマンドを使用してSRを特定できます。
    出力例:
    Found the following complete configurations that can be used to create SRs:
    Configuration 0:
      SCSIid       : 36001405852f77532a064687aea8a5b3f
          targetIQN: iqn.2009-01.example.com:iscsi192a25d6
             target: 198.51.100.27
           provider: iscsi


    Configuration 0 extra information:
クラスター化されたプール内のサーバーで、HBAターゲットの特定のLUN上に共有GFS2 SRを作成するには、次のコマンドを実行します。
xe sr-create type=gfs2 name-label="Example GFS2 SR" --shared \
  device-config:provider=hba device-config:SCSIid=<device_scsi_id>
HBA SR の操作の詳細については、ハードウェアHBAストレージ を参照してください。

次のステップ?

GFS2環境がセットアップされたので、クォーラムを確保してクラスター化されたプールの安定性を維持することが重要です。詳細については、クラスター化されたプールの管理 を参照してください。
GFS2環境で問題が発生した場合は、クラスター化されたプールのトラブルシューティングを参照してください。
GFS2 SRは、他のSRと同様に管理できます。たとえば、ストレージアレイに容量を追加してLUNのサイズを増やすことができます。詳細については、ライブLUN拡張を参照してください。

制約事項

共有GFS2ストレージには現在、以下の制約事項があります。
  • GFS2 SRを使用するVMでは、Intellicache™はサポートされていません。
  • 他のシンプロビジョニングされたSRと同様に、GFS2 SRの使用率が100%に達すると、VMからのそれ以降の書き込みは失敗します。これらの書き込み失敗は、VM内の障害、データ破損の可能性、またはその両方につながる可能性があります。
  • SRの使用率が80%に達すると、XenCenterはアラートを表示します。このアラートについてGFS2 SRを監視し、表示された場合は適切な措置を講じてください。GFS2 SRでは、使用率が高いとパフォーマンスが低下します。SRの使用率を80%未満に保つことをお勧めします。
  • VDIがGFS2 SR上にあるVMの場合、ストレージ移行を伴うVM移行（ライブまたはオフライン）はサポートされていません。また、別の種類のSRからGFS2 SRにVDIを移行することもできません。
  • ソフトウェアFCoEトランスポートはGFS2 SRではサポートされていません（完全にオフロードされたFCoEにはHBAを使用してください）。
  • Trim/unmapはGFS2 SRではサポートされていません。
  • CHAPはGFS2 SRではサポートされていません。
  • 2 TiBを超えるVDIをVHDまたはOVA/OVFとしてエクスポートすることはできません。ただし、2 TiBを超えるVDIを持つVMはXVA形式でエクスポートできます。
  • GFS2でシンプロビジョニングされたLUNを使用することはお勧めしません。ただし、この構成を選択する場合は、XenServerが書き込みできるように、LUNに常に十分な空き容量があることを確認する必要があります。
  • GFS2 SRでSAN重複排除を使用することはお勧めしません。ただし、この構成を選択する場合は、XenServerが書き込みできるように、SANの使用状況を適切に外部監視して、常に空き容量があることを確認する必要があります。
  • GFS2ファイルシステムは100 TiBを超えることはできません。
  • プールには62個を超えるGFS2 SRを含めることはできません。
  • クラスター化されたプールは、プールあたり最大16台のホストのみをサポートします。
  • クラスター化されたプールでHAを有効にするには、ハートビートSRがGFS2 SRである必要があります。
  • クラスタートラフィックには、少なくとも2つの異なるネットワークスイッチを使用するボンディングされたネットワークを使用することを強くお勧めします。このネットワークを他の目的で使用しないでください。
  • XenCenterを使用してクラスターネットワークのIPアドレスを変更するには、クラスタリングとGFS2を一時的に無効にする必要があります。
  • クラスターが稼働中でVMが実行されている間に、クラスターネットワークのボンディングを変更しないでください。この操作により、クラスター内のホストが強制的に再起動（フェンス）される可能性があります。
  • クラスタリングが有効になっている少なくとも1つのホストを含むクラスターネットワークでIPアドレスの競合（複数のホストが同じIPアドレスを持つ）がある場合、クラスターは正しく形成されず、ホストは必要に応じてフェンスできません。この問題を解決するには、IPアドレスの競合を解消してください。