一、Azure VM中Disk的存储账户设计
- Storage类型的选择
Azure VM的Disk服务是Azure Storage中blob存储服务中的Page Blob。Azure的Storage服务的种类有：
目前，国内还只有LRS、GRS和RA-GRS三种模式。由于LRS的Ingress和Egress的吞吐量比GRS都要大（请参考下面Storage Account的limitation表格），因此如果存储账户是用做VM的Disk，除非有特殊用途，建议采用LRS的模式。
- Storage Account的名字的设计
Storage Account Name是Storage Account的标识。
而Storage Account的负载均衡是通过Storage Account实现的。不同的Storage Account Name通过DNS解析，到不同的Storage Stamp。因此Storage Account Name的选择在某种程度上会影响Disk的性能。这主要是因为：
a. Azure存储使用分区(Partition)的方案来扩展和负载平衡。
就是说，一部分Storage Account在一个分区内，有可能多个Storage Account解析出来的IP地址都是一个，就是说这些Storage Account在一个分区内。而分区的划分是基于"键"的。而键是由Storage Account Name来决定的。如果客户选择Storage Account的名字比较相似，比如：msftpayroll, msftperformance, msftemployees，或者带时间戳的：log20160101, log20160102, log20160102，这些Storage Account有可能都被分配到同一个partition下。
b. Azure的partition是可以动态调整的。
Azure Storage有自动Balance的功能，当某一个Container的负载过高时，系统会自动进行负载的调整，实现负载均衡。但这个调整的过程中，存储的调用等的时延会增加。
c. 基于上面的讨论，建议在存储账户的设计时，就考虑这些因素。
最佳实践是：仔细检查帐户、容器、blob的命名约定。应该考虑使用散列函数给某些帐户名称前添加3位散列值。比如：s5x-msftpayroll, h79-msftperformance, n2a-msftemployees，如果企业命名规定中必须使用时间戳或数字标识，建议不要采用简单的前缀添加或后缀添加，这样有可能使所有访问集中到一个Partition上。如果采用时间，建议采用ssmmhh的模式，或在时间前加3位散列值。如果采用数字标识，建议在数字标识前加3位散列值，比如：jha-log20160101, a9g-log20160102, i76-log20160102。
- Storage Account的高可用设计
如果创建的Storage Account主要是用于VM Disk使用的，那在Storage Account的设计中，高可用性变的至关重要。根据这几年Azure项目中碰到的问题，建议的最佳实践是：
a. VM的Disk分散到不同的Storage Account
一般会把Web、APP的VM Disk分成两组，分别放到Left和Right两个Storage Account。这样万一当有一个Storage Account出现故障时，不会影响所有的VM。另外对于DB的Disk，建议一个DB VM的Disk放到一个存储账户中，如图所示。
b. 同一层VM的Disk放到不同的Storage Account
在a中提到的部署模式下，如果客户的VM数量比较多，这样部署也存在问题：有可能会hit到Storage Account的性能上限，这时会出现VM重启或无法启动的情况，这点在后面会介绍。
每一组VM分两个Storage Account，尽量将Disk分散部署。
- Storage Account的容量设计
每个Storage Account都有各种指标的限制，与Disk相关的具体如下：
其中每个Storage Account最大20,000个IOPS。而每个普通Disk的IOPS是500 IOPS。所以当一个Storage Account的Disk超过40个时（40*500 IOPS=20,000 IOPS），VM会出现重启或者不能启动的情况。
因此建议在每个Storage Account里的Disk的数量不要超过20个。由于Storage Account的数量相对比较大，而且没有费用产生，因此在有大量VM的情况下，建议多开Storage Account，以减少每个Storage Account中Disk的数量。