Обзорная статья про установку и настройку кластера ceph для построения отказоустойчивого файлового хранилища. Написал просто, своим языком с примерами.
https://serveradmin.ru/ustanovka-i-nastrojka-ceph/

#статья #ceph #devops

Понадобилось на днях установить 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

​​В комментариях к заметкам про синхронизацию файлов не раз упоминались отказоустойчивые сетевые файловые системы. Прямым представителем такой файловой системы является 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 сервера доступны друг другу по именам. Добавьте в /etc/hosts на каждый сервер примерно такие записи:
server1 10.20.1.1
server2 10.20.1.2
server3 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