Proxmox удалить storage

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

Если вы строите кластер из разных точек доступности (такое возможно), проверяйте сперва сеть между нодами на наличие multicast иначе corosync упадет не успев подняться.

Иногда возникают проблемы с кластером PROXMOX, чаще всего это происходит из-за непонимания того как этот кластер вообще работает. В случае когда чистые сервера объединяются в новый кластер как правило проблем никаких не возникает, но ситуации бывают разные.

Наверное все кто работал с данной системой виртуализации натыкались на разные «грабли». Я рекомендую перед тем как что-то сделать на сервере PROXMOX создать резервные копии файлов виртуальных машин, а так же файл storage.cfg — это значительно облегчит Вам жизни. Сделать это можно например так:

Этого вполне достаточно, что-бы сэкономить время.

Но это уже скорее всего лирика, кластер уже лежит раз Вы читаете эту статью. Не будем терять времени и приступим к восстановлению.

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

Нода удалена, но в интерфейсе присутствует со знаком вопроса — для ее удаления из интерфейса необходимо удалить каталог с именем ноды из каталога
/etc/pve/nodes
Нода исчезла из интерфейса, но я обнаружил, что не могу удалить задания репликации, в которых она учавствовала, хотя они и были предварительно отключены

Как я решил проблему:
В консоли любой ноды выполняем
grep -ilr «del_node_name» /etc/pve/

Вывод(в моем случае):

Открываем в текстовом редакторе и вдумчиво вычищаем все артефактные записи
Например репликация(replication.cfg):

Также имеет смысл почистить аналогичным способом по IP адресу удаленной ноды.
Следует особое внимание уделить файлу/etc/pve/corosync.conf(раздел totem)

Удаленная нода могла использоваться зля ввода других в кластер и ее ip необходимо заменить на IP активной ноды. После правки необходимо перегрузить corosync:
systemctl restart corosync

Содержание

Предварительное условие
Начальная установка и настройка Ceph
Установка пакетов Ceph
Создание начальной конфигурации Ceph
Создание Ceph мониторов
Создание Ceph Manager
Создание Ceph OSD
Создание Ceph Пулов
Ceph CRUSH и классы устройств
Ceph Client
CephFS
Ceph Мониторинг и устранение неполадок
Резервная копия конфигурации ноды
Обнуляем ноду PROXMOX
Восстановление конфигурации хранилища

Предварительное условие

Для построения гиперконвергентного кластера 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 предназначен для работы напрямую с дисками самостоятельно, без какой-либо абстракции между ними. R AID — контроллеры не предназначены для использования Ceph и могут усложнять ситуацию, а иногда даже снижать производительность, так как их алгоритмы записи и кэширования могут мешать работе Ceph.

Избегайте RAID-контроллера, используйте вместо него host bus adapter (HBA).

Приведенные выше рекомендации следует рассматривать как примерное руководство по выбору аппаратного обеспечения. Поэтому по-прежнему важно адаптировать его к вашим конкретным потребностям, протестировать вашу установку и постоянно контролировать работоспособность и производительность.

2Полная ячеистая сеть для Ceph https://pve.proxmox.com/wiki/Full_Mesh_Network_for_Ceph_Server

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

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

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

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

Шаг настройки включает в себя следующие параметры:

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

Кроме того, вы обязательно должны выбрать свой первый узел монитора.

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

Остальная часть этой главы будет направлять вас о том, как получить максимальную отдачу от вашего Ceph на базе Proxmox VE, это будет включать в себя вышеупомянутые шаги и другие, такие как CephFS (см. раздел 4.2.11), которая является очень удобным дополнением к вашему новому кластеру Ceph.

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

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

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

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

pveceph init —network 10.10.10.0/24

Создание Ceph мониторов

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

Создание Ceph Manager

Manager daemon работает рядом с мониторами, обеспечивая интерфейс для мониторинга кластера. С момента выпуска Ceph luminous демон ceph-mgr4 обязателен. Во время установки монитора также будет установлен Ceph manager.

3Ceph Monitor http://docs.ceph.com/docs/luminous/start/intro/4Ceph Manager http://docs.ceph.com/docs/luminous/mgr/

Рекомендуется установить Ceph Manager на узлах, где установлены мониторы. Для обеспечения высокой доступности установите более одного менеджера.

Создание Ceph OSD

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

Мы рекомендуем размер кластера Ceph, начиная с 12 OSD, равномерно распределенных между вашими, по крайней мере, тремя узлами (4 OSD на каждом узле).

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

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

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

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

Вы можете непосредственно выбрать размер для них, с помощью параметров -db_size и -wal_size соответственно. Если они не заданы, будут использоваться следующие значения (по порядку):

B хранит внутренние метаданные BlueStore, а WAL — это внутренний журнал BlueStore или журнал опережающей записи. Рекомендуется использовать быстрый SSD или NVRAM для повышения производительности.

5Ceph Bluestore http://ceph.com/community/new-luminous-bluestore/

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

Создание Ceph Пулов

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

Если параметры не заданы, используется значение по умолчанию 128PG, size 3 реплики и min_size 2 реплики для обслуживания объектов в случае деградации пула.

Количество PG по умолчанию подходит для 2-5 дисков. Ceph выдает предупреждение HEALTH_WARNING, если у вас слишком мало или слишком много PG в вашем кластере.

Рекомендуется рассчитать число PG в зависимости от ваших настроек, в интернете вы можете найти формулу и онлайн PG калькулятор6. Количество PG может быть увеличено позже, но оно никогда не может быть уменьшено.

Если вы хотите автоматически добавить хранилище во время создания пула, активируйте флажок «добавить хранилище» в графическом интерфейсе или используйте параметр командной строки —add_storages при создании пула.
Дополнительную информацию об обработке пула Ceph можно найти в Ceph pool operation7 manual.

6PG calculator http://ceph.com/pgcalc/7Ceph pool operation http://docs.ceph.com/docs/luminous/rados/operations/pools/

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

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

CRUSH вычисляет, где хранить и откуда извлекать данные, преимуществом этого подхода является то, что не требуется централизованная служба индексирования. C RUSH работает с картой OSD, сегментов (расположения устройств) и наборов правил (репликация данных) для пулов.

Дополнительную информацию можно найти в документации Ceph, в разделе CRUSH mapa.

aCRUSH map http://docs.ceph.com/docs/luminous/rados/operations/crush-map/8CRUSH https://ceph.com/wp-content/uploads/2016/08/weil-crush-sc06.pdf

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

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

ceph osd crush tree —show-shadow

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

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

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

Ceph Client

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

CephFS

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

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

pveceph mds create

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

mds standby replay = true

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

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

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

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

ПРЕДПОСЫЛКИ ДЛЯ УСПЕШНОЙ УСТАНОВКИ CEPHFS:

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/10Ceph Placement Groups http://docs.ceph.com/docs/luminous/rados/operations/placement-groups/

Уничтожение 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.

Дополнительную информацию об устранении неполадок12 кластера Ceph можно найти на его веб-сайте.

11Логирование и отладка Ceph http://docs.ceph.com/docs/luminous/rados/troubleshooting/log-and-debug/12Ceph устранение проблем http://docs.ceph.com/docs/luminous/rados/troubleshooting/

Резервная копия конфигурации ноды

Заходим на сервер по SSH, смотреть на pvecm status особого смысла нет т.к. все у нас лежит. На всякий случай делаем бэкап того, что мы имеем:

Бывает, что /etc/pve не доступен из-за падения служб или их зависанием. Настоятельно рекомендую добиться того, чтобы скопировать текущие файлы кластера перезапустив кластер systemctl restart pve-cluster.service. После перезапуска пытаемся сделать резервную копию. Если не получилось идем на другой сервер который в этом кластере и пытаемся сделать тоже самое т.к. если кластер работал то конфигурация машин и хранилища будут всех нод.