קטגוריה: יעוץ וירטואליזציה

קונטיינרים: ה"קרב" בין OpenShift ל-Docker DataCenter

בפוסט הקודם שכתבתי כאן על קונטיינרים וחברות מסחריות, ניסיתי להסביר מעט על קונטיינרים ועל המוצרים שנמכרים בארץ כאשר התרכזתי ב-2 מוצרים: ה-Docker DataCenter ומולו ה-OpenShift (גירסה מסחרית או גירסת Origin שהינה קוד פתוח) – עבור שוק ה-Enterprise. בפוסט זה אשווה קצת יותר (בצורה כללית) בין המוצרים ואנסה להסביר היכן כדאי להוציא הזמנת רכישה והיכן כדאי "לדלג".

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

בימים האחרונים השתמשתי בגירסת ה-Trial ל-Docker DataCenter (ובקיצור: DDC), למדתי אותה, הקמתי אותה אצלי ב-LAB הקטן שלי. השתמשתי ב-Swarm שבתוכו (שזה בעצם ה-Scheduler ועוד) ובשאר הכלים שגירסת ה-Enterprise כוללת. הייתי צריך להקים כ-5 מכונות וירטואליות (Nodes) כדי שהדברים יעבדו, עוד לפני שיכלתי להקים קונטיינר אחד. בסופו של דבר, המערכת עבדה בצורה טובה, יחסית. (אם כי נתקלתי באיזה באג או 2 שמצאתי להם "עיקוף").

מבחינת מחיר: DDC אינו זול. מחיר גירסת ה-Enterprise פר Node הוא 1500$ לשנה (כפי שניתן לראות כאן, גללו לאמצע הדף). על מנת להרים מערכת Enterprise, תצטרכו לרכוש לפחות 5 רשיונות: manager, registry, cache – אלו הם חלקים שרצים כ-VM נפרדים ב-DDC, עוד Node ל-Worker (שעליו בתכל'ס רצים הקונטיינרים) ותצטרכו מינימום עוד אחד אם אתם רוצים שרידות ועמידה בעומסים. (אפשר כמובן להריץ את החלקים השונים כקונטיינרים, אבל Docker ממליצים להרים את החלקי ניהול כמכונות VM נפרדות), כלומר אנחנו מתחילים במחיר של 7500$ לשנה. כל Node נוסף – עוד $1500.

הבעיות עם DDC פחות קשורות לבאגים או תכונות, אלא בעיה כללית שיש לחברת Docker בכל מה שקשור ל-Enterprise. הבעיה הראשית שלהם מאוד מזכירה את ההתנהגות של חברת רד-האט בצעירותה: רד-האט היתה משחררת גירסת לינוקס חדשה כל שנה ושוברת את התאימות הבינארית בין גירסה לגירסה. גירסה 5 לא תאמה לגירסה 4, גירסה 6 לא תאמה ל-5, גירסה 7 היתה עולם אחר לגמרי שלא תאם לגרסאות קודמות מבחינה בינארית. כלי ניהול הגיעו ונעלמו כלעומת שבאו, ויצרני תוכנה וחומרה התעצבנו מכל המהלכים הללו והן הביעו את דעתן בשיחות מול רד-האט ובעיתונות הטכנולוגית. לקח לרד-האט במשך שנתיים להבין שהדרך הזו אינה מקובלת לא על יצרני תוכנה וחומרה, ולא על Enterprise וכך נולדה משפחת ה-RHEL (כאשר כל הפיתוחים ושבירת התאימות עברו לגירסת Fedora), וכיום RHEL ניתנת עם תמיכה ועדכונים ל-10 שנים. ב-Docker לעומת זאת, שבירת התאימות היא עניין שבשגרה לגבי מוצרי הקוד פתוח, ומה לגבי הגירסה המסחרית שחברות משלמות? אה, לזה הם מוכנים לתת עדכונים ותיקונים למשך .. שנה אחת. מי בדיוק ה-Enterprise שמוכן לקנות מוצר שיהיה לו תמיכה ותיקונים לשנה אחת בלבד ובשנה אחר כך ב-DDC תישבר התאימות? שאלה מעולה!

ב-רד האט, למודי הנסיון, הדברים שונים לחלוטין.

ברד-האט יודעים שחברות לא ששות כל כך מהר לשלם עבור מוצרים שמיועדים לסביבות פיתוח, טסטים, QA, סביבות אוטומציה וכל דבר שאינו פרודקשן, ולכן רד האט אומרת: קחו את מוצר ה-OpenShift Container Platform (ובקיצור: OSCP) בחינם או את גירסת OpenShift Origin היציבה (נכון להרגע זו גירסה 1.4, כל עוד אתה מארח את הכל על התשתית שלך או תשתית הענן שלך), רק תזכור – זה לא מקבל תמיכה! כלומר את OSCP אפשר להרים על הלאפטופ (מספיק מכונת VM אחת או על הפצת הלינוקס במכונה ללא VM) או בשרתים הפנימיים לפיתוח וכו'. מעוניין בגירסה מסחרית עם תמיכה? הנה המחירון של Grey Matter. כפי שאתם יכולים לראות, על כל Node המחיר הוא 2724 ליש"ט ואם ה-Node הוא שרת פיזי, המחיר הוא 6810 ליש"ט (זה לפני מו"מ כמובן) עם תמיכה לשנה, ויש גם מחיר ל-3 שנים תמיכה, סטנדרט או פרימיום.

כלומר אם נניח יש לך 4 מכונות VM בפרודקשן שיריצו את ה-OpenShift והקונטיינרים, ושאר המכונות הם פיתוח, טסטים וכו' ואתה רוצה שרות תמיכה מרד-האט למכונות הפרודקשן, אתה יכול לרכוש 4 רשיונות. זה בדיוק כמו שאצל חברות רבות שרתי הפרודקשן מריצים RHEL עם רשיונות ואילו שאר המכונות של העובדים, פיתוח, טסטים וכו' – מריצים CentOS.

בסופו של יום, 2 המוצרים מציעים טכנולוגיות שונות. האחת (DDC) משתמשת ב-Swarm כדי לנהל את ה-Scheduling, Load Balancing, FT וכו' ואילו השניה משתמשת ב-Kubernetes. רוצה לדעת מי יותר פופולרי? תשאל את המפתחים ואנשי ה-Devops בחברתכם מי מכיר מה, אתה תקבל תשובה מהר מאוד מדוע Kubernetes כה פופולרית (כי היא קלה להתקנה וניהול בהשוואה ל-Swarm). ה-OpenShift של רד-האט תומך בגדילה של עד 1000 Nodes, ועד 120,000 pods. במילים אחרות, עם מערכת OpenShift אחת אתה יכול תיאורתית לארח את האתרים ואפליקציות בגדלים ענקיים!

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

על תשתית קונטיינרים לחברות מסחריות

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

מערכות קונטיינרים בפלטפורמות שונות (קרדיט: Wikibon)

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

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

בנוסף, פתרון של קונטיינרים עוזר לנצל בצורה טובה יותר את התשתיות שלכם. עשו נסיון פשוט: הקימו VM לינוקס עם 2 או 4 ליבות וכמות זכרון מספקת והתקינו עליו אפליקציה חשובה לכם. הריצו את ה-VM והאפליקציה ומדדו את ניצול הליבות. אם אתם רואים שניצול הליבות אינו מלא, אז אפליקציה כזו יכולה להיות מועמדת מעולה להרצה בקונטיינר, שם תוכלו להריץ אותה מספר פעמים עם אותם משאבים (כאשר אתם מקבלים "על הדרך" Load Balancing, High Availability מפלטפורמת הקונטיינרים) . אפשר גם להריץ אותה עם משאבים נמוכים יותר אם אינכם רוצים שרידות.

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

עתה נחלק ל-2 את החברות בארץ: יש כאלו שקוד פתוח זה "בעורקים" שלהם – יש להם צוותים שמכירים לינוקס מאוד לעומק, נסיון עשיר ב-Python ו-Go והם יכולים לקמפל לינוקס קרנל בין פיהוק למשנהו ואם יש בעיה בתוכנת קוד פתוח – מישהו בצוות יכול לחטט ולתקן. לאותן חברות שמחפשות פתרון קונטיינרים מקיף אני פשוט ממליץ ללכת על OpenShift Origin על תשתית וירטואליזציה ולהתחיל להשתמש. כל מה שאתם צריכים בשביל להריץ קונטיינרים, להקים, לבנות, Load balancing, HA וכו' וכו' – הכל כבר שם. תורידו מה-GIT ותתקינו ואין לכם צורך לשלם על כלום.

ב-95% מהמקרים האחרים – חברות בד"כ יעדיפו מוצר מסחרי עם תמיכה מלאה של היצרן, עדכונים מהיצרן וכו' וכאן בישראל נמכרים 2 מוצרים: Docker Datacenter שנמכר ע"י מטריקס ו-OpenShift שנמכר ע"י העסק שלי (אם כי, לשם הגילוי נאות וה"פרסומת", העסק שלי אינו היחיד שמוכר אותו, רק שכאן תקבלו משהו .. טיפה יותר מקצועי. הדגמות וידאו על Open Shift, אגב, בקרוב יופיעו בערוץ יוטיוב של חץ ביז).

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

  • אם אתם חושבים להקים מכמות של כמה מכונות בודדות (VM או פיזי) ועד כמה עשרות כאלו (הם נקראים Nodes) – אז מבחינת תמחור, ה-Docker Datacenter זול בהרבה מהפתרון עם OpenShift. בנוסף, אם מערכת ההפעלה העיקרית שלכם היא Windows והקונטיינרים שלכם יריצו קוד שרץ על מערכות מיקרוסופט – Docker Datacenter הוא הפתרון היחידי כרגע המתאים לפלטפורמות מיקרוסופט.
  • אם לעומת זאת אתם מתכננים על מאות Nodes ומעלה – הפתרון של OpenShift שווה יותר (וזול יותר)
  • אם אתם מעוניינים להקים תשתית חדשה לגמרי שתהיה נפרדת מתשתית הוירטואליזציה הנוכחית שלכם ושאותה תשתית חדשה תריץ קונטיינרים – אז אני ממליץ לרכוש את ה-OpenStack החדש (שם קוד: Magnum) שדואגת גם לתשתית כולה (Compute, Network, Storage, Authentication, Images וכו') וגם להרצת קונטיינרים, בניה, LB, HA וכו'. גם רד-האט וגם SuSE ישראל מוכרים את OpenStack Magnum. אינני יכול לפרסם מחירים של אף מוצר אבל מה שאני כן יכול לרמוז – זה שכדאי להתעניין אצל 2 הספקים במחירים. התחרות רצחנית!

כדאי לזכור משהו חשוב: אין מעבר קל בין Docker Datacenter ל-OpenShift. שתיהן אמנם משתמשות ב-Dockerfile כדי להרים קונטיינרים מבוססי Docker, אולם כל המערכות "מסביב" הינן שונות לחלוטין. ב-Docker Datacenter משתמשים ב-Docker Swarm ואילו ב-OpenShift משתמשים ב-Kubernetes. אפשר לייצא ולייבא קונטיינרים דרך סקריפטים אבל מנסיון – זה לא כיף גדול וזה די מורכב.

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

מעכשיו – יש גם מכירות

[blockquote author="(לקוח פוטנציאלי)"]במחירים כאלו – אין לנו כל כוונה לרכוש את המוצר![/blockquote]

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

עד ששבוע שעבר התרחש משהו שדי שכנע אותי לשנות דברים.

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

עברו 48 שעות ואותו מנמ"ר מרים אליי טלפון. ה-PoC שהוא חשב עליו? מבוטל. מדוע? הצעות המחיר שהוא קיבל היו לדבריו "מבהילות" והוא לא מוכן לשלם מחירים כאלו. מכיוון שאני מכיר מחירים, ביקשתי שישלח לי את ההצעות במייל, אולי יש כאן אי הבנה של איזה איש מכירות או משהו. קיבלתי את ההצעות ומכיוון שאני מכיר את המחירים של יצרן התוכנה – חשכו עיניי. קודם כל שהיו חסרים חלקים שגם עולים בתשלום אבל גם כך – הצעות המחיר היו בין 180 ל-250 אחוז מהמחיר שהיצרן מבקש וההצעות לא כללו מחירים נוספים הכוללים התקנה/אינטגרציה וכו'. פשוט קובץ ISO ומספרים סריאליים פר שרת.

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

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

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

אז החל מהיום, אם אתם מחפשים מוצרים ופתרונות של רד-האט או SuSE, "חץ ביז" הוא פרטנר רשמי של 2 החברות ואתם מוזמנים ליצור קשר

 

שאלות ותשובות על 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 ועוד.

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

כשזה מגיע לניהול מערכות VM

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

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

אבל מה לעשות, ברוב המקרים הטכנולוגיות הן שונות. להרבה חברות לדוגמא יש את Hyper-V מצד אחד או vSphere מקומי ומצד שני הם רוצים לעבוד עם אמזון או גוגל (או במקרים יותר מעניינים – Hyper-V עם אמזון או גוגל). אז לאמזון יש כלי שבקרוב יצא שיתן לך לחבר את AWS אל ה-vSphere שלך (חכו לחשבוניות השוק..), אבל גם פתרון כזה לא מכסה אפילו עשירית ממה ש-AWS מציע מבחינת שרותים וכשזה מגיע לחסכון – אתה חייב להכיר את השרותים השונים בכדי לחסוך. יש מקרים גם שצריך להרים עננים פרטיים (כמו ה-OpenStack) ומה לגבי קונטיינרים? מיקרוסופט ואחרים מאוד מעודדים להשתמש בקונטיינרים.

ישנם בשוק כלים שונים החל מ-Terraform, המשך ב-Ansible, Chef, Puppet ועוד – שהם מיועדים לכתיבת אוטומציה של בניה והגדרות התשתיות הללו, והם אכן מעולים לכך ואני ממליץ עליהם (עם העדפה ל-Ansible) לשימוש בתוך החברות. עם כלים כאלו אפשר לכתוב אוטומציה החל ברמה של הרמת VM ועד ההגדרות הכי קטנות ופרטניות בתוך ה-VM. תן לאוטומציה להריץ סקריפט (או Playbook או Recepie) שכתבת עבור הקמה כזו – והוא אץ רץ להקים זאת.

העניין הוא שחברות רוצות כלי שיש לו:

  • GUI
  • פופולריות רצינית בשוק כך שאפשר למצוא פתרונות לבעיות
  • שניתן להרחבה בקלות בעתיד
  • שיש לו "אבא" – שאפשר לקבל ממנו את התמיכה (ואם ה"אבא" לא אחראי על הקוד שלו, אפשר לתבוע לו את הצורה… שיטה מקובלת מאוד אצל האמריקאים, מה שנקרא indemnification).

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

תכירו את Cloudforms של חברת רד-האט.

ה-Cloudforms הוא כלי מרכזי שמאפשר למנהלי IT (ואחרים – כמו מפתחים, בודקי תוכנה ואחרים, הכל לפי הרשאות) לראות ולנהל את כל תשתית הענן שלהם ולא משנה ממה היא מורכבת. יש לכם Hyper-V? OpenStack? GCE? AWS? Kubernetes? ברזלים ללא VM? (ועוד רבים אחרים, יש ערימות תוספים) – אין שום בעיה. תגדירו אותם במערכת ותתחילו לעבוד. צריכים Orchestration? יש בפנים. רוצים לנהל אותה מבחוץ עם Puppet או Ansible? זה כבר כלול. רוצים גרפים יפים כדי להראות על מסך 50" בחדר ה-NOC? חיבור ל-Grafana מבוצע בקלות! צריכים להעביר VM מכאן בישראל לענן כלשהו ולא חשוב איזה ענן? אין שום בעיה! צריכים סטטיסטיקות מה קורה עם התשתית? כמה קליקים ויש לכם גם את זה. גדילה אוטומטית במקרים של עומס? יש. ויש עוד פונקציות נוספות רבות.

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

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

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

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

איזה מהמוצרים מתאים לכם? אם אתם חברה שאין בה אנשי לינוקס עם ידע רציני, ואתם לוקחים אינטגרטור רק להקמה ואולי לתמיכה – אז גירסת ה-Cloudforms תתאים לכם (יש גם Trial ל-PoC). לעומת זאת, אם אתם חברה שלינוקס זה חלק מהתשתיות שלכם ויש לכם אנשי לינוקס עם ידע רציני, אז ManageIQ יכול להיות פתרון די טוב עבורכם (כל עוד אינכם צריכים תמיכה רשמית).

פתרון אלטרנטיבי אחר (גם מבוסס לינוקס) הוא SuSE Manager (עם תמיכה ישראלית של סוזה ישראל) והוא יותר מתאים לחברות שלא מחפשות להשתמש בשרותים שספק הענן מציע (SQL, מייל וכו') אלא אך ורק להריץ מכונות VM, לנהל את מכונות ה-VM, עדכונים, Policy וכו'. המוצר זמין כגירסה מסחרית בלבד (עם גירסת Trial ל-60 יום).

הנה וידאו של חברה גדולה (General Mills) שעברה להשתמש ב-Cloudforms.

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

על "ספריות" וריבוי עננים

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

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

הבעיה הכי גדולה בד"כ כשמנסים להתממשק במקביל לענן פרטי וענן ציבורי, זה שכל ענן מצריך סקריפטים ו/או אפליקציות שונות להתחבר אליהם. ה-vSphere Client שלך לדוגמא לא יכול לדבר עם Azure או GCE, ולמרות שניתן לחבר אותו ל-AWS, לא ניתן לבצע דברים מרובים שקשורים בסטורג' בענן כמו S3 או דברים אחרים (כמו EFS לדוגמא). חמור מכך – כשיש לך תשתית מורכבת בענן הפרטי ובענן ציבורי, שתיהם יצטרכו תחזוקה אחרת. אחרי הכל, אם אתה משתמש לדוגמא ב-CloudFormation של אמזון, זה לא יעזור לך ממש מול כל ענן אחר, פרטי או ציבורי.

ישנם מספר פתרונות לכך, כולם מבוססים על ספריית libcloud של Apache והם:

פתרונות אלו יכולים לתת לחברה חופש לעבוד כמעט עם כל פתרונות וירטואליזציה מקומית (למעט Hyper-V – זה יותר באשמת מיקרוסופט שעדיין לא מתקנת את התמיכה שלה ב-libvirt) ובמקביל מאפשרת לעבוד עם כל ענן ציבורי, מהגדולים ועד הקטנים (הרשימה המלאה כאן). כך לדוגמא, אם אתה רוצה להרים מספר מכונות עם תשתית רשת פשוטה לצורך ביצוע עבודות שונות, אתה יכול לבחור לדוגמא ב-Digital Ocean או Linode ששם המחירים יותר זולים מהמחירים של ספקי הענן הגדולים ובנוסף אתה לא משלם על התעבורה החוצה (עד 3 או 5 טרהבייט כל חודש). אינך צריך לבנות את הסקריפטים מאפס אלא פשוט להשתמש בספריית libcloud ובפתרון שמתאים לשפה שאתם עובדים איתה כדי להרים את התשתית, לבצע שינויים וכו' ובכך תוכל בשימוש בספריה הזו לשלוט בכל תשתיות הענן שאתם משתמשים ללא צורך בכתיבה מיותרת של ערימות סקריפטים.

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

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

סיכום שנת 2016 – אחסון מבוסס קוד פתוח

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

מבחינת מוצרים מסחריים, ScaleIO של EMC יצא השנה בגירסה 2.0 עם שיפורים ניכרים הן בטכנולוגיה והן מבחינת ביצועים (לתשומת ScaleIO – אכפת לכם לרדת משמות ציודים כמו dev/sda/? היום הכל הולך ב-UUID, כך שמי שמזיז דיסקים, לא יקבל שמות שונים ומערכת שנופלת!). עוד ועוד חברות מוציאות Appliances שמשתמשים במוצרי קוד פתוח קיימים (Gluster, Ceph, ZFS) כדי למכור פתרונות Scale Out המאפשרים הרחבה לגדלים של פטהבייטים ומעלה. קשה לפרט כי יש המון כאלו.

מבחינת פתרונות Scale Up, עדיין ZFS שולט בראש, ומוצרים הכוללים אותו (QuantaStor, FreeNAS ואחרים) הולכים ומשתפרים "מסביב" – כלומר הטכנולוגיה נשארת אותה טכנולוגיה, רק שנוספים דברים כמו תמיכה יותר טובה ל-Active Directory, מכונות וירטואליות קטנות שניתן להרים על הקופסא הפיזית של ה-Storage (במקרה של FreeNAS) ועוד. השנה גם אינטל החלה להיכנס בזהירות לתוך ZFS (במיוחד ללינוקס) עם תרומות קוד בכל הקשור לטסטים ונסיונות על מכונות עם דיסקים מרובים (מה לעשות, אין הרבה חברות שמרימות מכונות עם 40+ דיסקים מכניים + SSD רק לשם טסטים). השנה גם עניין ההצפנה נכלל באופן טבעי ב-ZFS עם מספר אפשרויות להצפנה הן ברמת קובץ או Volume וכו'.

מבחינת Scale Out – פתרונות CEPH שולטים כפתרונות קוד פתוח וחינמי/זול. השנה סוף סוף הגיעה היציבות ל-CephFS כך שניתן לבצע ישירות mount ל-CephFS לשרתי לינוקס שונים ללא צורך בהגדרות מיוחדות. השנה החלה גם להיכנס (עדיין לא בצורה יציבה אלא כ-Technology Preview) ה-BlueStore – טכנולוגיה שכותבת את המידע שמגיע ל-Ceph בצורה שונה ויותר אופטימלית כך ששימוש ב-SSD ב-Ceph יכול לתת ביצועים פי 2 ומעלה. עוד דבר חשוב – טכנולוגיות דיסקים חדשות (PMR, SMR וכו') נתמכות ב-BlueStore עוד הרבה לפני הפתרונות הסגורים המסחריים (לא מומלץ להכניס דיסקים SMR לפתרונות סטורג' ל-VM או דברים כאלו, אלו דיסקים שמיועדים לגיבוי וארכיבאות בלבד)

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

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

למי שמחפש את הגירסה הארוכה:

אם נסתכל מבחינת ביצועים נטו, הן ZFS והן Ceph יכולים להוציא מיליוני IOPS בלי יותר מדי בעיות ולשרת משתמשים מרובים בצורה חלקה. כמובן שיש צורך בלהגדיר דברים רבים בשביל להגיע לתוצאות אלו – אך זה בהחלט דבר אפשרי, הן לעבודה מול שרתי וירטואליזציה, עיבוד תמונה, עיבוד וידאו, הזרמת וידאו וכו' וכו'. יחד עם זאת – אני לא ממהר להמליץ לזרוק את ה-Netapp/EMC/3PAR שלכם לטובת מערכות כאלו מהסיבה הפשוטה שיש הרבה דברים שהמערכות הסגורות נותנות וזה כולל ממשק נוח, הרחבות שונות קנייניות שעוזרות בעבודה של הסטורג' ועוד.

ב-2 הפתרונות, ניתן לייצא החוצה קבצים ב-CIFS ו-NFS וכמו כן Block Devices (כמו iSCSI).

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

  • בתוך LAB
  • בשימוש בוירטואליזציות קוד פתוח (Open Stack, KVM, Xen, Oracle VM, VirtualBox)
  • שרת אחסון נתונים הן כגיבוי והן כהזרמה (Streaming – לגיבוי אני יותר ממליץ את ZFS)
  • צוותי פיתוח (לזה אני ממליץ יותר את ZFS)
  • מקומות עריכה גדולים של וידאו (4K), אודיו וסטילס (פוטושופ)

מבחינת בחירת פתרון – Ceph ו-ZFS דורשים פתרונות חומרה שונים לחלוטין. ב-Ceph מתחילים עם 3 שרתים יעודיים (שלא יריצו כלום חוץ מ-Ceph) ומתג רציני (10 או 40 ג'יגה) וזה הפתרון שמאוד מתאים לחברות שרוצות להגדיל את הנפחים ומהר או להתחיל מההתחלה במאות טרה בייט ולגדול לפטהבייטים ומעלה. לעומת זאת, ZFS שאמנם יכול לגדול ל-Zettabyte עם תוספת בקרים שונים וקופסאות JBOD נוספות, אך הגדילה שלו מעבר לפטהבייטים מצריכה הרמת אשכולות ZFS ושימוש בפתרונות כמו Lustre וזהו עניין שבהחלט אפשרי – אך מורכב.

מבחינת חסכון: פתרון קוד פתוח לא מבטיח עלות אפס גם אם אתם מיישמים לבד הכל. כן, זה יהיה יותר זול מפתרון קנייני, אבל דיסקים, דיסקים SSD ל-Enterprise, המכונות עצמן, מתגים וכו' – עולים לא מעט ותחזוקת החומרה היא עליכם. בנוסף, יש לא מעט מקרים שאני ממליץ (במיוחד ב-Ceph) לרכוש את הגירסה המסחרית של תוכנת הקוד הפתוח על מנת לקבל עדכוני תוכנה ותיקוני תוכנה וכדאי לקחת זאת בחשבון (במקרה של Ceph ישנו הפתרון בישראל של SuSE SES 4 ו-RedHat Storage 2.1 – שתיהן מבוססות על Ceph בגירסת Jewel).

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

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

כשרוכשים 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]

כמה מילים על ניטור

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

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

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

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

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

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

עד כה דיברתי על 2 סוגי ניטור:

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

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

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

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