在《云計(jì)算架構(gòu)下Cloud TiDB的技術(shù)奧秘「上」》中，分析了TiDB與傳統(tǒng)單機(jī)關(guān)系型數(shù)據(jù)庫(kù)的區(qū)別，以及與幾種技術(shù)整合之后所形成的總體架構(gòu)。接下來寝杖，我們將深度探討CloudTiDB的關(guān)鍵特性和實(shí)現(xiàn)細(xì)節(jié)。
數(shù)據(jù)庫(kù)產(chǎn)品上云的一個(gè)先決條件是能實(shí)現(xiàn)自動(dòng)化的運(yùn)維管理撑教，因?yàn)樵谠粕峡渴止み\(yùn)維幾乎是不現(xiàn)實(shí)的朝墩。
第一步，用Kubernetes將云平臺(tái)的主機(jī)資源管理起來，組成一個(gè)大資源池收苏；
第二步亿卤，再通過tidb-opeartor及tidb-cloud-manager等組件，來自動(dòng)化完成TiDB實(shí)例的一鍵部署鹿霸、擴(kuò)容縮容排吴、在線滾動(dòng)升級(jí)、自動(dòng)故障轉(zhuǎn)移等運(yùn)維操作懦鼠。
來看集群創(chuàng)建钻哩。在上篇文章里提到過TiDB包含tidb、tikv和pd三大核心組件肛冶，每個(gè)服務(wù)又都是一個(gè)多節(jié)點(diǎn)的分布式結(jié)構(gòu)街氢，服務(wù)和服務(wù)之間的啟動(dòng)順序也存在依賴關(guān)系。此外睦袖，pd節(jié)點(diǎn)的創(chuàng)建和加入集群方式與etcd類似珊肃，是需要先創(chuàng)建一個(gè)單節(jié)點(diǎn)的initial集群，后加入的節(jié)點(diǎn)需要用特殊的join方式馅笙，啟動(dòng)命令上也有差別伦乔。
有一些操作完成后還需要調(diào)用API進(jìn)行通知。Kubernetes自身提供的StatefulSet很難應(yīng)付這種復(fù)雜部署董习，所以需要tidb-operator中實(shí)現(xiàn)特定Controller來完成這一系列操作烈和。同時(shí)，結(jié)合Kubernetese強(qiáng)大的調(diào)度功能皿淋，合理規(guī)劃和分配整個(gè)集群資源招刹，盡量讓新部署的TiDB實(shí)例節(jié)點(diǎn)在集群中均勻分布，最終通過LB暴露給對(duì)應(yīng)的租戶使用沥匈。
在線升級(jí)也類似蔗喂。由于tikv/pd的Pod掛載是本地存儲(chǔ)，并不能像云平臺(tái)提供的塊存儲(chǔ)或網(wǎng)絡(luò)文件系統(tǒng)那樣可以隨意掛載高帖。如果tikv/pd遷移到其它節(jié)點(diǎn)，相當(dāng)于數(shù)據(jù)目錄也被清空畦粮，所以必須保證tikv/pd的Pod在升級(jí)完成后仍然能夠調(diào)度在原地散址，這也是要由tidb-operator的Controller來保證。
TiDB的數(shù)據(jù)副本之間由Raft算法來保證一致性宣赔，當(dāng)集群中某一個(gè)節(jié)點(diǎn)暫時(shí)斷開预麸，可以不影響整個(gè)服務(wù)，所以在集群升級(jí)過程中儒将，必須嚴(yán)格按照服務(wù)的依賴關(guān)系吏祸，再依次對(duì)Pod進(jìn)行升級(jí)。
當(dāng)節(jié)點(diǎn)出現(xiàn)故障時(shí)钩蚊，同樣是由于掛載本地?cái)?shù)據(jù)盤的原因贡翘，也不能像StatefulSet那樣直接把Pod遷移走蹈矮。當(dāng)TiDB Operator檢測(cè)到節(jié)點(diǎn)失效，首先要等一段時(shí)間鸣驱，以確認(rèn)節(jié)點(diǎn)不會(huì)再恢復(fù)了泛鸟，再開始遷移恢復(fù)的操作。
首先調(diào)度選擇一個(gè)新節(jié)點(diǎn)啟動(dòng)一個(gè)Pod, 然后通知TiDB將失效節(jié)點(diǎn)放棄掉踊东，并將新啟的Pod加入集群北滥。后面會(huì)由TiDB的PD模塊來完成數(shù)據(jù)副本數(shù)恢復(fù)以及數(shù)據(jù)往新節(jié)點(diǎn)上遷移，從而重新維持集群內(nèi)數(shù)據(jù)平衡闸翅。
以上僅列舉了TiDB幾種典型的運(yùn)維操作流程再芋，實(shí)際生產(chǎn)上運(yùn)維還有很多case需要考慮，這些都以程序的方式在tidb-operator里實(shí)現(xiàn)坚冀。借助Kubernetes和tidb-operator來代替人工济赎，高效地完成TiDB數(shù)據(jù)庫(kù)在云平臺(tái)上的復(fù)雜運(yùn)維管理。
彈性水平伸縮是TiDB數(shù)據(jù)庫(kù)最主要的特性之一遗菠。在大數(shù)據(jù)時(shí)代联喘，人們對(duì)數(shù)據(jù)存儲(chǔ)的需求快速膨脹，有時(shí)用戶很難預(yù)估自己業(yè)務(wù)規(guī)模的增長(zhǎng)速度辙纬，如果采用傳統(tǒng)存儲(chǔ)方案豁遭，可能很快發(fā)現(xiàn)存儲(chǔ)容量達(dá)到了瓶頸，然后不得不停機(jī)來做遷移和擴(kuò)容贺拣。如果使用Cloud TiDB的方案蓖谢，這個(gè)過程就非常簡(jiǎn)單，只需在Cloud控制臺(tái)上修改一下TiDB的節(jié)點(diǎn)數(shù)量譬涡，就能快速完成擴(kuò)容操作闪幽，期間還不會(huì)影響業(yè)務(wù)的正常服務(wù)。
那么涡匀，在Cloud后臺(tái)盯腌，同樣借助Kubernetes和tidb-operator的能力來完成TiDB增減節(jié)點(diǎn)操作。Kubernetes本身的運(yùn)作是基于一種Reconcile機(jī)制陨瘩，簡(jiǎn)單來說就是當(dāng)用戶提交一個(gè)新請(qǐng)求腕够，比如期望集群里跑5個(gè)TiKV節(jié)點(diǎn)，而目前正在跑的只有3個(gè)舌劳，那么Reconcile機(jī)制就會(huì)發(fā)現(xiàn)這個(gè)差異帚湘，先由Kubernetes調(diào)度器根據(jù)集群整體資源情況，并結(jié)合TiDB節(jié)點(diǎn)分配的親和性原則和資源隔離原則來分配節(jié)點(diǎn)甚淡。另外很重要一點(diǎn)是選擇有空閑Local PV的機(jī)器來創(chuàng)建Pod并進(jìn)行掛載大诸，最終通過tidb-operator將2個(gè)節(jié)點(diǎn)加入TiDB集群。
縮容的過程也類似。假如數(shù)據(jù)庫(kù)存儲(chǔ)的總數(shù)據(jù)量變少资柔，需要減少節(jié)點(diǎn)以節(jié)省成本焙贷，首先用戶通過云控制臺(tái)向后端提交請(qǐng)求，在一個(gè)Reconciling周期內(nèi)發(fā)現(xiàn)差異建邓，tidb-operator的Controller開始通知TiDB集群執(zhí)行節(jié)點(diǎn)下線的操作盈厘。安全下線可能是比較長(zhǎng)的過程，因?yàn)樾枰蒔D模塊將下線節(jié)點(diǎn)的數(shù)據(jù)搬移到其他節(jié)點(diǎn)官边，期間集群都可以正常服務(wù)沸手。當(dāng)下線完成，這些TiKV變成tombstone狀態(tài)注簿，而tidb-operator也會(huì)通知Kubernetes銷毀這些Pod契吉，并且由tidb-volume-manager來回收Local PV。
資源隔離也是云上用戶關(guān)心的一個(gè)問題诡渴。尤其是數(shù)據(jù)庫(kù)這類應(yīng)用捐晶，不同租戶的數(shù)據(jù)庫(kù)實(shí)例，甚至一個(gè)租戶的多套數(shù)據(jù)庫(kù)實(shí)例妄辩，都跑在一套大Kubernetes管理集群上惑灵，相互間會(huì)不會(huì)有資源爭(zhēng)搶問題？某個(gè)實(shí)例執(zhí)行高負(fù)載計(jì)算任務(wù)時(shí)眼耀，CPU英支、內(nèi)存、I/O等會(huì)不會(huì)對(duì)同臺(tái)機(jī)器上部署的其他實(shí)例產(chǎn)生影響哮伟？
其實(shí)干花，容器本身就是資源隔離的一個(gè)解決方案，容器底層是Linux內(nèi)核提供的cgroups技術(shù)楞黄，用于限制容器內(nèi)的CPU池凄、內(nèi)存以及IO等資源的使用，并通過namespace技術(shù)實(shí)現(xiàn)隔離鬼廓。而Kubernetes作為容器編排系統(tǒng)肿仑，能根據(jù)集群中各個(gè)節(jié)點(diǎn)的資源狀況，選擇最優(yōu)策略來調(diào)度容器碎税。同時(shí)柏副，tidb-operator會(huì)根據(jù)TiDB自身特性和約束來綜合決策TiDB節(jié)點(diǎn)的調(diào)度分配。
舉例來說蚣录，當(dāng)一個(gè)Kubernetes集群橫跨多個(gè)可用區(qū)，用戶申請(qǐng)創(chuàng)建一個(gè)TiDB集群眷篇，那么首先根據(jù)高可用性原則萎河，將存儲(chǔ)節(jié)點(diǎn)盡量分配到不同可用區(qū)，并給TiKV打上label。那么同一個(gè)可用區(qū)內(nèi)也盡量不把多個(gè)TiKV部署到相同的物理節(jié)點(diǎn)上虐杯，以保證集群資源最大化利用玛歌。
此外，每個(gè)Local PV也是一塊獨(dú)立磁盤擎椰，每個(gè)TiKV的Pod分別掛載不同的盤支子，所以I/O上也是完全隔離。
Kubernetes還可以配置Pod之間的親和性(affinity)和反親和性(anti-affinity)达舒。例如：在TiKV和TiDB之間值朋，可以通過親和性使其調(diào)度到網(wǎng)絡(luò)延時(shí)較小的節(jié)點(diǎn)上，提高網(wǎng)絡(luò)傳輸效率巩搏。TiKV之間借助反親和性昨登，使其分散部署到不同主機(jī)、機(jī)架和可用區(qū)上贯底，降低因硬件或機(jī)房故障而導(dǎo)致的數(shù)據(jù)丟失風(fēng)險(xiǎn)丰辣。
上面解釋了容器層的隔離，也可以看作是物理層的隔離禽捆。再來看數(shù)據(jù)層的隔離笙什，TiDB的調(diào)度體系也有所考慮，比如一個(gè)大的TiDB集群胚想，節(jié)點(diǎn)分布在很多臺(tái)主機(jī)琐凭，跨越多個(gè)機(jī)架、可用區(qū)顿仇，那么用戶可以定義Namespace淘正，這是一個(gè)邏輯概念，不同業(yè)務(wù)的數(shù)據(jù)庫(kù)和表放置在不同的Namespace臼闻，再通過配置Namespace鸿吆、TiKV節(jié)點(diǎn)以及區(qū)域的對(duì)應(yīng)關(guān)系，由PD模塊來進(jìn)行調(diào)度述呐，從而實(shí)現(xiàn)不同業(yè)務(wù)數(shù)據(jù)在物理上的隔離惩淳。
TiDB作為一個(gè)分布式數(shù)據(jù)庫(kù)，本身就具有高可用性乓搬，每個(gè)核心組件都可以獨(dú)立地?cái)U(kuò)縮容思犁。任意一個(gè)模塊在部署多份副本時(shí)，如果有一個(gè)掛掉进肯，整體仍然可以正常對(duì)外提供服務(wù)激蹲，這是由Raft協(xié)議保證的。但是江掩，如果對(duì)數(shù)據(jù)庫(kù)節(jié)點(diǎn)的調(diào)度不加任何限制学辱，包含一份數(shù)據(jù)的多個(gè)副本的節(jié)點(diǎn)可能會(huì)被調(diào)度到同一臺(tái)主機(jī)乘瓤。這時(shí)如果主機(jī)發(fā)生故障，就會(huì)同時(shí)失去多個(gè)副本策泣，一個(gè)Raft分組內(nèi)失去多數(shù)派節(jié)點(diǎn)就會(huì)導(dǎo)致整個(gè)集群處于不可用狀態(tài)衙傀，因此tidb-operator在調(diào)度TiKV節(jié)點(diǎn)時(shí)需要避免出現(xiàn)這種情況。
另外萨咕，TiDB支持基于label的數(shù)據(jù)調(diào)度统抬，能給不同TiKV實(shí)例加上描述物理信息的label，例如地域(Region)危队、可用區(qū)(AZ)聪建、機(jī)架(Rack)、主機(jī)(Host)交掏，當(dāng)PD在對(duì)數(shù)據(jù)進(jìn)行調(diào)度時(shí)妆偏，就會(huì)參考這些信息更加智能地制定調(diào)度策略，盡最大可能保證數(shù)據(jù)的可用性盅弛。
例如钱骂，PD會(huì)基于label信息盡量把相同數(shù)據(jù)的副本分散調(diào)度到不同的主機(jī)、機(jī)架挪鹏、可用區(qū)见秽、地域上，這樣在物理節(jié)點(diǎn)掛掉讨盒、機(jī)架掉電或機(jī)房出故障時(shí)解取，其它地方仍然有該數(shù)據(jù)足夠的副本數(shù)。借助tidb-operator中controller-manager組件返顺，可以自動(dòng)給TiKV實(shí)例加上物理拓?fù)湮恢脴?biāo)簽禀苦，充分發(fā)揮PD對(duì)數(shù)據(jù)的智能調(diào)度能力，實(shí)現(xiàn)數(shù)據(jù)層面的高可用性遂鹊。
同時(shí)振乏，還可以達(dá)到實(shí)例級(jí)別的高可用性，通過Kubernetes強(qiáng)大的調(diào)度規(guī)則和擴(kuò)展的調(diào)度器秉扑，按優(yōu)先級(jí)會(huì)盡量選擇讓TiKV部署到不同的主機(jī)慧邮、機(jī)架和可用區(qū)上，把因主機(jī)舟陆、機(jī)架误澳、機(jī)房出問題造成的影響降到最低，使數(shù)據(jù)具有最大的高可用性秦躯。
另外忆谓，運(yùn)行在Kubernetes之上，能實(shí)時(shí)監(jiān)測(cè)到TiDB各組件運(yùn)行情況踱承，當(dāng)出現(xiàn)問題時(shí)陪毡，也能第一時(shí)間讓tidb-operator對(duì)集群進(jìn)行自動(dòng)修復(fù)(self-healing)米母。具體表現(xiàn)為tidb/tikv/pd實(shí)例出現(xiàn)故障時(shí)，執(zhí)行安全的下線操作毡琉，同時(shí)增加新實(shí)例來保證集群的規(guī)模和之前一致。
小結(jié)
TiDB作為一款CloudNative Database妙色，通過tidb-operator方式充分發(fā)揮Kubernetes平臺(tái)的強(qiáng)大能力桅滋，實(shí)現(xiàn)云上自動(dòng)化管理，極大降低人力運(yùn)維成本身辨。用戶可以根據(jù)業(yè)務(wù)需要進(jìn)行動(dòng)態(tài)擴(kuò)容縮容丐谋，多租戶隔離特性讓不同租戶的實(shí)例可以共享計(jì)算和存儲(chǔ)資源，互不干擾煌珊，同時(shí)最大程度充分使用云上資源号俐。Raft算法和tidb-operator自動(dòng)修復(fù)能力以及兩層調(diào)度機(jī)制保證了CloudTiDB的高可用性。
UCloud和PingCAP公司深度合作定庵，推出的Cloud TiDB產(chǎn)品現(xiàn)已開啟公測(cè)吏饿，歡迎大家來體驗(yàn)云計(jì)算架構(gòu)下的新一代數(shù)據(jù)庫(kù)。
