XenServer

GFS2 クラスタープール

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

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

注:

クラスタリング機能は、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 クラスタープールには、他のトラフィックには使用されないボンディングネットワークを使用することを強くお勧めします。

必要に応じて、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クラスタ化されたプールにホストを追加または削除できます。詳細については、「Add a Server to a Pool」および「Remove a Server From a Pool」を参照してください。

xe CLIを使用して、GFS2クラスタ化されたプールにホストを追加または削除することもできます。詳細については、「Add a host to a pool by using the xe CLI」および「Remove XenServer hosts from a resource pool」を参照してください。

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

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

ただし、ホストが強制的に、または予期せずシャットダウンされた場合、オフラインになる前に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 クラスタープール