农银人寿vSphere架构设计方案v.docx

A02 Virtualization Design and Deploy Architecture Design NEWVMware 虚拟化部署与设计方案架构设计（第一稿）撰稿：威睿信息技术（中国）有限公司 2010 VMware, Inc. All rights reserved.Page 3 of 43VMware虚拟化设计与部署服务架构设计版本变更记录版本号小数点前为大版本，小数点后为小版本，文档没有重大的变化，大版本不变化。日期作成者版本备注V1.0目录1.概述71.1参与背景71.2项目目标71.3业务需求81.4业务使用案例81.5文档结构82.需求分析102.1目前状态102.2存在问题113.解决方案123.1软件定义的计算之重要性123.2虚拟化解决方案133.3软件定义的计算之优势144.详细设计154.1方案逻辑设计154.2存储设计164.2.1合理设计共享存储架构的重要性164.2.2共享存储设计规范174.2.3存储的冗余性设计174.2.4NetApp存储的Aggregate设计原则204.2.5NetApp存储的Volume设计原则214.2.6各应用程序类型对存储I/O需求的通用参考224.2.7Datastore的容量需求估算：234.2.8Datastore的IOPS需求估算：244.2.9存储设计要点244.3虚拟化网络设计264.3.1设计正确网络的重要性264.3.2网络设计高级指导原则264.3.3网络最佳实践274.3.4网络隔离与VLAN284.3.5物理隔离或VLAN隔离294.3.6虚拟交换机304.3.7虚拟交换机数量的考虑314.3.8虚拟交换机示意图和表格324.3.9网卡绑定334.3.10网卡绑定和可用性344.3.11Network I/O Control354.3.12服务质量（QoS）标签364.3.13物理交换机364.3.14STP注意事项364.3.15基于NetFlow或Port Mirroring的网络监控374.4ESXi主机设计394.4.1ESXi主机硬件需求394.4.2硬件和系统资源394.4.3存储系统404.4.4主机平台414.5vCenter Server的设计424.5.1vCenter平台的选择424.5.2vCenter Server：物理机还是虚拟机？424.5.3vCenter Appliance的硬件要求（Linux）444.5.4vCenter Single Sign-On454.5.5vCenter Server的冗余性464.5.6vCenter故障切换 高可用性474.5.7关于vCenter Server服务的数据库设计484.5.8vCenter Server服务数据库的可用性494.5.9集群与资源池504.5.10vSphere HA心跳冗余514.5.11vSphere DRS集群534.5.12多个vSphere HA和DRS集群544.5.13vSphere分布式电源管理554.6虚拟机设计554.6.1虚拟机硬件兼容性554.6.2虚拟机vCPU的数量564.6.3最大限度提高虚拟机内存性能564.6.4虚拟机磁盘564.6.5虚拟机的vSCSI HBA类型574.6.6虚拟机的vNIC（虚拟网络适配器）574.6.7Guest OS的注意事项584.6.8VMware Tools584.6.9虚拟机的安全584.6.10虚拟机的命名规则594.6.11虚拟机相关的设计决策、理由及含义594.7虚拟平台管理604.7.1通用管理设计指导原则604.7.2基于图形化客户端管理vCenter环境604.7.3vCenter Server的用户和用户组604.7.4管理集群614.7.5时间同步624.7.6快照管理634.7.7NetFlow与Port Mirroring634.7.8任务与事件保留策略634.7.9统计信息收集等级644.7.10性能监控644.7.11警报644.8运维管理654.8.1运维管理注意事项654.8.2产品架构654.8.3基本功能664.8.4运营管理设计、理由754.9安全754.9.1虚拟机的安全注意事项764.9.2虚拟网络的安全注意事项764.9.3网络防火墙与vCenter774.9.4确保基于VLAN的虚拟机安全774.9.5确保标准虚拟交换机端口的安全784.9.6确保管理接口的安全794.9.7通用安全建议794.9.8Lockdown Mode804.9.9vCenter Server的身份验证与用户管理814.9.10加密与安全证书814.9.11确保vCenter Server系统安全814.9.12安全相关的设计决策、理由及含义824.10基础架构的备份与恢复824.10.1vCenter Server数据库的备份824.10.2针对虚拟机级别的备份834.10.3备份策略854.11基础架构备份与恢复相关的设计决策、理由及含义875.参考文献875.1核心文档875.2其它补充文件88附录A：硬件BIOS设置89附录B：网络规范90附录C：推荐的LUN尺寸911. 概述1.1 参与背景1.2 项目目标本文档详细地描述了VMware vSphere基础架构的最佳实践建议将与农银人寿的具体业务需求、目标相结合的基础之上进行实施，并在设计阶段与农银人寿、中科软公司的主要相关人员或SME（领域专家）进行讨论。本文档提供涵盖VMware vSphere基础架构相关的所有组件，其中包含了虚拟机、ESXi主机、网络、存储以及管理方面的要求和规范，以及对逻辑设计和物理设计方面的考虑。物理设计包含了对方案规划和建议的详细信息，以适用于农银人寿的业务需求，这就造成了具体的硬件型号、硬件固件，以及类似的对象可能从设计环节中被省略，以适用于通用的硬件环境。在最初的虚拟化基础架构成功实施后，应确保该架构能够被移植到其它站点上进行实施，以支持农银人寿的虚拟化数据中心对未来规划与部署的可扩展性。1.3 业务需求该体系架构通过逻辑设计来进行描述，与特定的硬件详细信息无关。此外，还要提供为该逻辑设计选择的物理设计组件的规格。只要农银人寿的业务需求未更改，使用该体系系架设计来实施解决方案时可以使用不同的硬件供应商。业务需求明确了农银人寿的虚拟化设计和部署解决方案，该架构设计将包括如下内容： 将120台物理服务器通过虚拟化技术整合到20台ESXi服务器上。 ESXi服务器的资源容量必须能够满足即将被虚拟化的120台物理服务器的计算需求。 部署完VMware vSphere虚拟化后，应能够相应地减少数据中心对于散热、冷却和维护的成本。 为农银人寿提供一个坚实的虚拟化基础架构，通过虚拟化为其关键业务应用程序提供诸多优势。 以VMware vSphere平台作为基础，在其数据中心内实现一个强大的灾难恢复（DR）解决方案。 这里包括农银人寿的 包括 特定业务需求。 调整虚拟化容量规模，以确保与当前的物理工作负载相比没有显著的性能或稳定性变化。 能够应对农银人寿预期的x86服务器未来一年30%增长率。1.4 业务使用案例虚拟化基础架构环境的使用目标案例将包括如下： 生产服务：o Active Directory、DNS、DHCP等30台。o 业务的关键应用程序（例如：个险、团险、银保通、网销、中介、影像等服务）。 测试和开发服务。 DMZ服务。 远程数据中心（作为灾难恢复策略的一部分）。1.5 文档结构本文档中所描述的虚拟化设计和部署架构被组织成表中所列出的部分。表1-1. 架构布局章节描述架构概述架构设计方法整体方法论、框架和设计方式。需求、限制、架设以及风险表格内包含在研讨会阶段所收集的长安责任保险的具体情况信息。当前状态分析评估长安责任保险的当前基础架构状态对虚拟化的准备。核心技术堆栈共享存储设计概述共享存储设计的重要性，以及存储基础架构的详细逻辑和物理设计。包括针对共享存储的最佳实践和设计决策。网络设计概述网络设计的重要性，以及网络基础架构的详细逻辑和物理设计。包括针对网络设计的最佳实践和设计决策。ESXi主机设计概述ESXi主机设计的重要性，以及主机基础架构的详细的逻辑和物理设计。包括针对ESXi主机设计的最佳实践和设计决策。虚拟数据中心概述虚拟数据中心设计的重要性，以及虚拟数据中心基础架构的详细逻辑和物理设计。包括针对虚拟数据中心设计的最佳实践和设计决策。虚拟机概述虚拟机设计的重要性，以及虚拟机基础架构的详细逻辑和物理设计。包括围绕虚拟机设计的最佳实践和设计决策。vCenter Server概述vCenter Server设计的重要性，以及vCenter Server基础架构的详细逻辑和物理设计。包括针对vCenter Server的最佳实践和设计决策。总体设计元素管理与监控概述使用各种工具管理和监控虚拟化基础架构的重要性，包括设计管理和监控解决方案的最佳实践与设计决策。基础架构安全概述使用各种工具保护当前虚拟化基础架构的重要性。包括针对安全解决方案的最佳实践和设计决策。基础架构的备份与恢复概述备份与还原对虚拟化基础架构各个组成部分的重要性。概述使用各种工具管理和监控当前虚拟化基础架构重要性。包括针对备份解决方案的最佳实践和设计决策。该设计文档将伴随着： VMware Virtualization Design and Deploy Service Validation Workbook文档，它提供了用于验证VMware虚拟化环境的安装和配置详细步骤。 VMware Virtualization Design and Deploy Service Configuration Workbook 文档。2. 需求分析2.1 目前状态根据农银公司所提供的现有数据中心包括核心业务120台服务器和非核心业务的30台服务器，一共150台服务器，按照职能不同规划为八个主要的分区，分别是： 核心DB区域：核心系统数据库业务区域 核心APP区： 核心系统应用服务器区域 生产业务区： 设厂系统数据库业务区域，包括生产应用服务器和生产数据库服务器； 办公业务区： 包括办公OA系统、资金系统、投资系统、 测试区： 业务开发测试区域 银保通区： 外联区域，与其他金融机构银行或保险业务相连，前端有防火墙隔离； 互联网区： 外联区域，Internet 服务； 分支接入： 外联区域，由于分公司大恒廊坊电话中心红莲电销业务其中大部分服务器已经老旧，一些服务器可能会在虚拟化整合项目中被淘汰，服务器系统将逐步迁移到虚拟化平台中，一些配置比较高的服务器将在今后考虑升级硬件再利用：图2-1 农银人寿架构图2.2 存在问题传统的数据中心，应用服务器采用竖井的方式，每台服务器上运行一个应用程序，服务器硬件以及上面的操作系统和应用以紧耦合的方式捆绑在一起。这种模式导致服务器的CPU和内存等物理计算资源利用率低。在典型的 x86 服务器部署中，平均只有总容量的 10% 到 15% 得到利用，计算资源浪费严重。从硬件采购成本来说，物理基础架构成本日益攀升。为支持不断增长的业务和应用需求，需要大量的硬件购置和更新换代。一方面，闲置在服务器中的计算资源无法充分利用，另一方面，需要不断购置新的服务器以应对新应用的部署。随着硬件设备的增加，机房有限的空间资源受到挑战。从维护角度来看，由于大多数计算基础架构都必须时刻保持运行，随之而来的能耗、散热和设施成本不断攀升。此外，随着计算环境日益复杂，基础架构管理人员所需的专业教育水平和经验以及此类人员的相关成本也随之增加。组织在与服务器维护相关的手动任务方面花费过多的时间和资源，因而需要更多的人员来完成这些任务。据估计，管理员花费大约70%的时间支持或者维护无法给公司带来任何价值的运维活动。更令人沮丧的是，尽管维护服务器基础架构和应用的成本大量占据了企业的资金和人力。管理层仍不断向IT经理施加压力，要求他们在保证一定SLA(服务级别协议)的同时，在相同甚至更少的IT预算下应对不断增加的业务请求。传统竖井式数据中心里复杂和脆弱的基础架构使IT无法适应快速的变化和更新，无法满足新业务部署和变化的需求。直接导致的结果是，基础架构的复杂和冗余拖累了IT的响应速度，而IT的不灵活进而拖累了业务的响应速度。IT成了拖累公司赚钱的绊脚石。图2-2：IT投资比例数据中心的问题，绝不仅仅是服务器计算资源的浪费，更多的是由此引发的运维开销和管理的不灵活。上图表面，在居高不下的IT投资中，基础架构维护和应用维护占了70%以上，只有不到30%用来投资新应用和基础架构来满足业务的创新需求。IT的资源浪费直接影响了业务。在现今科技驱动的全球化市场形势下，企业的业务直接依赖于IT架构。简而言之，业务的灵活依赖于IT的灵活。 3. 解决方案3.1 软件定义的计算之重要性软件定义的计算，即在x86平台上通过软件实现的对服务器计算能力的虚拟化。它是软件定义数据中心（SDDC）的基础，位于云计算基础架构的最底层。软件定义数据中心的概念不同于其他的云服务，其重点关注于基础设施即服务（laaS）。laaS产品实现了抽象化、自动化、封装和基于虚拟化的云互联来创建一个基于软件的数据中心。“软件定义”将是数据中心下一次变革的发展方向，基于虚拟基础设施之上，通过创建自服务的管理门户以改变传统IT供给的方式，将一个虚拟化数据中心转变为软件定义数据中心后能够启用自动化和自服务功能，使得信息化底层IT资源弹性、交付更加灵活、管理可控、符合业务发展需要，从而构建企业自有laaS私有云或混合云。图3-1：SDDC模块组件狭义来说，软件定义的计算就是服务器的虚拟化，通过虚拟化可以在底层硬件设备物理资源之上提取出一个抽象层，为系统提供与实际形式不同的资源。从本质上说，硬件资源是有限的。服务器虚拟化突破了这些限制，VMware技术将整个x86服务器虚拟化为逻辑实体虚拟机。通过虚拟化层（也称为虚拟化管理层hypervisor）可以在单个物理机器上运行多个操作系统。虚拟化层使得上层的操作系统独立于底层硬件，为在单台服务器上整合各种基于服务器的服务带来了许多可能性。图3-2：服务器虚拟化下面是业界比较公认的关于服务器虚拟化的定义：“简单来说，服务器虚拟化就是淡化用户对于物理服务器上的计算资源，如处理器、内存、I/O设备的直接访问，取而代之的是用户访问逻辑的资源，而后台的物理连接则由虚拟化技术来实现和管理。 ”3.2 虚拟化解决方案 农银将在北京数据中心建立VMware虚拟化平台，考虑未来几年的业务增长需要，将现有服务器逐步迁移到新购20台物理服务器上。利用VMware 虚拟化vMotion、DRS、HA等技术来保障系统的健壮性和稳定性。 图3-3 虚拟化拓扑结构存储方面，由于VMware虚拟化平台数据都存储在存储设备上，通过FC光纤交换机组建SAN网络环境，将VMware vSphere 主机与NetAPP 存储、H3C存储和EMC存储通过光纤连接起来。3.3 软件定义的计算之优势软件定义的计算解决方案是针对 x86 系统的虚拟化技术，旨在解决上述所面临的众多难题，并将 x86 系统转变成通用的共享硬件基础架构，原先多台服务器完成的工作可以整合到少数服务器完成。摆脱了竖井式的结构，服务器物理硬件、操作系统和应用以松耦合的方式联结，虚拟机和上面的操作系统和应用完全独立于底层的硬件。与此同时，服务器虚拟化解决方案，通过把服务器计算资源抽象化、池化和自动化来实现资源的自由调配和充分利用。使资源充分利用，并按需调配。当数据中心的服务器需要升级或维护的时候，通过虚拟机迁移技术可以把服务器上的虚拟机在工作状态迁移到另一个主机，始终保持业务的连续性。服务器虚拟化大大增加了数据中心的灵活性和IT的敏捷性，减少管理的复杂度和IT响应时间。图3-4：软件定义的计算的优势VMware软件定义的计算平台可以帮助企业客户节约资金、能源和时间，简化管理和运营：通过整合硬件和提高服务器利用率降低IT成本利用业界最可靠的服务器整合软件套件 VMware vSphere 来整合服务器硬件，可以帮助企业：u 将现有硬件利用率从 5-15% 最多提高到 80%u 将硬件需求减少到原来的十分之一或更少从单一控制点管理虚拟基础架构多数供应商都只提供针对服务器虚拟化的单点解决方案，而 VMware 则提供了从单一控制点管理整个虚拟基础架构的能力。使用经过生产验证的 VMware vSphere，企业能够：u 将执行部署的时间缩短 50-70%u 从中央位置管理虚拟机u 监控虚拟机及其主机的性能这些好处及其他好处使我们 85% 以上的客户能够在生产环境中将 VMware 虚拟机应用于广泛的应用程序。自动化数据中心的虚拟基础架构以实现峰值性能提供物理基础架构所无法实现的性能、可扩展性和可用性级别。将 VMware vCenter Server 与我们的 VMware vMotion 和 VMware DRS (Distributed Resource Scheduler) 产品结合使用，能够实现：u 通过实时迁移虚拟机避免计划内停机u 通过自动执行负载平衡实现基于策略的 IT 资源动态分配u 消除许多重复的配置和维护任务4. 详细设计4.1 方案逻辑设计如下示例图，描述的是可以作为概念设计一部分的主机、存储和网络之间的关系。在与主要的关键决策者或SME会谈时发现，有一项安全策略要求在DMZ服务器与内部服务器之间进行物理硬件（网闸）隔离。vSphere能够在同一个硬件平台上安全承载DMZ和内部服务器，只要保证TCPIP网络联通性，即可保证内外网数据的安全性。因此，该图为DMZ和内部服务器列出了它们各自的主机以及存储和网络资源。会谈时，尚未与农银人寿公司明确了生产服务的恢复时间目标（RTO）以及数据备份的方法，暂时空缺。图4-1. vSphere逻辑设计在针对农银人寿的虚拟化数据中心环境中，将包含共享存储配置的逻辑架构设计。vSphere集群相关的高级功能需要利用到共享存储，这包括例如vMotion、vSphere HA、vSphere DRS以及Storage I/O Control和Profile Driven Storage等功能的实现。通过实施共享存储，可以实现所有ESXi主机在同一vSphere集群中能够访问到同一组共享的Datastore，并运行虚拟机。4.2 存储设计4.2.1 合理设计共享存储架构的重要性 在vSphere环境中，共享的Datastore可以通过FCoE、FC、iSCSi协议，或基于文件级的NFS共享协议而创建。下列表格中，我们针对不同类型的存储设备所支持的vSphere功能进行了详细对比。表 4-1. 不同类型的存储设备所支持的vSphere功能存储类型引导虚拟机vSphere vMotionDatastoreRDMVM ClusterHA/DRSStorage APIs Data ProtectionLocal StorageYesNoVMFSNoYesNoYesFCoEYesYesVMFSYesYesYesYesFibre ChannelYesYesVMFSYesYesYesYesiSCSIYesYesVMFSYesNoYesYesNFSYesYesNFSNoNoYesYes从表格中您可以看出，FCoE和FC的存储类型，所支持的功能是最多，农银公司现有的Fibre Channel（FC）存储设备，因此在本架构设计方案中将选择FC协议作为存储协议，架构来构建vSphere虚拟化环境。正确的存储架构设计可为虚拟化数据中心奠定一定的良好性能基础，此外还能够实现如下目的： 防止未经授权的人员访问业务数据。 保护数据免受硬件和软件故障的影响。 保护数据免受恶意或意外破坏的影响。正确的存储架构设计对客户组织实现其业务目标能力，有着积极的影响。高级共享存储的设计指导原则 存储的架构设计必须经过合理优化，以满足农银人寿的应用、服务、管理员和用户的多样性需求。 目标是战略性地协调业务应用与存储基础架构，以降低成本、改善性能、提高可用性、提供安全性，以及增强功能。 必须使用从当前状态分析以及与农银人寿的主要相关人员和领域专家（SME）会谈所收集到的信息，将应用数据分配到相应的存储层。 每个存储层应具有不同的性能、容量和可用性等特征。 并非所有应用都需要昂贵、高性能、高度可用的存储，应为不同的应用类型设计出不同的存储层，以提高经济效益。4.2.2 共享存储设计规范本节详细解释针对农银人寿的共享存储平台所推荐的建议。表 2-2. 存储配置规格信息属性规格存储型号/协议类型FAS3250A / FC 协议存储控制器数量2控制器（冗余）FC交换机数量2台（冗余）LUN大小推荐1 TB，最大2 TB。LUN总数具体数量待定VMFS版本5Zoning架构根据NetApp最佳实践，推荐采用Single-Initiator/Multi-Target Zones的模式保护Fibre架构，以避免RSCN（注册状态更改通知）风暴并降低SAN交换机的配置复杂性。4.2.3 存储的冗余性设计为vSphere虚拟化数据中心架构提供具有冗余性的存储设计至关重要，它将提升存储的可用性、可扩展性以及性能，应从如下几个方面配置存储的冗余性： 冗余的存储网络组件。 冗余的存储路径。 冗余的存储控制器。 冗余的LUN配置（使用RAID技术）。VMKernel内置包含了支持存储设备多路径的模块，叫做Native Multipathing（NMP）。NMP能够检测受支持的存储类型，并自动配置NMP堆栈以支持存储的能力。NMP和Clustered ONTAP 8.1及之后版本都支持Asymmetric Logical Unit Access（ALUA）协议来协商Optimized（Direct）路径和Unoptimized（Indirect）路径。在Clustered ONTAP中，支持ALUA协议的ESXi主机会使用Optimized（Direct）路径对数据进行访问，Direct路径是通过LUN所在节点的一个Target端口去访问该LUN。默认情况下，ALUA协议在ESXi主机和NetApp存储控制器两端都是被启用的。ESXi的Native Multipathing（NMP）模块会认为NetApp存储是ALUA类型的存储，会使用ALUA存储阵列类型插件（VMW_SATP_ALUA），并且选用Round Robin（轮循策略）路径选择插件（VMW_PSP_RR）。这意味着由于使用了ALUA协议，当Optimized（Direct）路径可用时，到LUN的I/O还是在2条Direct路径之间切换。下图展示了一个由2节点NetApp HA集群中的一个LUN，在总共具有4条I/O路径的环境中，具有活动I/O的只有2条Optimized（Direct）路径。图4-2、 存储多路径存储多路径准则： VMware 建议ESXi服务器使用两个单端口的HBA适配器，而不是一个双端口的HBA适配器。 确认多路径策略与存储阵列类型相匹配：o 对于“Active-Passive”类型的存储阵列，推荐使用“Most Recently Used（MRU）” 选项。（避免路径超负荷）。o 对于“Active-Active” 类型的存储阵列，推荐使用“Fixed”或“Round Robin”选项。o 对于“ALUA（异步逻辑单元访问）”类型的存储阵列，推荐使用“MRU”或“Round Robin”选项。o 对“Virtual Port（虚拟端口）”类型的存储阵列，推荐使用“Most Recently Used（MRU）” 选项。o 始终参考阵列文档以了解具体的多路径策略支持。 可能存在第三方多路径功能插件。对这些插件使用供应商建议的选项。图4-3 VMware 存储多路径示意农银人寿要求存储环境更为强大，则必须实施存储多路径。对于采用Fibre Channel协议的NetApp存储，建议使用ALUA（非对称逻辑单元访问）协议与Round Robin（轮循策略）路径选择策略。ALUA允许在SCSI目标设备和目标端口间自动协商路径，从而实现动态重新配置。ESXi主机上默认启用ALUA。在NetApp存储阵列上，应当在iGroup中启用ALUA机制，以实现更为动态或类似于即插即用的SAN架构，而Round Robin路径选择策略（PSP）提供了存储路径的冗余和带宽聚合。对于iSCSI连接，vSphere为多路径在ESXi主机级别引入了对多TCP对话的支持。您可以拥有两个VMKernel端口，并使用Round Robin路径选择策略（PSP）实现即插即用的多路径。这样能提供多个活动路径，并且不需要在Guest OS中安装任何DSM软件。同样，也可以使用传统的多交换机中继网络设计。表4-3. iGroup属性与PSP（Path Selection Plug-In）的对应关系Data ONTAP模式igroup类型与设置存储协议存储负载均衡策略7-ModeVMwareiSCSI（MPIO）Fixed7-ModeVMware（with ALUA）FCRound RobinClutered ONTAPVMware（with ALUA）iSCSI（MPIO）Round RobinClutered ONTAPVMware（with ALUA）FC（MPIO）Round RobinNetApp利用vSphere可插拔存储体系结构（PSA），可提供相对于ESXi本机多路径功能插件（NMP）的性能和负载均衡优势。在Data ONTAP 7-Mode中，若使用iSCSI协议进行连接，推荐PSP采用Fixed模式，而FC协议推荐采用Round Robin模式。在Clustered ONTAP中，若使用iSCSI或FC协议进行连接，推荐PSP采用Round Robin模式。4.2.4 NetApp存储的Aggregate设计原则出于对数据的安全性考虑，将采用RAID-DP来构成Aggregate，RAID-DP与RAID-4相比有如下优势：n RAID-DP比RAID-4小得多的数据丢失风险：随着磁盘密度的增加，1TB SATA磁盘的损坏概率和损坏后的重构时间也大大延长（1TB SATA磁盘重构约5小时左右）。n 如果在第一块磁盘发生故障后的重构时间内，其它磁盘再次发生故障，若采用RAID-4的磁盘组将会发生数据丢失。n 根据统计，采用RAID-DP时丢失数据的概率比RAID-4丢失数据的风险约小12个数量级。n 性能与RAID-4相比仅损失2%以内，可用空间减少在10%以内（按照每个RAID组包含12块磁盘计算）。本次采购的NETAPP 存储采用双控制器，每个控制器分别拥有自己的Aggregate，考虑到用户以前的使用习惯，将所有生产数据集中到一个控制器，作为Active 控制器，另一个控制器只保留基本的Data ONTAP操作系统卷，作为Standby控制器。图4-4 NETAPP 存储控制器管理n 在Active控制器中，创建1个Aggregate，用于存储连接ESXi的LUN设备文件。n 在Active控制器中，考虑到扩容以16块磁盘为倍数比较经济，而且16块磁盘是SAS磁盘的默认RAID Group Size（缺省为16），可在性能和数据安全性方面得到良好的平衡，因此Aggregate的RAID Group Size采用默认的16，创建Aggregate时磁盘总数尽量接近16的倍数。n 在Active控制器中，考虑性能和容量满足的前提下，设置尽可能多的热备份盘（本次设置4块热备份盘），以备将来根据各Aggregate的需求来使用热备份盘扩容。n 在Standby控制器中为了节省空间，只使用最少3块磁盘创建1个Root Aggregate，并仅仅用于存放Data ONTAP操作系统的Root Volume（根卷）。n 在Standby控制器中为了节省空间，只预留1块Hot-Spare Disk（热备磁盘）。4.2.5 NetApp存储的Volume设计原则在NetApp的最佳实践里，我们推荐LUN所在的FlexVol的尺寸是LUN的2倍大小，这其实是与Volume的Fractional Reserve机制有着密切关系，这完全是出于NetApp快照空间预留和LUN Overwrite而考虑的。图4-5. NetApp推荐的LUN所在的Volume容量布局NetApp建议在部署Thin Provisioning模式的LUN的同时，也对LUN所在的FlexVol启用重复数据删除功能，并将这些LUN以1对1的方式（一个FlexVol内只包含一个LUN）部署到同样采用Thin Provision配置、且容量为LUN大小的2.2倍的FlexVol中。通过以这种方式部署LUN，FlexVol将仅仅充当一个配额（Quota）的作用，而LUN所实际占用的存储量会在FlexVol卷和包含它的Aggregate中所呈现。因此，我们推荐在NetApp存储环境中，LUN所在的Volume尺寸也不要太大，Volume的尺寸一般配置为LUN尺寸的2.2倍大小即可。若您考虑使用2TB的LUN，那么我们则推荐LUN所在的FlexVol尺寸为4TB即可，并且FlexVol也配置为Thin Provision模式即可。4.2.6 各应用程序类型对存储I/O需求的通用参考在设计存储解决方案阶段，了解放置在共享存储上的虚拟机I/O需求是至关重要的，I/O配置文件是应用程序和服务器I/O模式的描述。某些应用程序可能是侧重于读取操作，而有些应用程序可能是侧重于写入操作，并且每种应用程序有着不同的顺序或随机读取比例。下列表格中所描述的不同应用程序对应的I/O大小、读写比例、随机和顺序比例。表格中的比例为一个通用的参考值，比例接近真实各种应用的I/O类型。但不能包含全部的应用类型，因为根据不同生产环境，数值也会有很大的差异，这里的数据仅作为参考。表4-4 . 存储I/O需求的通用参考应用类型I/O大小读写比例随机与顺序读写比例Web Server4KB、8KB、64KB95%读取 / 5%写入75%随机 / 25%顺序Web Server Log8KB100%写入100%顺序OS Paging64KB90%读取 / 10%写入100%顺序Exchange Server4KB67%读取 / 33%写入100%随机Workstation8KB80%读取 / 20%写入80%随机 / 20%顺序Media Streaming64KB98%读取 / 2%写入100%顺序OLTP Data8KB70%读取 / 30%写入100%随机OLTP Log512bytes 64KB100%写入100%顺序根据客户所提供的历史性能信息，评估出Application Server类型的虚拟机需要大约175个IOPS。表4-5 . 不同应用类型的虚拟机IOPS需求虚拟机类型%Read%Write平均IOPSRAID写入惩罚I/O配置文件Application Server（Oracle WebLogic）60%40%175 IOPS2 IOPS245 IOPSOLTP（Oracle Database）70%30%1200 IOPS2 IOPS1560 IOPS我们假设每台Application Server类型的虚拟机潜在的平均I/O需求以175个IOPS来计算。根据客户所提供的Read/Write比率分析，Application Server类型的虚拟机通常是60%的读取操作，40%的写入操作。表 4-6. 各种RAID类型的写入惩罚值RAID类型RAID写惩罚RAID-01RAID-12RAID-54RAID-66RAID-DP（NetApp专用）2RAID-102当使用RAID-DP时，这将导致每台虚拟机产生如下的IOPS需求，考虑到RAID-DP的RAID惩罚，由于每次写入操作，会导致奇偶校验必须被写入到两个校验磁盘中，因此惩罚值为2。表4-7. IOPS需求计算公式IOPS需求计算公式：IOPS Requirements Pre VM =（Total IOPS%Read）+（Total IOPS%Write）RAID Penalty）虚拟机类型IOPS需求：Application Server（Oracle WebLogic）（17560%）+（17540%）2）（105）+（70）2）105 + 140 = 245（约等于245个IOPS）OLTP（Oracle Database）（120060%）+（120040%）2）（840）+（360）2）840 + 720 = 1560（约等于1560个IOPS）通过计算得出的结论是，若我们假设定义单台Application Server类型的虚拟机需要175个IOPS的话，在存储上实际需要产生约245个IOPS才能满足该虚拟机的I/O需求，而OLTP 类型的虚拟机若需要1200个IOPS的话，在存储上实际需要产生约1560个IOPS才能满足该虚拟机的I/O需求。从性能的角度而言，该配置文件的计算方式和结果将与NetApp顾问进行了深入讨论，确定出一个最优的策略。4.2.7 Datastore的容量需求估算：下列表格提供了所观察到的被候选为虚拟化的物理主机所实际消耗的存储容量信息。表 4-3. 虚拟机存储容量配置文件AVG C: SIZE（GB）AVG C: USED（GB）AVG “OTHER”: SIZE（GB）AVG “OTHER”: USED（GB）40GB9.36GB100GB40.74GB在这种情况下，平均每台Application Server类型的虚拟机的存储容量需求大约为50GB左右（C盘驱或“/”分区平均使用率约为9.36GB，而其它盘驱通常使用率约为40.74GB）。我们假设每台虚拟机平均需要50GB的存储容量，并且虚拟机配置为8GB Memory的情况下，在这种情况下您可以通过计算的虚拟机实际所需磁盘空间消耗，估算出每个Datastore所能容纳的虚拟机数量（虚拟内存占用vSWAP 空间容量后面有阐述）。之前我们已经定义过每个Datastore的Size为2TB，这就意味着约等于2048GB，计算公式如下：LUN容纳虚拟机数量计算公式：LUN Size 每台虚拟机实际所需磁盘空间消耗 = 每个 Datastore 所能够容纳的虚拟机数量2048GB 50GB 404.2.8 Datastore的IOPS需求估算：考虑到每个Datastore最多提供40台虚拟机的运行，这需要每个Datastore必须能够提供至少9800个IOPS，计算公式如下：表 4-9. DataStore 的IOPS 每LUN所需的IOPS计算公式：每个 Datastore 所能够容纳的虚拟机数量每个台虚拟机实际IOPS消耗 = 每个 Datastore 所需的IOPS数量35台245 IOPS =9800 IOPS根据估算，一块15K RPM的磁盘可以具有175 IOPS，而一块10K RPM的磁盘大约能具有125 IOPS。出于性能和安全性的考虑，NetApp对SAS磁盘的RAID Group Size默认定义为16块磁盘，DataStore需要 SAS磁盘数量才可满足IOPS需求，计算公式如下：9800IOPS 125 IOPS 79块10K RPM的SAS磁盘因此，建议每台NetApp存储控制器将配置具有512GB的Flash Cache缓存模块（PAM II），从而减轻磁盘的读取任务I/O压力，并提高读取响应时间，以满足vSphere环境中的磁盘I/O需求。 4.2.9 存储设计要点创建虚拟机时，在Datastore中所自动创建出的目录被称为“虚拟机主目录”。默认情况下，虚拟机的所有组成文件都放置于虚拟机主目录内。主目录包括虚拟机的配置文件，虚拟磁盘和虚拟描述符文件，以及VMKernel交换文件，快照文件，NVREM等等。每当虚拟机一旦被启动时，就会通过VMKernel自动创建出每台虚拟机所需的vSWAP文件。默认情况下，vSWAP文件的大小是等同于每台虚拟机所配置的虚拟内存大小。由于vSWAP是用于存放临时性内存交互数据的，无论是从备份副本恢复虚拟机，还是使用的Site Recovery Manager进行灾难恢复，NetApp都推荐将每台虚拟机的vSWAP文件从虚拟机的主目录中重新定向到一个单独的Datastore上。因此，我们推荐所有虚拟机的vSWAP文件应统一放置在一个单独的共享Datastore上。图4-6. NetApp推荐的虚拟机vSWAP文件布局如图所示出，这种虚拟机的文件布局图。其先决条件是在NetApp存储上创建一个专门用于存放虚拟机vSWAP文件的Datastoe。因为VMware的vSWAP文件对于存储的需求是动态的，所以NetApp的建议是创建一个自动精简配置的LUN或启用了卷自动增长功能的FlexVol。当用于存放vSWAP文件时，自动精简配置的LUN和自动增长的FlexVol卷，提供了非常高的性价比。这种设计避免了经常需要对vSWAP存储空间的变化调整，并且减少了存储的使用率。如果您的交换空间过小，虚拟机将会无法启动。相反，如果交换空间过大，将会导致存储空间的浪费。整个vSphere Cluster将使用一个单独的Datastore用于存储所有虚拟机的vSWAP文件。 NetApp并没有建议将每台ESXi主机的Local Datastore作为虚拟机vSWAP的存储空间，因为这种配置方式可能会给虚拟机的vMotion带来的负面影响，例如导致迁移时间过长等问题。在屏幕的右侧的数字描绘了简单的VMKernel交换vCenter Server中配置一个中央数据存储，虚拟机的vSWAP文件都被指定放置到一个单独的共享存储上，但是与虚拟机的主目录是分离的。这样的优势是能够增加虚拟机的vMotion速度、增强虚拟机的备份速度，因为SWAP文件不会被备份，由此也能带来节省备份成本的优势。表4-10. 关于vSWAP文件布局方式的对比优/略势Non-DedicatedDedicatedLocal优势：可提高vMotion速度。可提高vMotion速度。可减少存储复制带宽需求。可减少存储复制带宽需求。略势：增加存储复制带宽需求。可能会增加额外的管理成本。增加存储复制带宽需求。可能会增加额外的管理成本。通过对比，最终我们还是推荐农银人寿考虑单独划分出一个专属（Dedicated）用于存放虚拟机vSWAP文件的Datastore，以提高虚拟机的vMotion速度，并降低存储在执行容灾复制过程中对网络带宽的需求。4.3 虚拟化存储设计 随着业务和公司发展的不断壮大，应用系统等不断增加，对存储的需求成指数上升。根据预测，未来两年对存储的需求增长为每年41%。同时，存储面临多重挑战：首当其冲的就是如何在满足不断激增的应用和存储需求的同时，满足客户的SLA。其后，是故障排除和数据迁移过于复杂。如何在更少的时间应用更少的成本满足业务部门的SLA需要，在不失策略控制的前提下，简化、自动化管理流程，成为企业IT部门在存储领域的关切点。以前，存储都是在项目开始阶段配置和部署的，在其生命周期中不再更改。如果要求更改虚拟机所利用的 LUN 或卷的某些方面或功能，则在许多情况下，需要删除原始 LUN 或卷并创建具有所需功能的新卷。这是 一项干扰性很强且非常耗时的操作，可能需要花费数周的时间进行协调。 图：存储压力来源4.3.1 存储面临挑战第一个挑战是管理复杂、不灵活