Вимога швидкості запису: можливості 1,1 Гб / с?

У нас буде машина, яка на пікових роботах повинна мати можливість просувати 50 ("писати голови") x 75 ГБ даних на годину. Це пікова продуктивність швидкості запису ~ 1100 МБ / с. Щоб отримати це з машини, потрібно дві лінії 10 Гбіт. Моє запитання - який сервер + технологія може обробляти / зберігати такий потік даних?

В даний час для зберігання даних ми працюємо з ZFS, хоча швидкість запису ніколи не була проблемою. (ми навіть не наближені до цих швидкостей) Чи буде ZFS (zfs на linux) варіантом? Нам також потрібно зберігати багато даних, "ІТ-путівник" пропонує десь приблизно 50-75 ТБ. Тому, ймовірно, це не всі SSD-диски, якщо ми не хочемо запропонувати своїй первістці.

Деякі доповнення на основі чудових відповідей:

• максимум - 50x75 Гб / год., в пік - менше 24 годин (швидше за все, <6 год.)
• Ми не очікуємо, що це станеться незабаром, швидше за все, ми будемо працювати 5-10x75GB / hour
• це попередньо-альфа-машина, проте потрібно дотримуватися вимог (навіть якщо у грі багато питань запитань)
• ми б використовували NFS як з'єднання з машини до сервера
• макет: генеруюча машина -> сховище (ця) -> (безпечний рейд 6) -> обчислити кластер
• тому швидкість читання не є суттєвою , але було б непогано використовувати її з обчислювального кластера (але це абсолютно необов'язково)
• швидше за все, це будуть великі файли даних (не багато маленьких)

Абсолютно ... ZFS в Linux - це можливість, якщо архітектовано правильно. Існує багато випадків поганого дизайну ZFS , але добре зроблено, ваші вимоги можуть бути задоволені.

Отже, головним визначальним фактором буде те, як ви підключаєтесь до цієї системи зберігання даних. Це НФС? CIFS? Як клієнти підключаються до сховища? Або обробка тощо проводиться в системі зберігання даних?

Заповніть ще кілька деталей, і ми можемо побачити, чи зможемо ми допомогти.

Наприклад, якщо це NFS і з синхронними кріпленнями, то, безумовно, можна масштабувати ZFS в Linux, щоб задовольнити потреби в швидкості запису і все-таки підтримувати вимогу довгострокової пам’яті. Чи є дані стислими? Як підключений кожен клієнт? Гігабітний Ethernet?

Редагувати:

Гаразд, я кусаю:

Ось специфікація, яка коштує приблизно 17 000 доларів - 23 тисячі доларів і вміщається в стійки 2U.

HP ProLiant DL380 Gen9 2U Rackmount
2 x Intel E5-2620v3 or v4 CPUs (or better)
128GB RAM
2 x 900GB Enterprise SAS OS drives 
12 x 8TB Nearline SAS drives
1 or 2 x Intel P3608 1.6TB NVMe drives

Ця настройка забезпечить вам 80TB простору, використовуючи апаратний RAID6 або ZFS RAIDZ2.

Оскільки основна увага приділяється продуктивності на основі NFS (якщо припустити синхронні записи), ми можемо легко поглинути все це за допомогою накопичувачів P3608 NVMe (смугастий SLOG). Вони можуть вміщувати 3 Гб / с в послідовних записах і мати достатньо високий показник витривалості, щоб постійно обробляти описане вами робоче навантаження. Приводи легко переробляються, щоб додати деякі захисти у випадку використання SLOG.

З робочим навантаженням NFS записи будуть об'єднані та передані на спінінг-диск. У Linux ми налаштовуємо це на флеш кожні 15-30 секунд. Прядильні диски могли б впоратися з цим і можуть отримати користь навіть, якщо ці дані є стислими.

Сервер можна розширити за допомогою ще 4 відкритих слотів PCIe та додаткового порту для двопортових адаптерів FLR 10GbE FLR. Таким чином, у вас є гнучкість у мережі.

Для такої надзвичайної швидкості запису я пропоную проти ZFS, BTRFS або будь-яку файлову систему CoW. Я б використовував XFS, який надзвичайно ефективний при великій / потоковій передачі.

Є багато інформації про відсутність інформації (як ви плануєте отримати доступ до цих даних? Важлива швидкість читання? Збираєтеся писати великими шматками? Тощо), щоб дати конкретні поради, проте деякі загальні поради:

• використовуйте XFS поверх необробленої секції або жирового об'єму LVM (не використовуйте тонкі томи)
• налаштуйте розмір ioblock, щоб ефективно впоратися з великими записами даних
• використовувати апаратну RAID-карту з кешеним записом керованого запису; якщо використання апаратного RAID не викликає сумнівів, використовуйте програмну схему RAID10 (уникаючи будь-якого режиму RAID на основі паритету)
• використання двох мережевих інтерфейсів 10Gb / s з LACP (агрегація посилань)
• не забудьте включити Jumbo Frames
• оскільки ви збираєтеся використовувати NFS, розглядайте можливість використання pNFS (v4.1) для збільшення масштабованості
• напевно багато інших речей ...

25 Гбіт / с Ethernet вже є межею мейнстриму, тоді як NVMe на базі PCIe легко завантажує цей трафік.

Для довідки. Нещодавно я створив невелике рішення для "захоплення журналу", використовуючи чотири регулярні сервери з двома xeon (HPE DL380 Gen9s у цьому випадку), кожен з 6-ти накопичувачами NVMe, я використовував IP через Infiniband, але ці NIC 25 / 40Gbps були б однаковими і ми забираємо до 8 Гбіт / с на сервері - працює ласощі.

В основному це недешево, але це дуже виконувати в наші дні.

Це не здається великою справою. Наш місцевий постачальник обладнання має це як стандартний продукт - очевидно, він може підштовхнути 1400 МБ / с, підтримуваних у режимі запису відеоспостереження, що має бути складніше, ніж ваші пікові вимоги.

(Посилання на конфігурацію 12 ГБ за замовчуванням, але вони відзначають, що 20x4TB також є варіантом. Ніякого особистого досвіду роботи з цим конкретним сервером моделі.)

Послідовне записування при швидкості 1100 Мб / с не є проблемою для сучасного обладнання. Анекдотично, моя домашня установка з накопичувачами для ноутбуків 8x5900 RPM, накопичувачами 2x15000 RPM та накопичувачами 2x7200 RPM підтримує 300 Мб / с з одноразовим навантаженням 16 Гб.

Мережа - це 10GbE з волоконними кабелями, 9000 MTU на Ethernet, а прикладним шаром є Samba 3.0. Сховище налаштовано в raid50 з трьома смужками на трьох 4-х дискових рейдах5 томах. Контролером є LSI MegaRAID SAS 9271-8i зі швидкістю до 6 Гбіт / с на порт (у мене є додатковий, більш повільний порт-множник).

Поговоріть з будь-яким досвідченим систематиком, і вони повинні мати можливість точно сказати, який саме контролер (і) та накопичувачі відповідають вашим вимогам.

Я думаю, ви можете спробувати з будь-яким контролером 12 Гбіт / с і налаштувати дві дзеркальні смуги з восьми 7200 обертів на хвилину кожного (майже будь-який диск). Запустіть 3-4 TCP-з'єднання, щоб наситити посилання, і якщо одна пара 10GbE-карт не може впоратися з ним, використовуйте чотири карти.

Щось дотичне, але подумайте про використання InfiniBand замість подвійних 10GbE-посилань. Ви можете отримати картки Infiniband 56Gbps досить дешеві або 100Gbps для не надто багато, а в Linux легко використовувати NFS з RDMA через IB, що дасть вам надзвичайно низьку затримку і майже теоретичну пропускну здатність швидкості лінії (якщо ваш базовий накопичувач може розберися із цим). Вам не потрібен комутатор, лише дві карти InfiniBand та кабель прямого приєднання (або волоконний кабель InfiniBand, якщо вам потрібні більші відстані).

Однопортова карта Mellanox 56Gbps (8x PCIe 3.0), як MCB191A-FCAT, становить менше 700 баксів, а двометровий мідний кабель прямого приєднання - приблизно 80 доларів.

У всіх випадках використання продуктивність, як правило, продуває 10GbE з води. Немає жодних недоліків, якщо вам не потрібно отримати доступ до сервера з безлічі різних клієнтів, які не можуть усі використовувати InfiniBand (і навіть тоді комутатори Mellanox можуть передати 10 Гбіт і 40 Гбіт на ІБ, але це трохи більше інвестицій, звичайно).

Зробити це за допомогою ZFS можливо, проте, подумайте про використання FreeBSD, оскільки FreeBSD має швидший мережевий стек. Це дозволить отримати 100 Гбіт на одній машині.

1100 Мбіт / с звучить як багато, але реально досягти цього можна, використовуючи лише звичайні жорсткі диски. Ви кажете, що вам потрібно 75 ТБ місця, щоб ви могли використовувати 24 8 ТБ жорстких дисків у дзеркалах. Це дасть вам 12-кратну швидкість запису на одному приводі та 24-кратну швидкість зчитування диска. Оскільки ці накопичувачі мають більшу швидкість запису, ніж 100 Мбіт / с, це може легко працювати з пропускною здатністю. Не забудьте отримати SMR-накопичувачі, оскільки вони мають дуже повільні швидкості запису.

ZFS створює контрольні суми для кожного блоку. Це реалізовано однонитковим. Таким чином, у вас повинен бути процесор з досить швидкою тактовою частотою, щоб не блокувати.

Однак точні деталі реалізації сильно залежать від деталей.

Ми прив’язали дані демпінгу 10G NIC до кластера Gluster над їхнім клієнтом запобіжників. Потрібно трохи налаштувати трохи ви не повірите, що ефективність, яку вона може досягти, починаючи з 3.0.