seedbox hosting
种子盒和大容量存储
大容量存储工作负载需要三样东西，而大多数虚拟服务器都搞错了：真实容量而价格不像NVMe那样随容量增长，网络端口不会在使用的瞬间被限速，以及一个能对其内容进行校验的文件系统。VAULT基于ZFS构建，在企业级硬盘前有NVMe缓存层，因此元数据操作保持快速，而大容量数据则存放在便宜的机械硬盘上。
为什么这个配置
带有小时快照的ZFS保护你免受自己脚本的伤害，而且更大规格的无限流量让你无需进行复杂的计算。阿姆斯特丹和布加勒斯特在我们覆盖区域内拥有最便宜的流量。
我们会部署什么
规模确定
两个数字：库大小和种子热播的数量。VAULT支持32 TB，所以从库大小开始计算，并增加25%——ZFS在池使用率超过约80%时性能明显下降。内存用于ARC，每TB 1 GB对媒体是合理的规则，因为你需要缓存的是元数据而不是负载。16 GB可以索引16 TB的库，64 GB则留出ARC空间给热集。两个核心处理客户端；仅在重新加密或归档验证时增加更多。
种子库的池布局
播种是对一个大文件集中小片段的随机读取。RAIDZ2最大化可用容量，每个vdev大致提供一个磁盘的随机IOPS。镜像将容量减半，但IOPS翻倍。在NVMe缓存前置下，RAIDZ2使用两个vdev通常是超过10 TB库的正确取舍。设置atime=off、compression=lz4、recordsize=1M，并保持sync=standard。SLOG在这里没有帮助，因为种子写入是异步的。注意池老化后的碎片化：在80%以上使用率的池中大量改动会降低顺序读取性能，这比容量耗尽更早发生。
无限流量，及其实际限制
千兆无限端口一个月可移动约300 TB，如果保持饱和的话。但几乎没人能做到，因为瓶颈更早出现在别处。对等连接数和连接跟踪首先达到conntrack表限制——在你责怪磁盘之前，先提高nf_conntrack_max和哈希大小。然后每个种子的片段验证在重新检查时会消耗CPU进行哈希计算。然后池的随机IOPS耗尽。便宜的容量只有在布局能服务它时才划算，所以NVMe缓存的大小应能容纳活跃的种子集，而不是整个库。
常见问题
- 在媒体池上启用ZFS去重。去重表永久驻留在内存中，媒体文件很少去重，且以后删除它意味着重写整个数据集。使用压缩并关闭去重。
- 保留recordsize为128K。大型顺序媒体文件需要recordsize=1M——更少的间接块，更少的元数据，更好的顺序吞吐量。在写入数据之前先对数据集进行设置，因为它只适用于新块。
- 将无限流量视为无限IOPS。端口是无限的，但池不是。同时有上千个种子在播种是一个随机读取工作负载，RAIDZ每个vdev只提供一个磁盘的IOPS。
调整配置
- 存储和加密 — ZFS with hourly snapshots · €7
- 地址和传输 — Uplink upgrade to 10 Gbps · €19
- 控制面板 — No control panel · 包含