על CI/CD ועל Jenkins

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

נתחיל בהסתכלות על המצב ה"קלאסי" של פיתוח, אצל חברות שמפתחות תוכנה המשווקת לציבור. בחברת הפיתוח יושבים כמה מפתחים וכל אחד (או קבוצה) אחראים לפיתוח חלק כלשהו. GUI, לוגיקה, ועוד ועוד. כל קבוצה (או יחידים) מפתחים בנפרד ובסוף יום (או כמה פעמים ביום) כל אחד מעלה את הקוד שלו למערכת SCM (ר"ת Source Code Management) ואחת לזמן מה מגיע החלק הקשה – איחוד הקוד של כל האינדיבידואלים או הקבוצות השונות לקוד אחיד למה שיהיה בהמשך גירסה חדשה של התוכנה. באיחוד כזה מתרחשים הרבה קונפליקטים מבחינת קוד – אחד שבר (בטעות) קוד ישן, השני הגדיר דברים בצורה שונה והקוד שלו בעייתי לאיחוד, ויש עוד שלל בעיות באיחוד קוד (שלא לדבר על ההערות שנזרקות…) שנכתב לאורך תקופה ללא איחוד. אלו כמובן בעיות שיש להן פתרון (במיוחד עם GIT..) ולכן עולה השאלה "בשביל מה אנחנו צריכים CI/CD אם אנחנו לא סטארט-אפ?"

ל-CI/CD (ר"ת של Continuous Integration ו-Continuous Deployment בהתאמה) יש (די בצדק) שם שמתאים לפיתוח בדרכים של ASD (ר"ת Agile Software Development) או בשם יותר ידוע – XP (ר"ת Extreme Programming), מה שדי מרתיע חברות פיתוח "קלאסיות" מאימוץ CI/CD, אבל יש יתרונות גדולים ל-CI/CD:

  • זמן פיתוח קצר בהרבה
  • שמירת תאימות לאורך זמן
  • תיקון באגים בזמן קצר בהרבה בהשוואה למצב הקלאסי
  • ה-Time To Market מתקצר משנים לימים או שבועות.
  • לקוחות מקבלים יותר פונקציונאליות ושרותים נוספים מבלי להמתין זמן רב עד שהחברה תכתוב את הקוד הכרוך בפונקציונאליות הנוספת.
  • קל למצוא באגים בקוד ולתקן במהירות.
  • כל המערכת רצה בצורה הרבה יותר יציבה
  • זמן ה-Downtime מתקצר לאחוזים בודדים

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

Image result for jenkins logoנכיר בקצרה את Jenkins. מערכת Jenkins נוצרה ב-2005 ע"י מפתח שעבד ב-Sun ו-Sun שחררה את הקוד לקהילה והמוצר עבר שינויים שונים במהלך חייו והיה נקרא Hudson. ב-2011 חברת אורקל (שרכשה את SUN) הצליחה להסתכסך עם קהילת המפתחים בקוד פתוח ולפיכך המפתחים החליטו לקחת את הקוד ולפצל (Fork) את המוצר ולתת לו שם חדש: Jenkins.

ל-Jenkins ישנם יכולות רבות בכל מה שקשור ל-CI/CD. המערכת עצמה מתאימה הן למשימות פשוטות (קימפול קוד והנגשת קבצים בינאריים לשותפים עסקיים לדוגמא) ועד לעבודות מורכבות הקשורות להעברת קבצים בינאריים למערכות אחרות, המתנה לתשובות והעברה לפרודקשן, או להקמת מכונות VM חדשות שיריצו את החבילות הבינאריות החדשות, אך זה לא נעצר כאן – ל-Jenkins יש גם מספיק תוספים שמאפשרים פונקציונאליות כמו בדיקת סגנון קוד, הפצת קבצים בינאריים/חבילות (לדוגמא: artifcats) ועוד פונקציות רבות שמצריכות התקנת Plugin (לגבי מתחרים ל-Jenkins – ראו התייחסות בהמשך).

אחרי שהקמנו מערכת Jenkins, אנחנו מתחילים להשתמש בה והעבודה ב-CI/CD מתחילה עם המפתחים. אחרי שהמפתחים דחפו את השינויים מגיע תור ה-CI Server או במקרה שלנו – Jenkins לעשות את העבודה. ניצור JOB שבו בעצם אנחנו מגדירים ל-Jenkins מה לעשות. מהיכן לקחת את הקוד, מה לקמפל, ומה לעשות עם הקבצים (כמו לדוגמא האם להעביר אותם בדיקת סגנון קוד עם SonarQube לדוגמא) להעלות אותם ל-Artifactory, לשרת אחר וכו'.

מבחינת המפתחים, כשעובדים ב-Continuous Integration כל מפתח כותב את הקוד שלו, מוריד את הקוד של האחרים מה-SCM, משנה את הקוד שלו בהתאם על מנת לאחד אותו עם השאר, מריץ קוד בדיקות (Unite Testing), ולאחר שהקוד עבר בהצלחה בדיקות מקומיות, הוא מבצע Push ל-SCM. את התהליך עושים מספר פעמים ביום בכל פעם שכותבים חלק, לדוגמא – כותבים פונקציה חדשה, משפרים משהו קיים, מתקנים באגים וכו'. משם Jenkins ימשיך את תהליך ה-CI אם נגדיר לו מתי (אם לבדוק את ה-SCM אם מישהו ביצע commit לדוגמא, או לפי שעון).

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

מכאן אנו עוברים לחלק של ה-CD או ה-Continuous Deployment: קימפול והכנת קבצים בינאריים וחבילות זה טוב – אבל צריך לעשות עם זה משהו…

ב-Jenkins יש לנו "צינורות" (Pipelines) ועם הפונקציונאליות הזו אנחנו נגדיר ל-Jenkins מה אנחנו הולכים לעשות עם הקבצים הבינאריים. אנחנו יכולים לדוגמא להגדיר בצינורות לזרוק את הקבצים הבינאריים בשרת טסטים, להריץ טסטים שונים (Unit tests, Selenium ועשרות סוגים שונים של בדיקות, תלוי בקוד, פלטפורמה וכו'). לאחר שהקבצים עברו בהצלחה בחינה, אנחנו יכולים להורות בצינור לבצע Deploy של החבילות בשרת "מראה" של פרודקשן להתקין את החבילות ולהריץ בדיקות שונות נוספות. לאחר שגם כאן הבחינות עוברות, אפשר להורות בצינור להטמיע את החבילות החדשות בשרתי הפרודקשן באופן אוטומטי או לפי הוראה של המפתחים/מנהלים.

ci-cd-jenkins
כך נראית החלוקה בין CI ל-CD

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

בסופו של יום, לקוחות דורשים מיצרניות התוכנה והשירותים דברים רבים והם מעוניינים במענה מהיר ואם הם לא מקבלים, הם לא מתביישים להתחיל לבדוק את הפתרונות של המתחרים (תשאלו את Pay pal) ואף לעבור למתחרים, מה שעלול לגרום הפסדים כספיים. עבודה ב-CI/CD יכולה לעזור בקיצוץ הזמנים באופן ניכר.

מה לגבי מתחרים ל-Jenkins? ישנם לא מעט מתחרים ל-Jenkins בשוק (הנה לדוגמא טבלת השוואה קצרה בין ל-Jenkins ו-2 פתרונות אחרים מובילים, החלק של Open Source לא כל כך עדכני לגבי המתחרים), אך הבעיה הראשונה של רובם שהם פתרונות SAAS, כלומר שהמערכת אינה נמצאת אצלך בשרתים אלא אצל חברה אחרת ואתם משלמים לה. זה יכול להיות פתרון טוב אם הקוד כולו מהרגע הראשון הוא קוד פתוח, אולם מצד שני – אני לא מכיר הרבה חברות שיש להן קוד סגור שמעוניינות לבצע Build אצל חברות זרות. יחד עם זאת, כמובן – יש ויש.

מבחינת תאימות פלטפורמות – Jenkins הוא קוד פתוח מ-א' ועד ת' והוא רץ יפה מאוד על Windows (לא צריכים Windows Server), מק וכמובן לינוקס. הוא תומך בכל שפה, ויש לו יותר מ-1200 תוספים שונים שכוללים תמיכה בכל SCM, בכל קומפיילר, אותנטיקציה, אחסון וכו'. יחד עם זאת, כדאי לקחת בחשבון שלא כדאי "לערבב" – אם לדוגמא הקוד שלכם כתוב ב- #C, הקימו את Jenkins על Windows, אך אם אתם כותבים בשפות אחרות שרצות על לינוקס, עדיף להרים את ה-Jenkins על לינוקס הואיל ותחזוקת האבטחה הרבה יותר קלה.

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

[stextbox id="info" caption="הערת מפרסם"]הח"מ פרילאנסר שמחפש עבודות בתחום לינוקס, Devops, ודברים הקשורים ל-Software Defined Storage, וירטואליזציה וכו'. מי שמעוניין בפרטים – אפשר למצוא אותם כאן.[/stextbox]

השינוי המהותי שצריך במערכות הפעלה

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

אנחנו עובדים בשיטות האלו זמן רב, 22 שנה ליתר דיוק אם מסתכלים על השוק האינטלי לדוגמא, עוד מאז שאינטל הכניסה את Protected Mode למעבדי i386. אמנם Windows בזמנו לא נתנה ריבוי משימות אמיתי (היא נתנה "החלפת משימות" – Task Switching) אך מערכות יוניקס אחרות (SCO וכו') דווקא נתנו.

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

השינוי המהותי ביותר התחולל במערכות ה-Main Frame ולאחר מכן בוירטואליזציה על מערכות ההפעלה השונות: בעזרת אפליקציה/שרות היה ניתן להתקין מספר מערכות הפעלה שונות ולהריץ עליהן אפליקציות, ואותן אפליקציות לא היו מודעות כלל למערכות ההפעלה השכנות שרצות כ-Guest וכך קיבלנו מצב שגם אם היו פורצים ל-VM מסוים, שאר מערכות ה-VM לא היו מושפעות מכך בד"כ.

בעולם הלינוקס/יוניקס היו פתרונות שונים – ל-Solaris החל מגירסה 10 היתה תת מערכת של קונטיינרים שנקראה Zones שבה היה אפשר להרים מעין VM מבוסס סולאריס (בלבד, מאוחר יותר זה השתנה במעט) ובלינוקס היה בהתחלה את chroot ומאוחר יותר את LXC ובשנים האחרונות את Docker והמתחרה שלו – RKT. כל הפתרונות הנ"ל הציעו ברמת המאקרו סביבות נפרדות ללא צורך באמולציה של חומרה תוך הסתמכות על שרותי Kernel שרץ על השרת הפיזי. בעולם ה-Windows מערכת Docker הגיעה קצת יותר מאוחר בהשוואה ללינוקס, וכיום ב-Windows 2016 יש מערכת Containers מבוססת Docker.

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

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

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

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

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

[stextbox id="info" caption="הערת מפרסם"]הח"מ פרילאנסר שמחפש עבודות בתחום לינוקס, Devops, ודברים הקשורים ל-Software Defined Storage, וירטואליזציה וכו'. מי שמעוניין בפרטים – אפשר למצוא אותם כאן.[/stextbox]

טיפים בנושאי לימוד אונליין

כפרילאנסר שנותן שרות לדברים רבים הקשורים בלינוקס (אחרים ב-Windows או במערכות אחרות) אחד הדברים הראשונים שלמדתי – הוא שאתה לא יודע מה "יפול" עליך מחר מבחינת דרישות טכניות של לקוחות. כל לקוח והמערכות שלו, הגדרות שלו, אפליקציות ושרתים שלו וכל לקוח שונה מהשני. מחר אני יכול להרים ולתחזק שרת Jenkins עם Slaves וערימת סקריפטים הקשורים לכל מה שקשור ל-Build ו-Deploy, ומחרתיים אני אצטרך לכתוב מספר דברים ב-Python ועוד שבוע אני אצטרך לשבור את הראש מדוע אשכול (Cluster) של MySQL לא עובד טוב ואלו רק דוגמאות ספורות שכל פרילאנסר שנותן שרותים צריך להתמודד איתם, גם אם מדובר בכלים/פלטפורמות אחרות.

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

אחד הפתרונות ללימוד או רענון של שפת מחשבים, שרות או מערכת הפעלה – היא קורסים Online שחברות כמו Lynda.com, Oreily.com ואחרים נותנים הוא מנוי לספריה גדולה של קורסים שאתה יכול להיות מנוי, להתחבר, לבחור את הקורס ולעבור עליו בזריזות. זה טוב ונחמד, אבל הבעיה היא שהעלות של דבר כזה נעה בין 40-50$ לחודש. כלומר אם תעשה מנוי וגם אם תבטל אותו, הלכו 40-50$ כלומר שעת העבודה הראשונה שלך אצל הלקוח – תימחק מבחינת רווח. תוסיף עלויות של דלק, אוכל וכו' – ואם העבודה היא כולה שעתיים שלוש, תראה שבקושי יצאת עם משהו.

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

תרשו לי להכיר לכם את אתר Android Central Digital Offers. השם מרמז על דברים לאנדרואיד אבל אתר זה כמו עוד כמה אתרים – מציעים קטלוג של קורסים שכלל לא קשורים לאנדרואיד.

מה שמוצע באתר לעיל, הם קורסים שכרוכים בחבילות (Bundles) שקשורים בנושאים שונים כלליים. חלק מהחבילות לדוגמא מדבר על White Hackers, על VMWare, הסמכות MCSE ו-1001 דברים נוספים. הנה דוגמא:

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

vmware

כפי שאנחנו יכולים לראות בתמונה, אלו 3 החבילות, והן מוצעות במחירים זולים – 19$ ו-49$.

הבה נסתכל על ההצעה מימין. החבילה הזו בעצם מדברת על Complete White Hat Hacking & Penetration Testing Bundle. לא נשמע משהו שאנחנו צריכים אולם אם נסתכל מקרוב, הקוביה השניה משמאל מדברת על .. VMWare, כלומר אנחנו מקבלים את ה-VMWare בתוספת עוד כמה קורסים – והכל ב-19$. אם, אגב, נלך לאתר שמעביר את הקורס (כדי לדעת מי נותן את הקורס, נלחץ על הקוביה של ה-VMWare, נלחץ על ה-Instructor, שם יופיע לינק בכחול – לחצו עליו ותגיעו לאתר שנותן את הקורס) נראה שאותו קורס מוצע ב-202$. היי, חסכון לא רע בכלל! אבל מה שיותר יפה, הוא שבמקרה הזה עם נחזור להצעה ב-Digital Offers נראה משהו מעניין:

vmware2

הגישה שיש לנו לקורס זה היא לכל החיים מבלי לשלם סנט נוסף אחד.

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

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

טיפ חשוב – לחצו בדף של המוצר שבחרתם על Course Outline ותוודאו שהתכנים שאתם צריכים מופיעים שם. 19$ זה נשמע זול אבל אם התוכן שאתם מחפשים לא מופיע שם, אז חבל על הכסף.

עוד אפשרות נחמדה שיש באתר שמופיעה בחלק מהמקרים – זה Pay What You Want. נאמר שהחברה הכניסה לשימוש GIT ואתה צריך להכיר איך להשתמש בכלי הזה. חיפוש באתר של המילה GIT תתן לנו תוצאות והתוצאה לפני ה-Our Best Sellers תתן לנו את זה. אם נסתכל בחבילה, נראה שיש שם הרבה הרבה יותר מ-GIT, אבל בואו נסתכל על החבילה מקרוב (לחצו על התמונה להגדלה):

git-package

מספר 8 ברשימה זה מה שאנחנו צריכים – את GIT. השאר נחמדים ואם נרצה את כל החבילה, נשלם עליה 19$, אבל כרגע מה שמעניין אותנו זה GIT. ליד מספר 8 אין מנעול, ולכן אנחנו יכולים ללחוץ מימין על Pay What You Want ואנחנו יכולים להזין מספר מ-1 עד 19.36$, כלומר אתם יכולים לשלם דולר יחיד דרך Paypal ולקבל קישור Redeem שמאפשר לכם לצפות בקורס ובחלק מהמקרים גם להוריד את הוידאו שאינו מוגן ישירות למחשב שלכם, לשמור אצלכם על הדיסק הקשיח. מצד שני, אם אתה מפתח, אתה יכול לשלם את ה-19.36$ ולקבל שורה של קורסים שזמינים לך לכל החיים (ושוב, בחלק מהמקרים אתה פשוט יכול להוריד כל שיעור כקובץ MP4, יש שם קישורים להורדה בכל וידאו במקרה ואתה דואג שהאתר לא יהיה זמין בעתיד או שתרצה לצפות ב-Offline). עיסקה לא רעה, הייתי אומר.

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

אז האם כדאי לוותר על ההצעות של Lynda, Oreilly ואחרים למנוי? לא תמיד. אתרים אלו מציעים דברים עדכניים. אם לדוגמא בחברתכם יחליטו בהמשך לעבור ל-vSphere 6.5 לדוגמא, ב-Digital Offers לא תמצאו כלום. עדכונים להסמכות גם לא תמצאו באתר שהצעתי לעיל ובכלל קורסים של שפות תכנות, קורסים שמורכבים מעשרות שרות – עדיף את האתרים המקצועיים שמעבירים קורסים Online. האתר שהצעתי מתאים לרענון דברים שקיימים זמן רב ומאפשרים לאנשים לרענן את זכרונם במחיר זול.

[stextbox id="info" caption="הערת מפרסם"]הח"מ פרילאנסר שמחפש עבודות בתחום לינוקס, Devops, ודברים הקשורים ל-Software Defined Storage, וירטואליזציה וכו'. מי שמעוניין בפרטים – אפשר למצוא אותם כאן.[/stextbox]

הפצות לינוקס לחברות (2016)

[stextbox id="info"]הערה לקוראים: מדובר על דו"ח הפצות לינוקס ב-Corporate, לא בסטארט-אפים, לא בבית ולא במערכות משובצות.[/stextbox]

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

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

בעולם ה-Windows אף אחד לא מתקין לעצמו Windows Server 2012 R2 כתחנת עבודה. בלינוקס לעומת זאת, באופן עקרוני כל הפצת לינוקס יכולה לשמש הן לת"ע והן לשרת. אם תיקחו לדוגמא הפצה כמו CentOS 7.2 ותבחרו את הרכיבים הנכונים, לא תהיה שום בעיה להריץ אותה על כל שרת כ-שרת או על לאפטופ כמכונת דסקטופ רגילה. יחד עם זאת – ישנם הפצות שמיועדות יותר ל-Workstation, ויש ל-Server.

אני אחלק את ההמלצות לדסקטופ/תחנת עבודה (בקיצור – ת"ע) ושרתים.

מבחינת ת"ע, הבחירות שקיימות היום לשוק ה-Corporate הן ההפצות הבאות:

  • רד-האט 7.2 ותואמיו (CentOS, Oracle Linux)
  • אובונטו
  • SuSE Linux Enterprise Desktop (או בקצרה: SLED)

ישנן כמובן עוד הפצות כמו Debian, Gentoo, Arch ואחרות, אולם הם מיועדות לאנשי לינוקס מקצועיים ובד"כ לא רואים אותן בחברות הישראליות.

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

מבחינת הבדלים בין הפצות – רד-האט ותואמיו, ו-SLED עובדים על עקרון פשוט: מה שיש בהפצה מבחינת אפליקציות, שרותים, ספריות וכו' – זה מה שיש, זה מה שמקבל באופן רשמי תמיכה. מחר תצא גירסת Ruby חדשה, PHP חדשה או ספריות חדשות? הן לא חלק מהחבילה והן לא נתמכות במסגרת חוזה התמיכה של החברה מול יצרן ההפצה. הדבר שבראש וראשונה מודגש בהפצות לינוקס האלו היא שמירת תאימות ויציבות, גם במחיר ויתור על פונקציונאליות חדשה. כשאתה משתמש בהפצה כזו, אתה יכול להיות שקט מבחינת תמיכה. ברד-האט לדוגמא, כל גירסת Major של הפצה נתמכת 10 שנים (וכך אגב, גם ההפצות התואמות לרד-האט). בתוך תקופה זו היצרן משחרר עדכונים תקופתיים, אך עדכונים אלו שומרים על 100% תאימות בינארית, כלומר אין בעיה לדוגמא לעבור מרד-האט 6.1 ל-6.8 במכה אחת, התאימות תישאר במלואה.

באובונטו הדברים מעט שונים – ישנה גירסת LTS לכל הפצת לינוקס, אבל התאימות נשמרת רק ל-5 שנים והחברה מוציאה כמעט כל שנה גירסה אחרת של הפצת לינוקס.

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

  • אם ההתקנה תבוצע עבור הרצה של אפליקציות מסחריות שמגיעות עם קבצים בינאריים בלבד כקוד סגור (SolidWorks, סימולציות רפואיות, סימולציות מדעיות, שימוש בכרטיסי Tesla או כרטיסי PCie קנייניים לשימושים ספצייפיים, לא כרטיסי GPU רגילים וכו') – מומלץ לבחור הפצה כמו Red Hat או SLED או אורקל לינוקס. אלו הפצות שנמכרות בתשלום. אם אין כסף לרכישת הפצה, אפשר להשתמש ב-CentOS, רק כדאי לקחת בחשבון שיצרני התוכנה הנ"ל לא ששים לתת תמיכה ל-CentOS (פוליטיקה). אובונטו במקרים רבים עם אפליקציות כאלו מקבל "כתף קרה" – תשאלו את IBM לדוגמא.
  • אם ההתקנה תבוצע עבור פיתוח אפליקציות בקוד פתוח תוך שימוש בקוד פתוח אחר כאשר אין הסתמכות על אפליקציות בינאריות סגורות – כאן אפשר לבחור את SLED, CentOS או אובונטו LTS. אלו הפצות שקל מאוד להרחיב אותן בעזרת מאגרים (Repositories) חיצוניים נוספים על מנת לקבל גרסאות חדשות של אפליקציות ודברים שלא מגיעים עם ה-ISO הרשמי.
  • אם ההתקנה מיועדת לאנשי לינוקס ותיקים שלא מצריכים תמיכה – אני ממליץ פשוט לתת להם לבחור ISO ושהם יתקינו בעצמם מה שהם רוצים. אנשי לינוקס מקצועיים מסתדרים בד"כ בעצמם עם הבעיות בתחנה שלהם 🙂

כשזה מגיע לשרתים – ההפצות המומלצות שונות במעט מת"ע:

  • Red Hat Server Edition
  • SuSe Linux Enterprise Server (בקצרה: SLES)
  • Ubuntu LTS
  • CentOS 7.2 Server Edition (גירסת DVD ISO)
  • Oracle Linux

מכיוון ששרתים נחשבים הרבה יותר "חשובים" מדסקטופ/ת"ע, חשוב לבחור בהפצה הנכונה וגם במי שנותן לחברה תמיכה. אפשר בארץ לדוגמא לרכוש רשיון ל-Red Hat ואת התמיכה המוצעת, אך גם חברת SuSE ישראל וגם אורקל ישראל מוכרים שרותי תמיכה לרד-האט (ל-SuSE יש גם כלי מסחרי לניהול עדכונים שנקרא SuSE Manager הן ל-SLES, SLED, CentOS, Red Hat שנמכר ונתמך פה בארץ). הפצות כמו Red Hat ו-SLES מגיעות עם תמיכה מסחרית כך שההנהלה יכולה להיות שקטה שאם תקרה תקלה, יהיה מי שיענה, גם באמצע הלילה (ובמקרה של SuSE – בעברית). אני מודע לכך שחברות מעדיפות לוותר על רכישת רשיון (במיוחד כשיש צוות IT עם ידע בלינוקס), אבל לפעמים יש צורך ברכישת רשיונות כשצריך להריץ אפליקציות בינאריות והיצרן מתנה תמיכה רק אם בשרת מותקנת הפצת לינוקס מסחרית עם רשיון תקף.

לכן, חשוב לבחור איזו הפצת לינוקס להתקין בשרתים וחשוב לבחור הפצה שיצרני חומרה תומכים בה באופן רשמי. הפצות אלו הן Red Hat (הגרסאות התואמות יכולות להריץ דרייברים שנכתבו עבור רד-האט במידת הצורך), SLES. אובונטו, שוב, מקבל הרבה פחות תמיכה ו-Certficiation מיצרנים, גם בגירסת LTS, במיוחד כשמדובר בציודים כמו NVMe שהפצת גירסת ה-Server של אובונטו לא תומכת בצורה טובה, לדוגמא.

כשמדובר במכונות וירטואליות, כל ההפצות נתמכות, אם כי, שוב, רד-האט ותואמיו לוקחים את זה צעד קדימה וכל הכלים כדי להתממשק עם ה-Host כבר נמצאים ב-ISO, בין אם מדובר ב-ESXi או Hyper-V ווירטואליזציות אחרות. הכל תלוי ב-Policy של החברה.

כשמגיעים לבחירת הפצת לינוקס, לא חשוב איזו הפצה החלטתם לרכוש, חשוב לדעת ממי לרכוש. בארץ יש לא מעט License Pushers שסגרו עסקאות עם הפצות לינוקס שונות והם מוכרים רשיונות. כשזה מגיע לתמיכה לעומת זאת .. או שתקבל תמיכה מהודים, או שתקבל איש לינוקס הכי זול שהם מצאו כדי שיגיע אליך ולא בטוח שהוא יוכל לתמוך בך. לכן חשוב לבחור חברה שנותנת לך תמיכה בעברית עם אנשים שיש להם ידע עשיר בלינוקס בהתאם ל-SLA שאתה בוחר ושיש לה נציגות רשמית, לא נציגות של מפיץ. ל- Red Hat, SuSE ואורקל יש כאלו בארץ. ראיתי לצערי מספיק מקרים שחברות התפתו להתקין שרתי לינוקס מחברה שמוכרת שרותי Windows ואז יום אחד אותו ספק הפסיק לתמוך בלינוקס שהם התקינו ללקוח כי .. איש הלינוקס של אותה חברה המשיך הלאה בחייו, לכן כשזה מגיע לרשיונות וחוזי תמיכה – קחו מחברות שלינוקס זו הפעילות העיקרית שלהן.

והערה לסיום: ראיתי לא מעט חברות שעוברות ללינוקס או עוברות לגירסת לינוקס אחרת והדבר נעשה ע"י חברה חיצונית. בלא מעט מקרים לא נלקח יעוץ עצמאי ובלתי תלותי לגבי המעבר והח"מ ראה מספיק מקרים של פרויקטים שנעשו עם המון דברים לא נכונים ו/או מיותרים ו/או חסרים, החל מדברים פשוטים כמו Volume Management ועד תצורת אשכולות שכלל אינה לוקחת בחשבון את מה שרץ מתחתיה כדי לקבל יתרונות נוספים. המלצתי האישית – קחו יעוץ עצמאי ובלתי תלותי (לא מישהו מטעם מי שיבנה את הפרויקט) שיתן "מבט שני" בפרויקט ומה הולכים לעשות. זה יעלה כמה מאות דולרים/שקלים (תלוי ביועץ) – וזה שווה את זה. היעוץ הזה יכול במקרים רבים לחסוך הרבה יותר מהעלות של היעוץ. מבלי לאמר שמות, אני יכול לציין לדוגמא חברה ממשלתית שהשקיעו מאות אלפי דולרים במערכת שרתים ואפליקציות והם צריכים בקרוב לשלם יותר מ-$50,000 תחזוקה שנתית – ולפי בדיקה שערכתי, כל המערכת הזו לא עברה בחיים ניצול של יותר מ-2.5 אחוזים, שרתים שלא היה להם יותר מ-1% שימוש ומערכי דיסקים שאינם מפורמטים אפילו ואיש אינו חושב להרחיב את המערכת. למה? כי מישהו שמע הצעה אחת של חברה והחליט לשפוך כסף.

"שרת" קטן ל-LAB ביתי

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

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

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

לכן אני ממליץ בד"כ להקים את הדברים החיוניים על "שרת" נפרד שאינו וירטואלי, ועד כה ההמלצה שלי היתה על Raspberry Pi (במיוחד על ה-3). הוא קטן ואפשר להחביא אותו, ואפשר לסדר לו פתרון "UPS" שמורכב מסוללה חיצונית וזה יחזיק יותר מ-10-15 שעות בלי יותר מדי מאמץ. צריך אמנם לכתוב סקריפטים שידעו לבדוק אם יש חיבור LAN (ואם לא, לבצע unmount או לבצע soft mount), ואולי גם לחבר לו מודם סלולרי כך שבמקרה ויש הפסקת חשמל הוא ימשיך לעבוד, לצלם ולשלוח את התוצאות לענן דרך מודם סלולרי.

אבל ל-Pi-3 יש כמה בעיות קטנות:

  • אין לו אמצעי אחסון אמין. כרטיס מיקרו SD הוא טוב אבל הם מתקלקלים הרבה יותר מהר מאשר אמצעי אחסון פנימי "אמיתי", במיוחד אם השרת הקטן כותב קבצי לוגים לוקאלית, קבצי תמונות (מהמצלמה) או קבצים אחרים – בעת ובעונה אחת. כרטיס מיקרו SD הוא מדיום מאוד איטי בכתיבה והוא לא יודע לעבוד במצב של גם קריאה וגם כתיבה במקביל, זה או זה או זה.
  • כמות RAM: רבים מספרים ש-1 ג'יגהבייט RAM ל-Pi-3 זה מספיק בהחלט, וזה נכון כשמריצים כמות דברים קטנה, אך מנסיון – כשדברים עובדים, רוצים להכניס עוד כמה שרותים "קטנים" – אולי איזה Torrrent Client קטן שיעשה את העבודה ב-NFS/CIFS, אולי תוכנת ניטור שאינה מינימלית, אולי תוכנת מעקב מצלמה – וכך ה-Pi-3 הנחמד יהיה עמוס וצוואר הבקבוק הראשי עדיין יהיה כרטיס המיקרו SD או הזכרון.

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

הבעיה של השוק הזה – שהוא לא מזהה הזדמנויות כמו מכירה של הציוד עם הפצת לינוקס. כיום לדוגמא, ישנם מכשירים בודדים שמציעים לינוקס. יש כמובן את כל אלו שמתחרים ב-Pi-3 אבל ברוב המקרים מדובר במעבדים חלשים ואלו שטובים – מגיעים (כולל קופסא, ספק וכו') בקלות למחיר ה-100$. לעניות דעתי, אם ציוד שנמכר עם אנדרואיד במחיר של 40-50$ היה נמכר עם אופציה חינמית להתקנת לינוקס – היצרנים היו יכולים לעשות כסף לא רע, אבל כיום – מספר האופציות מצומצם יחסית – (אם אתה מחפש קופסא אחת שכבר בנויה ומכילה הכל ולא בחלקים או ציוד די חלש)

בשבועות האחרונים ראיתי משהו מעניין – יש לא מעט חברות סיניות שמוכרות MINI-PC פשוטים וזולים במחירים של בערך 70-80$ (ומעלה) שכוללים:

  • מעבד ATOM Z8300 מרובע ליבות במהירות עד 1.8 ג'יגהרץ
  • 2 ג'יגהבייט RAM
  • 32 ג'יגהבייט אחסון פנימי
  • כניסת כרטיס מיקרו SD
  • 2-4 פורטים USB-2/USB-3
  • Windows 10 (חלקם ללא רשיון מאוקטב, חלקם מאוקטב, חלקם עם רשיון פרוץ)

הנה לדוגמא מכשיר NEXBOX T10 שעולה 77$ לערך. יש גם את Wintel Pro CX-W8 שעולה 72$ (אך יש לו 3 חיבורי USB, לא 4).

אם נשווה את המחירים האלו ל-Pi-3 (גירסת חבילה), ה-Pi-3 עולה כ-50$, כלומר ההבדל הוא בסביבות ה-20-30$.

מכשירי Mini PC כמו הדוגמאות לעיל יכולים להיות "שרתים" מצויינים בהשוואה ל-Pi-3. היתרונות:

  • כמות זכרון (RAM) כפולה
  • מעבד יותר מהיר (ב-10-60% תלוי במבחן)
  • אמצעי אחסון פנימי הרבה יותר אמין מכרטיס מיקרו SD (וב-32 ג'יגהבייט אפשר להתקין המון דברים כשזה מגיע ללינוקס)
  • מכיוון שמדובר במעבד אינטל, אפשר להתקין כמעט כל הפצת לינוקס עדכנית (פדורה, OpenSuSE או אובונטו 16) ואם צריכים להוסיף REPO/PPA חיצוני – אז לא צריך לחפש אם יש גירסאות ARM לאפליקציה, אפליקציות 32 ו-64 ביט ירוצו מעולה על מכשיר כזה (שימו לב איזו גירסת הפצה אתם מתקינים, גירסת 32 ביט לא יכולה להריץ אפליקציות 64 ביט אבל ההיפך אפשרי).
  • מבחינת UPS – לא צריך UPS גדול ויקר, אפשר לחפש Battery Pack שיכול לשמש כ-UPS (מומלץ לבדוק את הנושא לפני שרוכשים כל Battery Pack).
  • אם רשיון ה-Windows 10 Home חשוב לך, גבה את המכשיר לפני שתפרמט, אולי תשים את זה על VM כלשהו 🙂

עם פתרון כזה אנחנו מקבלים "כמו Pi-3" אבל עם זכרון כפול, אחסון קבוע, ותאימות אינטל.

אישית – אני מחכה ל-Wintel שיגיע לי כדי להשמיש אותו כ"שרת".

ומה דעתכם?

כשרוכשים 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/איש סיסטם ללא קשר למערכת ההפעלה.

[stextbox id="info" caption="הבהרה"]במאמר זה אני משתדל לתת כמה שיותר הסברים. יחד עם זאת, חלק מהשרותים שעבדכם הנאמן מוכר הוא יעוץ בחומרה ולכן בפוסט זה לא אפרט שמות, דגמים, מחירים, נציגים בארץ וכו'. מקווה שהדבר יתקבל בהבנה מצד הקוראים.[/stextbox]

תכנון ראשוני

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

[stextbox id="info" caption="הבהרה"]לי אין קשר ל-Viewsonic או ליבואן ופוסט זה נכתב מהאספקטים של לינוקס, אבטחה וניהול יותר קל של Citrix Clients.[/stextbox]

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

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

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