הבדלים בין Snapshot לגיבוי

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

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

  • מימוש ראשון VMWare Snapshot
  • מימוש שני – AWS Snapshot

נאמר שיש לנו VM שיש בתוכו קובץ טקסט שבו כתוב "חץ קנה פיתה". נשמור את הקובץ וניצור Snapshot. עתה, נפתח את הקובץ הנ"ל ונשנה את הטקסט כך שיהיה כתוב "חץ קנה פיתה עם פלאפל". נשמור את הקובץ באותו שם.

עכשיו נעקוב אחר התהליך הנ"ל מקרוב. ברגע שיצרנו את ה-Snapshot לאותו VM, הוא מתחיל בגודל 0 בתים (או משהו קרוב לכך, יכול להיות שה-snapshot יכלול בתים ספורים בהתחלה). ברגע שערכנו את אותו קובץ טקסט ושמרנו אותו, הוא אינו שומר את השינוי לדיסק הקשיח הוירטואלי, אלא שומר אותו לתוך ה-snapshot. אם נבדוק, נוכל לראות שגודל ה-snapshot גדל בכמות הבתים שהוספנו לאותו קובץ טקסט (את הדברים הרבה יותר קל לראות "מבפנים" אם משתמשים במערכת ZFS, שהיווה "השראה" ל-VMWare כיצד ליצור snapshots). אם לאחר שיצרנו קובץ Snapshot, עבר זמן ויצרנו קובץ snapshot חדש, כל השינויים שניצור מעתה ישמרו ב-Snapshot החדש, וה-snapshot הקודם יעבור למצב read only.

המימוש השני של snapshot לשם הדוגמא יהיה AWS EBS Snapshot: הקמנו Instance (כלומר VM) עם מערכת ההפעלה שבחרנו, ולאחר מכן ביצענו מספר שינויים בהגדרות, הוספנו אפליקציות ועוד, וכעת אנחנו יוצרים Snapshot ב-AWS. ה-Snapshot הראשון שניצור ישמור את השינויים מהקמת ה-VM עד לרגע זה. אם ניצור Snapshot נוסף, הוא ישמור את השינויים שנוצרו מאז ה-Snapshot הראשון, כלומר כל שינוי שביצענו אחר ה-Snapshot הראשון ישמר בדיסק EBS ולא ב-snapshot ורק אם ניצור snapshot נוסף, השינויים יועתקו אליו.

המימוש של AWS Snapshot מאוד דומה לגיבוי אינקרמנטלי שאפשר ליצור עם תוכנת גיבוי לטייפ או VTL – אנחנו קודם כל יוצרים גיבוי מלא, ולאחר מכן כל גיבוי אינקרמנטלי מגבה בעצם את השינויים (Delta) מאז הגיבוי המלא האחרון.

מכאן נעבור לנקודה היותר "פילוסופית" – האם snapshot יכול להחליף את מקומו של הגיבוי? זה תלוי.

במקרים כמו VMWare התשובה היא "לא ממש" הואיל ויצירת Snapshot הוא דבר שצריך לבצע "ידנית". המערכת לא תיצור עבורך snapshot אוטומטית (למרות שלמערכת יש בהחלט דבר שנקרא Changed Block Tracking שמופעל אוטומטית ובכך המערכת יודעת לזהות כל שינוי שבוצע בדיסק, ואין זה משנה איזו מערכת הפעלה מדובר, כי אותה מערכת עובדת בבלוקים, לא ב-File system) ולכן גיבוי של המערכת ע"י תוכנת גיבוי (Veeam, Arcserve ושאר תוכנות) היא דבר חשוב ואף הכרחי.

בעננים ציבוריים כמו AWS לעומת זאת, יש צורך לעבוד בשיטה שונה (שלצערי יש לא מעט שמתחילים לעבוד עם AWS ולא מפנימים זאת): ב-AWS כדאי לבנות את מכונות ה-VM כ"שלדים" (templates) ולשמור את הקבצים המשתנים ב-EFS או ב-S3. כך, בונים VM, מגדירים את הדברים הקבועים, מוסיפים סקריפט שידע להעתיק את הקבצים הנחוצים מ-S3 או EFS, יוצרים snapshot ולאחר מכן ממירים את זה ל-Image בפורמט AMI סגור. נדפק ה-VM? פשוט מקימים חדש מה-AMI כשאחד הפרמטרים הוא בעצם הרצה של הסקריפט שיצרנו כך שלאחר הקמת ה-VM/Instance – הוא יעתיק את הקבצים וידווח לנו מה כתובת ה-IP הפנימית של ה-VM החדש.

ב-ZFS הדברים שונים. מכיוון ש-Snapshot ב-ZFS אינו תופס מקום בדיסק (0 בתים), ישנה שיטה פשוטה ליצור אוטומטית snapshots כל זמן שתרצה. אני לדוגמא עובד עם ZFS שיוצר snapshots כל שעה, כל יום, כל שבוע, כל חודש, כל שנה – ומגדיר את המערכת שתשמור לי 50 snapshots אחורה. מבחינת שרידות, ZFS תומך במערך RAID (שנקרא RAIDZ) עד רמה שלישית (כלומר: המערכת יכולה לתפקד עד למצב שבו יש שלושה דיסקים תקולים) עם תמיכה מלאה ב-Hot Spare. מעבר לכך, מערכת ZFS נותנת גם "להשתולל" עם מערכי RAIDZ כך שניתן להקים שתי מערכות RAIDZ3 ולצוות אותן יחד כ-RAIDZ1. בזבוז מטורף של דיסקים? בהחלט, אבל למי שיש תקציב – בכיף. מה עם גיבוי לטייפ? יש כאלו שמגבים אחת לזמן מה לטייפ ויש כאלו שפשוט מעדיפים להשתמש בתשתית ה-ZFS ופקודות ה-send/receive המובנות על מנת לגבות את ה-ZFS למערכת מרוחקת. (אפשר כך לבנות אחסון DR בזול. אגב, מקומות רבים בחו"ל משתמשים בשיטה הזו).

לסיכום: "snapshot אינו מחליף גיבוי" – זו הצהרה שאינה נכונה תמיד. יש מקרים שזו הדרך היחידה שלך לגבות (עננים ציבוריים), ויש מקרים שמימוש ה-Snapshots (כמו ב-ZFS) אינו מצריך גיבוי לקלטת כל יום. לגיבוי יש מקום חשוב ול-snapshot יש גם מקום חשוב וביטול אחד ו"הילול" הדרך השניה אינה בהכרח התשובה הנכונה.

על דיסקים מכניים גדולים ו-RAID

מי שעוקב אחרי חדשות טכנולוגיות יכול למצוא אחת לכמה חודשים הכרזות של יצרני דיסקים שונים על דיסקים חדשים, לפעמים על שיטת קריאה/כתיבה חדשה. כך לדוגמא, חברת Showa Denko K. K. הכריזה כי היא סיימה לפתח ראש MAMR חדש לדיסקים קשיחים עבור חברת טושיבה, וטושיבה תוציא דיסקים קשיחים בגודל 18 טרה המבוססים על טכנולוגיה זו במשך השנה. צפו להכרזות דומות מצד שאר היצרנים.

כיום, בין אם יש לך שרת שאתה מכניס בו דיסקים קשיחים ומחבר אותו לבקר RAID כלשהו, ובין אם יש לך סטורג' קנייני – כל היצרנים ישמחו למכור לך דיסקים קשיחים גדולים – בין אם ישירות מיבואן יצרן הדיסקים ובין אם דרך החברה שרכשת ממנה את השרת או הסטורג'. רוצה מדף עם 12 דיסקים של 10 טרהבייט? בשמחה! תחתום פה ופה, תעביר כרטיס אשראי או תשלח צ'ק וטכנאי בדרך אליך להתקין את המדף לסטורג' ולהגדיר אותו. אין צורך לדאוג, גם הדיסקים הגדולים שנמכרים כיום נמכרים עם SAS Dual Port לחבר ל-2 כרטיסי RAID (אם אתה רוצה להכניס את זה לשרת, בסטורג' זה אוטומטי).

אבל האם זה שווה לרכוש את הדיסקים הללו? בכל זאת, אם קנינו מדף של 12 דיסקים בגודל 10 טרה, אנחנו נקבל ברוטו 120 טרהבייט, זה שקט להרבה זמן מבחינת אחסון פנוי!

בעבר כתבתי על הנושא והצרות עם זה, ועכשיו גם חברת Western Digital, אחת מחברות יצרני הדיסקים הגדולים – כותבת על כך (ואני ממליץ מאוד לקרוא את הפוסט!). הסיבה שהם כותבים היא כמובן כדי לדחוף 2 מוצרים שהם מוכרים. אני לעומת זאת כותב מהנקודה היותר פרקטית – של סכנה.

לשם פוסט זה, נניח ויש לנו את ה-12 דיסקים של 10 טרה, והם מורכבים בסטורג' או בשרת עצמאי עם 2 בקרי RAID (או אחד, זה לא ממש משנה מבחינת מהירות קבלת נתונים, ה-Dual Port ב-SAS הוא יותר לשרידות, אם כי במצב שהולך לך בקר, אני הייתי ממליץ לך להשבית את השרת עד שיגיע טכנאי עם חלק חלופי. אתה לא רוצה לסכן את ה-DATA שלך!). נניח שהגדרנו RAID, נניח 5 או 6 (במצב של 1 זה הרבה יותר מסוכן) או כל "RAID" בסטורג'.

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

וכאן… מתחילות הבעיות והסיכונים צצים…

  • אם הדיסקים נמצאים בשרת והם מחוברים לבקר RAID (וזה לא חשוב איזה RAID הגדרתם, למעט כמובן 0 שאז הלך ה-DATA) – השחזור לא רק שיהיה איטי ויקח מספר ימים, אלא שאתם תסבלו מביצועים נמוכים מאוד באותם ימים הואיל וכל מערך ה-RAID צריך לעבוד בעצם כפול: גם לשרת את הצרכים שלכם, וגם לקרוא מהחלקים השונים של הדיסקים על מנת לכתוב את ה-DATA מחדש על הדיסק החלופי.
  • מכיוון שאתם מאמצים את המערכת – יש סיכוי שדיסק נוסף יפסיק לעבוד, הואיל והמערכת עובדת נון סטופ.
  • במקרים של שרת ו-RAID מבוסס בקר חומרה, הכתיבה היא "הכל" – גם אם היה לכם ב-RAID חומר בגודל 10 ג'יגהבייט, הוא יבצע Rebuild של 10 טרהבייט, מכיוון שבקר RAID הוא דבר די טיפש.
  • במקרים של סטורג' (או Software defined Storage) – שיטת ה-Rebuild תהיה שונה, וכמות ה-DATA שתיכתב על הדיסק תהיה כמו שאר הדיסקים באותו "RAID", כך אם יש חומר של 10 ג'יגה, יכתב 10 ג'יגה. ההבדל הגדול בין סטורג' לבין שרת עם בקר RAID חומרה – זה שהסטורג' יודע "להסתיר" את האיטיות עם דיסקים SSD, עם Flash Cache וטריקים אחרים, אבל עדיין – תורגש איטיות.

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

  • חברו את הדיסקים ל-HBA ולא לבקר RAID (אפשר לרכוש בקרי LSI עם IT MODE או להחליף להם קושחה).
  • השתמשו בתוכנה כדי לבצע RAID. יש הרבה פתרונות – החל מ-FreeNAS, ZFS, XPEnology, או Storage Spaces של מיקרוסופט. הכל תלוי בהעדפה שלכם.
  • השתמשו ב-SSD שהוא Mixed Intensed או SSD שמתאים ל-Enterprise אם המהירות חשובה לכם. ההמלצה שלי היא ללכת על Optane 900P או DC P4800X (אם יש לכם את התקציב) של אינטל על מנת לקבל Latency מאוד נמוך וביצועים גבוהים מאוד (שימו לב – אם השרת אינו חדש, אז ה-Optane לא יוכל לבצע Boot ואם בשרת אין תושבות PCIe 3.0 – אז הוא לא יעבוד).
  • אם אתם משתמשים ב-ZFS, אל תשכחו להגדיר תהליך "קרצוף" (scrub) של הדיסקים לפחות אחת לשבוע (התהליך עובר על כל ה-DATA והיכן שהוא מוצע בעיות, הוא משכתב את ה-DATA למקום פנוי אחר, כך שהעבודה תהיה חלקה).
  • גיבויים, גיבויים, גיבויים – תוכנות גיבוי זה טוב, אבל snapshots ברמת האחסון הם יותר טובים והשחזור הרבה יותר מהיר. דאגו שתהיה מכונה אחרת עם מקום פנוי לקבל את ה-Snapshots.

ככלל, לא חשוב אם האחסון שלכם הוא NAS שבניתם או סטורג' שקניתם, אם כמות האחסון שלכם נעה בין מאות טרהבייט לפטהבייט – עדיף לעבור לפתרון Scale Out (וכשאני מדבר על Scale Out אני מדבר על מספר מכונות [גם נקראות Nodes]) המכילים את הדיסקים או JBOD המחוברים לאותן מכונות. פתרונות כאלו יודעים להתמודד גם עם מצבים שמספר דיסקים קשיחים מתקלקלים במקביל ומענה לדרישה מוגברת של תעבורת נתונים הלוך ושוב לשרתים/מהשרתים.

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

כמה מילים על 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 החופשי

[stextbox id='info' caption='הערה לקוראים']למי שרק החל לעקוב אחרי בלוג זה, בעבר כתבתי כמה וכמה פוסטים על ZFS וניתן למצוא אותם כאן[/stextbox]

אנחנו בשנת 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).

[stextbox id="info" caption="גילוי נאות"]כותב שורות אלו מוכר שרותי יעוץ/הקמה/הגדרות למערכות יוניקס/לינוקס עם ZFS[/stextbox]

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 שונות ולבדוק את טיב הביצועים ואז להחליט.