案例分享：遷移 Azure 服務至新區域資料中心的過程及步驟
最近我們接到了需要將資料中心從美國中南部移到美東的客戶需求，該工作包括計劃一個適合的 SKU，以及有效利用地理複寫 (Geo-Replication) 的高可用性和可回復性。
客戶試圖整合他們 Azure 服務，並遷移之，其中最重要的需求是資料庫的預期停機時間，他們希望停機時間越短越好，不可超過6小時。
客戶概觀
此客戶是個社交手機遊戲 (可按地理位置搜尋) 的開發商，該遊戲存有世界各地知名的城鎮，玩家於遊戲中會選擇他們所在的地理位置。
計畫
從計畫的角度來看，我們考量了多個選項。這些都不是特別長的討論，但值得思考和關注的問題點，且通常都是必要的討論。
◎ 資料庫多大？
◎ 目前資料庫的 SKU 是？
◎ 你能容忍的停機時間是多久？
◎ 你可容忍多少資料於轉移過程中遺失？
◎ 你的預算？
◎ 你是否能容忍使用最近發佈或是仍在預覽階段的服務？
◎ 對於資料移轉是否有什麼特別的顧忌？
◎ 什麼是你不擔心的？
該客戶是最重視的是移動性，因此我們必須擁有相當足夠地於經緯度數量。
該資料庫約 35 GB，而其中約 5 GB 的資料被認為是於轉移過程中需保持 online 狀態，其餘的資料則可於 offline 狀態下進行添加。
該資料庫是企業版的 SKU，且並沒有使用任何具體 Azure 功能。
他們可以容忍長達 8 小時的停機時間，但若停機時間可小於 2 小時，是企業及消費者的期望。當然每週有特定的時間點是最適合停機的，因此停機時間控制是一個可被設計的需求。
客戶是成本導向的，但願意瞭解屏除成本考量外的任何方案。
客戶對於 DBCopy 過程是相當謹慎的，並認為資料的 import/export 時間若超過 10 小時，將造成嚴重損失。
計算節點的轉移不是主要考量，也不是迫切地需要將現有的 Blob Storage Data 轉移，解決方案是建構像是 No Cross DC Logic，以便訪問現有的 Blobs。
解決方案包括：
◎ 作用中地理複寫功能。
◎ 中斷所有連線後，導出資料、複製文件，再將資料導入美東地區。
◎ 創建DBCopy、導出資料、複製文件，並在美東地區恢復。
首選是「啟用地理複寫功能」，原因是：
- 最短的停機時間。
- 於轉移過程中不會有資料遺失。
- 可使用 Rollback。
- 若執行失敗，於美國中南部的資料中心重新啟用是很簡單的。
- 總成本最低。
- 可符合未來計劃 (升級到Premium SKU)。
比較值得注意的是，該服務是預覽版，但這被認為是一個容忍的風險。於分析歷史資料後，決定一個 P1 就足以滿足他們的需求。另外不可避免的風險是，複製過程是否會佔用過多資源，但這被視為是特殊事件，畢竟可預期的資源需求不高，故最後還是決定保有 P1，並隨時準備升級到 P2。
於容量規劃過程中，客戶是參考「變更資料庫服務層和效能層級」決定 SQL Azure 資料庫的版本。
執行
客戶必須註冊為 Premium SKU 預覽，這必須通過 portal 花幾秒鐘的時間完成。
一旦簽約，該資料庫可升級到 Premium，請參閱「更改資料庫服務層級和性能水平」。以下公式實際上是相當準確的，預估升級時間為 12 小時：
3 * [ 5分鐘 + 資料庫大小 / (150 MB/分鐘) ]
接下來的步驟是建立理想中的複製區域，即美國東地區，這部分較難預估需要多長時間，也較難預估即將開展的副本所需資源。這些步驟可參考「設定作用中地理複寫 (連續複製)」。
值得注意的是，這個執行計劃是基於程式碼間的部署，若過程是純技術性的，大多於 24 小時內完成。但客戶選擇多等一兩天再執行計畫的下一步，其理由是完成特定程式碼的修改，而發生在現有的拓撲不是在一個新的數據中心。他們關心DDL更改是否會被複製。所有的更改都將被複製，除了於更新主資料庫後必要的更動，像是登入設定等。這些必須在每個環境中進行，而使用者的創建可在 source 完成，詳情請參見「作用中地理複寫的安全性」，將具體說明登入相關議題。
最後一步是切換到新的區域。以下步驟是客戶特別分享的經驗談，提供給未來可能負責此工作的 IT 專業人員們。對於終止作用中地理複寫，可參考「終止連續複製關聯性」一文。
- 提前一週升級資料庫至 Premium 版本，並設定地理複寫到美東資料中心，這可能在同一天都可完成。花了不到 40 分鐘，可將一個 32 GB 的資料庫，從美國中南部完全複製到美東。
- 【轉移日】於美東創建名稱與美國中南部對應的 Blob Containers (我們沒有選擇移轉 Blob 資料，但你可以這麼做)。
- 部署新的 Web 和 Worker 角色到美東，並將美東的 DB 和 Blob Storage 指向新的部署。
- 於新環境中設定 SSL 憑證。
- 《停機時間開始》將舊的 Web 和新的 Web 都保持離線，我們於應用程式進行設定，顯示網站正在維護中。只有管理員可以正常進出 website / API。
- 更改 DNS 指向新的網站 IP 位置。
- 於舊資料中心部署新的程式碼，透過 connection strings 將 DB 和 Blob 指到新資料中心。
- 設置美東 DB，允許從美國中南部的 IP 位置連線 (可能不需要)。
- 將美國中南部資料庫設置新的部署 (於 staging 環境) 為離線模式，和 prod 環境交替。
- 停止 DB 作用中地理複寫功能 (連續複寫關係的終止)。
- 將美國中南部 DB 設成 Read-Only 模式。
- 於複製完成後將美東地區 DB 設成 read / write 模式 (非必要)。
- 《停機時間結束》於美國中南部和美東地區的資料中心重新啟用兩個 website / API。
- 於新的 DB 上設置 Azure DB 自動備份服務。
- 待 DNS 複製已於世界各地完成，刪除美國中南部地應用程式伺服器。
以下為客戶完成此偉大工作後的經驗談：
「轉移非常順利，我們停機約 1 小時，其餘大部分時間是在等待我們的新程式碼部署，配置更新和 prod / staging 的互換。中止 Azure DB 的複製和改變 read / write 模式是相當簡單的過程。」