使用TrueNAS SCALE已经有3个月，中间经历了RC到正式版本的发布。总的来说TrueNAS是一款很好的NAS系统，我就此总结一下它的基本特性和优缺点
TrueNAS SCALE是基于Linux的（实际是基于Debian），但总的来说很难像OMV那样脱离Web自己玩。
TrueNAS并不推荐你直接在系统里安装或运行程序，因此不支持apt包管理。增加的功能都应该放在Docker容器中进行，理由是安全性和稳定性。
TrueNAS SCALE提供了Shell，但并不像一般的Linux发行版那样自由，只能使用k3s和docker命令和一些常用工具，无法使用apt包管理，在系统更新后，除root目录和ZFS存储池外的数据会全部被覆盖重置，留给用户的空间很少。如果你更向往更大的自由度，还是安装Ubuntu或Debian等等（说实话Windows Server也不是个坏选择）。
ZFS
ZFS是TrueNAS的最大特点，TrueNAS几乎完全依靠ZFS进行存储，TrueNAS的各项功能也都是围绕ZFS设计的。
ZFS既提供了传统RAID容错能力（RAIDZ2相比于RAID5/6）的同时，比传统RAID具有更高的可靠性（尤其是相比于低端RAID卡）。
巡检功能可以定期检测硬盘的URE（不可恢复错误），重建过程中不会因为URE导致重建失败。
重建速度非常快（相比于RAID5/6的重建速度），也就降低了重建过程中发生第二块硬盘损坏的概率。
支持压缩、去重功能，节省硬盘空间、提高传输效率。
支持快照功能（TrueNAS也在这个基础上提供了APP的快照和版本回滚能力）。
提供Dataset（正常的文件存储，表现为目录，可以在系统中直接访问）和ZVOL（块存储，可以作为硬盘挂载到虚拟机或者用于ISCSI服务）两种存储功能。
但是ZFS也有一个非常明确的问题：单vdev（多块磁盘组成一个vdev，一个或多个vdev组成一个zpool）无法扩容，要扩容必须要和另一个同等容量的vdev拼成一个新pool。 目前，ZFS单vdev扩容的方案已经有所进展，但是还没合并到master（https://github.com/openzfs/zfs/pull/12225），距离落地到TrueNAS上还要更很久。
ZFS的另一个缺点对CPU和内存要求较高，官方推荐1TB容量要配1GB内存，以我自己为例，在不开去重的情况下，约12TB的总容量下ZFS Cache消耗了14.4GB的内存。
ZFS相当强大可靠，但是和传统RAID一样需要我们谨记的一点是： ZFS也好，RAID也好，它们都不是备份，它们更需要保证业务持续可用。在商业应用中也不会全部指望阵列能提供备份，而是会另外做冷备等方案来保证数据不丢失。 这与家庭NAS的目标是不同的，家庭NAS不一定要求7x24小时持续不间断运行（甚至不用的时候还想让它歇一歇，省点电），但却不能接受数据丢失。
因此对于家庭NAS来说，存储中的重要数据最好定期备份到网盘上。
数据保护
TrueNAS提供了保护数据的相关功能，除了ZFS的Scrub定期巡检功能，还有SMART定期检测、数据定期同步和备份。
虚拟机
TrueNAS使用KVM运行虚拟机，提供了VNC和SPICE的远程桌面选项，可以直接挂载在ZFS中创建的ZVOL。
TrueNAS的虚拟机有一个问题就是虚拟机和宿主机之间无法通过网络互相访问，但是我也不清楚这是KVM的问题还是TrueNAS的问题，如果是有意为之的话，我猜可能是为了安全吧。
解决方法是创建一个虚拟网桥，将宿主机和虚拟机连接起来。我进一步的做法是创建一个OpenWRT的虚拟机，添加在网桥里作为网关，其他虚拟机也可以通过它上网。
当然最好的办法是通过PCIE直通一个物理网卡给虚拟机。虚拟网桥对资源的消耗还是挺大的，我的配置是双路E5-2666v3，网桥内的速度常常达不到千兆。
APP
TrueNAS SCALE的插件是基于容器的，插件是无法改变系统自身的。
TrueNAS的APP功能是基于Kubernates的，使用下来更像在创建容器，因此要比插件复杂一些，但是用好各种APPS，会让你的体验提升一个等级。
官方的APPS源提供的软件不多，所以我们一般要添加TrueCharts社区的源，里面提供了相当丰富的APP，而且增加的速度很快，再过段时间可能就需要分类功能了。
有这三个APP非常重要，它们可以是良好体验的基础：
- Treafik
- k8s-gateway
- pihole
配置好后，当我需要部署一个新APP，比如Nextcloud，我只需要在配置时填入我想用来访问Nextcloud的域名，比如cloud.home，确认配置，稍等容器部署完毕，就可以直接在浏览器里用 https://cloud.home/ 访问Nextcloud了。
因为既然要从外部访问，这些APP都要绑定到同一个网卡上，它们之间必须采用不同的端口，否则 要记住哪个端口对应的是哪个应用是一件令人抓狂的事。
而这三个APP就解决了这一问题，部署APP的体验变得相当丝滑。
- Treafik是一个反向代理，它可以把各个APP的服务代理到自己的端口上，基于主机名HOST和访问URL规则将请求导向各个APP。
- k8s-gateway则会自动根据部署APP时设置的域名来设置相应的DNS解析记录。
- pihole作为k8s-gateway的前置服务器，提供更多dns解析功能。
（这些能力最终还是要归功于k8s）
APP有一个比较需要注意的地方，所有APP只能绑定到一个网口上，从其他网口上是无法访问的。这个一般不会引起什么大问题，但是我需要在虚拟机里访问APPS，结果是我既不能从外部局域网访问，也不能从内部网桥访问，无奈之下，把APP绑定到内部网桥上，然后用OpenWRT做端口转发。
OpenVPN
TrueNAS SCALE自带了OpenVPN服务端和客户端，OpenVPN证书配置让人很厌烦，但是在TrueNAS上操作很轻松，因为TrueNAS上的证书是统一管理的，签发后可以在不同服务中直接调用。
连接OpenVPN服务端后，默认是只能访问本机的，需要配置iptables，这个也许以后我会介绍，可以看这个视频：TrueNAS Scale - How to access your LAN through VPN connection
Middleware（Web服务等）
TrueNAS SCALE我认为最重要的两个特性：ZFS存储和基于k8s的APP，他们用的也是很可靠的技术，KVM也一样。这些都是经历了充分考验的，很难出什么问题。
但是TrueNAS建立在其上的一套东西的稳定性有些差强人意了，它们贡献了多数缺点。这一套东西指的就是沟通用户和服务的Web页面以及将请求转发到服务的一层，在系统中叫Middleware（中间件）。
在昨天我刚刚遇到了虚拟机管理界面无法与qemu通信的情况，重启才解决。
Web页面在许多情况下会出现无响应、卡顿，然而这只是浏览器里的网页而已，我不知道这到底是怎么设计得能影响到UI线程的。
对大陆用户不友好的网络需求，虽然很多海外NAS系统都有这个毛病，但是TrueNAS已经到了启动APP时要请求google的api，请求不了就无法启动容器的地步。按理说挂HTTP代理能解决，但是目前的22.02.1版本有一个BUG就是Middleware请求k8s服务api的时候（访问本机127.0.0.1的6443端口），会把请求导进HTTP代理...。结果就是22.02.1版本对我来说完全无法使用，BUG会在22.02.2中修复。
comments powered by Disqus