唯品會數據庫備份恢復容器化項目實踐經驗總結

項目背景

數據庫Docker的異地備份恢復容災項目，針對用戶數據庫的異地備份恢復場景的需求進行開發和測試，整合了容器網絡、存儲、調度、監控、鏡像等多個模塊。同時針對數據庫的日常運維工作開發了監控、資源調度、日志、Puppet自動推送等工具。

通過docker天生隔離性和快速部署等特點，實現在單臺物理機上運行多個數據庫備份/恢復實例，大大提高服務器使用率，節省大量成本。通過對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 正常，下面的容器運行正常。這是偶發事件，無法重現，以后需要繼續觀察。

由于容器以進程方式存在，體現出幾乎與物理機上相當的性能，overhead 極低（低于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, 這是來自思科的開源方案。neplugin以網絡插件的形式接入docker daemon, 網絡功能作為容器生命周期的一部分被調用。Netpluign 通過管理OVS, 基于OVS VLAN作隔離，容器分配外網IP, 可以直接訪問, 大大簡化了容器訪問的方式。考慮使用該方案的原因在于：1. 插件形式不會對docker產生升級依賴。2. openvswitch也是業界SDN的事實標準，希望籍此為容器帶來各種網絡SDN的能力，例如 限速，QoS訪問控制。事實證明，只在容器創建與刪除過程中調用到netplugin, 運行中的容器所有流量只經過openvswitch, 不依賴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健壯性不是很好，僅僅在低并發下，也會出現容器刪除失敗的情況，容器并發啟停偶爾出現找不到設備的情況。這種使用映射關系的設備，功能是豐富，實現上過于復雜，每次對設備的修改都需要額外去更新meta data, 并發場景出錯的機會就大了。讓我再選的話我會考慮overlay這種更簡單的driver。

對于convoy, 是來自rancher的產品，go語言，仍然處于未成熟階段，版本號0.5, 并沒有完全實現volume pluign接口。相比其它模塊它的問題也是最多的，例如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。 只需要telegraf簡單的配置，能夠幫忙我們清晰地展示容器及服務進程cpu, 內存，網絡，磁盤等情況。grafana上sql查詢語句的調試與開發，確實需要不少的時間，但這個工作量是一次性的。因為是go寫的，telegraf cpu占用屬于比較低的水平（0.4 - 5%）。功能上比較豐富，同時支持外部進程與容器的數據收集，多達55種數據源插件，有它就不需要布cadvisor了，個人比較推薦。需要告警的同學，可以考慮把influxDB改成Prometheus。它包含Alertmanager實現email, pagerduty等消息通知。數據backend可以選擇自帶的DB, 也可以外接influxDB, graphite, opentsdb等流行方案。

監控領域業界已經有很多開源方案可以參考，以下是要衡量的標準：易擴展，開銷低，入侵小，大集中，易部署，實時性，展現清晰靈活。這方面希望與各位有更多的交流。

 

來自：http://mp.weixin.qq.com/s?__biz=MzA5OTAyNzQ2OA==&mid=2649691631&idx=1&sn=bf5dd31a94312b0e9c1049a851f630ad&chksm=88932a8cbfe4a39afe58a6696bb8dba360c6f45880833e2de9eb8f804f87713d70c5f4b40343&scene=1&srcid=0913i2R0eH4TcibAIHuqJaYz#rd