本章介绍如何将 STA 1.0.x 升级到 2.0。此流程不同于将 STA 1.0.x 升级到其他 1.0.x 版本。只能从以前的三个 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 设置。要在 STA 2.0 中使用相同的帐户用户名脚注 1 和 SNMP 客户机属性,可参考任务 1中的说明获取这方面的信息。要保留以 "STA-" 开头的已保存的公共模板,请在升级前用新名称保存它们脚注 2 。
确保 STA 1.0.x 已配置并且正常运行:在 "Monitored Libraries" 表中,确保每个磁带库最近曾与 STA 服务器成功通信。
下载软件:STA 2.0 包含两个大型介质包 ZIP 文件。可能需要现在就开始将这些文件下载到单独的平台,并同时执行前几项升级任务(请参见"下载 STA")。
表 9-1 STA 2.0 安装所需的信息
所需信息 |
STA 1.0.x 值 | STA 2.0 值脚注 1 |
---|---|---|
WebLogic 管理控制台登录用户名 |
||
WebLogic 管理控制台登录密码 |
||
STA GUI 登录用户名 |
||
STA GUI 登录密码 |
||
STA 数据库 root 帐户密码脚注 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) |
NA |
|
staEngine 受管服务器,HTTPS(默认为 7024) |
NA |
|
staAdapter 受管服务器,HTTP(默认为 7025) |
NA |
|
staAdapter 受管服务器,HTTPS(默认为 7026) |
NA |
|
公司域名(例如 us.oracle.com) |
脚注 1 可以将现有的 STA 1.0.x 值用于 STA 2.0,也可以选择新值。
脚注 2 任务 2, "转储 STA 1.0.x 数据库"需要数据库 root 帐户密码或 DBA 帐户密码。
表 9-2 STA 2.0 安装后配置所需的信息脚注 1
所需信息 |
STA 1.0.x 值 | STA 2.0 值 |
---|---|---|
SNMP v3 用户名 |
||
SNMP v3 授权密码 (Auth) |
||
SNMP v3 隐私加密密码 (Privacy) |
||
用户社区 |
||
陷阱社区 |
||
其他 WebLogic 用户名和密码 |
脚注 1 SNMP 值必须与在磁带库上指定的值匹配。
警告: 只应由 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 管理控制台用户名和密码登录。
在屏幕左侧的 "Domain Structure"(域结构)下,单击 Security Realms(安全领域)。
在 "Realms"(领域)下,选择 myrealm(选择名称本身,而不是复选框)。
选择 Users and Groups(用户和组)选项卡。
STA 用户列表会出现在 "Users"(用户)表中。
获取 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 用户名、用户社区字符串和陷阱社区字符串会显示在 "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 数据库被转储到 STA 服务器上的 root 文件夹中,文件名为 20130711_dump.sql。
# /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 数据库转储文件将转移到平台外的备份服务器(单服务器方法)或者转移到新的 STA 2.0 服务器(双服务器方法)。
在将文件转移到备份服务器之前执行校验和计算。
# 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
警告: 如果采用单服务器方法,验证是否已成功地将 STA 数据库备份到其他服务器。在此任务中将销毁 STA 服务器上的所有数据。 |
由于 Linux 6.x 被视为 Linux 5.x 的重要升级,并且 Linux 不支持就地升级,因此无法在升级操作系统的同时保留现有的 Linux 5.x 文件系统。在 STA 1.0.x 服务器上安装 Linux 6.x 是全新安装。
要安装和配置 Linux 6.x,请参见章 1, "安装 Linux."。
按章 2, "安装 STA."所述安装 STA 2.0
登录到 STA 用户界面以确保 STA 正常工作,然后再执行剩余的升级任务(请参见"登录到 STA 用户界面")。
在 STA 服务器上打开一个终端会话。
发出以下命令停止所有 STA 2.0 服务:
# STA stop all
(可选)如果 STA 1.0.x 服务器配置为使用 SNMP v2c 与磁带库通信,则需要在 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...
仅适合单服务器方法:可以使用 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
(可选)执行以下步骤清除 STA 数据库中的过时数据(例如,已经处理过的 SNMP 记录和空的分析记录。)强烈建议执行此操作,这将显著缩减数据库大小以及大小超过 1 GB 的数据库的装入时间。此任务的剩余步骤都假设执行了清除操作。purgerecs
命令活动的永久记录保存在 STA 数据库中。
注: 在 STA 2.0 中,也会在运行时自动清除数据库。MySQL Event Scheduler 会定期从数据库中清除已处理的 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 个记录会显示一个进度点。
# 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
(可选)使用以下命令确定数据库文件大小并估计装入过程时间。装入过程处理未压缩的数据库快照的速度为 5 分钟/1 GB。
# 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/:将转储文件装入到数据库中。
该过程处理未压缩的数据库快照的速度大约为 2 分钟/1 GB,具体取决于要升级的 STA 1.0.x 版本。
通过发出以下命令将 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 卷上的磁盘空间。
根据升级方法继续操作:
单服务器方法:如果在升级过程中更改了 STA 服务器的 IP 地址,请重新添加每个磁带库的陷阱接收方列表以反映 STA 服务器的新 IP 地址。要重新添加陷阱接收方,请参见《STA 管理指南》中的“磁带库 SNMP 管理任务”。
双服务器方法:将 STA 2.0 服务器作为新陷阱接收方添加到每个磁带库的 SNMP 配置中。请参见"创建 SNMP v3 陷阱接收方"或"创建 SNMP v2c 陷阱接收方"。
注: STA 2.0 支持两个新的陷阱级别 13(测试陷阱)和 14(运行状况陷阱)。如果以前未在每个受监视的磁带库的陷阱接收方列表上指定这些级别,则还需要重新添加包括级别 13 和 14 的陷阱接收方列表。 |
登录到 STA,如"登录到 STA 用户界面"中所述。
重新输入 SNMP 客户机属性,如"配置 STA 的 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 组件:
如果采用了双服务器方法,则现在可以让 STA 1.0.x 服务器退役。
您可以选择从每个磁带库的 SNMP 配置中删除作为陷阱接收方的 STA 1.0.x 服务器。要删除陷阱接收方,请参见《STA 管理指南》中的“磁带库 SNMP 管理任务”。
脚注图例
脚注 1: 在 STA 2.0 中,其他应用程序用户是在 STA UI(而不是 WebLogic)中创建的。