求助：SAN Client备份频繁出现83错误
本帖最后由 s_p_kvw3000 于 2012-09-11 10:37 编辑环境：NetBackup 7.1，Suse 10 x64（media & client）
每个media上配置了3个光纤口用于FT Media，每个口下面连接3-6个SAN Client，每个Client上配置2个备份策略。media的最大FT连接数设置为16。另配置NUMBER_DATA_BUFFERS=16，SIZE_DATA_BUFFERS=262144。
存储介质为VTL，配置8个驱动器，并设置MPX为4。
现象：其中一台服务器在批量（约15个）开始备份任务后，仅3-5个任务可以正常执行，其余任务均报media open error(83)错误，详细日志如下：09/11/2012 01:10:57 - Info nbjm (pid=5246) requesting STANDARD_RESOURCE resources from RB for backup job (jobid=23935, request id:{DE2AF8E8-FB72-11E1-B128-3914357F5B6B})
09/11/2012 01:10:57 - requesting resource Any
09/11/2012 01:10:57 - requesting resource nbumaster.NBU_CLIENT.MAXJOBS.cbp39b
09/11/2012 01:10:57 - requesting resource nbumaster.NBU_POLICY.MAXJOBS.cbp39b.file
09/11/2012 01:10:57 - granted resourcenbumaster.NBU_CLIENT.MAXJOBS.cbp39b
09/11/2012 01:10:57 - granted resourcenbumaster.NBU_POLICY.MAXJOBS.cbp39b.file
09/11/2012 01:10:57 - granted resource00A065
09/11/2012 01:10:57 - granted resourceDrive001
09/11/2012 01:10:57 - granted resourcenbumedia1-hcart3-robot-tld-0
09/11/2012 01:10:57 - granted resourceTRANSPORT
09/11/2012 01:10:57 - estimated 8402934 kbytes needed
09/11/2012 01:10:57 - Info nbjm (pid=5246) started backup job for client cbp39b, policy cbp39b.file, schedule Full on storage unit nbumedia1-hcart3-robot-tld-0
09/11/2012 01:10:57 - started process bpbrm (pid=10221)
09/11/2012 01:10:59 - end writing
media open error(83)观察备份期间的服务器状态（Devices-Media Servers-View FT Conncetions），显示此时仅有3个连接，而与其配置相似的另一台media上则同时有8个连接。而且出现问题的客户端也不是固定的。查看media和client上的日志，只在报告里发现有伴随的pipe open failed(17)记录。
请各位大侠帮忙分析一下，谢谢。另外，NBU的FT介质服务器每个端口最多可以同时运行多少个备份任务（任务所属客户端不同）？
太夸张了吧，15个作业并发往里写。。83写入错误，nbu7x后常见的错误，要么VTL受不了要么FT服务器受不了。。。 那按照这个配置，最多允许多少个任务并行执行？肯定不会只有3个那么少 10几个就受不了了？
建议安装补丁到7104，看能好点不 问题出自VTL的驱动器数量与并发量不匹配。 并发15个，写到后面的8个驱动器上，问题在这。 回复 5# 无牙
我觉得问题不出在这里，即使有job没有驱动器可用，也不会产生83写入介质错误的吧 huanglao2002 发表于 2012-09-12 12:27 static/image/common/back.gif
10几个就受不了了？
建议安装补丁到7104，看能好点不
那么大并发数量，vtl或者ft服务器来不及处理也不奇怪。
你想想，如果客户端服务器和后端的存储都不存在任何瓶颈，意即每个通道都达到4Gb/s左右，那么按照楼主的情况，4*3=12Gb/s
如果是10多个硬盘，一个控制节点的那种中低端的VTL，他的并发写入能力有那么强吗？当然没有。。
不知道15个并发作业中，读取的数据是否都来自同一个存储？如果是，那么设定那么多的并发作业不可行啊，假如FT服务器和VTL不存在任何瓶颈的话，也就是客户端传送多少数据，备份就能接受多少数据，那么存储不被拖死才怪；
假如FT服务器和VTL存在瓶颈比如只能接受4Gb/s的流量，那么存储性能再好，备份效率也无法提高，这时候你设定15个并发作业，8个驱动器的备份效率还不如4个驱动器，4个并发作业来的快吧
本帖最后由 s_p_kvw3000 于 2012-09-12 18:02 编辑
我更详细地描述一下我的环境吧
备份介质是VTL，已经确认其并发任务数可以达到64；每个介质服务器分配1个虚拟带库，8个驱动器，通过光纤交换机到每一个介质服务器，配置multiplexing per driver为4；另配置了3张HBA卡用作FT传输，每个光纤卡通过交换机连到6-12个客户端，每个客户端上有2-3个任务，同一个客户端上的任务已经配置在不同的备份窗口内执行了。4台介质服务器是使用同一套VTL作为存储的，但是另外3台介质服务器上没有这个问题。
15个备份任务是比较高的情况，但是并不是说就有15个数据流在写数据。其中3个备份任务正常开始，稍后经过一次重试又有3个备份任务开始执行，剩余备份任务再次报83错误后终止，看起来就像是这个介质服务器上只能并发3个备份任务。成功执行的备份任务，平均备份速率为30MB/s。
这里先不考虑备份性能，主要是解决并发任务数的问题 回复 6# myguangzhou
SAN client 到FT media server这端是就是一个物理连接，所以有多少流都能通过， 问题出在FT media server写后端的存储。 FT 上的STU是怎么配置的？
页:
[1]
2