ARM 中可用性集使用的注意事項

azure 目前有兩種部署模型：經典部署模型 (asm) 和資源管理器 (arm)。如果您之前使用過 asm 模式下的可用性集，那麼很可能在使用 arm 模式下的可用性集時，會遇到一些問題或者疑惑。這裡就 arm 中可用性集使用的一些常見問題做個簡單回答。

arm 中，虛擬機器的整個生命週期都不能更改其可用性集設定。

arm-ha

什麼意思呢？就是說：

如果在建立虛擬機器的時候，如果沒有指定可用性集，那麼虛擬機器完成部署後，是不能將該虛擬機器加入到可用性集中的。

如果虛擬機器已經在可用性集中，您需要給它換個可用性集，或者將其移除可用性集，這也是不能的。

如果您的確需要更改該虛擬機器的可用性集設定，唯一的方法，就是通過刪除虛擬機器保留磁碟，並重建虛擬機器的方式，指定可用性集。

可用性集的設定也是只能在建立的時候指定。

建立可用性集時，您可以自定義容錯域和更新域的數量。但在建立完成後，這些設定就不能再更改了。

容錯域：範圍 1-3，預設值是 3。在物理上，乙個域中的所有虛擬機器和物理機，會共享同樣的電源和網路資源。

更新域：範圍 1-20，預設值是 5。這是乙個邏輯的概念，後台在執行計畫內維護時，所有更新域中一次只會有乙個域在進行維護。

可用性集中虛擬機器操作常見錯誤 1 :

由於後台部署失敗，造成虛擬機器建立失敗。這些失敗的虛擬機器因放在可用性集中，刪除也遇到問題。刪除單個虛擬機器，報錯虛擬機器分配失敗；通過刪除整個可用性集，報錯須首先刪除虛擬機器。

delete-vm-failure

解決方法 :

將可用性集下的所有虛擬機器，都執行一遍刪除操作，無論成功與否。然後再刪除該可用性集。

原因：通過對每台虛擬機器都執行刪除操作，即使未能成功刪除，也會將虛擬機器的狀態標記為「tobedelete」。此時再刪除可用性集，可用性集在驗證虛擬機器狀態時，發現所有虛擬機器都是可以被刪除的，則會將虛擬機器連同可用性集一起刪除。

可用性集中虛擬機器操作常見錯誤 2 :

在對可用性集中的虛擬機器進行一些管理平面的操作時，你可能會遇到如下錯誤。

如更改診斷設定儲存賬號/刪除虛擬機器：

provisioning-failed

或者向該可用性集中建立新虛擬機器 :

storage-account-not-find

而實際上，您操作的虛擬機器可能並沒有使用這些儲存賬號。

這是由於在對可用性集中的虛擬機器進行管理操作時，可用性集會驗證其所有虛擬機器的 os profile，保證資訊的一致性。如果任何一台虛擬機器引用的診斷儲存賬號不存在了，該驗證過程失敗，則操作無法繼續進行，該虛擬機器狀態會被同步標記為失敗。

解決方法 :

找到被刪除的儲存賬號是被哪個虛擬機器在使用。

通過 get-azurermvm -resourcegroupname -name 檢視 bootdiagnostics 和 diagnostic extensions 的儲存賬號設定。

禁用該虛擬機器的診斷儲存賬號即可。

如果該可用性集中同時有多個診斷儲存賬號被誤刪，則方法 1 因乙個虛擬機器設定等待另乙個虛擬機器設定先修正而造成死鎖。在這種情況下，需要找到所有被誤刪的診斷儲存賬號，重建之。

note

前端顯示儲存賬號重建成功後，後台各資源提供程式間的同步需要一段時間，可能發生因同步延遲造成的儲存賬號還是找不到的問題。請在重建好所有儲存賬號，大約一至乙個半小時後，再次嘗試管理操作。

同時，建議客戶在使用可用性集時，提前進行規劃，比如使用有意義的虛擬機器和儲存賬號命名，將診斷設定放在同乙個單獨的儲存賬號中等，避免儲存賬號被誤刪的情況發生。

立即訪問