Обзорная статья про установку и настройку кластера ceph для построения отказоустойчивого файлового хранилища. Написал просто, своим языком с примерами.
https://serveradmin.ru/ustanovka-i-nastrojka-ceph/
#статья #ceph #devops
https://serveradmin.ru/ustanovka-i-nastrojka-ceph/
#статья #ceph #devops
Server Admin
Установка, настройка и эксплуатация Ceph | serveradmin.ru
Подробное описание установки, настройки и эксплуатации ceph своими словами для новичков и тех, кто только знакомится с ceph.
Понадобилось на днях установить Ceph. У меня есть статья по этому поводу, но как оказалось, она очень сильно устарела. Я потратил целый день на то, чтобы развернуть свежую стабильную версию Ceph. Решил заодно и актуализировать статью.
💡Для тех, кто не знаком с Ceph, поясню, что это программная объектная отказоустойчивая сеть хранения данных. Если по-простому, то это кластер для хранения данных. Причём он может отдавать данные как обычные файлы через свою распределённую файловую систему cephfs, так и в виде блочных устройств. Первое актуально для кластеров, к примеру, под бэкапы или S3, а второе для файловых томов Kubernetes.
Ceph довольно навороченная система и с наскока её не осилить. В статье я постарался дать основную теорию и практику в виде установки кластера и примеров по работе с ним. Если у вас есть базовые навыки работы с Linux, то по статье вы сможете развернуть кластер и попробовать его в деле. Желательно, конечно, и Ansible понимать. Хотя бы на уровне чтения плейбуков и ошибок.
Один из вариантов использования Ceph - вместе с кластером Kubernetes. Достаточно купить любые 3 дешёвые дедика. Поставить туда Proxmox, нарезать виртуалки. На них раскатать Ceph и Kubernetes. Получится очень дешёвый тестовый кластер, который сможет сэкономить кучу денег. Он будет стоит в 3-5 раз дешевле, чем managed kubernetes. И при этом будет выдерживать выход одной ноды из строя. То есть вполне стабильное решение. Кто-то и прод таким образом строит.
⇨ https://serveradmin.ru/ustanovka-i-nastrojka-ceph
#ceph #devops
💡Для тех, кто не знаком с Ceph, поясню, что это программная объектная отказоустойчивая сеть хранения данных. Если по-простому, то это кластер для хранения данных. Причём он может отдавать данные как обычные файлы через свою распределённую файловую систему cephfs, так и в виде блочных устройств. Первое актуально для кластеров, к примеру, под бэкапы или S3, а второе для файловых томов Kubernetes.
Ceph довольно навороченная система и с наскока её не осилить. В статье я постарался дать основную теорию и практику в виде установки кластера и примеров по работе с ним. Если у вас есть базовые навыки работы с Linux, то по статье вы сможете развернуть кластер и попробовать его в деле. Желательно, конечно, и Ansible понимать. Хотя бы на уровне чтения плейбуков и ошибок.
Один из вариантов использования Ceph - вместе с кластером Kubernetes. Достаточно купить любые 3 дешёвые дедика. Поставить туда Proxmox, нарезать виртуалки. На них раскатать Ceph и Kubernetes. Получится очень дешёвый тестовый кластер, который сможет сэкономить кучу денег. Он будет стоит в 3-5 раз дешевле, чем managed kubernetes. И при этом будет выдерживать выход одной ноды из строя. То есть вполне стабильное решение. Кто-то и прод таким образом строит.
⇨ https://serveradmin.ru/ustanovka-i-nastrojka-ceph
#ceph #devops
Server Admin
Установка, настройка и эксплуатация Ceph | serveradmin.ru
Подробное описание установки, настройки и эксплуатации ceph своими словами для новичков и тех, кто только знакомится с ceph.
В комментариях к заметкам про синхронизацию файлов не раз упоминались отказоустойчивые сетевые файловые системы. Прямым представителем такой файловой системы является GlusterFS. Это условный аналог Ceph, которая по своей сути не файловая система, а отказоустойчивая сеть хранения данных. Но в целом обе эти системы используются для решения одних и тех же задач. Про Ceph я писал (#ceph) уже не раз, а вот про GlusterFS не было ни одного упоминания.
Вообще, когда выбирают, на основе чего построить распределённое файловое хранилище, выбирают и сравнивают как раз GlusterFS и Ceph. Между ними есть серьёзные отличия. Первое и самое основное, GlusterFS - это файловая система Linux. При этом Ceph - объектное, файловое и блочное хранилище с доступом через собственное API, минуя операционную систему. Архитектурно для настройки и использования GlusterFS более простая система и это видно на практике, когда начинаешь её настраивать и сравнивать с Ceph.
Я покажу на конкретном примере, как быстро поднять и потестировать GlusterFS на трёх нодах. Для этого нам понадобятся три идентичных сервера на базе Debian с двумя жёсткими дисками. Один под систему, второй под GlusterFS. Вообще, GlusterFS - детище в том числе RedHat. На её основе у них построен продукт Red Hat Gluster Storage. Поэтому часто можно увидеть рекомендацию настраивать GlusterFS на базе форков RHEL с использованием файловой системы xfs, но это не обязательно.
❗️ВАЖНО. Перед тем, как настраивать, убедитесь, что все 3 сервера доступны друг другу по именам. Добавьте в
На все 3 сервера устанавливаем glusterfs-server:
Запускаем также на всех серверах:
На server1 добавляем в пул два других сервера:
На остальных серверах делаем то же самое, только указываем соответствующие имена серверов.
Проверяем статус пиров пула:
На каждом сервере вы должны видеть два других сервера.
На всех серверах на втором жёстком диске создайте отдельный раздел, отформатируйте его в файловую систему xfs или ext4. Я в своём тесте использовал ext4. И примонтируйте в
Создаём на этой точке монтирования том glusterfs:
Если получите ошибку:
то проверьте ещё раз файл hosts. На каждом хосте должны быть указаны все три ноды кластера. После исправления ошибок, если есть, остановите службу glusterfs и почистите каталог
Если всё пошло без ошибок, то можно запускать том:
Смотрим о нём информацию:
Теперь этот volume можно подключить любому клиенту, в роли которого может выступать один из серверов:
Можете зайти в эту директорию и добавить файлы. Они автоматически появятся на всех нодах кластера в директории
По этому руководству наглядно видно, что запустить glusterfs реально очень просто. Чего нельзя сказать о настройке и промышленно эксплуатации. В подобных системах очень много нюансов, которые трудно учесть и сразу всё сделать правильно. Нужен реальный опыт работы, чтобы правильно отрабатывать отказы, подбирать настройки под свою нагрузку, расширять тома и пулы и т.д. Поэтому в простых ситуациях, если есть возможность, лучше обойтись синхронизацией на базе lsyncd, unison и т.д. Особенно, если хосты территориально разнесены. И отдельное внимание нужно уделить ситуациям, когда у вас сотни тысяч мелких файлов. Настройка распределённых хранилищ будет нетривиальной задачей, так как остро встанет вопрос хранения и репликации метаданных.
⇨ Сайт / Исходники
#fileserver #devops
Вообще, когда выбирают, на основе чего построить распределённое файловое хранилище, выбирают и сравнивают как раз GlusterFS и Ceph. Между ними есть серьёзные отличия. Первое и самое основное, GlusterFS - это файловая система Linux. При этом Ceph - объектное, файловое и блочное хранилище с доступом через собственное API, минуя операционную систему. Архитектурно для настройки и использования GlusterFS более простая система и это видно на практике, когда начинаешь её настраивать и сравнивать с Ceph.
Я покажу на конкретном примере, как быстро поднять и потестировать GlusterFS на трёх нодах. Для этого нам понадобятся три идентичных сервера на базе Debian с двумя жёсткими дисками. Один под систему, второй под GlusterFS. Вообще, GlusterFS - детище в том числе RedHat. На её основе у них построен продукт Red Hat Gluster Storage. Поэтому часто можно увидеть рекомендацию настраивать GlusterFS на базе форков RHEL с использованием файловой системы xfs, но это не обязательно.
❗️ВАЖНО. Перед тем, как настраивать, убедитесь, что все 3 сервера доступны друг другу по именам. Добавьте в
/etc/hosts на каждый сервер примерно такие записи:server1 10.20.1.1server2 10.20.1.2server3 10.20.1.3На все 3 сервера устанавливаем glusterfs-server:
# apt install glusterfs-serverЗапускаем также на всех серверах:
# service glusterd startНа server1 добавляем в пул два других сервера:
# gluster peer probe server2# gluster peer probe server3На остальных серверах делаем то же самое, только указываем соответствующие имена серверов.
Проверяем статус пиров пула:
# gluster peer statusНа каждом сервере вы должны видеть два других сервера.
На всех серверах на втором жёстком диске создайте отдельный раздел, отформатируйте его в файловую систему xfs или ext4. Я в своём тесте использовал ext4. И примонтируйте в
/mnt/gv0.# mkfs.ext4 /dev/sdb1# mkdir /mnt/gv0# mount /dev/sdb1 /mnt/gv0Создаём на этой точке монтирования том glusterfs:
# gluster volume create gv0 replica 3 server1:/mnt/gv0 server2:/mnt/gv0 server3:/mnt/gv0Если получите ошибку:
volume create: gv0: failed: Host server1 is not in 'Peer in Cluster' stateто проверьте ещё раз файл hosts. На каждом хосте должны быть указаны все три ноды кластера. После исправления ошибок, если есть, остановите службу glusterfs и почистите каталог
/var/lib/glusterd.Если всё пошло без ошибок, то можно запускать том:
# gluster volume start gv0Смотрим о нём информацию:
# gluster volume infoТеперь этот volume можно подключить любому клиенту, в роли которого может выступать один из серверов:
# mkdir /mnt/gluster-test# mount -t glusterfs server1:/gv0 /mnt/gluster-testМожете зайти в эту директорию и добавить файлы. Они автоматически появятся на всех нодах кластера в директории
/mnt/gv0. По этому руководству наглядно видно, что запустить glusterfs реально очень просто. Чего нельзя сказать о настройке и промышленно эксплуатации. В подобных системах очень много нюансов, которые трудно учесть и сразу всё сделать правильно. Нужен реальный опыт работы, чтобы правильно отрабатывать отказы, подбирать настройки под свою нагрузку, расширять тома и пулы и т.д. Поэтому в простых ситуациях, если есть возможность, лучше обойтись синхронизацией на базе lsyncd, unison и т.д. Особенно, если хосты территориально разнесены. И отдельное внимание нужно уделить ситуациям, когда у вас сотни тысяч мелких файлов. Настройка распределённых хранилищ будет нетривиальной задачей, так как остро встанет вопрос хранения и репликации метаданных.
⇨ Сайт / Исходники
#fileserver #devops
Для построения распределённого файлового хранилища наиболее популярной и зрелой технологией является Ceph. Это программная объектная отказоустойчивая сеть хранения данных. Минимальное количество нод для построения кластера - три. При этом максимальное количество может исчисляться десятками и возможно сотнями. Ceph сложен и в установке, и в эксплуатации.
Компания Canonical, авторы Ubuntu, создали проект MicroCeph, который позволяет очень быстро и просто развернуть небольшой кластер Ceph. Для обучения или тестовых задач его можно развернуть даже на одной машине. MicroCeph по своей сути тот же Ceph, только уже преднастроенный и упакованный в пакет snap.
Покажу, как быстро развернуть кластер из трёх нод на базе виртуальных машин Ubuntu 24. У нас будут 3 идентичные виртуалки, в каждой по два диска: системный sda, чистый sdb под ceph. Все три ноды видят друг друга по именам node-1, node-2, node-3, которые добавлены им в файлы
Устанавливаем microceph и сразу запрещаем обновление на всех трёх нодах:
Теперь на node-1 инициализируем кластер и создадим токены для добавления двух других:
Идём на node-2 и node-3 и добавляем их в кластер, используя полученные выше токены:
На каждой ноде добавим диск sdb к хранилищу:
Смотрим, что получилось:
Дальше с кластером можно работать, как с традиционным ceph. Смотреть статус:
Активировать модуль статистики для Prometheus:
Метрики появятся по адресу http://10.20.1.34:9283/metrics. Смотрим использование кластера:
Он пока пустой, без данных. Нет ни одного пула. Создадим пул с распределённой файловой системой cephfs:
Смотрим список пулов:
Смотрим ключ пользователя admin, который создан автоматически:
Этот ключ нам нужен для того, чтобы получить доступ к файловой системе по сети. Я это показываю для теста. В проде так делать не надо. Надо создать отдельную директорию, создать для неё пользователя с правами к этой директории. И использовать его. Всё это подробно описано в моей статье на сайте про ceph:
⇨ Установка, настройка и эксплуатация Ceph
Теперь мы можем подключить эту файловую систему на любую машину Linux. Для этого туда надо установить пакет ceph-common:
Подключаем cephfs:
Теперь все созданные файлы в
Помимо распределённой файловой системы вы можете использовать ceph для создания RBD дисков, которые можно монтировать индивидуально каждому клиенту, в отличии от общей cephfs, которая одна на всех. Также можно создать совместимое с S3 хранилище с помощью отдельного компонента RADOS Gateway (RGW). Инструкций в сети много, так как продукт популярный. Можно самому во всём разобраться.
Документация и примеры эксплуатации MicroCeph описаны в документации продукта. Она краткая, ёмкая и легкая для восприятия. Там монтируют немного по-другому, передавая файлы ключей из директории
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#ceph #fileserver
Компания Canonical, авторы Ubuntu, создали проект MicroCeph, который позволяет очень быстро и просто развернуть небольшой кластер Ceph. Для обучения или тестовых задач его можно развернуть даже на одной машине. MicroCeph по своей сути тот же Ceph, только уже преднастроенный и упакованный в пакет snap.
Покажу, как быстро развернуть кластер из трёх нод на базе виртуальных машин Ubuntu 24. У нас будут 3 идентичные виртуалки, в каждой по два диска: системный sda, чистый sdb под ceph. Все три ноды видят друг друга по именам node-1, node-2, node-3, которые добавлены им в файлы
/etc/hosts.Устанавливаем microceph и сразу запрещаем обновление на всех трёх нодах:
# snap install microceph# snap refresh --hold microcephТеперь на node-1 инициализируем кластер и создадим токены для добавления двух других:
# microceph cluster bootstrap# microceph cluster add node-2# microceph cluster add node-3Идём на node-2 и node-3 и добавляем их в кластер, используя полученные выше токены:
# microceph cluster join <token node-2># microceph cluster join <token node-3>На каждой ноде добавим диск sdb к хранилищу:
# microceph disk add /dev/sdb --wipeСмотрим, что получилось:
# microceph statusMicroCeph deployment summary:- node-1 (10.20.1.34) Services: mds, mgr, mon, osd Disks: 1- node-2 (10.20.1.35) Services: mds, mgr, mon, osd Disks: 1- node-3 (10.20.1.36) Services: mds, mgr, mon, osd Disks: 1Дальше с кластером можно работать, как с традиционным ceph. Смотреть статус:
# ceph statusАктивировать модуль статистики для Prometheus:
# ceph mgr module enable prometheusМетрики появятся по адресу http://10.20.1.34:9283/metrics. Смотрим использование кластера:
# ceph dfОн пока пустой, без данных. Нет ни одного пула. Создадим пул с распределённой файловой системой cephfs:
# ceph osd pool create cephfs_meta# ceph osd pool create cephfs_data# ceph fs new newFs cephfs_meta cephfs_dataСмотрим список пулов:
# ceph fs ls# rados lspoolsСмотрим ключ пользователя admin, который создан автоматически:
# ceph auth get-key client.adminЭтот ключ нам нужен для того, чтобы получить доступ к файловой системе по сети. Я это показываю для теста. В проде так делать не надо. Надо создать отдельную директорию, создать для неё пользователя с правами к этой директории. И использовать его. Всё это подробно описано в моей статье на сайте про ceph:
⇨ Установка, настройка и эксплуатация Ceph
Теперь мы можем подключить эту файловую систему на любую машину Linux. Для этого туда надо установить пакет ceph-common:
# apt install ceph-commonПодключаем cephfs:
# mkdir /mnt/cephfs# mount.ceph 10.20.1.34,10.20.1.35,10.20.1.36:/ /mnt/cephfs -o name=admin,secret='AQB8nRpn7MBLAxAANpLgc8UxrLhT487Tt9Y4DA=='Теперь все созданные файлы в
/mnt/cephfs будут автоматически размещаться в кластере. Их будет видно со всех клиентов, к которым подключен этот же пул. Помимо распределённой файловой системы вы можете использовать ceph для создания RBD дисков, которые можно монтировать индивидуально каждому клиенту, в отличии от общей cephfs, которая одна на всех. Также можно создать совместимое с S3 хранилище с помощью отдельного компонента RADOS Gateway (RGW). Инструкций в сети много, так как продукт популярный. Можно самому во всём разобраться.
Документация и примеры эксплуатации MicroCeph описаны в документации продукта. Она краткая, ёмкая и легкая для восприятия. Там монтируют немного по-другому, передавая файлы ключей из директории
/var/snap/microceph/current/conf. Но общий смысл тот же самый.❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#ceph #fileserver
Server Admin
Установка, настройка и эксплуатация Ceph | serveradmin.ru
Подробное описание установки, настройки и эксплуатации ceph своими словами для новичков и тех, кто только знакомится с ceph.
Неоднократно видел в комментариях и обсуждениях Ceph упоминание о VitaStor. Автор называет её быстрой и простой распределённой программной СХД. Архитектурно она сильно похожа на Ceph, так что если кто-то с ней знаком, попробовать Vitastor не составит труда. Я где-то за пару часов разобрался, настроил тестовый стенд и проверил в работе.
Сразу дам ссылку на выступление автора, где он подробно рассказывает об истории создания VitaStor. В первой половине презентации он делает обзор современных кластерных средств хранения данных. В целом всё выступление интересное, я целиком прослушал без ускорения.
▶️ Vitastor, или Как я написал свою хранилку
В сети мало информации про VitaStor, а сравнительных тестов так вообще почти нет. Есть от самого автора, он их приводит в выступлении. И есть статья на хабре от небезызвестного Kvaps, где он сравнивает разные распределённые хранилища: Linstor, Ceph, Mayastor и Vitastor. По этим имеющимся данным VitaStor значительно быстрее Ceph при схожих моделях использования. По сути это прямой аналог, который можно просто взять и поставить вместо Ceph.
Автор VitaStor - наш соотечественник, так что документация проста и понятна для русского человека. Я не буду приводить подробно все команды для установки и использования, потому что они не уместятся в заметке. Дам только ссылки из документации, по которым я делал. Больше никаких источников не использовал. Установка очень простая.
Сразу упомяну, что у VitaStor есть готовые плагины для использования с современными системами виртуализации и контейнеризации: Proxmox, OpenStack, Kubernetes CSI.
Основное предназначение VitaStor - сетевые блочные устройства для систем виртуализации. То есть это в первую очередь кластер для дисков виртуалок. По аналогии с CephFS есть кластерная файловая система VitastorFS. В планах обозначено объектное хранилище S3 - Vitastor S3.
Я взял тестовый кластер из 3-х виртуальных машин под ОС Debian 12. В каждую из них добавил по 2 виртуальных диска. Один под систему, второй под сетевое хранилище. Зашёл в раздел установка из пакетов и выполнил установку.
Далее пошёл в раздел быстрый старт и собрал кластер практически в режиме копирования и вставки. Порядок действий следующий:
1️⃣ Настраиваем мониторы на основе etcd. Аналог MON в Ceph.
2️⃣ Настраиваем OSD (Object Storage Device). В Ceph так же называется.
3️⃣ Создаём пул.
4️⃣ Создаём образ диска.
Процедура 1 в 1 как с Ceph. Дальше я немного замешкался, так как не понял, как теперь подключать созданный диск. Можно было создать VitastorFS, но мне хотелось именно блочные устройства попробовать.
Немного походил по документации и разобрался. Автор пишет, что лучший интерфейс для подключения дисков к системе - VDUSE (vDPA Device in Userspace), так как поддерживается на уровне ядра и работает в целом быстрее, чем что либо другое. Альтернатива - NBD.
Я подключил диск через VDUSE. Он поддерживается ядром, начиная с версии 5.15, но только в 6.6 и выше модуль ядра включён по умолчанию. На Debian 12 сейчас ядро 6.1, так что модуль пришлось собирать вручную по инструкции. Получилось всё без особых проблем простым копированием команд. В итоге подключил диск и получил блочное устройство
Немного погонял тесты, но толку от них никаких, так как собрано всё было в рамках одного сервера на виртуальных машинах. Никаких сравнительных тестов с другими системами хранения тоже не проводил, так как это трудоёмкая задача.
Отмечу для тех, кому это важно. Vitastor есть в реестре российского программного обеспечения. Можно без проблем использовать в рамках импортозамещения.
Ещё ссылка на интересное выступление автора, где он рассказывает про архитектуру:
▶️ Архитектура Vitastor. Тёмная сторона моей распределённой СХД
Продукт, конечно интересный. Понравился комментарий автора по поводу производительности Ceph. Он предполагает, что ускорить его невозможно, так как там более миллиона строк кода. Проще написать с нуля, что он и сделал.
⇨ Сайт / Исходники
#ceph #fileserver #devops #отечественное
Сразу дам ссылку на выступление автора, где он подробно рассказывает об истории создания VitaStor. В первой половине презентации он делает обзор современных кластерных средств хранения данных. В целом всё выступление интересное, я целиком прослушал без ускорения.
▶️ Vitastor, или Как я написал свою хранилку
В сети мало информации про VitaStor, а сравнительных тестов так вообще почти нет. Есть от самого автора, он их приводит в выступлении. И есть статья на хабре от небезызвестного Kvaps, где он сравнивает разные распределённые хранилища: Linstor, Ceph, Mayastor и Vitastor. По этим имеющимся данным VitaStor значительно быстрее Ceph при схожих моделях использования. По сути это прямой аналог, который можно просто взять и поставить вместо Ceph.
Автор VitaStor - наш соотечественник, так что документация проста и понятна для русского человека. Я не буду приводить подробно все команды для установки и использования, потому что они не уместятся в заметке. Дам только ссылки из документации, по которым я делал. Больше никаких источников не использовал. Установка очень простая.
Сразу упомяну, что у VitaStor есть готовые плагины для использования с современными системами виртуализации и контейнеризации: Proxmox, OpenStack, Kubernetes CSI.
Основное предназначение VitaStor - сетевые блочные устройства для систем виртуализации. То есть это в первую очередь кластер для дисков виртуалок. По аналогии с CephFS есть кластерная файловая система VitastorFS. В планах обозначено объектное хранилище S3 - Vitastor S3.
Я взял тестовый кластер из 3-х виртуальных машин под ОС Debian 12. В каждую из них добавил по 2 виртуальных диска. Один под систему, второй под сетевое хранилище. Зашёл в раздел установка из пакетов и выполнил установку.
Далее пошёл в раздел быстрый старт и собрал кластер практически в режиме копирования и вставки. Порядок действий следующий:
Процедура 1 в 1 как с Ceph. Дальше я немного замешкался, так как не понял, как теперь подключать созданный диск. Можно было создать VitastorFS, но мне хотелось именно блочные устройства попробовать.
Немного походил по документации и разобрался. Автор пишет, что лучший интерфейс для подключения дисков к системе - VDUSE (vDPA Device in Userspace), так как поддерживается на уровне ядра и работает в целом быстрее, чем что либо другое. Альтернатива - NBD.
Я подключил диск через VDUSE. Он поддерживается ядром, начиная с версии 5.15, но только в 6.6 и выше модуль ядра включён по умолчанию. На Debian 12 сейчас ядро 6.1, так что модуль пришлось собирать вручную по инструкции. Получилось всё без особых проблем простым копированием команд. В итоге подключил диск и получил блочное устройство
/dev/vda. Немного погонял тесты, но толку от них никаких, так как собрано всё было в рамках одного сервера на виртуальных машинах. Никаких сравнительных тестов с другими системами хранения тоже не проводил, так как это трудоёмкая задача.
Отмечу для тех, кому это важно. Vitastor есть в реестре российского программного обеспечения. Можно без проблем использовать в рамках импортозамещения.
Ещё ссылка на интересное выступление автора, где он рассказывает про архитектуру:
▶️ Архитектура Vitastor. Тёмная сторона моей распределённой СХД
Продукт, конечно интересный. Понравился комментарий автора по поводу производительности Ceph. Он предполагает, что ускорить его невозможно, так как там более миллиона строк кода. Проще написать с нуля, что он и сделал.
⇨ Сайт / Исходники
#ceph #fileserver #devops #отечественное
Please open Telegram to view this post
VIEW IN TELEGRAM