本篇重点：
Managed disk的优势和改进思路
Managed disk的限制和注意
今天我们来聊一聊托管磁盘managed disk。托管磁盘是我本人非常期待并催了产品组很多次的feature。这个功能的依赖度和关联度是非常高的。 几乎所有compute的新功能和API关联都与这个功能有关。而这功能本身，也解决了许多之前设计上和功能考虑上的问题。大致可以概括为这几部分：
稍后我们展开说，但是托管磁盘也不是银弹。不是说它就能解决所有问题并没有限制。等演示过后，我们聊聊它的限制。
首先，关于存储上的限制。一般存储账号本身是个逻辑概念，他的性能和大小是有限制的。但在管理磁盘层面，它的限制更多就在其本身上，没有了存储账号的限制。详情可以看下图：
当然，微软产品组也在尽力提供更多更快的IOPS和更大的磁盘。最近新的4TB的磁盘已经宣布GA,同时，相信这个利好也会很快来到Azure中国。
再而，磁盘本身在Azure restful api里也成为了一个可以被call的对象，如图：
这就意味着，我们可以在microsoft.compute/disk层面做各种API， 各种CRUD操作。诸如拷贝，升级等等。方便了我们抽象整个azure 资源。
而将磁盘单独出来并将其托管化，还为了一个很重要的点。就是给磁盘加可用性集。大家知道我们在计算节点上是有可用性集和故障域来保障计算node的可用性。而存储节点，我们很多时候是容易忽略的。好的设计应该是存储也有多个stamp区冗余，但这对于客户来说，学习成本是略高的。所以我们想到了用托管的方式，从内部解决这个问题。反应到ps上，就可以看到，我们在转换一个既有AVSET的虚拟机时，需要把他的COMPUTE和storage部分align.为的就是同时满足存储的可用性集。有了存储级别的高可用，那下次单一存储Stamp的问题也将不会影响整个环境了。
（这是一个将可用性集内的虚拟机转化为托管磁盘的例子）
架构如图：
依托于managed disk诞生的snapshot和image功能就更是画龙点睛了。snapshot可以直接从disk层面做全快照，而image则是对于整个虚拟机层面做到的镜像。image本身是可以带数据盘的，而snapshot则不可以。image和snapshot很多时候都是可以互相转换的。依托于image和snapshot, 客户可以很轻松的完成很多重建虚拟机和回滚任务。甚至是批量部署和定期还原。
托管磁盘的转换和扩展也是可以很容易做的。直接在Portal上就可以完成之前费尽周折的任务，点选类型，更改大小就好了。（注意，先不要shrink，可能有问题）
我们有大量的文档和命令提示帮助客户实现，非托管往托管转换，经典模式转换，可用性集转换，标准往高级转换等等。可以参考（docs.azure.cn)。
再说说VMSS，我本身对VMSS是很看重的。依托于托管磁盘，我们可以利用VMSS完成很多事。
创建带数据盘的image:
使用镜像创建实例：
自带数据盘，并可根据CPU自动scale up scale down。最多可以100个实例
我们也可以用Snapshot完成很多类似的操作：
说完了优势，我们来聊聊限制。
收费模式的限制，目前的managed disk采用的是类似prem disk的收费方式。即按照磁盘大小阶梯式收费，所以如果客户需要大量容量并且想要高IOPS，还是可以采用原来的unmanaged disk的方式组raid0.或者直接上ssd
冗余模式的限制， 目前managed disk只能使用LRS模式，在某些需要GRS的情况下，可以考虑用unmanaged disk
目前shrink功能还是有限制的。
**必须enable 出去的8443端口，否则agent无法通知host disk状态。部署可能会失败。
Managed disk无法使用迁移，不过可以通过snapshot/image实现
总的来说，managed disk在非管理存储模式下是有一定优势的。但总体来说，还有一些问题需要解决。用户可以考虑在特殊需求的情况下，使用非管理存储解决问题，2者的转换也是很容易很方便的 :)