Администрирование и архитектура Ceph

Введение в Ceph: архитектура RADOS, компоненты кластера и алгоритм CRUSH

Добро пожаловать на курс «Администрирование и архитектура Ceph». Мы начинаем погружение в одну из самых мощных и востребованных систем хранения данных в мире IT-инфраструктуры. В этой первой статье мы разберем фундамент, на котором строится Ceph, поймем, почему он считается стандартом де-факто для облачных сред, и детально изучим его внутреннюю магию — алгоритм CRUSH.

Что такое Ceph и зачем он нужен?

Ceph — это программно-определяемая система хранения данных (Software Defined Storage, SDS) с открытым исходным кодом. Главная особенность Ceph заключается в том, что она предоставляет унифицированное хранилище. Это означает, что в рамках одного кластера вы можете получить доступ к данным тремя разными способами:

Блочное устройство (RBD): Как виртуальный жесткий диск, который можно подключить к серверу (аналог SAN).

Объектное хранилище (RGW): Доступ по API S3 или Swift (аналог AWS S3).

Файловая система (CephFS): Распределенная файловая система, совместимая с POSIX (аналог NAS).

Традиционные системы хранения часто требуют дорогостоящего проприетарного оборудования (RAID-контроллеры, специализированные полки). Ceph же спроектирован для работы на commodity hardware — обычном серверном оборудовании. Вся логика надежности, репликации и восстановления перенесена с «железа» на программный уровень.

Ключевые характеристики Ceph: * Масштабируемость: От нескольких терабайт до эксабайт данных. * Отсутствие единой точки отказа: Все компоненты распределены и дублированы. * Самовосстановление: Система автоматически обнаруживает сбои и восстанавливает целостность данных без участия администратора.

Фундамент системы: RADOS

В основе Ceph лежит технология RADOS (Reliable Autonomic Distributed Object Store — Надежное автономное распределенное хранилище объектов). Независимо от того, используете ли вы блочное устройство, S3 или файловую систему, все данные в конечном итоге превращаются в объекты и сохраняются в RADOS.

Представьте RADOS как огромный, умный бассейн данных. Он берет на себя всю сложную работу: * Репликацию данных (создание копий). * Проверку целостности (Scrubbing). * Балансировку нагрузки. * Восстановление после сбоев.

Пользовательские интерфейсы (RBD, RGW, CephFS) — это лишь надстройки, которые «общаются» с RADOS через библиотеку librados.

!Диаграмма уровней архитектуры Ceph, показывающая, как различные интерфейсы доступа базируются на едином слое RADOS.

Компоненты кластера Ceph

Чтобы RADOS работал, ему необходим набор демонов (сервисных процессов), каждый из которых выполняет свою уникальную роль. Рассмотрим «анатомию» кластера.

1. Ceph Monitor (MON)

Мониторы — это «мозг» кластера. Они не хранят данные пользователей. Их задача — хранить карту кластера (Cluster Map). Карта кластера — это небольшая база данных, описывающая текущее состояние всей системы: какие узлы в строю, какие диски работают, как настроена топология сети.

* Функция: Поддержание кворума и консенсуса о состоянии кластера. * Алгоритм: Использует алгоритм Paxos для обеспечения согласованности данных между мониторами. * Количество: Для надежности всегда требуется нечетное количество мониторов (обычно 3 или 5), чтобы избежать ситуации «split-brain» (расщепления сознания), когда кластер не может договориться, кто прав.

2. Ceph OSD (Object Storage Daemon)

OSD — это «мышцы» кластера. Это демоны, которые непосредственно работают с дисками (HDD или SSD). Обычно на каждый физический диск запускается один процесс OSD.

* Функция: Хранение данных, чтение, запись, репликация данных на другие OSD, сообщение мониторам о своем состоянии («я жив», «я умираю», «соседний диск не отвечает»). * Взаимодействие: Клиенты читают и пишут данные напрямую в OSD, минуя мониторы (после получения карты).

3. Ceph Manager (MGR)

Менеджер работает в паре с монитором. Он берет на себя задачи, которые не требуют строгой консистентности Paxos, разгружая тем самым мониторы.

* Функция: Сбор метрик производительности, управление дашбордом, оркестрация внешних модулей (например, интеграция с Prometheus или Zabbix).

4. Metadata Server (MDS)

Этот компонент нужен только если вы используете файловую систему CephFS. В блочном и объектном хранилище он не участвует.

* Функция: Хранение метаданных файловой системы (имена файлов, права доступа, структура директорий). Сами данные файлов хранятся в OSD.

Магия распределения данных: Алгоритм CRUSH

Самая большая проблема традиционных хранилищ — это таблица размещения файлов. Когда вы сохраняете файл, контроллер записывает в таблицу: «Файл А лежит на диске 5, сектор 100». Когда файлов становятся миллиарды, эта таблица разрастается до гигантских размеров, становится узким местом и точкой отказа.

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

Для этого используется алгоритм CRUSH (Controlled Replication Under Scalable Hashing).

Как это работает? Путь данных

Процесс записи или чтения данных в Ceph происходит в несколько этапов, которые позволяют равномерно распределять нагрузку.

#### Шаг 1: От объекта к Placement Group (PG)

Представьте, что у вас есть миллионы объектов. Управлять каждым по отдельности и назначать ему конкретный диск — накладно. Поэтому Ceph группирует объекты в логические контейнеры, называемые Placement Groups (PG) или группы размещения.

Формула вычисления PG выглядит следующим образом:

Однако для понимания сути процесса мы можем использовать упрощенную модель:

Где: * — идентификатор группы размещения, в которую попадет объект. * — хеш-функция от имени объекта, превращающая имя в псевдослучайное число. * — операция взятия остатка от деления на . * — общее количество групп размещения (PG) в пуле.

Благодаря этой формуле, зная имя объекта и количество PG, любой клиент и любой демон OSD могут мгновенно вычислить, к какой группе относится объект. Это детерминированный процесс: одно и то же имя всегда даст один и тот же PG.

#### Шаг 2: От PG к списку OSD (CRUSH)

Теперь мы знаем ID группы размещения (например, PG 1.5). Но на каких физических дисках (OSD) хранится эта группа? Здесь вступает в игру алгоритм CRUSH.

CRUSH принимает на вход ID группы размещения и текущую карту кластера (Cluster Map), а на выходе выдает упорядоченный список OSD, где должны храниться реплики данных.

Где: * — идентификатор группы размещения. * — топология кластера (список серверов, стоек, дисков). * — правило репликации (например, «хранить 3 копии, причем на разных серверах»). * — список дисков. становится Primary (главным), остальные — Secondary (репликами).

!Визуализация логики распределения данных: объект хешируется в PG, а затем CRUSH распределяет PG по конкретным OSD.

Почему это гениально?

Нет бутылочного горлышка: Клиенту не нужно спрашивать центральный сервер «где лежит мой файл?». Клиент скачивает карту кластера один раз, а затем сам вычисляет адрес любого объекта. Это позволяет тысячам клиентов работать параллельно.

Топологическая осведомленность: CRUSH понимает физическую структуру вашего дата-центра. Вы можете настроить карту так: «Одна копия в стойке А, вторая в стойке Б, третья в другом здании». Это называется Failure Domain (домен отказа). Если сгорит целая стойка, данные останутся доступны.

Равномерное распределение: Благодаря хешированию, данные «размазываются» по дискам почти идеально ровно. Нет ситуации, когда один диск переполнен, а другой пуст (при правильной настройке количества PG).

Жизненный цикл записи (Write Path)

Чтобы закрепить понимание, проследим путь записи данных:

Клиент хочет записать объект my_photo.jpg.

Клиент обращается к MON, получает копию Cluster Map.

Клиент вычисляет хеш имени и определяет PG.

Клиент применяет CRUSH к PG и карте, получая список OSD: [OSD.5, OSD.12, OSD.8].

Клиент отправляет данные только на первый OSD в списке (Primary OSD — OSD.5).

Primary OSD (OSD.5) принимает данные и параллельно отправляет их на реплики (OSD.12 и OSD.8).

Реплики записывают данные и отправляют подтверждение (ACK) на Primary OSD.

Только когда Primary OSD получит подтверждения от всех реплик, он отправляет ACK клиенту: «Запись успешна».

Это обеспечивает строгую согласованность (Strong Consistency). Вы никогда не прочитаете устаревшие данные, если запись была подтверждена.

Заключение

Мы рассмотрели архитектуру Ceph на высоком уровне. Теперь вы знаете, что: * RADOS — это надежный фундамент объектного хранения. * MON, OSD, MGR — основные компоненты, обеспечивающие жизнь кластера. * CRUSH — это алгоритм, который заменяет централизованные таблицы адресации математическими вычислениями, обеспечивая бесконечную масштабируемость.

В следующей статье мы перейдем от теории к практике и рассмотрим процесс подготовки инфраструктуры для развертывания вашего первого кластера Ceph.

Развертывание кластера Ceph: использование cephadm и базовая конфигурация узлов

В предыдущей статье мы изучили теоретический фундамент Ceph: архитектуру RADOS, роль мониторов и магию алгоритма CRUSH. Теперь пришло время перейти от теории к практике. В этой статье мы разберем современный стандарт развертывания Ceph — использование инструмента cephadm, подготовим серверы и запустим наш первый рабочий кластер.

Эволюция развертывания: почему cephadm?

Раньше администраторы Ceph использовали инструменты вроде ceph-deploy (ныне устаревший) или Ansible-плейбуки. Однако с версии Ceph Octopus (15.2.0) появился новый официальный стандарт — cephadm.

Главное отличие cephadm заключается в том, что он развертывает все демоны Ceph (MON, MGR, OSD) внутри контейнеров (используя Docker или Podman). Это дает огромные преимущества:

Изоляция: Зависимости одного демона не конфликтуют с системными библиотеками.

Простота обновлений: Обновление версии Ceph сводится к замене образа контейнера.

Интеграция с systemd: Несмотря на контейнеризацию, управление службами остается привычным (systemctl status ceph-...).

!Архитектура развертывания через cephadm, показывающая управление контейнерами на удаленных узлах.

Этап 1: Подготовка инфраструктуры

Прежде чем запускать установку, необходимо подготовить «почву». Ceph — это распределенная система, чувствительная к сети и времени.

Требования к оборудованию и ОС

Мы будем рассматривать минимальную конфигурацию для production-ready кластера: * ОС: Linux (RHEL 8/9, Ubuntu 20.04/22.04, Debian 11). * Узлы: Минимум 3 физических или виртуальных сервера (для обеспечения кворума мониторов). * Диски: Отдельные неразмеченные диски для OSD (система должна стоять на отдельном носителе).

Настройка сети

В идеальной архитектуре Ceph использует две сети:

Public Network (Публичная сеть): Для общения клиентов с кластером и мониторов между собой.

Cluster Network (Кластерная сеть): Для репликации данных между OSD. Это позволяет отделить трафик восстановления (recovery) от клиентского трафика.

Синхронизация времени (NTP)

Это критически важный пункт. Алгоритм Paxos, который используют мониторы для консенсуса, требует точного времени. Если часы на узлах разойдутся, мониторы перейдут в состояние сбоя, и кластер остановится.

Убедитесь, что на всех узлах установлен и активен сервис синхронизации (например, Chrony):

Этап 2: Установка cephadm и Bootstrap

Процесс установки начинается на первом узле, который станет первым монитором и менеджером.

Установка инструментария

На первом узле выполните установку пакетов (пример для Ubuntu):

Инициализация кластера (Bootstrap)

Команда bootstrap делает всю грязную работу: создает ключи монитора, запускает первый контейнер MON и MGR, генерирует SSH-ключ для управления остальными узлами.

После успешного завершения вы увидите: * Адрес и логин/пароль для входа в веб-интерфейс (Dashboard). * Команды для доступа к CLI (Command Line Interface).

> «Успешный bootstrap — это рождение новой вселенной данных, где первый монитор становится точкой отсчета для всего кластера.»

Этап 3: Добавление узлов в кластер

Сейчас у нас есть кластер из одного узла. Чтобы сделать его распределенным, нужно добавить остальные серверы. Cephadm использует SSH для доступа к новым хостам.

Копирование ключа: Во время bootstrap был сгенерирован публичный SSH-ключ (/etc/ceph/ceph.pub). Его нужно скопировать на все новые узлы в файл authorized_keys пользователя root (или пользователя с sudo правами).

Добавление через CLI: Теперь сообщим оркестратору о новых узлах.

Проверить статус узлов можно командой:

Этап 4: Добавление хранилища (OSD)

Самый интересный этап — превращение пустых дисков в OSD. В cephadm для этого используется концепция Drive Groups или спецификаций служб.

Вы можете добавить OSD двумя способами:

Способ А: «Забрать все свободное» (Для простых инсталляций)

Вы можете сказать Ceph: «Используй все неиспользуемые диски на всех узлах».

Способ Б: Точечная настройка (Для PROD)

В реальных условиях часто требуется разделить диски (например, быстрые NVMe для базы данных RocksDB, а медленные HDD для самих данных). Для этого создается YAML-файл спецификации.

Пример простой спецификации osd_spec.yaml:

Применение спецификации:

После этого вы увидите, как запускаются новые контейнеры OSD. Проверить дерево устройств можно командой:

Планирование ресурсов: Математика памяти

При развертывании OSD важно правильно рассчитать оперативную память (RAM). Каждому процессу OSD требуется память для кэширования метаданных и буферов записи. Недостаток памяти приведет к падению производительности или OOM-Killer (принудительному завершению процессов системой).

Базовая формула для оценки минимально необходимого объема RAM выглядит так:

Где: * — требуемый объем оперативной памяти на узле. * — количество дисков (OSD) на данном узле. * — базовое потребление памяти на один OSD. Для современных версий Ceph (BlueStore) рекомендуется закладывать минимум 4 ГБ на один HDD (и больше для SSD/NVMe). * — резерв памяти для операционной системы и других служб (обычно 4–8 ГБ).

Например, если у вас сервер с 12 дисками, расчет будет следующим:

Это означает, что сервер с 32 ГБ RAM не сможет стабильно обслуживать 12 дисков OSD.

Базовая проверка состояния

После добавления дисков ваш кластер должен прийти в состояние HEALTH_OK. Проверьте это главной командой администратора:

Вывод должен выглядеть примерно так:

Если вы видите HEALTH_WARN, не паникуйте. Ceph часто предупреждает о мелочах, например, об отсутствии настроенных пулов, что мы исправим в следующих уроках.

Заключение

Поздравляю! Вы только что развернули программно-определяемое хранилище корпоративного уровня. Мы использовали cephadm для оркестрации контейнеров, объединили узлы в единую сеть и запустили OSD демоны.

В этой статье мы:

Подготовили инфраструктуру (сеть и NTP).

Инициализировали кластер через cephadm bootstrap.

Масштабировали кластер на несколько узлов.

Добавили дисковое пространство.

Теперь у вас есть рабочий «двигатель» Ceph. Но пока он работает вхолостую. В следующей статье мы научимся создавать Пулы (Pools), рассчитывать Placement Groups (PGs) и предоставлять доступ к данным клиентам.

Типы хранилищ: работа с блочными устройствами RBD, файловой системой CephFS и шлюзом RGW

Добро пожаловать на третью часть курса «Администрирование и архитектура Ceph». В прошлых статьях мы заложили фундамент: разобрали архитектуру RADOS, магию алгоритма CRUSH и развернули свой первый кластер с помощью cephadm.

Но давайте будем честны: сам по себе кластер Ceph («голое» хранилище объектов RADOS) для конечного пользователя бесполезен. Вы не можете установить Windows на «объект», и ваш веб-браузер не умеет сохранять картинки напрямую в OSD. Нам нужны интерфейсы — «переводчики», которые превращают абстрактные объекты RADOS в понятные сущности: диски, файлы и бакеты.

Сегодня мы разберем «Святую Троицу» Ceph:

RBD (RADOS Block Device) — блочное устройство.

CephFS (Ceph File System) — распределенная файловая система.

RGW (RADOS Gateway) — объектный шлюз S3/Swift.

---

1. RBD: Виртуальный диск, который никогда не умрет

RBD — это самый популярный способ использования Ceph. Представьте себе жесткий диск, который не находится внутри вашего сервера, а «размазан» по сети. Операционная система видит его как обычное устройство /dev/rbd0, форматирует его в ext4 или xfs, но физически данные лежат на десятках разных серверов.

Как это работает? Стрипинг (Striping)

Когда вы создаете в Ceph диск размером 100 ГБ, система не ищет 100 ГБ свободного места на одном физическом диске. Она разбивает этот виртуальный диск на маленькие кусочки — объекты (по умолчанию 4 МБ). Этот процесс называется стрипингом.

!Визуализация того, как единый образ диска разбивается на объекты и распределяется по кластеру.

Чтобы понять, какой именно объект нам нужен при чтении файла, Ceph использует простую математику. Допустим, мы хотим прочитать данные со смещением (offset) внутри образа диска.

Формула вычисления номера объекта:

Где: * — порядковый номер объекта, в котором находятся искомые данные. * — функция округления вниз до целого числа (floor). * — смещение в байтах от начала виртуального диска (адрес данных). * — размер одного объекта (обычно байт, то есть 4 МБ).

Например, если мы хотим прочитать данные на отметке 10 МБ (10 485 760 байт) при размере объекта 4 МБ:

Это означает, что данные находятся в объекте с индексом 2 (третий по счету, так как отсчет с нуля).

Практика: Создание и подключение RBD

Для работы с блочными устройствами нам сначала нужен пул.

Создание пула:

Инициализация пула:

Создание образа диска (Image):

Создадим диск размером 10 ГБ.

Отображение (Mapping):

Теперь подключим этот сетевой диск к локальной системе (требуется модуль ядра Linux).

Теперь /dev/rbd0 можно использовать как обычный HDD: создать разделы, файловую систему и монтировать.

Особенности RBD

* Thin Provisioning (Тонкое выделение): Если вы создали диск на 1 ТБ, но записали на него 1 МБ, в кластере будет занят только 1 МБ. * Снэпшоты (Snapshots): Мгновенные снимки состояния диска. Идеально для резервного копирования виртуальных машин.

---

2. CephFS: Единая файловая система для всех

Если RBD — это «диск для одного сервера» (обычно нельзя монтировать один RBD на два сервера одновременно без кластерной ФС типа OCFS2), то CephFS — это полноценная сетевая файловая система, аналог NFS, но без узких мест.

С CephFS сотни серверов могут одновременно читать и писать в одну и ту же папку /mnt/shared.

Архитектура: Роль MDS

Здесь на сцену выходит компонент, о котором мы упоминали в первой лекции — MDS (Metadata Server).

В файловой системе есть два типа информации:

Данные: Содержимое файлов (текст, картинки).

Метаданные: Имена файлов, права доступа, структура каталогов, время изменения.

CephFS хранит данные в OSD (как и все в Ceph), а метаданные обслуживает MDS. Это позволяет разгрузить OSD от операций «поиска файла» и ускорить работу с директориями.

!Схема разделения потоков данных и метаданных в CephFS.

Практика: Запуск CephFS

В современных версиях Ceph (с использованием cephadm) создание файловой системы автоматизировано.

Создание тома (Volume):

Эта команда создаст необходимые пулы и запустит демоны MDS.

Монтирование (Kernel Driver):

Самый быстрый способ — использовать драйвер ядра Linux.

Когда использовать CephFS?

* Общие папки для офиса или веб-серверов. * HPC (High Performance Computing) вычисления. * Хранилища контейнеров Kubernetes (ReadWriteMany).

---

3. RGW: Объектное хранилище (S3)

Третий кит Ceph — RADOS Gateway (RGW). Это интерфейс для приложений, а не для операционных систем. Он предоставляет доступ по протоколу HTTP/HTTPS, эмулируя API Amazon S3 или OpenStack Swift.

В чем отличие от файловой системы?

В CephFS у вас есть дерево каталогов. В RGW у вас есть плоская структура: * Бакет (Bucket): Контейнер для объектов (аналог папки верхнего уровня, но без вложенности). * Объект: Файл + Метаданные.

Главное преимущество RGW — доступ к данным из любой точки интернета по URL. Вам не нужно монтировать диск или устанавливать драйверы. Просто отправьте PUT запрос.

Архитектура RGW

RGW — это отдельный демон (сервис), который работает как веб-сервер. Он принимает HTTP-запросы от клиентов, переводит их на язык librados и сохраняет данные в кластер.

!Иллюстрация роли RGW как шлюза между веб-клиентами и кластером RADOS.

Практика: Настройка S3 доступа

Развертывание сервиса RGW:

Создание пользователя:

Чтобы работать с S3, нужны ключи Access Key и Secret Key. В ответ вы получите JSON с ключами.

Использование (пример с AWS CLI):

---

Сравнение типов хранилищ

Чтобы закрепить материал, давайте сведем все три типа в таблицу сравнения.

| Характеристика | RBD (Block) | CephFS (File) | RGW (Object) | | :--- | :--- | :--- | :--- | | Аналог в мире IT | Жесткий диск (SAN) | Сетевая папка (NAS) | AWS S3, Dropbox API | | Протокол доступа | librbd / Kernel module | POSIX (mount) | HTTP REST API | | Основной клиент | Виртуальные машины, БД | Пользователи, кластеры | Приложения (Web, Mobile) | | Совместный доступ | Нет (обычно ReadWriteOnce) | Да (ReadWriteMany) | Да (через API) | | Производительность | Высокая (низкие задержки) | Средняя (накладные расходы MDS) | Высокая пропускная способность |

Заключение

Ceph уникален тем, что объединяет эти три мира в одной системе. Вам не нужно покупать отдельную СХД для виртуализации и отдельный NAS для файлов. Все данные в конечном итоге попадают в один и тот же слой RADOS, распределяются CRUSH-алгоритмом и защищаются репликацией.

Теперь, когда мы умеем создавать пулы, диски и файловые системы, возникает вопрос: как обслуживать этот комбайн? Как менять диски, обновлять систему и следить за здоровьем кластера? Об этом мы поговорим в следующей статье, посвященной Day-2 Operations и мониторингу.

Эксплуатация кластера: управление картами CRUSH, мониторинг состояния и балансировка данных

Добро пожаловать на четвертую часть курса «Администрирование и архитектура Ceph». В предыдущих статьях мы прошли путь от теоретического понимания алгоритмов RADOS до развертывания кластера через cephadm и настройки различных типов хранилищ (RBD, CephFS, RGW).

Однако запуск кластера — это лишь начало пути. Настоящая работа администратора начинается на этапе, который в IT называют Day-2 Operations. Это ежедневная эксплуатация: мониторинг здоровья, замена вышедших из строя дисков, оптимизация распределения данных и обновление конфигурации топологии.

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

Мониторинг состояния кластера

Ceph спроектирован как автономная система. Он сам лечит себя, сам переносит данные и сам сообщает о проблемах. Ваша задача — правильно интерпретировать эти сообщения.

Три состояния здоровья

Основная команда, с которой начинается утро администратора Ceph:

Или более подробная версия:

Кластер может находиться в одном из трех состояний:

HEALTH_OK: Все системы работают штатно. Все данные реплицированы согласно правилам, все демоны активны.

HEALTH_WARN: Предупреждение. Кластер функционирует, данные доступны, но есть проблемы, требующие внимания. Примеры: один из OSD упал, место на дисках заканчивается, или сбились часы (NTP).

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

!Пример вывода команды ceph status и визуализация метрик в Ceph Dashboard.

Состояния OSD: Up/Down и In/Out

Для эффективной эксплуатации важно понимать разницу между состоянием процесса и состоянием данных. У каждого демона OSD есть два флага:

* Up / Down: Отражает состояние процесса (демона). Если демон запущен и отвечает мониторам — он Up. Если сервер выключен или процесс упал — он Down. * In / Out: Отражает участие в распределении данных. Если OSD In, алгоритм CRUSH распределяет на него данные. Если Out, CRUSH считает, что этого диска не существует, и данные на него не пишутся.

Типичный сценарий сбоя: Когда диск ломается, OSD переходит в состояние Down. Спустя определенное время (по умолчанию 600 секунд), монитор помечает его как Out. В этот момент начинается Recovery (восстановление) — кластер понимает, что копий данных стало меньше, чем нужно, и начинает создавать новые копии на оставшихся живых дисках.

Управление картой CRUSH

Карта CRUSH (CRUSH Map) — это схема вашего кластера. Она объясняет алгоритму, какие диски стоят в каких серверах, какие серверы — в каких стойках, а стойки — в каких дата-центрах. По умолчанию Ceph создает плоскую структуру: все хосты находятся в корневом каталоге default.

Однако для настоящей отказоустойчивости вам нужно настроить Failure Domains (домены отказа).

Иерархия ведер (Buckets)

CRUSH оперирует понятием «ведро» (bucket). Ведро — это логический контейнер, который может содержать другие ведра или OSD (листья дерева).

Стандартные типы ведер: * osd (диск) * host (сервер) * chassis (шасси) * rack (стойка) * row (ряд) * room (комната) * datacenter (ЦОД) * region (регион) * root (корень)

!Иерархическая структура карты CRUSH, показывающая вложенность компонентов инфраструктуры.

Вес OSD (Weight)

Как CRUSH решает, сколько данных положить на конкретный диск? Для этого используется параметр Weight (вес). Вес OSD обычно соответствует его объему в Терабайтах.

Формула расчета веса для одного OSD:

Где: * — вес OSD в карте CRUSH. * — емкость диска в Терабайтах. * — коэффициент нормализации (обычно 1 ТБ = 1.0 веса).

Например, диск на 4 ТБ будет иметь вес 4.0, а диск на 18 ТБ — 18.0. Это гарантирует, что диск большей емкости получит пропорционально больше данных.

Вес ведра (например, хоста) рассчитывается как сумма весов его компонентов:

Где: * — общий вес ведра (например, сервера). * — количество элементов внутри ведра. * — вес -го элемента (например, OSD внутри сервера).

Если в сервере стоит 10 дисков по 4 ТБ, вес сервера (host bucket) будет равен 40.0.

Практика: Редактирование карты

Допустим, вы добавили новый сервер node4 и хотите явно указать, что он находится в стойке rack2. Это можно сделать прямо из командной строки, не редактируя файлы вручную.

Создание стойки:

Перемещение стойки под корень:

Перемещение хоста в стойку:

Теперь, если вы настроите правило репликации с шагом step chooseleaf firstn 0 type rack, Ceph будет гарантировать, что копии данных лежат в разных стойках. Если одна стойка сгорит целиком, данные останутся доступны в другой.

Балансировка данных (Balancer)

В идеальном мире данные распределяются по дискам равномерно. В реальности часто возникает перекос: один диск заполнен на 80%, а соседний — на 40%. Это плохо, потому что емкость всего кластера определяется самым заполненным диском (вы не можете записать файл, если одна из его реплик должна попасть на переполненный OSD).

Почему возникает дисбаланс?

Алгоритм CRUSH — псевдослучайный. Как и при подбрасывании монетки, на малых выборках (малое количество Placement Groups) возможны отклонения. Кроме того, вы могли добавлять диски разного размера в разное время.

Ceph Manager Balancer

Начиная с версии Luminous, в Ceph встроен модуль Balancer, работающий на ceph-mgr. Он автоматически анализирует распределение PG и пытается выровнять его.

Проверить статус балансировщика:

Включить балансировщик:

Режимы балансировки

Существует два основных режима работы:

Crush-compat: Меняет веса (reweight) OSD в карте CRUSH. Это старый метод, который может привести к перемещению лишних данных. Он совместим со старыми клиентами.

Upmap (рекомендуемый): Начиная с версии Luminous, Ceph позволяет создавать исключения в таблице маршрутизации. Балансировщик говорит: «Я знаю, что по формуле CRUSH эта PG должна лежать на OSD.1, но я принудительно перенесу её на OSD.2». Это позволяет достичь идеального баланса без изменения весов.

Для использования upmap все клиенты (kernel rbd, librados) должны быть достаточно свежими (Luminous+).

Включение режима upmap:

Целостность данных: Scrubbing

Жесткие диски ненадежны. Иногда биты на пластинах магнитных дисков самопроизвольно меняют значение (bit rot). Чтобы бороться с этим, Ceph использует процесс, называемый Scrubbing (скраббинг или «чистка»).

Существует два типа проверок:

Light Scrubbing (Ежедневно): Проверяет, что метаданные объектов и размеры файлов совпадают на всех репликах. Это быстрая операция.

Deep Scrubbing (Еженедельно): Считывает сами данные бит за битом, вычисляет контрольную сумму и сравнивает её с репликами. Если контрольные суммы не совпадают, Ceph поднимает тревогу (Inconsistent PG) и пытается восстановить правильную версию, используя большинство голосов (если у двух реплик сумма совпадает, а у третьей нет — третья перезаписывается).

> «Deep Scrubbing — это тяжелая операция, которая создает нагрузку на диски. В плохо настроенном кластере это может приводить к просадкам производительности клиентов.»

Вы можете управлять временем скраббинга, чтобы он запускался только ночью:

Заключение

Эксплуатация Ceph — это баланс между автоматизацией и контролем.

Сегодня мы узнали: * Как интерпретировать вывод ceph -s и различать состояния OSD. * Как использовать веса и иерархию CRUSH для управления размещением данных. * Как модуль Balancer помогает использовать дисковое пространство эффективно. * Зачем нужен Deep Scrubbing и как он защищает от «гниения бит».

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

Продвинутые темы: интеграция с Kubernetes через Rook, оптимизация производительности и устранение неполадок

Добро пожаловать на финальную лекцию курса «Администрирование и архитектура Ceph». Мы прошли долгий путь: от понимания алгоритма CRUSH до ежедневной эксплуатации кластера. Теперь, когда вы умеете развертывать и поддерживать Ceph, пришло время заглянуть за горизонт базового администрирования.

В этой статье мы рассмотрим три критически важные темы для современного инженера:

Rook: Как подружить Ceph с Kubernetes и превратить хранилище в облачный сервис.

Оптимизация: Как выжать максимум IOPS и пропускной способности из вашего железа.

Troubleshooting: Методики поиска и устранения сложных проблем, когда простой ceph -s уже не помогает.

---

Часть 1: Ceph в мире Cloud-Native и Rook

Традиционно Ceph разворачивается на выделенных серверах («голое железо»). Однако с ростом популярности Kubernetes (K8s) возникла потребность управлять хранилищем так же, как и приложениями — декларативно, через YAML-манифесты. Здесь на сцену выходит Rook.

Что такое Rook?

Rook — это оператор (Operator) для Kubernetes. Представьте, что вы написали скрипт, который содержит все знания опытного администратора Ceph: как заменять диски, как обновлять версии, как настраивать конфиги. Rook — это и есть такой «робот-администратор», живущий внутри вашего кластера K8s.

Он берет на себя всю рутину: * Развертывание демонов (MON, OSD, MGR) в виде подов (Pods). * Автоматическое обнаружение дисков на узлах K8s. * Управление обновлениями и восстановлением.

!Диаграмма взаимодействия: Пользователь -> YAML (CRD) -> Rook Operator -> Ceph Cluster Pods.

Как это работает: CSI Driver

Самая важная часть интеграции — это CSI (Container Storage Interface). Это стандарт, позволяющий Kubernetes «общаться» с системами хранения.

Когда под в Kubernetes запрашивает диск (Persistent Volume Claim), происходит следующее:

K8s обращается к Rook-Ceph CSI драйверу.

Драйвер идет в Ceph, создает RBD-образ или папку CephFS.

Драйвер монтирует это устройство к нужному контейнеру.

Это происходит прозрачно для разработчика. Ему не нужно знать IP-адреса мониторов или ключи доступа — всё делает Rook.

---

Часть 2: Оптимизация производительности

Ceph — это программно-определяемое хранилище. Это значит, что за гибкость мы платим процессорным временем и задержками (latency). Однако правильная настройка может значительно ускорить кластер.

1. Разделение трафика и Jumbo Frames

Как мы обсуждали ранее, у Ceph есть две сети: Public (для клиентов) и Cluster (для репликации). Критически важно, чтобы сеть репликации была максимально быстрой.

Один из способов снизить нагрузку на CPU — включить Jumbo Frames (MTU 9000). Стандартный размер пакета Ethernet — 1500 байт. При передаче больших объемов данных процессору приходится обрабатывать миллионы пакетов. Увеличение размера пакета в 6 раз снижает количество прерываний процессора.

Для оценки теоретической пропускной способности сети можно использовать следующую формулу:

Где: * — время передачи данных. * — объем данных для передачи. * — пропускная способность канала (Bandwidth). * — эффективность сети (учитывает накладные расходы протоколов TCP/IP; обычно 0.9–0.95).

Если падает из-за фрагментации пакетов или высокой загрузки CPU, время передачи растет. Jumbo Frames помогают держать ближе к идеалу.

2. Тюнинг BlueStore: RocksDB и WAL

Современный бэкенд хранения в Ceph называется BlueStore. Он пишет данные напрямую на диск, минуя файловую систему. Однако у него есть метаданные (карта объектов), которые хранятся в базе данных RocksDB.

Золотое правило производительности: Никогда не храните RocksDB и WAL (Write Ahead Log) на медленных HDD, если у вас есть SSD/NVMe.

* Сценарий: У вас есть сервер с 10 HDD. * Решение: Добавьте 1-2 NVMe диска. При создании OSD укажите, что сами данные лежат на HDD, а DB/WAL — на разделе NVMe.

Это ускорит операции записи в разы, так как подтверждение записи (ACK) клиенту отправляется только после того, как данные попали в журнал (WAL).

3. Настройка профилей питания и ОС

Современные процессоры любят «засыпать» для экономии энергии (C-states). Для хранилища с низкой задержкой это враг. Процессору требуется время, чтобы «проснуться» и обработать запрос.

Рекомендуется использовать утилиту tuned с профилем для высокой пропускной способности:

Или настроить BIOS сервера на режим «Maximum Performance».

---

Часть 3: Устранение неполадок (Troubleshooting)

Когда кластер переходит в состояние HEALTH_ERR, администратор должен действовать хладнокровно. Рассмотрим самые частые проблемы.

1. Slow Requests (Медленные запросы)

Самое частое сообщение в логах: XX slow requests are blocked > 32 sec.

Что это значит? Клиент отправил запрос на чтение или запись, но OSD не ответил за 32 секунды. Это вечность для компьютера.

Причины и диагностика:

Умирающий диск: OSD пытается прочитать битый сектор и зависает. Проверьте dmesg на сервере OSD и SMART показатели диска.

Перегрузка сети: Пакеты теряются или застревают в очередях. Проверьте счетчики ошибок на сетевых картах (ethtool -S eth0).

Высокая нагрузка (Throttling): Если OSD не успевает сбрасывать данные из памяти на диск, он искусственно замедляет прием новых запросов.

Для анализа используйте команду:

Она покажет, какой именно OSD тормозит.

2. OSD Flapping (Мигание OSD)

Ситуация: OSD то up, то down каждые несколько минут.

Это классический признак нестабильной сети или перегруженного процессора. Мониторы Ceph обмениваются с OSD сообщениями «heartbeat» (пульс). Если OSD не отвечает на пульс вовремя, монитор помечает его как мертвого. Затем OSD «отвисает», сообщает, что он жив, и цикл повторяется.

Решение: * Проверьте загрузку канала между OSD и мониторами. * Увеличьте таймауты в конфигурации (временная мера!), например osd_heartbeat_grace.

3. Проблемы с Placement Groups (PG)

Иногда вы можете видеть статусы PG, отличные от active+clean:

* inconsistent: Во время скраббинга (проверки) выяснилось, что реплики отличаются друг от друга. Требуется ручное вмешательство командой ceph pg repair <pg_id>. * degraded: Количество реплик меньше желаемого. Обычно происходит при падении OSD. Это нормально, если идет процесс восстановления. * stale: Мониторы давно не получали вестей от OSD, хранящего эту группу. Скорее всего, проблема в сети.

!Визуальная карта состояний Placement Groups с цветовой кодировкой серьезности проблемы.

---

Заключение курса

Поздравляю! Вы завершили курс «Администрирование и архитектура Ceph». Мы начали с теории объектов RADOS, научились развертывать кластеры, настраивать блочные и файловые хранилища, и закончили тонкой настройкой производительности.

Ceph — это мощный инструмент, который требует уважения и постоянного обучения. Помните главные принципы:

Избыточность — ваше всё. Никогда не экономьте на репликах.

Мониторинг — лучше узнать о проблеме от Prometheus, чем от разгневанных пользователей.

Не паникуйте. Ceph очень живуч. В большинстве случаев он дает вам время на исправление ошибок.

Удачи в управлении вашими петабайтами данных!