云計算工程師日常運維OpenStack管理平臺遇到的坑及難點總結(jié)

云計算工程師日常運維OpenStack管理平臺遇到的坑及難點總結(jié)

金融企業(yè)在云化方面一直勇于探索，創(chuàng)新，很多新興技術(shù)應用總是走在多個行業(yè)的前列。很多企業(yè)都在積極努力的實踐、學習，搭建自己的私有云平臺。為了滿足自主可控的要求和大策略，OpenStack自然成為很多企業(yè)的首選。從部署在測試環(huán)境的探索到生產(chǎn)環(huán)境的實踐，OpenStack是一個靈活性非常強的云管理平臺，各個組件開源獨立，組合多樣。自然就增加了安裝和運維的復雜性和難度。為了讓企業(yè)云計算工程師在日常運維管理openstack平臺的時候能更好的互助解決遇到的坑和難點問題。組織了一場交流，并且整理了交流探討內(nèi)容分享給大家。1、如何把原有虛擬化下的系統(tǒng)遷移到openstack集群？哪種方案可行并更方便？如何把在vmware下的應用系統(tǒng)整體平滑遷移至openstack集群？

1.虛擬機vmdk文件倒進倒出

2.在openstack集群新搭建虛擬機，進行業(yè)務系統(tǒng)遷移

哪種方案可行并更方便？回復1：雖然第二種方式麻煩一些。不過終究還是比較穩(wěn)妥的一種可進可退的方案。只是在一些實際環(huán)境中。一些應用過老。文檔資料不全。技術(shù)支持中斷等原因?qū)е聸]有辦法搭建一個新的環(huán)境。而不得不被迫采用V2V的方式。

我覺得還是要根據(jù)具體情況詳細分析。針對所有的業(yè)務來制定適合的方案。如果可以新建環(huán)境進行業(yè)務遷移固然最好。如果新環(huán)境沒辦法成功搭建?？紤]V2V的方式。也并不一定就是九死一生，做好虛擬機備份在進行遷移也未嘗不可

回復2：為了業(yè)務的平穩(wěn)遷移，建議采用第2中方案。雖然第1種的方案操作簡單，但是vmdk磁盤格式轉(zhuǎn)換的過程中有可能會出錯。

回復3：根據(jù)項目經(jīng)驗，建議是重新建立VM，進行數(shù)據(jù)層的遷移，而不是VM的遷移，雖然vmdk可以轉(zhuǎn)換，但是風險很高。

回復4：從工作簡便易行上是第一種

從易用兼容是第二種，取決于你的數(shù)量級以及遷移時間與應用可接受的方式，看有沒有應用組支撐您重新部署，如果沒有就考慮第一吧，v2v把vmdk倒出，然后轉(zhuǎn)換qcow2。但是可能會有兼容性或者倒出損壞的問題

回復5：在openstack集群新搭建虛擬機，進行業(yè)務系統(tǒng)遷移

虛擬機導出導入之后，不能保證原有的程序一定可以正常運行。也不好保證vmdk在做v2v轉(zhuǎn)換之后就一定不會損失格式或者有虛擬化格式之后的效率損失。

遷移在大多數(shù)情況下比較靠譜，可以充分測試沒問題之后再切換業(yè)務入口。

也可以兩種同時進行，對于不同業(yè)務選擇不同的遷移方案。

個人意見是盡量多的選擇2。2、使用openstack建設企業(yè)桌面云平臺,成本控制？openstack的私有云已使用，win7的云主機

可以使用

目標：使用openstack

建設企業(yè)桌面云平臺

嘗試：進行了桌面云的調(diào)查

困惑：

成本問題，服務器的資源：cpu、內(nèi)存、硬盤的采購價是要高于pc機的；

為說服領(lǐng)導，建設桌面云，相對于pc采購沒有劣勢，如何考慮這個問題；

多謝討論意見?；貜?：云桌面，有劣勢，你要說明領(lǐng)導，首先你要知道缺點

（1）

不便宜，

現(xiàn)在pc機的價格大幅降低，但你要知道云桌面的一個節(jié)點，價格并不低，早些年，天

磯科技出過一款云桌面，服務器是送你的，你大概以為撿了個大便宜，但我告知你，一個節(jié)點一年收費近3千，你怎么想？

所以，如果你要上云桌面，首先，不是去說服領(lǐng)導，首先要去殺價。

（2）可靠性，

所有的節(jié)點都連上機房的服務器，請問，服務器掛了怎么辦。再請問，網(wǎng)絡堵住了又怎么辦？

你一定會說，有維保?。?/p>

好，又是錢，你買pc機需要這么貴的維保嗎？

所以，第二點，還是去殺價，把云桌面維保的價格殺到比pc維保低。

（3）性能，隨著你的節(jié)點數(shù)量的增加，服務器也要升級，問題又來了，供應商是否免費升，網(wǎng)絡是不是也要升，又是錢。

科技是在進步的，但進步不意味著都合適，你要仔細分析，努力殺價。

回復2：云桌面有以下優(yōu)勢：

第一，運維成本。PC部署以及系統(tǒng)軟件安裝耗時較長，云桌面后臺5分鐘一臺自動交付可供用戶使用的虛擬機；PC擴大部署投入巨大，云桌面只需要購買少量服務器接入云系統(tǒng)，快速擴大部署。

第二，故障處理效率。PC有問題，有可能需技術(shù)人員到用戶現(xiàn)場開箱檢查，故障排查耗時較長，嚴重點的硬件問題如需更換配件，等待周期更長。云桌面故障標準是5分鐘處理完畢。對于5分鐘無法解決的問題，只需后臺更換虛擬機解決。

第三，運維管理。PC分散在用戶桌面，運維需要用戶配合（比如保持開機）。云桌面提供了運維系統(tǒng)，只需設定好時間、安裝任務參數(shù)，系統(tǒng)會全自動進行安裝維護。同時，瘦客戶端輕量，無任何用戶數(shù)據(jù)，對用戶也帶來極大便利。典型的如用戶位置遷移，云桌面無需搬移，只需用戶到新位置登錄即可。

云桌面整體低碳、環(huán)保。瘦客戶端功率跟普通節(jié)能燈相近，比PC低一個數(shù)量級。

Openstack在資源整合方面，相對傳統(tǒng)行業(yè)，還是有很多優(yōu)勢的。

回復3：云桌面的優(yōu)勢

第一，運維成本。PC部署以及系統(tǒng)軟件安裝耗時較長，云桌面后臺5分鐘一臺自動交付可供用戶使用的虛擬機；PC擴大部署投入巨大，云桌面只需要購買少量服務器接入云系統(tǒng)，快速擴大部署。

第二，故障處理效率。PC有問題，有可能需技術(shù)人員到用戶現(xiàn)場開箱檢查，故障排查耗時較長，嚴重點的硬件問題如需更換配件，等待周期更長。云桌面故障標準是5分鐘處理完畢。對于5分鐘無法解決的問題，只需后臺更換虛擬機解決。

第三，運維管理。PC分散在用戶桌面，運維需要用戶配合（比如保持開機）。云桌面提供了運維系統(tǒng)，只需設定好時間、安裝任務參數(shù)，系統(tǒng)會全自動進行安裝維護。同時，瘦客戶端輕量，無任何用戶數(shù)據(jù)，對用戶也帶來極大便利。典型的如用戶位置遷移，云桌面無需搬移，只需用戶到新位置登錄即可。

最后，云桌面整體低碳、環(huán)保。瘦客戶端功率跟普通節(jié)能燈相近，比PC低一個數(shù)量級。

Openstack在資源整合方面，相對傳統(tǒng)行業(yè)，還是有很多優(yōu)勢的。回復4：1、桌面云從長遠來看，集中管理，可以減少運維成本；2.如果網(wǎng)絡可通達，可以隨時隨地連接到虛擬桌面開展工作；3.就安全方面考慮，虛擬桌面更容易集中設置安全策略；4.用電量也會減少；

2、采購pc機的話，需要人均一個，虛擬桌面的話，服務器的資源考慮滿足并發(fā)的需求就可以。三、OpenStack與K8S容器平臺的融合方案？背景環(huán)境：

我們公司目前有兩個輕量級的驗證性平臺一個是基于

OpenStack

P版本的

IaaS

云平臺，一個是基于

K8S

1.8版本的容器平臺，都是使用的社區(qū)版本進行的構(gòu)建，并且在進行了驗證之后將公司內(nèi)部的應用系統(tǒng)遷移到了云平臺上，將與項目、研發(fā)等相關(guān)的產(chǎn)品遷移到了容器平臺上。經(jīng)過一年多的運行之后，現(xiàn)在因為管理上的需要，規(guī)劃將兩個平臺進行整合，方便進行統(tǒng)一的管理。

現(xiàn)場信息：

云平臺有10臺主機，容器平臺5臺主機

已有的思考和嘗試：

當前的想法是準備采用在云平臺上開設虛機主機，通過虛擬主機的環(huán)境重新構(gòu)建一套新的

K8S

環(huán)境，對現(xiàn)有容器平臺的業(yè)務進行遷移。遇到的難點在于有些容器平臺上的業(yè)務對性能要求比較高，經(jīng)過這樣兩層包裝處理性能衰減的會比較多，影響運行的效率。另外，還有一塊兒我們的部分業(yè)務是需要直接和主機的外接物理設備進行通訊和交互處理的，在本身只有一層平臺的時候配置虛擬主機或者容器可以訪問到該硬件資源就比較復雜了，現(xiàn)在如果變成兩層結(jié)構(gòu)的話，感覺實施部署以及出現(xiàn)故障之后的排故，都會變的很復雜。

但之前有想嘗試通過

K8S

來打包

OpenStack，但結(jié)果嘗試失敗了，也沒找到比較合適的開源方案，而且感覺容器平臺上部署云平臺的思路，也有點兒本末倒置，就放棄了。

希望專家能夠提供一些方案性的建議，如果可以的話最好是基于開源的方案，以及一些思路?；貜?：目前在OpenStack上部署Kubernetes有多種方式：

//Tectonic

由CoreOS開發(fā)，是開源企業(yè)級的Kubernetes部署解決方案，對Kubernetes做了一些改造，支持多集群管理（也就是支持多租戶管理），更流暢的圖形化管理等。但Tectonic主要的目標是在公有云上部署，比如GCE、AWS等，雖然也開始支持OpenStack等私有云，但目前還不夠成熟，處于pre-alpha階段，所以暫不考慮。

//kops

由Kubernetes社區(qū)開發(fā)，是一個部署Kubernetes的命令行工具，和Tectonic一樣，主要的目標也是在公有云上部署Kubernetes，而且對OpenStack的支持也不算好，目前處于Alpha階段。所以kops也不予考慮。

//kubeadm

由Kubernetes社區(qū)開發(fā)，是Kubernetes目前官方推薦的部署方式，大幅簡化了Kubernetes的部署復雜度，但依舊需要較多的手動操作，而且這和在裸機上部署是沒有任何區(qū)別的，對Kubernetes沒有任何的功能增強。但是可以考慮在其他方案實施難度較大時，作為備選方案：先用kubeadm在OpenStack上手動搭建好環(huán)境，做成鏡像，再使用cloud-init注入個性化數(shù)據(jù)（可能這部分的工作量也不?。??；貜?：本來通過Magnum可以實現(xiàn)K8s在openstack環(huán)境下的部署，可你的實際情況又不允許，這就不好辦了。你或者可以試著按照社區(qū)里面那樣實現(xiàn)K8s和openstack各個組件的對接，但是工作量可不小。四、公司規(guī)劃基于Openstack開源架構(gòu)方面的進行存儲統(tǒng)一管理，是否有好的解決方案？目前公司規(guī)劃基于openstack開源架構(gòu)方面的進行存儲統(tǒng)一管理（例如對接ceph，或者對接glusterfs）但是開源存儲針對openstack

頁面管理等沒有很好的支持，是否有好一些的解決方式?回復1：對于開源的存儲解決方案，都是不穩(wěn)定的，比如glusterfs，就經(jīng)常不可讀，冒bug，讓你不得不重啟，總之，我們吃過無數(shù)的苦頭。Ceph也一樣，不過社區(qū)支持好，遇到問題總有前輩來解決。

所以，如果你一定要上開源的分布式存儲，建議上ceph、hdfs等社區(qū)活躍的分布式存儲。

ceph雖然源于openstack，但目前使用的領(lǐng)域已經(jīng)遠遠不限于openstack了。當然openstack對它的支持是原生的，最好的。

如果你再不放心，就只能去買華為的分布式存儲，性能很不錯。

奧，對了，你可能意思是沒有”界面‘’管理，不過你放心，ceph的新版本自己有比較好的管理界面了?；貜?：OpenStack私有云中，對傳統(tǒng)存儲的自動化統(tǒng)一管理，其實還是需要利用傳統(tǒng)存儲的自身工具，再開發(fā)一個統(tǒng)一的界面來進行管控。五、Openstack的nova接管vsphere時需注意什么問題？回復1：nova-scheduler可調(diào)度的nova-compute可以有多個，并且每個nova-compute對應了vSphere上的一個Cluster,每個Cluster又都要有一個Datastore進行配置和使用。

通過Openstack來創(chuàng)建vSphere的虛擬機后，虛擬機在vCenter的總控界面中會得到呈現(xiàn)，并且可以支持VMware的高級功能。除此之外，在Horizon中也會得到呈現(xiàn)，能夠像管理其他Openstack虛擬機一樣管理vCenter中的虛擬機，但也可能會存在部分VMware的功能限制(如sshkeys等)?；貜?：邏輯上看，OpenStack與vCenter直接通信，VC管理整個ESXi集群，vMotion、HA、DRS也都能用了。但vCenter從Nova-Compute中抽離出了ESXi主機，Nova-Scheduler將整個自管理的集群作為一個獨立主機接入——這會導致一些問題，大致特點如下：

·

不同于基于內(nèi)核的hypervisor，vSphere需要一個單獨的vCenter主機，VM是運行在ESXi主機上而不是計算節(jié)點上。

·

盡管OpenStack已支持多hypervisor，但一個計算節(jié)點同時只能支持一種hypervisor。因此，multi-hypervisor的OpenStack混合云，對于每一種hypervisor類型就至少要有一個計算節(jié)點來對應。

·

VCDriver有限制，每個Nova-Compute服務僅能對應一個vSphere集群。當計算節(jié)點作為VM運行在同一集群下時，就具有了HA能力。

·

VCDriver中每個cluster都要有一個datastore來進行配置和使用.六、Zabbix監(jiān)控openstack虛擬機方式選擇？使用了openstack

私有云，被迫研究監(jiān)控

想法是，使用zabbix監(jiān)控

openstack'云主機

一種方式：在云主機中安裝

zabbix'客戶端，這個不討論了。

另一種方式：zabbix'連接

openstack，

查看了一些

zabbix的模板，實現(xiàn)不了云主機的監(jiān)控；

目前還在困惑中?；貜?：分兩層，不要混淆

對于用戶層，只需要知道Iaas層的云虛擬機是否正常，當然是在openstack用zabbix來監(jiān)控Iaas層的實例，這沒有毛病是必須的。

對于底層，openstack集群的服務器的監(jiān)控，當然你也可以用zabbix，是用內(nèi)部的那個，還是自搭，我建議后者，由于網(wǎng)絡的原因，最好不好混起來。回復2：我們的做法是采用第一種方式：在云主機中安裝zabbix'客戶端。第二種方式使用zabbix連接openstack監(jiān)控云主機的話，監(jiān)控的內(nèi)容沒有第一種方式多，只能簡單的監(jiān)控云主機的狀態(tài)?；貜?：推薦第一種方案，openstack的監(jiān)控這塊做得并不好

如果通過openstack中轉(zhuǎn)的話，很多方面會收到openstack社區(qū)的限制

我們通過prometheus實現(xiàn)的。七、企業(yè)如何判斷自己的私有云建設使用Openstack還是VMware？越來越多的企業(yè)已經(jīng)開始或計劃建設自己的私有云，那么作為IT的規(guī)劃人員，基于哪些維度選擇適合自己的私有云平臺？回復1：私有云，如果用于生產(chǎn)，誰讓你用原生的openstack，如果你在的不是bat性質(zhì)的公司，你就把他給燒魷魚。都是坑啊，上生產(chǎn)，不是自己找藥吃。

如果生產(chǎn)要用openstack，一定要買商業(yè)化的openstack，比如easystack、青云的、ibm等等，有底層運維團隊的支持。其實就是bat團隊自己搞底層運維，而你雇一個團隊搞底層運維。

vmware基本不用如此，你只要買license就可以了，運維要求不高，

產(chǎn)品成熟??！

所以，你的錢大部分都花在license上，license依據(jù)vcore，一個大約5000，我的天，上千臺虛機不是天文數(shù)字，不過這是可談的，一般超了不多，vmware公司也不會來找你要。一般每年你只要意思意思給個幾十萬就可以了，

但這不是法律承認的。

正規(guī)公司都必須和vmware談一個總包價，不打擦邊球。回復2：首先要搞清楚，openstack是一個管控平臺，包括主機，網(wǎng)絡，存儲，容器，編排，裸金屬管理。。。諸多的項目。vmware是一個企業(yè)，里面包含了很多的產(chǎn)品，有和openstack相類似的平臺管控vcloud，or

vRA；也有虛擬化產(chǎn)品vsphere，分布式存儲vSAN，防護vShield。。。

你說的使用openstack，還是VMware，可能是指用openstack系列，還是VMware系列的產(chǎn)品；他們其實客戶相互包含的。具體要看項目的情況。八、Openstack與VMware的優(yōu)劣勢有哪些？目前私有云部署主要集中在開源領(lǐng)軍陣營的Openstack和商用領(lǐng)軍陣營對的老牌VMware，它們各自有哪些優(yōu)勢和劣勢？回復1：openstack

（1）openstack是免費的，但它是半成品，如果沒有強大的“團隊”做支撐，沒人敢于用于生產(chǎn)

（2）就是有團隊，我也很猶豫，因為太復雜，里面只要有一個故障，就是生產(chǎn)事故，而且排查困難。

（3）openstack是技術(shù)的方向，有了這個方向，各個商家去研發(fā)自己的類openstack產(chǎn)品，用于生產(chǎn)，比如Qcloud，青云。

vmware

（1）vmware是收費的，成熟的商業(yè)化產(chǎn)品，走強大的技術(shù)團隊；

（2）

vmware可以用于所有的環(huán)境，大量的產(chǎn)品在其中運行，基本上你不用擔心掛了，穩(wěn)定；

（3）vmware是cloud

foundry的組件之一，cloud

foundry是云平臺的基礎，走的是不同于openstack的一條路。回復2：Openstack可塑性高，門欄高，開源，技術(shù)支持服務少。

VMware穩(wěn)定，固化，收費，但是技術(shù)支持服務多，可靠?；貜?：openstack在2019年由幾個大廠支持的環(huán)境部署已經(jīng)很成熟,

技術(shù)層面,硬件sdn加openstack組件完成

聯(lián)動虛擬化部署方案的

華為是最優(yōu)勢選擇

反而vmware這些年的部署情況看了

vmware自己的sdn是軟件構(gòu)成幾乎沒有在金融行業(yè)部署

vmware如果集成cisco的sdn方案成本很高,包括日后的維護費用的運維費用

而且這些年容器的部署也開始逐步侵蝕vmware的部分業(yè)務,

但對于openstack和vmware的優(yōu)缺點可總結(jié)如下,

這里特指金融行業(yè),其他行業(yè)不具有參考力

1.

公有云技術(shù)輸出的能力

openstack使用廠商級別支持,

硬件sdn集成,可做類似公有云部署進行技術(shù)輸出

vmware反而沒有這個運維能力,資源無法完成租戶等業(yè)務模塊需要單獨開發(fā),

網(wǎng)絡部分需要集成cisco硬件sdn,成本很高,

vmwaer自己的軟sdn無法滿足業(yè)務需求,目前無法完成類似公有云的算力輸出能力

2.

價格方面

openstack廠商級別

比如華為,

圈套服務器+

openstack系統(tǒng)+

sdn系統(tǒng),打包后,

軟件成本幾乎對項目總成本來說占比很少,

vmware架構(gòu)做公有云技術(shù)輸出是:

服務器硬件成本,

+

sdn硬件(cisco)成本

+

vmware的軟件成本

+

二次開發(fā)運維平臺的成本.成本遠遠超過openstack方案

3.

項目實施層面,

openstack實施由廠商統(tǒng)一完成,

包括

sdn,

openstack集成,

上層云運營平臺部署可一體化無縫完成

而且vmware需要分別進行sdn集成,

服務器集成,

公有云運維系統(tǒng)開發(fā),

多方導致實施難度增大(即使又一家廠商完成總包方案也是分包到各個廠商的技術(shù)人員完成總體業(yè)務交付)

4.

后期維護成本

openstack

本身開源,

軟件升級速度由產(chǎn)品支持廠商完成,

費用相對較低

vmware本身技術(shù)成熟度搞,

維護費用由廠商支持(購買廠商的原廠支持license),

相對較高回復4：（1）設計層面

VMware軟件套件是自底向上的架構(gòu)，下端邊界為虛擬機管理器。像VMware的vSphere和vClouddirector產(chǎn)品都是依賴于免費的ESX(i)虛擬機管理器，ESX(i)虛擬機管理器為他們提供了非常優(yōu)秀的部署架構(gòu)。本身VMware的軟件套件也是經(jīng)過全面測試過的，并且都有單一部署框架。總的來說，VMware的產(chǎn)品由于其架構(gòu)的健壯性，很多高規(guī)格用戶在多數(shù)據(jù)中心規(guī)模的環(huán)境中都有使用。換句話說，VMware的軟件系統(tǒng)是封閉的，并且軟件的發(fā)展路線是完全遵循VMware自己的發(fā)展目標，用戶或消費者在此方面沒有任何控制權(quán)。

OpenStack作為一個開源系統(tǒng)，沒有任何一家單獨的公司在控制OpenStack的發(fā)展路線。本身OpenStack是年輕的，還不滿三周歲，但是他卻具有巨大的市場動力，與此同時，很多大公司都在支持OpenStack發(fā)展。有了如此多公司的資源投入，OpenStack的發(fā)展是多元化的。然而這也帶來了問題，就是OpenStack部署和架構(gòu)的實施和維護成本較比VMware有了陡然提高，與此同時，由于相對快速的版本更新速度，技術(shù)支持文檔不能跟上產(chǎn)品的腳步。

（2）在功能的支持方面和功能細節(jié)

OpenStack與VMware還是有差距的，但是這對OpenStack還是有優(yōu)勢的，因為較比VMware的昂貴價格，OpenStack免費、開放的優(yōu)勢顯現(xiàn)出來。VMware高投入帶來的功能，OpenStack大部分可以免費提供給客戶。

從VMware在功能方面的領(lǐng)先可以看出，VMware還在繼續(xù)研發(fā)除了vMotion、高可用、容錯以外其他的新功能去保護他們的虛擬機；OpenStack一方面跟隨VMware的腳步，另一方面他們投入精力在支持更多硬件廠商解決方案的上面。總的來說，OpenStack入門門檻較高，但是隨著項目規(guī)模的擴大，你將從中受益，因為不必支付高額的版權(quán)費用。VMware雖然在小規(guī)模安裝時相對容易，但是隨著規(guī)模擴大，事情就變了。這就是說，隨著云應用大規(guī)?；蠹乙哺邮煜penStack，那么OpenStack的入門門檻就低得多了。_九、openstack的實施中遇到的難題？在使用商用openstack產(chǎn)品，在納管vmware的vcenter時是如何能匹配openstack產(chǎn)品的上層組織架構(gòu)（如多租戶的情況）進而有效避免多次重復納管，在接管vcerter是如何能保證網(wǎng)絡的正常使用，對網(wǎng)絡的影響最小，在哪些操作的時候，對網(wǎng)絡有影響，請專家給點意見唄。

1.根據(jù)VMWare中的VM所在的網(wǎng)絡信息，在Openstack中創(chuàng)建對應的網(wǎng)絡，VLANID保持一

2.在OpenStack中創(chuàng)建port對象，MAC地址保持與VMWare中VM的MAC地址一致

3.在OpenStack中創(chuàng)建VM對象，UUID保持與VMWare中VM的UUID一致

4.將新創(chuàng)建的VM對象連接到分布式vSwitch

5.將新創(chuàng)建的VM的VNC端口打開，以支持遠程訪問

方案的核心思想是在OpenStack里增加一個與創(chuàng)建VM過程類似的納管過程，輸入被納管VM的IP、MAC、CPU和內(nèi)存規(guī)格、操作系統(tǒng)等信息，將創(chuàng)建VM的各環(huán)節(jié)在OpenStack里跑一遍，從而在OpenStack數(shù)據(jù)庫中構(gòu)造被納管的VM相關(guān)的配置管理數(shù)據(jù)，但在最后一步并不將相關(guān)指令真正下發(fā)到vCenter?；貜?：openstack產(chǎn)品納管vmware穩(wěn)態(tài)計算資源時候,

網(wǎng)絡部分需要根據(jù)穩(wěn)態(tài)網(wǎng)絡變化來進行對應調(diào)整

這個聯(lián)動技術(shù),目前定義為云網(wǎng)聯(lián)通,

意思就是

和云環(huán)境(openstack)進行聯(lián)動變化

穩(wěn)態(tài)網(wǎng)絡變更時候需要調(diào)用云網(wǎng)(openstack接口)完成sdn的網(wǎng)絡變化,下策略到sdn中使其能適應穩(wěn)態(tài)網(wǎng)絡環(huán)境的變化.

這個技術(shù)需要單獨適應客戶環(huán)境化開發(fā)(客制化)開發(fā).比較難處理的一部分業(yè)務內(nèi)容

。十、openstack中的內(nèi)部組件是靠什么協(xié)議通訊的，靠什么組件通訊的？如何保證通訊的可靠性？回復1：OpenStack組件之間的通信分為四類：

1基于HTTP協(xié)議

2基于AMQP(AdvancedMessageQueuingProtocol，一個提供統(tǒng)一消息服務的應用層標準高級消息隊列協(xié)議)協(xié)議（基于消息隊列協(xié)議）

3基于數(shù)據(jù)庫連接（主要是SQL的通信）

4NativeAPI（基于第三方的API）

基于HTTP協(xié)議進行通信

通過各項目的API建立的通信關(guān)系，基本上都屬于這一類，這些API都是RESTfulWebAPI，最常見的就是通過Horizon或者說命令行接口對各組件進行操作的時候產(chǎn)生的這種通信，然后就是各組件通過Keystone對用戶身份進行校驗，進行驗證的時候使用這種通信，還有比如說NovaCompute在獲取鏡像的時候和Glance之間，對GlanceAPI的調(diào)用，還有比方說Swift數(shù)據(jù)的讀寫，也是通過這個HTTP協(xié)議的RESTfulWebAPI來進行的。

基于高級消息隊列協(xié)議基于AMQP協(xié)議進行的通信，主要是每個項目內(nèi)部各個組件之間的通信，比方說Nova的NovaCompute和Scheduler之間，然后Cinder的Scheduler和CinderVolume之間。

需要說明的是，Cinder是從NovaVolume演化出來的，所以Cinder和Nova之間也有通過AMQP協(xié)議的通信關(guān)系，由于AMQP協(xié)議進行通信也屬于面向服務的架構(gòu)，雖然大部分通過AMQP協(xié)議進行通信的組件屬于同一個項目，但是并不要求它們安裝在同一個節(jié)點上，給系統(tǒng)的橫向擴展帶來了很大的好處，可以對其中的各個組件分別按照他們負載的情況進行橫向擴展，因為他們不在一個節(jié)點上，分別用不同數(shù)量的節(jié)點去承載它們的這些服務。

（AMQP是一種協(xié)議，OpenStack沒有規(guī)定它是用什么實現(xiàn)，我們經(jīng)常使用的是PrivateMQ，實際上用戶也可以根據(jù)自身的情況選擇其它的消息中間件。）

基于SQL的通信

通過數(shù)據(jù)庫連接實現(xiàn)通信，這些通信大多也屬于各個項目內(nèi)部，也不要求數(shù)據(jù)庫和項目其它組件安裝在同一個節(jié)點上，它也可以分開安裝，還可以專門部署數(shù)據(jù)庫服務器，把數(shù)據(jù)庫服務放到上面，之間通過基于SQL的這些連接來進行通信。OpenStack沒有規(guī)定必須使用哪種數(shù)據(jù)庫，雖然通常用的是MySQL

通過NativeAPI實現(xiàn)通信

出現(xiàn)在OpenStack各組件和第三方的軟硬件之間，比如說，Cinder和存儲后端之間的通信，Neutron的agent或者說插件和網(wǎng)絡設備之間的通信，這些通信都需要調(diào)用第三方的設備或第三方軟件的API，我們稱為它們?yōu)镹ativeAPI，那么這個就是我們前面說的基于第三方API的通信?；貜?：我們知道對Openstack的各個組件（nova，cinder，neutron等）來說，跨組件交互時使用的是RestAPI相互調(diào)用公共接口，組件內(nèi)部各個進程間通信時使用RPC消息通信，從而實現(xiàn)各組件、各進程之間的解耦。OpenstackRPC（RemoteProducerCall）機制基于AMQP（AdvancedMessageQueuingProtocol）協(xié)議，搭配各種消息服務器（RabbitMQ，Qpid等）實現(xiàn)各個組件內(nèi)部進程間的消息傳遞。

AMQP*

AMQP是一個提供統(tǒng)一消息服務的應用層標準協(xié)議，基于此協(xié)議的客戶端與消息中間件可傳遞消息，并不受客戶端/中間件不同產(chǎn)品、不同開發(fā)語言等條件的限制，實現(xiàn)異步通信。

RPC.call：發(fā)送請求到消息隊列，等待返回最終結(jié)果。

RPC.cast：發(fā)送請求到消息隊列，不需要等待最終返回的結(jié)果。

在AMQP模型中，幾個主要功能模塊連接成一個處理鏈完成預期的功能：Publisher：消息發(fā)送者，將消息發(fā)送到Exchange。

Message：由Header和Body組成，Header是由Publisher添加的各種屬性的集合，包括Message是否被持久化、由哪個MessageQueue接受（RoutingKey）、優(yōu)先級是多少等。而Body是真正需要傳輸?shù)臄?shù)據(jù)，它是對Server不可見的二進制數(shù)據(jù)流，在傳輸過程中不受影響……

Exchange：接收發(fā)布應用程序發(fā)送的消息，并根據(jù)RoutingKey和Binding信息、ExchangeType等參數(shù)將這些消息路由到消息隊列。

Binding：關(guān)聯(lián)Exchange和MessageQueue，提供路由規(guī)則。

MessageQueue：存儲消息，直到這些消息被消費者安全處理完為止。

Consumer：**消息接受者，從MessageQueue獲取消息。使用這個模型我們可以很容易的模擬出存儲轉(zhuǎn)發(fā)隊列和主題訂閱這些典型的消息中間件概念。AMQP是非對稱的，客戶端生產(chǎn)和消費消息，服務器存儲和路由這些消息。一個AMQP服務器類似于郵件服務器，Exchange類似于消息傳輸代理（email里的概念），MessageQueue類似于郵箱。Binding定義了每一個傳輸代理中的消息路由表，發(fā)布者將消息發(fā)給特定的傳輸代理，然后傳輸代理將這些消息路由到郵箱中，消費者從這些郵箱中取出消息。AMQP模型中不同類型的Exchange對應不同的routing算法：

DirectExchange：Point-to-Point消息模式，DirectExchange根據(jù)RoutingKey進行精確匹配，只有對應的MessageQueue會接收到消息。

TopicExchange：Publish-Subscribe（Pub-sub）消息模式，TopicExchange根據(jù)RoutingKey進行模式匹配，只要符合模式匹配的MessageQueue都會收到消息。

FanoutExchange：廣播消息模式，F(xiàn)anoutExchange將消息轉(zhuǎn)發(fā)到所有綁定的MessageQueue?；貜?：樓上的兄弟回答的很全面了，但問的是內(nèi)部組件，我只摘錄一段

rabbitmq是openstack的內(nèi)部默認隊列

，非常關(guān)鍵，一旦阻塞或宕了，整體openstack就會全跨。原生的沒有高可用，但如果真上生產(chǎn)，一定要要配置高可用基于高級消息隊列協(xié)議

基于AMQP協(xié)議進行的通信，主要是每個項目內(nèi)部各個組件之間的通信，比方說Nova的NovaCompute和Scheduler之間，然后Cinder的Scheduler和CinderVolume之間。需要說明的是，Cinder是從NovaVolume演化出來的，所以Cinder和Nova之間也有通過AMQP協(xié)議的通信關(guān)系，由于AMQP協(xié)議進行通信也屬于面向服務的架構(gòu)，雖然大部分通過AMQP協(xié)議進行通信的組件屬于同一個項目，但是并不要求它們安裝在同一個節(jié)點上，給系統(tǒng)的橫向擴展帶來了很大的好處，可以對其中的各個組件分別按照他們負載的情況進行橫向擴展，因為他們不在一個節(jié)點上，分別用不同數(shù)量的節(jié)點去承載它們的這些服務。（AMQP是一種協(xié)議，OpenStack沒有規(guī)定它是用什么實現(xiàn)，我們經(jīng)常使用的是PrivateMQ，實際上用戶也可以根據(jù)自身的情況選擇其它的消息中間件。）十一、同城雙活數(shù)據(jù)中心機房如何規(guī)劃使用openstack產(chǎn)品？商用openstack產(chǎn)品時，對不同同城雙活中心機房，如何進行納管vmware的vcenter，對納管同城雙活機房的Laas層的資源，架構(gòu)如何規(guī)劃，在實施過程中，請專家們在有這方便的多介紹一下經(jīng)驗，進而讓大家盡量避免少跳坑，進而提高業(yè)務的連續(xù)性?；貜?：同城的雙數(shù)據(jù)中心和異地中心通過專線互聯(lián)，搭建大二層網(wǎng)絡，并實現(xiàn)數(shù)據(jù)中心業(yè)務數(shù)據(jù)二層網(wǎng)絡的聯(lián)通，真正意義的實現(xiàn)了計算、存儲、網(wǎng)絡資源的統(tǒng)一管理統(tǒng)一調(diào)度。配合業(yè)務應用的高可用設計，可以實現(xiàn)同城雙活數(shù)據(jù)中心中有一個出現(xiàn)故障，可以由另一個中心無縫接替業(yè)務，業(yè)務連續(xù)運行，用戶使用無感知。而如果出現(xiàn)重大事故，同城的兩個雙活中心都出現(xiàn)故障，異地的災備中心可以分鐘級啟動并承載業(yè)務，從而最大限度保障業(yè)務連續(xù)性。

OpenStack采用multi-region方式，將平臺可以部署在3個數(shù)據(jù)中心，其中兩個為同城雙活數(shù)據(jù)中心實現(xiàn)業(yè)務無縫切換，和一個為異地容災中心，實現(xiàn)在同城的主數(shù)據(jù)中心出現(xiàn)重大故障的情況下，分鐘級業(yè)務切換。同時3個數(shù)據(jù)中心采用統(tǒng)一接口對接上層云資源管理平臺，集中化的認證keystone。各個數(shù)據(jù)中心的基礎資源有獨立調(diào)度平臺。回復2：個人想法,

商用openstack這里

只了解華為,

目前以華為來描述下面方案

每個數(shù)據(jù)中心部署

openstack云平臺(虛擬化平臺)區(qū)域,

統(tǒng)一由上層云管理平臺完成那管,

vmware區(qū)域由openstack的

wmware的納管接口完成納管,

資源規(guī)劃需要詳細調(diào)研你的業(yè)務云化需求,

具體

方案參考

vmware的一個虛擬化資源池

由48個服務器構(gòu)成,

每16個服務器一個機柜,

內(nèi)部部署vc等關(guān)聯(lián)系統(tǒng),

接入傳統(tǒng)網(wǎng)絡環(huán)境,IP地址等按照穩(wěn)態(tài)計算環(huán)境部署(傳統(tǒng)虛擬化環(huán)境)

openstack一個虛擬化資源池區(qū)域

15臺服務器組成一個區(qū)域,

3個控制節(jié)點,其他是計算節(jié)點,接入硬件SDN構(gòu)成租戶方式的云化虛擬化環(huán)境,通過彈性ip和外部系統(tǒng)完成互聯(lián).

兩個底層虛擬化技術(shù)通過云管理平臺完成互聯(lián)互動,對SDN進行集成(創(chuàng)建vmware系統(tǒng)的vm后,調(diào)用sdn接口完成網(wǎng)絡配置下發(fā))

要求實現(xiàn)

雙活需要每個數(shù)據(jù)中心部署對應的虛擬化池,

上層統(tǒng)一管理,

對vmware資源池要提前規(guī)劃好所需資源包括IP地址,網(wǎng)絡vlan,存儲空間等,

尤其網(wǎng)絡部分需要完整規(guī)劃避免日后有過多變更

openstack由于云化管理為敏態(tài)技術(shù),sdn

加持可通過接口后期定義完成網(wǎng)絡變化.

雙活的核心業(yè)務系統(tǒng)需要安裝業(yè)務需求完成規(guī)劃部署,

在兩個數(shù)據(jù)中心實現(xiàn)雙活運行,

先規(guī)劃好基礎的云架構(gòu),

然后挑選一個業(yè)務系統(tǒng)進行測試部署,測試成功后可推廣實施.

對于不適用的穩(wěn)態(tài)業(yè)務系統(tǒng),

目前還是應按照穩(wěn)態(tài)技術(shù)進行部署在vmware中。十二、Openstack剛填好坑，更新版本后又要填坑，如何才能高效的運維，避免踩坑？Openstack的坑是超多的，有的同學說不懼怕填坑，我要說等你填完，半年時間又上一個新版本，難道你繼續(xù)填坑？如何才能高效的運維，避免踩坑？聽聽大家日常運維經(jīng)驗！回復1：無法，因為軟件的更新迭代太快了，你看現(xiàn)在大家學習都不去書店了，為什么能，一方面是因為電子書，但更重要的原因是軟件更新太快，寫書的都寫不過來了，寫好書，可能寫書的版本就被淘汰了，所以，現(xiàn)代IT學習都靠原版的document。

所以，你要“高效運維”，

除非你不改版本。

（1）

選用成熟開源軟件，github上star低于200的，堅決不碰；

（2）

選用LTS版本，穩(wěn)定版；

（3）

不追逐潮流，基本上2年內(nèi)，不更新版本。回復2：簡單來說的話：

1.有開發(fā)能力的單位是不懼怕的，但是運維成本超高；

2.沒有開發(fā)能力的，建議使用成熟的商業(yè)套件；

3.無論開源還是商用，必須要做好架構(gòu)的高可用和存儲的高可用。十三、怎樣將數(shù)據(jù)中心現(xiàn)有的物理機和虛擬機平滑的遷移到云平臺上？風險和工作量怎樣評估？成熟的產(chǎn)品怎樣選型？回復1：傳統(tǒng)行業(yè)上云痛點分析

傳統(tǒng)企業(yè)上云會有一些痛點，大致分為以下幾個層面。

用戶體驗方面的考慮?？赡芤驗闃I(yè)務過去的包袱太重，導致他們遷移上云會涉及到部分代碼層面的修改、打包、重發(fā)布、應用管理方式等變化，這會有一定技術(shù)門檻，使得遷移上云有一定難度。比如企業(yè)軟件上云，過去企業(yè)的開發(fā)人員都是使用傳統(tǒng)的開發(fā)模型和開發(fā)工具做開發(fā)，而在云上，很多應用的開發(fā)直接就是基于云原生應用架構(gòu)進行開發(fā)的用戶體驗。這就好比一個使用WindowsXP的用戶，突然要他去馬上適應Windows10——過程類似，體驗不同。在云上，開發(fā)工具和開發(fā)理念不同，云原生應用開發(fā)會將應用的每個部分都打包在自己的容器中，動態(tài)編排，以便每個部分都被主動調(diào)度和管理，以優(yōu)化資源利用率和面向微服務的應用程序，從而提高應用程序的整體靈活性和可維護性。如此便捷輕度的開發(fā)體驗，是原來傳統(tǒng)的開發(fā)模式所無法達到的。當然，云原生應用給擁有多年傳統(tǒng)企業(yè)開發(fā)經(jīng)驗的開發(fā)人員也帶來不少的學習成本，在一定程度上打破了他們固有的開發(fā)習慣和開發(fā)方式，這對于企業(yè)業(yè)務軟件上云，也帶來了不少的門檻。我相信，隨著整個行業(yè)不斷的發(fā)展，企業(yè)的IT管理人員、開發(fā)人員，能夠有更多機會體驗到新技術(shù)帶來的效率提升、應用開發(fā)更靈活，大家慢慢用起來，這種現(xiàn)狀就可以得到改善。

數(shù)據(jù)安全方面的考慮。比如說他可能擔心數(shù)據(jù)放在公有云上數(shù)據(jù)本身是否安全？數(shù)據(jù)的請求與控制、訪問與授權(quán)，數(shù)據(jù)防泄露等安全誰來保障？其實客戶的疑問是可以理解的，當然，公有云廠商也提供了諸多的技術(shù)保障了數(shù)據(jù)安全，比如說我們客戶的核心業(yè)務系統(tǒng)，他的數(shù)據(jù)要放到云上去做災備，就涉及到很多技術(shù)，比如使用加密技術(shù)傳輸數(shù)據(jù)。使用密鑰技術(shù)來加密數(shù)據(jù)，數(shù)據(jù)的訪問需要客戶自主的、多因素的認證，即便是公有云廠商，自已后端的IT管理人員，他也沒有辦法看你的數(shù)據(jù)。另外，云上數(shù)據(jù)可以在多個不同區(qū)域間進行多副本存儲，避免了單一云區(qū)域離線后，數(shù)據(jù)無法請求的問題，在我看來，云上數(shù)據(jù)安全是有保障的。只不過，用戶可能始終會有一種感受，好像數(shù)據(jù)不在自己家里心里不踏實的那種感受，隨著越來越多的用戶接入云，大家也在適應云計算技術(shù)優(yōu)勢，慢慢相互建立信任的過程。

歷史包袱方面的考慮。比如有一些用戶過去籌建自己的業(yè)務系統(tǒng)，都是煙囪式或者叫孤島式的。今天我要上一個XX應用系統(tǒng)，找一個廠商過來，好，系統(tǒng)上線；到了明天，我又上一個系統(tǒng)……慢慢，系統(tǒng)越來越多，但是，這些個系統(tǒng)之間沒有去把數(shù)據(jù)全部打通，業(yè)務流程流轉(zhuǎn)僅限于幾個主流的企業(yè)應用，長期下來，你會發(fā)現(xiàn)一個大的企業(yè)里面可能有上百個小業(yè)務系統(tǒng)，其中打通的只有那么幾個。這時候因為前期孤島式的業(yè)務籌建方式，如果要上云的話，就需要花大量的時間去梳理不同業(yè)務邏輯間的關(guān)聯(lián)性、前端和后端的關(guān)系，或者是說，從上帝視角來看這些業(yè)務如何重新進行頂層設計，這是很多企業(yè)面臨的的痛點。所以，公司的業(yè)務如何在一個全面，有一定高度的方向和基于新平臺正確的應用架構(gòu)設計方式去做設計，是非常重要的。

關(guān)于企業(yè)上云，雖然有痛點，但辦法總比問題多，我們也有非常優(yōu)秀的云廠在提供好的平臺和技術(shù)來解決這些問題，也有類似我們這樣的云服務合作伙伴一直在努力幫助客戶去消除這些痛點，前方一片光明，我們都在路上。傳統(tǒng)企業(yè)數(shù)據(jù)中心向云數(shù)據(jù)中心遷移的優(yōu)勢

傳統(tǒng)企業(yè)的數(shù)據(jù)中心，都是標準化的三層架構(gòu)（主機層、網(wǎng)絡層、存儲層）。這種架構(gòu)經(jīng)過多年的企業(yè)業(yè)務的檢驗，其實也是較為穩(wěn)定可靠的架構(gòu)。當然，這是相對于過去的情況而言，因為過去企業(yè)的業(yè)務可能只是企業(yè)內(nèi)部，在大部分的情況下，訪問人數(shù)不多。不過仍然有一些大型集團公司的業(yè)務會面臨并發(fā)訪問的壓力。例如，在某個工作時間，所有人都要去訪問OA系統(tǒng)查看內(nèi)部公文、收發(fā)電子郵件等。

在傳統(tǒng)架構(gòu)下，比如X86的服務器，作為一個計算資源，有節(jié)點內(nèi)部的瓶頸，南橋與北橋的交互，CPU與內(nèi)存的交互，磁盤IO性能的吞吐。也有節(jié)點外部的瓶頸，比如服務器速度很快，但網(wǎng)絡如果是千M或者是萬M，數(shù)據(jù)交互經(jīng)過一層層網(wǎng)絡設備中轉(zhuǎn)，有大量的延遲響應；比如你網(wǎng)絡是25G或者是100G快速網(wǎng)絡，但你的存儲機頭是有性能極限的，如存儲機頭的CPU、內(nèi)存、IO控制器、存儲緩存高低等，都會成為傳統(tǒng)三層架構(gòu)中，出現(xiàn)木桶原理中的那個短板……

說到底，傳統(tǒng)數(shù)據(jù)中心的設計，并非是為大規(guī)模高并發(fā)的應用場景去設計的，很難承載較大的并發(fā)訪問壓力。

例如，云計算中心的后臺，X86架構(gòu)的計算能力，從主機層面開始就是定制的機器，并非市面通用的X862U或者是4U服務器。這種云計算后端的主機通過一切可能的定制，優(yōu)化減少各類接口和提高總線間訪問速度，精簡流轉(zhuǎn)過程，提高數(shù)據(jù)端到端的交互速度，通過融合架構(gòu)的方式實現(xiàn)分布式計算、存儲等。

大量分布式軟件定義的技術(shù)，實現(xiàn)網(wǎng)絡的高速通道，存儲亦是直接就是分布式存儲管理系統(tǒng)、分布式文件系統(tǒng)、分布式調(diào)度系統(tǒng)等，專為密集型高并發(fā)業(yè)務場景而設計，并起到很好的集約化效益，為企業(yè)用戶節(jié)省成本。

通過將企業(yè)線下數(shù)據(jù)中心與云上數(shù)據(jù)中心打通，實現(xiàn)業(yè)務數(shù)據(jù)級災備或者是應用級雙活，可以更靈活的實現(xiàn)業(yè)務的多重保護。

而基于云計算構(gòu)建的云上數(shù)據(jù)中心，顯然有更多的優(yōu)勢凸現(xiàn)?；貜?：首先要有一個正確的理解，你要遷移不是幾個虛機和物理機，而是一個或者多個應用系統(tǒng)。這樣這個問題就回到正軌了。

1、應用系統(tǒng)上云，先要對應用系統(tǒng)對一個評估，看是否具備上云的條件，比如應用的架構(gòu)，是單體架構(gòu)還是分布式架構(gòu)，應用運行環(huán)境，小機還是X86還是虛機，應用的資源占用情況，應用對資源是否有特殊需求，比如機密狗或者特殊硬件等等，需要對應用性能做一個周期型監(jiān)測和評估；

2、如果是小機勢必會涉及應用改造的問題，需要跟應用開發(fā)商溝通，評估代碼遷移改造的可行性和對性能的需求，然后再進行遷移上云；

3、如果是物理機，則需求對應用系統(tǒng)的性能需求進行評估，一般一臺物理機需要折算成若干臺虛擬機的算力，在云環(huán)境里面需要做一個架構(gòu)設計，需要SLB等組件的配合，還有評估應用系統(tǒng)是否支持無狀態(tài)部署，如果不支持，也得做無狀態(tài)的改造；

4、如果虛機，需要評估原系統(tǒng)虛擬機鏡像的直接遷移的可行性，是否兼容等等

5、至于具體如何進行遷移的實施，又得分若干情況，如果應用可以停機遷移，那是做踏實的，直接做就行了，如果非得在線熱遷移，那就比較麻煩，只能用工具。

6、一般來說，如果是公有云，或者主流大廠的云平臺，他們都有原廠的遷移工具，可以很好的利用，第三方的比如英方，也提供第三方遷移熱遷移工具，都可以試試。

保險起見，建議找一個提供msp服務的云服務商去幫你做這些工作。十四、openstack如何與Kubernetes做整合？回復1:vmware

+

Kubernetes

=

PKS，

可以做私有云的商業(yè)化部署；

openstack也有自己的組件marathon來對接docker容器，不過，方向錯了，應該去對接Kubernetes，結(jié)果卻是docker。所以，要把openstack和Kubernetes整合，只能由openstack構(gòu)建虛機Iaas，Kubernetes在虛機實例上建立集群。但很不穩(wěn)定，因為openstack不穩(wěn)定啊。

所以，現(xiàn)在都是由公有云廠商，對openstack的改進后，再和Kubernetes整合；

分為全托管（只管用集群）+半托管（master節(jié)點不管）+自建三種模式.回復2：openstack與k8s關(guān)注的層面不一樣，OpenStack關(guān)注IaaS資源以及管理，K8S專注容器，沒必要整合在一起吧?；貜?：這是兩種不同的技術(shù)，同時是兩種不同的虛擬化層面。openstack關(guān)注IAAS，k8關(guān)注的是容器。兩者可以獨立使用，也可以融合使用。十五、OpenStack虛擬機、裸金屬的OSagent應該如何統(tǒng)一嵌入？在構(gòu)建基于OpenStack的云解決方案，虛擬機、裸金屬往往需要使用一個帶內(nèi)agent幫助其中的監(jiān)控、管理（如修改密碼）能力補齊。但在虛擬機、裸金屬兩種典型不同的計算實例場景下，如何做到其統(tǒng)一嵌入agent是一個比較難的問題，涉及幾個點：

1.虛擬機、裸金屬鏡像統(tǒng)一是各云特別是公有云積極嘗試的點，如果裸金屬、虛擬機各自嵌入的agent不同，那鏡像統(tǒng)一難度又將變大；

2.按照OpenStack已有的虛擬機方案，其默認使用的qga使用虛擬機的VirtIO

serial保證平臺與agent通訊的，裸金屬目前沒有此方案，且在裸金屬之上實現(xiàn)虛擬的VirtIO

serial難度也較大；

以上，拋出這個問題，暫不了解AWS、阿里云為代表的公有云都是如何實現(xiàn)的，如有大神了解，請幫忙介紹下?；貜?：qga是通過compute節(jié)點socket與虛擬機serial隧道建立通信的，這種方案只適用于虛擬機，裸機無法支持。

目前OpenStack好像還沒有統(tǒng)一的OS

agent可以同時適用虛擬機