V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  sicifus  ›  全部回复第 1 页 / 共 10 页
回复总数  193
1  2  3  4  5  6  7  8  9  10  
OP 博客的 RSS 地址是什么?好像没法订阅?
41 天前
回复了 Int100 创建的主题 软件 不用密码记录器,实在顶不住了
用啥都行,千万别用 lastpass ,出安全事故 n 次了,我至少忍了两次,第三次实在忍不了删号跑路了。
现在是 keepass+webdav
光猫改桥接,路由器直接拨号,
一般就扫不到家宽的登录页
50 天前
回复了 q534 创建的主题 生活 买了个超级舒服的枕头。
mark 一下,等一波使用反馈
如果是床车,其实生活质量很差,你就联想一下一线 1k 以内房租的生活质量什么样,比那个差 2 倍以上就是了。

如果要省钱,至少入手一下房车,找二手的骨折价。
但如果要到「凑合」级的舒适性,也要再花一些成本做改造的,譬如基本的隔热隔音、水路、电路/发电、取暖、床位布局等等,
进一步有追求的还要规划厨房、卫生/淋浴及相应配套的水电扩展等。

另外,日常费用里,一线城市停车费是大头,如果能搞定便宜的上、下班停车位,那么成本可以极大地控制,否则不划算。
58 天前
回复了 CivAx 创建的主题 程序员 各位的家用服务器是 EXSi + OS 还是直接装 OS
@libook #108 你好,能方便说一下 MergerFS 不太适合的场景是什么吗?谢谢~
淋巴转移不算远端转移,LZ 要乐观、坚强
94 天前
回复了 37Y37 创建的主题 旅行 两年房车使用者劝你不要买房车
自动 LZ 在 V2 站发帖说买房车后就关注上你的博客 rss 了,
虽然我自己应该不会买房车,
但经常能看到房车旅行记录也蛮开心的,云吸房车,
有些经验在自驾游时也能用得上。
感谢~
自从家附近有奥乐齐后,感觉就不需要山姆了
@msg7086 #56
"放到今天来说,就相当于你之前买了两块 6T ,现在加了一块 12T ,那你 6T 还是用小容量占坑,等于还是亏了。如果是第三次扩容,那就相当于里面放了两块 3T ,一块 6T ,一块 12T ,更亏了。"
————————————————
我觉得这段话里大概有三个问题:
1 )扩容应该算边际成本的,在现有 2*6T 的情况下,方案①:只需额外采购 1 块 12T 、且充分利用原有 2*6T 、且构成了 1+1 容量完全均等(主 12T ,备 2*6T )的主备存储池,和方案②:采购 3 块 12T ,替换下原有的 2*6T 又没有合适的用途,明显是方案①的成本更优。
2 )第三次扩容你的方法写错了,不是 2*3T+1*6T+1*12T ,而是 2*6T+1*12T=24T 组成新的备用池,再采购 1 块 24T 组成主用池。保护
3 )至于“盘位成本很高”,我是寻求一条保护即有盘位投资+磁盘投资的同时、兼顾容量可扩展性的道路。
说白了现有一般的容量扩容思路有三种,
第 1 种是盘位扩容法,即容量用满时,新采购一个 NAS (或硬盘柜),缺点是最贵,即同时增加盘位投资和磁盘投资,同时亦存在文件跨盘管理的问题。
第 2 种是磁盘扩容法,即容量用满时,新采购 n 块磁盘,缺点是次贵,一般需要采购 2 块( raid1 )及以上( raid5 ),且数据迁移的难度不低,风险有较大争议。
第 3 种是 shr 扩容法,即可按单盘位分批容量升级。这是成本相对最理想的情况。
我的改进思路是基于 shr 的可扩展+性价比的基础上,一方面建议采用(n+n)+2n+4n 的分布扩容法,性价比(磁盘延迟采购)和数据安全性( 100%备份)最平衡,其次对于普通用户来说可以降低对条带化存储的迷信,开阔一下思路。

就像你说在 56#和 57#提到的企业级的方式,其中 zfs 我并不想否定其价值和意义,就像普通 raid 是有其价值和意义一样。我只是说从 basic 1+1 往上走,如果关注重点是性价比、磁盘扩容便捷性、数据备份性,而不是 NAS 高可用性等特性的话,其实有其他更便捷、性价比更高的 [民用级] 存储扩容和管理思路的,不需要直接跳到的条带化存储思路上去。


57#的“单盘单分区,放满了换块盘放,备份就是盘对盘互拷”的思路,其实的确是民用级最简便的扩容方案,唯一的一个问题是跨盘文件管理的不便,因此需要在这个基础上引入一下 mergerfs 做存储池。
@msg7086 #51
按照你提供的视频里的说法( 05:33 起),成品 NAS 都是有自动化的定期数据清理机制的,而开了这个机制后就能监控到磁盘损坏,而不必等到重建时才发现。他们之所以数据丢失的原因就是因为自搭的 CentOS 上没有开启定期清理,nothing more ,没有提到需要"刮数据"。以上是我看完后的理解,若有错误请指正。

关于既要又要还要,不是一个绝对的概念,而是和对标对象的 PK 下的相对胜出。主贴里的小结部分提到了,这里再扩展开说一下:

1 )省钱:主要对标 raid5 、raid1 、群晖。
raid5 的“不省钱”体现在需至少 [一次性] 采购 3 块同容量磁盘( 67%容量利用率)、更普遍做法 [一次性] 采购 4 块( 75%容量利用率)。此外,4 盘同时运转更耗电。
raid1 的“不省钱”体现在空间利用率只有 50%上,但由于初期磁盘可只买 2 块,数据量上去后再按需追加,实际有效容量的成本是接近乃至持平 raid5 的。(当然要看自己的数据增速,增速越快、磁盘二次采购期越近,raid1 越劣势)。
群晖的额外“不省钱”体现在盘位费贵、系统要在每块磁盘都要复制一份等等。

我的思路是保留 raid1 按需扩容的优点,同时避免它必须每次买 2 块的缺点,二次、三次购买都是采购容量翻倍的单块磁盘,通过延长分批采购的时间吃到技术进步&成本下降的红利。同时,磁盘越少电费约省。此外,无需捆绑于群晖。

2 )不折腾:在容量扩容的硬需求下,主要对标条带化 raid (包含 shr 、zfs 等),以及传统 basic 1+1 模式。
raid/zfs 的一个“折腾”主要体现在条带化存储导致的「 data lock-in 」,在磁盘扩容时必须经历数据导出 -> 磁盘清空 -> 重新导入数据的过程。
此外,磁盘替换时(坏道,或 shr 场景下的磁盘替换增容),raid 重建过程中 CPU 和 IO 性能会狂跌,要忍受大几十小时的不可用时间。
basic 1+1 模式的“折腾”主要体现在磁盘>=3 时,文件管理的不便。

我的思路是放弃条带化存储( raid 的缺点、basic 1+1 的优点),技术方案是 snapraid 。同时采用存储池( basic 1+1 的缺点、raid 的优点),技术方案是 mergerfs 。
针对有些楼内说的多盘 mergerfs 下 io 性能不佳的问题,采用主存储池单块磁盘、日常 io 操作,备存储池多块磁盘合并、只做冷备的方式来解决。

3 )低风险:对标条带化 raid 。
条带化 raid 的“风险”场景:重建时的损盘(争议很大,但至少 ≥ basic 吧? basic 重建只需复制、无需校验/擦写)
raid5 的额外“风险”场景:多盘同时坏块。

我的思路:同第二条,弃条带化,采用文件级 raid ,叠加 1+1 备份。即便多盘出现坏块,也只损伤特定文件,不涉及跨盘的条带校验值,也不影响其他文件的随意增查删改复制等操作。

不知上述解释能否略微澄清一些你的疑惑?
@msg7086 #49 感谢回复!
1 )关于 URE 或相关的重建恢复问题,我除了关注理论计算值外,另外也比较关注网友实际碰到的情况。毕竟如果只考虑理论风险的话,由 n 个数学大佬们加持的 LTCM 长期资本管理对冲基金应该直到现在还获得好好的。

目前我看到的网上可见案例里,一旦重建恢复,民用级 raid 导致的第二块磁盘故障的案例不少,结合风险=风险等级*风险概率的公式,在我的承受范围下属于不可接受的风险。

2 )诉求是想省钱、且不折腾、且低风险。所以整体方案要考虑 a)容量可扩展,b)扩展可平滑,c)1+1 存储池
@ButcherHu #36 另外,分期应不是"最优平衡",「延迟采购 x 分期」明显优于「仅分期」
@aru #26 你好,我把主贴的图示改了一下,如果日常增添删改永远在存储池 1 里操作、且存储池 1 永远只有 1 块磁盘,io 性能会不会好一点?存储池 2 仅作为冷备使用。
@ltkun #14
按照这篇文章( https://wzyboy.im/post/1186.html )的说法,zfs 同样有「 data lock-in 」的缺点,对磁盘容量扩展的友好性明显没有 mergerfs 高。
@libook #42 好的谢谢,我再学习一下
@ButcherHu #36 我又思考了一下,mergerfs 在下文件 io 表现不佳,会不会是因为小文件实际跨磁盘操作了?
我把主贴的图示改了一下,如果日常增添删改永远在存储池 1 里操作、且存储池 1 永远只有 1 块磁盘,会不会好一点?存储池 2 仅作为冷备使用。
@sicifus #40
我又思考了一下,mergerfs 在下文件 io 表现不佳,会不会是因为小文件实际跨磁盘操作了?
我把主贴的图示改了一下,如果日常增添删改永远在存储池 1 里操作、且存储池 1 永远只有 1 块磁盘,会不会好一点?存储池 2 仅作为冷备使用。
@libook #37 非常感谢~
的确是打算把 SnapRAID 作为温/冷数据定期备份来使用的,而且不打算跨存储池去操作数据。具体的思路是:
1 )重要数据(热数据)基于云+端的同步( 3 中心),确保数据多份拷贝和一致性。数据操作时不传 NAS/服务器。
2 )重要数据定期(每周 1~2 次)同步一次到 NAS+公司服务器上,仅用于规避中招勒索软件的时间成本(云端虽有版本管理功能,但一个个恢复起来时间太长)。其中在 NAS 侧,仅存到存储池 1 内。
3 )其他数据(主要是照片、影视、书籍等),日常的增添删改都只在存储池 1 内操作。
4 )存储池 1 内的温/冷数据定期(每周 1 次)通过 Snapraid 同步到存储池 2 中。除了 snapraid 同步、校验,及 s.m.a.r.t.扫描维护之外,其余时间原则上存储池 2 的硬盘休眠(省点电费,#doge )。

关于 HBA 卡和 12 盘位硬盘笼的信息我再去学习下,感谢~
关于 unRaid ,主要是看了 youtube 上一些 up 主的吐槽(譬如这个 https://www.youtube.com/@ZhangDaqi/search?query=unraid ),感觉好像槽点有点多、学习成本不低,所以也没特别关注了。
@ButcherHu #36 感谢回复!
Mergerfs 的实际体验是我特别想知道的,感谢提醒避坑~
1  2  3  4  5  6  7  8  9  10  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   941 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 41ms · UTC 22:22 · PVG 06:22 · LAX 15:22 · JFK 18:22
Developed with CodeLauncher
♥ Do have faith in what you're doing.