今天再來分享一波Azure管理的經驗，熟悉Azure的朋友都知道，Azure有託管磁盤和非託管磁盤之分，早期的VM全都是非託管磁盤的，需要我們手動維護以及規劃磁盤的使用情況，還有20000 IOPS的限制等問題，爲了解決這種問題，微軟引入了託管磁盤的概念，託管磁盤相對於非託管磁盤來說，有很多的優勢，主要有以下幾點：
簡單且可縮放的 VM 部署
託管磁盤在幕後處理存儲。 以前，必須創建存儲帳戶才能存儲 Azure VM 的磁盤（VHD 文件）。 進行擴展時，必須確保創建了額外的存儲帳戶，以便任何磁盤都不會超出對存儲的 IOPS 限制。 使用託管磁盤處理存儲時，不再受到存儲帳戶限制（例如每個帳戶 20,000 IOPS）的約束。 另外，不再需要將自定義映像（VHD 文件）複製到多個存儲帳戶。 可在一箇中心位置管理自定義映像（每個 Azure 區域保存一個存儲帳戶），並使用它們在一個訂閱中創建數百個 VM。
託管磁盤支持在每個區域中的一個訂閱中創建最多 50,000 個同一類型的 VM 磁盤，這使得可以在單個訂閱中創建數以萬計的 VM
可用性集的可靠性更高
通過確保可用性集中的 VM 的磁盤彼此之間完全隔離以避免單點故障，託管磁盤爲可用性集提供了更佳的可靠性。 磁盤自動放置於不同的存儲縮放單元（模塊）。 如果某個模塊因硬件或軟件故障而失敗，則只有其磁盤在該模塊上的 VM 實例會失敗。 例如，假定某個應用程序在 5 臺 VM 上運行並且這些 VM 位於一個可用性集中。 這些 VM 的磁盤不會存儲在同一個模塊中，因此，如果一個模塊失敗，該應用程序的其他實例可以繼續運行。
高度持久和可用
Azure 磁盤具備 99.999% 的可用性。 數據具有三個副本，高持久性可讓用戶高枕無憂。 如果其中一個或兩個副本出現問題，剩下的副本能夠確保數據的持久性和對故障的高耐受性。 此架構有助於 Azure 爲 IaaS 磁盤持續提供企業級的持久性，年化故障率爲 0%，達到行業領先水平。
粒度訪問控制
可以使用 Azure 基於角色的訪問控制 (RBAC) 將對託管磁盤的特定權限分配給一個或多個用戶。 託管磁盤公開了各種操作，包括讀取、寫入（創建/更新）、刪除，以及檢索磁盤的共享訪問簽名 (SAS) URI。 可以僅將某人員執行其工作所需的操作的訪問權限授予該人員。 例如，如果不希望某人員將某個託管磁盤複製到存儲帳戶，則可以選擇不授予對該託管磁盤的導出操作的訪問權限。 類似地，如果不希望某人員使用 SAS URI 複製某個託管磁盤，則可以選擇不授予對該託管磁盤的該權限。
所以現在微軟也是大力的推動託管磁盤的使用。那麼在實際應用中，企業IT管理員也肯定希望用戶能夠更多地去使用託管磁盤，但如何來實施這點呢，光靠嘴說可能很多時候並不好使，最好是能夠有一些技術手段限制創建非託管磁盤VM
Azure Policy是個很好的解決辦法
Azure Policy 是 Azure 中的一項服務，可用於創建、分配和管理策略。 這些策略將在整個資源中強制實施不同的規則和效果，以便這些資源符合公司標準和服務級別協議。 Azure Policy 通過評估資源是否符合指定策略來滿足此需求。 例如，可以設置一項策略，僅允許環境中有特定 SKU 大小的虛擬機。 實施此策略後，將評估新資源和現有資源的符合性。 通過使用正確的策略類型，可以確保現有資源的符合性。 也可以通過Policy明確禁止一些管理員不希望發生的操作
下邊來看如何來實施policy吧，policy其實也是通過JSON文件的形式進行了一些定義，所以我們只需要編寫一些policy的JSON文件即可
限制非託管磁盤VM的JSON文件如下：
{
"if": {
"allOf": [
{
"field": "type",
"equals": "Microsoft.Compute/virtualMachines"
},
{
"field": "Microsoft.Compute/virtualMachines/osDisk.uri",
"exists": true
}
]
},
"then": {
"effect": "deny"
}
}如何將這個定義轉換爲Policy呢？可以通過PowerShell
運行如下PowerShell命令
第一步：創建policydefinition
第二步：創建role assignment
之後可以看到在Azure Portal的policy裏，也能夠看到這些內容了
下邊來嘗試一下吧！在Portal中創建一個非託管磁盤的Linux VM
可以發現，在最後驗證的時候，會提示被policy deny掉了！
Azure Policy是個很不錯的東東，後續有機會繼續和各位分享！