Longhorn跨AZ实现存储高可用

Longhorn跨AZ实现存储高可用

longhorn基础组件功能及其作用这里就不做介绍了

方案一

• Longhorn跨AZ的高可用的就是一个PVC的replicas 均匀打散的不同的AZ区域之间，这样当某个AZ挂掉后，engine会立即使用另外一个数据副本，并重建这个副本，但是目前的关键点是如何将replica均匀打散到不同的AZ区域

• 为保证最大程度上的跨AZ数据高可用，这里列出关于longhorn关键参数(仅供参考)

	# replica-soft-anti-affinity是否允许replica跑在使用pv的节点上# default-replica-count	设置pv数据副本个数# default-data-locality是否允许replica跑在使用pv的节点上# auto-salvage当所有副本挂掉，时候允许longhorn找出可用的副本# auto-delete-pod-when-volume-detached-unexpectedly如果启用，当Longhorn卷意外分离(例如Kubernetes升级、Docker重启或网络断开)时，Longhorn将自动删除由控制器管理的工作负载pod。通过删除pod，其控制器将重新启动pod, Kubernetes将处理卷的重新连接和重新挂载# disable-scheduling-on-cordoned-node禁止在cordon节点安排replica# `replica-zone-soft-anti-affinity`    实现跨AZ高可用关键参数允许将卷的新副本调度到与现有健康副本相同区域中的节点。不属于任何Zone的节点将被视为属于同一个Zone。注意Longhorn依赖于标签拓扑。topology.kubernetes.io/zone=<Zone name of the node>

方案二

• 使用longhorn的backup/restore功能，但是随着数据量的增加，RTO时间具体需要多久待测试，且由于backup是定时或某个时刻手动触发的，RPO大小取决于备份完成后到发生故障这段时间具体产生了多少数据。且用户是否能容忍丢失这个数据量？

• 验证略

方案一验证

• 验证跨区域高可用(这里我们用topology.kubernetes.io/zone来模拟不同的zone)
• Longhorn需要开启：replica-zone-soft-anti-affinity参数，实现replica跨AZ数据同步
• 这里仅验证replica在某个AZ down是否可用，某个AZ内replica down了，实测是会重构replica，这里不做验证了

# 查看k8s节点
╰─ kubectl get nodes -o custom-columns=NAME:.metadata.name,LABELS:.metadata.labels
NAME           LABELS
k8s-master-1   map[beta.kubernetes.io/arch:arm64 beta.kubernetes.io/os:linux kubernetes.io/arch:arm64 kubernetes.io/hostname:k8s-master-1 kubernetes.io/os:linux]
k8s-node-1     map[beta.kubernetes.io/arch:arm64 beta.kubernetes.io/os:linux kubernetes.io/arch:arm64 kubernetes.io/hostname:k8s-node-1 kubernetes.io/os:linux]
k8s-node-2     map[beta.kubernetes.io/arch:arm64 beta.kubernetes.io/os:linux kubernetes.io/arch:arm64 kubernetes.io/hostname:k8s-node-2 kubernetes.io/os:linux]
k8s-node-3     map[beta.kubernetes.io/arch:arm64 beta.kubernetes.io/os:linux kubernetes.io/arch:arm64 kubernetes.io/hostname:k8s-node-3 kubernetes.io/os:linux]# 设置节点zonekubectl label nodes k8s-master-1 k8s-node-1 topology.kubernetes.io/zone=one --overwritekubectl label nodes k8s-node-2 k8s-node-3 topology.kubernetes.io/zone=two --overwrite# 测试YAML
╰─ cat mysql.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:name: mysql-pvcnamespace: devops
spec:storageClassName: longhornaccessModes:- ReadWriteOnceresources:requests:storage: 5Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:name: mysqlnamespace: devops
spec:selector:matchLabels:app: mysqltemplate:metadata:labels:app: mysqlspec:containers:- image: docker.io/library/mysql:8.2name: mysqlenv:- name: MYSQL_ROOT_PASSWORDvalue: passwordports:- containerPort: 3306name: mysqlvolumeMounts:- name: datamountPath: /var/lib/mysqlvolumes:- name: datapersistentVolumeClaim:claimName: mysql-pvc
---

通过上图我们可以发现：

1. 我们事先打的zone标签，longhorn识别了
2. 我们在创建mysql后，查看pv信息可以发现，replica分布在二个不同的ZONE区域

# 生成1000条数据
cat > 1.sql <<"EOF"
CREATE DATABASE `test_bai`;
USE `test_bai`;
CREATE TABLE `app_user`(`id` INT  NOT NULL AUTO_INCREMENT COMMENT '主键',`name` VARCHAR(50) DEFAULT '' COMMENT '用户名称',`email` VARCHAR(50) NOT NULL COMMENT '邮箱',`phone` VARCHAR(20) DEFAULT '' COMMENT '手机号',`gender` TINYINT DEFAULT '0' COMMENT '性别（0-男  ： 1-女）',`password` VARCHAR(100) NOT NULL COMMENT '密码',`age` TINYINT DEFAULT '0' COMMENT '年龄',`create_time` DATETIME DEFAULT NOW(),`update_time` DATETIME DEFAULT NOW(),PRIMARY KEY (`id`)
)ENGINE = INNODB DEFAULT CHARSET = utf8 COMMENT='app用户表';
SET GLOBAL log_bin_trust_function_creators=TRUE;
DELIMITER $$
CREATE FUNCTION mock_data()
RETURNS INT
BEGINDECLARE num INT DEFAULT 1000;DECLARE i INT DEFAULT 0;WHILE i < num DOINSERT INTO app_user(`name`,`email`,`phone`,`gender`,`password`,`age`)VALUES(CONCAT('用户',i),'2548928007qq.com',CONCAT('18',FLOOR(RAND() * ((999999999 - 100000000) + 1000000000))),FLOOR(RAND()  *  2),UUID(),FLOOR(RAND()  *  100));SET i =  i + 1;END WHILE;RETURN i;
END;
SELECT mock_data();
EOF# 导入数据
bash-4.4# mysql -uroot -ppassword < 1.sql
mysql: [Warning] Using a password on the command line interface can be insecure.
mock_data()
1000

将k8s-node-3/k8s-node-2节点关机(模拟zone-two down,mysql目前也跑在这个zone)

# 等待controller-manager驱逐mysql后，在zone-one启动mysql
╰─ kubectl get pods -n devops -o wide | grep mysql 
mysql-7bc9bc8b55-g7jn8                   1/1     Running   0                   118s    172.16.1.85    k8s-node-1     <none>           <none># mysql 调度到k8s-node-1后，查询数据量大小
bash-4.4# mysql -uroot -ppassword -e "use test_bai; select count(*) from app_user;"
mysql: [Warning] Using a password on the command line interface can be insecure.
+----------+
| count(*) |
+----------+
|     1000 |
+----------+

通过上述测试我们可以发现

• 当zone-two down后，pv的replica被标志为失败，且会在zone-one找一个节点去复制pv的replica来保证replica=2(即使我们配置了replica不能在同一个zone)
• 数据量大小也一致(未发生数据丢失)，这里仅做了小数据验证

注意：节点异常->apiserver感知->controller-manager驱逐mysql是存在一段间隔时间的(取决于controller-manager和kubelet上报节点状态信息间隔等参数)，这段时间实际上是无法访问的