Azure帳號註冊 Azure虛擬機可用性集怎麼配置

前言：為什麼要用「可用性集」

在雲端環境裡，高可用不是把服務做得越複雜越好，而是要把風險拆開、把故障影響範圍縮小，並確保在「機器或主機層級」出現不可避免的中斷時，系統仍能維持服務。Azure 提供了多種韌性能力，其中「可用性集（Availability Set）」是最基礎、也最常見的起點。

簡單講，可用性集用來把多個虛擬機（VM）分散到不同的容錯網域（Fault Domain）與更新網域（Update Domain）中，讓同一時間內，不會因為單一主機故障或單一批次更新導致全部 VM 同時不可用。它不保證「零停機」，但能把停機機率與停機範圍控制在合理範圍，讓你能以設計換取可靠性。

當你把應用拆成至少兩個可並行運作的節點，並讓它們在更新或硬體故障時能互相接棒，可用性集就會成為你架構的地基之一。下面我們從概念開始，逐步走到實際配置。

第一章：核心概念先釐清

容錯網域（Fault Domain）是什麼

容錯網域可以理解為「可能同時失效的硬體/電力/網路集合」。當其中一個容錯網域發生故障（例如主機損壞或機房電力問題的某類型事件），同一容錯網域內的 VM 可能一起受影響。

可用性集會限制：同一時刻，你的 VM 不會被放在同一個容錯網域裡。這樣就算其中一個容錯網域故障，至少仍有其他容錯網域的 VM 可以繼續提供服務。

更新網域（Update Domain）是什麼

更新網域可以理解為「系統維護或作業系統/硬體更新會分批進行的批次」。在 Azure 進行底層更新時，會依更新網域分批處理，避免所有 VM 在同一時間都被打斷。

在更新網域的概念下，你設計上會希望：即使有一個批次進行維護，還有其他批次中的 VM 可繼續回應請求。當你把 VM 放進可用性集並選擇足夠的更新網域數量，系統的「維護窗口造成的停機風險」會被削減。

可用性集能解決什麼、不能解決什麼

能解決：

• 單一主機或單一維護批次導致的同時停機風險。
• Azure帳號註冊 提升在硬體故障與更新時的容錯能力。
• 把可靠性從「靠運氣」變成「靠設計」。

不能解決：

• 整個資料中心級別的災難（例如整區不可用）。這通常要靠區域層級的架構，例如可用區（Availability Zone）或跨區（跨區域災備）。
• 應用本身沒有冗餘或沒有自動切換的問題。可用性集只是讓 VM 層級更可靠，應用層仍需能承受節點替換或短暫不可用。

第二章：配置前的規劃清單

很多人第一次配可用性集，卡在「照著做了但沒有感覺」或「配了才發現不符合需求」。要避免這種情況，建議在開始之前回答幾個問題。

你的應用是否可以水平擴展

可用性集的主要價值在於：同時有多台 VM 能提供相同或等價服務。常見情況包括 Web 前端、API 節點、背景處理的多工作者等。

Azure帳號註冊 如果你的應用本質上是單點（例如只能在同一台主機上運作且沒有複製/分流），那你只是把「單點」放進「更貴的單點」而已。即使配了可用性集，仍無法達到你期待的高可用。

Azure帳號註冊 是否需要負載平衡與健康檢查

把多台 VM 放進可用性集，並不會自動把流量分給它們。你通常還需要：

• 負載平衡器（Load Balancer）或 Web 應用程式閘道（Application Gateway）。
• 健康探測（Health Probe）與後端池配置。
• 必要的會話策略（例如避免黏性會話，或確認可支援的 session 方案）。

若你沒有負載平衡，使用者可能會遇到因單機故障或更新導致的連線中斷，體感仍可能不理想。

目標是什麼：降低停機還是提高吞吐

可用性集的第一目標是降低停機風險。若你的主要目標是吞吐量提升，那你要考慮 VM 數量、擴縮策略、快取層設計，以及資料層的可用性（例如資料庫與儲存是否也有冗餘）。

VM 大小與容量預留

Azure 對於 VM 資源配置會考量容量與硬體配合。你應用如果需要很特定的規格（例如高規格 CPU/RAM），可能會遇到容量不足的情況。可用性集並不會讓你免於容量問題，但良好的規劃與彈性（例如適當的資源選型、必要時調整 VM SKU）會降低風險。

第三章：建立可用性集（Availability Set）

下面用一個可落地的流程描述如何建立可用性集。實際畫面可能因 Azure 入口介面更新而略有不同，但概念與選項對應方式不會差太多。

步驟 1：進入 Azure 入口並建立新資源

登入 Azure Portal 後，選擇「建立資源（Create a resource）」。在搜尋框輸入「Availability set」或「可用性集」。點進後選擇建立。

步驟 2：填寫基本資訊

你需要設定：

• 訂用帳戶（Subscription）：選擇資源要歸屬的訂用帳戶。
• 資源群組（Resource Group）：建議與相關 VM、負載平衡等放在同一群組，方便管理。
• 名稱（Name）：命名規範清楚，未來排查時更快。
• 區域（Region）：可用性集是區域內的概念，需選擇你要部署的區域。

步驟 3：容錯網域與更新網域設定

接著是關鍵選項：你要設定容錯網域與更新網域。

• 容錯網域：一般建議至少 2 代表有冗餘。若你 VM 數量只有 2 台，通常 2 個容錯網域已足夠。
• 更新網域：你要考慮系統在更新期間的承受能力。若你的設計能容忍「一次只有部分節點不可用」，更新網域適當配置可以降低維護影響。

實務上你會遇到一個平衡：節點越多、更新網域越細，代表理論上更新分批更平滑，但配置複雜度也會增加，而且 VM 數量不足時不一定能真正分散。

步驟 4：檢查設定並建立

Azure帳號註冊 確認無誤後提交建立。建立完成後，你會看到可用性集的頁面，裡面包含容錯/更新網域資訊與後續加入 VM 的操作。

第四章：把 VM 加入可用性集

你可以在建立 VM 的時候就選擇可用性集，也可以在 VM 建好後把它加入（視 Azure 支援的情況與 VM 狀態而定）。但為了降低不確定性，第一次建議從「建立 VM 時即指定可用性集」開始。

建立 VM 時指定可用性集

在建立 VM 的流程中，通常會在「基本設定」或「高可用性」相關步驟看到：

• 是否要使用可用性集
• 可用性集的名稱

你只要選對已建立的可用性集，並確保 VM 的區域一致即可。

確認加入是否成功

建立後回到可用性集頁面，查看「概覽」或「虛擬機」清單，確認新 VM 出現在對應的容錯/更新網域中。

如果你發現 VM 分布並不符合預期，常見原因包括：可用性集容量不足、你只建立了少量 VM、或某些選項導致放置策略受限。這時不必急著重建 VM，先用檢查資訊理解限制來源。

至少幾台 VM 比較合理

Azure帳號註冊 若你要達到基本容錯，至少 2 台 VM 是常見下限。但是否要 3 台取決於：

• 你是否能承受「更新批次期間」只剩 1 台可用的風險。
• 你的應用是否支持自動故障切換與健康檢查。
• 資料層是否也有冗餘（例如資料庫是否可用、是否有複製延遲等）。

對於很多 Web 類型服務，3 台常能帶來更舒服的維護體驗；但成本也更高。你要依據可用性目標來定。

第五章：搭配負載平衡，才算真的「可用」

可用性集讓 VM 在故障/維護時不會同時全滅，但若流量仍然只打到其中一台，那就仍可能造成服務不可用。因此實務上你需要配合負載分配。

選擇負載平衡方案

常見路徑：

• Azure Load Balancer：適合 TCP/UDP 的轉發與基本負載分配。
• Application Gateway：偏 HTTP/HTTPS 層，能做更精細的路由與 WAF（若啟用）。

如果你的服務是典型 Web/API，Application Gateway 往往更貼近需求；如果你只要 L4 轉發，Load Balancer 也足夠。

健康檢查要設計得「像真實使用者」

健康探測不要只檢查 TCP 連線是否開著。更好的方式是：

• 對 HTTP 應答做驗證（例如回應特定路徑與狀態碼）。
• 必要時把依賴（例如資料庫連線）納入檢查邏輯，避免「假健康」。

如果健康檢查過於寬鬆，VM 可能在應用已故障但端口仍開著時，被錯誤地導入流量，造成更糟的用戶體驗。

會話與狀態要先想清楚

多節點服務的最大敵人之一是「狀態」：登入狀態、檔案上傳暫存、背景工作隊列等。

你可以考慮：

• 盡量使用無狀態服務（或把狀態移到外部共享儲存/快取/資料庫）。
• 若需要會話黏性（session affinity），確認你的負載平衡設定與應用機制能承受節點更換。
• 背景任務使用隊列（Queue）或分散式工作處理架構，避免節點切換造成重複執行。

第六章：更新網域期間會發生什麼

很多人看到「更新網域」會以為只是概念，實際操作時才知道它對體感影響很實在。理解運作邏輯後，你才能設計合理的維護流程與警戒指標。

Azure帳號註冊 分批更新的意義

當 Azure 進行維護或更新時，不是把整批 VM 同時關掉，而是依更新網域逐步處理。你可以把它想像成「依批次下線」。因此：

• 如果你的架構在單批節點失效時仍能保持服務（例如流量能導到其他 VM），停機會很短或看起來幾乎沒有。
• 如果你只有兩台 VM 且其中一台失效時系統就無法接受流量，那更新時你會感受到明顯中斷。

你應該準備哪些應對

• 自動擴縮或至少有容量冗餘：維護期間可能少一台，請確保仍能撐住。
• 健康檢查與連線耗盡策略：讓節點在即將下線前停止接新連線，或讓負載平衡在探測失敗前逐步移除。
• 觀測指標：監控 4xx/5xx 比率、延遲、錯誤率與健康探測狀態，才能知道中斷究竟來自哪一段。

第七章：常見誤區與排查方法

誤區一：只建可用性集，沒有冗餘流量入口

這是最常見的落差。可用性集只是 VM 層級的放置策略。若入口仍指向單點（例如只把 DNS 指到某一台、或負載平衡後端只有一台），那高可用就不會真正成立。

排查方法：確認入口是否有真正的多節點後端池，健康檢查是否生效，並在其中一台停機/重啟時觀察流量是否被轉移。

誤區二：更新網域數量設得很大，但 VM 不夠

更新網域是用來「分批」的。你可以設定 5 個更新網域，但如果你只有 2 台 VM，實際可用的分批效果有限。

排查方法：看可用性集頁面中的 VM 分佈，並用「目標事件」推演：更新期間你希望保留幾台？就反推 VM 數與更新網域策略。

誤區三：把「可用性」誤認為「資料」也可用

Azure帳號註冊 可用性集主要處理計算資源的可用性，但資料層（資料庫、快取、檔案儲存）也可能成為瓶頸或單點。

排查方法：在故障情境測試時，不只測 VM 是否存活，也要測應用的資料讀寫是否仍正常。若資料庫無冗餘，那你只是讓應用端更早崩。

誤區四：健康檢查過於簡化

如果健康檢查只看端口是否開啟，你可能會把流量導到「其實已無法服務」的節點。

排查方法：故障演練時，刻意讓應用進入「端口可連但功能不可用」的狀態，觀察負載平衡是否會正確移除節點。

誤區五：忽略初始化延遲與排程

很多服務在啟動後需要載入設定、建立連線、快取熱身等。若負載平衡太快把流量導入，會造成短暫錯誤。

排查方法：調整健康探測的容忍度（例如初始延遲、間隔與失敗次數），並在應用端把就緒狀態（readiness）與健康狀態分開處理（例如 readiness 端點）。

第八章：如何驗證配置真的有效

光看設定不算數。你需要用可重現的方法驗證。以下給一套實用驗證清單。

驗證一：故障演練（溫和測試）

從最溫和的方式開始，例如：

• 重啟其中一台 VM，觀察負載平衡是否移除該節點，流量是否被轉移到其他節點。
• 確認應用是否在重啟後能重新通過健康檢查並恢復服務。

你要記錄：平均回應延遲變化、錯誤率、恢復時間。

驗證二：觀測指標與日誌

把你關心的訊號接到監控系統中：

• Azure帳號註冊 健康探測狀態變化
• Web/API 回應狀態碼分佈
• VM CPU/記憶體飆升與連線數
• 應用日誌中的例外與重試行為

沒有觀測，就很難知道中斷是設計問題、應用問題、還是健康檢查問題。

驗證三：容量測試（最貼近業務）

用接近真實流量的方式測試，並在測試期間讓其中一台 VM 處於非預期狀態（例如暫停服務或觸發重啟）。你要確認：

• 系統仍能維持可接受的延遲與錯誤率。
• 佇列堆積是否可控（若有背景任務）。
• 資料層是否成為瓶頸。

第九章：進階建議：從可用性集走向更完整的韌性

Azure帳號註冊 當你完成可用性集的基礎配置後，下一步通常是把「單一區域內的韌性」提升到更全面的韌性。

可用性區（Availability Zones）與跨區設計

如果你要抵禦更大規模的故障（例如整個資料中心不可用），可用性集仍不夠。你需要考慮可用性區或跨區架構，把冗餘拉到更高層級。

但是否需要取決於你的可用性目標（例如停機容忍度）、合規要求與成本。

自動化部署與變更管理

可用性集讓硬體與更新帶來的停機風險下降，但你仍需要部署策略（例如滾動更新、金絲雀發布）。

實務上建議把下列流程標準化：

• 發佈時只更新一部分節點
• 觀察健康指標與錯誤率
• 再逐步擴大範圍

資料層也要同等重視

計算節點能容錯，但資料層若沒有冗餘，同樣會讓整體失效。從一開始就把資料策略納入設計：備援、備份、容錯、讀寫策略與遷移流程。

結語：把可用性集當作「設計工具」而不是「設定項目」

Azure 可用性集的配置看似只是幾個選項：選區域、填名字、設定容錯與更新網域。但真正能讓服務更可靠的，是你在配置前完成的架構思考：你的應用是否能水平運作？入口是否有多節點流量分配？健康檢查是否能反映真實就緒？更新期間你能承受多少節點不可用？資料層是否同樣具備容錯？

當你把這些問題回答清楚，再去落地可用性集與負載平衡，你就不會把高可用交給運氣。你做的每一步都在降低風險，並在未來變更時讓系統更可控、更容易排查。

如果你正在建立第一版高可用架構，從可用性集開始是合理且有效的起點。接下來再依需求擴展到可用性區、跨區備援與更完善的監控告警，你的韌性就會逐層變強。