搜索到
13
篇与
的结果
-
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 大小相等的时候，才算重建完成
-
-
truenas scale 之容器桥接不成功的问题 0x1 为什么桥接 其实如果是使用普通的http服务，单个ip足够使用了，那么就使用 nginx、treafik等服务直接放在前端做代理即可，通过不通端口或者不通域名定位到后端。 但是这里有一个多nfs服务端的需求，首先nfs服务端端口不好修改，再就是客户端又需要修改挂载端口，如果使用端口映射的方式那显然比较难以使用，所以多个公开ip是最好的方式。而实现用户直接访问（容器直接配置公众ip）的网络方式就是桥接，后续也可以使用到虚拟机上 0x2 如何配置 TrueNas版本：TrueNAS-SCALE-23.10.0.1 truenas网络接口这块的功能上其实做的非常好了，不过如果网络这块使用不多的人，一开始看的时候比较难以接收。比如上面已经有一个我的网卡了，那我继续add还做什么呢？以及展开的一些选项又能做什么用途呢？其实这些都是一些需要自己定制的功能，如果会，那么比较有用，如果不会，则一头雾水。 桥接配置方式 其实也不复杂，主要流程如下： 把目前的主接口ip拿掉，如果设置的dhcp，则关闭，之后保存（退出到外层后不要点测试） 创建（add）一个桥接类型的网络，设置名称，需要以br开头后面直接接数字，然后成员选择主接口，再设置之前主接口的ip，保存 现在可以点击测试了，如果没有问题，则会在60秒内生效，然后出现保存按钮，点击即可 第三步没有问题，则图标会变成链接状态，并且基本上跟主接口同步 但就是在这短短的几步出现了问题，点击测试后页面一直没有刷新，并且不再能够ping通ip，一直等到超时回滚后才刷新出页面，接下来查阅了大量资料后做了如下方法的尝试： 分别在web和终端中强制设置并且保存，无法访问web ui，无法ping通地址，最终无效 怀疑是mac地址不同导致无法访问，于是配置后在同网段的机器中访问，仍然不行 查阅资料后发现官方人员说启动的虚拟机或者app会影响，又关闭了整个app服务，取消了池，但重新配置仍失败 在这个过程中重启了很多次truenas，一步一步对比官方提供的操作创建了很多次接口，甚至顺序上也做了一些微小的调整，也咨询了一些使用的人，都没有给出有用的答案，最后都怀疑是truenas的bug了。 0x3 曙光 在查询了大量的类似问题之后，终于注意到了一段话。对方没有明确的说解决方案，但是说在虚拟化的平台中使用Truenas会有一些局限性。于是乎我恍然大悟，是否当前的 esxi 平台网络上有问题呢？ 登录到此esxi主机，依次找到 配置 -> 网络 -> 虚拟交换机，然后编辑，找到安全，可以看到当前的混杂模式是拒绝，修改为接收 再次返回 Truenas 配置桥接接口成功 0x4 其他 此次问题为虚拟机宿主机网络配置问题导致，如果后续实际迁移到物理机，应该是没有此问题的
-
