Распределенная файловая система Ceph FS за 15 минут

image

Нам понадобится всего лишь несколько минут для того что бы поднять распределенную файловую систему Ceph FS

Краткая справка

Ceph — это open source разработка эластичного легко масштабируемого петабайтного хранилища. В основе лежит объединение дисковых пространств нескольких десятков серверов в объектное хранилище, что позволяет реализовать гибкую многократную псевдослучайную избыточность данных. Разработчики Ceph дополняют такое объектное хранилище еще тремя проектами:

  • RADOS Gateway — S3- и Swift-совместимый RESTful интерфейс
  • RBD — блочное устройство с поддержкой тонкого роста и снапшотами
  • Ceph FS — распределенная POSIX-совместимая файловая система

Описание примера

В моем небольшом примере я использую всего 3 сервера в качестве хранилища. В каждом сервере мне доступно 3 SATA диска: /dev/sda как системный и /dev/sdb и /dev/sdc под данные файловой системы Ceph FS. ОС в этом примере будет Ubuntu 12.04 LTS. Еще один сервер будет монтировать файловую систему, то есть по сути выступать клиентом. Используем уровень избыточности по-умолчанию, то есть две реплики одного блока.

На момент написания статьи разработчики предлагают два метода создания простых конфигураций — старый, используя mkcephfs или новый ceph-deploy. Для новых версий, начиная с ветки 0.6x (cuttlefish), уже рекомендуется использовать ceph-deploy. Но в данном примере я использую более ранний, стабильный релиз ветки 0.56.x (bobtail), применяя mkcephfs.

Сразу предупрежу — Ceph FS на данный момент все еще находится в препрадакшн статусе, но по активности сообщества этот проект называют одним из самых горячих среди software defined storage.

Приступим.


Шаг 0. Установка ОС

Выполняем минимальную установку. Дополнительно необходимо установить ntpdate и ваш любимый редактор, например vim.

aptitude update && aptitude install ntpdate vim

Шаг 1. Инсталлируем пакеты Ceph

На каждую ноду кластера и клиент устанавливаем пакеты Ceph

wget -q -O- 'https://ceph.com/git/?p=ceph.git;a=blob_plain;f=keys/release.asc' | sudo apt-key add -
echo deb http://ceph.com/debian-bobtail/ $(lsb_release -sc) main | tee /etc/apt/sources.list.d/ceph.list
aptitude update && aptitude install ceph

Шаг 2. Создаем конфигурационный файл

На каждой ноде и клиенте создаем единый файл конфигурации /etc/ceph/ceph.conf

[global]
        auth cluster required = cephx
        auth service required = cephx
        auth client required = cephx

[osd]
        osd journal size = 2000
        osd mkfs type = xfs
        osd mkfs options xfs = -f -i size=2048
        osd mount options xfs = rw,noatime,inode64

[mon.a]
        host = node01
        mon addr = 192.168.2.31:6789

[mon.b]
        host = node02
        mon addr = 192.168.2.32:6789

[mon.c]
        host = node03
        mon addr = 192.168.2.33:6789

[osd.0]
        host = node01
        devs = /dev/sdb

[osd.1]
        host = node01
        devs = /dev/sdc

[osd.2]
        host = node02
        devs = /dev/sdb

[osd.3]
        host = node02
        devs = /dev/sdc

[osd.4]
        host = node03
        devs = /dev/sdb

[osd.5]
        host = node03
        devs = /dev/sdc

[mds.a]
        host = node01

Делаем файл читаемым для всех

chmod 644 /etc/ceph/ceph.conf

Шаг 3. Делаем безпарольный вход между нодами

Задаем рутовый пароль, генерируем ssh ключи без указания пассфразы

passwd root
ssh-keygen

Создаем ssh алиасы в /root/.ssh/config соответственно наименованию нод в вашем случае

Host node01
        Hostname node01.ceph.labspace.studiogrizzly.com
        User root
Host node02
        Hostname node02.ceph.labspace.studiogrizzly.com
        User root
Host node03
        Hostname node03.ceph.labspace.studiogrizzly.com
        User root

Добавляем публичные ключи на соседние ноды кластера.

ssh-copy-id root@node02
ssh-copy-id root@node03

Шаг 4. Разворачиваем кластер

Для начала подготовим необходимые диски к работе

mkfs -t xfs fs-options -f -i size=2048 /dev/sdb
mkfs -t xfs fs-options -f -i size=2048 /dev/sdc

Далее подготавливаем рабочие каталоги и монтируем диски соответственно нашему дизайну

Так для node01 выполним

mkdir -p /var/lib/ceph/osd/ceph-0
mkdir -p /var/lib/ceph/osd/ceph-1
mount /dev/sdb /var/lib/ceph/osd/ceph-0 -o noatime,inode64
mount /dev/sdc /var/lib/ceph/osd/ceph-1 -o noatime,inode64

для node02

mkdir -p /var/lib/ceph/osd/ceph-2
mkdir -p /var/lib/ceph/osd/ceph-3
mount /dev/sdb /var/lib/ceph/osd/ceph-2 -o noatime,inode64
mount /dev/sdc /var/lib/ceph/osd/ceph-3 -o noatime,inode64

и для node03

mkdir -p /var/lib/ceph/osd/ceph-4
mkdir -p /var/lib/ceph/osd/ceph-5
mount /dev/sdb /var/lib/ceph/osd/ceph-4 -o noatime,inode64
mount /dev/sdc /var/lib/ceph/osd/ceph-5 -o noatime,inode64

И наконец, на node01 запускаем скрипт создания хранилища Ceph

mkcephfs -a -c /etc/ceph/ceph.conf -k /etc/ceph/ceph.keyring

а затем скопируем ключ ceph.keyring на другие ноды кластера

scp /etc/ceph/ceph.keyring node02:/etc/ceph/ceph.keyring
scp /etc/ceph/ceph.keyring node03:/etc/ceph/ceph.keyring

и на клиентскую ноду, в моем случае — 192.168.2.39

scp /etc/ceph/ceph.keyring 192.168.2.39:/etc/ceph/ceph.keyring

Ключам выставляем доступ на чтения

chmod 644 /etc/ceph/ceph.keyring

Шаг 5. Запуск и статус

Благодаря беспарольному входу между нодами выполняем старт всего кластера с любой ноды

service ceph -a start

Там же проверяем состояния кластера

ceph -s

Наиболее ожидаемый статус при нормальной работе это HEALTH_OK

Со стороны клиента создаем каталог в необходимом месте, например /mnt/cephfs, парсим ключ для модуля ядра ceph и монтируем файловую систему

mkdir /mnt/cephfs
ceph-authtool --name client.admin /etc/ceph/ceph.keyring --print-key | tee /etc/ceph/admin.secret
mount -t ceph node01:6789,node02:6789,node03:6789:/ /mnt/cephfs -o name=admin,secretfile=/etc/ceph/admin.secret,noatime

Послесловие

Вот таким образом получаем распределенную файловую систему Ceph FS всего за 15 минут. Вопросы производительности, безопасности и обслуживания требуют более детального погружения и это материал на отдельную статью, а то и не одну.

P.S.


Забабахали связку OpenNebula+Ceph используя только объектное хранение Ceph, без файловой системы Ceph FS. Читать подробнее в хабе Я пиарюсь.
Поделиться публикацией

Похожие публикации

Комментарии 108

    +7
    и это материал на отдельную статью, а то и не одну.

    Почитал бы с удовольствием!
      +1
      Поддерживаю.
      Давно смотрю на эту ФС, один раз даже заводил для тестов.
      С удовольствием почитал бы.
        0
        Уже в процессе. Скоро будет.
          +1
          Год прошел, ждем ждем :)
      0
      Когда добавляете новые диски — надо руками править /etc/ceph/ceph.conf и раскладывать потом на все машины, после чего перезапускать всё?
        +1
        Нет. Кроме правки самого конфига надо еще обновить CRUSH map. Его надо вытащить, декомпилировать, подправить, скомпилировать и скормить ceph-у обратно.

        Сам изпользую ceph уже пару месяцев. Штука просто шикарная я вам скажу.
          0
          Данные то хоть потом сами разъедутся? Тестировали работу при деградации сети?
            0
            Да, в соответствии с «весом» каждого диска, ноды, шкафа. Да, забавные баги наковырял когда-то, уже пофиксить должны были.
            0
            crush не обязательно править руками(во всяком случае сейчас). через #ceph osd crush все делается.
          +3
          Стоит отметить, что для сносной работы требуется 10GB сеть.

          Consider starting with a 10Gbps network in your racks. Replicating 1TB of data across a 1Gbps network takes 3 hours, and 3TBs (a typical drive configuration) takes 9 hours. By contrast, with a 10Gbps network, the replication times would be 20 minutes and 1 hour respectively.
            +1
            было бы так, если бы винт 3Тб реально мог сам работать со скоростью 10 Gbps. А там интерфейс по факту — 6 Gbps, а сам винт ещё медленнее.
              0
              Смотрите, обычно в один сервер ставят больше одно винта.
                +2
                Вообще самое быстрое, что я видел на бытовых винтах и недорогом железе — это 280 мб/сек. Это синкался Software RAID10 на четыре SATA-диска 500 Гб на сервере начального уровня (с процом Xeon серии E3). Каждый из этих винтов способен выдать 140, а поскольку всего их было четыре — обе пары синкались параллельно — мы получили вдвое больше.

                Это — немного больше гигабита, и это линейная запись, т.е. очень хорошая для винтов ситуация. При реальной работе такой скорости, конечно, не добиться, и весь этот RAID10 выдаст заведомо меньше гигабита.

                Нахрена тут десять?
                  0
                  Как уже говорили, потому что винтов может быть десяток на одном хосте, вот и выходит что одновременно возможно копирование блоков с разных устройств.

                  + я почти уверен что как таковыми файлами система не оперирует а оперирует блоками, поэтому работа идёт не с множеством файлов, а множеством блоков, ну и их объем не должен быть черезчур маленьким.
                    0
                    Дополню.
                    Вот посмотрите на верхнюю строчку тут

                    Тут взяли всего один контроллер, пробросили 6 SATA дисков и получили около 800MB/s. Это при блоке в 4MB и btrfs.

                    Давайте представим себе наиболее худшую ожидаемую аварию — пропадает такое количество дисков при такой утилизации хранилища, при которых является необходимым отреплицировать все существующие блоки всех серверов.
                    К примеру, при 12 3TB дисках на каждой ноде и уровне избыточности 2, это может означать необходимость отреплицировать 18 TB данных.
                      +1
                      хочу сказать что это все про сферических коней. Если у вас будет нагрузка по 800МБ/с на запись регулярная на продакшене — вы никогда и ни за что не будете пользоваться подобными решениями. Вы купите Нетапп, МСА2000, поставите Нексенту, зарядите старвинд, на крайняк соберете RAID10/RAID6 на хорошем контроллере с BBU и все будет работать так же. И все будет работать без 10Г и если что-то пойдет не так, Вас лично точно не уволят =)
                      Массив RAID6 из 12 дисков на обычном 12 канальном Адаптеке легко выходит на 1,5-2ГБ в секунду по записи, что бы его прогрузить действительно нужна 10Г. Только вот задач такие встречаются крайне редко — может быть HD видео-монтаж?
                        0
                        Смотрите, Ceph это полностью распределенное объектное хранилище. Наличие абстрактного уровня Группы Размещения (Placement Group) позволяет очень гибко обслуживать репликацию блоков. У хранилища нет SPF. Отказ диска, ноды или шкафа с нодами не приводит к даунтайму, при правильном проектировании даже просадки производительности не будет при восстановлении. Архитектура может содержать несколько десятков серверов. Масштабирование горизонтальное и полностью прозрачное.
                          0
                          MongoDB+GridFS?
                            0
                            Как вариант к обсуждению по сравнению только с CephFS. Согласен с вами.
                              0
                              Posix будет? :)
              +3
              собирается все здорово, но надо бы сделать лабу на 3-4 машины с 8 дисками на каждой, смонтировать том на ноду и погонять тестами скоростными по IOPS и миграции ВМ туда-сюда. и услышать отзывы публики почтненной которая хотя бы год юзала это на продакшене плотно.
              по ходу пьесы подергать сетевые кабеля на машинах =) Хотите дадим машины для лабы, а вы отчет напишите полный?
                0
                я хочу! вот только не в москве…
                  0
                  Коллеги тестили, пытались положить туда нейм-ноду хадупа. Как только сеть начинала работать не идеально — ceph вставал колом.
                    0
                    Расскажи плз поподробнее, интересна архитектура которую вы собирали.
                      0
                      Подтверждаю. При маломальской нагрузке если перейти на другую ноду, образ виртуалки оказывается битым.
                      Как минимум, для применения в виртуализации еще сыро
                        0
                        а вы образ держали в файлике на ceph или же непосредственно в rbd?
                          0
                          Хотелось бы то же узнать это. Так как все советуют rdb для виртуализации.
                            0
                            в файлике на ceph, ибо с файлами удобно работать.
                            какие есть принципиальные различия rbd с точки зрения применения в продакшене для несложной виртуализации (2 ноды) и давно стабильно работающего drbd?
                              0
                              есть. drbd надёжнее в двух-новодом + меньше нагрузка на сру
                                0
                                Ceph обычно делают минимум на 3 ноды.
                                Дело в том, что демоны мониторинга mon находятся в кворуме — большинство определяет состояние кластера. То есть комбинации 1, 2:3, 3:5, 4:6 и т.д.
                              0
                              Уверен Вы про CephFS.
                              Для виртуализации замечательно подходит RBD, который можно использовать в продакшн.
                                0
                                Кстати, вы не сможете пособить советом в каком направлении читать — хочется попробовать развернуть proxmox с rbd?

                                Это конечная цель, но даже если говорить о последовательном приближении: вот qemu поддерживает rbd как сторадж, как это запускать с rbd?
                                  0
                                  У меня пока еще не было возможности познакомится с Proxmox поближе, но думаю что можно начать с этого.
                                    0
                                    Отлично, если у меня железо с аппаратным раидом — стоит сделать там действительно массив и один OSD, или же пусть будет JBOD и куча OSD?
                                      0
                                      Всегда лучше пробовать несколько вариантов. Начните с проброса каждого диска через контроллер и включите на нем writeback, если батарейка живая.
                                        0
                                        Понятно, в таком случае можно будет ему как-то объяснить, чтобы он не зеркалировал одни и те же данные на тот же самый сервер? Я хочу иметь реплики на других нодах, на той же самой они могут быть весьма бесполезны.
                                          0
                                          Такое поведение будет по-умолчанию. Когда поднимете сделайте ceph osd tree и все поймете.
                            0
                            Надо полагать, что вы про rbd говорили, cephfs прямо сильно зависит от тонких настроек под железо.

                            Вот здесь правильные цифры, мы их наблюдаем в продакшне. Ну не год, но полгода будет, да.

                            Вот rbd как раз позволяет гонять туда сюда образы, kvm например, с даунтаймами меньше секунды под нагрузкой.
                              0
                              Вот странная ситуация, у нас у самих есть машины. Но вот совершенно погрязли в работе не очень интересной.
                              Вы случайно не можете увеличить кол-во времени в сутках? :) Я бы тогда точно поигрался и написал отчет.
                                0
                                Это не про поиграться — это надо обязательно делать, если речь идет не про развлечения, а про работу и использование технологии для чего-то полезного. Как вообще себе можно представить использовать что-то не ознакомившись, как оно себя поведет под нагрузкой и в случае банального выпадения кабеля питания или сетевого провода?
                                потом кстати мне не очень понятна экономическая целесообразность таких решений — много старых серверов жрут электричество и занимают место в стойках, выгоднее сделать одну голову с репликацией и подцепить к ней JBOD на нужное количество дисков и идти пить пиво на сэкономленные деньги.
                                каждый активный сервер в хозяйстве — это примерно 200 баксов в месяц на его обслуживание в пересчете на электричество и зарплату админов, за год любая экономия просматривается насквозь.
                                  0
                                  Про поигратся — у меня работа как игра. Все, что новое и на тестирование для меня игра :)
                                  Конечно, перед внедрением чего-то все тестируется, но для меня этам тестов — это игра!
                                  Удачно положить с виду надежную систему или найти баги — это интересно!
                                    0
                                    Основные преимущества software defined storage, что пришли сразу в голову, я перечислил чуть выше.

                                    По поводу экономики — при сравнение надо учитывать намного больше переменных чем только «электричество и зарплату админов», потому что архитектура объектного хранилища совершенно иная от стандартного подхода на голове + JBOD.
                                0
                                А клиенту всё равно к какой ноде цепляться? И, возмжно стоит через днс раздавать ip сереов, тогда при вылете первой он не потеряет хранилище.

                                Но основной вопрос в другом, что у этой штуки с произвоительностью?
                                Как она себя будет вести, если скажем планово выключить хранилище.
                                Т.е. порядок выключения 1,2,3 (на третью что-то успели записать, после выключения 1). потом включаем 1,2 (пытаемся прочитать то, что записали на 3), потом уже включается 3.
                                  0
                                  А клиенту всё равно к какой ноде цепляться? И, возмжно стоит через днс раздавать ip сереов, тогда при вылете первой он не потеряет хранилище.

                                  Клиент «разговаривает» с тремя доступными демонами мониторинга mon.a, mon.b, mon.c.

                                  Но основной вопрос в другом, что у этой штуки с произвоительностью?
                                  Как она себя будет вести, если скажем планово выключить хранилище.
                                  Т.е. порядок выключения 1,2,3 (на третью что-то успели записать, после выключения 1). потом включаем 1,2 (пытаемся прочитать то, что записали на 3), потом уже включается 3.

                                  Все файлы размещаемые на Ceph FS разбиваются на блоки данных которые дублируются на разных физических дисках так, что бы оба дубликата одного и того же блока не попадали на диски одной ноды. В результате каждый блок данных будет случайно записан в двух экземплярах учитывая размещение физических дисков друг к другу. Хранилище не подтверждает команду записи блока данных до момента подтверждения записи от всех элементов участвующих в репликации этого блока.

                                  Плановое выключение, как и аварийное при продуманном дизайне дисковой подсистемы, не приведет к потери каких либо данных.
                                  0
                                  с синхронностью-асинхронностью транзакций как дела обстоят?
                                  +2
                                  mount -t ceph node01:6789:/ /mnt/cephfs -o name=admin,secretfile=/etc/ceph/admin.secret,noatime


                                  Почему монтирование с одним монитором? Надо все указывать.
                                  mon1,mon2,mon3:/ /mnt/cephfs

                                  Иначе, если откажет монитор, клиент повешается, иногда вместе с ядром.

                                  — не рекомендуется маунтить туда, где крутится сам osd
                                  — mds в данном конкретном случае очень важная штука, ей надо подкрутить ресурсов, она при большом количестве файлов жрет их очень много.
                                  — журнал лучше убрать подальше от всего хозяйства, он прямо и четко влияет на производительность.
                                  — btrfs лучше, чем xfs, ext4 тоже можно, но она самая медленная )
                                  — много чего еще из нюансов.

                                  cephfs еще сырой и имеет много нюансов, не отраженных (либо неявно отраженных) в документации. Если эти нюансы не учитывать, то будет все стоять колом.

                                  Мы для себя выбрали radosgw, полет отличный.
                                    0
                                    Да, монтировать можно не все, а в том числе и отдельные пулы. С бубном правда. Но работает.
                                      0
                                      Моя вина, недосмотрел. Поправил, спасибо!

                                      — не рекомендуется маунтить туда, где крутится сам osd
                                      — mds в данном конкретном случае очень важная штука, ей надо подкрутить ресурсов, она при большом количестве файлов жрет их очень много.
                                      — журнал лучше убрать подальше от всего хозяйства, он прямо и четко влияет на производительность.
                                      — btrfs лучше, чем xfs, ext4 тоже можно, но она самая медленная )
                                      — много чего еще из нюансов.

                                      И не только. Хочу написать об этом подробно позднее.
                                      0
                                      Есть проблема у ceph'а определённая, в необходимости выделения сервера под метаданные.
                                      собрать на трёх компах из 3х дисков можно, но эффективность будет ниже плинтуса.
                                        0
                                        Для тех кому уже для продакшена надо подобное и к тому же стабильное — посмотрите на MooseFS
                                          0
                                          Что там у moose случается при падении master server? Все операции записи/чтения обрываются?
                                          Что в случае split-brain?
                                            0
                                            Операции не обрываются, они «замирают» пока новый мастер не поднимится, подхватывается он автоматически, для клиентов это выглядит как временный фриз. Падение чанк-серверов вообще не заметно, как и дисков на них.
                                            Сплин-брейна нет как такового, т.к. метасервер только один + сколько захотите металоггеров, которые при падении мастера можно превратить в мастера.

                                            Музе не без минусов, и мастер-сервер без автофаиловера — его единственный минус мной обнаруженный.
                                            Они у себя советуют использовать ucarp, что я нахожу неприемлемым.
                                            У себя организовал ежесекундный мониторинг с проверкой как по живучести IP, так и на уровне работоспособности порта мастер-процесса.
                                            Переключение металоггера в мастера происходит только если кроме фиксирования падения мастера, видны другие металоггеры и не пингуется IP мастера, что исключает сплин-брейн полностью. На мастере тоже мониторинг, который освобождает IP, если мастер-процесс не отвечает.

                                            Посмотрите еще здесь начиная отсюда и вниз:
                                            habrahabr.ru/post/178533/#comment_6196527
                                              0
                                              А ну да, отсутствие авто-выбора нового master сервера и связанные с этим костыли и проблемы split-brain.
                                              Я смотрел на мусе, но из-за этого даже ставить не стал.
                                              Проблема такая что часть металлгеров могут оказаться в разных кусках разделённой сети — появиться новый мастер и обратно уже не склеешь. Так?
                                                0
                                                Да, это костыль, как расплата за стабильность и надежность. И это единственный фактор для меня, который играет наивысшую степень — данные должны жить, быть доступными и не испорченными при любом катаклизме. Поэтому я не даже не ставил ceph, достаточно просто отзывы о надежности почитать.

                                                Сплит-брейна не существует, это не гластер.

                                                Насчет разделенно сети, всё не так — вторичный мастер прежде чем подняться должен проверить агентов на доступность на всех сегментах.
                                                У меня проще — все сервера к одному свитчу подключены, нет разнесения по стойкам, поэтому достаточно просто другой металоггер проверить и убедиться что упал именно основной мастер.
                                                  0
                                                  Я так полагаю ты имеешь ввиду отзывы о CephFS?
                                                  Многие путаются между CephFS и собственно самим хранилищем Ceph (RADOS). Вот так выглядит «экосистема»:
                                                    0
                                                    да, отзывы именно о cephfs, а вглубь уже не интересно, если на этом уровне работает нестабильно.
                                                    Выглядит конечно ceph привлекательно, похож тот же музе, но говорят пока рано в продакшн. А музе работает уже у многих годами, недовольных не встречал, если есть голова на плечах (например не ставить goal=1, а потом сокрушаться куда же файлы пропали при вылете диска).
                                                      0
                                                      да, отзывы именно о cephfs, а вглубь уже не интересно, если на этом уровне работает нестабильно.

                                                      Не совсем так. CephFS это не уровень, это проект выстроенный «сверху» над хранилищем.
                                                      RBD и RADOS Gateway уже работают у многих в продакшн, погуглите.
                                                      Скорое напишу подробнее о RADOS Gateway.
                                          +1
                                          У меня вопрос: я игрался с cephfs, был впечатлён скоростью на чтение, но крайне разочарован производительностью за запись. Точнее, с линейной скоростью проблем не было, а вот скорость random write просто убивала.

                                          В моём случае я использовал 1 сервер с 8 OSD (каждый OSD на своём винте), плюс отдельные винты для mon и mds.

                                          На выходе я получал производительность записи в файл — примерно половина производительности одного диска.

                                          Это фича или я его готовить не умею?
                                            0
                                            Я видел Ваши вопросы в рассылке ceph-users, Георгий.
                                            Можно мне взглянуть на вашу песочницу, если она еще не снесена?
                                              0
                                              [global]
                                              	auth cluster required = cephx
                                              	auth service required = cephx
                                              	auth client required = cephx
                                              
                                              [osd]
                                              	osd journal size = 1000
                                              	filestore xattr use omap = true
                                              
                                              [mon.a]
                                              
                                              	host = lab
                                              	mon addr = 8.8.8.8:6789
                                              
                                              [osd.0]
                                              	host = lab
                                              	
                                              	devs = /dev/sda
                                              	osd mkfs type = xfs 
                                              
                                              [osd.1]
                                              	host = lab
                                              	devs = /dev/sdb
                                              	osd mkfs type = xfs 
                                              
                                              [osd.2]
                                              	host = lab
                                              	devs = /dev/sdc
                                              	osd mkfs type = xfs 
                                              
                                              
                                              [osd.3]
                                              	host = lab
                                              	devs = /dev/sdd
                                              	osd mkfs type = xfs 
                                              
                                              [osd.4]
                                              	host = lab
                                              	devs = /dev/sde
                                              	osd mkfs type = xfs 
                                              
                                              
                                              [osd.5]
                                              	host = lab
                                              	devs = /dev/sdf
                                              
                                              	osd mkfs type = xfs 
                                              
                                              [osd.6]
                                              	host = lab
                                              	devs = /dev/sdg
                                              
                                              	osd mkfs type = xfs 
                                              
                                              [osd.7]
                                              	host = lab
                                              	devs = /dev/sdh
                                              	osd mkfs type = xfs 
                                              
                                              [mds.a]
                                              	host = lab
                                              


                                              /dev/sda on /var/lib/ceph/osd/ceph-0 type xfs (rw,relatime,attr2,inode64,noquota)
                                              /dev/sdb on /var/lib/ceph/osd/ceph-1 type xfs (rw,relatime,attr2,inode64,noquota)
                                              /dev/sdc on /var/lib/ceph/osd/ceph-2 type xfs (rw,relatime,attr2,inode64,noquota)
                                              /dev/sdd on /var/lib/ceph/osd/ceph-3 type xfs (rw,relatime,attr2,inode64,noquota)
                                              /dev/sde on /var/lib/ceph/osd/ceph-4 type xfs (rw,relatime,attr2,inode64,noquota)
                                              /dev/sdf on /var/lib/ceph/osd/ceph-5 type xfs (rw,relatime,attr2,inode64,noquota)
                                              /dev/sdg on /var/lib/ceph/osd/ceph-6 type xfs (rw,relatime,attr2,inode64,noquota)
                                              /dev/sdh on /var/lib/ceph/osd/ceph-7 type xfs (rw,relatime,attr2,inode64,noquota)
                                              /dev/sdy on /var/lib/ceph/mon type xfs (rw,relatime,attr2,inode64,noquota)
                                              /dev/sdz on /var/lib/ceph/mds type xfs (rw,relatime,attr2,inode64,noquota)
                                                0
                                                Нет, нет. Это я уже видел.
                                                Я имел в виду возможно ли удаленно посмотреть по ssh или teamviewer?
                                              0
                                              На один сервер все ставить они вроде как не рекомендуют, или хотя бы в kvm. Журнал надо однозначно на ssd.
                                              Плюс что-то надо сделать с mds, тоже на быстрый диск и много cpu, самое слабое звено. XFS заменить на btrfs.
                                              С такими допущениями у нас проблем нет вроде со скоростью, все сопоставимо, есть проблемы с количеством файлов в этой штуке.

                                              А какой релиз, кстати, для них вполне нормально даже в минорном релизе что-нибудь громадное пофиксить и допилить.
                                              Почему relatime? noatime?
                                              0
                                              А эта FS принципиально умеет работать с shared storage? Ну есть у меня дисковая полка с FC подключением. Как-то тупо если я один виртуальный диск с полки с одним только узлом зацеплю, весь смысл от multipath теряется…
                                                0
                                                Простите, не осилил до конца вопрос.
                                                Ceph работает с выделенными дисковыми ресурсами посредством файловой системы, в этом примере — xfs. То есть, на презентованом диске должна быть файловая система, а ниже может быть HBA с multipath на LUN дисковой полки.
                                                  0
                                                  разрешите я попытаюсь пояснить

                                                  вот у меня есть полка, подключенная по FC. Один и тот же том на полке видится по multipath на нескольких нодах одновременно. Я так например могу использовать cluster lvm — создал lv на одном сервере, на другом тоже его вижу.

                                                  Могу ли я запустить на разных серверах несколько ODS, подключенных к одному и тому же тому на полке? Как пример, это может быть полезно для отказоусточивости — я таким образом как бы расшариваю в сеть через rados то, что у меня было доступно только через FC и гарантирую, что даже при выходе из строя одного из ODS я буду иметь другую ноду, которая подключена к тому же самому стораджу.
                                                    0
                                                    Логика RADOS в том, что бы разбить данные на блоки и положить их на файловые системы дисковых ресурсов. Во время записи блоки можно продублировать столько раз сколько необходимо на разные физические диски учитывая размещение физических дисков друг к другу (ноды, шкафы). При правильной архитектуре мы можем прозрачно потерять не только диск, OSD демон, но и всю ноду или шкаф.
                                                    Если есть такие простаивающие ресурсы как дисковые полки, их можно попробовать разбить по одному LUN на каждую ноду. Специально закупать классическую СХД под Ceph нет никакого экономического смысла.
                                                      +1
                                                      Резюмируя, не умеет. Более зрелые FS умеют, тот же GPFS, с дешевыми похоже никто не умеет. С glusterfs, например, та же фигня. OCFS2 умеет, но там максимум 32 ноды и они все должны быть подключены к полке.
                                                        0
                                                        Ваша идея уйти от обязательной репликации при падении OSD демона?
                                                          +1
                                                          Именно. Это же демон упал, а не полка. А до полки у меня несколько путей через разные сервера. Как-то тупо кроме RAID50, например, еще и поверх делать репликацию.
                                                            0
                                                            Принимая во внимание то, что отказ демона (или его диска) и восстановление данных будут не заметны для клиента, применение RAID вместе с Ceph выйдет всегда сильно расточительно.
                                                              0
                                                              Вот-вот, почему бы ему не научиться мультипафингу, в том числе.
                                                                0
                                                                Потому что расточительно. Воспринимайте Ceph как RAID только с гранулярнорстью в объект при очень большом количестве дисков с построением карты иерархии/весов (учитывается размещение физических дисков друг к другу).

                                                                Вы же не делаете RAID поверж прицепленых дисков с полки где тоже сделали RAID?
                                                                  0
                                                                  Я не очень понимаю куда вы клоните. Именно что Ceph как раз и провоцирует создать RAID (своими силами) поверх RAID с полки.

                                                                  Может вы не достаточно ясно представляете себе инфраструктуру? Допустим у нас есть несколько дисковых полок, подключаемых по фибре. У них там довольно приличные скорости дискового обмена, гигабайты в секунду. Есть пяток серверов, отвечающих за нашу параллельную ФС. Т.е. они подключены фиброй к полкам, на них крутятся все демоны и прочее. И есть сотня-другая клиентов, которые цепляют к себе ФС с этих файловых серверов и собственно юзают. Одновременно. Так как все серверы хранения подключены ко всем полкам, потеря одного-двух серверов не должна вызвать отказ в работе дисковой подсистемы. В этом заключается с одной стороны возможность максимально использовать пропускную способность полок (разные запросы могут идти разными маршрутами), с другой — отказоустойчивость.

                                                                  Так вот, Ceph в текущем виде предлагает выкинуть полки нафиг, воткнуть винты напрямую в серваки.
                                                                    +1
                                                                    Вы себе решения типа Ceph просто недостаточно точно представляете. Не нужен FC, не нужны дорогие полки. Берёте 5 машин, подтыкаете по обычной SAS полке к каждой, поднимаете Ceph (ну или не Ceph, не суть важно). Более того, делать RAID совсем не надо, лучше от него не станет, а восстанавливать средствами софта получится скорее всего быстрее, чем RAID под нагрузкой соберётся (во всяком случае у нас совсем грустные цифры восстановления получались, скопировать рсинком пару терабайт по гигабитной сети на порядок быстрее). На случай вылета сервера или проблем с сетью у вас и так есть вторая (и даже третья) копия. А поломка SAS канала между дисками и сервером редкость редкая.

                                                                    В чём вы видите профит при наличии нескольких серверов, раздающих данные с одной и той же полки?
                                                                      +1
                                                                      «Редкость редкая» != невозможная, а мультипаф решает ея
                                                                        0
                                                                        Надо понимать, что если уже есть полка, то надо ее использовать по-максимуму, тут цеф не подойдет. Он для тех, кто не хочет больше полок.

                                                                        ceph решает это другими методами. Есть куча osd, на них лежат размазанные кусочки объектов в репликации ^2 (или как настроить).
                                                                        osd вылетел — цеф автоматом сам восстановит данные от соседа. Если восстановить не сможет, значит у вас ошибка в архитектуре. Причем объекты размазываются псевдорандомно, не так, что
                                                                        osd.0 это копия osd.1, а osd.2 — > osd.3. Файл, как видит его клиент, может быть размазан одновременно по 4 дискам. а может и по двум. Или по трем. Причем ceph все время мониторит доступность и скорость дисков и чуть-чего начнет рекавери сам.
                                                                        Вероятность потери данных есть, для этого и придуманы уровни репликации. А если учесть, что osd — это простой блокдевайс с обычной файлухой, то какова вероятность того, что у вас что-то случится одновременно с двумя или тремя дисками с обычной файлухой так, что нельзя восстановить?

                                                                        Если система сложная, то надо сначала продумать и настроить расположение сервисов, CRUSH-карту распределения объектов, веса хранилищ и уровни репликации для пулов.
                                                                        0
                                                                        Профит в том, что полка может выжать допустим 1 ГБ/с, а у серверов сеть 1 Гбит/с. А с мультипафингом можно и больше выжать с инсталляции.

                                                                        А еще профит в том, что полки и фибра у меня уже есть, а сервера под сотни дисков — надо покупать.
                                                                          0
                                                                          Чего выжать-то? Это скорость для клиента? Да лааадно. Файлуха столько не жмет никакая распределенная.

                                                                          С полками другие проблемы — это гибкость и масштабируемость. Ну вот кончилось у вас место, дальше что? Или вам по пику два дня в месяц надо пережить на 100 гб больше, чем у вас есть?

                                                                          Файлуха распределенная как-будто не глючит? ocfs2 да жесть же. gfs2? такая же. Весь кластер в коллтрейс — да легко ))

                                                                          А если полка свалится? С проприетарным контроллером )) С вашей инфой что будет, пока эта полка по сервисам ездит 4 месяца?
                                                                            0
                                                                            Вот в том и грусть-пичяль современности. Вроде и надо, а делать-то не чего :(
                                                                              0
                                                                              Ну у меня на работе, допустим, GPFS до 8 ГБ/с жмет. При 6 сотнях клиентов. Правда соединение InfiniBand.

                                                                              Если у вас полка 4 месяца по сервисам ездит, меняйте системного интегратора что ли. Они по договору обычно менее чем за неделю заменяют железо.
                                                                                0
                                                                                Не пойму. 8 гигабайт в секунду скорость чего? Скорость чтения клиентом с дискового массива? О_о
                                                                                Или это шина прокачивет? Тогда при чем тут GPFS?

                                                                                Менее чем неделю — это круто. Будем менее, чем неделю стоять без данных ога.
                                                                                  0
                                                                                  8 гигабайт — скорость клиента с дискового массива, ага. Ну точнее это скорее максимальная агрегированная скорость со всех клиентов.

                                                                                  Если вы свои данные не бэкапите, то я уж не знаю, ну сидите неделю тогда. Мы как-то по старинке, ленточной библиотекой.
                                                                                    0
                                                                                    Ну то есть клиент читает файл с распределенной файловой системы и скорость чтения у него 8 гигабайт в секунду? cool story!
                                                                                      0
                                                                                      Ну я перепроверю конечно, но на этапе внедрения с тестами iozone было что-то в таком духе.
                                                    0
                                                    Ceph всё также уныло дохнет если вырубить mds?
                                                    В 0.4 в лучшем случае все зависало минут на пять пока новый mds не выбран, а обычно просто обратно ноды не собирались ругаясь на разсинхронизацию. Починили?
                                                      0
                                                      В препродакшн по-прежнему рекомендуют ставить не более одного mds.
                                                      Я пробовал то, о чем вы написали на версии 0.56.4 — задержка при создании/удалении файлов была, но измерялась секундами.
                                                        0
                                                        Один mds? Fault tolerance говорите? Ну-ну…
                                                        Хотел бы попросить сделать еще такой тест с ядерным клиентом:
                                                        В несколько потоков пишите и читаете на ceph большие файлы (по гигу скажем) и мелкие, в этот момент делаете kill -9 mds-у.
                                                        Что на клиенте? Kernel panic не случается? Linux не зависает на несколько секунд на всех файловых операциях?

                                                          0
                                                          Да, при kill -9 mds ввод-вывод зависает на несколько секунд, я об этом написал чуть выше уже.
                                                          Kernal panic не наблюдал.
                                                          Я уверен — через несколько релизов допилят и Fault tolerance для mds.
                                                            0
                                                            уже года полтора допиливают…
                                                            Что происходит с файлами которые были в процессе чтения и записи? Отваливается или заканчивает?
                                                              0
                                                              Заканчивает. На чтение если может продолжает читать, на запись приостанавливает. Актуально для версии 0.56.6.
                                                      0
                                                      Скажите, чем это лучше / хуже Хадупа?
                                                        0
                                                        Мы хотим уйти с хадупа, так как нам не нужен mapreduce и нужна POSIX совместимость.
                                                          0
                                                          Проще, сильно проще. Ну а вот сейчас поправьте меня, могу ошибаться.
                                                          Метаданные хадуп хранит на name-node, она одна, и все лежит в памяти. То есть количество файлов на файловой системе жестко ограничено размером памяти одной ноды с метаданными? Это — точка отказа и потенциальный bottleneck.

                                                          ceph скалируется по-всякому. Можно любое блочное устройство подцепить любого размера, все будет работать. Также у ceph есть и другие способы использования, помимо cephfs
                                                          — блочное устройство rbd. Эта штука давно в продакшн и везде впиливается. KVM умеет его как underlying, из софта — openstack, opennebula, proxmox, тот же hadoop.
                                                          — radosgw — почти полная совместимость с amazonS3 и swift.

                                                          То есть, имея свой кластер ceph, можно использовать его по-разному. И ничего ничему мешать не будет.

                                                            0
                                                            В целом идея понятна.
                                                            Что касается Хадупа, там сейчас две NameNode, Active/Passive, они дублируют друг друга для минимизации single point of failure.
                                                            Метаданные — действительно должны влезать в память. Но, впринципе люди говорят, что хватает 150 байт на один файл.
                                                            Each file or directory or block occupies about 150 bytes in the namenode memory.
                                                              0
                                                              Ну, то есть так и есть — основная проблема в том, что если памяти у name-node не хватит, то при избытке собственно места, мы ничего с ним сделать не сможем. Если мы говорим про петабайты и BIgData, то ceph умеет, а для hadoopfs — надо заморочиться )))
                                                              Другой вопрос, что cephfs еще сыровата, мягко говоря. Как бы не пришлось заморочиться еще больше )))))
                                                          0
                                                          Добрый вечер!
                                                          Спасибо автору за ценный материал. Однако, смущает потеря половины пространства при стандартном уровне репликации. Гугление привело к манам по пулам ceph.com/docs/master/rados/operations/pools/. По ним создан пул erasure с erasure-code-k=5 и erasure-code-m=2. Через rados df пул отображается. Но пока использовать этот пул получилось только через блочное устройство в пуле. Все данные при монтировании через mount -t ceph..., как указано в статье, попадают в дефолтный пул data. Как заставить ceph использовать для данных не пул data, а новый erasure пул?
                                                            0
                                                            Извини, только что заметил твой вопрос. Не знаю точно что делает erasure, но по поводу использования отличного от data пула для mds смотри тут
                                                            0
                                                            А как обстоят дела у Ceph FS с гео-репликацией (когда ноды разнесены по разным датацентрам)?
                                                              0
                                                              Насколько я знаю, пока никак. Кластер не может быть растянут на две автономные площадки, то есть если половинки развалятся, каждая будет жить сама по себе и никакой консистенции не будет. Как-то так.
                                                              Но, делать репликацию между двумя кластерами (они могут быть в разных датацентрах) для объектного доступа RadosGW уже возможно, но я не копал в эту сторону глубоко http://ceph.com/docs/master/radosgw/federated-config/.
                                                              0
                                                              У меня тут несколько вопрос накопилось:

                                                              — Правильно ли я понимаю, что CephFS можно монтировать r/w в нескольких местах одновременно?
                                                              — Читал, что если на ноде больше 8 osd, то прелесть журнала на ssd пропадает. Так ли это?
                                                              — В той же статье было написано, что больше 8 osd не желательно. Но тогда как-то не экномично выходит учитывая, что тут же рекомендация использовать 1:1 мапинг (osd:drive)
                                                              — Правда ли, что нода умирает если потерялся журнал?

                                                              Решаю между Ceph на 4 машинах (3 osd и 1 mds) и просто большим SAN'ом. Каждый OSD допустим имеет 24 диска. Ну или 12.
                                                                0
                                                                Попытаюсь ответить, так как у меня CEPH в продакшене.
                                                                1 — Да можно.
                                                                2 — Зависит от того как вы выносите журнал на SSD, и от вашей сети. Если вы пилите один SSD под журнал на 8+ винтов — то пропадает уже при 5 винтах, так как суммарная скорость записи на 5 разных HDD и на один SSD сравнивается. Про сеть — если у вас сети данных и сети синхронизации разделены и скорость 1G по больше 5 OSD на один сервер не ставьте. Если же сети не разделены то в 2 раза меньше. Ну а если у вас 10G и lowlatency свитч то можно и побольше поставить.
                                                                3 — Если у вас хороший SATA контроллер, и быстрая сеть — можно и больше 8.
                                                                4 — Да, правда, нода умирает, но в процессе восстановления находит данные и актуализирует их.
                                                                PS: поделитесь ссылкой на статью.

                                                                  0
                                                                  Понятно. Выходит при моем маштабе проще и дешевле большой тазик купить.

                                                                  Вот статять: www.hastexo.com/resources/hints-and-kinks/solid-state-drives-and-ceph-osd-journals
                                                                    0
                                                                    Ну не скажите, у меня собрано на очень старом железе и всё летает. Самое дорогое — винты.
                                                                    Сервера HP Proliant DL320 G4 4GB RAM 2TB*2HDD
                                                                    Коммутаторы D-link DGS3100-24TG
                                                                    Суммарно 5 серверов, до 1000iops проблем не знаю.
                                                                      0
                                                                      Тоесть у вас 20ТБ до redundancy выходит?

                                                                      Я то считал пачку тазиков на новых Dell R720 и R320 для mds. По FC или IB их цеплять между собой. В результате у меня вышло печально много. Дешевле выходит один R920. И брать MD1200 если место кончится. По-цене выходит так же, а администрировать проще.

                                                                      Конечно если брать G4 я бы не доверил все одной ноде и размазал на несколько.
                                                                        0
                                                                        Да, выходит 20TB.
                                                                        G4 я не покупал, валялись, решил задействовать.

                                                                        Далее — если вы купите один R920 то никакой отказоустойчивости у вас не будет. я бы на вашем месте взял несколько Dell R320 и размазал на них всю нагрузку. Например opennebula с этим бы прекрасно справилась.
                                                                        Для MDS не нужен отдельный хост, с 0.7Х ветки их можно ставить на каждый хост. Активен будет один, а остальные «на подхвате», аналогично с mon. у меня на каждой ноде 2 OSD, MON, MDS.
                                                                          0
                                                                          Но сами разработчики же не рекомендуют несколько MDS?

                                                                          Пачку R320 тоже расценивал. Но потом решил, что дешевле r920 и пожертвовать отказоуствоичивостью.
                                                                            0
                                                                            Это новая фишка, не помню с какой версии пошла. все остальные MDS находятся в режиме slave. одновременно работает только 1.

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

                                                              Самое читаемое