eric107008

之前在学校里帮忙运维了一下实验室的 GPU 集群，个人感受下基于容器的云方案的好处在于能够应付不懂操作的小白在未经良好培训的情况下瞎操作搞垮整个集群的问题。主要是学校里应付的人多而且你永远想不到一个“精通深度学习算法却不知道什么是栈”的博士生会从哪里给你问来类似“卸载 CUDA 只需要 sudo rm -rf /*" 之类的操作（因为真的遇到过有个博二的同门从一个群里问来这个操作，你不给 root 权限就等着天天被人发 teams 要密码）。总的来说其实是一个 Tradeoff ，毕竟 k8s 之类的其实是从云服务衍生出来的技术，为的是资源池化并且 expecting 类似 web 服务这种跑起来不关机的业务，所以也对 jupyter 之类的调试场景支持得更好一些。slurm 则是为超算之类的场景考虑的，expecting 那种一个脚本跑完拉到的业务，调试的话不是没有方案，但还是需要各种 hack 实现一些节点调度之类的问题。我的办法是，集群上先跑一个私有云（啥技术栈都无所谓，PVE ，VMWare, Microcloud 甚至 Hyper-V ），然后根据负载分成两部分，一部分用来跑 slurm 跑大任务，一部分用来跑（我们当时用的 lxd ）调试容器。白天调试的人多就多分点资源给容器，晚上没人上班就把容器冻结起来把资源分给 slurm 跑 Job 。最主要的还是做好人员培训，写个完善点的文档让每个人知道一点 linux 知识。你永远想不到草台班子会给你的集群带来什么样的惊吓，只能通过限制权限（提交 job 的方式非常单一，配环境要好好写配置文件）+织好安全网（调试只能用容器/虚拟机并且准备好一些常用的基础镜像）做好管理。

存储方面，自己并不是专家，只能用点 minio 这种勉强维持生活，听听社区里其他高手们的建议吧。

自上次讨论以来，结合最近一段时间的探索、配置和尝试，获得了一些阶段性的成果和结论，在此与大家分享。

首先，非常感谢 @iBugOne 提供的富有深度的见解，感谢铜币已经送上。如果大家觉得某个帖子的内容对你有所帮助，在收藏之余也还请同样点个感谢或者稍作回复 [对，也是来骗铜币的] 。

**目前的方案**
1. 4 个 HDD 单独组成了一个 RAID-Z2 ZFS 存储池，服务于备份、非性能敏感的长期温-冷数据存储。
2. 2xSSD+2xHDD 各自 RAID1 后，以 SSD 为 cache 组成了 LVM 。通过一些参数配置，使得尽可能更多的随机读写全部由 SSD 承接。
3. 在应用上，搭建了两套应用软件，包括一些数据库、少量的虚拟机磁盘、数据处理平台和其他性能相对敏感的应用被放在了 LVM 中，而 ZFS 作为数据仓库和备份的同时也承担了一些非性能敏感的大容量存储挂载。另外还有一系列的脚本和 cron 实现了包括监控、快照、备份等自动化维护。

**目前的方案带来的一些效果**
经过了一些简单的测试和近段时间的使用体验来看，基本达到了如下效果：
LVM 上：
1. 对于跑模型训练时的数据集这样的典型需求，大部分的读写可以跑满性能瓶颈。具体来说，小文件的随机读写可以在万兆局域网内跑出大约 500M/s 的速度，这基本是这两块 SSD 的随机读写性能的平均水平。大文件的顺序读写可以在万兆局域网内达到 6G+/s ，这也基本达到了 SSD 的性能极限。
2. 以上性能的前提是，数据集是在最近刚刚经过预处理而写进 LVM 的，这意味着使用场景符合 LVM“最近写入的数据往往会在短时间内被读取”这一假设。
在 ZFS 上：
大部分情况下多线程的综合读写（顺序+随机混合）最高可以达到 1.7G/s 左右，这也在纯 HDD 组合成的 RAID-Z2 阵列下的合理范围。

**一些补充结论**
1. 这台 NAS 与 iBug 非常熟悉的镜像站的使用场景有比较大的差别，主要在于读写数据的方式和频率不同。尽管依然存在文件大小带来的随机读写或顺序读写的区别，但这台 NAS 服务的对象并不是来自五湖四海访问镜像站的开发者们，而是几个确定的工作站并且有规划地进行数据的读写。这意味着读写由于相对有计划并其数据形式可预测，进而可以提前规划数据的流向，把需要 SSD 承接的部分尽可能让 SSD 承担，同时有计划地将“降温”的数据打包（从而将许多小文件变成一个大文件）落盘到更适合顺序读写的存储中。在这样的使用场景下，LVM+SSD Cache 依然可以通过一定的配置带来相当不错的收益。
2. LVM 本身的设计缺陷依然存在并且依然需要一些 tradeoff 。比如来自 UTSC 的同学们踩坑踩出来的 chunk size 和 blocks 数量等配置问题，以及脏块迁移问题。或许对于不同的场景，依然需要更加灵活、现代、先进的缓存适应和管理技术。在经过了一些调研后逐渐发现缓存和存储系统的优化一直是也将在很长时间内依然是学术界和工业界深入研讨的问题。在此向许多在这一领域辛勤探索的先驱者们致敬。
3. 一些方案的优点并不是绝对的，而是在某个特定的场景下，某种特定的需求中才会被体现出来。例如 iBug 倾情推荐的纯 ZFS 方案，本身是一个非常优秀的方案。我在配置和使用过程中也深刻体会到了这个方案本身的先进性。但不得不承认，这个方案对于镜像站这样一个内存充足、读取远大于写入的特殊场景下过于适应，以至于人们容易忘记在一些限制，例如空间、内存、经费有限的场景下，这个方案的优势可能难以发挥出来。一些人引以为豪的好主意，在忽略了讨论问题的背景和题设的情况下，这样的答案也没什么建设性。总的来说，还是要根据自己需求和一定的知识储备，选择适合自己的方案。

非常感谢所有参与讨论的朋友们，愿大家合家欢咯，万事如意~

@iBugOne 昨天还在拜读 [201.ustclug]( https://201.ustclug.org) 中关于 ZFS 和 LVM 相关文章，在这儿遇见 iBug 本尊有种教科书里的人物跑到了现实中的既视感，非常亦可赛艇 [鞠躬]

我确实深入考虑了你说的全 HDD ZFS 方案，也研读过 UTSC 镜像站相关的许多内容（如前面提到的 201 ）。目前来说仍然在进行思想斗争主要是这台 NAS 的使用场景与镜像站有着较大不同。我看到镜像站相关的很多文章讨论的是“读取的时候尽可能减小存储设备负担”的问题，因为镜像站的使用场景似乎是“少量且确定的写”（镜像站通常会有计划地进行同步）+“大量且随机的读”（没人知道哪个 PCDN 什么时候开始刷流），这时候 ZFS 针对读操作的优化就显得非常有用。同时，镜像站使用的是内存更大，CPU 性能更强的专业服务器硬件，有充足的内存资源支持 ZFS 的 ARC 缓存。在镜像站的使用场景下，ARC 的作用被非常充分地发挥了出来。相比之下，这台 NAS 面向的场景是日常工作过程中的数据存储。通常的使用场景是，为了某个明天打算跑训练的模型，把某个数据集下载下来，稍微做一些预处理，训练的时候写个 data loader 从 NAS 上读取数据。其通常会面对的是支持大量耗时且高 IO 的数据处理过程中工作站上的 SSD 装不下那么多数据的问题。

从这个角度来说，最理想的情况是，某种我不知道的东西可以“预约”SSD ，同时让 NAS 自己异步地在 SSD 和 HDD 之间 migration 。比如我即将要跑个数据处理，大量的中间数据和结果会通过网络写到 NAS 的 SSD 上，然后 NAS 自己在后台吭哧吭哧把这些数据慢慢挪到 HDD 里的同时，我处理完数据要跑模型训练的时候可以继续用 SSD 上处理好的数据集。等到我用完了这些数据，这些数据还会在 HDD 上好好呆着当作收藏(bushi)，或是下次用的时候再或是慢慢从 HDD 读取或是“预约”一下挪到 SSD 上。倒不是因为 ZFS 或 LVM 好还是不好，而是纯粹地这台 NAS 它既是一个用于存储冷数据的 NAS ，又是半个工作站的外置硬盘。

不过显然这有些既要又要了。所以 ZFS 依然是我非常认真考虑的选择。

个人认为，大家一直说的 Raid 不是备份，只解决可用性不解决可靠性之类的说法，通常是在更广义或者更严格的“可靠性”语境下提出的。对于个人和家用的 NAS ，RAID 实际上可以提升一些使用体验，降低一些心智负担。特别是，实际上个人和家用环境并不会有企业环境那么大量的硬盘和数据，同时自己用的东西对成本也会比企业更敏感，结合好校验以及备份，数据丢失的风险实际上可以在家用 NAS 上降低到一个可以容忍的程度。如果个位数的硬盘组个 RAID1 ，绝大部分情况下可以做到“换块硬盘就能继续用”的效果的。

只依赖 RAID 确实并不能避免所有可能导致数据丢失的风险，比如多盘同时故障，人为或程序误操作（比如软件层误删除或勒索病毒），文件系统/RAID 系统的元数据丢失或出错导致的恢复失败等等。对于这些情况，RAID 并不会给你“后悔药”。但在“一块硬盘坏了”的情况下，我希望能够做到“换块硬盘就能用”，那么 RAID 还是可以提升一些可靠性的。毕竟相比起没有冗余没有备份的大多数非专业用户的使用情况，如果他们遇到“一块硬盘坏了”的情况，大概率是所有数据全丢。从这个角度看，RAID 确实帮我提升了一些可靠性。

RAID 最初设计的主要目标之一确实是为了减少硬盘故障对系统带来的停机时间，提高整体存储的吞吐、可用性以及对单盘故障的容忍度。站在运维或服务连续性的角度，RAID 更常被提到的是“系统还能不能继续运行”这就是可用性的范畴。因此，如果单纯从“某块硬盘坏了之后还能不能快速、无痛地继续工作、并且重建数据”来看，RAID 确实能让你在硬件层面做到数据不丢失、系统不中断，也就是具备“提升部分可靠性+可用性”的作用。但如果放到“所有可能导致数据出问题的场景”这个更大范畴下，RAID 只是众多保护机制中的一环，做不到“全方位无死角”的数据可靠。

结合我自己的使用策略来看，RAID 对提升“数据可靠性”是有帮助的至少能抵御一定数量的硬盘物理损坏，让你“坏盘不丢数据”。数据本身的安全性当然是需要备份，容灾，校验等多层次的保护手段来实现的，良好的数据管理习惯才是确保数据不丢。

我刚刚也在 NAS 的话题下提了个关于存储规划方案的帖子，在我目前的方案中，除了备份以外，我也打算用 RAID1 来降低我维护的心智和体力负担。如果一个硬盘坏了，我可以以一个还不错的概率赌一把我换块硬盘就能继续用且不会丢数据。如果真的阵列恢复失败，那我就把备份恢复回来，毕竟问题比“换块硬盘就能用”还严重了的话，多花点力气似乎也是理所应当的事情。

不知道 OP 是什么专业，如果是纯计算机专业的话，可能还需要有一些技术上的创新点。但对于其他的可以考虑一些技术之外的因素（例如市场，道德，隐私）的专业，比如数媒或者信息管理，网盘（如 @Selenium39 所言，“基于云平台的文件管理系统”）还是可以做个毕设的，主要是需要把话说得好听一些。

立意点（意义）可以从人们对数据隐私的重视和目前环境下对数据隐私的担忧考虑。我之前遇到一个学生拿网盘作为毕设，也是说因为目前市面上的网盘也好 NAS 也罢，难以同时满足易用+可控。虽说百度网盘谷歌网盘之类的产品功能丰富设计精良（其实百度之流也并不精良），但终归是把自己的东西放在别人那里。仔细看看百度的用户协议可以发现基本上传上去的东西就是百度的了。而自部署(self-hosted)的一些选择也各有缺点，例如 Nextcloud 的单点架构设计不利于横向拓展之类的，你还可以对比一下 Seafile 和 Cloudreve 之类的产品. 商业 NAS 虽然数据存储在用户本地但软件上也并不能完全令人放心，毕竟没人知道不开源的 NAS 系统（例如群晖）会不会偷偷夹带什么私货。

总之就是论文的那些套路，别人的东西有哪些缺点，我的东西怎么怎么好之类的。具体实现的话就看自己的能力和喜好，不同的语言不同的方案都可以，还有很多开源方案可以借鉴参考。

总之就是根据学校毕设的评价方式，如果学校看重作品实现就把完成度做高一点，如果学校只看论文那就把论文改漂亮一些，想过并不难。