Что такое ceph proxmox

Code44free’s Blog

Виртуализация Proxmox + Ceph

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

Что получаем:

– Простое управление через Web-интерфейс Proxmox;
– Мониторинг нагрузки в реальном времени;
– Подключение к консоли гостевых систем из интерфейса управления;
– Возможность «живой миграции» (Live Migration) виртуальных машин, без перерыва в предоставлении сервиса;
– Объединение серверов в кластер и обеспечение высокой доступности за счет автоматической миграции виртуальных машин с вышедшей из строя ноды на работающие;
– Встроенное автоматическое резервное копирование виртуальных машин;

Схема решения:

Варианты решений:

Инсталляция в одном датацентре.
В кластер объединяются от 3-х до 16-ти серверов. Их жесткие диски объединяются в единое распределенное хранилище Ceph. Поверх настраивается HA-кластер Proxmox. Решение позволяет обеспечить работу сервисов в виртуальных машинах в случае отказа одного или нескольких серверов.

Инсталляция в 2-х или более датацентрах.
В кластер объединяются от 3-х до 16-ти серверов. Для больших инсталляций возможно создание нескольких 16-ти нодовых кластеров. Сервера распределены по 2-м или более датацентрам. Между датацентрами обеспечена видимость узлов по IP протоколу.

Жесткие диски объединяются в единое распределенное хранилище Ceph. Настраиваются правила репликации Ceph для гарантированного хранения образов виртуальных машин в 2-х или более датацентрах. Поверх настраивается HA-кластер Proxmox.

Для обеспечения сетевой видимости виртуальной машины, при миграции из одного датацентра в другой, настраивается «размазывание» VLAN виртуальных машин между датацентрами. Либо настраивается анонсирование сети виртуальных машин через протокол динамической маршрутизации.

При использовании динамической маршрутизации, в каждой виртуальной машине настраивается виртуальный IP-интерфейс с адресом с маской /32 и демон маршрутизации анонсирующий этот адрес через сетевое соединение и IP-адресацию датацентра в котором в данный момент работает виртуальная машина.

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

Инструкция по настройке proxmox_ceph_v0.1

Источник

Производительность системы хранения для Proxmox: сервер CIFS против Ceph SSD и Ceph HDD, а также разница между использованием LXC и QEMU

Проверена скорость работы дисковой системы при хранении образов в общей хранилке с подключением по CIFS. Также она сравнивается с ранее измеренной скоростью работы Ceph.

Содержание

Конфигурация [ править ]

Две конфигурации. Одна для FIO с тестированием NAS/HCI и вторая для SYSBENCH, где и кластер Ceph расширен с 3 до 5.

Сервер хранилища [ править ]

Хост [ править ]

5 серверов с одинаковой конфигурацией, на которых есть как локальный HDD, так и Ceph с двумя пулами, один на HDD и второй на SSD. Для тестов FIO использовались только 3 сервера в кластере с фактором репликации в 3.

Виртуальная машина [ править ]

Oracle Linux 8 QEMU4/KVM 10 ГБ ОЗУ 100 ГБ диск qcow2 с включенным сжатием

Образ виртуальной машины находится на общей хранилке, поключенной по CIFS/Samba.

Методика тестирования [ править ]

С помощью fio запускаются тесты на случайные чтение и записи по 4k и последовательные чтение-запись на 1М с большой очередью в 64 операции.

Тесты запускаются на самой хранилке (local native), с хоста на удаленной хранилке (remove native) и из виртуальной машины (remote qcow2). Нас интересует средняя латентность, пропускная способность и IOPS.

Для проведения тестирования надо задать папку, в которой будут тестовые файлы. Примеры ниже.

Кроме пропускной способности (bandwith) и IOPS измеряем латентность.

Также данные нормируем. local native по факту пишет со скоростью локального SSD, поэтому на эту скорость нормируем IOPS и приводим их относительно local native(но это плохо при чтении из ОЗУ). Также раз у нас пропускная способность канала 128 МБ/c, на неё нормируем пропускную способность

Результаты FIO [ править ]

Для учета влияния задержек в сети, латентность с хоста на хранилку пингками по 4к составила 0.3 мс.

Последовательная запись 1M [ править ]

При последовательной записи QEMU сжала диск и поэтому пропускная способность больше пропускной способности сети (в 128 МБ/c) и видимо по этой же причине ниже латентность.

Т.е. использование сжатия на уровне образа ускоряет последовательную запись сжимаемых данных.

В целом SSD значительного преимущества не даёт, а от нативной производительности хранилки остаётся от 16 до 39%.

Случайная запись 4k [ править ]

Случайная удалённая запись в QEMU раза в три медленнее по IOPS/MB и в 20 по латентности по сравнению с нативной скоростью общей хранилки.

Удивительно, но при случайной записи в Ceph разницы между SSD и HDD не наблюдается. Можно предположить, что это из-за записи через журнал и так как при линейной записи разница SSD/HDD не слишком велика, SSD особого прироста не даёт.

Последовательное чтение 1M [ править ]

Видно, что и QEMU и нативное чтение на хранилке идут из ОЗУ. ZFS видимо игнорирует direct-чтение. Причем QEMU читает не из ОЗУ сетевой хранилки, а из собственной памяти.

А вот удаленное чтение из хоста оказывается медленным.

Случайное чтение 4k [ править ]

Результаты опять неадекватные.

Выводы по FIO [ править ]

Тестам на чтение доверять нельзя, так как в действительности оно может идти из ОЗУ.

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

При последовательной записи Ceph в 2 раза медленнее удалённого хранения CIFS, но только если в QEMU используется сжатие. Локальный жесткий диск даёт производительность сравнимую с Ceph SSD и может превосходить запись по сети на SSD.

При случайной записи по 4k Ceph оказался быстрее удалённого хранилища по CIFS. Можно предположить, что это в результате того, что один из OSD Ceph оказывается локальным диском и оверхед Ceph при записи на локальный диск оказывается меньше оверхеда на запись по сети на CIFS. Но при случайных операциях на Ceph существенной разницы между SSD и HDD нет при использовании LXC, но есть разница в 6 раз при использовании QEMU. Можно предположить, что это из-за большого оверхеда QEMU на случайных записях.

Методика по SYSBENCH [ править ]

Методика вместе с результатами по Ceph взята из https://elibsystem.ru/node/546, но дополнена результатами по NAS через CIFS.

Результаты по SYSBENCH [ править ]

Последовательная запись 1 поток [ править ]

Видимо SYSBENCH пишет хорошо сжимаемые данные и они настолько хорошо жмутся, что QEMU их пишет почти на скорости локального хранилища и запись упирается в возможности хранилки, при этом формально превышая скорость подключения к хранилке по Ethernet в 120 МБ/c.

Ceph SSD и Ceph HDD оказались малоразличимы между собой, при этом их задержка примерно в три раза больше задержки записи хоста по CIFS и во столько же раз ниже IOPS/bandwith.

Интересно, что локальный диск обогнал сетевые хранилища даже с SSD.

Последовательное чтение 1 поток [ править ]

Нативная скорость чтения хранилки показала скорость обмена с ОЗУ (3.5 ГБ/c) и 224 тыс. IOPS на чтение.

QEMU опять хорошо сжался и превысил скорость канала и опять опередил в 6 раз несжатую скорость хоста.

Ceph SSD/HDD опять аутсайдеры и опять мало отличаются между собой.

Локальный диск по случайному совпадению оказался близок к работе QEMU.

Последовательная запись 10 потоков [ править ]

Локальная запись на хранилке опять уперлась в 21 тыс. IOPS.

QEMU сильно просел и оказался в 6 раз медленнее скорости записи хоста по сети.

Ceph SSD/HDD опять показал самый низкий результат со смешными 350 IOPS и латентностью как у HDD.

Локальный диск опередил сетевую запись.

Последовательное чтение 10 потоков [ править ]

Чтение на хранилище идет из ОЗУ на скорости 4 ГБ.

QEMU и чтение хоста по сети показывают близкие результаты примерно на скорости интерфейса.

Ceph SSD впервые в тесте значительно отличается от Ceph HDD (в 3 раза), но при этом Ceph SSD лишь немного опережает локальный HDD.

То, что Ceph SSD больше 120 МБ/c можно объяснить тем, что часть данных считалось с локального OSD.

Случайная запись 10 потоков [ править ]

Максимальная скорость здесь у хранилища при локальном чтении дисков, но только лишь 76 МБ/c при 4838 IOPS. Т.е. уперлись в систему хранения даже не смотря на использование SSD-кеша на запись.

Производительность QEMU и хоста при работе с сетью несколько меньше и сравнимы с Ceph SSD.

Явным аутсайдером является только локальный HDD, но и он смог выдать 1.5 тыс. IOPS, что неплохо для одиночного жесткого диска.

Случайное чтение 10 потоков [ править ]

Для чтения с хранилки опять читаем из ОЗУ.

QEMU, чтение хоста по сети и Ceph SSD опять оказались близки друг к другу и работают примерно на скорости сети.

Чтение с HDD хоть с Ceph HDD, хоть с локального HDD оказалось очень медленным, всего 6015 МБ/c, что типично для HDD при случайных операциях.

Выводы по SYSBENCH [ править ]

Поведение при случайных операциях и последовательных принципиально отличается.

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

При последовательном чтении такого единства нет и QEMU может читать из ОЗУ даже при флаге DIRECT, а локальный жесткий диск может превосходить сетевые по скорости и даже подключенные по сети SSD.

Для ряда задач уперлись в скорость сети, также следует обращать внимание на латентность и переход на 10G может не только снять ограничение там где скорости близки к 120 МБ/c, но и снизить латентность и повысить IOPS для случайных операций.

Источник

Глава 6. Настройка системы хранения

В данной главе мы собираемся рассмотреть как в Proxmox VE настраиваются системы хранения. Мы охватим следующие разделы в данной главе:

Настройку основного хранилища

Установку хранилища FreeNAS

Соединение с хранилищем iSCSI

Соединение с хранилищем LVM

Соединение с хранилищем NFS

Соединение с хранилищем Ceph RBD

Соединение с хранилищем ZFS

Соединение с хранилищем GlusterFS

Содержание

Введение

Хранилище является местом, где размещаются образы виртуальных дисков виртуальных машин. Существует множество различных типов систем хранения со многими различными свойствами, производительностью и способами применения. Вне зависимости от того является ли хранилище локальным с непосредственно подключенными к нему дисками или совместно используемым хранилищем с сотнями дисков, основным предназначением хранилища является размещения образов виртуальных дисков, шаблонов, резервных копий и тому подобного. Proxmox поддерживает различные типы хранилищ,такие как NFS, Ceph, GlusterFS и ZFS. Различные типы хранилищ могут хранить различные типы данных.

Системы хранения могут быть настроены в двух основных категориях:

Совместно используемые хранилища

< Прим. пер.: Это может показаться забавным, однако с некоторых пор стало возможным построение бесплатной среды виртуализации на основе гипервизора Hyper-V с бесплатной же системой хранения Storage Spaces, обладающей современными функциональностью и мощностью сопоставимыми, например, с Ceph. Хотя она и ограничена в масштабировании применением аппаратных технологий SAS/ FC. Остаётся дождаться смещения Storage Spaces Direct (S2D) в сферу халявного применения, чтобы имеющаяся в Непосредственно подключаемых пространствах хранения Программно определяемая шина хранения (Software Storage Bus), заменяющая собой SAS/FC, смогла составить конкуренцию системам хранения уровня Ceph!>

Локальные хранилища

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

Виртуальные машины могут осуществлять миграцию в реальном времени когда существует несколько узлов Proxmox в кластере и виртуальные диски сохраняются на совместно используемом хранилище доступном для всех узлов в кластере.

Совместно используемые хранилища

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

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

Хранилище Ceph

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

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

Демон монитора (MON)

Демон хранения объектов (OSD)

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

Карта Управляемых масштабируемым хешированием репликаций (CRUSH map, Controlled Replication Under Scalable Hashing map)

Группы размещения (PG, Placement Group)

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

Демоны хранения объектов OSD, Object Storage Daemons отвечают за хранение и извлечение действительных данных кластера. Обычно одно физическое устройство подобное жесткому диску, или твердотельному диску настраивается как отдельный OSD. Хотя несколько различных OSD может быть настроено на одном физическом диске, это не рекомендуется делать совсем ни для каких промышленных применений. Каждый OSD требует устройство журнала, где вначале записываются данные, которые позже переносятся на реальный OSD. Сохраняя данные в журналах на высокопроизводительных SSD мы можем значительно увеличивать производительность ввода/ вывода Ceph.

Благодаря архитектуре Ceph, чем больше и больше OSD добавляется в кластер, тем больше возрастает производительность ввода/ вывода. Журнал OSD работает очень хорош на малых кластерах при примерно восьми OSD на узел. OSD могут быть установлены с помощью графического интерфейса Proxmox после начального создания MON.

OSD Journal

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

Следует также отметить, что если происходит отказ журнала, это приведёт к выходу из строя всех OSD, которые обслуживает данное устройство журнала. В некоторых средах может быть необходимо помещать два устройства SSD для зеркального RAID и уже его применять для журнала В больших средах с более чем 12 OSD на узел производительность может быть на самом деле получена путём размещения журнала на том же диске OSD вместо применения SSD для ведения журнала.

CRUSH map

Карта Управляемых масштабируемым хешированием репликаций (CRUSH map) является сердцем распределенной системы хранения Ceph. Алгоритм для сохранения и извлечения пользовательских данных в кластерах Ceph планируется в карте CRUSH. CRUSH делает возможным прямой доступ клиента к OSD. Это устраняет единую точку отказа и любые физические ограничения масштабирования, поскольку не существует централизованных серверов или контроллеров для управления операциями чтения и записи хранимых данных. Во всех кластерах Ceph CRUSH поддерживает карту всех MON и OSD. CRUSH определяет как данные должны быть разбиты и реплицированы среди OSD распределяя их среди локальных узлов или даже среди удаленно расположенных узлов.

Карта CRUSH по умолчанию создается на только что установленный кластер Ceph. Она может дополнительно настраиваться дальше на основе потребностей пользователей. Для небольших кластеров Ceph эта карта должна работать просто прекрасно. Однако, когда Ceph развертывается для очень больших данных, эту карту необходимо настраивать дополнительно. Настроенная карта позволит лучше управлять массивными кластерами Ceph.

Для успешной работы с кластерами Ceph любых размеров обязательно ясное понимание карты CRUSH.

В Proxmox VE 3.4 мы не можем настраивать под требования пользователя карту CRUSH с применением графического интерфейса Proxmox. Она может только просматриваться в GUI, а ее изменение осуществляется через CLI.

< Прим. пер.: чтобы полностью использовать полосу пропускания SSD, они должны расщепляться примерно между 5 OSD (по опыту Mirantis), для включения такой возможности вам необходимо удалить OSD, созданные на этих SSD при установке, разделить каждый SSD на пять разделов и создать на них OSD. см., например, раздел 6.1 Эталонной архитектуры для компактного облачного решения с применением Mirantis OpenStack 9.1 и оборудования Dell EMC. >

В хранилище Ceph объекты данных собираются в группы определяемые с помощью алгоритмов CRUSH. Они называются группами размещения (PG, Placement Group), поскольку CRUSH помещает эти группы в различные OSD в зависимости от установленного в карте CRUSH уровня репликации и количества OSD и узлов. Отслеживая группы объектов вместо самих объектов можно сохранять огромное количество аппаратных ресурсов. Было бы невозможно отслеживать миллионы отдельных объектов в кластере. Следующая диаграмма показывает как объекты объединяются в группы и, как PG связаны к OSD:

Для балансировки доступных аппаратных ресурсов необходимо назначать правильное число групп размещения. Число групп размещения должно меняться в зависимости от число OSD в кластере. Следующая таблица предлагаемых групп размещений выполнена разработчиками Ceph:

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

Для получения дополнительных подробностей по группам размещения посетите http://ceph.com/docs/master/rados/operations/placement-groups/. < Прим. пер.: или раздел Группы размещения в переводе книги «Изучаем Ceph» Карана Сингха >.

Pools

Для получения дополнительных подробностей по Ceph и его компонентам посетите http://ceph.com/docs/master/. < Прим. пер.: или с переводом книги «Изучаем Ceph» Карана Сингха >.

Следующий рисунок демонстрирует основы кластера Proxmox+Ceph

В более продвинутых кластерах третья сеть создается исключительно между узлами Ceph для репликаций кластера, тем самым еще больше улучшая производительность. В Proxmox VE 3.4. один и тот же узел может использоваться и для Proxmox, и для Ceph. Это предоставляет больший способ управляемости всеми узлами из одного графического интерфейса Proxmox. Не рекомендуется размещать виртуальные машины Proxmox на узле который также настроен как Ceph. Во время повседневных операций узлы Ceph не потребляют больших объемов ресурсов подобных процессорам или памяти. Однако, когда Ceph переходит в режим балансировки вследствие отказа узла OSD возникают большие объемы реплицируемых данных, что требует больших объемов ресурсов. Если ресурсы совместно используются виртуальными машинами и Ceph, производительность значительно ухудшится.

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

Настройка основного хранилища

Как это сделать.

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

Настройка хранилищ обычно имеет следующий многострочный формат:

Изменение настройки хранилища не требует перезагрузки и вступает в действие немедленно.

Установка хранилища FreeNAS

FreeNAS является одной из наиболее популярных свободно распространяемой системой хранения которая проста в установке и сопровождении. Она предоставляет общие протоколы хранения, такие как iSCSI, NFS, CIFS, AFP и тому подобные. Применяя готовое к использованию общедоступное оборудование любой может настроить полностью функциональную систему хранения за несколько минут. Существует платная версия FreeNAS, которая поставляется с предустановленной системой хранения, продаваемой iXsystems под названием TrueNAS, посетите http://www.ixsystems.com/truenas/.

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

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

Следующий экранный снимок показывает графический интерфейс FreeNAS после обычной установки:

Приготовление

Для целей данной главы вам нужно установить систему хранения способную создавать хранилища на основе iSCSI, LVM и NFS, поскольку они могут быть присоединены к кластерам Proxmox. Если у вас уже есть такая установка системы хранения, пропустите, пожалуйста, данный раздел. Для целей обучения FreeNAS может быть установлена как виртуальная машина в кластере Proxmox. Загрузите последний ISO файл FreeNAS c http://www.freenas.org/download-freenas-release.html

Как это сделать.

Если вы устанавливаете FreeNAS на физическом узле, применяйте следующие шаги:

Подготовьте CD с образом ISO FreeNAS.

Вставьте USB флеш-диск c, по крайней мере, 8ГБ в USB порт.

Загрузите узел с диска ISO.

После приглашения выберите USB диск как диск установки.

Следуйте установке согласно графическому интерфейсу и перезагрузитесь после завершения.

Настройте сеть в соответствии с вашими настройками IP после перезагрузки.

Осуществите доступ к графическому интерфейсу FreeNAS из веб- просмотрщик применив IP из предыдущего пункта.

Если вы устанавливаете FreeNAS на виртуальной машине, применяйте следующие шаги:=

Загрузите образ ISO FreeNAS в хранилище Proxmox.

Создайте виртуальную машину с 8ГБ виртуальным диском и одним или более дисками необходимого размера.

Стартуйте виртуальную машину из образа ISO.

После приглашения выберите 8ГБ виртуальный диск как установочный диск.

Следуйте установке согласно графическому интерфейсу и перезагрузитесь после завершения.

Настройте сеть в соответствии с вашими настройками IP после перезагрузки.

Осуществите доступ к графическому интерфейсу FreeNAS из веб- просмотрщик применив IP из предыдущего пункта.

Есть кое-что еще.

Все подробности о том как настраивать различные типы хранилищ в FreeNAS выходят за рамки данной книги. Официальная документация FreeNAS по адресу http://doc.freenas.org/9.3/freenas.html поможет создать совместно используемые iSCSI и NFS, которые будут использоваться позже в этой главе.

Если у вас есть различные системы хранения, такие как iSCSI и NFS, вы можете использовать их для практических разделов данной главы. Если вы не знакомы ни с какими системами хранения и только начинаете работать в мире разделяемых систем хранения и виртуализации, тогда FreeNAS может стать хорошей отправной точкой.

Хорошей идеей будет потратить некоторое время на FreeNAS перед погружением в Proxmox.

Соединение с хранилищем iSCSI

Internet Small Computer System Interface (iSCSI) основывается на протоколе интернет , который позволяет передавать команды SCSI поверх стандартной сети на основе IP. iSCSI устройства могут быть установлены локально или на огромных расстояниях для предоставления вариантов хранения. Для клиента подключенное iSCSI устройство представляется просто как физически подключенное дисковое устройство.

В данном разделе мы собираемся рассмотреть как подключать iSCSI хранилище к кластеру Proxmox.

Приготовление

Как это сделать.

В графическом интерфейсе кликните по Datacenter в левом окне навигации.

Кликните на Storage в меню с закладками.

Кликните на Add чтобы открыть ниспадающее меню как показано на следующем снимке экрана:

Кликните на iSCSI чтобы открыть блок диалога.

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

IP узла совместно используемого хранилища.

Адресат iSCSI настроенный на совместно используемом узле.

Прямое применение LUN

Разрешение/ запрет прямого применения LUN. Параметр должен быть установлен на запрет. Разрешение может привести к потере данных.

Следующий экранный снимок показывает блок диалога хранилища iSCSI с уже введенной информацией:

Кликните на Add для подключения хранилища.

Следующий экранный снимок показывает хранилище iSCSI после его возникновения в графическом интерфейсе Proxmox:

Как это работает.

Следующий снимок экрана показывает файл конфигурации с добавленными настройками хранилища iSCSI. Мы также можем сделать изменения путем прямого редактирования файла:

Есть кое-что еще.

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

Соединение с хранилищем LVM

Приготовление

LVM может быть сконфигурирован с применением как локально подключенного дискового хранилища, так и iSCSI подключаемого устройства с различных узлов. Локально подключаемый LVM должен настраиваться с применением CLI. В версии ProxmoxVE 3.4 невозможно настраивать локально подключаемый LVM через графический интерфейс.

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

Как это сделать.

Следующие разделы покажут как добавлять хранилище LVM с локальными устройствами и создавать LVM с совместно используемыми хранилищами в качестве основы.

Добавление хранилища LVM с локальными устройствами

Следующие шаги показывают как добавить LVM хранилище с локальными устройствами:

Будьте уверены что устройства не имеют никаких разделов или файловых систем на них, поскольку они будут безвозвратно удалены.

Зарегистрируйтесь в консоли через SSH на узле Proxmox.

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

Создайте группу тома с именем pmx-lvmvg или любым другим удобным вам именем:

Кликните Add и выберите LVM в ниспадающем меню.

Введите pmx-lvm в качестве имени хранилища.

Кликните на Add чтобы создать хранилище LVM.

Создание LVM с совместно используемыми хранилищами в основе

Теперь мы собираемся рассмотреть как создать LVM с совместно используемым хранилищем в основе. Следующие шаги показывают как добавить хранилище LVM на сетевых iSCSI устройствах через графический интерфейс:

Кликните Add и выберите LVM в ниспадающем меню.

Введите pmx-lvm в качестве имени хранилища.

Кликните на Add чтобы создать хранилище LVM.

Следующий снимок экрана показывает блок диалога <добавления>хранилища LVM для LVM хранилищ на основе iSCSI:

Как это работает.

Вот содержание файла настройки хранилища в /etc/pve/storage.cfg после добавления хранилища LVM:

Есть кое-что еще.

LVM широко применяются во всех видах сетевых сред и является главным локальным хранилищем операционной системы. Если вы не знакомы с LVM, вам стоит научиться управлять им, поскольку это также может быть использовано в виртуальных машинах на основе Linux. Почти все основные дистрибутивы, в том числе Proxmox, используют LVM во время установки в качестве основного раздела устройства операционной системы. Для лучшего понимания как делать хранилище LVM посетите https://www.howtoforge.com/linux_lvm.

Соединение с хранилищем NFS

Изначально разработанная Sun Microsystems, Network File System (NFS) вероятно на сегодняшний день является одним из наиболее популярных протоколов совместно используемых протоколов. В настоящее время в версии 4 совместное использование NFS допускает все типы файлов Proxmox, такие как образы дисков, шаблоны ISO, контейнеры OpenVZи тому подобные. Почти все виртуальные или физические сетевые среды по всему миру реализуют некоторые виды хранилищ NFS.

В данном разделе мы собираемся рассмотреть как соединять разделяемые NFS с кластером Proxmox.

Приготовление

Чтобы подключится к разделяемому NFS, разделяемый ресурс должен быть вначале создан в совместно используемой системе хранения. Следуйте документации используемой вами системы хранения для создания разделяемого ресурса NFS. Для нашего примера мы создадим разделяемый ресурс с именем pmx-nfs в совместно используемом хранилище FreeNAS.

На сегодня существует четыре версии NFS. Несоответствие версий между серверами NFS и клиентскими узлами может вызвать проблемы с подключением. По умолчанию Proxmox применяет клиент NFS версии 3. Если вы не уверены какая версия используется для ресурса NFS, мы можем запустить следующую команду на узле Proxmox для вывода версии NFS:

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

Как это сделать.

Зарегистрируйтесь в графическом интерфейсе как root или другой пользователь с административными правами.

Выберите NFS из подключаемого модуля хранилища. Добавьте ниспадающее меню чтобы открыть блок диалога создания хранилища NFS.

Введите необходимую информацию как показано в следующей таблице:

IP узла совместно используемого узла хранилища.

Выберите доступный разделяемый ресурс NFS в ниспадающем меню.

Выберите тип сохраняемого содержимого.

Disk Image, ISO image

Выберите узлы Proxmox которые могут использовать данное хранилище.

Блок флага для включения/ запрета хранилища.

Максимальное численное значение сохраняемых файлов резервных копий. Более старые файлы резервных копий автоматически удаляются.

Кликните на Add чтобы добавить хранилище NFS.

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

Есть кое-что еще.

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

Соединение с хранилищем Ceph RBD

В данном разделе мы собираемся рассмотреть настройку блочного хранилища Ceph в кластере Proxmox.

Приготовление

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

Как это сделать.

Сейчас мы рассмотрим как настраивать блочное хранилище Ceph в Proxmox.

Установка Ceph на Proxmox

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

Следующие шаги должны быть выполнены на всех узлах Proxmox которые будут частью кластера Proxmox:

Зарегистрируйтесь на каждом узле через SSH или консоль.

Настройте второй сетевой интерфейс для создания отдельной сети Ceph с другой подсетью.

Перезагрузите узлы для инициализации сетевых настроек.

Воспользовавшись следующей командой установите пакт Ceph на каждом узле:

< Прим. пер.: в настоящее время последняя версия Hammer >

Инициализация настройка Ceph

Следующие шаги необходимо выполнить только на одном узле Proxmox который будет частью нашего кластера Ceph:

Зарегистрируйтесь на узле с применением SSH или консоли.

Выполните следующую команду для создания начальной настройки Ceph:

Выполните следующую команду для создания первого монитора:

Настройка Ceph с применением графического интерфейса Proxmox

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

Следующие шаги показывают как создавать мониторы и OSD Ceph из графического интерфейса Proxmox:

Зарегистрируйтесь в графическом интерфейсе Proxmox как root илидругой пользователь с правами администратора.

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

Поскольку никакие OSD пока ещене созданы, это будет нормальным для нового кластера Ceph показывать остановленные группы размещения и неясные ошибки.

Кликните на кнопку Disks меню с закладками под Ceph чтобы отобразить подсоединенные к узлу диски, как показано на следующем снимке экрана:

Выберите доступный подключенный диск, затем кликните на кнопку Create: OSD для открытия диалогового блока OSD, как показано на следующем снимке экрана:

Кликните на ниспадающее меню Journal Disk чтобы выбрать другое устройство или расположить журнал на том же самом OSD оставив его таким по умолчанию.

Кликните Create для завершения создания OSD.

По необходимости создайте дополнительные OSD в узлах Ceph.

Следующий экранный снимок показывает узел Proxmox с тремя настроенными OSD:

Следующие шаги показывают как создавать мониторы в графическом интерфейсе Proxmox:

Выберите узел Proxmox из ниспадающего меню.

Кликните кнопку Create для запуска процесса создания монитора.

Создайте в сумме три монитора Ceph для получения кворума Ceph.

Следующий экранный снимок показывает состояние Ceph с тремя мониторами и добавленными OSD:

Заметим, что даже с тремя добавленными OSD группы размещения будут подвисшими и с ошибками. Это происходит потому, что по умолчанию Ceph CRUSH установлен на две реплики. Более того, мы создали OSD только на одном узле. Для успешной репликации нам необходимо добавить немного больше OSD на втором узле так, чтобы данные могли бы реплицироваться дважды. Повторите описанные ранее шаги для создания трех дополнительных OSD на втором узле. После создания еще трех OSD состояние Ceph должно выглядеть как на следующем экране:

Управление пулами Ceph

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

Следующие шаги показывают как проверять, создавать и удалять пулы Ceph с помощью графического интерфейса Proxmox:

Кликните на Create для открытия диалогового блока создания.

Кликните OK для создания пула.

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

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

Присоединение RBD к Proxmox

После того как кластер Ceph полностью настроен мы можем выполнить присоединение его к кластеру Proxmox.

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

Введите информацию описанную в следующей таблице:

Источник

• ← Что такое cep в бразилии
• Что такое cer файл →