這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。
【編者的話】本文分享了唯品會資料庫Docker的異地容災項目實踐經驗，項目中針對使用者資料庫的異地恢複情境的需求進行開發與測試，整合了網路，儲存、調度、監控，鏡像等多個模組。在實施完成後，從技術上總結關於選型、開發、踩坑、測試等方面的經驗。
項目背景
資料庫Docker的異地備份恢複容災項目，針對使用者資料庫的異地備份恢複情境的需求進行開發與測試，整合了容器網路、儲存、調度、監控、鏡像等多個模組。同時針對資料庫的日常營運工作開發了監控、資源調度、日誌、Puppet自動推送等工具。
通過Docker天生隔離性和快速部署等特點，實現在單台物理機上運行多個Database Backup/恢複執行個體，大大提高伺服器使用率，節省大量成本。通過對Docker本身和相關組件的研究和改造，從普通開源產品落地到公司內部生產環境，積累寶貴的開發經驗。通過對Docker已經在其上層啟動並執行資料庫日常營運和監控，也積累寶貴的Docker營運經驗，為更大規模推廣容器提供基礎。
關於容器技術
通過實踐，證明容器技術在易用性，可管理性，快速部署具備天然的優勢。在資源使用率方面，容器部署在上百個物理節點上，提供約500多個資料庫災備執行個體，提升了硬體資源的利用率，節約了約400台物理機的採購成本。這些是容器技術帶來的實實在在收益。在資源分派與隔離方面，又不輸於虛擬機器。CPU、記憶體、磁碟IO、網路IO限流等技術的應用，保證了資源的合理使用，從機制上阻止了單一執行個體的資源過分消耗的問題。
穩定性是使用容器技術非常關注的一個點，也是基石。MySQL備份/恢複屬於CPU密集 + 磁碟IO密集 + 網路IO密集型業務，對於Docker daemon是個較大的考驗。就目前來看，限制每台宿主機的容器數量（5個左右）的情況下，叢集跑了三個多月沒有出現因為容器負載過大導致的crash現象，還是值得信賴的。遇到的唯一相關問題是Docker daemon掛死，具體現象是docker info、docker ps沒有響應，docker volume、docker images 正常，下面的容器運行正常。這是輕負荷事件，無法重現，以後需要繼續觀察。
由於容器以進程方式存在，體現出幾乎與物理機上相當的效能，Overheads極低（低於10%）。從資料幫浦任務的結果來看，與物理機相比，使用容器對成功率沒有影響，效率也差不多。這也很符合最初預想，不管跑容器還是外部服務從物理機角度來說它們之間是沒有什麼區別的，都是一個進程，唯一不同是父進程不一樣而已。
以上是容器“RUN”帶來的好處，通過統一開發流程，應用微服務化，CI/CD等方面的改進，能夠進一步利用容器“BUILD”、“SHIP” 優勢，容器技術還來的潛力是巨大的。要說容器技術的缺點，還真的不明顯。硬要提的話一個是需要一定的學習成本，改變開發流程與方式，一個是開發人員對容器技術的接受程度。這個項目僅用了不到二百人/天，對於一個採用新技術的項目來說，真的是很低的了。一開始我們也擔心因為採用新技術導致開發推廣有困難，後來實際能通過技術上解決問題，打消了大部分使用者對使用Docker的疑慮，反而有助於該技術的普遍應用。
關於Docker daemon版本的選擇，我們之前是有過一些討論的。現在Docker社區非常活躍，當時我們用1.10.3， 到現在已經出了兩個新版本了。在功能滿足的前提下，穩定性是第一考量。Docker自1.9.0引入CNM網路模型，1.10算是比較成熟。CNM是我們希望在這個項目嘗試的一部分。網路與Volume外掛程式功能與穩定性的提升，開始支援磁碟IO讀寫限速，Device Mapper的支援，等等，都是選擇了這個版本的原因。另外，Docker外掛程式的引入，很好地解耦了Docker與底層模組的關係，使我們可以專註於底層（網路、儲存）實現而不需要修改Docker daemon本身，同時避免產生升級依賴。
關於容器網路技術
容器網路基礎設施使用的是Contiv Netplugin，這是來自思科的開源方案。Netplugin以網路外掛程式的形式接入Docker daemon，網路功能作為容器生命週期的一部分被調用。Netpluign通過管理OVS，基於OVS VLAN作隔離，容器分配外網IP，可以直接存取，大大簡化了容器訪問的方式。考慮使用該方案的原因在於：1. 外掛程式形式不會對Docker產生升級依賴。2. Open vSwitch也是業界SDN的事實標準，希望籍此為容器帶來各種網路SDN的能力，例如限速，QoS存取控制。事實證明，只在容器建立與刪除過程中調用到Netplugin，運行中的容器所有流量只經過Open vSwitch，不依賴Netplugin，它即使掛了容器也能正常訪問，這個機制對網路的可靠性是好的一方面。OVS在之前一年半的OpenStack實踐中，已經證明是非常穩定的，OVS橋使用頻寬為1G的Uplink，與物理機相比只有不到5%的損耗。
Netplugin原方案是有流表的，每新增一個容器都會加一條flow，而且所有節點都添加，容器一多的話這個表的大小是不可想像的。我們把該功能去掉，以降低複雜度，提高穩定性。另外，引入了OVS rate-limit功能，把容器流控也做了，能夠根據情況即時的調整每個容器的可用頻寬。項目中Netplugin管理的IP位址集區有三個，很好地支援了500+容器的運行。
為了防止同一個二層廣播域容器增長，導致路由器arp表過快增長的的問題，在大規模部署中，需要在Netplugin增加ARP Proxy功能。
Netplugin很多優秀的功能例如VXLAN、多租戶、存取控制我們都沒有用到。雖然社區在不斷成長，但代碼還沒完全成熟。也遇到過一些bug，比如容器異常退出IP地址不能釋放的問題，這都需要我們自己去解決。我們的做法是基於某一版本，吃透代碼，只用準系統，經過充分測試，邊測邊改，逐漸擴大上線規模。
關於容器儲存
容器外部卷使用Convoy，以外掛程式的形式支援容器持久化資料。容器本身與外部卷均使用Device Mapper作為底層。沒有選擇分布式儲存原因，主要是為了簡化實現，更穩定。通過限制每個容器的BlkioDeviceReadBps、BlkioDeviceWriteBps、BlkioDeviceReadIOps、BlkioDeviceWriteIOps，使磁碟IO穩定地達到相當於95%物理機效能。
對於Device Mapper，因為是紅帽推薦的，而OS又是用的CentOS7.2, 所以就用了它。測試過程中發現Device Mapper健壯性不是很好，僅僅在低並發下，也會出現容器刪除失敗的情況，容器並發啟停偶爾出現找不到裝置的情況。這種使用映射關係的裝置，功能是豐富，實現上過於複雜，每次對裝置的修改都需要額外去更新Metadata，並發情境出錯的機會就大了。讓我再選的話我會考慮Overlay這種更簡單的driver。
對於Convoy，是來自Rancher的產品，Go語言，仍然處於未成熟階段，版本號碼0.5, 並沒有完全實現Volume Plugin介面。相比其它模組它的問題也是最多的，例如Volume建立失敗，無法刪除，UNIX Socket泄漏，重名衝突，異常自動結束等。屬於能用，但未完善的狀態，你自己得有一定開發調試能力去解決發現的問題。其它幾個儲存外掛程式情況也差不多，Flocker、Blockbridge、Horcrux等等，有的連第一個正式發布版都還沒有，Convoy反而相對好點，有點爛柿子堆裡挑的感覺。
對於Docker本身的Volume Plugin介面，我們也遇到一些坑。下面是其中一些：
- Docker Volume Plugin不支援擷取Volume使用狀態資料
- Docker Volume Plugin存在file descriptor leaks bug ——https://github.com/docker/docker/pull/20686
- Swarm定期list會偶然觸發Docker volume cache bug - https://github.com/docker/docker/issues/21403
關於容器監控
容器監控在這個項目裡還可以有很大的空間可以改進。項目裡用的是cAdvisor，容器內top、free、iostat命令劫持，基於已有的Zabbix體系作資料收集與展示。結論是Zabbix完全不合適做容器監控，資料收集密度，展示品質，靈活度都沒能滿足需求。
後來在測試中嘗試使用Telegraf + InfluxDB + Grafana。 只需要Grafana簡單的配置，能夠幫忙我們清晰地展示容器及服務進程CPU、記憶體、網路、磁碟等情況。Grafana上SQL查詢語句的調試與開發，確實需要不少的時間，但這個工作量是一次性的。因為是Go寫的，Telegraf CPU佔用屬於比較低的水平（0.4 - 5%）。功能上比較豐富，同時支援外部進程與容器的資料收集，多達55種資料來源外掛程式，有它就不需要布cAdvisor了，個人比較推薦。需要警示的同學，可以考慮把influxDB改成Prometheus。它包含Alertmanager實現Email、PagerDuty等訊息通知。資料Backend可以選擇內建的DB，也可以外接influxDB、Graphite、OpenTSDB等流行方案。
監控領域業界已經有很多開源方案可以參考，以下是要衡量的標準：易擴充、開銷低、入侵小、大集中、易部署、即時性、展現清晰靈活。這方面希望與各位有更多的交流。
Q&A
Q：發現現在很多採用橋接橋接器的方式改善Docker網路 ，這個可有測試？
A：橋接橋接器的方式是個簡單的方案，但IP地址分配只能在本機做IPAM，無法全域管理，存在地址資源浪費的問題。
Q：請問改體系在實戰中研發環境，測試環境和預發布環境的交付物是什麼呢？
A：MySQL資料的備份恢複能力。
Q：“容器異常退出IP地址不能釋放的問題，這都需要我們自己去解決。”可否提供一個大致的解決思路？
A：計劃通過libnetwork unix socket調一個叫ReleaseEndpoint的API，這樣可以保證刪除操作的完整性，包括ovs port、etcd ep資訊、IP地址。
Q：Docker 1.12內建Docker swarm mode，Overlay網路的效能相比其他開源方案的優劣勢是什嗎？
A：Overlay網路的優勢在於對虛擬網路，多租戶情境支援更好，沒有4096個的限制， 然而沒有支援VXLAN硬體的情況下無法直接存取，這對於開發，問題定位，監控都是個難題。效能的話對於容器來說不會是一個瓶頸。
Q：做過Mesos 1.0測試嗎？1.0已經不會依賴Docker daemon了？
A：Mesos 1.0中仍然支援Docker作為Containerizer。實驗環境驗證過Mesos + Docker + Netplugin是可行的，理論上無論用哪個Mesos版本，只要它仍然支援Docker，那麼就可以網路外掛程式的形式來落地網路實現。
Q：容器一般是即用即銷毀，想問下，你們做的容器監控，是如何保證資料持久性的？
A：MySQL備份出來的資料是儲存在容器外部卷上，即宿主機上的，容器銷毀外部卷並不會被刪除，所以資料仍然能夠保留下來。
Q：請問你們的容器警示是基於什麼做的，cAdvisor並不能提供警示吧？
A：基於我司已有的監控體系，即Zabbix。
Q：Devicemapper使用的是Direct LVM嗎？裝置空間用滿的情況下如何擴容？
A：是的。擴容可以通過添加物理磁碟裝置，擴VG，再resize dm pool大小。
Q：當您用到上百台機器的時候，鏡像是提前下載好的嗎？還是臨時下載，有沒有做鏡像下載加速這塊兒？
A：鏡像是儲存在本地IDC的Registry裡，所有機器訪問Registry通過相近的網路，下載速度很快。好的做法是先全域Pull一次再Run吧。
Q：我對容器中放資料庫的效能比較擔心，你們的效能這麼高，主要做了什麼配置？
A: 因為害怕互相搶資源，我們嚴格限制單一主機的容器數量、CPU、記憶體、磁碟都不超配。在資源充足的情況下，MySQL跑在容器裡跟跑在外面沒有本質的區別，都是進程。
Q：關於監控這塊，上文提到了兩個，能給我們介紹一下Zabbix和cAdvisor的分工嗎？
A：Zabbix通過自己寫的指令碼，向cAdvisor RESTful介面請求容器監控資料。
Q：MySQL資料庫容器化後，效能如何？故障恢複速度怎麼樣？
A：從資料備份恢複的角度來說，基本與在物理機上跑相當。
以上內容根據2016年9月6日晚群分享內容整理。分享
葉凱峰，唯品會雲平台資深開發工程師。十年IT行業工作經驗，開發老司機，成長在愛立信，測試界與開發界都打拚過。技術實現崇尚”Simple is the best”，“不以解決問題為目的的技術引進就是耍流氓”。現在專註OpenStack、Docker等雲端運算相關技術的設計與開發工作，負責Docker整體技術方案設計、容器網路、監控、日誌、作業系統等方面，為公司雲端運算技術基礎設施演化提供支援。。 DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加：
liyingjiesz，進群參與，您有想聽的話題或者想分享的話題都可以給我們留言。
