s o m e t h i n g a b o u t m e

mogilefs. installation and configuration

MogileFS is open source distributed filesystem. Its properties and features include:

  • Application level — no special kernel modules required.
  • No single point of failure — all three components of a MogileFS setup (storage nodes, trackers, and the tracker’s database(s)) can be run on multiple machines, so there’s no single point of failure. (you can run trackers on the same machines as storage nodes, too, so you don’t need 4 machines…) A minimum of 2 machines is recommended.
  • Automatic file replication — files, based on their “class”, are automatically replicated between enough different storage nodes as to satisfy the minimum replica count as requested by their class. For instance, for a photo hosting site you can make original JPEGs have a minimum replica count of 3, but thumbnails and scaled versions only have a replica count of 1 or 2. If you lose the only copy of a thumbnail, the application can just rebuild it. In this way, MogileFS (without RAID) can save money on disks that would otherwise be storing multiple copies of data unnecessarily.
  • “Better than RAID” — in a non-SAN RAID setup, the disks are redundant, but the host isn’t. If you lose the entire machine, the files are inaccessible. MogileFS replicates the files between devices which are on different hosts, so files are always available.
  • Flat Namespace — Files are identified by named keys in a flat, global namespace. You can create as many namespaces as you’d like, so multiple applications with potentially conflicting keys can run on the same MogileFS installation.
  • Shared-Nothing — MogileFS doesn’t depend on a pricey SAN with shared disks. Every machine maintains its own local disks.
  • No RAID required — Local disks on MogileFS storage nodes can be in a RAID, or not. It’s cheaper not to, as RAID doesn’t buy you any safety that MogileFS doesn’t already provide.
  • Local filesystem agnostic — Local disks on MogileFS storage nodes can be formatted with your filesystem of choice (ext3, XFS, etc..). MogileFS does its own internal directory hashing so it doesn’t hit filesystem limits such as “max files per directory” or “max directories per directory”. Use what you’re comfortable with.

installation and configuration:

  1. svn checkout http://code.sixapart.com/svn/mogilefs/trunk/
    дальше ставим trunk/server по шагам:

    $ make Makefile.PL
    $ make
    $ make test
    $ make install

    на шаге “make test” может оказаться, что не хватает перловских модулей. берем CPAN и ставим все, что нужно. CPAN в виде интерактивной оболочки запускаем как

    $ sudo perl -MCPAN -e shell
  2. делаем схему в базе данных, делаем отдельного юзверя mogile, даем ему полные права на базу. Все необходимые таблицы сделает mogdbsetup с параметрами хоста, базы, пользователя, пароля в коммандной строке.
  3. для запуска tracker-серверов и storage-серверов сделаем пользователя mogile
  4. настраиваем конфиги tracker-серверов и storage-серверов: /etc/mogilefs/mogilefsd.conf и /etc/mogilefs/mogstored.conf на соответствующих серверах (на каждом storage- и tracker- сервере запускается по демону, которому нужен конфиг)
    $ cat /etc/mogilefs/mogilefsd.conf
    #daemonize = 1
    db_dsn = DBI:mysql:mogilefs:host=DBhost.host.com
    db_user = mogile
    db_pass = mogile
    listen = 0.0.0.0:7001
    conf_port = 7001
    listener_jobs = 5
    delete_jobs = 1
    replicate_jobs = 5
    mog_root = /mnt/mogilefs
    reaper_jobs = 1
    $ cat /etc/mogilefs/mogstored.conf
    httplisten=0.0.0.0:7500
    docroot=/var/mogdata
    mgmtlisten=0.0.0.0:7501

    нужно сделать /var/mogdata где и будет хранится контент FS

  5. запускаем tracker-сервера (нужны для запуска и конфигурирования storage-серверов) как
    # su mogile
    $ mogilefsd -c /etc/mogilefs/mogilefsd.conf --daemon
    $ exit
  6. конфигурим хранилища:
    $ mogadm --lib=/usr/local/share/perl5/5.8.5 --trackers=trackerhost.host.com:7001 host add mogilestorageN
    --ip=STORAGEIP --port=7500 --status=alive

    где mogilestorageN - имя хранилища (любое), STORAGEIP - ip-шник хранилища. trackers-хосты с портами можно перечислять через запятую.

    проверить факт добаления можно так:

    $ mogadm --lib=/usr/local/share/perl5/5.8.5 --trackers=trackerhost.host.com:7001 host list

    теперь нужно добавить devices (папки, в которых будет хранится контент)

    $ mogadm --lib=/usr/local/share/perl5/5.8.5 --trackers=trackerhost.host.com:7001 device add mogilestorageN Y

    где mogilestorageN - хранилище, на котором создаем device, YY - порядковый номер device-а.
    Device-ы создаются с именами dev1, dev2, dev3 … (в лучших традициях :) ) и олицетворяют папки /var/mogdata/devN

    список девайсов смотрим так:

    $ mogadm --lib=/usr/local/share/perl5/5.8.5 --trackers=trackerhost.host.com:7001 device list

    и стартуем хранилища:

    $ su mogile
    $ mogstored --daemon
  7. окончательная проверка:
    $ mogadm --lib=/usr/local/share/perl5/5.8.5 --trackers=trackerhost1.host.com:7001,trackerhost2.host.com:7001 check
    Checking trackers...
      trackerhost1.host.com:7001 ... OK
      trackerhost2.host.com:7001 ... OK
    
    Checking hosts...
      [ 1] mogilestorage ... OK
      [ 2] mogilestorage2 ... OK
    
    Checking devices...
      host device         size(G)    used(G)    free(G)   use%   ob state   I/O%
      ---- ------------ ---------- ---------- ---------- ------ ---------- -----
      [ 1] dev1             6.736      2.942      3.794  43.68%  writeable   0.0
      [ 2] dev2             6.736      5.242      1.494  77.82%  writeable   0.0
      ---- ------------ ---------- ---------- ---------- ------
                 total:    13.473      8.185      5.288  60.75%

    Не доверяя автоматическим тестам можем проверить работу хранилищ вручную:

    $ telnet storagehost.host.com 7500
    Trying 10.10.10.10...
    Connected to storagehost.host.com (10.10.10.10).
    Escape character is '^]'.
    PUT /dev1/test HTTP/1.0
    Content-length: 4
    
    test
    HTTP/1.0 200 OK
    Content-Type: text/html
    Content-Length: 18
    Server: Perlbal
    Connection: close
    <h1>200 - OK</h1>
    Connection closed by foreign host.
    $

    и смотрим, сохранились ли данные:

    $ ll /var/mogdata/dev1/
    total 324
    -rw-r--r--  1 mogile mogile      4 Sep  5 02:33 test
    drwxr-xr-x  2 mogile mogile 319488 Sep  5 02:30 test-write
    -rw-rw-rw-  1 mogile mogile    140 Sep  5 02:33 usage

    папка test есть - все ok.

пара слов, чтобы утрясти в памяти и оставить steps-list на будущее.

поиск и борьба с java клиентом к этому цирку - в следующей серии :) стей ин тач


ext3cow

ext3cow
недавно попалась на глаза интересная файловая система - ext3cow. Решил сделать маленький обзор.Файловая система ext3cow реализует дополнитульную к функционалу ext3 функцию - сдвиг во времени. Т.е. это некоторое совмещение системы контроля версий и файловой системы. Вот что говорится в документации:

In time-shifting, ext3cow introduces an interface to versioning that presents a continuous view of time. Users or applications specify a file name and any point in time, which ext3cow scopes to the appropriate snapshot or file version. The time-shifting interface allows user-space tools to create snapshots and access versions. Applications may access these tools to coordinate snapshots with application state. User-space tools are suitable for automation, using software as simple as cron.

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

как это работает со стороны пользователя:

пользователь в определенный момент времени пожелавший сделать бекап файла/ов выполняет команду

[user@host]: snapshot
Snapshot on . 1067992521

(с параметром или без - конкретный файл или все файлы)

Эта команда создает на диске версию данных, актуальную на текущий момент (возвращается дата в формате юникс-эпохи). Это зовется snapshot epoch.
Дальнейшие изменения файла могут быть так же заснапшотены и будут сохранены уже в другой эпохе (что примечательно - изменения файла не сохраняются в рамках одной эпохи. т.е. бекап по желанию. но, исходя из возможностей ext3 - не чаще чем 1 snapshot в секунду. это существенное отличие этой файловой системы от систем контроля версий. subversion, например).
Чтение файла определенной эпохи выглядит так:

[user@host]: cat somefile@1067992521

Просмотреть список эпох, в которых существуют версии определенного файла можно командой

[user@host]: ls file@

Т.е. как будто бы на файловой системы все версии файла хранятся под именами file@TIME, что вполне корректно с точки зрения модели файловой системы в ядре.
Потому возможны интересные штуки -

  • можно монтировать снапшоты как директории. цитата:

    Distinguished snapshots may be created using links, which allows time-shifting to emulate the behavior of systems that put snapshots in their own namespaces or mount snapshot
    namespaces in separate volumes. For example, an administrator might create a read-only
    version of a file system prior to installing new software.

  • древовидно уходить в прошлое:

    it is permissible to have multiple time-shifts in a single path, e.g. /A/B@time1/C/D@time2/E.

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

как это работает изнутри:
Главное отличие ext3cow от ext3 - увеличение количества мета-информации в i-нодах (offtop: ох, вспоминая Симоненко и 3ю пересдачу :) ). Цитата:

ext3cow does not interfere or replace the Linux common file model, therefore, it integrates easily, requiring no changes to the VFS data structures or interfaces. Modifications are limited to on-disk metadata and the in-memory file system specific fields of the VFS metadata. Ext3cow adds metadata to inodes, directory entries, and the superblock that allows it to scope requests from any point-in-time into a specific file version and support scoping inheritance.

Далее:

Both on-disk and in-memory inodes were retrofitted to support snapshot and copy-on-write by adding three fields: an inode epoch number, a copy-on-write bitmap, and field pointing to the next inode in the version chain.

Т.е. версии файла - это связанный список i-нодов, головой которого является последняя версия файла. Каждый из которых содержит в себе номер эпохи, битовую маску копирования-при-записи (кстати, cow наверное отсюда и пошло :) ) и ссылку на следующий i-нод со следующей версией.

Подробней по каждому элементу:

  • номер эпохи. в ОС хранится счетчик эпохи, который соответствует текущему времени. когда идет snapshot - значение этого счетчика записывается в i-нод, а сам счетчик инкрементируется. т.е. новер эпохи в i-ноде - версия файла
  • a copy-on-write bitmap. эта карта предназначена для хранения отметок изменений. Т.е. структура тут напоминает svn-о подобные системы - каждый i-нод хранит ссылки на блоки файла. Если блок файла не поменялся в текущей версии по сравнению с прошлой - ссылка на блок просто копируется и два i-нода указывают на один блок. Ссылки на изменившиеся/удаленные блокои хранятся в i-нодах старых версий. Бит-карта же содержит в себе флажки - нужно ли копировать ссылку или блок изменился и ссылка останется в старой версии файла.
  • указатель на следующий i-нод. Тут разработчики предложили не очень красивое решение. Т.к. в ext3 цепь i-нодов ограничена по длине, то и цепь версий файла мы не сможем продолжать вечно. Нужно сказать, что мета-информация директории тоже расширена - в ссылках на i-ноды файлов хранятся birthepoch и deathepoch. Это нужно для хранения удаленных в новых версиях, но оставшихся в старых вариантах директорий, файлов. Потому ограничение на длину цепи i-нодов обойдено таким workaround-ом:

    When the length of a version chain meets a threshold value, ext3cow terminates that chain by setting the death epoch of the directory entry used to access this chain to the current system epoch and creates a new chain (of length one) by creating a duplicate directory entry with a birth epoch equal to the system epoch. The stability of inodes ensures that other directory entries linking to the same data find the new chain. Data blocks may be shared between inodes in the two chains. A long-lived, frequently-updated file is described by many short chains rather than a single long chain. While directory entries are also
    linear-search structures, this scheme increases search by a constant factor. It will improve the performance of version search from O(n) to O(1) when ext3 adopts extensible hashing for directories.

Вот. Структура довольно проста и ясна (автор на ней PhD получил).

По использованию. Говорят, система вполне стабильна и может уже сейчас использоваться, хотя в текущей реализации много TO-DO и иногда не хватает чущественного функционала (bugs and todos). Цитата:

The authors have been running ext3cow to store data on their laptops and personal workstations since June 2003. We have not experienced a system crash or data loss incident in that period. Ext3cow has appeal beyond the regulatory environment for which it is designed; it has been adopted as the storage platform for several research projects.

С быстродействием тоже проблем не должно быть - в документации есть сравнительный тест с ext3, так вот ext3cow проигрывает на 5-6 ms на двух-трех типах тестов, что уже впечатляет.

немного подождать и можно делать разделы и тестировать. если, конечно, такой функционал файловой системы востребован :)

by-the-way. интересно, как реализована славно-известная новая TimeMachine эппловская. программный журнал?

ну, и в конце, конечно же:

Ext3cow is stable and ready for use under the GNU Public License. It is available for download at http://www.ext3cow.com.