作者:
Uwe Hesse
Oracle高可用架构是我所讲课程里的一个热门话题,本文尝试对此话题做一个总体的说明,内容涵盖”普通的”单实例数据库,DataGuard,RAC以及扩展RAC(有时也被称为”伸展集群”)。Rac与Dataguard组合在一起就是Oracle公司推广的最大可用性架构( Maximum Availability Architecture,MAA)。除这些Oracle的HA解决方案外,我还会简单介绍一个第三方的HA解决方案(远程镜像,Remote Mirroring)。我不准备深入介绍所有这些解决方案的细节,而只是想做出一点区分的工作,并简要介绍它们各自的优势以及可能的缺陷。
Oracle高可用架构是我所讲课程里的一个热门话题,本文尝试对此话题做一个总体的说明,内容涵盖”普通的”单实例数据库,DataGuard,RAC以及扩展RAC(有时也被称为”伸展集群”)。Rac与Dataguard组合在一起就是Oracle公司推广的最大可用性架构( Maximum Availability Architecture,MAA)。除这些Oracle的HA解决方案外,我还会简单介绍一个第三方的HA解决方案(远程镜像,Remote Mirroring)。我不准备深入介绍所有这些解决方案的细节,而只是想做出一点区分的工作,并简要介绍它们各自的优势以及可能的缺陷。
首先,我们将考察目前为止仍然是应用最为广泛的Oracle数据库架构:单实例数据库。一个Oracle数据库总是由一个数据库(由数据文件、在线重做日志控制文件组成)与一个实例(有内存结构,比如数据库高速缓冲区,以及后台进程,例如数据库写进程)组成。如果我们有一个数据库以及多个访问这个数据库的实例,这就是一个RAC。如果只有一个实例访问这个数据库,就是单实例数据库。下图是一个所有组件都存储在一个服务器上的简单安装版本:
![singleinstance1.gif](http://lh3.ggpht.com/_Tj8VUwhrzbg/S6Mog-C4GOI/AAAAAAAAAJc/BHT6vkdJPBs/singleinstance1.gif)
将数据库文件放置在SAN(存储区域网络)的配置也是目前比较常见的配置,如下图所示:
![singleinstance2.gif](http://lh5.ggpht.com/_Tj8VUwhrzbg/S6MohF2tLPI/AAAAAAAAAJg/Z5HOO1nLm0A/singleinstance2.gif)
从高可用的角度来看,这个架构是非常脆弱的:服务器A与服务器B都是单点故障,数据库A与数据库B也都是单点故障,从而这些服务器所在的站点也是单点故障。这样,只要其中一个单点发生故障,整个数据库将不可用。一个”普通的”RAC就是为了解决其中的服务器单点故障的,如下图所示:
![rac.gif](http://lh4.ggpht.com/_Tj8VUwhrzbg/S6MoczU9CqI/AAAAAAAAAJQ/2jsB5-Bv4_8/rac.gif)
如果两个服务器的其中一个发生故障,数据库C将仍然可用。当然,使用RAC并不仅仅是为了实现HA。在使用RAC的其它的理由中,一个比较可靠的理由是为了实现伸缩性(Scalability):如果应用需求在将来出现增长,我们可以通过添加新的节点(Node)到集群中来解决。另外,通过使用RAC我们还可以选择使用服务管理(Service-Management)与负载均衡(Load Balance)。简言之,RAC不仅仅是HA,在此详述其它原因已经超出本文的范畴了。从HA的视角看,使用RAC的缺陷是:数据库C以及相应的站点C是单点。如果站点C发生故障(比如火灾),数据库C将不可用。因此,将数据库伸展到两个站点就成为我们的选择了,这也是通常所说的扩展RAC。
![extendedrac.gif](http://lh6.ggpht.com/_Tj8VUwhrzbg/S6Moc1lfpVI/AAAAAAAAAJM/zfgHb_jsZfg/extendedrac.gif)
现在,这两个站点就不再是单点了。数据库D是在两个站点之间做镜像的。这个架构的缺陷是两个站点之间的网络连接的成本。如果两个站点之间的距离比较远的话,这很关键,因为需要镜像的数据量会非常大。实际上,这使得两个站点之间的距离局限于几公里以内,而这与想要实现的灾难保护目标之间有冲突。这时,Dataguard就隆重登场了:利用DataGuard,我们很容易就可以实现长距离的灾难保护,因为,此时我们不再需要传输所有的数据量,而仅仅需要传输(相对小)的重做日志。在下图中,每个服务器都像上面的服务器A与服务器B一样,只有一个实例:
![dataguard1.gif](http://lh6.ggpht.com/_Tj8VUwhrzbg/S6Mochb8b4I/AAAAAAAAAJI/P8Uc-jrNfRg/dataguard1.gif)
备用数据库由来自主数据库的 重做日志。 当主库发生故障时,我们可以失败切换( Failover)到备库上并继续有效工作。这个失败切换工作可以由一个Observer(观察员程序,通常称为快速启动失败切换, Fast-Start Failover)自动实现。两个站点之间的距离达到几千公里(依赖于重做日志的传输策略与保护级别( protection level))。如果我们将RAC与Dataguard集合起来,我们就实现了MAA。显然,MAA是一个昂贵的解决方案,不过它也同时享有RAC与Dataguard的所有好处。
远程镜像是一个广受欢迎的第三方HA解决方案,总体上,它的架构与下图类似:
![remotemirroring.gif](http://lh6.ggpht.com/_Tj8VUwhrzbg/S6ModRrxi7I/AAAAAAAAAJY/RGdK6iFBT5s/remotemirroring.gif)
这时,也没有哪个站点是单点的,类似于使用扩展RAC架构。这个 解决方案的缺陷是:站点间的距离也是严格受限制的,理由与扩展RAC架构类似。同时,在镜像进行的时候,第二个站点是无法提供服务的,这一点与上述的Oracle提供的HA解决方案不同。使用RAC时,所有的服务器与相应的站点都可以提供服务。哪怕是使用Dataguard,备用数据库也不仅仅是等待主库发生故障。除此之外,它还可以提供只读访问服务,这将可以有效降低主库的负载。
![realtimequery.gif](http://lh5.ggpht.com/_Tj8VUwhrzbg/S6ModAA9GII/AAAAAAAAAJU/uGYJm45tRyc/realtimequery.gif)
上图展示了Oracle 11g的新特性”物理备用数据库上的实时查询”。在恢复过程中时,备用数据库也在同时提供只读访问。另外,还可以在物理备库( Physical Standby)上做离线备份(OffLoad Backup)。
附注:
其实还有另外一种可选择的架构, 基于Data Guard与单实例的一个结合。
类似于上面介绍的远程Data Guard方案,做了一点修正:将当前主库的一组Redo 日志放到远程(当然也受限于距离所产生的San 访问延时)。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/9399028/viewspace-682262/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/9399028/viewspace-682262/