XenDesktop SQL Server Mirror事务日志计算
为XenDesktop站点配置数据库是Citrix基础架构设施的一个重要组成部分,数据库里面 保存着该基础设施里面重要的数据。XD5 以及以后的版本由于架构的改变，数据库的重要 性和需求性都需要数据库保存 100%的时间在线，因此XD5 及以后的架构中，我们会花更多 时间来思考和规划数据库的高可用。在 XD 5 的架构中，由于去对应的是SQL Server 2008 的数据库，所以有上面我们提到的 3 中高可用的方法，当然不止这3 中，还可以借助第三方的软件进行数据库的高可用，但是这个一般都是基于成本考虑，有这 3 种就足够我们使用了，没必要在花冤枉钱再买第三方的软件来进行数据库高可用。在微软最新的SQL Server 2012 中，微软提供了一种最新的数 据库高可用方案：AlwaysOn，AlwaysOn 可用性组是 SQL Server 2012 中引入的具有高可用 性和灾难恢复能力的企业级解决方案。此方案可以使您最大程度地提高一个或多个用户数据库的可用性。 AlwaysOn 可用性组要求SQL Server 实例必须驻留在 Windows Server故障 转移群集 (WSFC) 节点上。具体信息可以参考一下微软官网的详细信息说明： http://msdn.microsoft.com/en-us/library/hh510230.aspx ，因此在XD7 中，对于数据库高可用 又可以新增一种方式：AlwaysOn；但是那和我们要讨论的Mirror事务日志貌似没多大区别， 在 XD7 中，如果对数据库做Mirror，其对数据库事务日志的增长更为迅速和庞大。其对数据库的要求比XD5更为依赖。1、XenDesktop 5 SQL Mirror事务日志增长量的计算
有一些重要的领域规划的SQL数据库，以便XenDesktop5时，包括考虑：•数据库大小•数据库镜像 数据库大小 数据库文件的大小取决于下列因素：•配置和注册工作站的数量•连接会话的数量•连接速率•管理桌面的数量•置备桌面的数量 每因素影响大小需求。
每个桌面上（托管或非托管）要求：• 〜2.9KB注册和虚拟机状态信息• 〜5.1KB的会话状态• 0.042 KB 为每个连接日志记录。默认情况下，这些都是在48 小时后清除。 每个机创建服务（MCS）配置的台式机还需要：• 〜1.8KB AD的计算机帐户信息• 〜1.94KB 为 MCS机器信息 例如，20,000 非托管的桌面，一个正常的用户每天会登录一次，有些用户也许漫游和重 新连接多次，使平均每一天的2 个连接的用户。使用这些数字和上述数据，我们可以计算出 数据库文件的大小为：• 每个虚拟机：2.9KB*20,000=58,000KB• 每个会话：5.1KB*20,000=102,000KB• 每个连接：0.042KB*40,000*2=3,360KB• 总计：163360 KB或160MB 基于思杰的测试，这个数据库大小相匹配的数据库为 20,000 个用户的规模。 使用上述数据，我们可以根据不同的用户数计算出预期的数据库大小。为各种用户数的 数据库大小显示在下面的表中：
UnmanagedDesktops5,00010,00020,000
Per Worker(KB)14,50029,00058,000
Per Session(KB)25,50051,000102,000
PerConnection(KB)8401,6803,360
Total(KB)40,84081,680163,360
Total(MB)4080160
ProvisionedDesktops5,00010,00020,000
Per Worker(KB)14,50029,00058,000
Per Session(KB)25,50051,000102,000
PerConnection(KB)8401,6803,360
Per ADAccount(KB)9,00018,00036,000
Per MCSmachine(KB)9,70019,40038,800
Total(KB)59,540119,080238,160
ProvisionedDesktops5,00010,00020,000
Total(MB)59117233
这是数据库的大小，而不是事务日志的大小。下面我们就老说说事务日志的增长量。 事务日志的大小计算比较困难，因为这取决于许多因素，包括：• 所使用的SQL 数据库恢复模型•在高峰时段启动速度•桌面的数量 •DDC心跳等 在测试中，如果数据库镜像为完整恢复模式，在 2000 台虚拟桌面中，发现只要40 个用 户以1.3MB/s的启动速度启动2 次虚拟桌面，这就将增大670MB的事务日志空间。空闲桌面没一个小时增长 62KB。注：这取决于后面讨论的心跳设置;增加心跳间隔将减少日志的使用。在24 小时内，一台桌面增长1.45 MB，那么20000桌面也就是增长29GB。 根据 Citrix的最佳实践，Citrix建议更改DDC 之前的心跳设置来减少事务日志的增长过 快。DDC 之间的心跳默认是 30 秒通信一次，这一次的通信会被记录进事务日志里面，而且 会产生大约6060 字节的大小。 Citrix 建议您使用数据库镜像时，更改默认的心跳超时。您可以通过更改注册表设置做 到这一点。这两个设置必须更改存储在HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\DesktopServer这些设置是：• HeartbeatPeriodMs - 控制心跳的时间间隔。即多久通信一次。Citrix 建议设置为10 分 钟。• MaxHeartbeatIntervalMs –指定心跳最长时间可以不用通信，默认情况下，这是没有 配置。 Citrix建议，如果使用完整恢复模式。那么建议设定一个固定大小的事务日志和一个怎对事务日志的SQL警告，这样，当事务日志达到50％或者80%时，事务日志自动备份并将以前的空数据释放掉。
2、XenDesktop7 SQL Mirror事务日志增长量的计算 对其事务日志的增长量有一下几方面来进行计算：l DDC心跳服务信息l 站点心跳服务信息l 虚拟机工作心跳服务信息 DDC心跳服务信息每一台XD7的DDC服务器都有10个WindowsService每隔30秒就进行一次心跳连接， 以证明DDC 服务器还活动并且正在运行。每一个心跳是606bytes，所以每一台DDC的心跳字节是6060bytes，一个小时是120个 心跳，那么每一台DDC一个小时的心跳字节就是727200bytes。 站点心跳服务信息有一个用户的登录请求等会话信息是由一台 DDC 来进行处理的，所以这种单独的站点 服务所产生的字节不会生成双份，我们单独在这里进行计算；Monitor:6 site services = 384 header + 6 * 190 = 1524 bytes DelegatedAdmin: 1 site service = 384 header + 1*190 = 574 bytes Broker: 16 site services = 384 header + 16 * 190 = 3424bytesHosting: 1 site service = 384+ 190 = 574bytesDesktopUpdate Manager: 1 site service = 384 + 190 = 574bytes Config Logging: 2 site services = 384 + 2*190 = 764bytesAD Identity: 1 site service =384 + 190 = 574bytes由此我们可以计算出，一次 Site Service 请求消耗的心跳是8008 bytes，那么每一个小时 就是960960bytes， 虚拟机工作心跳服务信息对于XD7的2 中模式（HSD和HVD）来说，每个虚拟机工作心跳是每5分钟进行一次， 心跳的大小为1150bytes，每一个工作心跳一个小时大约为13800bytes。 综上所述，我们来总结一下DDC 心跳=DDC 的数量 乘于 727200 bytes； 站点心跳=960960 bytes； 虚拟机工作心跳=虚拟机的数量 乘于 13800bytes；因此总空闲的增量=“DDC心跳”+“站点心跳”+“虚拟机工作心跳” 例如，对于一个10000台VM的VDI环境中，有2的DDC，最低的增长将是： DDC 心跳=2*727200 字节=1454400字节站点心跳=960960 字节 虚拟机工作心跳=10000*13800 字节=138000000字节每小时总空闲增长=1454400+960960+138000000=140415360字节或=134MB每小时那么每天增长3.2GB。
:)谢群主分享
页:
[1]