爲什麼不建議把數據庫部署在Docker容器內?

雲棲號資訊:【點擊查看更多行業資訊
在這裏您可以找到不同行業的第一手的上雲資訊,還在等什麼,快來!


前言

近兩年Docker非常的火熱,各位開發者恨不得把所有的應用、軟件都部署在Docker容器中,但是您確定也要把數據庫也部署的容器中嗎?

這個問題不是子虛烏有,因爲在網上能夠找到很多各種操作手冊和視頻教程,小編整理了一些數據庫不適合容器化的原因供大家參考,同時也希望大家在使用時能夠謹慎一點。

目前爲止將數據庫容器化是非常不合理的,但是容器化的優點相信各位開發者都嚐到了甜頭,希望隨着技術的發展能夠更加完美的解決方案出現。

Docker不適合部署數據庫的7大原因

1、數據安全問題

不要將數據儲存在容器中,這也是Docker官方容器使用技巧中的一條。容器隨時可以停止、或者刪除。當容器被rm掉,容器裏的數據將會丟失。爲了避免數據丟失,用戶可以使用數據卷掛載來存儲數據。但是容器的Volumes設計是圍繞Union FS鏡像層提供持久存儲,數據安全缺乏保證。如果容器突然崩潰,數據庫未正常關閉,可能會損壞數據。另外,容器裏共享數據卷組,對物理機硬件損傷也比較大。

即使你要把Docker數據放在主機來存儲,它依然不能保證不丟數據。Docker Volumes的設計圍繞Union FS鏡像層提供持久存儲,但它仍然缺乏保證。

使用當前的存儲驅動程序,Docker仍然存在不可靠的風險。如果容器崩潰並數據庫未正確關閉,則可能會損壞數據。

2、性能問題

大家都知道,MySQL屬於關係型數據庫,對IO要求較高。當一臺物理機跑多個時,IO就會累加,導致IO瓶頸,大大降低MySQL的讀寫性能。

在一次Docker應用的十大難點專場上,某國有銀行的一位架構師也曾提出過:“數據庫的性能瓶頸一般出現在IO上面,如果按Docker的思路,那麼多個Docker最終IO請求又會出現在存儲上面。現在互聯網的數據庫多是share nothing的架構,可能這也是不考慮遷移到Docker的一個因素吧”。

針對性能問題有些同學可能也有相對應的方案來解決:

  • 數據庫程序與數據分離,如果使用Docker跑MySQL,數據庫程序與數據需要進行分離,將數據存放到共享存儲,程序放到容器裏。如果容器有異常或MySQL服務異常,自動啓動一個全新的容器。另外,建議不要把數據存放到宿主機裏,宿主機和容器共享卷組,對宿主機損壞的影響比較大。
  • 跑輕量級或分佈式數據庫,Docker裏部署輕量級或分佈式數據庫,Docker本身就推薦服務掛掉,自動啓動新容器,而不是繼續重啓容器服務。
  • 合理佈局應用,對於IO要求比較高的應用或者服務,將數據庫部署在物理機或者KVM中比較合適。目前騰訊雲的TDSQL和阿里的Oceanbase都是直接部署在物理機器,而非Docker。

3、網絡問題

要理解Docker網絡,您必須對網絡虛擬化有深入的瞭解。也必須準備應付好意外情況。你可能需要在沒有支持或沒有額外工具的情況下,進行bug修復。

我們知道:數據庫需要專用的和持久的吞吐量,以實現更高的負載。我們還知道容器是虛擬機管理程序和主機虛擬機背後的一個隔離層。然而網絡對於數據庫複製是至關重要的,其中需要主從數據庫間24/7的穩定連接。未解決的Docker網絡問題在1.9版本依然沒有得到解決。

把這些問題放在一起,容器化使數據庫容器很難管理。我知道你是一個頂級的工程師,什麼問題都可以得到解決。但是,你需要花多少時間解決Docker網絡問題?將數據庫放在專用環境不會更好嗎?節省時間來專注於真正重要的業務目標。

4、狀態

在Docker中打包無狀態服務是很酷的,可以實現編排容器並解決單點故障問題。但是數據庫呢?將數據庫放在同一個環境中,它將會是有狀態的,並使系統故障的範圍更大。下次您的應用程序實例或應用程序崩潰,可能會影響數據庫。

知識點在Docker中水平伸縮只能用於無狀態計算服務,而不是數據庫。

Docker快速擴展的一個重要特徵就是無狀態,具有數據狀態的都不適合直接放在Docker裏面,如果Docker中安裝數據庫,存儲服務需要單獨提供。

5、資源隔離

資源隔離方面,Docker確實不如虛擬機KVM,Docker是利用Cgroup實現資源限制的,只能限制資源消耗的最大值,而不能隔絕其他程序佔用自己的資源。如果其他應用過渡佔用物理機資源,將會影響容器裏MySQL的讀寫效率。

需要的隔離級別越多,獲得的資源開銷就越多。相比專用環境而言,容易水平伸縮是Docker的一大優勢。然而在Docker中水平伸縮只能用於無狀態計算服務,數據庫並不適用。

我們沒有看到任何針對數據庫的隔離功能,那爲什麼我們應該把它放在容器中呢?

6、雲平臺的不適用性

大部分人通過共有云開始項目。雲簡化了虛擬機操作和替換的複雜性,因此不需要在夜間或週末沒有人工作時間來測試新的硬件環境。當我們可以迅速啓動一個實例的時候,爲什麼我們需要擔心這個實例運行的環境?

這就是爲什麼我們向雲提供商支付很多費用的原因。當我們爲實例放置數據庫容器時,上面說的這些便利性就不存在了。因爲數據不匹配,新實例不會與現有的實例兼容,如果要限制實例使用單機服務,應該讓DB使用非容器化環境,我們僅僅需要爲計算服務層保留彈性擴展的能力。

7、運行數據庫的環境需求

常看到DBMS容器和其他服務運行在同一主機上。然而這些服務對硬件要求是非常不同的。

數據庫(特別是關係型數據庫)對IO的要求較高。一般數據庫引擎爲了避免併發資源競爭而使用專用環境。如果將你的數據庫放在容器中,那麼將浪費你的項目的資源。因爲你需要爲該實例配置大量額外的資源。在公有云,當你需要34G內存時,你啓動的實例卻必須開64G內存。在實踐中,這些資源並未完全使用。

怎麼解決?您可以分層設計,並使用固定資源來啓動不同層次的多個實例。水平伸縮總是比垂直伸縮更好。

總結

針對上面問題是不是說數據庫一定不要部署在容器裏嗎?

答案是:並不是。

我們可以把數據丟失不敏感的業務(搜索、埋點)就可以數據化,利用數據庫分片來來增加實例數,從而增加吞吐量。

Docker適合跑輕量級或分佈式數據庫,當Docker服務掛掉,會自動啓動新容器,而不是繼續重啓容器服務。

數據庫利用中間件和容器化系統能夠自動伸縮、容災、切換、自帶多個節點,也是可以進行容器化的。

【雲棲號在線課堂】每天都有產品技術專家分享!
課程地址:https://yqh.aliyun.com/live

立即加入社羣,與專家面對面,及時瞭解課程最新動態!
【雲棲號在線課堂 社羣】https://c.tb.cn/F3.Z8gvnK

原文發佈時間:2020-07-07
本文作者:IT實戰聯盟
本文來自:“dockone”,瞭解相關信息可以關注“dockone”

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章