קטגוריה: שרתים

הגנה פשוטה נגד 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 root@ip-address כאשר ה-ip-address זו כתובת ה-IP של השרת הפיזי). אם תתבקש להכניס שם משתמש, הוא כמובן root והסיסמא היא אותה סיסמא שבחרת מקודם. הקש אותה ואם קיבלת את סימן ה-# אז אתה יכול לנשום לרווחה, הכל תקין.
  • חזור ל-vCenter, לחץ על כפתור ימני על השרת הפיזי, ובחר Exit Maintenance mode ולאחר מכן הפעל את המכונות הוירטואליות.
  • ברכותיי, לא צריך לפרמט את השרת. אל תשכח לחזור ל-Security Profile ולבטל את שרות ה-SSH (כמו שהפעלת רק שהפעם בחר Stop).

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

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

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

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

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

נתחיל בשאלה שנשאלת הכי הרבה: על איזה ספק שרתי 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 מגהבייט זכרון זה מתכון בדוק שהלקוח יהיה לא מרוצה ובמשך הזמן הוא יתלונן או יעזוב, אז מדוע להציע לו דבר כזה מלכתחילה?

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

אירוח שרת יעודי–כדאי?

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

מה קרה? החלטתי לחסל את העסק? להוריד את האירוח? לא ממש

נתחיל עם משהו פשוט: לא חשוב מה השרת שיש לך, חשובים הדברים הבאים:

  • מה גודל השרת ב-U. המידות הם 1U, 2U והלאה
  • כמה נקודות חשמל אתה צריך לשרת? 1? 2? (2 במקרה שיש לך RPS כלומר Reduntant Power Supply)
  • כמה כתובות אתה צריך? (אתה צריך לפחות כתובת אחת חיצונית לשרת, אך אם יש לך מודול שליטה מרחוק כמו iDrac/ILO/IMM/IPMI בהתאם ליצרן – תצטרך כתובות IP נפרדת לכך)
  • כמה חשמל השרת שלך צורך? אם יש לך שרת עם 4 מעבדים (לא ליבות)  כשכל אחד מהמעבדים צורך המון והשרת שלך עמוס נון סטופ, תהיה לך תוספת למחיר בכל חודש בהתאם לצריכה.

כיום, המחירים בארץ לאחסון שרת 1U נעים בין 250-450 שקל (לא כולל מע”מ, בד”כ לא כולל כתובות IP נוספות, הזנות חשמל נוספות וכו’, תלוי בספק), ובמחיר הזה לא תמיד שווה להכניס שרת משלך לחווה.

מדוע? יש לכך מספר סיבות:

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

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

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

  • ודא כי הספק מתחייב לרוחב פס סימטרי יעודי משלך (ללא טריקים של הכפלה, הווה אומר אם אתה מקבל 10 מגהביט סימטרי, אז תוכל להעלות או להוריד 10 מגהביט, יש ספק או 2 שמשתמשים בטריקים לאמר “10 מגה” בשעה שהם מתכוונים ל-5 מגה והם מחשבים בנפרד את ההעלאה או הורדה. אצל ספקים כאלו לא מומלץ לארח). ודא כי זה מה שהינך מקבל ושהספק מתחייב שרוחב הפס שלך יהיה פנוי רק לשימושך.
  • אם יש לך שרת עם 2 חיבורי חשמל (RPS), ודא כי אתה מקבל הזנה נפרדת לכל ספק, כך שאם יש תקלה בהזנה אחת, השרת שלך יקבל חשמל מההזנה הנפרדת.
  • אם אין לך בשרת מודול לשליטה מרחוק (IPMI/iLO/IMM/iDrac) הוסף זאת לשרת שלך ואל תסמוך על KVM של הספק המארח. לעיתים תצטרך בשעת לילה מאוחרת (שהספק כבר לא עונה לטלפונים או שבחווה עסוקים) להתחבר מרחוק לפתור תקלה וכניסת SSH או RDP לא אפשרית – ואז השקעה קטנה זו (בסביבות 50-100 דולר, תלוי בלוח אם, בלוחות רבים זה כבר מובנה) תחזיר את עצמה ותוכל לטפל בתקלה במהירות.
  • ודא כי בחבילה כלול חיבור רשת נוסף לאותה שליטה מרחוק עם כתובת IP וודא כי החיבור מוגדר.
  • אם יש לך מספר שרתים פיזיים (או מספר שרתי VPS) ויש לך איש טכני טוב, מומלץ שתנהל בעצמך חומת אש. כך תחסוך לעצמך זמן אם יש תקלה ואתה צריך לחסום דברים מסויימים. לשם כך עליך לבקש כתובות מ-2 סגמנטים שונים (סגמנט אחד חיצוני שישמש כ-WAN וסגמנט אחד לשרתים, שישמש כ-LAN).
  • אם אתה מחליט לשכור שרתים לטווח ארוך, נסה למצוא דיל שלאחר תקופה (נאמר שנתיים) אתה מקבל בעלות על השרתים שאתה משכיר. אין הרבה ספקים שנותנים זאת, אך שווה לחפש את זה, כך בעצם השכרת השרת הופכת ל-Leasing וההשקעה מחזירה את עצמה לאחר שנתיים.
  • ודא כי שרותי אצבע (לחיצת Reset) כלולים במחיר חבילת האירוח.
  • אם אין לך ידע טכני מספק לניהול שרת פיזי (או ניהול שרתים וירטואליים בנושא הקמה וכו’) בקש במחיר החבילה תמיכה בסיסית או מלאה, בהתאם לצורך שלך.

בהצלחה

Exit mobile version