暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

DB2数据库平台整合解决方案

ibm软件技术联盟 2015-03-04
573

很多企业反映内部的数据库系统占用的太多的服务器和存储空间,不利于资源的优化利用和管理。为了提高资源利用率,节省成本,并且实现标准化,统一化管理,数据库整合需求迫在眉睫。尤其是企业的一些老版本数据库面临过保的风险,需要升级,那么这将是一个很好的机会在升级的过程中直接完成数据库整合目标。

数据库整合的短期目标:

1.提高资源利用率,节省资源成本(存储容量减少30%,业务量增长40%)
一般企业的数据库应用可以分为关键,重要和普通三类。最适合拿普通数据库考虑整合到新的数据库平台。
2.减少维护成本
数据库整合之后,建立数据库维护标准,提高易管理性,提高维护效率,减少运维工作量。
3.建立数据库平台新规范
通过普通数据库整合实践,完善未来数据库云平台架构设计。

企业数据库管理长期目标:

1. 资源整合/虚拟化
2. 标准化
3. 自动化
4. 自助服务

整合过程中需要考虑的因素:
目标复杂性
应用数据库平台多样,DB2 版本众多。整合方案需要考虑正对不同平台的整合复杂程度。尤其是部分应用的DB2版本已经是EOS状态,需要升级。
整合简易性
应用数据库数量众多,整合工作量巨大。所以为了能和快速和顺利落地,整合必须简单易操作,能在短期内完成预期目标。
平台可靠性
数据库平台整合之后,相关可靠性需要得到保证,最小化整合风险。
性能扩展性
资源整合到一起之后要提高资源的利用率。应用的性能需要从新的平台获利。新的平台要利于性能扩展。

根据整合目标和落地需求,数据库的整合方案最好能够最小化对应用的影响。尤其是节省存储是当前最突出的需求,所以数据库平台整合主要从存储整合出发,提高存储的利用率,节省成本。我对于这类需求,提出了可行的两种解决方案:

共享存储整合(GPFS)
不改变当前数据库平台,仅将多个应用数据库的存储整合到共享存储平台,释放空余空间,提高存储IO利用率。
升级平台整合(pureScale)
可以看作是共享存储整合的延伸。对于需要升级的应用,建议直接升级到pureScale平台,不仅将数据库整合到共享存储,同时能够充分利用到pureScale平台的高可用性和高扩展性。

方案一:共享存储整合(GPFS)


对于没有升级需求的应用,现有的数据库架构将不做变化,不迁移服务器,仅将存储迁移到GPFS共享存储
GPFS集群节点不宜太多,建议4套应用使用1套GPFS共享存储
分析应用的IO使用情况,选择IO忙闲时间段互补的应用整合到一起
根据GPFS共享存储空间,设置应用数据库使用存储空间份额的警报


GPFS连接模式中选择采用直连存储的方式,当某个GPFS节点的SAN出现问题,无法访问SAN存储,此时该节点将作为GPFS NSD Client端访问就近的NSD Server端。


当该节点无法访问本地SAN存储,GPFS集群将自动使用NSD Client/Server方式,这样会影响该节点上的数据库服务的性能;

使用GPFS整合数据库建议只采用直连存储方式,需要在GPFS节点在mount文件系统时,指定不要切换至NSD Client/Server方式,在出现无法访问外部磁盘存储时,该节点上的数据库服务将停止,由PowerHA接管,切换数据库服务到对应的节点上

方案二:升级平台整合(pureScale)



对于有升级需求的应用,建议升级整合到DB2 pureScale集群环境
DB的高可用性由pureScale集群替代原来的双机HA环境


共享存储整合步骤

分析应用
分析应用的性能特点,将应用归类,参考容量,选择IO性能互补的4套应用为一组,使用一套GPFS集群
搭建GPFS共享存储
规范化定义GPFS共享存储的路径。
重定义数据库架建规划。
选择数据库迁移方式
重定向恢复(推荐),同时启用DB2自动存储特性
需要升级的应用可以考虑export + import
时间窗口少的可能使用HADR或者CDC做升级。
数据库管理迁移
修改HA存储脚本
数据库维护
维持原有维护策略和监控体系不变,增加对共享存储的监控。例如定义共享存储空闲空间的报警阀值。定期检查和扩容共享存储


下载附件点击阅读原文


文章转载自ibm软件技术联盟,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论