Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1021890
  • 博文数量: 584
  • 博客积分: 2293
  • 博客等级: 大尉
  • 技术积分: 3045
  • 用 户 组: 普通用户
  • 注册时间: 2006-03-28 11:15
文章分类

全部博文(584)

文章存档

2012年(532)

2011年(47)

2009年(5)

我的朋友

分类:

2012-02-09 02:57:49

原文地址:MHVTL + TSM 实践总结 作者:holland_1

Platform Specification:
Linux: Red Hat Enterprise Linux Server release 5.3 (Tikanga)
Mhvtl: mhvtl-0.18-11 (coded by mark_harvey@symantec.com / markh794@gmail.com)
TSM :  TIVsm-server-5.5.0-0
Installing the packages: zlib-devel、 sg3_devel、 mt-st、 mtx、 lsscsi、 gcc

Confirm the system requirment && supported platforms for TSM
or

本文实践初衷是搭建一个TSM实验环境,Solaris10 5/09 (client) + RHEL5.3(tsm server).
后来实现LANFREE在安装StorageAgent(TIVsmSsta)时根据如上url确认出没有for solaris 10 x86_32bit的版本。所以需要将client换成linux或其它受支持的OS.

TSM的安装、配置网上随处可见,此处不详细提及。 主要阐述一下在搭建过程中遇到的问题及解决方法。

Mhvtl模拟2个带库
Sun StorageTek L700 (STK L700)
Spectra Logic Python系统架构磁带库 (spectra logic公司的python带库产品)

mhvtl以rpm及源码2种方式发布(源码编译时可能会报错没有名为vtl的用户,useradd就是)。

【磁带相关操作:】
查看机械臂状态 :           [root@b ~]# mtx -f /dev/sg10 status
将1槽位的磁带放到0驱动器里:[root@b ~]# mtx -f /dev/sg10 load 1 0
卸载磁带:       [root@b ~]# mtx -f /dev/sg9 unload 1 0
往磁带上写数据:            [root@b ~]# tar -cvf /dev/st0 liusuping.com.txt
查看磁带上的数据:        [root@b ~]# tar -tvf /dev/st0
查看磁带的状态:                                      [root@b ~]# mt -f /dev/IBMtape0 status
显示磁头现在在磁带的那个block位置 : [root@b ~]# mt -f /dev/IBMtape0 tel
倒带:                               [root@b ~]# mt -f /dev/IBMtape0 rewind
将磁带转到最后的block的末端:              [root@b ~]# mt -f /dev/IBMtape0 eod
格式化磁带/清除内容:               [root@b ~]# mt -f /dev/IBMtape0 erase
查看磁带上的数据需要将磁带转到开始处才行(下面三步):
[root@b ~]# mt -f /dev/IBMtape0 rewind
[root@b ~]# mt -f /dev/IBMtape0 tel
[root@b ~]# tar -tvvf /dev/IBMtape0

TSM安装后, 增加一个管理员用户tsmadmin,并给予其系统操作员权限
1、register admin tsmadmin “password
2、grant authority tsmadmin classes=system
注册客户端用户
register node "client_node_name"  "password"

【COMPATIBILITY (What software does it work with:) && CONFIGURATION】

COMPATIBILITY
Symantec NetBackup
    * 5.1 (Recommend 5.1MP4 minimum)
    * 6.0
    * 6.5.x
    * 7.0
    * 7.1Beta
    * Supports SCSI Persistent Reservation
    * Encryption via KMS (NetBackup 6.5.2 and later)

Note: All mhvtl code development is tested using NetBackup

Last set of testing (0.18-8 & -9) with NetBackup 7.0, I had to revert the 'STK/L700' to 'SPECTRA/PYTHON' change made back in Nov 2009. It's just a manual edit of /etc/mhvtl/device.conf

The problem is that NetBackup 7.0 fails to extract the device serial number if SPECTRA/PYTHON is used and hence the automagic device discovery & configuration fails to place the drives within the robot.


Symantec BackupExec.
For the extraordinary writeup :
Includes how to setup the scst () to present the vtl via iSCSI 

EMC/Legato NetWorker

Is no longer causing headaches !

Don't use 'STK/L700' Use 'SPECTRA/PYTHON' instead.

Install at least mhvtl-2009-12-16.tgz (mhvtl-0.16-11).
Update: The latest mhvtl-2010-09-23.tgz (mhvtl-0.18-11) is a smoother ride when configuring the library using jbconfig.

Build kernel module from source (Note: /usr/src/packages/ is a SuSE RPM home dir. If you building on RedHat, then this will be /usr/src/redhat/)

# rpm -Uvh mhvtl-0.18-11.src.rpm
# cd /usr/src/packages/BUILD
# tar xvfz ../SOURCES/mhvtl-2009-11-23.tgz
# cd mhvtl-0.18/kernel
# make
# make install

Start the daemons

/etc/init.d/mhvtl start

Configure NetWorker as normal via jbconfig.

An ex colleague who has some very useful/helpful tips with NetWorker (If your interested in NetWorker, his blogs & tips are well worth following)
http://nsrd.info/blog/2009/07/13/carry-a-jukebox-with-you-if-youre-using-linux/

Also a follow up article
http://nsrd.info/blog/2009/11/14/networker-and-linuxvtl-redux/

A detailed setup of CentOS + NetWorker, see:
http://nsrd.info/blog/2010/10/14/new-micromanual-linuxvtl-and-networker/

Bakbone Netvault』it's ok


CONFIGURATION

SERVER

Vi /opt/tivoli/tsm/server/bin/dsmserv.opt
dsmserv.opt内容如下:
*******************************
COMMMETHOD TCPIP
TCPPORT 1500
COMMMETHOD HTTP  # optional ,如果client要通过http连接过来,就要指定
HTTPPORT 1580   # optional ,原因同上
DEVCONFIG devcnfg.out
*******************************

CLIENT

Vi /opt/tivoli/tsm/client/ba/bin/dsm.sys (注:将/opt/tivoli/tsm/client/ba/bin/dsm.sys.smp     改名为dsm.sys)
dsm.sys内容如下:
*******************************
SErvername         SERVER1 (此名称为TSM服务器名称,默认为SERVER1)
COMMMethod      TCPip
TCPPort            1500
HTTPPORT           1581  # optional ,客户端需要通过图形管理界面配置自身时,dsmcad启动WEB访问时会读此文件的这个参数,如果用纯cmd执行backup/archive任务,不用设置
TCPServeraddress    192.168.0.1   (此IP为服务器端的IP)
nodename               CLIENT1   (此名称为服务器端建立的client node的名称)
passwordaccess     generate
***********************************
dsm.opt内容如下
***********************************
SErvername      SERVER1
***********************************
完成后,客户端dsmc 或 dsmadmc即可相互连接成功。

要从缺省目录(/opt/tivoli/tsm/server/bin)以外的目录运行服务器,必须为 Tivoli Storage Manager 定义环境变量。
(就是要把安装文件的路径添加到系统环境变量PATH,
有2种方法:
1、在会话term中直接重新定义PATH并export,在当前登陆的session中有效,relogin则不行 ;
2、修改用户home目录下的profile环境变量文件,追加export DSMSERV_DIR=/opt/tivoli/tsm/server/bin.可保证永久生效。
{之所以能始终有效,其实质上是在PATH原有值的目录下添加一个到你自定义变量路径下执行文件的链接,便实现不用在安装目录下就能执行})

可以将环境变量定义为指向服务器选项文件(dsmserv.opt)。
这允许运行在同一机器上的两个 Storage Manager 服务器共享相同的选项文件或使用不同的选项文件。
例如,要将环境变量 DSMSERV_CONFIG 定义为指向 dsmserv.opt,输入:
export DSMSERV_CONFIG=/opt/tivoli/tsm/server/bin/dsmserv.opt

可将环境变量定义为指向记帐日志文件。
记帐记录存储在 dsmaccnt.log 文件中。
DSMSERV_ACCOUNTING_DIR 环境变量指定记帐文件打开的目录。如果服务器启动时没有设置该变量,服务器启动时 dsmaccnt.log 文件将置于当前目录下。
例如,要设置环境变量将记帐记录放置在 /home/engineering 目录中,请输入以下命令:
export DSMSERV_ACCOUNTING_DIR=/home/engineering
注:
也可以使用 DSMSERV 命令的 -o 参数来指定选项文件名。
如果外壳程序是 csh 系列的,请使用下列命令:
setenv DSMSERV_DIR /opt/tivoli/tsm/server/bin
如果外壳程序是 ksh 或 bash 系列的,请使用下列命令:
export DSMSERV_DIR=/opt/tivoli/tsm/server/bin
要保存此环境,请将这些条目保存到 $HOME 目录中的 .bash_profile 文件。

【报错及分析】

【1、】定义drive的PATH时报错:ANR8420E DEFINE PATH: An I/O error occurred while accessing drive DRV0.
cause: 定义时指定的设备文件与虚拟出的磁带驱动器不对应 或 当前驱动程序生成的设备文件不能为TSM识别
solution:重新尝试其它磁带驱动器设备文件 或 重装驱动
notes:
Tivoli Storage Manager 为非IBM设备提供了自己的设备驱动程序(TIVsm-tsmscsi)。
IBM 自己的设备支持 IBM 设备驱动程序 Atape。(Atape支持多种平台)
3580、3581、3582、3583、3584设备都属于LTO产品线,它们均使用相同的设备驱动程序。
IBM eServer P系列AIX操作系统使用的设备驱动程序叫做ATAPE。ATAPE包包括了LTO磁带机驱动程序也包含了介质变换器(机械臂)驱动程序。

The device driver FTP site will be sunset around in June 2010(ftp://ftp.software.ibm.com/storage/devdrvr/FTPSITE_IS_SUNSET.html) 
All new IBM tape device drivers are only be posted to the web through fix central downloading portal and not through ftp site. 
Obtain them by accessing the following URL ()

Four urls for reference
据如上4个web可确认虚拟出的IBM ULT-3580 需要安装atape for linux,步骤如下(机械臂驱动由TSM自带驱动支持):

说明:一个为源码驱动lin_tape-1.xx.0-1.src.rpm.bin;另外一个为守护进程驱动,按最新的下

1、download linux driver from “”
2、用rpmbuild -- rebuild <驱动名称>,来编译源码驱动,例如:
     # rpmbuild -–rebuild lin_tape-1.xx.0-1.src.rpm.bin
3. 运行后会在当前界面最下面显示一个rpm安装包路径,例如:
     Wrote: /usr/src/redhat/RPMS/i386/lin_tape-1.xx.0-1.i386.rpm
4. 使用rpm –ivh <文件名>,来安装这个rpm安装包,如:
     # rpm -ivh /usr/src/redhat/RPMS/i386/lin_tape-1.xx.0-1.i386.rpm
5. 安装守护程序,如:
     # rpm -ivh /usr/src/redhat/RPMS/i386/lin_taped-1.xx.0-rhel5.i386.rpm

"TSDrive0" -(/dev/IBMtape1n)  磁带驱动器  
/dev/IBMtape1 - tape volume
IBMchanger = robot arm = tape_library name

设备 设备示例 逻辑文件名
由 Tivoli Storage Manager 设备驱动程序支持的磁带机 /dev/mtx mtx
由 Tivoli Storage Manager 设备驱动程序支持的附带 SCSI 的库。 /dev/lbx lbx
由 Tivoli Storage Manager 设备驱动程序支持的光驱 /dev/ropx opx
与 GENERICTAPE 设备类型关联的驱动器 /dev/rmtx rmtx
IBM 3570 设备和作为库的 IBM 3590 B11 的自动盒式磁带设备功能部件 /dev/rmtx.smc rmtx
IBM 3575、3581、3583 和 3584 库 /dev/smcx smcx
IBM 349X 库 /dev/lmcpx lmcpx
在 REMOVABLEFILE 设备类型(CD-ROM)上使用的安装点 /dev/cdx cdx

【2、】无法删除已经register的node
cause :node有filespace(q filespace 确认),故无法删除
solution:delete filespace "client_node_name" *,再remove node "nodename"

【3、】备份报错 ,查看server artlog 信息 q act 有保存信息:
ANR0535W Transaction failed for session 18 for node SCOBAK (HPUX) - insufficient mount points available to satisfy the request.
solution: 
"make more mount points available or validate your device class and library configuration."
q node f=d 确认Maximum Mount Points Allowed: 1
执行 update node ‘nodename’ MAXNUMMP= 100

【4、】备份报错:ANS1312E Server media mount not possible。
cause:定义的drive同时能read和write的类型,与定义的设备类类型不符。
solution:
q devclass ‘devclassname’ f=d确认定义的设备类类型,update devclass “devclassname(可以通过q devclass看到)” format=‘新设备类型’

【5、】备份报错:
server console出现:ANR8308I 001: LTO volume ‘volumename’ is required for use in library ‘library name’; CHECKIN LIBVOLUME required within 55 minutes.
client 端报:ANS1114I Waiting for mount of offline media.
client 执行 q mount 出现:ANR2034E QUERY MOUNT: No match found using this criteri×

client 再次发起备份操作,再次q mount出现:
ANR8379I Mount point in device class LTO2 is waiting for the volume mount to complete, status: WAITING FOR VOLUME.
ANR8334I         1 matches found.

备份stgpool里面的所有volume状态被置为unavailable

cause: client node是往备份的stgpool里放数据(而q stgp ‘pool_name’ f=d可确定Maximum Scratch Volumes Allowed: ‘NO.’,即该pool中有几个volume,再通过q v得知,数据是往哪些volume中写的。
数据先往第一个volume上冲写,但底层的物理driver mount不上来,libvolume无法checkin,失败后就置volume的access状态为unavailable,然后再往stgpool里的第二个volume上冲。如果volume都失败,最终的所有volume的access状态都被置为unavailable。

analyse:Update drive online=no 并Update drive online=yes之后,drive状态变为UNKNOWN,可推测出是robot arm与drive不匹配兼容

solution:
执行cancel session ‘session number’取消client的备份操作
1、updata volume ‘volumename’ access=readwrite 更新volume状态
2、设置/etc/mhvtl/device.conf重新虚拟新的带机和带库,并重新定义设备类

notes:
ANR8972E DEFINE PATH: Unable to find the element number for drive DRV0 in library VTL02.
ANS8001I Return code 15
如上的报错,也基本可确定是虚拟出的机械臂和driver不匹配导致

【6、】checkout 磁带时
server console 报错如下:
ANR8387I: Request number : All entry/exit ports of library library name are full or inaccessible. 
Empty the entry/exit ports, close the entry/exit port door

analyse:
mhvtl虚拟的磁带是装好到带库里的,因为是虚拟带库,所以还没找到用什么mtx命令把磁带拿出带库。
checkout操作只是把磁带从定义的library中取出放到虚拟出的几个IMPORT/EXPORT 槽中(用mtx -f /dev/sg10 status命令可以确认)。 接下来应该是物理上的操作,即把磁带从门口取出

solution:  

【7、】checkin磁带到定义的library中并同时做label时
ANR8302E I/O error on drive DRV0 (/dev/IBMtape0) with volume CLN301L4 (OP=READ, Error Number=5, CC=0, KEY=02, ASC=30, ASCQ=03,
SENSE=F0....Description=An undetermined error has occurred).  Refer to Appendix C in the 'Messages' manual for recommended action.

solution:
http://www.ibm.com/developerworks/wikis/display/tivolistoragemanager/ANR8302E+and+ANR8806E+message+during+volume+labeling+using+TS3310+and+Application+Managed+Encryption--TSM+V6.1,+V5.5,+V5.4

notes:
对于手动执行的process ,在cancel后可能会出现pending状态,这时要cancel request all去cancel request,可重复执行直至所有request都cancel掉(根据屏幕回显来确认)

LANFREE方面,
linux下通过iscsi将虚拟磁带库(mhvtl)共享出去,然后在solaris端使用iscsi协议访问虚拟磁带库。
可参考http://candon123.blog.51cto.com/704299/415377  (此文把iscsi target共享权限设置这关键的一步漏掉. 所以在处理时注意自行设置添加)
如何配置 Solaris iSCSI initiator见 : http://tagche.blog.51cto.com/649757/278320. 

【几种方式的比较】

『VTL』是把磁盘虚拟成磁带库,磁带库的外部特征有三大要素:接口、驱动器和磁带槽位;内部特征是能进行顺序读写的指令集。一个VTL必须模拟这两大特征才能工作。目前有两种形式的VTL,
一种是集成在某一个备份软件内部的模块,如Bakbone的VTL,这种VTL只能被该备份软件调用;
另一种是单独运行在一个主机上的VTL软件,这种VTL是完全模仿了一个真实的磁带库,如FalconStor(飞康)的VTL,能被所有的备份软件调用。VTL的优点和缺点都是十分明显的。VTL的优点在于:
1.加快了读写速度,缩小了备份窗口。
2.能在不修改备份软件的前提下,利用磁盘进行备份。特别像FalconStor的VTL,能与任何备份软件结合使用。
而VTL的缺点包括:
1.VTL模拟磁带顺序读写方式,不能充分发挥磁盘的效率。
2.VTL的效率要受到虚拟驱动器个数的限制。虚拟驱动器的个数越多,效率就越高,但虚拟驱动器的个数不是免费的,且价格还不低。即使VTL免费送几个虚拟驱动器,用户也还要买备份软件中的驱动器许可证。
3.VTL的备份策略设置与磁带库完全一样,比较复杂。
4.用户需要花钱买VTL,还要花钱买备份软件中支持磁带库的许可证。

『D2D』是把磁盘直接作为备份介质来使用,其本质就是写文件系统,但并不是用原文件的格式和普通的写方法,而是把备份文件以大块为单位放在一个大文件中。
  CommVault的D2D技术采用的是带索引的写入方法,从而实现了中断重起、动态容量扩充、跨卷、网格存储等高级功能。这种D2D的优点是:
1.充分利用了磁盘的随机读写性能,效率比VTL高。
2.充分利用了文件系统的多线程技术,在多个备份任务情况下,不像VTL要受虚拟驱动器的限制,效率很高。
3.D2D与备份软件集成,不需要花双倍的费用。
4.D2D能实现许多高级功能,如中断重起、动态容量扩充、跨卷、网格存储等。这些高级功能在大型网络或广域网上备份,非常有用,能极大地提高备份的可靠性和成功率。
5.D2D的管理十分简单,管理员很容易掌握。
6.D2D并不是把磁盘当成备份的中介环节来设计,与备份Cache有本质的区别,它能让数据在磁盘上长期保存。在保存数据的能力上比VTL更高,D2D可以很方便地把数据迁移到不同的OS文件卷下,
   数据要做长期保留就需要这一特征,当某个系统过时了、介质或供货商停产了,数据就要往新的环境下迁移。

D2D的缺点是:
1.D2D没有统一的标准,只能与备份软件紧密地集成。
2.D2D在Unix SAN环境下的LAN-Free备份,如用户要把数据集中存放在一个卷下时,需要共享卷软件来支持,这样会提高使用成本。不过,Bakbone的VTL也需要共享卷软件来支持。

VTL与D2D2T:
『D2D2T』第二个D to T和以前的D to T是不一样的,备份软件是将D中的数据当作磁带数据处理的,将D假象为虚拟磁带,直接进行虚拟磁带到磁带的拷贝。
虚拟磁带库(VTL)和磁盘到磁盘(D2D)都是用磁盘来做备份的技术,要对两者进行比较,主要看它们是怎么工作的。

目前虚拟带库有两种方案,一种是真实的虚拟带库,有这样的产品,比如NetStor。第二种是以legato等软件以硬盘阵列模拟出来的driver。
现在关于虚拟带库用第二种方案的人居多,原因是第一种方案周样容量价钱高一些,同时这样的产品较新。
如下说说真实的虚拟带库与磁带库相比它的优缺点:
优点:
1、虚拟带库在legato软件看来就是一个真实的带库,完全适用对带库的管理方式,如果一个虚拟带被写满,它同样被置为full,这是做虚拟driver方式不能比的了,
   如果是虚拟driver被写满会错的(操作系统+备份软件)。
2、虚拟带库用的实际上磁盘阵列,因为磁盘的随机读的特性,如果你的数据只是很少量的坏,比如oracle的一个数据文件或一个block,此时它的恢复速度要比带库快的多。
3、同样是因为磁盘,虚拟带库可以保证备份的数据一定可以恢复,而带库就不一定了,因为磁带可能被磁化、被氧化,可能因为driver的故障引起损坏等等,所以虚拟带库的备份相对来说更安全。
4、虚拟带库是以带库的模式管理磁盘的这样的一个产品,结合两者的优点,当然优点突出。

缺点:
1、贵。
2、容量小。可以认为带库的容量是无限大的,而虚拟带库的容量是有限的,同时它与小阵列做虚拟driver的方式比容量也小了一些。
3、速度相对来说慢。一般虚拟带库有的都是sata盘,速度实测一般在80m-100M左右,而带库,用lto3的driver,假定为6个可以达到6*80=480M/秒左右的速度。


阅读(5789) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~