Izanami-тай хийсэн хаос туршилт

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

Изанами-ийг үйлдвэрлэлийн өмнөх уялдуулалтын шалгалт, регрессийн нөхөн үржихүйн болон санал нэгдлийн тохируулга хийхэд ашигла. Үйлдвэрлэлийн сүлжээг нэвтрүүлэхгүй: хэрэгсэл нь эхлүүлсэн ижил төстэй, тэр дундаа ижил төстэй сэргээлт хийхэд зориулагдсан. хадгалах хувцас, хиймэл багцыг алдах, орон нутгийн CPU эсвэл дискний даралт.

Урьдчилсан шаардлага

Izanami-ийг Iroha эх сурвалжийн сангаас ажиллуулж, энэ баримтын сангаас биш:

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

Бинэрийн хэрэгсэл нь сүлжээний ижил хүйстнийг бий болгох, зохицуулахыг тодорхой зөвшөөрөх ёстой. TUI бус гүйлгээний бүрт --allow-net дамжуулаарай эсвэл TUI-д allow_net-ийг ашиглах боломжтой болно.

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 блок интервалын хязгаартай доош байх тохиолдолд амжилттай болно.

Тус команд, seed, Iroha commit, peer count, faulty-peer count, workload profile, target TPS болон latency thresholdг бүртгэе. Эдгээр үнэлгээгүйгээр өөр оператор нь ижил алдааны загварыг дахин тоглож чадахгүй.

Ажлын ачаалал Profiles

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 загварыг ашиглах ёстой үед хэрэглэх.

Халуулгын хяналт

--faulty нь нулаас том бол хамгийн багадаа нэг алдааны үзэгдлийг идэвхжүүлэх ёстой. Халуун алдааг урьдчилсан хэлбэрээр идэвхтэй болгодог бөгөөд boolean flags-ийг =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-ийг хэрэглэж, инжекциялагдсан алдааны өмнөх болон дараагийн хяналтын тогтвортой байдалд байх хугацааг хадгалж байна. Энэ нь эхлүүлэх шуугийг алдааны үр нөлөөөөс ангилах илүү хялбар болгодог.

Сценарий хэлбэр

Изанами-ийн захиргааны каталог нь 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 давж байна
• Халуун цахилгаан дэлгэц хаагдсанаас хойш гүйлтийн үлдсэн хэсэгт шуурхай өсдөг.
• татгалзсан эсвэл хугацааг дууссан гүйлгээ нь сонгогдсон ажлын ачаалалтайгаар тайлбарлагдахгүй байна
• "Peer restart, storage wipe" эсвэл "Packet-loss" нөхөн сэргээлт нь гар угаах шаардлагатай.

Хөгжлийн бэрхшээлээс хойш ижил үр тариа, нэг удаа бага алдаатайгаар дахин ажиллуулъя. Энэ нь ажлын ачаалал, цаг хугацааг нөхөн сэргээх боломжийг хангасан бөгөөд алдааны давхаргыг буурах боломжтой болгодог.

Үүнтэй холбоотой хуудсууд

• Үйл ажиллагааны үзүүлэлтүүд
• Iroha Bare Metal дээр ажиллаж байна
• Torii эцсийн цэгүүд