הבלוג של חץ ביז

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אז מה ניתן לעשות? כל עוד מדובר במציאת פרילאנסר, אפשר לבצע כמה דברים:

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

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

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

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

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

קישורים:

1. XPLACE – אחד האתרים הגדולים בארץ למצוא פרילאנסרים ולפרסם פרויקטים (אגב, פרסום הפרויקט הוא בחינם) – מאוד פופולרי
2. Freelancerim – עוד אתר בתחום בארץ
3. vlancer
4. Find a freelancer
5. פורום "הייטק פרילאנסרים" בפייסבוק

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