Oracle Policy-Managed Cluster – Growing for DBaaS

作者：张乐奕

2014 年 12 月发布

Policy-Managed Cluster 在Oracle 11gR2 中被引进，在 Oracle 12c 中使用 dbca 创建 RAC 数据库的时候，Policy-Managed 选项已然成为默认值。

那么到底什么是 Policy-Managed 方式的集群和数据库呢？与以前的 Admin-Managed 方式有何区别？何种环境适合使用这种新的方式进行管理？本文尝试回答这些问题，并且做出简单的测试。

什么是 Policy-Managed 方式？

基于策略的管理方式，是以服务器池 (Server Pools) 为基础的，简单地说，就是先定义一些服务器池，池中包含一定量的服务器，然后再定义一些策略，根据这些策略 Oracle 会自动决定让多少数据库实例运行在池中的几台机器上。数据库实例名后缀、数据库实例个数、所运行的主机，这些都是通过策略决定的，而不是数据库管理员事先定好的。

与 Admin-Managed 方式有何区别？

实际上上面的表述已经明确说明了，Policy-Managed 和 Admin-Managed 方式的差别。让我们再回顾一下，在以往我们创建一个 RAC 数据库大概是怎样的方法，我们在 dbca 的界面中会选择要将数据库实例运行在整个集群中的几台机器上，或者是 2 台或者是 3 台，甚或是更多，但是只要在安装的时候选定几台机器，那么以后如果不做增减节点的操作，就始终会在这几台机器上运行。而且，通常会根据主机名称的排序自动将每台主机上的数据库实例依次命名为 dbname1 到 dbnameN。这些在管理员安装完毕以后，都不会再自动变化，这就是 Admin-Managed 方式。

何种环境适合使用这种新的方式进行管理？

当管理大量的服务器集群，并且在这些集群中运行着多种不同重要程度，不同策略的 RAC 数据库时，为了简化管理，建议使用 Policy-Managed 方式，实际上 Oracle 也建议只有在超过 3 台的服务器的时候才使用 Policy-Managed 来管理整个数据库集群。想象一下使用 Policy-Managed 方式可以达到的效果：如果我们有 10 台服务器组成，根据不同的应用的重要性定义服务器池的关键程度，然后在其中某些机器意外停机的情况下，仍然可以自动地保持足够多的机器给重要的系统提供数据库服务，而将不关键的系统数据库服务器个数降低到最低限度。

那么 Policy-Managed 方式到底长什么样？

在默认安装完 Oracle 12c 的 RAC 数据库之后，发现数据库实例始终只会启动在一个节点中。检查服务器池配置。

[oracle@dbserver2 ~]$ srvctl config srvpool
Server pool name: Free
Importance: 0, Min: 0, Max: -1
Category:
Candidate server names:
Server pool name: Generic
Importance: 0, Min: 0, Max: -1
Category:
Candidate server names:
Server pool name: orcl_pool
Importance: 0, Min: 0, Max: 1
Category: hub
Candidate server names:

Free 池和 Generic 池是默认存在的，orcl_pool 池则是在 dbca 创建数据库的时候由我们自己定义的。其中 Min: 0, Max: 1 表示在这个池中最少允许有 0 台机器，最多允许有 1 台机器被使用。所以这也造成了使用这个服务器池的数据库实例始终只会启动在一个节点中，即使这在我们最初的定义中是一个 RAC 数据库。

当前的数据库实例启动在节点 2 中，比较一下节点 1 和节点 2 服务器使用情况的输出。

[grid@dbserver2 ~]$ crsctl status server dbserver1 -f
NAME=dbserver1
MEMORY_SIZE=3954
CPU_COUNT=1
CPU_CLOCK_RATE=2
CPU_HYPERTHREADING=0
CPU_EQUIVALENCY=1000
DEPLOYMENT=other
CONFIGURED_CSS_ROLE=hub
RESOURCE_USE_ENABLED=1
SERVER_LABEL=
PHYSICAL_HOSTNAME=
STATE=ONLINE
ACTIVE_POOLS=Free --此处显示未 Free，表示节点 1 中不属于任何正在运行的服务器池资源。
STATE_DETAILS=
ACTIVE_CSS_ROLE=hub
 
[grid@dbserver2 ~]$ crsctl status server dbserver2 -f
NAME=dbserver2
MEMORY_SIZE=3954
CPU_COUNT=1
CPU_CLOCK_RATE=2
CPU_HYPERTHREADING=0
CPU_EQUIVALENCY=1000
DEPLOYMENT=other
CONFIGURED_CSS_ROLE=hub
RESOURCE_USE_ENABLED=1
SERVER_LABEL=
PHYSICAL_HOSTNAME=
STATE=ONLINE
ACTIVE_POOLS=ora.orcl_pool --此处显示节点 2 正运行在 orcl_pool 服务器池资源中。
STATE_DETAILS=
ACTIVE_CSS_ROLE=hub

接下来需要修改一下配置，让 RAC 数据库以我们熟知的方式启动在多个节点上。 –修改 orcl_pool 池中最少运行一台机器，最多运行 2 台机器，还记得我们前面说的关键程度吗？importance 表示该池的关键程度，数字越大表示关键程度越高，越优先被考虑满足 Min 条件。

[oracle@dbserver2 ~]$ srvctl modify srvpool -serverpool orcl_pool -importance 5 -min 1 -max 2

–重新检查服务器池信息，可以看到已经修改成功，Min: 1, Max: 2

[oracle@dbserver2 ~]$ srvctl config srvpool
Server pool name: Free
Importance: 0, Min: 0, Max: -1
Category:
Candidate server names:
Server pool name: Generic
Importance: 0, Min: 0, Max: -1
Category:
Candidate server names:
Server pool name: orcl_pool
Importance: 5, Min: 1, Max: 2
Category: hub
Candidate server names:

–查看当前服务器池的状态，可以看到 orcl_pool 池中激活的服务器包括了节点 1 和节点 2 两台机器。

[grid@dbserver1 ~]$ crsctl status serverpool
NAME=Free
ACTIVE_SERVERS=
 
NAME=Generic
ACTIVE_SERVERS=
 
NAME=ora.orcl_pool
ACTIVE_SERVERS=dbserver1 dbserver2

在修改完毕以后，节点1中的数据库实例就会自动启动，我们可以通过 crsctl 命令查看服务器的状态，其中 STATE_DETAILS 字段显示了正在启动资源，在正常启动完毕以后该字段会显示为空。

[grid@dbserver2 ~]$ crsctl status server dbserver1 -f
NAME=dbserver1
MEMORY_SIZE=3954
CPU_COUNT=1
CPU_CLOCK_RATE=2
CPU_HYPERTHREADING=0
CPU_EQUIVALENCY=1000
DEPLOYMENT=other
CONFIGURED_CSS_ROLE=hub
RESOURCE_USE_ENABLED=1
SERVER_LABEL=
PHYSICAL_HOSTNAME=
STATE=ONLINE
ACTIVE_POOLS=ora.orcl_pool
STATE_DETAILS=STARTING RESOURCES
ACTIVE_CSS_ROLE=hub

现在就出现了一个比较尴尬的情况（对于我们以前管理 RAC 的常识来说），由于 dbserver1 中的实例是后启动的，因此实例名后缀为 2，而 dbserver2 中的实例名后缀是 1，实际上，在 Policy-Managed 管理的 RAC 环境中，无需关注到底哪个实例启动在哪台机器上，我们需要的就是通过 SCAN IP，通过 Service 名去访问数据库就好，而不需要通过实例名访问数据库。但是这里为了测试一下功能，还是决定 1 归 1，2 归 2，我有说过我是完美主义者吗？

--先将 dbserver1 上的数据库服务资源 reolocate 到 dbserver2 中，这样实例 2 就运行回到了 dbserver2 中。
[grid@dbserver1 ~]$ crsctl relocate resource ora.orcl12c.db -s dbserver1 -n dbserver2
--再将 dbserver1 中的实例启动，因为实例 2 已经启动在 dbserver2 中，因此即使此时该实例是后启动的，但是仍然还是会命名为实例 1。
[oracle@dbserver1 ~]$ srvctl start instance -db orcl12c -node dbserver1

最后将这个 RAC 数据库再改回到只会启动一个实例的默认状态。

[oracle@dbserver2 ~] srvctl modify srvpool -serverpool orcl_pool -min 0 -max 1

以后，无论是启动在哪台机器上，数据库的实例名永远会是 dbname_1（注意，这里有一个下划线，这是 Policy-Managed 数据库实例的命名规则）。而我们访问数据库，则不应该指定实例名。比如：

sqlplus sys/passwd@db-cluster-scan:1521/orcl12c as sysdba

因为现在你已经无需关心到底实例是启动在哪台机器上了，后面是一个资源池，是不是有些熟悉这样的表述，是的，没错，Cloud! 我们也贴上了 Cloud 这个红到发紫的词，这就是 Oracle 私有云解决方案的构成组件之一。

鼓励发表数据库选件 (DBO) 相关的内容或在 Oracle 技术网上发表文章。参见在 Oracle 技术网上发表技术文章。

原文地址：http://www.oracle.com/technetwork/cn/articles/database/policy-managed-cluster-2398581-zhs.html