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 بلاک وقفے کی حد سے نیچے رہتا ہے.

نوشتہ جات کے ساتھ کمانڈ ، سیڈ ، Iroha کمیٹ ، ہم مرتبہ گنتی ، غلط ہم مرتبہ گنتا ، ورک لوڈ پروفائل ، ہدف TPS ، اور تاخیر کی حد کو ریکارڈ کریں۔ ان اقدار کے بغیر ، دوسرا آپریٹر ایک ہی خرابی کا نمونہ دوبارہ نہیں چلا سکتا ہے۔

کام کا بوجھ پروفائلز

Izanami دو کام کے بوجھ پروفائلز ہے:

پروفائل	اسے استعمال کریں	نوٹ
stable	لمبی ڈائیونگ اور reproducible کارکردگی کی جانچ	عملدرآمد کے لئے محفوظ ترکیبیں پسند کرتا ہے
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 کا استعمال کرتے ہوئے انجیکشن کی خرابی سے پہلے اور بعد میں ایک کنٹرول شدہ مستحکم حالت کی مدت کو برقرار رکھنے کے لئے۔ اس سے افتتاحی شور کو خرابی کے اثر سے ممتاز کرنا آسان ہوجاتا ہے۔

منظرنامے کی شکلیں

Upstream Izanami کیٹلاگ CLI پروفائلز کے لئے عام بلاکچین مواصلات ناکامی شکلوں کا نقشہ بناتا ہے۔ آپ انہیں ایک ہی پرچم کے ساتھ ماڈل کرسکتے ہیں:

منظرنامہ	عام شکل
ٹارگٹ بوجھ	--faulty 0 ، اعلی --tps، ایک جمع کرنے والا، اعلی --max-inflight
عارضی ناکامی	حادثہ/ری اسٹارٹ کو محدود خرابی کی ونڈو کے اندر ہی قابل بنائیں
پیکٹ کا نقصان	صرف پیکٹ نقصان کو فعال کریں، عام طور پر ڈیفالٹ 75٪ نقصان کی شرح کے ساتھ
روکنے اور بازیابی	حادثہ/ری اسٹارٹ کے ساتھ بڑے پیمانے پر غلطی والے ہم مرتبہ آبادی کا استعمال کریں
لیڈر الگ تھلگ	صرف نیٹ ورک پارٹیشن یا پیکٹ نقصان کی خرابیوں کے ساتھ بالکل ایک ناقص ہم مرتبہ کا استعمال کریں؛ Izanami Sumeragi رہنما ٹیلی میٹری پر عمل کرتا ہے

ایک وقت میں ایک متغیر کو فکسڈ رکھیں۔ اگر آپ ایک ہی بار میں ہم مرتبہ گنتی ، ورک لوڈ پروفائل ، خرابی ونڈو اور TPS کو تبدیل کرتے ہیں تو ، نتائج کی تشریح کرنا مشکل ہے۔

کیا دیکھنا ہے

دوڑ کے دوران، کارکردگی کی توثیق کے لئے استعمال کئے گئے اسی سگنل پر نظر رکھیں:

• ہر دوڑنے والے ہم مرتبہ میں بلاک اونچائی کی ترقی
• پیش کردہ، قبول شدہ، مسترد اور ٹائم آؤٹ ہونے والی لین دین
• قطار کی گہرائی، قطار کے saturation، اور اختتامی پوائنٹ بیک پریشر
• تبدیلیاں دیکھیں، بازیابی کے راستے، لاپتہ بلاکس اور لاپتہ کووروم سرٹیفکیٹ۔
• RBC بیک لوگ، زیر التواء سیشن اور کمی یا تاخیر سے اتفاق رائے ٹریفک
• CPU ، میموری، ڈسک، اور میزبان پر نیٹ ورک کے saturation ہم مرتبہ چل رہا ہے

توثیق کی تاخیر کے تجزیہ کے لئے، مین لوپ ڈیبگ logs فعال کریں:

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

ہر بلاک کو stateless_ms ، execution_ms، اور total_ms کے ساتھ block validation timings جاری کرنا چاہئے۔ اتفاق رائے ٹائمرز کو تبدیل کرنے سے پہلے ان اوقات کا موازنہ p95 بلاک وقفوں ، نقطہ نظر کی تبدیلی کاؤنٹرز ، اور قطار کے دباؤ سے کریں۔

نتائج کی تشریح

جب تمام منتخب کردہ ہم مرتبہ بلاکس کا ارتکاب جاری رکھیں تو ایک رن کو صحت مند سمجھیں ، بیک لوگ بغیر پابندی کے نہیں بڑھتا ہے ، اور ترتیب شدہ ونڈو ختم ہونے کے بعد غلطیوں سے نئی بازیافت کی سرگرمی ختم ہوجاتی ہے۔

ایک رن کو ناکامی کے طور پر علاج کریں جب:

• --progress-timeout سے زیادہ عرصے تک بلاک ترقی اسٹال۔
• ہم منصب اونچائیوں میں فرق ہوتا ہے اور دوبارہ تبدیل نہیں ہوتا
• p95 تاخیر --latency-p95-threshold سے زیادہ ہے
• ایک خرابی ونڈو بند ہونے کے بعد قطاریں باقی رن کے لئے بڑھتی ہوئی ہیں
• مسترد شدہ یا ٹائم آؤٹ ہونے والی ٹرانزیکشنز کی وضاحت منتخب کردہ کام کے بوجھ سے نہیں ہوتی
• پیئر ری اسٹارٹ، سٹوریج مسح، یا پیکٹ نقصان کی بحالی دستی صفائی کی ضرورت ہوتی ہے

ناکامی کے بعد، ایک ہی بیج اور ایک سے کم خرابی کی قسم کے ساتھ دوبارہ چلائیں. اس طرح کام کا بوجھ اور وقت کو دوبارہ پیدا کرنے میں مدد ملتی ہے جبکہ خرابی کی سطح کو تنگ کرتی ہے.

متعلقہ صفحات

• کارکردگی اور میٹرکس
• دوڑنا Iroha برے دھات پر
• Torii اختتام پوائنٹس