ქაოსის ტესტირება იზანამი-სთან

Izanami არის chaosnet orchestrator upstream 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

აღნიშნული გაშვება მხოლოდ იმ შემთხვევაში ხდება, თუ კლასტერმა შეაღწია მოთხოვნილი ბლოკის მიზანს, განაგრძობს პროგრესის მიღწევას დროის განმავლობაში და რჩება optional p95 ბლოკის ინტერვალის ზღვრის ქვემოთ.

ჩაწერეთ ბრძანება, seed, Iroha commit, peer count, faulty-peer count, workload profile, target TPS და latency threshold ჩანაწერებთან ერთად. ამ მნიშვნელობების გარეშე სხვა ოპერატორი ვერ ასრულებს იგივე ხარვეზის ნიმუშს.

სამუშაო დატვირთვის პროფილები

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 უფრო დიდია, ვიდრე ნულოვანი, მინიმუმ ერთი შეცდომის სცენარი უნდა იყოს ჩართული. შეცდომა ჩართულია გათვალისწინებით ჩართულია და ბულური დროშები შეიძლება გამორთული იყოს =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 იმისთვის, რომ ინექციური ჩავარდნის წინ და შემდეგ კონტროლირებადი სტაბილური მდგომარეობის პერიოდი შეინარჩუნოთ. ეს ხელს უწყობს საწყისი ხმაურის და ხარვეზის ეფექტის განასხვავებას.

სცენარის ფორმები

Upstream Izanami კატალოგი რუკა ჩვეულებრივი blockchain კომუნიკაციის წარუმატებლობის ფორმები CLI პროფილები. თქვენ შეგიძლიათ მოდელი მათ იგივე დროშებით:

სცენარი	ტიპური ფორმა
მიზნობრივი დატვირთვა	--faulty 0, მაღალი --tps, ერთი წარმომადგენელი, მაღალი --max-inflight
დროებითი წარუმატებლობა	შეამოწმეთ ჩავარდნა / განახლება მხოლოდ დაზღვეული ხარვეზის ფანჯრის შიგნით.
პაკეტის დაკარგვა	მხოლოდ პაკეტის დაკარგვის შესაძლებლობა, ჩვეულებრივ 75%-იანი დანაკლისის დონეზე
შეჩერება და აღდგენა	გამოიყენეთ დიდი ხარვეზური პარტნიორების პოპულაცია ჩავარდნის/გადაშლის დროს
ლიდერის იზოლაცია	გამოიყენეთ ზუსტად ერთი ხარვეზიანი პარტნიორი მხოლოდ ქსელის გაყოფის ან პაკეტის დაკარგვის ხარვეზებით; Izanami მოყვება Sumeragi ლიდერის ტელემეტრიას

შეინარჩუნეთ ერთი ცვლადი ფიქსირებული ერთდროულად. თუ შეცვლით თანატოლების რაოდენობას, სამუშაო დატვირთვის პროფილს, ხარვეზის ფანჯრას და TPS იმავე რეჟიმში, შედეგი რთულია ინტერპრეტაცია.

რა უნდა უყუროთ

გატარების დროს, ყურადღება მიაქციეთ იგივე სიგნალებს, რომლებიც გამოყენებულია შესრულების ვალიდატაციისთვის:

• ბლოკის სიმაღლის პროგრესი თითოეულ მიმდინარე თანატოლზე
• წარდგენილი, მიღებული, უარყოფილი და დროულად გათვალისწინებული ოპერაციები
• რიგის სიღრმე, რიგის saturation და ბოლო წერტილის backpressure
• ნახვა ცვლილებები, აღდგენის გზები, დაკარგული ბლოკები და დაკარგული კვორუმის სერტიფიკატები.
• RBC ჩამორჩენა, გამოწვეული სხდომები და შეფერხებული ან დაგვიანებული კონსენსუსის ტრაფიკი.
• CPU, მეხსიერება, დისკი და ქსელის saturation მასპინძელი run the თანატოლები

დამტკიცების დამახანგრძლივებლობის ანალიზისათვის, ჩართეთ ძირითადი ბლოკის დებუგის ლოგები:

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, შენახვის წაშლა ან პაკეტის დაკარგვის აღდგენა საჭიროებს ხელით გაწმენდას

შეცდომის შემდეგ, გაიმეორეთ იგივე მარცვლე და ერთი ნაკლები ხარვეზის ტიპი. ეს ინარჩუნებს სამუშაო დატვირთვას და დროის რეპროდუქციას, ხოლო შეამცირებს ხარვეზის ზედაპირს.

დაკავშირებული გვერდები

• შესრულება და მატერიკები
• გატარება Iroha Bare Metal-ზე
• Torii საბოლოო წერტილები