מהירות אחסון מתאימה ל- etcd? תשאל את פיו

סיפור קצר על פיו וכו'

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

  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]

הערות

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

סיפור ארוך על פיו וכו'

מה זה WAL ב- etcd

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

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

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

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

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

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

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

למה בדיוק פיו ואיך למדנו להגדיר את זה

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

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

השתמשנו לראשונה ב-strace כדי לחקור את שרת etcd עבור Kubernetes כאשר לא היה עומס על האשכול. ראינו שכמעט כל רשומות ה-WAL היו בערך באותו גודל: 2200–2400 בתים. לכן, בפקודה בתחילת הפוסט, ציינו את הפרמטר -bs=2300 (bs פירושו הגודל בבייטים עבור כל ערך fio). שימו לב שגודל הערך etcd תלוי בגרסת etcd, התפלגות, ערכי פרמטרים וכו', ומשפיע על משך ה-fdatasync. אם יש לך תרחיש דומה, בדוק את תהליכי ה-etcd שלך עם strace כדי לגלות את המספרים המדויקים.

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

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

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

נסה זאת בעצמך

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

מקור: www.habr.com