CrestVPS

hosting seedbox

Seedbox e storage bulk

Terabyte che restano economici e una porta che resta aperta.

Cosa implementeremmo

49,63 €/mese

70,90 €30% annuale

I carichi di lavoro di storage bulk richiedono tre cose che la maggior parte dei server virtuali sbaglia: capacità reale a un prezzo che non scala come NVMe, una porta di rete che non viene limitata appena la usi, e un filesystem in grado di verificare i checksum di ciò che contiene. VAULT è costruito su ZFS con un livello di cache NVMe davanti a dischi enterprise, così le operazioni di metadata restano veloci mentre il bulk poggia su dischi economici.

Perché questa configurazione

ZFS con snapshot orari ti protegge dai tuoi stessi script, e il traffico illimitato sulle taglie più grandi elimina l'aritmetica dall'equazione. Amsterdam e Bucarest hanno il transito più economico nella nostra rete.

Cosa implementeremmo

PlanVAULT V2
vCPU6
RAM16 GB
Storage6 TB
ImmagineDebian 13 Trixie

Dimensionamento

Due numeri: dimensione della libreria e quanto di essa vuoi tenere attivo. VAULT arriva a 32 TB, quindi parti dalla libreria e aggiungi il 25% — ZFS degrada notevolmente oltre circa l'80% di riempimento del pool. La RAM serve per ARC, e 1 GB per TB rimane una regola equa per i media, poiché sono i metadata che vuoi in cache, non il payload. 16 GB indicizzano una libreria da 16 TB, e 64 GB lasciano spazio ARC per il set attivo. Due core gestiscono il client; aggiungine di più solo per la ri-encryption o la verifica degli archivi.

Layout del pool per una libreria in seed

Il seeding è letture casuali di piccoli pezzi su un ampio insieme di file. RAIDZ2 massimizza la capacità utilizzabile e dà circa gli IOPS casuali di un disco per vdev. I mirror dimezzano la capacità e moltiplicano gli IOPS. Con la cache NVMe davanti, RAIDZ2 su due vdev è di solito il giusto compromesso per una libreria oltre 10 TB. Imposta atime=off, compression=lz4, recordsize=1M, e mantieni sync=standard. Un SLOG qui non aiuta nulla perché le scritture dei torrent sono asincrone. Osserva la frammentazione mentre il pool invecchia: un churn intenso su un pool mantenuto sopra l'80% degrada le letture sequenziali molto prima che la capacità si esaurisca.

Traffico illimitato, e dove si ferma davvero

Una porta gigabit illimitata muoverà circa 300 TB in un mese se la tieni satura. Quasi nessuno lo fa, perché i limiti arrivano prima e altrove. Il conteggio peer e il connection tracking colpiscono per primi i limiti della tabella conntrack — alza nf_conntrack_max e la dimensione della hash table prima di dare la colpa al disco. Poi la verifica dei pezzi per torrent brucia CPU sui controlli hash durante il recheck. Poi il pool esaurisce gli IOPS casuali. La capacità economica paga solo se il layout può servirlo, quindi dimensiona la cache NVMe per contenere il tuo set attivo di seed piuttosto che l'intera libreria.

Cosa va storto

  • Abilitare la deduplicazione ZFS su un pool di media. La tabella di dedup vive in RAM permanentemente, i file media raramente si deduplicano, e rimuoverla in seguito significa riscrivere l'intero dataset. Usa la compressione e lascia la dedup disattivata.
  • Lasciare recordsize a 128K. I file media grandi e sequenziali vogliono recordsize=1M — meno blocchi indiretti, meno metadata, migliore throughput sequenziale. Impostalo sul dataset prima di scrivere dati, perché si applica solo ai nuovi blocchi.
  • Trattare l'illimitato come IOPS illimitati. La porta è illimitata; il pool no. Mille torrent in seed contemporaneamente sono un workload di letture casuali, e RAIDZ ti dà gli IOPS di un solo disco per vdev.

Configura la macchina

  • Storage e crittografiaZFS with hourly snapshots · 7 €
  • Indirizzi e transitoUplink upgrade to 10 Gbps · 19 €
  • Pannello di controlloNo control panel · Incluso