Привет, Хабр! Меня зовут Павел Кишеня, я тимлид группы системных администраторов IT-инфраструктур в группе Рунити. К нам часто приходят заказчики с довольно высоконагруженными проектами, хранящими большой объем информации — всё это потребляет много места. 

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

Навигация по тексту:

• Когда данных становится всё больше и больше — где их хранить?

• Актуальные требования к современным системам хранения данных и какие у них есть слабые места

• Почему классические СХД больше не функционируют «как раньше» — плюсы и минусы вендорских и open-source решений

• «Дорого» — это сколько, или что делать, когда нужно сэкономить 

• Разбор кейса: добавляем в CEPH смешанный пул (SSD + HDD)

• Особенности переноса кластера с SSD на Гибрид (SSD+HDD): практический пример

• Ключевые выводы

Когда данных становится всё больше и больше — где их хранить?

Современный бизнес ежедневно генерирует более 400 млн терабайт данных: от медиафайлов и сложных сред разработки до пользовательских лайков и комментариев. Эти колоссальные объемы требуют надежного хранения, поэтому компании предпочитают переходить в облако. Здесь «живет» всё: данные, сервисы, системы хранения данных, в том числе enterprise-уровня.

Если раньше для хранения информации достаточно было одного сервера, то сегодня компании сталкиваются с необходимостью управлять сотнями и тысячами терабайт данных, обеспечивая при этом высокую доступность, скорость обработки и производительность системы. Соответственно, важно получить разумное хранилище. И здесь встает вопрос о том, как его выбрать? Сейчас попробуем разобраться.

Актуальные требования к современным системам хранения данных и какие у них есть слабые места

На первый взгляд кажется, что задача хранения данных довольно проста: купил сервер, поставил диски и пользуешься ими. На деле бывает не всё так просто. Стандартный сервер, как правило, может вместить 4 жестких диска — это позволяет хранить около 10-25 терабайт данных. Если количество информации растет до сотен терабайт, то приходится задумываться о мощном дисковом контроллере и построении RAID-массивов. Но здесь есть свое «но» и можно столкнуться с рядом проблем:

1. Производительность. В «недорогих» СХД-хранилищах установлены большие шпиндельные диски (HDD) — они выгодные, но довольно медленные. Их скорость чтения/записи редко превышает 150-180 МБ/с. Когда вы собираете RAID-массив из десятков таких дисков, получаете большой объем, но при этом хранилище может оказаться слишком медленным для активной работы. Речь не просто о мегабайтах в секунду, а об операциях ввода-вывода в секунду (IOPS). Для HDD — это всего ~75-100 IOPS. На 100 ТБ данных получается около 600 IOPS. Когда начинаем делить необходимый объем на количество IOPS, получаем интересную метрику — IOPS/Гб. Сейчас в облачных сервисах этот показатель имеет важное значение — хранение измеряется уже не только в объемах, но и в IOPS/Гб.

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

3.  Доступность. Ахиллесова пята больших распределенных систем — latency. Современные приложения требуют мгновенного отклика. Можно иметь сколько угодно IOPS, но, если задержка будет большой, то смысла в них нет. Пользователь не будет ждать, пока его запрос постоит в очереди, а потом обработается. В качественных системах, как правило, производительность измеряется при задержке не более 10 миллисекунд. То есть замеряем задержку и при времени latency — производительность. Только тогда в IOPS есть какой-то смысл — кстати, вот в этой статье автор приводит подробное объяснение, как измерить производительность.

Таким образом, производительность, надежность и доступность смещают современный подход к хранению данных в сторону кластерных систем.

Почему классические СХД больше не функционируют «как раньше» — плюсы и минусы вендорских и open-source решений

Когда компания достигает определенных масштабов, где один или несколько серверов уже не справляются с нагрузкой, чаще всего возникает вопрос о выборе между следующими видами хранилищ:

1. Вендорские СХД — готовые решения «из коробки» от крупных производителей. 

2. Open-source решения (например, Ceph) — кластерные хранилища.

Сравним особенности каждого из вариантов, а также их преимущества и недостатки. Начнем с плюсов вендорских СХД:

• простота внедрения. Вы покупаете готовое решение, в котором специалисты поставщика уже всё настроили и протестировали — оно готово к работе;

• удобство управления. У вендорских СХД обычно красивый и интуитивно понятный веб-интерфейс, а также настроенные RAID-массивы; 

• легкость интеграции. Часто такие СХД поддерживают множество протоколов, выступая как объектное или блочное хранилище.

Теперь о минусах:

• высокая стоимость — за удобство и поддержку, конечно, приходится платить. Кроме того, сегодня на рынке можно столкнуться со сложностями в обслуживании и технической поддержке подобных систем;

• ограниченная гибкость. Зачастую такие хранилища модульные, и пользователи привязаны к выбранным моделям оборудования, которые предлагает вендор;

• сложность масштабирования. Расширение инфраструктуры происходит ступенчато. Например, когда лимит дисковых полок будет исчерпан, придется покупать новую. А что дальше? Рост упирается в приобретение нового более крупного и дорогостоящего «головного устройства»;

• слабая отказоустойчивость. Аппаратная система, как правило, сконцентрирована в одном месте и ограничивается техническими возможностями оборудования, например, длиной кабеля. Также выход из строя одного элемента влечет за собой риск простоя другого оборудования. 

А как обстоят дела с open-source решениями, например, по типу Ceph? Начнем снова с плюсов: 

• горизонтальная масштабируемость. В open-source хранилищах можно добавлять новые серверы и диски практически неограниченно. Кроме того, линейно возможно наращивая как объем, так и производительность;

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

• гибкая производительность. Можно комбинировать типы дисков в рамках одного кластера и создавать разные пулы данных для различных требований по скорости и объему;

• развитое комьюнити. Огромное количество документации, best practices и активное комьюнити, готовое помочь.

Но есть и минусы:

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

• отсутствие «коробки». Нет «красивого» веб-интерфейса и всё необходимо настраивать вручную;

• сложность эксплуатации. Управление большой распределенной системой требует постоянного мониторинга, отладки и быстрого реагирования на инциденты. Отсюда — потребность в сильной команде инженеров. А делать это приходится либо силами самой компании, либо обращаться к аутсорсу. Плюс у облачных провайдеров есть всё необходимое оборудование, с которым можно быстро масштабировать мощности.

«Дорого» — это сколько, или что делать, когда нужно сэкономить 

В то же время возможны и кейсы, когда, вложившись в мощное хранилище, бизнес не растет дальше. И те параметры производительности, которые выдает кластер, уже не нужны. В таком случае компания вынуждена экономить на инфраструктуре — и это приводит к деградации. Покажу на примере. Допустим, у пользователя есть 100 ТБ данных, которые необходимо хранить экономнее. Сделать это с СХД сложно — ведь есть оборудование, которое нужно обслуживать или докупать новые устройства, если мощности предыдущих не хватает. Да, его можно заменить на другое, более бюджетное, но это снова приводит к покупке и дальнейшей настройке новых конфигураций.

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

1. Только SSD (NVMe).

2. SSD (NVMe) + HDD. 

3. Только HDD.

В каждом случае решение принимается индивидуально — в зависимости от запроса. Например, при построении гибрида используется NVMe + HDD, при SSD-only — возможно использование как NVMe, так и SSD дисков.

Однако, как это часто бывает, панацей становится средний вариант — цена, производительность и объем сохраняются.

Разбор кейса: добавляем в CEPH смешанный пул (SSD + HDD)  

Далее посмотрим, как начать процесс экономии на практике. Предположим следующую проблему: не всем компаниям требуется быстрый пул SSD, некоторым необходимо просто большое хранилище для бэкапов или редко изменяемой информации. В таком случае, чтобы поддержать уровень скорости, создаются смешанные пулы. Рассмотрим пример с добавлением 5 серверов по 7.7 ТБ NVMe + 4x20TБ HDD.

1. Подготовка серверов и предварительная настройка для Rocky Linux 9.

— Для начала разобьем NVMe-диски на равные LVM-разделы. Количество разделов равно количеству HDD-дисков:

• vgcreate vg-nvme0 /dev/nvme0n1 и vgcreate vg-nvme1 /dev/nvme1n1.

  При возникновении ошибки, что не может создать PV-девайс, комментируем строку в /etc/lvm/lvm.conf , выставляем значение как "0";

• создаем LVM, на примере одного диска lvcreate -l 50%FREE -n osd_db1 /dev/vg-nvme0 и lvcreate -l 100%FREE -n osd_db2 /dev/vg-nvme0. Аналогично на втором диске — должно получиться 4 LVM;

• osd_db1 vg-nvme0 -wi-ao---- 3.49t

  osd_db2 vg-nvme0 -wi-ao---- 3.49t

  osd_db3 vg-nvme1 -wi-ao---- 3.49t

  osd_db4 vg-nvme1 -wi-ao---- 3.49t

— Ставим пакеты, необходимые для работы:

dnf install podman lvm2 chrony -y

— Проверяем наличие Python:

# python -V

Python 3.9.18

— Далее настраиваем сети. Особое внимание обращаем на то, чтобы адреса не пересеклись — они должны быть уникальными.

На этом настройка ноды закончена, повторяем ее на всех необходимых нодах и можно переходить к добавлению их в кластер.

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

– Чтобы нода добавилась в кластер, нужно внести публичный ключ Ceph для авторизации от пользователя root. Сам ключ берем из cat /etc/ceph/ceph.pub и добавляем его в /root/.ssh/authorized_keys.

— Добавление ноды делаем по аналогии:

• ceph orch host add 10.92.15.61 osd, где osd11.example.ru — fqdn нового сервера, а 10.92.15.61 — IP-адрес публичной сети;

• в процессе добавления HEALTH_STATUS меняться не должен, так как в сам кластер OSD не попадают;

• просмотреть ноды можно так ceph orch host ls.

— После того, как все ноды успешно введены в кластер, можно добавить OSD:

ceph orch daemon add osd osd11.example.ru:data_devices=/dev/sda,db_devices=/dev/vg-nvme0/osd_db1, osds_per_device=1

Далее по аналогии каждый сервер. Обращаем внимание на имена дисков и LVM, для каждого диска — свой LVM.

3. Создание правил репликации

— ceph osd crush rule create-replicated replicated_ssd default host ssd В нашем Ceph хосты до этого имели class ssd.

— ceph osd pool set default.rgw.buckets.data crush_rule replicated_ssd

Правило, что по умолчанию всё сохраняем на SSD — быстрый class, делается для всех пулов:

• все пулы с метаданными уносим на ssd — только метаданные;

• ceph osd pool set default.rgw.log crush_rule replicated_ssd;

• ceph osd pool set default.rgw.control crush_rule replicated_ssd;

• ceph osd pool set default.rgw.meta crush_rule replicated_ssd;

• ceph osd pool set default.rgw.buckets.index crush_rule replicated_ssd;

• ceph osd pool set default.rgw.buckets.non-ec crush_rule replicated_ssd;

• ceph osd pool set .rgw.root crush_rule replicated_ssd;

• ceph osd pool set .mgr crush_rule replicated_ssd.

— Добавим профиль:

ceph osd erasure-code-profile set
"ec-3-2-host"
k="3"
m="2"
w="8"
technique="reed_sol_van"
packetsize="2048"
crush-failure-domain="host"
crush-root="default"
plugin="jerasure"
directory="/usr/lib64/ceph/erasure-code"
jerasure-per-chunk-alignment="false" 

Создаем отдельный тип пула — с EC (Erasure Coding), он отличается принципом работы от replicated пулов;

• ceph osd pool create --bulk "default.rgw.buckets.data-ec-3-2-host" "32" erasure "ec-3-2-host" "ec-3-2-host;

• radosgw-admin zone placement add --rgw-zone default --placement-id default-placement --storage-class "STANDARD_IA" --data-pool "default.rgw.buckets.data-ec-3-2-host".

  Создали STORAGE_CLASS — он понадобится для сохранения файлов в «медленный storage»;

• ceph osd pool application enable "default.rgw.buckets.data-ec-3-2-host" rgw.

Итак, базовая настройка завершена. Для сохранения на созданный медленный пул требуется добавить --storage-class "STANDARD_IA" при сохранении данных и работе с ними.

Особенности переноса кластера с SSD на Гибрид (SSD+HDD): практический пример

А теперь рассмотрим другой пример. Представим, что есть кластер из двух Placement Groups (PG):

[ceph: root@misc1 /]# ceph osd crush rule ls
replicated_rule
replicated_ssd
ec-3-2-host-hdd
[ceph: root@misc1 /]#

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

ceph osd crush rule create-replicated replicated-hdd-host default host hdd
hdd
[ceph: root@misc1 /]# ceph osd tree
ID CLASS WEIGHT TYPE NAME STATUS REWEIGHT PRI-AFF
CLASS - hdd

Смотрим, какие пулы есть в системе:

ceph osd pool ls
.mgr
.rgw.root
default.rgw.log
default.rgw.control
default.rgw.meta
default.rgw.buckets.index
default.rgw.buckets.non-ec
default.rgw.buckets.data

Из них данные клиента находятся в default.rgw.buckets.data, остальные пулы содержат лишь индексы, и их можно перенести «на горячую»:

ceph osd pool create default.rgw.buckets.data-hdd 512 erasure ec-3-2-host-hdd ec-3-2-host-hdd

Где 512 — количество PG, Erasure-профиль — erasure-code-profile - ec-3-2-host-hdd, CRUSH-правило — ec-3-2-host-hdd.

ceph osd pool application enable default.rgw.buckets.data-hdd rgw

Разрешаем на нем работать rgw.

После этого все служебные пулы переедут в гибридную часть — далее требуется настроить autoscale равным warn, чтобы инструмент ничего не чистил, и доступность не страдала в рабочее время:

ceph osd pool set "pool_name" pg_autoscale_mode warn

После того как пул создан, можно начинать работу по копированию.

Важно — при копирование RGW должен быть остановлен:

ceph orch rm rgw.default

Далее запускаем самое копирование.

Важно — запускать нужно в скрине, так как процесс копирования не является фоновым:

rados cppool default.rgw.buckets.data default.rgw.buckets.data-hdd

Где, default.rgw.buckets.data — исходный пул, default.rgw.buckets.data-hdd — конечный пул.

Процесс копирования может занять достаточно длительное время — по завершению переименовываем:

ceph osd pool rename default.rgw.buckets.data default.rgw.buckets.data-ssd — переименовываем в default.rgw.buckets.data-ssd. ceph osd pool rename default.rgw.buckets.data-hdd default.rgw.buckets.data — переименовываем в default.rgw.buckets.data-hdd в default.rgw.buckets.data.

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

ceph orch apply rgw default label:rgw --networks 10.92.14.0/23 --port 8000

Остается проверить, как всё работает. Для этого необходимо убедиться в возможности создать бакет и положить в него объект. Готово!

Ключевые выводы

Выбор архитектуры системы хранения — это поиск баланса между стоимостью, производительностью и надежностью. Высоконагруженные проекты и постоянно растущие объемы информации требуют особого хранения. В зависимости от масштабов, запросов и возможностей компании решают, какое решение больше подходит — вендорские СХД или open-source решения. В первом случае, вы получаете готовое «коробочное» решение с понятным интерфейсом, помощью с внедрением — но за это приходится платить. Во втором — гибкую и масштабируемую под ваши запросы инфраструктуру, но требующую внимания дополнительных специалистов. Для себя мы в Рунити выбрали Ceph за его универсальность. А какой подход к хранению ближе вам?