9. 测试故障切换功能
使用我编写的免费 GPL-d Java 应用程序 （在撰写本文时尚处于测试阶段），您可以通过非常简单的方式观察发生故障时可能的客户如何在实例间进行切换（以及衡量性能）。
ERAC1 上的实例故障
首先，在闲置数据库上运行 orajdbcstat：
[vnull@xeno orajdbcstat]$ ./orajdbcstat.sh -d ERAC -i ERAC1 -i ERAC2 1
------ ------conntime------ -----------stmt-------------------
tns rac# tcpping jdbc rac# ins sel upd del plsql
15:35:22 ERAC 2 0 49 1 3 0 2 2 0
15:35:22 +ERAC1 1 0 45 1 19 0 2 2 0
15:35:22 +ERAC2 2 0 60 2 4 0 2 14 0
15:35:23 ERAC 1 0 44 1 3 0 2 3 0
15:35:23 +ERAC1 1 0 65 1 2 0 2 3 0
15:35:23 +ERAC2 2 0 46 2 3 0 3 2 0
|
从输出可以看到，主线程（“ERAC”TNS 描述符）连接到编号为 1 的实例。“conntime”显示到 RAC
实例的新连接的时间以及主 TNS 描述符（使用故障切换功能；注意，当前未执行“tcpping”）。在“stmt”下面，我们可以监视来自
FCF（快速连接故障切换）池的连接 — 当前 RAC 实例数和简单的 SQL 语句时间安排。命令行末尾的“1”强制 orajdbcstat
每秒输出一次统计信息。
执行以下命令模拟 RAC 实例 #1 崩溃：
[oracle@rac1 ~]$ srvctl stop instance -d erac -i erac1 -o abort
[oracle@rac1 ~]$
|
在使用 orajdbcstat 的 SSH 会话中，您将得到以下输出（将在节选下面进行描述）：
15:36:55 ERAC 1 0 45 1 3 0 1 3 0
15:36:55 +ERAC1 1 0 42 1 43 0 2 2 0
15:36:55 +ERAC2 2 0 49 2 3 0 4 2 0
------ ------conntime------ -----------stmt---------------
tns rac# tcpping jdbc rac# ins sel upd del plsql
15:36:56 ERAC 2 0 49 1->X [ E!17008 ]
15:36:56 +ERAC1 -1 E!01092 E!01092 1->X [ E!17008 ]
15:36:56 +ERAC2 2 0 67 2 17 0 4 2 0
15:36:57 ERAC 2 0 46 X->2 [ E!17008 ]
15:36:57 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:36:57 +ERAC2 2 0 67 2 17 0 4 2 0
15:36:58 ERAC 2 0 46 X->2 [ E!17008 ]
15:36:58 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:36:58 +ERAC2 2 0 67 2 17 0 4 2 0
15:36:59 ERAC 2 0 46 X->2 [ E!17008 ]
15:36:59 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:36:59 +ERAC2 2 0 67 2 17 0 4 2 0
15:37:00 ERAC 2 0 46 X->2 [ E!17008 ]
15:37:00 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:37:00 +ERAC2 2 0 67 2 17 0 4 2 0
15:37:01 ERAC 2 0 56 2 12 0 7 3 0
15:37:01 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:37:01 +ERAC2 2 0 51 2 131 0 5 3 0
15:37:02 ERAC 2 0 59 2 178 0 17 29 0
15:37:02 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:37:02 +ERAC2 2 0 73 2 121 0 203 36 0
------ ------conntime------ -----------stmt---------------
tns rac# tcpping jdbc rac# ins sel upd del plsql
15:37:03 ERAC 2 0 68 2 2 0 3 2 0
15:37:03 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:37:03 +ERAC2 2 0 45 2 3 0 2 3 0
15:37:04 ERAC 2 0 48 2 7 0 3 2 0
15:37:04 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:37:04 +ERAC2 2 0 86 2 2 0 3 4 0
15:37:05 ERAC 2 0 47 2 2 0 3 2 0
15:37:05 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:37:05 +ERAC2 2 0 53 2 3 0 3 3 0
15:37:06 ERAC 2 0 48 2 3 0 2 2 0
15:37:06 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:37:06 +ERAC2 2 0 46 2 10 0 2 10 0
15:37:07 ERAC 2 0 48 2 2 0 3 3 0
15:37:07 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:37:07 +ERAC2 2 0 83 2 10 0 3 2 0
15:37:08 ERAC 2 0 48 2 3 0 2 2 0
15:37:08 +ERAC1 -z E!12521 E!12521 X [ E!17008 ]
15:37:08 +ERAC2 2 0 50 2 2 0 3 2 0
15:37:09 ERAC 2 0 48 2 2 0 2 2 0
15:37:09 +ERAC1 -1 E!12521 E!12521 X [ E!17008 ]
15:37:09 +ERAC2 2 0 44 2 3 0 2 3 0
[..utility still running, output trimmed for clarity..]
|
发生的情况如下：
- 在 15:36:56，所有到 ERAC1 的新连接开始返回错误，并且 FCF 池中的所有 ERAC1 连接暂停正常操作。主数据库的 FCF 池（ERAC TNS 描述符）检测到故障，故障切换功能启动。
- 在 15:36:57（故障发生后 1 秒），主 FCF 池开始重新连接到 RAC#2 实例 (“X->2”)。
- 在 15:37:00 和 15:37:01 之间（故障发生后 4 或 5 秒），到其余 ERAC2 实例的 FCF 池连接重新建立。
“E!NNNNN”字符串表明 SQL 连接发生 ORA-NNNNN 错误。（要对错误进行解码，使用 oerrutility。）恢复之后（启动实例 ERAC1）：
15:47:37 ERAC 2 0 64 2 3 0 2 3 0
15:47:37 +ERAC1 -1 E!01033 E!01033 X [ E!17008 ]
15:47:37 +ERAC2 2 0 57 2 8 0 13 1 0
15:47:38 ERAC 2 0 54 2 3 0 3 2 0
15:47:38 +ERAC1 1 0 481 X->1 [ E!17008 ]
15:47:38 +ERAC2 2 0 52 2 3 0 2 4 0
------ ------conntime------ -----------stmt---------------
tns rac# tcpping jdbc rac# ins sel upd del plsql
15:47:39 ERAC 2 0 54 2 3 0 3 2 0
15:47:39 +ERAC1 1 0 167 1 14 0 4 2 0
15:47:39 +ERAC2 2 0 56 2 8 0 27 3 0
|
如您所见，ERAC1 上的 FCF 池检测到实例正在运行，并在无需人工干预的情况下重新开始工作。
灾难性站点故障
构建扩展 RAC 集群的主要目的是能够经受住灾难性站点故障（RAC 节点和 SAN 崩溃）。再次从工作站启动 orajdbcstat：
------ ------conntime------ -----------stmt---------------
tns rac# tcpping jdbc rac# ins sel upd del plsql
17:24:18 ERAC 1 0 46 2 11 0 2 2 0
17:24:18 +ERAC1 1 0 45 1 4 0 3 2 0
17:24:18 +ERAC2 2 0 46 2 4 0 3 3 0
17:24:19 ERAC 1 0 45 2 2 0 4 3 0
17:24:19 +ERAC1 1 0 44 1 15 0 3 2 0
17:24:19 +ERAC2 2 0 44 2 3 0 3 3 0 |
如您所见，主 FCF 池正在使用 RAC#2 实例，因此您将使整个 #2 站点（iscsi2 和 rac2 节点）崩溃：
[root@quadovm ~]# xm list
Name ID Mem VCPUs State Time(s)
132_rac1 1 2048 1 -b---- 1845.0
134_rac2 6 2048 1 r----- 152.2
Domain-0 0 512 4 r----- 665.3
iscsi1 3 768 1 -b---- 194.0
iscsi2 5 768 1 -b---- 44.3
[root@quadovm ~]# xm destroy 134_rac2 && date && xm destroy iscsi2 && date
Sat May 31 17:25:55 CEST 2008
Sat May 31 17:25:56 CEST 2008
[root@quadovm ~]# |
现在，返回到 orajdbcstat 会话：
17:25:56 ERAC 2 0 44 2 3 0 3 2 0
17:25:56 +ERAC1 1 0 79 1 8 0 3 2 0
17:25:56 +ERAC2 2 0 44 2 11 0 3 2 0
17:25:57 ERAC 2 0 44 2 3 0 3 2 0
17:25:57 +ERAC1 1 0 79 1 8 0 3 2 0
17:25:57 +ERAC2 2 0 44 2 11 0 3 2 0
17:25:58 ERAC 2 0 44 2 3 0 3 2 0
17:25:58 +ERAC1 1 0 79 1 8 0 3 2 0
17:25:58 +ERAC2 -1 E!12170 E!12170 2 11 0 3 2 0
17:25:59 ERAC 2 0 44 2 3 0 3 2 0
17:25:59 +ERAC1 1 0 79 1 8 0 3 2 0
17:25:59 +ERAC2 -1 E!12170 E!12170 2 11 0 3 2 0
------ ------conntime------ -----------stmt---------------
tns rac# tcpping jdbc rac# ins sel upd del plsql
17:26:00 ERAC 2 0 44 2 3 0 3 2 0
17:26:00 +ERAC1 1 0 79 1 8 0 3 2 0
17:26:00 +ERAC2 -1 E!12170 E!12170 2 11 0 3 2 0
17:26:01 ERAC 2 0 44 2 3 0 3 2 0
17:26:01 +ERAC1 1 0 79 1 8 0 3 2 0
17:26:01 +ERAC2 -1 E!12170 E!12170 2 11 0 3 2 0
17:26:02 ERAC 2 0 44 2 3 0 3 2 0
17:26:02 +ERAC1 1 0 79 1 8 0 3 2 0
17:26:02 +ERAC2 -1 E!12170 E!12170 2 11 0 3 2 0
17:26:03 ERAC 2 0 44 2 3 0 3 2 0
17:26:03 +ERAC1 1 0 79 1 8 0 3 2 0
17:26:03 +ERAC2 -1 E!12170 E!12170 2->X [ E!03113 ]
17:26:04 ERAC -1 E!12170 E!12170 2 3 0 3 2 0
17:26:04 +ERAC1 1 0 43 X [ E!03113 ]
17:26:04 +ERAC2 -1 E!12170 E!12170 2->X [ E!03113 ]
17:26:05 ERAC -1 E!12170 E!12170 2 3 0 3 2 0
17:26:05 +ERAC1 1 0 43 X->1 [ E!03113 ]
17:26:05 +ERAC2 -1 E!12170 E!12170 2->X [ E!03113 ]
17:26:06 ERAC -1 E!12170 E!12170 2 3 0 3 2 0
17:26:06 +ERAC1 1 0 43 X->1 [ E!03113 ]
17:26:06 +ERAC2 -1 E!12170 E!12170 2->X [ E!03113 ] |
可以清楚地看到，整个扩展 RAC 都被阻塞（甚至 ERAC1 实例）。这是因为 ERAC1 实例（主要是 DBWR 和
LGWR）仍要重新尝试写入 iscsi2 上的 iSCSI 存储（不可用）。如果在 TCP iSCSI 连接上发生 iSCSI 超时，将向
Oracle 软件（集群件、ASM 和数据库）返回 I/O 错误。
如您在前面所见，我们在 rac1 和 rac2 上配置了 iSCSI 堆栈，将重试时间设置为 120 秒（/etc/iscsi/iscsid.conf
中的参数 node.session.timeo.replacement_timeout）。在此 120 秒期间，当存储上所有使用文件描述符
(fd) 的应用程序看起来要挂起时，内核将重试 I/O 操作。可以在 dmesg 命令的输出和 ASM 警报日志文件中看到更详细的信息。
一段时间之后：
17:28:17 ERAC -1 E!12571 E!12571 X [ E!03113 ]
17:28:17 +ERAC1 1 0 43 X->1 [ E!03113 ]
17:28:17 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
17:28:18 ERAC -1 E!12571 E!12571 X [ E!03113 ]
17:28:18 +ERAC1 1 0 75 X [ E!03113 ]
17:28:18 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
17:28:19 ERAC -1 E!12571 E!12571 X [ E!03113 ]
17:28:19 +ERAC1 1 0 91 X->1 29 0 23 23 0
17:28:19 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
17:28:20 ERAC -1 E!12571 E!12571 X [ E!03113 ]
17:28:20 +ERAC1 1 0 43 1 8 0 4 1 0
17:28:20 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
17:28:21 ERAC -1 E!12571 E!12571 X [ E!03113 ]
17:28:21 +ERAC1 1 0 42 1 8 0 4 2 0
17:28:21 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
17:28:22 ERAC -1 E!12571 E!12571 X->1 4 0 8 9 0
17:28:22 +ERAC1 1 0 42 1 7 0 2 2 0
17:28:22 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
------------conntime------ -----------stmt---------------
tns rac# tcpping jdbc rac# ins sel upd del plsql
17:28:23 ERAC 1 0 45 1 3 0 3 3 0
17:28:23 +ERAC1 1 0 43 1 2 0 3 2 0
17:28:23 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
17:28:24 ERAC 1 0 43 1 2 0 2 2 0
17:28:24 +ERAC1 1 0 43 1 2 0 2 2 0
17:28:24 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
17:28:25 ERAC 1 0 44 1 19 0 3 2 0
17:28:25 +ERAC1 1 0 43 1 2 0 3 2 0
17:28:25 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
17:28:26 ERAC 1 0 44 1 3 0 2 3 0
17:28:26 +ERAC1 1 0 43 1 2 0 1 2 0
17:28:26 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
17:28:27 ERAC 1 0 43 1 3 0 1 2 0
17:28:27 +ERAC1 1 0 42 1 2 0 3 2 0
17:28:27 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
17:28:28 ERAC 1 0 43 1 8 0 3 2 0
17:28:28 +ERAC1 1 0 43 1 4 0 3 2 0
17:28:28 +ERAC2 -1 E!12571 E!12571 X [ E!03113 ]
|
此处发生的情况为：
- 在 17:28:17 和 17:28:19 之间（故障发生后 2 分 14 秒），ERAC1 TNS 能够重新建立新连接。
- 在 17:28:19（故障发生后 2 分 16 秒），ERAC1 FCF 池正常工作。
- 在 17:28:19 到 17:28:22 之间（故障发生后 2 分 16 秒），主 ERAC FCF 池尝试故障切换到 ERAC1。
- 在 17:28:22（故障发生后 2 分 19 秒），主 ERAC FCF 池成功故障切换到 ERAC1。所有连接现在都正常工作。故障组 DATA1_0001 将其磁盘挂载状态由 CACHED 更改为 MISSING。
SQL> col path format a36
SQL> col diskgroup format a10
SQL> col failgroup format a10
SQL> SELECT path, dg.name diskgroup, failgroup, mount_status, mode_status FROM v$asm_disk d JOIN
v$asm_diskgroup dg ON (d.group_number=dg.group_number) ORDER BY 1;
PATH DISKGROUP FAILGROUP MOUNT_S MODE_ST
------------------------------------ ---------- ---------- ------- -------
/dev/iscsi/racdata1.asm1/lun0/part1 DATA1 DATA1_0000 CACHED ONLINE
DATA1 DATA1_0001 MISSING OFFLINE
SQL> |
延迟影响和性能下降
警告：这些测试是针对本指南的目的而设计的；它们不是真正、实际的测试，不应将其视为扩展 RAC 集群性能的真实测量。
扩展 RAC 配置的关键因素是 RAC 节点和存储阵列之间的距离。为了在不使用昂贵硬件的情况下解决模拟延迟问题，我们将使用 Linux
的内置网络通信量调整功能（有时简称为 QoS — 信源质量）。由于我们的 SAN 基于
iSCSI，因此我们只需在以太网层引入任意延迟、包重新排序和包删除。（这当然也适用于 NFS，并可能适用于当前开发的 FcoE。）RAC
节点之间的互连也是一样。
在本案例中，您要在 dom0 中配置内部 Xen 网络设备，以便在 VM 之间引入延迟。用于配置 Linux
通信量调整的主要实用程序称为“tc”（即通信量控制 (Traffic Control)）。当您开始研究细节时便会发现问题。标准 Oracle
VM Server dom0 的内核正在以 250HZ 运行，这仅意味着 dom0 内核中所有与时间相关的任务都以 4ms
的时间间隔执行。Linux netem 排队规则引入的延迟依赖于内核的 HZ 设置。因此，为了模拟 1ms 延迟，您需要使用具有不同 HZ
设置的内核（至少为 1,000HZ，以充分模拟 1ms 延迟）。
由于内核编译非常繁琐，因此建议您在下载可直接运行的 dom0 内核 RPM。将在后面的“为 Oracle VM Server 2.1 Xen dom0 构建内核”部分简要介绍构建 dom0 Xen 内核的过程。此外，还将在该部分介绍安装新内核的过程。
用于配置 Xen 网络接口以引入延迟的简单脚本名为 qosracinit.pl，已在 dom0 中运行。可以在下载该脚本。
根据环境更改变量之后，只需执行：
[root@quadovm ~]# ./qosracinit.pl > /tmp/qos && bash /tmp/qos
[root@quadovm ~]# |
为了弄清楚 QoS 规则以免引起延迟，只需执行：
[root@quadovm ~]# ./qosracinit.pl clear > /tmp/qos && bash /tmp/qos
[root@quadovm ~]#
|
使用 Dominic Giles 的 定单输入基准测试执行测试。Swingbench 是用于 RAC 环境的简单设置。“Min Think”和“Max Think”时间设置为 0，以充分利用此安装的事务处理潜力。（“Think”时间是推迟下一个事务所需的时间。）
配置了 15 个 JDBC 连接的两个负载生成器 (minibench) 正施加压力于单个 RAC 节点。负载生成器正在从“xeno”工作站运行。为 SOE 用户报告的实际数据库大小为：
SQL> conn soe/soe
Connected.
SQL> select sum(bytes)/1024/1024 mb from user_segments;
MB
----------
2250.72656
SQL> |
人为地将关键参数设置以下值：
- sga_target=1G
- db_cache_size =512M
- pga_aggregate_target=256M
- memory_target = 0（禁用）
为 db_cache_size 设置较低值是为了使 Oracle 数据库施加压力于互连和 SAN，并使其容易受到延迟的影响。
无延迟
首先，我们来测量 Vm 之间的实际延迟。（注：在 Swingbench 满负载期间收集了所有 ping 测试。）
[oracle@rac2 ~]$ ping -c 10 -i 0.2 -q -s 1200 10.97.1.1; ping -c 10 -i 0.2 -q -s 1200 10.98.1.101; ping -c 10 -i 0.2 -q -s 1200 10.98.1.102
PING 10.97.1.1 (10.97.1.1) 1200(1228) bytes of data.
--- 10.97.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1816ms
rtt min/avg/max/mdev = 0.067/0.091/0.113/0.018 ms
PING 10.98.1.101 (10.98.1.101) 1200(1228) bytes of data.
--- 10.98.1.101 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1804ms
rtt min/avg/max/mdev = 0.083/0.106/0.132/0.020 ms
PING 10.98.1.102 (10.98.1.102) 1200(1228) bytes of data.
--- 10.98.1.102 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1799ms
rtt min/avg/max/mdev = 0.079/0.108/0.193/0.034 ms
[oracle@rac2 ~]$
|
本测试显示 RAC2 节点和以下地址之间的延迟：
- 10.97.1.1（RAC1，通过互连）
- 10.98.1.101（iscsi1 openfiler，通过 SAN）
- 10.98.1.102（iscsi2 openfiler，通过 SAN）
（使用 1,200 字节的 ICMP 回显数据包）。我们对平均往返时间感兴趣，因为它是扩展 RAC 的关键因素。在下面可以看到，基准测试将生成大约 5460 TPM：
[oracle@rac1 ~]$ sqlplus -s / as sysdba @tpm
6356
5425
4924
5162
5430
Average = 5459.4
PL/SQL procedure successfully completed.
[oracle@rac1 ~]$ |
接下来，尝试引入延迟，并观察它对培训系统的实际影响。用于执行此操作的 tpm.sql 脚本如下所示：
set termout on
set echo off
set serveroutput on
DECLARE
val1 NUMBER;
val2 NUMBER;
diff NUMBER;
average NUMBER := 0;
runs NUMBER := 5;
BEGIN
FOR V IN 1..runs LOOP
SELECT SUM(value) INTO val1
FROM gv$sysstat WHERE name IN ('user commits','transaction rollbacks');
DBMS_LOCK.SLEEP(60);
SELECT SUM(value) INTO val2
FROM gv$sysstat WHERE name IN ('user commits','transaction rollbacks');
diff := val2-val1;
average := average + diff;
DBMS_OUTPUT.PUT_LINE(diff);
END LOOP;
DBMS_OUTPUT.PUT_LINE('Average = ' || average/runs);
END;
/
exit |
1ms 人为延迟
如您在前面所做的那样，首先测量实际的平均往返时间：
[oracle@rac2 ~]$ ping -c 10 -i 0.2 -q -s 1200 10.97.1.1; ping -c 10 -i 0.2 -q -s 1200 10.98.1.101; ping
-c 10 -i 0.2 -q -s 1200 10.98.1.102
PING 10.97.1.1 (10.97.1.1) 1200(1228) bytes of data.
--- 10.97.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1809ms
rtt min/avg/max/mdev = 2.693/3.482/3.863/0.389 ms
PING 10.98.1.101 (10.98.1.101) 1200(1228) bytes of data.
--- 10.98.1.101 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1854ms
rtt min/avg/max/mdev = 2.481/3.850/6.621/1.026 ms
PING 10.98.1.102 (10.98.1.102) 1200(1228) bytes of data.
--- 10.98.1.102 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1812ms
rtt min/avg/max/mdev = 0.080/0.135/0.233/0.051 ms
[oracle@rac2 ~]$ |
根据上面的输出可以得出如下结论：向 Linux 的输出网络队列添加 1ms 后，实际平均往返时间增加到 3.5 — 3.8 ms
左右。这是由于传出的 ICMP 回显请求数据包大约被推迟了 1ms，来自响应方的回复也相应地被推迟了 1ms。多余的大约 2ms
可能是在系统处于满负载期间，Xen 在已被超额预定的系统上调度上下文切换导致的。（注：您正在模拟四个 VM，但在实际情况下，实际的 IO
工作是由在 4x CPU 计算机上运行的第 5 台 VM dom0 完成的。）
[oracle@rac1 ~]$ sqlplus -s / as sysdba @tpm
5173
5610
5412
5094
5624
Average = 5382.6
PL/SQL procedure successfully completed.
[oracle@rac1 ~]$ |
3ms 人为延迟
[oracle@rac2 ~]$ ping -c 10 -i 0.2 -q -s 1200 10.97.1.1; ping -c 10 -i 0.2 -q -s 1200 10.98.1.101; ping
-c 10 -i 0.2 -q -s 1200 10.98.1.102
PING 10.97.1.1 (10.97.1.1) 1200(1228) bytes of data.
--- 10.97.1.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1819ms
rtt min/avg/max/mdev = 6.326/7.631/9.839/0.881 ms
PING 10.98.1.101 (10.98.1.101) 1200(1228) bytes of data.
--- 10.98.1.101 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1806ms
rtt min/avg/max/mdev = 6.837/7.643/8.544/0.426 ms
PING 10.98.1.102 (10.98.1.102) 1200(1228) bytes of data.
--- 10.98.1.102 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 1801ms
rtt min/avg/max/mdev = 0.076/0.149/0.666/0.172 ms
[oracle@rac2 ~]$ |
根据上面的观察可以得出如下结论：Xen 调度及系统超额预定增加了 1.5-2ms (7.5 [ms] – 2x3 [ms] = 1.5 [ms])。
[oracle@rac1 ~]$ sqlplus -s / as sysdba @tpm
5489
4883
5122
5512
4965
Average = 5194.2
PL/SQL procedure successfully completed.
[oracle@rac1 ~]$ |
我们可以看到，在人为测试中性能下降了大约 5200 TPM 和 5460 TPM（无延迟）。
10. 故障诊断和其他事项
本部分旨在解决实现扩展 RAC 体系结构时可能发生的不同问题。
连接到 RAC 时避免出现 ORA-12545 错误
连接到新配置的 RAC 客户端时，有时会遇到错误 ORA-12545“Connect failed because target
host or object does not exist”（由于目标主机或对象不存在导致连接失败）。要解决这个问题，请单独为每个实例更改
LOCAL_LISTENER 参数。
SQL> ALTER SYSTEM SET local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=10.99.1.91)(PORT=1521))' SID='erac1';
System altered.
SQL> ALTER SYSTEM SET local_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=10.99.1.92)(PORT=1521))' SID='erac2';
System altered.
|
另外，还可以设置 DNS 并在其中注册 RAC 节点，或者重新配置客户端以便将 RAC 主机名解析成 IP 地址 — 例如，将其添加到与 UNIX 类似的 JDBC 客户端上的 /etc/hosts 中：
10.99.1.191 vmrac1-vip vmrac1
10.99.1.192 vmrac2-vip vmrac2
|
为 Oracle VM Server 2.1 Xen dom0 构建内核
我的编译经验表明，要对 dom0 内核进行自编译，应将以下 RPM 上载到 Oracle VM：
[vnull@xeno Downloads]$ scp -r RPMS_OVM21_kernel_compile root@10.99.1.2:.
root@10.99.1.2's password:
m4-1.4.5-3.el5.1.i386.rpm 100% 133KB 133.2KB/s 00:00
rpm-build-4.4.2-37.el5.0.1.i386.rpm 100% 547KB 547.5KB/s 00:00
kernel-2.6.18-8.1.6.0.18.el5.src.rpm 100% 48MB 9.6MB/s 00:05
kernel-headers-2.6.18-8.el5.i386.rpm 100% 723KB 723.5KB/s 00:00
glibc-devel-2.5-12.i386.rpm 100% 2034KB 2.0MB/s 00:00
elfutils-0.125-3.el5.i386.rpm 100% 164KB 163.7KB/s 00:00
glibc-headers-2.5-12.i386.rpm 100% 605KB 604.6KB/s 00:00
patch-2.5.4-29.2.2.i386.rpm 100% 64KB 64.0KB/s 00:00
redhat-rpm-config-8.0.45-17.el5.0.1.noarch.rpm 100% 52KB 52.5KB/s 00:00
libgomp-4.1.1-52.el5.i386.rpm 100% 69KB 69.3KB/s 00:00
cpp-4.1.1-52.el5.i386.rpm 100% 2673KB 2.6MB/s 00:01
gcc-4.1.1-52.el5.i386.rpm 100% 5067KB 5.0MB/s 00:00
elfutils-libs-0.125-3.el5.i386.rpm 100% 105KB 105.2KB/s 00:00
[vnull@xeno Downloads]$
|
接下来，复制完安装程序包之后，将其安装在 OracleVM Server 上：
[root@quadovm RPMS_OVM21_kernel_compile]# rpm -Uhv *.rpm
[..]
[root@quadovm ~]# cd /usr/src/redhat/SPECS/
[root@quadovm SPECS]# vi kernel-2.6.spec |
在 kernel-2.6.spec 中应设置以下变量：
- %define buildboot 0
- %define buildxenovs 1
[root@quadovm SPECS]# rpmbuild -bp --target=`uname -m` kernel-2.6.spec
Building target platforms: i686
Building for target i686
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.29959
+ umask 022
[..]
[root@quadovm SPECS]# cd ../BUILD/kernel-2.6.18/linux-2.6.18.i686/
[root@quadovm linux-2.6.18.i686]# grep HZ .config
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
CONFIG_MACHZ_WDT=m
CONFIG_NO_IDLE_HZ=y
[root@quadovm linux-2.6.18.i686]# vi .config
|
将 .config 编辑为以下值，以确保将 HZ 设置为 1,000Hz：
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
编辑 Makefile 以区分我们的新内核并构建它：
[root@quadovm linux-2.6.18.i686]# vi Makefile
change EXTRAVERSION to e.g.: -8.1.6.0.18.el5xen_vnull03
[root@quadovm linux-2.6.18.i686]# make oldconfig
[..]
[root@quadovm linux-2.6.18.i686]# make config
[..disable KERNEL DEBUG!...]
[root@quadovm linux-2.6.18.i686]# make rpm
scripts/kconfig/conf -s arch/i386/Kconfig
[..] |
新构建的内核应存在于 /usr/src/redhat/RPMS/i386 目录中。
安装新内核
安装新内核是例行任务，但是由于自编译的内核不使用繁琐的安装程序，因此必须手动执行某些内核安装步骤。
[root@quadovm ~]# rpm -ihv kernel-2.6.188.1.6.0.18.el5xen_vnull03-1.i386.rpm
Preparing... ########################################### [100%]
1:kernel ########################################### [100%]
[root@quadovm ~]# depmod -a 2.6.18-8.1.6.0.18.el5xen_vnull03
[root@quadovm ~]# mkinitrd /boot/initrd-2.6.18-8.1.6.0.18.el5xen_vnull03.img 2.6.18-8.1.6.0.18.el5xen_vnull03 |
接下来，需要更改 GRUB 引导加载程序以引导新内核
[root@quadovm ~]# cd /boot/grub
[root@quadovm grub]# vi menu.lst |
首先，确保在 menu.lst 文件中将默认值设置为“0”：default=0。在默认情况下，这将引导在 menu.lst 中找到的第一个内核条目。将以下 GRUB 内核配置条目放在首位（在所有其他内容之前）：
title Oracle VM Server vnull03
root (hd0,0)
kernel /xen.gz console=ttyS0,57600n8 console=tty dom0_mem=512M
module /vmlinuz-2.6.18-8.1.6.0.18.el5xen_vnull03 ro root=/dev/md0
module /initrd-2.6.18-8.1.6.0.18.el5xen_vnull03.img |
从灾难性站点故障中快速恢复
这个简单过程说明如何在模拟灾难发生后使 iscsi2 阵列和 rac2 节点恢复全部功能。注：在本案例中，您丢失了 OCRmirror。（它位于 iscsi2 的 LUN 上。）
- 启动系统 iscsi2（例如，通过在 /OVS/running_pool/64_iscsi2 中运行 xm create vm.cfg）。
- 让 rac1 节点通过 iSCSI 连接到 iscsi2（请查看 /var/log/messages
中类似如下内容的消息：“iscsid:connection4:0 is operational after recovery (314
attempts)”（iscsid: connection4:0 自恢复后可正常运行（314 次尝试））。
- 执行 ALTER DISKGROUP DATA1 ONLINE ALLon +ASM1 实例。
- 丢失的故障组现在应该正在同步：
PATH DISKGROUP FAILGROUP MOUNT_S MODE_ST
------------------------------------ ---------- ---------- ------- -------
/dev/iscsi/racdata1.asm1/lun0/part1 DATA1 DATA1_0000 CACHED ONLINE
/dev/iscsi/racdata2.asm1/lun0/part1 DATA1 DATA1_0001 CACHED SYNCING
|
- 一段时间过后，ASM 故障组运行应该完全正常 (MODE_STATUS=ONLINE)。
- CSS 后台程序应使表决磁盘自动联机。
- Ocrcheck 应指出某个 OCR 镜像未被同步。
[root@rac1 bin]# ./ocrcheck
Status of Oracle Cluster Registry is as follows :
Version : 2
Total space (kbytes) : 327188
Used space (kbytes) : 3848
Available space (kbytes) : 323340
ID : 2120916034
Device/File Name : /dev/iscsi/racdata1.ocr/lun0/part1
Device/File integrity check succeeded
Device/File Name : /dev/iscsi/racdata2.ocr/lun0/part1
Device/File needs to be synchronized with the other device
Cluster registry integrity check succeeded
[root@rac1 bin]# |
- 为了修复此问题，只需运行 ocrconfig，然后您可以在 /u01/app/crs/log/rac1/crsd/crsd.log 中查看有关新 OCR 镜像（在替换期间发生的操作）的信息。
[root@rac1 bin]# ./ocrconfig -replace ocrmirror /dev/iscsi/racdata2.ocr/lun0/part1
[root@rac1 bin]#
|
- 启动系统 rac2，以形成运行完全正常的扩展集群。
11. 后续步骤
有许多方法可以使 RAC 集群变得更加坚不可摧。首先，可以使用 Linux 绑定驱动程序建立冗余互连。这种方法同样适用于具有 iSCSI
的 IO 多路径。如果使用更多磁盘（尤其是 iSCSI OpenFiler 系统的专用磁盘），性能和测试的效果会更佳。
12. 致谢
我要感谢以下人员：
- Rados aw Mańkowski，他是我的 Oracle 导师，并使我为 Oracle 着迷。
- Mariusz Masewicz 和 Robert Wrembel，允许我编写有关扩展 RAC 的文章，并将其作为波兹南理工大学的一个项目。
- Jeffrey Hunter 或有关 RAC 安装的出色文章（本文就是在这些文章的基础上编写的）。
- Kevin Closson () 和 Dan Norris ()，提供了有关在扩展 RAC 中使用 (Direct) NFS 的技术讨论。
Jakub Wartak [] 2008 年 2 月毕业于波兰波兹南理工大学，获计算机科学学士学位，目前正在攻读计算机科学硕士学位。他是 Oracle 10
g
(DBA) 的 Oracle 认证初级人员、Sun 认证的 Solaris 10 系统管理员，以及 Sun 认证的 Solaris 10
网络管理员。他以前是一位 UNIX/Linux 兼职管理员。Jakub 自 2008 年 9 月起一直在 GlaxoSmithKline
担任初级 DBA。
阅读(2727) | 评论(0) | 转发(0) |
