Розподілена файлова система зберігання - яка з них / чи є готовий до використання продукт?

З Hadoop та CouchDB у всьому блозі та пов’язаних новинах, що є дистрибутивним відмовою зберігання (двигун), який насправді працює.

• CouchDB насправді не має вбудованих функцій дистрибуції, наскільки мені відомо, клею для автоматичного розподілу записів або навіть цілих баз даних просто не вистачає.
• Hadoop, здається, дуже широко використовується - принаймні, він отримує хорошу пресу, але все ж має єдину точку відмови: NameNode. Крім того, це можливо лише через FUSE, я розумію, що HDFS насправді не є основною метою Hadoop
• У GlusterFS немає спільного поняття нічого, але останнім часом я прочитав кілька публікацій, які призводять мене до думки, що це не так стабільно
• У Luster також є одна точка відмови, оскільки він використовує виділений сервер метаданих
• Здається, Ceph є гравцем на вибір, але домашня сторінка стверджує, що вона все ще знаходиться на стадії альфа.

Отже, питання в тому, яка розподілена файлова система має такий набір функцій (немає конкретного порядку):

• POSIX-сумісний
• просте додавання / видалення вузлів
• концепція спільного - нічого
• працює на дешевому апаратному забезпеченні (процесори AMD Geode або VIA Eden)
• вбудована автентифікація / авторизація
• мережева файлова система (я хотів би мати можливість її одночасно монтувати на різних хостах)

Добре мати:

• локально доступні файли: я можу взяти вузол вниз, змонтувати розділ за допомогою стандартної локальної файлової системи (ext3 / xfs / що завгодно ...) і все одно отримати доступ до файлів

Я не шукаю розміщених додатків, а щось, що дозволить мені сказати 10 ГБ кожної з наших апаратних коробок і мати таке сховище в нашій мережі, яке легко можна встановити на безлічі хостів.

Я думаю, що вам доведеться відмовитись від вимоги POSIX, тому дуже мало систем реалізують це - насправді навіть NFS насправді не є (блокування думок тощо), і це не має надмірності.

Будь-яка система, яка використовує синхронну реплікацію, буде льодовиково повільною; будь-яка система, яка має асинхронну реплікацію (або "можливу послідовність"), порушує правила POSIX і не поводиться як "звичайна" файлова система.

Я не можу говорити з рештою, але ви, мабуть, заплутані між "механізмом розподіленого зберігання" та "розподіленою файловою системою". Вони не одне і те ж, вони не повинні помилятися на одне і те ж, і вони ніколи не будуть однаковою. Файлова система - це спосіб відстежувати, де розташовані речі на жорсткому диску. Двигун зберігання даних, як hadoop, - це спосіб відстежувати фрагмент даних, ідентифікований ключем. Концептуально, не велика різниця. Проблема полягає в тому, що файлова система - це залежність двигуна зберігання ... зрештою, їй потрібен спосіб запису на блоковий пристрій, чи не так?

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

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

Наприклад, Ocfs2 має журнал для кожної машини в кластері, яка збирається монтувати розділ. Отже, скажімо, у вас є чотири веб-машини, і коли ви робите цей розділ за допомогою mkfs.ocfs2, ви вказуєте, що всього буде шість машин, щоб ви могли собі трохи відрости. Кожен з цих журналів займає місце, що зменшує кількість даних, які ви можете зберігати на дисках. Тепер, скажімо, вам потрібно масштабувати до семи машин. У цій ситуації потрібно зняти цілекластер (тобто відключіть усі розділи ocfs2) та використовуйте утиліту tunefs.ocfs2 для створення додаткового журналу за умови, що є вільний простір. Тоді і лише тоді ви можете додати сьому машину до кластеру (що вимагає, щоб ви поширювали текстовий файл до решти кластеру, якщо ви не використовуєте утиліту), повертаєте все назад, а потім монтуєте розділ на всі сім машини.

Бачите, що я маю на увазі? Це повинно бути високою доступністю, що повинно означати "завжди в Інтернеті", але саме там у вас є маса простоїв ... і не дай бог, що ви переповнені на диску. Вам НЕ хочеться бачити, що відбувається, коли ви переповнюєте ocfs2.

Майте на увазі, що evms, який раніше був «кращим» способом управління кластерами ocfs2, пішов шляхом птаха Додо на користь clvmd та lvm2. (І хороша загадка на evms.) Також серцебиття швидко перетворюється на проект зомбі на користь стека Openais / пейсмейкер. (Убік: Виконуючи початкову конфігурацію кластера для ocfs2, ви можете вказати 'pcmk' як двигун кластера на відміну від серцебиття. Ні, це не документально.)

Для чого це варто, ми повернулися до nfs, якими керує пейсмейкер, тому що кілька секунд простою або кілька скинутих пакетів tcp, коли кардіостимулятор мігрує частку nfs на іншу машину, є тривіальною порівняно з кількістю простоїв, які ми бачили за базовий спільні операції зберігання, такі як додавання машин при використанні ocfs2.

Я, можливо, не розумію ваших вимог, але ви подивилися на http://en.wikipedia.org/wiki/List_of_file_systems#Distributed_file_systems

Просто кинути сюди мої 0,02 євро: чи не може OpenAFS робити те, що ви хочете?

Погляньте на чирп http://www.cse.nd.edu/~ccl/software/chirp/ та папугу http://www.cse.nd.edu/~ccl/software/parrot/

Як щодо Xtreemfs ? версія 1.4 (листопад 2012 р.) вважається якістю виробництва.

Він сумісний з POSIX і має чудову автоматичну стійкість до відмов.

Luster дозволяє безліч запасів метаданих в активній / пасивній конфігурації для надмірності, тому немає жодної точки відмови.

OCFS2, можливо, варто також переглянути.

Зауважте, що вирішення вимоги до багаторазового одночасного доступу до мережі дає можливість перейти на щось на зразок iSCSI або навіть cifs чи nfs. Мінус полягає в тому, що вам доведеться "вирізати" шматки вашого uberArray в укуси для кожного сервера, який потребує місця.

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

Запитання з питання, чи справді вам потрібна семантика POSIX, є хорошим початком. Семантика «файлової системи», що не є POSIX, може бути набагато гнучкішою, що призводить до набагато надійніших систем.

Якщо це застаріле додаток, мені дуже цікаво, чому сучасну розподілену файлову систему можна вважати найкращим рішенням.

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

Вам справді, абсолютно позитивно потрібна семантика POSIX? Життя стає набагато простішим, якщо ви можете користуватися користувальницьким сховищем даних. У нас є внутрішньо написана сховище даних, яка фактично є дуже великим сховищем розподілених ключових значень. Ви зберігаєте файл у ньому і отримуєте маркер назад. Якщо ви хочете повернути файл, дайте йому маркер, який вам було надано раніше. Він розповсюджується, не ділиться нічим, дані реплікуються три рази, вузли можна додавати та видаляти за бажанням, як серверів зберігання даних, так і керуючих серверів.

У Luster також є одна точка відмови, оскільки він використовує виділений сервер метаданих

Luster призначений для підтримки відмови, і MDS / MDT / OSS може мати ряд адрес, до яких можна зв’язатися, серцебиття може використовуватися для переміщення служби навколо.

Будьте в курсі, що в деяких останніх версіях виникли проблеми, коли, здається, працює деактивація, але дані все ще зберігаються на диску, однак захист подвійного кріплення повинен був допомогти (крім цікавих проблем, які виникли) ....

Я рекомендую вам використовувати MooseFS (Fault tolerant, Scaling-out, Network розподілена файлова система). Це сумісність з POSIX, і з моменту випуску 1.6 MooseFS пропонує просту аутентифікацію / авторизацію, схожу на NFS. Див. Також вимоги до апаратних засобів .