В ночь с 18 на 19 декабря в период с 1:00 до 3:30 мы провели стресс-тестирование сети Minter с целью обнаружить узкие места в собственной инфраструктуре и разработать решения для того, чтобы повысить её надежность.

В результате этого мы выявили целый ряд серьезных проблем, которые касаются работы всей сети, а не только нашего валидатора.

monitoring

Часть панели мониторинга сети Minter у валидатора BTC.Secure во время стресс-тестирования

Мы провели глубокий анализ результатов стресс-теста и хотим поделиться с вами выводами, которые мы сделали.

Инструмент для повышенной нагрузки сети

Для создания высокой нагрузки на сеть Minter мы использовали специальный скрипт, который создал Даниил Лашин, ведущий разработчик сети Minter.

Принцип действия скрипта заключается в том, что обналичивается большое количество чеков за короткий промежуток времени. Данный тип транзакции создает повышенную нагрузку на оборудование каждого валидатора. В результате работы скрипта в сети начинают создаваться блоки по 10 тысяч транзакций в каждом, что является текущим пределом пропускной способности Minter.

stress-test

Работа скрипта, нагружающего сеть предельным количеством транзакций

Сохранение такой нагрузки продолжительное время (от 30 минут) позволяет увидеть множество слабых мест в инфраструктурах валидаторов.

Активные валидаторы до и после стресс-тестирования

Перед началом стресс-тестирования мы зафиксировали список активных валидаторов и их показатели.

На скриншоте ниже видно, что до начала стресс-теста было 32 активных валидатора.

before-stress-test-2018-12-18-23-53

Рейтинг валидаторов до стресс-теста

После воздействия продолжительной нагрузки на протяжении 2,5 часов их осталось всего 4. В списке на скриншоте их 5, но один из них получил за время тестирования 2 штрафа и вновь запустил валидатор.

after-stress-test-2018-12-19-3-40

Рейтинг валидаторов после стресс-теста

На графике ниже видно, как изменялось количество активных валидаторов со временем.

validators

Активные валидаторы

Динамика показателей нагрузки на сеть Minter

Как мы видим, даже непродолжительная нагрузка в течении 10 минут (с 1:10 до 1:20) привела к тому, что более 10 валидаторов выпали из списка активных и получили штрафы. Это говорит об очень низком качестве их инфраструктуры. Вы можете это увидеть на графике активных валидаторов в сравнении с объемом транзакций в этот период на следующем графике.

number-of-transactions

Количество транзакций

В период с 2:10 по 3:20, на протяжении 70 минут, практически у всех блоков количество транзакций было максимальным и равнялось 10 тысячам. При такой сильной нагрузке многие валидаторы не успевают вовремя обработать поступающие блоки и начинают накапливать счетчик пропусков, а когда таких пропусков становится 12 за последние 24 блока, то такой валидатор получает штраф 1% от суммы всех стейков за отсутствие активности и вылетает из списка.

Когда более 1/3 валидаторов не успевают обработать блок за отведенное время (в пределах 5-6 секунд), то по этому блоку начинается повторный процесс его подтверждения, что приводит к значительному увеличению времени на обработку блока. На графике ниже видно, что при длительной нагрузке, время формирования блока увеличивается с 5-6 секунд до 40-80 секунд.

block-time

Продолжительность выпуска блоков

Показатели нагрузки на инфраструктуру валидатора

На графиках ниже будет видно, как влияет нагрузка на активные соединения с другими нодами, канал связи, процессор и дисковую систему.

Как мы видим, даже непродолжительная нагрузка сократила количество соединений с другими нодами с 50 до 20. Это означает, что ноды, с которыми была потеряна связь, начали отставать от текущего уровня блока. Оставшиеся ноды перестают получать от них новые блоки, что увеличивает вероятность получения пропуска у всех.

connected-peers

Активные соединения с другими нодами

Повышенная нагрузка в десятки раз увеличивает загруженность каналов связи с 1,5-2 Mpbs до 40-50 Mbps. Это также может стать причиной пропусков блоков, если у канала низкая пропускная способность, или он работает нестабильно.

network-traffic

Канал связи

Minter также очень требователен к производительности процессора. Есть серьезные отличия в производительности виртуальных и физических ядер. Под значительной нагрузкой виртуальный процессор не справляется со своей задачей, особенно это заметно при использовании конфигурации с 1 ядром, где явно видно, что процессор не успевает обрабатывать новые блоки, и создается очередь. Нагрузка процессора до 1.0 для 1-го ядра, 2.0 для 2-х ядер и 4.0 для 4-х ядер является приемлемой, однако, отсутствие очереди не означает, что блок будет обработан за отведенное время.

cpu-load

Нагрузка процессора

Значительно возрастают требования к скорости записи на диск (до 15-20 MB/s). Хотя это не такие уж и большие значения для жестких дисков, но сэкономить на дисковой системе не получится.

disk-read-write-bytes

Скорость чтения/записи диска

Пока блок не будет полностью записан на диск, то валидатор не сможет поставить свою подпись. Чем больше транзакций в блоке, тем больше операций записи будет сделано на диск. Здесь важна молниеносная реакция дисковой системы и её высокая надежность, ведь ошибки не допустимы.

disk-read-write-ops

Количество операций чтения/записи диска

Итоги стресс-теста в цифрах

  • 2,5 часа практически непрерывного нагрузочного тестирования
  • 1 миллион новых транзакций в сети
  • Время формирования новых блоков поднималось с 5 до 80 секунд
  • Из 32 валидаторов до конца теста дожило всего 4
  • Лучше всего себя показали валидаторы BTC.Secure и Monster Node, получив по 5-6 пропусков блоков и то, не подряд

Почему только 2 валидатора показывают максимально стабильные результаты, и что происходит с другими 30?

Ответ на этот вопрос мы получили, проанализировав географическое местоположение узлов в сети и некоторые другие параметры.

Исследование дополнительных факторов, влияющих на надежность сети

Мы также провели анализ активных узлов во всей сети и получили интересные результаты.

node-map

Географическое положение узлов в сети

Территориально узлы расположены следующим образом:

37 – Германия
32 – Россия
13 – Финляндия
8 – Франция
5 – Нидерланды
5 – США
4 – Великобритания
5 – Другие страны (не Европа)

data-centry-i-provaidery-oblachnyh-uslug

Большое количество узлов находится в Hetzner Online (21 нода) и провайдерах облачных услуг DigitalOcean (16 нод), а так же Google Cloud (10 нод). Кроме этого, 29 нод расположены в различных дата-центрах или в сложно определяемых условиях, среди них есть как надежные, так и нет.

port-dlya-raboty-minter-26656

Особое внимание хотелось бы уделить тому, что 2/3 активных узлов до сих пор имеют закрытые 26656 порты. В статистике по портам учтено, что в инфраструктурах валидаторов могут быть скрытые узлы, к которым не должно быть свободного доступа извне. В случае правильной настройки инфраструктуры валидатора, никто не смог бы получить информацию о том, что имеются узлы с закрытыми портами, их просто не будет в адресных книгах и списках активных соединений.

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

Выводы

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

Наши рекомендации:

  • Настроить прямые соединения с надежными узлами, чтобы уменьшить длину цепочки между валидататорами;
  • Необходимо иметь большой запас по пропускной способности канала связи, так как фактическая скорость не всегда соответствует заявленной, а при увеличении нагрузки загруженность канала вырастает в десятки раз;
  • Использовать для валидатора, сторожевых (Sentry Node) и API узлов выделенные (железные) сервера с максимально производительным процессором (частота от 3,5 GHz) и быстрым SSD;
  • В идеале, основные узлы нужно расположить в Германии и Финляндии;
  • Выбрать надежного поставщика услуг для установки оборудования (дата-центр), такие как Hetzner Online, Interxion, Equinix;
  • Открыть порт 26656 для входящих соединений, если узел является публичным. Правильно настроить конфигурацию тех узлов, которые должны быть скрыты (private_peer_ids в config.toml).

Ранее мы делали серьезную ставку на облачную инфраструктуру, но позже пришли к выводу, что облако является хорошим решением для защиты от DDoS-атак, но плохо справляется с обработкой больших блоков.

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

В основании высокодоступной инфраструктуры валидатора в сети Minter должны стоять мощные выделенные сервера для валидатора и основных сторожевых узлов (Sentry Node). А в качестве резервных узлов для защиты от DDoS-атак нужно использовать легко масштабируемые облачные решения.

Как обычно, задать вопросы и предлагать свои идеи, вы можете в сообществе BTC.Secure в Telegram.

Подписывайтесь на наш Telegram-канал, чтобы не пропускать полезный контент от команды BTC.Secure и получить доступ к нашим разработкам в первых рядах.