分类: Oracle
2008-04-21 19:02:02
文章摘要
24*7(有些叫法也为24*7*365)的高可用系统越来越多的受到广泛重视与应用,那是因为在实际环境中,不间断的系统代表的就是不间断的义务收入。但是
◆怎么样搭建与管理24*7的高可用环境?
◆各种各样的高可用环境之间到底有什么差别?
◆我们是否适合于哪种环境?
◆现在高可用环境的主要方式以及以后的发展趋势是什么?
这些话题,都是决策者与实施者都应当考虑的,也是本文所探讨的,我们需要搭建一个怎么样的高可用环境,才能真正做到最适合。
一、什么是高可用(High Availability)
在高可用的解释方面,有人给出了如下的诠释:
(1)系统失败或崩溃 (system faults and crashes)
(2)应用层或者中间层错误 (application and middleware failures)
(3)网络失败 (network failures)
(4)介质失败,一般指存放数据的媒体故障 (media failures)
(5)人为失误 (Human Error)
(6)容灾 (Disasters and extended outages)
(7)计划宕机与维护 (Planned downtime, maintenance and management tasks)
可见,高可用不仅仅包含了系统本身故障,应用层的错误,人为错误等等,还应当包括数据冗余、容灾以及计划的维护时间,也就是说,一个真正的高可用环境,不仅仅是能避免系统本身的问题,还应当能防止天灾人祸,以及有一个简单可靠的系统维护方法(如微码升级、软件升级等等计划停机维护)。
现在高可用的计算方法一般以年在线率来计算,如规定一年之中的可用环境要达到99.95%,那么24*365*(1-99.95%)=4.38小时(包括维护时间)。那么假定一个系统本身一年之中故障时间是1小时,但是计划维护时间却花了20小时,那么这个系统也不能算是一个满足设计要求的高可用环境。
现阶段使用环境中,基本没有真正的100%的在线环境,或者说,如果达到100%的在线能力,将花费非常多的代价,所以一般能达到99.95%以上的可用性的环境,一般都可以认为是高可用环境。
对于高可用性在线效率的计算,我们可以参考如下方法:
图1 |
在公司收益与投入成本计算方面取得一个平衡,则是我们所希望的在线效率,但是收益与成本的计算方法则是决策者与实施者需要着重考虑的问题了,也是我们下面希望能试图解释的问题。
二、Oracle高可用相关功能的产品概述
因为高可用的范围定义太广泛,本文我们只讨论与Oracle数据库有关系的高可用设计,如数据库主机的错误,数据所在的存储错误,介质损坏以及主机与数据的冗余保护等等,并不讨论应用层的设计,Oracle 提供支持high availability 相关产品主要有下面几种:
(1) Oracle Parallel Server(8i)/ Real Application Cluster(9i/10g)
(2) Oracle Standby Database(8i)/Oracle Data Guard(9i/10g)
(3) Oralce Advanced Replication(8i)/Oracle Stream(9i/10g)
(4) Oracle Server HA
(5) Other: Mv/RMAN/Oracle Log Miner/Oracle Flashback Query(9/10gi)
等等,还有其他很多小的功能,如在线表的重定义,新的安全审计功能等,也都是为在线系统而设计的,但是,我们这里主要只考虑构架方面的高可用设计,也就是与成本有关系的高可用设计,怎么样达到成本与收益的最大平衡。
所以,我们将主要讨论的是Oracle OPS/RAC、Standby/Ddata guard、Advanced Replocation/Stream以及与Oracle Server相关的OS HA(双机)。
1、OPS /RAC
OPS/RAC 最原始的设计初衷就是system/application high availability。与其他产品相比较: OPS/RAC 是多个服务器的cluster,组成具有更大计算处理能力与故障处理能力的集群。cluster 里面不同的 node 使用一个(一般是一个)或多个oracle instances 与一个database 连接(Shared Storage)。
主要的技术特点:
(1) database 所有的data files 是建立在共享存储(Shared Storage)上面的,一般可以采用raw设备,共享文件系统或者是ASM(10g提供),因此在技术方面对OS 的设置有很高的依赖性,需要有OS支持的cluster软件。
(2) OPS/RAC在共享存储方面并没有冗余保护,不具备在共享存储阵列损坏的情况下具有切换的能力,因此 media failure 方面,要依靠RAID (redundant array of inexpensive disk) Subsystem、LV镜相(LV Mirror)、卷复制(Volume Replication)或者是Standby/Data guard来实现数据的冗余保护。
(3)该技术是Oracle近来主推的技术,特别是10g以后的网格计算与线型扩展能力,在电信、移动、银行行业使用广泛。如果还是老的OPS,则不建议再使用,但是9i以后的Rac技术逐渐成熟,可以使用在高可用环境下,但是其管理成本与技术的复杂性,则也是需要考虑的。