Truenas scale 配置多个nfs server 0x1 问题背景 以前truenas core自带的nfs服务，分别共享了 docker swarm 的共享目录（2.7T），jenkins 数据目录（280G），seafile 数据目录（900G）。这三个目录非常多的小文件，甚至在统计目录大小的时候，十来分钟都无法出结果 也许是这个原因，默认的nfs服务共享了多个超多小文件的目录，以及共享到了多台机器。导致经常出现 INPUT/OUTPUT error，现象如下： 客户端挂载参数： 192.168.10.16:/mnt/dev1/jenkins on /var/jenkins_home type nfs4 (rw,noatime,nodiratime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,noresvport,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.3.106,local_lock=none,addr=192.168.10.16,_netdev) 创建新文件直接报错，但是创建目录没有问题 [root@localhost 123]# touch 1122 touch: cannot touch ‘1122’: Input/output error [root@localhost 123]# touch 2233 touch: cannot touch ‘2233’: Input/output error [root@localhost 123]# touch 3344 touch: cannot touch ‘3344’: Input/output error [root@localhost 123]# mkdir 1122 [root@localhost 123]# mkdir 2233 [root@localhost 123]# mkdir 3344 [root@localhost 123]# touch 4455 touch: cannot touch ‘4455’: Input/output error [root@localhost 123]# touch 5566 touch: cannot touch ‘5566’: Input/output error 重新客户端挂载，会正常一会儿，但是有一会儿又不行了 [root@localhost 123]# cd [root@localhost ~]# umount /var/jenkins_home/ [root@localhost ~]# mount -a [root@localhost ~]# cd /var/jenkins_home/123/ [root@localhost 123]# touch 1111 [root@localhost 123]# touch 2222 [root@localhost 123]# touch 3333 [root@localhost 123]# touch 4444 [root@localhost 123]# touch 5555 touch: cannot touch ‘5555’: Input/output error [root@localhost 123]# touch 6666 touch: cannot touch ‘6666’: Input/output error [root@localhost 123]# touch 1111 [root@localhost 123]# touch 2222 [root@localhost 123]# touch 3333 [root@localhost 123]# touch 4444 [root@localhost 123]# touch 5555 touch: cannot touch ‘5555’: Input/output error [root@localhost 123]# touch aaaa touch: cannot touch ‘aaaa’: Input/output error [root@localhost 123]# touch bbbb touch: cannot touch ‘bbbb’: Input/output error [root@localhost 123]# mkdir 5555 [root@localhost 123]# mkdir 6666 抓包发现很多过期的告警，很明显是不正常的，nfs的会话正常也不应该创建、列出一下就会有多个过期的响应 这个问题尝试了很多方案，使用不同的nfs版本挂载，把一部分数据迁移到其他的池以减少单个池的读写或者文件数量，但结果仍然不行。所以最后怀疑是Truenas core的nfs问题，有可能小文件太多性能不足、有可能多个nfs目录对应多个不同的客户端（网络传输过程中客户端ip识别有问题，导致会话过期）等，所以最后下定决心使用多个nfs server来解决这个问题 0x2 目标和方案 目标: 每个需要共享的数据集目录使用单独的nfs server，以单独维护每个共享目录，以及减少单个共享目录访问的客户端ip，以及文件并发

H3C S1850V2 链路聚合LACP 关于交换机 这款交换机是管理型的，支持不少功能，如下: 基本交换功能： VLAN 支持：支持虚拟局域网的配置和管理。 交换表：支持 MAC 地址学习和转发。 二层组播：支持组播的传输和管理。 管理和维护： 远程管理：支持 Telnet 和 SSH 等协议进行远程管理。 Web 管理界面：提供图形化的 Web 界面进行设备管理。 SNMP（Simple Network Management Protocol）：支持 SNMP 协议，用于网络监控和管理。 安全特性： 802.1X 认证：支持端口基于 IEEE 802.1X 的认证。 MAC 地址认证：通过 MAC 地址对设备进行认证。 静态 VLAN 认证：支持 VLAN 认证。 QoS（Quality of Service）： 802.1p 优先级：支持 IEEE 802.1p 优先级标记。 DiffServ（区分服务）：支持基于 DiffServ 的流量分类和标记。 链路聚合： 支持链路聚合以增加带宽和提高冗余性。 安全性功能： 动态 ARP 检测：用于检测和防范 ARP 欺骗攻击。 灵活的管理接口： Console 接口：通过串口连接进行设备配置。 Telnet/SSH：通过网络进行远程管理。 Web 界面：通过图形化的 Web 界面进行设备管理。 性能优化： Storm 控制：用于防范网络风暴，如广播风暴、组播风暴等。 IPv6 支持： IPv6 配置和管理功能。 端口镜像： 支持端口流量的镜像功能，用于网络监测和故障排除。 PoE（Power over Ethernet）: 如果你的 S1850V2-52P 支持 PoE，那么它可能提供 Power over Ethernet 功能，用于供电连接到交换机的网络设备，如 IP 摄像头、IP 电话等。 但是这款交换机基本上只支持在web管理，在CLI支持的配置非常有限，基本上最大的用途就是配置ip 交换机的默认ip是 192.168.0.233，所以调试的话，接入笔记本到同网段，然后访问此ip即可，也可以进入 cli 使用 ip-setup 来设置ip 配置管理vlan和业务vlan 既然是可web管理的，那么就需要配置当前网络环境的管理vlan48 以及 当前网络环境的业务vlan10，而不再使用默认的vlan1。再就是开启vlan后设置登录密码（默认无密码），首先保证默认的 ip 或 手动配置地址可以访问web (二层)交换机配置 1号端口 为trunk 与上联三层一样，这样可以放行两个vlan。在设备-端口管理-设置中 (三层)上联端口设置为 trunk，并且放行 vlan48 和 vlan10 int G 1/0/20 port link-type trunk port trunk permit vlan 10 48 port trunk pvid vlan 10 (二层)在网络-VLAN-创建中分别创建vlan10（业务）和vlan48（管理） (二层)在网络-VLAN-修改端口中，选中端口1，选择 tagged，把vlan10和48加上 (二层)在网络-VLAN虚接口-创建，创建两个VLAN的地址，其实创建一个vlan48的地址即可，此地址后续可以访问，作为管理ip，同时此网段也可以作为下一条，进入三层 (二层)在网络-IPV4路由-创建，创建下一跳路由，可以保证此接口出去的网络路由正常，下一条接口和网关ip，选择vlan48的即可 至此，其他接入此交换机的ip，如果配置vlan10或者vlan48，即可正常访问网络 配置链路聚合 这款交换机支持链路聚合功能，并且支持动态聚合，可以配合 NAS 支持的LACP使用，实现多条线路负载以及故障冗余 链路聚合以及LACP配置

truenas 链路聚合LACP 0x1 优点 Truenas使用链路聚合可以叠加带宽、增加链路冗余，有利于提升nas的性能 0x2 配置 链路聚合需要对端设备支持，所以首先要在交换机配置好对应端口的LACP 新建一个网络类型，选择链路聚合，协议 LACP，策略、速率默认，然后选择对应的端口即可，最后把ip从原接口拿掉，配置到下面的别名即可（与桥接类似） 0x3 测速 经过简单的测速，多台同交换机同时传文件到NAS上，可以看到NAS监控上最高速率约为 1.8Gb/s，对于3网口链路聚合来说稍微有点低，不过也算是提升了，可能跟线路质量等方面有一定关系

truenas 池的基本操作 基本操作 truenas 查看池状态，后面接池名称 zpool status dev1 truenas 导入池，或者查看池不能导入的原因 zpool import truenas 查看磁盘gptid和序列号的对应关系 # zpool status只能看到 gptid，但有时候我们需要格式化一个盘，需要定位到设备为止，可以结合两者查看 glabel status truenas 离线一个磁盘 # 总体的格式就是 池名称 设备gptid（zpool status 上完整的gptid路径） zpool offline dev1 gptid/GPTID # offline 后 online 同理，并且如果如果是旧盘，online 一会儿只需要同步部分数据，无需全盘同步

truenas core 升级到 scale 0x1 注意事项 升级是官方支持，并且比较容易，但受限点在于 core 是基于 freebds 开发的，是类unix系统，scale 是21年开始的支线，是基于 linux 开发的，所以有些功能是不兼容的，以下是几个注意点： scale 不支持 core 的虚拟机和 jail，因为这两个都是 freebds 的功能，与linux技术不符 然后有一些服务也是在 scale 中拿掉了，因为 scale 支持更广，可以使用其他方式来部署，不需要作为 core 中的服务 如果有 GELI 的池，需要先导出恢复到非加密池中，这样 scale 才能正常使用这个池 还有一些环境变量、其他服务的数据等，以及系统用户创建的规则 core 升级到 scale 对大版本和小版本有一定要求，但范围内都可以 完全升级成功是不可回退，需要备份好数据 0x2 为什么 freebds 是基于 unix 的，一些服务使用起来不方便，并且相对于linux支持的插件、服务更少，jail听说可以实现许多功能，但是学习资料少，学习成本高，所以最终是选择使用linux 0x3 升级步骤 因为之前基本上使用的 nfs 共享，没有使用 虚拟机 或者 jail，所以基本上不需要做很多的这些清理和备份，保留池以及池内关键数据做好备份即可，然后使用下面步骤： 备份好 core 的配置文件 刻录好 scale 的镜像 关闭机器，使用新的系统盘 重启安装 scale，选择安装到新的系统盘 重启后登录到 scale，恢复之前备份的配置文件 在存储中可以看到之前的池被导入，且其他配置恢复 PS. 这里升级有个重要的点可以确定下，就是在没有完全升级成功的情况下，用之前core的系统盘是可以正常启动到之前环境的。也就是说 truenas 升级并不会影响数据盘，除非升级成功之后点击了升级数据池(在后续确认了，如果两个盘分别安装了core和scale，那么可以轮流启动使用都没问题，所以所谓的单向升级、不能回滚仅针对于zfs 池版本升级后，那么不能够再使用core) 0x4 异常和故障 此次升级也并不是一帆风顺的，其中有几个点需要注意下： 使用u盘作为系统盘真的很烂，这估计就是为什么之前高版本freenas以及后面的truenas都不推荐使用个u盘作为系统盘的原因，购买的两个u盘只作为系统盘半年，再次安装scale的时候写入出现io错误，并且写入速度非常慢，整个流程使用了6个小时（正常外置硬盘盒的固态是30-60分钟），正常固态硬盘是十几分钟左右。最后硬盘盒也是不被推荐的，truenas的说法是usb设备都不再推荐。 在升级完成后原本两个数据池，但是只能看到一个SSD的固态池，另外一个机械池看不到了，这里列出异常信息和排查： Disk(s): sdm, sdj, sdh, sdf, sdi, sda are formatted with Data Integrity Feature (DIF) which is unsupported. 可以看到有6块硬盘提示都不在支持，因为格式化了DIF的功能，查看 /dev/ 目录，磁盘都是存在的，但是通过 fdisk 查看就显示不了这些磁盘 查看原来的机械池状态，使用 zpool import ，这个命令在需要导入池的时候可以使用 可以看到6块硬盘不可用，剩下的硬盘没有足够多的副本，所以池无法正常导入，这里我们做的是raidz3，最多可以允许丢失3块硬盘，而6块硬盘早已超过了上限 DIF 的原因 一般DIF有两种原因，一种是扇区是520字节或者其他，不是标准的，另一种是这些型号的硬盘启用了T10保护，我们可以通过两种方式的命令确认，后面接需要检测的硬盘即可 root@freenas[~]# sg_readcap -l /dev/sdX Read Capacity results: Protection: prot_en=1, p_type=1, p_i_exponent=0 [type 2 protection] Logical block provisioning: lbpme=0, lbprz=0 Last LBA=3907029167 (0xe8e088af), Number of logical blocks=3907029168 Logical block length=512 bytes Logical blocks per physical block exponent=0 Lowest aligned LBA=0 Hence: Device size: 2000398934016 bytes, 1907729.1 MiB, 2000.40 GB, 2.00 TB root@freenas[~]# smartctl -i /dev/sda smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.1.55-production+truenas] (local build) Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Vendor: IBM-XIV Product: HUS723020ALS64A4 Revision: JYK5 Compliance: SPC-4 User Capacity: 2,000,398,934,016 bytes [2.00 TB] Logical block size: 512 bytes Formatted with type 2 protection 8 bytes of protection information per logical block Rotation Rate: 7200 rpm Form Factor: 3.5 inches Logical Unit id: 0x5000cca01cbb427c Serial number: YGK9ZKTK Device type: disk Transport protocol: SAS (SPL-4) Local Time is: Sat Dec 9 16:32:48 2023 CST SMART support is: Available - device has SMART capability. SMART support is: Enabled Temperature Warning: Enabled 以上都可以看到是 type 2 protection 的保护 DIF 的解决 现代普通消费级硬盘很少有DIF功能了，而 truenas core 是支持这种硬盘的，scale 目前不支持，所以 core 升级到 scale 后就无法使用 通过查询资料，解决办法就是重新格式化。但已经升级了，如果贸然直接格式化，那这些盘不在池中，scale也无法读取数据，大概率应该没法自动恢复的。所以最终的结论就是需要还原到原系统？通过原系统格式化，然后替换硬盘恢复池数据。 安装回原系统，导入配置后还可以正常识别到池，文件读取也正常。现在通过以下命令来格式化硬盘了。先离线，每次格式化的个数取决于池的类型，比如我目前raidz3，那么一次不能超过3块，2块是比较保险的。在重新格式化后再次通过上面的命令查询是否有T10保护，确定移除保护之后替换原来离线的磁盘 # 格式化掉 T10 保护 sg_format --format --fmtpinfo=0 /dev/sd* 这个格式化的时间比正常格式化慢很多，大约用了3个小时 后续 在经过6块硬盘的折腾，发现一个事情，同时恢复多块硬盘的速度刚开始还可以，但是后续的速度会掉到 100-200M/S，而且重要的是他不会三快盘同时完成，而是有先后顺序。后续的盘又会计算需要恢复的容量，再跑一遍，也就是说多块盘共享了速度，然后又需要恢复多次。这样看起来非常浪费时间和效率，所以在后面3快盘的时候，都是格式化一块恢复一块，而速度基本上保持在300M-400M，比多块盘快多了。 我们可以使用 zpool status dev1(池名称) 来查看相关池的恢复状态、进度等 这张图剩余3小时50分钟，或者40.8%都是预估的，只有等到 issued 的大小与 scanned 大小相等的时候，才算重建完成