Ceph proxmox что это
Перейти к содержимому

Ceph proxmox что это

  • автор:

Proxmox. Ceph

Ceph — это распределенное хранилище объектов и файловая система, предназначенная для обеспечения отличной производительности, надежности и масштабируемости.

Proxmox VE объединяет вычислительные системы и системы хранения. Это позволяет локальные хранилища (диски) объединять в одно гиперконвергентное устройство. Благодаря интеграции Ceph, Proxmox VE имеет возможность запускать и управлять хранилищем Ceph непосредственно на узлах гипервизора.

По сути получаем вместо SAN или NAS хранилищ объединенное распределенное отказоустойчивое гиперконвергентное устройство (хранилище).

Данная технология реализована у VMware (VMware Virtual SAN) и Microsoft (Storage Spaces Direct).

Познакомиться с Ceph можно в этой статье: Знакомство с хранилищем Ceph в картинках.

Установка Ceph

Установим на всех нодах кластера:

Определим сети и назначим ноду монитора:

Готово. Установим на остальных нодах. Поскольку конфигурация в кластере уже установлена вместе с первой нодой, на остальных нодах этого не потребуется.

Если необходимо можно создать дополнительные мониторы:

На всех нодах добавляем диски в OSD:

И создаем Metadata Server:

Создаем хранилище в кластере CephFS:

CephFS – поддерживает тип хранилищ ISO images, VZDump backup, Container template, Snippets.

Для размещения дисков виртуальных машин и контейнеров нужно создать RDB Storage.

Далее добавим еще один сервер монитор и Metadata Server.

Создаем виртуальную машину или контейнер с размещением на Ceph (RDB) и тестируем работоспособность, возможность миграции между нодами.

Пример: Создан контейнер с веб сайтом (phpBB) на PVE3 с размещением на Ceph (RDB) диске. Создан ресурс высокой доступности (HA Resource) на контейнер. После выключаем ноду PVE3.

Результат. Контейнер мигрировал на рабочую ноду, сохранив работоспособность, Ceph деградировал, но сохранил работоспособность.

Восстановим работоспособность PVE3 и проверим данные.

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

Ceph в ProxMox на ZFS

В своей работе (системный администратор) приходится всегда искать вещи и знания, уникальные для своего региона. Одной из таких вещей в нашей конторе является ProxMox, поставленный на файловой системе ZFS, позволяющей использовать неплохой raid массив без использования железных контроллеров. Однажды, думая, чем можно еще удивить и порадовать клиентов, мы решили всё это водрузить на распределенную файловую систему Ceph. Не знаю уж, насколько было такое решение адекватным, но я решил воплотить желание в жизнь. И тут понеслась… Я перелопатил горы статей и форумов, но так и не нашел одного адекватного мануала, описывающего в подробностях что и как делать, поэтому, справившись со всем, родилась эта статья, кому интересно, добро пожаловать под кат.

image

Итак, в принципе, всё делается в консоли и веб-морда ProxMox нам особо не нужна. Делал я всё в тестовом режиме, поэтому было поднято две виртуалки с четырьмя дисками внутри не очень мощного по железу проксмокса (этакая матрёшка). Четыре диска изначально были обусловлены тем, что хотелось поднять, как и на будущем уже не тестовом железе, на ZFS10, но не вышла золотая рыбка по неведомым мне причинам (на самом деле, было лень разбираться). Вышло так, что ProxMox не смог разметить ZFS10 на виртуальных дисках, поэтому было решено использовать немного другую “географию”. На одном из дисков ставился собственно сам ProxMox, на двух других поднимался ZFS1, третий был якобы под журнал Ceph, но я в итоге про него забыл, поэтому пока оставим его в покое. Итак, приступим.

Тут будет небольшая вводная:

Проксмокс у нас свежеустановленный в двух местах. Ноды называются ceph1 и ceph2. Делаем на обеих нодах всё одинаково, кроме тех мест, что я обозначу. Сеть у нас 192.168.111.0/24. Первая нода (ceph1) имеет адрес 192.168.111.1, вторая (ceph2) — 192.168.111.2. Диски на обеих нодам имеют следующие значения: /dev/vda — диск, на котором стоит ProxMox, /dev/vdb и /dev/vdc — диски, предназначенные для ZFS, /dev/vdd — диск для журнала Ceph.

Первое, что нам нужно сделать, это поменять платный репозиторий ProxMox, требующий подписки, на бесплатный:

nano /etc/apt/sources.list.d/pve-enterprise.list

Там комментируем единственную строку и вписываем новую ниже:

deb http://download.proxmox.com/debian jessie pve-no-subscription

Далее обновляем наш ProxMox:

apt update && apt dist-upgrade

Устанавливаем пакеты для работы с Ceph:

pveceph install -version hammer

Следующим шагом нам нужно сделать кластер из проксмоксов.

На первой ноде выполняем последовательно:

pvecm create mycluster

где mycluster — это имя нашего кластера.

pvecm add 192.168.111.1

Соглашаемся с тем, что нужно принять ssh ключ и вводим пароль root от первой ноды.

Проверяем всё это дело командой pvecm status

Далее инициализуруем конфигурацию Ceph (делается только на первой ноде, которая будет “главной”):

pveceph init --network 192.168.111.0/24

это создаст нам симлинк на /etc/ceph/ceph.conf, от которого мы будем далее отталкиваться.

Сразу после этого нам надо добавить туда опцию в раздел [osd]:

[osd] journal dio = false

Это связано с тем, что ZFS не умеет directIO.

Следующее, чем делаем, это готовим наш ZFS пул. Для этого диски нужно разметить в GPT:

fdisk /dev/vdb

Там последовательно нажимаем g и w (g для создания таблицы GPT и w для принятия изменений). То же самое повторяем на /dev/vdc.

Создаем зеркальный ZFS пул, называться он у нас будет как принято в ProxMox – rpool:

zpool create rpool mirror /dev/vdb /dev/vdc

Проверим командой zpool status -v и получим (по крайней мере должны):

pool: rpool state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM rpool ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 vdb ONLINE 0 0 0 vdc ONLINE 0 0 0 errors: No known data errors

ZFS пул у нас создан, пришло самое время заняться самым главным — ceph.

Создадим файловую систему (странное название, но оно взято с доки по ZFS) для нашего монитора Ceph:

zfs create -o mountpoint=/var/lib/ceph/mon rpool/ceph-monfs

Создадим сам монитор (сначала на первой ноде, потом на второй):

pveceph createmon

Далее начинается то, с чем пришлось повозиться, а именно то, как сделать блочное устройство для Ceph OSD (а он именно с ними и работает) в ZFS и чтобы оно еще и работало.

А делается всё просто — через zvol:

zfs create -V 90G rpool/ceph-osdfs

90G — это то, сколько мы отдаем нашему Ceph на растерзание. Так мало потому, что сервер виртуальный и больше 100G я ему не давал.

Ну и сделаем сам Ceph OSD:

ceph-disk prepare --zap-disk --fs-type xfs --cluster ceph --cluster-uuid FSID /dev/zd0

—fs-type у нас выбран XFS потому, что XFS — это дефолтная ФС у Ceph. FSID — это ID нашего Ceph, который можно подсмотреть в /etc/ceph/ceph.conf. Ну, и /dev/zd0 — это наш zvol.

Если после этого у вас df -h не покажет примерно такое:

/dev/zd0p1 85G 35M 85G 1% /var/lib/ceph/osd/ceph-0

значит что-то пошло не так и вам либо нужно перезагрузиться, либо ещё раз нужно выполнить создание ceph OSD.

В общем то, на этом мы уже сделали наш ceph и можно дальше им рулить уже в вебморде ProxMox и создать на нем нужное RDB хранилище, но вы не сможете его использовать (собственно, ради чего всё это затевалось). Лечится простым способом (для этого всё-таки хранилище надо создать) — нужно скопировать ключ ceph с первой ноды во вторую.

Открываем конфиг хранилищ ProxMox:

nano /etc/pve/storage.cfg

И вписываем туда нужный нам RBD:

rbd: test monhost 192.168.111.1:6789;192.168.111.2:6789 pool rbd krbd 1 username admin content images

Здесь test — это имя нашего хранилища, а IP адреса — это то, где находятся ceph мониторы, то есть наши проксмоксы. Остальные опции дефолтные.

Дальше создаем папочку для ключа на второй ноде:

mkdir /etc/pve/priv/ceph

И копируем ключ с первой:

scp ceph1:/etc/ceph/ceph.client.admin.keyring /etc/pve/priv/ceph/test.keyring

Здесь ceph1 — наша первая нода, а test — имя хранилища.

На этом можно ставить точку — хранилище активно и работает, можем пользоваться всеми плюшками ceph.

Спасибо за внимание!

Для того, чтобы всё это поднять, пользовался данными ссылками:

Proxmox-репликация

Относительно недавно для клиентов нашей компании стала доступна к автоматической установке система виртуализации Proxmox . Предварительно мы тестировали качество предоставления подобной услуги и параллельно разбирались, как администрируется Proxmox. Своим опытом я бы хотел поделиться в небольшой серии статей. Начну с того, как выполнить репликацию Proxmox.

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

Арендуйте выделенные и виртуальные GPU серверы с профессиональными графическими картами NVIDIA RTX A5000 / A4000 в надежных дата-центрах класса TIER III в Москве и Нидерландах. Принимаем оплату за услуги HOSTKEY в Нидерландах в рублях на счет российской компании. Оплата с помощью банковских карт, в том числе и картой МИР, банковского перевода и электронных денег.

Предварительные настройки и подключение к серверу

Перед началом процедуры репликации необходимо провести ряд настроек и подключиться к первому серверу: Шаг 1. В панели управления перейти в раздел “Cluster” и нажать кнопку “Create Cluster”: Шаг 2. Ввести название кластера и сеть (или список подсетей) для стабильной работы кластера. После чего нажать на кнопку “Create”: Шаг 3. В разделе “Cluster” перейти во вкладку “Join information” и скопировать информацию из окна “Join information”, данная информация нужна для подключения второго сервера к кластеру: Шаг 4. На втором сервере в разделе “Cluster” перейти во вкладку “Join Cluster”: И ввести информацию для подключения, скопированную на предыдущем шаге: Задаем пароль (root) и IP-адрес сервера для подключения, после чего нажимаем на кнопку “Join-имя кластера”: Шаг 5. Дождаться подключения к кластеру:

Создание ZFS-раздела для настройки репликации виртуального сервера

В нашем сервере установлено два диска: на первом установлена система, второй предназначен для размещения виртуальных серверов, которые будут поставлены на репликацию на аналогичный физический сервер. Необходимо зайти на физический сервер по SSH и ввести команду lsblk. В примере ниже видно, что у нас имеется неразмеченный диск /sdb. Его мы и будем использовать для размещения серверов и настройки репликации: В основном окне управления серверами необходимо выбрать физический сервер и создать раздел ZFS: В открывшемся окне необходимо ввести имя раздела в строке “Name”. Меню “Create:ZFS” разделено на несколько функциональных блоков: с правой стороны можно настроить RAID, а ниже выбрать диски для объединения в RAID-группу. Важно обратить внимание на сообщение: “Note: ZFS is not compatible with disks backed by a hardware RAID controller”. Согласно рекомендации (на экран будет выведена ссылка на документацию) диски для ZFS должны быть презентованы в систему в обход аппаратного RAID-контроллера. После выполнения настроек необходимо завершить добавление диска — нажать кнопку “Create”: В результате настроена дисковая подсистема на физических серверах: После выполнения перечисленных настроек можно приступать к установке виртуального сервера. Для этого можно использовать нашу инструкцию.

Настройка репликации

В основном окне управления серверами необходимо выбрать виртуальный сервер, который необходимо поставить на репликацию, в нашем случае он находится на физическом сервере “prox1”, имя виртуального сервера “100 (CentOS 7)”. Шаг 1. Перейти в раздел “Replication” и нажать на кнопку “Add”: Шаг 2. В открывшемся окне необходимо указать физический сервер, на который будет проводиться репликация, а также репликации: Результат успешной настройки репликации можно увидеть, выбрав нужный физический сервер и нажав на кнопку “Replication”. С правой стороны будут видны серверы, поставленные на репликацию, время репликации, текущий статус.

Работа репликации

Настройка кластера и репликации из двух серверов без общего диска хороша лишь в том случае, когда не происходит сбоев, и в момент запланированных работ можно просто переключить виртуальный сервер, нажав на его название правой кнопкой мыши и выбрав пункт “Migrate”. В случае же выхода из строя одного из физических серверов, когда их только два, переключение не произойдет. Придется восстанавливать виртуальный сервер вручную. Поэтому ниже мы привели пример более стабильного и надежного решения в виде кластера из трех серверов. Добавление третьего сервера происходит согласно описанным шагам по добавлению физического сервера в кластер. Информация по дискам:

  1. data_zfs — на каждом сервере создан раздел zfs для настройки репликации виртуальных серверов;
  2. local — установлена система;
  3. pbs — Proxmox Backup Server;
  4. rbd — Ceph-распределенная файловая система.

Информация по настройке сети:

  1. Public network — предназначена для управления серверами Proxmox, также необходима для работы виртуальных серверов;
  2. Cluster Network — служит для синхронизации данных между серверами, а также миграции виртуальных серверов в случае выхода из строя физического сервера (сетевой интерфейс должен быть не менее 10G).

Пример настройки в тестовой среде:

После сборки кластера из трех серверов можно настроить репликацию на 2 сервера. Таким образом, в миграции будет участвовать три физических сервера. В нашем случае репликация настроена на серверы prox2, prox3:

Для включения режима “HA” (высокая доступность, миграция виртуального сервера) на виртуальных серверах, необходимо щелкнуть на “Datacenter”, с правой стороны выбрать пункт “HA” и в нём нажать на кнопку “Add”:

В открывшемся окне, в выпадающем списке “VM”, выбрать все серверы, на которых необходимо включить “HA” и нажать на кнопку “Add”:

Пример успешного добавления:

Также можем проверить, что режим “HA” включен на самом виртуальном сервере, для этого необходимо кликнуть на нужный виртуальный сервер (в нашем случае — CentOS7) и с правой стороны выбрать раздел “Summary”.

В нашем примере режим “HA” запущен и работает, можно отключить первый сервер и проверить миграцию VM на один из доступных физических серверов:

Проверка работы HA в случае выхода из строя сервера

После корректной настройки репликации виртуального сервера мы можем протестировать работу кластера. В нашем случае мы отключили все сетевые порты на физическом сервере prox1. Спустя некоторое время (в нашем случае — 4 минуты) происходит переключение виртуального сервера CentOS 7, и к нему можно получить доступ по сети.

Пример проверки результата переключения и доступности сервера:

В результате этого этапа был настроен кластер из трех серверов, внутренних дисков с ZFS и параметром “HA” на виртуальном сервере.

Переключение виртуального сервера с одного физического сервера на другой

Для переключения виртуального сервера с одного физического сервера на другой необходимо выбрать нужный сервер и щелкнуть на нем правой кнопкой мыши. В открывшемся меню необходимо выбрать пункт “Migrate”:

После нажатия на кнопку “Migrate” откроется окно, в котором можно выбрать сервер, на который мы планируем мигрировать наш виртуальный сервер, выбираем сервер и нажимаем “Migrate”:

Статус миграции можно отследить в окне “Task”:

После успешного завершения миграции в окне “Task” будет выведено сообщение “TASK OK”:

Также мы увидим, что наш виртуальный сервер был перенесен на сервер prox3:

Тестирование работы Ceph

В интернете очень просто найти много материалов по установке Ceph на Proxmox, поэтому мы коротко опишем только шаги установки. Для установки Ceph необходимо выбрать один из физических серверов, выбрать раздел “Ceph” и нажать на кнопку “Install Ceph”:

Версия Ceph указана по умолчанию. Необходимо нажать кнопку “Start nautilus installation”, после установки система попросит указать настройки сети. В нашем случае настройка проводилась с первого сервера и в качестве примера указаны его IP-адреса:

Нажимаем кнопки “Next” и “Finish” для завершения установки. Конфигурация выполняется только на первом сервере, и на два других сервера она будет перенесена системой автоматически.

Затем необходимо настроить:

  1. Monitor — роль координатора, обмен информации между серверами, желательно создавать нечетное количество, чтобы избежать ситуации (split-brain). Мониторы работают в кворуме: если упадет больше половины мониторов, кластер будет заблокирован для предотвращения рассогласованности данных;
  2. OSD — юнит хранилища (как правило — диск), который хранит данные и обрабатывает запросы клиентов, обмениваясь данными с другими OSD. Обычно за каждый OSD отвечает отдельный OSD-демон, который может запускаться на любой машине, на которой установлен этот диск;
  3. Pool — пул, объединяющий OSD. Будет использоваться для хранения виртуальных дисков серверов.

Затем необходимо выполнить добавление серверов с ролью “Monitor” и “Manager”. Для этого необходимо кликнуть на название физического сервера, перейти в раздел “Monitor”, пункт “Create”, и выбрать серверы, объединенные в кластер. И добавить их поочередно:

Аналогичные действия необходимо провести с серверов с ролью “Manager”. Для корректной работы кластера необходимо более одного сервера с этой ролью.

Добавление дисков OSD происходит аналогично:

Согласно рекомендации (на экран будет выведена ссылка на документацию) диски должны быть презентованы в систему в обход аппаратного RAID-контроллера. Использование аппаратного RAID-контроллера может негативно повлиять на стабильность и производительность реализации Ceph.

Пример настроенного Ceph (на всех трёх серверах диск /dev/sdc):

Последний шаг настройки Ceph — создание пула, который в дальнейшем будет указываться при создании виртуальных серверов. Для этого необходимо кликнуть на название физического сервера, перейти в раздел “Pools” и выполнить следующие настройки:

Описание значений использованных параметров:

Если size=3 и min_size=2, то все будет хорошо, пока работают две из трех OSD плейсмент-групп. Если останется один OSD, кластер заморозит операции данной группы, пока не “оживет” хотя бы еще один OSD.

Если size=min_size, то плейсмент-группа будет блокироваться при падении любого OSD, входящего в ее состав. Из-за высокого уровня “размазанности” данных большинство падений хотя бы одного OSD будет заканчиваться заморозкой всего или почти всего кластера. Поэтому параметр “Size” всегда должен быть хотя бы на один пункт больше параметра “Min_Size”.

Если Size=1, кластер будет работать, но поломка любой OSD будет означать безвозвратную потерю данных. Ceph позволяет выставить значение этого параметра, равное единице, но даже если администратор делает это с определенной целью и на короткое время, он берет на себя ответственность за возможные неполадки.

Pool (rbd), который мы создали выше, используется при создании виртуальной машины. В разделе “Disks” на нем будут располагаться диски наших виртуальных серверов:

Заключение

Наша инструкция позволяет выполнить настройку репликации Proxmox без лишних проблем, предлагаемый метод основан как на документации Proxmox, так и на нашем опыте работы с этой системой виртуализации. Proxmox-репликация предоставляет возможность обеспечить более высокую безопасность данных, так как позволяет сделать резервную копию данных на другом сервере. Таким образом, вы можете быть уверены, что данные будут всегда доступны и защищены. Также хотели бы обратить внимание: в момент тестирования надежную и стабильную работу показал кластер, включающий три сервера. В случае же реализации кластера из двух серверов и локальных дисков кластер не отрабатывал корректно и автоматическое переключение в случае выхода из строя одного из серверов не происходило. Ceph мы настраивали в качестве тестов и не использовали его в продуктовой среде.

Арендуйте выделенные и виртуальные GPU серверы с профессиональными графическими картами NVIDIA RTX A5000 / A4000 в надежных дата-центрах класса TIER III в Москве и Нидерландах. Принимаем оплату за услуги HOSTKEY в Нидерландах в рублях на счет российской компании. Оплата с помощью банковских карт, в том числе и картой МИР, банковского перевода и электронных денег.

Администрирование и не только

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

Страницы

вторник, 5 ноября 2019 г.

Руководство администратора Proxmox VE R 6.0 Глава 4.

  • Администрирование host системы
  • Оглавление
  • Графический интерфейс пользователя

Гиперконвергентная инфраструктура

  1. Преимущества гиперконвергентной инфраструктуры (HCI) с Proxmox VE
  2. Управление службами Ceph на узлах Proxmox VE
    1. Предварительное условие
    2. Начальная установка и настройка Ceph
    3. Установка пакетов Ceph
    4. Создание начальной конфигурации Ceph
    5. Создание Ceph мониторов
    6. Создание Ceph Manager
    7. Создание Ceph OSD
    8. Создание Ceph Пулов
    9. Ceph CRUSH и классы устройств
    10. Ceph Client
    11. CephFS
    12. Cephю Мониторинг и устранение неполадок

    Преимущества гиперконвергентной инфраструктуры (HCI) с Proxmox VE

    • Масштабируемость: плавное расширение вычислительных, сетевых и запоминающих устройств (т. е. быстрое и независимое масштабирование серверов и хранилищ).
    • Низкая стоимость: Proxmox VE является ПО с открытым исходным кодом и объединяет все необходимые компоненты, такие как вычислительные ресурсы, хранилище, сеть, резервное копирование и Центр управления. Он может заменить дорогостоящую вычислительную инфраструктуру / инфраструктуру хранения данных.
    • Защита данных и эффективность: интегрированы такие службы, как резервное копирование и аварийное восстановление.
    • Простота: простота настройки и централизованное администрирование.
    • Открытый исходный код: • Отсутствие блокировки со стороны поставщика

    Управление службами Ceph на узлах Proxmox VE

    Proxmox VE объединяет ваши вычислительные системы и системы хранения, т.е. вы можете использовать одни и те же физические узлы в кластере как для вычислений (обработка виртуальных машин и контейнеров), так и для реплицированного хранилища. Традиционные хранилища вычислительных и запоминающих ресурсов могут быть объединены в одно гиперконвергентное устройство. Отдельные сети хранения (SANs) и подключения через сетевые хранилища (NAS) исчезают. Благодаря интеграции Ceph, программной платформы хранения с открытым исходным кодом, Proxmox VE имеет возможность запускать и управлять хранилищем Ceph непосредственно на узлах гипервизора.
    Ceph — это распределенное хранилище объектов и файловая система, предназначенная для обеспечения отличной производительности, надежности и масштабируемости.

    • Простая настройка и управление с поддержкой CLI и GUI
    • Тонкая настройка
    • Поддержка снапшотов
    • Самовосстановление
    • Масштабируемость до уровня эксабайт
    • Настройка пулов с различными характеристиками производительности и резервирования
    • Данные реплицируются, что делает их отказоустойчивыми
    • Работает на бюджетном оборудовании
    • Нет необходимости в аппаратных RAID контроллерах
    • Открытый исходный код
    • Ceph Monitor (ceph-mon)
    • Ceph Manager (ceph-mgr)
    • Ceph OSD (ceph-osd; Object Storage Daemon)
    Предварительное условие

    Для построения гиперконвергентного кластера Proxmox + Ceph должно быть как минимум три (желательно) одинаковых сервера для установки.
    Проверьте также рекомендации с веб-сайта Ceph.

    CPU
    Более высокая частота ядра процессора уменьшает задержки и является предпочтительной. В качестве простого практического правила вы должны назначить ядро (или поток) процессора каждому сервису Ceph, чтобы обеспечить достаточно ресурсов для стабильной и надежной работы Ceph.

    Память
    Особенно в гиперконвергентной установке, потребление памяти необходимо тщательно контролировать. В дополнение к предполагаемой рабочей нагрузке от виртуальных машин и контейнера, Ceph требуется достаточно памяти, чтобы обеспечить хорошую и стабильную производительность. Как правило, для примерно 1 TiB данных, 1 GiB памяти будет использоваться OSD. Кэширование OSD будет использовать дополнительную память.

    Сеть
    Мы рекомендуем пропускную способность сети, которая используется исключительно для Ceph не менее 10 GbE или более. Ячеистая топология сети 2 также является выходом, если нет доступных коммутаторов 10 GbE. Объем трафика, особенно во время восстановления, будет мешать другим службам в той же сети и может даже разрушить стек кластера Proxmox VE. Кроме того, оцените свои потребности в пропускной способности. В то время как один жесткий диск может не насыщать канал 1 Гб, несколько жестких дисков на узле могут, а современные накопители SSD NVMe даже быстро насыщают пропускную способность 10 Gbps. Развертывание сети, способной к еще большей пропускной способности, гарантирует, что это не ваше узкое место и не будет в ближайшее время, возможно 25, 40 или даже 100 Gbps.

    Диски
    При планировании размера кластера Ceph важно учитывать время восстановления. Особенно с небольшими кластерами, восстановление может занять много времени. Рекомендуется использовать твердотельные накопители вместо жестких дисков в небольших установках, чтобы сократить время восстановления, минимизируя вероятность последующего сбоя во время восстановления.
    В целом SSD накопители обеспечивают больше операций ввода-вывода, чем вращающиеся диски. Этот факт и более высокая стоимость могут сделать привлекательным разделение пулов на основе классов устройств (см раздел 4.2.9). Другая возможность ускорить OSD — использовать более быстрый диск для журнала или DB/Write-Ahead-Log устройства (см. раздел Ceph OSD.) Если для нескольких операционных систем используется более быстрый диск, необходимо выбрать правильный баланс между OSD и Wal/DB (или журнальным) диском, в противном случае более быстрый диск становится узким местом для всех связанных операционных систем. Помимо типа диска, Ceph лучше всего работает с равномерным распределением размеров и количества дисков на узел. Например, 4 х 500 ГБ дисков с в каждом узле лучше, чем смешанная установка с одним 1 ТБ и три 250 ГБ диска.
    Также необходимо сбалансировать количество OSD и емкость одного OSD. Большая емкость позволяет увеличить плотность хранения, но это также означает, что сбой одного OSD сразу заставляет ceph восстанавливать большее количество данных.

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

    Начальная установка и настройка Ceph

    С Proxmox VE вы можете воспользоваться простым в использовании мастером установки Ceph. Щелкните на одном из узлов кластера и перейдите к разделу Ceph в дереве меню. Если пакет еще не установлен, вам будет предложено сделать это сейчас.

    Мастер разделен на различные разделы, каждый из них должен быть успешно завершен, чтобы использовать Ceph. После запуска установки мастер загрузит и установит все необходимые пакеты из репозитория Ceph Proxmox VE.

    После завершения первого шага, вам нужно будет создать конфигурацию. Этот шаг необходим только один раз для каждого кластера, поскольку эта конфигурация автоматически распространяется среди всех остальных узлов кластера через файловую систему конфигурации кластера Proxmox VE (pmxcfs), глава 7.

    • Публичная сеть: Вы должны настроить выделенную сеть для Ceph, этот параметр является обязательным. Отделение вашего трафика Ceph настоятельно рекомендуется, потому что это может привести к проблемам с другими зависимыми от задержки службами, например, взаимодействие узлов кластера может снизить производительность Ceph, если этого не сделано.
    • Сеть кластера: В качестве дополнительного шага вы можете пойти еще дальше и отделить трафик репликации разделов OSD (см. 4.2.7) и heartbeat трафик. Это облегчит работу общедоступной сети и может привести к значительному повышению производительности, особенно в больших кластерах.

    У вас есть еще два варианта, которые считаются расширенными и поэтому должны изменяться только в том случае, если вы являетесь экспертом.

    • Количество реплик: Определяет частоту репликации объекта.
    • Минимальное количество реплик: Определяет минимальное количество требуемых реплик для I/O, помеченных как завершенные.

    Вот и все, вы должны увидеть сообщение об успешном окончании установки в качестве последнего шага, с инструкциями о дальнейших действиях. Теперь вы готовы начать использовать Ceph, дальше вам нужно будет создать дополнительные мониторы (см. раздел 4.2.5), создать несколько OSD (см. раздел 4.2.7) и по крайней мере один пул (см. раздел 4.2.8).

    Установка пакетов Ceph

    Используйте мастер установки Proxmox VE Ceph (рекомендуется) или выполните следующую команду на каждом узле:

    pveceph install
    Создание начальной конфигурации Ceph

    Используйте мастер установки Proxmox VE Ceph (рекомендуется) или выполните следующую команду на одном узле:

    pveceph init --network 10.10.10.0/24
    Создание Ceph мониторов

    Ceph Monitor (MON) 3 поддерживает главную копию карты кластера. Для высокой доступности необходимо иметь не менее 3 мониторов. Один монитор уже был установлен, если вы использовали мастер установки. Вам не понадобится более 3 мониторов, пока ваш кластер мал до среднего размера, только действительно большие кластеры требуют большего количества.

    На каждом узле, где вы хотите разместить монитор (рекомендуется три монитора), создайте его с помощью вкладки Ceph → Monitor в графическом интерфейсе или запустите. 

    pveceph createmon
    Создание Ceph Manager

    Manager daemon работает рядом с мониторами, обеспечивая интерфейс для мониторинга кластера. С момента выпуска Ceph luminous демон ceph-mgr 4 обязателен. Во время установки монитора также будет установлен Ceph manager. 3 Ceph Monitor http://docs.ceph.com/docs/luminous/start/intro/
    4 Ceph Manager http://docs.ceph.com/docs/luminous/mgr/ Примечание Рекомендуется установить Ceph Manager на узлах, где установлены мониторы. Для обеспечения высокой доступности установите более одного менеджера.

    pveceph createmgr
    Создание Ceph OSD

    Используя GUI или с помощью коммандной строки следующим образом:

    pveceph createosd /dev/sd[X]

    Совет Мы рекомендуем размер кластера Ceph, начиная с 12 OSD, равномерно распределенных между вашими, по крайней мере, тремя узлами (4 OSD на каждом узле). Если диск использовался ранее (например, ZFS/RAID/OSD), для удаления таблицы разделов, загрузочного сектора и всех оставшихся OSD должна быть достаточно следующей команды.

    ceph-volume lvm zap /dev/sd[X] --destroy

    Внимание! Приведенная выше команда уничтожит данные на диске! Ceph Bluestore

    Начиная с выпуска Ceph Kraken, был представлен новый тип хранилища ceph OSD, так называемый Bluestore 5 . Это значение по умолчанию при создании OSD начиная с Ceph Luminous.

    pveceph createosd /dev/sd[X]

    Block.db и block.wal

    Если вы хотите использовать отдельное устройство DB/WAL для ваших OSD, вы можете указать его с помощью параметров -db_dev и -wal_dev . WAL помещается вместе с DB, если не указано отдельно.

    pveceph createosd /dev/sd[X] -db_dev /dev/sd[Y] -wal_dev /dev/sd[Z]
    • bluestore_block__size from ceph configuration.
      • . database, section osd
      • . database, section global
      • . file, section osd
      • . file, section global

      До Ceph Luminous, тип Ceph Filestore использовался в качестве хранилища по умолчанию для Ceph машин. Начиная с Ceph Nautilus, Proxmox VE больше не поддерживает создание таких OSD с pveceph. Если вы все же хотите создать filestore OSD, используйте непосредственно ceph-volume .

      ceph-volume lvm create --filestore --data /dev/sd[X] --journal /dev/sd[Y]
      Создание Ceph Пулов

      Пул-это логическая группа для хранения объектов. Он содержит группы размещения (PG, pg_num), набор объектов.

      Если параметры не заданы, используется значение по умолчанию 128PG, size 3 реплики и min_size 2 реплики для обслуживания объектов в случае деградации пула. Примечание Количество PG по умолчанию подходит для 2-5 дисков. Ceph выдает предупреждение HEALTH_WARNING, если у вас слишком мало или слишком много PG в вашем кластере. Рекомендуется рассчитать число PG в зависимости от ваших настроек, в интернете вы можете найти формулу и онлайн PG калькулятор 6 . Количество PG может быть увеличено позже, но оно никогда не может быть уменьшено.

      Вы можете создавать пулы с помощью графического интерфейса на каждом PVE узле в Ceph → Pools или командной строки.

      pveceph createpool
      Ceph CRUSH и классы устройств

      Фундамент Ceph — это его алгоритм «Controlled Replication Under Scalable Hashing» (CRUSH 8 ).

      CRUSH вычисляет, где хранить и откуда извлекать данные, преимуществом этого подхода является то, что не требуется централизованная служба индексирования. CRUSH работает с картой OSD, сегментов (расположения устройств) и наборов правил (репликация данных) для пулов.
      Примечание Дополнительную информацию можно найти в документации Ceph, в разделе CRUSH map a . a CRUSH map http://docs.ceph.com/docs/luminous/rados/operations/crush-map/ 8 CRUSH https://ceph.com/wp-content/uploads/2016/08/weil-crush-sc06.pdf Эта карта может быть изменена для отражения различных иерархий репликации. Реплики объектов могут быть разделены (например отказ доменов), сохраняя при этом желаемое распределение. Общим вариантом использования является использование различных классов дисков для разных пулов Ceph. По этой причине Ceph ввел классы устройств с версии luminous, чтобы удовлетворить потребность в простом создании набора правил.

      Классы устройств можно увидеть в выходных данных ceph osd tree. Эти классы представляют свои собственные корневые сегменты, которые можно увидеть с помощью приведенной ниже команды.

      ceph osd crush tree —show-shadow

      Пример вывода формы приведенной выше команды:

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

      ceph osd crush rule create-replicated

      Имя правила, для соединения с пулом (видно в GUI и командной строке)
      К какому корневому каталогу он должен принадлежать (по умолчанию ceph root «default»)
      Тип узлов CRUSH (не путать с понятием узлов PVE), через которые мы должны разделять реплики. (обычно хост)
      Какой тип OSD резервного хранилища использовать (например nvme, ssd, hdd)

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

      ceph osd pool set crush_rule
      Ceph Client

      Затем можно настроить Proxmox VE для использования таких пулов для хранения образов виртуальных машин или контейнеров. Просто используйте графический интерфейс, чтобы добавить новое хранилище RBD (см. раздел Ceph RADOS Block Devices (RBD) раздел 8.14).

      Вам также необходимо скопировать связку ключей в предопределенное расположение для внешнего кластера Ceph. Если Ceph установлен на узлах Proxmox, то это будет сделано автоматически. Примечание Имя файла должно быть + ‘.keyring’ — — это выражение после rbd: в /etc/pve/storage.cfg , который является my-ceph-storage в следующем примере:

      mkdir /etc/pve/priv/ceph cp /etc/ceph/ceph.client.admin.keyring /etc/pve/priv/ceph/my-ceph-storage.keyring
      CephFS

      Ceph также предоставляет файловую систему, работающую поверх того же хранилища объектов, что и блочные устройства RADOS. Сервер метаданных (MDS) используется для сопоставления объектов, поддерживаемых RADOS, с файлами и каталогами, что позволяет обеспечить реплицированную файловую систему, совместимую с POSIX. Это позволяет иметь кластерную высокодоступную общую файловую систему простым способом (если ceph уже настроен). Его серверы метаданных гарантируют, что файлы будут равномерно распределены по всему кластеру Ceph, таким образом, что даже высокая нагрузка не будет перегружать один хост, что может быть проблемой при использовании общих файловых систем с традиционным подходом, например таких, как NFS.

      Proxmox VE поддерживает оба варианта, используя существующую CephFS в качестве хранилища (см. раздел 8.15) для сохранения резервных копий, ISO-файлов или шаблонов контейнеров и создавая гиперконвергентную CephFS.

      Сервер метаданных (MDS)

      Для функционирования CephFS необходим как минимум один сервер метаданных, который должен быть настроен и запущен. Можно просто создать его через узел Proxmox VE web GUI -> панель CephFS или в командной строке с помощью:

      pveceph mds create

      В кластере можно создать несколько серверов метаданных. Но с настройками по умолчанию только один единовременно может быть активным. Если MDS или его узел перестает отвечать на запросы (или аварийно завершает работу), другой резервный MDS будет активирован. Можно ускорить передачу обслуживания между активным и резервным MDS помощью опции hotstandby при создании MDS, или если вы его уже создали его, вы можете установить/добавить:

      mds standby replay = true

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

      Несколько активных MDS

      Начиная с Ceph Luminous (12.2.x), вы также можете использовать несколько активных серверов метаданных, но это обычно полезно только для большого количества параллельных клиентов, так как в противном случае MDS редко является узким местом. Если вы все же хотите настроить их, пожалуйста, обратитесь к документации ceph 9 .

      CephFS интегрирована в Proxmox VE и вы можете легко создавать CephFS через веб-интерфейс, интерфейс командной строки или внешний API. Для этого требуются некоторые предварительные условия:

      • Установка пакетов Ceph (см. раздел 4.2.3), если это уже было сделано некоторое время назад, вы можете повторно запустить его в обновленной системе, чтобы убедиться, что также установлены все пакеты, связанные с CephFS.
      • Установлены Мониторы. (см. Раздел 4.2.5)
      • Настроены ваши OSD. (см. Раздел 4.2.7)
      • Настроен хотябы один MDS. (см. Раздел 4.2.11)
      pveceph fs create --pg_num 128 --add-storage

      При этом создастся CephFS с именем ‘cephfs’, использующая пул с именем ‘cephfs_data’ для своих данных с ‘128’ группами размещения и пул для метаданных с именем ‘cephfs_metadata’ с одной четвертью групп размещения пула данных (’32’). Обратитесь к разелу 4.2.8 «Настройка Ceph пула Proxmox VE» или документации Ceph для получения дополнительной информации о подходящем значении параметра «количество групп размещения» (pg_num) 10 для вашей настройки. Кроме того, параметр «add-storage», после успешного создания CephFS добавит новое хранилище в конфигурацию хранилища Proxmox VE. 9 Настройка нескольких активных демонов MDS http://docs.ceph.com/docs/luminous/cephfs/multimds/
      10 Ceph Placement Groups http://docs.ceph.com/docs/luminous/rados/operations/placement-groups/ Удаление CephFS

      Внимание! Уничтожение CephFS сделает все его данные непригодными для использования, и может быть отменено! Если вы действительно хотите уничтожить существующий CephFS, вам сначала нужно остановить или уничтожить все сервера метаданных (MDS). Вы можете уничтожить их либо через веб-интерфейс или интерфейс командной строки, с помощью:

      pveceph mds destroy NAME

      на каждом узле Proxmox VE, где размещается демон MDS.

      Затем вы можете удалить (уничтожить) CephFS, выполнив:

      ceph fs rm NAME --yes-i-really-mean-it

      на одном из узлов, где запущен Ceph. После этого вы можете удалить созданные пулы данных и метаданных, это можно сделать либо через веб-интерфейс пользователя, либо с помощью интерфейса командной строки:

      pveceph pool destroy NAME
      Ceph Мониторинг и устранение неполадок

      Хорошей практикой является непрерывный мониторинг работоспособности ceph с самого начала развертывания. Как через набор инструментов самого ceph, так и путем доступа к его статусу через API Proxmox VE.

      Нижеследующие команды ceph могут использоваться, чтобы увидеть, является ли кластер исправным (HEALTH_OK), есть ли предупреждения (HEALTH_WARN), или ошибки (HEALTH_ERR). Если кластер находится в нерабочем состоянии, нижеприведенные команды состояния также дадут вам обзор текущих событий и действий.

      # одноразовый вывод статуса:

      pve# ceph -s

      # непрерывный вывод изменений статуса (нажать CTRL+C для остановки)

      pve# ceph -w

      Для получения более детальной информации, каждая служба ceph имеет файл журнала в /var/log/ceph/ и если нет достаточной детализации, уровень логирования можно настроить 11 .

      • Администрирование host системы
      • Оглавление
      • Графический интерфейс пользователя
      Похожие публикации:
      1. Как написать запрос для бд из с
      2. Как получить список всех атрибутов объекта
      3. Как узнать включен ли удаленный компьютер
      4. Когда появился язык си плюс плюс

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *