雲端搬遷三步驟:應用程式如何無痛移轉到 Google Cloud

情境描述

一家虛構漫畫發行公司­ – Magenicons 決定要對公司的 IT 設備做現代化升級,以增加系統的可靠性,同時節省成本的支出。IT 部門的員工認為採用雲端計算可以在 IT 基礎架構和應用程式方面提升靈活性。公司選擇一個既有的基於內網的費用報告應用程式做為雲端遷移策略的 POC 前期功能驗證

背景資料

費用報告應用程式是一個以網站為基礎的標準二層式架構,依靠本地的 Microsoft IIS server,並在內部部屬 Microsoft SQL server 以分散式方式儲存資料。第二個本地的 IIS server 也提供 auditing 服務。透過本地的 AD 網域執行個體進行身分驗證後才能存取應用程式,同時應用程式的服務帳戶透過 SQL Server 的身份驗證來保護資料存取。

計畫達成方式

為了將風險最小化同時提升公司團隊雲端知識和經驗,Magenicons 希望分階段執行計畫,每個階段都有明確要完成的目標。這些目標會用來評估雲端運算對公司的長期可行性。GCP 因平台的強大功能和 Google 極佳的技術聲譽被選為雲端服務的供應商。

  • 階段1:使用 Google IaaS 基礎架構即服務將應用程式轉移到 GCE
    • 目標:GCE 可以使用最低的成本,結合 lift-and-shift 無痛轉移費用報告應用程式。特別的是,公司希望能夠盡量不修改現有應用程式碼,將應用程式移轉到雲端。
    • 必要條件:環境的設定,像是建立 GCP 和 Magenicons 公司內部之間的網路連線,將是現階段支援 lift-and-shift 無痛應用程式移轉的必要條件。
  • 階段2:透過雲端服務提高可用性 (HA)
    • 目標:一旦應用程式能成功在雲端運作後,Magenicons 公司希望增加 SQL Server 的高可用性,以降低應用程式可能停機的風險。AlwaysOn Availability Groups 是 SQL Server 建議的解決方案,讓使用者能夠配置抄寫副本,當故障發生就能夠自動轉移。GCP 支援 Windows Server Failoverr Clustering (WSFC) 和 SQL Server AlwaysOn Availability Groups。
  • 階段3:透過雲端服務進行災害恢復 (DR)
    • 目標:Magenicons 公司想藉由將內部部屬的 AD 擴展到雲端,進一步提升應用程式的可用性來改善 DR 計畫。在 DR 情況發生時,這提供了保護 AD 的成本效能考量選項。當公司的實體資料中心遇到停電或災難事故,在 GCP 中做為 AD DC 的 VM 主機仍能提供服務,會讓部署到雲端和本地端跟 AD 整合的應用程式不會受到影響。此外,在雲端一起佈署 AD 服務的應用程式,通常也會縮短網路的延遲,進而改善系統回應時間。

當前的本地部屬系統結構

費用報告系統是使用標準 ASP.NET MVC 應用程式架構作為內部網路環境。該應用程序部署在 IIS 服務的網站,使用已經加入 AD 網域的 Windows 主機。系統保護透過 Windows 整合式驗證來控管所有應用程式的存取。連接 SQL Server 的方式也是相當標準,使用 SQL Server 身分認證和網域服務帳戶的使用者 ID 和密碼。

最終目標的雲端系統架構

最終的目標系統架構應該與原始的本地系統類似,因為它將 GCP 視為本地資料中心的延伸,透過 VPN 虛擬私人網路存取,並具有 SQL Server HA 高可用和 AD DR 災難復原的附加功能。

操作指南

實現階段一目標

第一階段的目標想要透過 lift-and-shift 無痛轉移費用報告應用程式到雲端,有三個主要的工作必須完成

1.為 Project 專案建立適合的 GCP 網路
2.從 Magenicons 公司建立 VPN 連結到 GCP 雲端
3.建立需要的 VM 執行個體支援應用程式
4.進行必要的配置或程式碼的修改,以支援 lift-and-shift 無痛轉移

建立 GCP 網路

GCP 網絡將 VM 彼此連接並連接到外部網路,讓使用者可以區隔他們的網段,建立防火牆規則來控制存取,以及建立靜態路由轉發流量到特地目的地。隨著 Project 專案在不同階段的發展,將會需要這些功能。關於 GCP 網路的教學細節可參考此連結

重要提醒:

可以使用任何支援類型的子網路模式 (自動或自訂) 來實現第一階段的目標。然而,為了安裝 SQL Server AlwaysOn Availability Groups,必須使用自訂的子網路,第二階段的詳細內容說明如下。因此,如果終究會安裝此功能,強烈建議從一開始就建立自訂子網路,避免不必要的修改或重建工作。

建立 site-to-site VPN

建立 VPN 是很直覺的動作,專案團隊不會遇到任何問題,只要根據 Google documentation 設定,VPN 功能就可以在一天內上線運作。

建立 VMs 支援雲端系統架構

可透過以下三種方式在 Compute Engine 上建立 VMs:

  1. point-and-click 點選介面:訂閱者入口網站中的Google Cloud Console
  2. REST API
  3. 命令提示字元介面 (CLI),在 Google 的 case 中稱為 gcloud 命令提示字元介面

由於團隊了解自動化是雲端運算長期可持續性的關鍵因素,基於程式碼的方法,選擇 gcloud 命令提示字元介面成為他們的首選。

使用 CLI 是相當容易的,只要從 Google 下載 gcloud 命令提示字元介面並按照文件操作即可。以下提供建立一個 Windows Server 執行個體的截圖。

以下是 project 各階段所需的 VMs 及 roles:

  • 階段1
    • IIS Web Server
    • SQL Server
  • 階段2
    • 一個額外的 SQL Server 執行個體作為 SQL Server Availability Group 抄寫副本的一部分
  • 階段3
    • 在 GCP 運作的一個 AD Domain Controller 網域主控站執行個體,能夠完全複製本地 AD Domain Controller 網域主控站的資料

除了上述提到關於建立 VM 的方法,GCP 還提供了另一個在建立 VM instances 時能省下大量時間的替代方案:Google Cloud Launcher。Google Cloud Launcher 是一個 marketplace 市集,準備好讓第三方的夥伴可以開發堆疊、解決方案和服務。如果工作類型符合可用的功能,只需要簡單地點擊幾下便可建立需要的 VM。

對於第一階段的開發人員,需要一個具備 ASP.NET 4.6 的 IIS 網頁主機和安裝支援的 .NET Framework 版本。一般建立 VM 的方法,必須建立包含 OS VM 虛擬主機,以及手動安裝各種 .NET Framework 和 ASP.NET 的元件。然而使用 Cloud Launcher for ASP.NET,可以讓過程變得相當簡單。

  1. 前往以下連接:https://console.cloud.google.com/launcher
  2. 在搜尋列輸入 asp.net,並點選搜尋結果來啟動 Cloud Launcher for ASP.NET Framework。

  1. 填寫部署的規格細節,像是機器名稱、磁碟、CPU 大小

  1. 只需要幾分鐘,想要的 VM 虛擬主機和相關元件就會產生

至於 SQL Server instance 的建立,團隊使用以下的 gcloud 命令提示字元介面來產生映像檔:

The gcloud command line interface (CLI) compute instances create “magcustom-sql1” –machine-type “n1-standard-4” –zone “us-central1-a” –subnet “wsfcsubnet1” –image-project windows-sql-cloud –image-family sql-ent-2016-win-2016–boot-disk-size “200” –boot-disk-type “pd-ssd” –private-network-ip=10.201.1.3 –can-ip-forward

提醒:在 project 的第二階段,當團隊要建立 SQL Server HA 時,需要設立特定的網路路由 (詳細內容請參考第二階段)。因此這個 VM instance 的內部 IP address 需要依據第 2 階段中所描述的網絡設計。這是’private-network-ip’ 參數在建立 instance 時被指定採用內部網路 IP address 的原因。如果此參數用於指定特定的 IP address,之後不能更改靜態 IP address,可能會造成失去 instance 存取權限的風險。使用 CLI 部署 Cloud Launcher 解決方案會受 Cloud Launcher 服務條款和相關費用的約束。

程式碼部屬

在配置並正確設定 IIS VM 後,團隊的下一個任務就是在 instance 上部屬程式碼。ˊ這必須透過 Microsoft 眾多產品之一來完成:Web Deploy。

Web Deploy 是一個成熟、可擴展的 client-server 工具,在開發人員或 SysOps 的 workspace 工作區之間,用來將網站內容部署到 IIS instance 執行個體上。實際的運作機制已在 ASP.NET 社群中詳細記載,且超出了本文件的範圍,但可以在此文當中看到這項技術的簡介。

確保安全性的最佳作法,就是將包含敏感的設定檔案永遠加密,例如:憑證或其他的私密資料。如此可以改善安全性,即使駭客獲得您的設定檔案,仍能讓未經授權的存取變得困難,同樣的原則也適用於這個應用程式。

.NET Framework 包含兩個受保護內建的配置提供者,可以用來加密配置文件。RsaProtectedConfigurationProvider class 的種類使用 RSACryptoServiceProvider來加密設定的部分,而 DpapiProtectedConfigurationProvider class 的種類使用 Windows Data Protection API (DPAPI) 來加密設定的部分。但是,考量費用報告應用程式需要整合安全性和模擬的使用情況,RSACryptoServiceProvider 並不是個合適的選擇,因為它需要授予 RSA Key Container 密鑰容器存取權限,用於大量使用者群組的加密。

敏感資料的加密是部署過程的一部分

使用 DpapiProtectedConfigurationProvider 的其中一個主要的缺點,因為它不是 Web Deploy 預設的配置提供者,因此在部署的過程中無法替敏感資料自動加密。在經過一番研究之後,Magenicons 的開發人員提出一個解決方案,只要呼叫一次 MSBuild,就可以 (在部署主機) 建立、部署和加密敏感的資料。這個解決方要求利用 PowerShell 的 Invoke-command cmdlet 命令提示字元,它可以在本地或遠端電腦執行命令。結合此能力與 MSBuild 的嵌入式腳本的擴展功能,用於各種建構和部署事件 (於 MSDeployPublish 之後),團隊能夠優化建構/部屬的程序,能夠增強應用程式的安全性。

階段二

建立 SQL Server AlwaysOn Availability Groups 高可用性群組

企業級 SQL Server 的工作負載需要支援 HA 高可用和 DR 災難復原。AlwaysOn Availability Group 是 SQL Server 旗艦版的 HA/DR 解決辦法。這項技術提供 server 熱備援以及為資料庫提供資料抄寫複本。AlwaysOn 還針對一個或多個次要複本,提供唯讀的存取權限,在報表主機和其他唯讀的使用情境下,可以減輕主要資料庫的負擔。

基於上述的原因,Magenicons 公司的 IT 員工選擇這項技術來達成專案 HA 高可用的需求。剛好 Google 近期在 Compute Engine 新增對 SQL Server AlwaysOn Availability Group 的支援。

在計畫安裝 AlwaysOn Availability Groups 時,有幾個要求需要特別注意:

1. 目前 AlwaysOn Availability Groups 只能在 GCP 的子網路類型中安裝和支援,它無法在 legacy 舊版網路中安裝。此外,子望路必須在處於自定義模式,不能是預設的自動模式 (兩種網路類型的差異和子網路模式的詳細說明可參考此文)。
2. AlwaysOn Availability Group 中的每個節點都必須在不同的子網路中,因此需要設置至少兩個子網路。
3.每個資料庫的抄寫複本由 WSFC cluster 故障移轉叢集服務不同節點上的 SQL Server 的 instance 託管。
4.要實現雙節點的故障轉移叢集服務,必須準備四個靜態 IP address 用來配置給 cluster 叢集服務本身和 Availability Group Listener 監聽器。其中有一個很重要的點,這些指定的 IP address 必須不同於 cluster 節點實際 IP address 用到網段的範圍,但仍可以利用適當的子網路遮罩定址來找到。

讓我們來看一個簡單的例子:

如果子網路是 10.0.1.0/24,VM 的靜態 IP 和子網路遮罩被設為 10.0.1.4 和 d 255.255.0.0 (/16)。從 VM 方面來看,可循址的子網路是 10.0.0.0/16。因此,必須選擇 VM 所在的 10.0.1.0/24 子網路之外的 IP address,像是挑選 10.0.2.4 當成 listener的 IP address,但是仍然可以從 guest 端找得到,因為使用更廣的子網路遮罩。必須對 WSFC 和 Availability Group Listener 需要的所有 IP address 實施這個要求。下表提供了整個設定所需的簡單網路位址範例,逐步教學說明可參考此文。AlwaysOn Installation 安裝的網路地址範例:

subnetworks IP addresses ranges
wsfcsubnet1 10.201.1.32/29
wsfcsubnet2 10.202.1.32/29

 

Node Instances subnetworks WSFC Availability Group Listener
magcustom-sql 1 10.201.1.34 wsfcsubnet1 magcustom-wsfc 10.201.1.50 magcustom-as 10.201.1.51
magcustom-sql 2 10.202.1.34 wsfcsubnet2 10.202.1.51 10.202.1.51

5.最後,如逐步教學所說的,為了讓 listener 和 cluster 可以連到叢集節點 instance,針對 cluster 和 availability group listener 需要設定網路路由。想要建立網路路由只需要依照教學中所提供的範例命令操作即可 (依據自己的需要修改,以符合需要的網路結構)。

階段三

設定 AD 複寫到雲端做為備援

作為整個 project 的基本目標,GCP 中的網路應該被視為 Magenicons 本地網絡的擴展,應用程式才可以無縫接軌從地端移轉到雲端。只要兩站台之間的 VPN 設定成功,就可以像在外點分公司的辦公室一樣,在 GCP 中建立 AD DC 網域主控站和 DNS 名稱伺服器。一旦設定好開始運作,在 GCP 中運行的 application 應用程式就不需要透過 internet 外部網路進行身分認證和名稱解析,這會提高系統的性能。

下圖是動線的描繪:

利用 Compute Engine 建立 AD DC 的過程和其他 VM role 很類似。第一項任務是藉由下列的 gcloud 命令來產生 VM instance:

gcloud compute instances create your-dc-machine-name –machine-type n1-standard-1 \ –boot-disk-type pd-ssd –image-project windows-cloud \ –image-family windows-2016 –boot-disk-size 200GB \ –zone us-central1-a –subnet wsfcsubnet3 –private-network-ip=10.2.0.100

一旦 VM 建立完成,接著需要執行 site to site 站對站或 intra-site 站台間的網域資料複製工作:

在本地的 DC 上

  • 在 GCP 建立一個新的站台

 

  • 在 Active Directory Sites and Services 網域站台和服務增加 GCP 子網路

 

在 GCP AD DC 網域主控站操作

 

  • 將預設的 DNS IP 更改為指向現有本地 DC

  • 將 VM 加到本地網域

 

  • 安裝 Active Directory

 

  • 將 VM 升級成為網域主控站

 

  • 重新開機之後,修改 DNS 設定,以便將 VM 指向自己來進行 DNS 名稱查詢

有關 AD Replication 網域複寫,在各種網路拓樸中運作的細節 (包含這裡使用的),可參考此文件

結語

在專案完成之後,三個階段都成功完成而且實現了想要的目標。Magenicons IT 員工發現利用雲端的經驗是相當直覺且有效率的。GCP 的入口網站簡單明瞭。完成各種任務所需要的主題文件,在 Google 網站和支援 (有提供免費和付費的版本) 有很多的資源且容易上手。除了 SQL Server AlwaysOn 要求的技術文件,需要花一些時間消化和做實驗測試之外,員工在專案上並沒有遇到任何阻礙。最令人印象深刻的是,除了修改 web.config 設定檔的應用程式連接字串 (為了連接到新的 HA SQL Server instance),不需要修改任何一行程式碼,就能夠將系統部署到雲端。

(原文翻譯自 Google Cloud)

相關文章

[手把手教學] 如何在 Google Cloud 上跑 Windows Server 容錯移轉叢集 (一)

開發 Windows 應用更方便!GCP 全面支援 ASP.NET


連絡「GCP 專門家」