| StorageTek Tape Analytics インストールおよび構成ガイド リリース 2.0 E53328-01 |
|
 前 |
 次 |
この章では、STA 1.0.x を 2.0 にアップグレードする方法について説明します。このプロセスは、STA 1.0.x を別の 1.0.x バージョンにアップグレードするプロセスとは異なります。前にリリースされた 3 つの STA 1.0 バージョン 1.0.0.99、1.0.1.133、および 1.0.2.24 からのみアップグレードできます。アップグレード後に、STA は、新しいバージョンのスキーマと分析ルールに従って新しいデータを処理します (履歴データは再処理されません)。
|
注: ライブラリファームウェアと STA を同時にアップグレードする場合、ライブラリエンジン ID と SNMP 構成の更新が必要になることがあります。『STA 管理ガイド』内の「ライブラリ SNMP 接続の管理」を参照してください。 |
STA 2.0 の要件の確認:『STA 要件ガイド』を参照してください。
別のサーバーへのデータベースバックアップの移動: STA バックアップサービスを使用して作成されたデータベースバックアップは、アップグレード後には無効になります。
STA 1.0.x 設定の記録: WebLogic および MySQL の資格証明、ポート番号、SNMP クライアント属性、および「STA-」から始まるパブリックテンプレートは保持されません。"アップグレードワークシート"を使用して、STA 1.0.x 設定を記録してください。同じアカウントユーザー名脚注 1 と SNMP クライアント属性を STA 2.0 で使用するために、タスク 1 に、この情報を取得するための手順が記載されています。「STA-」で始まる保存済みのパブリックテンプレートを保持するには、アップグレード前に新しい名前で保存します脚注 2 。
STA 1.0.x が正しく構成され、動作していることの確認: 「Monitored Libraries」表で、各ライブラリに STA サーバーとの最新の正常な通信があることを確認します。
ソフトウェアのダウンロード: STA 2.0 は、2 つの大きなメディアパック ZIP ファイルで構成されます。最初のいくつかのアップグレードタスクを実行している間に、別のプラットフォームへのファイルのダウンロードを開始してもかまいません ("STA のダウンロード"を参照)。
表 9-1 STA 2.0 のインストールに必要な情報
| 必要な情報 |
STA 1.0.x の値 | STA 2.0 の値脚注 1 |
|---|---|---|
|
WebLogic 管理コンソールのログインユーザー名 |
||
|
WebLogic 管理コンソールのログインパスワード |
||
|
STA GUI ログインユーザー名 |
||
|
STA GUI ログインパスワード |
||
|
STA データベースのルートアカウントパスワード脚注 2 |
||
|
STA データベースのアプリケーションアカウントユーザー名 |
||
|
STA データベースのアプリケーションアカウントパスワード |
||
|
STA データベースのレポートアカウントユーザー名 |
||
|
STA データベースのレポートアカウントパスワード |
||
|
STA データベースの DBA アカウントユーザー名 |
||
|
STA データベースの DBA アカウントパスワード脚注 2 |
||
|
WebLogic 管理コンソールのログインポート、HTTP (デフォルトは 7001) |
||
|
WebLogic 管理コンソールのログインポート、HTTPS (デフォルトは 7002) |
||
|
STA GUI ログイン/staUi 管理対象サーバーのポート、HTTP (デフォルトは 7021) |
||
|
STA GUI ログイン/staUi 管理対象サーバーのポート、HTTPS (デフォルトは 7022) |
||
|
staEngine 管理対象サーバー、HTTP (デフォルト = 7023) |
なし |
|
|
staEngine 管理対象サーバー、HTTPS (デフォルト = 7024) |
なし |
|
|
staAdapter 管理対象サーバー、HTTP (デフォルト = 7025) |
なし |
|
|
staAdapter 管理対象サーバー、HTTPS (デフォルト = 7026) |
なし |
|
|
会社のドメイン名 (たとえば、us.oracle.com) |
脚注 1 STA 2.0 に既存の STA 1.0.x の値を使用するか、新しい値を選択できます。
脚注 2 データベースのルートまたは DBA アカウントパスワードはタスク 2, "STA 1.0.x データベースのダンプ" に必要です。
表 9-2 STA 2.0 のインストール後の構成に必要な情報脚注 1
| 必要な情報 |
STA 1.0.x の値 | STA 2.0 の値 |
|---|---|---|
|
SNMP v3 ユーザー名 |
||
|
SNMP v3 承認パスワード (承認) |
||
|
SNMP v3 プライバシ暗号化パスワード (プライバシ) |
||
|
ユーザーコミュニティー |
||
|
トラップコミュニティー |
||
|
追加の WebLogic ユーザー名とパスワード |
脚注 1 SNMP 値は、ライブラリで指定する値と一致する必要があります。
1 台のサーバーの方法 (図 9-1): すべてのタスクを番号順に実行します。
タスク 1、タスク 2、タスク 3、タスク 4、タスク 5、タスク 6、タスク 7、タスク 8、タスク 9、タスク 10
2 台のサーバーの方法 (図 9-2): タスクを番号順に実行しません。タスクは、次の順序で実行する必要があり、タスク 7 は省略します。
|
注意: Linux 管理者と STA 管理者のみが、アップグレードを実行するべきです。記載された順序どおりに正確に段階を実行しなかった場合、データが失われる可能性があります。 |
STA 1.0.x WebLogic ユーザー名、MySQL データベースユーザー名、および SNMP クライアント属性を取得するには、次の手順を使用します。詳細は、"アップグレード前に"を参照してください。
|
注: WebLogic、MySQL、および SNMP ユーザー名に関連付けられたパスワードは取得できません。 |
WebLogic ユーザーのリストを取得するには、次の手順に従います。
STA のインストール中に選択した HTTP (デフォルトは 7001) または HTTPS (デフォルトは 7002) のポート番号を使用して、WebLogic コンソールのログイン画面に移動します。
http(s)://yourHostName:PortNumber/console/
WebLogic 管理コンソールのユーザー名とパスワードを使用してログインします。
「ドメイン構造」(画面の左側) で、「セキュリティ・レルム」をクリックします。
「レルム」で、「myrealm」を選択します (チェックボックスではなく、名前自体を選択します)。
「ユーザーとグループ」タブを選択します。
STA ユーザーのリストが「ユーザー」表内に表示されます。
MySQL データベースユーザーのリストを取得するには、次の手順に従います。
端末セッションで、STA 1.0.x サーバーにログインします。
次のコマンドを発行して、プロンプトが表示されたら MySQL root ユーザーのパスワードを入力します。
# mysql -uroot -p -e "select distinct(user) from user order by user ;" mysql Enter password: root-password
表示される STA データベースユーザー名のリストを記録します。例:
+--------+ | user | +--------+ | root | | staapp | | stadba | | starpt | +--------+
SNMP クライアント属性を表示するには、次の手順に従います。
HTTP (デフォルトは 7021) または HTTPS (デフォルトは 7022) ポート番号を使用して、STA GUI ログイン画面に移動します。「STA」は大文字である必要があります。
http(s)://yourHostName:PortNumber/STA/
STA GUI ログインユーザー名とパスワードを使用してログインします。
ナビゲーションメニューで、「Settings」>「SNMP Connections」を選択します。
「SNMP Username」、「User Community」の文字列、および「Trap Community」の文字列が「Client Attributes」表に表示されます。
STA 1.0.x サーバーで端末セッションを開きます。
次のコマンドを発行して、すべての STA サービスを停止します。
# STA stop
次のコマンドを発行して、MySQL サービスを起動します。
# service mysql start
次のコマンドを発行して、データベースを単一のファイルにダンプします。
# /usr/bin/mysqldump -uroot -p --opt --routines --events --flush-logs --single-transaction --complete-insert --comments --dump-date --add-drop-database --databases stadb -v > /desired_path_for_dumpfile/dump_file_name.sql Enter password: mysql_root_password
|
注: -v (詳細出力のためののオプション) は、コマンドの進捗を表示します。ただし、大きなデータベースでは、ダンププロセスが大幅に遅くなる可能性があります。 |
例 9-1 STA 1.0.x データベースのダンプ
この例では、STA 1.0.x データベースは、ファイル名 20130711_dump.sql で STA サーバーの root フォルダにダンプされます。
# /usr/bin/mysqldump -uroot -p --opt --routines --events --flush-logs --single-transaction --complete-insert --comments --dump-date --add-drop-database --databases stadb -v > /root/20130711_dump.sql
Enter password: mysql_root_password
...
-- Retrieving view structure for table v_library_complex_io...
...
-- Retrieving view structure for table v_library_summary_averages...
-- It's base table, skipped
...
-- Retrieving table structure for table v_mdv_status_codes...-- It's a view, create dummy table for view
...
-- Disconnecting from localhost...
ダンプファイルサイズを約 50% 縮小するには、ファイルを gzip します。
# cd /path_to_dump_file/ # gzip dump_file_name.sql
このタスクでは、圧縮済みの STA 1.0.x データベースダンプファイルをプラットフォーム外のバックアップサーバー (1 台のサーバーの方法) または新しい STA 2.0 サーバー (2 台のサーバーの方法) のいずれかに転送します。
|
注意: 1 台のサーバーのアップグレード方法に従うときには、STA データベースを別のサーバーにバックアップする必要があります。タスク 4 の Linux 6.x のインストールによって、既存の STA サーバー上のデータはすべて破棄されるため、このサーバー上のファイルシステムにはデータベースをバックアップしないでください。 |
ファイルをバックアップサーバーに転送する前に、チェックサムを実行します。
# cksum dump_file_name.sql.gz
出力には、チェックサム値とバイト数が含まれています。チェックサム値を記録します。ファイルをバックアップサーバーに転送したあとで、これを使用してファイルの整合性を検証します。
SCP などの転送ユーティリティーを使用して、ファイルをターゲットサーバーに転送します。-p オプションは、タイムスタンプ値を保存します。
# scp -p dump_file_name.sql.gz target_host:/path/
ターゲットサーバーで、転送されたファイルのチェックサムを実行します。チェックサム値が一致することを確認します。
# cd /path_to_dump_file/ # cksum dump_file_name.sql.gz
|
注意: 1 台のサーバーの方法に従う場合は、STA データベースが別のサーバーに正常にバックアップされたことを確認してください。STA サーバー上のデータはすべてこのタスクで破棄されます。 |
Linux 6.x は Linux 5.x からのメジャーアップグレードであると考えられているため、インプレースアップグレードは Linux ではサポートされません。既存の Linux 5.x ファイルシステムを保持しながら OS をアップグレードすることはできません。Linux 6.x は STA 1.0.x サーバーに新規インストールされます。
Linux 6.x をインストールして構成するには、章 1, "Linux のインストール."を参照してください
章 2, "STA のインストール."に従って STA 2.0 をインストールします
残りのアップグレードタスクを実行する前に、STA ユーザーインタフェースにログインして、STA が正しく動作していることを確認します ("STA ユーザーインタフェースへのログイン"を参照)。
STA サーバーで端末セッションを開きます。
次のコマンドを発行して、すべての STA 2.0 サービスを停止します。
# STA stop all
(オプション) SNMP v2c を使用してライブラリと通信するように STA 1.0.x サーバーが構成されていた場合、STA 2.0 サーバーで v2c モードを有効にする必要があります。付録 B, "STA の SNMP v2c モードの有効化,"の手順に従いますが、STA を停止して再起動するための最後の段階は省略します。すでに STA を停止しており、アップグレードプロセスの後半で再起動するため、これは不要です。
アップグレードが失敗した場合は、バックアップダンプファイルを使用して、データなしで新規インストールした場合と同じように実行するように STA を構成できる状態に STA を回復します。
次のコマンドを発行して、MySQL サービスを起動します。
# STA start mysql
次のコマンドを発行して、バックアップファイルを作成します。
# /usr/bin/mysqldump -uroot -p --opt --routines --events --flush-logs --single-transaction --complete-insert --comments --dump-date --add-drop-database --databases stadb -v > /dbbackup/STA_FRESH_INSTALL_BACKUP.sql Enter password: mysql_root_password
出力は、次のようになります。
... -- Retrieving view structure for table v_mdv_request_states... -- Retrieving view structure for table version_info... ... -- Disconnecting from localhost...
|
注: 「Can’t connect to local MySQL server」が表示される場合、MySQL サーバーは実行中ではありません。MySQL が起動されていることを確認します (段階 1)。 |
1 台のサーバーの方法のみ: SCP を使用して、STA 1.0.x データベースのバックアップ済みコピーを STA 2.0 サーバーに転送できます。-p オプションは、タイムスタンプ値を保存します。
次のコマンドを発行します。
# scp -p backup_host:/path_to_dump_file/dump_file_name.sql.gz /local_path
転送されたファイルのチェックサムを実行します。チェックサム値が、タスク 2 で受け取った値と一致することを確認します。
# cd /path_to_dump_file/ # cksum dump_file_name.sql.gz
このタスクでは、圧縮済みの STA 1.0.x データベースを STA サーバーで圧縮解除して、復元します。
バックアップファイルを圧縮解除します。
# gunzip dump_file_name.sql.gz
(オプション) 次の段階を実行して、廃止されたデータ (たとえば、すでに処理された SNMP レコードや空の分析レコード) の STA データベースをパージします。これを強くお勧めします。サイズが 1G バイトを超えるデータベースでのデータベースサイズとロード時間が大幅に縮小します。このタスクの残りの段階では、パージが実行されていることを想定しています。purgerecs コマンドアクティビティーの永続レコードは、STA データベースに保存されます。
|
注: STA 2.0 では、データベースのパージも実行時に自動的に行われます。データベースが大きくなるのを最小限に抑えるために、定期的に、MySQL のイベントスケジューラは、処理された SNMP レコードをデータベースからパージします。 |
STA 更新ディレクトリに移動します。
# cd /Oracle/StorageTek_Tape_Analytics/db/updates
次のコマンドを発行します。
# ./purgerecs /path_to_dump_file/dump_file_name.sql /path_to_dump_file/purged_dump_file_name.sql
|
注: purgerecs コマンドのヘルプについては、次のように入力します。
# ./purgerecs -h
|
例 9-5 STA 1.0.x データベースからの廃止されたデータのパージ
この例では、purgerecs ユーティリティーを使用して、/root 内の圧縮解除済み MySQL ダンプファイル 20130711_dump.sql がパージされ、出力は /root 内の 20130711_dump_purged.sql という新しいファイルに送信されます。200 のレコードが処理されるたびに、進捗を示すドットが 1 つ表示されます。
# cd /Oracle/StorageTek_Tape_Analytics/db/updates
# ./purgerecs /root/20130711_dump.sql /root/20130711_dump_purged.sql
................................................
STA v1.0.2, Schema 33.02
Processed 11,689 lines from '20130711_dump.sql':
------------------------------------------------
snmp_storage_cells........1,614,255
snmp_media................110,205
...
media_summaries...........254
transform_logs............0
================================================
Records Processed:........13,143,283
Records Purged:...........2,857,623
Records Remaining:........10,285,660
Elapsed Time:.............00:00:11
(オプション) 次のコマンドを使用して、データベースファイルサイズを判別し、ロードプロセス時間を推測します。ロードプロセスには、実行する圧縮解除済みデータベーススナップショットサイズのG バイトあたり最大 5 分かかります。
# ls -s -h purged_dump_file_name.sql
STA 1.0.x データベースをロードします。
# mysql -uroot -p -e "SET SESSION SQL_LOG_BIN=0; SOURCE /path_to_dump_file/dump_file_name;" Password: mysql_root_password
コマンドが成功した場合は、プロセスの完了後にコマンドプロンプトに戻ります。-v (詳細) オプション (推奨されません) を指定した場合を除き、プロセスの実行中にコマンド出力は表示されません。
コマンドの説明:
-p: STA 2.0 のインストール中に設定した MySQL root パスワードを要求します。
-v: 詳細出力 (オプション)。これによって、ロードプロセスが大幅に遅くなります。
-e: 次の引用符で囲まれた文を実行します
SET SESSION SQL_LOG_BIN=0;: これは、不要なバイナリロギングをオフにするため、ロードの速度が上がります。
SOURCE /path_to_dump_file/: ダンプファイルを DB にロードします。
このプロセスには、アップグレードする STA 1.0.x バージョンに応じて、実行する圧縮解除済みデータベーススナップショットサイズの G バイトあたり約 2 分かかります。
次のコマンドを発行して、STA 1.0.x データベースを新しい STA 2.0 スキーマにアップグレードします。
# cd /Oracle/StorageTek_Tape_Analytics/db/updates # ./upgradedb.sh DB Root Password: mysql_root_password
|
注: セキュリティー上の理由により、パスワードは表示されません。upgradedb.sh コマンドのヘルプについては、次のように入力します。
# ./upgradedb.sh -h
|
出力例:
+-------------------------------------------------------------+ | STA DATABASE UPGRADE | | Upgrading DB schema from 49.00r0 to 50.00r0 | | Started: 2014-01-14 01:21:47 | +-------------------------------------------------------------+ STA database contains approximately 4,301 records. installed version 49.00 is a valid upgrade candidate, proceeding... ...allow approximately two minutes per 1GB of file size...
プロセスが完了すると、次のようなバナーが表示されます。
+-------------------------------------------------------------+ | Started.................2014-01-14 01:21:47 | | Finished................2014-01-14 01:21:54 | | Elapsed Time............00:00:07 | | Starting Version........49.00r0 | | Final Schema Version....50.00r0 | | Schema Release Date.....2014-01-08 15:16:17 | | Records (approximate)...4,282 | +-------------------------------------------------------------+
次のコマンドを発行して、すべての STA サービスを起動します。
# STA start all
(オプション) アップグレードが正常に完了した場合、STA_FRESH_INSTALL_BACKUP.sql ファイルを削除して、/dbbackup ボリュームのディスク容量を解放します。
アップグレード方法に従って続行します。
1 台のサーバーの方法: アップグレードプロセス中に STA サーバーの IP アドレスを変更した場合、各ライブラリのトラップ受信者リストを再度追加して、STA サーバーの新しい IP アドレスを反映させます。トラップ受信者を再度追加するには、『STA 管理ガイド』の「ライブラリ SNMP 管理タスク」を参照してください。
2 台のサーバーの方法: STA 2.0 サーバーを新しいトラップ受信者として各ライブラリの SNMP 構成に追加します。"SNMP v3 トラップ受信者の作成"または"SNMP v2c トラップ受信者の作成"を参照してください。
|
注: STA 2.0 では、2 つの新しいトラップレベルである 13 (テストトラップ) と 14 (ヘルストラップ) がサポートされます。それぞれのモニター対象ライブラリのトラップ受信者リストでこれらのレベルを以前に指定しなかった場合、レベル 13 と 14 を含めたトラップ受信者リストも再度追加する必要があります。 |
"STA ユーザーインタフェースへのログイン"の説明に従って STA にログインします。
"STA の SNMP クライアント設定の構成"の説明に従って SNMP クライアント属性を再度入力します。
モニター対象ライブラリごとに接続の詳細を更新します。
ナビゲーションメニューで、「Setup & Administration」>「Configuration」>「SNMP Connections」を選択します。
「Monitored Libraries」セクションで、ライブラリ名を選択して、「Edit」ボタンをクリックします。
「STA IP Address」ドロップダウンで STA 2.0 サーバーの IP アドレスを選択します。
「Save」をクリックします。
リスト内のモニター対象ライブラリごとにこれらの段階を繰り返します。
正しい通信を行うには、"ライブラリへの SNMP 接続のテスト"の説明に従って、それぞれの構成済みライブラリへの接続をテストします。
接続をテストする前に、「Last Successful Connection」と「Last Connection Attempt」のタイムスタンプを書き留めます。テストの実行後に、タイムスタンプを比較して、テストで最新の情報が提供されていることを確認できます。
"ライブラリからの最新の構成データの取得"の説明に従って、各ライブラリから最新データを取得します。
"ユーザーと電子メールの構成"の手順に従って、STA ユーザーを変更または作成し、電子メールプロパティーを構成 (およびテスト) します。
タスク 1 で追加の STA ユーザー (デフォルトの管理コンソールログインユーザーと STA GUI ログインユーザー以外) を記録した場合、この時点でこれらの同じユーザーを作成して、必要に応じて役割を割り当てることができます。
|
注: STA のアップグレード時にほとんどの電子メール通知設定は保持されますが、SMTP 通信を再度有効にして、電子メールアカウントのパスワードを再度入力する必要があります。 |
次の章に従って、STA の残りのコンポーネントを構成 (または再構成) します。
2 台のサーバーの方法に従った場合、この時点で STA 1.0.x サーバーを廃止してもかまいません。
オプションで、各ライブラリの SNMP 構成から、トラップ受信者としての STA 1.0.x サーバーを削除できます。トラップ受信者を削除するには、『STA 管理ガイド』の「ライブラリ SNMP 管理タスク」を参照してください。
脚注の凡例
脚注 1: STA 2.0 では、追加のアプリケーションユーザーが WebLogic ではなく STA UI 内に作成されます。