CrestVPS

hospedagem seedbox

Seedboxes e armazenamento em massa

Terabytes que continuam baratos e uma porta que permanece aberta.

O que implantaríamos

€ 49,63/mês

€ 70,9030% anual

Cargas de trabalho de armazenamento em massa precisam de três coisas que a maioria dos servidores virtuais erram: capacidade real a um preço que não escala como NVMe, uma porta de rede que não é limitada no momento em que você a usa, e um sistema de arquivos que possa verificar o que armazena. VAULT é construído em ZFS com uma camada de cache NVMe na frente de drives empresariais, então operações de metadados permanecem rápidas enquanto o volume principal fica em discos baratos.

Por que essa configuração

ZFS com snapshots horários protege você dos seus próprios scripts, e tráfego não medido nos tamanhos maiores remove a aritmética da equação. Amsterdã e Bucareste têm o trânsito mais barato em nossa infraestrutura.

O que implantaríamos

PlanVAULT V2
vCPU6
RAM16 GB
Armazenamento6 TB
ImagemDebian 13 Trixie

Dimensionamento

Dois números: tamanho da biblioteca e quanto dela você semeia ativamente. VAULT atinge 32 TB, então comece pela biblioteca e adicione 25% — ZFS degrada visivelmente acima de aproximadamente 80% de ocupação do pool. RAM é para ARC, e 1 GB por TB continua uma regra justa para mídia, pois são os metadados que você quer em cache, não o payload. 16 GB indexam uma biblioteca de 16 TB, e 64 GB deixam espaço de ARC para o conjunto ativo. Dois núcleos lidam com o cliente; adicione mais apenas para re-criptografia ou verificação de arquivos.

Layout do pool para uma biblioteca de seed

Seeding é leitura aleatória de pequenos pedaços em um grande conjunto de arquivos. RAIDZ2 maximiza capacidade utilizável e dá aproximadamente IOPS de um disco por vdev. Espelhos reduzem a capacidade pela metade e multiplicam IOPS. Com cache NVMe na frente, RAIDZ2 em dois vdevs é geralmente o compromisso certo para uma biblioteca acima de 10 TB. Defina atime=off, compression=lz4, recordsize=1M, e mantenha sync=standard. Um SLOG não ajuda aqui porque escritas de torrent são assíncronas. Observe a fragmentação conforme o pool envelhece: alta rotatividade em um pool acima de 80% degrada leituras sequenciais muito antes da capacidade acabar.

Tráfego não medido, e onde ele realmente para

Uma porta gigabit não medida moverá aproximadamente 300 TB em um mês se você a mantiver saturada. Quase ninguém faz, porque os limites chegam antes e em outros lugares. O número de pares e o rastreamento de conexões atingem os limites da tabela conntrack primeiro — aumente nf_conntrack_max e o tamanho da hash antes de culpar o disco. Depois, a verificação de peças por torrent queima CPU em verificações de hash durante recheck. Então o pool fica sem IOPS aleatórios. Capacidade barata só compensa se o layout puder servi-la, então dimensione o cache NVMe para conter seu conjunto de seeding ativo, não a biblioteca inteira.

O que dá errado

  • Ativar deduplicação ZFS em um pool de mídia. A tabela de deduplicação vive em RAM permanentemente, arquivos de mídia raramente deduplicam, e removê-la depois significa reescrever todo o dataset. Use compressão e deixe deduplicação desligada.
  • Deixar recordsize em 128K. Arquivos de mídia sequenciais grandes querem recordsize=1M — menos blocos indiretos, menos metadados, melhor throughput sequencial. Defina isso no dataset antes de escrever dados, porque se aplica apenas a novos blocos.
  • Tratar não medido como IOPS ilimitados. A porta é não medida; o pool não é. Mil torrents semeando ao mesmo tempo é uma carga de leitura aleatória, e RAIDZ dá IOPS de um disco por vdev.

Ajuste a máquina

  • Armazenamento e criptografiaZFS com snapshots horários · € 7
  • Endereçamento e trânsitoUplink upgrade to 10 Gbps · € 19
  • Painel de controleSem painel de controle · Incluído