1. מערכות הפעלה ( אביב 2009) חגית עטיה © 1 מערכות קבצים מבוזרות  מבוא  מבנה כללי  דוגמה : Network file system  דוגמה : Google file system

2. מערכות הפעלה ( אביב 2009) חגית עטיה ©2 מערכות קבצים מבוזרות מאפשרות לתהליכים אשר רצים במכונות שונות, גישה ושיתוף קבצים  שקיפות לאפליקציה : אפליקציה שנכתבה לטיפול בקבצים מקומיים לא צריכה להשתנות.  שקיפות מקום : שם הקובץ לא מכיל מידע על מיקומו ( מקומי / מרוחק ).  ב -URL מציינים במפורש את המיקום ( אין שקיפות מקום ) http://hostname/d1/d2/d3/f  אי - תלות במיקום : שינוי מיקום קובץ לא נראה למשתמש.  ב Andrew File System (AFS), ניתן להעביר volumes משרת לשרת בצורה שקופה לחלוטין.  מרחב שמות אחיד לקבצים ללא תלות במיקומם.

3. מערכות הפעלה ( אביב 2009) חגית עטיה ©3 התמונה הגדולה  תהליך רץ במחשב לקוח (client)  התהליך מבקש לגשת לקובץ הנמצא במחשב שרת (server)  מחשב הלקוח ומחשב השרת מחוברים באמצעי תקשורת כלשהו ( כבל תקשורת, רשת מקומית, אינטרנט ) File System ServerClient

4. מערכות הפעלה ( אביב 2009) חגית עטיה ©4 התמונה הגדולה  תהליך רץ במחשב לקוח (client)  התהליך מבקש לגשת לקובץ הנמצא במחשב שרת (server)  מחשב הלקוח ומחשב השרת מחוברים באמצעי תקשורת כלשהו ( כבל תקשורת, רשת מקומית, אינטרנט )  כאשר תהליכים בלקוח מבצעים קריאות מערכת לקבצים אצל השרת : הלקוח שולח לשרת בקשות  מערכת ההפעלה שולחת בקשות בהתאם לקריאות המערכת של התהליכים השרת מחזיר תשובות  תהליך מיוחד בשרת מאזין לבקשות, מבצע אותן, ומחזיר תשובות. סוגי ההודעות בין הלקוח והשרת מוגדרים בפרוטוקול תקשורת

5. מערכות הפעלה ( אביב 2009) חגית עטיה ©5 File System ServerClient אפשרות 1: שיגור פונקציה הפעולות מועברות לשרת אשר מבצע אותן לוקלית ומעביר את התוצאות חזרה ללקוח (Function Shipping)  מימוש פשוט ( למשל Remote Procedure Call) 2. read file id 5. buffer, status Service 3. read 4. results Application Invocation on remote file 1. read6. results

6. מערכות הפעלה ( אביב 2009) חגית עטיה ©6 File System ServerClient אפשרות 2: שיגור נתונים הנתונים מועברים מהשרת ללקוח, אשר מבצע את הפעולה באופן מקומי (Data Shipping)  מוריד עומס בשרת  איך יודעים האם הנתונים עדכניים ? 2.request data (if necessary) 3. data shipped 1. read 6. results Remote File Handling 4. read 5. results Application

7. מערכות הפעלה ( אביב 2009) חגית עטיה ©7 מדיניות משולבת : מטמון  מדיניות עדכון : מתי מעבירים עדכונים מהמטמון לשרת ? write-through: אמין, אך המטמון מנוצל אך ורק בקריאה write-back: עדכונים אחרונים עלולים ללכת לאיבוד write-on-close: השינויים מועברים בעת סגירת הקובץ delayed-write: השינויים מועברים כל פרק זמן  קונסיסטנטיות : איך הלקוח יודע שהנתונים במטמון תקפים ? client-initiated: הלקוח בודק בכל גישה, כל פרק זמן או כאשר הקובץ נפתח server-initiated: השרת זוכר איזה לקוח מחזיק איזה חלקים של קבצים  השרת יכול לשלוח הודעה revoke ללקוח אשר פוסל את העותק שלו  או, עבור קבצים הפתוחים לכתיבה ע " י מספר לקוחות, מבטלים את המטמון וניגשים כל הזמן לשרת

8. מערכות הפעלה ( אביב 2009) חגית עטיה ©8 יש מצב ? האם השרת שומר מצב עבור כל לקוח בין בקשה לבקשה ? למשל, איזה קבצים נפתחו ע " י הלקוח, מיקום בקובץ, מידע על הנתונים במטמון של הלקוח, מנעולים וכדומה.  פרוטוקול עם מצב (stateful). השרת שומר מידע לגבי כל לקוח. בקשה מתבצעת בהקשר מסוים, ואין צורך להעביר את כל המידע הדרוש לביצוע הפקודה.

9. מערכות הפעלה ( אביב 2009) חגית עטיה ©9 אין מצב !  פרוטוקול בלי מצב (stateless). השרת לא שומר מידע. בקשה מכילות את כל המידע הנחוץ לטיפול בהן. קל יותר למימוש. קל להתאושש מנפילות.  השרת יכול ליפול ולהתאושש מבלי שלקוחות ירגישו ( חוץ מאשר האטת זמן התגובה בעת ההתאוששות ).  לא ניתן לבצע שיפורים ולחסוך בתקשורת  קשה לממש נעילות של קבצים השרת לא יכול לזכור שהקובץ נעול

10. מערכות הפעלה ( אביב 2009) חגית עטיה ©10 Network File System: NFS  פרוטוקול שרת - לקוח.  בעיקרון, בלי מצב (stateless).  פעולות Remote procedure call (RPC):  read ו -write על קובץ  גישה לתכונות של קובץ  חיפוש בתוך מדריך  פעולות על מדריכים, כמו חיפוש, הוספת / מחיקת כניסה וכד '  אין בפרוטוקול פעולות open ו -close  הלקוח מרכיב (mounts) תת - עץ של השרת במדריך שלו.

11. מערכות הפעלה ( אביב 2009) חגית עטיה ©11 הרכבת מדריכים : Mount / etc binusrmail john datatest file1file2file3 Client / etc binusrmail dan shared_data1 dir1dir2dir3 Server shared_data2 f1 f2 f3 exports /usr/dan/shared_data1host1 host2 /usr/dan/shared_data2 host1

12. מערכות הפעלה ( אביב 2009) חגית עטיה ©12 הרכבת מדריכים : Mount / etc binusrmail john datatest Client / etc binusrmail dan shared_data1 dir1dir2dir3 Server shared_data2 f1 f2 f3 exports dir1dir2dir3 f1 f2 f3

13. מערכות הפעלה ( אביב 2009) חגית עטיה ©13 שקיפות ואי - תלות ב NFS  שקוף לאפליקציה : גישה כמו לקובץ מקומי.  שקיפות מקום, המשתמש לא מבחין מהו מיקום הקובץ. אלא אם ה -mount points ידועים לו  יש תלות במיקום : הזזת קובץ מחייבת שינוי ה -mount

14. מערכות הפעלה ( אביב 2009) חגית עטיה ©14 מימוש NFS Applicatio n Server System-call Interface Logical File System Physical File System NFS Client Device Driver RPC Client Virtual File System Interface Physical File System NFS Server Device Driver RPC

15. מערכות הפעלה ( אביב 2009) חגית עטיה ©15 ביצוע פקודות  NFS מבוסס על שיגור הפונקציה לביצוע אל השרת לשיפור הביצועים, משתמשים במטמון (cache) אצל הלקוח שאליו קוראים חלקים מהקובץ שאיתו עובדים עדכונים לקובץ נאגרים במטמון ונשלחים לשרת מדי פרק זמן כתיבות לקובץ אינן משפיעות מיד אצל לקוחות אחרים !  כמעט כל קריאת מערכת ( לגישה לקובץ ) מתורגמת ישירות לפעולת RPC. היוצאים - מן - הכלל הם open ו -close, אשר מחייבות פעולות ניהול מקומיות בלקוח.

16. מערכות הפעלה ( אביב 2009) חגית עטיה ©16 מערכת הקבצים של * Google  מערכת קבצים ייעודית לתמיכה באפליקציות ספציפיות אוספים מידע מכל הרשת (crawling) מאחסנים על " דיסק אחד גדול " מבצעים חיפושים של לקוחות על "PC אחד גדול " אבל דורש הרבה יותר זיכרון וכוח חישוב ממה שמחשב בודד יכול לתת בלי להשתמש במחשב מקבילי עצום * לפי המאמר : Ghemawat, S., Gobioff, H., and Leung, S. The Google file system. SOSP 2003

17. מערכות הפעלה ( אביב 2009) חגית עטיה ©17 שימוש במצבור של שרתים זולים  המון ( המון ) שרתים, כל אחד עם דיסק ו CPU. מאות ואלפים של יחידות PC סטנדרטיות לחלוטין וזולות  איך לפזר מידע על פני השרתים ?  איך לטפל בנפילות ? נפילות של דיסקים, שגיאות תכנות, בעיות חשמל, טעויות אנוש, בעיות תקשורת, ועוד ועוד  אולי NFS? כל הקבצים על שרת אחד, הרבה לקוחות צוואר בקבוק ? טיפול בנפילות ? GFS: מערכת קבצים על מצבור של שרתים, אשר תוכננה מתוך ידע מדוקדק על צרכי השימוש בה, עם התאוששות מנפילות באופן אוטומטי וחלק.

18. מערכות הפעלה ( אביב 2009) חגית עטיה ©18 GFS: שימוש ייעודי  קבצים גדולים מאוד ≥ 100 MB  קריאות גדולות ברצף (streaming) ≥ 1 MB Read once  כתיבות סדרתיות גדולות שמבצעות append ( כתיבה בסוף ) Write once  על - ידי כמה לקוחות בו - זמנית ! אטומיות על תור producer-consumer ללא סנכרון

19. מערכות הפעלה ( אביב 2009) חגית עטיה ©19 GFS: ארכיטקטורה  שרת ראשי יחיד ( עותקים משוכפלים לגיבוי )  מאות / אלפי שרתי חתיכות (chunk servers) חתיכה : חלק בגודל 64 MB של קובץ, עם מזהה יחודי  המון לקוחות ניגשים לאותו קובץ או לקבצים שונים במצבור

20. מערכות הפעלה ( אביב 2009) חגית עטיה ©20 GFS: השרת הראשי  מחזיק את כל ה metadata: מרחב השמות ( מדריכים ), הרשאות גישה, מיפוי מקבצים לחתיכות, מיקום החתיכות ( על שרתי חתיכות )  מנהל מתן הרשאות (leases) על חתיכות לשרתי החתיכות  מעביר חתיכות בין השרתים הכול בזיכרון ראשי, על מנת להאיץ את הגישה

21. מערכות הפעלה ( אביב 2009) חגית עטיה ©21 GFS: שרת חתיכות  מאחסן חתיכות על דיסק מקומי, בשימוש ב Linux רגיל  בקשות קריאה / כתיבה מציינות מזהה חתיכה וטווח בתים.  חתיכות משוכפלות בכמה שרתי חתיכות ( בדרך - כלל, 3)  אין caching מיוחד

22. מערכות הפעלה ( אביב 2009) חגית עטיה ©22 GFS: לקוח  שולח בקשות metadata אל השרת הראשי, ושולח בקשות לחתיכות אל שרתי החתיכות ( קצת דומה לשרתי שיתוף קבצים )  שומר metadata במטמון, לא שומר data במטמון חוסך בעיות של קונסיסטנטיות מטמון לא מועיל הרבה כאשר קוראים / כותבים פעם - אחת

23. מערכות הפעלה ( אביב 2009) חגית עטיה ©23 קריאה של הלקוח  הלקוח מבקש מהשרת הראשי לקרוא ( שם קובץ, אינדקס חתיכה )  השרת הראשי משיב עם מזהה חתיכה, מיקומי החתיכה  הלקוח מבקש את החתיכה משרת החתיכות " הקרוב ביותר " אשר מחזיק אותה נקבע על - פי כתובת ה IP  שרת החתיכות שולח את החתיכה

24. מערכות הפעלה ( אביב 2009) חגית עטיה ©24 כתיבה של לקוח 1  לכל חתיכה יש שרת חתיכות אחראי מקבל lease מהשרת הראשי, שצריך לחדש אחרי מעט זמן ( דקה )  הקליינט לומד מהשרת הראשי מי העותק האחראי והעותק המשני של כל חתיכה  שולח אליהם בקשות ( הם מעבירים אחד לשני בשרשרת )

25. מערכות הפעלה ( אביב 2009) חגית עטיה ©25 כתיבה של לקוח 2  כל העותקים מאשרים את הכתיבה ללקוח  הלקוח שולח בקשת כתיבה לעותק האחראי  השרת האחראי ממספר את בקשת הכתיבה, ומסדר אותה  השרת האחראי מעביר את הבקשה לשרתים המשניים  השרתים המשניים מאשרים את ביצוע הכתיבה  השרת הראשי עונה ללקוח

26. מערכות הפעלה ( אביב 2009) חגית עטיה ©26 עוד אספקטים  מימוש יעיל במיוחד לשרשור ( קובץ גדול במיוחד משמש כחוצץ בין יצרנים ולקוחות )  התנהגות לא - פשוטה כאשר יש פעילות בו - זמנית על קבצים שינויים ב metadata הם אטומיים ( מבוצעים בשרת הראשי ) לשינויים ב data מובטחת אטומיות רק במקרים מיוחדים  logging לגיבוי השרת הראשי

27. מערכות הפעלה ( אביב 2009) חגית עטיה ©27 GFS: סיכום  הצלחה : גוגל משתמשת בו לחיפוש ולאפליקציות נוספות זמינות ושרידות על חומרה זולה תפוקה טובה, בזכות ההפרדה בין בקרה (metadata) ובין מידע (data) תמיכה בכמויות מידע עצומות ו " הדבקה " בו - זמנית רעיונות דומים במערכת הקבצים Hadoop ( שהיא קוד פתוח )  התנהגות לא - שקופה לאפליקציות ( סמנטיקה לא - נקייה )  ביצועים לא טובים לחלק מהאפליקציות למשל, אם חוזרים וקוראים או כותבים מאותן כתובות, בגלל שאין מטמון אצל הלקוח

28. מערכות הפעלה ( אביב 2009) חגית עטיה ©28 התפתחויות טכנולוגיות  Network Attached Storage (NAS) התקנים יעודיים המריצים תהליכי שרת של מספר מערכות קבצים (NFS, CIFS, Samba)  מאפשרים שיתוף משאבים בין מספר מערכות קבצים  Plug-and-play  סולמיות (scalability)  משתמשים בתשתית התקשורת הקיימת client NAS device IP NAS device לכל שרת יש את הדיסקים שלו

29. מערכות הפעלה ( אביב 2009) חגית עטיה ©29 התפתחויות טכנולוגיות  Storage Area Networks (SAN) התקני איכסון חכמים יותר מדיסקים פשוטים, המחוברים דרך רשת תקשורת ייעודית ומהירה מאוד אל מערך של שרתים  מאפשר לכל שרת לגשת לכל דיסק  מאפשר מתן הגנה מסויימת ע " י מנגנון גידור ברמה של Logical Unit Number (LUN) client server Storage IP SAN