1 迁移说明

公司的saas平台是容器化的，基于华为云CCE的。建设这套环境的时候，把对象存储minio也使用了容器化的方式。

目前saas客户包含一个正式客户和若干个试用客户，对象存储占用空间一个5.3G，空间还不算大。

目前这个阶段，我们准备将容器化的minio进行迁移，转化为非容器化的minio，方便后期进行minio的集群化和有可能的进一步数据迁移等操作(容器环境内可使用的工具比较少 相比之下 云主机上可以自由的使用各种工具进行操作)。

迁移方案的主要动作已基于预生产环境做了验证。因为预生产环境没有客户，所以只需要考虑功能性即可。对于生产环境，要考虑到新老minio切换的影响时长，并把影响时长和范围降低到最低。

2 准备minio

2.1 minio安装

minio的相关说明

• minio的包用的是docp5.4发版的basic中的包 包名为minio-2.0.0-20220409190925-3357069.tar.gz

• 新的minio跟之前的不一样 minio有两个端口 18125是服务端口 供别的服务调用 18205是访问端口 如果是云主机想访问minio 安全组里要开18205端口

安装命令如下 不做详细解释

mkdir -p /data/{app,appData/minio,logs/minio} && tar -xvf minio-*.tar.gz -C /data/app
# 替换启动脚本占位符
local_ip=`echo $(hostname -I)`
sed -i "s#\${CW_RUN_USER}#cloudwise#g" /data/app/minio/scripts/minio
sed -i "s#\${CW_INSTALL_APP_DIR}#/data/app#g" /data/app/minio/scripts/minio
sed -i "s#\${CW_INSTALL_LOGS_DIR}#/data/logs#g" /data/app/minio/scripts/minio
sed -i "s#\${CW_INSTALL_DATA_DIR}#/data/appData#g" /data/app/minio/scripts/minio
sed -i "s#\${CW_LOCAL_IP}#${local_ip}#g" /data/app/minio/scripts/minio
sed -i "s#\${CW_SERVICE_PORT}#18125#g" /data/app/minio/scripts/minio
sed -i "s#\${CW_CONSOLE_SERVICE_PORT}#18205#g" /data/app/minio/scripts/minio
sed -i "s#\${CW_MINIO_ACCESSKEY}#admin#g" /data/app/minio/scripts/minio
sed -i "s#\${CW_MINIO_SECRETKEY}#minio#g" /data/app/minio/scripts/minio

mkdir -p /data/app/scripts && ln -s /data/app/minio/scripts/minio /data/app/scripts/minio

2.2 导入旧数据、启动minio

2.2.1 寻找云硬盘数据

由于minio的pod使用的云硬盘存储 而且华为云的云硬盘存储作为pod存储时只能设置为RWO 这就意味着 这块磁盘是非共享的磁盘 只能一个机器上挂载 想要在另外一个机器上挂载这个盘 从而实现新老minio数据的无缝切换变得不现实

好在可以通过minio pod所在主机找到挂载的盘，即使是给pod使用的云硬盘也是挂载在宿主机上的，通过如下命令确定好了minio使用的云硬盘在宿主机的挂在位置

[root@node3 ~]# df -h | grep sd
/dev/sda                       9.8G  5.3G  4.5G  55% /mnt/paas/kubernetes/kubelet/plugins/kubernetes.io/csi/pv/pvc-a717493c-d758-411d-a4c9-8f0afe9a7d3d/globalmount
[root@node3 ~]# ls /mnt/paas/kubernetes/kubelet/plugins/kubernetes.io/csi/pv/pvc-a717493c-d758-411d-a4c9-8f0afe9a7d3d/globalmount
lost+found  minio
[root@node3 ~]#

2.2.2 同步历史数据、启动服务

在另外一个主机上已经安装好了minio，使用sersync将云硬盘的minio目录同步到目标主机 并启动新的minio

chown -R cloudwise:cloudwise /data/app/minio /data/appData/minio /data/logs/minio
bash /data/app/minio/scripts/minio start

2.2.3 确认更新时间

因为白天saas客户一直在使用平台，重启服务的过程大概几分钟，这个过程如果客户上传图片，图片要么上传到新的minio上要么上传到老的minio上，要么上传失败，图片不会丢，但是如果上传失败，会影响客户使用saas平台的满意度，所以不能在白天进行新老minio的切换。

考虑到目前正式客户使用的产品有知识库和ITSM，所以选择凌晨2点进行变更，减少对客户的影响，并优先验证这两个产品是否可以正常使用对象存储。

3 变更操作

3.1 关闭sersync

因为sersync是从旧的minio同步数据到新的minio的 而且在rsync的过程中有–delete项 如果忘记关闭rsync 切换了之后客户往新的minio传入数据 老的sersync发现新的minio有新的数据会进行delete删除操作 这不是我们想要的

3.2 更改nacos配置

更改commons配置 Data Id: commons.properties

原来的: minioServers=http://svc-minio:18125

修改为: minioServers=http://172.16.0.101:18125

3.3 更改tengine配置

更改tengine配置 cm-tengine

原来的:
    upstream minioServers {
        server svc-minio:18125 weight=1;
        # check interval=3000 rise=2 fall=5 timeout=1000 type=tcp;
    }
    
修改为:
    upstream minioServers {
        server 172.16.0.101:18125 weight=1;
        # check interval=3000 rise=2 fall=5 timeout=1000 type=tcp;
    }

3.4 重启服务

删除minio的svc

重启服务后 后端服务就会获取到最新的minio地址 为了防止老的minio地址的影响 删除老的minio的svc 老的minio就无法访问了

这样确保如果可以上传成功图片 就是用的新的minio

重启服务

服务器上依次重启tengine/dosmserver/dokbserver/wisebotserver/middlewareserver

k8s命令不再赘述

4 验证minio功能

更新后验证ITSM/知识库/云小慧/服务台 是否可以正常使用minio 验证两个方面

• 之前的图片是否可以正常看到
• 是否可以新创建任务 并在新创建任务中成功上传图片

如果 ITSM/知识库/云小慧/服务台 都通过了上述两方面的验证 就可以认为新的minio切换成功

5 更改维护手册信息

将维护手册中minio的信息进行变更 包括

• minio的访问方式、账号密码
• 服务分布

6 清理容器化minio资源

容器化minio需要清理的资源有

• sts
• nodePort类型的service
• 云硬盘存储

这个暂时不足清理 定个任务提醒 再上线两次后 平台无任何问题再进行清理

7 监控和自动拉起补充

对minio服务 补充服务监控 并增加服务自动拉起的逻辑