系列文章目录

第一章-SUSE- Rancher-容器高可用与容灾测试-RKE2-外置Mysql（主备集群搭建）-CSDN博客

第二章-SUSE- Rancher-容器高可用与容灾测试-RKE2-集群搭建（外置Mysql）

第三章-SUSE- Rancher-容器高可用与容灾测试-Rancher-外置数据库（复用Mysql）

第四章-SUSE- Rancher-容器高可用与容灾测试-RKE2（容灾测试）

第五章-SUSE- Rancher-容器高可用与容灾测试-Rancher-back up（容灾测试）

第六章-SUSE- Rancher-容器高可用与容灾测试-Rancher拉起的集群（快照容灾测试）

第七章-SUSE- Rancher-容器高可用与容灾测试-Longhorn（容灾卷跨集群测试）

---

---

前言

第一章我们搭建好了Mysql（主备复制）实例。

第二章我们搭建好Rancher管理集群的基础设施- RKE2集群-Tarball方法-离线。

第三章我们使用helm离线方式部署好了Rancher到RKE2集群中，同时使用Rancher-backup-调度了一次备份任务到阿里云的对象存储。

本章我们做几个实验：

        1、RKE2集群-etcd-Mysql主备倒换-容灾测试。

        2、Rancher-backup-容灾测试。

                1、会对现有的Rancher做一些简单的变更，数据添加模拟运行了一段时间的Rancher。（比如修改密码等简单的，体现一下区别就行。）

                2、异地部署2台同规格的rke2主机.

                3、通过OSS将rke2集群需要的文件上传、在异地使用相同的离线镜像方式部署通过OSS拉取文件重新部署RKE2集群，模拟主数据中心故障，异地需要重新拉起RKE2集群的场景。

                4、拉起RKE2之后、一样的方式部署Rancher并且Rancher通过Rancher-backup还原。

---

一、RKE2集群-etcd-Mysql主备倒换。

先回顾一下我们到集群，2台节点部署RKE2-上面部署了Rancher以及Rancher-backup.使用的是外置的Mysql(主备)数据库。

本次先模拟主数据库故障，备数据库倒换。

主备倒换步骤

        1、先检查集群状态，所有业务都正常。

        2、主备数据库同步正常。

        3、备份一次主数据库。

        4、关闭主数据库（docker stop）

                1、观察Server节点的报错与rke2-server的状态做记录。

                2、观察worker节点的报错与rke2-agent的状态做记录。

        5、检查备数据库状态做记录。

        6、关闭备数据库只读状态，备升主。

        7、修改Server节点的config文件指向备数据库。

        8、检查业务是否恢复。

---

1.1、检查集群状态

1.1 RKE2集群：

1.2 Rancher以及Rancher-backup:

**这里说一下我今天升级了一下集群的配置，升级为了4C 8G。之前的2C 4G 太吃力了。

1.3 主数据库:

主数据库：

SHOW MASTER STATUS;

*注意bin的文件名称以及Position的位置编号。 

1.4 备数据库同步状态：

​​​​​​​SHOW SLAVE STATUS \G

**注意bin的文件名称以及Position的位置编号与主数据库为一致的。

1.5 备份

1.5.1 备份数据库

docker ps -a

 

你可以使用 docker exec 命令在运行的 MySQL 容器中执行 mysqldump 命令来备份数据库。

我的 MySQL 容器名称为 mysql-master，数据库名称为 kubernetes，你可以使用以下命令备份数据库：

docker exec mysql-master mysqldump -u root -pxxxxxx kubernetes  > /kubernetes_backup.sql

备份文件 kubernetes_backup.sql 会被保存到主机的 / 根目录下，而不是容器内部。这是因为你在命令中使用了 > 重定向符号，将 mysqldump 的输出重定向到了主机的文件系统中。

通过OSS客户端上传到我们备份的桶里。

 1.5.2 备份RKE2集群

上传Server与worker的配置文件在阿里云OSS上。
配置文件：

/etc/rancher/rke2/config.yaml

/etc/rancher/rke2/registries.yaml

对应RKE2版本的镜像文件：

 1.6 数据库灾备切换

1.6.1 关闭主数据库（docker stop）观察Server节点的报错与rke2-server的状态做记录。

*控制面pod全部卡死。 

执行kubectl 访问api-server报错：

1.6.2、观察worker节点的报错与rke2-agent的状态做记录。

因为Server节点控制面全部卡死，导致worker节点的保活机制全部挂掉。 

1.6.3 检查备数据库状态做记录。

SHOW SLAVE STATUS \G

*主数据库无法连接。 

1.6.4 在备库上执行以下命令，停止复制进程：

STOP SLAVE;
RESET SLAVE ALL;

1.6.5 提升备库为主库

在备库上执行以下命令，将其配置为可写，并更新相关配置：

SET GLOBAL read_only = OFF;
UNLOCK TABLES;

1.6.6 修改Server节点的config文件指向备数据库。

1.41为备数据库

1.6.7 重启rke2-server

systemctl restart rke2-server.service 

1.6.8 检查业务是否恢复。

server节点

journalctl -u rke2-server.service -f

Server节点启动就连接上了数据库。 说明OK的。

 Worker节点keeplive恢复。

节点上的POD正常运行。 

总结：这种方式的RTO和RPO比纯备份还原要好很多。 

---

总结

1、这篇文章整理的容灾备份是非常湿滑和顺利的，但是这里要达成如此湿滑的容灾也需要一点前提：

        1、优秀的镜像仓库的容灾机制。

        2、跨地域的对象存储。

        3、熟练的容灾恢复步骤。

        4、熟悉的人工操作手。

2、能达到上面这4点，基本上容灾的RTO和RPO可以做到很低。