偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

微博基于Docker容器的混合云遷移實戰(zhàn)

云計算 混合云
在過去很長的時間內(nèi),大部分稍大些的互聯(lián)網(wǎng)系統(tǒng)包括微博都是基于私有體系的架構(gòu),可以在某種程度理解成私有云系統(tǒng)?;旌显?,顧名思義就是指業(yè)務(wù)同時部署在私有云和公有云,并且支持在云之間切換

一、為什么要采用混合云的架構(gòu)

在過去很長的時間內(nèi),大部分稍大些的互聯(lián)網(wǎng)系統(tǒng)包括微博都是基于私有體系的架構(gòu),可以在某種程度理解成私有云系統(tǒng)。混合云,顧名思義就是指業(yè)務(wù)同時部署在私有云和公有云,并且支持在云之間切換。實際上“為什么要采用混合云”這個問題,就等于“為什么要上公有云”。我們的考慮點(diǎn)主要有四個方面

業(yè)務(wù)場景

隨著微博活躍度的提升,以及push常規(guī)化等運(yùn)營刺激,業(yè)務(wù)應(yīng)對短時極端峰值挑戰(zhàn),主要體現(xiàn)在兩個方面:

  • 時間短,業(yè)務(wù)需要應(yīng)對分鐘級或者小時級。
  • 高峰值,例如話題經(jīng)常出現(xiàn)10到20倍流量增長。

成本優(yōu)勢

對于短期峰值應(yīng)對,常規(guī)部署,離線計算幾個場景,我們根據(jù)往年經(jīng)驗進(jìn)行成本對比發(fā)現(xiàn)公有云優(yōu)勢非常明顯

效率優(yōu)勢

公有云可以實現(xiàn)5分鐘千級別節(jié)點(diǎn)的彈性調(diào)度能力,對比我們目前的私有云5分鐘百級別節(jié)點(diǎn)的調(diào)度能力,也具有明顯優(yōu)勢。

業(yè)界趨勢

“Amazon首次公布AWS業(yè)績:2014年收入51.6億美元,2015年1季度AWS收入15.7億美元,年增速超40%。”“阿里巴巴旗下云計算業(yè)務(wù)阿里云營收6.49億元,比去年同期增長128%,超越亞馬遜和微軟的云計算業(yè)務(wù)增速,成為全球增速最快的云計算服務(wù)商。”

我們預(yù)計未來產(chǎn)品技術(shù)架構(gòu)都會面臨上云的問題,只是時間早晚問題。

安全性

基于數(shù)據(jù)安全的考慮,我們現(xiàn)階段只會把計算和緩存節(jié)點(diǎn)上云,核心數(shù)據(jù)還放在私有云;另外考慮到公有云的技術(shù)成熟度,需要支持在多個云服務(wù)直接進(jìn)行業(yè)務(wù)靈活遷移。

基于上述幾點(diǎn)考慮,我們今年嘗試了以私有云為主,公有云為輔的混合云架構(gòu)。核心業(yè)務(wù)的峰值壓力,會在公有云上實現(xiàn),業(yè)務(wù)部署形態(tài)可參考下圖

下面介紹介紹技術(shù)實現(xiàn)。整體技術(shù)上采用的是Docker Machine + Swarm + Consul的框架。系統(tǒng)分層如下圖

二、跨云的資源管理與調(diào)度

跨云的資源管理與調(diào)度(即上圖中的pluto部分)的作用是隔離云服務(wù)差異,對上游交付統(tǒng)一的Docker運(yùn)行環(huán)境,支持快速彈性擴(kuò)縮容及跨云調(diào)度。功能上主要包括:

  • 系統(tǒng)初始化
  • 元數(shù)據(jù)管理
  • 鏡像服務(wù)
  • 網(wǎng)絡(luò)
  • 云服務(wù)選型
  • 命令行工具
  • 其他

系統(tǒng)界面如下圖:

系統(tǒng)初始化

最初技術(shù)選型時認(rèn)為Machine比較理想,僅需要SSH通道,不依賴任何預(yù)裝的Agent。我們也幾乎與阿里云官方同時向Docker Machine社區(qū)提交了Driver的PR,然后就掉進(jìn)了大坑中不能自拔。

例舉幾個坑:

  • 無法擴(kuò)展,Machine的golang函數(shù)幾乎都是小寫,即內(nèi)部實現(xiàn),無法調(diào)用其API進(jìn)行功能擴(kuò)展。
  • 不支持并發(fā),并發(fā)創(chuàng)建只能通過啟動多個Machine進(jìn)程的方式,數(shù)量多了無法承載。
  • 不支持自定義,Machine啟動Docker Daemon是在代碼中寫死的,要定義Daemon的參數(shù)就非常ugly。

目前我們采用的是Puppet的方案,采用去Master的結(jié)構(gòu)。配置在GitLab上管理,變更會通過CI推送到pluto系統(tǒng),然后再推送到各實例進(jìn)行升級。在基礎(chǔ)資源層面,我們目前正在進(jìn)行大范圍基礎(chǔ)環(huán)境從CentOS 6.5升級到CentOS 7的工作。做這個升級的主要原因是由于上層基于調(diào)度系統(tǒng)依賴Docker新版本,而新版本在CentOS 6.5上會引發(fā)cgroup的bug,導(dǎo)致Kernel Panic問題。

元數(shù)據(jù)的管理

調(diào)度算法需要根據(jù)每個實例的情況進(jìn)行資源篩選,這部分信息目前是通過Docker Daemon的Label實現(xiàn)的,這樣做的好處是資源和調(diào)度可以Docker Daemon解耦。例如我們會在Daemon上記錄這個實例的歸屬信息:

  • —label idc=$provider #記錄云服務(wù)提供商
  • —label ip=$eth0 #記錄ip信息
  • —label srv=$srv #記錄所屬業(yè)務(wù)
  • —label role=ci/test/production…

目前Docker Daemon最大的硬傷是任何元數(shù)據(jù)的改變都需要重啟。所以我們計劃把元數(shù)據(jù)從Daemon遷移到我們的系統(tǒng)中,同時嘗試向社區(qū)反饋這個問題,比如動態(tài)修改Docker Daemon Label的接口(PR被拒,官方雖然也看到了問題,但是比較糾結(jié)是否要支持API方式),動態(tài)修改registry(PR被拒,安全因素),動態(tài)修改 Docker Container Expose Port(開發(fā)中)。

鏡像服務(wù)

為了提升基礎(chǔ)資源擴(kuò)縮容的效率,我們正在構(gòu)建虛機(jī)鏡像服務(wù)。參考Dockerfile的思路,通過描述文件定義定義虛機(jī)的配置,支持繼承關(guān)系,和簡單的初始化指令。通過預(yù)先創(chuàng)建好的鏡像進(jìn)行擴(kuò)縮容,可以節(jié)省大約50%的初始化時間。

描述文件示意如下:

centos 7.0:

– dns: 8.8.8.8

– docker:

– version: 1.6

– net: host

meta:

– service: $SRV

puppet:

– git: git.intra.weibo.com/docker/puppet/tags/$VERSION

entrypoint:

– init.sh

不過虛機(jī)鏡像也有一些坑,例如一些云服務(wù)會在啟動后自行修改一部分配置,例如router, dns, ntp, yum等配置。這就是上面entrypoint的由來,部分配置工作需要在實例運(yùn)行后進(jìn)行。

網(wǎng)絡(luò)

網(wǎng)絡(luò)的互聯(lián)互通對業(yè)務(wù)來說非常關(guān)鍵,通常來說有三種方案:公網(wǎng),VPC+VPN,VPC+專線。公網(wǎng)因為性能完全不可控,而且云服務(wù)通常是按照出帶寬收費(fèi),所以比較適合相互通信較少的業(yè)務(wù)場景。VPC+VPN實際鏈路也是通過公網(wǎng),區(qū)別是安全性更好,而且可以按照私有云的IP段進(jìn)行網(wǎng)絡(luò)規(guī)劃。專線性能最好,但是價錢也比較好,且受運(yùn)營商政策影響的風(fēng)險較大。

網(wǎng)絡(luò)上需要注意的是包轉(zhuǎn)發(fā)能力,即每秒可以收發(fā)多少個數(shù)據(jù)包。一些云服務(wù)實測只能達(dá)到10萬的量級,而且與CPU核數(shù)、內(nèi)存無 關(guān)。也就是說你花再多的錢,轉(zhuǎn)發(fā)能力也上不去。猜測是云廠商出于安全考慮在虛機(jī)層面做了硬性限制。我們在這上面也中過槍,比如像Redis主從不同步的問題等等。建議對于QPS壓力比較重的實例進(jìn)行拆分。

云服務(wù)選型

我們主要使用的是虛機(jī)和軟負(fù)載兩種云服務(wù)。因為微博對緩存服務(wù)已經(jīng)構(gòu)建一套高可用架構(gòu),所以我們沒有使用公有云的緩存服務(wù),而是在虛機(jī)中直接部署緩存容器。

虛機(jī)的選型我們重點(diǎn)關(guān)注CPU核數(shù),內(nèi)存,磁盤幾個方面。CPU調(diào)度能力,我們測試總結(jié)公有云是私有云的1.2倍,即假設(shè)業(yè)務(wù)在私有云上需要6個核,在公有云上則需要8個。

內(nèi)存寫入速度和帶寬都不是問題,我們測試發(fā)現(xiàn)甚至還好于私有云,MEMCPY的帶寬是私有云的1.2倍,MCBLOCK是1.7倍。所以內(nèi)存主要考慮的是價錢問題。

磁盤的性能也表現(xiàn)較好,順序讀寫帶寬公有云是私有云的1.4倍,隨機(jī)寫是1.6倍。唯一要注意的是對于Redis這種業(yè)務(wù),需要使用I/O優(yōu)化型的虛機(jī)。

以上數(shù)據(jù)僅供參考,畢竟各家情況不一樣,我們使用的性能測試工具:sysbench, mbw, fio,可自行測試。

CLI客戶端(命令行工具)

為了伺候好工程師們,我們實現(xiàn)了簡單的命令行客戶端。主要功能是支持創(chuàng)建Docker容器(公有云或私有云),支持類SSH登陸。因為我們要求容器本身都不提供SSH(安全考慮),所以我們是用Ruby通過模擬docker client的exec命令實現(xiàn)的,效果如下圖:

其他方面

跨域的資源管理和調(diào)度還有很多技術(shù)環(huán)節(jié)需要處理,比如安全,基礎(chǔ)設(shè)施(DNS、YUM等),成本核算,權(quán)限認(rèn)證,由于這部分通用性不強(qiáng),這里就不展開了。

#p#

三、容器的編排與服務(wù)發(fā)現(xiàn)

提到調(diào)度就離不開發(fā)現(xiàn),Swarm是基于Consul來做節(jié)點(diǎn)發(fā)現(xiàn)的。Consul采用raft協(xié)議來保證server之間的數(shù)據(jù)一致性,采用 gossip協(xié)議管理成員和傳播消息,支持多數(shù)據(jù)中心。Consul集群中的所有請求都會重定向到server,對于非leader的server會將寫請求轉(zhuǎn)發(fā)給leader處理。

Consul對于讀請求支持3種一致性模式:

default :給leader一個time window,在這個時間內(nèi)可能出現(xiàn)兩個leader(split-brain情況下),舊的leader仍然支持讀的請求,會出現(xiàn)不一致的情況。

consistent :完全一致,在處理讀請求之前必須經(jīng)過大多數(shù)的follower確認(rèn)leader的合法性,因此會多一次round trip。

stale :允許所有的server支持讀請求,不管它是否是leader。

我們采用的是default模式。

除了Swarm是基于Consul來做發(fā)現(xiàn),業(yè)務(wù)直接也是通過Consul來做發(fā)現(xiàn)。我們服務(wù)采用Nginx來做負(fù)載均衡,開源社區(qū)的方案例如 Consul Template,都需要進(jìn)行reload操作,而reload過程中會造成大量的失敗請求。我們現(xiàn)在基于Consul實現(xiàn)了一個nginx- upsync-module。

Nginx僅需在upstream配置中聲明Consul集群即可完成后端服務(wù)的動態(tài)發(fā)現(xiàn)

  1. upstream test { 
  2. # fake server otherwise ngx_http_upstream will report error when startup 
  3. server 127.0.0.1:11111; 
  4. # all backend server will pull from consul when startup and will delete fake server 
  5. consul 127.0.0.1:8500/v1/kv/upstreams/test update_timeout=6m update_interval=500ms strong_dependency=off; 
  6. upstream_conf_path /usr/local/nginx/conf/upstreams/upstream_test.conf; 

這個模塊是用C語言實現(xiàn)的,效率已經(jīng)經(jīng)過線上驗證,目前驗證在20W QPS壓力沒有問題。而且這個模塊代碼已經(jīng)開源在Github上,也歡迎大家提Issue:https://github.com/weibocom/nginx-upsync-module。

下圖是我們做的幾種方案的性能對比:

當(dāng)然我們的RPC框架motan也會支持Consul,實現(xiàn)機(jī)制同樣也是利用Consul的long polling機(jī)制,等待直到監(jiān)聽的X-Consul-Index位置發(fā)生變化,這個功能已經(jīng)在我們內(nèi)網(wǎng)驗證通過,不過由于依賴整個motan框架,所以目前還沒有開源。

Consul的監(jiān)控

由于Consul處于系統(tǒng)核心位置,一旦出現(xiàn)問題會導(dǎo)致整體所有集群失聯(lián),所以我們對Consul做了一系列保障措施,其中所有Consul Server節(jié)點(diǎn)監(jiān)控指標(biāo)如下

Leader節(jié)點(diǎn)監(jiān)控指標(biāo)如下圖

Consul的坑

除了使用不當(dāng)導(dǎo)致的問題之外,Consul Server節(jié)點(diǎn)通信通道UDP協(xié)議,偶發(fā)會出現(xiàn)server不停被摘除的現(xiàn)象,這個問題官方已在跟進(jìn),計劃會增加TCP的通道保證消息的可靠性。

容器調(diào)度

容器調(diào)度基于Swarm實現(xiàn),依賴Consul來做節(jié)點(diǎn)發(fā)現(xiàn)(話說Swarm才剛剛宣布Production Ready)。容器調(diào)度分為三級,應(yīng)用-應(yīng)用池-應(yīng)用實例,一個應(yīng)用下有多個應(yīng)用池,應(yīng)用池可以按機(jī)房和用途等來劃分。一個應(yīng)用池下有多個Docker容器形式的應(yīng)用實例。

我們利用Swarm的Filter機(jī)制,實現(xiàn)了適應(yīng)業(yè)務(wù)的調(diào)度算法。整個調(diào)度過程分為兩步:主機(jī)過濾:指定機(jī)房、內(nèi)存、CPU、端口等條件,篩選出符合條件的主機(jī)集合;策略選擇:對符合條件的主機(jī)集合進(jìn)行打分,選擇出最合適的主機(jī),在其上創(chuàng)建容器以部署應(yīng)用。調(diào)度子系統(tǒng)Roam實現(xiàn)了批量的容器調(diào)度與編排。

業(yè)務(wù)調(diào)度

容器調(diào)度是于業(yè)務(wù)無關(guān),具體串聯(lián)起資源管理,容器調(diào)度,發(fā)現(xiàn)等系統(tǒng),完成業(yè)務(wù)容器最終跨云部署的是我們的JPool系統(tǒng)。JPool除了完成日常的業(yè)務(wù)容器上線發(fā)布之外,最重要的是完成動態(tài)擴(kuò)縮容功能,使業(yè)務(wù)實現(xiàn)一鍵擴(kuò)容、一鍵縮容,降低快速擴(kuò)容成本。一次擴(kuò)容操示意圖如下

圍繞這調(diào)度和發(fā)現(xiàn),需要很多工具的支撐:

例如為了使業(yè)務(wù)接入更加方便,我們提供了自動打包工具,它包括代碼打包、鏡像打包的解決方案,支持svn、gitlab等代碼倉庫,業(yè)務(wù)僅需要在工程中定義pom.xml和Dockerfile即可實現(xiàn)一鍵打包代碼,一鍵打包鏡像,過程可控,接入簡單。

我們還對Docker的Registry,我們進(jìn)行了一些優(yōu)化,主要是針對混合云跨機(jī)房場景,提供跨機(jī)房加速功能,整個服務(wù)架構(gòu)如下:

#p#

四、混合云監(jiān)控體

微博體系在經(jīng)歷了多年的IT建設(shè)過程后,已經(jīng)初步建立了一套完整的信息化管理流程,極大地提升了微博業(yè)務(wù)能力。同時微博開展了大量的IT基礎(chǔ)設(shè)施建設(shè)(包括網(wǎng)絡(luò)、機(jī)房、服務(wù)器、存儲設(shè)置、數(shù)據(jù)庫、中間件及各業(yè)務(wù)應(yīng)用系統(tǒng)等)。

針對于混合云體系,我們提供了一套完整的監(jiān)控告警解決方案,實現(xiàn)對于云上IT基礎(chǔ)架構(gòu)的整體監(jiān)控與預(yù)警機(jī)制,最大程度地保證了微博體系能夠穩(wěn)定地運(yùn)行在混合云體系上,不間斷地為用戶提供優(yōu)質(zhì)的服務(wù)。監(jiān)控告警解決方案實現(xiàn)了四個級別上的監(jiān)控與預(yù)警:

  • 系統(tǒng)級監(jiān)控
  • 業(yè)務(wù)級監(jiān)控
  • 資源級監(jiān)控
  • 專線網(wǎng)絡(luò)監(jiān)控
  • 系統(tǒng)級監(jiān)控

混合云體系支持的系統(tǒng)級監(jiān)控(與新浪sinawatch系統(tǒng)的對接)包括:CPU,磁盤,網(wǎng)卡,IOPS,Load,內(nèi)存

業(yè)務(wù)監(jiān)控

混合云體系集成了目前微博業(yè)務(wù)監(jiān)控平臺Graphite,自動提供了業(yè)務(wù)級別(SLA)的實時監(jiān)控與告警。所有的配置與操作都是系統(tǒng)自動完成的,不需要用戶進(jìn)行額外的配置操作。

業(yè)務(wù)級別的監(jiān)控包括:

  • JVM監(jiān)控: 實時監(jiān)控堆、棧使用信息、統(tǒng)計gc收集時間、檢查JVM瓶頸等。
  • 吞吐量監(jiān)控: 實時監(jiān)控業(yè)務(wù)系統(tǒng)吞吐量(QPS或TPS)。
  • 平均耗時監(jiān)控: 實時監(jiān)控業(yè)務(wù)系統(tǒng)接口的平均耗時時間。
  • 單機(jī)性能監(jiān)控: 實時監(jiān)控單臺服務(wù)器的各種業(yè)務(wù)指標(biāo)。
  • Slow監(jiān)控: 監(jiān)控服務(wù)器集群,實時顯示當(dāng)前業(yè)務(wù)系統(tǒng)中最慢的性能瓶頸。

資源監(jiān)控

混合云體系集成了目前微博資源監(jiān)控平臺sinadsp,自動提供了對各種底層資源的實時監(jiān)控與告警。所有的配置與操作都是系統(tǒng)自動完成的,不需要用戶進(jìn)行額外的配置操作。

具體的監(jiān)控指標(biāo)包括:命中率,QPS/TPS,連接數(shù),上行/下行帶寬,CPU,內(nèi)存。

五、前進(jìn)路上遇到的那些坑

需要注意的坑,實際在各部分中都有提及。今天分享的主要內(nèi)容就是這些了,當(dāng)然業(yè)務(wù)上云,除了上面這些工作之外,還存在很多技術(shù)挑戰(zhàn)要解決。比如跨云的消息總線,緩存數(shù)據(jù)同步,容量評估,流量調(diào)度,RPC框架,微服務(wù)化等。

Q&A

Q1 : 為什么選Consul?看中有對比Zookeeper、etcd,尤其是etcd?

我們有對比etcd和consul,主要還是看重了consul基于K-V之外額外功能,比如支持DNS,支持ACL。另外etcd不對get request做超時處理,Consul對blocking query有超時機(jī)制。

Q2 : 上面提到的方案主要是Java體系, 對于其他語言(php, nodejs, golang)體系系統(tǒng)的是否有很好的支持(開發(fā)、測試、發(fā)布部署、監(jiān)控等)?

已經(jīng)在開始php的支持。其實容器化之后,所有語言都是適用的。

Q3 : Docker registry底層存儲用的是什么,怎么保障高可用的?

底層使用的Ceph,前端無狀態(tài),通過DNS做跨云智能解析,加速下載。

Q4 : Consul temple reload nginx時為什么會造成大量請求失敗呢,不是graceful的嗎?

是graceful的,在QPS壓力較大的情況下,由于需要進(jìn)行大量重連,過程中會產(chǎn)生較多失敗請求。

Q5 : 剛才提到的調(diào)度系統(tǒng)是自己開發(fā)的?還是基于開源改的?

是基于Swarm二次開發(fā)的。

Q6 : 容器跨主機(jī)通信是host網(wǎng)絡(luò)嗎?

對,目前線上采用的是host網(wǎng)絡(luò)。

Q7 : Ceph IO情況怎么?高IO的是不是不太適合用Ceph?

針對Registry場景Ceph IO是可以勝任的。不過Ceph暫時還沒有宣布Production Ready,所以對于極端業(yè)務(wù)場景,請謹(jǐn)慎。

關(guān)于作者

微博研發(fā)中心技術(shù)經(jīng)理及高級技術(shù)專家。2008年畢業(yè)于北京郵電大學(xué),碩士學(xué)位。畢業(yè)后就職華為北研。2012年加入新浪微博,負(fù)責(zé)微博Feed、用戶關(guān) 系和微博容器化相關(guān)項目,致力于Docker技術(shù)在生產(chǎn)環(huán)境中的規(guī)?;瘧?yīng)用。2015年3月,曾在QClub北京Docker專場分享《大規(guī)模 Docker集群助力微博迎接春晚峰值挑戰(zhàn)》。

【內(nèi)容來源:高可用架構(gòu)公眾號ArchNotes】

 

 

責(zé)任編輯:Ophira 來源: 高可用架構(gòu)
相關(guān)推薦

2016-01-04 11:47:07

微博混合云Docker

2017-06-14 08:47:04

混合云PHP服務(wù)化

2021-11-09 09:46:09

ScrapyPython爬蟲

2021-11-08 14:38:50

框架Scrapy 爬蟲

2011-05-25 10:57:25

混合云遷移

2011-02-25 17:04:03

vCloud Conn混合云

2016-05-23 10:57:19

個人云云計算iBIG

2015-09-09 15:16:19

混合云云遷移

2020-04-27 09:38:15

Kubernetes多云混合云

2021-02-24 09:15:48

kubernetes混合云云端

2021-01-03 19:58:35

混合云云遷移云計算

2021-03-11 10:24:58

Kubernetes混合云云平臺

2015-05-28 09:54:33

美團(tuán)docker容器

2021-01-08 10:14:13

云計算混合云IT

2022-07-25 14:24:53

Docker容器安全

2010-06-15 22:06:55

私有云混合云遷移

2018-07-10 11:18:31

私有云混合云遷移

2016-04-06 10:02:23

手機(jī)微博運(yùn)維監(jiān)控

2017-11-25 19:11:45

微服務(wù)架構(gòu)設(shè)計

2010-11-09 11:12:23

點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號