Categories
程式開發

受水母啟發的數據庫:AWS不會開源這個數據庫,但是他們發表了一篇論文


本文最初發佈於The Next Platform,經原作者授權由InfoQ中文站翻譯並分享。

如果你想要獲得超大規模、彈性、分佈式塊存儲服務的靈感,水母顯然是一個開始尋找架構特性的好對象。

這正是Amazon Web Services為創建Physalia所做的事情。 Physalia是一種大型分佈式數據庫服務,它存儲著彈性塊存儲(Elastic Block Store)服務的元數據。顧名思義,彈性塊存儲服務為運行在公有云上的應用程序提供塊存儲。

去年12月舉行的re:Invent大會上,亞馬遜首席技術官Werner Vogels介紹了Physalia(它得名於僧帽水母)。 Physalia產品背後的技術人員發表了一篇論文,介紹它是什麼以及它與其他高速數據庫和數據存儲有什麼不同。雖然AWS將Physalia開源的可能性很小,但它有可能鼓勵其他人以開源的方式重新創建其架構元素,就像過去許多超大規模的雲構建科技公司所做的那樣。

數以百萬計的數據庫,而不是一個或幾個

在任何類型的分佈式系統中,組件遲早會出現故障,隨著組件數量在聚合系統中不斷增加,故障數量及其影響也會隨之增大。因此,系統架構師必須非常謹慎,尤其是當涉及到連接組件的網絡故障時,這通常被稱為網絡分區,集群兩邊的系統都可以正常運行,但是應用程序和數據存儲的兩個部分基本無法通信,這會導致各種各樣的問題。

關鍵是要非常精確地知道會發生什麼,預測這些問題,並找到在這種情況下可能的最佳解決方法。沒有一種方法是完美的,特別是在數據庫方面。但是,當你創建一個元數據數據庫構成Amazon Web Services彈性塊存儲的基礎時——很可能是這個星球上最大的單數據塊存儲設備的最大集合——你需要盡可能接近完美的方法,否則,人們會丟失數據,失去耐心,或兩者兼而有之。這意味著AWS將失去業務。獲得新客戶的難度是保持現有客戶的十倍,因此,讓使用基礎設施服務的客戶滿意是AWS收入增長的關鍵。

在詳細介紹AWS為管理EBS服務元數據而創建的大型分佈式數據庫Physalia之前,需要做一些準備。正如Vogels在他的主題演講中所指出的那樣,在超大規模雲構建的世界中,“任何事情都可能隨時失敗。”這意味著,大規模的企業不能僅僅特別關注單個組件的可用性以及當系統以巨大的規模運行時可能的可用性變化,還要最小化波及範圍,如設備的數量以及因此受到某種故障影響的客戶的數量。

最小化波及範圍是一件很棘手的事情。正如Vogels提醒大家的那樣,你可以跨區域(跨AWS區域內的多個可用性區域)分配工作負載,這是有幫助的,然後,你還可以將這些區域分解為容量更小的單元格,從而使停機範圍可以更小。同樣地,對於區域內的架構(一次只存在於一個可用性區域),你也可以將它們劃分為單元格,這樣就可以減少客戶受到任何潛在中斷的影響。

“我們總是希望縮小波及範圍,但我們如何選擇單元格的大小呢?”Vogels反問道。 “如果你的單元格較小,就可以真正地縮小波及範圍,這很容易測試,也很容易操作。但如果你的單元格較大,就更經濟,也可以減少分裂,所以整個系統更容易操作。所以問題總是在於如何很好地劃分你的系統,這樣你才能真正地利用基於單元格的架構。”

EBS是AWS上的分區服務,它不僅僅是運行在一堆磁盤驅動器上的磁盤捲的集合。數據被分割成許多塊(由於許多不同的原因),並且每個分片複製一個副本以確保可用性。配置管理器(它位於一個單獨的、與連接EBS和彈性計算服務的網絡不同的網絡上)控制這些分片的訪問——如果一個活躍的分片失敗,它知道在哪裡打開非活動副本並保持塊服務中的數據流,非常重要的是開始重新復制分片到另一個存儲位置,這樣,EBS很快就可以承受另一次打擊而不丟失數據。這種情況並不多見,但是如果很多服務同時出現故障,那麼跟踪所有活動和非活動的所有狀態並複制EBS卷分片的數據庫必須具有超快的速度和超高的彈性。因為AWS處理數百萬卷,所以在EBS下的配置管理器很容易在大範圍停機期間不堪重負。

像谷歌的人(如Eric Brewer,是這家搜索引擎巨頭的基礎設施副總裁,早在1998年,他就正式提出了分佈式數據庫和數據存儲的CAP定理)、亞馬遜的人,他們都清楚地意識到有三件事需要考慮——一致性、可用性和分區容錯性,所以縮寫為CAPT是不是更好呢? ——你只能把這三個事中的任意兩個做好。在實踐中,分佈式數據庫和數據存儲設計師會設法將三件事都盡可能做到100%,谷歌的全球性關係數據庫Spanner就通過一個巨大的核時鐘同步控制平面,這是一種方法,支撐EBS的Physalia數據庫需要一個非常不同的方法,創建一個大規模並行並智能地存放隨實際的EBS存儲塊一起遷移的元數據,因此,從根本上縮小存儲服務中斷的波及範圍。

構建塊

亞馬遜的彈性計算雲虛擬機計算服務(或稱為EC2)及其伴侶簡單存儲服務對象存儲服務(或稱為S3)都是在2006年3月首次露面,亞馬遜在恰當的時間(剛好在“大衰退”之前)推出的恰當的產品引發了已經進行了將近10年的效用計算的第二波浪潮,並最終取得了成功。 S3適合於很多場景,有很多有狀態的應用程序都需要比EC2實例中當時可用的臨時存儲更大一些的東西,還需要塊存儲來運行數據庫之類的東西,數據庫需要塊存儲,而且還需要其具備相當的規模。 EBS於2008年8月推出,它允許客戶直接訪問原始存儲,或者使用自己選擇的文件系統對其格式化,然後從EC2實例掛載。

在EBS設計上,你可能會認為亞馬遜所做的就是創建一種巨大的虛擬化的集群存儲區域網絡,利用商用服務器和存儲附件,開始時是磁盤,後來搭配使用了磁盤和閃存,所有鏈接都是通過公共雲和超大型數據中心使用的巨大的Clos網絡。但亞馬遜並沒有這麼做。相反,EBS是一組較小的虛擬塊存儲設備,最初,卷大小可以從1GB調整到1TB,最多僅為每個客戶分配20個卷。

現在,使用gp2實例的基於閃存的EBS服務可以從1GB擴展到16TB,每個卷的最大吞吐量為250 MB/秒,每個EC2實例的最大吞吐量為2375MB/秒;每秒I/O操作可多達到80000次。 io1實例的IOPS和吞吐量是其四倍,成本僅高出25%外加增加的IOPS費用。使用st1實例的基於磁盤的EBS服務可以從500GB擴展到16TB,每個卷的最大吞吐量為500MB/秒,最大IOPS為500。卷可以組合在一起跨應用程序提供PB級的容量。基於EBS磁盤的sc1實例只有一半的IOPS和吞吐量,成本略高於st1實例的一半。這四種不同的EBS實例類型允許客戶針對不同的工作負載調整其EBS性能(在帶寬和延遲方面)和容量。

EBS本身並不是一個單獨的、巨大的虛擬SAN,這是一件好事,因為它使得這個塊服務更容易管理,而且,由於Physalia數據庫的發明,它也更容易從失敗中恢復過來。這也是為什麼AWS可以承諾在其某個區域的可用性區域內實現EBS服務99.999%的可用性。多個數據中心組成一個可用性區域,其中每個可用性區域各有自己的電源、冷卻系統和設施,外加一個非常粗粒度的波及範圍,這些可用性區域一起組成一個AWS區域。我們知道AWS有22個區域,總共69個可用性區域,但是,我們不知道每個區域有多少個數據中心,因此,我們無法輕易地估計出AWS可能有多少個計算和存儲服務器。可能是數百萬台服務器和數千萬個EC2實例,以及數百萬到數千萬個EBS卷。我們有一種感覺,EBS的捲是以百萬計的,因為Vogels說有“數百萬個”小型的Physalia數據庫。

題外話:AWS說的是僧帽水母——一個準獨立的生物群作為一個整體運作,我們視為一個水母——準確地說,EBS服務本身就是受到這種基於單元格的架構的啟發,實際上,大多數具有彈性的雲服務都是如此。

當突然遇到麻煩

根據AWS的Marc Brooker、Tao Chen和Fan Ping等人撰寫的Physalia論文,2011年4月,發生了一件非常糟糕的事情,讓這個雲巨頭重新思考了EBS的控制平面數據本身的存儲方式。對於正在使用EBS的EC2實例,EBS控制平面必須跟踪連接到該實例卷中的所有副本分片,然後將所有這些配置數據存儲在一個數據庫中,該數據庫也存儲了EBS API通信流。它工作得很好,直到有一次有人修改了網絡,意外導致了網絡分區,致使一個可用性區域中13%的EBS卷變暗。隨之而來的是一場網絡風暴,在查找數據的EC2實例、存儲數據副本的EBS節點和可以將備份指定為主節點並將數據提供給那些EC2實例的EBS控制平面之間。但是隨後出現了競爭條件,EC2實例阻塞了EBS控制平面,導致它無法重新映射數據,EBS服務進入了衰退狀態,影響了所有EBS API的性能和可用性區域內的可用性。

他們花了好一段時間才弄清EBS那天發生了什麼事。在2013年,AWS著手創建一個新的數據庫,用於處理故障期間出現峰值負載的情況。這時,需要將EBS卷中的所有分片從主副本轉移到備份,新的備份會被創建並分配,這樣就可以提供高可用性,以及強一致性,最大限度地減少停機的波及範圍。

AWS技術人員的主要觀點是,並非所有EC2客戶端都需要隨時訪問所有EBS數據——實際上,出於數據安全和主權的考慮,對於公有云實用程序來說,這是一件非常糟糕的事情。因此,用於控制EBS分片複製的EBS卷分區的鍵可以跨網絡分佈在多個數據庫中,而不是一個。

AWS高級首席工程師Marc Brooker解釋說,“很明顯,有多種因素可能導致中斷,波及範圍將根據原因不同而變化。使用Physalia,我們為每個卷創建一個計算單元格,因此,計算單元格的邏輯故障——不管是由網絡分區引起的,還由斷電或其他原因引起的——與單個EBS卷的故障是隔離的。這與以前的架構差別很大,之前是通過將大量的捲組合在一起來獲得規模優勢。”

Physalia是一個鍵值存儲,它不保存客戶數據,只保存分區數據的鍵,這些分區數據控制著數據及其副本的位置。而且,由於它已經知道了數據卷的位置和AWS數據中心的拓撲結構,以及EBS卷的物理位置,所以它可以移動這個EBS控制平面的數據,使其始終靠近使用它的EC2客戶端。因此,在一個可用性區域或區域裡,網絡分區或其他類型的故障導致競態條件(比如當EBS控制數據被塞進API數據庫,而不是像現在這樣的獨立式和分佈式)的可能性會降低,因此,EBS從這些錯誤中恢復(或更準確地說不受他們影響)的可能性要高得多。波及範圍更小。

這個過程很複雜,這就是水母的角色。僧帽水母實際上是一個獨立生物體的集合,它們不能離開這個生物群體而生活。

控制EBS分片分區的鍵被分割並複製到7個節點(不是物理服務器節點,而是分佈式狀態機的邏輯元素),當節點中的數據發生變化時,使用Paxos協議在節點之間建立共識;其中一個節點被指定為Paxos單元中的主節點,它會一直承擔這項工作,直到失敗,然後由其他節點接管。這種方法使得分佈式EBS控制平面數據可以獲得極高的一致性。實際上,存儲在Physalia中的EBS控制數據的可用性大約是存儲在分片EBS卷中的客戶數據副本的5000倍。

重點是:不再採用EBS之前的集中式控制平面,而是一個Physalia單元格的集合(包含由Paxos連接的數理邏輯數據節點)進行控制,這些微型數據庫分佈在AWS基礎設施中的物理服務器節點上,它們的移動方式要保證它們被保存在與EBS卷分片相關聯的EC2實例附近。

這種單元格具身於小型的Physalia數據庫中,是AWS得以減少EBS波及範圍的原因。節點可以在單元格之間共享,這意味著,隨著EC2實例的移動,節點數據可以轉移到更靠近那個EC2節點的另一個Physalia數據庫,在快速切換到新位置之前,有一個邏輯單元格需要延伸一下,而又不會將Paxos節點之間的連接破壞到單元格中的主節點失敗,進而導致定位和復制數據方法失效的程度。單元格的位置存儲在一個最終一致的緩存(稱為發現緩存)裡。顯然,這並不需要完全一致才能很好地工作。

那麼,從集中式數據庫轉移到面向EBS控制平面的Physalia會有什麼影響呢?請看下面這兩個圖表:

受水母啟發的數據庫:AWS不會開源這個數據庫,但是他們發表了一篇論文 1

上面左邊的圖顯示了在Physalia(綠線的左邊)之前的14個月和在Physalia成為EBS控制平面數據存儲之後(9個月稍多點),EBS卷的主副本試圖在系統中獲取配置數據的錯誤率。硬件和軟件基礎設施的故障以及過載都導致了較高的錯誤率;在安裝了Physalia之後,這些問題並沒有神奇地消失,但是新的分佈式狀態機和智能分佈式控制數據(使其接近它們控制的EBS卷)可以在很大程度上克服這些故障。就AWS而言,這就是創建它的全部意義。

上面右邊的圖顯示了每月使用舊的和新的EBS控制平面數據存儲時錯誤率大於0.05%的小時數。同樣,幾乎看不到。

雖然一切都很好,而且是為了激勵系統架構師和站點可靠性工程師,但是AWS不太可能開源Physalia。但是,勇敢的數據庫設計者沒有理由不模仿它,就像來自雅虎的Doug Cutting創建的Hadoop及Hadoop分佈式文件系統,就是克隆了谷歌的MapReduce和谷歌文件系統,還有CockroachDB的創建方式很像谷歌的分佈式全球性關係數據庫Spanner。那麼,從理論上講,所有類型的集中式控制平面數據庫和數據存儲都可以像它們控制的服務一樣進行大規模的分佈,並展現出AWS正在展現的彈性增強。

原文鏈接:

THE JELLYFISH-INSPIRED DATABASE UNDER AWS BLOCK STORAGE