如何解决 NAS 单点故障还顺便省了 90% 的成本？

背景与痛点

墨刀（modao.cc）是一款在线产品设计及协同工具，目前在全球 150 多个国家，拥有超过140万注册用户，今年新上线的企业版目前已涵盖国内一线互联网公司及众多非互联网上市公司，在国内产品经理和设计师群体拥有良好口碑，超过 90% 新用户来自已有用户引荐。

公司成立 5 年来，在产品功能稳步迭代的同时，技术团队一直保持精简，依靠 JuiceFS 的帮助，在后端及运维团队不到 5 人的情况下支撑起每日近亿次的请求处理。

墨刀的业务系统中需要一个共享文件系统，方便进行文件处理，比如打包、解压、文件合并等。NAS 是使用最普遍的方案之一，但是在 AWS 上还没有提供 NAS 服务，所以墨刀基于 EC2 和 EBS（SSD） 自己搭建了一个 NAS，但有几方面的问题一直困扰他们：

1. NAS 中已有几千万文件，在高负载时 NFS Gateway 会成为瓶颈，需要很多调优工作。
2. NAS 的高可用是双机互备方案，还依赖额外的心跳、状态服务，搭建和维护的成本都不小，权衡之下他们做了一个单机的 NAS，自然也存在单点故障的风险。
3. 随着业务增长需要不断的手动扩容，如果每次扩的多会造成存储成本的浪费，如果扩的少，又需要经常操作，工作量大。
4. 对于整个 NAS 服务，需要对系统状态，每个节点的状态都进行监控，运维复杂度也是蛮高的。

选择 JuiceFS

JuiceFS 是一个在公有云上的全托管式 POSIX 共享文件系统。对比在上文中提到的背景，JuiceFS 具备以下几点优势：

1. 全托管服务，保证 99.95% SLA，省去自己监控、运维、灾难恢复的工作量。
2. 容量弹性伸缩，再也不用做扩容了。
3. 完全兼容 POSIX 接口，不改代码就能完成迁移。
4. 成本下降了 90%。

测试与迁移

测试工作是在 staging 环境完成的，因为 staging 环境可以停机，所以替换工作非常简单，不用修改任何业务代码，只有下面三步：

1. 卸载 NAS；
2. 将 JuiceFS 的文件系统挂载到与 NAS 相同的挂载点；
3. 用 rsync 同步 NAS 中的数据到 JuiceFS 文件系统中。

重启 staging 环境。到此就完成了从 NAS 到 JuiceFS 的迁移。

线上生产环境在不停机的情况下做迁移工作会多一个双写步骤：

1. 修改业务代码，将数据改为双写 NAS 和 JuiceFS，更新上线。此时所有新数据会同时写到 NAS 和 JuiceFS 中（NAS 和 JuiceFS 分别挂载到两个不同的挂载点上）；
2. 将 NAS 中的数据通过 rsync 同步到 JuiceFS 中；
3. 修改业务代码，让数据从 JuiceFS 中读取，更新上线；
4. 观察监控是否有报错，一段时间后修改代码停掉双写，只写 JuiceFS 即可。

到此，在不停机的前提下完成生产环境的迁移工作。

优化

JuiceFS 是分布式文件系统，文件的读写都需要通过网络，为了减少网络开销，JuiceFS 提供本地缓存机制，分为元数据缓存和数据缓存（详细介绍请查看文档中的缓存章节）。

JuiceFS 在挂载时默认启用了 1GB 数据缓存，默认缓存路径为 /var/jfsCache。如果有更多的本地磁盘空间可以使用，建议增加本地数据缓存的大小，同时建议打开元数据缓存。

在挂载时加上参数：

--metacache --cache-dir=CACHE-DIR --cache-size=CACHE-SIZE

总结

JuiceFS 高可用、弹性伸缩、完全兼容 POSIX 这三个特性就是替代自己维护 NAS 产品的理想选择。有些同学会问，一些公有云自己也提供了 NAS 产品，为什么还要选择第三方呢？原因有这样几个：

1. JuiceFS 具有更好的 POSIX 兼容性（我们正在准备一篇详细介绍兼容性差异的文章，稍后放出）；
2. JuiceFS 支持所有公有云，并提供了传输和存储加密，可以跨云挂载使用；
3. JuiceFS 有自动向其他服务区或云服务商 Replication 功能，轻松实现数据异地容灾。

现在，墨刀不仅用 JuiceFS 替代以前 NAS 的作用，还用 JuiceFS + logrotate 完成了集群日志收集归档（详细方案请查看文档：用 JuiceFS 备份 Nginx 日志）。

更丰富的使用场景教程请见文档中场景案例部分。