Skip Headers
StorageTek Tape Analytics 安装和配置指南
发行版 2.0
E53330-01
  转到目录
目录
转到索引
索引

上一页
上一页
 
下一页
下一页
 

9 升级 STA

本章介绍如何将 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 连接”。

9.1 在升级之前

  • 查阅 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.2 升级工作表


警告:

请查阅"在升级之前",了解哪些 STA 1.0.x 凭证和设置不会保留。

表 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 值必须与在磁带库上指定的值匹配。

9.3 升级概述

可以使用以下两种方法之一将 STA 1.0.x 升级到 2.0:

  • 单服务器方法(图 9-1:在为服务器重新配置 STA 2.0 时 STA 1.0.x 是脱机的(不监视磁带库),因此会增加停机时间。按数字顺序完成所有任务。

  • 双服务器方法(图 9-2:在一个单独的服务器配置 STA 2.0,在另一个服务器上 STA 1.0.x 保持联机(监视磁带库)。使用此方法时,按数字顺序完成任务。必须 按所示顺序完成任务。省略任务 7

9.4 升级流程


警告:

只应由 Linux 管理员和 STA 管理员执行升级。如果不严格按指定顺序执行各步骤,可能会导致数据丢失。

任务 1   (可选)记录 STA 1.0.x 设置

使用此过程获取 STA 1.0.x WebLogic 用户名、MySQL 数据库用户名和 SNMP 客户机属性。有关更多信息,请参见"在升级之前"


注:

与 WebLogic 用户名、MySQL 用户名和 SNMP 用户名关联的密码不可取回。

  1. 获取 WebLogic 用户列表:

    1. 使用您在 STA 安装过程中选择的 HTTP(默认为 7001)或 HTTPS(默认为 7002)端口号转至 WebLogic 控制台登录屏幕。

      http(s)://yourHostName:PortNumber/console/

    2. 使用 WebLogic 管理控制台用户名和密码登录。

    3. 在屏幕左侧的 "Domain Structure"(域结构)下,单击 Security Realms(安全领域)

      显示 "Security Realms"(安全领域)选项的位置
    4. 在 "Realms"(领域)下,选择 myrealm(选择名称本身,而不是复选框)。

      显示 "myrealm" 选项的位置
    5. 选择 Users and Groups(用户和组)选项卡。

      STA 用户列表会出现在 "Users"(用户)表中。

      显示 "Users and Groups"(用户和组)选项卡的位置
  2. 获取 MySQL 数据库用户列表:

    1. 在终端会话中,登录到 STA 1.0.x 服务器。

    2. 发出以下命令并在系统提示时输入您的 MySQL root 用户密码:

      # mysql -uroot -p -e "select distinct(user) from user order by user ;" mysql
      Enter password: root-password
      
    3. 记录显示的 STA 数据库用户名列表。例如:

      +--------+
      | user   |
      +--------+
      | root   |
      | staapp |
      | stadba |
      | starpt |
      +--------+
      
  3. 查看 SNMP 客户机属性:

    1. 使用 HTTP 端口号(默认为 7021)或 HTTPS 端口号(默认为 7022)转到 STA GUI 登录屏幕。"STA" 必须为大写。

      http(s)://yourHostName:PortNumber/STA/

    2. 使用 STA GUI 登录用户名和密码登录。

    3. 在导航菜单中,选择 Settings > SNMP Connections

      SNMP 用户名、用户社区字符串和陷阱社区字符串会显示在 "Client Attributes" 表中。

任务 2   转储 STA 1.0.x 数据库
  1. 在 STA 1.0.x 服务器上打开一个终端会话。

  2. 发出以下命令停止所有 STA 服务:

    # STA stop
    
  3. 通过发出以下命令启动 MySQL 服务:

    # service mysql start
    
  4. 通过发出以下命令,将数据库转储到单个文件中:

    # /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...
    
  5. 要将转储文件大小缩减约 50%,可用 gzip 压缩文件。

    # cd /path_to_dump_file/
    # gzip dump_file_name.sql
    
任务 3   转移 STA 1.0.x 数据库

在此任务中,经过压缩的 STA 1.0.x 数据库转储文件将转移到平台外的备份服务器(单服务器方法)或者转移到新的 STA 2.0 服务器(双服务器方法)。


警告:

在采用单服务器升级方法时,必须将 STA 数据库备份到其他服务器。不要将数据库备份到现有 STA 服务器上的文件系统,因为任务 4 中的 Linux 6.x 安装将销毁服务器上的所有数据。

  1. 在将文件转移到备份服务器之前执行校验和计算。

    # cksum dump_file_name.sql.gz
    

    输出将包括检验和值和字节计数。记录校验和值-在将文件转移到备份服务器之后,将使用该值来验证文件完整性。

  2. 使用 SCP 之类的转移实用程序将文件转移到目标服务器。-p 选项可保留时间戳值。

    # scp -p dump_file_name.sql.gz target_host:/path/
    

    示例 9-2 将 STA 1.0.x 数据库转移到备份服务器(单服务器方法)

    在此示例中,使用 SCP 将经过压缩的数据库转储文件 20130711_dump.sql.gz 转移到备份主机 backup1 上的 /root/dump 文件夹。

    # cd /root
    # scp -p 20130711_dump.sql.gz backup1:/root/dump
    

    示例 9-3 将 STA 1.0.x 数据库转移到新的 STA 2.0 服务器(双服务器方法)

    在此示例中,使用 SCP 将经过压缩的数据库转储文件 20130711_dump.sql.gz 转移到 STA 2.0 主机 sta_new 上的 /root 文件夹。

    # cd /root
    # scp -p 20130711_dump.sql.gz sta_new:/root
    
  3. 在目标服务器上,对转移的文件执行检验和计算。验证校验和值是否匹配。

    # cd /path_to_dump_file/
    # cksum dump_file_name.sql.gz
    
任务 4   在 STA 服务器上安装 Linux 6.x

警告:

如果采用单服务器方法,验证是否已成功地将 STA 数据库备份到其他服务器。在此任务中将销毁 STA 服务器上的所有数据。

由于 Linux 6.x 被视为 Linux 5.x 的重要升级,并且 Linux 不支持就地升级,因此无法在升级操作系统的同时保留现有的 Linux 5.x 文件系统。在 STA 1.0.x 服务器上安装 Linux 6.x 是全新安装。

要安装和配置 Linux 6.x,请参见章 1, "安装 Linux."

任务 5   在 STA 服务器上安装 STA 2.0
  1. 章 2, "安装 STA."所述安装 STA 2.0

  2. 登录到 STA 用户界面以确保 STA 正常工作,然后再执行剩余的升级任务(请参见"登录到 STA 用户界面")。

  3. 在 STA 服务器上打开一个终端会话。

  4. 发出以下命令停止所有 STA 2.0 服务:

    # STA stop all
    
  5. (可选)如果 STA 1.0.x 服务器配置为使用 SNMP v2c 与磁带库通信,则需要在 STA 2.0 服务器上启用 v2c 模式。执行附录 B, "为 STA 启用 SNMP v2c 模式,"中的过程,但省略停止并重新启动 STA 这个最后步骤-此操作已不必要,因为已经停止了 STA 并将在升级流程中稍后将其重新启动。

任务 6   转储新安装的 STA 2.0 数据库

在升级失败的情况下,使用备份转储文件将 STA 恢复到如下状态,在此状态下可以配置 STA 像是新安装的没有数据的系统一样运行。

  1. 通过发出以下命令启动 MySQL 服务:

    # STA start mysql
    
  2. 发出以下命令创建备份文件:

    # /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)。

任务 7   将 STA 1.0.x 数据库转移到 STA 2.0 服务器

仅适合单服务器方法:可以使用 SCP 将 STA 1.0.x 数据库的备份副本转移到 STA 2.0 服务器。-p 选项可保留时间戳值。

  1. 发出以下命令:

    # scp -p backup_host:/path_to_dump_file/dump_file_name.sql.gz /local_path
    

    示例 9-4 将 STA 1.0.x 数据库转移到 STA 2.0 服务器

    在此示例中,使用 SCP 将经过压缩的数据库转储文件 20130711_dump.sql.gz 从主机 backup1 上的 /root/dump 转移到 STA 2.0 服务器上的 /root 文件夹。

    # scp -p backup1:/root/dump/20130711_dump.sql.gz /root
    
  2. 对转移的文件执行检验和计算。确认检验和值与在任务 2 中收到的值匹配。

    # cd /path_to_dump_file/
    # cksum dump_file_name.sql.gz
    
任务 8   处理和装入 STA 1.0.x 数据库

在此任务中,解压缩经过压缩的 STA 1.0.x 数据库,并在 STA 服务器上恢复该数据库。

  1. 解压缩备份文件。

    # gunzip dump_file_name.sql.gz
    
  2. (可选)执行以下步骤清除 STA 数据库中的过时数据(例如,已经处理过的 SNMP 记录和空的分析记录。)强烈建议执行此操作,这将显著缩减数据库大小以及大小超过 1 GB 的数据库的装入时间。此任务的剩余步骤都假设执行了清除操作。purgerecs 命令活动的永久记录保存在 STA 数据库中。


    注:

    在 STA 2.0 中,也会在运行时自动清除数据库。MySQL Event Scheduler 会定期从数据库中清除已处理的 SNMP 记录,以最大程度地降低数据库的增长。

    1. 转到 STA 更新目录:

      # cd /Oracle/StorageTek_Tape_Analytics/db/updates
      
    2. 发出以下命令:

      # ./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
    
  3. (可选)使用以下命令确定数据库文件大小并估计装入过程时间。装入过程处理未压缩的数据库快照的速度为 5 分钟/1 GB

    # ls -s -h purged_dump_file_name.sql
    
  4. 装入 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/:将转储文件装入到数据库中。

任务 9   升级数据库

该过程处理未压缩的数据库快照的速度大约为 2 分钟/1 GB,具体取决于要升级的 STA 1.0.x 版本。

  1. 通过发出以下命令将 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                               |
    +-------------------------------------------------------------+
    

    注:

    如果升级失败,可尝试任务 8 中的步骤 4任务 9。如果升级再次失败,则数据库会处于一种未知的可能损坏状态。在这种情况下,应按如下所示将数据库恢复到其原始的新安装状态:
    1. 删除损坏的升级后数据库。

        # mysql -uroot -p -e "drop database stadb;"
      
    2. 装入在任务 6 中创建的全新安装数据库转储文件。

        # cd /dbbackup
      # mysql -uroot -p -e < STA_FRESH_INSTALL_BACKUP.sql
      
    3. 在执行了任务 9 之后,将 STA 配置为新安装。


  2. 通过发出以下命令启动所有 STA 服务。

    # STA start all
    

    警告:

    在此任务的步骤 1 中的数据库升级过程彻底完成之前,不要启动 STA。

  3. (可选)如果升级成功,请删除 STA_FRESH_INSTALL_BACKUP.sql 文件以释放 /dbbackup 卷上的磁盘空间。

任务 10   配置 STA 2.0
  1. 根据升级方法继续操作:

    • 单服务器方法:如果在升级过程中更改了 STA 服务器的 IP 地址,请重新添加每个磁带库的陷阱接收方列表以反映 STA 服务器的新 IP 地址。要重新添加陷阱接收方,请参见《STA 管理指南》中的“磁带库 SNMP 管理任务”。

    • 双服务器方法:将 STA 2.0 服务器作为新陷阱接收方添加到每个磁带库的 SNMP 配置中。请参见"创建 SNMP v3 陷阱接收方""创建 SNMP v2c 陷阱接收方"


    注:

    STA 2.0 支持两个新的陷阱级别 13(测试陷阱)和 14(运行状况陷阱)。如果以前未在每个受监视的磁带库的陷阱接收方列表上指定这些级别,则还需要重新添加包括级别 13 和 14 的陷阱接收方列表。

  2. 登录到 STA,如"登录到 STA 用户界面"中所述。

  3. 重新输入 SNMP 客户机属性,如"配置 STA 的 SNMP 客户机设置"中所述。

  4. 更新每个受监视的磁带库的连接详细信息。

    1. 在导航菜单中,选择 Setup & Administration > Configuration > SNMP Connections

    2. 在 "Monitored Libraries" 部分中,选择一个磁带库名称,然后单击 Edit 按钮。

    3. 在 "STA IP Address" 下拉列表中选择 STA 2.0 服务器的 IP 地址。

    4. 单击 Save

    5. 为列表中每个受监视的磁带库重复这些步骤。

  5. 要确保通信正常,请测试配置的每个磁带库的连接,如"测试到磁带库的 SNMP 连接"中所述。

    在测试连接之前,请记录 "Last Successful Connection" 和 "Last Connection Attempt" 时间戳。在执行了测试之后,可以比较时间戳以确保测试提供的是最新信息。

  6. 从每个磁带库获取最新数据,如"从磁带库获取最新配置数据"中所述。

  7. 执行"配置用户和电子邮件"中的过程来更改或创建 STA 用户并配置(和测试)电子邮件属性。

    如果在任务 1 中记录了其他 STA 用户(默认的管理控制台登录用户和 STA GUI 登录用户以外的用户),现在可以创建这些用户并为他们分配相应的角色。


    注:

    虽然在升级 STA 时会保留大多数电子邮件通知设置,但是需要重新启用 SMTP 通信以及重新输入电子邮件帐户密码。

  8. 按以下各章中的介绍配置(或重新配置)剩余的 STA 组件:

  9. 如果采用了双服务器方法,则现在可以让 STA 1.0.x 服务器退役。

    您可以选择从每个磁带库的 SNMP 配置中删除作为陷阱接收方的 STA 1.0.x 服务器。要删除陷阱接收方,请参见《STA 管理指南》中的“磁带库 SNMP 管理任务”。



脚注图例

脚注 1: 在 STA 2.0 中,其他应用程序用户是在 STA UI(而不是 WebLogic)中创建的。
脚注 2: 在升级之后,其他模板将显示为由 STA 拥有的公共模板。用户之后可以对其执行上载、指定为默认值、下载、修改、以不同名称保存和删除操作。