基于Citrix XenSever的虚拟化基础架构搭建之小试牛刀
Posted 往往Tech
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了基于Citrix XenSever的虚拟化基础架构搭建之小试牛刀相关的知识,希望对你有一定的参考价值。
Hello Every巴得,”往往”上次发布了一往篇“IT基础架构之存储篇初体验”之后,大伙儿已经等了N天了,因为”往往”近来很,累成狗矣,千呼万唤始出来“基于Citrix XenServer虚拟化的应用场景”的场景终于搭好了差点喷出二俩鲜血,”往往”秉持着为大家带来点儿小干货,共同学习,一起成长,有老鸟请不吝赐教!
话说盆友多鸟路好走,希望通过这个小平台认识更多知友,共享更多的经验,带来更多的可能。这时候看官们都火大了,费话了这么久能不能快点切入topic?往往差点儿吓尿,赶紧的拿点儿东西出来,搬砖中........ing.........
PS:之前接到某些朋友反馈说黄色字体阅读起来有些累,这次就换个蓝色的try try look,若有不对大家继续拍砖反馈吧,跪谢!
Firstly问:虚拟化应用场景都使用哪些牛X的Hypervisor?
往往(弱弱的)答:
VMware,这货无疑是虚拟化市场上的霸主,他们的研发与市场领导力地位自然不用多说他们的产品比较多。大家用得比较多的有基于个人PC简单易用的VMware Workstation。相信无数的人都使用至今感觉还是很良好的吧。再说说他们家比较牛逼的VMware vSphere套件,vSphere 是VMware公司推出一套服务器虚拟化解决方案。其中核心的Hypervisor就是ESXi,要实现虚拟化,那服务器(物理主机)上首先就得安装ESXi它是一款可以独立安装和运行在祼机上的系统。
PS:VMware公司的一个大股东是EMC,这家做存储的公司还是挺强悍的,8过前段时间被Dell下血本花670亿美刀收购EMC,所以他们的关系大伙儿自然就知道了,相今天在不久的将来,Dell+EMC+VMware就能出各种Totally solution,不过IT环境的成熟与商业壁垒的解除,无论使用哪种组合相应都能找到不错的解决方案,并非只有某一世无霸才能吃四方。
Citrix,他们家的XenServer在市场上使用者还是很多滴,他们的功能和VMware ESXi是相同的,市场占有率和研发上比VMware要逊色些,8过丝毫没有阻挡大家使用他的热情哦,功能上就不再赘述了吧。另外大家知道XenDesktop是他们家比较拿得出手的桌面虚拟化套件,再说说VDI(Virtual Desktop Infrastructure)对于劳动密集型企业批量使用统一管理维护还是很方便的,整体TCO还是有不错的产出,大伙儿想想,瘦终端(Thin Client)就是个无脑输出的盒子,所有的计算存储资源都放到后端虚拟化系统上,这样只需要极少的维护成本即可实现统一管理与维护,而不用雇很多Helpdesk guy去天天维护终端吧,TC不好了直接换,数据有问题后端直接重置,想想这是多么美好的事情。
Microsoft Hyper-V,这是微软自家研发的Hypervisor,自然无缝的与他们家Windows系统完美的集合,对于承载Linux的VM貌似支持不太好,毕竟Linux与Windows是两大阵营,支持不好更多的是出于商业考量而非技术难题。8过近年来他们也将Ubuntu Bash集成到Windows上面可以直接使用,Hyper-V也开始支持Redhat Enterprise之类的Linux,说明微软他们也是在慢慢的顺应市场需求作出了更多明智的选择,大伙儿都知道要让一个巨无霸改变他们的战略,遇到的阻力可想而知。随着近年云计算的发展趋势成为必然,Microsoft这样的实力玩家在造势铺他们的Azure cloud,”往往”本人坚信未来无数的云厂商中Azure必然是前五名之一的Player。
KVM, ( Kernel-based Virtual Machine) 他是 Linux系统上基于x86 硬件平台上的全功能虚拟化解决方案,个人感觉他们的UI做得比较丑,不过不要米而且很适合高度DIY的IT技术宅,高度定制化,基于CLI的操作和批量执行还是很方便,是个不错的选择哦。但相较于前面几种Totally solution的话,要在生产环境部署上对运维技术宅的要求还是比较高的。许多基于公有云、私有云部署OpenStack+KVM的模式已经在市场上占有相当大的比重。
OpenVZ,基于Linux平台的操作系统级服务器虚拟化解决方案。OpenVZ采用SWsoft的Virutozzo虚拟化服务器软件产品的内核,Virutozzo是SWsoft公司提供的商业虚拟化解决方案。如果要try一把他们如何使用可以安装个Proxmox的虚拟化套件,内部直接集成了KVM与OpenVZ,使用起来还是比较方便的,个人感觉应用场景比较适合内部测试或者对SLA要求不太高的地方。
2问:说了辣么多虚拟化的介绍,那能不能挑一种比较典型的部署架构让咱们get个方案,让大伙儿看看?
往往(很严肃的)答:本次就介绍基于Citrix XenServer的Infrastructure方案介绍:
(a) 先介绍此方案的架构先决条件:本次使用6台机架服务器,每台4个10GbE的NIC卡,服务器网卡的分配规则,业务与管理网卡连接到核心3层网络交换机,后端基于10GbE的NIC连接IP-SAN的共享存储,那么大致拓扑如下:
Server |
NICs |
MGMT IP |
Trunk/Access |
Bond NIC |
Functions |
XenSvr01 |
NIC0 |
10.10.10.111 |
Access |
NIC Bond |
MGMT+IP-SAN |
NIC1 |
|||||
NIC2 |
Trunk |
NIC Bond |
VM network(Vlan tag) |
||
NIC3 |
|||||
XenSvr02 |
NIC0 |
10.10.10.112 |
Access |
NIC Bond |
MGMT+IP-SAN |
NIC1 |
|||||
NIC2 |
Trunk |
NIC Bond |
VM network(Vlan tag) |
||
NIC3 |
|||||
XenSvr03 |
NIC0 |
10.10.10.113 |
Access |
NIC Bond |
MGMT+IP-SAN |
NIC1 |
|||||
NIC2 |
Trunk |
NIC Bond |
VM network(Vlan tag) |
||
NIC3 |
|||||
XenSvr04 |
NIC0 |
10.10.10.114 |
Access |
NIC Bond |
MGMT+IP-SAN |
NIC1 |
|||||
NIC2 |
Trunk |
NIC Bond |
VM network(Vlan tag) |
||
NIC3 |
|||||
XenSvr05 |
NIC0 |
10.10.10.115 |
Access |
NIC Bond |
MGMT+IP-SAN |
NIC1 |
|||||
NIC2 |
Trunk |
NIC Bond |
VM network(Vlan tag) |
||
NIC3 |
|||||
XenSvr06 |
NIC0 |
10.10.10.116 |
Access |
NIC Bond |
MGMT+IP-SAN |
NIC1 |
|||||
NIC2 |
Trunk |
NIC Bond |
VM network(Vlan tag) |
||
NIC3 |
(b) 架构方案的拓扑说明:
- 每台服务器NIC0连接到核心堆叠交换机A,NIC1连接到核心堆叠交换机B
- 每台服务器NIC2连接到IP-SAN交换机A,NIC3连接到IP-SAN交换机B
- 两台核心交换机做堆叠群集,在逻辑上看作是一台交换机,提高高冗余性与简化生成树(STP)配置
- 后端一台IP-SAN存储设备,提供给6台服务连接共享存储
(d) 安装XenCenter
- 从Citrix的官方网站下载对应的版本
- 从安装好的XenServer服务器上下载(本地下载)
- 下载好后打开安装包进行本地安装,基于windows的客户端
安装好以后运行XenCenter即可看到上面的画面,接下来要干嘛呢,就是添加刚才已经安装好的6台服务器,点击ADD a server直至把所有的服务器都添加XenCenter中会看到如下场景,6台服务器已经成功的躺在XenCenter中了,但他们现在还不是一个群集哦,所以呀要实现冗余集群功能请继续往下戳哦
(e)创建XenCenter群集
(f)配置服务器网络
按照前面我们服务器的规划将NIC0、NIC1做一个捆绑(Bond)提供IP-SAN与管理网络服务,同时捆绑两块物理网卡为一个边辑通道可以实现冗余与自动切换功能;将NIC2、NIC3做另外一个捆绑提供给所有VM网络使用,这样IP-SAN流量与VM的业务流量便可以在物理上分开互不干涉独立管理
通过上面两个Bond的创建,现在我们得到了两个逻辑的网络,为了便于好记我们给两个Bond重命名为:Bond 0+1(MGMT&IP-SAN)、Bond 2+3(VM Network),最终改好后就变成如下这样咯
看到上面的各种ISO文件是已经通过CIFS已经挂载好了,如果后续要安装VM的OS需要使用到这些image哦。
(h) 挂载IP-SAN后端存储
(i) 开启所有XenServer主机的多路径功能功能(MPIO),此处我只示范了一台如何操作,其余5台以此类推,当Master主机需要进入维护模式去开启MPIO时,要求切换到新的Master上,只需要切换至非维护模式的主机上即可,完成MPIO配置后可以通过再次切换回原有的Master主机上即可,废话不多说,看图说话吧。
(j) 创建VM
通过以上对此套标准的IP-SAN存储基础架构的建设就算基本完成了,接下来就是开始建立VM了。不过嘛按照多业务场景划分,很多VM是属于不同的VLAN网络的,所以根据业务而定,需要在分配给VM使用业务网络的NIC卡上做VLAN的Tag,以映射给不同的VM使用,实现网络流量的隔离与权限分配,操作极其easy,所以上个简单的图,以此类推即可。
以上的VLAN可以建N个,根据业务需求来决定,接下来开始建VM咯,走起!!!
以上就是整个VM的创建过程,点击VM切换到Console按钮即可进行VM的控制台操作,接下来安装VM的OS就不用再赘述了吧,相应各位很快就能上手哦。
(k) 配置XenCenter的HA
要想现实VM及整个集群高可用,防止单点故障,那么配置HA是相当有必要的哦,话说HA是啥玩意---High Availability就是高可用啦!配置上图来几张。
通过定义当部分XenServer主机故障或网络出现问题后,其承载的VM即可实现自动的迁移到其它主机上,从而保障业务的连续性运行,定义各种启动顺序与启动级别根据业务需求与优先级做适当调整即可。
(l)克隆VM
通常往往使用的是Full Copy,就是说是个独立的VM配置资源与映射文件,这样个人感觉安全性会比较高一些(或许这只是个心理安慰吧,哈哈)。
3问,如何在线迁移VM?
往往(快速)答:当你发现某台XenServer的物理资源使用率过高,那么可以通过将其承载的VM上右击选择vMotion即可将VM在线迁移至其它XenServer上,这个过程通过会使用网络丢3个包左右,因为在线迁移实际上就是将VM当前的状态完全拷贝到一份,最终完成一次资源接管,所以会短暂的丢包哦。
PS:如果VM上跑了很多动态资源基于session的校验,那么在线迁移这个session会失效,意味着应用可能会短暂的重新进行TCP3次握手建立会话,如果是应用也采用HA的部署那可能不会出现这个问题,希望对各位看官有所帮助。
4问,IP-SAN与FC-SAN他们究竟谁强?
往往(犹豫的)答:各有所长,如果都站在10Gbps的IP-SAN与8Gbps的FC-SAN比的话,标测环境下可能前者还有些优势。两种传输数据的方式存储差距,一种是基于block级,另一种是通过协议转换,各有各的实现方式。通常来说IP-SAN可以应用到比较简单压力小要求不高的环境,同时成本也比较低廉接受程度高,基于IP的网络接入方便简单门槛低。而FC-SAN是独立的第2网,独立于IP网络,扩展与易用性难以整合,不过传输的稳定与市场的验证得到了比较好的证实,投入成本与准入门槛相对比较高。根据应用场景可以将高要求的生产环境使用FC-SAN,而将DR站点配置为IP-SAN,这样可以兼备两种的距离与性能的优势,各位看官可根据自己的budget去权衡吧。
“往往”本人发布个小文章,还有很多不完善,还望各路朋友拿起你们的双手,果断给予评论,不要手软,这样能让往往有更加有动力哦,谢谢大家。
如果你有对本文有任何疑惑或需求的,请联系“往往Tech”邮箱:WangWangTech@gmail.com
“往往”只要有时间会尽快查阅并及时给予回复的,还请看官静待佳音哦!
如果你觉得“往往Tech”还不错,那就用你的大姆指长按下面这个二维码,这样就可以关注了哦!
以上是关于基于Citrix XenSever的虚拟化基础架构搭建之小试牛刀的主要内容,如果未能解决你的问题,请参考以下文章
Vmware 后台下Citrix Xendesktop 7.6实战篇之一 基础架构介绍