本文に進む 日本−日本語
日本HPホーム 製品とサービス お客様サポート/ ダウンロード ソリューション ご購入の方法
≫ お問い合わせ
詳細検索オプション
日本HPホーム
 Serviceguard の管理 > 第7章 クラスタとパッケージの管理

クラスタの再構成
≫ 

テクニカル ドキュメント

PDF版
≫ 関連ドキュメント
≫ フィードバック
ここから本文が始まります

 ≫ 目次

 ≫ 索引

spacerspacerspacer
spacer
spacer
  		 
 

クラスタの再構成は、停止中でも稼働中でも行えます。操作によっては、クラスタの停止中にのみ実行できるものもあります。表 7-1 「クラスタ構成に対する変更」に、各種の変更で前提となるクラスタ状態を示します。

表 7-1 クラスタ構成に対する変更

クラスタ構成の変更

クラスタの状態の必要条件

新規ノードの追加

このクラスタのメンバーとして構成されているすべてのノードが稼働している。

ノードの削除

使用不能または到達不能なノードでも削除できる。

ボリュームグループの追加

クラスタは稼働していてもよい。

ボリュームグループの削除

クラスタは稼働していてもよい。そのボリュームグループを使うパッケージは、構成を変更するまで再起動できない。

Maximum Conifgured Packages の変更

クラスタは稼働していてもよい。

クォーラムサーバー構成の変更

クラスタが稼働していない。

クラスタロック構成の変更 (LVM ロックディスク)

クラスタは特定の条件で動作していてもよい。「クラスタロック構成のアップデート」を参照。

クラスタロック構成の変更 (ロック LUN)

クラスタが稼働していない。「オフラインでのクラスタロック LUN 構成のアップデート」を参照。

クラスタ構成に NIC とその IP アドレス (存在する場合) を追加

クラスタは稼働していてもよい。「稼働中のクラスタのクラスタネットワーク構成の変更」を参照。

クラスタ構成から NIC とその IP アドレス (存在する場合) を削除

クラスタは稼働していてもよい。

「稼働中のクラスタのクラスタネットワーク構成の変更」を参照。

システムから NIC を削除する場合には、「ノードからの LAN または VLAN インタフェースの削除」を参照。

既存のインタフェースの指定を HEARTBEAT_IP から STATIONARY_IP に変更、またはその逆

クラスタは稼働していてもよい。「稼働中のクラスタのクラスタネットワーク構成の変更」を参照。

クラスタで使われている NIC の IP アドレスの再構成

インタフェースをクラスタ構成から削除し、再構成し、そして再びクラスタ構成に戻す必要がある。「留意事項」を参照。クラスタは稼働したままでもよい。

NETWORK_FAILURE_DETECTION パラメータの変更 (「LAN インタフェースの監視と障害の検出」を参照)

クラスタは稼働していてもよい。

NETWORK_POLLING_INTERVAL の変更

クラスタは稼働していてもよい。

HEARTBEAT_INTERVAL、NODE_TIMEOUT、AUTO_START_TIMEOUT の変更

CVM 環境以外であれば、クラスタは稼働していてもよい。下記の注記を参照。

アクセス制御ポリシーの変更

クラスタとパッケージは稼働していてもよい。

Faster Failover 製品の有効化/無効化によるフェイルオーバーの最適化

クラスタが稼働していない。

 

注記: CVM または CFS を使用している場合、クラスタが起動している最中は HEARTBEAT_INTERVAL、NODE_TIMEOUT または AUTO_START_TIMEOUT を変更しないでください。これらを変更すると、クラスタの起動時の CVM スタックに対してのみ通知するアグリゲーションフェイルオーバー時間に影響が出るためです。

クラスタロック構成のアップデート

クラスタノードを HP-UX 11i v3 で利用可能になった柔軟なアドレッシング方式 (「デバイスファイル名について (デバイス特殊ファイル)」を参照) に移行する場合など、クラスタロック物理ボリュームのデバイスファイル名を変更する必要がある場合には、以下に示す手順を実行します。

オンラインでのクラスタロックディスク構成のアップデート

以下の条件下では、クラスタロック物理ボリュームのデバイスファイル名 (DSF) (つまり、クラスタ構成ファイルの FIRST_CLUSTER_LOCK_PV パラメータと SECOND_CLUSTER_LOCK_PV パラメータの値) を、クラスタを停止させずに変更することができます。

  • 物理ディスク自体は変更しない

  • クラスタ構成ファイルにすでにある値を変更し、追加や削除は行わない

  • 変更しようとしているノードは、クラスタ内で動作していない (つまり、cmhaltnode を使うか、Serviceguard Manager で [ノードの停止] を選択することで停止済みである)

  • クラスタノードで Serviceguard 11.17.01 以降が動作している

クラスタを停止させずに FIRST_CLUSTER_LOCK_PV パラメータと SECOND_CLUSTER_LOCK_PV パラメータの値をアップデートするには、以下のようにします。

  1. 変更を行うノードを停止 (cmhaltnode) します。

  2. クラスタ構成ファイルで、このノードの FIRST_CLUSTER_LOCK_PV と SECOND_CLUSTER_LOCK_PV の値を変更します。

  3. cmcheckconf を実行して構成をチェックします。

  4. cmapplyconf を実行して構成を適用します。

  5. ノードを再起動します (cmrunnode)。

  6. 変更を行う各ノードでこの手順を繰り返します。

物理ディスクの交換については、「ロックディスクの交換」を参照してください。

オフラインでのクラスタロックディスク構成のアップデート

前述した、構成をオンラインでアップデートするための条件を満たすことができない場合や、クラスタの停止中に変更を行う場合は、以下のようにします。

  1. クラスタを停止します。

  2. クラスタ構成ファイルで、各ノードの FIRST_CLUSTER_LOCK_PV と SECOND_CLUSTER_LOCK_PV の値を変更します。

  3. cmcheckconf を実行して、構成をチェックします。

  4. cmapplyconf を実行して、構成を適用します。

物理ディスクの交換については、「ロックディスクの交換」を参照してください。

オフラインでのクラスタロック LUN 構成のアップデート

ロック LUN 構成を変更する前に、クラスタを停止する必要があります。以下の手順を実行します。

  1. クラスタを停止します。

  2. クラスタ構成ファイル内の各ノードの CLUSTER_LOCK_LUN の値を変更します。

  3. cmcheckconf を実行して、構成を確認します。

  4. cmapplyconf を実行して、構成を適用します。

物理デバイスの交換についての詳細は、「ロック LUN の交換」を参照してください。

停止したクラスタの再構成

以下の手順では、クラスタが停止している間に、そのクラスタの構成を恒久的に変更できます。表 7-1 「クラスタ構成に対する変更」で「クラスタが稼働していない」と記された変更は、 必ずこの手順に従って行いますが、その他のクラスタ構成も同様の手順で変更できます。

クラスタ構成の恒久的な変更を行うには、次の手順に従います。

  1. すべてのノードでクラスタを停止します。Serviceguard Manager の [クラスタの停止] コマンドを使うか、コマンド行で cmhaltcl を実行します。

  2. 第5章 「HA クラスタの構成」を参照して、クラスタをいずれか 1 つのノード上で再構成します。その際には、Serviceguard Manager を使用するか、コマンド行で cmquerycl を実行して、生成した ASCII 形式の構成ファイルを編集します。

  3. クラスタ構成ファイルに指定されているすべてのノードの電源が入っていて、ノードにアクセスできることを確かめます。バイナリ形式クラスタ構成ファイルを全ノードにコピーするには、Serviceguard Manager の [適用] ボタンを使うか、コマンド行で cmapplyconf を実行します。これにより、以前のバージョンのバイナリ形式クラスタ構成ファイルが上書きされます。

  4. すべてのノードまたは一部のノードでクラスタを起動します。Serviceguard Manager の [クラスタの実行] コマンドを使うか、コマンド行で cmruncl を実行します。

稼働中のクラスタの再構成

この項では、クラスタの稼働中に、クラスタ構成を変更する方法について説明します。ただし以下の制限に注意してください。

  • クラスタの稼働中にクォーラムサーバーやロックディスクの構成を変更することはできません。

  • クラスタからアクティブなノードを削除することはできません。先にノードを停止しておかなければなりません。

  • クラスタ構成からアクティブなボリュームグループを削除することはできません。あらかじめ、そのボリュームグループを使用するすべてのパッケージを停止して、ボリュームが非アクティブであることを確認してから削除します。

  • 到達できないノード (ネットワークから完全に切り離されているノードなど) に対して唯一可能な構成変更は、そのノードをクラスタ構成から削除することです。到達できないノードに依存するパッケージがある場合は、パッケージの構成も変更しないとそのノードを削除することはできません。これらすべては、1 回の構成要求 (cmapplyconf コマンド) で行わなければなりません。

パッケージ構成の変更については、後述する各項を参照してください。

稼働中のクラスタへのノードの追加

稼働中のクラスタにノードを追加するには、Serviceguard Manager を使うか、以下の例に示す Serviceguard コマンドを使います。

この例では、ノード ftsys8 と ftsys9 は稼働中の cluster1 というクラスタにすでに構成されていて、ftsys10 というノードを追加します。

  1. 以下のコマンドを使用して、既存のクラスタ構成の最新コピーを一時ファイルに保存します。

    cmgetconf -c cluster1 temp.ascii

  2. 構成するノードの新しいセットを指定して、新しい構成のテンプレートを作成します。ノード名 (39 バイト以下) は完全ドメイン名では指定しないでください。たとえば、ftsys8.cup.hp.com ではなく、ftsys8 と指定します。

    cmquerycl -C clconfig.ascii -c cluster1 \ -n ftsys8 -n ftsys9 -n ftsys10

  3. clconfig.ascii ファイルをエディターで開いて、新規ノードの情報が正しいか確認します。

  4. 新しい構成を検証します。

    cmcheckconf -C clconfig.ascii

  5. 構成の変更を適用し、新しいバイナリ形式構成ファイルを全クラスタノードに配布します。

    cmapplyconf -C clconfig.ascii

cmrunnode コマンドを使用して新しいノードを起動し、必要な場合は、/etc/rc.config.d/cmcluster ファイル内の AUTOSTART_CMCLD パラメータに 1 を設定して、クラスタを再起動するたびにそのノードが自動的にクラスタに結合するようにします。

注記: Veritas CVM をサポートするシステムで、Veritas CVM を使っている稼働中のクラスタにノードを追加する場合には、ノードには CVM ディスクグループのすべてのディスクドライブを前もって接続しておく必要があります。ノードをクラスタに参加させるときに、そのディスクグループはインポート可能になります。

稼働中のクラスタからのノードの削除

稼働中のクラスタからノードを削除するには、Serviceguard Manager を使うか、次に示す Serviceguard コマンドを使います。以下の制限があります。

  • ノードは停止している必要があります。「稼働中のクラスタのメンバーからノードを外す」を参照してください。

  • 削除するノードが到達不能なノード (LAN から切り離されているノードなど) のときは、そのノードを指定しているパッケージがない場合に限りノードを削除できます。到達不能なノードに依存するパッケージがある場合は、クラスタを停止するか、次項で説明するように、Serviceguard コマンドを使用します。

以下の手順に従い、HP-UX コマンドを使用してノードを削除します。この例では、ノード ftsys8、ftsys9、ftsys10 は稼働中の cluster1 というクラスタにすでに構成されていて、これからノード ftsys10 を削除します。

注記: ノードをクラスタから削除するには、同一クラスタ内の別のノードから cmapplyconf コマンドを実行します。削除するノードでコマンドを実行すると、エラーメッセージが表示されます。

  1. 以下のコマンドを使用して、既存のクラスタ構成の最新コピーを一時ファイルに保存します。

    cmgetconf -c cluster1 temp.ascii

  2. 構成するノードの新しいセット (ftsys10 を除く) を指定して、新しい構成のテンプレートを作成します。

    cmquerycl -C clconfig.ascii -c cluster1 -n ftsys8 -n ftsys9

  3. clconfig.ascii ファイルを開いて、クラスタに残っているノードの情報をチェックします。

  4. 削除するノード (この例では ftsys10) を停止します。

    cmhaltnode -f -v ftsys10

  5. 新しい構成を検証します。

    cmcheckconf -C clconfig.ascii

  6. ftsys8 または ftsys9 から構成の変更を適用し、新しいバイナリ形式構成ファイルを全クラスタノードに配布します。

    cmapplyconf -C clconfig.ascii

注記: 多くのパッケージが動作するように構成されている到達不能なノードを削除しようとすると、特にパッケージが大量の EMS リソースを使用する場合に、以下のメッセージが表示されることがあります。
The configuration change is too large to process while the cluster is running. 
Split the configuration change into multiple requests or halt the cluster.

このような場合は、クラスタを停止してから到達不能なノードを削除する必要があります。

稼働中のクラスタのクラスタネットワーク構成の変更

実行可能な操作

実行可能なオンライン操作には、以下のものがあります。

  • ネットワークインタフェースをその HEARTBEAT_IP または STATIONARY_IP と共に追加

  • 待機インターフェスの追加

  • ネットワークインタフェースをその HEARTBEAT_IP または STATIONARY_IP と共に削除

  • 待機インタフェースの削除

  • 既存インタフェースの指定の HEARTBEAT_IP から STATIONARY_IP への変更、またはその逆

  • NETWORK_POLLING_INTERVAL の変更

  • NETWORK_FAILURE_DETECTION パラメータの変更

  • 1 回の操作 (cmapplyconf) での上記の操作の組み合わせ (ただし、以下の制限があります)

留意事項

以下の制限があります。

  • すべてのハートビート構成を一度に変更してはなりません。また構成されている唯一のハートビートの変更や削除も行ってはなりません。

    少なくとも 1 つの動作中のハートビート (とできれば 1 つの待機ハートビート) は変更しないでおく必要があります。

  • CVM 構成で追加/変更ができるのは、データ LAN と IP アドレスだけです。

    CVM を使うクラスタが稼働している場合には、ハートビート構成は変更できません。

  • インタフェースと、クラスタ構成内の他のすべてのインタフェースが正常に動作していない限り、インタフェースを追加したり、その特性を変更することはできません。

    構成内には、不良 NIC や、機能しないサブネットやローカルにスイッチされるサブネットがあってはなりません。ただし、同じ操作でこれらの構成要素を削除するのであれば、あっても構いません。

  • クラスタ内の他のすべてのノードの、同一サブネット上のすべてのピアネットワークインタフェースでも同じ変更を行わない限り、既存のインタフェースの指定を HEARTBEAT_IP から STATIONARY_IP に変更したり、その逆の変更を行うことはできません。

  • すべてのノードでサブネットが共通でない限り、インタフェースの指定を STATIONARY_IP から HEARTBEAT_IP に変更することはできません。

    HEARTBEAT_IP はすべてのノードで同一サブネット上にあり、IPv4 アドレスである必要があります。

  • 待機インタフェースを削除対象ではない別の一次インタフェースで使う予定でない限り、一次インタフェースは、待機インタフェースも同時に削除しなければ削除できません。

  • サブネットや IP アドレスは、それらを (monitored_subnet、ip_subnet、または ip_address として) 使うパッケージがそのノード上で動作するように構成されている場合には、ノードから削除できません。

    パッケージのネットワーキングパラメータについての詳細は、「monitored_subnet」を参照してください。

  • クラスタで使われているインタフェースの IP 構成は、一回の操作 (cmapplyconf) では変更できません。

    クラスタ構成からまず NIC を削除し、その後 (たとえば、ifconfig (1m) を使って) NIC を再構成してから、NIC をクラスタに戻す必要があります。

    これを行う必要があるのは、次のような場合です。

    • NIC を 1 つのサブネットから別のサブネットに移す

    • NIC に IP アドレスを追加する

    • NIC から IP アドレスを削除する

いくつかの手順の例を以下に示します。

例: ハートビート LAN の追加

2 ノードクラスタ cluster1 のノード ftsys9 と ftsys10 でサブネット15.13.170.0 が共有されている場合に、そのサブネットをハートビートサブネットとしてクラスタ構成に追加する方法について考えます。以下の手順を実行します。

  1. cmquerycl を実行して、クラスタ構成に追加可能なインタフェース用のネットワーキング情報を含んでいるクラスタ構成テンプレートファイルを取得します。

    cmquerycl -c cluster1 -C clconfig.ascii

    注記: Serviceguard A.11.18 からは、cmquerycl -c は、クラスタ構成に現在は含まれていない利用可能なインタフェースについて、コメントアウトされたエントリーを含む出力を生成するようになりました。

    生成される clconfig.ascii のネットワーキング関係の出力は、以下のとおりです。

    NODE_NAME               ftsys9
 NETWORK_INTERFACE     lan1
    HEARTBEAT_IP        192.3.17.18
 #NETWORK_INTERFACE    lan0
    #STATIONARY_IP      15.13.170.18
 NETWORK_INTERFACE     lan3
# Possible standby Network Interfaces for lan1, lan0: lan2.
NODE_NAME               ftsys10
 NETWORK_INTERFACE     lan1
    HEARTBEAT_IP       192.3.17.19
 #NETWORK_INTERFACE    lan0
  # STATIONARY_IP       15.13.170.19
 NETWORK_INTERFACE     lan3
# Possible standby Network Interfaces for lan0, lan1: lan2

  2. ファイルを編集して、追加するサブネット (この例では、lan0) のエントリーのコメントを外し、STATIONARY_IP を HEARTBEAT_IP に変更します。

    NODE_NAME               ftsys9
 NETWORK_INTERFACE    lan1
    HEARTBEAT_IP        192.3.17.18
 NETWORK_INTERFACE    lan0
    HEARTBEAT_IP        15.13.170.18
 NETWORK_INTERFACE    lan3
# Possible standby Network Interfaces for lan1, lan0: lan2.
NODE_NAME               ftsys10
 NETWORK_INTERFACE    lan1
    HEARTBEAT_IP       192.3.17.19
 NETWORK_INTERFACE    lan0
  HEARTBEAT_IP          15.13.170.19
 NETWORK_INTERFACE    lan3
# Possible standby Network Interfaces for lan0, lan1: lan2

  3. 新しい構成を検証します。

    cmcheckconf -C clconfig.ascii

  4. 構成の変更を適用し、新しいバイナリ形式構成ファイルを全クラスタノードに配布します。

    cmapplyconf -C clconfig.ascii

データサブネットを構成しており、それをパッケージ構成に追加したい場合には、以下の手順を実行する必要があります。

  1. パッケージを停止します。

  2. パッケージ構成ファイルに新しいネットワーキング情報を追加します。

  3. 従来のパッケージの場合には、必要に応じて、新しいネットワーキング情報をパッケージ制御スクリプトに追加します。

  4. 新しいパッケージ構成を適用し、必要に応じて、制御スクリプトを配布します。

詳細は、「稼働中のクラスタでのパッケージ再構成」を参照してください。

例: パッケージで使われるサブネットの削除

この例では、サブネット 15.13.170.0 (lan0) を削除するとします。これは、他の一次 LAN で共有されていない、lan0 の待機サブネット lan3 も削除することを意味します。以下の手順を実行します。

  1. このサブネットを使っているパッケージを停止し、対応するネットワーキング情報 (monitored_subnet、ip_subnet、ip_address。「monitored_subnet」を参照) を削除します。

    詳細は、「稼働中のクラスタでのパッケージ再構成」を参照してください。

  2. cmquerycl を実行し、クラスタ構成ファイルを取得します。

    cmquerycl -c cluster1 -C clconfig.ascii

  3. ネットワークインタフェース lan0 と lan3、および他の影響を受けるノード上のネットワークインタフェースをコメントアウトします。編集後のファイルのネットワーキング関係の部分は、以下のとおりです。

    NODE_NAME               ftsys9
 NETWORK_INTERFACE    lan1
    HEARTBEAT_IP        192.3.17.18
 # NETWORK_INTERFACE    lan0
 # STATIONARY_IP        15.13.170.18
 # NETWORK_INTERFACE    lan3
# Possible standby Network Interfaces for lan1, lan0: lan2.
NODE_NAME               ftsys10
 NETWORK_INTERFACE    lan1
    HEARTBEAT_IP       192.3.17.19
 # NETWORK_INTERFACE    lan0
 # STATIONARY_IP          15.13.170.19
 # NETWORK_INTERFACE    lan3
# Possible standby Network Interfaces for lan0, lan1: lan2

  4. 新しい構成を検証します。

    cmcheckconf -C clconfig.ascii

  5. 構成の変更を適用し、新しいバイナリ形式構成ファイルを全クラスタノードに配布します。

    cmapplyconf -C clconfig.ascii

ノードからの LAN または VLAN インタフェースの削除

システムから LAN または VLAN インタフェースを削除する前に、クラスタ構成からインタフェースを削除する必要があります。

HP-UX 11i v3 システムの場合には、ノードをシャットダウンせずにインタフェースを削除できます。影響を受けるノードで、以下の操作を行います。

注記: この操作を行うことができるのは、HP-UX 11i v3 で動作しているシステムだけです。HP-UX 11i v2 システムの場合には、インタフェースを削除する前にシステムをシャットダウンする必要があります。

  1. 物理インタフェース (NIC) がクラスタ構成に含まれているかどうかが不明な場合には、削除するインタフェースのある I/O スロットの ID を引き数として olrad -C を実行します。NIC がクラスタ構成に含まれている場合には、先に進む前に構成からインタフェースを削除するように知らせる警告メッセージが表示されます。olrad についての詳細は、olrad(1M) のマンページを参照してください。

  2. cmgetconf コマンドを使って、既存のクラスタ構成のコピーを一時ファイルに格納します。たとえば、次のコマンドを実行します。

    cmgetconf clconfig.ascii 

  3. clconfig.ascii 編集し、NIC 名とその IP アドレスを指定している行があれば、それを構成から削除します。

  4. cmcheckconf を実行して、新しい構成を検証します。

  5. cmapplyconf を実行して構成の変更を適用し、新しい構成ファイルを全クラスタノードに配布します。

  6. olrad -d を実行して、NIC を削除します。

「LAN カードまたは Fibre Channel カードの交換」も参照してください。

稼働中のクラスタの LVM 構成の変更

この作業を行うには、以下の例に示すように、Serviceguard Manager を使うか、HP-UX コマンドを使います。

注記: クラスタ稼働中に、クラスタロックディスクのボリュームグループや物理ボリューム構成を変更することはできません。

注記: クラスタ構成からボリュームグループを削除する場合に、削除するボリュームグループをアクティブ化/非アクティブ化するパッケージがあれば、そのパッケージも変更します。また、削除したボリュームに対して LVM の vgexport コマンドを実行します。このコマンドは、削除したボリュームグループをすでに使用していない各ノード上で実行します。

LVM クラスタで、以下の手順を実行します。

  1. cmgetconf コマンドを使用して、既存のクラスタ構成のコピーを一時ファイルに格納します。たとえば、次のコマンドを実行します。

    cmgetconf clconfig.ascii 

  2. clconfig.ascii ファイルを編集して、ボリュームグループを追加または削除します。

  3. cmcheckconf コマンドを使用して新しい構成を確認します。

  4. cmapplyconf コマンドを使用して構成に変更を適用し、変更後の新しいバイナリ形式構成ファイルを全クラスタノードに配布します。

注記: クラスタから削除しようとしているボリュームグループが現在パッケージによってアクティブ化されている場合は、構成を変更しても、パッケージを停止しなければ削除は有効になりません。その後さらに、削除したボリュームグループをパッケージ構成ファイルやパッケージ制御スクリプトからも削除するなどの変更を行わなければ、パッケージを実行することはできません。

VxVM または CVM の記憶領域構成の変更

クラスタの動作中に、クラスタ構成に VxVM ディスクグループを追加できます。CVM ディスクグループを新規に追加するためには、クラスタが動作していなければなりません。

注記: CVM (および CFS: Veritas Cluster File System) は、HP-UX のいくつかのリリースでサポートされていますが、現行リリースのすべてでサポートされているわけではありません。最新情報については、お使いのバージョンに対応する Serviceguard の最新のリリースノートを参照してください (http://docs.hp.com/ja -> [ハイ アベイラビリティ] -> [Serviceguard] から入手可能です)。

CVM マスターノードで CVM ディスクグループを作成します。

  • CVM 3.5 と CFS を使わない CVM 4.1 以降の場合は、CVM ストレージを使っているパッケージの構成ファイルを編集し、cvm_dg パラメータ (従来のパッケージでの STORAGE_GROUP) を使って CVM ディスクグループを追加します。その後、cmapplyconf コマンドを実行します。

  • CFS を使っている CVM 4.1 以降の場合は、CFS を使っているパッケージの構成ファイルを編集し、3 つの dependency_ パラメータに値を設定します。その後、cmapplyconf コマンドを実行します。

同様に、その時点で VxVM や CVM ディスクグループがクラスタノードから使用されていなければ、削除することができます。

注意: Serviceguard は Veritas プロセス (具体的には、gab と llt) を管理するため、gabconfig、llthosts、lltconfig などの管理コマンドを使ってクラスタを管理することはできません。Veritas 管理コマンドを、gabconfig -a のように読み取り専用に使うのは問題はありませんが、管理用に使うとノードやクラスタ全体がクラッシュするおそれがあります。
注記: クラスタ構成からディスクグループを削除する場合、このディスクグループをインポートまたはデポートしているパッケージ構成ファイル (または従来のパッケージ制御スクリプト) も、変更するか削除してください。CFS を使わずに CVM で管理されるディスクグループを削除する場合は、パッケージ構成ファイルから、対応するディスクグループのエントリーも削除してください。CFS を使っていて CVM で管理されるディスクグループを削除する場合は、対応する dependency_ パラメータも削除してください。

MAX_CONFIGURED_PACKAGES の変更

Serviceguard A.11.17 から、クラスタの動作中に MAX_CONFIGURED_PACKAGES を変更できるようになりました。MAX_CONFIGURED_PACKAGES のデフォルトは、クラスタ内で許されている最大数です。MAX_CONFIGURED_PACKAGES を変更するには、Serviceguard Manager を使うか、以下に示すように Serviceguard コマンドを使います。

cmgetconf コマンドを使って、次のように、クラスタ内に存在する構成ファイルの現在のコピーを取得します。例を次に示します。

cmgetconf -c <cluster_name> clconfig.ascii 

clconfig.ascii ファイルを編集して、MAX_CONFIGURED_PACKAGES に新しい値を設定します。その後 cmcheckconf コマンドを使って新しい構成を検証します。-k オプションまたは-K オプションを指定すると、応答時間を大幅に短縮することができます。

cmapplyconf コマンドを使って構成の変更を適用し、新しい構成ファイルを全クラスタノードに配布します。-k オプションまたは-K オプションを指定すると、応答時間を大幅に短縮できます。



パッケージとサービスの管理
  		 


従来のパッケージの構成  
印刷用画面へ
プライバシー 本サイト利用時の合意事項
© 1995-2007 Hewlett-Packard Development Company, L.P.