|
为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 个用户的规模。 使用上述数据，我们可以根据不同的用户数计算出预期的数据库大小。为各种用户数的 数据库大小显示在下面的表中：
UnmanagedDesktops | | | | Per Worker(KB) | | | | Per Session(KB) | | | | Per Connection(KB) | | | | Total(KB) | | | | Total(MB) | | | | ProvisionedDesktops | | | | Per Worker(KB) | | | | Per Session(KB) | | | | Per Connection(KB) | | | | Per AD Account(KB) | | | | Per MCS machine(KB) | | | | Total(KB) | | | |
ProvisionedDesktops | | | | Total(MB) | | | |
这是数据库的大小，而不是事务日志的大小。下面我们就老说说事务日志的增长量。 事务日志的大小计算比较困难，因为这取决于许多因素，包括： • 所使用的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 = 3424bytes Hosting: 1 site service = 384+ 190 = 574bytes DesktopUpdate Manager: 1 site service = 384 + 190 = 574bytes Config Logging: 2 site services = 384 + 2*190 = 764bytes AD 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。
| 
发表于 2016-3-17 10:11:48
发表于 2017-7-10 09:35:46
谢群主分享
