关于云主机与VPS的区别，我们可以从以下六个方面来进行探讨：
1、从技术方面来讲：云主机使用了云计算技术，而云计算技术，整合了计算、网络、存储等各种软件和硬件技术。对于VPS来讲，它只是单纯的使用了虚拟化软件技术，相对于云计算技术的高标准来讲还是比较落后的；
2、从安全性方面来讲：云主机具有天然防ARP攻击和MAC欺骗，快照备份，数据永久不丢失。而VPS则不具有这方面的功能；
3、从可靠性来讲：云主机是基于服务器集群的，因此硬件冗余度较高，故障率低；而VPS则相对来说硬件冗余较少，故障率较高；
4、从灵活性方面来讲：用户可以在线实时增加自己的配置，可扩展空间较大；而VPS则有这方面的局限性；
5、从性能的角度来看：云主机是同等配置独立服务器计算能力的4倍，可满足高性能计算的要求；而VPS的计算能力只是独立服务器的一部分；
6、从隔离性方面来看：云主机则采用硬件隔离，彼此之间完全不影响；而VPS则采用的是软件隔离，相互之间影响较大。区别在于虚拟化是一种把硬件资源虚拟化的具体技术，而云计算是通过互联网来提供动态易扩展且经常是虚拟化的资源，类似服务器集群。虚拟化和云计算听起来可能类似，但每个都有更广泛的定义，可以应用于许多不同类型的系统。
云计算和虚拟化本质上是不同的。虚拟化是在单台服务器上创建多个虚拟环境的过程。它通过使用虚拟化软件来实现此目的，这使得可以在同一台服务器上同时运行多个 *** 作系统。OpenStack中国社区编者按：通过多年的发展，VMWare在虚拟化市场处于领军地位，很多企业部署了VMWare虚拟化方案，随着OpenStack云计算平台的快速崛起，很多企业都面临一个问题：能否、以及如何整合VMWare和OpenStack来最佳化已有的投资和对接未来的趋势？来自RackSpace的Kenneth Hui从不同角度分享了他的思考，而且给出了VMware vSphere与OpenStack整合的推荐方案。
在过去12个月中，“OpenStack 目前已经在风口浪尖之上”�0�2这句话我们已经从运营商或分析师口中听到了可事实上，很多公司仍在评估OpenStack并且试图确定如何将OpenStack与公司的IT策略整合。这也符合云计算等前沿技术的发展规律，个人的观点是：OpenStack正在经历由技术创新、实践向主流应用普及的发展过程。
我也和很多在早期就开始评估或在小型项目中应用OpenStack的公司谈过，他们的大多数如今还是VMware的忠实客户，并且运行的也都是传统应用，他们非常明白OpenStack不可忽视，但是他们很难真正理解OpenStack的真正价值，也很难理解它是如何影响他们的vSphere环境的。我们谈话中最常出现的问题如下：
OpenStack作为一个开源的虚拟机管理器，它能否替代我当前的ESXi 服务器么？
在OpenStack和vSphere之间，有没有一些特色功能的差异？如高可用性、vMotion，分布式资源调度等。
我们能否或者应否将OpenStack与vSphere混合使用？
有没有一些原因让我们同时运行OpenStack和vSphere？
我对于这些问题的答案通常从三个方面来说明问题的答案：
传统应用和云应用的区别
传统应用型架构与云应用消费型架构的不同
对使用OpenStack与vSphere过程中的一些选项进行具体说明
虚拟化和云计算
最开始对于我个人来说，当我与客户谈起vSphere和OpenStack时，重点要强调的就是传统应用架构与云计算架构的设计理念的不同。在这里，我想把重点放在基于虚拟化技术的传统应用架构上来，如ESX虚拟机管理器和vSphere，他们作为虚拟化技术的突出代表，可以在少数大型服务器之上虚拟化出很多小型服务器。这种工作机制在应用是单一架构时表现得相当不错，如Oracle或者Microsoft Exchange。今天，每一个这种传统类型应用都包裹在一个单独的虚拟机之中，只能通过ESXi虚拟机管理器扩展应用规模。在传统架构下，高可用的实现可以通过集群应用来实现，比如Oracle的Real Application Clusters；然而这同时也是非常复杂且昂贵的，并且大多数应用不支持集群式部署。大多数VMware用户则会选择将应用服务器作为虚拟机运行在vSphere集群之上，依赖于vSphere的高可用性和vMotion来提供基础架构的恢复和冗余。诚然这些解决办法都可以实现高可用，但是他们都需要特定的部署架构，如依赖共享存储等，这也一定程度地给架构的扩展性带来挑战。
云计算，较比传统虚拟化技术而言，更加适合不同类型的应用，如MongoDB和Hadoop。 像OpenStack这样的云平台，在最初就被设计成适应分布式应用的架构，应用的组件在OpenStack平台中跨越了多个物理或虚拟设备。这些类型的应用也被设计成随着规模的增加，可以通过添加应用实例或者重新平衡应用实例间的负载；另一个云计算平台背后的设计原则是，鉴于应用的分布式特性，应用d性控制权是掌握在应用自身手里而不在底层基础架构平台手中。OpenStack这种设计常常被VMware领域的同学们所误解为是它的确定或者不成熟的地方，“缺乏”如vSphere 高可用这种功能被看作是OpenStack还没有在生产级领域准备好。
但是，这是传统应用架构与云计算架构的设计理念不同所带来的误解。在云上运行的分布式应用（业内称此类型应用为“原生云应用”）已经降低了应用部署花费和可用性的门槛。通过将应用的d性化需求转移，云平台不再需要共享所有资源的架构如应用共享存储。这种改变促进了用户对构建高可扩展性云平台的需求，不单单是基础架构层，架构需要设计成包含多层以更加适合下一代大规模应用的部署。
消费模式
一旦客户了解了以上两种架构设计原则的不同，我们就可以开始讨论不同架构的消费模式问题了。这里也将区分这两种消费模式的不同。比如：
除了在我们自己的数据中心上运行裸机服务器和虚拟化技术，公司可以应用主机托管产品，如Rackspace的专用vCenter产品或在VMware的vCloud混合云产品。这两者都是建立在VMware技术基础之上，为用户提供虚拟化解决方案。两者的设计架构都较适用于那些不需要块数部署的、不依赖虚拟化基础设施提供d性和可扩展性的传统型应用。
相比之下，云计算型架构的消费模式通常开始于公有云的使用，将来向私有云部署上扩展。在这里，我们关注的重点仍是通过常用商用硬件能够实现快速资源供给、高可扩展、适应下一代应用的云架构。
vSphere与OpenStack整合
到目前为止我们应该很清楚了，VMware vSphere与OpenStack两者任何一个都无法满足多种应用类型。Rackspace就有一些用户，由于他们应用的分布式本质，用户已经将应用放到基于OpenStack的共有云或私有云之上了。相反，大多数用户都运营着传统型应用，这些应用通常运行在裸机或在虚拟化架构之上，并且它们并不那么容易地去迁移到如OpenStack这样的云架构之上。对于这些用户，共存、非替代可能是应用OpenStack的正确之道。这条混合之路通常伴随三种解决方案，如下：
孤岛型解决方案
孤岛型架构是用户选择最多的。通常，这种方案涉及到保存在vSphere上的现有遗留传统应用和在独立OpenStack云上建立新应用的抉择。虽然这是最最无痛的融合OpenStack的解决方案，但是它保持了IT基础架构的孤岛劣势，并且增加了运维和复杂性，通常我们需要两个独立团队去维护这两套独立系统，这也会带来额外的开销。
多虚拟机管理器集成解决方案
另一种解决方案是基于VMware已完成的工作将vSphere与OpenStack相集成。这种方案类似于孤岛型解决方案，传统型应用仍然运行在vSphere之上，而新的下一代应用则运行在新的虚拟机管理器之上，如KVM或在XEN。在这种情况下，OpenStack成为多虚拟机管理器的控制平台，它将允许新创建的应用被分配到最适合他们的虚拟机管理平台之上。这种架构的主要缺点是vSphere与OpenStack整合这种方案非常新，这带来了很多问题，比如两平台的整合边缘过于粗糙仍需改进，比如平台的资源如何调度等问题仍然需要解决。
Rackspace的混合实践方案
上图是Rackspace给出的OpenStack与vSphere混合解决方案。在分离管理平台这方面，这种架构非常像孤岛型架构，此外，它还保证不同类型应用可以被部署到合适的虚拟机管理平台之上。
这里的目标是保持架构的独立，整合两个环境的运维团队使他们可以共同工作来打造一个集成的平台。这其中的一个关键是应用技术，如Rackspace的RackConnect把这些基础架构连接起来，使每个架构都可以与其他架构协同工作。这里举一个例子，一个应用运行在基于OpenStack的Rackspace私有云之上，通过RackConnect与运行在vSphere集群上的Oracle数据库相连接。
运维人员的工作每天基本上都是在检查问题，枯燥但又重要， 要是你的某一个环节出现问题并没有及时发现问题，对于企业来说损失可能非常大，基本上运维人每天的工作我罗列了下，有这几种：
1、负责服务器的硬件配置、软件安装、机房上下架等技术维护工作
2、负责虚拟化技术产品物理机配置、管理和日常运行监控和维护
3、负责独立主机或虚拟应用产品的开通使用、日常维护、故障诊断和排除
4、提供独立主机或虚拟应用客户产品 *** 作和应用方面的技术支持
5、监视分管的服务器，及时发现问题，并积极解决问题
现在信息化数字时代，单靠人工去检查出现错误几率会很大，而且有的运维人还不只管理两台服务器，像我们公司的运维每人至少要管理30台服务器，这样子单靠人工运维耗费的人工成本和时间是非常大的，所以还是推荐你用运维工具吧，比如云帮手（）1支持跨云商批量管理服务器
2兼容性强大，兼容市面基本所有的云商云主机，兼容 *** 作系统；
3 *** 作简单，可视化界面预览资源、一键修复、一键部署；
4 可以远程登录云主机FTP桌面，处理云主机上的文件；
5监控和资源还有告警功能，这个是挺好的，不用盯着看；
6系统修复功能，这个是挺实用也比较必须的；
7免费使用。总得来说功能还是挺全的，不存在需要又要另外找软件的尴尬。
你好，很高兴回答你这个问题。从运维的角度来讲，服务器的数量少并不意味着我们的运维工作就非常轻松，相反我们更应该重视此阶段的工作。
我们可以从以下几方面来开展我们的运维工作：
1应用服务器
我们可以从当前服务器中找出 至少2个节点装Vsphere虚拟化，建立一个数据中心、集群 ；如果你的服务器有多网卡和SCSI，还可以做一些更高级的应用，如vmotion、负载均衡、高可用等。当虚拟机或服务器故障，可以 实现故障自动转移，有效的避免了单节点的故障，提供服务器的容错率 。
我们可以在新建的虚拟机部署Web、API等各种应用，而且 虚拟机可以在vCenter图形化界面下统一管理 。这一般是中小公司的在服务器方面的解决方案。
当然，我们对docker比较熟悉，可以使用一套docker解决方案，这比Vsphere更能节省一部分资源。当然这个需要的技能要求也比较高，需要我们不断积累。
2数据库服务器
数据库服务器在此我们单独拿出来，是因为数据库对服务器性能、磁盘IO要求比较高，不太建议使用虚拟机，当然这需要根据业务的实际情况来做选择。 数据库我们需要通过一主一从、一主二从的方式实现高可用，来避免数据库单点问 题，我们还可以选择合适的proxy来进行读写分离、读负载均衡等。另外还要考虑数据的本地备份、异地备份，来确保数据可恢复。
3系统监控
当我们在应用服务器和数据库服务器上线一套系统后， 我们需要通过监控掌握从服务器硬件、基础状态、应用、数据库等从下到上的运行状态 ，以便我们能够对告警及时做出响应。考虑到报警的及时性，我们需要监控接入多种报警渠道，如微信、钉钉、邮件、短信等。监控的目的是发现问题、解决访问，因此我们需要踏实的做好这一步，才能为我们的业务保驾护航。
好了，其实不管服务器多少，我们都需要扎实的把基础打好，这样才能以不变应万变面对各种情形。希望我的回答能够帮到你。
题主没有详细说明具体应用系统的功能，比如是否单一的Web服务？有没有微服务、分布式、集群化扩展的潜在需求？
通常来说，建议使用云服务自动化运维。云服务已经成为IT技术的核心基础设施，充分利用云服务带来的d性和分布式优势，赋能自动化运维。
一，自动构建系统
如果需要构建应用，那么就建议配置使用CI/CD持续化集成和自动化部署，比如常用的Jenkins，配置Git代码提交时触发构建，然后自动部署。
二，日志收集处理系统
1，ELK是常见的日志收集管理系统，包括ElasticSearch, LogStash, Kibana三个服务，架构示意图如下：
2，在ELK系统中，Kibana是一个图形化展示工具，配置查询条件，运维人员随时可以搜索指定日志信息，分析处理故障。
三，服务监控
1，云监控CloudMonitor
主流云服务商都将监控功能集成到了基础架构中，以阿里云为例，云监控提供了多种配置，多维度全方位监控。
比如配置CPU使用率到达80%时，自动触发动作，增加服务器实例，同时邮件通知运维人员。
2，应用监控
以监控宝为例，配置服务地址，选择分布在不同地区和运营商的监测点。当监测点不能正常调用配置的服务地址时，将收到警告信息，可以选择邮件、短信、电话等通知方式。
1，是否集群化部署？需要AutoScaling自动伸缩吗？
小型化和集群化并不冲突。如果采用集群化部署，可以配置触发条件，满足时自动增加或者释放服务器资源。比如当CPU使用率达到75%或者内存占用率达到75%时，根据配置好的服务器和数量，自动触发。
2，是否使用Docker容器技术？
Docker将应用以及依赖打包到一个可移植的镜像中，可以实现虚拟化，有助于快捷高效的交付应用，结合Docker-compose资源编排，快速实现自动部署更新，不再需要常用的Jenkins构建服务器。
机器数比较小的话，你可以用云的服务器，这样可以节省好多钱。找一个专门的运维，还不如让开发自己来搞，因为机器少运维他也应付得过来。现在都在搞云计算了，把你的机器放上阿里云或者腾讯云，你自己维护好很多，包括网络贷款都很容易扩容。上面这个我说到的只是说建议你如果你已经是自己的机器了。我建议你从我下面所说的来搞。
认为的整个过程的话一般分为三个阶段，第一的话是手工阶段，什么东西都是手工搞。
第2个阶段就是脚本阶段了，本来手工搞的东西全部脚本化。
第3个阶段就是平台化了，平台化了之后，所有东西都在页面上完成系统完成，不需要人工来干预，甚至不用运维来搞。
有一些人说既然认为就是最后的一个阶段，但是这个很不成熟。所以我就不说了。
针对你这个机器数少的，你可以手工认为，或者说用脚本认为都没问题。
在合适的阶段做合适的事情就是最好的。所以我建议你手工运维或者脚本运维。
我们项目用的 wgcloud运维监控系统 ，它前身是开源项目，后来推出的商业版，也有免费版
wgcloud运行很稳定，性能很好，部署和上手容易
wgcloud支持主机各种指标监控(cpu状态/温度，内存状态，磁盘容量/IO，硬盘smart监控，系统负载，网卡流量，硬件系统信息等)，数据可视化，进程应用监控，大屏可视化，服务接口检测，DOCKER监控，自动生成网络拓扑图，端口监控，日志文件监控，web SSH（堡垒机），指令下发执行，告警信息推送（邮件钉钉微信短信等）
可以装虚拟机代替，在同一个局域网情况下
找服务商外包服务，或者网上托管也不贵收费
服务器数量比较少，比如10台服务器，基本可以不设置运维岗位了，后端开发人员 或者架构师就能搞定。
我就是那种曾经在创业的小公司待过的开发人员，开发，运维我都干了。
但是想想如何更科学更高效的运维还是很有必要的。
软件系统的运行时环境：即公司的业务产线，靠它创造业务价值，这个是最核心的功能诉求。
实时监控系统: 任何时候都要对当前公司的产线的压力一清二楚，有问题功能随时解决，有性能问题及时扩容或者回收资源
降低服务器成本：在业务萎缩的情况下，准确评估哪些资源可以回收，降低服务器的支出
这个是当时我认为的运维的三个主要目的。
运维方案开发半路出家，当时采用的是shell+python+ansible+jekins+elk的方式
首先，我会及时的更新业务产线的物理架构图，根据架构图来规划服务器的资源使用。
比如多少个web服务，数据库多少，zk,kafka,redis集群怎么分布。
集群部署一般是放在多个服务器上的，这个时候ansible就派上用场了。
jekins主要用来自动发布更新程序已经做定时回收磁盘的任务。
elk主要用来做应用的日志系统和监控告警； 可以通过看板随时知道产线的请求数量和并发数量；
以上的运维方案适用于小公司。运维工程师看到了可以补充
搞个zabbix刷
数量少。如果配置好可以虚拟化。然后跑容器
目 录1 方案背景 3
2 VMWare解决方案综述 4
21 虚拟化简介 4
22 方案综述 5
221 VMware服务器整合解决方案 5
222 VMware商业连续性解决方案 7
223 虚拟架构部署 10
224 虚拟架构环境的集中管理、自动化及优化运行 12
3 虚拟化整合实施方案 14
31 使用硬件软件列表 14
32 部署方案 14
321 技术重点 14
322 实施步骤 15
323 数据同步 18
4 方案总结 20
方案背景
广发银行现有IT环境包含3台IBM X3850服务器，9台IBM X3650服务器以及1台HP DL580G4服务器。企业现考虑实现远程同步备份，要实现该功能，首先要配置与现有环境完全相同的IT架构， 如若要购买相同服务器进行建设并实现IT架构的高可用性，还需购置第三方应用软件进行支持，必然会导致资源严重浪费并需要大量资金支持。
基于ESX架构的虚拟化设计，可以帮助企业只需要2台高性能的服务器，既能够实现与原有IT架构完全相同的架构，还可以实现VMotion，DRS，HA等高级虚拟化功能，用以提升企业IT环境的高可用性，高管理性。为帮助贵行在不影响现有正常应用的前提下，快捷准确的实现虚拟化架构的转化，升级，特编写此方案。
VMWare解决方案综述
虚拟化简介
当前，全球有超过2万个公司用户，以及4百万个最终用户，涵盖各行各业、大中小企业等正在应用着VMware公司的软件，包括99%的Fortune 100公司。通过部署VMware软件以应对复杂的商业挑战，如资源的利用率和可用性，用户已经明显体验到它所带来的巨大效益，包括降低了整体拥有成本（TCO），高投资回报和增强了对他们的用户的服务水准等。
虚拟架构的发展
第一代的虚拟化产品通过一个hypervisor或者是主机的架构提供了服务器的分区能力。第二代的虚拟化技术增加了虚拟化的管理、生产力的规划、物理服务器到虚拟机的迁移已经其他的工具用于整合生产服务器。VMware的第三代虚拟架构（VI3）代表了下一代的虚拟化技术，该虚拟架构重新定义了一个新的IT标杆，它将工业标准服务器和存储虚拟化成了一个整体，聚合成一个动态的可集中管理的资源池，可使任何应用或 *** 作系统保持持续优化和高可用状态。它使得企业有能力去转化、管理和优化他们的IT系统架构。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-30 min；
以前硬件维护需要之前的数天/周的变更管理准备和1 - 3小时维护窗口，现在可以进行零宕机硬件维护和升级。
提高服务水平
帮助您的企业建立业务和IT资源之间的关系，使IT和业务优先级对应；
将所有服务器作为大的资源统一进行管理，并按需自动进行动态资源调配；
无中断的按需扩容。
旧硬件和 *** 作系统的投资保护
不再担心旧系统的兼容性，维护和升级等一系列问题。
方案综述
VMware服务器整合解决方案
随着企业的成长，IT部门必须快速地提升运算能力－以不同 *** 作环境的新服务器形式而存在。因此而产生的服务器数量激增则需要大量的资金和人力去运作，管理和升级。
IT部门需要：
提升系统维护的效率
快速部署新的系统来满足商业运行的需要
找到减少相关资产，人力和运作成本的方法
VMWARE服务器整合为这些挑战提供了解决方案。
虚拟构架提供前所未有的负载隔离，为所有系统运算和I/O设计的微型资源控制。虚拟构架完美地结合现有的管理软件并在共享存储（SAN）上改进投资回报率。通过把物理系统整合到有VMWARE虚拟构架的数据中心上去，企业体验到：
更少的硬件和维护费用
空闲系统资源的整合
提升系统的运作效率
性价比高，持续的产品环境
整合IT基础服务器
运行IT基础应用的服务器大多数是Intel构架的服务器
这一类的应用通常文件和打印服务器，活动目录，网页服务器，防火墙，数据库，NAT/DHCP服务器等。
虽然大多数服务器系统资源的利用率在10％－15％，但是构架，安全和兼容性方面的问题导致必须指定不同的物理平台来运行它们。
管理，安装补丁和添加安全策略将花去大量的时间。另外，服务器的衍生组件将导致设备，动力和散热方面的成本上升。
因为低服务器的利用率，低CPU的合并和中等I/O的要求，IT基础服务器首选作为虚拟化和相关整合的候选者。
虚拟化使贵行能实现：
达到甚至超过每个CPU，4个负载的整合比率
更便宜的硬件和运作成本
在服务器管理方面的重大改进，包含添加，移动，变更，预制和重置
基础应用将变得更强壮和灾难抵御能力
整合重要应用服务器
根据5个不同的服务器软件来大幅降低成本的实例，VMWARE出具了一份研究报告。
使用服务器TCO模型来分类和计算成本，我们分析显示VMWARE服务器软件帮助这些企业实现：
减少28％－53％的硬件成本
减少72％－79％的运作成本
减少29％－64％的综合成本
客户目标：
整合空闲服务器和存储资源，为新项目重新部署这些资源
提升运作效率
改进服务器的管理灵活性
通过零当机维护改善服务等级
标准化环境和改进安全
灾难状态下，减少恢复时间
更少冗余的情况下，确保高可用性
更有效的适应动态商业的需求
高级备份策略
在技术支持和培训方面降低成本
VMware商业连续性解决方案
每年成百上千的全球数据中心遭遇重大的服务中断。这些商业运行将受到用户错误，病毒，硬件故障和自然灾害等问题的影响。当前商业连续性处于企业IT策略的最前沿，并且从管理层到CEO的所有人都非常重视它。
成功的商业连续性策略元素包含：
应用程序可用计划
包含监控和平台冗余的预防措施
数据保护
灾难恢复策略
有效的人员计划
使用虚拟构架，IT管理员能改进商业连续性的所有方面，例如：
由于主备服务器之间的硬件独立性，使得灾难恢复更快而花费不多
排除计划内的硬件当机，并明显的减少计划内的软件当机
管理所有虚拟机和监控宿主机的单点控制技术
为了实现捕捉和恢复，完全的把主机压缩到文件里去
简化和可重复的自动程序
基于虚拟机的集群冗余简化
为了实现高可用性，企业使用中间软件例如微软和Veritas的集群软件，把两台服务器绑定在一个热备环境。即使运行在服务器上的应用程序有集群感知能力，万一主服务器遭遇硬件或软件错误，这样的安排仍然会导致非应用程序当机。冗余能消除单点失败。
随着IT对企业运作而言变得更加重要，高水平的服务普遍成为企业的需求，越来越多的应用则被要求高度可用。然而，为了实现如上所述的高可用性集群，就像很多服务器运行应用一样，企业需要预备和管理两次。
有了虚拟化，IT管理员能在运行重要应用的实体机和同等配置的虚拟机上创建集群。在待机状态下，虚拟机并不消耗计算机资源，并且能以非常高的比例整合到一个或几个实体平台上去。结果，企业无须在硬件数量或管理和安装补丁上投入双倍的人力和物力，从而实现高可用性。冗余的方式将由2N变为N+1。
实体到虚拟的集群和实体到实体的集群一样都支持同样的集群软件。同时，节省的成本能为更多的负载实现高可用性并签署更多的高水平服务协议。
无须原硬件的数据恢复
大多数企业IT部门使用常用的备份软件，例如Tivoli Storage Manager, Legato Networker, 或者Veritas NetBackup来创建数据和应用程序备份。既然备份策略能抵御用户错误和某些情况下的软硬件故障，比较长的恢复时间和多恢复点是能被接受的。
然而，为了获得备份所带来的好处，企业必须确保数据确实能被恢复。
业余备份，专业恢复？
为了测试数据恢复，IT管理员需要为每个已备份的主机提供一台测试的失败转移服务器，安装 *** 作系统，安装备份代理，尝试在测试失败转移服务器上调整Windows注册表和其他系统配置。如果系统调整成功，备份服务器和备份代理才能被用来测试数据恢复。
预制新的服务器和调整Windows注册表是一个漫长的手工过程并且有时并不可能。这样，在不同的失败转移服务器实现数据恢复是存在疑问的。
这些问题将被虚拟失败转移硬件给解决了。此外， *** 作系统安装，备份代理的安装和Windows注册表的调整只需做一次。此后，一个完整的已配置的VM模板将被存储在VM模板库内。Vmware软件能确保企业：
为灾难后的测试和恢复，消除硬件资源方面的障碍
避免系统和备份代理的安装，用虚拟机模板来缩短恢复周期
用标准的虚拟化硬件，使得灾难恢复更加可靠和可重复
失败转移服务器的整合和自动化
对于关联在存储域网（SAN）上重要应用的部署，企业灾难恢复策略通常包含一个灾难恢复的热站，这个站点有在主备之间的完全同步的数据复制。这种策略提供很少的恢复点对象（PRO）。然而，出于恢复时间对象（RTO）的考虑，恢复时间非常依赖于除了数据恢复之外的恢复实体服务器， *** 作系统，系统参数和应用程序的能力。
为了维持较少的恢复时间对象（RTO），硬件和系统的同一配置需要被维护在失败转移站点上。这样的配置无论在初始资本投入阶段还是在项目运作，升级，维护和支持阶段费用都是很昂贵的。
这种方案的两个明显缺点在于预制了太多的新服务器以及通常没有可能为数据恢复去调整Windows注册表和对不同的失败转移服务器的其他系统参数进行配置
部署在整个企业内的虚拟构架能确保企业：
避免在失败转移站点上停滞不前
在主备站点上，从服务器整合角度来减少投入成本
使恢复过程自动化，并实现存储管理软件的集成
改进恢复过程的可靠性
虚拟架构部署
本方案的主体部分既是安装了VMware ESX Server软件的较高配置的ESX服务器。ESX Server 是VMware虚拟架构套件VI3的基础组成部分，是动态、自我优化的 IT 基础结构的基础。<0} {0><}100{>VMware ESX Server是一个强健、经过生产验证的虚拟层，它直接安装在物理服务器的裸机上，将物理服务器上的处理器、内存、存储器和网络资源抽象到多个虚拟机中。<0} {0>通过跨大量虚拟机共享硬件资源提高了硬件利用率并大大降低了资金和运营成本。<0} {0>通过高级资源管理、高可用性和安全功能提高了服务级别 -- 对于资源密集型的应用程序也不例外。
单台物理服务器配置多个虚拟服务器的性能依据
根据统计，对于传统的服务器应用方式，通常服务器的平均利用率在5-15%之间，而采用虚拟架构整合后，服务器的平均利用率可达到60%-80%。例如，按照前面的计算，我们完全可以通过在一台双路双核30GHz主频以上的服务器上创建25个虚拟机，来完成传统方式需要25个低配置的PC机才能完成的工作，大大减少了环境的复杂性，降低了对机房环境的需求，同时具有更灵活稳定的管理特性。
采用VMware虚拟架构相比于传统单台服务器部署单一应用方式的另外一个好处是，可以充分满足不同应用对系统资源的不同要求，如有的应用只需要一个200 MHz CPU，256MB的内存就可以很好的运行，而有的高访问率、高吞吐量的应用则需要2个双核的CPU，4GB的内存才能保证稳定的运行，在传统方式下，往往不可能针对每一种应用来采购服务器，而是用一种或几种标准配置的服务器来统一采购，这样，势必会造成某些应用资源富裕，而另一些应用面临资源紧张的情况，且应用之间不能互相调配资源。采用虚拟架构后，由于每个虚拟机所需使用的系统资源都是由虚拟架构软件统一调配，这种调配可以在虚拟机运行过程中在线的发挥作用，使得任何一个应用都可以有充分保证的资源来稳定运行，同时，该应用在此时用不到的资源又可以被其他更需要资源的应用临时借用过去，最大限度的提高了整体系统的资源利用率。
每一台虚拟服务器都可以利用VMware 虚拟对称式多重处理 (SMP)技术，通过使单个虚拟机能够同时使用多个物理处理器，增强了虚拟机性能。<0}{0><}0{>作为一项独特的 VMware 功能，Virtual SMP 支持虚拟化需要多处理器和密集资源的企业应用程序（如数据库、企业资源计划和客户关系管理）。
虚拟架构环境的集中管理、自动化及优化运行
为了对服务器虚拟架构进行有效的管理和监控，方案中建议配置一台独立的Windows 2003服务器来做为VI3套件中的VirtualCenter服务器，VirtualCenter服务器为 IT 环境提供了集中化管理、 *** 作自动化、资源优化和高可用性。基于虚拟化的分布式服务为数据中心提供了前所未有的响应能力、可维护性、效率和可靠性级别。
<0}
虚拟化整合实施方案
使用硬件软件列表
软件产品 软件版本 数量
VI3企业版 35 U2 2
VirtualCenter 管理服务软件 25 U2 1
VMware Converter 401 1
硬件 型号 数量
IBM X3850 X3850 2
广发银行采购的IBM System x3850 M2(7141I02)，处理器类型为Xeon MP E7320，标配4个Xeon MP E7320处理器，最大内存容量 256GB。其硬件性能完全可以满足整合广发银行现有物理服务器整合至虚拟架构中。
部署方案
技术重点
该部署方案的技术重点在于P2V（物理机迁移至虚拟机） *** 作。通过大量实施经验表明，使用VMware Converter工具可以保证几乎所有的Windows平台物理机均可以顺利迁移至虚拟机中。而Linux的某些特定版本在进行虚拟机迁移后，可能出现无法正常开机的问题。为解决该技术难题，可以采取三种解决办法：
如果在迁移过程中没有任何报错显示迁移成功，但是启动虚拟机时无法正常引导进入 *** 作系统，在该虚拟机中直接挂载 *** 作系统的镜像文件进行引导修复，故障即可以解决。
如果迁移过程中显示报错并导致P2V *** 作无法进行，可以更换其他虚P2V工具进行 *** 作。如PlateSpin Convert等，迁移成功后使用该 *** 作系统的光盘镜像进行引导修复，即可以保证物理机完整的迁移至虚拟机中。
对于各种迁移软件均无法进行正常迁移的问题，可以采取预部署方式，首先在虚拟架构中新建虚拟机并安装相应 *** 作系统，并部署与原物理机完全相同的应用程序，确保新建虚拟机应用与原物理机应用相同。
实施步骤
首先选择一台服务器安装ESX Server，命名为ESX0，并在ESX0上创建一台虚拟机，安装windows2003 Server作为VirtualCenter Management Server（以下简称：“VC”）控制端用以统一管理以后新加入的ESX服务器。通过VC管理端添加共享存储，确保虚拟化过程中的文件全部储存在该共享存储中，为实现VMotion，HA等重要功能打下基础。
其次，使用VMware Converter工具将服务器导入到ESX0中。为了保证服务器虚拟化后，虚拟机会自动开机导致企业办公局域网中出现两个相同服务造成服务冲突，可以在虚拟化设置中将该虚拟机的网卡绑定暂时删除。在物理机转化虚拟机成功后启动该服务器虚拟机进行配置及其测试，保证虚拟机配置和物理机一致，这时可以首先闭原物理服务器，同时开启虚拟机“服务器”网卡绑定，使其接管服务器”服务。该过程会造成服务器5至15秒左右的网络中断，在该时间段无法正常进行网络服务，因此强烈建议在进行该 *** 作时避开网络高峰期或正常上班时段。
在将该物理服务器成功转化为虚拟机后，将原物理服务器安装ESX Server并命名为ESX1，通过安装好的VC控制端将ESX1添加入虚拟服务器群组中，将该台计算机的CPU、内存资源并入服务器群组的资源池中。
由于将物理服务器转换为虚拟化服务器需要至少1小时甚至更长的时间（具体虚拟化时间根据实际服务器使用率及存储空间决定），为了能够保证虚拟化实施的效率，可以在同一时间段同时虚拟多台物理服务器，在虚拟化完成后依次关闭相应物理机，并通过VC管理端依次添加目标物理服务器，实现ESX1，ESX2至ESXn全部添加到虚拟主机群组中并依次添加SAN光纤存储的绑定，实现所有的虚拟服务器均能够共享SAN存储。
最后，我们采用上文提到的虚拟化办法，将其他物理服务器，依次虚拟化为虚拟服务器，实现了物理服务器转移到虚拟服务器中的过程。
实现DRS、VMotion功能
DRS和VMotion是服务器虚拟化架构中极其重要的功能，DRS 跨聚合到逻辑资源池中的硬件资源集合来动态地分配和平衡计算容量。VMware DRS 跨资源池不间断地监控利用率，并根据反映业务需要和不断变化的优先级的预定义规则，在多台虚拟机之间智能地分配可用资源。当虚拟机负载增大时，VMwareDRS 会通过在资源池中的物理服务器之间重新分发虚拟机来自动分配额外的资源。VMware DRS 使 IT 部门能够：使资源优先用于最重要的应用程序，以便让资源与业务目标相协调；自动、不间断地优化硬件利用率，以响应不断变化的情况；为业务部门提供专用的（虚拟）基础结构，同时让 IT 部门能够集中、全面地控制硬件执行零停机服务器维护。
为了能够实现DRS功能的正常实现，在上一节服务器虚拟化过程中我们已经将所有ESX服务器全部添加绑定了同一SAN光纤存储，并添加入同一虚拟服务器群组中，确保实现DRS功能的前提条件。其次，在安装和配置ESX服务器时，我们均使用服务器中的第一块网卡进行控制，现在我们可以将服务器的第二块网卡设置为专门的“迁移”端口，保证所有虚拟服务器进行自动迁移时全部采用第二块网卡，这样就十分有效的避免了当进行大规模虚拟服务器迁移时造成的网络瓶颈，影响到虚拟服务器的网络传输性能。
虚拟化服务的调试与控制
在实现上两节的 *** 作后，服务器虚拟化的过程已经基本完毕，但是为保证企业使用服务器虚拟化架构时效率的最大化，还需要进行资源池及存储的调整。
通过多次实施经验，我们了解道有些服务器只有在特定的时间段资源利用率会提升很大，但是其余的大部分时间均保持在低资源利用率。而有些服务器则一直都保持在一个稳定的资源利用率区域内，波动很小。
为了保证资源利用率波动瞬间很大的服务器在特定时段不会出现数据拥堵，同时不影响其他服务的正常运行；为了保证一直占用较大资源且波动很小的服务器稳定运行。可以在服务器群组中分配几个资源池，将相似的虚拟服务器放入到同一资源池中。
例如某些服务器，服务器整体运行一直保持资源利用率平稳状态，很少产生较大浮的波动，我们可以在虚拟服务器群组中专门设立一个资源池命名为SR1并设置一个合理的上限值（具体上限值的设定根据企业具体办公环境确定），确保在该资源池中的所有虚拟机服务占用的资源均设置了该上限值。这样即使在极特殊情况下服务器资源突然占用很高时，也不会超过预设的上限值，从而就可以保证服务器保持一个平稳状态，而不会占用过多的不必要资源。
而某些验证或邮件服务器多数都在上午上班及中午出现资源利用率高峰时段，如果突然出现资源利用率的高峰，很可能导致虚拟化服务器资源调节功能无法及时为该服务器分配合适资源，造成数据的严重堵塞从而出现网络拥堵等不可预知情况，对企业业务连续性产生很大影响，这时可以建立资源池命名为SR2，设置合理的保留值，保留值的含义是无论服务器是否已闲置或繁忙，均分配服务器相等于保留值的资源进行保存，这样就确保了如果资源突然紧张ESX无法及时将资源分配到该虚拟服务器造成网络拥堵等问题。将这种资源利用率波动较大的服务器放入至该资源池中，即可合理避免该数据丢失的问题。
对于有些服务占用资源一直均较大，且资源波动较大的服务，则可以设置资源池命名为SR3，将SR3的共享值设置为“高”，这样无论在该资源池的服务器如何改变资源利用率，均可以分配到较高的资源，这样就确保了该服务器的正常运行。
数据同步
数据备份是保护数据可用性的最后一道防线。出色的备份战略将使IT主管在其它系统要素失效时维持正常系统运作。目前灾难恢复仍是备份 *** 作的主要目的。虽然基于磁盘的数据镜像和拷贝功能具有性能优势，但由于应用与用户 *** 作错误经常造成数据损坏，多数IT机构仍旧倾向于使用基于磁带的备份。此外，为满足管理要求而进行的长期存档将继续依赖于磁带库等离线存储设备。目前存在的备份模式主要有如下几种：
Inmage同步备份
为实现虚拟机应用服务与物理机应用服务同步，可采取Inmage工具进行。
使用Inmage的一健式应用恢复功能，实现端对端的应用级容灾的系统切换。包括数据库和应用程序， *** 作系统等。
切换 *** 作支持Failover 和Failback 两种。Failover 是指生产系统发生灾难后，容灾系统接管整个生产系统的应用和数据。Failback 是指当生产系统发生灾难或误 *** 作后，容灾系统将数据按指定的恢复点恢复回生产系统。
CDP是一种数据的连续时间点的保护技术，其根本作用是能在故障瞬间完成任何时间点的故障恢复，达到业务的快速连续的作用，从根本上解决传统备份中低恢复能力和非精细时间策略（如按照天的备份）的先天弱点。
由于Inmage 的CX 服务器可以支持一对多的传输技术，因此Inmage 可以提供本地CDP 加远程容灾同时进行。
Inmage 可以提供基于策略的广域网带宽管理，它可以给不同应用分配不同比例的带宽，例如给Oracle 分配60%,给SQL server 分配30%,给Exchange 分配10%等等。可以在您有限的广域网带宽资源的情况下，最大程度保证关键应用的容灾需求。
镜像级别同步备份
将物理服务器的系统数据和应用数据分成两部分，分别备份成为Acronis或Symentec镜像文件并通过FTP方式传输至远程灾难备份中心。过PlateSpin Convert工具将镜像文件转化为虚拟服务器可用服务。
一旦数据出现丢失或物理服务器宕机，容灾备份系统会自动启动远程虚拟服务器，保证广发银行的业务可以继续进行。
小结
总之，灾难备份计划要求有周详的事前准备，尤其是灾难所引起的对业务的冲击程度的分析并相应制定灾难后的恢复策略，配合目前最新的信息技术的可行技术，提出最佳的恢复方案。在系统备份计划建立以后，还必须在事前反复测试，并随时调整、加以改进，完整的系统恢复方案才得以建立。
方案总结
广发银行进行虚拟化实施项目，能够为广发银行未来继续进行实施虚拟化项目提供可靠的实践依据，并能在未来帮助广发银行获得更大的IT资源提升。能够极大体现虚拟化对客户的影响，具体体现有：
节省测试和新服务部署成本：利用虚拟化架构可以帮助广发银行快速建立虚拟机，随时部署新的应用及服务而不需要单独购买新的物理机。同时，快捷的虚拟机建立方式更可令广发银行IT部门节省大量的测试物理机成本而随时进行程序测试，服务测试等。测试完毕后只需要删除虚拟机，虚拟机占用的资源会自动恢复到资源池中，不影响服务期内其他虚拟机的任何正常应用。
提高资源利用率：通过在一台服务器上运行多个服务器环境，客户可有效地实现硬件资源的归集共享，并且可灵活地实现计算资源的重用以及系统环境计算资源的动态分配。
提高可管理性：通过VMware VirtualCenter可实现服务器环境创建、配置、资源管理和工作负荷管理的集中化与简单化。
简化部署：借助于模板，系统管理员只需几分钟的时间即可部署出新的、与硬件无关的标准化服务器虚拟机，并且可在部署过程中使用更多的自动化 *** 作。
降低成本：虚拟化基础设施可实现服务器计算资源的集中化以及服务器硬件的标准化，这样企业不仅降低服务器支持的复杂度，并且缩减了服务器支持成本。更高的灵活性：用户可从一台客户机访问多个服务器环境。管理员瞬间即可对那些当前未处于使用状态的服务器环境完成删除 *** 作，并且从中回收的资源马上就能得到重用。
提高数据保护能力：管理员可采用现有的数据中心备份过程来确保可靠的服务器备份。虚拟机的硬件无关性大幅度简化了系统恢复。而且所有数据都驻留在数据中心，这样数据安全保障也得到了简化。
保障业务连续性：虚拟化架构中的DRS功能可以自动检测服务器中虚拟机资源使用情况
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）