分布式1024节点！1天玩转 PolarDB-X 超大规模集群

Posted 2023-03-09 阿里云云栖号

架构简介

PolarDB-X 采用 Shared-nothing 与存储分离计算架构进行设计，系统由4个核心组件组成。

• 计算节点（CN, Compute Node） 计算节点是系统的入口，采用无状态设计，包括 SQL 解析器、优化器、执行器等模块。负责数据分布式路由、计算及动态调度，负责分布式事务 2PC 协调、全局二级索引维护等，同时提供 SQL 限流、三权分立等企业级特性。
• 存储节点（DN, Data Node） 存储节点负责数据的持久化，基于多数派 Paxos 协议提供数据高可靠、强一致保障，同时通过 MVCC 维护分布式事务可见性。
• 元数据服务（GMS, Global Meta Service） 元数据服务负责维护全局强一致的 Table/Schema, Statistics 等系统 Meta 信息，维护账号、权限等安全信息，同时提供全局授时服务（即 TSO）。
• 日志节点（CDC, Change Data Capture） 日志节点提供完全兼容 mysql Binlog 格式和协议的增量订阅能力，提供兼容 MySQL Replication 协议的主从复制能力。

开源地址：[https://github.com/polardb/polardbx-sql]

实验说明

PolarDB-X在22年11月份，发布开源v2.2新版本，这是一个重要的里程碑版本，重点推出符合分布式数据库金融标准下的企业级和国产化适配，共包括八大核心特性，全面提升 PolarDB-X 分布式数据库在金融、通讯、政务等行业的普适性。 版本发布文档：PolarDB-X v2.2: 企业级和国产ARM适配 开源重磅升级

分布式数据库最重要的特性就是线性扩展，目前PolarDB-X现有用户生产部署有64~256节点的规模，考虑未来5~10年的发展诉求，期望分布式能至少支撑4~5倍的容量扩展，因此我们需要验证下分布式下更大规模的扩展性。

本实验主要通过polardbx-operator，借助阿里云ACK容器服务，快速部署和体验PolarDB-X的大规模分布式(1024节点)，通过常见的sysbench/tpc-c等benchmark工具来初步验证大规模节点下的稳定性。

部署架构

说明：

PolarDB-X采用存储计算分离的架构，CN和DN是可以独立部署，本实验设计部署1024个DN节点，比如公有云PolarDB-X单个DN节点可支持3TB，那超大规模节点下可支持 1024 * 3TB = 3PB
本实验设计为了可低成本的复现，节点规格上采用了压缩部署的模式，比如DN节点选择了最小的1C8GB (1024节点下也需要8TB的内存)，通过k8s的多租户cgroup技术，采用24台高配ECS进行部署，单个ECS平均需要承载40+的PolarDB-X CN/DN节点。
本实验所需要的测试资源的成本，24台ECS按量付费 288元/小时，测试时间1天左右，预计花费7000元。

1. 部署k8s集群 (阿里云ACK)

创建ACK托管(k8s集群)

创建集群节点池 (24个高配ECS节点)

k8s集群配置

通过kubectl get nodes，返回了ECS集群列表，说明k8s环境已安装完毕

主机参数配置

修改sysctl.conf和limits.conf的内容。建议通过ansible工具对每个主机进行修改。

sysctl.conf

配置内容：

net.ipv4.neigh.default.gc_stale_time=120

# see details in https://help.aliyun.com/knowledge_detail/39428.html
net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.default.arp_announce = 2
net.ipv4.conf.lo.arp_announce=2
net.ipv4.conf.all.arp_announce=2

# see details in https://help.aliyun.com/knowledge_detail/41334.html
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 1024
net.ipv4.tcp_synack_retries = 2

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

kernel.sysrq=1

net.core.somaxconn = 256
net.core.wmem_max = 262144

net.ipv4.tcp_keepalive_time = 20
net.ipv4.tcp_keepalive_probes = 60
net.ipv4.tcp_keepalive_intvl = 3

net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_fin_timeout = 15

#perf
kernel.perf_event_paranoid = 1

fs.aio-max-nr = 1048576

将文件保存为/etc/sysctl.conf，然后执行

sysctl -p /etc/sysctl.conf

limits.conf

配置内容：

#*               hard    rss             10000
#@student        hard    nproc           20
#@faculty        soft    nproc           20
#@faculty        hard    nproc           50
#ftp             hard    nproc           0
#@student        -       maxlogins       4

# End of file
root soft nofile 655350
root hard nofile 655350

* soft nofile 655350
* hard nofile 655350
* soft nproc 655350
* hard nproc 655350

admin soft nofile 655350
admin hard nofile 655350
admin soft nproc 655350
admin hard nproc 655350

alidb soft nofile 655350
alidb hard nofile 655350
alidb soft nproc 655350
alidb hard nproc 655350

将文件保存到/etc/security/limits.conf

2. 安装 polardbx-operator

helm repo add polardbx https://polardbx-charts.oss-cn-beijing.aliyuncs.com
helm install --namespace polardbx-operator-system --set imageRepo=docker.mirrors.sjtug.sjtu.edu.cn/polardbx polardbx-operator polardbx/polardbx-operator

3. 创建 polardb-x 实例

将以下内容保存为polardbx.yaml文件

kind: PolarDBXCluster
metadata:
  name: p1024
spec:
  config:
    cn:
      static:
        EnableCoroutine: true
        RPCProtocolVersion: 2
        ServerProperties:
          galaxyXProtocol: 0
      dynamic:
        TRANSACTION_POLICY: TSO
        CONN_POOL_XPROTO_STORAGE_DB_PORT: 0
        CONN_POOL_XPROTO_MAX_CLIENT_PER_INST: 8
        CONN_POOL_XPROTO_MAX_SESSION_PER_CLIENT: 256
        CONN_POOL_XPROTO_MIN_POOLED_SESSION_PER_INST: 32
        CONN_POOL_XPROTO_MAX_POOLED_SESSION_PER_INST: 128
        XPROTO_MAX_DN_WAIT_CONNECTION: 1000
        XPROTO_MAX_DN_CONCURRENT: 2000
        RECORD_SQL: "false"
        SHARD_DB_COUNT_EACH_STORAGE_INST: 1
        MPP_METRIC_LEVEL: 0
  topology:
    rules:
      components:
        dn:
          rolling:
            replicas: 1
    nodes:
      gms:
        template:
          image: docker.mirrors.sjtug.sjtu.edu.cn/polardbx/polardbx-engine:80-8.0.18-20221208170957
          hostNetwork: false
          resources:
            limits:
              cpu: 16
              memory: 32Gi
          imagePullPolicy: IfNotPresent
      cn:
        replicas: 16
        template:
          image: docker.mirrors.sjtug.sjtu.edu.cn/polardbx/polardbx-sql:5.4.15-20221129135549
          hostNetwork: false
          resources:
            limits:
              cpu: 16
              memory: 16Gi
          imagePullPolicy: IfNotPresent
      dn:
        replicas: 1024
        template:
          image: docker.mirrors.sjtug.sjtu.edu.cn/polardbx/polardbx-engine:80-8.0.18-20221208170957
          hostNetwork: false
          resources:
            limits:
              cpu: 1
              memory: 8Gi
          imagePullPolicy: IfNotPresent
      cdc:
        replicas: 2
        template:
          image: docker.mirrors.sjtug.sjtu.edu.cn/polardbx/polardbx-cdc:5.4.15-2022110310
          hostNetwork: false
          resources:
            limits:
              cpu: 16
              memory: 16Gi
          imagePullPolicy: IfNotPresent

执行创建命令：

kubectl apply -f polardbx.yaml

可通过如下命令查看创建进度：

kubectl get pxc -w

创建完成后，可参考 连接PolarDB-X数据库 连接数据库 说明：如果遇到个别节点POD长时间创建不出来，可以尝试kubectl delete pod xx触发重新创建

4. 数据库体验和压测

PolarDB-X提供了benchmark一键压测工具，可参考文档：使用Benchmark Boot进行压测

一键安装命令：

在前端机器的浏览器上，访问 http://前端机器IP:4121/，出现 Benchmark-Boot 首页，证明部署成功。 参考benchmark boot工具的操作指南，通过页面完成： 配置数据库连接 -> TPCC数据导入 -> TPCC压测

正常的TPC-C运行日志

show stats查询运行指标，平均RT在0.67ms，表现比较平稳

数据库验证体验项：

说明：本实验采用了24台ECS部署，并非关注性能摸高，重点模拟1024节点下的数据库稳定性，比如30~50万 tps下的平均rt、以及12小时的高压长稳测试，仅供用户参考和复现实验操作。

图4.1

图4.2

图4.3

图4.4

图4.5

总结

分布式数据库主打线性扩展的能力，可以在满足OLTP高并发下提供海量PB级别的存储能力，在超大规模的集群架构下会带来蛮多技术挑战，比如：

元数据膨胀。管理大规模的1024个物理节点，需要关注节点高可用、以及元数据的存储，比如分布式的DAL、DDL，在任务执行上下文以及分布式聚合时会带来更大的内存开销。比如，batch insert场景下的分布式事务，会涉及1024个节点的分支事务管理，分布式事务的上下文和并发提交都会带来一定的挑战。

TCP连接风暴。 分布式share-nothing架构，不可避免会发生数据分片路由和转发，这里就会涉及节点之间的互相访问，比如PolarDB-X每个CN节点都要和DN节点建立RPC请求，在高压并发下节点之间需要RPC的连接池来提升性能(比如8~16个TCP连接)，通过1024个DN节点的放大，每个CN节点可能会出现几万的TCP连接，需要对RPC连接进行有效管理。本实验中，PolarDB-X CN配置16GB的内存来支撑1024节点的RPC连接。

分布式并发死锁。 分布式下不带分片条件的查询，因为无法命中分区裁剪，会带来全分片的查询(简称为：跨分片查询)。比如10个并发的跨分片查询，通过1024个DN节点的放大，会产生瞬时几万的分片并发查询，复杂的并发请求会产生互相等待的并发死锁的情况，造成更大的爆炸半径。比如，DDL操作的MDL锁获取，会因为个别长事务未提交而一直卡主，进一步阻塞后续其他的SQL，因为跨分片查询下的个别查询被锁住，在大规模节点下容易放大影响。

CDC多流日志合并。分布式数据库会通过CDC组件，向下游提供类似mysql binlog的机制，技术实现上都需要采集集群中的所有节点日志，进行采集和归并处理。通过1024个DN节点的放大，原本1024分之的归并排序无法满足性能和稳定性要求，需要引申出多流归并、以及内存swap机制。

实践是检验真知的唯一标准，通过本实验的设计，结合阿里云的云服务，可以快速且低成本的验证PolarDB-X在超大规模1024节点，在百万级别的TPS下满足业务使用的稳定性。

作者：七锋、不俗

原文链接

本文为阿里云原创内容，未经允许不得转载。