תגית: nfs

כמה מילים על GlusterFS

קשה לדמיין היום חברות ללא פתרונות Storage. יש חברות שקונות את הפתרונות של היצרנים הגדולים כמו IBM/NetApp/EMC או פתרונות בינוניים של Dell ו-HPE וכמובן פתרונות אחרים כמו Kaminario ועוד.

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

במקרים כאלו יש בד"כ יש סוגי פתרונות גנריים:

  • רכישת קופסת NAS מחברות כמו QNAP, Synology ואחרות. עם קופסאות כאלו, ההגדרות הן פשוטות, המערכת תשלח לך התראות אם יש בעיה, ולאחר שהגדרת את הדברים כל מה שנותר לעשות זה להגדיר למשתמשים חיבור לאותו NAS. החסרון בשיטה זו הוא שאם הקופסא קורסת מסיבה כלשהי (זכרון, רשת, לוח אם, ספק כח) – אותה קבוצת משתמשים תהיה מושבתת עד לתיקון הקופסא.
  • הסבת שרת ישן בכך שנכניס לו דיסקים ונחבר לבקר RAID מקומי, מכניסים זכרון, ומקימים שרות File Storage כלשהו בהתאם לפרוטוקולים שאנו רוצים (NFS, CIFS, iSCSI וכו'). זהו פתרון שמצריך ידע בלינוקס שעובד בד"כ לא רע. החסרון – אם אין לכם ידע בלינוקס, תצטרכו מישהו שמבין ולשלם לו בנפרד ובנוסף – גם כאן, אם יש בעיית חומרה (שאינה דיסק) – המערכת מושבתת עד שהיא תתוקן.

אז מה עושים שצריכים שרידות או שרוצים לגדול?

חברות כמו QNAP ו-Synology ישמחו למכור לכם קופסאות שרתים בגודל 2U (בד"כ) בצמד כך שתוכלו לעבוד במצב Cluster אקטיבי/פאסיבי או אקטיבי/אקטיבי תמורת אי אלו אלפי דולרים נוספים. בפתרון השני שתיארתי לעיל אפשר לעבוד עם פתרונות כמו DRBD ו-PaceMaker/Corosync על מנת לקבל את אותה תוצאה כמו הפתרון המסחרי, אבל הבעיה הגדולה ב-2 הפתרונות היא שלא ניתן לגדול מבחינת הוספת עוד שרתים, כלומר אפשר לעשות Scale Up (הוספת JBOD, דיסקים, זכרון, ואולי גם להוסיף כרטיס רשת או מעבד, תלוי במכונה), אך לא ניתן לבצע Scale Out – כלומר לגדול ממצב של 2 מכונות למצב של 3, 4 ומעלה כאשר כולן משתתפות באותה משימה.

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

מערכת GlusterFS, בניגוד למערכות כמו CePH אינה מתערבת ב-File System שלך. רוצה לבנות שרת עם כרטיס RAID וכמות דיסקים ב-RAID-5/RAID-6/RAID-10/RAID-1 וכו'? אין שום בעיה. תגדיר, תפרמט, תבצע Mount וזהו. רוצה לעבוד עם ZFS? תכין Pool ו-DataSets שיהיה להם Mount Point וזהו. מערכת ה-GlusterFS רוצה את ה-Mount point כנקודת התחלה. מה קורה מתחת? לא מעניין אותה.

עם GlusterFS, החל מהרגע שיש לנו Mount Points, מאותו רגע ה-Mount Points בשבילה זה דיסק קשיח שב-GlusterFS נקרא "Brick" (לבנה), ועם ה"לבנים" הללו אנחנו בונים Volume, וכאן אנחנו צריכים להחליט איך אנו בונים Volume בהתאם לכמות המכונות. האם אנו רוצים רק רפליקציה בין 2 מכונות או שאנחנו רוצים משהו שיפיץ את הנתונים בשרתי הקבצים השונים (מעל 3)? יש 9 אפשרויות לכך וניתן לקרוא עליהם כאן.

אחרי שיצרנו את ה-Volume (תמיד ניתן להגדיל אותו ולהוסיף Bricks נוספים) אנחנו צריכים להחליט דרך איזה פרוטוקול אנו משתפים את הנתונים החוצה, כמו NFS, CIFS, iSCSI, S3 ועוד, ואנחנו משתמשים בכלים השונים שתומכים באותם פרוטוקולים כדי לשתף את ה-Volume. זהו אותו Volume ש-GlusterFS מנהל עבורנו כך שכל דבר שנכתוב או נקרא – קיים בכל השרתים לפי הגדרות ה-Volume שהגדרנו. מבחינת הכלים שמממשים את הפרוטוקולים, אין להם מושג ירוק מה זה GlusterFS.

ומה עם שרידות? אנחנו נשתמש ב-PaceMaker/Corosync שיתנו לנו את השרידות, נוכל להוסיף כתובת IP שנותנת לנו גישה לאחת המכונות ב-Round Robin וכשהשרת שפנינו אליו נופל, המשתמשים "יוזזו" למכונה אחרת. אנחנו גם נוכל להשתמש ב-Round Robin ב-DNS (או דרך Load Balancer אם יש לכם) כך שכל ה-Clients ימשיכו לקבל את אותו שרות, גם אם שרת כלשהו מהחבורה נופל.

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

בוידאו קליפ הבא אני מסביר בקצרה על GlusterFS וכן מדגים אותה על 2 שרתי לינוקס + מכונת לינוקס שמשמשת כ-Client.

https://www.youtube.com/watch?v=0yo2nJcF9N8

 

על 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).