基于Oracle的私有云架构探析
基于Oracle的私有云架构探析
云是当今最为热门的一个话题或者说技术，在数据库界也一样，Oracle 12G这个名字不硬生生被掰弯成了Oracle 12C,数据库云在我看来能给企业带来的第一价值是节省资源，提高服务器资源的利用率，随着更快速CPU、更廉价大内存的出现，企业传统孤岛式的数据库使用方式，一个主机一个实例，会导致大量的资源浪费，想当年在阿里B2B，有多少服务器的CPU利用率平均只有15%，现在都在倡导绿色数据中心，只有数据库整合了，消耗的电少了，空调吹的少了，数据中心才能绿，地球才能绿（人可不能绿😊）。在电刚出现的时候，每个富豪家里都得买个发电机装家里，昂贵，噪声大，扰民，还不环保，后来慢慢发展成电网，每一家只需要接入电网就可获取电资源，不用去买发电机，现在的云很大程度上跟这个很像，私有云平台就像电网，用户只需要接入云平台，就可以便捷的获取资源。本篇文章主要讲解如何构建一个Oracle的私有云平台，主要从以下三个方面进行论述：
- 数据库整合技术的选择
- 资源快速供应
- 服务质量管理
在开始阐述这三部分内容之前，有必要带各位客官了解一些数据库的部署现状和相关的基本概念，例如DBaaS是什么？为什么要用Oracle RAC来构建DBaaS。以及Oracle RAC的版本的一个发展历史。
本文都指的是私有云
DBaaS
当今一些中大型企业有着成百上千的数据库，这些数据库可能有着不同的版本，不同的配置，甚至是在同样的大版本下打着不同小版本补丁，这给企业带来了非常大的成本和负担：管理的成本、运维的成本、人员的成本、机房的成本、数据库软件licence的成本、存储的成本等等，用一句话概括就是TCO的成本非常的大。此外，由于传统的孤岛式的数据库使用方式，也导致了数据库数量的激增和非常糟糕的敏捷性，每上一个业务，就要申请一批设备，一个机柜，一个数据库项目从立项到项目实施完成往往需要几周甚至几个月之久，如下图。
0DEF97AA-7D71-43F1-9850-775A7813C1FF.png
由于非标准化的东西非常多：硬件环境多变、配置多变、架构多变，这给数据库的可用性带来了非常大的风险，由这些风险带来的非计划性的停机也给企业带来了直接或间接的经济损失、企业信誉的损失。由于近些年PC服务型的CPU性能越来越强劲，内存的价格越来越低，企业往往采购的服务器配置相对都较高，而很多企业还采用着一个主机只部署一个实例这种方式，导致了数据库服务器的资源利用率非常的低下。根据GOOGLE的数字，28%的用户平均每年的数据库增长超过20%，50%的用户数据库是没有经过整合的。怎么办？
什么是DBaaS?
以上面临的场景和解决方案就是构建一个企业的DBaaS平台对数据库进行标准化整合，DBaaS 是一个标准化的、弹性可扩展的平台，基于网络访问，通过一系列共享的数据库服务，整合现有应用，以及快速部署新的应用。DBaaS私有云是部署于企业防火墙内的共享的数据库服务。DBaaS一方面用来满足开发、测试、QA的数据库服务要求，通过简单易用的自服务来满足申请数据库，schema等的需求。一方面帮助IT人员、DBA简化了数据库在标准平台上的部署，减少维护工作，更好的支持客户需求，更多的时间和预算用于创新。
RAC发展史概述
对于Oracle公司来说，构建数据库云的重担会落在RAC上，RAC天然具有高可用、可扩展的特性，RAC版本变化与Oracle一样，经历了从I时代到G时代C时代，I是Internet，G是Grid，C是Cloud，可以看出来Oracle的版本非常迎合时代标签，这个G稍微有点悲剧，其实跟云的概念非常像，但是最终Grid还是不敌Cloud包装的好，最终还是得投入了云的怀抱。Oracle 10G，11GR1虽然都以G冠名，但是产品层面其实并没有得力的配套技术，比如截止到11GR2之前，用户使用RAC，客户端还需要在连接描述符里配置多个条目：
GOBO1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.7.61)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.7.62)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.7.63)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = GOBO1)
)
)
Grid的概念类似于电网的概念，作为用户只需要通过像插头这样的工具接入电网即可，不用去知道后面有多少发电站。对于11GR2之前的RAC来说，如果集群的节点数发生了变化，还需要把客户端里配置都更新一遍，实在是很麻烦。所以Oracle到了11GR2版本发明了SCAN- Single Client Access Name，用户只需要使用SCAN Name，在连接描述符里配置一个条目就可以了：
GOBO1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = scan_name)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = GOBO1)
)
)
不管集群有多大，都只需要配置这么一行描述符就可以（ADDRESS所在行）。如同你使用Google，不管谷歌后台有多少台服务器，你都只需要输入google.com，你不需要关心到底是后台的哪个server为你提供的服务。
以前客户选择使用RAC，大多数是由于单实例的性能不足，可用性不够，现在云的概念如日中天，使用RAC的理由可能已经演变为建数据中心，做数据库的整合。下图为Oracle各个版本的一些核心特性图：
E8A2C5BB-F4D2-45B2-BF0E-4FD555DA7216.png
Oracle的核心功能在8I时就已经基本稳定下来了，但是这句话用在Oracle RAC产品上并不妥当，如上图，在Oracle 8I时，Oracle RAC只能算是初具雏形，当时的名字还不叫Oracle RAC，而是叫OPS-Oracle parallel server，在这个版本里，Oracle推出了自己的动态锁管理机制，Cache Fusion也已经出现，对于多个节点间的读读操作都已经能够完全在内存中实现，但是多实例之间的写操作仍然要通过磁盘作为媒介。Oracle 9I版本，出现了GRD-Global Resource Directory，Cache Fusion算法变得成熟，充分利用了私有网络的带宽，通过集群的私网来传递数据块包括脏数据块，真正的实现了内存融合。RAC区别于单机的最大一点是集群间需要协商，通过协商来保证多个实例的行为一致，而GRD、DML、Cache Fusion是实现协商的最重要技术，从Oracle RAC 8I到9I，RAC的这几个核心功能变得成熟，但是不管是Oracle 8I还是9I，Oracle都没有自己的集群件产品、没有自己的存储解决方案，都要借助于第三方厂商的集群件产品和存储解决方案，例如IBM，veritas等。但是到了Oracle 10G版本，霸气显露，Oracle已经不满足于RAC数据库本身了，一口气推出了自己的集群件Oracle ClusterWare 和存储管理软件ASM，并且Oracle ClusterWare在对外宣传上不仅支持Oracle，还提供了API接口支持其他类型的APP。鉴于RAC是shared nothing的技术架构，共享存储和集群文件系统变得非常的迫切，在10G之前的版本，用户必须借助于第三方的存储解决方案，例如veritas等第三方产品，无形中增加了产品的复杂度，因此在9I版本裸设备倒成了一个很大众化的选择。而10G出现的ASM解决了这一困境，ASM本身集卷管理和文件系统功能与一体，让Oracle真正的具有了管理卷，管理文件的能力，不过这个版本下的ASM有点像是“备胎”的味道，毕竟是新技术，不成熟，很多DBA那时候还不敢用它。到了11GR1这个版本，单就Oracle RAC来说，非常让人失望，几乎没有任何大的功能创新，似乎是为了保证每五年左右推出一个大版本下的产物，集群所有的核心功能都没有任何改变，不过对于旧的功能像是ASM，在这个版本变得较为稳定，而且也越来越多被DBA所接受。到了11GR2发行后，一堆亮瞎眼的功能出现，似乎让我们想明白了为什么11GR1会没什么新特性，因为11GR2发布的这些新特性是一揽子的云化解决方案：RAC One Node ,ServerPool ,Scan,Instance Caging、ACFS等等这些新技术都是为数据库整合，为云而生的，之前的ClusterWare也在11GR2版本被重新包装成为了Grid，ASM也被整合进Grid中作为集群的基础组件。后续的章节，我们也会对其中一些关键的技术做详细的讲解。到了12C版本，Oracle推出了Flex Cluster ,Flex ASM，更大程度提高了RAC的可用性和可扩展性，IN-Memory的出现也更让实时计算变得可能，CDB让数据库整合的方式更加多样，密度也可以更大。从以上RAC的发展史可以看出来，从11GR2版本开始，Oracle开始真正的从产品层面配合云的概念，我们本文讲解的技术也都是在11GR2之后出现的技术。
数据库整合技术
整合所需要的硬件平台
QDATA.png
云的核心是整合，既然要做数据库的整合，对于平台的整体能力要求会比较高，这个能力不但包括性能，对于可用性、可扩展的要求都会比较高。笔者认为做数据库整合的理想平台是一体机平台，像Exadata、QData，但是Exadata的价格实在是过于昂贵，性价比非常低，一般用户难以负担得起。笔者所在的沃趣科技是一家业界知名的做高性能解决方案的公司，我们是国内最早开始做一体机的厂商，QDATA一体机也是我们的明星产品，价格上相对于Exadata优势很大。很多朋友会问到，Exadata最为亮眼的地方是它的存储卸载功能，你们QDATA一体机有吗？对于这点我本人实在不敢苟同，试问有多少客户真的从卸载功能里受益非常大？就像Oracle 12C 推出了IN-Memory，理论上可以提升几十上百倍的性能，但是我去的几位客户那里做性能调优，发现客户业务系统的SQL并没有因为使用了IN-Memory而变快，因为使用IN-Memory有一些前提条件，而客户系统并不满足这样的前提条件，其实不管是针对In-Memory还是存储卸载功能，都需要DBA做一定的技术学习和精细化的调优工作，否则想发挥出它的能力是很难的，而且很多业务本身并不适合用这些特性，因此并不是上了这个IN-Memory或者卸载就能得到巨大的性能提升，例如使用上存储卸载必须要全表扫描，而你的SQL可能使用到了索引，那么你就要考虑是否需要把这个索引干掉以用到卸载功能，而这个索引是不是能被干掉，你又不确定，怕其他SQL引用这个索引，这种情况可能在客户那是一种非常普遍的情况。就我这些年的从业经历来看，传统的数据库架构最大的问题是它的整体性能不匹配，例如传统IOE架构最容易成为瓶颈的地方，不是CPU、Memory，而是IO，笔者在沃趣工作的不到两年里，接触了N多客户的性能瓶颈，很多都是IO问题（还有少数是索引没优化好）。对于热点数据较多较离散的OLTP系统来说，最为关注的是IO的延迟和整体的IOPS，而传统架构大多跑在机械盘上，因此IO的延迟非常大，并且机械盘能够提供的IOPS也非常的低，因此传统架构对于OLTP的支持就有明显的瓶颈，我们的QDATA一体机是通过使用全SSD闪存或者FLASHCACHE方案来加速IO的读写时间，解决IO性能瓶颈。而对于OLAP系统来说，最为关注的是数据库系统能够提供的IO吞吐量，传统IOE架构，吞吐量往往在几百M到1，2GB的量级，因此吞吐量就成为明显的瓶颈，Exadata通过使用infiniband网络来解决存储到计算节点的IO带宽的问题，同样对于我们的QDATA也是通过使用infiniband来提供高带宽。在传统架构中，由于性能组件之间配置的失调，导致了很多资源虽然非常的充足但是根本利用不到，就如刚才分析的，IO成为瓶颈后，即使CPU资源再富足，也没法利用到，因为都在等IO。而新的高性能解决方案，如一体机产品，基本都是聚焦于解决传统架构里性能组件之间失调的问题，让IO延时、IO吞吐、CPU、内存这些性能组件更加好的匹配在一起，不会在任何一点上成为明显瓶颈。而一体机作为一款高性能解决方案，完全符合了这些要求。它能提供的IOPS动辄几十万，几百万，IO吞吐更是轻轻松松几十GB，特别是随着100Gb的infiniband的出现，一体机能够提供的吞吐量会更加的大。我相信一体机的市场以后也会越来越大，不管是用它做私有云，还是为核心业务保驾护航，都是一个非常值得考虑的选择。同时一体机产品因为都是预先集成与优化的，这里面包含了我们十几年的运维经验和性能优化经验，例如我们对高TPS的系统预先做了REDO写的优化，把REDO放在了具有RAID卡缓存的磁盘上，保证日志的写延迟足够的稳定足够的低。
作为一名技术人员非常喜欢聊一些炫酷的技术，例如Exadata的卸载，我也是如此，如果你有兴趣，我可以跟你滔滔不绝聊上一整天的Exadata，理论上讲起来非常的浪漫和美好，但是现实情况比较残酷，很多甲方DBA认为上了Exadata后利用卸载功能就能让查询快的飞起来，结果大失所望。学习Exadata的成本非常高，并不是一种用了就能好的万能药。如果你有比较强的DBA团队，还有大把的钞票，还是可以考虑使用下Exadata的，如果你的DBA团队暂时还达不到这个要求，那么建议还是不要花这冤枉钱。
Exadata的卸载看似一项跨时代的创新，其实不然，它其实是向MPP架构致敬的一项功能，Oracle的Share Everything 的架构导致了存储一定需要是共享的，进而导致计算与存储必须分离，这种架构里存储不具备MPP架构中，每个节点都能处理数据的能力，因此Oracle的Exadata的出现一定程度上解决了这个问题，让存储节点在某些条件下具备了处理数据的能力。
数据库整合方案比对
5C2A09D8-CD6D-4AB9-9A4E-7B79AED752C5.png
虚拟化一度成为一种流行的数据库整合的方案（特别是MYSQL、PG），但是它的弊端非常的明显，虚拟化整合方案需要额外管理更多的OS，而且虚拟化本身会带来IO性能的大幅度衰减，因此性能上比较差，能够整合的数据库的密度也就比较小，不过就隔离性来说，由于每个虚拟机都有独立的OS，因此除了共享宿主机以外，OS，实例等等都是隔离的，很多用户选择这种整合方案很大程度上也是被它的强隔离性所吸引。单机多实例也是很多客户在使用的整合方案，在一个主机上部署多个实例，由于共享了主机和OS，性能损耗小，因此整合的密度可以比较大（相对于虚拟化整合），而且通过11GR2的Instance Caging技术可以做实例间CPU资源的隔离，由于单机多实例方案比虚拟化整合方案多共享了OS这一层，因此隔离线上相对于虚拟化方案来说，降低了一些，不过上面已经提到通过Instance Caging技术可以做到CPU的隔离。多schema方式的整合，就我们接触到的客户来说，也有客户在用，它的缺陷非常的明显，资源隔离不好做，业务上限制也比较大，同名的schema怎么做整合？几个schema间创建的一些公共权限有冲突怎么办？而且本身由于在一个数据库内，数据库的权限隔离也比较难做，就隔离性来看，因为共享了主机、操作系统、实例，它的隔离级别非常低，从长远来看，后期如果要做拆分，只能使用逻辑迁移，而逻辑迁移往往是非常复杂的。Oracle在12C版本发布了可插拔数据库，它是一个优缺点都比较中和的解决方案，相对于单机多实例来说，它的隔离性没那么强，但它整合的密度可以做到非常的大，因为它像schema整合方案一样，共享了主机、OS、实例（下图），因此性能损失非常的少，总体上，它的隔离性和安全性又比schema方案要强很多，因为本质上每一个PDB都是一个完整独立的DB，DB之间没办法互相访问，除非通过DBLINK这样的工具。
以上种种，笔者推荐的整合方案是基于单机多实例或基于12C的可插拔的方案，但是12C毕竟目前使用的人还不多，因此需要仔细考虑BUG带来的一些风险。
RAC One Node
根据整合的数据库的SLA要求，还需要决定整合数据库所选用的数据库类型，在数据库的类型上，11GR2版本之前，要不是单实例要不是RAC，单实例不具有HA的功能，只能做冷的HA，通过使用类似HACMP之类的软件进行切换，有不可用时间，而且由于引入了第三方的HA软件，让整个架构、运维变得复杂，如果使用RAC架构，那么对于数据库整合来说，显得有点资源浪费，RAC要求至少是双节点，对于整合的数据库来说，一般都是非核心库，往往压力不大，对于高可用的需求也没有那么高，因此使用RAC显得有点浪费，那么有没有一种折中的方案呢？既然Oracle的ClusterWare一个很重要的功能就是为其上的资源提供监控、故障处理、故障切换服务，为什么不能在ClusterWare之上跑单节点的RAC，然后在发生故障后对资源进行尝试重启，如果重启不成功，在另外的节点再进行实例的拉起。RAC One Node就是这样一种技术，顾名思义，RAC One Node是单节点的RAC，它跑在GI之上，通过GI基础组件实现HA，借助于GI集群件，RAC One Node作为其上的资源在发生故障后，可以尝试进行重启或切换，这一切都会自动完成，而不需要人工干预。RAC One Node除了能做故障切换外，还可以实现有计划性的在线漂移。漂移过程中，会阶段性的存在2个实例，等旧实例上的事务都完成后会被关闭，然后新实例对外提供服务。客官可能会问，在线迁移有啥用？做了数据库的整合后，一台机器上可能跑的就是多个数据库实例了，如果发现某些机器上的负载比较高，那么就可以使用RAC One Node的在线迁移功能，把负载较高的主机上的一些实例在线的迁移到其他负载低的机器上。仔细想想，Oracle能做到这一点还挺不容易的，因为里面涉及到了一些技术细节，只是你还没认识到。11GR2之前，增加实例是一个复杂的过程：
3FAEDDF7-CF17-4C78-B8A9-62695DD6607E.png
增加了一个RAC 实例，需要经过上面一系列的繁琐的操作。但是11GR2后，RAC One Node的在线迁移，本质上其实就是Oracle自动在另外一个节点帮你增加了一个实例，而创建REDO THREAD，UNDO这些事情它都已经帮你做好了，不用DBA再去干预做什么。
不过这里需要强调，RAC One Node是单节点的RAC，在发生故障后才去做切换的，也就是cold failover，那么实例在发生故障后其实是有不可用的时间的，所以对于RAC One Node的使用场景就是那些对于可用性要求不是那么高的应用场景，毕竟对于任何企业来说，不是所有的数据库可用性要求都是零RTO,RPO，因此找对合适的应用场景，RAC One Node就大有用武之地，它占用的系统资源更少，整合的密度可以更大，而且具有HA。下面我会详细讲解下RAC One Node的几个特性：在线漂移、故障切换、弹性伸缩。
在线漂移
数据库一旦做了整合，一个主机之上就可能会有多个实例，实例之间可能会互相影响性能，如果DBA发现某台主机上的负载较高，或者由于其他原因需要对RAC One Node进行节点迁移，就可以使用RAC One Node的在线漂移功能，DBA通过命令人为的把数据库实例迁移到其他机器上运行，在迁移过中，RAC One Node会等待旧的实例上的事务完成，同时在目标机器上启动一个新实例，在迁移这段时间内，会有两个实例以active-active双活的模式运行，当旧实例上的事务都完成后，这些连接会被转移到新的实例上来，一旦所有的连接转移工作都完成后，旧实例会被关闭，整个转移过程也完成了。
RAC One Node的在线漂移时间窗口默认为30分钟，在这段时间内，Oracle会等待旧实例上的事务完成，如果超过这个时间窗口后，还有事务未完成，那么会被强制取消，实例也会被强制关闭，可以通过srvctl命令增加-w参数来增加或减少这个默认的时间窗口。
漂移的命令是通过srvctl来完成的，具体用法如下：
srvctl relocate database -d <db_unique_name>
{[-n <target>] [-w <timeout>]|-a [-r]} [-v]
其中的参数机器说明如下
- -d：数据库的名称
- -n：目标节点
- -w：等待旧实例事务完成的时间窗口
- -a：放弃失败的在线漂移
下面给出一个在线漂移的例子，让读者更为直观的感受一下在线漂移的过程。本例中会把oltp8从节点RAC2迁移到目标节点RAC1.首先观察一下数据库的当前状态是否正常
srvctl status database -d oltp8
Instance oltp8_1 is running on node rac2
Online relocation: INACTIVE
oltp8为RAC One Node只有一个实例oltp8_1，当前运行在节点RAC2上，在线漂移的状态为INACTIVE。接下来我们对RAC One Node进行在线漂移，这是通过srvctl的relocate语法来完成的
srvctl relocate database -d oltp8 -n rac1 -w 5
漂移过程中，另开一个会话观察漂移的状态
srvctl status database -d oltp8
Instance oltp8_1 is running on node rac2
Online relocation: ACTIVE
Source instance: oltp8_1 on rac2
Destination instance: oltp8_2 on rac1
输出的信息非常的详细，oltp8_1这个实例正运行在RAC2上，ACTIVE关键字说明在线漂移也正在进行中，漂移的源端为RAC2，目标端为RAC1，并且目标端的实例名发生了变化：oltp8_2。
漂移完成后再查看状态，在线漂移状态已经为INACTIVE，实例oltp8_2也已经运行在新的节点上了
srvctl status database -d oltp8
Instance oltp8_2 is running on node rac1
Online relocation: INACTIVE
这里补充一个小细节，上面我已经提到过，这种在线漂移实例名是会发生变化，其实内部的操作就是在另外的节点帮我们自动的增加了一个实例，手工增加过实例的朋友都知道增加实例一般需要增加redo thread,增加undo表空间，那我们来看看，Oracle自动帮我们增加的实例有没有帮我们来搞定这些事
TABLESPACE_NAME TOTAL_MBYTES USED_MBYTES FREE_MBYTES PCT_FREE
------------------- ------------ ------------ ------------ ------------
SYSAUX 1080.00 1021.69 58.31 5.39
UNDOTBS1 145.00 31.25 113.75 78.44
USERS 5.00 1.69 3.31 66.25
SYSTEM 810.00 802.81 7.19 .88
UNDOTBS2 25.00 2.44 22.56 90.25
WXH 10.00 1.00 9.00 90.00
------------ ------------ ------------
2075.00 1860.88 214.13
上面的内容显示，有2个undo表空间，undotbs1 是之前oltp8_1实例用的，而undotbs2是新增加的。不过遗憾的是，这个undo表空间比较小，一般难以满足我们的要求。这里告诉大家一个小技巧，可以创建完RAC One Node后，手工增加undo表空间和redo thread，Oracle非常的智能，下次做实例漂移，它会自动使用上你手工创建的这些redo thread和undo表空间了，而且大小也都符合你的要求。
SQL>select group#,thread# from v$Log;
GROUP# THREAD#
---------- ----------
1 1
2 1
3 2
4 2
SQL>select group#,member from v$Logfile;
GROUP# MEMBER
---------- -----------------------------------------------
2 +OCRVOTE/OLTP8/ONLINELOG/group_2.265.907239997
1 +OCRVOTE/OLTP8/ONLINELOG/group_1.256.907239995
3 +OCRVOTE/OLTP8/ONLINELOG/group_3.264.907240291
4 +OCRVOTE/OLTP8/ONLINELOG/group_4.263.907240291
同样,redo thread也都帮我们创建好了，包括对应的日志文件。
故障切换
RAC One Node不但可以做有计划性的在线漂移，同时对于主机等故障发生后，通过GI的HA组件把失败主机上的实例迁移到其他节点，不过这种迁移有不可用时间。
下面我们通过杀死CRS进程的方式，模拟主机故障，来观察RAC One Node的故障切换。
oltp8正在运行的节点1上，在节点1上杀掉CRS进程
ps -elf | egrep "d.bin|ohas|oraagent|orarootagent|cssdagent|\
cssdmonitor" | grep -v grep |awk '{print $4}' |xargs -n 10 kill -9
在RAC2节点上观察数据库的状态，实例已经为not running状态。
>srvctl status database -d oltp8
Database is not running.
Online relocation: INACTIVE
通过crsctl stat命令查看故障切换是否已经发生
>crsctl stat res -t
-------------------------------------------------------------------
Name Target State Server State details
-------------------------------------------------------------------
Local Resources
-------------------------------------------------------------------
ora.DATADG.dg
ONLINE ONLINE rac2 STABLE
ONLINE ONLINE rac3 STABLE
ONLINE ONLINE rac4 STABLE
-------------------------------------------------------------------
Cluster Resources
-------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
1 ONLINE ONLINE rac4 STABLE
ora.MGMTLSNR
1 ONLINE ONLINE rac2 169.254.198.57 192.1
68.100.2,STABLE
ora.cvu
1 ONLINE ONLINE rac2 STABLE
ora.oltp8.db
2 ONLINE OFFLINE rac2 STARTING
-------------------------------------------------------------------
从crsctl stat res -t的输出可以清楚看到，集群正在RAC2节点上尝试拉起实例。过2分钟再次查看，数据库已经完成故障切换，整个过程不到五分钟，非常的棒！
>crsctl stat res -t
---------------------------------------------------------------------
Name Target State Server State details
---------------------------------------------------------------------
Local Resources
---------------------------------------------------------------------
ora.DATADG.dg
ONLINE ONLINE rac2 STABLE
ONLINE ONLINE rac3 STABLE
ONLINE ONLINE rac4 STABLE
---------------------------------------------------------------------
Cluster Resources
---------------------------------------------------------------------
ora.oltp8.db
2 ONLINE ONLINE rac2 Open,STABLE
---------------------------------------------------------------------
虽然RAC One Node的HA是Cold Failover的，但是对于一些边缘、测试、开发环境，对于可用性要求不是那么高的环境，它都是一种非常好的整合方案。试想，有几个客户会把自己最为核心的数据库来进行整合呢？
RAC One Node扩展性
RAC和RAC One Node之间可以通过srvctl命令轻松的做转换，我们以把RAC One Node扩展成多个节点的RAC。这里给出转换的示例：
查看当前RAC One Node的运行状态
srvctl status database -d oltp8
Instance oltp8_1 is running on node rac2
Online relocation: INACTIVE
运行在RAC2节点上，运行状态正常。
使用srvctl convert命令进行转换，-c参数代表了要把RAC One Node扩展成标准的RAC。
srvctl convert database -d oltp8 -c RAC
转换完成后，查看数据库的实例状态
srvctl status database -d oltp8
Instance oltp8_1 is running on node rac1
Instance oltp8_2 is running on node rac2
非常好，Oracle帮我们自动增加了实例，而且增加的实例已经启动。需要注意，笔者的测试环境为12C，如果为11GR2，增加的实例需要DBA手工去启动。
就这样轻松的完成了RAC One Node到RAC的转化。
同样我们看如何来“缩”，把RAC 转化为RAC One Node，同样通过srvctl 命令来完成，-c参数代表了把RAC“收缩”为RAC One Node.
srvctl convert database -d oltp8 -c raconenode
PRCD-1154 : Failed to convert the configuration of cluster database oltp8 into its equivalent RAC One Node database configuration because cluster database is running on more than one server [rac1, rac2]
提示有2个实例在运行，看来需要关闭一个实例才能进行RAC到RAC One Node的转化
srvctl stop instance -d oltp8 -i oltp8_1 -f
srvctl convert database -d oltp8 -c raconenode
转换完成后，再次查看数据库实例的状态
srvctl status database -d oltp8
Instance oltp8_2 is running on node rac2
Online relocation: INACTIVE
oltp8已经只有一个实例在运行了。
从上面的实验过程中可以看出，RAC One Node具有非常好的可用性、伸缩性，而且这一切的操作都非常的简便。
到这里你已经对RAC One Node有了一定了解，由于是以单实例的状态运行，而且还具有非常高的可用性，那么用来做数据库的整合太合适了，整合的密度可以很大，适用于那些对于可用性要求没有那么的高的开发、测试、QA、边缘系统。
12C CDB
7B4B0661-A565-42A9-9B8C-FCA53F94E290.png
12C出现了容器数据库CDB，虚拟化整合方案共享了宿主机，多实例整合方案共享了宿主机和OS，而12C的容器数据库共享了宿主机、OS和实例，共享的层次越多，内耗越少，性能越高，整合的密度就可以越大，但隔离性上会弱一些，一旦实例层面出现问题，所有的PDB都会出问题。Oracle通过在12C增强了Resource Manager的功能来进一步提供PDB之间的资源隔离实现。由于PDB的创建可以基于模板和克隆，因此资源供应速度上得到了很大的提升。12CR1版本，一个容器数据库最多支持252个PDB,到了12CR2版本已经增强到4096个。笔者所在公司-沃趣科技也一直在研发12C的相关数据库平台和产品，就我们的使用测试情况来看，12CR1版本的BUG还比较多，有些BUG在MOS上还没有记录，因此建议不要着急上12C，等12CR2发布后再做决定。
资源快速供应
资源快速供应是DBaaS出现之后延伸出来的一个概念，意在用户通过自服务的方式去快速的获取资源。以前数据库简直就是世界的中心，想申请一个数据库资源从项目的立项到最终获得资源，要经过相对漫长的时间，所有人都要围着它转，而DBaaS做为一个大的数据库平台，有着“无限”大的可用性能、可用容量，因此只需要用户在云平台之上点点鼠标，就能完成资源的获取，Oracle 12C出现的容器数据库让资源的获取更加的快速和便捷，它本身通过数据库的模板来快速提供PDB。要实现资源的快速供应，你需要：
- 有一个强大的硬件平台，比如一体机产品
- 有一个云平台，开发、测试、QA可以便捷的在云平台之上完成资源的申请和获取
- 决定使用何种技术提供资源，PDB？SCHEMA？DB？
目前我们沃趣科技也是在研发DBaaS云平台产品DBPool，在其上可以方便的完成资源的申请、获取、使用、下线，资源的整个生命周期都可以在平台之上完成，可以极大提升获取资源的敏捷性，为企业的数据库提供一个标准化的操作平台。
服务质量管理QoS
数据库做了整合之后，面临着几个问题
- 资源隔离如何做，如果不做资源隔离，就难以保证数据库对外的服务质量，实例之间或PDB之间会互相影响
- 可不可以对资源进行灵活的调配，以满足不同业务，不同时间段的对资源的需求情况
CPU资源隔离技术Instance Caging
63BAFF98-F89C-46D0-9F8F-DE7BCCC97052.png
我们首先来看第一个问题，资源隔离如何做，如果资源是无限的，就不需要对他们进行管理，资源隔离是DBaaS里一个非常重要的概念，也是每一个DBaaS平台都需要去解决的核心问题。
以前使用Oracle的方式大多都是一台机器跑一个实例，但是数据库一旦进行整合，一台机器可能就不是跑一个实例了，而是多个实例，实例一多，一个现实的问题摆在面前：资源隔离如何做？
为了保证每个数据库实例的服务质量，你需要提前对每个实例分配资源，在它的整个活跃周期内都不能跑出给它分配的数据库资源。如果资源不加以不加限制，就可能出现这样的情况：一个优先级非常低的业务由于应用程序BUG进而导致侵占了主机上的绝大部分CPU资源，最终导致主机上其他重要度高的应用受到非常大的影响，业务被降级。如下图：
5D5733D0-248B-4341-ACFE-2EF3B0E99A95.png
Instance Caging就是这样的技术，用于CPU资源的管控，它能够管理CPU在实例间的分布，确保每个实例可以使用的CPU资源不跑出它的一亩三分地。
3A465B37-3996-4112-9DF7-5E499C68A706.png
Instance Caging相对于其他资源管理的技术，例如操作系统的Cgroup，它具有一些天然的优势
- Instance Caging是11GR2自带的功能，不需要额外安装软件
- 它是免费的，不需要支付额外的licence费用
- 由于是自带的功能，因此它能与Oracle数据库库高度的集成，可以感知到数据库内部的负载
- 最为重要的一点，它的使用特别的简便，请看下一节
12C版本可以利用数据库的参数processor_group_name结合LINUX Cgroup来一起使用，这部分内容本文不做详细介绍。
启用Instance Caging
Instance Caging 通过设置2个数据库的初始化参数来达到管控CPU的目的：
- cpu_count
- resource_manager_plan
这两个初始化参数都可以在线修改不用重启，这为我们管控CPU资源的分配提供了极大的灵活性。在实施Instance Caging前，我们需要数据库有一个resource manager plan，如果你当前的数据库还没有resource manager plan，也可以启用默认的。
alter system set resource_manager_plan = 'default_plan';
注意：如果是RAC数据库，那么上面的语句将会在RAC的所有实例生效，确认这是你希望的结果，否则在alter system语句中增加sid='xxx'参数。在开启管理计划后，数据库的后台进程VKRM会开始运行。
如果要确认instance caging功能已经生效，可以使用下面的语句确认：
select instance_caging from v$rsrc_plan where is_top_plan = 'TRUE';
INSTAN
------
ON
剩下的事就是设置你的实例可以使用的CPU的个数了。先检查下当前数据库的CPU个数：
show parameter cpu_c
NAME TYPE VALUE
---------------------- ---------------------- ----------
cpu_count integer 40
我的主机上有40 core逻辑CPU，真实的CPU物理core其实是有20，由于采用了CPU的超线程技术，所以主机上看到的CPU数量是40.可以根据业务需要来设定实例可以使用的CPU个数。例如下面的语句设置让本实例最多可以使用到20个CPU资源。
alter system set cpu_count=20;
一单开启了instance caging，它就会发挥作用，限制单个实例的cpu使用数量。可以通过v$rsrc_consumer_group，v$rsrcmgrmetric，v$rsrcmgrmetric_history视图来获得Instance Caging的参考数据，它提供以分钟为单位的CPU使用情况和过去一小时的CPU流量反馈。
Instance Caging实践
准备脚本，目的是为了消耗CPU
test.sql的内容
declare
L_N number;
begin
while ( true)
loop
L_N := dbms_random.random();
end loop;
end;
/
a.sh脚本：开启60个并发执行test.sql
#! /bin/sh
. /home/Oracle/.bash_profile
step=1
while [ $step -lt 60 ]
do
nohup sqlplus test/test @test.sql &
let "step+=1"
echo $step
done
脚本准备好后，就可以让它在后台跑了。
开始实验
这里先不对cpu_count做任何限制，看看CPU最多能使用到多少
sys@TEST>show parameter cpu_c
NAME TYPE VALUE
--------------------- ---------------------- ----------
cpu_count integer 40
SQL>alter system set resource_manager_plan = 'default_plan';
System altered.
SQL>select instance_caging from v$rsrc_plan
where is_top_plan = 'TRUE';
INSTAN
------
ON
/home/Oracle>vmstat -w 1
procs --------------memory------------------ --system-- -----cpu-------
r b swpd free buff cache in cs us sy id wa st
41 0 0 39065524 341360 17386716 2 5 1 0 99 0 0
42 0 0 39066200 341360 17386716 41851 11027 92 0 8 0 0
40 0 0 39066072 341360 17386720 41205 10284 92 0 8 0 0
40 0 0 39066144 341368 17386712 41420 10578 92 0 8 0 0
40 0 0 39066144 341368 17386720 41297 11481 90 0 10 0 0
40 0 0 39066284 341368 17386720 41795 11919 91 0 9 0 0
几乎使用了所有的CPU资源，接下来通过调整cpu_count的值来观察资源管理是否会起作用，先调整到20，也就是逻辑CPU数的一半
sys@TEST>alter system set cpu_count=20;
System altered.
/home/Oracle>vmstat -w 1
procs ----------------memory------------------ --system-- -----cpu-------
r b swpd free buff cache in cs us sy id wa st
20 0 0 39067484 341392 17386756 2 5 1 0 99 0 0
20 0 0 39067476 341392 17386760 25716 10551 50 0 50 0 0
20 0 0 39066980 341392 17386764 26138 11154 50 0 50 0 0
23 0 0 39067228 341392 17386764 26818 12372 51 0 49 0 0
20 0 0 39071444 341392 17386772 27138 12124 52 0 48 0 0
select to_char(begin_time, 'HH24:MI') time,
sum(avg_running_sessions) avg_running_sessions,
sum(avg_waiting_sessions) avg_waiting_sessions
from v$rsrcmgrmetric_history
group by begin_time
order by begin_time;
TIME AVG_RUNNING_SESSIONS AVG_WAITING_SESSIONS
10:03 21.9687333 43.8441667
10:04 20.58455 38.56545
10:05 20.4874333 38.5253333
10:06 20.53805 38.54745
Instance Caging在发挥着作用，从操作系统监控CPU的资源使用情况非常清楚的看到CPU的使用率在50%上下。
再调整成10看看，也就是CPU的1/4数量
sys@TEST>alter system set cpu_count=10;
System altered.
/home/Oracle>vmstat -w 1
procs ---------------memory------------------ --system-- -----cpu-------
r b swpd free buff cache in cs us sy id wa st
10 0 0 39069604 341388 17387168 2 5 1 0 99 0 0
10 0 0 39069416 341388 17387168 16653 11306 25 0 75 0 0
11 0 0 39069292 341388 17387168 15504 10032 25 0 75 0 0
10 0 0 39069416 341388 17387244 15822 10124 25 0 75 0 0
11 0 0 39069540 341388 17387248 16079 10413 26 0 74 0 0
11 0 0 39069416 341388 17387248 16779 11280 26 0 74 0 0
select to_char(begin_time, 'HH24:MI') time,
sum(avg_running_sessions) avg_running_sessions,
sum(avg_waiting_sessions) avg_waiting_sessions
from v$rsrcmgrmetric_history
group by begin_time
order by begin_time;
TIME AVG_RUNNING_SESSIONS AVG_WAITING_SESSIONS
---------- -------------------- --------------------
10:00 14.0004833 45.4167667
10:01 14.0001833 48.5537833
10:02 14.0001333 48.2055167
和预期的一样，使用了25%的CPU资源。Instance Caging很好的发挥了作用。Good Job ！
如何为每个实例分配CPU资源
读者可能会有疑问，我能不能给一台主机上的实例分配的CPU资源超过总的逻辑CPU数，答案是可以的。但就核心数据库来说，并不建议去过量分配CPU。如下图，推荐为每一个实例按照工作负载来去分配CPU，分配CPU的总数等于逻辑CPU的数目。当然就像下图中所注释的，如果已经分配给实例的CPU，实例非常的空闲，无任何的压力，那么这些CPU会被浪费，别的实例一旦想要使用也不能使用。
A9A37583-D14C-4657-BF7B-177CECEC39B0.png
如果是开发、测试、QA一些边缘库，可以根据实际情况，酌情为主机上的实例分配的CPU之和大于主机的逻辑CPU数，使用这种分配方式的风险就在于一旦几个实例的负载同时上来，可能会出现CPU的争用问题，但是它的优点也是非常的明显，在限制资源的同时可以更加充分地利用主机的CPU资源。这种方式推荐在非核心库上使用，
D8A4976B-FA29-451D-9FEB-56C01963924D.png
内存资源隔离
对于内存使用量的隔离比较好做到，只需要在每个实例间通过sga_target，pga_aggregate_target参数设置就可以做到实例间内存资源的隔离。需要强调的是，对于PGA的使用，Oracle 12C之前并没有硬限制，请仔细为数据库预留出足够的PGA空间，以防内存出现SWAP。关于内存分配的详细介绍，请参考我的另一篇文章（文章最后的白皮书部分有链接），这里不做赘述。
IO资源隔离
Oracle并没有直接提供IO隔离的技术(Exadata可以)，如果ASM中的盘有SSD,SAS不同介质类型，建议在ASM层面进行存储池的划分，例如高性能SSD的为一个DG，SAS的为一个DG，在进行DB创建过程中根据业务的特点去选择把DB创建于哪个存储池之上。
ServerPool
我们再来看，服务质量的第二个问题，发现集群需要扩容或缩容，如果做到敏捷？答案是可以通过serverpool来实现，11GR2之前建立RAC的时候，需要去选节点，实例与节点间存在一个强耦合的关系，如果某个节点的实 例挂掉了，也不容易迁移（需要一些复杂操作）到集群其他可用的节点上，Oracle把这种方式称为基于管理员的管理方式，11GR2之后出现了一种新的管理方式，基于策略的管理方式，而serverpool就是这种理念下的一个产物。资源和机器之间不再具有耦合性，资源“随时随地”都可用。使用基于serverpool的方式创建DB，DB是创建在预先定义好的serverpool之上的，DB的可扩展性受限于serverpool的属性设置。我们通过一个具体的例子来看看如何使用这种新的方式来创建DB，以及使用它的好处是什么。
31B5E3C2-D026-4DDD-B28B-0C6C7EF530E3.png
构建Grid集群
Oracle Grid是个集群，把多个服务器虚拟成一台服务器，这一层集群通过上面的各种应用体现价值，这些应用被叫做资源，Oracle数据库就是一种资源，虽然Oracle一直宣称GI作为一个集群的基础组件，上面可以跑各种资源，但是市场的归市场，技术的归技术，目前GI之上跑的绝大部分资源还都是Oracle数据库，以上图为例，一共9个计算节点，组成了一个大的Grid集群,作为集群的基础组件，它本身具有HA、可扩展的特性，并且为其上层的应用提供监控、故障切换、心跳检测、节点成员管理等服务。上图中这9台机器需要装好Grid和Oracle Database的软件。
构建ServerPool
集群按照好后，就可以在这个Grid集群之上，创建serverpool，这里我们规划了4个serverpool：erppool,productpool,testpool,devpool，还有一个free pool（默认会创建）。
每一个serverpool都需要有一个定义，定义这个pool中主机数量的最小值、最大值、重要度。
- 最小值：定义serverpool中运行服务器的最小数量
- 最大值：定义serverpool中运行服务器的最大数量
- 重要度：Serverpool的重要度，只有相对意义，没有绝对意义，在计算节点分配阶段、计算节点故障后，重要度高的serverpool会优先被保证资源充足
我们现在对我们即将要创建的4个pool来规划好属性：
- erppool的属性：最小1个节点，最大2个节点，重要程度为3
- productpool的属性：最小3个节点，最大3个节点，重要程度为10
- testpool的属性： 最小1个节点，最大两个节点，重要度2
- devpool的属性：最小1个节点，最大两个节点，重要度1
集群在运行时，会根据serverpool的属性，动态的调整服务器在serverpool之间的分配，我们来看一下计算节点在serverpool上的分配规则：
- 按照Server Pool的Importance顺序，依次填充每个Server Pool，填充至Min个服务器。如果还有剩余机器，则进入到下一步。
- 再按照Server Pool的Importace顺序，依次填充每个Server Pool，填充至Max个服务器，如果还有剩余的机器，则进入到下一步。
- 再剩下来的机器进入到free pool中。
9个节点的集群安装完毕后，按照上面提到过的分配原则，看下我们这个例子中的分配过程：
- productpool的重要度最高，因此先满足它所要求的最小节点数量3
- 其次是erppool的重要度最高，因此满足它所要求的最小节点数量1
- 其次是testpool的重要度最好，因此满足它所要求的最小节点数量1
- 最后是devpool，满足它所要求的最小节点数量1
经过这一轮的分配后，还剩余3台机器，进入下一轮的分配：
- 满足serverpool的最大节点数量要求，同样从重要度最大的serverpool开始
- productpool的重要度最高，但是由于它已经满足了最大值要求，直接跳过，接下来是erppool，从剩余的4个节点中分配1个节点给它，满足它的最大节点数要求2
- 其次是testpool的重要度最高，再从剩余的2个节点中，分配一个节点给它，满足它的最大节点数要求2
- 最后是devpool，把仅剩的一个节点分配给它，这个时候已经没有多余的机器了，因此free pool中的机器数量为0.
最终的分配结果如下图所示。
31B5E3C2-D026-4DDD-B28B-0C6C7EF530E3.png
创建基于ServerPool的DB
serverpool创建完成后，就可以在serverpool之上去创建Oracle DataBase,旧的模式（Administrator-Based Management）在创建DB的时候，是选择节点列表。
基于Policy-Based Management的管理方式，db在创建的时候是选择serverpool。 你需要去问为什么要使用这种方式，能带来什么好处？接下来我们会讲到。
QoS服务质量保证
细心的同学可能已经发现了，我在定义serverpool的时候为每一个serverpool 不仅指定了最小值最大值要求，而且还指定了重要度，这个重要度是serverpool里一个很重要的概念。我们继续以上面的图里的内容为例，productpool是公司的核心生产库，它的重要度是最高的，而且对于这个pool的最小值要求是3，如果天有不测风云，productpool 里有天突然down了个节点，那么会发生什么呢？如果是基于ADMIN方式的管理模式，什么都不会发生，但是基于policy的管理方式，就不一样了，由于produdctpool的重要度最高，而且已经不满足了最小值要求，因此它会选择从其他重要度低的pool中拉过来一台机器，从哪拉呢？先从满足了最小值要求，而且重要度最低的pool里找机器，因此devpool就被盯上了，devpool不但满足了最小值要求，而且还多出了一个机器满足了最大值要求，因此强行把这个devpool里的一台机器拿走给了productpool，满足了productpool对于机器的最小值要求。productpool上面的资源，例如数据库实例在等这个机器加入到productpool后也会自动被拉起来，不需要DBA手工的干预，是不是非常的棒！等productpool之前故障的机器起来后，它会被放入freepool，然后发现所有的serverpool 除了devpool 都已经满足了最小值最大值要求，因此会把这个机器从free pool 中转移到devpool中，同样构建在devpool 里的资源也会被自动的拉起，不需要DBA手工的干预。
如果你还适应不了这么灵活的资源分配方式，那么可以通过把serverpool的重要度都设置成一样，这样就不会出现主机故障后，资源可能重分配的问题，而是通过DBA去决定是否通过修改serverpool的属性来达到资源重分配的目的。
弹性伸缩
使用serverpool的第二大好处是弹性伸缩的能力，继续以上图为例，如果某天业务上需要搞促销，生产环境压力会很大，DBA担心现有的服务器资源不够，那么就可以通过调整serverpool的属性值，自动完成生产环境的扩容，例如把productpool的最小值最大值数量从3调整为4，调整后，由于重要度最高的productpool不满足了它的最小值要求，因此会从重要度最低的pool中拿走一台来满足它的最小值要求，这里同样是从devpool中拉走一台，这台机器加入到 productpool后，上面的资源会被自动拉起，自动完成扩容，同样，促销结束后，通过修改productpool属性值，也会自动的完成收缩。从这里可以清楚的看出，RAC的可扩展性完全的依赖于serverpool的属性值。而之前旧的模式下，如果RAC需要扩容，需要去加实例，而加实例本身是一个比较复杂的过程，使用基于策略的管理之后，这些都会由Oracle自动帮你完成。
Policy Set
ServerPool在12C有一个新特性，可以建立一些策略集合，例如，某运营商有2个RAC集群，第一个RAC是用来做在线业务的，白天压力很大，需要5台服务器来满足业务的要求，而晚上压力很小，只需要2台服务器就能满足业务要求，第二个集群是用来做晚上的分析任务的，白天压力非常小，只需要2台就能满足业务要求，而晚上压力很大，需要5台服务器才能满足分析要求，那么基于这个情况，可以建立2个策略DAYTIME和NIGHTTIME，分别代表白天的策略和晚上的策略，再建立2个POOL，online 代表在线业务pool，DW代表数据仓库分析pool。这两个策略作为一个policy set，在白天时段，通过任务去触发DAYTIME这个policy，然后根据serverpool的功能自动完成服务器的分配和实例的拉起，在晚上时段，触发NIGHTTIME这个policy。很方便，是不是？
POLICY DAYTIME
Online： 最小值5，最大值5，重要度10
DW： 最小值2，最大值2，重要度10
POLICY NIGHTTIME
Online： 最小值2，最大值2，重要度10
DW： 最小值5，最大值5，重要度10
crsctl modify policyset –attr “LAST_ACTIVATED_POLICY= DAYTIME”
基于ServerPool的RAC One Node
如果要使用RAC One Node来做数据库的整合，强烈建议使用基于ServerPool的方案，在ServerPool之上来构建RAC One Node。经过测试，传统的方式不能把多个RAC One Node实例在多个节点间做平均分配。例如9个RAC One Node实例，3个RAC节点，如果使用基于Serverpool的管理方式，那么这9个节点用DBCA创建后会比较均匀的分配到这三个RAC节点上，但是基于Administrator-Based Management方式，9个节点在用DBCA创建后会全部被分配DBCA运行的节点上。同样，在主机发生down机后，基于ServerPool的RAC One Node也表现出了这一点，故障节点主机上的数据库实例会比较均匀的分布到其他存活的节点上。
12C CDB的资源隔离
这里简单提一句12C中CDB的资源隔离，12C的CDB容器数据库本身是一种基于云而生，用来做数据库整合的一个解决方案，12C CDB的发布，配套着资源管理器也新增了基于PDB的资源隔离的功能。
3AA5602D-D514-4D89-A045-7AFFD39FBC6B.png
如上图，CDB中一共存在3个PDB：Sales、Marketing、Support，使用资源管理器对这3个PDB做了一定的资源限制。Sales可以使用到最多90%的CPU资源，在主机资源不够用的情况下，需要保证50%的CPU资源，这一点上倒是比Instance Caging更灵活，同样Marketing和Support是一样的，作者不再给出详细说明。
架构设计与SLA定义
FF459163-3A30-42B8-9B32-6EB0C545DC0D.png
前面的章节已经讲解了种种构建DBaaS私有云可能使用到的技术，最终的架构设计还是要依据企业对于数据库SLA等级定义、根据实际的业务需要来决定使用何种架构、何种技术做整合，如果对于RPO，RTO要求非常的高，几乎不能有任何的不可用时间，那么我推荐使用基于RAC的方式来构建整个私有云，结合Instance Caging和Resource Manager做资源隔离，结合ServerPool来实现RAC的灵活伸缩以及QoS质量保证。数据库的整合方案建议使用单机多实例的方案，12C的容器数据库目前还需要有人去踩坑，缺少最佳实践。
如果业务对于RPO,RTO要求没那么高，数据库的负载也比较小，允许一小段时间的集群不可用，那么我推荐使用RAC One Node来构建私有云，同样，结合Instance Caging和Resource Manager做资源隔离，结合ServerPool来实现RAC的灵活伸缩以及QoS质量保证。
最后需要说明，混合可能是一种常态，现在都流行混搭、跨界，技术界也一样，什么混合云不就是混搭吗，架构设计也一样，你可以把私有云架构设计成一种混合的架构，既有高可用的RAC架构，也有RAC One Node这种可用性没有那么高的架构，两种架构同存于一个架构中。😊
关于作者
魏兴华，沃趣科技高级技术专家，主要参与公司一体机产品、监控产品、容灾产品、DBaaS平台的研发和设计。曾就职于东软集团，阿里巴巴集团，Oracle ACE组成员，DBGEEK 用户组发起人，ITPUB认证博客专家，ACOUG、SHOUG核心成员。曾在中国数据库大会、Oracle技术嘉年华、ORCL-CON、YY分享平台等公开场合多次做过数据库技术专题分享。对Oracle 并行机制、数据库异常恢复方法、ASM等有深入的研究，人称”Oracle Internal达人”，对企业数据库架构设计、故障恢复、高并发下数据库性能调优有丰富的经验，擅长从等待事件角度分析解决数据库性能问题，是OWI方法论的提倡者和践行者。
DB GEEK QQ 群: 516293316
公司主页:www.woqutech.com
其它白皮书
SQL MONITOR:
http://pan.baidu.com/s/1gfO2DtL
Parallel原理实现：
http://pan.baidu.com/s/1i5xun9F
12C IN-MEMORY：
http://pan.baidu.com/s/1ge7r1oZ
Oracle Memory Management and HugePage:
http://pan.baidu.com/s/1dFdPLEp
基于Oracle的私有云架构探析
http://pan.baidu.com/s/1c2sgONm
