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

简介: 谁说阿里云不能跑Oracle,让驻云架构师告诉你怎么办!

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

以下正文:

· 关于阿里云的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功能。


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


                                                                                                                                                                                                                          在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架构如下图:


一般是由有两台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的服务。


我们来看看下面这幅图

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


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


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

  1. 如果ECS服务不终止,数据库角色做切换,havip如何漂移?

  2. 如果ECS服务强制停止了,Havip如何漂移到备用环境?

 

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


·  实现思路

     1:首先我们先创建一套Dataguard环境,为了保证切换后连接池无需改动,两台ECS上的DB的sid必须一致。


    2: oracle的dataguard 通过DGbroker管理,当primary db崩溃physical standby db自动切换为primary;这里必须把observer启动在STANDBY上面,我们试过在管理控制台上强制关闭ecs,如果observer所在的ECS被强制关闭,dgbroker无法做主备切换。


    3: 接下来,将这两台ECS加载到HAVIP服务的集群挂载进集群的时候,可以看到两台ECS都是虚线连接,而且都是(备),这里,我们就要开始部署keepalived服务了。


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访问了。


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

注意配置文件中的这两段



这里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 的各种配置文件:




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


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



相关实践学习
借助OSS搭建在线教育视频课程分享网站
本教程介绍如何基于云服务器ECS和对象存储OSS,搭建一个在线教育视频课程分享网站。
7天玩转云服务器
云服务器ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,可降低 IT 成本,提升运维效率。本课程手把手带你了解ECS、掌握基本操作、动手实操快照管理、镜像管理等。了解产品详情: https://www.aliyun.com/product/ecs
相关文章
|
4月前
|
弹性计算 运维 安全
阿里云资深架构师经验分享——DevSecOps最佳实践
本文将分享阿里云在DevSecOps中设计环节的实践经验,希望能够让大家理解阿里云是如何保障产品安全水位,并希望这些经验能够帮助到正在尝试落地DevSecOps解决方案的企业。
773 167
阿里云资深架构师经验分享——DevSecOps最佳实践
|
3月前
|
弹性计算 负载均衡 网络协议
阿里云SLB深度解析:从流量分发到架构优化的技术实践
本文深入探讨了阿里云负载均衡服务(SLB)的核心技术与应用场景,从流量分配到架构创新全面解析其价值。SLB不仅是简单的流量分发工具,更是支撑高并发、保障系统稳定性的智能中枢。文章涵盖四层与七层负载均衡原理、弹性伸缩引擎、智能DNS解析等核心技术,并结合电商大促、微服务灰度发布等实战场景提供实施指南。同时,针对性能调优与安全防护,分享连接复用优化、DDoS防御及零信任架构集成的实践经验,助力企业构建面向未来的弹性架构。
316 76
|
1月前
|
消息中间件 存储 大数据
阿里云消息队列 Kafka 架构及典型应用场景
阿里云消息队列 Kafka 是一款基于 Apache Kafka 的分布式消息中间件,支持消息发布与订阅模型,满足微服务解耦、大数据处理及实时流数据分析需求。其通过存算分离架构优化成本与性能,提供基础版、标准版和专业版三种 Serverless 版本,分别适用于不同业务场景,最高 SLA 达 99.99%。阿里云 Kafka 还具备弹性扩容、多可用区部署、冷热数据缓存隔离等特性,并支持与 Flink、MaxCompute 等生态工具无缝集成,广泛应用于用户行为分析、数据入库等场景,显著提升数据处理效率与实时性。
|
3月前
|
存储 机器学习/深度学习 算法
阿里云X86/ARM/GPU/裸金属/超算等五大服务器架构技术特点、场景适配与选型策略
在我们选购阿里云服务器的时候,云服务器架构有X86计算、ARM计算、GPU/FPGA/ASIC、弹性裸金属服务器、高性能计算可选,有的用户并不清楚他们之间有何区别。本文将深入解析这些架构的特点、优势及适用场景,帮助用户更好地根据实际需求做出选择。
|
3月前
|
Cloud Native Serverless 流计算
云原生时代的应用架构演进:从微服务到 Serverless 的阿里云实践
云原生技术正重塑企业数字化转型路径。阿里云作为亚太领先云服务商,提供完整云原生产品矩阵:容器服务ACK优化启动速度与镜像分发效率;MSE微服务引擎保障高可用性;ASM服务网格降低资源消耗;函数计算FC突破冷启动瓶颈;SAE重新定义PaaS边界;PolarDB数据库实现存储计算分离;DataWorks简化数据湖构建;Flink实时计算助力风控系统。这些技术已在多行业落地,推动效率提升与商业模式创新,助力企业在数字化浪潮中占据先机。
234 12
|
6月前
|
Java Linux C语言
《docker基础篇:2.Docker安装》包括前提说明、Docker的基本组成、Docker平台架构图解(架构版)、安装步骤、阿里云镜像加速、永远的HelloWorld、底层原理
《docker基础篇:2.Docker安装》包括前提说明、Docker的基本组成、Docker平台架构图解(架构版)、安装步骤、阿里云镜像加速、永远的HelloWorld、底层原理
686 90
|
4月前
|
存储 弹性计算 运维
阿里云通用算力型U1实例怎么样?u1实例技术架构、场景适配与优惠价格参考
阿里云服务器ECS 通用算力型u1实例2核4G,5M固定带宽,80G ESSD Entry盘,企业用户专享优惠价格199元1年,很多用户关心这个款云服务器怎么样?阿里云通用算力型U1实例自推出以来,凭借独特的"均衡算力+智能调度"设计理念,在IaaS市场开辟出差异化的竞争赛道。本文将通过技术架构解析、典型场景适配分析、全生命周期成本测算三个维度,全面解构这款热门云服务器实例的核心价值,以供参考和选择。
|
7月前
|
弹性计算 运维 监控
阿里云云服务诊断工具:合作伙伴架构师的深度洞察与优化建议
作为阿里云的合作伙伴架构师,我深入体验了其云服务诊断工具,该工具通过实时监控与历史趋势分析,自动化检查并提供详细的诊断报告,极大提升了运维效率和系统稳定性,特别在处理ECS实例资源不可用等问题时表现突出。此外,它支持预防性维护,帮助识别潜在问题,减少业务中断。尽管如此,仍建议增强诊断效能、扩大云产品覆盖范围、提供自定义诊断选项、加强教育与培训资源、集成第三方工具,以进一步提升用户体验。
830 243
|
4月前
|
运维 安全 弹性计算
基于阿里云的开源应用智能管理架构设计与工程实践
本文以Websoft9技术方案为例,探讨企业级应用管理的范式。通过解析开源应用管理面临的部署复杂性、运维低效性和知识碎片化三大挑战,提出基于阿里云的三层架构:智能应用管理门户、核心功能层和基础设施层。文章详细阐述了应用编排标准化(IaC实践)、智能运维体系构建及知识资产数字化的技术实现路径,并结合金融与制造行业的案例,展示解决方案的实际效果。最后提供开发者资源与工具链支持,助力企业高效管理应用。
197 1

热门文章

最新文章