内容


为 IBM DB2 Content Manager 启用 Tivoli Storage Manager

实践方法

Comments

简介

对于企业来说,信息就意味着企业健康与财富。缺乏随时可用的信息的代价十分高昂。IBM Software Group 的高级副总裁 Steve Mill 曾经这样说:“除了人才之外,信息就是企业最宝贵的资产。但如果未能有效地管理信息,未能将其交付给正确的人员、商业应用程序和流程,其价值就无从体现。”

现今,80% 的企业数据依然为非结构化格式。由于分散的数据数量庞大,因此及时定位特定信息块可能会成为严峻的挑战。归档硬拷贝文件或在硬盘上保存重要文件 —— 而且可能没有共享的方法 —— 依然是当今的主流。IBM DB2 Content Manager 这样的 Enterprise Content Management 解决方案提供了从内容创建一直到处理的信息全生命周期管理解决方案。

Tivoli Storage Manager 和 DB2 Content Manager 的无缝集成根据管理员设置的策略启用要移植的对象。在很多时候,此类移植的目标都是将不太常用的数据转储到更便宜的外部设备上进行长期存储。DB2 Content Mananger 加上 DB2 Record Manager 可满足您的法规遵从需求。这通常还会要求具备硬件部分(例如 IBM TotalStorage Data Retention 550,即 DR550)。

Tivoli Storage Manager 还会在发生硬件故障时参与 DB2 Content Manager 数据库的备份与还原(Library Server and Resource Manager)。另外,DB2 Content Manager 中存储的对象可利用 Tivoli Storage Manager 进行加密/解密及压缩/解压缩。

在继续讨论之前,先简要介绍一下 IBM DB2 Content Manager 提供的部分其他特性:

  • 特殊扫描
  • 批量载入不同格式的内容
  • 经由 Windows 客户机、Web 客户机或 portlet 的本地内容查看器
  • 登记/注销
  • 过程工作流(可使用 GUI 工作流构建器构建)
  • 版本控制
  • 注释
  • LDAP 集成
  • 事件日志记录(包括用户和管理活动)
  • 与 SAP 及 Siebel 的集成
  • 与记录管理(如 IBM DB2 Record Manager)集成以实现法规遵从
  • 与客户的现有业务线集成
  • 可在应用程序内部使用或与其他 Web 服务协同使用的 Web 服务接口
  • XML 模式映射

下面详细介绍各类特性,包括以下主题:

服务器准备

AIX 系统 —— 硬件

在尝试集成两者之前,务必确保满足硬件和软件先决条件。(近乎 60% 至 70% 的安装问题都是由于未满足硬件需求引起的。)对于硬件,推荐系统配置为 1 个 CPU 和 1GB 内存。本文所用的硬件(P615)配置如下:

  • 双路处理器(1.65GHz)
  • 4GB RAM
  • 2 块内部硬盘(指派为 rootvg)
  • 2 块连接到 IBM 2104 的外部硬盘(指派为 techvg)

AIX 系统 —— 软件、维护级别与文件系统

为此系统安装的维护级别和软件为:

  • 具有维护级别(ML)7 的 AIX 5.2
  • gzip 实用工具
  • Mozilla Firefox 1.5.0.1

安装上述软件后,在 AIX 上实现了以下配置。注意,不要求您具有完全相同的文件系统布局。但可参考此布局(若是第一次使用此组合,建议您使用此布局)。

  • 创建的卷组:
    • 指派给 rootvg 的 hdisk0 与 hdisk1
    • 指派给 tchvg 的 hdisk2 与 hdisk3
  • 安装目录:
    • 本文所有组件的安装目录为 /usr(rootvg)
  • 创建的文件系统:
    • 存储 TSM 数据库与还原文件的文件系统 —— /tsmcore(rootvg)
    • 存储 TSM 备份数据的文件系统 —— /tsmtier1a 和 /tsmtier1b
    • 存储 TSM 归档数据的文件系统 —— /tsmtier2a 和 /tsmtier2b
    • 存储 TSM 数据库备份的文件系统 —— /tsmdbbkup

图 1 归纳了本练习的系统布局:

图 1. 对象移植场景硬件布局
对象移植场景硬件布局
对象移植场景硬件布局

对于 AIX 和 TSM 级别,有数不胜数的命令需要发出,因此约定 TSM>AIX# 分别表示 TSM 和 AIX 中发出的命令。

DB2 Content Manager 系统检查

在本文中,我们使用 DB2 Content Manager V8.3 与 TSM 5.3 相集成。下面列出软件先决条件。 (另请参考 所支持的软件 列表。)

  • DB2 Universal Database 8.1(Fixpack 7b)
  • WebSphere Application Server 5.1(Fixpack 1)
  • Information Integrator for Content 8.3
  • DB2 Content Manager 8.3 Server(Fixpack 1)
  • DB2 Content Manager eClient 8.3

为简单起见,DB2 Content Manager 将作为独立应用程序与 Library Server and Resource Manager 安装在同一台计算机上。但一般情况下,DB2 Library Server and Resource Manager 往往在其他服务器上运行,以确保获得更好的可伸缩性和性能。关于不同的安装配置,请参见 DB2 Content Manager Planning Wizard

在尝试集成 DB2 Content Manager 与 Tivoli Storage Manager 之前,最好运行 DB2 Content Manager 验证工具,以确保 Content Manager 工作正常。在 /opt/IBM/db2cmv8/bin 中运行 cminstvu 命令。您应看到验证成功信息,如 图 2。(验证 II4C 和 eClient 也没有什么坏处。)

图 2. DB2 Content Manager 验证工具
欢迎屏幕
欢迎屏幕

同样,确保能够看到 Resource Manager System Manage Storage(SMS),如 图 3 所示:

图 3. System Manage Storage
欢迎屏幕
欢迎屏幕

假如 DB2 Content Manager 验证失败,应先修复问题,然后再进行下一步。请参考 DB2 Content Manager 安装技巧(参见 下载 部分)。

集成 —— DB2 Content Manager 与 Tivoli Storage Manager

本文第一部分的目的在于将旧对象从 DASD 转移到外部存储中,这要求具备 Tivoli Storage Manager 并将其与 DB2 Content Manager Resource Manager 相集成。(更多信息请参见 “Comparing IBM DB2 Content Manager family products, Part 1: DB2 Content Manager: Technical and licensing comparisons”(developerWorks,2005 年 12 月)。)这一部分概述的安装与配置 TSM 和配置 Resource Manager 属性文件是先决步骤,完成这些步骤之后,管理员才能在 DB2 Content Manager System Administration Client 中的 System Manage Storage(SMS)上工作。

下面详细介绍如何执行以下任务:

Tivoli Storage Manager(TSM)安装

就本文而言,安装了以下 TSM 软件,并将其配置为与 DB2 Content Manager 8.3 共同使用:

  • Tivoli Storage Manager Server 5.3 for AIX
  • Tivoli Storage Manager Backup/Archive (B/A) Client 5.3 for AIX

请注意,在本文中 Tivoli Storage Manager 是安装在同一台计算机上的。但在生产系统中,总是建议将 TSM 分离出来,在其自己的一台计算机上安装。如果拥有一个以上的 Resource Manager,就需要以各 Resource Manager 的 icmrm.properties 为基础,为每个 Resource Manager 定义一个 TSM API 客户机选项文件。但在本文中,仅部署了一个 Resource Manager。

同样,在本文中,并未安装 TSM 5.3 的 Integrated Solution Console(ISC)和 Administration Center(AC)。所有安装和配置都是使用 TSM 的命令提示符完成的(仅有几条命令)。如果愿意,尽可随时选择安装 ISC。

选择并安装到 AIX 服务器上的文件集如下:

  • Tivoli Storage Manager Server 5.3 文件集:
    • tivoli.tsm.devices.aix5.rte —— IBM Tivoli Storage Manager Device Support Runtime
    • tivoli.tsm.license.cert —— IBM Tivoli Storage Manager License Certificates
    • tivoli.tsm.license.rte —— IBM Tivoli Storage Manager 32 bit License Registration
    • tivoli.tsm.msg.en_US.devices —— IBM Tivoli Storage Manager Devices SMIT Menus,US English
    • tivoli.tsm.msg.en_US.server —— IBM Tivoli Storage Manager Server Msgs,US English
    • tivoli.tsm.server.com —— IBM Tivoli Storage Manager Server 公共服务
    • tivoli.tsm.server.rte —— IBM Tivoli Storage Manager 32 bit Server Runtime
    • tivoli.tsm.server.webcon —— IBM Tivoli Storage Manager Web Console intfc
  • Tivoli Storage Manager Client 5.3 文件集:
    • tivoli.tsm.client.api.32bit —— TSM Client —— Application Programming Interface 32 bit
    • tivoli.tsm.client.ba.32bit.base —— TSM Client —— Backup/Archive Base Files
    • tivoli.tsm.client.ba.32bit.common —— TSM Client —— Backup/Archive Common Files
    • tivoli.tsm.client.ba.32bit.image —— TSM Client —— IMAGE Backup Client
    • tivoli.tsm.client.ba.32bit.nas —— TSM Client —— NAS Backup Client
    • tivoli.tsm.client.ba.32bit.web —— TSM Client —— Backup/Archive WEB Client

使用 AIX 的 smitty 实用工具安装 TSM Server 和 B/A Client 非常简单。图 4 展示了 “smitty installp” 的屏幕快照:

图 4. 通过 AIX 命令提示符运行的 “smitty installp”
smitty installp
smitty installp

切记将 “ACCEPT new license agreements?” 设置为 “yes”。安装好 TSM Server 和 B/A Client 5.3 后,在 AIX 命令提示符中键入 lppchk -v,确保安装没有任何损坏的文件集。TSM 安装目录如下:

  • TSM 服务器文件安装在 /usr/tivoli/tsm/server/bin 目录下
  • TSM B/A 客户机文件安装在 /usr/tivoli/tsm/client/ba/bin 目录下
  • TSM API 客户机文件安装在 /usr/tivoli/tsm/client/api/bin 目录下

由于我们需要使用磁带,所以在配置 TSM 之前首先介绍一下磁带的配置。

磁带配置

我们将以附加的 4MM 磁带驱动器作为第 3 层存储,因此需要在操作系统级别配置此驱动器。

  • 首次检查 AIX 能否识别 4mm 磁带驱动器时,键入 lsdev -Cc tape 并确保 4mm 磁带驱动器为 “Available”。注意 SCSI 地址(1n-08-01-0,0)。

    图 5. 在 AIX 命令提示符中键入 “lsdev -Cc tape”
    在 AIX 命令提示符中键入 “lsdev -Cc tape”
    在 AIX 命令提示符中键入 “lsdev -Cc tape”
  • 接下来,键入 smitty devices 并选择 Tivoli Storage Manager Devices

    图 6. 在 AIX 命令行中键入 “smitty devices”
    在 AIX 命令行中键入 “smitty devices”
    在 AIX 命令行中键入 “smitty devices”
  • 在 “Tivoli Storage Manager Devices” 终端选择 SCSI Attached DevicesTape Drive,然后再选择 Add a Tape Drive。选择 ADSM-SCSI-MT scsi Tivoli Storage Manager Tape Drive 和之前 lsdev -Cc tape 命令输出中提示的相应的 SCSI 地址。

    图 7. 选择 SCSI 磁带
    选择 SCSI 磁带
    选择 SCSI 磁带
  • 图 8 所示的屏幕操作,并按 Enter 键提交。

    图 8. 通过 AIX 命令提示符运行的 “Add a Tape Drive”
    通过 AIX 命令提示符运行的 “Add a Tape Drive”
    通过 AIX 命令提示符运行的 “Add a Tape Drive”
  • 配置结束时,应看到 “OK” 状态,如 图 9 所示:

    图 9. 配置好的 Tivoli Storage Manager 设备
    配置好的 Tivoli Storage Manager 设备
    配置好的 Tivoli Storage Manager 设备

Tivoli Storage Manager 配置

将以下 TSM 环境添加到 /etc/environment 目录下:

  • TSM Server 环境:

    清单 1. TSM Server 环境
          DSMSERV_CONFIG=/usr/tivoli/tsm/server/bin/dsmserv.opt
          DSMSERV_DIR=/usr/tivoli/tsm/server/bin
          DSMSERV_LOG=/usr/tivoli/tsm/server/bin/dsmserverror.log
  • TSM B/A Client 环境:

    清单 2. TSM B/A Client 环境
          DSM_CONFIG=/usr/tivoli/tsm/client/ba/bin/dsm.opt
          DSM_DIR=/usr/tivoli/tsm/client/ba/bin/
          DSM_LOG=/usr/tivoli/tsm/client/ba/bin/dsmbaerror.log
  • TSM API Client 环境:

    清单 3. TSM API Client 环境
          DSMI_CONFIG=/usr/tivoli/tsm/client/api/bin/dsm.opt
          DSMI_DIR=/usr/tivoli/tsm/client/api/bin
          DSMI_LOG=/usr/tivoli/tsm/client/api/bin/dsmapierror.log

应可在 dsm.sys 和 dsm.opt 中找到以下记录项:

  • dsm.sys —— dsm.sys 位于 /usr/tivoli/tsm/client/ba/bin 和 /usr/tivoli/tsm/client/api/bi 目录中

    清单 4. dsm.sys 内容
            SErvername         tech
            COMMMethod         TCPip
            TCPPort            1500
            TCPServeraddress   9.187.116.208
            nodename           techcm
            passwordaccess     generate
  • dsm.opt —— dsm.opt 位于 /usr/tivoli/tsm/client/ba/bin 和 /usr/tivoli/tsm/client/api/bin 目录中

    清单 5. dsm.opt 内容
            SErvername      tech

下面介绍本文中所用的 TSM 存储池和策略在 TSM 命令提示符中的配置方法。

现在让我们来依次执行这些活动:

  1. 为 4MM 磁带驱动器定义 TSM 库、设备类、驱动器、路径、存储池和卷
  2. 为内部磁盘定义 TSM 存储池和卷
  3. 为外部磁盘定义 TSM 设备类、存储池和卷
  4. 为资源管理器定义 TSM 节点
  5. 定义 TSM 策略
  1. 为 4MM 磁带驱动器定义 TSM 库、设备类、驱动器、路径、存储池和卷:
    • 4MM 库 —— 在手动磁带库中定义 4MM 磁带驱动器:

      清单 6. 为 4MM 手动磁带驱动器定义 TSM 库
      TSM> define library 4MMLIBRARY libtype=manual
    • 4MM 设备类 —— 4MM 磁带驱动器(手动驱动)的设备类将定义为 4MMDEVCLASS:

      清单 7. 定义 TSM 设备类
      TSM> define devclass 4MMDEVCLASS libr=4mmlibrary devtype=4MM format=DDS4
    • 4MM 磁带路径 —— 4MM 磁带驱动器的磁带路径指向 /dev/mt0(参见 图 9 —— 配置好的 Tivoli Storage Manager 设备):

      清单 8. 为 4MM 磁带驱动器定义 TSM 路径
      TSM> define path TSM 4MMDRIVE srctype=server desttype=drive 
      	          library=4MMLIBRARY device=/dev/mt0
    • 4MM 存储池:

      清单 9. 为 4MM 磁带定义 TSM 存储池
      TSM> define stgpool 4MMPOOL 4MMDEVCLASS maxscratch=5
  2. 为内部磁盘(rootvg —— hdisk0 和 hdisk1)定义 TSM 存储池和卷以进行备份:
    • 内部磁盘存储池将使用预定义的 DISK devclass:

      清单 10. 为内部磁盘定义 TSM 存储池
      TSM> define stgpool CMDiskTier1A disk pooltype=primary 
                    description='CM Disk Storage Pool for backup' 
                    access=readwrite maxsize=nolimit
                   TSM> define stgpool CMDiskTier1B disk pooltype=primary 
                    description='CM Disk Storage Pool for backup' 
                    access=readwrite maxsize=nolimit
    • 内部磁盘卷 —— 在各 /tsmtier1a 和 /tsmtier1b 文件系统中创建 TSM 卷。进入各文件系统(例如,/tsmtier1a)并发出以下命令:

      清单 11. 定义 TSM 卷
      AIX# dsmfmt -m -data tier1a1.dsm 200 tier1a2.dsm 200 tier1a3.dsm 200 
      	     tier1a4.dsm 200 tier1a5.dsm 200
    • 格式化各卷后,进入 TSM 命令提示符,为各存储池定义卷:

      清单 12. 为 TSM DISK 存储池定义 TSM 卷
      TSM> define vol CMDISKTIER1A /tsmtier1a/tier1ax.dsm
                   TSM> define vol CMDISKTIER1B /tsmtier1b/tier1bx.dsm
  3. 为外部磁盘(techvg —— hdisk2 和 hdisk3)定义 TSM 存储池和卷以进行归档:
    • 外部磁盘设备类 —— 使用名为 FILECLASS1 和 FILECLASS2 的设备类定义外部磁盘:

      清单 13. 定义 TSM 设备类
      TSM> define devclass FILECLASS1 devtype=file mountlimit=20 
                         directory=/tsmtier2a
      
                    TSM> define devclass FILECLASS2 devtype=file mountlimit=20
                         directory=/tsmtier2b
    • 外部磁盘存储池:

      清单 14. 为外部磁盘定义 TSM 存储池
      TSM> define stgpool CMDiskTier2A FILECLASS1 pooltype=primary 
                        description='CM Disk Storage Pool for archive' 
                        access=readwrite maxscratch=5
      
                   TSM> define stgpool CMDiskTier2B FILECLASS2 pooltype=primary 
                        description='CM Disk Storage Pool for archive' 
                        access=readwrite maxscratch=5
    • 卷 —— 在各 /tsmtier2a 和 /tsmtier2b 文件系统中创建 TSM 卷。进入各文件系统(例如,/tsmtier2a),并发出以下命令:

      清单 15. 格式化 TSM 卷
      AIX# dsmfmt -m -data tier2a1.dsm 200 tier2a2.dsm 200 tier2a3.dsm 200 
      	          tier2a4.dsm 200 tier2a5.dsm 200
    • 格式化各卷后,进入 TSM 命令提示符,为各存储池定义卷:

      清单 16. 定义 TSM 卷
      TSM> define vol CMDISKTIER2A /tsmtier2a/tier2ax.dsm 
                   TSM> define vol CMDISKTIER2B /tsmtier2b/tier2bx.dsm
  4. 为资源管理器定义 TSM 节点:

    清单 17. 为资源管理器定义 TSM 节点
    TSM> register node techcm password
  5. 定义 TSM 策略:
    • 策略域:

      清单 18. 定义策略域
      TSM> define domain CMDomain Description='Content Manager Domain' 
                   backretention=60 archretention=365
    • 策略集:

      清单 19. 定义策略集
      TSM> define domain CMDomain Description='Content Manager Domain' 
                   backretention=60 archretention=365
    • 管理类:

      清单 20. 定义管理类
      TSM> define mgmtclass CMDomain CMPolicy CMClass  
                   description='Content Manager TSM Management Class'
             TSM> assign defmgmtclass CMDomain CMPolicy CMClass
    • 验证并激活策略集:

      清单 21. 验证并激活策略集
      TSM> validate policyset CMDomain CMPolicy
             TSM> activate policyset CMDomain CMPolicy

配置资源管理器属性文件 —— ICMRM.properties

集成的最后一步是编辑 ICMRM.properties 文件,此文件的路径为 /usr/WebSphere/AppServer/installedApps/<your_hostname>/icmrm.ear/icmrm.war/WEB-INF/classes/com/ibm/mm/icmrm/。修改以下参数,如下所示:

清单 22. 修改 ICMRM.properties
       DSMI_LOG=/usr/tivoli/tsm/client/api/bin/dsmapierror.log
       DSMI_DIR=/usr/tivoli/tsm/client/api/bin
       DSMI_CONFIG=/usr/tivoli/tsm/client/api/bin/dsm.opt

如果遇到集成方面的问题,请参阅 TSM 和 DB2 Content Manager 的 故障排除技巧

对象移植

简介 —— System Manage Storage 简明教程

下面列出 System Manage Storage 相关图标的定义 —— 它们是什么,其用法如何:

  • 设备管理器(Device manager):

    设备管理器是 DB2 Content Manager Resource Manager 与底层存储系统(如文件系统、媒体归档、TSM 等)之间的接口。设备管理器的选择取决于资源管理器所在的操作系统或与资源管理器相集成的产品。请注意,终端用户无权控制新设备管理器的添加(也很少需要这样做),通常在默认情况下都是禁用的。设备管理器对于所安装的本地资源管理器是惟一的。下表按字母顺序列出了 DB2 Content Manager 提供的开箱即用的设备管理器:

    表 1. 预定义的设备管理器
    设备管理器产品名称操作系统启用与否
    ICMADDMTivoli Storage Manager(TSM)
    ICMCIFS
    Network Attached Storage for Windows
    ICMHDDM
    Filesystem for Windows
    ICMMADMMedia Archiver*
    ICMNFS
    Network Attached Storage for Unix
    ICMVCDMDB2 Video Charger
    ICMFILEPATH
    Catalog 文件系统
    ICMREMOTE
    远程服务器
    GPFS
    AIX 5 GPFS 卷
    JFS
    AIX 和 Solaris JFS 卷
    OAM
    仅 z/OS。可选择使用 TSM。


    * 使用 TSM 的 DB2 Video Charger 资产归档。DB2 Video Charger 不会自动归档不常用的资产。
  • 存储类(Storage Class):

    存储类指定一个对象将存储为的媒体类型。这些媒体包括 DASD、Optical、Stream、Tape 和 Tivoli Storage Manager(TSM)。 存储类与设备管理器直接相关。在创建新存储类时,可指定本地和远程目标。对于本地目标,需要选定一个设备管理器(仅一个)。但对于远程目标,仅可指定资源管理器和工作站集合。不可为远程目标指定设备管理器,因为各设备管理器与本地资源管理器紧密相连。既然存储类确定对象将存储为的媒体类型,因此常常会看到 FIXED(以 DASD 存储)、TABLE(存储为 RDBMS 中的 BLOB)和 TSM(Tivoli Storage Manager)、VC(Video Charger)等等。请注意,存储类指定的是媒体类型,而非对象将存储到的实际位置。
  • 存储系统(Storage System):

    存储系统(或卷)是对象存储的实际位置。所提供的预定义存储系统如下所示:
    • BLOB —— 资源管理器作为 BLOB 提供
    • File System(文件系统) —— 硬盘的物理或逻辑分区
    • Media Archive(媒体归档) —— 与 Video Charger 相集成
    • Tivoli Storage Manager —— 与 TSM 相集成
    • Video Charger —— 与 Video Charger 相集成
    可将存储系统指派给一个以上的存储组。可将一个卷标记为溢出卷。在主卷被填满之后,该溢出卷可用于接收溢出内容。若将文件系统和 TSM 卷均指派为溢出卷,则文件系统卷的优先级将高于 TSM。换言之,必须首先填满文件系统溢出卷,之后才能使用 TSM 卷。
  • 存储组(Storage Group):

    存储组将一个存储系统关联到存储类。它可有一个或多个存储系统及存储类。
  • 移植策略(Migration Policy):

    移植策略是将对象从创建位置移动到长期存储位置的方式。它是一组移植集合中的对象的规则。移植策略要求预定义存储类。由于存储系统和存储类之间存在关联,因此对象将根据移植策略中设置的规则移动到指定存储系统中。
  • 工作站集合(Workstation collection):

    工作站集合是同一移植策略和存储组内相关对象的逻辑分组。设置工作站的两项标准是移植策略和存储组。默认有三个集合,如下表所示:

    表 2. 预定义的集合
    集合名称详细说明
    CBR.CLLCT001文件系统集合
    TBL.CLLCT001资源管理器 BLOB

它们之间的关系如下:

  • 一个设备管理器可指派给多个存储类。
  • 一个存储类仅能有一个设备管理器,可指派给一个存储系统。
  • 存储系统(卷)可指派给一个以上的存储组。存储组包含多个存储系统和存储类。
  • 多个存储类可指派给一个移植策略。
  • 一个工作站集合拥有一个移植策略和一个存储组。

建议为各存储组指派一个不同的存储系统,为各集合指派一个不同的存储组。

实现 6-3-7

由于 DB2 Content Manager 支持层次化存储管理,因此本练习将展示如何利用最初存储在 DASD 中、随后移动到外部存储、最终移动到磁带上的对象来实现这种机制。典型情况下,用户最初会将对象存储在 DASD 中。而仅仅几个月或几年之后(取决于增长速率),他们就会开始规划移植到外部磁盘,而磁带通常要在几年以后才会参与进来。让我们来模拟一下这个场景,假设对象在 DASD 中存储 6 个月,在外部存储中存储 3 年,在磁带中存储 7 年。这种设定背后隐藏的基本原理就是 DASD 速度快、成本高。任何存在时间超过 6 个月的对象的必要性都会减低,并且很少被查询到。此数据将移动到外部磁盘以释放 DASD,同时,外部磁盘的性能不应对终端用户体验到的响应时间造成负面影响。最终,在磁带上保存数据 7 年的主要目的是为了满足法规遵从性。

图 10. 对象移植场景 —— 对象流
对象移植场景 —— 对象流
对象移植场景 —— 对象流

资源管理器配置

假设管理层决定将存在时间超过 6 个月的数据移动到外部磁盘上,并将存在时间超过 7 年的数据移动到磁带上。使用 System Admin Client —— System Manage Storage(SMS)配置移动到下一配置级别。这一配置需要在 DB2 Content Manager System Admin Client(GUI)中完成,那里不存在要发出的命令,也不存在可通过编程方式完成这一任务的方法(至少在 C++ 中是这样的)。

按以下步骤配置资源管理器,以使用 TSM:

  • 在配置 SMS 之前,最好备份资源管理器数据库。运行 /etc/rc.cmrmproc -act stop 命令关闭所有资源管理器服务,并使用 db2 backup db RMDB to /tmp 命令备份资源管理器数据库。
  • 添加新 TSM 服务器定义:
    • 从 System Manage Storage(SMS)右击 Server Definitions,以创建新服务器。

      图 11. 服务器定义
      服务器定义
    • 填充信息,如 图 12 所示。可在 Tivoli Storage Manager(TSM)命令提示符中运行 q stat 命令查找您的 TSM 服务器名称。可以使用主机名取代 IP 地址,并将 SchemaPath 保留为空。Port 可为任意内容,无关紧要。

      图 12. 服务器定义信息
      服务器定义信息
  • 启用 TSM 设备管理器:Tivoli Storage Manager 的设备管理器为 ICMADDM。默认情况下,此设备管理器已创建好,需要做的只是启用它。注意,要配置 EMC Centera 依从模式,您必须使用参数 mode=retention

    图 13. 启用 TSM 设备管理器
    启用 TSM 设备管理器
    启用 TSM 设备管理器


    输入 TSM 作为存储类(接下来将介绍其定义方法)。建议为对象移植这一目的使用 Tivoli Storage Manager(TSM)归档副本。为列出归档和备份副本,可在 TSM 管理控制台中运行 q mgmt 命令。
  • 定义 TSM 存储类:

    图 14. 定义 TSM 存储类
    定义 TSM 存储类
  • 定义 TSM 存储系统:务必输入正确的 TSM Management 类名。若匹配失败,将看到错误消息,如 “ICM9950: Undefined Tivoli Storage Manager management class”。

    图 15. 定义存储卷
    定义存储卷
    定义存储卷
  • 定义一个新的存储组。建议让 TM Storage System 自成一个存储组。总是建议将存储系统放在它自己的存储组中。

    图 16. 定义存储组
    定义存储组
    定义存储组
  • 设置移植策略:

    图 17. 定义移植策略
    定义移植策略
    定义移植策略
  • 您可能会注意到,之前的所有定义都包含在创建工作站集合的过程之中。由于移植策略和组是工作站集合必需的字段,因此移植策略本身是存储类,而存储组包含存储系统。

    图 18. 工作站集合
    定义工作站集合
    定义工作站集合

测试场景

设置 System Manage Storage(SMS)之后,通过以下步骤进行测试,以确保一切与预期相符:

  1. 创建项类型 ABC,确保集合更改为 MY_COLL

    图 19. 定义一个项类型
    定义一个项类型
    定义一个项类型
  2. 导入一些文档。
  3. 将 AIX 系统日期更改为 180 日之前,以模拟 6 个月的期间。
  4. 启动移植器。注意,移植器是高性能、多线程的进程,可将其规划为在指定时间启动。运行命令 /etc/rc.cmrmproc -act start -db rmdb -app icmrm。 。
  5. 通过在 RMOBJECTS 表中运行 obj_actiondate 检查移植到外部磁盘的情况。
  6. 通过在 TSM 管理控制台中运行 q occupancy 检查移动的总量。(注意第 4 行。)

    图 20. 使用 “q occupancy” 检查对象移动情况
    使用 “q occupancy” 检查对象移动情况
    使用 “q occupancy” 检查对象移动情况
  7. 测试检索已移植的对象。注意,使用 /lbosdata/staging 来缓存从其他资源管理器和 Tivoli Storage Manager 中检索到的对象。您可能会注意到,这是空的,因为尚未检索任何已移植的对象。一旦检索到某些对象,staging 区域将被填充。注意,由 TSM 处理的对象获取对用户来说是透明的。换句话说,终端用户不会意识到文档究竟位于何处 —— DASD、外部磁盘或者是磁带。

使用 TSM,可通过几种方式执行文件移植。常见可选方式如下:

  1. 为特殊存储池(在本例中为 CMDISKTIER1A)设置高和低移植阈值,以触发从 CMDISKTIER1A 到 4MMPOOL 的移植。
  2. 安排一个 TSM 管理调度程序,触发 CMDISKTIER1A 中的所有数据到 4MMPOOL 的移植。

在移植一个存储池之前,必须将 NEXTSTGPOOL 参数设置为指向 4MMPOOL。可通过以下命令完成此任务:

清单 23. 将 CMDISKTIER1A 的 NEXTSTGPOOL 参数设置为 4MMPOOL
TSM> update stgpool CMDISKTIER1A nextstgpool=4MMPOOL

对于第一种可选方式:默认情况下,高低移植阈值分别设置为 90% 和 70%。这意味着每当 CMDISKTIER1A 占用空间达到 90% 时,就会开始移植,直至这个数字达到 70%。

要为 CMDISKTIER1A 设置不同的高低移植阈值,请按以下步骤进行操作;

清单 24. 更新 CMDISKTIER1A 的高低移植阈值
TSM> update stgpool CMDISKTIER1A hi=90 lo=50

对于第二种可选方式:在典型的 CM 和 TSM 实现中,移植通常规划为在一定天数后开始(本例中为三年)。因此,管理调度程序将保持非活动状态,直至指定时间。

必须确保第一层的磁盘空间足以按希望的时期容纳对象。

清单 25. 定义一个调度程序来启动和停止 CMDISKTIER1A 的移植
TSM> define schedule CMMIGRATESTART type=administrative cmd="update stgpool 
            CMDISKTIER1A hi=0 lo=0" active=no starttime=20:00

       TSM> define schedule CMMIGRATESTOP type=administrative cmd="update stgpool 
            CMDISKTIER1A hi=90 lo=70" active=no starttime=22:00

三年后,可为调度程序 CMMIGRATESTART 和 CMMIGRATESTOP 更新 “active=yes” 参数。

清单 26. 更新调度程序 CMMIGRATESTART 和 CMMIGRATESTOP
TSM> update schedule CMMIGRATESTART active=yes
   
       TSM> update schedule CMMIGRATESTOP active=yes

在移植之前,CMDISKTIER1A 的 “q vol” 可显示空间占用状态,如下所示:

图 21. CMDISKTIER1A 的 “q vol”
CMDISKTIER1A 的 “q vol”
CMDISKTIER1A 的 “q vol”

至于磁带,不会有针对 4MMPOOL 的条目,因为尚未使用它。在移植过程中,通过 “dsmadmc -console” 将看到如下消息:

图 22. dsmadmc -console 显示的对象移植消息
dsmadmc -console 显示的对象移植消息
dsmadmc -console 显示的对象移植消息

在 TSM 命令提示符中键入 q pro,还能看到以下过程:

图 23. “q pro” 移植信息
“q pro” 移植信息
“q pro” 移植信息

移植后,应能看到 CMDISKTIER1A 的 Pct Util 已变为 0.0,同时 4MMPOOL 有一定百分比的空间被占用:

图 24. CMDISKTIER1A 变为 0.0
CMDISKTIER1A 变为 0.0
CMDISKTIER1A 变为 0.0
图 25. 部分空间被占用的 4MMPOOL
部分空间被占用的 4MMPOO
部分空间被占用的 4MMPOO

其他考虑事项

在对象存储管理方面还有其他一些考虑事项,例如,在什么时候利用阈值移植、DASD 被占满时会发生什么情况、如何使用溢出特性。

阈值移植是以 SMS 中设置的阈值为基础的移植。传统的基于数据的移植关注日期对象,在移植发生前与系统日期相比较。 阈值是一项新特性,它使一个卷的移植以阈值(默认为 95%)为基础。下面简要列出了关于阈值移植的一些事实:

  • 阈值移植不以时间为基础。
  • 启动阈值移植服务的方式与启动基于日期的移植服务相同。
  • 这两种移植方法可并存。
  • 管理员使用 System Admin Client。
  • 被移植的对象将被物理删除,方式与删除基于日期的移植对象相同。

为应对溢出对象或主卷不可用的情况,在创建存储系统的过程中,可指定溢出对象前往哪个卷。在 AIX 中默认为 /vol2。

DB2 Content Manager 不会检查完整的 Tivoli Storage Manager 管理类。定义为指向 Tivoli Storage Manager 的 DB2 Content Manager 卷被视为容量无限大。换句话说,需要在 TSM 端予以恰当的管理性关注。

备份与还原

为确保尽可能少地丢失数据或完全不丢失数据(例如,在介质发生故障时),备份与还原相当重要。备份与还原总是在业务需求、预算配额、特殊战略的复杂性因素、备份与还原窗口等方面间的一种折衷。本文的讨论排除了 High Availability 配置、选项和设置。(更多信息请参阅 DB2 Content Manager High Availability in AIX。)

通常,在所有环境中,都必须考虑备份以下项目:

  • 系统备份(使用 OS 系统备份工具,例如 “mksysb”、TSM for Sysback for AIX,或者 Cristie BMR
  • 文件系统/文件备份
  • 数据库备份

本文中所讨论的备份与还原是使用 Tivoli Storage Manager(推荐方式)为独立 DB2 Content Manager 系统实现的冷备份(脱机)和热备份(联机)。分布式 Content Manager 系统备份策略和考虑事项非常复杂,超出了本文的讨论范围。

由于这里介绍的冷备份和热备份均利用 Tivoli Storage Manager(TSM)作为备份工具,因而需要在使用 TSM 之前首先设置它。使用 TSM 进行备份与还原有多方面的优势,例如:

  • 与 DB2 UDB 紧密集成 —— TSM 一直以来与 DB2 UDB 集成良好
  • 简单性 —— 在备份命令中使用简单的 use TSM 即可使 TSM 管理备份
  • 自动化 —— 日常备份可实现自动化
  • 逻辑备份管理 —— 为各备份创建时间戳,这样即可操纵要还原的映像
  • 使用 db2adutl 获得灵活的备份与还原管理
  • TSM 支持广泛的 硬件
  • 压缩支持
  • 层次化存储支持

系统备份

系统备份是备份中的一个重要部分,但往往被忽略。Kernel(对于 Unix)和 System Object(对于 Windows)被视为系统的 “大脑”,没有它们,服务器将无法运行。系统 —— 或有时称为 OS —— 备份主要创建一个可引导的操作系统结构备份,这是重新构建操作系统所必需的。通常系统备份是在系统发生变化时执行的(例如安装新应用程序或补丁)。这是为了在不安装所有必要应用程序的情况下实现操作系统还原。

让我们看看使用名为 “mksysb”(Make System Backup)的 AIX 工具进行的系统备份。在 AIX 命令提示符中键入 smitty mksysb

图 26. 在 AIX 命令提示符中运行 “lsdev -Cc tape”
在 AIX 命令提示符中运行 “lsdev -Cc tape”
在 AIX 命令提示符中运行 “lsdev -Cc tape”

备份结束后,应相应地标记 rmt4 磁带,这是一个好习惯。

文件系统/文件备份

文件系统备份可临时执行,也可使用基于 TSM 日程表的调度程序安排。文件系统通常为递增备份,这是为了最小化备份窗口和优化存储空间。TSM 的优势就是累积式备份方法,仅备份新文件或有变化的文件。这些文件作为完整的文件备份,并由健壮的 TSM 数据库跟踪。这使每一次递增备份都是 TSM 中的完整备份。

例如,为备份 /lbosdata 和 /home/db2inst1/sqllib/db2ext,可定义 TSM 调度程序,以累积式地进行备份。运行以下命令:

清单 27. 在 TSM 中定义文件系统备份调度程序
TSM> define schedule CMDOMAIN CMFILES type=client description='Scheduled backup for 
            CM files' 
            action=incremental options=-subdir=yes objects='"/lbosdata/*" 
	    "/home/db2inst1/sqllib/*"' starttime=23:00

定义好调度程序后,必须将调度程序关联到节点名称,这样才能进行处理。为此,只需在 TSM 命令提示符中键入以下命令:

清单 28. 将调度程序 CMFILES 关联到节点名称 techcm
TSM> define association CMDOMAIN CMFILES techcm

为检查定义好的关联,执行 q association,此命令应展示以下结果:

图 27. “q association”
“q association”
“q association”

定义好调度程序和关联后,启动客户机调度程序以运行。在 AIX 上,在 AIX 命令提示符中运行 nohup 命令以便在后台启动守护进程:

清单 29. 通过 AIX 启动客户机调度程序
AIX# nohup /usr/tivoli/tsm/client/ba/bin/dsmc sched &

也可选择手动备份,运行以下命令:

清单 30. 手动备份文件
AIX# dsmc backup /lbosdata/* -subdir=yes

为将一个文件备份还原到其原始位置,只需在根处键入以下命令即可:

清单 31. 将一个文件备份还原到原始位置
AIX# dsmc restore /home/db2inst1/sqllib -subdir=yes

要还原到其他位置,在根处键入以下命令:

清单 32. 将一个文件备份还原到其他位置
AIX# dsmc restore /home/db2inst1/sqllib <new directory> -subdir=yes

使用 TSM 设置数据库备份

必须先进行一些简单的设置,之后才能使用 Tivoli Storage Manager(TSM)备份 DB2 UDB 数据库。按以下步骤设置 DB2 UDB,以使用 TSM。

  1. 登录到 db2inst1 用户,并在用户配置文件中为 TSM 添加三个环境变量:DSMI_DIR、DSMI_CONFIG、DSMI_LOG。关于其实际值,请参见上文中介绍的 ICMRM.properties 修改清单。
  2. 更改 DB2 TSM 参数:运行命令 db2 update db cfg for awt using TSM_MGMTCLASS CMCLASS。(注意,之前已定义了 CMCLASS。)在 TSM API 选项文件中使用 passwordaccess=generate 时,确保 DB2 参数 TSM_NODENAME、TSM_OWNER 和 TSM_PASSWORD 为 NULL,否则将收到 rc “2032”。为使这些参数为 NULL,运行命令 db2 update db cfg for awt using TSM_NODENAME NULL
  3. 作为根用户登录,运行命令 dsmapipw located in /sqllib/adsm。
  4. 键入旧口令和新口令(两次)。这一步是为文件系统上的此节点存储加密的 TSM 口令。
  5. 重启 DB2 UDB 实例,以反映所有更改(仅第一次)。
  6. 测试冷备份。备份测试数据库 AWT(使用一个示例数据库来测试)。运行命令 db2 backup db awt use TSM。应看到与下图类似的成功备份:

    图 28. 使用 TSM 的脱机备份
    使用 TSM 的脱机备份
    使用 TSM 的脱机备份
  7. 同样,登录到 TSM dsmadmc,并运行命令 q occupancy techcm 来显示所占用的磁盘空间。

    图 29. TSM 空间占用检查
    TSM 空间占用检查
    TSM 空间占用检查

注意,若 TSM Server 位于另外一台计算机上,需要使用注册节点的命令来注册节点。

为测试还原,首先授权此节点可访问映像。请参考 DB2 UDB 8 new behavior with TSM

  • 授予访问映像的权限。在授予访问映像的权限之前,运行命令 db2adutl queryacccess for all 返回一个空列表。现在运行命令 db2adutl grant user db2inst1 on nodename techcm for db awt。重新运行 db2adutl queryacccess for all 返回一个条目。

    图 30. 使用 db2adutl 查询访问控制
    使用 db2adutl 查询访问控制
    使用 db2adutl 查询访问控制
  • 测试还原。为还原之前备份的映像,运行命令 db2 restore db awt use tsm options "'-fromnode=techcm -fromowner=db2inst1'" taken at 200603271942。(注意,内有单引号,可选择映像内可用的任意时间戳。)

    图 31. 使用 TSM 还原
    使用 TSM 还原
    使用 TSM 还原


    应可看到数据库成功还原。检查表值,一切应正确无误。

成功执行上述步骤后,接下来就可为 DB2 Content Manager 执行冷备份和热备份了。

冷备份(脱机)

这种备份方式的含义就是,仅能还原最后一次完整的脱机备份。例如,若在每天午夜进行脱机备份,而系统在星期四上午 11 点发生故障,则仅可还原前夜(星期三午夜)所备份的映像 —— 惟一的版本还原,可还原最后一个完整、完好的映像。换句话说,在星期四上午 11 点之前所做的所有工作都会丢失。这种备份的优势在于,它非常简单,易于执行。只需要终止所有连接/应用程序,因为在备份过程中不允许有任何活动。

要为 DB2 Content Manager 执行此类备份,按以下步骤进行操作:

  1. 断开外部连接。需要终止来自默认客户机的连接,如 eClient 和 Windows thick 客户机、DB2 Document Manager 或任何需要终止的自定义客户机。为停止 eClient,运行命令 /usr/WebSphere/AppServer/bin/stopServer.sh eClient_Server
  2. 关闭文本搜索组件(若存在)
    • 网络搜索扩展器 —— 运行命令 db2text stop
  3. 关闭 DB2 Content Manager 组件
    • 资源管理器应用服务器 —— 运行命令 /usr/WebSphere/AppServer/bin/stopServer.sh icmrm
    • 资源管理器服务 —— 资源管理器服务包括 purger、migrator、replicator 和 stager。为关闭这些服务,运行命令 /etc/rc.cmrmproc -act stop。对停止和启动资源管理器服务有更好的控制。这种更好的 管理控制 在有多个资源管理器位于同一台计算机中时非常有用 —— 可以启动/停止特定资源管理器服务。例如,停止资源管理器 3 的 Migrator 服务。
    • Library Server 监控 —— 运行命令 /etc/rc.cmlsproc -shutdown,关闭 Library Server 监控流程。
    • 强制应用程序脱机 —— 运行命令 db2 force application all

      图 32. 列出所有应用程序
      列出所有应用程序
      列出所有应用程序
  4. 更新 DB2 Content Manager 数据库 db config —— 运行命令 db2 update db cfg for icmnlsdb using TSM_MGMTCLASS DISKdb2 update db cfg for rmdb using TSM_MGMTCLASS DISK(icmnlsdb 和 rmdb 分别是默认库服务器和资源管理器数据库的名称)。这一步骤只需完成一次即可。
  5. 备份 DB2 Content Manager 数据库 —— 运行如下两条命令备份 icmnlsdb 和 rmdb 数据库。
    • 备份库服务器数据库 —— 运行命令 db2 backup db icmnlsdb use tsm
    • 备份资源管理器数据库 —— 运行命令 db2 backup db rmdb use tsm
    图 33. 脱机备份 DB2 Content Manager 数据库
    脱机备份 DB2 Content Manager 数据库
    脱机备份 DB2 Content Manager 数据库


    例如,要查询所创建的 icmnlsdb 映像,运行命令 db2adutl query database icmnlsdb

数据库备份完成后,某些重要的文件系统和配置也同样需要备份。需要备份的最重要的文件系统就是 /lbosdata 和 Net Search Extender 索引(若存在)。下面列出了需要备份的文件系统:

  • /lbosdata
  • /home/db2inst1/sqllib/db2ext

关于 lbosdata 和文本索引的备份,请参考文件系统/文件备份部分的命令。

对于配置文件,某些配置文件可能需要定期备份或仅在其发生变化时备份。例如,cmadmin.properties 和 cmadmincfg.properties 位于 $IBMCMROOT/admin/common 目录下,它们很少会被更改,因而不需要定期备份

  • 资源管理器配置 —— 资源管理器服务日志记录文件(xml)和 ICMRM.properties 文件最好通过备份文件系统 /usr/WebSphere/AppServer/installedApps/<your_hostname>/icmrm.ear/icmrm.war/ 备份。
  • eClient 配置文件 —— IDM.properties 和 IDMadminDefaults.properties 的目录为 $IBMCMROOT/CMeClient
  • 公共配置文件 —— cmbcmenv.properties 等文件的目录为 $IBMCMROOT/cmgmt

根据具体环境的不同,可能需要定期备份 INI 文件 ,其路径在 cmbcmenv.properties 中指出(默认为 /home/ibmcmadm/cmgmt/connectors)。

完成上述所有操作后,TSM q occupancy 输出如下:

图 34. “q occupancy”
“q occupancy”
“q occupancy”

为备份文件系统和配置文件,请参考文件系统/文件备份部分中的命令。

考虑利用命令将 /lbosdata 和文本索引中的 DB2 Content Manager 数据库和对象备份到同一脚本。将配置文件备份到同一脚本很大程度上取决于其修改频率。

在数据库还原期间,例如,要还原资源管理器数据库,使用命令 db2 restore db rmdb use tsm options "'-fromnode=techcm -fromowner=db2inst1'" taken at 200604072024(外双引号)。要查询拥有的可用映像,只需为资源管理器运行命令 db2adutl query db rmdb,并为库服务器运行命令 db2adutl query db imcnlsdb 即可。但应确保还原映像在这两者之间是同步的。通常,在任何类型的还原期间,都应选择最新的时间戳加以还原,因为其中包含最新的可用数据。

对于 /lbosdata 和 DB2 NSE 文本索引中的对象,要通过 Tivoli Storage Manager 还原它们,输入以下命令(前面的清单列表已展示过相同的命令):

清单 33. 将 /lbosdata(文件备份)中的对象还原到其原始位置
AIX# dsmc restore /lbosdata/* -subdir=yes

要还原到其他位置,从根处键入以下命令(需要一个到此新目录的软链接):

清单 34. 将 /lbosdata(文件备份)中的对象还原到其他位置
AIX# dsmc restore /lbosdata/* <new directory> -subdir=yes

最后,若需要还原到最新的配置文件(确定对其作出的更改时),输入以下命令:

清单 35. 将文件备份还原到其原始位置
AIX# dsmc restore <backed up file directory> -subdir=yes

为还原到其他位置,从根处键入以下命令:

清单 36. 将文件备份还原到其他位置
AIX# dsmc restore <backed up file directory> <new directory> -subdir=yes

热备份

为 DB2 Content Manager 实现热备份将带来业务连续性,若处理得当,还将最小化数据损失,甚至完全不会有损失。热备份的主要好处是能够及时还原到系统发生故障的时间点。在此基础上,使用热备份,可执行递增和累积备份。使用 Tivoli Storage Manager 执行 DB2 Content Manager 热备份是一种自然而然的选择。让我们来看一下具体方法。

我们首先完整地讨论一个热备份,及其还原选项,随后再介绍递增和累积备份的执行方法。参考以下步骤为 DB2 Content Manager 设置热备份:

  1. 打开 LOGRETAIN。在使数据库进入备份模式之前,需要使用归档日志。为转换到归档日志模式,只需运行命令 db2 update db cfg for icmnlsdb using logretain on 即可。
  2. 断开所有应用程序,运行命令 db2 force application all 来关闭所有连接。
  3. 完成一次原始脱机备份。打开 logretain 后,需要进行一次全面脱机,否则将接收到 “Backup Pending” 错误。运行命令 db2 backup db icmnlsdb use tsm
  4. 随后每周(取决于您的策略)进行一次联机备份,包括日志在内。运行命令 db2 backup db icmnlsdb online use tsm include logs

通过上述步骤,如果已正确地使用 TSM 备份了 DB2 UDB 数据,则可看到在 DB2 UDB V8.2 中不必再为日志文件配置用户出口。不得不分别发送日志文件并试图断定应使用哪个日志文件的日子已一去不复返。需要做的只是在备份命令中加上短语 include logsinclude logs 仅包含运行联机备份命令时的日志。因此,在此命令发出后出现的那些要求日志完好(没有 “间隙或漏洞”)的事务可确保顺利前滚,而不会有任何数据损失。只要涉及到资源管理器和库服务器数据库,一旦有了一次原始备份,并且所有日志均完好无损,即可保证不损失任何数据。

在什么时候在联机备份命令中使用 include logs?最适当的一种情况就是日志记录发送到另一 DR 站点时。有了这个 新特性(自 DB2 UDB V8.2 起)日志发送和管理变得更轻松。但请注意,在还原时应满足以下标准:

  • 备份映像必须包含日志
  • 在 LOGTARGET 中指定的路径应有足够的权限
  • LOGTARGET 路径中不存在相同的日志文件名

注意:若未能满足上述任一标准,将导致还原失败。

由于 DB2 Content Manager 至少包含两个数据库,因此需要以上述方式热备份所有数据库。在练习中,由于我们只有一个资源管理器,因而将 icmnlsdb 替换为 rmdb,为资源管理器执行联机备份。另外一个好习惯就是使用 MIRRORLOGPATH 来避免日志单点故障。

在还原过程中,仅需完成以下几个步骤:

  1. 确定要使用的恰当映像。运行命令 db2adutl query db icmnlsdb。注意此映像的时间戳。
  2. 还原映像。运行命令 db2 restore db icmnlsdb use tsm options "'-fromnode=techcm -fromowner=db2inst1'" taken at 20060410215555 without prompting(外双引号)。
  3. 前滚。运行命令 db2 rollfoward db icmnlsdb to end of logs and complete

同样,例如,为将日志发送到一个 DR 站点,使用带有 include logs 选项的联机备份,还原它需要指定 LOGTARGET。还原步骤如下:

  1. 还原数据库。运行命令 db2 restore db icmnlsdb use tsm options "'fromnode=techcm -fromowner=db2inst1'" taken at 20060410231853 logtarget /home/db2inst1/db2inst1/NODE0000/SQL00003/SQLOGDIR without prompting,例如,要查找日志文件的 icmnlsdb 路径,使用 db2 get db cfg for icmnlsdb 并在 “path to log files” 下查看。
  2. 前滚。运行命令 db2 rollfoward db icmnlsdb to end of logs and complete

为使仅以更改为依据的备份更轻松,DB2 UDB 在完整联机备份(级别 0)的基础上又提供了递增式(级别 1)和 delta 备份(级别 2)。

递增式备份是对最近一次成功的完整备份之后作出的所有更改进行备份。这种备份形式也称为累积备份。每一个连续的递增映像都包含前一递增映像的完整内容以及前一次完整备份后的更改。在发生故障时,例如,在递增式备份完成后的星期六,可还原第一个星期日的完整备份,然后应用星期六的递增备份即可。参见 图 35

图 35. 递增式备份
递增式备份
递增式备份

delta 备份是对上一次成功、完整的递增或 delta 备份之后发生的变化的备份。如果星期六发生故障,可还原第一个星期日的完整备份,并应用星期六的 delta 备份。参见 图 36

图 36. delta 备份
delta 备份
delta 备份

为执行递增或 delta 备份,打开数据库配置参数 TRACKMOD。假设在星期日有每周一次的级别 0 备份,星期三和星期六有级别 1 备份,其余各日则有一次级别 2 的备份。一系列的设置步骤应与以下步骤类似:

  1. 打开 TRACKMOD。运行命令 db2 update db cfg for icmnlsdb using trackmod on
  2. 星期日,运行命令 db2 backup db icmnlsdb online use tsm
  3. 星期一,运行命令 db2 backup db icmnlsdb online incremental delta use tsm
  4. 星期二,运行命令 db2 backup db icmnlsdb online incremental delta use tsm
  5. 星期三,运行命令db2 backup db icmnlsdb online incremental use tsm
  6. 星期四,运行命令 db2 backup db icmnlsdb online incremental delta use tsm
  7. 星期五,运行命令 db2 backup db icmnlsdb online incremental delta use tsm
  8. 星期六,运行命令 db2 backup db icmnlsdb online incremental use tsm

要从递增式备份中还原,只需完成以下两步:

  1. 还原递增式备份。例如,运行命令 db2 restore db icmnlsdb incremental automatic use tsm options "'fromnode=techcm -fromowner=db2inst1'" taken at 20060411003128
  2. 前滚以完成还原:db2 rollfoward db icmnlsdb to end of logs and complete

DB2 Content Manager 系统的文件系统级备份与脱机完整备份类似。请参考上述步骤。

此外,考虑在磁盘镜像下放置 /lbosdata,以避免损失对象。联机备份与脱机备份不同,它允许用户执行正常任务。但建议在每天的最空闲时段安排备份。因为存在用户执行的活动,因此保证所有日志完整无误的联机备份连同 /lbosdata 下所有对象的磁盘镜像并不能确保库服务器和资源管理器同步。还原后依然需要执行资源管理器异步工具,以确保库服务器和资源管理器确实同步。相同的技术也可应用于多个资源管理器的环境。

加密

Tivoli Storage Manager V5.3 及更新版本支持 128 位 AES(Advanced Encryption Standard)数据加密,这是使用 最强加密的加密类型选项实现的。加密密钥 include.encrypt 和 exclude.encrypt 选项可用于管理 Tivoli Storage Manager 操作的加密。

为请求加密类型信息,在 TSM 服务器命令提示符中输入 query status

图 37. “q status” 显示加密长度:AES
“q status” 显示加密长度:AES
“q status” 显示加密长度:AES

为进一步加强备份数据的安全性,IBM Tivoli Storage Manager 客户机实现了一个加密函数,允许在将数据发送到 Tivoli Storage Manager 服务器之前加密数据。这有助于在传输过程中保护备份数据,它意味着存储在 Tivoli Storage Manager 服务器上的数据已加密,因而不能被恶意管理员所读取。

include.encrypt 和 exclude.encrypt 选项用于选择要加密处理的文件。默认情况下,除非使用 nclude.encrypt 选项显式包含文件,否则文件不会被加密,这一选项是在客户机的 dsm.sys 文件中配置的。

TSM 客户机自动要求加密密钥。在 encryptkey 选项设置为 “save” 时,密钥将存储于注册表中。已备份对象的密钥不可更改。如果将密钥从注册表中删除,则仅可为之后将备份的对象选择新密钥。已存储在服务器上的对象使用旧口令加密,并只能使用该密钥还原。

为加密文件数据,必须选择一个加密密钥口令,Tivoli Storage Manager 使用它来生成加密密钥,以加密和解密文件数据。存储加密密钥口令以便此后使用。可使用 encryptkey 选项(encryptkey=prompt)指定是否将加密密钥口令保存在一个名为 TSM.PWD 的文件中。在以下几种情况下,还原加密的文件时,Tivoli Storage Manager 将提示您输入密钥口令以解密文件:

  • 若 encryptkey 选项被设置为 “prompt”
  • 若用户在上述情况下提供的密钥不匹配
  • 若 encryptkey 选项被设置为 “save”,且本地保存的密钥口令与加密文件不匹配

在 dsm.sys 文件中(/usr/tivoli/tsm/client/api/bin),指定以下内容:

清单 37. 向 /lbosdata 添加加密
     include.encrypt  /lbosdata/*
     encryptkey       save
     encryptiontype   AES128

注意, include.encrypt 选项是在备份归档客户机上启用加密的惟一途径。若未使用 include.encrypt 语句,则不会发生加密。

压缩

压缩通常用于优化存储空间,且可在以下任一位置处设置:

  • TSM 客户机
  • TSM 服务器
  • 磁带驱动器

但压缩也意味着检索或还原速度将变得更慢,因为需要首先解压缩数据。

为启用压缩处理,需要在 dsm.sys 中将 compression 选项设置为 “yes”。修改 dsm.sys 以包含如下内容:

清单 37. 向 dsm.sys 中添加压缩
     compression yes

注意,Tivoli Storage Manager 首先处理 exclude.fs、exclude.dir 和其他 include-exclude 语句。Tivoli Storage Manager 随后会考虑所有 include.compression 和 include.encrypt 语句。include-exclude 压缩和加密处理仅对备份和归档处理有效。

结束语

本文主要关注设置 Tivoli Storage Manager 以与 DB2 Content Manager 集成的实践方面 —— 首要目标是对象移植。文中利用 DB2 Content Manager 数据库的 Tivoli Storage Manager 探索了脱机与联机备份。我们还介绍了使用 Tivoli Storage Manager 进行对象加密与压缩的相关内容。

本文适于任何想了解 DB2 Content Manager 如何利用 Tivoli Storage Manager 进行企业内容管理的读者。也是面向需要架设理论验证(PoC)或演示程序的读者的快速入门指南。

致谢

特别感谢 America TechWorks 公司 Content Management 部门的 Amit Saha,他为我们提出了很多建议。

免责声明

我们竭尽所能撰写本文。若您对文中观点有任何不同意见,请随时与我们联系。


下载资源


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=143996
ArticleTitle=为 IBM DB2 Content Manager 启用 Tivoli Storage Manager
publish-date=06292006