Elliptics network "make things easy" release: 2.6.2

Tagged:  

Name says it all: it is not dumb simple to create distributed hash table redundant storage over multiple nodes with HTTP data access.

Data is uploaded using POST method through special FastCGI application, which is linked with elliptics network library and writes data into the storage according to its config file (one can specify data redundancy there for example).

Data receiving is rather different idea - FastCGI application described above only lookups requested object in the network and returns direct URL to appropriate storage server. It has to be configured according to some standards (like data must be placed in subdirs, indexed by the parameter, which is equal to appropriate elliptics network port minus FCGI_DNET_BASE_PORT config option, i.e. if there are two elliptics nodes (for two disks for example) running on 1025 and 1026 ports, FCGI_DNET_BASE_PORT config parameter being set to "1024" and single web server, its document root should contain subdirs 1 and 2 (1025-1024 and 1026-1024).
There is bunch of other useful config parameters, although there is no authentification or any kind of permission checks yet.

Anyway, here is a changelog:

  • Added FastCGI daemon to handle GET (returns direct URL via redirect or XML) and POST requests
  • Extended lookup to optionally check whether requested object is stored locally
  • Added lighttpd fastcgi config
  • Bug fixes

I deployed small storage total of 1 Tb of data spread over 4 physical machines with 2 elliptics node on each (one per storage disk) and uploaded 60 gb of data there (about 3-4 thousans of files and each one has additional copy).

Upload is rather trivial:

wget --post-file=$file http://base_fast_cgi_host.net/name.mp3?name=$some_file_name

You might expect that file downloading will be as simple as

wget http://base_fast_cgi_host.net/name.mp3?name=$some_file_name

and you will be absolutely right, that it will redirect you to some server inside storage cloud via direct link to the requested object.

Also added files to make debian packages. This even works.

Full changelog is available in git tree.

That's it, enjoy!

а связка в цепочке сейчас работает?
если подключить по роутингу dnet_ioserv, то данные будут писаться на подключенный узел?

я запускаю вот так
killall dnet_ioserv;
dnet_ioserv -i 0234567890abcde0000 -a devel:1030:2 -s -j -d /tmp/dnet0/ -l /tmp/dnet0.log -t -D;
for i in `seq 1 9`;do
dnet_ioserv -i ${i}234567890abcde0000 -r devel:1030:2 -a devel:103${i}:2 -s -j devel -d /tmp/dnet${i}/ -l /tmp/dnet${i}.log -t -D;
done

И при попытке что-то зазгрузить через devel:1030:2 (основной), заливается только в него.
В других нодах данные не появляются, хотя они и подключены по роутингу к нему.

загрузка идёт через fcgi, который вы для примера сделали.

dnet_ioserv -i ${i}234567890abcde0000 -r devel:1030:2 -a devel:103${i}:2 -s -j devel -d /tmp/dnet${i}/ -l /tmp/dnet${i}.log -t -D;

-s - request stats from all connected nodes

-s не нужно в этом случае - система просто запустит запрос статистики и отключится.
Так же не ясно, что значит '-j devel', ключ '-j' используется без параметра.

Думаю, что просто ни один дополнительный сервер не запустился.

еще вопросы.
есть 10 нод, на них хранятся файлы. (как в вашем примере мп3)

1. умирает одна нода на которой была одна из копий файлов. куда будут писать новые копии пока мертвая не воскреснет ?

2. что будет если на диске закончится место?

3. ноды взаимно обмениваются информацией о доступных роутингах (DHT) ?

4. можно ли как-то переводить ноды в режим read/modify only в случае если места мало ? или надо делать какой нибудь дисковой кластер чтобы место не заканчивалось точно? (я могу ошибаться и просто не заметил описание этой проблемы в коде или в блоге у вас)

интерфейс сделаем :)

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

2. запись будет возвращаться с ошибкой

3. да, узлы обмениваются таблицами маршрутизации при подключении узлов

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

simple thanks :)

-j - join the network
я думал что join то нетворк, типа в будущем можно будет несколько сетей создавать на базе одного роутинга.

действительно вы были правы.

еще вопрос lib'a делается как полуфабрикат для хранилища (DHT) или будет полноценный продукт который будет учитывать свободное место, количество запросов и загрузку системы ?

спасибо за ваше время и за либу, очень интересно

Статистика по каждому узлу доступна, есть соответствующее приложение для мониторинга.

Какой-то красивой кнтрольной панели нет, и наверное было бы неплохо что-то подобное сделать, но пока только консольные утилиты.