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

בעלי אתרים בינוניים ומעלה (מעל רבע מיליון יוניקים לחודש) מעדיפים כיום במקרים לא מעטים להשתמש במחשוב ענן מחברות כמו אמזון, 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]) – תצטרך להשקיע לא מעט כדי לצאת לספק אחר.

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

מה לבקש מבוני אתרים?

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

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

להלן ההמלצות:

  • לעבוד תמיד עם פלטפורמות ידועות ומוכרות ולא להתפתות לכל מיני פלטפורמות נישה שהיום הם כאן ומחר אף אחד לא יודע מה קורה איתן. הפלטפורמות המוכרות הן: WordPress, Joomla, Drupal. הפלטפורמות הנ”ל מפותחות ומתעדכנות תדיר, ובעיות אבטחה בהן נסגרות במהירות, והן מספיק גמישות לתת פתרונות מבוססי תוכן החל מאתר קטן ועד לבלוגים ענקיים (CNN לדוגמא משתמשים בוורדפרס לבלוגים שלהם).
  • להשתמש רק בגרסאות האחרונות היציבותשל הפלטפורמה. לא מעט בוני אתרים מנסים לחסוך זמן בכך שהם מעתיקים ממערכת אחרת שהם בנו, וכך הלקוח יקבל גירסה ישנה עם חורי אבטחה שינוצלו על ידי כל מיני ילדים ופורצים למיניהם. נכון להיום הגרסאות האחרונות של הפלטפורמות הנ”ל הן:
    • ב-Joomla נכון לכתיבת שורות אלו הגירסה היציבה האחרונה היא 2.5.7
    • ב-Wordpress נכון לכתיבת שורות אלו הגירסה היציבה האחרונה היא: 3.4.2
    • ב-Drupal נכון לכתיבת שורות אלו הגירסה היציבה האחרונה היא: 7.16
  • יש לציין בהסכם בין הלקוח לבוני האתר כי אסור שבוני האתר ישנה קוד בפלטפורמה. לצערי רבים מבוני האתרים מנסים “לחתוך פינות” ולשנות קוד בתוך הפלטפורמה. הבעיה? שדרוג גירסה (דבר שצריך לבצע לפחות אחת לחודש או חודשיים) יגרום לאתר לא לעבוד. בונה האתר, אם יש לו צורך בשינוי, צריך לכתוב או להשתמש במודולים חיצוניים ש”מתלבשים” על הפלטפורמה. אותו הדבר לגבי עיצובים – אם יש צורך בשינוי בעיצוב, השינוי צריך להיות בקוד העיצוב בלבד ולא בפלטפורמה.
  • בכל הנוגע לעיצובים, ההמלצה שלי היא לרכוש עיצוב מאתרים בחו”לולשלם לבונה האתר על תרגום/”גיור” העיצוב לעברית/ימין-שמאל. הסיבה לכך היא שלצערי לא מעט מבוני אתרים משתמשים בעיצובים שהם השיגו בעבר (בין בצורה חוקית ובין שלא) ובאותם עיצובים יש חורי אבטחה. כאשר רוכשים עיצוב מאתרים גדולים בחו”ל (בד”כ הסכום הוא בסביבות כמה עשרות דולרים), מקבלים חינם שנה של עדכונים לעיצוב, ובאתרים רבים, ניתן באותו מחיר לקבל מספר עיצובים, כך שאם אתם הלקוחות יש לכם מספר אתרים, תוכלו להוריד עיצוב שונה לכל אתר.
    • אם הזכרתי כבר עיצובים, כדאי לבחור עיצובים שתומכים בשפות נוספות (רבים מהעיצובים תומכים בכך, חלקם גם תומכים באתרים עם ימין-שמאל כמו עברית, ערבית, פרסית וכו’), כך שמתרגם העיצוב יצטרך לכתוב קובץ תרגום פשוט, וקובץ CSS למיצוב/עיצוב אלמנטים. במקרה ויהיה צורך בעדכון, ניתן יהיה לעדכן בקלות ויהיה צורך רק בהחלפת קובץ CSS לאחר העדכון.
  • בכל הקשור לחנויות, תוכנת OsCommerce כבר מזמן “מתה” (גירסה 2.3 לא עודכנה זמן רב וקיימות לה פריצות רבות, גירסה 3.0 נמצאת בפיתוח זמן רב והם לא ממליצים להכניס אותה לשימוש בחנויות פעילות או חדשות). יש פלטפורמה בשם Magnto בגירסה חופשית או מסחרית, אולם כיום ישנם תוספים רבים שיודעים להתלבש על הפלטפורמות שהזכרתי לעיל שנותנות פונקציונאליות זהה. לא מומלץ להשתמש בפתרונות קנייניים שבונה האתר כתב לדוגמא, הואיל ושימוש בפתרון כזה “כולא” אותך עם הפתרון הנ”ל ללא אפשרות לבחור פתרון אחר.
  • הסכם עדכונים: מומלץ לסגור בהסכם עם בונה האתרים כי אחת לחודש הוא יכנס לחשבונכם אצל הספק בו הינכם מאחסנים את האתר שלכם כדי לעדכן את כל מה שצריך עדכון: פלטפורמה, תוספים/מודולים,חבילת עיצוב. ללא הסכם כזה, אתם חשופים לפריצות שיתגלו בהמשך הדרך ולהפסד לקוחות והכנסות אם האתר יפרץ (שחזור של הספק אינו מהווה פתרון, ושום ספק אינו מקבל על עצמו לבצע עדכונים אלו ללקוח).
  • בחרו רק בונה אתרים שנותן להם באחריות אבטחה: ב-99% מהמקרים שאתר נפרץ, הבעיה אינה נמצאת בתשתית של הספק אלא ב-חורי אבטחה שהתגלו לאותה פלטפורמה שהאתר שלכם משתמש. לצערי לא מעט בוני אתרים מנסים להתחמק בכך שהם מאשימים את הספק וכל העולם, אך אינם בודקים את הקוד שלהם (או שהם אינם מבינים מספיק בקוד או באבטחת קוד). ראיתי מקרים בעבר שבונה אתרים המליץ ללקוחותיו להשתמש בכל מיני פתרונות CDN (טכנולוגיה שמפיצה את האתר שלך בשרתים אחרים בעולם הקרובים גיאוגרפית למשתמשים) כפתרון אבטחה, אולם פתרון זה ברוב המקרים כלל לא עוזר אם יש חורי אבטחה בקוד הפלטפורמה/מודולים/תוספים/עיצוב.

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

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

דברים שלא מומלץ לעשות עם ספקים

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

הנה מספר דוגמאות מה לא מומלץ לרכוש אצל ספקי אחסון שרתים (בין אם שרת וירטואלי [VPS] ובין אם זה שרת פיזי):

  1. רכישת ציוד פיזי (בין אם מדובר בנתב, מתג, HUB או שרת מכל סוג שהוא) לא לרכוש את זה מספקי אחסון (כולל שלושת הספקים הגדלים בארץ). לא חסר סיבות מדוע לא לרכוש: מחיר גבוה יותר מכל הצעה נורמלית שתקבל בשוק, במחיר ב”דולרים” כאשר שער הדולר אצלהם הוא 4.1 שקלים ומעלה, ריבית גבוהה מאוד שהם לוקחים על העיסקה, וכמובן – אינך יכול להוציא את הציוד החוצה עד שלא תשלם.
  2. רכישת שרות לציוד: רכשת ציוד חכם (נתב, שרת, מתג מנוהל וכו’) ואתה צריך שרות עליו? רכוש את השרות מהמשווק המורשה או משווק מקביל. הדבר האחרון שאתה צריך זה שסטודנט שלא מבין בציוד יתחיל לטפל בו ובטעות ימחוק חצי מההגדרות או יעשה נזק שישבית זמנית את הציוד. למשווקים המורשים יש אנשים שמבינים בחומרה ובתוכנה של הציוד וברוב מוחץ של המקרים, המחיר יהיה יותר זול אצלהם.
  3. יעוץ בכל הקשור לרכישת ציוד: אם אתה צריך לרכוש ציוד עבור העסק שלך או עבור האחסון שלך שנמצא בחווה כלשהי, קח יעוץ עצמאי שיקשיב לצרכים שלך ויתן לך מספר הצעות לציודים שיתאימו לך או לפתרון שיתאים לך. אישית, ראיתי כבר מספר מקרים בהם ספקים שונים יעצו ללקוחות לרכוש ציודים שפשוט לא התאימו להם. כך לדוגמא, חבר טוב שרצה לאחסן גיבוי של האתרים שלו, קיבל הצעה חמה לרכוש ציוד של Netapp, בשעה שכל מה שהוא היה צריך זה דיסק קשיח נוסף שלא במסגרת ה-RAID בשרת שלו (מאחר וזה רק מאחסן גיבוי יומי).
  4. יעוץ בקשר לשרתים (וירטואליים או פיזיים): גם כאן, לספקים רבים אין מספיק ידע טכני לדעת מה להמליץ. האם הלקוח צריך שרת וירטואלי עם 2 ג’יגהבייט זכרון, או שהלקוח צריך תכנון רציני הכולל מספר שרתים, מפזר עומסים, שרתים ב-Front וב-Back? אישית, ראיתי מספיק דוגמאות שללקוחות נמכרו חבילות קטנות מדי או גדולות מדי מבלי להתייחס כלל לאפליקציות שהלקוח משתמש, כמות הגולשים המוערכת וצרכים נוספים וכך יוצא שהלקוח משלם יותר מדי או שהוא מקבל משהו חלש מדי לצרכיו.
  5. משהו נוסף שקשור לסעיף 4: תכנון לפני שניגשים לבקש הצעות. לקוחות פוטנציאליים רבים פונים לכל מיני ספקים לבקש הצעות מבלי שהלקוח עצמו יודע מה הוא צריך, מה שמבטיח שבהרבה מקרים הוא שוב ישלם יותר מדי או יקבל פחות מדי. לכן עדיף לקחת מישהו מקצועי, לשלם לו על פגישה עם הלקוח הפוטנציאלי, שישמע מה הוא רוצה להריץ ושיכתוב ללקוח מפרט מה הוא צריך לבקש מספק.

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

בהצלחה

טיפ: איך למנוע “צינור שבור” (SSH)

הנה בעיה שאנשים שלפעמים מתחברים למערכות לינוקס (או Solaris או FreeBSD/מק) נתקלים בה לעיתים קרובות: אתה מתחבר ב-SSH לשרת מרוחק.זה יכול להיות שרת VPS שלך, שרת יעודי, התחברות ללינוקס בבית וכו’. אתה עושה את העבודה שלך ואז מישהו צריך את תשומת ליבך לכמה רגעים. זה יכול להיות טלפון, הבוס קורא לך, יש תקלה אחרת, ובקיצור 1001 סיבות.

לאחר שטיפלת בעניין אתה חוזר לסשן SSH שפתחת ו… הוא לא מגיב או מוציא הודעה מעצבנת Broken Pipe. האפשרות היחידה שיש לך – להתחבר מחדש, ו”להרוג” את החיבור הקודם אם אתה בדיוק עורך קובץ ב-VI או EMACS וכו’.

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

אז איך פותרים זאת? יש 2 אפשרויות:

האפשרות הראשונה: שרת בניהולך. אם יש לך הרשאות sudo להתקין דברים ולהגדיר ברמת root, אז תוכל לשנות את קובץ etc/ssh/sshd_config ולהוסיף שורה:

ClientAliveInterval 60

לתוך הקובץ הנ”ל, לשמור, להפעיל שרות ssh (או sshd, תלוי בהפצת לינוקס) מחדש והבעיה תיפתר.

אבל מה קורה אם יש לך את הבעיה מול כל מיני שרתי לינוקס, או שיש לך חיבור אינטרנט גרוע/איטי, או שאין לך בכלל הרשאות לשנות את ה-SSH בשרת?

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

בתוך תיקיית המשתמש שלך, אמורה להיות תיקיה בשם ssh. (שימו לב לנקודה לפני המילה ssh). כנס לתוך תיקיה זו וצור (אם לא קיים) קובץ config, והכנס את השורות הבאות:

Host *
ServerAliveInterval 300

שמור וצא מהעורך.

כעת כל מה שעליך לעשות זה להתחבר מחדש, ומעתה בעיות החיבור יפסקו.

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

שרתים יעודיים או שרתי VPS?

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

רבים נוטים לחשוב שהתשובה לשאלה זו היא פשוטה: אם יש לך שרת פיזי בתצורת פיצה כמו השרת בתמונה למעלה, ואתה רוצה לארח אתר עם המון תוכן והרבה גולשים, שרת שיצטרך לפחות 4 ג’יגה זכרון, מספר ליבות וכמות תוכן גדולה, אז עדיף לך לשלם בין 250-450 שקל (תלוי בספק), להוסיף עוד קצת סכום על רוחב פס מכובד – ולארח את השרת אצל אחד הספקים בארץ. אחרי הכל, במחיר ממוצע של 350-400 שקל, אתה תקבל VPS שיתן לך רק חלק מהביצועים ששרת פיזי נותן לך.

לעניות דעתי, זה לא מדויק.

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

השרת שבתמונה לעיל שאני בונה, אינו שרת ממוצע. יהיו בו 64 ליבות, 256 ג’יגהבייט זכרון, ו-8 טרהבייט ב-SAS (לפני RAID חומרה כמובן, אחרי ה-RAID זה ירד ל-5.5 טרהבייט). כלומר זה לא ממוצע שספקים שמים עבור הלקוחות שלהם. בד”כ השרת שיש עבור לקוחות עבור שרותי VPS מורכב מ-2 מעבדים בעלי 4 ליבות (במקרים של ספקים עם פתרונות OpenVZ/Virtuozzo ישנים – 2 ליבות פר מעבד), 8 או 16 (בחלק מהמקרים 32) ג’יגהבייט זכרון, בחלק מהמקרים זה 2 דיסקים בתצורת RAID חומרה (שימו לב, חלק מהספקים מתקמצנים ומשתמשים ב-RAID תוכנה שנותן ביצועים נמוכים ואינו ידוע באמינותו!). יש כאלו שישתמשו בדיסקים SATA ויש כאלו ב-SAS. כל ספק והעדפותיו.

אם יש לך שרת פיזי ישן (לדוגמא: 2 מעבדי Xeon 3XXX ו-4 ג’יגהבייט זכרון עם דיסקים של 70 ג’יגהבייט), הביצועים שלו יהיו נמוכים בהרבה בהשוואה לכל שרת מהשנתיים האחרונות. הטכנולוגיה השתנתה, דברים יותר מהירים בהרבה, למעבדים יש Cache גדול יותר, ועוד לא דיברנו על עניין תחזוקת החומרה (שום ספק לא יחפש עבורך ויחליף לך חלקים בשרת פיזי שלך, כלומר אם אין לך חוזה שרות, השרת שלך מושבת עד שתבוא לחווה לתקן אותו).

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

אך אז מתעוררת בעיה אחרת מבחינת גדילה: האתר שלך מאוד פופולרי, כמות הגולשים גדלה ואתה מתחיל למצוא שיש לך צוואר בקבוק במקומות שונים. זה יכול להיות בדיסקים, בביצוע השרת הוירטואלי ואולי במקומות אחרים. אתה יכול כפתרון זמני להרים עוד 2 מכונות וירטואליות (אחת שתשמש כשרת Web משנית ואחת שתשמש כ-Load Balancer), אך זהו פתרון לטווח הקצר. תצטרך עוד שרתים, בין אם פיזיים או וירטואליים. שרת פיזי חדש יעלה לך בין 12-18 אלף שקל (תלוי בתצורה), ולא בטוח שהוא יחזיר את ההשקעה שלו (אם לדוגמא קם לאתר שלך אתר מתחרה ש”סוחב” גולשים מהאתר שלך).

לכן, כדאי לעשות את השיקולים הבאים, בהם לכל צד יש לו פתרון אחר:

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

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

בהצלחה

שרתי 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 שרתים ומעלה, המחירים ישתנו באופן ניכר.

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

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

נתחיל בשאלה שנשאלת הכי הרבה: על איזה ספק שרתי 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 מוגנים בסיסמא) שישבו בשרת פיזי אחר

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

בהצלחה

VPS או יעודי?

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

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

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

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

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

ב-VPS המצב שונה: השרת הוא וירטואלי וגם אם השרת יעלה באש, ניתן לקחת את הדיסקים ולהעביר לשרת פיזי אחר ולהפעיל את השרתים הוירטואליים מחדש, או לחלופין, אם החומר שמור על מערך RAID-1 חומרה לדוגמא, ניתן לקחת דיסק אחד, לשלוף ממנו את קבצי השרת הוירטואלי, להעתיק אותם לשרת אחר שפועל ולהפעיל את השרת. ה-Downtime במקרים כאלו אצל ספק רציני יהיה בין שעה לשעתיים, הרבה פחות מ-24 שעות בהשוואה לשרת פיזי.

אם אתה צריך את כל הכח שהשרת יכול להציע לך ולא אכפת לך שהשרת יהיה 24 שעות למטה, אז במקרים כאלו עדיף לשכור שרת פיזי ולא VPS.

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

המחיר הוא רק חלק מהמשוואה

מדי פעם מבקרים אצלנו באתר של “חץ ביז” לקוחות פוטנציאליים שמעוניינים בחבילות שרתי VPS שונים (בארץ או בחו”ל) ותוהים מדוע המחיר שלנו גבוה בהשוואה למתחרה X. מבחינת הלקוח, כשהוא משווה בין חבילות, אצלנו חבילה מסויימת כוללת ליבה ו-20 ג’יגהבייט דיסק במחיר של 200 שקלים ואצל המתחרה חבילה עם דיסק פי 3 בגודל ועוד ליבה עולה רק 100 ומשהו שקלים. מבחינה מספרית, עדיף כבר לסגור עם המתחרה עיסקה, הלא כן?

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

אבל, וכאן ה-אבל הגדול נכנס – זה רק תיאורתית.

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

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

כמה להרוויח? זה משתנה בין ספק VPS לספק מתחרה, אך אם ניקח שרת ממוצע שיש בו 32 ג’יגהבייט זכרון, 8 ליבות (כלומר 2 מעבדי אינטל XEON), ו-2 דיסקים של 500 ג’יגהבייט ב-RAID-1 (או 4 דיסקים של 500 ג’יגהבייט ב-RAID-10), אז סביר להניח שהרווח (ברוטו) הרצוי נע בין 1400 ל-3000 שקל פר שרת לחודש (מבוסס על חישוב של 7 שרתים וירטואליים קטנים, חלק מהליבות מחולקות וירטואלית במחיר ממוצע של 200 שקל לחודש). המציאות היא כמובן שאצל רוב הספקים יהיו הרבה יותר מ-7 מכונות פר שרת, משהו בכיוון ה-15 מכונות, כך שמגיעים ל-3000 שקל.

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

כלומר אותו לקוח שמשלם את ה-100 שקלים, בעצם מכניס את עצמו לתוך שרת עמוס מלכתחילה ובעצם הספק “בונה” על כך שהלקוח לא ישתמש במשאבים מרובים או בכל הדיסק, כי אם 15 לקוחות ישתמשו ב-60 ג’יגהבייט דיסק שהוקצה להם וירטואלית, הדיסק הקשיח יסתיים מהר מאוד ולקוחות בעצם “יתקעו”, כי בסופו של דבר הוירטואליזציה במערכת רק “רשמה לעצמה” שללקוח מגיע 60 ג’יגהבייט דיסק והיא מדמה דיסק כזה, אבל ברוב המקרים היא מקצה חלק מאוד קטן שגודל ככל שהלקוח משתמש (מה שנקרא Thin Provisioning) בדיסק ובשרת. מבחינת ביצועים, סביר מאוד שהלקוח יסבול אם המערכת שלו תדרוש משאבים רציניים וגם הלקוחות האחרים בשרת צריכים משאבי מעבד רציניים.

כך יוצא שלקוח שרצה לחסוך, “משלם” בעצם בביצועים של משאבים שונים בשרת.

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

  • בדוק עם הספק כמה ליבות יש בשרת הפיזי ותחשוב על החישוב שציינתי לעיל. האם באמת אתה מחפש להיות “כלוא” בתוך שרת שמשרת לקוחות רבים נוספים ושלא יתן לך את הביצועים אותם אתה צריך לכשתידרש לכך?
  • מה בעצם הם צרכיך? אם אתה מחפש בעצם רק FTP או rsync לשמור נתונים בגודל כולל של 30 ג’יגהבייט לדוגמא, אז כח העיבוד אינו משנה, מה שחשוב הוא רוחב הפס ושיש באמת מקום מספיק בדיסק להכניס את התוכן שלך, כך שבדיקה פשוטה שלך יכולה לתת תשובות בכך שתשכור את החבילה מאותו ספק ואם לא קיבלת את מבוקשך מבחינת רוחב פס לדוגמא, הרי ששמורה לך הזכות לקבל את כספך תוך 14 יום.
  • אם יש לך אתר חשוב שדורש משאבים כי מגיעים אליך מאות עד אלפי גולשים, סביר להניח שהחסכון שלך יעלה לך בביצועי מערכת גרועים עד מצב שגולשים לא יוכלו להיכנס לאתר שלך, ואז החסכון הזה הופך עבורך להפסד כספי.

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

בהצלחה

עוד דוגמא להטעיית לקוחות

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

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

היום ראיתי הודעה מעניינת. הנה המודעה:

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

  1. שרת יעודי אומר שאם אתה בא אליי ושוכר ממני שרת יעודי, אתה שוכר ממני ברזל פיזי שלם. במקרה הנ”ל מדובר על שרת עם מעבד אחד ומתוכו אתה מקבל ליבה אחת, כך שאתה לא מקבל שרת יעודי, אתה מקבל שרת וירטואלי ויש הבדל ענק בין שרת וירטואלי לשרת יעודי – במחיר, בביצועים ועוד.
  2. הנה נקודה שרבים טועים בה: חיבור SAS לא אומר בהכרח שזה חיבור מהיר יותר. SAS הוא בסופו של דבר צורת חיבור ופרוטוקול העברת נתונים בשרשור בין דיסקים לשרת ובין חיבור דיסקים חיצוניים במארז (כגון JBOD, טייפים וכו’). המהירות עצמה תלויה מאוד בדיסק עצמו – מה מהירות סיבובי הפלטות (RPM) בדיסק, זכרון חוצץ בדיסק (Cache) ועוד. ערימה של דיסקים SAS שמחוברים בשרשור יכולה לתת ביצועים מעולים, אולם אם נשים דיסק SAS אחד ונשווה אותו לדיסק בחיבור SATA-3 – שניהם יתנו פחות או יותר את אותה מהירות.
  3. vMotion אינו חלק משרידות והוא אינו מנגנון שרידות חומרה. vMotion מאפשר להעביר מכונה וירטואלית משרת לשרת מבלי שצריך לכבות אותה, אך לשם כך אין צורך בשום דבר זולת עוד שרת נוסף שאפשר להעביר אליו את המכונה הוירטואלית, וזהו אינו מנגנון שרידות. מנגנונים שהם כן מיועדים לשרידות הם דברים כמו Fault Tolarence או High Availability לדוגמא.

עוד נקודה אחת שלדעתי היא בעיה שקיימת אצל ספקים רבים בארץ ובעולם: מוכרים שרת וירטואלי עם כמות זכרון קטנה ומוכרים לו Windows 2008: מבחינה טכנית, Windows 2008 מחייב במינימום ההכרחי לפחות 1 ג’יגהבייט זכרון וזה עוד לפני שמתקינים עליו IIS, SQL ועוד, כלומר כדי ששרת יגיש אתרים (גם כאחסון משותף קטן), יש צורך בלפחות 2 ג’יגהבייט זכרון. למכור ללקוח שרת עם 512 מגהבייט זכרון זה מתכון בדוק שהלקוח יהיה לא מרוצה ובמשך הזמן הוא יתלונן או יעזוב, אז מדוע להציע לו דבר כזה מלכתחילה?

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

Exit mobile version