Сервер Proxmox: различия между версиями

Материал из wolfram
Перейти к навигации Перейти к поиску
мНет описания правки
мНет описания правки
Строка 139: Строка 139:
*[[Сервис MediaWiki#.D0.9D.D0.B0.D1.81.D1.82.D1.80.D0.BE.D0.B9.D0.BA.D0.B0 Proxmox .D0.B4.D0.BB.D1.8F MediaWiki|Настройка Proxmox для MediaWiki]]
*[[Сервис MediaWiki#.D0.9D.D0.B0.D1.81.D1.82.D1.80.D0.BE.D0.B9.D0.BA.D0.B0 Proxmox .D0.B4.D0.BB.D1.8F MediaWiki|Настройка Proxmox для MediaWiki]]


== О моём хранилище ==
Чтож - это большая тема! Со временем моё хранилище эволюционировало и модифицировалось. Начиналось всё с одного диска на 8 террабайт, сейчас на илюль 2023 года хранилище состоит из 10 накопителей по 12 террабайт и одного NVME PCIe GEN 3 на 1 террабайт под кеш.


Сначачала рейдов не было, но когда я купил 3 одинаковых накопителя, сразу же встал вопрос, какой рейд выбирать. На тот момент пал выбор именно на ZFS RAIDZ (аналог рейда 5), казался лучшим выбором. Затем через год расщирился до 5ти дисков, помучился с невозможностью расширить, пришлось искать накопители для переноса. на пяти дисках так же осатвался с аналогом рейда 5 от ZFS. Всё в общем то устраивало, но когда объем упал до 30 процентов, очень сильно стало сказываться на производительности. Так же колличесво оперативной памяти потреблялось черезвычайно много.
А так же очень затруднительная сложность найти обеём на стороне для сохранения информации, застатвила задуматься о перехоже на дрйгой програмный рейд, который бы позволил расширять себя налету. Выбр пал на MD рейд. В простонародье NDADM.
Куплено еще 5 накопителей. Сервер уже насчитвает 10 дисков. Теоритическим объемом 120 террабайт. Умопомрачительные объёмы надо сказать, для одного человека.
При данном колличесве накопителей надёжность всётаки уже кажется очень важной. Я уже готов пожертвовать 2 накопителя из 10 на четность. Потому выбирается Raid6.
Что в общем то и делается.
Вот небольшая инструкция как сделать.
Для начала нужно затереть все накопители. Есть много способов, воспользоваться утилитой fdisk и удалить разделы и так далее:
=== DD ===
Запись посекторно с начала диска значение нулей, смый жесткий метод.
Уничтоже всё что есть в анчале разделов и таблице, несмотря на занятость и востребованость. Станет не сразу понятно, но после перезагрузки, уже ничего не будет. Легко можно затереть системный раздел.
dd if=/dev/zero of=/dev/sdb
Та же можно затереть требуемым размером блоков, скорость будет выше:
dd if=/dev/zero of=/dev/sdb bs=2M
Еще можно сказать чтобы было записан нужное число раз, наприемер 2 мегабайта 1000 раз:
dd if=/dev/zero of=/dev/sdb bs=2M count=1000
Про DD в данных рамках пока что все.
=== wipefs ===
Сслучайно наткнулся на днную команду в посикаха разных способов стирать разделы.
Есть поумолчанию в линусе, потому очень удобно.
Уже чувствительна к тому используется ли где то что нужно затереть. Но если всё свободно то отлично стирает все зписи о разделах.
wipefs -a /dev/md1
----Вот такие способы. После отчистки дисков можно приступить к созданию самого массива.
Тут на удивление всё просто. Я рассмотрю 2 варианта Raid0 и Raid6. Нулевой рейд мен пригодился при копировании всей информации с моих дисков, это сильно экономит время, а так же скорость хорошая. Использовать для временного переноса всего очень нужная тема.
mdadm --create /dev/md0 --level=6 --raid-devices=10 /dev/sd{a,b,c,d,e,...}
'''--level=6''' - тип рейда 6 (всегда 2 диска в запасе), 0 (все диски - один большой диск)
'''--raid-devices=10''' - количесво дисков, в моём случае 10
Далее перечислить диски
После создания массива, происходит билдинг массива. Это не быстрый процесс. В этот момент уже можно вести запись на созданый массив. Но скорость будет снижена.
Псомтреть статус можно камандой:
cat /proc/mdstat
А так же дополнительную информацию командой
mdadm --detail /dev/md0
Далее можно уже создать файловую систему на нашем рейд массиве
mkfs.ext4 /dev/md0
Но это уже в прошлом. Теперь нужно создать прослойку для того чтобы можно было задействовать SSD кеш.
В процессе я столкнулся с двумя способами реализации данного метода. Вообще их даже 3. Превый я описываю в другой статье, можно назвать его ZTF, так как эта ФС поумолчанию может в использование SSD накопителя для кеширования.
----
=== LVM Cache ===
Изначально мне приглянулся данный способ, так как слишком уж хорошо он описан. А так же испозуется точно в тех же условиях что и нужно мне
Вот [https://winitpro.ru/index.php/2020/11/20/ssd-lvm-cache-v-linux-centos/ ссылка] на статью.
Заключается он в том, что SSD и созданом рейде md0, создаются LVM пулы и группы. И с помощью реализованой ими функции свзязываются между собой.
Сделай
lsblk
Чтобы посмотреть что там по дискам, произведи стирание дисков по иснтрукциям выше.
Из данных поняли что хранилищем данных у меня будет '''/dev/md0''', а кешом станет '''/dev/nvme0n1'''.
Еще раз чтобы было понятно:
'''/dev/md0''' - рейд массив с дисками
'''/dev/nvme0n1''' - диск под кеш
Теперь на основе это выполняю команды.
Инициализируем нужные нам диски как LVM
pvcreate /dev/md0
pvcreate /dev/nvme0n1
Создадим группу томов по имени '''ssdcache'''
vgcreate ssdcache /dev/md0 /dev/nvme0n1
Тут может возникнуть ошибка которая говорит от том что размеры блоков разные это нужно испраялть настройками:
nano /etc/lvm/lvm.conf
найти, исправить значение и разкоментировать строку
allow_mixed_block_sizes =1
Создадим логический том на нашем хранилище с именем '''hdd_data'''
lvcreate -l 100%FREE -n hdd_data ssdcache /dev/md0
Создадим тома на нашем кеше, сначала раздел 16 гигобайт, для метаданных, больще нельзя. Имя дадим '''ssd_meta.'''
lvcreate -L 16G -n ssd_meta ssdcache /dev/nvme0n1
Созадим том на оставшийся объем по имени '''ssd_data'''.
lvcreate -l 90%FREE -n ssd_data ssdcache /dev/nvme0n1
Далее операция не совсем мне понятная
lvconvert --type cache-pool --poolmetadata ssdcache/ssd_meta ssdcache/ssd_data
При создании данной операции может возникунуть предупреждение о рахмере блока. "'''''Using 2.00 MiB chunk size instead of default 64.00 KiB, so cache pool has less than 1000000 chunks.'''''"
Это лиш говорит о том что система выбрала размер блока отличного от размера по умолчанию.
И запустим работу с настройкой режима '''writeback'''
lvconvert --type cache --cachemode writeback --cachepool ssdcache/ssd_data ssdcache/hdd_data
Есть два режима кеширования:
* '''Writeback''' — данные сначала пишутся в кэш, затем на диск. Это более производительный вариант. При сбое кэширующего SSD диска, вы потеряете данные, которые не успели записаться на HDD. Хотя и не рекомендуется использовать этот режим на серверах с SSD без RAID, мне кажется с учетом надежности SSD дисков, это вполне рабочее решение.
* '''Writethrough''' — данные сразу пишутся одновременно на диск и в кэш, после чего наиболее часто используемые попадают в кэш. Это безопасный вариант, подходит для серверов с 1*SSD, но гораздо менее производительный.
После выполнения всех настроек, можно проверить кэш на наличие ошибок:
lvs -a
Теперь создадим файловую систему на новом LVM разделе:
mkfs.ext4 /dev/ssdcache/hdd_data
Дальше уже можно примонтировать раздел куда хочется.
Так же можно узнать UUID и прописать в fstab, для автозапуска.
blkid|grep cache
После чего всё уже должно работать.
Посмотреть какой статус можной командой:
lvs -o+cache_mode ssdcache
Так же иногда хочется наблюдать
watch lvs -o+cache_mode ssdcache
Для смены режима, используются команды:
lvchange --cachemode writeback ssdcache
lvchange --cachemode writethrough ssdcache
Так же если нужно заменить SSD накопитель, или просто отключить работу кеша, на время
lvconvert --uncache /dev/ssdcache/hdd_data
vgreduce ssdcache /dev/nvme0n1
pvremove /dev/nvme0n1
После этого всё будт работать без использования кеша.
Чтобы добавить диск обратно
pvcreate /dev/nvme0n1
vgextend ssdcache /dev/nvme0n1
lvcreate -L 16G -n ssd_meta ssdcache /dev/nvme0n1
lvcreate -l 90%FREE -n ssd_data ssdcache /dev/nvme0n1
lvconvert --type cache-pool --poolmetadata ssdcache/ssd_meta ssdcache/ssd_data
lvconvert --type cache --cachemode writeback --cachepool ssdcache/ssd_data ssdcache/hdd_data
Это всё о настройке данного кеша.
Прирост скорости действительно есть. Но я рещил рассмотреть еще варинаты исполнения данной функции.
----
=== Bcache ===
Решил я посмотреть и на этот вид кеширования. Я не очень склонялся на использрвание данного решения, так как информация не столь приятно и понятнр изложена как с LVM. Но я разобрался.
Почему я остановлся на именно этом варианте?
Производительность у данного споба всёже выше. На одинаковом массиве данных этот спасоб показывает всегода одинкавый результат, в отлиции от LVM.
А функционал такой же и даже больше, например сжатие. Это практически полностью затмевает ZTF.
Опять же припомню мой случай:
'''/dev/md0''' - рейд массив с дисками
'''/dev/nvme0n1''' - диск под кеш
Создам bcache на дисках
make-bcache -B /dev/md0
Создам bcache на SSD диске
make-bcache -C /dev/nvme0n1
Теперь нужно узнать uuid диска с кешом
bcache-super-show /dev/nvme0n1 | grep cset
Полученый uuid зарегистровать для нашего хранилища
echo e0bae1a5-4f68-4066-a7b6-5d0f16dd63da > /sys/block/bcache0/bcache/attach
Влючить обратный режим записи. Чтобы кеш работал на запись
echo writeback > /sys/block/bcache0/bcache/cache_mode
Дальше можно отформатировать раздел в btrfs, назавём его '''STORAGE'''
mkfs.btrfs -L STORAGE /dev/bcache0
И в целом всё. Оно уже работает, можно монтировать и использовать.
Так же можно примонтировать раздел с функцией сжатися.
mount -o compress=zstd:5 mount /dev/bcache0 /mnt/meganas
Можно посмотреть информацию о том заполнен ли чем то кеш и есть ли проблеммы
watch cat /sys/block/bcache0/bcache/state
watch cat /sys/block/bcache0/bcache/dirty_data
Так же о монтировании в fstab с функцией сжатия
UUID=a8e75a9d-a6f6-4c6e-be41-c10bc1077aa2 /data btrfs compress=zstd:5 0 0
Теперь если требутся отключить диск с кешем
echo e0bae1a5-4f68-4066-a7b6-5d0f16dd63da > /sys/block/bcache0/bcache/detach
и соответсвенно включить можно командой
echo e0bae1a5-4f68-4066-a7b6-5d0f16dd63da > /sys/block/bcache0/bcache/attach
Вот и всё, технически даже проще чем LVM, хотя козалось наооборот.
Время покажет, будет ли всё хорошо.


== ZFS на Proxmox ==
== ZFS на Proxmox ==

Версия от 17:15, 1 июля 2023

systemctl restart sshsystemctl restart ssh

Демонстрация Proxmox

Описание

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

Подготовка

Демонстрация настроек Rufus

На сервер установлен Proxmox (Гипервизор) версия 6.1-1. Брать с официального сайта.

  1. Скачиваем образ и записываем на USB накопитель.
  2. Делать лучше всего с помощью Rufus. Брать с официального сайта. Распространяется бесплатно.
  3. Устройство: выбираем наш USB накопитель.
  4. Метод загрузки: выбираем скачанный образ.
  5. Схема раздела: GPT (если совсем устаревшее железо, не совместимое с UEFI, то выбираем MBR)
  6. Старт.
  7. Ожидаем, когда запишется образ на USB накопитель.

Установка Proxmox

Загружаемся с USB накопителя. Появляется логотип Proxmox с выбором установки.

  • Выбираем: Install Proxmox VE.

Ожидаем, когда загрузится менеджер установки.

Соглашаемся с условиями: I agree.

  • Target Harddisk: Выбираем накопитель на который будет выполняться установка. Это 120 Гигабайт SSD.

Нажимаем: “Options”.

  • Выбор файловой системы ext4.
Filesystem: ext4
  • Общий размер раздела для установки.
hdsize: 120.0
  • Размер виртуальной оперативной памяти 2 гигабайта.
swapsize: 2

OK, Next, Next.

  • Вводим пароль для пользователя root, и второй раз для подтверждения.
Password: пароль_пользователя_root
  • Указываем почту, на случай если захотим получать оповещения о статусе Proxmox.
E-Mail: наша_почта

Next.

Сетевое устройство, с которым будем работать, сейчас такое, меняется в зависимости от оборудования.

Management Interface: ens33

IP адрес сейчас такой, это зависит от того, что присвоит DHCP сервер. Его лучше всего привязать к MAC адресу. Описывается в разделе сеть.

Убедившись в том, что адрес получен нажимаем Next.

Нам показывают все что мы настроили.

Наш сервер имеет имя: pve

IP адрес у него: 192.168.1.130

Install.


Дожидаемся установки Proxmox.

По окончании установки нам сообщают что все хорошо.

Для продолжения будет выполнена перезагрузка, после того как выполнится загрузка ОС можно попасть на сервер с помощью web браузера, используя локальный IP и порт 8006.


В моём случае: https://192.168.1.130:8006

Браузер скажет, что сайт небезопасен, но мы то знаем, что он наш, так что нечего бояться. Нас встречает экран авторизации Proxmox.

  • Сразу меняем язык на русский.
Language: Русский.

Интерфейс сразу же перезагрузиться, и все станет на русском.

Вводим имя пользователя: root

И пароль: пароль_пользователя_root

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

На данном этапе установка Proxmox закончена. Дальнейшие действия зависят от требований.

Первичная настройка Proxmox.

Теперь создаем для себя рабочую атмосферу.

Proxmox является готовым продуктом, но как ни крути настраивать его все ещё приходится по старике. А точнее то что касается аппаратных средств, монтирование дисков и так далее.

Самое главное установить SSH. Нужен для удаленного доступа к консоли сервера. Так как начинают работать все фишки консоли. Например, в Window PowerShell. Так намного быстрее можно вводить команды, производить копирование правым нажатием мыши, выделение текста.

Переходим в web интерфейсе в узел Датацентр/pve.

В узле переходим в “Оболочка”.

Открывается консоль с доступом к Proxmox на прямую. В ней уже выполнен вход от root. Но для более удобной работы с открываем PowerShell. Да мы гребаные “виндусятники”!

В PowerShell уже встроен клиент SSH. Вписываем локальный адрес Proxmox. Соглашаемся: yes.

ssh root@192.168.1.164

Вводим пароль Proxmox: пароль_пользователя_root

Все мы попали в консоль, теперь:

Обновляем репозитории:

Демонстрация PowerShell
apt-get update

Выполняем обновление пакетов из репозиториев.

apt-get upgrade -y

Устанавливаем файловый менеджер mc

apt-get install mc -y

Proxmox готов к работе.

Настройка сети

в консоли pve

apt-get install ifupdown2

Для устройств SMB и Plex решено виртуализировать собственную подсеть, для снижения нагрузки на канал вне сервера (Чиать далее).

Демонстрация добавления виртуального сетевого адаптера

В разделе pve выбираем Система/Сеть.

Нажимаем: “Создать”

Выбираем: Linux Bridge

Прописываем адрес IPv4: 192.168.2.1/24

Все виртуальная сетевая карта есть.

Настройка виртуальных машин

О моём хранилище

Чтож - это большая тема! Со временем моё хранилище эволюционировало и модифицировалось. Начиналось всё с одного диска на 8 террабайт, сейчас на илюль 2023 года хранилище состоит из 10 накопителей по 12 террабайт и одного NVME PCIe GEN 3 на 1 террабайт под кеш.

Сначачала рейдов не было, но когда я купил 3 одинаковых накопителя, сразу же встал вопрос, какой рейд выбирать. На тот момент пал выбор именно на ZFS RAIDZ (аналог рейда 5), казался лучшим выбором. Затем через год расщирился до 5ти дисков, помучился с невозможностью расширить, пришлось искать накопители для переноса. на пяти дисках так же осатвался с аналогом рейда 5 от ZFS. Всё в общем то устраивало, но когда объем упал до 30 процентов, очень сильно стало сказываться на производительности. Так же колличесво оперативной памяти потреблялось черезвычайно много.

А так же очень затруднительная сложность найти обеём на стороне для сохранения информации, застатвила задуматься о перехоже на дрйгой програмный рейд, который бы позволил расширять себя налету. Выбр пал на MD рейд. В простонародье NDADM.

Куплено еще 5 накопителей. Сервер уже насчитвает 10 дисков. Теоритическим объемом 120 террабайт. Умопомрачительные объёмы надо сказать, для одного человека.

При данном колличесве накопителей надёжность всётаки уже кажется очень важной. Я уже готов пожертвовать 2 накопителя из 10 на четность. Потому выбирается Raid6.

Что в общем то и делается.

Вот небольшая инструкция как сделать.

Для начала нужно затереть все накопители. Есть много способов, воспользоваться утилитой fdisk и удалить разделы и так далее:

DD

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

Уничтоже всё что есть в анчале разделов и таблице, несмотря на занятость и востребованость. Станет не сразу понятно, но после перезагрузки, уже ничего не будет. Легко можно затереть системный раздел.

dd if=/dev/zero of=/dev/sdb

Та же можно затереть требуемым размером блоков, скорость будет выше:

dd if=/dev/zero of=/dev/sdb bs=2M

Еще можно сказать чтобы было записан нужное число раз, наприемер 2 мегабайта 1000 раз:

dd if=/dev/zero of=/dev/sdb bs=2M count=1000

Про DD в данных рамках пока что все.

wipefs

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

Есть поумолчанию в линусе, потому очень удобно.

Уже чувствительна к тому используется ли где то что нужно затереть. Но если всё свободно то отлично стирает все зписи о разделах.

wipefs -a /dev/md1

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

Тут на удивление всё просто. Я рассмотрю 2 варианта Raid0 и Raid6. Нулевой рейд мен пригодился при копировании всей информации с моих дисков, это сильно экономит время, а так же скорость хорошая. Использовать для временного переноса всего очень нужная тема.

mdadm --create /dev/md0 --level=6 --raid-devices=10 /dev/sd{a,b,c,d,e,...}

--level=6 - тип рейда 6 (всегда 2 диска в запасе), 0 (все диски - один большой диск)

--raid-devices=10 - количесво дисков, в моём случае 10

Далее перечислить диски

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

Псомтреть статус можно камандой:

cat /proc/mdstat

А так же дополнительную информацию командой

mdadm --detail /dev/md0

Далее можно уже создать файловую систему на нашем рейд массиве

mkfs.ext4 /dev/md0

Но это уже в прошлом. Теперь нужно создать прослойку для того чтобы можно было задействовать SSD кеш.

В процессе я столкнулся с двумя способами реализации данного метода. Вообще их даже 3. Превый я описываю в другой статье, можно назвать его ZTF, так как эта ФС поумолчанию может в использование SSD накопителя для кеширования.


LVM Cache

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

Вот ссылка на статью.

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

Сделай

lsblk

Чтобы посмотреть что там по дискам, произведи стирание дисков по иснтрукциям выше.

Из данных поняли что хранилищем данных у меня будет /dev/md0, а кешом станет /dev/nvme0n1.

Еще раз чтобы было понятно:

/dev/md0 - рейд массив с дисками

/dev/nvme0n1 - диск под кеш


Теперь на основе это выполняю команды.

Инициализируем нужные нам диски как LVM

pvcreate /dev/md0
pvcreate /dev/nvme0n1

Создадим группу томов по имени ssdcache

vgcreate ssdcache /dev/md0 /dev/nvme0n1

Тут может возникнуть ошибка которая говорит от том что размеры блоков разные это нужно испраялть настройками:

nano /etc/lvm/lvm.conf

найти, исправить значение и разкоментировать строку

allow_mixed_block_sizes =1 

Создадим логический том на нашем хранилище с именем hdd_data

lvcreate -l 100%FREE -n hdd_data ssdcache /dev/md0

Создадим тома на нашем кеше, сначала раздел 16 гигобайт, для метаданных, больще нельзя. Имя дадим ssd_meta.

lvcreate -L 16G -n ssd_meta ssdcache /dev/nvme0n1

Созадим том на оставшийся объем по имени ssd_data.

lvcreate -l 90%FREE -n ssd_data ssdcache /dev/nvme0n1

Далее операция не совсем мне понятная

lvconvert --type cache-pool --poolmetadata ssdcache/ssd_meta ssdcache/ssd_data

При создании данной операции может возникунуть предупреждение о рахмере блока. "Using 2.00 MiB chunk size instead of default 64.00 KiB, so cache pool has less than 1000000 chunks."

Это лиш говорит о том что система выбрала размер блока отличного от размера по умолчанию.

И запустим работу с настройкой режима writeback

lvconvert --type cache --cachemode writeback --cachepool ssdcache/ssd_data ssdcache/hdd_data

Есть два режима кеширования:

  • Writeback — данные сначала пишутся в кэш, затем на диск. Это более производительный вариант. При сбое кэширующего SSD диска, вы потеряете данные, которые не успели записаться на HDD. Хотя и не рекомендуется использовать этот режим на серверах с SSD без RAID, мне кажется с учетом надежности SSD дисков, это вполне рабочее решение.
  • Writethrough — данные сразу пишутся одновременно на диск и в кэш, после чего наиболее часто используемые попадают в кэш. Это безопасный вариант, подходит для серверов с 1*SSD, но гораздо менее производительный.

После выполнения всех настроек, можно проверить кэш на наличие ошибок:

lvs -a

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

mkfs.ext4 /dev/ssdcache/hdd_data

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

Так же можно узнать UUID и прописать в fstab, для автозапуска.

blkid|grep cache

После чего всё уже должно работать.

Посмотреть какой статус можной командой:

lvs -o+cache_mode ssdcache

Так же иногда хочется наблюдать

watch lvs -o+cache_mode ssdcache

Для смены режима, используются команды:

lvchange --cachemode writeback ssdcache
lvchange --cachemode writethrough ssdcache

Так же если нужно заменить SSD накопитель, или просто отключить работу кеша, на время

lvconvert --uncache /dev/ssdcache/hdd_data
vgreduce ssdcache /dev/nvme0n1
pvremove /dev/nvme0n1

После этого всё будт работать без использования кеша.

Чтобы добавить диск обратно

pvcreate /dev/nvme0n1
vgextend ssdcache /dev/nvme0n1
lvcreate -L 16G -n ssd_meta ssdcache /dev/nvme0n1
lvcreate -l 90%FREE -n ssd_data ssdcache /dev/nvme0n1
lvconvert --type cache-pool --poolmetadata ssdcache/ssd_meta ssdcache/ssd_data
lvconvert --type cache --cachemode writeback --cachepool ssdcache/ssd_data ssdcache/hdd_data

Это всё о настройке данного кеша.

Прирост скорости действительно есть. Но я рещил рассмотреть еще варинаты исполнения данной функции.


Bcache

Решил я посмотреть и на этот вид кеширования. Я не очень склонялся на использрвание данного решения, так как информация не столь приятно и понятнр изложена как с LVM. Но я разобрался.

Почему я остановлся на именно этом варианте?

Производительность у данного споба всёже выше. На одинаковом массиве данных этот спасоб показывает всегода одинкавый результат, в отлиции от LVM.

А функционал такой же и даже больше, например сжатие. Это практически полностью затмевает ZTF.

Опять же припомню мой случай:

/dev/md0 - рейд массив с дисками

/dev/nvme0n1 - диск под кеш

Создам bcache на дисках

make-bcache -B /dev/md0

Создам bcache на SSD диске

make-bcache -C /dev/nvme0n1

Теперь нужно узнать uuid диска с кешом

bcache-super-show /dev/nvme0n1 | grep cset

Полученый uuid зарегистровать для нашего хранилища

echo e0bae1a5-4f68-4066-a7b6-5d0f16dd63da > /sys/block/bcache0/bcache/attach

Влючить обратный режим записи. Чтобы кеш работал на запись

echo writeback > /sys/block/bcache0/bcache/cache_mode

Дальше можно отформатировать раздел в btrfs, назавём его STORAGE

mkfs.btrfs -L STORAGE /dev/bcache0

И в целом всё. Оно уже работает, можно монтировать и использовать.

Так же можно примонтировать раздел с функцией сжатися.

mount -o compress=zstd:5 mount /dev/bcache0 /mnt/meganas

Можно посмотреть информацию о том заполнен ли чем то кеш и есть ли проблеммы

watch cat /sys/block/bcache0/bcache/state
watch cat /sys/block/bcache0/bcache/dirty_data

Так же о монтировании в fstab с функцией сжатия

UUID=a8e75a9d-a6f6-4c6e-be41-c10bc1077aa2 /data btrfs compress=zstd:5 0 0

Теперь если требутся отключить диск с кешем

echo e0bae1a5-4f68-4066-a7b6-5d0f16dd63da > /sys/block/bcache0/bcache/detach

и соответсвенно включить можно командой

echo e0bae1a5-4f68-4066-a7b6-5d0f16dd63da > /sys/block/bcache0/bcache/attach

Вот и всё, технически даже проще чем LVM, хотя козалось наооборот.

Время покажет, будет ли всё хорошо.

ZFS на Proxmox

raidz

создать массив raidz из трёх накопителей

смотрим id накопителей

ls /dev/disk/by-id/

в моем случае

ata-TOSHIBA_MG07ACA12TE_2050A07PF95G

ata-TOSHIBA_MG07ACA12TE_59D0A12KF95G

ata-TOSHIBA_MG07ACA12TE_60C0A07XF95G

из них и создадим массив raidz

набор команд и параметров взят от сюда преобразовано в такой вид: название пула meganas, тип пула raidz.

zpool create -o ashift=12 meganas raidz /dev/disk/by-id/ata-TOSHIBA_MG07ACA12TE_2050A07PF95G /dev/disk/by-id/ata-TOSHIBA_MG07ACA12TE_59D0A12KF95G /dev/disk/by-id/ata-TOSHIBA_MG07ACA12TE_60C0A07XF95G

после чего смотрим статус

zpool status

сообщается что нужно обновить для включения фич

zpool upgrade meganas

Кеш SSD

я подключаю SSD кеш, на чтение. Делаю это на ssd на 960 гигабайт, создав раздел на 120 гигабайт. И именно этот раздел и подключаю к массиву.

ls /dev/disk/by-id/

id раздела в моём случае

ata-Netac_SSD_960GB_AA000000000000000878-part1

подключаем

zpool add -f meganas cache /dev/disk/by-id/ata-Netac_SSD_960GB_AA000000000000000878-part1

теперь есть кеш

Точка монтирования

создадим папку для точки монтирования пула

mkdir /mnt/meganas

сразу меняем точку монтирования

zfs set mountpoint=/mnt/meganas meganas

Создание ФС

теперь создадим файловую систему для сервер NAS

zfs create meganas/nas

и еще одну ФС для Nextcloud

zfs create meganas/nextcloud


Посмотреть какие есть Папки:

zfs list

Удалить папку:

zfs destroy meganas/nextcloud

видим таблицу, того к каким из каталогов применены наши настройки. Команды указаны тут. А тут указывается методы просмотра информации.

источники

инфа про монтирование

инструкция о создании массива и некоторых важных настройках

Большой ман по множеству настроек NFS (Английский)

Манул по работе с ФС добавление каталогов

Информация о настройках хранилища в proxmox (Английский)

Статься о создании и настройках habr

Настройки ФС

Теперь о фичах, это максимально важно

компрессия данных, нужна даже если преобладает несжимаемые данные, особенность ФС писать данные блоками определённого объема, файлы меньше блока, иногда будут размером с блок. Сжатие позволит избавиться как минимум от этой особенности.

zfs set compression=on meganas/название каталога

и тип компрессии ставим lz4

zfs set compress=lz4 meganas/название каталога

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

Очень важная настройка sync. Для повышения производительности пула можно отключить синхронизацию. Обратите внимание что при отключенной синхронизации возможна потеря данных при отключении питания. Но прирост к скорости на больших файлах 100 процентов.

zfs set sync=disabled meganas/каталог ФС

Опции atime=off и relatime=on значительно повысят производительность ФС, соответственно пожертвовав метками времени доступа к файлам.

zfs set atime=off meganas/каталог ФС
zfs set relatime=on meganas/каталог ФС

Еще одна настройка для работы с NFS

zfs set sharenfs=on meganas/каталог ФС

Без этих настроек все сверх уныло


Посмотреть с подробностями по каждой папке, какие параметры были даны:

zfs list -o name,sharenfs,mountpoint,compression,sync,atime,relatime

Импорт пула

Если системы больше нет, но нужно вернуть пул с дисков в рабочее состоянии

zpool import

увидим название и вообще то что есть пул и с ним всё ок

теперь сделаем полноценный импорт

zpool import -f meganas

Пул на месте, если была точка монтирования то он примонтируется. Если нет:

zfs mount -a


NFS

Устанавливаем серверную часть.

apt-get install nfs-kernel-server 

Далее редактируем конфиг

nano /etc/exports 

Добавляем нашу папку, и указываем нужную нам подсеть.

/mnt/meganas/nas 192.168.2.0/24(rw,sync,no_subtree_check,no_root_squash)
/mnt/meganas/nextcloud 192.168.2.0/24(rw,sync,no_subtree_check,no_root_squash)

Запускаем службы

/etc/init.d/nfs-kernel-server start
service nfs-kernel-server restart
exportfs -ra

Готово.


Контейнеры

Открыл для себя контейнеры.

Хорошо экономит ресурсы, как памяти так и мощности.

Для использования контейнера в ProxMox нужно загрузить шаблон.

Делать это нужно в консоли хоста (сам сервер proxmox).

pveam update

показать список:

pveam available

я выбрал для себя ubuntu-20.04, просто привычнее. Скачиваем шаблон:

pveam download local ubuntu-20.04-standard_20.04-1_amd64.tar.gz

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

Перво наперво, это создать пользователя. Это иногда требуется. Потому, по умолчанию есть только ROOT. Из за этого не работает ssh из коробки.

adduser vova

Задаём ему пароль 2 раза. Будет вопрос по дополнительным данным, если ничего не нужно просто нажимаем ENTER. В конце соглашаем с тем что все правильно.

Дадим права пользователю

usermod -a -G sudo vova

После чего можно попасть на нашу контейнер по ssh


Есть и второй способ, не безопасный но быстрый. В файле /etc/ssh/sshd_config

nano /etc/ssh/sshd_config

Найти строку и сделать такой:

PermitRootLogin yes

Послу чего перезагрузить службу ssh

systemctl restart ssh


Далее лучше всего сделать обновление:

apt update
apt upgrade -y


Теперь неплохо установит русскую локаль.

dpkg-reconfigure locales

Выбираем из списка ru_RU.UTF-8

Её же в следующем меню

Готово

После перезапуска терминала будут доступны русские символы.

Установим часовой пояс как надо.

timedatectl set-timezone Asia/Omsk

и проверим время

timedatectl

Не лишним будет поставить MC

apt install mc


Как оказалось еще нет ADD-APT-REPOSITORY

apt install software-properties-common


Теперь расшарим папку из нашего Хоста внутрь контейнера, чтобы не было всяких там NFS.

Для это отредактируем файл конфигурации нашего контейнера. Они находятся /etc/pve/lxc/

Выполняем это на хосте, машине с proxmox

nano /etc/pve/lxc/номер.conf

Я хочу пробросить паку с ZFS рейда расположенную на хосте /mnt/meganas/nas/media/ в папку /media/nas/ в контейнере.

Добавлю строку в файл конфигурации

mp0: /mnt/meganas/media,mp=/media/nas

На машине контейнере создаём папку /media/nas

mkdir /media/nas

перезагружаем контейнер


Установка NVIDIA - Ускорение в контейнерах.

Ссылка