本帖最后由 史东杰 于 2014-7-19 16:57 编辑
一、 现状分析1.1 环境现状随着XX公司信息化建设的不断深入，促使信息系统的激增；信息系统在不同时期的建设导致了服务器烟囱式的增长、品牌型号各异，从而促使整个IT维护成本的增加。为满足业务系统发展的需求，能够快速、灵活的部署同时提高业务连续性，要求未来业务系统的部署能够根据实际业务量大小对运行该应用的虚拟机资源进行在线动态调整与增加，以提高未来快速部署应用系统的效率及实现基础架构平台的高效管理维护，同时提高X86服务器平台的高可用性、降低应用业务系统的整体建设成本，并逐步探索和积累云计算基础架构平台的运营管理经验。 传统服务器与应用一对一的部署方式对资源的有效利用及系统的管理维护带来了很多难以解决的问题，包括： 1、扩展性 因为每台服务器存储都为本地直连，这就造成了所有的计算资源（CPU，内存），网络资源和存储资源在虚拟化环境中无法进行转移和调配，从而形成了本地的资源“孤岛”，而无法通过有效的手段在线扩展。 本地存储的扩展能力有限，随着应用数据对于数据量以及I/O性能要求逐渐增加，本地磁盘会逐渐受限于缓存大小，磁盘转速，磁盘数量，容量等扩展能力的限制将无法持续满足需求。 2、可用性 因为当前环境下每个服务器都是单机运行，没有共享存储环境因此未配置为集群环境，系统维护和升级或者扩容时候需要停机进行，造成应用中断。 没有集群的高可用环境支持，每个服务器的故障（人为或者意外）会造成其上运行的应用停顿，并且在其他服务器上运行的与此服务器上的应用具有相互依存关系的应用也会受到影响，造成可用性整体下降。 通过本地RAID卡构建的本地存储的可用性差，本地存储通常没有配置热备盘，而且构建RAID的类型有限。 3、灵活性差 由于没有统一计算、网络和存储资源，这就造成了应用无法统一有效的快速部署。例如：在彼此分割的环境下，无法将某台服务器下多余的存储资源、计算资源分配给其他服务器使用。 对于某台服务器的维护和升级等操作，都会造成计划内应用的停机；无法在线迁移在其上运行的应用到其他服务器上。 4、成本高 目前因为需要在线的服务器数量较多，服务器的数量多意味着更多的空间占用，机柜占用，网络交换，网线，耗电，UPS布局以及冷却系统的布局和能耗。 管理成本相对较高，因为服务器数量多意味着对现有系统的升级、改造所需要的管理成本增加；此外一对一的应用部署模式，也意味着对于新设备的上线都需要重新规划网络、服务器等硬件设施，不但需要的考虑的管理成本的增加，交付时间的迟延，当然也要考虑到每个应用对业务应用上线需要重新服务器部署所造成了空间，硬件，耗能和冷却系统成本上的增加。 5、应用兼容性问题 现有环境存在多个应用部署在一个物理服务器上的情况，然而不具有虚拟化抽象层隔离特性的操作系统之上运行的多个应用，该操作系统如进行升级更新或者出现故障时将同时影响多个应用生产；并且当某个应用造成操作系统稳定性等问题也会影响在同一平台的其他应用。 在一个物理服务器上部署的应用，由于服务器物理硬件异构也无法连同底层系统直接迁移到其他物理服务器上，必须通过备份软件或者应用或第三方的迁移工具。 传统的IT系统难以解决上述问题，而在新的基于VMware虚拟化基础平台的系统部署规划中，能够解决上述这5个问题并带来以下收益： 在一个构建了弹性资源池的VMware虚拟架构中，用户可以把资源看成是专属于他们的，而管理员则可在企业范围内管理和优化整个资源。VMware的虚拟架构可以通过增加效率、灵活性和响应能力来降低企业的IT花费。管理一个虚拟架构可以让IT部门更快的连接和管理资源，以满足商业所需。虚拟架构可以让IT部门达成以下目标： 实现35%-75% TCO的节省：通过将整合多个物理服务器到一个物理服务器降低40％软件硬件成本；整合比：生产环境10-15 : 1，开发测试环境15-20 : 1；每个服务器的平均利用率从5％-15%提高到60%-80%；降低70-80%运营成本， 包括数据中心空间、机柜、网线，耗电量，冷气空调和人力成本。 提高运营效率：部署时间从小时级到分钟级， 服务器重建和应用加载时间从 20-40 hrs =>15-30min， 每年节省10,000 人/小时（300台服务器）；以前硬件维护需要之前的数天/周的变更管理准备和1 - 3小时维护窗口，现在可以进行零宕机硬件维护和升级。 提高服务水平：帮助企业建立业务和IT资源之间的关系，使IT和业务优先级对应；将所有服务器作为大的资源统一进行管理，并按需自动进行动态资源调配；无中断的按需扩容。 旧硬件和操作系统的投资保护：不再担心旧系统的兼容性，维护和升级等一系列问题。
1.2 需求分析1.2.1 应用环境基础构架分析XX公司数据中心的虚拟化系统平台构建将分为两个部份进行。 第一部份在新的IT架构建设中构建一个虚拟化的基础平台，实现服务器整合，提高业务连续性以及资源的动态扩展等功能。 第二部份主要是构建核心业务的灾备环境，构建一个两地三中心的灾备环境，在主站点出现故障后能瞬间切换到灾备站点，满足业务系统快速上线与降低信息系统基础架构管理复杂性的要求。 现有业务系统下表所示：(服务器总计20多台)： 本阶段虚拟化环境实现目标： 针对XX公司现有业务系统，本阶段完成基本的虚拟化基础平台架构建设，完成服务器整合，提高业务系统连续性；为关键业务系统实现应用级别的灾备环境，同时为未来业务的不断增加提供可自动在线弹性扩展的虚拟化资源池系统。 本阶段构建虚拟化环境的基本要求如下： l 考虑到构建集中式的虚拟机高可用集群环境，需要配置足够的冗余交换网络：这包括管理和VMwarevmkernel网络及集群心跳网络，在线迁移网络以及虚拟机应用对外连接的服务网络。 l 通过vMotion功能实现在线地迁移正在运行的虚拟机应用到不同的物理服务器。 l 通过storagevMotion功能实现在线的迁移正在运行的虚拟机应用到不同的物理存储位置。 l 对整个数据中心的应用资源构建资源池分配，确保平台运行各应用尤其是核心应用的计算资源和IO资源得到有效的保障。 l 对整体数据中心虚拟化集群环境实现通过DRS功能进行动态的资源池动态负载均衡的计算资源在线自动管理，以及数据中心基础架构的弹性扩展。 l 实现虚拟机动态负载均衡的高可用环境（VMwareDRS HA） l 通过创建与主实例保持虚拟同步的虚拟机实时影子实例，使应用在服务器发生故障的情况下也能够持续可用。 通过在发生硬件故障时在两个实例之间进行即时故障切换，FT完全消除了数据丢失或中断的风险。(vSphere Fault Tolerance(FT)) l 集中式虚拟机整合备份 （VMwarevStorage API） l 通过将防病毒功能卸载到经过强化的安全虚拟机，使这项功能不占用虚拟机空间，从而提高防病毒扫描性能。(vShieldEndpoint) l 使用内置的 vSphereReplication，可以消除第三方复制成本，并制定更灵活的灾难恢复计划。(vSphereReplication) l 虚拟机集群环境的集中统一管理和监控(vCenter ) l 通过虚拟化环境延长软硬件的生存周期，确保降低总体拥有成本TCO，提高投资回报率。 l 为了实现数据的集中存储、集中备份以及充分利用VMware虚拟架构中虚拟机可动态在线从一台物理ESXi服务器迁移到另一台物理ESXi服务器上和高可用等特性；建议数据中心整体构建在基于的IPSAN或FCSAN的存储网络，配置相应的IPSAN/FCSAN存储阵列，同时配置冗余的交换机及为台ESXi物理服务器配置冗余的SAN主机适配卡，将由VMware虚拟架构套件生产出来的虚拟机的封装文件都存放在IPSAN/FCSAN存储阵列上。这样通过共享的存储架构，可以最大化的发挥虚拟架构的整体优势。 l 借助属于 vCNS，保护虚拟数据中心内的应用程序免受网络威胁的侵扰。深入了解网络通信，并针对安全组实施细化的策略。这款解决方案经济高效，在安全性方面优于物理解决方案，消除了硬件和策略数量剧增的情况。 —可增强对虚拟机间网络通信的了解和控制 —无需再使用专用的硬件和 VLAN 来隔离不同的安全组 —优化硬件资源利用率，同时保持可靠的安全性 —可全面地将所有虚拟机网络活动记入日志，从而简化合规性工作 为达到本阶段虚拟化系统平台建设的要求，需要配置VMwarevSphere企业版或企业增强版软件许可，vCenter标准版，配合vCNS实现虚拟化环境下的病毒防护和虚拟主机以及虚拟机级别的防火墙。 1.2.2 虚拟化环境构建准备 针对以上两个阶段的要求，我们针对XX公司数据中心规划了新的虚拟化基础架构作为x86运行环境的主要支撑： l 将数据中心的计算、网络、存储基础架构环境进行整合，构建为集中自治控管的虚拟化结构 l 整合现有数据中心x86平台物理主机Windows系统，共计多个应用到各自的虚拟化支撑环境中。 l 确保整合后的虚拟机环境具备和物理机实际使用环境相当的运算能力，性能，并具有更好的扩展能力。 l 虚拟化环境应该具有高可用功能，应对计划外的停机，确保整合后应用的业务连续性。 l 虚拟化环境具备足够灵活性，可以根据需要：如主机维护和升级需要或者满足某个关键应用的性能需要，在不同的ESX服务器中在线的迁移虚拟机环境，以满足服务质量的要求。 l 虚拟化环境中形成计算资源和网络、存储IO资源的标准化虚拟化资源抽象，以资源池的方式灵活敏捷部署。 l 整体虚拟化环境依据为vmware虚拟化环境架构最佳实践原则。 本阶段虚拟化平台建设的具体软硬件要求及逻辑拓扑图如下：
系统连接图及应用高可用性
l 为了实现VMware虚拟架构针对XX公司应用特性所需要的功能，考虑到可靠性的需要，建议采用IBMX3850/IBM X3850/ IBM X3650/ IBM X3650/ IBM X3650做为虚拟化的生产中心，部署VMware服务器虚拟化套件。 l 每台服务器建议配置两块HBA光纤通道卡用于实现SAN存储网络的冗余和多路径功能。为测试SAN存储光纤网络的多路径功能，需要光纤交换机的支持。 l 根据需要，配置一到两台千兆以太网络交换机用于虚拟化平台的管理及应用网络。 l 整个虚拟架构需要一台独立的管理服务器（可配置一台单独的虚拟机）以配置相应的管理软件，用于测试统一管理。 推荐硬件平台配置： l CPU：Intel二路或四路多核处理器，单核主频2.0GHz或以上。 l 内存：96~128GB l 硬盘：2*146 SASDisks l 网卡：主板集成双千兆端口的基础上外插3~4块双端口千兆或万兆以太网卡 l HBA卡：两块HBA卡 l 存储：光纤磁盘阵列，按照应用虚拟机的容量要求配置磁盘数。 l 存储交换机：2台光纤交换机 l 网络交换机：千兆交换机2台以实现网络冗余 推荐软件配置： l vSphere5.1企业版（按照物理CPU插槽数计算License，如果配置3台2路服务器、1台4路服务器作为虚拟化平台载体，即配置3*2+1*4=10个CPULicense） l VMware vCenter5.1标准版(含Converter迁移软件，按照安装实例计算License，在本项目中只需要安装1个vCenter实例，也即1个vCenterLicense，1个vCenter可最大支持管理1000个vSphere虚拟平台宿主机)
1.2.3 方案总体拓扑及虚拟机VLAN网络介绍
XX公司数据中心虚拟化平台配置: 1个专用的vCenter 实例 1个应用生产集群 1个专有的集群连接光纤存储阵列 XX公司数据中心 VMware 虚拟基础架构项目，第一期整合约20个以上业务应用到虚拟架构中。 1.2.4 方案说明 此虚拟架构环境搭建是将vSphere套件安装在多台IBM X3850和IBM X3650(要求一个群集需要CPU兼容)的服务器上，组建成一个群集，将多个业务系统部署在ESXi主机中对外提供业务访问，虚机和业务系统数据均存储在共享存储上，考虑到关键业务系统，在没有通过SRM构建出两地三中心应用的容灾环境下，建议将业务系统分为三层架构，即有虚拟机来承担业务系统前端和中间件，现运行的数据库不做整合。(vSphere安装配置详见VMware文档中心：http://pubs.vmware.com/vsphere-51/index.jsp?lang=zh_CN) 业务全新部署过程中，需要在物理主机上安装vSphere 虚拟化套件，通过Hypervisor 将多台物理服务器硬件构成一个资源池，在资源池的基础上按需部署虚拟机 (Windows\Linux\SCO Unix 等) 用于业务系统部署(在资源池的基础上所有业务系统共享虚拟主机资源，同时可以随时灵活调整各虚拟机所需要的资源,如：CPU、内存以及对存储网络访问的优先级等)，考虑到业务系统的优先级可以通过不同级别或虚拟机本身的预留和限制来保障不同业务系统对资源的需求。同时，部署在群集中的业务系统会根据物理服务器的负载情况，自动在群集内迁移(DRS 自动判断，DRS策略设置想将VMware相关文档：http://pubs.vmware.com/vsphere-51/index.jsp?lang=zh_CN) 以满足业务系统对资源的需求。 云计算基础架构业务连续性保障： 在VMware对业务连续性的保障机制中，针对虚拟主机VMware有HA机制，群集中的任何一台物理服务器发生故障，该物理主机上的所有业务系统将被群集中任何一台可用物理主机接管。
针对虚拟机的保护，特别是关键业务系统，VMware设计了容错(FT)机制来保证数据零丢失。 vSphere Fault Tolerance (FT) 通过创建与主实例保持虚拟同步的虚拟机实时影子实例，使应用在服务器发生故障的情况下也能够持续可用。 通过在发生硬件故障时在两个实例之间进行即时故障切换，FT 完全消除了数据丢失或中断的风险。
- 在受保护的虚拟机响应失败时自动触发无缝的有状态故障切换，从而实现零停机、零数据丢失的持续可用性
- 在故障切换后自动触发新辅助虚拟机的创建工作，以确保应用受到持续保护
不论使用何种操作系统或底层硬件，均可为应用提供保护 ： 可以保护所有虚拟机，包括自主开发的应用，以及无法用传统的高可用性产品来保护的自定义应用。
- 与所有类型的共享存储都兼容，包括光纤通道、iSCSI、FCoE 和 NAS
- 与 VMware vSphere 支持的所有操作系统兼容
- 可与现有的 vSphere DRS 和 High Availability (HA)集群协同工作，从而实现高级负载平衡和经优化的初始虚拟机放置
- 特定于 FT 的版本控制机制，允许主虚拟机和辅助虚拟机在具有不同但兼容的补丁程序级别的 FT 兼容主机上运行
易于设置，可按虚拟机启用和禁用 ：
由于它利用了现有的 vSphere HA 集群，因此可以使用 FT 保护集群中任意数量的虚拟机。 对于要求在某些关键时段（例如季末处理）获得持续保护的应用，可以利用 FT 更加有效地保证它们在这些时段可用。
- 只需在 vSphere Web Client 中轻松执行点击操作，即可启用或禁用 FT，使管理员能够根据需要使用其功能
云计算基础架构下灵活的灾难恢复机制(vSphereReplication)： vSphere Replication 是深度集成在 vSphere 平台中的组件，也是当今市场上唯一一款真正的“虚拟化管理程序级”复制引擎。 在主站点上，正在运行的虚拟机所用的虚拟机磁盘中如果有数据块发生了变更，这些数据块将发送到辅助站点，并在该处应用于虚拟机磁盘，以制作虚拟机的离线 （保护）副本。
图 1 - 复制虚拟机中发生变更的数据块 vSphere Replication 由每个主机上包含在核心 vSphere 5 安装包中的一个代理和从管理界面部署的一组虚拟设备构成。 就概念而言，代理负责从正在运行的虚拟机发送变更的数据，设备则负责在远程站点接收复制内容，并将其应用于虚拟机的脱机磁盘文件。 vSphere Replication 设备还负责管理复制，得益于此，管理员可以了解虚拟机的保护状态并且通过几次简单的单击操作即可恢复虚拟机。 所有 vCenter 操作都通过同一个管理界面完成，使用该界面可以非常轻松地为最多 500 个虚拟机配置复制：只需右键单击某个虚拟机，并为其副本选择目标位置即可。 此过程中有一步是选择“恢复点目标”，此步骤将告知 vSphere Replication 可以获取多久以前的虚拟机副本。 然后它将时时尝试复制数据以满足恢复点目标，从而确保您的虚拟机数据不会早于为执行复制而配置的每个虚拟机所定义的策略。
图 2 - 为多个虚拟机选择一个恢复点目标 vSphere Replication 将会对源虚拟机及其副本执行一次初始完全同步；如果需要，可以在目标位置放置数据的种子副本，以减少初始复制所需的时间和带宽。 虚拟机的种子副本中包含一个虚拟机磁盘文件，您可以通过任何途径将该文件放置到目标位置。 放置种子并不是一个必需的过程，无论目标位置是否有种子，vSphere Replication 都会创建一个初始副本。 如果用户获得了一个用于复制的种子，即可使用其中的数据来减少初始同步主磁盘及其副本所需的复制量。 种子可以手动创建，也可以通过管理员选择的任何途径复制到相应位置，如采用脱机复制、FTP、“人工传输网络”，甚至使用 ISO 或虚拟机的克隆。 在完成基准同步之后，vSphere Replication 将切换为仅传输已变更的数据块。 vSphere 内核会亲自追踪对受保护虚拟机的磁盘文件执行的唯一性写入操作，并在所配置的恢复点目标期间仅识别和复制执行了唯一性写入操作的那些数据块。 这可确保通过网络向目标发送最少量的数据，并实现更高的恢复点目标。 在发送唯一性数据之后，无需再次发送。 系统仅复制发生变更的数据，这些数据块将发送到目标位置的 vSphere Replication 设备中。
图 3 - 从 vSphere 代理到 VR 设备的复制数据流 在目标位置，vSphere Replication 设备将接收并检查所发送的数据：只有完全一致的数据才会（通过 Network File Copy）写入到目标集群的 vSphere 主机，进而写入磁盘。 等待完全一致的数据块组这一方式可确保副本虚拟机随时可以恢复，即使数据在传送过程中丢失或者在传输过程中的任何时候发生崩溃也无妨。 从受保护的虚拟机的角度看，整个过程是完全透明的，不需要对配置或日常管理进行任何更改。 这种复制方式采用的是非侵入形式，与虚拟机中的操作系统无关。 (vSphere各组件模块功能详见：
vSphere各组件功能如下表所示： | 技术特性 | | | | | | | | | | | | | | | 确保在一个负载均衡/故障转移组内的不同虚拟机不会运行在同一个物理机上，保证虚拟机应用机群的运行可靠性。也用于保证某些虚拟机应用运行于特定的服务器上 | | | 确保多台物理机能够同时访问一个LUN并保证数据完整性和一致性 | | 将虚拟化数据中心服务器集群中的各服务器的CPU和内存等资源整体定义成一个“资源池”，实现资源整合和动态分配 | DRS（Distributed Resource Scheduler）集群能够根据所运行虚拟机的负载轻重，自动在集群的资源池内动态分配部署，实现负载均衡 | 资源的动态调配是企业数据中心虚拟化应用的最重要特性，保证了系统的弹性和资源利用 | | | 确保虚拟机的计算和内存等资源能够随需增加而不中断业务 | 内存优化功能，支持透明页映射和内存超用(OverCommit) | | “OverCommit”内存共享技术，就是把负载小的虚拟机的内存挤出来，给需要内存多的虚拟机使用。同等的资源下能支持整合更多的虚拟机业务 | | | 通过vCenter提供统一的图形界面管理软件以在单一客户端完成所有虚拟机的日常管理工作，包括各虚拟机控制管理、CPU内存管理、用户管理、存储管理、网络管理、日志收集、性能分析、故障诊断、权限管理、在线维护等 | 单一客户端在简化了虚拟化数据中心可管理性的同时，减少了人为失误 | | | 开放式虚拟机格式使得用户可以在现有虚拟机和其它的虚拟化产品和组织之间兼容， | | | 考虑到虚拟机的动态可迁移，实现对应业务及相关数据的访问控制，控制病毒和其它网络攻击，是建设虚拟数据中必须考虑的 |
虚拟机内部网络结构及VLAN配置说明
配置虚拟化环境下的VLAN比在一个物理网络中建立VLAN相对复杂，因此需要采用不同的方法——802.1QVLAN标签。 在一个物理网络中，服务器本身都具备连接到物理交换机端口的物理Network Interface Cards (NICs)。因此，VLAN通常是通过在物理交换机端口上设置VLAN ID进行控制，然后设置与这个NIC的VLAN相对应的服务器的IP地址。但在虚拟环境中，将一个物理NIC (pNIC)指定给宿主上的每一个VM则是无效的。事实上，一台宿主的物理NIC可以为很多需要连接到不同VLAN上的VM提供服务。因此，在物理交换机端口上设置VALN ID的老方法是行不通的。这就是引进802.1Q VLAN标签的原因所在。 在阐述什么是802.1Q VLAN标签之前，先探讨一下网络在虚拟环境中运行的基本条件。一台ESX/ESXi主机一般具备多个物理网络适配器以支持冗余、负载均衡和隔离。物理NIC (pNIC)是连接到各个物理交换机的，并且分配给每台主机上创建的虚拟交换机（vSwitch）。pNIC到vSwitch的连接被称为上行连接。接着在vSwitches上创建端口组，它们是与分配到宿主上的每台VM的虚拟NIC相连接的。虚拟机可以使用连接到vSwitch上的任意pNIC。vSwitch负载均衡策略定义了在路由流量通过VM时如何选择pNIC。 如下图所示：
由于这个架构特点，将一个VLAN ID 分配给一个物理端口的传统VLAN方法在虚拟环境中运行效果并不是很好。通过这种方法，一个vSwitch上所有的VM都必须使用相同的VLAN ID，这在大多数情况下是不合适的。虽然您可以为每个VLAN创建多vSwitch，但是如果您已经有了很多VLAN，那么您必须配备大量的pNIC。这就是802.1QVLAN标签为何重要的关键所在了。 802.1Q VLAN标签允许在一个物理交换机端口上使用多个VLAN。这种功能能够显著地减少主机上所需要的pNIC的数量。您可以使用一个NIC连接多个VLAN，而非为宿主每一个您需要连接的VLAN分别提供一个pNIC。这种标签的方法是通过为所有网络帧设置标签来确定它们属于一个指定的VLAN。根据所使用的标签方法，标签会在某个位置删除。 虽然为vSphere VLAN添加标签的方法有好几种，但是这些方法是根据标签应用的位置而有所不同的。Virtual Machine Guest Tagging (VGT)模式在宿客操作系统层实现，External Switch Tagging (EST)模式在外部物理交换机上实现，而Virtual Switch Tagging (VST)模式则是在VMkernel内部实现。 以下列出了各种VLAN标签模式的区别： Virtual Machine GuestTagging (VGT mode)——在这个模式下，802.1Q VLAN中继驱动器安装在虚拟机的内部。当帧通过虚拟交换机时，标签会被保存在虚拟机网络栈和外部交换机之间。 External Switch Tagging(EST mode)——在这个模式下，您可以使用外部交换机进行VLAN标签。这类似于物理网络，而且通常VLAN配置对于每台物理服务器都是透明的。当一个数据包到达交换端口时就会被打上标签，而当数据包离开交换端口传输到服务器时标签就会被去除。 Virtual Switch Tagging(VST mode)——在这个模式下，您可以在虚拟交换机上为每个VLAN配置端口组，同时将虚拟机器的vNIC连接到恰当的端口组。虚拟交换机端口会为所有外发的帧打上标签，而为到达的帧去除标签。它同时确保VLAN上的帧不会泄漏到其它的VLAN上。 在vSphere 中，VST模式是VLAN中最常使用的一种，因为它更容易配置和管理。它同时并不需要在虚拟机中安装特定VLAN驱动，而且在虚拟交换机中打标签是没有任何性能影响。
二、 虚拟化软硬件推荐配置2.1 VMwarevSphere产品构成VMware vSphere 5.1产品套件，包括ESX iSever与vCenter Server两部分。vCenter Server是中心管理端，需要单独购买，一套VC可以管理1000个物理主机、10000个虚拟机，因此一套数据中心通常只需要购买一套vCenterServer。
2.3 软件配置推荐根据上述分析以及VMware vSphere软件版本组成，我们推荐XX公司选择企业版本，主要考虑以下三点： 企业版本为VMware vSphere虚拟化平台功能较全面的版本，该版本具备了以最全面、最可靠的和最高性能及最易于管理的方式服务于服务级别高的生产应用环境的能力。 目前XX公司的应用环境，有可能需要在虚拟环境中实现4路SMP的物理服务器，因此也需要具备创建这种虚拟机能力的软件版本。出于许可证扩展性的考虑，企业增强版对物理内存支持没有限制，因此，选用这个版本可以在不增加软件费用的情况下可以再一台服务器上集成密度更多的应用。 | 服务器虚拟化软件（必选） | | | 采用裸金属架构，无需绑定操作系统即可搭建虚拟化平台。
每个虚拟机都可以安装操作系统，并且操作系统可以异构。
虚拟化软件可以在线进行版本升级，不同版本之间可以相互兼容。
兼容现有市场上X86服务器上能够运行的主流操作系统，尤其包括以下操作系统：Windows NT、WinXP、windows Vista、Win2000、Win2003、windows 2008、Reahat Linux、Suse linux、Solaris x86、Novell、Trubo linux、FreeBSD、Ubuntu、Debian、Mac OS等等。
每台VM(虚拟机)的vCPU数量可以达到32个vCPU。
每台VM(虚拟机)的内存大小可以达到1TB。
每台VM(虚拟机)可以支持到64TB的存储容量。
提供技术支持服务，如免费的版本升级和专业的售后服务专线支持（800电话）等。 | | | 1年Basic级SnS：产品更新和升级；5x12(8:30am to 8:30pm，周一至周五)电话和邮件支持 | | | | | | | 标准版vCenter管理软件，无管理数量限制；SnS支持服务必配 | | | 1年Basic级SnS：产品更新和升级；5x12(8:30am to 8:30pm，周一至周五)电话和邮件支持 | | | |
本次配置中采用5台物理服务器作为虚拟化主机。 [td] | 硬件名称 | | | | 虚拟化服务器 IBM X3850或3650（利旧）
| l CPU：Intel二/四路多核处理器，单核主频2.0GHz或以上。 l 内存：128GB，刀片配置为96G l 硬盘：2*146 SAS Disks，或者1块16GB以上的SLC SSD磁盘（减少服务器系统发热量，提高系统可靠性） l 网卡：四块千兆或3块万兆网卡 l HBA卡：两块 (如果要考虑使用现有服务器，须确认CPU指令集兼容) | | （此处未考虑通过SRM灾备，同时在服务器选型上建议采用四路服务器） 此处配置4台物理服务器充分考虑了资源的冗余，同时也考虑到的启用FT的要求 | | | |
| | | | | | | | vCenter Server可以使用现有物理服务器，也可使用虚拟机 | | 光纤口:8-Gb 容量：2TB(数据量需要按实际需求扩展) | | SAS盘(考虑到二期灾备环境的构建，建议考虑存储的镜像复制或同步功能) | | | | |
通过资源池可以委派对主机（或群集）资源的控制权，在使用资源池划分群集内的所有资源时，其优势非常明显。可以创建多个资源池作为主机或群集的直接子级，并对它们进行配置。然后便可向其他个人或组织委派对资源池的控制权。 使用资源池具有下列优点: 灵活的层次结构组织 根据需要添加、移除或重组资源池，或者更改资源分配。 资源池之间相互隔离，资源池内部相互共享，系统管理员可向部门级管理员提供一个资源池。某部门资源池内部的资源分配变化不会对其他不相关的资源池造成不公平的影响。 访问控制和委派 系统管理员使资源池可供部门级管理员使用后，该管理员可以在当前的份额、预留和限制设置向该资源池授予的资源范围内进行所有的虚拟机创建和管理操作。委派通常结合权限设置一起执行。 资源与硬件的分离 如果使用的是已启用 DRS 的群集，则所有主机的资源始终会分配给群集。这意味着管理员可以独立于提供资源的实际主机来进行资源管理。如果将三台 2GB 主机替换为两台 3GB 主机，则无需对资源分配进行更改。这一分离实现了聚合计算能力而非单个个主机。 管理运行多层服务的各组虚拟机 为资源池中的多层服务进行虚拟机分组。无需对每个虚拟机进行资源设置，而是可以通过更改该组虚拟机所属资源池的设置来控制对这些虚拟机的总体资源分配。 虚拟化整合平台资源池分配资源的示意图如下：
如图所示，资源池内部是计算资源和内存资源、Datastore提供存储资源、端口组提供网络资源。
三、 总结在XX公司在进行了整体虚拟化环境改造整合架构后，可以整体实现以下优势： 大大降低TCO · 通过服务器整合，控制和减少物理服务器的数量，明显提高每个物理服务器及其CPU的资源利用率， 从而降低硬件成本。 · 降低运营和维护成本， 包括数据中心空间、机柜、网线，耗电量，冷气空调和人力成本等。 提高运营效率 · 加快新服务器和应用的部署，大大降低服务器重建和应用加载时间。 · 主动地提前规划资源增长，这样对客户和应用的需求响应快速，不需要象以前那样，需要长时间的采购流程，然后进行尝试。 · 不需要象以前那样，硬件维护需要数天/周的变更管理准备和1 - 3小时维护窗口，现在可以进行快速的硬件维护和升级。 提高服务水平 · 帮助您的企业建立业务和IT资源之间的关系，使IT和业务优先级对应。 · 整个虚拟化环境集群提供了整体的高可用架构，确保应用的稳定和可靠。 · 将所有服务器作为大的资源统一进行管理，并按需进行资源调配。 旧硬件和操作系统的投资保护 · 不再担心旧系统的兼容性，维护和升级等一系列问题。 为将来的集中网络存储提供可能 · 对于由于成本或者其他原因没有接入到存储网络（SAN, iSCSi和NAS）的服务器，整合后物理服务器数量减少，可以考虑接入到存储网络, 这样充分利用网络存储的优势，将这些分散的数据集中管理备份，为这些服务器和应用的以后的容灾打下基础。同时，通过虚拟机的特有功能和网络存储的有效结合，提高了这些应用的可用性，移动性和灵活性。
| 
发布时间：2014-07-19 浏览：1508 
收藏
赞
