Введение в кластерные системы хранения и поиска данных
Кластерная система хранения и поиска данных объединяет несколько серверов в единый пул ресурсов. Одиночный сервер упирается в лимиты дисковой подсистемы, процессора и пропускной способности сети. При выходе такого сервера из строя данные становятся недоступными, а восстановление занимает часы или дни. Кластер решает обе проблемы: распределяет нагрузку между узлами и сохраняет доступность при отказе части оборудования.
Практическая ценность для DevOps-инженера и системного администратора сводится к трем задачам: горизонтальное масштабирование, отказоустойчивость и высокая доступность. Горизонтальное масштабирование означает добавление новых узлов вместо замены существующих на более мощные. Отказоустойчивость обеспечивается репликацией данных на несколько узлов. Высокая доступность достигается тем, что клиент продолжает работать с кластером даже при деградации отдельных компонентов.
В этой статье разобраны две распределенные системы хранения, Ceph и GlusterFS, и поисковый кластер на Elasticsearch. Для каждой технологии даны пошаговые примеры развертывания, настройки и проверки отказоустойчивости. Материал ориентирован на production-среды, где требования к надежности и производительности критичны.
Если вы уже проектируете инфраструктуру уровня enterprise, полезно изучить архитектуры высокой доступности и отказоустойчивости перед выбором конкретной системы хранения.
Ключевые архитектурные решения в распределенных системах
Любая кластерная система строится на трех базовых механизмах: шардирование, репликация и горизонтальное масштабирование. Их комбинация определяет производительность, надежность и сложность эксплуатации. Выбор конкретных параметров влияет на компромисс между консистентностью, доступностью и устойчивостью к разделению, описанный в CAP-теореме.
Шардирование данных: принципы и реализация
Шардирование разделяет набор данных на независимые части, шарды, которые распределяются по узлам кластера. Каждый шард отвечает за свой диапазон или подмножество данных. Это позволяет распараллелить операции чтения и записи: нагрузка распределяется между узлами вместо концентрации на одном сервере.
Выбор ключа шардирования критичен. Стратегия по диапазону хранит последовательные значения в одном шарде. Это удобно для диапазонных запросов, но создает горячие точки при монотонно возрастающих ключах. Стратегия по хэшу равномерно распределяет данные, но усложняет диапазонные выборки. В Elasticsearch каждый индекс разбивается на первичные шарды, количество которых задается при создании индекса. В Ceph данные распределяются по placement groups, которые отображаются на OSD с помощью алгоритма CRUSH.
Неправильный выбор количества шардов приводит к дисбалансу. Слишком мало шардов ограничивает параллелизм. Слишком много увеличивает накладные расходы на координацию. Для Elasticsearch типичное значение от 1 до 5 первичных шардов на индекс при объеме до 50 ГБ на шард.
Репликация данных: обеспечение отказоустойчивости
Репликация создает копии данных на разных узлах. При выходе узла из строя кластер продолжает обслуживать запросы с реплик. Синхронная репликация подтверждает запись только после фиксации на всех копиях, что гарантирует консистентность, но увеличивает задержку. Асинхронная репликация быстрее, но допускает потерю последних записей при сбое.
В Ceph фактор репликации задается параметром size. Значение size=3 означает хранение трех копий каждого объекта на разных OSD. При отказе одного OSD данные остаются доступными с двух оставшихся копий. В GlusterFS реплицированный том с параметром replica 3 хранит три копии каждого файла на разных brick. Увеличение фактора репликации повышает надежность, но кратно увеличивает использование дискового пространства и сетевого трафика на запись.
Стратегии горизонтального масштабирования
Горизонтальное масштабирование увеличивает мощность кластера добавлением узлов. Вертикальное масштабирование заменяет сервер на более мощный, что упирается в физические лимиты и требует простоя. Кластерные системы спроектированы под горизонтальный рост.
В Ceph добавление OSD-узлов расширяет емкость и пропускную способность. Новые OSD автоматически включаются в распределение placement groups, и данные ребалансируются. Добавление MON-узлов повышает отказоустойчивость управляющего уровня. В GlusterFS добавление brick позволяет расширить том, а при использовании распределенно-реплицированных томов одновременно увеличить емкость и сохранить избыточность.
Планирование емкости начинается с оценки текущего объема данных, темпа роста и требуемого запаса на репликацию. Для кластера Ceph с фактором репликации 3 полезная емкость составляет одну треть от суммарного объема OSD. Закладывайте запас 30% на ребалансировку и предотвращение переполнения.
Развертывание кластера Ceph для хранения данных
Ceph предоставляет объектное, блочное и файловое хранилище в одной платформе. Для production-среды минимальная конфигурация включает три узла с мониторами и минимум три OSD-узла. Это обеспечивает кворум и распределение реплик по разным серверам.
Подготовка окружения и установка Ceph
Выберите дистрибутив с длительной поддержкой: Ubuntu 22.04 LTS или CentOS Stream 9. На каждом узле настройте уникальное имя хоста, статический IP-адрес и SSH-доступ по ключу без пароля. Синхронизируйте время через chrony или systemd-timesyncd.
Установка выполняется через cephadm, который разворачивает компоненты в контейнерах. На первом узле выполните:
curl --silent --remote-name --location https://github.com/ceph/ceph/raw/quincy/src/cephadm/cephadm
chmod +x cephadm
./cephadm add-repo --release quincy
./cephadm install
cephadm bootstrap --mon-ip 192.168.10.11После bootstrap получите команду для добавления узлов. Выполните ее на остальных серверах, затем добавьте их в кластер:
ssh-copy-id -f -i /etc/ceph/ceph.pub root@node2
ceph orch host add node2 192.168.10.12
ceph orch host add node3 192.168.10.13Настройка OSD и пулов хранения
Добавьте диски как OSD на каждом узле. Укажите конкретные устройства, чтобы избежать случайного использования системного диска:
ceph orch apply osd --all-available-devicesСоздайте пул хранения с указанием фактора репликации и количества placement groups. Для пула из 6 OSD с репликацией 3 оптимально 128 PG:
ceph osd pool create data_pool 128 128 replicated
ceph osd pool set data_pool size 3
ceph osd pool set data_pool min_size 2Параметр min_size=2 разрешает запись при доступности двух копий из трех. Проверьте состояние кластера:
ceph -s
ceph osd treeПроверка отказоустойчивости и производительности
Симулируйте отказ узла, остановив все OSD на нем:
ceph orch daemon stop osd.node2Кластер перейдет в состояние HEALTH_WARN, но данные останутся доступными. После возврата узла запустите восстановление и дождитесь HEALTH_OK. Для тестирования производительности используйте rados bench:
rados bench -p data_pool 60 write --no-cleanup
rados bench -p data_pool 60 seqРезультаты записи и последовательного чтения покажут реальную пропускную способность. Сравните их с характеристиками дисков и сети, чтобы выявить узкие места.
Настройка кластера GlusterFS для отказоустойчивого хранения
GlusterFS строит распределенное файловое хранилище из локальных директорий, называемых brick. Архитектура проще Ceph: нет отдельного управляющего слоя, данные распределяются по алгоритму на основе имени файла. Это упрощает развертывание для файловых сценариев.
Установка GlusterFS и создание тома
Установите серверный пакет на всех узлах:
apt install glusterfs-server
systemctl enable --now glusterdСоздайте доверенный пул хранения, добавив узлы с первого сервера:
gluster peer probe node2
gluster peer probe node3
gluster pool listСоздайте реплицированный том с тремя копиями:
mkdir -p /data/glusterfs/brick1
gluster volume create gv0 replica 3 node1:/data/glusterfs/brick1 node2:/data/glusterfs/brick1 node3:/data/glusterfs/brick1
gluster volume start gv0Монтирование тома и проверка отказоустойчивости
На клиентской машине установите клиентский пакет и смонтируйте том:
apt install glusterfs-client
mount -t glusterfs node1:/gv0 /mnt/glusterfsДля постоянного монтирования добавьте запись в /etc/fstab:
node1:/gv0 /mnt/glusterfs glusterfs defaults,_netdev 0 0Проверьте отказоустойчивость: остановите glusterd на одном узле и запишите файл через клиента. Данные останутся доступными, так как две реплики продолжают работать. После восстановления узла запустите самовосстановление:
gluster volume heal gv0Построение поискового кластера на Elasticsearch
Elasticsearch распределяет индексы по шардам и репликам. Каждый шард - это самостоятельный индекс Lucene. Кластер из трех узлов обеспечивает отказоустойчивость при размещении одной реплики на каждом уровне.
Установка и настройка узлов Elasticsearch
Установите Elasticsearch на каждый узел. Настройте JVM heap не более 50% от оперативной памяти, но не более 31 ГБ. В файле elasticsearch.yml задайте уникальные имена:
cluster.name: search-cluster
node.name: es-node-1
network.host: 192.168.10.21
discovery.seed_hosts: ["192.168.10.21", "192.168.10.22", "192.168.10.23"]
cluster.initial_master_nodes: ["es-node-1", "es-node-2", "es-node-3"]Запустите службу и проверьте состояние:
systemctl enable --now elasticsearch
curl -X GET "http://localhost:9200/_cluster/health?pretty"Индексация и поиск данных
Создайте индекс с настройкой количества шардов и реплик:
curl -X PUT "http://localhost:9200/products" -H 'Content-Type: application/json' -d '{
"settings": {
"number_of_shards": 3,
"number_of_replicas": 1
}
}'Индексируйте документ и выполните поиск:
curl -X POST "http://localhost:9200/products/_doc/1" -H 'Content-Type: application/json' -d '{
"name": "Сервер Dell PowerEdge R750",
"category": "серверы",
"price": 450000
}'
curl -X GET "http://localhost:9200/products/_search?q=сервер"Масштабирование и мониторинг Elasticsearch
Добавление узла сводится к установке Elasticsearch с тем же cluster.name и добавлению его IP в discovery.seed_hosts. Кластер автоматически перераспределит шарды. Для равномерного распределения следите, чтобы количество шардов было кратно числу узлов данных.
Мониторинг выполняйте через API и Kibana. Ключевые метрики: состояние кластера, количество неприсвоенных шардов, задержки поиска и индексации, использование heap. Настройте алерты на переход кластера в состояние yellow или red.
Сравнение Ceph и GlusterFS: что выбрать?
Выбор между Ceph и GlusterFS определяется типом хранилища и требованиями к производительности.
| Критерий | Ceph | GlusterFS |
|---|---|---|
| Тип хранилища | Объектное, блочное, файловое | Файловое |
| Архитектура | Управляющий слой MON/MGR, данные в OSD | Распределенный хэш по brick |
| Сложность настройки | Высокая | Средняя |
| Производительность | Высокая для блочного доступа | Высокая для последовательных файловых операций |
| Отказоустойчивость | Репликация на уровне PG | Репликация на уровне тома |
| Интеграция с Kubernetes | RBD, CephFS CSI | Heketi, GlusterFS CSI |
Ceph выбирайте для блочного хранилища виртуальных машин и объектного S3-совместимого доступа. GlusterFS подходит для файлового хранилища с простой архитектурой и умеренными требованиями к производительности. Детальное сравнение и готовые конфигурации для обеих систем есть в руководстве по программно-определяемому хранилищу.
Типичные проблемы и их решения при эксплуатации кластеров
Сетевые проблемы вызывают разделение кластера и потерю кворума. В GlusterFS split-brain возникает, когда два узла одновременно считают себя источником истины для файла. Диагностируйте через gluster volume heal gv0 info split-brain. Решение требует ручного выбора правильной копии и очистки конфликтующих файлов.
В Ceph деградация данных происходит при отказе OSD и невозможности восстановить реплики. Мониторьте ceph health detail и своевременно заменяйте вышедшие из строя диски. Не допускайте заполнения OSD более 85%: это вызывает остановку записи и риск потери данных.
Резервное копирование конфигурации кластера выполняйте отдельно от репликации. Репликация защищает от отказа оборудования, но не от случайного удаления или повреждения данных. Настройте регулярные снапшоты пулов Ceph и экспорт критичных томов GlusterFS.
Для мониторинга кластерной инфраструктуры используйте сравнение решений для Linux и Kubernetes, где разобраны Pacemaker, Keepalived и нативные механизмы оркестрации.
Заключение: выбор архитектуры для вашего проекта
Кластерная система хранения и поиска данных строится на шардировании, репликации и горизонтальном масштабировании. Ceph закрывает потребности в блочном и объектном хранилище с высокой надежностью. GlusterFS проще для файловых сценариев. Elasticsearch решает задачу полнотекстового поиска в высоконагруженных проектах.
Порядок внедрения: определите тип хранилища, рассчитайте емкость с учетом фактора репликации, разверните кластер из трех и более узлов, настройте мониторинг, проведите тесты на отказ. После этого переносите рабочие нагрузки.
Для интеграции с контейнерной средой изучите проектирование production-ready кластеров Kubernetes. Если нужен облачный вариант без собственного оборудования, рассмотрите облачную инфраструктуру Timeweb Cloud с готовыми серверами и хранилищами.