הרבה זיכרון RAM פנוי, NVMe Intel P4500 והכל איטי במיוחד - הסיפור של הוספה לא מוצלחת של מחיצת החלפה

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

מבוא

אנו מפעילים ענן בגודל בינוני, אותו אנו בונים על שרתים טיפוסיים עם התצורה הבאה - 32 ליבות, 256 GB RAM וכונן 4500TB PCI-E Intel P4 NVMe. אנחנו מאוד אוהבים את התצורה הזו מכיוון שהיא מבטלת את הצורך לדאוג לתקורה של IO על ידי מתן ההגבלה הנכונה ברמת סוג המופע VM. בגלל NVMe Intel P4500 בעל ביצועים מרשימים, אנו יכולים לספק בו זמנית גם אספקת IOPS מלאה למכונות וגם אחסון גיבוי לשרת גיבוי עם אפס IOWAIT.

אנחנו מאותם מאמינים ותיקים שאינם משתמשים ב-SDN מקונברזציה ובשאר דברים מסוגננים, אופנתיים, לנוער כדי לאחסן נפחי VM, מתוך אמונה שככל שהמערכת פשוטה יותר, כך קל יותר לפתור אותה בתנאים של "הגורו הראשי נעלם להרים." כתוצאה מכך, אנו מאחסנים אמצעי אחסון VM בפורמט QCOW2 ב-XFS או EXT4, אשר נפרס על גבי LVM2.

אנו גם נאלצים להשתמש ב-QCOW2 על ידי המוצר בו אנו משתמשים לתזמור - Apache CloudStack.

כדי לבצע גיבוי, אנו מצלמים תמונה מלאה של עוצמת הקול כצילום מצב של LVM2 (כן, אנחנו יודעים שצילומי מצב של LVM2 איטיים, אבל ה-Intel P4500 עוזר לנו גם כאן). אנחנו עושים lvmcreate -s .. ועם dd אנו שולחים את עותק הגיבוי לשרת מרוחק עם אחסון ZFS. כאן אנחנו עדיין מעט מתקדמים - אחרי הכל, ZFS יכול לאחסן נתונים בצורה דחוסה, ואנחנו יכולים לשחזר אותם במהירות באמצעות DD או קבל אמצעי אחסון VM בודדים באמצעות mount -o loop ....

אתה יכול, כמובן, להסיר לא את התמונה המלאה של אמצעי האחסון LVM2, אלא לעלות את מערכת הקבצים ב- RO ולהעתיק את התמונות QCOW2 עצמן, עם זאת, עמדנו בפני העובדה ש-XFS הפך רע מזה, ולא מיד, אלא בצורה בלתי צפויה. אנחנו ממש לא אוהבים כשמארחי היפרוויזר "נדבקים" פתאום בסופי שבוע, בלילה או בחגים בגלל שגיאות שלא ברור מתי הן יקרו. לכן, עבור XFS אנחנו לא משתמשים בהרכבה של תמונת מצב RO כדי לחלץ אמצעי אחסון, אנו פשוט מעתיקים את כל אמצעי האחסון של LVM2.

מהירות הגיבוי לשרת הגיבוי נקבעת במקרה שלנו ע"י ביצועי שרת הגיבוי, שהם כ-600-800 מגה-בייט/שנייה לנתונים בלתי-דחוסים; מגביל נוסף הוא ערוץ ה-10Gbit/s איתו מחובר שרת הגיבוי לאשכול.

במקרה זה, עותקי גיבוי של 8 שרתי hypervisor מועלים בו זמנית לשרת גיבוי אחד. לפיכך, תת-מערכות הדיסק והרשת של שרת הגיבוי, בהיותן איטיות יותר, אינן מאפשרות לתתי-מערכות הדיסקים של מארח ה-Hypervisor להעמיס יתר על המידה, מכיוון שהן פשוט אינן מסוגלות לעבד, נניח, 8 GB/sec, שה-Hypervisor מארח בקלות. ליצר.

תהליך ההעתקה לעיל חשוב מאוד להמשך הסיפור, כולל הפרטים - שימוש בכונן Intel P4500 מהיר, שימוש ב-NFS וכנראה, שימוש ב-ZFS.

סיפור גיבוי

בכל צומת היפרוויזר יש לנו מחיצת SWAP קטנה בגודל 8 GB, ואנחנו "מגלגלים" את צומת ההיפרוויזר עצמו באמצעות DD מתמונת ההפניה. עבור נפח המערכת בשרתים, אנו משתמשים ב-2xSATA SSD RAID1 או 2xSAS HDD RAID1 בבקר חומרה של LSI או HP. באופן כללי, לא אכפת לנו בכלל מה יש בפנים, מכיוון שעוצמת הקול של המערכת שלנו פועלת במצב "כמעט לקריאה בלבד", למעט SWAP. ומכיוון שיש לנו הרבה זיכרון RAM בשרת והוא 30-40% פנוי, אנחנו לא חושבים על SWAP.

תהליך גיבוי. משימה זו נראית בערך כך:

#!/bin/bash

mkdir -p /mnt/backups/volumes

DIR=/mnt/images-snap
VOL=images/volume
DATE=$(date "+%d")
HOSTNAME=$(hostname)

lvcreate -s -n $VOL-snap -l100%FREE $VOL
ionice -c3 dd iflag=direct if=/dev/$VOL-snap bs=1M of=/mnt/backups/volumes/$HOSTNAME-$DATE.raw
lvremove -f $VOL-snap

שים לב ionice -c3, למעשה, הדבר הזה חסר תועלת לחלוטין עבור התקני NVMe, מכיוון שמתזמן ה-IO עבורם מוגדר כ:

cat /sys/block/nvme0n1/queue/scheduler
[none] 

עם זאת, יש לנו מספר צמתים מדור קודם עם SSD RAIDs קונבנציונליים, עבורם זה רלוונטי, אז הם זזים AS IS. בסך הכל, זו רק קטע קוד מעניין שמסביר את חוסר התוחלת ionice במקרה של תצורה כזו.

שימו לב לדגל iflag=direct עבור DD. אנו משתמשים ב-IO ישיר עוקף את מטמון המאגר כדי למנוע החלפה מיותרת של מאגרי IO בעת קריאה. למרות זאת, oflag=direct אנחנו לא עושים זאת מכיוון שנתקלנו בבעיות ביצועים של ZFS בעת השימוש בו.

אנו משתמשים בתוכנית זו בהצלחה במשך מספר שנים ללא בעיות.

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

Volume group "images" not found

התחלנו לחשוב על "הסוף הגיע ל-Intel P4500", אולם לפני כיבוי השרת כדי להחליף את הכונן, עדיין היה צורך לבצע גיבוי. תיקנו את LVM2 על ידי שחזור מטא נתונים מגיבוי LVM2:

vgcfgrestore images

השקנו גיבוי וראינו את ציור השמן הזה:

שוב היינו מאוד עצובים - היה ברור שאנחנו לא יכולים לחיות ככה, מכיוון שכל ה-VPSs יסבלו, מה שאומר שגם אנחנו נסבול. מה קרה לגמרי לא ברור - iostat הראה IOPS מעורר רחמים ואת ה-IOWAIT הגבוה ביותר. לא היו רעיונות מלבד "בואו נחליף את NVMe", אבל תובנה התרחשה בדיוק בזמן.

ניתוח המצב צעד אחר צעד

מגזין היסטורי. כמה ימים קודם לכן, בשרת זה היה צורך ליצור VPS גדול עם 128 GB RAM. נראה היה שיש מספיק זיכרון, אבל ליתר בטחון, הקצבנו עוד 32 גיגה-בייט למחיצת ההחלפה. ה-VPS נוצר, סיים את משימתו בהצלחה והתקרית נשכחה, ​​אך מחיצת ה-SWAP נשארה.

תכונות תצורה. עבור כל שרתי הענן הפרמטר vm.swappiness הוגדר כברירת מחדל 60. ו-SWAP נוצר על SAS HDD RAID1.

מה קרה (לפי העורכים). בעת גיבוי DD יצר הרבה נתוני כתיבה, שהונחו במאגרי RAM לפני הכתיבה ל-NFS. ליבת מערכת, מונחה על ידי מדיניות swappiness, העביר דפים רבים של זיכרון VPS לאזור ההחלפה, שהיה ממוקם על אמצעי אחסון איטי של HDD RAID1. זה הוביל לכך ש- IOWAIT צמח חזק מאוד, אבל לא בגלל IO NVMe, אלא בגלל IO HDD RAID1.

איך נפתרה הבעיה. מחיצת ההחלפה של 32GB הושבתה. זה לקח 16 שעות; אתה יכול לקרוא בנפרד איך ולמה SWAP נכבה כל כך לאט. ההגדרות שונו swappiness לערך השווה ל 5 בכל הענן.

איך זה לא יקרה?. ראשית, אם SWAP היה על מכשיר SSD RAID או NVMe, ושנית, אם לא היה מכשיר NVMe, אלא מכשיר איטי יותר שלא היה מייצר נפח כזה של נתונים – למרבה האירוניה, הבעיה קרתה בגלל שה-NVMe הזה מהיר מדי.

אחרי זה הכל התחיל לעבוד כמו קודם - עם אפס IOWAIT.

מקור: www.habr.com