Привет! Это Александр, DevOps инженер из Банки.ру. В прошлой статье я рассказал про сборку сетевого хранилища на базе XPenology. Сегодня продолжу тему Proxmox и XPenology и поделюсь историей о неудачном апгрейде мини-ПК Lenovo из первой статьи и чем она закончилась.
Содержание для удобной навигации по статье:
Как родилась идея апдейта CPU с «инженерником», и что пошло не так
После написания статьи про NAS я решил, что хорошо бы сделать апгрейд CPU у Lenovo (у меня модель m70q-gen2, с i3 10105t). Для этого мне нужны были не обычные процессоры 10 и 11 линейки Intel, а с индексом T. Если коротко — это ужатые в теплопакет 35 ватт процессоры со встроенным видеоядром, специально разработанные для таких мини-пк. Долгий поиск по доступным маркетплейсам выдал не утешительные результаты: либо что-то около i5 10400t/11400t за 20 тысяч рублей (ещё и б/у!), которые не обеспечат значительный прирост в числе так нужных мне ядер/потоков, либо отличный i9 10900t (10 ядер/20 потоков) с Озона, но за 35! КАРЛ!!! тысяч рублей. Расстроившись, я почти забросил идею апгрейда CPU, пока не наткнулся на вот эту страничку: «Список всех инженерных (ES) процессоров для сокета 1200».
Я давно слышал про CPU-«мутанты» и инженерные версии процессоров, но далеко не сразу обратил внимание на инженерники для 1200-го сокета. Снова начал поиск, но теперь искал информацию по этим процессорам. Как оказалось, инженерные CPU для 1200-го сокета — это предрелизные варианты обычных магазинных процессоров линейки Intel Core 10 и 11 поколения с минимальными различиями. Мое главное требование было в наличии на материнской плате минимум b460 или b560 чипсета (по ссылке выше описаны полные требования), что, впрочем, не мешало моему апгрейду — у Lenovo был b560 чипсет на борту.
Итак, моя цель была — купить инженерный i9 10900t (его индекс QTB0, так как инженерники маркируются иначе, чем релизные варианты). Поиск по его индексу привел меня на Али, где я его нашёл за вполне адекватные 8,5 тысяч рублей. Мой план был ясен: мне просто нужно было купить инженерный i9, дождаться доставки и установить его в Lenovo вместо i3!
Спойлер: план был обречен. Сразу после получения, я попробовал установить процессор, но не получил запуска системы. Процессор подошёл к сокету, нагревался при старте, а затем в течение пары секунд после старта система останавливалась, не выдавая изображение. Решив, что дело в процессоре, я попросил у товарища (Миха, привет и спасибо за помощь!) протестировать инженерный CPU в его ПК. И он запустился на его материнской плате с и 560-м чипсетом. Получается, что вернуть его обратно в Китай я не могу — товар рабочий, просто не в моей конфигурации. Как выяснилось, в Lenovo зашит проприетарный bios, в котором не добавлены микрокоды инженерных CPU, а прошить микрокоды в bios у меня так и не получилось, как не получилось это и в ремонтной мастерской.
План меняется: делаю самосбор на базе «инженерника»
Окончательно расстроившись, я вдруг вспомнил, что раз инженерник всё равно рабочий и запустился на обычной mATX материнке с b560 чипсетом. Поэтому у меня созрел новый план — самосбор на десктопном железе в компактном корпусе. Не стану углубляться в рассказ о поисках, сразу приведу список комплектующих, из которых в итоге был собран компактный сервер:
-
Инженерный процессор i9 10900t
-
Материнская плата Asrock b460m pro (б/у, сейчас трудно купить хороший новый b чипсет с 4 гнёздами под оперативную память)
-
Оперативная память Netac DDR4 - 4 модуля по 16 ГБ (суммарный объем в 64 гигабайта)
-
Охлаждение на процессор - ID-Cooling IS-50
-
m2 SSD из прошлой статьи - Samsung 980 на 500 гигабайт
-
Корпус - Zircon Scan 450W, формфактора Slim и с уже предустановленным блоком питания на 450 ватт
-
Две pci-e сетевые карты на 2,5Gb/s
В итоге у меня получился вот такой компактный ПК (даже с буквой S на передней панели 
) примерно за 40 тысяч рублей на момент сборки.
Дальше дело техники: установить Proxmox и получить в итоге сервер с 10 ядрами, 20 потоками и 64 гигабайтами памяти.
Но меня все же не покидала идея сделать апгрейд Lenovo и получить вторую ноду Proxmox. Прочитав официальную документацию к Lenovo, я обнаружил, что на модели m70q-gen2 не было поддержки i9 10900t. Зато была поддержка i9 11900t. И знаете, что? Я купил инженерный i9 11900t (его индекс QV1L) за 7,5 тысяч рублей. В общем, жизнь меня ничему не учит, итог был тот же, что и с QTB0, я получил посылку с QV1L, и он также не запустился на Lenovo.
В этот момент мое терпение иссякло, от Lenovo я со временем избавился. Но собрал себе ещё один сервер из следующих комплектующих:
-
Инженерный процессор i9 11900t
-
Материнская плата MSI MAG B560M Bazooka (опять б/у)
-
Оперативная память Netac DDR4: 2 модуля по 16 гигабайт (возможно, куплю потом ещё пару)
-
Охлаждение процессора - ID-Cooling IS-30i (что в первый, так и во второй сервер нужны были низкопрофильные кулеры, которые, впрочем, справляются с 35 ваттными процессорами)
-
SSD Transcend на 512 гигабайт (тоже уже был у меня в наличии, извлечён из NAS из прошлой статьи)
-
Корпус - Zircon Scan 450W
-
pci-e сетевая карта на 1 Gb/s
-
USB сетевая карта от Ugreen на 2.5 Gb/s
По внешнему виду получилось так же, как и предыдущий сервер, но с некоторыми отличиями. На матплате от Asrock был только гигабитный сетевой порт, и к ней я докупил сетевые карты на 2,5 гигабита, а на матплате от MSI уже был порт на 2,5 гигабита, так что я поставил дополнительно давно лежащую без дела сетевую карту на гигабит и позже добавил USB сетевую карту.
Также я заменил диски в NAS XPenology: докупил 2 nvme SSD на 256 ГБ от Netac для SSD кеша и откопал HDD WD Gold на 4 Терабайта. SSD кеш был назначен на пул с WD Gold, в итоге ускоряя HDD на чтение и запись.
В целом, на данном этапе я решил, что покупку железа можно закончить, распродать ненужное и в дальнейшем все эксперименты и настройки будут проходить на ранее описанном железе. Теперь переходим к софтовой части.
Создание кластера Proxmox
Сделаю небольшое отступление, которое я пишу уже после всех проб и ошибок. В целом, делать кластер из 2-х нод имеет смысл только для централизованного управления нодами, ВМ и бекапами на NFS (в том числе и через Terraform, но об этом будет позже). Потому что для хорошей работы HA (high availability — высокая доступность) необходимо от 3-х и более нод для кворума. Ещё моя идея состояла в том, чтобы связать NAS и 2 ноды в одну сеть 2,5 гигабита. В своем решении я сделал виртуальный маршрутизатор, но моя личная рекомендация — покупать отдельный маршрутизатор на 2,5 (или выше) гигабита и уже спокойно подключать туда всё железо. Если у вас уже есть в наличии маршрутизатор, то момент создания виртуалки OpenWRT можно пропустить.
Так как у меня не было маршрутизатора на 2,5 гигабита, я решил создать виртуальный. На моих серверах уже есть порты 2.5 гигабита, осталось их правильно задействовать.
Получилось примерно следующее:
-
из домашнего роутера в server1 приходит патчкорд с сетью
-
на сервере1 развёрнута виртуальная машина с OpenWRT. Выбрал её потому, что использую эту роутерную ОС на домашнем AX3000T — уже есть опыт работы
-
в роутерную виртуалку подключены мосты, которые физически используют порты по 2,5 гигабита
Виртуалку я поднимал с помощью скрипта с сайта Proxmox VE Helper-Scripts.
Настройки в OpenWRT минимальные: нужно объединить все интерфейсы в один bridge device и на его основе создать lan интерфейс.
В итоге мы получаем виртуальный роутер, который пропускает трафик через себя на физические порты.
Не обязательно использовать OpenWRT, можно задействовать PfSense и подобные виртуальные роутеры. Такое у меня получалось даже на крошечной ВМ с Alpine Linux, но для наглядности и возможности управления через веб-интерфейс я взял OpenWRT.
В дальнейшем я подключил в порты server1 2,5 гигабит NAS и server2. Используя iperf3, получил примерно 2,4 гигабита скорости , что в целом меня устраивает. Да, признаю, в данный момент схема не отказоустойчивая, так как при падении server1 потеряется доступность к NAS и server2, поэтому в дальнейшем я, возможно, заменю виртуальный роутер на физический. Но в таком режиме к моменту выхода статьи у меня uptime близится к трём месяцам и пока проблем с виртуальным роутером не было.
Итак, сеть настроили. Перейдем к кластеризации. На первой ноде (server1) переходим в Datacenter - Cluster и нажимаем Create Cluster. Придумываем название кластера и нажимаем Create.
После получения об успешной инициализации кластера нам становится доступна кнопка Join Information. Копируем зашифрованный в Base64 json с информаций подключения.
Теперь логинимся на вторую ноду (server2) и также переходим в Datacenter - Cluster. Тут нам нужна кнопка Join Cluster. Нажимаем на неё и вводим скопированный Base64 и пароль к первой ноде. Нажимаем Join.
В момент подключения может показаться, что всё зависло, но после перезагрузки страницы мы видим следующее сообщение:
Таким образом можно подключить дополнительные ноды, при этом ограничений на число нод нет. В итоге получаем централизованное управление нодами, бекапами, дисками и сетью.
Теперь попробуем добавить NFS папку с NAS. Идём в Datacenter - Storage - Add - Add NFS и заполняем следующим образом:
После подключения NFS папки настроим бекапы наших ВМ на NAS. Переходим в Datacenter - Backup и создаём новую задачу:
В General я исключил часть ВМ для бекапирования, так как одна ВМ — это виртуальный роутер, и там не планируется изменения, а вторая ВМ — это темплейт, из которого я создаю новые ВМ копированием или при использовании Terraform. Во вкладке Retention я указал хранить последние 5 бекапов. То есть при частоте копирования раз в сутки у нас будет сохраняться 5 суточных бекапов для отката/восстановления ВМ.
Использование Terraform в Proxmox
Terraform — это инструмент IaC (инфраструктуры как код), который позволяет описывать инфраструктуру в .tf файлах. А сами файлы можно хранить в git репозитории, что дополнительно добавляет гибкости. Terraform использует Hashicorp Language (HCL). Это yaml/jsonーподобный язык, который в основном используется в продуктах компании Hashicorp. В дальнейшем, возможно, понадобится VPN для просмотра документации и получение провайдера.
После того как я настроил Proxmox для работы с Terraform, я перестал в целом создавать ВМ в интерфейсе Proxmox, так как всё, что мне нужно, было уже описано в .tf файлах, и для создания новой ВМ я просто копировал блоки кода, изменяя нужные параметры.
Итак, для запуска проекта terraform нам нужен провайдер. Рабочий провайдер для Proxmox — это proxmox provider от разработчика Telmate (нужен VPN). Далее я приведу примеры конфигов, которые настроены у меня. Документация для глубокого изучения находится вот тут (тоже нужен VPN).
Файл «provider.tf» инициализации провайдера и настройка подключения к кластеру:
#секция установки провайдера
terraform {
required_providers {
proxmox = {
source = "Telmate/proxmox"
version = "3.0.1-rc6"
}
}
}
#секция подключения к кластеру/ноде
provider "proxmox" {
pm_tls_insecure = true
pm_api_url = "https://192.168.0.100:8006/api2/json"
pm_password = var.password
pm_user = "root@pam"
}Файл «variable.tf» с переменными (его можно дополнять в дальнейшем):
#тут вписываем свой ssh ключ
variable "ssh_key" {
description = "My SSH public key"
type = string
default = "ssh-rsa …"
}
variable "password" {
description = "my PVE password"
type = string
default = "enter_your_proxmox_password"
}Небольшое отступление.
По факту базовый конфиг взят отсюда. Здесь находится описание того, как создать cloud-init template в proxmox для дальнейшего его использования в Terraform. В рамках моего кластера файл «main.tf» выглядит вот так:
#определяем id, имя ВМ, целевой сервер и ресурсы ВМ.
resource "proxmox_vm_qemu" "gitlab" {
vmid = 180
name = "gitlab"
target_node = "server1"
agent = 1
cores = 2
memory = 8192
boot = "order=scsi0"
clone = "Ubuntu-24.04" #выбираем, с какого темплейта клонируем
full_clone = true
scsihw = "virtio-scsi-single"
vm_state = "running"
automatic_reboot = true
cicustom = "vendor=local:snippets/qemu-guest-agent.yml" #этот момент описан по ссылке выше, если вкратце - мы передаём команды, которые будут введены после старта склонированной ВМ
ciupgrade = true
nameserver = ""
ipconfig0 = "ip=192.168.0.180/24,gw=192.168.0.1"
skip_ipv6 = true
ciuser = "alex"
cipassword = "1"
sshkeys = var.ssh_key
#эта секция не используется, нужна для защиты ВМ от случайного удаления при использовании командной строки terraform
# lifecycle {
# prevent_destroy = true
# }
serial {
id = 0
}
disks {
scsi {
scsi0 {
disk {
storage = "local-lvm"
size = "32G"
}
}
}
ide {
ide2 {
cloudinit {
storage = "local-lvm"
}
}
}
}
network {
id = 0
bridge = "vmbr0"
model = "virtio"
}
}В целом на этом всё. Строчки из последнего файла можно копировать неограниченное число раз, изменяя имя и параметры под себя.
И да, чуть не забыл! Для запуска всего этого нам нужно установить Terraform на ваш ПК, откуда будет управляться кластер. Документация для установки под различные ОС находится вот тут.
После установки и написания файлов вводим следующие команды:
-
terraform init – установка и инициализация провайдера
-
terrafrom plan – планирование инфраструктуры (в терминале покажет, какие ресурсы будут созданы)
-
terrafrom apply – создание ВМ (вылезет запрос, нужно написать yes)
Terraform считает ваши файлы, клонирует template, введёт прописанные параметры и запустит ВМ. А к ней уже можно подключаться через ssh, используя ранее указанный в файлах ключ.
Заключение, планы, рекомендации
В заключении для полноты картины я хотел бы написать следующее: я закончил постройку той домашней лаборатории, которая бы меня устроила по соотношению цена/ресурсы. В трех статьях цикла были описаны варианты сборок как серверов, так и универсального сетевого хранилища с настройками. Далее я уже отойду от темы железа и продолжу цикл настройкой и эксплуатацией софта для DevOps.
Для подготовки этой статьи были использованы следующие ресурсы:
-
видео про инженерные CPU с YouTube-канала «Мой Компьютер»
-
Статьи с Хабра по использованию Proxmox вместе с Terraform: «Модуль Terraform для Proxmox LXC» и «Модуль Terraform для Proxmox VM»
-
Некоторые видео с YouTuve-каналов «Hardware Heaven» и «Jim’s Garage»
-
Различные доступные в РФ маркетплейсы для покупок комплектующих
Хотелось бы в качестве канала “на посмотреть” порекомендовать YouTube-канал Артура Крюкова. Коллега с большим опытом, много лет выпускает очень хороший цикл про Kubernetes и всё что с ним связано.
Автор: project_delta
