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