כשרוכשים SSD – תוספת קטנה למאמר

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

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

אחד הדברים החשובים הוא לשים לב לאיזה דיסקים SSD אתם הולכים לרכוש ומה המשימות שיריץ השרת עם הדיסקים שאתם רוכשים.

לדוגמא: יש לכם 2-3 שרתי ESXI, אין לכם אחסון משותף (NAS או SAN) ואתם מפעילים DRS (זה אפשרי, אם עומדים בדרישות). אחד מהשרתים נהיה עמוס והמערכת מתחילה להעיף VM החוצה לשרתים אחרים, מה שאומר – הרבה קריאה, הרבה כתיבה, אבל אם בחרתם SSD מבלי לבחור לדוגמא Mixed Intensive כל פעילות המיגרציה תהיה איטית ולא רק המיגרציה תהיה איטית אלא כל פעילות המכונות הוירטואליות שרצות בין השרתים שעוברים מ/אל השרתים הפיזיים – תהיה איטית. מדוע? כי זה שביקשתם SSD לא אומר שתקבלו את הדיסקים העוצמתיים, קיבלתם את הדיסקים שהם לא ממש "חיות ביצוע" (בלשון המעטה).

אחת הטעויות שרבים הרוכשים שרתים שעושים – היא להסתכל בטבלה של היצרן ולבדוק IOPS. קחו לדוגמא את HP שמציגים את ה-SAS SSD שלהם עם IOPS מעולה של 6 ספרות בקריאה ו-5 בכתיבה. נשמע מעולה, נכון? רק שהמספרים הללו משקפים עומס צפוי ולפרק זמן קצר, כלומר המספרים משקפים עומס שאינו רלוונטי במציאות. כמו שאנו יודעים, במציאות כשאנחנו מעבירים לדוגמא VM (ולא משנה אם מדובר ב-Hyper-V או ESXi) גודל ה-VM הוא עשרות ואפילו מאות ג'יגהבייטים, כך שאתם תראו העברה שמתחילה מהר אך כבר לאחר רגעים ספורים ההעברה תהיה איטית. איפה כל ה-IOPS שהובטח? אז הבטיחו.

ציינתי לעיל שבמקרה של DRS דברים נהיים איטיים בדיסקים SSD שקונים בברירת המחדל, אך נקודה חשובה  לא פחות היא העובדה שכל VM גם הוא דורש כתיבה/קריאה ובחלק מה-VM הכתיבה היא מרובה יותר מקריאה ובחלק אחר זה הפוך ובעוד חלק – זה "באמצע". כל כתיבה/קריאה נכנסת ל-Queue, מה שנקרא Queue Depth וככל שה-Queue יותר גדול, כך לוקח זמן ל-SSD שמגיע בברירת המחדל ברכישת שרת – לעשות את העבודה, וזאת בניגוד ל-SSD שתוכננו מראש גם לעמוד בעומסים של QD 32-256 לדוגמא, כך ששוב – תכנון ובחירת SSD נכונים עושים הבדלים של שמיים וארץ!

זו, אגב, אחת הסיבות שאני מאוד אוהב את השרתים של DELL. בניגוד ל-LENOVO ו-HP, ב-DELL מופיע לך עוד בזמן בחירת החומרה באתר – איזה דיסקים אתה הולך לקבל (DELL מוכרים ברוב הזמן דיסקים של סמסונג למעט SSD PCI שהם של אינטל), כך שכל מה שאתה צריך לעשות זה לפתוח TAB חדש ולחפש בגוגל סקירה על הדיסק ולראות תוצאות, לא צריך לקנות חתול בשק.

וזה אחד הדברים שלצערי הרבה מנהלי IT מסרבים בעקשנות לעשות: לקנות דיסקים מספק חיצוני במקרים של LENOVO/HP. סמסונג, ואינטל (וקצת משתרכת מאחור Sandisk ו-Toshiba) מרעננים דגמים כל שנה עם בקרים יותר משוכללים, עם מהירויות מטורפות ועם אורך חיים יותר גדול. גם לסמסונג וגם לאינטל יש נציגים רציניים בארץ עם שרות שליחים במקרה של תקלות (בדיסקים Enterprise) ובמקרים רבים אפשר לחסוך מאות דולרים פר דיסק וגם לקבל את המילה האחרונה ב-SSD ובכך לקבל ביצועים מעולה ושרות מנציג יצרן הדיסקים (אגב, אני תמיד ממליץ לרכוש את כל הפלסטיקים של ה-Tray – היכן שיושבים הדיסקים, כך שבעת רכישת דיסק נוסף, לא צריך לחפש את ה-Tray כדי להכניס חדש).

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

נקודה שנשאלתי כמה פעמים: קנינו כבר שרתים עם SSD. הם ב-RAID-5 כבר. מה לעשות? פה זה תלוי בכם. אם אתם מרוצים מהביצועים – השאירו את הדברים כך ובהזמנה הבאה תשנו דברים. לא מרוצים מהתוצאות? העבירו VM שדורשים יותר כתיבה לשרתים אחרים והעבירו VM שקוראים הרבה יותר משכותבים – למכונות הנוכחיות עם ה-SSD שכבר קניתם.

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

כשרוכשים SSD לשרתים

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

אחת הבעיות שיש כיום היא שלרבים אין כל כך מושג מה זה אומר SSD. כולם כמובן יודעים שדיסק קשיח מכני הוא דיסק המורכב ממספר פלטות, ראשים מגנטיים, ובקר בתוך הדיסק עם זכרון מטמון קטן (בין 16 ל-256 מגהבייט, תלוי בדיסק ולאיזה שוק הוא משוייך כמובן). כולם יודעים שכשזה מגיע לשרתים – אתה צריך בקר RAID טוב, חלקם ירכשו בקר עם סוללת גיבוי וזכרון מטמון נוסף – והעיקר כשרוכשים דיסקים מכניים – חשובה מהירות הסיבוב (10,15K RPM), חשוב סוג החיבור (SAS, SATA) ועוד כמה פרמטרים קטנים כמו PMP, Dual Connection וכו'.

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

מאמר זה יתן מספר מושגים לגבי תכנון ורכישה של דיסקים SSD. בכדי להתחיל אני ממליץ לקרוא את המאמר הזה באתר של Seagate. המאמר הזה מסביר איך מאוחסנים הנתונים, מה זה "איסוף זבל" (Garbage Collection), מה זה Over Provision (בקיצור: OP) ומה היתרונות. המאמר קצת ישן וחלקו לא עדכני לגבי הטכנולוגיות כיום, אבל הוא מצליח להעביר את המידע בצורה קלה ולפיכך הוא מומלץ לקריאה ע"י כל איש IT/איש סיסטם ללא קשר למערכת ההפעלה.

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

תכנון ראשוני

כשאנחנו רוצים לקנות שרת עם דיסקים מכניים, ההחלטה על כמות הדיסקים היא די קלה. אנחנו מחליטים איזו תצורת RAID נשתמש (1,10,5,50 וכו') וכמות המקום הרצויה לפי חישוב ה-RAID. אחרי שאנו יודעים על כמות המקום שאנו רוצים, אנחנו בוחרים בהתאם לתקציב את גודל הדיסקים, מהירות, סוג חיבור, בקר RAID יעודי בחלק מהמקרים וכו'. מכאן אנחנו ממשיכים בבחירת חלקים אחרים (מעבדים, זכרון, תקשורת, גודל שרת מבחינ U וכו')

כשזה מגיע ל-SSD, התהליך הוא שונה לחלוטין.

הדבר הראשון שאנחנו צריכים לדעת זה מה השרת עומד להריץ וגם מהו יחס הכתיבה/קריאה. לא חשוב אם אתה צריך 2 טרה מקום או 50 טרה מקום – זה הנתון הכי חשוב. מדוע? מכיוון שישנם 3 סוגי SSD בכל הקשור לעומס העבודה.

Read Intensive

ב-Read Intensive מדובר על כך שהשרת יותר יקרא מידע מה-SSD מאשר יכתוב ביחס של 70% קריאה, 30% כתיבה. לדוגמא: אם יש לנו שרת SQL מפלצתי שמכונות אחרות מחוברות אליו ורוב הזמן קוראות ממנו מידע ופה ושם גם כותבות מדי פעם רשומות – אנחנו נבחר SSD שהוא Read Intensive (רוב דגמי ה-SSD בשוק שיותר זולים הם Read Intensive)

Mixed Intensive

כשיש לנו שרת שמבצע כתיבה וקריאה (ביחס של 50% קריאה 50% כתיבה) אנחנו נבחר SSD שהוא Mixed Intensive. דיסקים כאלו מתאימים למצבים שבהם אנו לא רק קוראים הרבה, אנחנו גם כותבים הרבה. לדוגמא: אם יש לך מכונת ESXi עם דיסקים SSD מקומיים ואתה בכל יום מוחק כמה VM ויוצר VM חדשים (Full Clone או מ-אפס) אז דיסקים כאלו יתאימו לסיטואציה הזו.

Write Intensive

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

כמות המקום שאנחנו צריכים

כפי שציינתי לעיל, בדיסקים מכניים כמות הדיסקים שנצטרך לרכוש תלויה לפי חישוב ה-RAID ולפי חישוב הדיסקים. נניח שבדיסקים מכניים אנחנו צריכים RAID 5 ו-10 טרהבייט מקום, אנחנו נרכוש 6 דיסקים שכל אחד מהם הוא 2 טרה או 11 דיסקים של 1 טרה (פחות או יותר, דיסקים SAS מגיעים בגדלים ש"קופצים" ב-300 ג'יגה, אז אנחנו בעצם נרכוש 12 דיסקים של 900 ג'יגה שיתנו לנו ברוטו של 9.9 טרה).

גם כאן, ב-SSD החישוב שונה. כשיצרן מצהיר על גודל דיסק SSD לדוגמא בגודל 1.2 טרהבייט, הדיסק בעצם בגודלו האמיתי הוא 1.4 (בערך) טרהבייט, רק שהיצרן שומר מקום ל-Over Provisioning (אזור בדיסק שבו אנחנו לא נשתמש אך הבקר הפנימי ב-SSD כן ישתמש לצרכיו), אולם יש יצרנים שמציינים את הגודל כ"ברוטו", כלומר דיסק SSD של 500 ג'יגהבייט אולם הכמות כוללת את ה-OP.

כלל האצבע שאני ממליץ הוא "לחתוך" מהדיסק בערך כ-10-20% כך שמתוך 1 טרהבייט, ישארו למערכת 800-900 ג'יגהבייט. כך אנחנו נמשיך לקבל לאורך זמן ביצועים טובים מה-SSD. במבט ראשון זה נראה כמו "מכה" (בכל זאת, אם קנית 10 דיסקים של 1 טרהבייט, אז "זרקת" 2 טרהבייט וזה עוד לפני חישובי RAID!), אבל ה"מכה" הזו משתלמת לאורך זמן.

נקודה חשובה נוספת (שגם לא ממש תהיה קלה לעיכול): לא למקסם את המקום בדיסק, הווה אומר – אם אנחנו מגיעים ל-60-70% ניצול של המקום הפנוי, הגיע הזמן לעשות דיון ברכישת דיסקים נוספים. ככל שתגיעו למספרים גבוהים יותר (80% ומעלה) הביצועים ירדו.

כמות כתיבה יומית

דיסקים SSD אינם כמו דיסקים מכניים שאפשר לכתוב עליהם חופשי כמה שרוצים. הבקר שב-SSD לא רץ כל שניה לכתוב את קובץ ה-10K שכתבתם כרגע. הקובץ ישב בזכרון (DRAM) של ה-SSD ובפעילות הכתיבה הגדולה הבאה הוא יכתב, כך שבקר ה-SSD עושה את הכל כדי לחסוך בפעולות הכתיבה. לעיתים הוא דוחס מידע, ולעיתים הוא עושה פעולות אחרות (תלוי בבקר SSD). לפיכך, אחד הפרמטרים החשובים שאנחנו צריכים לדעת הוא כמה בהערכה גסה אנחנו הולכים לכתוב על הדיסק ביום. האם אנחנו הולכים לזרוק על דיסק 500 ג'יגהבייט כ-300-400 ג'יגהבייט ליום? או שאנחנו אולי נכתוב כמה עשרות ג'יגהבייט מקסימום ליום? המושג נקרא DWPD והוא ר"ת של Disk Write Per Day, והוא מציין במספרים כמה פעמים אתה יכול לכתוב על כל הדיסק ביום. דיסקים SSD פשוטים נותנים לדוגמא משהו כמו 0.3. שימו לב: אם אתם "חונקים" מדי יום את הדיסק בכתיבות, אתם עלולים לגרום לאחריות שלכם להסתיים הרבה יותר מוקדם ולכן חשוב לבדוק את הנושא כשבוחרים דיסקים SSD.

SAS? SATA? NVME?

כמו בדיסקים מכניים, גם דיסקים SSD מגיעים במספר חיבורים אם כי כמו שציינתי, SAS כבת "מת" בדיסקים SSD מהסיבה הפשוטה שהחיבור עצמו איטי מדי בהשוואה למה ש-SSD נותן, לכן נשארנו עם SATA או NVME.

אני מניח שחלק מהקוראים כרגע כבר אומרים לעצמם "בשום מצב לא SATA". אין לו Queue לפקודות SCSI, ויש הרבה דברים של-SAS יש ושלא קיימים בפרוטוקול SATA וזה נכון אבל אם תסכלו בקטלוגים של SSD ל-Enterprise תמצאו שחלק נכבד מהדיסקים הוא בחיבור SATA (במהירות של .. 6 ג'יגהביט). מדוע? מכיוון שאותו "תור" וריבוי ערוצים שנמצא ב-SAS מתאים לדיסקים מכניים שבהם כמות ה-IOPS שאנחנו מקבלים היא מקסימום תלת ספרתית מאוד נמוכה (סביב ה-120-150 IOPS) וריבוי ערוצים מעלה את זה ל-300 IOPS ויותר – אבל עדיין תלת ספרית, אך דיסק SSD בחיבור ה-SATA הפשוט נותן IOPS של 5 ספרות, כלומר מה שלא מקבלים בריבוי ערוצים, מקבלים במהירות.

דיסקים מבוססי NVME הם בעצם כרטיסים שמתחברים בחיבור מיוחד שנקרא U.2 (לשעבר SFF-8639) ל-PCIe בלוח האם, כלומר אלו דיסקים עצמאיים (תיכף נגיע לזה) שאין בינם לבין SSD אחרים מבוססי חיבור NVME – שום דבר. נסו לדמיין שאתם מכניסים 2 כרטיסים גרפיים ללא SLI. אותו דבר.

מה שמביא אותנו ל….

RAID

כשזה מגיע לדיסקים SSD מבוססי SATA, הסיפור פשוט. מחברים ל-RAID שבלוח האם או לכרטיס בקר יעודי (שימו לב להגדרות Cache בבקר, בחלק מהמקרים עם דיסקים SSD SATA שונים יתכן ותצטרכו לבטל את ה-Cache). מגדירים את הדיסקים לפני כן ל-OP שאנחנו קובעים (אני ממליץ לחשוף את הדיסקים כ-JBOD ב-RAID, להעלות לינוקס מ-CD או כרטיס SD ולעשות זאת עם פקודת hdparm ורק אז לבנות בבקר RAID את ה-RAID שאתם רוצים תוך כדי שמוודאים שהבקר "רואה" את הדיסק בניכוי ה-OP שהגדרתם) ומתחילים התקנה של המערכת שאתם רוצים.

הנה טיפ קטן: לא להגדיר דיסקים SSD כ-RAID-5,6,50,60 אלא אם אתם רוצים נחיתה מאסיבית בביצועים. היצרנים ממליצים RAID-0, RAID 1 או מקסימום RAID-10 (לעשירים מביניכם).

כשזה מגיע ל-NVME לעומת זאת תצפה לכם הפתעה. אין RAID. גם אם ממש תרצו, אין RAID בחומרה (למען האמת יהיה בקרוב, חברת AVAGO מוציאה צ'יפ לזה אבל גם אז אל תצפו לביצועים משהו, דיסקים SSD בחיבור NVME יודעים לחנוק DMI בקלילות). מדוע אין? כי אלו SSD שיכולים "לחנוק" את ה-DMI בקלילות. SSD מבוסס NVME מעביר בממוצע כ-2 ג'יגהבייט בשניה (אם תתנו לו סיבה) וה-DMI 3.0 שקיים בשרתים מודרניים יכול מקסימום להעביר 3.93 ג'יגהבייט בשניה, כלומר מספיק 2 דיסקים SSD בחיבור NVME "לחנוק" את השרת.

אז מה עושים עם השרידות? חושבים קצת אחרת. בדיסק SSD בחיבור NVME ל-Enterprise יש שרידות הרבה יותר גבוהה בהשוואה לדיסקים מכניים. "סקטורים" פגומים? הבקר ידע להעביר לבד את הנתונים לאזור תקין. יש Fragment? הבקר ידע להעביר בזמנו החופשי את הנתונים ולסדר אותם (במסגרת ה-Garbage Collection). הפסקת חשמל? יש "סופר קבלים" על ה-SSD ששומרים את המידע על ה-DRAM עד שהחשמל חוזר. בקיצור (ואני אומר את זה מנסיון) – יקח לכם המון המון מאמץ להרוס SSD מבוסס NVME שמיועד ל-Enterprise. בגלל זה האחריות עליהם היא ל-5 ולחלקם 10 שנים.

נקודה חשובה נוספת: הפופולריות של NVME עברה "מתחת לרדאר" של יצרני שרתים. (הח"מ סיים לפני מספר ימים שיחות עם נציגי חברת SuperMicro כדי שיוציאו כרטיס PCIe עם PLX כך שניתן יהיה לחבר 4 דיסקים SSD עם NVME למכונת PC. בשרתים זה יותר מסובך כי ה-Backplane לא "יודע" מה זה חיבור U.2) ולכן רובם מאפשרים גם במכונות החדשים מספר קטן של כונני SSD בחיבור NVME. ב-DELL ו-HP כמדומני המקסימום הוא 4 דיסקים והשאר SAS מכני או SATA מכני או SSD. לכן אם אתם רוצים מכונה שתהיה "מפוצצת" ב-SSD בחיבור NVME, צרו קשר עם חברת SuperMicro לדוגמא.

לכן, אם אתם מתכננים לדוגמא להרים ESXi עם NVMe, תשכחו מ-RAID. (מה לעשות, ESXi לא תומך אפילו ב-RAID תוכנה, לא חשוב כמה תנסו). או שתשתמשו בדיסקים SSD בחיבור SATA או שתבנו Datastores שונים על כל NVMe ומשם תרפלקו לכם עם Veeam או כל תוכנה אחרת VM חשובים.

חסכון

(הנה מילה ששומעים הרבה ב-IT ומצווים לכך … ותמיד אפשר לשמוע על איזה מנהל שהחליט לקנות מפלצת שהניצול שלה יהיה 10% ממה שהיא יכולה לנפק)

הבדל המחירים בין SSD לצרכן לבין SSD ל-Enterprise הוא הבדל שנע בין 50-300%. עם SSD שהוא NVME בחיבור PCIe אתם בקלות מגיעים לאלפי דולרים עד עשרות אלפי דולרים וכמובן שהדיסקים האלו נותנים ביצועים מהממים – IOPS של 6-7 ספרות, אבל מה לעשות שברוב המקרים תגישו הצעת מחיר כזו והמנהל יתהה לגבי בריאותכם הנפשית.

ה"סוד" הגדול וההבדלים לדוגמא ב-SSD בין גירסת הצרכן לגירסת ה-Enterprise נעוץ במספר דברים:

  • גירסת ה-Enterprise כוללת "סופר קבלים" לשמירת הנתונים שעדיין לא נכתבו – בעת נפילת מתח
  • בגירסת ה-Enterprise – השבבים שעליהם נשמרים המידע הם בתצורת MLC (למי שלא ידע, SLC כבר מת) או eMLC.
  • בגירסת ה-Enterprise – הבקר הוא הרבה יותר חכם
  • בגירסת ה-Enterprise – הם מוצעים גם בחיבור SATA וגם כ-NVME (כאשר יש תהום של ביצועים בין ה-2)
  • בגירסת ה-Enterprise – האחריות היא בין 5 ל-10 שנים.

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

  • כדאי ללכת על שבבים שהם 3D NAND (כמו של סמסונג או טושיבה) כל עוד מדובר על MLC. ליצרן זה חוסך שבבים והמחיר יורד. אם מדובר על מכונה שרוב הזמן יקראו ממנה, אפשר גם לבחור SSD שיהיה מבוסס על צ'יפים שהם TLC אך כדאי לזכור – במקרים כאלו הכתיבה תהיה איטית (יחסית).
  • אם יש UPS – אז נוכל לוותר על ה"סופר קבלים"
  • אפשר להסתפק גם ב-1-3 שנים של אחריות במקרים מסויימים.
  • חיבור SATA מספיק

כך בעזרת דברים אלו ש"נרד" מהם – ניתן במקרים מסויימים לרכוש דיסקים כמו ה-850 EVO או 950 PRO של סמסונג (ה-950 EVO הפתיע רבים בשוק מבחינת הביצועים שלא היו פחותים מ-SSD SATA ל-Enterprise שעולים פי כמה ממנו) ויש כמובן יצרנים נוספים עם SSD בהחלט "שווים". אני לא ממליץ לעשות שרתי פרודקשן עיקריים עם SSD כאלו, למעט אם צריכים שרתי טסטים, פיתוח ודברים שאינם כה קריטיים.

העתיד

כשזה מגיע להתפתחות טכנולוגיית ה-SSD, אפשר לאמר שהיא מתפתחת בקצב מהיר. אינטל וחברת מיקרון עובדות על XPoint – טכנולוגיה שתתן ביצועים פי כמה וכמה מהירים מכל SSD שקיים כיום. סמסונג עובדת גם על פתרון שתחשוף אותו בסוף השנה או בתחילת השנה הבאה (עקב NDA אינני יכול לפרט), וגם טושיבה, WD/Sandisk עובדות על טכנולוגיות אחרות לשמירה/קריאת נתונים הרבה יותר מהירות מכל שבב FLASH NAND שקיים כיום. כל החברות במקביל עובדות על טכנולוגיות תלת מימד (3D) עם מספר דו ותלת ספרתי של שכבות על מנת להוציא SSD עם הרבה יותר מקום (סמסונג הוציאה לאחרונה דיסק של 15 טרהבייט במחיר "עגול" של … $10000).

אחת הטכנולוגיות החדשות שבקרוב "תסתער" על השוק (במיוחד שוק הוירטואליזציה, קונטיינרים ועוד) היא טכנולוגיית ה-MVMEoF (כלומר NVME Over Fabrics). כיום, כשאנחנו רוצים לייצא חלק מהדיסקים לשרתים, אנחנו עושים זאת בעזרת טכנולוגיות כמו NFS, SMB או iSCSI אך איננו מקבלים את כל המהירות ש-SSD בחיבור NVME מקבלים. עם NVMEoF המהירות שנגיע לנתונים תימדד בננו שניות, כאילו הדיסק יושב פיזית במכונה (כמובן שלשם כך יהיה צורך בהחלפת תשתיות – 40 ג'יגה Ethernet כמינימום, כרטיסי רשת שמבצעים Offload ל-TCP כמו של מלאנוקס ואחרים) ויש עוד כמה דברים בצינור.

עוד תחום נוסף מעניין הם דיסקים SSD חדשים ש"ישתפו פעולה" עם מערכת ההפעלה ויתנו למערכת ההפעלה בעצם לנהל את הדיסק ובכך להעביר את רוב הלוגיקה של הבקר – למערכת ההפעלה. הפרויקט נקרא Open Channel SSD והמימוש שלו נמצא בקרנל 4.4 בלינוקס (עדיין לא ב-Windows). עדיין אין כוננים כאלו אך כל היצרנים משתתפים בפרויקט.

לסיכום

דיסקים SSD הם ההווה ועתיד. זה כמובן לא אומר שדיסקים מכניים הולכים למות (רחוק מכך, הם מצטיינים בגדלים ובמחירים זולים יותר מ-SSD, כרגע לפחות) אבל מצד שני טכנולוגיית ה-SSD עברה את סף ה"נסיון" והיא יציבה יותר מדיסקים מכניים, שלא לדבר על כך שמבחינת מהירות כתיבה וקריאת נתונים – היא עוקפת כל דיסק מכני גם בחיבור SAS. ה-SSD גרם לטכנולוגיה חדשה כבר למות (SATA Express) וטכנולוגיית ה-NVME מחברת את ה-SSD (דרך U.2 או ככרטיס PCIe או בחיבור M.2 – פוסט על M.2 יופיע בקרוב) ישירות ללוח אם תוך עקיפת צורך בבקר כלשהו או בצורך "מנהל" כלשהו – ה-SSD מבוסס NVME עושה הכל, (רק כדאי לוודא שה-BIOS/UEFI תומך ב-NVME) – והיא נותנת ביצועים שנמדדים בג'יגהבייטים תוך מתן עשרות אלפי IOPS.

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

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

כמה מילים על Thin Client ל-Citrix

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

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

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

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

כיום ישנו גם פתרון שהוא יותר זול.

piלמי שלא מכיר – זהו ה-Raspberry Pi-3 (מודל B). זהו מחשב בגודל קטן מאוד עם כמות זכרון של 1 ג'יגהבייט והוא מריץ מערכת Linux ויש לו גם Client מלא ל-Citrix עם כל הפונקציות פעילות. הוא יכול לשמש בעקרון כ-Thin Client מאוד זול ולהתאים לחברות…

… בערך …

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

HDX-READY-Pi

תכירו את Viewsonic SC-T25: זהו המוצר של חברת Viewsonic ובתוכו יש בדיוק את אותו Raspberry Pi-3 Model B, אך כאן מדובר למוצר שמיועד לחברות. יש לו מערכת הפעלה לינוקסאית הכוללת ניהול מרכזי והמכשיר תומך בכל הפונקציות של Citrix. המכשיר ישווק בקרוב במחיר הכרות של 89$ לקופסא (בחו"ל).

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

דוגמא אחרת שחשובה לאבטחה וקשה לבצע בקופסאות סגורות אחרות: רוב הקופסאות מגיעות עם 4 כניסות USB אבל המשתמש מנצל רק 2 (מקלדת, עכבר) או 3 (כרטיס חכם או מתאם USB->Serial). נשארה כניסה אחת או יותר פתוחה ואנו רוצים לנעול על מנת שהמשתש לא יכניס ציוד לא מורשה. בעזרת סקריפט פשוט (דוגמא: כאן) אפשר לכבות את הכניסות האלו כך שגם אם יוכנס ציוד, המערכת לא "תראה" אותו ולא ניתן יהיה להפעיל אותו, וניתן להוסיף עוד 1001 דברים שירוצו על הקופסא או מחוץ לקופסא כדי להרחיב את השימוש בהתאם לצרכי החברה. (אגב, בקרוב ל-Pi תהיה תמיכת PXE כך שלא יהיה צורך לעדכן שום דבר בקופסא. מכבים, מדליקים, הקופסא מוכנה לשימוש).

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

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

הבהרה
לי אין קשר ל-Viewsonic או ליבואן ופוסט זה נכתב מהאספקטים של לינוקס, אבטחה וניהול יותר קל של Citrix Clients.

להסתכל דרך החור בגרוש

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

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

הפסדתי פרויקט גדול. קורה לכל פרילאנסר. ככה זה בחיים.

אבל הסיפור לא מסתיים כאן. הבוקר החלה החברה ההודית לעבוד (מרחוק) ומסתבר שמי שעושה את העבודה מבין בלינוקס ובוירטואליזציה ברמה בסיסית ומטה. מי שעשה את העבודה החליט לעקוף את מנגנוני השדרוג הרגילים ולבצע שדרוג "בכח" על שרתי הפרודקשן מבלי ליצור אפילו Snapshots! כמובן ששרתי הפרודקשן נפלו וסירבו להפעיל כל קובץ בינארי (אפילו לא Bash!), אבל מה שהיה יותר גרוע מכך – לצוות ה-IT אסור היה להתערב או לנגוע. כל מה שהם היו יכולים לעשות זה לפתוח סשן KVM ולצפות באסון בשידור חי. הם בהחלט דפקו את הראש בקיר! היכן כל הפעולות שאיש מקצועי צריך לעשות (ליצור VM חדש, להעביר חלק חלק, לשנות סקריפטים, להתקין גרסאות עדכניות של האפליקציות והספריות הדרושות)? אותו איש טכני הודי החליט פשוט לוותר על העניין, כאילו היה מדובר בעבודה על איזה LAB ביתי קטן..

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

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

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

כפרילאנסר, ישנם 2 מצבים של עבודה:

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

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

פרילאנסרים בזול אפשר למצוא תמיד: הודו, מזרח אירופה, רוסיה ועוד. מה שלא זול – זו המערכת שלך, ה-Downtime של שרתים/תקשורת/סטורג'. האם המערכות שלך "מחזיקות" את החברה? אם כן, אז עדיף למצוא מישהו מקומי שיעשה את העבודה, גם אם זה יותר יקר מפרילאנסרים זולים בחו"ל, במיוחד שב-90% מהזמן מתרחשים דברים כמו תיאור לא נכון של בעיה בהשוואה למה שהשרתים מציגים או שלא הובנו נכון (היה לי מקרה לפני מס' חודשים שמישהו התעקש שמצא באג-קריטי ב-MySQL והתקלה האמיתית היתה .. חוסר מקום בדיסק הקשיח של ה-VM). פרויקטים צריכים להתבצע בשיתוף פעולה צמוד עם הצוות האחראי, ועדיף במקרים רבים שזה יתרחש במשרדים. מפרטים ומסמכים זה נחמד – עבודה מול שרתים מציגה תמונה אמיתית ולפעמים זה מצריך שינויים בתוכניות.

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

  1. כשמראיינים פרילאנסר, בקשו ממנו לתאר מה הצעדים שהוא יבצע בכלליות. אם הפרילאנסר לא מתאר צעדי מנע, Rollback, בדיקת תאימויות, testing (ושרת טסטים) אז יש בעיה.
  2. החליטו על שיטת העבודה: האם מישהו יושב ליידו ולומד כל צעד או שהפרילאנסר יבצע את העבודה ולאחר מכן הוא יסביר וידגים מה הוא עשה ויכתוב מסמך על זה? (שימו לב: אחת הסיטואציות שמתרחשות לא פעם זה שאיש הלינוקס בחברה הוא די חדש בתחום, ואז כל הסבר מפורט לוקח הרבה יותר זמן, ואז פרויקט של 10 שעות יכול "להימתח" ל-25 שעות לדוגמא, ואז כולם עצבניים..)
  3. מתכננים פרויקט גדול? תתחילו בקטן (יותר גדול מ-POC, הרבה יותר קטן מפרויקט מלא). ראיתי פרילאנסרים רבים שמתוסכלים (נתנו מחיר Fixed לפרויקט והפרויקט התברר כדורש הרבה יותר שעות  ממה שתכננו ולפי התכנון הם הגישו הצעת מחיר) וצוותי IT מתוסכלים (ה-Storage נחנק, השרתים לא נותנים את אותה תפוקה שהיו אמורים לתת לפי התכנון, התאימות נשברת בגלל כלי חדש שהוכנס ועוד ועוד). רוצים לקחת פרילאנסר לשדרג 100 מכונות VM לגירסת מערכת הפעלה אחרת? תתחילו עם 10-20, ש-2 הצדדים יפיקו לקחים ואז תמשיכו, עדיף (לדעתי) מאשר לראות שפרויקט הושלם אבל הלקוח לא מרוצה.
  4. רוצים לעבור למשהו חדש? מעבר לענן? CI? אוטומציה פופולרית? השכרת פרילאנסר להדרכה לא תספק (ראיתי כבר חברות שלקחו 3 שעות הדרכה על אוטומציה אבל לא לקחו ליווי ויעוץ להמשך ולבסוף הם זנחו את הכלי כי הם לא הכירו מספיק את ה-Quirks). שום הדרכה אינה מספקת בכדי לכסות Troubleshooting או אופטימיזציה, אם אתם לוקחים הדרכה, קחו גם ליווי/יעוץ "לדרך" ומנסיון – אתם תחסכו לעצמכם שעות רבות של תסכול ו/או חשבונות עתק (במקרים של עננים ציבוריים).
  5. רוצים לרכוש ציוד עבור הפרויקט? אל תקשיבו להמלצות של איש המכירות. אם אין בחברה ידע לגבי הציוד הנדרש (או שיש ידע חלקי/לא מעודכן) – קחו יעוץ ממישהו מקצועי שאינו Reseller (כך שלא יווצר הרושם שהוא מנסה "לדחוף" לכם ברזלים שהוא מוכר). ראיתי לדוגמא מספיק מקרים שחברות קנו SSD לשרתים מבלי לבדוק מה העומסי כתיבה/קריאה ובחירת דיסקים בהתאם. יש מקרים בהם אפשר לעשות שימוש בציוד קיים ויש מקרים שאין ברירה וצריך לרכוש ציוד והדברים אינם כה פשוטים.

ואם יש לכם פרויקטים בנושאים הקשורים לוירטואליזציה/חומרה/לינוקס/ZFS/סטורג' מבוסס תוכנה – אתם תמיד מוזמנים לפנות 🙂

כמה מילים על ניטור

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

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

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

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

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

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

עד כה דיברתי על 2 סוגי ניטור:

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

יש עוד סוג של ניטור שיכול לעזור לחברות שיוצרות המון קבצי לוגים (החל מחומות אש, IPS/IDS, אפליקציות שונות, בנקאות וכו'). במקרים כאלו, אפליקציות כמו שציינתי לעיל לא יסייעו. מישהו נניח חדר למערכת. דרך איזה פורט הוא נכנס? מה כתובת ה-IP שלו? מה הוא עשה? במה הוא השתמש? אלו פרטים שכל מערכת בטחון תדע. אם יש באג באפליקציה, מה הפלט שמופיע בלוג? איך ננתח את כל הלוגים מעשרות שרתי Web ושרתי אפליקציה?

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

לסיכום: כשאנחנו נכנסים ומחליטים לגבי ניטור, כדאי לבצע חלוקה ולדעת קודם כל מה אנחנו רוצים לנטר. אם יש לנו כמה מאות VM (לא משנה איזה Hypervisor) ועשרות שרתים, נתבים, מתגים, אין בעיה להרים מערכת Zabbix לדוגמא ותוך מספר ימים לנטר את רוב המערכת (יקח עוד כמה ימים לנטר את החלקים היותר "ממזרים" כמו מתגים, נתבים ובמיוחד – לעשות אופטימיזציה לשרת ניטור עצמו, דבר שלכשעצמו אינו כה קל לביצוע. החלק שלוקח הכי הרבה זמן הם ציודים שמצריכים כתיבת חוקים ידנית וכתיבת סקריפטים לפתרונות אוטומטיים), אבל אם אנחנו רוצים לנטר לוגיקה של שרתי אפליקציות, Web, ניתוח לוגים ממקורות שונים – אז פתרונות כמו ELK ואחרים צריכים להיות מיושמים, כלומר יכול להיות מצב בו תצטרכו 2 מערכות ניטור, כאשר כל אחת עושה דבר אחר (יש כל מיני פתרונות מסחריים שמנסים למכור את עצמם שיכולים לעשות את הכל ביחד, אני לא ממליץ להטמיע פתרונות כאלו, אלו פתרונות שמביאים להמון חיכוכים בין צוותים שונים).

כשצריך המון IOPS ואין תקציב

כמעט לכל חברה כיום יש בד"כ אמצעי אחסון גדול מאוד ומכובד, בין אם מדובר על יצרנים כמו NetApp, EMC, IBM, HP ויצרנים אחרים. בד"כ אלו "חיות" שיודעות להתמודד עם שלב מצבים והן מצויידות בשלל אמצעים לשרידות וגדילה. המחירים שלהם – מאוד יקרים בכל אספקט אפשרי, מדיסק קשיח יחד, מדף, מעבד נוסף, זכרון, חיבורים נוספים ועוד. זהו ביזנס מאוד יקר ויוקרתי עם חוזי תמיכה ארוכים (ויקרים, מה שמעמיד חברות לפני החלטות תקציביות בנושאי IT במצבים לא פשוטים לפעמים אם לחדש או לעשות את הצעד ולקנות סטורג' יותר מודרני). זהו אחד התחומים היחידים שבו אני ממליץ תמיד: אם הנתונים והמהירות חשובים – לא מומלץ לחסוך.

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

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

אבל מה קורה שהתקציב המאושר לא מספיק אפילו לחצי מדף של SSD עם MLC לדוגמא? נניח התקציב המאושר הוא פחות מ-$20K? ונניח שדרישת הפרויקט מחייבת 6 ספרות מבחינת IOPS וכמה טרהבייטים רציניים? תשאלו את רוב יצרני הסטורג' ואתם תקבלו תשובה פשוטה: תגדילו את התקציב, לא יכולים לאשר הרחבה בסכום כה.

מה לעשות? תלוי אם החברה שלכם "שמרנית" או "רפורמית".

פתרון "שמרני" הוא לפנות לכל מיני יצרני Appliance למיניהם שהם בעצם SDS (כלומר Software Defined Storage) ובד"כ תמצאו במחיר של עד $20K פתרון שכולל "12 טרהבייט", כלומר משהו כמו 4 טרה SSD והשאר דיסקים מכניים. זה פתרון טוב, אבל אם אתם מחפשים IOPS גבוה (נניח 6 ספרות), עומסים גבוהים והרחבה ליותר מחיבור יחיד של 10 ג'יגהביט, הפתרון הזה לא יעזור לכם. הפתרונות המוכנים כקופסא בתחום זה לא ממש מגיעים ל-6 ספרות של IOPS ואפשרויות ההרחבה שלהם – אינן גדולות אם בכלל. כמובן שאינני טוען שכל הפתרונות כאלו, אולם הרוב הם כך.

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

  • מארז PC או שרת? רבים יענו במחשבה ראשונה "שרת" 1U או 2U, אבל כאן הדבר תלוי מאוד איזה שרת. לדוגמא ב-HP לא ניתן יהיה להשתמש בשרתי דור 8 בדיסקים NVMe שאינם כרטיסי PCIe (תיכף אסביר מדוע לא מומלץ פתרון אחסון בכרטיסי PCIe). רק בדור 9 יש אפשרות עם מתאם מיוחד להכניס 4 כונני NVMe עם כרטיס PCIe שכולל מתג PLX (זהו "מתג" שמאפשר לחלק תושבת PCIe X16 ל-4 כוננים כיום) וזה פתרון משלים ש-HP מוכרים בדור 9, אבל הוא לא תואם מכנית לדור 8. ב-Dell המצב קצת יותר טוב ושרתים כמו R720/R720XD יכולים לקבל פתרון שמזכיר את הפתרון של HP ואילו בדגמי R730/R730XD יש אופציה שנקראת FlexBay.
    אם אתם רוצים להשתמש בשרת פיזי יותר ישן – תיתקלו בבעיה הואיל וה-Backplane לא מאפשר חיבור SFF-8639 (מה שנקרא היום U.2).
    בתצורת PC (אם זה MIDI, Tower או כל פתרון אחר) לעומת זאת הדברים יותר פשוטים: אין Back Plane אז אין בעיה להעביר כבל מכרטיס עם חיבוריות U.2/SFF-8639 לכונן  2.5".
  • כונני 2.5" או דיסקים SSD ככרטיסי PCIe? כונן 2.5" מהסיבה הפשוטה: בשביל לקבל ביצועים תצטרכו חיבורי רשת גדולים. 2 חיבורים של 1 ג'יגהביט לא ינצלו את ה-PC שאנחנו בונים, ולכן או שנשתמש בצמד של 10 ג'יגהביט (SFP לסוגיו או הרגיל) ומעלה, או מספר חיבורי 1 ג'יגהביט ב-Teaming או אם נרצה לייצא iSCSI – נשתמש ב-MPIO אבל גם אז מומלץ על חיבורי 10 ג'יגהביט. אנחנו הולכים לעבוד עם המון IOPS ולכן מומלץ כוננים עם חיבור U.2 כי אנחנו נצטרך את התושבות עבור כרטיסי רשת.
  • זכרון – כמה שיותר, יותר טוב. מערכות כמו ZFS על FreeBSD או לינוקס משתמשות בזכרון זה כ"מטמון" ולכן כמה שיש יותר זכרון, כך נקבל ביצועים (שבחלק מהמקרים יכולים להימדד בננושניות, אם המידע עדיין נמצא ב-RAM) ובמקביל אפשר להפעיל פונקציות כמו DeDupe, דחיסה ועוד. בכל מקרה אני ממליץ לפחות 64 ג'יגהבייט של זכרון ומעלה (אם ה-IOPS חשובים)
  • דיסקים NVMe – תשכחו מדיסקים SAS מכניים, דיסקים SAS SSD. ה-NVMe "בועט" בכל דבר קיים מכל בחינה אפשרית. הדיסקים הללו נחשבים יקרים אולם אנו צריכים רק זוג מהם והמחירים דווקא די מפתיעים. לדוגמא: כונן SSD עם MLC בחיבור U.2 עולה 569$ בחו"ל לצרכן. אותו כונן SSD בחיבור SATA עולה .. 729$ וכפי שציינתי, ה-NVMe מהיר פי כמה וכמה מ-SAS או SATA, כך ש-2 דיסקים כאלו יתנו לנו את המהירות קריאה/כתיבה שנצטרך (מתוך הנחה שאנחנו צריכים את כל הסטורג' שנבנה ל-70% קריאה ו-30% כתיבה). אני ממליץ לרכוש את ה-400לפחות.
  • כרטיס SATA: אם אתם הולכים לבנות את הפתרון עם לוח של PC, קנו כרטיס SAS/SATA. לא צריך כרטיס עם זכרון מובנה או סוללה כי ZFS (אם תחליטו לעבוד איתו) חוסך את הצורך בכך. מספיק כרטיס כמו M1015 או M1115 במצב "IT MODE" ללא שום הגדרות RAID. אם אתם עובדים עם שרת שיש לכם (1U, 2U וכו') תצטרכו להעביר את הבקר למצב JBOD. עלות כרטיס כזה – בין 80-100$ חדש, אפשר למצוא יותר זולים משומשים (הם נחשבים ל"סוסי עבודה" עד היום). בכל מקרה למעט אם על הלוח יש בקר מובנה של LSI – לא להשתמש בחיבורי ה-SATA על לוח האם, הם יוציאו ביצועים מחפירים.
  • כונני SSD SATA: בכוננים אלו יאוחסן בסופו של דבר החומר (כונני ה-NVMe משמשים כמטמון משני). אני מניח שחלקכם ירימו גבה ויתמהו מדוע לא כונני SSD SAS והתשובה לכך: הם יקרים בהרבה והם לא יתנו ביצועים יותר גבוהים ומה שיותר חשוב – כמעט אף חברה לא מייצרת אותם יותר (HP מוכרת אותם אבל אינטל, סמסונג ומיקרון לא מייצרים אותם יותר). כונן SATA SSD משתמש במלוא רוחב הפס של SATA (כ-550 מגהביט) ומכיוון שאנחנו משתמשים ב-NVMe SSD כמטמון גדול, הביצועים יגיעו ברוב הזמן מהם. הדיסקים SSD SATA מאחסנים את החומר.
    אלו דיסקים? אני ממליץ על דיסקים בגודל של 1 טרה או אם יש לכם תקציב – 2 טרה. מחירי ה-1 טרה (וחצי טרה) יורדים כל הזמן, כאן לדוגמא אתם יכולים לראות דיסק 1 טרה של סמסונג עם טכנולוגיית ה-V-NAND במחיר של $419. אתם יכולים גם לחשוב על גירסת 2 טרהבייט עם דגם 850 EVO (נכון, EVO נחשב "נמוך" יותר אולם טכנולוגיית ה-TurboWrite החדשה של סמסונג מצליחה להחביא את העובדה שמדובר ב-TLC NAND גם כשכותבים עשרות ג'יגהבייט במכה אחת!) במחיר של $700.
    כמה כוננים? כמה שיותר. כך נוכל לבנות RAIDZ עם שרידות של כונן 1 או 2 או 3 כך שהמערכת תמשיך לעבוד. ההמלצה שלי היא על 4 או 8. אם אפשר יותר –  מה טוב.
  • חיבור לכונני ה-NVMe: מה לעשות, רוב הלוחות (בשרתים ובלוחות PC) לא כוללים חיבורי U.2/SFF-8639 ולכן נצטרך כרטיס לחבר אותם. לצערי הכרטיסים שקיימים בשוק מציעים מקסימום 2 חיבורי U.2 והכרטיס שמומלץ הוא מחברת SuperMicro והוא כרטיס בעל השם: AOC-SLG3-2E4 ומחירו: $250. הוא מאפשר חיבור של 2 כוננים (יש גם דגם זול יותר – 2E4R – לא לרכוש אותו כי הוא בקושי תואם למספר לוחות אם).
  • זוג כונני SAS/SATA/SSD פשוטים – מהם תעלה מערכת ההפעלה (רוב לוחות האם הישנים לא מכירים בחיבורי ה-U.2 לשם Boot) ואותם נבנה כ-RAID-1. אפשר גם דיסק קשיח רגיל.
  • מעבד: ממליץ על מעבד Xeon סידרה D-1541 (סידרה E3 מוגבלת בכמות הזכרון ל-32 ג'יגהבייט) או מעבד i7 עם chipset שיאפשר 64 או 128 ג'יגהבייט זכרון.
  • כרטיסי רשת: מאוד ממליץ על כרטיסי 10 ג'יגהביט או על חיבורי סיב מעל 4 ג'יגהביט. כל המערכת הזאת לא תוציא IOPS רציני אם אין לה "עבודה" רצינית לעשות. חיבורי 1 ג'יגהביט בהצמדות יכולים לעבוד, אבל זה מאוד תלוי איזה פרוטוקול אתם מעבירים את הנתונים: iSCSI אז לכו על MPIO, אם זה NFS אז אפשר ללכת על Teaming/Bonding.

נעשה חישוב עם מכונה לדוגמא:

  • לוח אם עם מעבד i7 של SuperMicro דגם SUPERMICRO MBD-X10SDV-TLN4F-O. הלוח כולל בתוכו 2 חיבורי 10 ג'יגהביט, ו-2 חיבורי M.2 בתצורת PCIe כך שאפשר יהיה לקחת דיסקים קשיחים NVMe בתצורת "מקלות" ולחסוך כרטיס מתאם. המעבד (Xeon D-1541) כבר בפנים. מחיר: $939.
  • 4 מקלות זכרון שכל אחד מהם הוא 32 ג'יגהבייט ECC בתצורת LRDIMM של HP (סה"כ: 128 ג'יגהבייט זכרון) – מחיר: $1799
  • 2 "מקלות" בתצורת NVMe של סמסונג שישבו בחיבורי M.2 שקיימים על הלוח הנ"ל. כל "מקל" מכיל 512 ג'יגה. הדגם: SAMSUNG 950 PRO M.2 512GB PCI-Express 3.0 x4 Internal Solid State Drive (SSD) MZ-V5P512BW והמחיר: $638 ל-2 המקלות.
  • 8 כונני Samsung 850 Pro בגודל 1 טרהבייט בחיבור SATA – (מחיר $419 לכל כונן) סה"כ: $3352
  • מארז עם ספק 500W: נניח $100. (לגבי שרידות:
  • "מיני מארז" ל-8 כוננים 2.5" שנכנסים למארז PC ותופסים תושבת 5.25" (מחברים חשמל אחד ו-8 חיבורי SATA). מחיר: $120. פתרון של ICY DOCK מעולה לזה.
  • סך הכל: $6310. המחיר הוא בארה"ב כמובן. נעגל ל-$8000 במחירים בארץ. המחיר כמובן לא כולל עבודת הקמת ZFS (או מערכת קבצים אחרת), הגדרות ועבודה של מי שמקים את זה, אך אם ניקח לדוגמא כלל אצבע של 350 שקל לשעה כפול 27 שעות (3 ימי עבודה – אני בכוונה מגזים) אז תהיה תוספת של $2400 בערך, כלומר הכל כולל יוצא בערך $10K.

הערות על המערכת לעיל

  • קודם כל, המערכת למעלה היא תאורתית בלבד. חסר בה לדוגמא פתרון לספק כח כפול (בהזדמנות זו אני ממליץ להסתכל על FSP TWINS שיצא בקרוב) ופתרון של PC כשרת מאוד לא מקובל בחדר שרתים. במקרים כאלו הדברים היו שונים מעט אך המחיר לא היה כזה שונה.
  • נקודה נוספת שחשוב לדעת היא מה השימוש שלכם. צריכים לדוגמא IOPS גבוה לאורך זמן? אל תקנו NVMe שאינו אינטל 750 או מעליו לדוגמא כי בשאר המקרים רוב המתחרים נופלים ב-IOPS לאחר זמן קצר.
  • בלוחות אם (ובשרתים) חדשים יש מקום לאחד או 2 לכונני M.2 PCIe – עדיף להשתמש בהם במקום לרכוש מתאם.
  • כמות המקום נטו עם מערכת כזו תהיה: 6 טרהבייט (RAIDZ2) עם אפשרות החלפה ל-2 כונני SSD או 7 טרהבייט (RAIDZ1) עם אפשרות החלפה ל-1 דיסק SSD תקול.
  • אם רוצים מהירות עוד יותר גבוהה שלא "תנחת" בזמן כתיבה ל-SATA SSD, אפשר להחליף במקום ה-Samsung 850 Pro לאינטל 750. העלות תהיה בערך עוד $1600, כמות האחסון תרד ל-5.6 טרה (או 4.8 אם רוצים שרידות של 2 כוננים), אך בשביל טריק כזה, תצטרכו או HP G9 או DELL R730 שיכולים לקבל 8 כוננים בחיבור U.2, אבל אז אנחנו מדברים על הוספה של עוד $4K רק לשרת עצמו (בניכוי לוח האם לעיל) במחירי חו"ל. מה לעשות שאף חברה לא צפתה את הפופולריות של SFF-8639/U.2.

לסיכום: זהו אינו פתרון שמחליף את הסטורג' הגדול בשום מצב! זה כן פתרון שיכול להיות פתרון "באמצע" עד שהחברה תתקצב הרחבה לסטורג' המרכזי. זה כן פתרון שצריכים לתת למחלקה מסויימת מקום אחסון די זריז מבלי ש"ישחטו" את הסטורג' המרכזי, וזה כן פתרון ללקוחות קטנים ואפילו להרים טסט של כמה עשרות מכונות VDI (במקרה הזה גם תצטרכו כמה כרטיסי GPU רציניים, צרו קשר עם nVidia). נכון, סטורג' אמור להיות שורד בכל מצב אפשרי ואפשר בהחלט לבצע Cluster של 2 מכונות זהות כאלו גם ל-Active Active וגם ל-Active Passive, אבל לעניות דעתי צריך לדעת היכן לעצור בעניין ה"שרידות בכל מחיר" לסטורג' שהוא בעצם NAS והוא אינו מרכזי.

להגן על האתר שלך

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

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

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

אם לדוגמא ברגע זה אתה מבין שהאתר שלך אינו נגיש ואתה שומע מהספק שאתה מותקף, אתה יכול לגשת לאתר של CloudFlare, לבחור את הדומיין שלך (אם יש לך מספר דומיינים שמציגים אתרים מאותו שרת – עבור על כל אחד מהדומיינים), ללחוץ על כפתור ה-Firewall ופשוט לבחור "I'm Under Attack", כמו בתמונה הבאה:

cf

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

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

אפשרות מעולה שקיימת (בחבילה של ה-20$) היא שימוש ב-WAF (ר"ת Web Application Firewall). עם WAF החיים יותר קלים כשצריכים להגן על אתרים רציניים. חלק לא קטן מהתקפות דרך רשתות Botnet הם התקפות שנראות במקרים מסויימים כמו כמות גולשים גדולה שנכנסת, אבל מדובר בהתקפה. הנה דוגמא:

cf2

מי שלא מכיר לוגים של כניסות לאתרים לא יבין מה הבעיה, מי שמבין רואה שיש כאן נסיונות כניסה עם מחרוזות רנדומליות שנועדו לעקוף חוקים שחוסמים כניסה. במקרים כאלו ה-WAF יכול לסייע ולחסום דבר כזה בשניות (תומכי CloudFlare כותבים עבורך את החוק אם תתן להם קובץ access_log או שאתה יכול לכתוב בעצמך). מעבר לכך, חוקי ה-WAF מתעדכנים מצד CloudFlare נון סטופ, כך שאתה מקבל הגנה גם על דברים שאינך מודע אליהם (לדוגמא אם אתה משתמש בתוכנה כמו WHMCS (זו תוכנה שקשורה ל-Billing ואוטומציה של שרותי Hosting), אז בעבר היו מספר פריצות לתוכנה, ועד שיצרן התוכנה תיקן אותם, ב-CloudFlare הכניסו חוקי הגנה ל-WAF ללקוחותיהם, כך שאם מישהו היה מנסה לפרוץ ל-WHMCS שלך, הוא היה נכשל בשעה שאצל אחרים הפורץ היה "חוגג".

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

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

  • עדיף שההגנות לאתרך לא יבוצעו בשרת הפרטי שלך אלא ברמת ספק ה-CDN, ובמקביל – לא מומלץ לאפשר גלישה ישירה לאתר שלך, אלא גלישה רק דרך ספק ה-CDN.
  • אל תסמוך על הבטחות ההגנה של ספק התשתית שלך. במקרים מסויימים הוא יפיל את האתר שלך, ובמקרים אחרים אתה עלול ליפול לתומכים שלא ממש יודעים מה הם עושים. יש להם הגנות מכאן עד הודעה חדשה? זה לא רלוונטי לגביך.
  • הגנה רצינית אינה עניין של להגן על הוורדפרס/ג'ומלה/דרופל שאתרך מריץ, אלא על המון פרמטרים אחרים שחלקם אולי אינך מודע אליהם. מומלץ לשכור מישהו חד פעמית כדי לבצע הערכה ותוכנית מה צריך להגן, מה צריך להסיר ואם אפשר – איך להגיע לביצועים אופטימליים עם הגנה.
  • הגנות טובות גם מצריכות תחזוקה מתמשכת, ולכן כדאי לסגור עם מי שמטפל בך טכנית שגם יעדכן את השרת שלך אחת לכמה שבועות.
  • חשוב: אם האתר שלך חשוב מאוד ו/או מייצר לך רווחים, אל תאחסן אותו באחסון משותף (Shared Hosting). לצערי כמות ההגנה שניתן לבצע על אתר שמאוחסן באחסון משותף היא מאוד קטנה (לא ניתן להגן עליו מ-DDoS, לא ניתן להטמיע WAF "מבחוץ", לא ניתן להגן על המכונה ועוד).

תחליף ל-vSphere?

OVirt-logo-highresאם יש שאלה שאני מקבל בשיחות רבות בכל הקשור לוירטואליזציה, זו השאלה "איזה כלי יש כדי להחליף vSphere?". אחרי הכל, לא מעט חברות לא כל כך אוהבות את המחירים של VMWare, את עלויות התמיכה השנתיות (למרות שברוב המקרים לא משתמשים בזה כי האינטגרטור או בחברה יש ידע לטפל בבעיה ותמיד יש את גוגל) ולא מעט חברות מעוניינות לקחת את ההשקעה שהם השקיעו ולעבור לפתרון אחר, עדיף בכמה שפחות כסף.

אז לפני שאענה על השאלה, חשוב למקד את הנושא: vSphere זו משפחה של מוצרים, לא כולם מתחילים עם "vSphere": כך לדוגמא יש את vSan, Orchestrator, vCenter, vRealize ועוד מוצרים רבים שמתחברים אל תשתית ה-vSphere.

האם יש כלי קוד פתוח שיכול להחליף את אלו ואחרים כ-Drop In Replacement ללא צורך בעבודת הקמה? התשובה, לצערי, היא לא. לא OpenStack ולא שום כלי אחר יכול להחליף בצורה של לקחת ערימת ברזלים, להתקין, להריץ איזה שהוא Coverter שימיר את הכל לתשתית החדשה ולאחר כמה שעות תוכלו להפעיל את הכל מאיזה מוצר אחר.

מה שכן, המוצרים שכן קיימים כיום הוא RHEV של רד-האט (בגירסה המסחרית) ו-oVirt שהוא כלי קוד פתוח שעליו מתבסס בעצם RHEV. עם הכלי הזה – יש אפשרות להמיר מערכת כמו vSphere Essentials (ללא כל האוטומוציה של Orchestrator, בלי דברים כמו vCloud Air ואחרים) למערכת כמו oVirt/RHEV.

אבל לפני שאתם יוצרים קשר עם חברה או פרילאנסר לתאם פיילוט להעביר את התשתית ESXI שלכם ל-oVirt/RHEV, אני ממליץ לקרוא את הדברים הבאים..

מבחינת ESXI, ב-VMWare עשו את הכל על מנת שחברה לא תצטרך להחזיק איש לינוקס (או איש עם ידע של לינוקס) בחברה בשביל לתפעל את המערכת. גם כשנכנסים ב-SSH לשרת ESXI, הידע שצריך בלינוקס/יוניקס הוא די מינימלי ולחברה שרוב מוחלט של התשתיות שלה מבוססות מיקרוסופט, VMWare יצרו את PowerCLI שעובד עם Power Shell כך שאפשר לעשות כמעט הכל מבלי לדעת לינוקס. גם הקורסים של VMWare לא ממש מתמקדים על לינוקס אלא מתמקדים במוצרים של VMWare עם נגיעות בדברים חיצוניים כמו רשת, סטורג' בצורה כללית, כך שמי שרוצה לדוגמא להרים את NSX, עדיף שידע רשתות בצורה רצינית (CCNA ומעלה), כי מהקמה של NSX בלי ידע רציני בתקשורת – לא מגיעים רחוק.

בעולם ה-RHEV/oVirt לעומת זאת, הצורך באיש לינוקס להקמה של הדברים הוא קריטי. עם הכלים הללו לדוגמא אין כלי אוטומציה יעודי כמו שיש ל-VMWare, מכיוון שברד-האט (לדוגמא) מבינים שאם אתה רוצה אוטומציה, אתה עושה את זה עם כלי אוטומציה כמו Chef או Puppet או לדוגמא אם אתה עובד עם Ansible אז יש לך מודול ל-oVirt כדי להקים, לעצור, להפעיל מכונות וישנם מודולים אחרים שעוזרים בדברים אחרים הקשורים לוירטואליזציה. השוני הגדול בין רד-האט ל-VMWare הוא שבזמן ש-VMWare משלבים עוד ועוד כלים כחלק אינטגרלי מ-vSphere/vCenter, ברד-האט עובדים הפוך: אתה יכול לעשות עם הפתרון החלופי שלהם ל-vCenter (מה שנקרא אצלם: Hosted Engine) והשאר יכולים להיות כלים שונים עם ממשק RESTful וכאלו שיש להם Plugins אל ה-Hosted Engine, כמו במקרים של Neutron, Cinder וכו'. אתה יכול לעבוד עם ה-GUI או עם virsh או להשתמש בספריית libvirt ולעשות את הכל בעצמך באיזו שפה שתרצה.

אז לקחת עכשיו כמה ברזלים ולהרים את oVirt? זה תלוי. באופן עקרוני ההמלצה של רד-האט היא להקים Nodes ועליהם להקים את Hosted-Engine ב-Clusters. ישנם 2 גרסאות של oVirt Node שההבדל המהותי ביניהם זה שגירסה אחת משתמשת בממשק "קלאסי" ובגירסה השניה התקנת ה-Node היא כבר עם ממשק שיותר מזכיר התקנת CentOS/RHEL ויש כבר ממשק גרפי שמשתמש בכלי Cockpit כדי לתת כלים מבוססי Web הן כדי לנהל את ה-Node והן כדי לתת ממשק אחר ויותר מודרני (בהמשך) לניהול ה-Engine.

מי שחושב להוריד את ה-ISO ולהתחיל מיד לעבוד, צפוי לכמה "הפתעות" לא כל כך נעימות כרגע.

ovirt-node-oldovirt-node-newנסיון התקנה של ה-ISO בגירסה ה"קלאסית" על מכונה אמיתית נותן את התמונה משמאל (לחצו להגדלה) ואילו נסיון התקנה של הגירסה החדשה נותן את התמונה מימין (לחצו להגדלה).

ב-2 המקרים, ניתן לתקן את תקלות ההתקנה בשימוש Kickstart חיצוני או באמצעות הקמת ISO חדש תוך שימוש בהגדרות מהפצות Fedora אחרות, אבל שוב – אלו דברים שמצריכים איש לינוקס מקצועי שיודע לטפל בדברים האלו ולהגדיר את כל השרותים שצריך ל-oVirt ושאר החלקים ב-Hosted Engine. לאחר הקמה של הדברים וערימת ההגדרות (שבהמשך תהיה כבר אוטומטית) המערכת די יציבה ואפשר להתחבר ל-vCenter ושרתי ESXI כדי להמיר מכונות VM אל המערכת החדשה (בזמן ההמרה המערכת משנה את הגדרות הדרייברים, כך ש-VM שעובר, מוכן לשימוש לאחר ההמרה) ואפשר להתחיל לעבוד עם המערכת החדשה.

מבחינת oVirt/RHEV – העתיד הוא דווקא עתיד טוב. המערכת עוברת ממצב של שימוש ב-JAVA ל-Node.JS, היא תהיה הרבה יותר אינטרקטיבית, היא תדע להתמודד עם רשתות מאוד מורכבות, כבר כרגע היא יודעת להתחבר ל-iSCSI, NFS וגם Infiniband (אם כי יש כמה Gotchas בנוגע ל-Infiniband). היא תומכת כבר עכשיו ב-Clusters, עם Live Migration, עם HA וכו'. יחד עם זאת, כדאי לזכור שחלק מהמושגים שונים כי הטכנולוגיה לגמרי שונה מ-VMWare ולכן אם אתם מחליטים לעשות פיילוט, ודאו כי הפרויקט כולל הדרכה, כי הדברים שונים, אפילו ברמה של ISO ל-VM השונים (לא ממש מסכים עם השיטה שרד-האט בחרו, אבל זו החלטה שלהם). האם לחכות לגירסה העתידית? אין ממש צורך בכך, גם הגירסה הנוכחית עובדת, ועובדת טוב (עבדכם הנאמן בדיוק ממיר מערכת מ-ESXI-6 ל-oVirt עם 75 מכונות VM פה בבית), רק קחו בחשבון שהקמה של מערכת כזו אינה עניין של שעתיים שלוש ויכולה לקחת מספר ימים ואם אין לכם אנשי לינוקס, מומלץ לסגור על בנק שעות לתמיכה ואולי הדרכה לאנשיכם.

כמה מילים על הקשחת שרתי לינוקס

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

נתחיל בנהלים ובתפיסות שגויות. לא מעט ארגונים מעדיפים לבטל את SELinux ואת חומת האש המובנת בהפצת הלינוקס כי "יש חומת אש רצינית מלפני התשתית ובין כה אף אחד לא מגיע לשרת הזה מבחוץ, אין גישה אליו מהאינטרנט". אני בהחלט מבין את הטיעון הזה, אולם במקרים הטיעון הזה שגוי הואיל ולעיתים נותנים גישה לגורם חיצוני מבחוץ (בין אם דרך VPN, דרך Team Viewer או דרכים אחרות) ואין שום אפשרות לוודא כי מי שנכנס מבחוץ הוא אכן מי שמיועד להיכנס או מה הכישורים והכוונה של זה שנותן תמיכה (כלל ברזל באבטחת מידע: תחשוד לפני שתסמוך). סתם דוגמא: חברה גדולה בישראל שנותנת תמיכה למאות (ואולי יותר) ארגונים משאירה חיבור פתוח מבחוץ (תוך ידוע החברה) עם סיסמא שילד בן 10 יכול לנחש, וזה ללא VPN, עם כניסת מקלאס כתובות של אותה חברה. תארו לכם שנכנס מישהו "מאוד סקרן" לתוך המערכת ניצול העובדה שסמכתם על אותה חברה? אני יכול לדמיין כמה סיטואציות לא כל כך נעימות.

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

ההמלצה הכי טובה להקשחה, במידה והמכונות הן VM, היא לא להקשיח מכונה קיימת, אלא להתחיל מאפס, עם kickstart (מכונות מבוססות RedHat/CentOS/Fedora9) או Kickstart/Preseed/FAI (מכונות מבוססות Debian/Ubuntu ונגזרות שלהן). גם בהתקנות פשוטות של CentOS/RedHat לדוגמא יש ערימה של חבילות שאין בהן צורך והן יכולות להיות בעייתיות מבחינת אבטחת מידע (CUPS, YP, ועוד. NMAP הוא כלי מעולה כדי לגלות שרותים שרצים בתוך המכונה ושאינכם זקוקים להן) כך שכדאי לבנות את קובץ האוטומציה ולהתקין דרכו את ה-VM כך שהמכונה תהיה נקיה, קטנה ומאובטחת.

אחד הדברים שכדאי וצריך לעשות על מנת להקשיח את המכונות (ואפשר להכניס את זה לתוך ה-kickstart) הוא שימוש ב-CIS Benchmarks. ה-Benchmark (שקיים למערכות הפעלה ואפליקציות שונות) נותן הדרכה כללית כיצד להקשיח את מערכת ההפעלה שלכם. השימוש ב-CIS נפוץ מאוד בבנקים, מוסדות גדולים ואחרים וניתן ליישם אותו על מערכות חדשות (דרך kickstart) או דרך מערכות אוטומציה כמו Puppet, Chef, Ansible וכו'. אפשר כמובן להשתמש ב-CIS כדי ליישם על מערכות קיימות, ומומלץ לרכוש את CIS-CAT כדי לבחון את ההקשחות.

שילוב של SELinux, חוקי חומת אש ומימוש CIS Benchmark יכול לסייע רבות בהקשחת מכונות (אם כי מימוש שלושת הדברים אינו מבטיח הקשחה מלאה).

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

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

קצת על מתקפות OpIsrael ומה ניתן לעשות – ובזול

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

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

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

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

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

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

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

מבחינת מחיר – ישנם מספר חבילות. ישנה חבילה חינמית שיכולה לסייע לאתרים פשוטים להימנע מהתקפות, אך מומלץ להשקיע בחבילת ה-Pro (שעולה 20$) שיכולה למנוע תקיפות נגד כל מיני תוספים שקיימים באתר. לאתרים רציניים יותר (שמכניסים כסף) אני ממליץ ללכת על חבילת ה-Business שיודעת למנוע DDoS ועוד כמה סוגי התקפות.

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

cloudflare-dns

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

אם תסתכלו בתמונה לעיל, תוכלו לראות 2 חיצים אדומים שמצביעים על 2 עננים. הסימון הזה אומר שמבחינה חיצונית, כתובת ה-IP שלכם תוחבא ומה שיוצג החוצה זו כתובת IP של CloudFlare (שימו לב שיש ללחוץ על אייקון הענן שיהפך לכתום אחרת כתובת ה-IP שלכם האמיתית תוצג לעולם. כמובן שכדי לגשת לאתרכם דרך SSH או RDP, כדאי ליצור בנפרד רשומה נוספת עם שם לא צפוי או לרשום את זה אצלכם בחברה ב-DNS פנימי או קבצי hosts), כך שמי שינסה לתקוף ב-DDoS את .. CloudFlare, ו-CloudFlare יודעים היטב להתמודד עם DDoS (עד רמה מסויימת, תלוי בחבילה שלך. בחבילת ה-Business אתה לא תקבל DDoS – ויש ל-CloudFlare רוחב פס של כמה טרהבייט). אם נצרף את הגנת ה-DDoS להגנת ה-WAF (ר"ת Web Application Firewall) ועוד כמה הגנות שהם נותנים, אתרכם יהיה די מוגן.

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

אתרים/בלוגים פוליטיים לעומת זאת – יכולים לקבל הגנה מלאה בחינם דרך גוגל בפרויקט Shield. על מנת להצטרף – לחצו כאן.

מבחינת חברות גדולות (חברות ביטוח, בנקים וכו') שצריכות לתת ללקוחותיהם אתרי אינטרנט עם מידע – גם כאן CDN (ללא EDGE ישראלי או עם הגדרות שלא יגיע ל-Edge ישראלי, כך שאם יש התקפה היא לא מגיעה לישראל) יכול לסייע. נכון, הרגולטור לא מאפשר אחסון אתרים/שרתים בחו"ל לעסקים מסויימים, אבל התוכן שאינו מצריך Log In (מה שנקרא Pre Login Content) כבר זמין לכל והתוכן עצמו (והשרתים כמובן) נשאר בארץ ורק עובר דרך CDN, וההתקפות DDoS מבוצעות בד"כ על אתרים עם התוכן הזה, לא על התכנים לאחר Log in, כלומר מה שמגיע ל-CDN הוא תוכן די סטטי שכבר זמין, כך שגם חברות יכולות לקחת את אותו מסלול ובכך בעצם למנוע את הצורך לחסום תקשורת לחו"ל.

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