读书频道 > 系统 > 其他综合 > VMware vSphere设计(原书第2版)
2.3.4 对比不同的部署选项
2015-10-26 15:08:23     我来说两句 
收藏    我要投稿   
《VMware vSphere设计(原书第2版)》共12章,第1章介绍vSphere的设计流程,涉及如何理解基本需求和如何评估并设计一个成功有效的实施方案。第2章介绍ESXi管理程序的基本设计选择,主要研究ESXi背后的架构。第3  立即去当当网订购

每个部署选项都可以提供可服务的ESXi host,分别有各自的优点和缺点,每个方法都有各自最适合的环境。如图2-3所示,总结了这些选项以及它们是如何影响到服务器的引导位置的。

 
 

查看服务器是如何部署的

如果已经开始管理一些ESXi服务器了,但不确定它们是如何部署的。你可以通过一个简单的命令行工具查看。在ESXi Shell中,运行如下命令:esxcli-info –e。该命令结果中包含如下信息:

visor-hin:一个安装的host。也包括Auto Deploy部署的有状态安装。

visor-usb:嵌入式host,也包括在USB闪存或SD卡上自己安装的ESXi。

visor-pxe:无状态host,包括以无状态缓存模式交付的。

但是,如果无状态缓存host引导时无法找到Auto Deploy服务器,它就会从本地安装的副本中引导。此时,它的状态是visor-thin。

通常,部署方式的选择取决于部署规模、技术水平和时间要求。WAN拓扑和vCenter的实施也会影响到服务器的部署模式:可能每个vCenter只有一个Auto Deploy服务器,这就限制了无状态主机的部署,或者需要引入更多的vCenter才能满足要求。

调整部署规模

只有少量服务器的小公司很可能选择通过CD引导和常规的交互式安装方式手动安装每个服务器。随着公司的成长,自动化程度的提升,公司可能会考虑通过脚本方式安装。大多数服务器都在一个地方(或者分布在多个地方但WAN网络质量很好)的公司,通过PXE引导服务器集中管理镜像就是个很方便的部署方法。它是和kickstart脚本一起使用的,这样就可以更快更集中的安装了。有vSphere Enterprise Plus授权的大型企业,可以考虑使用自动化的post-install方法,指定初始化配置,并通过host profile策略来维护环境。

如果企业已经有了定制的PXE引导环境,而且积累了很多脚本安装的知识,那么他们很喜欢继续使用这种方式。但是还想从头开始建立自动安装环境。那么最好还是部署一个Auto Deploy基础设施。原则上,用脚本安装的定制PXE引导方式和有状态Auto Deploy部署方式很类似。

但是既然VMware已经提供了解决方案,为什么还要自己定制呢?Auto Deploy解决方案正在快速标准化,而且维护起来还比定制的方案容易得多。当组织需要最大化灵活度并减少部署时间的时候,无状态Auto Deploy部署就是个不错的选择。VMware一直在改进Auto Deploy,一个图形界面的Web配置客户端很快就会面世了,而且其host profiles 特性也随着每个版本的发布逐渐成熟。

不同的方案需要不同的技术。例如,在首要数据中心采用Auto Deploy无状态部署,在管理集群中使用有状态部署,在远程站点部署少量的嵌入式服务器并由外包人员管理,以及在准备发往小办事处的服务器的本地硬盘上部署可安装的host。

对于使用Auto Deploy的大型安装来说,Auto Deploy基础设施是可以扩展的。目前制约因素就是每个vCenter只能有一个Auto Deploy服务器。如果需要更多,那么就要增加vCenter。然后通过SSO服务将它们链接起来,这样才能用一个Web Client服务器(或者链接模式,如果你需要共享license和角色,也可以使用跨WAN链接)一起管理它们。

目前,vSphere 5.1中每个Auto Deploy服务器可以引导大约40个服务器,前提是使用没有VMware工具的简化版ESXi镜像。你应该为最坏的引导风暴场景(比如:断电后的引导)做好准备,并确定上电后应最先引导至少多少个host。你可以在负载均衡器前面增加很多的Web代理服务器,将Web服务负载分发给Auto Deploy服务器,这样能实现更高层次的线性扩展(每增加一个Web代理服务器就可以多引导40个host),但是,最终都会因Auto Deploy服务器的CPU能力而达到极限。和往常一样,只有在环境中测试过才能证明这些措施的有效性。不管Auto Deploy基础设施的规模有多大,你都不能将Auto Deploy服务和vCenter部署在同一个服务器上,因为重启多个服务器的时候,这两个服务的访问量都特别大。

镜像位置的影响

虽然所有的部署方法都在host上产生一个ESXi的运行版本,但是理解最终配置的不同还是很重要的。如果已经有了一些带有硬盘的服务器,且部署规模很小,那么本地磁盘就是个不错的选择。本地硬盘一般很可靠,其安装时有很好的默认配置,不需要安装后再更正什么缺陷或错误了。以最常用的镜像位置(本地硬盘)为例,对比下每个可选硬盘:

可移动硬盘 可移动的引导介质就是USB/SD安装和ESXi嵌入式安装,这两种方式安装后没有scratch分区。如果本地硬盘有VMFS卷,那么ESXi就会使用它来创建scratch目录。如果没有,ESXi就会将scratch目录存储在ramdisk中。最好的方法就是在host的高级设置中将scratch分区指向到远程VMFS卷。此外还可以设置并将syslog服务和转储服务重新定向到远程的syslog和转储收集服务器中。如果安装时不使用U盘或SD卡,那么最好还是买质量高的介质。

不要花了几千美元买服务器,然后拿5美元的引导硬盘来欺骗自己。虽然引导介质故障后服务器不会崩溃,但是还是要尽快更换引导介质并重启服务器。便宜的USB/SD介质用不了多久的。

从SAN引导 从SAN引导有很多优势,比如:可以买到比较便宜的服务器;使用SAN硬盘,具备较强的集中性和故障保护能力;服务器运行时是没有状态的,所以可以替换发生故障的服务器并重新指向SAN LUN。但是它也存在一定的问题,选择此方法时也要充分考虑到:

Boot-from-SAN 配置较复杂,每个服务器都需要单独的光纤结构分区,HBA/CAN的配置也很复杂。

SAN存储通常比本地存储贵,所以额外的SAN硬盘把服务器存储节省下来的费用都耗掉了。

每个服务器都需要分配和管理SAN LUN,为存储团队增加了不少工作量。

大量的VMkernel硬盘I/O交换会影响虚拟机硬盘的性能,因为它们共享的是相同的I/O渠道。

boot-from-SAN配置不支持用微软集群(Microsoft Clustering MSCS或者Failover Clustering故障转移集群)配置的虚拟机

在很多数据中心,从SAN引导的方式还是很流行的,特别是刀片服务器数据中心,但是无可争议,Auto Deploy(特别是vSphere 5.1改进了Auto Deploy之后)对大型的大站点数据中心来说是更好的选择。与ESXi安装的简易性相比,boot-from-SAN的复杂性意味着它不能提供与物理Windows或Linux boot-from-SAN配置同样的价值。

无状态 传统的无状态服务器没有基础硬盘,所有东西都是运行在ramdisk上的,没有可挂载scratch分区和store分区的硬盘。没有机会重新引导到alternate bootbank(虽然通过改变活动的规则集,可以为重新引导提供一个新的镜像)。

点击复制链接 与好友分享!回本站首页
分享到: 更多
您对本文章有什么意见或着疑问吗?请到论坛讨论您的关注和建议是我们前行的参考和动力  
上一篇:2.3.3 Auto Deploy基础设施
下一篇:2.4 升级ESXi
相关文章
图文推荐
2.7.12 使用仿真器查
2.7.11 栈和寄存器组
2.7.8 出栈
2.7.7 压栈
排行
热门
文章
下载
读书

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训
版权所有: 红黑联盟--致力于做最好的IT技术学习网站