company_banner

Пять вопросов о Ceph с пояснениями

Автор оригинала: Stacey Peterson
  • Перевод


Что нужно знать о Ceph, хранилище с открытым исходным кодом, чтобы решить, подходит ли оно вашей компании. В статье будет сравнение с альтернативными объектными хранилищами, а также рассмотрена оптимизация Ceph.


Хранилище Ceph — одно из наиболее популярных объектных хранилищ. Это высокомасштабируемое и унифицированное хранилище с открытым исходным кодом также обладает некоторыми преимуществами.


Ceph предлагает функции, которые, в принципе, есть в других хранилищах для предприятий, но он, вероятно, будет дешевле, чем обычный SAN. Для Ceph с открытым исходным кодом не нужны лицензионные отчисления, которые есть у проприетарных систем. Также у Ceph нету зависимости от дорогого специализированного оборудования, он может быть установлен на обычное оборудование.


Среди других преимуществ — масштабируемость и гибкость. Ceph предлагает несколько интерфейсов доступа к хранилищу: объектный, блочный и файловый. Для увеличения емкости системы достаточно добавить больше серверов.


К некоторым недостаткам при использовании Ceph можно отнести нужду в быстрой, а значит более дорогой сети. Это также не бесплатно для любой компании. Если вы используете его для хранения важных данных — скорее всего вы используете один из двух коммерческих вариантов с поддержкой от RedHat или SUSE. Несмотря на это, Ceph — это более дешёвая и живучая альтернатива проприетарным SAN.


Какое объектное хранилище лучше: Ceph или Swift?


Ceph и Swift — объектные хранилища, распределяющие и реплицирующие данные по кластеру. Они используют файловую систему XFS или другую файловую систему, доступную в Linux. Они оба разработаны для масштабирования, так что пользователи могут легко добавить узлы хранилища.


Но что касается доступа к данным, то Swift разработан с прицелом на облака, использует RESTful API. Приложения могут няпрямую получить доступ к Swift, обходя при этом операционную систему. Это хорошо в облачном окружении, но усложняет доступ к хранилищу Swift.


Ceph — более гибкое объектное хранилище с четырьмя способами доступа: Amazon S3 RESTful API, CephFS, Rados Block Device и шлюзом iSCSI. Ceph и Swift также отличаются способом доступа клиентов. Так в Swift клиенты должны идти через Swift Gateway, который сам по себе является единой точкой отказа. Ceph с другой стороны использует устройство объектного хранилища, доступное на каждом узле. Другая часть, используемая для доступа к объектному хранилищу, запускается на клиенте. Так что здесь Ceph более гибкий.


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


Какая разница между Ceph и GlusterFS?


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


Несмотря на наличие общих вещей, у них есть также ключевые различия. GlusterFS — файловая система Linux, которую легко внедрить в окружении Linux, но нельзя так же легко внедрить в окружении Windows.


Ceph с другой стороны предоставляет высокомасштабируемое объектное, файловое и блочное хранилище в единой унифицированной системе. Как и в любом другом объектном хранилище, приложения пишут в хранилище с помощью API, минуя операционную систему. С учетом этого, хранилища Ceph внедряются одинаково легко как в Linux, так и в Windows. Из-за этого, а также по другим причинам, Ceph — лучший выбор для разнородных окружений, где используются Linux и другие операционные системы.


Если сравнивать по скорости работы, то и Ceph и GlusterFS работают примерно одинаково. Также GlusterFS по большей части ассоциируется с RedHat, в то же время Ceph шире поддерживается сообществом.


Ceph с открытым исходным кодом или коммерческая версия Ceph: как их сравнивать?


Пользователи могут без каких либо выплат сделать любую SDS на основе Ceph, пока его исходный код остается открытым. Ceph предлагает руководства по запуску, в котором описаны все этапы по его сборке в любом дистрибутиве Linux, а также настройке окружения Ceph.


Это достаточно сложный процесс, требующий определенного опыта. Тут и появляются коммерческие сборки Ceph, их проще сделать, кроме сборок также предоставляется и поддержка.


Есть два коммерческих продукта: RedHat Ceph Storage и SUSE Enterprise Storage. Есть некоторые различия, так компания SUSE разработала iSCSI Gateway, позволяющий пользователям получить доступ к хранилищу Ceph. RedHat внедрила Ceph-Ansible, инструмент управления настройками, с которым Ceph относительно легче устанавливать и настраивать.


Какие способы улучшения производительности Ceph лучшие?


Для хорошей производительности достаточно SATA дисков. Алгоритм CRUSH (Controlled Replication Under Scalable Hashing) в Ceph решает, где хранить данные в хранилище. Он разработан для гарантии быстрого доступа к хранилищу. Однако для оптимальной скорости Ceph надо 10G сеть, а лучше — 40G.


Несколько больших серверов, на которых установлено много дисков, обеспечат наилучшую производительность, однако диск с журналом должен быть на отдельном устройстве. Использование журнала на SSD обеспечит максимальную скорость, а файловая система Btrfs даст оптимальную производительность Ceph.


Как вы внедряете Ceph на Windows?


Есть два способа внедрения: Ceph Gateway и iSCSI target в SUSE Enterprise Storage. Ceph Gateway обеспечивает приложениям доступ с помощью RESTful API, но это не самый лучший способ предоставления доступа для операционной системы.


Ceph может быть настроен как и любая другая СХД на основе iSCSI с помощью iSCSI target в SUSE Enterprise Storage. Это дает доступ к хранилищу для операционной системы с поддержкой iSCSI initiator, к примеру серверной Windows.


Курс по Ceph будет запущен образовательным центром Слёрм 15 октября 2020. Cейчас можно сделать предзаказ с существенной скидкой.


Программа курса:

№1: Что такое Ceph и чем он не является


  • Что такое Ceph
  • Что умеет Ceph, а для чего он не предназначен
  • Аналоги Ceph
    №2: Обзор архитектуры Ceph
  • Из чего состоит Ceph
  • За что отвечают различные компоненты Ceph
    №3: Установка Ceph
  • Настройка Ceph руками
  • Ceph-deploy, Cephadm, Ansible (обзорное представление)
  • Краткие системные требования
    №4: Варианты использования Ceph
  • Внешние интерфейсы RBD, CephFS, RGW (S3)
    №5: Интеграция Ceph с распространенными Cloud Native решениями
  • Kubernetes
  • OpenStack
  • Proxmox
  • OpenNebula
    №6: Эксплуатация Ceph. Регламентные работы
  • Добавление/удаление OSD, MON
  • Ребалансировка
  • Перенос данных между кластерами
  • Обновление кластера
  • Бэкапы
    №7: Мониторинг Ceph
  • Сбор метрик, на что обращать внимание
  • Алертинг
    №8: Дебаг Ceph. Что делать когда все сломалось
  • Флаги (nodown, noup, nobackfill, norecover)
  • Реакция на переполнение
  • Проблемы при ребилде
    №9: Расширенная диагностика Ceph. Что делать, когда все работает, но не совсем так, как надо
  • Рост latency
  • Отвалы OSD
  • Работа с админ-socket'ом
    №10: Производительность Ceph. Математика производительности
  • Что такое производительность кластера Ceph / системы хранения
  • Чего можно ожидать и чего ожидать не стоит от вашего кластера
  • Как оценивать производительность и как ее подсчитать
  • Что потребуется, чтобы выйти на определенный уровень производительности
  • Гиперконвергентные системы
    №11: Выбор железа под свой кластер
  • Рекомендации к выбору железа для своего кластера
Southbridge
Обеспечиваем стабильную работу highload-проектов

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

    +3

    Для новых версий Ceph активно рекомендуется использовать BlueStore (отдан диск целиком без файловой разметки) вместо FileStore, поэтому разговоры о лучшей ФС для Ceph сейчас не уместны.
    https://ceph.io/community/new-luminous-bluestore/

      +2

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


      Facepalm. Традиционная рекомендация — как можно больше небольших серверов. Чем больше серверов, тем больше ядер на диск. По бенчмаркам ceph упирается примерно 300% cpu на ядро на запись, и 200% на чтение (в сумме — 500%). Если у вас быстрые диски, то вынь да положь пять ядер на диск.


      Использование шпинделей под ceph при сегодняшних ценах на SSD — спорно. Очень спорно. Планировать нагрузку на SSD можно более менее разумно, на шпиндели почти невозможно, потому что любая случайная параллельная нагрузка вгоняет диски в полный аут (а на SSD просто просаживает пропорционально нагрузке).

        0
        300% cpu на ядро на запись, и 200% на чтение (в сумме — 500%)

        Не очепятка случайно ли? 300% cpu на диск?

          +1

          Это жаргон. Цеф жрёт процессор, много процессора. Когда сервера планируются, если конфигурация планируется без cpu/net bottleneck'ов, то учитывается worst case CPU use для ceph'а, и это 5 ядер CPU на устройство. Если само устройство достаточно быстрое, можно найти нагрузку, которая таки 500% сожрёт.


          Чтобы самим посчитать — сделайте ceph-osd на brd (block ram disk), в этой ситуации все боттлнеки будут в коде ceph'а (если бенчмаркать rados на пуле из одной osd на localhost). И это от 480 до 530% cpu в зависимости от модели.


          Если конфигурация делается cpu bound (это нормально — вопрос цены же), то тут нужно хорошо понимать, что под определёнными нагрузками диски (SSD) будут простаивать.

            0

            Я вполне понимаю суть изначального сообщения. Просто у вас уровнем выше написано "300% + 200% на ядро", что вроде как должно быть чем-то вроде "300% + 200% на blockdev". Ядро воспринимается как "ядро cpu" в том контексте.

        0
        Добавлю шестой вопрос- а как сейчас у него с восстановлением после сбоев?
        Время назад, сбой в ceph привел к остановке на сутки DigitalOcean
        Поскольку отказ приводит к лютой деградации производительности, а так же может привести к полному разрушению хранилища
        описание проблемы
        Какой прогресс в этой области?
          0

          Ну, cloudmouse это отдельный случай, а у ceph'а есть простые настройки о том, что важнее, сохранность данных или доступность. Нужна сохранность — min_size=2 (или даже 3), нужна доступность — min_size=1 под личную ответственность.

            0

            Алсо, отказ ноды в ceph'е не приводит к людой деградации производительности, данные просто реплицируются на оставшиеся ноды. По нагрузке это мало отличается от deep_scrub'а, который и так регулярно делается.

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

                Мне кажется, что очень сильно зависит от топологии. Если Вы внимательно почитаете исходную статью, то увидите, что там достаточно специфический конфиг с несколькими демонами цефа (OSD, если я правильно помню терминологию) на один узел. И их конкуренция друг с другом в условиях лимитированной озу.
                Это не отменяет того, что при помощи цефа можно хорошо себе отстрелить обе ноги, но надо же «нормально делать — нормально будет»

                  +1

                  Там же написаны базовые рекомендации — не собирать суперкомпьютеры под ceph. Если у вас кластер из 1000 почти-десктопных серверов (1 процессор, 8 тредов, 2 ssd), то вы вылетевшую стойку после двух суток починки не заметите. А если у вас superdome с 4x24 тредами и двумя jbod enscolsure на каждый сервер, то тут даунтайм одного сервера расштатает всё и вся.


                  Кстати, при том, что операционная боль от "медленного цефа" сохраняется, я напоминаю, что основной выбор тут — надёжность данных.


                  Историю mousecloud я знаю, но я не знаю что именно такого плохого они сделали.

              0
              Это также не бесплатно для любой компании.

              Я прошу прощения, но у меня мозг сломался на этой фразе. Заглянул в оригинал и все стало понятно:


              It's also not going to be free for every organization.
                +1
                Разница с гластером в первую очередь в том, что гластер это только файловое хранилище. Сеф даёт сразу все — блок, файл и объектное хранилище. При чем все три являются надстройками над rados, которое тоже объектное. Знаю на рынке других таких систем.
                Как правило сеф надёжнее и таки быстрее, если говорить о нелинейных нагрузках.
                  +1

                  Антиреклама курсов?


                  Такое ощущение, что статью писал человек, с ceph вообще незнакомый. Периодически вообще сравнивается тёплое с мягким: расскажите, например, как образом вы сравниваете GlusterFS — файловую систему, и один из компонентов ceph: объектное хранилище? С точки зрения возможности использования под Win сравните тогда CephFS с GlusterFS — ни первую, ни вторую там использовать нельзя (хотя сейчас пишут какой-то драйвер, вроде).


                  А жаль: софт-то отличный.

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

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