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

在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

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