March 13, 2006
Privileged and Confidential (c)2006
May 22, 2005
PCTI
Highly Confidential and Restricted, PCTI
ICX-UDS DB Scaler 3.1
下一代容灾数据库集群技术
沈新国(Gary Shen) 首席代表
中国代表处
美国并行计算技术公司
www.pcticorp.com/www.pcticorp.com.cn
中心问题
系统可靠性
系统的性能
系统服务可用性
核心问题:能否构建一个数据库集群系统,使得其象其他应用级集群系统那样在上述三方面同时具备良好的伸缩能力
关键词
冗余
数据一致性
可伸缩性
零切换
等等
进入演讲……
提纲
公司背景
数据库系统在整个信息系统中的核心地位
当前数据库集群技术总结
下一代容灾数据库集群技术特点
ICX并行事务交易的概念和技术
ICX 的特性
ICX在近,远程容灾系统上的应用
ICX典型案例分析
公司背景
美国并行计算技术公司开发并销售用于增强数据库系统性能和可靠性的中间件,包括:同步数据复制,服务器容错以及并行事务处理等产品.这些产品适合于具有中到大型关键电子数据处理系统的企业和单位.
总部:美国宾夕法尼亚州
具有美国国家技术专利,美国专利号:USPTO #6,421,668.
市场前景极为广阔,已在美国,中国,日本,澳大利亚等有不少成功案例和大量的测试用户
数据库系统在整个信息系统中的
核心地位
最薄弱的环节 (最后一公里)
数据库是所有电子交易处理系统中的最薄弱环节
不断增多的病毒,间谍件和黑客事件,以及快速变化的需求经常导致事务处理的回卷(rollback) 不断增长的有计划的数据库维护停机.
不断增长的软件复杂度, 以及24x7的使用要求 不断增长的意外的数据库停机.
不断增长的数据库访问致使数据库成为整个信息系统性能的瓶颈.但是不可能通过简单增加服务器并且不降低可用性这种方法来提升数据库的性能 由于系统伸缩性低而导致成本不断增长.
通信的发展使得人们跨时区的访问成为可能 不断增长的高可用性需求.
数据库停机服务的统计
系统设计问题 (36%)
机器硬件问题 (25%)
有计划的停机 (5%)
数据库引擎软件问题 (34%)
平均无故障时间(MTBF) = 102 days
平均故障修复时间(MTTR) = 18 hours
Source: Oracle - User Survey
数据库停机服务的损失
对于中等规模的分布式网络来讲, 有计划和意外的数据库停机导致的收入损失一般为$78,000/小时.
典型的金融服务企业每年因为数据库停机而导致的损失为一百万美元($1 Million).
得克萨斯大学的一项研究表明,遭受过灾难性数据丢失的公司里面有94%的公司无法继续生存: 其中42% 永远不能重新开张,51%在两年内关闭.
1998年4月, 由于内部的软件升级,AT&T 发生6-26 小时的服务中断.结果引发FCC(联邦通讯委员会)的法律诉讼,导致五千万美元的损失.
1998年8月5号, 由于维护系统的原因,AOL(美国在线)停止服务21小时. 结果AOL宣布向消费者提供三百万美元的补偿, 另外还花了八千万美元用于基础设施的建设.
当前数据库集群技术总结
串行数据库复制与"最后一公里"问题
数据库保存了任何有意义计算的最终结果.然而,这些结算结果的复制天生是串行的.
由于串行的特性,当前的备份和高可用性产品/方案存在众所周知的缺点:管理复杂,易出错,价格昂贵和低效率.
由于串行复制的局限性,数据库系统变得难以管理,可伸缩性差 (信息基础设施的 "最后一公里"问题).
减少数据库停机时间可以挽救成百万美元的业务损失.
灵活的数据库集群结构可以减少投资风险.
串行复制的困难: P, Q 和
同步: 主服务器的速度受到限制,被迫和进行串行处理的备份服务器的速度保持一致.主服务器或备份服务器只要发生任何问题,都将导致事务处理回滚,因此系统的可用性(P)降低了一半.
异步: 必须存在一个队列Q ,使得主服务器的处理速度 in (并行处理) 和备份服务器的处理速度 out (串行处理).( in > out)以为着队列变成无穷大 (Q->∞) 0严重的队列溢出问题.
串行复制存在的困境
异步数据库复制 ("主数据库先行")技术具有先天的队列溢出问题. 只能产生一份昂贵的温备份(warm standby),同时主数据库的性能受到影响.
同步数据库复制技术采用了两阶段提交协议 -- "All or nothing",与单机系统相比,会导致更多的停机时间.
同步数据库复制技术抑制了主数据库服务器的性能.
当前的数据库分区技术使得系统的可用性大为下降.
当前,不存在同时取得数据库高性能和高可用性的可能性.
下一代容灾数据库集群技术特点
目标
必须速度快,无论多大的数据集,多频繁的查询请求.
必须随时可用,无论发生什么样的软硬件错误.
必须利用现存的数据库访问方法.
必须是非入侵方式部署.
必须管理简单.
必须充分利用现有的软硬件资源,降低成本.
困难所在何处
一个简单的问题: 我们究竟能不能同步复制并发的事务处理
如果答案为"是",那么数据库的可伸缩性和可用性就容易做到,并且成本低廉.
否则,数据库的可伸缩性和可用性就很难提高,并且代价很高.
为什么业界"大腕"解决不了呢
数据库厂商希望这问题在他们的数据库引擎内部解决 -> 日志复制(log shipping)及其它非同步复制工具.
中间件厂商只在意向客户提供新的功能. 他们并不在意数据库基础设施本身-> 采用两阶段提交(2PC)的同步复制技术.
数据库方面的这个问题,由于摩而定律而暂时缓解了: 每十八个月CPU主频翻一番.现在摩而定律快结束了.2004年10月英特尔取消了主频为4GHz的Prescott微处理器的生产,这标志着摩而定律的正式结束.
ICX并行事务交易的概念和技术
我们的技术突破
开发出一个开销低,动态的事务处理同步复制算法(不是两阶段提交协议,同时不存在队列溢出问题),具备ACID特性 (原子性,一致性,孤立性,和持久性).
开发出一个具有5个9(99.999%)的系统可靠性 的技术,用以重新同步多个不一致的数据库服务器 (三秒钟的网络静默时间,与数据集大小无关)
美国专利 USPTO #6,421,668.
ICX并发事务复制
(IP,Port)
访问控制
自动的事务处理复制
动态锁定
自动的错误恢复
自动的重同步
IP接管器的保护
并行事务处理
数据库阵列
ICX 的特性
高可靠性
由于ICX使得系统同时保持了多个实时一致的数据集,因此大大提高了该数据库数据的可靠性和安全性,同时明显简化了数据备份的过程,甚至不需要象现在通常的做法那样进行数据备份了.同时ICX网自身可以做HA(双机热备份),这样真正消除了单点错误源,大大提高整个系统的可靠性,使系统真正达到5个9(99.999%)的系统可靠性.
高性能(1/3)
(IP,Port)
并行处理更新和查询操作
负载均衡的查询
同步复制的更新
性能随服务器数量的增加而线性提升-繁重的事务交易.
高性能(2/3)
混合请求
轻量级的只读查询
负载均衡和同步复制操作
负载均衡的只读查询
高性能(3/3)
_________________
客户端网络
服务器端网络
客户端请求
高服务可用性
(IP,Port)
访问控制
2. 离线重建
1. 自动错误切换
3. 自动同步.
(3 秒的静默时间)
特性列表
彻底消除了由集群扩展,软硬件修复和升级带来的计划停机服务.
彻底消除了由软硬件和网络错误带来的计划外停机服务.
自动的数据库查询负载均衡,带来更高的性能.
完全冗余,彻底消除单点错误源.
非入侵部署: 一对(IP,port),应用程序接口不作任何修改.
基于标准的宽带网络, 实时事务处理同步复制.
内置数据库访问防火墙.
内置加密/解密算法,用于公共网络传输.
不停机,近实时的数据挖掘能力.
内嵌的并发控制语句,使得客户可以进行更精确的调优.
用于应用整合和自动化管理的SDK包.
ICX在近,远程容灾系统上的应用
ICX容灾应用之一
本地数据库A
远程数据库B
数据库客户
主ICX网关
备ICX网关
前提要求:远地的网络延时不得大于400ms.
适合条件:带宽要求低,适合于更新少,查询多的情景.
ICX容灾应用之二
数据库北京
数据库上海
北京本地客户
主ICX网关
备ICX网关
上海本地客户
前提要求:远地的网络延时不得大于400ms.
适合条件:带宽要求低,适合于更新少,查询多的情景.
ICX容灾应用之三
数据库北京
数据库上海
北京客户
北京ICX网关
上海ICX网关
上海客户
前提要求:
1.远地的网络延时不得大于400ms.
2.北京客户和上海客户于不同的数据库或者没有共享冲突
ICX典型案例分析
Belkin(贝尔金)
DB 1
DB 2
备ICX同步复制器
数据库更新
HA
贝尔金公司的ICX数据库集群系统结构示意图
主ICX负载均衡器
数据库查询
HA
备ICX负载均衡器
备ICX同步复制器
情况介绍
存在问题:Web访问量的增加,降低了维护/帮助门户的性能,同时,贝公司也需要提高维护/帮助门户的可用性.
解决结果:贝公司采用了并发复制器和负载均衡器,将应用程序对数据库的访问分解成更新操作和只读查询操作.另外,每个ICX网关都实现了主备容错.贝公司于2005年4月份正式开始使用ICX.从那之后,Web访问的性能得到了明显的改善,同时通过ICX的PRT,维护工作也变得简单多了.ICX的负载均衡器使得系统能在不停止对外服务的情况下及时地提供统计报表.现在所有的访问流量都经过这几个数据库网关,这样就能够进一步利用多个同步一致的数据库数据来获得更好的性能表现.
Kamiya公司
DB 1
DB 2
DB 15
主ICX网关
备ICX网关
数据库客户
HA
K公司的日本客户的ICX数据库集群系统结构示意图
情况介绍
存在问题:如何在使用低成本的SQL Server(标准版的SQL Server)情况下,取得很高的事务处理性能
解决结果:K公司的软件工程师们设计出一个解决方案,让所有的信息查询只访问其中的某台SQL Server,同时数据库的更新操作全是通过ICX复制器来进行.通过ICX后面连接了15台数据同步一致的Microsoft SQL Server数据库,K公司向人们展示了由ICX构成的这种集群在超负荷压力情况下的出色性能表现(在同样硬件条件下,没有任何单一的SQL Server能保持不丢失网络连接).
ICX成功案例和测试客户
医疗:厦门中山医院,MedRisk
教育:上海大学,Liberty,UPRR.pr
电子政务:广西税务稽征系统
电子商务:Infinitesolutions, Kamiya
电力:国电招标网
企业:Belkin,redhotpie,MLS
媒体:Discover,
零售:e-Revolution,
金融:深圳招商银行,Investools,
等等
谢谢!
沈新国 首席代表
美国并行计算技术公司中国代表处
本文出自 51CTO.COM技术博客