製品ドキュメント
XenServer
XenServer 9 XenServer 8.4
PDFを表示

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

August 25, 2026
寄稿者: 
X X

シンプロビジョニングは、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製品ドキュメントを参照してください。

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
<!--NeedCopy-->

    新しいネットワークのUUIDが返されます。

  4. 以下のコマンドを使用して、ボンドで使用するPIFのUUIDを見つけます。

    xe pif-list
<!--NeedCopy-->

  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>
 <!--NeedCopy-->

      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
 <!--NeedCopy-->

プールコーディネーターでボンディングされたネットワークを作成した後、他のXenServerホストをプールに参加させると、ネットワークとボンドの情報は参加するサーバーに自動的に複製されます。

詳細については、ネットワーク を参照してください。

注:

  • XenCenter® を使用してクラスターネットワークのIPアドレスを変更するには、クラスタリングとGFS2を一時的に無効にする必要があります。
  • クラスターが稼働中でVMが実行されている間は、クラスターネットワークのボンディングを変更しないでください。この操作により、クラスター内のホストが強制的に再起動（フェンス）される可能性があります。
  • クラスターネットワーク上でIPアドレスの競合（複数のホストが同じIPアドレスを持つ）があり、クラスタリングが有効になっているホストが少なくとも1つ含まれている場合、クラスターは正しく形成されず、ホストは必要に応じてフェンスできません。この問題を解決するには、IPアドレスの競合を解消してください。

プールのクラスタータイムアウト値は、クラスター内のホスト数によって異なります。プールに対する token-timeout の値を秒単位で見つけるには、次のコマンドを実行します。

xe cluster-param-get uuid=<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>
<!--NeedCopy-->

      master-address パラメーターの値は、プールコーディネーターであるXenServerホストの完全修飾ドメイン名に設定する必要があります。password は、プールコーディネーターがインストールされたときに設定された管理者パスワードである必要があります。

    詳細については、ホストとリソースプール を参照してください。

  2. このネットワークに属するすべてのPIFについて、disallow-unplug=true を設定します。

    1. 次のコマンドを使用して、ネットワークに属するPIFのUUIDを見つけます。

      xe pif-list
<!--NeedCopy-->

    2. リソースプール内のXenServerホストで次のコマンドを実行します。

      xe pif-param-set disallow-unplug=true uuid=<pif_uuid>
<!--NeedCopy-->

  3. プールでクラスタリングを有効にします。リソースプール内のXenServerホストで次のコマンドを実行します。

    xe cluster-pool-create network-uuid=<network_uuid>
<!--NeedCopy-->

    以前の手順で作成したボンディングされたネットワークの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>
<!--NeedCopy-->

    コマンド xe pbd-list を使用して、PBDのUUIDを見つけることができます。

  3. multipathing パラメーターの値を true に設定するには、次のコマンドを使用します。

    xe host-param-set uuid=<host uuid> multipathing=true
<!--NeedCopy-->

  4. 複数のパスを持つシングルパスモードで実行されているホスト上に既存のSRがある場合：

    • 影響を受けるSR内の仮想ディスクを持つ実行中のゲストを移行または一時停止します。

    • 影響を受けるSRのPBDを再接続して、マルチパスを使用して再接続します。

       xe pbd-plug uuid=<pbd_uuid>
 <!--NeedCopy-->

  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経由で共有GFS2 SRを作成する

xe CLIを使用して、iSCSI経由でGFS2 SRを作成できます。

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>
<!--NeedCopy-->

  1. 次のコマンドを実行して開始します。

    xe sr-probe-ext type=gfs2 device-config:provider=iscsi
<!--NeedCopy-->

    コマンドの出力は、追加のパラメーターを指定するように促し、各ステップで可能な値のリストを提供します。

  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:
<!--NeedCopy-->

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>
<!--NeedCopy-->

GFS2ファイルシステムがマウントされている間にiSCSIターゲットに到達できない場合、クラスタープール内の一部のホストがハードリスタート（フェンス）する可能性があります。

iSCSI SRの操作に関する詳細については、ソフトウェアiSCSIストレージを参照してください。

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

xe CLIを使用して、HBA経由のGFS2 SRを作成できます。

GFS2 SRのデバイス設定パラメーター:

パラメーター名 説明 必須？
provider ブロックプロバイダーの実装。この場合、hba。 はい
SCSIid デバイスSCSI ID はい

xe sr-probe-extコマンドを使用して、SCSIidパラメーターに使用する値を見つけることができます。

xe sr-probe-ext type=<type> host-uuid=<host_uuid> device-config:=<config> sm-config:=<sm_config>
<!--NeedCopy-->

  1. 次のコマンドを実行して開始します。

    xe sr-probe-ext type=gfs2 device-config:provider=hba
<!--NeedCopy-->

    コマンドの出力は、追加のパラメーターを指定するように促し、各ステップで可能な値のリストを提供します。

  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:
<!--NeedCopy-->

クラスター化されたプール内のサーバーで、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>
<!--NeedCopy-->

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アドレスの競合を解消してください。

シンプロビジョニングされた共有GFS2ブロックストレージ
August 25, 2026
寄稿者: 
X X
August 25, 2026
寄稿者: 
X X

この記事の概要

サイトに関するフィードバック | Your privacy choices footer linkプライバシーに関する選択肢 | プライバシーと法令 | 同意設定 | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.