初識StarlingX

背景
- 發展歷程
- 願景
組件、架構
- StaringX控制、計算、存儲節點架構及和相關開源項目淵源
- StarlingX組成架構
- 擴展模式
- StarlingX架構技術棧
- Starling X組件架構
- StarlingX未來規劃
Openstack組件
- penstack的組件關係
- Openstack創建虛擬機流程
StaringX主要功能特性
- StarlingX分佈式雲架構：
- 配置管理
- 主機管理
- 服務管理：
- 軟件管理
- 基礎設施編排
- 故障管理
按項目介紹
- Metal
- Cnfig
- Distributed clud
- Fault managent
- NFV
- High Avaliablity
- Sftware updates
- Tols

背景

要說StarlingX，首先要弄清楚其發展的背景，作爲致力於邊緣雲的基礎設施，可以從兩個角度，一個是雲計算的發展，另一個是邊緣計算的發展

雲計算的發展經歷了虛擬化→基礎雲-->雲原生的發展，虛擬化時代的vmware領航着當時的雲發展，通過VMware完成虛擬機資源的統一管理，顯然這種方式有一定侷限，必須採購VMware的商業產品，只能使用VMware虛擬機，性能也比較受限。後來基礎雲階段，openstack出現，將KVM / ESXI / bare-matel 統一管理，並基於此搭建平臺，完成IAAS→PAAS的搭建。

而邊緣計算的發展時間還比較短，大家對邊緣計算的定義還有爭議，但是不影響我們的理解。邊緣計算不僅指端設備的計算，也指邊節點的計算，邊指端雲中間，用於彌補端的計算力不足以及雲延遲的產物。按照業內的定義邊緣計算分物邊緣、移動邊緣、雲邊緣，而StarlingX就是聚焦於邊邊緣的。

補充一下邊緣形態：

所以，總的說來，StarlingX就是提供分佈式邊緣雲的基礎設施的軟件堆棧，

先說說邊緣計算的特點：

聯接性：聯接性是邊緣計算的基礎。所聯接物理對象的多樣性及應用場景的多樣性，需要邊緣計算具備豐富的聯接功能，如各種網絡接口、網絡協議、網絡拓撲、網絡部署與配置、網絡管理與維護。聯接性需要充分借鑑吸收網絡領域先進研究成果，如TSN、SDN、NFV、Network as a Service、WLAN、NB-IoT、5G等，同時還要考慮與現有各種工業總線的互聯、互通、互操作。

數據第一入口：邊緣計算作爲物理世界到數字世界的橋樑，是數據的第一入口，擁有大量、實時、完整的數據，可基於數據全生命週期進行管理與價值創造，將更好的支撐預測性維護、資產管理與效率提升等創新應用;同時，作爲數據第一入口，邊緣計算也面臨數據實時性、確定性、完整性、準確性、多樣性等挑戰。

約束性：計算產品需適配工業現場相對惡劣的工作條件與運行環境，如防電磁、防塵、防爆、抗振動、抗電流/電壓波動等。在工業互聯場景下，對邊緣計算設備的功耗、成本、空間也有較高的要求。邊緣計算產品需要考慮通過軟硬件集成與優化，以適配各種條件約束，支撐行業數字化多樣性場景。

分佈性：邊緣計算實際部署天然具備分佈式特徵。這要求邊緣計算支持分佈式計算與存儲、實現分佈式資源的動態調度與統一管理、支撐分佈式智能、具備分佈式安全等能力。

融合性：OT與ICT的融合是行業數字化轉型的重要基礎。邊緣計算作爲“OICT”融合與協同的關鍵承載，需要支持在聯接、數據、管理、控制、應用、安全等方面的協同。

那麼傳統的雲爲什麼不能直接拿來部署：

Ø定位於集中於IDC機房到服務器集羣的管理，不能適應邊緣雲的分佈式網絡環境
Ø端雲的網絡路徑複雜，延時高（工控、醫療設備），且不穩定（遊戲，直播）
Ø端雲的帶寬有限，大設備量/大數據量下帶寬昂貴（視頻、CDN）
Ø端雲傳輸過程的安全性難以保證，中間遭竊聽、篡改風險
Ø端雲網絡連接情況複雜，難以保證持續連接

Ø邊緣環境惡劣，需要更多考慮高可用、無人值守

全新的場景，新的挑戰，需要有新的解決方案。

於是就出現了StarlingX.

發展歷程

上述是發展背景，從StarlingX的發展歷程看

2018年5月, Intel和風河宣佈將其電信雲/邊緣雲的商業產品Titanium Cloud中的部分組件開源, 命名爲StarlingX, 並提交給OpenStack Foundation管理。

風河Titanium Cloud最初構建在OpenStack等開源組件上, 然後對其進行擴展和加固, 以滿足關鍵的基礎設施需求, 包括: 高可用性、故障管理和性能管理，可用於NFV電信雲、邊緣雲、工業物聯網等場景。

StarlingX是一款高性能的電信雲/邊緣雲軟件, 最初版本代碼基於風河的商業軟件Titanium Cloud R5產品，開源以後代碼採用Apache2許可證。而Titanium Cloud繼續提供商用的邊緣雲解決方案。

願景

將已經經過驗證的雲技術應用在邊緣計算上，然後來發展邊緣計算的管理框架，簡化部署邊緣雲，最後把它應用在交通運輸、能源、製造業、零售、視頻、智慧城市、無人駕駛、醫療衛生等等領域中。我們通過邊緣計算整體去編排中心雲與邊緣雲之間的所有資源。

Ø提供快速部署、伸縮、高可靠的邊緣軟件平臺基礎設施：
l適配已有的雲端技術至邊緣計算場景
l全系統範圍內的自動編排
l集中部署和管理邊緣雲
l簡化分佈式邊緣系統的部署
l事件快速響應
l快速故障恢復

l低延遲

組件、架構

除了OpenStack等開源社區的組件, StaringX項目新增的組件主要有以下6個：

1. 配置管理 2. 主機管理 3. 服務管理 4. 軟件管理 5. 故障管理 6. 基礎設施管理

下面會詳細介紹這六個組件。

另外, StarlingX會對使用到的開源項目, 如: CEPH, CentOS, OpenStack等做增強和擴展, 這些代碼最終將會回饋給社區。

StaringX控制、計算、存儲節點架構及和相關開源項目淵源

StarlingX控制節點的架構，和其他項目淵源關係：

藍色代表由titanium cloud項目創建，starlingx繼承的項目

黃色代表基於開源項目進行少量改動的項目

紅色代表基於開源項目進行大量改動的項目

紫色代表直接引用未做修改的開源項目

StarlingX計算節點的架構及組件關係：

StarlingX存儲節點的架構及組件關係：

StarlingX組成架構

StarlingX的節點/組網結構和普通的OpenStack沒有太大區別。

在標準配置下, 包括:

2個HA的控制節點集羣

* 2-100個計算節點

* 2-9個CEPH (可選)

* 計算節點採用了DVR分佈式路由

* Cinder後端可採用LVM或者CEPH

* Glance後端可採用文件系統或者CEPH

* Swift後端只支持CEPH

擴展模式

單臺服務器部署:

* 控制、計算、網絡、存儲功能部署在同一臺節點上

* 不支持HA

2臺服務器部署:

* 每臺服務器上運行控制、計算、網絡、存儲功能

* 計算、網絡、存儲採用雙機HA方式

多臺服務器部署:

* 2臺HA控制節點集羣

* 2-100臺計算節點

* 2-9臺可選的CEPH存儲節點集羣

* 計算節點上運行DVR分佈式路由

StarlingX架構技術棧

Starling X組件架構

starlingx 與 k8s openstack共同構成了邊緣雲的基礎設施

StarlingX未來規劃

StarlingX 的發展方向：OpenStack容器化、部署在Kubernetes集羣上、基於OpenStack-Helm管理集羣的生命週期。
整合Kubernetes：Docker Runtime、Calico CNI plugin、CEPH作爲持久存儲後端、HELM作爲包管理、本地Docker鏡像倉庫。
支持其他容器化的邊緣應用部署。

Openstack組件

下面從Openstack的角度理解starlingx的組件關係及配合方式

openstack的組件關係

這張圖簡單描述了openstack組件的關係，從高層次的抽象角度看，其實starlingx的組件關係也是類似的

Openstack創建虛擬機流程

這裏還可以看下Openstack創建虛擬機的流程，可以更好的理解其組件間的配合方式：

圖中流程-1

首先你訪問dashboard之後，顯示的是一個登錄頁面，人家horizon告訴你：想用Openstack新建雲主機？那你先把你的賬號密碼交給我，等我找我大哥keystone確認你的身份之後才能放你進去

原來我還一直以爲這裏登錄的時候只是一個簡單的django框架使用pymysql直接查詢數據庫，而實際上這裏的表單信息是提交到了keystone，然後通過keystone查詢數據庫進行驗證的

圖中流程-2

keystone接收到前端表單傳過來的域、用戶、密碼信息以後，查詢了數據庫，確認身份後將一個token（就像是辦了身份證～～～）返回給該用戶，讓這個用戶以後再進行操作的時候不需要再提供賬號密碼，而是拿出token來

圖中流程-3

horizon拿到token之後，實際上這裏在web頁面上的顯示就是登錄成功了，接着找到創建雲主機的按鈕並點擊

填寫雲主機相關配置信息

填了這麼一大堆配置信息，點擊啓動實例之後，horizon就帶着三樣東西去找nova-api了：

　　1.創建雲主機的請求

2.雲主機相關配置信息

　　3.剛剛keystone返回給的token

圖中流程-4

你horizon來找我nova-api辦事可我也不認識你啊，這樣，你把身份證給我，我去找我大哥keystone問問（這些組件都有一個共同的大哥keystone，但他們自己之間卻不認識）。然後他就帶着horizon的token去找keystone

圖中流程-5

keystone一看nova-api帶來的token，這不就是自己剛發的那個麼，但程序可沒這麼聰明，它還得乖乖查一次數據庫，然後告訴nova-pai，這兄弟信得過，你就照它說的做吧

圖中流程-6

nova-api從大哥那回來，接收了horizon提供的兩樣東西，一是雲主機配置信息，二是創建請求，這nova-api手底下也有一幫小兄弟，這幫人之間溝通可不太方便都得通過一塊小黑板（mq消息隊列），把自己的需求寫在小黑板上，能做的了這事的人自然就去做了。但配置信息現在還不能寫在小黑板上，得找到確定去幹活的人之後才行啊，所以nova-api就把配置信息放到數據庫裏

圖中流程-7

數據庫把配置信息收好之後，對nova-api說了聲，我放好了

圖中流程-8

放好配置信息後nova-api就在小黑板上寫“現在要創建一臺雲主機，配置信息我已經放到數據庫了，小s你給安排安排吧”

圖中流程-9

這個小s就是nova-schedular，他就像是nova-api的祕書，nova-api的有事都是通過它交代給其他人的，這一步就是他從小黑板上看到了nova-api的信息

圖中流程-10

小s現在知道了要創建雲主機，但它要看一看雲主機都要什麼配置，纔好決定該把這事交給誰去做（這裏是指多個nova-compute的情況，各個計算節點的資源使用情況都在小s這裏），所以他讓數據庫把雲主機配置信息發給他看看

圖中流程-11

數據庫收到請求之後，把雲主機配置信息發給小s

圖中流程-12

小s拿到配置信息後，使用調度算法決定了要讓nova-compute去幹這個事，就在小黑板上寫“nova-compute你給創建個雲主機，配置都在數據庫裏了”

圖中流程-13

nova-compute看到小黑板上的東西之後，本應該直接去數據庫拿取配置信息，但因爲nova-compute的特殊身份，nova-compute所在計算節點上全是雲主機，萬一有一臺雲主機被黑客入侵從而控制計算節點，直接拖庫是很危險的。所以不能讓nova-compute知道數據庫在什麼地方

圖中流程-14

nova-compute沒辦法去數據庫取東西難道就不工作了嗎？那可不行啊，他不知道去哪取，但他哥們知道啊，於是他在小黑板上寫“nova-conductor，你幫我去數據庫取一下配置信息”

圖中流程-15

nova-conductor從小黑板上看到了nova-compute的請求

圖中流程-16

nova-conductor告訴數據庫我要查看某某雲主機的配置信息

圖中流程-17

數據庫把雲主機配置信息發送給nova-conductor

圖中流程-18

nova-conductor把配置信息寫在小黑板上

圖中流程-19

nova-compute從小黑板上讀取雲主機的配置信息

圖中流程-20

nova-compute拿到了雲主機配置信息一看，人家可是專業的，立馬就知道該怎麼做了，先去找glance-api拿鏡像吧，剛纔講了那麼多，可都是在nova組件內部的，這次去找別的組件可不是寫在小黑板上了，它得帶着自己的身份證去，告訴glance-api，我要xxx鏡像

圖中流程-21

glance-api看nova-compute過來，他可不認識nova-compute，讓nova-compute拿出身份證，拿着人家身份證找到自己大哥keystone看看這人靠不靠譜，keystone一看，沒問題，按他說的做吧（在nova驗證horizon被當做兩步，這裏化做一步，是爲了簡化重複的流程）

圖中流程-22

glance-api把鏡像資源信息返回給nova-compute（這裏主要說創建雲主機的過程，除nova外其他組件內部先不提）

圖中流程-23

接着nova-compute找到neutron-server（圖裏畫錯了，因爲是偷別人的圖，自己的圖畫了半天畫不好。。。），告訴他我要xxx網絡資源

圖中流程-24

neutron-server也不認識他，拿着他的身份證找keystone確認了一下身份

圖中流程-25

nuetron-server把網絡資源信息返回給nova-compute

圖中流程-26

nova-compute找到cinder-api要存儲資源，雲主機得有硬盤啊，得存東西啊（同樣，這裏圖中也有錯誤）

圖中流程-27

cinder-api也不認識他，拿着他的身份證找keystone確認了一下身份

圖中流程-28

cinder-api把存儲資源信息返回給nova-compute

圖中流程-29

nova-compute拿到了所有資源之後，他其實也只是個收集信息的，他把工作全都交給了真正創建虛擬機的Hypervisor（kvm，zen等虛擬化技術）

到此爲止，你已經擁有了一臺雲主機了，流程看似複雜實際上在幾十秒就完成了

StaringX主要功能特性

StarlingX分佈式雲架構：

StarlingX支持分佈式雲，可用來支持邊緣計算場景。其主要功能有:

* 基於OpenStack多region概念

* 中心region通過分佈式管理器(dc-manager)統一對各子云進行管理、配置、故障聚合、軟件升級/patching等

* 邊緣region將會通過3層網絡/REST API和中心region通信

* 邊緣雲運行精簡過的控制平面

配置管理

StarlingX的代碼提供了節點配置以及庫存管理服務，帶有對新節點的自動發現及配置功能，並且管理着大量遠端或者難以訪問的站點。

安裝

* 自動發現新節點

* 管理安裝參數 (控制檯、根磁盤等)

* 通過xml文件批量配置節點

* 具備安裝進度條

資產發現

* CPU/核, SMT, 內存、大頁信息

* GPU, 加解密/壓縮硬件, LLDP鄰居信息

節點配置

* 節點角色, 角色配置

* CPU核, 內存(包括大頁)分配, dpdk

* 網絡接口和存儲配置

* 批量節點配置

用戶界面

* 支持REST API, Horizon界面和命令行

另外, 可通過puppet進行配置

主機管理

StarlingX軟件提供生命週期管理功能，通過一個REST API接口管理主機。這種與供應商無關的工具可以檢測主機故障並且通過爲集羣的連接，關鍵進程故障，資源利用率閾值以及硬件故障提供監控和警報的方式來啓動自動修復。這個工具還與主板管理控制器連接，用於輔助復位（out-of-band reset），電源開/關機以及硬件傳感器監控，並與其他的StarlingX組件共享主機狀態。”

* 管理主機的生命週期

* 自動發現主機故障, 並恢復

* 監控、告警和恢復。包括: 網絡連接、進程問題、接口狀態、資源利用率、硬件故障、主機看門狗等等

* 主機帶外重啓、上電、下電、硬件傳感器監控

* 發佈主機狀態給其它組件

* 可通過REST API進行主機管理

服務管理：

通過基於跨多個節點的N + M或N等冗餘模型來提供高可用性，實現提供服務的生命週期管理。這項服務支持使用多個消息傳遞路徑來避免腦裂（split-brain）通信故障，以及支持使用主動或被動監視，通過完全數據驅動的體系結構來明確定義服務故障的影響。

軟件管理

這項服務允許用戶使用適用於從內核到OpenStack服務的所有基礎架構堆棧的一種一致性機制，來部署糾正內容和新功能的更新。這個模塊可以完成滾動升級，包括並行化和對主機重新啓動的支持，允許通過使用實時遷移將工作負載從節點移出。

* 提供軟件升級功能

* 可以對整個軟件的各層次升級/打補丁, 從kernel層一直到openstack的各服務層

* 所有節點軟件可以並行更新

* 已在線的服務如果打了patch需要進行重啓

* 提供詳細的補丁狀態信息, 包括節點層和系統層

* 支持滾動升級(Rolling Upgrade)

* 自動處理數據庫schema變更和轉換

* 提供REST API, Horizon界面和命令行

基礎設施編排

* 管理和編排VM HA能力

* 自動恢復故障虛擬機實例

* 生成實例告警和日誌信息

* 可對節點的軟件升級和打補丁進行編排

* 支持REST API, Horizon界面和命令行

故障管理

用戶即可以在基礎架構節點上，也可以在諸如虛擬機和網絡等虛擬資源上設定，清除或者查詢爲重要事件自定義的報警以及日誌。用戶可以在Horizon的圖形用戶界面上訪問主動報警列表（Active Alarm List）以及主動報警計數面板（Active Alarm Counts Banner）。

* 提供一個故障管理的框架軟件服務

* 可通過客戶端/REST API對故障管理軟件進行配置、清空、查詢告警、日誌等事件。並可通過SNMPv2c Trap進行信息發佈

* 可在Horizon界面上顯示告警信息列表

* 故障信息覆蓋: 節點、虛擬機、網絡、存儲等等

按項目介紹

Metal

The StarlingX Metal project is a new repository that manages the lifecycle, operation, and administration of the Host. StarlingX Metal also provides Host fault monitoring, alarms, and initiates fault recovery.

New Features¶:

Manages the life cycle of the Host.

Detects and automatically handles host failures and initiates host recovery.

Monitors, Alarming, and Recovery for the following:
- Cluster connectivity.
- Critical process failures.
- Resource utilization thresholds.
- Interface states.
- H/W fault / sensors.
- Host watchdog.
- Activity progress reporting (e.g. booting, testing).

Provides an interface with board management (BMC) for out-of-band reset, power-on/off, and H/W sensor monitoring.

Publishes the Host’s state with other StarlingX components.

Exposes a set of administrative commands for the user to manage the Host through REST API:
- Lock/unlock, reboot, reset, re-install, SWACT.
- Out-of-band via BMC: Reboot, reset, power on/off.

Config

The StarlingX Config project is a new repository that provides the following:Host Installation.Inventory Discovery.Host Configuration, which moves to Host Management in future.System-level Configuration.Configuration of StarlingX Platform Services.API, Horizon and CLI services for all Main Components.Configuration for various services in StarlingX.

New Features¶

Installation:
- Auto-discover new nodes.
- Manage installation parameters (i.e. console and root disks).
- Bulk provisioning of nodes through xml file.
- Installation progress indicators.

Inventory Discovery:
- CPU/cores, SMT, processors, memory, and huge pages.
- Storage, ports.
- GPUs, crypto/compression H/W, and LLDP neighbor information.

Nodal Configuration:
- Node role and role profiles.
- Core and memory (including huge page) assignments.
- Network Interfaces and storage assignments.
- Bulk configuration of nodes through system profiles.

User Interface:
- REST API, Horizon GUI, and “system” CLI commandsuite.

Distributed cloud

The StarlingX Distributed Cloud project is a new repository. It supports an edge computing solution by providing central management and orchestration for a geographically distributed network of StarlingX systems.

Fault managent

The StarlingX Fault project is a new repository that provides Alarm and Log Reporting Services for other StarlingX Components.

New Features¶

Framework for infrastructure services through a client API to do the following:
- Set, clear, and query customer alarms.
- Generate customer logs for significant events.

Framework to maintain an Active Alarm List.

Active Alarm Counts Banner on Horizon GUI.

Framework to provide REST API to query alarms and events and also publishes through SNMPv2c Traps.

Support for Alarm suppression.

Operator Alarms on the following:
- Platform Nodes and Resources.
- Hosted Virtual Resources (i.e. VMs, Volumes, and Networks).

Operator Logs - Event List:
- Logging of Set/Clears of Alarms.
- Related to Platform Nodes and Resources.
- Related to Hosted Virtual Resources (i.e. VMs, Volumes, and Networks).

NFV

The StarlingX NFV project is a new repository that provides High Availability management of VMs and Software Patching & Upgrade Orchestrator Services.

New Features¶

Responsible for managing and orchestrating the VM carrier grade and high availability capabilities,

Auto-healing of failed instances

Orchestrates guest API actions

Raising and clearing operator alarms about instances. Generating operator logs about instances

Orchestrates the migration of instances off compute hosts being taken administratively out of service

Orchestrates software patching and upgrades of hosts

High Avaliablity

The StarlingX HA project is a new repository that provideds High Availability Cluster Management for StarlingX and OpenStack Services on Controllers.

New Features¶

High availability manager to manage the life cycle of services where the redundancy model can be N+M or N across multiple nodes:
- Currently used in StarlingX to provide 1+1 HA Controller Cluster.

Configured to use multiple messaging paths to avoid split-brain communication failures:
- Up to 3 independent communication paths.
- LAG can also be configured for multi-link protection of each path.
- Messages are authenticated using HMAC SHA-512 if configured / enabled on an interface-by-interface basis.

Active or passive monitoring of services.

Allows for specifying the impact of a service failure.

Completely data driven through the configuration of a SQL database.

Software updates

The StarlingX Update project is a new repository that provides Software Patch (bug fix) management and deployment, and also Software Release Upgrade management.

New Features¶

Provides the ability to deploy software updates for corrective content and/or new functionality

Consistent mechanism for patching all layers of the infrastructure stack – kernel all the way up to the openstack services layer

Rolling update strategy across nodes
- Nodes can be updated in parallel when constraints are not violated

In-service and reboot required patches supported
- Reboot required for kernel replacement etc.
- For patches that require a reboot, VMs are live migrated off of node

Comprehensive patch status at node and system level

REST API, Horizon GUI and “sw-patch” CLI command suites

Tools

These release notes cover the initial release of StarlingX. The StarlingX Tools project is a new repository of tools used in the development, build, test and release of StarlingX.

New Features¶