truenas core 升级到 scale
侧边栏壁纸
博主昵称
yuc

  • 累计撰写 291 篇文章
  • 累计收到 0 条评论

truenas core 升级到 scale

yuc
yuc
2023-12-13 / 最后修改: 2023-12-19 03:38 / 0 评论 / 3 阅读 / 正在检测是否收录...
0x1 注意事项

升级是官方支持,并且比较容易,但受限点在于 core 是基于 freebds 开发的,是类unix系统,scale 是21年开始的支线,是基于 linux 开发的,所以有些功能是不兼容的,以下是几个注意点:

  1. scale 不支持 core 的虚拟机和 jail,因为这两个都是 freebds 的功能,与linux技术不符
  2. 然后有一些服务也是在 scale 中拿掉了,因为 scale 支持更广,可以使用其他方式来部署,不需要作为 core 中的服务
  3. 如果有 GELI 的池,需要先导出恢复到非加密池中,这样 scale 才能正常使用这个池
  4. 还有一些环境变量、其他服务的数据等,以及系统用户创建的规则
  5. core 升级到 scale 对大版本和小版本有一定要求,但范围内都可以
  6. 完全升级成功是不可回退,需要备份好数据
0x2 为什么

freebds 是基于 unix 的,一些服务使用起来不方便,并且相对于linux支持的插件、服务更少,jail听说可以实现许多功能,但是学习资料少,学习成本高,所以最终是选择使用linux

0x3 升级步骤

因为之前基本上使用的 nfs 共享,没有使用 虚拟机 或者 jail,所以基本上不需要做很多的这些清理和备份,保留池以及池内关键数据做好备份即可,然后使用下面步骤:

  1. 备份好 core 的配置文件
  2. 刻录好 scale 的镜像
  3. 关闭机器,使用新的系统盘
  4. 重启安装 scale,选择安装到新的系统盘
  5. 重启后登录到 scale,恢复之前备份的配置文件
  6. 在存储中可以看到之前的池被导入,且其他配置恢复

PS. 这里升级有个重要的点可以确定下,就是在没有完全升级成功的情况下,用之前core的系统盘是可以正常启动到之前环境的。也就是说 truenas 升级并不会影响数据盘,除非升级成功之后点击了升级数据池(在后续确认了,如果两个盘分别安装了core和scale,那么可以轮流启动使用都没问题,所以所谓的单向升级、不能回滚仅针对于zfs 池版本升级后,那么不能够再使用core)

0x4 异常和故障

此次升级也并不是一帆风顺的,其中有几个点需要注意下:

  1. 使用u盘作为系统盘真的很烂,这估计就是为什么之前高版本freenas以及后面的truenas都不推荐使用个u盘作为系统盘的原因,购买的两个u盘只作为系统盘半年,再次安装scale的时候写入出现io错误,并且写入速度非常慢,整个流程使用了6个小时(正常外置硬盘盒的固态是30-60分钟),正常固态硬盘是十几分钟左右。最后硬盘盒也是不被推荐的,truenas的说法是usb设备都不再推荐。
  2. 在升级完成后原本两个数据池,但是只能看到一个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 大小相等的时候,才算重建完成

0

评论

博主关闭了当前页面的评论