vmware云计算数据中心解决方案建议书v1

vmware云计算数据中心解决方案建议书v1内容摘要：

份认证 系统可使用的总容量为 340G，现已使用了 170G，使用率为 50%。  IBM DS5020 阵列上， 视频服务器 可使用的总容量为 1540G，现已使用了1530G，使用率为 97%； 防病毒系统 可使用的总容量为 270G，现已使用了206G，使用率为 76%。  EMC CX340 阵列 上， 财务 系统可用总容量为 941G，现已使用了 325G，使用率为 32%； 移动站业务管理系统 可用总容量为 800G，现已使用了270G，使用率为 34%； 安全评估 系统可用总容量为 600G，现已使用了305G，使用率为 51%。  EMC CX500 阵列上， 任务管理系统 可用总容量为 120G，现已使用了 95G，使用率为 79%； 固定资产管理系统 可用总容量为 300G，现已使用了 280G，使用率为 94%。  EMC CX4480 阵列上， 下载服务器 可用总容量为 2020G，现已使用 了2020G，使用率为 100%； 生产经营管理系统 可用总容量为 980G，现已使用了 800G，使用率为 82%。 上述 存储设备及其相应系统的容量与使用率情况如下 表 所示。 阵列名称 使用系统 可用空间 已用空间 使用率 IBM DS4700 网管系统 1400G 800G 57% 邮件系统 1950G 900G 67% 人力资源系统 400G 400G 100% IBM FastT600 库存管理系统 1340G 1340G 100% 身份认证系统 340G 170G 50% IBM DS5020 视频服务器 1540G 1530G 97% 防病毒系统 270G 206G 76% EMC CX340 财务系统 941G 325% 32% 移动站业务管理系统 800G 270G 34% 安全评估 系统 600G 305G 51% EMC CX500 任务管理系统 120G 95G 79% 固定资产管理系统 300G 280G 94% EMC CX4480 下载 服务器 2020G 2020G 100% 8 生产经营管理系统 980G 800G 82% 表： XXX 客户 数据中心 存储阵列 可见，目前 XXX 客户的磁盘阵列划分孤立、分散，造成了磁盘阵列的浪费以及数据的高风险性，而且十分不易于维护。 随着之后系统和数据量的不断增加，这一现象将会持续加剧。  现状分析 通过对 XXX 客户 服务器 和 存储 现状的分析，目前 IT 基础架构有以下几个问题亟待解决：  资源孤立且利用率低下。 现有 数据中心中，计算、存储以及网络资源都是紧耦合的，也就是说数据中心内的 IT 建设是烟囱式的，根据客户需求一个项目建设一套系统，这样便形成了一个个的 ―项目孤岛 ‖。 这种系统牵一发而动全身，很难作任何改变，扩展起来要对系统进行重新设计。 在这种环境下，系统之间无法相互通信，资源不能在整个数据中心里实时、动态调度与共享，这样便使服务器与存储以及网络资源得不到充分利用，各种资源的利用效率全面低下。  服务器和存储购置成本高，维护成本递增。 随着 应用的不断增加， 服务器数量 也跟着 增加，每年要支出高额购置费用不说，还有 部分 服务器已经过保修期，部件逐渐进入老化期，维护、维修预算费用也逐年增加。  能源消耗巨大。 当前数据中心存在 海量的能源消耗和恼人的散热问题，这也成为数据中心发展的一大瓶 颈。 目前电力和数据中心辅助设施的成本已经超过了购买 IT 设备的费用，电力能耗占到数据中心整体成本中的 50%以上。  可 用 性 低下。 首先 ，几乎每个应用服务器都是单机，如果 某 台服务器出现故障，相对应的业务也将中断。 其次是 当硬件需要维护、升级或出现硬件故障时，上层业务系统均会出现较长时间的中断，影响业务的连续性， 其中包括一些重要业务系统，一旦中断服务影响很大 ，未来数据中心搬迁时会更加麻烦。  兼容性差。 系统和应用迁移到其他服务器，需要和旧系统兼容的系统。 新的软件包括操作系统和应用软件无法运行在老的硬件平台，而老的代码有时候也很难移植到新的硬件平台上。 例如： 由于各种资源数据库不同 公司分别开发 ，需要的运行的软硬平台很多时候不能保证兼容。 为节省时间、物力和保持 系统部署的顺利 ，只能用增加服务器 单独部署的 方法来解决。  资源配置与 运维管理 的 成本 非常 高昂且 效率低下。 现有数据中心的资源配置与部署大多采用人工方式，没有对应平台的支撑，没有自动化的部署。 这种管理方式首先会增加人力成本，耗费大量人力在繁重的工作上，这 使得管理费用成为机构的沉重负担。 其次，这种管理方式会导致出错率高，效率底下，灵活性低等后果 ，同时，在性能调优，容量管理方面，这种管理方式的效率也是非常低下的。  对业务需求无法做到及时响应，灵活性差。 当有新的应用需要部署时，需要重新部署服务器，存储系统，并需要对网络系统进行调整以适应新的 IT 应用的需求，因此， 运维管理人员无法快速高效地响应业务部门提出的各种要 9 求。 同时，部署实施新应用的周期比较长、成本也很高，这往往会延误新应用和新产品上市的时间，进而使企业失去了许多宝贵的商机。 虚拟化 技术 在一定程度上缓解了上述问题带来的影响，例如，服务器虚拟化可以帮助数据中心减少物理服务器的数量，进而使企业在电源、散热以及机房面积上节省巨大的成本。 此外，它还可以减少数据中心 UPS 和网络设备的费用以及所占用的空间，同时还可以大幅减少管理物理服务器的宝贵时间，提高部署服务器的效率。 但是， 仅仅 依靠 服务器虚拟化还是远远不能 充分 解决上述这些难题的， 这主要体现在如下四 个方面。 1) 现有 网络与安全 体系结构对虚拟化环境产生束缚 虽然服务器虚拟化的普及彻底改变了应用的调配和管理，但是，这些动态工作负载所连接的网络 和存储等周边资 源 却未能跟上它的发展步伐。 这些资源的 调配仍然极其缓慢，甚至一个简单的拓扑结构的创建也需要数天或数周时间。 下图给出了一个典型的示例。 图：服务器虚拟化后部署一台服务器所需的时间 从上面这张图可以看出，在服务器虚拟化之前，管理员部署一台服务器需要大概数周时间并花费上万美金。 有了服务器虚拟化后，虽然部署一台虚拟机只需要几分钟且仅花费几百美金，但是，在该虚拟机 ―周边 ‖部署所需的各种网络安全以及存储等设备仍需数天的时间，同时耗费数千美金。 可见， 虽然服务器虚拟化可以加快虚拟机的部署，但是与之相连接的网络 安全以及存储等组件并没有跟上服务器虚拟化的步伐 ， 它们严重影响了虚拟数据中心的部署效率。 传统的网络与安全体系结构除了会降低虚拟数 据中心的部署效率，在虚拟化环境下，它们还存在很多其他方面的不足 ， 下图给出了现有的网络架构在虚拟化环境下存在的一些缺陷。 10 图 ： 现有的网络架构对虚拟 化环境产生 束缚 现有的网络体系结构对底层物理硬件有很大的依赖，他们依赖于专用物理设备，因此灵活性很差。 另外，由于各种网络服务的管理界面杂乱无章，非常分散，无法进行统一的集中管理，因此，相应的运维管理工作非常复杂且容易出错。 除此之外，这种不灵活的体系结构对工作负载和应用的扩展与迁移都产生了很大的限制。 在安全方面，传统的安全防护手段价格昂贵，对虚拟化平台不具感知能力，使用不够灵活，管理难度大，不能很好地满足新架构的需要。 由此可以看出，现有网络与安全体系结构的限制将日益池化的动态虚拟世界重新束缚到缺乏灵活性的专用硬件上，人为地阻碍了虚拟数据中心的发展。 2) 传统 可用性与灾难恢复 解决方案在虚拟化环境下难以应用 虽然业务可用性与灾难 恢复技术已经有了很多年的发展，但是传统的解决方案还是存在很多的问题 ，这使得现有的可用性与灾难恢复技术在虚拟化环境下更是难以得到很好地应用 ，这些问题具体如下。 首先，传统的可用性解决方案是利用特定于应用的解决方案（如： Oracle RAC、MS SQL 集群、 Exchange Database Access Groups (DAG)等）在应用级别实施业务可用性。 虽然这种方法通常可以提供不错的可用性，但是由于每一组应用都有自己的解决方案，因此这种方法有如下弊端：  复杂且昂贵  对管理员的技术要求较高  出错的风险大  许可证较贵 (如 RAC)  专用的备份架构 其次，虽然有一些基础架构层 的解决方案可以比应用级解决方案更加经济高效，但是这些解决方案往往在正常运行时间和 RTO（恢复时间目标）方面表现得比较差。 11 除此之外，传统的 灾难恢复 解决方案很 难在 现有 的物理 X86 环境中实现 ，这是因为 传统的灾难恢复计划依赖于一套非常复杂的流程和基础架构 ，操作起来非常复杂繁琐且容易出错。 可见，传统的可用性与灾难恢复解决方案存在的诸多弊端使其很难在真正的生产环境中达到业务高可用与灾难恢复的功能， 在虚拟化环境下就更是如此， 因此，一套专门针对虚拟化环境的切实可行的可用性与灾难恢复技术成为必须。 3) 传统 运维管理 方式 无法适应全新的动态虚拟化环境 在运维管理方面， 虽然服务器虚拟化可以解决 XXX 客户现有数据中心的某些 问题，但随着虚拟化的引入，现有的传统运维管理方式已经不能满足虚拟化环境对运维管理的需求，现有的这些运维方法在新环境下存在诸多的 挑战，使用起来也将显得捉襟见肘，这是因为 现有的 传统管理工具和方法是为了支持孤立的计算环境而设计的， 因此IT 团队面临着如何利用传统管理工具和方法有效地支持新的动态 IT 基础设施 （虚拟化环境） 的挑战， 这些挑战主要包括 如下四个方面。 第一 ， 虚拟化 环境中有大量 的 数据需要管理，相对于物理环境而言， 管理员可管理的虚拟机数量要多出达 5~10 倍，服务器和变更的数量也明显增多。 这些都使得 IT专业人员在尝试部署新的虚拟化管理计划时要面对重重困难。 同时，环境中的伪警报数量大幅度增加，使得客户非常难以应对其环境所面临的挑战和性能问题。 现有的运维管理方法已经无法保证管理员可以高效地管理如此大量的数据并对问题做出快速地响应。 因此，新的运维管理方法需要提供整个 基础架构和应用 的 运行状况、风险和效率的全面 可见性，并可以提高管理员对问题的响应速度。 图： 当前的传统 运维 管理方式 第二， 对于虚拟化平台的管理员而言，工作中遇 到的问题大多是性能方面的问题，处理性能问题所花费的精力大约占到全部管理任务的 80%，要迅速定位并解决性能问题，需要 高效 的工具来辅助，单纯地使用 ―红黄绿 ‖三色交通灯的性能指示 是无法迅速地解决这些性能问题的。 因此，这就需要一种 主动管理基础架构和应用性能 而不是被动监控的解决方案。 12 第三 ，管理员在使用虚拟化平台时会面对两个对立的目标：一方面，要尽可能地增加虚拟机的密度以充分利用硬件平台的处理能力，增加投资回报。 另一方面，虚拟化的主要特征就是资源池化，资源整合以后，调配资源的灵活性大大提高，但同时也对性能和容量的管理带来了更大的挑战，如果不能有效地管理资源分配，则可能出现资源滥用，资源匮乏等情况。 实际的生产环境中一个比较常见的问题 就是 容量 “ 过度调配 ”和硬件利用率低下 ，它会损害组织最初在节约成本方面寻求的核心价值， 同时它 还会使组织无法实现最初部署虚拟化和云计算时所寻求的敏捷性。 因此，这就需要推 动更高的整合率， 管理员需要随时保证业务增长对性能和容量的要求。 第四 ，现有的运维模式容易导致大家相互指责，同时无法迅速查明问题的源头、在哪方面需要立即采取措施，以及如何尽快恢复服务。 为了解决这个问题，新的运维管理方法应该能够帮助管理员高效地定位问题的根源，它应该可以快速地缩小问题的范围，迅速定位问题所属的范畴，例如：计算，存储，网络等。 4) 云计算数据中心需要全新的 服务调配 方法 在服务调配方面， 目前没有 一种自动化的方法来为业务提供所需资源 ， 进而 导致调配延迟 ， 同时无法 提供自助服务 给终端用户 来满足常规需求。 图：传统服务调配 当前企业环境中， IT 的运营有许多带来浪费、低效率和客户不满意的通病 ， 传统的管理模式无法满足动态变化的虚拟化和云环境。 传统的垂直竖井式管理把特定应用和基础架构捆绑在一起，这种方式脆弱且不便管理。 为了增加业务敏捷性，许多企业希望缩短由竖井式的手动操作导致的冗长的服务响应时间，由于操作的不灵活， IT 专家经常需要数天甚至数周来交付急需的资源和应用。 此外，应用开发较以往任何时期都要发展迅速，功能每日都会更新，规模每小时都在改变，因此，用户需求带来的持续压力使得应用所有者面临着始终如一的快速变更率。 云计算使应用所有者可以即时访问基础架构，然而构建应用程序仍需管理员在各个虚拟机上分别安装和配置应用程序组件，以便插入到应用体系结构中。 在当下的云计算时代中，企业和组织需要更行之有效的跨云加快应用部署速度的方法。 同时， 随着业务的快速增长，企业 需要 一个更快部署系统来创造商业机会，快速响应市场需求和提高生产力的方法。 此外， 以提高 IT 效率和优化资源使用率的方式削 13 减成 本也是越来越多的 IT 部门开始寻求云基础设施的重要原因。 最后， IT 的消费者希望像获得他们生活中的自助服务和应用一样方便地获得企业的 IT 基础资源服务。 可见，。