В этом посте я хочу представить перевод довольно занятного, по моему мнению, руководства по развертыванию собственного распределенного хранилища данных с помощью GlusterFS. Авторство этого руководства принадлежит человеку по имени Jeff Darcy, который опубликовал его блоге CloudFS еще 2 мая.
Мой предыдущий пост вызывал большое количество откликов и просьб описать процесс создания собственного приватного хранилища в стиле Dropbox, так что сегодня я покажу как это сделать.
Во-первых, вам нужен сервер, который будет доступен если не 24 часа в сутки, то хотя бы в то время, когда вы будете пользоваться услугами хранилища. Лично я использую сервер на Rackspace Cloud, который обходится мне в 10$ в месяц. Любой другой облачный сервер, VPS или домашний компьютер также подойдут.
Во-вторых, на этом сервере и его клиентах необходимо запустить GlusterFS. Она доступна во многих дистрибутивах, но следует учитывать, что версия GlusterFS в прекомпилированном пакете может быть устаревшей. Например, в Fedora доступна версия 3.1.3, что очень неплохо, но в репозиториях Ubuntu можно найти только версию 3.0.5, которая слишком устарела, чтобы быть пригодной к использованию. Свежие пакеты для некоторых дистрибутивов доступны также на сайте GlusterFS и в других местах. Также следует учитывать, что до версии 3.1.4 сервер GlusterFS не подключения подключения с непривилегированных портов, поэтому если ваша домашняя (клиентская) машина находится за NAT или подключена к интернету с помощью VPN или чего-то вроде этого, вы не сможете подключиться к GlusterFS-серверу. В версии 3.1.4 разработчики добавили опцию, которая отключает это странное поведение, но лично я просто выпилил из исходников кусок кода, реализующий эту функциональность и собрал собственный RPM-пакет. Скоро я выложу этот RPM, пните меня если я забуду это сделать. Короче, устанавливайте любую версию выше 3.1 и приступайте к следующему шагу.
Для начала вы должны создать один или несколько томов для хранения своих данных и запустить демон GlusterFS на сервере. Делается это примерно так:
// Выбираем устройство, которое будет использовано для хранения данных,
// создаем на нем новую файловую систему и монтируем ее
# mkfs -t ext4 /dev/sdxX
# mkdir /mycloud
# mount -o noatime,user_xattr /dev/sdxX /mycloud
// Создаем новый GlusterFS-том и расшариваем его в сеть
# gluster volume create mycloud внешний.IP.адрес.машины:/mycloud
# gluster volume start mycloud
Уже после этого вы получите возможность смонтировать том "mycloud" с помощью GlusterFS-клиента, но сделать это не получиться если порт сервера будет закрыт брэндмауэром (как и произошло в моем случае с сервером Rackspace). Чтобы решить эту проблему достаточно выполнить две простые команды, хотя я бы не рекомендовал использовать этот метод по причинам, которые я опишу позже:
// Смотрим на каком порту висит сервер GlusterFS
# netstat -lpn | grep glusterfsd
// Открывем этот порт с помощью iptables
# iptables -I INPUT -p tcp --dport 24009 -j ACCEPT
Также вы можете добавить несколько правил, которые будут актуальные для вас (например, ограничить доступ к сервису только со своего IP-адреса - прим. пер.). Причина же, по которой этот метод не слишком удачен заключается в том, что после открытия порта, доступ к вашему хранилищу будет открыт всем, а это не очень хорошая идея с точки зрения безопасности. Вместо этого я бы рекомендовал использовать что-нибудь вроде туннеля, который позволит ограничить доступ к хранилищу и зашифровать передаваемые по сети данные. Сделать это можно с помощью SSH (естественно, на сервере должен быть запущен SSH-демон):
# ssh -L24009:localhost:24009 я@мой.облачный.сервер
Следующее, что мы должны сделать, это создать так называемый "vol-файл", содержащий мета-данные хранилища. Делать это не обязательно, однако он поможет нам сохранить несколько сотен нервных клеток и десяток секунд времени при монтировании. Пример такого файла находится на сервере по адресу /etc/glusterd/vols/mycloud/mycloud-fuse.vol. Скопируйте его на клиентскую машину и отредактируйте так, чтобы он выглядел примерно так:
volume mycloud-client-0
type protocol/client
option remote-host localhost
option remote-port 24009
option remote-subvolume /mycloud
option transport-type tcp
end-volume
Теперь смонтируйте удаленное хранилище к своему локальному каталогу. Без использования vol-файла, команда монтирования будет выглядеть так:
# mount -t glusterfs мой.облачный.сервер:mycloud /mnt/mycloud
Но гораздо удобнее делать так:
# mount -f ~/mycloud-fuse.vol /mnt/mycloud
Теперь у вас есть сетевое хранилище файлов, доступное через зашифрованный интернет-канал, однако данные на удаленном сервере до сих пор доступны любому, кто может получить доступ к этому серверу (здесь речь идет о сотрудниках компаний, сдающих сервер в аренду - прим. пер.). Другими словами, вы уже имеет эквивалент одного из многочисленных облачных хранилищ, включая те, за использование которых платите деньги. Все что осталось сделать, это настроить шифрование данных так, чтобы доступ к ним могли получить только вы. Эту задачу можно решить с помощью плагинов к GlusterFS, доступных в CloudFS. Для этого получите этот код, скомпилируйте и установите его (это модуль для выполнения AES-шифрования на лету - прим. пер.). После этого откройте полученный ранее vol-файл и добавьте в него следующие строки:
volume mycloud-crypt
type encryption/crypt
option key %0123456789abcdef0123456789abcdef
subvolumes mycloud-client-0
end-volume
Ключ (key) может быть любым, длиной 128, 192 или 256 бит. Его можно сохранить в файл и прописать путь до файла вместо самого ключа. Простой способ сгенерировать такой ключ, это воспользоваться командой dd:
# dd if=/dev/urandom bs=16 count=1 | od -tx1 -An | tr -d '\n '
Можете вновь примонтировать хранилище используя vol-файл и вы получите полное шифрование данных в самом хранилище и при их передаче по сети с хранением всех ключей шифрования на вашей клиентской машине (машинах). На некоторых операциях производительность работы такой связки может быть не очень хорошей, но за все время использования я не заметил особых проблем со скоростью. Когда-нибудь я закончу работу над "UID-mapping translator", так что вы сможете использовать систему с разных машин, используя различные учетные записи. Также я работаю над транспортным SSL-модулем, который позволит получить шифрование канала связи без использования SSH-туннеля. Но знаете что может быть круче этого? Используя GlusterFS 3.2 (уже вышел - прим. пер.) вы сможете настроить репликацию данных между двумя серверами, купленными у разных облачных провайдеров, так что если один из них отвалится, ваши данные останутся доступны. С помощью CloudFS 1.0 вы сможете сделать все то же самое, но намного быстрее и с приемлемой производительностью.
UPDATE: Некоторые люди с Hacker News правильно сказали, что описанное в этой статье не эквивалент Dropbox. Да, это скорее подключаемая напрямую сетевая файловая система, которая представляется мне гораздо лучшим выбором. Но если вы хотите получить что-то действительно похожее на Dropbox, вы должны сделать две вещи. Чтобы получить функцию синхронизации данных и возможность работы с файлами при отсутствии интернета, вы должны добавить к этой связке еще один компонент: дополнительный каталог и инструмент синхронизации файлов, подобный rsync, Unison или lsyncd. Чтобы получить GUI вы можете установить на сервер одно из сотен Web-приложений для управления файлами, смонтировать том GlusterFS локально и указать точку монтирования в качестве корня этого приложения. Но я бы не рекомендовал этого делать, так как в этом случае ваши данные сможет увидеть любой, кто получит доступ к серверу.
PS От переводчика: в ближайшее время я планирую сделать перевод еще одного руководства по созданию своего Dropbox, но с использованием SSH и lypsinс и возможностью работы с данными при отсутствии интернет-подключения. Так что следите за новостями.
