vSAN超融合架构
vsan超融合非常适合企业应用环境
vSAN超融合架构
vSAN架构之高可用性
基于策略的的存储管理
1 概述 1.1 背景信息 从互联网到数据中心再到移动设备，IT已成为推动我们现代经济快速发展的基础架构。然而，一直以来我们都将基础设施看作是硬件。现在是不是需要重新考虑这个问题了呢？ 虚拟化使企业思考 IT 基础架构的方式发生了变化：从硬件定义到软件定义。软件在崛起，未来数据中心真正的统治者将是软件。 所需的资源需要实现动态化和自动化：要以一种便于使用的服务来提供，而不是以传统 IT 项目来提供。这种转变正在计算领域以一种势不可挡的势头顺利推进。通过服务器虚拟化来替代服务器硬件可被看做是这一转型的第一步。这种方法为我们提供了新的、更加强大和灵活的方式来利用和优化数据中心中的资源。 现在，存储领域也开始发生变化。工作重点从磁盘阵列转移到软件为基础的逻辑资源，这在十年前也许还无法想象，但现在这一现象正在逐渐成为现实。通过联合使用服务器和存储虚拟化软件，能够更好地落实端到端虚拟化战略的优势。通过不断地改进，这一存储方法今后还可能获得额外的硬件独立性、更好地利用磁盘容量和降低成本、建立虚拟的存储基础设施。 由于IT预算保持不变或进一步缩小，企业被迫寻找能够以较少的人管理更多的存储设备的方法，同时还能够降低资本和运营支出。事实上，在观察今天的经济环境产生的新兴技术的购买需求时，我们很明显的看到，IT决策者在增加更加诱人的附属功能的时候不只是增加了计算或存储能力，取而代之的是，IT管理人员正在寻找一些不但能够切实提供显而易见节约硬件资本同时还可提供必要的物质资源的解决办法。 下图是来自IDC在2013年11月对IT公司的调研数据，如图所示，随着业务的不断增加，对存储的需求成指数上升。根据预测，未来两年对存储的需求增长为每年41%。
存储增长趋势 同时，存储面临多重挑战：首当其冲的就是如何在满足不断激增的应用和存储需求的同时，满足客户的SLA。其后，是故障排除通常需要资深专家的支持。如何在更少的时间应用更少的成本满足业务部门的SLA需要，在满足策略控制的前提下，简化、自动化管理流程，并确保服务在线，成为企业IT部门在存储领域的关切点。 以前，存储都是在项目开始阶段配置和部署的，在其生命周期中不再更改。如果要求更改虚拟机所利用的 LUN 或卷的某些方面或功能，则在许多情况下，需要删除原始 LUN 或卷并创建具有所需功能的新卷。这是一项干扰性很强且非常耗时的操作，可能需要花费数周的时间进行协调。 存储压力来源 超融合旨在通过主机上与底层硬件集成并对其进行抽象化处理的软件层实，现存储服务和服务级别协议的自动化。
通过超融合，可以动态满足虚拟机存储要求，而无需重新调整 LUN 或卷。虚拟机工作负载可能会随着时间的推移有所变化，而底 层存储可以随时适应工作负载。通过超融合，可以动态满足虚拟机存储要求，而无需重新调整LUN或卷。虚拟机工作负载可能会随着时间的推移有所变化，而底层存储可以随时适应工作负载。 XXX客户作为国内大型企业，信息化建设不断发展。目前信息化网络以信息中心为运营维护单位，覆盖XXXX等多套业务系统，服务器资源庞大，对存储的需求也不断激增。出于经济效益和管理安全性考虑，针对虚拟化环境的存储解决方案已经提上日程。 1.2 现状分析 随着xxxx信息化建设的不断深入、业务系统的不断上线，一方面提供信息服务的IT软硬件的种类与数量不断增加；另一方面，IT软硬件的运行情况和企业各部门业务的捆绑越来越紧密，IT软硬件承担的责任也越来越重，对xxx数据中心的安全、运营和维护管理的要求也越高。 虚拟化和云计算技术成为xxxx数据中心选择的解决方案。该数据中心的基础架构由服务器、存储和网络构成，其中，为虚拟化平台提供数据空间的存储大多采用传统的集中存储，包括SAN和NAS等。随着业务规模和种类不断扩大，运维人员逐渐感受到服务器虚拟化带来的便利和高效，但僵化的传统外置磁盘阵列逐渐成为提高管理水平和效率的瓶颈，数据中心的运维人员需要同时管理服务器、网络、存储等硬件，还要管理业务软件、数据库、中间件、操作系统，甚至虚拟化和云管理平台。运维人员发现，每当新业务需要存储空间时，负责存储管理的人员必须向存储空间使用方详细了解所需逻辑卷的空间、性能、可用性（快照、容灾）等数据服务的需求。导致存储无法做到像虚拟服务器那样快速高效分配计算资源一样，去分配存储资源。整个数据中心运维的敏捷性、灵活性都因此受限。 而且，如果采用传统外置磁盘阵列，按照最高SLA（服务等级协议）进行配置，将会导致成本居高不下，并造成严重浪费。同时单个存储的功能与性能绑定在某个具体存储硬件上，并不能满足所有的应用要求。如果为不同的应用配置不同的集中存储，将会造成大量的分散的集中存储，造成管理的困难。此外，集中存储存在扩展性问题，存储的容量无法随服务器计算能力的扩展实现存储容量的水平扩展。同时，集中存储在扩容的时候可能面临被存储硬件厂商绑架，丧失议价能力。总结一下，XXX面临的主要挑战有：存储资源利用率低运维管理压力大 存储无法随应用SLA调整 存储无法水平或垂直扩展 总体拥有成本居高不下
2 超融合 2.1 数据中心虚拟化对存储提出新的要求和挑战 随着虚拟化成为基础架构主要的工作负载机制，数据中心的存储设计面临前所未有的挑战： 面临三个领域的挑战 第一个挑战是管理复杂、不灵活。存储一直是虚拟化架构设计中最关键的环节之一。很多性能的问题都和存储有关。虚拟化架构师需要了解很底层的存储设备及其特性，需要在IOPS，延迟和容量等各个方面优化。另外存储的分层、扩展和运维都有很多考虑的方面。在引入超融合以前，存储都是在项目开始阶段配置和部署的，在其生命周期中不再更改。如果要求更改虚拟机所利用的LUN或卷的某些方面或功能，则在许多情况下，需要删除原始LUN或卷并创建具有所需功能的新卷。这是一项干扰性很强且非常耗时的操作，可能需要花费数周的时间进行协调。 第二个挑战是费用昂贵。或者要求性能很高，采用外置磁盘阵列，将大幅提高整个虚拟化解决方案的成本。 第三个挑战是无法确保差异化服务等级。由于数据存储选择LUN时并不考虑每个虚拟机的性能和可用性要求，因此难以在存储方面保证不同应用或者不同虚机的SLA。在每个卷中包含多个VMDK的情况下，很难排除性能问题。 虚拟环境的数据中心，要求存储能够提供新的特征： 提供虚拟机精确控制 在应用高度整合的情况下满足性能要求
提供与vSphere相同级别的应用和数据移动性 支持快速调配零停机操作 按需动态扩展 支持VDI和大数据等新应用 性能可以满足对关键应用的需求 这些新特性是传统的存储所不能满足的，因此超融合应运而生。它从前文提及的三个维度解决虚拟化数据中心面临的问题和挑战：简化存储的管理、降低总拥有成本、实现端到端的SLA交付。 解决三个领域的挑战 2.2 什么是超融合 到底什么是超融合呢？在引入这个概念之前，我们先来看一下市场发展趋势： 数据业务正在以指数形式增长。IDC预测在2011到2015年，数据业务将增长9倍。驱动数据业务增长的主要驱动是新的应用和现有应用的结合，随着社交媒体到大数据业务的广泛产生，现有的数据管理面临巨大的挑战。有益于摩尔定律，我们正处于一个历史上数据业务增长最迅猛的时期。到2014年，平均的CPU将达到32线程，每个处理器插槽将拥有32个逻辑CPU——16核乘以2个线程。HDD容量迅速扩展。而从一个高性价比的观点来看，SSD已经成为CPU/内存与HDD的重要纽带。
三大趋势推进超融合 超融合是软件定义的数据中心的基本组件，可对存储资源进行抽象化处理，以支持存储的池化、复制和按需分发。这使存储层与虚拟化计算层非常相似：都具有聚合、灵活、高效和弹性扩展的特点。它们的优势也如出一辙：全面降低了存储基础架构的成本和复杂性。 综合来看，超融合具备如下三个特征： 以应用为中心的策略，可实现存储使用自动化 超融合支持对异构存储池中的所有资源实施一致的策略，使存储的使用像为每个应用或虚拟机指定容量、性能和可用性要求那样简单。这种基于策略的自动化最大限度地利用了底层存储资源，同时将管理开销降至最低。 与硬件无关的虚拟化数据服务 数据服务（如快照、克隆和复制）作为虚拟数据服务在软件中交付，并按虚拟机进行调配和管理。独立于底层存储硬件使得这些服务的分配极其敏捷和灵活。 通过硬盘和固态磁盘虚拟化确保数据持久性 随着服务器功能的增多，超融合解决方案可让企业利用廉价的行业标准计算硬件来扩大其存储资源。利用固态磁盘和硬盘作为虚拟机的共享存储，可获得高性能、内置的恢复能力和动态可扩展性，并将存储总体拥有成本降低50%之多。
3 VMware超融合解决方案描述 VMware是这样定义“软件定义的数据中心”的：所有的基础设施都被虚拟化，并以服务的形式提供，对数据中心的控制完全由软件自动化完成。 软件定义的数据中心改变了传统数据中心的运行和管理模式。数据中心已经转由运行在基于x86服务器的虚拟化软件所管理，这种转变提供了极大的灵活性和控制，同时提高了效率，也大大降低了成本。软件定义数据中心最关键的组成部分是计算、网络和存储。 SDDC模块组件 存储虚拟化这个领域相对于软件定义的计算和网络稍显滞后。然而，存储的产业和市场需求是非常庞大的。VMware在服务器级别先进的技术促成了一种新的存储模式，也就是所谓的超融合（SDS）。在深入介绍这个概念之前，先来了解一下存储随着虚拟化的发展发生的演进。 同时从控制层面和数据层面进行虚拟化是SDS的核心原则。通过软件并基于x86服务器平台的虚拟化层来交付存储资源是SDS的另外一个核心原则。同时，外接存储仍然在交付企业存储资源中扮演非常重要的角色。所以，VMware认为，把服务器直连存储和汇聚在虚拟化层的外接存储结合起来，建立一种可扩展的，高性能且高可靠的存储架构，可以获得最高的性价比。
SDDC|SDS 3.1 VMware超融合方案概况 如前文阐述，超融合是软件定义的数据中心的重要支柱之一，它把应用于服务器的先进技术运用于存储领域，可对异构存储资源进行抽象化处理，以支持存储在逻辑上的池化、复制和按需分发。并以应用为中心进行消费和管理，并实现基于策略的自动化。 VMware在超融合方面的计划主要侧重于一系列围绕本地存储、共享存储和存储/数据服务的计划。从本质上来说，VMware希望使vSphere成为一个存储服务平台。超融合旨在通过主机上与底层硬件集成并对其进行抽象化处理的软件层，实现存储服务和服务级别协议的自动化。 超融合的一个关键因素是基于存储策略的管理(SPBM)。SPBM可以视为新一代VMware vSphere存储配置文件功能。SPBM是VMware实施超融合的一个关键要素。使用SPBM和VMware vSphere API，底层存储技术会呈现一个抽象化的存储空间池，为vSphere管理员提供用于虚拟机调配的各种功能。这些功能可能与性能、可用性或存储服务(例如VMware vSphere ThinProvisioning)有关。然后，vSphere管理员即可使用虚拟机上运行的应用所需的部分功能创建虚拟机存储策略。在部署时，vSphere管理员可根据虚拟机的需要选择恰当的虚拟机存储策略。SPBM会将要求向下推送至存储层。这时将启用多种数据存储以供选择，这些数据存储可提供虚拟机存储策略中包括的各种功能。这意味着系统将始终根据虚拟机存储策略中设置的要求，在恰当的底层存储上创建虚拟机实例。如果虚拟机的工作负载随时间推移发生变化，只需将具有能够反映新工作负载的最新要求的策略应用于虚拟机即可。
超融合 超融合通过纯软件实现了存储相关的三个层面的功能： 通过策略自动化消费存储资源：以虚拟机为中心的安置、保护和性能策略 基于虚拟化的不依赖于硬件的数据服务：以虚拟机为中心的快照、克隆、复制、备份 通过虚拟化管理程序提取出存储抽象层：以数据存储和VMDK形式使用的异构存储 贯穿这三个层面，VMware提供对应于分布式存储DAS的解决方案Virtual SAN。 和基于共享存储的解决方案Virtual Volume，本文主要介绍分布式存储解决方案——Virtual SAN。 3.2 Virtual SAN部署要求 下一节将详细介绍创建Virtual SAN集群必须满足的硬件和软件要求。 3.2.1 vSphere要求 3.2.1.1 vCenter Server Virtual SAN至少需要VMware vCenter Server版本6.0。vCenter Server的Microsoft Windows版和VMware vCenter Server Appliance均可管理Virtual SAN。Virtual SAN通过 VMware vSphere Web客户端进行配置和监控，这同样需要VMware vCenter Server版本 6.0。
3.2.1.2 vSphere 一个Virtual SAN至少需要三台vSphere主机(其中每台主机均具有本地存储)以形成受支持的Virtual SAN集群。这样，集群才能达到至少允许一台主机、磁盘或网络发生故障的最低可用性要求。vSphere主机至少需要vSphere版本6.0。 3.2.2 存储要求 3.2.2.1 磁盘控制器 Virtual SAN集群中的每台vSphere主机均需要一个磁盘控制器。它可以是SAS/SATA主机总线适配器(HBA)或RAID控制器。不过，RAID控制器必须至少支持以下两种功能模式中的一种：直通模式或RAID0模式。直通模式，通常指JBOD或HBA模式，是VSAN6.0推荐的配置，VSAN将会通过存储策略特性要求管理所有RAID配置。Virtual SAN6.0的硬件兼容性列表(HCL)会列出已通过测试的硬件和支持的控制器。http://www.vmware.com/resources/compatibility/search.php 3.2.2.2 硬盘驱动器 在采用VSAN6.0混合架构时，每台vSphere主机在加入Virtual SAN集群时均必须至少具有一块HDD磁盘，可是是SAS，NL-SAS或SATA磁盘。HDD构成Virtual SAN数据存储的存储容量。磁盘驱动器提供VSAN共享存储的存储容量。 3.2.2.3 固态磁盘 在VSAN 6.0架构基于闪存的设备可同时用于缓存层以及持久的容量层。在混合架构的vSphere每个主机必须至少有一个基于闪存的缓存盘——SAS，SATA或PCI-E参与VSAN群集。基于闪存的设备提供既一个写缓冲区和读取高速缓存。 在全闪存架构的每个vSphere主机必须至少有一个基于闪存的容量盘——SAS，SATA或PCI-E标记为一个容量设备，同时必须至少有一个用于提升性能的闪存盘才能加入VSAN群集。虚拟VSAN 6.0全闪存架构是基于两层模型的性能和容量。 在混合结构，每个主机基于闪存设备的容量越大，用于提升I / O的缓冲越大，性能提升越高。此场景并不适用于全闪速的结构。 注意：在混合和全闪存架构，基于闪存的高速缓存设备不向分布式VSAN提供数据存储的整体容量。因为它们是用于读取和写入缓存，他们只计入VSAN缓存层或写
入缓冲区。在全闪存架构基于闪存的设备标记为容量的设备组成的分布式VSAN数据存储的大小。 3.2.3 网络要求 3.2.3.1 网卡 VSAN混合架构，每台vSphere主机必须至少具有一个1Gb或10Gb的网卡(NIC)。作为最佳实践，VMware 建议使用10Gb网卡。全闪存架构只支持10Gb以太网能力的网卡。为实现冗余和高可靠性，可以为每台主机配置一组网卡，但是不支持链路聚合。VMware将此视为最佳实践，但不认为这对于构建功能完善的Virtual SAN集群来说是必要的。 3.2.3.2 支持的虚拟交换机类型 VSAN6.0支持VMware vSphere Distributed Switch (VDS)和vSphere标准交换机(VSS)。不支持其他任何虚拟交换机类型。 3.2.3.3 VMkernel网络 在每台vSphere主机上，必须创建用于Virtual SAN通信的VMkernel端口。VMkernel端口标记为Virtual SAN。当集群中的一台vSphere主机拥有特定虚拟机时，此端口将用于集群间的节点通信，也用于读写操作，但组成虚拟机文件的实际数据块位于集群中的另一台vSphere主机上。在这种情况下，I/O必须通过在集群中的主机之间配置的网络进行传输。如果这个接口在分布式交换机VDS上创建，可以通过设定份额或预留功能实现vSphere网络VSAN流量的I/O控制。 需要注意的是：并不是Virtual SAN集群中的每个节点都需要有本地存储；没有本地存储的主角仍然能够利用分布式数据存储。
用于Virtual SAN流量的VMkernel端口 3.3 解决方案设计 注：该章节需要SE结合客户需求扩写或删除 3.3.1 方案概括 一个 Virtual SAN 群集最初由 3到 64 个X86服务器节点组成。混合结构，每个节点必须至少有一个全新的SSD 和一个全新的SAS/SATA/PCI-e 磁盘驱动器。全闪存结构，每个节点必须至少拥有两个全新SSD和一个全新SAS/SATA/PCI-e磁盘驱动器，其中一个SSD标记为缓存层，其他一个用于存储容量。这些计算节点并不会专用于 Virtual SAN：它们也会为各种正常的 vSphere 工作负载提供支持。
基础架构 Virtual SAN 会在创建群集时“开启”；这样，新的存储资源就会像计算资源一样透明地添加到池中。 Virtual SAN 可在所有节点之间提供一个集中的数据存储，供虚拟机及其 VMDK 使用。可以在同一个 Virtual SAN 数据存储实施多种策略（冗余、性能），无需预先创建常用的存储池：金级、银级等。 Virtual SAN 可对所需的策略进行监控，并且只要有足够的资源，也可以根据需要进行自我调整：条带化数据对象、使用更多 SSD 缓存等。 目前，Virtual SAN 的数据服务都由 vSphere 提供：快照、链接克隆、复制、vSphere HA、DRS、VDP，或者通过第三方技术合作伙伴提供。此外，Virtual SAN 具有卓越的“节点撤离功能”，可以在关闭节点进行维护或更换之前，重新定位正在运行的进程及其相关存储。 在 vSphere 群集中，并非所有节点都需要具有本地存储；没有磁盘的节点可通过网络访问 Virtual SAN 数据存储。 混合架构解决方案 运行Virtual SAN 的每个服务器节点最多支持 5 个磁盘组。每个磁盘组有1~ 7 个HDD磁盘，但必须有一个的 SSD用于缓存层。这些磁盘可以是内部磁盘，也可以是通过JBOD 进行认证的外部磁盘。之所以有磁盘组的概念是因为，允许主机内多个SSD参与读写缓存的工作，并把故障域缩小到一定范围内。
磁盘组 SSD充当分布式读写缓存，并不用于永久保存数据。每个磁盘组只支持一个SDD：70%的SSD 容量用于缓存读取，其余30% 用于写入。可以在取消向磁盘暂存之前，在两个或两个以上节点之间镜像缓存写入来对该缓存写入进行保护。也可以使用多节点镜像来防止发生磁盘故障和节点故障。 全闪存架构解决方案 全闪存架构中，所有的磁盘都必须是固态磁盘，运行Virtual SAN 的每个服务器节点最多支持 5 个磁盘组。每个磁盘组有1~ 7 个SSD磁盘用于存储容量，同时必须有至多一个的 SSD用于缓存层。 SSD充当分布式缓存时，并不用于永久保存数据。每个磁盘组只支持一个SSD最为缓存层：由于全闪存架构的存储容量的也用固态硬盘实现，故读性能不是瓶颈，缓存层SSD100% 用于写入。 借助于全闪存架构，以及更高的可用性，VSAN 6.0除了支持VDI、DR和测试/开发场景之外，还能支持关键的业务应用。
3.3.2 应用于关键应用的方案框架（可选） VSAN6.0相比之前的版本，有许多性能提升和功能增加，VSAN已经被验证，可以支持关键应用的环境要求。为虚拟化的关键应用提供高性能、高可用性和可在线扩展的企业级存储解决方案，包括Tier-1生产和业务关键应用。 在VSAN6.0 里，全闪存能为每主机提供高达90K IOPS的性能 。响应时间缩短到亚毫秒级别，可以满足Tier-1或关键业务工作负载的需求，包括Oracle 、Microsoft SQL Server和ERP等关键业务应用程序的需求。 全闪存架构示意 3.3.3 应用于虚拟桌面场景的方案框架（可选）
虚拟桌面的存储 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.4 应用于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.5 应用于灾备的方案框架（可选）
容灾方案框架 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.6 规划设计细则 Virtual SAN利用多个服务器的本地存储构建成一个共享的分布式数据存储（datastore）。这个数据存储的容量是由组成Virtual SAN群集的多个主机里面的磁盘组汇集而成的。这些主机可以是vSphere群集的一个子集。Virtual SAN数据存储的总容量就是Virtual SAN群集主机里HDD磁盘的容量之和。SSD磁盘的容量仅专用于Virtual SAN的缓存层，不记算在存储容量中。 3.3.6.1 容量规划相关的概念 在分析容量规划前，首先引入三个概念： 对象（Object） 在VSAN数据存储上部署的虚拟机由一系列对象组成。每对象以多个组件（component）的形式储存在Virtual SAN数据存储中。对象是设置存储策略的最小单位，可通过VM存储档案（VM Storage Profiles）为不同对象设置性能和可用性的策略服务。 对象有四种类型： VM Home：放置虚拟机配置文件（.vmx, log文件等） 交换Swap：仅在虚拟机开机时候产生 VMDK：虚拟机磁盘文件 快照：VM级别的快照存储对象 组件（Component）
对象由分布到不同主机节点的组件构成。Virtual SAN6.0中，每个主机目前支持最多9000个组件。容量大于255GB的对象自动分成多个组件。每个组件消耗2MB的磁盘容量存放元数据。 仲裁（Witness） 每个存储对象都存在仲裁组件。只储存对象的元数据。仲裁扮演裁判的角色，在主机故障是，决定哪个含有备份的主机来接管服务。用来防止脑裂。每个Virtual SAN仲裁组件消耗2MB用来存放元数据。 3.3.6.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 6.0中支持另一种文件系统VirstoFS，采用这种文件系统，每个文件系统格式需要消耗磁盘容量1%的。在设计VSAN容量时需要考虑这个因素。 允许故障主机数 允许故障主机数是在Virtual SAN中对存储容量影响最大的因素。基于对VM的可靠性需求，设定不同的存储策略，最多可以致使一个VM占用与之前相比四倍的磁盘空间。 对象的磁盘条带数 如果对象的条带数超过默认值1，那么每个条带将算为一个拆开的组件（component），这将会影响主机可支持的组件总数。 磁盘组（Disk Group）设计 每个磁盘组一个flash设备 如果主机包含多个flash设备，需要建立多个磁盘组来利用额外的flash设备 Flash设备容量与磁盘容量比例越高，缓存层的厚度越大。 需要定义并尽可能减少存储的故障域。 SSD容量设计 推荐的Virtual SAN的用于缓存的flash磁盘（SSD）容量是VSAN存储总容量的10%（在考虑最大允许故障主机之前）。如下图所示，如果规划的每个VM需要20GB的空间，有1000个VM，那么总的为VM规划的存储空间需求大约是20TB，按推荐的10%flash来计算，总的flash容量需求为2TB。 Flash设计举例 在实践中，总的flash容量比例应该基于使用案例和存储容量对性能的需求。
全闪存架构需要考虑的因素 需要VSAN6.0版本 要求 10Gb 网络，不支持 1Gb 网卡 最大的全闪存节点数 32 闪存设备同时用作缓存和容量 在全闪存配置中不采用读缓存预留 需要标记用于存储容量的闪存设备 3.3.6.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 组件/主机 (每主机最大9000个组件) 组件元数据 公式: 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