Важные отличия от других распределенных файловых систем
- Поддерживает автоматическую репликацию данных между серверами.
- Поддерживает моментальные снимки пользовательских папок
- Находится в стадии разработки, не рекомендована для промышленного применения, тем не менее уже входит в стандартные пакеты Ubuntu и ядро Linux.
Настройка сервера, Ubuntu
Изначально имеет: Ubuntu Server в минимальном варианте внутри VMWare, на жестком диске файловая система / – Ext4, /data – btrfs
Всё выполняем от имени root (oneiric – название дистрибутива, на сайте есть список поддерживаемых)
wget -q -O- https://raw.github.com/NewDreamNetwork/ceph/master/keys/release.asc \
| apt-key add -
tee /etc/apt/sources.list.d/ceph.list <<EOF
deb http://ceph.newdream.net/debian/ oneiric main
deb-src http://ceph.newdream.net/debian/ oneiric main
EOF
apt-get update
apt-get install ceph
Прописать в hosts IP-адреса ваши сервера s0, s2, s3
Создать файл cluster.conf
[global]
auth supported = cephx
keyring = /etc/ceph/$name.keyring
[mon]
mon data = /data/mon.$id
[mds]
[osd]
osd data = /data/osd.$id
osd journal = /data/osd.$id.journal
osd journal size = 1000
[mon.a]
host = s1
mon addr = 192.168.59.10:6789
[mon.b]
host = s2 mon addr = 192.168.59.12:6789
[mon.c]
host = s3
mon addr = 192.168.59.13:6789
[osd.0]
host = s1
[osd.1]
host = s2
[osd.2]
host = s3
[mds.a]
host = s1
Создать на каждом сервере папку с данными, например для s0 mkdir /data/osd.0
Сделать безпарольную авторищацию по ssh между серверами.
На каждом сервере создаем свою папку для данных, например на c1 это выглядит так:
mkdir /data/osd.0
На каждом сервере:
mkdir /var/run/ceph
Затем на главном
mkcephfs -a -c cluster.conf -k cluster.keyring
Скопировать на каждый сервер cluster.conf в /etc/ceph/ceph.conf и выполнить /etc/init.d/ceph start
Подождать, пока кластер войдет в рабочее состояние, проверить это можно командой
ceph -k cluster.keyring -c cluster.conf health
Должна появиться надпись:
2011-09-06 12:33:51.561012 mon <- [health]
2011-09-06 12:33:51.562164 mon2 -> 'HEALTH_OK' (0)
На главном сервере:
ceph -k cluster.keyring -c cluster.conf auth list
client.admin
key: AQCBJUlPuIarKRAA1dP4J+Kq+8P0fyZK6MqENg==
caps: [mds] allow
caps: [mon] allow *
caps: [osd] allow *
Отсюда нужна строка key, её вставим в клиента.
Настройка клиента, Ubuntu 11.10
Изначально имеет: Ubuntu Server в минимальном варианте внутри VMWare, на жестком диске файловая система / – Ext4, /data – btrfs
Всё выполняем от имени root (oneiric – название дистрибутива, на сайте есть список поддерживаемых)
wget -q -O- https://raw.github.com/NewDreamNetwork/ceph/master/keys/release.asc \
| sudo apt-key add -
tee /etc/apt/sources.list.d/ceph.list <<EOF
deb http://ceph.newdream.net/debian/ oneiric main
deb-src http://ceph.newdream.net/debian/ oneiric main
EOF
apt-get update
apt-get install ceph
mkdir /ceph
mount -t ceph 192.168.59.10:6789:/ /ceph/ -vv -o name=admin,secret=AQCBJUlPuIarKRAA1dP4J+Kq+8P0fyZK6MqENg==
secret – строка, полученная при настройке сервера
Тест внутри VMWare на домашнем ноутбуке
На домашнем ноутбуке настроил кластер из 3-х серверов, по 512МБ памяти на каждом, подключил к ним 3-х клиентов. На положить-отдать файл всё работает, изменения показываются.
Запустил на одном из клиентов bonnie++. Некоторое время всё работало, потом подвисло на стадии “Delete files in random order...”, два сервера хранения из 3-х заняты на 100% процессами (на одном cosd, на втором cmon). Запустил ls /ceph на одном из клиентов – завис намертво.
Из-за чего завис непонятно – может просто ресурсов нехватило – на каждом сервере было 512МБ памяти, а рекомендуется несколько гигабайтов. Надо пробовать на более мощном железе.
Тест внутри Hyper-V
В кластере 3 серверные машины, на каждой 4 ядра процессора и 4Гб памяти, Linux s2 3.0.0-12-generic-pae #20-Ubuntu SMP Fri Oct 7 16:37:17 UTC 2011 i686 i686 i386 GNU/Linux
1 Сервер метаданных, 3 сервера с данными, 2 клиента, нагрузка с одного клиента, вторым наблюдаю изменения визуально
Провожу нагрузочный тест bonnie++.
Эталон bonnie++ на локальной файловой системе выполнялся 7 минут, на распределенной выполняется уже больше 5 часов, думаю конкретных цифр можно уже не дожидаться. Попробовал перенести файлы журналов в память (tmpfs) кардинальных изменений не увидел – за 40 минут выполнились только первые 2 теста.
При выключении кластера обращения к нему с клиентских машин просто зависают, вместо того чтобы отвалиться.
При удалении через rm –rf папок внутри ceph на 32-битных клиентах возникает ошибка, что папка ресурсивно зациклена, в багрепортах отмечено что это из-за 32-битности – inode 64-битные и 32-битная уникальность не соблюдается.
В общем для использования на данный момент не подходит.