כמה מילים על ZFS (לשנת 2018)

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

כיום, אם חברה מסויימת רוצה לרכוש לעצמה סטורג' כפתרון קצה – היא בהחלט יכולה וישנם פתרונות טובים בשוק שיתנו לכם קופסא עם דיסקים, חיבורי רשת מאחורה, מערכת Appliance שרצה בתוך הקופסא עם ממשק WEB ו-CLI ועם פונקציונאליות בהתאם למחיר ולרשיון שרכשתם. פעם היו EMC, NetApp הכי פופולריים, היום יש מגוון שלם של מוצרים מוכנים – רק להרכיב, להגדיר מספר דברים מצומצם וקדימה – אפשר לעבוד עם הפתרון, ואלו פתרונות שיכולים להתאים לרוב החברות והעסקים.

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

להלן צילום מסך מ-vSphere client בגירסה 5.5, כאשר מגדירים LUN חדש ובוחרים את ה-Block Size (לחצו להגדלה):

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

במקרה לעיל, לא חשוב איזה Storage יש לך, מהרגע שהגדרת iSCSI LUN בסטורג', לסטורג' אין מושג ירוק מה אתה הולך לעשות איתו. מבחינתו זה Block ולך תשבור את הראש מה לעשות ואיך להגדיר ואיך לעשות אופטימיזציה לו ב-Initiator שלך.

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

אבל מה קורה אם אנחנו רוצים לבנות פתרון סטורג' משלנו ואנחנו מעוניינים לעשות לו אופטימיזציה ולא להיות "שבויים" באיזה פתרון שלא מאפשר לנו להגדיר דברים לעומק? אם אנחנו בונים עם לינוקס מערכת כזו עם File System כמו XFS או EXT4, מאותו הרגע שחילקנו את הדיסק עם או בלי LVM, ואנחנו מפרמטים את כל מערך ה-RAID בזמן ההתקנה, אז כבר אי אפשר לשנות את גודל הבלוקים. ב-XFS לדוגמא, ברירת המחדל היא להגדיר בלוקים בגודל 4K כל בלוק, אבל אם אנחנו הולכים לאחסן רק קבצים שרובם בגודל מס' ג'יגהבייטים, אנחנו נפסיד מהירות.

לעומת זאת ב-ZFS, גם אחרי ששייכנו את כל הדיסקים ל-Pool מסויים, אנחנו תמיד יכולים להגדיר את גודל הבלוקים (ב-ZFS זה נקרא record size) גם אחרי יצירת ה-Pool ויצירת Dataset (חשוב כמובן לשים לב שאם יצרנו Dataset ואנחנו מגדירים לו record size חדש, רק הקבצים החדשים יקבלו את גודל ה-record size החדש, לא הקבצים הישנים) כפי שניתן לראות לדוגמא כאן. (אגב, זה דבר שמאוד עוזר עם MySQL לדוגמא, אתם מוזמנים להציץ כאן)

נקודה נוספת וחשובה היא כמובן הדיסקים. ישנם עדיין מקרים רבים שיש שרתים פיזיים שמריצים אפליקציות מסויימות על דיסקים מקומיים עם כרטיס RAID הכולל זכרון Cache וסוללה, אך עם הדיסקים החדשים שיש כיום שמחירם יורד כל הזמן, יהיו לא מעט חברות שישמחו לקנות דיסקים בגודל 6,8,10,12 או אפילו 14 טרה בייט ויחברו אותם לבקר ה-RAID וכך הם יקבלו כמות אחסון מכובדת, אך יש בעיה מרכזית אחת: כל דיסק מעל גודל 4 או 6 טרהבייט שנדפק ומוחלף, יאיט אוטומטית את הביצועים של כל מערך הדיסקים לזמן רב (זה יכול לקחת ימים או במקרים של דיסקים גדולים כמו 10,12,14 טרהבייט – אפילו שבועות!) מהסיבה הפשוטה שבקר דיסקים הוא דבר די טיפש, הוא יודע לקרוא בלוקים, אבל הוא לא יודע מה יש בבלוקים, כך שבקר ה-RAID מבצע rebuild, הוא יעתיק את כל הבלוקים, גם אם 60% מהדיסק הוא בכלל ריק! לעומת זאת ב-ZFS אם נדפק דיסק והחלפנו אותו, מערכת ה-ZFS תשחזר (מה שנקרא: resilver) רק את הקטעים שלא קיימים בדיסק החדש, כך שה-rebuild יהיה הרבה יותר קצר והמערכת תשוב לאיתנה במהירות הרבה יותר גבוהה מאשר בתהליך rebuild של כרטיס RAID.

חסרונות נוסף שקיימים ל-XFS ול-EXT4 הם לדוגמא:

  • אין בדיקת קבצים מתמשכת. ב-ZFS לכל קובץ יש checksum כך ש-ZFS יודע בדיוק אם מה שהוא קרא תקין או לא ואם לא הוא יטפל בבעיה אוטומטית בכך שהוא יעביר את הנתונים למקום אחר (בערך כמו שבקר SSD טוב עושה) ול-ZFS ישנו גם תהליך scrubbing שעובר אחת לכמה ימים על כל הקבצים בדיסקים לבדוק זאת ולטפל בתקלות באופן אוטומטי. ב-XFS וב-EXT4 יש לך Journal שיכול לעזור בקריסת המכונה, אך זהו פתרון שאינו מספק על מנת לשמור על הנתונים.
  • ב-EXT4 וב-XFS אין מנגנונים לניצול משאבי המכונה מבחינת זכרון. כן, ללינוקס יש שימוש מתוחכם בזכרון החופשי לשם Cache מסוגים שונים, אבל ב-ZFS יש את ARC שלוקח כברירת מחדל מחצית מהזכרון של המערכת להאצת ביצועי דיסק בכך שהוא משתמש באותו זכרון שהוא "גזר" בהתחלה, וכידוע – זכרון RAM הוא הדבר הכי מהיר שיש, יותר מכל SSD שקיים בשוק.
  • שימוש מושכל ב-SSD וב-NVME: עם מערכת כמו bcache או fastcache (לאלו שאוהבים לחיות על הקצה) יכול להיות פתרון די טוב על מנת להאיץ ביצועים של דיסקים מכניים, אך ב-ZFS יש לך 3 מנגנונים שמטפלים בכך:
    • מנגנון ה-ARC (שמשתמש כברירת במחצית הזכרון של המכונה לשם CACHE מהיר)
    • מנגנון ה-ZIL (להאצת ביצועים וטרנזאקציות של קבצים קטנים ורישומי הפניות להיכן קבצים נכתבים, אפשר לקרוא על כך כאן)
    • מנגנון ה-L2ARC – כאן בד"כ יהיה SSD מהיר ששומר עותקים של קבצים שניגשים אליהם בתכיפות גבוהה.
  • מערכת ZDB – לכל File system יש כלים משלו (tune2fs ל-EXT3/EXT4 לדוגמא או ערימת הכלים הזו ל-XFS), אבל ZDB לוקח את זה כמה צעדים קדימה – לבדיקה האם יש Cache אופטימלי, לבדיקה של ביצועים פר דיסק, בדיקות והגדרות ל-B-TREE (כן, ZFS שומר את הקבצים ב-B-Tree) ועוד המון דברים. ZDB הוא ה"אולר השוויצרי" ל-ZFS ועבודה איתו יכולה לתת ביצועים שעוקפים מרחוק כל File System לינוקסי.

יחד עם זאת ל-ZFS יש עדיין חסרונות (שיטופלו בשנה הקרובה):

  • הוספת דיסקים: לא, אתה לא יכול להוסיף עוד דיסק אחד אלא 2 ומעלה. גם החלפת דיסקים קיימים בדיסקים יותר גדולים היא לא בדיוק פיקניק כרגע (אבל זה אפשרי). במהלך 2019 יתווסף קוד להוספה דיסקים – אפילו דיסק בודד כמעט מבלי שנצטרך להתמודד עם איטיות של פריסת DATA מחדש (יועתקו מספר בלוקים בודדים וזהו).
  • עבודה עם SSD – אחד החלקים היותר נחמדים ב-SSD זו פקודת trimfs שאומרת ל-SSD לבצע פקודת TRIM ב-SSD. ב-ZFS יש תמיכה ל-Trim אך היא אינה אוטומטית בגירסת ZFS ללינוקס. יש Pull request שיכול לעבוד ברוב המקרים בגירסה הנוכחית היציבה של ZFS ללינוקס, ובגירסת ה-Master זה עובד בצורה טובה. אני מאמין שבחודשים הקרובים זה יוכנס פנימה.

לסיכום: אפשר להקים שרת ZFS תוך דקות ספורות על מכונה חדשה. יוצרים pool עם תצורת RAIDZ רצויה, מחלקים דיסק SSD ל-2 פרטישנים (אחד log ואחד cache, ככלל עדיף 2 SSD שיעבדו כ-Mirror), מצמידים אותם ל-pool ויאללה – יש מערכת ZFS עובדת. העניין הוא שאם אתה רוצה ביצועים מעולים, תצטרך להשקיע זמן בהגדרות דברים לפי מה שרוצים להריץ ומה ה-ZFS צריך לשרת (ואני ממליץ את הספר הזה ל-ZFS על לינוקס, או את הספרון הזה). האם ZFS הוא פתרון חלופי לסטורג' סגור – במקרים מסויימים כן ובמקרים מסויימים לא (תלוי בדרישות ובצרכים), אבל הוא מאוד מתאים אם חברה מחליטה להקים סטורג' קטן והיא מוכנה להשקיע את שעות העבודה כדי לבצע אופטימיזציה וזה לוקח זמן (לפי הידע של מי שמבצע זאת), זה לא משהו שנעשה בחצי יום, וצריך לעיתים להקים מערכת שלמה כדי להגדיר לבדוק את הביצועים.

הסטטוס של ZFS החופשי

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

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

בחודש יולי שנה שעברה שוחררה גירסת 0.7.0 עם ערימות של תיקונים ופונקציונאליות חדשה שתוכלו לקרוא עליה כאן. חלק מהפונקציות ישמעו טריוויאליות לחלוטין אך צריך לזכור שכש-SUN שחררה את ZFS לפני 13 שנה, לקוד לא היה שום קשר ללינוקס, הכל היה בנוי ל-Solaris בלבד ובכל הקשור לתמיכה בחומרה, היתה תמיכה במה שסולאריס תמך, או בקיצור – למעט הפצות סולאריס פתוחות, הקוד לא רץ בצורה אופטימלית עם תמיכה טובה לאף מערכת לינוקס או BSD וכך כל צוות של מערכת הפעלה היה צריך לממש פונקציונאליות של ZFS עם תמיכת חומרה של אותה מערכת הפעלה. בלינוקס זה לקח זמן וסוף סוף בגירסה 0.7.0 יש תמיכת "ברזלים" טובה. כך לדוגמא, אם יש לך מערך של 6 דיסקים, הגדרת 5 דיסקים ל-RAIDZ כלשהו והגדרת דיסק כ-hot-spare והתקלקל דיסק, המערכת אוטומטית משתמשת בדיסק הנוסף שהוגדר hot-spare מבלי שאף אחד ירגיש במשהו.

פונקציונאליות נוספות מעניינות:

  • הקץ לשרשור פקודות בשליחת/קבלת snapshots! שימוש בפרמטר c- וה-snapshot יהיה דחוס בשליחה ובקבלה.
  • תמיכה מלאה בפונקציות SSE2 ואחרים של המעבדים, כך ששימוש בדחיסה יעשה עם הפונקציות הללו במקום הפונקציות הרגילות כך שהפעילות תהיה הרבה יותר מהירה.
  • Compressed ARC – זה אחת הפונקציות שממש אהבתי! אם לדוגמא ניקח מכונה ממוצעת שנריץ עליה ZFS, אז בברירת המחדל ZFS ישתמש לשם Cache (כ-ARC) במחצית הזכרון (זה כמובן ניתן לשנות), כך שאם במכונה יש לדוגמא 32 ג'יגהבייט זכרון, ה-ARC ישתמש ב-16 ג'יגהבייט. עם Compressed ARC, ה-ZFS כביכול "מכפיל" את ה-ARC להיות 32 ג'יגהבייט בכך שהוא דוחס את ה-ARC ופורס דינמית תוך כדי שהוא משתמש בליבות המכונה והמהירות היא מדהימה – הדחיסה/פריסה עובדים במהירות של 1-2 ג'יגהבייט לשניה פר ליבה (תלוי כמה ליבות יש). פתאום הביצועים יותר טובים 🙂
  • המשכיות send/recieve. שלחת snapshot ועצרת באמצע או שהיתה לך תקלת תקשורת. מעתה אפשר להמשיך את הסשן במקום להתחיל מחדש. מעולה למצב שהתקשורת בין DC ל-DC היא לא משהו עקב … חברת תקשורת מסויימת.
  • הקפאת "קרצוף" (scrub). סיטואציה שאישית אני סבלתי ממנה: אני מכין ללקוח הדגמת PoC אצלי בבית, רק שבדיוק ה-scrub נזכר "שבת היום" – והוא מתחיל לבצע "קרצוף" והביצועים נוחתים ב-80%. מעתה ניתן להקפיא את ה"קרצוף" ובסיום העבודה לחדש אותו.
  • קריפטוגרפיה יותר רצינית. עכשיו יש תמיכה ב-SHA-512, Skein, Edon-R כ-Checksum על כל בלוק וכו' (קחו בחשבון שדבר כזה מומלץ להפעלה אם יש לכם מעבדי Xeon V3 ומעלה)
  • "אני המחליט" – כחלק מתהליך ה"ריפוי עצמי" של ZFS, מעתה ZFS יכול להחליט אוטומטית מתי דיסק גרוע, להשבית אותו ולבצע rebuild לדיסק אחר. (בשלב הבא הבא הוא יצווה עליך להוציא שליח שיביא דיסק חדש 🙂 )
  • הסוף לשימוש ב-sudoers עבור דברים טריוויאליים – פקודות zpool, zfs וכו' שאינן משנות דברים ניתן מעתה לעשות ע"י משתמש רגיל ובכך להדק יותר את האבטחה.
  • ויש עוד פונקציות חדשות, כנסו ללינק לעיל.

מאז גירסה 0.7.0 תוקנה המון וכיום יש 0.7.5. גירסה 0.7.6 תצא בקרוב עם שיפור מהירות ה-ARC ועוד מספר תיקונים (ניתן לראות כאן) ומבחינת יציבות – המערכת הרבה יותר יציבה ממה שהיתה בגירסאות 0.6, כך שאני ממליץ לאלו שיש להם מערכת ZFS – לשדרג (או לחכות ל-0.7.6 ולקבל מהירות יותר גבוהה אחרי תיקוני ה-ARC miss).

עתה אני רוצה להתייחס לציוד המודרני שקיים כיום במחשבים ובלוחות אם. כיום בעזרת השקעה בינונית אפשר לקנות SSD NVME בחיבור M.2 כמו הסמסונג 960 EVO או PRO ולקבל ביצועי קריאה של 2.5 ג'יגהבייט וכתיבה של 1.5 ג'יגהבייט לשניה. האם כדאי עם מערכות כאלו לפרמט ולהתקין אותן ישירות עם ZFS עוד מה-Boot? (כאן לדוגמא הוראות מאוד מפורטות לאובונטו 17.10).

התשובה שלי לכך היא פשוטה: זה תלוי במשתמש. ZFS היא לא עוד מערכת של File System, היא הרבה הרבה יותר מזה. נכון, משתמש רגיל לא ישתמש ב-90% מהאפשרויות ש-ZFS נותן (ומה לעשות, בשביל להכיר טוב ZFS צריך להשקיע זמן), אבל דברים כמו snapshots לפני שדרוג, ביצוע snapshot אוטומטי כל רבע שעה או דברים כאלו (זה לא ממש עולה לך, snapshot ריק תופס 0 מקום), וכל העניין של "לחיות את ZFS" מצריך שינוי מחשבה מסוים ואם בעל המכונה/שרת מוכן לכך, אז בהחלט – כדאי ללכת על ZFS.

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

לסיכום: ZFS ממזמן נמצא במצב פרודקשן כשזה מגיע למערכות של אורקל, FreeBSD (לגבי FreeBSD ו-ZFS.. מומלץ לא לנסות להריץ על מעבדי Xeon-SP החדשים.. אלא אם בא לכם לתלוש שערות כשהמכונה בעומס. רק אומר..). עכשיו גם גירסת הלינוקס של ZFS יכולה לתת פתרונות מעולים הן כ-iSCSI, CIFS, NFS. יחד עם זאת, חשוב לזכור: בשביל ש-ZFS יתן ביצועים מעולים, הוא גם צריך חומרה מעולה, עם PCIe 3.0, עם UEFI טוב, עם SSD של Enterprise עם גיבוי קבל (לפחות אחד כזה) או Optane של אינטל, ועם המון RAM (שמשמש ב-ZFS כ-Cache ראשי). עוד משהו חשוב: להקים ZFS לוקח חצי-שעה עד שעה הקמה ראשונית. להגדיר ZFS עבור עבודות שונות כולל בחינות ביצועים – יכול לקחת ימים. אין כאן הוקוס פוקוס וכדאי לקחת זאת בחשבון.

פתרון GlusterFS – היכן הוא מתאים לכם?

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

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

נתחיל בהצהרה די פשוטה: למרות שטכנית ניתן לבנות את GlusterFS כפתרון שיכול לתת "פייט" רציני לכל פתרון אחסון Scale Up מסחרי, לא תמצאו אותי מחר אץ רץ לחברות תקשורת, בנקים וכו' וממליץ להם בחום לזרוק את פתרון האחסון שלהם לטובת GlusterFS, בדיוק כמו שפתרון VSAN של VMWare אינו פתרון להחליף סטורג' רציני עתיר משאבים. אלו 2 דברים שונים לחלוטין.

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

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

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

סיטואציה ראשונה
כאחד שנותן שרותי תמיכה ל-vSphere לגרסאותיו השונות, יש לי מילים חמות לאמר על VSAN. זהו פתרון אמין מאוד עם שרידות גבוהה מאוד ללא צורך בסטורג'. עם VSAN אפשר להגדיר פונקציות שונות כמו פונקציית שרידות מאוד גבוהה כך שמתוך קבוצה של 3 שרתים פיזיים, 2 נכבים, אפשר להגדיר ש-VM קריטי עדיין ישרוד.
הבעיה המרכזית עם VSAN אינה טכנית, אלא בעיה כספית. במחיר של $2500 לרשיון פר מעבד, על קבוצה של 3 שרתים פיזיים, אנחנו מדברים על 15,000$ וזה לא כולל את הרשיון היעודי של vSphere ולא כולל תמיכה של 3 שנים (שזה עוד 15,000$) ועוד לא הגענו בכלל למחירי הדיסקים – במיוחד שעם VSAN חובה ללכת בתצורת קבוצות של 2+1 (כלומר 2 דיסקים מכניים ו-1 SSD אם כי אפשר ללכת בתצורה היותר יקרה של 3 SSD ונוסיף לכך שאתה צריך שרתים מהדור האחרון או לפניו כדי להריץ את כל הדברים. מחיר כזה, לדעתי, אינו מוצדק עבור Dev, stage, testing, POC וכו'. במחיר כזה חברות כבר יחשבו על קניית אחסון יעודי.

במקום זה, אנחנו יכולים לקחת 3 מכונות שדווקא אינן חדשות (כל עוד בקר הדיסקים שלהם תומך ב-6 ג'יגהביט SATA/SAS, אם זה תומך רק ב-SATA 2.0, אז אפשר להכניס כרטיס בקר צד ג') כמו דור 7 של HP, דור 11 של DELL, דור 3 של LENOVO, ולמלא אותן בדיסקים. ניקח דוגמא: 10 דיסקים SATA של WD RED PRO (מחיר של 319$ באמזון פר דיסק, המחיר קצת יותר יקר אצל המפיץ בארץ) או WD GOLD Enterprise בגודל 10 טרה שעולה $361 פר דיסק, או Seagate מסידרת EXOS ל-Enterprise בגודל 10 טרהבייט שגם עולה $360. סה"כ עד כה – בערך $3600 (פר שרת). נוסיף עוד 2 דיסקים SSD – אם מחפשים זול וטוב, אז 2 דיסקים מה-850 PRO של סמסונג יוכלים לעבוד טוב (סה"כ 418$)ואם המכונה היא 2U, אז 2 כרטיסי SSD PCIE מסוג אינטל 900P 280GB AIC בתצורת PCIE (סה"כ 780$) יכולים לתת Cache די רציני למכונה.

ניקח את הבקר (ואת כרטיסי ה-PCIE) ונצמיד את כולם למכונת VM, נצמיד לה 32 ג'יגהבייט זכרון ו-4 ליבות, ועליה נרים GlusterFS (אם אתם מעוניינים בדחיסה, Dedup ושאר תפנוקים – יש צורך להקים עליה ZFS ועל זה GlusterFS), נחבר את המכונות ברשת פרטית וברשת "ציבורית") (כלומר 2 כרטיסי רשת וירטואלית פר VM של GlusterFS) והרי לנו תחליף ל-VSAN שיכול לתת לנו iSCSI, CIFS, NFS, אחסון אובייקטים (Object Storage) ועוד ועוד. בשביל ביצועים ושרידות נצטרך עוד מכונה כזו (עדיף עוד 2) – ויש לנו אחסון עם שרידות חזקה וביצועים גבוהים, ובו זמנית אפשר להריץ על השרתים עוד מכונות VM, ואת כל זה נעשה דרך ה-vSphere, כך שמבחינת עלות – שילמנו רק על החומרה ולא הפכנו את השרתים היעודיים לסטורג' בלבד (כך שלא נצטרך לבזבז שרתים). מבחינת גיבוי – זה VM ואפשר לגבות בכל תוכנה שמשתמשים בחברה (רק שחשוב לזכור לא לגבות את כל ה-VM שמריצים GlusterFS אלא רק אחד, חבל לשמור את הנתונים באותו גיבוי 3 פעמים).

סיטואציה שניה – אפליקציות
קונטיינרים הם ה"שוס" בשנתיים האחרונות ורבים מעבירים חלק מהמערכות לרוץ בקונטיינרים, שזה מעולה, אבל בחלק מהמקרים עדיין מעדיפים להריץ אפליקציות מסויימות בהכפלה וכו', לדוגמא MySQL על 2-3 מכונות VM, שרתי Front ו-Back על מספר מכונות VM ועוד. בכל המקרים הללו, באותם שרתים ניתן להקים GlusterFS כ-VM כמו שתיארתי לעיל (עם פחות דיסקים, רק חשוב שיהיה לפחות SSD אחד שישמש כ-Cache) ואז ה-DATA של האפליקציה (לדוגמא עם MySQL התיקיה var/lib/mysql/) תשב ב-GlusterFS (איך עושים? עוקבים אחרי ההוראות כאן), ה-WWW של שרת ה-Web ישב ב-GlusterFS וכו' וכו'. יהיו מספר שינויים קטנים שצריך לבצע (אולי להשתמש ב-HAProxy), וכך נוכל לקבל שרידות רצינית ומהירות משופרת בהרבה מכיוון שכל שרת אפליקציות יכול לקבל נתונים משרת GlusterFS קרוב וסינכרון הנתונים הוא מיידי – מבלי להשקיע כספים רבים.

סיטואציה שלישית – קונטיינרים/Kubernetes/Openshift
קונטיינרים רצים בד"כ על שרתי VM וקבצי ה-YAML, קבצי קונפיגורציות יושבים על דיסקים מקומיים אך ניתן להגדיר את ה-VM שירוצו על דיסקים וירטואליים שה-vSphere יקבל מ-GlusterFS דרך NFS או iSCSI. בנוסף, ניתן להגדיר Volumes עבור ה-Pods שישתמשו ב-GlusterFS (גם Kubernetes וגם אפליקציות שמריצות את Kubernetes כמנוע כמו Rancher, OpenShift וכו' תומכים ב-GlusterFS החל מ-Kubernetes 1.5). ואנחנו יכולים להשתמש לדוגמא ב-Volume מסויים במספר Pods במקביל, ועם GlusterFS ניתן לוותר על הרצת קבצי YAML/JSON ליצור את ה-Volumes ולגשת ישר ל-Volume Claim, המערכת תיצור את ה-Volume אוטומטית.

סיטואציה רביעית – בענן
מכיוון של-GlusterFS לא אכפת מה נמצא מתחתיו (דיסק מסכן, EBS וכו'), אפשר להקים את GlusterFS גם בענן. כל מה שאנחנו נצטרך הם מספר Instances (מומלץ 3 ומעלה לפרודקשן, 2 לטסטים) ולאותם Instances (שישמשו כ-Nodes) נחבר 2-3 אחסוני EBS ונתקין את GlusterFS ומשם אנחנו יכולים להשתמש ב-GlusterFS כפתרון אחסון לצרכים שלנו.

סיטואציה חמישית – קרוב רחוק
הקמה של GlusterFS זה דבר טוב ועוזר, אולם לפעמים אנחנו צריכים את הנתונים בחוץ, בחוות שרתים אחרת בארץ או בחו"ל. לשם כך, החל מ-GlusterFS 3.8 ומעלה ניתן להריץ Geo Replication לסנכרן בין מספר Volumes (בשיטת Master/Slave), ואפשר גם לספק צרכים "מופרעים" כאלו:

סיטואציה 6 – פתרון אחסון ל-VDI
הקמת VDI למאות עובדים זה פרויקט מורכב עם עלויות אסטרונומיות. (בימים אלו אני מנסה בבית להקים פתרון VDI עם דגש על מחירים נמוכים, ברגע שאצליח, אפרסם פוסט על כך). יש צורך לשלם למיקרוסופט, ל-VMWare וכמובן כל נציג מכירות יאמר לך – All Flash Array, כך שאם תרצה פתרון VDI טוב, תחשוב על כך סכום של 7 ספרות.

האם GlusterFS יכול לחסוך כאן במחיר? התשובה היא בהחלט. נתחיל בגירסה הזולה: זוכרים שהמלצתי על השרתים הישנים להרצת GlusterFS? אנחנו נשתמש בכאלו בגודל 2U עם פאנל קידמי של כונני 2.5 אינטש כך שאפשר יהיה להכניס בין 16 ל-24 דיסקים 2.5". לתוכם נכניס דיסקים 850 PRO של סמסונג בגודל שתבחרו, יש עד 2 טרהבייט (יש לוודא שהבקר דיסקים תומך במצב JBOD ושהוא תומך ב-SATA-3, אם לא – יש צורך בבקר אחר) ונכניס את הדיסקים הנ"ל למגירות ונצטרך לרכוש או אינטל 900P בגודל 480 ג'יגה או 2 כרטיסי אינטל 900P בגודל 280 ג'יגה, הכל לפי התקציב (עם 2 כרטיסים השרידות הרבה יותר גבוהה). על כל שרת כזה נקים ZFS עם Hot Spare ל-2 דיסקים SSD. כל ה-RAID יוגדר דרך ה-ZFS (כלומר RAIDZ לפי תצורה שמחליטים) ועל זה נקים את GlusterFS. את החיבור בין השרתים נחבר ב-10 ג'יגהביט (נחושת, SFF, FC – החלטה שלכם) ואת הזכרון נמלא ב-ECC 3 8500R (שהוא פחות מהיר אבל המהירות אינה ממש חשובה כשהשרת משמש Node ל-Gluster, הזכרון משמש בראש וראשונה כ-Cache ב-ZFS) עד המקסימום. המחיר לא כזה יקר: 2000 שקל (תלוי מהיכן אתם קונים) ל-192 ג'יגהבייט זכרון. נצטרך 3 מכונות. שימו לב: בשרת כזה נרוץ "על הברזל" ללא וירטואליזציה כלל ונוכל לגבות אותו כמו כל תחנת לינוקס (אם כי צריך לגבות רק אחד מהם, לא את שלושתם).

אם יש לכם כמה וכמה שרתים ישנים, אפשר לפצל את כמות הדיסקים לפי כמות השרתים הישנים שלכם (לדוגמא – 6 דיסקים בשרת 1U) ובכך לקבל ביצועים יותר גבוהים הואיל ולא מדובר בסיטואציית Active/Passive אלא עבודת קריאה/כתיבה מקבילית לכל המכונות.

אם מצד שני יש תקציב – אפשר לרכוש 3 שרתים כשהפאנל הקדמי שלהם הוא NVME ונרכוש דיסקים NVME U.2 – גם סמסונג וגם אינטל מוכרים דיסקים מעולים, והעלות משתנה לפי גודל הדיסק והפירמה שקונים ממנה. מבחינת רשת, תצטרכו לחשוב איך לחבר את הכל מכיוון שברוטו, תעבורת הקריאה מגיעה בין 40-60 ג'יגהבייט לשניה. אפשרי לצמד מס' כרטיסי רשת 10 ג'יגהביט או לרכוש כרטיסים ו-Switch של 40 ג'יגהביט (מלאנוקס, אינטל וכו' ישמחו למכור לכם). עם ההצעה הזו, המחיר שתצטרכו לשלם בהשוואה לפתרון אחסון מבוסס AFA (כלומר All Flash Array) יהיה נמוך יותר ב-50-70% מפתרון קופסא, וגם יש לכם שרידות יותר גבוהה.

בכל שאר הפרמטרים (וירטואליזציה, רשיונות וכו') – הכל נשאר אותו דבר.

ומה עם תמיכה? רד האט מוכרת את פתרון ה-GlusterFS כמוצר (Red Hat Gluster Storage) עם תמיכה מסביב לשעון.

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

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

קצת על רד-האט, BTRFS, פוליטיקה ומוכנות ל-Enterprise

אם נסתכל כיום על תשתיות של כל Enterprise או כל חברה גדולה, נראה שכיום רוב מכונות הלינוקס וה-Windows רצות כרגע על VM, בין אם זה רץ על ESXI, על Hyper-V, על OpenStack או בעננים ציבוריים או פרטיים. גם לינוקס וגם Windows רצים בלי בעיה כ-VM ולכל מערכת הפעלה יש תמיכה טובה בקישוריות בין ה-VM ל-Hypervisor שמריץ אותו.

הבעיות מתחילות כשצריכים להריץ הפצות לינוקס כמו רד-האט או סנטוס על "ברזל" פיזי או Appliance פיזי. אין שום בעיה להתקין לינוקס וברוב המקרים גם לא נצטרך דרייברים, וה-File system יעבוד כמו שצריך, אולם יש דברים בלינוקס שהם אינם קלים או מובנים למשתמשים רבים שאינם אנשי לינוקס ותיקים. יצירת RAID מבוסס תוכנה (Software RAID או Fake RAID) הם לא בדיוק דבר הכי קליל, במיוחד אם רוצים לשלב Volume Management בתוך אותו RAID תוכנה (אם כי כמובן יש אתרים שמסבירים כיצד לעשות זאת). את המשוכה הזו ניתן לדלג עליה די בקלות אולם אם אנחנו רוצים לבצע Snapshots או להוסיף SSD כ-Cache לאותו RAID, זה כבר נהיה יותר מורכב. רוצה גם לבצע Compression ו-DeDup בזמן אמת? כאן כבר תצטרך איש לינוקס טוב וזה לא תמיד אפשרי, תלוי במה קיים ובאפשרות לשנות דברים.

האם ניתן לעשות את הדברים בלינוקס? התשובה היא שבהחלט כן. אני כותב את הפוסט הזה בביתי ואחד משרתי ה-NAS שלי עושה בדיוק את הדברים הללו: ה-RAID הוא תוכנה, המערכת מייצאת iSCSI, CIFS, NFS החוצה למערכות אחרות (כל עריכת הוידאו שלי שאתם רואים בערוץ הוידאו של העסק מבוצעת על CIFS/SAMBA, לא על דיסק מקומי), יש DeDuplication  ויש דחיסה והכל רץ על "מפלצת" עם … מעבד i5 ועם 16 ג'יגהבייט זכרון, 5 דיסקים מכניים ו-2 דיסקים SSD ישנים שישבו אצלי במגירות. המערכת עצמה רצה על ZFS עם הפצת CentOS 7 ועם כל העומס שאני זורק עליה (ויש עומס) – היא עושה את עבודתה יציב כבר 4 שנים בלי תקלה אחת הקשורה ל-ZFS.

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

הסיבה הרשמית היא "בעיה ברשיון", הסיבה המציאותית יותר היא … פוליטית.

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

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

ב-2008 החלה לקום מערכת ניהול קבצים ודיסקים חדשה בשם BTRFS. בעקרון, BTRFS אמור להיות התשובה ל-ZFS רק בקוד GPL והוא משולב בתוך הליבת לינוקס. אנחנו ב-2017 וכיום כל הפצת לינוקס תומכת ב-BTRFS אולם הבעיה הגדולה ביותר של BTRFS היא ביציבות. ה-BTRFS יציב מבחינת file-system אך יש לא מעט בעיות במימוש ה-RAID שלו ובחלקים אחרים. בזמנו הקוד נבנה תחת קורת הגג של אורקל, אולם מאז שאורקל החליטה לברוח מקוד פתוח כאילו מדובר במחלה מדבקת – התפזרו המפתחים לכל עבר ואין עבודה יציבה על BTRFS, מה שגרם לרד-האט להודיע שהיא "יורדת" מ-BTRFS בגירסאות הבאות של הפצת הלינוקס שלה (בינתיים שאר ההפצות ממשיכות לתמוך ב-BTRFS, וזו מערכת עיקרית בהפצות כמו SuSE).

נשמע כמו צעד די דרסטי – לא? אכן, רק שבימים האחרונים הסתבר מדוע רד-האט עשתה זאת. רד-האט רכשה חברה קטנה בשם Permabit ש.. מציעה בדיוק את השרותים שה-Enterprise צריך: דחיסה, Dedupe, thin provisioning וכו'. האם רד-האט תציע זאת בחינם לקהל הרחב? כן, אבל יקח זמן. במילים אחרות, במקום לחכות ש-BTRFS יבשיל, רד-האט העדיפה לקנות חברה וטכנולוגיה. במקביל הודיעה רד-האט שהם החלו פרויקט חדש שנקרא Stratis שיאפשר לבצע חלק מהדברים בצורה קלה ופשוטה. אל תחזיקו את נשימתכם, לפרויקט יקח כמה שנים עד שיהיו פירות וניתן יהיה להשתמש בו בצורה בטוחה.

לסיכום: כיום ב-8 מתוך 10 מקרים, כשמקימים מכונת לינוקס, מקימים אותה כ-VM. לא צריך RAID ב-VM (אבל כן צריך LVM אם תרצו להגדיל דיסק או להוסיף דיסק ל-VM) ו-snapshots ניתן לעשות ברמת VM – ועדיין, עקב כל מיני החלטות שאני קורא להן "פוליטיות" הפצות רשמיות עדיין לא כוללות (גם בגרסאות המסחריות) דברים ש-Enterprise צריכים כשמקימים מערכת עם דיסקים מקומיים. הרכישה ש-רד האט ביצעה מסייעת במשהו, אבל אם רד-האט היתה עושה צעדים לפני מס' שנים כדי לסגור עיסקה עם אורקל, אז היינו כיום עם מערכת כמו ZFS שנותנת את הדברים שאותם לקוחות חשובים צריכים, במיוחד במקומות שמעוניינים להרים Software defined storage בשיטה של Scale Up.

על אחסון ווידאו בחברות מדיה

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

בעולם ה-Corporate, סטורג' הינו חלק קריטי מהתשתית. מכונות VM מאוחסנות על סטורג' ולא על דיסקים מקומיים, אפליקציות כמו SQL/Oracle DB דורשות סטורג' (במיוחד אם מריצים כתצורת אשכול [cluster]), כל קבצי העבודה של העובדים (מסמכים, קוד וכו') מאוחסנים בסטורג', גיבויים זמניים מאוחסנים בסטורג' ובקיצור – הסטורג' "נוגע" כמעט בכל תחום. אחרי הכל, כולם מכירים: כשסטורג' נופל – ההיסטריה בשיאה.

בשנים האחרונות, עם חדירת העננים הציבוריים ל-Corporate – השימוש ב-Storage פוחת במעט (ככל שמעבירים VM ושרותים לענן), אך עדיין לסטורג' יש מקום מאוד שוב. יחד עם זאת, כמות השדרוגים או רכישות סטורג' חדש – מתמעטת. אחרי הכל, אם "העפתי" 50 VM ל-AWS לדוגמא, והם יעבדו ב-AWS באופן קבוע, אני אשמור מקומית גיבוי, אבל אני לא אצטרך להשאיר אותם ב-Datastore היקר המקומי, אני אמחק אותם ואז יתפנה לי מקום בסטורג', מה שאומר שרכישת עוד מדף סטורג' תיהפך למיותרת. בנוסף, בעולם ה-Corporate הגדילה היא איטית. לא כל יום מרימים עוד 100 VM (וגם אם מרימים, משתמשים ב-Template כך שרק השינויים נשמרים ולא כל VM שוקל 10 ג'יגה ומעלה).

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

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

מדוע? כי חברות הוידאו דורשות צילום איכותי וגבוה. פעם היו מסתפקים ברזולוציית SD ולאחר מכן העולם קפץ ל-HD ול-Full HD וכיום הרוב מצולם ב-4K או 5K ו-6K וחלק (שמשתמשים ב-RED לדוגמא) מצולם בכלל ב-8K. בניגוד לצילום באייפון (או גוגל פיקסל) – מצלמות מקצועיות מצלמות ב-Bitrate החל מ-20 מגהביט ועד 80-130 מגהביט (ומעלה במקרה של RED אם לא משתמשים ב-REDCODE) ועוד לא דיברנו על ביטים פר ערוץ צבע (8,10,12 וכו') ועוד. במקרים רבים מצלמים ב-2 מצלמות (או יותר), נוסיף אודיו שמוקלט בנפרד, צילומי סטילס (בחלק מהמקרים). את כל הערימה הזו צריך להעלות לאיזה סטורג' כלשהו ובחלק מהמקרים צריך גם לתרגם (Transcode) ל-Codec אחר (מה שנקרא Mezzanine Codec) בכדי לאפשר עבודה רציפה על התכנים בהתאם לתוכנת העריכה המועדפת על החברה. אחרי זה יש צורך בעריכה של הקובץ, הוספת תכנים שונים (אפקטים, תלת מימד, אנימציות, אודיו וכו'), ולבסוף יש צורך שוב בהמרה של התכנים לפורמטים שונים (הוצאה לאולפנים שונים בהתאם לדרישות שלהם, יוטיוב, סטרימינג וכו').

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

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

הבה נאמר שלחברה יש סטורג' כיום זמין שאליו מתחברים עורכי הוידאו ומשתמשים בתכנים. אחרי שהתוכן עבר עריכה והמרה – יש צורך לאחסן את התכנים על מנת שיהיו זמינים מיידית. כאן פתרון Scale Up פתוח (כמו ZFS) יכול להוות פתרון מעולה תוך שימוש בשרת יחיד שאליו משורשרים מספר JBOD ובתוך אותה מערכת יש מספר קטן של דיסקים SSD מהירים והשאר – דיסקים SATA פשוטים (או SAS או NL-SAS, בהתאם לתקציב) וגדולים מאוד (8,10,12 טרהבייט) עם תצורת RAIDZ שמאפשרת מצב שגם אם 2 דיסקים קשיחים נדפקים, התוכן נשאר תקין בצורה זמינה. זיכרו – סטורג' זה משמש רק לאחסון ולא לעבודה ישירות, כך שעורך שצריך תוכן כלשהו, רואה את הקבצים כ-Read Only ללא אפשרות שינוי. נגמר המקום? מוסיפים JBOD גדול עם 36 דיסקים (לדוגמא) וכל דיסק הוא בגודל 10 טרהבייט, ב-RAIDZ2, הרי שנטו נקבל תוספת של 309 טרהבייט, ואם חברה רוצה ממש אחסון של 1 פטהבייט, אז 4 JBOD כאלו מלאים יתנו 1.2 פטהבייט עם שרידות טובה.

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

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

האם חייבים להשקיע ב-DR כמו במערכת פרודקשן?

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

ההחלטה: להרים מערכת DR זהה מבחינת ברזלים ותוכנות – למערכת הפרודקשן.

מכיוון שיש אנשים שונים שמבינים את המושג "DR" במשמעויות שונות. המשמעות שאני מדבר עליה היא כדלקמן:

  • מערכת שהיא Active/Passive – כלומר מערכת הפרוקדשן נותנת שרות ומערכת ה-DR לא נותנת שרות בזמן שהיא "פאסיבית". אף אחד לא מתחבר אליה והחיבור היחיד שיש הוא בין המערכת DR למערכת הפרודקשן עם אפליקציית סינכרון מתמשכת שמעבירה כל ביט בין ה-Storage השונים (ה-Storage שבפרודקשן ל-Storage ב-DR), וסינכרונים נוספים רצים בין שרתים עצמאיים (Active Directory וכו').

הנה מערכת קטנה ופשוטה לדוגמא. יש לנו שרת קבצים גדול שאליו מחוברים עוד 2 JBOD (בתצורת RAID, אפשר לחשוב עליהם כמודולים המרחיבים את המקום הפנוי ב-Storage), נתב, חומת אש, ו-12 שרתים שמריצים מכונות וירטואליות שונות.

mind mapping software

האם אנו צריכים בדיוק אותו דבר למערכת DR?

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

מערכת DR באופן עקרוני, חוץ מלקבל נתונים מה-Storage ושרותים שונים, רוב הזמן כשמערכת הפרודקשן עובדת, היא לא עושה כמעט כלום. אם ניקח את המושג "DR" במובן הקלאסי, השרתים וה-Storage יושבים במיקום פיזי אחר, אולי בבניין אחר, אולי בעיר אחרת, בחוות שרתים שאינה החווה שלנו ואם נשתמש בה שם כ-Active/Active, החברה תצטרך לשלם לא מעט על רוחב פס, חשמל (מה לעשות, חוות שרתים גובות בערך 150-250% יותר מתעריפי חברת החשמל שאתם משלמים בבניין שלכם).

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

  • שרותי קבצים
  • שרותי גיבוי לצד ג' (אם הפרודקשן מושבת עקב הפסקת חשמל ממושכת, רעידת אדמה, אסון כלשהו וכו' – אין לך לאן לגבות את הנתונים)
  • שרותי אותנטיקציה למשתמשים
  • שרתי אפליקציה (SQL, Exchange, Sharepoint וכו')
  • חיבור אינטרנט

אז כשמקימים את ה-DR, אפשר להקים אותו ולחסוך כספים בדרכים הבאות:

  • לא חייבים לרכוש במיליוני שקלים שרת קבצים. זיכרו – שרת הקבצים ב-DR יתן שרותים לזמן קצר עד שהתקלה תטופל, כלומר זה יכול להיות למשך מספר שעות ובמצב אסון טבע – כמה ימים עד שבועות, לא חודשים עד שנים.
  • מבחינת שרת קבצים – אנחנו צריכים 2 (השני ישמש כגיבוי לראשון כי אין לנו במצב חרום קלטות). עם 2 השרתים אנחנו יכולים להשתמש ב-ZFS ובמקום להשתמש בדיסקים מבוססים SAS יקרים, אנחנו יכולים "להעמיס" דיסקים מבוססי SATA זולים וגדולים (הם זולים – בערך 200$ ל-4 טרהבייט ויש אחריות ל-5 שנים) ובשביל לקבל מהירות נוסיף בין 2-4 דיסקים מבוססי SSD שישמשו כ-Cache. ככל שנעמיס יותר דיסקים SATA על המערכת, מהירות הקריאה תהיה הרבה יותר גבוהה כי אנו ניצור RAID של ZFS עם יותר דיסקים מיכניים, כך שאפשר להגיע בקלות למהירות קריאה של בין 400 ל-800 מגהבייט לשניה (אם אתה משתמש בחיבורי 10 ג'יגה או שאתה מחבר מספר פורטים של 1 ג'יגה).
    שרת הגיבוי לעומת זאת, לא מצריך הרבה השקעה – שוב, אפשר נניח להכניס 10 דיסקים של 4 טרהבייט (SATA), ו-2 דיסקים SSD. רוב התעבורה אליו היא כתיבה ולכן ה-SSD יקבל באופן מהיר את הנתונים וברקע מערכת ה-ZFS תכתוב את הנתונים לדיסקים המכניים.
  • לא חייבים לשים שרתים מהדור האחרון, אפשר לשים שרתים מדור קודם או לפני כן במיוחד אם אתם שוכרים מקום לפי ארונות ולא לפי U בחוות שרתים. ה"סוד" הכי ידוע בוירטואליזציה זה זכרון – ואפשר להשיג בזול זכרון לשרתים מלפני 3-4 שנים.
  • אם לא נעביר את כל השרותים, יהיה לנו מקום "להתפרס" מבחינת השרותים, כך שכמות המכונות הוירטואליות שרצות פר שרת לא תהיה גדולה, וכך נוכל לתת את אותו שרות חרום – במהירות מיטבית.
  • גם מבחינת רוחב פס החוצה מהשרתים למשרדי החברה נצטרך לדאוג ל-Policy כלשהו ש"אין חגיגות" כי במצב חרום לא רק תעבורת אינטרנט מבחוץ עוברת, עכשיו גם כל ה-DATA מהשרתים מבחוץ עוברים על אותו רוחב פס, והדבר האחרון שאתם צריכים זה לא להצליח להיות מחוברים לשרתים בחוץ כי כמה עובדים החליטו שעכשיו בדיוק הזמן לצפות בשידורים חיים לגבי המצב. (פתרון למצב כזה שהרמתי בעבר: PC עם מודם 3G שמצד אחד מקבל שידורים דרך סקריפט, ומצד שני משדר אותם ב-LAN הפנימי דרך VLC תוך וידוא שאין אפשרות להתחבר למודם 3G מבחוץ).

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

בפוסט הבא נדבר על מערכות Active/Active.

המלצות לגבי שרת ZFS ל-Enterprise

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

נתחיל במעבד: ל-ZFS אין צורך במעבדים ממש חזקים, כך שעד גבול מסויים אתה יכול להשתמש במעבד Xeon נמוך מאוד או מעבד Atom שמיועד לשרתים (סידרה C25XX או C27XX). מה הגבול? הגבול קשור לדברים שאתה רוצה ממערכת ZFS. אם לדוגמא אתה צריך Deduplication או הצפנה, תצטרך בהחלט משאבי מעבד טובים כמו Xeon E3 / E5.

שמתם לב שלא הזכרתי לעיל מעבדים כמו כל סידרת ה-i5/i7? הסיבה לכך פשוטה: שרת ZFS ב-Enterprise צריך זכרון ECC, ומעבדי i3/i5/i7 (או מעבדי AMD מסידרה 8XXX/6XXX ומטה) אינם תומכים בזכרון זה. כשמדובר בשרת ביתי, חשיבות הדיוק של קריאת הנתונים מהדיסקים אינה כה קריטית ורוב הזמן לא תהיה בעיה, אבל ב-Enterprise, במיוחד שאתה מחבר שרתים לשרת ZFS, כל ביט חשוב שיעבור בדיקה ויגיע ליעדו בצורה תקינה (זה היתרון של ZFS – הוא לא בודק checksum של כל מה שהוא כותב לדיסקים, אלא גם הפוך, כשהוא קורא ושולח אותו, דבר שלא מבוצע במערכות מתחרות שמשתמשות במצבי RAID חומרה, וכך יכולים לקרות גם מצבים לא נעימים של bit-flip) ולכן זכרון ECC הוא חשוב מאוד.

אם דיברנו על זכרון: כמות הזכרון שצריך לשרת ZFS מאוד תלויה בשרותים שתריצו על שרת זה החוצה (SMB, NFS, iSCSI וכו'). שרותים כאלו צריכים זכרון. גם ZFS בעצמו צריך לא מעט זכרון, ושוב, במיוחד אם אתה רוצה להשתמש ב-Deduplication – תצטרך ערימה של מקלות זכרון (עם ECC).

בברירת מחדל, ZFS ישתמש בערך במחצית ה-RAM שיש במכונה שלך לצרכי ARC (סוג מסויים של Cache שיושב על ה-RAM) אבל המכונה תצטרך גם כונני SSD (תיכף אגיע לכך) לצרכי Cache. במקומות רבים התיעוד של ZFS הולך עם "כלל אצבע" שיש צורך ב-1 ג'יגהבייט זכרון על כל טרה דיסק שאתה מכניס (מדובר על טרהבייט "ברוטו" לפני RAIDZ) אבל אם אינך משתמש ב-deduplication, כלל זה אינו נכון. מנסיוני, אני ממליץ על הדברים הבאים:

  • 16 ג'יגהבייט זכרון על מערכת בינונית שכוללת בין 4-8 דיסקים של 1-3 טרהבייט
  • 32 ג'יגהבייט זכרון על מערכת שמורכבת מ-8-16 דיסקים של 2 טרהבייט
  • 64 ג'יגהבייט זכרון על מערכת שמורכבת מ-12-24 דיסקים של 2-4 טרהבייט

חשוב לציין: את הגדרות ה-Cache של ARC ניתן כמובן להגדיר מבחינתם מינימום/מקסימום, ולכן אלו רק המלצות ולא "כללי ברזל", אך ככל שהשרת ZFS מגיש/מקבל יותר ויותר קבצים והעומס גודל – יש צורך ב-ARC גדול יותר, כך שהמערכת תגיש קבצים בצורה מהירה יותר.

דיסקים קשיחים: את נושא הדיסקים אחלק ל-3:

  1. מערכת הפעלה – מכיוון ש-ZFS עצמו לא משנה הרבה דברים במערכת, כל דיסק קשיח קטן יכול להספיק. את קבצי ההגדרות של ZFS ניתן בקלות לגבות לתוך מערכת ה-ZFS (או החוצה), כך שגם אם הדיסק הזה הולך, אפשר להקים על דיסק חדש לינוקס מינימלי, להתקין את ה-ZFS, לבצע import של ה-pool ואולי להעתיק קובץ הגדרות יחיד, לבצע reboot (לשם בדיקה) ולחזור להשתמש. למחמירים, אפשר להכניס את מערכת ההפעלה על 2 דיסקים קטנים ב-RAID-1 (שאינו ZFS), אבל זה מיותר ברוב המקרים (הח"מ עובד בתקופה הנוכחית על סקריפט להתקנת כל המערכת הפעלה עבור ה-ZFS ישירות לתוך ה-ZFS עצמו כך שכמעט ולא יהיה צורך במחיצות נפרדות על ext3/4/xfs, והצורך היחידי יהיה מחיצות עבור UEFI ו-boot/ שאותן אפשר להכניס על כרטיס SD כי הן לא משתנות.
  2. דיסקים ל-Cache ול-Logs (נקרא ZIL – ZFS Intent Log) – כאן מומלץ על דיסקים SSD, מומלץ לפחות 2-4 דיסקים. ל-logs עצמם יש צורך ב-Partition קטן מאוד (אין צורך יותר מ-5 ג'יגהבייט), וכל שאר המקום ב-SSD יחובר יחדיו (כמו RAID-0) לשמש כ-Cache גם לכתיבה וגם לקריאה. הנתונים עליו אינם חשובים והם בין כה מתאפסים בזמן reboot, אבל עצם קיומם נותן ל-ZFS אפשרות לתת ביצועים ממש מעולים. אין צורך לקנות כונני SSD ממש גדולים (1 טרה ומעלה), אפשר להסתפק ב-2-3 כוננים של 256 ג'יגהבייט – בהתאם לעומס המתוכנן שאתם רוצים להעמיס על אותו שרת ZFS.
    לגבי סוג של SSD – אנחנו ב-2015, כיום כונני ה-SSD מחברות רציניות (כמו סמסונג, סאנדסיק, אינטל, וכו') כוללות בקר בכונן SSD שיודע מתי לכתוב את הנתונים בצורה שהכי פחות תשחק את הכונן, ומבחינת TRIM – מערכות לינוקס (ZFS על לינוקס) יודעות לתמוך ב-Trim על מנת להאריך את חיי הכונן.
  3. דיסקים קשיחים – ידוע לי כי ב-Enterprise מאוד אוהבים דיסקים מבוססי SAS ו-ZFS מאוד שמח לעבוד עם דיסקים כאלו, אולם ניתן לעבוד גם עם דיסקים מבוססי SATA, ולפני שגבות יורמו לאחר קריאת השורה לעיל – הדיסקים שיצאו בשנת 2014 לפחות הם אמינים לא פחות מדיסקים מבוססי SAS ולראיה – הרחבת האחריות שיצרני הדיסקים ביצעו לאחרונה. כך לדוגמא עם דיסקים Red Pro של Western Digital (כן, עם חיבור SATA) האחריות הורחבה מ-3 ל-5 שנים.
    אני מניח שרבים יטענו כי דיסקים SAS נותנים ביצועי כתיבה/קריאה הרבה יותר מהירים, אבל בעולם ה-ZFS הדברים שונים: הכל נכנס ויוצא דרך 2 שכבות ה-Cache (ה-ARC ו-L2ARC) שאחת מהן יושבת על ה-RAM והשניה יושבת על SSD. יש כמובן דיסקים SAS עם בקרים שכותבים/קוראים במהירות מדהימה של 12 ג'יגהביט לשניה, אבל המחירים שלהם מאוד גבוהים. אני ממליץ לקרוא את המאמר הזה לגבי SAS מול SATA בהתייחסות ל-ZFS.

מבחינת ברזל שיארח את הדיסקים, אפשר כמובן ללכת בשיטה הקלאסית של להכניס את הכל על שרת 2U או 3U בהתאם לכמות הדיסקים שאתם מכניסים, וזה עובד מצוין.
אישית ההמלצה שלי היא להפריד בין הדברים. להשתמש (לדוגמא) בשרת 1U שבו ישב הדיסק עם מערכת ההפעלה, וכונני ה-SSD (ב-1U אפשר להכניס בקלות 6 כונני SSD) כשכל הדיסקים הם 2.5". שאר הדיסקים המכניים יכולים לשבת בתוך מארז JBOD שמתחבר ב-SAS חיצוני לשרת 1U.
הסיבה להמלצה? כמה סיבות:
* במארזי JBOD אין הרבה אלקטרוניקה שיכולה להתקלקל (אין זכרונות, אין לוח אם)
* קל לשרשר JBOD נוספים אם רוצים להתרחב.
* ב-JBOD יש לוגיקה פשוטה – backplane ובקר.
* אפשר להעביר את ה-JBOD למערכות אחרות במידה ויהיה לכך צורך.

חיבורי רשת – מכיוון ש-ZFS רץ על לינוקס מערכת הפעלה, מי שמטפל בכל עניין התקשורת פנימה החוצה זו מערכת ההפעלה, לא ה-ZFS, כך שאפשר להשתמש בכל סוג חיבור שמעוניינים, החל מחיבור Ethernet של 1 ג'יגהביט ועד Infiniband בחיבור EDR ומעלה או בכלל להשתמש בסיבים אופטיים. הכל תלוי בתשתית שיש לכם ובהשקעה שאתם רוצים להשקיע.
ההמלצה שלי לכל הפחות היא להשתמש ב-4 חיבורי רשת שקיימים בכל שרת מכובד, ולהפריד בין iSCSI, SMB, NFS וכמובן ניהול. אם אתם משתמשים בפרוטוקול יחיד כלשהו (iSCSI לדוגמא) אז אפשר כמובן לצרף חיבורים וגם להגדיר את החיבורים בשיטות שונות.

אלו בעקרון ההמלצות. אין שום בעיה לקחת PC, לדחוף כמה דיסקים ולהרים מערכת ZFS, אבל התוצאות יהיו בהתאם. מערכות ZFS אינן "קסם" והן דורשות משאבים (במיוחד תהליך ה"קרצוף" שמומלץ שירוץ אחת לשבוע אם מדובר בדיסקים SATA או אחת לחודש אם מדובר בדיסקים SAS).

גילוי נאות
כותב שורות אלו מוכר שרותי יעוץ/הקמה/הגדרות למערכות יוניקס/לינוקס עם ZFS

ZFS על לינוקס וחסרונות

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

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

  • עריכות וידאו (כאשר ישנן מספר תחנות שעליהן עורכים וידאו וכל התכנים יושבים על שרת ZoL)
  • VOD – לשידור וידאו החוצה ללקוחות
  • גיבויים ושחזורים, ארכיב
  • שרת PXE/BOOT לתחנות Diskless
  • שרת קבצים (CIFS, iSCSI, NFS)

כפי שציינתי בפוסטים קודמים, עם ZFS אין לך בעיה של התרחבות. נגמר לך המקום בשרת מבחינת כמות דיסקים שאפשר להכניס? חבר JBOD כלשהו ואם זה JBOD שאתה בונה, אני ממליץ להשתמש בפאנל של Areca מסוג 8026 או 8028, כך שאתה יכול לחבר אליו עוד 2 JBOD נוספים ואם צריך, לשרשר אליהם (אם כי במקרים כאלו אני ממליץ לפצל את חיבור ה-SAS מה-JBOD השונים בשרת עצמו למספר כרטיסים). ל-ZoL/ZFS אין שום בעיה לתמוך בעשרות אלפי כוננים ובאקסבייטים של נתונים והעבודה עצמה לאחר ההרכבה מאוד פשוטה: להגדיר RAIDZ ברמה כלשהי (אם יש לך הרבה דיסקים אז רמת RAIDZ3 מומלצת, כך שעד 3 דיסקים קשיחים יכולים להתקלקל והמכונה עדיין תמשיך לעבוד בצורה חלקה), ומיד תראה שיש לך מקום שזמין לכל השרותים שאתה מריץ על השרתים השונים ללא צורך בהגדרות LVM.

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

אחת הדוגמאות לכך היא שרותי NFS לשרתי ESXI.

הבעיה עצמה מחולקת ל-2 חלקים, כאשר ZFS עצמו אינו אשם במצב, אלא המערכת מתחת שנותנת שרותי NFS וגם VMware קצת אשמים.

יצרני הפצות לינוקס (במיוחד רד-האט) דוחפים תמיד את ההפצה קדימה מבחינת טכנולוגיות שהלינוקס בהפצה נותן ללקוחות. כך לדוגמא בלינוקס יש NFS גירסה 3 וגם NFS גירסה 4.1 (מ-RHEL 7 ומעלה), אבל ה-NFS-3 שקיים ללינוקס לא יכול להשתוות בביצועים שלו ל-NFS-3 של סולאריס כי מדובר ב-2 מימושים שונים לחלוטין. בלינוקס פשוט החליטו לא להשקיע יותר מדי ועברו למימוש גירסה 4 ו-4.1 שנותנים ביצועים הרבה יותר טובים וגם אבטחה הרבה יותר גבוהה עם אפשרויות התחברות מקביליות (pNFS), ואפשר לקבל יותר פרטים ממסמך ה-PDF הזה.

כשמחברים שרת לינוקס לשרת ZoL אפשר להתגבר על הבעיות ביצועים עם mount options שונים כמו rsize,wsize וכו', וכאן צצה הבעיה שמגיעה ל-VMWare.

ב-VMware, כשאתה מחבר NFS דרך vSphere או vCenter או VSA לשרתי ESXI (או ישירות לשרת ESXI מסויים) אין לך יותר מדי מקום "לשחק". אתה צריך לתת לו את שם השרת, שם ה-Share, השם שיהיה ל-Datastore וזהו. אתה לא יכול להכניס פרמטרים ובנוסף לכך – התמיכה היא רק ב-NFS-3, כלומר התמיכה ב-NFS במוצרים של VMWare כבר מהרגע הראשון היא לא מי יודע מה. המימוש עצמו עובד עם כל השרותים של vCenter/VSA כמו DR, HA, DRS וכו' מול NFS, אבל גם אז הביצועים לא יהיו הכי טובים שניתן לקבל.

מהצד של VMware הבעיה תוקנה באופן רשמי בגירסת ה-vSphere החדשה (גירסה 6) ששוחררה חודש שעבר. סוף סוף יש תמיכה ב-NFS 4.1 עם אותנטיקציה כך ששרת vSphere 6 מול ZoL יעבוד בצורה טובה מאוד.

תיקון לבעיה הזו קיים בגירסה 0.6.4 של ZoL והמצב יותר טוב, אך עדיין, אם יש לך שרתי vSphere 5 ואתה רוצה לחבר אותם רק דרך NFS ל-ZFS, אולי כדאי גם לבדוק פתרון מבוסס Opensolaris (כמו Openindiana) ואז לראות מי נותן לך פתרון יותר טוב.

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

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

כל מימושי ה-ZFS השונים, בין אם זה תחת לינוקס, BSD, גירסאות פתוחות של סולאריס משתמשים בגירסה אחידה שנקראת 5000 ומערכות ZFS יודעות לייבא Pool מגרסאות ישנות יותר עד גירסה 28. סולאריס הרשמית נמצאת כיום בגירסה 35 אבל שום גירסת ZFS פתוחה לא יכולה לתמוך בכל משהו שהוא מעל גירסה 28, כלומר אם הרמת Pool על BSD או על גירסת סולאריס פתוחה, אין שום בעיה להביא את הדיסקים למכונת לינוקס, להריץ פקודת zfs import והוא יכניס מיידית את הדיסקים שהבאת לשימוש, הפורמט נשמר ותואם, אולם אם ה-pool נוצר בסולאריס סגור  (מגירסה 11 ומעלה), לא תוכל להשתמש ב-pool הזה בשום גירסת ZFS פתוחה. הכל "תודות" לאורקל שסגרו את הקוד. אגב, ההבדל הגדול בין גירסה מעל 28 ל-5000 זה שיש הצפנה, ובגירסה 5000 יש פתרון עקיף להצפנה בשימוש אפליקציה נוספת שעושה זאת.

ו"חסרון" אחרון שהוא יותר פסיכולוגי הוא עניין גירסת ה-ZoL. כיום יש את גירסת 0.6.3 ובשבועות הקרובים תצא גירסת 0.6.4 שתשפר מספר דברים. היכן גירסה 1.0? היא כנראה תצא בשנה הבאה, אולם אין צורך להמתין לה. גירסה 0.6.3 מוכרזת כ-Production Ready, כלומר אפשר להתחיל ולהשתמש בהן כבר עכשיו. גרסאות חדשות שיצאו בהמשך הן גרסאות תואמות, תוכל פשוט לבצע yum update, להפעיל את השרת מחדש ולהריץ פקודת zpool upgrade, וזהו. אין שינויים שתצטרך להתכונן אליהם במיוחד וגם השינויים שמבוצעים בגרסאות לא משפיעים מבחינת הגדרות, השרת יכול להמשיך לעבוד ולשרת את השרתים ותחנות אחרים.

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

ZFS על לינוקס בהשוואה לפתרונות ZFS אחרים

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

לאחר שחברת Sun נקנתה ע"י Oracle, פרוייקטי הקוד הפתוח נסגרו ומה שנשאר בחוץ – היווה הבסיס ל-ZFS שבשנים האחרונות קיבל Push משמעותי באותן הפצות יוניקס, כמו גם ZFS על לינוקס (שנקרא במקרים רבים ZoL, כלומר ZFS On Linux).

כיום ישנן הפצות יוניקס "ידידותיות" כמו FreeNAS ואחרות שמיועדות לרוץ מ-Disk On Key על מחשב פשוט, ובכך ניתן תוך דקות ספורות להרים "שרת" שיתן שרותי שיתוף שמערכת הקבצים הינה ZFS. ישנה גם מערכת של חברת Nexenta שרצה תחת גירסת קוד פתוח של Solaris אשר מאפשרת לך להרים בעזרת ממשק Web (לא ממש ידידותי, לעניות דעתי) מערכת ZFS.

האם אני ממליץ על מערכות אלו ל-Corporate? לא כל כך, וברשותכם, אסביר.

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

המצב שונה לחלוטין בגרסאות BSD למיניהן, וגם בגרסאות הקוד הפתוח של Solaris (כמו Open Indiana) – שם כמות הפיתוח נמוכה משמעותית ובמקרים רבים היא נעשית ע"י חברות קטנות שמפתחות דרייברים עבור שרת מסוים או Appliance מסוים. אם זה ירוץ על כרטיסים אחרים – מה טוב, ואם לא .. אז תממן פיתוח (כפי שאמרו לי חברת iX systems כשניסיתי להריץ FreeNAS ללקוח עקשן על שרתי DELL מסדרות R7XX).. כמה חברות אתם מכירים שמוכנים לשפוך כמה עשרות אלפי דולרים על פיתוח דרייברים בשביל שמערכת כלשהי תרוץ על שרת שהם רוצים? לא הרבה.

ומה עם אורקל? או, שאלה מצויינת.

אורקל מפתחת דרייבים ל-Solaris הסגור כל עוד השבבים נמצאים בתוך השרתים שהם מוכרים והם גם תומכים ומתקנים באגים אך לשם כך עליך להשתמש ב-Solaris הסגור (ואם אינך משתמש במכונה של Sun/Oracle, התעריף למערכת ההפעלה נע בין 1000-3000 דולר למכונה עם 1-4 מעבדים + 200 דולר עבור DVD – התקליטור, לא הכונן) ומחיר זה מקנה לך את מערכת ההפעלה עצמה, שום דבר אחר.

cw20v1-zfs-zs3-ba-04-2267398לאורקל יש ארונות שלמים וגם פתרונות של 4U, 20U ו-36U (תוכל לראות את הדגמים כאן) והמחירים כמובן בשמיים. על גירסת 4U לדוגמא שנותנת 6 טרהבייט (שמורכבים מ-20 דיסקים של 300 ג'יגה + מאיץ כתיבה [כונן SSD]) תצטרך לשלם פה בארץ משהו כמו 200,000 שקל (יש צורך להוסיף מיסוי, תוספת של יבואן וכו' למחיר המופיע בקישור). חשקה נפשך במשהו שנותן כמעט 400 טרהבייט של אחסון מהיר? המנכ"ל יצטרך להיות מעורב, כי בארץ זה יצא בערך מיליון שקל וגירסת ה-736 טרהבייט תצא בין 1.5-2 מיליון שקלים. אגב, מחירים אלו כוללים תמיכה רק לשנה הראשונה. לשנה השניה והלאה, יש צורך בהפרשה של סכומים ניכרים נוספים לתמיכה.

במחירים כאלו, אני בהחלט ממליץ לבדוק פתרונות מתחרים, למרות היתרונות הרבים של ZFS.

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

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

אז מה ההמלצה שלי? המלצתי מחולקת למספר חלקים:

  • אם אתם לוקחים PC פשוט ולא חדש (כלומר שיש לו תמיכה ב-BIOS או ב-Legacy Mode ב-UEFI) ויש לכם את הכח ללמוד ולהתנסות על דרך הלימוד והטעיה ואתם צריכים ממשק WEB ולהרים מערכת עכשיו – אתם יכולים לנסות את FreeNAS. החסרון: תמיכה בפורומים לפי המזל שלך. בעבר שיגרתי כמה בעיות רציניות שגיליתי עם FreeNAS שהיה מחובר ל-VCSA, רק כדי לגלות שאף אחד לא עונה.
  • אם המכונה היא PC (לא חדש) או שרת ישן (בן לפחות 3-4 שנים) עם BIOS, אתם יכולים להתקין Nexenta (כל עוד המערכת תכיר בדיסקים, בקרים, רשת ושאר ציוד, לא תמיד הציוד מוכר) עם מגבלה של גירסת ה-Community שלא מקבלת תמיכה רשמית, והגודל (ברוטו) אינו יותר מ-18 טרהבייט (כך שאם יש לך 2 דיסקים של 3 טרהבייט והם יהיו Mirror, אז החישוב הוא של 6 טרה, לא 3). מעבר לכך, המחיר הוא בערך $1800 דולר לשנה (אתם יכולים לראות רשימת מחירים של משווקים שלהם כאן) והמחיר עולה בהתאם לכמות האחסון וברמת התמיכה הרצויה.
  • אם מדובר בשרת רציני או שרת חדש (2 מעבדים ומעלה, 16 ג'יגה זכרון ומעלה, כמות רצינית של דיסקים) ואתם צריכים משהו חזק ויציב – אז ZFS שרץ על לינוקס יכול להוות פתרון מעולה (אפשר ליצור במייל קשר בנושא).

בפוסט הבא אסביר את ההבדל בין ZFS ל-File systems "מתחרים" שקיימים בשוק. פוסט נוסף שמסביר יותר לגבי חסרונות של ZFS On Linux ותשובות לבעיות – מופיע כאן.

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

שימוש ב-ZFS בשרת קבצים מבוסס לינוקס

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

יש בחברה שרת קבצים מאוד רציני שנותן שרותים שונים: CIFS/SMB, NFS, iSCSI ועוד. הוא מתממשק ל-Active Directory של החברה ודרכו שרתים שונים ותחנות עבודה מקבלים שיתופים שונים, הן בצורת "כוננים", כ-LUN וכו'. שרת הקבצים הזה (יכול להיות של NetApp או EMC או של IBM לדוגמא) מאוד קריטי בחברה והוא מאוד יקר, הן מבחינת תכנים שיש עליו והן מבחינת ה"ברזלים" שבו. כל מגהבייט מחושב בקפידה ואי אפשר לבוא למי שמנהל אותו ולבקש "תן לי 2 טרהבייט LUN למספר בדיקות שאני צריך לעשות". בקשה כזו בד"כ תצטרך להיות מלווה בנוהל שמצדיק את המקום, עם תאור מה הולכים לעשות ולמה צריכים את המקום, במקרים רבים יש ישיבות ולבסוף מחליטים אם לאשר או לא, ואם התשובה היא שלילית, ינתן פתרון אלטרנטיבי כלשהו.

מוכר לכם? גם לי זה מוכר.

סיטואציה נוספת שקיימת היא שיש צורך בשרת קבצים מחלקתי, נניח עבור קבוצת מפתחים, ומפתחים בד"כ "משתוללים" עם הצרכים שלהם. הם משתמשים ב-Version Control כלשהו ש"מטיס" המון קבצים מפה לשם, פתאום לכל משתמש יש כמה מאות קבצים בתיקיה והמספר הולך וגודל בקצב מהיר מאוד, לפעמים יש גם צורך בהקמת מכונות וירטואליות לטסטים שצריכים לא רק מקום אלא גם חיבור מהיר ותגובה מהירה מצד השרת (שלא לדבר על קצב IOPS…). כל הדברים הללו יכולים לשבת בשרת קבצים יקר, אך אם תשאלו כמעט כל מנהל Storage, הוא יעדיף שאת כל ה"השתוללות" הזו שתבוצע בשרת קבצים אחר ופעם ביום יהיה גיבוי אליו שלאחר מכן יועבר למערכת הגיבוי המרכזית, לדוגמא. אני לא מכיר אף מנהל מערכת Storage שממש מחפש לראות איך המערכת שלו "נחנקת" על ידי 1001 דברים שאפשר להפנות אותם לפתרונות משניים.

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

  • הביצועים של שרת כזה במקרים רבים הם לא בדיוק מהירים, במיוחד שמחברים אותו לשרותים תובעניים כמו vSphere. ב-vSphere אם לדוגמא תרים מכונות וירטואליות דרך NFS, וכל הדיסקים בשרת קבצים הם דיסקים מכניים (לא SSD) – אתה תכיר את העובדה ש-vSphere מחכה בכל פעם שיש כתיבה לדיסק דרך NFS, שהשרת קבצים באמת כתב כל בייט לדיסק (תקימו מכונת VM מבוססתWindows 7 או 8 ותראו זאת כבר בהתחלה, לדוגמא).
  • גיבוי של שרת כזה מצריך לעיתים פתרונות די "יצירתיים". אם אתה משתמש ב-LVM על הלינוקס, אתה יכול להשתמש בפונקציית ה-Snapshot שלו, אך פתרון זה הוא פתרון די מורכב (והוא בכלל ברמה של מתחת ל-File system). אם תשתמש בפתרונות מבוססים tar או rsync, סביר להניח שתיתקל בבעיות אחרות (במיוחד שכל המכונות הוירטואליות רצות), שלא לדבר על ביצועים נחותים יותר בזמן הגיבוי. (אפשר כמובן לגבות מכונות וירטואליות עם VEEAM לדוגמא, אבל אז מדובר בצורך ברכישת רישוי וכו').
  • אם יש לך הפסקת חשמל או ששרת הקבצים נופל בגלל סיבה כלשהי (בעיות בקר דיסק לדוגמא או כבל SAS סורר), תצטרך לטפל בשרת קבצים ולקוות שה-VMs לא נדפקו, במיוחד אם הם היו עסוקים בפעילות אינטנסיבית של כתיבת קבצים רבים ורק אחר כך לטפל בכל המערכת וירטואליזציה, והסיפור נהיה יותר מורכב כשמדובר ב-Version Control שונים.
  • ויש עוד מספר אתגרים. (חוק מרפי מאוד אוהב מצבים כאלו).

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

  1. מבחינת "חזרה לאחור" (הערה: snapshots בכל מערכת אינם גיבויים), אפשר לבצע snapshots מיידים שלא לוקחים כמעט שום מקום ואותם snapshots זמינים מיידית לקריאה והעתקה מהם/שחזור מהם. כך לדוגמא אני מממש סכמת Snapshots:
    1. יצירת snapshot כל רבע שעה (בשיטת FIFO כך שהראשון מושמד בהתחלת שעה וכו')
    2. יצירת snapshot כל שעה עגולה (שוב, בשיטת FIFO) כאשר ה-24 ה-snapshots האחרונים זמינים לי.
    3. יצירת snapshot יומי לכל החודש (31 סטים סה"כ)
    4. יצירת snapshot שבועי (4 סטים סה"כ)
    5. יצירת snapshot דו שבועי (2 סטים סה"כ)
    6. יצירת snapshot חודשי (12 סטים)
  2. לכל הקבצים במערכת יש checksum שנכתב ונבדק אוטומטית ע"י ה-ZFS, כך שאני בטוח מבחינת קבצים וסקטורים מקולקלים. יש בעיה בקובץ? ה-ZFS יקח אוטומטית את הקובץ ממקום אחר (mirror).
  3. אין לי צורך בשום LVM, ואני ממש לא צריך לחשוב על Partitions למיניהם, שלא לדבר על מקום שנגמר בווליום כלשהו. ב-ZFS הכל מחובר ביחד ואפשר לתת מקום לכולם ומצד שני אפשר להגביל מקום או לשמור מקום לצרכים שונים.
  4. יש לי את כל השרותי שיתוף שאני צריך זמינים מיידית. כך לדוגמא אם אני רוצה להגדיר שיתוף NFS, באותה שורה שאני יוצר את השיתוף דרך ה-command line, אני יכול לאמר לו מה יהיה השיתוף ועם מי. גם מבחינת iSCSI אני לא צריך להסתבך יותר מדי ואני יכול להגדיר לי אחד בגודל שאני רוצה (כולל תמיכה ל-thin provisioning) בפקודה אחת פשוטה.
  5. בסופ"ש מערכת ZFS יכולה להריץ פעולת "קרצוף" (scrub) שבודקת כל כל הקבצים בכל הדיסקים ומסמנת לעצמה מה תקין ומה לא ויודעת לנתב אוטומטית ולמפות לעצמה את התוצאות קרצוף.
  6. אני יכול בעזרת מספר פעולות פשוטות לראות איך הביצועים של המערכת מבחינת שיתוף התוכן ולראות היכן הביצועים יורדים, כך שאני יכול לתכנן איך אשדרג כדי לקבל ביצועים יותר גבוהים.
  7. אני יכול להגדיל את המערכת לכמה שצריך, תיקיות יכולות להכיל מאות אלפי או מיליוני קבצים מבלי לשתות קפה ולהמתין לקבלת פלט של ls בתיקיה "מפוצצצת" בקבצים. אין שום בעיה לצרף מספר JBODs כדי לקבל מאות טרהבייטים, פטהבייטים ומעלה.
  8. החלפת דיסקים היא פעולה פשוטה מאוד, ואני יכול להגדיר מערכי RAID (שנקראים RAIDZ ב-ZFS) שבהם גם מצב ש-3 דיסקים הם תקולים – המערכת תמשיך לעבוד.
  9. חשוב: אני לא חייב שכל הדיסקים יהיו SSD או SAS. אני יכול להשתמש בדיסקים מבוססי SATA (אני ממליץ על סידרת Red Pro של WD) ואני יכול להסתפק בכמות מצומצמת (מומלץ 2) של כונני SSD (לא חייבים סדרות שמיועדים ל-Enterprise) על מנת לקבל ביצועים טובים.
  10. אין לי יותר את הבעיה של הפסקת חשמל פתאומית בזמן שהמערכת בדיוק כתבה קבצים, כי ZFS מכיל דבר שנקרא ZIL שיודע להסתדר לבד ברגע שהחשמל יחזור (תאמינו לי, מנסיון של הפסקות חשמל מהסופות האחרונות, זה עובד יופי).
  11. אין לי צורך בבקרי RAID יקרים עם זכרון CACHE או סוללת גיבוי. יספיק לי כרטיס RAID פשוט במצב טיפש (JBOD).
  12. מבחינת גיבוי שרת הקבצים, 2 פקודות פשוטות יבצעו לי גיבוי מהיר לשרת ZFS משני או שאני יכול להתקין כל Client של מערכת גיבוי מרכזית, היא תראה את השרת ZFS כשרת לינוקס רגיל, כל מה שאני צריך זה להגדיר מה אני רוצה לגבות.
  13. אם כבר דיברנו על גיבוי – קל מאוד להתאים אותו לשימוש עם Windows, כך שגם משתמש פשוט יוכל לשחזר קבצים שלו דרך Restore Previous Versions ב-Windows במקום לבקש שישחזרו לו מגיבוי שנמצא על קלטות..

ואפשר גם לגדול:

  1. יש לך כמות דיסקים גדולה בשרת ואתה רוצה שקט נפשי? חלק את הדיסקים ל-2 בקרים שונים (בגלל שזה ZFS הבקרים יכולים להיות בקרי LSI מבוססי SAS2008 פשוטים שאפשר לקנות ב-100$) ומכיוון שאתה רץ על לינוקס, לא תהיה ללינוקס להכיר גם ב-5 בקרים על שרת אחד (מנסיון..)
  2. צריך לשרת יותר שרתים/תחנות? בשמחה! אתה יכול להשתמש ב-Lustre או Gluster עם ZFS, בין אם בשיטה של Active/Active או Active/Passive.
  3. צריך יותר רוחב פס? אתה משתמש בלינוקס, ולינוקס תומך כבר בכל כרטיס שנותנת תקשורת כלשהי, בין אם זה 10G או 40G או אפילו 100G, בין אם מדובר ב-Infiniband וגם פתרון משולב כמו FCoE וגם פתרונות של מספר כרטיסי רשת שונים באותו שרת. הכל רץ ונתמך בלינוקס.
  4. ZFS הוא מאוד גמיש, אפשר להתאים אותו החל מצרכים שלא דורשים הרבה תעבורה החוצה (לדוגמא: ארכיב), או הפוך (לדוגמא: VOD). אפשר להתאים אותו לצרכים תובעניים (לשרת הרבה מכונות VM, בין אם ה-Hypervisor או Hyper-V, vSphere, Xen או KVM).

ZFS הוא שילוב מעולה בין לינוקס למערכת File System הכי טובה שיש כיום. הפצות לינוקס כמו Red Hat או CentOS (וגם SuSE) יודעות לתמוך בשרתים החל מהרמה של שרתים מבוססי מעבדי Atom (סדרות C2XXX) ועד שרתי מפלצת עם 8 מעבדים ו-4 טרהבייט זכרון. לינוקס דואג לכל עניין תמיכת החומרה מבחינת דרייברים בהכל ובצורה הרבה יותר טובה מכל מערכת הפעלה מבוססת יוניקס אחרת (על כך הפוסט הבא ירחיב). ZFS משתלב עם הלינוקס המותקן כך ש-ZFS לא צריך לדאוג לשכבות מתחת ל-File System (חומרה ודרייברים).

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

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