摘自: https://docs.citrix.com/en-us/xenapp-and-xendesktop/7-15-ltsr/citrix-vdi-best-practices.html
概览
失败原因分析
1. 缺少业务支撑
2. 缺少架构方法
3. 缺少经验
Define 定义
通过创建顶级的项目计划规划、优先活动、存储和硬件评估来搭建桌面虚拟化的商务案例
评估
关联主要业务,然后据此调整工作重心优先级。 此外,审查当前环境潜在风险和项目测试案例。这些信息有助于制定Citrix 部署、升级、扩容方向。
设计
设计框架要满足客户主要业务,继承评估阶段确立的标准。例如 环境可扩展、冗余、高可用等等。
部署
在部署阶段,基础架构要按照设计阶段的描述来安装配置。所有架构组件需要在提供给用户访问权限之前通过单元测试、集成测试。
监控
定义生产环境的架构和运维过程
项目评估
- 明确组织结构organization
- 明确用户分组
- 明确应用
- 明确项目团队
第一步 明确组织结构organization
客户是什么组织,为什么需要Citrix Desktop, 能带来什么好处,业务出发点是什么
第二步 明确用户分组
用户划分
- 用户属于哪个数据中心
- 用户的个性化设置需求(无,基本,完全)
- 安全性需求 (高、中、低)
- 可移动性 (本地、漫游的本地、远程、移动设备)
- 桌面丢失风险严重性(低,中,高)
- 工作负载 轻,中,重
分配桌面模型
- 服务器托管应用(windows Apps, VM Hosted Apps, Linux Apps,Browser Apps)
- 共享桌面(低费用,高密度解决方案)
- 池桌面
- 个性化桌面
- 专业图形桌面
- 本地流桌面
- 本地虚拟桌面
- 远程PC访问
Citrix 建议从服务器托管应用、共享桌面或池桌面开始规划, 不可能完全匹配需求,桌面丢失与个性化间冲突,考虑运维工作
第三步 明确应用
- 应用合理化(删除重复的应用)
- 映射应用到用户
应用合理化
- 多版本
- 非业务应用
- 历史遗留应用
- 管理应用
应用分类
- 通用应用
- 部门应用
- 用户个人应用
- 管理应用
应用详情
- 复杂性
- 应用需求
- 可移动性
- 外设
- 应用限制(权限、license、安全性、敏感性)
第四步 明确项目团队
业务角色
- Project sponsor 项目发起人
- Project manager 项目经理
- Business Manager 业务经理
- Business continuity manager 业务连续性经理 (think PM is)
- Test manager 测试经理
- Application owner 应用负责人
- Service desk manager 服务桌面管理
- Training manager 培训经理
- Communication manager 沟通经理
技术角色
- Citrix desktop architect
- AD Architect
- Virtualization architect
- network architect
- desktop architect
- storage architect
- backup architect
- Application packaging architect
- monitoring architect
- systems management architect
- security architect