一个ECS上自建Oracle数据库的案例的相关实践-阿里云开发者社区

开发者社区> 云计算> 正文

一个ECS上自建Oracle数据库的案例的相关实践

简介:

问题起因

    近期一个客户上云,系统用的是Oracle数据库,正确的姿势当然是去O,改用MySQL再上云,但因采用的软件系统来自外购,短时间内无法做去O改造,就采用了购买ECS并在上面安装Oracle的做法,使用SharePlex for Oracle做主备同步,具体架构如下:

这个架构看起来有应用的负载均衡,有数据库的主备做高可用,有SSD云盘保证IO,有快照做容灾,还是挺完美嘛~但实际使用中,就发现问题多多。

问题一:ECS实例选型

    该用户选择的ecs.hfg5型实例,属于“高主频型”,让我们看看这个类型实例的适用场景https://help.aliyun.com/document_detail/25378.html#localssd:“可以满足高性能前端集群、Web 服务器、批量处理、分布式分析、高性能科学和工程应用、广告服务、MMO 游戏、视频编码等场景”,有没有做数据库服务的场景?可能用户觉着选择“高主频型”后,计算能力是足够了,再配合上“SSD云盘”,那存储上的IO也不是瓶颈,岂不是Perfect?

    然而在上线后,系统访问压力增大才发现,实际的数据库性能总是上不去,最后发现问题还是在于磁盘IO上:

    数据盘队列长度一直在5左右,随便搜搜关于磁盘队列长度的讨论,比如:
http://www.ithacks.com/2008/09/12/high-avg-disk-queue-length-and-finding-the-cause/,“As a general rule for hard disks, an Avg Disk Queue Length greater than 2 (per hard disk) for extended periods of time is considered undesirable.”,还有“Disk Queue Length is over 2 and % Disk Time is hovering at 60% or above, you may want to look into a possible I/O bottleneck.”,嗯,似乎确实有点问题哈。

    既然都用了SSD云盘了,为什么还有磁盘IO瓶颈呢?经过找块存储的同学沟通后,确认IO带宽并不会是瓶颈,瓶颈是出在延迟上,既然是云盘,是会增加那么一丁点延迟的,经过测试,SSD云盘的写延迟在1ms左右,读延迟在1~2ms,这个结果其实并不差(比行业水平,比如其他云供应商还是强滴),但用在对读写延迟高度敏感的数据库服务器上,就稍显不够了。

    那么既然SSD云盘都不够,是不是我们就该放弃云上自建数据库,下云得了?答案是No!其实从一开始我们就有更好的选择,那就是选择“本地SSD”型的ECS,我们来看看这个类型的ECS用在什么场景:“对应本地盘存储类型为NVMe SSD资源,高随机 IOPS 和高顺序读写吞吐、低时延。适用于 OLTP 联机事务处理、NoSQL 数据库、Hadoop 等应用场景”,看到没,这才是真正该选择用于自建数据库的ECS实例类型,前面那是方向错了(但努努力还是有救的,后面再说)。

    话说阿里云还是提供过非实例型本地SSD盘(https://promotion.aliyun.com/act/aliyun/localssd.html),只不过现在下架了,这个选项就不再在考虑范围内了。

问题二:磁盘的配置

    接问题一,客户都已经买好了实例了,还一口气买了很久,相关的系统也部署好了,业务也在运行了,还沉淀了不少的业务数据,在系统正繁忙阶段,也没时间做各种折腾,需要尽快的优化性能,这还有救吗?答案是Yes!

    看系统性能图可以发现,用户的数据库服务器其实只有两块盘,一个是系统盘(高效云盘),另一个是数据盘(SSD云盘),数据、日志等都写在数据盘上,在高访问压力的时候,除了大量的数据写入外,也产生巨量的redo log。那么数据、日志分别写不同的磁盘,是否可以提高并行程度,从而改进写入效率呢?

    说做就做,请用户新购买个SSD云盘,把当前9组redo log全部从当前数据库盘挪到新盘,并新加9组redo log,这样18个日志组都存在新盘中:1fbf8ac2480a1406110adb95932d6e4c.png
    现在系统架构变这样了:d586d108bf8b8b1612b9d33e1e5abc32.png
    再看看系统性能情况:
e3167a797efa815e290a269f3530cdf2.png

    数据盘的队列长度1,已经到了合理范围内,现在压力到了日志盘(F盘),似乎有点儿矫枉过正了,两个盘又有点写入不均匀。但是anyway,数据库的IO性能大有改善,在业务顶峰的时候也妥妥的扛得住。

    虽然用户系统扛得住,但咱们还是要总结经验教训的,得找正式说法不是~其实Oracle官方文档已经早早的给咱们指明这个道路啦https://docs.oracle.com/cd/B28359_01/server.111/b28310/onlineredo002.htm#ADMIN11312,“Datafiles should also be placed on different disks from redo log files to reduce contention in writing data blocks and redo records.”。当然系统还可以进一步优化,比如数据文件也分布在不同的盘上,比如数据文件和日志文件怎么分布才能取得最佳平衡点,这就是下一步目标了。

问题三:快照容灾

    OK,现在性能的问题解决了,是不是就一切OK了呢?别急,还早着了,下一个问题就是用快照做数据容灾不靠谱。如果用“oracle datafile corrupted”搜一下,会发现那结果是相当的多,估计背后都是满满的眼泪~在ECS上对云盘做快照,因为是不停机状态,数据文件更容易处于一个不完全的状态,换句话说,在真正需要基于快照恢复的时候,你会发现有很大的几率告诉你因为数据文件损坏,数据库无法启动。

    在云下的时候,数据文件被损坏了还是能恢复的,条件是:A datafile can still be recovered if no backup exists for it, provided: a、all redolog files since the creation of the datafile are available;b、the control file contains the name of the damaged file (that is, the control file is current, or is a backup taken after the damaged datafile was added to the database)”,可以发现这个在云上是很难满足的,也就代表你从快照恢复数据库也是很难满足的。

    那正确的容灾姿势是什么呢?见下图:

9faf6dc2c27159b8d1bb7c73cc2d223e.png


    其中备份到OSS这个其实可选,毕竟云盘提供9个9的可靠性(见https://help.aliyun.com/document_detail/25382.html),OSS也不过10个9,主备实例的云盘加上备份用的云盘全挂的概率实在不高。如果希望能够进一步提高数据的可靠性(及时备份),可以在主实例上做rman数据备份,这会损失一点主实例的性能。

问题四:快照时机

    上个问题提到快照容灾不靠谱,容易导致数据文件损坏,无法做灾难恢复。其实用户使用快照还有另一个有问题的地方,就是为了容灾中尽量少损失数据,设置了每3个小时做一次快照,而其中有几次会发生在业务高峰期!这就导致了在快照的时间点(因为数据量巨大,快制作快照需要的时间比较久)会因为备份争抢磁盘的IO,这会导致数据库性能的进一步恶化,这也是在实际使用中发生性能不够的一个重要的因素。正常的快照操作应该在业务低谷时候做。

问题五:数据库HA方案

    现在我们回过头来看看该用户的Oracle HA方案,架构里面看起来似乎做到了HA,但实际还离得远,很简单,如果主实例出故障,那么会怎么切换?首先这没有自动切换的机制,如果半夜三更没人值班,发生故障了只能等业务出问题了,再去找运维人员,然后做手动切换。

    那找到运维人员是不是就能快速恢复?No!既然是应用服务器上直连数据库服务器,那么不管使用IP还是实例名,切到备服务器都需要修改应用服务器的配置,然后重新应用,这个时间可就长了,别说做不到业务无感的自动切换,连快速恢复都算不上。

    数据库HA最常见的实践是用VIP,但在阿里云里面现在是不支持VIP的使用,如果对数据库的请求走“SLB+多ECS(ECS内再自建load balancer)”来实现failover似乎性能的损失会比较大,目前看来还没能找到比较靠谱的云上自建数据库HA方案,如果哪位知道还请指点一下:)

后记:ESSD云盘

2018年1月9日阿里云推出了ESSD云盘,单盘IOPS高达100万,单路随机写时延低至100微秒,这个应该是自建数据库中更好的存储解决方案,有兴趣的同学可以试试这个。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
云计算
使用钉钉扫一扫加入圈子
+ 订阅

时时分享云计算技术内容,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。

其他文章