Распределенная файловая система: описание, особенности, преимущества

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

Основы сетевых БД

Эти элементы относятся к сетевым файловым системам и гарантируют доступ к ним на серверах. С их поддержкою пользователь имеет возможность сформировать цельную межсетевую файловую систему. Она включает различные средства для серверов.

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

Существует несколько РФС, которые различаются в приложении, интерфейсе и протоколе, а также различные функции, такие как кеширование, ведение журнала, многоканальное использование в локальных сетях. Поскольку пропускная способность распределенных файловых систем для кластеров чрезвычайно низка, эти приложения имеют специальные системы со скоростями передачи более 100 МБ/с. К ним относятся Глобальная система (GFS) и проприетарная общая система (GPFS).

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

Примерами являются:

  1. Сетевая файловая система (NFS).
  2. Общая файловая система интернета (CIFS), расширение блока сообщений сервера (SMB).
  3. Протокол подачи Apple (AFP) Apple.
  4. Основной протокол NetWare (NCP) от Novell.

Известными реализациями РФС являются:

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

Сравнение распределенных файловых систем.

Обслуживание и виды системных услуг

Такая система предоставляет следующие услуги:

  1. Обслуживание хранилища. Распределение и управление пространством на вторичном устройстве хранения, обеспечивая тем самым логический вид системы хранения.
  2. Истинное обслуживание файлов. Включает семантику совместного доступа к файлам, механизм кэширования, репликацию, контроль параллелизма, протокол копирования нескольких копий.
  3. Служба имени каталога. Отвечает за действия, связанные с каталогом: создание и удаление каталогов, добавление нового файла в каталог, удаление из каталога, изменение имени, перемещение его из одного каталога в другой.

Необходимые функции РФС:

  1. Прозрачность. Клиенты распределенной файловой системы DFS не должны знать количество или расположение файловых серверов и устройств хранения. Множество файловых серверов обеспечивают производительность, масштабируемость, надежность и прозрачность доступа.
  2. Как локальные, так и удаленные файлы должны быть доступны одинаково. Система должна автоматически найти доступный и перенести его на сайт клиента. Имя файла не должно указывать на местоположение файла. Оно не должно изменяться при переходе с одного узла на другой. Если файл реплицируется на нескольких узлах, то наличие нескольких копий и их местоположения должны быть скрыты от клиентов.
  3. Мобильность автоматически приводит в действие пользовательскую среду, например, домашний каталог пользователя к узлу, в который он входит.
  4. Производительность измеряется, как среднее время, необходимое для удовлетворения запросов клиентов. Это время включает время процессора + время для доступа к вторичному хранилищу + время доступа к сети. Желательно, чтобы производительность распределенной файловой системы Windows была сопоставима с производительностью централизованной системы.
  5. Пользовательский интерфейс в системе прост, тем не менее, количество команд должно быть, как можно меньше.
  6. Масштабируемость, рост узлов и пользователей не должен серьезно нарушать обслуживание.
  7. Высокая доступность РФС должна продолжать функционировать в условиях частичных сбоев, таких, как сбой связи, узла или накопителя, и должна иметь несколько независимых серверов файлов, управляющих несколькими устройствами хранения.
  8. Высокая надежность. Вероятность потери хранимых данных должна быть минимизирована. Система должна автоматически создавать резервные копии критических файлов.
  9. Целостность данных обеспечивается параллельностью запросов доступа от нескольких пользователей, которые конкурируют за доступ и должны быть правильно синхронизированы с использованием механизма управления несколькими формами.
  10. Пользователи должны быть уверены в конфиденциальности своих данных.
  11. Неоднородность РФС, должен быть обеспечен легкий доступ к общим данным на разных платформах, например, рабочая станция Unix, платформа Wintel и другие.

Модель переноса на уровне блока

В файловых системах, использующих модель кэширования данных, важной проблемой проектирования является выбор единицы передачи данных. Это относится к доле файла, который переносится и формируется клиентами в результате одной операции чтения или записи.

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

  1. Файл должен быть передан только один раз в ответ на запрос клиента и, следовательно, он более эффективен, чем перенос страниц за страницей, что требует большего количества сетевых протоколов.
  2. Снижает нагрузку на сервер и сетевой трафик, поскольку он обращается к серверу только один раз.
  3. Это улучшает масштабируемость. Когда весь файл кэшируется на клиентском сайте, он невосприимчив к сбоям сервера и сети.

Недостатки модели:

  1. Требуется достаточное пространство для хранения на клиентской машине. Этот подход не подходит для очень больших файлов, особенно когда клиент работает на бездисковой рабочей станции.
  2. Если требуется только небольшая часть файла, перемещение всего файла является расточительным.
  3. Передача файлов происходит в блоках. Он является его смежной частью и имеет фиксированную длину и также может быть равен размеру страницы виртуальной памяти.

Для модели переноса единица передачи - это байт. Модель обеспечивает максимальную гибкость, поскольку она позволяет хранить и извлекать произвольный объем файла, заданный смещением внутри и длины. Недостатком является то, что управление кэшем сложнее из-за данных переменной длины для разных запросов доступа.

Модель переноса на уровне записи используется со структурированными файлами, а единица передачи - это запись. Несколько пользователей могут одновременно обращаться к совместно используемому файлу. Важной проблемой проектирования для любой файловой системы является определение того, когда изменения файлов данных, сделанные пользователем, наблюдаются другими пользователями.

Формы и расположение кэша

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

Причины создания кэша:

  1. Лучшая производительность, поскольку неоднократные обращения к одной и той же информации обрабатываются дополнительными сетевыми доступом и дисковыми передачами.
  2. Это связано с локальностью в шаблонах доступа к файлам.
  3. Способствует масштабируемости и надежности РФС, поскольку данные могут быть удаленно кэшированы на клиентском узле.

Основные решения, которые должны быть приняты в схеме кэширования файлов для РФС:

  1. Расположение кеша.
  2. Модификация распространения.
  3. Проверка кеша.

Расположение кеша относится к месту хранения кэшированных данных. Предполагая, что исходное местоположение файла находится на диске его сервера. В РФС есть несколько возможных расположений кеша:

  1. Основная память сервера. В этом случае кеш попадает в один сетевой доступ. Это не способствует масштабируемости и надежности системы, так как каждый кеш-клик требует доступа к серверу. Преимущества метода - простота внедрения, прозрачность для клиентов, простота сохранности исходного файла в кэше.
  2. При использовании клиентского диска кеш попадает на один доступ к диску. Это несколько медленнее, чем наличие кеша в основной памяти сервера. Преимущества распределяемых файловых систем в случае использования клиентского диска обеспечивает надежность от сбоев, так как изменение кэшированных данных теряется при сбое. Этот вариант большой емкости, способствует масштабируемости и надежности, поскольку в кэше удаленный запрос доступа можно обслуживать локально без необходимости обращаться к серверу.

Модификация распространения

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

Существуют две проблемы с дизайном:

  1. При распространении изменений, внесенных в кэшированные данные на соответствующий файловый сервер.
  2. При проверке достоверности кэшированных данных.

Используемая схема распространения модификации оказывает критическое влияние на производительность и надежность системы.

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

Недостаток - эта схема подходит только тогда, когда соотношение обращений чтения к записи довольно велико. Он не снижает сетевой трафик для записи. Это связано с тем, что каждый доступ на запись должен ждать, пока данные будут записаны на главную копию сервера.

Схема с задержкой записи

Чтобы уменьшить сетевой трафик для записи, используется схема с задержкой записи. В этом случае новое значение данных записывается только в кеш, и все обновленные записи кэша отправляются на сервер позднее.

Существует три часто используемых подхода с задержкой записи:

  1. Запись при выталкивании из кеша. Модифицированные данные в кеше отправляются на сервер только тогда, когда политика замены кэша решила извлечь из кеша данные. Это может привести к хорошей производительности, но может возникнуть проблема надежности, поскольку некоторые данные сервера стареют в течение длительного времени.
  2. Периодическая запись. Кэш периодически проверяется, и любые кэшированные данные, которые были изменены с момента последнего сканирования, отправляются на сервер.
  3. Закрытие. Модификация кэшированных данных отправляется на сервер, когда клиент закрывает файл. Это мало помогает в сокращении сетевого трафика для тех файлов, которые открыты в течение очень коротких периодов или редко изменяются.

Преимущества схемы с задержкой-записью:

  1. Запись доступа выполняется быстрее, потому что новое значение записывается только в кеш клиента. Это приводит к увеличению производительности.
  2. Модифицированные данные могут быть удалены до того, как настало время отправить их на сервер, например, временные данные. Поскольку модификации не должны распространяться на сервер, это приводит к существенному усилению производительности.
  3. Сбор всех обновлений файлов и отправка их на сервер более эффективны, чем отправка каждого обновления отдельно.

Недостаток схемы с задержкой записи - надежность все еще может быть проблемной, поскольку изменения, неотправленные на сервер из кеша клиента, будут потеряны.

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

Высокая доступность - это нужная функция хорошей распределенной файловой системы, а репликация файлов является основным механизмом улучшения доступности файлов.

Реплицированный файл представляет собой файл, который имеет несколько копий, при этом каждый на отдельном сервере.

Разница между репликацией и кэшированием

  1. Реплика файла связана с сервером, тогда как кешированная копия обычно связана с клиентом.
  2. Существование кэшированной копии в первую очередь зависит от местоположения в шаблонах доступа к файлам, тогда как наличие реплики обычно зависит от требований доступности и производительности.
  3. По сравнению с кешированной копией реплика является более постоянной, широко известной, безопасной, доступной, полной и точной.
  4. Кэшированная копия зависит от реплики. Только путем периодической проверки в отношении реплики может быть полезной кешированная копия.

Преимущества репликации:

  1. Повышенная доступность. Альтернативные копии реплицированных данных могут использоваться, когда основная копия недоступна.
  2. Повышенная надежность. Из-за наличия избыточных файлов данных в системе становится возможным восстановление от катастрофических сбоев, например, сбой жесткого диска.
  3. Улучшено время отклика. Он позволяет получать доступ к данным либо локально, либо от узла, на которое время доступа меньше, чем время доступа к первичной копии.
  4. Снижение сетевого трафика. Если реплика файла доступна с файловым сервером, который находится на узле клиента, запрос на доступ клиента может обслуживаться локально, что приводит к снижению сетевого трафика.
  5. Улучшенная пропускная способность системы. Несколько запросов клиентов на доступ к файлу могут обслуживаться параллельно на разных серверах, что приводит к повышению пропускной способности системы.
  6. Улучшенная масштабируемость. Для обслуживания клиентских запросов доступно несколько серверов, поскольку из-за репликации файлов. Это улучшает масштабируемость.

Настройка работы клиента при отключении

Частой проблемой при работе системы DFS является появление сообщения «Отключен клиент распределенной файловой системы DFS». Microsoft имеет решения этой проблемы, для этого нужно включить клиента на сервере, например, Windows Server 2012 R2.

Алгоритм действий:

  1. Открыть Диспетчер серверов и выбрать «Управление DFS» на вкладке «Сервис», если пользователь не может найти его, требуется добавить функцию DFS Namespace.
  2. Кликнуть мышью и выбрать «Новое пространство имен», мастер запустится.
  3. Указать имя хоста, назвать свое пространство имени распределенной файловой системы DFS.
  4. Нажать «Создать», и область имен DFS.
  5. Включают общие папки в DFS.
  6. Выбрать пространство имен и нажать папку New Folder.
  7. Объединить несколько папок в уникальную виртуальную папку.
  8. Можно увидеть, созданный путь \\Domain_Name\Namespace_Name\Virtual_folder_Name.
  9. После этого сообщения «служба распределенной файловой системы не установлена», больше поступать пользователю не будет.

Система для совместного использования сетевых ресурсов в Линукс

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. Графические инструменты облегчают обзор и мониторинг. Управление возможно даже на веб-сайтах.

Комментарии