קטגוריה: יעוץ VPS

יעוץ בנושאי VPS, שרתים וירטואליים, וירטואליזציה, שרתים יעודיים ועוד

הדרך ל-LAB משלי (פרק ראשון)

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

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

מה מטרות ה-LAB שלי? יש לה כמה מטרות:

  1. התנסות בגירסאות חדשות של הפצות לינוקס
  2. הפעלה ולימוד כל מיני פרוייקטים בקוד פתוח
  3. שחזור בעיות שיש ללקוחות שלי ומציאת פתרונות להן
  4. תרומה לקהילה – בניית Nightly Builds לכל מיני פרוייקטים מבוססי קוד פתוח והעלאתם לאותם אתרים בחזרה לשם הורדה ציבורית
  5. לימוד דברים חדשים בכלל

אתחיל במשהו שלא קשור ישירות למחשבים אלא לאחסונם. היו מספר אנשים שהציעו לי לפנות לאחת ממפעילי ה-Data Center ולקחת שם חצי ארון או ארון, ואז כל פעם שיש לי ציוד שאני צריך להשתמש בו, להתקין אותו שם ולפעול מרחוק. הבעיה? המחיר. חישוב סולידי שלי לכמות ה-U שאצטרך בארון מגיע בין 12U ל-16U, מה שאומר שצריך להשכיר לפחות חצי ארון. עלות השכרת חצי ארון? לא פחות מ-2500 שקל לחודש. 

לעומת זאת, אם נחשב תצרוכת חשמל של 2 שרתי Storage, עוד 4 מחשבי דסקטופ שישמשו כשרתים, מתג ואולי עוד מחשב אחד, נקבל סכום נמוך בהרבה. קילוואט שעה נמכר כיום הוא 63.76 אגורות (כולל מע"מ). נניח שאשתמש ב-3 קוט"ש (נניח פרוע מאוד, המספר שסביר שיהיה אצלי הוא בסביבות 2 גג). אז נכפיל 3 כפול 65.76, יוצא 197.28 אגורות. נכפיל את זה ב-744 (שזה 24 שעות כפול 31 ימים בחודש), ונמיר לשקלים, יוצא 1467.76 שקל. נחזור למציאות ששם אשתמש ב-2 קוט"ש לשעה גג, יוצא 978 שקל, בערך שליש מעלות השכרת ארון בחוות שרתים כלשהי. כך זה כואב פחות בכיס.

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

כמה מילים על 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, צפו להתקפת אנשי מכירות עליכם השנה 🙂

טיפ ל-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 היכן שהוא  Smile

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

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

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

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

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

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

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

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

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

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

בהצלחה