Hitachi

JP1 Version 12 JP1/Network Node Manager i セットアップガイド

24.4.1　アプリケーションフェイルオーバー構成のNNMi 12-10からのアップグレード

NNMiアプリケーションフェイルオーバー設定で実行している12-10のNNMiをアップグレードする場合，次の手順に従ってください。

〈この項の構成〉

(1)　アプリケーションフェイルオーバー構成のNNMi 12-50へのアップグレード

アプリケーションフェイルオーバーを設定しているNNMi 管理サーバーをアップグレードするには，次の手順を実行します。

  1. 万一に備えて，以降の操作を行う前に，アクティブおよびスタンバイNNMi管理サーバーの両方で，nnmconfigexport.ovplスクリプトを実行する。

    詳細については，「4.2　ベストプラクティス：既存の設定を保存する」を参照してください。

  2. 万一に備えて，以降の操作を行う前に，アクティブおよびスタンバイNNMi管理サーバーのNNMiデータをバックアップする。

    詳細については，「20.2.2　バックアップ領域」を参照してください。

  3. アクティブNNMi管理サーバーで次の手順を実行する。

    nnmclusterの手順が機能するには，NNMiを実行している必要があります。この手順を完了すると，手順7.で示すスタンバイNNMi管理サーバーの起動が速くなります。

    a　nnmclusterコマンドを実行します。

    b　NNMiに入力を求められたら，「dbsync」と入力し，［Enter］キーを押します。表示される情報に次のメッセージが含まれていることを確認します。

    • ACTIVE_DB_BACKUP：アクティブNNMi管理サーバーが新しいバックアップを実行しています。

    • ACTIVE_NNM_RUNNING：アクティブNNMi管理サーバーが，前のメッセージによって示されたバックアップを完了しました。

    • STANDBY_RECV_DBZIP：スタンバイNNMi管理サーバーは，アクティブNNMi管理サーバーから新しいバックアップを取得しています。

    • STANDBY_READY：スタンバイNNMi管理サーバーは，アクティブNNMi管理サーバーで障害が発生した場合に実行できる準備が整えられています。

    c　exitまたはquitを実行して，手順aで開始したインタラクティブnnmclusterプロセスを停止します。

  4. スタンバイNNMi管理サーバーでnnmcluster -shutdownコマンドを実行する。

    スタンバイNNMi管理サーバーのすべてのnnmclusterプロセスをシャットダウンします。

  5. スタンバイNNMi管理サーバーでnnmclusterノードが動作していないことを確認するには，スタンバイNNMi管理サーバーで次の手順を実行する。

    a　nnmclusterコマンドを実行します。

    b　(SELF)とマークされているもの以外にnnmclusterノード(ローカル)が存在しないことを確認します。1つ以上のリモートノードが存在する場合があります。

    c　exitまたはquitを実行して，手順aで開始したインタラクティブnnmclusterプロセスを停止します。

  6. 次の手順をスタンバイNNMi管理サーバーで実行し，アプリケーションフェイルオーバーを一時的に無効にする。

    a　次のファイルを編集します。

    • Windows：%NNM_SHARED_CONF%\props\nms-cluster.properties

    • Linux：$NNM_SHARED_CONF/props/nms-cluster.properties

    b　com.hp.ov.nms.cluster.nameパラメーターをコメントにします。

    c　変更を保存します。

    d　次のファイルを編集します。

    • Windows：%NNM_DB%\Postgres\postgresql.conf

    • Linux：$NNM_DB/Postgres/postgresql.conf

    e　次に示すアプリケーションフェイルオーバーの設定内容を削除します。

    　・“# The following lines were added by the NNM cluster.”で始まる行

    　・”archive_command = ”で始まる行

    　・”archive_timeout = ”で始まる行

    　・”max_wal_senders = ”で始まる行

    　・”archive_mode = ”で始まる行

    　・”wal_level = ”で始まる行

    　・”hot_standby =”で始まる行

    　・”wal_keep_segments = ”で始まる行

    　・”listen_addresses = ”で始まる行

    f　変更を保存します。

    g　次の空ファイルを作成します。

    • Windows：%NNM_TMP%\postgresTriggerFile

    • Linux：$NNM_TMP/postgresTriggerFile

  7. スタンバイNNMi管理サーバーでプロセスを開始してから停止する。

    a　スタンバイNNMi管理サーバーでovstartコマンドを実行します。ovstartコマンドを実行すると，スタンバイNNMi管理サーバーはトランザクションログをアクティブNNMi管理サーバーからインポートします。

    b　ovstartコマンドの完了後，ovstatus -vコマンドを実行します。すべてのNNMiサービスで，［実行中］状態が表示されます。

    c　スタンバイNNMi管理サーバーでovstopコマンドを実行します。

  8. 「2.　NNMiのインストールとアンインストール」およびリリースノートの指示に従い，スタンバイNNMi管理サーバーをNNMi 12-50にアップグレードする。

    証明書のリポジトリをPKCS #12リポジトリに移行していない場合は，アップグレード完了後に，以前のスタンバイ NNMi 管理サーバーにて「10.2　アップグレードされたNNMi環境で新しいキーストアーを使用するための設定」の手順に従い，PKCS #12リポジトリに移行してください。

    以前のアクティブNNMi管理サーバーがNNMi 12-10以前を実行し，以前のスタンバイNNMi管理サーバーがNNMi 12-50を実行しています。両方のNNMi管理サーバーが個別に動作し，データベースは同期していません。つまり両方のNNMi管理サーバーがネットワークを並行して監視しています。

    アップグレードを完了してこの状況を解決するには，以前のアクティブなクラスタノードをNNMi 12-50にアップグレードします。このアップグレードを完了する間，以前のスタンバイノードをオペレータに一時的に使用させてネットワークを監視させます。

    この手順の残りの部分では，以前のアクティブなクラスタノードのデータベース情報を維持して，以前のスタンバイノードのデータベース情報を破棄することを想定しています。

  9. 以前のアクティブNNMi管理サーバーでnnmcluster -haltコマンドを実行する。

  10. 以前のアクティブNNMi管理サーバーでnnmclusterノードが動作していないことを確認するには，以前のアクティブNNMi管理サーバーで次の手順を実行する。

    a　nnmclusterコマンドを実行します。

    b　(SELF)とマークされているもの以外にnnmclusterノード(ローカル)が存在しないことを確認します。1つ以上のリモートノードが存在する場合があります。

    c　exitまたはquitを実行して，手順aで開始したインタラクティブnnmclusterプロセスを停止します。

  11. 次の手順を以前のアクティブNNMi管理サーバーで実行し，アプリケーションフェイルオーバーを一時的に無効にする。

    a　次のファイルを編集します。

    • Windows：%NNM_SHARED_CONF%\props\nms-cluster.properties

    • Linux：$NNM_SHARED_CONF/props/nms-cluster.properties

    b　com.hp.ov.nms.cluster.nameパラメーターをコメントにします。

    c　変更を保存します。

  12. 「2.　NNMiのインストールとアンインストール」の指示に従い，以前のアクティブNNMi管理サーバーをNNMi 12-50にアップグレードする。

    証明書のリポジトリをPKCS #12リポジトリに移行していない場合は，アップグレード完了後に，以前のアクティブ NNMi 管理サーバーにて「10.2　アップグレードされたNNMi環境で新しいキーストアーを使用するための設定」の手順に従い，PKCS #12リポジトリに移行してください。

    2つのサーバーでNNMi 12-50を実行していますが，データベースが同期していないため，まだ個別に動作しています。

  13. 以前のアクティブNNMi管理サーバーで次の手順を実行する。

    a　ovstopコマンドを実行します。

    b　次のファイルを編集します。

    • Windows：%NNM_SHARED_CONF%\props\nms-cluster.properties

    • Linux：$NNM_SHARED_CONF/props/nms-cluster.properties

    c　11-50からアップグレードした場合，com.hp.ov.nms.cluster.nameパラメーターの値を入力します。

    　11-50からアップグレードした場合コメントにしたプロパティは保持されません。したがって，クラスタ名は再入力する必要があります。

    d　com.hp.ov.nms.cluster.nameパラメーターのコメントを解除します。

    e　変更を保存します。

  14. ovstartコマンドまたはnnmcluster -daemonコマンドを以前のアクティブNNMi管理サーバーで実行する。これがアクティブなクラスタノードとなる。

  15. アクティブなクラスタノードを使用してネットワークを監視するように，オペレータに指示する。

    以前のスタンバイNNMi管理サーバーは，手順9.から手順13.のメンテナンス中に発生したすべてのデータベースアクティビティを破棄します。

  16. 以前のスタンバイNNMi管理サーバーで次の手順を実行する。

    a　ovstopコマンドを実行します。

    b　次のファイルを編集します。

    • Windows：%NNM_SHARED_CONF%\props\nms-cluster.properties

    • Linux：$NNM_SHARED_CONF/props/nms-cluster.properties

    c　11-50からアップグレードした場合，com.hp.ov.nms.cluster.nameパラメーターの値を入力します。

    d　com.hp.ov.nms.cluster.nameパラメーターのコメントを解除します。

    e　変更を保存します。

  17. ovstartコマンドまたはnnmcluster -daemonコマンドを以前のスタンバイNNMi管理サーバーで実行する。

    このNNMi管理サーバーはスタンバイノードになり，アクティブなクラスタノードからデータベースのコピーを受信します。

ページの先頭へ

(2)　アプリケーションフェイルオーバー構成のNNMi12-50への修正パッチ適用手順

両方のNNMi管理サーバーで同じバージョンとパッチレベルのNNMiを実行している必要があります。アクティブおよびスタンバイのNNMi管理サーバーにパッチを追加するには，次のどちらかの方法を使用します。

(a)　アプリケーションフェイルオーバー用にパッチを適用する（アクティブとスタンバイの両方をシャットダウン）

この手順を実行すると，パッチプロセス中の一定期間，両方のNNMi管理サーバーが非アクティブになります。アプリケーションフェイルオーバーを設定しているNNMi管理サーバーにパッチを適用するには，次の手順を実行します。

  1. 万一に備えて，以降の操作を行う前に，アクティブおよびスタンバイNNMi管理サーバーの両方で，nnmconfigexport.ovplスクリプトを実行する。

    詳細については，「4.2　ベストプラクティス：既存の設定を保存する」を参照してください。

  2. 万一に備えて，以降の操作を行う前に，アクティブおよびスタンバイNNMi管理サーバーのNNMiデータをバックアップする。

    詳細については，「20.2.2　バックアップ領域」を参照してください。

  3. 万一に備えて，アクティブNNMi管理サーバーで，次の手順を実行する。

    a　nnmclusterコマンドを実行します。

    b　NNMiに入力を求められたら，「dbsync」と入力し，［Enter］キーを押します。表示される情報に次のメッセージが含まれていることを確認します。

    • ACTIVE_DB_BACKUP：アクティブNNMi管理サーバーが新しいバックアップを実行しています。

    • ACTIVE_NNM_RUNNING：アクティブNNMi管理サーバーが，前のメッセージによって示されたバックアップを完了しました。

    • STANDBY_READY：スタンバイNNMi管理サーバーの前のステータスを示します。

    • STANDBY_RECV_DBZIP：スタンバイNNMi管理サーバーは，アクティブNNMi管理サーバーから新しいバックアップを取得しています。

    • STANDBY_READY：スタンバイNNMi管理サーバーは，アクティブNNMi管理サーバーで障害が発生した場合に実行できる準備が整えられています。

    c　exitまたはquitを実行して，手順aで開始したインタラクティブnnmclusterプロセスを停止します。

  4. アクティブNNMi管理サーバーでnnmcluster -haltコマンドを実行する。

    アクティブおよびスタンバイNNMi管理サーバーのすべてのnnmclusterプロセスをシャットダウンします。

  5. 両方のサーバーでnnmclusterノードが実行していないことを確認するには，アクティブおよびスタンバイNNMi管理サーバーの両方で次の手順を実行する。

    a　nnmclusterコマンドを実行します。

    b　(SELF)とマークされているもの以外にnnmclusterノードが存在しないことを確認します。

    c　exitまたはquitを実行して，手順aで開始したインタラクティブnnmclusterプロセスを停止します。

  6. アクティブNNMi管理サーバーで，nms-cluster.propertiesファイルのcom.hp.ov.nms.cluster.nameパラメーターをコメントにする。

    a　次のファイルを編集します。

    • Windows：%NNM_SHARED_CONF%\props\nms-cluster.properties

    • Linux：$NNM_SHARED_CONF/props/nms-cluster.properties

    b　com.hp.ov.nms.cluster.nameパラメーターをコメントにします。

    c　変更を保存します。

  7. パッチに同梱されているRELEASE.TXTの指示に従い，アクティブNNMi管理サーバーにNNMiパッチを適用する。

  8. アクティブNNMi管理サーバーで，nms-cluster.propertiesファイルのcom.hp.ov.nms.cluster.nameパラメーターのコメントを解除する。

    a　次のファイルを編集します。

    • Windows：%NNM_SHARED_CONF%\props\nms-cluster.properties

    • Linux：$NNM_SHARED_CONF/props/nms-cluster.properties

    b　com.hp.ov.nms.cluster.nameパラメーターのコメントを解除します。

    c　変更を保存します。

  9. アクティブNNMi管理サーバーでovstartコマンドを実行する。

  10. NNMiコンソールの［ヘルプ］＞［システム情報］ウィンドウにある［製品］タブで情報を表示し，アクティブNNMi管理サーバーにパッチが正しくインストールされたことを確認する。

  11. nnmcluster -dbsyncコマンドを実行して，新しいバックアップを作成する。

  12. 手順6.のa〜cに示されているように，スタンバイNNMi管理サーバーで，nms-cluster.propertiesファイルのcom.hp.ov.nms.cluster.nameパラメーターをコメントにする。

  13. NNMiパッチをスタンバイNNMi管理サーバーに適用する。

  14. 手順8.のa〜cに示されているように，スタンバイNNMi管理サーバーで，nms-cluster.propertiesファイルのcom.hp.ov.nms.cluster.nameパラメーターのコメントを解除する。

  15. スタンバイNNMi管理サーバーでovstartコマンドを実行する。

(b)　アプリケーションフェイルオーバー用にパッチを適用する（1つのアクティブNNMi管理サーバーを保持）

この手順を実行すると，パッチプロセスの間，1つのNNMi管理サーバーが常にアクティブになります。

このプロセスでは，ネットワークが継続的に監視されますが，NNMiでパッチプロセス中に生じたトランザクションログは失われます。

アプリケーションフェイルオーバーを設定しているNNMi管理サーバーにNNMiパッチを適用するには，次の手順を実行します。

  1. 万一に備えて，以降の操作を行う前に，アクティブおよびスタンバイNNMi管理サーバーの両方で，nnmconfigexport.ovplスクリプトを実行する。

    詳細については，「4.2　ベストプラクティス：既存の設定を保存する」を参照してください。

  2. 万一に備えて，以降の操作を行う前に，アクティブおよびスタンバイNNMi管理サーバーのNNMiデータをバックアップする。

    詳細については，「20.2.2　バックアップ領域」を参照してください。

  3. ノードのどれかでnnmclusterコマンドを実行する。

  4. 前の手順で2つのデータベースの同期に使用したNNMi管理サーバーでdbsyncを入力する。

    dbsyncオプションは，組み込みデータベースを使用するNNMi管理サーバーで機能します。

  5. アクティブNNMi管理サーバーがACTIVE_NNM_RUNNINGに戻り，スタンバイNNMi管理サーバーがSTANDBY_READYに戻るまで待機してから，次に進む。

  6. nnmclusterを終了または中断させる。

  7. 次のコマンドをスタンバイNNMi管理サーバーで実行して，スタンバイNNMi管理サーバーのクラスタを停止する。

    nnmcluster -shutdown

  8. 次のプロセスとサービスが終了しているのを確認してから，次に進む。

    postgres
ovjboss

  9. nnmclusterプロセスが終了しているのを確認してから，次に進む。

    nnmclusterプロセスが終了していない場合，ほかに方法がなければ，nnmclusterプロセスを手動で強制終了します。

  10. スタンバイNNMi管理サーバーで，次のファイルを編集する。

    • Windows：%nnmDataDir%shared\nnm\conf\props\nms-cluster.properties

    • Linux：$nnmDataDir/shared/nnm/conf/props/nms-cluster.properties

  11. 行の先頭に#を入れてクラスタ名をコメントにして変更を保存する。

    #com.hp.ov.nms.cluster.name = NNMicluster

  12. スタンバイNNMi管理サーバーにNNMiパッチをインストールする。

  13. この時点で，スタンバイNNMi管理サーバーはパッチが適用済みで停止中，アクティブNNMi管理サーバーはパッチが未適用で実行中である。

    アクティブNNMi管理サーバーを停止し，ただちにスタンバイNNMi管理サーバーを起動してネットワークを監視させます。

  14. アクティブNNMi管理サーバーで次のコマンドを実行して，アクティブNNMi管理サーバーのクラスタをシャットダウンする。

    nnmcluster -halt

  15. nnmclusterプロセスの終了を確認する。

    数分以内に終了しない場合は，nnmclusterプロセスを手動で終了してください。

  16. スタンバイNNMi管理サーバーで，nms-cluster.propertiesファイルからクラスタ名のコメントを解除する。

  17. 次のコマンドをスタンバイNNMi管理サーバーで実行して，スタンバイNNMi管理サーバーのクラスタを起動する。

    nnmcluster -daemon

  18. アクティブNNMi管理サーバーにNNMiパッチをインストールする。

  19. この時点で，以前のアクティブNNMi管理サーバーはパッチが適用済みですが，オフラインである。

    次の手順を実行して，（スタンバイNNMi管理サーバーとして）クラスタに復帰させます。

    a　アクティブNNMi管理サーバーで，nms-cluster.propertiesファイルのエントリのコメントを解除します。

    b　次のコマンドを使用して，アクティブNNMi管理サーバーを起動します。

    nnmcluster -daemon

  20. 進行状況を監視するには，アクティブとスタンバイの両方のNNMi管理サーバーで次のコマンドを実行する。

    nnmcluster

    以前のアクティブNNMi管理サーバーが，以前のスタンバイNNMi管理サーバーからデータベースの取得を完了するまで待機します。

  21. 以前のアクティブNNMi管理サーバーにSTANDBY_READYが表示されたら，以前のアクティブNNMi管理サーバーで次のコマンドを実行する。

    nnmcluster -acquire

ページの先頭へ

© Copyright 2009-2021 Micro Focus or one of its affiliates.

All Rights Reserved. Copyright (C) 2019, 2021, Hitachi, Ltd.

This software and documentation are based in part on software and documentation under license from Micro Focus or one of its affiliates.