目前本本的獨立顯卡的設計有三種：一為焊接式，既移動芯片直接焊接在主板上，此種方案設計復雜但占用空間小，多用于輕薄和超輕薄筆記本中。第二種為針腳兼容式，既圖形芯片廠商推出的移動圖形芯片與前一代芯片在針腳上完全兼容，這樣筆記本制造廠商便可以將它已有的電路模塊中無需重新設計，由此可以縮短設計時間。第三種為ATI和NVIDIA所推出的模塊形式，該模塊包括移動圖形芯片和顯存，通過模塊底部的觸點與主板焊接。但這三種有一個共同點就是都不能進行隨意的更換。而且存在一個致命的弊端：從產品發(fā)布到對應的筆記本電腦上市，中間往往間隔漫長的時間。
從部署在測試環(huán)境的探索到生產環(huán)境的實踐，OpenStack是一個靈活性非常強的云管理平臺，各個組件開源獨立，組合多樣。自然就增加了安裝和運維的復雜性和難度。為了讓企業(yè)云計算工程師在日常運維管理openstack平臺的時候能更好的互助解決遇到的坑和難點問題，社區(qū)日前組織了交流，本文將活動中大家交流的一些典型問題整理分享給讀者。整理者：Garyy
1、如何把原有虛擬化下的系統遷移到OpenStack集群？哪種方案可行并更方便？
【問題描述】如何把在vmware下的應用系統整體平滑遷移至openstack集群？1.虛擬機vmdk文件倒進倒出；2.在openstack集群新搭建虛擬機，進行業(yè)務系統遷移。哪種方案可行并更方便？
@潘延晟 系統工程師：
雖然第二種方式麻煩一些。不過終究還是比較穩(wěn)妥的一種可進可退的方案。只是在一些實際環(huán)境中。一些應用過老。文檔資料不全。技術支持中斷等原因導致沒有辦法搭建一個新的環(huán)境。而不得不被迫采用V2V的方式。
我覺得還是要根據具體情況詳細分析。針對所有的業(yè)務來制定適合的方案。如果可以新建環(huán)境進行業(yè)務遷移固然最好。如果新環(huán)境沒辦法成功搭建。考慮V2V的方式。也并不一定就是九死一生，做好虛擬機備份在進行遷移也未嘗不可。
@youki2008 廣東溢達 系統架構師：
為了業(yè)務的平穩(wěn)遷移，建議采用第2中方案。雖然第1種的方案操作簡單，但是vmdk磁盤格式轉換的過程中有可能會出錯。
@chinesezzqiang 信息技術經理：
根據項目經驗，建議是重新建立VM，進行數據層的遷移，而不是VM的遷移，雖然vmdk可以轉換，但是風險很高。
@liujinlong 項目經理：
從工作簡便易行上是第一種。
從易用兼容是第二種，取決于你的數量級以及遷移時間與應用可接受的方式，看有沒有應用組支撐您重新部署，如果沒有就考慮第一吧，v2v把vmdk倒出，然后轉換qcow2。但是可能會有兼容性或者倒出損壞的問題。
@hongtu_zang 中信科技發(fā)展有限公司 技術經理：
在Openstack集群新搭建虛擬機，進行業(yè)務系統遷移。
虛擬機導出導入之后，不能保證原有的程序一定可以正常運行。也不好保證vmdk在做v2v轉換之后就一定不會損失格式或者有虛擬化格式之后的效率損失。
遷移在大多數情況下比較靠譜，可以充分測試沒問題之后再切換業(yè)務入口。
也可以兩種同時進行，對于不同業(yè)務選擇不同的遷移方案。
個人意見是盡量多的選擇2。
2、OpenStack 與 K8S 容器平臺的融合方案？
【問題描述】
背景環(huán)境：我們公司目前有兩個輕量級的驗證性平臺。一個是基于 OpenStack P版本的 IaaS 云平臺，一個是基于 K8S 1.8版本的容器平臺，都是使用的社區(qū)版本進行的構建，并且在進行了驗證之后將公司內部的應用系統遷移到了云平臺上，將與項目、研發(fā)等相關的產品遷移到了容器平臺上。經過一年多的運行之后，現在因為管理上的需要，規(guī)劃將兩個平臺進行整合，方便進行統一的管理。
現場信息：云平臺有10臺主機，容器平臺5臺主機
已有的思考和嘗試：當前的想法是準備采用在云平臺上開設虛機主機，通過虛擬主機的環(huán)境重新構建一套新的 K8S 環(huán)境，對現有容器平臺的業(yè)務進行遷移。遇到的難點在于有些容器平臺上的業(yè)務對性能要求比較高，經過這樣兩層包裝處理性能衰減的會比較多，影響運行的效率。另外，還有一塊兒我們的部分業(yè)務是需要直接和主機的外接物理設備進行通訊和交互處理的，在本身只有一層平臺的時候配置虛擬主機或者容器可以訪問到該硬件資源就比較復雜了，現在如果變成兩層結構的話，感覺實施部署以及出現故障之后的排故，都會變的很復雜。
但之前有想嘗試通過 K8S 來打包 OpenStack，但結果嘗試失敗了，也沒找到比較合適的開源方案，而且感覺容器平臺上部署云平臺的思路，也有點兒本末倒置，就放棄了。
希望專家能夠提供一些方案性的建議，如果可以的話最好是基于開源的方案，以及一些思路。
@Garyy 某保險 系統工程師：
目前在 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 注入個性化數據（可能這部分的工作量也不?。?。
@鄭金輝 中國電信系統集成公司 技術總監(jiān)：
本來通過 Magnum 可以實現K8s在openstack環(huán)境下的部署，可你的實際情況又不允許，這就不好辦了。你或者可以試著按照社區(qū)里面那樣實現K8s和openstack各個組件的對接，但是工作量可不小。
3、公司規(guī)劃基于OpenStack開源架構方面的進行存儲統一管理，是否有好的解決方案？
【問題描述】目前公司規(guī)劃基于openstack開源架構方面的進行存儲統一管理（例如對接ceph，或者對接glusterfs）但是開源存儲針對openstack 頁面管理等沒有很好的支持，是否有好一些的解決方式?
@zhuqibs Mcd 軟件開發(fā)工程師：
對于開源的存儲解決方案，都是不穩(wěn)定的，比如glusterfs，就經常不可讀，冒bug，讓你不得不重啟，總之，我們吃過無數的苦頭。Ceph也一樣，不過社區(qū)支持好，遇到問題總有前輩來解決。
所以，如果你一定要上開源的分布式存儲，建議上ceph、hdfs等社區(qū)活躍的分布式存儲。ceph雖然源于openstack，但目前使用的領域已經遠遠不限于openstack了。當然openstack對它的支持是原生的，最好的。 如果你再不放心，就只能去買華為的分布式存儲，性能很不錯。
奧，對了，你可能意思是沒有”界面‘’管理，不過你放心，ceph的新版本自己有比較好的管理界面了。
@youki2008 廣東溢達 系統架構師：
OpenStack私有云中，對傳統存儲的自動化統一管理，其實還是需要利用傳統存儲的自身工具，再開發(fā)一個統一的界面來進行管控。
4、OpenStack的nova接管vSphere時需注意什么問題？
@zhuqibs Mcd 軟件開發(fā)工程師：
nova-scheduler 可調度的 nova-compute 可以有多個，并且每個 nova-compute 對應了 vSphere 上的一個 Cluster ,每個 Cluster 又都要有一個 Datastore 進行配置和使用。
通過 Openstack 來創(chuàng)建 vSphere 的虛擬機后，虛擬機在 vCenter 的總控界面中會得到呈現，并且可以支持 VMware 的高級功能。除此之外，在 Horizon 中也會得到呈現，能夠像管理其他 Openstack 虛擬機一樣管理 vCenter 中的虛擬機，但也可能會存在部分 VMware 的功能限制(如ssh keys等)。
@youki2008 廣東溢達 系統架構師：
邏輯上看，OpenStack與vCenter直接通信，VC管理整個ESXi集群，vMotion、HA、DRS也都能用了。但vCenter從Nova-Compute中抽離出了ESXi主機，Nova-Scheduler將整個自管理的集群作為一個獨立主機接入——這會導致一些問題，大致特點如下：
不同于基于內核的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來進行配置和使用。
5、Zabbix 監(jiān)控OpenStack虛擬機選擇什么方式？
【問題描述】使用了openstack 私有云，被迫研究監(jiān)控。想法是，使用zabbix監(jiān)控 openstack云主機。
一種方式：在云主機中安裝 zabbix客戶端，這個不討論了。
另一種方式：zabbix連接 openstack。
查看了一些 zabbix的模板，實現不了云主機的監(jiān)控，目前還在困惑中。
@zhuqibs Mcd 軟件開發(fā)工程師：
分兩層，不要混淆。
對于用戶層，只需要知道Iaas層的云虛擬機是否正常，當然是在openstack用zabbix來監(jiān)控Iaas層的實例，這沒有毛病是必須的。
對于底層，openstack集群的服務器的監(jiān)控，當然你也可以用zabbix，是用內部的那個，還是自搭，我建議后者，由于網絡的原因，最好不好混起來。
@youki2008 廣東溢達 系統架構師：
我們的做法是采用第一種方式：在云主機中安裝 zabbix客戶端。第二種方式使用zabbix連接openstack監(jiān)控云主機的話，監(jiān)控的內容沒有第一種方式多，只能簡單的監(jiān)控云主機的狀態(tài)。
@Garyy 某保險 系統工程師：
推薦第一種方案，openstack的監(jiān)控這塊做得并不好
如果通過openstack中轉的話，很多方面會收到openstack社區(qū)的限制
我們通過prometheus實現的。
6、OpenStack的實施中遇到的難題？
【問題描述】在使用商用openstack產品，在納管VMware的vCenter時是如何能匹配OpenStack產品的上層組織架構（如多租戶的情況）進而有效避免多次重復納管，在接管vcenter時如何能保證網絡的正常使用，對網絡的影響最??？在哪些操作的時候，對網絡有影響？請專家給點意見唄。
@Garyy 某保險 系統工程師：
1.根據VMWare中的VM所在的網絡信息，在Openstack中創(chuàng)建對應的網絡，VLAN ID保持一致
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和內存規(guī)格、操作系統等信息，將創(chuàng)建VM的各環(huán)節(jié)在OpenStack里跑一遍，從而在OpenStack數據庫中構造被納管的VM相關的配置管理數據，但在最后一步并不將相關指令真正下發(fā)到vCenter。
@asdf-asdf cloudstone 研究學者：
openstack產品納管vmware穩(wěn)態(tài)計算資源時候，網絡部分需要根據穩(wěn)態(tài)網絡變化來進行對應調整。這個聯動技術，目前定義為云網聯通,，意思就是和云環(huán)境(openstack)進行聯動變化。穩(wěn)態(tài)網絡變更時候需要調用云網(openstack接口)完成sdn的網絡變化，下策略到sdn中使其能適應穩(wěn)態(tài)網絡環(huán)境的變化。這個技術需要單獨適應客戶環(huán)境化開發(fā)(客制化)開發(fā).比較難處理的一部分業(yè)務內容 。
7、OpenStack中的內部組件是靠什么通訊的？如何保證通訊的可靠性？
@youki2008 廣東溢達 系統架構師：
OpenStack 組件之間的通信分為四類：
1 基于 HTTP 協議
2 基于 AMQP(Advanced Message Queuing Protocol，一個提供統一消息服務的應用層標準高級消息隊列協議) 協議（基于消息隊列協議）
3 基于數據庫連接（主要是 SQL 的通信）
4 Native API（基于第三方的 API）
基于HTTP協議進行通信：
通過各項目的 API 建立的通信關系，基本上都屬于這一類，這些 API 都是 RESTful Web API，最常見的就是通過 Horizon 或者說命令行接口對各組件進行操作的時候產生的這種通信， 然后就是各組件通過 Keystone 對用戶身份進行校驗，進行驗證的時候使用這種通信，還有比如說 Nova Compute 在獲取鏡像的時候和 Glance 之間，對 Glance API 的調用， 還有比方說 Swift 數據的讀寫，也是通過這個 HTTP 協議的 RESTful Web API 來進行的。
基于高級消息隊列協議：
基于 AMQP 協議進行的通信，主要是每個項目內部各個組件之間的通信，比方說 Nova 的 Nova Compute 和 Scheduler 之間，然后 Cinder 的 Scheduler 和 Cinder Volume之間。
需要說明的是，Cinder 是從 Nova Volume 演化出來的，所以 Cinder 和 Nova 之間也有通過 AMQP 協議的通信關系，由于 AMQP 協議進行通信也屬于面向服務的架構， 雖然大部分通過 AMQP 協議進行通信的組件屬于同一個項目，但是并不要求它們安裝在同一個節(jié)點上，給系統的橫向擴展帶來了很大的好處，可以對其中的各個組件分別按照他們負載的情況進行橫向擴展，因為他們不在一個節(jié)點上，分別用不同數量的節(jié)點去承載它們的這些服務。
（ AMQP 是一種協議，OpenStack 沒有規(guī)定它是用什么實現，我們經常使用的是 Private MQ，實際上用戶也可以根據自身的情況選擇其它的消息中間件。）
基于SQL的通信：
通過數據庫連接實現通信，這些通信大多也屬于各個項目內部，也不要求數據庫和項目其它組件安裝在同一個節(jié)點上，它也可以分開安裝，還可以專門部署數據庫服務器， 把數據庫服務放到上面，之間通過基于 SQL 的這些連接來進行通信。OpenStack 沒有規(guī)定必須使用哪種數據庫，雖然通常用的是 MySQL
通過Native API實現通信：
出現在 OpenStack 各組件和第三方的軟硬件之間，比如說，Cinder 和存儲后端之間的通信，Neutron 的 agent 或者說插件和網絡設備之間的通信， 這些通信都需要調用第三方的設備或第三方軟件的 API，我們稱為它們?yōu)?Native API，那么這個就是我們前面說的基于第三方 API 的通信。
@Garyy 某保險 系統工程師：
我們知道對Openstack的各個組件（nova，cinder，neutron等）來說，跨組件交互時使用的是RestAPI相互調用公共接口，組件內部各個進程間通信時使用RPC消息通信，從而實現各組件、各進程之間的解耦。Openstack RPC（Remote Producer Call）機制基于AMQP（Advanced Message Queuing Protocol）協議，搭配各種消息服務器（RabbitMQ，Qpid等）實現各個組件內部進程間的消息傳遞。
AMQP是一個提供統一消息服務的應用層標準協議，基于此協議的客戶端與消息中間件可傳遞消息，并不受客戶端/中間件不同產品、不同開發(fā)語言等條件的限制，實現異步通信。
RPC.call：發(fā)送請求到消息隊列，等待返回最終結果。
RPC.cast：發(fā)送請求到消息隊列，不需要等待最終返回的結果。
在AMQP模型中，幾個主要功能模塊連接成一個處理鏈完成預期的功能：
Publisher：消息發(fā)送者，將消息發(fā)送到 Exchange。
Message：由Header和Body組成，Header是由Publisher添加的各種屬性的集合，包括Message是否被持久化、由哪個Message Queue接受（Routing Key）、優(yōu)先級是多少等。而Body是真正需要傳輸的數據，它是對Server不可見的二進制數據流，在傳輸過程中不受影響……
Exchange：接收發(fā)布應用程序發(fā)送的消息，并根據Routing Key和Binding信息、Exchange Type等參數將這些消息路由到消息隊列。
Binding：關聯Exchange和Message Queue，提供路由規(guī)則。
Message Queue：存儲消息，直到這些消息被消費者安全處理完為止。
Consumer：消息接受者，從 Message Queue 獲取消息。
使用這個模型我們可以很容易的模擬出存儲轉發(fā)隊列和主題訂閱這些典型的消息中間件概念。
AMQP是非對稱的，客戶端生產和消費消息，服務器存儲和路由這些消息。一個AMQP服務器類似于郵件服務器，Exchange類似于消息傳輸代理（email里的概念），Message Queue類似于郵箱。Binding定義了每一個傳輸代理中的消息路由表，發(fā)布者將消息發(fā)給特定的傳輸代理，然后傳輸代理將這些消息路由到郵箱中，消費者從這些郵箱中取出消息。
AMQP模型中不同類型的Exchange對應不同的routing算法：
Direct Exchange：Point-to-Point 消息模式，Direct Exchange 根據 Routing Key 進行精確匹配，只有對應的 Message Queue 會接收到消息。
Topic Exchange：Publish-Subscribe（Pub-sub）消息模式，Topic Exchange 根據 Routing Key 進行模式匹配，只要符合模式匹配的 Message Queue 都會收到消息。
Fanout Exchange：廣播消息模式，Fanout Exchange 將消息轉發(fā)到所有綁定的 Message Queue。
@zhuqibs Mcd 軟件開發(fā)工程師：
樓上的兄弟回答的很全面了，但問的是內部組件，我只摘錄一段：
rabbitmq是openstack的內部默認隊列 ，非常關鍵，一旦阻塞或宕了，整體openstack就會全跨。原生的沒有高可用，但如果真上生產，一定要要配置高可用。
基于高級消息隊列協議：
基于 AMQP 協議進行的通信，主要是每個項目內部各個組件之間的通信，比方說 Nova 的 Nova Compute 和 Scheduler 之間，然后 Cinder 的 Scheduler 和 Cinder Volume之間。
需要說明的是，Cinder 是從 Nova Volume 演化出來的，所以 Cinder 和 Nova 之間也有通過 AMQP 協議的通信關系，由于 AMQP 協議進行通信也屬于面向服務的架構， 雖然大部分通過 AMQP 協議進行通信的組件屬于同一個項目，但是并不要求它們安裝在同一個節(jié)點上，給系統的橫向擴展帶來了很大的好處，可以對其中的各個組件分別按照他們負載的情況進行橫向擴展，因為他們不在一個節(jié)點上，分別用不同數量的節(jié)點去承載它們的這些服務。
（ AMQP 是一種協議，OpenStack 沒有規(guī)定它是用什么實現，我們經常使用的是 Private MQ，實際上用戶也可以根據自身的情況選擇其它的消息中間件。）
8、同城雙活數據中心機房如何規(guī)劃使用OpenStack產品？
【問題描述】商用openstack產品時，對不同同城雙活中心機房，如何進行納管vmware的 vcenter，對納管同城雙活機房的Laas層的資源，架構如何規(guī)劃，在實施過程中，請專家們在有這方便的多介紹一下經驗，進而讓大家盡量避免少跳坑，進而提高業(yè)務的連續(xù)性。
@Garyy 某保險 系統工程師：
同城的雙數據中心和異地中心通過專線互聯，搭建大二層網絡，并實現數據中心業(yè)務數據二層網絡的聯通，真正意義的實現了計算、存儲、網絡資源的統一管理統一調度。配合業(yè)務應用的高可用設計，可以實現同城雙活數據中心中有一個出現故障，可以由另一個中心無縫接替業(yè)務，業(yè)務連續(xù)運行，用戶使用無感知。而如果出現重大事故，同城的兩個雙活中心都出現故障，異地的災備中心可以分鐘級啟動并承載業(yè)務，從而最大限度保障業(yè)務連續(xù)性。
OpenStack采用multi-region方式，將平臺可以部署在3個數據中心，其中兩個為同城雙活數據中心實現業(yè)務無縫切換，和一個為異地容災中心，實現在同城的主數據中心出現重大故障的情況下，分鐘級業(yè)務切換。同時3個數據中心采用統一接口對接上層云資源管理平臺，集中化的認證keystone。各個數據中心的基礎資源有獨立調度平臺。
@asdf-asdf cloudstone 研究學者：
每個數據中心部署 openstack云平臺(虛擬化平臺)區(qū)域，統一由上層云管理平臺完成納管，vmware區(qū)域由openstack的 wmware的納管接口完成納管，資源規(guī)劃需要詳細調研你的業(yè)務云化需求。
方案參考 vmware的一個虛擬化資源池由48個服務器構成，每16個服務器一個機柜，內部部署vc等關聯系統，接入傳統網絡環(huán)境,IP地址等按照穩(wěn)態(tài)計算環(huán)境部署(傳統虛擬化環(huán)境)。
openstack一個虛擬化資源池區(qū)域 15臺服務器組成一個區(qū)域，3個控制節(jié)點，其他是計算節(jié)點，接入硬件SDN構成租戶方式的云化虛擬化環(huán)境，通過彈性ip和外部系統完成互聯。
兩個底層虛擬化技術通過云管理平臺完成互聯互動,對SDN進行集成(創(chuàng)建vmware系統的vm后，調用sdn接口完成網絡配置下發(fā))。
要求實現
雙活需要每個數據中心部署對應的虛擬化池，上層統一管理，對vmware資源池要提前規(guī)劃好所需資源包括IP地址、網絡vlan、存儲空間等, 尤其網絡部分需要完整規(guī)劃避免日后有過多變更。
openstack由于云化管理為敏態(tài)技術，sdn 加持可通過接口后期定義完成網絡變化。
雙活的核心業(yè)務系統需要安裝業(yè)務需求完成規(guī)劃部署，在兩個數據中心實現雙活運行，先規(guī)劃好基礎的云架構，然后挑選一個業(yè)務系統進行測試部署，測試成功后可推廣實施。對于不適用的穩(wěn)態(tài)業(yè)務系統, 目前還是應按照穩(wěn)態(tài)技術進行部署在vmware中。
9、Openstack剛填好坑，更新版本后又要填坑，如何才能高效的運維，避免踩坑？
【問題描述】Openstack的坑是超多的，有的同學說不懼怕填坑，我要說等你填完，半年時間又上一個新版本，難道你繼續(xù)填坑？如何才能高效的運維，避免踩坑？聽聽大家日常運維經驗！
@zhuqibs Mcd 軟件開發(fā)工程師：
無法，因為軟件的更新迭代太快了，你看現在大家學習都不去書店了，為什么能，一方面是因為電子書，但更重要的原因是軟件更新太快，寫書的都寫不過來了，寫好書，可能寫書的版本就被淘汰了，所以，現代IT學習都靠原版的document。 所以，你要“高效運維”， 除非你不改版本。
（1） 選用成熟開源軟件，github上star低于200的，堅決不碰；
（2） 選用LTS版本，穩(wěn)定版；
（3） 不追逐潮流，基本上2年內，不更新版本。
@chinesezzqiang 信息技術經理：
簡單來說的話：
1.有開發(fā)能力的單位是不懼怕的，但是運維成本超高；
2.沒有開發(fā)能力的，建議使用成熟的商業(yè)套件；
3.無論開源還是商用，必須要做好架構的高可用和存儲的高可用。
10、OpenStack如何與Kubernetes做整合？
@zhuqibs Mcd 軟件開發(fā)工程師：
vmware + Kubernetes = PKS， 可以做私有云的商業(yè)化部署；
openstack也有自己的組件marathon來對接docker容器，不過，方向錯了，應該去對接Kubernetes，結果卻是docker。
所以，要把openstack和Kubernetes整合，只能由openstack構建虛機Iaas，Kubernetes在虛機實例上建立集群。但很不穩(wěn)定，因為openstack不穩(wěn)定啊。 所以，現在都是由公有云廠商，對openstack的改進后，再和Kubernetes整合； 分為全托管（只管用集群）+半托管（master節(jié)點不管）+自建三種模式.
@youki2008 廣東溢達 系統架構師：
openstack與k8s關注的層面不一樣， OpenStack關注IaaS資源以及管理，K8S專注容器，沒必要整合在一起吧。
@chinesezzqiang 信息技術經理：
這是兩種不同的技術，同時是兩種不同的虛擬化層面。openstack關注IAAS，k8關注的是容器。兩者可以獨立使用，也可以融合使用。
@俞黎敏 IBM廣州 軟件開發(fā)工程師：
OpenStack提供IaaS資源以及管理，K8S負責CaaS管理，K8S專注在容器這一層。
11、OpenStack虛擬機、裸金屬的OS agent應該如何統一嵌入？
【問題描述】在構建基于OpenStack的云解決方案，虛擬機、裸金屬往往需要使用一個帶內agent幫助其中的監(jiān)控、管理（如修改密碼）能力補齊。但在虛擬機、裸金屬兩種典型不同的計算實例場景下，如何做到其統一嵌入agent是一個比較難的問題，涉及幾個點：
1.虛擬機、裸金屬鏡像統一是各云特別是公有云積極嘗試的點，如果裸金屬、虛擬機各自嵌入的agent不同，那鏡像統一難度又將變大；
2.按照OpenStack已有的虛擬機方案，其默認使用的qga使用虛擬機的VirtIO serial保證平臺與agent通訊的，裸金屬目前沒有此方案，且在裸金屬之上實現虛擬的VirtIO serial難度也較大；
以上，拋出這個問題，暫不了解AWS、阿里云為代表的公有云都是如何實現的，如有大神了解，請幫忙介紹下。
@付廣平 民生銀行 研發(fā)工程師：
qga是通過compute節(jié)點socket與虛擬機serial隧道建立通信的，這種方案只適用于虛擬機，裸機無法支持。
目前OpenStack好像還沒有統一的OS agent可以同時適用虛擬機和裸機，可以參考trove guest agent自己寫一個應用層agent實現如監(jiān)控、修改密碼等功能。
AWS也是通過應用agent進行監(jiān)控和管理的，可以參考ssm-agent。
@chinesezzqiang 信息技術經理：
據我所知，這兩個方案是獨立的。
1.虛擬機是使用qga來監(jiān)控虛擬機的，不適合裸金融的使用；
2.其他的平臺，如阿里、騰訊等用的是自開產品；
3.建議在openstack環(huán)境內部署saltstack等類似的運維自動化軟件，便于監(jiān)控和維護。
