Proxmox как удалить диск
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
fireon
Famous Member
i've tested something with an HDD. I've created in the GUI an EXT4 disk and added this automatically to the storage's. So i would delete it. But there is no button for removing directories. On CMD i also nothing found about. Only the file "/etc/pve/.rrd" there is this entry, but this file is not variable.
Attachments
Best Regards
Fireon
dietmar
Proxmox Staff Member
Best regards,
Dietmar
Do you already have a Commercial Support Subscription? - If not, Buy now and read the documentation
fireon
Famous Member
I also unpluged the hdd from the server but nothing, the entry didn't go away.
Best Regards
Fireon
dietmar
Proxmox Staff Member
Best regards,
Dietmar
Do you already have a Commercial Support Subscription? - If not, Buy now and read the documentation
fireon
Famous Member
Best Regards
Fireon
fireon
Famous Member
Best Regards
Fireon
dietmar
Proxmox Staff Member
Just verified the code, but what you describe is not really possible - at least I can't see how that happens. Maybe it is a browser problem? Already tried to clear the browser cache, or used another browser?
Best regards,
Dietmar
Do you already have a Commercial Support Subscription? - If not, Buy now and read the documentation
fireon
Famous Member
Just verified the code, but what you describe is not really possible - at least I can't see how that happens. Maybe it is a browser problem? Already tried to clear the browser cache, or used another browser?
What should i say. it's there. Removed the firefoxconfig, and tested with fresh chromium. Same problem. Proxmox will mount the disk. But the disk was removed. No enry in the file "/etc/pve/.rrd".
ZFS (Zettabyte File System) — файловая система, изначально созданная в Sun Microsystems для операционной системы Solaris. Эта файловая система поддерживает большие объёмы данных, объединяет концепции файловой системы и менеджера логических дисков (томов) и физических носителей, новаторскую структуру данных на дисках, легковесные файловые системы (англ. lightweight filesystems), а также простое управление томами хранения данных. ZFS является проектом с открытым исходным кодом и лицензируется под CDDL (Common Development and Distribution License).
Основное преимущество ZFS — это её полный контроль над физическими и логическими носителями. Зная, как именно расположены данные на дисках, ZFS способна обеспечить высокую скорость доступа к ним, контроль их целостности, а также минимизацию фрагментации данных. Это позволяет динамически выделять или освобождать дисковое пространство на одном или более носителях для логической файловой системы. Кроме того, имеет место переменный размер блока, что лучшим образом влияет на производительность, параллельность выполнения операций чтения-записи, а также 64-разрядный механизм использования контрольных сумм, сводящий к минимуму вероятность незаметного разрушения данных.
В Proxmox VE с помощью ZFS можно позволить себе репликацию данных на другой гипервизор, миграцию виртуальной машины/LXC контейнера, доступ к LXC контейнеру с хост-системы и так далее.
1.2. Пулы хранения.
В отличие от традиционных файловых систем, которые располагаются на одном устройстве и, следовательно, при использовании более чем на одном устройстве для них требуется менеджер томов, ZFS строится поверх виртуальных пулов хранения данных, называемых zpool. Пул построен из виртуальных устройств (vdevs), каждое из которых является либо физическим устройством, либо зеркалом (RAID 1) одного или нескольких устройств, либо (RAID Z) — группой из двух или более устройств. Ёмкость всех vdevs затем доступна для всех файловых систем в zpool.
Для ограничения пространства, доступного конкретной файловой системе или тому, может быть установлена квота. Кроме того, возможно использование дискового резервирования (лимита) — это гарантирует, что всегда будет оставаться некоторый доступный объём для конкретной файловой системы или тома.
Каждый пул хранения состоит из одного или нескольких виртуальных устройств (virtual device, vdev). В свою очередь, каждый vdev включает одно или несколько реальных устройств. Большинство виртуальных устройств используются для простого хранения данных, но существует несколько вспомогательных классов vdev, включая CACHE, LOG и SPECIAL. Каждый из этих типов vdev может иметь одну из пяти топологий: единое устройство (single-device), RAIDz1, RAIDz2, RAIDz3 или зеркало (mirror).
RAIDz1, RAIDz2 и RAIDz3 — это особые разновидности того, что назовут RAID двойной (диагональной) чётности. 1, 2 и 3 относятся к тому, сколько блоков чётности выделено для каждой полосы данных. Вместо отдельных дисков для обеспечения чётности виртуальные устройства RAIDz полуравномерно распределяют эту чётность по дискам. Массив RAIDz может потерять столько дисков, сколько у него блоков чётности; если он потеряет ещё один, то выйдет из строя и заберет с собой пул хранения.
В зеркальных виртуальных устройствах (mirror vdev) каждый блок хранится на каждом устройстве в vdev. Хотя наиболее распространённые двойные зеркала (two-wide), в зеркале может быть любое произвольное количество устройств — в больших установках для повышения производительности чтения и отказоустойчивости часто используются тройные. Зеркало vdev может пережить любой сбой, пока продолжает работать хотя бы одно устройство в vdev.
Одиночные vdev по своей сути опасны. Такое виртуальное устройство не переживёт ни одного сбоя — и если используется в качестве хранилища или специального vdev, то его сбой приведёт к уничтожению всего пула. Будьте здесь очень, очень осторожны.
Виртуальные устройства CACHE, LOG и SPECIAL могут быть созданы по любой из вышеперечисленных топологий — но помните, что потеря виртуального устройства SPECIAL означает потерю пула, поэтому настоятельно рекомендуется избыточная топология.
1.3. Встроенное сжатие.
Механизм копирования при записи также упрощает систему встроенного сжатия. В традиционной файловой системы сжатие проблематично — как старая версия, так и новая версия изменённых данных находятся в одном и том же пространстве.
Если рассмотреть фрагмент данных в середине файла, который начинает свою жизнь как мегабайт нулей от 0x00000000 и так далее — его очень легко сжать до одного сектора на диске. Но что произойдёт, если мы заменим этот мегабайт нулей на мегабайт несжимаемых данных, таких как JPEG или псевдослучайный шум? Неожиданно этому мегабайту данных потребуется не один, а 256 секторов по 4 КиБ, а в этом месте на диске зарезервирован только один сектор.
У ZFS нет такой проблемы, так как изменённые записи всегда записываются в неиспользуемое пространство — исходный блок занимает только один сектор 4 КиБ, а новая запись займёт 256, но это не проблема — недавно изменённый фрагмент из «середины» файла был бы записан в неиспользуемое пространство независимо от того, изменился его размер или нет, поэтому для ZFS это вполне штатная ситуация.
Встроенное сжатие ZFS отключено по умолчанию, и система предлагает подключаемые алгоритмы — сейчас среди них LZ4, gzip (1-9), LZJB и ZLE.
- LZ4 — это потоковый алгоритм, предлагающий чрезвычайно быстрое сжатие и декомпрессию и выигрыш в производительности для большинства случаев использования — даже на довольно медленных CPU.
- GZIP — почтенный алгоритм, который знают и любят все пользователи Linux-систем. Он может быть реализован с уровнями сжатия 1-9, с увеличением степени сжатия и использования CPU по мере приближения к уровню 9. Алгоритм хорошо подходит для всех текстовых (или других чрезвычайно сжимаемых) вариантов использования, но в противном случае часто вызывает проблемы c CPU — используйте его с осторожностью, особенно на более высоких уровнях.
- LZJB — оригинальный алгоритм в ZFS. Он устарел и больше не должен использоваться, LZ4 превосходит его по всем показателям.
- ZLE — кодировка нулевого уровня, Zero Level Encoding. Она вообще не трогает нормальные данные, но сжимает большие последовательности нулей. Полезно для полностью несжимаемых наборов данных (например, JPEG, MP4 или других уже сжатых форматов), так как он игнорирует несжимаемые данные, но сжимает неиспользуемое пространство в итоговых записях.
Рекомендуется сжатие LZ4 практически для всех вариантов использования. Штраф за производительность при встрече с несжимаемыми данными очень мал, а прирост производительности для типичных данных значителен. Копирование образа виртуальной машины для новой инсталляции операционной системы Windows (свежеустановленная операционная система, никаких данных внутри ещё нет) с compression=lz4 прошло на 27% быстрее, чем с compression=none .
1.4. Секторы.
Последний, самый базовый строительный блок — сектор. Это наименьшая физическая единица, которая может быть записана или считана с базового устройства. В течение нескольких десятилетий в большинстве дисков использовались секторы по 512 байт. В последнее время большинство дисков настроено на сектора 4 КиБ, а в некоторых — особенно SSD — сектора 8 КиБ или даже больше.
В системе ZFS есть свойство, которое позволяет вручную установить размер сектора. Это свойство ashift. Несколько запутанно, что ashift является степенью двойки. Например, ashift=9 означает размер сектора 2^9, или 512 байт.
ZFS запрашивает у операционной системы подробную информацию о каждом блочном устройстве, когда оно добавляется в новый vdev, и теоретически автоматически устанавливает ashift должным образом на основе этой информации. К сожалению, многие диски лгут о своём размере сектора, чтобы сохранить совместимость с Windows XP (которая была неспособна понять диски с другими размерами секторов).
Это означает, что администратору ZFS настоятельно рекомендуется знать фактический размер сектора своих устройств и вручную устанавливать ashift. Если установлен слишком маленький ashift, то астрономически увеличивается количество операций чтения/записи. Так, запись 512-байтовых «секторов» в реальный сектор 4 КиБ означает необходимость записать первый «сектор», затем прочитать сектор 4 КиБ, изменить его со вторым 512-байтовым «сектором», записать его обратно в новый сектор 4 КиБ и так далее для каждой записи.
В реальном мире такой штраф бьёт по твёрдотельным накопителям Samsung EVO, для которых должен действовать ashift=13 , но эти SSD врут о своём размере сектора, и поэтому по умолчанию устанавливается ashift=9 . Если опытный системный администратор не изменит этот параметр, то этот SSD работает медленнее обычного магнитного HDD.
Для сравнения, за слишком большой размер ashift нет практически никакого штрафа. Реального снижения производительности нет, а увеличение неиспользуемого пространства бесконечно мало (или равно нулю при включённом сжатии). Поэтому мы настоятельно рекомендуем даже тем дискам, которые действительно используют 512-байтовые секторы, установить ashift=12 или даже ashift=13 , чтобы уверенно смотреть в будущее.
Внимание! Свойство ashift устанавливается для каждого виртуального устройства vdev, а не для пула, как многие ошибочно думают — и не изменяется после установки. Если вы случайно сбили ashift при добавлении нового vdev в пул, то вы безвозвратно загрязнили этот пул устройством с низкой производительностью и, как правило, нет другого выхода, кроме как уничтожить пул и начать всё сначала. Даже удаление vdev не спасёт от сбитой настройки ashift!
Вывод
Если есть вопросы, то пишем в комментариях.
Также можете вступить в Телеграм канал, ВК или подписаться на Twitter. Ссылки в шапки страницы.
Заранее всем спасибо.
4. Удаление хранилища.
Удаление производится простым способом. Паркуем все виртуальные машины, которые используют данное хранилище, размонтируем хранилище и удалим его.
Внимание! Удаление не предусматривает запроса на подтверждение. Имейте в виду. Удаляется сразу.
Рассмотрим два варианта добавления физических дисков в гипервизоре Proxmox.
После физического подключения диска к серверу необходимо получить информацию об аппаратной части в Proxmox, а точнее проверить наличие диска (рис.1). Чтобы узнать информацию о всех блочных устройствах воспользуемся командой "lsblk" (рис.2):
1. Создаем раздел на новом диске (В первый раз будет предложено создать файловую систему gpt):
> New -> (Выбираем объем раздела) (рис.3)
> Primary - Выбираем тип раздела
> Write -> "yes" - Сохраняем настройки (рис.4)
2. Форматируем новый раздел в формат "ext4"
3. Чтобы подключить диск, создадим новую папку (можно задать любое имя папки и точку монтирования, мы выбрали "SATA2"):
7. Подключаемся к гипервизору через web-интерфейс. Чтобы добавить новую директорию, проходим по пути: Datacenter> Storage> Add> Directory (рис.5). В открывшемся окне (рис.6), указываем следующие параметры: "ID" - имя хранилища, "Directory" - путь к новой папке, "Content" - что будет храниться на новом диске.
Рассмотрим второй вариант подключения диска в качестве LVM (LVM-thin) менеджер логических томов в области нового диска, который может хранить образы дисков виртуальных машин и контейнеров.
За последние несколько лет я очень тесно работаю с кластерами Proxmox: многим клиентам требуется своя собственная инфраструктура, где они могут развивать свой проект. Именно поэтому я могу рассказать про самые распространенные ошибки и проблемы, с которыми также можете столкнуться и вы. Помимо этого мы конечно же настроим кластер из трех нод с нуля.
Proxmox кластер может состоять из двух и более серверов. Максимальное количество нод в кластере равняется 32 штукам. Наш собственный кластер будет состоять из трех нод на мультикасте (в статье я также опишу, как поднять кластер на уникасте — это важно, если вы базируете свою кластерную инфраструктуру на Hetzner или OVH, например). Коротко говоря, мультикаст позволяет осуществлять передачу данных одновременно на несколько нод. При мультикасте мы можем не задумываться о количестве нод в кластере (ориентируясь на ограничения выше).
Сам кластер строится на внутренней сети (важно, чтобы IP адреса были в одной подсети), у тех же Hetzner и OVH есть возможность объединять в кластер ноды в разных датацентрах с помощью технологии Virtual Switch (Hetzner) и vRack (OVH) — о Virtual Switch мы также поговорим в статье. Если ваш хостинг-провайдер не имеет похожие технологии в работе, то вы можете использовать OVS (Open Virtual Switch), которая нативно поддерживается Proxmox, или использовать VPN. Однако, я рекомендую в данном случае использовать именно юникаст с небольшим количеством нод — часто возникают ситуации, где кластер просто “разваливается” на основе такой сетевой инфраструктуры и его приходится восстанавливать. Поэтому я стараюсь использовать именно OVH и Hetzner в работе — подобных инцидентов наблюдал в меньшем количестве, но в первую очередь изучайте хостинг-провайдера, у которого будете размещаться: есть ли у него альтернативная технология, какие решения он предлагает, поддерживает ли мультикаст и так далее.
Установка Proxmox
Proxmox может быть установлен двумя способами: ISO-инсталлятор и установка через shell. Мы выбираем второй способ, поэтому установите Debian на сервер.
Перейдем непосредственно к установке Proxmox на каждый сервер. Установка предельно простая и описана в официальной документации здесь.
Добавим репозиторий Proxmox и ключ этого репозитория:
Обновляем репозитории и саму систему:
После успешного обновления установим необходимые пакеты Proxmox:
Заметка: во время установки будет настраиваться Postfix и grub — одна из них может завершиться с ошибкой. Возможно, это будет вызвано тем, что хостнейм не резолвится по имени. Отредактируйте hosts записи и выполните apt-get update
Изображение 1. Веб-интерфейс ноды Proxmox
Распространенные ошибки, возникающие при удалении виртуальной машины в Proxmox
Недавно столкнулся с невозможностью удалить виртуальную машину в Proxmox. И как оказалось существует несколько распространенных случаев невозможности удаления виртуальных машин из Proxmox. Давайте рассмотрим их.
3. Добавление нового хранилища.
Добавляем новое хранилище в web-панели управления Proxmox VE.
Переходим в web-интерфейс панели управления Proxmox VE, Выбираем сервер виртуальных машин и раздел «Диски» — «ZFS»:
Готово! ZFS в строю.
Теперь мы можем использовать хранилище для размещения виртуальных машин и контейнеров.
Удалить виртуальную машину из командной строки
Чтобы удалить виртуальную машину из командной строки, сначала нам нужно найти VMID.
Как только мы войдем в узел. Мы используем приведенную ниже команду, чтобы найти ids — номер нашей виртуальной машины.
Данная команда выдаст нам примерно следующее:
Как только мы получим идентификатор, мы используем приведенную ниже команду, чтобы удалить его.
Таким образом, мы удаляем виртуальную машину в Proxmox.
В завершении
Надеюсь, что данная статья пригодится вам, когда вы будете настраивать Proxmox кластер в Hetzner. Если позволит время, то я расширю статью и добавлю инструкцию для OVH — там тоже не все очевидно, как кажется на первый взгляд. Материал получился достаточно объемным, если найдете ошибки, то, пожалуйста, напишите в комментарии, я их исправлю. Всем спасибо за уделенное внимание.
Автор: Илья Андреев, под редакцией Алексея Жадан и команды «Лайв Линукс»
Сегодня давайте обсудим, как можно удалить виртуальную машину в Proxmox.
Вы хотите удалить виртуальную машину в Proxmox? Мы можем помочь вам сделать это. И так начнем:
Репликация инстансов на соседний гипервизор
В кластере Proxmox есть возможность репликации данных с одного гипервизора на другой: данный вариант позволяет осуществлять переключение инстанса с одного сервера на другой. Данные будут актуальны на момент последней синхронизации — ее время можно выставить при создании репликации (стандартно ставится 15 минут). Существует два способа миграции инстанса на другую ноду Proxmox: ручной и автоматический. Давайте рассмотрим в первую очередь ручной вариант, а в конце я предоставлю вам Python скрипт, который позволит создавать виртуальную машину на доступном гипервизоре при недоступности одного из гипервизоров.
Для создания репликации необходимо перейти в веб-панель Proxmox и создать виртуальную машину или LXC контейнер. В предыдущих пунктах мы с вами настроили vmbr1 мост с NAT, что позволит нам выходить во внешнюю сеть. Я создам LXC контейнер с MySQL, Nginx и PHP-FPM с тестовым сайтом, чтобы проверить работу репликации. Ниже будет пошаговая инструкция.
Загружаем подходящий темплейт (переходим в storage —> Content —> Templates), пример на скриншоте:
Изображение 10. Local storage с шаблонами и образами ВМ
Нажимаем кнопку “Templates” и загружаем необходимый нам шаблон LXC контейнера:
Изображение 11. Выбор и загрузка шаблона
Теперь мы можем использовать его при создании новых LXC контейнеров. Выбираем первый гипервизор и нажимаем кнопку “Create CT” в правом верхнем углу: мы увидим панель создания нового инстанса. Этапы установки достаточно просты и я приведу лишь конфигурационный файл данного LXC контейнера:
Контейнер успешно создан. К LXC контейнерам можно подключаться через команду pct enter , я также перед установкой добавил SSH ключ гипервизора, чтобы подключаться напрямую через SSH (в PCT есть небольшие проблемы с отображением терминала). Я подготовил сервер и установил туда все необходимые серверные приложения, теперь можно перейти к созданию репликации.
Кликаем на LXC контейнер и переходим во вкладку “Replication”, где создаем параметр репликации с помощью кнопки “Add”:
Изображение 12. Создание репликации в интерфейсе Proxmox
Изображение 13. Окно создания Replication job
Я создал задачу реплицировать контейнер на вторую ноду, как видно на следующем скриншоте репликация прошла успешно — обращайте внимание на поле “Status”, она оповещает о статусе репликации, также стоит обращать внимание на поле “Duration”, чтобы знать, сколько длится репликация данных.
Изображение 14. Список синхронизаций ВМ
Теперь попробуем смигрировать машину на вторую ноду с помощью кнопки “Migrate”
Начнется миграция контейнера, лог можно просмотреть в списке задач — там будет наша миграция. После этого контейнер будет перемещен на вторую ноду.
Ошибка “Host Key Verification Failed”
Иногда при настройке кластера может возникать подобная проблема — она мешает мигрировать машины и создавать репликацию, что нивелирует преимущества кластерных решений. Для исправления этой ошибки удалите файл known_hosts и подключитесь по SSH к конфликтной ноде:
Примите Hostkey и попробуйте ввести эту команду, она должна подключить вас к серверу:
2. Подключаем диск в системе.
Подключаем физический диск к серверу и смотрим появился ли он в системе. Просто выполните действия в web-интерфейсе гипервизора Proxmox VE.
Инициализируем диск в GPT разметке диска.
Если всё хорошо, то преобразование может начаться сразу:
А может не начаться и выдать выдать ошибку:
Затем снова переходим в меню преобразования диска в GPT и операция завершается успешно.
Виртуальная машина Proxmox заблокирована
При анализе узла мы обнаружили, что виртуальная машина находится в состоянии блокировки. Итак, сначала мы найдем VMID — номер нашей виртуальной машины.
Затем мы используем команду, чтобы разблокировать виртуальную машину.
Как только мы разблокируем виртуальную машину, мы сможем удалить ее без каких-либо ошибок.
2. Подключаем диск в системе.
Подключаем физический диск к серверу и смотрим появился ли он в системе. Просто выполните действия в web-интерфейсе гипервизора Proxmox VE.
Инициализируем диск в GPT разметке диска.
Если всё хорошо, то преобразование может начаться сразу:
А может не начаться и выдать выдать ошибку:
Затем снова переходим в меню преобразования диска в GPT и операция завершается успешно.
Особенности сетевых настроек на Hetzner
Переходим в панель Robot и нажимаем на кнопку “Virtual Switches”. На следующей странице вы увидите панель создания и управления интерфейсов Virtual Switch: для начала его необходимо создать, а после “подключить” выделенные сервера к нему. В поиске добавляем необходимые сервера для подключения — их не не нужно перезагружать, только придется подождать до 10-15 минут, когда подключение к Virtual Switch будет активно.
После добавления серверов в Virtual Switch через веб-панель подключаемся к серверам и открываем конфигурационные файлы сетевых интерфейсов, где создаем новый сетевой интерфейс:
Давайте разберем подробнее, что это такое. По своей сути — это VLAN, который подключается к единственному физическому интерфейсу под названием enp4s0 (он у вас может отличаться), с указанием номера VLAN — это номер Virtual Switch’a, который вы создавали в веб-панели Hetzner Robot. Адрес можете указать любой, главное, чтобы он был локальный.
Отмечу, что конфигурировать enp4s0 следует как обычно, по сути он должен содержать внешний IP адрес, который был выдан вашему физическому серверу. Повторите данные шаги на других гипервизорах, после чего перезагрузите на них networking сервис, сделайте пинг до соседней ноды по IP адресу Virtual Switch. Если пинг прошел успешно, то вы успешно установили соединение между серверами по Virtual Switch.
Я также приложу конфигурационный файл sysctl.conf, он понадобится, если у вас будут проблемы с форвардингом пакетом и прочими сетевыми параметрами:
Добавление IPv4 подсети в Hetzner
Перед началом работ вам необходимо заказать подсеть в Hetzner, сделать это можно через панель Robot.
Создадим сетевой мост с адресом, который будет из этой подсети. Пример конфигурации:
Теперь переходим в настройки виртуальной машины в Proxmox и создаем новый сетевой интерфейс, который будет прикреплен к мосту vmbr2. Я использую LXC контейнер, его конфигурацию можно изменять сразу же в Proxmox. Итоговая конфигурация для Debian:
Обратите внимание: я указал 26 маску, а не 29 — это требуется для того, чтобы сеть на виртуальной машине работала.
Добавление IPv4 адреса в Hetzner
Ситуация с одиночным IP адресом отличается — обычно Hetzner дает нам дополнительный адрес из подсети сервера. Это означает, что вместо vmbr2 нам требуется использоваться vmbr0, но на данный момент его у нас нет. Суть в том, что vmbr0 должен содержать IP адрес железного сервера (то есть использовать тот адрес, который использовал физический сетевой интерфейс enp2s0). Адрес необходимо переместить на vmbr0, для этого подойдет следующая конфигурация (советую заказать KVM, чтобы в случае чего возобновить работу сети):
Перезапустите сервер, если это возможно (если нет, перезапустите сервис networking), после чего проверьте сетевые интерфейсы через ip a:
Как здесь видно, enp2s0 подключен к vmbr0 и не имеет IP адрес, так как он был переназначен на vmbr0.
Теперь в настройках виртуальной машины добавляем сетевой интерфейс, который будет подключен к vmbr0. В качестве gateway укажите адрес, прикрепленный к vmbr0.
Установка и настройка ZFS
ZFS — это файловая система, которая может использоваться совместно с Proxmox. С помощью нее можно позволить себе репликацию данных на другой гипервизор, миграцию виртуальной машины/LXC контейнера, доступ к LXC контейнеру с хост-системы и так далее. Установка ее достаточно простая, приступим к разбору. На моих серверах доступно три SSD диска, которые мы объединим в RAID массив.
Обновляем список пакетов:
Устанавливаем требуемые зависимости:
Устанавливаем сам ZFS:
Если вы в будущем получите ошибку fusermount: fuse device not found, try ‘modprobe fuse’ first, то выполните следующую команду:
Теперь приступим непосредственно к настройке. Для начала нам требуется отформатировать SSD и настроить их через parted:
Аналогичные действия необходимо произвести и для других дисков. После того, как все диски подготовлены, приступаем к следующему шагу:
zpool create -f -o ashift=12 rpool /dev/sda4 /dev/sdb4 /dev/sdc4
Применим некоторые настройки для ZFS:
Теперь нам надо рассчитать некоторые переменные для вычисления zfs_arc_max, я это делаю следующим образом:
В данный момент пул успешно создан, также мы создали сабпул data. Проверить состояние вашего пула можно командой zpool status. Данное действие необходимо провести на всех гипервизорах, после чего приступить к следующему шагу.
Теперь добавим ZFS в Proxmox. Переходим в настройки датацентра (именно его, а не отдельной ноды) в раздел «Storage», кликаем на кнопку «Add» и выбираем опцию «ZFS», после чего мы увидим следующие параметры:
ID: Название стораджа. Я дал ему название local-zfs
ZFS Pool: Мы создали rpool/data, его и добавляем сюда.
Nodes: указываем все доступные ноды
Данная команда создает новый пул с выбранными нами дисками. На каждом гипервизоре должен появится новый storage под названием local-zfs, после чего вы сможете смигрировать свои виртуальные машины с локального storage на ZFS.
Удаление виртуальной машины из веб-интерфейса Proxmox
Один из самых простых способов удалить виртуальную машину — это сделать это из веб-интерфейса.
Сначала мы входим в веб-интерфейс Proxmox.
Затем мы нажимаем на виртуальную машину в левой панели и выключаем нашу виртуалку.
Затем мы нажимаем на вкладку Дополнительно. В раскрывающемся списке мы выбираем пункт Удалить.
Таким образом, мы удаляем виртуальную машину.
Установка Nginx и Let’s Encrypt сертификата
Мне не очень нравится ситуация с сертификатом и IP адресом, поэтому я предлагаю установить Nginx и настроить Let’s Encrypt сертификат. Установку Nginx описывать не буду, оставлю лишь важные файлы для работы Let’s encrypt сертификата:
Команда для выпуска SSL сертификата:
Не забываем после установки SSL сертификата поставить его на автообновление через cron:
Заметка: чтобы отключить информационное окно о подписке, выполните данную команду:
Сетевые настройки
Перед подключением в кластер настроим сетевые интерфейсы на гипервизоре. Стоит отметить, что настройка остальных нод ничем не отличается, кроме IP адресов и названия серверов, поэтому дублировать их настройку я не буду.
Создадим сетевой мост для внутренней сети, чтобы наши виртуальные машины (в моем варианте будет LXC контейнер для удобства) во-первых, были подключены к внутренней сети гипервизора и могли взаимодействовать друг с другом. Во-вторых, чуть позже мы добавим мост для внешней сети, чтобы виртуальные машины имели свой внешний IP адрес. Соответственно, контейнеры будут на данный момент за NAT’ом у нас.
Работать с сетевой конфигурацией Proxmox можно двумя способами: через веб-интерфейс или через конфигурационный файл /etc/network/interfaces. В первом варианте вам потребуется перезагрузка сервера (или можно просто переименовать файл interfaces.new в interfaces и сделать перезапуск networking сервиса через systemd). Если вы только начинаете настройку и еще нет виртуальных машин или LXC контейнеров, то желательно перезапускать гипервизор после изменений.
Теперь создадим сетевой мост под названием vmbr1 во вкладке network в веб-панели Proxmox.
Изображение 2. Сетевые интерфейсы ноды proxmox1
Изображение 3. Создание сетевого моста
Изображение 4. Настройка сетевой конфигурации vmbr1
Настройка предельно простая — vmbr1 нам нужен для того, чтобы инстансы получали доступ в Интернет.
Теперь перезапускаем наш гипервизор и проверяем, создался ли интерфейс:
Изображение 5. Сетевой интерфейс vmbr1 в выводе команды ip a
Заметьте: у меня уже есть интерфейс ens19 — это интерфейс с внутренней сетью, на основе ее будет создан кластер.
Повторите данные этапы на остальных двух гипервизорах, после чего приступите к следующему шагу — подготовке кластера.
Также важный этап сейчас заключается во включении форвардинга пакетов — без нее инстансы не будут получать доступ к внешней сети. Открываем файл sysctl.conf и изменяем значение параметра net.ipv4.ip_forward на 1, после чего вводим следующую команду:
В выводе вы должны увидеть директиву net.ipv4.ip_forward (если не меняли ее до этого)
Настройка Proxmox кластера
Теперь перейдем непосредственно к кластеру. Каждая нода должна резолвить себя и другие ноды по внутренней сети, для этого требуется изменить значения в hosts записях следующих образом (на каждой ноде должна быть запись о других):
Также требуется добавить публичные ключи каждой ноды к остальным — это требуется для создания кластера.
Создадим кластер через веб-панель:
Изображение 6. Создание кластера через веб-интерфейс
После создания кластера нам необходимо получить информацию о нем. Переходим в ту же вкладку кластера и нажимаем кнопку “Join Information”:
Изображение 7. Информация о созданном кластере
Данная информация пригодится нам во время присоединения второй и третьей ноды в кластер. Подключаемся к второй ноде и во вкладке Cluster нажимаем кнопку “Join Cluster”:
Изображение 8. Подключение к кластеру ноды
Разберем подробнее параметры для подключения:
- Peer Address: IP адрес первого сервера (к тому, к которому мы подключаемся)
- Password: пароль первого сервера
- Fingerprint: данное значение мы получаем из информации о кластере
Вторая нода успешно подключена! Однако, такое бывает не всегда. Если вы неправильно выполните шаги или возникнут сетевые проблемы, то присоединение в кластер будет провалено, а сам кластер будет “развален”. Лучшее решение — это отсоединить ноду от кластера, удалить на ней всю информацию о самом кластере, после чего сделать перезапуск сервера и проверить предыдущие шаги. Как же безопасно отключить ноду из кластера? Для начала удалим ее из кластера на первом сервере:
После чего нода будет отсоединена от кластера. Теперь переходим на сломанную ноду и отключаем на ней следующие сервисы:
Proxmox кластер хранит информацию о себе в sqlite базе, ее также необходимо очистить:
Данные о коросинке успешно удалены. Удалим оставшиеся файлы, для этого необходимо запустить кластерную файловую систему в standalone режиме:
Перезапускаем сервер (это необязательно, но перестрахуемся: все сервисы по итогу должны быть запущены и работать корректно. Чтобы ничего не упустить делаем перезапуск). После включения мы получим пустую ноду без какой-либо информации о предыдущем кластере и можем начать подключение вновь.
Не удается удалить из-за отсутствия хранилища
Другой случай с ошибкой: «не удается удалить из-за отсутствия хранилища» при попытке удалить виртуальную машину. Давайте обсудим, как устранит эту ошибку.
Файл конфигурации виртуальной машины находится в директории /etc/pve/qemu-server.
Мы находим нужный нам файл, например 100.conf и удаляем его.
Таким образом, при обновлении веб-интерфейса виртуальная машина присутствовать не будет.
Также может помочь и удаление конфига виртуальной машины из директории /etc/pve/nodes/pve/lxc или /etc/pve/lxc — симлинка на предыдущую директорию.
Читайте также: