Що саме робить Gluster?

Останні 2 дні я грав з глюстером і задавав питання тут і в їхній системі запитань. Я дійсно не розумію деяких речей. Я бачу, як люди говорять такі речі

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

або

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

Оскільки я монтую віддалений об'єм сервера до клієнта (клієнтів), як глюстер обробляє несправність серверного вузла, з якого змонтовано томи? З того, що я спробував папку на клієнті, де було встановлено гучність, стає недоступним, і мені потрібно використовувати umount, щоб розблокувати його. А після цього немає вмісту з сервера.

Це, в основному, те, що я не бачу в жодних поясненнях: що відбувається, коли серверний вузол виходить з ладу і чи можливо реально копіювати вміст, як це робиться унісон чи rsync?

Нещодавно ми почали досліджувати GlusterFS для власного використання, тому мені це питання було цікавим. Gluster використовує те, що називається "перекладачами" на клієнті FUSE для обробки способу зберігання даних. Тут викладено кілька видів перекладачів:

http://www.gluster.com/community/documentation/index.php/GlusterFS_Translators_v1.3

Той, про кого ви конкретно запитуєте, називається перекладачем автоматичної реплікації файлів або AFR, тут детально висвітлено:

http://www.gluster.com/community/documentation/index.php/Understanding_AFR_Translator

Дивлячись на вихідний код, виявляється, що дані фактично записуються у вузли одночасно, набагато краще, ніж rsync!

Щодо виходу із ситуації з ладом, я знайшов одну цікаву ноту. Система Gluster відрізняється від Ceph тим, що вона не активно усвідомлює зміни стану реплікації і повинна бути "запущена". Отже, якщо ви втратите вузол у своєму кластері, вам потрібно шукати кожен файл, щоб Gluster пересвідчився у його копії:

http://www.gluster.com/community/documentation/index.php/Gluster_3.2:_Triggering_Self-Heal_on_Replicate

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

Маючи лише 2 вузли, що реплікуються, gluster не сильно відрізняється, ніж автоматичний скрипт rsync. Речі дійсно стають цікавими лише після того, як у вас є 4 або більше вузла зберігання - ваші клієнтські машини бачать простір, але складові файли розповсюджуються по всіх вузлах зберігання (цегли). Це означає, що якщо ваші 4 сервери мають 10 ТБ локального простору, ваші клієнтські машини можуть бачити єдиний простір імен у 20 ТБ (реплікацію або 40 ТБ незахищеного сховища).

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

Ви описуєте несподівану поведінку - я би порадив #gluster на irc.freenode.net або gluster-users@gluster.org або http://community.gluster.org/

-John Mark Gluster Community Guy

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

Однак якщо клієнт встановив його за допомогою IP / DNS іншого сервера, то обсяг все ще буде онлайн для цього клієнта. Однак читання / запис не перейде до невдалого / розбитого екземпляра.