SQL Azure存儲架構設計

發布時間: 2013-09-15 12:46  閱讀: 4045 次  推薦: 3   [收藏]  

  SQL Azure簡介

  SQL Azure是Azure存儲平臺的邏輯數據庫,物理數據庫仍然是SQL Server。一個物理的SQL Server被分成多個邏輯分片(partition),每一個分片成為一個SQL Azure實例,在分布式系統中也經常被稱作子表(tablet)。和大多數分布式存儲系統一樣,SQL Azure的數據存儲三個副本,同一個時刻一個副本為Primary,提供讀寫服務,其它副本為Secondary,可以提供最終一致性的讀服務。每一個SQL Azure實例的允許的最大數據量可以為1GB或者5GB(Web Edition),10GB, 20GB, 30GB, 40GB或者50GB(Business Edition)。由于限制了子表最大數據量,Azure存儲平臺內部不支持子表分裂。

    Azure整體架構.png

  如上圖,與大多數Web系統架構類似,Azure存儲平臺大致可以分為四層,從上到下分別為:

  1)Client Layer:將用戶的請求轉化為Azure內部的TDS格式流;2)Services Layer:相當于網關,相當于普通Web系統的邏輯層;3)Platform Layer:存儲節點集群,相當于普通Web系統的數據庫層;4)Infrastructure Layer:硬件和操作系統。Azure使用的硬件為普通PC機,論文中給出的典型配置為:8核,32GB內存,12塊磁盤,大致的價格為3500美金。

  Services Layer

  服務層相當于普通Web系統的邏輯層,包含的功能包括:路由,計費,權限驗證。另外,SQL Azure的服務層還監控Platform Layer中的存儲節點,完成宕機檢測和恢復,負載均衡等總控工作。Services Layer的架構如下:

    Azure Service.png

  【sorry,圖片直接copy的,字體比較小,重點理解功能劃分及流程,Utility Layer理解大意即可】

  如上圖,服務層包含四種類型的組件:

  1、Front-end cluster:完成路由功能并包含防攻擊模塊,相當于Web架構中的Web服務器,如Apache或者Nginx;

  2、Utility Layer:請求服務器合法性驗證,計費等功能;

  3、Service Platform:監控存儲節點集群的機器健康狀況,完成宕機檢測和恢復,負載均衡等功能;

  4、Master Cluster:配置服務器,保存每個SQL Azure實例的副本所在的物理存儲節點信息。

  其中,Master Cluster一般配置為七臺機器,采用”Quorum Commit”技術,也就是任何一個Master操作必須同步到四個以上副本才算成功,四個以下Master機器故障不影響服務;其它類型的機器都是無狀態的,且機器之間同構。上圖中,請求的流程說明如下:

  1、客戶端與Front-end機器建立連接,Front-end驗證是否支持客戶端的操作,如CREATE DATABASE這樣的操作只能通過Azure實用工具執行;

  2、Front-end網關機器與客戶端進行SSL協議握手認證,如果客戶端拒絕使用SSL協議則斷開連接。這個過程中還將執行防攻擊保護,比如拒絕某個或某一段范圍IP地址頻繁訪問;

  3、Front-end網關機器請求Utility Layer進行必要的驗證,如請求服務器地址白名單認證;

  4、Front-end網關機器請求Master獲取用戶請求的數據分片所在的物理存儲節點副本信息;

  5、Front-end網關機器請求請求Platform Layer中的物理存儲節點驗證用戶的數據庫權限;

  6、如果以上認證均通過,客戶端和Platform Layer中的存儲節點建立新的連接;

  7~8、后續所有的客戶端請求都直接發送到Platform Layer中的物理存儲節點,Front-end網關只是轉發請求和回復數據,起一個中間代理作用。

  Platform Layer

  平臺層就是存儲節點集群,運行物理的SQL Server服務器。客戶端的請求通過Front-end網關節點轉發到平臺層的數據節點,每個SQL Azure實例是SQL Server的一個數據分片,每個數據分片在不同的SQL Server數據節點上存儲三個副本,同一時刻只有一個副本為Primary,其它副本為Secondary。數據寫入采用”Quorum Commit”策略,至少兩個副本寫成功時才返回客戶端,這樣即使一個數據節點發生故障也不影響正常服務。Platform Layer的架構如下:

    platform.jpg

【sorry,圖片直接copy,字體太小,請關注后續對存儲節點Agent程序的描述】

  如上圖,每個SQL Server數據節點最多服務650個數據分片,每一個數據節點上的所有數據分片的寫操作記錄到一個操作日志文件中,從而提高寫入操作的聚合性能。每個分片的多個副本之間的數據同步是通過同步并回放操作日志實現的,由于每個分片的副本所在的機器可能不同,因此,每個SQL Server存儲節點最多需要和650個其它存儲節點進行數據同步,網絡聚合不夠,這也是限制單個存儲節點最多服務650個分片的原因。

  如上圖,每個物理存儲節點上都運行了一些實用的deamon程序(稱為fabric),大致介紹如下:

  1、Failure detection:檢測數據節點故障從而觸發Reconfiguration過程;

  2、Reconfiguration Agent:節點故障后負責在數據節點重新生成Primary或者Secondary數據分片;

  3、PM (Partition Manager) Location Resolution:解析Master的地址從而發送數據節點的消息給Master的Partition Manager處理;

  4、Engine Throttling:限制每個邏輯的SQL Azure實例占用的資源比例,防止超出容量限制;

  5、Ring Topology:所有的數據節點構成一個環,從而每個節點有兩個鄰居節點可以檢測節點是否宕機。

  分布式相關問題

  1、數據復制(Replication)

  SQL Azure中采用”Quorum Commit”的策略,普通的數據存儲三個副本,至少寫成功兩個副本才可以返回成功;Master存儲七個副本,至少需要寫成功四個副本。每個SQL Server節點的更新操作寫到一個操作日志文件中并通過網絡發送到另外兩個副本,由于不同數據分片的副本所在的SQL Server機器可能不同,一個存儲節點的操作日志最多需要和650個分片數量的機器通信,日志同步的網絡聚合效果不夠好。Yahoo的PNUTS為了解決這個問題采用了消息中間件進行操作日志分發,達到聚合操作日志的效果。

  2、宕機檢測和恢復

  SQL Azure的宕機檢測論文中講的不夠細,大致的意思是:每個數據節點都被一些對等的數據節點監控,發現宕機則報告總控節點進行宕機恢復過程;同時,如果無法確定數據節點是否宕機,比如待監控數據節點假死而停止回復命令,此時需要由仲裁者節點進行仲裁。判斷機器是否宕機需要一些協議控制,后面的文章會專門介紹。

  如果數據節點發生了故障,需要啟動宕機恢復過程。由于宕機的數據節點服務了最多650個邏輯的SQL Azure實例(子表),這些子表可能是Primary,也可能是Secondary。總控節點統一調度,每次選擇一個數據分片進行Reconfiguration,即子表復制過程。對于Secondary數據分片,只需要通過從Primary拷貝數據來增加副本;對于Primary,首先需要從另外兩個副本中選擇一個Secondary作為新的Primary,接著執行和Secondary數據分片Reconfiguration一樣的過程。另外,這里需要進行優先級的控制,比如某個數據分片只有一個副本,需要優先復制;某個數據分片的Primary不可服務,需要優先執行從剩余的副本中選擇Secondary切換為Primary的過程。當然,這里還需要配置一些策略,比如只有兩個副本的狀態持續多長時間開始復制第三個副本,SQL Azure目前配置為兩小時。

  3、負載均衡

  新的數據節點加入或者發現某個節點負載過高時,總控節點啟動負載均衡過程。數據節點負載影響因素包括:讀寫個數,磁盤/內存/CPU/IO使用量等。這里需要注意的是,新機器加入時需要控制子表遷移的節奏,否則大量的子表同時遷移到新加入的機器導致系統整體性能反而變慢。

  SQL Azure由于可以控制每個邏輯SQL Azure實例,即每個子表的大小,因此,為了簡便起見,可以不實現子表分裂,很大程度上簡化了系統。

  4、事務

  SQL Azure支持數據庫事務,數據庫事務相關的SQL語句都會記錄BEGIN TRANSACTION,ROLLBACK TRANSACTION和COMMIT TRANSACTION相關的操作日志。在SQL Azure中,只需要將這些操作日志同步到其它副本即可,由于同一時刻同一個數據分片最多有一個Primary提供寫服務,不涉及分布式事務。SQL Azure系統支持的事務級別為READ_COMMITTED。

  5、多租戶干擾

  云計算系統中多租用的操作相互干擾,因此需要限制每個SQL Azure邏輯實例使用的系統資源:

  1)系統操作系統資源限制,比如CPU和內存。超過限制時回復客戶端要求10s后重試;

  2)SQL Azure邏輯數據庫容量限制。每個邏輯數據庫都預先設置了最大的容量,超過限制時拒絕更新請求,但允許刪除操作;

  3)SQL Server物理數據庫數據大小限制。超過該限制時返回客戶端系統錯誤,此時需要人工介入。

  與SQL Server的差別

  1、不支持的操作:Microsoft Azure作為一個針對企業級應用的平臺,盡管嘗試支持盡量多的SQL特性,仍然有一些特性無法支持。比如USE操作:SQL Server可以通過USE切換數據庫,不過在SQL Azure不支持,這時因為不同的邏輯數據庫可能位于不同的物理機器。具體可以參考SQL Azure vs. SQL Server

  2、觀念轉變:對于開發人員,需要用分布式系統的思維開發程序,比如一個連接除了成功,失敗還有第三種不確定狀態:云端沒有返回操作結果,操作是否成功我們無從得知;又如,天下沒有像SQL這么好的免費午餐;對于DBA同學,數據庫的日常維護,比如升級,數據備份等工作都移交給了微軟,可能會有更多的精力關注業務系統架構。

  完整的信息可以參考微軟前不久公布的Azure存儲系統架構Inside SQL Azure論文

3
0
 
標簽:云計算 Azure
 
 

文章列表

arrow
arrow
    全站熱搜

    大師兄 發表在 痞客邦 留言(0) 人氣()