855
京東網上商城
京東MySQL數據庫Docker化最佳實踐（附PPT）
講師介紹
劉風才
京東資深數據庫專家
-
2012年加入京東，擔任MySQL DBA一職，負責數據庫架構設計、數據庫性能優化等日常運維工作，參與過分布式數據庫項目、多中心交易項目等。
-
2013~2016連續4年作為MySQL數據庫618、11.11項目DBA負責人，負責相應備戰工作，為大促平穩護航。
演講大綱：
-
京東Docker技術發展曆程
-
MySQL數據庫為何要Docker化
-
MySQL數據庫Docker化前準備工作
-
遇到的問題與解決方案
-
總結與展望
京東MySQL數據庫Docker化的推進之路，從開始如履薄冰的使用，到目前占比超過70%以上的大規模部署，下麵給大家一一講解這期間的發展曆程。
一、京東Docker技術發展曆程
Docker技術的發展為MySQL數據庫部署環境能夠容器化奠定了基礎。京東Docker技術的發展可以歸納為3個階段：
1、初出茅廬
京東從2013年開始規劃虛擬化平台項目。可以說，一切從零開始，組建團隊，架構采用當時主流的OpenStack+KVM架構，在發展初期，隻有一些非核心的應用服務開始跑在kvm上。虛擬化研發團隊在技術上很快掌握了OpenStack核心代碼，當時來說，OpenStack對VM支持可以說是天生的好，在各方麵認為成熟的時期，虛擬化團隊滿懷信心地接入了一個核心業務，不幸的是，正是這個核心業務給虛擬化團隊帶來了不小的打擊，在性能上tp99無法縮短到40ms以內，無法滿足應用服務的性能要求，在2013年夏天-2014年夏天研發嚐試了各種方法，進行改造優化，最終仍無法達到物理機的性能水平。這一年對於虛擬研發團隊來說是壓抑、苦悶，也是積攢經驗的一年。
2、小試牛刀
2014年9月，公司安排首席架構師劉海峰帶領虛擬化團隊。他提出一套新的方案、新的思路，Docker由此進入京東。2014年6月 Docker1.0發布，當時Docker還非常單薄，隻有鏡像和對cgroup簡單的操作功能是可用之處，由於虛擬化研發團隊在過去一年的壓抑，這一新的思路對於團隊來說無疑是希望，經過簡單的二次開發後，進行了基本性能測試，驚喜地發現TP99可以部分降低到40ms以內，雖不完美，但對於團隊來說，這已經看到了曙光。
經過研發團隊的不謝努力，性能問題終於完全解決了。但另一個問題接踵而來，如何管理眾多的Docker容器？自己開發時間成本太大，基於團隊過去一年裏在Openstack方麵經驗的積累，團隊最終選擇OpenStack + Docker的架構，並命名為京東第一代容器引擎平台JDOS1.0(JD DataCenter OS)。
3、駕輕就熟
解決了性能問題、批量管理的問題後，京東第一代容器引擎平台推廣速度極快，從15年起步到 16年618已完成100%應用業務環境容器化，並經受住了618大促的考驗。到目前為止，京東Docker部署已近15萬個左右，可以說是規模最大的Docker集群。
二、MySQL數據庫為何要Docker化
先談一下京東MySQL數據庫發展的曆程。京東從2011年開始使用 MySQL數據庫，在此之前以SQL Server為主。2012年以後，MySQL數據庫迅速在京東崛起，爆炸式增長，到2013年 MySQL數據庫就占了京東交易係統的一半，發展到2014年、2015年，MySQL已經成為京東主流的數據庫。並且數據庫服務器規模不斷增大。下麵看看選擇Docker化會帶來哪些收益呢？
1、快速部署
數據庫服務器實例創建隻需要1分鍾，和物理機os安裝相比，速度提升了幾十倍。
2、動態擴容
空間問題對於DBA來說，可以說是比較常見的問題。隨著業務的發展，磁盤使用超出了預先的評估，使用Docker在一定條件下可以在線擴容，方便快捷。但這並不是解決空間問題的最佳方案，數據可能不斷增長，但磁盤空間不可能無限擴容；基於性能、長遠考慮，建議進行數據結轉、數據清理或者庫表拆分等操作。
3、提升資源利用率
隨著SSD硬盤成本的降低，SSD服務器使用越來越普遍，IO性能也有了很大提高，對於數據量小的數據庫係統單獨部署在物理機，在成本上考慮存在著浪費，但如果采用多庫合用或多實例部署，這雖然可以提升了資源利用率，但無法避免物理資源競爭、相互影響問題，而Docker在物理資源上良好的隔離性，恰恰可以解決這一難點。
也許有人會問Docker和虛擬機的區別？其實這兩者是有本質區別的。虛擬機的本質上是模擬。通過模擬物理機上的硬件，向用戶提供資源。容器的基石是經過隔離與限製的linux進程。容器提供的是性能損失更小的原生物理機的計算能力，容器之間唯一共享的是linux內核。
4、降低成本
資源利用率提高了，節約了服務器資源、機架位資源，提升經濟效益，降低了成本。
5、成熟的Docker技術
最重要的一點，京東在Docker技術上的逐步成熟，應用部署環境100%容器化，有了豐富的經驗，有專業的團隊的技術支持，並經曆618、雙11大促的考驗。
三、MySQL數據庫Docker化前準備工作
1、Docker管理頁麵的開發
實現Docker申請創建、暫停、開啟、在線擴容等功能，方便DBA日常操作。
2、製定Docker容器分配算法
數據庫高可用是不容忽視的。在Docker容器分配時如何保障主從不在同一宿主機上呢？
下麵介紹一下分配算法原理：如果一個集群申請的數據庫服務器大於1，調度時會為每一個容器選擇合適的宿主機，主要是根據宿主機的狀態（是否正常可用）、宿主機上的可用資源（cpu、內存、磁盤容量）是否滿足申請的容器規格，將集群中所有的服務器都篩選完後，會計算服務器的權值，從中選擇最適合的服務器作為宿主機，然後在內存中記錄下這個宿主機，下一個容器選擇宿主機時，會在篩選服務器的過程中加上一個判斷，如果這個服務器已經被選中過作為宿主機，則過濾掉這個服務器。
3、Docker模板的製定、調度算法優化
提升磁盤IO性能。靈活的調度算法，如某係統對IO性能要求高，在Docker容器創建時，根據傳入的參數，調度算法會在篩選合適的宿主機時，根據宿主機負載情況，選擇壓力最小的作為宿主機。
4、Docker 管理平台與數據庫管理平台結合
實現Docker容器批量申請、下線等一鍵化操作。實現Docker日常運維查詢工作，例如：根據宿主機IP查詢該宿主機下所有Docker信息，根據Docker IP查詢該宿主機及其下所有Docker信息等功能。
5、監控項調整
監控對運維來說是重中之重，京東MySQL 數據庫監控采用的是Zabbix監控。在監控負載值獲取上Docker與物理機是有區別的。在Docker上我們無法通過os係統命令抓取係統負載情況，目前京東的實現方式：在宿主機上通過專門開發監控程序，把計算結果實時存儲到Redis中，Zabbix從Redis中讀取對應監控值。
四、遇到的問題與解決方案
隨著Docker集群規模越來越大，在推廣中也經曆了些痛點，下麵我們來扒一扒踩過的坑，以及是如何解決的：
1、OpenStack集群規模受限。OpenStack遇到集群規模的問題，發生嚴重的信息不可靠問題；如：創建容器消息在MQ傳輸過程丟失，容器狀態掛起，DB連接數過大，計算節點各種agent定時任務hang住，部署升級無法核對升級結果。
解決方案：由於社區暫時沒有遇到這麼大規模，沒有任何現成的解決方案，研發團隊隻能自己動手創造。設計目標為單個集群1萬台物理節點，開發了一個python版本的RPC（brood）框架，解除對MQ依賴。特別是依賴MQ操作DB的部分，全部改為使用京東自研的Python版本RPC框架，對數據庫的全部操作均使用RPC自帶支持的京東JIMDB（內存緩存集群）進行處理。成功解決了集群規模受限的問題。
2、性能、穩定性問題。規模壯大之後，遇到很多低概率但是實實在在發生了性能和穩定性問題，mac表滿導致無法網絡通信，UDP大報文硬塞，丟包，中斷異常，係統slab集中回收性內存申請鎖住時間過長。
解決方案：發現問題的根源在於Linux kernel，意識到做容器就是做Linux kernel，即刻組建了Linux Kernel 團隊，修改內核代碼，最終解決並維護了京東自己的Linux Kernel分支。
3、Zabbix監控agent不自動重啟，加到rc.local裏的任務不生效，雖不是難點，但往往容易忽視。
4、磁盤IO隔離性不太好，一台Docker磁盤繁忙程度比較高，會影響該宿主機上其他Docker 性能。避免性能要求敏感的係統與磁盤IO使用較高的在同一宿主機上。
5、Zabbix監控負載取值問題，Docker與物理機有區別，上麵提及過，避免取值錯誤。
五、總結與展望
目前生產環境中70%的MySQL數據庫都運行在Docker容器上。已順利支撐了兩個618、一個雙11大促，經住了大流量的考驗。京東Docker部署已近15萬個，成為全世界規模最大的Docker集群。
Q&A
Q1：MySQL Docker使用的標準？
A1：將MySQL數據庫部署環境Docker化，首先是技術成熟，並且有了一定經驗。我們是從非核心重要程度低的開始，逐步接入。目前已經有超過70%的係統都部署到Docker上了。
但是對於一些空間上要求比較大的係統，由於業務發展的需求，數據庫不可能拆得特別大，數據文件多於1T多的情況下是不太合適部署在Docker上的；再有就是在性能上要求特別高的，特別重要的核心係統目前仍跑在物理機上，後麵隨著Docker技術不斷的改進，會陸續地遷到Docker上。
Q2：我是一個獨立核算的部門，公司有其他產品要到Docker上跑，怎麼衡量它應用的成本，按部門進行核算，需要考慮哪些因素？
A2：對於數據庫來說，主要是CPU核數、內存、硬盤這三項。因為每個Docker配置不一樣，數據庫這邊有8C、12G、500G，12C、24G、500G，12C、48G，1000G和16C、48G、1000G等類似模板，分別對應CPU核數、內存、硬盤。
Q3：剛才您遇到了兩個問題裏麵，一個是IO在用的問題，我想部署Docker時，能不能指定Docker隻能占用多少IO這種呢？
A3：內存CPU這個是Docker上通過宿主機可以嚴格進行控製隔離，IO其實是底層共用一塊資源，在隔離性上不好，其實在Docker創建時，是指定了IO的使用情況，但還會存在互相影響和幹擾的情況。
Q4：有可能其中一台會引起整個宿主機使用的情況，可能會產生這種幹擾。您之前說那個模板，如果定好了500G，如果發現之前的不夠用，這個時候可以對之前的模板進行更改嗎？如果可以，是批量還是？
A4：這個是完全可以的，並且不影響應用的正常運行，但是有一定的條件，就是當前宿主機上有足夠的剩餘資源。比如當前是16C、32G、500G配置的Docker，打算升級成16核、32G、1T配置的的docker,需要保證當前宿主機上需要有大於500G的空閑硬盤。
對於擴容來說，目前是通過web觸發來進行擴容操作的，完全滿足當前的工作場景；對於批量來說，目前沒有實現。主要是由於前期已經進行了容量劃不會產生大批量的擴容情況。
Q5：數據量比較大，表增長肯定也會增大的，後期數據的歸檔問題怎麼做？
A5：這個問題，普通物理機也有遇到。一般分兩種情況：一個是業務上需要繼續訪問的，一般是通過程序，將曆史數據歸檔道一個曆史集群中，這樣保證業務上也可以繼續訪問；另外一種是業務上曆史過期數據，業務上不需要訪問的，可以放到HBase或者Hadoop裏，根據具體業務而定。
Q6：我想了解一下Docker在MySQL備份怎麼管理的？
A6：在Docker和物理機使用上沒有太多區別。主要是通過dump或者xtrabback備份到本地，同時上傳到存儲中，並且定期的刻盤保存。
Q7：我想問一下你們做OLAP這一塊，因為MySQL是不適合數據分析大查詢這種東西的。我們公司也考慮把數據轉到MySQL上，這還需要在線分析嗎？我想問一下你們怎麼做的？
A7：如果數據量比較小，也是可以考慮MySQL的，單獨的從庫做統計的查詢，也可以考慮MySQL；另外，在選型的時候一定要根據實際考慮最適合的方案，不一定非要使用MySQL。
如果數據量達到一定規模的話，就需要單獨的大數據團隊來搞了。現在我們那邊除DBA團隊外之外，還有一個大數據部門，他們會定期地從MySQL抽取數據，兩種模式，一種是實時，一種是離線，每天會把數據拉到大數據那邊進行處理。
Q8：你們前麵做一個中間件嗎？
A8：有些係統采用了中間件，但有些係統分庫分表是在應用端實現的，主要是這兩種情況。
Q9：剛才你說Docker模板後續會不會考慮自動擴容？
A9：由於我們采用的是非共享存儲模式，因此我們的自動擴容是有一定限度的，主要是受限於宿主機剩餘的資源。在線擴容這塊，目前我們已經做到了，但是是需要人工介入的觸發，完全自動的擴容，暫時還沒有考慮。
Q10：有一種方式就是數據卷容器的掛載。
A10：這個是有一定的適用場景，但對於數據庫來說，並不適用，一般統一宿主機上的Docker不需要共享數據。
原文發布時間為：2017-03-16
本文來自雲棲社區合作夥伴DBAplus
最後更新：2017-05-16 10:32:32