Obciążenia magazynowe wymagają trzech rzeczy, których większość wirtualnych serwerów nie oferuje: realnej pojemności w cenie, która nie skaluje się jak NVMe, portu sieciowego, który nie jest ograniczany w momencie użycia, oraz systemu plików, który może sumować kontrolnie swoje dane. VAULT jest zbudowany na ZFS z warstwą cache NVMe przed dyskami enterprise, więc operacje na metadanych pozostają szybkie, podczas gdy dane masowe leżą na tanich talerzach.

Dlaczego ta konfiguracja

ZFS z godzinowymi snapshotami chroni Cię przed Twoimi własnymi skryptami, a nielimitowany ruch w większych rozmiarach usuwa rachunki z równania. Amsterdam i Bukareszt mają najtańszy transit w naszym zasięgu.

Co byśmy wdrożyli

PlanVAULT V2

vCPU6

RAM16 GB

Dysk6 TB

Obraz systemuDebian 13 Trixie

Rozmiar

Dwie liczby: rozmiar biblioteki i ile z niej seedujesz na gorąco. VAULT osiąga 32 TB, więc zacznij od biblioteki i dodaj 25% — ZFS zauważalnie degradował powyżej około 80% zapełnienia puli. RAM jest dla ARC, a 1 GB na TB pozostaje dobrą zasadą dla multimediów, ponieważ chcesz cache'ować metadane, nie payload. 16 GB indeksuje bibliotekę 16 TB, a 64 GB zostawia miejsce ARC dla gorącego zbioru. Dwa rdzenie obsługują klienta; dodaj więcej tylko przy re-encji lub weryfikacji archiwum.

Układ puli dla biblioteki seedującej

Seedowanie to losowe odczyty małych kawałków z dużego zbioru plików. RAIDZ2 maksymalizuje użyteczną pojemność i daje mniej więcej jeden dysk losowych IOPS na vdev. Mirrors halve pojemność i mnożą IOPS. Z cache NVMe z przodu, RAIDZ2 w dwóch vdevach jest zwykle właściwym kompromisem dla biblioteki powyżej 10 TB. Ustaw atime=off, compression=lz4, recordsize=1M i trzymaj sync=standard. SLOG nie pomaga tutaj nic, bo zapisy torrentowe są asynchroniczne. Obserwuj fragmentację w miarę starzenia się puli: ciężki churn na puli utrzymywanej powyżej 80% degraduje odczyty sekwencyjne na długo przed wyczerpaniem pojemności.

Nielimitowany ruch i gdzie faktycznie się kończy

Nielimitowany port gigabitowy przesunie w miesiącu mniej więcej 300 TB, jeśli utrzymasz go nasyconym. Prawie nikt tego nie robi, bo limity pojawiają się wcześniej i gdzie indziej. Liczba peerów i śledzenie połączeń najpierw uderzają w limity tablicy conntrack — podnieś nf_conntrack_max i rozmiar hasha, zanim obwinisz dysk. Potem weryfikacja kawałków na torrent spala CPU na haszowaniu podczas rechecku. Potem pula kończy się na losowych IOPS. Tania pojemność płaci się tylko, jeśli układ może ją obsłużyć, więc rozmiar cache NVMe trzymaj dla aktywnego zbioru seedującego, nie całej biblioteki.

Co może pójść źle

Włączanie dedup w ZFS na puli multimediów. Tabela dedup żyje w RAM permanentnie, pliki multimedialne rzadko się deduplikują, a usunięcie jej później oznacza przepisanie całego datasetu. Użyj kompresji i zostaw dedup wyłączony.
Zostawienie recordsize na 128K. Duże sekwencyjne pliki multimedialne chcą recordsize=1M — mniej bloków pośrednich, mniej metadanych, lepsza przepustowość sekwencyjna. Ustaw to na datasetcie przed zapisem danych, bo dotyczy tylko nowych bloków.
Traktowanie nielimitowanego jako nielimitowanych IOPS. Port jest nielimitowany; pula nie. Tysiąc torrentów seedujących naraz to obciążenie losowymi odczytami, a RAIDZ daje IOPS jednego dysku na vdev.

Dostrojenie maszyny

Pamięć i szyfrowanie — ZFS with hourly snapshots · 7 €
Adresacja i tranzyt — Uplink upgrade to 10 Gbps · 19 €
Panel sterowania — No control panel · W zestawie

Seedboxy i magazyn masowy

Dlaczego ta konfiguracja

Co byśmy wdrożyli

Rozmiar

Układ puli dla biblioteki seedującej

Nielimitowany ruch i gdzie faktycznie się kończy

Co może pójść źle

Dostrojenie maszyny

Stworzone dla konkretnych zadań

Hosting serwerów gier

VPS do tradingu i niskich opóźnień

Prywatne punkty końcowe VPN i proxy

Węzły robocze Kubernetes

Inferencja AI i fine-tuning

Reseller hostingu