oracle集群及相关技术分析.docx
- 文档编号:9914621
- 上传时间:2023-02-07
- 格式:DOCX
- 页数:90
- 大小:5.46MB
oracle集群及相关技术分析.docx
《oracle集群及相关技术分析.docx》由会员分享,可在线阅读,更多相关《oracle集群及相关技术分析.docx(90页珍藏版)》请在冰豆网上搜索。
oracle集群及相关技术分析
(一)集群概念介绍
集群概念介绍
集群术语须知
服务硬件:
指提供计算服务的硬件,比如PC机、PC服务器。
服务实体:
服务实体通常指服务软体和服务硬体。
节点(node):
运行Heartbeat进程的一个独立主机称为节点,节点是HA的核心组成部分,每个节点上运行着操作系统和Heartbeat软件服务。
资源(resource):
资源是一个节点可以控制的实体,当节点发生故障时,这些资源能够被其他节点接管。
如:
磁盘分区、文件系统、IP地址、应用程序服务、共享存储
事件(event):
事件也就是集群中可能发生的事情,例如节点系统故障、网络连通故障、网卡故障和应用程序故障等。
这些事件都会导致节点的资源发生转移,HA的测试也是基于这些事件进行的。
什么是集群
集群(cluster)就是一组计算机,它们作为一个整体向用户提供一组网络资源,这些单个的计算机系统就是集群的节点(node)。
集群提供了以下关键的特性。
(一)可扩展性。
集群的性能不限于单一的服务实体,新的服务实体可以动态的加入到集群,从而增强集群的性能。
(二)高可用性。
集群通过服务实体冗余使客户端免于轻易遭遇到“outofservice”警告。
当一台节点服务器发生故障的时候,这台服务器上所运行的应用程序将在另一节点服务器上被自动接管。
消除单点故障对于增强数据可用性、可达性和可靠性是非常重要的。
(三)负载均衡。
负载均衡能把任务比较均匀的分布到集群环境下的计算和网络资源,以便提高数据吞吐量。
(四)错误恢复。
如果集群中的某一台服务器由于故障或者维护需要而无法使用,资源和应用程序将转移到可用的集群节点上。
这种由于某个节点中的资源不能工作,另一个可用节点中的资源能够透明的接管并继续完成任务的过程叫做错误恢复。
分布式与集群的联系与区别如下:
(一)分布式是指将不同的业务分布在不同的地方。
(二)而集群指的是将几台服务器集中在一起,实现同一业务。
(三)分布式的每一个节点,都可以做集群,而集群并不一定就是分布式的。
而分布式,从狭义上理解,也与集群差不多,但是它的组织比较松散,不像集群,有一定组织性,一台服务器宕了,其他的服务器可以顶上来。
分布式的每一个节点,都完成不同的业务,一个节点宕了,这个业务就不可访问了。
集群主要分成三大类:
HA:
高可用集群(HighAvailabilityCluster)。
LBC:
负载均衡集群/负载均衡系统(LoadBalanceCluster)
HPC:
科学计算集群(HighPerformanceComputingCluster)/高性能计算(HighPerformanceComputing)集群。
为什么搭建数据库集群
随着经济的高速发展,企业规模的迅猛扩张,企业用户的数量、数据量的爆炸式增长,对数据库提出了严峻的考验。
对于所有的数据库而言,除了记录正确的处理结果之外,还面临着以下几方面的挑战。
∙l 如何提高处理速度,实现数据库的均衡负载。
∙l 如何保证数据库的可用性、数据安全性、以及如何实现数据集群可扩性。
∙l 怎么综合解决这些问题成为众多企业关注的焦点。
在数据库上,组建集群也是同样的道理,主要有以下几个原因:
(一)伴随着企业的成长,业务量提高,数据库的访问量和数据量快速增长,其处理能力和计算速度也相应增大,使得单一的设备根本无法承担。
(二)在以上情况下,若扔掉现有设备,做大量的硬件升级,势必造成现有资源的浪费,而且下一次业务量提升时,又将面临再一次硬件升级的高额投入。
于是,人们希望通过几个中小型服务器组建集群,实现数据库的负载均衡及持续扩展;在需要更高数据库处理速度时,只要简单的增加数据库服务器就可以得到扩展。
(三)数据库作为信息系统的核心,起着非常重要的作用,单一设备根本无法保证系统的下持续运行,若发生系统故障,将严重影响系统的正常运行,甚至带来巨大的经济损失。
于是,人们希望通过组建数据库集群,实现数据库的高可用,当某节点发生故障时,系统会自动检测并转移故障节点的应用,保证数据库的持续工作。
(四)企业的数据库保存着企业的重要信息,一些核心数据甚至关系着企业的命脉,单一设备根本无法保证数据库的安全性,一旦发生丢失,很难再找回来。
于是,人们希望通过组建数据库集群,实现数据集的冗余,通过备份数据来保证安全性。
数据库集群的分类
数据库集群技术是将多台服务器联合起来组成集群来实现综合性能优于单个大型服务器的技术,这种技术不但能满足应用的需要,而且大幅度的节约了投资成本。
数据库集群技术分属两类体系:
基于数据库引擎的集群技术和基于数据库网关(中间件)的集群技术。
在数据库集群产品方面,其中主要包括基于数据库引擎的集群技术的OracleRAC、MicrosoftMSCS、IBMDB2UDB、SybaseASE,以及基于数据库网关(中间件)的集群技术的ICX-UDS等产品。
一般来讲,数据库集群软件侧重的方向和试图解决的问题划分为三大类:
∙l 负载均衡集群(LoadBalanceCluster,LBC)侧重于数据库的横向扩展,提升数据库的性能。
∙l 高可用性集群(HighAvailabilityCluster,HAC)侧重保证数据库应用持续不断。
大部分的数据库集群侧重与此。
∙l 高安全性集群(HighSecurityCluster,HSC)侧重于容灾。
只有OracleRAC能实现以上三方面
可扩展的分布式数据库架构
(一)OracleRAC:
其架构的最大特点是共享存储架构(Shared-storage),整个RAC集群是建立在一个共享的存储设备之上的,节点之间采用高速网络互联。
OracleRAC提供了非常好的高可用特性,比如负载均衡和应用透明切块(TAF),其最大的优势在于对应用完全透明,应用无需修改便可切换到RAC集群。
但是RAC的可扩展能力有限,首先因为整个集群都依赖于底层的共享存储,所以共享存储的I/O能力和可用性决定了整个集群的可以提供的能力,对于I/O密集型的应用,这样的机制决定后续扩容只能是Scaleup(向上扩展)类型,对于硬件成本、开发人员的要求、维护成本都相对比较高。
Oracle显然也意识到了这个问题,在Oracle的MAA(MaximumAvailabilityArchitecture)架构中,采用ASM来整合多个存储设备的能力,使得RAC底层的共享存储设备具备线性扩展的能力,整个集群不再依赖于大型存储的处理能力和可用性。
RAC的另外一个问题是,随着节点数的不断增加,节点间通信的成本也会随之增加,当到某个限度时,增加节点可能不会再带来性能上的提高,甚至可能造成性能下降。
这个问题的主要原因是OracleRAC对应用透明,应用可以连接集群中的任意节点进行处理,当不同节点上的应用争用资源时,RAC节点间的通信开销会严重影响集群的处理能力。
所以对于使用ORACLERAC有以下两个建议:
∙l 节点间通信使用高速互联网络;
∙l 尽可能将不同的应用分布在不同的节点上。
基于这个原因,OracleRAC通常在DSS环境(决策支持系统DecisionSupportSystem,简称DSS)中可以做到很好的扩展性,因为DSS环境很容易将不同的任务分布在不同计算节点上,而对于OLTP应用(On-LineTransactionProcessing联机事务处理系统),OracleRAC更多情况下用来提高可用性,而不是为了提高扩展性。
(二)MySQLCluster
MySQLcluster和OracleRAC完全不同,它采用无共享架构Sharednothing(sharednothingarchitecture)。
整个集群由管理节点(ndb_mgmd),处理节点(mysqld)和存储节点(ndbd)组成,不存在一个共享的存储设备。
MySQLcluster主要利用了NDB存储引擎来实现,NDB存储引擎是一个内存式存储引擎,要求数据必须全部加载到内存之中。
数据被自动分布在集群中的不同存储节点上,每个存储节点只保存完整数据的一个分片(fragment)。
同时,用户可以设置同一份数据保存在多个不同的存储节点上,以保证单点故障不会造成数据丢失。
MySQLcluster主要由3各部分组成:
∙l SQL服务器节点
∙l NDB数据存储节点
∙l 监控和管理节点
这样的分层也是与MySQL本身把SQL处理和存储分开的架构相关系的。
MySQLcluster的优点在于其是一个分布式的数据库集群,处理节点和存储节点都可以线性增加,整个集群没有单点故障,可用性和扩展性都可以做到很高,更适合OLTP应用。
但是它的问题在于:
∙l NDB(“NDB”是一种“内存中”的存储引擎,它具有可用性高和数据一致性好的特点。
)存储引擎必须要求数据全部加载到内存之中,限制比较大,但是目前NDB新版本对此做了改进,允许只在内存中加载索引数据,数据可以保存在磁盘上。
∙l 目前的MySQLcluster的性能还不理想,因为数据是按照主键hash分布到不同的存储节点上,如果应用不是通过主键去获取数据的话,必须在所有的存储节点上扫描,返回结果到处理节点上去处理。
而且,写操作需要同时写多份数据到不同的存储节点上,对节点间的网络要求很高。
虽然MySQLcluster目前性能还不理想,但是sharenothing的架构一定是未来的趋势,Oracle接手MySQL之后,也在大力发展MySQLcluster,我对MySQLcluster的前景抱有很大的期待。
(三)分布式数据库架构
MySQL5之后才有了数据表分区功能(Sharding),Sharding不是一个某个特定数据库软件附属的功能,而是在具体技术细节之上的抽象处理,是水平扩展(ScaleOut,亦或横向扩展、向外扩展)的解决方案,其主要目的是为突破单节点数据库服务器的I/O能力限制,解决数据库扩展性问题。
比如Oracle的RAC是采用共享存储机制,对于I/O密集型的应用,瓶颈很容易落在存储上,这样的机制决定后续扩容只能是ScaleUp(向上扩展)类型,对于硬件成本、开发人员的要求、维护成本都相对比较高。
Sharding基本上是针对开源数据库的扩展性解决方案,很少有听说商业数据库进行Sharding的。
目前业界的趋势基本上是拥抱ScaleOut,逐渐从ScaleUp中解放出来。
Sharding架构的优势在于,集群扩展能力很强,几乎可以做到线性扩展,而且整个集群的可用性也很高,部分节点故障,不会影响其他节点提供服务。
Sharding原理简单,容易实现,是一种非常好的解决数据库扩展性的方案。
Sharding并不是数据库扩展方案的银弹,也有其不适合的场景,比如处理事务型的应用它可能会造成应用架构复杂或者限制系统的功能,这也是它的缺陷所在。
读写分离是架构分布式系统的一个重要思想。
不少系统整体处理能力并不能同业务的增长保持同步,因此势必会带来瓶颈,单纯的升级硬件并不能一劳永逸。
针对业务类型特点,需要从架构模式进行一系列的调整,比如业务模块的分割,数据库的拆分等等。
集中式和分布式是两个对立的模式,不同行业的应用特点也决定了架构的思路。
如互联网行业中一些门户站点,出于技术和成本等方面考虑,更多的采用开源的数据库产品(如MYSQL),由于大部分是典型的读多写少的请求,因此为MYSQL及其复制技术大行其道提供了条件。
而相对一些传统密集交易型的行业,比如电信业、金融业等,考虑到单点处理能力和可靠性、稳定性等问题,可能更多的采用商用数据库,比如DB2、Oracle等。
就数据库层面来讲,大部分传统行业核心库采用集中式的架构思路,采用高配的小型机做主机载体,因为数据库本身和主机强大的处理能力,数据库端一般能支撑业务的运转,因此,Oracle读写分离式的架构相对MYSQL来讲,相对会少。
读写分离架构利用了数据库的复制技术,将读和写分布在不同的处理节点上,从而达到提高可用性和扩展性的目的。
最通常的做法是利用MySQLReplication技术,MasterDB承担写操作,将数据变化复制到多台SlaveDB上,并承担读的操作。
这种架构适合read-intensive类型的应用,通过增加SlaveDB的数量,读的性能可以线性增长。
为了避免MasterDB的单点故障,集群一般都会采用两台MasterDB做双机热备,所以整个集群的读和写的可用性都非常高。
除了MySQL,Oracle从11g开始提供ActiveStandby的功能,也具备了实现读写分离架构的基础。
读写分离架构的缺陷在于,不管是Master还是Slave,每个节点都必须保存完整的数据,如果在数据量很大的情况下,集群的扩展能力还是受限于单个节点的存储能力,而且对于Write-intensive类型的应用,读写分离架构并不适合。
采用Oracle读写分离的思路,WriterDB和ReaderDB采用日志复制软件实现实时同步;WriterDB负责交易相关的实时查询和事务处理,ReaderDB负责只读接入,处理一些非实时的交易明细,报表类的汇总查询等。
同时,为了满足高可用性和扩展性等要求,对读写端适当做外延,比如WriterDB采用HA或者RAC的架构模式,目前,除了数据库厂商的集群产品以外,解决数据库扩展能力的方法主要有两个:
数据分片和读写分离。
数据分片(Sharding)的原理就是将数据做水平切分,类似于hash分区的原理,通过应用架构解决访问路由和ReaderDB可以采用多套,通过负载均衡或者业务分离的方式,有效分担读库的压力。
对于Shared-nothing的数据库架构模式,核心的一个问题就是读写库的实时同步;另外,虽然ReaderDB只负责业务查询,但并不代表数据库在功能上是只读的。
只读是从应用角度出发,为了保证数据一致和冲突考虑,因为查询业务模块可能需要涉及一些中间处理,如果需要在数据库里面处理(取决与应用需求和设计),所以ReaderDB在功能上仍然需要可写。
下面谈一下数据同步的技术选型问题:
能实现数据实时同步的技术很多,基于OS层(例如VERITASVVR),基于存储复制(中高端存储大多都支持),基于应用分发或者基于数据库层的技术。
因为数据同步可能并不是单一的DB整库同步,会涉及到业务数据选择以及多源整合等问题,因此OS复制和存储复制多数情况并不适合做读写分离的技术首选。
基于日志的Oracle复制技术,Oracle自身组件可以实现,同时也有成熟的商业软件。
选商业的独立产品还是Oracle自身的组件功能,这取决于多方面的因素。
比如团队的相应技术运维能力、项目投入成本、业务系统的负载程度等。
采用Oracle自身组件功能,无外乎LogicalStandby、Stream以及11g的PhysicalStandby(ActiveDataGuard),对比来说,Stream最灵活,但最不稳定,11gPhysicalStandby支持恢复与只读并行,但由于并不是日志的逻辑应用机制,在读写分离的场景中最为局限。
如果技术团队对相关技术掌握足够充分,而选型方案的处理能力又能支撑数据同步的要求,采用Oracle自身的组件完全可行。
选择商业化的产品,更多出于稳定性、处理能力等考虑。
市面上成熟的Oracle复制软件也无外乎几种,无论是老牌的Shareplex,还是本土DSG公司的RealSync和九桥公司的DDS,或是Oracle新贵Goldengate,都是可供选择的目标。
随着GoldenGate被Oracle收购和推广,个人认为GoldenGate在容灾、数据分发和同步方面将大行其道。
当然,架构好一个可靠的分布式读写分离的系统,还需要应用上做大量设计,不在本文讨论范围内。
(四) CAP和BASE理论
分布式领域CAP理论:
∙l Consistency(一致性),数据一致更新,所有数据变动都是同步的
∙l Availability(可用性),好的响应性能
∙l Partitiontolerance(分区容错性)可靠性
定理:
任何分布式系统只可同时满足二点,没法三者兼顾。
忠告:
架构师不要将精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍。
关系数据库的ACID模型拥有高一致性+可用性很难进行分区:
∙l Atomicity原子性:
一个事务中所有操作都必须全部完成,要么全部不完成。
∙l Consistency一致性.在事务开始或结束时,数据库应该在一致状态。
∙l Isolation隔离层.事务将假定只有它自己在操作数据库,彼此不知晓。
∙l Durability.一旦事务完成,就不能返回。
(五) 跨数据库事务
2PC(two-phasecommit),2PCistheanti-scalabilitypattern(PatHelland)是反可伸缩模式的,也就是说传统关系型数据库要想实现一个分布式数据库集群非常困难,关系型数据库的扩展能力十分有限。
而近年来不断发展壮大的NoSQL(非关系型的数据库)运动,就是通过牺牲强一致性,采用BASE模型,用最终一致性的思想来设计分布式系统,从而使得系统可以达到很高的可用性和扩展性。
那么,有没有可能实现一套分布式数据库集群,既保证可用性和一致性,又可以提供很好的扩展能力呢?
BASE思想的主要实现有按功能划分数据库sharding碎片BASE思想主要强调基本的可用性,如果你需要High可用性,也就是纯粹的高性能,那么就要以一致性或容错性为牺牲,BASE思想的方案在性能上还是有潜力可挖的。
∙l 共同点:
都是关系数据库SQL以外的可选方案,逻辑随着数据分布,任何模型都可以自己持久化,将数据处理和数据存储分离,将读和写分离,存储可以是异步或同步,取决于对一致性的要求程度。
∙l 不同点:
NOSQL之类的Key-Value存储产品是和关系数据库头碰头的产品BOX,可以适合非Java如PHPRUBY等领域,是一种可以拿来就用的产品,而领域模型+分布式缓存+存储是一种复杂的架构解决方案,不是产品,但这种方式更灵活,更应该是架构师必须掌握的。
目前,已经有很多分布式数据库的产品,但是绝大部分是面向DSS类型的应用,因为相比较OLTP应用,DSS应用更容易做到分布式扩展,比如基于PostgreSQL发展的Greenplum,就很好的解决了可用性和扩展性的问题,并且提供了很强大的并行计算能力。
对于OLTP应用,业务特点决定其要求:
高可用性,一致性,响应时间短,支持事务和join等等。
数据库和NoSQL当越来越多的NoSQL产品涌现出来,它们具备很多关系型数据库所不具备的特性,在可用性和扩展性方面都可以做到很好。
第一,NoSQL的应用场景非常局限,某个类型的NoSQL仅仅针对特定类型的应用场景而设计。
而关系型数据库则要通用的多,使用NoSQL必须搞清楚自己的应用场景是否适合。
第二,利用关系型数据库配合应用架构,比如Sharding和读写分离技术,同样可以搭建出具备高可用和扩展性的分布式数据库集群。
第三,关系型数据库厂商依然很强大,全世界有大量的用户,需求必然会推动新的产品问世。
第四,硬件的发展日新月异,比如闪存的技术的不断成熟,未来闪存可以作为磁盘与内存之间的cache,或者完全替代磁盘。
而内存价格越来越低,容量越来越大,In-memorycache或database的应用越来越广泛,可以给应用带来数量级的性能提升。
数据库面临的IO问题将被极大改善。
ORACLE集群概念和原理
(二)
Oracle集群概念和原理
Oracle的三种高可用集群方案
1RAC(RealApplicationClusters)
多个Oracle服务器组成一个共享的Cache,而这些Oracle服务器共享一个基于网络的存储。
这个系统可以容忍单机/或是多机失败。
不过系统内部的多个节点需要高速网络互连,基本上也就是要全部东西放在在一个机房内,或者说一个数据中心内。
如果机房出故障,比如网络不通,那就坏了。
所以仅仅用RAC还是满足不了一般互联网公司的重要业务的需要,重要业务需要多机房来容忍单个机房的事故。
2DataGuard.(最主要的功能是冗灾)
DataGuard这个方案就适合多机房的。
某机房一个production的数据库,另外其他机房部署standby的数据库。
Standby数据库分物理的和逻辑的。
物理的standby数据库主要用于production失败后做切换。
而逻辑的standby数据库则在平时可以分担production数据库的读负载。
3MAA
MAA(MaximumAvailabilityArchitecture)其实不是独立的第三种,而是前面两种的结合,来提供最高的可用性。
每个机房内部署RAC集群,多个机房间用DataGuard同步。
RAC概述
共享存储文件系统(NFS),或甚至集群文件系统(如:
OCFS2)主要被用于存储区域网络(所有节点直接访问共享文件系统上存储器),这就使得节点失效而不影响来自其他节点对文件系统的访问,通常,共享磁盘文件系统用于高可用集群。
OracleRAC的核心是共享磁盘子系统,集群中所有节点必须能够访问所有数据、重做日志文件、控制文件和参数文件,数据磁盘必须是全局可用的,允许所有节点访问数据库,每个节点有它自己的重做日志和控制文件,但是其他节点必须能够访问它们以便在那个节点出现系统故障时能够恢复。
OracleRAC运行于集群之上,为Oracle数据库提供了最高级别的可用性、可伸缩性和低成本计算能力。
如果集群内的一个节点发生故障,Oracle将可以继续在其余的节点上运行。
Oracle的主要创新是一项称为高速缓存合并的技术。
高速缓存合并使得集群中的节点可以通过高速集群互联高效地同步其内存高速缓存,从而最大限度地低降低磁盘I/O。
高速缓存最重要的优势在于它能够使集群中所有节点的磁盘共享对所有数据的访问。
数据无需在节点间进行分区。
Oracle是唯一提供具备这一能力的开放系统数据库的厂商。
其它声称可以运行在集群上的数据库软件需要对数据库数据进行分区,显得不切实际。
企业网格是未来的数据中心,构建于由标准化商用组件构成的大型配置之上,其中包括:
处理器、网络和存储器。
OracleRAC的高速缓存合并技术提供了最高等级的可用性和可伸缩性。
Oracle数据库10g和OracleRAC10g显著降低了运营成本,增强了灵活性,从而赋予了系统更卓越的适应性、前瞻性和灵活性。
动态提供节点、存储器、CPU和内存可以在实现所需服务级别的同时,通过提高的利用率不断降低成本。
RAC集成集群件管理
OracleRAC10g在Oracle数据库10g运行的所有平台上提供了一个完整集成的集群件管理解决方案。
这一集群件功能包括集群
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- oracle 集群 相关 技术 分析
![提示](https://static.bdocx.com/images/bang_tan.gif)