Network Functions Virtualization ?infrastructure?? ?網絡功能虛擬化 基礎設施?? ??? ?
NFV最大吸引力是運營商降低成本，提高管理、維護、網絡及業務部署效率、節能、以及未來的開放和創新潛力

NFV架構：橫向三層 基礎設施層（即NFV-I），虛擬網絡層（UNC/UDG），運營支撐層（BSS/OSS）
?? ??? ??? ? ? 縱向二層 業務網絡域（NFVI+VNF+OSS/BSS）管理編排域（MANO：VIM+VNFM+O）
?? ??? ??? ? ??
management and orchestration 管理和編排
MANO：VNF的部署（上線/下線/自動擴減容調整）ETSI標準定義的組件名稱
MAE：（華為網管，實現了MANO功能）
包含：VNF LCM ? 是MAE產品的一個功能組件，實現虛VNF的部署（上線/下線/自動擴減容調整）
? ? ? ? ?NFVO ? ? ? ?是MAE產品的一個功能組件，實現虛VNF的部署（上線/下線/自動擴減容調整）
?? ??? ? NFVO與VNF LCM差別： ? NFVO可加載VNFD模板+NSD模板，安裝SDN組網的VNF（VNF LCM只能安裝非SDN組網的VNF）。
? ? ? ? ?NFVO安裝VNF時，NFVO僅下發命令到VNF LCM，由VNF LCM和VIM安裝VNF。

Oenstack是云操作系統
?? ??? ??
①用戶從操作管理界面（Horizon門戶功能）提交虛擬機創建請求，同時攜帶虛擬機的資源量需求（資源配置文件等）。
②該需求會下發給Nova組件。Nova首先根據虛擬機的資源需求分配計算資源。Nova檢索全部計算資源，過濾掉不可用的計算資源，將剩余的計算資源進行排序，選擇最優的資源。
③Nova必須保證所創建的虛擬機有鏡像資源可以使用，以便分配完全部資源之后可以使用鏡像來啟動虛擬機。Nova向Glance申請鏡像資源。該鏡像資源也是由資源配置文件指定。隨后Glance啟動鏡像相關管理工作，查找鏡像資源。如果自身目錄沒有對應鏡像資源，Glance會去后端Swift存儲請求對應的鏡像資源。此時Swift類似一個文件服務器。找到對應的鏡像資源后，Glance將鏡像資源（就是文件）傳遞給Nova組件。
④Nova隨即請求網絡資源。即為虛擬機分配端口資源、配置IP地址、配置二層互通資源（VLAN、VxLAN等等）、打通三層路由。
⑤通過Cinder請求存儲。同Nova申請計算資源一樣，Cinder也經過查找、篩選和排序過程選定存儲資源，將相應磁盤參數傳遞給Nova組件。最后Nova組件將計算、存儲和網絡資源組合，創建虛擬機。利用鏡像文件引導啟動虛擬機的系統，虛擬機即可運行。
⑥如果上述鏡像中的上層應用不完整，用戶也可以在虛擬機啟動之后安裝自己所需的應用。
⑦安裝完成后，使用Glance將包含新裝應用的虛擬機打包創建鏡像；
⑧通過Swift將新創建的鏡像保存。后續如果Nova使用新的鏡像啟動虛擬機，新啟動的虛擬機就會包含本次新裝的應用，用戶不必重新安裝該應用。

nova是核心部件，負責管理計算資源（CPU內存），還是存儲和網絡資源的總協調
提供計算服務，虛擬機生命周期管理

neutron 網絡資源（IP、Vlan、路由），虛擬機與外部網絡的互通與隔離
數據轉發的集中控制節點，未來發展方向是SDN（軟件定義網絡） Controller

glance ?鏡像管理（提供鏡像查詢/上傳/下載） 只負責創建/刪除/傳遞鏡像信息，保存鏡像文件的是后端存儲swift
glance用來記錄鏡像存儲在哪個swift里了
nova讀取鏡像內容，將鏡像復制到虛擬機磁盤，虛擬機從磁盤引導啟動鏡像中的Guest OS

swift對象存儲 只為glane服務（適合靜態數據，長期存放的）

cinder 為虛擬機提供塊存儲資源 （塊指的是操作系統將磁盤劃分一個個塊），分配的存儲資源其實就是虛擬機的本地磁盤
對卷的管理，允許對卷，卷的類型，卷的快照，卷備份進行處理
cinder本身并不是存儲技術，只是為后端存儲提供統一的接口，比如DAS/NAS/SAN/對象存儲/分布式存儲

ceilometer 資源的計量和監控 ?計量各租戶使用的計算/存儲/網絡資源，從而計費

Horizon 為幾乎所有組件提供基于web的操作界面（各組件只提供命令行模式，horizon提供了圖形化封裝）

keystone 鑒權（所有需要鑒權才能繼續的操作，各組件都要先通過API與keystone交互進行鑒權和認證）

邏輯網絡
external_api ?用于VNFM進入VIM （VIM就是FM）
external_om ?登錄的ip
internal_base ?I層內部管理網絡，用于控制節點管理計算節點
stroage_date1 存儲數據網絡

OVS（open vSwitch 開源以太網虛擬交換機）：傳遞虛擬機VM之間的流量，實現VM和外界網絡的通信
vEPC中OVS用于I層和CSM的數據轉發

EVS 彈性虛擬交換機 ? 華為自研基于OVS 兩者區別 ? （應用于CloudCore或CloudMSE業務數據面）
1.基于DPDK技術提升了端口IO性能（需要網卡支持inter的DPDK技術, 占用專門的CPU內核來負責收發包功能）
2.EVS會在vswitchd啟動線程接管內核收發包功能，而OVS沒有專門線程。
3.OVS數據接收和發送是在內核態完成，EVS是在用戶態完成。

SRIOV硬直通（與硬件I/O性能相近） ? 一種基于硬件的虛擬化技術，借助直通網卡虛擬出的PCI設備直接掛載到虛擬機
應用在CloudEdge 中vEPC OM, vEPC業務及Intra vAPP 流量

FusionSphere Openstack OM ?物理資源管理，虛擬化資源管理，基于角色的訪問控制、自動化運維、虛擬負載均衡管理等
VIM：由FS、FM和eSight來實現，主要負責資源管理和自動資源發放，運維，告警和KPI上報。

DC（物理數據中心）下面劃分AZ（數據中心中有資源共同依賴的資源集合），再出HA（FM上創建的主機組），HA上創建VDC（虛擬數據中心），VDC下面再細分VPC（虛擬私有云）給不同網元
一個DC規劃一個AZ（版本主推），支持多個AZ，比如管理域劃分一個AZ，業務域劃分另外一個AZ。AZ分計算AZ和存儲AZ。計算AZ關聯HA（?Host Aggregate?主機組）。存儲AZ關聯后端存儲
不同VDC之間是隔離的，又分管理域（U2020/VNFM） 業務域（UNC/UDG），VPC也分管理VPC和業務VPC
VPC具有完全獨立的IP地址空間設置，與其他不在該私有云中的虛擬機完全網絡隔離（一個VPC就是一個網元）
為了容災保證，不同的AZ不能用公用的數通、電源節點

正向代理 ?客戶端通過代理服務器訪問網絡服務器（隱藏客戶端信息）
反向代理 ?客戶端訪問代理服務器，代理服務器將請求轉發給網絡服務器（隱藏服務端信息，或為多臺web服務器提供負載均衡或者緩沖）

VNF部署流程
1、登錄LCM，導入VNFD和TOSCA模板，同時導入Guest OS鏡像包(Euler OS)和業務Pod鏡像包，啟動VNF部署過程。
2、LCM接收到VNF啟動部署通知后，向FusionSphere申請創建VM的相關I層資源。
3、LCM與FusionSphere交互創建，根據VNFD模板和GuestOS鏡像完成VM的創建。
4、LCM通知FusionStage進行VM納管。FusionStage在納管VM時，會把VM作為K8S系統中的Node節點（一個VM對應一個Node節點），在Node節點中裝載Docker、Kubelet、Kube-proxy等服務。
5、FusionStage在Node節點中根據TOSCA模板和Pod鏡像，創建業務所需的Pod和容器，完成網元的創建。

VNFD: Virtualized Network Function Descriptor描述符 ?部署VNF的詳細描述文件，包含了VNF的部署策略、依賴軟件包、彈性策略
template模板---scripts劇本---blue_prints藍圖
plan 規劃（Deployment plan 安裝網元，Scaling plan 擴縮容，Upgrade Plan 升級或回退，Disaster Recovery Plan 容災備份，Termination Plan卸載）
關鍵參數：input定義，plan定義，network定義，VM定義

NUMA （Non-Uniform Memory Access，非一致內存訪問）
當前服務器架構中，一般都會有多個物理CPU，每個物理CPU都有對應的內存資源。這些分配給指定CPU的內存與CPU之間的通信是最快的。另外還可能有IO設備和這個CPU綁定。
這些和CPU綁定的所有內存和IO資源，我們就把其歸為一個NUMA節點，也稱為node。

親和：以虛擬機為例，兩個虛擬機必須部署在一個XX里，叫XX親和。
反親和：以虛擬機為例，兩個虛擬機必須部署在不同的XX里，叫XX反親和。
NUMA親和：兩個虛擬機必須部署在1個numa里，也就是不能跨numa。這樣性能佳。
主機反親和：兩個虛擬機必須部署在不同的主機里，也就是不能放到一個主機，這樣可靠性佳。

vm_antii_affinity:
?? ?policy_level：host 代表反親和的粒度，如host、region等。vEPC場景一般使用的是host為粒度
?? ?max_num_per_location：1 代表了確認反親和過后，其上最多承載多少虛擬機，如這里指單個??host上最多承載1個虛擬機
?? ?enforced：true 當取值為true時，即使資源或者其他條件不夠的情況下也必須強制執行設置好的反親和性；當取值為false時，會根據實際情況進度適度的變化;
cross_numa_zone:disallowed 取值為allowed時表示VM的多個vCPU可以跨numa node部署，disallowed時表示只能單node部署；
cross_io_numa_zone:disallowed 取值為allowed時表示VM可以共享IO NUMA資源，disallowed時表示只能獨占

--------磁盤陣列---------- ? ? ? ------FS----- ? ? ? ?------FM------
硬盤域---生成---存儲池---映射---后端存儲---映射---卷類型---分配指定資源---VM
1、 在FM中，1個“卷類型”對應1個“后端存儲”；
2、 在FS中， 1 個“后端存儲”對應 1個或者多個 ?“存儲池”，“存儲池”配置為RAID10；
3、在磁陣中，1 個“硬盤域”對應 1個 “存儲池”；
4、若干個硬盤（不超過50）組成1個 “硬盤域”，硬盤域不能跨磁陣。

非SDN組網方案
基于機架服務器網絡架構說明
采用三層架構：TOR+EOR+DC-GW；
TOR，EOR，工作在L2模式，基于VLAN/MAC轉發。
DC-GW作為業務&管理 L3GW，同時支持靜態路由/OSPF/BGP及BFD協議。
業務EOR和業務TOR分別采用M-LAG組網。
DC-GW獨立雙主（兩臺DCGW不同IP不同MAC），之間三層級聯（BGP/OSPF）。
硬件管理TOR由于對可靠性要求不高，不需要成對配置。
主推用戶面和控制面分機柜部署。
主推用戶面和控制面獨立業務TOR，共用管理&存儲TOR、共用硬件管理TOR。

基于E9000服務器網絡架構說明
采用三層架構：CX交換板+EOR+DC-GW；
CX交換板，EOR，工作在L2模式，基于VLAN/MAC轉發。
DC-GW作為業務&管理 L3GW，同時支持靜態路由/OSPF/BGP及BFD協議。
業務EOR和CX交換板分別采用M-LAG組網。
DC-GW獨立雙主，之間三層級聯（BGP/OSPF）。
E9000下一般不配置單獨的設備管理TOR，設備管理和存儲管理TOR合一。
E9000下，交換板已經對服務器進行收斂，不需要再單獨配置TOR 。

采用Leaf-Spine（圖中業務TOR和EOR）網絡架構，交換設備間全IP互聯互通。
業務EOR作為大帶寬管道，不感知業務，提供高性能的轉發能力。
DC-GW引入大容量路由器作為VNF業務網關，與外部交換路由。
E9000場景，單框E9000只允許歸屬于一對Leaf，不能跨多對Leaf接入。
業務TOR作為硬件VTEP，同時部署 DVR功能進行東西向流量就近轉發。
E2E自動化，支持VNF相關L2/L3網絡、靜態路由+BFD、BGP路由等業務在網絡側的配置自動化。

IMS確定部署在非SDN資源池上。其余EPC/5GC網元部署在SDN資源池中。

AZ分為2個業務AZ與1個VIM AZ：
AZ1?? ??? ??? ?與硬件分區A對應，命名舉例：NFV-AZ-HDNJIH-12A-HW-01-AZ1 ? ? ? ? ? ? ? ? ?業務AZ
AZ2?? ??? ??? ?與硬件分區B對應，命名舉例：NFV-AZ-HDNJIH-12A-HW-01-AZ2 ? ? ? ? ? ? ? ? 業務AZ
VIM AZ ? ? 華為VIM按需劃分的獨立AZ，命名舉例：NFV-AZ-HDNJIH-12A-HW-01-AZM ? 把硬件分區A的VIM服務器單獨劃分AZ。

HA劃分為以下五種類型：
MNG?? ? ? ?用于部署MANO、OMC、漏掃等管理類網元的主機?? ? ? ?type=MgmtPlaneXX，ovs=C-plane，sriov=false
SVIC?? ?用于部署CSCF等控制面網元的主機?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?type=TrustPlaneXX，ovs=C-plane，sriov=false
SVIU?? ?用于部署SAE GW等轉發面網元的主機（初期不涉及）?? ?type=TrustPlaneXX，ovs=false，sriov= U-Plane
DMZC?? ?DMZ區的主機 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?? ?type=DmzPlaneXX，ovs=C-plane，sriov=false
VIM?? ? ? ?NFV-HA-HDNJIH-12A-HW-01-VIM?? ? ? ? ? ? ? ? ? ? ? ? ? ?規范新增VIM HA定義；包含PaaS服務器

劃分原則：
1、HA不跨AZ。
2、為保證資源共享效率，HA的虛擬網絡統一采用 OVS+DPDK（非SDN：用戶態OVS；混合SDN：CE1800V）。
3、不同安全域的計算服務器物理隔離，劃分獨立HA。
4、為便于維護管理，要求每個 HA 內主機數原則上不多于 256 臺，并以N 個標準化服務器模塊為單位進行劃分。（三期最新規范：為便于維護管理，本期項目SDN組網資源池每個HA內主機數量最大可以等于單個 AZ的服務器數量。）
5、建議新建HA為網元后續擴容預留空間，比如規劃256臺但實際業務只使用200臺，或規劃200臺以內業務使用200臺將來可以擴容到256臺。
6、網絡云三期2B/2C共HA。
7、建議每個HA盡量包含不同類型的網元5GC/UDM/PCF。
8、同省同類型網元，應盡量按照：跨大區主備節點、跨資源池、跨AZ、跨HA的優先級順序部署，以降低硬件故障的影響范圍。
9、安全類服務器HA規劃在AZ1，共享AZ1的VIM存儲池，避免規劃在AZ2導致跨AZ訪問VIM存儲池。
10、為第三方廠家NFVO+/VNFM/OMC規劃獨立HA。
11、在保證共享效率的前提下，為便于維護管理，建議按省份、廠家劃分HA。
12、擴容新增硬件，建議和原有硬件分HA部署。

1、存儲池個數：
建議：單AZ內業務存儲池劃分為3個或以上，3個存儲池的容量盡量均衡，以滿足“主備從”類型虛擬機跨存儲池部署的可靠性；對于IMS和CS只需要2個存儲池、卷類型的業務，多個VNF在3個卷類型中輪選2個卷類型使用。“單AZ單存儲池”可支持商用，但從可靠性角度建議采用“單AZ多存儲池”。ToB、ToC網元共存儲池。安全、VIM，在硬件分區A的存儲集群劃分1個存儲池，避免跨區訪問。
2、卷類型復用說明：
不同卷QoS要求的業務不共卷類型。不同廠家不共卷類型。ToB、ToC共存儲池場景下，ToB、ToC網元采用相同的卷類型。不同解決方案不共卷類型，UNC和用戶數據劃分不同卷類型。
3、卷類型個數：
每5GC VNF（含UNC/UDM/PCF）部署需要3個卷類型。每CS/IMS VNF部署需要2個卷類型。每AZ給MAE-CN規劃2個卷類型，分別為NFVO/G-VNFM、OMC/S-VNFM提供存儲。

卷類型名稱（假如多類網元都在一個存儲池中）：
自定義部分需包含后端存儲配置名稱關鍵字、用途類型、廠家標識、業務標識與序號，例如：
NFV-R-HNZJI-01A-HW-01-VOLT-A102-S-HW-USC01/02/03（用于部署融合數據網元）
NFV-R-HNZJI-01A-HW-01-VOLT-A102-S-HW-UNC01/02/03（用于部署數據域網元）
NFV-R-HNZJI-01A-HW-01-VOLT-A102-S-HW-SPS01/02（用于部署信令域網元）
NFV-R-HNZJI-01A-HW-01-VOLT-A102-S-HW-CMN01/02（用于部署CS域網元）
NFV-R-HNZJI-01A-HW-01-VOLT-A102-S-HW-SVC01/02(用于部署二層增強資源池的IMS網元)
NFV-R-HNZJI-01A-HW-01-VOLT-A102-S-HW-ENS01/02(用于部署二層增強資源池的融合數據EnumDNS網元，不一定每資源池都有)

FusionStage作為容器化VNF的遠端生命周期管理模塊，FusionStage 和VNFM的關系如下：
VNFM負責VNF生命周期管理動作，觸發網元虛擬機創建任務。
FusionStage作為VNFM遠端模塊，負責容器化VNF(workload)的管理。
VNFM完成虛擬機創建后通知FusionStage執行虛擬機納管(作為容器集群的node)和容器化VNF的實例化等生命周期管理。

4套PaaS管理面VM全部部署在管理AZ、管理HA（指定服務器部署）。
4套PaaS所管轄的VNF按如下原則劃分：按AZ劃分，2B/2C VNF共享PaaS，建議VNF根據自身的容量和目標擴容規格，規劃部署時采用的PaaS，同一省的2B、2C網元分別在同一AZ的2套PAAS中輪選。
PaaS1/PaaS3：管理AZ1的 網元；PaaS2/PaaS4：管理AZ2的 網元

OpenStack 本身不會虛擬化資源，但會使用虛擬化資源來構建云。OpenStack 也不執行命令，但會將命令轉發到基礎 OS。OpenStack、虛擬化軟件和基礎操作系統，這 3 種技術必須協同工作。正是由于這種相互依賴性，所以許多人才會使用 Linux? 來部署 OpenStack 云，也因此，RackSpace 和 NASA 才會將 OpenStack 作為開源軟件來發布

glance-api 后臺運行的服務進程，對外提供restapi，響應對鏡像的查詢，獲取和存儲的調用，服務安裝在usr/bin/目錄下
glane-api不會真正處理請求，會轉發給glance-registry（負責處理和存取 image 的 metadata，例如image 的大小和類型）和store backend（與image自身存取相關的操作）
glance支持的image格式類型：qcow2、iso、raw、vhd、vmdk、vdi、aki、ari、ami
metadate數據存儲在datebase中（數據庫，默認是mysql）
支持的store backend類型：1、A directory on a local file system本地文件（這是默認配置）2、GridFS ?3、Ceph RBD ?4、Amazon S3 ?5、Sheepdog ?6、OpenStack Block Storage (Cinder) ?7、OpenStack Object Storage (Swift) ??
具體使用哪種 backend，是在cat /etc/glance/glance-api.conf | grep filesystem_store_datedir配置文件中配置的(現網UPF查到的目錄不是用來放鏡像的)，
openstack默認是在/var/lib/glance/images下，每個 image 在該目錄下都對應有一個文件，文件以 image 的 ID命名
glance創建鏡像（現網叫注冊鏡像）：1、上傳鏡像到控制節點?? ?2、openstack image create "cirros" --file 鏡像文件名 --disk-format qcow2 --container-format bare --public

ps aux | grep glance-api/glance-registry 查看glance進程
openstack image list 查看已存在的鏡像 或者 glance image-list
openstack endpoint list | grep list ?查看nova的endpoints
nova service-list 查看 nova子服務都分布在哪些節點上
cinder service list 查看 cinder-* 子服務都分布在哪些節點上

nova是最核心的部件，nova位于openstack架構中心，其他組件都為nova提供支持，虛擬機生命周期管理就是通過noca實現的 ? ?虛擬機默認保存在計算節點的/var/lib/nova/instances目錄下
用途與功能 :1) 實例生命周期管理?? ?2) 管理計算資源?? ?3) 網絡和認證管理?? ?4)REST 風格的 API?? ??? ?5) 異步的一致性通信?? ?6)Hypervisor
nova組件很多：
nova-api?? ?整個nova組件的門戶，所有對nova的請求都首先由nova-api處理（只要是跟虛擬機生命周期相關的操作，nova-api 都可以響應：關閉/重啟/刪除/重建虛擬機等等），并且兼容Amazon EC2 API
nova-api 對接收到的 HTTP API 請求會做如下處理：1. 檢查客戶端傳入的參數是否合法有效?? ?2. 調用 Nova 其他子服務的處理客戶端 HTTP 請求?? ?3. 格式化 Nova 其他子服務返回的結果并返回給客戶端

nova-scheduler虛機調度服務，負責決定在哪個計算節點上運行虛機。創建虛擬機時，用戶會指定flavor（CPU、內存、磁盤等資源需求定義在flavor）
配置文件：/etc/nova/nova-scheduler.config ?? ?nova 通 過driver=filter_scheduler 這個參數來配置 nova-scheduler
Filter scheduler 是 nova-scheduler 默認的調度器，調度過程分為兩步：1. 通過過濾器filter選擇滿足條件的計算節點（運行 nova-compute）?? ??? ?2. 通過打分（weighting權重計算）選擇在最優（權重值最大）的計算節點上創建虛擬機【目前默認是根據計算節點空閑的內存量計算權重值】
Nova 允許使用第三方 scheduler，配置 scheduler_driver 即可。Scheduler 可以使用多個 filter 依次進行過濾，過濾之后的節點再通過計算權重選出最適合的節點。

nova-compute?? ?是管理虛機的核心服務，在計算節點上運行。通過調用Hypervisor API 實現節點上的 instance 的 生 命 周 期 管 理 。 OpenStack 對instance的操 作，最后都是交給nova-compute來完成的 。
nova-compute與Hypervisor（KVM，Xen， VMWare 等，nova-compute定義了統一的接口）一起實現OpenStack對instance生命周期的管理

nova-conductor ? nova-compute 經常需要更新數據庫，比如更新和獲取虛機的狀態。 出于安全性和伸縮性的考慮，nova-compute 并不會直接訪問數據庫，而是將這個任務委托給 nova-conductor
優勢：1. 更高的系統安全性?? ?2. 更好的系統伸縮性

Console Interface服務：
nova-console： 用戶可以通過多種方式訪問虛機的控制臺：
nova-novncproxy： 基于 Web 瀏覽器的 VNC 訪問
nova-spicehtml5proxy： 基于 HTML5 瀏覽器的 SPICE 訪問
nova-xvpnvncproxy： 基于 Java 客戶端的 VNC 訪問
nova-consoleauth： 負責對訪問虛機控制臺請求提供 Token 認證
nova-cert： 提供 x509 證書支持

Database服務：Nova 會有一些數據需要存放到數據庫中，一般使用 MySQL。數據庫安裝在控制節點上。 Nova使用命名為 “nova” 的數據庫
進入mysql數據：mysql -uroot -p?? ??? ?然后切換服務對應的數據庫，例如use nava、use cinder等
RabbitMQ 和 MySQL 通常放在控制節點上

Nova 包含眾多的子服務，這些子服務之間需要相互協調和通信。為解耦各個子服務，Nova 通過 Message Queue （默認是RabbitMQ，MQ也是opensatck的核心組件）作為子服務的信息中轉站。
1. 只有 nova-compute 需要放在計算節點上。?? ?2. 其他子服務則是放在控制節點上的。（控制節點可以也作為計算節點，也安裝nova-compute服務。rabbitMQ和mysql）

虛擬機創建流程：
1、用戶或者其他程序向 API（nova-api）發送請求：“幫我創建一個虛機”?? ?2、API 對請求做一些必要處理后，向 Messaging（RabbitMQ）發送了一條消息：“讓Scheduler 創建一個虛機”
3、Scheduler（nova-scheduler）從 Messaging 獲取到 API 發給它的消息，然后讓scheduler執行調度算法，從若干計算節點中選出節點 A?? ??? ?4、Scheduler 向 Messaging 發送了一條消息：“在計算節點 A 上創建這個虛機”
計算節點 A 的 Compute（nova-compute）從 Messaging 中獲取到 Scheduler 發給它的消息，然后在本節點的 Hypervisor 上啟動虛機。
在虛機創建的過程中，Compute如果需要查詢或更新數據庫信息，會通過Messaging向Conductor（nova-conductor）發送消息，Conductor負責數據庫訪問。

network?? ?是隔離的二層廣播域（local，flat，vlan，vxlan，gre），一個 subnet 只能屬于某個 network；一個 network 可以有多個 subnet。network 必須屬于某個 Project（ Tenant 租戶），Project 中可以創建多個 network。 network與 Project 之間是 1 對多 關系。
同一 vlan 中的 instance可以通信，不同 vlan 只能通過 router 通信。vlan 網絡可跨節點
vxlan 是基于隧道技術的 overlay 網絡。vxlan 網絡通過唯一的 segmentation ID（也叫 VNI）與其他 vxlan 網絡區分。vxlan 中數據包會通過 VNI 封裝成 UDP 包進行傳輸。因為二層的包通過封裝在三層傳輸，能夠克服 vlan 和物理網絡基礎設施的限制。

subnet子網 是一個ipv4或者ipv6地址段，虛擬機的ip從subnet中分配，subnet 與 port 是 1 對多 關系。一個 port 必須屬于某個 subnet；一個 subnet 可以有多個port
port 虛擬交換機上的端口，當虛擬機的虛擬網卡綁定到port上時，port會將分配mac和ip分配給虛擬機網卡

二層交換：instance是通過虛擬交換機（Linux Bridge 或者 Open vSwitch）連接到虛擬二層網絡的
三層路由：neutron 的 router（IP forwarding 或者 iptables 來實現路由和NAT）實現 instance 跨網段通信
負載均衡：LBaaS 支持多種負載均衡產品和方案，不同的實現以 Plugin（目前默認的是HAProxy）的形式集成到 Neutron
防火墻：兩種方式來保障 instance 和網絡的安全性?? ?1、security group（安全組）通過 iptables 限制進出 instance 的網絡包?? ?2、FWaaS，限制進出虛擬路由器的網絡包，也是通過 iptables 實現

neutron部署方案：
控制節點neutron-server（集成core-plugin-agent和service-plugin-agent）+計算節點core-plugin-agent（提供二層網絡功能）?? ??? ??? ?控制節點和計算節點通過core-plugin-agent建立二層連接
控制節點neutron-server+網絡節點core-plugin-agent/service-plugin-agent+計算節點core-plugin-agent?? ??? ??? ?（適合規模較大的環境）
這個方案的要點是將所有的 agent 從控制節點分離出來，部署到獨立的網絡節點上。控制節點只負責通過 neutron server 響應 API 請求。由獨立的網絡節點實現數據的交換，路由以及 load balance 等高級網絡服務。

網絡流量至少要包含：
Management：用于節點之間 message queue 內部通信以及訪問 database 服務，所有的節點都需要連接到management 網絡。
API：各 組 件 通 過 該 網 絡 向 用 戶 暴 露 API 服 務 。 Keystone, Nova, Neutron, Glance, Cinder, Horizon 的 endpoints 均配置在 API 網絡上。通常，管理員也通過 API 網絡 SSH 管理各個節點
VM：也叫 tenant （租戶）網絡，用于 instance 之間通信。VM 網絡可以選擇的類型包括 local, flat, vlan, vxlan 和 gre。VM 網絡由 Neutron 配置和管理。
External：VM 網絡之外的網絡，該網絡不由 Neutron 管理。 Neutron 可以將router attach 到 External 網絡，為 instance 提供訪問外部網絡的能力。 External 網絡可能是企業的 intranet（內聯網），也可能是 internet。
一般三個網卡：eth0 Management+API?? ?eth1 VM ? ? eth2 External（控制節點，計算節點不需要）

neutron組件：
neutron server 對外提供opensatack網絡的api，并調用plugin處理請求
agent 處理 Plugin 的請求，負責在 network provider 上真正實現各種網絡功能
Queue ? Neutron Server，Plugin 和 Agent 之間通過 Messaging Queue 通信和調用。
Database ? 存放 OpenStack 的網絡狀態信息，包括 Network, Subnet, Port, Router 等。
plugin 處理 Neutron Server 發來的請求，維護 OpenStack 邏輯網絡狀態， 并調用 Agent 處理請求（ML2 plugin，各種 network provider 無需開發自己的 plugin，只需要針對 ML2 開發相應的 driver 就可以了）

plugin按功能分為2類：1、core plugin 維護 Neutron 的netowrk, subnet 和 port 相關資源的信息，與 core plugin 對應的 agent 包括 linux bridge,OVS 等； ?? ?2、service plugin 提供 routing, firewall, load balance 等服務，也有相應的 agent。

network創建流程：
1、Neutron Server 接收到創建 network 的請求，通過 Message Queue（RabbitMQ）通知已注冊的 Linux Bridge Plugin（其中network provider 是 linuxbridge，那么就得使用 linux bridge 的 plungin 和 agent；如果 network provider 換成了OVS 或者物理交換機，plugin 和 agent 也得替換。）
2、Plugin 將要創建的 network 的信息（例如名稱、VLAN ID 等）保存到數據庫中，并通過Message Queue 通知運行在各節點上的 Agent。
3、Agent 收到消息后會在節點上的物理網卡（比如 eth2）上創建 VLAN 設備（比如 eth2.100），并創建 bridge （比如 brqXXX） 橋接 VLAN 設備。

neutron service分層模型：（1. 提供 API 服務。2. 運行 Plugin。）
core api （對外提供管理 network, subnet 和 port 的 RESTful API） ? ?extension API（對外提供管理 router, load balance, firewall ，security groups等資源 的 RESTful API）
Commnon Service：認證和校驗 API 請求（validation、authn、authz）
Neutron Core：Neutron server 的核心處理程序，通過調用相應的 Plugin 處理請求
Core Plugin API：定義了 Core Plgin 的抽象功能集合，Neutron Core 通過該 API 調用相應的Core Plgin?? ??? ??? ?Extension Plugin API：定義了 Service Plgin 的抽象功能集合，Neutron Core 通過該 API 調用相應的 Service Plgin。
Core Plugin：實現了 Core Plugin API，在數據庫中維護 network, subnet 和 port 的狀態，并負責調用相應的 agent 在 network provider 上執行相關操作，比如創建 network。
Service Plugin：實現了 Extension Plugin API，在數據庫中維護 router, load balance, security group 等資源的狀態，并負責調用相應的 agent 在 network provider 上執行相關操作，比如創建 router
DB：數據庫

操作系統獲得存儲空間的方式有2種：
塊存儲：通過某種協議（SAS,SCSI,SAN,iSCSI 等）掛接裸硬盤，然后分區、格式化、創建文件系統；或者直接使用裸硬盤存儲數據（數據庫）。每個裸硬盤也稱為卷volume，從instance角度看每一個volume都是一塊硬盤
文件系統存儲：通過 NFS、CIFS 等 協議，mount 遠程的文件系統（NAS 和 NFS 服務器，以及各種分布式文件系統提供的都是這種存儲）
Cinder 提供block stroage service（vloume從創建到刪除整個生命周期管理）
1、提供 REST API 使用戶能夠查詢和管理 volume、volume snapshot 以及 volume type
2、提供 scheduler 調度 volume 創建請求，合理優化存儲資源的分配
3、通過 driver 架構支持多種 back-end（后端）存儲方式，包括 LVM，NFS，Ceph 和其他諸如 EMC、IBM 等商業存儲產品和方案

cinder-api?? ?客戶端將vloume生命周期相關的請求發送到cinder-api的endpoints指定的地址，cinder-api調用其他子服務處理請求，然后返回處理結果（控制節點）
cinder-volume 管理volume的生命周期（包括 volume 的 create、extend、attach、snapshot、delete 等），運行cinder-volume的節點稱為存儲節點，與volume provider一起實現volume的生命周期管理（cinder-volume自身并不管理存儲設備，存儲設備由volume provider管理）
cinder-volume 會定期向 Cinder 報告存儲節點的空閑容量來做篩選啟動 volume，在 cinder-volume 的配置文件 /etc/cinder/cinder.conf 中 volume_driver 配置項設置該存儲節點使用哪種 volume provider。
volume provider數據的存儲設備，為 volume 提供物理存儲空間（存儲解決方案，市面上有很多），cinder-volume為這些存儲解決方案定義了統一的接口（driver架構，即插即用，一般只需要將driver和cinder-volume放在一起就行，/usr/lib/python2.7/site-packges/cinder/volume/drivers源代碼目錄下有很多driver）
conder-scheduler 通過調度算法選擇最合適的存儲節點創建 volume。創建 Volume 時，cinder-scheduler 會基于容量、Volume Type 等條件選擇出最合適的存儲節點，然后讓其創建 Volume（控制節點）
Message Queue ?Cinder 各個子服務通過消息隊列實現進程間通信和相互協作。因為有了消息隊列，子服務之間實現了解耦，這種松散的結構也是分布式系統的重要特征

volume創建流程：
1、用戶或其他程序）向 API（cinder-api）發送請求：“幫我創建一個 volume”?? ?2、API 對請求做一些必要處理后，向 Messaging（RabbitMQ）發送了一條消息：“讓 Scheduler 創建一個 volume”
3、Scheduler（cinder-scheduler）從 Messaging 獲取到 API 發給它的消息，然后執行調度算法，從若干計存儲點中選出節點 A
4、Scheduler 向 Messaging 發送了一條消息：“讓存儲節點 A 創建這個 volume”，存儲節點 A 的 Volume（cinder-volume）從 Messaging 中獲取到 Scheduler 發給它的消息，然后通過 driver 在 volume provider 上創建 volume。

Horizon（地平線）提供web ui界面進行操作，提供DashBoard（儀表盤）服務

Ceph 分布式文件系統（在國內一些公司的云環境中，通常會采用 ceph 作為 openstack 的唯一后端存儲來提高數據轉發效率）
高性能：a.摒棄了傳統的集中式存儲元數據尋址的方案，采用 CRUSH 算法，數據分布均衡，并行度高。?? ??? ?b.考慮了容災域的隔離，能夠實現各類負載的副本放置規則，例如跨機房、機架感知等。?? ??? ?c. 能夠支持上千個存儲節點的規模，支持 TB 到 PB 級的數據。
高可用：a. 副本數可以靈活控制。?? ??? ?b. 支持故障域分隔，數據強一致性。?? ??? ?c. 多種故障場景自動進行修復自愈。?? ??? ?d. 沒有單點故障，自動管理。
高可擴展性：a. 去中心化。?? ?b. 擴展靈活。?? ??? ?c. 隨著節點增加而線性增長。
特性豐富：a. 支持三種存儲接口：塊存儲（由 RBD 提供，可以直接作為磁盤掛載，內置了容災機制）、文件存儲（提供 POSIX 兼容的網絡文件系統 CephFS，專注于高性能、大容量存儲）、對象存儲（提供 RESTful 接口，也提供多種編程語言綁定。兼容 S3、Swift）。?? ?b. 支持自定義接口，支持多種語言驅動。

RabbitMQ?? ??? ?消息中間件:它接受并轉發消息
（ 1）客戶端連接到消息隊列服務器，打開一個 channel（頻道）。
（ 2）客戶端聲明一個 exchange，并設置相關屬性。
（ 3）客戶端聲明一個 queue（隊列），并設置相關屬性。
（ 4）客戶端使用 routing key，在 exchange 和 queue 之間建立好綁定關系。
（ 5）客戶端投遞消息到 exchange。
（ 6） exchange 接收到消息后，就根據消息的 key 和已經設置的 binding，進行消息路由，將消息投遞到一個或多個隊列里
Rabbitmq 的 metadata：元數據可以放在內存或者磁盤中

Memcached 是一個開源的、高性能的分布式內存對象緩存系統。通過在內存中緩存數據和對象來減少讀取數據庫的次數，從而提高網站訪問速度，加速動態 WEB 應用、減輕數據庫負載。
Memcached 緩存流程
1. 檢查客戶端請求的數據是否在 Memcache中，如果存在，直接將請求的數據返回，不在對數據進行任何操作。
2. 如果請求的數據不在 Memcache 中，就去數據庫查詢，把從數據庫中獲取的數據返回給客戶端，同時把數據緩存一份 Memcache 中
3. 每次更新數據庫的同時更新 Memcache中的數據庫。確保數據信息一致性。
4. 當分配給 Memcache 內存空間用完后，會使用 LRU(least Recently Used ，最近最少使用 ) 策略加到其失效策略，失效的數據首先被替換掉，然后在替換掉最近未使用的數據。

服務器---PHY CPU（物理CPU）---PHY kernel 01 （物理內核）---super thread 01（超線程）---vCPU
超分/復用比 ?可以分配的“總vCPU個數”和“總pCPU個數”之比
內存復用 可以超額分配內存給VM（虛擬機密度提升150%） ?內存共享（只讀），寫時復制 ? ? ? 內存置換 ? ? 內存氣泡

Qos服務質量

external_om（ssh登錄，對接FTP/SFTP，監控主機狀態收集主機性能，系統備份）
external_api（inertnet訪問，VNC登錄，對接OBS）
external_tenant_data 租戶虛擬機與外部網絡通信的平面。
tunnel_bearing 租戶虛擬機所使用的VXLAN網絡所承載的系統平面
internal_base ?I層程序互通平面，所有主機上的i層程序基于此平面通信。（Internal_Base平面只支持64位掩碼）
outband_monitor ? FusionSphere OpenStack OM對服務器進行監控所需的網絡（帶外監控平面）
storage_data0 ?內部存儲平面，存儲數據時需要使用。可用于接入華為分布式塊存儲及其他存儲設備網絡
BMC Base 裸金屬
provision 裸金屬

權限管理方式為分角色（區分“操作權限”）、分租戶管理（區分“數據管理范圍”）
日志分為操作日志和運行日志。每個組件輸出的操作日志和運行日志大小分別配置為10M。當日志文件達到10M后進行壓縮歸檔（2~3點）。每個組件對應日志文件的歸檔數量默認是20個。當歸檔數量超出時，自動刪除最老的歸檔日志。

操作系統加固：1、關閉不必要的服務，如屏蔽Telnet服務和FTP服務。?? ?2、加固SSH的服務。?? ?3、控制文件和目錄的訪問權限。?? ?4、限制系統訪問權限。?? ?5、管理用戶密碼。?? ??? ?6、記錄操作日志。?? ??? ?7、檢測系統異常。
GaussDB關系數據庫加固：1、遠程訪問數據庫時支持加密傳輸。2、帳戶密碼加密保存。3、記錄數據庫的操作日志。4、設置高復雜度的帳戶密碼。 ?本地在線備份方式（凌晨2:00執行備份腳本）和異地備份（第三方備份服務器）方式

安全組（Security Group）邏輯上的分組 ? ? 為同一個VPC內具有相同安全保護需求并相互信任的彈性云服務器提供訪問策略

FusionSphere包含：FusionSphere OpenStack、FusionStroage、FusionSphere OpenStack OM
獲取網設、軟件包、本地PC要求、FM虛擬機要求
安裝FusionOpenstack（安裝openstack主機、部署openstack服務、配置分庫節點）
?? ?下電全部主機---PC上啟動FusionSphere_OpenStack_InstallTool安裝工具---選擇語言和安裝包、驅動包---選擇系統配置---本地PC引導安裝首節點（需要先設置主機從PXE啟動）30分鐘---首節點引導安裝其他主機（將其他待安裝的主機設置為從PXE啟動并上電）
?? ? 配置基礎設置、AZ代理、DNS、NTP及高級配置---部署角色（簡單類型：控制節點/計算節點）---修改主機名稱---清除PXE網口配置
?? ? 配置分庫節點部署規模”達到1024主機/10000虛擬機及以上時，需要新增擴展控制節點，，并且需要將gaussdb、rabbitmq分庫
加載驅動軟件（Mellanox驅動包、存儲多路徑包、Hi1822驅動包、IBMA軟件包、inter驅動包、信息收集項軟件包）
配置FusionOpenstack
加載Guest OS驅動軟件、配置VNF計算節點流控參數
安裝FM（安裝OM虛擬機、配置與FS資源對接、配置FTP服務器、配置FS告警上報、配置磁盤類型、配置時間同步/時區、創建主機組、創建VDC/VPC、配置租戶注入文件配額、加載license）

VBS是安裝在用戶系統中的一個代理，當用戶需要存放數據在分布式存儲中時，VBS會先接收用戶的數據，然后對用戶數據進行切塊分區(一般會把數據分成1MB大小的數據分片。

?

?

?

Keystone（鑒權管理）	Keystone是OpenStack框架中，負責身份驗證、服務規則和服務令牌的功能，它實現了OpenStack的Identity API。
Celiometer（度量監控）	Celiometer對資源進行計量和監控。
Glance（鏡像管理）	Glance提供虛擬機鏡像的查詢、上傳和下載服務。
Nova（計算資源管理）	Nova負責虛擬機計算資源的管理，對存儲、鏡像和網絡資源進行協調管理，及虛擬機、裸金屬資源對象生命周期管理功能。
Neutron（網絡資源管理）	Neutron負責虛擬機的網絡資源，支撐虛擬機的數據轉發，為虛擬機分配端口資源、配置IP地址、配置二層互通資源（VLAN、VxLAN等）、提供三層路由。
Heat（業務編排）	Heat可以根據定義的模板，通過調用OpenStack API來編排復雜的云應用。
Cinder（塊存儲管理）	Cinder為云平臺提供統一接口、按需分配的、持久化的塊存儲服務，通過驅動的方式接入不同種類的后端存儲。
Swift（對象存儲管理）	Swift是可擴展的冗余存儲系統。采用完全對稱、面向資源的分布式系統架構設計，所有組件都可擴展，避免因單點失效而擴散并影響整個系統運行。
Ironic（裸金屬服務器發放）	Ironic提供了一系列管理物理機的API接口，可以對“裸”操作系統的物理機進行管理，從物理機上架安裝操作系統到物理機下架維修。
Placement（計算資源池模型管理維護）	提供統一的資源池模型管理維護功能，并配合Nova進行資源對象調度操作。
FusionSphere OpenStack OM	提供云服務的運維能力。
虛擬化池	通過KVM虛擬化技術將計算服務器資源虛擬化后納入統一的虛擬化池，接入FusionSphere OpenStack，供上層業務按需調度。
存儲資源池	為虛擬機提供存儲資源，分為本地存儲和后端存儲。FusionSphere OpenStack實現存儲資源從底層的磁盤到上層虛擬機存儲卷的逐層映射。
網絡資源池	網絡設備接入iMaster NCE-Fabric，提供網絡資源池。

?

總結

以上是生活随笔為你收集整理的开源openstack的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。