Logical volume management

Logical volume management או בקיצור LVM (המונח ניהול נפח אחסון שהוא התרגום לעברית איננו בשימוש) הוא שכבת הפשטה בין כוננים קשיחים (או התקני אחסון אחרים) ומערכות קבצים, צורה זו מחליפה (לפחות חלקית) את מערכת ניהול המחיצות הסטטית הישנה יותר. מנהל האחסון יכול לשרשר מחיצות, לפרוס את הנתונים על כמה מחיצות או לשלב בדרך אחרת את המחיצות לתוך נפח אחסון וירטואלי גדול שניתן לשנות את גודלו או להעבירו, לעיתים (בתלות במערכת ההפעלה וב־LVM עצמו) גם כאשר נמצא בשימוש.
השם של הרכיב נקבע על פי השם של רכיב זה ב־HP-UX והוא מעט מטעה כי LVM מורכב משני מרכיבים עיקריים: רמה ניהולית (מנהל) עם ממשק תווי או גרפי, ורכיב בליבת מערכת ההפעלה אשר מכיל את ניהול האחסון בפועל.
LVM מהווה את אחת מהצורות רבות של וירטואליזצית אחסון והוא מיושם כשכבה במחסנית הדרייברים במערכת ההפעלה.
בעיקרון אין צורך לשמור תמונה מדויקת של המיפוי מה־PV ל־LV, משום שהפיזור של ה־PV-ים בתוך VG מתבצע באופן אוטומטי על ידי ה־LVM. אולם על מנת לייעל את התנועה של ראשי הכתיבה/קריאה ולקבל ביצועים טובים יותר ביישומים קריטיים ניתן להבטיח שקריאות או כתיבות לדיסק המתרחשות בו זמנית יבוצעו על דיסקים פיזיים שונים. יתר על כן, נהוג בפועל לשלוט על תפוצת הנתונים הפיזית כך ש־LV יהיה מפוזר על פני מספר דיסקים פיזיים ולפיכך ההשפעה של כשל בדיסק תהא מוגבלת. למטרות אלו ה־LVM צריך לתמוך בבדיקה של התפלגות הנתונים על התקן האחסון הפיזי ולתת אפשרות לשנותה.

יתרונות וחסרונות

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

ארכיטקטורה

רוב מימושי מנהלי אחסון משתמשים באותו העיצוב הבסיסי. העיצוב מתחיל מדיסקים פיזיים (PV-ים), אשר יכולים להיות דיסקים קשיחים, מחיצות בדיסק הקשיח, או LUN-ים שבהתקן אחסון חיצוני (לרוב ב־SAN). ההתייחסות ל־PV-ים היא כאל רצפים של גושים המכונים מקטעים פיזיים (physical extents - PEs). בכמה מנהלי אחסון (כגון אלו של HP-UX ולינוקס) כל ה־PE-ים חייבים להיות בגודל אחיד; באחרים (כגון VxVM) גודלם יכול להשתנות וניתן אף לפצלם ולמזגם.
בדרך כלל, PE-ים פשוט ממופים, אחד אל אחד, אל מקטעים לוגיים (Logical extents - LEs). כאשר מופעל שיקוף, PE-ים מרובים ממופים אל כל LE.‏ PE-ים אלו יוצרים VG פיזי (physical volume group - PVG) שהוא קבוצה של PV-ים באותו גודל שפועלת בדומה לדיסקים קשיחים במערך RAID1‏. PVG-ים בדרך כלל מוגדרים כך שהם נשמרים על דיסקים שונים (ולעיתים אף על מערכי SAN שונים) או על אפיקי נתונים שונים עבור יתירות מקסימלית.
קבוצה של LE-ים מרכיבה VG ‏(volume group). דיסקים לוגיים או LV-ים (Logical volumes) נוצרים על ידי מחיצות דיסק וירטואלי המכילות שרשור של ה־LE-ים. ה־LV-ים משמשים כהתקני בלוקים בסיסיים, כמו מחיצות בדיסק והשימושים בהם זהים - כבסיס למערכות קבצים שניתן לבצע לה mount, כקובץ החלפה או ישירות (למשל על ידי מסדי נתונים).
כאשר ה־LV-ים פרוסים על מספר דיסקים, כל אחד מסדרה של LE-ים רצופים מוקצה מ־PV אחר; מצב זה יכול לשפר את הביצועים בקריאה רצופה ארוכה, וזאת בתלות בגודל של ה־LE, בשל שילוב תפוקת הקריאה של PV-ים מרובים.
אפשר להגדיל או לכווץ LV-ים באמצעות שרשור LE-ים או להקטין אותם על ידי החזרת LE-ים למאגר הלא מנוצל. ה־LE-ים בשרשור לא חייבים להיות רציפים, מה שמאפשר ל־LV-ים לגדול מבלי צורך להעביר את המידע על מה שכבר הוקצה. כמה מנהלי אחסון מאפשרים ל־LV-ים לשנות את גודלו בזמן השימוש. שינוי גודל כזה משנה את גודל השטח המכיל אותו ולא בהכרח משנה את גודל מערכת הקבצים שעליו. במקרה כזה מומלץ להשתמש במערכת קבצים שניתן לשנות את גודלה על מנת להתאים את מערכת האחסון שלה בזמן הפעילות מבלי להפריע ליישומים.
לא ניתן לשתף או לחלק PV-ים ו־LV-ים בין VG-ים שונים (אף על פי שכמה מנהלים עשויים לאפשר העברה שלהם בין VG-ים שונים על אותו מחשב). מצב זה מאפשר להעבירם למצב פעיל או לא פעיל ולהעביר VG-ים בין מחשבים, כיחידה ניהולית אחת. תכונות אלו מנוצלות לעיתים קרובות על ידי אשכולות שבדרך כלל משתפים VG-ים שלמים שבהתאם להגדרות האשכול עשויים להיות פעילים או לא פעילים.
ניתן להגדיל VG-ים על ידי קליטת PV-ים חדשים או לכווצם באמצעות הורדת PV-ים, שינוי כזה עשוי להיות כרוך בהזזת LE-ים שכבר הוקצו בתוך PV. רוב המנהלים יכולים לבצע תהליך זה בזמן הפעילות כך שמתאפשר, ללא השבתה של המערכת (אם החומרה הבסיסית תומכת בהחלפה חמה), לשדרג או להחליף את התקני האחסון, לעיתים יכולת זו מתאפשרת גם תוך כדי שימוש בקבצים המוזזים עצמם.

RAID ו־LVM

מנהלי LVM רבים תומכים בארגון של LV-ים כמערכת RAID, כך שניתן להגן על נתונים מפני כשלים בדיסק או להאיץ את הגישה אליהם. באופן כללי, מערכת ההפעלה מיישמת פונקציות ניהול נפוצות, אשר במידה רבה בלתי תלויות בכל מנהל אחסון או בתוכנת ה־RAID (תוכנה המממשת את ה־RAID בלי חומרה נוספת). בתלות במערכת ההפעלה נתמכים בדרך כלל RAID 0 (ללא הגנה מפני כשל בדיסק) ו־RAID1 (שיקוף מידע) ובחלק מהמימושים נתמך גם RAID5 (יתירות באמצעות שמירת זוגיות), תכונה הדורשת משאבי מחשוב משמעותיים. בכמה מערכות (לדוגמה HP-UX ולינוקס), תוכנת ה־RAID ותמיכת ה־LVM ב־RAID הן הרחבות אופציונליות המותקנות וניתנות לשימוש ללא תלות זו בזו (למשל ה־LVM דרוש גם ל־RAID בחומרה). חלק מהיצרנים דורשים רישיון מיוחד, שניתן בדרך כלל עבור RAID1 ו־RAID5 בנפרד. גישה שונה לעניין זה היא השילוב של ZFS ב־Solaris שבה יש שילוב הדוק בין ה־LVM ובין תוכנת ה־RAID.
לעיתים תכופות העבודה והתפקוד של ה־LVM ושל תוכנת RAID מעורבבים זה בזה אולם יש תיחום ברור. תוכנות ה־RAID תמיד מספקות יתירות RAID, ומשום כך תמיד יש מנוע נוסף של ה־RAID היוצר זרמי נתונים נוספים עבור היתירות הדרושה. האלגוריתמים הנפוצים ביותר הממומשים על ידי תוכנה זו הם RAID1,‏ RAID5 המיישמים שיקוף נתונים וחישוב זוגיות על ידי XOR בהתאמה. תפוקת הנתונים של מנוע ה־RAID היא גורם חשוב בביצועים מכיוון שתוכנת ה־RAID מייצרת נתונים נוספים.
המשימה של ה־LVM היא מיפוי לוגי של אמצעי אחסון פיזי והשימוש הנפוץ ביותר ב־LVM הוא מיפוי המחיצות למערכות קבצים. ה־LVM לא מייצר זרמי נתונים נוספים, אין לו מנוע ולכן הוא גם לא מציע יתירות ומשום כך יש צורך רק בחישוב מועט. לפיכך, הוא כמעט לא משפיע על הביצועים (אף על פי שיש מערכות LVM שRAID משולב 0 בהן כהרחבה). המשימה של מנהלי LVM היא באופן בסיסי להפיץ את זרמי הנתונים של מערכות הקבצים לדיסקים הפיזיים הקשורים אליה (בדומה לפעולת יחידת ניהול זיכרון). וזאת בניגוד למערכת RAID המפיצה אמנם גם את זרמי הנתונים המקוריים, אך גם מייצרת זרמי נתונים נוספים.

תמונות מידע

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

רפליקציות

חלק מהמנהלים מסוגלים לבצע גם רפליקציות, מה שמאפשר גיבוי של הנתונים באופן קבוע. למשל ZFS תומך ברפליקציה סינכרונית מקומית, עבור VxVM קיים Veritas Volume Replicator המאפשר הן רפליקציות סינכרוניות והן א-סינכרוניות ואילו Sun StorEdge Availability Suite פועל אמנם ברמת ה־LVM אך הוא תלוי גם בתמיכה של מערכת ה־SAN.
ביצוע שיקוף בין דיסקים מרוחקים שקול למעשה לרפליקציה סינכרונית ברמת הדיסקים הפיזיים שמתבצע על ידי ה־LVM ובמקרה של תמיכה של שימוש בו זמני בכמה רמות RAID (למשל RAID1 על RAID5), אפשר לקבל תוצאה שקולה לרפליקציה סינכרונית רגילה (VxVM אף תומך בחלוקה ל־Plex-ים המקלה על הניהול על מבנה כזה).