9 ACSLS クラスタの操作

Solaris Cluster は、1 つのサーバーノードから別のサーバーノードへと動作制御を移動させることで、重大な障害シナリオが発生した場合に自動的にシステムを回復するように設計されています。ただし、Solaris システムで発生するほとんどの障害では、回復するために完全なシステムのスイッチオーバーアクションは必要ありません。

  • ネットワーク通信で発生した障害は、Solaris IPMP によって通知なしに迅速に処理されます。

  • システムディスクの障害は、Solaris ZFS によって通知なしに自動的に処理されます。

  • 接続されているストレージアレイ内の単一のディスクドライブで発生した障害は、ストレージアレイのファームウェアによって自動的に回復されます。ストレージアレイにディスク障害から回復する機能が不足している場合は、Solaris ZFS の制御下で、ミラー化構成での代替ドライブへの中断なしのディスク I/O が実現されます。

  • 共有アレイへの HBA ポートに障害が発生した場合は、Solaris によって自動的に代替ポートに切り替えられます。同様に、共有アレイ上のコントローラモジュールに障害が発生した場合や、相互接続ケーブルが切断された場合も、Solaris によって即座にディスクリソースに接続している代替パスに戻されます。

  • ライブラリ通信パスの障害は、ACSLS のデュアル TCP/IP ロジックによって自動的に回復されます。障害が発生したライブラリコントローラカードからの操作は、ライブラリの冗長電子装置 (RE) に関連付けられた ACSLS HA ロジックによって自動的に回復されます。

  • ACSLS で動作している複数のプロセスのいずれかにエラーが発生した場合は、ACSLS デーモンによって即座にエラーが発生したプロセスがリブートされます。

  • ACSLS デーモン自体にエラーが発生した場合や、残りの ACSLS サービスのいずれかの動作が停止した場合は、Solaris Service Management Facility (SMF) によって即座にエラーが発生したサービスが再起動されます。

前述のシナリオはすべて、Solaris Cluster が関与せずに迅速かつ自動的に処理されます。ただし、その他の重大な障害によってアクティブなサーバーノード上の ACSLS 操作が影響を受ける場合は、制御を代替ノードに切り替えるように、ACSLS HA から Solaris Cluster に指示されます。

ACSLS HA は起動後に、システムを 1 分に 1 回調査して、次のイベントのいずれかが発生していないかどうかを監視します。

  • 接続されているライブラリへの通信が失われた。

  • ACSLS 論理ホストへのネットワーク接続が失われた。

  • クライアント呼び出し用の RPC リスナーポートへの接続が失われた。

  • ACSLS ファイルシステムへのアクセスが失われた。

  • ACSLS SMF サービスの保守状態を回復できない。

前述のイベントのいずれかが発生すると、Cluster のフェイルオーバーがトリガーされます。また、アクティブなサーバーノード上のシステムに致命的な状況が発生した場合にも、Solaris Cluster はフェイルオーバーを実行します。

ACSLS のクラスタ制御の開始

クラスタのフェイルオーバー制御をアクティブにするには:

# cd /opt/ACSLSHA/util
# ./acsAgt configure

ユーティリティーでは論理ホスト名の入力を求めるプロンプトが表示されます。論理ホストが /etc/hosts ファイルで定義されていること、および対応する IP アドレスが、ACSLS HA 用の Solaris システムの構成の章で定義されている ipmp グループにマップされていることを確認してください。acsAgt configure を実行する前に、zpool list を使用して、acslspool が現在のサーバーノードにマウントされていることを確認します。

このアクションによって、ACSLS のクラスタ制御が開始されます。Solaris Cluster はシステムをモニターして、ACSLS の詳細と Solaris システム全般の健全性を確認するために 1 分に 1 回プローブします。致命的な状況であると判断されると、代替ノード上でアクションが開始されます。

ACSLS リソースグループのクラスタステータスをチェックするには:

# clrg status

次のことが表示されます。

  • 各ノードのステータスを表示します。

  • アクティブなノードを特定します。

  • フェイルオーバーアクションが一時停止されているかどうかを示します。

acsls-storage へのフェイルオーバーポリシーの設定

アクティブノードと共有 RAID ディスクデバイスとの通信が失われた場合は常に、そのノードをリブートするポリシーを acsls-storage リソースに設定することをお勧めします。このアクションにより、アクティブノードはディスクに接続できなくなると制御を放棄するため、Solaris Cluster が制御を代替ノードに渡せるようになります。Failover_mode を SOFT から HARD に設定することで、共有ストレージデバイスへの通信が失われたときは常にアクティブノードが確実にリブートされるようになります。

既存の Failover_mode を表示するには、次のコマンドを実行します。

#  clrs show -v acsls-storage | grep Failover

Failover_mode を次のように HARD に設定します。

# clrs set -p Failover_mode=HARD  acsls-storage

クラスタ制御下での ACSLS の操作および保守

クラスタ制御がアクティブになると、通常の方法で ACSLS を操作できます。ACSLS の起動および停止には、標準の acsss 制御ユーティリティーを使用します。クラスタ制御下では、ユーザーはスタンドアロンの ACSLS サーバーでアプリケーションを起動および停止するときと同じ方法で、ACSLS サービスを起動および停止します。操作は、次のような標準の acsss コマンドを使用して管理されます。

acsss enable
acsss disable
acsss db

これらのコマンドを使用して手動で acsss サービスを起動または停止しない場合は、Solaris Cluster がフェイルオーバーアクションに介入します。同様に、Solaris SMF コマンド (svcadm など) を使用しない場合も Cluster が介入します。acsss サービスが異常終了した場合や中断された場合は常に、Cluster ではなく、主に SMF がこれらのサービスの再起動に対処します。

Solaris Cluster は、次の状況が発生した場合にのみ、隣接するノード上の制御の復元に介入します。

  • ACSLS ファイルシステムとの通信が失われた。

  • すべての冗長化されたパブリック Ethernet ポートとの通信が失われた。

  • 指定したライブラリとの通信が失われ、回復できない。

クラスタ制御の一時停止

保守アクティビティーによってクラスタの不要なフェイルオーバーイベントがトリガーされるおそれがある場合は、acsls リソースグループのクラスタ制御を一時停止できます。

クラスタ制御を一時停止するには:

# clrg suspend acsls-rg

リソースグループが一時停止されている間は、このようなアクションがトリガーされるような状況が発生しても、Solaris Cluster は隣接するノードへの制御の切り替えを試みません。

この一時停止により、ライブラリの生成がフル稼働中の場合でも、より侵襲的なシステム修復が可能です。

一時停止モード中にアクティブなノードのリブートが発生した場合は、リブート後に acslspool がマウントされず、ACSLS 操作が停止されます。このような状況を解消するには、クラスタ制御を再開します。

クラスタ制御を再開するには:

# clrg resume acsls-rg

共有ディスクリソースが現在のノードにマウントされている場合は、正常な操作が再開されます。ただし、アクティブ化時に Solaris Cluster で、zpool がマウントされていないことが検出された場合は、隣接するノードに制御が即座に切り替えられます。隣接するノードにアクセスできない場合、制御は現在のノードに切り替わります。クラスタは acslspool をマウントしてこのノード上で ACSLS サービスを起動しようとします。

ACSLS HA クラスタの電源切断

次の手順では、ACSLS HA システムの電源を切断する必要がある場合の、安全な電源切断シーケンスについて説明します。

  1. クラスタ内のアクティブなノードを特定します。

    # clrg status

    オンラインのノードを検索します。

  2. root としてアクティブなノードにログインし、ACSLS リソースグループの Solaris Cluster 制御を停止します。

    # clrg suspend acsls-rg

  3. ユーザー acsss に切り替え、acsss サービスを停止します。

    # su - acsss
$ acsss shutdown

  4. acsss としてログアウトし、ノードの電源を正常に切断します。

    $ exit
# init 5

  5. 代替ノードにログインし、init 5 を使用して電源を切断します。

  6. 物理的な電源スイッチを使用して、共有ディスクアレイの電源を切断します。

一時停止された ACSLS クラスタシステムの電源投入

制御されたシャットダウンの前にアクティブであったノード上で ACSLS 操作を復元するには:

  1. ローカルで物理的な電源スイッチを使用するか、またはリモートで Sun Integrated Lights Out Manager を使用して、両方のノードの電源を投入します。

  2. 共有ディスクアレイの電源を投入します。

  3. root として、どちらか一方のノードにログインします。

  4. acsss としてログインするか、$ACS_HOME ディレクトリを一覧表示してみれば、どちらか一方のノードに共有ディスクリソースがマウントされていないことがわかります。クラスタのモニタリングを再開するには、次のコマンドを実行します。

    # clrg resume acsls-rg

    このアクションによって、Solaris Cluster は、システムをシャットダウンしたときにアクティブであったノードに共有ディスクをマウントします。また、このアクションによって自動的に acsss サービスがリブートし、通常の操作が再開されます。

単一ノードクラスタの作成

ほかのノードの保守中に、あるノード上のスタンドアロンサーバー環境から ACSLS 操作を続行する必要がある場合があります。これは、ハードウェアの保守、オペレーティングシステムのアップグレード、または Solaris Cluster へのアップグレードの状況に当てはまります。

次の手順を使用して、スタンドアロンの ACSLS サーバーを作成します。

  1. 非クラスタモードで目的のノードをリブートします。

    # reboot -- -x

    SPARC サーバーで Open Boot Prom (OBP) からブートして非クラスタモードになるには:

    ok: boot -x

    X86 サーバー上で、GRUB ブートメニューを編集する必要があります。

    1. システムの電源を投入します。

    2. GRUB ブートメニューが表示されたら、「e」 (編集) を押します。

    3. サブメニューから矢印キーを使用して、「kernel /platform/i86pc/multiboot」を選択します。これを選択したら、「e」を押します。

    4. 編集モードで、マルチブートオプション kernel /platform/i86pc/multiboot -x に -x を追加して、「return」をクリックします。

    5. マルチブートオプション -x が選択されている状態で「b」を押して、そのオプションでブートします。

  2. ブートサイクルが完了したら、root としてログインし、ACSLS Z プールをインポートします。

    # zpool import acslspool

    ディスクリソースが別のノードに関連付けられたままになっている場合は、必要に応じて、-f (強制) オプションを使用します。

    # zpool import -f acslspool

  3. acsss サービスを起動します。

    # su - acsss
$ acsss enable