2019 年 2 月

第 34 卷,第 2 期

本文章是由機器翻譯。

[Azure]

在 Azure 上建置及部署具備高可用性和復原的解決方案

藉由Srikantan Sankaran

這篇文章中所討論之技術的一些目前為預覽版。所有的資訊有可能變更。

組織近來有全球支援,並期望他們任務關鍵性的應用程式觸及使用者跨多個地理位置。在這類組織的 IT 人員達成這些預期,不足的壓力,而且其成功與否取決於程度其應用程式 」 和 「 平台的架構和建置來處理該目標的複雜性。Microsoft Azure 提供許多服務和功能,提供幾乎周全的實作,以處理相關的需求,是否會涉及啟用異地複寫服務和資料,延遲使用者要求的路由服務更接近使用者或提供無縫式的應用程式容錯移轉至其他區域在災害發生時。在本文中我將看看幾個這些目標,並討論如何使用 Azure,實作高可用性與恢復功能的全球化應用程式。

我使用 MVC 和 Web API 應用程式所組成的三層式解決方案來說明建置及部署高可用性與恢復功能的應用程式,在 Azure 中的重要層面。若要擷取到他的家人,就會傳遞至 API 層級,接著將資料保存到異地複寫 Cosmos DB 資料庫相關的基本資訊的使用者存取應用程式。應用程式部署主動-主動跨多個區域,以確保針對區域性中斷時提供恢復功能。在區域內,它會部署在可用性區域來防禦資料中心的失敗 (bit.ly/2zXlRll)。資料庫已啟用多重區域寫入功能 (bit.ly/2zV6OI0),確保使用者可以寫入和讀取資料,從資料庫接近其點的存取權,以將延遲降到最低 (bit.ly/2QRr1Il).

解決方案的架構

[圖 1代表方案的架構。Azure Service Fabric 裝載封裝為 Docker 容器中,適用於 Linux 的應用程式元件,提供協調流程功能,並確保的可用性和可靠性的應用程式。有兩個區域的 Service Fabric 叢集部署到每個兩個 Azure 區域,在東南亞和美國東部 2。區域備援的 Azure Load Balancer 會用來循環配置資源,因此兩個可用性區域中每個區域之間的要求。

解決方案架構
[圖 1 解決方案架構

Azure 的前端服務 (仍處於公開預覽狀態) 使用者會將要求導向負載平衡端點的其中一個跨兩個區域中,根據延遲最少的路徑。它也提供應用程式或整個資料中心停機的其中一個區域,將導向至其他區域中的端點的要求時的恢復功能。

應用程式中使用的 Azure Cosmos DB 資料庫會是跨兩個 Azure 區域異地複寫,並設定多區域寫入。因此,資料會寫入來自每個區域中的 API 服務會寫入至該區域的 Cosmos DB 集合。

Azure DevOps 是應用程式的來源的程式碼存放庫。Azure 的管線用來建置應用程式,這些檔案封裝為 Docker 容器並上傳至 Docker 中樞登錄中。

在裝載此解決方案的組織的 IT 原則會禁止透過公用網際網路到 Service Fabric 叢集的系統管理存取權。使用 Jenkins 部署在 Azure 虛擬網路內實作持續傳遞 (CD) 管線。它會分別從 Git 存放庫,Azure DevOps 和 Docker Hub 提取的部署套件和容器,並應用程式部署到兩個區域中的 Service Fabric 叢集。

Service Fabric 叢集部署到每個區域是由兩個節點類型所組成。主要節點類型執行的 Service Fabric 平台服務,並會公開管理端點,使用內部負載平衡器。第二個節點類型會執行使用 Docker 容器封裝的 MVC 和 Web API 應用程式。公開的負載平衡器會從透過網際網路存取應用程式的終端使用者的要求路由傳送。

(未顯示在圖表中) 的第三個 Azure Load Balancer 用於此架構中,以允許輸出呼叫網際網路從叢集下載的 Service Fabric 平台元件。設定內部負載平衡器沒有公開端點,而且無法連線到網際網路。而不需要建立此額外公用負載平衡器的輸出連線能力,Service Fabric 叢集無法設定 (bit.ly/2A0VBpp)。

請注意,標準 SKU 的 Azure Load Balancer 和 Public IP 位址資源單獨支援部署至 Azure 可用性區域,把出的基本 SKU,則否。

Azure Service Fabric 會利用區域性部署為基礎的 Azure 虛擬機器擴展集 (VMSS) 資源的能力。 

開發應用程式

有兩個與這篇文章共用的 Visual Studio 2017 方案檔:

• censusapp.sln:ASP.NET Core 2.0 MVC 應用程式。

• censusapi.sln:ASP.NET Core 2.0 的 Web API 應用程式。

請記住,雖然此範例應用程式已使用 ASP.NET Core 2.0 所建置,它很可能使用其他技術,例如 Node.js、 PHP 等等建立 Web 應用程式。此外,與這篇文章共用的範例應用程式不會實作任何編碼的最佳作法。其目的是只是為了說明選取設計實作詳細資料。

MVC 應用程式會實作可讓使用者提交人口普查資料,並顯示該資料的 UI。它會在 Service Fabric 中使用服務探索功能來呼叫 REST API,將資料保存在 Azure Cosmos DB。API 專案會使用 Cosmos DB SDK,實作連線到以讀取和寫入資料的資料庫位置的優先順序的清單。部署至 「 南部 」 東亞區域應用程式會將此區域為"priority 1 」 和 「 美國東部 2 」 優先順序 2 」。 美國東部 2 區域部署,它會是反向。因此,會有兩個不同的容器映像,Web API 專案,分別用於部署到個別的區域。容器映像的 MVC 專案會相同,不論它已部署的 Azure 區域。

下列程式碼片段顯示的優先順序的清單的位置新增到 Cosmos DB 的方式,以及如何設定應用程式中的多區域寫入:

ConnectionPolicy policy = new ConnectionPolicy
  {
    ConnectionMode = ConnectionMode.Direct,
    ConnectionProtocol = Protocol.Tcp,
    UseMultipleWriteLocations = true,
  };
policy.PreferredLocations.Add("East US 2");
policy.PreferredLocations.Add("South East Asia");
DocumentClient client = new DocumentClient(new Uri(this.accountEndpoint), 
  this.accountKey, policy);

Web API 專案會使用 「 Bogus 「 NuGet 封裝來產生虛構的資料。

Cosmos DB 連接字串和存取金鑰會儲存在與 Web API 專案的簡易性 appsettings.json 檔案。針對生產用途,它們可以改為儲存在 Azure 金鑰保存庫。請參閱我的文件 」 保護您敏感商務資訊與 Azure 金鑰保存庫 」 指引 (msdn.com/magazine/mt845653)。

啟用 Web 應用程式的 Docker 容器Visual Studio 2017 Tools for Docker 提供周全的實作,以啟用 ASP.NET 2.0 Web 應用程式適用於 Windows 和 Linux 容器。Visual Studio 2017 來 [啟用 Docker 支援] 中選取的專案上按一下滑鼠右鍵選項將 Docker 檔案加入至它。選取的專案上按一下滑鼠右鍵選項,「 啟用協調流程 」 會建立 Docker compose 檔案。

此解決方案中的應用程式封裝適用於 Docker Linux 容器。稍加編輯所進行的 Docker compose 檔案,以新增應用程式 (連接埠 80 上存取的 MVC 應用程式和 Web API 的連接埠 5002 VMSS 節點) 部署時要使用的連接埠對應。

持續整合 (CI) Visual Studio 2017 方案檔案已簽入的 Azure DevOps Git 存放庫。Azure 的管線就會建立會執行 Docker compose 檔案的每個先前步驟中建立的 MVC 和 Web API 專案。這會建置 ASP.NET Core 2.0 應用程式,並建立 Docker 容器映像。

在管線中下一個步驟中的 Bash 指令碼用來標記容器映像,並將其推送至 Docker Hub。此步驟必須執行一次部署到 Azure 區域中東南亞,另一次部署到 Azure 區域 「 美國東部 2。同樣地,MVC 容器是相同無論到哪一個 Azure 區域部署它。[圖 2顯示若要完成此步驟中所建立的 CI 管線的快照集。

Azure DevOps Pipeline
[圖 2 Azure 的 DevOps 管線

封裝部署至 Service Fabric 應用程式我使用的 Yeoman 產生器產生的應用程式和服務資訊清單檔案,並將解決方案封裝的 Windows。您可以使用這項工具,在找到相關指引bit.ly/2zZ334n

單一應用程式封裝會建立該套件組合的 MVC 和 API 應用程式,為服務類型。在服務資訊清單檔案中,輸入在上一個步驟中上傳至 Docker Hub 的容器名稱。

請注意,Web API 專案的服務資訊清單會定義服務的 DNS 名稱應該符合在 MVC 專案的 appsettings.json 檔案中,要用於服務探索的值。

資訊清單中每個服務類型 (也就是 Web 和 API 專案) 的執行個體數目設為兩個。這會指示 Service Fabric 有兩個 alwayson 叢集中執行該服務類型的容器執行個體。這個數字可以修改以符合部署,或可設定為自動調整規模最小和最大範圍內。

服務資訊清單支援的放置條件約束。在下列片段中,放置條件約束被定義服務應該部署 Service Fabric 叢集中的節點型別名稱。如果未指定,會在所有的節點類型包括 Service Fabric 叢集中的主要節點類型,部署程式碼套件。不過,我想要只 Service Fabric 平台在託管服務的主要節點類型。

<ServiceTypes>
  <StatelessServiceType ServiceTypeName="censusapiType" 
    UseImplicitHost="true">
<PlacementConstraints>(NodeTypeName==nt-sfazvm0) </PlacementConstraints>
  </StatelessServiceType>
</ServiceTypes>

(稍後討論) 來部署 Service Fabric 叢集的 Azure Resource Manager (ARM) 範本中所設定的節點型別名稱必須符合,在服務資訊清單的放置條件約束。

部署至 Service Fabric 應用程式

現在讓我們來建立 Service Fabric 叢集,然後再部署到它的 [應用程式封裝。

第一個步驟是佈建 Cosmos DB 資料庫,您可以從 Azure 入口網站執行。開始在東南亞建立資料庫並啟用異地複寫到美國東部 2 區域。在精靈中選取 [啟用多重區域寫入 」 選項。

我保留工作階段一致性設定,也就是 Cosmos DB 資料庫的預設值和預設結構描述中設定該索引的所有屬性。您可以只選取特定屬性編製索引,如果您偏好,根據需要來查詢資料。

若要處理產生的啟用多重主機寫入任何可能發生衝突,我會使用預設值,「 最後寫入者獲勝衝突解決 」 原則。

接下來,您佈建 Service Fabric 叢集使用 ARM 範本 (bit.ly/2swVkI5bit.ly/2rBvFfi)。範本 SF-Std-ELB-ZonalDeployment.Json 會部署到現有的虛擬網路的兩個區域叢集。有特定必要條件,若要執行此範本。

首先,使用 Azure Key Vault 中儲存在叢集中的節點對節點安全性的憑證。此步驟中的憑證指紋,金鑰保存庫 URL 和憑證 URL 需要在 ARM 範本的 Parameters 區段中輸入中所示**[圖 3**。這必須為每個區域分開,因為 Service Fabric 叢集和其所使用的金鑰保存庫應該位於相同的區域。

[圖 3 儲存憑證指紋,而 Azure 金鑰保存庫 URL 和憑證 URL

"certificateThumbprint": {
      "type": "string",
      "defaultValue": "<Certificate Thumb print>
    },
    "sourceVaultValue": {
        "type": "string",
        "defaultValue": "/subscriptions/<SubscriptionId>/resourceGroups/
          lpvmvmssrg/providers/Microsoft.KeyVault/vaults/<vaultname>”
    },
    "certificateUrlValue": {
        "type": "string",
        "defaultValue": "https://<vaultname>.vault.azure.net/secrets/
          soloclustercert/<GUID>
        }
  }

第二,會產生自我簽署的憑證,使用 Open SSL。在 ARM 範本的 Parameters 區段中輸入此憑證的指紋:

"clientCertificateStoreValue": {
      "type": "string",
      "defaultValue": "<Client certificate thumbprint
    },

此憑證用於 Jenkins 中,以連線到 Service Fabric 叢集部署應用程式。請參閱bit.ly/2GfLHG0如需詳細資訊。

請注意,本文會使用自我簽署的憑證供說明。生產環境部署中,您會使用 Azure 認證安全地連線到管理端點和部署應用程式。

如需 Service Fabric 安全性的詳細資訊,請參閱 < bit.ly/2CeEzpibit.ly/2SR1E73

用於 MVC 應用程式和 Web API 必須使用正確的連接埠號碼和要求路徑,設為使用 HTTP,如中所示的負載平衡器健康情況探查**[圖4**。

[圖 4 設定的連接埠和要求路徑

{
    "name": "SFContainerProbe1",
    "properties": {
      "protocol": "Http",
      "port": 5002,
      "requestPath": "/api/family",
      "intervalInSeconds": 5,
      "numberOfProbes": 2
    }
  },
    {
    "name": "SFContainerProbe2",
    "properties": {
      "intervalInSeconds": 5,
      "numberOfProbes": 2,
      "port": 80,
      "requestPath": "/",
      "protocol": " Http "
    }
  }

以下是在 ARM 範本中,區域性部署特有的其他主要組態:

• 標準 SKU 會選擇在叢集中的所有負載平衡器。

• 標準 SKU 會選擇公用 IP 位址資源。

• 可用性區域屬性必須指定。這是區域性的部署,因為單一區域中的屬性值指定。針對區域性 SF Cluster 1 在東南亞,這個值會是"1"和區域性 SF Cluster 2 在東南亞,這個值會是"2"。

•"SinglePlacementGroup"的屬性設定為"true"。

• 若要啟用在叢集中,Service Fabric DNS 服務探索,必須啟用。

[圖 5顯示這些 ARM 範本中的設定方式。確認成功部署範本和所示的服務**[圖 5**會顯示在 Azure 入口網站中。

區域性部署 ARM 範本中所使用的 VMSS 資源
[圖 5 VMSS 資源用於區域性部署 ARM 範本

請注意,Azure 可用性區域尚無法使用所有 Azure 區域中。此外,功能已公開上市 (GA) 某些區域中,但只在其他預覽狀態。

現在讓我們先連接到 Service Fabric 叢集。內部負載平衡器後方部署 Service Fabric 管理端點。因此,若要存取 Service Fabric Explorer,若要部署應用程式,部署執行 Windows Server 2016 的跳躍方塊虛擬機器 (VM),在相同的虛擬網路與 Service Fabric 叢集,或到不同虛擬網路具有的對等互連叢集。

Service Fabric 系統管理員用戶端 (稍早建立的自我簽署憑證),將憑證複製至使用者憑證存放區,在跳躍方塊 VM。當啟動 Service Fabric Explorer,請選取 [出現提示時,此憑證。

接下來,佈建 Jenkins 以部署應用程式。在本文案例中,我將使用 Jenkins 和 Service Fabric 外掛程式執行的 Docker 容器映像。此映像部署到 Ubuntu VM 在 Azure 中執行的 Service Fabric 叢集相同的虛擬網路中。

您會發現更多有關下載、 安裝和設定在容器映像所需的步驟bit.ly/2RRRt1Q

若要準備連線至 Service Fabric 叢集的 Jenkins,我可以執行下列額外步驟:

• 複製憑證的 Service Fabric 系統管理用戶端 (稍早建立的自我簽署憑證) Jenkins VM 上的主目錄,使用如 WinSCP 的工具。

• 啟動此 VM 上的 Jenkins 容器,並執行"docker exec"命令,以將此憑證複製到 Jenkins 主目錄,在容器內。

啟動 Jenkins,並登入若要設定 Service Fabric 外掛程式 http://<Public-IP-of-JenkinsVM>:8080。

在說明的步驟,若要設定 Service Fabric 外掛程式的 Jenkins bit.ly/2UBVhWV。用來執行應用程式部署至一個區域的叢集的 [Post 建置動作] 設定所示**[圖 6**。新增第二個區域叢集,同樣的道理的其他文章建置 」 動作。

Service Fabric jenkins 外掛程式
[圖 6 Service Fabric jenkins 外掛程式

手動觸發 Jenkins 組建作業選項,並確定後續觸發程序動作會順利完成。從跳躍方塊 VM 中,啟動 Service Fabric Explorer,若要確認應用程式部署到這兩個區域的叢集。[圖 7應用程式部署之後,會顯示 Service Fabric Explorer。

Service Fabric Explorer 中管理端點
[圖 7 的 Service Fabric Explorer 中的管理端點

重複上述步驟來部署第二個 Azure 區域。請確定 API 專案的服務資訊清單檔,讓它指向正確的容器映像,適用於此區域的 API 服務的修改。您應該記得 API 服務的每個的兩個容器映像會有不同的區域的優先順序,當連接到 Cosmos DB 和實作多區域寫入。

執行應用程式

若要顯示為區域 1 部署的應用程式,請啟動下列 Url:

• http://<Public-IP-Address-LB Region1 > 啟動 MVC 應用程式

• http://<Public-IP-Address-LB Region1 >: 5002/api/系列會直接啟動 Web API。MVC 專案呼叫 API 就內部而言,使用服務探索。

另一組 Url 的會是適用於區域 2。

[圖 8顯示透過 Azure 前端服務所公開的端點存取的應用程式頁面。您會發現呼叫 DataOrigin 指出從中插入記錄,Cosmos DB 資料庫的寫入區域的名稱,並展示 Cosmos DB 的多重區域寫入功能的資料行。

範例人口普查應用程式
[圖 8 範例人口普查應用程式

佈建 Azure 前端服務

使用 Azure 入口網站來佈建 Azure 前端服務,並新增 MVC 和 Web API 的應用程式的公開端點,如後結束,前端服務。

其中一個後端端點不可以存取,因為其中一個中斷的影響,因為區域,或當應用程式會取得沒有回應,後續的要求會被導向至另一個狀況良好的一個時,前端服務中設定的健康情況探查請確認。中的組態設定**[圖 9**顯示兩個區域中的應用程式端點如何對應到前端服務所公開的單一端點。雖然 Azure 流量管理員無法使用或者以 Azure 大門,我選擇實作這裡的第二個,因為它提供層 7 反向 Proxy、 SSL 終止和路由要求,這類應用程式所需。

Azure 的前端組態
[圖 9 Azure 前端組態

您會發現更多有關建立 Web 應用程式全域大門bit.ly/2QXRkwu

總結

在本文中我將討論 Azure Service Fabric 如何可以用來封裝及部署 Docker 容器功能的應用程式及實作協調流程和微服務架構的基礎的服務探索功能。在 Azure 中的可用性區域的支援,我可以部署 2 個區域的 Service Fabric 叢集跨越區域中的多個資料中心,以便排除的資料中心故障影響。

若要增加應用程式的範圍,我應用程式部署到多個 Azure 區域,並利用多重區域 Azure Cosmos DB 中撰寫支援,這可確保不只是異地複寫的無狀態應用程式層,但資料庫也是真正分散式和複寫。最後,為了確保使用者在存取應用程式時會經歷最少的延遲,我實作了單一 Azure 前端服務的路由要求,以正確的應用程式端點。示範如何實作此架構以最少的中斷對業務,並確保會遵守安全性原則,我討論過 CI 和 CD 的做法可以實作,以及如何使用 Azure DevOps 服務及 Jenkins這些可以實行的公司網路的範圍內。

您可以下載範例應用程式,在bit.ly/2Lra9Dm。若要實作的範例應用程式所需的軟體,請參閱 「 軟體必要條件 」 的資訊。


Srikantan Sankaran是一個商業夥伴小組,印度班加羅爾以外的主體技術推廣者。他適用於許多在印度的 Isv,並且可幫助他們設計和部署他們在 Microsoft Azure 上的解決方案。與他連絡sansri@microsoft.com

感謝下列 Microsoft 技術專家來檢閱這篇文章:Sudhanva Huruli,Muni Pulipalyam


MSDN Magazine 論壇中的這篇文章的討論