Использование Ceph в AccentOS¶

5.1 Наличие графического интерфейса управления SDS, интегрированного в общий интерфейс управления облачной платформы 5.2 Возможность использования all-flash конфигурации дисков узлов хранения — SSD (MLC/eMLC), NVMe/SCM. Возможность создания all-flash конфигураций без выделенных кэш-носителей. 5.7 Наличие интерфейса iSCSI target для внешних подключений.

Возможности¶

Текущие современные продуктивные версии Ceph – Tentacle и Squid.

Ceph — это распределённая платформа хранения, обеспечивающая высокую масштабируемость и отказоустойчивость. Ceph поддерживает работу в качестве отдельной программно-определяемой СХД или совместно с вычислительной нагрузкой в режиме гиперконвергентного облака.

Современная версия Ceph Tentacle 20.2 позволяет поддерживать высокоскоростной режим для варианта репликации и избыточного кодирования с высокой скоростью работы, компрессией данных.

Ceph предоставляет сервисы блочного устройства, сетевой файловой системы (NFS, SMB) и объектного S3-хранилища. Основной рекомендуемый сетевой протокол Ceph – Ethernet/TCP.

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

Ceph поддерживает работу с классическими жёсткими дисками и SSD-дисками с интерфейсами SATA и SAS, а также с современными NVMe-дисками для создания flash storage и all-flash storage.

Ceph обеспечивает высокую производительность, для чего ему нужно предоставить соответствующие ресурсы – CPU, RAM, LAN, и один или несколько дисков одного или разного типа.

Ceph предоставляет ресурсы в виде блочных устройств по традиционным интерфейсам iSCSI, Ceph driver и новому интерфейсу NVMe-oF-TCP.

Ceph обеспечивает разные виды акселерации за счёт использования ресурсов CPU (AVX, QAT), операционной системы (DPDK, SPDK).

Ceph обеспечивает гибкое резервирование хранения и другие функции. Современный Ceph в зависимости от назначения может создавать ёмкие пулы для хранения холодных данных на основе HDD и высокоскоростные пулы на основе NVMe-дисков.

Разворачивание Ceph осуществляется с помощью штатного ПО Cephadm и для пулов больших данных, и для высокоскоростных пулов. Мониторинг Ceph осуществляется с помощью Ceph dashboard через браузер.

Новые версии Ceph для высокоскоростных решений принесут в ближайших релизах исключение блокировок, использование нового механизма хранения метаданных (Crimson-OSD и SeaStore), что ещё больше повысит производительность.

Данный документ будет посвящён рекомендациям при выборе высокоскоростной конфигурации (all-flash storage), поскольку в остальном процесс установки Ceph одинаков и приведён на сайте Ceph. Для установки советуем придерживаться рекомендаций для устанавливаемой версии Ceph, которые могут меняться от версии к версии.

Производительность Ceph¶

Производительность Ceph может быть обеспечена следующими механизмами:

Монопольное использование ресурсов сервера (отключение HT, IOMMU), Huge Pages, SR-IOV, CPU Pinning, NUMA.
Режим энергосбережения CPU должен быть отключён.
Использование современных процессоров с высокой производительностью и поддержкой AVX, QAT (для Intel) и математическими библиотеками (MKL для Intel).
Включение TCMalloc и компиляция с ним.
Поддержка ОС Linux механизмов SPDK/DPDK.
Высокоскоростная сеть, разделение трафика в Public и Cluster сетях.
Использование сетевых адаптеров с CPU offload.
Использование современных интерфейсов с поддержкой SPDK/DPDK (Ceph driver, NVMe-oF-TCP) вместо iSCSI, который остаётся действующим интерфейсом подключения блочных устройств Ceph RBD.
Включение threads для обработки сетевого трафика.
Использование NVMe/SSD enterprise класса с сохранением данных и all-flash конфигурации.
Настройки распределения нагрузки между сервисами — mClock.
Переход в ближайших версиях Ceph от BlueStore к SeaStore и Crimson-OSD для all-flash.

Квалификация¶

Прежде чем начать, обратите внимание, что для создания кластера Ceph необходимы знания в области администрирования Linux, сетей и концепций хранения. Рекомендуется иметь опыт работы с системами Linux, контейнерами, Ansible и интерфейсами, а также с работой в режиме командной строки.

Необходимо иметь предыдущий опыт проектирования и настройки высокопроизводительных серверных систем.

Контейнерный метод разворачивания Ceph даёт лучшую изоляцию и простоту развёртывания, но потребует более высокой квалификации при отладке и настройке высокопроизводительных all-flash кластеров Ceph.

Стратегия развёртывания на основе контейнеров может подойти, если уже есть опыт работы с контейнерами или нет необходимости в настройке и тестировании производительности. Базовое развёртывание может быть правильным выбором, если уже есть опыт настройки ОС и аппаратного уровня.

Обслуживание¶

Ceph является независимым, хорошо интегрированным с OpenStack продуктом. Функционал в SDS Ceph реализован таким образом, чтобы он мог выступать в роли СХД для любой сущности, в том числе и для OpenStack через Cinder driver.

Администрирование Ceph чётко разделено: администрирование физических и внутренних сущностей относится к Ceph (HDD, OSD, пулы), логическими сущностями (блочными устройствами) управляют внешние программы через API. В AccentOS это Cinder driver для Ceph. Такое разделение объясняется тем, что перенос функционала физического управления СХД Ceph (равно как и любой другой СХД) внутрь любого приложения ограничивает его использование только данным продуктом (облаком AccentOS/OpenStack) и не даёт возможности использовать СХД для других целей.

Ceph предоставляет возможность администрирования через модуль Ceph Manager, к которому можно подключиться через Web UI (Ceph Dashboard). Это очень удобный продукт, который даёт возможность выполнять настройки большинства параметров и осуществлять мониторинг.

Для выполнения мониторинга и оповещения о событиях Ceph предлагает шаблоны Zabbix и более современную интеграцию с Prometheus/Grafana.

AccentOS использует SDS Ceph «из коробки», даёт рекомендации по проектированию, настраивает Ceph на производительный режим работы и поддерживает на уровне 3/2-линии технической поддержки.

Ceph Dashboard может быть интегрирован непосредственно в консоль управления AccentOS Dashboard с помощью технологии фреймов:

http://docs.tnxholding.com/2.4.0/ru/modules/dashboard/instruction/identity/frames.html#id2

Рекомендации по подбору оборудования для all-flash Ceph¶

Ceph – это программное обеспечение, которое работает на классических серверах с CPU x86/64, так называемых COTS-серверах. Ceph не использует информацию об отличии серверов между собой и строит распределение ресурсов исходя из ёмкости предоставленных ему дисков. Поэтому, хотя Ceph и может работать на серверах разной конфигурации, разработчики рекомендуют использовать унифицированную конфигурацию для всех узлов хранения (единый тип CPU, RAM, LAN, HDD, SSD, NVMe). Версия модулей Ceph и операционной системы, её компонентов должна быть одинаковой.

У Ceph имеются уникальные аппаратные потребности для каждого типа сервисов управления кластером.

Ceph Monitors¶

Мониторы Ceph ведут информацию о состоянии кластера, включая группы размещения (placement groups) и OSD. Кластеры должны иметь нечётное количество мониторов, обычно 3 или 5, работающих на отдельных хостах. В современных версиях Ceph мониторы хранят данные в RocksDB. Обычно мониторы имеют низкие системные требования даже для всех all-flash развёртываний и могут быть размещены вместе на тех же узлах, что и другие демоны, такие как OSD, при условии, что для демона MON доступно достаточное количество оперативной памяти и процессора.

Менеджеры Ceph¶

Демон-менеджер Ceph Manager (ceph-mgr) собирает и ведёт статистику времени выполнения операций кластера и отвечает за различные функции, включая дашборд, оркестрацию, телеметрию и другие. В целом требования к процессору и памяти низкие, однако они могут стать довольно загруженными для очень больших кластеров, где нужно поддерживать много данных. Обычно менеджер не потребляет больше одного ядра процессора и может выиграть от более высоких тактовых частот. Как правило, для крупных кластеров скорость сбора статистики может быть снижена, что уменьшит потребление ресурсов. Эти демоны обычно расположены вместе с мониторами Ceph.

Ceph OSD¶

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

Общие советы по OSD

Хотя нет конкретного правила относительно количества флэш-устройств в одном узле, замечено, что с очень высокоскоростными NVMe-устройствами в некоторых случаях можно достичь предела масштабирования на узел при 4–6 дисках. Цену, ёмкость и производительность следует тщательно учитывать при выборе конфигурации узлов OSD. Обычно меньшие узлы с меньшим количеством OSD на узел обеспечивают более высокую производительность и лучшую отказоустойчивость, тогда как крупные узлы обеспечивают большую плотность и меньшие первоначальные затраты.

Каждый OSD может использовать до 12+ ядер на быстрых NVMe-дисках. Ожидайте, что процессор может быть ограничен для небольших нагрузок ввода-вывода при использовании меньшего количества (в зависимости от скорости используемых флэш-устройств).

Используйте NVMe-диски Enterprise Class с защитой от потери питания, так как они безопаснее и часто быстрее потребительских дисков. Также обратите внимание на реализацию TRIM и на то, нужна ли онлайн-TRIM для использования демона OSD Ceph.

Дайте OSD достаточно памяти для предотвращения промахов кэша и, возможно, больше для кэширования объектных данных. Относитесь к норме «1 ГБ памяти на 1 ТБ хранилища» как к очень приблизительной оценке.

Процессор OSD

Полностью флэш-OSD Ceph могут использовать значительные ресурсы процессора в зависимости от выполняемой нагрузки. К сожалению, некоторые производители ранее рекомендовали для Ceph OSD на флеш-базе всего 2 ядра. Но высокопроизводительный кластер Ceph на базе флэш-памяти может использовать до 12 ядер на один OSD при многоузловом развёртывании и максимальной нагрузке.

OSD NVMe

Ceph OSD имеют специфические требования к базовым устройствам хранения. В частности, Ceph требует аппаратных гарантий, что все данные для всех реплик будут безопасно записаны до того, как диск потеряет питание при аварии. Эта функция имеется у Enterprise class устройств и отсутствует в бытовых NVMe-дисках.

Бытовые диски также не способны поддерживать заявленную производительность в течение длительного времени, что недопустимо для СХД.

Корпоративные диски не только быстрее, но они более надёжны для корпоративных задач, таких как Ceph. Обычно у них более высокая выносливость записи (DWPD), чем у потребительских дисков, и лучшее поведение при выравнивании износа. Для кластеров, ориентированных на чтение, корпоративных дисков с одной перезаписью диска в день (1 DWPD) обычно достаточно для многолетних развёртываний с типичным уровнем отказов. Для кластеров, ориентированных на интенсивную запись, желательными могут быть диски с 3 или 5 DWPD в зависимости от нагрузки, общего дизайна кластера и ожидаемого срока службы.

По умолчанию Ceph OSD не выполняют онлайн-операции TRIM/сброса, так как не все диски и прошивки ведут себя хорошо при активном устройстве. Тщательно проанализируйте влияние операций TRIM на устройство и возможность их включения на вашем кластере. Также рассмотрите устройства, которые могут автоматически выполнять внутреннюю операцию TRIM.

Память OSD

OSD Ceph используют память для различных целей — от хранения внутри памяти представлений карт кластера и журналов последних операций до кэширования объектных данных и метаданных. Многие руководства по Ceph рекомендуют 1 ГБ памяти на 1 ТБ хранящихся данных. Хотя это удобная оценка, она плохо работает для очень маленьких или очень больших размеров дисков. OSD с SSD на 1 ТБ будет работать плохо или даже нестабильно, если он ограничен 1 ГБ памяти. Точно так же преимущество предоставления OSD, работающих на дисках большой ёмкости (30–60 ТБ) с десятками ГБ памяти, очень зависит от ситуации.

Более точный ответ: внутри OSD есть несколько потребителей памяти. Некоторые потребители имеют постоянные потребности, некоторые растут с размером кластера, а некоторые, например внутренние объектные данные и кэши метаданных, могут масштабироваться в зависимости от требований к производительности.

По умолчанию целевой объём памяти OSD — 4 ГБ (в контейнерных развёртываниях целевой объём памяти может быть установлен как доля лимита контейнера при включении osd_memory_target_autotune). Этого достаточно для обычных потребностей OSD, плюс около 1–3 ГБ памяти для кэшей BlueStore. Точная величина зависит от фрагментации объектов и других факторов. Из памяти, назначенной кэшам BlueStore, самым важным с точки зрения производительности является кэш метаданных BlueStore (onode). На кластерах с полностью флэш-памятью промахи по onode относительно очень дороги, и их следует минимизировать.

В результате Ceph по умолчанию агрессивно отдаёт приоритет мета-кэшу над кэшем данных и KV (в основном omap). Для проверки эффективности кэширования onode Ceph предоставляет различные счётчики производительности для каждого OSD, которые можно проверить:

ceph tell osd.N perf dump

Например, следующие два счётчика показывают, насколько эффективно OSD кэширует onode:

"onode_hits": 13789150,
"onode_misses": 46427,

Для all-flash кластеров рекомендуется поддерживать уровень попадания кэша onode на уровне 90% и выше. В качестве основного правила — масштабируйте osd_memory_size (или лимит контейнера) в зависимости от того, сколько горячих данных могут быть активными в кластере одновременно.

Если большая часть данных, хранящихся в кластере, обычно холодная, можно остаться со стандартной целевой памятью. Если большая часть данных горячая, особенно на больших дисках, может быть полезно использовать целевые значения памяти 8 ГБ и выше.

Помимо счётчиков попаданий в кэш, OSD также предоставляют счётчики производительности, показывающие, как система управления памятью PriorityCache от Ceph приоритизирует память для каждого кэша на разных уровнях. Например, следующий фрагмент показывает, как память назначается на «мета»-кэш BlueStore на разных уровнях приоритета:

"bluestore-pricache:meta":
    "pri0_bytes": 0,
    "pri1_bytes": 29880,
    "pri2_bytes": 178434427,
    "pri3_bytes": 14895681,
    "pri4_bytes": 14940,
    "pri5_bytes": 59761,
    "pri6_bytes": 0,
    "pri7_bytes": 0,
    "pri8_bytes": 0,
    "pri9_bytes": 0,
    "pri10_bytes": 0,
    "pri11_bytes": 0,
    "reserved_bytes": 75000767,
    "committed_bytes": 268435456

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

RadosGW¶

При развёртываниях на HDD одного или небольшого количества экземпляров RadosGW может быть достаточно для обеспечения сбалансированной архитектуры.

Для all-flash развёртывания требуется значительно больше экземпляров, и для достижения оптимальной производительности могут потребоваться экземпляры RadosGW с существенно более высокими аппаратными требованиями.

Соотношение 1 демон RGW на каждые 3 OSD в масштабе нереалистично, а расход процессора у демонов RGW значителен. Фактически совокупное потребление процессора у RGW демонов было выше, чем у OSD в нескольких тестах.

Масштабирование количества демонов RGW значительно выше 20 может быть сложным без тщательного планирования. Дополнительная настройка и оптимизация кода могут улучшить использование и производительность процессора RGW в будущем. RGW также может показывать более высокую эффективность (хотя и с меньшей производительностью), если используется меньше демонов. Пока что, возможно, придётся выделять значительные ресурсы процессора при попытке достичь максимальной производительности для демонов RGW, поддерживаемых кластером OSD на базе флэш-памяти. RGW и любые узлы HAProxy также могут потребовать значительных вложений в сетевую пропускную способность для соответствия совокупной пропускной способности узлов OSD для больших объектных рабочих нагрузок.

CephFS MDS¶

Ceph использует один или несколько серверов метаданных (MDS) для обработки запросов метаданных для распределённой файловой системы CephFS. Один MDS может быть достаточен для all-flash кластеров Ceph, если количество операций с метаданными файлов и каталогов остаётся ограниченным. Для нагрузок, требующих больших затрат на метаданные, может потребоваться развёртывание нескольких активных MDS.

Каждая MDS имеет относительно низкие требования к процессору, обычно используя не более 2–3 ядер. Высокие тактовые частоты обычно полезны. Ceph MDS имеют распределённый кэш, который может значительно расти при работе с множеством клиентов. При больших нагрузках на метаданные может потребоваться назначать десятки ГБ памяти в кэш MDS. В некоторых сложных случаях использования метаданных один MDS может одновременно использовать 80 ГБ и более памяти.

Сеть¶

При внедрении All-Flash Ceph задержка и пропускная способность сети могут существенно влиять на общую производительность. Стандартная рекомендация — использовать 1 или 2 интерфейса в объединённой конфигурации LACP с отдельными VLAN для пользовательской и кластерной сетей. Если используются два независимых интерфейса, убедитесь, что они не находятся в одной подсети.

Лучше всего выбирать высокопроизводительные сетевые карты с достаточной пропускной способностью для удовлетворения потребностей восстановления и больших операций чтения/записи. При использовании NVMe-дисков это может означать 1–2 ГБ/с на один OSD или более. По возможности старайтесь приобретать неблокируемые коммутаторы с низкой задержкой и полной пропускной способностью. Держите OSD на минимальной топологии коммутаторов, даже на одном коммутаторе для небольших развёртываний. В противном случае тщательно планируйте топологию сети, исходя из общей пропускной способности и потребностей в задержке. Используйте качественные кабели и оптику и держите маршруты до узлов OSD как можно короче.

Конфигурация программного обеспечения¶

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

Операционная система¶

Ceph хорошо работает с несколькими дистрибутивами Linux, однако есть несколько ключевых моментов, которые особенно важны для all-flash развёртывания Ceph.

Настройки ОС

Настройки буферов ввода-вывода, сетевых адаптеров, механизмы обработки запросов должны быть установлены в соответствии с рекомендациями Ceph с учётом возможностей и типов дисков (HDD, SSD, NVMe) и сетевых контроллеров. Драйверы устройств должны быть обновлены до последних рекомендованных версий.

TCMalloc

Крайне важно, чтобы Ceph был скомпилирован с поддержкой tcmalloc. Без него Ceph будет медленнее и потреблять значительно больше памяти.

Обратите внимание, что исполняемый файл ceph-osd может находиться в разных директориях в зависимости от дистрибутива и способа установки. На момент написания этого текста ни пакеты Ubuntu, ни Debian для Ceph не компилируются с поддержкой tcmalloc.

Помимо компиляции Ceph с поддержкой tcmalloc, важно, чтобы клиенты, использующие библиотеки Ceph, также были скомпилированы с tcmalloc. Компиляция QEMU с поддержкой tcmalloc значительно улучшает производительность одного клиента при использовании all-flash кластера Ceph.

IOMMU

Если Ceph не работает в гиперконвергентной среде и на узле не требуется гипервизор, отключение IOMMU может повысить его производительность на 50–100%.

Состояния питания процессора

Предотвращение перехода процессоров между состояниями низкого и высокого энергопотребления на узлах OSD может привести к значительному снижению задержек и повышению производительности. Один из самых простых способов сделать это — использовать tuned-adm. Tuned-adm доступен на дистрибутивах RedHat и Debian. Tuned обычно по умолчанию ориентируется на профиль пропускной способности и производительности:

tuned-adm active
# Текущий активный профиль: throughput-performance

Рекомендуется профиль с настройками latency-performance или network-latency, так как оба имеют несколько полезных стандартных настроек для Ceph. Это можно настроить с помощью следующей команды:

sudo tuned-adm profile network-latency

Локальная сеть

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

Конфигурация кластера¶

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

Уровень Debug для журналирования

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

По умолчанию RGW записывает информацию о каждом запросе в журнал rgw, чтобы улучшить видимость попыток доступа. Для высокоскоростных all-flash развёртываний это приводит к дополнительным накладным расходам и использованию диска. Отключение журнала доступа RGW может повысить производительность и эффективность, но увеличить риск безопасности.

В крупных кластерах с большим количеством OSD (или небольших кластерах, где количество PG выше обычного) MGR-узлы могут замедляться из-за большого количества обновлений статистики PG. В таком случае частоту обновлений MGR можно контролировать с помощью следующих двух настроек:

mgr_tick_period
mgr_stats_period

Конфигурация OSD

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

ceph orch daemon add osd ceph-nvme01:/dev/nvme0n1 osds_per_device=1

Репликация и размещение данных

Ceph позволяет использовать несколько стратегий репликации для пулов. В основном пользователь может выбрать между репликацией (обычно 3) и избыточным кодированием (EC). Для каждого из них есть вопросы по использованию дискового пространства и производительности. В новой версии Tentacle режим избыточного кодирования приблизился к простой репликации по производительности при существенно большем объёме хранения.

Помимо стратегии кодирования, пулы Ceph настроены с определённым количеством PG. По умолчанию Ceph пытается автоматически масштабировать количество PG в зависимости от объёма данных в пуле, а также пытается автоматически сбалансировать распределение данных между PG.

Процесс увеличения и уменьшения количества PG в пуле накладывает дополнительные нагрузки как фоновая операция и часто приводит к низкому числу PG, что снижает производительность. Теоретически более равномерное распределение данных между PG может помочь. Конфликты внутри OSD сами по себе могут стать серьёзным узким местом.

Большое количество PG значительно улучшает производительность случайного чтения в 4K, но очень большое количество PG будет потреблять больше памяти, оставляя меньше кэша, а обновления характеристик PG в менеджере могут вызвать дополнительные нагрузки. Чтобы установить высокое количество PG, необходимо выбрать один из вариантов проверки оптимального количества PG.

Тестирование и верификация¶

Существует множество инструментов, которые могут помочь в тестировании производительности all-flash кластеров Ceph. Ниже приведён неполный список:

(здесь можно перечислить инструменты, например rados bench, fio и т.д. — автор исходного текста не привёл список, оставлено как есть)

Мониторинг и обслуживание¶

По мере старения кластера и увеличения объёма хранящихся данных некоторые операции в Ceph могут замедляться. RocksDB, например, может потребоваться пройти дополнительные уровни для поиска метаданных объектов, а дисковый аллокатор может тратить немного больше времени на поиск непрерывного свободного пространства, если BlueStore стал фрагментированным. All-flash кластеры Ceph должны быть более устойчивы к этим проблемам, однако есть несколько моментов, которые стоит учитывать.

Обычно лучше работать ниже максимальной мощности. Нет жёсткого правила, насколько близко к полному — это слишком близко. Однако если занятое пространство превышает 50%, стоит внимательно следить за темпами роста и начинать планировать расширение. Работа почти на пределе занятости может быть опасной: потеря стойки, узла или даже просто диска может привести к сбою восстановления, если не осталось достаточно ёмкости для записи новых копий данных. Само восстановление создаёт большую нагрузку на устройства для записи, что увеличивает вероятность второго сбоя в процессе восстановления. Также для SSD может быть медленнее и сложнее запускать кластер, близкий к максимальной ёмкости, когда свободное пространство фрагментировано.

Многие SSD требуют периодических TRIM для поддержания высокой производительности и снижения внутреннего износа записи. Совместимость, накладные расходы и продолжительность операций TRIM различаются. Рекомендуется периодически проверять SMART-статус устройств OSD на базе флэш-памяти и убедиться, что нет предупреждений и/или быстро ухудшающихся счётчиков износа. Обращайте внимание на скорость изменения индикаторов износа носителей и планируйте замену SSD задолго до их износа.

Особенности оптимизации для гомогенных сред¶

Начиная с версии Luminous, Ceph ввёл несколько оптимизаций, касающихся сред с гомогенными дисками (неважно, HDD или SSD). Суть оптимизаций заключается в простой логике:

Если диски одинаковые, то нет смысла выделять отдельные диски под BlueStore, который обычно состоит из WAL и RocksDB. Эти данные можно размещать вместе с хранимыми данными на одном устройстве — это дешевле, поскольку все данные (служебные и пользовательские) занимают место более эффективно, и нет проблем с дополнительной защитой служебных данных.
Для гомогенных SSD отпадает необходимость в журнале WAL, так как скорость записи в любое место одинаковая, значит, место под WAL не требуется.
Исключается дополнительное переписывание из WAL в область хранения данных.
Освобождаются порты (особенно важно для NVMe) для увеличения количества установленных дисков.

Общий процесс авторазворачивания Ceph¶

После первоначальной установки операционных систем на хосты, Ceph устанавливает всё необходимое ПО и конфигурационные файлы на один из узлов хранения (процедура bootstrap) и после получения минимальной информации от администратора (используемые для Ceph хосты, тип кодирования/репликации, компрессию, топологию, сети) выполняет автоопределение дисков на хостах, определяет по умолчанию количество и расположение мониторов, расположение WAL/DB (в гомогенной среде all-flash WAL/DB хранятся вместе с данными, параметры совместного хранения устанавливаются автоматически, как было описано в предыдущем пункте).

Процесс установки Ceph с помощью FirstBoot включён в общую инструкцию установки по ссылке (ссылка на инструкцию). # здесь нужно будет заменить на ссылку