Настройка сервера, установка ноды, администрирование

Какие гайды уже существуют?

На текущий момент я знаю 3 авторов, которые писали гайды по установке ноды в Солане и одного, который выпустил другие гайды для Соланы, а именно:

1. Гайды от Димана (в формате видео)
1. Установка Ноды
2. Настройка RAM-диска
3. Raid-0 в дата-центре Hetzner
4. Установка мониторинга telegraf
2. Гайд по установке ноды от Артема (в формате текста)
3. Гайды от Абеза (в формате видео, плюс полезная информация по Solana)
1. Raid-0 в дата-центре OVH
4. Гайд по установке ноды от команды Let's Node (в формате текста)

Какой гайд использовать для установки ноды?

Можете брать любой из списка выше, или читать мой и пробовать ставить по нему, в своем гайде я постарался учесть все возможные проблемы и ошибки, которые может совершить новичок, на пути становления валидатором. Сам же в мае 2021 года я ставил ноду по гайду Димана, но многие тонкости и нюансы понял позже, когда сам нарыл всю информацию и общался с другими валидаторами.

Итак, поехали.

У нас есть два варианта, как мы будем производить настройку сервера и дальнейшую установку ноды, мы можем это делать или под самым главным пользователем операционной системы Ubuntu - Root, или под любым другим пользователем, который уже создан в системе, например, у дата-центра OVH стандартная настройка сервера подразумевает работу под пользователем ubuntu, или под тем пользователем, которого вы создадите сами.

Подготовка к установке

Для того, чтобы исключить возможные проблемы после установки Соланы, нам необходимо провести тестирование железа и интернет-канала, очень часто бывают проблемы на новых серверах, связанные с коннектором для NVME дисков, в связи с этим скорость их записи и чтения становится недопустимо маленькой. Чтобы потом не мучиться и не писать в чат вопросы: "А почему у меня что-то не работает" мы и проводим все эти процедуры. Но для начала установим Raid 0 и операционную систему Ubuntu 20.04

Raid 0

Raid 0 представляет собой массив из двух или более дисков, запись на которые происходит параллельно, за счет этого скорость записи и считывания увеличивается в 2 и более раз (зависит от количества дисков, если 2 диска - в два раза, 3 - в три). Реальное увеличение скорости можно увидеть для записи/чтения больших файлов, но и при записи/чтении маленьких файлов скорость также увеличивает, но немного меньше.

Для чего это там нужно? Так как Солана достаточно требовательна к скорости вашего диска и команда рекомендует использовать NVME-диски, то оптимизировать их работу мы можем с помощью Raid 0.

Проверка дисков

Сначала запускаем команду, которая проверит скорость записи/чтения информации на диск:

И видим следующую информацию:

Обращаем внимание на скорость записи/чтения для файлов 4k, т.е. для файлов размером 4кб, так как основной объем работы Солана проделываем как раз с файлами такого размера. На скриншоте мы видим отличные показатели диска для работы Соланы. Если ваш диск покажет скорость меньше 500мб/с на запись/чтение, то с большей долей вероятности этот диск не подойдет для работы Соланы. Хотя, есть успешные истории людей, которые запускали Солану на HDD-дисках, в которых скорость еще меньше. Но мы люди не рисковые, делать будем все максимально безопасно, чтобы в будущем не хапнуть проблем.

Также хорошо бы посмотреть, новые нам дали диски или старые, хотя даже диски использованные на 50% могут работать отлично, при этом многие дата-центра не будут вам менять диски, если с ними все в порядке, но они не новые. Эта информация больше нужна нам самим, для понимания, с каким железом мы работаем, писать в саппорт с предъявами, что нам поставили старые диски смысла особо нет, но вы можете попробовать это сделать ).

Итак, сначала смотрим список всех дисков, которые установлены на нашем сервере, вводим команду:

И видим такую информацию:

Красным я выделил диски и их названия в системе, теперь нам нужно проверить каждый из них, для этого устанавливаем сначала утилиту smart:

apt install smartmontools

Далее смотрим информацию по первому диску:

smartctl -a /dev/nvme0n1

Видим следующее:

1. Модель нашего первого NVME диска
2. Объем нашего первого NVME диска
3. Критическая температура, выше которой нашему диску будет плохо

Спускаемся ниже и видим остальную информацию:

1. Текущую температуру первого NVME-диска (информация поступает с двух сенсоров)
2. Процент износа диска
3. Объем информации, который уже были записаны на наш первый NVME-диск
4. Объем информации, который был считан с нашего первого NVME-диска
5. Отсутсвие информации об ошибках

Исходя из этой информации, мы можем сделать для себя несколько выводов:

Для дополнительной уверенности советую также протестировать и второй диск, в нашем случае это можно будет сделать командой:

Возможно, вам пригодится еще команда, чтобы посмотреть свободное место на дисках, вот она:

Тут видим, что у нас из 1,9Тb занято системой (потому что сейчас на диск установлена только система) 2,4Gb, а свободно 1,8Тб. Этого для работы Соланы нам более чем достаточно.

Проверка интернета

Для Соланы необходим канал в 1Гбит, обычно она потребляет не больше 300мбит/сек входящего и 300мбит/сек исходящего трафика. Суммарно за месяц в тестнете тратится около 100Тб трафика (50Тб исходящий, 50 Тб входящий), если ваш дата-центр или провайдер ограничивает скорость при достижении порога в 50Тб или меньше, то вам этот провайдер или дата-центр не подойдет, возможно, придется докупать еще трафик дополнительно. Запускаем проверку скорости первым способом:

Получаем вот такой результат:

Как мы видим на скриншоте, на нашем сервере достаточно хороший интернет, для Соланы нам его однозначно хватит.

Обычно этого теста достаточно, чтобы понять, все ли у нас хорошо с интернетом или нет, но можно протестировать его еще этим способом, устанавливаем:

и запускаем:

Видим следующее:

И этот тест тоже говорит нам, что с каналом у нас все отлично.

Проверка памяти

Достаточно редкое явление, что вам подсунули в дата-центре плохую память, но такой дата-центр как Икула (ikoula.com) частенько подсовывает битую память своим клиентам, видимо она переходит от одного сервера к другому, вдруг арендатор сервера не заметит что с ней есть проблемы и будет работать на битой памяти. Видимо так они рассуждают. Поэтому проверить память точно будет не лишним, устанавливаем memtester:

Теперь нам нужно запустить тестирование оперативной памяти, но тут есть один нюанс, memtester сможет протестировать только свободную на данный момент оперативную память. Для того, чтобы узнать, сколько на текущий момент у нас свободно оперативной памяти вводим команду:

И видимы мы следующую информацию:

1. Свободная оперативная память 61 619Мб
2. Доступная оперативная память 63 317Мб

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

Цифра 1 указывает на количество циклов, которые будет тестировать память программа memtester, в нашем случае 1 цикла будет достаточно.

61Gb = 61 * 1024 = 62 464Mb, так как это значение входит в доступную память, которая на момент проверки ровняется 63 317Мб, то у меня проверку запустить удалось. Если у вас запустить не получится и memtester выдаст ошибку, то запускайте проверку свободной оперативной памяти, в Гб это будет 61 619 / 1024 = 60Gb

В результате тестов увидим следующую информацию:

У нас все с памятью хорошо, все тесты пройдены.

Firewall

Firewall - это программа, которая выполняет роль сетевого экрана и ограничивает трафик. С одной стороны если мы умеем (реально умеем, а не думаем, что умеем) ей пользоваться она позволит нам защитить сервер от лишнего трафика, сетевых атак и взлома. С другой стороны (если вы читаете о фаирволе впервые в этом мануале) фаирвол может запороть работу ноды, что в результате выльется в высокий скип-рейт. Если вы не знаете, что это, то в работе Соланы вы можете не использовать фаирвол, все будет работать и так хорошо, но если у вас возникают проблемы с дата-центром, и он рекомендует вам ограничить трафик вашего сервера в приватные сети (это такие сети, в которые если вдруг ваша нода начинает слать трафик, то это будет выглядеть как попытка атаки, и ваш дата-центр может на время изолировать трафик вашего сервера).

Устанавливаем фаирвол:

Проверка статуса фаирвола:

После этой команды (если вы еще не производили никаких настроек фаирвола) вы увидите ответ - Status: inactive, это значит, что в данный момент вы только установили фаирвол, но он у вас еще не активен.

Далее добавляем правила, по которым наш фаирвол будет фильтровать трафик:

Первая строка разрешает нам работать по 22 порту (по этому порту мы подключаемся к нашему серверу по SSH)

Далее мы открываем порты, по которым мы будем получать и отправлять трафик по протоколу TCP.

И нижняя строчка разрешает нам отправлять и получать трафик по протоколу UPD через порты с 8000 до 8020.

Далее запрещаем ноде отправлять трафик в приватные сети (куда нельзя посылать трафик лучше всего уточнить у вашего провайдера), в данном случае написаны правила для дата-центра Hetzner, у вас однозначно адреса подсетей будут другие:

После того, как создали правила дня нашего фаирвола, мы можем его включить:

И еще раз на всякий случай проверить его статус:

В ответ вы увидите список правил, который вы прописали для работы вашего фаирвола.

Root

Если вы решили устанавливать ноду под пользователем Root, а ваш дата-центр предпочитает выдавать клиентам пользователя с правами администратора (могут быть ограничения, по сравнению с пользователем Root), то вам нужно его включить и разрешить авторизоваться с помощью пользователя Root по SSH.

Вводим команда:

Видим следующее:

Вводим пароль для пользователя root, его нужно будет ввести дважды, видим такое сообщение:

Теперь нам нужно от отредактировать конфигурационный файл SSH, который позволит нам подключаться к серверу по SSH используя пользователя Root, вводим команду:

Видим следующее:

Нам интересна вот эта строка - #PermitRootLogin prohibit-password она запрещает пользователю Root авторизироваться в системе с помощью пароля.

Убираем решетку (#) из строчки PermitRootLogin, убираем значение prohibit-password и дописываем в конце yes, чтобы было вот так:

Нажимаем ctrl+c, сохраняем изменения (нажимаем y, потом enter)

Перезагружаем сервис SSH:

Далее система попросит ввести текущий пароль от пользователя, под которым вы подключены сейчас к серверу по SSH, вводим пароль.

После введения пароля системы ответит нам, что сервис SSH перезапустился.

Все, мы включили пользователя Root и разрешили ему подключаться к серверу по SSH, теперь нам нужно проверить, все ли нормально, для этого еще раз подключаемся к нашему серверу по SSH (не закрываем старое подключение), но теперь уже под пользователем root и паролем, который мы задали. Если подключение прошло успешно, то смело можем закрывать старое подключение под пользователем. Теперь у нас все работает под root. Мы молодцы)

Ram-диск

Что такое рамдиск?

Рамдиск представляет собой область в оперативной памяти, куда оперативная система может складывать файлы для хранения, словно они находятся на жестком диске.

Для чего он нужен и нужен ли нам он вообще?

В официальной документации Соланы написано, что если на вашем сервере много оперативной памяти, то вы можете использовать рамдиск для хранения на нем папки accounts. Что значит много?

• Если мы ставим ноду для тестнета, то там во время обычной работы сети Солана потребляет порядка 32Гб оперативной памяти, с возможными скачками до 64Гб, а в моменты стресс-тестов и 128Гб не хватает, спасает свап.
• Если мы говорим о майннет, то тут оперативной памяти Солана потребляет больше и 64ГБ тут минимальное значение с возможными скачками до 128Гб, но бывают момент, когда сеть нереально загружена и 128Гб оперативной памяти в майннете тоже не хватает, и тут опять же спасает свап.

Поэтому, если у вас 128Гб оперативной памяти, то и для тестнета и для майннета можно сделать рамдиск на 300Гб, при этом свап можно сделать 250-300Гб (я делаю 300Гб).

Что такое свап?

Свап или файл подкачки, представляет собой место на жестком диске, куда операционная система записывает файлы, которые не могут поместиться в операционной памяти потому, что оперативная память уже занята. И тут возникает вопрос, а зачем нам делать рамдиск, который будет храниться частично в оперативной памяти, а остальную информацию система будет скидывать в свап? А все просто, в свап система скидывает те файлы, которые ей в данный момент особо не нужны, а вот в оперативную память она будет записывать те файлы, которые нужны прямо сейчас и очень сильно нужны.

Если вы решили делать рамдиск (я делаю всегда), то вот инструкция:

1. Отключаем все файлы подкачки (свап):

2. Создаем новый свап-файл для хранения данных размером в 300Гб:

В результате создания увидим такую картину:

3. Задаем необходимые права для свап-файла:

4. Создаем свап из свап-файла:

Видим следующее:

5. Включаем файл подкачки (свап):

6. Проверить свап файл и память можно командой:

Видим следующее:

Вот и появился наш раздел с файлом подкачки.

7. В конфигурационный файл файловой системы fstab добавляем информацию о новом файле и комментируем старые файлы подкачки (свапы):

Комментируем решеткой, ищем строчки, где содержатся слова swap и их комментируем (выключаем) с помощью символа решетка - #, вот так:

Добавляем в конец файла 2 строчки:

В общем запись будет иметь такой вид:

Нажимаем на клавиатуре ctrl+x, затем y и enter

8. Создаем новую папку для рамдиска:

9. Монтируем папку в качестве нового раздела:

10. Проверяем созданный рамдиск командой:

Видим:

На этом все, наш рамдиск готов, теперь нам лишь осталось в сервисном файле указать, где будет храниться папка accounts, это мы сделаем уже после установки Соланы с помощью параметра:

Установка ноды под Root

В этом пункте вы уже должны протестировать свой сервер и сделать необходимые настройки, а именно:

• Однозначно должен быть сделан Raid 0,
• Настроен Root (по желанию, но я делаю все только под рутом),
• Протестирован жесткий диск
• Протестирован интернет канал
• Протестирована оперативная память
• по желанию настроен фаирвол (можете его вообще не устанавливать, как я),
• создан рамдиск.

Теперь нам нужно узнать, какую на данный момент версию команда просит чтобы устанавливали валидаторы? Так как если вы зайдете на https://docs.solana.com/cli/install-solana-cli-tools, то с большей вероятностью вы увидите последнюю версию Соланы, которая еще не рекомендована для всех валидаторов, что в теснтете, что в майннет, поэтому нам нужно будет зайди в дискорд проекта и посмотреть анонсы:

1. Для майннета
2. Для тестнета

Там вы увидите просьбы команды обновиться до той или иной версии, также вы можете перейти на сайт SolanaTools и посмотреть, на какой версии в тестнете или в майннет больше всего валидаторов и поставить эту версию вот такой командой:

Видимо вот такой результат:

Солана просит нас или закрыть текущую сессию (отключиться от сервера) и подключиться снова или прописать нижнюю строчку в консоль, отключаться мы не будем, а просто выделим эту строчку и введем в консоль:

Потом смотрим, добавили ли мы в переменную PATH пути до Соланы, вводим:

Увидим вот такую страшную строку, у вас она может быть другой, так что не пугаемся:

Далее создаем папку solana, в которой у нас все (кроме папки accounts) будет храниться:

Переходим в эту папку:

Настройки конфига соланы

Теперь задаем стандартные настройки для кластера, в котором мы будем работать и для ключа, которым мы по дефолту будем подписывать все транзакции:

Для тестнета:

Увидим следующее:

Для майннета:

Сюда скриншот вставлять не буду, разница будет только в адресе и файле.

Создание ключей

Теперь мы будем или создавать ключи (если мы первый раз устанавливаем ноду и у нас вообще нет никаких ключей) или будем их копировать с нашего домашнего компьютера на сервер.

Создаем основной ключ валидатора:

И видим следующее:

Система предлагает нам добавить дополнительное слово в нашу стандартную мнемоническую фразу, которая состоит из 12 слов, если вы добавите это слово, то мнемоника вашего ключа будет состоять уже из 13 слов (точнее 12+1), вероятно, это уменьшает шансы на взлом вашего ключа, но я не использую дополнительной слово и просто нажимаю Enter, в результате система нам покажет нам:

1. Путь до созданного ключа и его имя (можете создать ему любое имя, это нужно только для вашего удобства, чтобы вы понимали где какой ключ у вас находится).
2. Публичный ключ, по которому можно осуществлять перевод на этот ключ.
3. Приватный ключ в виде мнемонической фразы

Запрашиваем на свой основной ключ токены из тестовой сети, для этого идем на сюда и вводим публичный ключ своего основного ключа, жмем "show me the money!":

Ждем надписи на сайте Tokens sent! и проверяем баланс нашего кошелька:

И видим там 100 SOL:

Создаем ключ для воут-аккаунта:

Тут все один в один, как и с основным ключом валидатора, создаем, сохраняем на свой компьютер файл, записываем мнемоническую фразу.

Создаем ключ для ауторизед виздравера (Authorized Withdrawer Account):

Тут все один в один, как и с основным ключом валидатора, создаем, сохраняем на свой компьютер файл, записываем мнемоническую фразу.

Из ключа, который мы создали для воут-аккаунта, делаем это самый воут-аккаунт, и сразу в этой же команде назначаем ауторизет виздравером тот ключ, который мы для этого создали следующей командой:

И видим что у нас все получилось:

Если бы у нас не было SOL на основном ключе, то мы бы не смогли создать воут-аккаунт для нашего основного ключа, так как для этой операции нам нужны SOL для оплаты комисси, которая составляет около 0,026 SOL. Столько стоит эта операция хоть в тестнете, хоть в майннете.

Или после того, как вы сделали войт-аккаунт (без ауторизет виздравера), вот так:

Или после того, как вы сделали войт-аккаунт (с авторизет виздравером), вот так:

За место 81iuTYDaeJ71XFGkPXNUuQ8gNvHQfBxpU7Vj2hzJ9Q4e ставите пабкей своего воут-аккаунта.

Продолжаем установку Соланы.

Установка систюнера

Систюнер представляет собой набор настроек, которые оптимизируют операционную систему для работы Соланы. Так как систюнер уже встроен в Solana CLI, то мы можем или запускать его каждый раз перед запуском или рестартом Соланы вот так:

Или прописать те настройки, которые устанавливает систюнер, сразу в систему и не запускать его каждый раз перед стартом или рестартом Соланы. Мы пойдем вторым путем, сразу пропишем все настройки и не будем систюнер постоянно запускать, для этого вводим эти команды по очереди, всего 3 команд:

sudo bash -c "cat >/etc/sysctl.d/21-solana-validator.conf <<EOF
# Increase UDP buffer sizes
net.core.rmem_default = 134217728
net.core.rmem_max = 134217728
net.core.wmem_default = 134217728
net.core.wmem_max = 134217728

# Increase memory mapped files limit
vm.max_map_count = 1000000

# Increase number of allowed open file descriptors
fs.nr_open = 1000000
EOF"

sudo sysctl -p /etc/sysctl.d/21-solana-validator.conf

sudo bash -c "cat >/etc/security/limits.d/90-solana-nofiles.conf <<EOF
# Increase process file descriptor count limit
* - nofile 1000000
EOF"

Сервисный файл. Создание и настройка

Теперь создаем сервисный файл:

И записываем в этот файл следующее:

[Unit]
Description=Solana Node
After=network.target syslog.target
StartLimitIntervalSec=0
[Service]
Type=simple
Restart=always
RestartSec=1
LimitNOFILE=1024000
Environment="SOLANA_METRICS_CONFIG=host=https://metrics.solana.com:8086,db=tds,u=testnet_write,p=c4fa841aa918bf8274e3e2a44d77568d9861b3ea"
ExecStart=/root/.local/share/solana/install/active_release/bin/solana-validator \
--entrypoint entrypoint.testnet.solana.com:8001 \
--entrypoint entrypoint2.testnet.solana.com:8001 \
--entrypoint entrypoint3.testnet.solana.com:8001 \
--known-validator 5D1fNXzvv5NjV1ysLjirC4WY92RNsVH18vjmcszZd8on \
--known-validator 7XSY3MrYnK8vq693Rju17bbPkCN3Z7KvvfvJx4kdrsSY \
--known-validator Ft5fbkqNa76vnsjYNwjDZUXoTWpP7VYm3mtsaQckQADN \
--known-validator 9QxCLckBiJc783jnMvXZubK4wH86Eqqvashtrwvcsgkv \
--only-known-rpc \
--expected-genesis-hash 4uhcVJyU9pJkvQyS88uRDiswHXSCkY3zQawwpjk2NsNY \
--wal-recovery-mode skip_any_corrupted_record \
--identity /root/solana/validator-keypair.json \
--vote-account /root/solana/vote-account-keypair.json \
--ledger /root/solana/ledger \
--accounts /mnt/ramdisk/accounts \
--snapshot-interval-slots 500 \
--maximum-local-snapshot-age 1000 \
--maximum-snapshots-to-retain 1 \
--minimal-snapshot-download-speed 20485760 \
--limit-ledger-size 50000000 \
--dynamic-port-range 8000-8020 \
--log /root/solana/solana.log \
--private-rpc \
--rpc-port 8899
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
[Install]
WantedBy=multi-user.target

Взять и скопировать сервисный файл вообще не добавляет человеку ни знаний, ни счастья, а только умножает печали, поэтому, чтобы мы не печалились, будем разбирать каждый параметр, который используем. Поехали.

Начиная с версии 1.9 команда добавила в Солану инкрементальные снепшоты, за место вот этих параметров:

--snapshot-interval-slots 500 \
--maximum-local-snapshot-age 1000 \
--maximum-snapshots-to-retain 1 \

Вы можете поставить эти:

--incremental-snapshots \
--full-snapshot-interval-slots 25000 \
--incremental-snapshot-interval-slots 500 \
--maximum-full-snapshots-to-retain 1 \
--maximum-incremental-snapshots-to-retain 2 \
--maximum-local-snapshot-age 1500 \

Опишу каждый параметр я ниже.

--entrypoint - Точка входа для Соланы, представляет собой такую же ноду, как и у нас, только она мощнее и является своеобразным маяком, на который ориентируются рядовые ноды в кластере. Эта нода принадлежит команде Соланы. Для каждого кластера мы указываем свои энтрипоинты, их мы можем найти в официальной документации Соланы

--known-validator - известный нам валидатор, которому мы доверяем и с которого мы будем качать снепшоты в случае, если мы их не пишем на свой жесткий диск или они оказались повреждены. В случае, когда мы берем этих валидаторов с доков соланы (для каждого кластера свои кноун-валидаторы), то мы указываем ноды, которые принадлежат команде Соланы, также мы можем указать там своего друга и качать снепшоты с него (но чтобы это заработало, нужны настройки его ноды, ниже об этом будет сказано)

--only-known-rpc - запрещает вашей ноде качать снепшоты с НЕ известных вам валидаторов, если у вас стоит этот параметр, то вы будете качать снепшот только с тех валидаторов, которые указали в параметре --known-validator, если же этого параметра не будет, то сначала нода попробует скачать снепшот с кноун-валидаторов, и если не получится, начнет качать у других. Почему этот параметр может оказаться важным? Все потому, что он защищает кластер от злоумышленников. Если вдруг владелец ноды, с которой можно качать снепшоты, изменит снепшот и внедрит в него вредоностный код, то ноды, которые будут с него качать этот снепшот будут делать то, что нужно ему. Если в тестнете это не критично, так как перезапустить сеть не стоит денег, а вот в майннете это может дорогого стоить, поэтому в майннете лучше качать снепшоты с доверенных нод.

--expected-genesis-hash - Ожидание определенного хэша у генезиса

--wal-recovery-mode - Режим восстановления леджера

--identity - путь до нашего основного ключа

--vote-account - путь до нашего воут-аккаунта

--ledger - путь до леджера

--accounts - путь до папки с аккаунтами

--snapshot-interval-slots - интервал, через сколько слотов делать снепшоты

--snapshot-compression - сжимать или не сжимать снепшоты, которые мы записываем на диск, если указываем значение none - то не сжимаем, если вообще не указываем параметр "--snapshot-compression" в сервисном файле - то сжимаем

--snapshot-archive-format - в каком формате будем сжимать снепшоты, если их сжимаем. По дефолту - zstd, могут быть варианты: bz2, gzip, zstd, tar.

--maximum-local-snapshot-age - этот параметр необходим для того, чтобы нода стартовала с локального снепшота в том случае, если он моложе этого показателя. Если поставите значение 2000, то с локального будете стартовать тогда, когда ваш локальный снепшот младше 2000 слотов (менее 2000 слотов отстает от кластера на данный момент), если старше - нода скачает свежий снепшот с кластера.

--incremental-snapshots - наличие этого параметра в вашем сервисном файле говорит о том, что вы включили функцию инкрементальных снепшотов.

--full-snapshot-interval-slots - через сколько слотов делать полный снепшот кластера.

--incremental-snapshot-interval-slots - через сколько слотов делать инкрементальные снепшоты.

--maximum-full-snapshots-to-retain - максимальное количество полных снепшотов кластера, которые будут храниться в вашем леджере (или в том месте, где укажите, чтобы хранились ваши снепшоты)

--maximum-incremental-snapshots-to-retain - максимальное количество инкрементальных снепшотов, которые будут храниться в вашем леджере (или в том месте. где укажете, чтобы хранились ваши снепшоты

--maximum-snapshots-to-retain - сколько снепшотов хранить на диске (этот параметр используется в случае, если инкрементальные снепшоты мы не включали)

--minimal-snapshot-download-speed - минимальная скорость скачивания снепшотов, этот параметр будет работать только в том случае, если есть выбор откуда качать снепшоты. Если у нас стоит запрет на скачивание снепшотов с НЕ известных для нас валидаторов, то скачивание снепшота будет идти с тех, кого мы указали в списке известных валидаторов, вне зависимости от скорость, с которой это скачивание будет происходить.

--limit-ledger-size - ограничение размера леджера, которое исчесляется в шредах, что такое шреды читаем тут.

--dynamic-port-range - порты, на которые Солана будет принимать и отправлять трафик.

--log - путь до файла с логами. Если этот параметр не указан, что логи будут писаться с системный журнал Соланы, как их смотреть в этом случае смотрим тут.

--private-rpc - запрещает другим валидаторам качать с вас снепшоты и выполнять другие действия с помощью RPC-команд, которые могут нагружать ваш сервер. Для обычных валидаторов (таких как мы) команда не советует открывать RPC наружу.

--rpc-bind-address - этот параметр раньше выполнял роль параметра --private-rpc, по идее его уже можно не использовать, на на всякий случай он есть в моем сервисном файле.

--rpc-port - на каком порте будет работать RPC, если вдруг вы решите ее открыть наружу и сделать доступной для других. В этом случае этот порт должен быть у вас открыт (если вы используете фаирвол)

--no-port-check - не выполнять проверку доступных портов для работы Соланы. Вы можете поставить этот параметр себе в сервисный файл после того, как проверите, что у вас Солана работает нормально и логах нет никаких ошибок, связанных с портами. Этот параметр может сократить время запуска Соланы после перезагрузки на несколько секунд.

Параметры, которые могут нам пригодиться в момент подъема кластера, после падения сети:

--expected-shred-version

--wait-for-supermajority - запускает работу ноды полностью только тогда, когда 80% стейка окажется на слоте, который на 1 меньше значение, которое указано в параметре

--no-snapshot-fetch - запрет на скачивание снепшотов с других валидатор. Старт с локального снепшота, если он есть

--no-genesis-fetch - не запрашивать из кластера данные о генезисе

Информацию по остальным параметрам вы можете найти в своем терминале введя команду:

Установка logrotate

Для чего нам нужно?

Логротейт позволяет нам создать ротацию для файла лога, если сказать простым языком, то файл с логированием всех событий в Солане мы режем на куски, которые по времени равны одному дню. Файлы, которые содержат логи старше чем за 7 дней система удаляет. Итого у нас в системе находится актуальный файл с логами за текущий день плюс 7 файлов логов за последние 7 дней. Файл с логами за каждый день в Солане весит около 10Гб, итого получается мы храним 70Гб логов за 7 дней плюс логи за текущий день.

Создаем файл в папке Solana:

nano solana.logrotate

И записываем в него следующее:

/root/solana/solana.log {
rotate 7
daily
missingok
postrotate
systemctl kill -s USR1 solana.service
endscript
}

Что значат эти параметры?

rotate 7 - храним 7 файлов;

daily - интервал файлов 1 день;

missingok - не записывать сообщение об ошибке, если файл с логом отсутсвует;

postrotate - после этой команды и между endscript записывается команда, которая будет выполнена после создания каждого файла с логами.

systemctl kill -s USR1 solana.service - отправляет сигнал USR1 процессу solana-validator (так называется процесс нашей ноды Соланы) на пересоздание лог файла.

Создание символических ссылок

Для чего нам нужны?

Символические ссылки это своеобразные ярлыки на файлы или папки в Windows, используем мы их для удобства, чтобы производить редактирование сервисного файла из папки solana, а не из папки /etc/systemd/system

Создаем символические ссылки следующими командами

для Соланы:

ln -s /root/solana/solana.service /etc/systemd/system

для логротейта:

ln -s /root/solana/solana.logrotate /etc/logrotate.d/

Включение сервиса Соланы и запуска ноды

Теперь нам остался последний шаг, нам нужно включить в системе сервис и запустить Солану:

systemctl daemon-reload
systemctl enable solana.service
systemctl start solana.service

systemctl daemon-reload - эта команда выполняет роль "мягкой" перезагрузки системы, обновляет конфигурации из файловой системы и восстанавливает деревья зависимостей.

systemctl enable solana.service - эта команда автоматически запускает Солану после перезагрузки вашего сервера.

systemctl start solana.service - запускает Солану.

Установка ноды под пользователем (не Root)

Администрирование ноды

Скачивание снепшота с быстрых RPC Node до рестарта соланы

Как заменить пароль на ключ и изменить порт для SSH

Как читать логи?

Мониторинг температуры

Установка аватарки и смена имени ноды на сайте валидатор.апс