ZFS בהשוואה ל-File Systems אחרים בלינוקס

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

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

בלינוקס כשאתה מכניס דיסק קשיח חדש (בין אם זה ב-Hot Swap או דיסק שהכנסת ואז הפעלת את המחשב) המערכת תכיר אותו מיידית, אבל לא תוכל להשתמש בו מיידית עם ה-File Systems הנוכחיים שקיימים בלינוקס. אתה קודם כל צריך ליצור Partition אחד או יותר (לפי הצורך), או שאתה יכול לשייך את הדיסק למערך RAID כלשהו (אם אתה משתמש במערכת MD). אם אתה משתמש ב-RAID חומרה, תוכל להיכנס למערכת הניהול הפנימית (בין אם זה בהפעלה מחדש וכניסה ל-GUI הבסיסי) או דרך Client שונים שיודעים להתממשק לבקר ה-RAID. מעבר לכך, אם בדיסק קיימים Partitions ואתה מוסיף או מוריד אחד מהם, תצטרך לעשות Reboot על מנת שהמערכת תכיר בשינוי (לפי רד-האט, אין צורך לעשות reboot אם הדיסק הוא ללא Partitions ואתה מוסיף אותם עתה. לשם כך יש את פקודת partprobe).

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

נניח ויש לי מערכת לינוקס שמשתמשת ב-LVM כך ש-use לדוגמא נמצא את Logical Volume אחד, ו-home נמצא על Logical Volume אחר. שניהם נמצאים באותו Volume Group. נניח שמחיצת ה-usr שלי התמלאה אך אני בקושי משתמש במחיצת home ויש שם הרבה מקום. ל-LVM יש פקודות הגדלה והקטנה אולם אינני יכול לשנות ווליום שהוא בסטטוס mounted. אני יכול לבצע unmount ל-home (אם אני אבצע כניסה כ-root מבלי שיהיה לי משתמש פתוח שמשתמש במחיצת home) אבל אינני יכול לבצע unmount ל-usr מכיוון שישנם שרותים שרצים ומשתמשים בו. הדרך היחידה שאוכל לשנות את גודל הווליומים הלוגיים, היא דרך הפעלה מחדש של המערכת עם Live CD כלשהו, לבצע vgchange כדי שיכיר בווליומים ואז לבצע את השינוי ולאחריו שוב reboot כדי שהשינוי יכנס לתוקף ואוכל להשתמש במערכת.

מבחינת File Systems המצב יחסית די טוב בלינוקס. מערכת XFS ו-EXT4 הן טובות ויודעות (בד"כ) להתאושש במקרה שעשו כיבוי והפעלה (או reset) לשרת. אם יש לך קרנל מגירסה 3.7 ומעלה, ויש לך כונני SSD אז ישנה תמיכה ל-TRIM בכל מערכות הקבצים המוכרות כמו ext4, xfs, btrfs, jfs ואפילו ל-vfat, כך שאורך חיי הכוננים  ישאר די ארוך(יחסית).

מכיוון שישנה הפרדה בין File System למה שרץ מתחת (Volume Management, Partitions table), כמעט כל מערכות File systems שקיימות כיום ללינוקס, אינן מתערכות בשכבות מתחת. כך לדוגמא אם אתה מעוניין לבצע snapshots (מומלץ לבצע לפני שדרוגים), תצטרך לפנות ל-LVM (כמובן, אם החלטת להקים מערכת לינוקס בלי LVM, לא תוכל לבצע snapshots אלא אם מדובר במערכת וירטואלית ואז תוכל לבצע snapshot ברמת ה-Hypervisor). המערכת היחידה שכלולה ב-kernel שכן מאפשרת לבצע snapshots היא btrfs.

לינוקס בד"כ רץ על כל מיני חומרות, ואני מעוניין להתייחס ל-2 הקטגוריות העיקריות שבהם משתמשים בלינוקס: תחנות עבודה/Desktop ושרתים ושימוש ב-ZFS כמערכת חלופית למערכות File Systems שמגיעות עם הקרנל.

מבחינת תחנות עבודה – כל עוד יש לך דיסק קשיח יחיד, אתה לא תקבל ביצועים טובים ב-ZFS. גם אם יש לך 2 כוננים לא תקבל ביצועים טובים (בהשוואה ל-xfs, ext4) אלא אם יש לך כונן נוסף מבוסס SSD (גם כונן קטן של כמה עשרות ג'יגה יכול להספיק). למערכת ZFS יש הרבה דברים שהיא מבצעת שמערכות File Systems אחרות לא מבצעות. כך לדוגמא ZFS משתמש ב-checksum על כל פיפס של מידע ומערכות אחרות (למעט btrfs ו-xfs עם קרנל 3.10 וגם זה נמצא ב-experimental). בנוסף, ל-ZFS יש גם תהליכים של "קרצוף" שלא ממש נמצאים ב-file systems אחרים (שוב, למעט btrfs שתיכף אתייחס אליו בנפרד).

מבחינת שרת לעומת זאת, ZFS עוזר יותר מכל file systems אחרים שקיימים ללינוקס (שוב, btrfs יקבל יחס בנפרד). קודם כל, הוא מוזיל עלויות מבחינת חומרה – אתה כבר לא צריך RAID יקר עם סוללת גיבוי, כי ZFS דורש מצב פעילות JBOD, הוא יעשה הכל והוא הוא נותן הרבה יותר יתרונות (הסתכלו בפוסט הראשון – לינק למעלה). רוצה להוסיף דיסקים? זרוק לתוך השרת עוד כמה דיסקים וצור RAIDZ חדש, כל המחיצות על ה-pool יקבלו את המקום ואתה לא תצטרך להילחם ב-LVM (כי אין LVM ב-ZFS). רוצה להחליף דיסקים של 1 טרה ב-2/3/4/6 טרהבייט? (לא דיסקים מבוססים SMR החדשים והזולים!!!) תכניס אחד, תן למערכת לטפל בו, אחרי זה תכניס שני וכו'. אתה גם לא חייב להשתמש בדיסקים גדולים מבוססי SSD בלבד או דיסקים SAS יקרים – אתה יכול להכניס דיסקים מבוססי SATA (כל עוד יש לך לפחות 2 דיסקים קטנים מבוססי SSD כדי לקבל ביצועים) או שאתה יכול להכניס דיסקים SAS ו-SSD. אתה לא מוגבל. (רק כדאי לשים לב שהספק שאתם קונים ממנו את הדיסקים, אינו ספק שרוצה "בדיקות מעבדה" לדיסק תקול לפני שהוא מחליף, לצערי ראיתי מקרה כזה לפני חודש). יחד עם זאת, אם אותו שרת מבצע פעילויות אחרות (הוא שרת DB, שרת אפליקציות או דברים יעודיים וכבדים אחרים חוץ משרותי קבצים) ואין לכם תקציב לשרת קבצים עצמאי – עדיף להשתמש ב-file systems הקיימים בקרנל וב-RAID חומרה. זיכרו – ZFS הוא הרבה יותר מסתם עוד file system.

לגבי btrfs: אורקל, ב"גאונותה" הגדולה, החליטה החלטה שנראה כאילו היא נלקחה מסידרת הקומיקס Dilbert: יש להם את הקוד של ZFS אז במקום לפתוח אותו  ולהמשיך לפתח אותו כדי שהוא יכנס לקרנל של לינוקס, הם החליטו שהם יוצרים משהו חדש – את btrfs. הרעיון מאחורי btrfs הוא רעיון טוב בעקרון – לעשות מה ש-ZFS עושה אבל עם תוספות. כך לדוגמא ב-ZFS יש Quota, ב-btrfs לקחו את זה צעד קדימה ויש גם Quota Groups, דבר יעיל מאוד שיש לך כמה מאות משתמשים בקבוצות שונות ואתה רוצה להגדיר לכל קבוצה Quota בפקודה פשוטה אחת, או פונקציה נחמדה אחרת של snaphots – ב-ZFS הם read only, ב-btrfs אפשר ליצור snapshots שהם read-write ויש עוד פונקציות נחמדות רבות (templates וכו').

אבל הבעיה המרכזית של btrfs היא שזו מערכת שהיא עדיין בשלב של "נסיוני" (experimental). פונקציות חדשות עדיין מתווספות (בקרנל 3.19 האחרון שיצא לדוגמא – התווסף האפשרות לבצע scrub למערכי RAID והחלפת מערכות RAID. על הפוקנציה הראשונה אני עדיין חוכך את פדחתי להבין מדוע צריך אותה – אם scrub אז שיעשה להכל, ולגבי הפונקציה השניה – זה בהחלט טוב בהשוואה ל-ZFS). שום הפצה (טוב, למעט Open SuSE) לא מאפשרת הקמת שרת/Desktop עם btrfs כמערכת ברירת מחדל וכל ההפצות כותבות בפירוש ליד השם btrfs שזה experimental, כך שאם אתה מרים שרת עם btrfs, וזה שרת פרודקשן, תתפלל שזה יהיה יציב ועדיף שתכיר ממש טוב את btrfs ובמיוחד את btrfs-rescue. במקרה כזה אם החלטת ללכת "על הקצה", עדיף שההפצת לינוקס עצמה תהיה מותקנת ב-xfs ושאר התכנים יהיו ב-btrfs, כך לפחות תוכל לעבוד עם הלינוקס עצמו ללא צורך ב-live CD כלשהו.

אם אתם רוצים להשתמש ב-btrfs כמערכת file system מרכזית על דסקטופ/לאפטופ שלכם, אני ממליץ בחום להשתמש בהפצת לינוקס שהיא Rolling Release (כמו Open SuSE), כך לפחות תקבלו גירסאות core-utils יותר מעודכנות וגרסאות קרנל חדשות עם תיקוני באגים ל-btrfs.

בשביל ש-btrfs יהיה טוב לשרתים, יצטרכו קודם כל באורקל לבצע feature freeze עם הקוד (מה שעדיין לא קורה, תסתכלו בחדשות wiki של btrfs) ואז להתחיל לטפל בבאגים (ויש באגים מסמרי שיער! rsync כבד עם קרנל שהוא פחות מ-3.16 גורם ל-deadlock עם btrfs, ויש עוד כמה Gotchas למיניהם, ונכון לאתמול – יש גם memory leaks, הידד!) ואז יצטרכו המון טסטים כדי שזה יעבוד בצורה ממש יציבה, וכאן מדובר על טסטים הרבה יותר מורכבים ממה שהיה ל-ext3/ext4/xfs כי כמו ZFS, גם btrfs היא לא רק מערכת file-system. אני מאמין שזה יקח בין שנה לשנתיים.

עוד מערכת קבצים שלא כל כך התייחסתי אליה אבל כדאי להכיר אותה (במיוחד לדסקטופ/לאפטופ עם כונני SSD) היא מערכת F2FS שסמסונג פיתחה וכיום מפותחת גם ע"י אחרים. היא לא מתאימה לשרתים והיא עדיין נסיונית, אבל מצד שני יש לה ביצועים לא רעים בכלל ופונקציונאליות בהחלט מעניינת (כמו rollback ו-fitrim), תוכלו לראות Benchmarks בהשוואה לאחרים כאן.

ועוד משהו קטן שדווקא לא קשור ללינוקס אלא למתחרים – למיקרוסופט. גם הם ראו את ZFS ו-btrfs וגם להם יש תשובה (אם כי לא מומלץ לאיש סיסטם Windows להשתמש כרגע בפתרון הנ"ל אלא אם הוא מעוניין בפיטורין..) – וזה ה-ReFS, אם כי בהשוואה ל-btrfs ו-ZFS, חסרים לה פונקציות כמו דחיסה, Deduplication, COW.

אסכם את הדברים כך: לכל file system יש יתרונות וחסרונות. אני ממליץ לשקול את כל האפשרויות שזה מגיע לשרתי קבצים בפרודקשן, במיוחד כשזה מגיע לעניין של ברזלים ותקציבים וגם השיקול הקטן של לילות לבנים כשחטפתם deadlock או כל תקלה אחרת. קחו בחשבון גם שיקולים (שלצערי חלק מהאנשים שוכחים) כמו מה אתם הולכים לאחסן (אם לדוגמא יש לכם תיקיה עם כמה מאות אלפי או מיליוני קבצים, ללכת על ext4 לדוגמא זה רעיון גרוע), מה היעוד של מערכת הקבצים ומול מה היא מתחברת, האם יש דברים כמו thin provisioning קל לביצוע, האם המערכת יודעת לדאוג ולטפל בדיסקים, האם ההגדלה שלה כרוכה בהשבתות או שניתן לבצע דברים Online, האם קל לגבות מערכת חיה, ועוד דברים.

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

Comments

comments

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *