בדיקת כאוס עם Izanami

Izanami הוא ארכיסטרטור הרדמה במרחב העבודה Iroha העליון. הוא מתחיל קלאסטר מקומי חד פעמי Iroha, שולח עומס עבודה מותאם ומכניס פגמים לעמיתים נבחרים כדי שהפעילים יוכלו לבדוק אם הרשת ממשיכה להתקדם תחת כישלון מנוהל.

השתמש ביזאנאמי עבור בדיקות עמידות לפני ההפקה, פירוש הגדרה והצליחת הסכמה. אל תכוון אותו לרשת הייצור: הכלים נועדו להחזיק את הדוגמאות שהוא מתחיל, כולל התחלות מחדש של דוגמאות, כביסות אחסון, אובדן חבילות מלאכותי ולחץ דיסק או CPU מקומי.

תנאים מוקדמים

להפעיל Izanami מאחסון המקור Iroha , ולא מאחסון המסמכים זה:

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

יש לאפשר באופן מפורש ל-binary ליצור ולפעול על עמיתי רשת. לעבור --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 כדי לשמור על תקופה של מצב יציב נשלטת לפני ואחרי הפסד הנגרם. זה מקל להבחין בין רעש התחלה לתופעת הפסד.

צורות תרחיש

קטלוג אזינמי העליון מפה צורות נפוצות של כישלון תקשורת ב-blockchain לפרופילים CLI.

תסריט	צורה טיפוסית
עומס ממוקד	--faulty 0, גבוה --tps, מועמד אחד, גבוה --max-inflight
כישלון זמני	תפעיל כשל/תחל מחדש רק בתוך חלון פגם מוגבל
אובדן חבילה	אפשר רק אובדן חבילה, בדרך כלל עם שיעור הפסד של 75%
עצירה והתאוששות	השתמשו באוכלוסייה גדולה של עמיתים חוטפים עם קריסה / התחלה מחדש
בידוד מנהיג	השתמשו בדיוק ב- peer אחד שגוי עם רק שגיאות בחלקת רשת או אובדן פקטים; 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 על מתכת עירומה
• נקודות קצה Torii