הקשחת שרתים במבט יותר עמוק

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

הדבר הראשון שצריך להבין לגבי ההקשחות זה שתלויות חיצוניות לא תמיד עוזרות או לא עוזרות הרבה. ה-Firewall שיש בחברה לדוגמא כמעט ולא רלוונטי לנושא. כן, הוא יכול לזהות שכתובת IP מסויימת מנסה להיכנס, דרך פורט מסוים, אבל ה-Firewall לא יודע ולא יכול לדעת אם הפורץ הצליח להיכנס, ואם הצליח, באיזה קבצים הוא נגע. בלינוקס יש דבר שנקרא access time לדוגמא שיכול לאמר איזה משתמש נגע באיזה קובץ ומתי, אבל אם הפורץ כבר יצא והמשתמש הלגטימי (עם אותו username) נכנס ועבר על הקבצים, אז הרבה פעולות פורנזיות לא יעזרו הרבה לדעת מי נכנס ובמה הוא נגע (מה עוד שבימינו פורצים רציניים משתמשים ב-VPN ושלל טריקים נוספים להחביא את זהותם כך שמאוד קשה לדעת מי בדיוק נכנס). ישנם כלים אחרים שעובדים עם חתימות שונות כדי לזהות כניסות דרך שיטות ידועות וזה עוזר, אבל שוב – לא תמיד זה יעזור ותיכף ארחיב על כך.

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

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

עוד נקודה שרבים שוכחים היא פורטים 80 ו/או 443. בד"כ הם פתוחים לעולם, וכאן גם מתרכזת בעיה רצינית: קיימים לא מעט סקריפטים שיתנו מעין shell גם אם ל-user שמריץ את שרת ה-web אין בכלל גישת shell מכיוון שלמודולים שרצים תחת אותו שרת web יש אפשרות לבצע דברים שונים הקשורים ל-shell. דוגמא נפוצה עם PHP היא [email protected] ומשם אפשר לבצע נזקים רבים, ולכן צריך לקחת בחשבון מה רץ בשרת ה-web ומה רץ "מאחורה", והכי חשוב – בדיקת ההזנה של המידע המגיע מהאינטרנט אל שרת האפליקציות לדוגמא (זהו החלק שקשור לצוות הפיתוח או מי שמריץ pen-testing).

עוד נקודה חשובה היא היכולת לזהות פורנזית אם מישהו פרץ – במה הוא נוגע. נכון, סביר להניח שחברה רצינית תכניס פתרון IPS/IDS כלשהו, אבל פתרון כזה אינו מסייע אם הפורץ הצליח להיכנס ולפתרון ה-IDS/IPS אין מושג ירוק מה הפורץ עושה בשרת עצמו. אפשר כמובן לגלות עם ה-IPS/IDS אם הוא מעלה/מוריד קבצים לשרת שהוא פרץ, אבל מה אם הפורץ מחליט למחוק קבצים? לשם כך יש צורך בפתרון שהוא בעצם Host IDS (כלומר: HIDS) שיודע לזהות את הדברים ולרשום במה הוא נגע, איזה process הוא הפעיל ועוד ועוד. שילוב פתרון כזה אפשרי אבל מצד שני יכול גם להאיט את ביצועי השרת ולכן אם הלקוח רוצה בפתרון כזה, יש להיערך לכך מבחינת שרתים שנותנים שרות, היכן יאוחסן המידע מהניטור ועוד ועוד.

והדבר הכי חשוב: לא חשוב מי עושה הקשחה לשרת שלכם, לא מדובר בעבודה של "אי בודד" (כלומר האינטגרטור מקבל IMAGE ועושה עבודה משלו, מגיש את ה-IMAGE המעודכן ותיעוד, מקבל כסף ולהתראות), אלא מדובר ב"פינג פונג" בין האינטגרטור למחלקות שונות בחברה. אני יכול להקשיח שרת לעילא ולעילא אבל אם הקוד שרץ על השרת הוא קוד שאינו בודק מה הוא מקבל בצורה רצינית – אז הפורץ יכול להיכנס למערכת די בקלות. אם אין שום Penetration testing, אז שוב – הפורץ יכול להיכנס בקלות. יש גם צורך בלעבוד עם ה-IMAGE כדי לראות האם יש צורך לשנות על מנת לקבל ביצועים יותר גבוהים, כמות clients יותר גבוהה, ועוד ועוד, כך שזהו תהליך שיכול לקחת ימים או שבועות, לא יום או יומיים וזה שונה מחברה לחברה.

לסיכום: בכל הקשור ללינוקס, אפשר להקשיח שרת בצורה מעולה, אבל זה מצריך עבודה ולא איזה סקריפט שישנה דברים פה ושם. אצל כל לקוח הדברים שונים, ויש דגשים שונים בין הצרכים. חשוב לזכור ששרת אינו עובד כדבר עצמאי ולכן יש לדאוג לחלקים נוספים, בין אם השרת רץ כשרת פיזי או VM אצלכם בחברה או רץ כקונטיינר(ים). אם אתם עובדים בענן, אז אחד הדברים בנוסף להקשחות שצריך לדאוג לגביהם – זה Firewall וכלי שנותן גם IPS/IDS כי ספק הענן לא מגן על שום דבר שיש לכם בענן – ומה שהכי חשוב – זה שיתוף פעולה בין מי שמקשיח לבין הצוותים השונים, על זה דברים יפלו או יקומו.

כמה מילים על 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 הוא פתרון חלופי לסטורג' סגור – במקרים מסויימים כן ובמקרים מסויימים לא (תלוי בדרישות ובצרכים), אבל הוא מאוד מתאים אם חברה מחליטה להקים סטורג' קטן והיא מוכנה להשקיע את שעות העבודה כדי לבצע אופטימיזציה וזה לוקח זמן (לפי הידע של מי שמבצע זאת), זה לא משהו שנעשה בחצי יום, וצריך לעיתים להקים מערכת שלמה כדי להגדיר לבדוק את הביצועים.

על לינוקס, VMWare וטעות הקשורה לחיישנים

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

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

אם יש לכם שרתים שמריצים VMWare, אחד הדברים החשובים שתרצו לדעת הוא מה מצב החיישנים במערכת. מה הטמפרטורה של המעבד, דיסקים, ספק כח, חום פנימי בשרת, מצב תקלות זכרון ודברים כאלו ואכן, עד גירסה 6 של vCenter קיבלתם את המידע כולו בתצורת עץ. המידע הזה חשוב (וגם ניתן לקריאה על ידי תוכנת הניטור שלכם דרך SNMP). עד גירסה 6 ה-vCenter עשה משהו פשוט מאוד: הוא פנה לכל שרת ESXi שרשום ב-vCenter וקרא ממנו את הערכים. איך ESXi קורא את הערכים? בעזרת חבילה שכלולה בכל הפצת לינוקס שנקראת lm-sesors והיא קיימת בכל התקנה של שרת ESXi. החבילה הזו מעודכנת כל הזמן וכל עוד הקרנל בלינוקס מעודכן, תוכל לקרוא את כל החיישנים במערכת, וזה רץ על כל מערכת, בין אם מדובר במחשב נייד, בדסקטופ, תחנת עבודה או שרת מפלצתי.

בגירסה 6.5 ל-VMware "קפץ הפיוז" והם החליטו שה-vCenter (בין בגירסת Windows או VCSA) לא יקרא יותר את החיישנים מה-ESXi (שכבר יש לו את הנתונים שמתעדכנים כל 90 שניות), אלא יפנה אל ה-IPMI. למי שלא מכיר – בכל לוח אם של שרת יש רכיבים שנותנים ניהול מרחוק, אתם אולי מכירים את זה בשמות כמו ILO, IMM, iDRAC – וכולם בעצם מממשים פחות או יותר את סטנדרט IPMI לשליטה מרחוק על המכונה. הבעיה, כמו תמיד, שיש לא מעט מקרים שהמימושים הם לא ממש משהו או שהיצרן החליט להתעלם מחלק מסטנדרט ה-IPMI. אחרי הכל, למשתמש יש גישת CLI או גישת Web לניהול מרחוק, אז אפשר להחביא את המימוש העקום מתחת לשטיח.

וזה משהו שב-VMWare לא ממש התעמקו כנראה. מבחינתם, החל מגירסה 6.5, יש שרות שנקרא wbem ויש API לפונקציה שנקראת HostConfigManager.healthStatusSystem והיצרן צריך לכלול (או לשחרר) VIB שכולל את הגישה לניהול מרחוק של השרת, כך שבתאוריה המנהל יצטרך רק להכניס פרטי התחברות ל-IMM/IDRAC/ILO והמערכת תתחיל לקרוא את החיישנים ישירות מהניהול הרחוק.

במציאות .. זה לא ממש עובד. כך לדוגמא אחד השרתים שלי (גם אחרי התקנת ה-VIB) מראה תצוגה של החיישנים בכל שרת (לחצו להגדלה):

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

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

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

נקודות חשובות בשדרוג ל-CentOS 7.4

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

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

כמו תמיד, בגרסאות עדכון Minor ישנם שינויים רבים בהפצה, אך שינויים אלו עדיין שומרים על תאימות בינארית, תאימות קבצי הגדרות וכו'. יחד עם זאת, בחלק מהמקרים מעדיפים ברד-האט (ונגזר מזה גם ב-CentOS) לשדרג חבילות מסויימות לגרסאות Major מתקדמות יותר ובלבד שתשאר התאימות. הסיבה לכך היא שהפצת לינוקס (בניגוד לגירסת Windows) כוללת אלפי חבילות (וזאת לפני הפעלת מאגר תוכנות מומלץ כמו EPEL) ואין לרד-האט את המשאבים לעקוב אחרי כל החבילות וליישם Backporting של עדכוני אבטחה. ברד-האט בודקים אם ישנן פריצות ידועות ואם הפריצות נחסמו בגירסה יציבה מתקדמת יותר, גירסת העדכון הבאה תכלול את הגירסה המתקדמת יותר (מה שנקרא בשפה המקצועית "Rebase").

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

ברוב המקרים, הרצת yum update תשדרג מערכת מכל גירסה קודמת (7.0, 7.1 וכו') לגירסה האחרונה בלי הרבה בעיות, אולם ישנם מקרים בהם השדרוג יכשל או יותר חמור – המכונה/VM לא תצליח לעשות Boot או לא תצליח להפעיל תקשורת דרך כניסות התקשורת הרגילות/וירטואליות.

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

  • אם אתם משתמשים ב-iptables וב-ip6tables (הראשון מיועד ל-IPV4 והשני ל-IPV6, הן מותקנות כברירת מחדל בהתקנה רגילה). אם אתם מפעילים את שתיהם, יכולות להיווצר בעיות של תקשורת. הבאג מתוקן ב-CentOS 7.4 בחבילה iptables-1.4.21-18.0.1.el7 אך הוא עדיין לא מתוקן ברד-האט 7.4. הפתרון המומלץ כרגע – להפעיל רק אחד מהם ולבטל את השני (בעזרת פקודת systemctl disable).
  • אם אתם משתמשים ב-Xen, מכונת VM של CentOS 7.4 עם דרייברים Paravirtualized – ה-VM לא יצליח לבצע BOOT וכרגע הפתרון הוא HVM (או PV-on-HVM). תיקון לכך יצא בקרוב.
  • במקרים מסויימים הרצת yum update תתקין חבילות i686 ולא X86-64. הבעיה מתרחשת עקב התקנת RDMA. אם אתם משתמשים ב-RDMA, מומלץ להריץ yum install rdma-core && yum update. אם אתם עדיין רואים בעיה, מומלץ להריץ yum install rdma-core ibacm. 
  • אם אתם רוצים להתקין VirtualBox על תחנת עבודה שתריץ כ-host את CentOS 7.4, תצטרכו להתקין את גירסת VirtualBox 5.1.28 מהאתר. גירסה 5.1.26 לא תעבוד.
  • משתמשים ב-VMware ורוצים להקים VM מבוסס CentOS 7.4? עקב שינויים שרד-האט ביצעו בקרנל, התקשורת הוירטואלית לא תעבוד. יש צורך בהתקנת Patch ל-VMware tools. לפרטים – כנסו ובצעו את ההוראות בקישור הזה.
  • חבילת ה-initramFS הרבה יותר גדולה מבעבר, ולכן אם מחיצת ה-boot/ שלכם קטנה מ-1 ג'יגהבייט, תצטרכו להרחיב אותה לפני השדרוג ל-7.4 לפחות לגודל 1 ג'יגהבייט (אני ממליץ להרחיב לגודל 5 ג'יגהבייט אם הנכם מתקינים מספר גרסאות קרנל).
  • יכול להיות ששרות SAMBA יפול עם השגיאה symbol krb5_get_init_creds_opt_set_pac_request, not defined. במקרים כאלו יש להתקין את חבילת  krb5-libs-1.15.1-8.el7 ולהפעיל את שרות SAMBA מחדש.
  • ועוד בעניין SAMBA – אם אתם עובדים עם אותנטיקציית SSSD ומאפשרים SHARE, זה לא יעבוד. כרגע האפשרות היחידה היא לשנמך לגירסה שקיימת בסנטוס 7.3. כרגע רד-האט עובדים על הבאג הזה.
  • נדיר, אבל ראיתי מקרים שזה קורה: אתם מפעילים את ה-CentOS ואין תקשורת עד שאתם מבצעים Login או שהתקשורת לא מופעלת בזמן Boot. במקרים כאלו, עקבו אחר ההוראות כאן.
  • החל מגירסה 7.4, מינימום זכרון שנדרש עבור המערכת הוא 1 ג'יגהבייט. במקרים שאתם רוצים להריץ את ה-ISO כ-LIVE, יש צורך בלפחות 1.5 ג'יגהבייט זכרון.
  • עוד בענייני VMWare: אם אתם מגדירים ידנית VM לשימוש עם CentOS 7.4, אל תנסו לבחור דרייברים SCSI אלא אך ורק את ה-Paravirtualized. דרייברים ל-SCSI ש-VMWare השתמשו כבר לא קיימים בקרנל הזה.
  • אוהבים את פקודת ifconfig ו-netstat? תתכוננו לשכוח מהם. הם מסומנים כ-Deprecated והם אינם מותקנים כברירת מחדל עם CentOS 7.4, ולכן אם הרשת שלך לא עלתה, השתמשו בפקודת nmcli כדי להפעיל את כרטיס הרשת ואז תוכלו להתקין את החבילה (ותתכוננו לשנות סקריפטים שמשתמשים בפקודות הנ"ל).
  • בסנטוס 7.4 מותקנת גירסה חדשה של sudo שמשתמשת ב-var/db/sudo/lectured/ ולפיכך ההתראה הראשונה שמשתמשים ב-sudo (עם האזהרות וכו') תופיע מחדש לכל המשתמשים ב-sudo לאחר שדרוג לסנטוס 7.4.
  • אם אתם משתמשים ב-CentOS 7.4 עם GNOME, יכול להיות שמנהל הקבצים (Nautilus) יראה את האייקונים מאוד גדולים. הפתרון הוא להריץ את הפקודה: gsettings set org.gnome.nautilus.icon-view default-zoom-level 'small' ולבצע lougout ולאחר מכן login.
  • אם אתם משתמשים ב-CentOS 7.3 (או גרסאות 7 קודמות) ואתם מריצים על זה OpenLDAP ואתם מתכוונים לשדרג, יש לבצע את ההוראות בלינקים כאן וכאן או שתהיה לכם בעיה רצינית עם ה-OpenLDAP. בכל מקרה אם מדובר ב-VM, בצעו snapshot לפני כן.

בכל מקרה, תמיד מומלץ להסתכל בדף ה-Errata של רד-האט ולוודא שאין עדכונים שלא התקנתם או שלא שמתם לב אליהם.

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

קצת על רד-האט, 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.

על הקשחות תחנות עבודה/דסקטופ ושרתים

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

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

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

  • אנשים מסתכלים על המאמרים של מיקרוסופט וחושבים שעניין האבטחה זה כמו שמיקרוסופט מפרסמת – 3-5 עמודים בלינקים שונים ואפשר לסמן ✔ על הנושא. זהו, שזה לא. אבטחת מידע רצינית בין אם זה על דסקטופ או שרת היא הרבה יותר מורכבת ואתם מוזמנים להעיף מבט על ה-CIS Benchmark שנחשב ה-דבר בהקשחה. על Windows 10 בלבד מדובר על 942 עמודים. Windows Server 2012 R2? זה 732 עמודים. (ועם CIS זה הולך לפי ניקוד לגבי השינויים שעושים, כל דבר מקבל ניקוד שונה)
  • אין "הקשחה אחידה". איש אבטחת המידע רוצה את מקסימום האבטחה, איש ה-IT רוצה פחות כדי שהוא אשכרה יוכל לעבוד בצורה נוחה, ולכן זה יקח לא מעט זמן לעבור על הנקודות ולבצע את הדברים.
  • "חיתוך פינות" – הנה משהו שאני שומע שוב ושוב מלקוחות פוטנציאליים: "כבר עשית את רוב העבודה ללקוחות קודמים, תביא את זה, נעשה תיאומים ונגמור עניין". הבעיה – עדיין לא פגשתי לקוח שמוכן שקוד או סקריפטים שכתבתי עבורו – יעברו הלאה ללקוחות אחרים, גם אם מדובר בדברים שכתבתי בביתי עם ה-LAB שלי. לקוחות רוצים משהו פשוט: שילמנו? זה נשאר אצלנו וזה לא עובר לאף לקוח, אז צריך לכתוב מחדש דברים שוב ושוב.
  • אוטומציה – האם אפשר לעשות את הדברים בצורה אוטומטית פחות או יותר? (להריץ אוטומציה בלי הגדרות פר שרת ששונים מאחד לשני יוביל להשבתה של המערכות שלכם. ראיתי כבר מישהו שניסה זאת פעם) – בהחלט, אבל זה דורש עבודה של 2-3 חודשים של כתיבה ומימוש כל הסעיפים והגדרת קובץ שבו יהיה אפשר לבחור מה יהיה enabled ומה יהיה Disabled, וכן, אני מדבר על אוטומציה ל-Windows עם דברים כמו Ansible.זו עבודה שאינה קלה שמצריכה המון snapshots הואיל וכל מימוש סעיף ובחינתו מצריך snapshot ו-rollback לאחר הבדיקה.
  • תחנות עבודה / דסקטופ – אפשר גם לעשות שם אוטומציה בנוגע להקשחה אולם עדיף לעשות Image מאסטר ולשכפל בין התחנות, תוך יצירת שינויים בהתאם לתפקיד התחנה/דסקטופ.
  • רגולציה / Conformance tests – יש הבדל ענק בין חברה לייבוא שימורים לבין חברת ביטוח או בנק שרוצים הקשחות. במקרים של הגופים הגדולים, חוץ ממחלקת אבטחת מידע צריך לערב את המחלקה שאחרית על מימוש רגולציות ו-Conformance tests (ראיתי מקרה שעבודה ענקית של הקשחה בוטלה ברגע האחרון לפני מימוש רק כי לא עירבו את המחלקה הזו. עבודה עבורי של חצי שנה נעלמה במחי מייל אחד מאותה מחלקה).
  • שילוב הקשחה של Windows ו-Linux. רעיון נחמד, לא ניתן לביצוע מכיוון שמדובר במערכות לגמרי שונות שמצריכות סקריפטים שונים לחלוטין.

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

על רשיון VDA ועל פתרונות עוקפים

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

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

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

פתרון 1
הפתרון הראשון הוא שימוש במערכת הפעלה של מיקרוסופט המיועדת לשרתים, ו"הפיכתה" למערכת דסקטופ. אפשר לבצע זאת הן על מערכת 2008/2008R2 והן על 2012/2012R2 בגרסאות Standard. מיקרוסופט עצמה מאשרת כי למערכת ש"הומרה" לדסקטופ, אין צורך רשיון VDA (אבל מצד שני גם לא תוכלו להשתמש במערכת הזו למשתמשים רבים אלא אך ורק מכונה פר משתמש). הנה מה שמיקרוסופט כותבת (מתוך ה-FAQ לגבי VDI – לחצו להגדלה)

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

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

הרבה, הרבה מאוד חברות לא אוהבות רעיון ה-VDA. תחשבו על זה לרגע – הדסקטופים שלכם והלאפטופים – בכולם יש Windows ששולם פעם אחת בלבד, וגם הרשיונות למערכות Windows 2012/2012R2/2008 שולמו באופן חד פעמי, ואילו VDA מצריך תשלום כל שנה, ולכן החברות הללו שהיו מעוניינות לחשוב על פתרון VDI פנו הן ל-Citrix והן ל-VMWare למצוא פתרונות חלופיים.

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

ה-VDI שיופעל עבור המשתמש הוא לינוקס לכל דבר ועניין, בין אם זו הפצת RHEL או Centos (גירסאות 6.6 ומעלה) או אובונטו 12 (שאר ההפצות לא נתמכות באופן רשמי אבל מנסיון – אין שום בעיה להשתמש בהן, כולל סביבות כמו KDE, XFCE ואחרות). ההטמעה בלינוקס (במקרה ומדובר ב-Horizon View של VMware, ב-Citrix זה שונה) כוללת התקנת VMWare Tools (ואני ממליץ לא להתקין את החבילה ש-VMWare נותנת אלא את Open VM Tools שזו גירסת הקוד הפתוח שהיא הרבה יותר יציבה, מעודכנת, וגם המהנדסים של VMWare משתתפים בפרויקט והחבילה כלולה בתוך ה-REPO ברירת המחדל של ההפצה), התקנת JRE (כן, ב-VMWare עדיין חושבים שלהריץ JAVA על דסקטופ זה דבר חכם…) ואת ה-View Agent והגדרות נוספות שונות שאיש הלינוקס יצטרך להוסיף. אגב, את עניין הרפליקציה של המכונות (בין אם Linked Clones או Full Clones יש צורך לבצע עם סקריפט שכתוב ב.. Power Shell. לך תבין מדוע..)

לאחר שהמשתמש מקבל את המסך הלינוקס (אחרי שהוא התחבר ל"פורטל"), הוא מבצע Login למערכת (אין שום בעיה שיבצע Login מול AD של מיקרוסופט) והוא יקבל סביבה גרפית שאיש הלינוקס בחברה בנה/שינה כדי שתיראה כמה שיותר "ווינדוזית". מכאן והלאה, שמשתמש יבצע Double Click על אייקון כלשהו (דפדפן, וורד וכו' וכו') הוא יקבל בעצם את האפליקציה משרת 2012/2008 כך שהלינוקס הוא רק "מעטפת", אתם לא תתחילו להריץ תוכנות לינוקסיות בחברה (אלא אם אתם רוצים, אבל זה משהו אחר. זו לדוגמא יכולה להיות הזדמנות מעולה להטמיע כרום ולשכוח מוירוסים)

בשיטה זו – אתם משלמים 0 פר VDI למיקרוסופט (שוב, למעט רשיונות שאתם צריכים לשלם על Published Apps)

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

 

טכנולוגיה אינה דת

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

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

ישנם דברים שיכולים מאוד להתאים לאיש IT מקצועי עם שנים רבות של נסיון שפשוט לא יכולים להתאים למשתמשים רבים. אני יכול לתת דוגמא פשוטה: אני כותב את הפוסט הזה עם מחשב ASUS ChromeBox שמריץ את ChromeOS שרוב הזמן אני עובד עליו. מדוע? כי אני מקבל את החוויה של שימוש בכרום תוך 6 שניות מהפעלת המכשיר, אין לי חשש מבעיה של תקלת אחסון (הכל בענן או ברשת) ואין שום דבר שיכול לגרום למכונה הקטנה הזו "להיתקע". אם אני צריך דברים יותר מורכבים, אז אני משתמש ב-Crouton באותה מכונה ואז יש לי בנוסף ל-ChromeOS אובונטו או Debian ובלחיצה על צירוף מקשים יש לי Shell כדי לעשות דברים פשוטים או מורכבים ואני אפילו יכול להריץ אפליקציות Android על ה-ChromeBox הזה ללא צורך במכשיר סלולרי או טאבלט.

האם אני ממליץ את הקונפיגורציה הזו לאנשי IT? אם הם הטיפוסים שאוהבים "לחטט" ו"לשחק" עם דברים – אז כן, בהחלט. האם אני ממליץ להעביר תחנות של מזכירות ומשתמשים קלים אחרים ל-ChromeBox? לא, כי אין עדיין ב-ChromeOS שום תמיכה פנימית ל-Active Directory, לניהול מרוכז עם כלי System Center של מיקרוסופט (שחברות רבות משתמשות בו), אין עדיין מספיק כלים שיכולים להחליף או לתת חוויית שימוש דומה בכלים שיש בעולם של מיקרוסופט למשתמש הסופי. היכן כן אמליץ להטמיע אותו למשתמשי קצה? באותן חברות קטנות שהחליטו להשתמש בשרותי Google Apps (או מה שנקרא היום Google for Work) ושכל העבודה מתבצעת דרך דפדפן. עלויות התחזוקה שם הן מאוד קטנות וגם אם מתקלקלת קופסא כלשהי, שום מידע לא הולך לאיבוד.

דוגמא אחרת היא בתחום הוירטואליזציה. התחום הזה נחלק בין 2 חברות גדולות (VMWare, מיקרוסופט) ויש גם את המתחרים כמו Xen, אורקל (VM Server). בעולם חברות רבות החלו במעבר מוירטואליזציות שרצות מקומית על השרתים של החברה לשרותי ענן כמו Amazon, Azure וגם ל-Google Cloud. בישראל, לעומת זאת, המעבר לשרותים הנ"ל עדיין איטי וחלק גדול מהחברות לא חושבות לעבור (אם כי כן להשתמש בשרותים אחרים כמו אחסון, DNS וכו')

אם אנחנו מדברים על וירטואליזציה, ושוב – אנשי ה-IT שאוהבים "לשחק", אני ממליץ להם על הכרות עם KVM. זו וירטואליזציה בקוד פתוח שנותנת ביצועים כמו ESXI. למי שמצפה ל-GUI כמו שיש עם vCenter (או VCSA/VSA) או כמו כלים של מיקרוסופט – יתאכזב. ה-GUI שיש מהרגע הראשון הוא מאוד פשוט. KVM נבנה יותר לכיוון אנשים שאוהבים Command Line ומכיוון שהוא נכתב כך, ישנם עשרות כלים, חלקם חינמיים וחלקם בתשלום – שמאפשרים לך ניהול של שרתים פיזיים שמריצים KVM. אפשרות שתעניין אתכם אולי זה להריץ את oVirt (המנהל הרשמי להרצת מכונות KVM, זה יותר מזכיר את ה-vCenter). אפשרות נוספת בבית שלכם (אם יש לכם כרטיס nVidia במחשב וגם כרטיס onboard) היא להריץ Windows עם משחקים בביצועים של בערך 95-99% בהשוואה ל-Native. הנה הדגמה:

אגב, ספריה טובה שאני ממליץ עליה (לאלו שכותבים ב-Python, PHP וכו') היא ספריית libvirt. בעזרת ספריה זו אתם יכולים להתחבר גם ל-ESXi, גם ל-Hyper-V, גם ל-Xen, ל-VirtualBox ועוד כמה מערכות וירטואליזציה ולהריץ עליהם אפליקציות שאתם תכתבו, כך שאם יש לכם סביבה מעורבת, ספריה זו יכולה לעזור לכם לכתוב כלים לנהל, לדגום ביתר קלות.

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

המלצות לגבי שרת 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 אחרים

לפני מספר שנים, חברת 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 לארגונים.