服務層級的高可用性
若要了解 Azure SQL 中的可用性選項和功能，您必須了解服務層級。 您所選服務層級將決定所部署資料庫或受控執行個體的基礎架構。
有兩個購買模型可考量：DTU 和 vCore。 本單元將著重於虛擬核心服務層級及其架構，以獲得高可用性。 您可以讓 DTU 模型的基本和標準層級等同於一般用途，並讓其進階層級等同於業務關鍵。
一般用途
一般用途服務層級中的資料庫和受控執行個體具有相同可用性架構。 請使用下圖作為指南，首先考慮「應用程式」和「控制通道」。 應用程式會連線到伺服器名稱，然後連接到閘道 （GW），以將應用程式的連線指向在 VM 上執行的正確伺服器。 使用一般用途時，主要複本會針對 使用本機連結的 tempdbSSD。 資料和記錄檔會儲存在 Azure 進階儲存體中，這是在本機的備援儲存體 (一個區域中有多個複本)。 然後備份檔案會儲存在 Azure 標準儲存體中，其預設為 RA-GRS。 RA-GRS 是全域備援記憶體，具有多個區域中的複本。
如同我們在此學習路徑的先前課程模組所述，所有 Azure SQL 都建置在 Azure Service Fabric 之上，其可作為 Azure 骨幹。 如果 Azure Service Fabric 判斷需要進行容錯移轉，容錯移轉將會類似於容錯移轉叢集執行個體 (FCI)。 Service Fabric 會尋找具有備用容量的節點，並加速新的 SQL Server 執行個體。 接著會附加資料庫檔案、執行復原，並將閘道更新為將應用程式指向新節點。 不需要任何虛擬網路或接聽程式或更新。 這是內建的功能。
業務關鍵
下一個要考慮的服務層級是業務關鍵，這通常可達到所有 Azure SQL 服務層級 (一般用途、超大規模資料庫、業務關鍵) 的最高效能和可用性。 業務關鍵適用於需要低延遲和最短停機時間的任務關鍵性應用程式。
使用業務關鍵類似於在幕後部署 Always On 可用性群組 (AG)。 不同於一般用途層，業務關鍵 中的數據和記錄檔全都在直接連結的 SSD 上執行，這可大幅降低網路等待時間。 (一般用途使用遠端存放庫。) 在這個 AG 中，有三個次要複本。 您可以使用其中一個作為唯讀端點（不收取額外費用）。 當至少有一個次要複本已強化其交易記錄的變更時，交易就可完成認可。
具有其中一個次要複本的讀取向外延展支援會話層級一致性，因此，如果唯讀會話在複本無法使用的連線錯誤之後重新連線，它可能會重新導向至與讀寫複本沒有 100% 最新狀態的複本。 同樣地，如果應用程式使用讀寫工作階段來寫入資料，且使用唯讀工作階段來立即讀取該資料，則可能不會在複本上立即看到最新的更新。 此延遲是由非同步交易記錄重做作業所造成。
如果發生任何類型的失敗，且 Service Fabric 判斷需要故障轉移，故障轉移至次要複本的速度會很快，因為複本已經存在，且已附加數據。 在容錯移轉中，您不需要接聽程式。 即使故障轉移之後，閘道也會將連線重新導向至主要複本。 此交換器會快速發生，然後 Service Fabric 會負責啟動另一個次要複本。
超大規模資料庫
超大規模資料庫服務層級僅適用於 Azure SQL 資料庫。 此服務層級具有唯一的架構，因為它會使用分層式快取和頁面伺服器，以擴充快速存取資料庫頁面的能力，而不需要直接存取資料庫檔案。
因為此結構會使用已配對的頁面伺服器，因此您可以進行水平縮放來將所有資料放在快取層中。 這個新結構也允許超大規模資料庫支援高達 100 TB 的資料庫。 因為其使用快照集，所以無論大小，可以進行近乎即時的資料庫備份。 資料庫還原需要幾分鐘的時間，不用數小時甚至數天。 您也可以在固定時間內擴大或縮小，以配合工作負載。
記下在此結構中如何取得記錄服務相當有趣。 記錄服務會用來饋送複本以及頁面伺服器。 當記錄服務強化到登陸區域時，交易可以認可，因此認可不需要次要計算複本的變更耗用量。 不同於其他服務層級，您可以決定是否要次要複本。 您可以設定零到四個次要複本，全部都可用於讀取級別。
與其他服務層級一樣，如果 Service Fabric 判斷需要自動故障轉移，但復原時間將取決於次要復本的存在。 例如，若您沒有複本且發生容錯移轉，則案例會與一般用途服務層級類似：Service Fabric 必須先尋找備用容量。 若有一或多個複本，則復原速度會更快，且會更接近業務關鍵服務層級的複本。
業務關鍵 針對需要低延遲的小型記錄寫入工作負載維持最高效能和可用性，但超大規模資料庫服務層級可讓您在 MB/秒方面取得較高的記錄輸送量、提供最大的資料庫大小，並提供最多四個次要複本來達到較高的讀取規模層級。 因此，當您在兩者之間選擇時，您必須考慮您的工作負載。