150 ТБ і росте, але як рости?

В даний час у моїй групі є два великі сервери зберігання даних, обидва NAS працюють з debian linux. Перший - це все-в-одному 24-диск-сервер (SATA), якому вже кілька років. У нас є два апаратні RAIDS, встановлені на ньому з LVM над ними. Другий сервер - це 64 диски, розділені на 4 корпуси, кожен апаратний RAID 6, підключений через зовнішній SAS. Ми використовуємо XFS з LVM над цим, щоб створити схожий на 100 ТБ сховище. Все це працює досить добре, але ми переростаємо ці системи. Побудувавши два таких сервери і все ще зростаючи, ми хочемо створити щось таке, що дозволяє нам більше гнучкості в плані майбутнього зростання, резервного копіювання, що краще поводиться при збої диска (перевірка більшої файлової системи може зайняти день і більше), і може стояти в сильному паралельному середовищі (думаю, невеликий комп'ютерний кластер). У нас немає підтримки системного адміністрування,

Отже, що ми прагнемо - це порівняно недороге, прийнятне рішення для зберігання продуктивності, яке дозволить забезпечити майбутній ріст і гнучку конфігурацію (думаю, ZFS з різними пулами, що мають різні експлуатаційні характеристики). Ми, мабуть, поза сферою єдиного NAS. Ми думали про комбінацію ZFS (наприклад, на openindiana) або btrfs на сервері з glusterfs, що працює над цим, якщо ми це робимо самі. На що ми зважимо, це просто кусати кулю та вкладати кошти в рішення для зберігання Isilon або 3Par.

Будь-які пропозиції чи досвід оцінюються.

Я сподіваюся, що це трохи допоможе. Я намагався не дати йому перетворитися на повну стінку тексту. :)

3Пар / Ісілон

Якщо ви можете і присвятите фіксовану кількість робочих годин тому, хто виконує роль адміністратора SAN і хочете насолоджуватися безболісним життям з нічним сном замість нічної роботи, то це я б пішов.

SAN дозволяє вам виконувати всі речі там, де одне «зберігання» обмежує вас (тобто підключити масивний флеш-масив із чистим сховищем та великий монстр 3par sata до того ж сервера), але вам також доведеться платити за це та підтримувати його добре. час, якщо ви хочете використовувати гнучкість.

Альтернативи

Амплідати

Плюси: масштабування, дешеве, розроблене з приємною концепцією і виділеними шашами кешу читання / запису Це насправді може бути найкращим для вас.

RisingTideOS

Їх цільове програмне забезпечення зараз використовується майже у всіх сховищах Linux, і це дозволяє трохи краще керувати, ніж могла звичайна Linux / gluster. (Imho) Комерційну версію, можливо, варто подивитися.

Gluster / btrfs

PRO: масштаби і "Цеглини" дають вам абстракційний шар, який дуже хороший для управління.

КОН: Перший був для мене загальним ПДФА. Це не було надійним, і невдачі могли бути або локальними до однієї цегли, або вивезти все. Тепер, коли RedHat контролюється, це насправді може перетворитися на щось працююче, і я навіть зустрів людей, які можуть приручити його так, щоб він працював роками. А друге все ще напів експериментальне. Зазвичай ФС потребує 3-4 років після того, як він "зроблений", поки він не буде перевіреним і надійним. Якщо ви дбаєте про дані, чому б ви коли-небудь вважали це? Якщо говорити про експериментальну, комерційна підтримка Ceph зараз майже не працює, але вам потрібно буде дотримуватися шару "RBD", FS ще недостатньо добре перевірений. Хочеться дати зрозуміти, що Сеф набагато привабливіший у перспективі. :)

ZFS

Про: Особливості, які безумовно вкладають цвях у труну інших речей. Ці функції добре розроблені (думаю, L2ARC) і стиснення / зменшення функції - це цікаво. Майте більше "кластерів для зберігання", тобто, маючи лише невеликі збої замість одного великого консолідованого буму

Con: Обслуговування багатьох невеликих програмних коробок замість реального сховища. Потрібно інтегрувати їх і витратити $$$ годин, щоб мати надійну настройку.

Маршрут XFS + LVM - це дійсно один з найкращих варіантів розширеного масштабного рішення для зберігання Linux за останні кілька років. Мені рекомендується, що ти вже там. Тепер, коли вам потрібно рости більше, у вас є ще кілька варіантів.

Як відомо, у великих виробників обладнання там є NAS-головки для їх зберігання. Це дійсно дасть вам одного постачальника, щоб працювати, щоб все це відбулося, і це працювало б досить добре. Вони легко входять у рішення (порівняно із самим собою), а їх ремонтопридатність нижча. Але вони коштують досить багато. З одного боку, у вас буде більше інженерних ресурсів для вирішення основних проблем, а не інфраструктурних проблем; з іншого боку, якщо ви схожі на більшість кафедр університету, я знаю, що влада є дуже дешевою, ніж платити за речі.

Йдучи маршрутом "Зробіть сам", ви вже добре оцінюєте доступні вам варіанти. ZFS / BTRFS - це очевидний шлях оновлення від XFS + LVM для масштабованого зберігання. Я б ухилявся від BTRFS, поки він не буде оголошений "стабільним" в основному ядрі Linux, що має бути зовсім скоро, коли кілька основних безкоштовних дистрибутивів використовують його як файлову систему за замовчуванням. Для ZFS я б рекомендував використовувати базу BSD, а не OpenIndiana, просто тому, що це було довше, і розроблені перегини (більше).

Gluster був розроблений для описаного тут випадку. Він може робити реплікацію, а також представляти єдиний віртуальний сервер з великою кількістю прикріпленого місця. Їх розподілені томи звучать саме те, що ви шукаєте, оскільки вони розповсюджують файли на всіх серверах зберігання даних на заявленому томі. Ви можете продовжувати додавати окремі сервери зберігання, щоб продовжувати розширювати видимий об'єм. Єдиний простір імен!

Гетча з Gluster полягає в тому, що він найкраще працює, коли ваші клієнти можуть використовувати клієнт Gluster для доступу до системи, а не CIFS або NFS. Оскільки ви використовуєте невеликий кластерно-обчислювальний кластер, можливо, ви просто зможете використовувати клієнт GlusterFS.

Ви на правильному шляху тут.

Наскільки я розумію, ви можете використовувати рішення SAN, засноване на Linux SCST + FibreChannel або infiniband, що зараз щось будує. В якості бази для LUN ви можете використовувати LVM поверх апаратних RAID і піклуватися про знімки / реплікації (взяти DRBD як приклад) нижче рівня файлової системи. Як файлова система я не знаю жодного хорошого рішення для стиснення, оскільки я ставлю ESXi поверх вузлів, тому сховищами даних керує ESX одночасно FS. Я думаю, що GFS2 може працювати з цим середовищем, але я не на 100% впевнений, як ви повинні перевірити свої точні вимоги. У будь-якому випадку, коли у вас є надійний SAN під своїми вузлами, зробити це досить просто.