Я люблю Цефа.
Работаю с ним уже 4 года (0.80.х - 12.2.6 , 12.2.5).
Иногда я настолько увлечен им, что провожу вечера и ночи в его компании, а не со своей девушкой.
Я сталкивался с различными проблемами с этим продуктом и с некоторыми живу до сих пор.
Иногда меня радовали простые решения, а иногда я мечтал встретиться с разработчиками, чтобы выразить свое возмущение.
Но Ceph по-прежнему используется в нашем проекте и не исключено, что он будет использоваться в новых задачах, по крайней мере мной.
В этом рассказе я поделюсь нашим опытом использования Ceph, в какой-то мере выскажусь на тему того, что мне не нравится в этом решении и, возможно, помогу тем, кто только присматривается к нему.
На написание этой статьи меня побудили события, которые начались около года назад, когда в наш проект была привлечена Dell EMC ScaleIO, теперь известная как Dell EMC VxFlex OS. Это никоим образом не является рекламой Dell EMC или их продукта! Лично я не очень хорошо отношусь к крупным корпорациям и черным ящикам типа VxFlex OS. Но как известно, все в мире относительно, и на примере ОС VxFlex очень удобно показать, что из себя представляет Ceph с эксплуатационной точки зрения, и я попробую это сделать.
Параметры.
Речь идет о четырехзначных числах! Сервисы Ceph, такие как MON, OSD и т. д., имеют различные параметры для настройки всевозможных подсистем.
Параметры задаются в файле конфигурации, и демоны считывают их при запуске.
Некоторые значения можно удобно менять на лету с помощью механизма «инъекции», о котором речь пойдет ниже.
Все почти супер, если не обращать внимания на то, что параметров сотни: Молоток:
Светящийся:> ceph daemon mon.a config show | wc -l 863
> ceph daemon mon.a config show | wc -l
1401Получается ~500 новых параметров за два года.
В целом параметризация — это круто, что не круто, так это то, что в 80% этого списка есть сложности с пониманием.
В документации описано, по моим прикидкам, ~20% и местами неоднозначно.
Понимание значения большинства параметров приходится искать в гитхабе проекта или в списках рассылки, но это не всегда помогает. Вот пример нескольких параметров, которые мне были интересны совсем недавно, я нашел их в блоге цефового овода: throttler_perf_counter = false // enable/disable throttler perf counter
osd_enable_op_tracker = false // enable/disable OSD op tracking
Комментарии к коду в духе лучших практик.
Я как бы понимаю слова и даже примерно, о чем они, но что мне это даст - нет. Или здесь: osd_op_threads Luminous исчез, и только исходный код помог нам найти новое имя: osd_peering_wq потоки Еще мне нравится, что там есть особо параметры холивара.
Здесь парень показывает, что увеличение rgw_num_rados_handles Этот хороший : а другой парень думает, что > 1 сделать нельзя и даже опасный .
А больше всего мне нравится, когда начинающие специалисты в своих постах в блоге приводят примеры конфига, где все параметры бездумно (мне кажется) скопированы из другого похожего блога, и так есть куча параметров, о которых никто не знает, кроме автор кода - они мигрируют из конфига в конфиг.
Я также просто потрясен тем, что они сделали с Luminous. Есть супер крутая функция — изменение параметров на лету, без перезапуска процессов.
Вы можете, например, изменить параметр конкретного OSD: > ceph tell osd.12 injectargs '--filestore_fd_cache_size=512'
или поставьте «*» вместо 12 и значение будет изменено на всех OSD. Это очень круто, правда.
Но, как и многие вещи в Ceph, это делается левой ногой.
По замыслу не все значения параметров можно изменить на лету.
Точнее, их можно объединить в сеть, и на выходе они будут выглядеть измененными, но на самом деле лишь некоторые из них перечитываются и повторно применяются.
Например, вы не можете изменить размер пула потоков без перезапуска процесса.
Чтобы исполнитель команды понял, что менять параметр таким образом бесполезно, мы решили напечатать сообщение.
Привет. Например: > ceph tell mon.* injectargs '--mon_allow_pool_delete=true'
mon.c: injectargs:mon_allow_pool_delete = 'true' (not observed, change may require restart)
mon.a: injectargs:mon_allow_pool_delete = 'true' (not observed, change may require restart)
mon.b: injectargs:mon_allow_pool_delete = 'true' (not observed, change may require restart)
Двусмысленный.
Фактически удаление пулов становится возможным после инъекции.
То есть данное предупреждение не актуально для данного параметра.
Ок, но есть сотни других параметров, в том числе очень полезных, о которых тоже есть предупреждение и нет возможности проверить их реальную применимость.
На данный момент я даже из кода не могу понять, какие параметры применяются после инъекции, а какие нет. В целях безопасности приходится перезапускать службы и, знаете ли, это раздражает. Меня это бесит, потому что я знаю, что существует инъекционный механизм.
Как с этим обстоят дела у VxFlex OS? Подобные процессы, такие как MON (в VxFlex это MDM), OSD (SDS в VxFlex) также имеют файлы конфигурации, каждый с десятком параметров.
Правда, их имена тоже ничего не значат, но хорошая новость в том, что мы никогда не прибегали к ним, чтобы получить такой же ожог, как с Ceph.
Технический долг
Когда начинаешь знакомство с Ceph с самой актуальной на сегодня версии, все кажется замечательным, и хочется написать только положительную статью.Но когда живешь с ним в продакшене с версии 0.80, то все выглядит не так радужно.
До Jewel процессы Ceph выполнялись с правами root. Jewel решила, что они должны работать под пользователем «ceph», и это потребовало смены владельца всех каталогов, используемых службами Ceph. Казалось бы, что не так? Представьте себе OSD, обслуживающий магнитный диск SATA емкостью 2 ТБ, заполненный на 70%.
Итак, параллельное пролистывание такого диска (в разные подкаталоги) с полной утилизацией диска занимает 3-4 часа.
Представьте, что у вас есть, например, 3 сотни таких дисков.
Даже если обновляться нодами (чеканить сразу 8-12 дисков), в результате получается довольно долгое обновление, при котором в кластере будут OSD разных версий и на одну реплику данных меньше на момент поднятия сервера на обновление.
В общем, мы подумали, что это абсурд, пересобрали пакеты Ceph и оставили OSD работать от имени root. Мы решили, что по мере внедрения или замены OSD будем передавать их новому пользователю.
Сейчас меняем 2-3 диска в месяц и добавляем 1-2, думаю к 2022 году справимся).
CRUSH настройки РАЗДАВИТЬ — сердце цефа, все вращается вокруг него.
Это алгоритм, с помощью которого псевдослучайным образом выбирается местоположение данных и благодаря которому клиенты, работающие с кластером RADOS, узнают, на каком OSD хранятся нужные им данные (объекты).
Ключевой особенностью CRUSH является отсутствие необходимости в каких-либо серверах метаданных, таких как Lustre или IBM GPFS (теперь Spectrum Scale).
CRUSH позволяет клиентам и OSD напрямую взаимодействовать друг с другом.
Хотя, конечно, сложно сравнивать примитивное объектное хранилище RADOS и файловые системы, которые я привел в качестве примера, но идея, думаю, ясна.
В свою очередь, настройки CRUSH представляют собой набор параметров/флагов, которые влияют на работу CRUSH, делая ее более эффективной, по крайней мере теоретически.
Так вот, при обновлении с Хаммера на Джевел (тестирование, естественно) появилось предупреждение о том, что профиль настройки имеет параметры, не оптимальные для текущей версии (Джевел) и рекомендуется переключить профиль на оптимальный.
В общем, все понятно.
В документе сказано, что это очень важно и это правильный путь, но также сказано, что после переключения данных произойдет ребалансировка 10% данных.
10% звучит не страшно, но мы решили проверить.
Для кластера примерно в 10 раз меньшего, чем на продакшене, с таким же количеством PG на OSD, наполненного тестовыми данными, мы получили ребаланс в 60%! Представьте, например, при 100ТБ данных между OSD начинает перемещаться 60ТБ и это при постоянно работающей клиентской нагрузке, требовательной к задержке! Если я еще не сказал, мы предоставляем s3 и даже ночью нагрузка на rgw особо не снижается, которых сейчас 8 и еще 4 для статических сайтов.
В общем, мы решили, что это не наш путь, тем более, что делать такой ребаланс на новой версии, с которой мы еще не работали в продакшене, это как минимум слишком оптимистично.
Кроме того, у нас были большие индексы сегментов, которые не очень хорошо пережили ребалансировку и это тоже было причиной задержки переключения профиля.
Индексы будут рассмотрены отдельно ниже.
В итоге мы просто убрали предупреждение и решили вернуться к нему позже.
А при переключении профилей в тестировании отваливались клиенты cephs, которые были в ядрах CentOS 7.2, так как они не могли работать с более новым алгоритмом хеширования, идущим с новым профилем.
Мы не используем cephfs в продакшене, но если бы использовали, это было бы еще одним поводом не переключать профиль.
Кстати, в документе написано, что если то, что происходит во время ребалансировки, вас не устраивает, то вы можете откатить профиль.
Фактически после чистой установки версии Hammer и обновления Jewel профиль выглядит так: > ceph osd crush show-tunables
{
.
"straw_calc_version": 1, "allowed_bucket_algs": 22, "profile": "unknown", "optimal_tunables": 0, .
}
Здесь важно то, что он «неизвестен», и если вы попытаетесь остановить ребалансировку, переключив его на «legacy» (как сказано в доке) или даже на «забить», то ребалансировка не остановится, она будет просто продолжаться в соответствии с другими настройками, а не «оптимально».
В общем, все нужно тщательно проверить и перепроверить; нет доверия к ceph. CRUSH обмен Как известно, все в этом мире сбалансировано и при всех преимуществах есть и недостатки.
Недостаток CRUSH в том, что PG размазаны по разным OSD неравномерно, даже при одинаковом весе последних.
Плюс ничто не мешает разным PG расти с разной скоростью, поэтому хеш-функция встанет на свои места.
Конкретно у нас диапазон утилизации OSD составляет 48-84%, несмотря на то, что они имеют одинаковый размер и, соответственно, вес.
Мы даже стараемся сделать серверы одинаковыми по весу, но это так, просто наш перфекционизм, не более того.
И неважно, что IO распределяется по дискам неравномерно, самое страшное, что когда хотя бы одна OSD в кластере достигает полного (95%) состояния, вся запись прекращается и кластер переходит в режим readonly. Весь кластер! И не важно, что места в кластере еще достаточно.
Всё, финал, выходим! Это архитектурная особенность CRUSH. Представьте, вы в отпуске, какое-то OSD пробило отметку 85% (первое предупреждение по умолчанию), и у вас есть в запасе 10%, чтобы запись не остановилась.
А 10% при активно ведущейся записи - это не так уж и много/долго.
В идеале при такой конструкции Ceph понадобится помощник, способный выполнить подготовленную инструкцию в таких случаях.
Итак, мы решили разбалансировать данные в кластере, потому что.
несколько OSD были близки к почти полной отметке (85%).
Есть несколько способов:
- Добавить диски
Сами данные из полной OSD могут не переместиться, либо перемещение будет незначительным.
- Изменить постоянный вес экранного меню (ВЕС)
- Изменение непостоянного веса экранного меню (REWEIGHT)
Это приводит к изменению так называемого веса корректировки OSD без изменения веса сегментов более высокого уровня.
В результате данные балансируются между разными OSD одного сервера, как бы не выходя из CRUSH-ведра.
Нам очень понравился такой подход, мы посмотрели пробный прогон, какие изменения будут внесены, и внедрили это в производство.
Все было хорошо, пока процесс ребалансировки не перестал работать где-то на полпути.
Снова гуглим, читаем рассылки, экспериментируем с разными вариантами и в итоге выясняется, что остановка вызвана отсутствием некоторых настроек в нашем профиле, как говорилось выше.
Технический долг снова настиг нас.
В итоге мы пошли по пути добавления дисков и максимально неэффективной ребалансировки.
К счастью, нам всё равно пришлось это сделать, потому что.
Переключение профиля CRUSH планировалось производить с достаточным запасом мощности.
Да, мы знаем о включенном в mgr балансировщике (Luminous и выше), который предназначен для решения проблемы неравномерного распределения данных путем перемещения ГУ между OSD, например, в ночное время.
Но положительных отзывов о его работе я пока не слышал, даже в нынешнем Мимике.
Вы, наверное, скажете, что технический долг – это чисто наша проблема, и я, наверное, соглашусь.
Но за четыре года работы Ceph мы зафиксировали только один простой s3, который длился целый 1 час.
И потом, проблема была не в RADOS, а в RGW, который, набрав свои дефолтные 100 потоков, зависал намертво и запросы большинства пользователей не выполнялись.
Это все еще было на Хаммере.
На мой взгляд, это хороший показатель и достигнут он за счет того, что мы не делаем резких движений и довольно скептически ко всему относимся в Ceph.
Дикий GC
Как известно, удаление данных непосредственно с диска — достаточно ресурсоемкая задача, а в продвинутых системах удаление задерживается или не производится вообще.Ceph также является продвинутой системой, и в случае с RGW при удалении объекта s3 соответствующие объекты RADOS не удаляются с диска сразу.
RGW помечает объекты s3 как удаленные, а отдельный поток gc отвечает за удаление объектов непосредственно из RADOS-пулов и, соответственно, с дисков в отложенном порядке.
После обновления до Luminous поведение gc заметно изменилось; он стал работать более агрессивно, хотя параметры gc остались прежними.
Под «заметно» я имею в виду, что мы начали видеть, как gc работает над внешним мониторингом службы из-за скачкообразной задержки.
Это сопровождалось большим количеством операций ввода-вывода в пуле rgw.gc. Но проблема, с которой мы столкнулись, гораздо более эпична, чем просто IO. Когда gc работает, создается множество таких журналов: 0 <cls> /builddir/build/BUILD/ceph-12.2.5/src/cls/rgw/cls_rgw.cc:3284: gc_iterate_entries end_key=1_01530264199.726582828
Где 0 в начале — это уровень журналирования, на котором печатается это сообщение.
Опускать лог ниже нуля как будто некуда.
В результате одна OSD за пару часов сгенерировала ~1 Гб логов, и все бы ничего, если бы узлы ceph не были бездисковыми.
Загружаем ОС через PXE напрямую в память и не используем локальный диск или NFS, NBD для системного раздела (/).
Результатом являются серверы без сохранения состояния.
После перезагрузки все состояние восстанавливается автоматикой.
Как это работает я опишу в отдельной статье, но сейчас важно то, что под «/» выделено 6 ГБ памяти, из которых обычно свободно ~4. Мы отправляем все журналы в Graylog и используем довольно агрессивную политику ротации журналов и, как правило, не испытываем никаких проблем с заполнением диска/ОЗУ.
Но мы были к этому не готовы, при 12 OSD на сервере «/» заполнялось очень быстро, дежурные вовремя не реагировали на триггер в Zabbix и OSD просто начинала останавливаться из-за невозможности записи лога .
В результате мы снизили интенсивность GC; мы не открыли тикет, потому что.
он уже был, и мы добавили в cron скрипт, в котором мы принудительно обрезаем логи OSD при превышении определенного объема, не дожидаясь logrotate. Кстати, уровень логирования продвинутый .
Группы размещения и хваленая масштабируемость
На мой взгляд, PG — самая сложная для понимания абстракция.PG необходимы, чтобы сделать CRUSH более эффективным.
Основное назначение PG — группировка объектов для снижения потребления ресурсов, повышения производительности и масштабируемости.
Обращаться к объектам напрямую, по отдельности, без объединения их в PG, было бы очень дорого.
Основной проблемой для PG является определение их количества для нового пула.
Из блога Ceph:
«Выбор правильного количества PG для вашего кластера — это своего рода черное искусство и кошмар удобства использования».Это всегда очень специфично для конкретной установки и требует много размышлений и расчетов.
Основные рекомендации:
- Слишком много PG в OSD – это плохо; будет перерасход ресурсов на их обслуживание и замедление работы при ребалансировке/восстановлении.
- Слишком мало ГУ на OSD – это плохо, производительность пострадает и OSD будет заполняться неравномерно.
- Номер PG должен быть кратен степени 2. Это поможет получить «силу CRUSH».
PG не имеют ограничений по объему и количеству объектов.
Сколько ресурсов (в реальных цифрах) необходимо для обслуживания одного PG? Зависит ли это от его размера? Зависит ли это от количества реплик этой PG? Стоит ли мне беспокоиться, если у меня достаточно памяти, быстрых процессоров и хорошая сеть? А еще нужно подумать о будущем росте кластера.
Количество ПГ нельзя уменьшать – только увеличивать.
Однако делать это не рекомендуется, так как это по сути приведет к расщеплению частей ГУ на новые и дикой ребалансировке.
«Увеличение количества PG в пуле является одним из наиболее влиятельных событий в кластере Ceph, и его следует избегать для производственных кластеров, если это возможно».Поэтому о будущем нужно думать сразу, если это возможно.
Реальный пример.
Кластер из 3 серверов с OSD 14х2 ТБ каждый, всего 42 OSD. Реплика 3, полезное пространство ~28 ТБ.
Будет использоваться под S3, вам необходимо рассчитать количество PG для пула данных и пула индексов.
RGW использует больше пулов, но эти два являются основными.
Пойдем Калькулятор PG (есть такой калькулятор), считаем с рекомендованными 100 ПГ на OSD, итого получаем 1312 ПГ.
Но не все так просто: у нас есть вводный — кластер за год обязательно вырастет в три раза, но оборудование будет куплено чуть позже.
Увеличиваем «Целевые PG на OSD» в три раза, до 300 и получаем 4480 PG. 
Выставляем количество PG для соответствующих пулов - получаем предупреждение: слишком много PG Per OSD. приехали.
Мы получили ~300 PG на OSD с лимитом 200 (Luminous).
Кстати, раньше было 300. И самое интересное, что все ненужные ПГ не пускают в пиринг, то есть это не просто предупреждение.
В конце концов, мы считаем, что все делаем правильно, поднимаем лимиты, отключаем предупреждение и идем дальше.
Другой реальный пример более интересен.
S3, полезная емкость 152 ТБ, 252 OSD по 1,81 ТБ, ~105 PG на OSD. Кластер рос постепенно, все было хорошо, пока с новыми законами в нашей стране не возникла необходимость вырасти до 1 ПБ, то есть +~850 ТБ, и при этом сохранить производительность, которая сейчас вполне хорошо для S3. Допустим, мы берем 6 (реально 5,7) ТБ дисков и с учетом реплики 3 получаем +447 OSD. С учетом текущих получается 699 OSD по 37 PG, а если учесть разный вес, то получается, что старые OSD будут иметь всего десяток PG. Так скажите мне, насколько хорошо это будет работать? Производительность кластера с разным количеством PG довольно сложно измерить синтетически, но тесты, которые я проводил, показывают, что для оптимальной производительности нужно от 50 PG на 2 ТБ OSD. А как насчет дальнейшего роста? Без увеличения количества PG можно добиться сопоставления PG с OSD 1:1. Может я чего-то не понимаю? Да, вы можете создать новый пул для RGW с необходимым количеством PG и сопоставить с ним отдельный регион S3. Или даже построить новый кластер поблизости.
Но согласитесь, все это костыли.
И получается, что, казалось бы, хорошо масштабируемый Ceph, благодаря своей концепции PG, масштабируется с оговорками.
Вам придется либо жить с отключенными предупреждениями при подготовке к росту, либо в какой-то момент провести ребалансировку всех данных в кластере, либо забыть о производительности и жить с тем, что происходит. Или пройти через все это.
Я рад, что разработчики Ceph понимать , что PG — это сложная и ненужная для пользователя абстракция и ему лучше об этом не знать.
«В Luminous мы предприняли важные шаги, чтобы окончательно устранить один из наиболее распространенных способов загнать ваш кластер в кювет, и в перспективе мы стремимся в конечном итоге полностью скрыть PG, чтобы большинству пользователей никогда не пришлось их знать или думать о".В vxFlex нет понятия PG или каких-либо аналогов.
Вы просто добавляете диски в пул и всё.
И так до 16 ПБ.
Представьте, ничего рассчитывать не надо, нет кучи статусов по этим ГУ, диски утилизируются равномерно на протяжении всего периода роста.
Поскольку диски отправляются в vxFlex целиком (поверх них нет файловой системы), то оценить их заполненность нет возможности и такой проблемы нет вообще.
Я даже не знаю, как передать вам, как это приятно.
«Надо дождаться SP1»
Еще одна история «успеха».Как вы знаете, RADOS — это очень примитивное хранилище значений ключей.
S3, реализованный поверх RADOS, тоже примитивен, но все же немного более функционален.
Например, в S3 можно получить список объектов по префиксу.
Чтобы это работало, RGW поддерживает собственный индекс для каждого сегмента.
Этот индекс представляет собой один объект RADOS, который фактически будет обслуживаться одним OSD. По мере роста количества объектов в корзине увеличивается и индексный объект. По нашим наблюдениям, начиная с нескольких миллионов объектов в ведре, начинаются заметные подтормаживания при записи в это ведро.
OSD, обслуживающее индексный объект, потребляет много памяти и может периодически отключаться.
Тормоза вызваны тем, что индекс блокируется при каждом изменении, чтобы сохранить согласованность.
Кроме того, во время операций очистки или перебалансировки индексный объект также блокируется на все время операции.
Все это периодически приводит к тому, что клиенты получают таймауты и 503, производительность больших бакетов страдает в принципе.
Изменение индекса сегмента — механизм, позволяющий разделить индекс на несколько частей (RADOS-объектов) и, соответственно, распределить их по разным OSD, тем самым добиться масштабируемости и снизить влияние сервисных операций.
Кстати, стоит отметить, что возможность ручного перешарда появилась только в Jewel и была бекпортирована в один из последних багфиксов! Молотковые сборки, что показывает его высокую важность, т.к.
Это не исправление ошибки.
Как работали большие ведра до этого? В Hammer у нас было несколько бакетов с 20+ миллионами объектов, и мы регулярно сталкивались с ними, знали номера заветных OSD и на основе сообщений Graylog понимали, что с ними происходит. Ручной перешард нам не подходил, потому что.
требовал остановки IO для конкретного сегмента.
Нам нужен был Luminous, потому что.
он делал перешардинг автоматическим и прозрачным для клиентов.
Обновились до Luminous, но решардинг не включили, протестировали.
Все выглядело хорошо, и мы включили это в производство.
IO в индексном пуле как и ожидалось выросло, ведра стали шардироваться, я открыл бутылку пива и рано закончил рабочий день.
Через день мы обнаружили, что IO стабильно работает на высоком уровне, при этом все проблемные корзины не шардируются.
Оказалось, что индексы шардировались по кругу.
Вскоре билеты были найдены; один раз , два : Пришлось его отключить, так как проблемные индексы уже были шардированы.
В копилку технического долга нужно добавить еще одну позицию, потому что.
Ведра могут вырасти дальше и шардинг снова понадобится не завтра, а через месяц.
Кстати, обновление Hammer-> Jewel было забавным из-за этих жирных индексов.
OSD, содержащий индекс, пробил все таймауты при перезапуске.
Нам пришлось подправить таймауты потоков прямо в продакшене, чтобы эти заветные OSD могли подняться, а не убить себя.
История с авторешардингом — не единственный случай, когда новая функция сработала так, что было бы лучше, если бы она вообще не работала.
Версия Hammer имела функцию s3, называемую управлением версиями объектов.
Это принесло нам гораздо больше вреда, чем пользы.
Для многих бакетов с включенным версионированием постепенно, по мере роста количества объектов, стали появляться объекты с неверным etag или нулевым телом, а также возникали ошибки при удалении объектов.
Тогда мы нашли несколько открытых отчетов с похожими проблемами.
Мы тщетно пытались воспроизвести эти проблемы и потратили много времени, но безрезультатно.
Приостановка управления версиями не решила проблему.
В итоге «решением» стало создание новых бакетов без версионирования и перенос в них объектов.
Это довольно сильно повредило нашей репутации и доставило неудобства нашим клиентам, и мы потратили много ресурсов, пытаясь им помочь.
Священные войны на количество реплик
Как только заходит речь о количестве реплик, сразу реплика 2 - это идиотизм, наркомания и вообще такую конфигурацию скоро постигнет судьба Cloudmouse. Да, если у вас есть Ceph, то это возможно.В ОС vxFlex коэффициент репликации равен 2, и его нельзя изменить.
Единственное, вам необходимо иметь в запасе определенное количество места для восстановления данных в случае катастрофы.
Этот том должен быть равен объему диска, который может выйти из строя за один раз.
Если потенциально может быть отключена вся ваша стойка, вам необходимо зарезервировать объем самой толстой стойки.
Можно спорить об эффективности и надежности такой схемы, но не зная точно, как она работает внутри, можно доверять только инженерам Dell EMC.
Производительность
Еще одна тема холивара.Какова производительность распределенной системы хранения данных, да еще с репликацией по сети? Хороший вопрос.
Понятно, что такие системы имеют большие накладные расходы.
По моему мнению, уровень производительности таких систем, как Ceph и vxFlex, следует измерять относительно их производительности и производительности используемого оборудования.
Важно понимать, сколько производительности мы теряем из-за используемого слоя.
Этот показатель также является экономическим; он определяет, сколько дисков и серверов нам нужно купить, чтобы достичь требуемых абсолютных значений.
Письмо от 9 августа от ceph-devel рассылки : Короче говоря, ребята получают серверы с загрузкой ЦП (по два Xeon на сервер!) и смешные IOPS на кластере All-NVMe на Ceph 12.2.7 и bluestore. В списках рассылки много статей, презентаций и дискуссий, но уровень Ceph все еще довольно низкий.
Несколько лет назад (во времена Hammer) мы тестировали различные решения для блочного хранения, и Ceph был нашим фаворитом, поскольку мы использовали его как s3 и надеялись использовать его в качестве решения для блочного хранения.
К сожалению, тогдашний ScaleIO потеснил Ceph RBD с потрясающими результатами.
Основная проблема, с которой мы столкнулись при использовании Ceph, заключалась в недостаточной загрузке дисков и чрезмерной загрузке ЦП.
Я хорошо помню наши приседания с RDMA над InfiniBand, jemalloc и прочими оптимизациями.
Да, если писать с 10-20 клиентами, то можно получить вполне неплохое общее количество iops, но при отсутствии параллелизма клиентского io Ceph совершенно плох даже на быстрых дисках.
vxFlex хорошо использует все диски и демонстрирует высокую производительность.
Потребление ресурсов принципиально другое — у Ceph большое системное время, у Scaleio — io wait. Да, тогда bluestore не было, но, судя по сообщениям в рассылке, это не панацея, да и сейчас по количеству сообщений об ошибках он, похоже, является лидером в трекере Ceph. Мы без колебаний выбрали актуальный на тот момент ScaleIO. Учитывая метрику, обсуждаемую в начале этого раздела, Ceph не будет экономически жизнеспособным, даже принимая во внимание стоимость лицензий Dell EMC. Кстати, если в кластере используются диски разной емкости, то PG будут распределяться в зависимости от их веса.
Это справедливое распределение с точки зрения объема (типа), но несправедливое с точки зрения ввода-вывода.
Из-за меньшего количества PG небольшим дискам потребуется меньше операций ввода-вывода, чем большим дискам, даже если они обычно имеют одинаковую производительность.
Возможно, было бы разумно сначала увеличить вес дисков меньшего размера и уменьшить его по мере приближения к почти полному.
Таким образом производительность кластера может быть более сбалансированной, но это не точно.
В vxFlex нет понятия журнала или какого-либо кэша или совместного использования; вся запись идет напрямую на диски.
Также нет процедуры предварительной настройки диска (смотрю в сторону ceph-volume), вы просто даете ему блочное устройство в эксклюзивное пользование, все очень просто и удобно.
Скраб
Это банально, я согласен.Все, кто живет с Ceph, наверняка прошли через это.
Как только в вашем кластере появляется много данных и начинается их активное использование, не заметить влияние скраба довольно сложно.
«Много данных» в моем понимании — это не какой-то общий объем в кластере, а заполненность используемых дисков.
Например, если у вас есть диски емкостью 2 ТБ и они заполнены > 50%, то у вас много данных в Ceph, даже если дисков всего два.
Мы в свое время сильно пострадали от скраба и долго искали решение.
Наш рецепт , который хорошо работает и по сей день.
В vxFlex OS тоже есть такой механизм и по умолчанию он отключен, как и почти все, что не является основным функционалом.
При включении можно задать только один параметр — пропускную способность в килобайтах.
Оно меняется «на лету» и позволяет выбрать оптимальное значение для вашего кластера.
Оставили значение по умолчанию и пока все хорошо, даже диски периодически меняем после сообщений об ошибках.
Кстати, что интересно, vxFlex сам разрешает такие ситуации, как Scrub-Error. Ceph с той же репликой 2 требует ручного вмешательства.
Мониторинг
Luminous — знаковый релиз во многих отношениях.В этой версии наконец-то представлены собственные инструменты мониторинга.
Используя встроенный плагин MGR и официальный шаблон для Zabbix, вы можете за несколько шагов получить базовый мониторинг с графиками и самыми важными оповещениями (3 штуки).
Также есть плагины для других систем.
Это действительно круто, мы этим пользуемся, но все равно нужно писать свои скрипты и шаблоны для мониторинга IO по пулам, чтобы понимать, когда gc капризничает, например.
Отдельная тема — мониторинг экземпляров RGW. 
Без него я просто как слепой котёнок.
Вам также необходимо написать это самостоятельно.
А это фрагмент внешнего мониторинга S3, как «видят» сервис клиенты: 
Этот мониторинг, конечно, не имеет ничего общего с самим Ceph, но я настоятельно рекомендую вам его приобрести, если у вас его еще нет. Приятно отметить, что мониторы Ceph могут использовать Graylog с использованием протокола GELF, и мы его используем.
Мы получаем оповещения, например, когда OSD не работает, отключается, выходит из строя и другие.
Настроив парсинг сообщений, мы можем анализировать логи за определенный период времени, например, узнать верхний OSD на предмет падения за месяц или построить график интенсивности парсинга.
Теги: #it-инфраструктура #Хранилище данных #Администрирование сервера #s3 #ceph #sysadmin #sds #rados #блочное хранилище
-
Список Бесплатных Dns-Сервисов
19 Oct, 24 -
Виджет Со Счетчиком Непрочитанных Сообщений
19 Oct, 24
