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

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

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

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

neutron 網(wǎng)絡資源（IP、Vlan、路由），虛擬機與外部網(wǎng)絡的互通與隔離
數(shù)據(jù)轉發(fā)的集中控制節(jié)點，未來發(fā)展方向是SDN（軟件定義網(wǎng)絡） Controller

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

swift對象存儲 只為glane服務（適合靜態(tài)數(shù)據(jù)，長期存放的）

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

ceilometer 資源的計量和監(jiān)控 ?計量各租戶使用的計算/存儲/網(wǎng)絡資源，從而計費

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

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

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

OVS（open vSwitch 開源以太網(wǎng)虛擬交換機）：傳遞虛擬機VM之間的流量，實現(xiàn)VM和外界網(wǎng)絡的通信
vEPC中OVS用于I層和CSM的數(shù)據(jù)轉發(fā)

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

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

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

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

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

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

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

NUMA （Non-Uniform Memory Access，非一致內存訪問）
當前服務器架構中，一般都會有多個物理CPU，每個物理CPU都有對應的內存資源。這些分配給指定CPU的內存與CPU之間的通信是最快的。另外還可能有IO設備和這個CPU綁定。
這些和CPU綁定的所有內存和IO資源，我們就把其歸為一個NUMA節(jié)點，也稱為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時，即使資源或者其他條件不夠的情況下也必須強制執(zhí)行設置好的反親和性；當取值為false時，會根據(jù)實際情況進度適度的變化;
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組網(wǎng)方案
基于機架服務器網(wǎng)絡架構說明
采用三層架構：TOR+EOR+DC-GW；
TOR，EOR，工作在L2模式，基于VLAN/MAC轉發(fā)。
DC-GW作為業(yè)務&管理 L3GW，同時支持靜態(tài)路由/OSPF/BGP及BFD協(xié)議。
業(yè)務EOR和業(yè)務TOR分別采用M-LAG組網(wǎng)。
DC-GW獨立雙主（兩臺DCGW不同IP不同MAC），之間三層級聯(lián)（BGP/OSPF）。
硬件管理TOR由于對可靠性要求不高，不需要成對配置。
主推用戶面和控制面分機柜部署。
主推用戶面和控制面獨立業(yè)務TOR，共用管理&存儲TOR、共用硬件管理TOR。

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

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

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

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

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

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

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

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

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

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

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

glance-api 后臺運行的服務進程，對外提供restapi，響應對鏡像的查詢，獲取和存儲的調用，服務安裝在usr/bin/目錄下
glane-api不會真正處理請求，會轉發(fā)給glance-registry（負責處理和存取 image 的 metadata，例如image 的大小和類型）和store backend（與image自身存取相關的操作）
glance支持的image格式類型：qcow2、iso、raw、vhd、vmdk、vdi、aki、ari、ami
metadate數(shù)據(jù)存儲在datebase中（數(shù)據(jù)庫，默認是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配置文件中配置的(現(xiàn)網(wǎng)UPF查到的目錄不是用來放鏡像的)，
openstack默認是在/var/lib/glance/images下，每個 image 在該目錄下都對應有一個文件，文件以 image 的 ID命名
glance創(chuàng)建鏡像（現(xiàn)網(wǎng)叫注冊鏡像）：1、上傳鏡像到控制節(jié)點?? ?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子服務都分布在哪些節(jié)點上
cinder service list 查看 cinder-* 子服務都分布在哪些節(jié)點上

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

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

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

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

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

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

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

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

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

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

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

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

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

neutron組件：
neutron server 對外提供opensatack網(wǎng)絡的api，并調用plugin處理請求
agent 處理 Plugin 的請求，負責在 network provider 上真正實現(xiàn)各種網(wǎng)絡功能
Queue ? Neutron Server，Plugin 和 Agent 之間通過 Messaging Queue 通信和調用。
Database ? 存放 OpenStack 的網(wǎng)絡狀態(tài)信息，包括 Network, Subnet, Port, Router 等。
plugin 處理 Neutron Server 發(fā)來的請求，維護 OpenStack 邏輯網(wǎng)絡狀態(tài)， 并調用 Agent 處理請求（ML2 plugin，各種 network provider 無需開發(fā)自己的 plugin，只需要針對 ML2 開發(fā)相應的 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創(chuàng)建流程：
1、Neutron Server 接收到創(chuàng)建 network 的請求，通過 Message Queue（RabbitMQ）通知已注冊的 Linux Bridge Plugin（其中network provider 是 linuxbridge，那么就得使用 linux bridge 的 plungin 和 agent；如果 network provider 換成了OVS 或者物理交換機，plugin 和 agent 也得替換。）
2、Plugin 將要創(chuàng)建的 network 的信息（例如名稱、VLAN ID 等）保存到數(shù)據(jù)庫中，并通過Message Queue 通知運行在各節(jié)點上的 Agent。
3、Agent 收到消息后會在節(jié)點上的物理網(wǎng)卡（比如 eth2）上創(chuàng)建 VLAN 設備（比如 eth2.100），并創(chuàng)建 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：實現(xiàn)了 Core Plugin API，在數(shù)據(jù)庫中維護 network, subnet 和 port 的狀態(tài)，并負責調用相應的 agent 在 network provider 上執(zhí)行相關操作，比如創(chuàng)建 network。
Service Plugin：實現(xiàn)了 Extension Plugin API，在數(shù)據(jù)庫中維護 router, load balance, security group 等資源的狀態(tài)，并負責調用相應的 agent 在 network provider 上執(zhí)行相關操作，比如創(chuàng)建 router
DB：數(shù)據(jù)庫

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

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

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

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

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

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

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

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

Qos服務質量

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

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

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

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

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

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

?

?

?

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

?

總結

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

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