OpenStack 作為開源雲端平臺,其核心元件 Keystone、Glance 和 Nova 分別負責身份管理、映像服務和計算資源管理,構成了雲端基礎設施的基本。然而,雲端架構固有的延遲特性對物聯網等實時應用造成挑戰,促使邊緣計算的興起。邊緣閘道器作為橋樑,連線雲端和不相容 IP 協定的物聯網裝置,降低延遲並提升響應速度。OpenFog 參考架構提供了一個分層模型,從邊緣感測器到應用服務,促進雲端和邊緣計算的融合,並定義了不同層級的協作和資料交換標準。

OpenStack的核心元件

OpenStack的核心元件包括Keystone、Glance、Nova等。Keystone是身份管理服務,負責使用者認證和授權。Glance是映像服務,提供虛擬機器管理的核心功能。Nova是計算資源管理服務,負責識別和分配計算資源,並控制系統的虛擬機器和容器。

Keystone - 身份和服務管理

Keystone是OpenStack的身份管理服務,負責建立使用者認證和登入授權。它維護了一個中央目錄,記錄使用者和其訪問許可權。Keystone可以與LDAP等服務進行介面,以提供企業級別的目錄管理。它還維護了一個令牌資料庫,為使用者提供臨時令牌,類似於Amazon Web Services(AWS)建立的認證。

Glance - 映像服務

Glance提供了OpenStack虛擬機器管理的核心功能。它是一個RESTful服務,允許客戶開發虛擬機器範本,發現可用的虛擬機器,克隆映像到其他伺服器,註冊虛擬機器,甚至在不中斷的情況下將正在執行的虛擬機器遷移到不同的物理伺服器。Glance支援不同的虛擬映像格式,包括raw、vhd、vmdk、vdi和iso等。

Nova - 計算資源管理

Nova是OpenStack的計算資源管理服務,負責識別和分配計算資源,並控制系統的虛擬機器和容器。Nova可以與多種虛擬機器監視器(如VMware或Xen)合作,或者管理容器。隨著需求的變化,Nova可以動態擴充套件或縮減計算資源。

雲端和霧計算拓撲

OpenStack的架構是由多個元件組成的,每個元件都有其特定的功能。這些元件透過Advanced Message Queueing Protocol(AMQP)訊息佇列進行通訊,具體使用RabbitMQ或Qpid。這種通訊方式允許元件之間的解耦,從而實現雲端環境中的動態擴充套件和縮減。

在OpenStack中,所有的通訊都透過AMQP訊息佇列進行,這使得客戶端和伺服器之間完全解耦。這種解耦使得伺服器可以動態擴充套件或縮減,從而提高了雲端環境的靈活性和可擴充套件性。

OpenStack 基礎架構管理

OpenStack是一個開源的雲端運算平臺,提供了一系列的工具和服務來管理和控制雲端基礎架構。其中,Nova是OpenStack中的計算服務,負責管理和控制虛擬機器的生命週期。

Nova 的 RESTful API

Nova提供了一個RESTful API,允許使用者透過HTTP請求來控制和管理虛擬機器。例如,想要獲取虛擬機器列表,可以使用GET請求:

GET {your_compute_service_url}/servers

想要建立一個新的虛擬機器,可以使用POST請求:

POST {your_compute_service_url}/servers
{
  "server": {
    "name": "IoT-Server-Array",
    "imageRef": "8a9a114e-71e1-aa7e-4181-92cc41c72721",
    "flavorRef": "1",
    "metadata": {
      "My Server Name": "IoT"
    },
    "return_reservation_id": "True",
    "min_count": "10",
    "max_count": "20"
  }
}

Nova會響應一個reservation_id:

{
  "reservation_id": "84.urcyplh"
}

Nova 的狀態管理

Nova使用一個資料庫來維護虛擬機器的狀態。虛擬機器的狀態可以包括:

  • ACTIVE:虛擬機器正在執行
  • BUILD:虛擬機器正在被建立
  • DELETED:虛擬機器已經被刪除
  • MIGRATING:虛擬機器正在遷移到新的主機

Nova 的排程器

Nova使用一個排程器來確定哪個任務需要被執行和在哪裡執行。排程器可以使用隨機的方式來分配任務,也可以使用過濾器來選擇最適合的主機。

OpenStack 的過濾器

OpenStack提供了一系列的過濾器來允許使用者自定義的方式來分配虛擬機器和服務。過濾器可以根據不同的引數來選擇最適合的主機,例如:

  • RAM大小
  • 磁碟容量和型別
  • IOPS級別
  • CPU配置
  • 群組親和力
  • CIDR親和力

Swift 和 Neutron

Swift是一個物件儲存系統,提供了一個冗餘的儲存系統來儲存OpenStack資料中心的資料。Neutron是一個網路管理和VLAN服務,提供了一系列的網路服務,例如:

  • 域名服務
  • DHCP
  • 閘道功能
  • VLAN管理
  • L2連線
  graph LR
    A[Nova] -->|RESTful API|> B[虛擬機器管理]
    B -->|排程器|> C[主機分配]
    C -->|過濾器|> D[虛擬機器分配]
    D -->|Swift|> E[物件儲存]
    E -->|Neutron|> F[網路管理]

圖表翻譯:

此圖表展示了OpenStack中的Nova、Swift和Neutron之間的關係。Nova提供了一個RESTful API來管理虛擬機器,排程器負責分配虛擬機器到主機,過濾器用於選擇最適合的主機。Swift提供了一個物件儲存系統,Neutron提供了一個網路管理和VLAN服務。

雲端運算基礎設施管理

雲端運算基礎設施管理是指管理和維護雲端運算環境的基礎設施,包括計算資源、儲存資源、網路資源等。OpenStack是一個開源的雲端運算平臺,提供了一系列的工具和服務來管理和維護雲端運算基礎設施。

SDN和網路虛擬化

SDN(Software-Defined Networking)是一種網路虛擬化技術,允許使用者定義和控制網路流量。OpenStack中的Neutron元件提供了SDN功能,允許使用者建立和管理虛擬網路、路由器和安全組。

Overlay和Tunneling協議

Overlay和Tunneling協議是用於在不同網路之間建立連線的技術。OpenStack中的Neutron元件支援多種Overlay和Tunneling協議,包括VXLAN、GRE和VLAN。

VPN和NAT

VPN(Virtual Private Network)是一種技術,允許使用者建立安全的網路連線。OpenStack中的Neutron元件提供了VPN功能,允許使用者建立和管理VPN連線。NAT(Network Address Translation)是一種技術,允許使用者將私有IP地址轉換為公有IP地址。OpenStack中的Neutron元件提供了NAT功能,允許使用者建立和管理NAT規則。

Intrusion Detection Systems和Load Balancing

Intrusion Detection Systems是一種技術,允許使用者偵測和防止網路入侵。OpenStack中的Neutron元件提供了Intrusion Detection Systems功能,允許使用者建立和管理Intrusion Detection Systems規則。Load Balancing是一種技術,允許使用者分配網路流量到多個伺服器。OpenStack中的Neutron元件提供了Load Balancing功能,允許使用者建立和管理Load Balancing規則。

Firewalls和Cinder

Firewalls是一種技術,允許使用者控制網路流量。OpenStack中的Neutron元件提供了Firewalls功能,允許使用者建立和管理Firewalls規則。Cinder是一種技術,允許使用者提供持久的區塊儲存服務。OpenStack中的Cinder元件提供了持久的區塊儲存服務,允許使用者建立和管理儲存裝置。

Horizon和Heat

Horizon是一種技術,允許使用者提供網路基礎的使用者介面。OpenStack中的Horizon元件提供了網路基礎的使用者介面,允許使用者管理和維護OpenStack環境。Heat是一種技術,允許使用者提供自動化的雲端應用程式佈署和管理。OpenStack中的Heat元件提供了自動化的雲端應用程式佈署和管理功能,允許使用者建立和管理Heat範本。

  graph LR
    A[OpenStack] -->|提供|> B[雲端運算基礎設施管理]
    B -->|包括|> C[計算資源]
    B -->|包括|> D[儲存資源]
    B -->|包括|> E[網路資源]
    C -->|管理|> F[SDN]
    D -->|管理|> G[Cinder]
    E -->|管理|> H[Neutron]
    F -->|支援|> I[Overlay和Tunneling協議]
    G -->|提供|> J[持久的區塊儲存服務]
    H -->|支援|> K[Firewalls和Load Balancing]
    I -->|包括|> L[VXLAN]
    I -->|包括|> M[GRE]
    I -->|包括|> N[VLAN]
    J -->|允許|> O[建立和管理儲存裝置]
    K -->|包括|> P[Intrusion Detection Systems]
    K -->|包括|> Q[Load Balancing]
    L -->|是一種|> R[Overlay協議]
    M -->|是一種|> S[Tunneling協議]
    N -->|是一種|> T[Overlay協議]
    O -->|允許|> U[管理儲存裝置]
    P -->|是一種|> V[網路安全技術]
    Q -->|是一種|> W[網路流量分配技術]
    R -->|允許|> X[建立連線]
    S -->|允許|> Y[建立連線]
    T -->|允許|> Z[建立連線]

內容解密:

上述Mermaid圖表展示了OpenStack的雲端運算基礎設施管理架構,包括計算資源、儲存資源、網路資源等。圖表中展示了各個元件之間的關係,包括SDN、Cinder、Neutron等。圖表還展示了Overlay和Tunneling協議、Firewalls和Load Balancing等技術。

圖表翻譯:

上述Mermaid圖表是一個雲端運算基礎設施管理架構圖,展示了OpenStack的各個元件之間的關係。圖表中包括計算資源、儲存資源、網路資源等,展示瞭如何使用SDN、Cinder、Neutron等技術來管理和維護雲端運算基礎設施。圖表還展示了Overlay和Tunneling協議、Firewalls和Load Balancing等技術的應用。

雲端架構對物聯網的限制

雲端服務提供商位於物聯網邊緣裝置之外,管理著廣域網路。物聯網架構的一個特點是,個人區域網路(PAN)和無線個人區域網路(WPAN)裝置可能不符合IP協定。例如,藍牙低功耗(BLE)和Zigbee等協定不根據IP,而廣域網路(WAN)上的所有東西,包括雲端,都根據IP。

雲端和霧端拓撲

因此,邊緣閘道器的角色是執行該級別的轉換。圖4顯示了雲端中的延遲效果:延遲對於許多物聯網應用程式的實時響應至關重要,迫使處理更接近端點裝置。

延遲效果

延遲和事件的響應時間是另一個影響。當您更接近感測器時,您會進入硬實時要求的領域。這些系統通常是深度嵌入式系統或微控制器,其延遲由玄貓設定。例如,影片相機對幀率(通常為30或60fps)敏感,並且必須在資料流水線中執行一系列任務(去馬賽克、去噪、白平衡和伽馬校正、色域對映、縮放和壓縮)。透過影片成像管道(使用8位元每通道的1080p影片,60fps)流動的資料量約為1.5 GB/s。每個幀都必須在實時中透過此管道流動,因此大多數影片影像訊號處理器在矽中執行這些轉換。

如果我們向上移動堆疊,閘道器具有下一個最佳的響應時間,通常在單位毫秒範圍內。響應時間的限制因素是WPAN延遲和閘道器的負載。如前所述,在WPAN章節中,大多數WPAN,例如BLE,都是可變的,取決於閘道器下的BLE裝置數量、掃描間隔、廣告間隔等。BLE連線間隔可以低至幾毫秒,但可以根據客戶調整廣告間隔以最小化功耗。Wi-Fi訊號通常具有1.5毫秒的延遲。在此級別,延遲需要與PAN的物理介面。您不會期望將原始BLE封包傳遞給雲端以實現近實時控制。

  graph LR
    A[雲端] --> B[邊緣閘道器]
    B --> C[WPAN]
    C --> D[PAN]
    D --> E[感測器]
    E --> F[實時資料]
    F --> G[延遲]
    G --> H[響應時間]

圖表翻譯:

此圖表顯示了雲端、邊緣閘道器、WPAN、PAN和感測器之間的關係。雲端是中心,邊緣閘道器是下一級,WPAN和PAN是更接近感測器的級別。感測器產生實時資料,延遲和響應時間是關鍵因素。圖表顯示了資料流動和延遲的方向,強調了實時控制的重要性。

雲端元件的延遲影響

雲端元件的引入為廣域網(WAN)帶來了額外的延遲。閘道器和雲端提供商之間的路由可能根據資料中心和閘道器的位置而有多個路徑。雲端提供商通常提供一組區域資料中心以正常化流量。要了解雲端提供商的真實延遲影響,必須在數周或數月內跨區域取樣延遲ping:

延遲樣本

區域延遲
美國東部(弗吉尼亞州)91 毫秒
美國東部(俄亥俄州)80 毫秒
美國西部(加利福尼亞州)50 毫秒
美國西部(俄勒岡州)37 毫秒
加拿大(中央)90 毫秒
歐洲(愛爾蘭)177 毫秒
歐洲(倫敦)168 毫秒
歐洲(法蘭克福)180 毫秒
歐洲(巴黎)172 毫秒
歐洲(斯德哥爾摩)192 毫秒
中東(巴林)309 毫秒
亞太地區(香港)216 毫秒

圖表翻譯:

  graph LR
    A[閘道器] -->|延遲|> B[雲端提供商]
    B -->|區域資料中心|> C[正常化流量]
    C -->|延遲ping|> D[樣本]
    D -->|分析|> E[真實延遲影響]

這個圖表展示了閘道器和雲端提供商之間的延遲路徑,以及區域資料中心的作用。樣本的延遲ping結果可以用來分析真實的延遲影響。

雲端延遲分析與實時系統挑戰

在評估雲端服務的延遲時,瞭解不同區域之間的延遲情況至關重要。以下是使用CloudPing服務分析亞太地區、南美洲、中國和美國政府雲端(AWS GovCloud)等多個區域的延遲結果:

  • 亞太地區(孟買):281毫秒
  • 亞太地區(大阪):170毫秒
  • 亞太地區(首爾):192毫秒
  • 亞太地區(新加坡):232毫秒
  • 亞太地區(悉尼):219毫秒
  • 亞太地區(東京):161毫秒
  • 南美洲(聖保羅):208毫秒
  • 中國(北京):205毫秒
  • 中國(寧夏):227毫秒
  • AWS GovCloud(美國東):80毫秒
  • AWS GovCloud(美國):37毫秒

這些資料顯示出不同區域之間的延遲差異,對於需要低延遲的應用程式來說,這些差異可能具有重要意義。

雲端延遲的影響

雲端延遲對於實時系統和需要快速反應的應用程式具有重要影響。例如,在工廠自動化或硬實時控制系統中,5毫秒的延遲尖峰可能導致系統失敗。因此,瞭解和分析雲端延遲對於設計和部署這類系統至關重要。

延遲分析工具

工具如CloudPing提供了對雲端延遲的全面分析,透過每日監測TCP、HTTP和SQL資料庫延遲,跨多個AWS和Microsoft Azure區域。這些工具提供了對雲端解決方案延遲影響的最佳可見性,幫助開發人員和系統設計師做出明智的決定。

圖示說明

圖5:從美國山區時間區的使用者端到全球各地資料中心的往返時間(RTT)和延遲

這個圖示了從美國山區時間區的一個使用者端到全球各地領先的雲端解決方案提供商的資料中心的RTT和延遲。它顯示了RTT的變化性,突出了在設計和部署需要低延遲的系統時需要考慮的挑戰。

雲端架構與 IoT 的關係

在設計 IoT 的雲端架構時,應該考慮到不同架構的響應時間。近端架構(near-device architectures)可以提供低於 10 毫秒的響應時間,並且具有可重複性和確定性的優點。另一方面,雲端解決方案可能會引入變異性和更長的響應時間。因此,架構師需要根據這兩個因素來決定將解決方案的哪些部分部署在哪裡。

雲端提供商的選擇

選擇雲端提供商時,應該考慮到其資料中心的部署模式。如果 IoT 解決方案需要全球部署或涵蓋多個地區,則雲端服務應該具有地理位置相似的資料中心,以幫助正常化響應時間。

Fog 計算

Fog 計算是雲端計算在邊緣的延伸。Fog 代表了一個系統級別的水平架構,分佈資源和服務在網路中。這些資源和服務包括儲存元件、計算裝置、網路功能等。節點可以位於雲端和「事物」(感測器)之間的任何位置。

Fog 計算與 Edge 計算的區別

Fog 計算和 Edge 計算都是為了減少延遲和增加效率而設計的,但它們之間存在一些差異。Edge 計算是指將處理移到資料生成的附近,而 Fog 計算則是指將處理分佈在網路中,包括雲端和 Edge 計算。

OpenFog 參考架構

OpenFog 參考架構是一個 Fog 架構框架,定義了不同層之間的協作和資料合同。這個架構包括了 Fog 節點、Edge 計算和雲端服務等。

  graph LR
    A[Cloud] -->|Fog|> B[Fog Node]
    B -->|Edge|> C[Edge Device]
    C -->|Mist|> D[Mist Device]
    D -->|Sensor|> E[Sensor]

內容解密:

上述 Mermaid 圖表展示了雲端、Fog、Edge 和 Mist 之間的關係。Fog 節點是 Fog 計算的核心,負責分佈資源和服務。Edge 裝置是 Edge 計算的實現,負責將處理移到資料生成的附近。Mist 裝置是 Mist 計算的實現,負責在極端邊緣進行近源計算。

圖表翻譯:

這個圖表展示了不同層之間的協作和資料合同。Fog 節點是 Fog 計算的核心,負責分佈資源和服務。Edge 裝置是 Edge 計算的實現,負責將處理移到資料生成的附近。Mist 裝置是 Mist 計算的實現,負責在極端邊緣進行近源計算。這個圖表幫助我們瞭解不同層之間的關係和協作。

雲端運算與邊緣計算的融合:OpenFog 參考架構

OpenFog Consortium是一個非營利性行業組織,致力於定義邊緣計算的互操作性標準。雖然它不是一個標準組織,但透過聯盟和行業影響力,影響著其他組織的方向。OpenFog 參考架構是一個模型,旨在幫助架構師和商業領導者建立硬體、軟體和基礎設施,以實現邊緣計算。

雲端和邊緣拓撲

OpenFog 參考架構採用了一種分層方法,從底層的邊緣感測器和執行器到頂層的應用服務。這種架構與典型的雲端計算架構(如 OpenStack)有一些相似之處,但它更像是 PaaS 而不是 IaaS。OpenFog 提供了一個完整的堆疊,並且通常是硬體無關的,或者至少是將平臺從系統的其他部分抽象出來。

應用服務

應用服務層的作用是提供所需的服務和自定義服務,以實現任務。這包括提供聯結器以連線其他服務,宿主資料分析套件,提供使用者介面(如果需要),以及提供核心服務。聯結器在應用層將服務連線到支援層。協議抽象層提供了一個聯結器直接與感測器通訊的途徑。每個服務都應該被視為一個容器中的微服務。OpenFog Consortium 倡導容器部署作為軟體在邊緣部署的正確方法。

應用支援

應用支援是基礎設施元件,幫助構建最終的客戶解決方案。這一層可能具有部署方式的依賴性(例如,作為容器)。支援包括多種形式,例如:

  • 應用管理(映像識別、映像驗證、映像部署和身份驗證)
  • 日誌工具
  • 元件和服務的註冊
  • 執行引擎(容器、虛擬機器)
  • 執行語言(Node.js、Java、Python)
  • 應用伺服器(Tomcat)
  • 訊息匯流排(RabbitMQ)
  • 資料庫和歸檔(SQL、NoSQL、Cassandra)

縱觀產業生態圈的動態變化,OpenStack作為開源雲端平臺,其核心元件Keystone、Glance和Nova在構建雲端基礎設施方面扮演著關鍵角色。透過多維比較分析,OpenStack的模組化設計和開放架構使其在靈活性、可擴充套件性和成本效益方面具備優勢,但也面臨著部署複雜度高、整合挑戰以及技術支援分散等限制。深入剖析OpenStack的架構可以發現,其核心元件間的協同運作仰賴於AMQP訊息佇列,實現了元件解耦,提升了系統的彈性。然而,雲端架構本身的延遲效應,尤其在跨區域部署時,對於需要低延遲的物聯網應用構成了挑戰。從技術演進角度,邊緣計算和霧計算的興起為解決此問題提供了新的方向,OpenFog參考架構的出現有助於標準化邊緣計算的部署和管理,預示著雲端和邊緣融合的趨勢。玄貓認為,OpenStack在未來仍將是雲端基礎設施的重要組成部分,但其發展需要更加關注與邊緣計算的整合,以及簡化部署流程和提升使用者體驗,才能更好地滿足日益增長的物聯網應用需求。