Data Repository の移行

Data Repository を移行するには、Vertica を新しいクラスタにインストールし、データを移行します。 以下の状況では、移行が必要な場合があります。
capm370
Data Repository を移行するには、Vertica を新しいクラスタにインストールし、データを移行します。 以下の状況では、移行が必要な場合があります。
  • メジャー OS アップグレード(たとえば、RHEL 6.9 から RHEL 7.3)の新しいホストに移行する。
  • 現在のデータベースのハードウェアがサイジング要件を満たしていない。
  • 仮想マシンからデータベースの物理的なハードウェアに移動している。
既存のシステムを移行後の製品バージョンにアップグレードしてから、移行を行う必要があります。
別のクラスタへのデータベースのコピーの詳細については、Vertica のドキュメントを参照してください。
2
データ量によっては、Data Repository の移行にかなりの時間がかかることがあります。
ダウンタイムを最小限に抑えるには、最初のバックアップ後に増分バックアップを実行します。
移行先 Data Repository のインストールの準備
新しいクラスタに Vertica をインストールする前に、インストール用の環境を準備します。 宛先クラスタの準備の詳細については、「Data Repository のインストールの準備」を参照してください。
ターゲット クラスタには以下の要素が必要です。
  • ソース クラスタと同じ数のノード
  • ソースデータベースと同じ名前のデータベース
    ターゲット データベースを空にすることができます。
  • ソースクラスタと同じノード名
    両方のクラスタの NODES システム テーブルにリストされているノード名が一致する必要があります。 新しいシステムへのインストール後に既存のノード名に一致するようにノード名を変更するには、サポートにご連絡ください。
  • ソース クラスタからアクセスできる
  • 同じデータベース管理者アカウントとすべてのノードで、ソース クラスタのデータベース管理者がパスワードを入力せずに SSH でログインできる必要があります。
    1 つのクラスタ内でパスワードを使用しないアクセスは、複数のクラスタ間でパスワードを使用しないアクセスと同じではありません。 ソース クラスタとターゲット クラスタでは管理者アカウントの SSH ID が同じでない可能性があります。 ソース クラスタの SSH 認証を受け入れるように、ターゲット クラスタの各ホストを設定する必要があります。
  • vbr --task copycluster
    コマンドが完了するための十分なディスク領域。
新しいクラスタに Vertica をインストールする
インストール プロセスは通常の Data Repository インストールと同じです。詳細については、「Data Repository のインストール」を参照してください。
移行元クラスタと同じ設定を、新しいクラスタに使用します。 たとえば、vertica のバージョン、ノード数、データベース名、管理者、ユーザ、カタログ ディレクトリ、およびデータ ディレクトリは元の Data Repository と同じである必要があります。
クラスタの移行
新しいクラスタにデータベースをインストールした後、既存のデータを移行します。 移行では、コピー クラスタ コマンドを使用して、既存のデータベースをバックアップするのと同時に、新しいクラスタにデータをリストアします。 コピー クラスタは新しいシステムを指し示すソース システムで設定、起動、および実行されます。 ソース システムの 1 つのノードでコピー クラスタを実行すると、新しいシステムのすべてのノードにデータがコピーされます。 コピー クラスタは、コマンドを実行する前から、Data Repository 内のすべてのデータをコピーします。 移行中、
DX NetOps Performance Management
はデータを集め続けるため、処理が複数回コピー クラスタ コマンドを実行する必要があります。
3
コピー クラスタ用設定ファイルの作成
ターゲット クラスタを設定する前に、ソース データベース内のすべてのノードに対して
admintools
によって指定された正確な名前を知っておく必要があります。
ノード名を表示するには、以下の例のようなクエリを実行します。
VMart=> select node_name from nodes;
node_name
------------------
v_vmart_node0001
v_vmart_node0002
v_vmart_node0003
(3 rows)
コピー クラスタ コマンドには、必要な情報が含まれる設定ファイルが必要です。 ソース システム上で目的の場所にファイルを作成して、
.ini
拡張子を持つ任意の名前を付けることができます。 構成ファイルで、バックアップ ホストとしてターゲット クラスタ内のノードのホスト名を指定します。 以下の例に示されているように、
[Mapping]
セクションでノードを指定します。 ノードの短縮名ではなく、完全名を指定します(たとえば、
node0001
ではなく
v_vmart_node0001
)。
例:
以下のサンプル設定ファイルは 3 つのノード クラスタ(
v_vmart_node0001
v_vmart_node0002
、および
v_vmart_node0003
)上のデータベースを test-host01、test-host02、test-host03 のノードからなる別のクラスタにコピーするように設定されています。
dbName パラメータでは、大文字と小文字が区別されます。
[Misc]
snapshotName = CopyVmart
restorePointLimit = 5
objectRestoreMode = createOrReplace
tempDir = /tmp/vbr
retryCount = 5
retryDelay = 1
[Database]
dbName =
vmart
dbUser =
dradmin
dbPassword =
password
dbPromptForPassword = False
[Transmission]
encrypt = False
checksum = False
port_rsync = 50000
[Mapping]
; backupDir is not used for cluster copy
v_vmart_node0001= test-host01
v_vmart_node0002= test-host02
v_vmart_node0003= test-host03
/home/dradmin/backup
ディレクトリがマシンに存在することを確認します。
/tmp/vbr
ディレクトリに読み取りおよび書き込み権限があることを確認します。
ターゲット データベースの停止
移行を開始する前に、ターゲット クラスタ上でデータベースをシャット ダウンします。
以下の手順に従います。
  1. データベース管理者ユーザとしてターゲット データベース クラスタにログインします。
  2. Vertica admin Tools を開きます。
    /opt/vertica/bin/adminTools
  3. [(4) Stop Database]を選択します。 コピー クラスタを実行する前に、シャットダウンが完了するのを待ちます。
履歴データのコピー
新しいクラスタにデータベースをインストールした後、既存のデータベースからデータをコピーします。 コピー クラスタ コマンドは、コマンドを開始する前からすべての情報をコピーします。 コマンドが実行されている間、新しいデータは入り続けますが、コマンドはこのデータをコピーしません。 コピー クラスタを実行する前に、ターゲット クラスタを停止する必要があります。
以下の手順に従います。
  1. データベース管理者アカウントでソース クラスタにログインします。
  2. データベース管理者アカウントのパスワードなしの SSH が有効になっていることを確認します。 クラスタ インストールで、クラスタに含まれている
    ホストにパスワードなしの ssh キーがセットアップされていることを確認します。
    ssh
    hostname
    ls
    hostname
    は、Data Repository がインストールされているホストの名前です。
    パスワードなしの ssh キーがセットアップされている場合は、パスワードの入力は要求され
    ません
    。 パスワードの入力を促すプロンプトが表示されたら、パスワードなしの ssh をセットアップします。
    1. CTRL+C キーを押します。
    2. パスワードなしの ssh キーで、データベース管理者ユーザの Linux ユーザ アカウントをセットアップします。
      ssh-keygen -N "" -t rsa -f ~/.ssh/id_rsa
      cp ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys2
      chmod 644 ~/.ssh/authorized_keys2
    3. SSH 認証情報をクラスタ内の他のホストにコピーします。
      ssh-copy-id -i
      dradmin
      @
      other-hostname-in-the-cluster
    4. パスワードを要求
      されない
      ことを確認します。
      ssh hostname ls
  3. コピー クラスタ コマンドを実行します。
    vbr.py --task copycluster --config-file
    CopyClusterConfigurationFile
    .ini
    コマンドは、データベースの履歴データをコピーし、以下のメッセージを表示します。
    > vbr.py --config-file CopyVmart.ini --task copycluster
    Preparing...
    Copying...
    1871652633 out of 1871652633, 100%
    All child processes terminated successfully.
    copycluster done!
    copycluster
    コマンドが失敗した場合に、データベース管理者アカウントのパスワードなしの SSH が有効になっていることを確認します。
履歴データのコピーを確認します。
コピー クラスタの処理が完了したら、データの整合性を確認します。
以下の手順に従います。
  1. データベース管理者ユーザとしてターゲット データベース クラスタにログインします。
  2. Vertica adminTools を開きます。
    /opt/vertica/bin/adminTools
  3. データベースを起動します。
  4. クラスタ内の任意のノードから、Vertica SQL プロンプトを開きます。
    /opt/vertica/bin/vsql -U dauser
  5. これらの主要なデータベース テーブルのタイムスタンプを確認するため、以下のクエリを実行します。
    SELECT to_timestamp(max(tstamp)) from dauser.reach_rate;
    SELECT to_timestamp(max(tstamp)) from dauser.ifstats_rate;
    日付と時刻は、コピーを開始した時刻に対応している必要があります。
  6. adminTools を開き、データベースを停止します。
Data Aggregator の停止
データの整合性を維持するには、Data Repository の最終コピーの前に、Data Aggregator を停止します。 Data Aggregator の停止時に、実行およびポーリングしている場合、Data Collector でポーリングが続行されます。 後で Data Aggregator に配信するために、Data Collector のキューにデータがポーリングされます。
以下の手順に従います。
  1. root ユーザまたは sudo ユーザとして、Data Aggregator ホストにログインします。
    Data Aggregator を sudo ユーザとしてインストールした場合は、service dadaemon コマンド用の sudo コマンド エイリアスをセットアップします。 sudo コマンドを使用します。
  2. すべての Data Collector からのトラフィックをブロックするファイアウォール ルールを使用します。 各 Data Collector に対して、以下のコマンドを実行します。
    iptables -A INPUT -s
    DC_IP
    -j DROP
    DC_IP
    は、Data Collector の IP アドレスを指定します。
  3. 以下の手順のいずれかを実行します。
    • Data Aggregator サービスを停止します。
      service dadaemon stop
      RHEL 7.x または OL の場合、
      service
      systemctl
      を呼び出します。 代わりに
      systemctl
      を使用できます。
    • (フォールト トレラント環境)ローカルの Data Aggregator が実行されている場合は、次のいずれかのコマンドを実行することでシャットダウンして、メンテナンスが完了するまで再起動しないようにします。
      • RHEL 6.x:
        service dadaemon maintenance
      • RHEL 7.x、SLES、または OL:
        DA_Install_Directory/scripts/dadaemon maintenance
    Data Aggregator が停止します。
最近のデータのコピー
Data Aggregator を停止した後、再度コピー クラスタ コマンドを実行して、最近のデータをコピーします。 Data Repository は、最初のコピー後に到着した新しいデータのみをコピーします。
以下の手順に従います。
  1. データベース管理者アカウントでソース クラスタにログインします。
  2. コピー クラスタ コマンドを実行します。
    vbr.py --task copycluster --config-file
    CopyConfigurationFile
    .ini
    コマンドは最近のデータをコピーします。
最近のデータのコピーの確認
データの整合性を確保するため、データを確認します。
以下の手順に従います。
  1. データベース管理者ユーザとしてターゲット データベース クラスタにログインします。
  2. Vertica admin Tools を開きます。
    /opt/vertica/bin/adminTools
  3. データベースを起動します。
  4. クラスタ内の任意のノードから、Vertica SQL プロンプトを開きます。
    /opt/vertica/bin/vsql -U dauser
  5. これらの主要なデータベース テーブルのタイムスタンプを確認するため、以下のクエリを実行します。
    SELECT to_timestamp(max(tstamp)) from dauser.reach_rate;
    SELECT to_timestamp(max(tstamp)) from dauser.ifstats_rate;
    日付と時刻は、コピーを開始した時刻に対応している必要があります。
データベース接続情報の更新
Data Aggregator を移行しない場合に、Data Aggregator と新しい Data Repository クラスタ間の通信を有効にするには、データベース接続情報を更新します。
以下の手順に従います。
  1. Data Aggregator ホストにログインします。
  2. 以下のファイルを開きます。
    vi /opt/IMDataAggregator/apache-karaf-
    version
    /etc/dbconnection.cfg
  3. 新しい Data Repository クラスタのホスト名で以下のパラメータを更新します。
    dbHostNames=
    hostname1,hostname2,hostname3
Data Aggregator の再起動
移行の完了後、Data Aggregator を再起動します。
以下の手順に従います。
  1. root ユーザまたは sudo ユーザとして、Data Aggregator ホストにログインします。
    Data Aggregator を sudo ユーザとしてインストールした場合は、service dadaemon コマンド用の sudo コマンド エイリアスをセットアップします。 sudo コマンドを使用します。
  2. 以下の手順のいずれかを実行します。
    • Data Aggregator サービスを開始します。
      service dadaemon start
    • (フォールト トレラント環境)以下のいずれかのコマンドを実行することでフォールト トレラント Data Aggregator を有効化して、必要に応じて開始できるようにします。
      • RHEL 6.x:
        service dadaemon activate
      • RHEL 7.x、SLES、または OL:
        DA_Install_Directory
        /scripts/dadaemon activate
    Data Aggregator が起動し、CA
    NetOps Portal
    と Data Repository に同期されます。 iptables のエントリが削除されると、Data Collector でキューに入れられポーリングされたデータは Data Aggregator に送信されます。 キューに入れられたデータが、Data Collector システムに設定されているディスク容量制限を超えると、最も古いデータが破棄されます。 その結果、ポーリングされたレポート データに空白ができます。
  3. Data Aggregator の再起動プロセスを監視します。
    1. Data Aggregator ホストにログインし、以下のディレクトリに移動します。
      /opt/IMDataAggregator/performance-spool
    2. Data Aggregator サービスを開始した後に、数分待ちます。 0 より大きいサイズの DTO ファイルが存在しないことを確認します。
    3. ポーリングされるアイテムの最大数を持つ SNMP Data Collector からのトラフィックを有効にします。
      iptables -D INPUT -s
      DC_IP
      -j DROP
      Data Aggregator はスキーマの検証と、この Data Collector からのキャッシュおよびポーリングされた新しいデータの処理を開始します。
    4. Data Aggregator のシステム使用率が減少した後、残りの SNMP Data Collector からのトラフィックを有効にします。
    5. Data Aggregator のシステム使用率が減少した後、CAMM Data Collector からのトラフィックを有効にします。
移行の確認
Data Aggregator のスタートアップが完了したら、
NetOps Portal
にログインし、以下のインジケータを確認します。
  • システム ステータスが正常だと Data Aggregator データ ソースを利用できます。
  • 最終ポーリング日時を確認します。
  • Data Collector リストに移動し、すべての Data Collector が起動中およびデータ収集中であることを確認します。
  • インフラストラクチャ概要ダッシュボードを開き、データが以下の時間範囲で使用できることを確認します。
    • 過去 1 時間
    • 過去 7 日間