telnet4730
作者telnet47302019-08-16 14:16
数据库运维工程师, 光大证券

多套Oracle数据库系统的整合思路及整合实例

字数 4001阅读 3555评论 1赞 5

随着企业业务的发展,系统增多,数据库数量逐年增加,每套系统使用独立的数据库服务器,软硬件成本投入较高,但资源利用率较低,同时管理成本也不断增高,造成整体的拥有成本较高,那么企业怎样消减数据库方面的使用成本呢? 数据库整合是一种很好的消减策略来消减成本。整合是将现有数据库实例或数据库组合到一起,最终的目标是降低成本,这些节省的费用主要来自 : 可能会减少所需的许可证数量、降低管理成本、提高资源利用率、标准化、降低基础设施成本。

整合的好处 :

1 、软硬件费用及维护费用减少。由于我们最终会使用更少的服务器和数据库实例,许可成本可能会下降,而且物理硬件的数量也可能会减少。这就意味着用更少的钱购买硬件,同时花费在环境维护(如电源、机房)和硬件维护上费用也将变少。

2 、有更好的系统安全性、稳定性及可维护性的提高。以往的情况是,随着数据库服务器的增多,就会增加整个环境成本,并且服务器可能由多个团队管理,有可能存在不遵循 IT 流程的情况。管理许多不同的系统会导致更多的管理工作,将这些系统整合到集中式数据库服务器可以极大地减少维护工作, 且有更好的系统安全性和稳定性。

常见的合并方式及合并需要考虑的因素:

1 、数据库整合或者 schema 整合

为了使用更少的数据库实例和更高的利用率,将一些使用频率不高的系统,或者只有少数人使用的系统(还不能下线),合并到新的正在使用新的数据库实例中 。这样做的好处是可以减少必须授权和维护的实例的数量。如果迁移的实例的服务器位于物理硬件上,那么很可能还会降低硬件和基础设施成本。使用更少的实例,那么监视和维护 ( 备份、一致性检查、索引维护等 ) 也可以更容易地完成 ,整个管理工作将会减少。

数据库层面的整合可能会影响移动数据库和目标数据库上的性能 sla ,因为这样做意味着现在将有更多的数据库共享更少的硬件资源( CPU 、内存、网络和 IO ),同时同一实例的数据库将共享数据库的资源如连接的 agent ,临时表空间,缓冲池及其他的内部对象。所以在迁移之前,首先必须分析源数据库和目标实例的性能基线,以确保传入的工作负载不会超过目标实例上的可用资源。

整合后有可能有部分程序影响数据库的性能, 例如,一个应用程序上的服务器阻塞可能导致线程不足,这将导致所有其他应用程序失去访问该服务器上数据的能力。或者一个应用程序可能过度消耗资源,从而限制了其他应用正常存取数据。

还需要考虑的问题是,一些应用程序只支持旧版本的数据库,其他的应用程序需要最新的版本。整合后还需要考虑,维护时间的冲突,比方说修补补丁,现有的补丁和维护的需求不会违反另一个数据库的维护时间( ha sla )。

2 、实例整合

实例整合是将整个数据库实例移动到已经运行数据库实例的服务器 ( 物理或虚拟 ) 的过程。最终目标仍然是提高利用率,但这次是在服务器级别,通过拥有多个数据库实例来保持一定的隔离。这样做的好处是减少了数据库服务器环境所需的服务器数量。

数据库整合带来的许多相同的好处和关注点也适用于实例整合。实例将共享服务器资源如内存、 CPU 、 IO 和网络。当前工作负载和服务器资源的基线是成功整合的关键。需要分析传入的负载,以确保目标服务器上的可用资源不会被过度使用。

实例整合和数据库整合的一个关键区别在于,数据库整合所有数据库都可以共享该实例的整个服务器内存。对于多个实例,服务器内存将在单独的实例之间进行分配,每个数据库将只有给定该实例的可用内存量。我们需要决定如何最好地分配服务器资源。目前的数据库实例都可以自动平衡内存需求,但随着缓冲池大小的频繁更改,这可能导致延迟写、删除缓存的执行计划等,从而导致实例上的性能问题。 所以为确保不受彼此的影响,必须根据工作负载和服务器资源的基线及实际的需要分配服务器的内存。主要的参数也要设置下,比方内存 sqlserver 建议设置 maxserver, 在 cpu 的的分配上 sqlserver CPU 关联掩码配置,而 db2 instance memory 不自动调整, oracle sga 的值也安需要分配下。

3 、虚拟化整合

虚拟化是在服务器级进行合并的一种方法。虚拟化允许多个客户服务器在主机服务器上运行。每个客户机作为一个完全独立的实体运行,并且看起来是一个独立的服务器。如果机器已经是虚拟服务器,那么迁移是一个相当简单的过程,因为映像可以移动到新的主机。

此外,许多虚拟化技术都提供了在主机之间移动客户机的解决方案。从安全性的角度来看,虚拟机是完全独立的,因此整合工作不需要做出任何妥协。从性能 SLA 的角度来看,我们没有在虚拟服务器级别共享任何内容,但是主机服务器资源将被共享。虚拟化技术假设客户机不会同时使用它们的所有资源,倾向于过度使用主机资源,这将有助于更充分地利用主机服务器的硬件。但确实会带来性能问题的风险,因为主机资源很容易被过度利用。

需要对所有客户机服务器的工作负载进行基线化,并与主机服务器的容量进行比较,以确保资源不会过度消耗。虚拟化整合的另一个好处是过期的数据库版本不会因为服务器硬件升级而造成数据库软件不能安装。

4 、混合合并

混合多种整合类型。混合合并可能使您能够在更大程度上进行合并。例如,数据库整合可能仍然会降低一些服务器的利用率,但是安全性需求阻止了进一步的整合。这些服务器可以被虚拟化,然后合并到同一台主机上运行。仔细考虑关于 SLA 的所有整合的影响。通常情况下,实例整合和虚拟化不会同时进行。如果使用虚拟化,每个实例可以拥有自己适当大小的 VM ,而不是共享更大的 VM 。单个 VM 应该比在单个 VM 上合并多个实例更具灵活性。

我司数据库整合的思路、挑战与收益

目前我司有多套信息系统,各系统的数据库架构体系通常以 Linux 服务器作为计算层,存储层使用本地硬盘或采用集中式存储,系统包括 Windows 、 Linux ,数据库软件使用 Oracle 10g 、 11g ,各业务系统因采用烟囱式建设管理,每套采用独立的硬件设备,数据库服务器设备数量较多,并且有部分服务器已经超过使用期限,无硬件维保。并且各系统上线时间不同,上线的数据库标准不统一,运维人员多,且管理成本高,运维的压力较大。在性能压力、资源扩展、监控管理上面临着巨大的挑战。我们既要面对系统性能瓶颈及运维复杂度上升的问题,又要考虑对 IT 成本的投入问题。

我司考虑实际情况,利用服务器周期性更换的机会,对现有的 oracle 数据库做了整合, 主要考虑以下的原则:

Ø 考虑整合的影响,先不整合交易系统,首先整合管理类系统;

Ø 整合服务器已经过保或者马上过保的系统;

Ø 整合存在较多的批处理作业且运行时间较长的系统;

Ø 整合运行存在瓶颈,达到了扩容要求的系统;

Ø 整合要符合系统监管要求,如监管要求必须使用独立的设备,那么将不整合到平台中;

Ø 由于网络管理的需求,对现有的数据库有网络划分,那么对跨网络的数据库将不整合到一起;

Ø 不整合将要下线的系统 ;

Ø Windows 系统暂不整合,涉及到版本升级,需要应用大量测试的系统不做整合 ;

Ø 不整合已经是虚拟机的系统;

Ø 整合过程中迁移时尽量考虑对应用改动的最小

在目标服务器的选择上考虑可扩展性且保持现有 DB 的 SLA 不变, 采用 2+3 的 oracle rac 架构模式,即使用 2 个计算节点和 3 个存储节点,均采用普通 x86 服务器,存储节点利用分布式的存储软件并配置闪存盘构成共享的存储节点,在磁盘半配的情况下,提供 30 万的 iops 。在整合方面,采用实例级整合的办法,实例运行采用 rac one node 的方式,多个实例分布于俩个计算节点。

整合前首先对系统性能基线、负载进行详细的分析,包括系统名称、上线时间、系统类型、系统的等级、服务器过保时间、服务器的配置 、服务器的负载、 cpu 的最大值、平均值、内存的使用率,数据库的大小及已分配的空间、归档日志的大小,备份的大小、及 corontab 维护任务,各系统繁忙的时间点等等。整合过程采用 rman 的备份恢复方式迁移数据,迁移后为了使应用改动最小,我们采用 ip 不变的方式,即 rac one node 的 vip 使用原来的 IP 地址。应用只需要修改下连接字符串应用就可以正常运行,原来的连接字符串使用的是 service name , 那么连接字符串就不需要改变,如果使用 sid ,那么只需要需要改成 service name 就可以正常运行。

数据库整合固然有很多好处但是也存在诸多的挑战,比方说数据库之间会不会互相影响,或者说怎样做让影响降到最低,实际整合过程中,我们一是选择了平行可扩展并且硬件成本费用适中的高性能的目标系统,另外我们合理的分配负载不同的实例,将不同的负载错峰执行,实际的效果还是比较理想的。另一个问题是我们如何在多实例的情况下快速的定位问题、解决问题也非常关键。比如如何快速判断是那个实例、那个应用、什么 sql 导致了性能问题, 这确实是个挑战,但是通过监控手段是可以快速发现的,比方说现在 cpu 使用高,我们可对比 db time 的走势和 cpu 利用率的走势,就可以很快的判断出那个实例正在消耗了较多的 cpu ,进而找到是那个应用的什么 sql ,最后快速的解决问题。另外通过查看每个实例上读写的吞吐可以快速发现是那个实例占用了 io ,进而快速的做出相应优化。

通过实例级的整合,我们提高了系统资源的利用率,加强了数据库的标准化运维,同时减少了服务器的数量,降低了数据库的运维人员的工作强度,降低了管理成本,极大的消减了企业数据库方面的成本。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

5

添加新评论1 条评论

#Switcher数据库管理员, 某银行
2019-08-16 14:45
怎么没有考虑Oracle CDB PDB?

Switcher@telnet4730 这倒是.....数据库大版本升级的各种测试太累人了

2019-08-16 15:51

telnet4730@Switcher 这次整合的系统较老,主要为了减少应用方面升级及测试,新的系统的整合将选择pdb

2019-08-16 15:46
Ctrl+Enter 发表

分布式关系型数据库选型优先顺序调查

发表您的选型观点,参与即得50金币。