Citrix XenDesktop桌面虚拟化
终端更新和不断的增长
更低的桌面拥有成本
法规遵从和数据安全
随时随地的访问
各种因素驱动虚拟桌面的到来
桌面虚拟化
VDI（Virtual Desktop Infrastructure）
下一个IT基础架构的发展热点
适合所有类型的员工
信息保存在数据中心保证了数据的安全性
桌面的性能能够得到提升，因为它和应用后端的服务器都运行在数据中心
桌面可以分享最新最强大的服务器硬件
可以从任何地点远程访问桌面
维护桌面的费用大大降低
客户端管理的目标在哪里？
企业的用户划分
Task Workers
任务工作者
Information Workers
知识工作者
30%
55%
15%
Mobile Workers
移动用户
低个性化要求
低满意度要求
锁定应用
低成本
高个性化要求
高满意度要求
管理员权限
高成本
任务工作者 – 保持简单
标准化工作环境SOE
运行快速/低运维成本
数据安全
合规管理
Delivering shared desktops w/ apps
Thin client
XenApp
Task Workers (30%)
Deliver apps into VMs
XenApp for Virtual Desktops
XenDesktop
Desktop Appliance, Repurposed PC
Delivering virtual desktops with apps
Office Workers (55%)
信息工作者 – 部分个性化
Office day extension
Inter / intra office roaming
不经常出差
PC需要时常升级和更新
移动用户 – 最高灵活性
经常出差、离线工作
基本没有管理或很少管理
PC需要时常更新和升级
XenApp
Delivering apps into an installed desktop OS
Laptop
Mobile Workers (15%)
什么是个性化？
Applications
Folders & Files
Gadgets & Widgets
RSS, Favorites & Cookies
Wallpaper
Shortcuts
Screen Saver
Start Menu and Systray
Fonts & Toolbars
Search Catalog
Drive Labels
个性化 - XenDesktop 之前
在虚机上安装操作系统
在虚机上安装应用程序
在虚机上保存用户配置文件
每个用户都需要一个指定的虚机
传统方法IT 面临的问题
Desktop Delivery Controller
ICA
Image storage
on-line
off-line
VM sprawl thwarts scalability
Spiraling storage cost
Highly susceptible to storage bloat if VM lifecycle left unchecked
*: based on Citrix $101k purchase of SAN (fiber-channel, 15k-rpm drives)
Citrix提供最佳的VDI方案
Users
数据中心
高效传输协议ICA
用户配置文件
应用虚拟化
操作系统流处理
Apps
User Settings
OS
虚拟桌面
按需组合
尽量少的桌面镜像
简化桌面镜像
避免冲突，减少测试工作量
动态交付
虚拟化/隔离
XenDesktop – 轻松实现个性化
在虚机上安装操作系统
应用隔离发布
用户配置文件独立存放
所有用户使用标准镜像 – 隔离实现个性化需求
Desktop Support
EasyCall
桌面交付架构
Desktop Performance Monitoring
Desktop Appliances
Desktop Delivery Controller
Secure Remote Access
WAN Optimization
User Profiles
XenApp for Virtual Desktops
Desktop Provisioning
Apps
User Settings
Any Hypervisor or Blade PC
Virtual Desktop
OS
操作系统、应用和用户文件分别管理
Hypervisor
Network Storage
Xen, Hyper-V, VM
Network Storage
1:1
非Citrix
应用安装在桌面上
每个桌面一个影像
每个桌面需要独立管理
依然大量的维护和存储，只是从前端移到了后端
Citrix
应用和操作系统分离
只存放和维护一个OS 影像
应用独立运行，动态发布给用户
独立管理用户配置文件
真正的逻辑集中
Data Center
XenDesktop 架构
XenServer
Hyper-V, VMware
局域网用户
Desktop Appliances
远程和家庭用户
访问网关
Access Gateway
桌面
交付控制器
SAN
PVS
虚拟服务器
活动目录
漫游profiles
XenApp
虚拟桌面体验
Desktop Appliances
unmanaged machines
Access Scenarios
Web page
Windowed
Full-Screen
login
Full-Screen
XenDesktop
Apps streamed
App installed
XenApp
App published
SAP
用户的工作环境：虚拟桌面+虚拟应用
XenDesktop v2工作流程
ICA 客户端
Data Store
登录
Domain Controller
AD OU
Golden Image:
PV Tools
Virtual Desktop Agent
ICA & Streaming Client
虚拟磁盘
VDisk
Xen, Hyper-V, VM
request
sign & launch
桌面交付控制器
find desktop
resume
prepare
Licensing
ICA
validate
policies
license
Profiles
Apps
OS
XenDesktop和XenApp结合使用场景
共享桌面 发布应用
发布应用
笔记本
瘦客户端
任务型人员
移动办公人员
发布应用
XenApp for Virtual Desktops
XenDesktop Enterprise
办公室人员
XenApp
桌面接收器
虚拟桌面 发布应用
Rename Enterprise to Advanced
Add XA for VDI to new Enterprise & Platinum
New Enterprise
XenDesktop Includes
Virtual Desktop Infrastructure (XenServer )
Virtual Desktop Provisioning (Provisioning Server SP1)
Desktop Delivery Controller (DDC )
XenDesktop Setup Wizard
Virtual Desktop Agent with ICA Service (Version )
XenDesktop Architecture
Citrix Confidential - Do Not Distribute
让我们首先了解一下虚拟化市场机遇方面的概况。
*
*
*
Desktop delivery – a better way to deliver virtual desktops
Citrix XenDesktop goes beyond desktop virtualization to provide an end-to-end desktop delivery solution. XenDesktop dynamically assembles virtual desktops on-demand, providing users a new and pristine, yet personalized, desktop each time they log on – ensuring that performance never degrades. In addition, XenDesktop’s high-speed delivery protocol provides unparalleled responsiveness over any network. For IT organizations, XenDesktop greatly simplifies desktop lifecycle management and radically drives down cost of ownership by separating the delivery of the desktop OS, applications and user settings.
*
Let’s start by looking at the end user view. A typical XD deployment caters very well for users access virtual desktops through the Intranet. In a desktop-replacement scenario, where the user’s desktop is entirely virtualized, Desktop Appliances are the most cost effective way of delivering access. DAs are available from a wide range of Citrix partners, and are access devices that require minimal management overhead and provide an excellent end user experience when accessing and using virtual desktops.
Of course our reference architecture works also well for remote and home users, who would typically connect through the Internet. The Citrix Access Gateway functionalityis included in all XenDesktop editions and ensures that the communication with the virtual desktop is safe and secure – it works just like it always has when deployed in conjunction with XenApp.
Besides the end user devices and security appliances such as the gateway, all other components reside in the data center. We recommend that XD farms are not deployed across data centers separated by WANs. Instead, in such an environment you should implement separate farms in every site, and aggregate them using Web Interface technology that underpins the end user access mechanism.
The Desktop Delivery Controller is responsible for providing access to desktops, managing them and brokering access. It is built on top of XenApp technology, and is thus fully fault tolerant.
In our reference architecture, the virtual desktops are running as Virtual Machines – this is the most economic solution and can exploit the advantages of virtualisation, . Allowing unused virtual desktops to be suspended so that they don’t consume valuable resources. However, of course XD also supports virtual desktops running on top of blade PC hardware, if your applications require this (remember traders?). In any case, the virtual desktops should be properly secured and ideally be hosted in a separate security enclave in the data center, to protect your other data center services from interference.
The XenServer hypervisor is included in XD and thus the first choice to implement virtual machines. However, XD is virtualisation agnostic and will also work with 3rd party hypervisor solutions such as Hyper-V, Virtual Server, and VMware’s Virtual Infrastructure. In all cases, the DDC drives the hypervisors to start and stop virtual machines based on demand and administrative policy.
In our reference architecture, we use PVS to stream the OS environment to the virtual machines, and VMs use shared disk images. In other words, you can set up and manage a single PVS disk image which is then used in parallel by any number of VMs. This reduces both storage cost and management overhead. The virtual disk image is best stored on a SAN, and each VM also has a write back cache which is implemented through a per-VM virtual disk that is also mapped through XenServer into the SAN. This set-up provides a good balance between network utilization and performance.
Since shared disk images are used, user personalization in our reference architecture is catered for through the use of roaming profiles, where user data and configuration is saved to a separate file server.
Finally, apps are delivered to the virtual desktop from XenApp.
Using this environment, we can achieve a clear and clean separation between OS images (handled by PVS and XS), applications (handled by XenApp) and settings and configuration (handled by roaming profiles), which immensily improves manageability. And so this architecture provides a fully fault tolerant, scalable solution for delivering virtual desktops.
How XD works is essentially quite similar to how end users connect to XenApp.
The end user will get to the landing page shown earlier and enter their credentials at which point, the request for the desktop are sent to the delivery controller.
The delivery controller then works out which desktop is appropriate for the end user. It establishes that from the data store.
What it does then is to set up the environment for the end user to connect to. If it’s a provisioned desktop (the way that we’ve recommended that you implement the product) and the environment is not already spun up, it will initiate a boot of the virtual machine and the operating system will be delivered from Provisioning Server.
In the setup for XD, you have an alternative option to eliminate the startup delay for the end user. You can do this by configuring that for particular desktop groups, you want to specify an idle pool. From marketing perspective, this will be known as an ‘instant on’ capability.
What that really means is that on the backend, we can have the virtual machines pre-launched such that when the user connects, they get an instant on experience.
The way that this is configured on the desktop delivery controller is for each group, you specify the range of time you want a specific number of idle machines available. For example you can say that from 9am to 5pm you want 15 machines spun up and ready for use, where as outside of working hours, you bring it down to 2 or 3. Then the Desktop delivery controller will manage your infrastructure accordingly so that the user gets an instant on experience.
That integration is only available for virtual machines at launch, but an SDK will be coming later on for customers to modify that for support with blades. We’re going to introduce blade support as we move forward in upcoming releases.
Once the VM has been started, we send a preparation for connection to the VDA (the thing that delivers the ICA experience from the virtual desktop). The VDA resides on the virtual desktop. Its not always waiting for a connection.
From a security perspective, we wanted to be able to control when you’d be able to connect to those virtual machines. Not until an end user authenticates and the desktop delivery controller sends a preparation message to the VDA that you can connect to a virtual machine using ICA. This is a nice security feature that we’ve implemented to control who can access the virtual desktop and when.
What happens then is that the ICA client connects to the VDA. What's important about this is that clearly unlike the first release of DS v1, this is a direct ICA connection to whatever the virtual desktop is running on, virtual machine or the blade. This is a direct ICA experience just like customers are used to with XenApp.
What we do then is that we validate through examining a ticket that was previously created, whether that is the right user that is supposed to be connecting to the virtual machine and if that is not correct, we drop the connection.
We consume a license (XenDesktop will be licensed on a CCU basis, just like XenApp).
Then we implement policies for the way that that ICA connection is delivered. This is the point at which we would in XenApp say which apps are available. In XenDesktop this is the point at which we control policies like the ‘end user is able to map drives from the local machine’.
We have full support for the policies that customers are familiar with in XenApp as well as the SmartAccess capabilities of the AG product line. That is when those policies would be implemented.
That is essentially how XD works.
*
Something about making the devices the headings?
*
* XenDesktop only (Secure Gateway mode, no SSL-VPN available)
*
Virtual Desktop Infrastructure (XenServer ) - Enterprise-class virtualization infrastructure that creates the foundation for delivering virtual desktops and offers advanced management features.
Virtual Desktop Provisioning (Provisioning Server SP1)- Stream a single desktop image to create many virtual desktops in the data center on demand, enabling simplified management and lower network storage costs.
XenDesktop Setup Wizard- A simple wizard to enable IT to quickly create and deliver hundreds of virtual desktop.
Desktop Delivery Controller (DDC ) - Connects office workers to their personalized desktops with the best performance, ease of use and rich desktop experience.
Virtual Desktop Agent with ICA Service (ver ) – The component installed on the workstation to allow ICA connectivity.
*
*
