此參考架構示範如何使用 Linux 上的 Apache Cassandra，針對數據層部署虛擬機（VM）和針對 多層 式應用程式設定的虛擬網路。
架構
工作流程
架構具有下列元件。
一般
資源群組。 資源群組 可用來將 Azure 資源分組，以便依存留期、擁有者或其他準則加以管理。
可用性區域。 可用性區域 是 Azure 區域內的實體位置。 每個區域都包含一或多個具有獨立電源、冷卻和網路的數據中心。 藉由將 VM 放在區域之間，應用程式就會在區域內復原失敗。
網路和負載平衡
虛擬網路和子網。 每個 Azure VM 都會部署到可分割成子網的虛擬網路。 為每個層建立個別的子網。
應用程式閘道。 應用程式閘道 是第 7 層負載平衡器。 在此架構中，它會將 HTTP 要求路由傳送至 Web 前端。 應用程式閘道 也提供 Web 應用程式防火牆 （WAF），可保護應用程式免於常見的惡意探索和弱點。
負載平衡器。 使用 Azure Standard Load Balancer 將網路流量從 Web 層散發到商務層。
網路安全性群組 (NSG)。 使用 NSG 來限制虛擬網路內的網路流量。 例如，在此處顯示的三層架構中，資料庫層不接受來自 Web 前端的流量，只接受來自商務層和管理子網的流量。
DDoS 保護。 雖然 Azure 平臺提供基本保護，以防止分散式阻斷服務 （DDoS） 攻擊，但我們建議使用 Azure DDoS 網路保護，其具有增強的 DDoS 風險降低功能。 請參閱安全性考慮。
Azure DNS。 Azure DNS 是 DNS 網域的裝載服務。 它會使用 Microsoft Azure 基礎結構提供名稱解析。 在 Azure 中裝載網域，即可使用與其他 Azure 服務相同的認證、API、工具和計費來管理 DNS 記錄。
虛擬機器
Apache Cassandra 資料庫。 藉由啟用複寫和故障轉移，在數據層提供高可用性。
OpsCenter。 部署 DataStax OpsCenter 之類的監視解決方案，以監視 Cassandra 叢集。
Jumpbox。 也稱為防禦主機。 網路上系統管理員用來連線到其他 VM 的安全 VM。 Jumpbox 具有 NSG，只允許來自安全清單上公用 IP 位址的遠端流量。 NSG 應該允許遠端桌面 （RDP） 流量。
建議
您的需求可能與此處所述的架構不同。 使用這些建議作為起點。
虛擬機器
如需設定 VM 的建議，請參閱 在 Azure 上執行 Linux VM。
虛擬網路
當您建立虛擬網路時，請判斷每個子網中的資源需要多少個IP位址。 使用 CIDR 表示法，指定子網掩碼和網路位址範圍足以容納所需的 IP 位址。 使用落在標準 私人IP位址區塊內的位址空間，也就是10.0.0.0.0/8、172.16.0.0/12和192.168.0.0/16。
選擇不會與內部部署網路重疊的位址範圍，以防稍後您需要在 VNet 與內部部署網路之間設定閘道。 建立 VNet 之後，就無法變更位址範圍。
設計具有功能和安全性需求的子網。 相同層級或角色中的所有 VM 都應該進入相同的子網，這可以是安全性界限。 如需設計 VNet 和子網的詳細資訊，請參閱規劃和設計 Azure 虛擬網絡。
應用程式閘道
如需設定 應用程式閘道 的相關信息，請參閱 應用程式閘道 組態概觀。
負載平衡器
請勿將 VM 直接公開至因特網。 相反地，請為每個 VM 提供私人 IP 位址。 用戶端會使用與 應用程式閘道 相關聯的IP位址進行連線。
定義負載平衡器規則，以將網路流量導向 VM。 例如，若要啟用 HTTP 流量，請建立規則，將埠 80 從前端組態對應至後端位址池上的埠 80。 當用戶端將 HTTP 要求傳送至埠 80 時，負載平衡器會使用 包含來源 IP 位址的哈希演算法 來選取後端 IP 位址。 用戶端要求會分散到所有 VM。
網路安全性群組
使用 NSG 規則來限制階層之間的流量。 例如，在上述的三層架構中，Web 層不會直接與資料庫層通訊。 若要強制執行此作業，資料庫層應該封鎖來自 Web 層子網的連入流量。
- 拒絕來自 VNet 的所有輸入流量。 （在
VIRTUAL_NETWORK規則中使用 標籤。 - 允許來自商務層子網的輸入流量。
- 允許來自資料庫層子網本身的輸入流量。 此規則允許資料庫 VM 之間的通訊，這是資料庫複寫和故障轉移所需的。
- 允許來自 jumpbox 子網的 SSH 流量（埠 22）。 此規則可讓系統管理員從 Jumpbox 連線到資料庫層。
建立優先順序高於第一個規則的規則 2 – 4，因此會覆寫規則。
Cassandra
我們建議 DataStax Enterprise 用於生產環境，但這些建議適用於任何 Cassandra 版本。 如需在 Azure 中執行 DataStax 的詳細資訊，請參閱 Azure 的 DataStax 企業部署指南。
以機架感知模式設定節點。 將容錯網域對應至檔案中的 cassandra-rackdc.properties 機架。
您不需要叢集前面的負載平衡器。 用戶端會直接連線到叢集中的節點。
此架構的部署腳本會使用名稱解析來初始化叢集內部通訊的種子節點（八卦）。 若要啟用名稱解析，部署會建立具有 Cassandra 節點 A 記錄的 Azure 私用 DNS 區域。 視您的初始化腳本而定，您可能能夠改用靜態 IP 位址。
注意
Azure 私用 DNS 目前處於公開預覽狀態。
Jumpbox
不允許從公用因特網對執行應用程式工作負載的 VM 進行 SSH 存取。 相反地，這些 VM 的所有 SSH 存取都必須透過 Jumpbox。 系統管理員登入 Jumpbox，然後從 Jumpbox 登入其他 VM。 Jumpbox 允許來自因特網的 SSH 流量，但只允許來自已知安全 IP 位址的 SSH 流量。
Jumpbox 的效能需求最低，因此請選取較小的 VM 大小。 建立 jumpbox 的公用 IP 位址 。 將 jumpbox 放在與其他 VM 相同的 VNet 中，但放在個別的管理子網中。
若要保護 jumpbox，請新增 NSG 規則，只允許來自一組安全公用 IP 位址的 SSH 連線。 設定其他子網的 NSG，以允許來自管理子網的 SSH 流量。
考量
延展性
擴展集
針對 Web 和商務層，請考慮使用 虛擬機器擴展集，而不是將個別的 VM 部署到可用性設定組。 擴展集可讓您輕鬆地部署和管理一組相同的 VM，並根據效能計量自動調整 VM。 隨著 VM 上的負載增加，額外的 VM 會自動新增至負載平衡器。
設定部署在擴展集中的 VM 有兩種基本方式：
在部署 VM 之後，請使用擴充功能來設定 VM。 使用這種方法，新的 VM 實例可能需要更長的時間才能啟動，而不是沒有擴充功能的 VM。
使用自定義磁碟映像部署受控磁碟。 此選項可能更快速地部署。 不過，您必須讓映像保持最新狀態。
如需詳細資訊，請參閱 擴展集的設計考慮。
提示
使用任何自動調整解決方案時，請事先以生產層級工作負載進行測試。
訂用帳戶限制
每個 Azure 訂用帳戶都有預設限制，包括每個區域的 VM 數目上限。 您可以提出支援要求來增加限制。 如需詳細資訊，請參閱 Azure 訂用帳戶和服務限制、配額和條件約束。
應用程式閘道
應用程式閘道 支援固定容量模式或自動調整模式。 固定容量模式適用於工作負載一致且可預測的案例。 請考慮針對具有可變流量的工作負載使用自動調整模式。 如需詳細資訊，請參閱自動調整和區域備援 應用程式閘道 v2。
效能效益
若要從 Azure VM 上的 Cassandra 取得最佳效能，請參閱在 Azure VM 上執行 Apache Cassandra 中的建議。
可用性
可用性區域可在單一區域內提供最佳的復原能力。 如果您需要更高的可用性，請考慮跨兩個區域複寫應用程式。
並非所有區域都支援可用性區域，並非所有區域都支援所有 VM 大小。 執行下列 Azure CLI 命令，以尋找區域內每個 VM 大小的支援區域：
az vm list-skus --resource-type virtualMachines --zone false --location <location> \
--query "[].{Name:name, Zones:locationInfo[].zones[] | join(','@)}" -o table
如果您將此架構部署到不支援可用性區域的區域，請將每一 層的 VM 放在可用性設定組內。 相同可用性內的 VM 會部署在多個實體伺服器、計算機架、儲存單位和網路交換器之間，以進行備援。 擴展集會自動使用 放置群組，這可作為隱含的可用性設定組。
部署至可用性區域時，請使用 Azure Load Balancer 的標準 SKU 和 應用程式閘道 的 v2 SKU。 這些 SKU 支援跨區域備援。 如需詳細資訊，請參閱
單一 應用程式閘道 部署可以執行閘道的多個實例。 針對生產工作負載，請至少執行兩個實例。
Cassandra 叢集
針對 Cassandra 叢集，故障轉移案例取決於應用程式所使用的一致性層級和複本數目。 如需 Cassandra 中的一致性層級和使用方式，請參閱 設定數據一致性 和 Cassandra：與仲裁交談多少個節點？ Cassandra 中的數據可用性取決於應用程式和複寫機制所使用的一致性層級。 如需 Cassandra 中的複寫，請參閱 No 中的數據復寫 SQL 資料庫 說明。
健康情況探查
應用程式閘道 和Load Balancer都會使用健康情況探查來監視 VM 實例的可用性。
- 應用程式閘道 一律使用 HTTP 探查。
- Load Balancer 可以測試 HTTP 或 TCP。 一般而言，如果 VM 執行 HTTP 伺服器，請使用 HTTP 探查。 否則，請使用 TCP。
如果探查無法在逾時期間內觸達實例，閘道或負載平衡器就會停止將流量傳送至該 VM。 如果 VM 再次可供使用，探查會繼續檢查並將 VM 傳回後端集區。
HTTP 探查會將 HTTP GET 要求傳送至指定的路徑，並接聽 HTTP 200 回應。 此路徑可以是根路徑 （“/”），或是實作一些自定義邏輯來檢查應用程式健康情況的健康情況監視端點。 端點必須允許匿名 HTTP 要求。
如需健康情況探查的詳細資訊，請參閱：
- 健康狀態探查 (機器翻譯)
- 應用程式閘道 健康情況監視概觀
如需設計健康情況探查端點的考慮，請參閱 健康情況端點監視模式。
成本最佳化
使用 Azure 定價計算機來預估成本。 以下是一些其他考慮。
虛擬機器擴展集
所有 Linux VM 大小都可以使用虛擬機擴展集。 您僅需支付您部署的 Azure VM，以及使用的任何額外基礎結構資源，例如儲存體與網路。 虛擬機器擴充集服務本身沒有累加的費用。
如需單一 VM 定價選項，請參閱 Linux VM 定價。
負載平衡器
您只需支付已設定的負載平衡和輸出規則數目的費用。 輸入 NAT 規則是免費的。 當未設定任何規則時，Standard Load Balancer 不會按小時計費。
如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework 中的成本一節。
安全性
虛擬網路是 Azure 中的流量隔離界限。 一個 VNet 中的 VM 無法直接與不同 VNet 中的 VM 通訊。 除非您建立 網路安全組 （NSG） 來限制流量，否則相同 VNet 內的 VM 可以通訊。 如需詳細資訊，請參閱 Microsoft 雲端服務和網路安全性。
針對連入因特網流量，負載平衡器規則會定義哪些流量可以到達後端。 不過，負載平衡器規則不支援IP安全清單，因此如果您想要將特定公用IP位址新增至安全清單，請將NSG新增至子網。
DMZ。 請考慮新增網路虛擬設備 （NVA），以在因特網與 Azure 虛擬網路之間建立 DMZ。 NVA 是虛擬設備的一般詞彙，可執行網路相關工作，例如防火牆、封包檢查、稽核和自定義路由。 如需詳細資訊，請參閱 在 Azure 與因特網之間實作 DMZ。
加密。 加密待用敏感數據，並使用 Azure 金鑰保存庫 來管理資料庫加密密鑰。 金鑰保存庫 可以將加密金鑰儲存在硬體安全性模組 （HSM） 中。 此外，建議您將應用程式秘密，例如資料庫 連接字串，儲存在 金鑰保存庫 中。
DDoS 保護。 Azure 平台預設會提供基本的 DDoS 保護。 此基本保護是以整體保護 Azure 基礎結構為目標。 雖然會自動啟用基本 DDoS 保護，但建議使用 Azure DDoS 網路保護。 網路保護會根據應用程式的網路流量模式使用調適型調整來偵測威脅。 這可讓其針對可能不受基礎結構 DDoS 原則忽視的 DDoS 攻擊套用防護功能。 網路保護也會透過 Azure 監視器提供警示、遙測和分析。 如需詳細資訊，請參閱 Azure DDoS 保護：最佳做法和參考架構。
卓越營運
由於所有主要資源及其相依性都位於此架構中的相同虛擬網路中，因此它們會隔離在相同的基本工作負載中。 這一事實可讓您更輕鬆地將工作負載的特定資源與 DevOps 小組產生關聯，讓小組可以獨立管理這些資源的所有層面。 此隔離可讓 DevOps Teams 和服務執行持續整合和持續傳遞 （CI/CD）。
此外，您可以使用不同的部署範本，並將其與 Azure DevOps Services 整合，以在幾分鐘內布建不同的環境，例如只在需要時復寫生產環境，例如案例或負載測試環境，以節省成本。
在此案例中，您的虛擬機是使用虛擬機擴充功能進行設定，因為它們提供安裝某些其他軟體的可能性，例如 Apache Cassandra。 特別是，自定義腳本擴充功能允許在虛擬機上下載和執行任意程式碼，允許無限制地自定義 Azure VM 的操作系統。 VM 擴充功能只會在 VM 建立期間安裝和執行。 這表示如果操作系統在稍後階段設定不正確，則需要手動介入，才能將其移回正確的狀態。 組態管理工具可用來解決此問題。
請考慮使用 Azure 監視器 來分析和優化基礎結構的效能、監視和診斷網路問題，而不需要登入虛擬機。 Application Insights 實際上是 Azure 監視器的其中一個元件，可提供豐富的計量和記錄，以驗證完整 Azure 環境的狀態。 Azure 監視器可協助您遵循基礎結構的狀態。
請務必不僅監視支援應用程式程式代碼的計算元素，而且監視您的數據平臺，特別是您的資料庫，因為應用程式的數據層效能低可能會產生嚴重後果。
為了測試執行應用程式的 Azure 環境，它應該透過與應用程式程式代碼相同的機制進行版本控制並部署，然後也可以使用 DevOps 測試範例進行測試和驗證。
如需詳細資訊，請參閱 Microsoft Azure Well-Architecture Framework 中的 Operational Excellence 一節。