נקודות למחשבה כשרוצים לרכוש סטורג' חדש

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

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

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

  • 22 דיסקים של סמסונג מסוג PM883 בגודל 1 טרהבייט מסוג Mixed Intensive
  • 2 דיסקים של אינטל 900P (לצרכי Cache, ZIL, Logs) בגודל 280 ג'יגהבייט
  • 256 ג'יגהבייט זכרון DDR4 ECC במהירות 2666 מגהרץ
  • מעבד יחיד Xeon V4 עם 4 ליבות
  • מערכת הפעלה: Fedora 28 עם ZFS
  • חיבורי רשת של 25 ג'יגהביט

המערכת הזו עבדה במשך חודשיים תוך כדי שהיא מחוברת ל-15 שרתי ESXi ונתנה הן שרותי iSCSI והן שרותי NFS (נפרדים, ישירות ל-VM). מבחינת IOPS – זה נע בין חצי מיליון ל-מיליון.

מערכת כזו אינה בנויה כפי שניתן לראות ל-Enterprise. אין בה בקרי RAID כפולים והשרידות שלה היא לא משהו (אין שום שרת נוסף זהה לצרכי HA), אבל אני מראה כאן את Elsa כדי ללמוד משהו חשוב, על Tiering שמאוד חשוב בכל סטורג' שקונים.

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

  • ה-256 ג'יגהבייט זכרון – זה ה-RAM של המערכת, זה הדבר הכי מהיר שיש
  • 2 הדיסקים 900P של אינטל – יש להם Latency יותר גבוה מ-RAM אבל יותר נמוך מכל דיסק אחר
  • דיסקים SSD

בסטורג' קנייני לעומת זאת (StorWiz של IBM, או VNX של EMC לדוגמא) ה-Tiering מעט שונה:

  • שכבת ה-RAM
  • שכבת NVRAM – זהו זכרון מסוג מיוחד שאינו נמחק ברגע שאין חשמל
  • שכבת ה-SSD
  • שכבת הדיסקים המכניים / SSD שליפים (במדפים)

בשרתי סטורג' שהם SDS אין שכבת NVRAM ובמקרים רבים גם אין בקרי RAID כפולים, כך שה-Tiering הוא כמו זכרון, SSD, ודיסקים. כאן, חשוב לדרוש שיהיו SSD שלא מותקנת עליהם מערכת ההפעלה, ה-Cache אמור לשבת ב-SSD נפרדים ושיהיו Mixed Intensive. ברוב ההצעות מחיר שתקבלו, ה-SSD יהיו Read Intensive ויש הבדל ניכר במחיר.

דבר נוסף שחשוב הוא עניין החיבוריות: כמעט כל מי שמוכר פתרון סטורג', מוכר אותו עם פתרון FC (כלומר Fiber Channel) במהירות 16 ג'יגהביט. זהו פתרון טוב לדיסקים בחיבור SAS ו-SAS2 או SATA למדפים/JBOD או בדיסקים שיושבים בשרת, אבל אם אתם חושבים על NVME – פתרון ה-FC יהווה צוואר בקבוק – חיבור 16 ג'יגהביט מאפשר ברוטו 2 ג'יגהבייט לשניה, ו-NVME מעביר בין 1.5 ל-2.5 ג'יגהבייט לשניה ואני מדבר על דיסק יחיד, ומכיוון שלעולם לא תכניסו SSD NVME יחיד, החיבור יחנק, ולכן אולי כדאי לחשוב על פתרונות Infiniband או Ethernet מהירים במהירות 25 ג'יגהביט ומעלה (ובקשר ל-Latency – ישנם מס' פתרונות עם Latency נמוך, כולל RDMA וחבריו).

אם כבר דיברנו על FC, לא מומלץ לסמוך על 4 חיבורי ה-FC שקיימים ותמיד מומלץ לקנות מתג לחיבור המהיר, במיוחד אם יש לכם רק 3 שרתים ואתם חושבים לגדול בהמשך. יש תחרות, נצלו אותה לשם מו"מ כדי להשיג מחירים טובים.

נקודה נוספת שחשוב לקחת בחשבון היא גיבוי הסטורג' עצמו. כן, יש Veeam שמגבה מכונות וירטואליות (והוא מגבה ל.. סטורג') אך תקלה רצינית בסטורג' (ותקלות תמיד קורות, תשאלו את מרפי) לא תאפשר לכם לא לשחזר מכונות VM או דברים אחרים, ולכן כדאי לגבות את הסטורג' לקלטות גיבוי או למכונת NAS זולה אחרת (במכונות שהן אינן G8/G9/G10 של HPE שהן אינן ביצור/פרודקשן אפשר גם להכניס SATA "ביתיים" גדולים זולים, רק חשוב להוסיף SSD לשם Cache). כאן, אגב, אני רוצה להזהיר בהזדמנות שדיסקים SSD של אינטל ש-HPE משווקת, במקרים רבים הקושחה כזו גרועה, שדיסקים נופלים גם בצוותים!

ודבר אחרון שיכול להיות חשוב: חוץ מ-iSCSI, תחשבו על פרוטוקולים אחרים שאתם צריכים בשרתים שניתן להוציא אותם באופן "טבעי" מהסטורג' ולא להסתמך על שרת VM שיוציא אותם (SMB/CIFS, NFS) מכיוון שסטורג' תמיד יוציא אותם עם ביצועים גבוהים יותר. ואם יש לכם צורך בכך, הכניסו את זה בתנאי הרכישה של הסטורג'.

ומה לגבי כל ההתלהבות לגבי HCI עם vSAN/Nutanix/Simplivity במקום סטורג' יעודי? הם טובים, אבל הבעיה האמיתית שלא תמיד שמים לב אליה היא עניין גדילת כמות הסטורג': במקרים כמו vSAN לדוגמא תצטרכו להוסיף 3 דיסקים (2 מכניים או SSD Read פלוס SSD מהיר) פר שרת שמשתתף ב-HCI, ומהירות IOPS גבוהה מקבלים רק כשכמות השרתים המשתתפים ב-HCI היא גדולה (ארון פלוס). נוסיף לכך שבניגוד לדיסקים ביתיים, דיסקים ל-Enterprise יקרים והמחירים בקושי יורדים (וחברה כמו HPE לוקחת עשרות אחוזים יותר בגלל … מדבקה ושינוי כמה ביטים בקושחה) – זה יכול להוות בעיה בטווח הארוך.

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

על גריטת שרתים ישנים ומה ניתן לעשות

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

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

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

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

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

  • HP G9 לסוגיו
  • DELL X30 (ה-X מוחלף ב-400, 600, 700 וכו'. האות שבשם לא ממש משנה)

הדבר הראשון שצריך לבדוק הוא אלו מעבדים יש לכם (אפשר להסתכל ב-BIOS/UEFI). אם יש לכם Xeon V3 אז אתם יכולים לפנות ליצרן ולרכוש Kit שדרוג למעבדים, אפשר להכניס מעבדי Xeon V4 לשרת (יש צורך לעדכן את ה-BIOS/UEFI לפני כן, אם לא שדרגתם לאחרונה). הביצועים לא יהיו כמו שרת דור קדימה (G10, X50), אבל אתם תקבלו ביצועים שגבוהים בין 30-60% (ההפרש בביצועים הוא בגלל הזכרון, בשרתים כמו G10,X50 הזכרון הוא DDR4 במהירות יותר גבוהה ממה שיש לכם עם ה-DDR3).

הבעיה בעניין השדרוג קשורה לדרך שאתם רוצים לשדרג. אם אתם לדוגמא חושבים לפנות ליצרן, המחיר שיגבה מכם לא ממש זול. אם לדוגמא יש לכם שרתי X30 של DELL (שוב, ה-X מוחלף במספר 430,630,730 וכו'), תצטרכו לשלם בסביבות ה-800-6000 דולר (תלוי במעבד) כפי שאתם יכולים לראות כאן. אם לעומת זאת אתם קונים מסוחר יד שניה שמביא טכנאי שעושה לכם זאת, המחיר זול יותר. כך אתם מאריכים את חיי השרתים הללו בעוד כמה שנים.

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

שרתים ישנים יותר כמו:

  • HP G7 לסוגיו
  • IBM M3 לסוגיו
  • DELL X20 (שוב, תחליפו את ה-X ב-620,720,420 וכו', לא חשוב האות)

אלו שרתים שניתן ניתן לשדרג מעבדים אבל רק לאותה משפחה (כלומר Xeon V1, לרשימה הזו וגם אז, רק ה-E5-2XXX או E5-4XXX אם יש לכם שרתים עם 4 תושבות למעבדים), כך שאתם יכולים לדוגמא לעבור ממעבדים עם 4 ליבות, למעבדים עם 12 ליבות. השדרוג יוצא יותר זול מהדוגמאות לעיל, אבל הביצועים, למען האמת, לא יהיו כאלו גבוהים כי הם לא כוללים טכנולוגיות יותר מתקדמות שקיימות ב-Xeon V4 והזכרון מאוד איטי בהשוואה לשרתים הכוללים זכרון DDR4.

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

שרת NAS מהיר.

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

כיצד? די פשוט:

בשרת הישן אנחנו נתקין בקר RAID די מודרני (LSI/AVAGO) ונחליף את כל הדיסקים לדיסקים SATA או NL-SAS (אנחנו לא רוצים להשקיע יותר מדי כסף, נכון? זה לא פרודקשן) ואנחנו נוסיף דיסק SSD (יחיד או זוג, תלוי בכם) שישמש כ-Cache מהיר. את ה-Back Plane של השרת אנחנו ננתק מבקר ה-RAID הפנימי ונחבר לבקר ה-RAID החדש.
כרטיס נוסף שנצטרך הוא כרטיס רשת QSFP (יש גם +SFP) של 10 ג'יגהביט עם 2 פורטים (אפשר להתקין 2 כרטיסים כאלו עם כניסה יחידה בכל אחד מהם, מכיוון שבשרת יש לנו רק PCIe 2.0) ובשרתים נתקין גם כרטיס רשת כזה.
מה עם סוויצ'? לא צריך. אנחנו מחברים כבל DAC בין ה-NAS לבין כל שרת ESXI.

מבחינת מערכת הפעלה, זה כבר תלוי בכם: אתם יכולים להתקין לכם Windows עם Storage Spaces, לינוקס רגיל ולהגדיר דברים ידנית, FreeNAS ויש עוד מספר פתרונות. אחרי ההתקנה של הפתרון אנחנו יכולים לבחור מה אנחנו רוצים לייצא החוצה (לא לשכוח להגדיר את ה-SSD כ-Cache במערכת שהקמנו) – בין אם זה NFS או iSCSI או CIFS ו"לשדך" את זה למערכת ה-ESXi (ה-CIFS הוא למקרים אם אתם משתמשים ב-Hyper-V לדוגמא).

והרי לנו שרת NAS שיכול לתת לנו פתרון שעוקף פתרונות NAS הרבה יותר טובים מפתרונות NAS זולים סגורים.

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

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

על פריצות "מבפנים" ועל דרכים להקשות זאת

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

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

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

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

בדרך כלל, לפני פריצה כזו, הם יבצעו תחקיר בסיוע כל דבר אפשרי (ריגול דרך האינטרנט ברשתות חברתיות, ריגול "קלאסי" תוך שימוש בסוכנים שנמצאים בארץ) כדי למצוא מי האנשים שאותם הם הולכים לתקוף במובן הסייבר. הם יחפשו אנשי IT ואם אפשר – אנשים שיש להם כמה שפחות ידע/נסיון בתחום ה-IT אך שיש להם גישה פנימית למערכות, אחד כזה שלמחשב שלו בעבודה יש חיבור לאינטרנט ול-LAN הפנימי, והוא לא ממש שם לב לשינוי בין URL כמו secure.iec.co.il ל-secure.iec.co.il.info (דוגמא פיקטיבית, אין לי מושג ירוק בתשתית של חברת חשמל). נניח שהראשון מפנה ל-ADFS או משהו חשוב אחר. ה-URL השני שנתתי הוא מזויף והפורצים הקימו אותו (כולל העתקה של גרפיקה עד לביט האחרון) כך שאותו איש IT לא יחוש בסכנה ויכניס את פרטיו האמיתיים להיכנס למערכת. (אגב, טריק ששמעתי שמשתמשים בו אחרי הכנסת שם משתמש וסיסמא הוא להציג הודעה של שם משתמש/סיסמא שגויים כדי "לשאוב" שמות משתמש וסיסמאות נוספות מאותו איש IT).

לאחר מכן יעשו נסיונות לגרום לאותו איש IT להוריד קובץ כלשהו להפעיל אותו. בד"כ אותם קבצים לא יזוהו ע"י מערכת האנטי וירוסים כקבצים מסוכנים (יש לפורצים ממומנים תקציב מספיק גדול כדי לקנות את כל האנטי וירוסים ולבדוק את הרוגלות/פורצות שלהן על אותן מערכות אנטי וירוס ולוודא שאף אחת מהן לא "תקפוץ"). במידה ואותו איש IT הוריד את הקובץ והפעיל אותו, המערכת כבר תחפש דרך לצאת לאינטרנט ולהקים Tunnel דינמי שיוכל לשלוח צילומי מסך, RAT, Key logger וכו'. במידה והם לא יצליחו, הם יחפשו דרך לבצע זאת פיזית (המוסד מומחה בזה, לפי מקורות זרים).

מהרגע שאותו קובץ פועל, לפורצים יש בעצם גישה. סביר להניח שהם יפתחו איזו מערכת C&C (ר"ת Command & Control) כדי לראות איך לגשת אל המערכת, ומכיוון שמשתמשי IT רבים משתמשים בתוכנות כמו SecureCRT ותוכנות אחרות המאפשרות גישה במקביל לשרתים, יש עכשיו לפורצים דרך להיכנס למערכות האחרות עם ההרשאות של אותו איש IT ומהמחשב שלו, כך שסביר להניח ששום מערכת מניעה לא ממש תזהה פעילות חריגה. תזכרו – בשלבים הראשונים, הפורצים לא משנים קבצים וקונפיגורציות, הם לומדים.

אז … מה ניתן לעשות כדי להקשות?

יהיו כאלו שיציעו להשתמש ב-Smart Card. רעיון לא טוב, מכיוון שבד"כ ה-Smart Card נמצא בתוך המחשב ולא מוציאים אותו ואת ה-PIN אפשר לתפוס עם key logger. אז הפתרון הזה עף החוצה.

פתרונות אחרים שיכולים לעזור, הם פתרונות שבעצם מבוססים על אימות כפול, תוך שימוש בטביעת אצבע עם ציוד בחיבור USB או באמצעות TOTP (ר"ת Time Based One Time Password) שמותקן על הטלפון הסלולרי. אפליקציה פופולרית לכך (שנמצאת ב-Repo של כל הפצת אינטרנט) היא Google Authenticator (האפליקציה לא מצריכה חיבור אינטרנט).

איך מיישמים זאת? בכמה צעדים, תלוי במערכת:

  • מערכות לינוקס רחוקות עם כניסת SSH: אם נחליט על TOTP עם שימוש באפליקציה כמו ה-Google Authenticator (יש אפליקציות אחרות ויש גם את המפתחות RSA המפורסמים, כולם עושים את אותה עבודה), נוכל לעקוב אחר ההוראות כאן כדי להתקין זאת. משהו שצריך לקחת בחשבון – תצטרכו להעיף מפתחות SSH מקובץ ה-authorized_keys על מנת שה-TOTP יפעל. כך שתנסו להיכנס לאפליקציה, המערכת תבקש ממכם קוד וידוא שיופיע לכם באפליקציה בטלפון (או במפתח RSA הפיזי).
  • מערכות לינוקס/Windows מרוחקות עם כרטיס Yubikey (גוגל בקרוב מוציאה מוצר מתחרה שנקרא Google Titan, גם הוא פתרון מבוסס FIDO2) – בדרך זו יש לחבר ל-USB מפתח ובכל פעם להעביר את האצבע כשיש צורך לבצע אותנטיקציה. השיטה הזו יותר מאובטחת משיטות שימוש בקורא טביעות אצבע שמובנה במחשב). גם כאן, תצטרכו לבצע תהליך התקנה, רק שכאן יש גם שימוש ב-OpenPGP. כל הפרטים נמצאים כאן.
  • מערכות Windows (תוך שימוש ב-RDP): פתרון חינמי אין למיטב ידיעתי, יש פתרון מסחרי שתומך גם ב-TOTP וגם ב-FIDO2, יש פתרון של חברת ROHOS כאן.

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

וירטואליזציה כקוד פתוח – כפתרון טוב

לפני כשבועיים פרסמתי את הפוסט הזה שמדבר על פתרונות אלטרנטיביים ל-vSphere של VMWare. הפעם אני רוצה לדבר על פתרונות קוד פתוח כפתרונות טובים לוירטואליזציה ומדוע RHV/oVirt הוא פתרון שעולה על רוב פתרונות הקוד הפתוח.

פתרונות וירטואליזציה בקוד פתוח מתחלקים בעצם ל-2: אלו שמעוניינים לנהל מספר קטן של שרתים פיזיים וצרכי הוירטואליזציה שלהם בסיסיים, ואלו שמעוניינים בפתרון וירטואליזציה מלא כולל הדברים המתקדמים, משהו כתחליף ל-Hyper-V (עם הניהול המרכזי) או תחליף ל-ESXI+vCenter.

כשמדובר בצרכים בסיסיים לוירטואליזציה ומדובר בכמות קטנה של שרתים (נניח 2-5), ומדובר, לשם השוואה, בדברים ש-ESXi עצמאי (ללא vCenter) יכול לתת – אז הפתרונות שהצעתי בפוסט הקודם יכולים לתת זאת ללא בעיה. יותר מכך, כל הפתרונות (למעט שימוש ב-KVM וב-libvirt עם סקריפטים) שהצעתי גם יכולים לתת לכם ניהול מרוכז של השרתים שלכם בממשק Web.

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

  • שימוש ב-vSwitch (בגירסת הקוד הפתוח – Open vSwitch) כ-SDN
  • הקמה אוטומטית של מכונות VM
  • שימוש ב-Grafana לתצוגת מצבי מכונות, דיסקים, מעבדים וכו'
  • High Availability מלא
  • אופטימיזציה לשימוש ב-NVME SSD תוך הגדלת I/O Threads
  • תמיכה מובנית ב-DR
  • יצוא/יבוא OVA/OVF
  • תמיכה במעבדי Power של IBM
  • תמיכה בכל פרוטוקולי הסטורג' (NFS, iSCSI, Fiber) + דיסקים מקומיים ו-GlusterFS
  • תמיכה במעבדים חדשים (EPYC, Xeon SP – ברוב הפתרונות המוצעים זה לא יעבוד טוב, במיוחד כשמדובר ב-HA).
  • ניהול מרוכז של כמות שרתים גדולה (עד 400 מכונות פיזיות)
  • פרופילים (סוגי מכונות, גדלים ועוד) כולל High Performance VMs.
  • תמיכה מורחבת ל-Over Commit
  • יבוא/יצוא של Images מ-OpenStack Glance (לא חייבים OpenStack מותקן בחברה).
  • פורטל למשתמשים (לאלו שצריכים לגשת למספר מכונות VM, ולנהל את אותן מכונות VM)
  • תמיכה במספר סוגי LDAP (כולל AD)
  • התממשקות ל-vCenter ויבוא מכונות VM
  • אפשרות לעבוד במצב הרגיל או במצב HCI.
  • תמיכה מלאה ב-GPU וב-VDI.
  • ועוד הרבה פונקציות אחרות.

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

האם פתרון כמו RHV/oVirt יכול להיות תחליף מלא ל-vSphere? התשובה היא: עדיין לא. העניין קשור יותר ל-Kernel ולדברים מתקדמים אחרים שלא קיימים ב-RHEL-7/CentOS-7 (שעליהם oVirt/RHV רץ):

  • Fault Tolerance עדיין לא זמין בגירסה הנוכחית (4.2)
  • VAAI/VVol – יש תמיכה ב-Kernel 4.X כך שנצטרך להמתין ל-RHEL-8/CentOS-8.
  • תוספים כמו vRealize ואחרים (שהם בתשלום) – יש להם חלופות. חלקם בחינם, חלקם בתשלום.

בכל הקשור לפתרונות וירטואליזציה, הגענו לזמנים טובים, למען האמת. רק לפני 3 שנים אם חברה גדולה היתה שואלת אותי לגבי פתרונות אחרים ל-VMWare או Hyper-V, הייתי ממליץ להם לנהל מו"מ בינם לבין מיקרוסופט ו-VMWare כי הפתרונות לא היו מספיק לדעתי טובים לשום Enterprise. פתרונות כמו Proxmox או פתרונות מבוססי Xen היו קיימים, אך לדעתי הם אינם נותנים מענה מספק ל-Enterprise (אם כי הם היו בהחלט יכולים לתת מענה לעסקים קטנים). בשנים האחרונות, החברה שהשקיעה הכי הרבה בפיתוח פתרון וירטואליזציה טוב היתה דווקא רד-האט. המצב בשוק פשוט התהפך: מיקרוסופט ו-VMWare היו עסוקים בפתרונות וירטואליזציה ואילו רד-האט היו עסוקים בפיתוח פתרונות מבוססי קונטיינרים (OpenShift) וב-3 השנים האחרונות רד-האט משקיעה הרבה יותר בפיתוח פתרון וירטואליזציה וגם בשיפור OpenShift, בשעה שמיקרוסופט ו-VMWare בשנתיים האחרונות יותר מתעסקים בפתרונות קונטיינרים.

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

במקרה חרום

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

נתחיל בעניין ה-DR/DRP. כן, אני מודע לכך שהנושא היה "שוס" ב-3 השנים האחרונות, ערימות של מסמכים נכתבו על הנושא פנימית וחיצונית בחברות שונות בארץ ובעולם וכמובן שחברות רבות רכשו חבילות תוכנה/שרותים ורכשו ציוד שיושב באיזו שהיא חווה (או באחד מהעננים הציבוריים) והמערכת מסתנכרנת תדיר בין ישראל לבין המיקום השני. הפתרון הזה הוא פתרון מעולה כאשר חברה נותנת שרותים לקהל לקוחותיה שנמצאים מחוץ לחברה. במקרים כאלו, התשתית המרוחקת (לאחר שינוי DNS) תתן שרותים וכשהתשתית הישראלית תחזור לפעילות, הנתונים יסתנכרנו ארצה.

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

אין תקשורת. החוצה.

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

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

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

  • שימוש ב-DNS פנימי, 2 שרתי DNS שמסונכרנים ביניהם תדיר עם AD ו-DHCP. (סביר להניח שזה מצב קיים אצל הרוב, אבל יש כאלו שהעבירו את זה לענן. תתפלאו).
  • שרת מייל פנימי – נכון, אין אפשרות לקבל/לשלוח מיילים מחוץ לחברה אך במקרים רבים המיילים/יומנים הם פנימיים ולכן שרת מייל פנימי יוכל לבצע זאת. (מכיוון שאינני מומחה Exchange, כדאי לשאול את מיקרוסופט איך מסנכרנים שרת כזה ל-365 אחרי שהתקשורת חוזרת).
  • שרתים (VM) שעברו לענן – כדאי להקים אותם פנימית בחברה עם DB ו-Snapshot שמתעדכן תדיר, עם כתובות FQDN זהות פנימית לשרתי DNS שציינתי בנקודה הראשונה, כך ששירותים חיוניים יופעלו מהתשתית המקומית בהיעדר תקשורת החוצה.
  • גיבוי – לוודא היטב שיש גיבוי מקומי והוא תקין (כן, מומלץ להריץ Verify על הקלטות). תזכרו – אין תקשורת, אין DR מרוחק.

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

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

אנשי שיווק מול אנשי מקצוע

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

ואז שאלתי: איזה פתרון וירטואליזציה אתם הולכים להריץ? הם נקבו בשם מוצר. תשובתי: זה לא ירוץ.

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

תשובתי: אם אדוני מעוניין, אשמח לחבר אותו ל-LAB אצלי, שם המוצר שבחרתם רץ, ואשמח להראות לאדוני שהמוצר שבחרו אינו עושה את אותם דברים עם הברזלים שיש לכם.

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

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

עוד דוגמא: חברה מסויימת פנתה אליי בקשר למוצר שהם משתמשים וכבדרך אגב אותו אדם שפנה אליי סיפר לי שגם להם יש שרתים כמו שרכשתי (X3550 M3 של IBM) והם בדיוק הולכים  לרכוש הרחבת זכרון ל-256 ג'יגהבייט. הסברתי לבחור משהו פשוט: אתה תרחיב זכרון, ותראה נחיתה של 40% בביצועים. הוא לא האמין, הנציג שמוכר לו את הזכרון לא סיפר לו כלום על כך, אז שלחתי לו מסמך של לנובו שמראה שבשרתים עם מעבדים המבוססים על פלטפורמה של Westmere או Sandy Bridge, ברגע שממלאים את הזכרון, מהירות הזכרון יורדת מ-1333 מגהרץ ל-800 מגהרץ. אז יהיה יותר RAM, אבל הגישה תהיה יותר איטית. עדיף להוסיף שרתים – וזה ההבדל בין מישהו מקצועי לאיש שיווק.

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

  1. הפתרון שלהם מתאים אולי לשנת 2000, לא לשנת 2018.
  2. אין שום גדילה אופקית בפתרונות שהציעו
  3. אין שום שרידות רצינית בפתרונות שהציעו
  4. אין שום עדכוני אבטחה בפתרונות שהציעו.
  5. ההשקעה הכספית הראשונית גבוהה.
  6. הפתרון שהצעתי לאותה חברה הוא פתרון מבוסס קונטיינרים בענן. לאותה חברה יש ספק ענן מועדף ובכל הקשור לתמחור – יש לפנות לאיש השיווק של אותו ספק ענן.

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

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

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

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

מעבר ל-CI/CD בחברות גדולות

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

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

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

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

  1. לבחור צוות שיעבור ל-CI/CD מתוך כל הצוותים שיש בחברה. כדאי שבצוות יהיו אנשים עם מוטביציה ועם ראש פתוח. בלי זה – המעבר יכשל, מבטיח לכם.
  2. להעדיף כלים מבוססי קוד פתוח או פתרונות מסחריים מבוססי קוד פתוח. כלים קנייניים הם מקור לצרות בעולם ה-CI/CD שמתפתח בקצב מהיר. לעומת זאת, כלים בקוד פתוח צריכים בד"כ הרצה של פקודת YUM או APT כדי לעדכן.
  3. האם בהזדמנות זו מכניסים פתרון קונטיינרים? (אפשר לבצע CI/CD ללא קונטיינרים) – אם כן, כדאי להחליט אם הולכים על פתרון מסחרי של Kubernetes (כמו CAAS של SuSE) או על OpenShift של רד-האט שהוא גם מבוסס Kubernetes אבל נותן הרבה הרבה יותר יכולות. (ישנם כמובן גם פתרונות אחרים אבל הם לא עונים לצרכים של Enterprise).
  4. פיתוח כ-Multi Platform – חשוב במיוחד לבנקים, חברות ביטוח וחברות פיננסיות. זה נחמד וטוב לפתח ל-Windows אבל אפשר בעזרת עבודה די קצרה לעבור ל-Multi Platform. עובדים ב-JAVA? מצוין, אפשר גם עם לינוקס, צריך בסה"כ לשנות מספר סקריפטים (אם כתבתם) כדי לעבוד בלינוקס. עובדים עם Dot Net? תכירו את Dot Net Core שמאפשר לכם עבודה עם Windows ולינוקס. היתרון של עבודה עם לינוקס הוא שמגוון רחב של כלים יהיה זמין לכם (במיוחד אם אתם עובדים עם קונטיינרים).
  5. טסטים טסטים טסטים … יש עדיין מקומות שמעסיקים אנשי QA. ברוב המקומות לעומת זאת, כבר אין חיה כזו מהסיבה הפשוטה שהיום פשוט כותבים טסטים שרצים במערכת כמו Jenkins המבצעים בדיקות Unit testing ועוד מספר סוגי טסטים על מנת לוודא שמה שמפותח – הוא יציב ועובד.

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

ועוד משהו אחד שרבים לא יאהבו שאני כותב זאת: החיה הזו בשם "איש Devops" זו המצאה שגויה של אנשים שלא מבינים מה זה Devops. הבה נסתכל על משהו פשוט בחברה גדולה: החברה מחליפה תוכנת גיבוי, תוכנת Code Repository, אולי כלי אוטומציה ועוד מספר דברים. האם אותה חברה צריכה פתאום שכיר נוסף? לא, כי צוות ה-IT אמור לדעת לתמוך בכלים. אפשר לקרוא למישהו מבחוץ שילמד ויתרגל את הצוות, אבל הצוות יכול בהחלט להמשיך ולתחזק את אותם כלים. אדרבא, הן אנשי ה-IT והן צוותי הפיתוח צריכים להכיר את הכלים (ברמות מסויימות כמובן, ה-IT ברמה של Sysadmin והשאר ברמה של Usage).

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

רכישת/מכירת שרתים יד שניה, פוסט המשך

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

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

מס' אנשים תלו (ותולים) תקוות שחברות אחרות ירכשו את השרתים שלהם, אך האמת הדי פשוטה היא שרוב החברות בארץ פשוט לא רוכשות שרתים יד שניה (למעט כמובן חברות סוחרים כמו All Trade ואחרים) מהסיבה הפשוטה: חידוש אחריות ל-3 שנים הכוללת הגעת טכנאי בזמן SLA  של 4 שעות – יהיה יקר בהרבה ממחיר רכישת השרת. כך לדוגמא, אם רכשתם שרת יד שניה ב-1500 שקל, עלות השרות שציינתי לעיל תעלה בסביבות 6000-10000 שקל, בשעה שרכישת שרת חדש עם הוספה של תמיכת SLA ל-4 שעות תעלה הרבה פחות בהשוואה לרכישת השרות לשרת יד שניה, כך שכל חברה שאפילו תחשוב על רכישת יד שניה ותרצה SLA כזה, תרד מרכישת שרת יד שניה.

מה לגבי ציודים שבשרתים? אז כך:

  • מקלות זכרון בגודל 1,2,4 ג'יגהבייט – אין להם בד"כ דרישה בשוק, כך שמי שרוצה למכור זכרונות ECC יכול לנסות את מזלו אולי ב-eBay. הדרישה בשוק בד"כ היא למקלות זכרון בגודל 8 ג'יגה ומעלה עם תיוג PC3 10300 או PC3 12800. גם עם מקלות אלו אין הרבה "בשר" מבחינת כסף להרוויח הואיל ורוב המוכרים (שוב, למעט חברות שזה מה שהן מציעות) פשוט לא נותנים שום אחריות לזכרונות, ולכן לדוגמא מקלות זכרון של 8 ג'יגה שווים בערך 20-40 שקל פר חתיכה (בסביבות ה-50-60 לזכרון PC3 10300 בהנחה שמדובר ב-DDR3 ECC).
  • דיסקים קשיחים – לא מומלץ לשום חברה שמעוניינת למכור את הציוד, למכור או לתת את הדיסקים הקשיחים עקב עניינים של אבטחת מידע. השרת מבחינתכם "מת"? העבירו את הדיסקים לגריטה. דיסקים SSD – לא מומלץ לרכוש יד שניה מכיוון שכמות הכתיבה עליהם מוגבלת ודיסקים SSD יד שניה בד"כ אינם כוללים בקרים מורכבים כך שסביר להניח שה-SSD ימות עוד לפני שתימלא לו שנה לאחר רכישה מיד שניה.
  • מעבדים – מאוד תלוי בדגם השרת. שרתים כמו Gen9 של HP (או R730 של Dell או M5 של לנובו) יכולים לקבל מעבדי Xeon E5 v4 כשדרוג במקום E5 v3 (כל מה שצריך זה לשדרג BIOS לגירסה האחרונה לפני החלפת מעבדים), ולכן גם כאן, מי שרוצה לרכוש שרת יד שניה, עדיף שירכוש את המעבד הכי "נמוך" שאפשר וישדרג ברכישת מעבדים ב-eBay. למוכרים – זו עיסקת חבילה ובקטע הזה לא תקבלו הרבה גם על הדגמים עם הכי הרבה ליבות.

מה לגבי מחירים? הפופולריים ביותר אלו הם שרתי 1U ו-2U מה-5 שנים האחרונות (אלו שלפני כן נמכרים במחירים של 3 ספרות). כך לדוגמא שרת Gen8 של HP עם 192 ג'יגהבייט זכרון ועם מעבדים בעלי 8 או 10 ליבות נמכרים במחירים של 1000-1500 שקל (ה-1500 זה אם יש דיסקים חדשים). Gen7 של HP נמכרים בסביבות ה-600-900 שקל עם 208 ג'יגהבייט זכרון לדוגמא, כך שכמו שאתם רואים – הרבה כסף אי אפשר לעשות מזה.

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

סוויצ'ים, UPS – גם כאן, המחירים נעים סביב ה-3 ספרות. UPS לדוגמא לא שווה הרבה אחרי 6-9 שנים של שימוש מכיוון שיש צורך להחליף סוללות פנימיות (והן יקרות!). סוויצ'ים לעומת זאת, חברות רבות נפטרות מהמתגים במהירות 1 ג'יגהביט לטובת מתגים במהירות 10 ג'יגה ומטה, כך שגם כאן המוכר לא יעשה מזה הרבה כסף והרוכשים הפרטיים יכולים אולי למצוא הזדמנויות טובות לשדרג LAB או להוסיף מתג לדברים/פרוייקטים צדדיים.

אז מדוע חברות כמו All Trade מוכרת במחירים כאלו גבוהים שרתים יד שניה? הסיבה פשוטה: הם חייבים להחזיק מלאי והם מוכרים שרות, כך שאם לדוגמא הם רכשו מלאי של 10 שרתי Gen8, הם יוכלו למכור רק 5-7 כאלו כי הם חייבים להחזיק שרתים אחרים כמלאי להחלפה בעת תקלות חרום כחלק מהשרות שהם מוכרים.

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

הפצה מול הפצה: רד האט מול SuSE

בעולם ה-Enterprise יש כיום 2 הפצות לינוקס מרכזיות שנותנות פתרונות מלאים לשוק זה והן RHEL של חברת Red Hat ו-SLE של חברת SuSE. הפעם ננסה לבחון מי מהן טובה יותר בכל מיני קטגוריות, לא כולן טכניות.

נתחיל מבחינה טכנית של הטמעה ושימוש: לשתי ההפצות יש התקנה מסודרת שיודעת לתמוך במגוון ציודים שיש בשרת, בין אם הן רצות "על הברזל" או על מכונה וירטואלית או כ-Image בסיס לקונטיינר. ב-99% מהמקרים לא תצטרך לחפש דרייברים נוספים (למעט כרטיסים של nVidia, אם כי SuSE מציעה פתרון שאינו מצריך חיפוש והורדה של דרייברים). אם כל מה שאתם עושים בלינוקס נמצא בתוך החבילות של ההפצה, אין שום בעיה לעבוד עם כל אחת מההפצות, והשינויים בין הפצה אחת לשניה אינם כה מהותיים. פה yum ושם zypper.

למרות זאת, עם כל האהבה שלי ל-CentOS/RHEL, ל-SuSE יש מספר יתרונות על רד-האט שחשוב לדעת עליהם, לדוגמא:

  • הפצת SLE מתקדמת יותר מההפצת לינוקס של רד-האט. יש שם Kernel חדש יותר, והכלים עצמם יותר מעודכנים ויותר מודרניים, כך שאם לדוגמא מתקינים Kubernetes, אז לא צריך לחפש אותם במאגר צד ג' כלשהו, מה שמגיע עם ההפצה זו הגירסה האחרונה היציבה, וכנ"ל שאר כלים נוספים כולל קומפיילרים וסביבות פיתוח יותר עדכניות.
  • הפצת SLE קלה יותר להגדרת דברים. ב-SLE יש כלים כמו yast2 שמאפשרים להגדיר הרבה דברים במערכת, החל מ-NFS, iSCSI, רשת ועוד ועוד מבלי לדעת איזה פרמטרים להכניס בקבצי ההגדרה.
  • ויש עוד דברים…

נמשיך מכאן להפצות עבור שימוש בכלים או פלטפורמות יחודיות להפצה. לדוגמא OpenShift במקרה של Red Hat, או SES במקרה של SuSE או OpenStack במקרה של שתי ההפצות: הגרסאות שההפצות מוציאות רצות אך ורק על הפצות הלינוקס מתוצרתיהן, כך שלדוגמא OpenShift לא ירוץ על SLE וגירסת ה-SES או OpenStack של SuSE לא ירוצו על מערכת של Red Hat (ניתן כמובן לעשות טריקים שכן ירוצו אך לא תקבלו לכך תמיכה רשמית). לכל אחת מההפצות יש שינויים ותוספים יחודיים לה (לדוגמא מערכת OpenAttic שנמצאת ב-SES), כך שבמקרים כאלו אם ארגון מסויים מעוניין במערכת של אחד היצרנים והפצת הלינוקס אינה ההפצה הרגילה של שאר מערכותיו, הוא יכול להתקין את את ההפצה והפלטפורמה כמעין "Appliance". הן מערכות RHEL והן מערכות SLE ניתנות להגדרה בקלות לניטור ולביצוע פעולות אחרות והן אינן מערכות סגורות.

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

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

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

החל ה"מרדף" אחר החלפת הדיסקים קשיחים שלכם

כמעט בכל חברה גדולה בארץ יש שרתים ואם נסתכל בשרתים – ברוב המקרים נמצא דיסקים קשיחים מכניים. הם לא מהירים כמו דיסקים SSD, אבל הם "סוסי עבודה" שעושים עבודה טובה. אני די בטוח שהיו למנמר"ים או אנשי IT הצעות להחליף את הדיסקים האלו ב-SSD ובוודאי בחלק מהמקרים הדיסקים המכניים הוחלפו ב-SSD, אבל בד"כ חברות לא ממהרות להחליף – בגלל המחיר. אחרי הכל, מחיר ממוצע של SSD ל-Enterprise עולה הרבה יותר מאשר דיסק מכני SAS או NL-SAS ל-Enterprise.

מי שקורא את הפוסטים בבלוג זה, אולי קרא את הפוסט הזה שכתבתי על סוגי SSD וגם כתבתי על סוג שבבי NAND חדש עם תאי QLC (כלומר ניתן לכתוב 4 ביטים בתא אחד, בניגוד ל-SLC שבו ניתן לכתוב רק ביט אחד, אבל בהשוואה ל-QLC הוא הרבה יותר מהיר בכתיבה). החסרון הגדול של QLC זו הכתיבה האיטית ולכן דיסקים SSD מבוססי QLC NAND Flash לא מיועדים להתחרות מול SSD רגיל.

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

הבה נודה על האמת: דיסקים מכניים בגודל 2.5" לא התקדמו כמעט בשנים האחרונות. ברוב המקרים הדיסק הכי גדול ל-2.5" ל-Enterprise הוא בגודל 2 טרהבייט (יש כמובן גם 5 טרהבייט אם כי הם אינם מיועדים ל-Enterprise ובכל מקרה לא בטוח הם יוכלו להיכנס לשרת שלכם אם השרת הוא של HP לדוגמא – המערכת פשוט תקפיץ הודעה שזה לא נתמך והיא לא תציג התראות מדיסק כזה). המהירות שלהם אינה גבוהה (בין 200-270 מגהבייט ב-Sequencial Read).

חברת Micron, בשיתוף פעולה עם אינטל, הציגו אתמול את ה-SSD מבוסס QLC הראשון שלהם. עדיין אין הרבה פרטים ציבוריים עליו ובאתר Toms Hardware כתבו כמה מילים לגביו.

טכנית, הדיסקים הללו, כפי שציינתי לעיל, מיועדים להיות "באמצע" – בין כוננים מכניים ל-SSD שכולם מכירים ל-Enterprise. הכתיבה שלו לא מהירה בהשוואה לשום SSD שקיים בשוק (כן, גם בהשוואה ל-SSD שעולה 1000 שקל בחנות מחשבים), אולם מהירות הקריאה שלו היא כמו מהירות קריאה של SSD ל-Enterprise, כלומר אתם תקבלו מהירות של 550 מגהבייט לשניה (שוב, ב-Sequencial Read, ב-Random התוצאה תהיה מעט שונה ואם משתמשים ב-Queue Depth התוצאות יהיו לא רעות .. הייתי מרחיב אבל יש אמברגו עד לסתיו הקרוב).

הגדלים של הדיסקים הללו יהיו שונים מגדלים של דיסקים מכניים. ה-5210 ION יהיה זמין בגדלים החל מ-2 טרהבייט ועד 8 טרהבייט (אני מעגל את המספרים), כך שתיאורתית דיסקים כאלו יכולים להחליף גם דיסקים מכניים בגודל 3.5" (ניתן לאכסן תיאורתית בשרת בגודל 1U עם 10 כניסות דיסקים – כמעט 80 טרהבייט של DATA).

והשאלה הכי חשובה לפני שחושבים לרכוש דבר כזה בעתיד: לאיזה עומסי עבודה זה מתאים? ובכן, התשובה היא במובהק לעבודות Read Intensive. זה לא מיועד לאכסן שרת SQL או נתונים של שרת SQL, זה לא מיועד לשמש כדיסקים לוקאליים עבור הרצת מכונות VM. זה מיועד יותר לאחסן תוכן סטטי, כך שאם אתם מריצים פורטל ארגוני גדול בחברה לדוגמא, דיסק כזה יכול לאחסן את התכנים עבור הפורטל (בנוסף לדיסק רגיל שיאחסן את השרת ה-Web ו/או ה-Application Server). חשוב לזכור: כמות הכתיבה/מחיקה על כל תא היא מוגבלת (בסביבות ה-1000 פעם, אבל בד"כ בקר ה-SSD עושה עבודה חכמה שלא תגיעו לזה)

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

לסיכום: SSD עם תאים QLC מגיע לשוק. זה לא מתאים לכולם. כרגע יהיו הכרזות ל-Enterprise ובהמשך זה יזלוג לשוק הסמי-מקצועי ושוק הצרכנים. האם הייתי ממליץ לצרכן לרכוש דיסקים SSD כאלו? הפיתוי יהיה גדול הואיל והוא יהיה יותר זול מ-SSD מבוסס TLC או MLC (וצרכנים לא מודעים יקנו כאלו "כי זה SSD") – וזה יכול להתאים לשוק הביתי, אך לא לשוק המקצועי (במיוחד אם יש צורך לטפל בקבצים גדולים במהלך העבודה).