תכירו: Red Hat Storage One

חברת Red Hat הכריזה אתמול על פתרון חדש לסטורג' לחברות שנקרא Red Hat Storage One. הפתרון עצמו הוא די פשוט: אתה קובע פרמטרים מסויימים, אנחנו אומרים לך איזו מערכת יכולה לתת לך את מה שאתה רוצה ומוכרים לך אותה אין צורך ברכישת רשיונות נוספים. אתה רוכש בעצם מחברת Red Hat – ברזל מוכן. הקץ להתקנות ו-1001 קונפיגורציות וכך זה נראה (לחצו להגדלה):

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

אז רד-האט מוציאים את Red Hat Storage One כפתרון סטורג'. זהו הפתרון הראשון ובהמשך יהיו פתרונות נוספים שלא מבוססים על GlusterFS אלא גם על Ceph, וכאן בד"כ נמצאת הבעיה בד"כ – לדעת את ההבדלים בין GlusterFS ל-Ceph ומה מתאים למה (ולא, הם לא מתאימים לכל הצרכים).

בוא נסתכל לשם הדוגמא בכל סטורג' קנייני בינוני. סביר להניח שאותו פתרון סטורג' יתן לך את כל מה שתרצה. רוצה להקים LUN ל-iSCSI? אהלן. שיתוף קבצים? שלם רשיון ויש לך CIFS. רוצה NFS? שוב, רשיון – ויש לך את זה. רוצה snapshots? אולי clones? זה בפנים. רוצה לגבות את הסטורג'? תצטרך תוכנה יעודית – אבל זה אפשרי. רוצה Cluster לסטורג'? זה אפשרי, תכין צ'ק שמן :).

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

  • גישת קבצים – CIFS או NFS – מערכת GlusterFS בנויה כולה על גישת קבצים ואת זה היא יודעת לעשות בצורה מהירה (במיוחד אם הכנסת כרטיס PCIe ל-Nodes עם 3DXpoint של אינטל). צריך Cluster של CIFS או NFS שגם יכול לגדול? GlusterFS הוא הפתרון. אם תנסו את Ceph ל-CIFS או NFS, תקבל בערך 50% פחות בביצועים מהסיבה הפשוטה ש-Ceph עובד מבפנים על Object Store וכך הוא מאחסן הכל, כך שכל גישה לקובץ מצריכה מהמערכת "להרכיב" את הקובץ מאובייקטים ולהגיש אותו, ולפני כן על ה-Client לברר דרך אחד משרתי ה-MDS איפה בכלל הקובץ נמצא, איזה Node זמין וכו', כך שאם אנחנו צריכים להעתיק 1000 קבצים – עשו את זה לקראת היציאה מהעבודה באותו יום, זה יקח זמן.
  • Block Storage. בסטורג' קנייני עניין ה-iSCSI ו-LUN מבוצע בד"כ ברמת חומרה + שימוש ב-NVRAM, כך שהביצועים מאוד גבוהים. ב-GlusterFS זה אפשרי, אבל הביצועים לא יהיו גבוהים כי המערכת לא מכוונת לעשות את זה (אבל למי שמתעקש – זה אפשרי אך עדיין תצטרך באמצע מכונה "מתווכת"). ב-Ceph לעומת זאת גישת Block Storage היא אפשרית בהחלט וזה עובד מעולה, במיוחד אם משתמשים במערכת OpenStack למכונות וירטואליות וקונטיינרים (או Swift). מצד שני יש תמיכה ב-iSCSI אבל שוב, יש צורך ש-2 מכונות (בשביל HA) שיבצעו המרה מ-Raw Block Device ל-iSCSI החוצה.
  • סטורג' לקונטיינרים או Object Store – כאן Ceph מנצח מבלי להתאמץ אפילו. הבסיס העיקרי של Ceph לכל הקבצים הם אחסון אובייקטים, כך שאם החברה רוצה להקים אחסון מדמה S3 כחלק מפתרון ל-OpenStack – אז Ceph נותן פתרון מעולה. גם כאן ל-GlusterFS יש פתרון אבל אם רוצים משהו גדול או ענק לאחסן מיליוני אובייקטים – Ceph עדיף.
  • פתרון Hyper Converge המשלב את הסטורג' יחד עם מכונות וירטואליות. כאן התשובה פשוטה: GlusterFS. מערכות Ceph צריכות להיות מוקמות על שרתים פיזיים נפרדים (שזה מה שהם יעשו בלבד) ו-Ceph אינו פתרון Hyper Converge (וכן, בדקתי, זה הזכיר לי את מהירות טעינות משחקים מקלטות בקומודור 64…).

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

כמה מילים על פתרון סטורג' (קוד פתוח) משולב

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

הבעיה בד"כ היא במחשבה או בתכנון מעבר. אם לדוגמא יש לכם פתרון וירטואליזציה של VMWare ותרצו ליישם את VSAN, ההשקעה תהיה גבוהה. על כל שרת ממוצע תצטרכו לשלם 5000$ וזה עוד לפני הדיסקים והתצורה היחודית שיש צורך ב-VSAN (על כל 2 דיסקים מכניים או SSD בינוניים, דיסק SSD מהיר או Mixed Intense או ביחד). במקרים אחרים יש פתרונות HyperConverged כמו Nutanix, Simplivity וכו' שבסופו של דבר מחייבות אותך לרכוש כמעט הכל מחדש (אם כי כמובן אפשר במקרים מסויימים להשמיש שרתים שונים, תלוי מה ה"גיל" שלהם).

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

גם במקרים של פתרון קוד סגור או קוד פתוח, נצטרך דבר ראשון להעיף מבט על השרתים שיש לנו. רוב השרתים שמריצים פתרון וירטואליזציה כלשהי, אנחנו נראה שרוב התושבות בשרתים – פנויים (וכמובן שיצרני השרתים מנצלים זאת על מנת לתת פתרון Backplane חלקי, כך שגם אם תרצה למלא 24 דיסקים 2.5" בשרת, לא תוכל אלא אם תרכוש עוד 2 backplanes עם החיבורים. בד"כ ה-backplane שאתה מקבל בשרת יכול לחבר מקסימום 8 דיסקים), כלומר שמבחינת השקעה בברזלים אם נרצה פתרון סטורג' מבוזר, נצטרך לרכוש פתרונות backplane לשרתים, וכמובן דיסקים מכניים, SSD (מסוגים שונים – read intense או mixed Intese – תלוי בתקציב ובמה שאתם רוצים לעשות). נקודה נוספת שנצטרך לקחת בחשבון זו הרחבת זכרון. אין צורך "להשתולל", בד"כ לפתרון SDS נצטרך 16 או 32 ג'יגהבייט זכרון. הנקודה האחרונה שיכולה להיות קצת יקרה היא רשת – אנחנו נצטרך בכל מכונה חיבור של 10 ג'יגהביט לתקשורת פנימית בין ה-VM שמריצים את פתרון ה-SDS.

את פתרון ה-SDS נריץ כ-VM בתוך כל מכונה, אולם אנחנו צריכים קודם כל להחליט איפה בעצם לאכסן את הנתונים, באלו דיסקים. דיסקים בגודל 2.5" לדוגמא יהיו קצת בעייתיים כי כמות ה-DATA שאפשר לאכסן בהם היא לא גדולה אך המחיר הוא די גבוה. אם לדוגמא נדמיין שאנחנו מכניסים 20 דיסקים של 1 טרה בגודל 2.5", ועוד 2 דיסקים SSD שישמשו כ-Cache, אז נקבל "ברוטו" 20 ג'יגהבייט. אולם אם נחליף את הפאנל הקדמי (כולל הלוח המוצמד) לגירסת LFF (כלומר Large Form Factor), אז נוכל להכניס 12 דיסקים של 4 טרהבייט, אז נקבל "ברוטו" 48 טרהבייט ומחירי הדיסקים הללו יהיו יותר זולים מ-20 דיסקים של 2.5" (בד"כ נוכל להכניס 2 דיסקים SSD ל-Cache מאחורי השרת). מבחינת הוירטואליזיציה, אין לנו צורך להתקין אותה (בגירסת vSphere) על הדיסקים המקומיים, 2 כרטיסוני מיקרו SD יוכלו לעשות את העבודה. (בין כה כמות הכתיבה אליהן מאוד קטנה ואם כרטיס נופל, כרטיס שני "לוקח פיקוד") כך שאנחנו יכולים בסופו של דבר להצמיד את כרטיס ה-RAID ל-VM עצמו ולקבל מקסימום ביצועים.

מבחינת תוכנות SDS בקוד פתוח, ישנו Ceph וישנו GlusterFS. התוכנות הנ"ל זמינות הן כקוד פתוח והן כמוצר מסחרי עם תמיכה מסביב לשעון. במקרים כמו שאני מתאר, אני ממליץ דווקא ללכת על GlusterFS. הסיבה לכך היא פשוטה: Ceph היא מערכת SDS מעולה, אבל היא פשוט לא בנויה לעבוד עם משאבים מצומצמים שאותם נקדיש ל-SDS ב-VM. כעקרון, Ceph דורשת שרתים יעודיים שיריצו רק את Ceph ולכן היא לא מתאימה למשימה.

כעת, כל מה שנותן לעשות זה לחבר את הדברים. בכל מכונה נקים VM עם הפצת לינוקס כלשהי (GlusterFS קיים לכל הפצת לינוקס שתרצו), להגדיר אם אנחנו מעוניינים בשכפול והפצת קבצים (אפשר לראות את האפשרויות כאן, פוסט מורחב על הנושא יהיה בקרוב) ומאותו פתרון SDS נוכל להגדיר שיתופים איך שנרצה: CIFS, NFS, iSCSI ועוד. כך נוכל להנות גם מפתרון SDS יציב, שיכול לעמוד במצב ששרת או 2 נופלים (תלוי איך הוגדר GlusterFS, בד"כ הגדרות ברירת מחדל יתנו HA כך שאם מכונה נופלת, השניה לוקחת פיקוד), גם נוכל להרחיב את הפתרון בהמשך (הוספת דיסקים, JBOD, מכונות נוספות) והכי חשוב – נוכל להנות מפתרון שנותן גם ביצועים מהירים וגם התחזוקה עצמה תהיה די מינימלית.

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

נקודות למחשבה בעת קניית סטורג' – חלק שני

בחלק הראשון של הפוסט דיברתי בכלליות על סוגי פתרונות שקיימים, גדילה (Scale Up או Scale Out) והתייחסות לצוות שיווק (Pre Sales).

בעסק קטן עם נניח 1-2 שרתים ועוד כמה Share ל-Windows, המחשבות וההתלבטויות לגבי קניית פתרון אחסון הם אינן גדולות. קונים NAS טוב, דיסקים, מגדירים את הכל ומתחילים לעבוד. בד"כ הפרמטרים הכי חשובים שם זה מהירות מספקת לצרכי עבודה ומחיר טוב. בד"כ פתרון NAS טוב נותן את הדברים שהעסק שצריך החל מ-CIFS, iSCSI, שרידות מינימלית וזהו.

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

נתחיל ברמה הכללית בכמה נקודות (ותודה לעומר שציין מס' נקודות בפייסבוק):

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

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

  • DeDuplication (או DeDup בקיצור): כשאנחנו משתמשים בוירטואליזציה, אנחנו מקימים מכונות VM רבים שיש בהם את אותה מערכת הפעלה ואותם קבצים. פונקציונאליות ה-DeDup מזהה חלקים זהים והיא "רושמת לעצמה" היכן נמצאים החלקים הזהים (ברמת Block או קבצים) אך היא שומרת עותק יחיד (במקרים מסויימים 2 עותקים) של אותם אזורים זהים, ובכך המערכת חוסכת מקום בסטורג'. ככל שיש יותר חלקים זהים, המערכת חוסכת יותר מקום.
  • Compression (דחיסה): פונקציואנליות נוספת "שכנה" של DeDup היא הדחיסה. יצרניות סטורג' שונות מאפשרות להקים Policy (שוב, ברמת בלוק או קבצים) המאפשרת דחיסה של נתונים שונים ופריסתם ברגע שצריך את הנתונים (הדחיסה והפריסה הם "שקופים").
  • Thin Provisioning: כשיש צורך בהקמת LUN (או משאב אחר הקשור בהקצאת שטח אחסון לטובת פרוייקט כלשהו) יש באפשרותנו להקצות חלק משטח האחסון ב-2 שיטות עיקריות: Thick Provisioning ו-Thin Provisioning. ב-Thick כל השטח המתבקש מוקצה מיידית לטובת אותו LUN לדוגמא ואילו ב-Thin יש רק "הכרזה" במערכת כי LUN X יקבל כך וכך שטח אך במציאות הוא מקבל מעט מקום ובכל פעם שיש צורך בעוד מקום, אותו LUN יקבל את מבוקשו עד גובה ההכרזה הראשונית. היתרון ב-Thin Provisioning הוא שאין צורך מיד "לכסח" חלק גדול ממקום האחסון אך החסרון הוא שכל בקשה לוקחת מעט יותר זמן (דבר שיכול להיות קריטי למערכות כבדות כמו שרת SQL וכו'). היתרון ב-Thick הוא בכך שיש את השטח לאפליקציה זמין כל הזמן והגישה היא יותר מהירה.
  • Snapshots: כל חברה נורמלית דואגת לגיבוי יומי של כל הנתונים בשרתים ובסטורג', אך הבעיה עם גיבוי ושחזור – זה ששחזור לוקח זמן. לעומת זאת, Snapshot מייצר "צילום" עכשוי של אחסון ספציפי (LUN או משאבים אחרים לדוגמא) וכך אם לדוגמא אנחנו משדרגים מערכת שמשתמשת ישירות בסטורג' ואיננו מרוצים מהתוצאה, אנחנו יכולים "לקפוץ אחורה" אל ה-Snapshot במקום לשחזר מהגיבוי, ופעולת החזרה אל ה-Snapshot היא מאוד מהירה.
  • Disaster Recovery: נשרף הראש, קרתה תקלה באחד הבקרים – מהי הדרך לשחזר, האם קיימת כזו, מה הזמן שלוקח לשחזר?
  • Tiering – עם Tiering פתרון האחסון עובד ב"שכבות" והוא מעביר קבצים לפי השימוש שלהם, כלומר אם יש לנו קבצים שיש בהם צורך מדי יום, הוא יאחסן אותם בדיסקים הכי מהירים שיש במערכת ואילו קובץ שקוראים אותו אולי פעם בכמה חודשים – עובר להישמר באחסון הכי איטי שיש (דיסקים SATA), ובכך המערכת מגיבה הרבה יותר מהר כי הקבצים שיש בהם צורך תכוף נמצאים בדיסקים הכי מהירים שיש.
  • IOPS – המושג שמשתמשים בו הכי הרבה בתחום הזה. כמה IOPS הסטורג' נותן בכתיבה ובקריאה? אל תתפתו להאמין לנתוני שיווק! דרשו מסמך התחייבות לכמה IOPS הפתרון נותן ומתי.

נקודות חשובות נוספות שכדאי לבדוק:

  • כמות תושבות PCIe: לפעמים יש צורך להכניס עוד כרטיסים לסטורג', כמו להוסיף כרטיסי תקשורת וכו'. כמה מקומות יש, אם בכלל?
  • כמות דיסקים וסוג: כל סטורג' יכול להכיל כמות מסויימת של דיסקים ולא מעבר לכך, ולכן חשוב לדעת מהי המגבלה, וכמו כן אלו דיסקים מתקבלים: SAS, NL-SAS, NVME, FC, SATA…
  • מעבדים מסייעים: בכל סטורג' היום נמצא מעבד Xeon כלשהו, והשאלה החשובה היא האם קיימים מעבדים מסייעים לעבודות שונות, כמו Block Storage Processor שלוקח עליו את העבודה בכל הקשור ל-Block Storage. קיומם של מעבדים כאלו במערכת מסייע מאוד בעבודה מהירה.
  • עדכונים ועדכוני אבטחה: בכל סטורג' חדש תקבלו עדכונים בשנתיים שלוש הראשונות כולל עדכוני אבטחה. השאלה החשובה היא מה קורה לאחר התקופה הזו. האם היצרן מתחייב לפרסם עדכוני אבטחה גם לאחר שלוש שנים? אם כן, לכמה זמן?
  • המשכיות: קניתם פתרון סטורג' מהיצרן ולאחר 3-4 שנים החלטתם לשדרג לדגם אחר – האם אפשר להשתמש בציודים הקיימים (מדפים ודיסקים) בציוד העתידי או שצריך הכל מחדש?
  • הדרכה/שרות/SLA: האם יש הדרכה רשמית שמדריך מגיע לחברה ומלמד את צוות ה-IT או שזורקים עליכם כמה קבצי PDF ותסתדרו? וכשזה מגיע לשרות – מה ה-SLA? זיכרו: במקרים רבים, כש-SLA לא מצוין, מדובר על יום העסקים הבא (NBD), וזה קורה במיוחד כשמוכרים לעסקים קטנים, קחו את זה בחשבון.

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

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

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

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

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

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

בהצלחה

חנות באינטרנט

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

זו שיטה נחמדה, אבל בעייתית מכמה סיבות.

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

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

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

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

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

  1. מצא לך בונה אתרים מקצועי (אחד שיש לו כמה שנות ותק ונסיון עשיר) ותאר לו מה אתה רוצה להקים, איך זה יראה, מה הדברים שיהיו בו ועוד. בונה האתרים יוכל לאמר לך מה תצטרך, מה העלויות וסביר להניח שהוא גם יקשר אותך לגרפיקאי שיבצע עבורך את העיצוב (ניתן לרכוש גם עיצובים בחו"ל ובונה האתר יוכל "לגייר" אותם בתשלום לעברית)
  2. מצא לך אחסון אתרים אמין (יש מספר ספקים גדול בארץ שמספק זאת. אם אינך מבין באחסון אתרים, תוכל לשאול את בונה האתרים על כך והוא יוכל להמליץ לך על ספק זה או אחר) וסגור חבילה עם הספק, ותן את הפרטים הטכניים לבונה האתר שלך (הסיבה שעדיף לך לעשות זאת בעצמך ולא עם בונה האתרים היא פשוטה: עדיף שהשליטה בנושא אחסון האתר תהיה שלך, אתה בסופו של דבר הלקוח).
  3. אם יש לך המון (מאות או אלפי פריטים), אתה רוצה להחזיק מאגר לקוח, לעשות סליקת כרטיסים מאובטחת, כדאי לך לקחת במקום חבילת אחסון אתרים, שרת וירטואלי (VPS). המחיר הוא יותר גבוה בהשוואה לאחסון אתרים, אולם ב-VPS יש לך שליטה מלאה ומי שינהל לך את האתר והשרת יוכל לדאוג למקסימום אבטחה.
  4. במרבית המקרים בונה האתרים יקח פלטפורמה לניהול תוכן כדי להקים את אתר המכירות שלך, בקש ממנו שיוודא כי הגירסה של התוכנות תהיה עדכנית.
  5. לקראת סיום הבניה, ודא כי האתר שלך עולה ונראה טוב בכל הדפדפנים הסטנדרטיים כמו פיירפוקס, כרום, אופרה ואקספלורר, ומומלץ לוודא כי האתר עולה ונראה טוב גם באייפון או טלפונים כמו גלקסי.
  6. ודא כי החוזה בינך לבין בונה האתר כולל: תחזוקה חודשית ועדכוני תוכנה, ותמיכה. סביר להניח שזה יוסיף מעט למחיר, אך זה שווה את הסכום: הדבר האחרון שתרצה לראות שקורה לאתר שלך שהוא נהפך מחנות לאתר עם דגל פלסטין וקללות.

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

בהצלחה

על שרתים וירטואליים (VPS) ו-DNS

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

מטבע הדברים, לכל אתר מגיעים עם שם הדומיין. היכן מוגדר שם הדומיין כדי שיוכר בעולם? ב-DNS כמובן, ומטבע הדברים, אלו שמשכירים שרתים וירטואליים ברוב המקרים מגדירים את השרת גם להיות שרת ה-DNS, ומכיון שבשביל DNS יש צורך ב-2 שרתים, כמעט כולם מגדירים את שרת ה-DNS שישמש כ"אדון" (Master) ו-Slave ("עבד").

כאן מתחילה הבעיה (והיא לא קשורה לספק כלשהו אלא בכלל).

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

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

כלומר הפתרון של לאחסן את רישומי ושרות ה-DNS בתוך שרת ה-VPS שלך אינו רעיון טוב.

מה עושים? אני מציע 3 פתרונות, שוב, ללא קשר לספק, את הפתרונות האלו כמעט כל ספק יכול למכור לך.

  • אם יש לך מספר קטן של דומיינים (נניח כמה עשרות דומיינים) מספיקה חבילת אחסון משותף (נקראת גם "אחסון אתרים" או "אכסון אתרים") בתצורת "ריסלר" (ישנם ספקים שקוראים לזה שמות אחרים, אתה צריך לבקש חבילה שאתה יכול לרשום בה דומיינים דרך הפאנל). חשוב לוודא שלאותו ספק שרתי ה-DNS שלו מופרדים (מומלץ שיהיו מופרדים ברמה הפיזית כך שכל שרת DNS ישב בשרת פיזי אחר). עם חבילה זו תוכל לרשום את הדומיינים שלך אצל אותו ספק ולהפנות את ה- A record לכתובת ה-IP של שרת ה-VPS שלך (אפשר גם רישומים אחרים כמו MX, CNAME ועוד, ועל כך מומלץ להתייעץ עם הספק או עם מישהו מקצועי שמבין ב-DNS ובהתאם לצרכים). ודא עם הספק שהרישומים שיצרת מסונכרנים אוטומטית עם שרת ה-DNS השני שלו. במקביל, כשרשמת בחבילה את הדומיינים, הספק יתן לך 2 רישומים (או יותר) של Name Servers שאלו בד"כ שמות שרתי ה-DNS שלו. את הרישומים האלו אתה צריך להכניס אצל רשם הדומיינים, היכן שרכשת את הדומיינים.
  • אם יש לך כמות גדולה של דומיינים (מאות ומעלה), מומלץ לשכור מספק אחר שרת VPS מאוד קטן (256 מגהבייט זכרון, דיסק קשיח וירטואלי קטן, עוצמת השרת אינה חשובה), ולהרים עליו שרת DNS. אם הינך משתמש בשרת ה-VPS העיקרי שלך עם cPanel, אז הנה חדשות טובות: אתה יכול להוריד ולהתקין ללא תשלום בשרת ה-VPS הקטן את cPanel DNS Only ולעקוב אחר ההוראות שם. תוכל להגדיר דומיינים בשרת ה-VPS העיקרי שלך והוא יסנכרן את הרישומים אוטומטית עם שרת ה-VPS הקטן שלך. (אגב, הסיבה לספק אחר נעוצה בעניין שאם יש תקלה כלשהי אצל הספק העיקרי שלך, שרותי DNS עדיין יוכלו לזהות את הדומיינים שלך בעולם).
  • אפשרות שלישית (והכי זולה, אם כי לא תמיד אפשרית): להשאיר את ניהול ה-DNS אצל רשם הדומיינים שלך. רובם מציעים פאנל כלשהו לשינוי ה-A record וכו' בקלות, וכך גם אם השרת הוירטואלי שלך נופל, שרתי ה-DNS בעולם עדיין ידעו לגבי הדומיינים שלך. החסרון בשיטה זו: אצל רוב הרשמי דומיינים הישראליים, העדכון עצמו מתרחש רק לאחר 24 שעות ועד אז לוקח עוד 24 שעות עד שזה מתעדכן בארץ (בהשוואה לחו"ל שזה עניין של שניות). לצערי, בנושאי DNS, "תודות" לספקי האינטרנט הגדולים ולאיגוד האינטרנט (ולכל תהליך רישומי דומיינים מקומיים), אנחנו עדיין "תקועים" בשנות ה-90.

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

כשבוחרים ספק לשרות VPS

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

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

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

אני יכול לתת דוגמא מהעסק שלנו: אנחנו מתמקדים בשרתי VPS המיועדים לתחום ה-Prosumer  כלומר לשוק שמורכב גם ממקצוענים שמכירים היטב ולעומק מה זה VPS, מה זה שרת וירטואלי, מה ניתן ומה לא ניתן לעשות איתו, איך להגדיר אותו, איך לשנות אותו מכל צד אפשרי, לעשות לו אופטימיזציה ועוד, וגם לאנשים עצמם שמתכנתים, אנשי סיסטם (שיש להם בעבודה שרתים וירטואליים והם מנהלים אותם או שהם מנהלים של המחלקות הללו), אינטגרטורים, בוני אתרים מקצועיים, אנשי QA ועוד. גם האחסון המשותף שלנו שונה מאוד מאחסון אתרים שאחרים נותנים, כי אצלנו שמים דגש יותר על תמיכה של שפות נוספות, כלים (כמו GIT,SVN וכו') לניהול קוד, בקרה, והגבלת המשתמש כדי שלא יוכל "לחנוק" משתמש אחר (כן, גם באחסון משותף). אם מישהו שלא מבין כלל בתחום מגיע אלינו והוא רוצה לאחסן אתר, אנחנו נבקש לסגור את הפרטים הטכניים מול בונה האתרים שלו ולא איתו. אם אין לו בונה אתרים והוא לא מבין כלום בנושא ורוצה להרים בלוג משלו, נשמח להפנות אותו למתחרים, כי זה לא התחום שלנו. אנחנו לא נותנים שרות ל-End Users אבל רוב הספקים הישראלים שנותנים שרותי אחסון אתרים (אחסון משותף) נותנים בשמחה למשתמשי קצה, אז שירוויחו, בשמחה.

זה הפוקוס אצלנו.

ספקים אחרים לא יפרסמו את הפוקוס שלהם כי הפוקוס שלהם מסתכם ב"הכל". רוצה שרת משחקים? קח. רוצה חבילות מוכרנים (ריסלר)? קבל. רוצה לארח פורנו? אין בעיה. הונאת לייקים בפייסבוק? אוקיי. זו כמובן זכותם המלאה לקבל את כולם ולעשות את הפרנסה שלהם מזה.

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

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

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

בהצלחה