Cloud 團隊：讓 TiDB 在雲上跳舞 | PingCAP 招聘季

時間 2019-12-04

原文原文鏈接

TiDB 是 Cloud Native 的數據庫，對於 TiDB 來講，如何用 Cloud 的思想和技術讓 TiDB 在雲上跳舞，是 Cloud 團隊研究的重要課題，本期我司商業產品副總裁劉寅老師將爲你們介紹 Cloud 團隊，Enjoy~ios

TiDB 與 Cloud

經過前面的招聘職位解讀系列文章，相信你們對開發 TiDB 的挑戰有了更深刻理解。水平彈性伸縮是 TiDB 最酷的特性之一，不一樣於傳統的單機數據庫，TiDB 管理的每每是成百上千的分佈式存儲節點、計算節點以及監控、日誌相關組件，這對於 TiDB 的使用來講是很是大的挑戰。所以，咱們在開發 TiDB 之初，就將其定義爲 Cloud Native 的數據庫。咱們意識到須要用 Cloud 的思想和技術，讓 TiDB 用起來更加簡單，開發者和用戶纔可以輕鬆「玩轉」 TiDB。git

Cloud Engineering Team

在 PingCAP 咱們有一支專門的團隊在作和 Cloud 相關的事情。這裏的 Cloud 是一個比較泛泛的概念，它既包括公有云，也包含私有部署，凡是關於「如何以集羣化和集中式來管理大規模的 TiDB 實例」的問題都是這個團隊須要關心的事情。看到這裏小夥伴們可能已經想到了容器和 Kubernetes。是的，容器是在 Cloud 上部署和管理的最佳實踐，Cloud Team 的一個主要職責就是把 TiDB 容器化，並結合 TiDB 自身的特性實現集羣自動化管理，包括並不限於：github

一鍵部署集羣數據庫
彈性擴縮容安全
數據庫滾動升級網絡
故障自治癒架構

上面幾個 features 你可能看了並無什麼感受，我展開說一下。運維

首先，一鍵部署不只要支持像 AWS，GCP，Azure 這樣全球頂級雲供應商，也要支持國內 Aliyun 等主流的公有云。用戶根據自身業務選擇雲提供商和可用區，甚至可能提出跨雲的需求。國內的環境下，不少企業選擇混合雲的建設方式，所以也會提出 TiDB 要在私有數據中心部署，那麼在數據庫的一鍵部署以前咱們要先搞定 Kubernetes 集羣的一鍵部署。此外，咱們還要考慮不少方面的問題，好比：如何跨可用區高可用，高性能本地盤支持，如何最大化資源利用率，統一監控等等。傳統的基於 Ansible 管理的 TiDB 集羣即便是熟手也須要 10-20 分鐘，而在雲上建立一個 TiDB 集羣多是秒級完成。分佈式

當應對計劃內的業務增加，好比像雙 11 這樣特殊時間段，用戶但願只提出需求，好比：所需的存儲容量、QPS / TPS，剩下的交給程序自動完成 TiDB 的擴容。當業務高峯事後，還能夠經過縮容把資源釋放出來。分佈式數據庫是有狀態的，特別是 TiKV 須要本地盤的支持，那麼有狀態服務的擴縮容須要尤爲謹慎地管理 local volume 的生命週期，以及處理好服務間的依賴關係等。藉助公有云提供的 Auto Scaling 能力，按需建立節點，只有在雲上才能作到真正的彈性伸縮。ide

TiDB 的版本迭代速度還很快，線上升級是常態。用戶固然指望有計劃升級的 RTO/RPO 皆爲零，在雲上對 TiDB 升級必須把對用戶的影響降到最小。這就須要在升級期間配合 TiDB 的 graceful shutdown 和 evict-leader-scheduler 機制，對節點依次進行升級。保證把對上層業務的影響降到最低，同時儘量縮短升級的時間。

TiDB 利用 Raft 協議保證多副本之間的強一致，能夠容忍單個節點，甚至單個可用區掛掉的狀況下，不影響提供服務。在傳統的運維方式下，一旦發生單點故障雖然不用馬上響應，但後繼的節點恢復仍需人工介入，並根據實際狀況來判斷恢復副本的策略。另外，如需作跨區高可用部署也須要運維人員對 TiDB 原理有充分的理解，而基於 Cloud 這些理所應當是自動來完成。

Cloud Team 在作的事情

以上只是這個團隊所解決領域中的一部分問題，接下來看看咱們具體作的事情。

Kubernetes

Kubernetes（k8s）幾乎已是容器編排領域的事實標準，它更像一個集羣上的操做系統。TiDB 的容器化依託於 k8s 強大的調度和資源管理能力也就成了很天然的事情。能夠認爲不管是公有云仍是私有部署，只要基於標準的 k8s 就能夠把 TiDB run 起來。

Cloud Team 必須充分的瞭解 k8s，不只包括 k8s 的使用和運維，還要深刻到源碼理解其內部細節、幫忙貢獻代碼。k8s 自己是 GitHub 活躍度排名前幾的項目，擁有龐大的社區和生態。咱們積極的深度參與社區，由於解決有狀態服務的調度是一個共性問題，咱們既能夠從社區找到更先進的思想和方法，也會把咱們的成果回饋給社區。

K8s 最初是用於無狀態應用部署管理的，因此長期以來一直只支持網絡持久化存儲，StatefulSet 設計之初也是以網絡存儲爲基礎，其對 Pod 處理的順序保證在最近幾個版本增長的 Local PV 已經顯得有些捉襟見肘，一臺機器掛掉後，對應 Pod 的 Local PV 數據可能就沒法恢復，不像網絡 PV 數據還在，能夠直接從故障機器轉移掛載到其它健康節點。如何對使用 Local PV 的有狀態應用進行恢復，單純靠 StatefulSet 是沒法作到的。

K8s 雖然已經支持本地持久化存儲 Local PV，但對於本地盤的管理還比較初級，要作到磁盤 IOPS 隔離，只能經過一個 PV 一塊物理磁盤方式實現，無法動態分配，資源浪費比較嚴重，若是使用 bind mount 共享磁盤，則沒法支持容量和 IOPS 隔離。而隔離性幾乎是企業級必須具有的功能，如何解決這些問題須要咱們與 k8s 社區一塊兒共同探討。

磁盤設備若是支持 IOPS 隔離，那 storage 自己除了容量大小以外又增長了 IOPS 這一屬性，再加上本地磁盤自己不可移動特性，其調度將會變得異常複雜。

K8s 當前跨 Region 部署能力是藉助於集羣聯邦（Federation）實現，但其功能比較弱並且有很多問題，如何解決跨地域部署實現真正意義上的分佈式系統還須要社區大量努力，社區目前也正在設計討論聯邦第二版。

K8s 支持水平自動擴縮容（HPA）和垂直自動擴縮容（VPA），可以使集羣資源達到更合理的利用，可是對於有狀態應用，如何使自動擴縮容知足業務場景需求同時又不對業務形成較大波動，就不只僅是拿監控的 CPU/Memory/Disk 幾個指標就能完成的。

「Eating your own dog food」是咱們信奉的原則，在 PingCAP 內部的研發和測試資源，只提供惟一的管理方式，也就是 k8s。幾乎全部的 DevOps 平臺，內部系統，穩定性測試平臺，都跑在 k8s 上，在 PingCAP 若是你須要一臺虛擬機做爲開發機是須要特批的。沒錯，咱們 All in k8s。

TiDB Operator

TiDB Operator 是在 k8s 上運行 TiDB 的關鍵，它擴展了 k8s 在 TiDB 運維領域的專業知識。彈性伸縮、滾動升級、failover 等特性也主要是由 TiDB Operator 實現的。Operator 自身也是一個 k8s Deployment，擴展了 k8s 的調度器和控制器，而對 k8s 的代碼徹底沒有侵入性。

咱們基於 Operator 能夠作不少有意思的事情，好比：

跨可用區調度問題，如何將 R 個數據副本的 N 個 tikv 節點均勻分佈在 Z 個可用區，結合 pd 數據層面的調度策略，從而保證掛掉任一臺機器，一個機櫃，甚至整個可用區，都不會影響數據庫服務。
當一個集羣部署多套 TiDB 實例，如何利用 k8s 親和與反親和的特性提升混合部署的效率，實現資源利用率最大化。
如何擴展 k8s 調度器，實現基於本地盤的調度策略，對有狀態的服務提供管理。
如何實現數據庫的全量備份和增量備份，以及備份數據的管理。
如何利用 Admission Webhooks 機制實現更優雅的節點上下線。
如何更好的處理有狀態服務的故障自動轉移。

TiDB Operator 自己也是開源項目https://github.com/pingcap/tidb-operator，咱們也計劃把更多的特性加入進來。好比，CLI 工具，細粒度 API，甚至簡單的 UI 界面，k8s 部署工具等等。也歡迎各位小夥伴對這個項目感興趣，能參與進來。

DBaaS

上面是咱們 DBaaS 產品的原型設計截圖，這是咱們目前還在開發中的項目，預計在 2019 年會作出一個版本出來。

DBaaS 即 Database-as-a-Service，是數據庫在雲上開箱即用的一個概念，是 Cloud Native 的最佳打開方式。具體來說，TiDB DBaaS 是由 PingCAP 全託管，支持 multi-cloud 和 cross-cloud，實現了多租戶多用戶下的多實例管理，具有完整計費和預算控制功能的數據庫雲平臺。用戶只須要註冊帳號便可體驗 TiDB 服務，根據業務選擇對應的 Cloud 供應商和地理 Region。接下來只須要點點鼠標就能夠快速建立具有多副本，跨可用區高可用的 TiDB 實例。TiDB 的節點數能夠根據用戶資源使用量和預設的預算來自動擴縮。用戶經過 VPC Peering Connection 創建應用 VPC 與數據庫 VPC 之間的安全通道，保證數據庫的安全訪問。用戶能夠看到數據庫性能、用量、調度狀態等基本的監控，更復雜的運維由咱們後臺統一管理，用戶只關心如何使用的問題。

實現這樣一套架構並不容易，不只要考慮底層對接不一樣的 Cloud Provider，更重要的是要保障用戶的數據安全和資源隔離，以及服務的可靠性（SLA）。同時，成本也是重要的因素，可以實現資源利用率最大化，以及讓資源按需自動擴縮才能體現數據庫上雲的價值。還有一些特性目前還停留在想法階段，好比同一個 TiDB 集羣跨物理地域（跨 VPC）部署，實如今雲上的全球級高可用，還有不少技術挑戰等着你一塊兒來實現。

測試

雖然把測試寫在了最後，但實際上這是咱們最重視的一個環節。測試的對象不只包括 TiDB 和 Operator，還有 k8s。而分佈式系統的測試須要應對無數種可能性的組合，在雲上的環境更是錯綜複雜，靠人肉來測試是 impossible mission。分佈式系統的測試秉承一切皆能夠 scaling 的思想，經過寫代碼來實現大規模的自動化測試。咱們另一個團隊開發的「薛定諤」平臺，也是基於 k8s 和容器實現各類錯誤注入，模擬各類 Chaos 環境，用來專門測試分佈式系統的穩定性。下一篇文章咱們還會詳細介紹「薛定諤」。