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

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

August 25, 2026
寄稿者: 
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アドレスが構成されたNICが4つ必要です。

  • 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 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>
<!--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 はい

SCSIid パラメーターに使用する値は、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=hba
<!--NeedCopy-->

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

  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:
<!--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
August 25, 2026
寄稿者: 
X

この記事の概要

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