Red Hat Global File System
Red Hat Global File System (GFS) — POSIX-сумісна кластерна файлова система, що забезпечує організацію файлів в файлову систему за допомогою менеджера томів (Logical Volume Manager, LVM); працює на серверах Red Hat Enterprise Linux, підключених до мережі зберігання даних (SAN). GFS належить до вільного програмного забезпечення.
Провідна (і перша) кластерна файлова система Linux, Red Hat GFS має найповніший набір функцій, найширше промислове впровадження та підтримку програмного забезпечення, найкраще співвідношення ціна/продуктивність ніж будь-яка кластерна файлова система Linux. Red Hat GFS дозволяє для серверів Red Hat Enterprise Linux одночасне читання і запис до мережевого сховища даних (SAN), досягаючи високої продуктивності і зменшуючи складність і накладні витрати на управління надлишковими копіями даних. Red Hat GFS не має єдиної точки збою, є поступово масштабованою від одного до ста серверів Red Hat Enterprise Linux, і працює з усіма стандартними додатками Linux.
Історія[ред. | ред. код]
Розробка GFS почалася в 1995 році професором Matthew O'Keefe в університеті Міннесоти. В цей час в університеті використовувався великомасштабний обчислювальний кластер, де породжувалася величезна кількість даних, які ефективно записувалися в центральне сховище даних. Для вирішення цієї проблеми Matthew O'Keefe, в той час професор університету Міннесоти, почав з групою студентів розробку GFS. Надалі він став керівником напряму Storage Strategy в Red Hat. Результатом цих зусиль стала поява кластерної файлової системи Red Hat GFS, яка випущена під ліцензією GPL. В даний момент GFS доступна тільки для Linux.
Внутрішня будова GFS[ред. | ред. код]
Global File System була створена як 64-бітова кластерна файлова система. Вона дозволяє декільком серверам здійснювати підключення до мережевого сховища даних (SAN) для доступу до загальних, спільно використовуваних файлів одночасно з допомогою стандартної UNIX / POSIX семантики файлової системи.
Файлова система GFS є журнальованою файловою системою. Для кожного вузла кластера заводиться свій власний журнал. Зміни метаданих у файловій системі записуються спочатку в журнал, а потім у файлову систему, як і в інших журнальованою файлових системах. У разі збою вузла, узгодженість файлової системи може бути відновлена шляхом повторення операцій з метаданими. Існує можливість визначити, чи будуть журналюватися тільки метадані, чи в журнал будуть потрапляти також дані вмісту файлів.
GFS зберігає дескриптор файлової системи в індексних дескрипторах (inodes), які виділяються динамічно за мірою необхідності (надалі називаються dynamic nodes або dinodes). Вони займають повний блок файлової системи (4096 байт — це стандартне значення розміру блоку файлової системи в ядрі Linux).У кластерній файловій системі кілька серверів звертаються до файлової системи в один і той же час, звідси випливає, що об'єднання декількох dinodes в одному блоці призведе до доступу до конкуруючих блоків і помилкового суперництва. Для ефективного розподілу місця і зменшення доступу до диска, дані файлів зберігаються безпосередньо всередині dinode, якщо файл досить малий для розміщення цілком у dinode. В цьому випадку необхідний тільки доступ до одного блоку для доступу до маленьких файлів. Якщо файл великий, то GFS використовує проксі структуру файлу. Всі покажчики в dinode мають однакову глибину. Існує лише три види покажчиків: прямі (direct), непрямі (indirect), або двічі непрямі (double indirect) покажчики. Висота дерева збільшується за мірою необхідності, наскільки це потрібно для зберігання файлу з даними.
Розширюване хешування («Extendible hashing», ExHash) використовується для збереження індексної структури для каталогів. Для кожного імені файлу мультибітний хеш зберігається як індекс у хеш-таблиці. Відповідний покажчик у таблиці вказує на листовий вузол. На кожен листовий вузол можуть посилатися кілька покажчиків. Якщо хеш-таблиця для листових вузлів стає недостатньою для зберігання структури каталогів, то розмір всієї хеш-таблиці подвоюється. Якщо розміру одного листового вузла недостатньо, то він поділяється на два вузли того ж розміру. Якщо є невелика кількість записів в каталозі, то інформація про нього зберігається всередині dinode блоку, як файл з даними. Така структура даних дозволяє виконати пошук в каталогах при кількості дискових операцій пропорційно глибині структури дерева «extendible[en]» хешування, яка досить пласка. Для великих каталогів з тисячами і мільйонами файлів потрібна невелика кількість дискових операцій для пошуку запису в каталозі.
Остання версія GFS 6.0 пропонує нові можливості, включаючи списки управління доступом до файлів (ACL), підтримку квотування, прямий ввід / вивід (для підвищення продуктивності баз даних), і динамічне збільшення файлової системи без відключення.
Масштабованість[ред. | ред. код]
Класична IT система складається зі служб і додатків, які працюють на окремих серверах і звичайно їхня робота обмежена конкретним сервером. Якщо обладнання, до якого прив'язаний індивідуальний додаток, більше не задовольняє вимогам, то програма може зіткнутися з проблемою нестачі пам'яті, процесорної потужності або дискового об'єму, які доступні в решті частини кластера. У противагу цьому, додатки, які можуть паралельно виконуватися на кластері зберігання, значно простіше масштабуються. У разі нестачі ресурсів, нові компоненти (сервер, дисковий масив) можуть бути легко інтегровані в систему для досягнення потрібної продуктивності. Спільне використання дискового пулу дозволяє не тільки відмовитися від трудомісткого дублювання даних на кілька серверів, але також надає зручні можливості масштабування. Зі зростаючими вимогами до обсягу дискового сховища, загальний дисковий масив може бути розширений і стане одразу доступний для всіх серверів.
Доступність (відмовостійкість)[ред. | ред. код]
Доступність системи в цілому є важливим аспектом у наданні IT послуг. Для отримання 3-го класу доступності (від 99% до 99,9%) необхідно усунути єдину точку збою. Для 4-го класу доступності (від 99,9% до 99,99%) необхідно мати кластер високої доступності, віддзеркалювання даних і другий центр обробки даних на випадок стихійного лиха. Служби повинні мати можливість працювати на декількох територіально розподілених серверах. Вихід з ладу одного сервера або цілого обчислювального центру не повинен вплинути на їх доступність, допускається тільки втрата доступності на короткий час. Кластер GFS може бути підключений до центрального сховища через SAN за допомогою резервних каналів вводу / виводу для подолання виходу з ладу одного з компонентів системи, таких як комутатори, адаптери HBA або кабелі. Резервування каналів вводу / виводу може бути досягнуто c використанням драйвера fibre channel для адаптера HBA або використовуючи GFS пул. На жаль, GFS кластер не має можливості дублювати інформацію між дисковими масивами з вузлового сервера, зате можна скористатися апаратним дублюванням, яке присутнє в досконалих дискових RAID масивах. Віддзеркалення з вузлового сервера в GFS кластері з'явиться трохи пізніше, в 2005 році з появою Cluster Logical Volume Manager (CLVM).
Менеджер блокувань, який є основою GFS, доступний у двох видах. Це спрощена версія — єдиний менеджер блокувань (Single Lock Manager, або SLM), який є єдиною точкою збою для цілої системи і версія з дублюванням — дубльований менеджер блокувань (Redundant Lock Manager, або RLM). Цей варіант дозволяє визначити кілька серверів з RLM, які можуть прозоро перехоплювати роль активного сервера блокувань у разі збою. До того ж, Red Hat Cluster Suite може бути використаний для забезпечення відмовостійкості додатків в GFS кластері.
Резервне копіювання без використання мережі[ред. | ред. код]
Резервування даних зазвичай відбувається з клієнтських машин (які найчастіше є серверами додатків) через локальну мережу (LAN) на виділений сервер резервного копіювання (за допомогою такого ПО, як Legato Networker[en] або Veritas Netbackup[fr]) або без використання мережі (LAN-free) через сервер додатків відразу на пристрій резервного копіювання. Через те, що кожний підключений сервер, який використовує кластерну файлову систему, має доступ до всіх даних, з'являється можливість перетворити будь-який сервер в сервер резервного копіювання. Сервер резервного копіювання дозволяє робити резервування інформації під час роботи, не надаючи впливу на сервера додатків. Зручно використовувати можливість формування знімка або клона тома GFS, використовуючи апаратні можливості дискового масиву. Такі знімки томів можуть бути підключені до сервера резервного копіювання для подальшого резервування. Щоб задіяти цю можливість, GFS містить можливість «заморозки» файлової системи для забезпечення узгодженого стану даних. «Заморожування» означає, що всі спроби доступу до файлової системи перериваються після операції скидання (sync[en]) файлової системи, яка гарантує, що всі метадані і дані узгоджено записані на сховище до формування знімка.
Бездисковий кластер з подільним кореневим розділом[ред. | ред. код]
Всі сервера в GFS кластері отримують доступ до даних через мережу зберігання даних (SAN), і для збільшення продуктивності можуть бути легко додані додаткові сервери. Отже, кожен сервер може розглядатися як черговий ресурс в пулі вільних серверів. Системні дані і образ операційної системи зберігається в загальнодоступному сховищі, тому сервери і сховище можуть розглядатися як незалежні один від одного. В результаті — це бездисковий кластер з подільним кореневим розділом, в якому жоден сервер не має локальних дисків, і завантаження операційної системи відбувається через SAN. Образи з додатками і операційною системою доступні, це означає що розділ root (/) для всіх вузлів кластера однаковий. Внаслідок чого отримуємо просте управління системою. Зміни вносяться один раз і відразу стають доступні для всіх серверів. Побудова бездискових кластерів з поділюваним кореневим розділом з використанням GFS є специфічним завданням і залежить від устаткування і версії ядра, і цю можливість можна реалізувати тільки за допомогою фахівців компанії Red Hat або партнерів Red Hat, таких як ATIX[en] GmbH.
Приклад впровадження: IP Tech AG[ред. | ред. код]
Використовуючи кластер Red Hat Enterprise Linux з Red Hat GFS, IP Tech досягла високої доступності та продуктивності. Якщо один із серверів вийде з ладу або додаток (наприклад, http або qmail[en]) зависне, то цей сервер може бути швидко перезапущений і включений назад у кластер без порушення працездатності сервісів на інших серверах. На додаток IP Tech використовує технологію GFS з поділюваним кореневим розділом, яка спрощує процес оновлення програмних продуктів і надає можливість розподіляти навантаження в кластері для статичних служб. Наприклад, коли на IP Tech починається спам атака, то вони швидко переводять частину вебсерверів на обслуговування поштових серверів і тим самим підтримують роботу пошти в робочому режимі, виявляють і протистоять спам-атаці, у той час коли всі сервери у кластері продовжують працювати. Вони можуть масштабувати інфраструктуру протягом декількох хвилин, використовуючи нові сервери і дискові масиви. Насамкінець, IP Tech виробляє регулярне резервне копіювання знімків томів GFS на певний момент часу, використовуючи окремий сервер в кластері. Цей підхід дозволяє робити резервування файлової системи GFS, не заважаючи роботі інших серверів.
Посилання[ред. | ред. код]
«RED HAT GLOBAL FILE SYSTEM» [Архівовано 26 травня 2012 у Wayback Machine.]
«Red_Hat_Enterprise_Linux-5-Global_File_System-en-US» [Архівовано 15 травня 2012 у Wayback Machine.]