מה משותף ל-LVM ומטריושקה?

שָׁלוֹם.
ברצוני לחלוק עם הקהילה את הניסיון המעשי שלי בבניית מערכת אחסון נתונים עבור KVM באמצעות md RAID + LVM.

התוכנית תכלול:

• בניית md RAID 1 מ-NVMe SSD.
• הרכבת md RAID 6 מ-SATA SSD וכוננים רגילים.
• תכונות של פעולת TRIM/DISCARD ב-SSD RAID 1/6.
• יצירת מערך md RAID 1/6 הניתן לאתחול על קבוצה משותפת של דיסקים.
• התקנת המערכת ב-NVMe RAID 1 כאשר אין תמיכה ב-NVMe ב-BIOS.
• שימוש במטמון LVM וב-LVM דק.
• שימוש בתמונות BTRFS ושלח/קבל לגיבוי.
• שימוש בצילומי מצב דקים של LVM ו- thin_delta עבור גיבויים בסגנון BTRFS.

אם אתה מעוניין, אנא ראה חתול.

הצהרה

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

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

ברזל

הזמינים היו:

לוח אם מסביבות 2013 עם ערכת שבבים Z87, שלם עם Intel Core i7 / Haswell.

• מעבד 4 ליבות, 8 חוטים
• זיכרון RAM של 32 GB DDR3
• 1 x 16 או 2 x 8 PCIe 3.0
• 1 x 4 + 1 x 1 PCIe 2.0
• 6 x 6 GBps מחברי SATA 3

מתאם SAS LSI SAS9211-8I הבהב למצב IT / HBA. קושחה התומכת ב-RAID הוחלפה בכוונה בקושחה HBA כדי:

1. אתה יכול לזרוק את המתאם הזה בכל עת ולהחליף אותו בכל אחד אחר שנתקלת בו.
2. TRIM/Discard עבד כרגיל על דיסקים, כי... בקושחה של RAID פקודות אלו אינן נתמכות כלל, ול-HBA, באופן כללי, לא אכפת אילו פקודות משודרות דרך האוטובוס.

כוננים קשיחים - 8 חתיכות של HGST Travelstar 7K1000 עם קיבולת של 1 TB בפורמט 2.5, כמו למחשבים ניידים. כוננים אלה היו בעבר במערך RAID 6. יהיה להם שימוש גם במערכת החדשה. לאחסון גיבויים מקומיים.

נוסף נוסף:

6 חלקים SATA SSD דגם Samsung 860 QVO 2TB. כונני SSD אלה דרשו נפח גדול, נוכחות של מטמון SLC, אמינות ומחיר נמוך היו רצויים. נדרשה תמיכה ב-discard/zero, אשר נבדקת על ידי השורה ב-dmesg:

kernel: ata1.00: Enabling discard_zeroes_data

2 חתיכות של NVMe SSD דגם Samsung SSD 970 EVO 500GB.

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

מתאם StarTech PEX8M2E2 עבור 2 x NVMe SSD מותקן בחריץ PCIe 3.0 8x. זה, שוב, הוא רק HBA, אבל עבור NVMe. הוא שונה מתאמים זולים בכך שהוא אינו דורש תמיכה בפיצול PCIe מלוח האם בשל נוכחותו של מתג PCIe מובנה. זה יעבוד אפילו במערכת העתיקה ביותר עם PCIe, גם אם זה חריץ X1 PCIe 1.0. באופן טבעי, במהירות המתאימה. אין שם RAIDs. אין BIOS מובנה בלוח. אז, המערכת שלך לא תלמד באופן קסום לאתחל עם NVMe, ופחות לעשות NVMe RAID הודות למכשיר הזה.

רכיב זה נבע אך ורק מהנוכחות של PCIe 8 חינמי אחד בלבד במערכת, ואם יש 3.0 חריצים פנויים, ניתן להחליף אותו בקלות בשני אגורות PEX2M4E2 או אנלוגים, אותם ניתן לקנות בכל מקום במחיר של 1 רובל.

דחיית כל מיני חומרה או ערכת שבבים/BIOS RAID מובנים נעשתה בכוונה, על מנת שניתן יהיה להחליף לחלוטין את כל המערכת, למעט ה-SSD/HDD עצמם, תוך שמירה על כל הנתונים. באופן אידיאלי, כך שתוכל לשמור אפילו את מערכת ההפעלה המותקנת בעת מעבר לחומרה חדשה/שונה לחלוטין. העיקר שיש יציאות SATA ו-PCIe. זה כמו תקליטור חי או כונן הבזק שניתן לאתחול, רק מהיר מאוד וקצת מגושם.

Юморאחרת, אתה יודע מה קורה - לפעמים אתה צריך בדחיפות לקחת את כל המערך איתך כדי לקחת. אבל אני לא רוצה לאבד נתונים. לשם כך, כל המדיה המוזכרת ממוקמת בנוחות על השקופיות במפרצים 5.25 של המארז הסטנדרטי.

ובכן, וכמובן, להתנסות בשיטות שונות של שמירה במטמון SSD בלינוקס.

פשיטות חומרה משעממות. הפעל אותו. או שזה עובד או שזה לא. ועם mdadm תמיד יש אפשרויות.

תוכנה

בעבר, Debian 8 Jessie הותקן על החומרה, שקרובה ל-EOL. RAID 6 הורכב מהכוננים הקשיחים שהוזכרו לעיל בשילוב עם LVM. הוא הפעיל מכונות וירטואליות ב-kvm/libvirt.

כי למחבר יש ניסיון מתאים ביצירת כונני פלאש ניידים אתחול SATA/NVMe, וגם, כדי לא לשבור את תבנית המתאימה הרגילה, נבחרה אובונטו 18.04 כמערכת היעד, שכבר התייצבה מספיק, אבל עדיין יש לה 3 שנים של תמיכה בעתיד.

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

מתכונן להתקנה

כדי להתקין את המערכת אנו זקוקים ל-Ubuntu Desktop Image. למערכת השרת יש איזשהו מתקין נמרץ, שמראה עצמאות מוגזמת שלא ניתן לנטרל על ידי דחיפה של מחיצת מערכת UEFI על אחד הדיסקים, ומקלקל את כל היופי. בהתאם, הוא מותקן רק במצב UEFI. לא מציע שום אפשרויות.

אנחנו לא מרוצים מזה.

למה?לרוע המזל, אתחול UEFI אינו תואם בצורה גרועה ביותר ל-RAID של תוכנת האתחול, מכיוון ש... אף אחד לא מציע לנו הזמנות למחיצת UEFI ESP. ישנם מתכונים באינטרנט המציעים למקם את מחיצת ה-ESP על כונן הבזק ביציאת USB, אך זו נקודת כשל. ישנם מתכונים המשתמשים בתוכנה mdadm RAID 1 עם מטא נתונים גרסה 0.9 שאינם מונעים מה-UEFI BIOS לראות את המחיצה הזו, אבל זה חי עד לרגע המאושר שבו ה-BIOS או מערכת הפעלה חומרה אחרת כותבים משהו ל-ESP ושוכחים לסנכרן אותו עם אחרים מראות.

בנוסף, האתחול של UEFI תלוי ב-NVRAM, שלא יעבור יחד עם הדיסקים למערכת החדשה, מכיוון הוא חלק מלוח האם.

אז, לא נמציא מחדש גלגל חדש. יש לנו כבר אופני סבא מוכנים שנבדקו בזמן, הנקראים כעת Legacy/BIOS boot, הנושאים את השם הגאה של CSM במערכות תואמות UEFI. פשוט נוריד אותו מהמדף, נשמן אותו, נשאב את הצמיגים וננגב אותו במטלית לחה.

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

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

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

#sudo bash

אֵיך…?השורה למעלה היא הטריגר הקנוני להוליוואר על סודו. ג בоהזדמנויות גדולות יותר באות וоאחריות גדולה יותר. השאלה היא אם אתה יכול לקחת את זה על עצמך. אנשים רבים חושבים ששימוש ב-sudo בדרך זו הוא לפחות לא זהיר. למרות זאת:

#apt-get install mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc

למה לא ZFS...?כאשר אנו מתקינים תוכנה על המחשב שלנו, אנו בעצם משאילים את החומרה שלנו למפתחי התוכנה הזו לנהוג.
כאשר אנו סומכים על התוכנה הזו בבטיחות הנתונים שלנו, אנו לוקחים הלוואה השווה לעלות שחזור הנתונים הללו, שנצטרך לשלם מתישהו.

מנקודת מבט זו, ZFS הוא פרארי, ו-mdadm+lvm הוא יותר כמו אופניים.

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

למה אז BTRFS...?על מנת לאתחל את מערכת ההפעלה, אנו זקוקים למערכת קבצים שנתמכת ב-Legacy/BIOS GRUB מחוץ לקופסה, ובמקביל תומכת בצילומי מצב חיים. אנו נשתמש בו עבור מחיצת /boot. בנוסף, המחבר מעדיף להשתמש ב-FS זה עבור / (שורש), בלי לשכוח לציין שלכל תוכנה אחרת אתה יכול ליצור מחיצות נפרדות ב-LVM ולעלות אותן בספריות הדרושות.

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

בנוסף, המחבר בדרך כלל מעדיף לשמור על מינימום תוכנה ישירות על החומרה ולהפעיל את כל התוכנות האחרות במכונות וירטואליות באמצעות דברים כמו העברת GPUs ובקרי PCI-USB Host ל-KVM דרך IOMMU.

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

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

עם זאת, המחבר מתעלם בכוונה מתכונות השיקוף/RAID והיתירות המובנות שיש ל-ZFS, BRTFS ו-LVM.

כטיעון נוסף, ל-BTRFS יש את היכולת להפוך כתיבה אקראית לכתיבת רצף, מה שיש לו השפעה חיובית ביותר על מהירות סנכרון צילומי מצב/גיבויים ב-HDD.

בואו נסרוק מחדש את כל המכשירים:

#udevadm control --reload-rules && udevadm trigger

בואו נסתכל מסביב:

#lsscsi && nvme list
[0:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sda
[1:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdb
[2:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdc
[3:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdd
[4:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sde
[5:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdf
[6:0:0:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdg
[6:0:1:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdh
[6:0:2:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdi
[6:0:3:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdj
[6:0:4:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdk
[6:0:5:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdl
[6:0:6:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdm
[6:0:7:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdn
Node SN Model Namespace Usage Format FW Rev
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1 S466NXXXXXXX15L Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7
/dev/nvme1n1 S5H7NXXXXXXX48N Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7


פריסת דיסק

NVMe SSD

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

SATA HDD

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

#cat >hdd.part << EOF
label: dos
label-id: 0x00000000
device: /dev/sdg
unit: sectors

/dev/sdg1 : start= 2048, size= 1953523120, type=fd, bootable
EOF
#sfdisk /dev/sdg < hdd.part
#sfdisk /dev/sdh < hdd.part
#sfdisk /dev/sdi < hdd.part
#sfdisk /dev/sdj < hdd.part
#sfdisk /dev/sdk < hdd.part
#sfdisk /dev/sdl < hdd.part
#sfdisk /dev/sdm < hdd.part
#sfdisk /dev/sdn < hdd.part


SATA SSD

זה המקום שבו הדברים נעשים מעניינים עבורנו.

ראשית, הכוננים שלנו הם בגודל 2 TB. זה בטווח המקובל עבור MBR, וזה מה שנשתמש בו. במידת הצורך, ניתן להחליף ב-GPT. לדסקי GPT יש שכבת תאימות המאפשרת למערכות תואמות MBR לראות את 4 המחיצות הראשונות אם הן ממוקמות בתוך 2 הטרה-בייט הראשונים. העיקר הוא שמחיצת האתחול ומחיצת bios_grub בדיסקים האלה צריכים להיות בהתחלה. זה אפילו מאפשר לך לאתחל מכונני GPT Legacy/BIOS.

אבל זה לא המקרה שלנו.

כאן ניצור שני חלקים. הראשון יהיה בגודל 1 GB וישמש עבור RAID 1 /boot.

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

מה זה האזור הלא מסומן הזה?לפי מקורות ברשת, כונני SATA SSD שלנו כוללים מטמון SLC הניתן להרחבה דינמית בגודל של 6 עד 78 גיגה-בייט. אנחנו מקבלים 6 ג'יגה-בייט "בחינם" בגלל ההבדל בין "גיגה-בייט" ל-"ג'י-בייט" בגיליון הנתונים של הכונן. שאר ה-72 גיגה-בייט מוקצים משטח לא בשימוש.

כאן יש לציין שיש לנו מטמון SLC, והשטח תפוס במצב MLC 4 סיביות. מה שאומר עבורנו למעשה שעל כל 4 גיגה-בייט של מקום פנוי נקבל רק 1 גיגה-בייט של מטמון SLC.

תכפילו 72 גיגה-בייט ב-4 ותקבלו 288 גיגה-בייט. זהו השטח הפנוי שלא נסמן על מנת לאפשר לכוננים לעשות שימוש מלא במטמון SLC.

כך, למעשה, נקבל עד 312 גיגה-בייט של מטמון SLC מתוך שישה כוננים בסך הכל. מכל הכוננים, 2 ישמשו ב-RAID לצורך יתירות.

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

#cat >ssd.part << EOF
label: dos
label-id: 0x00000000
device: /dev/sda
unit: sectors

/dev/sda1 : start= 2048, size= 2097152, type=fd, bootable
/dev/sda2 : start= 2099200, size= 3300950016, type=fd
EOF
#sfdisk /dev/sda < ssd.part
#sfdisk /dev/sdb < ssd.part
#sfdisk /dev/sdc < ssd.part
#sfdisk /dev/sdd < ssd.part
#sfdisk /dev/sde < ssd.part
#sfdisk /dev/sdf < ssd.part


יצירת מערכים

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

#mcedit /etc/hostname
#mcedit /etc/hosts
#hostname
vdesk0


NVMe SSD

#mdadm --create --verbose --assume-clean /dev/md0 --level=1 --raid-devices=2 /dev/nvme[0-1]n1

למה -להניח-נקי...?כדי להימנע מאתחול מערכים. עבור שתי רמות RAID 1 ו-6 זה תקף. הכל יכול לעבוד ללא אתחול אם מדובר במערך חדש. יתרה מכך, אתחול מערך ה-SSD עם היצירה הוא בזבוז של משאב TBW. אנו משתמשים ב-TRIM/DISCARD במידת האפשר על מערכי SSD מורכבים כדי "לאתחל" אותם.

עבור מערכי SSD, RAID 1 DISCARD נתמך מהקופסה.

עבור מערכי SSD RAID 6 DISCARD, עליך להפעיל אותו בפרמטרים של מודול הליבה.

יש לעשות זאת רק אם לכל כונני ה-SSD המשמשים במערכים ברמה 4/5/6 במערכת זו יש תמיכה פעילה עבור discard_zeroes_data. לפעמים נתקלים בכוננים מוזרים שאומרים לקרנל שהפונקציה הזו נתמכת, אבל למעשה היא לא שם, או שהפונקציה לא תמיד עובדת. כרגע, תמיכה זמינה כמעט בכל מקום, עם זאת, ישנם כוננים ישנים וקושחה עם שגיאות. מסיבה זו, תמיכת DISCARD מושבתת כברירת מחדל עבור RAID 6.

שימו לב, הפקודה הבאה תשמיד את כל הנתונים בכונני NVMe על ידי "אתחול" המערך ב-"אפסים".

#blkdiscard /dev/md0

אם משהו משתבש, נסה לציין שלב.

#blkdiscard --step 65536 /dev/md0

SATA SSD

#mdadm --create --verbose --assume-clean /dev/md1 --level=1 --raid-devices=6 /dev/sd[a-f]1
#blkdiscard /dev/md1
#mdadm --create --verbose --assume-clean /dev/md2 --chunk-size=512 --level=6 --raid-devices=6 /dev/sd[a-f]2

למה כל כך גדול...?להגדלת גודל הנתח יש השפעה חיובית על מהירות הקריאה האקראית בבלוקים עד גודל הנתח כולל. זה קורה בגלל שפעולה אחת בגודל המתאים ומטה יכולה להתבצע במלואה במכשיר בודד. לכן, ה-IOPS מכל המכשירים מסוכם. על פי הסטטיסטיקה, 99% מה-IO אינו עולה על 512K.

RAID 6 IOPS לכל כתיבה תמיד פחות או שווה ל-IOPS של כונן אחד. כאשר, כקריאה אקראית, IOPS יכול להיות גדול פי כמה מזה של כונן אחד, וכאן יש חשיבות מרכזית לגודל הבלוק.
המחבר לא רואה טעם בניסיון לייעל פרמטר שהוא רע ב-RAID 6 by-design ובמקום זאת לייעל את מה ש-RAID 6 טוב בו.
נפצה על הכתיבה האקראית הגרועה של RAID 6 באמצעות מטמון NVMe וטריקים של אספקה ​​דקה.

עדיין לא הפעלנו את DISCARD עבור RAID 6. אז לא "נאתחל" את המערך הזה לעת עתה. נעשה זאת מאוחר יותר, לאחר התקנת מערכת ההפעלה.

SATA HDD

#mdadm --create --verbose --assume-clean /dev/md3 --chunk-size=512 --level=6 --raid-devices=8 /dev/sd[g-n]1

LVM על NVMe RAID

למהירות, אנו רוצים למקם את מערכת קבצי השורש ב-NVMe RAID 1 שהוא /dev/md0.
עם זאת, עדיין נצטרך את המערך המהיר הזה לצרכים אחרים, כגון swap, metadata ו-LVM-cache ו-LVM-thinn metadata, אז ניצור LVM VG על מערך זה.

#pvcreate /dev/md0
#vgcreate root /dev/md0

בואו ניצור מחיצה עבור מערכת קבצי השורש.

#lvcreate -L 128G --name root root

בואו ניצור מחיצה להחלפה לפי גודל ה-RAM.

#lvcreate -L 32G --name swap root

התקנת מערכת הפעלה

בסך הכל, יש לנו את כל הדרוש להתקנת המערכת.

הפעל את אשף התקנת המערכת מסביבת Ubuntu Live. התקנה רגילה. רק בשלב בחירת הדיסקים להתקנה, עליך לציין את הדברים הבאים:

• /dev/md1, - נקודת mount /boot, FS - BTRFS
• /dev/root/root (aka /dev/mapper/root-root), - נקודת הרכבה / (שורש), FS - BTRFS
• /dev/root/swap (aka /dev/mapper/root-swap), - השתמש כמחיצת החלפה
• התקן את טוען האתחול ב-/dev/sda

כאשר אתה בוחר BTRFS כמערכת קבצי השורש, המתקין יצור אוטומטית שני אמצעי אחסון BTRFS בשם "@" עבור / (שורש), ו-"@home" עבור /home.

בואו נתחיל בהתקנה...

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

#sudo bash

צור סביבת chroot כדי להמשיך בהתקנה:

#mkdir /mnt/chroot
#mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@ /dev/mapper/root-root /mnt/chroot
#mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@home /dev/mapper/root-root /mnt/chroot/home
#mount -o defaults,space_cache,noatime,nodiratime,discard /dev/md1 /mnt/chroot/boot
#mount --bind /proc /mnt/chroot/proc
#mount --bind /sys /mnt/chroot/sys
#mount --bind /dev /mnt/chroot/dev

בואו נגדיר את הרשת ואת שם המארח ב-chroot:

#cat /etc/hostname >/mnt/chroot/etc/hostname
#cat /etc/hosts >/mnt/chroot/etc/hosts
#cat /etc/resolv.conf >/mnt/chroot/etc/resolv.conf

בואו ניכנס לסביבת chroot:

#chroot /mnt/chroot

קודם כל נספק את החבילות:

apt-get install --reinstall mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc debsums hdparm

בואו נבדוק ונתקן את כל החבילות שהותקנו בצורה עקומה עקב התקנת מערכת לא שלמה:

#CORRUPTED_PACKAGES=$(debsums -s 2>&1 | awk '{print $6}' | uniq)
#apt-get install --reinstall $CORRUPTED_PACKAGES

אם משהו לא מסתדר, ייתכן שתצטרך לערוך תחילה את /etc/apt/sources.list

בואו נתאים את הפרמטרים של מודול RAID 6 כדי לאפשר את ה-TRIM/DISCARD:

#cat >/etc/modprobe.d/raid456.conf << EOF
options raid456 devices_handle_discard_safely=1
EOF

בואו נשנה מעט את המערכים שלנו:

#cat >/etc/udev/rules.d/60-md.rules << EOF
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/stripe_cache_size", ATTR{md/stripe_cache_size}="32768"
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_min", ATTR{md/sync_speed_min}="48000"
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_max", ATTR{md/sync_speed_max}="300000"
EOF
#cat >/etc/udev/rules.d/62-hdparm.rules << EOF
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/hdparm -B 254 /dev/%k"
EOF
#cat >/etc/udev/rules.d/63-blockdev.rules << EOF
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/blockdev --setra 1024 /dev/%k"
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="md*", RUN+="/sbin/blockdev --setra 0 /dev/%k"
EOF

מה זה היה..?יצרנו קבוצה של חוקי udev שיעשו את הפעולות הבאות:

• הגדר את גודל המטמון של הבלוק עבור RAID 2020 כדי להתאים לשנת 6. ערך ברירת המחדל, כך נראה, לא השתנה מאז יצירת לינוקס, ולא היה מספיק במשך זמן רב.
• שמור מינימום של IO למשך בדיקות/סנכרון מערך. זה כדי למנוע מהמערכים שלך להיתקע במצב של סנכרון נצחי תחת עומס.
• הגבל את ה-IO המקסימלי במהלך בדיקות/סנכרון של מערכים. זה הכרחי כדי שסנכרון/בדיקת SSD RAIDs לא יטגן את הכוננים שלך בצורה חדה. זה נכון במיוחד עבור NVMe. (זוכרים לגבי הרדיאטור? לא צחקתי.)
• אסרו על דיסקים לעצור את סיבוב הציר (HDD) באמצעות APM והגדר את פסק זמן השינה עבור בקרי דיסק ל-7 שעות. אתה יכול להשבית לחלוטין את APM אם הכוננים שלך יכולים לעשות זאת (-B 255). עם ערך ברירת המחדל, הכוננים יעצרו לאחר חמש שניות. ואז מערכת ההפעלה רוצה לאפס את מטמון הדיסקים, הדיסקים יסתובבו שוב, והכל יתחיל מחדש. לדיסקים יש מספר מרבי מוגבל של סיבובי ציר. מחזור ברירת מחדל פשוט כזה יכול בקלות להרוג את הדיסקים שלך תוך כמה שנים. לא כל הדיסקים סובלים מכך, אבל שלנו הם "לפטופים", עם הגדרות ברירת המחדל המתאימות, שגורמות ל-RAID להיראות כמו מיני-MAID.
• התקן Readahead על דיסקים (מסתובב) 1 מגה-בייט - שני בלוקים רצופים/נתח RAID 6
• השבת את Readahead במערכים עצמם.

בואו נערוך את /etc/fstab:

#cat >/etc/fstab << EOF
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# file-system mount-point type options dump pass
/dev/mapper/root-root / btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@ 0 1
UUID=$(blkid -o value -s UUID /dev/md1) /boot btrfs defaults,space_cache,noatime,nodiratime,discard 0 2
/dev/mapper/root-root /home btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@home 0 2
/dev/mapper/root-swap none swap sw 0 0
EOF
למה..?נחפש את המחיצה /boot לפי UUID. תיאורית שמות של מערכים עשוי להשתנות.

נחפש את החלקים הנותרים לפי שמות LVM בסימון /dev/mapper/vg-lv, מכיוון הם מזהים מחיצות בצורה די ייחודית.

אנחנו לא משתמשים ב-UUID עבור LVM בגלל UUID של אמצעי אחסון LVM ותצלומי המצב שלהם יכולים להיות זהים.הר /dev/mapper/root-root.. פעמיים?כן. בְּדִיוּק. תכונה של BTRFS. מערכת קבצים זו ניתנת להרכבה מספר פעמים עם תת-נפחים שונים.

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

בואו ניצור מחדש את תצורת ה-mdadm:

#/usr/share/mdadm/mkconf | sed 's/#DEVICE/DEVICE/g' >/etc/mdadm/mdadm.conf

בואו נתאים את הגדרות LVM:

#cat >>/etc/lvm/lvmlocal.conf << EOF

activation {
thin_pool_autoextend_threshold=90
thin_pool_autoextend_percent=5
}
allocation {
cache_pool_max_chunks=2097152
}
devices {
global_filter=["r|^/dev/.*_corig$|","r|^/dev/.*_cdata$|","r|^/dev/.*_cmeta$|","r|^/dev/.*gpv$|","r|^/dev/images/.*$|","r|^/dev/mapper/images.*$|","r|^/dev/backup/.*$|","r|^/dev/mapper/backup.*$|"] issue_discards=1
}
EOF

מה זה היה..?אפשרנו הרחבה אוטומטית של בריכות דקות של LVM כשהגענו ל-90% מהשטח התפוס ב-5% מהנפח.

הגדלנו את המספר המרבי של בלוקי מטמון עבור מטמון LVM.

מנענו מ-LVM לחפש נפחי LVM (PV) ב:

• מכשירים המכילים מטמון LVM (cdata)
• מכשירים המאוחסנים במטמון באמצעות מטמון LVM, עוקפים את המטמון ( _קוריג). במקרה זה, המכשיר המאוחסן עצמו עדיין ייסרק דרך המטמון (רק ).
• מכשירים המכילים מטא נתונים של מטמון LVM (cmeta)
• כל המכשירים ב-VG עם תמונות השם. כאן יהיו לנו תמונות דיסק של מכונות וירטואליות, ואנחנו לא רוצים ש-LVM במארח יפעיל אמצעי אחסון השייכים למערכת ההפעלה האורחת.
• כל המכשירים ב-VG עם השם גיבוי. כאן יהיו לנו עותקי גיבוי של תמונות מכונות וירטואליות.
• כל המכשירים ששמם מסתיים ב-"gpv" (נפח פיזי של אורח)

הפעלנו תמיכת DISCARD בעת פינוי שטח פנוי ב-LVM VG. הזהר. זה יגרום למחיקת LVs ב-SSD די גוזלת זמן. זה חל במיוחד על SSD RAID 6. עם זאת, על פי התוכנית, נשתמש בהקצאה דקה, כך שזה לא יפריע לנו כלל.

בואו נעדכן את תמונת initramfs:

#update-initramfs -u -k all

התקן והגדר את grub:

#apt-get install grub-pc
#apt-get purge os-prober
#dpkg-reconfigure grub-pc

באילו דיסקים כדאי לבחור?כל מי שהם sd*. המערכת חייבת להיות מסוגלת לאתחל מכל כונן SATA או SSD פועלים.

למה הוסיפו os-prober..?לעצמאות יתר וידיים שובבות.

זה לא עובד כשורה אם אחד מ-RAIDs נמצא במצב פגום. הוא מנסה לחפש את מערכת ההפעלה במחיצות המשמשות במכונות וירטואליות הפועלות על חומרה זו.

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

עם זה השלמנו את ההתקנה הראשונית. זה הזמן לאתחל מחדש למערכת ההפעלה החדשה שהותקנה. אל תשכח להסיר את ה- Live CD/USB הניתן לאתחול.

#exit
#reboot

בחר כל אחד מכונני SATA SSD כהתקן האתחול.

LVM על SATA SSD

בשלב זה, כבר אתחול למערכת ההפעלה החדשה, הגדרנו את הרשת, apt, פתחנו את אמולטור המסוף והשקנו:

#sudo bash

אנחנו ממשיכים.

"אתחל" את המערך מ- SATA SSD:

#blkdiscard /dev/md2

אם זה לא עובד, נסה:

#blkdiscard --step 65536 /dev/md2
צור LVM VG על SATA SSD:

#pvcreate /dev/md2
#vgcreate data /dev/md2

למה עוד VG..?למעשה, כבר יש לנו VG בשם root. למה לא להוסיף הכל ל-VG אחד?

אם ישנם מספר PVs ב-VG, אז כדי שה-VG יופעל כהלכה, כל ה-PVs חייבים להיות נוכחים (מקוון). היוצא מן הכלל הוא LVM RAID, שאנו לא משתמשים בו בכוונה.

אנחנו מאוד רוצים שאם יש כשל (אובדן נתונים) בכל אחד ממערכי ה-RAID 6, מערכת ההפעלה תאתחל כרגיל ותיתן לנו את ההזדמנות לפתור את הבעיה.

לשם כך, ברמת ההפשטה הראשונה נבודד כל סוג של "מדיה" פיזית ל-VG נפרד.

מבחינה מדעית, מערכי RAID שונים שייכים ל"תחומי אמינות" שונים. לא כדאי ליצור עבורם נקודת כשל נפוצה נוספת על ידי דחיסתם ל-VG אחד.

הנוכחות של LVM ברמת "חומרה" תאפשר לנו לחתוך באופן שרירותי חתיכות של מערכי RAID שונים על ידי שילובם בדרכים שונות. למשל - לרוץ בו זמנית bcache + LVM דק, bcache + BTRFS, LVM cache + LVM thin, תצורת ZFS מורכבת עם מטמונים, או כל תערובת גיהנומית אחרת כדי לנסות ולהשוות את הכל.

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

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

LVM על SATA HDD

#pvcreate /dev/md3
#vgcreate backup /dev/md3

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

הגדרת מטמון LVM

בואו ניצור LV ב-NVMe RAID 1 כדי להשתמש בו כהתקן מטמון.

#lvcreate -L 70871154688B --name cache root

למה יש כל כך מעט...?העובדה היא שלכונני ה-NVMe SSD שלנו יש גם מטמון SLC. 4 גיגה-בייט של "חופשי" ו-18 גיגה-בייט דינמי בגלל השטח הפנוי שתפוס ב-3-bit MLC. לאחר מיצוי המטמון הזה, כונני SSD של NVMe לא יהיו מהירים בהרבה מה-SATA SSD שלנו עם מטמון. למעשה, מסיבה זו, אין זה הגיוני עבורנו להפוך את מחיצת המטמון של LVM לגדולה בהרבה מפעמיים מגודל המטמון SLC של כונן NVMe. עבור כונני ה-NVMe המשמשים, המחבר סבור שזה הגיוני לייצר 32-64 גיגה-בייט של מטמון.

גודל המחיצה הנתון נדרש כדי לארגן 64 גיגה-בייט של מטמון, מטא נתונים של מטמון וגיבוי של מטא נתונים.

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

בואו ניצור LV ב-SATA RAID 6 כדי להשתמש בו כהתקן שמור.

#lvcreate -L 3298543271936B --name cache data

למה רק שלושה טרה-בייט..?כך שבמידת הצורך תוכל להשתמש ב-SATA SSD RAID 6 לצרכים אחרים. ניתן להגדיל את גודל השטח המאוחסן באופן דינמי, תוך כדי תנועה, מבלי לעצור את המערכת. כדי לעשות זאת, עליך לעצור זמנית ולהפעיל מחדש את המטמון, אך היתרון המובהק של LVM-cache על פני, למשל, bcache הוא שניתן לעשות זאת תוך כדי תנועה.

בואו ניצור VG חדש לאחסון במטמון.

#pvcreate /dev/root/cache
#pvcreate /dev/data/cache
#vgcreate cache /dev/root/cache /dev/data/cache

בואו ניצור LV במכשיר השמור.

#lvcreate -L 3298539077632B --name cachedata cache /dev/data/cache

כאן תפסנו מיד את כל השטח הפנוי ב- /dev/data/cache כך שכל שאר המחיצות הדרושות נוצרו מיד ב- /dev/root/cache. אם יצרת משהו במקום הלא נכון, תוכל להעביר אותו באמצעות pvmove.

בואו ניצור ונפעיל את המטמון:

#lvcreate -y -L 64G -n cache cache /dev/root/cache
#lvcreate -y -L 1G -n cachemeta cache /dev/root/cache
#lvconvert -y --type cache-pool --cachemode writeback --chunksize 64k --poolmetadata cache/cachemeta cache/cache
#lvconvert -y --type cache --cachepool cache/cache cache/cachedata

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

64k הוא גודל הבלוק המינימלי המותר עבור LVM דק.

היזהר בכתיבה חוזרת..!כן. סוג זה של מטמון דוחה סנכרון כתיבה למכשיר השמור. המשמעות היא שאם המטמון יאבד, אתה עלול לאבד נתונים במכשיר השמור. מאוחר יותר, המחבר יספר לכם אילו אמצעים, בנוסף ל-NVMe RAID 1, ניתן לנקוט כדי לפצות על הסיכון הזה.

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

בוא נבדוק מה קיבלנו:

#lvs -a -o lv_name,lv_size,devices --units B cache
LV LSize Devices
[cache] 68719476736B cache_cdata(0)
[cache_cdata] 68719476736B /dev/root/cache(0)
[cache_cmeta] 1073741824B /dev/root/cache(16384)
cachedata 3298539077632B cachedata_corig(0)
[cachedata_corig] 3298539077632B /dev/data/cache(0)
[lvol0_pmspare] 1073741824B /dev/root/cache(16640)

רק [cachedata_corig] צריך להיות ממוקם ב-/dev/data/cache. אם משהו לא בסדר, השתמש ב-pvmove.

אתה יכול להשבית את המטמון במידת הצורך בפקודה אחת:

#lvconvert -y --uncache cache/cachedata

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

הגדרת LVM דק

בואו נעריך בערך כמה מקום אנחנו צריכים למטא נתונים דקים של LVM:

#thin_metadata_size --block-size=64k --pool-size=6terabytes --max-thins=100000 -u bytes
thin_metadata_size - 3385794560 bytes estimated metadata area size for "--block-size=64kibibytes --pool-size=6terabytes --max-thins=100000"

עיגול עד 4 גיגה-בייט: 4294967296B

הכפל בשניים והוסף 4194304B עבור מטא נתונים של LVM PV: 8594128896B
בואו ניצור מחיצה נפרדת ב-NVMe RAID 1 כדי למקם עליה מטא נתונים דקים של LVM ועותק הגיבוי שלהם:

#lvcreate -L 8594128896B --name images root

בשביל מה..?כאן עשויה להתעורר השאלה: מדוע למקם בנפרד מטא נתונים דקים של LVM אם הם עדיין יישמרו במטמון ב-NVMe ויעבדו במהירות.

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

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

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

בואו ניצור VG חדש שיהיה אחראי להקצאת דק:

#pvcreate /dev/root/images
#pvcreate /dev/cache/cachedata
#vgcreate images /dev/root/images /dev/cache/cachedata
בואו ניצור בריכה:

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T images/thin-pool
למה -Z yבנוסף למה שמצב זה נועד למעשה - למנוע דליפה של נתונים ממכונה וירטואלית אחת למכונה וירטואלית אחרת בעת חלוקה מחדש של שטח - נעשה שימוש נוסף באפס כדי להגביר את מהירות הכתיבה האקראית בלוקים הקטנים מ-64k. כל כתיבה של פחות מ-64k לאזור שלא הוקצה בעבר של הנפח הדק יהפוך ליישור קצה של 64K במטמון. זה יאפשר לבצע את הפעולה כולה דרך המטמון, תוך עקיפת המכשיר המאוחסן.

בואו נעביר את ה-LVs ל-PVs המתאימים:

#pvmove -n images/thin-pool_tdata /dev/root/images /dev/cache/cachedata
#pvmove -n images/lvol0_pmspare /dev/cache/cachedata /dev/root/images
#pvmove -n images/thin-pool_tmeta /dev/cache/cachedata /dev/root/images

בוא נבדוק:

#lvs -a -o lv_name,lv_size,devices --units B images
LV LSize Devices
[lvol0_pmspare] 4294967296B /dev/root/images(0)
thin-pool 274877906944B thin-pool_tdata(0)
[thin-pool_tdata] 274877906944B /dev/cache/cachedata(0)
[thin-pool_tmeta] 4294967296B /dev/root/images(1024)

בואו ניצור נפח דק לבדיקות:

#lvcreate -V 64G --thin-pool thin-pool --name test images

נתקין חבילות לבדיקות וניטור:

#apt-get install sysstat fio

כך תוכל לצפות בהתנהגות של תצורת האחסון שלנו בזמן אמת:

#watch 'lvs --rows --reportformat basic --quiet -ocache_dirty_blocks,cache_settings cache/cachedata && (lvdisplay cache/cachedata | grep Cache) && (sar -p -d 2 1 | grep -E "sd|nvme|DEV|md1|md2|md3|md0" | grep -v Average | sort)'

כך נוכל לבדוק את התצורה שלנו:

#fio --loops=1 --size=64G --runtime=4 --filename=/dev/images/test --stonewall --ioengine=libaio --direct=1
--name=4kQD32read --bs=4k --iodepth=32 --rw=randread
--name=8kQD32read --bs=8k --iodepth=32 --rw=randread
--name=16kQD32read --bs=16k --iodepth=32 --rw=randread
--name=32KQD32read --bs=32k --iodepth=32 --rw=randread
--name=64KQD32read --bs=64k --iodepth=32 --rw=randread
--name=128KQD32read --bs=128k --iodepth=32 --rw=randread
--name=256KQD32read --bs=256k --iodepth=32 --rw=randread
--name=512KQD32read --bs=512k --iodepth=32 --rw=randread
--name=4Kread --bs=4k --rw=read
--name=8Kread --bs=8k --rw=read
--name=16Kread --bs=16k --rw=read
--name=32Kread --bs=32k --rw=read
--name=64Kread --bs=64k --rw=read
--name=128Kread --bs=128k --rw=read
--name=256Kread --bs=256k --rw=read
--name=512Kread --bs=512k --rw=read
--name=Seqread --bs=1m --rw=read
--name=Longread --bs=8m --rw=read
--name=Longwrite --bs=8m --rw=write
--name=Seqwrite --bs=1m --rw=write
--name=512Kwrite --bs=512k --rw=write
--name=256write --bs=256k --rw=write
--name=128write --bs=128k --rw=write
--name=64write --bs=64k --rw=write
--name=32write --bs=32k --rw=write
--name=16write --bs=16k --rw=write
--name=8write --bs=8k --rw=write
--name=4write --bs=4k --rw=write
--name=512KQD32write --bs=512k --iodepth=32 --rw=randwrite
--name=256KQD32write --bs=256k --iodepth=32 --rw=randwrite
--name=128KQD32write --bs=128k --iodepth=32 --rw=randwrite
--name=64KQD32write --bs=64k --iodepth=32 --rw=randwrite
--name=32KQD32write --bs=32k --iodepth=32 --rw=randwrite
--name=16KQD32write --bs=16k --iodepth=32 --rw=randwrite
--name=8KQD32write --bs=8k --iodepth=32 --rw=randwrite
--name=4kQD32write --bs=4k --iodepth=32 --rw=randwrite
| grep -E 'read|write|test' | grep -v ioengine

בקפידה! מַשׁאָב!קוד זה יריץ 36 בדיקות שונות, שכל אחת מהן תפעל למשך 4 שניות. מחצית מהבדיקות מיועדות להקלטה. אתה יכול להקליט הרבה ב-NVMe ב-4 שניות. עד 3 גיגה-בייט בשנייה. לכן, כל ריצה של מבחני כתיבה יכולה לאכול ממך עד 216 גיגה-בייט של משאב SSD.

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

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

בין היתר, אני ממליץ למדוד את המהירות על נפח דק כבר מלא שממנו צולמה בדיוק תמונת מצב. למחבר הייתה הזדמנות לראות כיצד כתיבה אקראית מואצת בחדות מיד לאחר יצירת תמונת המצב הראשונה, במיוחד כאשר המטמון עדיין לא מלא לחלוטין. זה קורה עקב סמנטיקה של כתיבה העתקה על כתיבה, יישור מטמון ובלוקי נפח דקים, והעובדה שכתיבה אקראית ל-RAID 6 הופכת לקריאה אקראית מ-RAID 6 ואחריה כתיבה למטמון. בתצורה שלנו, קריאה אקראית מ-RAID 6 מהירה עד פי 6 (מספר כונני SATA SSD במערך) מאשר כתיבה. כי בלוקים עבור CoW מוקצים ברצף ממאגר דק, ואז ההקלטה, לרוב, הופכת גם לרצף.

ניתן להשתמש בשתי התכונות הללו לטובתך.

שמור תמונות מצב "קוהרנטיות".

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

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

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

1. עבור כל כרך דק עם השם <name>, צור תמונת מצב עם השם <name>.cached
2. בואו נגדיר את סף ההעברה לערך גבוה סביר: #lvchange --quiet --cachesettings "migration_threshold=16384" cache/cachedata
3. בלולאה אנו בודקים את מספר הבלוקים המלוכלכים במטמון: #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' עד שנקבל אפס. אם האפס חסר במשך זמן רב מדי, ניתן ליצור אותו על ידי מעבר זמני של המטמון למצב כתיבה. עם זאת, בהתחשב במאפייני המהירות של מערכי SATA ו-NVMe SSD שלנו, כמו גם את משאב ה-TBW שלהם, תוכל לתפוס את הרגע במהירות מבלי לשנות את מצב המטמון, או שהחומרה שלך תאכל לחלוטין את כל המשאב שלה ב כמה ימים. עקב מגבלות משאבים, המערכת, באופן עקרוני, לא מסוגלת להיות תחת עומס כתיבה של 100% כל הזמן. כונני ה-NVMe SSD שלנו מתחת לעומס כתיבה של 100% ימצו לחלוטין את המשאב פנימה 3-4 של היום. כונני SATA SSD יחזיקו מעמד רק פי שניים יותר. לכן, נניח שרוב העומס הולך לקריאה, ויש לנו פרצים קצרי טווח יחסית של פעילות גבוהה במיוחד בשילוב עם עומס נמוך בממוצע לכתיבה.
4. ברגע שתפסנו (או עשינו) אפס, אנו משנים את שם <name>.cached ל-<name>.committed. ה-<name>.committed הישן נמחק.
5. לחלופין, אם המטמון מלא ב-100%, ניתן ליצור אותו מחדש על ידי סקריפט, ובכך לנקות אותו. עם מטמון ריק למחצה, המערכת עובדת הרבה יותר מהר בעת כתיבה.
6. הגדר את סף ההגירה לאפס: #lvchange --quiet --cachesettings "migration_threshold=0" cache/cachedata זה ימנע זמנית את סנכרון המטמון עם המדיה הראשית.
7. אנו ממתינים עד שיצטברו די הרבה שינויים במטמון #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' או שהטיימר ייכבה.
8. אנחנו חוזרים שוב.

למה קשיים עם סף הגירה...?העניין הוא שבפועל, הקלטה "אקראית" היא למעשה לא לגמרי אקראית. אם כתבנו משהו למגזר בגודל של 4 קילובייט, יש סבירות גבוהה שבדקות הקרובות תיעשה רשומה לאותו סקטור או אחד מהסקטורים הסמוכים (+- 32K).

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

איפה הקוד..?למרבה הצער, המחבר מחשיב את עצמו לא מספיק מוכשר בפיתוח תסריטי בש, כי הוא 100% אוטודידקט ומתאמן בפיתוח מונע "גוגל", לכן הוא מאמין שאף אחד לא צריך להשתמש בקוד הנורא שיוצא מידיו אַחֵר.

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

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

TRIM/DISCARD ב-libvirt/KVM

כי אחסון הנתונים ישמש עבור KVM המריץ libvirt, אז זה יהיה רעיון טוב ללמד את ה-VMs שלנו לא רק לתפוס מקום פנוי, אלא גם לפנות את מה שכבר לא נחוץ.

זה נעשה על ידי הדמיית תמיכת TRIM/DISCARD על דיסקים וירטואליים. כדי לעשות זאת, עליך לשנות את סוג הבקר ל-virtio-scsi ולערוך את ה-xml.

#virsh edit vmname
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='writethrough' io='threads' discard='unmap'/>
<source dev='/dev/images/vmname'/>
<backingStore/>
<target dev='sda' bus='scsi'/>
<alias name='scsi0-0-0-0'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>

<controller type='scsi' index='0' model='virtio-scsi'>
<alias name='scsi0'/>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</controller>

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

גיבוי BTRFS

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

בואו ניצור נפח במכשיר הגיבוי:

#lvcreate -L 256G --name backup backup

בואו נעצב אותו ב-BTRFS:

#mkfs.btrfs /dev/backup/backup

בואו ניצור נקודות הרכבה ונעלה את תת-הסעיפים הבסיסיים של מערכת הקבצים:

#mkdir /backup
#mkdir /backup/btrfs
#mkdir /backup/btrfs/root
#mkdir /backup/btrfs/back
#ln -s /boot /backup/btrfs
# cat >>/etc/fstab << EOF

/dev/mapper/root-root /backup/btrfs/root btrfs defaults,space_cache,noatime,nodiratime 0 2
/dev/mapper/backup-backup /backup/btrfs/back btrfs defaults,space_cache,noatime,nodiratime 0 2
EOF
#mount -a
#update-initramfs -u
#update-grub

בואו ניצור ספריות לגיבויים:

#mkdir /backup/btrfs/back/remote
#mkdir /backup/btrfs/back/remote/root
#mkdir /backup/btrfs/back/remote/boot

בואו ניצור ספרייה עבור סקריפטים לגיבוי:

#mkdir /root/btrfs-backup

בואו נעתיק את התסריט:

הרבה קוד bash מפחיד. השימוש על אחריותך בלבד. אל תכתוב מכתבים זועמים לסופר...#cat >/root/btrfs-backup/btrfs-backup.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

LOCK_FILE="/dev/shm/$SCRIPT_NAME.lock"
DATE_PREFIX='%Y-%m-%d'
DATE_FORMAT=$DATE_PREFIX'-%H-%M-%S'
DATE_REGEX='[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]'
BASE_SUFFIX=".@base"
PEND_SUFFIX=".@pend"
SNAP_SUFFIX=".@snap"
MOUNTS="/backup/btrfs/"
BACKUPS="/backup/btrfs/back/remote/"

function terminate ()
{
echo "$1" >&2
exit 1
}

function wait_lock()
{
flock 98
}

function wait_lock_or_terminate()
{
echo "Wating for lock..."
wait_lock || terminate "Failed to get lock. Exiting..."
echo "Got lock..."
}

function suffix()
{
FORMATTED_DATE=$(date +"$DATE_FORMAT")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function filter()
{
FORMATTED_DATE=$(date --date="$1" +"$DATE_PREFIX")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function backup()
{
SOURCE_PATH="$MOUNTS$1"
TARGET_PATH="$BACKUPS$1"
SOURCE_BASE_PATH="$MOUNTS$1$BASE_SUFFIX"
TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
TARGET_BASE_DIR="$(dirname $TARGET_BASE_PATH)"
SOURCE_PEND_PATH="$MOUNTS$1$PEND_SUFFIX"
TARGET_PEND_PATH="$BACKUPS$1$PEND_SUFFIX"
if [ -d "$SOURCE_BASE_PATH" ] then
echo "$SOURCE_BASE_PATH found"
else
echo "$SOURCE_BASE_PATH File not found creating snapshot of $SOURCE_PATH to $SOURCE_BASE_PATH"
btrfs subvolume snapshot -r $SOURCE_PATH $SOURCE_BASE_PATH
sync
if [ -d "$TARGET_BASE_PATH" ] then
echo "$TARGET_BASE_PATH found out of sync with source... removing..."
btrfs subvolume delete -c $TARGET_BASE_PATH
sync
fi
fi
if [ -d "$TARGET_BASE_PATH" ] then
echo "$TARGET_BASE_PATH found"
else
echo "$TARGET_BASE_PATH not found. Synching to $TARGET_BASE_DIR"
btrfs send $SOURCE_BASE_PATH | btrfs receive $TARGET_BASE_DIR
sync
fi
if [ -d "$SOURCE_PEND_PATH" ] then
echo "$SOURCE_PEND_PATH found removing..."
btrfs subvolume delete -c $SOURCE_PEND_PATH
sync
fi
btrfs subvolume snapshot -r $SOURCE_PATH $SOURCE_PEND_PATH
sync
if [ -d "$TARGET_PEND_PATH" ] then
echo "$TARGET_PEND_PATH found removing..."
btrfs subvolume delete -c $TARGET_PEND_PATH
sync
fi
echo "Sending $SOURCE_PEND_PATH to $TARGET_PEND_PATH"
btrfs send -p $SOURCE_BASE_PATH $SOURCE_PEND_PATH | btrfs receive $TARGET_BASE_DIR
sync
TARGET_DATE_SUFFIX=$(suffix)
btrfs subvolume snapshot -r $TARGET_PEND_PATH "$TARGET_PATH$TARGET_DATE_SUFFIX"
sync
btrfs subvolume delete -c $SOURCE_BASE_PATH
sync
btrfs subvolume delete -c $TARGET_BASE_PATH
sync
mv $SOURCE_PEND_PATH $SOURCE_BASE_PATH
mv $TARGET_PEND_PATH $TARGET_BASE_PATH
sync
}

function list()
{
LIST_TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
LIST_TARGET_BASE_DIR="$(dirname $LIST_TARGET_BASE_PATH)"
LIST_TARGET_BASE_NAME="$(basename -s .$BASE_SUFFIX $LIST_TARGET_BASE_PATH)"
find "$LIST_TARGET_BASE_DIR" -maxdepth 1 -mindepth 1 -type d -printf "%fn" | grep "${LIST_TARGET_BASE_NAME/$BASE_SUFFIX/$SNAP_SUFFIX}.$DATE_REGEX"
}

function remove()
{
REMOVE_TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
REMOVE_TARGET_BASE_DIR="$(dirname $REMOVE_TARGET_BASE_PATH)"
btrfs subvolume delete -c $REMOVE_TARGET_BASE_DIR/$2
sync
}

function removeall()
{
DATE_OFFSET="$2"
FILTER="$(filter "$DATE_OFFSET")"
while read -r SNAPSHOT ; do
remove "$1" "$SNAPSHOT"
done < <(list "$1" | grep "$FILTER")

}

(
COMMAND="$1"
shift

case "$COMMAND" in
"--help")
echo "Help"
;;
"suffix")
suffix
;;
"filter")
filter "$1"
;;
"backup")
wait_lock_or_terminate
backup "$1"
;;
"list")
list "$1"
;;
"remove")
wait_lock_or_terminate
remove "$1" "$2"
;;
"removeall")
wait_lock_or_terminate
removeall "$1" "$2"
;;
*)
echo "None.."
;;
esac
) 98>$LOCK_FILE

EOF


מה זה עושה בכלל..?מכיל קבוצה של פקודות פשוטות ליצירת תמונות BTRFS והעתקתן ל-FS אחר באמצעות BTRFS שליחה/קבלה.

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

עוד סקריפט שנכניס ל-cron:

עוד קצת קוד bash#cat >/root/btrfs-backup/cron-daily.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

BACKUP_SCRIPT="$SCRIPT_DIR/btrfs-backup.sh"
RETENTION="-60 day"
$BACKUP_SCRIPT backup root/@
$BACKUP_SCRIPT removeall root/@ "$RETENTION"
$BACKUP_SCRIPT backup root/@home
$BACKUP_SCRIPT removeall root/@home "$RETENTION"
$BACKUP_SCRIPT backup boot/
$BACKUP_SCRIPT removeall boot/ "$RETENTION"
EOF


מה זה עושה..?יוצר ומסנכרן תמונות מצב מצטברות של אמצעי האחסון המפורטים של BTRFS ב-FS הגיבוי. לאחר מכן, הוא מוחק את כל התמונות שנוצרו לפני 60 יום. לאחר ההשקה, תצלומי מצב מתוארכים של אמצעי האחסון הרשומים יופיעו בספריות המשנה /backup/btrfs/back/remote/.

בואו ניתן לקוד זכויות ביצוע:

#chmod +x /root/btrfs-backup/cron-daily.sh
#chmod +x /root/btrfs-backup/btrfs-backup.sh

בוא נבדוק את זה ונשים את זה ב-cron:

#/usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/btrfs-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t btrfs-backup
#cat /var/log/syslog | grep btrfs-backup
#crontab -e
0 2 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/btrfs-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t btrfs-backup


גיבוי דק של LVM

בואו ניצור מאגר דק במכשיר הגיבוי:

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T backup/thin-pool

בואו נתקין ddrescue, כי... סקריפטים ישתמשו בכלי זה:

#apt-get install gddrescue

בואו ניצור ספרייה עבור סקריפטים:

#mkdir /root/lvm-thin-backup

בואו נעתיק את התסריטים:

הרבה בושה בפנים...#cat >/root/lvm-thin-backup/lvm-thin-backup.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

LOCK_FILE="/dev/shm/$SCRIPT_NAME.lock"
DATE_PREFIX='%Y-%m-%d'
DATE_FORMAT=$DATE_PREFIX'-%H-%M-%S'
DATE_REGEX='[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]'
BASE_SUFFIX=".base"
PEND_SUFFIX=".pend"
SNAP_SUFFIX=".snap"
BACKUPS="backup"
BACKUPS_POOL="thin-pool"

export LVM_SUPPRESS_FD_WARNINGS=1

function terminate ()
{
echo "$1" >&2
exit 1
}

function wait_lock()
{
flock 98
}

function wait_lock_or_terminate()
{
echo "Wating for lock..."
wait_lock || terminate "Failed to get lock. Exiting..."
echo "Got lock..."
}

function suffix()
{
FORMATTED_DATE=$(date +"$DATE_FORMAT")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function filter()
{
FORMATTED_DATE=$(date --date="$1" +"$DATE_PREFIX")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function read_thin_id {
lvs --rows --reportformat basic --quiet -othin_id "$1/$2" | awk '{print $2}'
}

function read_pool_lv {
lvs --rows --reportformat basic --quiet -opool_lv "$1/$2" | awk '{print $2}'
}

function read_lv_dm_path {
lvs --rows --reportformat basic --quiet -olv_dm_path "$1/$2" | awk '{print $2}'
}

function read_lv_active {
lvs --rows --reportformat basic --quiet -olv_active "$1/$2" | awk '{print $2}'
}

function read_lv_chunk_size {
lvs --rows --reportformat basic --quiet --units b --nosuffix -ochunk_size "$1/$2" | awk '{print $2}'
}

function read_lv_size {
lvs --rows --reportformat basic --quiet --units b --nosuffix -olv_size "$1/$2" | awk '{print $2}'
}

function activate_volume {
lvchange -ay -Ky "$1/$2"
}

function deactivate_volume {
lvchange -an "$1/$2"
}

function read_thin_metadata_snap {
dmsetup status "$1" | awk '{print $7}'
}

function thindiff()
{
DIFF_VG="$1"
DIFF_SOURCE="$2"
DIFF_TARGET="$3"
DIFF_SOURCE_POOL=$(read_pool_lv $DIFF_VG $DIFF_SOURCE)
DIFF_TARGET_POOL=$(read_pool_lv $DIFF_VG $DIFF_TARGET)

if [ "$DIFF_SOURCE_POOL" == "" ] then
(>&2 echo "Source LV is not thin.")
exit 1
fi

if [ "$DIFF_TARGET_POOL" == "" ] then
(>&2 echo "Target LV is not thin.")
exit 1
fi

if [ "$DIFF_SOURCE_POOL" != "$DIFF_TARGET_POOL" ] then
(>&2 echo "Source and target LVs belong to different thin pools.")
exit 1
fi

DIFF_POOL_PATH=$(read_lv_dm_path $DIFF_VG $DIFF_SOURCE_POOL)
DIFF_SOURCE_ID=$(read_thin_id $DIFF_VG $DIFF_SOURCE)
DIFF_TARGET_ID=$(read_thin_id $DIFF_VG $DIFF_TARGET)
DIFF_POOL_PATH_TPOOL="$DIFF_POOL_PATH-tpool"
DIFF_POOL_PATH_TMETA="$DIFF_POOL_PATH"_tmeta
DIFF_POOL_METADATA_SNAP=$(read_thin_metadata_snap $DIFF_POOL_PATH_TPOOL)

if [ "$DIFF_POOL_METADATA_SNAP" != "-" ] then
(>&2 echo "Thin pool metadata snapshot already exist. Assuming stale one. Will release metadata snapshot in 5 seconds.")
sleep 5
dmsetup message $DIFF_POOL_PATH_TPOOL 0 release_metadata_snap
fi

dmsetup message $DIFF_POOL_PATH_TPOOL 0 reserve_metadata_snap
DIFF_POOL_METADATA_SNAP=$(read_thin_metadata_snap $DIFF_POOL_PATH_TPOOL)

if [ "$DIFF_POOL_METADATA_SNAP" == "-" ] then
(>&2 echo "Failed to create thin pool metadata snapshot.")
exit 1
fi

#We keep output in variable because metadata snapshot need to be released early.
DIFF_DATA=$(thin_delta -m$DIFF_POOL_METADATA_SNAP --snap1 $DIFF_SOURCE_ID --snap2 $DIFF_TARGET_ID $DIFF_POOL_PATH_TMETA)

dmsetup message $DIFF_POOL_PATH_TPOOL 0 release_metadata_snap

echo $"$DIFF_DATA" | grep -E 'different|left_only|right_only' | sed 's/</"/g' | sed 's/ /"/g' | awk -F'"' '{print $6 "t" $8 "t" $11}' | sed 's/different/copy/g' | sed 's/left_only/copy/g' | sed 's/right_only/discard/g'

}

function thinsync()
{
SYNC_VG="$1"
SYNC_PEND="$2"
SYNC_BASE="$3"
SYNC_TARGET="$4"
SYNC_PEND_POOL=$(read_pool_lv $SYNC_VG $SYNC_PEND)
SYNC_BLOCK_SIZE=$(read_lv_chunk_size $SYNC_VG $SYNC_PEND_POOL)
SYNC_PEND_PATH=$(read_lv_dm_path $SYNC_VG $SYNC_PEND)

activate_volume $SYNC_VG $SYNC_PEND

while read -r SYNC_ACTION SYNC_OFFSET SYNC_LENGTH ; do
SYNC_OFFSET_BYTES=$((SYNC_OFFSET * SYNC_BLOCK_SIZE))
SYNC_LENGTH_BYTES=$((SYNC_LENGTH * SYNC_BLOCK_SIZE))
if [ "$SYNC_ACTION" == "copy" ] then
ddrescue --quiet --force --input-position=$SYNC_OFFSET_BYTES --output-position=$SYNC_OFFSET_BYTES --size=$SYNC_LENGTH_BYTES "$SYNC_PEND_PATH" "$SYNC_TARGET"
fi

if [ "$SYNC_ACTION" == "discard" ] then
blkdiscard -o $SYNC_OFFSET_BYTES -l $SYNC_LENGTH_BYTES "$SYNC_TARGET"
fi
done < <(thindiff "$SYNC_VG" "$SYNC_PEND" "$SYNC_BASE")
}

function discard_volume()
{
DISCARD_VG="$1"
DISCARD_LV="$2"
DISCARD_LV_PATH=$(read_lv_dm_path "$DISCARD_VG" "$DISCARD_LV")
if [ "$DISCARD_LV_PATH" != "" ] then
echo "$DISCARD_LV_PATH found"
else
echo "$DISCARD_LV not found in $DISCARD_VG"
exit 1
fi
DISCARD_LV_POOL=$(read_pool_lv $DISCARD_VG $DISCARD_LV)
DISCARD_LV_SIZE=$(read_lv_size "$DISCARD_VG" "$DISCARD_LV")
lvremove -y --quiet "$DISCARD_LV_PATH" || exit 1
lvcreate --thin-pool "$DISCARD_LV_POOL" -V "$DISCARD_LV_SIZE"B --name "$DISCARD_LV" "$DISCARD_VG" || exit 1
}

function backup()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
SOURCE_PEND_LV="$SOURCE_LV$PEND_SUFFIX"
TARGET_PEND_LV="$TARGET_LV$PEND_SUFFIX"
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")
SOURCE_PEND_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_PEND_LV")
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
TARGET_PEND_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_PEND_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "Source base not found creating snapshot of $SOURCE_VG/$SOURCE_LV to $SOURCE_VG/$SOURCE_BASE_LV"
lvcreate --quiet --snapshot --name "$SOURCE_BASE_LV" "$SOURCE_VG/$SOURCE_LV" || exit 1
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
echo "Discarding $SOURCE_BASE_LV_PATH as we need to bootstrap."
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SOURCE_BASE_CHUNK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)
discard_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
sync
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found out of sync with source... removing..."
lvremove -y --quiet $TARGET_BASE_LV_PATH || exit 1
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
sync
fi
fi
SOURCE_BASE_SIZE=$(read_lv_size "$SOURCE_VG" "$SOURCE_BASE_LV")
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_VG/$TARGET_LV not found. Creating empty volume."
lvcreate --thin-pool "$BACKUPS_POOL" -V "$SOURCE_BASE_SIZE"B --name "$TARGET_BASE_LV" "$TARGET_VG" || exit 1
echo "Have to rebootstrap. Discarding source at $SOURCE_BASE_LV_PATH"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SOURCE_BASE_CHUNK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)
discard_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
TARGET_BASE_POOL=$(read_pool_lv $TARGET_VG $TARGET_BASE_LV)
TARGET_BASE_CHUNK_SIZE=$(read_lv_chunk_size $TARGET_VG $TARGET_BASE_POOL)
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
echo "Discarding target at $TARGET_BASE_LV_PATH"
discard_volume "$TARGET_VG" "$TARGET_BASE_LV"
sync
fi
if [ "$SOURCE_PEND_LV_PATH" != "" ] then
echo "$SOURCE_PEND_LV_PATH found removing..."
lvremove -y --quiet "$SOURCE_PEND_LV_PATH" || exit 1
sync
fi
lvcreate --quiet --snapshot --name "$SOURCE_PEND_LV" "$SOURCE_VG/$SOURCE_LV" || exit 1
SOURCE_PEND_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_PEND_LV")
sync
if [ "$TARGET_PEND_LV_PATH" != "" ] then
echo "$TARGET_PEND_LV_PATH found removing..."
lvremove -y --quiet $TARGET_PEND_LV_PATH
sync
fi
lvcreate --quiet --snapshot --name "$TARGET_PEND_LV" "$TARGET_VG/$TARGET_BASE_LV" || exit 1
TARGET_PEND_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_PEND_LV")
SOURCE_PEND_LV_SIZE=$(read_lv_size "$SOURCE_VG" "$SOURCE_PEND_LV")
lvresize -L "$SOURCE_PEND_LV_SIZE"B "$TARGET_PEND_LV_PATH"
activate_volume "$TARGET_VG" "$TARGET_PEND_LV"
echo "Synching $SOURCE_PEND_LV_PATH to $TARGET_PEND_LV_PATH"
thinsync "$SOURCE_VG" "$SOURCE_PEND_LV" "$SOURCE_BASE_LV" "$TARGET_PEND_LV_PATH" || exit 1
sync

TARGET_DATE_SUFFIX=$(suffix)
lvcreate --quiet --snapshot --name "$TARGET_LV$TARGET_DATE_SUFFIX" "$TARGET_VG/$TARGET_PEND_LV" || exit 1
sync
lvremove --quiet -y "$SOURCE_BASE_LV_PATH" || exit 1
sync
lvremove --quiet -y "$TARGET_BASE_LV_PATH" || exit 1
sync
lvrename -y "$SOURCE_VG/$SOURCE_PEND_LV" "$SOURCE_BASE_LV" || exit 1
lvrename -y "$TARGET_VG/$TARGET_PEND_LV" "$TARGET_BASE_LV" || exit 1
sync
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function verify()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "$SOURCE_BASE_LV_PATH not found"
exit 1
fi
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_BASE_LV_PATH not found"
exit 1
fi
activate_volume "$TARGET_VG" "$TARGET_BASE_LV"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
echo Comparing "$SOURCE_BASE_LV_PATH" with "$TARGET_BASE_LV_PATH"
cmp "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH"
echo Done...
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function resync()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "$SOURCE_BASE_LV_PATH not found"
exit 1
fi
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_BASE_LV_PATH not found"
exit 1
fi
activate_volume "$TARGET_VG" "$TARGET_BASE_LV"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SYNC_BLOCK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)

echo Syncronizing "$SOURCE_BASE_LV_PATH" to "$TARGET_BASE_LV_PATH"

CMP_OFFSET=0
while [[ "$CMP_OFFSET" != "" ]] ; do
CMP_MISMATCH=$(cmp -i "$CMP_OFFSET" "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH" | grep differ | awk '{print $5}' | sed 's/,//g' )
if [[ "$CMP_MISMATCH" != "" ]] ; then
CMP_OFFSET=$(( CMP_MISMATCH + CMP_OFFSET ))
SYNC_OFFSET_BYTES=$(( ( CMP_OFFSET / SYNC_BLOCK_SIZE ) * SYNC_BLOCK_SIZE ))
SYNC_LENGTH_BYTES=$(( SYNC_BLOCK_SIZE ))
echo "Synching $SYNC_LENGTH_BYTES bytes at $SYNC_OFFSET_BYTES from $SOURCE_BASE_LV_PATH to $TARGET_BASE_LV_PATH"
ddrescue --quiet --force --input-position=$SYNC_OFFSET_BYTES --output-position=$SYNC_OFFSET_BYTES --size=$SYNC_LENGTH_BYTES "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH"
else
CMP_OFFSET=""
fi
done
echo Done...
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function list()
{
LIST_SOURCE_VG="$1"
LIST_SOURCE_LV="$2"
LIST_TARGET_VG="$BACKUPS"
LIST_TARGET_LV="$LIST_SOURCE_VG-$LIST_SOURCE_LV"
LIST_TARGET_BASE_LV="$LIST_TARGET_LV$SNAP_SUFFIX"
lvs -olv_name | grep "$LIST_TARGET_BASE_LV.$DATE_REGEX"
}

function remove()
{
REMOVE_TARGET_VG="$BACKUPS"
REMOVE_TARGET_LV="$1"
lvremove -y "$REMOVE_TARGET_VG/$REMOVE_TARGET_LV"
sync
}

function removeall()
{
DATE_OFFSET="$3"
FILTER="$(filter "$DATE_OFFSET")"
while read -r SNAPSHOT ; do
remove "$SNAPSHOT"
done < <(list "$1" "$2" | grep "$FILTER")

}

(
COMMAND="$1"
shift

case "$COMMAND" in
"--help")
echo "Help"
;;
"suffix")
suffix
;;
"filter")
filter "$1"
;;
"backup")
wait_lock_or_terminate
backup "$1" "$2"
;;
"list")
list "$1" "$2"
;;
"thindiff")
thindiff "$1" "$2" "$3"
;;
"thinsync")
thinsync "$1" "$2" "$3" "$4"
;;
"verify")
wait_lock_or_terminate
verify "$1" "$2"
;;
"resync")
wait_lock_or_terminate
resync "$1" "$2"
;;
"remove")
wait_lock_or_terminate
remove "$1"
;;
"removeall")
wait_lock_or_terminate
removeall "$1" "$2" "$3"
;;
*)
echo "None.."
;;
esac
) 98>$LOCK_FILE

EOF


מה זה עושה...?מכיל קבוצה של פקודות למניפולציה של צילומי מצב דקים וסנכרון ההבדל בין שתי תמונות דקות שהתקבלו דרך thin_delta להתקן בלוק אחר באמצעות ddrescue ו-blkdiscard.

עוד סקריפט שנכניס ב-cron:

עוד קצת בושה#cat >/root/lvm-thin-backup/cron-daily.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

BACKUP_SCRIPT="$SCRIPT_DIR/lvm-thin-backup.sh"
RETENTION="-60 days"

$BACKUP_SCRIPT backup images linux-dev
$BACKUP_SCRIPT backup images win8
$BACKUP_SCRIPT backup images win8-data
#etc

$BACKUP_SCRIPT removeall images linux-dev "$RETENTION"
$BACKUP_SCRIPT removeall images win8 "$RETENTION"
$BACKUP_SCRIPT removeall images win8-data "$RETENTION"
#etc

EOF


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

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

בואו ניתן את הזכויות:

#chmod +x /root/lvm-thin-backup/cron-daily.sh
#chmod +x /root/lvm-thin-backup/lvm-thin-backup.sh

בוא נבדוק את זה ונשים את זה ב-cron:

#/usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/lvm-thin-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t lvm-thin-backup
#cat /var/log/syslog | grep lvm-thin-backup
#crontab -e
0 3 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/lvm-thin-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t lvm-thin-backup

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

ריצות עוקבות יעתיקו את הנתונים בהדרגה הודות למעקב אחר שינויים באמצעות מטא נתונים דקים של LVM.

בוא נראה מה קרה:

#time /root/btrfs-backup/cron-daily.sh
real 0m2,967s
user 0m0,225s
sys 0m0,353s

#time /root/lvm-thin-backup/cron-daily.sh
real 1m2,710s
user 0m12,721s
sys 0m6,671s

#ls -al /backup/btrfs/back/remote/*
/backup/btrfs/back/remote/boot:
total 0
drwxr-xr-x 1 root root 1260 мар 26 09:11 .
drwxr-xr-x 1 root root 16 мар 6 09:30 ..
drwxr-xr-x 1 root root 322 мар 26 02:00 .@base
drwxr-xr-x 1 root root 516 мар 6 09:39 [email protected]
drwxr-xr-x 1 root root 516 мар 6 09:39 [email protected]
...
/backup/btrfs/back/remote/root:
total 0
drwxr-xr-x 1 root root 2820 мар 26 09:11 .
drwxr-xr-x 1 root root 16 мар 6 09:30 ..
drwxr-xr-x 1 root root 240 мар 26 09:11 @.@base
drwxr-xr-x 1 root root 22 мар 26 09:11 @home.@base
drwxr-xr-x 1 root root 22 мар 6 09:39 @[email protected]
drwxr-xr-x 1 root root 22 мар 6 09:39 @[email protected]
...
drwxr-xr-x 1 root root 240 мар 6 09:39 @[email protected]
drwxr-xr-x 1 root root 240 мар 6 09:39 @[email protected]
...

#lvs -olv_name,lv_size images && lvs -olv_name,lv_size backup
LV LSize
linux-dev 128,00g
linux-dev.base 128,00g
thin-pool 1,38t
win8 128,00g
win8-data 2,00t
win8-data.base 2,00t
win8.base 128,00g
LV LSize
backup 256,00g
images-linux-dev.base 128,00g
images-linux-dev.snap.2020-03-08-10-09-11 128,00g
images-linux-dev.snap.2020-03-08-10-09-25 128,00g
...
images-win8-data.base 2,00t
images-win8-data.snap.2020-03-16-14-11-55 2,00t
images-win8-data.snap.2020-03-16-14-19-50 2,00t
...
images-win8.base 128,00g
images-win8.snap.2020-03-17-04-51-46 128,00g
images-win8.snap.2020-03-18-03-02-49 128,00g
...
thin-pool <2,09t


מה זה קשור לבובות קינון?

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

נ.ב.

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

מקור: www.habr.com