增強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

【註：規格與價格由廠商提供，因時有異動，正確資訊請洽廠商】