解决方案 Dynamic News

智慧教育> 智慧工作>

学校的vsan方案

发布于2018-11-19 16:30    

学校的vsan方案

概述

1.1 项目背景

长期以来,XX学院学园网购置了大量的基础架构设备,其中混杂各种X86服务器,交换机及存储设备,服务器品牌不一、配置多样,还有多台承担数据库应用的服务器和存储设备。校园网上运行的各业务系统、教学资源库建设与管理采用分散、独立的模式,教师采用各种方式进行教学资源的分享,存储方式、分享渠道不统一。设备单体能力过剩,资源浪费严重,由于各单位采购的设备并不是很高端,设备可靠性较低,扩展性比较差,各单位都是自行管理,管理水平参差不齐,服务整合能力弱,不便统一管理
以前,存储都是在项目开始阶段配置和部署的,在其生命周期中不再更改。如果要求更改虚拟机所利用的 LUN 或卷的某些方面或功能,则在许多情况下,需要删除原始 LUN 或卷并创建具有所需功能的新卷。这是 一项干扰性很强且非常耗时的操作,可能需要花费数周的时间进行协调。
 
软件定义的存储旨在通过主机上与底层硬件集成并对其进行抽象化处理的软件层实,现存储服务和服务级别协议的自动化。
通过软件定义的存储,可以动态 满足虚拟机存储要求,而无需重新调整 LUN 或卷。虚拟机工作负载可能会随着时间的推移有所变化,而底 层存储可以随时适应工作负载。通过软件定义的存储,可以动态满足虚拟机存储要求,而无需重新调整LUN或卷。虚拟机工作负载可能会随着时间的推移有所变化,而底层存储可以随时适应工作负载。

1.2 现状分析

下图是来自IDC在2013年11月对IT公司的调研数据,如图所示,随着业务的不断增加,对存储的需求成指数上升。根据预测,未来两年对存储的需求增长为每年41%。

图:存储增长趋势
同时,存储面临多重挑战:首当其冲的就是如何在满足不断激增的应用和存储需求的同时,满足客户的SLA。其后,是故障排除和数据迁移过于复杂。如何在更少的时间应用更少的成本满足业务部门的SLA需要,在不失策略控制的前提下,简化、自动化管理流程,成为企业IT部门在存储领域的关切点。
以前,存储都是在项目开始阶段配置和部署的,在其生命周期中不再更改。如果要求更改虚拟机所利用的 LUN 或卷的某些方面或功能,则在许多情况下,需要删除原始 LUN 或卷并创建具有所需功能的新卷。这是 一项干扰性很强且非常耗时的操作,可能需要花费数周的时间进行协调。

图:存储压力来源
软件定义的存储旨在通过主机上与底层硬件集成并对其进行抽象化处理的软件层实,现存储服务和服务级别协议的自动化。
通过软件定义的存储,可以动态 满足虚拟机存储要求,而无需重新调整 LUN 或卷。虚拟机工作负载可能会随着时间的推移有所变化,而底 层存储可以随时适应工作负载。通过软件定义的存储,可以动态满足虚拟机存储要求,而无需重新调整LUN或卷。虚拟机工作负载可能会随着时间的推移有所变化,而底层存储可以随时适应工作负载

1.3  本次项目逻辑示意图

 

软件定义的存储

2.1 数据中心虚拟化对存储提出新的要求和挑战

随着虚拟化成为基础架构主要的工作负载机制,数据中心的存储设计面临前所未有的挑战:

图:面临三个领域的挑战
第一个挑战是管理复杂、不灵活。存储一直是虚拟化架构设计中最关键的环节之一。很多性能的问题都和存储有关。虚拟化架构师需要了解很底层的存储设备及其特性,需要在IOPS,Latency和容量等各个方面优化。另外存储的分层、扩展和运维都有很多考虑的方面。在引入软件定义的存储以前,存储都是在项目开始阶段配置和部署的,在其生命周期中不再更改。如果要求更改虚拟机所利用的LUN或卷的某些方面或功能,则在许多情况下,需要删除原始LUN或卷并创建具有所需功能的新卷。这是一项干扰性很强且非常耗时的操作,可能需要花费数周的时间进行协调。
第二个挑战是费用昂贵。如果数据量很大,特别是用存储光纤网络(SAN)的情况下,那是虚拟化平台烧钱的很大一块,平庸的存储设计看起来四平八稳循规蹈矩,殊不知可能会在存储上开销很大。
第三个挑战是无法确保差异化服务等级。由于数据存储选择LUN时并不考虑每个虚拟机的性能和可用性要求,因此难以在存储方面保证SLA。在每个卷中包含多个VMDK的情况下,很难排除性能问题。
虚拟环境的数据中心,要求存储能够提供新的特征:
u  提供虚拟机精确控制
u  在应用高度整合的情况下满足性能要求
u  提供与vSphere相同级别的应用和数据移动性
u  支持快速调配零停机操作
u  按需动态扩展
u  支持VDI和大数据等新应用
这些新特性是传统的存储所不能满足的,因此软件定义的存储应运而生。它从前文提及的三个维度解决虚拟化数据中心面临的问题和挑战:简化存储的管理、降低总拥有成本、实现端到端的SLA交付。

图:解决三个领域的挑战

2.2 什么是软件定义的存储

到底什么是软件定义的存储呢?在引入这个概念之前,我们先来看一下市场发展趋势:
数据业务正在以指数形式增长。IDC预测在2011到2015年,数据业务将增长9倍。驱动数据业务增长的主要驱动是新的应用和现有应用的结合,随着社交媒体到大数据业务的广泛产生,现有的数据管理面临巨大的挑战。有益于摩尔定律,我们正处于一个历史上数据业务增长最迅猛的时期。到2014年,平均的CPU将达到32线程,每个处理器插槽将拥有32个逻辑CPU——16核乘以2个线程。HDD容量迅速扩展,到2016年有望到达60TB之高。而从一个高性价比的观点来看,SSD已经成为CPU/内存与HDD的重要纽带。

图:三大趋势推进软件定义的存储
软件定义的存储是软件定义的数据中心的基本组件,可对存储资源进行抽象化处理,以支持存储的池化、复制和按需分发。这使存储层与虚拟化计算层非常相似:都具有聚合、灵活、高效和弹性扩展的特点。它们的优势也如出一辙:全面降低了存储基础架构的成本和复杂性。
综合来看,软件定义的存储具备如下三个特征:
Ø  以应用为中心的策略,可实现存储使用自动化
软件定义的存储支持对异构存储池中的所有资源实施一致的策略,使存储的使用像为每个应用或虚拟机指定容量、性能和可用性要求那样简单。这种基于策略的自动化最大限度地利用了底层存储资源,同时将管理开销降至最低。
Ø  与硬件无关的虚拟化数据服务
数据服务(如快照、克隆和复制)作为虚拟数据服务在软件中交付,并按虚拟机进行调配和管理。独立于底层存储硬件使得这些服务的分配极其敏捷和灵活。
Ø  通过硬盘和固态磁盘虚拟化确保数据持久性
随着服务器功能的增多,软件定义的存储解决方案可让企业利用廉价的行业标准计算硬件来扩大其存储资源。利用固态磁盘和硬盘作为虚拟机的共享存储,可获得高性能、内置的恢复能力和动态可扩展性,并将存储总体拥有成本降低50%之多。

VMware软件定义的存储解决方案描述

VMware是这样定义“软件定义的数据中心”的:所有的基础设施都被虚拟化,并以服务的形式提供,对数据中心的控制完全由软件自动化完成。
软件定义的数据中心改变了传统数据中心的运行和管理模式。数据中心已经转由运行在基于x86服务器的虚拟化软件所管理,这种转变提供了极大的灵活性和控制,同时提高了效率,也大大降低了成本。软件定义数据中心最关键的组成部分是计算、网络和存储。

图:SDDC模块组件
存储这个领域相对于软件定义的计算和网络稍显滞后。然而,存储的产业和市场需求是非常庞大的。VMware在服务器级别先进的技术促成了一种新的存储模式,也就是所谓的软件定义的存储(SDS)。在深入介绍这个概念之前,先来了解一下存储随着虚拟化的发展发生的演进。
同时从控制层面和数据层面进行虚拟化是SDS的核心原则。通过软件并基于x86服务器平台的虚拟化层来交付存储资源是SDS的另外一个核心原则。同时,外接存储仍然在交付企业存储资源中扮演非常重要的角色。所以,VMware认为,把服务器直连存储和汇聚在虚拟化层的外接存储结合起来,建立一种可扩展的,高性能且高可靠的存储架构,可以获得最高的性价比。

图:SDDC|SDS

3.1VMware软件定义的存储

如前文阐述,软件定义的存储是软件定义的数据中心的重要支柱之一,它把应用于服务器的先进技术运用于存储领域,可对异构存储资源进行抽象化处理,以支持存储在逻辑上的池化、复制和按需分发。并以应用为中心进行消费和管理,并实现基于策略的自动化。
VMware在软件定义的存储方面的计划主要侧重于一系列围绕本地存储、共享存储和存储/数据服务的计划。从本质上来说,VMware希望使vSphere成为一个存储服务平台。软件定义的存储旨在通过主机上与底层硬件集成并对其进行抽象化处理的软件层,实现存储服务和服务级别协议的自动化。
软件定义的存储的一个关键因素是基于存储策略的管理(SPBM)。SPBM可以视为新一代VMware vSphere存储配置文件功能。SPBM是VMware实施软件定义的存储的一个关键要素。使用SPBM和VMware vSphere API,底层存储技术会呈现一个抽象化的存储空间池,为vSphere管理员提供用于虚拟机调配的各种功能。这些功能可能与性能、可用性或存储服务(例如VMware vSphere Thin Provisioning)有关。然后,vSphere管理员即可使用虚拟机上运行的应用所需的部分功能创建虚拟机存储策略。在部署时,vSphere管理员可根据虚拟机的需要选择恰当的虚拟机存储策略。SPBM会将要求向下推送至存储层。这时将启用多种数据存储以供选择,这些数据存储可提供虚拟机存储策略中包括的各种功能。这意味着系统将始终根据虚拟机存储策略中设置的要求,在恰当的底层存储上创建虚拟机实例。如果虚拟机的工作负载随时间推移发生变化,只需将具有能够反映新工作负载的最新要求的策略应用于虚拟机即可。

图:软件定义的存储
软件定义的存储通过纯软件实现了存储相关的三个层面的功能:
u  通过策略自动化消费存储资源:以虚拟机为中心的安置、保护和性能策略
u  基于虚拟化的不依赖于硬件的数据服务:以虚拟机为中心的快照、克隆、复制、备份
u  通过虚拟化管理程序提取出存储抽象层:以数据存储和VMDK形式使用的异构存储
贯穿这三个层面,VMware提供对应于分布式存储DAS的解决方案Virtual SAN。

3.2 Virtual SAN部署要求

下一节将详细介绍创建Virtual SAN集群必须满足的硬件和软件要求。

3.2.1 vSphere要求

3.2.1.1vCenter Server

Virtual SAN至少需要VMware vCenter Server版本5.5 U1。vCenter Server的Microsoft Windows版和VMware vCenter Server Appliance均可管理Virtual SAN。Virtual SAN通过 VMware vSphere Web客户端进行配置和监控,这同样需要VMware vCenter Server版本 5.5 U1。

3.2.1.2 vSphere

一个Virtual SAN至少需要三台vSphere主机(其中每台主机均具有本地存储)以形成受支持的Virtual SAN集群。这样,集群才能达到至少允许一台主机、磁盘或网络发生故障的最低可用性要求。vSphere主机至少需要vSphere版本5.5 U1。

3.2.2 存储要求

3.2.2.1 磁盘控制器

Virtual SAN集群中的每台vSphere主机均需要一个磁盘控制器。它可以是SAS/SATA主机总线适配器(HBA)或RAID控制器。不过,RAID控制器必须在通常称为直通模式或HBA模式的环境下运行。换言之,它必须能够将底层硬盘驱动器(HDD)和固态磁盘(SSD)作为不具有RAID层的独立磁盘驱动器向上传递。这很有必要,因为如果定义了虚拟机的可用性和性能等策略属性,则Virtual SAN将会管理所有RAID配置。Virtual SAN的硬件兼容性列表(HCL)会列出已通过测试阶段的控制器。
集群中将本地存储提供给Virtual SAN的每台vSphere主机均必须至少具有一块HDD和一块SSD。

3.2.2.2 硬盘驱动器

每台vSphere主机在加入Virtual SAN集群时均必须至少具有一块HDD。HDD构成Virtual SAN数据存储的存储容量。附加HDD不仅可以增加容量,还可能提高虚拟机性能。这是因为虚拟机存储对象可能以条带形式供多个磁盘组使用。在本文稍后探讨存储策略时,将对此进行更加深入具体的介绍。

3.2.2.3 固态磁盘

每台vSphere主机在加入Virtual SAN集群时均必须至少具有一块SSD。SSD可提供写缓冲区和读缓存。主机具有的SSD容量越大,性能就越强,因为可以缓存更多的I/O。
注意:SSD不会影响分布式Virtual SAN数据存储的总体大小。

3.2.3网络要求

3.2.3.1网卡

每台vSphere主机必须至少具有一个网卡(NIC)。网卡速度必须能达到1Gb。不过,作为最佳实践,VMware 建议使用10Gb网卡。为实现冗余,可以为每台主机配置一组网卡。VMware将此视为最佳实践,但不认为这对于构建功能完善的Virtual SAN集群来说是必要的。

3.2.3.2支持的虚拟交换机类型

Virtual SAN在VMware vSphere Distributed Switch (VDS)和vSphere标准交换机(VSS)上均受支持。在初始版本中,不支持其他任何虚拟交换机类型。

3.2.3.3VMkernel网络

在每台vSphere主机上,必须创建用于Virtual SAN通信的VMkernel端口。VMkernel端口标记为Virtual SAN。当集群中的一台vSphere主机拥有特定虚拟机时,此端口将用于集群间的节点通信,也用于读写操作,但组成虚拟机文件的实际数据块位于集群中的另一台vSphere主机上。在这种情况下,I/O必须通过在集群中的主机之间配置的网络进行传输。
需要注意的是:并不是Virtual SAN集群中的每个节点都需要有本地存储;没有本地存储的主角仍然能够利用分布式数据存储。
 

图:Virtual SAN硬件需求

3.3 解决方案设计

3.3.1 方案概括

一个 Virtual SAN 群集最初由 3到 32 个X86服务器节点组成,每个节点必须至少有一个 全新的SSD 和一个全新的SAS 磁盘驱动器。这些计算节点并不会专用于 Virtual SAN:它们也会为各种正常的 vSphere 工作负载提供支持。
 

图:基础架构
  Virtual SAN 会在创建群集时“开启”;这样,新的存储资源就会像计算资源一样透明地添加到池中。
 运行Virtual SAN 的每个服务器节点最多支持 5 个磁盘组。每个磁盘组有1~ 7 个HDD磁盘,但必须有一个的 SSD。这些磁盘可以是内部磁盘,也可以是通过JBOD 进行认证的外部磁盘。之所以有磁盘组的概念是因为,允许主机内多个SSD参与读写缓存的工作,并把故障域缩小到一定范围内。

图:磁盘组
  SSD充当分布式读写缓存,并不用于永久保存数据。每个磁盘组只支持一个SDD:70%的SSD 容量用于缓存读取,其余30% 用于写入。可以在取消向磁盘暂存之前,在两个或两个以上节点之间镜像缓存写入来对该缓存写入进行保护。也可以使用多节点镜像来防止发生磁盘故障和节点故障。
Virtual SAN 可在所有节点之间提供一个集中的数据存储,供虚拟机及其 VMDK 使用。可以在同一个 Virtual SAN 数据存储实施多种策略(冗余、性能),无需预先创建常用的存储池:金级、银级等。
Virtual SAN 可对所需的策略进行监控,并且只要有足够的资源,也可以根据需要进行自我调整:条带化数据对象、使用更多 SSD 缓存等。
目前,Virtual SAN 的数据服务都由 vSphere 提供:快照、链接克隆、复制、vSphere HA、DRS、VDP,或者通过第三方技术合作伙伴提供。此外,Virtual SAN 具有卓越的“节点撤离功能”,可以在关闭节点进行维护或更换之前,重新定位正在运行的进程及其相关存储。
在 vSphere 群集中,并非所有节点都需要具有本地存储;没有磁盘的节点可通过网络访问 Virtual SAN 数据存储。

3.3.2应用于虚拟桌面场景的方案框架(可选)


图:虚拟桌面的存储
Ø  Virtual SAN 是适用于 VDI 的理想解决方案
·   经过闪存加速的体系结构可处理写入密集型工作负载的峰值需求(启动风暴、登录风暴等)
·   可与 Horizon View 产品互操作以实现简单性和易用性
·   能够精确地从概念证明扩展到生产以避免超额配置
·   极具吸引力的性价比可提供一流的性能和价值
·   无缝的按需求扩展,避免了前期的巨额投资
·  支持高密度VDI
 
图:Virtual SAN的扩展
传统虚拟桌面环境(VDI)的共享存储,在进行扩展的时,需要增添服务器和存储阵列;而采用Virtual SAN作为VDI存储的时候,仅需要扩展服务器,依靠服务器内的本地存储来增加虚拟共享存储容量。可以说,VDI的存储包含在单独的服务器里,纵向可以通过添加磁盘进行扩展,横向可以通过增加新的服务器节点,新的节点需要包含SSD和HDD磁盘。这样的最大好处是可以根据需要平滑扩展,降低前期投资。企业可以快速从POC测试环境转化到生产环境,同时免除了对外界存储的设计和容量规划。最重要的是,应用的性能并没有下降,服务器内的SSD层把应用的延迟/相应时间降到了毫秒级。
Virtual SAN在和View结合使用时,Horizon View 可用性策略如下(默认且推荐、可修改):
Ø  全克隆策略
·   FTT = 1 永久
·   FTT = 0 非永久
Ø  链接克隆策略
·    OS Disk: FTT = 1 专属池
·    OS Disk: FTT =  0 浮动池
·    Replica Disk: FTT = 1

3.3.3应用于2、3层应用或测试和开发的方案框架(可选)


图:通用使用场景
Ø  Virtual SAN 是适用于服务器工作负载的理想解决方案
·   在服务器层调配和管理存储非常简单快捷
·   内置在 ESXi 内核中以提高性能
·    基于策略的体系结构可自动执行常规存储功能
·    可基于任何 x86 硬件运行并通过 vSphere Web Client 进行管理
·    基于私有云的2\3层级测试和开发
·     理想性价比
·     数据中心占地面积最小化

图:基础架构
如上图所示,每个ESXi主机贡献SSD和HDD磁盘容量。Virtual SAN把这些资汇集到vSphere群集的一个数据存储中。每个虚拟机的home文件夹和每个虚拟磁盘以一个Virtual SAN对象的形式存放。虚拟机在vSphere群集中的某个主机上运行,如果主机故障,HA和DRS会让虚拟机在其他的主机上重启。Virtual SAN 对象能够分成多个组件来提升性能和数据保护,这些都由存储策略监管。

3.3.4应用于灾备的方案框架(可选)


图:容灾方案框架
Ø  Virtual SAN 是适用于灾难恢复的理想解决方案
·   以应用为中心的数据保护,自动化的灾难恢复
·    与vSphere Replication和VMware SRM集成
·    SRM 互操作性:自动化的灾难恢复编排功能可降低 RTO 和运营开销
·    较低的存储成本:Virtual SAN 可充分利用基于 x86 的
异构硬件设备
·    灵活性,可用于任何虚拟化应用、任何存储
·     数据中心占地面积最小化
Virtual SAN恢复能力强,可以抵抗任何硬件故障,如下图所示Virtual SAN 旨在确保出现故障时决不会丢失任何数据。Virtual SAN的恢复能力易于通过策略进行设置,并且按虚拟机进行交付,由于在其他节点设置了副本,可以做到发生磁盘、网络或主机故障时的零数据丢失,确保在磁盘或网络故障时实现零停机。此外,可与 vSphere HA 和维护模式互操作,将基础设施模块化以通过中断修复模式。实现更高效的数据中心运营。

图:Virtual SAN可抵御硬件故障
 
如下图所示,vSphere Replication可以把任意类型的存储复制到Virtual SAN中:

图:目标站点复制到Virtual SAN
同时,可以为灾备对象选择磁盘级或虚拟机级别的存储策略:

图:存储策略

3.3.5规划设计细则

Virtual SAN利用多个服务器的本地存储构建成一个共享的分布式数据存储(datastore)。这个数据存储的容量是由组成Virtual SAN群集的多个主机里面的磁盘组汇集而成的。这些主机可以是vSphere群集的一个子集。 Virtual SAN数据存储的总容量就是Virtual SAN群集主机里HDD磁盘的容量之和。SSD磁盘的容量仅专用于Virtual SAN的缓存层,不记算在存储容量中。

3.3.5.1 容量规划相关的概念

在分析容量规划前,首先引入三个概念:
Ø  对象(Object)
Individual storage block device that is compatible with SCSI semantics.
每对象以多个组件(component)的形式储存在Virtual SAN数据存储中。对象是设置存储策略的最小单位,可通过VM存储档案(VM Storage Profiles)为不同对象设置性能和可用性的策略服务。
对象有四种类型:
VM Home:放置虚拟机配置文件(.vmx, log文件等)
交换Swap:仅在虚拟机开机时候产生
VMDK:虚拟机磁盘文件
快照:VM级别的快照存储对象
Ø  组件(Component)
对象由分布到不同主机节点的组件构成。Virtual SAN5.5中,每个主机目前支持最多3000个组件。容量大于255GB的对象自动分成多个组件。每个组件消耗2MB的磁盘容量存放元数据。
Ø  仲裁(Witness)
每个存储对象都存在仲裁组件。只储存对象的元数据。 仲裁扮演裁判的角色,在主机故障是,决定哪个含有备份的主机来接管服务。用来防止脑裂。每个Virtual SAN仲裁组件消耗2MB用来存放元数据。

3.3.5.2 需要考虑的因素

了解存储的可靠性和性能对存储容量消耗的影响非常重要。在规划Virtual SAN数据存储容量时需要考虑的因素有:
允许的故障主机数:Number of Failures to Tolerate
对象的磁盘条带数:Number of Disk Stripes per Object
缓存的预留:Flash Read Cache Reservation
对象空间预留:Object Space Reservation
Ø  磁盘组(Disk Group)
前文提及一个磁盘组包含一个flash设备(SAS/SATA/PCIe SSD)和一个或多个磁盘设备 (SAS/SATA HDD)。磁盘组共享分布式缓存层和Virtual SAN数据存储的存储空间。
Virtual SAN文件格式采用的是修改过的的VMFS文件系统:VMFS-L,以一个单独的数据存储形式加载到ESXi的对象存储文件系统中。
VMFS-L 的文件系统格式每个磁盘需要消耗750MB的磁盘空间。

图:磁盘组设计
Ø  允许故障主机数
允许故障主机数是在Virtual SAN中对存储容量影响最大的因素。基于对VM的可靠性需求,设定不同的存储策略,最多可以致使一个VM占用与之前相比四倍的磁盘空间。
Ø  对象的磁盘条带数
如果对象的条带数超过默认值1,那么每个条带将算为一个拆开的组件(component),这将会影响主机可支持的组件总数。
Ø  磁盘组(Disk Group)设计
· 每个磁盘组一个flash设备
·  如果主机包含多个flash设备,需要建立多个磁盘组来利用额外的flash设备
·  Flash设备容量与磁盘容量比例越高,缓存层的厚度越大。
·  需要定义并尽可能减少存储的故障域,故障域的概念如下图所示。

图:故障域
Ø  SSD容量设计
推荐的Virtual SAN的flash磁盘(SSD)容量是HDD总容量的10%(在考虑最大允许故障主机之前)。如下图所示,如果规划的每个VM需要20GB的空间,有1000个VM,那么总的为VM规划的存储空间需求大约是20TB,按推荐的10%flash来计算,总的flash容量需求为2TB。

图:Flash设计举例
在实践中,总的flash容量比例应该基于使用案例和存储容量对性能的需求。

3.3.5.3 容量计算公式

Ø  常量:
VSAN 组件和VMFS元数据开销 (VSANmetaDataOverhead):     1GB/磁盘
Ø  变量(以下数字为计算举例):
群集主机数:Number of Hosts Per cluster (Hst) = 8
每个主机的磁盘组数:Number of Disk Groups (DskGrp) = 5
每个磁盘组的磁盘数:Number of Disks Per Disk Group (DskPerDskGrp) = 7
磁盘容量:Size of Disks (SzHDD) = 4000 GB
允许故障主机数:Number of Failures To Tolerate (ftt) = 1
每主机支持VM数:Number of Virtual Machines (VMs) = 800
每个虚拟机的磁盘数 (NumOfVMDK) = 1
每个VM的内存 (vmSwp) = 10 GB
 
VSAN群集的毛容量
公式: Hst x NumDskGrpPerHst x NumDskPerDskGrp x SzHDD = y
例如: 8 x 5 x 7 x 4000 GB =1,120,000 GB =1,120 TB
 
VMFS元数据
 • 公式: VMFSMetadata x NumDskGrpPerHst x NumDskPerDskGrp = y
 • 例如: 750 MB x 5 x 7 = 26,250 MB = 26.2 GB VMFS 元数据
 
对象
 • 公式: VMs x [VMnamespace + vmSwap + NumOfVMDK] = y
 • 例如: 800 x [1 + 1 + 1] = 2400 Objects
注: 如有快照, 克隆或大于1 的磁盘条带,则需要增加对象
 
组件
 • 公式: Object x [ftt x 2 + 1] = y
 • 例如: 2400 x (1 x 2 + 1) = 7200 组件 = 900 组件/主机 (每主机最大3000个组件)
 
组件元数据
 • 公式: NumComponents x compMetadata = y
 • 例如: 7200 组件 x 2 MB = 14.4 GB 组件元数据
VSAN元数据
 • 公式: compMetadata + VMFSMetadata = y
 • 例如: 14.4 GB + 26.2 GB = 40.6 GB VSAN 元数据
 • 简化公式:  NumDskGrpPerHst x NumDskPerDskGrp x NumHosts x 1 GB = y
 • 简化公式例如:  5 x 7 x 8 x 1 GB = 280 GB
        • 每个磁盘组1GB元数据考虑到快照条带等因素
 
交换的空间占用Swap Utilization
 公式: (VMs x vmSwp x 2)
 例如: Swap Space = (100 x 10GB x 2) = 2000 GB
       可获得容量Available Capacity = 毛容量Raw Capacity – 交换容量Swap Capacity = 1120000 GB – (100 x 10GB x 2) = 1120000 – 2000 = 1118000 = 1,118 TB 磁盘容量Disk Capacity
 
可用容量Usable Capacity
• 公式: (DiskCapacity – VSAN Meta Data) / (ftt + 1)
• 例如: (1118000 GB - 41 GB) / 2 = 1117959 GB / 2 = 558,980 GB 可用容量
最佳实践建议分配给使用的容量不超过虚拟磁盘容量的80%

3.3.5.4 内存和CPU

Virtual SAN需要的内存取决于虚拟化层管理的磁盘组个数和其中的磁盘个数。只要vSphere主机有多于32GB的RAM内存,就足以支持Virtual SAN允许的最大磁盘组数和最大磁盘数(5*7=35个HDD)。
考虑到Virtual SAN部署的高度整合性和应用对CPU的需求,Virtual SAN在开发设计时就把目标定在每个主机占用不超过10%的CPU额外开销。

3.3.5.5 网络

Virtual SAN 的网络活动能够占满1GbE的网络,尤其在故障后重建和同步的操作时。如果采用1GbE网络就必须要独占整个带宽。
通过VLAN把不同的流量(管理,vMotion,VM,Virtual SAN)隔离开并加以不同权重是保障QoS、在某些可能的拥塞使用场景维持一定服务等级的有效方法。最佳实践推荐使用10GbE的网络。
Virtual SAN 需要在2层物理网段的开启IP 多播功能来供Virtual SAN 的通信。

3.3.6 部署最佳实践

在部署Virtual SAN时有如下几个宗旨:
u  不要只用Virtual SAN群集中的少数主机存放全部存储对象
u  不要只用Virtual SAN群集中的少数主机运行全部的虚拟机
u  虚拟机默认都是精简配置
根据这件宗旨,VMware做出如下推荐:
u  在一个Virtual SAN数据存储内最多3200个虚拟机,这只是初期版本的软限制,以后这个数值会增加
u  存储设备(SSD,HDD)需要平均分配到集群中的所有主机。否则,Virtual SAN集群内可支持的最大虚拟机数会受到影响。
u  开启的虚拟机(在Virtual SAN数据存储中)需要平均分布到集群中的所有主机。在稳定模式下(即无主机故障时)大约100个虚拟机/主机/Virtual SAN数据存储。否则,将无法达到最佳性能。VMware推荐的最佳实践是群集内每个主机采用相似的存储配置来达到平均的群集分布。
u  SSD是提升性能的重要因素。如果虚拟机负载要求高性能,可以考虑部署多个高SSD:HDD比例的磁盘组,也可以考虑更高性能的SSD硬件。
u  需要注意的是随着虚拟机尺寸的增加,需要在Virtual SAN群集添加存储,尤其在过量分配开启并达到容量上限的时候。
 

4  可扩展DAS方案——Virtual SAN产品描述

Virtual SAN是专为虚拟机设计的极其简单的存储,它具有速度快、恢复能力强、具有动态性等优点,并且在性能大致相当的情况下,总体拥有成本降低达50%。

4.1  Virtual SAN简介

VMware Virtual SAN是全新的软件定义的存储层,可以扩展vSphere虚拟化管理程序以将计算和直连存储池化。通过建立服务器直连硬盘和固态硬盘(HDD和SSD)集群,Virtual SAN可创建专门针对虚拟机设计和优化的分布式共享数据存储。
Virtual SAN内置在vSphere内核中并采用分布式体系结构:利用SSD提供高性能读/写缓存,利用HDD确保经济高效的数据持久性。该技术基于高度可用的体系结构并且无单点故障。它可以应对磁盘、服务器和网络级别的故障并且不丢失数据,因为它内置了冗余机制,可以为磁盘和主机上的数据透明地存储多个副本。
Virtual SAN实现了基于策略的存储管理方法。您可以通过将简单策略与各个虚拟机或虚拟磁盘关联起来指定存储属性,如容量、性能和可用性。存储可以根据指定的策略立即完成资源调配和自动配置。无论位于集群中的什么物理位置,虚拟机都会维持自己的独特策略。工作负载条件变化时,Virtual SAN会动态地自行调整并实现负载平衡,以遵守每个虚拟机的策略。

图:Virtual SAN介绍
分布式存储的主要特点是:
u  完全在Hypervisor层实现,无需其他硬件和软件
u  与已有的vSphere管理整合,极大的简化了存储层的管理
u  充分利用DRS实现对运算、存储和网络资源的全面优化分配
u  存储策略的制定可以具体到某个VM
u  扩展性和存储集群

4.2 功能和优势

4.2.1 主要特性和功能

VMware Virtual SAN体现了VMware软件定义存储愿景的第一个例子。它在全面集成的直连磁盘解决方案中纳入基于策略的控制层、以应用程序为核心的服务以及虚拟数据层。VMware Virtual SAN采用分布式架构,利用SSD实现高性能的读/写缓存,并利用硬盘实现高成本效益的数据长期保存。功能特性包括:
内置在vSphere内核中——Virtual SAN在vSphere内核内部实施。Virtual SAN与vSphere的无缝集成非常独特,置入VMware vSphere内核的VMware Virtual SAN将提供最佳性能和可扩展性。简单的一键式部署——VMware Virtual SAN易于配置和部署,如下图所示,只需要单击对话框就可完成。

图:vSphere内置一键开启Virtual SAN
读/写I/O缓存——Virtual SAN通过在服务器端闪存中内置缓存,加快读/写磁盘I/O的速度,将存储延迟降到最低限度。
内置故障防护——该技术利用分布式RAID和缓存镜像确保磁盘、主机或网络发生故障时绝不丢失数据。
无中断容量可扩展性——您可以通过为集群添加主机或为主机添加磁盘,轻松地无中断扩展Virtual SAN数据存储的容量。
以虚拟机为中心的基于策略的管理——该解决方案采用可自动转换为系统配置的策略语句,将存储要求与各个虚拟机或虚拟磁盘关联起来。采用该方法,IT人员可以立即调配存储以严格遵守服务级别协议(SLA)。
自行调节存储和动态存储负载平衡——Virtual SAN自动无中断地保持为每个虚拟机指定的存储容量、性能和可用性级别。该技术可以与VMware vSphere Distributed Resource Scheduler进行互操作,实现端到端计算和存储平衡。
与vSphere数据服务集成——该解决方案利用vSphere快照、vSphere克隆、VMware vSphere Data Protection和vSphere Replication,跨集群或站点提供数据保护、备份、快速克隆和数据传输以便进行灾难恢复。
与vSphere Web Client集成——Virtual SAN通过vSphere Web Client进行管理,借助vSphere实现单一窗口管理。
广泛的硬件兼容性——Virtual SAN是独立于硬件的解决方案,可以在所有服务器OEM厂商提供的硬件上部署。
与VMware Horizon View和VMware vCenter Site Recovery Manager互操作——该解决方案可以与Horizon View一起部署在虚拟桌面基础架构(VDI)环境中,可以与vCenter Site Recovery Manager一起部署在灾难恢复环境中。

4.2.2 优势和应用场景

专为虚拟机设计的极其简单的存储——Virtual SAN可以大大简化虚拟机的存储调配和管理。只需要直接在vSphere Web Client中单击几下即可快速完成存储调配。作为自行调节的系统,Virtual SAN 可以根据每个虚拟机的要求进行自我优化,以提供适当的 SLA。
在性能相当的情况下,大幅降低总体拥有成本 ——Virtual SAN利用价格便宜的服务器磁盘和闪存、采用 vSphere标准网络连接、减少电源和散热成本并通过自动化提高运营效率,从而大幅度降低存储资本开销和运营开销。
凭借“随增长而扩展”功能降低前期投资——与传统存储阵列不同,Virtual SAN不需要大量初始投资。您可以创建只包含三个服务器的Virtual SAN数据存储。此外,Virtual SAN还允许您更精细、更前瞻地扩展存储性能和容量,以配合计算资源的扩展。
VMware和广泛的体系支持——Virtual SAN是一种纯软件解决方案,与硬件无关,可以在所有主流服务器OEM厂商的硬件上使用,不依赖专用硬件。

图:Virtual SAN主要优势
Virtual SAN优势如下:
Ø  及其简单
·  单击两次即可完成安装
·   从 vSphere Client 中进行管理
·   基于策略的管理
·    能够自调节并具有弹性
·    与 VMware 产品体系深度集成
Ø  高性能
·    嵌入在 vSphere 内核中
·    经过闪存加速
·    32 节点的集群高达 200K IOPS
·    达到全闪存阵列的 VDI 密度
·     最高性价比
Ø  较低TCO
·     省去了大量的前期投入(资金开销)
·     可随增长扩展(运营开销)
·     能够灵活选择行业标准硬件
·     无需学习专门技能
那么Virtual SAN适合承载什么样的应用和业务呢?下图蓝色阴影表明了Virtual SAN适合的业务类型。横向来看,Virtual SAN适合中偏高级的服务级别,纵向来看,Virtual SAN适合对性能要求比较高而对容量要求没那么苛刻的应用和服务。

图:Virtual SAN服务定位
Ø  适合于 Virtual SAN 的理想工作负载要求:
·    高性能
·    中级服务级别(数据保护)
·    精确的性能和容量可扩展性
·    高性价比
·    简单性 - 由 vSphere 团队直接管理
·    网络隔离
Ø  主要使用情形:
·    VDI
·    第 II/III 层
·    生产前调试
·    DMZ
·    DR
Virtual SAN目前版本适合的应用场景举例如下图所示,需要补充一点的是,随着Virtual SAN版本的不断演进,还会支持更多的应用场景。

图:应用场景例举

4.3 体系结构

4.3.1  独立节点可靠阵列(RAIN)

RAIN的含义是独立节点可靠阵列,与独立磁盘可靠阵列(RAID)相对。简单地说,RAIN意味着数据中心的环境现在可以承受vSphere主机(或主机中的组件,例如磁盘驱动器或网络接口)故障,并可继续为所有虚拟机提供完整功能。不过,需要注意一点,即虚拟机可用性现在通过使用虚拟机存储策略按具体虚拟机逐一定义。现在,vSphere管理员可以使用存储策略定义Virtual SAN集群中的虚拟机能够容许多少个主机、网络或磁盘故障。如果选择在存储策略中将可用性功能设置为零,则主机或磁盘故障肯定会影响您的虚拟机可用性。
关于RAIN需要格外注意的另一点是,如果出现故障,无需将故障节点上的所有数据迁移至集群中的其他节点。凭借RAIN体系结构以及虚拟机存储策略的使用,虚拟机副本可保留在集群中的多个节点上。无需将故障主机上存储的数据撤出,因为数据已存在于集群中的其他位置。

图:针对可用性的SAN数据存储
如上图所示,虚拟机存储对象(虚拟机主目录、VMDK、增量、交换)可以分布在Virtual SAN集群中的多个主机和磁盘内。虚拟机可以使用复制副本提供可用性,或使用条带提供HDD性能。对于独立节点仅包括虚拟机的部分数据,这种分布式结构增加了原有数据的可靠性。

4.3.2 仲裁和副本

副本是为虚拟机指定可用性功能时创建的虚拟机存储对象实例的备份。可用性功能决定了可创建的副本数量。在集群中出现主机、网络或磁盘故障时,此机制可使虚拟机使用一组完整的对象继续运行。仲裁是每个存储对象的一部分。它们不包含数据,而仅包含元数据。其作用是在Virtual SAN集群中做出可用性决定时用作仲裁。仲裁在Virtual SAN数据存储上占用大约2MB的空间用于存储元数据。注意:要使某个对象在Virtual SAN中可访问,则其50%以上的组成部分必须可供访问。

4.3.3 固态磁盘的作用

固态磁盘(SSD)在Virtual SAN中具有两个作用:提供读缓存和写缓冲区。这可以显著提高虚拟机的性能。在某些方面,Virtual SAN可以与市场上的大量“混合”存储解决方案相媲美,后者也是使用SSD和HDD存储组合以提高I/O性能,并具有基于低成本HDD存储进行横向扩展的能力。
 

4.3.3.1 读缓存的作用

读缓存可以保留经常访问的磁盘块的缓存。这可减少缓存命中时的I/O读取延迟。虚拟机中运行的应用实际读取的块可能并非位于运行虚拟机的同一vSphere主机上。为解决这一问题,Virtual SAN会在Virtual SAN集群中的vSphere主机之间分发缓存块目录。这使vSphere主机可以确定是否另一台主机具有不在本地缓存中的缓存数据。如果确实如此,则vSphere主机会通过互连线路从另一台主机上检索缓存块。如果缓存块不在任何Virtual SAN主机中,则直接从HDD进行检索。

4.3.3.2 写缓存的作用

写缓存可用作非易失性写缓冲区。事实上,通过使用SSD存储来执行写入,还可以减少写入操作的延迟。由于写入的数据将进入SSD存储,因此自然需要确保在Virtual SAN集群中的其他位置有数据副本。部署到Virtual SAN的所有虚拟机都具有一项可用性策略设置,用于确保至少有一个额外的虚拟机数据副本可用,其中包括写缓存内容。
当客户操作系统(OS)中运行的应用启动写入之后,写入的数据将被并行发送到当前主机上的本地写缓存和远程主机上的写缓存。在确认写入前,写入的数据必须提交至上述两台主机上的SSD中。
这意味着如果某台主机出现故障,在Virtual SAN集群中的另一块SSD上还有一份数据副本,因此不会发生数据丢失。虚拟机将通过Virtual SAN互连线路访问另一个Virtual SAN主机上的数据副本。

4.4 基于存储策略的管理

前文曾提到,基于存储策略的管理(SPBM)目前在VMware的“软件定义的存储”愿景的策略和自动化方面发挥主要作用。使用虚拟机存储策略,管理员可以为虚拟机指定一组必需的存储功能,或者更具体地为虚拟机中运行的应用指定一组要求。这组必需的存储功能将被向下推送至存储层,存储层则检查可对此虚拟机的存储对象进行实例化以满足这组要求的位置。例如,集群中的可用条带宽度是否足以满足此虚拟机的要求。或者,集群中是否有足够数量的主机来满足“允许的故障数量”要求。如果Virtual SAN数据存储可识别虚拟机存储策略中设置的功能,则将在调配向导中作为匹配资源而亮显。因此,在部署虚拟机时,如果Virtual SAN数据存储可以满足虚拟机附带的虚拟机存储策略中的要求,则从其自身摘要窗口的存储角度看,可以认为该数据存储符合规定。如果Virtual SAN数据存储被超额分配或无法满足容量要求,则可能仍在部署向导中显示为匹配资源,但调配任务却失败。
SPBM现在可以提供策略驱动的自动机制,基于虚拟机存储策略中设置的所需存储功能,为虚拟机选择恰当的数据存储。

4.4.1 Virtual SAN功能

本节将介绍可以在虚拟机存储策略中设置的所需存储功能。这些功能在成功配置集群后由Virtual SAN数据存储
显示,它们着重说明了每个虚拟机上的存储所需的可用性、性能和大小要求。
如果未正确提出要求,换言之,如果将功能置于Virtual SAN数据存储无法检测到的存储级别,则Virtual SAN数据存储在调配期间将不再显示为匹配资源。

4.4.1.1 允许的故障数量

这一属性要求存储对象至少允许集群中的并行主机、网络或磁盘故障的“Number Of Failures To Tolerate”(允许的故障数量),并仍确保对象的可用性。
如果此属性已填充,则指定配置必须至少包含“Number Of Failures To Tolerate”(允许的故障数量)+1个副本,还可包含一个额外的仲裁对象以确保此对象的数据可用(维护定额以防裂脑),即使存在“Number Of Failures To Tolerate”(允许的故障数量)的并发主机故障,情况也不例外。因此,要容许n个故障,至少必须存在(n+1)个对象副本且至少需要(2n+1)台主机。
注意:单台主机上的任意磁盘故障均可视为符合此标准的“故障”。因此,如果将“Number Of Failures To Tolerate”(允许的故障数量)设置为1,则当主机A上出现一个磁盘故障,同时主机B上出现另一个磁盘故障时,此对象将无法保存。

4.4.1.2 每个对象的磁盘条带数

这可定义分布有存储对象的每个副本的物理磁盘的数量。如果读缓存无效的话,则高于1的值可能会提高性能,但会使用更多的系统资源。
为了解磁盘条带的影响,我们首先从写入操作方面对其进行了解,然后再从读取操作方面进行了解。由于写入的所有数据都将进入SSD写缓冲区,因此增加磁盘条带数量可能无法提高写入性能。这是因为无法保证新的条带使用不同的SSD。新的条带可能位于相同的磁盘组中并因此使用相同的SSD。磁盘条带数量增加能够发挥作用的唯一一种情况是在许多写入从SSD降级到磁盘时。
从读取角度来看,磁盘条带数量增加在您遇到许多缓存丢失时会有帮助。例如,如果虚拟机每秒处理2000个读取操作且缓存命中率为90%,则每秒将有200个读取操作必须通过HDD存储处理。在这种情况下,单个HDD可能无法处理这些读取操作,因此,磁盘条带数量增加对此会有所帮助。
通常,默认磁盘条带数量1能满足所有或大多数虚拟机工作负载要求。磁盘条带是仅在少量高性能虚拟机运行时才应更改的要求。

4.4.1.3 闪存读缓存预留

这是在SSD上预留的作为存储对象读缓存的闪存容量大小。它被指定为虚拟机磁盘存储对象的逻辑大小的百分比。它以百分比值(%)形式表示,具有四位小数。精细的粒度单位大小是必需的,这样管理员可以表达(sub–1)%单位。以1TB磁盘为例。如果我们将读缓存预留限制为1%的增量,会造成缓存预留以10GB增量增加,在大多数情况下,对于单个虚拟机来说,这样的增量过大。
注意:无需设置预留以获取缓存。预留应设置为0,除非您试图解决真正的性能问题。如果不预留缓存空间,则Virtual SAN调度程序可管理公平缓存分配。为一个虚拟机预留的缓存不可用于其他虚拟机。未预留的缓存在所有对象之间平等共享。
有关闪存读缓存预留的最后一点涉及读取性能。即使读取性能已可接受,仍可使用额外缓存避免更多读取进入HDD,从而减少缓存丢失。这可使更多写入进入HDD。因此,通过增加闪存读取缓存预留可以间接提高写入性能。不过,仅当从SSD向HDD刷新数据造成瓶颈时,才应考虑设置预留。

4.4.1.4 对象空间预留

此功能可定义初始化期间在HDD上应预留的存储对象的逻辑大小百分比。默认情况下,Virtual SAN数据存储上的调配为“精简”。“ObjectSpaceReservation”(对象空间预留)是在Virtual SAN数据存储上预留的空间量,指定为虚拟机磁盘的百分比。此值是必须预留的最小容量。此属性用于指定精简调配的存储对象。如果将
“ObjectSpaceReservation”(对象空间预留)设置为100%,则虚拟机的所有存储容量均预先提供。
注意:如果您调配虚拟机并选择厚磁盘格式lazy zero或eager zero,则此设置将覆盖虚拟机存储策略中的“ObjectSpaceReservation”(对象空间预留)设置。目前不推荐这样使用。

4.4.1.5 强制调配

如果启用此选项,则即使当时集群中的可用资源无法满足虚拟机存储策略中指定的功能,仍将调配对象。Virtual SAN将尝试在资源可用时使对象达到合规。如果此参数设置为非零值,则即使数据存储不符合虚拟机存储策略中指定策略的要求,仍将调配对象。不过,如果集群中有足够空间可满足至少一个副本的预留要求,则即使已打开“Force Provisioning”(强制调配),调配仍将失败。此选项默认为禁用。
 

4.4.2 仲裁示例

以下仲裁示例涉及磁盘条带数为1且“NumberOfFailuresToTolerate”(允许的故障数量)为1的虚拟机的部署。在这种情况下,将创建此虚拟机的两个副本。实际上,这是一个具有两个副本的RAID-1虚拟机。不过,只有两个副本,无法区分网络分区和主机之间的故障。因此,称为“仲裁”的第三个实体被添加到配置中。要使Virtual SAN上的对象可用,必须满足以下两个条件:
·         至少一个副本必须完整,可用于数据存储。
·         所有组件中,50%以上必须可用。
在上面的示例中,仅当存在对一个副本和一个仲裁或两个副本的访问权限时才可访问对象。这样,集群的一部分在网络分区情况下最多可以访问一个对象。
 

4.4.3 虚拟机存储策略

Virtual SAN中的虚拟机存储策略的工作方式与vSphere5.0中引入的vSphere存储配置文件类似,因为您构建了一个包含虚拟机调配要求的策略。与之前版本的vSphere存储配置文件相比,Virtual SAN中的虚拟机存储策略工作方式有一个主要区别。使用原始版本的vSphere存储配置文件,可以在调配虚拟机时使用策略中的功能选择恰当的数据存储。新的虚拟机存储策略不仅可选择恰当的数据存储,还能与对指定虚拟机具有特定可用性和性能要求的底层存储层通信。因此,当使用虚拟机存储策略调配虚拟机时,Virtual SAN数据存储可能成为目标数据存储,其他策略设置则规定可用性对虚拟机文件副本数量的要求,并且还可能包含性能方面的条带宽度要求。
 

4.4.3.1 启用虚拟机存储策略

启用Virtual SAN时将自动启用虚拟机存储策略。要手动启用虚拟机存储策略,必须导航到VMware vSphere Client主页位置,然后选择规则和配置文件。虚拟机存储策略部分位于此处。单击虚拟机存储策略将显示大量图标。其中一个图标可启用虚拟机存储策略功能。这可以按主机或集群启用。
 

4.4.3.2 创建虚拟机存储策略

启用虚拟机存储策略后,vSphere管理员可使用这一窗口中的另一个图标创建各个级别。如前所述,大量与可用性和性能相关的功能将由vSphere API呈现。此时,管理员必须从性能和可用性的角度决定哪些功能是虚拟机内部运行的应用所必需的。例如,管理员要求此虚拟机在继续正常运行的情况下允许多少次组件故障(主机、网络和磁盘驱动器)?或者从IOPS的角度来看,此虚拟机中运行的应用是否要求严苛?如果是,那么闪存读缓存预留可能是满足性能的一项必需功能。其他注意事项可能包括决定虚拟机是进行精简调配还是厚调配。
在本示例中,虚拟机存储策略创建了两个功能。这两个功能分别与可用性和性能有关。 “NumberOfFailuresToTolerate” (允许的故障数量)定义了可用性,而磁盘条带则定义了性能。

图:创建新的虚拟机存储策略
注意:vSphere5.5 U1还支持对调配使用标记。因此,不会将Virtual SAN数据存储功能用于虚拟机存储策略创建,而可能会创建基于标记的策略。基于标记的策略的使用不在本白皮书范围之内,但在vSphere存储文档中可以找到详细信息。
 

4.4.3.3   在虚拟机调配期间分配虚拟机存储策略

虚拟机存储策略的分配发生在虚拟机调配期间。当vSphere管理员必须选择一个目标数据存储时,他们会从可用虚拟机存储策略下拉菜单中选择恰当的级别。然后,数据存储会分为兼容的数据存储和不兼容的数据存储,从而使vSphere管理员可以选择准确恰当的位置来安置虚拟机。
 

4.4.3.4 虚拟机对象

就Virtual SAN数据存储上的对象布局而言,虚拟机具有大量不同的存储对象。虚拟机磁盘文件(VMDK)、虚拟机命名空间目录(虚拟机配置和日志文件所在的目录)、虚拟机交换文件和快照增量文件全都是独特的存储对象。每个对象可能都有不同的存储策略。vSphere UI还使管理员能够查询虚拟机对象布局以及查看存储对象的每个组件(条带、副本和仲裁)所在的位置。

图:存储对象物理映射
 

4.4.3.5匹配资源

当虚拟机调配向导报告Virtual SAN数据存储是虚拟机存储策略的匹配资源时,可保证数据存储了解了策略中定义的所有要求。这并不意味着数据存储一定能够满足那些功能,而调配流程仍有可能失败。兼容性不保证数据存储真的符合要求。例如,如果使用Virtual SAN功能,则只有Virtual SAN数据存储发生匹配,与其是否具有资源用于调配虚拟机无关。

4.4.3.6 合规性

“Virtual Machine Summary”(虚拟机摘要)选项卡显示了虚拟机的合规性状态。只要Virtual SAN满足虚拟机存
储策略中定义的功能要求,就可以说此虚拟机合规。如果集群中的组件失败,则Virtual SAN可能无法满足策略要求。在此情况下,则可以说此虚拟机不合规。此不合规状态将显示在虚拟机摘要中。

图:虚拟机摘要——不合规