קטגוריה: כללי

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

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

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

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

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