增强NFV应用提升混合云整合红帽OpenStack迈入11版

社会动态2021-03-09 08:07:08
最佳答案

在2017年2月底,OpenStack推出第15个版本Ocata,几个月后,于美国波士顿举行的OpenStack高峰会上,Red Hat很快也基于这个OpenStack版本,而宣布推出了Red Hat OpenStack Platform 11。

这个版本当中,Red Hat强化了OpenStack系统升级的相关支援机制,当中可延伸至组装式系统角色(Composable Roles),并提供新的网路功能,另外,对于整合Red Hat CloudForms这套混合云管理软体平台的部分,也有所改良,提升控管云端环境的能力。

以Red Hat OpenStack Platform的系统架构而言,主要是建立在该公司所长期发展的企业级Linux作业系统——Red Hat Enterprise Linux之上,搭配OpenStack社群所开发出来的程式码,同时经过该公司的测试、认证而成。而这套可用来架设云端基础架构即服务(IaaS)环境的平台,现在也包含了Red Hat CloudForms,能够用来协助简化整个IaaS的日常管理工作,以及维运相关作业。透过它,企业可以取得混合云环境的管理与监控能力,扩大掌握範围,能够涵盖到上层执行的应用系统工作负载,而不只是针对OpenStack基础架构的元件。

除此之外,Red Hat OpenStack Platform 11也仍然紧密整合Red Hat Ceph Storage,而能提供软体定义的储存服务,同时,可在OpenStack运算节点使用,提供主机托管(co-location)功能。这个版本的OpenStack还正式推出了储存镜射(storage mirroring)的保护机制,能够简化不同站点之间的资料远端複製作业,增进储存服务的灾难复原能力。

针对私有云IaaS服务与电信业环境的网路功能虚拟化应用,Red Hat OpenStack Platform在今年推出的第11版里面,已经提供了许多特色,而在接下来发布的版本当中,红帽也预告了发展方向,令人期待。例如,第12版将提供容器化OpenStack、完整支援OpenDayLight,第13版之后,可在OpenShift环境部署容器化OpenStack,以及运用远端複製技术的储存延伸丛集。

强化系统升级功能

改善整体系统的升级方式,一直是许多OpenStack用户所关注的重大议题,在Red Hat OpenStack Platform 10首度提出了组装式系统角色的功能,负责维护IaaS服务系统运作的人员,可藉此对不同的服务与处理程序,自定对应的组态,以符合各自的独特需求。有了这项机制之后,也让维运人员能够随时针对个别的服务项目,进行规模扩展与管理作业,而非以整个云端环境来处理,如此一来,可大幅提升维运效率,也使得企业能够更容易去自定OpenStack的部署,以便在大规模使用的状况下,适应不同的需求。

Composable Roles本身整合了许多服务,能够一起部署到Red Hat OpenStack Platform的Overcloud元件上,原本Red Hat OpenStack Platform预设有5个角色——控制器、运算、区块储存、物件储存、Ceph储存,可因应大部分情境上的架构设计,每一个服务都可以在Composable Roles当中,透过个别的OpenStack Heat範本来定义,以此提供标準作法,确保服务实作出输入参数与输出数值的基本套装形式。採用了这样的方法之后,所有的服务範本将能够更容易搬移,或是组装到自定的角色当中,因而能够在服务的放置与管理上,带来更大的使用弹性。

而上述这项组装式角色的机制,在系统平台本身升级到Red Hat OpenStack Platform 11时,也会面临挑战,而Red Hat在新的OpenStack版本上,特别提供了自定角色的升级功能,让Red Hat OpenStack Platform在进行部署与升级工作的过程中,在保留系统整体生命週期管理的重要层面时,也能具备更强大的适应能力,并能维持一致性。

此外,OpenStack的服务也能个别进行自定与指派,维运人员可将资料库、代理伺服器或讯息服务等元件,根据它们独有的需求而置放在特定的节点上执行。而这部份功能,将包含了组装式角色的后部署机制(post-deployment),可于正在运作中的云环境当中执行,如此将为企业或云端服务供应商,提供更多使用弹性,增加云端服务业务支援能力。

在先前没有Composable Roles时,若要管理系统升级的作业,都是需要透过大量、複杂的程式码来帮忙,来确保所有的步骤正确执行,然而,现在可以将服务解构到更小、标準化的模组之后,升级的逻辑能移到庞大、複杂的指令码之外,然后,直接置入服务範本里面。

而这部分之所以能够实现,主要是因为升级程序经过完整重构,放到基于Ansible程式码的模组化片段(modular snippets),而这样一来就可以由OpenStack Heat来进行整合与资源调度指挥。在这样的配置下,每一个服务的範本都会有一套剧本(Ansible plays),来处理升级的步骤与动作,而当中的每一套Ansible plays,都会有套用标籤的数值,让OpenStack Heat能够跨到程式码里面,执行精确与可控的顺序。整体而言,这跟Puppet的方式,以及在每一个服务範本的输出部分所用的step_config一样,都是基于相同的方法而成。

上图是Red Hat OpenStack Platform director的发展蓝图,主要是针对部署框架、升级与容器的应用,提供相关功能,红帽在当中列出最新版本(11)及之后3个版本的规画。以组装式服务与自定角色为例,目前已提供升级的功能,在第12版之后,将会更为成熟,可提供组装式更新的功能。

 

延伸网路服务与网路虚拟化应用

在网路服务的扩展与网路功能虚拟化的支援上,Red Hat OpenStack Platform 11也增设了几项新功能,能够针对资讯与通讯服务供应商环境的需求,协助他们能够处理超大型的网路服务工作负载。

例如,新版Red Hat OpenStack Platform在虚拟机器的使用上,能够完整支援VLAN感知的机制(VLAN-aware VM)——这些在OpenStack上执行的虚拟机器,一旦部署到Open vSwitch(OVS),或是OVS Data Plane开发套件(OVSDPDK)上,就能够传送与接收VLAN封装的流量。

实际上,VLAN-aware VM就是Openstack Neutron里面的Trunkports,这是让OpenStack实例在单一虚拟网路介面(vNICs)上,能够支援VLAN标籤讯框(VLAN tagged frames)的作法。有了这项技术之后,维运OpenStack的人员仅需透过少量的虚拟网路介面,即可存取多个不同的网路,不必针对每一个网路都配置一张虚拟网路介面。

图中是OpenStack里面所使用的Trunkport运作架构,在同一台运算节点里面,可将OpenStack实例里面所配置的多张网路介面,汇聚到一张虚拟网路介面,并予以封装,接着,以此连接到实体的网路介面,并使其成为主网路埠(Parent port),之后分别连至不同的子网路埠(subport)或网路。

而且,透过在API里面启动Trunk,能界定出主网路埠和子网路埠、其他网路之间的连结。此外,在OpenStack实例与网路节点之间,也会再重新对应(remap)相关封装

而这种在主网路埠之外,另行区隔出子网路的方式,可让Neutron将主网路埠的用途转换为虚拟的连结汇聚埠(virtual trunk),子网路埠则是各自拥有专属的区段代号,之后,维运人员可将这些埠直接配置到不同的VLAN。

Red Hat OpenStack Platform 11另一个新的网路应用特色,则是升级使用新版的OVS(2.6版)和DPDK(16.11版),促使OpenStack环境取得更多网路通讯的相关功能,相对地,也协助採用这套OpenStack版本的服务供应商,提升他们在云端服务环境当中的网路传输效能。

OVS 2.6的主要进展,在于针对网路功能虚拟化的部署,打好效能与虚拟网路应用的基础,尤其是在OVSDPDK部署空间的层面,并且支援开放式虚拟网路(Open Virtual Network,OVN)的架构。

而DPDK 16.11的部分,则是对于openvswitch-dpdk的部署,添加了非统一记忆体存取(NUMA)的感知机制,虚拟主机装置(Virtual host devices)所涵盖的多种型态记忆体,现在也能够配置到同一台实体节点上。

至于上述所谓的Ceph的主机托管功能,是指Ceph的物件储存系统服务(Object Storage Daemons,OSD),现在可直接在OpenStack运算节点执行,如此能降低建置成本与工作负载运作的複杂度,并且减少储存I/O需求,以及OpenStack部署时需要架设的节点总量,硬体也不必为了储存系统的专属需求而个别建置,可运用OpenStack本身的运算节点来提供服务,之后若要横向扩展使用规模,也会变得比较便利,而且在单一OpenStack环境当中,企业就能横跨不同的伺服器硬体与网路技术,同时进行工作负载与部署架构的最佳化。

在目前的Red Hat OpenStack Platform里面,在部署Ceph主机托管时,可透过director的自定角色来进行操作,维运人员若要执行更细部的部署,例如运用SR-IOV加速伺服器虚拟化环境存取网路的技术,相关的作法也更为容易,Red Hat也提供说明文件与参考架构。

值得一提的是,这样结合OpenStack与Ceph的使用方式,Red Hat称为超融合基础架构(Hyper-converged Infrastructure,HCI),并且分为纯HCI和混合HCI等两种作法。

Red Hat OpenStack Platform与Ceph Storage之间的整合运用,将更为密切,以第11版而言,已经能够做到横向扩展Ceph节点、提供可担当服务重任的超融合架构,未来将继续强化这两个部分,并且设法使Ceph储存服务能够容器化。

增强混合云管理能力

对于整个云环境的管理,Red Hat OpenStack Platform 11在整合Red Hat CloudForms的部分有所改善,在Red Hat OpenStack云端服务的日常维运作业上,可因应更多的管理需求。

举例来说,CloudForms对于OpenStack汇聚的多个分区(regions)、网域(domains)、主机(hosts),能够进行存取与控管,以更为单一的视野,掌握整个云端服务的健康状态与运作效率。

而在储存服务与资源的管理上,也有所强化。CloudForms现在可执行Volume快照的相关维运作业,像是建立、列举、删除,藉此增进云端平台的储存管理效率。

Red Hat Cloudforms能同时管理多种私有云平台,像是OpenStack、Red Hat Enterprise Virtualization,以及OpenShift,而在搭配Red Hat OpenStack Platform时,可存取、控管OpenStack的分区、网域与主机。

产品资讯

Red Hat OpenStack Platform 11

●原厂:Red Hat(02)7743-2972
●建议售价:厂商未提供
●版本基础:OpenStack Ocata
●环境建置最低需求:Director、Compute node、Controller node各1台
●主机软硬体需求:8核心64位元x86处理器、16GB记忆体、40GB硬碟空间,需安装Red Hat Enterprise Linux 7.3

【注:规格与价格由厂商提供,因时有异动,正确资讯请洽厂商】

免责声明:本文由用户上传,如有侵权请联系删除!