XenServer

GFS2 クラスタプール

GFS2 クラスタリングは、GFS2 SR を使用するリソースプールに必要となる追加機能を提供します。GFS2 の詳細については、ストレージの構成 を参照してください。

GFS2 クラスターは、非クラスター化プール内のホストよりも密接に接続され、連携している最大 16 台の XenServer® ホストで構成されるプールです。GFS2 クラスター内のホストは、選択されたネットワーク上で相互に常に通信を維持します。GFS2 クラスター内のすべてのホストは、GFS2 クラスター内の各ホストの状態を認識しています。このホスト連携により、GFS2 クラスターは GFS2 SR のコンテンツへのアクセスを制御できます。

注:

GFS2 クラスタリング機能は、GFS2 SR を含むプールにのみメリットがあります。プールに GFS2 SR が含まれていない場合は、プールで GFS2 クラスタリングを有効にしないでください。

クォーラム

GFS2 クラスター内の各ホストは、常に GFS2 クラスター内のホストの過半数 (自身を含む) と通信している必要があります。この状態は、ホストがクォーラムを保持している状態として知られています。ホストがクォーラムを保持していない場合、そのホストは自己フェンスします。

最初にクォーラムを確立するために通信している必要があるホストの数は、GFS2 クラスターがクォーラムを維持するために必要なホストの数とは異なる場合があります。

次の表に、この動作をまとめます。n の値は、GFS2 クラスター化プール内のホストの総数です。

  クォーラムを確立するために必要なホストの数 クォーラムを維持するために必要なホストの数
プール内のホスト数が奇数の場合 (n+1)/2 (n+1)/2
プール内のホスト数が偶数の場合 (n/2)+1 n/2

GFS2クラスタープールの場合、GFS2クラスターのis-quorateパラメーターをクエリすることで、プールがクォーラムを持っているかどうかを確認できます。

xe cluster-list params=is-quorate uuid=<cluster_id>

GFS2クラスター内で稼働中のホスト数を表示するには、次のコマンドを実行します。

xe cluster-list params=live-hosts uuid=<cluster_id>

GFS2クラスターがクォーラムを達成するために必要な稼働中のホスト数を表示するには、次のコマンドを実行します。

xe cluster-list params=quorum uuid=<cluster_id>

GFS2クラスターが作成されると、稼働中のホスト数はこの値以上である必要があります。クォーラムを維持するには、GFS2クラスターに奇数または偶数個のホストが含まれているかどうかに応じて、必要なホスト数がこのコマンドによって返される値とは異なる場合があります。

奇数ホストプール

奇数ホストプールでクォーラム値を達成するには、GFS2クラスター内のホスト総数に1を加えた数の半分、つまり (n+1)/2 が必要です。これは、プールがクォーラム状態を維持するために接続可能である必要がある最小ホスト数でもあります。

例えば、5ホストのGFS2クラスタープールでは、GFS2クラスターがアクティブになり、クォーラム状態を維持するためには、3つのホストが接続可能である必要があります[(5+1)/2 = 3]。

可能な限り、GFS2クラスタープールでは奇数個のホストを使用することをお勧めします。これは、ホストが常にクォーラムセットを持っているかどうかを判断できることを保証するためです。

偶数ホストプール

偶数ホストのGFS2クラスタープールがコールドスタートから起動する場合、ホストがクォーラムを持つ前に、(n/2)+1個のホストが利用可能である必要があります。ホストがクォーラムを持つと、GFS2クラスターはアクティブになります。

しかし、アクティブな偶数ホストプールは、接続可能なホスト数が少なくともn/2であれば、クォーラム状態を維持できます。その結果、偶数個のホストを持つ稼働中のGFS2クラスターが正確に半分に分割される可能性があります。稼働中のGFS2クラスターは、GFS2クラスターのどちらの半分がセルフフェンスを行い、どちらの半分がクォーラムを持つかを決定します。GFS2クラスターが分割される前にアクティブと見なされた最も低いIDを持つノードを含むGFS2クラスターの半分はアクティブなままとなり、GFS2クラスターのもう半分はセルフフェンスを行います。

例えば、4ホストのGFS2クラスタープールでは、GFS2クラスターがアクティブになるためには、3つのホストが接続可能である必要があります[4/2 + 1 = 3]。GFS2クラスターがアクティブになった後、クォーラム状態を維持するには、2つのホストのみが接続可能である必要があります[4/2 = 2]。そして、そのホストセットには、アクティブであることが知られている最も低いノードIDを持つホストが含まれている必要があります。

セルフフェンシング

ホストがクォーラムを持っていないことを検出すると、数秒以内に自己フェンスします。ホストが自己フェンスすると、すぐに再起動します。ホストがハードシャットダウンを実行するため、ホスト上で実行されているすべてのVMはすぐに停止します。高可用性を使用するGFS2クラスタープールでは、XenServerは他のプールメンバー上の再起動構成に従ってVMを再起動します。自己フェンスしたホストは再起動し、GFS2クラスターへの再参加を試みます。

GFS2クラスター内の稼働中のホスト数がクォーラム値を下回ると、残りのすべてのホストはクォーラムを失います。

理想的なシナリオでは、GFS2クラスタープールは常にクォーラムに必要な数よりも多くの稼働中のホストを持ち、XenServerがフェンスすることはありません。このシナリオの可能性を高めるために、GFS2クラスタープールをセットアップする際には、以下の推奨事項を考慮してください。

  • ハードウェアの冗長性が十分に確保されていることを確認してください。

  • GFS2クラスターネットワークには、専用のボンディングネットワークを使用してください。ボンディングされたNICが同じL2セグメント上にあることを確認してください。詳細については、ネットワークを参照してください。

  • プールとGFS2 SRの間でストレージマルチパスを構成してください。詳細については、ストレージマルチパスを参照してください。

GFS2クラスタープールの作成

開始する前に、以下の前提条件が満たされていることを確認してください。

  • GFS2クラスタープール内のすべてのXenServerホストは、少なくとも2 GiBのコントロールドメインメモリを持っている必要があります。

    環境によっては、ホストがこれよりも多くのコントロールドメインメモリを必要とする場合があります。ホストのコントロールドメインメモリが不足している場合、プールでネットワークの不安定性が発生する可能性があります。ネットワークの不安定性は、GFS2 SRを持つGFS2クラスタープールに問題を引き起こす可能性があります。コントロールドメインメモリの量を変更し、メモリの動作を監視する方法については、メモリ使用量を参照してください。

  • GFS2クラスター内のすべてのホストは、GFS2クラスターネットワークに静的IPアドレスを使用する必要があります。

  • 2つのホストからなるプールはプール全体の自己フェンスに敏感であるため、GFS2クラスタリングは少なくとも3つのホストを含むプールでのみ使用することをお勧めします。

  • GFS2クラスタープールは、プールあたり最大16ホストのみをサポートします。

  • プール内のホスト間にファイアウォールがある場合は、ホストが以下のポートを使用してGFS2クラスターネットワーク上で通信できることを確認してください。
    • TCP: 8892, 8896, 21064
    • UDP: 5404, 5405

    詳細については、XenServer で使用される通信ポートを参照してください。

  • 既存のプールにGFS2クラスタリングを追加する場合は、高可用性が無効になっていることを確認してください。GFS2クラスタリングが有効になった後で、高可用性を再度有効にできます。

  • GFS2クラスタープールには、他のトラフィックには使用されないボンディングネットワークを使用することを強くお勧めします。

必要に応じて、XenCenterを使用してプールにGFS2クラスタリングを設定できます。詳細については、XenCenter製品ドキュメントを参照してください。

xe CLIを使用してGFS2クラスタープールを作成するには、次の手順を実行します。

  1. GFS2クラスターネットワークとして使用するボンディングネットワークを作成します。

    注:

    GFS2クラスタープールには専用のボンディングネットワークを使用することを強くお勧めします。このネットワークを他のトラフィックには使用しないでください。

    プールコーディネーターにするXenServerホストで、次の手順を実行します。

    1. XenServerホストでコンソールを開きます。

    2. 次のコマンドを使用して、ボンディングされたNICで使用するためのネットワークを作成します。

      xe network-create name-label=bond0
      <!--NeedCopy-->
      

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

    3. 次のコマンドを使用して、ボンディングで使用するPIFのUUIDを見つけます。

      xe pif-list
      <!--NeedCopy-->
      
    4. アクティブ/アクティブモード、アクティブ/パッシブモード、または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ホストをプールに参加させると、ネットワークとボンドの情報は参加するサーバーに自動的に複製されます。

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

  2. 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は、プールコーディネーターがインストールされたときに設定された管理者パスワードである必要があります。

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

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

    1. 以下のコマンドを使用して、ネットワークに属するPIFのUUIDを検索します。

      xe pif-list
      <!--NeedCopy-->
      
    2. リソースプール内のXenServerホストで以下のコマンドを実行します。

      xe pif-param-set disallow-unplug=true uuid=<pif_uuid>
      <!--NeedCopy-->
      
  4. プールでGFS2クラスタリングを有効にします。リソースプール内のXenServerホストで以下のコマンドを実行します。

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

    以前の手順で作成したボンディングされたネットワークのUUIDを指定します。

GFS2クラスタリングを無効にする

GFS2クラスタリングを無効にできます。GFS2クラスタリングを無効にした後も、プールは存在し続けますが、GFS2クラスタリングされなくなり、GFS2 SRを使用できなくなります。

GFS2クラスタリングを無効にするには、次のコマンドを実行します。

xe cluster-pool-destroy cluster-uuid=<uuid>

GFS2クラスタープールを管理する

GFS2クラスタープールを管理する際、以下の方法により、プールがクォーラムを失うリスクを軽減できます。

GFS2クラスタープールでホストを追加または削除する

GFS2クラスタープールでホストを追加または削除する際は、GFS2クラスター内のすべてのホストがオンラインであることを確認してください。

XenCenterを使用して、GFS2クラスタープールでホストを追加または削除できます。詳細については、「プールへのサーバーの追加」および「プールからのサーバーの削除」を参照してください。

xe CLIを使用して、GFS2クラスタープールでホストを追加または削除することもできます。詳細については、「xe CLIを使用してプールにホストを追加する」および「リソースプールからXenServerホストを削除する」を参照してください。

ホストが正常にシャットダウンされていることを確認する

ホストが正常にシャットダウンされると、再起動されるまで一時的にGFS2クラスターから削除されます。ホストがシャットダウンされている間、GFS2クラスターのクォーラムにはカウントされません。ホストの不在によって、他のホストがクォーラムを失うことはありません。詳細については、「XenServerホストをシャットダウンする」を参照してください。

ただし、ホストが強制的にまたは予期せずシャットダウンされた場合、オフラインになる前にGFS2クラスターから削除されません。このホストはGFS2クラスターのクォーラム値にカウントされます。そのシャットダウンにより、他のホストがクォーラムを失う可能性があります。

ホストを強制的にシャットダウンする必要がある場合は、まずGFS2クラスターにいくつのライブホストがあるかを確認します。これはコマンドcorosync-quorumtoolで実行できます。コマンド出力では、ライブホストの数はTotal votes:の値であり、クォーラムを維持するために必要なライブホストの数はQuorum:の値です。

  • ライブホストの数がクォーラムを維持するために必要なホストの数と同じである場合、ホストを強制的にシャットダウンしないでください。そうすると、GFS2クラスター全体がフェンスされます。

    代わりに、他のホストを回復し、強制的にホストをシャットダウンする前に、稼働中のホスト数を増やしてください。

  • 稼働中のホスト数が、クォーラムを維持するために必要なホスト数に近い場合、ホストを強制的にシャットダウンできます。ただし、これにより、プール内の他のホストに問題が発生した場合、GFS2クラスターが完全にフェンシングされるリスクが高まります。

GFS2クラスターの回復力を高めるため、シャットダウンしたホストはできるだけ早く再起動するように常に努めてください。

メンテナンスモードの使用

ホストがクォーラムを失う可能性のある操作をホストに対して行う前に、そのホストをメンテナンスモードにしてください。ホストがメンテナンスモードの場合、実行中のVMはプール内の別のホストに移行されます。また、そのホストがプールコーディネーターであった場合、その役割はプール内の別のホストに引き継がれます。メンテナンスモードのホストが自己フェンシングするような操作を行った場合でも、VMが失われたり、プールへのXenCenter®接続が失われたりすることはありません。

メンテナンスモードのホストも、GFS2クラスターのクォーラム値にカウントされます。

GFS2クラスタープールの一部であるホストのIPアドレスは、そのホストがメンテナンスモードの場合にのみ変更できます。ホストのIPアドレスを変更すると、そのホストはGFS2クラスターから離脱します。IPアドレスが正常に変更されると、ホストはGFS2クラスターに再参加します。ホストがGFS2クラスターに再参加した後、メンテナンスモードを解除できます。

自己フェンシングした、またはオフラインのホストを回復する

自己フェンシングしたホストを回復することが重要です。これらのGFS2クラスターメンバーがオフラインの間、それらはGFS2クラスターのクォーラム数にカウントされ、連絡可能なGFS2クラスターメンバーの数を減少させます。この状況は、その後のホスト障害がGFS2クラスターのクォーラム喪失と完全シャットダウンを引き起こすリスクを高めます。

GFS2クラスターにオフラインのホストがあると、特定の操作を実行できなくなります。GFS2クラスタープールでは、プールメンバーシップの変更が成功する前に、プール内のすべてのメンバーがその変更に同意する必要があります。GFS2クラスターメンバーに連絡できない場合、XenServerはGFS2クラスターメンバーシップを変更する操作(ホストの追加や削除など)を防止します。

ホストを回復不能としてマークする

1つ以上のオフラインホストを回復できない場合、GFS2クラスタープールにそれらを忘れるように指示できます。これらのホストはプールから永久に削除されます。ホストがGFS2クラスタープールから削除された後、それらはクォーラム値にカウントされなくなります。

ホストを回復不能としてマークするには、次のコマンドを使用します。

xe host-forget uuid=<host_uuid>

忘れられたホストを回復する

GFS2クラスタープールがホストを忘れるように指示された後、そのホストをプールに再度追加することはできません。

GFS2クラスタープールに再参加するには、ホストにXenServerを再インストールして、プールに新しいホストとして表示されるようにする必要があります。その後、通常の方法でホストをGFS2クラスタープールに参加させることができます。

GFS2クラスタープールのトラブルシューティング

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

制限事項

  • GFS2クラスタープールは、プールあたり最大16ホストのみをサポートします。
  • GFS2クラスタープールでHAを有効にするには、ハートビートSRがGFS2 SRである必要があります。
  • GFS2クラスターのトラフィックには、少なくとも2つの異なるネットワークスイッチを使用するボンディングされたネットワークを使用することを強くお勧めします。このネットワークを他の目的で使用しないでください。
  • XenCenterを使用してGFS2クラスターネットワークのIPアドレスを変更するには、GFS2クラスタリングとすべてのGFS2 SRを一時的に無効にする必要があります。
  • GFS2クラスターが稼働中でVMが実行されている間に、GFS2クラスターネットワークのボンディングを変更しないでください。この操作により、GFS2クラスター内のホストが強制的に再起動(フェンス)される可能性があります。
  • GFS2クラスタリングが有効になっている少なくとも1つのホストを含むGFS2クラスターネットワークでIPアドレスの競合(複数のホストが同じIPアドレスを持つ)がある場合、GFS2クラスターは正しく形成されず、ホストは必要に応じてフェンスできません。この問題を解決するには、IPアドレスの競合を解消してください。
GFS2 クラスタプール