别伤了虚拟桌面管理员的"心"

简介:

    在CITRIX去年发布的XenDesktop 5中一直让我头痛的问题,就是对后台数据库的依赖性,以及更让我头痛的就是事务日志文件的疯狂增长。原以为在SP1发布后会得到改善,可还是让我失望了
    以下将介绍在XenDesktop 5中数据库文件(.mdf)及事务日志文件(.ldf)的增长情况以在实现数据库HA的问题:

一、针对数据库文件(.mdf):


以下为可能影响到数据库文件尺寸大小的几个因素:
a、配置与注册的工作站数量
b、连接会话的数量
c、连接率
d、管理桌面的数量
e、预备的桌面数量

每一个(管理、非管理)虚拟桌面尺寸要求:
a、注册与工作状态信息2.9KB
b、会话状态消息5.1KB
c、每一个连接日志记录信息0.042KB
 
每一个通过MCS生成的虚拟桌面尺寸需求:
a、在AD中计算机账号信息1.8KB
b、MCS机器信息1.94KB
 
例子:
20000个非管理桌面,在常规一天时间里每用户登录一次,以及一些漫游用户也许会进行多次连接,平均为每用户在一天时间里有两次连接。依照这种情况,我们可以得出以下数据:
• Per Worker: 2.9 KB X 20,000 = 58,000 KB
• Per Session: 5.1 KB X 20,000 = 102,000 KB
• Per Connection: 0.042 KB X 40,000 X 2 days = 3,360 KB
• Total: 163,360 KB or approximately 160 MB

以上基于CITRIX测试,数据是完全相匹配的。同比不同规模的数据库文件尺寸大小,如下:

 二、针对事务日志文件(.ldf):---痛苦的开始!

影响事务日志尺寸大小其主要包括以下几个因素:
a、SQL 数据库所使用的恢复模式
b、高峰时间的启动率
c、虚拟桌面的数量
 
    在测试过程中,如果数据库为完全恢复模式情况下,在一秒中内启动40个用户将消耗1.3MBs事务日志,还是以20000个虚拟桌面为例,将直接产生670MB事务日志。
而空闲的虚拟桌面在每隔一小时会自动生产62KB日志文件,如果要控制事物日志的增长,可以设置心跳的频率。

 


    另外在一天24小时内,每个虚拟桌面将会生产1.45MB日志文件,如果是20000个虚拟桌面将会是29GB,所在在大型环境中你需要对事物日志额外的观察及管理。
当然,在默认情况下XD5对数据库的恢复模式是“简单恢复”这样可以不产生事物日志文件,但会直接影响到灾难恢复,无法恢复到某一时间点。所以CITRIX建议你把数据库的恢复模式改也“完全恢复”模式,但前提是你要能容忍事务日志的快速增长。还要进行相应的备份。 如此大的量,备份也是一个问题吧!!

    CITRIX给出的建议是对事务日志文件尺寸进行控制并加以监视 (治标不治本),当达到50%时进行报警,再进行相关备份,以便控制日志文件尺寸的进一步增大。因为当事物日志文件达到一定的尺寸时,会直接影响到数据库的性能。可能直接导致虚拟桌面状态信息与数据库信息不致,从而让原本空闲的虚拟桌面不能分配给最终终端用户。
 


    从以上信息得出结论,CITRIX XENDESKTOP 5对数据库有着极大的依赖性,从而我们不得不考虑数据库的高可用性。而数据库的高可用性,从SQL Server 2005 SP1后,微软建议采用数据库镜像的方式,而非SQL Server 2000群集方案。而在配置数据库镜像方面,却不是每一位普通管理员可以做到的事情,要想实现一套最高级别的数据库镜像你是需要下点功夫的,特别是出现故障时,你必定会傻眼。在配置方式有多复杂,可参考我另一篇Blog:
SQL Server 高可用最高级别 , 加固你的 DATA STORE
http://virtualtop.blog.51cto.com/41003/499118


 

本文转自 zhxhua 51CTO博客,原文链接:http://blog.51cto.com/virtualtop/624930 ,如需转载请自行联系原作者

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
存储 前端开发 虚拟化
|
关系型数据库 MySQL 开发工具
|
存储 虚拟化 数据安全/隐私保护