SQL Azure存儲架構(gòu)設(shè)計

SQL Azure簡介

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

如上圖，與大多數(shù)Web系統(tǒng)架構(gòu)類似，Azure存儲平臺大致可以分為四層，從上到下分別為：

1）Client Layer：將用戶的請求轉(zhuǎn)化為Azure內(nèi)部的TDS格式流；2）Services Layer：相當(dāng)于網(wǎng)關(guān)，相當(dāng)于普通Web系統(tǒng)的邏輯層；3）Platform Layer：存儲節(jié)點集群，相當(dāng)于普通Web系統(tǒng)的數(shù)據(jù)庫層；4）Infrastructure Layer：硬件和操作系統(tǒng)。Azure使用的硬件為普通PC機，論文中給出的典型配置為：8核，32GB內(nèi)存，12塊磁盤，大致的價格為3500美金。

Services Layer

服務(wù)層相當(dāng)于普通Web系統(tǒng)的邏輯層，包含的功能包括：路由，計費，權(quán)限驗證。另外，SQL Azure的服務(wù)層還監(jiān)控Platform Layer中的存儲節(jié)點，完成宕機檢測和恢復(fù)，負載均衡等總控工作。Services Layer的架構(gòu)如下：

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

如上圖，服務(wù)層包含四種類型的組件：

1、Front-end cluster：完成路由功能并包含防攻擊模塊，相當(dāng)于Web架構(gòu)中的Web服務(wù)器，如Apache或者Nginx；

2、Utility Layer：請求服務(wù)器合法性驗證，計費等功能；

3、Service Platform：監(jiān)控存儲節(jié)點集群的機器健康狀況，完成宕機檢測和恢復(fù)，負載均衡等功能；

4、Master Cluster：配置服務(wù)器，保存每個SQL Azure實例的副本所在的物理存儲節(jié)點信息。

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

1、客戶端與Front-end機器建立連接，F(xiàn)ront-end驗證是否支持客戶端的操作，如CREATE DATABASE這樣的操作只能通過Azure實用工具執(zhí)行；

2、Front-end網(wǎng)關(guān)機器與客戶端進行SSL協(xié)議握手認(rèn)證，如果客戶端拒絕使用SSL協(xié)議則斷開連接。這個過程中還將執(zhí)行防攻擊保護，比如拒絕某個或某一段范圍IP地址頻繁訪問；

3、Front-end網(wǎng)關(guān)機器請求Utility Layer進行必要的驗證，如請求服務(wù)器地址白名單認(rèn)證；

4、Front-end網(wǎng)關(guān)機器請求Master獲取用戶請求的數(shù)據(jù)分片所在的物理存儲節(jié)點副本信息；

5、Front-end網(wǎng)關(guān)機器請求請求Platform Layer中的物理存儲節(jié)點驗證用戶的數(shù)據(jù)庫權(quán)限；

6、如果以上認(rèn)證均通過，客戶端和Platform Layer中的存儲節(jié)點建立新的連接；

7~8、后續(xù)所有的客戶端請求都直接發(fā)送到Platform Layer中的物理存儲節(jié)點，F(xiàn)ront-end網(wǎng)關(guān)只是轉(zhuǎn)發(fā)請求和回復(fù)數(shù)據(jù)，起一個中間代理作用。

Platform Layer

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

【sorry，圖片直接copy，字體太小，請關(guān)注后續(xù)對存儲節(jié)點Agent程序的描述】

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

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

1、Failure detection：檢測數(shù)據(jù)節(jié)點故障從而觸發(fā)Reconfiguration過程；

2、Reconfiguration Agent：節(jié)點故障后負責(zé)在數(shù)據(jù)節(jié)點重新生成Primary或者Secondary數(shù)據(jù)分片；

3、PM(Partition Manager)Location Resolution：解析Master的地址從而發(fā)送數(shù)據(jù)節(jié)點的消息給Master的Partition Manager處理；

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

5、Ring Topology：所有的數(shù)據(jù)節(jié)點構(gòu)成一個環(huán)，從而每個節(jié)點有兩個鄰居節(jié)點可以檢測節(jié)點是否宕機。

分布式相關(guān)問題

1、數(shù)據(jù)復(fù)制(Replication)

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

2、宕機檢測和恢復(fù)

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

如果數(shù)據(jù)節(jié)點發(fā)生了故障，需要啟動宕機恢復(fù)過程。由于宕機的數(shù)據(jù)節(jié)點服務(wù)了最多650個邏輯的SQL Azure實例（子表），這些子表可能是Primary，也可能是Secondary?？偪毓?jié)點統(tǒng)一調(diào)度，每次選擇一個數(shù)據(jù)分片進行Reconfiguration，即子表復(fù)制過程。對于Secondary數(shù)據(jù)分片，只需要通過從Primary拷貝數(shù)據(jù)來增加副本；對于Primary，首先需要從另外兩個副本中選擇一個Secondary作為新的Primary，接著執(zhí)行和Secondary數(shù)據(jù)分片Reconfiguration一樣的過程。另外，這里需要進行優(yōu)先級的控制，比如某個數(shù)據(jù)分片只有一個副本，需要優(yōu)先復(fù)制；某個數(shù)據(jù)分片的Primary不可服務(wù)，需要優(yōu)先執(zhí)行從剩余的副本中選擇Secondary切換為Primary的過程。當(dāng)然，這里還需要配置一些策略，比如只有兩個副本的狀態(tài)持續(xù)多長時間開始復(fù)制第三個副本，SQL Azure目前配置為兩小時。

3、負載均衡

新的數(shù)據(jù)節(jié)點加入或者發(fā)現(xiàn)某個節(jié)點負載過高時，總控節(jié)點啟動負載均衡過程。數(shù)據(jù)節(jié)點負載影響因素包括：讀寫個數(shù)，磁盤/內(nèi)存/CPU/IO使用量等。這里需要注意的是，新機器加入時需要控制子表遷移的節(jié)奏，否則大量的子表同時遷移到新加入的機器導(dǎo)致系統(tǒng)整體性能反而變慢。

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

4、事務(wù)

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

5、多租戶干擾

云計算系統(tǒng)中多租用的操作相互干擾，因此需要限制每個SQL Azure邏輯實例使用的系統(tǒng)資源：

1）系統(tǒng)操作系統(tǒng)資源限制，比如CPU和內(nèi)存。超過限制時回復(fù)客戶端要求10s后重試；

2）SQL Azure邏輯數(shù)據(jù)庫容量限制。每個邏輯數(shù)據(jù)庫都預(yù)先設(shè)置了最大的容量，超過限制時拒絕更新請求，但允許刪除操作；

3）SQL Server物理數(shù)據(jù)庫數(shù)據(jù)大小限制。超過該限制時返回客戶端系統(tǒng)錯誤，此時需要人工介入。

與SQL Server的差別

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

2、觀念轉(zhuǎn)變：對于開發(fā)人員，需要用分布式系統(tǒng)的思維開發(fā)程序，比如一個連接除了成功，失敗還有第三種不確定狀態(tài)：云端沒有返回操作結(jié)果，操作是否成功我們無從得知；又如，天下沒有像SQL這么好的免費午餐；對于DBA同學(xué)，數(shù)據(jù)庫的日常維護，比如升級，數(shù)據(jù)備份等工作都移交給了微軟，可能會有更多的精力關(guān)注業(yè)務(wù)系統(tǒng)架構(gòu)。