CrestVPS

seedbox-хостинг

Сидбоксы и оптовое хранилище

Терабайты, которые остаются дешёвыми, и порт, который остаётся открытым.

Что бы мы развернули

49,63 €/мес

70,90 €30% ежегодно

Оптовым хранилищам нужно три вещи, которые большинство виртуальных серверов делают неправильно: реальная ёмкость по цене, не растущей как NVMe, сетевой порт, который не режется в момент использования, и файловая система, способная проверять контрольные суммы. VAULT построен на ZFS с NVMe-кэшем перед enterprise-дисками, так что операции с метаданными остаются быстрыми, а основная масса лежит на дешёвых дисках.

Почему такая конфигурация

ZFS с почасовыми снапшотами защищает от своих же скриптов, а безлимитный трафик на больших тарифах убирает арифметику из уравнения. В Амстердаме и Бухаресте самый дешёвый транзит в нашей сети.

Что бы мы развернули

PlanVAULT V2
vCPU6
RAM16 GB
Хранилище6 TB
ОбразDebian 13 Trixie

Размер

Два числа: размер библиотеки и то, сколько из неё раздаётся горячо. VAULT достигает 32 ТБ, так что отталкивайтесь от библиотеки и добавляйте 25% — ZFS заметно деградирует при заполнении пула выше примерно 80%. RAM нужна под ARC, и 1 ГБ на ТБ остаётся разумным правилом для медиа, поскольку кэшируются метаданные, а не данные. 16 ГБ индексируют библиотеку на 16 ТБ, а 64 ГБ оставляют место под ARC для горячего набора. Два ядра обслуживают клиента; добавляйте только под пере-шифрование или проверку архива.

Раскладка пула для раздающей библиотеки

Раздача — это случайные чтения мелких кусков из большого набора файлов. RAIDZ2 максимизирует полезную ёмкость и даёт примерно один диск случайных IOPS на vdev. Зеркала вдвое уменьшают ёмкость и умножают IOPS. С NVMe-кэшем спереди RAIDZ2 в двух vdev обычно правильный компромисс для библиотеки свыше 10 ТБ. Установите atime=off, compression=lz4, recordsize=1M и оставьте sync=standard. SLOG здесь не помогает, так как записи торрентов асинхронные. Следите за фрагментацией по мере старения пула: интенсивная замена данных на пуле выше 80% ухудшает последовательные чтения задолго до исчерпания ёмкости.

Безлимитный трафик и где он реально кончается

Безлимитный гигабитный порт за месяц перегонит примерно 300 ТБ при полной загрузке. Почти никто так не делает, потому что ограничения приходят раньше и с других сторон. Количество пиров и трекинг соединений упираются в лимиты conntrack — поднимите nf_conntrack_max и размер хэша до того, как винить диск. Затем проверка кусков тратит CPU на хэши при речеке. Потом пул кончается на случайных IOPS. Дешёвая ёмкость окупается только если раскладка её обслуживает, так что размер NVMe-кэша под активный раздающий набор, а не под всю библиотеку.

Что идёт не так

  • Включение дедупликации ZFS на медиа-пуле. Таблица дедупликации живёт в RAM постоянно, медиа-файлы редко дедуплицируются, а её удаление требует перезаписи всего датасета. Используйте сжатие и оставьте дедупликацию выключенной.
  • Оставление recordsize на 128K. Большие последовательные медиа-файлы требуют recordsize=1M — меньше косвенных блоков, меньше метаданных, лучше последовательная производительность. Установите его на датасете до записи данных, потому что он применяется только к новым блокам.
  • Отношение к безлимиту как к неограниченным IOPS. Порт безлимитный, а пул нет. Тысяча одновременных сидов — это нагрузка случайного чтения, а RAIDZ даёт IOPS одного диска на vdev.

Настройте машину

  • Хранилище и шифрованиеZFS with hourly snapshots · 7 €
  • Адресация и транзитUplink upgrade to 10 Gbps · 19 €
  • Панель управленияNo control panel · Включено