SQL Azure簡(jiǎn)介

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

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

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

　　Services Layer

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

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

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

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

　　2、Utility Layer：請(qǐng)求服務(wù)器合法性驗(yàn)證，計(jì)費(fèi)等功能；

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

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

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

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

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

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

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

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

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

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

　　Platform Layer

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

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

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

　　如上圖，每個(gè)物理存儲(chǔ)節(jié)點(diǎn)上都運(yùn)行了一些實(shí)用的deamon程序（稱為fabric），大致介紹如下：

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

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

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

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

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

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

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

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

　　2、宕機(jī)檢測(cè)和恢復(fù)

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

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

　　3、負(fù)載均衡

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

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

　　4、事務(wù)

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

　　5、多租戶干擾

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

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

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

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

　　與SQL Server的差別

　　1、不支持的操作：Microsoft Azure作為一個(gè)針對(duì)企業(yè)級(jí)應(yīng)用的平臺(tái)，盡管嘗試支持盡量多的SQL特性，仍然有一些特性無(wú)法支持。比如USE操作：SQL Server可以通過(guò)USE切換數(shù)據(jù)庫(kù)，不過(guò)在SQL Azure不支持，這時(shí)因?yàn)椴煌倪壿嫈?shù)據(jù)庫(kù)可能位于不同的物理機(jī)器。具體可以參考SQL Azure vs. SQL Server。

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

　　完整的信息可以參考微軟前不久公布的Azure存儲(chǔ)系統(tǒng)架構(gòu)Inside SQL Azure論文。

it知識(shí)庫(kù)：SQL Azure存儲(chǔ)架構(gòu)設(shè)計(jì)，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。