碼上歡樂
相關內容    簡體    繁體

談談我對OpenStack的理解

本文轉載自   查看原文   2020-12-09 15:07   670 

摘要

OpenStack 是當今最具影響力的雲計算管理工具——通過命令或者基於 Web 的可視化控制面板來管理 IaaS 雲端的資源池（服務器、存儲和網絡）。它最先由美國國家航空航天局（NASA）和 Rackspace 在 2010 年合作研發，現在參與的人員和組織匯集了來自 100 多個國家的超過 9500 名的個人和 850 多個世界上赫赫有名的企業，如 NASA、谷歌、惠普、Intel、IBM、微軟等。

OpenStack 支持 KVM、Xen、Lvc、Docker 等虛擬機軟件或容器，默認為 KVM。通過安裝驅動，也支持 Hyper-V 和 VMware ESXi，不過有些功能暫時不支持。

OpenStack 采用 Python 語言開發，遵循 Apache 開源協議，因此相比 CloudStack 來說，更輕量化，效率更高。

一、雲計算服務模型

1.1、基礎設施及服務（Infrastructure as a Service，Iaas）

雲服務提供商把IT系統的基礎設施層作為服務租出去，由消費者自己安裝操作系統、中間件、數據庫和應用程序

面向對象一般是IT管理人員

1.2、平台即服務（Platform as a Service，Paas）

雲服務提供商把IT系統中的平台軟件層作為服務租出去，消費者自己開發或者安裝程序，並運行程序

面向對象一般是開發人員

1.3、軟件即服務（Software as a Service，SaaS）

雲服務提供商把IT系統中的應用軟件層作為服務租出去，消費者不用自己安裝應用軟件，直接使用即可，這進一步降低了雲服務消費者的技術門檻

面向對象一般是普通用戶

二、OpenStack服務

2.1、OpenStack核心組件、可選組件以及其他組件介紹

分類

服務

項目名稱

功能

核心組件

Compute
（計算服務）

Nova

管理虛擬機的整個生命周期:創建、運行、掛起、調度、關閉、銷毀等。這是真正的執行部件。接受 DashBoard 發來的命令並完成具體的動作。但是 Nova 不是虛擬機軟件，所以還需要虛擬機軟件（如 KVM、Xen、Hyper-v 等）配合

Network
（網絡服務）

Neutron

管理網絡資源，提供/一組應用編程接口(API)，用戶可以調用它們來定義網絡(如 VLAN )，並把定義好的網絡附加給租戶。Networking 是一個插件式結構，支持當前主流的網絡設備和最新網鉻技術

Object Storage

（對象存儲服務）

Swift

是 NoSQL 數據庫，類似 HBase，為虛擬機提供非結構化數據存儲，它把相同的數據存儲在多台計箅機上，以確保數據不會丟失。用戶可通過 RESTful 和 HTTP 類型的 API 來和它通信。這是實際的存儲項目，類似 Ceph，不過在 OpcnStack 具體實施時，人們更願意采用 Ceph。

Block Storage

（塊存儲服務）

Cinder

管理塊設備，為虛擬機管理 SAN 設備源。但是它本身不是塊設備源， 需要一個存儲后端來提供實際的塊設備源（如 iSCSI、FC等）。

Cinder 相當於一個管家，當虛擬機需要塊設備時，詢問管家去哪里獲取具體的塊設備。它也是插件式的，安裝在具體的 SAN 設備里。

Identity
（身份認證服務）

Keystone

為其他服務提供身份驗證、權限管理、令牌管理及服務名冊管理。要使用雲計算的所有用戶事先需要在 Keystone 中建立賬號和密碼，並定義權限（注意:這里的“用戶”不是指虛擬機里的系統賬戶，如 Windows 7 中的 Administrator )。另外，OpenStack 服務（如 Nova、Neutron、Swift、Cinder 等）也要在里面注冊，並且登記具體的 API，Keystone 本身也要注冊和登記 API

Image Service
（鏡像服務）

Glance

存取虛擬機磁盤鏡像文件，Compute 服務在啟動虛擬機時需要從這里獲取鏡像文件。這個組件不同於上面的 Swift 和 Cinder，這兩者提供的 存儲是在虛擬機里使用的

Dashboard
（控制面板服務）

Horizon

提供了一個網頁界面，用戶登錄后可以做這些操作：管理虛擬機、配置權限、分配 IP 地址、創建租戶和用戶等。本質上就是通過圖形化的 操作界面控制其他服務（如 Compute、Networking 等)。當然，如果你熟悉命令，也可以直接采用命令來完成相應的任務

Telemetry
（計量服務）

Ceilometer

結合 Aodh、CloudKitty 兩個組件，完成計費任務，如結算、消耗的 資源統計、性能監控等。OpenStack 之所以能管理公共雲，一是因為 Ceilometer 的存在，二是因為引人了租戶的概念

可選組件

 

Heat

如果要在成千上萬個虛擬機里安裝和配置同一個軟件，該怎么辦？采用 Orchestrates 是一個不錯的主意，它向每個虛擬機里注人一個名叫 heat-cfntools 的客戶端工具，然后就能同時操作很多虛擬機

 

Sahana

使用戶能夠在 OpenStack 平台上（利用虛擬機）一鍵式創建和管理 Hadoop 集群，實現類似 AWS 的 EMR（Amazon Elastic MapReduce Service）功能。用戶只需要提供簡單的配置參數和模板，如版本信息（CDH 版本）、集群拓撲（幾個 Slave、幾個 Datanode）、節點配置信息（CPU、內存）等，Sahara 服務就能夠在幾分鍾內根據提供的模板快速 部署 Hadoop、Spark 及 Storm 集群。Sahana 是一個大數據分析項目

 

Ironic

把裸金屬機器（與虛擬機相對）加人到資源池中

 

Zaqar

Zaqar 為 Web 和移動開發者提供多租戶雲消息和通知服務，開發人員可以通過 REST API 在其雲應用的不同組件中通過不同的通信模式（如 生產者/消費者或發布者/訂閱者）來傳遞消息

 

Barbican

是 OpenStack 的密鑰管理組件，其他組件可以調用 Barbican 對外暴露的 REST API 來存儲和訪問密鑰

 

Manila

為虛擬機提供文件共享服務，不過需要存儲后端的配合

其他組件

Congress（策略服務）、Designate（DNS 服務）、Freezer（備份及還原服務）、Magnum（容器支持）、Mistral（工作流服務）、Monasca（監控服務）、Searchlight（索引和搜索）、Senlin（集群服務）、Solum（APP集成開發平台）、Tacker（網絡功能 虛擬化）、Trove（數據庫服務）

2.2、Openstack優勢

①模塊松耦合：與其他開源軟件相比，OpenStack模塊分明。添加獨立功能的組件非常簡單。有時候，不需要通讀整個OpenStack的代碼，只需要了解其接口規范及API使用，就可以輕松地添加一個新的模塊

②組件配置較為靈活：OpenStack也需要不同的組件。但是OpenStack的組件安裝異常靈活。可以全部都裝在一台物理機上，也可以分散至多個物理機中，甚至可以把所有的結點都裝在虛擬機中。

③二次開發容易：OpenStack發布的OpenStack API是Rest-full API。其他所有組件也是采種這種統一的規范。因此，基於OpenStack做二次開發，較為簡單。而其他3個開源軟件則由於耦合性太強，導致添加功能較為困難。

④兼容性：OpenStack兼容其他公有雲，方便用戶進行數據遷移。

⑤可擴展性：模塊化設計，可以通過橫向擴展，增加節點、添加資源。

三、OpenStack架構

OpenStack是由一系列具有RESTful接口的Web服務所實現的，是一系列組件服務集合。如下圖為OpenStack的概念架構，我們看到的是一個標准的OpenStack項目組合的架構。這是比較典型的架構，但不代表這是OpenStack的唯一架構，我們可以選取自己需要的組件項目，來搭建適合自己的雲計算平台，設計的基本原則如下：

  • 按照不同的功能和通用性來划分不同項目並拆分子系統
  • 按照邏輯計划、規格子系統之間的通信
  • 通過分層設計整個系統架構
  • 不同的功能子系統間提供統一的API接口

3.1、概念架構圖

雲平台用戶在經過Keystone服務認證授權后，通過Horizon或者Reset API模式創建虛擬機服務，創建過程中包括利用Nova服務創建虛擬機實例，虛擬機實例采用Glance提供鏡像服務，然后使用Neutron為新建的虛擬機分配IP地址，並將其納入虛擬網絡中，之后再通過Cinder創建的卷為虛擬機掛載存儲塊，整個過程都在Ceilometer模塊資源的監控下，Cinder產生的卷（Volume）和Glance提供的鏡像（Image）可以通過Swift的對象存儲機制進行保存。

3.2、邏輯架構圖

  • 雖然上面這幅圖看上去很復雜，但是分層去看的話，就可以較為容易的去了解它，OpenStack包括若干個服務的獨立組件，像之前我們提到的核心組件以及一些可選組件都是在這幅圖里面的，比如nova、keystone、Horizon等，我們先去找到這些組件，然后再去分析下一層
  • 每個組件里有各自的一些服務，所有服務都需要通過keystone進行身份驗證，每個服務之間又可以關聯若干個組件，每個服務至少有一個API進程，通過去監聽API的請求，並對這些請求進行預處理，並將它們發送到相對於該服務的其他組件，服務之間可以通過公共API進行交互
  • 服務之間的通信使用AMQP消息代理，將服務的狀態信息存儲在數據庫中

OpenStack組件通信關系：

  • 基於HTTP協議進行通信：通過各項目的API建立的通信關系，API都是RESTful Web API
  • 基於SQL的通信：用於各個項目內部的通信
  • 基於AMQP協議的通信：用於每個項目內部各個組件之間的通信
  • 通過Native API實現通信：Openstack各組件和第三方軟硬件之間的通信

3.3、OpenStack物理架構

整個OpenStack是由控制節點，計算節點，網絡節點，存儲節點四大部分組成。

控制節點負責對其余節點的控制，包含虛擬機建立，遷移，網絡分配，存儲分配等等

計算節點負責虛擬機運行

網絡節點負責對外網絡與內網絡之間的通信

存儲節點負責對虛擬機的額外存儲管理等等

①控制節點

控制節點包括支持服務、基礎服務、擴展服務以及管理網絡

  • 因為控制節點是管理整個OpenStack進行運作的，所有需要keystone身份認證服務以及Harizon控制面板服務這樣的全局組件來對OpenStack進行管控和操作
  • 為虛擬機提供一些相對應的基礎資源，比如glance鏡像服務為虛擬機提供磁盤鏡像文件、network網絡服務對網絡資源進行管理，提供/一組應用編程接口(API)，用戶可以調用它們來定義網絡以及nova計算服務管理虛擬機的整個生命周期
  • 數據的存儲以及通信支持，我們使用到的是Mysql與RabbitMQ，后續我們需要對數據進行管理需要使用Cinder、Swift以及trove服務，並且提供對物理資源以及虛擬資源的監控，並記錄這些數據，對該數據進行分析，在一定條件下觸發相應動作的ceilometer計量服務
  • 而且還需要基於模板來實現雲環境中資源的初始化，依賴關系處理，部署等基本操作，也可以解決自動收縮,負載均衡等高級特性的heat服務
  • 管理私有網段與公有網段的通信，以及管理虛擬機網絡之間的通信/拓撲，所以需要網絡接口和外面進行連通

②網絡節點

只有一個基礎服務，Neutron網絡服務。負責整個openstack架構的網絡通信。整個網絡接口又可分為管理網絡、數據網絡、外部網絡。管理網絡負責關聯其他節點的網絡，讓控制節點可管控其他節點的網絡。數據網絡負責整個架構的數據通信。外部網絡負責架構與外部物理網絡的連接通信。

③計算節點

計算節點包括基礎服務、擴展服務、網絡接口。基礎服務有Nova Hypervisor 和網絡插件代理。擴展服務為ceilometer agent 計量代理服務。網絡接口為管理網絡和數據網絡。

④存儲節點

存儲節點包括cinder和swift兩個基礎的存儲服務和網絡接口。網絡接口為管理網絡和數據網絡。

四、核心服務概述

4.1、Keystone身份認證服務

4.1.1、Keystone概念

Keystone (OpenStack Identity Service)是OpenStack中的一個獨立的提供安全認證的模塊，主要負責openstack用戶的身份認證、令牌管理、提供訪問資源的服務目錄、以及基於用戶角色的訪問控制。

Keystone類似一個服務總線，或者說是整 個Openstack框架的注冊表,其他服務通過keystone來注冊其服務的Endpoint (服務訪問的URL)，任何服務之間相互的調用，需要經過Keystone的身 份驗證，來獲得目標服務的Endpoint來找到目標服務。

4.1.2、主要功能

  • 身份認證：負責令牌的發放和校驗
  • 用戶授權：授權用戶有指定的可執行動作的范圍
  • 用戶管理：管理用戶的賬戶
  • 服務目錄：提供可用服務的API端點位置

4.1.3、Keystone的管理對象

Keystone服務貫穿整個架構，在進行身份認證服務的整個流程中，有幾個重要的概念。

  • 用戶（user）：指的是使用openstack架構的用戶。
  • 證書（credentials）：用於確認用戶身份的憑證，證明自己是自己，包括用戶的用戶名和密碼，或是用戶名和API密鑰，或者身份管理服務提供的認證令牌。
  • 認證（authentication）：確定用戶身份的過程。
  • 項目（project）：可以理解為一個人，或服務所擁有的資源的集合。
  • 角色（role）：用於划分權限，通過給user指定role，使user獲得role對應操作權限
  • 服務（service）：openstack架構的組件服務，如nova、neutron、cinder、swift、glance等。
  • 令牌（token）：由字符串表示，作為訪問資源的憑證，是用戶的身份/權限證明文件；token決定了用戶的權限范圍，在指定的權限內進行操作；也包括令牌的有效期，在指定的時間范圍內用戶才有這些權限。
  • 端點（endpoint）：一個可以通過網絡來訪問和定位某個openstack service的地址，即用戶創建一個項目過程中需要的各個服務資源的位置

Keystone工作流程

  • 用戶通過命令行或者horizon控制面板的方式登錄openstack，憑借自己的證書（credentials）給keystone驗證。
  • Keystone對用戶的證書驗證，驗證通過則會發布一個令牌（token）和用戶所需服務的位置點（endpoint）給用戶。
  • 用戶得到了位置點（endpoint）之后，攜帶自己的令牌，向nova發起請求，請求創建虛擬機。
  • nova會拿着用戶的token向keystone進行認證，看是否允許用戶執行這樣的操作。
  • keystone認證通過之后，返回給nova，nova即開始執行創建虛擬機的請求。首先需要鏡像資源，nova帶着令牌（token）和所需要的鏡像名向glance提出鏡像資源的請求。
  • glance會拿着token去向keystone進行認證，看是否允許提供鏡像服務。keystone認證成功后，返回給glance。glance向nova提供鏡像服務。
  • 創建虛擬機還需要網絡服務，nova攜帶token向neutron發送網絡服務的請求
  • neutron拿着nova給的token向keystone進行認證，看是否允許向其提供網絡服務。keystone認證成功后，返回給nuetron。nuetron則給nova提供網絡規划服務。
  • nova獲取了鏡像和網絡之后，開始創建虛擬機，通過hypervisior可調用底層硬件資源進行創建。創建完成返回給用戶，成功執行了用戶的請求。

4.2、Glance鏡像服務

它在OpenStack中的項目名稱為Glance。在早期的OpenStack版本中，Glance只有管理鏡像的功能，並不具備鏡像存儲功能。現在，Glance已發展成為集鏡像上傳、檢索、管理和存儲等多種功能的OpenStack核心服務

4.2.1、鏡像

鏡像的英文名為Image，又譯為映像，通常是指一系列文件或一個磁盤驅動器的精確副本。鏡像文件其實和ZIP壓縮包類似，它將特定的一系列文件按照一定的格式制作成單一的文件，以方便用戶下載和使用

4.2.2、鏡像服務

鏡像服務就是用來管理鏡像的，讓用戶能夠發現、獲取和保存鏡像。在OpenStack中提供鏡像服務的是Glance，其主要功能如下：

  • 查詢和獲取鏡像的元數據和鏡像本身
  • 注冊和上傳虛擬機鏡像，包括鏡像的創建、上傳、下載和管理
  • 維護鏡像信息，包括元數據和鏡像本身
  • 支持多種方式存儲鏡像，包括普通的文件系統、Swift、Amazon S3等
  • 對虛擬機實例執行創建快照命令來創建新的鏡像，或者備份虛擬機的狀態

4.2.3、Image API的版本

Glance提供的RESTful API目前只有兩個版本：API v1和API v2

  • v1只提供基本的鏡像和成員操作功能，包括鏡像創建、刪除、下載、列表、詳細信息查詢、更新，以及鏡像租戶成員的創建、刪除和列表
  • v2除了支持v1的所有功能外，主要增加了鏡像位置的添加、刪除、修改、元數據和名稱空間操作，以及鏡像標記操作

兩個版本對鏡像存儲支持相同，v1從N版開始已經過時，遷移路徑使用v2進行替代

4.2.4、鏡像格式

虛擬機鏡像文件磁盤格式

  • raw：無結構的磁盤格式
  • vhd：改格式通用於VMware、Xen、VirtualBox以及其他虛擬機管理程序
  • vhdx：vhd格式的增強版本，支持更大的磁盤尺寸
  • vmdx：一種比較通用的虛擬機磁盤格式
  • vdl：由VirtualBox虛擬機監控程序和QEMU仿真器支持的磁盤格式
  • iso：用於光盤（CD-ROM）數據內容的檔案格式
  • ploop：由Virtualzzo支持，用於運行OS容器的磁盤格式
  • qcow2：由QEMU仿真支持，可動態擴展，支持寫時復制（Copy on Write）的磁盤格式
  • aki：在Glance中存儲的Amazon內核格式
  • ari：在Glance中存儲的Amazon虛擬內存盤（Ramdisk）格式
  • ami：在Glance中存儲的Amazon機器格式

虛擬機鏡像文件容器格式

  • bare：沒有容器或元數據“信封”的鏡像
  • ovf：開放虛擬化格式
  • ova：在Glance中存儲的開放虛擬化設備格式
  • aki：在Glance中存儲的Amazon內核格式
  • ari：在Glance中存儲的Amazon虛擬內存盤（Ramdisk）格式
  • Docker：在Glance中存儲的容器文件系統的Docker的tar檔案

如果不能確定選擇哪種容器格式，那么簡單地容器格式指定為bare是最安全地

4.2.5、鏡像狀態

鏡像從上傳到識別的過程：

  • queued：初始化過程，鏡像文件剛被創建，在Glance數據庫只有其元數據，鏡像數據還沒有上傳至數據庫中
  • saving：導入數據庫過程，是鏡像地原始數據在上傳到數據庫中地一種過渡狀態，表示正在上傳鏡像
  • uploading：提交給服務識別過程，指示已進行導入數據提交調用，此狀態下不允許調用PUT/file（saving狀態會執行PUT/file，這是另外一種上傳的方法）
  • importing：准使用狀態，指示已經完成導入調用，但是鏡像還未准備好使用

鏡像上載完成后的狀態

  • active：表示可使用
  • deactivated：表示只對管理員開放的權限
  • killed：表示鏡像上傳中發生錯誤
  • deleted：鏡像將在不久后自動刪除，鏡像不可用（保留數據）
  • pending_delete：與deleted類似，但是刪除后無法恢復

4.2.6、訪問權限

  • Public（公共的）：可以被所有的項目使用
  • Private（私有的）：只有被鏡像所有者所在的項目使用
  • Shared（共享的）：一個非共有的鏡像可以共享給其他項目，這是通過項目成員（member-*）操作來實現的
  • Protected（受保護的）：這種鏡像不能被刪除

4.2.7、架構圖

  • glance-api 是 glance服務后台運行的服務進程，是進入glance的入口，對外提供REST API ，負責接收外部客戶端的服務請求，如響應鏡像查詢、獲取和存儲的調用。
  • glance-registry 是服務后台遠程的鏡像注冊服務，負責處理與鏡像的元數據相關的外部請求，如鏡像大小、類型等信息。glance-api 接收外部請求，若與元數據相關，則將請求轉發給glance-registry，glance-registry會解析請求的內容，並與數據庫交互，進行存儲、處理、檢索鏡像的元數據，元數據所有信息即存儲在后端的數據庫中。
  • glance的DB模塊存儲的是鏡像的元數據，可以選用MySQL、mariaDB、SQLite等數據庫。鏡像的元數據是通過glance-registry存放在數據庫中。鏡像本身（chunk 塊數據）是通過glance的存儲驅動存儲在后端的各種存儲系統中。
  • 存儲后端（store backend）將鏡像本身的數據存放在后端存儲系統，存儲系統有多種存儲方式，支持本地文件系統存儲、對象存儲、RBD塊存儲、Cinder塊存儲、分布式文件存儲等。具體使用哪種backend，可以在glance的配置文件 /etc/glance/glance-api.conf 中配置 [glance-store] 模塊。

4.2.8、流程解析

①紅色方框是對客戶端的請求進行認證和授權的服務流程：openstack的操作都需要經過keystone進行身份認證，並授權，glance也不例外，授權成功再去請求glance服務，glance服務接收到外部請求后，會去keystone進行認證，此請求是否已授權，認證通過后，才會將請求傳到后端。

  • Auth(授權)：用來控制鏡像的訪問權限，決定鏡像信息是否可以修改

②黃色方框的glance domain controller 是主用的中間件，相當於調度器，作用是將glance 內部服務的操作分發到下面的各個功能層

  • Policy（規則定義）：定義鏡像操作的訪問規則
  • Quota（配額限制）：管理員對用戶定義了鏡像大小的鏡像上傳上限
  • Location（定位）：通過glance_store與后台進行交互，在該層新位置添加進行時檢查位置URI是否正確，防止鏡像位置重復

③藍色方框里鏡像的元數據是通過glance-registry存放在數據庫中。鏡像本身（chunk 塊數據）是通過glance的存儲驅動存儲在后端的各種存儲系統中。

  • Registry Layer（注冊層）：通過使用單獨的服務控制Glance Controller與Glance DB之間的安全交互
  • Glance DB：存儲鏡像的元數據信息
  • Glance Store：用來處理Glance和各種存儲后端的交互，提供了一個統一接口來訪問后端的存儲

④綠色方框是存儲后端（store backend）將鏡像本身的數據存放在后端存儲系統

  • DB（數據庫）：實現與數據庫進行交互的API，將鏡像轉換為響應的格式存儲在數據庫中

4.3、Nova計算服務

4.3.1、Nova計算服務

  • nova計算服務是openstack最核心的服務之一，負責維護和管理雲環境的計算資源
  • nova本身並不提供虛擬化的能力，他通過計算服務使用不同的虛擬化驅動來與底層的Hypervisor進行交互，nova對所有的計算實例進行生命周期的管理
  • nova需要其他服務組件的支持，比如Glance、Keystone、Neutron以及Cinder等，通過與這些服務的支持實現實例的管理

4.3.2、Nova系統架構

 

 

Nova由多個服務器進程構成，每個進程執行不同的功能，下面介紹各個組件的功能

①DB：用於數據存儲的sql數據庫

②API：用於接收HTTP請求、通過消息隊列或HTTP與其他組件通信

  • API是訪問nova的接口，nova-api服務接收和處理來自用戶的所有計算api請求，它是openstack對外服務最主要的接口並且提供了可以查詢所有api的端點，也是外部訪問並使用nova提供的各種服務的唯一途徑，nova-api對接收到的api請求有以下幾個步驟，首先檢查客戶端傳過來的參數是否合法，如果合法則調用其他服務來處理客戶端的HTTP請求，最后格式化nova其他子服務返回結果並返回給客戶端
  • API提供REST標准調用服務，便於與第三方系統集成，只要與虛擬機生命周期相關的操作，nova-api都會響應
  • 用戶不會直接發送RESTful API請求，而是通過命令行、控制台和其他需要跟nova交換的組件來使用這些API

③Scheduler：用於決定那台計算節點承載計算實例的nova調度器

簡介

  • 調度器，它主要由nova-scheduler服務實現，它可以解決如何選擇在哪個節點上啟動實例，並通過調度算法來確定虛擬機具體創建在哪一個計算服務器上，nova-scheduler服務會通過讀取數據庫的內容，從可用的資源中選擇最合適的計算節點來吃新的虛擬機實例
  • 創建虛擬機的過程中，用戶會提出各種各樣的資源要求，比如Cpu、內存以及磁盤各需要多少，openstack會根據用戶的需求，來確定具體使用哪個實例

調度器的類型

  • 隨機調度器：從所有正常運行nova-compute服務的節點中隨機選擇
  • 緩存調度器：是隨機調度器的一種特殊類型，在隨機調度器的基礎上，將主機資源信息緩存在本地內存中，然后通過后台的定時任務，定時從數據庫中獲取最新的主機資源信息，周期性同步而不是實時獲取主機資源信息。
  • 過濾器調度器：根據指定的過濾條件以及權重選擇最佳的計算節點，又稱為篩選器。

過濾器調度器的調度過程

主要分為兩個階段：

  • 通過指定的過濾器選擇滿足條件的計算節點，比如內存使用率，可以使用多個過濾器依次進行過濾。（預選）
  • 對過濾之后的主機列表進行權重計算並排序，選擇最優的計算節點來創建虛擬機實例。（優選）

調度器與DB的交互過程：

  • scheduler組件決定的是虛擬機實例部署在哪台計算節點上並調度，在調度之前，會先向數據庫獲取宿主機資源信息作為依據；
  • 之后可通過過濾器和權重選擇最合適的節點調度，或者指定節點直接調度；
  • 計算節點的 libvirt 工具負責收集宿主機的虛擬化資源，根據已創建的實例再次統計資源，將資源信息更新到數據庫中，整個更新資源信息的過程是周期性執行的，而不是實時的；
  • 所以存在一個問題，當剛創建完一個實例，隨即又需要創建時，數據庫還未來得及更新宿主機的最新狀態，那么調度器依據的信息就不正確，有可能所選的節點資源並不夠用，而導致調度失敗。
  • 這同時也是緩存調度器的缺陷，無法實時獲取租主機資源信息。我們可在調度完成時，直接將資源信息返回給數據庫，更新數據庫狀態，解決這個問題。

過濾器

  • 當過濾調度器需要執行調度操作時，會讓過濾器對計算節點進行判斷，返回ture或false，按照主機列表中的順序依次過濾。
  • scheduler_available_filters 選項用於配置可用過濾器，默認是所有nova自帶的過濾器都可以使用。
  • scheduler_default_filters 選項用於指定nova-schedule 服務真正使用的過濾器。

過濾器類型

  • RetryFilter（再審過濾器）

主要作用是過濾掉之前已經調度過的節點（類比污點）。如A、B、C都通過了過濾，A權重最大被選中執行操作，由於某種原因，操作在A上失敗了。Nova-filter 將重新執行過濾操作，再審過濾器直接過濾掉A，以免再次失敗。

  • AvailabilityZoneFilter（可用區域過濾器）

主要作用是提供容災性，並提供隔離服務，可以將計算節點划分到不同的可用區域中。Openstack默認有一個命名為nova的可用區域，所有計算節點一開始都在其中。用戶可以根據需要創建自己的一個可用區域。創建實例時，需要指定將實例部署在那個可用區域中。通過可用區過濾器，將不屬於指定可用區的計算節點過濾掉。

  • RamFilter（內存過濾器）

根據可用內存來調度虛擬機創建，將不能滿足實例類型內存需求的計算節點過濾掉，但為了提高系統資源利用率, Openstack在計算節點的可用內存允許超過實際內存大小，可臨時突破上限，超過的程度是通過nova.conf配置文件中ram_ allocation_ ratio參數來控制的， 默認值是1.5。（但這只是臨時的）Vi /etc/nova/nova . conf

Ram_ allocation_ ratio=1 .5

  • DiskFilter（硬盤過濾器）

根據磁盤空間來調度虛擬機創建，將不能滿足類型磁盤需求的計算節點過濾掉。磁盤同樣允許超量，超量值可修改nova.conf中disk_ allocation_ ratio參數控制，默認值是1.0，（也是臨時的）

Vi /etc/nova/nova.conf

disk_ allocation_ ratio=1.0

  • CoreFilter（核心過濾器）

根據可用CPU核心來調度虛擬機創建，將不能滿足實例類型vCPU需求的計算節點過濾掉。vCPU也允許超量，超量值是通過修改nova.conf中cpu_ allocation_ratio參數控制，默認值是16。

Vi /etc/nova/nova. conf

cpu_allocation_ ratio=16.0

  • ComputeFilter（計算過濾器）

保證只有nova-compute服務正常工作的計算節點才能被nova-scheduler調度，它是必選的過濾器。

  • ComputeCapabilitiesFilter（計算能力過濾器）

根據計算節點的特性來過了，如不同的架構。

  • ImagePropertiesFilter（鏡像屬性過濾器）

根據所選鏡像的屬性來篩選匹配的計算節點，通過元數據來指定其屬性。如希望鏡像只運行在KVM的Hypervisor上，可以通過Hypervisor Type屬性來指定。

  • 服務器組反親和性過濾器

要求盡量將實例分散部署到不同的節點上，設置一個服務器組，組內的實例會通過此過濾器部署到不同的計算節點。適用於需要分開部署的實例。

  • 服務器組親和性過濾器

此服務器組內的實例，會通過此過濾器，被部署在同一計算節點上，適用於需要位於相同節點的實例服務。

權重

  • 在對計算節點進行過濾時，多個過濾器依次進行過濾，而不是並行，相當於一個個預選，避免重復對同一個節點進行所有過濾項檢驗。過濾之后的節點再通過計算權重選出最終的計算節點。
  • 所有權重位於nova/scheduler/weights 目錄下，目前默認是RAMweighter，根據計算節點空閑的內存計算權重，內存空閑越多權重越大，實例將被部署到內存空閑最大的計算節點。

④Network：管理IP轉發、網橋或虛擬局域網的nova網絡組件

⑤Compute：管理Hypervisor與虛擬機之間通信的nova計算組件

⑥Conductor：處理需要協調的虛擬處理對象轉換

schedule組件小結：

定位：決定實例具體創建在哪個計算節點

調度流程：
有多個調度器、過濾器共同合作，一次過濾，首先篩選出符合要求的節點，接着以權重（一般是基於內存空閑）的方式，對節點打分排序，最終決定出一個節點。

子功能：
粗過濾（基礎資源），例如CPU、內存、磁盤
精細化過濾，例如鏡像屬性，服務性能契合度
高級過濾，親和性/反親和性過濾

過濾之后，可以進行隨機調度，會進行再篩選，即污點機制，對剩下的節點過濾，排除掉之前有故障的節點。

4.3.3、compute計算組件

Nova-compute在計算節點上運行，負責管理節點上的實例。通常一個主機運行一 個Nova-compute服務, 一個實例部署在哪個可用的主機上取決於調度算法。OpenStack對實例的操作最后都是提交給Nova-compute來完成。

Nova-compute可分為兩類，一類是定向openstack報告計算節點的狀態，另一類是實現實例生命周期的管理。

  • 定期向OpenStack報告計算節點的狀態
    每隔一段時間，nova-compute就會報告當前計算節點的資源使用情況和nova-compute服務狀態。nova-compute是通過Hypervisor的驅動獲取這些信息的。
  • 實現虛擬機實例生命周期的管理
    OpenStack對虛擬機實例最主要的操作都是通過nova-compute實現的。包括創建、關閉、重啟、掛起、恢復、中止、調整大小遷移、快照。
    以實例創建為例來說明nova-compute的實現過程。
    (1)為實例准備資源。
    (2)創建實例的鏡像文件。
    (3)創建實例的XML定義文件。
    (4)創建虛擬網絡並啟動虛擬機。

通過Driver (驅動)架構支持多種Hypervisor虛擬機管理器：
面對多種Hypervisor, nova-compute為這些Hypervisor定義統一 的接口，Hypervisor只需要對接這個接口， 就可以Drive驅動的形式即插即用到OpenStack系統中，使得compute組件可以調用虛擬化的資源，創建實例。

 

 

 

4.3.4、conductor協調組件

  • 為數據庫的訪問提供一層安全保障。Nova-conductor作為nova-compute服務與數據庫之間交互的中介，避免了compute直接訪問，由nova-compute服務對接數據庫，compute組件位於第三方上，與架構外部進行交互。這樣就可避免一些越權操作，並且為數據庫分壓。
  • Nova-compute訪問數據庫的全部操作都改到nova-conductor中，nova-conductor作為對數據庫操作的一個代理，而且nova-conductor是部署在控制節點上的。
  • Nova-conductor有助於提高數據庫的訪問性能，nova-compute可以創建多個線程使用遠程過程調用(RPC)訪問nova-conductor。
  • 在一個大規模的openstack部署環境里，管理員可以通過增加nova-conductor的數量來應對日益增長的計算節點對數據庫的訪問量。

4.3.5、 Placement API

  • 以前對資源的管理全部由計算節點承擔，在統計資源使用情況時，只是簡單的將所有計算節點的資源情況累加起來，但是系統中還存在外部資源，這些資源由外部系統提供。如ceph、nfs等提供的存儲資源等。
    面對多種多樣的資源提供者，管理員需要統一的、簡單的管理接口來統計系統中資源使用情況，這個接口就是Placement API。
  • PlacementAPI由nova-placement-api服務來實現， 旨在追蹤記錄資源提供者的目錄和資源使用情況。被消費的資源類型是按類進行跟蹤的。 如計算節點類、共享存儲池類、IP地址類等。

4.3.6、虛擬機實例化流程

  • 用戶訪問控制台
    可以通過多種方式訪問虛擬機的控制台：
    ■ Nova-novncproxy守護進程: 通過vnc連接訪問正在運行的實例提供一個代理，支持瀏覽器novnc客戶端。（最常用的）
    ■ Nova-spicehtml5proxy守護進程: 通過spice連接訪問正在運行的實例提供一個代理，支持基於html5瀏覽器的客戶端。
    ■ Nova-xvpvncproxy守護進程: 通過vnc連接訪問正在運行的實例提供一個代理，支持openstack專用的java客戶端。
    ■ Nova-consoleauth守護進程: 負責對訪問虛擬機控制台提供用戶令牌認證。這個服務必須與控制台代理程序共同使用，即上面三種代理方式。

如果無法通過控制台/URL連接到內部實例：
1、實驗場景中，虛擬機資源不足
2、實驗場景中，鏡像問題（公共鏡像，作為測試用的鏡像）
3、生產環境中，路由配置問題，路由網關配置到了其他實例地址，內部有多個實例項目。

  • 首先用戶（openstack最終用戶或其他程序）執行nova client提供的用於創建虛擬機的命令。
  • nova-api服務監聽到來自客戶端的http請求，會將請求轉換為AMQP消息之后上傳到消息隊列。
  • 通過消息隊列調用conductor服務
  • conductor服務從消息隊列中接收到虛擬機的實例化請求后，進行准備工作
  • conductor通過消息隊列告訴scheduler服務去選擇一個合適的計算節點創建虛擬機，此時scheduler會讀取數據庫的內容
  • conductor服務從nova-schedule服務得到了計算節點的信息后，通過消息隊列通知compute服務實現虛擬機的創建。

4.3.7、Nova部署架構

經典部署架構：

負載均衡部署架構：

4.3.8、Nova的Cell架構

 

使用此架構原因

為了解決openstack nova集群的規模變大時,數據庫和消息隊列服務就會出現瓶頸問題。Nova為提高水平擴展及分布式、大規模的部署能力，同時又不想增加數據庫和消息中間件的復雜度，從而引入了Cell概念。

cell概念

Cell可譯為單元。為支持更大規模的部署,openstack將大的nova集群分成小的單元，每個單元都有自己的消息隊列和數據庫，可以解決規模增大時引起的瓶頸問題。在Cell中，Keystone、Neutron、 Cinder、Glance等資源是共享的。

cell架構的數據庫

  • nova-api數據庫：存放全局信息，這些全局數據表是從nova庫遷移過來的，包括實例模型信息，實例組，配額信息。
  • nova-cell0數據ku：當實例調度失敗時，實例的信息不屬於任何一個cell，所以存放到cell0數據庫中。

單cell部署：

 

 

多cell部署：

 

多cell部署的架構，可以從分層的角度來看：
為了應付集群規模的擴大，對數據庫、消息隊列進行擴容，實現nova規模的擴展。通過划分多個小的cell單元，多個單元同時處理業務，每個cell單元都有各自的數據庫和消息隊列。為了管理這些小的單元，需要一個集中化管理組件 super conductor，主conductor來管理cell單元，同時完成自身的工作。

藍色方框：是對消息隊列的划分。划分為API消息隊列，和cell單元中的消息隊列。API消息隊列中是外部對nova的請求，以及nova內部子服務之間的通信請求，作為它們之間通信的載體。cell消息隊列中是cell單元需要處理的業務請求。
紅色方框：是對conductor的划分，super-conductor用於集中管理cell單元，同時負責通知 nova-scheduler 調度計算節點，調度失敗直接寫入cell0，成功則控制任務具體下發給哪個cell單元處理，將所有數據寫入數據庫。cell中的conductor，通過消息隊列收到本cell需要創建實例的請求后，會通知nova-compute創建實例，進行具體的處理和協調。
粉色方框：是對數據庫的划分。API數據庫存放全局的交互數據，總的資源統計。cell0數據庫存放實例創建失敗的信息，cell1/2存放各自單元成功創建實例的信息，對應處理的請求數據。
nova-api：每個創建實例的請求都有編號，創建成功與否的結果會存儲在cell數據庫中，nova-api會根據編號，從cell數據庫中調取到請求的最終結果，格式化后返回給用戶。

4.4、Neutron 網絡服務

簡介：
網絡是openstack最重要的資源之一， 沒有網絡，虛擬機將被隔離。Openstack的網絡服務最主要的功能就是為虛擬機實例提供網絡連接，最初由nova的一-個單獨模塊nova-compute實現，但是nova-compute支持的網絡服務有限，無法適應大規模、高密度和多項目的雲計算，現已被專門的網絡服務項目Neutron所取代。
Neutron為整個openstack環境提供軟件定義網絡支持，主要功能包括二層交換、三層路由、防火牆、VPN, 以及負載均衡等。Neutron在由其他openstack服務 (如nova)管理的網絡接口設備 (如虛擬網卡)之間提供網絡連接即服務。

4.4.1、linux網絡虛擬化

linux網絡虛擬化：
傳統的物理網絡：

 

需要對二層物理網絡進行抽象和管理：

 

  • 實現虛擬化后，多個物理服務器可以被虛擬機取代，部署在同一台物理服務器，上。虛擬機由虛擬機管理器(Hypervisor)實現，在Linux系統中Hypervisor通常采用kvm。在對服務器進行虛擬化的同時，也對網絡進行虛擬化。
  • Hypervisor為虛擬機創建一個或多個虛擬網卡(vNIC)，虛擬網卡等同於虛擬機的物理網卡。物理交換機在虛擬網絡中被虛擬為虛擬交換機(vSwitch)，虛擬機的虛擬網卡連接到虛擬交換機上，虛擬機交換機再通過物理主機的物理網卡連接到外部網絡。
  • 對於物理網絡來說，虛擬化的主要工作是對網卡和交換設備的虛擬化。

linux虛擬網橋：

 

  • 與物理機不同，虛擬機並沒有硬件設備，但是也要與物理機和其他虛擬機進行通信。LinuxKVM的解決方案是提供虛擬網橋設備，像物理交換機具有若干網絡接口(網卡) 一樣，在網橋上創建多個虛擬的網絡接口，每個網絡接口再與KVM虛擬機的網卡相連。
  • 在Linux的KVM虛擬系統中，為支持虛擬機的網絡通信，網橋接口的名稱通常以vnet開頭，加上從0開始順序編號，如vnet0、vnet1, 在創建虛擬機時會自動創建這些接口。虛擬網橋br1和br2分別連接到物理主機的物理網卡1和物理網卡2。

虛擬局域網：

 

  • 一個網橋可以橋接若干虛擬機，當多個虛擬機連接在同一網橋時，每個虛擬機發出的廣播包會引發廣播風暴，影響虛擬機的網絡性能。通常使用虛擬局域網(VLAN)將部分虛擬機的廣播包限制在特定范圍內，不影響其他虛擬機的網絡通信。
  • 通常使用VLAN將部分虛擬機的廣播包限制在特定范圍內，不影響其他虛擬機的網絡通信。
  • 將多個虛擬機划分到不同的VLAN中，同一VL AN的虛擬機相當於連接同一網橋上。
  • 在Linux虛擬化環境中，通常會將網橋與VLAN對應起來，也就是將網橋划分到不同的VLAN中
  • VLAN協議為802.1Q，VLAN是具有802.1Q標簽的網絡。

開放虛擬交換機：

 

  • 開放虛擬交換機 (Open vSwitch) 是與硬件交換機具備相同特性，可在不同虛擬平台之間移植（保持自己的功能特性，同時具有兼容性），具有產品級質量的虛擬交換機，適合在生產環境中部署。
  • 交換設備的虛擬化對虛擬網絡來說至關重要。在傳統的數據中心，管理員可以對物理交換機進行配置，控制服務器的網絡接入，實現網絡隔離、流量監控、QoS配置、流量優化等目標。在雲環境中，采用Open vSwitch技術的虛擬交換機可使虛擬網絡的管理、網絡狀態和流量的監控得以輕松實現。
  • Open Switch在雲環境中的虛擬化平台上實現分布式虛擬交換機，可以將不同主機上的OpenvSwitch交換機連接起來，形成一個大規模的虛擬網絡。

OpenStack網絡服務提供一個API讓用戶在雲中建立和定義網絡連接。該網絡服務的項目名稱是Neutron。OpenStack網絡負責創建和管理 虛擬網絡基礎架構，包括網絡、交換機、子網和路由器，這些設備由OpenStack計算服務Nova管理。同時，網絡服務還提供防火牆和VPN這樣的高級服務。可以將網絡服務部署到特定主機.上。OpenStack網絡組件與身份服務、計算服務和儀表板等多個OpenStack組件進行整合

4.4.2、Neutron網絡結構

  • 一個簡化的典型的Neutron網絡結構如圖所示，包括一個外部網絡、一個內部網絡和一個路由器。
  • 外部網絡負責連接OpenStack項目之外的網絡環境，又稱公共網絡。與其他網絡不同，它不僅僅是-一個虛擬網絡，更重要的是，它表示OpenStack網絡能被外部物理網絡接入並訪問。外部網絡可能是企業的局域網(Intranet) ，也可能是互聯網(Internet) ，這類網絡並不是由Neutron直接管理。
  • 內部網絡完全由軟件定義，又稱私有網絡。它是虛擬機實例所在的網絡，能夠直接連接到虛擬機。項目用戶可以創建自己的內部網絡。默認情況下，項目之間的內部網絡是相互隔離的，不能共享。該網絡由Neutron直接配置與管理。
  • 路由器用於將內部網絡與外部網絡連接起來，因此，要使虛擬機訪問外部網絡，必須創建一個路由器。
  • Neutron需要實現的主要是內部網絡和路由器。內部網絡是對二層(L 2)網絡的抽象，模擬物理網絡的二層局域網，對於項目來說，它是私有的。路由器則是對三層(L3) 網絡的抽象，模擬物理路由器，為用戶提供路由、NAT等服務。

 

網絡子網與端口

  • 網絡：一個隔離的二二層廣 播域，類似交換機中的VLAN。Neutron支持多種類型的網絡， 如FLAT、VLAN、VXLAN等。
  • 子網：一個IPV4或者IPV6的地址段及其相關配置狀態。虛擬機實例的IP地址從子網中分配。每個子網需要定義IP地址的范圍和掩碼(這個有點像DHCP中定義的作用域的概念)。
  • 端口：連接設備的連接點，類似虛擬交換機上的一個網絡端口。端口定義了MAC地址和IP地址，當虛擬機的虛擬網卡綁定到端口時，端口會將MAC和IP分配給該虛擬網卡。
  • 通常可以創建和配置網絡、子網和端口來為項目搭建虛擬網絡。網絡必須屬於某個項目，一個項目中可以創建多個網絡。一個子網只能屬於某個網絡，一個網絡可以有多個子網。一個端口必須屬於某個子網，一個子網可以有多個端口。

網絡拓撲類型

  • Local
    Local網絡與其他網絡和節點隔離。該網絡中的虛擬機實例只能與位於同-節點上同- -網絡的虛擬機實例通信，實際意義不大，主要用於測試環境。位於同一Local網絡的實例之間可以通信，位於不同Local網絡的示例之間無法通信。一個Local網絡只能位於同一個物理節點上，無法跨節點部署。
  • Flat
    Flat是一種簡單的扁平網絡拓撲，所有的虛擬機實例都連接在同一網絡中，能與位於同一網絡的實例進行通信，並且可以跨多個節點。這種網絡不使用VLAN,沒有對數據包打VLAN標簽，無法進行網絡隔離。Flat是基於不使用VLAN的物理網絡實施的虛擬網絡。每個物理網絡最多只能實現- -個虛擬網絡。
  • VLAN
    VLAN是支持802.1q協議的虛擬局域網，使用VLAN標簽標記數據包，實現網絡隔離。同一VLAN網絡中的實例可以通信，不同VLAN網絡中的實例只能通過路由器來通信。VLAN網絡可以跨節點。
  • VXLAN
    VXLAN (虛擬擴展局域網)可以看作是VLAN的一種擴展，相比於VLAN,它有更大的擴展性和靈活性，是目前支持大規模多租房網絡環境的解決方案。由於VLAN包頭部限長是12位， 導致VLAN的數量限制是4096 (2^12) 個，不能滿足網絡空間日益增長的需求。目前VXLAN的封包頭部有24位用作VXLAN標識符(VNID)來區分VXLAN網段，最多可以支持16777216 (2^24) 個網段。
    VXLAN使用STP防止環路，導致- -半的網絡路徑被阻斷。VXLAN的數據包是封裝到UDP通過三層傳輸和轉發的，可以完整地利用三層路由，能克服VLAN和物理網絡基礎設施的限制，更好地利用已有的網絡路徑。
  • GRE
    GRE (通用路由封裝)是用一種網絡層協議去封裝另一種網絡層協議的隧道技術。GRE的隧道由兩端的源IP地址和目的IP地址定義，它允許用戶使用IP封裝IP等協議，並支持全部的路由協議。在OpenStack環境中使用GRE意味着"IP over IP”,GRE與VXLAN的主要區別在於，它是使用IP包而非UDP進行封裝的。
  • GENEVE
    GENEVE(通用網絡虛擬封裝)的目標宣稱是僅定義封裝數據格式，盡可能實現數據格式的彈性和擴展性。GENEVE封裝的包通過標准的網絡設備傳送，即通過單播或多播尋址，包從一個隧道端點傳送到另一個或多個隧道端點。GENEVE幀格式由- -個封裝在IPV4或IPV6的UDP里的簡化的隧道頭部組成。GENEVE推出的主要目的是為了解決封裝時添加的元數據信息問題(到底多少位, 怎么用GENEVE自動識別與調整) ，以適應各種虛擬化場景。
  • 總結
    隨着雲計算、大數據、移動互聯網等新技術的普及，網絡虛擬化技術的趨勢在傳統單層網絡基礎上疊加一層邏輯網絡。這將網絡分為兩個層次，傳統單層網絡稱為Underlay (承載網絡)，疊加其上的邏輯網絡稱為Overlay (疊加網絡或覆蓋網絡)。Overlay網絡的節點通過虛擬的或邏輯的連接進行通信，每一個虛擬的或邏輯的連接對應於Underlay網絡的一條路徑，由多個前后銜接的連接組成。Overlay網絡無須對基礎網絡進行大規模修改，不用關心這些底層實現，是實現雲網融合的關鍵。

VXLAN、GRE、GENEVE都是基於隧道技術的overlay網絡。

VLAN和VXLAN：vlan是虛擬局域網，通過不同的vlan標簽進行網絡隔離；vxlan是vlan的擴展，能充分利用三層路由，解決傳統vlan和物理設備的環境限制問題，並且比vlan支持更多的網段，基於udp協議。

簡單理解：隨着目前互聯網技術的發展，對於網絡部分，使用虛擬化的方案，實現對傳統網絡的擴展，利用疊加的方式，常用的疊加網絡VXLAN、GRE。

4.4.4、openstack中的網絡基本架構

 

  • Neutron僅有一個主要服務進程neutron-server。它是運行在控制節點上的，對外提供Openstack網絡API作為訪問Neutron的入口，收到請求后調用插件進行處理，最終由計算節點和網絡節點上的各種代理完成請求。
  • 網絡提供者是指提供OpenStack網絡服務的虛擬或物理網絡設備，如Linux Bridge、Open vSwitch,或者其他支持Neutron的物理交換機。
  • 與其他服務一樣，Neutron的各組件服務之間需要相互協調和通信，neutron-server. 插件和代理之間通過消息隊列進行通信和相互調用。
  • 數據庫用於存放OpenStack的網絡狀態信息，包括網絡、子網、端口、路由器等。
  • 客戶端是指使用Neutron服務的應用程序，可以是命令行工具、Horizon和Nova計算服務等。

實例：以一個創建VLAN 100虛擬網絡的流程為例說明這些組件如何協同工作。

  • neutron-server收到創建網絡的請求，通過消息隊列通知已注冊的Linux Bridge插件。(插件可以有很多，這里舉例創建虛擬網絡的插件是Linux Bridge插件)
  • 該插件將要創建的網絡信息(如名稱、VLAN ID等)保存到數據庫中，並通過消息隊列通知運行在各節點上的代理
  • 代理收到消息后會在節點上的物理網卡上創建VLAN設備(比如eth1.100)，並創建一個網橋(比如brqxxx)來橋接VLAN設備。

neutron-server詳解：
結構：

 

  • RESTful API:直接對客戶端提供API服務，屬於最前端的API，包括Core API和Extension API兩種類型。Core API提供管理網絡、子網和端口核心資源的RESTful API; Extension API則提供管理路由器、防火牆、負載均衡、安全組等擴展資源的RESTful API。
  • Common Service:通用服務，負責對API請求進行檢驗、認證，並授權。
  • Neutron Core:核心處理程序，調用相應的插件API來處理API請求。
  • Plugin API:定義插件的抽象功能集合，提供調用插件的API接口，包括Core Plugin API 和 ExtensionPlugin API兩種類型。Neutron Core通過Core Plugin API調用相應的Core Plugin

 


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 談談你對this的理解 談談openstack部署規模問題 談談對css定位的理解 談談你對Promise的理解 談談對運維的理解 談談對zynq的淺顯理解 談談對Spring IOC的理解 1.3 談談你對MVC的理解 面試——談談對JAVA的理解 談談對IOC的理解
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM