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

השם של הרכיב נקבע על פי השם של רכיב זה ב־HP-UX והוא מעט מטעה כי LVM מורכב משני מרכיבים עיקריים: רמה ניהולית (מנהל) עם ממשק תווי או גרפי, ורכיב בליבת מערכת ההפעלה אשר מכיל את ניהול האחסון בפועל.

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

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

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

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

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

ארכיטקטורה
----------

LVM1 בלינוקס
רוב מימושי מנהלי אחסון משתמשים באותו העיצוב הבסיסי. העיצוב מתחיל מדיסקים פיזיים (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-ים המקלה על הניהול על מבנה כזה).

LVM-ים נפוצים
-------------

| החברה | הוצג לראשונה ב | שם המנהל | הקצאה בכל מקום | תמונות מידע | RAID0 | RAID1 | RAID5 | שיקוף עם פריסה |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| IBM | AIX 3.0 ‏(1989) | Logical Volume Manager | כן | לא | כן | כן | לא | כן |
| Hewlett-Packard | HP-UX 9.0 | HP Logical Volume Manager | כן | כן | כן | כן | לא | כן |
|  | FreeBSD | Vinum Volume Manager | כן | לא | כן | כן | כן |  |
|  | לינוקס 2.2 | Logical Volume Manager | כן | כן | כן | כן | לא |  |
|  | לינוקס 2.4 | Enterprise Volume Management System | כן | כן | כן | כן | כן |  |
| סיליקון גרפיקס | Irix או לינוקס | XVM Volume Manager | כן | כן | כן | כן | כן |  |
| Sun Microsystems | SunOS | Solaris Volume Manager (נקרא בעבר Solstice DiskSuite) | לא | לא | כן | כן | כן | כן |
| Sun Microsystems | Solaris 10 | ZFS | כן | כן | כן | כן | כן | כן |
| Veritas | מרובות | Veritas Volume Manager ‏(VxVM) | כן | כן | כן | כן | כן | כן |
| מיקרוסופט | Windows 2000 ומערכות מבוססות NT מאוחרות יותר | Logical Disk Manager | כן | כן | כן | כן | כן |

AIX, HP-UX, Tru64תמיכה ב־LVM עם אפשרות להגדיל LV-ים מקוונים ולהפעיל שיקוף עליהם. עם רישיון נוסף HP-UX תומך ב־MirrorDisk UX ו־OnlineJFS ואילו Tru64 תומך ב־AdvFS ו־LSM. המנהל של AIX מתייחס ל־PE-ים כאל מחיצות פיזית ול־LE-ים כמחיצות לוגיות.
לינוקסה־LVM שוחרר ב־1998 והוא מסתמך על הדגם של HP-UX. הרחבה מקוונת היא אפשרית, בין השאר, עם מערכות הקבצים הבאים: ext2 ext3, JFS, XFS, ו־ReiserFS (החל מגרסה 3). כמו כן, ניתן לבצע שיקוף של LV בלי קשר למערכת הקבצים. בנוסף ליישום LVM של Red Hat זמין גם מנהל EVMS התומך בנוסף ל־LVM בכמעט כל פעילויות האחסון האחרות (מחיצות, RAID וניהול מערכות קבצים).
Solarisמגרסה 9 SVM ‏(Solaris Volume Manager) הוא חלק ממערכת ההפעלה, תוכנה זו מתייחסת ל־PV-ים כדיסקים פיזיים (אשר ניתן לשלב עם RAID0, RAID1 או RAID5 הבסיסיים לתוך דיסקים גדולים), מתייחסת ל־LV-ים כאל מחיצות רכות (מקטעים רציפים שניתן למקם בכל מקום על הדיסק, אבל לא יכול להתחלק בין מספר דיסקים) ול־VG-ים כקבוצת דיסקים.  
מגרסה 10 נוספה גם ZFS, המיישמת הן מערכת קבצים מפותחת והן תוכנת RAID, בתוכנה זו קיים מאגר אליו מוקצים דיסקים או חלקי דיסקים ומערכות הקובצים (ZFS) נשמרות ישירות על מאגר אחסון זה. ניתן להרחיב באופן דינמי הן את מאגר האחסון והן את מערכות הקבצים.
IRIXהן XLV הישן והן XVM החדש מצורפים לגרסה 6.5, אבל להגדרת שיקוף יש צורך ברישיון נוסף (רישיון Plexing)
OS/2, eComStationה־LVM שוחרר בו זמנית עם גרסת JFS (בשנת 2000). הניהול יכול להתבצע דרך שורת הפקודה או באמצעות ממשק המשתמש הגרפי.
חלונות 2000 ומעלהניהול LV כאן הוא למעשה ניהול דיסקים דינמיים שניתן להתקין עליהם את מערכת הקבצים NTFS. במערכת זו אין מושג של PE או LE והיא תומכת רק ב־RAID0, RAID1, RAID5 או במחיצות משורשרות בדיסק לתוך דיסקים גדולים יותר. מערכות הקבצים חייבות להיות על מחיצות שלמות (שיכולות להיות הדיסק כולו) והמערכת תומכת בהגדלה של LV-ים דינאמיים מקוונים (אך לא משוקפים).
FreeBSD, NetBSD, OpenBSD
Vinum הוא LVM שהושפע מהמנהל של Veritas אך לא מבוסס עליו. הוא פותח בתחילה ל־FreeBSD, הופץ כחלק מגרסה 3.0 וכעת יש לו וגרסאות ל־NetBSD ול־OpenBSD. המנהל תומך ברמות 0, 1, 5, של RAID וב־JBOD.
Veritas Volume Manager; : תומך במערכות הפעלה מרובות, כולל HP-UX, לינוקס, Solaris וחלונות וכולל ממשקים גרפיים ותווים. Veritas מציעה גם Cluster Volume Manager המאפשר ניהול LV עבור אשכולות. שני ה־LVM דורשים רישיון נפרד. המוצר מתייחס ל־LV-ים כדיסקים, ל־VG-ים כאל קבוצות דיסקים, יש תמיכה ב־PE-ים בעלי גודל שונה הנקראים תת-דיסקים וב־LE-ים המכונים plex-ים.

Oracle Automatic Storage Management ‏(ASM)זהו LVM ייעודי עבור מסד הנתונים אורקל, הכולל תמיכה בפריסה המידע על מספר דיסקים ובשיקוף. פריסת הנתונים נעשית לא לפי כמות הנתונים, אלא לפי עומס הקלט/פלט. עומס זה מאוחסן ומנותח באמצעות מאגר פנימי (Automatic Workload Repository - AWR). רכיב ASM מסופק בחינם עם תוכנת מסד הנתונים של Oracle והוא שימושי במיוחד באשכולות RAC.

הערות שוליים
------------

1. ↑  מציין האם המנהל מאפשר ל־LV-ים לגדול על כל השטח של ה־PV ב־VG.
2. ↑  אין מנגנון העתקה בזמן כתיבה, אך ניתן ליצור תמונות מידע באמצעות הקפאת הנתונים של בן זוג אחד בשיקוף.
3. ↑  AIX 5.1
4. ↑  מוצר של ספק חיצוני הזמין עבור חלונות ומערכות Unix רבות
5. ↑  מ־Windows Server 2003 והלאה