יש לך גיבויים למכונות שלך בעננים?

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

כמו בענייני אבטחה, רבים נוטים לשכוח שספקי ענן לא נותנים אחריות לגבי השירותים שאתם משלמים עליהם. אם הלך לך ה-DATA – זו בעיה שלך, וזו לא דעה שלי. אם נסתכל בתנאי השרות של AWS, סעיף 4.11 קובע בפירוש את הדברים הבאים לגבי EC2 לדוגמא:

"As part of using Amazon EC2, you agree that your Amazon EC2 resources may be terminated or replaced due to failure, retirement or other AWS requirement(s). We have no liability whatsoever for any damages, liabilities, losses (including any corruption, deletion, or destruction or loss of data, applications or profits), or any other consequences resulting from the foregoing. "

במילים אחרות: מכונות יכולות להיתקע או להתקלקל וברגע שתפעיל את ה-Instance מחדש, הוא אוטומטית יופעל על מכונה תקינה, אך יחד עם זאת, הדיסק הוירטואלי שלך שרץ על EBS – זה משהו אחר. EBS יכול להתקלקל (אמזון מתחייבים על Five Niners, כלומר 99.999%) ואמזון תעשה את המאמצים לשחזר, אך אם הם לא יצליחו, הם לא יהיו אחראים ל-DATA שאיבדת.

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

אז מה ניתן לעשות? להלן מספר אפשרויות:

  • כל ספק ציבורי מאפשר ליצור Snapshot לדיסקים שנמצאים ב-Instnace. השימוש ב-Snapshot יכול להיות הן לשחזור, והן להמרה ל-Image (אם אתם רוצים ליצור Image חדש ל-Instances חדשים). יצירת ה-Snapshot נעשית "מבחוץ" (בין אם דרך ממשק ה-Web, דרך ה-SDK/CLI, או דרך כלי אוטומציה שתבחרו) ואין צורך ב-Agent כלשהו. ההוראות לבצע זאת ב-AWS נמצאות כאן.
  • Immutable מול Mutable: רוב האנשים שמגיעים מעולם הוירטואליזציה שרצה On Prem ומתחילים להשתמש בעננים ציבוריים – עובדים בשיטה שנקראת Mutable: יש לנו VM, עליו רץ כמעט הכל: האפליקציה, שרת ה-Web, אולי גם שרת SQL וכו' וברוב המקרים ה-DATA נשמר מקומית. בשיטה הזו גם המתודה לשדרג לגרסאות חדשות ולשנות דברים היא די בעייתית (במקרים רבים אפליקציות מצריכות שינויי הגדרות בין גירסה לגירסה, לדוגמא), ואם לא מדובר ב-instance יחיד אלא כמה וכמה – זה נהיה יותר מורכב, והשדרוג לא תמיד מצליח.
    שיטת ה-Immutable היא שיטה הרבה יותר קלה לעבודה: אנחנו מכינים Image Master שאינו כולל DATA, אך כולל את כל ההגדרות שאנחנו צריכים, ובעת ה-Deploy של ה-Image אנחנו נריץ סקריפט שנמצא בתוך ה-Image שיבצע את השינויים וההגדרות האחרונים שאנחנו רוצים (אפשר לדוגמא לכתוב סקריפט קצר של 2-3 שורות שימשוך מ-GIT את הסקריפט שיבצע עדכון הגדרות, לא לעדכן/להתקין חבילות אחרת זה רק יאיט את הזמן עד שהמכונה תהיה זמינה – את זה תעדכנו ב-Master Image). ב-Instance החדש שום דבר לא נשמר מקומית: לוגים עוברים לשרתי עיבוד (Elastic וחבריו), SQL רץ במקום אחר (שרות מנוהל או ממכונה אחרת), קבצים שצריך להנגיש מגיעים מ-EFS או S3, כך שבשרת עצמו שום דבר מהותי לא יכתב, ואם צריך – נוכל למחוק מיידית את ה-Instance ללא נזקים. את ה-Image הזה נוכל לעשות Deploy בכל כמות שנרצה (לא לשכוח לחבר אותם ל-Load Balancer). בשיטה הזו אין צורך לגבות את המכונות, אבל כן כדאי לגבות את ה-DATA שנשמר במקומות אחרים מחוץ ל-Instance.
    למעוניינים, יש בלינק הזה קליפ שמסביר זאת בצורה יותר מוחשית.
  • קונטיינריזציה/אורקסטרציה: עם קונטיינרים, אין שמירה של הדברים, הואיל וכשקונטיינר מפסיק לעבוד, הוא "מת" ולכן עבודה עם קונטיינרים מחייבת עבודה מול אחסון חיצוני. חשוב: את ה-Volume של הקונטיינר (או PV/PVC במקרים של Kubernetes או OpenShift) למפות למקור חיצוני. Kubernetes/OpenShift יודעים לתמוך במגוון מקורות כמו NFS, וגם Docker יודע לדוגמא לתמוך ב-NFS (תמיכה ב-iSCSI ל-Docker – בדרך).

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

תחום ה-VDI וענן – עדכון מצב

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

על מנת להבין את הבעיה, נתחיל בהתחלה הפשוטה: כל ספקי הענן ישמחו לאפשר לך לשכור מכונה (Instance או VM) מבוססת Windows, בין אם מדובר על Windows Server 2012, 2016 או אפילו 2019. אין שום בעיה. רוצה משהו כמו Windows 10 או גירסה מתחת? תשכח מזה. ספקית ענן כמו אמזון שמחה להציע משהו "דומה ל-Windows 10" לדוגמא. מה שתקבל בעצם זה Windows Server 2016 ששינו לו מספר גדול של ערכים ב-Registry, שהותקן עליו Windows Experience וגם מספר אפליקציות בסיסיות. יש גם את חבילת ה"פלוס" שכוללת אופיס, אבל אז אתה משלם תוספת שכוללת תשלום חודשי למיקרוסופט לא רק על ה-OS, אלא גם על ה-Office שמותקן ב-Instance. למכונה כזו אתה יכול להתחבר עם כלים שונים שמתאימים לכל מערכת הפעלה קיימת, כולל סלולרי/טאבלט/כרומבוק וכו'.

אז מדוע אף אחד לא מציע מכונה מבוססת Windows 10? אחרי הכל, שרות שידע להקים מכונה כזו מ-אפס או אפילו לקחת Sysprep שלך ו"להלביש" אותו על ה-OS זה לא משהו כזה מסובך לכתוב…

הבעיה מגיעה מכיוון רדמונד. מיקרוסופט לא רוצה (ולפעמים גם נלחמת באמצעים משפטיים) ששום ספק יציע שרות כזה, ולא חשוב אם מדובר בספק ענן ענק, או בחברת Hosting פצפונת. מבחינת מיקרוסופט, המוצרים היחידים מבחינת OS המוצעים לספקי Hosting וענן כאחד – הם אלו הכלולים תחת רשיון SPLA בהם הספק משלם למיקרוסופט כל חודש על רשיונות ה-Windows Servers (וכלים אחרים) ואת המחיר הוא מגלגל על הלקוח. במסגרת הדברים המוצעים ב-SPLA, אין שום הצעה/שורה למערכת דסקטופ כלשהי, ולא חשוב אם מדובר בגירסת Home או Enterprise.

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

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

וכאן נשאלת השאלה שכולם ירצו לדעת: האם זה שווה פיננסית? ניקח דוגמא: ראובן, CTO של חברה גדולה מעוניין לזרוק/לגרוט את כל ה-800 דסקטופים של החברה. להתקין לכולם Thin Client (ואלו שמחוץ לחברה ישתמשו בתוכנת Client יעודית או בדפדפן) ופשוט לעבוד בענן. אם מחר ראובן היה שוכר את שרותי היעוץ שעבדכם הנאמן מציע – מה הייתי אומר לו?

כל מי שהרים מערכת VDI יודע שיש בעצם 2 אפשרויות, ברמת המאקרו: הראשונה היא "לפרסם" אפליקציות ולהתחבר דרך מערכת מרוכזת אחת ולקבל בעצם (לאחר אותנטיקציה) את תצוגת האפליקציה ללא כל הדסקטופ "מסביב", והאפשרות השניה היא בעצם "Pool" של מכונות וירטואליות הכוללות מערכת הפעלה עם האפליקציות הדרושות, וכשהמשתמש מתחבר, הוא מקבל בעצם VM עם הדסקטופ כשאליו מקושר הפרופיל של המשתמש.

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

בקיצור: אם ספקי הענן יציעו שרות של מכונות וירטואליות עם Windows 10 כ-שרות VDI והם יגבו כמו שהם גובים כיום על Instances, המחיר הכולל פשוט לא יהיה שווה מכיוון שעלויות התקשורת יהיו אסטרונומיות. החברות יצטרכו להציע חבילות Bundle הכוללות מספר טרהבייט תעבורה בחודש עם שרות VDI.

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

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