Ceph установка и настройка debian
Обновлено: 02.07.2024
Поскольку заниматься Ceph я начал недавно, возможны недочеты или же некоторые действия могут показаться лишними или неправильными.
Я действую из той информации, которая доступна и понятна мне. Список материалов будет представлен в конце статьи.
В качестве тестового стенда я взял ESXi сервер, на котором развернул виртуальные машины с необходимым мне количество виртуальных дисков, которые будут имитировать работу физических серверов.
Коротко о демонах
OSD (object storage daemon) — в каждой ноде кластера может быть несколько дисков и на каждый диск нужен отдельный демон OSD.
Демоны Ceph OSD сохраняют данные в виде объектов в плоском пространстве имён, то есть без иерархии в виде каталогов. Объекты обладают идентификаторами, бинарными данными и метаданными в виде ключ-значение, которые использует MDS сохраняя владельца файла, время создания, время модификации и так далее. Идентификатор объекта уникален в пределах кластера.
Демон OSD в составе кластера постоянно сообщает о своём статусе - up или down. Если по ряду причин OSD демон не сообщает о своём состоянии, демон монитора периодически сам проверяет статус OSD демонов и уполномочен обновлять кластерную карту и уведомлять других демонов мониторов о состоянии OSD демонов.
Metadata server (MDS) — вспомогательный демон для обеспечения синхронного состояния файлов в точках монтирования CephFS. В один момент времени работает только один MDS в пределах кластера, а другие находятся в режиме ожидания и кто-то станет активным, если текущий MDS упадёт.
Мониторы Ceph (Ceph Monitors) поддерживают главную копию (master copy) кластерной карты (cluster map), по которой клиенты Ceph могут определить расположение всех мониторов, OSD демонов и серверов Metadata (MDS). До того как клиенты начнут что-либо писать или читать у OSD или MDS, они должны впервую очередь связаться с монитором Ceph.
С текущей кластерной картой и алгоритмом CRUSH, клиенты могут вычислить расположение любого объекта. Эта способность позволяет клиентам напрямую общаться с OSD, что является важным аспектом в архитектуре Ceph и его способности к высокой доступности и производительности.
Главная задача мониторов - поддерживать главную копию кластерной карты. Помимо этого мониторы занимаются аутентификацией и журналированием.
Кластерная карта - это комплексная карта. Она состоит из карты мониторов (monitor map), карты OSD (OSD map), карты плейсмент-группы (placement group map) и карты MDS (metadata server map).
Приступим.
Выполняем установку ОС на сервера и базовую настройку сети, также отключаем IPv6 и SElinux.
Установку системы производим на один диск, загрузчик ставим туда же, никаких RAID не собираем (тоже самое касается аппаратного RAID - только RAID 0 (JBOD)).
- Ceph-node-admin [192.168.2.67]
- Ceph-node-mon [192.168.2.68]
- Ceph-node-00 [192.168.2.69]
- Ceph-node-01 [192.168.2.70]
- Ceph-node-02 [192.168.2.71]
Для удобства будем работать по каноническим именам, если нет своего личного DNS-сервера, то не забываем внести соответствующие настройки в файл /etc/hosts на каждом сервере.
Настройка NTP
Выполняем настройку NTP сервера на каждой ноде.
Это очень важный шаг, поскольку большинство проблем может возникнуть именно из-за некорректной настройки времени.
Установим NTP
Вносим изменения в конфигурационный файл /etc/ntp.conf .
Выполним настройку временной зоны, если это не было сделано при установке системы.
Создаем нового пользователя
Поскольку данный пункт я выполнил на стадии установки, то я сразу перейду к следующему шагу.
Изменим файл /etc/sudoers на каждом сервере и добавим в него следующую строчку, что позволит выполнять sudo команды без запроса пароля. Либо создадим в папке /etc/sudoers.d/ файл с именем пользователя, в который добавим тоже самое.
Мы создали пользователя ceph на каждой ноде, теперь создадим ключ авторизации, без указания кодовой фразы, для беспарольного доступа между серверами.
Теперь скопируем его на все используемые сервера.
Настройка ядра системы
При наличии большого количества OSD, возможно создание огромного количества тредов (threads), особенно в процессе восстановления или же при повторной балансировке. Изменим в Linux значение по умолчанию на необходимое нам.
kernel.pid_max служит для поддержки большего значения тредов (threads). В теории, максимум это - 4,194,303 .
Внесем изменения в файл /etc/sysctl.conf , добавив строчку:
Применяем параметры “на лету”:
Настроим правила на файрволле
Для Firewalld
Для Iptables
Также установим пакет yum-plugin-priorities , чтобы менеджер пакетов устанавливал предпочтительные пакеты.
Установка Ceph Storage Cluster с помощью ceph-deploy
Начнем пожалуй с простого. Сделаем кластер с двумя OSD демонами и одним монитором. После достижения статуса active+clean добавим третий OSD демон в уже работающий кластер, а также резервный MDS и несколько мониторов.
Выполним установку ceph-deploy
Установим необходимые пакеты и репозитории:
Подключим репозиторий Ceph /etc/yum.repos.d/ceph.repo :
Заменим на наш дистрибутив, в данном случае el7 .
Заменим на стабильную версию Ceph.
На момент написания статьи это infernalis .
После всех этих действий установим пакет ceph-deploy :
Создадим рабочую директорию на административной ноде для генерации конфигурационных файлов и ключей, дальнейшие действия необходимо выполнять находясь в ней.
Очень важно!
Не выполняйте команду ceph-deploy с sudo или же от root , если авторизованы под другим пользователем.
На некоторых дистрибутивах, в частности CentOS, при выполнении команды ceph-deploy возможны ошибки, для этого измените параметр Defaults requiretty с помощью sudo visudo в /etc/sudoers.d/ceph на Defaults:ceph !requiretty для того, чтобы ceph-deploy мог подключаться с помощью пользователя ceph и выполнять команды с sudo .
Далее при установке, если на каком-то из пунктов получили неисправимую ошибку, то можно затереть данные и откатиться, используя следующие команды:
Для удаления пакетов:
Если выполнялась команда purge , то необходимо переустановить пакеты Ceph.
Создаем кластер Ceph Storage Cluster
С админской ноды из директории, которую мы создали для хранения конфигурационных файлов, выполняем команду для создания кластера:
После этого в папке появится конфигурационный файл и ключ монитора. Убедитесь в этом.
По умолчанию имя кластера будет ceph. Если вы хотите на одном и том же оборудовании использовать несколько кластеров, то для каждого из них нужно задавать имя, используя ceph-deploy –cluster new …
Изменим значение по умолчанию для количества реплик в Ceph. По умолчанию значение равно 3 , изменим его на 2 , чтобы Ceph мог достичь статуса Active+Clean с помощью двух OSD. Добавим следующую строку в директиву [global] файла ceph.conf .
Зададим значения для плейсмент групп (Placement Groups) и плейсмент групп для размещения (Placement Groups for Placement) в директиве [global] . Для небольших кластеров (менее 5 OSDs) рекомендуется 128 плейсмент группы.
- менее 5 OSD - значение pg_num и pgp_num ставим 128;
- от 5 до 10 OSD - значение pg_num и pgp_num ставим 512;
- от 10 до 50 OSD - значение pg_num и pgp_num ставим 4096;
- от 50 OSD и выше параметры pg_num и pgp_num рассчитываем по следующей формуле:
osd_pool_default_size значение, которое мы устанавливали на предыдущем шаге.
Установим максимальное количество плейсмент груп на OSD. По умолчанию это значение равно 300. Несколько пулов могут использовать один и тот же набор правил CRUSH. Когда OSD имеют слишком много плейсмент групп это может сказаться на производительности.
Установка типа CRUSH для отказоустойчивости. По умолчанию это значение равно 1. Если мы хотим сделать как минимум для 3-х объектов реплики, то необходимо изменить параметр на 3.
Установим max_open_files для того чтобы задать максимальное значение открытых дескрипторов файлов на уровне ОС:
XATTR параметры используются с файловой системой ext4 для улучшения производительности.
Как уже и говорилось в начале статьи, рекомендуется правильная настройка времени на сервере.
Установим full_ratio и near_full_ratio на приемлемые значения. Полную мощность на 95% и почти заполненную на 85%.
Если на сервере имеется и используется больше одного сетевого интерфейса, то добавим public_network в секцию [global] конфигурационного файла Ceph. ( Подробнее о сетевой конфигурации )
Установим Ceph:
В процессе установки может появиться следующая ошибка:
Устраняем проблему командой:
Настройка CRUSH карты с SSD кэшированием
В файле конфигурации ceph запрещаем обновлять карту автоматически:
Сохраним текущую карту и переведем её в текстовый формат:
Обратите внимание на то, что я создал два root для SSD и HDD, а также два правила ruleset.
Скомпилируем обратно и запустим CRUSH-карту
Добавим первоначальные мониторы и соберем ключи
Для обеспечения высокой доступности необходимо запустить Ceph как минимум с 3-мя мониторами. Ceph использует алгоритм, который требует консенсуса среди большинства мониторов в кворуме.
Подсчет мониторов осуществляется приблизительно следующим образом: 1:1 , 2:3 , 3:4 , 3:5 , 4:6 , etc. Необязательно, но желательно, чтобы количество мониторов в кластере было нечётным числом для улучшения работы алгоритма Paxos при сохранении кворума.
В идеале, разработчики Ceph советуют ноды-мониторы не совмещать с нодами OSD, так как мониторы активно используют fsync() и это пагубно влияет на производительность OSD.
После выполнения данного процесса в локальной директории ceph-admin проверим наличие всех ключей:
Добавление OSD
Первоначальный вариант предусматривает OSD в виде директорий на диске, я же буду использовать диски полностью.
Добавление и удаление OSD демонов в кластер может занимать несколько шагов, особенно если используется запись на диск и в журнал.
Для листинга дисков ноды используем следующую команду:
Затираем диски
Определившись с дисками затираем все данные на них (в т.ч. таблицу разделов) и подготовим для использования Ceph.
Подготовим диски
Разработчики Ceph рекомендуют использовать файловую систему XFS. ( см. Ceph Docs ), поэтому позаботьтесь о том, чтобы пакет xfsprogs был установлен на всех нодах кластера.
При подготовке дисков ceph-deploy автоматически форматирует диски в XFS. Если установка производится на разделы, то отформатировать его можно командой sudo mkfs.xfs -i size=512 /dev/sdX .
После создания кластера и установки Ceph пакетов, а также создания ключей, можем выполнить подготовку OSD и развернуть их на OSD нодах. Команда prepare только подготовит OSD!
Активация OSD
После успешной подготовки дисков активируем OSD. (Обратите внимание, что необходимо указать разделы диска.)
Для того чтобы подготовить, развернуть и активировать OSD можно воспользоваться одной командой create :
Скопируем ключи и конфигурационный файл на ноды:
Убедимся в корректных привилегиях ceph.client.admin.keyring :
Получаем статус Ceph:
При получении предупреждения, например:
Создание OSD с SSD кэшированием
К сожалению OSD автоматически в конфигурационный файл не запишутся. Кроме того даже после записи в конфигурацию автоматическое монтирование этих точек тоже не работает.
Чтобы поднять OSD демон при загрузке необходим файл ключ, который лежит на не примонтированном разделе. Поэтому дополняем конфигурационный файл ceph.conf :
Кроме этого смотрим на каждом узле где есть osd:
Добавляем записи в /etc/fstab для надежности:
На текущем моменте у нас есть кластер с единственным и пока не настроенным пулом.
RBD можно считать некоторым аналогом жесткого диска на котором необходимо будет нарезать разделы.
Например для Opennebula потребуется три пула: files , system и images .
Цифра в конце команды - количество PG и PGP для пула. Можно считать, что PG это минимальный реплицирующийся кусок пространства, в которое мы можем запихнуть обьект (файл) или кусок от него. PGP - максимальное количество PG групп для пула.
По мануалам есть формула общего количество PG (указано выше): ((количество OSD)100)/(osd pool default size). То есть 3100/2 = 150. полученное число ещё необходимо округлить вверх до степени двойки - то есть у нас получается 256. Делим это число на количество пулов, округляем вверх до степени 2 - получаем искомую настройку. 256/2 (system,rbd)=128.
Получаем информацию о плейсмент группах:
Задаем значения PG вручную:
Ceph находится в зависимости от Ceph клиентов и Ceph OSD демонов, будучи осведомленных о кластерной топологии, которые включают в себя 5 отдельных карт, коллективно называемых как “Cluster Map”:
Монитор: Содержит FSID кластера, положение, адреса и порт каждого монитора. Он так же указывает на текущую версию сервера монитора, когда карта была создана и когда в последний раз изменялась. Чтобы просмотреть карту монитора необходимо выполнить команду: ceph mon dump
OSD: Содержит FSID кластера, когда карта была создана и последние изменения, список пулов, размер репликаций, количество PGs, список OSD и их текущее состояние. Для просмотра OSD карты необходимо выполнить команду: ceph osd dump
PG: Содержит версию PG, его метки времени, последнию версию OSD, полные соотношения и подробную информацию о каждой группе размещения, такие как PG ID, состояние PG (например active+clean ) и т.д. Для просмотра PG карты необходимо выполнить команду: ceph pg dump
CRUSH: Содержит список устройств хранения, отказоустойчивую иерархию домена (device,host,rack,row,room,datacenter) и правила для иерархий при хранений данных. Для просмотра структуры CRUSH алгоритма необходимо выполнить команду: ceph osd tree
MDS: Содержит текущую MDS версию карты, когда карта была создана и когда в последний момент изменялась. Так же содержится pool для хранения метаданных, список серверов метаданных и какие сервера включены и выключены. Для просмотра MDS карты, необходимо выполнить ceph mds dump
Терминология
Metadata server (MDS) — вспомогательный демон для обеспечения синхронного состояния файлов в точках монтирования CephFS. Работает по схеме активная копия + резервы, причем активная копия в пределах кластера только одна.
Mon (Monitor) — элемент инфраструктуры Ceph, который обеспечивает адресацию данных внутри кластера и хранит информацию о топологии, состоянии и распределении данных внутри хранилища. Клиент, желающий обратиться к блочному устройству rbd или к файлу на примонтированной cephfs, получает от монитора имя и положение rbd header — специального объекта, описывающего положение прочих объектов, относящихся к запрошенной абстракции (блочное устройство или файл) и далее общается со всеми OSD, участвующими в хранении файла.
Объект (Object) — блок данных фиксированного размера (по умолчанию 4 Мб). Вся информация, хранимая в Ceph, квантуется такими блоками. Чтобы избежать путаницы подчеркнем — это не пользовательские объекты из Object Storage, а объекты, используемые для внутреннего представления данных в Ceph.
OSD (object storage daemon) — сущность, которая отвечает за хранение данных, основной строительный элемент кластера Ceph. На одном физическом сервере может размещаться несколько OSD, каждая из которых имеет под собой отдельное физическое хранилище данных.
Карта OSD (OSD Map) — карта, ассоциирующая каждой плейсмент-группе набор из одной Primary OSD и одной или нескольких Replica OSD. Распределение placement groups (PG) по нодам хранилища OSD описывается срезом карты osdmap, в которой указаны положения всех PG и их реплик. Каждое изменение расположения PG в кластере сопровождается выпуском новой карты OSD, которая распространяется среди всех участников.
Плейсмент-группа (Placement Group, PG) — логическая группа, объединяющая множество объектов, предназначенная для упрощения адресации и синхронизации объектов. Каждый объект состоит лишь в одной плейсмент группе. Количество объектов, участвующих в плейсмент-группе, не регламентировано и может меняться.
Primary OSD — OSD, выбранная в качестве Primary для данной плейсмент-группы. Клиентское IO всегда обслуживается той OSD, которая является Primary для плейсмент группы, в которой находится интересующий клиента блок данных (объект). rimary OSD в асинхронном режиме реплицирует все данные на Replica OSD.
RADOS Gateway (RGW) — вспомогательный демон, исполняющий роль прокси для поддерживаемых API объектных хранилищ. Поддерживает географически разнесенные инсталляции (для разных пулов, или, в представлении Swift, регионов) и режим active-backup в пределах одного пула.
Replica OSD (Secondary) — OSD, которая не является Primary для данной плейсмент-группы и используется для репликации. Клиент никогда не общается с ними напрямую.
Фактор репликации (RF) — избыточность хранения данных. Фактор репликации является целым числом и показывает, сколько копий одного и того же объекта хранит кластер.
Установка Ceph
mv /etc/yum.repos.d/ceph.repo /etc/yum.repos.d/ceph-deploy.repo(для устранения ошибки
[ceph_deploy][ERROR ] RuntimeError: NoSectionError: No section: 'ceph')
На Сервере1
ssh-keygen
Enter, Enter, Enter .
копируем ключ на все сервера
Инициализация сервера монитора
ceph-deploy mon create-initial
Развернуть дополнительный MDS standby
sudo ceph-deploy mds create ceph02
Удалить дополнительный MDS standby пока невозможно, согласно оф.документации.
Но можно сделать так.
Удаление CephFS и связанных с ней пулов
После этого можно удалить пулы которые использовались для работы файловой системы:ceph osd pool rm cephfs_data cephfs_data --yes-i-really-really-mean-it
ceph osd pool rm cephfs_metadata cephfs_metadata --yes-i-really-really-mean-it
Просмотр статусов
Правка прав
sudo chmod +r /etc/ceph/ceph.client.admin.keyring
Просмотр состояния дисков
ceph osd tree
Просмотр состояния кластера
ceph -s
monmap e2: 3 mons
- Работает 3 демона монитора
fsmap . , 1 up:standby
- 1 демон MDS активный и одни standby
osdmap e37: 3 osds:
- 3 демона osd
Подключение диска Block Device (rbd)
На Клиенте
chmod 644 /etc/ceph/ceph.client.admin.keyring
rbd ls -l
rbd map rbddisk01
rbd showmapped
mkfs.ext4 /dev/rbd0
mkdir /mnt/rbddisk01
mount /dev/rbd0 /mnt/rbddisk01
Подключение диска CephFS
*_netdev - чтобы монтирование прошло после подъёма сети.
Команды
ceph df
ceph osd stat
ceph osd dump
ceph osd tree
ceph mds stat
ceph fs dump
MDS Failover варианты
Правка ceph.conf
[mon]
mon clock drift allowed = 2
mon host = server1,server3,server3
mon addr = 192.168.0.10:6789,192.168.0.11:6789,192.168.0.12:6789
[mon.a]
host = server1
mon addr = 192.168.0.10:6789
[mon.b]
host = server2
mon addr = 192.168.0.11:6789
[mon.c]
host = server3
mon addr = 192.168.0.12:6789
[osd.0]
host = server1
osd data = /mnt/disk1/
osd journal = /mnt/disk1/journal
[osd.1]
host = server2
osd data = /mnt/disk1/
osd journal = /mnt/disk1/journal
[osd.2]
host = server3
osd data = /mnt/disk1/
osd journal = /mnt/disk1/journal
Тиражирование конфигурации среди узлов Кластера
ceph-deploy --overwrite-conf config push server1 server2 server3
Также желательно на админской машине
Добавление новых нод и OSD демонов
ceph-deploy --overwrite-conf osd prepare server4:/SDBceph-deploy --overwrite-conf osd activate server4:/SDB
Остановка, Старт, Рестарт кластера Ceph
/usr/bin/systemctl enable ceph-osd@2
Правка Crush-Карты Ceph
/ceph-admin/ceph.conf
отключаем автоматическое обновление карты
osd_crush_update_on_start = false
После правки компилируем
crushtool -c map.decompile -o map.new
И отправлем карту в Ceph
ceph osd setcrushmap -i map.new
Удаление OSD
ЕслиError EBUSY: osd.11 is still up; must be down before removal тогда на хосте где распологается данный OSD выполнить
1) Статус ceph
ceph -s
health HEALTH_WARN
too many PGs per OSD (320 > max 300)
Проверить количество Placement Groups можно так:
Получим вывод:
pool : 0 1 2 | SUM
----------------------------------------
osd.0 64 128 128 | 320
osd.1 64 128 128 | 320
osd.2 64 128 128 | 320
----------------------------------------
SUM : 192 384 384 |
Узнать текущий фактор репликации
ceph osd dump | grep -i pool
pool 0 'rbd' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 64 pgp_num 64 last_change 1 flags hashpspool stripe_width 0
pool 1 'cephfs_data' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 64 pgp_num 64 last_change 20 flags hashpspool crash_replay_interval 45 stripe_width 0
pool 2 'cephfs_metadata' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 64 pgp_num 64 last_change 18 flags hashpspool stripe_width 0
На текущий момент у вас уже достаточно сведений о Ceph, включая некоторые практические навыки. В данной главе мы узнаем следующие интересные материалы о Ceph:
Планирование аппаратных средств Ceph
Подготовка к вашей установке Ceph
Развертывание кластера Ceph вручную
Расширение кластера Ceph
Развертывание кластера Ceph с помощью инструментария ceph-deploy
Модернизация кластера Ceph
Содержание
Планирование аппаратных средств для кластера Ceph
Ceph является системой хранения на базе программного обеспечения, которая разработана для работы на обычном доступном у любого производителя оборудовании. Такая доступность Ceph делает ее экономичной, расширяемой и не привязанной к определенному производителю решению для систем хранения.
Настройка оборудования Ceph требует планирования на основании ваших потребностей. Тип аппаратных средств, а также проект кластера являются факторами, которые необходимо проанализировать на начальной стадии проекта. Тщательное планирование на начальном этапе может занять длинный путь для того, чтобы избежать узких мест и помочь с лучшей надежностью кластера. Выбор аппаратных средств зависит от различных факторов, таких как бюджет, том, есть ли необходимость сосредоточиться на производительности или емкости, либо на том и другом сразу, уровне отказоустойчивости, а также на вариантах окончательного использования. В данной главе мы обсудим мы обсудим общие соображения относительно аппаратных средств и проектирования кластера.
Требования монитора
Мониторы Ceph заботятся о работоспособности всего кластера, поддерживая его карты. Они не участвуют в хранении данных кластера. Следовательно, им не требуются мощные процессоры и большая память и у них довольно низкие запросы к системным ресурсам. В большинстве случаев для узла монитора вполне достаточно экономичного сервера начального уровня с одноядерным процессором и несколькими гигабайтами оперативной памяти.
Если у вас уже есть сервер с приличным количеством доступных системных ресурсов, вы можете выбрать такой узел для дополнительных обязанностей запуска мониторов Ceph. В этом случае вы должны быть уверены, что прочие службы, работающие на данном узле оставляют достаточные ресурсы для демонов монитора Ceph. В не промышленных средах, когда у вас есть бюджетные или аппаратные ограничения, вы можете рассмотреть возможность запуска мониторов Ceph на физически выделенных виртуальных машинах. Однако в производственной практике следует запускать монитор Ceph на нетребовательных к ресурсам, экономичных физических серверах.
Если вы настроили кластер на хранение журналов на локальном узле монитора, убедитесь, что у вас есть достаточное дисковое пространство на этом узле монитора для хранения таких журналов. Для кластера в рабочем состоянии журналы могут расти в объеме до нескольких гигабайт, однако для столкнувшегося с проблемами кластера, при включенном режиме отладки, они быстро потребляют гигабайты. Пожалуйста, регулярно проверяйте, что кластер не остается в проблемном состоянии в течении длительного времени при наличии любого пространства для журналов. В промышленной среде вы должны выделить достаточно большой раздел для журналов и выработать политику ротации журналов, чтобы всегда оставалось свободное пространство.
Сеть для узла монитора должна иметь резервирование., поскольку монитор не является участником автоматического восстановления кластера. Достаточно будет дополнительного сетевого адаптера с 1Gbps. Избыточности на сетевом уровне будет вполне достаточно, поскольку монитор устанавливает кворум с другими мониторами и отказ более 50 процентов узлов мониторов создаст проблемы при подключении к кластеру. В не промышленном окружении вы можете осуществлять управление и с одним сетевым адаптером узла монитора, но для промышленной установки избыточность на сетевом уровне является важным фактором.
Требования OSD
Типичная реализация кластера Ceph создает одно OSD (устройство хранения объектов) для каждого физического диска на узле кластера, что является рекомендованной практикой. Однако, OSD поддерживают гибкое развертывание одного OSD на диск или одного OSD на том RAID. Большинство реализаций кластера Ceph в среде JBOD использует одно OSD на физическое устройство. Для OSD Ceph необходимы:
Процессор и оперативная память
Журнал OSD (блочное устройство или файл)
Файловая система поддержки (XFS, ext4 или Btrfs)
Отдельная отказоустойчивая (рекомендуется) сетевая среда OSD или кластера
Рекомендуемая конфигурация процессора и оперативной памяти, которую вам необходимо иметь, состоит из процессора 1 ГГц и оперативной памяти 2 ГБ на OSD. Этого должно быть достаточно для большинства кластерных сред; однако, важно отметить, что в случае происшествий процесс восстановления требует больших системных ресурсов, чем при обычной работе.
Как правило, экономически эффективно выделить избыточные ресурсы процессора и памяти на ранней стадии планирования вашего кластера, поскольку мы сможем в любое время добавить дополнительные физические диски JBOD- подобным образом в тот же хост, если он имеет достаточно системных ресурсов, вместо покупки целиком нового узла, что является более дорогостоящим решением.
OSD является основной единицей хранения в Ceph; вы должны иметь достаточно жестких дисков в соответствии с вашими потребностями к емкости хранилища. Для дисковых устройств обычно чем выше их емкость, тем ниже стоимость в терминах стоимости за гигабайт . Вам следует воспользоваться преимуществом стоимости гигабайта и использовать OSD довольно большого размера. Однако следует иметь в виду, что чем больше размер диска, тем больше оперативной памяти необходимо для работы. < Прим. пер.: при операциях балансировки и восстановления для OSD рекомендуется наличие оперативной памяти из расчета 1 ГБ на 1 ТБ. >
С точки зрения производительности, вам следует рассмотреть возможность выделения отдельных дисков ведения журналов для OSD. Отмечается повышение производительности при создании журналов OSD в разделах SSD диска при хранении данных на отдельном шпиндельном диске. Когда для журналов используются твердотельные диски, это улучшает производительность кластера и управляет рабочей нагрузкой быстро и эффективно. Тем не менее, недостатком твердотельного диска является то, что он увеличивает стоимость хранения одного гигабайта в вашем кластере. Эффективным способом инвестирования в SSD является назначение одного SSD диска в качестве журнального для более чем одного OSD. Компромиссом здесь является то, что если вы потеряете твердотельный диск ведения журналов, который является общим для нескольких OSD, вы потеряете ваши данные на всех этих дисках, следовательно, попытайтесь избегать перегруженности SSD журналами. Достойным количеством журналов должно быть от двух до четырех на SSD.
Требования сетевой среды
В отношении конфигурации сетевой среды рекомендуется, чтобы кластер имел по крайней мере две отдельные сети, по одной для сети передачи данных передней стороны или общедоступной сети и другой для сетевой среды тыльной стороны или кластерной сети. Две различные сети рекомендуются для того, чтобы разделять сети данных клиентов и обмена данных кластера Ceph. БОльшую часть времени сетевой обмен в среде кластера Ceph превосходит по объему обмен данными клиентов, поскольку Ceph использует сеть кластера для выполнения репликаций для всех объектов, а также для восстановления после сбоев < Прим. пер.: и для балансировки OSD >. Если у вас обе сети содержатся в одной физической среде, вы можете столкнуться с некоторыми проблемами производительности. Опять же, рекомендуется иметь две различные сети, но вы всегда можете запустить свой кластер Ceph в одной физической сети. Эти отдельные сети должны иметь пропускную способность не менее 1Gbps. Тем не менее, всегда будет лучше иметь сеть 10Gbps основываясь на вашей рабочей нагрузке или требуемой производительности. Елси вы проектируете кластер Ceph, который планируется расширять в ближайшем будущем, и можете рассчитывать на хороший объем рабочей нагрузки, старт с 10Gbps физически разделенных сетей и для данных и для кластера будет правильным выбором если вас беспокоят отдача на инвестиции и производительность.
Желательно также иметь избыточность на каждом уровне конфигурации сети, а именно: сетевых контроллеров, портов, коммутаторов и маршрутизаторов. Сеть передачи данных передней стороны или общедоступная сеть обеспечивает взаимосвязь между клиентами и кластером Ceph. Каждая операция ввода/вывода между клиентами и кластером Ceph будет проходить через этот интерконнект. Вы должны убедиться, что у вас существует достаточно пропускной способности для каждого клиента. Второй интерконнект, который является серверной кластерной сетью, используется внутри узлов Ceph OSD. Поскольку Ceph обладает распределенной архитектурой, для каждой клиентской операции записи, данные реплицируются N раз и хранятся в кластере. Таким образом, для одной операции записи кластер Ceph должен выполнить N* значений одной операции записи. Все это копии данных перемещаются по одноранговым связям узлов во внутрикластерной сети. Помимо начальной репликации записи, сеть кластера также используется при балансировке и восстановлении данных. Поэтому она играет жизненно важную роль для определения производительности вашего кластера.
Учитывая потребности вашего бизнеса, рабочей нагрузки и общей производительности вы всегда должны пересматривать конфигурацию своей сети и можете выбрать отдельные интерконнекты 40Gbps как для общедоступной, так и для кластерной сетевой среды. Это может сделать существенные улучшения для очень больших кластеров с размерами в сотни терабайт. Большинство реализаций кластеров основано на Ethernet, однако, InfiniBand также набирает популярность в качестве высокоскоростной сетевой среды для сетей переднего и заднего плана. В качестве дополнительной опции, исходя из вашего бюджета, вы также можете рассмотреть отдельную сеть для управления, а также аварийную сеть для обеспечения дополнительного уровня резервирования сети в вашем промышленном кластере.
Требования MDS
По сравнению с монитором (MON) Ceph и OSD, Ceph MDS (сервера метаданных) является слегка более ресурсоемкими. Они требуют значительно больших мощностей процессоров с четырьмя ядрами и более. Поскольку серверы метаданных должны быстро обслуживать данные, они сильно зависят Ceph от кешируемых данных, поэтому им требуется много оперативной памяти. Чем выше объем оперативной памяти для Ceph MDS, тем лучше будет производительность CephFS. Если у вас существует большая нагрузка на CephFS, вы должны выделить для серверов метаданных Ceph отдельные физические машины с относительно большим количеством ядер и оперативной памяти. Сетевой интерфейс с резервированием со скоростью 1Gb или выше будет работать в большинстве случаев для MDS Ceph.
Вам рекомендуется для операционной системы использовать отдельные диски в RAID- массиве для MON, ODS и MDS. Вам не следует использовать диски/ разделы операционной системы для данных кластера.
Настройка вашей среды VirtualBox - еще раз
В Главе 2. Моментальное развертывание Ceph мы создали три виртуальные машины VirtualBox, которые мы использовали для развертывания первого мгновенного кластера Ceph. Теперь вы должны удалить этот кластер Ceph и деинсталлировать пакеты Ceph или удалить эти виртуальные машины. В данной главе мы опять установим Ceph, однако используем другой способ. Вы должны следовать указаниям раздела Создание среды песочницы с использованием VirtualBox в Главе 2. Моментальное развертывание Ceph для повторного создания виртуальных машин,которые мы будем использовать в данной главе.
Подготовка к установке вашей Ceph
Ранее в данной главе мы обсудили некоторые особенности выбора правильного оборудования в зависимости от ваших потребностей и вариантов использования. Вы должны соответствующим образом организовать ваши аппаратные средства, включая компоненты сетевой среды. Оборудования кластера должно быть смонтировано, соединено кабелями, запитано, а также должно иметь действующую сеть для своих узлов. Как только вы завершите с подготовкой аппаратных средств, вы будете готовы к выполнению настройки программных средств вашего кластера.
Вам рекомендуется использовать одни и те же дистрибутив, редакцию и версию ядра на всех узлах кластера Ceph.
Получение программного обеспечения
Ceph является проектом с открытым исходным кодом; существует несколько способов получения его программного обеспечения через интернет.
Получение пакетов
Получение пакетов через интернет является одним из наиболее распространенных вариантов получения Ceph. Опять же, существует два различных способа получения пакетов:
Первый метод состоит в загрузке Ceph и соответствующих пакетов вручную в необходимом формате. Если по соображениям безопасности ваши узлы Ceph не имеют доступа в интернет, это будет возможным вариантом для вас. Вы можете скачать Ceph и все связанное с ним на любую из машин в вашей сети и скопировать их на каждый узел, после чего выполнить установку.
Ceph – программное обеспечение для организации высокодоступного распределенного кластера хранения данных на серверном оборудовании общего назначения. В ПК СВ Брест Ceph может быть использован для предоставления доступа к создаваемым в нем блочным устройствам RBD.
Требования
- Имеется 2N+1 узлов для развертывания ceph
- На серверах развернута ОС в соответствии с Установка ОС
Для более надежной работы кластера рекомендуется в дальнейшем добавление четвертого сервера с сервисом OSD для хранения данных.
При расчете продуктовых кластеров CEPH рекомендуется резервировать по 4 Gb ОЗУ на каждый сервис OSD .
Установка и настройка кластера Ceph с помощью ceph-deploy
Подготовка серверов ceph и серверов ПК СВ Брест
Синхронизация времени
На каждом сервере ceph необходимо прописать в файл /etc/ntp.conf сервер для синхронизации времени:
После чего перезапустить и сделать автозапуск после перезагрузки службы ntp на каждом сервере ceph командами:
sudo systemctl enable ntp
sudo systemctl restart ntp
Разрешение имен
Для удобной работы с кластером Ceph необходимо, чтобы все серверы инфраструктуры могли обращаться к узлам Ceph по доменным именам. В зависимости от типа используемого домена настройте разрешение имен:
Внесите записи об узлах Ceph в DNS-сервисе FreeIPA, как указано в этом подразделе: Добавление записей в DNS
Создайте локальный файл со следующим содержимым:
Отредактируйте локальные файлы на каждом узле Ceph как описано в разделе Разрешение имен
Обратите внимание, что информацию об узлах Ceph также потребуется аналогичным образом внести на всех остальных узлах домена, если это не сделано ранее.
Создание пользователя ceph-adm
На каждом сервере кластера Ceph, front-end и узлах виртуализации добавляем пользователя ceph-adm и разрешаем ему sudo без пароля следующими командами:
sudo adduser ceph-adm
echo "ceph-adm ALL = (root) NOPASSWD:ALL" |sudo tee /etc/sudoers.d/ceph-adm
sudo chmod 0440 /etc/sudoers.d/ceph-adm
sudo pdpl-user -i 63 ceph-adm
Если узел ceph настраивается на front-end, или узле виртуализации, выполните команду:
sudo pdpl-user -i 127 ceph-adm
На сервере <ceph-1-hostname> настройте беспарольный доступ по ssh на все серверы ceph, front-end и узлы виртуализации (команды выполнять от пользователя < local-admin >):
можно использовать циклы так:
for node_id in $(seq 1 <X>); do ssh-copy-id ceph-adm@ceph-$node_id; done
for front_id in $(seq 1 <Y>); do ssh-copy-id ceph-adm@front-$front_id; done
for ceph_id in $(seq 1 <Z>); do ssh-copy-id ceph-adm@node-$ceph_id; done
<X> узлов ceph c именами вида ceph-1, ceph-2, и т.д.;
<Y> фронтальных машин с именами вида front-1, front-2, и т.д.;
<Z> узлов виртуализации c именами вида node-1, node-2, и т.д.;
Установка служб кластера Ceph на серверах ceph и серверах ПК СВ Брест
Установите пакет ceph-deploy на сервер <ceph-1-hostname> командой:
Далее все команды с ceph-deploy выполняются строго из консоли сервера <ceph-1-hostname>, находясь в домашнем каталоге администратора!Необязательно разворачивать монитор (MON) на каждом узле кластера Ceph, но количество мониторов должно быть 2N+1.
Запустите команду для установки Ceph компонент на серверах ceph:
ceph-deploy --username ceph-adm install --mon --osd <ceph-1-hostname> <ceph-2-hostname> . <ceph-N-hostname>
Запустите команду для установки на сервере ceph1 компоненты ceph-mgr:
ceph-deploy --username ceph-adm install --mgr <ceph-1-hostname>
Запустите команду для создания нового кластера Ceph, при этом требуется указать в команде сервера кластера, на которых в дальнейшем будут инициализированы мониторы кластера:
ceph-deploy --username ceph-adm new <ceph-1-hostname> <ceph-2-hostname> . <ceph-N-hostname>
После выполнения команды будут созданы конфигурационный файл (по умолчанию ceph.conf) и keyring-файл мониторов
Запустите команду для инициализации мониторов на ранее указанных серверах кластера:
ceph-deploy --username ceph-adm mon create-initial
Важно знать, что после инициализации мониторов на хостах нельзя менять сетевой адрес, к которому будет привязана служба монитора кластера Ceph. Кластер перестанет быть доступен и работаспособен! Сменить сетевой адрес можно удалив службу монитора и инициализовать ее заново с новыми настройками сети! Будьте внимательны.
Дайте команду для запуска комоненты mgr на сервере <ceph-1-hostname>:
ceph-deploy --username ceph-adm mgr create <ceph-1-hostname>
Запустите команду для перезагрузки серверов Ceph
for ceph_id in $(seq <X> -1 1); do ssh ceph-adm@< ceph- $ceph_id-hostname> sudo reboot; done
Здесь: <X> - количество узлов Ceph.
Запустите команды для создания служб OSD на блочных устройствах /dev/sdb серверов кластера ceph
ceph-deploy --username ceph-adm osd create --data /dev/sdb <ceph-1-hostname>
ceph-deploy --username ceph-adm osd create --data /dev/sdb <ceph-2-hostname>
ceph-deploy --username ceph-adm osd create --data /dev/sdb <ceph-N-hostname>
Для каждой службы OSD рекомендуется предоставлять один физический диск для хранения данных.
Запустите команды для установки утилиты управления кластером Ceph:
ceph-deploy --username ceph-adm install --cli <ceph-1-hostname> <ceph-2-hostname> . <ceph-N-hostname>
ceph-deploy --username ceph-adm install --cli <front-1-hostname> <front-2-hostname> . <front-N-hostname>
ceph-deploy --username ceph-adm install --cli <node-1-hostname> <node-2-hostname> . <node-N-hostname>
Запустите команду для копирования конфигурационного файла и keyring-файла администратора на сервер <ceph-1-hostname>:
ceph-deploy --username ceph-adm admin <ceph-1-hostname>
Запустите команду для проверки кластера Ceph на сервере <ceph-1-hostname>:
Вывод команды должен быть примерно таким:
Запустите команду для отправки конфигурационных файлов на сервера ПК СВ Брест и сервера ceph
ceph-deploy --username ceph-adm config push <ceph-1-hostname> <ceph-2-hostname> . <ceph-N-hostname>
ceph-deploy --username ceph-adm config push <front-1-hostname> <front-2-hostname> . <front-N-hostname>
ceph-deploy --username ceph-adm config push <node-1-hostname> <node-2-hostname> . <node-N-hostname>
Проверка
Следующими командами можно получить информацию по работе служб мониторов на серверах кластера Ceph, команда запускается на сервере <ceph-1-hostname>
sudo ceph mon stat
sudo ceph mon dump
Создание пула для организации и хранения данных
По формуле нужно вычислить необходимое количество PGs для кластера Ceph: Total PGs = ((Total number of OSD * 100) / Max Replication Count) с округлением до ближайшей степени 2 в сторону увеличения . В случае для 3 узлов ceph получится:
(3 OSD * 100) / 3 = 100 и округляем до 128.
На сервере <ceph-1-hostname> используйте следующие команды для создания пула с именем one и включаем возможность подключения к пулу по протоколу rbd :
sudo ceph osd pool create one 128
sudo ceph osd pool application enable one rbd
Будет создан пул one с уровнем репликации равным 3 (значение по-умолчанию).
Создание пользователя и ключей для доступа к пулу кластера Ceph
Создать пользователя кластера Ceph, который будет иметь доступ к пулу one. Данный пользователь будет также использоваться libvirt для доступа к образам дисков:
sudo ceph auth get-or-create client.libvirt mon 'allow rwx' osd 'allow rwx pool=one'
Далее необходимо получить копию ключа данного пользователя для его дальнейшей передачи на сервера ПК СВ Брест:
sudo ceph auth get-key client.libvirt | tee client.libvirt.key
sudo ceph auth get client.libvirt -o ceph.client.libvirt.keyring
Установка ключей на серверы ПК СВ Брест для доступа к данным на кластере Ceph
Скопировать все файлы ключей на все серверы (front-end и узлы виртуализации) и перенести в нужные каталоги следующими командами:
scp ceph.client.libvirt.keyring ceph-adm@<server-hostname>:/tmp
scp client.libvirt.key ceph-adm@<server-hostname>:/tmp
ssh ceph-adm@<server-hostname> "sudo mv /tmp/ceph.client.libvirt.keyring /etc/ceph"
ssh ceph-adm@<server-hostname> "sudo mv /tmp/client.libvirt.key /var/lib/one"
ssh ceph-adm@<server-hostname> "sudo ln -s /var/lib/one/client.libvirt.key /root/client.libvirt.key"
Далее требуется сгенерировать секретный ключ для Ceph пользователя и скопировать его на сервера ПК СВ Брест в каталог /var/lib/one.
Запомнить универсальный уникальный идентификатор (UUID) для дальнейшего использования, команды выполняются на сервере <ceph-1-hostname>:
Скопируйте полученный ключ на каждый сервер облака (front-end и узлы виртуализации):
scp secret.xml ceph-adm@<server-hostname>:/tmp
ssh ceph-adm@<server-hostname> "sudo mv /tmp/secret.xml /var/lib/one"
ssh ceph-adm@<server-hostname> "sudo ln -s /var/lib/one/secret.xml /root/secret.xml"
Установите секретный ключ libvirt и удалите файлы ключа на всех серверах облака (переменная $UUID должна быть определена с предыдущих шагов):
ssh ceph-adm@<server-hostname> "sudo virsh -c qemu:///system secret-define /root/secret.xml"
BASE64=$(cat client.libvirt.key)
ssh ceph-adm@<server-hostname> "sudo virsh -c qemu:///system secret-set-value --secret $UUID --base64 $BASE64"
ssh ceph-adm@<server-hostname> "sudo rm /root/client.libvirt.key"
ssh ceph-adm@<server-hostname> "sudo rm /var/lib/one/client.libvirt.key"
Проверка
Нужно убедиться, что Ceph клиент имеет корректные настройки на серверах ПК СВ Брест, выполнив команду для каждого сервера облака (результатом выполнения команды должен быть пустой вывод без ошибок):
ssh ceph-adm@<server-hostname> "sudo rbd ls -p one --id libvirt"
Установить пакет qemu-block-extra на все серверы облака , выполнив для каждого из них команду:
ssh ceph-adm@<server-hostname> "sudo apt install qemu-block-extra"
Примечание, для установки этого пакета в качестве репозитория необходимо использовать диск для разработчика ОС Astra Linux SE и соответствующее обновление безопасности!
Подключение кластера Ceph в ПК СВ Брест
Создание хранилища system
В меню слева развернуть вкладку "Storage" и выбрать пункт "Datastores", далее перейти в настройки и нажать зеленую кнопку +
На следующей странице справа выбрать вариант настройки "Advanced" и внести конфигурацию хранилища:
NAME - имя хранилища
POOL_NAME - имя пула в кластере Ceph
CEPH_HOST - имена узлов мониторов
BRIDGE_LIST - имена узлов, которые получат доступ к хранилищу
CEPH_SECRET - UUID из файла secret.xml
Нажать кнопку Create. Результат добавления нового хранилища в ПК СВ Брест:
Создание хранилища images
Снова нажать зеленую кнопку +. На следующей странице справа выбрать вариант настройки "Advanced" и внести конфигурацию хранилища:
После чего нажать зеленую кнопку "Create"
Проверка
В результате добавления хранилищ в разделе Storage - Datastores веб-интерфейса должен отображаться объем хранилища Ceph (в примере - 189Гб):
Создание хранилищ из командной строки
Кроме содания хранилищ через веб интерфейс вы можете воспользоваться следующими командами из терминала на front-end, предварительно сформировав файлы описаний system-ds.txt и images-ds.txt:
Создать системное хранилище (CEPH_SECRET значение брать из файла secret.xml):
sudo onedatastore create system-ds.txt
Создать хранилище образов (CEPH_SECRET значение брать из файла secret.xml):
sudo onedatastore create images-ds.txt
После выполнения инструкций данного раздела вернитесь на предыдущую статью
Читайте также: