第 4 章 一般的な Sun Cluster の管理
この章では、次の項目について説明します。
クラスタとクラスタノードの起動
ノードをクラスタの最初のメンバーにするには、scadmin startcluster コマンドを使用します。このノードは、そのクラスタのノード 0 になります。その他の Sun Cluster ノードは、scadmin startnode コマンドで起動します。このコマンドは、複数のノードの同期に必要なプログラムを起動するとともに、Sun Cluster ソフトウェアが最初のノードですでに動作している場合、2 つ目以降のノードが最初のノードと統合するように調整します。クラスタからノードを削除するには、削除するノード上で stopnode オプションを指定して scadmin コマンドを実行します。
クラスタの最初のメンバーには、ローカルノードを指定してください。scadmin startcluster コマンドを正常に実行するためには、このノードがクラスタで構成されていなければなりません。このコマンドの実行が正常に終了すると、ほかのノードをクラスタに加えることができます。ほかのノードをクラスタに加えている間に何らかの理由でローカルノードが停止する場合、CCD が破損することがあります。このような状況が発生した場合は、「CCD を復元するには」に従って CCD を復元してください。
ローカルノードをクラスタの構成ノードにするには、「クラスタノードの追加と削除」を参照してください。
クラスタを起動するには
この時点では、ほかのノードがクラスタソフトウェアを実行していてはなりません。他のクラスタノードがアクティブであることをこのノードが検出した場合、ローカルノードは起動しません。
-
scadmin(1M) コマンドを使用して、クラスタの最初のノードを起動します。
# scadmin startcluster localnode clustername
コマンドが実行されるノードの名前と localnode が一致しない場合、startcluster オプションは動作しません。詳細は、scadmin(1M) のマニュアルページを参照してください。
次に例を示します。
phys-hahost1# scadmin startcluster phys-hahost1 haclust Node specified is phys-hahost1 Cluster specified is haclust =========================== WARNING============================ = Creating a new cluster = =============================================================== You are attempting to start up the cluster node "phys-hahost1" as the only node in a new cluster. It is important that no other cluster nodes be active at this time. If this node hears from other cluster nodes, this node will abort. Other nodes may only join after this command has completed successfully. Data corruption may occur if more than one cluster is active. Do you want to continue [y,n,?] y
reconfig.4013 エラーメッセージが表示された場合は、クラスタにすでにノードが存在するか、ほかのノードがまだ停止の途中にあります。動作していると思われるノードの状態を調べるには、そのノードで get_node_status(1M) コマンドを実行してください。
-
クラスタにほかのノードをすべて追加します。
クラスタの各ノードで次のコマンドを順番に実行します。
# scadmin startnode
次に示す reconfig.4015 エラーメッセージが表示された場合は、クラスタが存在しない可能性があります。scadmin startcluster localnode コマンドを使用して、クラスタを再起動してください。
SUNWcluster.clustd.reconf.4015 "Aborting--no existing or intact cluster to join."
パーティションまたはノードの障害も考えられます (2 つのノードの一方に障害が発生している間に、2 ノードクラスタに対して 3 つ目のノードの追加が試みられているなど)。これらの障害が発生した場合は、障害が落ち着くまで待ち、何か問題があれば解決し、その後クラスタへの追加を再度試みてください。
必要なソフトウェアパッケージが欠如している場合、コマンドは失敗し、コンソールに次のようなメッセージが表示されます。
Assuming a default cluster name of haclust Error: Required SC package `SUNWccm' not installed! Aborting cluster startup.
Sun Cluster ソフトウェアパッケージのインストールについては、『Sun Cluster 2.2 ソフトウェアのインストール』を参照してください。
クラスタとクラスタノードの停止
ノードをマルチユーザー以外のモードに設定する場合、あるいはノードを停止または再起動する場合は、Sun Cluster メンバーシップモニターを停止する必要があります。停止した後で、サイトに適した方法でノード管理を継続できます。
クラスタを停止するには、すべてのクラスタノードで scadmin stopnode コマンドを同時に実行し、すべてのノードのメンバーシップモニターを停止する必要があります。
-
メンバーシップモニターを停止できるのは、ローカルの Sun Cluster ノードが論理ホストを所有していない場合だけです。
-
1 つのノードでメンバーシップモニターを停止するには、haswitch(1M) コマンドを使用してその論理ホストを別のノードにスイッチオーバーし、次のコマンドを入力してメンバーシップモニターを停止します。
phys-hahost1# haswitch destination_host logicalhost phys-hahost1# scadmin stopnode |
scadmin stopnode コマンドの実行時にそのノードが論理ホストを所有している場合、メンバーシップモニターが停止される前に、その論理ホストをマスターできる別のノードに所有権が移されます。論理ホストのマスターとなることができる別のノードがダウンしている場合、scadmin stopnode コマンドはメンバーシップモニターを停止するとともにデータサービスを停止します。
scadmin stopnode コマンドの実行後、システムを再起動しても Sun Cluster は停止したままとなります。Sun Cluster を起動するには、scadmin startnode コマンドを実行する必要があります。
scadmin stopnode コマンドは、クラスタからノードを削除します。ほかに同時に障害が発生していないかぎり、残っているノードで定足数を満たした範囲で、いくつでもノードを停止できます (定足数が満たされないとクラスタ全体が停止します)。
ディスクの保守のためにノードを停止する場合は、第 10 章「Sun Cluster ローカルディスクの管理」で説明している起動ディスクの作業、またはボリュームマネージャのマニュアルで説明しているデータディスクの作業を行なって、起動ディスクまたはデータディスクを用意する必要もあります。
SBus カードの追加や削除などのハードウェア保守作業を行うには、Sun Cluster ノードを停止しなければならない場合があります。以下の節では、単一のノードまたはクラスタ全体を停止する方法を説明します。
注 -
クラスタに 2 つを超えるノードがあり、ストレージが直接接続されている場合は、クラスタの最後のノードがパニックを起こしたり、(stopnode 移行を行わずに) クラスタから異常な抜け方をすると、問題が起ることがあります。このような場合、すべてのノードがクラスタから削除されているため、クラスタは存在しなくなりますが、最後のノードは、異常な方法でクラスタから抜けたためノードロックをまだ保持している場合があります。この場合には、この後で scadmin startcluster コマンドを実行しても、ノードロックを取得できません。この問題を回避するには、クラスタを再起動する前に、「クラスタパニックの後にノードロックのフリーズを解除するには」の手順を使ってノードロックを手動で解除する必要があります。
1 つのクラスタノードで Sun Cluster を停止するには
-
データを使用できる状態にしておく必要がない場合は、論理ホスト (ディスクグループ) を保守モードにします。
phys-hahost2# haswitch -m logicalhost
詳細は、haswitch(1M) マニュアルページを参照してください。
注 -halt(1M) コマンドを使用すると、Sun Cluster ノードを停止し、フェイルオーバーによりバックアップノードで論理ホストサービスを復元できます。しかし、halt(1M) を実行すると、ノードに障害が発生する可能性があります。論理ホストの所有権をスイッチオーバーする方法としては、haswitch(1M) コマンドの方が信頼性があります。
-
クラスタ内のほかのノードで動作しているサービスを停止することなく、1 つのノードで Sun Cluster を停止します。
phys-hahost1# scadmin stopnode
注 -ノードを停止するときに、次のエラーメッセージが表示されることがあります。 in.rdiscd[517]: setsockopt (IP_DROP_MEMBERSHIP): Cannot assign requested address このエラーは、in.rdiscd デーモンと IP モジュール間のタイミングの問題に起因しています。悪影響はありませんので、無視しても問題ありません。
-
ノードを停止します。
phys-hahost1# halt
以上で、ノードの保守作業が行える状態になります。
すべてのノードの Sun Cluster を停止するには
環境状態が極めて悪い場合 (冷却システムの障害や稲光を伴った嵐が発生した場合など) は、Sun Cluster 構成内のすべてのノードを停止できます。
-
scadmin(1M) コマンドを使用して、すべてのノードでメンバーシップモニターを停止します。
このコマンドはクラスタの各ノードのコンソールで実行しますが、ノードがクラスタから切り離され、残りのノードが再構成を終了するまで、次のノードに進まないでください。
phys-hahost1# scadmin stopnode ...
-
phys-hahost1# halt ...
Sun Cluster ノードを停止するには
Sun Cluster ノードはどれも、halt(1M) コマンドまたは uadmin(1M) コマンドで停止できます。
ノードの停止時にメンバーシップモニターが動作している場合、そのノードは通常「Failfast タイムアウト」をとり、次のメッセージを表示します。
panic[cpu9]/thread=0x50f939e0: Failfast timeout - unit |
この状況を避けるには、ノードを停止する前にメンバーシップモニターを停止します。詳細は、「すべてのノードの Sun Cluster を停止するには」の作業を参照してください。
クラスタパニックの後にノードロックのフリーズを解除するには
クラスタに 2 つを超えるノードがあり、ストレージが直接接続されている場合は、クラスタの最後のノードがパニックを起こしたり、(stopnode 移行を行わずに) クラスタから異常な抜け方をすると、問題が起ることがあります。このような場合、すべてのノードがクラスタから削除されているため、クラスタは存在しなくなりますが、最後のノードは、異常な方法でクラスタから抜けたためノードロックをまだ保持している場合があります。この場合には、この後で scadmin startcluster コマンドを実行しても、ノードロックを取得できません。
この問題を回避するには、クラスタを再起動する前にノードロックを手動で解除する必要があります。クラスタが完全に異常終了した後に、ノードロックを手動で解除し、クラスタを再起動するには、次の手順を実行します。
-
root でクラスタ構成を表示します。
# scconf clustername -p
出力から次の行を探します。
clustername Locking TC/SSP, port : A.B.C.D, E
-
端末集配信装置 (TC) に対するノードロックの場合は、次の各手順を行います。
-
端末集配信装置 tc-name に対し telnet 接続を開始します。
$ telnet tc-name Trying 192.9.75.51... Connected to tc-name. Escape character is `^]'.
Return キーを押して処理を続けます。
-
cli (コマンド行インタフェース) を指定します。
Enter Annex port name or number: cli
-
root でログインします。
-
admin コマンドを実行します。
annex# admin
-
Port E をリセットします。
admin : reset E
-
telnet 接続を閉じます。
annex# hangup
-
手順 4 に進みます。
-
-
システムサービスプロセッサ (SSP) に対するノードロックの場合は、次の各手順を行います。
-
SSP に接続する。
$ telnet ssp-name
-
ユーザー ssp でログインします。
-
次のコマンドを使って clustername.lock ファイルの情報を表示します (このファイルは、/proc/csh.pid への記号リンクになっています)。
$ ls -l /var/tmp/clustername.lock
-
プロセス csh.pid を検索します。
$ ps -ef | grep csh.pid
-
ps -ef の出力に csh.pid プロセスがある場合は、次のコマンドを使ってこのプロセスを強制終了します。
$ kill -9 csh.pid
-
clustername.lock ファイルを削除します。
$ rm -f /var/tmp/clustername.lock
-
SSP からログアウトします。
-
-
クラスタを再起動します。
$ scadmin startcluster
RDBMS インスタンスの実行中におけるメンバーシップモニターの停止
データベースサーバーインスタンスをノード上で実行するには、あらかじめ startnode オプションを呼び出し、そのノードをクラスタに加える必要があります。stopnode オプションの呼び出しは、すべてのデータベースインスタンスを停止した後に行います。
注 -
Oracle7 Parallel Server、Oracle8 Parallel Server、または Informix XPS を使用している場合は、各製品のマニュアルで停止方法を参照してください。
ノードで Oracle7 または Oracle8 インスタンスが動作している間に stopnode コマンドを実行すると、stopnode はハングアップし、コンソールに次のメッセージが表示されます。
ID[vxclust]: stop: waiting for applications to end |
stopnode コマンドを正常に終了させるためには、Oracle7 または Oracle8 インスタンスを停止する必要があります。
ノード上で Informix-Online XPS インスタンスが動作している間に stopnode コマンドを実行すると、データベースがハングアップし、使用できなくなります。
論理ホストのスイッチオーバー
指定した論理ホスト (および関連するディスクグループ、データサービス、論理 IP アドレス) を宛先ホストによって指定されたノードにスイッチオーバーするには、haswitch(1M) コマンドを使用します。たとえば、次のコマンドは、論理ホスト hahost1 と hahost2 の両方が phys-hahost1 に、マスターされるようにスイッチオーバーします。
# haswitch phys-hahost1 hahost1 hahost2 |
論理ホストに複数のデータサービスが構成されている場合、それらのデータサービスの 1 つまたは一部だけを選択してスイッチオーバーすることはできません。論理ホスト上のデータサービスはすべてスイッチオーバーする必要があります。
注意 - 論理ホストのファイルシステムがビジーの間にフェイルオーバーやスイッチオーバーが発生すると、論理ホストのフェイルオーバーは部分的にしか発生しません。つまり、そのディスクグループの一部は元のターゲット物理ホストに残ったままです。論理ホストのファイルシステムがビジーの場合は、スイッチオーバーを行わないでください。また、NFS ロックとローカルロックが両方とも存在すると、ファイルロックが正しく機能しないため、どのホストのファイルシステムにもローカルでアクセスしないでください。
注 -
宛先ホストと論理ホストの現在のマスターは、クラスタのメンバーでなければなりません。この条件に当てはまらない場合、コマンドは失敗します。
自動スイッチオーバーの無効化
HA データサービスを提供するクラスタでは、ノード障害のためにマスターされている論理ホストが別のノードにスイッチオーバーされ、障害が発生したノードが後でクラスタに戻されるという状況に対し、「自動スイッチオーバー」を設定できます。スイッチオーバー先のホストでマスターが続行するように構成しないかぎり、論理ホストは自動的にそれらのデフォルトのマスターで再び制御されます。
論理ホストが本来のマスターに自動的にスイッチバックしないようにする場合は、-m オプション を指定して scconf(1M) コマンドを実行します。詳細は、scconf(1M) のマニュアルページを参照してください。
注 -
論理ホストの自動スイッチオーバーを無効にするには、クラスタのアクティブメンバーである単一のノードで scconf(1M) コマンドを実行します。
# scconf clustername -L logicalhost -n node1,node2 -g dg1 -i qe0,qe0,logaddr1 -m |
論理ホストを保守モードに設定する
ファイルシステムとディスクグループの管理作業では、保守モードを使用すると便利な場合があります。論理ホストのディスクグループを保守モードにするには、-m オプションを指定して haswitch(1M) コマンドを実行します。
注 -
論理ホストのほかの所有権と異なり、保守モードはノードの再起動を行なっても持続します。
次に、論理ホスト hahost1 を保守モードにする例を示します。
phys-hahost2# haswitch -m hahost1 |
このコマンドは、現在このディスクグループを所有している Sun Cluster ノード上の、hahost1 に対応するデータサービスを停止するとともに、すべての Sun Cluster ノード上の、hahost1 に対応する障害監視プログラムを停止します。このコマンドは、この論理ホスト上のすべての Sun Cluster ファイルシステムの umount(1M) も実行します。対応するデータサービスの所有権は解放されます。
このコマンドは、論理ホストとディスクグループの現在の所有権にかかわらず、どのホストでも実行できます。
保守モードでは、ディスクグループを所有する予定の物理ホストを指定してスイッチオーバーを実行することにより論理ホストを削除できます。たとえば、保守モードで hahost1 を削除するには次のコマンドを使用できます。
phys-hahost1# haswitch phys-hahost1 hahost1 |
クラスタ分割からの復元
ネットワーク分割のような複合的な障害が発生すると、クラスタメンバーの複数のサブセットがクラスタに留まる場合があります。通常、これらのサブセットは相互通信の一部が不可能になるか、まったく通信できない状態になります。このような場合、ソフトウェアは有効なクラスタを 1 つだけ残すように試みます。そのため、ソフトウェアはノードの一部またはすべてを停止させる場合があります。この節では、これらの決定に使用される基準について説明します。
定足数基準は、クラスタノードの本来のセット (構成ノードに限らない) の半分以上のメンバーを含むサブセットと決められています。サブセットが定足数基準に満たない場合、サブセット内のノードは自ら停止し、reconfig.4014 エラーメッセージが表示されます。定足数基準に満たない原因は、ネットワーク分割や、半分を超えるノードで同時に障害が発生したことなどが考えられます。
注 -
有効なクラスタには、プライベートネットワーク上で互いに通信できるノードだけが含まれます。
2 つのサブセットに分割された 4 ノードクラスタを考えてみましょう。この 2 つのサブセットの一方は 1 つのノード、他方は 3 つのノードから構成されています。各サブセットは、定足数基準を満たそうと試みます。最初のサブセットには本来の 4 つのうちの 1 つのノードしかなく、定足数基準を満たしていません。そのため、このサブセットのノードは停止します。2 つ目のサブセットには本来の 4 つのうちの 3 つのノードが含まれ、定足数基準を満たしているため、動作したままとなります。
別の例として、定足数デバイスを持つ 2 ノードクラスタを考えてみます。このような構成で分割が発生する場合、一方のノードと定足数デバイスで定足数基準が満たされるため、クラスタは起動したままとなります。
split-brain 分割 (VxVM のみ)
split-brain 分割は、1 つのサブセットにクラスタメンバーのちょうど半分が含まれる場合に発生します (split-brain 分割には 2 ノードクラスタ + 定足数デバイスというケースは含まれない)。Sun Cluster の最初のインストールでは、split-brain 分割が発生する場合の復元方法の選択を求められます。選択肢は ask と select です。ask を選択した場合、split-brain 分割の発生時にシステムはどのノードを起動しておくか尋ねてきます。select を選択した場合、システムはどのクラスタメンバーを起動しておくべきか自動的に選択します。
split-brain 分割の処理方法として自動選択ポリシーを選択した場合は、Lowest Nodeid または Highest Nodeid を選択できます。Lowest Nodeid を選択すると、最小の ID 値を持つノードが入ったサブセットが新しいクラスタになります。Highest Nodeid を選択すると、最大の ID 値を持つノードが入ったサブセットが新しいクラスタになります。詳細は、『Sun Cluster 2.2 ソフトウェアのインストール』の第 3 章を参照してください。
どちらの場合も、ほかのサブセットのノードは手動で停止する必要があります。
自動選択ポリシーを選択しなかった場合 (分割発生時にシステムが入力を求めてくる場合)、システムは次のエラーメッセージを表示します。
SUNWcluster.clustd.reconf.3010 "*** ISSUE ABORTPARTITION OR CONTINUEPARTITION *** Proposed cluster: xxx Unreachable nodes: yyy" |
さらに、10 秒ごとにコンソールに次のようなメッセージが表示されます。
*** ISSUE ABORTPARTITION OR CONTINUEPARTITION *** If the unreachable nodes have formed a cluster, issue ABORTPARTITION. (scadmin abortpartition <localnode> <clustername>) You may allow the proposed cluster to form by issuing CONTINUEPARTITION. (scadmin continuepartition <localnode> <clustername>) Proposed cluster partition: 0 Unreachable nodes: 1 |
自動選択処理を有効にしなかった場合は、新しいクラスタを選択してください。
注 -
split-brain 障害の後でクラスタを再起動するには、停止したノードが完全に起動するまで待ち (ノードの自動再構成または自動再起動が起きる場合があります)、その後 scadmin startnode コマンドを使用してそのノードをクラスタに戻します。
新しいクラスタを選択するには
-
どのサブセットで新しいクラスタを構成するかを決定します。停止させるサブセット内のノードの 1 つで、次のコマンドを実行します。
# scadmin abortpartition
1 つのノードで abortpartition コマンドを発行すると、クラスタメンバーシップモニター (CMM) がそのコマンドをそのパーティション内のすべてのノードに伝播します。そのため、パーティション内のすべてのノードがそのコマンドを受け取った場合、それらはすべて停止します。しかし、CMM が通信できないノードがパーティションに存在する場合、それらは手動で停止させる必要があります。停止しない残ったノードで、scadmin abortpartition コマンドを実行してください。
-
起動したままにしておくサブセット内のノードの 1 つで、次のコマンドを実行します。
# scadmin continuepartition
注 -新しいクラスタで別の障害が発生すると、さらに再構成が行われます。アクティブクラスタは、常に 1 つです。
/var ファイルシステムの管理
/var/adm/messages ファイルに Solaris と Sun Cluster ソフトウェアのエラーメッセージが書き込まれるために、/var ファイルシステムが満杯になることがあります。ノードの動作中に /var ファイルシステムが満杯になっても、ノードは継続して動作しますが、/var ファイルシステムが満杯のままでは、通常、そのノードにログインできません。ノードが停止すると、Sun Cluster は起動せず、ログインはできません。このような状況が発生した場合には、シングルユーザーモード (boot -s) で再起動する必要があります。
ノードが /var ファイルシステムが満杯であることを報告し、Sun Cluster サービスを継続して実行する場合は、次の作業を行なってください。
満杯の /var ファイルシステムを修復するには
この例では、phys-hahost1 に満杯の /var ファイルシステムが存在していると仮定します。
-
スイッチオーバーを行います。
問題が発生しているノードから論理ノードをすべて移動させます。
phys-hahost2# haswitch phys-hahost2 hahost1 hahost2
-
クラスタメンバーシップからそのノードを削除します。
phys-hahost1 にアクティブなログインがある場合は、次のコマンドを入力します。
phys-hahost1# scadmin stopnode
phys-hahost1 にアクティブなログインがない場合は、ノードを停止します。
-
(0) ok boot -s INIT: SINGLE USER MODE Type Ctrl-d to proceed with normal startup, (or give root password for system maintenance): <root_passward> Entering System Maintenance Mode Sun Microsystems Inc. SunOS 5.6 Generic August 1997
-
満杯のファイルシステムを消去するための通常の手順を実行します。
-
ファイルシステムが消去された後で、マルチユーザーモードに入ります。
# exit
-
scadmin startnode コマンドを使用して、そのノードを構成に再度加えます。
# scadmin startnode
Sun Cluster 構成における時間の管理
Solaris オペレーティング環境に Network Time Protocol (NTP) が付属している場合は、NTP を使用してクラスタノード間の時間の同期を管理することをお勧めします。
注意 - 管理者は、Sun Cluster 構成内のノードの時間は調整できません。date(1)、rdate(1M)、xntpdate(1M) コマンドによる時間変更は決して行わないでください。
Sun Cluster 環境では、クラスタノードは NTP クライアントとして動作できます。NTP を使用するには、クラスタの外で NTP サーバーの設定と構成を行う必要があります。クラスタノードは、NTP サーバーとしては構成できません。NTP クライアントと NTP サーバーについては、xntpd(1M) のマニュアルページを参照してください。
クラスタノードを NTP クライアントとして稼動させる場合、ntpdate(1M) を呼び出す crontab(1) エントリが存在しないことを確認してください。NTP クライアントでは、xntpd(1M) を実行する方がより安全です。このコマンドは、大きな進みや遅れを出すことなくクロックの同期を保ちます。
障害が発生したノードの交換
1 つのノードにハードウェア障害が発生し、新しいノードと交換が必要になった場合は、次の手順に従ってください。
注 -
この作業は、障害が発生したノードのルートディスクがまだ使用可能であることを想定しています。障害が発生したルートディスクがミラー化されていない場合は、ご購入先にお問い合わせください。
障害が発生したノードを交換するには
障害が発生したノードが使用不可能な場合は、手順 5から始めてください。
-
パラレルデータベース構成の場合は、データベースを停止します。
注 -データサービスについては、該当するマニュアルを参照してください。HA アプリケーションはすべて、scadmin stopnode コマンドで自動的に停止します。
-
クラスタコンソールを使用して、端末ウィンドウを開きます。
-
root として、端末ウィンドウに次のコマンドを入力します。
このコマンドは、クラスタからノードを削除し、Sun Cluster ソフトウェアを停止し、そのノード上のボリュームマネージャを無効にします。
# scadmin stopnode
-
ノード上のオペレーティングシステムを停止します。
必要に応じて、Solaris のシステム管理のマニュアルを参照してください。
-
ノードの電源を切ります。
詳細は、ハードウェアのサービスマニュアルを参照してください。
注意 - この時点で、障害が発生したノードからケーブルを抜かないでください。
-
障害が発生したノードから、起動ディスクを取り外します。
詳細は、ハードウェアのサービスマニュアルを参照してください。
-
起動ディスクを、新しいノードの同一のスロットに差し込みます。
ルートディスクは、以前と同じアドレスでアクセスできます。詳細は、ハードウェアのサービスマニュアルを参照してください。
注 -新しいノードの IP アドレスが、障害が発生したシステムと同じであることを確認してください。必要に応じて、起動サーバーまたは arp サーバーを変更し、新しい Ethernet アドレスに IP アドレスを割り当て直してください。詳細は、『NIS+ と DNS の設定と構成』を参照してください。
-
新しいノードに電源を入れます。
詳細は、ハードウェアのサービスマニュアルを参照してください。
-
ノードが自動的に起動する場合は、オペレーティングシステムを停止し、システムを OpenBoot PROM モニターの状態にします。
詳細は、shutdown(1M) のマニュアルページを参照してください。
-
すべての scsi-initiator-id が正しく設定されているか確認します。
scsi-initiator-id を設定する詳細な手順については、『Sun Cluster 2.2 Hardware Site Preparation, Planning, and Installation Guide』の第 4 章を参照してください。
-
新しいノードの電源を切ります。
詳細は、ハードウェアのサービスマニュアルを参照してください。
-
多重ホストディスクを障害が発生したノードと共有するほかのノードで、障害が発生したノードに接続されている 1 台のディスク拡張装置内のすべてのディスクを取り外します。
詳細は、ハードウェアのサービスマニュアルを参照してください。
-
ディスク拡張装置の電源を切ります。
詳細は、ハードウェアのサービスマニュアルを参照してください。
注 -障害が発生したノードを交換する間、システムコンソールに次のようなメッセージが表示される場合があります。このメッセージは問題についての説明ではない場合があるため、無視してください。
Nov 3 17:44:00 updb10a unix: WARNING: /sbus@1f,0/SUNW,fas@0,8800000/sd@2,0 (sd17): Nov 3 17:44:00 updb10a unix: SCSI transport failed: reason "incomplete": retrying ¥ command Nov 3 17:44:03 updb10a unix: WARNING: /sbus@1f,0/SUNW,fas@0,8800000/sd@2,0 (sd17): Nov 3 17:44:03 updb10a unix: disk not responding to selection
-
障害が発生したノードから SCSI ケーブルを抜き、新しいノードの対応するスロットに差し込みます。
詳細は、ハードウェアのサービスマニュアルを参照してください。
-
ディスク拡張装置の電源を入れます。
詳細は、ハードウェアのサービスマニュアルを参照してください。
-
手順 12で取り外したディスクをすべて、元のように設置します。
詳細は、ハードウェアのサービスマニュアルを参照してください。
-
ディスク拡張装置内のすべてのボリュームが回復するのを待ちます。その後、対応するミラーディスク拡張装置を取り外します。
ボリューム回復がいつ発生したかを確認するには、ボリュームマネージャソフトウェアを使用してください。
-
交換したノード (新しいノード) に電源を入れます。
詳細は、ハードウェアのサービスマニュアルを参照してください。
-
ノードを再起動し、システムが起動するのを待ちます。
<#0> boot
-
交換したノードの Ethernet アドレスを決定します。
# /usr/sbin/arp nodename
-
交換したノードのノード ID を決定します。
消去法によって、クラスタにどのノードが存在しないかを確認できます。ノード ID は、ノード 0 から始まる連続した番号にする必要があります。
# get_node_status sc: included in running cluster node id: 0 membership: 0 interconnect0: unknown interconnect1: unknown vm_type: vxvm vm_on_node: master vm: up db: down
-
すべてのクラスタノードで次のコマンドを入力し、クラスタシステムに交換ノードの新しい Ethernet アドレスを知らせます。
# scconf clustername -N node-id ethernet-address-of-host
手順 22 の例を使用した場合、ノード ID は 1 になります。
# scconf clustername -N 1 ethernet-address-of-host
-
交換したノードを起動します。
# scadmin startnode
-
パラレルデータベース構成の場合は、データベースを再起動します。
注 -データサービスについては、該当するマニュアルを参照してください。HA アプリケーションはすべて、scadmin startcluster コマンドと scadmin startnode コマンドで自動的に起動します。
障害が発生した端末集配信装置の交換
クラスタを動作させておくために、端末集配信装置が操作可能である必要はありません。端末集配信装置に障害が発生しても、クラスタ自体に障害が発生することはありません。
障害が発生した端末集配信装置は、クラスタに影響を与えることなく交換できます。新しい端末集配信装置が元の名前、IP アドレス、パスワードをそのまま使用する場合は、クラスタコマンドは不要です。新しい端末集配信装置にプラグを差し込むだけで、正常に動作します。
交換した新しい端末集配信装置が新しい名前、IP アドレス、パスワードを使用する場合は、「TC/SSP 情報の変更」で説明しているように、scconf(1M) コマンドを使用してクラスタデータベース内のこの情報を変更してください。この作業は、クラスタを動作させたまま、クラスタの処理に影響を与えることなく行えます。
クラスタ構成データベースの管理
クラスタ構成データベース (CCD) の管理作業には、ccdadm(1M) コマンドを使用します。詳細は、ccdadm(1M) のマニュアルページを参照してください。
注 -
ccdadm(1M) コマンドは、root として任意のアクティブノードで実行できます。このコマンドは、クラスタ内のすべてのノードを更新します。
クラスタ構成が更新されるごとに、ccdadm(1M) に -c (checkpoint) オプションを使用し、CCD の状態を記録することをお勧めします。Sun Cluster フレームワークは、論理ホストと HA データサービスに関連した構成データを格納するために CCD を頻繁に使用します。CCD は、PNM が使用するネットワークアダプタ構成データの格納にも使用されます。クラスタの HA 構成または PNM 構成を変更した後は、将来障害が発生する場合に起き得る問題への対応策として、-c オプションを使用して CCD の現在の有効スナップショットをキャプチャすることを強くお勧めします。この必要性は、データベース管理者やシステム管理者が、予測できない状況によって起きる将来のデータ損失を防ぐためにデータを頻繁にバックアップしなければならないのと同じです。
CCD の全体的な整合性を検証するには
-
動的 CCD を検証する場合は、-v オプションを実行します。
このオプションは、すべてのクラスタノード上の各 CCD コピーの整合性記録を比較します。この比較により、すべてのノードに渡ってデータベースに矛盾がないことを検証できます。この検証が行われる間、CCD の照会は無効になります。
# ccdadm clustername -v
CCD のバックアップをとるには
-
-c オプションは、週に 1 度実行するか、CCD のバックアップごとに実行します。
このオプションは、動的 CCD のバックアップコピーを作成します。作成したバックアップコピーは、-r オプションで動的 CCD を復元する場合に使用できます。詳細は、「CCD を復元するには」を参照してください。
注 -CCD をバックアップする場合は、ccdadm -c コマンドを実行する前にすべての論理ホストを保守モードにしてください。論理ホストは、CCD データベースの復元時にも保守モードにする必要があります。したがって、復元状態に近いバックアップファイルを用意すれば、不要なエラーや問題を防止できます。
# ccdadm clustername -c checkpoint-filename
checkpoint-filename には、バックアップコピーの名前を指定します。
CCD を復元するには
CCD が破損した場合は、-r オプションを指定して ccdadm(1M) を実行してください。このオプションは、動的 CCD の現在のコピーを破棄し、指定される復元ファイルの内容を使用して復元を行います。このコマンドは、クラスタの再起動時に、ccdd(1M) 再構成アルゴリズムが有効な CCD コピーを選択するのに失敗した後、動的 CCD を初期化または復元する場合に使用してください。復元が終わると、CCD は有効と見なされます。
-
必要に応じて、定足数を無効にします。
詳細は 「CCD 定足数を有効 / 無効にするには」を参照してください。
# ccdadm clustername -q off
-
論理ホストを保守モードにします。
# haswitch -m logicalhosts
-
CCD を復元します。
restore-filename には、復元するファイルの名前を指定します。
# ccdadm clustername -r restore-filename
-
必要に応じて、CCD 定足数を有効に戻します。
# ccdadm clustername -q on
-
論理ホストをオンラインに戻します。
次に例を示します。
# haswitch phys-host1 logicalhost1 # haswitch phys-host2 logicalhost2
CCD 定足数を有効 / 無効にするには
-
一般に、クラスタソフトウェアは、CCD を更新する前に定足数を必要とします。-q オプションを使用すると、この制限を無効にし、任意の数のノードで CCD を更新できます。
-q オプションは、動的 CCD の更新または復元時に定足数を有効または無効にする場合に使用します。quorum_flag は、オン (定足数を有効にする) とオフ (定足数を無効にする) のトグルになっています。定足数は、デフォルトでは有効に設定されています。
たとえば、3 つの物理ノードが存在する場合、更新を行うには少なくても 2 つのノードが必要です。ハードウェア障害のために 1 つのノードしか起動できない場合は、クラスタソフトウェアは CCD の更新を認めません。しかし、ccdadm -q コマンドを実行すると、ソフトウェアの制御を無効にして CCD を更新できます。
# ccdadm clustername -q on|off
CCD を浄化 (purify) するには
-
-p オプションは、CCD データベースファイルを浄化 (内容を検証して構文をチェックする) します。このオプションは、CCD データベースファイルに構文エラーがある場合に実行してください。
# ccdadm -p CCD-filename
-p オプションは、指定されたファイル内の書式エラーを報告し、修正されたコピーを .pure という拡張子の付いたファイルに書き込みます。この「浄化された」ファイルは、新しい CCD データベースとして復元に使用できます。詳細は、「CCD を復元するには」を参照してください。
CCD の障害追跡
システムは、CCD 内のエラーを /var/opt/SUNWcluster/ccd/ccd.log ファイルに記録します。重大なエラーメッセージは、クラスタコンソールにも渡されます。さらに、クラッシュというまれな状況が発生した場合は、/var/opt/SUNWcluster/ccd にコアファイルが作成されます。
次に、ccd.log ファイルの例を示します。
lpc204# cat ccd.log Apr 16 14:54:05 lpc204 ID[SUNWcluster.ccd.ccdd.1005]: (info) starting `START' transition with time-out 10000 Apr 16 14:54:05 lpc204 ID[SUNWcluster.ccd.ccdd.1005]: (info) completed `START' transition with status 0 Apr 16 14:54:06 lpc204 ID[SUNWcluster.ccd.ccdd.1005]: (info) starting `STEP1' transition with time-out 20000 Apr 16 14:54:06 lpc204 ID[SUNWcluster.ccd.ccdd.1000]: (info) Nodeid = 0 Up = 0 Gennum = 0 Date = Feb 14 10h30m00 1997 Restore = 4 Apr 16 14:54:06 lpc204 ID[SUNWcluster.ccd.ccdd.1002]: (info) start reconfiguration elected CCD from Nodeid = 0 Apr 16 14:54:06 lpc204 ID[SUNWcluster.ccd.ccdd.1004]: (info) the init CCD database is consistent Apr 16 14:54:06 lpc204 ID[SUNWcluster.ccd.ccdd.1001]: (info) Node is up as a one-node cluster after scadmin startcluster; skipping ccd quorum test Apr 16 14:54:06 lpc204 ID[SUNWcluster.ccd.ccdd.1005]: (info) completed `STEP1' transition with status 0 |
次の表は、主なエラーメッセージと問題の解決方法を示しています。エラーメッセージの一覧は、『Sun Cluster 2.2 Error Messages Manual』を参照してください。
表 4-1 クラスタ構成データベースの主なエラーメッセージ
共有ディスクの予約 (VxVM)
ボリュームマネージャによって管理されるディスク一覧は、障害防御用のデバイスセットとして使用されます。システム内にディスクグループが存在しない場合、障害防御用のデバイスは存在しません (保護すべきデータが実際に存在しないため)。しかし、ノードがクラスタに存在しない間に新しい共有ディスクグループがインポートされる場合には、追加分のデバイスセットが障害防御を必要とすることをクラスタに知らせる必要があります。
共有デバイスを予約するには (VxVM)
-
ノードがクラスタに存在しない間に新しい共有ディスクグループがインポートされる場合、追加分のデバイスセットが障害防御を必要とすることをクラスタに知らせる必要があります。これは、新しいディスクグループにアクセスできるノードから scadmin resdisk コマンドを実行して行えます。
# scadmin resdisks
同じデバイスセットに接続できるノードがクラスタメンバーシップにほかに存在しない場合、このコマンドは 1 つのノードに接続されたすべてのデバイスを予約します。つまり、そのデバイスに実際に直結されたすべてのノードのうち 1 つのノードだけがクラスタメンバーシップに入っている場合にかぎり予約が行われます。この条件が満たされない場合、scadmin resdisks コマンドは無効です。このコマンドは、クラスタ再構成が進行中の場合も失敗します。共有デバイスの予約は、この唯一のノードが停止した場合や、その共有デバイスに直結されたほかのノードがクラスタメンバーシップに加わる場合に自動的に解除されます。
注 -すべてのノードがクラスタに存在する間に共有ディスクグループがインポートされる場合は、scadmin resdisks コマンドを実行する必要はありません。予約と障害防御は、完全なクラスタメンバーシップが存在する場合には適用されません。
ただし、共有ディスクグループがデポートされると、デポートされたディスクグループ内の共有デバイスに対する予約は解除されません。これらの予約は、予約を行うノードが停止されるか、デバイスを共有するほかのノードがクラスタに加わるまでは解除されません。
デポートされたディスクグループに属するディスクをすぐに使用できるようにするには、共有ディスクグループをデポートした後、すべてのディスクノードで、連続して次の 2 つのコマンドを入力します。
# scadmin reldisks # scadmin resdisks
最初のコマンドは、すべての共有デバイスの予約を解除します。2 つ目のコマンドは、現在インポートされているディスクグループセットにもとづいて実際に再予約を行い、デポートされたディスクグループに関連付けられた一連のディスクを自動的に除外します。
- © 2010, Oracle Corporation and/or its affiliates