Кластер Proxmox и интеграция Terraform

Привет! Это Александр, DevOps инженер из Банки.ру. В прошлой статье ^[1] я рассказал про сборку сетевого хранилища на базе XPenology. Сегодня продолжу тему Proxmox и XPenology и поделюсь историей о неудачном апгрейде мини-ПК Lenovo из первой статьи ^[2] и чем она закончилась.

Содержание для удобной навигации по статье:

• Как родилась идея апдейта CPU с «инженерником», и что пошло не так ^[3]

• План меняется: делаю самосбор на базе «инженерника» ^[4]

• Создание кластера Proxmox ^[5]

• Использование Terraform в Proxmox ^[6]

• Заключение, планы, рекомендации ^[7]

Как родилась идея апдейта 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» ^[8].

Я давно слышал про 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 чипсетом. Поэтому у меня созрел новый план — самосбор на десктопном железе в компактном корпусе. Не стану углубляться в рассказ о поисках, сразу приведу список комплектующих, из которых в итоге был собран компактный сервер:

1. Инженерный процессор i9 10900t

2. Материнская плата Asrock b460m pro (б/у, сейчас трудно купить хороший новый b чипсет с 4 гнёздами под оперативную память)

3. Оперативная память Netac DDR4 - 4 модуля по  16 ГБ (суммарный объем в 64 гигабайта)

4. Охлаждение на процессор - ID-Cooling IS-50

5. m2 SSD из прошлой статьи ^[1] - Samsung 980 на 500 гигабайт

6. Корпус - Zircon Scan 450W, формфактора Slim и с уже предустановленным блоком питания на 450 ватт

7. Две 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 я со временем избавился. Но собрал себе ещё один сервер из следующих комплектующих:

1. Инженерный процессор i9 11900t

2. Материнская плата MSI MAG B560M Bazooka (опять б/у)

3. Оперативная память Netac DDR4: 2 модуля по 16 гигабайт (возможно, куплю потом ещё пару)

4. Охлаждение процессора - ID-Cooling IS-30i (что в первый, так и во второй сервер нужны были низкопрофильные кулеры, которые, впрочем, справляются с 35 ваттными процессорами)

5. SSD Transcend на 512 гигабайт (тоже уже был у меня в наличии, извлечён из NAS из прошлой статьи ^[1])

6. Корпус - Zircon Scan 450W

7. pci-e сетевая карта на 1 Gb/s

8. 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 ^[9].

Настройки в 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 ^[10] (нужен VPN). Далее я приведу примеры конфигов, которые настроены у меня. Документация для глубокого изучения находится вот тут ^[11] (тоже нужен 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"
}

Небольшое отступление.

По факту базовый конфиг взят отсюда ^[12]. Здесь находится описание того, как создать 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 на ваш ПК, откуда будет управляться кластер. Документация для установки под различные ОС находится вот тут ^[13].

После установки и написания файлов вводим следующие команды:

1. terraform init – установка и инициализация провайдера

2. terrafrom plan – планирование инфраструктуры (в терминале покажет, какие ресурсы будут созданы)

3. terrafrom apply – создание ВМ (вылезет запрос, нужно написать yes)

Terraform считает ваши файлы, клонирует template, введёт прописанные параметры и запустит ВМ. А к ней уже можно подключаться через ssh, используя ранее указанный в файлах ключ.

Заключение, планы, рекомендации

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

Для подготовки этой статьи были использованы следующие ресурсы:

• видео про инженерные CPU с YouTube-канала «Мой Компьютер» ^[14]

• Статьи с Хабра по использованию Proxmox вместе с Terraform: «Модуль Terraform для Proxmox LXC» ^[15] и «Модуль Terraform для Proxmox VM» ^[16]

• Некоторые видео с YouTuve-каналов «Hardware Heaven» ^[17] и «Jim’s Garage» ^[18]

• Различные доступные в РФ маркетплейсы для покупок комплектующих

Хотелось бы в качестве канала “на посмотреть” порекомендовать YouTube-канал Артура Крюкова ^[19]. Коллега с большим опытом, много лет выпускает очень хороший цикл про Kubernetes и всё что с ним связано.