הטריקים של אורקל עם OVS

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

נשמע משתלם, לא? 

לא בדיוק.

הבה נציץ מאחורי הקלעים: פתרון הוירטואליזציה שאורקל נותנים עם המערכת הוא פתרון שהיה נקרא בעבר Virtual Iron שהיה מבוסס על Xen. מאז שאורקל רכשו את החברה, הפיתוח הואט כנראה וכיום הוא אפילו לא משתווה למתחרה הישיר שלו – XenServer של Citrix. מה שאורקל שינו מאז במערכת הם שינויים קטנים ועדכונים (כך לדוגמא, אם אתה חושב להצמיד כרטיס PCI למכונה וירטואלית, תתכונן לכשלון, זה פועל בקושי. חושב על פתרון כמו Shared Memory בין מערכות וירטואליות שמריצות את אותה מערכת הפעלה? יש, אבל שלא תחשוב שזה כמו ESXI) אבל הם מתנדפים בהשוואה למערכות וירטואליות כמו ESXI או אפילו Hyper-V. אם אתם לא מכירים לינוקס טוב, תתכוננו להרבה תסכול, כי זה מה שה-GUI (ה-VM Manager) נותן: תצוגה מוזרה של דברים, נעילות של מכונות אם JOB נופל (לך חפש את ה-JOB ומהיכן לשחרר נעילה), ותשכח ממצב לראות סטטוס כללי של כל המכונות הוירטואליות שלך אם הם רצים, כמה זכרון הם משתמשים וכו'. רוצים סקירה קצת יותר עמוקה על המוצר? קחו, קראו בעצמכם.

לא מדובר פה באיזו "אשמה" של המערכת הוירטואלית עצמה (XEN) כלל וכלל! אם תיקחו לדוגמא את XenServer של Citrix, יש למוצר דווקא ממשק בכלל לא רע כי ל-Citrix יש הרבה יותר נסיון עם ממשקים, Windows וכו'. גם מבחינת תמחור קשה להתחרות במוצר של Citrix. אפשר להוריד אותו בחינם (קוד פתוח) ואפשר לקבל שרותי תמיכה בתשלום שנתי של $199 פר תושבת מעבד. 

פה בישראל, הבעיה חמורה בהרבה. הבעיה עצמה מתחילה בתמיכה, והח"מ, כאחד שעבד עם התמיכה של אורקל למוצר, אני יכול לתאר את אותה תמיכה כמתחת לכל ביקורת. תומכים שלא יודעים על מה הם סחים, אינטגרטורים של אורקל עצמה שמגיעים ולא יודעים מה הם מתקינים (או שמתקינים ושוכחים להתקין קבצי RPM שונים) או שלא יודעים להתקין דברים בצורה נכונה (ראיתי אישית מקרה של'קח להם יומיים לפתור תקלה של … invalid boot signature של GRUB. הם פירמטו את המכונה הפיזית, אני לא צוחק!). בשבוע האחרון ראיתי את ה"יעילות" של אורקל. עמית פתח באורקל תקלה על אחד מהשרתים הוירטואליים (שנתמך ע"י אורקל). לכלי איסוף לוגים של אורקל לקח כמעט 3 שעות עבודה ליצור קובץ שצריך לשלוח לתמיכה (אחרת הם לא עוזרים לך בכלים), אני החלטתי מנסיוני פשוט לפתור את העניין וסיימתי את התקלה (לאחר תיקונים והתקנות של חבילות חסרות שאורקל ישראל לא התקינו) לאחר דקות ספורות. אם לא הייתי נותן שרות ללקוח, הוא היה מושבת לפחות ליום!.

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

  1. ודא כי יש לך איש לינוקס מקצועי בחברה או פרילאנסר שנותן שרותים ושהוא מקצועי, עם המערכת OVS של אורקל, אתה בהחלט תצטרך את זה.
  2. אם החלטת ללכת על פתרון XEN, כדאי שתתקין על שרת טסטים את XenServer, הוא יותר מעודכן ויותר ידידותי לחובבי GUI (אם כי גם שם תצטרך איש לינוקס לכל האוטומציה, סקריפטים וכו').
  3. אל תאמין לכל מיני חומרים שיווקיים שמראים לך כי OVS יותר טוב מ-ESXI או Hyper-V. הייתי שמח לפרסם תוצאות ביצועים, אולם הרשיון של OVS אוסר זאת. 

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

מוגש כחומר למחשבה.

הבעיות של VCSA

קצת היסטוריה על VMWare ו-ESX: כש-VMWare החליטו בזמנו לצאת עם גירסת שרת מלאה (לפני כן היתה “גירסת שרת” אבל שהיתה רצה על מערכת ההפעלה שמותקנת במחשב שלך) הם יצאו עם 2 גרסאות: האחת נקראה ESX והשניה ESXi. גירסת ה-ESX נראתה כמו הפצת לינוקס (מה שגרם לרבים להתבלבל ולחשוב שמדובר בהפצת לינוקס מטעם VMWare עם קרנל לינוקס. המציאות היא שהקרנל הוא כולו של VMWare והם השתמשו בממשק תאימות בינארית ללינוקס (ABI) על מנת להריץ שרותי לינוקס שונים על ה-ESX וגם שמנהל השרת יוכל להתקין שרותים נוספים מלינוקסים אחרים על המכונה (זה היה תואם רד-האט). גירסת ESXi לעומת זאת היתה גירסה רזה שכללה רק את הקרנל + Shell מינימלי ועוד כמה כלים, רק בלי חומת אש, שרותי לינוקס וכו’.כיום יש רק גירסת ESXi.

אחד הדברים שהפתיע אנשי לינוקס רבים היה כלי הניהול של VMWare, מה שמוכר בתור ה-vCenter (לשעבר Virtual Center) שהיה כלי על טהרת ה-Windows שנכתב בדוט-נט ושגם שילב בתוכו חלקים מאינטרנט אקספלורר. VMWare גם הוציאה כלי וובי אבל שלא נתן הרבה פונקציונאליות (כלומר הוא לא יכל להחליף את ה-vCenter). מנהלי רשת רבים התלוננו מדוע אין כלי לינוקסאי כזה והתשובה של VMWare היתה שחרור של SDK וגם מכונה וירטואלית לינוקסאית קטנה שכללה סקריפטים שאפשרו לחברות שמשתמשות בלינוקס – להתממשק עם ה-vCenter.

בגירסה 5 הדברים התחילו להשנות (והשתנו יותר בגירסה 5.1) כאשר VMWare שחררו את ה-VCSA (ר”ת של VMWare vCenter Server Appliance) – זו מכונת לינוקס וירטואלית שאמורה להחליף את הגירסה החלונאית בגירסת לינוקס. היא עדיין לא כוללת את כל הפונקציונאליות של הכלי החלונאי (כך לדוגמא עדיין לא ניתן להתקין תוספים/Plugins ב-VCSA עצמו), אבל VMWare נתנה רמז עבה מאוד שזו דרכה – היא חוזרת ללינוקס ובגרסאות עתידיות היא תשקיע יותר ב-Appliance הלינוקסאי מאשר בכלי החלונאי.

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

הבעיה הראשית מתחילה בזה ש-VMWare לא שחררה אותו כקובץ ISO להתקנה שמזכירה לינוקס (כמו שהיה ב-ESX 3.X) אלא שחררה אותו כקופסא סגורה עם קבצי OVF, VMDK וכו’, ומה ששחררו קיימות בו כל מיני בעיות הקשורות לרשת שפוסט זה יתייחס אליהם.

כאן אצלי בבית ב-LAB שלי, יש לי 2 שרתי DNS (מאסטר/סלייב) וסביר להניח שאם אתה מתעסק עם VMWare בחברה, יש לכם איזה שרת DNS, בין אם זה לינוקס או (סביר להניח) הפתרון של מיקרוסופט שמשולב Active Directory. אני מניח שהכנת לך שם hostname יחודי עבור ה-VCSA עם כתובת IP יחודית משלו ושלא ממש הלכת ל-Go Daddy או ספקים אחרים כדי לרכוש לשרת תעודת SSL, וכאן מתחילה הבעיה (לא באי רכישה) – ה-VCSA מגיע עם שם מכונה localhost שזה לא בדיוק דבר שתרצה.

אתה יכול להיכנס לממשק הוובי, להגדיר כתובת IP ושם hostname, להתחבר ל-AD ואולי להשתמש ב-DB חיצוני (אורקל או DB2 של IBM, עוד לא SQL של מיקרוסופט וגם משום מה לא MySQL, קצת מפתיע ש-VMWare משתמשים ב-JAVA ב-VCSA והם משתמשים ב-JDBC ב-Tomcat אבל הם לא כוללים תמיכה ל-DB אחרים. אם אתם רוצים להוסיף תמיכה למיקרוסופט SQL נסו את הלינק הזה [אגב, הלינק כרגע מת, אבל תודות לגוגל אפשר לראות את הגירסה הטקסטואלית כאן]), אבל ברגע שתשנו כתובת IP ואת ה-hostname ושאר פרמטרים (לא לשכוח ללחוץ על Toggle certificate settings שישתנה ל-yes) – תצטרכו להפעיל את המכונה מחדש (דרך החוצץ System)

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

waiting for the embedded database to startup [ok]

מה קרה? אוה, טוב ששאלתם…

ה-VCSA הבין שצריך ליצור תעודת SSL חדשה, והוא יצר, אבל הסקריפט של ה-DB לא יודע מה לעשות הלאה, אז הוא פשוט נתקע. אם תעשו Reboot למחשב, זה לא יעזור. זה יחזור שוב. מה שצריך לעשות הוא לבטל את האופציה ליצור תעודות SSL, אבל … אין לכם גישה לא לממשק הוובי ולא ל-SSH. תצטרכו לטפל בזה כמו שמטפלים בתקלה בשרת לינוקס (לא חשבתם שתתחמקו מלינוקס, נכון?)

אז איך מטפלים? כרגיל עם VCSA, מי שבנה את ה-Appliance בנה בצורה מחורבנת לגמרי. Safe mode לא יעזור לכם, ולכן עקבו אחר ההוראות הבאות:

  1. הפעילו את השרת מחדש והיכנסו מיד ל-Console ולחצו על מקש (לדוגמא רווח) כדי לעצור את הטיימר.
  2. לחצו על מקש p ואז ה-grub יבקש סיסמא. הסיסמא היא סיסמת ה-root שלכם (אם לא שיניתם אותה עדיין, היא vmware באותיות קטנות)
  3. לאחר הקשת הסיסמא תחזרו שוב ל-GRUB. בחרו בשורה הראשונה ולחצו על מקש e
  4. כעת יופיעו לכם השורות ש-grub אמור להריץ. לחצו על החץ למטה ובחרו בשורה השניה ושוב לחצו על מקש e
  5. לכו עם החיצים עד סוף השורה והוסיפו את הטקסט הבא: init=/bin/sh ולחצו על מקש enter
  6. כעת לחצו על מקש b והלינוקס יתחיל להיטען ולאחר מספר שניות הוא יעצר עם סימן #
  7. כעת עלינו למחוק קובץ. כל עוד הקובץ קיים, המערכת תנסה ליצור תעודות חדשות והמערכת תיתקע ב-boot רגיל, לכן הכניסו את הפקודה:
    rm /etc/vmware-vpx/ssl/allow_regeneration
  8. הקישו את הפקודה reboot ולחצו enter. המערכת תיתן אולי מספר הודעות שגיאה. תתעלמו.
  9. המערכת תעלה מחדש ובהצלחה. לאחר שתקבלו את המסך הכחול (אחלה בחירת צבעים יש להם), תמתינו עוד מספר שניות (או דקות, תלוי במעבד וכמה חזקה המכונה) ואז היכנסו לממשק הוובי

ברכותיי. נגמרה הבעיה.

אני ממליץ בחום לא להשתמש ב-VCSA במערכות פרודקשן! כותב שורות אליו מצא המון סקריפטים בתוך ה-VCSA שיש להם באגים ומי שכתב אותם כנראה למד לינוקס מתוך ספר ולא מתוך התנסות מלאה (שורות של סקריפטים שחוזרות במקום להשתמש ב-while וכו’) ויש גם לא מעט שגיאות במימוש התחברות ל-NFS – עקבו אחר ההוראות כאן) ואני משער שהדברים ישתפרו בעתיד (ואולי, מי יודע, אולי הם יוסיפו איזה משהו שמראה הורדת גירסה בזמן שמשדרגים במקום מסך סטטי שאין לך אפשרות לדעת אם יורד משהו וכמה ירד!), אבל עד אז, שימו את ה-VCSA כ-VM על מכונה צדדית (אגב, בניגוד להגדרות שם, אין צורך ב-8 ג’יגה זכרון, גם 4 יספיקו בשביל הטסטים). אני גם מקווה שבעתיד הם יוציאו גירסת ISO נורמלית ואולי, רק אולי, יהיה פורום או מקום כלשהו לדווח על באגים ואולי לתת להם תיקוני סקריפטים, גם למי שאין לו מנוי בתשלום (היי, אני יכול לקוות, לא?).

כמה מילים על KVM ועל Open Stack

אנשי IT רבים, כשהם מדברים על וירטואליזציה, הם מדברים בד”כ על אחת מ-2 הפתרונות הידועים: VMware עם סל הפתרונות שלו או פתרונות מבוססי Hyper-V של מיקרוסופט. חלק קטן מהאנשים גם מכיר פתרונות מבוססי Xen כמו הפתרון של Citrix.

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

חלק עיקרי מ-Open Stack הוא החלק של הוירטואליזציה, העיבוד, ה-Compute ולמרות ש-Open Stack יכול לעבוד כמעט עם כל פתרון וירטואליזציה, בברירת המחדל שלו הוא משתמש ב-KVM של רד האט.

KVM שבעבר נתפס כמשהו “נחמד” אך רבים העדיפו לא להיכנס אליו (ואם להשתמש בפתרון מבוסס קוד פתוח אז פתרון מבוסס Xen), נתפס היום ככלי וירטואליזציה רציני מאוד. חברות כמו גוגל עם ה-Compute Engine שלה משתמשת ב-KVM, חברות Hosting רבות יורדות לאט מהפתרון שיש להם ועוברות להשתמש ב-KVM, וגם חברות שמציעות שרתים וירטואליים ממש בזול (כמו Digital Ocean) נותנות את הפתרון עם KVM ולא עם פתרונות וירטואליזציה אחרים. גם חברות ענק כמו IBM שבעבר היו נותנות פתרונות מבוססי VMWare או פתרונות אחרים, נותנות כיום פתרונות עם KVM ועם תוכנות נוספות משלימות. כך לדוגמא IBM מציעה פתרונות VDI עם שילוב פתרון של VERDE כאשר הוירטואליזציה עצמה היא KVM “נטו”.

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

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

יתרון גדול נוסף הוא שגם מבחינת Middlewear אינך מוגבל. אתה משתמש ב-SAN כלשהו? כל עוד אותו SAN יודע “לדבר” בפרוטוקולים כמו iSCSI או NFS וכל פתרון לינוקס/יוניקס ידוע, הוא יוכל לעבוד עם KVM. אתה מעוניין ב-Switch וירטואלי חזק שיודע לעשות פילטרים, QoS ודברים אחרים? פתרון כמו OpenVSwitch ישמח לגשר בין המכונות הוירטואליות שלך ולתת לך את מה שאתה צריך. פתרונות מבוססי VDI ל-Windows או Linux? אם זה Windows, אז יש לך פתרון RDP כבר בתוך ה-Windows (ומעליו יש לך VLC לראות את ה-Boot אם אתה רוצה), ובלינוקס אתה יכול להשתמש בפתרונות כמו NX שיחסוך לך תעבורה וגם יתן לך איכות תצוגה מעולה.

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

  • רוצה לעבוד עם סקריפטים? (סביר להניח שהתשובה שלך תהיה “כן”): אז הפתרון הראשי שתרצה לבדוק הוא Libvirt שנותן לך תמיכה בכל שפת סקריפטים ידועה ואפילו בשפה כמו #C. עם Libvirt אתה יכול לעשות אוטומציה להכל, כיד הדמיון הטובה עליך.כלי שיכול לעזור לך הרבה בתוך Libvirt הוא virsh, שניתן להריץ אותו דרך shell ולבצע דברים. אגב, עם Libvirt ניתן גם לנהל מערכות וירטואליות מתחרות כמו vCenter או שרתי VMware בחיבור יש ל-host.
  • רוצה קצת GUI על הלינוקס שלך? (נו טוב, יש גם כאלו). לשם כך יש כלי כמו Virt-Manager. עם הכלי הזה תוכל בקלות להרים מכונות, לראות צריכת משאבים וכו’. זה ל-vCenter כמובן, אבל זה כלי בסיסי מספיק כדי להתחיל ללמוד וגם לעקוב אחרי מערכות קיימות שרצות.
  • מה עם כלי רציני שרץ דרך דפדפן? אה, טוב ששאלתם, בשביל זה יש את oVirt. זה הכלי הכי רציני שנותן לך לנהל הכל ב-KVM.

אז מה ההבדל הגדול בין KVM ל-Open Stack? אפשר להשוות את ההבדל ביניהם להבדל בין vCenter ל-vCloud Director. ה-Open Stack מתאים למצבים שיש צורך בהמון, המון מחשוב ענן של אלפי שרתים וירטואליים, פריסה על פני כמה Data Centers, צורך בשרותים דמויי AWS של אמזון (כמו S3 וכו’) ובקיצור – כשמדובר על דברים גדולים, Open Stack יכול בהחלט להיות אופציה טובה.

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

סקירה מקדימה: Google Compute Engine

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

גם גוגל נמצאת בזירה, אבל לא תשמעו על הרבה לקוחות שמשתמשים במחשוב הענן של גוגל (אלא אם מדובר ב-Google App Engine שהוא דבר שונה). הסיבה? גוגל עדיין לא מקבלת את כולם ויש צורך בתהליך בקשת אישור על מנת להצטרף. הדברים כפי שנראים כרגע ישתנו בחודשים הקרובים לאחר I/O 2013 שיערך בחודש מאי הקרוב.

לעבדכם הנאמן (שמציע, אההמ, שרותים בנושא). יצא קצת לשחק ב-Google Compute Engine (נקרא לזה פשוט GCE מעתה והלאה) ואת האמת… הופתעתי לטובה, ולא קל להפתיע אותי. כל כך הופתעתי לטובה שאני יכול להמליץ בחום, שאם מחכה לכם פרויקט הטמעה למחשוב ענן וזה יכול לחכות 3-4 חודשים, אז אני ממליץ להמתין ולהשתמש ב-GCE.

אז נתחיל מההתחלה: מה זה בעצם ה-GCE ומה הוא שונה מהמתחרים?

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

מבחינת המכונות עצמם, גוגל כרגע מבדלת את עצמה משאר המתחרים מבחינת המכונות הפיזיות: כאן לא תמצאו מעבדים שאיזה ספק קנה בקילו מיצרן מעבדים שרצה להיפטר מהמלאי. כל המכונות הן Sandy Bridge (גירסת XEON) ומעלה, וכאן מגיעה נקודה חשובה שיכולה אולי לבעס חלק מהלקוחות הפוטנציאלים: גוגל משכירה מכונות גדולות. הכי קטנה מתחילה עם כמעט 4 ג'יגה זכרון ו-400 ג'יגה דיסק מקומי (יש גירסה ללא דיסק מקומי, על כך בהמשך) והמחיר מתחיל בערך ב-100 דולר לחודש, כך שמי שרוצה איזה מכונה נחמדה לארח את הבלוג שלו שנכנסים אליו 10 קוראים בשבוע, עדיף שימצא פתרון אחר. מבחינת גודל מקסימלי של מכונות, כאן תמצאו מכונות עם עד 8 ליבות ועד 52 ג'יגהבייט זכרון.

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

קצת יותר פרטים לעומק:

אחסון מידע

גוגל מאפשרת לך לאחסן את מידע בדיסק ב-3 תצורות שונות, כאשר הראשונה היא דיסק מקומי, השניה היא Persistant והשלישית היא ה-Cloud Storage:

  • דיסק מקומי: אתה יכול להקים מכונה וירטואלית על דיסק מקומי. גוגל מאפשרת זאת אבל בפירוש גוגל ממליצה להשתמש בדיסק מקומי רק לכתיבה של דברים זמניים. בנוסף, אם אתה מוחק מכונה וירטואלית, נמחק גם הדיסק. 
  • Persistant: שיטה זו יותר מוכרת למשתמשי אמזון כ-EBS. אתה מקבל אחסון שאתה עושה לו Mount במכונות שלך. לעומת אמזון, גוגל לקחה את זה צעד קדימה ואתה יכול להקים מכונה ללא דיסק (Diskless) כאשר מדובר בעצם במכונה עם דיסק קטן מאוד שעושה Boot ו-Mount לאחסון.
  • Cloud Storage: בקצרה, מי שמכיר את S3 יודע על מה מדובר. גם כאן יש לך דליים (Buckets) וכו'.

טופוגרפיה:

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

גיבויים ו-Snapshots:

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

רשתות תקשורת:

כשאתה מרים מכונות או פרויקט חדש, GCE מקים עבורך רשת ברירת מחדל עם גישה פתוחה לפורט 80 ופורט 22. אתה יכול להקים עד 4 רשתות תקשורת ולקבוע חוקים ל-Firewall מבחינת גישה של איזה מכונה תוכל לדבר עם מי ובאיזה פורט. יש לך NAT בתצורת 1:1. כמו אצל ספקים אחרים, כתובת ה-IP שאתה מקבל לגישה חיצונית היא זמנית ועליך לשייך כתובת IP לרשת שלך, אתה יכול להוסיף לך גם כתובות IP נוספות שיגשו למכונות שונות (פרוקדקשן, טסטים, סטייג' וכו'). 

אזורים:

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

רישומים:

כמנהל מערכת, סביר להניח שתרצה לדעת מי הקים ועשה מה ב-GCE שלכם, ולכן גוגל נותנת לך רישומי מערכת (Audit)

גישה וניהול:

מבחינת גישה וניהול המערכת שלך, לרשותך 3 אפשרויות:

  • גישת Web דרך הדפדפן
  • גישת CLI דרך חבילה שתתקין על מק או על לינוקס
  • דרך RESTful API, לחובבי התכנות והסקריפטים

תמחור:

בניגוד לאחרים (אהלן Azure!) טבלת המחירים של גוגל מאוד פשוטה ואינה מצריכה מחשב כיס / רואה חשבון כדי להבין אותה, ואפשר לראות אותה כאן.

לאחר שתיארתי את המערכת, נתאר גם חסרון מהותי שלה: אם מישהו משתמש ותיק באמזון וחושב לעבור ל-GCE מחר בבוקר, תהיה לו בעיה. בניגוד לאמזון, ה-GCE של גוגל עדיין צעיר ועדיין חסרים לו כל מיני חלקים. רוצים Load Balancing? תקימו פתרון כזה בעצמכם. רוצים כל מיני פתרונות הקמה אוטומטית של שרתים בעת עומס? שוב, תכתבו פתרון עם ה-API שבעת עומס יקים מכונות נוספות. רוצים DNS כמו Route 53? אין כרגע, ועוד הרבה דברים שיש באמזון, אין כרגע אצל גוגל.

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

לסיכום

ה-GCE של גוגל עדיין נמצא בשלבי בדיקה לקראת קבלת לקוחות בכמות מאסיבית, וכיום יש צורך בהגשת בקשה כדי להתקבל ולהשתמש בשירות, אבל מה שגוגל מציעים נראה מפתה ומבטיח הן מבחינת פתרונות והן מבחינת ביצועים. ה-GCE עדיין לא מתחרה במגוון הפתרונות שאמזון מציעים, וזה יכול להוות לחברות שמחפשות שרות מוכן (כמו Load Balacing), אך מצד שני, חברות סטארט-אפ עם אנשי Devops או Sysadmin טובים, יוכלו לקחת פתרונות קוד פתוח ולהשתמש בהם כדי לתת לעצמם פתרון כזה, כך שזה מאוד תלוי בלקוח GCE. המחירים עצמם עדיין מעט יותר גבוהים (סנט או 2) מאמזון ואני מניח שבעת הפתיחה הרשמית, תחל מלחמת מחירים רצינים בין גוגל, אמזון ומיקרוסופט. עדיין אין מכונות עם Windows אך אני מניח שזה יפתר בקרוב, ואני מאמין שלראשונה נראה קרב רציני בין 3 ענקי ספקי מחשוב ענן גדולים. אם אתם אנשי IT, צפו להתקפת אנשי מכירות עליכם השנה 🙂

הגנה פשוטה נגד Defacement – לבעלי VPS

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

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

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

הטריק שאנחנו הולכים להשתמש, הוא טריק שמשנה הרשאות ברמת ה-File system אך לא ברמת ה-UNIX אלא ברמה של ה-EXT2/3/4, כלומר ברמה של הקבצים ב-Partition. שם ההרשאות הן שונות מרמת הלינוקס הרגילה שאנחנו מכירים וניתן לעשות דברים רבים עם זה. אפשר לקרוא על כך עוד כאן.

בעקרון אנו צריכים לשנות את הרשאות הכתיבה כך שלא ניתן לשנות או למחוק את הקובץ בכלל, גם משתמש root לא יוכל למחוק את הקבצים הנ"ל. אלו קבצים אנו צריכים לשנות? את קבצי ה-index.php שלא ישתנו בהמשך הדרך. בד"כ זה קובץ ה-index.php הראשי וגם קבצי index.php של תוספים.

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

ההרשאה שאנו מדברים עליה נקראת immutable bit, וכפי שהסברתי מקודם, שינוי הרשאה של קובץ עם הביט הזה, ולא ניתן יהיה לשנות או למחוק אותו. על מנת לשנות את הקובץ ולהגן עליו, בצעו את הפקודה הבאה כ-root או עם sudo:

chatter +i index.php

כעת אתם יכולים לנסות לערוך את הקובץ ולשמור. המערכת פשוט תאמר לכם שלא ניתן לכתוב.

רוצים לשנות את הקובץ בחזרה למצב רגיל כך שניתן יהיה לכתוב עליו? בצעו את הפקודה הבאה:

chatter -i index.php

עכשיו תוכלו לעדכן.

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

השיטה הזו אינה מגינה 100%. אם פורץ הצליח לקבל הרשאות root ע"י שימוש ב-exploit כלשהו, הוא יגיע לקבצים ואם הוא יודע קצת לינוקס, הוא יוכל לשנות עם פקודת chattr, אבל גם בלי זה, אם האתר שלכם נפרץ, אז יש מצב שהפורץ יעלה לשם קבצים או שישנה לכם את ה-DB, ולכן אם אכפת לכם מהאתרים, מומלץ מדי פעם להציץ ב-DB לראות שהכל תקין, שאתם יכולים להיכנס ל-wp-admin (אם זה וורדפרס) או administrator (אם זה ג'ומלה), ובדקו שאין בתיקיית האתר קבצים שלא אתם הוספתם. כבר ראיתי מקרים שמישהו הגן על האתר שלו אבל הצצה לתיקיית ה-public_html שלו הראתה ערימות של קבצי פריצה רק מחכים לשימוש.

 

טיפ ל-VMWARE ESX/I: סיסמת root

כל איש סיסטם/Devops שמשתמש ב-VMWare ESXI יודע שהחיים עם VMWare הם יחסית לא רעים. החברה מנפיקה כלים לנהל/להקים/לתחזק את המערכות הוירטאוליות וחברות צד שלישי כותבות כל מיני אפליקציות שנותנות ערך מוסף (כמו VEEAM עם הגיבויים והמיגרציה שלהם וכו’).

בעקרון כל מערכות ה-vSphere של VMWare מומלץ שיעבדו מול Storage שעליו יאוחסנו ושם בעצם ימצאו הדיסקים הקשיחים הוירטואליים. אם אין לך Storage, בגירסה 5 הוסיפו VMWare תכונות להקים Storage קטן ופשוט (יחסית). זה לא מה שיחליף פתרונות של EMC או NETAPP במקרים מסויימים, אבל זה יכול לשמש כפתרון לא רע בשלב התחלתי.

אחת הסיטואציות שקורות גם עם VMWare אבל גם עם כל מערכת הפעלה רגילה אחרת, זה ששוכחים את סיסמת מנהל השרת (ה-root או ה-Administrator) לשרת מסוים. ב-Windows אם אתה משתמש ב-Active Directory והשרת משוייך ל-AD, אתה יכול להתחמק מכך בכך שתבחר את ה-AD, תכניס שם משתמש וסיסמא של בעל הרשאות אדמיניסטרציה ותגמור עם זה. בלינוקס אתה יכול פשוט לעשות boot במצב Single mode (במערכות אובונטו או דביאן תצטרך לבצע שינוי זמני ב-GRUB בזמן שאתה מפעיל את השרת), ולאחר שנכנסת למצב המינימלי תוכל להריץ פקודת passwd לשנות סיסמא, ולהפעיל את השרת מחדש (reboot) או לעבור ל-mode אחר (telinit 2 דביאן, telinit 3 ב-CentOS לדוגמא).

ב-VMWare אין לך אף לוקסוס כזה. שכחת את סיסמת ה-root, אין אפשרות לבצע rescue boot ולשכתב סיסמא מחדש. הפתרון הרשמי של VMWare זה שתעשה vmotion לכל המכונות שלך לשרתים פיזיים אחרים, תפרמט ותתקין את ה-ISO מחדש. לאחר ההתקנה תבצע שוב vmotion מהשרתים האחרים לשרת שהתקנת הרגע ונגמרה הבעיה.

הכל טוב ויפה, אבל מה אם אין לך Storage? מה אם שכרת שרת או 2 בחוות שרתים וזה מה שיש לך? אתה יכול לשכור עוד שרתים פיזיים ולהעביר אליהם את המכונות הוירטואליות, אבל אז ה-Migration הוא מה שנקרא Cold, כלומר העברת המכונה תהיה בתהליך של יצירת snapshot, העברת כל ה-VMDK ושאר קבצים, עוד snapshot, העברת ה-Delta, והפעלה מחדש (אם כמובן כל ההגדרות רשת תואמות וכו’, אחרת תצטרך לשנות ידנית כל מכונה). כל התהליך הזה כרוך ב-Down time, אבל הוא כרוך בהמון עבודה, תלוי כמה מכונות יש לך על כל שרת – אתה יכול לצפות לעבודה של לפחות כמה שעות טובות או לפחות יום (שוב, תלוי בכמות שרתים, תעבורת תקשורת וכו’).

יש פתרון חלופי לבעיה זו. זה לא פתרון רשמי של VMWare אבל הוא בהחלט עובד. הפתרון אמנם כרוך ב-Downtime מוערך בדקה או 2 של השרת הפיזי, אבל זה הרבה יותר משתלם מאשר להתחיל להעביר את כל המכונות הלוך ושוב.

להלן הצעדים לביצוע התהליך (הכל דרך vcenter).

  • ודא כי המכונה הנ”ל מחוברת ל-vcenter שלך, בלעדי זה אי אפשר לבצע את התהליך כי אין לך כניסה ב-SSH למכונה (אין לך סיסמת root זוכר?).
  • כבה את כל המכונות הוירטואליות
  • בחר לעבור למצב Maintenance mode (לחיצה ימנית על השרת, ובחירת האופציה הנ”ל)
  • בתפריט ה-Host profile (שמופיע עם לחיצה ימנית על השרת הפיזי) בחר Create Profile from host – תן לזה שם שתכיר שזו המכונה הנ”ל ועדיף שתכתוב קצת תיאור ב-Description, אם תצטרך זאת יום אחד.
  • לאחר שיצרנו פרופיל – נערוך אותו: לחץ על ה-Home משמאל למעלה, ובחר Host Profiles (בד”כ מופיע בשורה שלישית)
  • מצד שמאל יופיעו לנו הפרופילים. בחר את הפרופיל שיצרת, לחץ כפתור ימני עליו ובחר Edit profile
  • יופיע חלון חדש עם “עץ”, בתוך ה”עץ” בחר את Security configuration ובתוכו את Administrator Password
  • לאחר שלחץ על Administrator Password מצד ימין, החלק הימני של החלון יעודכן, בחר מתוך ה-Drop Down את האפשרות Configure a fixed administrator password, כך אנחנו בעצם נקבע סיסמא חדשה
  • כעת החלק החשוב: הקש סיסמא מורכבת, הווה אומר לפחות 8 סימנים המורכבים מאותיות ומספרים (אפשר גם סימנים אחרים). סיסמאות של 6 אותיות או 6 מספרים יכשילו את התהליך. כתוב שוב את הסיסמא בקוביית ה-confirm.
  • לחץ על OK
  • כעת חזור אל העמוד עם פירוט השרתים (לחץ על Home למעלה משמאל ועל Host & Clusters)
  • בחר את השרת הפיזי, לחץ על כפתור ימני, ובחר Manage Profile. אם תקבל אזהרה על כך שכבר מוצמד פרופיל למכונה, לחץ על Cancel. אם תקבל חלון עם רשימת הפרופילים, בחר את הפרופיל שיצרת
  • אם השרת הפיזי אינו נבחר כרגע בחלון ה-vcenter, בחר אותו ותסתכל על חוצץ ה-Summary. כמעט בסוף המלבן השמאלי מופיע Profile Compliance – ואם הכל תקין, אמור להופיע עיגול ירוק עם סימון V. אם לא, משהו בהגדרות פרופיל שלך אינו נכון, חזור אחורה וערוך את הפרופיל עם סיסמא מורכבת.
  • לחץ כפתור ימני על השרת הפיזי, ובחר ב-Host profile את Apply Profile. התהליך יקח כמה שניות ותוכל לעקוב אחריו בחלונית ה-Tasks. אם הכל תקין, אתה תראה ב-Tasks הודעת Completed. אם לא, תקבל שגיאה, סביר להניח שקשורה לסיסמא. סיסמא מורכבת, כבר אמרתי?
  • הפעל את שרות SSH (בחירה מתוך חוצץ Configuration, בחר Security Profile, לחץ על Propteries למעלה מימין, בחר את SSH, לחץ על Options ולחץ על Start ואחר כך כפתור OK. אתה תראה את SSH כ-running.
  • פתח תוכנת טרמינל כמו Putty (או terminal במק או לינוקס), הכנס את כתובת ה-IP של השרת, פורט 22 (על מק או לינוקס יש לכתוב ssh [email protected] כאשר ה-ip-address זו כתובת ה-IP של השרת הפיזי). אם תתבקש להכניס שם משתמש, הוא כמובן root והסיסמא היא אותה סיסמא שבחרת מקודם. הקש אותה ואם קיבלת את סימן ה-# אז אתה יכול לנשום לרווחה, הכל תקין.
  • חזור ל-vCenter, לחץ על כפתור ימני על השרת הפיזי, ובחר Exit Maintenance mode ולאחר מכן הפעל את המכונות הוירטואליות.
  • ברכותיי, לא צריך לפרמט את השרת. אל תשכח לחזור ל-Security Profile ולבטל את שרות ה-SSH (כמו שהפעלת רק שהפעם בחר Stop).

זהו, אפשר להמשיך לעבוד עם המכונה, רק שהפעם מומלץ לרשום את סיסמת ה-root היכן שהוא  Smile

מחשוב ענן: תכין מסמך טיעונים

כל אינטגרטור, איש Devops, איש סיסטם ואחרים שמעודכנים בתחומי Cloud computing מודע בוודאי לכך שחוץ מאמזון שמציעה שרותי ענן רציניים, יש מתחרים לא פחות רציניים כמו מיקרוסופט, גוגל, Rack space ועוד פה ושם כמה ספקים קטנים (יחסית, יחסית).

מבחינת השרותים השונים, אפשר לנהל דיונים וויכוחים מקצועיים מכאן ועד להודעה חדשה אלו שרותים מתאימים מבחינת ספקים שונים. סתם דוגמא: האם שרותי ה-Cloud Front יותר טובים ממה שספקים אחרים כמו Akamai מציעים? התשובה היא כמובן “תלוי” – ל-Akamai יש רשת ענקית של שרתים בכל נקודה בעולם (רק בארץ יש להם 3 נקודות!), אבל מצד שני, המחיר ש-Akamai מבקש יכול להבהיל כל לקוח קטן עד בינוני.

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

תרשו לי להסביר, ואתייחס לנקודה הישראלית (אם כי כמובן זה יכול לקרות בכל מקום בעולם): בארץ, ה-Gold Standard בכל הקשור למחשוב ענן כשהלקוחות שלך מגיעים מכל העולם זה כמובן אמזון. סטארט-אפ שרוצה להציע שרותים והיזם הוא זה מי שמקים את התשתית, סביר להניח שזה מה שיבחר. הסיבות לכך פשוטות: רוב “החבר’ה” כבר שם, יש שפע של מידע איך לעשות מה מו מי, ויש לאמזון שם של חברה יציבה (יחסית כמובן).

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

מיקרוסופט בד”כ משתמשת בטריק ידוע: פינוק. לקוחות מוזמנים לכנסים עם ארוחות, סופי שבוע בבתי מלון ושאר פינוקים אחרים כדי “לרכוש את ליבם” של מנהלי ה-IT, ה-CTO ולפעמים ה-CEO של חברות שונות, באמצעות מצגות שונות שמראים כמה המוצרים של מיקרוסופט זולים יותר ונותנים ביצועים יותר גבוהים. רובנו, האנשים המקצועיים, יכולים די מהר לחלוק על המצגות האלו בכל מיני נקודות ולהראות שמיקרוסופט מציגה תמונה מעוותת בקשר ליכולות XYZ בהשוואה ל-ABC שהמתחרה מציע.

וכאן מגיע החלק של ה”הנחתה” (והוא קיים במיוחד בחברות) – נציגי מכירות של מיקרוסופט פונים בהתחלה לאנשי ה-IT ואם הם לא מצליחים לעשות מכירה, הם פונים לסמנכ”לים או למנכ”לים כדי למכור להם את המוצרים, ואם הלקוח מבחינת מיקרוסופט הוא חשוב – מיקרוסופט מוכנה “להוריד את המכנס” (סליחה על הביטוי) מבחינת מחירים והבטחות, וכך המפתחים או אנשי ה-IT יכולים לקבל יום אחד הוראה: אנחנו עוברים ל-Azure. כל איש Devops, אינטגרטור ואיש סיסטם רציני יכול להבין מיד את המשמעות: שכתוב ערימות סקריפטים מחדש וכאב ראש ענק ומי שהכי גרוע – העבודה הארוכה והסיזיפית אחר כך, לוודא שהביצועים הם אותו דבר כמו שיש לך כיום. בכל זאת, הוירטואליזציה שמיקרוסופט מציעה לא ממש מרשימה מבחינת Performance (תסתכלו באתר spec וחפשו פתרונות של מיקרוסופט).

אז איך אפשר להימנע ממכה כזו? בכך שאתה מכין מראש מסמך טיעונים שכולל:

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

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

המלצה שלי: תכינו מסמך כזה.

מחשוב ענן–איך אפשר לחסוך?

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

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

המחיר שאותן חברות מציגות נראה נמוך ולאלו שחדשים בתחום הוא נראה לעיתים מגוחך. אמזון מציעה מכונה עם 3.75 ג’יגהבייט זכרון ו-410 ג’יגה דיסק ב-13 סנט לשעה (או 23 סנט לשעה אם זה Windows). זה נשמע כלום, 3.12 דולר ליום, תקציב שתיה קלה למנכ”ל ליום כבר יותר גדול מזה.

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

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

אבל מה קורה אם ה-2-3 מכונות שלך הן מכונות גדולות? (אני מדבר על מכונות עם מעל 4 ג’יגה זכרון ומספר ליבות) – באמזון מכונה עם כמעט 16 ג’יגהבייט זכרון עולה לך כבר 374 דולר לחודש, בלי Storage משותף בין מכונות, בלי תעבורה, בלי כלום. תכפיל את זה ב-2-3 מכונות ואנחנו מסתכלים על מעל $1000 לחודש רק על מכונות וירטואליות, וזה כבר לא כל כך זול.

וכאן – ניתן כבר לחסוך. איך חוסכים? שילוב של ישן וחדש.

ספקים רבים כיום יכולים להציע להשכרה שרתים פיזיים במחירים שהם נמוכים ממה שספקי ענן מציעים עם שרתים וירטואליים. כך לדוגמא ניתן להשיג במחיר של $400 לערך שרת עם 16 ג’יגהבייט זכרון, בסביבות ה-600 להשיג עם 32 ג’יגה בייט זכרון, ובמחיר של 850$ בערך אתה יכול להשיג מכונה עם 64 ג’יגהבייט זכרון. כל מה שתצטרך לשים לב זה שהמעבד הוא חזק (סידרה E56XX או E5 של אינטל לדוגמא – הם מעבדים חזקים)

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

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

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

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

איזה שרות CDN? יש כל מיני. לגוגל יש פתרון, למיקרוסופט יש פתרון, לאמזון יש, ל-Rackspace יש וגם לאחרים יש פתרונות (כמו Cloud Flare, או Rackspace CDN ועוד).

לכל הפתרונות CDN יש מספר דברים משותפים:

  • אם הינך משתמש במערכת CMS (כמו וורדפרס, ג’ומלה, דרופל) – ישנם תוספים לאותן חברות שאתה יכול להתקין בקלות, להזין מספר פרטים ולהתחיל לקבל גולשים דרך מערכת CDN.
  • אין צורך שתיקח מהן שרת או שרתים. מערכת ה-CDN מתממשקת לשרת שלך שישב היכן שתבחר.
  • כל ספק CDN שמכבד את עצמו נותן לך סטטיסטיקות וגרפים כדי שתוכל לראות מי גלש, מהיכן וכו’ (אתה כמובן יכול להמשיך להשתמש בכלים משלך כמו Google Analytics וכו’)

חלק מספקי ה-CDN מספקים חבילות “יעד” (כלומר עד 3 טרהבייט תשלם X, מ-3 עד 6 תשלם Y וכו’) וחלק גובים פר ג’יגהבייט. תצטרך לעשות את החישובים שלך בהסתמך על נתונים קודמים שיש לך.

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

שימו לב: שיטה זו אינה מתאימה לכולם:

  • אם הינך משתמש ב-API להוספת שרתים דינמית, השיטה לא תעזור לך.
  • אם המערכת בנויה בצורה שהיא קשורה למחשוב ענן של ספק כלשהו (מבחינת פיזור עומסים, שימוש ב-Storage משותף חיצוני [כמו EBS]) – תצטרך להשקיע לא מעט כדי לצאת לספק אחר.

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

שרתי VPS, איזון עומסים, וישראל

אצלנו ב”חץ ביז” יש לא מעט לקוחות שיש להם מספר שרתים וירטואליים (מדוע לכל הרוחות חברות קוראות לזה “שרתים וירטואלים” עם י’ אחת? עברית?) עם Load Balancing (אני אקרא לזה LB במהלך הפוסט הנוכחי) וזהו אחד התחומים ששם נמצאת ההתמחות שלנו, ומתוקף זה חשבתי לשתף אתכם הקוראים בעניין שלא תמיד מקבל פתרון ראוי.

אם כיום לקוח יגיע לאינטגרטור רציני ויאמר לו “יש לי אתר גדול, ואני צריך 10 שרתים (בין אם זה פיזיים או וירטואליים – לא רלוונטי לשם הדוגמא) כשחלק יהיו DB, חלק שרתי ווב, חלק שרתי אפליקציה” – אז במרבית המקרים אותו אינטגרטור לכשיקבל את החוזה, ילך לאמזון או לאחת המתחרות שלהם בחו”ל, יקים שרתים (אולי ישתמש בשרות הקמת שרתים נוספים אוטומטית), ישתמש בשרותי Load Balancing ובקיצור – הוא ישתמש ב-API של אותו ספק כדי לבנות פתרון ללקוח.

עד פה הכל טוב ויפה.

אבל מה קורה שהלקוח רוצה פתרון פה מקומית בישראל? יש לכך סיבות:

  • הלקוח מעוניין ב-Latency הכי נמוך שאפשר
  • עקב סיבות משפטיות ובעצת עורכי דינו – הוא רוצה את זה פה בישראל
  • ללקוח “נכנס ג’וק לראש” והוא מתעקש מסיבותיו שלו שהפתרון יהיה כאן בארץ.

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

אם תפנו לספקים שונים בארץ ותציינו כי אתם רוצים X שרתי VPS ו-LB (אני לא מדבר על שרותים יותר מתקדמים כמו HA וכו’) אתם תקבלו הצעת מחיר לא קטנה. כמה לא קטנה? חבר אינטגרטור ביקש עבור לקוח שלו הצעה מספקים שונים. כמה שהוא התווכח עם הספקים השונים (כולל הגדולים), המחיר לא ירד מתחת ל-5000 שקל + מע”מ לחודש על: LB, ו-4 שרתים עם 2 ליבות ו-4 ג’יגה זכרון, דיסקים של 200 ג’יגה ו-100 ג’יגה לאחד מהם.

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

אז מה? האם באמת לפתרון הכולל LB ומפרט כפי שציינתי צריך לשלם 5000+מע”מ לחודש בארץ? כן, אם הלקוח רוצה לשכור 2 מכשירים של F5 מהדגמים המתקדמים + תשלום מופרז על שרתי VPS, אבל אפשר גם אחרת ואפשר לחסוך המון עם מספר נקודות פשוטות:

  • קודם כל, צריך לבדוק על מה הלקוח צריך LB בכלל. האם הוא צריך את זה על שרתי ווב כמו Apache? אם כן, יש מספר פתרונות מבוססי קוד פתוח, טריקים כמו Round Robin ועוד שיטות אחרות כדי לחלק את העומס בין שרתי הווב. חלק מהשיטות מצריכות שרת VPS שיקבל את הבקשות ויפנה, ובחלק מהשיטות אין צורך בכך.
  • שרותי SQL (בין אם זה מבוסס קוד פתוח או סגור) – כאן צריך לבדוק לעומק באיזו שיטה לעבוד. לדוגמא: MySQL מאפשר רפליקציה בשיטת Master/Slave, אך לא כל אפליקציה יודעת לעבוד מול Slave. אם לדוגמא הלקוח רוצה לעבוד עם אפליקציית וורדפרס כאפליקציה וובית ראשית, תהיה בעיה לחבר את הוורדפרס ל-Slave. במקרה של וורדפרס לדוגמא, ניתן להשתמש בתוסף כמו HyperDB.
  • שימוש בפתרונות “זוללי זכרון” כמו memcachd או Varnish – אלו פתרונות שאמנם מצריכות שרתי VPS עם יותר זכרון, אולם מצד שני הם יכולים להתמודד עם כמות גולשים יותר גדולה ובכך לחסוך בעצם כמות שרתים שצריך לשכור.

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

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

ההגנה הכי טובה–ההגנה שלכם

10276894_s

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

נתחיל בשאלה שנשאלת הכי הרבה: על איזה ספק שרתי VPS ניתן לסמוך בעיניים עצומות? תשובתי אולי תפתיע חלק מהקורים: אף ספק. לא בישראל ולא בעולם.

הרשו לי להסביר מדוע.

לא חשוב מי יהיה הספק שאיתו תבחרו לעשות עסקים. בין אם זה ספק “מחשוב ענן”, בין אם זה ספק שרתים וירטואליים (VPS), ובין אם זה ספק שמוכר שרות אחסון אתרים – כולם יבטיחו לכם שהם משתמשים במילה האחרונה של הטכנולוגיה להגנה. “חומת האש הכי חדשה של צ’ק-פוינט? יש לנו!” “חומת האש המפלצתית של סיסקו? קנינו אותה ראשונים”, “אנחנו מבצעים בדיקות שוטפות לגבי נסיונות חדירה”, “יש לנו את מיטב המומחים לענייני הגנה ואבטחת מידע” ועוד הבטחות כאלו ואחרות.

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

לחברת “שוקי הקופץ” יש איש ממש “שפיץ” בכל הנוגע לחומות אש. קוראים לו איציק. איציק לא יושב כל היום על הגדרות של החומות אש, הוא גם מגדיר שרתי לינוקס ו-Windows עבור לקוחות החברה, הוא גם כותב סקריפטים, ואין לו שום כח בעולם להיכנס להגדרות ה-Firewall על כל פיפס של לקוח, אז הוא יוצר משתמש נוסף בחומת האש עבור יוסי, הבחור שמקבל פניות מלקוחות בקשר להגדרות של החומת אש. הבעיה? יוסי לא כל כך מבין מה ההבדל בין TCP ל-UDP, מה זה לכל הרוחות ICMP ומה בעצם צריך להגדיר אם הלקוח שולח בקשה להגדרות פורטים של FTP? פורט 21? רגע, מה זה Passive ו-Active ב-FTP?

אז מה יוסי עושה במקרים רבים? פותח מה שנקרא “ANY ANY”. הלקוח מרוצה? כן, בהחלט. יוסי מבחינתו סיים את המטלה? סיים. עם מה נשארנו? עם כניסה מלאה לשרת, והדבר היחיד שעומד בין פורץ משועמם לבין השרת –הן ההגדרות של השרת. אם הלקוח השאיר SSH פתוח לקבלת סיסמאות בפורט 22 והסיסמא שהלקוח הגדיר היא: !1q2w3e4r – אז הולכות להיות צרות צרורות ללקוח.

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

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

חלק גדול מהקוראים ירים עכשיו גבה “מה אני? מאיפה אני מבין בחומות אש?”, אתה לא צריך להבין, אתה צריך לשכור מישהו שכן מבין, ושהוא יבנה לך את ההגנות.

מצבך ההתחלתי: דמיין לך ששכרת אצל ספק כלשהו מקום לאחסן שרת שלך. קיבלת כבל חשמל, כבל רשת, כתובות IP ו… זהו. יש 0 חוקים בחומת האש שחלים על השרת שלך. זה המצב שאתה צריך לחשוב עליו ולדמיין אותו.

עד כאן יש? מצוין. עכשיו מתחילים השלבים הבסיסיים בהגנה:

  1. יש לך שרת Windows? מצוין. קודם כל תשנה את חיבור ה-RDP לפורט אחר, לא ברירת המחדל (3389). איך עושים זאת? תסתכל כאן.
  2. יש ל-Windows 2008 חומת אש לא רעה (בהשוואה לגרסאות קודמות). כדאי שתיכנס קצת ותראה מה הפורטים הפתוחים מבחוץ פנימה. אתה צריך פינג? לא? בטל ICMP. יש לך כל מיני שרותים שרצים ונותנים פתרון לחשבונות לוקאליים? סגור אותם לכניסה מבחוץ. מוכן להשקיע קצת? חברות כמו MCAFEE מוכרות חומת אש ל-Windows, תחשוב על לרכוש אחת.
  3. נקודה נוספת שרבים שוכחים: לסגור את הפורטים המיותרים גם מבפנים החוצה.מדוע? מספיק שסקריפט כלשהו יוטמע באתרך, הוא ינסה להתחבר לאיזה “מרכז בקרה” של הפורץ, וסביר להניח שזה יהיה בפורט לא סטנדרטי (כמו 6667). חסימת הפורטים לא תמנע מהסקריפט הזה להיות מושתל באתרך (על כך בהמשך), אבל לפחות תמנע מהסקריפט להתחבר ל”מרכז בקרה”.
  4. סביר להניח שהספק יכול להציע לך שרות VPN בתשלום נוסף. לא צריך, יש קוד פתוח. תכיר את OpenVPN שקיים גם ל-Windows. עם OpenVPN תוכל להגדיר לך כתובת פנימית שרק דרכה תוכל להתחבר לשרותים כמו RDP.

יש לך שרת לינוקס? כאן הדברים קצת שונים אבל עדיין לא מסובכים:

  1. מומלץ לשנות את הפורט SSH מ-22 לכתובת אחרת, כדאי לשים לב שהכתובת לא מתנגשת עם כתובות אחרות. בד”כ השינוי מתבצע בקובץ sshd_config. השינוי יחול רק לאחר שתפעיל את השרות. אל תפעיל את השרות מחדש אלא רק לאחר שביצעת את הסעיפים בהמשך…
  2. לא מומלץ לפתוח פורטים כמו של MySQL החוצה! רבים פותחים חיבורים לשרת MySQL החוצה כדי לנהל אותו עם איזה כלי GUI ושוכחים שברירת המחדל MySQL אינו מוצפן. אם אתם זקוקים לחיבור מבחוץ, עשו זאת עם VPN או שתשתמשו בהוראות האלו כדי להעביר את הנתונים עם SSL.
  3. תכירו תוכנה בשם CSF. זוהי תוכנה קטנה ונחמדה שיודעת לשלוט בחומת אש הפנימית של מערכות לינוקס, ויש בה עוד חלקים שיכולים מאוד לסייע כמו סגירה של פורטים לא נחוצים מבפנים החוצה וההיפך, חסימה אוטומטית של משתמשים אחרי שלא הכניסו סיסמא נכונה 3 פעמים, ועוד המון המון דברים נחמדים שיכולים לסייע המון. אם אתם משתמשים בה, אז עשו טובה קטנה ותרמו להם כמה דולרים בפייפאל, הם עושים עבודה מעולה.
  4. אם יש לך דיסק-אן –קי שהולך איתך קבוע או מחשב נייד שלך שהוא ממש צמוד עליך, עדיף לעבוד עם SSH בשיטה של מפתח פרטי/ציבורי ולחסום בקשת סיסמאות. בדרך זו תחסום סקריפטים רבים שמנסים להיכנס דרך SSH לשרת שלך.
  5. גם כאן מומלץ לחשוב לעבוד עם OpenVPN שנכלל בכל הפצת לינוקס.

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

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

עוד נקודה נוספת: רבים סומכים על הגיבוי שספקים שונים מציעים. זו טעות. מה אם מחר נדפקים הדיסקים של הגיבוי שלכם? לא נעים. לכן, מומלץ לבצע snapshot למערכת, לבקש את קובץ ה-snapshot ולשמור אותו אצלכם בצד, ולהשכיר שטח גיבוי שאליו תבצעו גיבוי משלכם שבמקרה חרום הספק ירים לכם מכונה בתולית, תוכלו להטמיע את ה-snapshot ולשחזר גיבויים. מדוע גיבוי משלכם ולא גיבוי מרוכז של הספק? כי אין לכם שום מושג מה מצב הגיבוי, כמה הגיבוי והשרת עצמו מוגנים, וכו’. בגלל זה מומלץ להתקין תוכנת גיבוי משלכם (אנשי לינוקס יכולים פשוט לכתוב סקריפט פשוט לבצע rsync או קבצי tar מוגנים בסיסמא) שישבו בשרת פיזי אחר

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

בהצלחה