服務層級的高可用性
若要了解 Azure SQL 中的可用性選項和功能，您必須了解服務層級。 您所選服務層級將決定所部署資料庫或受控執行個體的基礎架構。
有兩個購買模型可考量：DTU 和 vCore。 本單元將著重於虛擬核心服務層級及其架構，以獲得高可用性。 您可以讓 DTU 模型的基本和標準層級等同於一般用途，並讓其進階層級等同於業務關鍵。
一般用途
一般用途服務層級中的資料庫和受控執行個體具有相同可用性架構。 請使用下圖作為指南，首先考慮「應用程式」和「控制通道」。 應用程式會連線到伺服器名稱，該名稱之後會連線到閘道 (GW)，閘道可將應用程式的連線指向在 VM 上執行的正確伺服器。 使用一般用途時，主要複本會針對 tempdb 使用連結本機的 SSD。 資料和記錄檔會儲存在 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 Database。 此服務層級具有唯一的架構，因為它會使用分層式快取和頁面伺服器，以擴充快速存取資料庫頁面的能力，而不需要直接存取資料庫檔案。
因為此結構會使用已配對的頁面伺服器，因此您可以進行水平縮放來將所有資料放在快取層中。 這個新結構也允許超大規模資料庫支援高達 100 TB 的資料庫。 因為其使用快照集，所以無論大小，可以進行近乎即時的資料庫備份。 資料庫還原需要幾分鐘的時間，不用數小時甚至數天。 您也可以在固定時間內擴大或縮小，以配合工作負載。
記下在此結構中如何取得記錄服務相當有趣。 記錄服務會用來饋送複本以及頁面伺服器。 當記錄服務強化到登陸區域時，交易便可以進行認可，因此認可不需要使用次要計算複本的變更。 不同於其他服務層級，您可以決定是否要次要複本。 您可設定零到四個次要複本，且這些複本全部都可供您用於讀取縮放。
如同其他服務層級，若 Service Fabric 判斷需要進行容錯移轉，即會進行自動容錯移轉，但其復原的時間取決於是否存在次要複本。 例如，若您沒有複本且發生容錯移轉，則案例會與一般用途服務層級類似：Service Fabric 必須先尋找備用容量。 若有一或多個複本，則復原速度會更快，且會更接近業務關鍵服務層級的複本。
業務關鍵會針對需要低延遲的小型記錄寫入工作負載維持最高的效能和可用性，但是超大規模資料庫服務層級可讓您取得較高的記錄輸送量 (以 MB/秒為單位)、提供最大的資料庫大小，並提供最多四個次要複本，以取得更高層級的讀取規模。 因此，當您在兩者之間選擇時，必須考量您的工作負載。