SHOUG成员 – ORACLE ACS高级顾问罗敏
数据库私有云技术
云计算是当下IT行业最为热门的技术领域之一。无论是IT行业各厂商，还是IT从业人员，如果不念念有词云计算，不知道什么叫IaaS、PassS、SaaS，似乎就Out了。不仅广大IT人士被各厂商的云计算概念弄得云山雾罩，而且也有很多调侃云计算的段子。例如，美国某记者在街头随机采访一老太太，询问“什么叫云计算？”。老太太一本正经：“就是在飞机上访问Internet吧？”，呵呵。
云计算到底是什么？作为IT公司大佬的Oracle是如何定义和诠释云计算，特别是数据库云计算的？Oracle数据库云计算中有哪些关键技术？数据库云计算有哪些成功案例？本章将就这些话题展开讨论。
20.1 云计算概述
云计算定义
云计算实际上是网格计算、分布式计算，以及并行计算、网络存储、虚拟化、负载均衡等传统计算机技术和网络技术发展融合的产物。虽然各IT软硬件供应商都在研究和发展自己的云计算产品和技术，对云计算的定义和解释也不尽相同。但美国国家标准与技术研究院（National Institute of Standards and Technology，NIST）的如下定义，基本为IT行业所普遍接受：
“云计算是一种新的计算模式。在该模式下，用户可便捷、按需地通过网络访问一组包括网络、服务器、存储、应用和服务在内的计算资源池，并且服务供应商可以极少的管理成本，对计算资源提供快速供应和释放能力。”
以下是云计算架构示意图：
云计算基本特征
根据上述定义，云计算具有如下基本特征：
- 按需的自助服务能力
- 资源共享池
- 快速灵活的伸缩性
- 可度量的服务
- 高速网络访问能力
云计算服务模式
云计算可以认为包括以下几个层次的服务：
- IaaS：基础设施即服务
IaaS(Infrastructure-as-a-Service)：基础设施即服务。消费者通过Internet可以从完善的计算机基础设施获得的服务。
- PaaS：平台即服务
PaaS(Platform-as-a-Service)：平台即服务。PaaS实际上是指将软件研发的平台作为一种服务提交给用户。
- SaaS：软件即服务
SaaS(Software-as-a-Service)：软件即服务。它是一种通过Internet提供软件的模式，用户无需购买软件，而是向提供商租用基于Web的软件，来管理企业经营活动。
云计算的实施模式
从实施角度而言，云计算具有如下4种模式：
- 公有云
公共云是在公共网络上搭建的计算平台，比如亚马逊等网站提供的云服务。
- 私有云
私有云就是企业内部搭建的计算资源平台。比如Oracle公司在企业内部就拥有并使用很多私有云平台，供广大研发和技术支持人员使用。
- 社区云
社区云是公有云和私有云的变种，实际上是若干个企业共享一个云计算平台，介于公有云和私有云之间，主要特征是使用权和所属权的分离。
- 混合云
混合云是将私有云和公有云结合起来的计算资源。比如很多银行和保险公司在月底做报表的时候需要大量的计算资源，如果按照这个峰值配置硬件设备又很浪费，80%的时间内有80%的机器是闲置的。因此，可以将企业内部的机器和亚马逊这类的云服务供应商相连接，需要的时候通过云计算服务租取机器。
云计算的益处
云计算的核心思想即为客户提供一组资源共享池。通过云计算理念构造的IT系统，将为客户带来如下图所示的四方面的效益：
- 降低IT系统成本
在云计算架构下，各IT系统不再拥有独立的计算资源，而是共享计算资源，因此，IT系统建设和运行维护成本都将显著下降。例如在建设方面，服务器、存储等硬件资源将大幅度减少，对应的软件许可证（License）和资源投入也将大幅度减少。
- 降低IT系统复杂性
云计算架构的共享计算资源池，将具有规范的配置，包括操作系统、数据库等平台和系统软件都将实现标准化和统一化，从而有效降低IT系统的复杂性。
- 提高IT系统灵活性
云计算架构所具有的在线变更能力、快速响应能力等，将使得随着业务的不断发展，可灵活变更IT系统架构，充分提高IT系统灵活性。
- 提高IT系统服务质量
云计算架构提供了完备的高可用性解决方案，将有效保障IT系统服务时间。共享资源池将使得 IT系统处理能力和响应速度大大提升。同时，各种有效的安全技术和产品施，也将使得运行在云计算架构下的IT系统更加安全、可靠。
不同层次的云计算
不同层次的云计算
根据Oracle公司的定义，云计算可划分为如下层次：
即划分为基础架构云计算和数据库云计算。其中基础架构云计算是指在主机和操作系统层面实现的资源共享和整合，例如通过虚拟技术将一台高端物理主机划分为多台虚拟主机，或者将多台物理虚拟成一台高端主机。
而数据库云计算则是在基础架构云计算之上实现的更高层次、给客户带来更高投入产出比的资源共享和整合技术。数据库云计算又可分为平台整合和数据库整合技术。其中平台整合是指将过去在多个平台、多个版本的数据库，整合到统一的硬件和操作系统平台，但仍然部署为多套数据库的架构技术。而数据库整合则是进一步将多个数据库整合为一套集群数据库的架构技术。
不同层次的云计算的对比
以下是Oracle公司针对上述不同层次的云计算架构，而进行的对比分析：
总之，数据库云计算相比基础架构云计算，给客户带来的投入产出比更高，具有更好的架构灵活性，并提供更好的服务质量，但实施难度更大。
某案例的基础架构云计算实施
某客户采购了IBM 770服务器，并欲在其中实施数据库云计算项目。以下就是IBM公司从基础架构层面提供的云计算实施建议，供大家参考：
总体思路
通过虚拟化技术，将XX客户采购的IBM 770服务器资源划分为多个逻辑服务器，作为数据库云服务器。这些逻辑服务器可以快速的根据XX客户各业务需要灵活部署应用，并可根据实时业务压力，分配各个业务的资源需求，从而提高系统管理效率，降低管理成本。
随着系统规模的扩大，如今后资源服务器池需要扩充时，可以通过纵向扩容的方式增加服务器处理能力；或者采购新的高端服务器，添加到数据库服务器池中。
实施策略
- 根据业务需要，可初步规划多个分区分别用于各个生产应用。另外，虚拟IO分区可以用于向其他分区提供虚拟网卡和虚拟磁盘。对于关键应用，可以配置真实的物理网卡和物理磁盘。对于非关键业务（如：开发测试或者一些小规模的应用，可以分配虚拟的网卡和虚拟的磁盘，这些磁盘和网卡由虚拟IO服务器提供）。
- 在系统部署时，通过高级虚拟化技术（如：IBM Power 770服务器中采用的PowerVM虚拟化技术），可将整台服务器进行灵活的逻辑划分，分区的颗粒度可达到0.1颗CPU。每个分区相互独立，各自运行独立的操作系统和应用，互不影响。同时，利用共享处理器池(shared processor pool)和动态逻辑分区(dynamic logical partition)的功能，能够保证最大限度地利用系统宝贵的硬件资源，能够为分区提供极大的峰值处理能力，还可以根据实际需要，在不停机的情况下调整硬件资源，部署新的业务分区等。
- 在实施时，可以将分区设置为“不受限”uncapped分区：即，分区能够使用到的CPU处理能力，允许超过其分配的CPU容量。如下图：
其优势在于，当分配给此分区的CPU没有使用时，分区内的CPU资源可以“还回”共享处理器池。而当此分区有工作负载时，此分区又可以马上得到“额定”的CPU资源。
另外，虚拟化技术的引入，使对于操作系统的监控方法和指标发生了改变。这需要我们转变思路来适应。在硬件层面，使用共享处理器池方案分区可以自动调整计算能力，分区所获得的计算能力会根据负载变化。
最终产生的效果是通过虚拟化技术，降低了物理设备的资源需求的，提升了系统总体的利用率，示意图请参见下图。
- 根据上述初步规划，IT资源服务管理平台可以帮助实现IT资源的自动化部署，且在不停机的情况下动态调整资源配置。
- 为了保证系统的持续运行和高可用性，770服务器上的分区都安装高可用集群软件，实现自动的故障探测和切换，消除系统单点故障。
- 每个逻辑分区中还配置多块Gigabit 以太网卡，进行高速的数据通信。在分区中配置8Gb/s的HBA光纤通道卡，连接存储服务器，实现对数据的高速访问。
在IBM Power机器上配置的8Gb HBA卡是有NPIV功能的。如前文所述，对于开发和测试可以考虑使用虚拟的IO设备，由虚拟IO服务器分区来提供，而在这些分区中使用NPIV（N-Port ID Virtualization）技术可以简化VIO Server的部署和管理。简单的讲NPIV功能原本就是在SAN交换机上的一种虚拟化技术，目前应用到Power服务器上实际上是HBA卡的虚拟化，同时也需要SAN交换机的配合（这种配合比较简单，目前大多数的SAN交换机，都支持NPIV技术。在实施时，将相应的SAN交换机的NPIV功能激活即可）。
产品和方案特点
- 优异的系统处理能力
此次XX客户采购的IBM 770服务器是IBM的顶级UNIX服务器，配置36核CPU和320GB内存，具有强大的在线事务处理能力和计算能力。该服务器采用先进的POWER7微处理器，高主频提供了优异的整机性能及近线性的扩展能力。其多项基准测试数值为业界领先。在衡量服务器在线事物处理能力的基准测试中，是目前在该项测试中排名第一的服务器产品。
- 选择业界领先的处理器技术和平衡的服务器体系结构
服务器体系结构是决定服务器性能的关键因素。在选择服务器时，需要根据业务情况选择合适的主机平台，主机平台要能够支持交易处理，业务查询和应用开发，尤其在交易高峰期间能够与磁盘系统配合，使整个系统性能平衡不会出现系统瓶颈，保证系统响应大压力的数据负载。
IBM一直保持着单机性能业界第一的位置，在CPU的数量上仅为其他竞争厂商的一半甚至更少，也就是说在相同性能下选用IBM服务器大大降低了IT系统的总体成本，在现在IT系统更讲究系统资源集中的情况下，IBM的服务器以更高的性能、较少的CPU、更高的安全稳定性、更低的功耗、更小的占地面积来完成IT系统的整合。大大降低用户的初期总体投资以及运营成本。
- 选择高可用技术
XX客户运行的关键业务要求其生产系统达到7X24的连续运作水平，因此系统高可用性的考虑是系统方案中必不可少的因素之一。在进行硬件配置时，用户肯定会选择运行更为稳定的硬件，以及更高安全级别的技术，但任何单机运行的系统都是不安全的，因此，建议为生产系统中的分区配置高可用软件（如：IBM的HACMP软件），同时配置相应的配件（如：串口卡等），构成双机系统。
在生产系统中，某个应用至少要部署在两个服务器分区上，分区上安装高可用软件，实现双机互为备份或者双机同时工作。
能够对群集环境中每个结点的异常情况进行实时监测并进行恢复响应，监测过程不需要人工干预，可以监测的对象包括：系统处理器、系统内存、网络介质及网卡、系统进程、应用进程等。当POWERHA监测到上述故障时，它会重新配置群集结构，并将应用从出现问题的主机系统快速地切换到正常工作的主机之上继续运行，保证了应用的连续和正确运行，这个恢复相应的过程也无需操作人员的参与。
除了减少意外停机外，还能减少计划停机的时间。当需要进行硬件更换或软件升级等系统维护工作时，操作人员可以发出简单的命令将应用包从待维护的结点移至其他结点。这样，在进行系统维护的同时，整个群集中的应用不受影响。当结点的维护工作完成之后，便可将其重新加入到群集结构中，并把原在其上运行的应用包切换回来，恢复该结点的正常运行。采用循环升级的方法可以升级群集内的所有系统，同时不影响群集的正常运行。
因此，在我们的推荐的方案中，对所有的生产系统全部进行高可用性保护，消除整个系统中的单一故障点。
- 选择成熟稳健的虚拟化技术
建议XX客户业务在服务器上的部署采用先进和成熟的分区方式。虚拟化技术能够提高服务器资源利用率，简化系统管理和维护的负担。
以IBM PowerVM技术为例：它提供了比物理分区更好的灵活性和细颗粒度，以及比软件（操作系统级）分区更好的性能，可靠性和效率。其最大的特点在于可实现资源的动态分配而无需重启操作系统。对于XX客户业务而言，重启操作系统就等同于宕机，这种无形的损失是无法估量的，这一动态分配技术则很好的解决了这一问题。
在CPU、内存、I/O等资源控制和调配上，分区技术具有更大的灵活性和操作性，使用户更加有效地利用服务器资源，当各个分区投入生产后，若某个分区的资源不够时，动态分区技术可以做到不用停止操作系统和应用程序，就可以将分区之间的资源进行相互调配(动态增加或删除CPU、内存、I/O卡等)。分区技术稳定可靠，能够保证各分区之间相互隔离，保证一个分区的错误不会影响到另一个分区的运行。
数据库云计算中的典型技术
在Oracle数据库云计算实施中，为实现按需的自助服务能力、资源共享池、快速灵活的伸缩性、可度量的服务等云计算基本特征，特别是实现对数据库整合之后的性能、安全性、资源管理等精细化管理和控制，Oracle提供了RAC集群、自动存储管理（ASM）、服务（Service）、资源管理（Resource Manager）、实例隔离（Instance Caging）、企业管理器（OEM）、Data Guard 容灾等典型技术，其中除实例隔离（Instance Caging）等之外，其它技术均在11g之前就已经推出，但这些技术在数据库云计算中得以发扬光大，真可谓老树发新芽。
以下只介绍服务（Service）、资源管理（Resource Manager）、实例隔离（Instance Caging）等技术在数据库云计算中的运用。
服务（Service）及在数据库云计算中的运用
服务的概念最早是在 Oracle8i 中引进的，当时是通过服务的设置，使得监听程序在集群的节点和实例之间实现连接负载平衡。现在，服务的概念、定义和实施都已经有了巨大的扩展，特别是在数据库云计算中，通过服务可以实现对众多整合资源的精细化管理和控制。
服务是一项工作量管理功能，用于组织数据库内的整个工作执行，以便使该工作更易于管理、衡量、优化和恢复。服务是数据库内相关任务的组合，这些任务有共同的功能、质量预期值以及相对于其它服务的优先级。服务可提供单一系统映像，用于管理在单个实例内运行的竞争应用程序，以及跨多个实例和数据库运行的竞争应用程序。
使用标准接口（例如 DBCA、Oracle Enterprise Manager 和 SRVCTL），可将服务作为单个实体进行配置、管理、启用、禁用和度量。
服务具有高可用性特征。即某个节点或实例宕机之后，运行在其上的服务中断后，仍然会在仍正常运行的节点或实例上快速自动恢复。
在Oracle的AWR中，可以服务为单位进行性能的监控分析，更有效地进行应用的性能管理。在Resource Manager中，也可以服务为单位进行资源的细粒度分配，能更合理地有效利用系统资源。Oracle的其它工具和产品，例如Oracle Scheduler, Parallel Query, and Oracle Streams Advanced Queuing等均能有效地运用Service概念，进行系统负载的管理工作。
服务还具有动态性。即负载增大时，可增加服务运行的实例数；负载减小时，可减少服务运行的实例数。通过这种动态资源分配，可以实现经济有效的解决方案，随时满足各种需求。
在下面的案例中，我们将看到在数据库云平台中，如何通过服务实现众多应用的精细化管理和控制的。
资源管理器（Resource Manager）及在数据库云计算中的运用
通常客户都有这样的需求：防止普通用户通过SQL*Plus或PL/SQL Developer等工具，随意执行低质量的SQL语句，从而消耗大量资源，对前台正常业务造成影响。针对优先级特别高的应用模块，希望Oracle能优先分配更多资源，等等。
为满足客户对系统资源使用的细粒度控制，Oracle自8i开始就推出了Database Resource Manager技术。在历经8i、9i、10g之后，该技术在 Oracle 11g中不仅日益成熟，而且功能也有了重大增强，更在数据库云计算中得到了更大的运用空间。
试想，在数据库云平台中，众多应用模块同时运行在一个资源池中，共享也是竞争相同的硬件和软件资源，如何有效地根据不同应用模块的特征和优先级，合理调度和控制资源的使用，是数据库云计算项目建设和运维需要考虑的重大问题。
Resource Manager通过将用户分组，然后把系统资源分配给不同用户组，实现系统资源的管理。Resource Manager可以管理CPU资源，内存资源，以及服务器上的其它资源，并且可以实现资源管理的自动化。例如，如果预计某个用户组的资源使用将超过限额，Resource Manager将重新安排它的优先级，从而使系统的整体性能达到最佳。
Resource Manager允许对资源的更多粒度控制并为客户组添加诸如自动客户组切换、最大活动会话数控制、查询执行时间估计和撤消池限额之类的特性。管理员能够指定每个客户组的最大并发活动会话数。一旦达到这一极限，Resource Manager 将对所有后续请求进行排队并仅在现有活动会话完成之后才运行它们。
Resource Manager 的自动客户组切换功能允许管理员指定某一准则，如果满足它，将导致 Resource Manager 自动切换一个长时间运行的客户组，例如，从为 OLTP 操作而建立的客户组到另一个适合成批报告的客户组。管理员也能够为每个客户组设置最大估计执行时间。然后 Resource Manager 在每个操作开始之前为操作估计大致的查询执行时间，如果此时间超过指定的极限，将终止该操作。利用撤消池限额特性，管理员能够为每个资源客户组生成的回退数据总量指定一个最大值。这将阻止一个”欺骗”事务处理消耗过多的回退空间并因而影响系统操作。
以下是某电信公司为避免部分用户对系统资源过度使用系统资源，运用 Resource Manager的一个实施案例：
- 资源计划设计
resource_manager_plan = FORCE:CRM_PLAN
即强制设置了资源计划：CRM_PLAN。
- 资源消费组设计
以下是在 OEM中设计的资源消费组(Comsumer Group)和Direcive等情况：
即设置了多个消费组，并对其中的INTERACTIVE_GROUP、INTERFACE_GROUP、MAINTAIN_GROUP等消费组的Execution Time、I/O等指标进行了限制，并达到了显著效果。
实例隔离（Instance Caging）技术及在数据库云计算中的运用
实例隔离（Instance Caging）技术是11g R2为满足数据库云计算需求而推出的新技术。该技术其实很简单，就是增加了一个数据库初始化参数：CPU_COUNT，该参数表示该实例所能使用的CPU个数，其缺省值为0，表示该实例可以无限制地使用机器当前服务器的所有CPU配置。
Oracle RDBMS的若干组件都与CPU个数相关，例如：优化器、并行查询、资源管理器等。因此，通过CPU_COUNT参数的配置，可为共享服务器中的数据库实例提供CPU访问能力控制，避免无限制使用CPU资源，保证服务级别。特别在采用平台整合技术实现的数据库云平台，通过Instance Caging技术的运用，可根据不同应用、不同实例和不同数据库的服务级别的优先级，设置相应的可使用的CPU数量上限。
例如，右图表示在一个8核CPU服务器上整合了HR、Sales、ERP三套数据库和应用。我们可以根据需求，为ERP应用分配4颗CPU，为HR、Sales各分配2颗CPU。
同时，CPU_COUNT参数可不停机动态进行调整，如果业务负载发生变化或服务级别发生变化，可通过该参数的调整，满足相应的需求。
另外，Instance Caging技术支持硬件分区和虚拟化技术。该技术也是对Resource Manager的补充。即在数据库实例内部，主要通过Resource Manager来进行资源使用的管理和控制，而实例之间则可通过Instance Caging技术来进行资源的管理和控制。二者的有机协调工作，将会为数据库云平台的资源合理、有序使用提供保障。
一次尴尬的拜访经历
一次尴尬的拜访经历
2013年夏天，本人作为服务解决方案顾问拜访某外资银行时，得知该客户的现有几十套IT系统为典型的“竖井”式架构，并具有典型的“三多”特征：系统多、平台多、版本多。当时我们力荐客户进行数据库整合和版本升级，并从数据库云平台高度去帮助客户立项。但客户当时说需要等几个月进行内部调整之后，方可进行这么大的架构改造动作。
待2013年12月我们再次拜访该客户，旧话重提，并希望我们Oracle服务团队能在此项目中大显身手时，客户的回答是：“我们已经做完升级和整合了”。-
—- 惊讶、失望、尴尬，刹那间这些复杂情绪全部涌上心头。惊讶的是客户怎么如此之快就悄然完成了这么复杂的数据库升级和整合操作？失望的是客户自己完成了这么浩大的工程，我们Oracle服务团队失去了一次商机，更失去了一次在客户面前展现原厂服务价值的机会。尴尬的是我们Oracle公司成天讲升级、整合的难度和风险，客户现在这么神速完成升级和整合，肯定会觉得这不就是搭建个11g RAC数据库，然后把现有系统数据一倒，应用一跑就完了吗？你罗工不就是一大忽悠吗？
尽管感到一定震惊，但经验让我马上镇定下来。接下来，我开始详细了解客户如何完成升级和整合的。哦，原来如此：客户的数据库资源池硬件为IBM X86平台，8核或16核CPU、64GB，按照该外资银行总部的整合规则，最多6个数据库部署在2个节点的6套RAC数据库中。原来只是在硬件平台进行了整合，即上述的平台整合，而不是以schema方式进行的数据库整合。也就是说：虽然数据库版本都升级到11g R2，并且部署到统一的硬件平台，但数据库并没有整合，整合力度不够，仍然存在实例过多，内存、进程浪费的问题。
而且在平台整合过程中，客户并没有充分考虑实例之间的Instance Caging、实例内部的资源管理器等技术的运用，即没有考虑不同应用对资源使用的不同优先级需求。同时，也没有考虑Service等技术的运用。也就是说，虽然系统整合了，但精细化管理技术的运用并不够。总之，该项目是一个整合力度不够，而且粗放型的整合项目。
进一步，在对被整合的一个最大的数据仓库系统进行现场调研分析时，也发现该系统存在应用软件质量较差，例如索引策略不合理，语句共享性较差；没有实施分区方案；RMAN实施存在缺陷等诸多问题。具体而言，在RMAN实施方面采取简单的每天全库备份策略，3TB的全库备份时间长达3个小时，而且备份时间从8：00开始，直接影响了生产系统正常访问，非常不合理。改进措施就是不仅调整备份时间窗口，更重要的是采用“全库+增量”备份策略，并采用快速增量备份（FIB）技术。果然，客户在马上采纳我们的建议之后，增量备份时间才18分钟！
因此，再次验证本人一句断言：任何一个IT 系统的实施都会存在不足，只要有心，作为Oracle原厂技术服务团队，我们都能找到服务机会，并展现我们的服务价值的。
但是，我在离开该客户现场之后，仍然是感慨万千，特别是失落感更为强烈：毕竟客户围绕Oracle展开这么大的架构改造动作，居然一点没告诉我们Oracle公司，虽然存在一定问题，但总体还是成功了。如果客户能更相信我们，甚至依靠我们；如果我们的销售、售前、实施团队能更紧密地与客户沟通，也许客户就会采纳我们的更多方案和建议，例如在数据库层面进行整合、采用资源管理和Service等关键技术，我们的服务价值就能得到更充分发挥，我们与客户的合作关系就将更加紧密… …
毕竟IT系统建设和运维是一项长期的系统工程，亡羊补牢，为时未晚。这个世界上也允许有很多如果存在的… …
数据库云计算案例分享
某移动客户的业务支撑部门在多年发展中，不仅建设了营业、帐务、计费、中心枢纽等核心业务系统，而且还由于业务和历史原因，还建设了平台、架构不一的几十个外围小系统。如何将这些系统进行整合，并有效提高设备利用率、加强技术平台规范化、降低建设和运行维护成本，成了该客户领导和技术人员关注的话题。于是，综合资源池项目建设提到了议事日程，并在局方、Oracle ACS团队、多个开发商的共同努力下，于2012年 – 2013年间成功实施了该项目。下面将该项目一些主要情况叙述如下，供大家在建设类似项目时，加以借鉴。
“我们的架构也差不多都是这样”
下图就是该移动客户业支部门大大小小的部分外围小系统基本情况：
可见，具有典型的“三多”现象：系统多、平台多、版本多。例如，平台包括HP-UX、AIX、Sun Solaris等，数据库版本包括9.2.0.1、9.2.0.6、10.2.0.3、10.2.0.4、10.2.0.5、11.2.0.2等。
从架构方面而言，大量采用双机热备技术，只有一套系统采用了RAC技术。双机热备架构并不能充分满足高可用性切换的时效性需求，而且备份服务器资源不能得到充分利用。
上述系统在CPU、内存配置和利用率等方面也各不相同，数据库容量也相差甚远。这种设备配置和部署都是考虑各业务系统峰值，而系统之间是绝对隔离的，资源无法共享，导致了资源极大浪费，同时又存在业务高峰时单个系统资源不足的风险。
这就是典型的竖井式架构！当本人每次将该表格展现给其它客户时，他们都会掩嘴自乐：“我们的架构也差不多都是这样”。我想很多读者看过之后，也会发出类似感慨和会心一笑，呵呵。
整合目标和总体架构
以下就是综合资源池项目的总体目标：
- 构建安全的共享数据处理资源池
- 采用云化技术统一构建与管理
- 统一考虑处理能力与冗余
- 主机与数据库平台的规范化建设，降低运维成本
- 统一管理平台
- 统一采用集群与容灾技术
- 增强业务高可用性
- 分布式数据层技术
- 通过分布式的数据层和智能存储解决性能瓶颈，实现高智能复杂业务
- 能够容易水平的扩展处理能力
- 良好投资回报率
以下就是数据库整合之后的架构：
可见，数据库整合项目将部署在一个4节点组成的RAC数据库之中，即采用的是数据库整合架构，而不仅仅是平台整合架构。即原有各应用数据库以Schema形式部署到新的数据库资源池中。
在4个节点中，前三个节点承担相关应用的运行，而第4个节点作用则包括两个：一是承担日常数据库备份操作，二是当前三个节点发生故障时，承担故障切换（Failover）角色。
在前三个节点的应用部署中，则综合考虑了多种因素，例如：重要系统与一般系统；OLTP与OLAP；操作系统厂商情况；CPU、内存、IO负载情况；业务数据量大小；业务应用连接数量；业务负载情况；数据库版本情况；数据库数据字符集；原有数据库部署架构；应用代码开发编写特点（绑定变量的使用）；业务月结负载特点… …
可见，如何在考虑业务尽量均衡、数据访问冲突间量少，还要兼顾上述那么多因素，以及未来业务发展趋势等方面进行应用部署，并不是一件轻松的事情。
关键技术的运用
- Service的运用
在该项目的数据库资源池中大量利用Service技术，来达到对众多整合资源的精细化管理和控制。具体而言，该项目按照如下原则进行Service的设计和部署：
- 每个业务或者应用皆定义为Service。
- 应用基于Service进行部署，并实现高可用性的连接。
- 应用基于Service进行动态的部署
- 应用基于Service进行故障切换
- 基于Service进行资源的控制
- 基于Service进行管理，提供了一种新运维管理维度
例如，以下就是部分Service设计和部署情况：
| 原有数据库名 | 应用名 | 服务名 | PREFER | AVAILABLE | TAF policy | Failover type | Failover method | retries | delay | |
| 双屏数据库 | Ngdus | ngdus | inetg1 | integ4 | Basic | select | basic | 10 | 2 | |
| 稽核系统数据库 | Ahaudit | ahaudit | inetg2 | integ4 | Basic | select | basic | 10 | 2 | |
| BI库(接口) | Worabidb | dss_bi | integ3 | integ4 | Basic | select | basic | 10 | 2 | |
| … … |
以下就是创建Service的规范化语句：
srvctl add service -d 云平台 -s srv14 -r 云平台1 -a 云平台4 -P basic -e select -m basic -z 10 -w 2 其中： -d <dbname> -s <service name> -r <prefer node> -a <available node> -p <TAF policy> 服务端设置为basic -e <failover type> 配置为session 或者select 建议默认配置为select -m <failover method> 配置为basic -z <failover retries> 云平台设置为10 -w <failover delay> 云平台设置为2
- 资源管理器的运用
该项目通过资源管理器来合理控制资源使用，即一方面为不同层级应用制定资源优先级策略，为核心应用确保足够的资源，另一方面也防范对资源滥用情况的发生。为此，该项目制定了如下一些资源管理策略：
- 每一类应用用户使用固定的service 连接至云平台数据库。
- 每一类应用至少给予5%的CPU 资源。
- 核心应用至少给予30%的CPU 资源
- 系统管理类用户(sys/system) 会有最高权限获得至少75%的 CPU 资源并且保证可以连接
- 系统自动任务和管理类JOB 会使用应用CPU 资源余下部分中的至少5%的CPU资源并且总CPU资源消耗不超过90%
- 其余连接用户或者服务使用余下资源。
例如，以下就是节点1的资源分配计划：
即：
- 划分了level1至level3 三级分配策略。Level1 优先级最高,level3优先级最低。
- 上一级未用完的系统资源可用于下一级。
- 如节点1中，首先管理进程可获得最多75%的CPU资源。
- INGWDB,PMOS,SMS,MRMSPU资源的最大比例为7:1:1:1。
- 如果前两级资源为充分使用，在第三级可获得前两级剩余CPU资源。其中分配比例为3:3:3:1
效益评估
以下就是从项目建设和系统运维方面对该项目的效益评估：
- 项目建设方面
首先在硬件方面降低了成本，通过整合，将16台数据库服务器整合到4个数据服务器，平均每台数据库服务器利用率从15%增加到40％。
在软件方面，由于通过整合，将30台服务器192 CPU整合到4台112CPU ,降低了软件采购成本。
再则，打破了以前建设一套新系统需要专门部署一套硬件和软件的思路，现在的新系统建设，只需在数据库设计、应用设计、Service设计、应用部署等方面进行规范化检查，即可快速部署，而无需专门部署硬件和安装系统软件。
- 系统运维方面
首先，通过整合，将原有30台主机的日常维护，健康检查，补丁升级工作，降低为对4台主机的日常维护，运维管理效率提高7.5倍。通过企业管理平台的实施，包括诊断和调优包实现自动诊断和调优操作，使运维人员工作效率提高。同时，通过标准化平台管理，降低了复杂性并和减少配置工作。
再则，将原有30台主机的耗电空调降温成本，降低为对4台主机的耗电空调降温成本。将原有30台主机整合到1-2个机柜，减少了数据中心空间占用。
最后，数据库版本升级后，使用11G数据库新优化特性，提高数据库处理性能。 另外，数据库迁移后，数据碎片得到整理。提高数据库IO处理效率。而且，数据库版本升级后原厂支持响应更及时。
20.7本章参考资料及进一步读物
本章参考资料及进一步读物：
| 序号 | 资料类别 | 资料名称 | 资料概述 |
| 1. | Oracle公司网址 | http://www.oracle.com/technetwork/topics/cloud/whatsnew/index.html | 这是Oracle公司技术网站中有关云计算的资源汇集地，有产品、技术、白皮书、最佳实践经验等。 |
| 2. | Oracle技术白皮书 | 《 Architectural Strategies for Cloud Computing》
该文章位于http://www.oracle.com/us/ciocentral/architecrl-strategies-for-cc-396213.pdf |
该文章描述了云计算基本概念，特别是Oracle公司的云计算基本策略。 |
| 3. | Oracle技术白皮书 | 《 Database Consolidation onto Private Clouds》 | 该文章描述了Oracle数据库私有云基本概念、架构、关键技术运用及实施案例等。 |
| 4. | My Oracle Support | 《Master Note for Real Application Clusters (RAC) Oracle Clusterware and Oracle Grid Infrastructure (Doc ID 1096952.1)》 | RAC作为重要基础架构技术，在Oracle数据库私有云计算中至关重要。这篇文章就是RAC技术资源的汇集地。 |
| 5. | Oracle 11g R2联机文档 | 《Oracle® Real Application Clusters Administration and Deployment Guide》 | 该文档全面介绍了RAC 管理和实施，例如多个章节均讲述了Service的概念、运用和管理。 |
| 6. | My Oracle Support | 《Master Note for Automatic Storage Management (ASM) (Doc ID 1187723.1)》 | ASM为实施云计算的存储资源整合提供了良好的平台。这篇文章就是ASM技术资源的汇集地。 |
| 7. | My Oracle Support | 《Configuring and Monitoring Instance Caging (Doc ID 1362445.1)》 | 什么是Instance Caging？如何配置？如何监控其使用过程，以及如何优化？请看这篇文档。 |
| 8. | My Oracle Support | 《Master Note: Overview of Oracle Resource Manager and DBMS_RESOURCE_MANAGER (Doc ID 1484302.1) 》 | Resource Manager技术在数据库云计算平台的精细化管理中起到了重要作用，这篇文档就是各类Resource Manager资料的汇集地。 |
Leave a Reply