谁说阿里云不能跑Oracle，让驻云架构师告诉你怎么办！-阿里云开发者社区

开发者社区> 数据库> 正文
登录阅读全文

谁说阿里云不能跑Oracle，让驻云架构师告诉你怎么办！

驻云科技 2016-03-09 12666浏览量

简介： 谁说阿里云不能跑Oracle，让驻云架构师告诉你怎么办！

58e3d8465ca3f89b3e9f469177b4f2525f130796

本文作者，缪睿，来自驻云信息的云计算资深数据库架构师。

以下正文：

· 关于阿里云的HAVIP


阿里云官方文档的介绍：

私网高可用虚拟IP（Private High-Availability Virtual IP Address，简称HaVip），是一种可以独立创建和释放的私网IP资源。这种私网IP的特殊之处在于，用户可以在ECS上使用协议进行该IP的宣告。

  • 一个HaVip对象可以与最多两台ECS实例进行绑定；绑定了的实例可以通过ARP方式进行该私网IP的宣告。
  • 一台ECS实例可以在持有一个普通私网IP的情况下，可以宣告多个HaVip类型的私网IP，从而同时持有多个私网IP。
  • 利用可在ECS进行私网IP宣告的功能，可以 实现基于VRRP协议的高可用方案,包括keepalived、heartbeat等成熟的开源方案。
  • HaVip可以与EIP进行绑定，从而实现HaVip在ECS实例间切换时，发向EIP的消息也被重定向到新的ECS实例上。
  • HaVip仅支持VPC网络环境。Classic网络环境下不提供HaVip功能。

文字多了理解起来困难，直接看图。

02520b5f4d34ddb248d8184883add1cd6025aa1c

在vpc-23c099ge5中有个交换机vsw-23a3275jc的交换机，交换机下有个HAVIP是10.10.1.99，在这个高可用虚拟IP下挂载了两台ECS,那10.10.1.99 这个IP地址就可以在这两台ECS上飘来飘去了。

·  Keepalived是什么？

keepalived是一个类似于layer3、4、7交换机制的软件，也就是我们平时说的第3层、第4层和第7层交换。Keepalived的作用是检测web服务器的状态，如果有一台web服务器死机，或工作出现故障，Keepalived将检测到，并将有故障的web服务器从系统中剔除，当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中，这些工作全部自动完成，不需要人工干涉，需要人工做的只是修复故障的web服务器。

但是在这里，keepalived的作用是与HAVIP通信，目的是将HAVIP指向到我们开启了keepalived服务的那台ECS上。

· 关于阿里云的Oracle的高可用

         有着Oracle背景的DBA们都知道，Oracle的高可用集群是Real Application Cluster（RAC），但是搭建RAC集群需要几个硬性条网络通讯模式得是广播

  1. 网络通讯模式得是广播
  2. 必须有两个网络分别用于心跳链路与公网服务
  3. 共享存储 （可以使用NFS挂载来解决）

这网络广播模式在阿里云上就无法跳过，更不用说VPC环境下只能有一个网卡地址，只能考虑使用其他的方案来解决OracleDB的高可用环境。


有过阿里云RDS经验的同学都知道，RDS的高可用是通过主备库的服务切换来实现的，当主库损坏的情况下，备库会在很短时间内接管服务，其代价就是在切换过程中session会断开造成短时间的数据库服务中断，大概在30秒左右。而我们在阿里云上实现Oracle高可用也是类似这种方式实现。


言归正传，接下来我们说说如何在阿里云上部署这套高可用方案。


传统方式下的Dataguard架构如下图：

c70076277c546a788488e840d2e3d1ebe52ee5a7

一般是由有两台ECS，IP地址分别为10.10.1.2，与10.10.1.3，这两台ECS上部署着一套Oracle PRIMARY-STANDBY环境，这套Dataguard方案使用Oracle dgbroker管理，当PRIMARY库崩溃的时候，Standby会主动的接管服务，但是这里大家都知道，Oracle database的访问是需要通过listener的，我们两台ECS默认的IP地址是不同的，这样当standby接管服务后，application的数据库连接池要把IP改为10.10.1.3才能再次连接数据库服务，大家都知道，连接池地址的改动是要重启容器，如果application都需要重启，就完全不能称做高可用了，很庆幸，阿里云提供了一个叫做havip的服务。


我们来看看下面这幅图

8afb68710361c9945e3d8cae59bf7cfe9b99b2c1

这里我们在ECS原IP的基础上，加入了HAVIP的概念，application 通过10.10.1.99这个IP地址访问数据库服务，当PRIMARY与STANDBY角色互换之后。

948083269797422b839be826fe23585e94f5d979

      application依然还是通过10.10.1.99访问数据库服务，只是这个IP地址已经漂移到我们曾经的standbyDB了。大家都知道Oracle的RAC环境是必须共享存储的，也就是说当物理文件损坏的时候，整个数据库服务依然还是会崩溃。上面这套HAVIP+Dataguard的方案既实现了数据库物理层面的灾备，同时可以实现数据库服务停止后的快速接管。


     以上就是这套方案的框架图，说起来很简单，但是实现起来就麻烦了，主要两个难点：

  1. 如果ECS服务不终止，数据库角色做切换，havip如何漂移？
  2. 如果ECS服务强制停止了，Havip如何漂移到备用环境？

 

要解决这两个问题，我们就要用到我们的keepalived了，具体的实现思路，我们来看看。


·  实现思路

      1：首先我们先创建一套Dataguard环境，为了保证切换后连接池无需改动，两台ECS上的DB的sid必须一致。
bfd183da528e02a96f25ce7950c1af00965dbd4d
     2： oracle的dataguard 通过DGbroker管理，当primary db崩溃physical standby db自动切换为primary;这里必须把observer启动在STANDBY上面，我们试过在管理控制台上强制关闭ecs，如果observer所在的ECS被强制关闭，dgbroker无法做主备切换。
8cd13bcc6627e06561f4b34ed61ba1b16a773632
     3： 接下来，将这两台ECS加载到HAVIP服务的集群挂载进集群的时候，可以看到两台ECS都是虚线连接，而且都是（备），这里，我们就要开始部署keepalived服务了。
932f1381d1fafe64cf7106d8dcc76a4dfd964254

4：通过keepalived做一个master->backup的配置集群启动，这里贴出两份配置文件这里master (10.10.1.2) backup(10.10.1.3)master配置文件keepalived.conf



! Configuration File for keepalived

global_defs {


         router_id LVS_DEVEL   #集群的ID 主备两台机器的这名字得一样

}

#检查脚本，keepalived会定时的执行shell做检查

vrrp_script chk_http_port {

     script  "/etc/keepalived/mcheckdb.sh" 

     interval 2

     weight 2

}

      vrrp_instance VI_1 {

          state MASTER

          interface eth0

          virtual_router_id 51

          priority 100

          advert_int 1

          authentication {

              auth_type PASS

              auth_pass 1111

          }

      track_script {

                chk_http_port

         }

          virtual_ipaddress {

              10.10.1.99 dev eth0 label eth0:havip  #havip

         }

          unicast_src_ip 10.10.1.2   #本地IP

          unicast_peer {

                  10.10.1.3   #备机IP

                       }

      }

Backup 配置文件

keepalived.conf


! Configuration File for keepalived

 global_defs {

           router_id LVS_DEVEL

        }

vrrp_script chk_http_port {

     script  "/etc/keepalived/scheckdb.sh"

     interval 2

     weight 2

}

        vrrp_instance VI_1 {

            state BACKUP

            interface eth0

            virtual_router_id 51

            priority 99

            advert_int 1

            authentication {

                auth_type PASS

                auth_pass 1111

            }

      track_script {

         chk_http_port

       }

            virtual_ipaddress {

              10.10.1.99 dev eth0 label eth0:havip

        }

            unicast_src_ip 10.10.1.3

            unicast_peer {

                    10.10.1.2

                         }

        }

 


这里我们假设两个场景，keepalived启动后。


1、10.10.1.2使用了master（primary）配置文件，10.10.1.3使用了backup（standby）配置文件。当primary db与standby db互换了角色，而这时候havip依然是与master也就是10.10.1.2这台绑定。


2、10.10.1.2使用了master（primary）配置文件，10.10.1.3使用了backup（standby）配置文件。我们强制关闭了10.10.1.2这台ECS，这时候havip漂移到了backup机器

上，standby db也变成了primary角色，当我们再次启动10.10.1.2这台ECS后，havip又会飘回master配置文件所在的ECS,这时候数据库服务又无法通过havip访问了。


这里该如何去解决这个问题呢？面对上面的两个场景，我们取了个巧。

注意配置文件中的这两段


1beaf898e9055ec5f4a86d2412a2ee63edecfd3e
1df0fbb4833bc0a8e4e01378dd5a3d188a280dd2

这里shell都会定时的在ECS上执行用于检查环境配置。那么既然可以写逻辑，还有什么不能实现？

说到这，大家是不是很想看看shell的代码~

首先我们看看master的检查逻辑

mcheckdb.sh


#!/bin/bash

max_sn="PRIMARY"

su - oracle  -c "sh /etc/keepalived/oracle/dbrole.sh"

max_sn=`cat /etc/keepalived/oracle/dbrole`

if [ "$max_sn" != "PRIMARY" ]

then

    cat /etc/keepalived/samples/backup.keepalived.conf > /etc/keepalived/keepalived.conf

    /etc/init.d/keepalived restart

    echo `date` > /etc/keepalived/date

fi;

很简单的逻辑，切换到oracle用户执行一个dbrole.sh，这个shell会执行Oracle db的角色查询，然后把结果写在/etc/keepalived/oracle/dbrole这个文件中。如果结果不是’PRIMARY’就把/etc/keepalived/samples/backup.keepalived.conf 文件内容替换掉当前keepalived进程使用的配置文件，然后再重启keepalived 服务。到这儿，大家应该知道如何做了吧。

scheckdb.sh


#!/bin/bash

max_sn="PHYSICAL STANDBY"

su - oracle  -c "sh /etc/keepalived/oracle/dbrole.sh"

max_sn=`cat /etc/keepalived/oracle/dbrole`

if [ "$max_sn" = "PRIMARY" ]

then

    cat /etc/keepalived/samples/master.keepalived.conf > /etc/keepalived/keepalived.conf

    /etc/init.d/keepalived restart

    #echo "stop keepalived"

#打开监听

#su - oracle  -c " lsnrctl start listener2"

fi;

scheckdb.sh的内容大同小异样,不过多了一步，打开监听listener2,这listener2，就是开启HAVIP的监听地址。

我们可以在两台ECS上都准备好master与backup 两份配置文件，这样不但解决了上面两个场景的问题，还直接让havip可以根据数据库的角色做漂移，保证在dataguard可用的前提下，时刻漂移在我们的primary database。


最后，给大家提供一些代码与一个小工具。


Keepalived 的各种配置文件：


下载地址：http://jiagouyun-cn.oss-cn-hangzhou.aliyuncs.com/oracle/keepalived/keepalived.zip


解压后把整个keepallived 目录直接放到/etc下，注意其中有个oracle目录，包括其中的文件必须改成oracle用户的权限。


再提供提供一个配置DG的shell工具，大家没事可以用用，脚本有针对性，仅用于学习不建议配置生产环境时使用。


下载地址：http://jiagouyun-cn.oss-cn-hangzhou.aliyuncs.com/oracle/dataguard.1.3.zip

弹性计算 Oracle 关系型数据库 Shell 数据库 RDS 架构师 存储 数据库管理 容器

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

分享：
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿，解构实战干货，推动数据库技术变革

其他文章
展开