上一節(jié)內容《【重識云原生】第2.4節(jié)——主流虛擬化技術之KVM》
三、商用云主機解決方案
????????在大規(guī)模商用云主機解決方案中，目前頭部廠商大部分是基于KVM來實現(xiàn)各自云主機的虛擬化方案。不過虛擬化技術如果要大規(guī)模商用，僅有KVM還不夠。上述ESXi、Xen、KVM等虛擬化技術方案，均聚焦于單宿主機級別的資源虛擬化實現(xiàn)，而面向整個數(shù)據(jù)中心規(guī)模的大型計算資源的虛擬化，除了解決單宿主機虛擬化問題，還需要大型分布式資源調度系統(tǒng)來真正實現(xiàn)計算資源的全局調度、部署交付、運維管控。云計算行業(yè)經(jīng)過年發(fā)展，確實也先后產(chǎn)生了多種分布式調度實現(xiàn)方案，比較知名的有?Hadoop YARN、Mesos、阿里伏羲、Google Borg、Kubernetes等。
3.1 調度系統(tǒng)架構演進簡述
????????Google 和 UC Berkeley 提出的調度系統(tǒng)的架構演進分類，分為統(tǒng)一調度架構、兩級調度架構和共享狀態(tài)調度架構。
1. 統(tǒng)一調度架構
如上圖所示，左側的架構即為統(tǒng)一調度架構，下方是集群的宿主機；中間是集群狀態(tài)信息，用于保存宿主機的資源狀態(tài)；上方是統(tǒng)一的調度器，負責接收調度請求，并在集群狀態(tài)信息的基礎上進行調度決策。許多調度系統(tǒng)最初都被設計為這種架構，例如第一代 Hadoop MapReduce。
這種架構，設計簡單，可以便捷的保持資源數(shù)據(jù)一致性，但是當宿主機規(guī)模增大時，調度器處理單次資源調度請求的時間會開始增加。當資源調度請求增大到一定程度時，調度器的吞吐量不足，調度請求開始排隊，造成任務阻塞積壓。
2. 兩級調度架構
????????兩級調度系統(tǒng)，其典型代表是 Mesos。Mesos Master 通過 Resource Offer 的形式和上層 Framework 的調度器進行資源通信。在靈活性上和并發(fā)性上有了一定的改善。但是仍然存在局限性。
????????缺乏全局資源視圖。上層調度器只能在分配給它的 Resource Offer 的范圍內進行調度，相當于只有子集資源視圖，沒有全局資源視圖，無法保證調度決策全局最優(yōu)。特別是在需要搶占的情況下，無法實現(xiàn)跨調度器搶占，例如公有云中競價實例的場景。
????????并發(fā)度仍然受限，Resource Offer 機制本質上是在不同的 Framework 之間進行串行輪詢，相當于悲觀加鎖并發(fā)控制，并發(fā)度仍然有提升空間。
????????和 Mesos 同時期的 Hadoop YARN 是另一款著名的分布式調度系統(tǒng)，其類型劃分一直存在爭議。Hadoop YARN 的支持者[3]表示 YARN 是一款兩級調度系統(tǒng)，而 Google 系的研究成果則通常認為 YARN 屬于統(tǒng)一調度架構。我們更加認同 Google 的看法，認為 YARN 屬于統(tǒng)一調度架構。
????????統(tǒng)一調度、兩級調度、共享調度是 Omega 提出的分類方法，這里的調度是指為任務分配資源，而不是處理任務間的關系。在這個前提下，Hadoop YARN 的調度過程是由 Resource Manager 完成的，而 Application Master 主要負責任務間關系的管理工作，并未實際參與調度過程。因此，Hadoop YARN 屬于統(tǒng)一調度架構。
3. 共享狀態(tài)調度架構
????????兩級調度架構在資源視圖、調度并發(fā)度方面存在的問題，業(yè)界提出了共享狀態(tài)調度架構，其典型代表是 Google Borg 和 Omega。調度系統(tǒng)具有多個調度器，調度器之間采用無鎖樂觀并發(fā)機制，每個調度器都具有全局資源視圖，可接收待調度任務，同時進行調度。
????????但是，并發(fā)調度也帶來一個明顯的問題——調度沖突：即多個調度器同時工作并選中了相同的宿主機，只有一個調度器可以調度成功，其余調度器需要重新進行調度。在調度并發(fā)度較大的情況下，其實調度沖突的概率是比較大的，重新調度的代價偏大。
3.2 阿里云方案
????????如下圖所示，在阿里云整體產(chǎn)品體系中，計算產(chǎn)品屬于IaaS基礎服務層，包括云主機ECS、彈性伸縮ESS、資源編排ROS等產(chǎn)品服務。
3.2.1 依托業(yè)務上云生命周期管理設計的計算層產(chǎn)品服務落地方案
????????而從整體計算資源保障體系建設來看，整個彈性計算產(chǎn)品服務可以從下圖看出阿里云的落地解決方案思路，技術底座依然基于飛天云操作系統(tǒng)，包括神龍計算平臺、盤古存儲平臺、洛神虛擬網(wǎng)絡平臺、后裔超大規(guī)模調度平臺，而上層產(chǎn)品服務分為面向業(yè)務應用的資源型產(chǎn)品服務與面向運維用戶的工具型產(chǎn)品服務——資源型產(chǎn)品服務具備包括ECS虛擬機實例服務、彈性裸金屬實例服務、專有宿主機實例服務、ECI彈性容器實例服務、鏡像與客戶機操作系統(tǒng)倉庫服務，運維工具型產(chǎn)品服務包括SMC服務器遷移服務、ROS資源編排服務、OOS運維編排服務、彈性伸縮服務、彈性供應服務，而此兩類服務均支持OpenAPI、控制臺、命令行工具三類管控模式。
????????其中運維工具產(chǎn)品，整體確實是遵循業(yè)務上云的全生命周期管理思路來做的整體解決方案設計，分遷移上云、交付部署、彈性運行、自動運維四個階段提供計算資源層面的產(chǎn)品服務，可以參見下圖：
? ? ? ? 1.在第一階段遷移上云，阿里云考慮了線下服務器遷移上云、軟件鏡像云上存儲、操作系統(tǒng)鏡像云上存儲三類資源層面的場景，當然業(yè)務應用上云是一個很復雜的方案，軟件上云會在微服務、容器等領域方案中闡述，便不在此章細述。
? ? ? ? 2.在資源上云后，在第二階段交付部署環(huán)節(jié)，計算層主要提供計算資源編排服務，在業(yè)務應用的部署方案設定之后，ROS服務來協(xié)助實現(xiàn)應用自動化發(fā)布，完成應用部署前的資源交付與部署工作。
? ? ? ? 3.當應用成功部署上線后，應用程序持續(xù)運行的第三階段，阿里云提供彈性伸縮服務，以應對互聯(lián)網(wǎng)業(yè)務的潮汐流量場景，當然，資源的擴縮容并然后業(yè)務并發(fā)量傳導而來，從而能實現(xiàn)自動化擴縮容。
? ? ? ? 4.除了運行支持，應用的日常運維工作中，自然也包含資源的日常運維部分，此即是阿里云設計的自動運維階段，在此階段與計算資源相關的，阿里云提供了OOS運維編排服務，配合云平臺本身的監(jiān)控、日志服務，以及應用的鏈路監(jiān)控、微服務監(jiān)控等手段，來實現(xiàn)運維自動化的目標。
3.2.2 阿里云大規(guī)模資源調度方案
????????云計算將單臺PC計算能力通過分布式調度軟件連接起來，形成數(shù)以萬計的集群算力，其中最核心的問題是如何把成千上萬臺普通PC機高效組織起來，靈活地進行任務調度和管理，從而可以像使用單臺臺式機一樣無差別使用整朵云的算力。故在云計算底座能力模塊中，最核心的便是分布式調度系統(tǒng)，它好比云計算的中央處理器。目前，業(yè)界已存在多種分布式調度實現(xiàn)方案，如伏羲、Hadoop MapReduce、YARN、Mesos等系統(tǒng)。
3.2.2.1 伏羲調度系統(tǒng)簡介
????????伏羲系統(tǒng)在前人的基礎上進行了一系列改造，首先與YARN和Mesos系統(tǒng)類似，將資源調度和任務調度分離，形成兩層架構，使其具備以下優(yōu)勢：
????????規(guī)模：兩層架構易于橫向擴展，資源管理與調度模塊僅負責資源的整體分配，不負責具體任務調度，可以輕松擴展集群節(jié)點規(guī)模；
????????容錯：當某個任務運行失敗不會影響其他任務的執(zhí)行；同時資源調度失敗也不影響任務調度；
????????擴展性：不同的計算任務可以采用不同的參數(shù)配置和調度策略，同時支持資源搶占；
????????調度效率：計算framework決定資源的生命周期，可以復用資源，提高資源交互效率。
????????這套系統(tǒng)目前已經(jīng)在阿里集團進行了大范圍的應用，能支持單集群5000節(jié)點、并發(fā)運行10000作業(yè)、30分鐘完成100T數(shù)據(jù)terasort，性能是Yahoo在Sort Benchmark的世界紀錄的兩倍。
3.2.2.2 伏羲的系統(tǒng)架構
????????伏羲的系統(tǒng)架構如下圖所示，整個集群包括一臺Fuxi Master以及多臺Tubo。其中Fuxi Master是集群的中控角色，負責資源的管理和調度；Tubo是每臺機器上都有的一個Agent，負責管理本臺機器上的用戶進程；同時集群中還有一個叫Package Manager的角色，用戶的可執(zhí)行程序以及一些配置需要事先打成一個壓縮包并上傳到Package Manager上，Package Manager專門負責集群中包的分發(fā)。
1. 集群部署完后，用戶通過Client端的工具向Fuxi Master提交計算任務；
2. Fuxi Master接收到任務后首先通知某一個Tubo啟動這個計算任務所對應的APP Master；
3. APP Master啟動之后，它獲知了自己的計算任務，包括數(shù)據(jù)分布在哪里、有多少的任務需要計算等等信息；
4. 接著APP Master會向Fuxi Master提交資源申請，表明它需要多少計算資源；
5. Fuxi Master經(jīng)過資源調度以后，將資源的分配結果下發(fā)給APP Master；
6. APP Master在這個資源的基礎之上進行它的任務調度，來決定哪些機器上運行哪些計算任務，并且將這個計算任務發(fā)送給對應機器上的Tubo進程；
7. Tubo接受到命令之后就會從Package Manager中下載對應的可執(zhí)行程序并解壓；
8. 然后啟動用戶的可執(zhí)行程序，加載用戶的配置（上圖中的APP Worker）；
9. APP Worker根據(jù)配置中的信息讀取文件存儲系統(tǒng)中的數(shù)據(jù)，然后進行計算并且將計算結果發(fā)往下一個APP Worker。其中，數(shù)據(jù)的切片稱之為Instance或者叫計算實例。
10. Fuxi Master與Tubo這套結構解決了分布式調度中的資源調度，每個計算任務的APP Master以及一組APP Worker組合起來解決任務調度的問題。
3.2.2.3 任務調度
????????伏羲在進行任務調度時，主要涉及兩個角色：計算框架所需的APP Master以及若干個APP Worker。
1. APP Master首先向Fuxi Master申請/釋放資源；
2. 拿到Fuxi Master分配的資源以后會調度相應的APP Worker到集群中的節(jié)點上，并分配Instance（數(shù)據(jù)切片）到APP Worker；
3. APP Master同時還要負責APP Worker之間的數(shù)據(jù)傳遞以及最終匯總生成Job Status；
4. 同時為了達到容錯效果，APP Master還要負責管理APP Worker的生命周期，例如當發(fā)生故障之后它要負責重啟APP Worker。
????????而APP Worker的職責相對比較簡單，首先它需要接收App Master發(fā)來的Instance，并執(zhí)行用戶計算邏輯；其次它需要不斷地向APP Master報告它的執(zhí)行進度等運行狀態(tài)；其最為主要的任務是負責讀取輸入數(shù)據(jù)，將計算結果寫到輸出文件；此處的Instance是指輸入數(shù)據(jù)的切片。伏羲任務調度系統(tǒng)的技術要點主要包括數(shù)據(jù)的Locality、數(shù)據(jù)的Shuffle以及Instance重試和Backup Instance三點。
數(shù)據(jù)Locality
????????數(shù)據(jù)Locality是指調度時要考慮數(shù)據(jù)的親近性，也就是說APP Worker在處理數(shù)據(jù)時，盡量從本地的磁盤讀取數(shù)據(jù)，輸出也盡量寫到本地磁盤，避免遠程的讀寫。要實現(xiàn)這一目標，在任務調度時，盡量讓Instance（數(shù)據(jù)分片）數(shù)據(jù)最多的節(jié)點上的AppWorker來處理該Instance。
數(shù)據(jù)Shuffle
????????數(shù)據(jù)Shuffle指的是APP Worker之間的數(shù)據(jù)傳遞。在實際運行中，APP Worker之間是有多種傳遞形態(tài)的，如一對一、一對N、M對N等模式。如果用戶去處理不同形態(tài)的傳輸模式，勢必會帶來較大的代價。伏羲分布式調度系統(tǒng)將數(shù)據(jù)傳遞的過程封裝成streamline lib，用戶無需關心數(shù)據(jù)傳遞的細節(jié)。首先Map進行運算，將結果直接交給streamline，streamline底層會根據(jù)不同的配置將數(shù)據(jù)傳給下游計算任務的streamline；然后streamline將接到的數(shù)據(jù)交給上層的計算任務。
Instance重試和backup instance
????????在Instance的運行過程中可能有多種原因導致Instance失敗，比如APP Worker進程重啟或運行時機器、磁盤發(fā)生故障，種種原因都可能導致一個Instance在運行時最終失??；另外APP Master還會監(jiān)控Instance的運行速度，如果發(fā)現(xiàn)Instance運行非常慢（容易造成長尾），會在另外的APP Worker上同時運行該Instance，也就是同時有兩個APP Worker處理同一份數(shù)據(jù)，APP Master會選取最先結束的結果為最終結果。判斷一個Instance運行緩慢的依據(jù)有：
????該Instance運行時間超過其他Instance的平均運行時間；
????該Instance數(shù)據(jù)處理速度低于其他Instance平均值；
????目前已完成的Instance比例，防止在整體任務運行初期發(fā)生誤判。
3.2.2.4 資源調度
????????資源調度要考慮幾個目標：一是集群資源利用率最大化；二是每個任務的資源等待時間最小化；三是能分組控制資源配額；四是能支持臨時緊急任務。在飛天分布式系統(tǒng)中，F(xiàn)uxi Master與Tubo兩者配合完成資源調度。
????????在飛天分布式系統(tǒng)中，F(xiàn)uxi Master與Tubo兩者配合完成資源調度。Tubo是每個節(jié)點都有的，用于收集每個機器的硬件資源（CPU、Memory、Disk、Net），并發(fā)送給FuxiMaster；FuxiMaster是中控節(jié)點，負責整個集群的資源調度。當啟動計算任務時，會生成APP Master，它根據(jù)自己的需要向Fuxi Master申請資源，當計算完成不再需要時，歸還該資源。
????????飛天分布式調度常用的分配資源策略包括優(yōu)先級和搶占、公平調度、配額。在實際應用場景中，不同策略可配合起來使用。
策略之優(yōu)先級和搶占
????????每個Job在提交時會帶一個priority值（整數(shù)值），該值越小優(yōu)先級越高；相同優(yōu)先級按提交時間，先提交的優(yōu)先級高；FuxiMaster在調度時，資源優(yōu)先分配給高優(yōu)先級的Job，剩余的資源繼續(xù)分配給次高優(yōu)先級Job。
????????如果臨時有高優(yōu)先級的緊急任務加入，F(xiàn)uxiMaster會從當前正在運行的任務中，從最低優(yōu)先級任務開始強制收回資源，以分配給緊急任務，此過程稱為“搶占”。搶占遞歸進行，直到被搶任務優(yōu)先級不高于緊急任務，也就是不能搶占比自己優(yōu)先級高的任務。
策略之公平調度
????????公平調度策略是指當有資源時Fuxi Master依次輪詢地將部分資源分配給各個Job，它避免了較大Job搶占全部資源導致其他Job餓死現(xiàn)象發(fā)生。公平調度首先按優(yōu)先級分組，同一優(yōu)先級組內的平均分配，如果有剩余資源再去下一個優(yōu)先級組進行分配，依此類推。
配額
????????配額是資源分配時的第三個策略，通常是按照不同的業(yè)務進行區(qū)分，多個任務組成一個組，例如淘寶、支付寶等；集群管理員會設立每一個組的資源上限，意味著這個組最多能使用這么多CPU、Memory、磁盤等，該上限值稱為Quota；每個組的Job所分配的資源總和不會超過該組內的Quota，當然如果每一個組內沒有用完的Quota是可以分享給其他組的，會按照Quota的比例進行均分。
3.2.2.5 容錯機制
????????在大規(guī)模進程集群中故障是常態(tài)，這些常態(tài)會來自硬件，比如主板、電源、內存條；也可能來自軟件，比如進程有Bug導致進程Crash，機器故障導致性能慢。因此，分布式調度必須具有容錯機制，以保證正在運行的任務不受影響，并對用戶透明，能夠從故障中恢復過來，保障系統(tǒng)的高可用。下面將從任務調度的Failover和資源調度的Failover兩個方面介紹。
AppMaster進程重啟后的任務調度Failover
????????每個計算任務有自己的APP Master，如果APP Master進程發(fā)生了重啟，那其重啟之后的任務調度如何進行Failover呢？這里采用了Snapshot機制，它將Instance的運行進度保存下來，當APP Master重啟之后會自動加載Snapshot以獲取之前每個Instance的執(zhí)行進度，然后繼續(xù)運行Instance；當APP Master進程重啟之后，從APP Worker匯報的狀態(tài)中重建出之前的調度結果，繼續(xù)運行Instance。
FuxiMaster進程重啟后的資源調度Failover
????????另一種情況是Fuxi Master發(fā)生了Failover。Fuxi Master Failover起來之后需要重建內部狀態(tài)，該狀態(tài)通常分為兩種：一是Hard State，主要是之前提交的Application配置信息，如不同的Job配置參數(shù)等，它們來自于Fuxi Master寫的Snapshot；另一類是Soft State，F(xiàn)uxi Master會收集來自各個Tubo以及APP Master的信息重建出自己的狀態(tài)，這些信息包括機器列表、每個APP Master的資源請求以及之前的資源分配結果。
????????Fuxi Master進程重啟之后的資源調度過程如下圖所示，首先會從Checkpoint中讀取出所有Job的配置信息；同時會收集所有的Tubo以及APP Master上報上來的關于資源分配的結果，如CPU多少、Memory多少等等。
規(guī)模挑戰(zhàn)
????????分布式系統(tǒng)設計主要目標之一就是橫向擴展（scale-out），目前阿里云飛天在2013年時已支撐單個集群5000個節(jié)點、并發(fā)1萬個任務。在做橫向擴展設計時，需要注意兩個要點：一是多線程異步；二是增量的資源調度。
多線程異步
????????多線程異步是編寫分布式程序一個非常重要而且常用的技術手段。在網(wǎng)絡通信模塊中，每個APP Master都需要跟Fuxi Master進行資源通信，同時也需要跟多個Tubo進行通信以啟動它們的APP Worker。APP Master處理網(wǎng)絡通信的過程稱之為RPC，RPC通信時必須采用線程池來處理。如圖5中采用四個線程池來處理這些消息。由于Fuxi Master是一個中控節(jié)點，而Tubo的數(shù)量非常眾多，如果將這些消息都在同一個線程池中處理，則Fuxi Master的消息有可能會被大量的Tubo消息阻塞（對頭阻塞問題）。為了解決該問題，在伏羲系統(tǒng)當中設立了一個獨立的線程池來處理Fuxi Master的消息；另外一個線程池來處理Tubo的消息，將線程池進行分開，也稱之為泳道；獨立的泳道能有效解決Fuxi Master的消息被對頭阻塞的問題。
增量的資源調度
????????伏羲解決規(guī)模問題的另一個技術點是增量。目前，伏羲采用增量的消息通信和資源調度，下面通過具體例子，來介紹伏羲所采用的增量資源調度的協(xié)議。
????????上圖左側是中控節(jié)點Fuxi Master；右邊為某一個APP Master，如果說APP Master需要1000份資源，最直接的一種實現(xiàn)方式是將“我要1000個資源”這樣的消息直接發(fā)送給Fuxi Master；Fuxi Master在接到消息之后可能當前的剩余資源只有200份，它將會“我分配給你200”這樣的消息發(fā)送給APP Master；那APP Master還會繼續(xù)發(fā)送消息“我還要剩余的800”，F(xiàn)uxi Master回復“此時沒有資源，我分配0個給你”；則APP Master在下一次通信的時候需要繼續(xù)發(fā)送“我還要剩余的800”……依此類推，可能某一個時刻Fuxi Master還能分一點資源下來。這就是最直觀的全量消息通信，每一次APP Master提出請求時都要指明它總共需要多少。
????????而在伏羲的實現(xiàn)當中為了減小通信量和不必要的開銷，采用了增量的語義。首先APP Master發(fā)送一個請求“我要1000個資源”，F(xiàn)uxi Master收到之后將當時空閑的200個資源返回給APP Master；之后APP Master無需再提交請求說我還需要800，因為Fuxi Master會將這1000個請求記錄下來等到某一時刻又有更多的資源，比如150個資源釋放，它直接將150個分配結果發(fā)送給APP Master即可。這期間APP Master無需再發(fā)多余的網(wǎng)絡通信。
3.2.2.6 安全與性能隔離
????????在分布式系統(tǒng)當中通常有多個用戶在執(zhí)行自己的計算任務，多個任務之間需要互相隔離、互相不影響。飛天伏羲實現(xiàn)了全鏈路的訪問控制，采用了兩種訪問控制進行安全的驗證，一種是Capability，指通信雙方基于私鑰進行解密并驗證的一種方式；還有一種稱為Token的方式，這種方式需要通信的雙方臨時生成基于私鑰加密的口令，在通信時進行驗證。
????????兩種方式最大區(qū)別在于口令生成的時機，Capability方式是在通信之前就已經(jīng)加密好；而Token是需要在通信時臨時生成。
????????兩種方式使用于不同的場景，如上圖所示FuxiMaster與Tubo通信采用的是Capability方式，因為這兩個角色在集群部署時就已啟動，可以事先進行加密生成好Capability；FuxiMaster與APP之間是采用Token的方式，這是因為APP與FuxiMaster進行通信時，當每個任務執(zhí)行完計算之后會退出；在進程與進程之間，伏羲采用了沙箱的方式將不同的進程進行隔離開、互不干擾。
????????除了安全的隔離之外，還需要考慮性能的隔離。目前伏羲采用的幾種技術手段：Cgroup（Linux LXC）、Docker container、VM等。這幾種技術的隔離性、資源配額/度量、移動性、安全性的比較如下圖所示，不再一一敘述。
????????伏羲目前采用的隔離技術是基于Docker和LXC混合部署的方式，之所以拋棄虛擬機的方式，是因為其性能損耗太多。當運行計算任務時，如果完全放在虛擬機當中，它的IO以及CPU時間片會受到很大的影響，會降低任務的執(zhí)行效率。在目前阿里的生產(chǎn)環(huán)境中，實踐發(fā)現(xiàn)基于Docker和LXC的隔離技術已經(jīng)可以很好地滿足需求。
3.2.2.7 分布式調度的發(fā)展方向
????????隨著計算能力和數(shù)據(jù)量的持續(xù)增長，分布式調度未來可能朝向以下幾個方向發(fā)展：
????????在線服務與離線任務混跑。云計算最終的目的是降低IT成本，最大限度地利用單臺PC的CPU處理能力，所以未來的趨勢一定是在線服務與離線任務能夠在同一物理集群上運行從而實現(xiàn)削峰填谷效果、最大化提高集群利用率。但是由于兩種任務的特點不同，在線運用對于響應時間要求很高，而離線運用則對調度的吞吐率要求比較高，因此混跑會帶來性能隔離與資源利用率之間的矛盾。
????????實時計算的發(fā)展，Map Reduce是一個很偉大的框架，但其是為數(shù)據(jù)量一定的批處理而設計的。隨著云計算越來越普及，很多計算形態(tài)需要實時拿到計算結果，并且其輸入數(shù)據(jù)可能是不間斷的。目前，伏羲也已經(jīng)開發(fā)出了實時的計算框架——OnlineJob，它可以提供更快的執(zhí)行速度。
????????更大的規(guī)模，目前已能夠支撐5000臺的節(jié)點，隨著計算量越來越大，客戶的需求越來越多，需要進一步優(yōu)化伏羲系統(tǒng)，能夠支撐起1萬、5萬、10萬等更大規(guī)模單集群，同時能夠支撐更多的并發(fā)任務。
3.3 騰訊云方案
3.3.1 計算產(chǎn)品服務簡述
????????在騰訊云的產(chǎn)品全景圖中，計算屬于IaaS層服務，對外提供云服務器CVM、裸金屬服務BMS、彈性伸縮AS以及專有宿主機服務CDH等產(chǎn)品服務。
????????騰訊云云服務器CVM的實現(xiàn)基于開源KVM方案，不過全云資源調度方案基于自研VStation實現(xiàn)。KVM實現(xiàn)方案因前文已經(jīng)詳述，接下來著重講述VStation的機制。
3.3.2 VStation實現(xiàn)機制
????????騰訊云的 VStation 從誕生之初，便肩負著大規(guī)模調度、海量并發(fā)和支持異構計算的歷史使命，歷經(jīng)五年的打磨和歷練，VStation 通過消息壓縮、鏡像緩存、快照回滾等系列優(yōu)化實踐，實現(xiàn)了生產(chǎn)吞吐率從數(shù)百臺/分鐘到數(shù)萬臺/分鐘、平均創(chuàng)建時間由300秒下降到30秒以下的驚人蛻變。
3.3.2.1 VStation 總體架構
作為騰訊云新一代的調度系統(tǒng)，VStation 承載了騰訊云 CVM 后臺的整體集群管理與系統(tǒng)調度，其架構如下圖所示。在 VStation 架構中存在多種模塊：
Compute，是宿主機上的 agent 程序，負責和后端通信，并調用 libvirt 等工具；
Compute Access，是 Compute 與后臺架構通信的一個接入層。
Network，負責云主機的網(wǎng)絡相關操作；
Image，負責云主機的鏡像相關操作；
Scheduler，負責調度功能，為云主機挑選最佳宿主機；
Resource，負責資源數(shù)據(jù)的操作；
Volume，負責磁盤相關操作；
????????在 VStation 中，每個模塊并不直接相互調用，而是監(jiān)聽特定的隊列并提供一個回調函數(shù)，框架會將參數(shù)傳遞給回調函數(shù)執(zhí)行，業(yè)務層的開發(fā)人員只需專注于自身的業(yè)務邏輯，不必關心消息通信，通信會由框架統(tǒng)一進行管理。
????????那么各個模塊如何協(xié)同完成任務的呢？這些模塊會通過消息隊列進行間接通信，具體的通信策略由上層 VStation API 進行配置化，API 定義每個流程需要執(zhí)行的具體步驟和順序。
????????這樣的架構設計理念類似于 Unix，只做一件事并把它做好。每個模塊就像 Unix 中的命令一樣，專注于自身的邏輯，如果它們需要互相組合，開發(fā)人員可以通過上層 API 進行配置化組合。
????????以創(chuàng)建云主機為例，當 VStation API 收到用戶的創(chuàng)建任務時，API 會構造一個消息模板，設置好用戶的參數(shù)，填充好預先定義的配置步驟，按照配置步驟發(fā)送給第一個步驟對應的模塊，第一個步驟的模塊執(zhí)行完成后會發(fā)送給第二個步驟的模塊，依次類推。Scheduler 則屬于其中的一個模塊，其中的一個消費者收到任務信息后，選擇合適的選宿主機，當完成調度后，將數(shù)據(jù)包轉發(fā)給下一個接收模塊進行處理。最后所有的步驟按照配置的順序執(zhí)行完成，虛擬機創(chuàng)建流程也就自然完成了。
3.3.2.2 VStation 的調度架構與優(yōu)化實踐
調度架構
????????VStation 的調度架構，本質上與 Google Borg/Omega類似，采用共享狀態(tài)調度架構，眾多調度器采用無鎖樂觀并發(fā)機制、基于全局資源視圖進行調度決策，顯著提升了調度器的吞吐率； 提交調度結果保證事務性，保證資源數(shù)據(jù)的強一致性。另一方面，針對 Google Omega 存在的隱患，對調度沖突進行優(yōu)化。
????????總體來說，調度過程包括資源同步、調度決策和提交調度結果三個環(huán)節(jié)。
資源同步
????????調度器在接收待調度虛擬機后，會先進行資源同步，拉取集群狀態(tài)信息，以此為數(shù)據(jù)基礎進行調度決策。資源同步操作在邏輯上看較為直觀，但是在超大規(guī)模數(shù)據(jù)中心中遇到了挑戰(zhàn)。騰訊云單個 Region 宿主機的規(guī)模達到了十萬量級，調度器達到了數(shù)百規(guī)模，即調度總量數(shù)據(jù)為千萬級規(guī)模，即使使用高配置的數(shù)據(jù)庫集群也會在調度高峰時出現(xiàn)明顯的延遲。
????????為此，我們采用私有緩存和增量更新的方法拉取數(shù)據(jù)。調度器啟動后首次調度時，會全量拉取數(shù)據(jù)，并緩存在調度器本地內存中，形成私有緩存；后續(xù)調度時會根據(jù)時間戳進行增量更新，對上一次調度之后發(fā)生變化的數(shù)據(jù)進行更新。這樣，在大規(guī)模調度的場景下，同步數(shù)據(jù)量可減少95%以上。
調度決策
????????在資源同步之后，調度器會在全局資源視圖的基礎上，為虛擬機選擇合適的宿主機，整體包括3個環(huán)節(jié)過濾、排序和打散。
????????過濾，應對硬性約束。根據(jù)虛擬機信息中的資源需求和私有緩存中的宿主機信息，對宿主機集合進行過濾，保留符合標準的宿主機，剔除不符合標準的宿主機，得到候選宿主機列表。
????????排序，應對軟性約束。根據(jù)候選宿主機列表，計算每臺宿主機多個維度的優(yōu)先級值，并對宿主機進行優(yōu)先級排序，得到候選宿主機排序列表。\\t
????????打散。根據(jù)候選宿主機排序列表，對其中第一檔前 k 個宿主機進行隨機打散重新排序，得到新的排序列表，這樣做的目的是防止眾多調度器在并發(fā)場景下都選擇相同的宿主機，盡量防止調度沖突，降低其發(fā)生概率。
提交調度結果
????????VStation 提交調度結果，會保證資源數(shù)據(jù)更新的事務性。這一點非常重要，因為在并發(fā)調度的場景下，很容易出現(xiàn)調度沖突，我們通過事務來保證資源數(shù)據(jù)的一致性。主要環(huán)節(jié)如下：
????按序遍歷宿主機候選列表；
????對當前宿主機模擬扣減資源；
????提交資源變更事務：更新資源數(shù)據(jù)、反親和性記錄；
????如果事務成功，則本次調度成功，同時更新私有緩存中的數(shù)據(jù)；
????如果事務多次失敗，則發(fā)生調度沖突，嘗試下一臺宿主機；
????如果發(fā)生調度沖突，VStation 會選擇次優(yōu)宿主機。相比 Google Omega 重新調度的做法，對調度沖突的處理代價顯著減小。在公有云海量并發(fā)創(chuàng)建的場景下，VStation 在調度決策和調度吞吐率進行權衡，選擇次優(yōu)解來保證調度吞吐率。
海量并發(fā)場景下的極速創(chuàng)建
????在調度專題優(yōu)化以外，針對其他問題，VStation 也進行了相應優(yōu)化，包括：
????消息壓縮、合并，提升系統(tǒng)內部消息流轉效率；
????宿主機緩存高頻使用鏡像，調度器優(yōu)先選擇命中鏡像緩存的鏡像，盡量避免下載鏡像；
????采用 CBS 云盤快照回滾技術，避免下載鏡像，減少創(chuàng)建時間；
????????結合這些技術優(yōu)化，VStation 生產(chǎn)流程的整體吞吐率得到了大幅提升。在十萬量級的宿主機環(huán)境下，采用數(shù)百個 Scheduler 消費者，我們對 CVM 進行了多次海量并發(fā)創(chuàng)建演習，生產(chǎn)吞吐率從原來的數(shù)百臺/分鐘提升到數(shù)萬臺/分鐘；而平均創(chuàng)建時間降低了90%，部分公有鏡像的創(chuàng)建時間更是可以縮減到10秒以內。成功應對了2016、2017年以來的海量并發(fā)創(chuàng)建的挑戰(zhàn)，為騰訊云 CVM 業(yè)務的爆發(fā)式增長提供了堅實的技術基礎。
3.3.2.3 騰訊云分布式調度系統(tǒng)的技術優(yōu)勢
????????與業(yè)界系統(tǒng)對比，VStation 具有大規(guī)模調度能力、速度快、高可用、支持異構計算調度等方面的優(yōu)勢：
????????速度快：VStation 在騰訊云數(shù)十萬集群規(guī)模中，得到了充分的考驗。結合騰訊云的真實業(yè)務場景來看，調度模塊的吞吐量可達每分鐘數(shù)萬臺，整個系統(tǒng)的生產(chǎn)吞吐率可達每分鐘數(shù)萬臺，相比業(yè)界 OpenStack Nova，其并發(fā)調度和創(chuàng)建100臺虛擬機，則系統(tǒng)運行開始變慢，在沖突加劇的場景則會導致創(chuàng)建失敗，需要重新進行調度資源，調度效率低。
????????高可用：得益于框架的能力，VStation 的每個調度進程都是無狀態(tài)、可平行擴容的。同時，在一些特殊情況如消費者崩潰、MQ 崩潰等極端場景下，VStation 能夠基于 MQ 的 ACK 機制、Mirror 機制、消息持久化機制等，將未執(zhí)行完成的消息重新發(fā)送給活躍的進程，重新進行調度。
????????支持異構計算：隨著硬件產(chǎn)品的豐富，例如 GPU、FPGA、智能網(wǎng)卡等專用設備的出現(xiàn)，以前的調度系統(tǒng)也需要考慮相關新硬件的資源統(tǒng)籌調度。在 VStation 中，針對這類的 PCI 設備進行統(tǒng)一管理，可以快速適配和納管新型異構硬件。
3.3.2.4 未來改進策略
任務間調度
????????目前，VStation 側重點是一個資源調度系統(tǒng)，未來會對加強任務間的管理與調度，能夠對任務關系和資源統(tǒng)一進行管理，整合資源的負載情況，做出最優(yōu)的調度決策。
調度系統(tǒng)的可視化運營
????????對于資源運營同學來看，資源調度的內部邏輯相當于黑盒。例如這臺宿主機為何沒有被分配資源，整個調度過程是如何層層篩選的、又是如何優(yōu)選排序的等運營問題。VStation后續(xù)計劃開發(fā)一個為調度系統(tǒng)服務的實時可視化系統(tǒng)，使得調度邏輯更加透明化、直觀化，讓使用的人員可以了解調度系統(tǒng)的內部運行機制。
3.4 OpenStack - Nova 方案
3.4.1 Nova簡介
????????Nova是OpenStack最核心的服務模塊，負責管理和維護云計算環(huán)境的計算資源，負責整個云環(huán)境虛擬機生命周期的管理。Nova和Swift是OpenStack最早誕生的兩個組件。Nova分為控制節(jié)點和計算節(jié)點，計算節(jié)點通過Nova Computer進行虛擬機創(chuàng)建，通過libvirt調用kvm創(chuàng)建虛擬機。Nova之間通信通過rabbitMQ隊列進行通信。如下圖所示，Nova位于Openstack架構的中心，其他服務或者組件（比如Glance、Cinder、Neutron等）對它提供支持——Glance 為 VM 提供鏡像，Cinder 和?Swift?分別為 VM 提供塊存儲和對象存儲，Neutron 為 VM 提供網(wǎng)絡連接。
3.4.2 Nova系統(tǒng)架構
????????Nova 邏輯架構如下圖所示（紅色方框內為 Nova 組件，方框外為 Nova 和 OpenStack 其他服務之間的調用關系）：?
3.4.3 Nova工作流程
??????? 1. 界面或命令行通過RESTful API向keystone獲取認證信息。
??????? 2. keystone通過用戶請求認證信息，正確后生成token返回給對應的認證請求。
??????? 3. 界面或命令行通過RESTful API向nova-api發(fā)送一個創(chuàng)建虛擬機的請求（攜帶token）。
??????? 4. nova-api接受請求后向keystone發(fā)送認證請求，查看token是否為有效用戶。
??????? 5. keystone驗證token是否有效，如有效則返回有效的認證和對應的角色（注：有些操作需要有角色權限才能操作）。
??????? 6. 通過認證后nova-api檢查創(chuàng)建虛擬機參數(shù)是否有效合法后和數(shù)據(jù)庫通訊。
??????? 7. 當所有的參數(shù)有效后初始化新建虛擬機的數(shù)據(jù)庫記錄。
??????? 8.?nova-api通過rpc.call向nova-scheduler請求是否有創(chuàng)建虛擬機的資源(Host ID)。
??????? 9. nova-scheduler進程偵聽消息隊列，獲取nova-api的請求。
?????? 10. nova-scheduler通過查詢nova數(shù)據(jù)庫中計算資源的情況，并通過調度算法計算符合虛擬機創(chuàng)建需要的主機。
?????? 11. 對于有符合虛擬機創(chuàng)建的主機，nova-scheduler更新數(shù)據(jù)庫中虛擬機對應的物理主機信息。
?????? 12. nova-scheduler通過rpc.cast向nova-compute發(fā)送對應的創(chuàng)建虛擬機請求的消息。
?????? 13. nova-compute會從對應的消息隊列中獲取創(chuàng)建虛擬機請求的消息。
?????? 14. nova-compute通過rpc.call向nova-conductor請求獲取虛擬機消息。
?????? 15. nova-conductor從消息隊隊列中拿到nova-compute請求消息。
?????? 16. nova-conductor根據(jù)消息查詢虛擬機對應的信息。
?????? 17. nova-conductor從數(shù)據(jù)庫中獲得虛擬機對應信息。
?????? 18. nova-conductor把虛擬機信息通過消息的方式發(fā)送到消息隊列中。
?????? 19. nova-compute從對應的消息隊列中獲取虛擬機信息消息。
??????? 20. nova-compute通過keystone的RESTfull API拿到認證的token，并通過HTTP請求glance-api獲取創(chuàng)建虛擬機所需要鏡像。
??????? 21. glance-api向keystone認證token是否有效，并返回驗證結果。
??????? 22. token驗證通過，nova-compute獲得虛擬機鏡像信息(URL)。
??????? 23. nova-compute通過keystone的RESTfull API拿到認證k的token，并通過HTTP請求neutron-server獲取創(chuàng)建虛擬機所需要的網(wǎng)絡信息。
??????? 24. neutron-server向keystone認證token是否有效，并返回驗證結果。
??????? 25. token驗證通過，nova-compute獲得虛擬機網(wǎng)絡信息。
??????? 26. nova-compute通過keystone的RESTfull API拿到認證的token，并通過HTTP請求cinder-api獲取創(chuàng)建虛擬機所需要的持久化存儲信息。
??????? 27. cinder-api向keystone認證token是否有效，并返回驗證結果。
??????? 28. token驗證通過，nova-compute獲得虛擬機持久化存儲信息。
??????? 29. nova-compute根據(jù)instance的信息調用配置的虛擬化驅動來創(chuàng)建虛擬機。
3.4.4 Nova組件設計思想
????????Nova 組件設計思想，其實也是 OpenStack 的組件設計思想，OpenStack 的所有組件設計都遵循此思想：
1. API 前端服務
????????nova-api 作為 Nova 組件對外的唯一窗口，向客戶暴露 Nova 能夠提供的功能。當客戶需要執(zhí)行虛機相關的操作，能且只能向 nova-api 發(fā)送 REST 請求。
????????設計 API 前端服務的好處在于：
????對外提供統(tǒng)一接口，隱藏實現(xiàn)細節(jié)
????API 提供 REST 標準調用服務，便于與第三方系統(tǒng)集成
????可以通過運行多個 API 服務實例輕松實現(xiàn) API 的高可用，比如運行多個 nova-api 進程
2. Scheduler 調度服務
????????對于某項操作，如果有多個實體都能夠完成任務，那么通常會有一個 scheduler 負責從這些實體中挑選出一個最合適的來執(zhí)行操作。
????????Nova 有多個計算節(jié)點， 當需要創(chuàng)建虛機時，nova-scheduler 會根據(jù)計算節(jié)點當時的資源使用情況選擇一個最合適的計算節(jié)點來運行虛機。
????????除了 Nova，塊服務組件 Cinder 也有 scheduler 子服務。
3. Worker 工作服務
????????調度服務只管分配任務，真正執(zhí)行任務的是 Worker 工作服務。
????????在 Nova 中，這個 Worker 就是 nova-compute 了。 將 Scheduler 和 Worker 從職能上進行劃分使得 OpenStack 非常容易擴展：
????????當計算資源不夠了無法創(chuàng)建虛機時，可以增加計算節(jié)點（增加 Worker）
????????當客戶的請求量太大調度不過來時，可以增加 Scheduler
4. Driver 框架
????????OpenStack 作為開放的云操作系統(tǒng)，支持業(yè)界各種優(yōu)秀的技術。這種開放的架構使得 OpenStack 能夠在技術上保持先進性，具有很強的競爭力，同時又不會造成廠商鎖定（Lock-in）。OpenStack 的這種開放性一個重要的方面就是采用基于 Driver 的框架。
????????以 Nova 為例，OpenStack 的計算節(jié)點支持多種 Hypervisor。 包括 KVM, Hyper-V, VMWare, Xen, Docker, LXC 等。
????????nova-compute 為這些 Hypervisor 定義了統(tǒng)一的接口，hypervisor 只需要實現(xiàn)這些接口，就可以 driver 的形式即插即用到 OpenStack 中。
????????Glance、Cinder 和 Neutron 都有 driver 框架的應用 。
5. Messaging 服務
????????nova-* 子服務之間的調用嚴重依賴 Messaging。Messaging 是 nova-* 子服務交互的中樞。帶來以下好處：
????????解耦各子服務。子服務不需要知道其他服務在哪里運行，只需要發(fā)送消息給 Messaging 就能完成調用。
????????提高性能。異步調用使得調用者無需等待結果返回。這樣可以繼續(xù)執(zhí)行更多的工作，提高系統(tǒng)總的吞吐量。
????????提高伸縮性。子服務可以根據(jù)需要進行擴展，啟動更多的實例處理更多的請求，在提高可用性的同時也提高了整個系統(tǒng)的伸縮性。而且這種變化不會影響到其他子服務，也就是說變化對別人是透明的。
6. Database
????????OpenStack 各組件都需要維護自己的狀態(tài)信息。比如 Nova 中有虛機的規(guī)格、狀態(tài)，這些信息都是在數(shù)據(jù)庫中維護的。每個 OpenStack 組件都有自己的數(shù)據(jù)庫。
7. 基于分離設備驅動模型實現(xiàn)的I/O虛擬化
????????為了提升I/O虛擬化性能，子系統(tǒng)采用分離設備驅動模型實現(xiàn)I/O的虛擬化。該模型將設備驅動劃分為前端驅動程序、后端驅動程序和原生驅動三個部分，其中前端驅動在虛擬機中運行，而后端驅動和原生驅動則在VMM中運行。前端驅動負責將虛擬機的I/O請求傳遞到VMM中的后端驅動，后端驅動解析I/O請求并映射到物理設備，提交給相應的設備驅動程序控制硬件完成I/O操作。
總結 Nova 組件設計思想的特點：
????????分布式：由多個邏輯和物理上均可分離的組件組成，實現(xiàn)靈活部署；
????????無中心：可以通過增加組件部署實例來實現(xiàn)水平擴展；
????????無狀態(tài)：所有組件無本地持久化狀態(tài)數(shù)據(jù)；
????????異步執(zhí)行：大部分執(zhí)行流通過消息機制實現(xiàn)異步執(zhí)行；
????????插件化、可配置：大量使用插件機制、配置參數(shù)實現(xiàn)靈活的擴展與變更；
????????RESTful API：支持 RESTful 方式訪問的 API，方便客戶端訪問，方便集成到其他應用系統(tǒng)
3.4.5 Nova各組件功能簡介
3.4.5.1 Nova-api
????????nova-api 是整個 Nova 組件的門戶，所有對 Nova 的請求都首先由 nova-api 處理。 nova-api 向外界暴露若干 HTTP REST API 接口。OpenStack CLI，Dashboard 和其他需要跟 Nova 交換的組件會使用這些 API。Nova接收到外部的請求并通過Message Queue將請求發(fā)送給其他的服務組件，同時也兼容EC2 API，所以也可以用EC2的管理工具對nova進行日常管理。
? ? ? ? 在 keystone 中我們可以查詢 nova-api 的 endponits?？蛻舳司涂梢詫⒄埱蟀l(fā)送到 endponits 指定的地址，向 nova-api 請求操作。
????????nova-api 對接收到的 HTTP API 請求會做如下處理：
1）檢查客戶端傳人的參數(shù)是否合法有效
2）調用 Nova 其他子服務的處理客戶端 HTTP 請求
3）格式化 Nova 其他子服務返回的結果并返回給客戶端
????????只要是跟虛擬機生命周期相關的操作，nova-api 都可以響應。大部分操作都可以在 Dashboard 上找到。
3.4.5.2 Nova-scheduler
????????nova-scheduler是調度組件，決策虛擬機創(chuàng)建在哪個宿主機（計算節(jié)點）上。當用戶提出創(chuàng)建虛擬機實例的資源需求，例如 CPU、內存、磁盤各需要多少，OpenStack將這些需求定義在 flavor 中，用戶只需要指定用哪個 flavor 就可以了。nova-scheduler 會按照 flavor 去選擇合適的計算節(jié)點。
? ? ? ? zcdOpenStack 的虛擬機調度策略主要是由 FilterScheduler 和 ChanceScheduler 實現(xiàn)的，其中FilterScheduler 作為默認的調度器實現(xiàn)了基于主機過濾(filtering)和權值計算(weighing)的調度算法，而 ChanceScheduler 則是基于隨機算法來選擇可用主機的簡單調度器。
????????總體而言，決策一個虛擬機應該調度到某物理節(jié)點，需要分為兩個步驟：
? ? ?1.?過濾（filter）：過濾出可以創(chuàng)建虛擬機的主機。
???? 2. 計算權值（weight）：根據(jù)權重大小進行分配，默認根據(jù)資源可用空間進行權重排序。?
?3.4.5.3 Nova-compute
????????nova-compute負責虛擬機的生命周期管理，創(chuàng)建并終止虛擬機實例的工作后臺程序hypervisor api。
????????nova-compute 在計算節(jié)點上運行，負責管理節(jié)點上的實例。OpenStack 對實例的操作，最后都是交給 nova-compute 來完成。nova-compute 與 Hypervisor 一起實現(xiàn) OpenStack 對實例生命周期的管理。
????????由前面介紹的 Driver 框架可知，nova-compute 通過 Driver 架構支持多種 Hypervisor。nova-compute 為各種 Hypervisor 定義了統(tǒng)一的接口，Hypervisor 只需要實現(xiàn)這些接口，就可以 Driver 的形式即插即用到 OpenStack 系統(tǒng)中。可以在 /nova/nova/virt/ 目錄下查看到 OpenStack 源代碼中已經(jīng)自帶了上面這幾個 Hypervisor 的 Driver。
????????某個特定的計算節(jié)點上只會運行一種 Hypervisor，只需在該節(jié)點 nova-compute 的配置文件 /etc/nova/nova.conf 中配置所對應的 compute_driver 就可以了。
nova-compute 的功能可以分為兩類：
????????定時向 OpenStack 報告計算節(jié)點的狀態(tài)，每隔一段時間，nova-compute 就會報告當前計算節(jié)點的資源使用情況和 nova-compute 服務狀態(tài)?？梢圆榭慈罩?/var/log/nova/nova-compute.log。這樣OpenStack 就能得知每個計算節(jié)點的 vcpu、ram、disk 等信息。nova-scheduler 的很多 Filter 才能根據(jù)計算節(jié)點的資源使用情況進行過濾，選擇符合 flavor 要求的計算節(jié)點。
????????實現(xiàn)實例生命周期的管理，OpenStack 對實例最主要的操作都是通過 nova-compute 實現(xiàn)的，包括實例的啟動、關閉、重啟、暫停、恢復、刪除、調整實例大小、遷移、創(chuàng)建快照等。
3.4.5.4?Nova-conductor
???????nova-compute 需要獲取和更新數(shù)據(jù)庫中實例的信息。但 nova-compute 并不會直接訪問數(shù)據(jù)庫，而是通過 nova-conductor 實現(xiàn)數(shù)據(jù)的訪問：
1）實現(xiàn)更高的系統(tǒng)安全性
????????在 OpenStack 的早期版本中，nova-compute 可以直接訪問數(shù)據(jù)庫，但這樣存在非常大的安全隱患。因為 nova-compute 這個服務是部署在計算節(jié)點上的，為了能夠訪問控制節(jié)點上的數(shù)據(jù)庫，就必須在計算節(jié)點的 /etc/nova/nova.conf 中配置訪問數(shù)據(jù)庫的連接信息。如果任意一個計算節(jié)點被黑客入侵，都會導致部署在控制節(jié)點上的數(shù)據(jù)庫面臨極大風險。
????????為了解決這個問題，從 G 版本開始，Nova 引入了一個新服務 nova-conductor，將 nova-compute 訪問數(shù)據(jù)庫的全部操作都放到 nova-conductor 中，而且 nova-conductor 是部署在控制節(jié)點上的。這樣就避免了 nova-compute 直接訪問數(shù)據(jù)庫，增加了系統(tǒng)的安全性。
2）實現(xiàn)更好的系統(tǒng)伸縮性
????????nova-compute 與 nova-conductor 是通過消息中間件交互的。這種松散的架構允許配置多個 nova-conductor 實例。在一個大規(guī)模的 OpenStack 部署環(huán)境里，管理員可以通過增加 nova-conductor 的數(shù)量來應對日益增長的計算節(jié)點對數(shù)據(jù)庫的訪問。
3.4.5.5 Nova-api-metadata
????????nova-api-metadata負責從實例中接收元數(shù)據(jù)請求。nova-api-metadata服務通常在nova-network安裝時使用的是多宿主模式運行。
3.4.5.6 Nova-placement-api
????????nova-placement-api負責跟蹤每個計算提供者的倉庫和使用情況。
3.4.5.7 Nova-consoleauth
????????nova-consoleauth用于控制臺的授權驗證，授權控制臺代理提供的用戶令牌。此服務必須運行用于控制臺代理工作。您可以運行任何類型的代理，而不是集群配置中的單nova-consoleauth服務。
3.4.5.8 Queue
????????Queue用于在守護進程之間傳遞消息的中心。通常使用RabbitMQ也可以用另一個基于AMQP的消息隊列，例如ZeroMQ。
3.4.7 常用操作
??? 一、生命周期和虛擬機管理
??? 二、云主機類型和安全組管理
??? 三、網(wǎng)絡、浮動IP、密匙和配額管理
