作者：吴秋林
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
VMwareVirtualSAN实战试读：
前言
存储从产生至今，已经经过数十个年头了，天下大势，合久必分，分久必合。在虚拟化、云计算数据中心的大背景下，在满足了企业计算高可用、网络高可用之后，企业对于存储的高可用、双活等的要求也就随之提上了议事日程。
传统的存储解决方案要想实现存储的双活，其中最大的问题就在于：对于用户来说，实现双活的费用太高了，尤其是对于用户的TCO与ROI而言，更是如此。大家可以想一下，这就相当于你买了两台iPhone 6 Plus手机，一台正常使用，一台放着不用。这毕竟不是豆浆，价格低廉到可以让你买一杯倒一杯。
同时，传统的共享存储有一个大问题：支持真正双活的存储设备价格很高昂，而中低端存储设备根本无法实现存储层面的双活。
可随着业务的发展，必然存在双活的要求。正是在这样的背景下，以Nutanix、Ceph和Virtual SAN之类为代表的存储虚拟化产品出现了，这类型的产品最大的卖点就在于：
·不用独立的Standby存储设备；
·不用额外的双活软件支持；
·不用额外的兼容性；
·不用额外的可用性；
·不再需要考虑LUN、Volume等的规划；
·价格低廉；
·改造技术成本低廉；
·深度整合数据中心虚拟化产品；
·……
在存储虚拟化的支持下，存储虚拟化产品全面转向了面向对象的服务级别。所有业务的可用性、数据可靠性，都依赖于面向对象的策略进行工作，可以个性化地针对不同业务级别定义不同的对象策略，实现不同的可用性级别和数据对于物理硬件的写入位置分割。
在保障计算可用的基础上，存储虚拟化产品同时保障了数据的可用性。在闪存设备与HDD设备的有机组合下，提供了远超传统共享存储的IOPS支持，解决了传统性能密集型业务（例如：Oracle数据库之类的业务）无法运行在x86平台上的问题。
在软件定义存储产品出现之前，x86结构下对于承载OLTP（Online Transaction Processing）或OLAP（Online Analytical Processing）之类的业务是有所欠缺的。因为x86结构下的业务模型，导致了对计算、I/O密集型业务的承载能力的欠缺，尤其是I/O密集型业务，比如Oracle RAC之类的业务、医疗领域PACS系统等。传统的SAN存储用于虚拟化，要么成本过高，要么无法匹配x86虚拟化本身。正是在这个背景之下，Server SAN出现了，其迅速迎合了这类业务的需求。
以Virtual SAN为例，它已经得到了国内部分三甲医院的认可，并用于PACS系统，也得到了部分证券型业务的认可。虽然现在其应用规模还不算太大，但无疑证明了它的可用性。第1章Virtual SAN产品概念章节概要
本章的核心内容如下：
·Virtual SAN产品介绍；
·Virtual SAN关键概念；
·Virtual SAN与传统存储的异同；
·Virtual SAN的多种构建方式；
·Virtual 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个生产发布版本。它利用物理服务器本地硬件设备资源，以类似分布式存储技术的方式，为vSphere Cluster中的所有ESXi Hosts提供共享存储服务。Virtual SAN创造性地利用策略驱动技术来帮助vSphere环境提供最简化、最高效和最快速的存储部署与管理支持。利用VM级别的存储策略，Virtual SAN支持自动化、动态的按需匹配VMs存储资源分配。有了Virtual SAN，针对存储的管理、维护、扩容等，都将变得异常简单。同时，存储带来的额外硬件成本开销也变得更加低廉。相对于传统存储而言，Virtual SAN的优势主要体现在下列几个方面：
·低成本；
·低管理成本；
·高可用性；
·管理简单；
·高弹性；
·高性能；
·支持融合式能力；
·同城双活。
利用位于物理服务器本地的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 SAN 5.5、Virtual SAN 6.0中与全闪存存储的功能比较。表 1-11.2Virtual SAN关键概念
Virtual SAN作为区别于传统集中存储的类分布式存储技术，在基础概念上，与传统存储的概念有着巨大的差异。Virtual SAN的关键基础概念如表1-2所示。表 1-2
作为一款面向对象的存储虚拟化产品，Virtual SAN中最重要的基础概念就是对象。在Virtual SAN中，对象涵盖的内容如表1-3所示。
除了对象之外，由于Virtual SAN是一款Storage Policies Based的存储，它以虚拟机对象为颗粒度参考，因此可为不同的虚拟机以及其对应的对象提供不同程度的可用性级别，而为了满足可用性级别的工作需求，在Virtual SAN有一个基础概念叫作Witness。Witness是一个仅包含Metadata，不包含应用数据的组件。它唯一的用途就是在故障发生后，Datastore需要做可用性调整时，充当可用性调整时的见证用途。在Virtual SAN 1.0文件系统中，它大约会消耗Metadata 2MB的空间，Virtual SAN 2.0中，它大约会消耗Metadata 4MB的空间。表 1-31.3Virtual SAN与传统存储
从概念上讲，Virtual SAN与传统存储存在很多差异，实现形式、对象处理、扩展能力等各方面，都存在着差异。
同时，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帮助企业实现了一体化的管理员交付模式。
·Virtual SAN利用Storage Policies，帮助VMs在生成时，自动匹配自己的策略，灵活地实现了不同可用性级别与条带化级别的交付。
Virtual SAN很好，但是当前它最大的局限就在于它只支持vSphere产品，这一点是它相对于其他存储产品最大的优势，也是最大的劣势。所以Virtual SAN不是万能的，它只能用作Virtual SAN Cluster节点的存储用途，无法用作其他用途。不过，有消息称，在后续的版本中会加入对第三方服务器虚拟化产品的支持及推出类似NAS的功能，以便让它也具备传统存储的文件共享功能。
另外，软件定义类型的存储对于空间的开销是蛮大的，所以，如果要用它，需要有这个思想准备，也就是50％以上的空间浪费比例。1.4Virtual SAN的构建方式
针对Virtual SAN的构建，基础设备准备部分支持以下3种模式：
·Virtual SAN Ready Nodes；
·VMware EVO：RAIL；
·DIY。1.4.1 Virtual SAN Ready Nodes
Virtual SAN Ready Nodes这种Virtual SAN准备模式表示通过了VMware公司对应Virtual SAN版本兼容性测试的现存物理硬件设备，其中包含了几家国际性厂家的成型产品，包括CISCO、DELL、IBM、HITACHI、SUPERMICRO、HUAWEI、HEWLETT PACKARD等几家国际知名硬件设备提供商，详情请查阅：VMware Virtual SAN Ready Nodes。利用Virtual SAN Ready Nodes，可以直接选购List清单中的物理服务器设备，然后按照Virtual SAN的部署策略标准化部署即可。
这种部署方式是官方推荐的方式，因为Virtual San Ready Nodes经VMware公司官方反复测试过，例如驱动的版本、设备型号、设备固件版本、CPU型号等，都经过反复测试。在稳定性和可靠性上是毋庸置疑的，而且还有一个至关重要的因素，就是VMware公司的官方服务。选购Virtual San Ready Nodes如果出了问题，VMware公司负责解决，如果不选购Virtual San Ready Nodes，VMware公司是不会负责的。在市场上曾出现过这样的情况：由于驱动版本不在兼容性列表中，所以VMware公司判定不在服务范畴。
因此，如果条件允许，强烈建议选择Virtual SAN Ready Nodes来构建存储虚拟化环境。
VSAN Ready Nodes的查询页面如图1-1所示。图 1-11.4.2 VMware EVO：RAIL
VMware EVO：RAIL是由VMware公司出品的一款组合了计算虚拟化、网络虚拟化、存储虚拟化（Virtual SAN）的一体化设备，对于最终用户而言，如果选择EVO：RAIL，只需要将该设备购买回来，即可上架使用。更多VMware EVO：RAIL的相关信息，请查阅地址http://www.vmware.com/products/evorail。目前，全球范围之内，EVO：RAIL一体化设备得到了包括CISCO、DELL等公司的支持，最初HP公司也支持，但截止到2015年08月10日，HP已经放弃支持这个产品了。1.4.3 DIY：Do It Yourself
DIY（Do It By Yourself）顾名思义，就是一种很草根的处理方式，同时也是多数中小型企业最合适的解决方案。它最大的优势就是无视硬件设备厂家，只需要满足Virtual SAN对于设备最基础的要求，即可让任意部署了3台以上vSphere 5.5 Update 1+的企业轻松、快速完成Virtual SAN存储虚拟化的改造，这种做法并不遵循VMware Compatibility Guide（VCG），因此，笔者并不为这种做法承担任何官方的法律责任。但是，需要说明的是：这种做法是成本最低、效率最高的改造基础化设施Virtual SAN Aware的方式。所以，这种解决方案是笔者最欣赏的。
假设一个企业有3台以上的vSphere 5.5 Update 1+的服务器虚拟化平台，但是没有共享存储，如果想要实现Virtual SAN，则只需要做下面的3件或者4件事情。
·购买Virtual SAN 5.5/6.0的License。
·为现有的服务器配备至少一块SSD设备。
·按需配备HDD机械硬盘。
·为每台主机选配1～2个32GB的SD卡或USB盘。
SD卡或USB盘将被用于安装ESXi Server系统，SSD闪存盘将被用于Read Cache，HDD机械硬盘则是虚拟机文件存放点。
从最简化的角度而言，只需要做完上述三件事情，构建一个最简化的Virtual SAN Aware节点的工作就算完成了，无论是从利旧，还是成本方面考量，这都是上佳的选择。同时，还不需要管理员跨界增补知识储备，只需要简单的Virtual SAN知识补充即可完成从管理人员到基础设施的扩展。
但是，DIY方式通常要求维护人员对Virtual SAN的工作原理和组件构成有着深层次的理解，这样才能确保当出现可能存在的问题之后，独立自主地排查问题。同时，需要再次提醒大家的是：这种方式是不被VMware公司推荐的，如果出现什么问题，通常只能自行承担责任。我们的学员、客户群众已经有人用这种方式构建了生产环境并运行了快一年的时间了，而且从没出现过问题，笔者自己也针对这个产品测试了一年左右的时间，没出现过什么问题。
DIY时的查询界面如图1-2所示。图 1-2
友情提醒一：DIY是虚拟人比较推荐的方式，但是即使选择了这种方式，还可以有以下两种选择：
选择一：可以选择使用VMware公司提供的兼容列表中的相关配件来作为改造备选组件。
选择二：可以随意选择一个能基本满足环境改造的备选组件完成改造。
这两个选择，虚拟人建议选择第一种。
友情提醒二：如果选择DIY方式构建Virtual SAN环境，那么，请务必深入学习Virtual SAN的工作原理、它可能存在的故障以及故障解决思路，以便在遇到问题时可以掌控局面。1.5Virtual SAN产品的兼容性
Virtual SAN作为VMware公司自有的存储虚拟化产品，针对VMware公司的其他产品和功能模组，有着强大的耦合支持能力。Virtual SAN支持的VMware公司其他产品如下：
·vSphere Data Protection；
·vSphere Replication；
·vRealize Operations Manager；
·vRealize Automation Center；
·Site Recovery Manager；
·Horizon View。
从vSphere自身的功能组件耦合度看，Virtual SAN与下列vSphere经典功能有着强大的协同工作能力。
·vSphere HA；
·vSphere DRS；
·vMotion；
·Storage vMotion；
·Snapshots。1.6Virtual SAN功能限制
Virtual SAN有着强大的功能，但也有其自身的局限，尤其是针对传统的vSphere功能而言，它不支持下列功能：
·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.7Virtual SAN适用的业务场景
Virtual SAN支持的融合式云计算数据中心模型如图1-3所示。图 1-3
Virtual SAN适用的场量包括：
·多层模型的私有云数据中心。
·A/A与B&R数据中心。
·Horizon一体化BYOD桌面环境。
·vMSC数据中心。
·统一管理集群。
其中，针对虚拟桌面的组合程度是最佳的。根据生产数据显示，Horizon View结合Virtual SAN的组合，轻松解决了传统桌面虚拟化中面临的各种问题，例如所谓的启动风暴问题就在Virtual SAN中得到了完美的解决。
在国内，桌面虚拟化与Virtual SAN组合项目已经得到了用户的广泛认可，堪称Virtual SAN与VMware公司其他产品线的最佳组合。落地的桌面虚拟化项目极好地证实了这一点。1.8本章小结
通过对本章的学习，可以基础性地了解VMware Virtual SAN的基本形态、相关业务契合支持、构建方式、基本用途、基本概念组件、兼容性要求、功能极限等。
充分理解Virtual SAN与vSphere的基础功能兼容性、Virtual SAN的局限等。也就是说，通过对本章的学习，可以了解到什么样的业务类型适合运行在Virtual SAN上，而什么样的功能需求不应该运行在Virtual SAN平台上。
还可以初步了解对传统存储与Virtual SAN之间的大体差别和颗粒度区分，以及在Virtual SAN存储中的基础概念对象、SPBM策略。这个很重要，因为在以Virtual SAN为代表的存储虚拟化产品的工作中，对象与SPMB策略都将会贯穿始终。本章不要求理解这两个概念，但是需要建立起区别于传统共享存储的基本印象，别再用对传统存储的理解来理解Virtual SAN虚拟化存储。第2章软件定义数据中心与Virtual SAN章节概要
本章的核心内容如下：
·软件定义数据中心；
·为什么要SDDC；
·SDDC的核心组件；
·Virtual SAN在SDDC中的定位。
软件定义数据中心（Software Defined Data Center，SDDC）是在虚拟化领域中最早由VMwrae公司于2014年初提出来的概念。它是由计算虚拟化、存储虚拟化、网络虚拟化、自动化、一体化监控等系列模块结合在一起，形成的一个All-in-One的大型自动化云计算数据中心。
根据最近这2年全球科技发展动态来看，SDDC无疑是未来数据中心的趋势，同时从提出SDDC概念的VMware公司的各种动向来看，无论是从VMworld大会展示的主题，还是从VMware公司的产品构成等多个方面的综合，都表明了它的未来发展趋势。目前，VMware公司应该说是为数不多的能够用自己一家的产品实现一个完整的软件定义数据中心的公司。
为什么需要软件定义数据中心？业务系统越来越多，x86设施越来越复杂，企业针对系统、数据、安全、响应速度等方面的需求越来越高，企业数据中心已经发展到需要一个强大的、具备创新性的产品架构出现，而SDDC很明显满足这个条件。
软件定义数据中心给客户带来的优势主要有下面几个方面：
·为用户交付统一的平台；
·实现融合式业务与办公交付；
·强大的安全性与控制能力；
·大幅度缩减企业新业务上线的时间。
·可以轻松实现Public Cloud与Hybrid Cloud接口。
软件定义数据中心的结构如图2-1所示。图 2-12.1VMware软件定义数据中心产品清单
归纳起来，VMware公司的软件定义数据中心产品如下：
·vSphere；
·VSAN；
·NSX；
·vRealize Automation Center；
·vRealize Operations Manager；
·Horizon。
从最基础的构成来看，上述产品中，最基础、最核心的产品是前5个。接下来将介绍前5个产品的结构和特征。2.1.1 vSphere计算虚拟化
在SDDC的概念中，通常会将vSphere定义为SDC（Software Defind Compute）。在VMware公司的产品线里，它有着绝对的基础性、中心化地位，VMware公司几乎全系列产品都围绕着vSphere展开，vSphere的存在，是VMware得以称霸x86虚拟化领域的重要支撑点。
vSphere从发布至今经历了超过50个版本，从1.0到今天的6.0，有着长足的发展和变化，图2-2所示为vSphere的产品结构形态。图 2-2
从图2-2中可以看出，vSphere的核心工作模式就是通过虚拟化技术允许在一台强劲的物理服务器上运行多台虚拟机，实现资源最大化利用，帮助企业从空间、电力、制冷和运营成本等多方面长期节省资源开销。
作为基础服务器虚拟化产品，它有着强大的稳定性、功能性、可用性、可扩展性等一系列好处。由于本书重点阐述的是Virtual SAN，所以就不再过多地夸赞它了。
友情提醒：对vSphere产品部署不太熟悉的读者，请快速跳转到5章，第5章专门介绍如何安装部署vSphere相关组件产品。2.1.2 Virtual SAN存储虚拟化
Virtual SAN的出现补齐了SDDC的最后一块短板，也算是开启了存储虚拟化的大门。在SDDC中，对Virtual SAN的定义就是SDC（Software Defined Storage），它利用高速闪存与机械盘或全闪存结构的技术方式，第一次可以与中端，甚至部分高端存储在性能上正面对抗。而在可靠性上，与虚拟化环境相比甚至更胜一筹。Virtual SAN的结构示意图如图2-3所示。图 2-3
在Virtual SAN中，一切都是对象，核心对象就是虚拟机和虚拟机中的相关文件，正是对这些文件的处理，完成了Virtual SAN的文件承载。结合类似分布式RAID技术，对虚拟机进行数据安全保护，再结合条带化技术实现按需对象切片，高性能输出。
有了Virtual SAN，就可以完成折衷性价比的VMware软件定义数据中心超融合架构设计的数据承载模块了。2.1.3 NSX网络虚拟化
NSX是VMware公司将2012年收购的Nicira公司与VMware自身针对网络虚拟化部分的积累结合起来，推出的网络虚拟化产品，也是目前全球范围内为数不多的具备商用能力和商用案例的纯软件网络虚拟化解决方案。
NSX包含网络交换、网络安全、分布式路由、VPN、Load Balancer等功能，可以实现Software Overlay。同时，结合Micro-Segment技术，可以帮助企业在纯软件环境中实现大二层的复杂网络环境。
它的架构组件包含以下几个关键性的组件：
·NSX Manager；
·NSX Controller；
·NSX vSwitch；
·NSX Edge；
·Distributed Firewall；
·Distributed Logical Router。
上述组件结合起来，就可以从功能上实现对于下列业务与物理层的解耦：
·Logical Switching：从物理网络层面解耦的大二层网络。
·Logical Routing：在虚拟网络之间实现跨网段数据转发。
·Logical Firewall：分布式虚拟防火墙功能，有较高的性能输出。
·Logical Load Balancer：支持软件实现应用程序层面的负载均衡。
·Logical Virtual Private Network：Site-to-Site的VPN功能。
·VMware NSX API：通过REST API与包含vRA、OpenStack之类的云计算管理平台结合。
·Service Composer：帮助在虚拟基础架构环境中部署和分配网络与安全到应用程序。管理员可以将相关的服务映射到对应的安全组。
NSX与vSphere环境的基础结构示意如图2-4所示。从图中可以快速了解到NSX网络虚拟化产品与vSphere的管理。
NSX作为网络虚拟化产品，既可以单独与vSphere结合，也可以融合在SDDC环境中，作为其中的SDC（Software Defined Network）组件部分，为SDDC提供无缝的软件融合式网络。图 2-4
截止到本书定稿时间，NSX最新版本是6.2.0，如果有读者对NSX实现SDN的技术感兴趣，基础部分可以查询虚拟人的官方网站去查看同样是笔者编写的NSX系列基础文档。当然，如果更多人感兴趣，未来，也可以考虑针对NSX单独编写一本书。2.1.4 vRealize Automation Center自动化云平台
vRealize Automation Center的前身是VMware从Dell公司收购的CAC产品，VMware公司收购CAC后，将其更名为vCAC，全称为vCloud Automation Center，用作VMware公司私有云自动化管理平台。截至本书完稿时，vCAC最新版本是7.0，并且从6.0开始，由vCloud Automation Center更名为vRealize Automation Center。因此，vRealize Automation Center在VMware的SDDC解决方案中，承载的是自动化的部分功能。利用它，可以在SDDC中轻松实现如下功能：
·Infrastructure as a Server；
·Application as a Service；
·XaaS；
·Daas。
vRealize Automation Center通过与vCenter Server的有机组合，可以轻松将vSphere、NSX、VSAN等功能纳入自己的统一协作空间中，再结合自动化的Worflow（vRealize Orchestrator），就可以展现Self-Service Portals与自动化动作流程。
借助vRealize Automation Center，用户可以轻松处理全自动化的工作流程、新的虚拟机请求、审批、生命周期管理等工作，再结合ITBMS组件，即可输出企业的SDDC财务报表信息。而这一系列的特征，正是云计算的基本特征。因此，基于这样的认知基础，我们通常会把vRealize Automation Center称为VMware公司的私有云计算管理平台。
vRealize Automation Center可以管理的对象包含但是不限于vSphere（SDC），它还能统一管理下列产品：
·vCloud Director；
·OpenStack；
·Citrix XenServer；
·KVM；
·SCVMM；
·Hyper-V；
·UCSM；
·iDRAC；
·NetApp Flex Array；
·AWS；
·vCloud Hybrid Service。
因此，从功能与扩展管理能力的角度看，它是足够强大的。它还可以与VMware公司的vCloud AIR产品连接展现更多功能。当然了，对于企业用户而言，利用它来构建一个SDDC会更重要一些。vRealize Automation Center所能做的事情如图2-5所示。图 2-5
当前，最新版本的vRealize Automation Center是7.0，但是如果要生产环境的部署与应用，还是建议使用vRealize Automation Center 6.2.1。
至此，SDDC的一个完整产品组件就全部呈现在大家的面前了，也就说，利用vSphere、VSAN、NSX、vRealize Automation Center可以为企业实现一个最基础的SDDC环境。2.1.5 vRealize Operations Manager统一监控
有了一个完整的SDDC环境之后，就意味着企业有了一个完整的云计算平台。但是，由于这个平台由多个组件构成，每个组件的工作状态、统计信息、是否存在性能问题、是否出现故障问题，等等一系列的问题，都需要有很好的处理方案，这样才能够为企业交付高效运维能力。
VMware公司针对这个需求的答案是：vRealize Operations Manager（vROPS），当前最新版本是6.1.0。利用vROPS，可以轻松实现针对下列产品的统一监控与报表生成。
·vSphere；
·NSX；
·Virtual SAN；
·vRealize Automation Center；
·Horizon；
·Database。
除了上述产品外，vROPS还可以针对整个SDDC环境提供一个统一的环境硬件监控。自动化的报表能力和自定义的报表能力在SDDC运营中是非常必要的。
记得早在2013年左右虚拟人举行一年一度的技术沙龙时，笔者在沙龙上就阐述过未来的运维要求是怎样的。当时提出的超级运维概念，实质上针对的就是SDDC的运维能力。传统的数据中心管理技能在未来已经不再实用，在自动化的SDDC环境中，要求工作人员至少具备理解和使用SDDC核心组件的能力。同时，要求工作人员对于vROPS这样的统一监控平台具备轻松驾驭、灵活输出的能力。vROPS的界面Dashboard可以比较灵活地展现出当前整体SDDC的状态，如图2-6所示，Dashboard窗口中的Health、Risck、Efficiency分别代表当前SDDC的状态。图 2-6
图2-7所示的Dashboard则是进一步深入展示了vROPS这个统一监控平台强大的整体环境状态把控能力。通过图2-7中的Risk选项可以很轻松地知道当前存在哪些可能的问题。通过Efficiency选项可以看到当前系统的运行效率，在vCPU、vRAM和Disk几个方面的利用率情况，当前的资源分配是否存在浪费，当前环境是否存在可回收的资源部分：图 2-7
vRealize Operations Manager作为统一监控平台，它是强大的。虽然它的部署不太复杂，但想要真正用好，还是需要很多知识储备的。因此，笔者也会考虑根据需要专门针对vRealize Operations Manager的深度使用方式撰写一本关于这个产品的书籍。2.1.6 Horizon桌面虚拟化
Horizon在SDDC中不是必选项，因为它帮助企业实现的功能是桌面虚拟化，而桌面虚拟化的概念放到云计算平台中之后，就变成了现在很多云计算服务商所说的云桌面或桌面云。
Horizon有很多版本，其间的名字、功能也是几经变化，由最早的VDI变成View，再到Horizon View和目前最新的Horizon。名字的变化不但意味着版本的更新，也意味着不断增强的性能和不断新增的组件。截止到现在，最新的Horizon版本是6.2，在Horizon 6.2中，存在如下3个大的产品组件：
·View；
·Mirage；
·Workspace。
如图2-8所示，Horizon中包含了上述三个组件。图 2-8
这3个组件的用途分别如下：
·View用于帮助企业实现虚拟桌面，它的竞争产品是Citrix的XenDeskop和微软的VDI。当然，现在还多了一些基于KVM解决方案的国产桌面虚拟化解决方案，例如华为、H3C等公司的产品。
·Mirage是企业桌面系统的统一管理平台，可以帮助企业实现针对桌面系统的统一管理，这个统一管理包含统一升级、统一打补丁、统一部署软件、统一安全保护等功能，也可以实现远程分支机构统一桌面的高效率、低成本管理。
·Workspace用于存放虚拟桌面与虚拟应用程序，某种程度上比较类似于企业的内部虚拟桌面逻辑空间归类工具。登录Workspace，就可以轻松实现桌面应用虚拟化与桌面虚拟化的访问和展示。
图2-9为一个接入了类似vRealize Automation Center的云计算管理平台的Horizon环境，这也是一个相对成熟、可商用的结构。图 2-9
上述内容结合起来，可以构建一个强大的SDDC，而上述组件分开存在，也可以为企业按需提供不同层面的服务输出。
VMware公司正是利用上述产品组件帮助企业实现了一体化SDDC的交付。当然了，在SDDC中还可以按需纳入更多其他的第三方产品。例如，Veeam Backup&Replication用来做数据安全备份、Site Recovery Manager用来做数据中心异地容灾、Stretched Cluster用于实现双活存储等。正因为可以灵活地增减不同的组件，所以软件定义数据中心才会有较大的吸引力。因为做这些事情都不需要过多考虑Hardware Compatibility的事情，基本实现了软件与硬件的分离。2.2软件定义数据中心之软件定义存储
从软件定义数据中心的字面意思就可以看出，这要求用纯软件来实现。而一个数据中心涉及的主要组件就是计算部分、网络部分、存储部分、安全部分等。要实现软件定义数据中心就必须存在软件定义存储。
只有利用软件定义存储，才可以灵活实现高性能、高弹性、硬件无关和分布式等软件定义数据中心需要的基本特征，从而将所有的存储对象软件化，按需实现不同SLAs的业务等级交付。
当前，全球范围内的软件定义存储——对象存储的主要产品有下列几款：
·从OpenStack项目衍生出来的Ceph分布式存储项目；
·Swift存储；
·Virtual SAN；
·VVoLS；
·Datacore；
·Storage Virtual VSA。
利用这些产品，都可以构建一个对象存储，而且都可以实现软硬件分离的软件定义存储的基础特征。但是构建一个SDDC并不是说实现了软硬分离之后，就可以了。还有很多问题需要考量，尤其是不同产品组件之间的配合选型问题。2.2.1 构建软件定义数据中心的概念
构建软件定义数据中心的方式有两种，一种是用厂商封装的成型软件定义数据中心产品，如VMware公司的EVO：RACK、EVO：RAIL之类的。这类产品内置了一个BOX，可即插即用。另一种方案是自行DIY一个软件定义数据中心，这种方式可以借助开源计算虚拟化、网络虚拟化、存储虚拟化之类的方案来实现，不过这样做的技术成本和后续问题实在数不胜数了。因此，通常都不会选择这种方式，这种方式对于提供方和用户方来说都是灾难。
目前，笔者推荐的解决方案是利用VMware公司完整的产品线自行DIY软件定义数据中心，而2.1节阐述的组件是其中的关键，这些组件各自的用途是：
·vSphere负责SDC部分。
·VSAN或VVoLS负责SDS部分。
·NSX负责SDN部分。
·vRealize Automation Center负责Automation部分。
·vROPS负责统一监控部分。
利用这些产品的组合，就可以形成一个初具雏形的软件定义数据中心环境。这个环境虽然没有统一的管理界面可用，但是绝对具备软件定义数据中心的完备特征，用户如果需要一个统一的UI，则完全可以开发一个Home Page，利用这个Home Page分别调度相关组件，即可完成从基础的软件定义数据中心统一管理整个数据中心相关组件。2.2.2 软件定义存储选择
从VMware公司的软件定义存储概念来看，它将软件定义存储定义为两种类型：VVoLS和Virtual SAN。
这两种VMware SDS存储解决方案的结构示意如图2-10所示，图左边部分是Virtual SAN，右边部分是VVoLS，两者可以共存于vSphere平台中。图 2-102.2.3 VVoLS技术特征
VVoLS（vSphere Virtual Volumes）是针对共享存储的一种软件定义存储技术。它通过对EMC、NimbleStorage、NetApp、HITCHI、DELL之类的存储产品公司结合VMware公司提供的VASA接口类型来实现软件定义存储功能，允许虚拟机直接对存储进行操作，跳过VMFS，变相实现业务与硬件的分离。VVoLS的结构示意图如图2-11所示。图 2-11
VVoLS的技术特色如下：
·VVoLS利用Storage Container（SC）来实现跨厂商的虚拟存储池。
·Protocol Endpoint（PE）负责处理虚拟机IO，每个存储设备对应一个PE，虚拟机的IO发到PE后，由PE定向到对应的VVoLS。
·Storage Provider（SP）负责实现vCenter与存储设备之间的通信。这是一个VMware公司提供的标准接口，由存储厂商在存储端实现，利用VASA（VMware vStorage APIs for Storage Awareness）接口与vCenter之间建立存储配置通道。VVoLS可实现虚拟机到存储设备的双向通信，而在这之前只能实现单向信息流通信。
利用VVoLS技术最终可实现VM-Aware存储的模型，进而可以轻松实现虚拟机快照等业务。
VVoLS的应用优势如下：
·可以简化存储的运维，轻松实现快速调整存储。
·可以借助云计算自动化工具进行自动化调配。
·可以轻松利用Array本身的功能。
·可以执行动态配置。
·可以提供虚拟机级别的颗粒度控制。
·支持与策略结合的自动化合规性保障。
·可以有效提升容量利用率。
但是，这种VVoLS技术对存储的要求是很高的，简单说就是要求物理存储支持VVoLS-Aware，普通的存储是不行的。因此，虽然它是一个很好的概念，但是这个概念的实现成本太高了。2.2.4 Virtual SAN技术特征
Virtual SAN是另一种软件定义存储的选择。低成本、高效率、高性能输出、高扩展能力等多方面的综合功能输出是它最大的价值体现。如果说VVoLS方案在成本、准入门槛等方面都更高，那么Virtual SAN则是有着下列几个方面的优势：
·超级简单的配置；
·超级简单的UI提供；
·SPBM策略驱动；
·超强弹性；
·超高性能输出；
·无缝整合vSphere；
·无重复化固定资产投资；
·无中断扩容；
·运营人员超易入手。
一系列优势的结合，都充分证明了一点：如果要选择VMware公司的SDDC解决方案，软件定义存储的最佳选择就是Virtual SAN。Virtual SAN基础概念、结构和用途在第1章已经初步介绍了，这也是本书的核心内容。
利用Virtual SAN构建VMware版本的DIY SDDC方案，只需要购买Virtual SAN的License，然后将企业现有的vSphere平台升级到5.5 Update 1以上的版本即可。而要构建一个具备生产能力、生产可靠性的软件定义存储产品，自然是让vSphere升级到vSphere 6.0，至少选用2.0版本的Virtual SAN来完成软件层面的准备。
之所以这样做，是因为要想改造企业现有的环境，完成软件定义存储的准备工作并不需要大动干戈，只需要为服务器增补合适的闪存卡、万兆网络、HDD磁盘即可。
再结合2.1节对于Virtual SAN的描述，即可轻松明白为何在VMware DIY SDDC的构建中选择Virtual SAN作为软件定义存储组件了。2.3为软件定义数据中心准备Virtual SAN
为软件定义数据中心准备Virtual SAN这个软件定义存储在第3章会详细阐述。这里只是简单说明。准备Virtual SAN的基础要求如下：
·3台以上的x86服务器；
·3块以上闪存设备；
·3块以上HDD设备；
·兼容Virtual SAN的I/O Controller；
·最小千兆网络，最佳万兆网络；
·vSphere 6.0服务器虚拟化。2.4本章小结
关于软件定义数据中心的概念，本章并没有从完整技术层面完善每一个组件的功能、用户描述和初始化配置。毕竟，如何构建一个企业软件定义数据中心不在本书的范畴。
本章的主要内容是软件定义数据中心的存在方式、组件构成和SDS在SSDC中的定位。
本章阐述了SDC、SDS、SDN、Automation、vROPS以及Horizon在SDDC中的用途，也为笔者计划后续出版书籍《利用VMware产品实战构建企业级SDDC》开个小头，让读者对SDDC的大概念构成和用途有一个前导性的了解。
本章也重点阐述了VMware SDS产品中VVoLS和Virtual SAN的技术特征和部分技术细则，尤其详细介绍了VVoLS。而对于Virtual SAN本书就是围绕它展开的，所以本章除了它的基础结构外，其他都是泛泛而谈，更多详细内容，请看后面的章节。第3章Virtual SAN配置要求章节概要
本章的核心内容如下：
·配置Virtual SAN的硬件清单；
·配置Virtual SAN的软件清单；
·Virtual SAN对于License的要求。3.1Virtual SAN硬件配置要求
Virtual SAN的硬件配置最佳选择自然是参考VMware Compatibility Guide（参考附录）。具体而言，还是要从以下5个层面来阐述：
·存储设备；
·CPU；
·Memory；
·NIC；
·启动设备。
这几个方面与Virtual SAN的要求如表3-1所示。表 3-13.2Virtual SAN软件配置要求
Virtual SAN内置于vSphere中，仅支持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版本如下：
·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+操作系统安装到物理服务器后，并不需要额外安装什么软件，只需要安装这个vSphere操作系统的物理服务器满足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的客户选择在现有的环境基础上改造Virtual SAN实现存储虚拟化，那么，VMware公司的盈利回报绝对是巨大的。当然，有消息称，未来不排除会有第三方虚拟化产品的兼容支持，但是，笔者认为这样做的意义并不大，也许只会在招投标参数上有所体现吧。
也有人提到Nutanix这样的Server SAN竞争对手。从成本、空间、利旧、工作效率和运营工作人员知识储备等多个角度看，Virtual SAN的优势都是异常明显的。Nutanix之类的产品虽然兼容多款Hypervisor，但是它是一个硬件产品，需要打包购买。另外，它有自己的OS存在，再加上它的Metadata处理机选用的是开源产品，从复杂度和稳定度上看，都有一定的风险。因此，综合而论，虽然不是说Nutanix不好，但是Virtual SAN在VMware软件定义数据中心领域的优势也是显而易见的。3.3Virtual SAN License的要求
Virtual SAN需要单独的License，与vSphere的License并不是同一个，综合起来，在vSphere+VSAN的平台环境中，需要的License就包括了三大类，分别是：
·vSphere服务器虚拟化所需的License
·vCenter Server管理平台所需的License
·Virtual SAN自身所需的License
对于Virtual SAN自身而言，它的License也分为两大类型，分别是：
·用于混合存储环境
·用于全闪存环境
它的License也是依据CPU数量来销售的。具体销售方式与价格，请联系VMware相关代理商获取，VMware代理商列表可从http://www.vmware.com/cn/partners/north.html查询。3.4本章小结
通过本章的学习，相信读者初步了解了配置Virtual SAN在硬件、软件和License方面的要求。本章的着力点就在于向读者说明，想要学习Virtual SAN或者想要为生产环境构建一个Virtual SAN存储虚拟化是多么的简单。
一个新的产品要想普及，最难的就在于它可能会以毁灭性的方式摧毁现有的业务平台，比如，要求购买一套全新设备、软件或要求人员重新进行知识储备。这样的新技术要普及起来就很困难。而Virtual SAN最大的好处就是不需要过多地改动现有基础设施或新购设备，就可以轻松改造现有业务环境的Virtual SAN存储虚拟化。这一点是非常难得的，也是笔者认为Virtual SAN最可取的一个切入点。只有和风细雨般地改造才有可能得到更大的成功可能性，如果一开始就摆出破坏式的姿态，那么，企业的抗拒性就显而易见了。在这一点上，Virtual SAN的优势是独一无二的。即使是知名的Nutanix在这点上也比不上Virtual SAN，因为它至少需要您花掉9万美金之后，才有可能得到它最基础的体验。
有人可能会说Virtual SAN不兼容其他产品，这个问题在本章解释过了。这里说下其他同时支持很多虚拟化软件的产品的劣势。以Nutanix为代表的Server SAN厂家的确支持几乎所有的x86虚拟化产品，但是它是以牺牲性能为代价的。它们通过内置控制软件的方式来实现这个支持功能，也就是说，它们的产品架构至少是三层：硬件→厂商控制软件→虚拟化产品，Virtual SAN是二层结构：硬件→vSphere虚拟化。
另外，Virtual SAN的技术切入成本低到只需要参加虚拟人的“Virtual SAN入门到精通”的培训，再结合本书就可以轻松完成技术准备工作。第4章Virtual SAN Cluster构建准备工作章节概要
本章的核心内容如下：
·Virtual SAN构建的主机层面要求；
·Virtual SAN与存储组件相关的信息；
·All Flash与Hybrid结构下的存储组件相关异同；
·Virtual SAN对于虚拟交换机的支持；
·NIC Teaming策略与Virtual SAN的结合；
·Fault Domain的功能与好处；
·Virtual SAN的日志问题。
构建Virtual SAN Cluster的准备工作主要从硬件与软件这两个大的层面来考量。具体下来，针对硬件部分和软件部分自然又有所不同。
硬件层面主要是三大块：
·存储设备相关；
·网络设备相关；
·主机设备相关。
这个部分相对于第2章所描述的是更进一步细化的内容。
除了软件版本、License部分之外，软件层面的考量则相对复杂一些，主要从Virtual SAN本身的特性展开，核心包含以下多个方面的多个层面：
·存储层面相关；
·网络层面相关；
·Virtual SAN Cluster相关；
·Fault Domains容错模块；
·Virtual SAN日志相关。4.1Virtual SAN存储组件
在构建Virtual SAN之前，有一个很重要的考量就是关于存储设备部分的，因为，存储设备的构成以及物理磁盘设备的数量、空间大小会直接影响Virtual SAN Datastore中的对象数目。在Virtual SAN 6.0中，单台主机支持的最大对象数目为9000，而单个对象的最大容量为255GB（SWAP文件除外，它可以到256GB），超过之后，系统将会对其执行自动切割。因此，如果物理设备数量不够，就会产生各种莫名其妙的问题。
同时，容错级别、条带数目等，都会导致对象数量的倍增。所以，在设计存储的物理设备资源时，需要充分结合这一部分阐述的关联因素去准备物理设备数量。
如果Tolerate为默认值1，则虚拟机相关对象可用物理资源为50％，如果Tolerate值为2，则可用资源就只有33％，如果Tolerate值为最大值3，则可用物理资源只有25％。
这里的详细计算逻辑，将会在下一本书中进一步阐述。
另外，根据Virtual SAN Datastore的不同版本，构建Virtual SAN Datastore文件系统对于每一块磁盘带来的Metadata开销的不同为：v1.0开销为每设备1GB，v2.0开销为每设备容量的1％。
同时，由于vsanDatastore是由Disk Groups构成的，因此，在考虑存储层面时，Disk Groups的数量、SSD与HDD的比例这些也是需要考虑的。当然，具体内容还是会放到下本书中再进行细化。4.1.1 Flash缓存组件
Flash缓存部分主要由以下两种业务场景构成：
·全闪存环境；
·混合存储环境。
图4-1左边是全闪存存储结构，顾名思义就是全部由闪存设备构成。右边是混合存储结构，顾名思义就是由闪存与传统机械磁盘组合起来。
试读结束[说明：试读内容隐藏了图片]