云存儲高可用機制2 說課一等獎

云存儲高可用機制22Ceph的高可用機制

作為一個面向大規(guī)模的分布式存儲系統(tǒng)，故障處理是作為一個常態(tài)異常處理。Ceph為了細化和保證故障發(fā)生和故障恢復(fù)的集群高可用性和一致性，在設(shè)計上將故障分為兩類:臨時性故障:主機升級維護，重啟，掉電等等在一定時間內(nèi)可以重新上線OSD的故障永久性故障:作為強一致存儲系統(tǒng)，狀態(tài)只跟存儲在持久設(shè)備的數(shù)據(jù)有關(guān)，因此這類故障主要就是盤損壞或者主機損壞并無法及時轉(zhuǎn)移盤到另外主機。換句話說救是一定時間內(nèi)無法將原來的OSD數(shù)據(jù)重新加入集群。Ceph將所有數(shù)據(jù)域劃分成若干個PG(PlacementGroup)管理，每個PG都存活在一個OSD節(jié)點上，因此PG是管理、恢復(fù)數(shù)據(jù)的主體。而Monitor節(jié)點不參與用戶數(shù)據(jù)的任何操作，只提供了PG選舉的協(xié)調(diào)作用。PG所屬數(shù)據(jù)的處理和恢復(fù)都由PG本身進行協(xié)調(diào)。3臨時性故障

首先這里考慮臨時性故障的處理，Ceph引入了PGLog的概念，顧名思義，PGLog由PG維護并且記錄了該PG所有的操作，其非常類似于關(guān)系型數(shù)據(jù)庫領(lǐng)域的undolog，同時需要將PGLog與Journal概念劃分清楚，Journal是底層單機存儲模塊用來維護事務(wù)一致性的，它是數(shù)據(jù)庫領(lǐng)域的redolog。undolog和redolog在數(shù)據(jù)庫的作用與Ceph的PGLog和Journal作用是一致的。PGLog通常只保存PG最近幾千條的操作記錄，但是在PG處于Degraded狀態(tài)時，PGLog會保存更多的日志條目期望能在故障PG重新上線后用來恢復(fù)數(shù)據(jù)。下面來簡單描述故障發(fā)生導(dǎo)致OSD下線的流程:某一個OSD下線如果OSD主動下線它會通知Monitor自己下線，請做好相關(guān)通知工作。如果是異常下線，那么其他OSD和Monitor會通過Heartbeat來得知OSD下線同樣讓Monitor知曉Monitor重新計算該OSD擁有的的PrimaryPG，并將結(jié)果主動通知這些PG所在的OSDPG將自己設(shè)為Degraded狀態(tài)后，將會減小自己的副本數(shù)，并增加保存的PGLog條目數(shù)4故障流程故障發(fā)生后，如果一定時間后重新上線故障OSD，那么PG會進行以下流程:1.故障OSD上線，通知Monitor并注冊，該OSD在上線前會讀取存在持久設(shè)備的PGLog，2.Monitor得知該OSD的舊有id，因此會繼續(xù)使用以前的PG分配，之前該OSD下線造成的DegradedPG會被通知該OSD已重新加入3.這時候分為兩種情況，注意這個情況下PG會標(biāo)志自己為Peering狀態(tài)并暫時停止處理請求:3.1第一種情況是故障OSD所擁有的PrimaryPG3.1.1它作為這部分?jǐn)?shù)據(jù)"權(quán)責(zé)"主體，需要發(fā)送查詢PG元數(shù)據(jù)請求給所有屬于該PG的Replicate角色節(jié)點。3.1.2該PG的Replicate角色節(jié)點實際上在故障OSD下線時期間成為了Primary角色并維護了“權(quán)威”的PGLog，該PG在得到故障OSD的PrimaryPG的查詢請求后會發(fā)送回應(yīng)3.1.3PrimaryPG通過對比ReplicatePG發(fā)送的元數(shù)據(jù)和PG版本信息后發(fā)現(xiàn)處于落后狀態(tài)，因此它會合并得到的PGLog并建立“權(quán)威”PGLog，同時會建立missing列表來標(biāo)記過時數(shù)據(jù)3.1.4PrimaryPG在完成“權(quán)威”PGLog的建立后就可以標(biāo)志自己處于Active狀態(tài)3.2第二種情況是故障OSD所擁有的ReplicatePG3.2.1這時上線后故障OSD的ReplicatePG會得到PrimaryPG的查詢請求，發(fā)送自己這份“過時”的元數(shù)據(jù)和PGLog3.2.2PrimaryPG對比數(shù)據(jù)后發(fā)現(xiàn)該PG落后并且過時，比通過PGLog建立了missing列表3.2.3PrimaryPG標(biāo)記自己處于Active狀態(tài)4.PG開始接受IO請求，但是PG所屬的故障節(jié)點仍存在過時數(shù)據(jù)，故障節(jié)點的PrimaryPG會發(fā)起Pull請求從Replicate節(jié)點獲得最新數(shù)據(jù)，ReplicatePG會得到其他OSD節(jié)點上的PrimaryPG的Push請求來恢復(fù)數(shù)據(jù)5.恢復(fù)完成后標(biāo)記自己Clean5永久性故障

上面的流程的前提故障OSD在PGLog保存的最大條目數(shù)以內(nèi)加入集群都會利用PGLog恢復(fù)，那么如果在N天之后或者發(fā)生了永久故障需要新盤加入集群時，PGLog就無法起到恢復(fù)數(shù)據(jù)的作用，這時候就需要backfill(全量拷貝)流程介入。backfill會將所有數(shù)據(jù)復(fù)制到新上線的PG，這里的流程跟上述過程基本一致，唯一的差異就是在第三步PrimaryPG發(fā)現(xiàn)PGLog已經(jīng)不足以恢復(fù)數(shù)據(jù)時，這時候同樣分為兩種情況:

故障OSD擁有PrimaryPG，該PG在對比PGLog后發(fā)現(xiàn)需要全量拷貝數(shù)據(jù)，那么毫無疑問PrimaryPG在復(fù)制期間已經(jīng)無法處理請求，它會發(fā)送一個特殊請求給Monitor告知自己需要全量復(fù)制，需要將ReplicatePG臨時性提升為Primary，等到自己完成了復(fù)制過程才會重新接管Primary角色

故障OSD擁有ReplicatePG，該PG的Primary角色會發(fā)起backfill流程向該PG復(fù)制數(shù)據(jù)，由于故障OSD是Replicate角色，因此不影響正常IO的處理除此之外，恢復(fù)數(shù)據(jù)還需要涉及到恢復(fù)數(shù)據(jù)的帶寬控制、優(yōu)先級等細節(jié)問題，這里就不一一贅述了。6小結(jié)