原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://frankfan.blog.51cto.com/6402282/1193501
Problem Statement
存储设计是虚拟化设计的重要部分之一，确定合适的存储类型是展开存储设计的关键一步。
FC/FCoE, iSCSI, NFS 甚至 Local Storage, 你会选择哪一种呢？参见下图。
Requirements
客户需要移植物理服务器到VMware虚拟化平台，很多物理服务器使用FC SAN,有的SAN Disk容量大于2T。其中有的服务器运行MS Cluster Service。
有的应用对响应时间的要求很高。
Assumptions
目前存储支持部门很熟悉EMC FC SAN，并且有完善的管理流程
Constraints
目前用户的物理服务器使用EMC的FC SAN。
因为一些物理服务器用于关键应用，只能在夜间进行。希望移植的时间能在8小时以内。
Motivation
满足某些关键应用对存储设计性能的高要求
考虑目前存储支持部门的能力和选择倾向
Architectural Decision
新建虚拟化平台的存储类型选择EMC的FC SAN
Justification
1 P2V移植需要在8小时内完成，而且某些SAN Disk超过2T。如果新建的虚拟化平台使用FC SAN，可以在P2V时不选择大容量的SAN Disk。在P2V结束后，再用RDM的方式把原来物理机连接的SAN Disk直接挂接到虚拟机上。
2 相对于NFS而言，FC对MSCS的支持较好。
3 因为有的应用对响应时间的要求很高，希望由于存储产生的Latency越小越好。相比基于网络的NFS而言，FC Switching 所需时间很短。
4 目前的存储支持部门已经熟悉FC SAN. 继续使用该技术可以有效保护已经的投资。而且减少因为采用新存储技术所必须的人员培训，额外风险等等。
Alternatives
iSCSI/NFS/Local Storage
Implications
1.注意LUN的数目不能超过vSphere支持的最大数目。
2.如果采用physical RDM, 不支持VMware Sanpshot
我们经常在FC存储设计中常问的是：LUN多大合适，一个LUN能最大支持多少个虚拟机？
在存储扩容时常见错误是，只注重满足容量需求，而忽视了对性能的影响。我建议Storage Sizing需要在保证性能的前提下，再考虑容量、可用性、安全等其他方面。
一概念及性能指标
上图是一个SAN环境下虚拟机访问存储设计到的模块，可以看到影响虚拟机性能的因素很多了。所以我们在设计存储时要周到的考虑到各个模块，是不是可能有瓶颈？
性能指标：
Throughput
单位时间内传输的数据量。往往以KBPS或MBPS来衡量。
Latency (响应时间)
指完成一个IO请求所需要的时间。往往以milliseconds来衡量。
二存储扩展时考虑因素
SCSI Reservation
在vSphere 4.1 推出VAAI之前，的确SCSI Reservation需要特别注意。VAAI的Hardware AssistedLocking很大程度上避免了SCSI Reservation的问题。
那么，这是不是意味这我们就可以用一个很大的LUN，比如说64T, 然后在那个LUN上无限制的添加VM呢？
千万别忘了人们往往忽视的队列。
队列 Queuing
从上图可以看到从上到下的四层都有队列。队列中等待执行的任务越长，意味着更长的响应时间。
先拿ESXi主机这一层来说，LUN Queue Depth决定了在同一时间可以对某个LUN发起的ActiveCommand 数量。ESXi缺省值是32. 所有虚拟机发起的Active Commands的总数最好不要持续超过LUN Queue Depth. 虽然LUN Queue Depth可以最大增加到64，但一般还是建议使用缺省值。
比如有多个I/O intensive的虚拟机在同一个LUN的时候，需要考虑把部分虚拟机转移到其他LUN以避免Active Commands的总数持续超过LUNQueue Depth，从而造成延时。
HBA这层也有队列，通常4,000 commandsper port 或者更高。所以一般瓶颈不在HBA层。
具体怎么算一个VMFS Volume最大支持的VM数，请参见下文。
http://www.yellow-bricks.com/2009/07/07/max-amount-of-vms-per-vmfs-volume/
不过该文最后也提到了，公式仅仅是个参考。
三实践
化太多时间精力想设计的很完美，未免学究气。不妨开始先尝试一个很粗的计划。然后看情况在实践中调整。
·10 high I/O VMs perdatastore
·15 average I/O VMs perdatastore
·20 low I/O VMs perdatastore
上述建议来自VAAIand the Unlimited VMs per Datastore Urban Myth
虚拟机本身的I/O行为时变化的，而且实际中出现的因素，有时在设计时不能考虑周全。
实际出现问题的时候，你可以用Storage vMotion转移VM到其他不忙的LUN。你也可以用StorageDRS。
Multipathing 在存储设计中是必须的，因为有多条路径可以访问LUN，它不仅保证了高可用性，同时也有负载均衡的作用。
PSA (PluggableStorage Architecture)
上图是了解Multipathing底层机制的概念。详情参考此文
存储类型
Active-Passive:
在某一时刻仅有一个Storage Processor(SP)拥有对某个LUN访问的专有权。从其他SP对该LUN发起的访问会被拒绝。只有当该主SP失败时，其他的SP对该LUN的访问才会被接受
Active-Active:
没有主SP的概念，某个LUN可以接受任何SP的访问。
MultiPathing策略
基于存储类型，可以参考本文选择相应的Multipathing策略
Policy/Controller
Active/Active
Active/Passive
Most Recently Used
Administrator action is required to fail back after path failure.
Administrator action is required to fail back after path failure.
Fixed
VMkernel resumes using the preferred path when connectivity is restored.
VMkernel attempts to resume using the preferred path. This can cause path thrashing or failure when another SP now owns the LUN.
Round Robin
No fail back.
Next path in round robin scheduling is selected.
Fixed with Array Preference
For ALUA arrays, VMkernel picks the path set to be the preferred path.
For both A/A and A/P and ALUA arrays, VMkernel resumes using the preferred path, but only if the path-thrashing avoidance algorithm allows the fail-back.
注意：以上策略及说明适用VMwareNative Multipathing (NMP) Path Selection Plug-ins (PSP) 的情况。如果使用第三方的方案，请参考该提供商的资料。
实例
下面是VCDX Boot Camp - Preparing for the VCDX panel defense一书给出的排错的例子。
问题描述：
当前的架构设计
具体分析：
因为以上设计的缺陷，有两种情况下会出现path thrashing的情况。
情况一：下图所示的两条路径失败。
Screen clipping taken:18/05/2013 4:15 PM
情况二：采用不恰当的Multipathing策略。在Active-passive的存储设备使用了Fixed
这两种情况都可以导致的后果是：
SPA1和SPB1不断的争夺对LUN1的读写控制，从而导致LUN的主控制器频繁在SPA1和SPB1之间切换。我们称这种情况为PathTrashing
下图的改良后的设计，同一个光线交换机连到了阵列的不同控制器上，这样就不会出现我们上面提到的情况了。
问题描述：
本地存储在近年来的虚拟化架构设计中越来越受到关注，相比SAN来说，本地存储的成本低很多。是不是本地存储适合你的环境，还需要具体问题具体分析。本文仅以一个案例来帮你了解本地存储的利弊。
需求：
客户运行一个虚拟桌面的环境，目前大约有500台虚拟桌面，预计最多扩展到1000台。
虚拟机的主要用户是呼叫中心的客服人员。因为所有用户使用标准化的应用，采用PooledDesktop。虚拟机的RTO（RecoveryTime Objective）要求是1小时。也就是说如果一台虚拟机宕机，该用户在1小时内可以重新连接一台虚拟桌面。
客户的预算不多，存储设备如果花费很多的话有可能让这个项目夭折。
假设：
N/A
限制条件：
目前客户的共享存储的可用容量不能完全满足虚拟桌面项目的需求
架构设计倾向：
用户倾向考虑低成本的方案
架构推荐方案：
新建虚拟化平台的存储类型选择本地存储和Filer混合的方式。下图来自ABrief History of Desktop Storage Architecture一文
HostDASD (Host Direct Access Storage Device) 也就是指ESXi Host本地存储。
CorporateFiler 用于存储应用程序和用户数据
因为本案例是Pooled Desktop，所以没有User Persona，那么SAN也就用不上了。
其他可选方案:
FC/iSCSI/NFS Storage
选择理由：
1 采用本地存储可以大大降低前期的投入
2 因为是Pooled Desktop，虚拟桌面及其运行的应用是完全标准化的。用户不能保存个性的设置。假设某个虚拟桌面所处主机宕机后，用户可以马上连接到其他主机上运行的虚拟桌面。
在这种情况下HA、vMotion并不是必须的。
3 客户可以采用一些流程来均衡在所有主机上运行的虚拟桌面。DRS不是必须的。
4 因为500-1000虚拟桌面环境是相对容易控制的。在需要对主机维护的时候，可以采用人工的Change Management方式。Call Center每个Shift的工作时间也是固定的，可以预先安排维护时间段，告知用户在维护前Log Off
该设计决定的影响:
1.必须有完善的CapacityPlanning. 保证本地存储有能满足虚拟桌面的性能和容量需要
2.在IOPS需求较高时，可以考虑SSD与其他低成本类型混合的方式。或者考虑Fusion-IO等Flash Memory
3.完善的Change Management 是必须的。因为主机维护需要介入ChangeManagement,运维的人工成本相对高一些.
参考：
VDIstorage should be local!
ABrief History of Desktop Storage Architecture
