Выбор распределенной файловой системы для Linux. Пару слов о Ceph и остальных
Существует несколько десятков файловых систем, все из них предоставляют пользовательские интерфейсы для хранения данных. Каждая из систем хороша по-своему. Однако, в наш век высоких нагрузок и петабайтов данных для обработки, оказалось довольно непросто подыскать то, что нужно, стоит лишь задуматься о распределенных данных, распределенных нагрузках, множественном монтировании rw и о прочих кластерных прелестях.
Задача: организовать распределенное файловое хранилище
— без самосборных ядер, модулей, патчей,
— с возможностью множественного монтирования в режиме rw,
— POSIX совместимость,
— отказоустойчивость,
— совместимость с уже использующимися технологиями,
— разумный overhead по I/O операциям по сравнению с локальными файловыми системами,
— простота конфигурации, обслуживания и администрирования.
В работе мы используем Proxmox и контейнерную виртуализацию OpenVZ. Это удобно, это летает, у этого решения больше плюсов, чем у аналогичных продуктов. По крайней мере для наших проектов и в наших реалиях.
Сам storage везде монтируется по FC.
OCFS2
У нас был успешный опыт использования данной файловой системы, решили сначала попробовать ее. Proxmox с недавнего времени перешел на редхатовское ядро, в нем поддержка ocfs2 выключена. Модуль в ядре есть, но на форумах openvz и proxmox не рекомендуют его задействовать. Мы попробовали и пересобрали ядро. Модуль версии 1.5.0, кластер из 4 железных машин на базе debian squeeze, proxmox 2.0beta3, ядро 2.6.32-6-pve. Для тестов использовался stress. Проблемы за несколько лет остались те же самые. Все завелось, настройка данной связки занимает полчаса от силы. Однако, под нагрузкой кластер может самопроизвольно развалиться, что ведет к тотальному kernel panic на всех серверах сразу. За сутки тестов машины перезагружались в общей сложности пять раз. Это лечится, но доводить такую систему до работоспособного состояния довольно тяжело. Пришлось также пересобирать ядро и включать ocfs2. Минус.
Хоть ядро и редхатовское, модуль по умолчанию включен, завестись мы и здесь так и не смогли. Все дело в proxmox, которые со второй версии придумали свой кластер с шахматами и поэтессами для хранения своих конфигов. Там cman, corosync и прочие пакеты из gfs2-tools, только все пересобранные специально для pve. Оснастка для gfs2, таким образом, из пакетов просто так не ставится, так как предлагает сначала снести весь proxmox, что мы сделать не могли. За три часа зависимости удалось победить, но все опять закончилось kernel panic. Попытка приспособить пакеты для proxmox для решения наших проблем успехом не увенчалась, после двух часов было принято решение отказаться от этой идеи.
Остановились пока на ней.
POSIX совместимая, высокая скорость работы, отличная масштабируемость, несколько смелых и интересных подходов в реализации.
Файловая система состоит из следующих компонентов: 
1. Клиенты. Пользователи данных.
2. Сервера метаданных. Кэшируют и синхронизируют распределенные метаданные. С помощью метаданных клиент в любой промежуток времени знает, где находятся нужные ему данные. Также сервера метаданных выполняют распределение новых данных.
3. Кластер хранения объектов. Здесь в виде объектов хранятся как данные, так и метаданные.
4. Кластерные мониторы. Осуществляют мониторинг здоровья всей системы в целом.
Фактический файловый ввод/вывод происходит между клиентом и кластером хранения объектов. Таким образом, управление высокоуровневыми функциями POSIX (открытие, закрытие и переименование) осуществляется с помощью серверов метаданных, а управление обычными функциями POSIX (чтение и запись) осуществляется непосредственно через кластер хранения объектов.
Любых компонентов может быть несколько, в зависимости от стоящих перед администратором задач.
Файловая система может быть подключена как напрямую, с помощью модуля ядра, так через FUSE. С точки зрения пользователя, файловая система Ceph является прозрачной. Они просто имеют доступ к огромной системе хранения данных и не осведомлены об используемых для этого серверах метаданных, мониторах и отдельных устройствах, составляющих массивный пул системы хранения данных. Пользователи просто видят точку монтирования, в которой могут быть выполнены стандартные операции файлового ввода / вывода. С точки зрения администратора имеется возможность прозрачно расширить кластер, добавив сколько угодно необходимых компонентов, мониторов, хранилищ, серверов метаданных.
Разработчики гордо называют Ceph экосистемой.
GPFS, Lustre и прочие файловые системы, а также надстройки, мы не рассматривали в этот раз, они либо очень сложны в настройке, либо не развиваются, либо не подходят по заданию.
Конфигурация и тестирование
Конфигурация стандартная, все взято из Ceph wiki. В целом файловая система оставила приятные впечатления. Собран массив 2Тб, пополам из SAS и SATA дисков (экспорт блочных устройств по FC), партиции в ext3.
Ceph storage примонтирован внутрь 12-и виртуальных машин на 4 hardware nodes, осуществляется чтение-запись со всех точек монтирования. Четвертые сутки стресс-тестов проходят нормально, I/O выдается в среднем 75 мб/с. на запись по пику.
Мы пока не рассматривали остальные функции Ceph (а их осталось еще довольно много), также есть проблемы с FUSE. Но хотя разработчики предупреждают, что система экспериментальная, что ее не стоит использовать в production, мы считаем, что если очень хочется, то можно -_-
Прошу всех заинтересованных, а также всех сочувствующих, в личку. Тема очень интересная, ищем единомышленников, чтобы обсудить возникшие проблемы и найти способы их решения.
Источник
forum.lissyara.su
Чем глубже в песке твоя голова — тем беззащитнее жопа
DFS и BSD/Linux клиенты
Модератор: terminus
DFS и BSD/Linux клиенты
У кого нить есть клиент под это дело, а именно под MS DFS (Microsoft Distributed File System). Кто сталкивался то знает, сто ента весчь нужна для обеденения виндовых или самбовских шар (с разных серверов) в одну шару, где они представляются ввиде обыкновенных каталогов. При ентом сохраняются права которые были им назначены изночально (на конечном сервере). Дело втом что самба подерживает только серверную часть DFS, которую я поставил, а вот клиентскую часть нет.
Если же нет сиго чуда, у кого нить есть идеи по реализации иными способами данного дерева!
Услуги хостинговой компании Host-Food.ru
Не так меня понял
есть четыре сервера serv1, serv2, serv3
на первом
\\serv1\data
на втором
\\serv2\musik
\\serv2\films
\\serv2\distr
\\serv2\drivers
на третьем
\\serv3\netdocs
\\serv3\hlam
на четвертом
\\serv4\backup
По отдельности все эти шары конектятся номально через mount_smbfs. Как под линем так и под фрюхой
Но что бы не конектить все эти шары сетевыми дисками, я создал Дерево DFS. тперь эти все шары объеденены одним каталогом выглядит это так
\\serv1\dfs\Сетевые документы
Хотя на самом деле это сылка на \\serv3\netdocs
Когда я просто открываю шару \\serv3\netdocs то все видно, а когда \\serv1\dfs\, то папка «Сетевые документы» видна, а что внутри нет. Здесь приведен пример с русской папкой, пробывал и с ангельской!
Проблема не с шарами, а в DFS а точнее нужен клиент под енто дело для фри и линя.
Если такого нет, то нужна альтернатива как реализовать такой каталог который будет содержать некоторые шары серверов.
Источник
Alexflex / HDFS.md
Лабораторная работа. Распределенная файловая система HDFS
Изучение основных операций для работы с распределенной файловой системой HDFS.
- подготовка окружения
- запуск shell-клиента
- изучение основных shell-команд
Подготовка рабочего окружения
Работа на сервере
Для подключения к серверу в локальной сети кафедры необходимо использовать один из возможных ssh-клиентов. Например, putty. Действия, которые необходимо выполнить для подключения к серверу:
- указать сервер 10.101.26.201, порт 22
- логин (vtizi) и пароль (секретный)
Работа с виртуальной машиной
Для выполнения задания вне сети кафедры необходимо подготовить виртуальное окружение:
- настроить окружения для запуска виртуальных машин VMware
- скачать и развернуть виртуальную машину от компании Cloudera по ссылке
- ИЛИ сразу скачать готовый образ для VMWare
Задание на лабораторную работу
Запуск shell-клиента HDFS в терминале
Нативный shell-клиент для HDFS позволяет работать с файловой системой через командную строку. Для использования shell-клиента через командную строку, необходимо в терминале запустить утилиту hdfs:
- hdfs — утилита работы с HDFS;
- dfs — специальный параметр, который обозначает, что мы будем работать с непосредственно с распределенной файловой системой. Могут быть указаны другие параметры;
- — команда, которую мы хотим применить к файловой системе;
- — опции команды (могут отсутствовать);
- — путь в виде URI-схемы. URI (/ˌjuː ɑːr ˈaɪ/англ. Uniform Resource Identifier) — унифицированный (единообразный) идентификатор ресурса. символьная строка, позволяющая идентифицировать какой-либо ресурс: документ, изображение, файл, службу, ящик электронной почты и т. д. Прежде всего, речь идёт о ресурсах сети Интернет и Всемирной паутины. URI предоставляет простой и расширяемый способ идентификации ресурсов. Расширяемость URI означает, что уже существуют несколько схем идентификации внутри URI, и ещё больше будет создано в будущем.
Пример команды для просмотра содержимого (листинг) корневой директории:
Запуск терминала 
Запуск на виртуальной машине 
Задание пути в виде URI-схемы
| Название части URI | Фрагмент | Описание |
|---|---|---|
| scheme | hdfs:// | схема |
| authority | localhost:8020 | часть авторизации — название сервера, порт, на котором находится Namenode, может быть указано имя пользователя |
| HDFS path | /user/home | путь в распределенной или локальной файловой системе |
- Local Указываем file:// — схема, а путь — /to/path/dir . Аналогична команде ls /to/path/dir локальной файловой системы
- HDFS Просмотр файлов в распределенной файловой системе HDFS
где hdfs:// — схема, а localhost/to/path/dir — расположение namenode, а далее путь к файлам в HDFS. На сервере:
В виртуальной машине:
- fs.default.name=hdfs://localhost Чтобы постоянно не указывать схему и сервер при работе с одной и той же HDFS применяется упрощенный способ доступа к файлам HDFS без схемы и части авторизации. В конфигурации указан специальный параметр, который автоматически будет подставляться в схему
В HDFS клиенте реализованы стандартные команды для работы с файловой системой. Называются похоже на команды bash (локальной файловой системы).
- похожие на команды Linux : cat, rm, ls, du, . ;
- специфичные для HDFS операции: setrep — смена фактора репликации;
получить список всех команд в HDFS-клиенте
показать информацию по команде:
ls — самая популярная команда, выводит листинг директории и статистику файлов. Если запустим команду для определенной директории, то увидим ее содержимое:
- сколько элементов в данной директории items
- файлы, которые содержатся в директории
- статистика — указание прав доступа и типа файла (поддиректории), фактор репликации (у директории — нет), принадлежность файла (пользователь и группа), время создания. Параметры команды:
- -r — вывести статистику по поддиректориям Пример команды:
3. Команда mkdir
4. Команда чтения файлов cat
Выводит источник в стандартный поток вывода — stdout .
- вывести весь файл hdfs dfs -cat /dir/file.txt — для больших файлов очень долго и не понятно для чего
- перенаправление потока вывода через каналы pipe в утилиты less, head, tail
- получить первые 100 строк из файла hdfs dfs -cat /dir/file.txt | head -n 100
5. Команда чтения файлов text
Аналог команды cat , но разархивирует архивы:
Если файл не заархивирован, то работа команд text и cat будет одинакова.
6. Команда чтения файлов tail
Выводит последние строчки файла:
В первом случае читается весь файл и только потом от него отрезаются последние строчки для вывода. Для большого файла может потребоваться на чтение много времени — прочитать все блоки файла со всех серверов. Только с последнего блока вывести последние строки. Во втором случае нет лишних действий, будут выведены последние строчки из последнего блока.
Полезна для просмотра, например, логов.
7. Копирование данных в shell
cp — копирование файла из одного места в другое. Годится только для небольших файлов!
Копирует файл из одной директории в другую. Т.к. файл состоит из блоков, то каждый блок копируется на новое место. Если файл большой и состоит из многих блоков, то копирование такого файла будет выполняться долго. Разумно копировать небольшие файлы, иначе для больших файлов потребуется много времени.
distcp — копирование больших файлов или множества файлов.
это команда не часть команды dfs . При использовании команды distcp блоки файла копируются параллельно и независимо друг от друга. Файл копируется быстро. Для больших файлов. mv — перемещение файла из одного места в другое
Физически перемещение данных не происходит. Указание Namenode, что файл теперь будет храниться в другой директории.
put , copyFromLocal — копирование локального файла в директорию HDFS
get , copyToLocal — копирование файла из HDFS в локальную файловую систему
8. Команда удаления в shell
rm — удаляет файл в корзину. При случайном удалении большого файла его очень трудно восстановить. Поэтому файл сначала помещается в корзину. Корзина — специальная для каждого пользователя директория. Файлы из нее можно удалить или скопировать на прежнее место. Автоматически очистка корзины задана в параметрах HDFS. Если нужно освободить место в HDFS, то можно удалить файл из корзины.
9. Команда выведения статистики в shell
du — размер файла или директории в байтах du -h — размер файла или директории в удобно-читаемом формате
В HDFS файлы большие, поэтому удобнее использовать ключ -h .
Права доступа в HDFS
- ограничения на уровне файла/директории — сходство с моделью прав в POSIX — Read (r) , Write (w) , Execute (x) — Разделяется на пользователя, группу и всех остальных
- Права пользователя определяются исходя из прав той ОС, где он запускает клиентское приложение.
У файлов есть владелец и группа, которой он принадлежит.
Источник
