数据库管理平台DMP

深信服数据库管理平台(DMP)提供MySQL、Oracle的RDS功能,支持全生命周期管理、自动MySQL主从切换、故障自愈、事务一致性备份、监控告警等,能够实现业务快速上线、资源快速分发、数据安全保护,提供SLA保障,使数据库运维复杂度大幅下降,帮助客户减少被动性救火工作,专注业务创新。
点击可切换产品版本
知道了
不再提醒
通用文档
{{sendMatomoQuery("数据库管理平台DMP","资源评估")}}

资源评估

更新时间:2024-07-24

网络配置评估

建议配置同段网络,因为当发生故障转移时,应用连接的是监听IP,则不需要修改应用侧连接串;否则生故障转移时应用需要修改连接串,且搭建 AlwaysOn 需要配置两个监听IP

带宽需要根据对于 RPO 的需求以及数据增量来规划,假设有 10 个库需要做容灾,且每个库每秒钟产生 100KB 的数据量,那么 10 个库就是 1MB/s ,若要求 RPO = 0,理论带宽为 10Mpbs,不过实际情况可能有一些损耗,根据经验值建议给 10 Mbps,也就是理论值的 2 倍。

这里还没有计算流量峰值,比如某个时间段的业务量可能是平均值的10倍;也忽略了可用性模式(同步提交模式、异步提交模式),这些都需要综合考虑,按实际情况和需求配置网络带宽。

CPU配置评估

核心业务系统灾备到超融合平台后需要对原服务器CPU配置进行评估,原 CPU 配置过剩,并且客户要求释放过剩CPU资源的,需要减少配置;原 CPU 资源配置不足需增加 CPU 资源;原 CPU 资源利用率合理则保持配置不变。评估原则如下:

评估原则:

服务器CPU资源的合理平均利用率为:30%-70%,业务高峰期时也能保持在80%以下;

超融合平台主机的主频建议要高于原服务器或者保持持平,从目前主流的CPU看,云平台的主频不低于2.0Ghz。如果云平台的主频低于原服务器的主频,则容灾后要考虑是否要增加核数配置来弥补主频的不足;需要注意的是,如果原有的数据库类型为OLAP、数据仓库或单线程的SQL类型的,因为这样的系统中,语句的执行量不是考核标准,因为一个语句的执行时间可能会非常长,也就意味这CPU的主频会严重影响这种类型数据库的性能,禁止云平台的性能低于原服务器的主频;

数据库服务器容灾后不建议降低CPU配置,可以运行一段时间后观察,是否需要降低CPU配置;

数据库服务器容灾,若原系统CPU使用率过高(超过70%),可以增加原系统的CPU配置;

单实例数据库服务器配置建议16C-32C,如果32C还不能满足业务需求,建议1、优化数据库,排查慢查询;2、更改数据库架构,改为集群架构,不建议再通过增加服务器配置来承载业务;

集群数据库服务器配置建议16C-32C,如果32C还不能满足业务需求,建议1、优化数据库,排查慢查询;2、更改数据库架构,为集群增加新的节点,以此来承载更多的业务访问,不建议再通过增加服务器配置来承载业务。

内存配置评估

数据库系统灾备到超融合平台后需要对原服务器内存配置进行评估,原内存配置过剩,并且客户要求释放过剩内存资源的,需要减少配置;原内存资源配置不足需增加内存资源;原内存资源利用率合理则保持配置不变。评估原则如下:

评估原则:

服务器内存的合理平均利用率为:30%-70%,业务高峰期时也能保持在80%以下;

数据库服务器内存在容灾上云时建议增加,不建议降低。随意降低数据库服务器内存可能会导致数据库无法启动;

数据库原内存平均利用率若经常保持在80%以上时,建议为容灾后的虚拟机增加内存配置;

数据库服务器,单实例内存配置建议在16G-64G的区间,单节点内存配置建议在32G-128G区间。具体配置需要通过专业的DBA进行计算,容灾时不可随意更改数据库服务器内存配置。

存储配置评估

数据库系统容灾到超融合平台磁盘的配置根据容灾方法不同,容灾后的结果也不同。评估的原则如下:

评估原则:

源端数据库的磁盘使用率不高于70%的情况下,容灾过来后可保持原状。如果源端数据库的磁盘使用率高于70%,考虑到未来3-5年的业务需要,建议容灾过来后通过扩容磁盘,将磁盘的使用率降低到60%以下。