ORACLE Fusionio最佳实践.docx

ORACLE Fusionio最佳实践.docx

《ORACLE Fusionio最佳实践.docx》由会员分享，可在线阅读，更多相关《ORACLE Fusionio最佳实践.docx（5页珍藏版）》请在冰豆网上搜索。

ORACLEFusionio最佳实践

ORACLEFusion-io最佳实践

Fusion-io是基于NANDFlash技术的存储设备，底层存储技术与SSD相同，不同的是，Fusion-io采用PCI-E接口，SSD采用SATA接口。

相比较SSD，Fusion-io省略了南桥芯片，RAID控制器等访问路径，所以Fusion-io又把他们的产品称为IOMemory，意思就是可以象内存一样访问，性能比SSD要好很多。

我们目前数据库使用SSD，采用的是硬件RAID5的方案，这个方案的优点是：

通过RAID卡提供冗余功能，提升了整体的可靠性。

缺点是：

RAID会损失部分性能，通过RAID卡屏蔽之后，无法检测到SSD的使用寿命。

选择硬件RAID5方案，是在大量测试的基础上，结合我们的实际情况做出的选择，并不一定是最优的方案。

ORACLE使用Fusion-io的方案，需要考虑三个方面的内容：

1.数据冗余方案；2.数据存放方案；3.高可用方案。

数据冗余方案：

Fusion-io采用PCI-E接口，无法使用硬件RAID，我们可以使用OSLVM或者ORACLEASM实现软RAID的功能。

1.ExternalRedundancy（Striping/RAID0）

这个方案相当于RAID0，只是将多块ioDrive（Fusion-io的产品名称）的空间整合为一个统一的DG，不提供任何数据冗余。

2.NormalRedundancy（Mirroring/RAID1）

这个方案相当于RAID10，同时提供了数据冗余与条带，是可靠性比较高的方案。

需要注意的是：

可以通过ASMfailgroup的功能，将两块ioDrive之间做镜像，以防止单块卡出现故障。

3.HighRedundancy（Mirroring/RAID10+1）

这个方案相当于RAID10+1，数据被冗余了三份，进一步提高了可靠性，不过代价有些高。

4.ASMMirroringwithaRead-PreferredDevice

这个方案稍微复杂，ioDrive与存储的LUN做RAID10，利用ASM的Preferredmirrorread功能，读取时优先读取ioDrive，提高性能的同时，又保证了可靠性。

5.方案分析：

上述四个方案中，方案一没有数据冗余，其他三个方案都有数据冗余，方案三代价过于高昂，方案四必须要有FC存储，方案二是最有可能采用的方案，但是RAID10要损失一半的容量，对于价格昂贵的ioDrive来说，代价依然高昂。

回头看看方案一，因为本地数据没有冗余，所以必须采用DataGuard来保证系统高可用，如果要求数据100%不丢失，DataGuard必须采用同步模式，网络延迟必须满足日志同步写入的要求，如果系统压力过大，依然存在丢失数据的可能性。

看来没有十全十美的方案，必须有所取舍。

数据存放方案：

1.将所有文件都保存在ioDrive上：

如果存储空间许可，这是最简单可靠，也是性能最好的一种方案。

2.将temp文件保存在ioDrive上：

针对一些DSS系统，temp文件可能是性能的瓶颈，比如大量的sort，Hashjoin可能耗费大量的temp空间，将temp文件放在ioDrive上可能带来性能上的收益。

不过，我很少见到类似的需求，这个方案应该很少使用。

3.将redo保存在ioDrive上：

对于ORACLE数据库，redolog必须同步串行（9i串行，10g以后可以并行），对于write-intensive系统，要求redo必须有很低的写入延迟，否则redo可能成为整个系统的瓶颈。

所以，可以考虑将redolog放在ioDrive上，提高响应延迟。

但是，我个人并不是特别建议这个方案，因为redolog的写入是一种小IO的顺序写入，顺序写入更适合磁盘，并不适合flash存储（可以参考《基于SSD的数据库性能优化》）。

如果磁盘可以满足响应延迟需求，建议将redolog放在磁盘上，而不是ioDrive上。

4.将热点数据保存在ioDrive上：

如果整个系统无法全部放在ioDrive上，而用户可以识别出系统的热点数据，那么可以人工将热点数据放在ioDrive上，将其他数据放在磁盘存储上，从而获得比较好的性能。

5.ioDrive作为flashcache：

将ioDrive作为数据库内存和磁盘之间的cache，Flashcache是用户透明的一种解决方案，系统自动将热点数据加载在flashcache中，提升系统性能。

ORACLE 11gR2提供了flashcache功能，当block从SGA中被换出时，会被写入到flashcache中，但是在ORACLE的flashcache方案中，只有cleanblock才会被写入到flashcache中，Dirtyblock必须写入到磁盘上（DBWR会优先保证dirtyblock的写出，只有空闲时才会写flashcache），这就是我们所说的writethrough模式（Facebook的flashcache方案可以采用writeback模式，dirtyblock首先被写入flashcache，然后定期刷新到磁盘上，flashcache同时承担了读cache和写buffer，这个方案性能更好），ORACLEflashcache是纯粹的读cache，可以大幅度提升读的性能，但是无法提升写的性能。

ORACLE的方案很安全，就算flashcache损坏，也不会丢失任何数据，但是性能比WB模式要差一些，而且flashcache预热的过程也比较长。

另外一点，ORACLEflashcache必须使用ORACLELINUX，其他操作系统不提供这个功能。

Flashcache提供了一个高性价比的方案，但是同时增加了系统的复杂度，如果是WB模式，可能存在数据丢失的风险，在做方案时，需要做一些权衡。

个人建议：

如果空间可以满足需要，可以考虑方案一，性能和可靠性都最好。

如果热点数据很明确，可以采用方案四，简单可控，性价比高。

另外，Facebook的flashcache方案也是一个很好的选择，淘宝在MySQL数据库上广泛采用了这一技术，XX也在MySQLinnodb存储引擎上，自主开发了flashcache的功能。

不过，我始终认为flashcache是一个过渡方案，技术上并不是特别成熟，如果技术上无法完全把握这项技术，请谨慎使用flashcache。

数据高可用方案：

ORACLE数据库高可用方案有两个：

DataGuard和RAC，DataGurad相对比较简单，但是可用性并不理想。

RAC基于共享存储架构，必须有一套SAN存储，RAC使用FusionIO也有两个方案：

1.共享存储+Fusion-io+Flashcache

这个方案采用传统RAC架构，只是在RAC节点上配置ioDrive，用ioDrive作为数据库的flashcache，提升性能。

这里要说明一点，为什么ORACLEflashcache不提供WB模式，原因是ORACLERAC架构必须基于共享存储，如果dirtyblock写入RAC节点的flashcache，当发生节点crash的时候，将出现数据不一致的情况。

2.Fusion-io+iSCSI+infiniband

这个方案将配置ioDrive的机器作为存储节点，利用iSCSI和ASM技术，将存储节点整合为共享的存储设备，输出给RAC节点使用。

事实上，很早之前我就做过类似的方案：

ORACLERAC廉价数据仓库解决方案，大致的原理一致，只是存储节点变成了ioDrive。

但是，我们在做这个方案时，发现在千兆以太网上运行iSCSI，延迟时间根本无法满足需求。

如果存储节点换成ioDrive，存储节点可以提供强大的IOPS能力，但是网络延迟将会成为整个系统的瓶颈。

后来，ORACLEExadata出现了，内部互连采用infiniband技术，这给了我们一个启发，我们同样可以利用infiniband的低延迟特性，来实现这个方案。

Infiniband与以太网不同，采用SRP（SCSIRDMAprotocol）协议，是IBSAN的一种协议，其主要作用是把iSCSI协议的命令和数据通过RDMA的方式跑到Infiniband网络上，可以认为是iSCSI协议的一种增强和扩展，iSER代表iSCSIExtensionsforRemoteDMA。

下图清晰的展示了各种协议与底层物理链路之间的关系。

ORACLEExadata的最大优势在于，将OLTP和DSS融合在一套系统之内，Exadata有一些特性，其中smartscan，storageindex，hybridcolumnarcompressed，这几个特性适合DSS应用。

而对于OLTP类型的应用，主要是靠存储节点的flash存储和flashcache技术。

对于我们的需求来看，DSS系统更适合采用分布式系统，例如hadoop，greenplum等，而对于OLTP系统，高性能的集中式数据库，可以解决很大的问题。

所以，上述的方案如果可行，就为我们提供了一个新的方向。

我不知道ORACLEExadata内部采用何种协议进行互联，我也很想搭建一套系统，去验证这个方案是否可行。

另外，现在的存储厂商都可以提供内置SSD的存储产品，很多产品还提供自动分层的技术，从技术的角度看，这是比较成熟的。

如果采用上述方案，性价比和风险还有待于进一步验证。

–EOF–