HamCQ 站点服务器迁移完成

共码了1052个字
文内使用到的标签:

近期,HamCQ 社区所在的运行服务器临近过期,综合一年以来的运营数据及平台收支情况,本站在 11 月 10 日至 11 月 17 日期间,利用夜间时间段进行了迁移工作,希望能够保障社区的运行状态,为大家提供更长久的服务。

迁移过程中,由于时间有限,且过于专注技术方案的实施,没有提前撰写对应的公告说明,收到了非常多用户的无法访问反馈,恰巧 @BH4ERY 在抖音及 B 站等平台上宣传社区,即便是在夜间 0 点 到 2 点的时间段迁移,也有十几位用户发送邮件、QQ、微信、留言咨询无法访问的情况,彼时虽然睡意朦胧,却给了我极大地鼓舞。

此次硬件迁移情况:

阿里云实例:ecs.s6-c1m2.large(1 台) => ecs.e-c1m1.large (同地域 2 台)
单机配置:2 核 (vCPU) 4 GiB => 2 核 (vCPU) 2 GiB

此次平台迁移大致流程:

1、购买新服务器套餐,尝试同地域挂载磁盘,但由于新套餐硬件续费有要求,旧服务器磁盘有进行过扩容,遂采用后续方案。
2、进行旧服务器磁盘内容清理,由 92% 缩减至 65%,为下一步工作做好铺垫。
3、对旧服务器快照备份,CDN 解析至维护界面,保证无新业务数据流入。
4、使用 SMC 迁移中心,重新制作镜像文件,内网迁移大致花费了 40 分钟完成。
5、购买新服务器套餐,从镜像文件启动,初步完成迁移工作。

原本以为工作到此结束,没想到运行一段时间后,频繁的收到高负载报警,相同的应用程序在旧服务器上运行稳定,且各项占用指标对于新服务器也符合,这时候才意识到阿里云的共享型实例:「不同实例 vCPU 会争抢物理 CPU 资源,并导致高负载时计算性能波动不稳定,有可用性 SLA 保证,但无性能 SLA 保证」,尤其 E 实例所带来的新问题……

于是,便采购了 2 个同地域服务器套餐,简单画了个图。

如下图所示,请求流量由 DCDN 进来后,到达 A 服务器所在的 WAF 层,清洗后转发至 B 服务器的 Nginx 服务。同地域的 2 台服务器,用 VPC 对等连接打通内网环境(免连接费、流量费、带宽无上限,延迟低),A/B 两台服务同时运行 PHP-FPM 进程,但由于 B 服务器运行 MySQL ,需要较多的资源保证,且 A 服务有较多闲置资源,便通过 Nginx 配置负载,将大部分 PHP 处理放置 A 服务器,并开启 Zend-Opcache,其中,通过 NFS 实现了对应入口文件的挂载。

以上是本次迁移工作的大致情况,按照现有指标,进行简单压力测试后,能够应对社区日常及五五节活动流量。

采用如上方案是希望能够兼顾「面包和爱情」,特地记录此次过程,非常欢迎大佬们在评论区提出宝贵的意见和建议~

Prev:
Next:

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注