В своей работе (системный администратор) приходится всегда искать вещи и знания, уникальные для своего региона. Одной из таких вещей в нашей конторе является ProxMox, поставленный на файловой системе ZFS, позволяющей использовать неплохой raid массив без использования железных контроллеров. Однажды, думая, чем можно еще удивить и порадовать клиентов, мы решили всё это водрузить на распределенную файловую систему Ceph. Не знаю уж, насколько было такое решение адекватным, но я решил воплотить желание в жизнь. И тут понеслась… Я перелопатил горы статей и форумов, но так и не нашел одного адекватного мануала, описывающего в подробностях что и как делать, поэтому, справившись со всем, родилась эта статья, кому интересно, добро пожаловать под кат.


image



Итак, в принципе, всё делается в консоли и веб-морда ProxMox нам особо не нужна. Делал я всё в тестовом режиме, поэтому было поднято две виртуалки с четырьмя дисками внутри не очень мощного по железу проксмокса (этакая матрёшка). Четыре диска изначально были обусловлены тем, что хотелось поднять, как и на будущем уже не тестовом железе, на ZFS10, но не вышла золотая рыбка по неведомым мне причинам (на самом деле, было лень разбираться). Вышло так, что ProxMox не смог разметить ZFS10 на виртуальных дисках, поэтому было решено использовать немного другую “географию”. На одном из дисков ставился собственно сам ProxMox, на двух других поднимался ZFS1, третий был якобы под журнал Ceph, но я в итоге про него забыл, поэтому пока оставим его в покое. Итак, приступим.


Тут будет небольшая вводная:


Проксмокс у нас свежеустановленный в двух местах. Ноды называются ceph1 и ceph2. Делаем на обеих нодах всё одинаково, кроме тех мест, что я обозначу. Сеть у нас 192.168.111.0/24. Первая нода (ceph1) имеет адрес 192.168.111.1, вторая (ceph2) — 192.168.111.2. Диски на обеих нодам имеют следующие значения: /dev/vda — диск, на котором стоит ProxMox, /dev/vdb и /dev/vdc — диски, предназначенные для ZFS, /dev/vdd — диск для журнала Ceph.


Первое, что нам нужно сделать, это поменять платный репозиторий ProxMox, требующий подписки, на бесплатный:


nano /etc/apt/sources.list.d/pve-enterprise.list

Там комментируем единственную строку и вписываем новую ниже:


deb http://download.proxmox.com/debian jessie pve-no-subscription

Далее обновляем наш ProxMox:


apt update && apt dist-upgrade

Устанавливаем пакеты для работы с Ceph:


pveceph install -version hammer

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


На первой ноде выполняем последовательно:


pvecm create mycluster

где mycluster — это имя нашего кластера.


На второй ноде:


pvecm add 192.168.111.1

Соглашаемся с тем, что нужно принять ssh ключ и вводим пароль root от первой ноды.


Проверяем всё это дело командой pvecm status


Далее инициализуруем конфигурацию Ceph (делается только на первой ноде, которая будет “главной”):


pveceph init --network 192.168.111.0/24

это создаст нам симлинк на /etc/ceph/ceph.conf, от которого мы будем далее отталкиваться.


Сразу после этого нам надо добавить туда опцию в раздел [osd]:


[osd]
    journal dio = false

Это связано с тем, что ZFS не умеет directIO.


Следующее, чем делаем, это готовим наш ZFS пул. Для этого диски нужно разметить в GPT:


fdisk /dev/vdb

Там последовательно нажимаем g и w (g для создания таблицы GPT и w для принятия изменений). То же самое повторяем на /dev/vdc.


Создаем зеркальный ZFS пул, называться он у нас будет как принято в ProxMox – rpool:


zpool create rpool mirror /dev/vdb /dev/vdc

Проверим командой zpool status -v и получим (по крайней мере должны):


pool: rpool
state: ONLINE
scan: none requested
config:
    NAME    STATE               READ    WRITE   CKSUM
    rpool   ONLINE              0       0       0
        mirror-0    ONLINE          0       0       0
            vdb     ONLINE      0       0       0
            vdc     ONLINE      0       0       0
errors: No known data errors

ZFS пул у нас создан, пришло самое время заняться самым главным — ceph.


Создадим файловую систему (странное название, но оно взято с доки по ZFS) для нашего монитора Ceph:


zfs create -o mountpoint=/var/lib/ceph/mon rpool/ceph-monfs

Создадим сам монитор (сначала на первой ноде, потом на второй):


pveceph createmon

Далее начинается то, с чем пришлось повозиться, а именно то, как сделать блочное устройство для Ceph OSD (а он именно с ними и работает) в ZFS и чтобы оно еще и работало.


А делается всё просто — через zvol:


zfs create -V 90G rpool/ceph-osdfs 

90G — это то, сколько мы отдаем нашему Ceph на растерзание. Так мало потому, что сервер виртуальный и больше 100G я ему не давал.


Ну и сделаем сам Ceph OSD:


ceph-disk prepare --zap-disk --fs-type xfs --cluster ceph --cluster-uuid FSID /dev/zd0

--fs-type у нас выбран XFS потому, что XFS — это дефолтная ФС у Ceph. FSID — это ID нашего Ceph, который можно подсмотреть в /etc/ceph/ceph.conf. Ну, и /dev/zd0 — это наш zvol.


Если после этого у вас df -h не покажет примерно такое:


/dev/zd0p1         85G   35M   85G   1% /var/lib/ceph/osd/ceph-0

значит что-то пошло не так и вам либо нужно перезагрузиться, либо ещё раз нужно выполнить создание ceph OSD.


В общем то, на этом мы уже сделали наш ceph и можно дальше им рулить уже в вебморде ProxMox и создать на нем нужное RDB хранилище, но вы не сможете его использовать (собственно, ради чего всё это затевалось). Лечится простым способом (для этого всё-таки хранилище надо создать) — нужно скопировать ключ ceph с первой ноды во вторую.


Открываем конфиг хранилищ ProxMox:


nano /etc/pve/storage.cfg 

И вписываем туда нужный нам RBD:


rbd: test
    monhost 192.168.111.1:6789;192.168.111.2:6789
    pool rbd
    krbd 1
    username admin
    content images

Здесь test — это имя нашего хранилища, а IP адреса — это то, где находятся ceph мониторы, то есть наши проксмоксы. Остальные опции дефолтные.


Дальше создаем папочку для ключа на второй ноде:


mkdir /etc/pve/priv/ceph

И копируем ключ с первой:


scp ceph1:/etc/ceph/ceph.client.admin.keyring /etc/pve/priv/ceph/test.keyring

Здесь ceph1 — наша первая нода, а test — имя хранилища.


На этом можно ставить точку — хранилище активно и работает, можем пользоваться всеми плюшками ceph.


Спасибо за внимание!


Для того, чтобы всё это поднять, пользовался данными ссылками:


» https://pve.proxmox.com/wiki/Storage:_Ceph
» https://pve.proxmox.com/wiki/Ceph_Server
» http://xgu.ru/wiki/ZFS
» https://forum.proxmox.com

Поделиться с друзьями
-->

Комментарии (10)


  1. Faight
    27.12.2016 13:03
    +4

    В чем смысл создавать osd поверх zfs? Ceph и так обеспечит необходимую вам реплекацию данных. Тем более вы не используете распредленную файловую систему cephFS, а подключаетесь через RBD.


    1. farcaller
      27.12.2016 13:43
      +1

      Аналогичный вопрос, конкретно мне не понятно зачем делать zfs mirror. Это где-то так же, как ставить ceph на mdraid1? Вы теряете в гибкости crushmap, а что получаете—я толком даже и не знаю?


    1. SinTeZoiD
      27.12.2016 13:44
      +3

      Что бы потом рассказывать какой CEPH плохой, кривой и не работает. Какой-то в этом особый смысл.


    1. celebrate
      28.12.2016 01:19

      Ну я вижу, как минимум, два потенциальных довода в сторону OSD на ZFS:
      1) Цеф не следит за чексуммами объектов, а ZFS следит.
      2) CoW в ZFS позволяет избежать оверхеда двойной записи на диск OSD (сначала в журнал, потом на диск). Для небольших кластеров, где нет денегвозможности юзать SSD под журналы, ZFS отлично подходит.

      Why not?


      1. gbg
        28.12.2016 10:03
        +1

        1) в ceph контрольные суммы считаются и проверяются во время scrub

        2) засовывание osd на zfs со включенным журналом невозможно — ругаться будет (как раз в формате «у меня уже есть журнал, зачем мне еще журнал?»). Встроенный в ceph журнал придется вырубить. Ваш совет теряет смысл.


        1. celebrate
          28.12.2016 12:47

          1) Все верно, но Цеф не хранит информацию о чексуммах объектов в кластере, по крайней мере в реализации FileStore, возможно в BlueStore уже это пофикшено. Так или иначе, если у вас фактор репликации 2 и у вас разошлись чексуммы двух реплик объекта, то Цеф вывалит pg inconsistent и сам ничего делать не будет, оставляя решение за админом. То же самое при факторе репликации, например 3, если для объекта в данный момент существует только две копии.
          ZFS хранит у себя чексуммы всех файлов и при несовпадении блокирует доступ. Цеф расценивает это как отсутствие объекта и пересоздает реплику.

          2) Да ладно, что вы такое говорите. Год назад по приколу сетапил OSD на ZFS и все прекрасно работало. Пришлось опцию «filestore journal parallel» = true выставить, чтобы работало как на btrfs.

          Я лично давно задумывался о том, чтобы держать OSD на ZFS. Единственное, что меня останавливает — непонятный статус ZFS on Linux, то ли стабильный, то ли нет.


  1. gbg
    27.12.2016 14:01
    +3

    Ужас какой. Вы мануал от ceph открывали? Там английским по белому написано:

    We recommend using a dedicated drive for the operating system and software, and one drive for each Ceph OSD Daemon you run on the host


    Один диск — один демон OSD.

    А вы что натворили?

    Пока все прогрессивное админство с интересом тестирует (в лабе, не на проде) Bluestore (это такой бэкэнд, чтобы ceph работал поверх дисков, а не поверх ФС), вы творите лажу.


    1. Faight
      27.12.2016 14:46
      +4

      С нетерпением жду, когда он станет production ready.


    1. celebrate
      28.12.2016 01:20

      Что не отменяет возможности использовать ZFS просто как файловую систему для OSD.


      1. n1nj4p0w3r
        28.12.2016 18:50

        Вы можете использовать и перфокарты при должном старании, есть ли в этом хоть доля разумности?