CrestVPS

seedbox hosting

Сідбокси та масове зберігання

Терабайти, які залишаються дешевими, та порт, який залишається відкритим.

Що б ми розгорнули

49,63 EUR/міс

70,90 EUR30% щорічно

Масовим навантаженням зберігання потрібні три речі, які більшість віртуальних серверів роблять неправильно: реальна ємність за ціною, що не масштабується як NVMe, мережевий порт, який не тротлиться в момент використання, та файлова система, здатна контролювати контрольні суми. VAULT побудовано на ZFS з шаром NVMe-кешу перед корпоративними дисками, тому операції з метаданими залишаються швидкими, поки основний обсяг даних знаходиться на дешевих HDD.

Чому ця конфігурація

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 на вдев. Дзеркала вдвічі зменшують ємність і множать IOPS. З NVMe-кешем попереду RAIDZ2 у двох вдевах зазвичай є правильним компромісом для бібліотеки понад 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 одного диска на вдев.

Налаштуйте машину

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