近日,由于项目中的需要对HP UNIX下的Oracle的集群模式进行了研究。Oracle拥有VG共享存储模式和独占模式两种集群模式,本文结合在实际项目,详细介绍了实现oracle数据库服务器的双机热备和动态负载均衡的过程,具体如下:
1、双机热备(VG共享存储模式)及负载均衡方案
双机热备的含义就是设置两台互为备份的服务器,并且在同一时间内只有一台服务器运行。当出现意外情况时候,其中一台运行着的服务器出现意外故障而无法启动时,另一台备份的服务器就会自动的并迅速的启动运行,从而保证整个应用系统的正常运行。双机热备的工作机制实际上是为整个网络系统的中心服务器提供了一种故障自动恢复能力。
这里需要清楚阵列盘信息、双机软件信息、HP unix双机系统集群技术层次构架、负载均衡和单点故障自动切换:
1) 阵列盘就是盘阵上的硬盘,就是双机热备要用到的物理存储。
2) 操作系统双机软件:roseha,IBM的AIX小机的HACMP,HP-UNIX的SG(MC/service guard)。windows的mscs等等。这里用HP-UNIX的SG(service guard)。
3) oracle数据库集群软件Serviceguard Extension for RAC
4) HP unix双机系统集群技术层次构架由HP unix 11.31操作系统、HP UX service guard 集群组件、Oracle数据库集群等三部分组成,请看示意图“HP unix双机系统集群技术层次构架”。
a) HP unix 11.31操作系统重要信息内容是由系统内核和卷组管理器组成。在安装数据库集群软件(Serviceguard Extension for RAC)和操作系统集群软件(service guard)的时候,需要修改HP unix的内核参数信息,所以这里信息比较重要。
b) MC/service guard 是HP RX系列服务器的高可用性集群,在计算机软硬件出现故障时候,可以继续执行应用系统服务,是一种基于应用的可迁移方法。
c) 卷组管理器是管理阵列盘,就是盘阵上的硬盘,就是双机热备要用到的物理存储。在HP UX系统中对应关系是这样:LUN——VG(逻辑磁盘)——对应多个LV(逻辑卷),并挂在文件系统和未格式化裸设备(raw device)——共享存储裸设备(shared raw device)。
5) 本次实施负载均衡方案是建立在加强网络数据处理能力,自动调节应用服务对两台节点上数据库的响应请求,分别对共享存储数据的读写服务操作,实现增加数据吞吐量和提高效率。
6) 单点故障自动切换:2台主机(node1:40、node2:42)连接共享裸设备存储,同时只有一台主机对一个物理设备进行读写操作。系统定时发送heartbeat信息,一旦node1发生故障,系统自动切换到node2上。
首先进行相应的网络规划,每台主机需要有4个局域网IP和2个私有IP,公共ip地址和浮动ip地址要在同一网段。如下表:
节点 |
主机名 |
IP |
描述 |
1 |
node1 |
10.150.70.40 |
公共ip地址,管理用 |
1 |
node1-vip |
10.150.70.41 |
浮动ip地址,提供对外的数据库服务 |
1 |
node1_priv |
192.168.10.31 |
心跳ip地址,节点间通讯和数据同步用 |
2 |
node2 |
10.150.70.42 |
公共ip地址,管理用 |
2 |
node2-vip |
10.150.70.43 |
浮动ip地址,提供对外的数据库服务 |
2 |
node2_priv |
192.168.10.32 |
心跳ip地址,节点间通讯和数据同步用 |
随后以本次双机集群设置为例(如图示:集群硬件故障时-单点故障自动切换示意图-正常状态),node1包含一个应用服务包、一个浮动IP(node1-vip)和若干系统进程及应用占用的硬盘。同样,node 2也包含一个应用服务包、一个浮动IP(node2-vip)和若干系统进程及应用占用的硬盘。node1-vip、node2-vip地址是固定的,node1、node2可以保证各自稳定的为前端用户提供服务所对应的数据服务。同时,集群系统中没有任何一台机器都在时刻运行,没有闲置,各自运行自己的应用,资源利用得到合理配置,性能得到最大发挥。
如果node1在集群系统中出现软硬件或者网络故障,MC/service guard自动将程序包控制权转移给node2。保证应用服务继续进行,同时所有负载压力加载到node2上。(如图示:集群硬件故障时-单点故障自动切换示意图-切换状态)
1.1 HP unix阵列盘信息
HP unix阵列盘信息:一共有10个磁盘设备: /dev/dsk/ c0t6d0、/dev/dsk/ c1t2d0、 /dev/dsk/ c2t6d0、/dev/dsk/ c5t15d0、 /dev/dsk/c4t15d1、/dev/dsk/ c4t15d2、/dev/dsk/ c4t15d3、/dev/dsk/ c4t15d4、/dev/dsk/c4t15d5、/dev/dsk/c4t15d6。
Class I H/W Path Driver S/W State H/W Type Description ======================================================================= disk 0 0/0/0/2/0.6.0 sdisk CLAIMED DEVICE HP 300 GMBA3300NC /dev/dsk/c0t6d0 /dev/rdsk/c0t6d0 /dev/dsk/c0t6d0s1 /dev/rdsk/c0t6d0s1 /dev/dsk/c0t6d0s2 /dev/rdsk/c0t6d0s2 /dev/dsk/c0t6d0s3 /dev/rdsk/c0t6d0s3 disk 1 0/0/0/2/1.2.0 sdisk CLAIMED DEVICE HL-DT-STDVD-RAM GH40L /dev/dsk/c1t2d0 /dev/rdsk/c1t2d0 disk 2 0/0/0/3/0.6.0 sdisk CLAIMED DEVICE HP 300 GMBA3300NC /dev/dsk/c2t6d0 /dev/rdsk/c2t6d0 /dev/dsk/c2t6d0s1 /dev/rdsk/c2t6d0s1 /dev/dsk/c2t6d0s2 /dev/rdsk/c2t6d0s2 /dev/dsk/c2t6d0s3 /dev/rdsk/c2t6d0s3 disk 3 1/0/12/0/0/0/0.1.0.255.14.15.0 sdisk CLAIMED DEVICE HITACHI DF600F /dev/dsk/c4t15d0 /dev/rdsk/c4t15d0 disk 4 1/0/12/0/0/0/0.1.0.255.14.15.1 sdisk CLAIMED DEVICE HITACHI DF600F /dev/dsk/c4t15d1 /dev/rdsk/c4t15d1 disk 5 1/0/12/0/0/0/0.1.0.255.14.15.2 sdisk CLAIMED DEVICE HITACHI DF600F /dev/dsk/c4t15d2 /dev/rdsk/c4t15d2 disk 6 1/0/12/0/0/0/0.1.0.255.14.15.3 sdisk CLAIMED DEVICE HITACHI DF600F /dev/dsk/c4t15d3 /dev/rdsk/c4t15d3 disk 7 1/0/12/0/0/0/0.1.0.255.14.15.4 sdisk CLAIMED DEVICE HITACHI DF600F /dev/dsk/c4t15d4 /dev/rdsk/c4t15d4 disk 8 1/0/12/0/0/0/0.1.0.255.14.15.5 sdisk CLAIMED DEVICE HITACHI DF600F /dev/dsk/c4t15d5 /dev/rdsk/c4t15d5 disk 9 1/0/12/0/0/0/0.1.0.255.14.15.6 sdisk CLAIMED DEVICE HITACHI DF600F /dev/dsk/c4t15d6 /dev/rdsk/c4t15d6 |
1.2 存储规划
HITACHI DF600F(日立存储)磁盘阵列划分为7个vDisk(LUN)全部映射到两台主机。
具体划分如下:
vDisk序号 |
容量/单位 |
磁盘设备 |
VG(逻辑磁盘) |
用途说明 |
3 |
1GB |
/dev/dsk/c4t15d0 |
/dev/datavg |
ASM spfile |
4 |
1GB |
/dev/dsk/c4t15d1 |
/dev/datavg |
OCR |
5 |
1GB |
/dev/dsk/c4t15d2 |
/dev/datavg |
ORC镜像 |
6 |
1GB |
/dev/dsk/c4t15d3 |
/dev/datavg |
RAC表决盘 |
7 |
1GB |
/dev/dsk/c4t15d4 |
/dev/datavg |
RAC表决盘镜像1 |
8 |
1GB |
/dev/dsk/c4t15d5 |
/dev/datavg |
RAC表决盘镜像2 |
9 |
700GB |
/dev/dsk/c4t15d6 |
/dev/vg00/lvoracle |
ASM 磁盘 |
1.3 VG共享模式(shared)状态
VG同时在两台的主机上(40和42)被激活。在应用Oracle OPS时,这里卷组被以一种共享的方式激活,数据的完整性必须由应用程序来保证。
因为操作系统本身无法保证数据的完整性,所以设成共享模式激活的卷组必须使用裸设备,这样OS不会对该设备进行缓冲,而完全交给应用程序处理。
应用VG的共享方式需要安装MC/SG OPS edition.,其控制命令是vgchange –a s/n /dev /datavg。
VG对应多个LV(逻辑卷,并挂在文件系统和共享裸设备(shared raw device)。这里对应系统VG逻辑磁盘是:/dev/datavg,包含oracle数据库安装、升级、加载信息等文件存储位置,都在这个/dev/datavg逻辑磁盘下,并划分进行相应的LV逻辑卷。以下是系统中oracle数据库文件对应的存储位置。
ll /dev/datavg/r* crw-r----- 1 oracle dba 64 0x020008 Sep 24 16:37 /dev/datavg/rdb_control01 crw-r----- 1 oracle dba 64 0x020009 Sep 24 16:37 /dev/datavg/rdb_control02 crw-r----- 1 oracle dba 64 0x02000a Sep 24 16:37 /dev/datavg/rdb_control03 crw-r----- 1 oracle dba 64 0x020020 Sep 24 16:37 /dev/datavg/rdb_fwms_01 crw-r----- 1 oracle dba 64 0x02001e Sep 24 16:37 /dev/datavg/rdb_lcam_01 crw-r----- 1 oracle dba 64 0x02001f Sep 24 16:37 /dev/datavg/rdb_lcam_02 crw-r----- 1 oracle dba 64 0x020014 Sep 24 16:37 /dev/datavg/rdb_redo1_01 crw-r----- 1 oracle dba 64 0x020015 Sep 24 16:37 /dev/datavg/rdb_redo1_02 crw-r----- 1 oracle dba 64 0x020016 Sep 24 16:37 /dev/datavg/rdb_redo1_03 crw-r----- 1 oracle dba 64 0x020017 Sep 24 16:37 /dev/datavg/rdb_redo1_04 crw-r----- 1 oracle dba 64 0x020018 Sep 24 16:37 /dev/datavg/rdb_redo1_05 crw-r----- 1 oracle dba 64 0x020019 Sep 24 16:37 /dev/datavg/rdb_redo2_01 crw-r----- 1 oracle dba 64 0x02001a Sep 24 16:37 /dev/datavg/rdb_redo2_02 crw-r----- 1 oracle dba 64 0x02001b Sep 24 16:37 /dev/datavg/rdb_redo2_03 crw-r----- 1 oracle dba 64 0x02001c Sep 24 16:37 /dev/datavg/rdb_redo2_04 crw-r----- 1 oracle dba 64 0x02001d Sep 24 16:37 /dev/datavg/rdb_redo2_05 crw-r----- 1 oracle dba 64 0x02000c Sep 24 16:37 /dev/datavg/rdb_sysaux01 crw-r----- 1 oracle dba 64 0x02000d Sep 24 16:37 /dev/datavg/rdb_system01 crw-r----- 1 oracle dba 64 0x02000e Sep 24 16:37 /dev/datavg/rdb_temp01 crw-r----- 1 oracle dba 64 0x02000f Sep 24 16:37 /dev/datavg/rdb_temp02 crw-r----- 1 oracle dba 64 0x020010 Sep 24 16:37/dev/datavg/rdb_undo1_01 crw-r----- 1 oracle dba 64 0x020011 Sep 24 16:37 /dev/datavg/rdb_undo1_02 crw-r----- 1 oracle dba 64 0x020012 Sep 24 16:37 /dev/datavg/rdb_undo2_01 crw-r----- 1 oracle dba 64 0x020013 Sep 24 16:37 /dev/datavg/rdb_undo2_02 crw-r----- 1 oracle dba 64 0x02000b Sep 24 16:37 /dev/datavg/rdb_users01 crw-r----- 1 oracle dba 64 0x020026 Sep 24 16:37 /dev/datavg/rlvexp crw-r----- 1 oracle dba 64 0x02002b Sep 24 16:37 /dev/datavg/rlvwz_01 crw-r----- 1 oracle dba 64 0x02002c Sep 24 16:37 /dev/datavg/rlvwz_02 crw-r----- 1 oracle dba 64 0x02002d Sep 24 16:37 /dev/datavg/rlvwz_03 crw-r----- 1 oracle dba 64 0x02002e Sep 24 16:37 /dev/datavg/rlvwz_04 crw-r----- 1 oracle dba 64 0x02002f Sep 24 16:37 /dev/datavg/rlvwz_05 crw-r----- 1 oracle dba 64 0x020030 Sep 24 16:37 /dev/datavg/rlvwz_06 crw-r----- 1 oracle dba 64 0x020031 Sep 24 16:37 /dev/datavg/rlvwz_07 crw-r----- 1 oracle dba 64 0x020032 Sep 24 16:37 /dev/datavg/rlvwz_08 crw-r----- 1 oracle dba 64 0x020033 Sep 24 16:37 /dev/datavg/rlvwz_09 crw-r----- 1 oracle dba 64 0x020034 Sep 24 16:37 /dev/datavg/rlvwz_10 crw-r----- 1 oracle dba 64 0x020035 Sep 24 16:37 /dev/datavg/rlvwz_11 crw-r----- 1 oracle dba 64 0x020036 Sep 24 16:37 /dev/datavg/rlvwz_12 crw-r----- 1 oracle dba 64 0x020037 Sep 24 16:37 /dev/datavg/rlvwz_13 crw-r----- 1 oracle dba 64 0x020038 Sep 24 16:37 /dev/datavg/rlvwz_14 crw-r----- 1 oracle dba 64 0x020021 Sep 24 16:37 /dev/datavg/rlvwz_15 crw-r----- 1 oracle dba 64 0x020022 Sep 24 16:37 /dev/datavg/rlvwz_16 crw-r----- 1 oracle dba 64 0x020023 Sep 24 16:37 /dev/datavg/rlvwz_17 crw-r----- 1 oracle dba 64 0x020024 Sep 24 16:37 /dev/datavg/rlvwz_18 crw-r----- 1 oracle dba 64 0x020025 Sep 24 16:37 /dev/datavg/rlvwz_19 crw-r----- 1 oracle dba 64 0x02003f Sep 24 16:37 /dev/datavg/rlvwz_archives01 crw-r----- 1 oracle dba 64 0x020039 Sep 24 16:37/dev/datavg/rlvwz_archives02 crw-r----- 1 root oinstall 64 0x020004 Sep 24 16:37 /dev/datavg/rora_crs01 crw-r----- 1 root oinstall 64 0x020005 Sep 24 16:37 /dev/datavg/rora_crs02 crw-r----- 1 oracle dba 64 0x020007 Sep 24 16:37 /dev/datavg/rora_pwd crw-r----- 1 oracle dba 64 0x020006 Sep 24 16:37 /dev/datavg/rora_spfile crw-r----- 1 oracle dba 64 0x020001 Sep 24 16:37 /dev/datavg/rora_vote01 crw-r----- 1 oracle oinstall 64 0x020002 Sep 24 16:37 /dev/datavg/rora_vote02 crw-r----- 1 oracle oinstall 64 0x020003 Sep 24 16:37 /dev/datavg/rora_vote03 |
2、双机热备(VG独占模式)方案
此类是纯应用服务器的集群,即各个应用服务器都访问统一的数据库服务器,但彼此间并不需要文件共享存储等,这种集群是比较简单的。
2.1 VG独占模式(exclusive)状态
当2台主机共享一个VG时,可以在2台主机上激活VG,那么其中随意一台主机都可以对数据进行修改,而其他的主机却不知道数据已被改变,这样数据的完整性无法保证。
所以在Cluster环境下,将共享VG的属性置为exclusive模式。这样,当一台主机已经以exclusive模式激活VG之后,在其他的主机上无法再激活这个VG,这样就保证了数据的完整性。应用VG独享方式需要安装MC/SG,其控制命令是vgchange –c y/n vgXX。
3 两种模式优缺点
a) 不采用共享的存储设备,只通过软件方式实现双机热备。
优点:节约了昂贵的存储设备投资。本机数据可以直接在多台主机间流动。
缺点:会产生数据的前后不一致、或者会影响数据库读取的速度。闲置服务器资源。
举例:如果在服务中断时切换到备份服务器,则可能有少量已经在主机完成的事务在备机上尚未实现。而与备份数据的恢复不同,备机启动后,后面的操作已经进行,因此丢失的数据包要找回就相当难。故此种方式适用于对于丢失少量数据不是非常敏感的系统。
b) 采用共享的存储设备,通过软件方式实现双机热备。
优点:可以在无人值守的情况下提供快速的切换,并且不会有数据丢失现象。
缺点:购买存储设备花费会比较高。
举例:目前双机热备主流方式是这种软硬件结合方式,本次测试实施内容也是HP UX共享存储的双机热备框架。