《VMwareVirtualSAN实战.html.pdf》由会员分享，可在线阅读，更多相关《VMwareVirtualSAN实战.html.pdf（111页珍藏版）》请在三一文库上搜索。
1、前言 存储从产生至今，已经经过数十个年头了，天下大势，合久必分，分久必合。在虚拟化、云计算数据中心的大背景下，在满 足了企业计算高可用、网络高可用之后，企业对于存储的高可用、双活等的要求也就随之提上了议事日程。 传统的存储解决方案要想实现存储的双活，其中最大的问题就在于：对于用户来说，实现双活的费用太高了，尤其是对于用 户的TCO与ROI而言，更是如此。大家可以想一下，这就相当于你买了两台iPhone 6 Plus手机，一台正常使用，一台放着不用。 这毕竟不是豆浆，价格低廉到可以让你买一杯倒一杯。 同时，传统的共享存储有一个大问题：支持真正双活的存储设备价格很高昂，而中低端存储设备根本无法实现
2、存储层面的双 活。 可随着业务的发展，必然存在双活的要求。正是在这样的背景下，以Nutanix、Ceph和Virtual SAN之类为代表的存储虚拟化 产品出现了，这类型的产品最大的卖点就在于： 不用独立的Standby存储设备； 不用额外的双活软件支持； 不用额外的兼容性； 不用额外的可用性； 不再需要考虑LUN、Volume等的规划； 价格低廉； 改造技术成本低廉； 深度整合数据中心虚拟化产品； 在存储虚拟化的支持下，存储虚拟化产品全面转向了面向对象的服务级别。所有业务的可用性、数据可靠性，都依赖于面向 对象的策略进行工作，可以个性化地针对不同业务级别定义不同的对象策略，实现不同的可用性级
3、别和数据对于物理硬件的写入 位置分割。 在保障计算可用的基础上，存储虚拟化产品同时保障了数据的可用性。在闪存设备与HDD设备的有机组合下，提供了远超 传统共享存储的IOPS支持，解决了传统性能密集型业务（例如：Oracle数据库之类的业务）无法运行在x86平台上的问题。 在软件定义存储产品出现之前，x86结构下对于承载OLTP（Online Transaction Processing）或OLAP（Online Analytical Processing）之类的业务是有所欠缺的。因为x86结构下的业务模型，导致了对计算、I/O密集型业务的承载能力的欠缺，尤其是 I/O密集型业务，比如Oracl
4、e RAC之类的业务、医疗领域PACS系统等。传统的SAN存储用于虚拟化，要么成本过高，要么无法匹 配x86虚拟化本身。正是在这个背景之下，Server SAN出现了，其迅速迎合了这类业务的需求。 以Virtual SAN为例，它已经得到了国内部分三甲医院的认可，并用于PACS系统，也得到了部分证券型业务的认可。虽然现 在其应用规模还不算太大，但无疑证明了它的可用性。 第1章 Virtual SAN产品概念 章节概要 本章的核心内容如下： Virtual SAN产品介绍； Virtual SAN关键概念； Virtual SAN与传统存储的异同； Virtual SAN的多种构建方式； Vir
5、tual SAN的兼容性； Virtual SAN的优缺点； Virtual SAN与其他VMware公司产品的结合度。 1.1 产品介绍 VMware Virtual SAN是由Hypervisor-Converged软件定义的分布式存储基础平台，它内置于VMware公司的vSphere服 务器虚拟化平台，最早出现在vSphere 5.5 Update 1版本中，截止至2015年3月，最新版本为vSphere 6.0的Virtual SAN 6.0， 它是一个存储虚拟化产品。 Virtual SAN又称VSAN，当前版本是6.1，也是第3个生产发布版本。它利用物理服务器本地硬件设备资源，以类
6、似分布式 存储技术的方式，为vSphere Cluster中的所有ESXi Hosts提供共享存储服务。Virtual SAN创造性地利用策略驱动技术来帮助 vSphere环境提供最简化、最高效和最快速的存储部署与管理支持。利用VM级别的存储策略，Virtual SAN支持自动化、动态的 按需匹配VMs存储资源分配。有了Virtual SAN，针对存储的管理、维护、扩容等，都将变得异常简单。同时，存储带来的额外 硬件成本开销也变得更加低廉。相对于传统存储而言，Virtual SAN的优势主要体现在下列几个方面： 低成本； 低管理成本； 高可用性； 管理简单； 高弹性； 高性能； 支持融合式能力
7、； 同城双活。 利用位于物理服务器本地的SSD与HDD磁盘资源的组合，构成了Virtual SAN节点的基础构成单元。Virtual SAN 5.5作为第 一个VMware公司发布的存储虚拟化产品，仅支持SSD与HDD的混合存储组合的底层物理硬件构成。最新发布的Virtual SAN 6.0和VSAN 6.1则支持全闪存与混合存储两种结构形态。 在混合存储结构下，SSD设备被用作Cache来优化读写性能，HDD则用作对象存放目标，负责为存储对象提供存储空间和 永久性数据存放点。 在全闪存结构存储下，无论是Cache，还是存储空间，都由SSD设备负责提供。表1-1所示是混合存储在Virtual
8、SAN 5.5、 Virtual SAN 6.0中与全闪存存储的功能比较。 表 1-1 1.2 Virtual SAN关键概念 Virtual SAN作为区别于传统集中存储的类分布式存储技术，在基础概念上，与传统存储的概念有着巨大的差异。Virtual SAN的关键基础概念如表1-2所示。 表 1-2 作为一款面向对象的存储虚拟化产品，Virtual SAN中最重要的基础概念就是对象。在Virtual SAN中，对象涵盖的内容如表 1-3所示。 除了对象之外，由于Virtual SAN是一款Storage Policies Based的存储，它以虚拟机对象为颗粒度参考，因此可为不同的 虚拟机以
9、及其对应的对象提供不同程度的可用性级别，而为了满足可用性级别的工作需求，在Virtual SAN有一个基础概念叫作 Witness。Witness是一个仅包含Metadata，不包含应用数据的组件。它唯一的用途就是在故障发生后，Datastore需要做可用 性调整时，充当可用性调整时的见证用途。在Virtual SAN 1.0文件系统中，它大约会消耗Metadata 2MB的空间，Virtual SAN 2.0中，它大约会消耗Metadata 4MB的空间。 表 1-3 1.3 Virtual SAN与传统存储 从概念上讲，Virtual SAN与传统存储存在很多差异，实现形式、对象处理、扩展
10、能力等各方面，都存在着差异。 同时，Virtual SAN的优点也很多，例如： Virtual SAN不再要求外部存储，也就是说不再需要FC、iSCSI、FCoE之类的外部存储设备。 利用本地存储的特征，Virtual SAN不再强调存储设备厂家的差异。 Virtual SAN是一款面向对象的存储，它不再有传统存储的LUN、Volumes之类的概念。 传统的存储协议，如iSCSI、FCP、NFS之类的都不再适用于Virtual SAN。 Virtual SAN的部署只需要通过vSphere Web Client即可完成，不再需要额外的存储管理软件。 Virtual SAN帮助企业实现了一体化的
11、管理员交付模式。 Virtual SAN利用Storage Policies，帮助VMs在生成时，自动匹配自己的策略，灵活地实现了不同可用性级别与条带化级别的 交付。 Virtual SAN很好，但是当前它最大的局限就在于它只支持vSphere产品，这一点是它相对于其他存储产品最大的优势，也 是最大的劣势。所以Virtual SAN不是万能的，它只能用作Virtual SAN Cluster节点的存储用途，无法用作其他用途。不过，有 消息称，在后续的版本中会加入对第三方服务器虚拟化产品的支持及推出类似NAS的功能，以便让它也具备传统存储的文件共 享功能。 另外，软件定义类型的存储对于空间的开销
12、是蛮大的，所以，如果要用它，需要有这个思想准备，也就是50%以上的空间浪 费比例。 1.4 Virtual SAN的构建方式 针对Virtual SAN的构建，基础设备准备部分支持以下3种模式： Virtual SAN Ready Nodes； VMware EVO：RAIL； DIY。 1.5 Virtual SAN产品的兼容性 Virtual SAN作为VMware公司自有的存储虚拟化产品，针对VMware公司的其他产品和功能模组，有着强大的耦合支持能 力。Virtual SAN支持的VMware公司其他产品如下： vSphere Data Protection； vSphere Repl
13、ication； vRealize Operations Manager； vRealize Automation Center； Site Recovery Manager； Horizon View。 从vSphere自身的功能组件耦合度看，Virtual SAN与下列vSphere经典功能有着强大的协同工作能力。 vSphere HA； vSphere DRS； vMotion； Storage vMotion； Snapshots。 1.6 Virtual SAN功能限制 Virtual SAN有着强大的功能，但也有其自身的局限，尤其是针对传统的vSphere功能而言，它不支持下列功能
14、： Virtual SAN所构成的Datastore仅适用于VSAN本身。 单台ESXi Host一次只能配置到一个Virtual SAN Cluster中，无法复用。 Virtual SAN不支持Fault Tolerance（6.0）。 Virtual SAN不支持DPM。 Virtual SAN不支持Storage I/O Control。 Virtual SAN不支持SCSI Reservation。 Virtual SAN不支持RDM。 Virtual SAN不支持传统的VMFS。 Virtual SAN没有故障诊断辅助分区。 1.7 Virtual SAN适用的业务场景 Virtu
15、al SAN支持的融合式云计算数据中心模型如图1-3所示。 图 1-3 Virtual SAN适用的场量包括： 多层模型的私有云数据中心。 A/A与B&R数据中心。 Horizon一体化BYOD桌面环境。 vMSC数据中心。 统一管理集群。 其中，针对虚拟桌面的组合程度是最佳的。根据生产数据显示，Horizon View结合Virtual SAN的组合，轻松解决了传统桌 面虚拟化中面临的各种问题，例如所谓的启动风暴1问题就在Virtual SAN中得到了完美的解决。 在国内，桌面虚拟化与Virtual SAN组合项目已经得到了用户的广泛认可，堪称Virtual SAN与VMware公司其他产品
16、线的最 佳组合。落地的桌面虚拟化项目极好地证实了这一点。 1 所谓启动风暴，就是在同一时间大批量虚拟机同时启动时带来的巨大I/O请求。 1.8 本章小结 通过对本章的学习，可以基础性地了解VMware Virtual SAN的基本形态、相关业务契合支持、构建方式、基本用途、基本概 念组件、兼容性要求、功能极限等。 充分理解Virtual SAN与vSphere的基础功能兼容性、Virtual SAN的局限等。也就是说，通过对本章的学习，可以了解到什么样 的业务类型适合运行在Virtual SAN上，而什么样的功能需求不应该运行在Virtual SAN平台上。 还可以初步了解对传统存储与Virt
17、ual SAN之间的大体差别和颗粒度区分，以及在Virtual SAN存储中的基础概念对象、SPBM 策略。这个很重要，因为在以Virtual SAN为代表的存储虚拟化产品的工作中，对象与SPMB策略都将会贯穿始终。本章不要求理 解这两个概念，但是需要建立起区别于传统共享存储的基本印象，别再用对传统存储的理解来理解Virtual SAN虚拟化存储。 第2章 软件定义数据中心与Virtual SAN 章节概要 本章的核心内容如下： 软件定义数据中心； 为什么要SDDC； SDDC的核心组件； Virtual SAN在SDDC中的定位。 软件定义数据中心（Software Defined Data
18、 Center，SDDC）是在虚拟化领域中最早由VMwrae公司于2014年初提出来的概念。 它是由计算虚拟化、存储虚拟化、网络虚拟化、自动化、一体化监控等系列模块结合在一起，形成的一个All-in-One的大型自动 化云计算数据中心。 根据最近这2年全球科技发展动态来看，SDDC无疑是未来数据中心的趋势，同时从提出SDDC概念的VMware公司的各种动 向来看，无论是从VMworld大会展示的主题，还是从VMware公司的产品构成等多个方面的综合，都表明了它的未来发展趋势。 目前，VMware公司应该说是为数不多的能够用自己一家的产品实现一个完整的软件定义数据中心的公司。 为什么需要软件定义
19、数据中心？业务系统越来越多，x86设施越来越复杂，企业针对系统、数据、安全、响应速度等方面的 需求越来越高，企业数据中心已经发展到需要一个强大的、具备创新性的产品架构出现，而SDDC很明显满足这个条件。 软件定义数据中心给客户带来的优势主要有下面几个方面： 为用户交付统一的平台； 实现融合式业务与办公交付； 强大的安全性与控制能力； 大幅度缩减企业新业务上线的时间。 可以轻松实现Public Cloud与Hybrid Cloud接口。 软件定义数据中心的结构如图2-1所示。 图 2-1 2.1 VMware软件定义数据中心产品清单 归纳起来，VMware公司的软件定义数据中心产品如下： vSp
20、here； VSAN； NSX； vRealize Automation Center； vRealize Operations Manager； Horizon。 从最基础的构成来看，上述产品中，最基础、最核心的产品是前5个。接下来将介绍前5个产品的结构和特征。 2.2 软件定义数据中心之软件定义存储 从软件定义数据中心的字面意思就可以看出，这要求用纯软件来实现。而一个数据中心涉及的主要组件就是计算部分、网络 部分、存储部分、安全部分等。要实现软件定义数据中心就必须存在软件定义存储。 只有利用软件定义存储，才可以灵活实现高性能、高弹性、硬件无关和分布式等软件定义数据中心需要的基本特征，从而将
21、 所有的存储对象软件化，按需实现不同SLAs1的业务等级交付。 当前，全球范围内的软件定义存储对象存储的主要产品有下列几款： 从OpenStack项目衍生出来的Ceph分布式存储项目； Swift存储； Virtual SAN； VVoLS； Datacore； Storage Virtual VSA。 利用这些产品，都可以构建一个对象存储，而且都可以实现软硬件分离的软件定义存储的基础特征。但是构建一个SDDC并 不是说实现了软硬分离之后，就可以了。还有很多问题需要考量，尤其是不同产品组件之间的配合选型问题。 1 SLA是Service Level Agreement的缩写，表示服务等级的意思
22、，通常用来形容业务可靠性或可用性级别。 2.3 为软件定义数据中心准备Virtual SAN 为软件定义数据中心准备Virtual SAN这个软件定义存储在第3章会详细阐述。这里只是简单说明。准备Virtual SAN的基础 要求如下： 3台以上的x86服务器； 3块以上闪存设备； 3块以上HDD设备； 兼容Virtual SAN的I/O Controller； 最小千兆网络，最佳万兆网络； vSphere 6.0服务器虚拟化。 2.4 本章小结 关于软件定义数据中心的概念，本章并没有从完整技术层面完善每一个组件的功能、用户描述和初始化配置。毕竟，如何构 建一个企业软件定义数据中心不在本书的范
23、畴。 本章的主要内容是软件定义数据中心的存在方式、组件构成和SDS在SSDC中的定位。 本章阐述了SDC、SDS、SDN、Automation、vROPS以及Horizon在SDDC中的用途，也为笔者计划后续出版书籍利用 VMware产品实战构建企业级SDDC开个小头，让读者对SDDC的大概念构成和用途有一个前导性的了解。 本章也重点阐述了VMware SDS产品中VVoLS和Virtual SAN的技术特征和部分技术细则，尤其详细介绍了VVoLS。而对于 Virtual SAN本书就是围绕它展开的，所以本章除了它的基础结构外，其他都是泛泛而谈，更多详细内容，请看后面的章节。 第3章 Virt
24、ual SAN配置要求 章节概要 本章的核心内容如下： 配置Virtual SAN的硬件清单； 配置Virtual SAN的软件清单； Virtual SAN对于License的要求。 3.1 Virtual SAN硬件配置要求 Virtual SAN的硬件配置最佳选择自然是参考VMware Compatibility Guide（参考附录）。具体而言，还是要从以下5个层 面来阐述： 存储设备； CPU； Memory； NIC； 启动设备。 这几个方面与Virtual SAN的要求如表3-1所示。 表 3-1 3.2 Virtual SAN软件配置要求 Virtual SAN内置于vSphe
25、re中，仅支持vSphere 5.5 Update 1以上的版本。如果想要用到本书描述的全部Virtual SAN功能 组件或全闪存存储结构，则需要ESXi Host全部为vSphere 6.0+。混合vSphere 5.5 Update 1+与vSphere 6.0构成的Virtual SAN Cluster节点，则只能选用1.0版本的Virtual SAN文件系统版本（VMFS-L），2.0版本（基于Virsto构建的VSAN文件系 统）的文件系统只能是纯vSphere 6.0+Virtual SAN Cluster节点。 归纳起来，Virtual SAN目前支持的vSphere版本如下：
26、 vSphere 5.5 Update 1 vSphere 5.5 Update 2 vSphere 6.0 vSphere 6.0 Update 1 vSphere 6.1 以及相关的vSphere小版本，如1a、1b、2a、2b等。 很多人比较关心Virtual SAN是否可以支持VMware公司以外的产品，如KVM、Hyper-V或XenServer之类的。答案是否定 的，Virtual SAN的出现并不是以独立软件的形式存在，它其实是内置于vSphere操作系统中。将vSphere 5.5 Update 1+操作 系统安装到物理服务器后，并不需要额外安装什么软件，只需要安装这个vSph
27、ere操作系统的物理服务器满足Virtual SAN的 VCG，且环境满足Virtual SAN Cluster的最小节点数要求，即可随时拥有Virtual SAN存储虚拟化环境。 如前文所述，这是它最大的优势。因为在x86虚拟化领域，VMware公司的vSphere产品是当之无愧的NO.1，而VMware公 司高达450亿美金的市值，70%以上都是靠这个vSphere产品。很多人说Virtual SAN被局限在了VMware产品线里，这是它最大 的劣势，其实在笔者看来，这正好是VMware最聪明的地方：想象一下，如果VMware公司的全球vSphere客户群里有1/3的客 户选择在现有的环境
28、基础上改造Virtual SAN实现存储虚拟化，那么，VMware公司的盈利回报绝对是巨大的。当然，有消息 称，未来不排除会有第三方虚拟化产品的兼容支持，但是，笔者认为这样做的意义并不大，也许只会在招投标参数上有所体现 吧。 也有人提到Nutanix这样的Server SAN竞争对手。从成本、空间、利旧、工作效率和运营工作人员知识储备等多个角度 看，Virtual SAN的优势都是异常明显的。Nutanix之类的产品虽然兼容多款Hypervisor，但是它是一个硬件产品，需要打包购 买。另外，它有自己的OS存在，再加上它的Metadata处理机选用的是开源产品，从复杂度和稳定度上看，都有一定的
29、风险。因 此，综合而论，虽然不是说Nutanix不好，但是Virtual SAN在VMware软件定义数据中心领域的优势也是显而易见的。 3.3 Virtual SAN License的要求 Virtual SAN需要单独的License，与vSphere的License并不是同一个，综合起来，在vSphere+VSAN的平台环境中，需要 的License就包括了三大类，分别是： vSphere服务器虚拟化所需的License vCenter Server管理平台所需的License Virtual SAN自身所需的License 对于Virtual SAN自身而言，它的License也分为两
30、大类型，分别是： 用于混合存储环境 用于全闪存环境 它的License也是依据CPU数量来销售的。具体销售方式与价格，请联系VMware相关代理商获取，VMware代理商列表可 从http:/ 3.4 本章小结 通过本章的学习，相信读者初步了解了配置Virtual SAN在硬件、软件和License方面的要求。本章的着力点就在于向读者说 明，想要学习Virtual SAN或者想要为生产环境构建一个Virtual SAN存储虚拟化是多么的简单。 一个新的产品要想普及，最难的就在于它可能会以毁灭性的方式摧毁现有的业务平台，比如，要求购买一套全新设备、软件 或要求人员重新进行知识储备。这样的新技术要
31、普及起来就很困难。而Virtual SAN最大的好处就是不需要过多地改动现有基础设 施或新购设备，就可以轻松改造现有业务环境的Virtual SAN存储虚拟化。这一点是非常难得的，也是笔者认为Virtual SAN最可取 的一个切入点。只有和风细雨般地改造才有可能得到更大的成功可能性，如果一开始就摆出破坏式的姿态，那么，企业的抗拒性 就显而易见了。在这一点上，Virtual SAN的优势是独一无二的。即使是知名的Nutanix在这点上也比不上Virtual SAN，因为它至少 需要您花掉9万美金之后，才有可能得到它最基础的体验。 有人可能会说Virtual SAN不兼容其他产品，这个问题在本章
32、解释过了。这里说下其他同时支持很多虚拟化软件的产品的劣 势。以Nutanix为代表的Server SAN厂家的确支持几乎所有的x86虚拟化产品，但是它是以牺牲性能为代价的。它们通过内置控制 软件的方式来实现这个支持功能，也就是说，它们的产品架构至少是三层：硬件厂商控制软件虚拟化产品，Virtual SAN是二 层结构：硬件vSphere虚拟化。 另外，Virtual SAN的技术切入成本低到只需要参加虚拟人的“Virtual SAN入门到精通”的培训，再结合本书就可以轻松完成 技术准备工作。 第4章 Virtual SAN Cluster构建准备工作 章节概要 本章的核心内容如下： Virtu
33、al SAN构建的主机层面要求； Virtual SAN与存储组件相关的信息； All Flash与Hybrid结构下的存储组件相关异同； Virtual SAN对于虚拟交换机的支持； NIC Teaming策略与Virtual SAN的结合； Fault Domain的功能与好处； Virtual SAN的日志问题。 构建Virtual SAN Cluster的准备工作主要从硬件与软件这两个大的层面来考量。具体下来，针对硬件部分和软件部分自然又有 所不同。 硬件层面主要是三大块： 存储设备相关； 网络设备相关； 主机设备相关。 这个部分相对于第2章所描述的是更进一步细化的内容。 除了软件版本
34、、License部分之外，软件层面的考量则相对复杂一些，主要从Virtual SAN本身的特性展开，核心包含以下多个 方面的多个层面： 存储层面相关； 网络层面相关； Virtual SAN Cluster相关； Fault Domains容错模块； Virtual SAN日志相关。 4.1 Virtual SAN存储组件 在构建Virtual SAN之前，有一个很重要的考量就是关于存储设备部分的，因为，存储设备的构成以及物理磁盘设备的数 量、空间大小会直接影响Virtual SAN Datastore中的对象数目。在Virtual SAN 6.0中，单台主机支持的最大对象数目为9000， 而
35、单个对象的最大容量为255GB（SWAP文件除外，它可以到256GB），超过之后，系统将会对其执行自动切割。因此，如果物 理设备数量不够，就会产生各种莫名其妙的问题。 同时，容错级别、条带数目等，都会导致对象数量的倍增。所以，在设计存储的物理设备资源时，需要充分结合这一部分阐 述的关联因素去准备物理设备数量。 如果Tolerate为默认值1，则虚拟机相关对象可用物理资源为50%，如果Tolerate值为2，则可用资源就只有33%，如果 Tolerate值为最大值3，则可用物理资源只有25%。 这里的详细计算逻辑，将会在下一本书中进一步阐述。 另外，根据Virtual SAN Datastore
36、的不同版本，构建Virtual SAN Datastore文件系统对于每一块磁盘带来的Metadata开 销的不同为：v1.0开销为每设备1GB，v2.0开销为每设备容量的1%。 同时，由于vsanDatastore是由Disk Groups构成的，因此，在考虑存储层面时，Disk Groups的数量、SSD与HDD的比例 这些也是需要考虑的。当然，具体内容还是会放到下本书中再进行细化。 4.2 Virtual SAN Cluster配置要求 Virtual SAN 6.0 Cluster最大支持64个节点，也就是最多支持64台主机构成一个Virtual SAN Cluster。最小则要求至少
37、3个 节点。这里的3个节点的来源是什么呢？ 核心参数就一个最小容灾数量Tolerate（FTT），Virtual SAN Cluster最小Tolerate默认为1，因此，在Virtual SAN Cluster初始化构建完成之后，默认最小Replica为2，在3个节点状态下的Virtual SAN Cluster，允许每份数据拥有2个Replicas 和1份Witness，且分布在3个主机节点上。由此得出了一个推论公式：假定Tolerate为n，则对应的Virtual SAN Cluster节点数 要求为2n+1，当n为1时，以2n+1的计算法则应该为21+1=3，因此，此时的主机数要求为3
38、，以此类推，如表4-4所示。 表 4-4 综合考虑，Virtual SAN 6.0的最大Tolerates为3，也就是n的最大值为3，所以，在Virtual SAN Cluster中，最大允许每个 对象拥有4份Replicas与3份Witness（Home Namespace除外，它只能有1份Replica和1份Witness），如图4-3所示。 图 4-3 由于3节点状态下，任意节点故障都会导致Virtual SAN无法重建相关组件或无法部署新的VM，也就会导致VM无法被保 护，因此，在生产中，最佳的Virtual SAN Cluster最小节点数为4，见图4-3。 因为Virtual SA
39、N可以完美地结合vSphere HA组件，所以在准备Virtual SAN初始环境时，还需要考虑Virtual SAN与 vSphere HA Cluster的结合。当vSphere HA发生时，故障主机上的相关计算负载会自动在Cluster中的其他主机上重新启动。 vSphere HA自身通过准入控制策略来完成计算资源（CPU、Memory）的预留，以便满足故障发生时的计算资源预留。 与想象的场景不同，Virtual SAN不会与vSphere HA之间发生交互行为。因此，它也就无法通过vSphere HA来检查或者确 认Cluster中的主机是否存在足够的磁盘空间。实质上，默认状态下系统会
40、在主机故障后每隔60分钟尝试确认主机是否存在足够 的存储空间。 注意事项： 配置Virtual SAN之前，请先关闭vSphere HA Cluster。 vSphere HA不会选用Virtual SAN Datastore作为心跳存储。 vSphere HA必须用Virtual SAN网络进行通信。 vSphere HA在激活Virtual SAN的环境下不用Management Network做心跳。 隔离响应地址无法ping通。 在3节点状态下，当vCenter Server部署到Virtual SAN Datastore时，或Virtual SAN Cluster故障时，将无法使用它
41、进行排错， 需要借助其他故障排查工具。 4.3 Virtual SAN网络配置要求 4.3.1 Virtual SAN与vSwitch vSphere支持vSphere Standard Switch和vSphere Distributed Switch两种类型的虚拟交换机。无论是哪一种，我们都将 它简称为vSwitch，其中vSphere Standard Switch简称为vSS，vSphere Distributed Switch简称为vDS。 作为内置于ESXi Host中的Virtual SAN，也支持vSphere Standard Switch和vSphere Distribut
42、ed Switch。从基础功能和 性能的角度上看，无论是vSphere Standard Switch，还是vSphere Distributed Switch，两者运行Virtual SAN环境得到的结 果都存在差异，但如果不做特别设定，其实两者差别不会太大，尤其是在10Gbit/s的物理网络环境下更是如此。 那么，运行在vSphere Distributed Switch上的Virtual SAN环境究竟存在哪方面的优势？是否有必要为Virtual SAN环境配 置使用vSphere Distributed Switch？ 答案是肯定的。没错，虽然从基本组件功能角度上看，vSphere D
43、istributed Switch和vSphere Standard Switch差别不太 大。但是，由于vSphere Distributed Switch多了很多新功能组件（见图4-4），所以，在vSphere Distributed Switch工作模 式下，可以针对Virtual SAN提供更加精细的管理支持。其中最典型的就是Network I/O Control功能。vSphere Distributed Switch提供了一个名叫NIOC的功能，它可以区分不同的Traffic，然后保障Virtual SAN的网络优先级，在10Gbit/s环境下，这 个需求尤其有意思。 图 4-4
44、vSphere Distributed Switch支持针对图4-4所示功能做精细化的Share值划分，包括： Fault Tolerance Traffic； Management Traffic； NFS Traffic； Virtual Machine Traffic； Virtual SAN Traffic； iSCSI Traffic； vMotion Traffic； vSphere Data Protection Backup Traffic； vSphere Replication（VR）Traffic。 精细化NIOC后，可以看到类似图4-5所示的结果。 图 4-5 结合vS
45、phere Distributed Switch的NIOC功能就可以轻松保障Virtual SAN网络链路要求。这一点，很明显vSphere Standard Switch是实现不了的。 另外，针对vSphere Distributed Switch，还有一个LAG功能与Load Balancing模式的配置可供选择。 4.4 Virtual SAN Fault Domain配置要求 Fault Domain是Virtual SAN 6.0中的新功能，它存在的最大价值就是规避同一个刀片中心或同一个机架设备出现意外事故 时的容灾级别无法保障的问题。总体来说，它与Virtual SAN最低主机节点
46、数的要求一样，它要求最少3个Fault Domains，每个 Fault Domains中最少要有1台ESXi Hosts，和主机最小数量要求一样，在条件许可的情况下，最好是4个Fault Domains，理由 和主机最小要求数量一样。 激活Fault Domain之后，VM的Storage Policies会参考Fault Domains的设定选择Replicas与Witness的位置。Fault Domain的Tolerate数目与Fault Domain的关系如表4-6所示，如果Tolerate为1，则依然是2n+1的关系。 表 4-6 未配置Fault Domains前，8节点的Vir
47、tual SAN Cluster模型的Replicas与Witness示意图如图4-8所示。 配置Fault Domains后，8节点Virtual SAN Cluster模型的Replicas与Witness示意图如图4-9所示，将被分成4个Fault Domains。 由图4-9可以看到，在激活Fault Domains的8节点环境中，Replicas、Witness分布到了不同的FD中，这样极大程度上规避 了同一个刀片中心或机架意外故障导致的Virtual SAN Cluster崩溃问题。 图 4-8 图 4-9 4.5 Virtual SAN Cluster日志问题 按照标准结构做出来
48、的Virtual SAN Cluster是没有地方存放日志信息的，鉴于此，需要选择下面任意一种方案作为日志存 放位置。 单独准备一个共享存储作为日志存放空间。 配置ESXi Dump Collector与Syslog Collector来执行ESXi Host的内存与系统日志收集。 这个选项的配置理由很简单，前面说过了，因为Virtual SAN Cluster输出的Datastore不会用于存放日志，而SD卡/USB启 动的系统也没有介质存放日志记录，所以才需要做这样的额外安排。 4.6 本章小结 工欲善其事，必先利其器。只有在充分完成构建一个新环境的准备工作之后，才能够在构建、配置和使用的
49、过程中得心应 手。 本章从下列几个角度阐述了构建Virtual SAN Cluster的相关注意项和关联注意事项： 存储设备相关； 网络设备相关； 主机设备相关。 针对存储部分，重点阐述了闪存设备和HDD设备的用途、要求以及支持情况。针对网络部分，则详细介绍了vSwitch、Jumbo Frames和Network NIC Teaming负载均衡等方面的细节、兼容性。 还介绍了Virtual SAN 6.0中Fault Domain这个新功能的情况。综合这几个方面的因素，组合起来就形成了构建Virtual SAN Cluster必需的相关组件要求和前提条件。 第5章 构建一个全新的Virtual SAN Cluster 章节概要 本章的核心内容如下： 配置Virtual SAN所需的软件准备； 如何从零开始部署vSphere主机； 如何从零开始部署vCenter管理平台的SLES版