ORACLE Fusion-io最佳实践

2 20th, 2011 | Posted by jacky | 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 scan,storage index,hybrid columnar compressed,这几个特性适合DSS应用。而对于OLTP类型的应用,主要是靠存储节点的flash存储和flashcache技术。对于我们的需求来看,DSS系统更适合采用分布式系统,例如hadoop,greenplum等,而对于OLTP系统,高性能的集中式数据库,可以解决很大的问题。所以,上述的方案如果可行,就为我们提供了一个新的方向。

我不知道ORACLE Exadata内部采用何种协议进行互联,我也很想搭建一套系统,去验证这个方案是否可行。另外,现在的存储厂商都可以提供内置SSD的存储产品,很多产品还提供自动分层的技术,从技术的角度看,这是比较成熟的。如果采用上述方案,性价比和风险还有待于进一步验证。

–EOF–

版权说明:本文中的部分内容来自于Fusion-io官方文档《Oracle Fusion-io Best Practices Guide》,最后的协议与链路关系图,来自于同事林钰的PPT,比我画得好多了。

标签: , , ,
  1. Kamus
    2 20th, 201102:39

    请教两个问题。
    FCP协议中FC-0~FC-4,然后和FC交互就是当前最常见的FC应用方式吗?这种方式的latency跟iSCSI走TCPIP相比在latency上有很大优势吗?
    另外,FCIP和iFCP以及FCoE又是怎样的应用场景?

  2. orainxiong
    2 20th, 201103:56

    先抢沙发再拜读

  3. vogts
    2 20th, 201109:50

    板凳

  4. jacky
    2 20th, 201110:16

    地板

  5. jacky
    2 20th, 201110:18

    @Kamus
    我其实也是一知半解,去请教一下我们专业负责存储的同事。

  6. jacky
    2 24th, 201110:08

    @Kamus
    我们实际使用中,如果用千兆网络跑iscsi,IO延时比较大,用来做数据库不行,但可以用来做备份。市面上也有一些IP SAN存储产品,他们虽然也是iscsi,但是因为在硬件层和网络层做了很多优化,肯定要好很多,甚至不逊色于FC的存储。我们没有做什么改动,所以性能不是特别好。
    iFCP和FCIP,都是将FC协议封装在TCP协议中,两者在封装形式上有细微的差异,比如两个机房的FC SAN,中间可以通过以太网,将FC协议封装在TCP协议中,其中FCIP比较成熟,iFCP应用很少。FCOE就是直接将FC协议跑在以太网络上,不需要TCP封装,性能更好,这也是目前发展比较快的技术。最后就是在我们常见的跑在光纤上的FC协议了。

  7. rmans
    2 28th, 201110:08

    Google,亚马逊都没有使用Raid的

  8. tonyy
    3 5th, 201101:44

    数据高可用方案2目前有成熟的产品解决方案,以前的Voltaire(目前已经被Mellanox并购)有一个VSA的软件产品,就是将FUSION-IO的PCI-E SSD安装在IA服务器中,此服务器再装上InfiniBand HCA,在此服务器中安装VSA软件后把此服务器+SSD变成一个IB接口的SSD磁盘阵列,客户端通过ISER协议访问此块儿级存储!这样,Oracle服务器用于inter-connection的InfiniBand网络也得以充分利用!VSA所在的服务器还可以安装光纤卡把现有的FC接口存储设备链接起来,VSA不仅提供了SSD的共享存储,同时将原有的FC磁盘阵列转换成InfiniBand接口!
    此方案在海外银行以及电信行业已经有一些应用案例!FUSION-IO那边应该能找到相关资料!

  9. jacky
    3 7th, 201109:51

    @tonyy
    感谢,我研究一下看看。

  10. 冬瓜头
    3 11th, 201111:42

    老兄,你认为PCIE的flash卡与SSD的应用场景和市场前途各怎么样?你们会在什么场景下优先选择SSD或者PCIE?

  11. jacky
    4 18th, 201116:14

    @冬瓜头
    我觉得SSD和使用PCIe接口的flash卡都有市场,你可以看看我的PPT,分别包含了这两种设备的解决方案。

  12. AMY
    5 16th, 201121:11

    这个加INFINIBAND的案子, 我们现在有很多案例呢。 还有一家国内的集成商, 你要不要真的试试?

  13. jacky
    5 18th, 201114:32

    @AMY
    听说类似的解决方案很多,不过我们现在更倾向于另外一种方案。

  14. 大金
    7 6th, 201109:24

    ORACLE Exadata的最大优势在于,将OLTP和DSS融合在一套系统之内,Exadata有一些特性,其中smart scan,storage index,hybrid columnar compressed,这几个特性适合DSS应用。而对于OLTP类型的应用,主要是靠存储节点的flash存储和flashcache技术。

    –这一段非常同意!

  15. alexdu
    8 7th, 201121:06

    请问有具体如何在rac+fusionIO+flashcahe的实际方案吗,正好有这方面的需求

  16. lucky
    8 2nd, 201315:37

    传统的千兆以太网iscsi的性能的确不行,就包括万兆以太网的iscsi性能也是不行的,延迟是最大的问题,性能表现不稳定。iSER虽然不如SRP协议高效,但是相比较已经足够的高效,而SRP也需要target能够支持。