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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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