<form id="tznrh"><form id="tznrh"><th id="tznrh"></th></form></form>

            容器數據庫|容器化數據庫必經之道

            發布時間:2020-04-08 | 信息來源: | 發布作者:




            作為DBA運維人員


            數據庫真的可以運行在容器里面嗎?


            容器本身會不會存在安全隱患?


            會不會丟失數據?


            那就是丟了飯碗了?。。?!



            但是公司業務發展的速度實在太快,來了一個廠商或者應用就要求我們上線一個RDS實例,并且要求實例具備高可用、可擴展能力,隨時上線或者下線,領導又要求提高物理硬件資源利用率。業務部門整天催著我們快速提供數據庫服務,數據庫實例多了后,運維難度和復雜度直線上升。公司IT發展戰略朝著微服務和互聯網化全面改造,DevOps建設又旨在打通運維和開發部門壁壘,作為DBA運維人員該如何適應這種轉型?


            傳統DBA運維管理方式無法滿足當前需求


            筆者同是MySQL 運維DBA過來人,目前在乙方公司轉型做RDS相關產品工作。同甲方DBA運維或開發部門打交道過程中,非常能夠感同身受在當前云計算、容器化、微服務等大浪中,DBA運維人員的痛點和難點。


            通常DBA運維人員,研發能力比較弱,沒有工程化項目經驗。當然自動化運維、shell或者python腳本輔助工具等,對于小規模的RDS集群(10~20)的運維管理已經夠用。但是隨著公司規模的擴大應用場景的豐富,企業通常不會只有一種數據庫實例,可能并存著MySQL、Oracle、SQL Server、 PostgreSQL等。


            那么企業用人方要求DBA掌握多種數據庫的特性能力,或者招聘每種DBA從業人員。其實關系型數據庫在橫向使用場景上存在共性如:高可用、RDS集群規??蓴U展、計算/存儲可變更、備份恢復、監控告警等等。


            不要讓RDS服務質量成了最后的短板


            研發和運維之間確實存在壁壘,我們經??吹窖邪l人員發布軟件應用上線后,需要由運維人員提供硬件和網絡環境進行部署,通常運維人員并不關心你軟件運行的“好壞”或者“快慢”,只關心物理服務和網絡等監控指標。


            DBA運維人員除了需要關心這些指標外,還需要關心數據庫軟件本身的“好壞”和“快慢”。比如應用的表是否創建了合理的索引、物理機存儲空間大小、SQL語句是否非法如使用了select * From table1、table2...等導致存儲介質的IO被打滿等等。當企業開始微服務和DevOps建設后,對服務敏捷和快速交付能力提出了要求。而關系型數據庫又是一類比較特別的應用場景,一些大規模的企業更是專門設置了DBA部門來負責數據庫實例的運維和開發工作。隨著企業業務對產品研發速度和快速適應市場的要求,數據庫實例交付速度和能力逐漸成為瓶頸。


            容器化是必經之道


            研發人員為什么喜歡容器數據庫?因為容器數據庫技術打包了程序所需運行時的上下文并且擁有優秀的跨平臺能力,通過定義簡單的流程,可以協助企業開發和運維人員快速發布和部署應用。當然也有部分DBA運維人員對容器數據庫不感冒,我認為是沒有合適的場景。上文提到DBA運維人員可以通過自動化運維、shell或者python腳本輔助工具等,對于小規模的RDS集群(10~20)的運維管理已經足夠。


            那么什么場景是合適容器數據庫呢?筆者接觸到的客戶場景,通常是企業開始建設自己的DevOps需要快速交付RDS服務或是企業DBA人員 VS 負責數據庫實例數量達到1:50+以上的規模比例。


            淺談容器數據庫價值


            所謂容器數據庫只不過是一個普通進程,這個進程的特殊之處在于:1)它可能是位于不同命名空間(ns)的,使用clone/unshare/setns系統調用將容器進程加入不同的命名空間 2)它對資源的使用(cpu,memory,diskio等)可能受到CGroup資源控制的限制。


            通過使用容器graphdriver的特性,DBA在單機運行多個實例的場景下,同樣版本的數據庫實例本身需要運行的庫文件共享了base image,大大節省了物理機器的存儲空間。





            容器數據庫的“安全”問題


            DBA最關心的基礎問題是數據完整性和安全性,上文提到容器只不過是普通的一個進程,利用了Linux kernel的特性“偽裝”成一個虛擬的OS運行環境,graphdriver通過CoW機制,解決鏡像文件共享問題。


            運行關系型容器數據庫,我們需要通過另外的“接口”,不通過graphdriver來持久化數據。容器數據庫本身提供持久化數據的能力。例如:運行容器化MySQL實例,將OS的目錄/opt掛載到容器的/var/lib/mysql目錄,容器內MySQL實例所產生的數據都寫到宿主機的/opt目錄下。


            docker run --name mysql -v /opt:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=somepassword -d mysql/mysql-server:5.7


            我們通過docker inspect docker-id命令,查看該容器數據庫的運行spec信息。截取部分關鍵信息。


            "Mounts": [ { "Type": "volume", "Name": "b13109e14d1fd5c2d9957689a2d509b90ca8eafd4080a92de636eeb97090c0fd", "Source":"/var/lib/docker/volumes/b13109e14d1fd5c2d9957689a2d509b90ca8eafd4080a92de636eeb97090c0fd/_data", "Destination": "/var/lib/mysql",


            我們看到,docker通過type為volume的方式,映射OS目錄到容器內進行綁定,我們完全可以通過OS的文件系統如ext4和XFS,或者利用分布式存儲的卷來保證容器數據庫的數據安全。

            kubernetes是容器數據庫集群最佳實踐


            以上非常粗淺的談到運維DBA通常對容器數據庫的質疑,當然如果要大規模部署容器數據庫集群,離不開好的架構設計。


            "kubernetes is eating the Container world"這句話一點都不夸張,云原生,微服務,PaaS,IoT,DevOps等等,以容器為技術棧的架構幾乎都將k8s做為首選。筆者所負責的產品,同樣將k8s作為容器數據庫編排的框架提供多類RDS服務,目前單集群最大支持RDS規模達到1000+。kubernets架構可以讓企業通過擴展自定義的資源類型來部署容器化數據庫,當然還需要根據自身的業務場景來解決容器數據庫的數據持久化問題,容器數據庫的編排調度策略,網絡方案及服務暴露方式等等。


            當企業將k8s作為IT架構將數據庫容器化后,給運維DBA帶來的收益將是完全匹配業務快速發展的需要以及對RDS服務質量的要求,但同時也對運維DBA帶來了全新的挑戰,運維DBA需要充分理解k8s架構設計體系,能夠通過k8s自帶的Cli組件或者自定義yaml來管理資源任務。




            沃趣科技,讓客戶用上更好的數據庫技術!
            三分快3