Ceph: обзор распределённого TCP-хранилища петабайт данных — RADOS, OSD, PG, RBD, S3 и CephFS

Ceph — это программно-определяемая распределённая система хранения, которая объединяет в одном кластере объектный, блочный и файловый доступ к данным. Она предназначена для построения масштабируемого хранилища из серверов стандартной архитектуры и может использоваться для хранения очень больших объёмов данных — от десятков терабайт до петабайтных и более крупных инфраструктур. Архитектура Ceph построена вокруг распределённого объектного хранилища RADOS, поверх которого реализованы RBD, RGW и CephFS.

Система не просто хранит, а сама распределяет данные между OSD, отслеживает состояние кластера, выполняет репликацию

В названии этой статьи Ceph назван TCP-хранилищем не потому, что TCP является моделью хранения. Правильнее говорить о сетевом распределённом хранилище, в котором клиенты и внутренние компоненты взаимодействуют по сетевому протоколу Ceph Messenger, а стандартный POSIX-транспорт использует TCP/IP. Современный Ceph поддерживает Messenger v2, а в конфигурации можно разделить public network и cluster network для клиентского трафика и внутренней репликации, heartbeat, recovery и backfill.

Главная особенность Ceph заключается не просто в способности хранить петабайты. Система сама распределяет данные между OSD, отслеживает состояние кластера, выполняет репликацию или erasure coding, восстанавливает данные после отказов и перераспределяет нагрузку при изменении состава инфраструктуры. Это позволяет строить scale-out storage, где увеличение ёмкости и производительности достигается добавлением новых узлов и дисков.

Что такое Ceph

Для CIO и ИТ-руководителя Ceph имеет смысл рассматривать не как отдельный файловый сервер, а как унифицированную программную платформу хранения. Один и тот же кластер RADOS может одновременно обслуживать виртуальные машины через RBD, приложения через S3-совместимый RGW и файловые рабочие нагрузки через CephFS.

Внутри Ceph данные не хранятся как обычное дерево файлов или как набор дисков, собранных в единый RAID. Пользовательский интерфейс преобразует данные в набор объектов RADOS, а затем механизм размещения CRUSH определяет, где должны находиться соответствующие placement groups и OSD. Такой подход позволяет отказаться от центральной таблицы, в которой для каждого блока необходимо хранить его физический адрес. Клиент и OSD используют карту кластера и CRUSH для вычисления расположения данных.

На практике Ceph особенно интересен там, где требуется сочетание нескольких характеристик:

• горизонтальное масштабирование вместо постоянного наращивания одного storage-контроллера;
• отказоустойчивость на уровне распределённого кластера;
• работа с десятками и сотнями дисков и OSD;
• поддержка object, block и file storage в единой системе;
• программное управление репликацией и размещением;
• возможность использовать стандартные серверы и сетевую инфраструктуру;
• интеграция с виртуализацией, Kubernetes, OpenStack и аналитическими платформами.

При этом Ceph требует гораздо более внимательного проектирования, чем традиционный NAS. На производительность влияют сеть, тип и количество дисков, OSD, размеры и распределение PG, правила CRUSH, репликация, recovery и характер нагрузки. Поэтому Ceph — это не просто «поставить программу на несколько серверов и объединить диски», а полноценная распределённая storage-архитектура.

Как появился

История Ceph начинается в исследовательской среде. Проект возник в Storage Systems Research Center Университета Калифорнии в Санта-Крузе. В 2004 году Sage Weil начал работу над Ceph в рамках исследования систем хранения петабайтного масштаба, финансировавшегося при участии национальных лабораторий США. В 2006 году работа была представлена на OSDI, а исходный код Ceph стал доступен как open source.

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

Одним из фундаментальных результатов этой работы стал алгоритм CRUSH — Controlled Replication Under Scalable Hashing. Его задача — вычислять размещение данных в распределённом кластере без необходимости обращаться к центральной таблице соответствия «объект → физический диск». Это принципиально отличает Ceph от многих более традиционных storage-архитектур.

Зачем нужен

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

Например, виртуальные машины получают виртуальные диски через RBD, приложения работают с объектами через S3 API RGW, а вычислительные узлы монтируют CephFS как POSIX-файловую систему. Все три интерфейса в конечном счёте используют один распределённый storage backend — RADOS.

Для корпоративной инфраструктуры это позволяет использовать Ceph в нескольких классах задач:

• виртуализация — диски виртуальных машин;
• private cloud — storage для OpenStack и аналогичных платформ;
• Kubernetes — persistent volumes через Ceph CSI;
• Data Lake — объектное хранение больших массивов данных;
• резервное копирование — масштабируемое объектное или блочное хранилище;
• HPC — параллельный доступ к файловым данным;
• медиаданные — большие объёмы файлов и объектов;
• корпоративные файловые ресурсы — через CephFS.

При этом не стоит воспринимать Ceph как универсальную замену абсолютно любого storage. Высоконагруженная транзакционная СУБД, специализированный SAN, файловая система для специфического HPC-профиля и S3 Data Lake имеют разные требования. Сильная сторона Ceph — именно унификация и горизонтальное масштабирование.

RADOS Gateway и S3 API

RADOS Gateway (RGW) предоставляет поверх Ceph интерфейс объектного хранилища. Для приложения это уже не RADOS и не OSD, а HTTP/REST API, совместимый с базовой моделью Amazon S3. RGW также поддерживает совместимость с OpenStack Swift.

Таким образом, приложение может обращаться к Ceph примерно так же, как к S3-совместимому object storage: создавать bucket, загружать object, читать object, удалять его и выполнять другие поддерживаемые операции. А RGW переводит эти запросы в операции над RADOS.

Приложение
    │
    │ HTTP / S3 API
    ▼
RADOS Gateway
    │
    │ RADOS
    ▼
Ceph Storage Cluster
    │
    ├── OSD
    ├── OSD
    ├── OSD
    └── OSD

RGW имеет собственную модель пользователей и аутентификации. В частности, для S3-запросов поддерживаются AWS Signature механизмы, а доступ к bucket и object может регулироваться ACL и политиками.

Для ИТ-архитектуры RGW особенно интересен как основа частного S3: можно предоставить приложениям и аналитическим системам объектный API, не привязывая их к публичному облачному провайдеру.

RADOS Block Device

RADOS Block Device (RBD) превращает Ceph в распределённое блочное хранилище. Клиент получает виртуальный block device, который может использоваться как диск для виртуальной машины, контейнерной платформы или другого приложения, работающего с блочным устройством.

RBD поддерживает thin provisioning, изменение размера, snapshots и cloning, а данные виртуального устройства распределяются по нескольким OSD. Это делает RBD естественным интерфейсом для инфраструктур виртуализации.

Типичный сценарий выглядит следующим образом:

VM / QEMU
    │
    ▼
RBD image
    │
    ▼
RADOS objects
    │
    ├── OSD.01
    ├── OSD.07
    ├── OSD.12
    └── OSD.19

Для виртуализации особенно полезна возможность создавать snapshot образа и затем использовать его как основу для клонов. Например, можно создать эталонный образ операционной системы, сделать snapshot и на его основе быстро создавать новые виртуальные диски.

POSIX-совместимая файловая система

CephFS предоставляет поверх RADOS полноценный файловый интерфейс, совместимый с POSIX. Пользователь работает с каталогами и файлами, а Ceph самостоятельно распределяет содержимое по объектному слою.

Архитектура CephFS разделяет metadata и file data. Метаданные обслуживаются Metadata Server, а сами данные хранятся в RADOS. При этом клиент получает прямой доступ к RADOS для операций с данными файлов, то есть MDS не становится универсальным прокси для всего I/O.

Это принципиально важно для масштабирования. MDS занимается каталогами, именами файлов, правами доступа и другим metadata, тогда как большие объёмы пользовательских данных проходят непосредственно через storage layer.

CephFS подходит для shared filesystem, домашних каталогов, scratch space HPC и распределённых рабочих процессов, где приложения ожидают привычную POSIX-модель файловой системы.

Сущности и архитектура

Внутреннюю архитектуру Ceph проще всего понять, если двигаться от пользовательского запроса к физическому хранению данных. Клиент получает информацию о кластере, определяет, где находится нужная PG, а затем обращается непосредственно к соответствующим OSD. В этом процессе участвуют Monitor, OSD Map, Placement Group, Primary OSD, Replica OSD и другие сущности.

Ключевая особенность заключается в отсутствии центрального storage-controller, через который должен проходить каждый запрос. Monitors поддерживают актуальную карту кластера, а клиенты и OSD используют CRUSH для вычисления расположения объектов. Это позволяет распределять работу по самому кластеру.

Главный принцип архитектуры Ceph: центральные компоненты управляют состоянием и картой кластера, но не становятся обязательным маршрутизатором каждого пользовательского I/O.

Object

Object — базовая единица данных RADOS. Пользовательский файл, блок RBD или объект RGW в конечном счёте представляется через набор внутренних объектов, которые хранятся в RADOS.

Важно не путать этот термин с объектом Object Storage. RADOS Object — это внутренняя единица хранения, с которой работают OSD и механизмы распределения данных. Размер объекта не является универсальной константой для всех сценариев Ceph: он зависит от типа и настроек соответствующего storage-интерфейса и pool.

В частности, для RBD часто используется объектный размер 4 MiB, однако утверждать, что «любой объект Ceph всегда равен 4 MiB», неправильно. Архитектору необходимо рассматривать object size как параметр конкретной конфигурации.

Placement Group

Placement Group (PG) — логическая группа, в которую попадает множество RADOS objects. PG нужна для того, чтобы не управлять размещением каждого объекта как отдельной сущности на уровне всей карты кластера.

Упрощённо путь данных можно представить так:

Object
   │
   ▼
Hash / Pool
   │
   ▼
Placement Group
   │
   ▼
CRUSH
   │
   ├── Primary OSD
   ├── Replica OSD
   └── Replica OSD

Каждый объект относится к одной PG, а конкретная PG размещается на наборе OSD в соответствии с pool и CRUSH rule. Именно PG являются важнейшей единицей peering, recovery и многих операций балансировки.

Количество PG имеет непосредственное значение для архитектуры кластера. Слишком малое количество может ограничить равномерность распределения, а чрезмерное количество увеличивает служебные затраты. В современных версиях Ceph для pools используется PG autoscaler, который помогает выбирать и изменять число PG.

OSD — Object Storage Daemon

OSD (Object Storage Daemon) — основной исполнительный элемент хранения Ceph. Именно OSD отвечает за хранение объектов, обслуживание клиентских операций, репликацию, recovery, peering и взаимодействие с другими OSD.

Обычно OSD связан с отдельным устройством хранения, хотя конкретная архитектура может использовать различные схемы размещения. На одном сервере может работать несколько OSD, поэтому физический сервер и OSD — это не одно и то же.

При отказе диска или узла OSD сообщает о своём состоянии, после чего кластер может изменить acting set соответствующих PG и начать восстановление данных. OSD также выполняют scrub, позволяющий обнаруживать определённые проблемы с целостностью объектов и реплик.

Primary OSD

Primary OSD — OSD, выбранная в acting set конкретной PG в качестве primary. Именно она принимает клиентский I/O для объектов этой PG и координирует операции с другими OSD из acting set.

Поэтому клиенту не требуется самостоятельно обращаться к каждой реплике. Клиент определяет расположение PG, получает набор OSD и выполняет операцию через primary, которая координирует дальнейшую работу внутри storage layer.

Важно не упрощать этот механизм до формулировки «Primary асинхронно копирует данные на Replica». Реальная модель зависит от операции и настроек pool: подтверждение записи связано с состоянием реплик и параметром min_size. Ceph обеспечивает согласованность реплицируемых данных и не сводит запись к простой фоновой копии после подтверждения клиенту.

Replica OSD

Replica OSD — OSD, входящая в acting set PG, но не являющаяся её primary. В replicated pool такие OSD хранят дополнительные копии объектов и участвуют в обеспечении отказоустойчивости.

Если pool настроен, например, с size = 3, логически хранится три экземпляра каждого объекта. Это не означает, что три копии обязательно находятся на одном физическом сервере: CRUSH rules могут распределять их по разным host, rack или другим failure domains.

Именно поэтому выбор CRUSH rule является не просто технической настройкой, а частью политики отказоустойчивости. Можно потребовать распределения реплик между разными серверами, стойками или другими уровнями топологии.

Фактор репликации

Replication factor показывает, сколько копий RADOS object должно храниться в replicated pool. Например, значение size = 3 означает три экземпляра объекта.

Если в пуле используется size=3, необработанная ёмкость, необходимая для хранения данных, будет существенно выше пользовательского объёма. Для 1 PB логических данных простая трёхкратная репликация требует примерно 3 PB только на копии данных, ещё до учёта служебных накладных расходов и других резервов.

Альтернативой является erasure coding. Например, профиль с k=10 и m=4 разбивает данные на 10 data chunks и создаёт четыре coding chunks. Такой подход может повысить эффективную ёмкость, но предъявляет другие требования к производительности, отказоустойчивости и восстановлению.

OSD Map

OSD Map — часть общей карты состояния кластера, содержащая сведения об OSD и их состоянии. Cluster Map в Ceph является составной структурой, включающей несколько карт, в том числе OSD map, PG map, CRUSH map и MDS map.

Изменение состояния OSD приводит к изменению карты. Например, если OSD выходит из строя, кластер получает новую информацию о topology и может начать перераспределение соответствующих PG.

Важно понимать, что OSD Map не является таблицей, в которой для каждого объекта записан физический диск. Конкретное расположение объекта вычисляется с помощью комбинации pool, PG и CRUSH. Именно это позволяет Ceph масштабировать систему без необходимости поддерживать гигантский центральный каталог всех объектов.

Monitor

Monitor (MON) поддерживает эталонное состояние кластера и предоставляет клиентам актуальную Cluster Map. Monitor знает о состоянии OSD, PG, MDS и других основных компонентах.

Клиент первоначально обращается к Monitor, получает актуальную информацию о кластере и затем может самостоятельно вычислять расположение объектов. Monitors также участвуют в аутентификации и поддержании согласованного состояния. Несколько Monitor обеспечивают отказоустойчивость самого control plane.

Таким образом, Monitor — это не storage proxy. Его задача — знать и распространять состояние кластера, а не передавать через себя весь пользовательский поток данных.

Metadata Server

Metadata Server (MDS) нужен только для CephFS. Он обслуживает metadata файловой системы: каталоги, имена, права, состояние файлов и другие операции namespace.

Современная архитектура CephFS допускает кластер MDS, который может масштабироваться для более высоких metadata-нагрузок. Поэтому формулировка «в кластере всегда только одна активная MDS» слишком категорична. В зависимости от конфигурации CephFS могут использоваться несколько active MDS, а standby MDS обеспечивают отказоустойчивость.

Принципиально важно другое: MDS не обслуживает весь поток данных файлов. Metadata хранится отдельно от file data, а клиенты получают прямой доступ к RADOS для чтения и записи содержимого файлов.

RADOS Gateway

RADOS Gateway (RGW) — HTTP-сервис, предоставляющий приложениям объектный интерфейс поверх RADOS. Он поддерживает S3-compatible API и Swift-compatible API.

RGW является отдельным сервисным уровнем. Это важное отличие от CephFS и RBD: клиент S3 не получает прямой RADOS API, а работает через HTTP endpoint RGW.

В крупных инсталляциях количество RGW может масштабироваться отдельно от OSD, поскольку требования к HTTP/API-нагрузке и требованиям к физическому storage могут сильно различаться.

Сценарии

Практическая ценность Ceph определяется не количеством его компонентов, а тем, какие инфраструктурные задачи он позволяет решить. Один и тот же кластер можно использовать для разных типов нагрузки, однако для каждого сценария необходимо выбирать правильный интерфейс — RBD, CephFS или RGW — и правильно настраивать pool.

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

Распределение данных в кластере

Когда клиент записывает данные, Ceph не выбирает OSD случайным образом. Объект сначала относится к определённой PG, а затем CRUSH вычисляет набор OSD, на которых эта PG должна находиться.

CRUSH использует topology кластера и правила размещения. Поэтому администратор может задать политику, при которой реплики не будут сосредоточены на одном физическом сервере или в одной failure domain.

Например:

Pool: vm-images
Replication: 3

              CRUSH
                │
        ┌───────┼───────┐
        ▼       ▼       ▼
      host01  host02  host03
        │       │       │
      OSD.01  OSD.17  OSD.29
        │       │       │
        └────── Object ──┘

При таком подходе отказ одного сервера не означает автоматическую потерю всех экземпляров данных. Однако реальная устойчивость определяется конкретной CRUSH policy, failure domains, размером pool и состоянием кластера.

Георепликация

Для территориально распределённых инфраструктур Ceph поддерживает механизмы, позволяющие организовать репликацию между сайтами. В объектном сценарии RGW существует multi-site архитектура, позволяющая строить распределённые object storage deployment.

Это принципиально отличается от обычной внутрикластерной репликации. Репликация между OSD решает задачу отказоустойчивости внутри storage cluster, тогда как георепликация решает задачу катастрофоустойчивости между площадками.

При проектировании DR необходимо отдельно определить:

• RPO — сколько данных допустимо потерять при аварии;
• RTO — за какое время сервис должен восстановиться;
• какие данные должны реплицироваться синхронно или асинхронно;
• какая пропускная способность доступна между ЦОД;
• как будет выполняться переключение приложений;
• как будет проверяться целостность резервной площадки.

Нельзя считать георепликацию простой «копией кластера». Между площадками появляются задержка, пропускная способность WAN, конфликты, порядок операций и отдельные требования к disaster recovery.

Восстановление данных

Одно из важнейших преимуществ Ceph — возможность автоматически восстанавливать состояние данных после отказа OSD. Когда состав кластера изменяется, CRUSH определяет новое размещение PG, после чего Ceph начинает процессы recovery и backfill.

Если, например, один OSD выходит из строя, кластер не просто оставляет данные в деградированном состоянии навсегда. Соответствующие PG переходят через состояния peering и recovery, а недостающие копии восстанавливаются на доступных OSD в соответствии с политикой размещения.

Однако восстановление — дорогая операция. Она потребляет диск, CPU и сеть и конкурирует с пользовательским I/O. Поэтому скорость recovery необходимо рассматривать не только как характеристику надёжности, но и как параметр производительности кластера.

Для ИТ-руководителя здесь появляется важный компромисс: слишком агрессивное recovery позволяет быстрее вернуть избыточность, но способно сильнее влиять на production-нагрузку; слишком медленное восстановление дольше оставляет данные в degraded state.

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

Ребалансировка возникает, когда изменяется состав кластера или правила размещения. Например, в Ceph добавили новые OSD. Изменение Cluster Map влияет на расчёт CRUSH, вследствие чего часть PG получает новое предпочтительное размещение.

Ceph не переносит все данные сразу. CRUSH обладает свойством относительной стабильности: изменение topology вызывает перемещение только той части PG, для которой действительно изменилось вычисленное размещение.

Это позволяет постепенно расширять кластер. Но увеличение ёмкости не означает мгновенного получения всей новой свободной ёмкости: после добавления OSD требуется время на rebalancing и recovery.

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

Сравнение с GlusterFS, GPFS, iSCSI и NFS

Ceph часто сравнивают с GlusterFS, IBM GPFS/Storage Scale, iSCSI и NFS, однако эти технологии находятся на разных уровнях архитектуры. NFS и GlusterFS в первую очередь относятся к файловому доступу, iSCSI предоставляет транспорт для SCSI block storage, а GPFS/IBM Storage Scale является высокопроизводительной кластерной файловой системой. Ceph же объединяет object, block и file interfaces поверх единого RADOS backend.

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

Технология	Основная модель	Типичный интерфейс	Сильная сторона	Особенность
Ceph	Object + Block + File	S3, RBD, CephFS	Унифицированный scale-out storage	Сложная распределённая архитектура
GlusterFS	Distributed File System	File / POSIX	Простая концепция распределённой файловой системы	Архитектура построена вокруг bricks и volume
GPFS / IBM Storage Scale	Clustered / parallel file system	POSIX	Высокопроизводительная работа с файлами	Коммерческая enterprise-платформа
NFS	Network File System	File / POSIX-like	Простота и широкая совместимость	Зависит от архитектуры NFS-сервера и backend storage
iSCSI	Block transport	SCSI over TCP	Предоставление блочного устройства по IP	Сам по себе не является распределённым storage-кластером

Ceph и GlusterFS

GlusterFS — распределённая файловая система, которая объединяет storage-серверы в единое пространство. Её архитектура основана на bricks, volumes и наборе translators; различные типы volume позволяют выбирать распределение, репликацию или комбинацию этих подходов.

Ceph имеет более широкий набор интерфейсов. Если GlusterFS прежде всего отвечает на вопрос «как предоставить распределённую файловую систему», Ceph отвечает на более широкий вопрос: как построить общий storage backend, поверх которого можно предоставить file, block и object storage.

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

Ceph и GPFS

GPFS, современное название продукта IBM — Storage Scale, ориентирован на высокопроизводительную кластерную файловую систему. IBM описывает Storage Scale как высокопроизводительную shared storage-платформу для больших объёмов данных, включая HPC, Big Data, analytics и другие интенсивные workloads.

Здесь принципиально различается модель. GPFS прежде всего предоставляет кластерную файловую систему, тогда как Ceph строит object store и поверх него реализует несколько storage interfaces.

Поэтому для HPC или специализированной файловой нагрузки вопрос обычно должен звучать не «что быстрее вообще», а «какая модель доступа соответствует приложению». Если приложение интенсивно работает с файлами и требует специфических возможностей параллельной файловой системы, Storage Scale может рассматриваться отдельно от Ceph. Если же требуется единая storage-платформа с object/block/file, Ceph имеет другую архитектурную ценность.

Ceph и NFS

NFS — сетевой файловый протокол, предоставляющий клиенту доступ к файловой иерархии сервера. NFSv4 поддерживает традиционный файловый доступ, locking, client caching, security mechanisms и другие функции распределённой файловой системы.

NFS обычно значительно проще для прикладных систем: приложение видит каталог и работает с обычными файлами. CephFS тоже предоставляет POSIX-интерфейс, но внутри строится на распределённом RADOS backend и MDS.

Поэтому сравнение Ceph с NFS — это фактически сравнение распределённой storage-платформы с файловым сетевым протоколом. NFS может использоваться поверх совершенно разных storage backend и сам по себе не определяет, как данные физически распределены по дискам.

Ceph и iSCSI

iSCSI — это протокол транспортировки SCSI поверх TCP/IP. Он позволяет initiator обращаться к SCSI target по IP-сети. Таким образом, iSCSI решает задачу доставки блочных SCSI-команд через сеть, а не задачу построения распределённого storage-кластера.

Ceph RBD и iSCSI могут давать приложению блочный доступ, но находятся на разных архитектурных уровнях. RBD — это блочный интерфейс поверх распределённого RADOS, а iSCSI — сетевой протокол доступа к SCSI target.

Именно поэтому фраза «Ceph — это аналог iSCSI» некорректна. Более точная формулировка: RBD может решать задачу, для которой в другой архитектуре используется SAN/iSCSI, но реализует её совершенно другим способом.

Сравнение архитектур

Критерий	Ceph	GlusterFS	GPFS / Storage Scale	NFS	iSCSI
Object storage	Да, RGW	Не основная модель	Поддерживается в составе современной платформы	Нет	Нет
Block storage	Да, RBD	Не основная модель	Есть специализированные механизмы	Нет	Да
File storage	Да, CephFS	Да	Да	Да	Нет
Горизонтальное масштабирование	Да	Да	Да	Зависит от backend	Зависит от target/backend
Распределённая репликация	Да	Да	Да	Не является функцией протокола	Не является функцией протокола
CRUSH-подобное размещение	Да	Нет	Другая модель	Нет	Нет
Основной уровень	Storage platform	Distributed file system	Clustered file system	File protocol	Block transport protocol

Что в итоге

Ceph — это не просто «сетевой диск на несколько петабайт» и не только альтернатива SAN или NAS. Это распределённая storage-платформа, в центре которой находится RADOS, а пользовательские интерфейсы представлены RBD, RGW и CephFS.

Ключевое архитектурное преимущество Ceph состоит в том, что система масштабирует не только ёмкость, но и сам storage backend. Данные распределяются по OSD, логически группируются в PG, а CRUSH определяет их размещение с учётом topology и правил отказоустойчивости. Monitor поддерживает состояние кластера, а клиенты и OSD используют полученную информацию для прямого обращения к нужным компонентам.

Ceph — это прежде всего архитектура распределённого хранения, а не конкретный протокол доступа. TCP/IP, S3, RBD и POSIX — лишь разные уровни и интерфейсы этой архитектуры.

Для CIO выбор Ceph следует рассматривать через требования к инфраструктуре:

• нужна ли единая storage-платформа для object, block и file;
• необходимо ли масштабирование до петабайтного уровня;
• какие требования предъявляются к RPO и RTO;
• какая сеть доступна между storage-узлами;
• какой тип дисков используется;
• какая доля нагрузки приходится на random и sequential I/O;
• нужна ли репликация или erasure coding;
• требуется ли георепликация между ЦОД;
• какие системы будут использовать storage — VM, Kubernetes, Data Lake, HPC, backup или файловые приложения.

Отдельное внимание необходимо уделить сети. Ceph активно использует сеть не только для клиентского I/O, но и для репликации, heartbeat, recovery и backfill. Официальная документация прямо подчёркивает, что сетевое проектирование критично для производительности и устойчивости; для нагруженных кластеров рекомендуется рассматривать высокоскоростные сетевые соединения, а для крупных клиентских нагрузок — отдельную cluster network.

Именно поэтому при проектировании Ceph нельзя оценивать только объём дисков. Кластер на 10 PB и кластер на 10 PB могут иметь принципиально разную производительность и стоимость эксплуатации в зависимости от количества OSD, типа накопителей, сети, replication factor, CRUSH topology, PG и характера нагрузки.

В результате Ceph наиболее интересен для организаций, которым нужна масштабируемая программно-определяемая инфраструктура хранения без привязки к одному монолитному storage-массиву. Но цена такой гибкости — необходимость профессионально проектировать сеть, topology, отказоустойчивость, storage pools и процессы эксплуатации. Для петабайтного кластера это уже не вспомогательная инфраструктура, а самостоятельная технологическая платформа, которую необходимо проектировать и сопровождать как критическую часть корпоративной ИТ-архитектуры.