Розподілена файлова система: опис, особливості, переваги

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

Основи мережевих БД

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

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

Існує кілька РФС, які розрізняються в додатку, інтерфейс і протоколі, а також різні функції, такі як кешування, ведення журналу, багатоканальне використання в локальних мережах. Оскільки пропускна здатність розподілених файлових систем для кластерів надзвичайно низька, ці програми мають спеціальні системи зі швидкостями передачі понад 100 МБ/с. До них відносяться Глобальна система (GFS) і проприетарная загальна система (GPFS).

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

Прикладами є:

  • Мережна файлова система (NFS).
  • Загальна файлова система інтернету (CIFS), розширення блоки повідомлень сервера (SMB).
  • Протокол подачі Apple (AFP) Apple.
  • Основний протокол NetWare (NCP) від Novell.
  • Відомими реалізаціями РФС є:

  • DFS в ОС Windows від Microsoft. Розподілена файлова система DFS зі стандартом Microsoft в серверних операційних систем. Вона вперше з’явилася в Windows NT4 і була відправлена з Windows 2000 Server. У Windows Server 2003 на сервер були додані поліпшення, такі як кілька коренів DFS.
  • AFS Andrew File System, для яких існує декілька виробників у рамках проекту «Розподілене обчислювальне середовище».
  • DCE Консорціуму Open Group в якості подальшої розробки для AFSCoda, розроблена в Університеті Карнегі-Меллоналоск.
  • BeeGFS / FhGFS для кластерів і додатків HPCGlusterFS, для всіх сумісних з POSIX операційних систем.
  • Файлова система Hadoop пропонує об’єкти, блок і сховище файлів, частина ядра Linux, LGPL.XtreemFS, відмовостійкий РФС з POSIX-сумісних інтерфейсом.
  • Файлова система Google (GFS, GoogleFS) від Google, заснована на Linux, оптимізована для високої пропускної здатності даних.
  • Порівняння розподілених файлових систем.

    Обслуговування і види системних послуг

    Така система надає наступні послуги:

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

  • Прозорість. Клієнти розподіленої файлової системи DFS не повинні знати кількість або розташування файлових серверів та пристроїв зберігання. Безліч файлових серверів забезпечують продуктивність, масштабованість, надійність та прозорість доступу.
  • Як локальні, так і віддалені файли повинні бути доступні однаково. Система повинна автоматично знайти доступний і перенести його на сайт клієнта. Ім’я файлу не повинно вказувати на місце розташування файлу. Воно не повинне змінюватися при переході з одного сайту на інший. Якщо файл реплікується на декількох вузлах, то наявність декількох копій та їх місцезнаходження повинні бути приховані від клієнтів.
  • Мобільність автоматично приводить в дію користувача середовище, наприклад, домашній каталог користувача до сайту, у який він входить.
  • Продуктивність вимірюється, як середній час, необхідне для задоволення запитів клієнтів. Цей час включає час процесора + час для доступу до вторинного сховища + час доступу до мережі. Бажано, щоб продуктивність розподіленої файлової системи Windows була порівнянна з продуктивністю централізованої системи.
  • Користувацький інтерфейс в системі простий, тим не менше, кількість команд повинно бути як можна менше.
  • Масштабованість, зростання вузлів і користувачів не повинен серйозно порушувати обслуговування.
  • Висока доступність РФС повинна продовжувати функціонувати в умовах часткових збоїв, таких, як збій зв’язку, вузла або накопичувача, і повинна мати декілька незалежних серверів файлів, управляючих кількома пристроями зберігання.
  • Висока надійність. Ймовірність втрати збережених даних повинна бути мінімізована. Система повинна автоматично створювати резервні копії критичних файлів.
  • Цілісність даних забезпечується паралельністю запитів доступу декількох користувачів, які конкурують за доступ і повинні бути правильно синхронізовані з використанням механізму управління декількома формами.
  • Користувачі повинні бути впевнені в конфіденційності своїх даних.
  • Неоднорідність РФС, повинен бути забезпечений легкий доступ до загальних даних на різних платформах, наприклад, робоча станція Unix, платформа Wintel та інші.
  • Модель перенесення на рівні блоку

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

    У моделі переносу на рівні файлів, коли дані повинні бути передані, весь файл переміщується. Переваги моделі:

  • Файл повинен бути передано тільки один раз у відповідь на запит клієнта і, отже, він ефективніший, ніж перенесення сторінок за сторінкою, що вимагає більшої кількості мережевих протоколів.
  • Знижує навантаження на сервер і мережевий трафік, оскільки він звертається до сервера тільки один раз.
  • Це покращує масштабованість. Коли весь файл кешується на клієнтському сайті, він несприйнятливий до збоїв сервера і мережі.
  • Недоліки моделі:

  • Потрібен достатній простір для зберігання на клієнтській машині. Цей підхід не підходить для дуже великих файлів, особливо коли клієнт працює на бездисковой робочої станції.
  • Лише невелика частина файлу, переміщення всього файлу є марнотратним.
  • Передача файлів відбувається в блоках. Він є його окремою частиною і має фіксовану довжину і також може бути дорівнює розміру сторінки віртуальної пам’яті.
  • Для моделі переносу одиниця передачі – це байт. Модель забезпечує максимальну гнучкість, оскільки вона дозволяє зберігати і витягувати довільний об’єм файлу, заданий зміщенням всередині і довжини. Недоліком є те, що управління кешем складніше за даних змінної довжини для різних запитів доступу.

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

    Форми і розташування кеша

    Кожна розподілена файлова система Windows використовує свою форму кешування.

    Причини створення кешу:

  • Краща швидкодія, оскільки неодноразові звернення до однієї і тієї ж інформації обробляються додатковими мережевими доступом і дисковими передачами.
  • Це пов’язано з локальністю в шаблонах доступу до файлів.
  • Сприяє масштабованості і надійності РФС, оскільки дані можуть бути віддалено кешованими на клієнтському сайті.
  • Основні рішення, які повинні бути прийняті в схемі кешування файлів для РФС:

  • Розташування кеша.
  • Модифікація поширення.
  • Перевірка кеша.
  • Розташування кеша відноситься до місця зберігання кешованих даних. Припускаючи, що початкове місце розташування файлу на диску його сервера. В РФС є кілька можливих розташувань кеша:

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

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

    Існують дві проблеми з дизайном:

  • При поширенні змін, внесених у ці дані на відповідний файловий сервер.
  • При перевірці достовірності кешованих даних.
  • Використовувана схема розповсюдження модифікації надає критичний вплив на продуктивність і надійність системи.

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

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

    Схема із затримкою запису

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

    Існує три часто використовуваних підходу з затримкою запису:

  • Запис при виштовхуванні з кеша. Модифіковані дані в кеші відправляються на сервер тільки тоді, коли політика заміни кешу вирішила витягти дані з кеша. Це може призвести до гарної продуктивності, але може виникнути проблема надійності, оскільки деякі дані сервера старіють протягом тривалого часу.
  • Періодична запис. Кеш періодично перевіряється, і будь-які кешовані дані, які були змінені з моменту останнього сканування, відправляються на сервер.
  • Закриття. Модифікація кешованих даних відправляється на сервер, коли клієнт закриває файл. Це мало допомагає в скороченні мережевого трафіку для тих файлів, які відкриті протягом дуже коротких періодів або рідко змінюються.
  • Переваги схеми з затримкою-записом:

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

    Реплікація, як механізм доступності

    Висока доступність – це потрібна функція хорошою розподіленої файлової системи, а реплікації файлів є основним механізмом поліпшення доступності файлів.

    Реплицированный файл являє собою файл, який має кілька копій, при цьому кожен на окремому сервері.

    Різниця між реплікацією і кешуванням

  • Репліка файлу пов’язана з сервером, тоді як кешированная копія зазвичай пов’язана з клієнтом.
  • Існування кешовану копію в першу чергу залежить від місця розташування в шаблонах доступу до файлів, тоді як наявність репліки зазвичай залежить від вимог доступності і продуктивності.
  • Порівняно з кешованій копією репліка є більш постійною, широко відомої, безпечної, доступної, повною та точною.
  • Кешована копія залежить від репліки. Тільки шляхом періодичної перевірки щодо репліки може бути корисною кешированная копія.
  • Переваги реплікації:

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

    Частою проблемою при роботі системи DFS є поява повідомлення «Відключений клієнт розподіленої файлової системи DFS». Microsoft має вирішення цієї проблеми, для цього потрібно включити клієнта на сервері, наприклад, Windows Server 2012 R2.

    Алгоритм дій:

  • Відкрити Диспетчер серверів і вибрати «Управління DFS» на вкладці «Сервіс», якщо користувач не може знайти його, потрібно додати функцію DFS Namespace.
  • Клікнути мишею і вибрати «Новий простір імен» майстер запускається.
  • Вказати ім’я хоста, назвати свій простір імені розподіленої файлової системи DFS.
  • Натиснути «Створити», і область DFS.
  • Включають спільні теки в DFS.
  • Вибрати простір імен і натиснути папку New Folder.
  • Об’єднати кілька папок в унікальну віртуальну папку.
  • Можна побачити, створений шлях \Domain_NameNamespace_NameVirtual_folder_Name.
  • Після цього повідомлення «служба розподіленої файлової системи не встановлена», більше надходити не буде.
  • Система для спільного використання мережевих ресурсів в Лінукс

    NFS – найбільш поширена файлова система для спільного використання мережевих ресурсів. Найбільш поширеною версією, є NFS v2. Ця розподілена файлова система Linux веде себе як верхній рівень локальної файлової системи. Доступ до віддалених файлів здійснюється через виклики процедур RPC. Він не піклується про стан сервера доступному або недоступному і використовує дуже мало технологій кешування файлів. Крім того, безпека цієї системи заснована на довірі клієнта. Дійсно, це ідентифікатор клієнта, який передається для ознайомлення з правами доступу до ресурсів.

    NFS v3 – це еволюція NFS і в даний час використовується в сучасній запатентованої Unix, яка заповнює деякі прогалини останнього. Таке визначення розподіленої файлової системи, конструкційно дозволяє підтримувати великі файли розміром 2 64-розрядної потужності, а також перевіряти права доступу на сервері. Вони можуть бути засновані на традиційних аутентифікації Unix або використовувати додаткову аутентификацию, наприклад Kerberos. Версія забезпечує можливість запису даних асинхронно, що дає їй кращу продуктивність. Однак більшість інших операцій залишаються синхронними. Підтримка NFS v3 в даний час знаходиться на експериментальній фазі ядра Linux, і вона дуже ефективна.

    Маштабируемое блочне сховище

    Ceph – це ПО, призначене для забезпечення масштабованого об’єктного, блочного і файлового сховища в системі. Кластери зберігання розподіленої файлової системи Ceph призначений для роботи на товарному обладнанні з використанням алгоритму CRUSH, щоб забезпечити рівномірний розподіл даних по кластеру, тоді всі вузли кластера можуть швидко отримувати дані без будь-яких централізованих вузьких місць.

    Ceph доступний через Amazon Simple (S3) і OpenStack Swift (REST) на основі інтерфейсів прикладного програмування, і рідний API для інтеграції з програмними додатками. В блочному сховище Ceph використовується блокування, яка є віртуальним диском і може бути підключена до серверів на базі Linux або віртуальним машинам з відкритим кодом. Надійне автономне сховище розподілених об’єктів Ceph (RADOS) забезпечує можливості зберігання блоків, такі як моментальні знімки і реплікацію.

    Блочний пристрій Ceph RADOS інтегровано для роботи в якості задньої частини з блоковим сховищем OpenStack. Сховище файлів Ceph використовує сумісної з POSIX файлову систему CephFS (CephFS) для зберігання даних в кластері зберігання Ceph. CephFS використовує ту ж кластерну систему, що і сховище блоків Ceph і сховище об’єктів Ceph.

    Переваги розподіленої файлової системи

    Технічно вона забезпечує доступ до загальної директорії, яка не містить файли, а тільки переходи і необов’язкові піддиректорії з великою кількістю переходів. Переходи аналогічні м’яким посиланнях, як відомо з файлових систем Unix, але відносяться до загальних каталогів і можуть вказувати на загальні каталоги на інших серверах. Спочатку клієнти запитують сервер DFS з’єднання, потім звертаються до сервера файл, на який вказує це з’єднання.

    Основне завдання використання розподіленої файлова система DFS – створити альтернативне простір імен (подання дерева каталогів), яке приховує деталі базової інфраструктури від користувачів. Шляхи, які користувачі бачать і називаються іменами DFS, не змінюються при перейменуванні серверів або при переміщенні деяких з каталогів на інший сервер.

    Адміністратори можуть просто замінити застаріле ім’я на нове, що вказує на нову мету. Ім’я може вказувати на більш ніж одну мету, тобто надати клієнтові кілька альтернативних з’єднань для різних спільних папок. В цьому випадку клієнти розподіленої файлової системи DFS можуть отримати доступ до будь-якої з цілей. Це забезпечує балансування навантаження та автоматичний перехід на інший сервер, якщо один із серверів виходить з ладу.

    Завдяки DFS більше немає суворого з’єднання з сервером загальним доступом. Пам’ять представлена у вигляді пулу великої ємності, за яким стоять файлові системи, приховані для користувача. На самому ділі це неймовірно корисний інструмент для вирішення зростаючих вимог до того, щоб файлова система розподіляла дискову пам’ять нових серверів виходячи з вимог доступності.

    Технологія, подібна Windows DFS, приносить користь будь-яким компаніям і великим, і маленьким. Для великих компаній окупається аспект більш гнучкого використання ресурсів зберігання. Оскільки всі диски є частиною віртуальної пам’яті, більше немає невикористовуваних або переповнених дисків і масивів.

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

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

    Розробники інтегрували всебічне управління розподіленої файлової системи DFS Windows, консоль являє собою єдину точку управління для декількох кореневих систем DFS. Графічні інструменти полегшують огляд і моніторинг. Управління можливо навіть на веб-сайтах.