为了账号安全,请及时绑定邮箱和手机立即绑定

【悲催】机房跑路,服务迁移之路

起因

        最近总是遇到悲催的事情,这次的事情更悲催,某机房提供服务供应商跑路了,早上10点多通知 晚上6点断电,我X你的仙人板板。抱怨归抱怨,但是烂屁股的事情还得擦。 没办法只能换机房了,幸好早都勾搭上了一家高防供应商。但是迁移也是一个麻烦事情。

https://img1.sycdn.imooc.com/5f4bc7f10001a78007600202.jpg

https://img1.sycdn.imooc.com/5f4bc7f000015e8703000236.jpg

https://img4.sycdn.imooc.com/5f4bc7f10001300a02790177.jpg

窘境

需要备份的文件过大

        目前这边公司的主要提供广告服务,所有各种图片,静态页面比较多,图片总共差不多80G(分别是30G、50G 两个文件夹)


https://img1.sycdn.imooc.com/5f4bc8100001142e08640514.jpg

https://img3.sycdn.imooc.com/5f4bc81000019e8814000467.jpg

待迁移的服务器过多

    大概负责3个公司,高防机器总共5台。在相对差不多8个小时(其实不到6个小时,因为整理好这些机器的业务之后差不多12点了)要处理好这些迁移事情,时间总体来说肯定是不够的。

Nginx配置太混乱

    nginx的配置完全是没有章法,没有规范能操作能看就行,这就是以前的毫无规范的带来的技术债。有很多用泛解析,用default_server导致不知道有哪些域名解析上来了

服务器环境不一致

    服务器软件的安装手法应该是经历了好几位前任的规划,导致手法完全不一致

https://img2.sycdn.imooc.com/5f4bc830000140ed14000104.jpg

https://img4.sycdn.imooc.com/5f4bc8300001e71f14000290.jpg

特定业务域名过多

    有的业务域名加起来估计都得有6000多个,其实本身多没什么事情。但是 高防机房都要对域名加百名单,这么多域名就是加完估计都得一个星期(也许大家觉得很简单,但是这里面的事情比较复杂,我觉得机房没把事情服务做好导致慢的原因)

针对方案

需要备份的文件过大

    这个实在没办法,只能备份,担心同步不及时,丢数据,全部都在本地备份一份,以防万一。技巧:对于大文件、大文件夹 要使用分卷压缩(例如一个卷一个G)尽量同步更多文件回来进行备份,降低损失

待迁移的服务器过多

    这个没什么好办法,一个人不够,就加人,我比较尴尬的场面是组内熟悉linux的并不多,所以只能让熟悉业务的整理nginx配置和代码,我进行环境初始化

Nginx配置太混乱

    这个就没什么好办法,加人过来整理成我规范好的nginx配置就好了。在规定的文件夹放规定的东西就行了,加人安排做就行了

    https://img4.sycdn.imooc.com/5f4bc8580001839403910154.jpg

服务器环境不一致

    这个我只能自夸我习惯好,我个人非常不喜欢重复性劳动,所以用fabric写了脚本。这样就可以快速执行服务器的软件环境初始化 并达到一致性的结果。好处:5台服务器,从12点20拿到服务器,整体安装完不到30分钟就搞定了

  

https://img3.sycdn.imooc.com/5f4bc883000118ca11340658.jpg

https://img3.sycdn.imooc.com/5f4bc8830001351c12950697.jpg

https://img3.sycdn.imooc.com/5f4bc8830001fd2607850606.jpg

特定业务域名过多

    这个主要是机房加白非常耗时间,从我们整理出来到机房添加成功时间是完全不够的,所以当时我们的想法是先将重要业务线加白,加白一个业务就迁移一个业务。其中有2个业务 域名比较少,业务相对来说也简单很多,所以规划先迁移。这里面的诟病就是 机房加白名单有几个烦人的地方(我不知道其他家,我说的是我这家的情况)

    1:重复的提交过去在家会非常慢

    2:要在工信部网站查看是否备案过,工信部的网站估计做的查询很慢大家应该用过的都知道

基于如上情况,当下午4点左右才把2个简单的业务迁移完成。然后这个时候50G的图片备份还没有完成,30G的图片已经完成了,看样子预计到6点都不太可能备份完成。只能继续其他3个业务的迁移。遇到如下图的问题

https://img2.sycdn.imooc.com/5f4bc8a20001b46212921042.jpg

域名太多,加白肯定来不及了,我赶紧给新的供应商打电话,看看有没有什么新的方案可以先保证业务可以访问。简单电话之后,发现可以用如下方案解决

https://img4.sycdn.imooc.com/5f4bc8bd0001e9c114000698.jpg

如上图,由于 proxy 不需要加白,只要域名备案了都可以,这样我们就可以先保证业务线使用, 这里其实大家也明白,上面规划的nginx目录有 vhosts_proxy 就可以解释了

零碎问题解决方案

域名怎么解析好维护

    我们是按照业务区分,每个业务有一个单独的cname域名,所有需要绑定这个业务的全部都cname到 改域名,然后改域名在解析对应IP,这是我们整理之后部分这样修改了(还有一部分下周还要继续整理)。这样以后在换服务器,只用改cname域名的解析ip就好了

Nginx:could not build optimal server_names_hash

    这次错误就是有的服务域名过多导致的,所以要在http 段增加两个参数

https://img3.sycdn.imooc.com/5f4bc8d70001231f14000133.jpg

https://img4.sycdn.imooc.com/5f4bc8d7000102bb14000361.jpg

server_names_hash_max_size 4000;
server_names_hash_bucket_size 128;

这个数字大家情况设置,我就是慢慢试,1000不行,设置2000,2000不行就3000 ,直到行了就可以

发布系统遇到的问题

    proxy服务器不知道为什么发布就是不成功,有一个报错 如下,其实解决很简单,就是讲  /etc/sudoers 中的  “Default requiretty” 注释掉

sudo 问题:sorry, you must have a tty to run sudo

我们的发布系统很简单,但是作用对我们来说还是很大的替我们减负,提高了效率,给大家看看截图 ,可以发布代码。可以对nginx等服务进行重启操作

https://img3.sycdn.imooc.com/5f4bc9030001160614000380.jpg

https://img3.sycdn.imooc.com/5f4bc90300018d9d14000418.jpg

https://img4.sycdn.imooc.com/5f4bc9030001fb1c14000420.jpg

感谢团队

为了保证服务的正常提供,整个技术团队通宵了,感谢有他们的支持,让我们越战越成熟

https://img4.sycdn.imooc.com/5f4bc92a0001eefe14001050.jpg

--------------------------------------------------------------------------------

点击查看更多内容
1人点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
全栈工程师
手记
粉丝
1.8万
获赞与收藏
849

关注作者,订阅最新文章

阅读免费教程

感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消