Problem Statement
存储设计是虚拟化设计的重要部分之一,确定合适的存储类型是展开存储设计的关键一步。
FC/FCoE, iSCSI, NFS 甚至 Local Storage, 你会选择哪一种呢?参见下图。
![](https://img-blog.csdn.net/20130531102655452)
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
![](https://img-blog.csdn.net/20130531102705620)
我们经常在FC存储设计中常问的是:LUN多大合适,一个LUN能最大支持多少个虚拟机?
在存储扩容时常见错误是,只注重满足容量需求,而忽视了对性能的影响。我建议Storage Sizing需要在保证性能的前提下,再考虑容量、可用性、安全等其他方面。
一概念及性能指标
![](https://img-blog.csdn.net/20130531102856699)
上图是一个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
![](https://img-blog.csdn.net/20130531102921678)
从上图可以看到从上到下的四层都有队列。队列中等待执行的任务越长,意味着更长的响应时间。
先拿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)
![](https://img-blog.csdn.net/20130531103212704)
上图是了解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一书给出的排错的例子。
问题描述:
![p2 (Mobile).jpg](https://i-blog.csdnimg.cn/blog_migrate/03323109a92372cb27d2b5a1f54053e3.jpeg)
当前的架构设计
![](https://img-blog.csdn.net/20130531103232063)
具体分析:
因为以上设计的缺陷,有两种情况下会出现path thrashing的情况。
情况一:下图所示的两条路径失败。
![](https://img-blog.csdn.net/20130531103243891)
Screen clipping taken:18/05/2013 4:15 PM
情况二:采用不恰当的Multipathing策略。在Active-passive的存储设备使用了Fixed
![](https://img-blog.csdn.net/20130531103253703)
这两种情况都可以导致的后果是:
SPA1和SPB1不断的争夺对LUN1的读写控制,从而导致LUN的主控制器频繁在SPA1和SPB1之间切换。我们称这种情况为PathTrashing
下图的改良后的设计,同一个光线交换机连到了阵列的不同控制器上,这样就不会出现我们上面提到的情况了。
![](https://img-blog.csdn.net/20130531103329661)
问题描述:
本地存储在近年来的虚拟化架构设计中越来越受到关注,相比SAN来说,本地存储的成本低很多。是不是本地存储适合你的环境,还需要具体问题具体分析。本文仅以一个案例来帮你了解本地存储的利弊。
需求:
客户运行一个虚拟桌面的环境,目前大约有500台虚拟桌面,预计最多扩展到1000台。
虚拟机的主要用户是呼叫中心的客服人员。因为所有用户使用标准化的应用,采用PooledDesktop。虚拟机的RTO(RecoveryTime Objective)要求是1小时。也就是说如果一台虚拟机宕机,该用户在1小时内可以重新连接一台虚拟桌面。
客户的预算不多,存储设备如果花费很多的话有可能让这个项目夭折。
假设:
N/A
限制条件:
目前客户的共享存储的可用容量不能完全满足虚拟桌面项目的需求
架构设计倾向:
用户倾向考虑低成本的方案
架构推荐方案:
新建虚拟化平台的存储类型选择本地存储和Filer混合的方式。下图来自ABrief History of Desktop Storage Architecture一文
![k1 (Mobile).png](https://i-blog.csdnimg.cn/blog_migrate/79cd9663e9e1535843bd1aae090abff3.png)
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