על NFS v3 מול NFS v4.1 ו-pNFS

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

בעולם היוניקס, פרוטוקול שיתוף הקבצים הכי ידוע הוא NFS (שפותח ע"י SUN) וספציפית גירסה 3 (כלומר NFS v3) וגירסה זו היתה שיפור של דברים ישנים יותר כמו DFS ו-AFS. בפרוטוקול זה, כל יצרני היוניקס/BSD ולינוקס השתמשו ומשתמשים עד היום, למרות שהפרוטוקול עצמו די ותיק (השנה ימלאו לו 20).

גירסה 3 של NFS הומצאה בזמנים שכמות התעבורה וכמויות המידע שהיו לחברות, היו נמוכות (במושגים של היום) ובהתחלה גירסה 3 תמכה רק בהרשאות של מה שקיים בשרת עצמו, כלומר אם משתמש X לא קיים במערכת, אז משתמש X לא היה יכול להשתמש/לקרוא/לכתוב קבצים ששותפו ע"י ה-NFS. במשך הזמן אותה גירסה 3 "שופצה" והתווספו לה (בעקיפין) תמיכה לדברים כמו NIS, LDAP, AD ואחרים, בין באמצעות שימוש ב-Mapping (במקרים של משתמשים בודדים עם הגדרות ידניות ללא שרת אותנטיקציה) ובין בשימוש ב-Translation שהשתמש ב-nsswitch ואותו nsswitch היה מתממשק לשרות האותנטיקציה.

כפי שאתם יכולים להבין, NFS v3 אינו פרוטוקול ממש נוח והוא למען האמת מאוד "בזבזני". כך לדוגמא מבחינת פורטים, הוא צריך לא מעט מהם (תריצו rpcinfo -p על שרת NFS ותראו). בנוסף, מבחינת תעבורה, הוא היה זקוק למידע מהשרת על כל פיפס. כך לדוגמא, מספיקה פקודת ls פשוטה בשביל "לתזז" את ה-NFS שישאל את השרת לגבי שמות קבצים, הרשאות, וכו' וכל הבקשות האלו היו טוריות ונפרדות, בלי שום אופטימיזציה. יצרני ה-Storage למיניהם שרצו למכור מוצרי Storage לחברות היו צריכים לבצע שמיניות באויר כדי לתת לשרתים ותחנות שרותי NFS v3 ולהתמודד עם הבעיות שלו.

ב-SUN היו מודעים לבעיות והם שחררו ב-2000 לפתח את גירסה 4 (וגירסה זו זכתה לשיפוצים ב-2003). מכיוון שהם רצו שזה יהיה סטנדרט, הם עבדו עם ארגון ה-IETF וב-2010 יצאה גירסה 4.1 בצורה רשמית כסטנדרט.

אנחנו נמצאים בשנת 2015 והשימוש ב-NFS 4.1 אינו גדול בעולם. מדוע? ישנן מספר סיבות:

  • אחת הסיבות שלא משתמשים (או שמשתמשים ב"עירוב" של גירסה 3 ו-4, מה שלא ממש מקל על צוות ה-IT) היא חוסר תמיכה לגירסה 4.1. כל חברה שמכבדת את עצמה משתמשת בוירטואליזציה ואם רצית להשתמש בוירטואליזציה עם NFS, האפשרות היחידה שהיתה לך – זה להשתמש ב-NFS 3 (או iSCSI).
  • סיבה נוספת ודי עיקרית – אין Clients, במיוחד שלא היה שום Client רשמי ללינוקס, כיום רוב השרתים שאינם מבוססי Windows הם לינוקס, ומכיוון שלא היתה תמיכה (עד גירסת Red Hat 6.4 וגם אז זה היה מוגדר כ-Technology Preview) – חברות העדיפו להשתמש ב-NFS 3 או בפרוטוקולים אחרים.

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

אולם אחד היתרונות הגדולים של גירסה 4.1, היא שאין יותר מצב של שרת אחד שמשרת את כולם. מעתה אפשר לשים כמה שרתי נתונים (Data Storage) שעליהם מאוחסנים הנתונים (בשכפול או בכל תצורה אחרת) וישנו שרת שמנהל את ה-Meta Data (וגם נקרא כך – MDS – Meta Data Server), כך שהתחנות שפונות וצריכות שרותי NFS, מדברות בהתחלה עם ה-MDS וה-MDS מפנה אותם לשרתי DS שעליהם מאוחסן המידע. זה, אגב, ה-pNFS שהוא בעצם חלק מ-NFS 4.1.

בנוסף, יתרון גדול מאוד שיש לגירסה 4.1, זה שעתה במקום לתת רק שרותי קבצים, השרת יכול להגיש עוד 2 סוגים של אחסון: האחד הוא Object Storage והשני (שסביר להניח שרבים יאהבו) הוא Block Storage – כמו iSCSI, FC, FCoE וכו'. כלומר, אפשר להכין כמה LUN נחמדים, לתת ל-MDS לעשות Discovery מול ה-iSCSI Target ולשתף אותם, דבר שבעייתי לבצע עם iSCSI Initiator שונים (למעט במקרים של Cluster Aware כמו ב-ESXi, Hyper-V וכו').

ויש עוד יתרונות רבים ל-NFS v4.1.

נשמע נחמד, לא?

זהו, שכאן גם מגיעה הבעיה המרכזית שתמנע מכם להרים כרגע כמה שרתי פרודקשן של NFS 4.1.

הבעיה הגדולה היא שמה שרד-האט והפצות אחרות נותנים, זה רק Client. אסייג בדבריי ואומר שאין מניעה מלהרים שרת NFS 4.1, אולם בגירסת רד-האט 7 האחרונה, יש תמיכה בשיתוף קבצים, אולם תמיכה ב-Object Storage וב-Block Storage מוגדרת כ-Technology Preview (גם בגירסת רד האט/סנטוס 7.1 שתצא בקרוב). התמיכה הרצינית ש-pNFS (כ-שרת) צריך תגיע רק בקרנל 4.0, וגם אז התמיכה היא ל-XFS בלבד.

אבל הבעיות לא עוצרות כאן. גם אם נורא בא לך לקמפל קרנל, לשדרג את חבילות ה-nfs-utils ואחרות (שנמצאות ב-Fedora 22 שעוד לא יצא), אתה תמצא מהר מאוד שקיימת בעיה רצינית של תיעוד. הוא פשוט כמעט ולא קיים ומה שקיים כתוב בצורה שקשה להבין מי נגד מה ואיך, כמו איך להגדיר שרת קבצים כ-DS, מה צריך להיות בשרת MDS, איך משתפים בלוק של iSCSI ועוד ועוד. דווקא ניסיתי לשלוח מספר מיילים ולצ'וטט ב-IRC בערוץ linux-nfs, אך עד כה לא קיבלתי כל תשובה..

עם כל הבעיות, יש בהחלט מקום לאופטימיות. אני מאמין שהדברים ישתנו בחודשים הקרובים וישנם גם שיפורים שהחבר'ה מאורקל (לשעבר SUN) גם ירצו לאמץ כמו 21 הטלאים שהוצעו כ-RFC אתמול ל-Linux-NFS שמאפשרים דבר חדש: RichACL, כלומר ACL שיתן תאימות מלאה גם ל-SMB וגם ל-NFS, דבר שיכול להקל מאוד לסביבות מעורבות (ויכול להחליף את ה-POSIX ACL).

האם חייבים להשקיע ב-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.

טיפים להגנה על האתרים שלך

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

זה לא משנה אם הדעות הפוליטיות שלך הן ימין, שמאל, או מרכז, כולנו יודעים שישראל היא מטרה להתקפות תדירות על כל פיפס שקורה במדינה ושקשור למצב בטחוני, מצב בשטחים וכו'. כל מיני "התקהלויות" שונות קובעים תאריכים כדי לתקוף אתרים שמתארחים בארץ (או בחו"ל) כל עוד יש להם קשר כלשהו לישראל, ולפעמים מספיק שיש לאתר דומיין עם סיומת co.il/org.il/net.il כדי שהאתר יהיה באיזו "רשימת מטרות" להתקפה.

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

אתרים רבים מתארכים באחת מ-2 חבילות עקריות לאירוח אתרים: אכסון משותף (Shared Hosting) ושרת יעודי (בין אם וירטואלי או פיזי). אתחיל באכסון המשותף.

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

אירוח אתר (או אתרים) בשרת פיזי או וירטואלי נותן יתרונות גדולים וברורים כגון:

  • רוחב פס יותר גדול לשרת את גולשי האתר
  • אפשרות לאחסן הרבה יותר אתרים ותתי-אתרים
  • אפשרות לקבוע אלו שרותים ירוצו
  • אתם קובעים את הגדרות האבטחה
  • ועוד ועוד

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

הנה כמה דברים שמומלץ לעשות על מנת למנוע כמה שיותר פריצות לשרתים כאלו:

  1. מומלץ להעביר את התוכן של האתר דרך ספק CDN כלשהו ודרכו בלבד. ישנם 2 ספקי CDN גדולים שאני יכול להמליץ עליהם:  Cloudflare ו-Incapsula. ל-Incapsula יש יתרון שיש להם שרת סופי (Edge) בישראל, אולם כמות הנתונים שהשרות נותן בחבילת החינם היא קטנה מאוד (50 ג'יגהבייט). ל-Cloudflare לעומת זאת, אין מגבלת תעבורת נתונים גם בחבילת החינם. אצל 2 הספקים החבילות המסחריות נותנות הגנה רצינית מאוד נגד סוגים רבים של התקפות כך שכל גלישה לאתרכם (ובמידה והתעבורה של האתר שלכם עוברת דרך אותו ספק CDN) – המערכת תבדוק מהיכן הגולש מגיע, האם זהו גולש אמיתי או סקריפט זדוני, האם זהו נסיון גלישה אמיתי או נסיון לפרוץ לכם את האתר וכו'. למי שיש אתר והאתר יוצר רווחים עבורו, אני ממליץ להתחבר לאחד מספקי ה-CDN כמה שיותר מהר.
    נקודה חשובה שרבים מתבלבלים בה – ספק CDN אינו מארח את האתר שלכם. הוא שומר חלקית עותק מקבצים מסויימים ובכך הוא מאיץ את מהירות הגשת חלק מהדפים לגולש, אך כשמגיעה בקשה לדף מסויים לדוגמא, הוא מעביר את הבקשה לשרת שלכם (למעט מקרים שהשרות מזהה שמדובר בסקריפט זדוני, במקרים כאלו הוא ינקוט צעדים שונים למנוע מהסקריפט לפרוץ).
  2. שרות Mail – שרתים וירטואליים רבים של לקוחות מריצים שרותי Mail כך שהאתר ישלח אימיילים ללקוחות וגם ישלח לבעל האתר הודעות אימייל שונות (אישורים לתגובות, אישורי רכישה מהאתר, הודעות מלקוחות וכו'). במקרים רבים שרות ה-Mail אינו מוגדר בצורה מיטבית או בצורה מאובטחת בצורה מספקת, כך שיכולים לקרות במקרים רבים בעיות של שליחה וקבלת הודעות מייל מכיוון שהשרת נחסם ע"י שרתים אחרים וההודעות שיוצאות מהשרת הוירטואלי יסומנו כ"זבל" (spam).
    אני ממליץ לבטל את שרות ה-Mail המתוקן בשרת ולהשתמש בשרות כמו של חברת Mailgun. החשבון החינמי שאותה חברה נותנת, מאפשר משלוח וקבלה של עד 10,000 אימיילים בחודש. האתר עצמו אינו מארח חשבונות אימייל, אלא משמש כ-redirect, כך שהשרות ישלח את המייל בשם האתר שלכם וכל מייל שיגיע אליכם, יופנה אוטומטית לחשבון מייל שיש לכם.
  3. התחברות דרך SSH: ישנם מאות אלפי סקריפטים שסורקים את רשת האינטרנט למצוא דרכים להיכנס לאתר שלכם, במיוחד דרך חיבור SSH (זהו החיבור שדרכו ניתן לבצע פעולות על השרת שלכם דרך מסוף [terminal]). יש לי 3 המלצות לגבי שרות זה (ההמלצות מיועדות למי שמתחזק את השרת):
    * להעביר את חיבור ה-SSH מכניסה 22 למספר פורט אחר (מעל 1024)
    * לחסום כניסת root ישירות (כך ששימוש ב-root יתאפשר ע"י sudo או su בלבד)
    * לעבור מכניסה של סיסמאות לכניסה עם מפתחות
    * לעבור להשתמש ב-Port Knocking.
  4. שימוש בפאנלים כמו WHM/cPanel או Direct Admin: פאנלים אלו הם פאנלים נוחים לעבודה למי שאינו מכיר לינוקס, אולם הבעיה המרכזית איתם שהם מוגבלים מדי לחסום הגדרות שבעל האתר עושה שיגרמו לכך שהשרת יהיה חשוף לפריצות.
    לכן, אם אתם מתעקשים לעבוד עם פאנל כלשהו, לכל הפחות מומלץ לגשת אל הפאנל מאחורי שרות VPN (כדי שהפאנל לא יהיה חשוף לנסיונות תקיפה). אם יש לכם הרבה אתרים והגדרות שונות שאתם צריכים תדיר, מומלץ במקום פאנל לקחת מישהו שמבין בלינוקס ובאבטחת מידע, כך שהשרת יהיה כמה שיותר מוגן.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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