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

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 וחוקר אותו לעומק

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

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

סוגי ענן 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

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

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

מבנה ענן 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 גרסה 0.18.2 עם הגדרות ברירת המחדל. Cloud Architecture– Rotem Eiko and Daniel Krom

אנליזת תוצאות הביצועים 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

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

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

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

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

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

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

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

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