上一篇《自组NAS折腾（一）》发布至今，已经一月有余，主要介绍了我对NAS的基本诉求，以及硬件选型。在文章的结尾处，我提到，之后会介绍一下系统架构设计及软件选型。怎奈最近一个月，比较忙碌、并无心气把软件这部分完完整整写下来。最近终于可以坐下来安安静静开始写一写这块的内容了。

言归正传，下面我就来介绍一下，在这个硬件平台上，我是如何思考网络、系统架构并对其进行设计的。

1. 虚拟化方案选型

从整体来看，当前自组的这个NAS平台性能并不差，如果直接在这个硬件平台上安装NAS系统的话，可玩性比较差，虽然现在很多成品的NAS系统提供了很多扩展能力，比如，在系统之上安装各种插件实现诸如对象存储、多媒体服务、智能家居服务等；很多NAS系统也提供了虚拟化的能力，可以在系统上安装虚拟机来增加系统的可玩性。但是，这种虚拟化方案相关资料很少，遇到问题没有参照，难以快速解决。另外，在系统设计中有一个原则：一个工具仅用于做一件事儿，解决一类问题，不要将过多功能继承在一个工具中，这样会提高系统的复杂度，增加系统的运维成本，降低可靠性，也并不能充分利用硬件的资源。考虑到这一点，再加上对可玩性的考虑，本次采用虚拟化的方案——在硬件及NAS系统之间安装一个完备支持虚拟化的宿主机，将NAS系统作为虚拟机，运行在虚拟化环境中，未来如果有其他需要，也可以直接在虚拟化环境中创建新的虚拟机，从而实现系统的横向扩展。

目前，现成的虚拟化的解决方案比较多，比如ESXi、Proxmox VE、TrueNAS、unRaid等。其中TrueNAS、unRaid这两个系统，本质是为了NAS而生的，并非专门的虚拟化系统，因此不在本次选型的范围内。对于ESXi和Proxmox VE，我们可以简单对比一下：

考虑到自己有几年Linux系统的使用经验，对系统的操作相对熟悉，也喜欢折腾，因此ProxmoxVE看起来比较适合我。

PS：在选型时，我更偏向于成熟的开源软件，可能是因为可玩性高，能够折腾。

2.宿主机系统安装

这一部分我不打算细说，因为ProxmoxVE的安装教程网上一抓一大把，没有太大细说的必要。当然，提到PVE的安装，就不得不提一点，安装之后，默认的硬盘会主要被分割成两个部分，这两个部分都是基于LVM机制的，方便未来对系统的存储容量进行调整。一部分为“local”，另一部分为“local-lvm”。其中local主要默认存储的是系统的镜像文件，而local-lvm是基于lvm-thin的，主要用于存储虚拟机系统盘等。

在安装好PVE之后，我们默认可以通过“https://{宿主机}:8006/”访问虚拟机管理界面，对宿主机上运行的所有虚拟机进行管理。

当前最新版的PVE主要支持两种虚拟化技术，一种是基于KVM的虚拟机，另一种是基于LXC的容器。关于这两种虚拟化的技术，我不在此多说，网上有太多对这两者对比的文章。

3.虚拟机系统安装与配置

我们在硬件平台上安装PVE后，理论上，我们可以在这个宿主机上安装任意的虚拟机来满足不同的需求。在最初我们搭建这个硬件平台其实就是为了实现文件共享等NAS相关的功能，因此我们首先需要安装NAS系统。

其实作为一个NAS系统，最主要、也最核心的的功能就是文件共享，围绕着文件共享这个功能，其实还衍生出很多其他的需求，比如离线下载、私人网盘、家庭多媒体系统、数据保护、系统监控等等。这每一个功能，其实目前都有各种开源的或者商业的软件，比如，我们可以只用安装一个Linux系统的发行版（Debian、Ubuntu等），在此基础上，为了实现文件共享，我们可以安装Samba；为了实现离线下载，我们可以自己安装Aria2等等，其实各种现成的NAS系统很多也是用的现成的工具。可以发现，这种完全自主选择确实给我们带来了极大的灵活性，可以随意定制，很自由。但是这种也带来了很大的一个问题，就是所有的功能都得自己调配，表面上我们似乎只要像搭积木一样就可以实现任意想要的功能，实际上，随着我们安装的工具越来越多，我们需要花费大量的时间解决权限、防火墙、更新等各种各样的问题，这极大的增大了我们的运维成本。基于以上考虑，我们决定安装一个现成的NAS系统。

目前现成的NAS系统很多，unRaid、TrueNAS、TrueNAS Scale等，由于我们的内存支持ECC，TrueNAS Scale也是基于Linux的，免费，因此最终选择了这个系统。

安装TrueNAS Scale系统如何安装的就在此不细表了。在系统安装完成之后，为了能够更好的发挥硬件的性能（毕竟我们有两个万兆网口、4个6T的企业级硬盘），保证数据传输性能及读写速度，我们打算将其中一个万兆网卡和一个SATA控制器直通给NAS系统，完全由NAS系统控制。为了实现这个功能，需要做以下几件事：

3.1. 开启宿主机IOMMU

进入PVE管理页面，进入PVE的Shell，或者直接利用SSH进入PVE的命令行。使用nano或者vi打开 /etc/default/grub，找到变量 GRUB_CMDLINE_LINUX_DEFAULT 注释掉，如果当前宿主机使用的是Intel的CPU，则将GRUB_CMDLINE_LINUX_DEFAULT 变量改成如下值：

1

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on"

如果宿主机的CPU是AMD，则将GRUB_CMDLINE_LINUX_DEFAULT 变量改成如下值：

1

GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on"

保存编辑的内容。然后在Shell中执行如下命令：

1

update-grub

该命令执行成功之后，重启宿主机。重启完成之后，为了确保IOMMU已经正确打开，我们再次登陆Shell，执行如下命令：

1

dmesg | grep -e DMAR -e IOMMU

如果有输出，则说明IOMMU已经正确打开，否则说明并为正确打开，需要排查问题的原因。

3.2. 检查CPU是否支持VT-D技术

可以拿着当前宿主机的CPU型号，到官网上搜索一下，在技术特性部分即可查看当前CPU是否支持该技术。

3.3 直通指定的硬件

在这一步中，我们就需要正式的将我们指定的硬件设备直通给指定的虚拟机了。
这一步操作非常危险，如果错误地将PVE宿主机启动盘对应的SATA控制器直通给NAS虚拟机，将会导致PVE宿主机无法正常启动，因此，请务必取消虚拟机的开机自动启动，这样即使直通设备搞错了，只要重启一下PVE宿主机即可，因为虚拟机没有设置宿主机开机自动启动，也就不会导致冲突而无法正常开机。
首先，我们登陆PVE宿主机的管理后台，选择我们需要直通的虚拟机，点击硬件标签。然后在页面左上点击添加PCI设备。在弹出的对话框中选择需要直通的设备，并勾选PCI-Express选项，如下图。最后点击OK即可。

这样，我们就把指定一个万兆网卡、插着4个6T硬盘的SATA控制器，直通给了虚拟机。重启TrueNAS Scale虚拟机后，登录TrueNAS Scale管理后台，就可以看到我们直通的一个万兆网卡和4块硬盘了。

特别说明一下，直通之后的PCIe设备是无法再通过PVE宿主机管理的。也就是说，对于网卡这种设备来说，一旦直通，就不能再PVE的管理后台看到流量情况了，因为该设备已经完全被TrueNAS Scale虚拟机接管了。

完成硬件直通之后，我们就可以愉快地在TrueNAS的管理后台中设置存储池、设置网卡IP、打开文件共享服务、安装各种插件来扩展增加我们的NAS系统了。

对于我自己的这个NAS来说，我主要做了以下几个配置：

• 将4块6T硬盘组成了一个磁盘阵列，冗余级别为RAIDZ2；
• 开启了一系列硬盘保护任务：磁盘阵列一致性校验；快速SMART测试；长期SMART测试；关键数据集快照；
• 开启了Samba服务，用于与手机、电脑等设备共享文件；
• 开启了NFS服务，用于与宿主机及各个虚拟机内共享数据及文件，并不对外部系统提供服务；
• 安装了nextcloud私人云盘服务，用于自动共享各种照片、文档；
• 安装了aria2服务，用于离线下载；
• 安装了netdata服务，用于监控NAS虚拟机各项运行指标。

PVE宿主机上除了安装TrueNAS Scale虚拟机外，还安装了以下几个虚拟机：

• Windows系统：作为沙箱，用于临时安装不受信任的Windows专有软件；
• Ubuntu系统：作为编译机，安装了一些工具链，用于编译各种开源软件；
• Home Assistant系统：作为智能家居中枢，用于控制各种智能家居设备（以后有机会会单独介绍Home Assistant的使用）；
• OpenWRT系统：作为旁路由，上面搭建了透明代理及反向代理，用于自由上网及打洞（以后也会单独开一篇博客介绍）。

为了每次在折腾的时候没有后顾之忧，在PVE宿主机管理后台开启了每天定时备份任务，会将全部虚拟机备份一遍，并保存最近5天的备份记录。即使虚拟机折腾挂了，也可以轻松会退到前一个正常时间点。

这个主机整体的系统结构如下图所示：

从上图中，其实可以发现，我们的硬件配置为6C32G，但是PVE上所有的虚拟机总配置已经达到18C36.5G，严重超售。但是PVE宿主机上运行的虚拟机系统中，除了TrueNAS Scale、Home Assistant、OpenWRT需要7*24全天候运行外，其他两个系统并不会长期开机，仅在需要的时候才会开机。此外，实测这三个全天候运行的系统，日常CPU消耗在15%以下，整体内存占用也小于32G。这三个系统也不会有CPU密集型的任务，即便某个虚拟机偶尔CPU密集型的任务运行，也是错峰的，出现多个虚拟机同时执行CPU密集型的任务的概率极小。

最后

本次主要介绍了这个自组NAS系统的软件结构。其实从上面的介绍来看，这个系统已经超越了常规意义上的NAS系统，因为在引入了ProxmoxVE之后，我们不仅可以在上面安装各种NAS体统来实现NAS的相关功能，还可以通过安装其他虚拟机的方式自定义其他功能，因此我个人认为，这已经可以称之为all in one的主机了，也契合我之前希望折腾的愿望。

其实本次还想介绍一下，这个主机以及家里现在的网络结构的，但是限于篇幅，本次就先不讲了，放在下一篇来重点介绍这部分内容。

好了，就这样吧～🤪

最近半个月以来，一直想把最近的所见所闻写出来，但是一直不知道如何下笔，以至于很多情绪的东西郁结于心，难以入眠。刚刚看了昨晚刷屏朋友圈的视频《四月之声》，原本似乎已经被压制到平静的情绪瞬间汹涌起来，于是就随便写写吧。

从小区首次封闭到今天，已经一个多月了。在这段时间里，封控层层升级，从最开始的仅小区大门封闭，可以在小区内闲逛，到后来的不建议不允许下楼，每天下楼只能做三件事儿，核酸、倒垃圾、拿快递。再到昨天晚些时候，对部分楼栋每户上了封条。不知道后续还会有什么措施。在整个过程中，日常用品从来没有好买过，从最开始的各大买菜平台上定时抢菜，到后来的社区团购，再到现在社区不时投喂。目前各项物资虽然说不上缺乏，但也说不上丰富。至于说核酸检测，目前也基本上是1～2天就要做一次，到现在为止，已经不知道做了多少次核酸检测了。

在这一个多月的时间里，看到、听到各种乱象：护士因为突发哮喘无法得到及时的救治，无奈离世；全国各种支援物资无法得到有效的分配、被变卖，导致部分部分居民缺吃少穿；发放到居民手中的物资质量有各种各样的问题。不少人因为无法得到有效的救治而和亲人阴阳两隔；各种阳性患者没有被及时转移到方舱而引发社区聚集传播；被作为方舱的建筑设施由于没有竣工导致根本无法正常居住。各种向上反馈的渠道都失效了，所以究竟封控还要多久？

在这次封控之前，每次下班打车回家，我都会和司机师傅聊聊天，他们中的大多数人，都不是本地人，没有真正属于自己的房子，不少人甚至没有固定的居所。这样的底层人有太多太多了，这次封控政策，真不知道他们的处境怎么样。

一直以来，对于清零与共存，我是无感的。最近看到的种种乱象，我发现，感染病毒不一定会死，但是缺吃少穿，各种急症重症那真的会有生命危险。所以，我们真的一定要不管不顾，不考虑现状地执行清零政策么？为了执行这个政策，我们究竟要付出多大的代价，人命、经济、各种各样的连带损失如何计算？我们真的有认真的、专业的、独立的评估过我们各种方案的可行性么？

最近看到一些报道，说我们当前执行的清零政策与国外的策略已经成为了一种政治正确，成为了东西方文明、政治制度的竞争，我在想，这种防疫政策难道不是根据当前的现状而采取的科学的应对措施么？为什么会成为一种政治正确，这件事情与东西方的竞争有什么关系呢？当一种政策成为政治正确，在所有向上反馈渠道都阻塞之后，如何适时调整公共卫生政策呢？另外，在这种情况下，谁来保证政策在落地过程中不变形呢？

从周围人的反应来看，当前的这种Omicron变种，似乎并不会造成很大的致死率，在一定的疫苗接种率下，配合一定的隔离措施，并不会对自己的身体和周围人的健康造成很大的影响。可是在上海封闭的这一个多月的时间里，由于不合理的管控措施造成的伤亡和各项损失已经远远超出了病毒本身造成的损失和伤亡。所以，当前的这种措施真的是最合理的措施吗？

在家禁足的这段时间里，看到了物资投放的各种问题，有些人没有得到足够的物资或者压根没有的到物资，而有些人得到的物资质量存在很大的问题。这让我切身的感受到了几十年前，在这片土地上发生的各种人间惨剧，也让我感受到了计划经济的可怕。其实一直以来质量不过关的商品都是存在的，但是由于市场经济的存在，这些不合格的产品在市场上并没有立足之地，但是随着封控政策的升级，市场调节与供需关系被打破，所有生活必须品与各种产品的流动都统一由政府统一协调，而由于权利寻租的原因，导致这些产品充斥在各种投放的物资中，另外，政府无论多么高效（事实上，由人组成的各种组织在没有外部监管的情况下是不可能高效的），都不可能满足大众各种基本需求的，更别提各种个性化的需求，因为每个人的基本状况是不同的。所以，单纯的计划经济是永远不可能大众过上更好的生活的。

当然在家的这段时间，也并不是只有坏事，在文章的最后，我还想说说让我感觉暖心的各种事情。在封控的一开始，由于通知非常临时，并且当时说很快就会解封，所以很多家里并没有准备充足的物资，导致在封控了几天后，部分人缺吃少喝，而那时，支援物资几乎没有到位。当时小区内出现了各种各样的支援群，团购群，大家在群内，不仅一起团购各种生活必须品，经常还有人发各种求助信息，大到各种应急药品，小到各种葱姜蒜。每每有这种求助信息，群里的大家都会一起想办法，一起帮忙。住在一栋楼的各家人也建立了楼道群，大家信息共享、相互帮助。由于政府发放的各种物资并不能满足每个家庭的需求，所以大家也就经常在群里相互分享自己家里多余的东西，以物易物。在此次疫情之前，大家并不认识，即使是邻居也少有交集，而这次，因为疫情，大家似乎也熟络起来，就好像回到了以前的弄堂一样。这是疫情的灰暗之中的一抹亮色。

最后的最后，我还想说，其实经历了这一个多月的封控，其实大家已经非常疲惫了，无论是医生、护士、各种志愿者，还是我们每个人，希望能够按照当前的形势，重新审视当前的公共卫生政策，让专业的人做专业的事，不要外行指导内行了。

1、什么是NAS

NAS（Network Attached Storage）是网络附接存储的英文简称。下面是维基百科对网络附接存储的定义。

网络附接存储（英语：Network Attached Storage，缩写：NAS）是一种文件级（与块级存储相对）的计算机数据存储服务器，它连接到计算机网络，并提供对异构网络用户的数据访问。它专门用于通过其硬件、软件或配置来提供文件服务。

对于我个人来说，NAS更像是一个位于本地网络的“云”盘，同时为个人提供基本的多媒体等各种定制服务服务，如影音服务、离线下载、文件同步等，以满足我一般意义上的网络云盘满足不了的诉求。

实际上，很早之前就已经对NAS有一个简单的了解了，但是当时考虑到无论是成品NAS还是自组NAS，成本都不小，受限于当时的预算，并没有打算入坑。而是采用了另一种低成本的实现方式——在路由器上刷入OpenWRT系统。为此专门购买了LinkSys的WRT32X路由器（毕竟官方支持开源固件），刷入了OpenWRT，并安装了Samba、Aria2等工具，提供了离线下载、文件共享、Apple的Time Machine。系统备份等功能，也算是野生NAS了。

2、为什么要自组NAS

目前市面上，有很多面向C端用户的网盘服务（某某云、XCloud等），但是这些厂商提供的服务，在我看来有以下问题：

• 上传下载速度受限：由于ISP提供的上下行带宽并不对等（一般上行远远小于下行），导致对于大文件的上传体验较差；另外，不少云盘服务提供商会对未达到一定等级用户的下载速度做限制，导致很多时候，很难快速将自己的文件下载回来。由于速度不尽人意，整体体验不佳。
• 数据安全问题：一旦自己的数据上传到云盘，数据的安全问题就需要云盘服务提供商和用户共同努力去解决，但是近些年来时不时出现网盘数据被泄漏，私人照片被公开等情况。导致数据安全问题比较突出。
• 其他不可描述的原因：由于众所周知的某些原因，数据一旦通过互联网上传至网盘服务提供商，这些数据就不可避免的受到某些扫描和分析，很可能成为大数据的一部分，某些情况下可能会被篡改（比如文件上传至某某云后，被替换为8秒的宣传广告）。

此外路由器刷入OpenWRT，并安装Samba、Aria2这种方式，需要在路由器的USB3.0接口上外挂一个移动硬盘，而硬盘整体的功耗比较高，可能会导致路由器的电源处于过载状态，如此一来，路由器也很难长期稳定的运行，由于供电不足，并且需要常年工作，外挂的移动硬盘的寿命也会受到影响。而在路由器上通过Aria2做离线下载时，经常提示由于硬盘存在坏块导致下载失败，但是重试之后又恢复正常了。虽然LinkSys的WRT32X是内置一颗双核CPU，但整体性能羸弱，在对网络硬盘做基本读写过程中，1min的CPU负载在1.2以上，整体负载60%以上。除此之外，由于没有基本的电源备份，一旦市电中断，可能会对路由器上挂载的移动硬盘造成毁灭打击。

综上所述，对于数据控制及隐私比较在意的场景下，使用公共的云盘服务，并不能满足要求，而在通过OpenWRT上搭建各种数据共享及离线下载工具这种野生方式又不够稳定。因此，搭建一个NAS似乎就成了唯一的选择。

3、诉求梳理

为了解决上面提到的问题，现在对自己的一些诉求做一个简单的梳理：

目前市面上也有不少成品的NAS，比如群晖、威联通等，整体来看，成品NAS简单省事，利用厂商提供的软件，可以实现各种功能，包括但不限于网络文件共享，多端数据同步等。但成品NAS性价比不高，可玩性不高，扩展性也不高，考虑到未来的扩展性及可玩性，最终采用自组NAS而不是成品的NAS。

4、硬件选型

从上表计算可得，总计整个NAS的硬件共花费¥8770.56。

在硬件选择过程中，主要需要根据上面一节的诉求，选择主板，根据主板再来选择其他的硬件设备这样，选择的过程会比较高效。

由于希望使用ECC内存，这种内存条需要专门支持RDIMM的主板才可以，因此其实可以选择的范围就少了很多，因为大多数个人消费级主板都不支持RDIMM，所以选择的方向只剩下服务器级别的主板品牌了。大多数服务器级别的主板个人都很难买到（选择过程借助了一个比较购物平台PCPartPicker）最后选择了超微。在超微官网按照需求进行选择。原本选择了X11SPM-F主板，但是实际购买的时候，发现X11SPM-TF只比X11SPM-F贵了几百块，但是网卡可以从两个千兆电口升级为两个万兆网口。因此最终选择了此型号。

在NAS系统里，并不需要大容量的硬盘，对读写性能要求也不高，只要可以稳定、长期运行即可。因此在最开始的计划中，并没有打算购买SSD，当时考虑直接将NAS系统安装在U盘里。可是考虑到未来需要在系统上安装其他应用，并且U盘的读写性能、稳定性相对不足，长期运行可能有风险，因此最后决定新增购入一块SSD，不仅用于安装NAS，还可以用于扩展其他的系统或者应用。

5、最后

本篇文章，主要介绍了NAS的定义，为什么要自组NAS，并针对自己的各项诉求，最终提供了一份本人实际的硬件配置列表。在后面的文章中，将会对系统架构设计、软件安装与配置做详细的介绍。

自从2020年初最开始搭建这个博客到现在，已经过去两年了。在遥想两年前的今天，与现在的情形如此的类似。

在这段时间里，虽然一直在倒腾各种东西，NAS、Java，也一直在平时不断的了解业务，但是一直没有及时把这些想法记录下来。在之后的这段时间里，我会将最近的各种想法以及折腾的过程记录下。