קצת על Windows ואוטומציה

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

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

  • Chef
  • Puppet
  • Ansible
  • SALT

לכל אחד יתרונות וחסרונות, אך מבחינת פלח שוק, Ansible מוביל בפער ענק על פני האחרים כולל פתרונות מסחריים סגורים, הנה גרף שיציג זאת (מקור: Datanyze) (לחצו להגדלה):

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

אחד היתרונות הגדולים בגירסה האחרונה (2.5) של Ansible היא פתרון מלא ל-Windows. צריכים לעדכן שרתים? צריכים להוסיף אתר ל-IIS? צריכים להעביר קבצים? מעתה כל מה שצריך זה ליצור קבצי Playbooks פשוטים (לא, לא צריך לדעת לתכנת בשביל לכתוב Playbooks) ופשוט להריץ אותם. Ansible ירוץ במקביל לכל המכונות שהגדרתם ויבצע את העבודה. בתוך Ansible יש חלקים שנקראים מודולים שהם בעצם הקוד שירוץ על השרתים (דרך WinRM) והם כתובים ב-Python ולכן חלוקת העבודה יכולה להיות שמי שמבין בפייתון יכתוב מודולים והשאר יכתבו Playbooks בהתאם לצורך. אגב, יש תמיכה במערכות הפעלה אחרות, וירטואליזציה וגם חומרה.

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

תכירו את Redfish

אני רוצה להכיר לכם את Redfish. בעקרון, Redfish זה API סטנדרטי לנהל כמעט כל דבר בתחום ה-IT, החל מ-SDDC (כלומר Software Defined Data Center) וכלה בשרתים, שרותים, מתגים ובקיצור כמעט כל דבר שניתן להתחבר אליו. Redfish משתמש בסטנדרטים קיימים (REST API, web services ופלט כ-JSON) על מנת לעשות את החיים הרבה יותר קלים למחלקת ה-IT בחברה.

אחד הדברים שצריך לדעת על Redfish שזה משהו ענק שמשתתפים בו כל המי ומי בתחומי הברזלים לדוגמא. לפוסט הזה, אני מעוניין להתרכז בתחום ה-OOB (שזה אומר כל ה-iDRAC/IMM/ILO/IMC למיניהם).

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

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

כשמדובר על כמות של 1-3 שרתים, זה לא כזה ביג דיל, אבל אם מדובר על פרויקט חדש והגיעו 20 שרתים.. אתם יכולים לדמיין את הכאב ראש.

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

איך? עם ה-API של Redfish. כאן לדוגמא תוכלו למצוא עבור שרתי Dell סקריפטים הן ב-Python או ב-PowerShell על מנת להשתמש עם ה-Redfish בחיבור ל-iDRAC לעשות כמעט הכל, החל מהגדרת UEFI/BIOS, שדרוגי קושחה, הגדרות iDRAC, הגדרות RAID ושלל ירקות נוספים.

הכל טוב, רק שיש בעיה אחת קטנה: יש לי 20 שרתים להקים, להתחיל לשנות כל פעם סקריפטים? לכתוב סקריפט wrapper שמריץ את הסקריפטים שניתנים באותו אתר? זה חתיכת כאב ראש.

נכון. בשביל זה יש דרך אחרת, אוטומציה מקבילית, ואני מדבר כמובן על Ansible.

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

לסיכום: Redfish נותן סוף סוף דרך "לדבר" בצורה מאובטחת עם הציודים שלכם דרך סקריפטים שונים שניתנים לשימוש באוטומציה. אפשר גם להגדיר כך הגדרות שונות וגם לקרוא לדוגמא מה-OOB את התקלות האחרונות מה-Log. אם נחכים להשתמש גם ב-PXE (אני דווקא ממליץ על IPXE במקום PXE, הוא הרבה יותר מהיר כי הוא עובד ב-HTTP ולא TFTP כך שניתן לעבוד מהר ובמקביל) נוכל גם להתקין בצורה אוטומטית תוך שימוש בכלים כמו kickstart או preseed להתקין מערכות הפעלה שונות בתצורה מינימלית ואת השאר לעשות עם Ansible (כן, כולל Windows, אסביר בפוסט הבא) ובכך לחתוך את הזמן להקמת השרתים בעשרות אחוזים וגם התחזוקה תהיה הרבה יותר מהירה ואוטומטית.

להלן וידאו הדגמה של Dell מכנס Red Hat Summit האחרון שנערך לפני ימים ספורים:

על Ceph ועל HCI – סיבוב בדיקה נוסף

כתבתי כאן בעבר על סוגי סטורג' מבוסס קוד פתוח וניסיתי לענות על השאלה האם הם מתאימים לפתרונות HCI (כלומר Hyper Converege Infrastructure). התשובה שלי לגבי Ceph היתה בפשטות: לא.

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

אינטל לאחרונה החליטה להוכיח לעולם שדווקא Ceph יכול בהחלט להיות פתרון סטורג' טוב ל-HCI, ובכנס Red Hat Summit האחרון נציגי אינטל הדגימו זאת. להלן הוידאו עם המספרים:

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

והדברים שתצטרכו:

  • כוננים קשיחים מכניים? החוצה.
  • מעבדים – כרטיסי ה-XPoint של אינטל לא יעבדו (לא Boot ולא נעליים, הכרטיסים מצריכים UEFI 2.3.1 מהשנה וחצי האחרונות) על מעבדי E5 מדור 4 ומטה, תצטרכו שרתים חדשים מבוססי Xeon SP כך שגם את השרתים תצטרכו להחליף.
  • כונני SSD 3D של אינטל – זולים, הם לא. המחיר בשוק הוא בערך 3,500$ פר דיסק (וכן, הם צריכים PCIe 3.1, כך שגם שם אתם צריכים להתקין אותם בשרת חדש), כלומר ההדגמה של אינטל עולה רק מבחינת דיסקים 14,000$. (הדגם שהוצג בתצוגה הוא דגם ישן, כיום מוכרים את ה-P4600).
  • ליבות והרבה – המעבד שאינטל הדגימו (ושייכו אליו הרבה ליבות עם CPU Affinity) הוא Xeon SP Platifum 8176 עם 28 ליבות. מחירו בשוק (מעבד בלבד): 8500$.
  • זכרון – כן, ה-384 ג'יגה אמנם אינו מינימלי אבל הוא די באמצע, כך שלרדת מהכמות הזו תפגע בביצועים.
  • כרטיסי רשת במהירות 25 ג'יגה – כמובן שתצטרכו סוויצ' תואם, אתם יכולים לנחש את המחיר.

בקיצור – על כל שרת חדש כזה תצטרכו לשלם לא מעט.

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

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

על בעיה X ופתרון Y

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

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

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

  • מה הפונקציונאליות שהוא מחפש
  • מה הפונקציונאליות שמאוד חשובה לו, ומה הפונקציונאליות שבשבילו זה יהיה "נחמד" אם קיים אך אותה פונקציונאליות אינה קריטית.
  • האם הוא מחפש פתרון Scale Up או Scale Out
  • האם הוא מחפש פתרון שישולב כ-Hyper Converge או שהוא מחפש פתרון של ברזלים נפרדים
  • ויש עוד לא מעט שאלות…

ההבדלים ביני (וכמובן אחרים), כיועץ ואינטגרטור בלתי תלוי (כלומר אחד שהוא אינו בעצם Reseller של ברזלים ממותגים) הם דברים חשובים כגון:

  • אינטגריטי – אם מישהו יבוא אליי ויבקש לדוגמא פתרון סטורג' Scale Out והדבר הכי חשוב לו זה iSCSI לדוגמא, אז אני אומר לו בפשטות שכרגע אין פתרון Scale Out בקוד פתוח (גם כמוצר מסחרי) שיש לו פתרון iSCSI ל-Scale Out בצורה טובה והוא יצטרך פתרון קנייני.
  • על מה הפתרון אמור לענות? לקוח רוצה X על מנת לפתור את בעיית Y. נעזוב לרגע את X, ונשמע מהלקוח מהו אותו Y. אין ספק, דרישותיו של הלקוח הן חשובות, אולם ברגע שמספרים לי מהו אותו Y, אז ניתן להעלות מספר פתרונות שיכולים לענות על Y וגם להתחשב בצרכי הלקוח.
    לדוגמא: ללקוח יש 20 מכונות VM שמשמשות לפיתוח והלקוח רוצה פתרון סטורג' עבורם Scale Up. במקרה כזה אני יכול להציע לדוגמא פתרונות מבוססים ZFS, בין אם כקוד פתוח נטו או מוצרים מסחריים ובהצעה שאגיש לו יוסבר מדוע הפתרון הזה טוב ויוצעו ללקוח מספר פתרונות מבוססים ZFS, כך שבסופו של דבר ה-Y הם אותם 20 מכונות VM וה-X יהיה פתרון מבוסס ZFS.

וכאן בעצם מגיעה השאלה המרכזית שלי…

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

שלח לחמך על פני המים

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

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

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

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

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

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

תודה,
חץ בן חמו
[email protected]

מה ההבדל האמיתי בין SSD רגיל ל-SSD ל-Enterprise?

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

הרשו לי להציג לכם את ה"יורש" של הסמסונג 850 PRO  שיצא שלשום – אחד מכונני ה-SSD שהצליח במשך 3 שנים להתעלות מעל רוב כונני ה-SSD הביתיים מבחינת ביצועים. זהו הסמסונג 860 PRO. מבחינת ביצועים הן מבדיקות והן "על הנייר" – זו חיה: 560 מגהבייט לשניה בקריאה ו-530 מגהבייט לשניה בכתיבה (זהו כונן בחיבור SATA). מבחינת IOPS יש לו בהחלט מה להתגאות: 100000 בקריאה, 90000 בכתיבה, ואורך החיים שלו – אתם יכולים לכתוב עליו ולמחוק – עד 4800 טרהבייט בכל משך ימי חייו. שום דיסק מכני לא נותן דבר כזה כמובן. מחיר: $238 לחצי טרהבייט.

והנה ה"אח הבכור" – ה-960 PRO בגירסת M.2 NVME. הביצועים? 3.5 ג'יגהבייט קריאה, 1.9 ג'יגהבייט כתיבה. IOPS? טוב ששאלתם: 440000 בקריאה, 360,000 בכתיבה. המחיר: $300 לחצי טרהבייט. אפשר לכתוב עליו באורך חייו כ-400 טרהבייט. (כן, ה-860 מחזיק הרבה יותר).

תכירו את ה-SSD החדש ביותר של אינטל (כתבתי עליו בעבר) – ה-900P. הוא יקר יותר ($628 לגירסה של 480 ג'יגהבייט), הוא יותר איטי בגישה לנתונים (2.5 ג'יגה בקריאה, 2 ג'יגה בכתיבה) אבל כשזה מגיע ל-IOPS, הוא בועט בכולם: 550,000 בקריאה, 500,000 בכתיבה.

אז מי מהם מתאים לחברות ומי לא מתאים לבית? ומדוע ההבדלים?

נתחיל ב-900P (הוא "האח הקטן" של ה-DC P4800X). נניח שאתה רוצה SSD מהיר לבית, אתה עורך וידאו נניח או מוכן לשפוך סכומים רציניים על המחשב למשחקים שלך. הכסף לא ממש משנה לך. האם כדאי לקנות אותו? התשובה היא לא. אם נעמיד את ה-900P במבחן מול ה-960 PRO או ה-860 PRO, שתיהם ינצחו אותו בקלות, כלומר אתה יכול לחסוך 300 דולר ולקבל SSD שיתאים לך לבית.

עכשיו נלך לחברה. נניח שאנחנו מקימים Storage משלנו, נניח שאנחנו מקימים שרת SQL כלשהו (לא חשוב אם זה מיקרוסופט, אורקל או PostgreSQL או MySQL) או שרת אפליקציה שאמור לתת שרות למחשבים רבים או משתמשים רבים. כאן דווקא ה-900P יתן ביצועים הרבה יותר גבוהים בהשוואה ל-2 ה-SSD של סמסונג, הם "יחנקו" מהר מאוד.

ה-SSD ל-Enterprise בעקרון בנוי לתת שרות לכמה שיותר משתמשים/מחשבים/תחנות, כמה שיותר Clients, בשעה שה-2 השניים בנויים לתת שרותים לכמה שפחות, כלומר למחשב אחד, לכמה אפליקציות שרצות במקביל במחשב הביתי/תחנת עבודה. במילים אחרות – אם לא מעמיסים על דיסק SSD ל-Enterprise אתם תקבלו ביצועים רחוקים מאוד ממה שמוצהר ע"י היצרן.

פרסמתי כאן בתחילת השנה פוסט על SSD ל-Enterprise והוא רלוונטי בדיוק לפוסט זה. בפוסט הקודם הזכרתי את ה-QD (ה-Queue Depth) שצריך אותו כדי לתת שרותים לכמה שיותר Clients וזה בדיוק מה ש-SSD ל-Enterprise מצטיין בו ו-SSD לבית גרוע בו. ניקח לדוגמא את ה-960 PRO, אם תסתכלו בסקירה זו תיראו שברגע שמתחילים להעמיס עליו, הביצועים צונחים דרמטית.

עכשיו נשארנו עם בעיה אחת: נניח ואנחנו רוצים ביצועים מאוד גבוהים לשרתים עם דיסקים מקומיים (כן, לאלו שמריצים vSphere עם דיסקים מקומיים לדוגמא) אבל המחיר מפחיד. ה-DC P4800X לדוגמא בגירסה צנועה של 375 ג'יגהבייט עולה $1700 (המחיר קצת יקר באמזון, המחיר הרשמי הוא $1520) וגירסת ה-750 ג'יגהבייט עולה מחיר "צנוע" של $3,653. במחיר כזה, גם חברות גדולות מתחילות לחשוב פעמיים אם לקנות במחיר כזה.

מה ניתן לעשות? ישנן מס' אפשרויות:

  • לקנות כמה קטנים. אפשר לדוגמא לרכוש 2 כרטיסי 900P (אגב, אם השרתים שלכם חדשים, אז ניתן לקנות את ה-900P בגירסת U.2 שנכנסת מקדימה) ולחבר אותם ב-RAID-0 ולהגדיר אותם כ-Cache. זה מתאים למצבים שאנחנו רוצים להריץ את השרת כשרת קבצים או כשרת NFS/SAMBA ואליו נחבר לדוגמא שרתי vSphere.
  • אם אנחנו רוצים להריץ שרת SQL או שרת אפליקציה כבד, נוסיף דיסק SSD כלשהו למערכת, עליו נתקין את מערכת ההפעלה והאפליקציות אך ה-DATA ישב ב-RAID-0 (מתוך הנחה שיש לכם גיבוי יומי!) כ"כונן" נפרד.
  • נבחר כונני Enterprise יותר זולים. לאינטל יש את ה-750 שישן קצת (מ-2015) אבל נותן ביצועים יותר טובים, יש את ה-P4600 ו-4700, שהם מעולים. חברות גדולות, כמובן, לא קונות כוננים ישירות מאינטל או סמסונג, ולכן מומלץ לחברות אלו לבדוק מיצרן השרת שלהם אלו דיסקים ניתן לקנות (לא מומלץ לקנות עם חיבור SAS, לכולן יש פאנל קדמי לחיבור דיסקים SSD בחיבור U.2 או SATA).

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

כמה מילים על SSD ל-Enterprise

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

נתחיל ב"קרב" של SAS מול SATA: כשזה היה בדיסקים מכניים, אז כמובן ה-SAS ניצח, אבל כשזה מתקדם ל-SSD, אתם תראו יותר ויותר פתרונות ל-Enterprise שהם מבוססי SATA. רגע, כבר נכתבו אלפי מאמרים והרבה מרצים הרצו כמה SATA נחות לעומת SAS, אז מה קרה שהיצרניות מייצרות SSD כ-SATA ועוד ל-Enterprise?

התשובה לכך פשוטה וקשורה ל… תור, ספציפית לדבר שנקרא QD (כלומר: Queue Depth). המושג QD אומר בעצם כמה פעולות הבקר והדיסק יכולים להתמודד מבחינת תור. נסו לדמיין את עצמכם בסופרמרקט, זה עתה סיימתם להכניס מוצרים לעגלה ואתם עוברים לקופות. בד"כ אתם לא תגיעו ישר לקופאית, אלא תמתינו בתור כמו כל אחד אחר (טוב, תמיד יש תחמנים אבל זה משהו אחר) עד שיגיע תורכם להעלות את המוצרים מהעגלה למסוע, לתת לקופאית להעביר את המוצרים בסורק ולבסוף לשלם על המוצרים. ככל שיש יותר קופות פתוחות, התורים מתקצרים, וזה ההבדל הגדול בין דיסק SAS ל-SATA: בדיסק SATA יש 32 ערוצי תורים, ב-SAS יש 254 תורים, כך ש-SAS תמיד ישרת את הפניות יותר מהר.

עכשיו נשנה את הסיטואציה: אין קופאיות, העגלה בעצמה סורקת את המוצרים שלך ואז אתה מעביר את כרטיס האשראי בעמדות תשלום. האם התור יתקצר? בוודאי, תוך 2-3 דקות תוכל לסיים את הקניה, להעביר לשקיות ולצאת (טוב נו, בתיאוריה) – וזה מה שקורה עם SATA SSD: בגלל שה-SSD מאד מהיר והוא יודע בדיוק כל קובץ היכן הוא נמצא ואין צורך בראשים שיגיעו ויתחילו לקרוא את הנתונים ממקומות שונים, אז כתיבת/קריאת הנתונים תהיה מאוד זריזה, בוודאי כשנשווה זאת מול דיסק SAS מכני ולא חשוב מה תהיה מהירות ה-RPM שלו. בנוסף, דיסק SSD SATA טוב מגיע למהירות קריאה/כתיבה לפחות כפולה מכל דיסק SAS מכני והוא מריץ את ה-QD המוגבל שלו הרבה יותר יעיל ומהר מדיסק SAS מכני.

עוד סוג דיסקים שקיים הוא SAS SSD. טכנית, הדיסק נותן מהירות כפולה מדיסק SATA SSD, אך אם תבדקו אצל יצרנים שונים, תראו שהם פשוט כבר כמעט לא מייצרים כאלו מהסיבה הפשוטה: אם אתה רוצה משהו יותר מהיר מ-SATA, עבור ל-NVME. סמסונג, לדוגמא, מייצרת רק דיסק SSD אחד בחיבור SAS, והוא ה-PM1633a שמיוצר בגודל מרשים של 15.3 טרהבייט. המחיר? 4500$ לחתיכה. משום מה אני בספק אם יהיו רבים בארץ שיקנו אותו.

דיסקים NVME לא מתחברים לשום בקר RAID אלא מתחברים דרך חיבור U.2 (שהוא בעצם PCIe X4) ישירות ללוח ולמעבד (אם כי בחלק מהמקרים הוא עובר דרך צ'יפ "Switch" שנקרא PLX כי בלוח אין הרבה יציאות PCIe בלוחות מבוססי אינטל, ב-AMD Epyc התמונה אחרת לגמרי).

דיסקים SSD NVME בנוים בתצורה כזו של שרידות מאוד גבוהה, כך שאפשר לעבוד עליהם כיחידים או שניתן לקבוע זוג (דרך ה-BIOS/UEFI) כ-RAID-1 בשביל שרידות טובה או RAID-0 בשביל איחוד מקום (הדיסקים האלו הרבה יותר אמינים מכל דיסק SAS והם יודעים בעצמם לתקן שגיאות, בגלל זה יש להם גם אחריות של 5 שנים), אבל לפני שרצים חשוב לשים לב לא לקנות את הכי יקרים מהסיבה הפשוטה: אם אתם מייעדים את הדיסקים לשימוש אותו שרת מקומי בלבד או אם אתם מכניסים את זה לשרת קבצים שישרת 2-4 שרתים, אז הדיסקים המאוד יקרים לא יתנו לכם את הביצועים שאתם צריכים, בשביל שיתנו ביצועים גבוהים, צריכים כמה שיותר שרתים ושרותים שיכתבו ויקראו לדיסק, כלומר צריך למלא את ה-QD והרבה – בד"כ QD של 128 ידע לנצל את הדיסק הזה ואגב, אם SAS יכול לתת 254 תורים, דיסק NVME יכול לתת.. 50,000 תורים וכמה שתמלא את התור הזה הביצועים יהיו יותר גבוהים, לכן מומלצים דיסקים NVME מהסוג כמו של סמסונג כמו ה-PM863a  שמכיל 1 טרהבייט ועולה (בחו"ל) 480$. חשוב גם להכניס למחיר פאנל קדמי שיודע לתמוך ב-NVME (זה מגיע רק בתוספת תשלום ובחלק מהדגמים רק לחלק מהפאנל).

נקודה חשובה נוספת בשיקול היא דיסקים SSD עם או בלי סופר-קבלים (Supercapacitors). ישנם דיסקים רבים ל-Enterprise שמכילים זאת ובכך הם שומרים נתונים שעדיין לא נכתבו בעת הפסקת חשמל. זהו דבר חשוב אם אתם קונים דיסקים NVME, אולם אם הדיסקים הם SATA SSD, בד"כ הסוללה על הבקר תשמור את הנתונים עד לחזרת החשמל. כדאי לקחת זאת בחשבון.

לסיכום: מעבר ל-SSD זה דבר שיכול רק להועיל. לא חייבים לשרוף את התקציב השנתי על דיסקים ולא תמיד חייבים דיסקים Enterprise במקרים של SSD, אבל אם גם הולכים על דיסקים Enterprise, אין תמיד הצדקה לרכוש את היקרים ביותר – מכיוון שהם לא יתנו את הביצועים אם הדברים שאנחנו הולכים לבצע לא "קורעים" את ה-QD. לא מומלץ לנסות להקים RAID-5/RAID-6 על דיסקים NVME (ולמען האמת גם לא על SATA SSD) כי זה יקצר את חייהם משמעותית ולכן עדיף לרכוש דיסקים מעט יותר גדולים ולחבר אותם (דרך ה-BIOS/UEFI או תוכנת Storage) כ-RAID-1/RAID-10.

פתרון GlusterFS – היכן הוא מתאים לכם?

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

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

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

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

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

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

סיטואציה ראשונה
כאחד שנותן שרותי תמיכה ל-vSphere לגרסאותיו השונות, יש לי מילים חמות לאמר על VSAN. זהו פתרון אמין מאוד עם שרידות גבוהה מאוד ללא צורך בסטורג'. עם VSAN אפשר להגדיר פונקציות שונות כמו פונקציית שרידות מאוד גבוהה כך שמתוך קבוצה של 3 שרתים פיזיים, 2 נכבים, אפשר להגדיר ש-VM קריטי עדיין ישרוד.
הבעיה המרכזית עם VSAN אינה טכנית, אלא בעיה כספית. במחיר של $2500 לרשיון פר מעבד, על קבוצה של 3 שרתים פיזיים, אנחנו מדברים על 15,000$ וזה לא כולל את הרשיון היעודי של vSphere ולא כולל תמיכה של 3 שנים (שזה עוד 15,000$) ועוד לא הגענו בכלל למחירי הדיסקים – במיוחד שעם VSAN חובה ללכת בתצורת קבוצות של 2+1 (כלומר 2 דיסקים מכניים ו-1 SSD אם כי אפשר ללכת בתצורה היותר יקרה של 3 SSD ונוסיף לכך שאתה צריך שרתים מהדור האחרון או לפניו כדי להריץ את כל הדברים. מחיר כזה, לדעתי, אינו מוצדק עבור Dev, stage, testing, POC וכו'. במחיר כזה חברות כבר יחשבו על קניית אחסון יעודי.

במקום זה, אנחנו יכולים לקחת 3 מכונות שדווקא אינן חדשות (כל עוד בקר הדיסקים שלהם תומך ב-6 ג'יגהביט SATA/SAS, אם זה תומך רק ב-SATA 2.0, אז אפשר להכניס כרטיס בקר צד ג') כמו דור 7 של HP, דור 11 של DELL, דור 3 של LENOVO, ולמלא אותן בדיסקים. ניקח דוגמא: 10 דיסקים SATA של WD RED PRO (מחיר של 319$ באמזון פר דיסק, המחיר קצת יותר יקר אצל המפיץ בארץ) או WD GOLD Enterprise בגודל 10 טרה שעולה $361 פר דיסק, או Seagate מסידרת EXOS ל-Enterprise בגודל 10 טרהבייט שגם עולה $360. סה"כ עד כה – בערך $3600 (פר שרת). נוסיף עוד 2 דיסקים SSD – אם מחפשים זול וטוב, אז 2 דיסקים מה-850 PRO של סמסונג יוכלים לעבוד טוב (סה"כ 418$)ואם המכונה היא 2U, אז 2 כרטיסי SSD PCIE מסוג אינטל 900P 280GB AIC בתצורת PCIE (סה"כ 780$) יכולים לתת Cache די רציני למכונה.

ניקח את הבקר (ואת כרטיסי ה-PCIE) ונצמיד את כולם למכונת VM, נצמיד לה 32 ג'יגהבייט זכרון ו-4 ליבות, ועליה נרים GlusterFS (אם אתם מעוניינים בדחיסה, Dedup ושאר תפנוקים – יש צורך להקים עליה ZFS ועל זה GlusterFS), נחבר את המכונות ברשת פרטית וברשת "ציבורית") (כלומר 2 כרטיסי רשת וירטואלית פר VM של GlusterFS) והרי לנו תחליף ל-VSAN שיכול לתת לנו iSCSI, CIFS, NFS, אחסון אובייקטים (Object Storage) ועוד ועוד. בשביל ביצועים ושרידות נצטרך עוד מכונה כזו (עדיף עוד 2) – ויש לנו אחסון עם שרידות חזקה וביצועים גבוהים, ובו זמנית אפשר להריץ על השרתים עוד מכונות VM, ואת כל זה נעשה דרך ה-vSphere, כך שמבחינת עלות – שילמנו רק על החומרה ולא הפכנו את השרתים היעודיים לסטורג' בלבד (כך שלא נצטרך לבזבז שרתים). מבחינת גיבוי – זה VM ואפשר לגבות בכל תוכנה שמשתמשים בחברה (רק שחשוב לזכור לא לגבות את כל ה-VM שמריצים GlusterFS אלא רק אחד, חבל לשמור את הנתונים באותו גיבוי 3 פעמים).

סיטואציה שניה – אפליקציות
קונטיינרים הם ה"שוס" בשנתיים האחרונות ורבים מעבירים חלק מהמערכות לרוץ בקונטיינרים, שזה מעולה, אבל בחלק מהמקרים עדיין מעדיפים להריץ אפליקציות מסויימות בהכפלה וכו', לדוגמא MySQL על 2-3 מכונות VM, שרתי Front ו-Back על מספר מכונות VM ועוד. בכל המקרים הללו, באותם שרתים ניתן להקים GlusterFS כ-VM כמו שתיארתי לעיל (עם פחות דיסקים, רק חשוב שיהיה לפחות SSD אחד שישמש כ-Cache) ואז ה-DATA של האפליקציה (לדוגמא עם MySQL התיקיה var/lib/mysql/) תשב ב-GlusterFS (איך עושים? עוקבים אחרי ההוראות כאן), ה-WWW של שרת ה-Web ישב ב-GlusterFS וכו' וכו'. יהיו מספר שינויים קטנים שצריך לבצע (אולי להשתמש ב-HAProxy), וכך נוכל לקבל שרידות רצינית ומהירות משופרת בהרבה מכיוון שכל שרת אפליקציות יכול לקבל נתונים משרת GlusterFS קרוב וסינכרון הנתונים הוא מיידי – מבלי להשקיע כספים רבים.

סיטואציה שלישית – קונטיינרים/Kubernetes/Openshift
קונטיינרים רצים בד"כ על שרתי VM וקבצי ה-YAML, קבצי קונפיגורציות יושבים על דיסקים מקומיים אך ניתן להגדיר את ה-VM שירוצו על דיסקים וירטואליים שה-vSphere יקבל מ-GlusterFS דרך NFS או iSCSI. בנוסף, ניתן להגדיר Volumes עבור ה-Pods שישתמשו ב-GlusterFS (גם Kubernetes וגם אפליקציות שמריצות את Kubernetes כמנוע כמו Rancher, OpenShift וכו' תומכים ב-GlusterFS החל מ-Kubernetes 1.5). ואנחנו יכולים להשתמש לדוגמא ב-Volume מסויים במספר Pods במקביל, ועם GlusterFS ניתן לוותר על הרצת קבצי YAML/JSON ליצור את ה-Volumes ולגשת ישר ל-Volume Claim, המערכת תיצור את ה-Volume אוטומטית.

סיטואציה רביעית – בענן
מכיוון של-GlusterFS לא אכפת מה נמצא מתחתיו (דיסק מסכן, EBS וכו'), אפשר להקים את GlusterFS גם בענן. כל מה שאנחנו נצטרך הם מספר Instances (מומלץ 3 ומעלה לפרודקשן, 2 לטסטים) ולאותם Instances (שישמשו כ-Nodes) נחבר 2-3 אחסוני EBS ונתקין את GlusterFS ומשם אנחנו יכולים להשתמש ב-GlusterFS כפתרון אחסון לצרכים שלנו.

סיטואציה חמישית – קרוב רחוק
הקמה של GlusterFS זה דבר טוב ועוזר, אולם לפעמים אנחנו צריכים את הנתונים בחוץ, בחוות שרתים אחרת בארץ או בחו"ל. לשם כך, החל מ-GlusterFS 3.8 ומעלה ניתן להריץ Geo Replication לסנכרן בין מספר Volumes (בשיטת Master/Slave), ואפשר גם לספק צרכים "מופרעים" כאלו:

סיטואציה 6 – פתרון אחסון ל-VDI
הקמת VDI למאות עובדים זה פרויקט מורכב עם עלויות אסטרונומיות. (בימים אלו אני מנסה בבית להקים פתרון VDI עם דגש על מחירים נמוכים, ברגע שאצליח, אפרסם פוסט על כך). יש צורך לשלם למיקרוסופט, ל-VMWare וכמובן כל נציג מכירות יאמר לך – All Flash Array, כך שאם תרצה פתרון VDI טוב, תחשוב על כך סכום של 7 ספרות.

האם GlusterFS יכול לחסוך כאן במחיר? התשובה היא בהחלט. נתחיל בגירסה הזולה: זוכרים שהמלצתי על השרתים הישנים להרצת GlusterFS? אנחנו נשתמש בכאלו בגודל 2U עם פאנל קידמי של כונני 2.5 אינטש כך שאפשר יהיה להכניס בין 16 ל-24 דיסקים 2.5". לתוכם נכניס דיסקים 850 PRO של סמסונג בגודל שתבחרו, יש עד 2 טרהבייט (יש לוודא שהבקר דיסקים תומך במצב JBOD ושהוא תומך ב-SATA-3, אם לא – יש צורך בבקר אחר) ונכניס את הדיסקים הנ"ל למגירות ונצטרך לרכוש או אינטל 900P בגודל 480 ג'יגה או 2 כרטיסי אינטל 900P בגודל 280 ג'יגה, הכל לפי התקציב (עם 2 כרטיסים השרידות הרבה יותר גבוהה). על כל שרת כזה נקים ZFS עם Hot Spare ל-2 דיסקים SSD. כל ה-RAID יוגדר דרך ה-ZFS (כלומר RAIDZ לפי תצורה שמחליטים) ועל זה נקים את GlusterFS. את החיבור בין השרתים נחבר ב-10 ג'יגהביט (נחושת, SFF, FC – החלטה שלכם) ואת הזכרון נמלא ב-ECC 3 8500R (שהוא פחות מהיר אבל המהירות אינה ממש חשובה כשהשרת משמש Node ל-Gluster, הזכרון משמש בראש וראשונה כ-Cache ב-ZFS) עד המקסימום. המחיר לא כזה יקר: 2000 שקל (תלוי מהיכן אתם קונים) ל-192 ג'יגהבייט זכרון. נצטרך 3 מכונות. שימו לב: בשרת כזה נרוץ "על הברזל" ללא וירטואליזציה כלל ונוכל לגבות אותו כמו כל תחנת לינוקס (אם כי צריך לגבות רק אחד מהם, לא את שלושתם).

אם יש לכם כמה וכמה שרתים ישנים, אפשר לפצל את כמות הדיסקים לפי כמות השרתים הישנים שלכם (לדוגמא – 6 דיסקים בשרת 1U) ובכך לקבל ביצועים יותר גבוהים הואיל ולא מדובר בסיטואציית Active/Passive אלא עבודת קריאה/כתיבה מקבילית לכל המכונות.

אם מצד שני יש תקציב – אפשר לרכוש 3 שרתים כשהפאנל הקדמי שלהם הוא NVME ונרכוש דיסקים NVME U.2 – גם סמסונג וגם אינטל מוכרים דיסקים מעולים, והעלות משתנה לפי גודל הדיסק והפירמה שקונים ממנה. מבחינת רשת, תצטרכו לחשוב איך לחבר את הכל מכיוון שברוטו, תעבורת הקריאה מגיעה בין 40-60 ג'יגהבייט לשניה. אפשרי לצמד מס' כרטיסי רשת 10 ג'יגהביט או לרכוש כרטיסים ו-Switch של 40 ג'יגהביט (מלאנוקס, אינטל וכו' ישמחו למכור לכם). עם ההצעה הזו, המחיר שתצטרכו לשלם בהשוואה לפתרון אחסון מבוסס AFA (כלומר All Flash Array) יהיה נמוך יותר ב-50-70% מפתרון קופסא, וגם יש לכם שרידות יותר גבוהה.

בכל שאר הפרמטרים (וירטואליזציה, רשיונות וכו') – הכל נשאר אותו דבר.

ומה עם תמיכה? רד האט מוכרת את פתרון ה-GlusterFS כמוצר (Red Hat Gluster Storage) עם תמיכה מסביב לשעון.

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

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

העתיד: דיסקים, Storage ו-NVME-OF

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

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

התשובה: במקרים של דיסקים מכניים – בהחלט. במקרים של SSD – זה יוצא ההיפך. קחו דיסק SSD בחיבור SATA ותקבלו לדוגמא מהירות קריאה של 550 מגהבייט לשניה. לזה, שום SAS לא הגיע עם דיסקים מכניים (אלא אם מכניסים את ה-Cache של הבקר אבל זה יפה במבחנים, לא לעבודה במציאות) וכך עולם הדיסקים חזר "אחורה" ל-SATA ופורמט ה-SAS די "מת" למרות מאמצים מצד יצרני בקרים ושרתים להוציא (מאוחר מדי, LSI היו הראשונים להוציא מוצרים ב-2013) את SAS-12G, וכך המצב בשנתיים האחרונות בשוק הוא שדיסקים SSD קיימים בגירסאות SATA בלבד – אבל הדיסקים עצמם מכילים את כל תכונות ה-Enterprise כמו תיקון תקלות אוטומטי, שמירת מידע עצמאית בעת הפסקת חשמל, שרידות גבוהה בעבודות כבדות ועוד.

דיסקים SSD מבוססים SATA מאפשרים לחברות להמשיך לעבוד כאילו הם עובדים עם דיסקים מכניים או דיסקים SSD ישנים, ורבים נוטים עדיין לעשות את הטעות לעבוד כ-RAID-5,50,60 כשהם שוכחים 2 דברים מאוד חשובים:

ה-RAID-5 וה"אחים" שלו 50,60 ביצעו 2 דברים חשובים: נתנו ביצועים גבוהים הנובעים מעבודה עם ריבוי דיסקים וחלוקת העבודה בין הדיסקים, ושרידות יותר גבוהה מכיוון שאם הולך דיסק אחד או 2 (בהתאם לשלב ה-RAID) – המערכת היתה ניתנת לשיקום לאחר החלפת הדיסקים. עם SSD לעומת זאת (גירסת Enterprise!) הביצועים שהדיסקים האלו מוציאים די "חונקים" כל כרטיס רשת. תחשבו על כך: 2 דיסקים SSD ב-RAID-0 מוציאים מהירות תיאורתית של 1100 מגהבייט לשניה (בקריאה). נתרגם זאת לג'יגהביט ונקבל .. 8 ג'יגהביט, כלומר כרטיס רשת של 10 ג'יגהביט יהיה תפוס ב-80% בזמן שהוא משדר את ה-DATA מצמד הדיסקים, ושוב – אני מדבר על 2 דיסקים בלבד. אז מה בעצם נותן בקר דיסקים? ביצועים? יש כבר לדיסקים, לא צריך גם Cache. שרידות? ב-SSD ל-Enterprise יש יכולות הרבה יותר מרשימות של שרידות פנימית מאשר כמעט כל בקר RAID בשוק. ובכל זאת, חברות ממשיכות לעבוד כך. מדוע? אני חושב שזה עניין של הרגל.

בשנתיים האחרונות נכנסנו לעידן חדש של דיסקים SSD, מה שבהתחלה נקרא PCI SSD והיום פשוט נקרא NVME SSD. לדיסקים הללו לא תמצאו שום RAID כי הדיסק מחובר ישירות לתושבת PCIE X4 (בחיבור שנקרא כיום U.2, חלק מהיצרנים לצערי עדיין משתמשים בחיבור קנייני משלהם, לרווחתם של יצרני הדיסקים והשרתים, לצערם של הלקוחות ש"ננעלים" בכך שלא ניתן להכניס דיסקים יותר טובים מצד ג'). הדיסקים הללו כיחידות עצמאיות נותנות יותר ביצועים מכל מה שתשיג עם SSD ו-RAID, מהירויות של 2-4 ג'יגהבייט לשניה בקריאה ועד 2 ג'יגהבייט בכתיבה עם עשרות עד מאות אלפי IOPS (וכמובן את המילה האחרונה בשרידות, ושוב – שרידות הרבה יותר גבוהה מכל דיסק מכני שאתם מכירים) ושם כבר אין RAID (ואם רוצים RAID 0,1,10 – עושים זאת בתוכנה. הביצועים לא יהיו נמוכים יותר בהשוואה לבקר יעודי, האמינו לי, גם אם תנסו את זה על מעבד i5 פשוט [ניסיתי בעצמי מול בקר יוקרתי של LSI ]).

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

אם נסתכל מבחינת דיסקים, בשנה הנוכחית השוק מנסה להסתגל למצב חדש שבו יש הרבה יותר ביקוש מהיצע. דיסקים NVME SSD של 3-4 טרהבייט, גם אם תנפנף מול היצרן בכרטיס אשראי פלטיניום, תשלום מיידי או ערימת מזומנים – תיאלץ במקרים רבים לחכות וזה כרגע עדיין "מכה" ב-HP, DELL וגם ב-Lenovo. היצרנים נתפסו "במערומיהם" עם דרישות היסטריות לשבבי Flash מצד כל יצרני המחשבים והטלפונים. כולם רוצים שבבי NAND ועכשיו. יצרני השבבים גדלים (חברת TSMC לדוגמא, אחת החברות הגדולות ליצור שבבים – מתכננת בניה של FAB נוסף בסין בדיוק בשביל זה) ושבבי ה-3D NAND החדשים מאפשרים ליצור שבבים עם כמות אחסון יותר גדלה בליטוגרפיה בשיטות יותר "ישנות" כך שניתן פר Waffer ליצור יותר שבבים. שלבים אלו ואחרים יתורגמו לשחרור לחץ בשוק במהלך השנה שנתיים הקרובות.

אבל גם אם הבעיה תיפתר, נמצא את עצמנו בבעיה אחרת: בשביל ביצועים רציניים צריך NVME SSD וגם אם יש לך דיסקים חדשים וגדולים כאלו, איך בדיוק תשתמש בהם? זה לא שיש לך בקר RAID להגדיר Virtual Disk שעל זה אתה מתקין Windows, Linux, vSphere וכו'.. אפשר כמובן להוסיף דיסק קשיח כלשהו (ולהשתמש בבקר הפנימי כדי לבנות RAID-1 מדיסקים פשוטים) כדי להתקין את מערכת ההפעלה וכו', אבל הדבר הבא שהיצרנים ידחפו נקרא NVME-OF (זהירות, לינק לקובץ PDF). זהו הסטנדרט חדש שנבנה ע"י החברות שבנו את סטנדרט NVME, ועם הסטנדרט הזה אנחנו משתמשים בכמה מושגים שבוודאי שמעתם עליהם:

  • ה-AFA (כלומר All Flash Array) – מערכת סטורג' (או שרת) שבנוי כולו מדיסקים NVME SSD.
  • על מה נעביר את הנתונים? זוכרים ROCE? אז הוא חוזר לסיבוב נוסף, ולאלו שאוהבים לשפוך כסף כאילו אין מחר (בנקים, מכוני מחקר יוקרתיים וכו') – Infiniband.
  • ובאיזו שיטה? זוכרים iSCSI? אז נגזור משם את ה-Target ו-Initiator, שיהיה לכם חיים יותר קלים.
  • אבל מה עם כתובות IP וכו'? זה ישאר, רק שהפעם זה "נעקר" מה-OS ומועבר לביצוע ע"י כרטיס הרשת (כלומר TCP Offload).

עכשיו נשלב את הכל ביחד: נבנה שרת מבוסס Dual Xeon עם 128 ג'יגה (עדיף יותר, תלוי בכמות ה-Clients וכו') מבוסס לינוקס עם קרנל 4.8.7 ומעלה, עליו נרים מערכת שתהווה בעצם Target ובה ישבו לא רק הדיסקים אלא גם מספר כרטיסי רשת עם פס רחב (25 ג'יגה ומעלה או Infiniband). הכרטיסים יחוברו למתג תואם ומשם יחוברו לשאר השרתים שאנו מעוניינים. את חלוקת ה-Volumes וכו' נעשה על ה-Linux והמערכת בלינוקס תשדר זאת דרך ה-ROCE כבלוקים (אפשר עם שילוב TCP/IP, אפשר גם בלי אבל אז יתחילו הצרחות ממחלקת ה-IT) וה-Initiator בשרתים יתחבר ל-Target (יהיו גם אפשרויות אותנטיקציה, הצפנה וכו'). שרתים ישנים יוכלו להעלות את ה-Initiator לדוגמא דרך IPXE (או PXE לחובבי טכנולוגיה קלאסית) ומשם ה-OS יעלה ויקבל תמיכה מלאה כאילו מדובר בדיסקים מקומיים.

והביצועים? אם נשווה זאת לדיסקים NVME מקומיים, ההבדל יהיה באחוזים בודדים. מכיוון שכל השיטה מעיפה כל דבר שמוסיף Latency, הביצועים נראים כאילו מדובר בדיסקים מקומיים, רק שאין צורך לבצע תחזוקת דיסקים פר שרת והכל מבוצע ממקום אחד (ומנסיון, התחזוקה לא כזו מורכבת). סתם דוגמא: גם אם שפכתם כסף והפכתם את המערכת תקשורת שלכם ל-100 ג'יגהביט, תקבלו (במספר חיבורים במקביל) קצב של 93 ג'יגהביט בקריאה, ו-40 ג'יגהביט בכתיבה. עכשיו תנסו לדמיין מערכת VDI לאלפי משתמשים ואיך זה יעבוד, וכן – יש Initiators ללינוקס, Windows ול-VMWare כבר כיום.

כמובן שחובבי מיקרוסופט לא ישארו בצד ואם הם רוצים להקים לעצמם Target מבוסס Windows Storage Server אז הם יצטרכו להמתין קצת לגירסה הבאה.

לסיכום: דיברתי כאן על דיסקים SSD, על תקשורת שגבוהה בהרבה מ-10 ג'יגהביט, על NVME-OF (ממש על קצה המזלג). הטכנולוגיה קיימת כבר כיום (חברת Mellanox  כבר דוחפת ומדגימה אותה), אבל שום חברה לא עוברת מהיום למחר לטכנולוגיה חדשה שמצריכה החלפת מתגים וכרטיסי רשת ורכישה רצינית של NVME SSD ושרתים לכך. אלו דברים שלוקחים זמן, לפעמים שנים – אבל זהו הכיוון שהשוק ל-Data Center עובר אליו. חברות סטורג' רבות ישמחו למכור לכם את הפתרון לאחסון מחר בבוקר, אבל לפחות מבחינת TCO ו-ROI (ואם החברה מוכנה לאמץ מעט ראש פתוח) אני ממליץ לחשוב על פתרון בניה עצמית. הוא הרבה יותר קל ממה שרבים נוטים לחשוב (סתם דוגמא: הוא הרבה יותר קל מאשר הקמה וניהול של שרת ZFS) והוא פתרון שיכול להיות Scale Out די בקלות וזול בהרבה אם חושבים להרחיב – מאשר פתרון קנייני.

מוגש כחומר למחשבה 🙂

שאלות ותשובות על Cloudforms/ManageIQ

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

ש: האם CF/MIQ מתאים להחליף את הממשק ה-Windows/Flash/Web של vSphere?
ת: באופן עקרוני CF/MIQ בהחלט יכולים להחליף הממשק הקנייני של vSphere (או vCenter כפי רבים מכירים זאת), כמו שהוא יכול להחליף את ממשק ה-SCVMM בכל מה שקשור למכונות VM, אבל שימוש בכלי כזה רק לשם החלפת ממשק כמוהו כחיסול זבוב עם תותח 🙂

חשוב – שימוש ב-CF/MIQ אינו מייתר רכישת vSphere. ה-CF/MIQ מתממשק ישירות ל-CF/MIQ ולפיכך יש צורך ברכישת הרשיון vSphere.

המטרה העיקרית של CF/MIQ היא לנהל Life Cycle מלא של מכונות VM, וכדי לייעל תהליכים להקמת VM שאינם קשורים ישירות לפלטפורמת ה-VM שלך (פרטית או ענן). תהליכים הקשורים לבירוקרטיה בחברה, אורך חיי VM, פורטל בקשות הקמת VM ע"י הצוותים השונים בחברה, מימוש נהלים, עדכוני אבטחה (בשלב זה במכונות Linux Guest) ועוד. אם נשווה את זה לכלים המוכרים בתחום VMWare למשל, אז זה משהו כמו vRealize Orchestrator + vCenter Server – רק ש-CF/MIQ לוקחים את זה צעד קדימה לאפשר לך להתחבר גם לפלטפורמות VM אחרות ולעננים פרטיים וציבוריים.

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

ש: האם ניתן להשתמש בחלק מה-Appliances גם בגירסה הפתוחה (MIQ) וגם בגירסה המסחרית (CF)
ת: ברוב המקרים התשובה היא "כן", אבל אז אינך יכול לקבל תמיכה רשמית למערכות CF/MIQ. חברות שמעוניינות בפתרון, צריכות או להשתמש בגירסה המסחרית או בגירסה החופשיה (ללא תמיכה רשמית).

ש: האם ישנה פלטפורמת אוטומציה ב-CF/MIQ?
ת: בהחלט! בברירת המחדל CF/MIQ תומכת ב-Puppet יחד עם Foreman, ניתן להשתמש גם ב-Chef וב-Ansible.

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

ש: איזו גירסה יותר מעודכנת ועם יותר Features ואיזו גירסה נחשבת יציבה?
ת: ה-ManageIQ כולל את "המילה האחרונה" מבחינת תכונות המערכת. זו המערכת שמפותחת מדי יום (לתוך GIT מרכזי פתוח) וניתן לשלוף את הגירסה האחרונה או גרסאות קודמות. האם מערכת כזו נחשבת יציבה? כל עוד לא הולכים ל-Bleeding Edge (או ה-Master ב-GIT) – אז יחסית כן, אם כי יכולים לצוץ באגים פה ושם.

לעומת זאת ה-Cloudform זו מערכת שמבוססת על ManageIQ אם כי לא על הגירסה האחרונה של ManageIQ. לגירסה זו נערכים בדיקות ומתוקנים באגים ורק למוצר הרשמי ניתנת התמיכה הרשמית של רד-האט.

ש: מה המחיר של Cloudforms?
ת: עניין המחיר הוא דינמי, זה תלוי על איזו מכונה אתה מריץ את CF, כמה Appliances אתה צריך, מהו סוג השרות שאתה מחפש (NBD, 24/7 וכו'), האם אתם משתמשים בעוד מוצרי רד-האט וכו'. אינני יכול לתת מספרים אבל אני כן יכול לרמוז שהמחיר נמוך ממחיר vRealize Operations (ואתה מקבל יותר, ואף אחד לא "יושב לך על הצוואר" מבחינת כמות VM) 🙂

ש: אנחנו משתמשים באובונטו במערכות שלנו, האם המוצר (המסחרי או הפתוח) יכול לרוץ על VM אובונטו?
ת: מכיוון שה-CF הוא Appliance, הוא מגיע כ-VM מוכן שצריך רק לבצע לו Deploy, להגדיר כתובת IP (או DHCP), להיכנס למסך הניהול ולהגדיר את שאר הדברים משם (ניתן כמובן לבצע SSH ולהשתמש במכונה כמכונת לינוקס אם רוצים לשנות דברים, לא מומלץ אם לא מכירים CF/MIQ).
יחד עם זאת, אם אתם משתמשים בגירסת ManageIQ, ישנם הוראות ברשת איך להקים זאת על VM מבוסס אובונטו (ולכך כמובן לא ניתן לקבל תמיכה מרד-האט).

ש: היכן ניתן לראות רשימת Features שקיימים בגירסה האחרונה?
ת: הנה (לחצו להגדלה)

ש: בחברתנו חוששים להכניס מוצרים כאלו מכיוון שבמקרים רבים התיעוד לוקה בחסר. האם למוצר יש תיעוד מלא שנגיש ללקוחות?
ת: במקרה של Cloudforms כלקוח אתה מקבל גישה מלאה ואתה יכול להוריד את ההסברים וההוראות כקבצי PDF. בנוסף יש גם ספרות רשמית שניתנת להורדה.
גם ל-ManageIQ יש תיעוד (ברובו אותו תיעוד של Cloudforms) אולם יש לשים לב לשינויים שיש פה ושם בין ManageIQ לבין Cloudforms.

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

ש: האם יש תמיכה ב-Cluster/High Availability?
ת: בהחלט! זה אחד הדברים הראשונים שהתיעוד מסביר איך לעשות אם אתה רוצה להשתמש במערכת כ-Cluster.

ש: כמה זמן לוקח לאינטגרטור מטעם רד-האט בארץ להקים PoC של Cloudform מקומית? האם יש גירסת Trial?
ת: זה מאוד תלוי ב-Scope של ה-PoC ותלוי במסמך ה-SoW. לדוגמא: הקמה של Appliance וחיבור לפלטפורמת ה-VM הנוכחית שלכם אפשר לבצע תוך יום עבודה. קאסטומיזציה, טפסים, כתיבת תוספים – אלו דברים שלוקחים זמן נוסף. כל פרויקט לגופו.

לגבי Trial – בהחלט יש.

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

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

ש: יש תמיכה ב-LDAP/Active Directory?
ת: בהחלט. מטרת המערכת בסופו של דבר לתת למספר אנשים גדול בחברה להיכנס ולמלא בקשות שונות ולמנהלים לתת הוראות ואישורים.

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

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