CA Performance Management Data Aggregator Data Aggregator Readme 2.4

1.0 はじめに

Data Aggregator Readme をご覧いただき、誠にありがとうございます。 この Readme には、このリリースの既知の問題のリストと、このリリースの機能および拡張機能がユーザに与える可能性のある影響が記載されています。

2.0 製品ドキュメントへのアクセス方法

この Readme には、最新の既知の問題とその回避策のリストが含まれています。 その他の製品ドキュメントには、Data Aggregator マニュアル選択メニューからアクセスできます。マニュアル選択メニューには、CA Performance Center ユーザ インターフェースの［ヘルプ］メニューからアクセスできます。 また、マニュアル選択メニューは CA サポートからダウンロードすることもできます。 マニュアル選択メニューには、PDF および HTML 形式のリリース ノート（システム要件を含む）、オンライン ヘルプ、およびガイドが含まれています。

［ヘルプ (?)］ボタンをクリックするか、または［ヘルプ］メニューから［このページのヘルプ］を選択すると、ページおよびビューに対応する状況依存のオンライン ヘルプを利用できます。

3.0 アップグレードに関する考慮事項

CA Performance Management ソフトウェアの以前のリリースからのアップグレードは、増分アップグレードとしてサポートされています。 アップグレード パスの詳細については、「Data Aggregator リリース ノート」を参照してください。

3.1 Data Repository のアップグレードが論理ボリューム マネージャ（LVM）の使用により失敗する

以下の手順は、データとカタログのディレクトリを、LVM を使用して Vertica 6.0.2 を実行している Data Repository から、LVM を使用していない Vertica 6.0.2 に移行する方法について説明します。 Vertica データベースは、Data Repository をバックアップしますが、Vertica は、LVM ボリューム上で実行されるそのデータベースをサポートしません。 Vertica は LVM 上でのデータベースの実行をサポートしていません。 ただし、Vertica 7.0.1-2 以降（Data Aggregator リリース 2.3.4 および リリース 2.4 では Vertica 7.0.1-2 が必要です）では、Vertica インストーラによって、Vertica を LVM 上で実行できないという要件が強制的に適用されます。

LVM パーティション上に存在するデータベース ディレクトリを非 LVM パーティションにマイグレートする手順は、Data Repository 単一ノード展開および Data Repository クラスタ展開の両方に対して説明されています。 Data Repository で、LVM が管理するボリュームを使用している場合、Data Aggregator リリース 2.3.4 および リリース 2.4 はインストールできません。

3.1.1 データ リポジトリ - 単一ノード

重要： 続行する前に Data Repository をバックアップしてください。 スケジュールされたバックアップがこの間に実行されないことを確認します。

重要： LVM パーティションを変換する間、データベース コンテンツを一時的に格納するために十分な空き容量を持ったローカル パーティションまたはネットワーク接続されているパーティションが必要です。

前提：

• データ ディレクトリは /data です。
• カタログ ディレクトリは /catalog です。
• LVM はデータおよびカタログのディレクトリを管理します。
• データベース管理者ユーザは dradmin です。
• データベースの名前は drdata になります。

マイグレーションを続行するには、以下の手順に従います。

1. Data Collector の各インスタンスを停止します。
   1. ssh dc_hostname -l root
   2. /etc/init.d/dcmd stop
   3. /etc/init.d/dcmd status
2. Data Aggregator を停止します。
   1. ssh da_hostname -l root
   2. /etc/init.d/dadaemon stop
   3. /etc/init.d/dadaemon status
3. dradmin として、データベースを停止します。
   1. ssh dr_hostname -l dradmin
   2. /opt/vertica/bin/adminTools を使用してデータベースを停止します

重要： 特に指定のない限り、root ユーザとして以下の手順に従ってください。

1. データ ディレクトリのコンテンツを一時的に格納するために、一時ディレクトリ（/tmp_data）を作成します。 このディレクトリは、/data/drdata フォルダの完全なコピーを格納するのに十分な容量があるパーティションに置かれている必要があります。 これは一時的な格納場所です。 データは後でこの場所から移動されます。
   1. mkdir /tmp_data
   2. /tmp_data が一時パーティションにマウントされていることを確認します。

      mount data_partition /tmp_data

   3. 手順 7 の /data ディレクトリのサイズを後で参照できるように書き留めます。

      du -ch /data | grep -i total

   4. 格納先パーティション上のディスク空き容量を確認します。

      df -h /tmp_data

   5. 格納先パーティション（/tmp_data に対するパーティション）に、/data ディレクトリの完全なコピーを格納するのに十分なディスク空き容量があることを確認します。
2. /tmp_data フォルダの権限を変更します。

   chown dradmin:verticadba /tmp_data

   • dradmin

     データベース管理者ユーザです。

3. データベースを新しいディレクトリに移動させます。

   mv /data/drdata /tmp_data

4. 手順 4.c でレポートされたサイズにファイル サイズが一致することを確認します。

   du -ch /tmp_data | grep -i total

5. カタログ ディレクトリを格納するために、一時ディレクトリ（/tmp_catalog）を作成します。 このディレクトリは、/catalog/drdata フォルダの完全なコピーを格納するのに十分な容量があるパーティションに置かれている必要があります。 これは一時的な格納場所です。 データは後でこの場所から移動されます。
   1. mkdir /tmp_catalog
   2. /tmp_catalog が一時パーティションにマウントされていることを確認します。

      mount data_partition /tmp_catalog

   3. 手順 11 の /catalog ディレクトリのサイズを後で参照できるように書き留めます。

      du -ch /catalog | grep -i total

   4. 格納先パーティション上のディスク空き容量を確認します。

      df -h /tmp_catalog

   5. 格納先パーティション（/tmp_catalog に対するパーティション）に、/catalog ディレクトリの完全なコピーを格納するのに十分なディスク空き容量があることを確認します。
6. /tmp_catalog フォルダの権限を変更します。

   chown dradmin:verticadba /tmp_catalog

   • dradmin

     データベース管理者ユーザです。

7. カタログを新しいディレクトリに移動させます。

   mv /catalog/drdata /tmp_catalog

8. 手順 8.c でレポートされたサイズにファイル サイズが一致することを確認します。

   du -ch /tmp_catalog | grep -i total

9. マウントの出力を記録することにより lvm マウント ポイントを書き留めます。

   mount

10. /data および /catalog のマウントを解除します。

    umount /data

    umount /catalog

    注： "ビジー" 関連のエラーが発生した場合は、すべてのウィンドウおよびアプリケーションがこれらのディレクトリにアクセスしていないことを確認してください。

11. /data および /catalog 上に非 LVM ボリュームを再構築します。 以下の 3 つの方法があります。
    • 既存の非 LVM ファイル システム： /data および /catalog のマウントを解除する際、空のフォルダは Linux ファイル システムのルートと同じパーティションに再配置されます。 このパーティションがサイジング要件に適合し、今後のデータを保存する場所にする場合は、/data および /catalog のディレクトリに関連する行を /etc/fstab から削除します。

      vim /etc/fstab

    または

    • 既存の LVM ファイル システムを非 LVM に変換： LVM パーティションを非 LVM パーティションに変換する場合は、手順 12 の情報を使用して、以下の手順を完了します。
      1. lvremove /dev/<lvmvolumegroup>/<lvmlogicalvolume>
      2. vgremove <lvmvolumegroup>
      3. pvremove /dev/<sdaX>
      4. mkfs.ext3 /dev/sdaX
      5. /etc/fstab 内に以下のようなエントリを追加します。

         /dev/sdaX /catalog ext3 defaults 0 0

         /dev/sdaY /data ext3 defaults 0 0

    または

    • 新しい非 LVM ファイル システム： 新しい非 LVM パーティションを使用する場合、ファイル システムをフォーマットし、/data および /catalog 用のマウント ポイントを追加します。

      a. mkfs.ext3 /dev/sdaX

      b. /etc/fstab 内に以下のようなエントリを追加します。

      /dev/sdaX /catalog ext3 defaults 0 0

      /dev/sdaY /data ext3 defaults 0 0

12. すべてのファイルシステムを再度マウントします。

    mount -a

13. 一時ディレクトリのデータを Vertica が認識する /data および /catalog ディレクトリに移動させます。
    1. mv /tmp_data/drdata /data
    2. mv /tmp_catalog/drdata /catalog
14. /data ディレクトリのサイズが、手順 4.c でレポートされたサイズに一致することを確認します。

    du -ch /data | grep -i total

15. /catalog ディレクトリのサイズが、手順 8.c でレポートされたサイズに一致することを確認します。

    du -ch /catalog | grep -i total

16. データベースを再起動します。
    1. su – dradmin
    2. /opt/vertica/bin/adminTools

       注： これには数分かかる場合があります。

17. データベースが実行されていることを確認します。
    1. su - dradmin
    2. /opt/vertica/bin/adminTools
    3. "View Database Cluster State" を選択し、データベースの状態が "UP" であることを確認します。
18. Data Aggregator を再起動します。
    1. ssh da_hostname -l root
    2. /etc/init.d/dadaemon start
    3. /etc/init.d/dadaemon status
19. Data Collector の各インスタンスを開始します。
    1. ssh dc_hostname -l root
    2. /etc/init.d/dcmd start
    3. /etc/init.d/dcmd status

3.1.2 Data Repository - クラスタ

重要： 続行する前に Data Repository をバックアップしてください。 スケジュールされたバックアップがこの間に実行されないことを確認します。

前提：

• データ ディレクトリは /data です。
• カタログ ディレクトリは /catalog です。
• LVM はデータおよびカタログのディレクトリを管理します。
• データベース管理者ユーザは dradmin です。
• データベースの名前は drdata になります。

マイグレーションを続行するには、以下の手順に従います。

1. Data Collector の各インスタンスを停止します。
   1. ssh dc_hostname -l root
   2. /etc/init.d/dcmd stop
   3. /etc/init.d/dcmd status
2. Data Aggregator を停止します。
   1. ssh da_hostname -l root
   2. /etc/init.d/dadaemon stop
   3. /etc/init.d/dadaemon status

クラスタ内のノードをマイグレートする手順

重要： 特に指定のない限り、root ユーザとして以下の手順に従ってください。

クラスタ内の各ノードに対して以下の手順に従います。 1 つのノードに対してすべての手順（手順 1 ～ 15）を一度ずつ実行します。

重要： adminTools を使用して、データベースが実行されていることを確認してください。

1. 現在のノードの IP アドレスを記録しておきます。

   ifconfig

2. dradmin ユーザとして、adminTools にアクセスします。
   1. su - dradmin
   2. /opt/vertica/bin/adminTools
3. ホスト上の Vertica を停止します。
   1. "Advanced Tools Menu" に移動します。 Enter キーを押します。
   2. "Stop Vertica on Host" に移動します。 Enter キーを押します。
   3. セクション「クラスタ内のノードをマイグレートする手順」の手順 1 で記録したホスト IP アドレスを選択します。 Enter キーを押します。
   4. "Main Menu" に移動します。 Enter キーを押します。
   5. "Exit" に移動します。 Enter キーを押します。
4. root ユーザに切り替えます。

   exit

5. 以下のコマンドが "root" を出力することを確認します。

   whoami

6. /data ディレクトリからファイルを削除します。

   rm -rf /data/drdata

7. /catalog ディレクトリからファイルを削除します。

   rm -rf /catalog/drdata

8. 以下のコマンドの出力をデバッグ目的で記録します。
   1. mount
   2. cat /etc/fstab
9. /data LVM ディレクトリをマウント解除します。

   umount /data

10. /catalog LVM ディレクトリをマウント解除します。

    umount /catalog

11. /data および /catalog 上に非 LVM ボリュームを再構築します。 以下の 3 つの方法があります。
    • 既存の非 LVM ファイル システム： /data および /catalog のマウントを解除する際、空のフォルダは Linux ファイル システムのルートと同じパーティションに再配置されます。 このパーティションがサイジング要件に適合し、今後のデータを保存する場所にする場合は、/data および /catalog のディレクトリに関連する行を /etc/fstab から削除します。

      vim /etc/fstab

      または

    • 既存の LVM ファイル システムを非 LVM に変換： LVM パーティションを非 LVM パーティションに変換する場合は、手順 8 の情報を使用して、以下の手順を完了します。
      1. lvremove /dev/<lvmvolumegroup>/<lvmlogicalvolume>
      2. vgremove <lvmvolumegroup>
      3. pvremove /dev/<sdaX>
      4. mkfs.ext3 /dev/sdaX
      5. /etc/fstab 内に以下のようなエントリを追加します。

         /dev/sdaX /catalog ext3 defaults 0 0

         /dev/sdaY /data ext3 defaults 0 0

    または

    • 新しい非 LVM ファイル システム： 新しい非 LVM パーティションを使用する場合、ファイル システムをフォーマットし、/data および /catalog 用のマウント ポイントを追加します。

      a. mkfs.ext3 /dev/sdaX

      b. /etc/fstab 内に以下のようなエントリを追加します。

      /dev/sdaX /catalog ext3 defaults 0 0

      /dev/sdaY /data ext3 defaults 0 0

12. すべてのファイル システムをマウント解除

    mount -a

13. 正しい権限を使用して /data および /catalog 内に drdata フォルダを作成します。
    1. mkdir -p /data/drdata
    2. mkdir -p /catalog/drdata
    3. chown -R dradmin:verticadba /data
    4. chown -R dradmin:verticadba /catalog
14. ホスト上の Vertica を再起動します。
    1. su - dradmin
    2. /opt/vertica/bin/adminTools
    3. 下向き矢印キーを使用して "Restart Vertica on host" に移動します。 Enter キーを押します。
15. adminTools の監視を続行します。 データが再構築される間、現在のノードのステータスは「Recovering」のままになります。 データベースが「UP」に戻るまで続行しないでください。 データベースが「UP」状態に移行するまでにかなりの時間がかかる可能性があります。
    1. "View Database Cluster State" を選択します。 Enter キーを押します。
    2. Enter キーを押して、メイン メニューに戻ります。

    データベースがバックアップされた後、次のノードに対して、手順 1-15 （「クラスタ内のノードをマイグレートする手順」）を繰り返します。 Data Repository ノードがすべて LVM からマイグレートされるまで、これらの手順を続行します。

すべての Data Repository ノードに対してセクション「クラスタ内のノードをマイグレートする手順」の手順を完了したら、以下を実行します。

1. Data Repository ノードにログインします。

   su - dradmin

   /opt/vertica/bin/vsql -U dradmin –w drpass

2. カスタム アプリケーション設定を再構築するために以下の vsql コマンドを実行します。
   1. SELECT set_config_parameter('MaxClientSessions',1024);
   2. SELECT set_config_parameter('StandardConformingStrings','0');
3. Data Aggregator を開始します。
   1. ssh da_hostname -l root
   2. /etc/init.d/dadaemon start
   3. /etc/init.d/dadaemon status
4. Data Collector インスタンスをすべて開始します。
   1. ssh dc_hostname -l root
   2. /etc/init.d/dcmd start
   3. /etc/init.d/dcmd status

3.2 CA Mediation Manager アップグレード後の既知の制限

CA Mediation Manager との統合アーキテクチャは著しく拡張されました。 CA Performance Management 2.3.4 以上で実行する場合は、CA Mediation Manager のバージョン 2.2.6 以上が必要です。 ただし、統合のそのバージョンは、Device Pack Generator ユーティリティをサポートしていません。

CA Mediation Manager の今後のバージョンは、このユーティリティの拡張版をサポートする予定です。 それまでは、このユーティリティを使ってカスタム デバイス パックを構築することはできません。

重要： CA Mediation Manager 2.2.6 は、CA Performance Management の以前のバージョンと完全に上位互換ではありません。 Raw データを処理するには、Data Collector を リリース 2.4 にアップグレードする必要があります。 CA Performance Management をアップグレードする前に、必ずデバイス パックをマイグレートしてください。 詳細については、CA Performance Management Data Aggregator マニュアル選択メニューの「デバイス パックをマイグレートする方法」というタイトルを参照してください。

3.3 データベース テーブルのセグメント化

CA Performance Management Data Aggregator をアップグレードしている場合、および Data Repository がクラスタ環境にインストールされている場合は、Data Repository コンポーネントをアップグレードした後、および Data Aggregator コンポーネントをアップグレードする前に、データベース テーブルがセグメント化されていることを確認します。

注： データベース テーブルがセグメント化されているかどうかを確認する詳細については、「CA Performance Management Data Aggregator アップグレード ガイド」を参照してください。

3.4 Data Repository 上の Write Optimized Storage のサイズの変更

100 万以上のポーリングされたアイテムを管理している場合は、Data Repository 上で WOS （Write Optimized Storage）のサイズを、デフォルトの 2 GB から 4 GB に増やしてください。 この変更を行うには、Data Aggregator のシャット ダウンが必要となるので、Data Aggregator をアップグレードする前に以下の手順を実行することをお勧めします。

1. Data Aggregator がインストールされているコンピュータにログインします。 Data Aggregator を停止するため、コマンド プロンプトを開いて、以下のコマンドを入力します。

   service dadaemon stop

2. Data Repository ノードに SSH で接続します。
3. WOS （Write Optimized Storage）にあるすべてのデータを ROS （Read Optimized Storage）に移動するため、以下のコマンドを入力します。

   /opt/vertica/bin/vsql -U database_admin_user -w database_admin_user_password -c "select do_tm_task('moveout')";

4. データが WOS に残っていないことを確認するには、以下のコマンドを入力します。

   /opt/vertica/bin/vsql -U database_admin_user -w database_admin_user_password -c "select sum( region_in_use_size_kb ) as wos_usage_kb from wos_container_storage";

   このコマンドで 0 の値が返らない場合、5 分待機してから、再度コマンドを発行します。 5 分が経過しても返される値がまだ 0 を超えている場合は、手順 3 のコマンドを再入力し、この手順のコマンドを再度発行します。

5. WOS のサイズを 4 GB に増やすには、以下のコマンドを入力します。

   /opt/vertica/bin/vsql -U database_admin_user -w database_admin_user_password -c "alter resource pool wosdata maxMemorySize '4G'";

3.5 CA Spectrum のサポートおよびアップグレードに関する考慮事項

CA Spectrum データ ソースを CA Performance Management リリース 2.4 に 登録する場合は、CA Spectrum リリース 9.4 にアップグレードすることをお勧めします。 CA Spectrum の以前のバージョンでは、以下の新機能を完全にはサポートしません。

• CA Spectrum での CA Performance Center IP ドメインの同期
• グローバル コレクションおよびランドスケープ同期
• CA Spectrum OneClick 内のデバイスおよびインターフェース モデルから CA Performance Center パフォーマンス データへのドリルダウン機能
• IP ドメイン対応の同期ディスカバリ

注： CA Spectrum リリース 9.4 へのアップグレードの詳細については、CA Spectrum リリース 9.4 のドキュメントを参照してください。

4.0 データ エクスポートの前提条件

Data Aggregator の CPU、メモリ、ネットワーク I/O の要件は、データ エクスポート機能を有効にしても同じです。 ただし、ディスク ストレージでデータ エクスポートに使用する別のパーティションには追加の要件があります。 中規模の展開では、このパーティションのサイズは 50 GB である必要があります。 サイズが 50 GB の場合、バッチ ジョブがファイルを別のファイル システムに移動する前に、データを 1 時間保持することができます。

5.0 CAMM DC のアップグレード実行時間の短縮

Data Collector に CAMM がインストールされている場合は、InstallAnywhere 内の制限のため、アップグレードに 1 時間以上かかることがあります。 この問題の回避策については、ナレッジ ベースの記事 https://communities.ca.com/thread/241693769 を参照してください。

6.0 既知の問題

6.1 Data Repository インストールまたはアップグレードで論理ボリューム マネージャ（LVM）が間違って検出され失敗する

Data Repository が使用するボリュームを管理するために論理ボリューム マネージャ（LVM）が使用されている場合、Data Repository はインストールできません。

Vertica データベースは、Data Repository をバックアップしますが、Vertica は、LVM ボリューム上で実行されるそのデータベースをサポートしません。 Vertica は LVM 上でのデータベースの実行をサポートしていません。 ただし、Vertica 7 以降（Data Aggregator リリース 2.3.4 では Vertica 7 が必要です）は、Vertica インストーラによって、Vertica が LVM 上で実行されないようにするという要件を強制的に適用します。

Vertica 7.0.1-2 インストーラに既知の問題があります。 LVM がクラスタ内の任意のボリュームで検出された場合（Vertica が使用するボリューム以外でも）、インストーラは WARN メッセージを生成します。 具体的には以下の WARN メッセージが生成されます。

WARN (S0170): https://my.vertica.com/docs/7.0.x/HTML/index.htm#cshid=S0170

lvscan (LVM utility) indicates some active volumes.

dr_install.sh の実行中に WARN メッセージが発生し、Vertica が使用するカタログおよびデータのディレクトリが LVM によって管理されていないことを確認した場合は、Vertica のインストールまたはアップグレードが正常に行われるようにするための手順をさらに実行します。

注： Vertica が使用するカタログおよびデータのディレクトリが LVM によって管理されている場合は、「アップグレードに関する考慮事項」セクションを参照してください。

重要： install.sh スクリプトが、LVM に関連していない追加の WARN または ERROR メッセージを生成していないことを確認したら、以下の手順に従います。

以下の手順を実行します。

1. dr_install.sh スクリプト内で “/opt/vertica/sbin/install_vertica” で始まる行を探します。 行は以下のように表示されています。

   /opt/vertica/sbin/install_vertica -s $DB_HOST_NAMES -u $DB_ADMIN_LINUX_USER -l $DB_ADMIN_LINUX_USER_HOME -d $DB_DATA_DIR -L ./resources/$VLICENSE -Y -r ./resources/$VERTICA_RPM_FILE $POINT_TO_POINT_SPREAD_OPTION 2>&1 | tee -a $LOG_FILE

2. "-d$DB_DATA_DIR" エントリの後に、以下の新しいエントリを追加し、両側にスペースを挿入します。

   --failure-threshold FAIL

   行は以下のように表示されます。

   /opt/vertica/sbin/install_vertica -s $DB_HOST_NAMES -u $DB_ADMIN_LINUX_USER -l $DB_ADMIN_LINUX_USER_HOME -d $DB_DATA_DIR --failure-threshold FAIL -L ./resources/$VLICENSE -Y -r ./resources/$VERTICA_RPM_FILE $POINT_TO_POINT_SPREAD_OPTION 2>&1 | tee -a $LOG_FILE

   このエントリの追加により、インストール中に 1 つ以上の FAIL メッセージが発生した場合にのみインストールが失敗するようにできます。 LVM WARN メッセージが発生しても無視され、インストールは正常に完了します。

3. Vertica をインストールまたはアップグレードするには、dr_install.sh スクリプトを再実行します。 LVM に固有の WARN メッセージは省略されます。

   dr_install.sh を再実行した場合、以下の LVM WARN メッセージが表示されます。

   WARN (S0170): https://my.vertica.com/docs/7.0.x/HTML/index.htm#cshid=S0170

   lvscan (LVM utility) indicates some active volumes.

   ただし、この WARN メッセージは、Vertica 7 のインストールまたはアップグレードをブロックしません。

6.2 Data Repository ユーザ名と Data Repository 管理者ユーザ名を同じにできない

Data Aggregator コンポーネントをインストールし、Data Repository 認証情報を求められた場合、Data Repository ユーザ名と Data Repository 管理者ユーザ名に対して同じユーザ名を使用しないでください。 Data Aggregator では、新規インストール時にこれらのユーザ名が異なっていることが必要になります。

6.3 複数のオクテットおよび OOB インターフェース メトリック ファミリ

インターフェース/ポートのコンポーネントにカスタム認証を作成する際、MIB テーブルのインデックスに複数のオクテット（たとえば： 23.4.5.12）がある場合は、標準のインターフェース メトリック ファミリを認証に使用することはできません。 この状況でインターフェース メトリック ファミリを使用すると CA Performance Center で同期の問題が発生します。

回避策：

代替インターフェース メトリック ファミリを使用するか、または独自のカスタム メトリック ファミリを作成します。 このアクションによってデバイス コンポーネントの下にインターフェース/ポート アイテムが表示されます。ただし、理想的な結果が得られない場合があります。

7.0 CA Technologies へのお問い合わせ

テクニカル サポートの詳細については、弊社テクニカル サポートの Web サイト（http://www.ca.com/jp/support/）をご覧ください。

Copyright © 2014 CA Technologies. All rights reserved. 本書に記載された全ての製品名、サービス名、商号およびロゴはそれぞれ各社の商標またはサービスマークです。