Цей матеріал — операційний runbook для підготовки сервера під валідатор Solana. Ви отримаєте покрокову послідовність: від вибору дистрибутива до фінальної перевірки готовності системи. Кожен крок містить команди, очікуваний результат, ризики та шлях відкату.
Операційні вимоги для «Як підготувати Linux для валідатора Solana» перевірено 2 серпня 2026 року. Для production використовуйте тільки реліз Agave, рекомендований для конкретного кластера, і звіряйте параметри з agave-validator --help . Офіційні вимоги Anza на цю дату орієнтують операторів на Ubuntu 24.04, щонайменше 12 ядер/24 потоки, 256 ГБ RAM, окремі швидкі NVMe та симетричний канал від 2 Гбіт/с; це рекомендації, а не гарантія достатньої продуктивності.
Середовище перевірки: клієнт — Agave (reference-клієнт Solana); кластер — mainnet-beta; ОС — Ubuntu 24.04 LTS, Debian 12, Rocky Linux 9; дата останньої перевірки команд — верифікуйте актуальність пакетів і параметрів ядра безпосередньо перед застосуванням на вашому сервері.
Передумови: фізичний або виділений сервер із архітектурою x86_64, root-доступ через SSH, підключення до інтернету без обмежень на вихідний трафік.
Вибір дистрибутива: Ubuntu, Debian, Rocky
Solana-екосистема та інструменти розробки найширше документовані для сімейства Debian. Проте робочі середовища часто вимагають інших дистрибутивів. Ось фактична різниця для операційного контексту:
- Ubuntu 24.04 LTS. Найбільша кількість готових інструкцій, активна спільнота операторів. Пакети `systemd-resolved` та `cloud-init` іноді конфліктують із кастомним DNS — вимагає уваги при налаштуванні мережі. Підходить як стандартний вибір, якщо у вас немає жорстких обмежень.
- Debian 12. Мінімальне споживання ресурсів, відсутність сторонніх сервісів за замовчуванням. Ідеальний варіант, коли ви хочете повний контроль над кожним процесом і не потребуєте автоматичного визначення облак-інфраструктури. Пакетна база ідентична Ubuntu, команди збігаються.
- Rocky Linux 9. RHEL-сумісний дистрибутив. Вибирайте, якщо ваша інфраструктура стандартизована під Red Hat, ви використовуєте Ansible-плейбуки з RHEL-специфічними модулями або маєте корпоративні політики безпеки, орієнтовані на цю гілку. Пакетний менеджер — `dnf`, шляхи конфігураційних файлів відрізняються.
Критерій вибору: якщо ваша команда не має явної прив'язки до RHEL-екосистеми — беріть Ubuntu 24.04 LTS або Debian 12. Це зменшить час на діагностику нетипових поведінок.
Оновлення системи та встановлення залежностей
Спочатку оновіть всі пакети до актуальних станів. Це усуває відомі вразливості та гарантує, що залежності збірки будуть коректними.
Для Ubuntu та Debian:
- Оновіть індекси пакетів та саму систему:
apt update && apt upgrade -y - Встановіть необхідні для компіляції та роботи інструменти:
apt install -y build-essential pkg-config libssl-dev libudev-dev \ curl jq git ufw logrotate htop iotop
Для Rocky Linux 9:
- Оновіть систему:
dnf update -y - Увімкніть репозиторій EPEL та встановіть залежності:
dnf install -y epel-release dnf install -y gcc gcc-c++ make pkgconfig openssl-devel systemd-devel \ curl jq git ufw logrotate htop iotop
Очікуваний результат: команди завершуються без помилок, `gcc --version` показує встановлений компілятор.
Ризик: оновлення ядра вимагає перезавантаження. На активному валідаторі це означає пропущені слоти. Плануйте оновлення на етапі підготовки, до запуску ноди.
Відкат: якщо оновлення зламало сумісність, на Debian/Ubuntu відкотити можна через `apt install package=version`. На Rocky — через `dnf downgrade package`. Заздалегідь зафіксуйте поточні версії: `dpkg -l > packages_before.txt` або `dnf list installed > packages_before.txt`.
Налаштування параметрів ядра
Solana-клієнт інтенсивно використовує memory-mapped файли для роботи з ledger та accounts. Типові значення ядра Linux для цих параметрів недостатні.
vm.max_map_count, fs.file-max
Параметр `vm.max_map_count` обмежує кількість memory-mapped областей на процес. За замовчуванням у більшості дистрибутивів — 65530, валідатору потрібно значно більше. `fs.file-max` — загальнесистемна межа відкритих файлових дескрипторів.
- Перевірте поточні значення:
sysctl vm.max_map_count sysctl fs.file-max - Встановіть робочі значення:
sysctl -w vm.max_map_count=1000000 sysctl -w fs.file-max=1000000 - Зробіть зміни постійними, додавши у файл `/etc/sysctl.d/99-solana.conf`:
vm.max_map_count = 1000000 fs.file-max = 1000000 - Застосуйте:
sysctl -p /etc/sysctl.d/99-solana.conf
Перевірка: `sysctl vm.max_map_count` має повернути `1000000`.
Ризик: збільшення `vm.max_map_count` не впливає на інші сервіси негативно, але змінює поведінку алокації пам'яті на рівні ядра.
Відкат: видаліть файл `/etc/sysctl.d/99-solana.conf` та виконайте `sysctl --system`. Значення повернуться до дефолтних після перезавантаження.
Transparent HugePages
Transparent HugePages (THP) динамічно виділяє великі сторінки пам'яті. Для баз даних та блокчейн-нод це джерело непередбачуваних затримок, оскільки ядро може призупинити процес для дефрагментації пам'яті.
- Перевірте поточний стан:
Якщо ви бачите `[always]` — THP активний і його треба вимкнути.cat /sys/kernel/mm/transparent_hugepage/enabled cat /sys/kernel/mm/transparent_hugepage/defrag - Вимкніть негайно:
echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag - Зробіть постійним через `systemd-tmpfiles`. Створіть файл `/etc/tmpfiles.d/disable-thp.conf`:
# Path Mode UID GID Age Argument w /sys/kernel/mm/transparent_hugepage/enabled - - - - never w /sys/kernel/mm/transparent_hugepage/defrag - - - - never
Перевірка: після перезавантаження обидві команди з кроку 1 мають показувати `[never]`.
Ризик: вимкнення THP може уповільнити роботу сервісів, які явно на нього розраховують (деякі СУБД з відповідною конфігурацією). На сервері, виділеному під валідатор, цей ризик відсутній.
Відкат: видаліть `/etc/tmpfiles.d/disable-thp.conf` та перезавантажте сервер. Або негайно: `echo always > /sys/kernel/mm/transparent_hugepage/enabled`.
Сетеві буфери
Solana використовує Turbine — протокол пакетного розповсюдження, що генерує значний обсяг UDP-трафіку. Типові розміри буферів ядра призводять до втрат пакетів (drops) під час сплесків.
- Перевірте поточні значення:
sysctl net.core.rmem_max sysctl net.core.wmem_max sysctl net.core.rmem_default sysctl net.core.wmem_default - Встановіть збільшені буфери:
sysctl -w net.core.rmem_max=134217728 sysctl -w net.core.wmem_max=134217728 sysctl -w net.core.rmem_default=16777216 sysctl -w net.core.wmem_default=16777216 - Додайте у `/etc/sysctl.d/99-solana.conf` (разом із попередніми параметрами):
net.core.rmem_max = 134217728 net.core.wmem_max = 134217728 net.core.rmem_default = 16777216 net.core.wmem_default = 16777216 - Застосуйте:
sysctl -p /etc/sysctl.d/99-solana.conf
Перевірка: `sysctl net.core.rmem_max` має повернути `134217728`.
Ризик: збільшені буфери споживають додаткову пам'ять, але на сервері з 128 ГБ+ RAM це непомітно.
Відкат: аналогічно — видалення рядків із конфігураційного файлу та `sysctl --system`.
Створення користувача для валідатора
Запуск валідатора від імені root — неприпустимий ризик. Компрометація процесу означає повний контроль над сервером.
- Створіть користувача без права входу через пароль:
useradd -m -s /bin/bash solana - Налаштуйте авторизацію за SSH-ключами. З вашої робочої машини скопіюйте публічний ключ:
ssh-copy-id -i ~/.ssh/your_key.pub solana@<SERVER_IP> - Забороніть парольний вхід для цього користувача. Відредагуйте `/etc/ssh/sshd_config` або створіть файл `/etc/ssh/sshd_config.d/99-solana-hardening.conf`:
Match User solana PasswordAuthentication no PubkeyAuthentication yes - Перезавантажте SSH:
systemctl reload sshd - Надайте selective sudo-доступ. Створіть файл `/etc/sudoers.d/solana`:
Це дозволяє перезапускати сервіс та читати журнали без повного shell-доступу до root.solana ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart solana, /usr/bin/systemctl stop solana, /usr/bin/systemctl start solana, /usr/bin/journalctl -u solana *
Очікуваний результат: `ssh solana@<SERVER_IP>` заходить без пароля за ключем; `sudo systemctl restart solana` працює; `sudo apt update` — запитує пароль (відмовлено).
Ризик: неправильне налаштування Match-блоку в sshd_config може заблокувати всіх користувачів. Зберігайте окрему root-сесію відкритою до підтвердження, що SSH-доступ працює.
Відкат: видаліть `/etc/ssh/sshd_config.d/99-solana-hardening.conf`, виконайте `systemctl reload sshd`, видаліть користувача `userdel -r solana`.
Налаштування дискових розділів та монтування
Увага: операції з розділами руйнівні та незворотні. Переконайтеся, що обрали правильний диск. Всі дані на ньому будуть знищені. Якщо на диску є щось важливе — зробіть резервну копію перед продовженням.
Solana-валідатор генерує інтенсивний послідовний запис (ledger) та випадковий читання/запис (accounts). Єдиний правильний вибір — NVMe SSD. HDD та SATA SSD не забезпечують необхідного IOPS.
Рекомендована структура монтування:
| Точка монтування | Призначення | Мінімальний об'єм | Файлова система |
|---|---|---|---|
/mnt/ledger |
Ledger, snapshots, accounts | Верифікуйте актуальні вимоги для вашого кластера на момент розгортання | XFS |
Розділення ledger та accounts на різні фізичні диски історично рекомендувалося, але сучасні NVMe з високим довільним IOPS дозволяють використовувати єдиний розділ без деградації.
- Визначте диск (приклад — `/dev/nvme0n1`):
Переконайтеся, що це саме той диск, який вам потрібен.lsblk fdisk -l /dev/nvme0n1 - Створіть розділ:
parted /dev/nvme0n1 mklabel gpt parted /dev/nvme0n1 mkpart primary 0% 100% - Форматуйте в XFS:
mkfs.xfs /dev/nvme0n1p1 - Створіть точку монтування та налаштуйте fstab:
Отримайте UUID:mkdir -p /mnt/ledger
Додайте рядок у `/etc/fstab` (замініть `YOUR_UUID`):blkid /dev/nvme0n1p1YOUR_UUID /mnt/ledger xfs noatime,nodiratime,discard 0 0 - Змонтуйте та перевірте:
mount -a df -h /mnt/ledger - Передайте права користувачу валідатора:
chown solana:solana /mnt/ledger
Очікуваний результат: `df -h /mnt/ledger` показує XFS-розділ з коректним об'ємом; після перезавантаження розділ змонтовується автоматично.
Чому XFS: Solana-документація рекомендує XFS для ledger через ефективну роботу з великими файлами та послідовним записом. ext4 працює, але XFS показує стабільніший результат при високому навантаженні на запис.
Опції монтування: `noatime` та `nodiratime` вимикають запис часу останнього доступу, що зменшує навантаження на I/O. `discard` увімкнює TRIM для NVMe (альтернативно — налаштуйте cron з `fstrim`).
Ризик: помилка в UUID у fstab призведе до неможливості завантаження системи. Виправляється через rescue-режим або Live USB.
Відкат: видаліть рядок із `/etc/fstab`, виконайте `umount /mnt/ledger`. Дані на диску залишаться, але розділ можна переформатувати за потреби.
Перевірка готовності системи
Перед переходом до встановлення Solana-клієнта та створення ключів виконайте фінальну перевірку. Це дозволить локалізувати проблеми на етапі, коли виправлення найпростіші.
Чек-лист параметрів ядра:
sysctl vm.max_map_count fs.file-max net.core.rmem_max net.core.wmem_max
cat /sys/kernel/mm/transparent_hugepage/enabled
cat /sys/kernel/mm/transparent_hugepage/defragОчікувані значення: `vm.max_map_count = 1000000`, `fs.file-max = 1000000`, `rmem_max` та `wmem_max = 134217728`, THP — `[never]`.
Чек-лист дискової підсистеми:
df -h /mnt/ledger
mount | grep /mnt/ledger
ls -ld /mnt/ledgerОчікуваний результат: XFS, опції `noatime,nodiratime,discard`, власник — `solana:solana`.
Чек-лист користувача та безпеки:
id solana
su - solana -c "sudo systemctl restart solana" 2>&1
su - solana -c "sudo apt update" 2>&1Очікуваний результат: перша команда виконується без помилки, друга — повертає помилку відмови в доступі (це правильно).
Дискова продуктивність (базовий тест):
solana@server:~$ dd if=/dev/zero of=/mnt/ledger/test_write bs=1M count=1024 oflag=direct
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.23 s, 873 MB/sКонкретна швидкість залежить від вашого NVMe-накопичувача. Якщо результат нижчий за 500 МБ/с для послідовного запису — перевірте стан диска та PCIe-лінії.
Прибрати тестовий файл:
rm /mnt/ledger/test_writeМережева доступність:
curl -sI https://api.mainnet-beta.solana.com | head -n 1Очікуваний результат: `HTTP/2 200` або `HTTP/1.1 200 OK`. Якщо відповіді немає — перевірте фаєрвол та DNS.
Якщо всі пункти чек-листу пройдені — система готова до встановлення Solana-клієнта та створення identity та vote account, що розглядається в наступному розділі.