היבטים טכניים של עבודה באמצעות שירותי ענן

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

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

מבנה הענן, ואתגרים בעבודה מול שירותי ענן

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

בואו נדבר על המקרה הפשוט ביותר, חיבור משרד בודד לענן, ועד לעבודה ממספר רב של סניפים מול ענן בודד ומול מספר עננים שונים Multi-Cloud:

• מקרה 1 – משרד בודד מול ענן
• מקרה 2 – משרדים רבים בארץ, מול ענן מקומי או גלובלי
• מקרה 3 – משרדים רבים, בארץ ובעולם, מול ענן מקומי או גלובלי

אבל קודם כל, בואו נדבר קצת על פרוטוקולים

מבנה וסוגי עננים

"ענן" הוא בסה"כ שרתים שמותקנים באתר או אתרים מרוחקים, כאשר בנוסף לשרת הכולל CPUs, RAM ו- Storage, תשתיות כמו Databases (MS-SQL, MongoDB ואחרים) ניתן לרכוש שירותים ויישומים שונים, החל מאבטחת מידע, חלוקת עומסים (Load balancing), Caching וארגון המידע ברשתות גלובליות (CDNs), ועד לשרתי וידאו עם "דחיפת" הוידאו למשתמשים ועוד.

בעבודה מול ענן כזה או אחר, ישנן שתי אפשרויות:

1. עבודה מול אחד מספקי השירות המקומיים. במקרה זה היישומים והמידע יאוכסנו מקומית, והגישה אליהם תהיה ברוחב פס שנרכוש, וב- Delay של mSec בודדים. על החשיבות של נתון זה נדבר בהמשך. בתלות בסוגי היישומים שבהם נעבוד, יש משמעות רבה גם האם קו התקשורת הוא סימטרי או אסימטרי, כפי שנראה בהמשך.
2. עבודה מול אחד מספקי השירות הגלובליים – Amazon AWS, Microsoft Azure, Google Cloud ואחרים. במקרה זה, נעבוד מול שרתים ושירותי תקשורת באתרים אחרים בעולם, עד להקמת סניפים מקומיים של הענקים. מייקרוסופט כבר מתוכנן ב- 2021, אמזון בדרך, גם אורקל ורבים אחרים, מה שיהווה תחרות מאוד משמעותית לספקים המקומיים.

ישנן כמובן תצורות רבות נוספות, למשל עבודה מול מספר ספקי ענן (Multi-cloud), ענן היברידי כלומר עבודה מול שירותים ברשת שלנו  (On-Prem)וברשת ענן (Cloud) ועוד. ההיבטים הטכניים עליהם נדבר נכונים לכל האפשרויות.

סקירה על תצורות עבודה בענן ומי ספקי הענן המובילים בישראל – ניתן לקרוא כאן.

יישומים

היישומים העובדים מול שירותי הענן הם אותם היישומים שאיתם אנחנו עובדים מאז ומתמיד. יישומים אלו יהיו:

1. אחסון קבצים, כולל עבודה ב- Office, עבודה ביישומי תיב"מ (קבצים גדולים), קבצים גרפיים/וידאו וכד'
2. עבודה מול Databases – ב- Client, HTTP או ב- Terminal/Citrix
3. שירותי Voice/Video/Multimedia

אחסון קבצים

באחסון קבצים אנחנו נעבוד במספר אפשרויות. באפשרות הראשונה נעבוד בהעברת/שמירת קבצים באמצעות HTTP, כאשר אנחנו עובדים כמובן מעל TCP. כפי שכבר הסברתי במאמרים קודמים, הנוסחה לחישוב קצב העברה (או כלל האצבע, כי TCP השתדרג כבר מספר פעמים מאז שנבעה הנוסחה):

כאשר RTT זה הזמן בין משלוח TCP Segment  לקבל ה- Acknowledge עליו, שתלוי גם ב- Delay על קו התקשורת. כלומר, ככל שה- Delay  גבוה יותר מהירות ההעברה תהיה נמוכה יותר. אם אנחנו מדברים על אחסון קבצים באירופה (50-70 מילי שניות) או ארה"ב (150-200 מילי שניות), אז ישנה איטיות מובנית בהעברת קבצים, וגם אם ניקח קו מאוד רחב לאינטרנט (בדרך לשירותי הענן), מגבלה זו תאיט את העבודה שלנו.

נושא חשוב נוסף הוא שב- Google נעבוד בפרוטוקול העברת קבצים של QUIC/GQUIC שהם פרוטוקולי העברת קבצים מעל UDP שפותחו על ידי Google  עצמם, ויעבדו יותר מהר משמעותית מהפרוטוקולים הסטנדרטיים.

דבר נוסף, בתלות באופן העבודה, אם מדובר על שמירת ופתיחת קבצים חשוב שקו התקשורת לאינטרנט יהיה סימטרי, כלומר זהה בשני הכיוונים (50/50, 100/100 וכד'). לא מעט לקוחות קטנים שהגיעו אלינו התחברו בקו אסימטרי לאינטרנט, עם מהירויות העלאה של 4Mbps  או 5Mbps ולא הבינו למה שמירת קובץ לוקחת דקות או עשרות דקות.

עבודה מול Databases

בעבודה מול Database ישנן שלוש צורות עבודה עיקריות – עבודה ב- Client/Server, גישה ב- HTTP  או גישה ב- Terminal/Citrix. לכל אחת מהשיטות יתרונות וחסרונות, כאשר גם כאן גורם ה- Delay הוא משמעותי.

1. עבודה ב- Client/Server – כאן יש Client שמחליף מידע עם ה- Server. יותר מדי Packets שיעברו בינהם, כאשר השרת נמצא במרחק של כמה עשרות מילי-שניות ומעלה יכול להיות בעייתי ולהאיט את העבודה.
2. עבודה ב- Terminal Server או Citrix MetaFrame (XenApp) – כאן אופן העבודה הוא שאנחנו מקלידים למעשה על השרת, כאשר מה שאנחנו רואים זה ה- Echo אלינו למסך. היו לי כמה מקרים שעבדו בצורה זו מול ה- Database, כאשר הקלדנים הקלידו מאוד מהר, ומכיוון שה- Echo חזר אליהם משרתים מרוחקים (70-80 מילי-שניות ומעלה), לקח זמן ל- Echo של האותיות לחזור מהשרת למחשבים המקומיים, והקלדנים התלוננו שהם כותבים והכתב זה מאוד לאט ..
3. עבודה ב- HTTP, כאשר ניגשים לשרת WEB שעליו מותקן ה- Client שעובד מול השרת. זאת בד"כ צורת העבודה היעילה והנפוצה ביותר. צריך רק לדאוג לזה (וגם לשלם לספק ה- Cloud) שיהיה שרת WEB חזק שייגש לשרת ה- Database ושניהם יותקנו אצל ספק הענן.

שירותי Voice/Video/Multimedia

בשירותי Voice/Video פשוטים, כלומר שיחות טלפון או שיחות וידאו, מה שנראה בעבודה מול ענן זה בדיוק מה שאנחנו רואים בשירותים כמו Microsoft Skype, Google Hangouts ועשרות שירותים אחרים. מכיוון שה- Signaling יעבוד ב- SIP מהמרכזייה ממנה רכשנו את השירות מול המרכזייה אליה מחובר יעד השיחה, והשיחה תתנהל בכל מקרה ב- RTP, אזי איכות השיחה שנקבל תהיה תלויה באיכות הקו ביננו לבין היעד, דבר שאין לנו עליו שליטה אבל כמעט תמיד נוכל לקבל איכות סבירה ויותר.

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

פרוטוקולי תקשורת ואופן העבודה בענן

כמה מילים על פרוטוקולים. נדבר ונראה דוגמאות להעברת קבצים, עבודה ב- Database וצפיה בווידאו. כל הדוגמאות מתוך קורס Wireshark אותו אני מעביר (*4)

העברת קבצים

בהעברת קבצים מעל TCP, נראה בד"כ מספר Packets בכיוון ההעברה, ו- Acknowledge בכיוון הנגדי, כמו בדוגמא הבאה (הורדת Driver למדפסת מאתר HPE):

בתמונה רואים את Packets 3118-3134, אבל אם ניקח בחשבון קובץ של כמה Mbytes לפחות, שייקח אלפי Packets להביאו אלינו, כאשר אחרי כל 2-3Packets מקבלים גם Acknowledge חזרה, אז ברור למה ההורדה ב- Delay גבוה תיקח זמן.

בגרף קצב ההורדה אנחנו רואים כי אנחנו מגיעים לקצב הורדה של כ- 0.8-1.8Mbps בממוצע, כפי שרואים להלן:

והסיבה לכך היא Delay גבוה, כפי שרואים ב- IO Graph להלן:

למרות שהקו הוא של 100Mbps קיבלנו קצב הורדה נמוך, וזאת בגלל ה- Delay המאוד גבוה.

אותן בעיות יהיו אם תעבדו ב- FTP כמו בדוגמא, ב- HTTP או ב- NetBIOS/SMB. במקרה של שימוש בפורטלים (למשל Sharepoint), Caching, רשתות CDNs  וכד', חשוב המיקום הפיסי של הקבצים, ומאיפה אנחנו ניגשים אליהם. ככל שיהיו יותר קרובים אלינו (במונחי Delay), נקבל ביצועים טובים יותר.

ב- Google GQUIC (תמונה הבאה), אנחנו רואים העברה מעל UDP, כאשר רואים כמות גדולה של Packets בכיוון השרתים (שמירת קובץ), ורק אחרי 8-10 Packets רואים Packet חוזר. כמובן שגם גודל ה- Header ב- UDP קטן מזה שב- TCP, מה שגם משפר את מהירות שמירת הקובץ.

עבודה ב- Database

גם בעבודה ב- Databases, כאשר עובדים ב- Client/Server, נושא ה- Delay הוא קריטי. בדוגמא הבאה רואים עבודה של Client מול Server:

וגם כאן, למרות שה- Delay סביר יחסית (עשרות mSec’s), מכיוון שעבור Query מסויים ה- Client  מעביר אלפי Packets מול ה- Server, נקבל את התוצאה של אותו ה- Query לאחר זמן רב.

סיכום:

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

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