网络配置评估

建议配置同段网络，因为当发生故障转移时，应用连接的是监听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%以下。