1. מציגים: דניאל קרום ורותם איקו סמינר בתקשורת מכללת הדסה
Cloud Architecture

2. Cloud Architecture– Rotem Eiko and Daniel Krom
מאמרים שעליהם התבססנו
Cloud computing: state-of-art and research challenges Qi Zhang, Lu Cheng and Raouf Boutaba.
Towards Understanding Cloud Performance Tradeoffs Using Statistical Workload Analysis and Replay Yanpei Chen, Archana Sulochana Ganapathi, Rean Griffith and Randy H. Katz
עסקנו בשני מאמרים ...
הראשון הוא מאמר שמדבר על מבנה של ענן, ספקים מוכרים וכל מיני היבטי מחקר
השני לוקח שימוש ספציפי בענן הנקרא MapReduce וחוקר אותו לעומק

3. First article - Cloud computing: state-of-art and research challenges
מהו ענן?
Cloud Architecture– Rotem Eiko and Daniel Krom

4. סוגי ענן Private Public מנוהל בבלעדיות ע"י הארגון
First article - Cloud computing: state-of-art and research challenges
סוגי ענן
Private
Public
מנוהל בבלעדיות ע"י הארגון
לרוב בנוי ומותאם אישית לצרכי הארגון
קיימת ביקורת שההתנהגות היא סתם חוות שרתים ולא ענן שמשולם ע"פ דרישה
מנוהל ע"י ספק שירותים
משאבים משותפים למשתמשים
הגדרות על מידע, רשתות ואבטחה מוגבלות
יש ענן פרטי ויש ענן ציבורי בגדול. ענן פרטי כמו שנשמע הוא ענן המתוחזק בתוך החברה, מותאם אישית עבור צרכי החברה אך הבעיה היא שיש עליו ביקורת שזו סתם חוות שרתים כי לא חולקים את המשאבים עם אף אחד לעומת ענן ציבורי ולא תמיד יש ניצולת מקסימלית מהמשאבים הקיימים.
Cloud Architecture– Rotem Eiko and Daniel Krom

5. סוגי ענן Virtual Private Hybrid שילוב של ענן פרטי וציבורי
First article - Cloud computing: state-of-art and research challenges
סוגי ענן
Virtual Private
Hybrid
שילוב של ענן פרטי וציבורי
גמיש מאוד בנוגע להגדרות והתאמות
שדרוג לענן הציבורי
מעבר לוירטואליזציה של כוח מחשוב, מאפשר גם ניהול רשתות ואבטחה כגון firewall
היברידי- החברה מתחזקת חלק מהענן וחלק אחר יושב אצל ספק שירותים חיצוני, למשל חברה שמאחסנת את כל נתוני הלקוחות שלה אצלה בענן פרטי אבל משתמשת בGMAIL לתקשורת ארגונית.
VPC- נדגים יותר מאוחר מהו, שכבה היושבת על גבי ענן ציבורי ומאפשרת וירטואליזציה של רשתות ואבטחה כלומר אפשר ממש להגדיר בענן חוקי תקשורת בדיוק כמו בראוטר של כל המידע הנכנס והיוצא.
Cloud Architecture– Rotem Eiko and Daniel Krom

6. First article - Cloud computing: state-of-art and research challenges
מאפייניי ענן
מרובה משתתפים (Multi-tenancy) כל משתמש מקבל מקום למידע שלו. מידע זה מפוצל על גבי מספר יחידות אחסון. המשתמשים חולקים את כוח המחשוב.
שיתוף כוח עיבוד(Shared Resource Pooling) הצרכנים "מאחדים כוחות מחשוב" עם צרכנים אחרים והופכים את כוח העיבוד למשותף, גדול וחזק.
לכוח העיבוד הגיאוגרפי, התמונה הזאת טובה אבל למחוק למעלה את הכותרת
מאפייני ענן – מספר תכונות שמאפיינות סוגים שונים של ענן
MULTY TENANCY- המידע מפוזר בין יחידות אחסון שונות אבל המשתמשים חולקים את כוח המחשוב. למשל קיים שרת מרכזי שכל משתמש עושה אליו פעולת RDP התחברות מרחוק אבל משתמש רק במשתמש שלו.
שיתוף כוח עיבוד – לכל אחד יש איזשהו כוח עיבוד. מדי פעם רק חלק מכוח זה בשימוש ומדי פעם כל הכוח לא מספיק. מאפיין זה נותן למשתמשים את היכולת להשאיל ולשאול כוח עיבוד.
Cloud Architecture– Rotem Eiko and Daniel Krom

7. First article - Cloud computing: state-of-art and research challenges
מאפייניי ענן
כוח עיבוד גאוגרפי(Geo-distribution) המשתמש מופנה לכוח עיבוד שהכי קרוב אליו מבחינה גאוגרפית.
כוח עיבוד דינאמי(Dynamic Resource Provisioning) הצרכנים "מאחדים כוחות מחשוב" עם צרכנים אחרים והופכים את כוח העיבוד למשותף, גדול וחזק.
כוח עיבוד גאוגרפי – במקרים רבים נרצה שזמן התגובה יהיה קטן מאוד ולכן נפרוש את הענן על גבי מספר מיקומים גאוגרפיים ונפנה את המשתמש אל כוח העיבוד הקרוב אליו ביותר. (דומה לארכיטקטורה של CDN-CONTENT DELIVERY NETWORK)
כוח עיבוד דינאמי – המשתמש מבקש מספק הענן הקצאות נוספות של כוח עיבוד או שחרור כוח עיבוד (כדי לחסוך עלויות).
Cloud Architecture– Rotem Eiko and Daniel Krom

8. מבנה ענן Virtual Private Cloud Application 1 Load Balancer Proxy
First article - Cloud computing: state-of-art and research challenges
מבנה ענן
Virtual Private Cloud
HTTPS
Geo Load Balancer SSL offloading
Proxy
HTTP
Application 1 Load Balancer
Application 2 Load Balancer
Application 3 Load Balancer
Application 4 Load Balancer
Application 1
Application 2
Application 3
Application 4
Clustered DB
Internet
Cloud Architecture– Rotem Eiko and Daniel Krom

9. First article - Cloud computing: state-of-art and research challenges
דרישות מהענן
קיבולת (Uniform high capacity)-התקשורת בין שרת לשרת צריכה להיות מוגבלת רק חומרתית (בידי כרטיסי הרשת)
יכולת נדידה וירטואלית (Free VM migration) – לענן צריכה להיות היכולת להעביר מחשב וירטואלי ממחשב פיזי אחד לאחר.
יכולת התרחבות (Scalability) – תשתיות הענן צריכות לספק את היכולת לגדול ולהתרחב (scale up & scale out).
יכולת התאוששות (Resiliency) –על הענן לדאוג שכוח העיבוד והתקשורת לא יושפע כלל משגיאות שעלולות להופיע בעת גדילה (scale).
יכולת נדידה וירטואלית – כשמישהו מקבל מחשב בענן מ"ה והכל, אותו מחשב הוא רכיב וירטואלי כלשהו שיושב על מחשב פיזי עם עוד מחשבים וירטואליים. צריכה להיות היכולת להעביר מחשב וירטואלי ממחשב פיזי אחד לאחר.
התרחבות – יש שתי יכולות התרחבות- התרחבות למעלה והחוצה. ההבדל- בלמעלה אנו לוקחים את אותה כמות משאבים שכבר יש לנו ומחזקים חלקים ממנה למשל הוספת מעבד, הוספת RAM וכדומה. בהחוצה אנו לוקחים כוח עיבוד ומחברים אותו לתוך יחידות העיבוד הקיימות כלומר מוסיפים עוד מחשב לכל המחשבים שיש עכשיו.
יכולת התאוששות- פעולת SCALE היא פעולה רגישה, שיכולה לגרום למספר רב של תקלות. ספק הענן צריך לדאוג שכוח העיבוד והתקשורת לא יושפע כלל בעת שינוי גודל.
Cloud Architecture– Rotem Eiko and Daniel Krom

10. First article - Cloud computing: state-of-art and research challenges
פיזור מידע
Cloud Architecture– Rotem Eiko and Daniel Krom

11. First article - Cloud computing: state-of-art and research challenges
פיזור מידע
MapReduce
Cloud Architecture– Rotem Eiko and Daniel Krom

12. First article - Cloud computing: state-of-art and research challenges
ספקי ענן עיקריים
הדגמה
Cloud Architecture– Rotem Eiko and Daniel Krom

13. First article - Cloud computing: state-of-art and research challenges
אתגרי מחקר
אוטומציה של משאבים דרושים במינימום עלות תיאור: תשלום עבור שירותי ענן לרוב מיוחס לכמות כוח עיבוד דרושה. הבעיה: אוטומציה של הקצאת משאבים מינימלית על מנת לחסוך מקסימום עלויות ומבלי לפגוע באיכות הביצועים.
נדידה של מחשבים וירטואליים תיאור: מחשב וירטואלי יושב על מחשב פיזי ואינו קבוע. הבעיה: נדידה של מחשב מחייבת את השבתתו. כיצד גורמים לזמן ההשבתה להיות אפסי?
איחוד שרתים תיאור: על מנת לחסוך באנרגיה נרצה לאחד מספר שרתים. הבעיה: איחוד מקסימום שרתים במינימום שימוש באנרגיה, בעיית ה-bin packing וזוהי בעיה NP-קשה.
לפי המאמר, כל עולם הענן עם כמה שהוא מפותח הוא עדיין בחיתוליו והוסברו מספר אתגרים מחקריים שעדיין קיימים שאיתם עדיין מתמודדים:
אוטומציה של משאבים דרושים במינימום עלות –התשלום בעבור הענן הוא לפי כוח העיבוד שדרשת. הבעיה היא איך אני יודע באופן אוטומטי שהמחשב יקבל אלגוריתם ויגיד בכל רגע מה המינימום שהוא צריך כדי לחסוך בעלויות מבלי שייפגעו הביצועים.
נדידה של מחשבים וירטואליים – אינו קבוע- יכול לזוז בכל רגע ממחשב פיזי אחד לאחר. בענן אנו מקבלים מחשב וירטואלי שאולי יושב על כמה מחשבים פיזיים וחולק משאבים פיזיים עם מחשבים וירטואליים נוספים. האתגר שמתמודדים איתו הוא minimum down time בעת נדידה. כלומר, איך נגיע למצב שהעברנו את המכונה הווירטואלית שלנו למחשב פיזי אחר עם זמן מינימלי שהמחשב הווירטואלי לא עובד. שיקול לדוגמה-העברה רק של הקבצים והאפליקציות לעומת העברה גם של מערכת ההפעלה. היתרון הגדול של נדידה הוא שרתי hotspot (כוח עיבוד זמני שנמכר במכירה פומבית).
איחוד שרתים-objects of different volumes must be packed into a finite number of bins or containers each of volume V in a way that minimizes the number of bins used
Cloud Architecture– Rotem Eiko and Daniel Krom

14. First article - Cloud computing: state-of-art and research challenges
אתגרי מחקר
ניהול אנרגיה תיאור: צריכת האנרגיה וקירור המערכות מהווה כ-53% מעלויות התפעול של הענן. הבעיה: מחקרים הראו כי האטה של מעבד והוספת יותר מעבדים יכולה להפחית עלויות אלו. כיצד מחליטים כמה להאט וכמה להוסיף?
אבטחת מידע תיאור: למשתמשי הענן אין גישה למחשב הפיזי שעליו מאוחסנים הנתונים ולכן הם נאלצים לסמוך על ספק הענן בכל הקשור לאבטחת המידע שלהם. במקרים רבים מידע של משתמשים שונים מאוחסן על אותה יחידה פיזית. הבעיה: הגנה על המידע של המשתמש מפני דליפה החוצה ומפני דליפה למשתמשים אחרים.
ניהול אנרגיה .
אבטחת מידע – מבחינת אחסון פיזי, הרבה פעמים המידע שלי והמידע של משתמש אחר יושב על אותו הארד דיסק פיזי.
Cloud Architecture– Rotem Eiko and Daniel Krom

15. Cloud Architecture– Rotem Eiko and Daniel Krom
Second article - Towards Understanding Cloud Performance Tradeoffs Using Statistical Workload Analysis and Replay
מאמר שני - הקדמה
זמן קבלת תוצאת ה- MapReduce מושפע משני גורמים מנוגדים:
Latency – זמן תגובה של שרת.
Cluster utilization - מספר השרתים המעורבים בתהליך.
ככל שיש יותר שרתים יש יותר כוח עיבוד למידע אבל צריך לחכות גם לתשובה של כל שרת ויש גם זמן העברת המידע ביניהם.
מאמר זה בא לבדוק השפעות של מספר גורמים על זמני ה-MapReduce.
Cloud Architecture– Rotem Eiko and Daniel Krom

16. Cloud Architecture– Rotem Eiko and Daniel Krom
Second article - Towards Understanding Cloud Performance Tradeoffs Using Statistical Workload Analysis and Replay
נתוני המחקר
התבצע איסוף נתוני אמת של שתי חברות עם ענן פרטי עצום:
Facebook – נתונים של שישה חודשים שנאספו מ-600 יחידות עיבוד שהריצו Hadoop Cluster (Hadoop היא פלטפורמה מבוססת MapReduce).
חברת אינטרנט גדולה – נתונים של שבועיים שנאספו מ-40 יחידות עיבוד שגם הורצו ע"י Hadoop Cluster.
כדי לבצע את המחקר, נאספו נתוני אמת משתי חברות גדולות.
להסביר למה זה הגיוני שבחרו חברה עם 600 יחידות עיבוד לעומת חברה עם 40 יחידות עיבוד- כי המאמר בא לחקור את הנושא של זמן תגובה משרת לעומת כמות שרתים. בהוספת שרת מתווסף גם זמן לתגובה והעברת מידע שלו.
Cloud Architecture– Rotem Eiko and Daniel Krom

17. Cloud Architecture– Rotem Eiko and Daniel Krom
Second article - Towards Understanding Cloud Performance Tradeoffs Using Statistical Workload Analysis and Replay
מושגים
CDF (Cumulative distribution function) – פונקציית הסתברות של משתנה מקריX שערכי הפונקציה קובעים את ההסתברות למאורעות X<=a.
Job – תת תהליך ב-MapReduce.
Cluster – קבוצה של מחשבים הפועלים כמחשב אחד.
Workload Analysis – כלי המאפשר לחזות תהליך עתידי ומשאבים דרושים בהתבסס על נתונים היסטוריים.
VNM – כלי עזר המאפשר לבחון השפעה משוקללת בין זמן תגובה (Latency) ובין גודל הקצרת משאבים. מבוסס על תאוריה מתורת המשחקים בכלכלה.
Cloud Architecture– Rotem Eiko and Daniel Krom

18. Cloud Architecture– Rotem Eiko and Daniel Krom
Second article - Towards Understanding Cloud Performance Tradeoffs Using Statistical Workload Analysis and Replay
נתוני המחקר
השמאלי- מייצג את ההסתברות של זמן הסיום של ג'וב אקראי. אם נסתכל על 60 שניות, ג'וב אקראי של פייסבוק רוב הסיכויים שסיים עד 60 שניות והחברה השניה בערך עד 300 שניות.
הימני- מייצג את הזמן הטוטאלי של סיום פעולת ה-MapReduce.
פונקציית ההסתברות של זמן ההגעה של עבודה פנימית
פונקציית ההסתברות של זמן הריצה של פעולת MapReduce
Cloud Architecture– Rotem Eiko and Daniel Krom

19. Cloud Architecture– Rotem Eiko and Daniel Krom
Second article - Towards Understanding Cloud Performance Tradeoffs Using Statistical Workload Analysis and Replay
נתוני המחקר
פונקציית ההסתברות של גודל המידע בכל אחד מהשלבים של MapReduce
פונקציית ההסתברות של ההבדל בין גודל הנתונים בכל אחד מהשלבים של MapReduce
Cloud Architecture– Rotem Eiko and Daniel Krom

20. Cloud Architecture– Rotem Eiko and Daniel Krom
Second article - Towards Understanding Cloud Performance Tradeoffs Using Statistical Workload Analysis and Replay
נתוני המחקר
פונקציית ההסתברות של ההבדל בין גודל הנתונים בכל אחד מהשלבים של MapReduce
פונקציית ההסתברות של ההבדלים בין המידע הנכנס למידע הסופי היוצא מתהליך ה -MapReduce
Cloud Architecture– Rotem Eiko and Daniel Krom

21. Cloud Architecture– Rotem Eiko and Daniel Krom
Second article - Towards Understanding Cloud Performance Tradeoffs Using Statistical Workload Analysis and Replay
נתוני המחקר
פונקציית ההסתברות של מספר הפעמים שרצה פונקציית ה- Map ומספר הפעמים שרצה פונקציית ה- Reduce
פונקציית ההסתברות של השבר של ריצות MapReduce על מכונה לוקאלית ו-Rack local (המידע שהמכונה מעבדת הוא לא המידע שהיא מאחסנת)
Cloud Architecture– Rotem Eiko and Daniel Krom

22. Statistical Workload Analysis and Replay for MapReduce
Second article - Towards Understanding Cloud Performance Tradeoffs Using Statistical Workload Analysis and Replay
SWARM
Statistical Workload Analysis and Replay for MapReduce
שיטה שפותחה ע"י כותבי המאמר Statistical Workload Analysis and Replay for MapReduce
השיטה יודעת לקבל נתוני עבר ובאמצעות אלגוריתם סטטיסטי יודעת לייצר עבודות אמיתיות עתידיות
Cloud Architecture– Rotem Eiko and Daniel Krom

23. Cloud Architecture– Rotem Eiko and Daniel Krom
Second article - Towards Understanding Cloud Performance Tradeoffs Using Statistical Workload Analysis and Replay
עיבוד המידע
המטרה היא ליצור את היכולת לייצר תהליכי עבודה שניתן להריץ בהינתן היסטוריים. עושים זאת ע"י: דוגמים מספר עבודות ובעבור כל עבודה מייצרים את הווקטור הבא: [inter-job arrival time, job name, input size, shuffle-input ratio, output-shuffle ratio]
באמצעות מערך הווקטורים שקיבלנו, ה-SWARM ייצר רצף של עבודות MapReduce במטרה להתחקות אחר מספר עבודות שרצות במקביל עם גדלים וזמנים שונים.
התוצאה: נוצרו שני סטים של עבודות. הראשון פייסבוק שכשמו כן הוא-מסתמך בעיקר על נתוני פייסבוק והשני דו-מצבי הנוצר ע"י כלי החיזוי.
לוקחים ג'וב מסוים, לוקחים את הזמן שלקח לו לרוץ ובאמצעות השם שלו עושים הצלבה על שאר הנתונים שלו שבוקטור.
לוקחים כל מיני ג'ובים שלא בהכרח שייכים לאותו תהליך MapReduce מקורי ומייצרים סטים של עבודות שממש ניתן להריץ בהסתמך על נתונים אלה.
Cloud Architecture– Rotem Eiko and Daniel Krom

24. Cloud Architecture– Rotem Eiko and Daniel Krom
Second article - Towards Understanding Cloud Performance Tradeoffs Using Statistical Workload Analysis and Replay
עיבוד המידע
סט העבודות מחולק ל-0.5% עבודות גדולות- 500 מגה של קלט לכל יחידת עיבוד ול-99.5% עבודות עם 50 מגה קלט לכל יחידת עיבוד.
Cloud Architecture– Rotem Eiko and Daniel Krom

25. Cloud Architecture– Rotem Eiko and Daniel Krom
Second article - Towards Understanding Cloud Performance Tradeoffs Using Statistical Workload Analysis and Replay
סביבת הניסוי
הניסוי בוצע באמאזון (EC2) על מחשבים מסוג m1.large שבהם 7.5GB של RAM ו-4 יחידות עיבוד (מדד אמאזון להקצאות זמן מעבד). על כל חד מהמחשבים הותקנה תוכנת Hadoop גרסה עם הגדרות ברירת המחדל.
Cloud Architecture– Rotem Eiko and Daniel Krom

26. אנליזת תוצאות הביצועים
Second article - Towards Understanding Cloud Performance Tradeoffs Using Statistical Workload Analysis and Replay
אנליזת תוצאות הביצועים
בוצעו מספר תהליכי MapReduce באמצעות שני ה-Workload שיצרו. תחילה כל אחד מהם רץ על מכונות מבודדות ולאחר מכן על מכונות משותפות על מנת לבחון את השפעת multi-tenant והופקו המסקנות הבאות:
ההתפלגות של זמן הביצוע של כל מכונה היא קבועה כלומר פונקציית ההסתברות באמת מייצגת את זמני הביצועים.
ניתן להפחית את הביצועים של כל מכונה ולהעלות את כמות המכונות אבל נשלם במחיר של Latency
באמצעות שימוש ב-VNM ניתן להרחיב את השקלול גם בעבור סוגים שונים של מכונות חישוב, גדלים שונים של cluster ועוד.
הרצה של מספר משתמשים במקביל מהווה את אותו שקלול של הקצאת משאבים מול זמן תגובה כמו הרצת קבוצה של עבודות במקביל.
Cloud Architecture– Rotem Eiko and Daniel Krom

27. Cloud Architecture– Rotem Eiko and Daniel Krom
Second article - Towards Understanding Cloud Performance Tradeoffs Using Statistical Workload Analysis and Replay
הרצה בקבוצות
על מנת לבחון את הביצועים של כל אחת מהעבודות בסקאלות שונות, הריצו אותן בקבוצות באופן בלתי תלוי על cluster בגודל 100 מחשבים זהים כאשר כל פעם הריצו קבוצה של עבודות באינטרוולים של 5 דקות, 15 דקות, שעה ויום.
הרצה בקבוצה (batch) – סט עבודות שמאופיינות:
קיימת גישה לכל המידע.
ייתכן שיחושב משהו גדול ומסובך.
לרוב מתייחס יותר לתפוקה מאשר זמן תגובה של אחד הרכיבים.
בדרך כלל זמן התגובה מחשוב בדקות (או יותר).
להסביר בעל פה על STREAM
Cloud Architecture– Rotem Eiko and Daniel Krom

28. Cloud Architecture– Rotem Eiko and Daniel Krom
Second article - Towards Understanding Cloud Performance Tradeoffs Using Statistical Workload Analysis and Replay
הרצה בקבוצות
Cloud Architecture– Rotem Eiko and Daniel Krom

29. Cloud Architecture– Rotem Eiko and Daniel Krom
Second article - Towards Understanding Cloud Performance Tradeoffs Using Statistical Workload Analysis and Replay
הרצה בקבוצות
Cloud Architecture– Rotem Eiko and Daniel Krom

30. Cloud Architecture– Rotem Eiko and Daniel Krom
Second article - Towards Understanding Cloud Performance Tradeoffs Using Statistical Workload Analysis and Replay
הרצה בקבוצות
Cloud Architecture– Rotem Eiko and Daniel Krom

31. Cloud Architecture– Rotem Eiko and Daniel Krom
Second article - Towards Understanding Cloud Performance Tradeoffs Using Statistical Workload Analysis and Replay
שקלולים נוספים
גודל ה-cluster – ניתן להריץ כמות גדולה של נתונים עלcluster גדול ויחיד או לפצל את סט העבודות הנדרש ולחלק אותו בין מספר מכונות שונות. בעבור כמות נתונים גדולה, cluster יחיד הוא הפתרון ההכרחי לעומת זאת, שימוש ב- clusters קטנים יכול למנוע צוואר בקבוק.
צוואר בקבוק- בCLUSTER גדול הנתונים מתקבצים למספר מוקטן של מחשבים.
Cloud Architecture– Rotem Eiko and Daniel Krom

32. Cloud Architecture– Rotem Eiko and Daniel Krom
Second article - Towards Understanding Cloud Performance Tradeoffs Using Statistical Workload Analysis and Replay
שקלולים נוספים
2. סוג המכונה – cluster מורכב ממספר מכונות ובחירת המכונה הנכונה הוא צעד חשוב. בדרך כלל מכונה יותר "חזקה" תעלה יותר כסף אבל נרצה שהמכונה תהייה חזקה יותר ביכולות שרלוונטיות לחישוב MapReduce.
(לדוגמא- ניתן להשתמש במכונה מאוד יקרה שרוב עלותה הוא כוח עיבוד גרפי (GPU) אבל כוח זה אינו רלוונטי לדרישות).
Cloud Architecture– Rotem Eiko and Daniel Krom

33. Cloud Architecture– Rotem Eiko and Daniel Krom
סיכום
בתהליך ה-MapReduce תמיד זמן התגובה וכמות המשאבים יבואו אחד על חשבון השני בין היתר בגלל פערים בין ספקי שירותי הענן לבין קהילת המפתחים.
משתמשים המעוניינים לעשות אופטימיזציה חייבים להבין את המאפיינים הסטטיסטיים של סט העבודות שלהם.
כלי ה-SWARM שפותח מראה שגם בעבור פעולות מורכבות כמו MapReduce ניתן לחבר סט פעולות באמצעות התפלגות סטטיסטית מנתונים קודמים שנאספו.
ניתן להרחיב את כל ה-SWARM בעבור פעולות נוספות (שאינן קשורות ל- MapReduce) וכלי זה יכול להוות כלי חישוב בעבור תוכנות רבות שרצות בענן.
באמצעות כלי ה-VNM ניתן לחשב שקלול רב מימדי (לא רק זמן תגובה מול כמות משאבים) ובכך ניתן להגדיר ביצוע טוב במספר דרכים.
Cloud Architecture– Rotem Eiko and Daniel Krom

34. Cloud Architecture– Rotem Eiko and Daniel Krom
שאלות?
Cloud Architecture– Rotem Eiko and Daniel Krom