案例分享:遷移 Azure 服務至新區域資料中心的過程及步驟

案例分享:遷移 Azure 服務至新區域資料中心的過程及步驟

  • Comments 6
  • Likes

Azure Regions

最近我們接到了需要將資料中心從美國中南部移到美東的客戶需求,該工作包括計劃一個適合的 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、導出資料、複製文件,並在美東地區恢復。

首選是「啟用地理複寫功能」,原因是:

  1. 最短的停機時間。
  2. 於轉移過程中不會有資料遺失。
  3. 可使用 Rollback。
  4. 若執行失敗,於美國中南部的資料中心重新啟用是很簡單的。
  5. 總成本最低。
  6. 可符合未來計劃 (升級到Premium SKU)。

比較值得注意的是,該服務是預覽版,但這被認為是一個容忍的風險。於分析歷史資料後,決定一個 P1 就足以滿足他們的需求。另外不可避免的風險是,複製過程是否會佔用過多資源,但這被視為是特殊事件,畢竟可預期的資源需求不高,故最後還是決定保有 P1,並隨時準備升級到 P2。

於容量規劃過程中,客戶是參考「變更資料庫服務層和效能層級」決定 SQL Azure 資料庫的版本。

執行

客戶必須註冊為 Premium SKU 預覽,這必須通過 portal 花幾秒鐘的時間完成。

一旦簽約,該資料庫可升級到 Premium,請參閱「更改資料庫服務層級和性能水平」。以下公式實際上是相當準確的,預估升級時間為 12 小時:

3 * [ 5分鐘 + 資料庫大小 / (150 MB/分鐘) ]

接下來的步驟是建立理想中的複製區域,即美國東地區,這部分較難預估需要多長時間,也較難預估即將開展的副本所需資源。這些步驟可參考「設定作用中地理複寫 (連續複製)」。

值得注意的是,這個執行計劃是基於程式碼間的部署,若過程是純技術性的,大多於 24 小時內完成。但客戶選擇多等一兩天再執行計畫的下一步,其理由是完成特定程式碼的修改,而發生在現有的拓撲不是在一個新的數據中心。他們關心DDL更改是否會被複製。所有的更改都將被複製,除了於更新主資料庫後必要的更動,像是登入設定等。這些必須在每個環境中進行,而使用者的創建可在 source 完成,詳情請參見「作用中地理複寫的安全性」,將具體說明登入相關議題。

最後一步是切換到新的區域。以下步驟是客戶特別分享的經驗談,提供給未來可能負責此工作的 IT 專業人員們。對於終止作用中地理複寫,可參考「終止連續複製關聯性」一文。

  1. 提前一週升級資料庫至 Premium 版本,並設定地理複寫到美東資料中心,這可能在同一天都可完成。花了不到 40 分鐘,可將一個 32 GB 的資料庫,從美國中南部完全複製到美東。
  2. 【轉移日】於美東創建名稱與美國中南部對應的 Blob Containers (我們沒有選擇移轉 Blob 資料,但你可以這麼做)。
  3. 部署新的 Web 和 Worker 角色到美東,並將美東的 DB 和 Blob Storage 指向新的部署。
  4. 於新環境中設定 SSL 憑證。
  5. 《停機時間開始》將舊的 Web 和新的 Web 都保持離線,我們於應用程式進行設定,顯示網站正在維護中。只有管理員可以正常進出 website / API。
  6. 更改 DNS 指向新的網站 IP 位置。
  7. 於舊資料中心部署新的程式碼,透過 connection strings 將 DB 和 Blob 指到新資料中心。
  8. 設置美東 DB,允許從美國中南部的 IP 位置連線 (可能不需要)。
  9. 將美國中南部資料庫設置新的部署 (於 staging 環境) 為離線模式,和 prod 環境交替。
  10. 停止 DB 作用中地理複寫功能 (連續複寫關係的終止)。
  11. 將美國中南部 DB 設成 Read-Only 模式。
  12. 於複製完成後將美東地區 DB 設成 read / write 模式 (非必要)。
  13. 《停機時間結束》於美國中南部和美東地區的資料中心重新啟用兩個 website / API。
  14. 於新的 DB 上設置 Azure DB 自動備份服務。
  15. 待 DNS 複製已於世界各地完成,刪除美國中南部地應用程式伺服器。

以下為客戶完成此偉大工作後的經驗談:

「轉移非常順利,我們停機約 1 小時,其餘大部分時間是在等待我們的新程式碼部署,配置更新和 prod / staging 的互換。中止 Azure DB 的複製和改變 read / write 模式是相當簡單的過程。」

原文發表於 Migrating Azure Service to new regions

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment