כיצד לבדוק דיסקים עם fio לביצועים מספקים עבור etcd

הערה. תרגום: מאמר זה הוא תוצאה של מחקר מיני שבוצע על ידי מהנדסי IBM Cloud בחיפוש אחר פתרון לבעיה אמיתית הקשורה לתפעול של מסד הנתונים etcd. משימה דומה הייתה רלוונטית עבורנו, אולם מהלך ההרהורים והפעולות של המחברים עשוי להיות מעניין בהקשר רחב יותר.

סיכום קצר של המאמר כולו: fio וכו'

הביצועים של אשכול etcd תלויים מאוד במהירות האחסון הבסיסי. etcd מייצאת מדדי Prometheus שונים כדי לנטר את הביצועים. אחד מהם הוא wal_fsync_duration_seconds. בתיעוד עבור וכו' זה אומרשאחסון יכול להיחשב מהיר מספיק אם האחוזון ה-99 של מדד זה אינו עולה על 10 אלפיות השנייה...

אם אתה שוקל להגדיר אשכול etcd במכונות לינוקס וברצונך לבדוק אם כוננים (כגון SSD) מהירים מספיק, אנו ממליצים להשתמש בבודק ה-I/O הפופולרי הנקרא פיו. זה מספיק כדי להפעיל את הפקודה הבאה (ספרייה test-data חייב להיות ממוקם במחיצה המותקנת של הכונן הנבדק):

fio --rw=write --ioengine=sync --fdatasync=1 --directory=test-data --size=22m --bs=2300 --name=mytest

נותר רק להסתכל על הפלט ולבדוק אם האחוזון ה-99 מתאים fdatasync תוך 10 אלפיות השנייה אם כן, הכונן שלך עובד מהר מספיק. הנה פלט לדוגמה:

fsync/fdatasync/sync_file_range:
  sync (usec): min=534, max=15766, avg=1273.08, stdev=1084.70
  sync percentiles (usec):
   | 1.00th=[ 553], 5.00th=[ 578], 10.00th=[ 594], 20.00th=[ 627],
   | 30.00th=[ 709], 40.00th=[ 750], 50.00th=[ 783], 60.00th=[ 1549],
   | 70.00th=[ 1729], 80.00th=[ 1991], 90.00th=[ 2180], 95.00th=[ 2278],
   | 99.00th=[ 2376], 99.50th=[ 9634], 99.90th=[15795], 99.95th=[15795],
   | 99.99th=[15795]

כמה הערות:

1. בדוגמה לעיל, התאמנו את הפרמטרים --size и --bs למקרה ספציפי. כדי לקבל תוצאה משמעותית fio, ציין ערכים המתאימים למקרה השימוש שלך. כיצד לבחור אותם יידונו להלן.
2. במהלך הבדיקה בלבד fio טוען את תת-מערכת הדיסק. בחיים האמיתיים, סביר להניח שתהליכים אחרים יכתבו לדיסק (מלבד אלו הקשורים ל wal_fsync_duration_seconds). עומס נוסף זה יכול לגדול wal_fsync_duration_seconds. במילים אחרות, אם האחוזון ה-99 מבדיקה עם fio, רק מעט פחות מ-10 אלפיות השנייה, יש סיכוי טוב שביצועי האחסון אינם מספיקים.
3. עבור הבדיקה תצטרך את הגרסה fio לא נמוך מ 3.5כי גרסאות ישנות יותר אינן צוברות תוצאות fdatasync בצורה של אחוזונים.
4. המסקנה לעיל היא רק קטע קטן מהמסקנה הכללית fio.

עוד על fio ו- etcd

כמה מילים על WALs וכו'

בדרך כלל, מסדי נתונים משתמשים רישום יזום (רישום כתיבה קדימה, WAL). וכו' מושפע גם כן. דיון ב-WAL הוא מעבר להיקף של מאמר זה, אך למטרותינו, מה שאתה צריך לדעת הוא שכל חבר באשכול etcd מאחסן את WAL באחסון מתמשך. etcd כותב כמה פעולות אחסון של ערך מפתח (כגון עדכונים) ל-WAL לפני ביצוען. אם צומת קורס ומופעל מחדש בין תצלומי מצב, וכו' יכול לשחזר עסקאות מאז תמונת המצב הקודמת בהתבסס על תוכן ה-WAL.

לפיכך, בכל פעם שלקוח מוסיף מפתח למאגר ה-KV או מעדכן את הערך של מפתח קיים, וכו' מוסיף את תיאור הפעולה ל-WAL, שהוא קובץ רגיל ב-persistent store. etcd חייב להיות בטוח ב-100% שערך ה-WAL אכן נשמר לפני שתמשיך. כדי להשיג זאת בלינוקס, זה לא מספיק להשתמש בקריאת המערכת write, שכן פעולת הכתיבה עצמה למדיה הפיזית עלולה להתעכב. לדוגמה, לינוקס עשויה לשמור ערך WAL במטמון ליבה בזיכרון (למשל, במטמון הדף) למשך זמן מה. כדי לוודא שהנתונים נכתבים למדיה, יש להפעיל קריאת מערכת לאחר הכתיבה fdatasync - זה בדיוק מה ש-etcd עושה (כפי שניתן לראות בפלט הבא strace; כאן 8 - מתאר קובץ WAL):

21:23:09.894875 lseek(8, 0, SEEK_CUR)   = 12808 <0.000012>
21:23:09.894911 write(8, ".20210220361223255266632$1020103026"34"rn3fo"..., 2296) = 2296 <0.000130>
21:23:09.895041 fdatasync(8)            = 0 <0.008314>

לרוע המזל, כתיבה לאחסון מתמשך לוקחת זמן מה. ביצוע ממושך של קריאות fdatasync יכול להשפיע על הביצועים של etcd. בתיעוד המאגר צויןשעבור ביצועים מספקים יש צורך באחוזון 99 של משך כל השיחות fdatasync כאשר הכתיבה לקובץ WAL הייתה פחות מ-10 אלפיות השנייה. ישנם מדדים אחרים הקשורים לאחסון, אך מאמר זה יתמקד בזה.

הערכת אחסון עם fio

אתה יכול להעריך אם אחסון מסוים מתאים לשימוש עם etcd באמצעות כלי השירות פיו - בודק I/O פופולרי. זכור ש-I/O לדיסק יכול להתרחש בדרכים רבות ושונות: סנכרון/אסינכרון, מחלקות syscall רבות ושונות וכן הלאה. הצד השני של המטבע הוא זה fio קשה ביותר לשימוש. לכלי השירות יש פרמטרים רבים, ושילובים שונים של הערכים שלהם מובילים לתוצאות שונות לחלוטין. כדי לקבל הערכה סבירה עבור etcd, עליך לוודא שעומס הכתיבה שנוצר על ידי fio קרוב ככל האפשר לעומס הכתיבה של קובץ WAL של etcd:

• זה אומר שהנוצר fio הטעינה צריכה להיות לפחות סדרה של כתיבה רצופה לקובץ, כאשר כל פעולת כתיבה מורכבת מקריאה למערכת writeבא אחריו fdatasync.
• כדי לאפשר כתיבה רציפה, עליך לציין את הדגל --rw=write.
• כי fio כתב באמצעות שיחות write (במקום קריאות מערכת אחרות - למשל, pwrite), השתמש בדגל --ioengine=sync.
• סוף סוף הדגל --fdatasync=1 מבטיח שכל write חייב להיות fdatasync.
• שני הפרמטרים האחרים בדוגמה שלנו הם: --size и --bs - עשוי להשתנות בהתאם למקרה השימוש הספציפי. הסעיף הבא יתאר את התצורה שלהם.

למה בחרנו ב-fio ואיך למדנו איך להגדיר את זה

הערה זו מגיעה ממקרה אמיתי שנתקלנו בו. היה לנו אשכול על Kubernetes v1.13 עם ניטור על Prometheus. כונני SSD שימשו כאחסון עבור etcd v3.2.24. מדדי Etcd הראו זמן אחזור גבוה מדי fdatasync, גם כשהאשכול היה בטל. לנו, המדדים האלה נראו מפוקפקים מאוד, ולא היינו בטוחים מה בדיוק הם מייצגים. בנוסף, האשכול כלל מכונות וירטואליות, כך שלא ניתן היה לומר אם העיכוב נובע מווירטואליזציה או שה-SSD אשם.

בנוסף, שקלנו שינויים שונים בתצורת החומרה והתוכנה, ולכן היינו צריכים דרך להעריך אותם. כמובן שניתן יהיה להריץ etcd בכל תצורה ולהסתכל על מדדי Prometheus התואמים, אבל זה ידרוש מאמץ משמעותי. מה שהיינו צריכים היה דרך פשוטה להעריך תצורה ספציפית. רצינו לבדוק את ההבנה שלנו לגבי מדדי Prometheus המגיעים מ-etcd.

זה דרש פתרון של שתי בעיות:

• ראשית, איך נראה עומס הקלט/פלט שנוצר על ידי etcd בעת כתיבה לקבצי WAL? באילו שיחות מערכת משתמשים? מה הגודל של בלוקי הרשומות?
• שנית, נניח שיש לנו תשובות לשאלות לעיל. כיצד לשחזר את העומס המתאים עם fio? אחרי הכל fio - שירות גמיש במיוחד עם שפע של פרמטרים (קל לאמת זאת, למשל, כאן - משוער. תרגום).

פתרנו את שתי הבעיות באותה גישה מבוססת פקודות lsof и strace:

• עם lsof אתה יכול להציג את כל מתארי הקבצים שבהם נעשה שימוש בתהליך, כמו גם את הקבצים שהם מתייחסים אליהם.
• עם strace אתה יכול לנתח תהליך שכבר פועל או להפעיל תהליך ולצפות בו. הפקודה מציגה את כל קריאות המערכת שנעשות בתהליך זה ובמידת הצורך, את צאצאיה. זה האחרון חשוב לתהליכים שמתפצלים, וכו' הוא תהליך כזה.

הדבר הראשון שעשינו היה להשתמש strace לבחון את שרת ה-etcd באשכול Kubernetes בזמן שהוא לא פעיל.

לפיכך, התגלה כי בלוקי הכתיבה ב-WAL מקובצים בצפיפות רבה, רובם בטווח של 2200-2400 בתים. זו הסיבה שהפקודה בתחילת מאמר זה משתמשת בדגל --bs=2300 (bs הוא הגודל בבייטים של כל בלוק כתיבה ב fio).

שים לב שהגודל של בלוקים לכתיבה etcd עשוי להשתנות בהתאם לגרסה, הפריסה, ערכי הפרמטרים וכו'. - זה משפיע על משך הזמן fdatasync. אם יש לך מקרה שימוש דומה, נתח עם strace תהליכי etcd שלך כדי לקבל ערכים עדכניים.

לאחר מכן, על מנת לקבל מושג ברור ומקיף כיצד etcd עובד עם מערכת הקבצים, התחלנו את זה מלמטה strace עם דגלים -ffttT. זה איפשר ללכוד תהליכי ילד ולכתוב את הפלט של כל אחד מהם לקובץ נפרד. בנוסף, התקבל מידע מפורט על שעת ההתחלה ומשך כל שיחת מערכת.

השתמשנו גם בפקודה lsofכדי לאשר את הבנתך את הפלט strace במונחים של איזה מתאר קובץ שימש לאיזו מטרה. קיבלתי את המסקנה strace, בדומה לזה שלמעלה. מניפולציות סטטיסטיות עם זמני סנכרון אישרו כי המדד wal_fsync_duration_seconds מ-etcd מתאים שיחות fdatasync עם מתארי קובץ WAL.

ליצור עם fio עומס עבודה דומה לזה של etcd, התיעוד של כלי השירות נבדק ונבחרו הפרמטרים המתאימים למשימה שלנו. אימתנו ששיחות המערכת הנכונות מתבצעות ואישרנו את משך הזמן שלהן בהפעלה fio של strace (כפי שנעשה במקרה של וכו').

תשומת לב מיוחדת ניתנה לקביעת ערך הפרמטר --size. הוא מייצג את עומס ה-I/O הכולל שנוצר על ידי כלי השירות fio. במקרה שלנו, זהו המספר הכולל של בתים שנכתבו לתקשורת. זה עומד ביחס ישר למספר השיחות write (ו fdatasync). עבור מסוים bs מספר שיחות fdatasync שווה size / bs.

מכיוון שהתעניינו באחוזון, רצינו שמספר המדגמים יהיה גדול מספיק כדי להיות מובהק סטטיסטית. והחליט את זה 10^4 (שמתאים לגודל של 22 מגה-בייט) יספיק. ערכי פרמטרים קטנים יותר --size הפיק רעש בולט יותר (לדוגמה, שיחות fdatasync, אשר לוקח הרבה יותר זמן מהרגיל ומשפיע על האחוזון ה-99).

זה תלוי בך

המאמר מראה כיצד להשתמש fio אפשר לשפוט אם המדיה המיועדת לשימוש עם etcd היא מהירה מספיק. עכשיו זה תלוי בך! אתה יכול לחקור מכונות וירטואליות עם אחסון מבוסס SSD בשירות IBM Cloud.

נ.ב מהמתרגם

עם מקרי שימוש מוכנים fio למשימות אחרות, ראה תיעוד או ישירות ל מאגרי פרויקטים (יש הרבה יותר מהם ממה שהוזכר בתיעוד).

PPS מהמתרגם

קרא גם בבלוג שלנו:

• «etcd 3.4.3: מחקר אמינות ואבטחה באחסון";
• «הניסיון שלנו עם נתונים באשכול Kubernetes etcd ישירות (ללא K8s API)";
• «6 באגי מערכת משעשעים בתפעול של Kubernetes [והפתרון שלהם]".

מקור: www.habr.com