方案背景

客户主要生产业务在阿里云，运行在阿里云侧业务应用, MySQL, Redis, MongoDB，现在需要将阿里云侧资源与部署在Ucloud云平台的资源组建多活容灾系统

客户资源现状

资源	部署形式	实例数量	数据量	容灾策略
应用	大部分为普通应用,小部分容器	150台		DNS负载均衡
RDS	MySQL 5.7 binlog默认开启	8主5从	2T	PXC集群同步
Redis	主从版 4.0	5	4G	不做容灾处理
MongoDB	MongoDB 4.0 副本集	1	50G	单向同步容灾
ES	版本:6.8.6 数据节点4	1	300G左右	应用双写
Oracle	机器部署 Oracle 11G	1	1T左右	Rac方式同步

容灾方式

阿里云/ucloud 主从热备，默认阿里云主，ucloud从，故障后切换后，切换角色

容灾级别

基础设施容灾, Ucloud 支持多云组网能力，可以实现基础设施容灾，和提供数据库级容灾方案能力，对其他各个云厂商限制的应用可以实现定时备份的能力，

数据级容灾, 仅将生产中心的数据复制到容灾中心，在生产中心出现故障时，仅能实现存储系统的接管或是数据的恢复。容灾中心的数据可以是本地生产数据的完全复制（在同城实现），也可以比生产数据略微落后，差异的数据可以通过一些工具（如操作记录、日志等）可以手工补回。

应用级容灾, 是在数据级容灾的基础上，在Ucloud侧创建和阿里云侧生产中心系统的核心资源复制，包括主机、数据库、应用、当生产系统发生灾难时，依赖GTM实现故障切换，切换到备用可用区，实现应用级容灾.

方案概述

多云不同 Region 内网互通，使用ucloud罗马打通
使用GTM 做业务流量调度 -> SLB/ULB(两地中心入口地址) https://developer.aliyun.com/article/754825
业务架构面向多活架构改造
业务应用弹性扩缩容
1. 容器化应用采用k8s集群的原生特性自动扩容(CA/HPA/VPA)
2. 虚拟机扩容采用监控结合API方式扩容
数据集群分布式化
1. mysql采用强一致性的集群方案Percona XtraDB Cluster
2. MongoDB容灾采用 MongoShake 单向实时同步
3. Oracle 可以寻求商业支持，例如采用Oracle Rac高可用方案

GTM流量调度

GTM 本质上是通过 DNS，结合监控，实现流量调度，为客户输出不同网络或地区用户访问实现就近接入、应用服务运行状态的健康检查、故障自动切换，等能力。

GTM和LB对比表

对比项	网络层	后端地址	加权轮询	跨Region难度	故障间隔时间	会话保持
GTM	3 层	域名、IP	支持	简单	分钟级	不支持
LB	4层、7层	IP	支持	困难	秒级	支持

GTM和GSLB 对比表

无法复制加载中的内容

GTM故障切换时间

GTM能在 5分钟内将应用服务的90%左右的流量切换成功。GTM的故障切换生效时间 = 故障发现时间 + DNS切换同步时间。

故障发现时间：目前默认的健康检查配置可以在故障的3分钟左右准确发现故障；
DNS切换同步时间：目前 GTM 的cname接入域名TTL设置为60秒，理论上域名切换后60秒内可以生效，但实际情况取决于全国各地运营商的缓存设置时间。

GTM主要应用场景

应用主备容灾：建立两个地址池 Pool A 和 Pool B，设置默认地址池为 Pool A、备用地址池为 Pool B ，结合健康检查，即可以实现应用服务主备IP容灾切换
应用多活：建立一个地址池Pool A，然后把 1.1.1.1、2.2.2.2、3.3.3.3 三个地址添加进地址池，并配置上健康检查，即可实现多个IP多活。
也适用于，高并发应用服务负载分摊，不同区域访问加速

业务应用系统面向多活架构改造

容灾说明：

业务应用需要清晰的解耦分层，web应用(无状态)，缓存/消息队列，ES日志，DB 云主机资源
阿里云/Ucloud云 VPC网络使用ipsecVpn 或者罗马打通vpc
业务域名入口采用阿里云GTM做跨Region 流量调度和故障切换
业务阿里云/Ucloud云容灾，其中阿里云BGP入口为主，Ucloud云BGP入口为备用，阿里云杭州可用区和UC上海可用区使用罗马打通VPC网络，延时4-6ms
阿里云资源故障后，GTM将流量切换到Ucloud云BGP入口
Ucloud云资源全新部署，建议web应用采用容器集群，充分利用k8s原生的特性实现节点自动扩容，应用实例扩容
1. Cluster Autoscaler：集群node节点扩容/缩容
2. HPA： Pod个数自动扩/缩容
3. VPA ：Pod配置自动扩/缩容，主要是CPU、内存 addon-resizer组件
虚拟机扩容采用监控结合API方式扩容 (节点监控(cpu/mem/connet) -> monitor -> altermanager-webhook-API操作扩容 )
MySQL数据层建议采用兼容InnoDB引擎的Percona XtraDB Cluster集群模式来保证强一致性
MongoDB容灾采用 MongoShake实现实时从阿里云侧同步到Ucloud云侧

问题：

1、网络抖动或短时故障，不建议切业务主备，影响时间将更长

2、都云异构的容灾方式后续维护成本较高，包括物理环境、网络环境、自建系统环境等，需要业务侧投入人力更大

3、Percona XtraDB Cluster保证了强一致性能，但是牺牲了部分性能

image

不支持在 Docs 外粘贴 block

MongoDB 容灾

MongoShake从源库抓取oplog数据，然后发送到各个不同的tunnel通道。源库支持：ReplicaSet，Sharding，Mongod，目的库支持：Mongos，Mongod。

MongoDB同步方式采用 Direct通道类型，直接写入目的MongoDB

DB容灾方案

Percona XtraDB Cluster(简称PXC)，是由percona公司推出的mysql集群解决方案。特点是每个节点都能进行读写，且都保存全量的数据。也就是说在任何一个节点进行写入操作，都会同步给其它所有节点写入到自己的磁盘，选择PXC作为容灾方案的理由是:

PXC 强一致性特性，在故障转移，恢复等自动化程度高
支持 IST 增量传输，适合在跨地域，网路延迟较高的场景做同步
阿里云侧和Ucloud侧各自配置了一个4层LB来作为DB请求的入口，轮询方式(避免)

PXC特性和优点

完全兼容 MySQL。
同步复制，事务要么在所有节点提交或不提交。
多主复制，可以在任意节点进行写操作。
在从服务器上并行应用事件，真正意义上的并行复制。
节点自动配置，数据一致性，不再是异步复制。
故障切换：因为支持多点写入，所以在出现数据库故障时可以很容易的进行故障切换。
自动节点克隆：在新增节点或停机维护时，增量数据或基础数据不需要人工手动备份提供，galera cluster会自动拉取在线节点数据，集群最终会变为一致；

PXC最大的优势：强一致性、无同步延迟，适合订单，交易系统等场景

PXC的局限和劣势

复制只支持InnoDB 引擎，其他存储引擎的更改不复制
短板效应
- 集群写入性能取决于性能最差那台机器，所以建议配置相同
锁冲突严重
- 建议单节点写+负载均衡，或者写不同的库
全量SST时，donor节点性能影响较为严重，receiver恢复较慢
- 尽量避免SST
维护成本高，限制和注意事项较多

PXC与Replication的区别

无法复制加载中的内容

PXC 使用注意事项

PXC各个节点默认是不会记录全量日志的，只会记录当前节点变化数据的binlog：想要节点记录全量binlog日志需要添加该配置：log_slave_updates, 在PXC集群中，官方推荐使用相同的server-id
PXC支持两种同步方式：
1. SST 全量传输支持 XtraBackup、mysqldump、rsync三种方式，
2. IST 增量传输支持 XtraBackup
群集的最小建议大小是3个节点。第三个节点会是仲裁者
复制仅适用于InnoDB存储引擎。其他存储引擎的表的写入都不复制(包括mysql.表)。但是，DDL语句会在statement级别进行复制，对mysql.表的更改将以这种方式进行复制。因此您使用CREATE USER...命令，而不应该使用INSERT INTO mysql.user...。
不支持的查询：
1. 在多主设置中，不支持LOCK TABLES和UNLOCK TABLES
2. Lock functions如GET_LOCK(),RELEASE_LOCK()也不支持
general.log、slow.log不支持输出到TABLE，如果启用general.log、slow.log，则必须将日志输出到文件：

log_output  =  FILE

设置输出到table，会有严重的锁冲突，导致性能问题，严重时导致mysqld崩溃。

允许的最大事务大小由wsrep_max_ws_rows和wsrep_max_ws_size变量定义。LOAD DATA INFILE处理将(按参数设置)每10000行提交一次。因此大事务LOAD DATA时将被拆分为一系列小事务。
由于集群级的乐观并发控制，事务在COMMIT阶段可能仍会中止。可以有两个事务写入相同的行并在单独的Percona XtraDB Cluster节点中提交，并且只有其中一个可以成功提交。失败的将被中止。对于集群级中止，Percona XtraDB Cluster提供了死锁错误代码：

(Error: 1213 SQLSTATE: 40001  (ER_LOCK_DEADLOCK)).

由于可能在提交时回滚，因此不支持XA事务。
整个集群的写吞吐量受最弱节点的限制。如果一个节点变慢，则整个群集速度变慢。如果您对稳定的高性能有要求，则应该由相应的硬件支持。
不支持InnoDB虚假更改功能。enforce_storage_engine=InnoDB与wsrep_replicate_myisam=OFF（默认）不兼容。
在群集模式下运行Percona XtraDB群集时，请避免ALTER TABLE ... IMPORT/EXPORT操作。如果未在所有节点上同步执行，则可能导致节点数据不一致。
所有表必须具有主键。这可确保相同的行在不同节点上以相同的顺序出现。DELETE没有主键的表的语句不被支持。

无法复制加载中的内容

POC 环境以及测试数据

GTM故障切换

这里采用阿里云的GTM服务做业务流量调度，和

首先需要开通阿里云GTM服务，购买GTM实例，完成基本配置域名和配置地址池

image

为地址池IP 添加健康检查，支持ping tcp http https

image

设置访问策略

image

模拟故障，停掉主地址池IP 业务应用服务，业务域名解析会切换到备用地址池IP

阿里云 GTM 标准版本TTL需要10分钟，健康检查最小间隔分钟级，需要更快切换，建议购买阿里云 GTM 旗舰版服务

image

故障恢复后，业务域名会重新恢复到主地址池

业务应用扩容

业务应用弹性扩容分两个场景, 容器方式部署的应用和虚拟机部署的应用：

容器应用扩容

首先将应用转变容器应用，然后部署在k8s集群中，可以充分k8s集群的能力，实现自动扩缩容：

集群节点的自动扩容
应用资源配额的横向/纵向扩容
通过配置uk8s的集群伸缩，可以实现集群node节点扩容/缩容(Cluster Autoscaler)

image

Metrics-server 已经内置，Pod个数自动扩/缩容(HPA)，只需要对应用配置 HPA 即可，示例如下:

创建一个nginx服务，ULB 由 cloudprovider-ucloud 自动创建，和公有云相关配置在名为uk8sconfig的configmap中,创建 test-nginx.yaml

apiVersion: v1
kind: Service
metadata:
  name: ucloud-nginx
  labels:
    app: ucloud-nginx
spec:
  type: LoadBalancer
  ports:
    - protocol: TCP
      port: 80
  selector:
    app: ucloud-nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ucloud-nginx
spec:
  selector:
    matchLabels:
      app: ucloud-nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: ucloud-nginx
    spec:
      containers:
      - name: ucloud-nginx
        image: uhub.service.ucloud.cn/ucloud/nginx:1.9.2
        resources:
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
        ports:
        - containerPort: 80

执行命令: kubectl apply -f test-nginx.yaml 创建资源，

执行命令: kubectl get services 可以查询到 EXTERNAL-IP 即创建服务生成ULB外网IP

创建HPA配置，参考如下：

apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: ucloud-nginx
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: ucloud-nginx
  minReplicas: 1
  maxReplicas: 1000
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 2
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 500
        periodSeconds: 15
      - type: Pods
        value: 10
        periodSeconds: 15
      selectPolicy: Max
    scaleDown:
      stabilizationWindowSeconds: 10
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15

缩容策略: 稳定窗口的时间为 300 秒，允许 100% 删除当前运行的副本，
扩缩策略: 立即扩容，每 15 秒添加 4 个 Pod 或 100% 当前运行的副本数，直到 HPA 达到稳定状态。
https://kubernetes.io/zh/docs/tasks/run-application/horizontal-pod-autoscale/

使用AB压测验证:

操作压测集群节点执行命令: ab -n 100000 -c 300 http://nginx_server_ip/

集群初始状态:

image

压测过程中，随着请求带来对pod带来的压力，会触发Pod快速扩容个数，同时集群node节点的请求值达到扩容阈值的时候，会自动新增node节点

image

在压测结束后，稳定窗口时间结束后，集群内pod数量，node节点数会恢复到初始状态

Pod配置自动扩/缩容(VPA) 需要部署vertical-pod-autoscaler控制器参考https://github.com/kubernetes/autoscaler VPA示例以及VPA使用限制

apiVersion: autoscaling.k8s.io/v1beta2
kind: VerticalPodAutoscaler
metadata:
  name: nginx-vpa
  namespace: vpa
spec:
  targetRef:
    apiVersion: "apps/v1"
    kind: Deployment
    name: nginx
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: "nginx"
      minAllowed:
        cpu: "250m"
        memory: "100Mi"
      maxAllowed:
        cpu: "2000m"
        memory: "2048Mi"

不能与HPA（Horizontal Pod Autoscaler ）一起使用
Pod比如使用副本控制器，例如属于Deployment或者StatefulSet

非容器应用扩容

虚拟机节点扩容目前没有标准的服务，可以结合监控，调用API方式扩容，需要结合具体业务监控做ucloud平台接口对接实现。

部署 PXC 集群

部署第一个节点

docker run -d                    \
-p 3306:3306                     \
-e MYSQL_ROOT_PASSWORD=abc123456 \
-e CLUSTER_NAME=PXC              \
-e XTRABACKUP_PASSWORD=abc123456 \
-v /data/:/var/lib/mysql         \
--privileged                     \
--name=pxc-node-1                \
--net=host                       \
percona/percona-xtradb-cluster:5.7

加入其他节点

docker run -d                    \
-p 3306:3306                     \
-e MYSQL_ROOT_PASSWORD=abc123456 \
-e CLUSTER_NAME=PXC              \
-e XTRABACKUP_PASSWORD=abc123456 \
-e CLUSTER_JOIN=pxc-node-1       \
--privileged                     \
--name=pxc-node-4                \
--net=host                       \
percona/percona-xtradb-cluster:5.7

可用性测试

停掉任一节点，PXC集群服务不中断，业务应用无感知
如需PXC升级集群配置，逐台离线升级，重建加入集群即可

sysbench压力测试

mysql -h 10.10.114.135 -uroot -pabc123456
create database sbtest;

sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua \
--mysql-host=10.10.114.135  \
--mysql-port=3306           \
--mysql-user=root           \
--mysql-password=abc123456  \
--oltp-test-mode=complex    \
--oltp-tables-count=10      \
--oltp-table-size=10000     \
--threads=10                \
--time=120                  \
--report-interval=10 prepare

sysbench /usr/share/sysbench/tests/include/oltp_legacy/oltp.lua \
--mysql-host=10.10.114.135  \
--mysql-port=3306           \
--mysql-user=root           \
--mysql-password=abc123456  \
--oltp-test-mode=complex    \
--oltp-tables-count=10      \
--oltp-table-size=100000    \
--threads=10                \
--time=120                  \
--report-interval=10 run >> /root/sysbench-mysql.log

POC 应用环境

整个 POC 环境使用，wordpress / redis插件/ PXC DB集群北京/上海两地多活部署方式

北京/上海两地网络延迟平均30ms
北京/上海两地k8s集群规模 3master 5node
PXC DB 集群单节点配置 4核8G sysbench测试结果

   SQL statistics:
    queries performed:
        read:                            304850
        write:                           54616
        other:                           76002
        total:                           435468
    transactions:                        21760  (181.25 per sec.)
    queries:                             435468 (3627.15 per sec.)
    ignored errors:                      15     (0.12 per sec.)
    reconnects:                          0      (0.00 per sec.)

General statistics:
    total time:                          120.0560s
    total number of events:              21760

Latency (ms):
         min:                                   52.43
         avg:                                   55.16
         max:                                  110.09
         95th percentile:                       56.84
         sum:                              1200266.64

Threads fairness:
    events (avg/stddev):           2176.0000/14.59
    execution time (avg/stddev):   120.0267/0.02

多云容灾以及弹性扩容技术方案

方案背景

客户资源现状

容灾方式

容灾级别

方案概述

GTM流量调度

GTM和LB对比表

GTM和GSLB 对比表

GTM故障切换时间

GTM主要应用场景

业务应用系统面向多活架构改造

MongoDB 容灾

DB容灾方案

PXC特性和优点

PXC的局限和劣势

PXC 使用注意事项

POC 环境以及测试数据

GTM故障切换

业务应用扩容

容器应用扩容

非容器应用扩容

部署 PXC 集群

可用性测试

sysbench压力测试

POC 应用环境

你可能感兴趣的:(多云容灾以及弹性扩容技术方案)