Citrix Hypervisor

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

June 18, 2024

寄稿者:

X X

シンプロビジョニングは、事前にVDIの仮想サイズすべてを割り当てるのではなく、仮想ディスクにデータが書き込まれるたびにディスクストレージ領域をVDIに割り当てることによって、ストレージ領域をよりうまく利用します。シンプロビジョニングを使用すると、共有ストレージアレイに必要な領域と総所有コスト（TCO）を大幅に削減できます。

共有ブロックストレージのシンプロビジョニングは、次の場合に特に役立ちます：

領域の使用効率を高める必要がある場合。イメージが散在し密に割り当てられていない場合。
ストレージアレイ上の1秒あたりの入出力操作数を減らす必要がある場合。GFS2ストレージリポジトリは、共有ブロックストレージ上のストレージ読み取りキャッシュをサポートする、一級のストレージリポジトリです。
複数の仮想マシンで基本イメージを共用する場合。共用することで個々の仮想マシンのイメージは限られた領域を有効活用できます。
スナップショットを使用する場合で、各スナップショットがイメージであり、各イメージが散在する場合。
2TiBを超えるサイズのVDIを作成する場合。GFS2ストレージリポジトリは、最大16TiBのVDIをサポートします。
お使いのストレージはNFSまたはSMB3をサポートしておらず、ブロックストレージのみをサポートしています。ストレージがNFSまたはSMB3をサポートしている場合は、GFS2の代わりにそれらの種類のストレージリポジトリを使用することをお勧めします。
ストレージはLUNのシンプロビジョニングをサポートしていません。ストレージがシンプロビジョニングLUNを実行している場合、GFS2と組み合わせるときに問題が発生し、領域が不足する可能性があります。GFS2とシンプロビジョニングLUNを組み合わせても、メリットは期待できないため、お勧めできません。

注：

クラスター化ネットワークが非管理VLAN上にある場合、クラスター化プール上でホストを追加または削除できないという既知の問題があるため、GFS2ストレージリポジトリをVLANで使用しないことをお勧めします。

この種類のストレージリポジトリでは、iSCSIまたはHBA LUN上に作成されたファイルシステムと同様にディスクが表示されます。GFS2ストレージリポジトリに保存されているVDIは、QCOW2イメージ形式で保存されます。

この記事では、xe CLIを使用してGFS2環境をセットアップする方法について説明します。XenCenterを使用してGFS2環境をセットアップするには、XenCenter製品ドキュメントを参照してください。

1. GFS2環境を計画する

データ損失のリスクなしに共有ブロックストレージ上でのシンプロビジョニングのメリットを提供するには、プールが高いレベルで信頼性と接続性を提供する必要があります。GFS2を使用するリソースプールのホスト同士が相互に高い信頼性をもって通信できる必要があります。これを実現するため、Citrix Hypervisorでは、クラスター化されたプールをGFS2ストレージリポジトリと連動させることが要求されます。また、できるだけ高い回復性と冗長性を提供できるように、環境の設計とCitrix Hypervisor機能の設定を行うこともお勧めします。

GFS2ストレージリポジトリと連動するようにCitrix Hypervisorプールを設定する前に、理想的なGFS2環境を実現するための以下の必須事項と推奨事項を確認してください：

推奨： 冗長なネットワークインフラストラクチャを構成する。
推奨： 専用のボンディングネットワークを作成する
必須： クラスター化されたプールを設定する
オプション コントロールドメインのメモリを増やす
推奨： ストレージのマルチパスを設定する
必須： GFS2ストレージリポジトリを作成する

GFS2ストレージリポジトリを使用したクラスター化されたプールは、他の種類のプールやストレージリポジトリとはいくつかの動作が異なります。詳しくは、「制約」を参照してください。

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

ボンディングネットワークは、2つ以上のネットワークインターフェイスカードをリンクして、ネットワークトラフィック用の単一チャネルを作成します。クラスター化されたプールのトラフィックには、ボンディングネットワークを使用することをお勧めします。ただし、ボンディングネットワークを設定する前に、ネットワークハードウェア構成がボンディングネットワークの冗長性を促進するものであることを確認してください。組織や環境に合わせて、これらの推奨事項をできるだけ多く実装することを検討します。

以下のベストプラクティスにより、ネットワークスイッチに影響を与える可能性のあるソフトウェア、ハードウェア、または電源の障害に対する回復性が向上します：

同じスイッチ上のポートだけでなく、ボンディングネットワークで使用できる別の物理ネットワークスイッチがあることを確認してください。
個々のスイッチが、別々の独立した配電ユニット（Power Distribution Unit：PDU）から電力を引き出すようにします。
可能であれば、データセンターで、PDUを給電のさまざまなフェーズに配置するか、さまざまな電力会社が提供する給電にも配置します。
電源障害が発生した場合に、ネットワークスイッチやサーバーが引き続き動作できるように、または、正常なシャットダウンを実行できるように、無停電電源装置を使用することも検討してください。

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

クラスター化されたプールのホスト同士が相互に高い信頼性で通信できることを確認する必要があります。このプールトラフィック用にボンディングネットワークを作成すると、クラスター化されたプールの回復性が向上します。

ボンディングネットワークは、2つ以上のNIC間にボンディングを作成します。このボンディングは、クラスター化されたプールがクラスターのハートビートトラフィックに使用できる単一の高性能チャネルとして機能します。このボンディングネットワークは他のトラフィックに使用しないことを強くお勧めします。管理トラフィックに使用するネットワークは別個のネットワークとしてこのプールに作成してください。

警告：

この推奨事項に従わない場合は、クラスター管理ネットワークパケットが失われるリスクが高くなります。クラスター管理ネットワークパケットが失われると、クラスター化プールがクォーラムを失い、プール内の一部またはすべてのホストが自己隔離される可能性があります。

クラスターが隔離されているか、この推奨されていない構成の問題が発生している場合、サポートが調査の過程で同じ問題を推奨構成で再現するよう依頼する場合があります。

ボンディングネットワークを作成して、クラスタリングネットワークとして使用するには：

プール内のホスト間にファイアウォールがある場合は、ホスト同士が以下のポートを使用してクラスターネットワーク上で通信できることを確認してください：
- TCP：8892、8896、21064
- UDP：5404、5405
詳しくは、「Citrix Hypervisorで使用される通信ポート」を参照してください。
プールマスターとして機能させるCitrix Hypervisorサーバーでコンソールを開きます。
次のコマンドを使用して、NICボンディングで使用するネットワークを作成します：
```
xe network-create name-label=bond0

```
これにより、新しいネットワークのUUIDが返されます。
次のコマンドを使用して、ボンディングに使用するPIFのUUIDを見つけます：
```
xe pif-list

```
アクティブ/アクティブモード、アクティブ/パッシブモード、または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>
 
```
  ボンディングを構成するNICの数に応じて、2つまたは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
 
```

プールマスターでボンディングしたネットワークを作成した後、他のCitrix Hypervisorサーバーをプールに追加すると、ネットワークとボンディングの情報が自動的に追加するサーバーに複製されます。

詳しくは、「ネットワーク」を参照してください。

注：

XenCenterを使用してクラスターネットワークのIPアドレスを変更するには、クラスタリングとGFS2を一時的に無効にする必要があります。

クラスターが稼働中で、クラスターに実行中の仮想マシンがある間は、クラスタリングネットワークのボンディングを変更しないでください。この操作により、クラスター内のホストがハード再起動（隔離）される可能性があります。

クラスタリングが有効になっているホストが少なくとも1つ含まれるクラスタリングネットワーク上で、IPアドレスの競合（同じIPアドレスを持つホストが複数存在）が発生した場合、クラスタは正しく形成されず、必要なときにホストが隔離できなくなります。この問題を解決するには、IPアドレスの競合を解決します。

アクティブ/パッシブボンディングネットワークのフェイルオーバー時間をテストするには、次の手順を実行します：

アクティブ/パッシブモードを使用するボンディングネットワークの場合、アクティブリンクに障害が発生すると、パッシブリンクがアクティブになる間にネットワークリンクが切断され、フェイルオーバー期間が発生します。アクティブ/パッシブボンディングネットワークのフェイルオーバーにかかる時間がクラスターのタイムアウトよりも長い場合、クラスター化プール内の一部またはすべてのホストが引き続き隔離される可能性があります。

次のいずれかの方法を使用してネットワークを強制的にフェイルオーバーすることで、ボンディングされたネットワークのフェイルオーバー時間をテストできます：

ネットワークケーブルを物理的に引き抜く
1つのネットワークリンク上のスイッチポートを無効にする

テストを何度も繰り返して、結果が一貫していることを確認します。

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

xe cluster-param-get uuid=<cluster_uuid> param-name=token-timeout

フェイルオーバー時間がタイムアウト値よりも長くなる可能性がある場合は、ネットワークインフラストラクチャと構成の信頼性がクラスター化プールをサポートするのに十分ではない可能性があります。

4. クラスター化されたプールを設定する

共有GFS2ストレージを使用するには、Citrix Hypervisorのリソースプールがクラスター化されたプールである必要があります。GFS2ストレージリポジトリを作成する前に、プールでクラスタリングを有効にしてください。

クラスター化プールは、クラスター化されていないプールのホストよりも密接に接続され協調する、Citrix Hypervisorサーバーのプールです。クラスター内のホストは、選択したネットワーク上で互いに一定の通信を維持します。クラスター内のすべてのホストは、クラスター内のすべてのホストの状態を認識しています。このホスト協調により、クラスターはGFS2ストレージリポジトリのコンテンツへのアクセスを制御できます。クラスター化プールが常に通信状態を維持できるようにするには、クラスター内の各ホストが、クラスター内のホストの少なくとも半分（自身を含む）と常に通信している必要があります。この状態は、クォーラムを持つホストと呼ばれます。ホストにクォーラムがない場合、ホストはハード再起動され、クラスターから削除されます。このアクションは「フェンス（隔離）」と呼ばれます。

詳しくは、「クラスター化プール」を参照してください。

クラスター化プールの設定を開始する前に、次の前提条件が満たされていることを確認してください：

3～16台のホストから成るプールの作成を計画します。

可能な場合は、クラスター化されたプールでは奇数のホストを使用します。これにより、ホストがクォーラムを持っているかどうかを常に判断できるようになります。クラスタリングを使用するのは、プールが3つ以上のホストを含む場合だけにすることをお勧めします。これは、2つのホストを含むプールではプール全体の自己隔離で問題が発生しやすいためです。

クラスター化プールでは、プールあたり16台までのホストのみがサポートされます。
クラスター化プール内のすべてのCitrix Hypervisorサーバーには、少なくとも2GiBのコントロールドメインメモリが必要です。
クラスター内のすべてのホストは、クラスターネットワークに静的IPアドレスを使用する必要があります。
既存のプールをクラスタリングする場合は、高可用性が無効になっていることを確認してください。クラスタリングが有効になった後、高可用性を再度有効にできます。

xe CLIを使用してクラスター化プールを作成するには、以下の手順を実行します：

少なくとも3台のCitrix Hypervisorサーバーのリソースプールを作成します。

プールマスターではないでCitrix Hypervisorの各参加サーバーで、次の手順を繰り返します：
1. Citrix Hypervisorサーバーのコンソールを開きます。
2. 次のコマンドを使用して、Citrix Hypervisorサーバーをプールマスターのプールに参加させます：
```
xe pool-join master-address=<master_address> /
    master-username=<administrators_username> /
    master-password=<password>

```
  master-addressパラメーターの値は、プールマスターであるCitrix Hypervisorサーバーの完全修飾ドメイン名に設定する必要があります。passwordにはプールマスターのインストール時に設定した管理者パスワードを指定します。
詳しくは、「ホストとリソースプール」を参照してください。
このネットワークに属するすべてのPIFについて、disallow-unplug=trueを設定します。
1. 次のコマンドを使用して、ネットワークに属するPIFのUUIDを見つけます：
```
xe pif-list

```
2. リソースプール内のCitrix Hypervisorサーバーで次のコマンドを実行します：
```
xe pif-param-set disallow-unplug=true uuid=<pif_uuid>

```
プールでクラスタリングを有効にします。リソースプール内のCitrix Hypervisorサーバーで次のコマンドを実行します：
```
xe cluster-pool-create network-uuid=<network_uuid>

```
前の手順で作成したボンディングしたネットワークのUUIDを入力します。

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

ホスト上のコントロールドメインのメモリが不足すると、プールのネットワークが不安定になる可能性があります。ネットワークが不安定になることにより、GFS2ストレージリポジトリを含むクラスター化プールに問題が発生する可能性があります。

クラスター化プールに、適切な量のコントロールドメインのメモリがあることを確認することが重要です。コントロールドメインのメモリの量を変更し、メモリの動作を監視する方法については、「メモリ使用率」を参照してください。

6. ストレージのマルチパスを設定する

クラスター化プールとGFS2ストレージリポジトリの間にストレージのマルチパスが設定されていることを確認してください。

マルチパスは、ストレージトラフィックを、冗長性を持たせるために、複数のパスを介してストレージデバイスにルーティングします。通常の運用中は、すべてのルートにアクティブなトラフィックを分散することで、スループットを向上させることができます。

マルチパスを有効にする前に、以下の事項を確認してください：

イーサネットまたはファイバースイッチは、ストレージサーバー上で複数のターゲットに可用性を持たせることができるように構成されています。

たとえば、iSCSIストレージバックエンドの特定のポータルに対してsendtargetsを照会した場合、以下のように複数のターゲットが返されます：
```
  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を使用してマルチパスを有効にするには

ストレージリポジトリを作成する_前_に、プール内のすべてのホストに対してマルチパスを有効にすることをお勧めします。マルチパスを有効にする前にストレージリポジトリを作成する場合は、ホストを保守モードにして、マルチパスを有効にする必要があります。

Citrix Hypervisorサーバーのコンソールを開きます。
次のコマンドを使用して、ホスト上のすべてのPBDをアンプラグします：
```
xe pbd-unplug uuid=<pbd_uuid>

```
コマンドxe pbd-listを使用して、PBDのUUIDを見つけることができます。
次のコマンドを使用して、multipathingパラメーターの値をtrueに設定します：
```
xe host-param-set uuid=<host uuid> multipathing=true

```
ホスト上でシングルパスモードで動作しているストレージリポジトリのマルチパスを有効にするには、次の操作を行います。
- そのストレージリポジトリ上の仮想ディスクを使用している、実行中の仮想マシンを移行または一時停止します。
- そのストレージリポジトリのPBDをマルチパスで再接続するために、再プラグします：
```
 xe pbd-plug uuid=<pbd_uuid>
 
```
プール内のすべてのホストでマルチパスを有効にするために、これらの手順を繰り返します。

プール内のすべてのホストでマルチパスを有効にしてください。実際のケーブル接続やサブネット設定（iSCSIの場合）は、各ホスト上のNICと一致している必要があります。

詳しくは、「ストレージのマルチパス」を参照してください。

7. GFS2ストレージリポジトリを作成する

リソースプール内のすべてのCitrix Hypervisorホストが認識できるiSCSIまたはHBA LUN上に、共有GFS2ストレージリポジトリを作成します。GFS2でシンプロビジョニングされたLUNを使用することはお勧めしません。ただし、それでもこの構成を選択する場合は、Citrix Hypervisorが書き込むのに十分な領域がLUNにあることを常に確認する必要があります。

クラスター化されたプールには最大62個のGFS2ストレージリポジトリを追加できます。

以前にLVMによるシックプロビジョニングにブロックベースのストレージデバイスを使用したことがある場合、これがCitrix Hypervisorによって検出されます。XenCenterを使用すると、既存のLVMパーティションを使用するか、ディスクをフォーマットしてGFS2パーティションをセットアップすることができます。

iSCSI経由の共有GFS2ストレージリポジトリを作成する

XenCenterを使用すると、iSCSIストレージリポジトリ上にGFS2を作成できます。詳しくは、XenCenter製品ドキュメントの「ソフトウェアiSCSIストレージ」を参照してください。

または、xe CLIを使用してiSCSIストレージリポジトリ上にGFS2を作成することもできます。

次の表は、GFS2ストレージリポジトリ用のdevice-configパラメーターの一覧です：

パラメーター名	説明	必須?
`provider`	ブロックプロバイダ実装。この場合は、`iscsi`。	はい
`target`	ホストするiSCSIファイラのIPアドレスまたはホスト名	はい
`targetIQN`	ストレージリポジトリをホストする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-->

次のコマンドを実行して起動します：
```
xe sr-probe-ext type=gfs2 device-config:provider=iscsi

```
コマンドからの出力では、追加のパラメーターを指定するように求められ、各ステップで使用できる値のリストが示されます。
このコマンドを繰り返して、毎回新しいパラメーターを追加します。

コマンド出力がFound the following complete configurations that can be used to create SRs:で始まる場合、xe sr-createコマンドとdevice-configパラメーターを指定、使用してストレージリポジトリを格納できます。

出力例：

ストレージリポジトリの作成に使用できる次の完全な構成が見つかりました。
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ストレージリポジトリを作成するには、クラスター化プール内のサーバーで次のコマンドを実行します：

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ストレージリポジトリの操作について詳しくは、「ソフトウェアiSCSIのサポート」を参照してください。

HBAストレージリポジトリ上の共有GFS2を作成する

XenCenterを使用すると、HBAストレージリポジトリ上にGFS2を作成できます。詳しくは、XenCenter製品ドキュメントの「ハードウェアHBAストレージ」を参照してください。

または、xe CLIを使用してHBAストレージリポジトリ上にGFS2を作成することもできます。

次の表は、GFS2ストレージリポジトリ用のdevice-configパラメーターの一覧です：

パラメーター名	説明	必須?
`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-->

次のコマンドを実行して起動します：
```
xe sr-probe-ext type=gfs2 device-config:provider=hba

```
コマンドからの出力では、追加のパラメーターを指定するように求められ、各ステップで使用できる値のリストが示されます。
このコマンドを繰り返して、毎回新しいパラメーターを追加します。

出力例：

ストレージリポジトリの作成に使用できる次の完全な構成が見つかりました。
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ストレージリポジトリを作成するには、クラスター化プール内のサーバーで次のコマンドを実行します：

xe sr-create type=gfs2 name-label="Example GFS2 SR" --shared \
  device-config:provider=hba device-config:SCSIid=<device_scsi_id>
<!--NeedCopy-->

HBAストレージリポジトリの操作について詳しくは、「ハードウェアホストバスアダプタ」を参照してください。

次の操作

GFS2環境のセットアップが完了したので、クラスター化プールにクォーラムがあることを確認して、クラスター化プールの安定性を維持することが重要です。詳しくは、「クラスター化プールを管理する」を参照してください。

GFS2環境で問題が発生した場合は、「クラスター化プールのトラブルシューティング」を参照してください。

GFS2ストレージリポジトリは、他のストレージリポジトリと同じ方法で管理できます。たとえば、ストレージアレイに容量を追加して、LUNのサイズを増やすことができます。詳しくは、「LUNのライブ拡張」を参照してください。

制約

現在、共有GFS2ストレージには次の制約があります：

シンプロビジョニングされたSRと同様、GFS2 SRの使用率が100%になると、仮想マシンからのそれ以上の書き込みは失敗します。これらの書き込みの失敗は、仮想マシン内の障害、データの破損、またはその両方につながる可能性があります。
XenCenterは、SRの使用量が80%に増加するとアラートを表示します。GFS2 SRにこのアラートが表示されていないか監視を行い、表示された場合は適切な処置を行ってください。GFS2 SRでは、使用率が高くなるとパフォーマンスが低下します。SRの使用量を80%以下に保つことをお勧めします。
VDIがGFS2ストレージリポジトリ上にある仮想マシンでは、ストレージ移行（ライブまたはオフライン）による仮想マシンの移行はサポートされていません。また、VDIを別のタイプのストレージリポジトリからGFS2ストレージリポジトリに移行することもできません。
ソフトウェアFCoEトランスポートはGFS2ストレージリポジトリではサポートされていません（完全にオフロードされたFCoEの場合はHBAを使用してください）。
トリミングとマッピング解除は、GFS2ストレージリポジトリではサポートされていません。
CHAP（Challenge Handshake Authentication Protocol：チャレンジハンドシェイク認証プロトコル）は、GFS2ストレージリポジトリではサポートされていません。
MCSフルクローン仮想マシンでは、GFS2ストレージリポジトリは使用できません。
同じMCSカタログで複数のGFS2ストレージリポジトリを使用することはサポートされていません。
GFS2ストレージリポジトリおよびこれらのストレージリポジトリ上のディスクでは、パフォーマンス測定値は利用できません。
変更ブロック追跡は、GFS2 SRに格納されているVDIではサポートされません。
2TiBを超えるVDIをVHDまたはOVA（Open Virtual Appliance）やOVF（オープン仮想化フォーマット）でエクスポートすることはできません。ただし、VDIが2TiBを超える仮想マシンは、XVA形式でエクスポートできます。
GFS2でシンプロビジョニングされたLUNを使用することはお勧めしません。ただし、それでもこの構成を選択する場合は、Citrix Hypervisorが書き込むのに十分な領域がLUNにあることを常に確認する必要があります。
GFS2ストレージリポジトリでSAN重複排除を使用することはお勧めしません。ただし、この構成を選択する場合は、Citrix Hypervisorが書き込むための領域が常に確保されるように、SAN使用率に対して適切な外部監視機能を使用する必要があります。
GFS2ファイルシステムを100TiBより大きくすることはできません。
プール内に62を超えるGFS2ストレージリポジトリを含めることはできません。
クラスター化プールでは、プールあたり16台までのホストのみがサポートされます。
クラスター化プールで高可用性を有効にするには、ハートビートストレージリポジトリはGFS2ストレージリポジトリである必要があります。
クラスタートラフィックの場合、少なくとも2つの異なるネットワークスイッチを使用するボンディングネットワークを使用することを強くお勧めします。このネットワークを他の目的に使用しないでください。
XenCenterを使用してクラスターネットワークのIPアドレスを変更するには、クラスタリングとGFS2を一時的に無効にする必要があります。
クラスターが稼働中で、クラスターに実行中の仮想マシンがある間は、クラスタリングネットワークのボンディングを変更しないでください。この操作により、クラスター内のホストがハード再起動（隔離）される可能性があります。
クラスタリングが有効になっているホストが少なくとも1つ含まれるクラスタリングネットワーク上で、IPアドレスの競合（同じIPアドレスを持つホストが複数存在）が発生した場合、クラスタは正しく形成されず、必要なときにホストが隔離できなくなります。この問題を解決するには、IPアドレスの競合を解決します。

このコンテンツの正式なバージョンは英語で提供されています。Cloud Software Groupドキュメントのコンテンツの一部は、お客様の利便性のみを目的として機械翻訳されています。Cloud Software Groupは機械翻訳されたコンテンツを管理していないため、誤り、不正確な情報、不適切な用語が含まれる場合があります。英語の原文から他言語への翻訳について、精度、信頼性、適合性、正確性、またはお使いのCloud Software Group製品またはサービスと機械翻訳されたコンテンツとの整合性に関する保証、該当するライセンス契約書またはサービス利用規約、あるいはCloud Software Groupとのその他すべての契約に基づき提供される保証、および製品またはサービスのドキュメントとの一致に関する保証は、明示的か黙示的かを問わず、かかるドキュメントの機械翻訳された範囲には適用されないものとします。機械翻訳されたコンテンツの使用に起因する損害または問題について、Cloud Software Groupは責任を負わないものとします。

この情報は役に立ちましたか?

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

June 18, 2024

寄稿者:

X X

June 18, 2024

寄稿者:

X X

この情報は役に立ちましたか?