Тестирование хаоса с Izanami

Izanami - это хооснет-оркестратор в рабочем пространстве Iroha. Он запускает одноразовый локальный кластер Iroha, отправляет конфигурируемую рабочую нагрузку и вводит ошибки в выбранные коллеги, чтобы операторы могли проверить, продолжает ли сеть добиваться прогресса при контролируемой неисправности.

Используйте Izanami для проверки устойчивости до производства, регрессионного воспроизводства и консенсусной настройки. Не указывайте его на производственную сеть: инструмент предназначен для того, чтобы владеть перезагрузками, в том числе перезагрузочными пусками, полотенцами для хранения, искусственной потерей пакетов и локальным CPU или давлением диска.

Предварительные условия

Запустить Izanami из Iroha источник хранилища, не из данного хранилища документации:

git clone https://github.com/hyperledger-iroha/iroha.git
cd iroha
cargo build -p izanami

Бинарный файл должен иметь прямое разрешение на создание и манипулирование сетевыми партнерами. Перейти --allow-net для каждого выполнения, не являющегося TUI или включить allow_net в TUI.

cargo run -p izanami -- --allow-net --peers 4 --faulty 1 --duration 120s

Для интерактивной конфигурации выполнения:

cargo run -p izanami -- --tui --allow-net

Izanami сохраняет настройки TUI и CLI в каталоге пользовательской конфигурации, поэтому пересмотрите отображаемые настройки перед повторным использованием предыдущего профиля.

Исходный показатель

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

cargo run -p izanami -- \
  --allow-net \
  --peers 4 \
  --faulty 1 \
  --duration 5m \
  --target-blocks 100 \
  --progress-interval 15s \
  --progress-timeout 120s \
  --latency-p95-threshold 2s \
  --tps 15 \
  --max-inflight 32 \
  --submitters 1 \
  --seed 42

Это выполнение удается только в том случае, если кластер достигает требуемой цели блока, продолжает добиваться прогресса в течение времени и остается ниже опционального порога интервала блока p95.

Зарегистрируйте команду, сейм, Iroha commit, пересчет сверстников, пересчёт неисправностей сверстника, профиль рабочей нагрузки, цель TPS и порог задержки в журналах. Без этих значений другой оператор не может воспроизвести тот же шаблон отказа.

Профили нагрузки

Izanami имеет два профиля рабочей нагрузки:

Профиль	Используйте его для	Примечания
stable	Длинные пробеги на погружении и воспроизводимые проверки производительности	Он предпочитает безопасные рецепты .
chaos	Покрытие неудачных путей	Включает намеренно недействительные рецепты

Прежде всего используйте стабильный профиль:

cargo run -p izanami -- --allow-net --workload-profile stable --seed 42

Перейти к профилю хаоса, когда базовая линия уже понята:

cargo run -p izanami -- --allow-net --workload-profile chaos --seed 42

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

cargo run -p izanami -- \
  --allow-net \
  --workload-profile stable \
  --allow-contract-deploy-in-stable

Используйте --nexus, когда выполнение должно использовать встроенные дефолты SORA Nexus из рабочего пространства "upstream".

Контролирование ошибок

Когда --faulty является более чем нулевым, должен быть включен хотя бы один сценарий ошибки. Ошибка переключается на включенный по умолчанию, и булевые флаги могут быть отключены с =false.

Ошибка .	CLI флаг	Что он делает
Сбой и перезагрузка .	--fault-enable-crash-restart	Потеря и восстановление процессов сверстников
Стирать хранилище и перезапустить	--fault-enable-wipe-storage	Восстановление после исчезновения местного государства
Недействительный спам транзакций	--fault-enable-spam-invalid-transactions	Пути приема и отказа
Задержка сети	--fault-enable-network-latency	Медленные сплетни и задержанные сообщения консенсуса
Сетевое разделение	--fault-enable-network-partition	Временная изоляция с доверенными людьми
P2P потеря пакета	--fault-enable-network-packet-loss	Снижение трафика в рамках приложений
CPU стресс	--fault-enable-cpu-stress	Местное давление на проверку и расписание
Насыщение диска	--fault-enable-disk-saturation	Местное давление хранения

Для курса с исключительной потерей пакетов:

cargo run -p izanami -- \
  --allow-net \
  --peers 20 \
  --faulty 5 \
  --duration 800s \
  --fault-window-start 133s \
  --fault-window-end 266s \
  --tps 200 \
  --submitters 20 \
  --max-inflight 512 \
  --fault-enable-crash-restart=false \
  --fault-enable-wipe-storage=false \
  --fault-enable-spam-invalid-transactions=false \
  --fault-enable-network-latency=false \
  --fault-enable-network-partition=false \
  --fault-enable-network-packet-loss=true \
  --fault-enable-cpu-stress=false \
  --fault-enable-disk-saturation=false \
  --fault-network-packet-loss-percent 75 \
  --seed 42

Используйте --fault-window-start и --fault-window-end для поддержания контролируемого периода стабильного состояния до и после инъекции неисправности. Это облегчает различение шума запуска от эффекта ошибки.

Сценарии формы

Каталог Izanami вверх по течению отображает общие формы неисправности коммуникации на блокчейн до профилей CLI.

Сценарий	Типичная форма
Целевая нагрузка	--faulty 0, высокий --tps, один заявитель, высокая --max-inflight
Временная неудача	Включить отказ / перезагрузку только в окне с ограниченным пробоем
Потеря пакета	Включить только потерю пакетов, как правило, с дефолтным уровнем потерь 75%
Прекращение и восстановление	Используйте большую популяцию неисправностей с отказом / перезагрузкой
Изоляция лидеров	Используйте точно один неисправенный коллега с только сетевой разделения или пакетной потери ошибок; Izanami следует Sumeragi лидер телеметрии

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

Что нужно смотреть

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

• прогресс в высоте блока по каждому бегущему партнеру
• представленные, принятые, отклоненные и завершенные сделки
• глубина очереди, насыщенность очереди и обратное давление в конечном пункте
• изменения в просмотре, пути восстановления, отсутствие блоков и отсутствие сертификатов кворума
• RBC отставание, ожидающие сессии и снижение или задержка консенсусного трафика
• CPU, память, диск и насыщенность сети на хостере, выполняющем сверстники

Для анализа валидации-задержки включить журналы дебогирования главного цикла:

RUST_LOG=iroha_core::sumeragi::main_loop=debug \
  cargo run -p izanami -- --allow-net --seed 42

Каждый блок должен выделять block validation timings с stateless_ms, execution_ms и total_ms. Сравните эти сроки с интервалами блоков p95, счетчиками изменения просмотра и давлением очереди перед изменением консенсусных таймеров.

Результаты толкования

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

Оценить бег как неудачу, если:

• прогрессные блоки более длинные, чем --progress-timeout
• высоты одинаков расходятся и не пересоединяются
• задержка p95 превышает --latency-p95-threshold
• очереди растут в течение остальной части пробега после закрытия окна неисправности
• Отказанные или отсроченные операции не объясняются выбранной рабочей нагрузкой.
• перезагрузка сверстников, стирание хранилища или восстановление потери пакета требует ручной очистки

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

Сюжетные страницы

• Продуктивность и показатели
• Работа Iroha на Bare Metal
• конечные точки Torii