HebronG 最近的时间轴更新 HebronG 最近的时间轴更新 |
HebronGV2EX 第 296874 号会员，加入于 2018-03-05 19:45:42 +08:00今日活跃度排名 13746 |
HebronG 最近回复了
68 天前 回复了 xueyuehua 创建的主题 › 浏览器 › 哪个浏览器适合长时间使用的 |
firefox ，单位笔记本基本每周重启一次浏览器不关常驻十几个标签页，从来没卡过
139 天前 回复了 barathrum 创建的主题 › NAS › 到底还是 all in boom 了 |
@KINGWAY 全部 16T ，便宜的时候一千五一块，现在不好买了
方案可以去隔壁 chiphell 学学，了解不同方案的倾向，不同系统的特性，然后建议自己做一个不要抄，如果自己搞不出方案说实话大概率没有相应的运维能力，硬上后期会很麻烦，建议直接 WIN 下挂几个单盘就完了，或者买成品 NAS
说真的 V2EX 主攻软件工程方面的，这种涉及硬件的综合系统运维还是隔壁比较熟
方案可以去隔壁 chiphell 学学，了解不同方案的倾向，不同系统的特性，然后建议自己做一个不要抄，如果自己搞不出方案说实话大概率没有相应的运维能力，硬上后期会很麻烦，建议直接 WIN 下挂几个单盘就完了，或者买成品 NAS
说真的 V2EX 主攻软件工程方面的，这种涉及硬件的综合系统运维还是隔壁比较熟
140 天前 回复了 barathrum 创建的主题 › NAS › 到底还是 all in boom 了 |
@pfffs 唯一可能可以在当前条件下更进一步的，大概是迁移到 trueNAS 系统而不是在 ubuntu 下进行配置，虽然也是基于 linux ，但官方适配可能能比 openZFS 要更好一些。但只是可能，我没具体比较过这两种方式的区别
140 天前 回复了 barathrum 创建的主题 › NAS › 到底还是 all in boom 了 |
@pfffs 连硬件 raid 卡都有机会“莫名其妙”就坏了，你这个需求不用 zfs 也没啥更好的选择了啊，反正本来也就是单台系统，ZFS 莫名爆炸的概率比系统莫名爆炸的概率还是要低一点的
如果要安全性更进一步的花，就要多台服务器了，要么用更高级的软件定义存储，要么多个存储系统互为热备，你参考自己的情况考虑下有没有这个必要
如果要安全性更进一步的花，就要多台服务器了，要么用更高级的软件定义存储，要么多个存储系统互为热备，你参考自己的情况考虑下有没有这个必要
140 天前 回复了 barathrum 创建的主题 › NAS › 到底还是 all in boom 了 |
@pfffs 如果你不需要额外的可用性和读写速度，你就不需要 ZFS （以及其他任何 raid 方案）
至于安全性，合理配置不折腾的情况下目前认为 ZFS 是足够安全的，最好 ECC 内存就是
至于安全性，合理配置不折腾的情况下目前认为 ZFS 是足够安全的，最好 ECC 内存就是
140 天前 回复了 barathrum 创建的主题 › NAS › 到底还是 all in boom 了 |
140 天前 回复了 barathrum 创建的主题 › NAS › 到底还是 all in boom 了 |
@bugmaker233 没特殊需求不建议直通任何东西，虚拟机隔离的越好，性能越好问题越少
140 天前 回复了 barathrum 创建的主题 › NAS › 到底还是 all in boom 了 |
顺便，对于没有运维经验的人来说，选择 WINSERVER 真的挺好的，不管装 vm 还是用 hyper-v 都行，从性能和功能上比不过 linux 平台，但胜在一般人都有操作和一定程度上维护 WIN 系统的经验，比较傻瓜化，选择 linux 意味着要从头学习，要接受完全不同的思维和操作方式。
我就是干运维的，折腾这些和上班一样，早就习惯了，甚至比 WIN 更习惯
我就是干运维的，折腾这些和上班一样，早就习惯了，甚至比 WIN 更习惯
140 天前 回复了 barathrum 创建的主题 › NAS › 到底还是 all in boom 了 |
@HeyWeGo 备份不是为了数据迁移，也不是防系统损坏，而是防硬盘本身损坏，拉长时间看所有硬盘都是会坏的，即使没坏也有静默腐坏的问题，这些情况下还不丢失数据才是冗余/备份的意义，只有一份的数据就是默认“可以丢失”的
@gongquanlin 本质其实很简单，多文件系统，多备份，少在宿主机搞操作，把能分离的系统尽量分离开来。
我自己的话，宿主机是单独一块 SSD ，ZFS 系统一倍冗余，虚拟机磁盘单独一块 SSD ，ZFS 系统无冗余，备份下载单独一块 HDD ，ZFS 系统无冗余，存档数据三块 HDD ，XFS 系统 snapraid2：1 冗余
这其中，系统 SSD 和虚拟机 SSD 是绑定的可以视为宿主机部分，用一块盘也可以，选择 ZFS 系统主要看重读写缓存与文件完整性校验，有校验至少腐坏的时候即使无法恢复也可以及时发现。系统采用一倍冗余没啥意义，坏盘全都丢，只有遇到数据腐坏的时候有点用，这么做纯粹因为硬盘太空了，不是必须的。宿主机本身不需要备份，直接跑在宿主机上的只有 nut(UPS 通知)、hd-idle(磁盘休眠)、samba/nfs(文件服务)和 snapraid(数据仓库的冗余校验)，定期或有修改的时候备份/etc 即可，重装时直接恢复相关配置文件就行。
备份下载的缓存 HDD 一块，采用 ZFS 系统的理由和宿主机同样，除了当下载和临时存放盘外，还用来放宿主机备份和安装镜像/模板，唯一需要和宿主机分离的原因就是因为虚拟机备份，这样系统/宿主机坏了可以恢复备份，备份坏了就重做，两个同时损坏的概率不高，即使有也可以把备份数据在另外地方额外多存一份。
数据仓库三块 HDD ，用前面提到的 snapraid 进行冗余和完整性校验，因此不需要 ZFS ，选择更加成熟稳定兼容性好的 xfs 文件系统，也可选择 ext4 ，这俩个文件系统是个 linux 就能挂载(而且 zfs 和 snapraid 的相性不太好)。这一部分完全独立，没有任何外部依赖，因此出现问题可以第一时间把这几块盘物理卸载掉，等系统恢复了再挂载上。
剩下的所有功能都在四台虚拟机里面，一台 linux 作为核心应用服务器，通过 nfs 挂载缓存盘，部署网页、下载等服务。一台 WIN 用来运行只有 win 能运行的软件，包括各种不想跑在自己电脑上的国产软件，利用快照功能也可以当半个沙盒用。一台黑群晖用来同步手机和管控对外共享的权限，本身不长期存储数据，整理好了定期扔到数据仓库。还有一台软路由作为入口网关。这些虚拟机都有每月备份，有大改动的时候再手动备份，并且有意避免任何硬件直通，增加可恢复和可迁移性能，出现问题随时恢复。
需要注意的是，我这套系统是有点 overkill 的，全套 epyc 甚至还有异地备份，通常来说，至少数据系统和功能系统要分离开来，备份放在数据系统里面，两套系统同时爆炸的概率还是很低的，然后再根据具体的需求强度进一步细分
@gongquanlin 本质其实很简单，多文件系统，多备份，少在宿主机搞操作，把能分离的系统尽量分离开来。
我自己的话，宿主机是单独一块 SSD ，ZFS 系统一倍冗余，虚拟机磁盘单独一块 SSD ，ZFS 系统无冗余，备份下载单独一块 HDD ，ZFS 系统无冗余，存档数据三块 HDD ，XFS 系统 snapraid2：1 冗余
这其中，系统 SSD 和虚拟机 SSD 是绑定的可以视为宿主机部分，用一块盘也可以，选择 ZFS 系统主要看重读写缓存与文件完整性校验，有校验至少腐坏的时候即使无法恢复也可以及时发现。系统采用一倍冗余没啥意义，坏盘全都丢，只有遇到数据腐坏的时候有点用，这么做纯粹因为硬盘太空了，不是必须的。宿主机本身不需要备份，直接跑在宿主机上的只有 nut(UPS 通知)、hd-idle(磁盘休眠)、samba/nfs(文件服务)和 snapraid(数据仓库的冗余校验)，定期或有修改的时候备份/etc 即可，重装时直接恢复相关配置文件就行。
备份下载的缓存 HDD 一块，采用 ZFS 系统的理由和宿主机同样，除了当下载和临时存放盘外，还用来放宿主机备份和安装镜像/模板，唯一需要和宿主机分离的原因就是因为虚拟机备份，这样系统/宿主机坏了可以恢复备份，备份坏了就重做，两个同时损坏的概率不高，即使有也可以把备份数据在另外地方额外多存一份。
数据仓库三块 HDD ，用前面提到的 snapraid 进行冗余和完整性校验，因此不需要 ZFS ，选择更加成熟稳定兼容性好的 xfs 文件系统，也可选择 ext4 ，这俩个文件系统是个 linux 就能挂载(而且 zfs 和 snapraid 的相性不太好)。这一部分完全独立，没有任何外部依赖，因此出现问题可以第一时间把这几块盘物理卸载掉，等系统恢复了再挂载上。
剩下的所有功能都在四台虚拟机里面，一台 linux 作为核心应用服务器，通过 nfs 挂载缓存盘，部署网页、下载等服务。一台 WIN 用来运行只有 win 能运行的软件，包括各种不想跑在自己电脑上的国产软件，利用快照功能也可以当半个沙盒用。一台黑群晖用来同步手机和管控对外共享的权限，本身不长期存储数据，整理好了定期扔到数据仓库。还有一台软路由作为入口网关。这些虚拟机都有每月备份，有大改动的时候再手动备份，并且有意避免任何硬件直通，增加可恢复和可迁移性能，出现问题随时恢复。
需要注意的是，我这套系统是有点 overkill 的，全套 epyc 甚至还有异地备份，通常来说，至少数据系统和功能系统要分离开来，备份放在数据系统里面，两套系统同时爆炸的概率还是很低的，然后再根据具体的需求强度进一步细分
Select Language