前言
https://ithelp.ithome.com.tw/articles/10214092
成本評估
Azure ASR 依下列定價面向計費：
| 前 31 天的價格 | 過了 31 天後的價格 | |
|---|---|---|
| Azure Site Recovery 至客戶擁有的網站 | 免費 | 每月每受保護的執行個體 NT$480.868 |
| Azure Site Recovery 至 Azure | 免費 | 每月每受保護的執行個體 NT$751.355 |
Azure Site Recovery 是以整個月平均每天受保護的執行個體數目為單位加以計費架設如上半個月持續保護了10 台主機，而下半個月沒有保護任何執行個體，則該月每日平均受保護執行個體的數量換算為 5 台。(因為少了半個月的時間)
而啟用保護的成本外覆寫的資料量也是個別按照吃的空間量計算如複寫了100GB就是吃100GB，受控磁碟在複寫期間的會產生屬於非受控磁碟及分頁 Blob類別的儲存體費用，就是呼應上述的吃法。
最後把機器開起來執行服務以及頻寬資料量也屬於額外要估算的…..記得呦！
Azure ASR Q&A
Azure Site Recovery 的免費層次如何運作？
- 每個受 Azure Site Recovery 保護的執行個體，在受保護的前 31 天皆為免費。自第 32 天起，就會依上述費率，針對為該執行個體提供的保護進行收費。
假設我已經使用 Azure Site Recovery 一個多月了。這樣的話，每個受保護的執行個體前 31 天仍然免費嗎？
- 不論已經使用了多久的 Azure Site Recovery。每個受保護的執行個體在前 31 天皆無 Azure Site Recovery 費用如：過去 6 個月保護了 10 個執行個體，而現在您將第 11 個執行個體連線到 Azure Site Recovery，則第 11 個執行個體的前 31 天不會產生任何 Azure Site Recovery 費用。而前 10 個執行個體則因為受保護已超過 31 天，所以會繼續產生 Azure Site Recovery 費用。
SQL Server 授權如何搭配使用 Azure Site Recovery？
- 軟體保證 – 災害復原權益涵蓋適用於 SQL Server 的 Azure Site Recovery 複寫，並適合所有 Azure Site Recovery 案例 (內部部署至 Azure 的災害復原或跨地區 Azure IaaS 的災害復原)。
- 使用任何其他 SQL Server 高可用性技術 (如容錯移轉叢集) 或複寫技術 (如 SQL AlwaysOn 可用性群組、資料庫鏡像及記錄傳送) 時，受到下列 SQL Server 授權指導方針的規範：主要資料庫的軟體保證授權涵蓋第一個被動資料庫執行個體 (通常用來確保本機高可用性)。任何其他被動資料庫執行個體 (若是災害復原，其可能位於遠端內部部署資料中心或任何雲端當中) 都需要額外的 SQL Server 授權。如果主要的 SQL 執行個體位於專用硬體，則專用硬體上的軟體保證授權 (而非共用硬體) 涵蓋第一個被動執行個體。如果主要的 SQL 執行個體位於共用硬體，則第一個被動執行個體也在共用硬體涵蓋範圍中。如需詳細資訊，請參閱 SQL Server 授權指南。
服務架構
圖中範例很明顯可以知道當美東的服務失效時可以立刻透過美國中部地區把原來複寫過來的做容錯移轉把機器帶起來盡可能讓RTO / RPO 為最佳
前置作業
虛擬網路以及異地備援服務建議預先建立，以利後續好管理。
複寫排程規則可以先後都行
簡易實測環境
圖1. 此唯一台東南亞的Linux主機，連線均正常
圖2. 機器也只有我這台Ubuntu
圖3. 選擇到異地備援(中文被翻成嚴重損壞修復)，預設是配對的地區東亞，但其實只要選單上的都是可以依照需求選擇複寫的地區的
圖4. 我選擇日本東部
圖5. 不良示範GG，原來版本不支援
圖6. 看一下白皮書目前Ubuntu只支援14與16兩種
圖7. 重建一台新的16.04版本連線正常
圖8. 選擇已設置好的資源群組與虛擬網路
圖9. 可用性我選擇單一，但實際可以透過選擇可用群組或是可用區域來增強高可用，另外磁碟也可以與來源端的不同，快取儲存就是要跟來源端同地區的儲存體作為複寫過程的暫存複寫的檔案之用
圖10. 選擇日本東部的復原保存服務與原則(如果沒有則都會新增幫你建立只是名稱後面都會帶亂數，未來不好管理)
圖11. 設置確認是否無誤，沒問題就可以複寫了
圖12. 啟用複寫程序進行中
圖13. 從複寫服務的管理介面在進行中的地方已經顯示為一台
圖14. 經過約五分鐘後已經顯示受保護的主機狀態良好並且已經有拓墣產生
圖15. 啟用複寫健康狀態OK
圖16. 開始進行啟用複寫程序(與地端保護相同一樣要安裝Agent)只是步驟Azure背景處理掉了
圖17. 啟用複寫程序完成
圖18. 開始要執行複寫同步作業目前進度為0
圖19. 開始建立第一組快照
圖20. 保護完成可以開始執行測試容錯移轉(也有提示)
圖21. 選快照復原點，我選擇最新的一次狀態
圖22. 方向是從東南亞到日本東部，並選擇開機後取的虛擬網路
圖23. 開始執行測試容錯移轉作業
圖24. 已經把日本東部的複寫主機帶起來了，如最下面所示
圖25. 預設是沒有Public IP的，我因為要測試故手動指派Public IP給它
圖26. 指定完成
圖27. 連線到日本東部這台Lnux OK
圖28. 沒問題就透過清除容錯移轉程序來移除他，千萬不要手動把機器給刪了，後面ASR這服務要把此紀錄移除就會有難度，切記
圖29. 沒問題就可以清除了
圖30. 恢復後一樣只會有東南亞的這台受保護主機嘍！
圖31. 補充如果是容錯移轉就會是把來源關機而在開啟複寫端(建議都要事先把來源關機尤其是有網路有打通的狀態下)
圖32. 容錯移轉程序進行中
圖33. 容錯移轉程序完成
圖34. 實際是複寫的機器還在建立中，來源端尚未關機
圖35. 已經把來源端關機
圖36. 異地複寫的主機連線正常嘍！
圖37. 這不難理解，因為已經由日本東的主機提供服務，中間一定有差異，所以如果還是要由東南亞來提供則就需要重新保護做複寫
圖38. 就會由此台轉正
圖39. 認可完成
Invisible computing 