基于Oracle的私有云架构探析（连载三）@【DTCC干货分享】
Instance Caging 通过设置2个数据库的初始化参数来达到管控CPU的目的：
• cpu_count
• resource_manager_plan
这两个初始化参数都可以在线修改不用重启，这为我们管控CPU资源的分配提供了极大的灵活性。在实施Instance Caging前，我们需要数据库有一个resource manager plan，如果你当前的数据库还没有resource manager plan，也可以启用默认的。
注意：如果是RAC数据库，那么上面的语句将会在RAC的所有实例生效，确认这是你希望的结果，否则在alter system语句中增加sid='xxx'参数。在开启管理计划后，数据库的后台进程VKRM会开始运行。
如果要确认instance caging功能已经生效，可以使用下面的语句确认：
剩下的事就是设置你的实例可以使用的CPU的个数了。先检查下当前数据库的CPU个数：
我的主机上有40 core逻辑CPU，真实的CPU物理core其实是有20，由于采用了CPU的超线程技术，所以主机上看到的CPU数量是40.可以根据业务需要来设定实例可以使用的CPU个数。例如下面的语句设置让本实例最多可以使用到20个CPU资源。
开启了instance caging，它就会发挥作用，限制单个实例的cpu使用数量。可以通过vrsrcmgrmetric，v$rsrcmgrmetric_history视图来获得Instance Caging的参考数据，它提供以分钟为单位的CPU使用情况和过去一小时的CPU流量反馈。
•Instance Caging实践
准备脚本，目的是为了消耗CPU：
a.sh脚本：开启60个并发执行test.sql
脚本准备好后，就可以让它在后台跑了。
开始实验
这里先不对cpu_count做任何限制，看看CPU最多能使用到多少
几乎使用了所有的CPU资源，接下来通过调整cpu_count的值来观察资源管理是否会起作用，先调整到20，也就是逻辑CPU数的一半
Instance Caging在发挥着作用，从操作系统监控CPU的资源使用情况非常清楚的看到CPU的使用率在50%上下。
再调整成10看看，也就是CPU的1/4数量
和预期的一样，使用了25%的CPU资源。Instance Caging很好的发挥了作用。Good Job ！
• 如何为每个实例分配CPU资源
读者可能会有疑问，我能不能给一台主机上的实例分配的CPU资源超过总的逻辑CPU数，答案是可以的。但就核心数据库来说，并不建议去过量分配CPU。如下图，推荐为每一个实例按照工作负载来去分配CPU，分配CPU的总数等于逻辑CPU的数目。当然就像下图中所注释的，如果已经分配给实例的CPU，实例非常的空闲，无任何的压力，那么这些CPU会被浪费，别的实例一旦想要使用也不能使用。
如果是开发、测试、QA一些边缘库，可以根据实际情况，酌情为主机上的实例分配的CPU之和大于主机的逻辑CPU数，使用这种分配方式的风险就在于一旦几个实例的负载同时上来，可能会出现CPU的争用问题，但是它的优点也是非常的明显，在限制资源的同时可以更加充分地利用主机的CPU资源。这种方式推荐在非核心库上使用，
• 内存资源隔离
对于内存使用量的隔离比较好做到，只需要在每个实例间通过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，以及使用它的好处是什么。
• 构建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.
最终的分配结果如下图所示。
• 创建基于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
• 基于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的资源隔离的功能。
如上图，CDB中一共存在3个PDB：Sales、Marketing、Support，使用资源管理器对这3个PDB做了一定的资源限制。Sales可以使用到最多90%的CPU资源，在主机资源不够用的情况下，需要保证50%的CPU资源，这一点上倒是比Instance Caging更灵活，同样Marketing和Support是一样的，作者不再给出详细说明。
• 架构设计与SLA定义
前面的章节已经讲解了种种构建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方法论的提倡者和践行者。
其它白皮书
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
完结