Базовая настройка кластера Ceph на простом примере

Конфиг кластера:

  • Ноды кластера: 2 штуки с CentOS 7
  • HDD: 1 для os + 2 для кластера
  • Сеть: 172.22.12.0/24

Подготовка

Устанавливаем на все ноды кластера ntp и импортируем ssh ключи для без парольного доступа пользователю root:

Добавляем необходимые репы на ноду с которой будем запускать ceph-deploy:

Создаем репу Ceph релиз jewel для CentOS 7

Устанавливаем ceph-deploy

Создаем директорию для размещегия конфигов кластера при деплое

Создаем непосредственно кластер ceph

Добавляем в файл ceph.conf в директории mycluster следующие строки:

У вас должно получится что-то вроде этого:

Остановимся на том беспределе, что мы внесли в конфиг. Строка public network = 172.22.12.0/24 указывает кластеру менеджмент сеть. По ней так же будет осуществляться и репликация данных между нодами. В боевых системах стоит разделять эти вещи в разные сети и вешать на разные сетевые интерфейсы. Строка osd pool default size = 2 говорит о том, что мы будем использовать репликацию с коэффициентом 2, по умолчанию ceph использует реплику 3, но так как у нас всего две ноды и реплика будет идти между ними, то выбор очевиден. Последняя запись osd_crush_update_on_start = false запрещает ceph управлять CRUSH картой кластера. Ее мы будем править руками и импортировать в кластер.
Так как я запускаю ceph-deploy с ноды кластера, то нужно закоментить репу ceph, чтобы при установке основных пакетов скрипт правильно отработал. Если вы запускаете деплой со своего ноута или PC, тогда этот шаг можно пропустить.

Инсталим ceph на ноды ceph1 и ceph2 явно указывая версию кластера --release jewel

Если все прошло успешно — инсталим монитор mon и создаем ключи для ceph. Монитор в нашем случае один, так как для создания кворума нужно нечетное число мониторов, а нод у нас всего две. Но для тестов пойдет. Главное, когда будете ломать кластер не убивайте ноду с монитором или не останавливайте сервис ceph.mon. Или добавте еще одну ноду без дисков и разместите на ней монитор и на второй ноде с дисками. Итого у вас будет их три, тогда и ломайте.

Создаем osd, т.е. включаем наши диски, выделенные для данных на нодах в кластер. В моем случае я использую диски vdb и vdc на обеих нодах. Журналы osd у меня будут хранится на тех же дисках, ceph автоматом создаст под них партиции. Можно конечно скормить и директории в системе в роли дисков, но для удобства, я рекомендую под osd отдавать непосредственно сам диск или на крайний случай lvm.

Данная команда сотрет все данные с дисков и отформатирует их в xfs.
Копируем конфиг ceph который мы заполняли в самом начале в файлике ceph.conf на все наши ноды кластера командой:

Тепрь займемся созданием CRUSH карты. Вытягиваем текущую карту кластера командой:

Декомпилируем ее в человеческий формат:

И приводим ее к такому виду:

Компилируем ее обратно и скармливаем ceph:

Проверяем состояние кластера командой ceph -s. Через какое то время он перестроит pg и вывод будет примерно таким:

Чтобы проверить карту osd сделаем так:

Здесь мы видим что все osd, они же диски имеют статус UP и относятся нужным нодам, согласно нашей crush карте. На этом создание кластера закончено. Далее будем создавать пулы RBD и CephFS.

Создание CephFS

Для функционирование распределенной файловой системы служат серверы mds. на них хранятся метаданные. В нашем случае мы создадим два сервера метаданных на обеих нодах в режиме standby_replay (главный и запасной). В случае отказа основного mds его роль подхватит второй. Важное замечание: в нашей тестовой схеме только один сервер мониторов mon, поэтому важно обеспечить его доступность. В продакшене у вас должно быть три и более монитора. Еще одно замечание: если у вас вдруг будут недоступны сервера mds, то файловые операции просто застопорятся. При восстановлении работы сервера метаданных — система продолжит работу.
Создадим сервера MDS на ceph1 и ceph2:

Создадим пулы для данных и метаданных в кластере для нашей файловой системы:

Если посмотреть состояние кластера после создание пулов, то будем иметь следующую картину:

В данный момент кластер занят ребалансировкой и созданием pg. Через несколько секунд снова проверяем статус и видим что все ок:

Установим пулам cephfs_data и cephfs_metadata режим реплики size 2, обеспечим работу кластера в режиме деградации пока доступна хотя бы одна копия данных в пуле min_size 1 и укажем правило репликации pg crush_ruleset 0 согласно нашей crush карте, что значит реплицировать пул между хостами кластера.

Создаем нашу фаловую систему:

Посмотрим на состояние кластера и увидим, что файловая система создалась

Проверим статус наших серверов метаданных:

Нам сообщают, что в данный момент активен mds на ноде ceph2 и второй (ceph1) в режиме standby. Если погасить сервис mds на ноде ceph2, то активным станет mds на ceph1.

Перейдем к созданию пользователя для аунтификации при монтировании файловой системы на клиентах, так как делать это от админа не очень хорошо в целях безопасности. Дадим пользователю cephfs права на чтение из mon и mds и полные права на пулы cephfs_data и cephfs_metadata

У вас должен был создаться новый пользователь в кластере:

Монтирование файловой системы на клиенте

Монтировать будем через модуль ядра. Для этого нам нужно установить недостающие пакеты на клиенте:

Создадим файл ключа пользователя cephfs для монтирования FS на клиенте и директорию для монтирования /mnt/cephfs:

В отличии от glusterfs в cephfs можно монтировать сразу директории из корневой fs. В нашем случае у нас их пока нет, поэтому понтируем корень. Команда имеет следующий формат mount -t ceph [mon_ip_or_fqdn]:[mon_port]:/ /mnt/cephfs/ -o name=cephfs,secretfile=[path_secretfile]. Порт монитора можно опустить, так как он стандартный:

Смотрим вывод dh -h и видим, что cephfs примонтирована и ее текущий размер 20GB. Это полезный объем данных, сырой объем в кластере 20GB (4 osd по 10GB реплика 2):

Собственно можно пользоваться и проводить тесты.

Работа с блочными устройствами RBD и взаимодействие с libvirt

При создании кластера ceph по умолчанию создается пул rbd. С ним мы и будем работать. Вы можете создать отдельный пул или несколько для работы с libvirt, все зависит от ваших нужд. К примеру пул для gold image и пул для vm image. В пулах мы будем размещать блочные устройства и отдавать виртуалкам в виде дисков и получить кучу плюсов. Помимо надёжности и производительности RBD также предоставляет функциональность корпоративного уровня подобную полным и инкрементальным снимкам, динамичному выделению (thin provisioning), клонированию копированием при записи (copy on write), динамическое изменение размеров и тому подобное. RBD также поддерживает кэширование в памяти.
Вернемся на любую из нод кластера и посмотрим статистику занятого места по пулам:

Мы видим три пула: rbd, cephfs_data, cephfs_metadata которые имеют одинаковую емкость. Это обусловлено тем, что каждому пулу изначально доступно все место в кластере. Расширяя объем кластера — вы автоматически расширяете все пулы. Хорошо это или плохо — решать вам.
Теперь перейдем к созданию пользователя libvirt в ceph. Тут все аналогично как и с cephfs, только мы не указываем права на mds, так как для работы блочных устройств сервер метаданных не нужен. Даем права на чтение из mon и полные права на пул rbd. прошу обратить внимание, что пулы которые мы создали для cephfs не будут доступны пользователю libvirt. Это хорошо и правильно.

Создадим блочное устройство в пуле rbd размером 10G:

Если посмотреть информацию по vm-test.img то увидим, что оно не занимает место на диске. Это дополнительная плюшка ceph, которая и реализует thin provisioning

Идем на гипервизор и создаем файл секрета для доступа libvirt к ceph rbd:

Импортируем файл через virsh:

Устанавливаем ключ пользователя libvirt из ceph который мы получили выше:

Правим конфиг виртуалки через virsh edit vm-test, которой хотим отдать блочное устройство из ceph

Небольшое пояснение: <source protocol='rbd' name='rbd/vm-test.img'> сообщает, что мы будем использовать блочное устройство с именем vm-test.img которое находится в пуле rbd. Пул и rbd диск должен существовать (и то и другое было создано выше). Указываем наш монитор <host name='172.22.12.31' port='6789'/>. Их должно быть столько же, сколько у нас мониторов. Реализуется просто добавлением аналогичных строк в секции <source></source>. Тут мы передаем указатель на секрет, созданный выше <secret type='ceph' uuid='36607386-41fe-4730-9c13-624081e5d21a'/>.
Если у вас гипервизор находится на ноде, которая не входит в кластер ceph, то придется установить пакеты ceph для обеспечения работы. Нормальной практикой считается совмещение ролей compute и storage на одной ноде с целью уплотнения потребления ресурсов, энергии и места в стойке.

На этом все, спасибо за внимание и всем кто дошел до конца статьи. Понадобилось много терпения чтобы дописать ее до конца.