分类：
2009-11-16 16:37:43
刚完成VCB1.0/NBU5.1MP6到VCB1.5/NBU6.5.4的升级. 碰到几个不大不小的问题.
1. 原计划是NBU只升级到6.5.3. 步骤:
A) NBU5.1MP6到NBU6.5 升级安装
B) NBU6.5到NBU6.5.3 升级安装
C) 卸装VCB1.0
D) 安装VCB1.5
2. 完成上述步骤后遇第一个问题. 备份时NBU报156错-SNAPSHOT相关的问题. 用VCBMOUNTER查看, VM成功建立快照, 在拷贝VMDK文件时出错 – DISK LEASE 更新请求失败.
跟VMWARE技术支持扯皮两天, “”偶然”"的发现, 运行VCB1.5的用户户口权限要求与VCB1.0不同了. VCB1.5要求该户口对CLUSTERS & HOSTS”授权, 以前只要对备份VM所在CLUSTER授权即可.
哎, 既然改变了就要有所说明嘛(也许我和他们SUPPORT都没看到).
3. NBU6.5.3在VM备份过程中, 调用vcbmounter拷贝VMDK文件到VCB MOUNT POINT时的文件格式问题.
进行FuLLVM备份时, NBU先调用vcbmounter将VM的VMDK数据拷贝到VCB MOUNT POINT上再行备份.
过去用NBU5.1的时候, VCB拷贝一个300GB的VMDK文件大约用一个半小时. 在NBU6.5.3下, 竟用了将近9小时.
仔细观察, NBU5.1调用VCB拷贝VMDK文件是采用parse文件的形式(莫认, 可设置成其它) – 既将大VMDK文件分割成许多2GB的小文件来传输. 而NBU6.5.3时, 则用了monolithic, 既整文件传输, monolithic的话, 文件越大, 传输速率越低.
NBU5.1使用config.js配置文件对调用vcbmounter时的参数进行配置. 其中莫认文件传输格式为parse. 到了NBU6.5.3, 它不再使用config.js. 指定使用monolithic. 不可改. 经过两个星期的”"探讨”"(和Symantec), 最后确定必需升级至6.5.4, 然后在加载一个EEB(Engineering Binary), 该EEB添加了一个设置, 可选文件格式(monolithic或parse). 这样, VCB文件拷贝速度才又回升.
4. VCB Mount Point cluster size 和NBU client properties中raw partition read buffer size设置对备份速度的影响.
Symantec 建议在格式化VCB mount point使用cluster size=64KB. 同时在NBU配置中将VCB PROXY client 的读缓冲设为mount point cluster size的数倍. 测了几个配搭 (test backup target: A virtual machine with 130GB backup data):
VCB Mount Point Partition Cluster Size = 4KB
NBU Client Raw Partition Read Buffer 32 KB 64 KB 128 KB
VCB Mount Time (mins) 51 38 41
Backup Time (mins) 58 55 48
Backup Speed (MB/s) 40 45 51
VCB Mount Point Partition Cluster Size = 64KB
NBU Client Raw Partition Read Buffer 32 KB 64 KB 128 KB 256 KB 512 KB
VCB Mount Time (mins) 38 50 46 36 43
Backup Time (mins) 52 65 48 44 44
Backup Speed (MB/s) 46 37 50 55 55
从这些测试来看, VCB Mount Point Partition Cluster Size (比如, 4KB或者64KB, 似乎对效率影响不大. 而NBU Client的读缓冲相对于Cluster Size的倍数影响比较大一些. 最好能有个4倍.
由于测试是在共享环境里做的, 无法完全排除其他影响因素, 结果只能做参考.
5. VCB 备份过程中vmdk”脏块 – dirty blocks”的问题.
在VCB备份过程中, VCB可以区别VM的vmdk中已使用的数据块和尚未存储用户数据的空白数据块, 并在备份过程中只备份已被使用的数据块. 以提高备份的效率. 比如, 创建一个有300GB大小vmdk的VM, 加载100GB的数据, 此时对该VM的VCB FULLVM备份数据应该是100GB多一点, 而不是300GB.
不过要注意的是, 如果此时在guest OS中删除80GB数据(剩下20GB的数据), 此时再对该VM做FULLVM备份, 备份数据仍是100GB, 而非20GB.
原因是ESX数据登记表记录guest OS使用的数据块情况. 一个vmdk新建立时, 数据表清零. 之后每分配一个块, 都在块登记表中将该块记录为已使用块(所谓的dirty block). 但是在guest OS中删除数据时, guest OS只修改它自己的文件对照表. ESX没有机制去修改VM的数据块登记表. 所以VCB依然认为这些块是guest OS正在使用的. 将其备份.
这个虽然对备份效率有影响, 但目前似乎也没有办法解决. 所能建议的是建立一个新vmdk, 在guest OS中将数据考到新盘上. 希望VMware今后能改进.
6. 在NBU/VCB 备份过程取消备份操作. 如果此时VCB正在将vmdk拷贝到VCB mount point. 即使在NBU中看到取消请求成功完成, 但回发现其实VCB的拷贝并未中断. 它会一直进行知道拷贝完成, 然后再将考贝的数据删除, 并删除VM的快照.
这有几个问题, 如果是大VM, 采用单一(monolithic)文件格式做VCB拷贝, 拷贝过程相当长. 在此过程中, VCB mount point被大量数据占据; VM的快照持续增长, LUN的IO仍在为被取消的操作做无用功.
而且, 由于在NBU的管理界面上看到取消操作已经成功完成. 又发现该VM还存在快照, 容易误认为是备份操作完成后遗留下来的, 往往会去清除快照. 其实此时VCB的vmdk拷贝还在进行中. VCB仍拥有对该快照的控制. 手动删除会失败. 以为VM出了问题.
Symantec说它们目前没有办法中断VCB拷贝. 建议咨询VMware. 我查了一下, 有些人的建议是中断VCB服务. 不过我自己还没试过.
