Запуск полного узла EOS и настройка ZFS

Оригинал: https://medium.com/@cc32d9/running-a-full-eos-node-and-tuning-zfs-5830c45908d1

На сегодняшний день сети EOS уже почти 6 месяцев, и она очень быстро растет. Блокчейн обслуживается nodeos software daemons, работающим в Peer-to-peer сети. Как правило, Блок Продюсер будет запускать nodeos серверы и предоставлять публичные конечные точки API для пользователей.

Один из публичных API обеспечивается через history_plugin, который требует значительных технических ресурсов и затрат на обслуживание. Время от времени, он имеет тенденцию к сбоям, и его полное восстановление может занять несколько дней. Есть несколько текущих проектов, нацеленных на предоставление альтернативы этому плагину: 1, 2, 3, 4.

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

Вашему интерактивному приложению требуется быстрый ответ от узла API, а те, которые предоставляются блок продюсерами, слишком медленные или они слишком далеко;
Вы хотите запустить определенные плагины, такие как плагин ZMQ и т. п., Для экспорта событий в режиме реального времени из блокчейна и обработки их вашими приложениями.
Вам нужен ближайший Peer-to-peer узел для поддержки ваших других nodeos случаев с данными блока.

ZFS - многофункциональная файловая система, разработанная Sun Mycrosystems, и в настоящее время доступна на Linux. В частности, в системе Ubuntu 18.04 он есть в стандартном дистрибутиве ОС, ему нужно только несколько пакетов для установки. Среди других возможностей ZFS позволяет быстро и легко создавать снапшоты, а также быстро откатываться к уже существующм снапшотам. Также он поддерживает сжатие и настраиваемый размер записи, подходящий для приложения.

Таким образом, для запуска сервера nodeos по состоянию на ноябрь 2018 года вам нужен физический или виртуальный сервер с объемом памяти не менее 16 ГБ, также 50-Гбайтый накопитель для операционной системы с объемом хранения в 500 ГБ для пула ZFS.

Я использую контейнер LXC в своем сценарии, но это необязательно. nodeos также может работать в основной ОС. Но LXC позволяет изолировать контейнер по функциональности, а также позволяет легко копировать весь контейнер на другой сервер.

Внутри пула создаются несколько файловых систем ZFS:

Операционная система контейнера LXC. Это стандартная файловая система ZFS с recordsize=128k, primarycache=all. При необходимости вы можете зашифровать ее.
state данные для nodeos. Это большой разреженный файл, представляющий состояние памяти EOS. Обычно выделяется 32 ГБ, а сам файл занимает около 3 ГБ данных. Файл состояния представляет собой общий сегмент памяти Linux, сопоставленный с файлом. Я не смог найти информацию о том, как Linux читает и записывает его, а strace не показывает эти файловые операции. Если предположить, что стандартная memory page Lunux составляет 4 КБ, имеет смысл выделить ее с помощью recordsize=128k, primarycache=metadata. Поскольку его содержимое уже представляет состояние RAM, поэтому есть смысл отключить полное кэширование содержимого и оставить только кэширование метаданных.
blocks data for nodeos. Эта папка содержит большой лог блокчейна (около 80 ГБ к моменту написания статьи) и несколько дополнительных файлов. Если nodeos воспроизводит всю цепочку, он считывает лог в 8 КБ сегментах. Если он уже синхронизирован с мейннетом, он добавляет рандомные фрагменты данных между 3 КБ и 30 КБ. Но когда соседний P2P запрашивает блоки, nodeos читает их в 8 КБ сегментах. LZ4 - очень быстрый алгоритм сжатия, поддерживаемый ZFS, и дает коэффициент сжатия 1.46x для данных блока. Таким образом, параметры ZFS: recordsize=8k, compression=lz4, primarycache=all. Есть смысл кэшировать содержимое, поскольку нескольким соседним P2P могут потребоваться данные блока. Кроме того, если случайно размер вашей записи составит 128k, кеширование только метаданных значительно снижает производительность, так как весь блок 128k. Его приходится читать несколько раз.
Мой сценарий также использует базу данных MySQL в том же контейнере. Данные MySQL обычно сжаты с коэффициентом 2x, а коэффициент сжатия binlog превышает 4x. Сжатие уменьшает нагрузку ввода-вывода на диск, что увеличивает общую производительность сервера.

ZFS очень эффективен в управлении снапшотами. Вы можете остановить nodeos в середине работы (при условии, что он не воспроизводится), и создать ZFS снапшот его блоков и данных состояния. Затем в случае какого-либо аномального сбоя вы всегда можете вернуться в промежуточную точку, не перестраивая все состояние снова. Но прежде чем откатываться назад, важно очистить кеш памяти, иначе ваши данные будут повреждены:
sync; echo 3 > /proc/sys/vm/drop_caches
Полный сценарий установки: https://gist.github.com/cc32d9/04b66b732bec9aade93abd4a1b5a715e

Переведено CryptoLions