前序的文章，可能很多同学都会反映说在日常的项目中，很少能够有机会构建一个超过1000个桌席的环境，这个对于我有什么作用？

其实项目的规模都是由小变大，在整体的设计逻辑上完全是相同的。

比如：基础架构部分，对于500点左右的规模，我们可以使用2套基础架构来支撑。

桌面承载的密度，还是要取决于你用户的使用场景的负载来决定你的密度。

同样还需要考虑所使用的CPU的核数，理论上核数越多，能支撑的用户数也就越多。

 

除此之外，例如：DDC，StoreFront，SQL的高可用都一定不要忽略，实现至少双机的冗余。

 

同时，存储规划也是在桌面项目中重中之重，但很多时候花了大钱买存储去没有把存储真正用起来。

原因就在于，桌面虚拟化项目中，除非考虑DR，否则他对于存储只有以下两个最基本的要求：

1. 空间够用

2. IOPS够用

说起来容易，但做起来不易。其中最容易被我们忽略的就是用户数据这一块。因为大家一般都会把桌面承载、基础架构的资源给的足足的，而用户这块经常忽略掉。

 

其实在一个桌面项目中，合理的规划是把用户数据统一上收存放在共享类存储中，以保证任意设备、桌面访问时都能获取数据。

而用户数据多使用网盘形式挂载，那么就牵涉到两块内容：

1. 用户的Roaming Profile

2. 用户网盘数据

这两种数据无论哪一种，他都需要基于微软的CIFS/SMB协议来支持，而这也是为什么在桌面项目中，经常会建议用户使用NAS类存储的原因。

如果如本例中，使用SAN存储那么需要部署独立的Windows Server来作为文件服务器。

 

那么回到存储规划这块，随着服务器、存储技术的提升，现在对于VM的IO压力很多时候可以通过各种新技术来进行消化，事实上在合理规划后这块的IO压力几乎可以忽略。这也是为什么在本例中，几乎没有对任意一个类型的VM的IO进行特别多的规划的原因，因为其IO实在太小了。

 

而反观用户数据，他由于使用CIFS/SMB协议，天生无法使用这些存储级别的优化，而且由于Roaming Profile在每次用户打开自己桌面时都需要从存储中读取到虚拟机中，如果存储、网络性能不好，直接的结果就是用户开机会觉得特别的慢。

而网盘数据虽然不会每次开机读取，但如果用户的单个文件特别大，结果就可能导致读取偏慢。

 

所以现阶段，很多时候我们会把像固态硬盘这样的资源优先提供给用户数据部分，其次才是虚拟机。同时在网络层面，提供足够的带宽完成用户数据/Profile的交互就变得极为重要。因为归结到底，我们要提供一个***的使用体验给到用户。这在用户层面是最最需要考虑的。

 

写在最后：

本系列文档中描述的各种方式，其实并一定是标准化的选择，因为在每个项目中，我们所能使用的硬件（服务器、网络、存储），用户需求都不一样，我们可能需要因时、因地、因人来合理的规划一个项目，但这个逻辑架构设计的思路是不变的。

同时随着技术的发展，类似于SDN，Server SAN等解决方案，万兆、40G吞吐网络，FCOE等新技术事实上都会对包括桌面虚拟化各种解决方案进行有益的推进。

 

参考文档：

Citrix Virtual Desktop Handbook 7.x

http://support.citrix.com/article/CTX139331

 

      本文转自sesame.qian  51CTO博客，原文链接：http://blog.51cto.com/kaiqian/1717067，如需转载请自行联系原作者