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

כשצריכים סטורג' סופר מהיר (חלק שני)

בפוסט הקודם הסברתי מעט מהו סטורג' סופר מהיר. למעוניינים בגירסה המקוצרת: סטורג' כזה עובד כ-NVMEoF (כלומר NVME over Fiber אם כי הוא כמובן יכול לעבוד גם על Ethernet בלי שום בעיה, אבל תצטרכו תקשורת במהירות של 40/50/100 ג'יגה – תלוי בכמויות שרתים, חיבוריות וכו') והוא בעצם נותן לנו ביצועים של דיסקים SSD NVME מקומיים עם Latency מאוד נמוך (בסביבות ה-20 מיקרו-שניות). מערכי AFA רגילים יכולים תיאורתית לתת NVMEoF אך ה-Latency יהיה בערך פי 10-20 יותר גבוה. בדרך כלל, רוב החברות שרוצות לרכוש AFA לא ממש יצטרכו NVMEoF למעט אותן חברות שמחפשות את ביצועי הדיסקים הכי גבוהים שניתן לקבל, חברות כמו High Frequency Trading, Fast Analysis, מערכי VDI ענקיים (מעל 5000 עם ביצועים מאוד גבוהים), AI/ML כשהביצועים המבוקשים חייבים לכלול Latency סופר נמוך כדי להתמודד עם כמות עצומה של DATA ל-Training, מערכות BIG DATA ענקיות, וכמובן – אלו שרוצים את ה-Top שב-Top (לא תמיד בגלל סיבות טכניות.. יש לא מעט חברות שרכשו פתרון שהוא פי 10 גדול מהצרכים שלהם מהסיבה הפשוטה … שיש תקציב).

על מנת לקבל את אותם ביצועים סופר מהירים, ברוב המקרים ישתמשו ב-XPoint של אינטל או Z-NAND של סמסונג. במקרים אחרים (כמו עם מערכות של E8) יהיה NAND אך ישולב בו Cache אימתני ועוד כמה דברים על מנת לתת את אותו Latency.

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

אני לא אציין כאן שמות חברות ודגמים מכיוון שכל דגם טוב לתחום מסוים ועל כך תיכף ארחיב, אבל יש 2 דברים שהייתי ממליץ לעשות:

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

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

לכן, כדי לקבל את המספרים הטובים, אנחנו צריכים גוף שהוא מוכר עולמית, יש לו גישה לכל הציודים והוא עורך בדיקות עם הציודים ומפרסם מספרים ללא כל מיני "טובות" והשפעות. יש גוף כזה שנקרא STAC Research שחברים בו יותר מ-300 חברות והוא מפרסם Benchmarks על ציודים שונים בכל התחומים ומי שאינו מכיר את הגוף, מוזמן לקרוא את המאמר הזה באתר The Register. כך לדוגמא נראה גרף טיפוסי בדו"ח:

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

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

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

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

כשצריכים סטורג' סופר-מהיר (חלק ראשון)

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

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

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

עכשיו אסביר.

רוב הסטורג'ים AFA הם פחות או יותר "גלגול" של הסטורג'ים מבוססי דיסקים מכניים. במקרים רבים עם כל היוקרה של AFA, אתם מקבלים SSD בחיבורי SAS/SAS2 או SATA Enterprise (שם נחמד ל-SATA רגיל רק עם "יוקרה"), לאו דווקא דיסקים SSD בחיבור NVME וגם אלו עם חיבור ה-NVME – יתנו בהחלט ביצועים יותר גבוהים מדיסקים מכניים, אבל ה-Latency יהיה עדיין גבוה בהשוואה לדיסקים NVME שיושבים בתוך השרת פיזית. זו לא דעה, זו עובדה – קחו 2 דיסקים NVME והגדירו אותם לדוגמא כ-RAID-0 בשרת, עשו את העבודות שאתם רוצים לבדוק ואחר כך קחו זוג דיסקים SSD NVME במכונה אחרת והגדירו שיתוף כמו iSCSI או CIFS או NFS. לא חשוב איזו רשת יש לכם (10/25/50/100 ג'יגה), Ethernet או Infiniband – הביצועים יהיו גבוהים אבל ה-Latency יהיה גבוה. פתרונות כאלו יכולים להיות מעולים לאלו שרוצים מהירות גבוהה יותר מדיסקים מכניים, אבל הם לא הביצועים הכי גבוהים שניתן להשיג, ומכיוון ש-AFA עולה מאוד יקר, ההמלצה שלי לחברים ולעסקים שמשוחחים איתי – היתה להמתין, לא לרכוש עדיין.

הביצועים הכי גבוהים שמאוד רצויים אצל חברות פיננסיות, AI/ML, HFT ולכל ארגון גודל שמוכן לשלם בתמורה לביצועים מקסימליים – הם ביצועים ששווים לדיסקים SSD NVME (כמו ה-XPoint של אינטל/מיקרון או Z-SSD של סמסונג) שיושבים מקומית בתוך השרתים. זיכרו: דיסק NVME (בקרוב יהיו גם דיסקים מכניים עם NVME, אגב) לא מצריך איזה בקר שיושב באמצע והוא מדבר ישירות ל-CPU ולזכרון המחשב ולכן דיסקים בטכנולוגיות כמו XPoint או Z-SSD מצטיינים ב-Latency נמוך וביצועים שנמוכים אך במעט מזכרון RAM שיושב במחשב. ב-AFA שנמכרים כיום, יש לנו כל מיני פרוטוקולים שמגדילים את ה-Latency, החל מ-iSCSI, המשך ב-NFS וכלה ב-CIFS, כך שהדיסקים יושבים בסטורג' היוקרתי, יש צורך באחד מהפרוטוקולים הנ"ל כדי להעביר DATA דו צדדית בין השרתים לסטורג'.

כאן נכנס לתמונה ה-NVMEoF שכתבתי עליו לפני 3 חודשים, ועם NVMEoF ה-Latency יורד לרמה של דיסקים SSD NVME מקומיים, כך שפעולות התחלת קריאה/כתיבה או כל פעילות אחרת נעשית ב-Latency מאוד נמוך.

איך זה מבוצע? כפי שציינתי באותו פוסט – עם RDMA, כלומר עם אותו פרוטוקול ותיק, ידוע ומאוד אמין ובמקרים רבים זה נעשה על מעבד יעודי שנמצא בכרטיסי הרשת (בגלל זה כרטיסי Mellanox מעולים לארכיטקטורה כזו הן בשרתים והן בסטורג') ואת עניין ה-NVMEoF לא תמצאו ברוב הסטורג'ים AFA. רק בשנה האחרונה חברות ישראליות כמו E8 וכמובן Kaminario (כן, אנחנו "מעצמה" בתחום הסטורג'… טוב, לפחות בפיתוח 🙂 ) וחברות כמו Toshiba, Pure Storage ו-Lenovo (וכמובן הגדולים) מתחילים להציע פתרונות כאלו. אלו שרכשו סטורג' AFA יוכלו (תלוי בחברה) אולי לשדרג ל-NVME-oF אבל גם אז – יהיה צורך להחליף כרטיסים בשרתים וציודים "באמצע" בחלק גדול מהמקרים.

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

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

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

כמה מילים על Microsoft SQL 2017 ללינוקס

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

אתחיל במידע כללי: מדוע מיקרוסופט בעצם שחררה את שרת ה-SQL שלה ללינוקס? התשובה די פשוטה: להתחרות מול אורקל ולהציע לחברות שמריצות לינוקס בפרודקשן בגלל היציבות – את שרת ה-SQL שלהם. בדרך להציע זאת ללקוחות, מיקרוסופט פתחה לעצמה פתח להציע דברים אחרים ללקוחות עם Linux עם פרויקט Draw bridge וזאת מבלי לשנות שום קבצים באפליקציה שלהם ומבלי לשבור תאימות, כך שהכלים של SQL ב-Windows יוכלו להתחבר לשרת לינוקס ולעשות את אותה עבודה. כלל, מבחינה טכנית, כשאתם מורידים SQL Server של מיקרוסופט ללינוקס, אתם מקבלים את האפליקציה + ספריות וגם קבצים בינאריים של .. Windows 8 (אפשר לקרוא על כך ולשחק עם זה, למעוניינים. פרטים כאן).

נעבור לאספקט הטכני: שרת SQL של מיקרוסופט ללינוקס נראה בדיוק כמו כל אפליקציה אחרת ללינוקס. כשרוצים להתקין לדוגמא על שרת CentOS או RHEL או SLE של SuSE – מורידים קובץ אחד של REPO ומשתמשים ב-YUM להתקין (או zypper במקרה של SuSE) (לצערי מיקרוסופט לא כל כך עקבו אחרי תקן ה-LSB ללינוקס והקבצים ימצאו ב-var/opt/mssql/ בשעה שהסטנדרט מדבר על opt/). הנה וידאו על התקנה של SQL על CentOS 7 כולל שימוש בכלי חדש של מיקרוסופט לעבוד עם ה-SQL (אפשר לעבוד כמובן גם עם הכלים הרגילים):

וכאן יש וידאו כיצד לבצע Auto Tune עם SQL על לינוקס:

כלומר מבחינת עבודה עם SQL Server של מיקרוסופט, אתם יכולים לעבוד עליו בדיוק כאילו התקנתם אותו על שרת Windows. הרשיון הוא אותו רשיון ואין צורך בתשלום נוסף ולאנשי ה-DBA אין שינוי כלשהו שצריך לבצע. לעומת זאת, לאנשים שאוהבים לעבוד ב-CLI, מיקרוסופט מספקת את mssql-cli שמאפשר עבודה ב-cli (כפי שמודגם בוידאו הראשון) ויש גם את פקודת sqlcli שמאפשרת לגבות DB, לשחזר וכו' וכו'. מנסיוני, ה-sqlcli עובד יפה (רק חבל שמיקרוסופט לא הטמיעו שיטה להכנסת סיסמאות מוצפנות דרך ה-cli).

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

אבל אחד היתרונות הגדולים של SQL Server של מיקרוסופט בלינוקס – זה שאפשר להריץ אותו כקונטיינר, ואז כל עניין ה-Cluster מתייתר. כל מה שצריך לעשות זה להריץ את גירסת הקונטיינר של SQL Server של מיקרוסופט תחת Kubernetes או OpenShift ואז תקבלו לא רק ביצועים גבוהים, אלא שרידות הרבה יותר גבוהה ממה שהייתם משיגים מכל פתרון Cluster קלאסי (לינוקס או Windows), החל מרמה פשוטה של הרצת SQL ב-Pod שכשהוא נופל אוטומטית Pod אחר קם ואז ניתן לעבוד שוב, וכלה בפתרון של הרצת 3 PODs כשבכל אחד מהם רץ SQL Server וכאשר אחד מהם נופל, מתקיים תהליך "בחירות" אוטומטי והזוכה נהיה ה-Primary. אפשר לראות הדגמה של כך בלינק הזה.

לסיכום: SQL Server של מיקרוסופט מאפשר לכם לעבור מ-Windows ללינוקס מבלי להיתקל ביותר מדי בעיות ומבלי לשלם על רשיון SQL נוסף. תגבו את כל ה-DB בגירסת SQL ל-Windows, תקימו SQL Server ללינוקס, תשחזרו נתונים על הלינוקס ותתחילו לעבוד (וכן, אפשר לחבר את המכונה ל-AD). אתם יכולים גם להשתמש בכלי אוטומציה שקיימים ללינוקס ולבצע פעולות רבות על ה-SQL ללינוקס בדיוק כמו לכל שרת לינוקס אחר. אין Kernel Modules (מיקרוסופט העיפה את כל ה-syscalls של Windows) כך ששום דבר לא אמור להפריע למערכת לעבוד בצורה נורמלית, יש את כל התמיכה ב-SystemD וכן .. זה רץ גם על אובונטו 🙂

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

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

הקשחת שרתים במבט יותר עמוק

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

הדבר הראשון שצריך להבין לגבי ההקשחות זה שתלויות חיצוניות לא תמיד עוזרות או לא עוזרות הרבה. ה-Firewall שיש בחברה לדוגמא כמעט ולא רלוונטי לנושא. כן, הוא יכול לזהות שכתובת IP מסויימת מנסה להיכנס, דרך פורט מסוים, אבל ה-Firewall לא יודע ולא יכול לדעת אם הפורץ הצליח להיכנס, ואם הצליח, באיזה קבצים הוא נגע. בלינוקס יש דבר שנקרא access time לדוגמא שיכול לאמר איזה משתמש נגע באיזה קובץ ומתי, אבל אם הפורץ כבר יצא והמשתמש הלגטימי (עם אותו username) נכנס ועבר על הקבצים, אז הרבה פעולות פורנזיות לא יעזרו הרבה לדעת מי נכנס ובמה הוא נגע (מה עוד שבימינו פורצים רציניים משתמשים ב-VPN ושלל טריקים נוספים להחביא את זהותם כך שמאוד קשה לדעת מי בדיוק נכנס). ישנם כלים אחרים שעובדים עם חתימות שונות כדי לזהות כניסות דרך שיטות ידועות וזה עוזר, אבל שוב – לא תמיד זה יעזור ותיכף ארחיב על כך.

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

אחת העבודות היותר מורכבות לפני שמגיעים למימוש CIS Benchmark היא עניין החבילות תוכנה שמותקנות על השרת. התקנת גירסת CentOS 7 לדוגמא בתצורה מינימלית מתקינה בסביבות 300+ חבילות. זה שאני יכול לבטל שרותים זה נחמד, אבל פורץ רציני יכול להפעיל את השרותים מחדש ברגע שהוא נכנס, ולכן העבודה הראשונית היא "כיסוח" של החבילות המותקנות שאין צורך בהן ובמקרים מסויימים קימפול מחדש של חבילות מסויימות ויצירת חבילות חדשות יותר מצומצמות על מנת להקטין כמה שיותר את וקטור התקיפה, ביטול גישת אינטרנט להתקנת חבילות ועוד ועוד. רק לאחר מכן אפשר לעבור לשלב מימוש ה-CIS Benchmark.

עוד נקודה שרבים שוכחים היא פורטים 80 ו/או 443. בד"כ הם פתוחים לעולם, וכאן גם מתרכזת בעיה רצינית: קיימים לא מעט סקריפטים שיתנו מעין shell גם אם ל-user שמריץ את שרת ה-web אין בכלל גישת shell מכיוון שלמודולים שרצים תחת אותו שרת web יש אפשרות לבצע דברים שונים הקשורים ל-shell. דוגמא נפוצה עם PHP היא [email protected] ומשם אפשר לבצע נזקים רבים, ולכן צריך לקחת בחשבון מה רץ בשרת ה-web ומה רץ "מאחורה", והכי חשוב – בדיקת ההזנה של המידע המגיע מהאינטרנט אל שרת האפליקציות לדוגמא (זהו החלק שקשור לצוות הפיתוח או מי שמריץ pen-testing).

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

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

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

כמה מילים על ZFS (לשנת 2018)

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

כיום, אם חברה מסויימת רוצה לרכוש לעצמה סטורג' כפתרון קצה – היא בהחלט יכולה וישנם פתרונות טובים בשוק שיתנו לכם קופסא עם דיסקים, חיבורי רשת מאחורה, מערכת Appliance שרצה בתוך הקופסא עם ממשק WEB ו-CLI ועם פונקציונאליות בהתאם למחיר ולרשיון שרכשתם. פעם היו EMC, NetApp הכי פופולריים, היום יש מגוון שלם של מוצרים מוכנים – רק להרכיב, להגדיר מספר דברים מצומצם וקדימה – אפשר לעבוד עם הפתרון, ואלו פתרונות שיכולים להתאים לרוב החברות והעסקים.

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

להלן צילום מסך מ-vSphere client בגירסה 5.5, כאשר מגדירים LUN חדש ובוחרים את ה-Block Size (לחצו להגדלה):

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

במקרה לעיל, לא חשוב איזה Storage יש לך, מהרגע שהגדרת iSCSI LUN בסטורג', לסטורג' אין מושג ירוק מה אתה הולך לעשות איתו. מבחינתו זה Block ולך תשבור את הראש מה לעשות ואיך להגדיר ואיך לעשות אופטימיזציה לו ב-Initiator שלך.

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

אבל מה קורה אם אנחנו רוצים לבנות פתרון סטורג' משלנו ואנחנו מעוניינים לעשות לו אופטימיזציה ולא להיות "שבויים" באיזה פתרון שלא מאפשר לנו להגדיר דברים לעומק? אם אנחנו בונים עם לינוקס מערכת כזו עם File System כמו XFS או EXT4, מאותו הרגע שחילקנו את הדיסק עם או בלי LVM, ואנחנו מפרמטים את כל מערך ה-RAID בזמן ההתקנה, אז כבר אי אפשר לשנות את גודל הבלוקים. ב-XFS לדוגמא, ברירת המחדל היא להגדיר בלוקים בגודל 4K כל בלוק, אבל אם אנחנו הולכים לאחסן רק קבצים שרובם בגודל מס' ג'יגהבייטים, אנחנו נפסיד מהירות.

לעומת זאת ב-ZFS, גם אחרי ששייכנו את כל הדיסקים ל-Pool מסויים, אנחנו תמיד יכולים להגדיר את גודל הבלוקים (ב-ZFS זה נקרא record size) גם אחרי יצירת ה-Pool ויצירת Dataset (חשוב כמובן לשים לב שאם יצרנו Dataset ואנחנו מגדירים לו record size חדש, רק הקבצים החדשים יקבלו את גודל ה-record size החדש, לא הקבצים הישנים) כפי שניתן לראות לדוגמא כאן. (אגב, זה דבר שמאוד עוזר עם MySQL לדוגמא, אתם מוזמנים להציץ כאן)

נקודה נוספת וחשובה היא כמובן הדיסקים. ישנם עדיין מקרים רבים שיש שרתים פיזיים שמריצים אפליקציות מסויימות על דיסקים מקומיים עם כרטיס RAID הכולל זכרון Cache וסוללה, אך עם הדיסקים החדשים שיש כיום שמחירם יורד כל הזמן, יהיו לא מעט חברות שישמחו לקנות דיסקים בגודל 6,8,10,12 או אפילו 14 טרה בייט ויחברו אותם לבקר ה-RAID וכך הם יקבלו כמות אחסון מכובדת, אך יש בעיה מרכזית אחת: כל דיסק מעל גודל 4 או 6 טרהבייט שנדפק ומוחלף, יאיט אוטומטית את הביצועים של כל מערך הדיסקים לזמן רב (זה יכול לקחת ימים או במקרים של דיסקים גדולים כמו 10,12,14 טרהבייט – אפילו שבועות!) מהסיבה הפשוטה שבקר דיסקים הוא דבר די טיפש, הוא יודע לקרוא בלוקים, אבל הוא לא יודע מה יש בבלוקים, כך שבקר ה-RAID מבצע rebuild, הוא יעתיק את כל הבלוקים, גם אם 60% מהדיסק הוא בכלל ריק! לעומת זאת ב-ZFS אם נדפק דיסק והחלפנו אותו, מערכת ה-ZFS תשחזר (מה שנקרא: resilver) רק את הקטעים שלא קיימים בדיסק החדש, כך שה-rebuild יהיה הרבה יותר קצר והמערכת תשוב לאיתנה במהירות הרבה יותר גבוהה מאשר בתהליך rebuild של כרטיס RAID.

חסרונות נוסף שקיימים ל-XFS ול-EXT4 הם לדוגמא:

  • אין בדיקת קבצים מתמשכת. ב-ZFS לכל קובץ יש checksum כך ש-ZFS יודע בדיוק אם מה שהוא קרא תקין או לא ואם לא הוא יטפל בבעיה אוטומטית בכך שהוא יעביר את הנתונים למקום אחר (בערך כמו שבקר SSD טוב עושה) ול-ZFS ישנו גם תהליך scrubbing שעובר אחת לכמה ימים על כל הקבצים בדיסקים לבדוק זאת ולטפל בתקלות באופן אוטומטי. ב-XFS וב-EXT4 יש לך Journal שיכול לעזור בקריסת המכונה, אך זהו פתרון שאינו מספק על מנת לשמור על הנתונים.
  • ב-EXT4 וב-XFS אין מנגנונים לניצול משאבי המכונה מבחינת זכרון. כן, ללינוקס יש שימוש מתוחכם בזכרון החופשי לשם Cache מסוגים שונים, אבל ב-ZFS יש את ARC שלוקח כברירת מחדל מחצית מהזכרון של המערכת להאצת ביצועי דיסק בכך שהוא משתמש באותו זכרון שהוא "גזר" בהתחלה, וכידוע – זכרון RAM הוא הדבר הכי מהיר שיש, יותר מכל SSD שקיים בשוק.
  • שימוש מושכל ב-SSD וב-NVME: עם מערכת כמו bcache או fastcache (לאלו שאוהבים לחיות על הקצה) יכול להיות פתרון די טוב על מנת להאיץ ביצועים של דיסקים מכניים, אך ב-ZFS יש לך 3 מנגנונים שמטפלים בכך:
    • מנגנון ה-ARC (שמשתמש כברירת במחצית הזכרון של המכונה לשם CACHE מהיר)
    • מנגנון ה-ZIL (להאצת ביצועים וטרנזאקציות של קבצים קטנים ורישומי הפניות להיכן קבצים נכתבים, אפשר לקרוא על כך כאן)
    • מנגנון ה-L2ARC – כאן בד"כ יהיה SSD מהיר ששומר עותקים של קבצים שניגשים אליהם בתכיפות גבוהה.
  • מערכת ZDB – לכל File system יש כלים משלו (tune2fs ל-EXT3/EXT4 לדוגמא או ערימת הכלים הזו ל-XFS), אבל ZDB לוקח את זה כמה צעדים קדימה – לבדיקה האם יש Cache אופטימלי, לבדיקה של ביצועים פר דיסק, בדיקות והגדרות ל-B-TREE (כן, ZFS שומר את הקבצים ב-B-Tree) ועוד המון דברים. ZDB הוא ה"אולר השוויצרי" ל-ZFS ועבודה איתו יכולה לתת ביצועים שעוקפים מרחוק כל File System לינוקסי.

יחד עם זאת ל-ZFS יש עדיין חסרונות (שיטופלו בשנה הקרובה):

  • הוספת דיסקים: לא, אתה לא יכול להוסיף עוד דיסק אחד אלא 2 ומעלה. גם החלפת דיסקים קיימים בדיסקים יותר גדולים היא לא בדיוק פיקניק כרגע (אבל זה אפשרי). במהלך 2019 יתווסף קוד להוספה דיסקים – אפילו דיסק בודד כמעט מבלי שנצטרך להתמודד עם איטיות של פריסת DATA מחדש (יועתקו מספר בלוקים בודדים וזהו).
  • עבודה עם SSD – אחד החלקים היותר נחמדים ב-SSD זו פקודת trimfs שאומרת ל-SSD לבצע פקודת TRIM ב-SSD. ב-ZFS יש תמיכה ל-Trim אך היא אינה אוטומטית בגירסת ZFS ללינוקס. יש Pull request שיכול לעבוד ברוב המקרים בגירסה הנוכחית היציבה של ZFS ללינוקס, ובגירסת ה-Master זה עובד בצורה טובה. אני מאמין שבחודשים הקרובים זה יוכנס פנימה.

לסיכום: אפשר להקים שרת ZFS תוך דקות ספורות על מכונה חדשה. יוצרים pool עם תצורת RAIDZ רצויה, מחלקים דיסק SSD ל-2 פרטישנים (אחד log ואחד cache, ככלל עדיף 2 SSD שיעבדו כ-Mirror), מצמידים אותם ל-pool ויאללה – יש מערכת ZFS עובדת. העניין הוא שאם אתה רוצה ביצועים מעולים, תצטרך להשקיע זמן בהגדרות דברים לפי מה שרוצים להריץ ומה ה-ZFS צריך לשרת (ואני ממליץ את הספר הזה ל-ZFS על לינוקס, או את הספרון הזה). האם ZFS הוא פתרון חלופי לסטורג' סגור – במקרים מסויימים כן ובמקרים מסויימים לא (תלוי בדרישות ובצרכים), אבל הוא מאוד מתאים אם חברה מחליטה להקים סטורג' קטן והיא מוכנה להשקיע את שעות העבודה כדי לבצע אופטימיזציה וזה לוקח זמן (לפי הידע של מי שמבצע זאת), זה לא משהו שנעשה בחצי יום, וצריך לעיתים להקים מערכת שלמה כדי להגדיר לבדוק את הביצועים.

סטארטאפים ואבטחת מידע בענן

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

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

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

וכאן בדרך כלל מתחילות הבעיות הקשורות לאבטחת מידע.

לא מעט אנשים שמתחילים סטארטאפים חושבים להם שאם יקימו את התשתית שלהם בענן, ספק הענן יגן עליהם בצורות כלשהן וזו כמובן טעות ענקית. לא חשוב מי ספק הענן, כמות ההגנה המסופקת ללקוח היא ברמה אפסית (אינני מדבר על הגנות בתוספת תשלום כמו נגד DDoS). אתה יכול להפעיל Multi Factor Authentication כדי למנוע כניסת אנשים לא מורשים לחשבון בענן, אבל זה לא אומר כלום לגבי ה-Instances שאתה משתמש. מהרגע שיש לך Instance חי ויש לו כתובת IP ציבורית, עשרות אלפי סקריפטים ינסו לחדור לשרת שלך בכל דרך. כל שרות שתפעיל באותו Instance ושאינו סגור לכתובת הציבורית (כמו שרבים נוטים להשאיר פורטים פתוחים לשרותי SQL/NOSQL, GUI, או SSH עם סיסמא (ללא מפתחות) – הסקריפטים ינסו להיכנס, ואם הם יצליחו, חלקם יעבירו את המידע חזרה מבלי לנגוע במידע בשרת וחלק אחר של סקריפטים פשוט "יגייסו" את המכונה להריץ BOT או תולעים או 1001 דברים מזיקים אחרים ויש כמובן גם סקריפטים שישמחו פשוט למחוק את המכונה.

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

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

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

  • אם מדובר במספר עובדים בסטארטאפ אחד שיושבים במשרד כלשהו, דאגו ל-VPN וחברו את ה-VPN כ-Site To Site לחשבון הענן שלכם. מי שרוצה להתחבר מהבית, יתכבד הבחור ויתחבר ל-VPN שלכם ומשם לתשתית.
  • עבודה עם סיסמאות לכניסה לשרתי לינוקס היא no no. השתמשו במפתחות בלבד והחליפו את קבצי ה-PEM שניתנו לכם ע"י שרות הענן שלכם במפתחות שלכם בחלוקה של פרטי/ציבורי (עדיף ליצור עבור כל מפתח מפתח, להכניס את החלק הציבורי לשרת ואת החלק הפרטי למכונה של המפתח כך שאפשר לדעת מי נכנס עם איזה מפתח), כך שמי שצריך להיכנס למכונה יהיה לו את החלק הפרטי של המפתח (החלק הציבורי נמצא בשרת). קבצי ה-PEM למיניהם קל "לדוג" אותם מכל מיני פורומים, אימיילים ושאר מקומות.
  • מקימים DB? ראשית יש להקשיח את ה-DB לפני שמכניסים אליו נתונים. אם זה mysql לדוגמא, יש להריץ קודם כל mysql_secure_install, ואם זה mongoDB יש למחוק משתמש דוגמא,  ובכל המקרים יש לוודא כניסה רק דרך IP מסוים פנימי.
  • משתמשים בשרותים שונים של ספק הענן? ודאו שאתם משתמשים בכתובות IP פנימיות בלבד. זה לא מצליח? יש לכם בעיה עם ה-VPC (במקרה של אמזון), כדאי לבדוק הגדרות.
  • שימוש ב-DB – לפני שכותבים נתונים ל-DB, כדאי "להמליח" דברים כמו סיסמאות ומידע חשוב (להלן לינק לוידאו המסביר איך לעשות זאת ב-MySQL לדוגמא), כך שמי שיצליח לגנוב את ה-DB, לא יוכל לעשות הרבה עם זה. אפשר כמובן לשפר את זה ולהשתמש בכל מיני שרותי Vault לשמור את המפתח להמלחה אך זה כבר עניין אחר.
  • גיבויים ל-S3 או כל מקום ששומר Object Storage – לאחר יצירת הגיבוי, יש להצפין אותו ורק אז להעלות אותו (כמובן שכדאי לוודא שהרשאות ה-S3 שלכם מוגדרות בצמצום).
  • לא לקחת כתובות IP ציבוריות עבור כל Instance (טריק שלצערי ראיתי פעמים רבות שנעשה בחברות שונות). אם אין אפשרות להקים ולהשתמש ב-VPN ויש צורך להתחבר ממקומות שונים עם IP שונה, מומלץ להשתמש בטריק שנקרא Linux Bastion, זו מכונת לינוקס קטנה שבה נשתמש כ"מקפצה" (להלן לינק למאמר שמסביר זאת) ולמכונה זו יש להגדיר Security Groups עם הכתובות שיכנסו אליה (חשוב: לא להוסיף כל פעם כתובות אלא לעדכן ב-SG).
  • תעודות SSL – אם המכונה פונה החוצה ואין לכם עדיין תעודות SSL מסודרות, אפשר להשתמש ב-Let's Encrypt כדי ליצור תעודות SSL תקינות זמניות (שניתנות להארכה בפקודה פשוטה) במקום להשתמש ב-Self Signed Certificates. באותה הזדמנות כדאי לבטל Ciphers ישנים ולאפשר אך ורק ל-TLS מהגירסא האחרונה להיכנס.

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