本文档详细介绍基于云数据库专属集群MyBase在金融公共云部署物理围笼实践的方案。

1. 概述

1.1 行业背景

泛金融和金融云

泛金融指包含银行、保险、证券、基金理财等在内的传统金融机构，还包含消费金融、助贷、融租、融担、典当、金融科技等以传统机构为中心的上下游生态企业。

对于传统金融机构，满足监管合规是必须遵守的红线。阿里云的金融云平台就是为以上客户提供上云的方案。

目前阿里云可提供给强监管客户的有金融云公共区域和专有云两种方案。专有云属于重资产交付，对前期投入和后期运维要求都较高，专有云主要适用于银行和证券行业的客户，其他类型的金融客户主推的仍然是轻资产交付的金融云方案。

监管要求

2020年10月16日，中国人民银行正式发布《云计算技术金融应用规范技术架构》（JR/T 0166-2020）、《云计算技术金融应用规范安全技术要求》（JR/T 0167-2020）、《云计算技术金融应用规范容灾》（JR/T 0168-2020）等三项金融行业标准。

《云计算技术金融应用规范安全技术要求》围绕云计算金融应用潜在风险，在兼容国家和金融行业现有信息系统安全要求基础上，从基本要求、扩展要求和增强要求三个类别分类施策，提出基础硬件安全、资源抽象与控制安全、应用安全、数据安全、安全管理、服务能力和可选组件安全等方面安全技术要求。

基于上述的背景，对金融云平台内的云数据库提出了更高的安全与物理隔离需求，在金融监管要求升级的大背景下，阿里云数据库专属集群MyBase在金融云专内的物理围笼方案应运而生。

1.2 方案介绍

金融云专区（围笼模式）

金融云专区（围笼模式）是在金融行业云的平台上，专为某一个客户提供的物理隔离、资源独占并且物理设施连续分布的专属资源池，进一步增强金融合规性来满足银保监会的严格要求。专区采取金融云标准计费模式。专内的云产品资源均是客户独占，且与其他机构的设施、系统、数据完全隔离，拥有极高的数据安全性和私密性。

金融云专区的三个特点：

•物理角度上增加了金属隔笼。

•独立的门禁系统, 保障物理安全。

•独立的网络，保障数据传输安全。

MyBase专属数据库

MyBase可以帮助客户构建在金融云专区内的物理隔离的数据库专属集群，集群内包含独占的计算资源和存储资源，拥有对物理机的管理能力，同时也能在集群内的物理机上构建出RDS，NoSQL等阿里云数据库PaaS服务。云数据库专属集群MyBase目前已支持MySQL、PostgreSQL、SQL Server、Redis、MongoDB等多款云数据库。

同时，MyBase借助金融云专区的物理围笼模式，严格保障笼内数据的安全性和私密性，且对笼内的云数据库具备自主运维的白盒管理能力。

1.3 适用场景

适用场景包含银行应用、消费金融公司、保险应用、证券应用，基金和对数据隐私性有更高要求的所有互联网金融等垂直行业，以及上下游生态企业。

1.4 目标读者

金融各行业数据开发、运维人员、架构师、DBA。

2. 方案架构

本方案重点关注在金融专区内部署云数据库的方案，专区内的其他产品资源，比如：大数据、弹性计算等不在这里展开叙述。

2.1 架构图

MyBase是公有云上的专属数据库，是由多台主机组成的数据库集群。提供MySQL、SQLServer、PostgreSQL、Redis、MongoDB等多款云数据库服务，具有云资源独享、支持资源超分配，自主可运维、开放数据库和OS权限等特点。

RDS就像写子楼租一个房间来开公司，即开即用。而MyBase直接租整层楼开公司，客户可以自主设计这层楼里些房间作会议室、仓库、财务室等等, 从而满足更高性价比，更多样化的需求。

2.2 方案优势

物理隔离

物理隔离是金融行业监管合规的必要条件，阿里金融云专区（围笼）提供最高保障企业数据的安全性和私密性，实现金融数据中心相关设施与其他行业和用户物理隔离。

资源独占

金融云专区内数据库选型为资源完全独占的云数据库专属集群MyBase，可严格按照底层资源规划进行数据库部署，最大限度避免因资源争抢导致的业务不稳定。

除了数据库，金融云专区的其他云产品也选型为资源独占类型，比如：块存储专属集群、专有宿主机DDH等。形成专区内完整的专属云产品矩阵。

安全等保

阿里金融云安全等保， 同时云数据库专属集群MyBase的SLA可用性承诺。

自主可控

MyBase是白盒式管理的云数据库，支持开放主机OS和数据库管理员权限，让客户获得更多自主可控的权限，可充分发挥企业DBA的价值，及时解决数据库问题。兼顾DBA的黑屏运维习惯，避免因封闭权限造成的黑盒问题而引起运维效率下降。

灾备建设

方案支持笼内笼外或双围笼的容灾方案建设，通过MyBase数据库灾备产品能力以及DTS数据同步链路，完全满足监管合规的灾备切换要求，支持金融行业的灾备演练，同时也具备灵活多样的灾备架构配置。

2.3 方案模块-笼内主机

MyBase产品形态天然与金融云专区（围笼）契合，只需将主机资源部署到围笼区域即可。围笼内的底层主机采用了弹性计算的专有宿主机（DDH），从金融云专区、集群、主机、数据库都实现用户资源独占。

DDH是指由一个租户独享物理资源的云主机。作为该云主机的唯一租户，用户不需要与其他租户共享云主机所有物理资源。还可以获得这台物理服务器的物理属性信息，包括CPU数量（Socket数）、物理CPU核数、内存大小，并根据宿主机规格创建指定规格族的ECS实例。

DDH有以下特点：

• 阿里云提供宿主机的虚拟化托管，单租户独享宿主机资源，不会和其他租户共享一台物理机。

• 可以得到宿主机更全面的信息，包括总可用资源和剩余可用资源。

• 可以得到虚拟机和物理机的对应部署关系。

• 可以组件一个可调度的DDH资源池，可以自由的调度ECS。

MyBase通过和DDH组成联合解决方案，为笼内主机定制专门的主机规格码，购买特定规格码的DDH主机，会落入客户的物理围笼中。

用户只需提前报备资源的使用量，会有MyBase和DDH团队协作开出笼内主机资源池。然后，用户可以在MyBase控制台的金融云地域创建集群并购买主机规格，有了MyBase主机后，就可以生产MySQL、Redis等实例。流程如下图所示。

2.4 方案模块-笼内云数据库

创建出MyBase主机之后，就可以在MyBase控制台上自由的创建和管理数据库实例，如下图所示：

创建成功后的笼内云数据库实例，功能与公共云RDS、NoSQL数据库产品能力保持一致，提供了高可用容灾、备份、恢复、监控、迁移等方面的云数据库产品能力，同时具备阿里云自研的数据库内核（比如：AliSQL），可彻底解决数据库手动运维的烦恼。

3. 方案实施

3.1 前提条件

1. 已注册为阿里云金融公共云客户。

2. 提前报备为金融公共云专区（围笼）客户，申请专区内机柜数量（可联系阿里云架构师进行现场勘查后评估）。

3. 开通金融云Region内指定AZ（比如：华南金融云E区）的VPC，创建MyBase的集群在该VPC内。

3.2 操作步骤

步骤一：开通阿里云金融公共云账号

金融云开通使用流程

步骤二：报备为金融云专区客户

联系您的阿里云销售或架构师，申请为金融云专区客户，专区客户会在阿里金融云机房内开辟专属包间，并会部署物理围笼进行隔离。

金融云专区适合存在监管风险无法使用普通公共云，且需求轻量交付的客户（无需专有云的重资产底座）。

目前，阿里金融云专区可以分布在：华东1（杭州）、华东2（上海）、华南1（深圳）三个地域，我们会结合您的资源数据、基础设施、业务规模进行容量评估，最终在匹配的地域开通适配的可用区作为金融云专区。

步骤三：创建专有网络（VPC）后，开通MyBase集群

1. 创建专有网络（VPC）,并配置虚拟路由器与虚拟交换机，将本套环境与其他环境的网络完全隔离。 金融云推荐网络环境。

2. 创建MyBase集群，可根据您的数据库业务进行资源的超配比例配置，实现降本增效。创建MyBase集群。

步骤四：创建MyBase主机，完成笼内主机资源部署

1. 在MyBase集群内创建主机，选择适配的数据库引擎，主机规格名称后缀带有"围笼规格" 如何创建MyBase主机。

如果准备使用RDS数据库，为了保障金融云内数据库的高可用性，建议至少创建2台主机。以实现一主一备的经典高可用架构。

重要

MyBase不支持主库和备库部署在同一台主机上，必须跨主机部署，才能保障高可用性。

目前金融云专区内MyBase支持的笼内主机规格主要为NVME SSD本地盘物理机型, 常见型号如下：

笼内主机型号	主机规格码
80vCPU 320GB内存 7TB本地SSD（围笼规格）	rds.ddh.i2g.20xlarge
80vCPU 640GB内存 17TB本地SSD（围笼规格	rds.ddh.i2.20xlarge
104vCPU 384G内存 5TB本地SSD（围笼规格	rds.ddh.i3g.26xlarge
104vCPU 768G内存 21TB本地SSD（围笼规格	rds.ddh.i3.26xlarge

1. 进行MyBase主机购买流程，完成支付，对比公共云，金融云有独立的价格体系。金融云产品定价。

步骤五：创建云数据库实例，完成笼内数据库资源部署

1. 主机创建后，需要在专属集群MyBase内创建数据库实例才能完成最终的笼内数据库部署。创建MyBase MySQL数据库实例。

2. 数据库实例创建成功后，就可以像使用RDS一样使用围笼内的数据库了。

重要

为了保障笼为数据的安全性和私密性, 数据库实例禁止开通外网访问。

4. 笼内MyBase数据库管理

4.1 登录主机黑屏管理实例

围笼内的MyBase数据库，除了资源专属、金融合规等产品特性，还具备自主可控，白盒化运维的特点。

金融行业的用户在笼内数据库的使用过程中，难以避免的会出现各种问题，比如：慢SQL、只读库延时等，这种情况下在传统的云数据库运维中一般需要申请工单处理，而对于MyBase数据库，可以由用户的DBA或运维人员进行自主操作。

在MyBase控制台的主机列表菜单栏中选中“远程连接”即可登录主机。

以MySQL为例，在MyBase主机中可以部署多个实例，它们在主机中占用不同的端口号。

可以在主机详情页中查看各个MySQL实例监听的端口号：

通过上面查询出的信息，我们就可以使用黑屏方式连接到主机，并且可以本地登录到数据库实例中，下面通过两个MySQL的例子来实践说明：

4.2 加速binlog消费，解决主备延时问题

当发现备实例复制延时后, 使用aliyun_root账户和port本地登录到实例：

重要

aliyun_root拥有云数据库的最高权限, 仅MyBase数据库开放，请按生产安全规范合理使用。

针对实例的延时情况，可以采取一些优化的措施加速binlog消费，比如调整刷盘参数，这样可以加快binlog的消费，让备库尽快追上主库。

SET SQL_LOG_bin=0;                            # 避免命令同步到主库
set global sync_binlog = 1000;                # 调整binlog刷盘参数
set global innodb_flush_log_at_trx_commit=0;  # 调整innodb刷盘参数

4.3 内存使用分析

在MySQL的使用中，有时候会出现内存使用率缓慢增加，严重的时候会引起OOM，引起实例HA切换，影响业务。

使用PTS（Performance Schema）来分析问题。

步骤一：打开PTS，激活内存相关数据分析

mysql> show variables like 'performance_schema';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| performance_schema | ON    |
+--------------------+-------+
1 row in set (0.00 sec)

update performance_schema.setup_instruments set enabled = 'yes' where name like 'memory%';

步骤二：排查哪些访问用户使用的内存比较大

mysql> select user, current_count_used ccu, current_allocated, current_avg_alloc, current_max_alloc, total_allocated from sys.memory_by_user_by_current_bytes;
+--------------+--------+-------------------+-------------------+-------------------+-----------------+
| user         | ccu    | current_allocated | current_avg_alloc | current_max_alloc | total_allocated |
+--------------+--------+-------------------+-------------------+-------------------+-----------------+
| member_user  | 104614 | 414.91 MiB        | 4.06 KiB          | 348.01 MiB        | 338.94 GiB      |
| bet_user     |  10208 | 34.56 MiB         | 3.47 KiB          | 34.41 MiB         | 11.16 GiB       |
| member_wallet|   6172 | 32.94 MiB         | 5.46 KiB          | 32.55 MiB         | 1.52 GiB        |
| replicate    |      3 | 12.04 KiB         | 4.01 KiB          | 8.00 KiB          | 16.30 MiB       |
| background   |    447 | 2.08 KiB          | 5 bytes           | 15.16 KiB         | 110.85 MiB      |
+--------------+--------+-------------------+-------------------+-------------------+-----------------+
5 rows in set (0.00 sec)

步骤三：排查哪些主机使用的内存较多

mysql> select host, current_count_used ccu, current_allocated, current_avg_alloc, current_max_alloc, total_allocated from sys.memory_by_host_by_current_bytes WHERE host IS NOT NULL;
+---------------+-------+-------------------+-------------------+-------------------+-----------------+
| host          | ccu   | current_allocated | current_avg_alloc | current_max_alloc | total_allocated |
+---------------+-------+-------------------+-------------------+-------------------+-----------------+
| 192.168.20.25 | 37379 | 147.19 MiB        | 4.03 KiB          | 119.26 MiB        | 139.59 GiB      |
| 192.168.10.172| 36815 | 144.81 MiB        | 4.03 KiB          | 119.37 MiB        | 101.59 GiB      |
| 192.168.10.104| 35996 | 139.12 MiB        | 3.96 KiB          | 119.42 MiB        | 105.15 GiB      |
| 127.0.0.1     |  6301 | 33.63 MiB         | 5.47 KiB          | 33.25 MiB         | 1.54 GiB        |
| 172.16.30.42  |  6630 | 31.78 MiB         | 4.91 KiB          | 31.73 MiB         | 7.56 GiB        |
| 172.16.32.78  |   339 | 1.33 MiB          | 4.01 KiB          | 1.32 MiB          | 19.39 MiB       |
| 172.16.32.69  |   205 | 1.05 MiB          | 5.24 KiB          | 1.05 MiB          | 2.10 MiB        |
| 172.16.33.155 |   201 | 1.03 MiB          | 5.26 KiB          | 1.03 MiB          | 2.57 MiB        |
| background    |   463 | 1.96 KiB          | 4 bytes           | 15.72 KiB         | 112.91 MiB      |
| 172.16.35.46  |     0 | 0 bytes           | 0 bytes           | 0 bytes           | 0 bytes         |
| 172.16.32.43  |     0 | 0 bytes           | 0 bytes           | 0 bytes           | 0 bytes         |
+---------------+-------+-------------------+-------------------+-------------------+-----------------+
11 rows in set (0.01 sec)

步骤四：排查占用内存多的SQL

SELECT    m.thread_id tid,   USER,   esc.DIGEST_TEXT,   total_allocated  FROM   sys.memory_by_thread_by_current_bytes m,   performance_schema.events_statements_current esc WHERE m.`thread_id` = esc.THREAD_ID \G;
*************************** 1. row ***************************
            tid: 615122
           USER: member_user@172.16.30.42
    DIGEST_TEXT: UPDATE TRIGGERS SET `trigger_source` = ? , `modify_time` = ? , `enc_type` = ? , DATA = ? WHERE `trigger_id` = ? 
total_allocated: 1007.24 MiB
*************************** 2. row ***************************
            tid: 3764468
           USER: bet_user@172.16.32.78
    DIGEST_TEXT: SELECT `announcement_content` `announcementContext` FROM `sbi_announcement` WHERE ? = ? AND `is_disable` = ? ORDER BY `create_time` DESC LIMIT ?, ... 
total_allocated: 1006.90 KiB
...

通过上面的步骤，可以收集到占用内存较多的用户、主机、SQL，然后综合分析定位问题，一般就能抓到“幕后黑手”。

通常情况下，并发的大事务会导致内存占用较高，而且MySQL对于这些占用的内存不会释放（便于后续的查询可以复用内存），这样就会导致内存处于高位。通过MyBase的白盒式运维，可以方便用户快速定位问题, 高效解决性能隐患和问题。

另外, 由于MyBase开放了主机OS，可以根据以上的排查过程编写Shell脚本，然后部署在主机上，以crontab日程定时调用脚本，兼顾了黑屏时代MySQL经典运维的习惯。

4.4 围笼容灾方案

另外，MyBase还提供同城的容灾方案：

• 在围笼内部署MyBase数据库主实例的主备双节点（读写），实现单实例AZ内容灾能力。在别的区域部署灾备实例双节点（只读，主从高可用）。

• 容灾方案涉及3个DB实例共4个节点，以及DTS双向同步任务（master->master）。此时只有围笼内->围笼外的数据同步路径生效。DTS会打包在MyBase产品中，降低维护的成本。

• 正常模式下，所有AZ的App都优先访问围笼内的DB实例，以保证数据私密性。

在金融领域，一般都会有定期的容灾模拟演练，来验证灾备系统的数据库是否满足RTO、RPO的指标。

通过MyBase提供的笼内龙外容灾方案，在用户进行故障切换演练中可以一键完成且能回切，并可通过API实现批量切换，基本等同于真实接管业务能力的数据库切换演练，完全满足银保监会要求的灾备切换要求

1. 根据金融云专区容量规划和数据私密性需求，可以选择笼内笼外容灾或双围笼容灾两种容灾方案。

2. 根据容灾切换需求选择DTS链路为单向还是双向同步，如果需要容灾回切，建议使用DTS双向同步。

5. 总结

云数据库专属集群MyBase在金融云的物理围笼最佳实践，旨在解决金融云用户来自主管部门的监管要求，即和云上其他用户的资源进行物理强隔离。同时，MyBase创建的实例可以落在指定金融专区的服务器上，允许开放底层资源权限，拥有RDS和NoSQL的云产品能力，提供数据库内核兜底，通过金融云专区+围笼集群+DDH主机+云数据库服务这样一站式的数据库专属平台解决方案实现了金融客户的需求。

该实践方案是金融行业用户强监管合规、轻资产交付的最佳选择。现已在国内多家金融消金、保险企业落地实施。