הבדלים בין Snapshot לגיבוי

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

על מנת להדגים זאת, ניקח שני מימושים שונים שיהיו מוכרים לרוב הגולשים:

  • מימוש ראשון VMWare Snapshot
  • מימוש שני – AWS Snapshot

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

עכשיו נעקוב אחר התהליך הנ"ל מקרוב. ברגע שיצרנו את ה-Snapshot לאותו VM, הוא מתחיל בגודל 0 בתים (או משהו קרוב לכך, יכול להיות שה-snapshot יכלול בתים ספורים בהתחלה). ברגע שערכנו את אותו קובץ טקסט ושמרנו אותו, הוא אינו שומר את השינוי לדיסק הקשיח הוירטואלי, אלא שומר אותו לתוך ה-snapshot. אם נבדוק, נוכל לראות שגודל ה-snapshot גדל בכמות הבתים שהוספנו לאותו קובץ טקסט (את הדברים הרבה יותר קל לראות "מבפנים" אם משתמשים במערכת ZFS, שהיווה "השראה" ל-VMWare כיצד ליצור snapshots). אם לאחר שיצרנו קובץ Snapshot, עבר זמן ויצרנו קובץ snapshot חדש, כל השינויים שניצור מעתה ישמרו ב-Snapshot החדש, וה-snapshot הקודם יעבור למצב read only.

המימוש השני של snapshot לשם הדוגמא יהיה AWS EBS Snapshot: הקמנו Instance (כלומר VM) עם מערכת ההפעלה שבחרנו, ולאחר מכן ביצענו מספר שינויים בהגדרות, הוספנו אפליקציות ועוד, וכעת אנחנו יוצרים Snapshot ב-AWS. ה-Snapshot הראשון שניצור ישמור את השינויים מהקמת ה-VM עד לרגע זה. אם ניצור Snapshot נוסף, הוא ישמור את השינויים שנוצרו מאז ה-Snapshot הראשון, כלומר כל שינוי שביצענו אחר ה-Snapshot הראשון ישמר בדיסק EBS ולא ב-snapshot ורק אם ניצור snapshot נוסף, השינויים יועתקו אליו.

המימוש של AWS Snapshot מאוד דומה לגיבוי אינקרמנטלי שאפשר ליצור עם תוכנת גיבוי לטייפ או VTL – אנחנו קודם כל יוצרים גיבוי מלא, ולאחר מכן כל גיבוי אינקרמנטלי מגבה בעצם את השינויים (Delta) מאז הגיבוי המלא האחרון.

מכאן נעבור לנקודה היותר "פילוסופית" – האם snapshot יכול להחליף את מקומו של הגיבוי? זה תלוי.

במקרים כמו VMWare התשובה היא "לא ממש" הואיל ויצירת Snapshot הוא דבר שצריך לבצע "ידנית". המערכת לא תיצור עבורך snapshot אוטומטית (למרות שלמערכת יש בהחלט דבר שנקרא Changed Block Tracking שמופעל אוטומטית ובכך המערכת יודעת לזהות כל שינוי שבוצע בדיסק, ואין זה משנה איזו מערכת הפעלה מדובר, כי אותה מערכת עובדת בבלוקים, לא ב-File system) ולכן גיבוי של המערכת ע"י תוכנת גיבוי (Veeam, Arcserve ושאר תוכנות) היא דבר חשוב ואף הכרחי.

בעננים ציבוריים כמו AWS לעומת זאת, יש צורך לעבוד בשיטה שונה (שלצערי יש לא מעט שמתחילים לעבוד עם AWS ולא מפנימים זאת): ב-AWS כדאי לבנות את מכונות ה-VM כ"שלדים" (templates) ולשמור את הקבצים המשתנים ב-EFS או ב-S3. כך, בונים VM, מגדירים את הדברים הקבועים, מוסיפים סקריפט שידע להעתיק את הקבצים הנחוצים מ-S3 או EFS, יוצרים snapshot ולאחר מכן ממירים את זה ל-Image בפורמט AMI סגור. נדפק ה-VM? פשוט מקימים חדש מה-AMI כשאחד הפרמטרים הוא בעצם הרצה של הסקריפט שיצרנו כך שלאחר הקמת ה-VM/Instance – הוא יעתיק את הקבצים וידווח לנו מה כתובת ה-IP הפנימית של ה-VM החדש.

ב-ZFS הדברים שונים. מכיוון ש-Snapshot ב-ZFS אינו תופס מקום בדיסק (0 בתים), ישנה שיטה פשוטה ליצור אוטומטית snapshots כל זמן שתרצה. אני לדוגמא עובד עם ZFS שיוצר snapshots כל שעה, כל יום, כל שבוע, כל חודש, כל שנה – ומגדיר את המערכת שתשמור לי 50 snapshots אחורה. מבחינת שרידות, ZFS תומך במערך RAID (שנקרא RAIDZ) עד רמה שלישית (כלומר: המערכת יכולה לתפקד עד למצב שבו יש שלושה דיסקים תקולים) עם תמיכה מלאה ב-Hot Spare. מעבר לכך, מערכת ZFS נותנת גם "להשתולל" עם מערכי RAIDZ כך שניתן להקים שתי מערכות RAIDZ3 ולצוות אותן יחד כ-RAIDZ1. בזבוז מטורף של דיסקים? בהחלט, אבל למי שיש תקציב – בכיף. מה עם גיבוי לטייפ? יש כאלו שמגבים אחת לזמן מה לטייפ ויש כאלו שפשוט מעדיפים להשתמש בתשתית ה-ZFS ופקודות ה-send/receive המובנות על מנת לגבות את ה-ZFS למערכת מרוחקת. (אפשר כך לבנות אחסון DR בזול. אגב, מקומות רבים בחו"ל משתמשים בשיטה הזו).

לסיכום: "snapshot אינו מחליף גיבוי" – זו הצהרה שאינה נכונה תמיד. יש מקרים שזו הדרך היחידה שלך לגבות (עננים ציבוריים), ויש מקרים שמימוש ה-Snapshots (כמו ב-ZFS) אינו מצריך גיבוי לקלטת כל יום. לגיבוי יש מקום חשוב ול-snapshot יש גם מקום חשוב וביטול אחד ו"הילול" הדרך השניה אינה בהכרח התשובה הנכונה.

המעבר לענן ציבורי – התהליכים המקדימים

דמיינו לעצמכם סיטואציה פשוטה: יש לכם 20 שרתים בחברה (פיזיים) שמערכת vSphere רצה עליהם. הכל מתקתק ועובד טוב עד שיום אחד האחראי על ה-vSphere בחברה מפוטר עקב סיבה כלשהי. האם יהיה קשה למצוא עובד חלופי לאותה משרה? לא ממש, השאלה למה אתה מצפה: אם לדוגמא העובד שפוטר היה כותב סקריפטים ב-Powershell או ב-PERL לאוטומציה של ה-vSphere ורוב העבודה היתה נעשית באוטומציה כלשהי ללא שימוש ב-GUI – אז כן, אתה תתקשה למצוא מחליף (וגם אם תמצא, תצטרך לשלם לו הרבה יותר ממה שחשבת). אם לעומת זאת אתה מחפש מישהו שינהל רק ברמת הממשק Web, תמצא לא מעט כאלו בקלות ותוכל לשלם להם משכורת יותר נמוכה אפילו (תלוי בכישורי המו"מ שלך והבטחון העצמי של המועמד). מצד שני, אם יש לך תקלות שמתאפיינות במסך סגול וגוגל לא ממש עוזר – תתכונן לשלם והרבה, בין אם זה ל-VMware או למישהו מומחה.

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

מה בעצם העבודה שהרוב יציעו ויעשו? הם יעשו מה שאני קורא "Copy Paste". נניח שיש 10 מכונות VM, הם פשוט יעלו אותן לענן כ-Instances, יקצו להן כתובות IP חיצוניות פר Instance (תתפלאו כמה חוסר מקצועיות יש בנושא), יגדירו Security Group שנושאת מטוסים יכולה לעבור דרכו, חס ושלום VPC חדש ונורמלי, או ניתובים קצת יותר מוקשחים. אם הלקוח מתעקש על Firewall, אז יתקינו איזה משהו שקיים ב-Market עם חוקים מאוד "רפים". אני לא מנסה "ללכלך", אני בדרך כלל מי שמגיע אחרי כן לבדוק מדוע הדברים לא עובדים טוב וזה מה שאני מוצא. אני כמובן שלא אומר שכולם כך, יש דווקא לא מעט אנשים מקצועיים בתחום.

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

בהעברת התשתית לענן יש לנו 3 מטרות חשובות:

  • הורדת המחיר פר מכונה
  • קבלת ביצועים יותר גבוהים
  • הגנה יותר נאותה.

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

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

כך ניתן להגיע למצב שבמקום "לזרוק" X מכונות VM לענן, אפשר לתכנן בצורה מיטבית מ-אפס את הכל ולנצל טכנולוגיות עכשוויות גם לקבל ביצועים יותר גבוהים וגם לשלם מחיר יותר נמוך  וכמובן – אבטחה הרבה יותר רצינית ומודרנית, לא רק חסימה של פורטים ב-Firewall.

יהיו כמובן כאלו שיאמרו שזה תהליך יותר יקר, שזה נכון, אבל מצד שני, לאחר תהליך ההקמה, התשלום החודשי יהיה יותר זול והתשתית תהיה יותר מאובטחת מאשר בשיטה של "לזרוק מכונות VM לענן".

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

האם תוכניות DR באחסון ישראלי שוות את הכסף?

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

כשזה מגיע ל-DR בארץ, כל הגורמים המשתתפים בהקמה – בדרך כלל יכולים לחייך. אם חברה X רוצה להקים DR, הספקים והאינטגרטור מחייכים. מדוע? כי כשחברה צריכה DR, צריך לרכוש ציוד. זה מתחיל בסטורג' זהה למה שיש לחברה כיום (ברוב המקרים), שרתים, סוויצ'ים, אולי הרחבה של התקשורת היעודית בין החווה המקומית לחוות שרתים ששם תשכון תשתית ה-DR, אולי גם VPN, רשיונות מערכות הפעלה, רשיונות פלטפורמות, וירטואליזציה ובקיצור, מדובר על "לשפוך" כמות גדולה של כספים. תזכרו את הפיסקה הזו, נגיע אליה בהמשך.

אחד הדברים הראשונים שהכי חשובים לזכור לגבי DR ולא חשוב מה הפלטפורמה שמשתמשים קשור ל-איך זה יוקם ומה השימוש: ה-DR מטרתו לתת לנו המשכיות עבודה לזמן קצר (שעות, ימים) ואחת ההחלטות הראשונות שצריך להחליט היא בעצם איזה חלק מהתשתית יש צורך להקים כ"מראה" בצד של חוות השרתים החיצונית. על מנת לפשט את הדברים, נניח שיש חברה בשם "אבגד" שיש להם תשתית מקומית של 50 שרתים, 2 מכונות סטורג', ומספר מתגים. החברה בודקת אם להקים DR מול החווה של בזק נניח. האם החברה רוצה להקים בבזק 2 מכונות סטורג', 50 שרתים פיזיים ומתגים? או שהחברה רוצה לעשות DR שהתשתית בצד של בזק תהיה יותר מצומצמת כך שרק הדברים ההכרחיים ירוצו? בכל צד יש יתרונות וחסרונות וזהו שיקול חשוב שהחברה תצטרך לשקול.

מכיוון שיש ערימות של פלטפורמות ופתרונות DR שעובדות ומסנכרנות נתונים בדרכים שונות, אתאר את התהליך באופן כללי: אחרי שרכשנו את הציוד, ומתוך הנחה שהחברה משתמשת בוירטואליזציה, אנחנו נתקין את מערכת הוירטואליזציה הבסיסית (ESXI) בשרתים ולאחר שמכונות הסטורג' יסתנכרנו, נחבר דרך ה-vCenter את הסטורג' לשרתים, נגדיר את המתגים, כתובות IP ועוד ועוד. אחרי שמסיימים את הכל, התוכנה שמבצעת את עבודת הרפליקציה בין הסטורג' בחברה לחווה – ממשיכה לעבוד 24/7 וברוב הזמן היא מרפלקת לכיוון אחד (כי בצד של החווה אף אחד ברוב הזמן לא עובד על השרתים, עד למצב חרום או "תרגיל"). ברוב המקרים כשתהיה נפילה, פתרון תוכנת ה-DR ידע לשנות את הפרמטרים הנחוצים על מנת לאפשר עבודה מול החווה של בזק.

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

ומה לגבי פתרונות בעננים ציבוריים? הנה משהו שהרבה מאוד אינטגרטורים יציעו שלא להשתמש כפתרון DR בגלל כל מיני סיבות: מחיר, Latency, ועוד…

מבחינת מחיר – אכן, עננים ציבוריים אינם דבר זול, אך בניגוד לתוכנות DR רבות, ב-AWS עם שימוש פלטפורמה כמו CloudEndure, אתה יכול לבחור אלו מכונות להעביר לענן בפקודה (או בקליק פשוט) וכל עוד יש בחברה ידע בשימוש AWS לדוגמא, כל תהליך ה-DR יקח מספר שעות (תלוי ברוחב הפס שיש לחברה). עלות השרות היא 99$ למכונה + עלות המכונה (Instance) עצמו כפי שניתן לראות כאן. וכאן ניתן לראות הדגמה של גיור מספר מערכות לענן של אמזון עם CloudEndure.

האם ניתן לקבל פתרונות יותר זולים? כן, אבל אז מדובר בעבודה "ידנית" של העלאת מכונות VM לתוך Region אצל ספק הענן, יש צורך בבניית רשת תקשורת לוגית, ואחרי שהכל הועבר בפעם הראשונה, אפשר להשתמש בשרות כמו Datasync לרפליקציה מתמשכת מחוות השרתים לענן הציבורי. מכיוון שמדובר ברפליקציה שברובה תתבצע בכיוון אחד, אין תשלום על התעבורה והתשלום לגבי נתוני הרפליקציה הוא ברובו על האחסון ו-4 סנט פר ג'יגהבייט על שרות Datasync.

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

ומה לגבי עניין ה-Latency? ובכן, אחד היתרונות הגדולים של ספקי הענן, הוא שאין צורך לשלם מראש או לשלם סכום חודשי קבוע בכדי לנסות שרות, אפליקציה, פלטפורמה וכו'. אם לדוגמא אתם רוצים לדעת אם יש Latency רציני עם אפליקציות פרודקשן שאתם צריכים שירוצו ב-DR, כל מה שתצטרכו לעשות זה להיכנס ל-Market Place של אמזון לדוגמא, "לשכור" את התוכנה (המערכת תקים עבורכם את המכונות ותתן לכם כתובת IP עם פרטי התחברות). ברגע שזה רץ, מעלים נתונים ומגדירים את המערכת, ופשוט מנסים זאת. אצל ספק הענן תמיד ניתן יהיה לבחור מכונה יותר קטנה או גדולה מבלי לאבד נתונים וזה לוקח דקות ספורות.

אחרי שהקמתם ו"שיחקתם" עם המערכת, יהיו בידיכם נתונים ברורים האם ה-Latency משחק תפקיד, האם זה רץ יותר מהר או לאט ממה שיש לכם כיום (אפשר תמיד לבחור דיסק עם יותר IOPS והמכונות הן יותר חדשות ממה שיש לכם ויותר מהירות) – ואז תוכלו להחליט. עלות כל הבדיקה הזו – דולרים ספורים. לאחר שסיימתם, אל תשכחו למחוק את המכונה.

לסיכום: ענן ציבורי צריך לעניות דעתי להיחשב כאופציה נוספת לפני שמחליטים על תוכנית DR, איזה DRaaS וכו'. המחירים יקרים – כשמשלמים לפי שעה (אם לדוגמא משלמים מראש ל-3 שנים, יש עד 75% הנחה פר VM באמזון, לדוגמא). אין צורך לרכוש ציוד נוסף ותלוי בתהליך ה-DR שבחרתם, הוא יכול להתבצע תוך זמן קצר או כפרויקט. יכול להיות שההצעות מספקים מקומיים יהיו יותר זולים, אולי כדאי לחשב את הדברים מראש כתשלום ל-3 שנים ואז להשוות (שימו לב: כל ספקי הענן, ברוב המקרים, ישמחו לתת לכם אלפי עד עשרות אלפי דולר כקרדיטים לשנה הראשונה, כך שזה יכול בהחלט להשפיע על מחיר וההחלטה). אל תקשיבו לאלו שישר פוסלים הצעות של עננים ציבוריים, עדיף שיהיו בידכם המספרים המדוייקים והמעודכנים – ואז תוכלו להחליט.

(גילוי נאות: "חץ ביז" מציע את שרותי ה-DR לעננים ציבוריים)

קצת על CDN וישראל

לא מעט אנשים שמבינים בבניית תשתית, שרתים, פלטפורמת Web, הפצת תכנים וכו' יוכל לאמר לך שכיום אין יתרון ממשי לארח אתרים בישראל. בעבר, רבים הקימו פה בארץ אתרים לקהל הישראלי עקב מחשבה על SEO (לא בגלל מחירים), אבל מי שקצת מבין באמת ב-SEO ולא הולך לפי אמונות תפלות (ולא חסרים כאלו) יכול להבין מהר מאוד שלגוגל ממש לא אכפת אם תאכסן את האתר/שרת וירטואלי שלך בקוטב הצפוני – כל עוד קהל המטרה המוגדר (נניח ישראל) מקבל את הדפים והאתר במהירות, ובשביל זה יש CDN ולגוגל ממש אין בעיה עם CDN (אדרבא, הם מציעים שרות כזה במסגרת שרותי הענן הציבורי שלהם).

הדוגמא הכי פשוטה שאני יכול לתת היא בלוג זה שאתם גולשים בו כרגע. הוא מתארח ב-AWS בוירג'יניה, אך הוא נעזר בשרותי CDN של Cloudflare וכ-600-1500 איש גולשים בו ביום, הם מקבלים את הדפים במהירות, והעלות הכוללת היא מזערית (20$ + מע"מ לחודש). בלי שרותי CDN, המכונה הקטנה הזו (2 ליבות, 4 ג'יגה זכרון) לא היתה מחזיקה מעמד עם אותה כמות של גולשים ובלוגים שאני כותב.

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

  • שרתים וירטואליים (או פיזיים) שמפוזרים ביבשות ובמדינות מפתח שונות הכוללים שרתי Web, שרתי אפליקציה, שרת (או שרותי) בסיסי נתונים, שרות DNS ועוד ועוד. לחלופין במקום שרתים, אפשר להשתמש (ומומלץ) בקונטיינרים עם שרותי קונטיינריזציה שספקי ענן ציבורי מציעים (או להקים משלכם, אם כי בעננים ציבוריים זה קצת פחות מומלץ והרבה יותר מסובך).
  • תשתית שמאפשרת לבצע Scaling דינמי
  • תשתית אחסון
  • תשתית ניטור
  • הגנה – חומת אש, WAF…
  • CDN
  • ועוד ועוד..

שרות ה-CDN בעקרון נותן לגולש שמגיע את התכנים הסטטיים שמרכיבים את דף הבית. ברגע שהמשתמש מבצע Login ומתחיל להשתמש במערכת, הוא יקבל גם תכנים סטטיים (נניח גרפיקה) וגם תכנים המותאמים לו אישית (כותרת עם שמו, הפרטים שלו וכו') דרך ה-CDN. ה-CDN אינו מבצע קסמים והוא יודע להנגיש את התכנים הסטטיים, אולם כל דבר שצריך עיבוד, מגיע אל שרתי האפליקציה שלך וכאן חשוב המיקום הגיאוגרפי של השרתים, ויש לא מעט פלטפורמות שיודעות להפנות את הגולש שלך לשרתים הקרובים אליו גיאוגרפית.

ישנם לא מעט חברות המציעות שרותי CDN. כל ספקי הענן הציבורי מציעים זאת, וכמובן חברות כמו Cloudflare, Akamai, Brightcove, Incapsula ועוד ועוד. ספציפית לגבי ישראל, לכל ספקי ה-CDN היעודיים יש בארץ נקודות שמזרימות תכנים אל גולשים ישראליים ומבחינת ספקי ענן – כרגע רק אמזון מציעה נקודה כזו (שנקראת POP) בישראל.

אחרי שאנחנו מבינים את הצורך ב-CDN, נשאלת השאלה – איזה CDN כדאי להשתמש?

שרותים כמו Incapsula ו-Cloudflare מציעים פתרון שמאוד מזכיר דבר כמו Reverse Proxy. אתה צריך להעביר את ניהול ה-DNS שלך לספק כזה ומאותו רגע, כל התעבורה אל ומהאתר שלך עוברת דרך אותו ספק ענן (אפשר כמובן להחריג בכך שבוחרים רשומות A records מסויימים שלא יעברו דרך הענן). בשיטה זו יש יתרון גדול בכך שאותו ספק CDN יכול לאפשר לך דברים כמו:

  • חסימת כתובות IP מסויימים או חסימת גלישה ממדינות שונות
  • שרותי הגנה נגד התקפות שונות
  • SSL חינמי
  • שרות DNS מאובטח
  • אופטימיזציה של התכנים מבחינת תעבורה
  • טעינה זריזה של דפים
  • שמירת Cache מקומית
  • ועוד

כך שמבחינת החברה שמשתמשת בשרות כזה, כמות העבודה שצריך לעשות על מנת להשתמש בשרות CDN כזה היא קטנה וניתן תוך זמן קצר לחבר אתר, קטן כגדול, ל-CDN ולהתחיל להנות מהיתרונות.

ה-CDN של ספקי הענן הציבורי – שונה והוא יותר ה-CDN ה"קלאסי" המוכר. אתה ממשיך להשתמש בשרותי ה-DNS שלך (או בשרותי ה-DNS של ספק הענן, גם אם זה ספק ענן אחר ממה שאתם משתמשים לארח את התשתית האחרת שלכם) ואתה צריך לפתוח A record נוסף שישמש לשרותי ה-CDN וכמו כן עליך לבצע שינויים באתרים שלך על מנת שתוכלו להשתמש בשרותי ה-CDN (במקרה של אמזון יש ספר שנגיש דרך אפליקציית Kindle במחיר של 0$ כאן איך להשתמש בשרותי ה-CDN שלהם).

יש מספר יתרונות של ה-CDN של ספקי ענן כמו אמזון מול שרותי CDN כמו Cloudflare:

  • אין צורך בשרתים ובאחסון להנגיש תכנים סטטיים. פשוט מאחסנים אותם ב-Object Storage כמו S3 ומגדירים את ה-CDN להנגיש אותם לפי הצורך.
  • ניתן להנגיש דרך ה-CDN תכנים מוגנים כמו וידאו, מוסיקה, וקבצים מיוחדים שמיועדים ללקוחות משלמים בין כהורדה ובין כהזרמה (Stream).
  • ניתן לקבל Raw Access Log (ב-Cloudflare זה בתשלום, ב-Cloudfront זה ללא תשלום נוסף) שניתן להכניס למערכת עיבוד לוגים (Elastic Stack וכו')
  • ניתן להשתמש ב-Wildcard SSL
  • ניתן "לדחוף" תכנים

(מצאתי כאן טבלה שמשווה בין Cloudflare ו-Cloudfront אך היא אינה מעודכנת לגמרי).

אחת הנקודות החשובות ביותר קשורה למחיר: ספק כמו Cloudflare לא גובה אפילו סנט אחד על תעבורה, בין אם תעביר בחודש 10 ג'יגהבייט או 10 טרהבייט, אולם אתה תצטרך לשלם על פונקציות נוספות. אצל ספקי ענן ציבורי תוכל לקבל עד 50 ג'יגהבייט תעבורה החוצה בחינם ולאחר מכן תצטרך לשלם על השרות.

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

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

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

נקודות למחשבה לגבי מעבר לענן (2019)

כמדי תקופה, אני כותב פוסט כמו זה לגבי כמה נקודות למחשבה לגבי העברת התשתית של חברות (כולה או חלקה) לענן ציבורי. אדגיש: אני מדבר על עננים ציבוריים בלבד (אמזון, גוגל, מיקרוסופט) ולא על כל מיני "עננים" שהוקמו פה בארץ על ידי ספקי תקשורת מקומיים (צר לי, אני מתייחס ל"עננים" כאלו כבדיחה, וכ-לא יותר מאשר Fancy Hosting).

לכל מי שיש שרתים כמו R720 או R730 של Dell לדוגמא, האחריות תפוג בקרוב (את ה-R730 ניתן להאריך כמובן), ומכיוון שרבים מעוניינים לעבוד עם שרתים שנמצאים תחת אחריות מלאה, יש לא מעט פניות ותהיות אם לרכוש שרתים חדשים או פשוט להעביר את הדברים לענן.

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

השאלה הראשונה שלי תהיה: מה אתם בעצם רוצים לעשות? האם אתם מחפשים להעביר את השרתים הוירטואליים (VM) כמו שזה מכאן לענן? או שאתם רוצים גם להשתמש בשירותים שספק הענן נותן? לדוגמא: אם בחברה של ירון יש 50 מכונות וירטואליות, האם ירון בעצם רוצה להעביר את כל ה-50 לספק ענן ולהשתמש במערכת כאילו היא יושבת בחדר שרתים שלו, או שהוא רוצה להעביר חלק וחלק אחר להמיר בשירותים של אותו ספק ענן?

נניח וירון בוחר את השיטה להחליף "ברזלים" – נניח R710/R720 ב-R740 – העלות שלו תהיה Fixed ומשולמת מראש. נניח לשם הדוגמא ש-R740 עולה 10,000$ ויש לו 3 שרתים ישנים והוא מעוניין להחליף את כולם, אז העלות תהיה בעצם 30,000$. במחיר הזה ירון מקבל את האפשרות להביר מכונות VM לתשתית החדשה תוך שימוש ברשיונות קיימים (בדרך כלל, קיימות גם חריגות) והוא יכול בהמשך להוסיף עוד מכונות VM ללא עלות נוספת (שוב, למעט מקרים של רשיונות ל-OS וכו').

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

אז בואו נחשב מחיר: יש לנו 50 מכונות VM שפרוסים על 3 שרתים והם יתנו שרות לפחות ל-3 שנים הקרובות. מחיר פר VM יצא 600$. אפשר כמובן לקצץ ולרדת ל-2 שרתים עם מעבדים חזקים מרובי ליבות וכמות זכרון משמעותית (נניח 256 ג'יגה פר שרת פיזי). חושבים שזה יעזור? מהרגע שעוברים ממעבדים כמו Xeon SP Silver למשהו יותר רציני – המחיר יטפס בכמה אלפי דולרים, כך שלא בטוח שאם נרד בכמות השרתים (אך נשדרג במעמד ההזמנה את אלו שאנחנו רוצים לרכוש במפרט יותר "כבד") זה יעזור. אנחנו יכולים לרדת במחיר VM מ-600$ נניח ל-500$ ואפילו $400. המחיר ירד יותר אם אותן מכונות VM יעבדו יותר שנים, כמו לדוגמא 5 שנים – אז אנחנו יכולים לרדת ל-$133 פר VM.

נניח עתה שירון רוצה להסתכל על הפתרונות בענן. שיהיה מה להשוות.

אז בואו נאמר שב-AWS ניקח מכונה צנועה, 2 ליבות, 8 ג'יגה זכרון, תעבורת תקשורת נמוכה ו-80 ג'יגה דיסק (EBS). המחיר לחודש – 80$. את המחיר הזה ניתן "לחתוך" אם ירון מוכן לשלם לשנה מראש או 3 שנים מראש על אותו VM. אם זה לשנה, הוא יצטרך לשלם $1740 ואם זה ל-3 שנים, אז הוא יצטרך לשלם $1159 (כלומר אפקטיבית הוא כביכול ישלם 32.20$ לחודש) – אז בתכל'ס ניתן להגיע למחירים טובים פר VM (זה קיים אצל כל ספקי הענן הגדולים, אגב). יש,אגב, מסלולים שונים, תלוי בספק הענן.

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

  • רוצים קו יעודי (MPLS) של 100 מגה נניח מחברתכם אל אמזון? זה יעלה כמה אלפי דולרים, לאמזון ולספק התשתיות שלכם.
  • לא רוצים פתרון MPLS אלא VPN? אין בעיה. התשלום יהיה על ה-Instance שיריץ את פתרון ה-VPN ועל התעבורה היוצאת מאמזון אליכם (משלמים על הכיוון מאמזון החוצה, לא להיפך)
  • יציאה לאינטרנט – אתם משלמים על כל ביט שיוצא החוצה לאינטרנט מהתשתית שלכם בענן, ותלוי גם לאן התקשורת יוצאת – כל אזור והמחיר שלו (המחיר הולך פר ג'יגהבייט)
  • רוצים לגבות את התכנים? רעיון מעולה! כל ספקי הענן מציעים שרותי אחסון שונים (כמו S3 ועוד) ויש עלויות של כמה סנטים פר ג'יגהבייט (תלוי בענן, ובסוג שרידות שאתם מחפשים עבור הגיבוי).
  • כתובות IP אמיתיות – כל כתובת עולה כסף ואם ביקשתם הקצאת כתובות ולא השתמשתם – המחיר פר IP קופץ פי 3-4 (המחיר הוא בדרך כלל ל-IP אמיתי בשימוש בסביבות 1-2$ לחודש)
  • החלטתם להשתמש בשירותים שונים כדי לחסוך הקמה ותחזוקה של שרות דומה? יש מחירים Pay as you go ויש מקרים שאפשר לשלם מראש ולחסוך. ככל שיש יותר שימוש, המחיר עולה.

(עכשיו אתם מבינים מדוע אני מתייחס לעננים המקומיים שמציעות חברות תקשורת מקומיות שונות שמריצות תשתית של VMWare או Hyper-V כבדיחה?)

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

  • ב-On Prem אתה משלם על הציוד פעם אחת ואם אתה רוצה להוסיף נניח עוד מכונות VM, העלות תהיה אפסית (למעט במקרים שצריך שדרוג ציוד).
  • ב-On Prem כשיש תקלה, אפשר לטפל בה מקומית 24X7 ולא תלוים בספק הענן (אם משתמשים בשרותים של ספק הענן לדוגמא) עד שיתקנו את התקלה.
  • בענן אפשר תוך דקות ספורות להתחבר לשרותים שונים שחוסכים הקמת שרתים/הגדרות/תחזוקה ואפשר להשתמש ישירות בשירות. כך לדוגמא, במקום להחזיק Cluster של SQL, אפשר להשתמש בשרותי RDS.
  • בענן מחירי ה-VM יותר זולים – אם מוכנים לשלם מראש.
  • בענן אתה תמיד רץ על תשתית חזקה ואף אחד לא מכניס את ה-Instances שלך למכונות שכבר עמוסות. במקרים רבים ה-Instances רצים על מעבדים יחודיים חזקים שלא זמינים לשוק הרחב.
  • שרותי תמיכה בענן ישירות מספק הענן – אינם זולים.
  • נקודה חשובה: ב-On Prem אין לך הפתעות במחיר או בחשבונית חודשית.
  • כשזה מגיע לתשלום – בענן אין "שוטף/שוטף פלוס". התשלום הוא בתחילת החודש הבא.

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

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

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

קונטיינרים וגדילה, צרכים מול מציאות

עבדכם הנאמן ממשיך בביקורים בחברות גדולות במשק הישראלי בנסיון להסביר יותר לגבי קונטיינרים, מערכות אורקסטרציה לקונטיינרים (מה שמבוסס Kubernetes), תמיכה ב-CI/CD וכו', אך אחד הדברים שקשה להעביר להנהלות השונות, הוא עניין ה-Scaling הרוחבי, שהוא אחד ההבדלים המהותיים בין עבודה עם מכונות VM ו-Scale קבוע, לבין קונטיינרים עם Scale דינמי.

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

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

אם היינו לוקחים אתר מסחרי ו"ממירים" אותו לעבודה כקונטיינרים על ענן ציבורי כלשהו, רוב התקלות היו נמנעות, כי מערכת כמו Kubernetes/OpenShift יודעות לבצע Scaling אוטומטית אם פשוט מגדירים זאת, בין אם מדובר בגדילה או בהקטנה, בהתאם לעומסים. אתם עובדים עם אמזון וצריכים עכשיו להרים 500 קונטיינרים וכבר הגדרתם את הכל באותו ענן? תוך דקות ספורות הכל יהיה למעלה ואם תצטרכו יותר קונטיינרים עקב עומסים, יקח למערכת שניות ספורות להוסיף קונטיינרים, וזה אחד ההבדלים הגדולים בין קונטיינרים ל-VM (או EC2 Instance): ל-VM לוקח מספר דקות כדי להיווצר ולהיות מוגדר לעבודה יחד עם השאר. גרוע מכך: אם המערכת רצה On Premise, אז בעצם צריך לנחש כמה מכונות להקים ומערכות וירטואליה אינן טובות בהוספה אוטומטית של מכונות VM (וכמובן – בענן ציבורי יש הרבה יותר משאבים ממה שיש On Premise או בכל ספק Hosting מקומי).

קונטיינרים הם דברים חד פעמיים, שנהרסים בתום עבודה (או כשהם קורסים עקב שגיאה/באג), וכשמתחילים להשתמש בכלי CI/CD עם קונטיינרים, כמות הקונטיינרים שתרוץ במקביל מתחילה לטפס במהירות. אם לדוגמא נשתמש בכלי כמו Jenkins עם תמיכה בקונטיינרים ונגדיר את Jenkins לעקוב אחרי כל מיני Repositories של קוד שמפתחים כותבים, ברגע שמבצעים Commit, מערכת Jenkins תקים קונטיינר ותבנה בתוכו את הקוד. נניח שיש לנו מספר Repositories ומספר עבודות ב-Jenkins שזה מה שהן עושות, נראה שהמערכת מהר מאוד תקים מספר קונטיינרים, ואם נגדיר את המערכת להריץ טסטים על קונטיינרים שנבנו מ-Build אחרון, נקבל מספר כפול ותוך זמן קצר כולם יכולים לראות שמשאבים מנוצלים במהירות, הן מבחינת Compute וכמובן מבחינת אחסון (תסתכלו על הגרפים של ה-VM שמריצים את ה-Kubernetes/OpenShift). היתרון הגדול כמובן בקונטיינרים, זה שהכל נבנה מאפס, ואין יותר "אצלי זה עובד אז אם לך לא עובד, זו בעיה שלך".

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

אבל הבעיה מתחילה שצריכים להריץ קונטיינרים ומערכת כמו OpenShift/Kubernetes – כדי לשרת את הקהל בחוץ. כמות הגולשים היא דינמית, והמערכת צריכה להיות בנויה בצורה שונה בהשוואה לעבודה מול מערכות VM או EC2 Instances. דוגמא פשוטה: אם אנחנו רוצים לכתוב תכנים החוצה מהקונטיינר (שוב, קונטיינר הוא דבר חד פעמי וכשהוא נהרס, המערכת מוחקת הכל אלא אם הקונטיינר נבנה עם הגדרות של כתיבה חיצונית בדרכים מסויימות), זה שלאותו VM יהיה גם 10 טרהבייט דיסק קשיח וירטואלי לא יעזור במאומה כי שיטת אחסון הנתונים היא שונה, יהיה צורך במקרים רבים וכשיש כמות גדולה של כתיבה ודרישה לשרידות רצינית – להשתמש ב-Object Storage שמבוצע ב-Scale Out שאינו בנוי על VM שמאוחסן על איזה Datastore ב-vSphere, וכאן כבר יש צורך או בסטורג' Scale Out קנייני שיודע לתמוך ב-Object Storage או להקים מערכת שתרוץ כ-VM על הברזלים וגם הקונטיינרים ירוצו על הברזלים עצמם ללא וירטואליזציה (למעט קונטיינרים מסויימים שאיננו סומכים עליהם ונוכל להריץ אותם עם וירטואליזציה קטנה כמו עם Kata Containers) ומעל זה יכול להיות שנצטרך להריץ איזה Load Balancer כלשהו (אם כי מערכות Kubernetes/OpenShift נותנות פתרון Load Balancing אבל לא בטוח שחברות ירצו להשתמש בו לצרכים של אתרים חשופים). פתרונות כאלו לא יתנו לנו גמישות מקסימלית כמו שרות הרצת קונטיינרים שספקי הענן מציעים (בגלל שלהם יש הרבה יותר משאבים).

אם יש משהו שלא קל לשכנע חברות גדולות לעשות, זה לרכוש סטורג' חדש (שתומך טבעית ב-Object Storage) או לרכוש תוכנה כמו Ceph שתתן זאת ושתותקן על הברזלים, ולהתחיל להריץ קונטיינרים על ברזלים כדי לקבל מקסימום ביצועים וגולשים. לכך, יש 4 פתרונות:

  • ענן פרטי עם OpenStack: הפתרון הזה יכול לתת לנו את הכל ביחד. אנחנו יכולים להשתמש בסטורג' קנייני כלשהו ולחבר אותו ל-OpenStack כדי לקבל שרותים כמו Object Storage, Block Storage וכו' או שאנחנו יכולים להקים VM בכל שרת ולהריץ עליו Ceph.
  • עבודה במצב Hybrid: יש לנו מקומית מערכת OpenShift או Kubernetes פנימית שעליה אנחנו מבצעים פיתוח וכו', ואת האתרים הציבוריים אנחנו נשתמש בשרותי הקונטיינרים שספק הענן שבחרנו מציע. אם לדוגמא החברה משתמשת ב-Azure, אז הם יכולים להשתמש בשרות AKS. באמזון יש את אותו שרות (בערך) שנקרא EKS (או Fargate ששם אמזון מנהלת את ה-Kubernetes ואתה מריץ את הקונטיינרים) ובענן של גוגל יש את GKE. ה-Hybrid מומלץ לחברות שהרגולטור אוסר עליהן להוציא הכל החוצה.
  • עבודה "באותו ענן" – במקומות בהן בחרו לעבוד לדוגמא עם Azure, ניתן לרכוש מיצרן השרתים המועדף עליכם את Azure Stack – זהו פתרון שרץ על הברזלים אצלכם מקומית עם חיבור ל-Azure, כך שאפשר להשתמש באותם שרותים, מקומית או בענן בחוץ. עם עננים אחרים, אתם משתמשים בשרותי ה-Kubernetes של ספק הענן כך שהשינויים להריץ דברים מקומית או בענן הם די מינוריים וניתן להפריד את ההגדרות לקבצים שונים. בהמשך השנה, גם אמזון וגם גוגל יציעו לכם ברזלים ותוכנה להריץ את השרותים שאתם מריצים בענן – מקומית ובענן, כמו ה-Azure Stack.
  • שימוש ב-OpenShift – מערכת OpenShift קיימת לשימוש מקומי בשרתים שלכם או ב-OpenShift בענן שקיים אצל כל ספקיות הענן.

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

אם יש לכם שאלות, אתם מוזמנים לפנות אליי.

מעבר לענן – תכנונים, עדיפויות ומציאות

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

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

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

ניקח לדוגמא תשתית פשוטה: יש לנו 2 מכונות, אחת מריצה MySQL והשניה מריצה שרת Web NGINX ושרת שלישי שמריץ אפליקציות על Tomcat. התשתית הזו נגישה החוצה לציבור שמבצע אותנטיקציה עם שם משתמש/סיסמא והתשתית יושבת מאחורי Firewall (ואולי מערכות הגנה נוספות).

אם נסתכל על התשתית הזו בתצורה המקומית, סביר להניח שהמכונה שמריצה את ה-NGINX תהיה חשופה (מבחינת כתובת IP) לאינטרנט עם פורט 80 או 443 פתוח החוצה ב-Firewall עם כתובת IP אמיתית או שתהיה כתובת חיצונית ב-Firewall שתמופה אל כתובת IP פנימית. יהיו כאלו שיטמיעו את מכונת ה-NGINX ב-DMZ עם 2 רגליים – אחת ב-DMZ ואחת ב-LAN, כך שה-NGINX יוכל לדבר עם ה-Tomcat ברשת הפנימית (מכונת ה-Tomcat ומכונת ה-MySQL לא יהיו זמינות מבחוץ כלל).

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

  • אנחנו נצטרך להקים VPC שיכלול:
    • חלוקה ל-Subnets ששם ישבו מכונות בהתאם לקטגוריות שאנחנו בונים: Prod, testing, stage, devel וכו'. רובם לא יקבלו כלל כתובות IP אמיתיות.
    • Internet Gateway שיתן ל-Subnet שנבחר גישת אינטרנט החוצה
    • Elastic IP – שיהיה מחובר ספציפית למכונת ה-NGINX
    • NAT Gateway – שיאפשר למכונות הפנימיות לגשת לאינטרנט מבפנים החוצה (אך לא ההיפך)
    • Network ACL – שישמש כ-Stateless Firewall על מנת להחליט מי יכול לצאת ודרך איזה פורטים
    • Security Groups (שהולכים עם Network ACL) – שם נגדיר ספציפית מאלו כתובות ואלו פורטים יוכלו להיכנס לשרת(ים).
    • ויש עוד כמה צעדים, וחברות רבות גם יוסיפו כאן אולי Appliance Firewall מסחרי בנוסף למה שאמזון נותנת ועוד ועוד…

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

לאחר מכן אנחנו נקים מכונות ב-EC2. נצטרך לבחור Template של מכונה מהקטלוג, בחירת ה-VPC, וכמובן – גודל Storage מקומי למכונה. כאן הדברים שונים מהסטורג' שנמצא אצל חברות – ב-AWS תוכל לבחור בין General Purpose SSD לבין Provisioned IOPS SSD שהוא הרבה יותר מהיר והאפשרות השלישית היא דיסקים מגנטיים (מבלי אפשרות לבחור IOPS). ההבדל (חוץ מביצועים) בין ה-General ל-Provisioned מתבטא לא רק בביצועים אלא גם במחיר (ב-Provisioned הוא הרבה יותר גבוה) וראיתי מספר מקרים שבחרו ב-Provisioned והתפלאו מדוע המחיר טס בכמה מאות דולרים פר מכונה. לאחר הגדרות הסטורג' נצטרך לבחור תגים (Tags) אם נרצה, את ה-Security Groups (אם לא הגדרנו קודם), מפתח PEM להתחברות ולבסוף נאשר את הכל ו-AWS יקים לנו את המכונה. לאחר מספר דקות נוכל להתחבר אליה אם הגדרנו שהיא תקבל כתובת IP אמיתית דינמית או ללא כתובת IP דינמית דרך מכונת Bastian או דרך חיבור Direct שיש לנו אל ה-VPC. משם נגדיר פנימית את המכונה, נקים עוד כמה מכונות וכו' וכו'.

בקיצור – העברת תשתית ממקומית לענן היא לא בדיוק מספר קליקים בעכבר (אני לא מדבר על שימוש בפתרונות כמו VMWare on AWS), ויש כל מיני Gotcha בדרך, ויכול להיות שגם הביצועים לא יהיו כה-מרשימים אם דברים לא הוגדרו נכון (אמזון לא דוחפים מכונות VM לשרתי ברזל כמו סרדינים, כמו כל מיני ספקי Hosting), כך שלפחות בפעמים הראשונות – מיגרציה תיקח יותר זמן ולכן חשוב לקחת זאת בחשבון (כמובן שאם מישהו חיצוני מקצועי עושה זאת יקח פחות זמן אך עדיין יהיו דברים שלא היו צפויים מראש שהחברה תרצה וגם זה לוקח זמן). בהמשך, סביר להניח, יוכנסו כלים שונים כדי לבצע אוטומציה של הדברים, בדיקת מהירויות, ניטור דרך הענן ועוד.

אחד הדברים שיותר ויותר חברות מעוניינות בו, הוא פתרון ה-Hybrid, וכאן הדברים קצת מסתבכים..

כפי שציינתי לעיל, יש פתרון כמו VMWare on AWS שמאפשר לך "להרחיב" את המערכת המקומית שלכם לענן אך ממשיך להשתמש במושגים ובטכנולוגיות של VMWare. אם ניקח לדוגמא את 3 המכונות מהדוגמא הקודמת, נוכל בקלות לבצע עבורם Migrate לתשתית ה-VMWare on AWS בענן וכל מה שנצטרך לשנות לפני המעבר זה החיבור ל-vSwitch/DVSwitch, לבחור לאן לאחסן את המכונות ועוד מספר פרמטרים – והמערכת תבצע את השאר בצורה עצמאית.

חברות רבות לעומת זאת מחפשות משהו יותר "מעונן" – הן מחפשות דברים כמו שרצים בענן, אך שירוצו מקומית עם אפשרות שימוש ב-Hybrid להעברת עומסים, מבלי להיות תלוים בפתרון של VMware (או שהם כלל לא משתמשים ב-VMware). מיקרוסופט לדוגמא מציעה את Azure Stack – מדובר בערימה של שרתים שמריצים תוכנות, סקריפטים ודברים נוספים על המכונות הללו והתשתית הזו יושבת ב-DC המקומי של הלקוח והוא מקבל גירסה מזערית של Azure מקומית עם אפשרות להתרחב ל-Azure הגלובאלי ובכך לעבוד או מקומית בלבד תוך שימוש בכלים הרגילים על Azure (מתאים לגופים בטחוניים לדוגמא) או שימוש כ-Hybrid כמקומי והעברה פנימה והחוצה לענן הציבורי. גם אמזון הכריזה על פתרון דומה שנקרא AWS Outposts וגוגל גם בונים פתרון כזה (אם כי עדיין לא ראיתי שום הכרזה קונקרטית על משהו מצד גוגל).

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

אלו שרוצים משהו פחות מחייב ויותר מדבר על פתרון Hybrid שמתייחס לקונטיינרים ומכונות VM יכול להשתמש כמובן ב-Open Stack והוידאו הבא מסביר בהרחבה איך ניתן לחבר OpenStack מקומי לעננים הציבוריים השונים.

לסיכום: בין אם מתחילים להעביר תשתית ממקומית לענן ובין אם חושבים לעבור מתשתית מקומית בלבד/ענן בלבד ל-Hybrid – מומלץ להתאזר בסבלנות ולחקור את הפתרונות. תחום ה-Hybrid מקבל המון "באזז" לאחרונה וחלק מהפתרונות לא שווים אפילו PoC, אז לפני שקופצים למים – קראו על הנושא, קחו יעוץ ותראו מה הפתרונ/ות ששווים עבורכם.

על עננים ציבוריים ותקציבים

בשנים האחרונות חברות רבות עברו להשתמש בשרותי ענן ציבוריים, החל בשרותים של מיקרוסופט שהחליפו שרתי Exchange מקומיים (אופיס 365), העברת מכונות VM לענן, שימוש היברידי בתשתית מקומית ובעננים ציבוריים וכלה בשימוש בשרתים כפלטפורמות ושירותים (PAAS/SAAS). גם הבנקים, אחד הסקטורים הכי שמרניים שהשתמש בשרותי ענן יותר לצרכים שיווקיים – קיבל אישור מהרגולטור להשתמש ביותר שרותי ומשאבי ענן ציבורי.

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

יש לעומת זאת לא מעט חברות שאינן זכאיות לקרדיטים באלפי/עשרות אלפי דולרים ויש כמובן את המצב שהקרדיטים נגמרו ויש צורך לשלם. במצבים כאלו, ספק הענן מוציא חשבונית חודשית שנגבית מיידית מכרטיס האשראי של החברה (מתגעגעים ל-ש+60?) והחשבונית עוברת למנמ"ר/מנהל צוות ה-IT. אצל לא מעט חברות, כמעט כל חשבונית כזו גורמת לכינוס ישיבה של צוות IT (ושאר גורמים) עם שלל ביקורות ופקודות: מדוע הרמתם שרות X שעולה הרבה? מדוע הורם שרות בלי לקבל אישור, וכמובן הוראות להעיף דברים החוצה ולחסוך. לגטימי לחלוטין.

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

כאן קיים איזה ניתוק בחלק מהחברות בין ההנהלה הבכירה לצוותי IT/פיתוח, והניתוק נובע מהרגל לשימוש ב-On Prem. אסביר:

נניח ואני חברה בשם X ויש לי חדר שרתים נחמד עם 5 ארונות, ו-100 שרתים פיזיים, תקשורת, סטורג', מיזוג וכו'. השרתים מריצים כ-1500 מכונות VM. נניח ועכשיו יש צורך להוסיף עוד 500 מכונות VM ויש לי משאבים פנויים בשרתים ובסטורג', אז תוספת העלות לחברה תהיה יחסית זניחה (אני לא מדבר כרגע על רשיונות פר OS כמו ב-Windows): עלות החשמל תהיה קצת יותר גבוהה. אם אצטרך לרכוש ברזלים כדי להקים את אותן מכונות VM, אז העלות שלהם תהיה עלות חד פעמית ואני יכול להשתמש בציוד הזה במשך 3-5 שנים בלי בעיה, אך בשורה התחתונה – ההוצאות הכספיות לגבי תוספת אותן מכונות VM הן צפויות.

בעננים ציבוריים לעומת זאת, חוץ מהתקשורת מבחוץ פנימה ותקשורת פנימית ברוב התשתית הוירטואלית שלך – הכל עולה כסף, החל מהביט הראשון שיוצא ממכונה וירטואלית או מאחסון S3 לדוגמא, כך שבניגוד ל-On prem שלא היית צריך לשלם עוד כסף על כל VM כל חודש – פה אתה חייב לשלם והתשלום מיידי.

ההבדל בין On Prem לשימוש בענן בלא מעט מקרים גורם לכך שחברות, לאחר ישיבות תקציביות שנתיות – מתחילות להתעניין באחת מ-3 האפשרויות הבאות:

  • "לחזור הביתה" – לתשתיות On prem
  • להתחיל לשוחח עם נציגי ענן מתחרה על שרותים זהים כמו שמשתמשים עכשיו אך במחיר יותר נמוך
  • קיצוץ מאסיבי בשימוש שרותי הענן, ואם משתמשים ב-Hybrid (כלומר On Prem ועננים) – לקצץ את השימוש בענן לצרכים הכרחיים בלבד.

החלטתי לשאול חברים מקצועיים בפורום Operation Israel בפייסבוק את דעתם. מי שמעוניין לקרוא, להלן הלינק (לצערי לא ניתן לעשות Embed לפוסט ספציפי מקבוצה אל וורדפרס)

מי שהסתכל בלינק יכל לראות שישנן תשובות שונות. אני אפרסם כאן את התשובות שלי:

  • בנוגע למעבר ל-On Prem ("חזרה הביתה") – אם מדובר על מכונות VM, אז זה אפשרי כמובן, אם כי סביר להניח שתקבלו אולי ירידה כלשהי בביצועים הואיל וספקי הענן בד"כ משתמשים במעבדים מהדור האחרון או זה שלפניו, בהשוואה ל-2-3 דורות אחורה שחברות משתמשות. בנוסף, תלוי בסיטואציה, יכול להיות שתצטרכו לרכוש ציוד נוסף כדי לארח את המכונות שמוחזרות מהענן.
    לעומת זאת – אם אתם משתמשים בשרותים שספקית הענן מציעה (RDS, S3, ELB ועוד שרותים רבים) – חלק מהם ניתן להקים מקומית בקלות (אם כי לא באותה שרידות – לדוגמא במקרה של S3) וחלקם מצריך משאבים ניכרים בכדי להקים משהו זהה רק ב-Scale קטן בהרבה (כמו Aurora), כך שבכל מקרה מדובר על הקצאת משאבים ניכרים שהולכים וגודלים ככל שהעברתם/הקמתם תשתיות וירטואליות בענן או שאתם משתמשים בשרותים המוצעים ע"י ספק הענן.
  • מעבר לענן מתחרה: "על הנייר" זה נשמע קל – מביאים את נציגי המתחרים, מבקשים מחיר נמוך וקרדיטים ואפשר לסגור חוזה. הבעיה בדרך כלל היא במימוש: אם אתם בנק ואתם משלמים מאות אלפי דולרים ומעלה פר חודש לספק הענן הנוכחי, אז ספק הענן המתחרה יקח על עצמו את כל ההקמה והעברת המכונות והנתונים אליו. אם אתם יותר קטנים – הספק המתחרה ישמח לתת לכם שרותי יעוץ (תרגום: אתם עושים את העבודה השחורה, הספק רק מייעץ תיאורתית ושולח לכם לינקים לתיעוד).
    משהו שחשוב לזכור: אין הבדלים רציניים במחירים בין ספקי הענן. הוא יכול נניח לתת לכם מחיר יותר זול על הקמת VM, אבל הוא יקח יותר על ה"דיסק" הוירטואלי, על רשתות תקשורת וירטואליות או על דברים אחרים, כך שלדעתי הסיבות היחידות לעזוב ספק ענן זה שרות גרוע, בעיות Downtime או שאין שרותים שאתם צריכים.
  • קיצוץ בשימוש שירותי הענן: אני יכול להבין בהחלט את אלו שרוצים את האופציה הזו, אבל חשוב לזכור (וזה רלוונטי אצל רוב ספקי הענן!) – אפשר להוציא לדוגמא 1000$ לחודש על פרויקט שרץ על הענן ואפשר במקרים רבים לעשות את זה אצל אותו ספק ענן ב-500$. הכל תלוי בידע של אותו אדם לגבי השרותים המוצעים על ידי אותו ספק ענן.
    סתם דוגמא מציאותית: התשתית שמציגה את הבלוג הזה (ובלוגים אחרים שלי ועוד כמה אפליקציות וניסויים שאני מריץ) לפני כשנה עלתה בסביבות ה-85$ לחודש. כיום אני משלם בחודש 26$. איך? צריך לדעת לבחור את השרותים, לראות מה השרותים החדשים שמוצעים, היכן ספק הענן הוריד מחירים, איך ניתן לבזר את הדברים, היכן כדאי לשלם מראש על משאבים מסויימים לתקופה ארוכה ולחסוך הרבה כסף, היכן ניתן להשתמש במשאבים זמניים כדי להריץ דברים שלא לוקחים זמן רב וזולים בהרבה ועוד ועוד. יש מספר חברות (כולל הח"מ) שמציעים שרות כזה, כך שלפני שמניפים את הגרזן – כדאי להתייעץ.

לסיכום: בלא מעט חברות שיש להם תשתיות בענן ציבורי מגיעים לפעמים סיטואציות שההנהלה דורשת חיתוך רציני בתקציב התשלומים לספק הענן. לא צריך להיכנס לפאניקה, תמיד אפשר למצוא פתרונות איך לקבל ביצועים נאותים תוך ביצוע שינויים שחוסכים מחיר ללא צורך ירידה לשימוש במשאבים בלתי מספקים (תמיד אזכור את אותו עסק שפנה אליי אחרי שקיבל חשבונית היסטרית על שרת SQL שהריץ באמזון ושבקושי נותן שרותים למישהו, אבל האינטגרטור הקודם החליט שזה רעיון מעולה להגדיר שה-SQL ירוץ על m5.4xlarge [כלומר 16 ליבות, 64 ג'יגהבייט זכרון!]).

תודה למשתתפי פורום Operation Israel על תשובותיהם.

כמה מילים על VMWare on AWS

(תודה לניצן וייסברג שהעיר את תשומת ליבי לגבי השרות החדש)

בכנס Re:Invent האחרון של אמזון, חברת VMWare הכריזה על שרות חדש בשיתוף אמזון שנקרא VMWare on AWS – שרות שנותן לך להרים SDDC (כלומר Software Defined Data Center). עם שרות זה, הלקוח מקבל מינימום 4 שרתים פיזיים שמותקנים עליהם ESXI יחד עם VSAN ו-NSX וכמובן כל השרותים של vSphere שמגיעים ברשיון Enterprise Plus. הלכתי לקרוא בכמה מקומות על השרות ולהלן התרשמותי:

מבחינת המכונות – אין מה לאמר, מפלצות אחת אחת. בכל מכונה תקבל 36 ליבות (מהמעבדים האחרונים – Xeon-SP של אינטל), 512 ג'יגהבייט זכרון, ו-8 דיסקים SSD NVME (כל אחד בגודל של 2 טרה, כאשר 2 מתוכם משמשים כ-Cache, כך שמבחינת Storage בחישוב כולל, יש לך בערך 20 טרהבייט, לפי הדף באתר של אמזון) והרשת היא ברוחב פס רציני של 25 ג'יגהביט. אין מה לאמר – הלוואי על כולנו!

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

איך נאמר בפרסומת: סבבה אגוזים!

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

הכל טוב ויפה, עד שמגיעים … למחיר, וכפי שאתם יכולים להסתכל על מפרט הברזלים לעיל – זול זה לא הולך להיות!

המחיר מתחיל ב-8.3681 דולר לשעה פר ברזל ומכיוון שצריך מינימום 4 ברזלים (אי אפשר פחות), אז אנחנו מדברים על 33.47 דולר לשעה. נכפיל ב-720 שעות לחודש ונגיע ל-24,100 דולר לחודש, או 289,201 דולר לשנה. המחיר כמובן לא נגמר פה, על כך יש להוסיף מחיר תעבורה מהתשתית של אמזון החוצה (רוצים להתחבר ב-Remote? להוריד VM לארץ? להוריד DATA לארץ? סינכרוניזציה או רפליקציה בין VMים משם לכאן? אז תוסיפו בבקשה, 5 סנט פר ג'יגהבייט) וכרגע אם אתם רוצים Latency נמוך, אתם יכולים לשכוח מזה – בשלב זה השרות זמין בצפון אמריקה בלבד (אלא אם יש לכם קו יעודי לארה"ב, שזה סיפור אחר כמובן).

רוצים הנחה? בשמחה! תתחייבו לשנה מראש, ותשלמו פר הוסט סכום של 51,987 דולר, נכפיל ב-4 וכך נרד למחיר "מציאה" של 208,000 דולר לערך או 437,464 דולר בהתחייבות ל-3 שנים. אין שוטף+30 או 60, זה תשלום מיידי ואין אפשרות לצאת מהמחויבות באמצע התקופה.

אבל בואו נעזוב את המחיר. יש לא מעט חברות גדולות מאוד ששרפו מיליוני דולרים באגפי המחשוב בצעדים תמוהים (אל תאמינו לי, תראו מה קרה עם 600 מיליון שקל וביטוח לאומי) שבשבילם Money is not a object ואין להם בעיה להוציא מאות אלפי דולרים בשנה – האם להם זה שווה?

מבחינה טכנית גרידא, התשובה היא לא רבתי, מהסיבות הבאות:

  • השרידות היא אשלייתית. באמזון לדוגמא, אם תשתמש בשרות Aurura להקים שרות MySQL, אתה מגדיר שם Availability Zone, כלומר השרות שיוקם עבורך מבוזר על פני שרתים שנמצאים ב-Zones שונים שנמצאים באותו Region, כך שאם Zone נופל (הנה דוגמא) אז Zone אחר תופס פיקוד ואתה אפילו לא מרגיש נפילה. עם השרות החדש הזה – כל השרתים שלך נמצאים באותו Zone, ואם ה-Zone נופל, הכל נופל בתשתית המרוחקת. מעבר לכך, לא ניתן לפרוס את ה-Hosts על פני Regions שונים של אמזון (אם כי ניתן להקים SDDC שונים ב-Regions שונים, אך כרגע רק בצפון אמריקה).
  • גדילה של Storage היא בעייתית בהשוואה למחיר. זה שתוסיף עוד Host לא תקבל עוד 20 טרה אחסון, אלא סביר להניח שתקבל בערך 5 טרהבייט נטו (הסיבה לכך שעם VSAN, ה-DATA של מכונות ה-VM או DATA שאתה מייצא כ-iSCSI החוצה – מתרפלק בין המכונות כולן, כך שאם מכונה אחת נופלת, ה-Cluster ממשיך לעבוד כי ה-DATA נמצא. אפשר לעשות את החישובים כאן). הדבר המוזר בכל השרות הזה הוא שלא ניתן לחבר EBS מסוג io1 (או כל סוג EBS) כ-Datastore לתשתית.
  • חייבים 4 מכונות, למרות ש-VSAN יכול לעבוד גם בתצורות של 2 ו-3 מכונות פיזיות.

אבל שוב, אם יש לחברה את התקציבים, יש גם יתרונות:

  • הקמה של SDDC מלא עם מכונות מאוד חזקות בשעות ספורות במקום לבזבז מס' חודשים על בדיקת הצעות מחיר, ישיבות תקציב, הזמנות, הגעת ציוד, הגדרות והכנה לעבודה.
  • גדילה של התשתית הרחוקה תוך דקות ספורות. צריך עוד 2 ברזלים? זה יקח מס' דקות והברזלים יהיו מחוברים לתשתית ה-SDDC שלך. Host נפל? לא נורא, תוך דקות תקום מכונה אחרת ואתה יכול לגדול ל-עד 32 מכונות פיזיות (כרגע).
  • עבודה שקופה – מנהלי תשתית ה-vSphere שלך יכולים להקים מכונות פה או שם (או פה ושם) בצורה מהירה, מבלי להכיר לעומק איך לעבוד עם AWS (למעט החלק הראשוני של הקמת ה-SDDC).
  • גיבויים – הקץ ל"אין מקום לגבות". עובדים עם Veeam? מעכשיו תוכלו להשתמש באמולציית ה-VTL שלו ולגבות ל-S3 של אמזון. גם זול, גם שרידות סופר גבוהה, וזה תמיד זמין. (כעקרון אפשר לעבוד עם כל תוכנת גיבוי שיודעת לעבוד עם S3).
  • אחריות ושרות – אתה מקבל ניהול תשתית ומענה לכל בעיה ישירות מ-VMWare.
  • תשלום פר שימוש – אפשר לנסות את זה לכמה שעות או כמה ימים מבלי להתחייב על כלום ולשלם רק על השעות שניצלת.

לסיכום: אם בחברה שלכם יש תקציבים כמו מים זורמים, ואתם משתמשים בתשתית vSphere, אז בהחלט כדאי להסתכל בהצעה החדשה של אמזון/VMware. אם לעומת זאת כל שרת נרכש אצלכם בדם-ויזע, אז עדיף לוותר על השרות ומבחינה כספית – יהיה יותר זול לרכוש שרתים חזקים + רשיונות ולהכניס אותם ל-Data Center שלכם או באחת החוות של ספקי האינטרנט.

על נקודות חשובות בעת מעבר לענן

במסגרת בלוג זה כתבתי בעבר כל מיני מאמרים על מעבר לענן, כמו פוסט זה על מעבר לענן מבחינה כספית, נקודות חשובות, שאלות ותשובות, שרידות ועוד (אתם יכולים למיין מצד שמאל לפי הקטגוריות). הפעם הפוסט מיועד יותר לאחראים על צוות ה-IT או ראש צוות ה-IT ובקיצור – ברמה של יותר החלטות, פחות Hands on.

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

שרותי SAAS כחלק ממעבר לענן
SAAS (כלומר Software As A service) זה דבר מעולה, בתנאים ובדברים מסוימים. צריך לשלוח עשרות אלפי מיילים? יש כמה ספקי SAAS וסביר להניח שספק הענן שתבחר (טוב, למעט Azure לפחות ממה שידוע לי) שישמחו להציע לך שרות כזה. אם תיקח עצמאי שיקים לך דבר כזה, זה יעלה לך לא מעט, ובנוסף יש צורך לתחזק זאת ברמה שבועית או פחות (RBL, Black List ושאר צרות שמגיעים עם זה), כלומר במקרה כמו המקרה הנ"ל – השימוש ב-SAAS הרבה יותר זול מבחינת עלות ראשונית (ואולי גם בהמשך, תלוי בכל מיני פרמטרים) והוא שרות מוצדק.

לעומת זאת, אם לדוגמא אתה צריך שרות כמו MySQL או PostgreSQL בתצורה כמו Master ו-2 Slaves שיהיו מותקנים באזורים זמינים (Availability Zones במושגים של AWS), יהיה לכם יותר זול להקים זאת בעצמכם עם MariaDB (ו-Galera) לדוגמא, מכיוון שאתה יכול לבחור איזה גודל מכונה שתרצה (ולא רק מה שיש מבחינת SAAS), וגם התחזוקה עצמה אינה מסובכת. הבעיות הנפוצות ביותר שקיימות עם SQL (ולא חשוב איזה SQL) הם בד"כ השאילתות שנכתבות ע"י צוות הפיתוח וחוסר אופטימיזציה, וכאן שרותי SAAS לא יעזרו הרבה כי בסופו של יום – יותר קל וזול לתקן שאילתות מאשר להוסיף 20 שרתי רפליקציה ל-SQL.

מה שמוביל לנקודה הבאה..

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

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

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

מבחינת מעבר ענן, הדבר הכי קל להעביר זה מכונות VM. מקימים רשת וירטואלית אצל ספק הענן החדש, מייצאים את ה-VM מהספק הישן, מייבאים אצל הספק החדש ומתחילים לעבוד. מה עם שרותי ה-SAAS שהחברה משתמשת אצל ספק הענן הישן? כאן בד"כ נמצא הכאב ראש המרכזי להעביר את הדברים הללו וזה החלק שיקח הכי הרבה זמן (כדי לבצע שינויים בקוד הפנימי ובסקריפטים).

מה שמוביל לנקודה הבאה..

סקריפטים, קוד ואוטומציה
כשיש לנו תשתית פנימית שנמצאת בחדר השרתים, סביר להניח שצוות ה-IT יכתוב במהלך הזמן עשרות או מאות סקריפטים (ב-PowerShell, Bash, Python, Ruby וכו') על מנת להריץ דברים מסויימים כמו תהליכים מתוזמנים (Cron), ניקוי ומחיקת קבצים ועוד עשרות דברים שונים.

בענן הציבורי לעומת זאת, לרשותכם עשרות או מאות שרותי SAAS שונים וכל אחד מהם צריך הגדרות שונות על מנת שיפעל ויבצע מה שהשרות צריך לבצע, ובמקרים רבים הדבר שנעשה ע"י הצוות הוא כתיבת סקריפטים שיעשו את הדברים או שמכניסים את הקוד לאפליקציה שכותבים שרצה לדוגמא ב-Back end, וכאן בד"כ ישנם 2 בעיות:

  • במקרים רבים לאבטחת המידע לא ניתנת החשיבות המספיקה ובמקרים רבים הסקריפטים מכילים מפתחות של החברה, מה שעלול להוביל למצב שאם סקריפט דולף (או חמור מכך – המפתחות דלפו) – מישהו ישתמש במפתחות ליצור מכונות או שרותים שהחברה תשלם עליהם (וזה קרה בעבר לגוף גדול). בנוסף, שרותי SAAS שונים מצריכים הגדרות נוספות לשם אבטחת מידע, מה שלא תמיד מקבל מספיק יחס מבחינת הכותבים, מה שיוצר מצבים לא נעימים.
  • אחד הדברים הכי חשובים להכניס ולהטמיע בחברה הם כלי אוטומציה או כלים לעבוד עם הענן, כלים שהם ידועים במקום להמציא את הגלגל. כך לדוגמא, עבודה עם Terraform או כלי אוטומציה כמו Ansible, Puppet, Chef הם דרכים הרבה יותר טובות כדי לבצע מה שצריך, מכיוון שכלים אלו כוללים כבר תמיכה ב-API החדש של ספק הענן (בד"כ יש צורך בעדכון גירסת הכלי ושינויים קטנים בקוד שנכתב תוך שימוש בכלי על מנת לקבל את הפונקציונאליות החדשה), וכלים כאלו נותנים גם תמיכה יותר טובה בהצפנת מפתחות, קבלת פלט מסודר בהרצת הדברים ועוד. אלו דברים שהרבה יותר קשה לתחזק בקוד ללא אוטומציה שנכתב כולו בחברה.

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

מה שמוביל לנקודה הבאה…

אימוץ טכנולוגיות חדשות
הנה אחד הדברים שאני שומע: "אנחנו מעוניינים שתקים לנו את הדברים בקונטיינרים, אנחנו רוצים גם לעבוד ב-CI/CD עם Jenkins ושהכל יהיה עם Auto Scaling".

לי אישית, אין לי שום בעיה לתת את השרות הזה, בין אם בעבודה עם ECS, עם Kubernetes, עם Swarm או Kubernetes ואין לי גם בעיה לעבוד עם Jenkins. זו לא הבעיה. הבעיה בד"כ היא מה קורה עם הצוות שלך. כל הכלים שציינתי לעיל מורכבים מאוד (ועוד לא דיברנו על שרותי ה-SAAS השונים שספק הענן מציע והחברה רוצה להשתמש בהם).

לכן, בד"כ ההמלצה היא להכיר ולעבוד אחד אחד. רוצים ש-Jenkins יקים עבורכם קבצים (Build) שמגיע ממערכת GIT? קודם תכירו את זה, ואחרי שיש לצוות ידע, נמשיך לקונטיינרים, נכיר את המושגים השונים ונתחיל להעביר לאט את הדברים לשיטה החדשה. "לזרוק" על הצוות ערימת טכנולוגיות מבטיחה שדברים יזוזו לאט, עם המון באגים, ואבטחת מידע ברמה נמוכה. אלו דברים שלוקחים זמן ולעניות דעתי – שווה להשקיע את הזמן הזה. זה שאני (או עצמאי או חברה אחרת) יקים את הדברים וזה יעבוד – זה נחמד, אבל אם הצוות לא מכיר כלום, יהיו המון בעיות.

לסיכום: מעבר לענן הוא טוב, בתנאים מסויימים, אבל חשוב לשים לב לדברים שונים שלא רק יעכבו את המעבר, אלא גם לצורה ולדרך המעבר. לא עושים את הדברים תוך יום או יומיים, תמיד מומלץ שיהיה מישהו חיצוני שהצוות יוכל להתייעץ איתו ויתן לכם תמיכה (וחשוב שאותו  מישהו יכיר גם תשתית On Premise וגם ענן, הנקודה הזו קריטית כשעוברים, כמו במקרים רוצים להעביר מכונות VM עם DVSwitch לענן… סיפור מההפטרה).