ページの先頭行へ戻る
PRIMECLUSTER  Cluster Foundation 導入運用手引書 4.5
FUJITSU Software
第1章 Cluster Foundation > 1.1 CF、CIP、およびCIMの構成設定
前次

1.1 CF、CIP、およびCIMの構成設定

CF、Cluster Interconnect Protocol (CIP)、および Cluster Integrity Monitor (CIM) の構成設定は、RMS (Reliant Monitor Services) などの他のPRIMECLUSTERの機能を構成設定する前に、設定する必要があります。

CFは、クラスタを構成するノードを定義します。SF (シャットダウン機構) およびRMSは、CFおよびCIPの構成設定後に、実行可能となります。

ノードの強制停止はシャットダウン機構 (SF) が行います。これは、RMSがインストールされていない場合や、RMSがクラスタ内で稼動していない場合でも、CFのハートビートが失われると、SFによりノードの強制停止が行われます。

Cluster AdminのCFウィザードを使用すれば、クラスタ内のすべてのノードのCF、CIP、およびCIMを簡単に構成設定することができます。

CFの構成では、以下の情報を設定します。

CF専用のネットワーク接続をインタコネクトといいます。通常、インタコネクトは何らかの高速ネットワーク形式 (100メガビットまたはギガビットイーサネットリンクなど) で構成されています。これらのインタコネクトをCFで使用する場合は、インタコネクトが以下の要件を満たしている必要があります。

また、CF は IP 上でも動作します。ノード上にある任意の IP インタフェースを IP“デバイス”として選択すると、CF はこのデバイスをイーサネットデバイスと同様に扱うことができます。ただし、そのインタコネクトに関わるすべてのクラスタの全 IP アドレスが、同一の IP サブネットワーク上にあり、同一の IP ブロードキャストアドレスを持っている必要があります。 (詳細については、“第9章 CF over IP”を参照してください。)

CF で使用する IP インタフェースは、使用前にシステム管理者が構成設定を完了しておく必要があります。CF は、イーサネットデバイスおよび IP デバイスの両方で動作することができます。RMS、SF、Global File Services (以降、GFS) などの上位レベルのサービスでは、CF が IP 上で動作していても違いはありません。

CFの構成設定処理を開始する前に、クラスタ内で使用するインタコネクトの数を慎重に選択する必要があります。クラスタでCFを構成設定した後でインタコネクトの数を変更するには、各ノード上でCFを停止して再設定します。CFを停止するには、上位サービス (RMS、SF、GFSなど) をそのノード上で停止する必要があるので、再構成プロセスは複雑で、他の作業に影響が及びます。

注意

1本のインタコネクトで構成すると、故障してしまった場合、サービスが停止してしまうので、インタコネクトは二重化することを推奨します。

CFの設定を行う前に、選択したインタコネクトにすべてのノードが接続され、すべてのノードがこれらのインタコネクトを通じて互いに通信できることを確認する必要があります。CFでは、クラスタ内で他のすべてのノードとの通信を可能にするインタコネクトがノード上で1つ以上稼動していれば、そのノードはクラスタに参入できます。しかし、Cluster Adminを使用して適切にCFを構成設定するには、構成プロセス中にすべてのインタコネクトが稼動している必要があります。

CIP (クラスタインタコネクトプロトコル)の構成設定には、仮想CIPインタフェースの定義や仮想CIPインタフェースへのIPアドレスの割当てが伴います。各ノードで最大8つのCIPインタフェースを定義できます。IPトラフィックがCFインタコネクト上を流れることを除いて、これらの仮想インタフェースは通常のTCP/IPインタフェースと同様に機能します。通常、CFは複数のインタコネクトで構成されるので、1つのインタコネクトに障害が発生しても、CIPトラフィックは停止しません。このため、クラスタ間のTCP/IPトラフィックに関する限り、物理ネットワーク接続に一点故障は発生しません。

各ノードで定義できる最大8つのCIPインタフェースは、IP構成を除いてすべて同様に扱われます。特定のインタフェースが優先されることはなく、各インタフェースがすべてのCFインタコネクトを同様に使用します。このため、多くのシステム管理者は各ノードで1つのCIPインタフェースだけを定義します。

CIPを使用してノード間で通信できるようにするため、特定のCIPインタフェースに対する各ノードのIPアドレスは同じサブネットを使用する必要があります。また、IPv6アドレスを使用する場合は、CIPインタフェースに対して割り当てた、1つのIPv6アドレスを使用して通信を行います。リンクローカルアドレスを使用した通信は行えません。

CIPトラフィックはクラスタ内でのみ経路指定が可能です。CIPアドレスをクラスタの外部で使用しないでください。このため、経路指定不可能な予約済みIPアドレス範囲のアドレスを使用する必要があります。

IPv4アドレスの場合、Address Allocation for Private Internets (RFC 1918) で、専用サブネット用に以下のアドレス範囲が定義されています。

Subnets(s)                       Class        Subnetmask
10.0.0.0                         A            255.0.0.0
172.16.0.0 ... 172.31.0.0        B            255.255.0.0
192.168.0.0 ... 192.168.255.0    C            255.255.255.0

IPv6アドレスの場合、Unique Local IPv6 Unicast Addresses (RFC 4193)で、プレフィックス FC00::/7 で定義された範囲を、プライベートネットワーク内で自由に割り当て可能なアドレス(ユニーク・ローカル・ユニキャスト・アドレス)としています。

CIPノード名に関して、以下のRMSの命名規則を使用することを推奨します。

cfnameRMS

cfnameはノードのCF名で、語尾に「RMS」をつけます。これは、ノードのCIPインタフェースで使用されます。Cluster Admin GUIではこの命名規則が使用されるので、通常のノード名とCIP名を容易に対応付けることができます。一般に、1つのノードは最低でも1つのCIPインタフェースで構成されている必要があります。

注意

CIP構成では、/etc/hostsにCIP名が格納されています。ノードを探すときに、最初に/etc/hosts を参照するよう、/etc/nsswitch.conf(4)を設定してください。

CF、CIP、およびCIMの構成を設定するには、Cluster Admin GUIを使用することを推奨します。GUIのCF/CIP ウィザードを使用すると、数個の画面でクラスタ内のすべてのノード上でCF、CIP、およびCIMを構成設定できます。ただし、ウィザードを実行する前に、以下のステップを完了する必要があります。

  1. CF/CIP、Web-Based Admin View、およびCluster Adminをクラスタ内のすべてのノードにインストールします。

  2. イーサネット上でCF を実行する場合は、クラスタ内のすべてのインタコネクトが適切なハブまたはネットワークの装置に物理的に接続され、稼動している必要があります。

  3. CF over IP を実行する場合は、CF over IP で使用するすべてのインタフェースが適切に構成設定され、稼動している必要があります。詳細については、“第9章 CF over IP”を参照してください。

  4. Web-Based Admin Viewを設定する必要があります。詳細については、“PRIMECLUSTER Web-Based Admin View 操作手引書”の“2.4.1 管理サーバの構築”を参照してください。

Cluster Admin画面の [cf] タブで、ノード上にCFドライバがロードされていることを確認します。ドライバをロードする必要がある場合は、＜ドライバのロード＞ボタンを押します。次に、＜設定＞ボタンを押して、CFウィザードを開始します。

まだCFを設定していないノードを選択して Cluster Admin を起動した場合は、CF/CIP ウィザードが自動的に起動します。

以下のいずれかの方法でGUIを起動します。

PRIMECLUSTERでは、管理LANとクラスタインタコネクトは、別々の NIC で構成することを推奨しています。しかし、KVM環境またはVMware環境において、ハードウェア上の制約からそのような構成を取ることができない場合、管理LANとクラスタインタコネクトでNICを共有する構成もサポートします。

KVM環境

管理LANとクラスタインタコネクトでNICを共有する構成では、ネットワークおよび Global Link Services (以降、GLS) は、以下の条件をすべて満たすようにしてください。

  • 管理OS において、2 つの NIC を GLS の仮想NIC方式により冗長化します。

  • 仮想インタフェース上に、管理OS、ゲストOS の管理LAN、業務LAN、クラスタインタコネクトに必要な数の VLAN インタフェースを作成します。

  • 管理OS用、ゲストOS 用のクラスタインタコネクトは、その VLANインタフェース上に作成します。クラスタインタコネクト側では冗長化しません。

  • 業務LAN については、ゲストOS 上に Gls リソースを作成し、ゲストOS 上の RMS が監視します。

本構成は、CLI による CF の設定が必要となります。設定方法の詳細については、“1.1.7 CLIによるCF設定例”を参照してください。

注意

本構成では、以下の注意事項があります。

  • ネットワークスイッチ二重故障時の可用性
    2 つの NIC が接続されているネットワークスイッチが両方とも故障した場合、管理LAN、業務LAN、クラスタインタコネクトがすべて故障した状態となります。
    この状態では、管理OSやゲストOSを強制停止できなくなり、業務切替えも発生しません。
    なお、サーバのNICが二重故障した場合であれば、もう一方のサーバから強制停止できるため、業務切替えが発生します。

  • クラスタインタコネクトのタイムアウト値の制約
    GLS の仮想NIC方式では、パス切替えに約 20 秒かかります。一方、クラスタインタコネクトの異常検出時間は 10 秒 (初期値) です。このため、設定が初期値のままでは、1 つのNIC故障が発生した場合、クラスタインタコネクトの異常が先に検知されてしまいます。
    この問題を解決するため、タイムアウト値 (CLUSTER_TIMEOUT) を、管理OSは 40 秒、ゲストOSは 30 秒に変更してください。
    この設定変更により、クラスタインタコネクトの異常の検出時間は長くなります (10 秒 → 40 秒) 。

  • 業務LAN高負荷によるクラスタ切替え
    業務LANに負荷がかかり、30 秒以上の通信遅延が発生する状態となった場合、PRIMECLUSTERがクラスタインタコネクトの異常を検出し、管理OS またはゲストOS を強制停止し、クラスタ切替えが発生することがあります。

  • GLSの停止と起動、およびネットワーク・サービスの再起動に関する制約
    GLSの停止と起動、またはシステムのネットワーク・サービスの再起動をする場合は、事前にCFを停止してください。CFの停止方法については、本書の“4.6 CFの起動と停止”を参照してください。

VMware環境

VMware環境で管理LANとクラスタインタコネクトのNICを共有する場合は、VMwareの機能で仮想マシンに割り当てるネットワークを分けてください。なお、その構成の場合、CF設定はGUIから実施可能です。

前次
Copyright FUJITSU LIMITED 2017-2020