באביב הזה כבר דנו בכמה נושאי מבוא, למשל, כיצד לבדוק את מהירות הכוננים שלך и מה זה RAID. בשנייה שבהן, אפילו הבטחנו להמשיך ללמוד את הביצועים של טופולוגיות ריבוי דיסקים שונות ב-ZFS. זוהי מערכת הקבצים מהדור הבא המיושמת כעת בכל מקום: מ תפוח עץ до אובונטו.

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

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

Zpool, vdev ומכשיר

דיאגרמת המאגר המלאה הזו כוללת שלושה vdevs עזר, אחד מכל מחלקה, וארבעה עבור RAIDz2

בדרך כלל אין סיבה ליצור מאגר של סוגים וגדלים של vdev לא תואמים - אבל אין שום דבר שמפריע לך לעשות זאת אם תרצה בכך.

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

zpool

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

היתירות של ZFS היא ברמת המכשיר הוירטואלי, לא ברמת הבריכה. אין שום יתירות ברמת הבריכה - אם אבד כונן vdev או vdev מיוחד, אז כל הבריכה אובדת יחד איתו.

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

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

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

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

vdev

כל מאגר אחסון מורכב ממכשיר וירטואלי אחד או יותר (מכשיר וירטואלי, vdev). בתורו, כל vdev מכיל מכשיר אמיתי אחד או יותר. רוב המכשירים הווירטואליים משמשים לאחסון נתונים פשוט, אבל יש כמה מחלקות vdev helper, כולל CACHE, LOG ו-SPECIAL. לכל אחד מסוגי vdev אלה יכולה להיות אחת מחמש טופולוגיות: התקן בודד (התקן בודד), RAIDz1, RAIDz2, RAIDz3 או מראה (מראה).

RAIDz1, RAIDz2 ו- RAIDz3 הם זנים מיוחדים של מה שהטיימרים הוותיקים יקראו RAID זוגיות כפולה (אלכסונית). 1, 2 ו-3 מתייחסים לכמה בלוקים זוגיות מוקצים לכל רצועת נתונים. במקום דיסקים נפרדים לצורך זוגיות, התקנים וירטואליים של RAIDz מפיצים את הזוגיות הזו באופן חצי שווה בין הדיסקים. מערך RAIDz יכול לאבד דיסקים רבים כמו שיש לו בלוקים זוגיים; אם הוא יאבד עוד אחד, הוא יתרסק וייקח איתו את בריכת האחסון.

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

VDEV בודדים מסוכנים מטבעם. מכשיר וירטואלי כזה לא ישרוד כשל אחד - ואם הוא משמש כאחסון או כ-vdev מיוחד, אזי כישלון שלו יוביל להרס של הבריכה כולה. היו מאוד מאוד זהירים כאן.

ניתן ליצור CACHE, LOG ו-SPECIAL VAs באמצעות כל אחת מהטופולוגיות הנ"ל - אך זכור כי אובדן SPECIAL VA פירושו אובדן הבריכה, כך שטופולוגיה מיותרת מומלצת מאוד.

מכשיר

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

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

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

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

נניח שאתה רוצה לשים שרת על שמונה דיסקים ומתכננים להשתמש בדיסקים של 10 TB (~9300 GiB) - אבל אתה לא בטוח איזו טופולוגיה הכי מתאימה לצרכים שלך. בדוגמה שלמעלה, אנו בונים מאגר בדיקות מקבצים דלילים בשניות - ועכשיו אנו יודעים ש-RAIDz2 vdev של שמונה דיסקים של 10 TB מספק 50 TiB של קיבולת שמישה.

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

לאחר התחברות ל-vdev המושפע, המכשיר הרזרבי מתחיל לקבל עותקים או שחזורים של הנתונים שאמורים להיות במכשיר החסר. ב-RAID המסורתי זה נקרא בנייה מחדש, בעוד שב-ZFS זה נקרא resilvering.

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

מערכי נתונים, בלוקים ומגזרים

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

מערך נתונים (מערך נתונים)

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

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

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

קודם כל, למערך נתונים יכולה להיות מכסה מוקצית. אם מוגדר zfs set quota=100G poolname/datasetname, אז לא תוכל לכתוב לתיקיה המורכבת /poolname/datasetname יותר מ-100 GiB.

שמים לב לנוכחות - והיעדר - של צלזים בתחילת כל שורה? לכל מערך נתונים יש מקום משלו הן בהיררכיית ZFS והן בהיררכיית הרכבת המערכת. אין לוכסן מוביל בהיררכיית ZFS - אתה מתחיל עם שם המאגר ולאחר מכן הנתיב ממערך נתונים אחד למשנהו. לדוגמה, pool/parent/child עבור מערך נתונים בשם child תחת מערך הנתונים האב parent בבריכה עם שם יצירתי pool.

כברירת מחדל, נקודת ההרכבה של מערך הנתונים תהיה שוות ערך לשמו בהיררכיית ZFS, עם קו נטוי מוביל - המאגר בשם pool רכוב כמו /pool, מערך נתונים parent רכוב פנימה /pool/parent, ואת מערך הנתונים של הילד child רכוב פנימה /pool/parent/child. עם זאת, ניתן לשנות את נקודת ההרכבה של מערכת הנתונים.

אם נפרט zfs set mountpoint=/lol pool/parent/child, ואז מערך הנתונים pool/parent/child מותקן על המערכת כ /lol.

בנוסף למערכי נתונים, עלינו להזכיר כרכים (zvols). אמצעי אחסון זהה בערך למערך נתונים, פרט לכך שאין לו למעשה מערכת קבצים - זה רק התקן בלוק. אתה יכול, למשל, ליצור zvol עם שם mypool/myzvol, לאחר מכן פרמט אותו עם מערכת קבצים ext4, ולאחר מכן התקן את מערכת הקבצים הזו - כעת יש לך מערכת קבצים ext4, אבל עם כל תכונות האבטחה של ZFS! זה אולי נראה טיפשי במכונה בודדת, אבל הרבה יותר הגיוני בתור קצה עורפי בעת ייצוא התקן iSCSI.

בלוקים

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

אנחנו באמת באמת לא מתלוצץ על עונש הביצוע העצום אם תגדיר הסט קטן מדי

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

אלא אם צוין אחרת, גודל רשומות ברירת המחדל הנוכחי הוא 128 KiB. זה סוג של טרייד-אוף מסובך שבו הביצועים לא מושלמים, אבל זה גם לא נורא ברוב המקרים. Recordsize ניתן להגדיר לכל ערך מ-4K עד 1M (עם הגדרות מתקדמות recordsize אתה יכול להתקין אפילו יותר, אבל זה רק לעתים רחוקות רעיון טוב).

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

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

ל-Zvols אין נכס recordsize - במקום זאת יש להם נכס שווה ערך volblocksize.

מגזרים

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

למערכת ZFS יש מאפיין המאפשר לך להגדיר באופן ידני את גודל הסקטור. הנכס הזה ashift. באופן קצת מבלבל, אשיפט הוא כוח של שניים. לדוגמה, ashift=9 פירושו גודל מגזר של 2^9, או 512 בתים.

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

משמעות הדבר היא שמנהל ZFS מומלץ מאוד לדעת את גודל הסקטור האמיתי של המכשירים שלהם ולהגדיר באופן ידני ashift. אם ה-shift מוגדר נמוך מדי, מספר פעולות הקריאה/כתיבה גדל מבחינה אסטרונומית. אז, כתיבת "מגזרים" של 512 בתים לתוך מגזר אמיתי של 4 KiB פירושה צורך לכתוב את "המגזר" הראשון, ואז לקרוא את המגזר של 4 KiB, לשנות אותו עם "מגזר" שני של 512 בתים, לכתוב אותו בחזרה למגזר החדש מגזר 4 KiB וכן הלאה עבור כל כניסה.

בעולם האמיתי, עונש כזה פוגע בכונני SSD של Samsung EVO, שעבורם ashift=13, אבל כונני ה-SSD האלה משקרים לגבי גודל הסקטור שלהם, ולכן ברירת המחדל מוגדרת ל ashift=9. אם מנהל מערכת מנוסה לא משנה את ההגדרה הזו, ה-SSD הזה עובד איטי יותר HDD מגנטי קונבנציונלי.

לשם השוואה, לגודל גדול מדי ashift אין כמעט עונש. אין עונש אמיתי לביצועים, והגידול בשטח שאינו מנוצל הוא אינסופי (או אפס כאשר דחיסה מופעלת). לכן, אנו ממליצים בחום להתקין אפילו כוננים שמשתמשים בסקטורים של 512 בתים ashift=12 או אפילו ashift=13להתמודד עם העתיד בביטחון.

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

מנגנון העתקה על כתיבה

אם מערכת קבצים רגילה צריכה להחליף נתונים, היא משנה כל בלוק היכן שהוא נמצא

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

בפשטות, אם נתעלם מהמיקום הפיזי האמיתי של הבלוקים, אז "שביט הנתונים" שלנו מפושט ל"תולעת נתונים" שנעה משמאל לימין על פני מפת השטח הזמין

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

מנגנון העתק בכתיבה (CoW) הוא הבסיס הבסיסי למה שהופך את ZFS למערכת כה מדהימה. הרעיון הבסיסי הוא פשוט - אם תבקש ממערכת קבצים מסורתית לשנות קובץ, היא תעשה בדיוק מה שביקשת. אם תבקש ממערכת קבצים העתקה על כתיבה לעשות את אותו הדבר, היא תגיד "בסדר" אבל תשקר לך.

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

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

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

ZIL: יומן כוונת ZFS

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

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

SLOG, או מכשיר LOG משני, הוא רק Vdev מיוחד - ורצוי מהיר מאוד - שבו ניתן לאחסן את ה-ZIL בנפרד מהאחסון הראשי

לאחר התרסקות, כל הנתונים המלוכלכים ב-ZIL מושמעים מחדש - במקרה זה, ZIL נמצא ב-SLOG, אז הוא מושמע מחדש משם

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

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

ZFS מטפל בכתיבה סינכרונית בצורה שונה ממערכות קבצים רגילות - במקום לחייב אותן מיד לאחסון רגיל, ZFS מחייב אותן לאזור אחסון מיוחד הנקרא ZFS Intent Log, או ZIL. החוכמה היא שהרשומות האלה גם להישאר בזיכרון, להצטבר יחד עם בקשות כתיבה א-סינכרוניות רגילות, כדי להיסחף מאוחר יותר לאחסון כ-TXG רגילים לחלוטין (Transaction Groups).

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

אם ZFS נכשל - קריסת מערכת הפעלה או הפסקת חשמל - בזמן שיש נתונים ב-ZIL, הנתונים האלה ייקראו במהלך ייבוא ​​הבריכה הבא (לדוגמה, כאשר מערכת החירום מופעלת מחדש). כל דבר ב-ZIL ייקרא, יקובץ ל-TXGs, יתחייב לאחסון הראשי, ולאחר מכן ינותק מה-ZIL במהלך תהליך הייבוא.

אחת ממחלקות העזר vdev נקראת LOG או SLOG, ההתקן המשני של LOG. יש לזה מטרה אחת - לספק לבריכה VDV נפרד, ועדיף הרבה יותר מהיר, עמיד מאוד בכתיבה לאחסון ה-ZIL, במקום לאחסן את ה-ZIL בחנות ה-vdev הראשית. ה-ZIL עצמו מתנהג אותו הדבר לא משנה היכן הוא מאוחסן, אבל אם ל-LOG vdev יש ביצועי כתיבה גבוהים מאוד, הכתיבה הסינכרונית תהיה מהירה יותר.

הוספת vdev עם LOG לבריכה לא עובדת לא יכול שפר את ביצועי הכתיבה הא-סינכרונית - גם אם תכריח את כל הכתיבה ל-ZIL עם zfs set sync=always, הם עדיין יהיו מקושרים לאחסון הראשי ב-TXG באותו אופן ובאותו קצב כמו ללא היומן. שיפור הביצועים הישיר היחיד הוא ההשהיה של כתיבה סינכרונית (כי יומן מהיר יותר מאיץ את הפעולות). sync).

עם זאת, בסביבה שכבר דורשת הרבה כתיבה סינכרונית, vdev LOG יכול להאיץ בעקיפין כתיבה אסינכרונית וקריאה שאינה מאוחסנת במטמון. הורדת ערכי ZIL ל-vdev LOG נפרד פירושה פחות מחלוקת עבור IOPS באחסון ראשי, מה שמשפר את הביצועים של כל הקריאה והכתיבה במידה מסוימת.

תצלומים

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

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

שכפול

ספריית Steam שלי בשנת 2015 הייתה 158 GiB וכללה 126 קבצים. זה די קרוב למצב האופטימלי עבור rsync - שכפול ZFS ברשת היה מהיר יותר "רק" ב-927%.

באותה רשת, שכפול קובץ תמונת מחשב וירטואלי יחיד בנפח 40GB של Windows 7 הוא סיפור אחר לגמרי. שכפול ZFS מהיר פי 289 מ-rsync - או מהיר יותר "רק" פי 161 אם אתה חכם מספיק לקרוא ל-rsync עם --inplace.

כאשר תמונת VM עוברת קנה מידה, rsync מוציא איתה קנה מידה. 1,9 TiB הוא לא כל כך גדול עבור תמונת VM מודרנית - אבל הוא מספיק גדול כדי שכפול ZFS מהיר פי 1148 מ-rsync, אפילו עם הארגומנט --inplace של rsync

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

הדברים הופכים אפילו יותר מעניינים בשנייה zfs send. יש לנו כעת שתי מערכות, שכל אחת מכילה poolname/datasetname@1, ואתה מצלם תמונת מצב חדשה poolname/datasetname@2. לכן, בבריכה המקורית שיש לך datasetname@1 и datasetname@2, ובבריכת המטרה עד כה רק תמונת המצב הראשונה datasetname@1.

מכיוון שיש לנו תמונת מצב משותפת בין המקור למטרה datasetname@1, אנחנו יכולים לעשות את זה מצטבר zfs send מעל זה. כשאנחנו אומרים למערכת zfs send -i poolname/datasetname@1 poolname/datasetname@2, הוא משווה בין שני עצי מצביע. כל מצביע שקיים רק ב @2, כמובן מתייחסים לבלוקים חדשים - אז אנחנו צריכים את התוכן של הבלוקים האלה.

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

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

דחיסה מובנית

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

אם ניקח בחשבון פיסת נתונים באמצע קובץ שמתחיל את החיים כמגה-בייט של אפסים מ-0x00000000 וכן הלאה, קל מאוד לדחוס אותו למגזר אחד בדיסק. אבל מה קורה אם נחליף את המגה-בייט הזה של אפסים במגה-בייט של נתונים בלתי-דחוסים כמו JPEG או רעש פסאודו-אקראי? באופן בלתי צפוי, מגה-בייט זה של נתונים ידרוש לא אחד, אלא 256 4 KiB סקטורים, ובמקום זה בדיסק רק מגזר אחד שמור.

ל-ZFS אין בעיה זו, מכיוון שרשומות שהשתנו נכתבות תמיד לשטח שאינו בשימוש - הבלוק המקורי תופס רק סקטור אחד של 4 KiB, והרשומה החדשה יתפוס 256, אבל זו לא בעיה - קטע ששונה לאחרונה מה-" middle" של הקובץ ייכתב לשטח שאינו בשימוש ללא קשר אם הגודל שלו השתנה או לא, כך שעבור ZFS זהו מצב די רגיל.

דחיסת ZFS מקורית מושבתת כברירת מחדל, והמערכת מציעה אלגוריתמים ניתנים לחיבור - נכון לעכשיו LZ4, gzip (1-9), LZJB ו-ZLE.

• LZ4 הוא אלגוריתם סטרימינג המציע יתרונות דחיסה ופירוק וביצועים מהירים במיוחד עבור רוב מקרי השימוש - אפילו במעבדים איטיים למדי.
• GZIP הוא אלגוריתם מכובד שכל משתמשי יוניקס מכירים ואוהבים. ניתן ליישם אותו עם רמות דחיסה 1-9, כאשר יחס הדחיסה והשימוש ב-CPU גדל ככל שהוא מתקרב לרמה 9. האלגוריתם מתאים לכל מקרי שימוש בטקסט (או אחרים בעלי דחיסה גבוהה), אך בדרך כלל גורם לבעיות ב-CPU - השתמש בו בזהירות, במיוחד ברמות גבוהות יותר.
• LZJB הוא האלגוריתם המקורי ב-ZFS. הוא הוצא משימוש ואין להשתמש בו יותר, ה-LZ4 עולה עליו בכל מובן.
• ZLE - קידוד ברמה אפסית, קידוד ברמה אפסית. הוא אינו נוגע כלל בנתונים רגילים, אלא דוחס רצפים גדולים של אפסים. שימושי עבור מערכי נתונים בלתי ניתנים לדחיסה לחלוטין (כגון JPEG, MP4 או פורמטים אחרים שכבר דחוסים) מכיוון שהוא מתעלם מנתונים בלתי ניתנים לדחיסה אך דוחס שטח שאינו בשימוש ברשומות המתקבלות.

אנו ממליצים על דחיסת LZ4 כמעט לכל מקרי השימוש; עונש הביצועים בעת מפגש עם נתונים בלתי ניתנים לדחיסה הוא קטן מאוד, ו צְמִיחָה ביצועים עבור נתונים טיפוסיים הם משמעותיים. העתקת תמונת מכונה וירטואלית להתקנה חדשה של מערכת ההפעלה Windows (מערכת הפעלה מותקנת לאחרונה, עדיין אין נתונים בפנים) עם compression=lz4 עבר 27% מהר יותר מאשר עם compression=noneבתוך מבחן זה בשנת 2015.

ARC - מטמון חלופי אדפטיבי

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

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

כל מערכות ההפעלה המודרניות המוכרות, כולל MacOS, Windows, Linux ו-BSD, משתמשות באלגוריתם LRU (Least Recently Used) כדי ליישם את מטמון העמודים. זהו אלגוריתם פרימיטיבי שדוחף את הבלוק השמור "למעלה התור" לאחר כל קריאה, ודוחף את הבלוקים "למטה בתור" לפי הצורך כדי להוסיף פספוסי מטמון חדשים (בלוקים שהיו צריכים להיקרא מהדיסק, לא מהמטמון) לְמַעלָה.

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

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

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

מסקנה

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

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

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

מקור: www.habr.com