對(duì)于蘑菇街而言，每年的11.11已經(jīng)成為一年中最大的考驗(yàn)，考驗(yàn)的是系統(tǒng)穩(wěn)定性，容災(zāi)能力，緊急故障處理，運(yùn)維等各個(gè)方面的能力。蘑菇街的私有云平臺(tái)，從無到有，已經(jīng)經(jīng)過了近一年的發(fā)展，生產(chǎn)環(huán)境上經(jīng)歷了3次大促，穩(wěn)定性方面得到了初步驗(yàn)證。本文我將從架構(gòu)、技術(shù)選型、應(yīng)用等角度來談?wù)勀⒐浇值乃接性破脚_(tái)。

另，ArchSummit全球架構(gòu)師峰會(huì)北京站將于2015年12月18日~19日在北京國(guó)際會(huì)議中心召開，大會(huì)設(shè)置了《揭秘雙十一背后的技術(shù)較量》專題來深入解讀雙十一背后的技術(shù)故事，歡迎關(guān)注。

蘑菇街的私有云平臺(tái)（以下簡(jiǎn)稱蘑菇街私有云）是蘑菇街面向內(nèi)部上層業(yè)務(wù)提供的基礎(chǔ)性平臺(tái)。通過基礎(chǔ)設(shè)施的服務(wù)化和平臺(tái)化，可以使上層業(yè)務(wù)能夠更加專注在業(yè)務(wù)自身，而不是關(guān)心底層運(yùn)行環(huán)境的差異性。它通過基于Docker的CaaS層和KVM的IaaS層來為上層提供IaaS/PaaS層的云服務(wù)，以提高物理資源的利用率，以及業(yè)務(wù)部署和交付的效率，并促進(jìn)應(yīng)用架構(gòu)的拆分和微服務(wù)化。

在架構(gòu)選型的時(shí)候，我們覺得Docker的輕量化，秒級(jí)啟動(dòng)，標(biāo)準(zhǔn)化的打包／部署／運(yùn)行的方案，鏡像的快速分發(fā)，基于鏡像的灰度發(fā)布等特性，都十分適合我們的應(yīng)用場(chǎng)景。而Docker自身的集群管理能力在當(dāng)時(shí)條件下還很不成熟，因此我們沒有選擇剛出現(xiàn)的Swarm，而是用了業(yè)界最成熟的OpenStack，這樣能同時(shí)管理Docker和KVM虛擬機(jī)。相對(duì)來說，Docker適合于無狀態(tài)，分布式的業(yè)務(wù)，KVM適合對(duì)安全性，隔離性要求更高的業(yè)務(wù)。
對(duì)于上層業(yè)務(wù)來說，它不需要關(guān)心是運(yùn)行在容器中，還是KVM虛擬機(jī)里。今后的思路是應(yīng)用的微服務(wù)化，把上層的業(yè)務(wù)進(jìn)行拆分，變成一個(gè)個(gè)微服務(wù)，從而對(duì)接PaaS基于容器的部署和灰度發(fā)布。

技術(shù)架構(gòu)

在介紹雙十一的準(zhǔn)備工作之前，我先簡(jiǎn)單介紹一下蘑菇街私有云的技術(shù)架構(gòu)。

我們采用的是OpenStack＋novadocker＋Docker的架構(gòu)模式，novadocker是StackForge上一個(gè)開源項(xiàng)目，它做為nova的一個(gè)插件，通過調(diào)用Docker的RESTful接口來控制容器的啟停等動(dòng)作。每個(gè)Docker就是所謂的“胖容器”，它會(huì)有獨(dú)立的IP地址，通過supervisord來管理容器內(nèi)的子進(jìn)程，常見的如SSHD、監(jiān)控agent等進(jìn)程。

我們?cè)贗aaS的基礎(chǔ)上自研了PaaS層的編排調(diào)度等組件，實(shí)現(xiàn)了應(yīng)用的彈性伸縮、灰度升級(jí)，支持一定的調(diào)度策略。我們通過Docker和Jenkins實(shí)現(xiàn)了持續(xù)集成（CI）。Git中的項(xiàng)目如果發(fā)生了git push等動(dòng)作，便會(huì)觸發(fā)Jenkins Job進(jìn)行自動(dòng)構(gòu)建，如果構(gòu)建成功便會(huì)生成Docker Image并push到鏡像倉(cāng)庫(kù)?；贑I生成的Docker Image，可以通過PaaS的API或界面，進(jìn)行開發(fā)測(cè)試環(huán)境的實(shí)例更新，并最終進(jìn)行生產(chǎn)環(huán)境的實(shí)例更新，從而實(shí)現(xiàn)持續(xù)集成和持續(xù)交付。
網(wǎng)絡(luò)方面，我們沒有采用Docker默認(rèn)提供的NAT網(wǎng)絡(luò)模式，NAT會(huì)造成一定的性能損失。通過OpenStack，我們支持Linux bridge和openvswitch，不需要啟動(dòng)iptables，Docker的性能接近物理機(jī)的95%。

準(zhǔn)備工作 穩(wěn)定性

迎戰(zhàn)雙11，最重要的當(dāng)然是確保穩(wěn)定性。通過近一年的產(chǎn)品化和實(shí)際使用，我們積累了豐富的提高穩(wěn)定性的經(jīng)驗(yàn)。
對(duì)于那些已遇到過的問題，需要及時(shí)采用各種方式進(jìn)行解決或者規(guī)避。

比如說，CentOS6.5對(duì)network namespace支持不好，在Docker容器內(nèi)創(chuàng)建Linux bridge會(huì)導(dǎo)致內(nèi)核crash，upstream在2.6.32-504中修復(fù)了這個(gè)bug，因此線上集群的內(nèi)核版本，必須升級(jí)至2.6.32－504或以上。

又比如，CentOS6.5自帶的device mapper存在dm-thin discard導(dǎo)致內(nèi)核可能隨機(jī)crash，這個(gè)問題我們?cè)缭谒脑路莸臅r(shí)候已經(jīng)發(fā)現(xiàn)并解決了，解決的辦法是關(guān)閉discard support，在docker配置中添加“--storage-opt dm.mountopt=nodiscard --storage-opt dm.blkdiscard=false”，并且嚴(yán)格禁止磁盤超配，因?yàn)榇疟P超配可能會(huì)導(dǎo)致整個(gè)device mapper無法分配磁盤空間，而把整個(gè)文件系統(tǒng)變成只讀，從而引起嚴(yán)重問題。

監(jiān)控

我們?cè)陔p11前重點(diǎn)加強(qiáng)的是針對(duì)容器的監(jiān)控。

在此之前，我們已經(jīng)自研了一套container tools。主要功能有兩個(gè)：一是能夠以容器為粒度計(jì)算load值，可以根據(jù)load值進(jìn)行容器粒度的qps限流。二是替換了原有的top、free、iostat、uptime等命令，確保運(yùn)維在容器內(nèi)使用常用命令時(shí)看到的是容器的值，而不是整個(gè)物理機(jī)的值。雙十一之后我們還會(huì)把lxcfs移植到我們的平臺(tái)上來。

在宿主機(jī)上，我們?cè)黾恿硕嗑S度的閾值監(jiān)控和報(bào)警，包括對(duì)關(guān)鍵進(jìn)程的存活性監(jiān)控／語義監(jiān)控，內(nèi)核日志的監(jiān)控，實(shí)時(shí)pid數(shù)量的監(jiān)控，網(wǎng)絡(luò)連接跟蹤數(shù)的監(jiān)控，容器oom的監(jiān)控報(bào)警等等。

實(shí)時(shí)pid數(shù)量監(jiān)控

為什么要監(jiān)控實(shí)時(shí)的pid數(shù)量呢？因?yàn)槟壳暗腖inux內(nèi)核對(duì)pid的隔離性支持是不完善的。還沒有任何Linux發(fā)行版能做到針對(duì)pid按照容器粒度進(jìn)行pid_max限制。

曾經(jīng)發(fā)生過一個(gè)真實(shí)的案例是：某個(gè)用戶寫的程序有bug，創(chuàng)建的線程沒有及時(shí)回收，容器中產(chǎn)生了大量的線程，最后在宿主機(jī)上都無法執(zhí)行命令或者ssh登陸，報(bào)的錯(cuò)是"bash: fork: Cannot allocate memory"，但是此時(shí)通過free命令看到空閑的內(nèi)存卻是足夠的。

為什么會(huì)這樣呢？根本原因是內(nèi)核中的pid_max(/proc/sys/kernel/pid_max)是全局共享的。當(dāng)一個(gè)容器中的pid數(shù)目達(dá)到上限32768，會(huì)導(dǎo)致宿主機(jī)和其他容器無法創(chuàng)建新的進(jìn)程。最新的4.3-rc1才支持對(duì)每個(gè)容器進(jìn)行pid_max的限制。

內(nèi)存使用監(jiān)控

值得一提的是，我們發(fā)現(xiàn)cgroup提供的內(nèi)存使用值是不準(zhǔn)確的，比真實(shí)使用的內(nèi)存值要低。因?yàn)閮?nèi)核memcg無法回收slab cache，也不對(duì)dirty cache量進(jìn)行限制，所以很難估算容器真實(shí)的內(nèi)存使用情況。曾經(jīng)發(fā)生過統(tǒng)計(jì)的內(nèi)存使用率一到70-80%，就發(fā)生OOM的情況。為此，我們調(diào)整了容器內(nèi)存的計(jì)算算法，根據(jù)經(jīng)驗(yàn)值，將cache的40%算做rss，調(diào)整后的內(nèi)存計(jì)算比之前精確了不少。

日志亂序

還有一個(gè)問題是跑Docker的宿主機(jī)內(nèi)核日志中經(jīng)常會(huì)產(chǎn)生字符亂序，這樣會(huì)導(dǎo)致日志監(jiān)控?zé)o法取到正確的關(guān)鍵字進(jìn)行報(bào)警。
經(jīng)過分析發(fā)現(xiàn)，這個(gè)跟我們?cè)谒拗鳈C(jī)和Docker容器中都跑了rsyslogd有關(guān)。由于內(nèi)核中只有一個(gè)log_buf緩沖區(qū)，所有printk打印的日志先放到這個(gè)緩沖區(qū)中，docker host以及container上的rsyslogd都會(huì)通過syslog從kernel的log_buf緩沖區(qū)中取日志，導(dǎo)致日志混亂。通過修改container里的rsyslog配置，只讓宿主機(jī)去讀kernel日志，就能解決這個(gè)問題。

隔離開關(guān)

平時(shí)我們的容器是嚴(yán)格隔離的，我們做的隔離包括CPU、內(nèi)存和磁盤IO，網(wǎng)絡(luò)IO等。但雙十一的業(yè)務(wù)量可能是平時(shí)的十幾倍或幾十倍。我們?yōu)殡p十一做了不少開關(guān)，在壓力大的情況下，我們可以為個(gè)別容器進(jìn)行動(dòng)態(tài)的CPU，內(nèi)存等擴(kuò)容或縮容，調(diào)整甚至放開磁盤iops限速和網(wǎng)絡(luò)的TC限速。

健康監(jiān)測(cè)

我們還開發(fā)了定期的健康監(jiān)測(cè)，定期的掃描線上可能存在的潛在風(fēng)險(xiǎn)，真正做到提前發(fā)現(xiàn)問題，解決問題。
災(zāi)備和緊急故障處理

除了穩(wěn)定性，災(zāi)備能力也是必須的，我們做了大量的災(zāi)備預(yù)案和技術(shù)準(zhǔn)備。比如我們研究了不啟動(dòng)Docker Daemon的情況下，離線恢復(fù)Docker中數(shù)據(jù)的方法。具體來說，是用dmsetup create命令創(chuàng)建一個(gè)臨時(shí)的dm設(shè)備，映射到Docker實(shí)例所用的dm設(shè)備號(hào)，通過mount這個(gè)臨時(shí)設(shè)備，就可以恢復(fù)出原來的數(shù)據(jù)。

我們還支持Docker容器的冷遷移。通過管理平臺(tái)的界面可以一鍵實(shí)現(xiàn)跨物理機(jī)的遷移。
與已有運(yùn)維系統(tǒng)的對(duì)接

Docker集群必須能與現(xiàn)有的運(yùn)維系統(tǒng)無縫對(duì)接，才能快速響應(yīng)，真正做到秒級(jí)的彈性擴(kuò)容／縮容。我們有統(tǒng)一的容器管理平臺(tái)，實(shí)現(xiàn)對(duì)多個(gè)Docker集群的管理，從下發(fā)指令到完成容器的創(chuàng)建可以在7秒內(nèi)完成。

性能優(yōu)化

我們從系統(tǒng)層面也對(duì)docker做了大量的優(yōu)化，比如針對(duì)磁盤IO的性能瓶頸，我們調(diào)優(yōu)了像vm.dirty_expire_centisecs,vm.dirty_writeback_centisecs, vm.extra_free_kbytes這樣的內(nèi)核參數(shù)。還引入了Facebook的開源軟件flashcache，將SSD作為cache，顯著的提高docker容器的IO性能。

我們還通過合并鏡像層次來優(yōu)化docker pull鏡像的時(shí)間。在docker pull時(shí)，每一層校驗(yàn)的耗時(shí)很長(zhǎng)，通過減小層數(shù)，不僅大小變小，docker pull時(shí)間也大幅縮短。

總結(jié)

總的來說，雙11是對(duì)蘑菇街私有云的一次年終大考，對(duì)此我們已有了充分的準(zhǔn)備。隨著Docker集群部署的規(guī)模越來越大，我們還有很多技術(shù)難題有待解決，包括容器本身的隔離性問題，集群的彈性調(diào)度問題等等。同時(shí)我們也很關(guān)注Docker相關(guān)的開源軟件Kubernetes、Mesos、Hyper、criu、runC的發(fā)展，未來將引入容器的熱遷移，Docker Daemon的熱升級(jí)等特性。

感謝閱讀，希望能幫助到大家，謝謝大家對(duì)本站的支持！

最新評(píng)論