上上周码云挂了一次，时间30分钟左右，今天又挂了一次，时间将近30分钟。两次挂机的原因的是一样的。其中两台配置较差的机器在高峰期大量代码的 push 下宕机，每次挂一台机器。让机器重启机器后系统就恢复了。这个过程大概是 20-30 分钟。
为什么会有配置较差的机器呢？
最开始我们在准备码云服务器的时候，老的架构下是分为应用服务器和存储服务器，因此我们采购的应用服务器一般是CPU很强，存储容量较小；而存储服务器的存储容量很大但是CPU只有单颗。
而去年年底我们对整个分布式结构做了大幅度的调整，直接将 Git 仓库拆到不同的机器上，也就是每一台机器既充当存储又充当计算的角色，然后每一台机器只处理一部分的 Git 仓库。
老的那些应用服务器我们已经增加了存储，但是老的存储服务器还是单个 CPU，于是在每天下班之前这段时间内，是码云一天中并发 Push 代码量最高的时期，直接导致这些配置较差的存储服务器宕机。另外一个更为重要的原因是最近两三个月每天 Push 代码的项目数又翻了一倍，因此负载过重。
为什么分布式单个节点宕机会导致整个仓库无法访问？
原因也在这两台配置较差的服务器上，为了降低这两台机器的压力，我们把 HTTP/HTTPS 的请求分发到其他的节点去处理，这样的话后台临时需要通过 NFS 方式访问这两台设备上的 Git 仓库，因此产生了互相影响。
接下来的处理措施
也就是说最近挂机稍显频繁的原因在于机器的处理能力上。我们已经开始采购新的一批服务器，按照高处理性能以及大存储的要求，用来替换这两台设备。完全替换之后再进行老设备的处理性能升级（增加CPU和内存），然后重新加入集群节点中。
这个过程预计前后大约需要1个月左右的时间，在此期间我们会将这两台老设备的 Git 仓库迁移一部分到其他机器上以降低压力。
目前码云集群中除了前端 Web 服务、数据库、缓存、队列等单独服务器之外，共有 8 个节点，总存储容量 80T 左右。
压力很大，全力以赴！