存储规划是企业必须考虑的因素。无限增长的资源不仅需要管理和维护，还需要容灾和备份机制。在存储变化方面，我司很快发现磁盘使用率超标，并启动了数据存储迁移的规划方案1.静态资源架构①实施前的节点架构：res1-res10为10个静态资源节点，data目录位于/data/下有一个2TB的数据盘挂载，32TB的共享存储块通过nfs挂载在/mnt下。数据通过rsync+sersync在/mnt目录同步，32TB共享存储块保持实时状态。②实现后的节点架构：单数res节点为nfs-master，双数res节点为nfs-slave，每两个节点共享一个32T的存储块。2TSSD数据盘依旧是程序目录，之前的静态资源目录/data/webapps/nginx/res/upload/cdn/node*改为新路径/resource_nginx/res/upload/cdn/node*。10个节点还是nfs-slave用于db共享存储，静态资源实时同步2.实现操作①购买5个共享存储块②10个实例每两个实例挂载一个共享存储块，共5块，使用nfs③之前④更改res静态目录，将2T中的静态资源对复制到新的存储块路径中，将node1和node2的静态数据导入到新的块存储中，将node3和node4的静态数据复制到新的块存储中块存储，将node5和node6的静态数据导入新块存储，每两个节点的数据导入一个新块，以此类推⑤确认新数据同步到5块存储，开始更新变更到新的res路径，在中心配置config项目中将资源项目的目录参数修改为新的res路径⑦每次调整权重为0，重启项目平滑升级，重新加载nginx使新路径生效⑧确认项目输出日志是否异常⑨测试功能上传访问⑩恢复权重，更改fstab，备份块rsync+sersync路径3.问题①8月1日更新后，8月2日的任务是恢复静态资源的备份计划和重新调整rsync+sersync文件的配置。由于运维过程中的疏忽，10个res节点很少更改res6的配置。下面附上需要恢复的普通rsyncd.conf配置文件（比如res1）对于res6当时正常改过的文件和没改过的文件[root@hmf_res1~]#cat/etc/rsyncd.conf#rsync_config_______________start#createdbywang2017-04-1800:08##rsyncd.confstart##uid=rootgid=rootusechroot=nomaxconnections=200timeout=300pidfile=/var/run/rsyncd.pidlock文件=/var/run/rysnc.locklogfile=/var/log/rsyncd.logignoreerrorsreadonly=falselist=falsehostsallow=127.0.0.1/8#hostsdeny=0.0.0.0/32#authusers=rsync_backup#secretsfile=/etc/rsync.password[node1]path=/mnt/node1[node2]path=/mnt/node2[node3]path=/mnt/node3[node4]path=/mnt/node4[node5]path=/mnt/node5[node6]path=/mnt/node6[node7]path=/mnt/node7[node8]path=/mnt/node8[node9]path=/mnt/node9[node10]path=/mnt/node10config.xml正常sersync中需要恢复的配置文件[root@hmf_res1~]#cat/data/server/sersync/config/config.xml<插件名称="refreshCDN"></head>当时res6中的rsyncd.conf配置文件没有改动，也就是规划项目之前的配置[root@hmf_res6~]#cat/etc/rsyncd.conf#rsync_config_______________start#createdbywang2017-04-1800:08##rsyncd.confstart##uid=rootgid=rootusechroot=nomaxconnections=200timeout=300pidfile=/var/run/rsyncd.pidlockfile=/var/run/rysnc.locklogfile=/var/日志/rsyncd。logignoreerrorsreadonly=falselist=falsehostsallow=127.0.0.1/8#hostsdeny=0.0.0.0/32#authusers=rsync_backup#secretsfile=/etc/rsync.password[node1]path=/mnt/node1[node2]path=/mnt/node2[node3]path=/mnt/node3[node4]path=/mnt/node4[node5]path=/mnt/node5[node6]path=/mnt/node6[node7]path=/mnt/node7[node8]path=/mnt/node8[node9]path=/mnt/node9[node10]path=/mnt/node10[resource]#这里配置不删，继续在新块同步path=/resource_nginx/res/upload/cdn/node6没有更改res6中的sersyncconfig.xml配置文件[root@hmf_res6~]#cat/data/server/sersync/config/config.xml#这里没有改成新的存放路径，一直监听原来的2T路径，只是这个路径不再写到数据<插件nname="command">②根据sersync同步的默认规则，，这个参数是监听源服务器目录位置，如果源服务器目录下没有文件，会执行删除，同步一些文件，保持文件处于相同状态。这是致命的导火索。③8月7日后一周，未发现异常。但是这段时间res6节点没有新上传的文件内容，因为新路径一直在监听老路径目录，老路径肯定没有新文件，res6会删除上传的新文件。它将在收到后被删除，遵循规则。这个时候res6中已经有大量的404，静态资源访问状态码的监控不到位。④这天刚拿到删除旧路径数据的权限。运维过程中，使用rm命令删除旧数据rm-rf/data/webapps/nginx/res/cdn/upload/node1/*rm-rf/data/webapps/nginx/res/cdn/upload/node2/*rm-rf/data/webapps/nginx/res/cdn/upload/node3/*rm-rf/data/webapps/nginx/res/cdn/upload/node4/*rm-rf/data/webapps/nginx/res/cdn/upload/node5/*rm-rf/data/webapps/nginx/res/cdn/upload/node6/*rm-rf/data/webapps/nginx/res/cdn/upload/node7/*rm-rf/data/webapps/nginx/res/cdn/upload/node8/*rm-rf/data/webapps/nginx/res/cdn/upload/node9/*rm-rf/data/webapps/nginx/res/cdn/upload/node10/*8月8日，发生意外，res6节点静态资源访问出现大量404状态码。第一时间查看访问日志，发现从旧数据删除后，404逐渐上报，7号半夜404全部上报。意识到数据有问题，发现新的块存储中的数据不存在/resource_nginx/res/cdn/upload/node6/，准备恢复备份，发现备份的数据没有了存在/mnt/node6/因为sersync监控路径/data/webapps/nginx/res/cdn/upload/node6/同步到目标服务器的两个路径/resource_nginx/res/cdn/upload/node6,/mnt/node64.解决问题①第一个问题的解决：在运维过程中，如果出现配置缺失或者配置错误的问题，那肯定是自动化统一运维没有做好。后续架构运维中，使用saltstack，设置主机组，实现统一cmd，统一分发文件，监控节点组：hmf_res10'salt-N'hmf_res'cmd.run'command'#指定组统一管理②解决问题2：在生产环境中，如果不刻意要求源服务器和目标服务器的文件一致性，请确定关闭这个默认项，更改sersync主配置文件③问题三的解决方法：加强和完善监控服务器上的监控脚本，优化大量404、500、502状态码.跟不上变化，无限增加的资源一定不能受制于成本。请谨慎使用rm命令。使用时请注意可能带来的后果
