שאלה LVM סכנות ואזהרות


לאחרונה התחלתי להשתמש ב- LVM בשרתים מסוימים עבור כוננים קשיחים גדולים מ -1 TB. הם שימושיים, ניתנים להרחבה וקל להתקנה. עם זאת, לא הצלחתי למצוא נתונים על הסכנות והאזהרות של LVM.

מה הם חסרונות השימוש LVM?


178
2018-06-12 07:34




בעת קריאת התשובות לשאלה זו, יש לזכור את התאריך (שנה). הרבה קורה ב 3 שנים בענף זה. - MattBianco
עשיתי כמה עדכונים לאחרונה (אפריל 2015) לאחר סרק כדי לראות אם משהו השתנה. הקרנל של 2.6 הוא עכשיו מיושן, SSD הם נפוצים יותר, אבל מלבד כמה תיקוני LVM קטן לא הרבה השתנה באמת. אני לא לכתוב כמה דברים חדשים על השימוש VM / ענן שרת תמונות במקום LVM תמונות. מצב של כתיבה במטמון, שינוי גודל מערכת הקבצים ותצלומי LVM לא השתנו הרבה עד כמה שאני יכול לראות. - RichVel
לגבי "דובי לזכור את התאריך" תגובה - נכון מספיק, אבל גם רואים כי הרבה "מפעלים" עדיין משתמש RHEL 5 ו RHEL 6, שניהם של המדינה- of-the-art או יותר מאשר התאריך של התשובה - JDS


תשובות:


סיכום

סיכוני שימוש ב- LVM:

  • פגיע לכתוב בעיות במטמון עם SSD או VM hypervisor
  • קשה יותר לשחזר נתונים בשל מבנים מורכבים יותר על הדיסק
  • קשה יותר לשנות את גודל מערכות הקבצים כהלכה
  • תצלומי בזק קשים לשימוש, איטיים וכרכרות
  • דורש מיומנות מסוימת כדי להגדיר כראוי בהתחשב בבעיות אלה

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

- עודכן ספטמבר 2017: עשה את החומר הקרנל הישן פחות בולט

מקלים על הסיכונים

LVM עדיין יכול לעבוד טוב אם:

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

פרטים

חקרתי את זה לא מעט בעבר נתקל כמה אובדן נתונים הקשורים LVM. הסיכונים העיקריים LVM ונושאים אני מודע הם:

פגיעות לדיסק קשיח של כתיבה בדיסק הקשיח בגלל וירוסים של VM, מטמון בדיסק או גרעיני לינוקס ישנים, ומקשה על שחזור נתונים בשל מבנים מורכבים יותר על הדיסק - ראה להלן פרטים. ראיתי מלא setups LVM על כמה דיסקים לקבל פגום ללא כל סיכוי של התאוששות, ו LVM בתוספת דיסק קשיח לכתוב במטמון הוא שילוב מסוכן.

  • כתוב במטמון וכתוב מחדש הזמנה על ידי הכונן הקשיח חשוב ביצועים טובים, אבל יכול להיכשל לשטוף בלוקים לדיסק כראוי בשל Hyperors VM, כונן קשיח לכתוב במטמון, גרעיני לינוקס ישנים, וכו '
    • לכתוב מחסומים כלומר את הקרנל ערבויות כי זה יהיה להשלים דיסק מסוים כותב לפני הדיסק "המכשול" לכתוב, כדי להבטיח כי מערכות קבצים RAID יכול להתאושש במקרה של אובדן כוח פתאומי או לקרוס. מחסומים כאלה יכולים להשתמש ב FUA (יחידת כוח גישה) פעולה כדי לכתוב מיד בלוקים מסוימים לדיסק, שהוא יעיל יותר מאשר סומק מלא המטמון. ניתן לשלב מחסומים ביעילות מתויג/יליד הפקודה הפקודה (הנפקת מספר דיסק I / O בקשות בבת אחת) כדי לאפשר את הכונן הקשיח לבצע אינטליגנטי לכתוב מחדש סדר מבלי להגדיל את הסיכון של אובדן נתונים.
  • VM hypervisors יכולות להיות בעיות דומות: הפעלת LVM באורח לינוקס על גבי Hypervisor VM כגון VMware, Xen, KVM, Hyper-V או VirtualBox יכול ליצור בעיות דומותלקרנל ללא מחסומים לכתוב, בשל לכתוב במטמון ולכתוב מחדש סדר. בדוק בקפידה את תיעוד ה- Hypervisor לקבלת אפשרות "שטוף לדיסק" או מטמון כתיבה (קיים ב KVM, VMware, Xen, VirtualBox ואחרים) - ולבדוק את זה עם ההתקנה שלך. כמה hypervisors כגון VirtualBox יש הגדרת ברירת מחדל מתעלמת מהדיסק מהאורח.
  • שרתי Enterprise עם LVM צריכים תמיד להשתמש סוללה מגובה RAID בקר - - ו להשבית את הדיסק הקשיח לכתוב במטמון (הבקר יש גיבוי המגן לכתוב מטמון שהוא מהיר ובטוח) - ראה תגובה זו על ידי המחבר של זה ערך XFS שאלות נפוצות. זה יכול להיות גם בטוח לבטל מחסומים לכתוב - - בקרנל, אך מומלץ לבדוק.
  • אם אין לך בקר RAID המגובה על ידי סוללה, השבתת המטמון של כתיבה בכונן הקשיח תאט את כתיבת ה- LVM באופן משמעותי, אך תיצור את LVM בטוח. אתה צריך גם להשתמש המקבילה של ext3 data=ordered אופציה (או data=journal עבור בטיחות נוספת), פלוס barrier=1 כדי להבטיח אחסון במטמון ליבה אינו משפיע על שלמות. (או להשתמש ext4 אשר מאפשר מחסומים כברירת מחדל.) זוהי האפשרות הפשוטה ביותר ומספקת שלמות נתונים טובה במחיר של ביצועים. (לינוקס שינית את אפשרות ברירת המחדל ext3 כדי מסוכנת יותר data=writeback זמן מה אחורה, לכן אל תסמוך על הגדרות ברירת המחדל עבור FS).
  • כדי להשבית את המטמון של כתיבה בכונן הקשיח: הוסף hdparm -q -W0 /dev/sdX עבור כל הכוננים /etc/rc.local (עבור SATA) או להשתמש sdparm עבור SCSI / SAS. עם זאת, על פי ערך זה ב- XFS FAQ (שהוא טוב מאוד בנושא זה), כונן SATA עשוי לשכוח הגדרה זו לאחר שחזור שגיאת כונן - כך שעליך להשתמש ב- SCSI / SAS, או אם עליך להשתמש ב- SATA ולאחר מכן, שים את הפקודה hdparm בתפקיד cron רץ כל דקה בערך.
  • כדי לשמור את המטמון של כתיבה מסוג SSD / כונן קשיח מופעל עבור ביצועים טובים יותר: זהו אזור מורכב - ראה סעיף להלן.
  • אם אתה משתמש כונני פורמט מתקדם כלומר 4 KB מגזרים פיזיים, ראה להלן - השבתת מטמון כתיבה יכול להיות בעיות אחרות.
  • יו פי אס הוא קריטי הן עבור הארגון והן עבור SOHO, אך לא מספיק כדי להפוך את LVM לבטוחה: כל דבר שגורם לקריסה קשה או להפסקות חשמל (כגון כשל ב- UPS, כשל ב- PSU או תשישות של סוללות למחשב נייד) עלול לאבד נתונים במטמון של כונן קשיח.
  • לינוקס ישנים מאוד (2.6.x מ 2009): יש להשלים תמיכה מחסום לכתוב גרסאות ליבה ישנות מאוד, 2.6.32 ו מוקדם יותר (2.6.31 יש תמיכה כלשהי, בזמן 2.6.33 עובד עבור כל סוגי היעד התקן) - RHEL 6 משתמשת 2.6.32 עם טלאים רבים. אם אלה גרסאות 2.6 הישן הם unpched עבור בעיות אלה, כמות גדולה של metadata FS (כולל כתבי עת) יכול ללכת לאיבוד על ידי התרסקות קשה משאיר נתונים במאגרים כתיבה של כוננים קשיחים (למשל 32 MB לכל כונן עבור כונני SATA נפוצים). איבוד 32MB של האחרונה שנכתבו FS metadata ונתוני היומן, אשר הקרנל חושב כבר על הדיסק, בדרך כלל אומר הרבה שחיתות FS ומכאן אובדן נתונים.
  • סיכום: אתה חייב לטפל במערכת הקבצים, RAID, VM hypervisor, ואת הכונן הקשיח / SSD ההתקנה בשימוש עם LVM. אתה חייב להיות גיבויים טובים מאוד אם אתה משתמש LVM, ולוודא במיוחד לגבות את metadata LVM, הגדרת מחיצה פיזית, MBR ומגזרים אתחול נפח. כמו כן, מומלץ להשתמש כונני SCSI / SAS כמו אלה נוטים פחות לשקר על איך הם עושים לכתוב במטמון - טיפול נוסף נדרש להשתמש כונני SATA.

שמירה על שמירה במטמון של כתיבה עבור ביצועים (והתמודדות עם כוננים שוכבים)

אפשרות מורכבת יותר אך ביצוע היא לשמור על SSD / כונן קשיח לכתוב במטמון מאופשר להסתמך על מחיצות לכתוב ליבה עובד עם LVM על הקרנל 2.6.33 + (בדיקה כפולה על ידי מחפש "המכשול" הודעות ביומנים).

כמו כן, עליך לוודא שתצורת RAID, הגדרת VM ו- Hypervisor משתמש מחסומי לכתוב (כלומר מחייב את הכונן לשטוף כתובים בכתב לפני ואחרי מטה metadata / כתב העת כותב). XFS עושה שימוש במחסומים כברירת מחדל, אבל ext3 לא, אז עם ext3 אתה צריך להשתמש barrier=1 אפשרויות הר, ועדיין להשתמש data=ordered או data=journal כאמור לעיל.

  • למרבה הצער, כמה כוננים קשיחים ו- SSD לשקר אם הם באמת סומק המטמון שלהם לדיסק (במיוחד כוננים ישנים יותר, אבל כולל כמה כונני SATA ו כמה ארגוניים SSD) - פרטים נוספים כאן. יש סיכום גדול ממפתח XFS.
  • יש כלי בדיקה פשוטה עבור כוננים שוכב - - (סקריפט Perl), או לראות זה רקע עם כלי אחר בדיקה עבור כתיבה מחדש של ההזמנה כתוצאה מטמון הכונן. תשובה זו ערכה בדיקות דומות של כונני SATA שחשפו בעיה במחסום לכתוב בתוכנה RAID - בדיקות אלה למעשה לממש את כל מחסנית אחסון.
  • כונני SATA חדשים יותר תומכים תורי פקודה מקורי (NCQ) עשוי להיות פחות סביר לשקר - או אולי הם מבצעים היטב מבלי לכתוב במטמון עקב NCQ, ומעט מאוד כוננים לא יכול להשבית כתיבה במטמון.
  • כונני SCSI / SAS הם בדרך כלל בסדר כי הם לא צריכים לכתוב במטמון כדי לבצע טוב (באמצעות SCSI מתויג שורת פקודה, בדומה ל NCQ של SATA).
  • אם כוננים קשיחים או כונני SSD עושים שקר על שטיפת המטמון שלהם לדיסק, אתה באמת לא יכול להסתמך על מחסומי לכתוב חייב לבטל כתיבה במטמון. זוהי בעיה עבור כל מערכות הקבצים, מסדי נתונים, מנהלי נפח, ו תוכנה, לא רק LVM.

SSD הם בעייתיים, כי השימוש במטמון כתיבה הוא קריטי לכל החיים של SSD. עדיף להשתמש SSD שיש לו supercapacitor (כדי לאפשר מטמון הסמקה על הפסקת חשמל, ולכן לאפשר מטמון להיות לכתוב בחזרה לא לכתוב דרך).

פורמט מתקדם הגדרת כונן - כתיבה במטמון, יישור, RAID, GPT

  • עם חדש יותר כונני פורמט מתקדם כי שימוש 4 מגזרים פיזיים KiB, זה עשוי להיות חשוב לשמור על כונן כתוב במטמון מופעלת, שכן רוב הכוננים האלה כיום לחקות 512 בתים מגזרים לוגיים ("512 אמולציה"), וחלקם אף טוענים שיש להם מגזרים פיזיים של 512 בתים, תוך שימוש באמת ב- 4 KiB.
  • כיבוי מטמון הכתיבה של כונן Advanced Format עלול לגרום להשפעת ביצועים גדולה מאוד אם היישום / הליבה עושה כתיבה של 512 בתים, שכן כוננים כאלה מסתמכים על המטמון כדי לצבור 8 x 512 בתים בכתב לפני ביצוע פיזי 4 KiB לכתוב. מומלץ לבדוק את ההשפעה אם תשבית את המטמון.
  • יישור LVs על גבול 4 KiB חשוב לביצועים אבל צריך לקרות באופן אוטומטי כל עוד המחיצות הבסיסית עבור PVs מיושרים, מאז LVM פיזית Extents (PE) הם 4 MiB כברירת מחדל. RAID חייב להיחשב כאן - זה LVM ותוכנה RAID מציע לשים את RAID superblock בסוף נפח ו (אם יש צורך) באמצעות אפשרות ב pvcreate כדי ליישר את PVS. זה רשימת דוא"ל LVM פתיל מציין את העבודה שנעשתה בגרעינים במהלך שנת 2011 ואת הבעיה של בלוק חלקי כותב בעת ערבוב דיסקים עם 512 בתים ו 4 מגזרים KiB ב LV אחד.
  • GPT מחיצות עם פורמט מתקדם צריך טיפול, במיוחד עבור אתחול + דיסקים שורש, כדי להבטיח את הראשון LVM מחיצה (PV) מתחיל על גבול 4 KiB.

קשה יותר לשחזר נתונים בשל מבנים מורכבים יותר על הדיסקYou

  • כל שחזור של נתוני LVM הנדרשים לאחר התרסקות קשה או אובדן חשמל (עקב אחסון מטמון שגוי) הוא תהליך ידני במקרה הטוב, מכיוון שאין כנראה כלים מתאימים. LVM טוב בגיבוי מטה מטה שלה /etc/lvm, אשר יכול לעזור לשחזר את המבנה הבסיסי של LVs, VGs ו PVS, אבל לא יעזור עם מטא נתונים לאיבוד קבצים.
  • לפיכך, סביר שיידרש שחזור מלא מהגיבוי. זה כולל זמן השבתה הרבה יותר מאשר fsck מבוסס יומן מהיר כאשר לא משתמש LVM, ונתונים שנכתב מאז הגיבוי האחרון יאבדו.
  • טסטדיסק, ext3grep, ext3undel ו כלים אחרים  יכול לשחזר מחיצות וקבצים שאינם דיסקים LVM אבל הם לא תמיכה ישירה שחזור נתונים LVM. TestDisk יכול לגלות כי מחיצה פיזית אבודה מכיל PVV LVM, אבל אף אחד מהכלים האלה לא מבינים LVM כרכים לוגיים. קובץ גילוף כלים כגון PhotoRec ורבים אחרים יעבדו כפי שהם לעקוף את מערכת הקבצים כדי להרכיב מחדש את הקבצים מ בלוקים נתונים, אבל זה האחרון, ברמה נמוכה גישה גישה לנתונים יקרי ערך, ופחות עובד טוב עם קבצים מקוטעת.
  • שחזור LVM ידני אפשרי במקרים מסוימים, אך הוא מורכב זמן רב - ראה בדוגמה זו ו זה, זה, ו זה איך להתאושש.

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

  • עדכון: גרסאות עדכניות יותר של lvextend תתמוך ב -r (--resizefs) אפשרות - אם זה זמין, זה בטוח ומהיר לשנות את גודל LV ואת מערכת הקבצים, במיוחד אם אתה מתכווץ FS, ואתה יכול בעיקר לדלג על סעיף זה.
  • רוב המדריכים כדי לשנות את גודל LVM מבוססי FS לא לוקחים בחשבון את העובדה כי FS חייב להיות קצת קטן יותר מאשר בגודל של LV: הסבר מפורט כאן. בעת צמצום מערכת קבצים, יהיה עליך לציין את הגודל החדש לכלי שינוי גודל FS, למשל. resize2fs עבור ext3, ו lvextend או lvreduce. ללא טיפול רב, הגדלים עשויים להיות מעט שונה בגלל ההבדל בין 1 GB (10 ^ 9) ו 1 GiB (2 ^ 30), או את האופן שבו הכלים השונים עגולים למעלה או למטה.
  • אם אתה לא עושה את החישובים בדיוק נכון (או להשתמש בכמה צעדים נוספים מעבר לאלה הברורים ביותר), אתה עלול בסופו של דבר עם FS כי הוא גדול מדי עבור LV. הכל ייראה בסדר במשך חודשים או שנים, עד שתמלא את ה- FS, ובנקודה זו תקבלו שחיתות רצינית - ואם אינך מודע לבעיה זו, קשה לדעת מדוע, כפי שעלול להיות לך שגיאות בדיסק אמיתיות עד אז כי ענן המצב. (ייתכן כי בעיה זו משפיעה רק על הקטנת גודל של מערכות קבצים - עם זאת, ברור כי שינוי גודל של מערכות קבצים בשני הכיוונים מעלה את הסיכון לאובדן נתונים, ככל הנראה עקב שגיאת משתמש).
  • נראה כי גודל LV צריך להיות גדול יותר מאשר גודל FS על ידי 2 x גודל LVM פיזי (PE) גודל - אבל לבדוק את הקישור לעיל לפרטים כמקור זה אינו סמכותי. לעתים קרובות אפשר 8 MiB מספיק, אבל זה יכול להיות טוב יותר לאפשר, למשל. 100 MiB או 1 GiB, רק כדי להיות בטוח. כדי לבדוק את גודל PE, ואת נפח הגיונית שלך גודל FS, באמצעות 4 KiB = 4096 בתים בתים:

    מראה גודל PE ב- KiB:
    vgdisplay --units k myVGname | grep "PE Size"

    גודל של כל LVs:
    lvs --units 4096b

    גודל (ext3) FS, מניחה 4 KiB FS blockize:
    tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

  • לעומת זאת, ההתקנה הלא LVM עושה שינוי גודל FS מאוד אמין וקל נמסר ולשנות את FSs נדרש, אז זה יעשה הכל בשבילך. בשרתים, באפשרותך להשתמש parted מן הקליפה.

    • זה בדרך כלל הכי טוב להשתמש תקליטור חי או קסם מופרד, כמו אלה יש לאחרונה הרבה יותר ללא באגים Gparted & Kernel מאשר גרסת distro - פעם איבדתי FS כולו בשל Gparted של Distro לא לעדכן מחיצות כראוי הקרנל פועל. אם אתה משתמש Gparted של distro, הקפד לאתחל מיד לאחר שינוי מחיצות כך להציג את הקרנל הוא הנכון.

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

צילומים יכול להיות גם איטי מאוד (כלומר 3 עד 6 פעמים לאט יותר מאשר LVM עבור אלה בדיקות) - ראה תשובה זו המכסה בעיות בזק שונות. האטיות היא חלקית בגלל תצלומים מחייבים כתיבת סינכרוני רבות.

בתצלומים יש כמה באגים משמעותיים, למשל במקרים מסוימים הם יכולים לעשות אתחול מאוד איטי, או לגרום לאתחול להיכשל לחלוטין (כי הקרנל יכול להיגמר  מחכה לשורש FS כאשר הוא תצלום LVM [קבוע ב- Debian initramfs-tools עדכון, מרץ 2015]).

  • מדד אחד הוא שיש הרבה באגים דביאן התאמה "lvm תמונת מצב 2015", כמה מהם רציני למדי - עם זאת, רבים תמונת מצב גזע באגים יש כנראה תוקנו. LVM ללא תמונות בדרך כלל נראה די טוב debugged, אולי בגלל תמונות לא משמשים כמו תכונות הליבה.

חלופות של תמונת מצב - מערכות קבצים ו- Hypervisors VM

תמונות VM / ענן:

  • אם אתה משתמש ב- Hypervisor של VM או בענן IaaS, התמונות שלהם (לדוגמה, VMware, VirtualBox או תמונות EBS של EBS) הן לעתים קרובות אלטרנטיבה טובה יותר לתצלומי LVM. אתה יכול בקלות לקחת תמונה עבור מטרות גיבוי (אבל שקול להקפיא את FS לפני שאתה עושה).

תמונות מערכת קבצים:

  • תמונות ברמת מערכת הקבצים עם ZFS או btrfs הן קלות לשימוש ובדרך כלל טובות יותר מ- LVM, ואף על פי שאף מערכת קבצים אינה בוגרת ב- Linux, הן עשויות להיות אופציה טובה יותר עבור אנשים שבאמת זקוקים לתמונות ללא צורך במסלול VM / ענן:

    • ZFS: יש עכשיו ליבה ליישום ZFS, אשר כבר בשימוש במשך כמה שנים צריך להיות הרבה יותר מהר מאשר ZFS על FUSE.
    • btrfs הוא לא ממש מוכן לשימוש הייצור, שלה fsck וכלים לתיקון עדיין בפיתוח.

צילומי מסך לגיבויים מקוונים ו- fsck

ניתן להשתמש בתצלומים כדי לספק עקביות מקור עבור גיבויים, כל עוד אתה זהיר עם שטח שהוקצה (באופן אידיאלי את התמונה היא באותו גודל כמו LV להיות מגובה). מעולה rsnapshot (מאז 1.3.1) אפילו מנהל את LVM יצירת תמונת מצב / מחיקה בשבילך - לראות את זה HOWTO על rsnapshot באמצעות LVM. עם זאת, שים לב לנושאים הכלליים עם תצלומי מסך, ותמונת מצב לא צריכה להיחשב כגיבוי בפני עצמה.

אתה יכול גם להשתמש LVM תמונות לעשות fsck מקוון: תצלום LV ו fsck את התמונה, תוך שימוש עדיין הלא תמונת מצב FS - המתואר כאן - עם זאת, זה לא לגמרי פשוט אז עדיף להשתמש e2croncheck כפי ש שתואר על ידי טד Ts'o, תחזוקה של ext3.

אתה צריך "להקפיא" את מערכת הקבצים באופן זמני בעת צילום התמונה - כמה מערכות קבצים כגון ext3 ו XFS יהיה לעשות זאת באופן אוטומטי כאשר LVM יוצר את התמונה.

מסקנות

למרות כל זאת, אני עדיין משתמש LVM על כמה מערכות, אבל עבור ההתקנה שולחן העבודה אני מעדיף מחיצות גלם. היתרון העיקרי שאני יכול לראות מ LVM היא הגמישות של העברת ושינוי FSs כאשר אתה חייב להיות uptime גבוהה בשרת - אם אתה לא צריך את זה, gparted קל יותר יש פחות סיכון של אובדן נתונים.

LVM דורש טיפול רב על הגדרת במטמון הגדרת עקב VM hypervisors, כונן קשיח / SSD לכתוב במטמון, וכן הלאה - אבל אותו הדבר חל על השימוש לינוקס כשרת DB. היעדר תמיכה של רוב הכלים (gparted לרבות חישובי הגודל הקריטיים ו testdisk וכו ') עושה את זה יותר קשה להשתמש מאשר זה צריך להיות.

אם אתה משתמש ב- LVM, קח תשומת לב רבה עם תמונות: השתמש בתמונות VM / ענן אם אפשר, או בדוק ZFS / btrfs כדי למנוע LVM לחלוטין - אתה עלול למצוא ZFS או btrs הוא מספיק בוגרת לעומת LVM עם תמונות.

שורה תחתונה: אם אתה לא יודע על הבעיות המפורטות לעיל וכיצד לטפל בהם, עדיף לא להשתמש LVM.


239
2018-06-12 08:19



שינוי גודל מקוון עם xfs עובד בצורה מושלמת, אתה אפילו לא צריך לציין את הגודל. זה יגדל לגודל של LV לקרוא יותר ב xfs_grow (5). OTOH אני מכה +1 לסיכום על מחסומי לכתוב. - cstamas
אחי! איפה היית כל החיים שלי!? - songei2f
@ TRREE: הרעיון עם בקר RAID המגובה על ידי סוללה הוא שהמטמון שלו מתמיד לאורך תקלות חשמל וניתן לבטוח בו באופן כללי כמתועד, בעוד שמספר מטמוני דיסק קשיח נמצאים בשאלה האם הם כתבו למעשה בלוק לדיסק, ושל כמובן המטמונים האלה לא מתמשך. אם אתה משאיר את מטמון הדיסק הקשיח מופעל, אתה חשוף לכשל חשמל פתאומי (לדוגמה, PSU או UPS נכשל), המוגן מפני גיבוי הסוללה של RAID. - RichVel
אחת התשובות הטובות ביותר שראיתי אי פעם, בכל נושא. רק לשנות הייתי עושה, להעביר סיכום למעלה של השאלה עבור אלה עם הפרעת קשב וריכוז או לא הרבה זמן. Youנות - Prof. Falken
כשראיתי את כל ההערות ואת העדכון האחרון לתשובה היה לפני שנה, תהיתי אם התשובה יכולה להתעדכן כדי לשקף כל השינויים החדשים אמינות, ביצועים וקלות השימוש. - Luis Alvarado


אני [+1] פוסט זה, ולפחות עבורי אני חושב שרוב הבעיות קיימות. ראיתי אותם בעת הפעלת כמה מאות שרתים וכמה נתונים של 100TB. לי LVM2 בלינוקס מרגיש כמו "רעיון חכם" מישהו היה. כמו כמה מהם, הם מתברר להיות "לא חכם" לפעמים. I.e אין צורך להפריד לחלוטין את הקרנל ואתמשתמשים (lvmtab) מדינות אולי הרגישו ממש חכם לעשות משם, כי לא יכול להיות בעיות שחיתות (אם אתה לא מקבל את הקוד הנכון)

ובכן, רק ההפרדה הזאת היתה שם מסיבה מסויימת - ההבדלים מראים עם טיפול באובדן PV, והפעולה מחדש באינטרנט של VG עם חסרים PV PV כדי להחזיר אותם למשחק - מה זה משב רוח על "LVMs המקורי" (AIX, HP-UX) הופך לחרא על LVM2 מאז טיפול המדינה אינו מספיק טוב. ואפילו אל תדברו על זיהוי אובדן רווחים (Haha) או על טיפול ממשלתי (אם אני מסיר דיסק, זה לא יסומן כבלתי זמין. יש עמודת הסטטוס הארור)

Re: יציבות pvmove... למה

אובדן נתונים

כגון מאמר הדף בדירוג על הבלוג שלי, המממ? רק עכשיו אני מסתכל על דיסק שבו נתונים phyiscal lvm עדיין תלוי על המדינה מ באמצע pvmove. היו כמה memleaks אני חושב, ואת הרעיון הכללי זה דבר טוב להעתיק סביב נתונים בלוק חי מ userspace הוא פשוט עצוב. ציטוט נחמד מרשימת lvm "נראה כמו vgreduce - Missing אינו מטפל pvmove" אמצעים למעשה אם הדיסק מנותק במהלך pvmove אז כלי ניהול lvm משתנה מ lvm כדי vi. אה ויש גם באג שבו pvmove ממשיך לאחר בלוק קריאה / כתיבה שגיאה עושה למעשה לא לכתוב נתונים למכשיר היעד. WTF?

Re: תמונות CoW נעשה בצורה לא בטוחה, על ידי עדכון הנתונים החדשים לתוך LV תמונת מצב ולאחר מכן מיזוג בחזרה לאחר למחוק את הצמד. זה אומר שיש לך קוצים IO כבד במהלך המיזוג הסופי של נתונים חדשים לתוך LV המקורי, וחשוב הרבה יותר, אתה כמובן גם יש הרבה יותר סיכון לשחיתות נתונים, כי לא את התמונה תהיה שבורה ברגע שאתה מכה את הקיר, אבל המקורי.

היתרון הוא בביצועים, עושה 1 כותב במקום 3. בחירת אלגוריתם מהיר אבל לא בטוח יותר הוא משהו אחד ברור מצפה מאנשים כמו VMware ו- MS, על "יוניקס" אני מעדיף לנחש דברים יהיה "לעשות נכון". לא ראיתי הרבה בעיות ביצועים כל עוד יש לי את החנות גיבוי גיבוי על שונה כונן הדיסק מאשר הנתונים העיקריים (וגם גיבוי אחד נוסף כמובן)

Re: מחסומים אני לא בטוח אם אפשר להאשים את זה על LVM. זה היה נושא devmapper, ככל שאני יודע. אבל יכול להיות קצת אשמה לא ממש אכפתיות בעיה זו מ לפחות 2.6 ליבה 2.6.33 AFAIK Xen הוא ההיפרוויזור היחיד המשתמש ב- O_DIRECT עבור המכונות הווירטואליות, כשהבעיה הייתה כאשר "לולאה" שימשה כי הקרנל עדיין היה מטמון באמצעות זה. Virtualbox לפחות יש כמה הגדרות כדי להשבית דברים כאלה ו Qemu / KVM בדרך כלל נראה לאפשר למטמון. כל FUSE FS גם נתקל בבעיות שם (לא O_DIRECT)

Re: גדלים אני חושב LVM עושה "עיגול" של הגודל המוצג. או שהוא משתמש ב- GiB. בכל מקרה, אתה צריך להשתמש VG גודל Pe ולהכפיל אותו על ידי מספר LE של LV. זה צריך לתת את גודל נטו הנכון, וכי הבעיה היא תמיד בעיה בשימוש. זה נעשה גרוע יותר על ידי מערכות קבצים שלא רואים דבר כזה במהלך fsck / mount (שלום, ext3) או אין לך עבודה באינטרנט "fsck-n" (שלום, ext3)

כמובן שזה אומר שאתה לא יכול למצוא מקורות טובים עבור מידע כזה. "כמה LE עבור VRA?" "מהו קיזוז phyiscal עבור PVRA, VGDA, ... וכו '

לעומת LVM2 המקורי הוא הדוגמה העיקרית של "אלה שאינם מבינים UNIX נידונים להמציא את זה מחדש, גרוע."

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

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


15
2017-12-11 14:03



נקודות טובות, במיוחד על אובדן נתונים pvmove (לא מבינים שזה יכול לקרוס תחת זיכרון נמוך) ואת עיצוב תמונת. על מחסומי לכתוב / במטמון: הייתי conflating LVM ואת mapper התקן הקרנל כמו מנקודת מבט המשתמש הם עובדים יחד כדי לספק מה LVM מספק. הצביע. גם אהב את הבלוג שלך פרסום על אובדן נתונים pvmove: deranfangvomende.wordpress.com/2009/12/28/... - RichVel
בתצלומים: הם איטיים לשמצה LVM, כך ברור שזה לא היה החלטה עיצוב טוב ללכת על הביצועים על אמינות. על ידי "מכה את הקיר", האם התכוונת התמונה מתמלא, וזה באמת יכול לגרום לשחיתות של נתונים LV המקורי? LVM HOWTO אומר כי התמונה הוא ירד במקרה זה: tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html - RichVel
"CoW נעשה בצורה לא בטוחה, על ידי עדכון הנתונים החדשים לתוך LV תמונת מצב ולאחר מכן מיזוג בחזרה לאחר למחוק את הצמד." זה פשוט שקר. כאשר נתונים חדשים נכתבים למכשיר המקורי, ישן הגרסה היא כתובה לתוך התמונות COW שטח. אין נתונים ממוזגים אי פעם בחזרה (למעט אם אתה רוצה). ראה kernel.org/doc/Documentation/device-mapper/snapshot.txt על כל הפרטים הטכניים. - Damien Tournoud
היי Damien, בפעם הבאה רק לקרוא על הנקודה שבה אני תיקנתי את ההודעה שלי? - Florian Heigl


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

אם אתה הולך להשתמש כונן 1TB, זוכר על יישור מחיצה - הכונן הזה כנראה יש 4kB מגזרים פיזיים.


12
2018-06-12 09:44



+ 1 עבור אזהרת ביצועים עבור תמונות פתוחות. - Prof. Falken
הניסיון שלי הוא כי כוננים 1TB בדרך כלל להשתמש במגזרים 512 בתים, אבל רוב הכוננים 2TB להשתמש 4Kb. - Dan Pritts
@ DanPritts אין שום נזק בהנחה כי גודל הסקטור הוא 4kB או אפילו 128kB - רק במקרה יש פשיטה בין לבין. אתה מאבד כל כך מעט - אולי 128kB ואתה יכול להרוויח הרבה. גם כאשר הדמיה מהדיסק הישן אחד חדש. - pQd
יש קצת נזק קטן כדי להפוך את גודל בלוק גודל הקובץ "גדול מדי"; כל קובץ נכלל לא פחות מאשר בלוק אחד. אם יש לך הרבה קבצים זעירים 128KB חוסם זה יוסיף. אני מסכים כי 4K הוא די הגיוני, ואם אתה מעביר את מערכת הקבצים חומרה חדשה, אתה בסופו של דבר עם 4k מגזרים בסופו של דבר. - Dan Pritts
(לא אתן לי לערוך את ההערה הקודמת שלי) ... בזבוז של שטח לא משנה, אבל זה יהיה בסופו של דבר להגדיל את הממוצע לחפש זמן על ספינינג דיסקים. זה עלול להפוך הגברה לכתוב (מילוי את המגזר עם nulls) על SSD. - Dan Pritts


אדם,

יתרון נוסף: ניתן להוסיף נפח פיזי חדש (PV), להעביר את כל הנתונים כי PV ולאחר מכן להסיר את PV הישן ללא כל הפרעות שירות. השתמשתי ביכולת הזאת לפחות ארבע פעמים בחמש השנים האחרונות.

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

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

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

בסך הכל, אני מעריץ של LVM2.


5
2018-06-22 21:03



לשמור /boot נפרד הוא תמיד רעיון טוב - Hubert Kario
GRUB2 תומך באתחול מתוך אמצעי אחסון לוגי LVM (ראה wiki.archlinux.org/index.php/GRUB2#LVM) אבל GRUB1 לא. אני תמיד להשתמש נפרד לא LVM / אתחול רק כדי להבטיח שזה קל להתאושש. רוב הדיסקים הצלה בימים אלה תומכים LVM - חלקם דורשים ידנית vgchange -ayכדי למצוא את כרכים LVM. - RichVel
ב pvmove: לראות את הנקודה על אובדן נתונים pvmove שנעשו התשובה של פלוריאן היגל. - RichVel