金山云迁移记录

公司用了aws、阿里云、金山云。金山云要迁移机房，所以需要我们把云主机从北京3区迁移到6区，是的让客户把自己的云主机从一个区迁移到另一个区。。。。。。

然后与金山商务长达一个余月的沟通，忽悠加扯皮，最终定下了一个日期进行迁移：由金山云技术从底层进行操作，从一个区迁移到另一个区，然后当前区主机不可见，新区挂载可见。

然而迁移过程中，也算是对金山云进行了异常功能测试，越测试越感觉有点打酱油。。。。。。。。。。

整个迁移过程，就是一场从一个坑爬出，然后再跳进另一个坑的过程，大体总结如下：

1、关机，然后金山技术从底层进行磁盘热数据归档合并，结果第一次合并完毕热数据后，打开主机，里面服务的xml配置文件乱码，直接变成二进制文件，导致服务各种无法启动——整个环节最最折磨人的地方。最终由恍然所悟的金山技术主动要求重传，问题得以解决。

2、金山云主机迁移完毕后，安全组规则发生改变——把过往添加又删除的安全规则，全部给加载还原出来。只能硬着头皮手工一个个的核对删除。

3、由于迁移的jenkins  master主机 在金山，jenkins slave 一部分在金山，一部分在aws的中国区和美国区，导致各种调试和配置安全组。

4、由于迁移过程中主机开机顺序不同，导致nfs共享磁盘无法自动挂载，最终手工挂载。

5、中美两台hubot机器人无法正常访问jenkins-cli，jenkins-cli客户端一直在报错。导致hubot机器人无法正常执行任务。。。。。。。。。。

java.io.EOFException
        at java.io.DataInputStream.readBoolean(DataInputStream.java:244)
        at hudson.cli.Connection.readBoolean(Connection.java:95)
        at hudson.cli.CLI.authenticate(CLI.java:567)
        at hudson.cli.CLI._main(CLI.java:478)
        at hudson.cli.CLI.main(CLI.java:384)

而jenkins master 也一直在报当前活动目录没有此用户的错误，但是通过指定用户和密码也无法正常build 任务

java -jar jenkins-cli.jar -s https://jenkins_url/ login --username username --password password build job_name

由于jenkins 使用了ldap 的安全矩阵，起初一直把思路盯在 ldap 和 安全矩阵上，结果最后发现了jenkins用户的公钥配置——专门为jenkins cli而设。。。。。这不是 github的用法嘛。。。。。

 

 

转载于:https://www.cnblogs.com/husbandmen/p/7066454.html