test

Sun Cluster 2.2 のシステム管理

ネットワークインタフェースの管理

この章では、Sun Cluster のパブリックネットワーク管理 (PNM) の機能と、ネットワークインタフェースコンポーネントの追加または交換を行う方法について説明します。この章で説明する項目は次のとおりです。

この章で説明する手順は次のとおりです。

パブリックネットワーク管理 (PNM) の概要

Sun Cluster の PNM 機能は、障害監視とフェイルオーバーによって、単一のネットワークアダプタまたはケーブルの障害によってノードが使用できなくなる状況を防ぎます。PNM の障害監視は、ローカルノードモードまたは全クラスタモードで、ノード、ネットワークアダプタ、ケーブル、ネットワークトラフィックの状態を確認します。PNM フェイルオーバーは、「バックアップグループ」と呼ばれるネットワークアダプタセットを使用して、クラスタノードとパブリックネットワーク間に冗長接続を提供します。障害監視機能とフェイルオーバー機能は、サービス継続のため連携して動作します。

HA データサービスは、PNM の障害監視に依存します。そのため、構成に HA データサービスが含まれる場合は、PNM を有効にする必要があります。HA データサービスで可用性問題が発生すると、HA データサービスはその問題がパブリックネットワーク接続に関連したものであるかを確認するため、クラスタフレームワークを介して PNM に問い合わせます。パブリックネットワーク接続に関連している場合、データサービスは PNM が問題を解決するまで待ちます。パブリックネットワーク接続に関連していない場合、データサービスは独自のフェイルオーバー機構を呼び出します。

PNM パッケージ SUNWpnm は、Sun Cluster ソフトウェアの最初のインストール時にインストールされます。PNM に関連するコマンドを次に示します。

詳細は、対応するマニュアルページを参照してください。

PNM の障害監視とフェイルオーバー

PNM は、クラスタ内の各ノードに対応するパブリックネットワークとネットワークアダプタの状態を監視し、疑わしい状態またはエラー状態を報告します。主アダプタ (現在、ノードとの間でネットワークトラフィックを伝送しているアダプタ) からの応答がないことを感知すると、PNM はそのノードのアダプタバックアップグループに存在する別の稼動アダプタに、ネットワークサービスをフェイルオーバーします。続いて、PNM は、アダプタとネットワークのどちらに障害が発生しているかを確認します。

アダプタ障害の場合、PNM は syslog(3) にエラーメッセージを送ります。このエラーメッセージは、次にクラスタマネージャによって検出され、GUI を介してユーザーに表示されます。障害が発生したアダプタは、修復された後、次のクラスタ再構成時にバックアップグループで自動的にテストされ回復されます。アダプタバックアップグループ全体がダウンしている場合には、Sun Cluster フレームワークはノードのフェイルオーバーを呼び出して、ノードを使用できる状態に保ちます。サブネット全体の障害のようにエラーが PNM 制御の範囲外で発生した場合には、通常のフェイルオーバーとクラスタ再構成が行われます。

PNM 監視は、クラスタ認識モードとクラスタ非認識モードで行われます。PNM は、クラスタが使用可能な場合、クラスタ認識モードで動作します。PNM は、クラスタ構成データベース (CCD) を使用して、ネットワークの状態を監視します。CCD の詳細は、『Sun Cluster 2.2 ソフトウェアのインストール』の概要の章を参照してください。PNM は、CCD を使用して、パブリックネットワーク障害とローカルアダプタ障害を区別します。パブリックネットワーク障害によって起きる論理ホストのフェイルオーバーについては、「Sun Cluster の障害検証」を参照してください。

PNM は、クラスタが使用不可能な場合、クラスタ非認識モードで動作します。このモードでは PNM は CCD を使用できないため、PNM はアダプタ障害とネットワーク障害を区別できません。クラスタ非認識モードでは、PNM はローカルネットワーク接続の問題を検出するだけです。

パブリックネットワークとアダプタの状態は、PNM 監視コマンド pnmstat(1M) を使用して確認できます。詳細は、マニュアルページを参照してください。

バックアップグループ

バックアップグループは、単一のクラスタノードとパブリックネットワーク間に冗長接続を提供するネットワークアダプタセットです。バックアップグループは、最初のインストール時に scinstall(1M) コマンドを使用して構成するか、最初のインストールの後で pnmset(1M) コマンドを使用して構成します。冗長アダプタは、単一のホスト上にいくつでも構成できます。

バックアップグループを初めて構成する場合は、クラスタが起動する前に root として pnmset(1M) を実行します。このコマンドは、対話型のスクリプトとして動作し、バックアップグループの構成と検証を行います。このコマンドは、主 (アクティブ) アダプタとして使用されるアダプタの選択も行います。pnmset(1M) コマンドは、バックアップグループに nafon という名前を付けます (n はユーザーが割り当てる整数)。このコマンドは、バックアップグループ情報を /etc/pnmconfig ファイルに格納します。

クラスタノードの既存の PNM 構成を変更するには、クラスタからそのノードを削除し、続いて pnmset(1M) コマンドを実行する必要があります。PNM は、変更を監視して、バックアップグループメンバーシップにその変更を動的に組み入れます。

注 -

ソフトウェアのアップグレードなどの際に SUNWpnm パッケージが削除されても、/etc/pnmconfig ファイルは削除されません。つまり、ソフトウェアアップグレードが行われてもバックアップグループのメンバーシップ情報は維持されるため、バックアップグループメンバーシップの変更が必要ない場合は、pnmset(1M) ユーティリティを再実行する必要はありません。

nsswitch.conf に対する更新

バックアップネットワークアダプタを使用して PNM を構成する場合、/etc/nsswitch.conf ファイルに netmasks エントリとして次の 1 つを指定します。

表 6-1 /etc/nsswitch.conf ファイルのネームサービスエントリの選択

使用中のネームサービス 

netmasks エントリ

なし 

netmasks: files

nis

netmasks: files [NOTFOUND=return] nis

nisplus

netmasks: files [NOTFOUND=return] nisplus

上記の設定が行われると、NIS/NIS+ ルックアップテーブルで netmasks 設定は照合されません。このことは、障害が発生したアダプタが主パブリックネットワークであり、そのため要求された情報を提供できない場合に重要な意味を持ちます。ネットマスクエントリが所定の方法で設定されない場合、バックアップアダプタに対するフェイルオーバーは成功しません。

注意 - 注意 -

上記の変更が行われると、ルックアップテーブルとしてローカルファイル /etc/netmasks と /etc/groups が使用されます。NIS/NIS+ サービスは、これらのローカルファイルが使用できない場合にだけ使用されます。そのため、これらのファイルはその NIS/NIS+ バージョンを使用して最新の状態に保つ必要があります。更新が行われないと、クラスタノードでこれらのファイル内の期待値にアクセスできなくなります。

パブリックネットワーク管理 (PNM) の設定

この節では、PNM の設定とバックアップグループの構成を行う方法について説明します。

PNM を設定するには

次に、PNM の設定手順の概略を示します。

次に、PNM の詳しい設定手順を示します。

  1. 同じサブセットを使用して、単一のノード上に複数のネットワークアダプタが存在するようにノードハードウェアを設定します。

    ネットワークアダプタを設定するには、Sun Cluster ノードのハードウェアのマニュアルを参照してください。

  2. Sun Cluster ノードソフトウェアパッケージがまだインストールされていない場合は、scinstall(1M) コマンドを使用してそれらをインストールします。

    scinstall(1M) コマンドで、選択されたパッケージを対話形式でインストールします。PNM パッケージ SUNWpnm は、ノードパッケージセットの一部です。クラスタのインストール作業の詳細は、『Sun Cluster 2.2 ソフトウェアのインストール』を参照してください。

  3. 各ノードでデフォルトのネットワークインタフェースを登録します (まだ登録されていない場合)。

    各ノードに対応するインタフェースデータベース内のノードごとにデフォルトネットワークインタフェースを 1 つ登録するとともに、そのインタフェースが取り付けられ、正常に動作していることを確認する必要があります。

    1. 各ノードでインタフェースデータベースを作成し、主パブリックネットワークインタフェースを登録します。

      各ノードの /etc ディレクトリに、インタフェースデータベースとして使用するファイルを作成します。このファイルに、hostname.interfaceという名前を付けます (hostname は主物理ホストの名前)。続いて、そのノードのインタフェース名が入った 1 行を追加します。たとえば、デフォルトインタフェース qfe-1 を持つノード phys-hahost1 で、次に示す行が入ったファイル /etc/phys-hahost1.qfe1 を作成します。 

      phys-hahost1-qfe1

    2. 各ノードの /etc/hosts ファイルで、主パブリックネットワークインタフェース名と IP アドレスを関連付けます。

      次の例では、主物理ホスト名は phys-hahost1 です。

      129.146.75.200 phys-hahost1-qfe1

      システムが /etc/hosts 以外の命名方法を使用している場合は、『TCP/IP とデータ通信』の該当する説明を参照し、同等の機能を実行してください。

  4. pnmset(1M) コマンドを使用して、PNM バックアップグループを作成します。

    対話式の pnmset(1M) スクリプトを実行して、バックアップグループを設定してください。

    注意 - 注意 -

    論理ホストとデータサービスをすでに構成してある場合は、pnmset(1M) を使用してバックアップグループメンバーシップを変更する前に、HA データサービスを停止する必要があります。pnmset(1M) コマンドを実行する前にデータサービスを停止しないと、重大な問題やデータサービス障害が発生することがあります。

    1. pnmset(1M) コマンドを実行します。

      phys-hahost1# /opt/SUNWpnm/bin/pnmset

    2. 構成するバックアップグループの合計数を入力します。

      通常、この数はパブリックサブネットの数に一致します。

      In the following dialog, you will be prompted to configure public 
network management.

 do you want to continue ... [y/n]: y

 How many NAFO backup groups on the host [1]: 2

    3. バックアップグループ番号を割り当てます。

      プロンプトで、0 〜 255 (最大) の範囲で整数を指定します。pnmset(1M) コマンドは、この数字を文字列 nafo に加えてバックアップグループ名にします。

      Enter backup group number [0]: 0

    4. アダプタをバックアップグループに割り当てます。

      Please enter all network adapters under nafo0:
 qe0 qe1
...

      続けて、構成内のほかのすべてのバックアップグループに、バックアップグループ番号とアダプタを割り当てます。

    5. pnmset(1M) コマンドによって、アダプタ構成のテストが始まります。

      pnmset(1M) コマンドは、アダプタ構成の正確さをテストします。この例では、バックアップグループにアクティブアダプタが 1 つ、冗長アダプタが 2 つ含まれています。

      The following test will evaluate the correctness of the customer 
NAFO configuration...
 name duplication test passed


 Check nafo0... < 20 seconds
 qe0 is active
 remote address = 192.168.142.1
 nafo0 test passed


 Check nafo1... < 20 seconds
 qe3 is active
 remote address = 192.168.143.1
 test qe4 wait...
 test qe2 wait...
 nafo1 test passed
 phys-hahost1#

      構成の検証が終わると、PNM デーモン pnmd(1M) は自動的に構成の変更を認識し、インタフェースの監視を開始します。

      注 -

      バックアップグループのアダプタの内、取り付けが行われ、/etc/hostname.adapter というファイルにエントリを持つのは、1 つのアダプタだけです。バックアップアダプタに IP アドレスは割り当てないでください。バックアップアダプタは取り付けられません。

      注 -

      PNM は、ブロードキャスト ping(1M) を使用してネットワークを監視します。ネットワークは、ブロードキャスト ICMP (Internet Control Message Protocol) パケットを使用して、ほかの遠隔ホストと通信を行います。ルーターの中にはブロードキャスト ICMP パケットを転送しないものがあり、PNM の障害検出動作はこの影響を受けます。この問題の対策については、『Sun Cluster 2.2 ご使用にあたって』を参照してください。

  5. scadmin(1M) コマンドを使用してクラスタを起動します。

    1 つのノードで、次のコマンドを実行してください。

    # scadmin startcluster physical-hostname sc-cluster

    続いて、ほかのすべてのノードで次のコマンドを実行し、クラスタにほかのすべてのノードを追加してください。

    # scadmin startnode

  6. pnmstat(1M) コマンドを使用して、PNM 構成を検証します。

    phys-hahost1# /opt/SUNWpnm/bin/pnmstat -l
bkggrp  r_adp   status  fo_time live_adp
 nafo0   hme0    OK      NEVER   hme0
 phys-hahost1#

    以上で、PNM の初期設定は終了です。

PNM を再構成するには

ネットワークアダプタを追加または削除して既存の PNM 構成を再構成する方法を次に示します。作業中も Sun Cluster サービスを利用できるように、この手順は一度に 1 つのノードに対して行なってください。

  1. 再構成するノードで、Sun Cluster ソフトウェアを停止します。 

    phys-hahost1# scadmin stopnode

  2. ネットワークアダプタを追加または削除します。

    「ネットワークインタフェースの追加と削除」に説明されている作業を行なってください。

  3. pnmset(1M) コマンドを実行して、バックアップグループを再構成します。

    「PNM を設定するには」の手順 4 に説明されているように、pnmset(1M) コマンドを使用してバックアップグループを再構成してください。

    phys-hahost1# pnmset

  4. そのノードで、Sun Cluster ソフトウェアを再起動します。

    管理ワークステーションから次のコマンドを実行して、ノードを再起動してください。

    phys-hahost1# scadmin startnode

  5. 再構成するノードごとに、手順 1 〜 4 を繰り返します。

バックアップグループの状態を確認するには

pnmptor(1M) と pnmrtop(1M) コマンドを使用すると、ローカルバックアップグループだけの状態を確認できます。pnmstat(1M) コマンドを使用すると、ローカルまたは遠隔のバックアップグループの状態を確認できます。

    アダプタが属しているバックアップグループを確認するには、pnmptor(1M) コマンドを実行します。

pnmptor(1M) コマンドは、実際のアダプタ名に指定する疑似アダプタ名を割り当てます。次の例では、システム出力は、疑似アダプタ名 nafo0 がアクティブアダプタ hme2 に対応することを示しています。

phys-hahost1# pnmptor nafo0
hme2

    特定のバックアップグループに対応するアクティブアダプタを確認するには、pnmrtop(1M) コマンドを実行してください。

次の例では、システム出力は、アダプタ hme1 がバックアップグループ nafo0 に属することを示しています。

phys-hahost1# pnmrtop hme1
nafo0

    バックアップグループの状態を確認するには、pnmstat(1M) コマンドを実行します。

ローカルホスト上のバックアップグループの状態を確認するには、-c オプションを使用します。

phys-hahost1# pnmstat -c nafo0
OK
 NEVER
 hme2

遠隔ホスト上のバックアップグループの状態を確認するには、次の構文を使用します。

phys-hahost1# pnmstat -sh remotehost -c nafo1
 OK
 NEVER
 qe1
注 -

-s と -h オプションを共に使用することは重要です。-s オプションが指定されると、pnmstat(1M) はプライベートインターコネクトを介して通信を行います。-s オプションが省略されると、pnmstat(1M) はパブリックインターコネクトを介して照会を行います。remotehost と pnmstat(1M) を実行するホストは、両方ともクラスタメンバーでなければなりません。

ローカルホストと遠隔ホストのどちらを確認している場合でも、pnmstat(1M) コマンドは状態、履歴、現在のアクティブアダプタを報告します。詳細は、マニュアルページを参照してください。

構成可能な PNM パラメータ

次の表は、ユーザーが構成できる PNM パラメータについて説明しています。これらのパラメータは、PNM をインストールした後で (ただしクラスタを立ち上げる前)、クラスタ内のすべてのノードの構成ファイル /opt/SUNWcluster/conf/TEMPLATE.cdb を手作業で編集して構成してください。1 つのノードで編集したファイルをほかのすべてのノードにコピーすることも、クラスタコンソールを使用してすべてのノードでファイルを同時に変更することも可能です。現在の PNM 構成は、pnmset -l を使用して表示できます。

表 6-2 構成可能な PNM パラメータ

pnmd.inactive_time

秒単位で示した障害検証間の時間。デフォルトの間隔は 5 秒。 

pnmd.ping_timeout

秒単位で示した、障害検証がタイムアウトするまでの時間。デフォルトのタイムアウト値は 4 秒。 

pnmd.repeat_test

PNM が失敗した検証を再試行する回数。この回数を過ぎると、PNM は障害があると判断する。デフォルトの反復数は 3 回。 

pnmd.slow_network

秒単位で示した、障害検証の待機 (listen) 段階とアクティブ検証段階の間の応答時間。デフォルトの応答時間は 2 秒。ネットワークが遅く、PNM が疑似テイクオーバーを引き起こす場合は、この応答時間を増やすとよい。 

PNM エラーの障害追跡

以下に、PNM が返す主なエラーを示します。 

PNM rpc svc failed

このエラーは、PNM デーモンがまだ起動していないことを示します。次のコマンドを使用して、PNM を再起動してください。node-id は、/opt/SUNWcluster/bin/get_node_status コマンドによって返される値です。


# /opt/SUNWpnm/bin/pnmd -s -c clustername -l node-id



PNM not started

このメッセージは、バックアップグループが構成されていないことを示します。バックアップグループを作成するには、pnmset(1M)コマンドを使用してください。

No nafoXX

このメッセージは、無効なバックアップグループ名が指定されたことを示します。特定のアダプタに対応するバックアップグループ名を確認するには、pnmrtop(1M) コマンドを使用してください。有効なバックアップグループ名を使用して、コマンドを再実行してください。

PNM configure error

このメッセージは、PNM デーモンがアダプタを構成できなかったか、構成ファイル /etc/pnmconfig にフォーマットエラーがあるかのいずれかを示しています。syslog メッセージを確認し、Sun Cluster Manager で指定された作業を行なってください。詳細は第 2 章「Sun Cluster の管理ツール」を参照してください。

Program error

このメッセージは、PNM デーモンがシステムコールを実行できなかったことを示しています。syslog メッセージを確認、Sun Cluster Manager で指定された作業を行なってください。詳細は第 2 章「Sun Cluster の管理ツール」を参照してください。

ネットワークインタフェースの追加と削除

この節で説明する作業は、クラスタ構成内のパブリックネットワークインタフェースカードの追加または削除に使用できます。

論理ホストの制御にネットワークインタフェースを追加または削除するには、そのインタフェースを使用するように構成された各論理ホストを変更する必要があります。論理ホストの構成を変更するには、クラスタからその論理ホストを完全に削除した後、必要な変更を加えて追加し直します。論理ホストは、scconf(1M) または scinstall(1M) コマンドを使用して再構成できます。この節の例では、scconf(1M) コマンドを使用しています。scinstall(1M) コマンドによる論理ホストの構成手順については、「論理ホストの追加と削除」を参照してください。

ネットワークインタフェースの追加

ネットワークインタフェースを追加するには、そのインタフェースに対応する論理ホストの構成を解除し、再構成します。この作業は短時間ですみますが、その間すべてのデータサービスはアクセスできなくなることに注意してください。

ネットワークインタフェースを追加するには

新しいネットワークインタフェースを追加するノードごとに、次の手順を実行します。

  1. クラスタソフトウェアを停止します。

    phys-hahost# scadmin stopnode

  2. カードに付属している説明書の指示に従って、新しいインタフェースカードを追加します。

  3. 各ノードで、新しいネットワークインタフェースを構成します。

    この手順は、新しいインタフェースが論理ホストの一部である場合だけ必要です。構成に論理ホストが含まれない場合、この手順は省略してください。

    phys-hahost# pnmset

    Ethernet の場合、各ノードの新しいインタフェースごとに新しい /etc/hostname.if ファイルを作成し、非クラスタ環境で通常行うように ifconfig(1M) コマンドを実行します。

    注 -

    複数のネットワークインタフェースをクラスタ内の別々の論理ホストで使用するように構成する場合、それらのインタフェースをすべて同じサブネットに接続する必要があります。

  4. クラスタソフトウェアを起動します。

    すべてのノードが停止している場合は、ノード 0 で scadmin startcluster コマンドを実行し、続いてほかのすべてのノードで scadmin startnode コマンドを実行してください。クラスタソフトウェアを停止していないノードがある場合は、ほかのノードで scadmin startnode コマンドを実行してください。

    phys-hahost# scadmin startnode

    新しいインタフェースが既存のバックアップグループに追加される場合は、作業は以上で終了します。

    バックアップグループ構成を変更した場合は、クラスタを通常のオペレーションに戻し、新しいネットワークコントローラセットを使用する各論理ホストを再構成する必要があります。論理ホストごとに構成を解除して再構成するため、これらの手順を開始する前に scconf -p コマンドを実行して現在の構成を出力してください。scconf -p コマンドは、アクティブクラスタメンバーである任意のノードで実行できます。このコマンドは、すべてのクラスタノードで実行する必要はありません。

    論理ホストの構成を解除して再構成するには、これらの例に示されているように scconf(1M) コマンドを使用するか、「論理ホストの追加と削除」に説明されているように scinstall(1M) コマンドを使用できます。

  5. 影響を受ける論理ホストのデータサービスがしばらく使用できなくなることをユーザーに知らせます。

  6. 元の構成に復元する場合に備えて、各ノードの /etc/opt/SUNWcluster/conf/ccd.database ファイルのコピーを保存します。

  7. データサービスを無効にします。

    phys-hahost# hareg -n dataservice

  8. データサービスの登録を解除します。

    phys-hahost# hareg -u dataservice

  9. クラスタから論理ホストを削除します。

    アクティブクラスタメンバーである任意のノードで、次のコマンドを実行してください。このコマンドは、すべてのクラスタノードで実行する必要はありません。

    phys-hahost# scconf clustername -L logicalhost -r

  10. 論理ホストを再構成して、新しいインタフェースを含めます。

    アクティブクラスタメンバーである任意のノードで次のコマンドを実行してください。このコマンドは、すべてのクラスタノードで実行する必要はありません。

    phys-hahost# scconf clustername -L logicalhost -n nodelist -g dglist -i logaddrinfo

    logaddrinfo フィールドには、新しいインタフェース名を指定します。各論理ホストを再構成するには、scconf -p コマンド出力で表示されるリストを参照してください。

  11. データサービスを再登録します。

    phys-hahost# hareg [-s] -r dataservice

  12. データサービスを有効にします。

    phys-hahost# hareg -y dataservice

  13. データサービスに対するアクセスを確認します。

  14. データサービスが元どおり使用できるようになったことをユーザーに知らせます。

    以上で、ネットワークインタフェースの追加作業は終了です。

ネットワークインタフェースの削除

クラスタからパブリックネットワークインタフェースを削除するには、次の作業を行なってください。

ネットワークインタフェースを削除するには

すべてのノードがクラスタに属している間に、1 つのノードだけで次の手順を実行してください。

  1. ネットワークインタフェースを削除するために、どの論理ホストの再構成が必要かを確認します。

    これらの論理ホストはすべて、構成を解除した後で再構成する必要があります。scconf -p コマンドを実行して現在の構成の論理ホストの一覧を出力し、後で使用できるようにこの一覧を保存してください。scconf -p コマンドは、すべてのクラスタノードで実行する必要はありません。このコマンドは、アクティブクラスタメンバーである任意のノードで実行できます。

  2. pnmset(1M) コマンドを実行し、現在の PNM 構成を表示します。

  3. 必要に応じて、バックアップグループからコントローラを削除します。

    削除するコントローラがバックアップグループの一部である場合は、すべての論理ホストからコントローラを削除し、その後 pnmset(1M) コマンドを実行してバックアップグループからコントローラを削除します。

  4. 影響を受ける論理ホストのデータサービスがしばらく使用できなくなることをユーザーに知らせます。

  5. データサービスを無効にします。

    phys-hahost# hareg -n dataservice

  6. データサービスの登録を解除します。

    phys-hahost# hareg -u dataservice

  7. クラスタから論理ホストを削除します。

    注 -

    論理ホストの構成を解除して再構成する (手順 7と 手順 8) には、これらの手順で示されているように scconf(1M) コマンドを実行することも、「論理ホストの追加と削除」で説明しているように scinstall(1M) コマンドを実行することもできます。

    このコマンドは、アクティブクラスタメンバーである任意のノードで実行できます。このコマンドは、すべてのクラスタノードで実行する必要はありません。

    phys-hahost# scconf clustername -L logicalhost -r

  8. 論理ホストを再構成して、新しいインタフェースを含めます。

    このコマンドは、アクティブクラスタメンバーである任意のノードで実行できます。このコマンドは、すべてのクラスタノードで実行する必要はありません。

    phys-hahost# scconf clustername -L logicalhost -n nodelist -g dglist -i logaddrinfo

    logaddrinfo フィールドには、新しいインタフェース名を指定します。各論理ホストを再構成するには、scconf -p コマンド出力で表示される一覧を参照してください。

  9. 削除するコントローラがバックアップグループの一部である場合は、pnmset(1M) コマンドを再実行します。

    pnmset(1M) コマンドを再実行し、コントローラを削除してください。

  10. (省略可能) ノードからネットワークアダプタを削除する場合は、影響を受ける各ノードで次の手順を実行します。

    1. クラスタソフトウェアを停止します。

      phys-hahost# scadmin stopnode

    2. ノードを停止し、インタフェースカードを取り外します。

    3. ノードを起動します。

    4. 通常行う Solaris システム管理作業 (hostname.if ファイルの削除、/etc/hosts の更新など) を実行して、ネットワークインタフェースを削除します。

    5. クラスタソフトウェアを再起動します。すべてのノードが停止されている場合は、scadmin startcluster コマンドを使用して最初のノードを起動します。クラスタソフトウェアをまだ実行しているノードがある場合は、ほかのノードを再起動します。

      phys-hahost# scadmin startnode

  11. データサービスを登録します。

    phys-hahost# hareg -r dataservice

  12. データサービスを有効にします。

    phys-hahost# hareg -y dataservice

  13. データサービスに対するアクセスを確認します。

  14. データサービスが元どおり使用できるようになったことをユーザーに知らせます。

スイッチ管理エージェントの管理

スイッチ管理エージェント (SMA) は、クラスタプライベートインターコネクトを介して通信チャネルを管理するクラスタモジュールです。SMA は、プライベートインターコネクトを監視し、障害を検出した場合にバックアップネットワークに対するフェイルオーバーを呼び出します。

作業を開始する前に、次の制限に注意してください。

スイッチと SCI カードを追加するには

クラスタノードにスイッチと SCI カードを追加するには、次の作業を行なってください。詳細は、sm_config(1M) マニュアルページを参照してください。

  1. sm_config 一時ファイルを編集して、構成変更を反映させます。

    この一時ファイルは、通常、/opt/SUNWsma/bin/Examples にあります。

  2. ノードの 1 つから sm_config(1M) コマンドを実行して、SCI SBus カードを構成します。

    このコマンドを再実行して、SCI のノード ID と IP アドレスがクラスタノードに正しく割り当てられていることを確認してください。割り当てが不正に行われていると、ノード間で通信不良が発生することがあります。

  3. 新しいノードを再起動します。

SCI ソフトウェアの障害追跡

SCI に問題が発生した場合は、次の点を確認してください。

次に示す問題とその解決方法も参考にしてください。

ノード間の接続を検査するには

ノード間の接続を検査するには、get_ci_status(1M) または ping(1) を実行できます。

    get_ci_status(1M) コマンドは、すべてのクラスタノードで実行します。

次に、get_ci_status(1M) の出力例を示します。

# /opt/SUNWsma/bin/get_ci_status
sma: sci #0: sbus_slot# 1; adapter_id 8 (0x08); ip_address 1; switch_id# 0; 
port_id# 0; Adapter Status - UP; Link Status - UP
sma: sci #1: sbus_slot# 2; adapter_id 12 (0x0c); ip_address 17; switch_id# 1; 
port_id# 0; Adapter Status - UP; Link Status - UP
sma: Switch_id# 0
sma: port_id# 1: host_name = interconn2; adapter_id = 72; active | operational
sma: port_id# 2: host_name = interconn3; adapter_id = 136; active | operational
sma: port_id# 3: host_name = interconn4; adapter_id = 200; active | operational
sma: Switch_id# 1
sma: port_id# 1: host_name = interconn2; adapter_id = 76; active | operational
sma: port_id# 2: host_name = interconn3; adapter_id = 140; active | operational
sma: port_id# 3: host_name = interconn4; adapter_id = 204; active | operational
#

最初の 4 つの行は、ローカルノード (この例では interconn1) の状態を示しています。ローカルノードは、switch_id# 0 および switch_id# 1 と通信しています (Link Status - UP)。

sma: sci #0: sbus_slot# 1; adapter_id 8 (0x08); ip_address 1; switch_id# 0; 
port_id# 0; Adapter Status - UP; Link Status - UP
sma: sci #1: sbus_slot# 2; adapter_id 12 (0x0c); ip_address 17; switch_id# 1; 
port_id# 0; Adapter Status - UP; Link Status - UP

ほかの行は、クラスタ内のほかのノードの全体的な状態を示しています。2 つのスイッチ上のノードはすべて、それらのノードと通信しています。ハードウェアに問題があると、active ではなく inactive が表示されます。ソフトウェアに問題があると、operational ではなく inoperational が表示されます。

sma: Switch_id# 0
sma: port_id# 1: host_name = interconn2; adapter_id = 72; active | operational
sma: port_id# 2: host_name = interconn3; adapter_id = 136; active | operational
sma: port_id# 3: host_name = interconn4; adapter_id = 200; active | operational
sma: Switch_id# 1
sma: port_id# 1: host_name = interconn2; adapter_id = 76; active | operational
sma: port_id# 2: host_name = interconn3; adapter_id = 140; active | operational
sma: port_id# 3: host_name = interconn4; adapter_id = 204; active | operational
#

    ping(1) コマンドは、遠隔ノードのすべての IP アドレスに対して実行します。

次に、ping(1) の出力例を示します。

# ping IP-address

IP アドレスは、/etc/sma.ip ファイルに入っています。ping(1) コマンドは、必ずクラスタ内のノードごとに実行してください。

ping(1) コマンドは、2 つの末端が支障なく通信している場合、「alive」というメッセージを返します。問題がある場合は、エラーメッセージが表示されます。

次に例を示します。

# ping 204.152.65.2
204.152.65.2 is alive

SCI インタフェース構成を検査するには

    すべての SCI インタフェースが動作しており、クラスタノードの IP アドレスが正しいことを確認するには、ifconfig -a コマンドを実行します。

IP アドレスの最後の 8 ビットは、/etc/sma.config ファイルの IP フィールドの値に一致する必要があります。 

# ifconfig -a
lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
 	inet 127.0.0.1 netmask ff000000
hme0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
 	inet 129.146.238.55 netmask ffffff00 broadcast 129.146.238.255
 	ether 8:0:20:7b:fa:0
scid0: flags=80cl<UP,RUNNING,NOARP,PRIVATE> mtu 16321
 	inet 204.152.65.1 netmask fffffff0
scid1: flags=80cl<UP,RUNNING,NOARP,PRIVATE> mtu 16321
 	inet 204.152.65.17 netmask fffffff0