Налаштування PXE-завантаження для масового провіжинінгу серверів

PXE завантаження: чому масова установка серверів ламається

Масова установка серверів по мережі ламається не на старті, а на масштабі. PXE завантаження — це ланцюжок із відповіді DHCP із вказівником на завантажувач, видачі образу через TFTP і джерела пакетів через HTTP.

Достатньо однієї розбіжності всередині неї — застарілого вказівника, хибного шляху, розбіжного файлу конфігурації — і частина парку замість установки потрапляє в помилку, а інженер ходить стійками з консоллю.

Далі час з'їдає ручне: шаблони автовідповідей правлять прямо на живому розгортанні, і наступна партія заліза отримує відбиток попередньої — чужі розділи, чужу мережну адресу, чужий ключ доступу.

Ревізії плат і прошивок різняться, режим BIOS і UEFI доводиться вибирати вручну, а ручні збірки образів живуть на робочій машині одного інженера. Автоматизація провізіонінгу в такій схемі тримається на пам'яті людей, а не на перевірюваних правилах.

Облік розгорнутого ведуть у таблиці, і вона розходиться з реальністю після першої ж заміни диска або переустановки. Повторна установка займає години: спочатку треба зрозуміти, що стоїть у стійці, яка конфігурація на ньому актуальна і який із шаблонів до неї застосовний.

Розбираємо, як це закривається: єдине джерело шаблонів і образів, прив'язка конфігурації до конкретного заліза через інвентаризацію, автоматичний вибір режиму завантаження й облік кожної установки як окремої події, а не рядка в таблиці.

Що дає єдиний контур мережевої установки

Єдиний контур установки — це коли сервер будь-якої ролі отримує адресу, завантажувач і профіль з одного спільного опису, а не з флешки в руках чергового.

Інженер додає запис до опису, машина при ввімкненні сама звертається до області адресації, забирає образ по мережі й застосовує свій профіль. Час введення сервера падає з кількох годин ручної роботи до 10–15 хвилин на машину, причому без людини біля консолі.

Шаблони образів дають основний ефект: базова система й ролі описані один раз. Правка розмітки диска, мережевих параметрів або складу пакетів робиться в одному файлі — і наступна установка йде вже з нею.

З парку зникає цілий клас помилок: «сніжинки» з ручними відмінностями, через які потім неможливо відтворити збій і повторити робочий сервер.

Звільнений час інженера рахуйте на партію: установка йде паралельно, машини не стоять у черзі до єдиного носія.

На парку в кілька десятків серверів це різниця між однією зміною та розтягнутою на дні роботою, де фахівець зайнятий мережею, залізом і профілями, а не натисканням «Далі» біля кожної стійки.

Повторюваність налаштувань перевіряється тим самим контуром: порівняння еталона з фактичним станом, єдині правила розмітки, облікових записів і служб.

Новий сервер відрізняється від раніше встановленого тільки тим, що закладено в шаблоні, а не тим, хто і в якому порядку його ставив.

Профілі розгортання: порівняння режимів завантаження

Профіль розгортання — це зв'язка з режиму завантаження, образу й шаблону відповідей: розмітка дисків, набір пакетів, параметри ядра, введення вузла в домен.

Чим точніше профіль описує роль вузла, тим менше ручних правок після першого завантаження — але тим більше шаблонів доводиться версіонувати й синхронізувати з образами.

Режим завантаження вибирають окремо від профілю. Класичний мережевий старт достатній для невеликих і ізольованих сегментів; завантаження через HTTP швидше віддає великі образи й не потребує локального сховища; групова установка однією пачкою економить час на стійку.

Сценарії установки різняться обсягом парку й вимогами до швидкості — тому починаємо з одного профілю за замовчуванням, а решту підключаємо в міру зростання парку.

Етапи впровадження: від аудиту мережі до передачі в роботу

Впровадження йде чергами, і порядок етапів фіксований: помилка в адресації або в опціях завантаження ламає не тільки нову установку, а й машини, що вже працюють, у тому самому сегменті. Тому ми починаємо не з налаштування сервера, а з опису мережі й парку.

1. Аудит мережі й парку. Збираємо схему адресації, віртуальні мережі, агенти-ретранслятори запитів, межі широкомовних доменів, моделі серверів і режими завантаження. На виході — карта сегментів, де мережеве завантаження проходить, і список винятків.

2. Проєктування схеми завантаження. Визначаємо, що віддаємо через DHCP — адресу завантажувача й файл образу, куди кладемо самі образи, як розділяємо профілі обладнання і як обмежуємо завантаження за апаратною адресою, щоб тестовий цикл не пішов на робочу стійку.

3. Налаштування сервера завантаження. Піднімаємо меню, розкладаємо образи й файли автоустановки, прив'язуємо розмітку дисків, мережу й базовий набір пакетів до профілю. Перший прогін — на одній машині в ізольованому сегменті.

4. Тестова установка на резервному вузлі. Проходимо повний цикл: увімкнення, отримання адреси, завантаження, розмітка, конфігурування, перший запуск. Вимірюємо час до готового вузла й кількість ручних кроків.

5. Перевірка відмовних сценаріїв. Переривання на середині установки, повторний запуск, відкат на попередній образ, поведінка при недоступному сервері завантаження — усе має приводити вузол у відомий стан, а не в напівналаштований.

6. Передача в роботу. Віддаємо документацію щодо схеми адресації та профілів, налаштовуємо доступи й ролі, показуємо черговій зміні, як додати новий профіль і як вимкнути завантаження для конкретного вузла. Далі будь-які правки меню йдуть через той самий тестовий контур.

Що залишається у вас: конфігурації та регламенти

Комплект передається так, щоб PXE-завантаження у вашій мережі не залежало від одного інженера: конфігурації лежать у репозиторії з історією правок, схеми — в актуальному вигляді, а не «на серветці», регламенти описують штатні операції — додавання нової моделі сервера, виведення вузла з експлуатації, відкат невдалої збірки. Нижче — що саме залишається у вашої команди після здачі.

• Конфігурації завантажувального сервера — правила видачі адрес, опис меню завантаження, прив'язка образів до груп обладнання. З коментарями, навіщо потрібен кожен блок і що зламається, якщо його прибрати.
• Схеми адресації та сегментів — які підмережі обслуговує завантажувальний сервер, де проходить межа мережевих зон, як влаштований маршрут до сховища образів і що має бути доступним до старту провізіонінгу.
• Політики прав доступу — хто з інженерів змінює меню й образи, хто працює тільки з логами, як видаються й відкликаються облікові записи служб автоматики.
• Документація з розгортання — покроковий порядок підняття стенда з нуля: підготовка образів, увімкнення служб, перевірка після запуску.
• Регламент змін — як нова версія образу потрапляє в обіг, хто погоджує, як повернутися на попередню збірку за один крок.
• Порядок діагностики — список перевірок для типових відмов: клієнт не отримав адресу, не знайшов завантажувальний файл, завис на меню. Що дивитися в першу чергу й які журнали знімати.
• Карта залежностей — які служби мають відповідати до початку масового ввімкнення, щоб одночасний старт сотні машин не перетворився на відлагодження наосліп.

Ці артефакти живуть у вашому контурі: правки вносяться за описаним порядком, а не з пам'яті конкретної людини, тому супровід можна передати своїй команді або іншому підряднику без відновлення логіки з нуля.

Кейс: різнорідний парк і один набір шаблонів

До: у кожного покоління заліза свій рецепт

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

Введення вузла займало майже день: інженер вручну вибирав профіль, стежив за розміткою й доставляв відсутні драйвери вже після установки системи.

Після: один шаблон і профілі під залізо

Завантаження описали один раз: вузол представляється за MAC-адресою, отримує адресу й вказівку, звідки тягнути образ, а далі Ansible доводить його до робочого стану за роллю.

Відмінності між поколіннями винесені у змінні — розмітка, набір драйверів і список пакетів задаються профілем, а не копією шаблону. Перед публікацією в спільний репозиторій профіль проганяється на тестовому вузлі.

Метрики після переходу: введення сервера в стрій — 15–20 хвилин замість кількох годин, без постійної присутності інженера. Частка машин, які збираються зі спільного набору шаблонів, дійшла до 90%, решта — рідкісне залізо, для нього залишені окремі профілі. Відмови на першій установці майже зникли: збій профілю ловиться на стенді, а не на серійному вузлі.

Відкат теж став передбачуваним: профіль версіонується разом із шаблоном, і попередня робоча версія повертається однією правкою в репозиторії.

Чим PXE завантаження відрізняється від клонування дисків?

Клонування дисків копіює вже встановлену систему: зняли образ з еталона — розлили на десять машин. PXE завантаження працює інакше: сервер стартує по мережі, отримує зі сховища підготовлений образ і розгортається на чистому залізі без участі оператора. Різниця проявляється не на першій машині, а на сотій.

Клонування ламається там, де парк перестає бути однорідним. Інший контролер дисків, інша мережева карта — і система не піднімається або втрачає пристрій. Плюс копії успадковують ідентифікатори еталона: ключі хоста, імена, мережеві налаштування.

Їх доводиться правити на кожному вузлі вручну, і саме це доведення з'їдає весь виграш від швидкої заливки.

Мережеве завантаження будується навколо підготовки образів як окремого процесу. Еталон збирається автоматично з опису, а не знімається з живої машини, тому в ньому немає накопиченого сміття й слідів минулих налаштувань.

Конфігурація прив'язується до конкретного вузла: роль, розмітка, мережеві параметри — сервер отримує рівно той набір, який йому належить, включно з унікальними ідентифікаторами, що генеруються при першому старті.

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

Клонування залишається розумним для разового перенесення кількох однотипних машин; регулярне введення серверів у стрій мережеве завантаження закриває передбачувано й без ручних доведень.

Технічні сумніви: безпека, відкат, сумісність

Сумніви навколо мережі завантаження предметні: вона працює до операційної системи, і помилка в меню спрямовує не той вузол. Нижче — відповіді на те, що найчастіше уточнюють інженери перед увімкненням схеми в роботу.

Як це не зачіпає робочі сервери?

Провізіонінг вмикається за явним підтвердженням і тільки для вузлів, позначених вільними, — робочі машини в меню не потрапляють. Службовий сегмент виносимо в окремий VLAN, ретрансляція DHCP налаштована на конкретні порти, стенд і прод не плутають профілі.

Що з відкатом, якщо образ виявиться битим?

Кожна конфігурація меню — окремий версіонований профіль, перемикання вказівника повертає попередній за хвилини. Невдалий образ знімається з публікації, а вузол доїжджає за старим профілем до розбору.

Що з різними моделями й прошивками?

UEFI і Legacy BIOS ведемо різними ланцюжками завантаження, на змішаному парку першою ставимо iPXE. Нестандартні мережеві адаптери перевіряємо на пілотній партії і тільки потім розширюємо область на весь парк.

Обговоримо вашу задачу мережевої установки

Щоб оцінка спиралася на факти, а не на «плюс-мінус», достатньо кількох ввідних. Щодо PXE-завантаження вони типові — за ними видно, скільки конфігурацій доведеться описати й де почнуться розбіжності з поточною інфраструктурою.

• Інвентар машин: модель, ролі й MAC-адреси портів — за ними шаблони прив'язуються до конкретного заліза.
• Схема мережі: підмережі, хто роздає адреси, чи потрібен окремий VLAN для службового трафіку роздачі.
• Цільові системи й розмітка дисків: файлові системи, програмні RAID-масиви, шифрування, точки монтування даних.
• Що ставити після першого завантаження: ролі, пакети й налаштування за групами машин.
• Правила імен і адресації: як машина отримує ім'я й адресу, чи є облік виданого.
• Доступи: консоль або віддалене управління, сервер роздачі, право завести записи — вистачить тестового стенда.
• Вікно на пілот: дві-три машини, які можна перезалити без ризику для робочих сервісів.

План впровадження будуємо по наростаючій: пілот на двох-трьох машинах, де обкатуємо шаблони й перевіряємо повторюваність прогону, потім одна стійка цілком, потім парк частинами.

Описи зберігаємо в репозиторії й тримаємо декларативними — через Ansible або аналогічний інструмент, — щоб повторний запуск приводив машину до того самого стану.

З оцінкою проєкту повернемося планом: етапи, склад робіт, що робимо ми й що залишається на стороні замовника, ризики й точки відкату. Опишіть задачу у вільній формі — обговоримо обсяг мережевої установки парку й порядок робіт.