اختبار الفوضى مع 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 الالتزام، عدد الأقران، حساب الأقران الخاطئ، ملف تحميل العمل، الهدف 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 من مساحة العمل المتقدمة.
التحكم في الأخطاء
عندما يكون --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 - الصفوف تنمو لبقية السباق بعد إغلاق نافذة الفشل
- لا يتم تفسير المعاملات التي تم رفضها أو انتهت في الوقت المناسب عن طريق عبء العمل المختار
- إعادة تشغيل الأقران، مسح التخزين، أو استرداد فقدان الحزمة يتطلب تنظيف يدوي
بعد فشل، قم بإعادة تشغيل نفس البذور ونوع خطأ واحد أقل. هذا يبقي عبء العمل والتوقيت قابلاً للتكرار مع تقليص سطح الفشل.