Важные отличия от других распределенных файловых систем

1. Поддерживает автоматическую репликацию данных между серверами.
2. Поддерживает моментальные снимки пользовательских папок
3. Находится в стадии разработки, не рекомендована для промышленного применения, тем не менее уже входит в стандартные пакеты 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-битная уникальность не соблюдается.

В общем для использования на данный момент не подходит.