存档

文章标签 ‘asm’

最近参加了OTN China Tour技术嘉年华的活动,并准备了一个关于软硬件结合的主题演讲,介绍了我们在软硬件结合方面提升Oracle数据库性能和可用性的案例,后续我会详细介绍这些案例的架构与设计。
PPT:软硬件结合的数据库解决方案
–EOF–

感谢ACOUG,云和恩墨,Eygle和Kamus。

10 24th, 2011 | Filed under 大话技术

Fusion-io是基于NAND Flash技术的存储设备,底层存储技术与SSD相同,不同的是,Fusion-io采用PCI-E接口,SSD采用SATA接口。相比较SSD,Fusion-io省略了南桥芯片,RAID控制器等访问路径,所以Fusion-io又把他们的产品称为IO Memory,意思就是可以象内存一样访问,性能比SSD要好很多。
我们目前数据库使用SSD,采用的是硬件RAID5的方案,这个方案的优点是:通过RAID卡提供冗余功能,提升了整体的可靠性。缺点是:RAID会损失部分性能,通过RAID卡屏蔽之后,无法检测到SSD的使用寿命。选择硬件RAID5方案,是在大量测试的基础上,结合我们的实际情况做出的选择,并不一定是最优的方案。
ORACLE使用Fusion-io的方案,需要考虑三个方面的内容:1.数据冗余方案;2.数据存放方案;3.高可用方案。
数据冗余方案:
Fusion-io采用PCI-E接口,无法使用硬件RAID,我们可以使用OS LVM或者ORACLE ASM实现软RAID的功能。
1.External Redundancy (Striping/RAID0)
这个方案相当于RAID0,只是将多块ioDrive(Fusion-io的产品名称)的空间整合为一个统一的DG,不提供任何数据冗余。

2.Normal Redundancy (Mirroring/RAID1)
这个方案相当于RAID10,同时提供了数据冗余与条带,是可靠性比较高的方案。需要注意的是:可以通过ASM failgroup的功能,将两块ioDrive之间做镜像,以防止单块卡出现故障。

3.High Redundancy (Mirroring/RAID10 +1)
这个方案相当于RAID10+1,数据被冗余了三份,进一步提高了可靠性,不过代价有些高。

4.ASM Mirroring with a Read-Preferred Device
这个方案稍微复杂,ioDrive与存储的LUN做RAID10,利用ASM的Preferred mirror read功能,读取时优先读取ioDrive,提高性能的同时,又保证了可靠性。

5.方案分析:
上述四个方案中,方案一没有数据冗余,其他三个方案都有数据冗余,方案三代价过于高昂,方案四必须要有FC存储,方案二是最有可能采用的方案,但是RAID10要损失一半的容量,对于价格昂贵的ioDrive来说,代价依然高昂。回头看看方案一,因为本地数据没有冗余,所以必须采用Data Guard来保证系统高可用,如果要求数据100%不丢失,Data Guard必须采用同步模式,网络延迟必须满足日志同步写入的要求,如果系统压力过大,依然存在丢失数据的可能性。看来没有十全十美的方案,必须有所取舍。
数据存放方案:
1.将所有文件都保存在ioDrive上:
如果存储空间许可,这是最简单可靠,也是性能最好的一种方案。
2.将temp文件保存在ioDrive上:
针对一些DSS系统,temp文件可能是性能的瓶颈,比如大量的sort,Hash join可能耗费大量的temp空间,将temp文件放在ioDrive上可能带来性能上的收益。不过,我很少见到类似的需求,这个方案应该很少使用。
3.将redo保存在ioDrive上:
对于ORACLE数据库,redo log必须同步串行(9i串行,10g以后可以并行),对于write-intensive系统,要求redo必须有很低的写入延迟,否则redo可能成为整个系统的瓶颈。所以,可以考虑将redo log放在ioDrive上,提高响应延迟。但是,我个人并不是特别建议这个方案,因为redo log的写入是一种小IO的顺序写入,顺序写入更适合磁盘,并不适合flash存储(可以参考《基于SSD的数据库性能优化》)。如果磁盘可以满足响应延迟需求,建议将redo log放在磁盘上,而不是ioDrive上。
4.将热点数据保存在ioDrive上:
如果整个系统无法全部放在ioDrive上,而用户可以识别出系统的热点数据,那么可以人工将热点数据放在ioDrive上,将其他数据放在磁盘存储上,从而获得比较好的性能。
5.ioDrive作为flashcache:
将ioDrive作为数据库内存和磁盘之间的cache,Flashcache是用户透明的一种解决方案,系统自动将热点数据加载在flashcache中,提升系统性能。ORACLE  11g R2提供了flashcache功能,当block从SGA中被换出时,会被写入到flashcache中,但是在ORACLE的flashcache方案中,只有clean block才会被写入到flashcache中,Dirty block必须写入到磁盘上(DBWR会优先保证dirty block的写出,只有空闲时才会写flashcache),这就是我们所说的write through模式(Facebook的flashcache方案可以采用write back模式,dirty block首先被写入flashcache,然后定期刷新到磁盘上,flashcache同时承担了读cache和写buffer,这个方案性能更好),ORACLE flashcache是纯粹的读cache,可以大幅度提升读的性能,但是无法提升写的性能。ORACLE的方案很安全,就算flashcache损坏,也不会丢失任何数据,但是性能比WB模式要差一些,而且flashcache预热的过程也比较长。另外一点,ORACLE flashcache必须使用ORACLE LINUX,其他操作系统不提供这个功能。
Flashcache提供了一个高性价比的方案,但是同时增加了系统的复杂度,如果是WB模式,可能存在数据丢失的风险,在做方案时,需要做一些权衡。个人建议:如果空间可以满足需要,可以考虑方案一,性能和可靠性都最好。如果热点数据很明确,可以采用方案四,简单可控,性价比高。另外,Facebook的flashcache方案也是一个很好的选择,淘宝在MySQL数据库上广泛采用了这一技术,百度也在MySQL innodb存储引擎上,自主开发了flashcache的功能。不过,我始终认为flashcache是一个过渡方案,技术上并不是特别成熟,如果技术上无法完全把握这项技术,请谨慎使用flashcache。
数据高可用方案:
ORACLE数据库高可用方案有两个:Data Guard和RAC,Data Gurad相对比较简单,但是可用性并不理想。RAC基于共享存储架构,必须有一套SAN存储,RAC使用FusionIO也有两个方案:
1.共享存储+Fusion-io+Flashcache
这个方案采用传统RAC架构,只是在RAC节点上配置ioDrive,用ioDrive作为数据库的flashcache,提升性能。这里要说明一点,为什么ORACLE flashcache不提供WB模式,原因是ORACLE RAC架构必须基于共享存储,如果dirty block写入RAC节点的flashcache,当发生节点crash的时候,将出现数据不一致的情况。
2.Fusion-io+iSCSI+infiniband
这个方案将配置ioDrive的机器作为存储节点,利用iSCSI和ASM技术,将存储节点整合为共享的存储设备,输出给RAC节点使用。

事实上,很早之前我就做过类似的方案:ORACLE RAC廉价数据仓库解决方案,大致的原理一致,只是存储节点变成了ioDrive。但是,我们在做这个方案时,发现在千兆以太网上运行iSCSI,延迟时间根本无法满足需求。如果存储节点换成ioDrive,存储节点可以提供强大的IOPS能力,但是网络延迟将会成为整个系统的瓶颈。后来,ORACLE Exadata出现了,内部互连采用infiniband技术,这给了我们一个启发,我们同样可以利用infiniband的低延迟特性,来实现这个方案。
Infiniband与以太网不同,采用SRP(SCSI RDMA protocol)协议,是IB SAN的一种协议 ,其主要作用是把iSCSI协议的命令和数据通过RDMA的方式跑到Infiniband网络上,可以认为是iSCSI协议的一种增强和扩展,iSER代表iSCSI Extensions for Remote DMA。下图清晰的展示了各种协议与底层物理链路之间的关系。
ORACLE Exadata的最大优势在于,将OLTP和DSS融合在一套系统之内,Exadata有一些特性,其中smart [...]

2 20th, 2011 | Filed under 大话技术
标签: , , ,