筆者之前在多場研討會和課程中講授SQL Azure時，都會強調一件事：『雖然SQL Azure和SQL Server很像，但它們本質上還是不同的』。看起來再怎麼像的東西，也一定有不同的地方，SQL Azure以Windows Azure基礎建設環境為基石建構，同時享有了高可用度與容錯能力，但是它並不是什麼都沒改就能做容錯的，除了基礎建設對網路與虛擬機器資源的支援外，SQL Server本身勢必也要做一些修改，才能符合SQL Azure原始設計上應有的功能。

每個資料中心最多會有650個分割區來儲存SQL Azure的資料庫，每個節點是一台實體伺服器（擁有8核心CPU、32GB RAM與12顆硬碟組成，平均每台成本3,500美元），在每台實體伺服器內都有安裝SQL Server執行個體，以及與其他SQL Server節點串接的Fabric Service，除了協調與管理SQL Server節點的重要工作，高可用性與容錯的核心也是由它負責，而SQL Server執行個體則是特別為SQL Azure環境所設計的，擁有特殊的資料複製演算法以及配合區域對應所設計的服務。SQL Azure的Fabric Service則有下列不同的功能：

1. 錯誤偵測管理員（Failure Detector）：負責處理當主機發生硬體故障中斷時，偵知並通報Reconfiguration Agent處理資料庫重定位（Re-location）的工作。
2. 更新組態代理程式（Reconfiguration Agent）：負責對每個資料庫的Primary Database與Secondary Database進行轉置與重定位的工作，會在每台機器的錯誤偵測管理員偵知時啟動。
3. PM（Partition Manager）位置解析器（PM Location Resolution）：處理分割區的位置解析訊息以及與Partition Manager的訊息互動。
4. 資料庫引擎節流（Engine Throttling）：類似於SQL Server的Load Balancing機制，如果發現資料庫連線有長時間滯留、耗用資源達上限或執行時間過久時，會自動切斷連線。
5. 環拓樸技術（Ring Topology）：以環狀的方式作為叢集的基礎管理主機與其他主機的關係，在環狀的關係線上，每台伺服器都會自動偵測左邊和右邊的伺服器的健康狀況。

SQL Azure在使用者建立新資料庫時，會在同一資料中心內將資料庫另存成三份並保存在不同的實體儲存區內（不同的磁碟櫃或不同的磁碟），這三份資料庫之間有特殊設計的複製機制，主要的資料庫稱為Primary Database，而複本則是Secondary Database，在每次資料庫進行變更（INSERT, UPDATE, DELETE）時，Primary Database會將變更發送給三個Secondary Database，並以投票式認可（Quorum Commit）的方式，確認資料變更已正確的寫入Secondary Database，內，以達成分散儲存的備援能力。

SQL Azure特製的SQL Server本身，利用了Replication Agent（執行資料複製與投票認可）以及Local Partition Map（對應不同資料庫分割的對照表）達成了將資料分散複製的能力，同時因為SQL Azure內的SQL Server都是自動化作業，所以有不少的系統級功能都無法在SQL Azure上使用，像是：

1. SQL CLR（無法存取系統登錄）
2. Replication（由Replication Agent處理）
3. Partition（無法存取系統登錄）
4. Filegroups與資料庫路徑定義（由Local Partition Map與Partition Manager處理）
5. Backup與Restore（由Windows Azure基礎建設處理）
6. Database Mirroring（由SQL Server以及Local Partition Map處理）
7. 跨資料庫存取（一條連線僅可存取一個資料庫）

而部份T-SQL以及系統管理指令也因應這些功能的限制而修改，所以影響較大的會是存取到系統資源與系統管理的SQL指令，而只限於單一資料庫的T-SQL指令，像基本的SELECT, INSERT, UPDATE和DELETE都不會受到影響，SQL Azure可用的T-SQL指令也可以在MSDN Library中取得。

我們在Windows Azure Management Portal所建立的SQL Azure Server，它的本身其實是在SQL Azure基礎建設之上的隔離層（Façade），負責對外的連線管理以及存取控制等，稱為SQL Azure Gateway，對外以SQL Azure Server的方式呈現，它內含了一個master資料庫，以及使用者資料庫的分割位置和所屬的SQL Server的位置，每一條對資料庫的連線都會經過它，先進行指令解析與授權後，再將連線轉到實際處理的SQL Server，這個階段稱為Connection Routing。

連線的處理過程是：

1. 應用程式使用TDS開啟連線，訊息送到SQL Azure Server，首先由Gateway的Protocol Parser解析封包以及指令有沒有惡意指令。
2. 通過Protocol Parser後，進入Gateway Logic，它會處理SSL的三方交握程序（handshaking），並且偵測是否在同一個IP或是一段的IP中已產生過多的連線（防止DoS攻擊）。
3. 傳送給工具服務（Utility Layer）檢查，包含伺服器名稱以及檢核身份認證資訊（Logins），以及防火牆的設定是否允許連線。請注意，在這個階段如果是要處理像CREATE DATABASE這種指令時，由工具服務進行認證，若只是單純存取資料庫，則不會真的進行驗證。
4. 由Master Node中的Partition Manager搜尋並對應連線要求的伺服器以及資料庫是在哪個Data Node，這些Data Node的分布稱為Partition，由SQL Azure的服務所維護。
5. 當資料庫被找到後，連線會和該節點的SQL Server連接起來，真正的身份認證會在這個階段執行，完成認證後即可進行SQL的處理工作。這份資料會一併回傳給Gateway。
6. Gateway會保留連線成功的Session狀態，下次連線時，Gateway即為代理程式，會自動將連線導向到正確的位置。
   7.應用程式再次要求連線，由Gateway取得先前保留的狀態，包含資料庫的位置。
7. Gateway直接導向連線到目標的資料庫位置。

因為SQL Azure的Gateway會偵測與處理連線過多或過長的問題，所以一般來說，存取SQL Azure的連線不宜過長，而且如果一個連線可以跑多個SQL的話，就不要建立其他的連線，同時也要避免連線進入Idle（閒置）狀態，如果閒置過久，連線也會被Gateway自動關閉。

因為這兩個是使用SQL Azure前必須要了解的核心知識，所以筆者就只針對這兩個來說明，其他關於高可用度與容錯的部份，可自行參考TechNet Wiki中的Inside SQL Azure一文。

Reference:
http://social.technet.microsoft.com/wiki/contents/articles/inside-sql-azure.aspx
http://en.wikipedia.org/wiki/Quorum_(distributed_computing)