SuperMap iManager 云套件 nfs 数据迁移一、停止云套件服务二、数据拷贝三、云套件 pv 和 pvc 文件导出3.1 导出pvc3.2 导出pv四、修改 pv 内容4.1 单个pv处理4.1.1 导出pv4.1.2 删除 pv4.1.3 修改pv4.1.4 运行 pv4.15 查看pv状态4.2批量pv处理不建议4.2.1 批量解除 pv 与 pvc 绑定关系4.2.2 批量删除pv4.2.3 修改giscloud-pv.yaml文件4.2.4 apply giscloud-pv.yaml五、云套件服务恢复5.1 恢复deploy资源的副本数5.2 恢复statefulset资源的副本数六、可能遇到的问题6.1 keycloak-database起不来日志报错如下截图不少项目习惯把NFS直接跑在K8s节点上。遇到机器回收或调整持久化一断iManager云套件服务就起不来了。这种情况数据怎么搬老办法通常是备份环境、建新站点、拷数据再还原。其实还有条不用重新创建新站点的方式直接改PV。操作虽多点但不用动整个站点。核心就四步停服务→拷数据→改PV→恢复。下面咱们一步步拆解实操。一、停止云套件服务再停止服务之前建议先执行云套件的备份功进行云套件备份。导出 deployment / statefulset 资源# 导出云套件命名空间(icloud-native-31)的deployment资源状态方便后续恢复的时候进行调整 kubectl get deployment -n icloud-native-31 giscloud-deployment-status.txt # 导出 icloud-native-31 statefulset方便后续恢复的时候进行调整 kubectl get statefulset -n icloud-native-31 giscloud-statefulset-status.txt将 deployment / statefulset 资源副本数置0# 将云套件命名空间(icloud-native-31)的deployment 资源的副本伸缩成0 kubectl get deployment -n icloud-native-31 | awk NR1{print $1} | xargs kubectl scale deployment -n icloud-native-31 --replicas0 # 将云套件命名空间(icloud-native-31)的statefulset 资源的副本伸缩成0 kubectl get statefulset -n icloud-native-31 | awk NR1{print $1} | xargs kubectl scale statefulset -n icloud-native-31 --replicas0二、数据拷贝新nfs服务器创建旧nfs挂载目录并将旧nfs mount到该目录上# nfs文件拷贝原nfs共享mount目录/data/nfs_data/117新nfs共享目录/data/nfs_data/iMananger_v1210_117 cp -rf /data/nfs_data/117/* /data/nfs_data/iMananger_v1210_117/ # 若只是对云套件的持久化数据进行迁移本地云套件的命名空间是“icloud-native-31”故需要拷贝nfs中icloud-native-31开头的目录 cp -rf /data/nfs_data/117/icloud-native-31-* /data/nfs_data/iMananger_v1210_117/拷贝之后可以对nfs持久化数据一个777 的权限防止数据读取不到或者写入不进去三、云套件 pv 和 pvc 文件导出导出云套件的pv和pvc yaml文件主要是用于备份任何操作前建议都需要进行备份。3.1 导出pvc# 云套件命名空间icloud-native-31存储类名称appset-storage-class-gisappset kubectl get pvc -n icloud-native-31 | grep appset-storage-class-gisappset | awk {print $1} | xargs kubectl get pvc -n icloud-native-31 -o yaml giscloud-pvc.yaml3.2 导出pv# 云套件命名空间icloud-native-31存储类名称appset-storage-class-gisappset kubectl get pv | grep appset-storage-class-gisappset | awk {print $1} | xargs kubectl get pv -o yaml giscloud-pv.yaml四、修改 pv 内容对于不熟悉k8s人员建议一个一个的对pv进行修改和删除操作不建议进行批量操作若遇到问题进行处理时就容易慌神且任何操作修改删除操作前均要进行备份操作4.1 单个pv处理4.1.1 导出pv# 导出名为“pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c“的pv编排 kubectl get pv pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c -o yaml pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c.yaml4.1.2 删除 pvkubectl delete -f pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c.yaml # 如果删不到可能就是pvc绑定的缘故需要先清除 claimRef 解除绑定关系在进行删除 kubectl patch pv pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c -p {spec:{claimRef:null}}4.1.3 修改pv修改前修改后4.1.4 运行 pv# 运行修改后的pv kubectl apply -f pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c.yaml4.15 查看pv状态# 查看pv情况 kubectl get pv | grep pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c # 查看pv内容按照yaml格式输出 kubectl get pv pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c -o yaml4.2批量pv处理不建议对于不熟悉的k8s操作人员建议一个一个pv的进行处理这样更加安全4.2.1 批量解除 pv 与 pvc 绑定关系批量解除之前建议先对进行留痕然后在进行清除pv 和 pvc的绑定。# 将存储类名为“ appset-storage-class-gisappset ”的pv名称进行备份 kubectl get pv | grep appset-storage-class-gisappset | awk {print $1} pv-names.txt # 清除 pv与pvc 的绑定关系 cat pv-names.txt |xargs kubectl patch pv -p {spec:{claimRef:null}}解除绑定前解除绑定后4.2.2 批量删除pvcat pv-names.txt | xargs kubectl delete pv # 如果存在pv删除不掉可以重复上一步清除绑定操作。 cat pv-names.txt |xargs kubectl patch pv -p {spec:{claimRef:null}}4.2.3 修改giscloud-pv.yaml文件giscloud-pv.yaml文件就是步骤导出pv的yaml文件内容直接使用通过编辑工具进行批量修改nfs的server 和path4.2.4 apply giscloud-pv.yamlkubectl apply -f giscloud-pv.yaml五、云套件服务恢复5.1 恢复deploy资源的副本数根据第一步导出giscloud-deployment-status.txt进行修改指令# x 为副本数支持写入多个deployment kubectl scale deployment 【deployment名称】 -n icloud-native-31 --replicas【x】5.2 恢复statefulset资源的副本数根据第一步导出giscloud-statefulset-status.txt进行修改指令# x 为副本数支持写入多个statefulset kubectl scale statefulset 【statefulset名称】 -n icloud-native-31 --replicas【x】 # keycloak 和 keycloak-database 副本数均为1合并示例如下 kubectl scale statefulset -n icloud-native-31 --replicas1 cloudsuite-keycloak cloudsuite-keycloak-database六、可能遇到的问题6.1 keycloak-database起不来日志报错如下截图【问题原因】PostgreSQL 出于安全考虑要求数据目录必须由运行数据库的用户Bitnami 镜像中默认是 UID/GID 1001 的postgres用户拥有。如果目录属于root或其他用户启动时会报此错。【解决办法】给keycloak-database持久化目录下的data目录的拥有者改为1001# 需要进入到 keycloak-database的持久化目录中执行下面的操作 chown -R 1001:1001 data
SuperMap iManager 云套件 nfs 数据迁移
SuperMap iManager 云套件 nfs 数据迁移一、停止云套件服务二、数据拷贝三、云套件 pv 和 pvc 文件导出3.1 导出pvc3.2 导出pv四、修改 pv 内容4.1 单个pv处理4.1.1 导出pv4.1.2 删除 pv4.1.3 修改pv4.1.4 运行 pv4.15 查看pv状态4.2批量pv处理不建议4.2.1 批量解除 pv 与 pvc 绑定关系4.2.2 批量删除pv4.2.3 修改giscloud-pv.yaml文件4.2.4 apply giscloud-pv.yaml五、云套件服务恢复5.1 恢复deploy资源的副本数5.2 恢复statefulset资源的副本数六、可能遇到的问题6.1 keycloak-database起不来日志报错如下截图不少项目习惯把NFS直接跑在K8s节点上。遇到机器回收或调整持久化一断iManager云套件服务就起不来了。这种情况数据怎么搬老办法通常是备份环境、建新站点、拷数据再还原。其实还有条不用重新创建新站点的方式直接改PV。操作虽多点但不用动整个站点。核心就四步停服务→拷数据→改PV→恢复。下面咱们一步步拆解实操。一、停止云套件服务再停止服务之前建议先执行云套件的备份功进行云套件备份。导出 deployment / statefulset 资源# 导出云套件命名空间(icloud-native-31)的deployment资源状态方便后续恢复的时候进行调整 kubectl get deployment -n icloud-native-31 giscloud-deployment-status.txt # 导出 icloud-native-31 statefulset方便后续恢复的时候进行调整 kubectl get statefulset -n icloud-native-31 giscloud-statefulset-status.txt将 deployment / statefulset 资源副本数置0# 将云套件命名空间(icloud-native-31)的deployment 资源的副本伸缩成0 kubectl get deployment -n icloud-native-31 | awk NR1{print $1} | xargs kubectl scale deployment -n icloud-native-31 --replicas0 # 将云套件命名空间(icloud-native-31)的statefulset 资源的副本伸缩成0 kubectl get statefulset -n icloud-native-31 | awk NR1{print $1} | xargs kubectl scale statefulset -n icloud-native-31 --replicas0二、数据拷贝新nfs服务器创建旧nfs挂载目录并将旧nfs mount到该目录上# nfs文件拷贝原nfs共享mount目录/data/nfs_data/117新nfs共享目录/data/nfs_data/iMananger_v1210_117 cp -rf /data/nfs_data/117/* /data/nfs_data/iMananger_v1210_117/ # 若只是对云套件的持久化数据进行迁移本地云套件的命名空间是“icloud-native-31”故需要拷贝nfs中icloud-native-31开头的目录 cp -rf /data/nfs_data/117/icloud-native-31-* /data/nfs_data/iMananger_v1210_117/拷贝之后可以对nfs持久化数据一个777 的权限防止数据读取不到或者写入不进去三、云套件 pv 和 pvc 文件导出导出云套件的pv和pvc yaml文件主要是用于备份任何操作前建议都需要进行备份。3.1 导出pvc# 云套件命名空间icloud-native-31存储类名称appset-storage-class-gisappset kubectl get pvc -n icloud-native-31 | grep appset-storage-class-gisappset | awk {print $1} | xargs kubectl get pvc -n icloud-native-31 -o yaml giscloud-pvc.yaml3.2 导出pv# 云套件命名空间icloud-native-31存储类名称appset-storage-class-gisappset kubectl get pv | grep appset-storage-class-gisappset | awk {print $1} | xargs kubectl get pv -o yaml giscloud-pv.yaml四、修改 pv 内容对于不熟悉k8s人员建议一个一个的对pv进行修改和删除操作不建议进行批量操作若遇到问题进行处理时就容易慌神且任何操作修改删除操作前均要进行备份操作4.1 单个pv处理4.1.1 导出pv# 导出名为“pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c“的pv编排 kubectl get pv pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c -o yaml pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c.yaml4.1.2 删除 pvkubectl delete -f pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c.yaml # 如果删不到可能就是pvc绑定的缘故需要先清除 claimRef 解除绑定关系在进行删除 kubectl patch pv pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c -p {spec:{claimRef:null}}4.1.3 修改pv修改前修改后4.1.4 运行 pv# 运行修改后的pv kubectl apply -f pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c.yaml4.15 查看pv状态# 查看pv情况 kubectl get pv | grep pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c # 查看pv内容按照yaml格式输出 kubectl get pv pvc-fe7d53c4-320c-440f-91bd-2f968eaf6f7c -o yaml4.2批量pv处理不建议对于不熟悉的k8s操作人员建议一个一个pv的进行处理这样更加安全4.2.1 批量解除 pv 与 pvc 绑定关系批量解除之前建议先对进行留痕然后在进行清除pv 和 pvc的绑定。# 将存储类名为“ appset-storage-class-gisappset ”的pv名称进行备份 kubectl get pv | grep appset-storage-class-gisappset | awk {print $1} pv-names.txt # 清除 pv与pvc 的绑定关系 cat pv-names.txt |xargs kubectl patch pv -p {spec:{claimRef:null}}解除绑定前解除绑定后4.2.2 批量删除pvcat pv-names.txt | xargs kubectl delete pv # 如果存在pv删除不掉可以重复上一步清除绑定操作。 cat pv-names.txt |xargs kubectl patch pv -p {spec:{claimRef:null}}4.2.3 修改giscloud-pv.yaml文件giscloud-pv.yaml文件就是步骤导出pv的yaml文件内容直接使用通过编辑工具进行批量修改nfs的server 和path4.2.4 apply giscloud-pv.yamlkubectl apply -f giscloud-pv.yaml五、云套件服务恢复5.1 恢复deploy资源的副本数根据第一步导出giscloud-deployment-status.txt进行修改指令# x 为副本数支持写入多个deployment kubectl scale deployment 【deployment名称】 -n icloud-native-31 --replicas【x】5.2 恢复statefulset资源的副本数根据第一步导出giscloud-statefulset-status.txt进行修改指令# x 为副本数支持写入多个statefulset kubectl scale statefulset 【statefulset名称】 -n icloud-native-31 --replicas【x】 # keycloak 和 keycloak-database 副本数均为1合并示例如下 kubectl scale statefulset -n icloud-native-31 --replicas1 cloudsuite-keycloak cloudsuite-keycloak-database六、可能遇到的问题6.1 keycloak-database起不来日志报错如下截图【问题原因】PostgreSQL 出于安全考虑要求数据目录必须由运行数据库的用户Bitnami 镜像中默认是 UID/GID 1001 的postgres用户拥有。如果目录属于root或其他用户启动时会报此错。【解决办法】给keycloak-database持久化目录下的data目录的拥有者改为1001# 需要进入到 keycloak-database的持久化目录中执行下面的操作 chown -R 1001:1001 data
