קונטיינרים וגדילה, צרכים מול מציאות

עבדכם הנאמן ממשיך בביקורים בחברות גדולות במשק הישראלי בנסיון להסביר יותר לגבי קונטיינרים, מערכות אורקסטרציה לקונטיינרים (מה שמבוסס Kubernetes), תמיכה ב-CI/CD וכו', אך אחד הדברים שקשה להעביר להנהלות השונות, הוא עניין ה-Scaling הרוחבי, שהוא אחד ההבדלים המהותיים בין עבודה עם מכונות VM ו-Scale קבוע, לבין קונטיינרים עם Scale דינמי.

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

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

אם היינו לוקחים אתר מסחרי ו"ממירים" אותו לעבודה כקונטיינרים על ענן ציבורי כלשהו, רוב התקלות היו נמנעות, כי מערכת כמו Kubernetes/OpenShift יודעות לבצע Scaling אוטומטית אם פשוט מגדירים זאת, בין אם מדובר בגדילה או בהקטנה, בהתאם לעומסים. אתם עובדים עם אמזון וצריכים עכשיו להרים 500 קונטיינרים וכבר הגדרתם את הכל באותו ענן? תוך דקות ספורות הכל יהיה למעלה ואם תצטרכו יותר קונטיינרים עקב עומסים, יקח למערכת שניות ספורות להוסיף קונטיינרים, וזה אחד ההבדלים הגדולים בין קונטיינרים ל-VM (או EC2 Instance): ל-VM לוקח מספר דקות כדי להיווצר ולהיות מוגדר לעבודה יחד עם השאר. גרוע מכך: אם המערכת רצה On Premise, אז בעצם צריך לנחש כמה מכונות להקים ומערכות וירטואליה אינן טובות בהוספה אוטומטית של מכונות VM (וכמובן – בענן ציבורי יש הרבה יותר משאבים ממה שיש On Premise או בכל ספק Hosting מקומי).

קונטיינרים הם דברים חד פעמיים, שנהרסים בתום עבודה (או כשהם קורסים עקב שגיאה/באג), וכשמתחילים להשתמש בכלי CI/CD עם קונטיינרים, כמות הקונטיינרים שתרוץ במקביל מתחילה לטפס במהירות. אם לדוגמא נשתמש בכלי כמו Jenkins עם תמיכה בקונטיינרים ונגדיר את Jenkins לעקוב אחרי כל מיני Repositories של קוד שמפתחים כותבים, ברגע שמבצעים Commit, מערכת Jenkins תקים קונטיינר ותבנה בתוכו את הקוד. נניח שיש לנו מספר Repositories ומספר עבודות ב-Jenkins שזה מה שהן עושות, נראה שהמערכת מהר מאוד תקים מספר קונטיינרים, ואם נגדיר את המערכת להריץ טסטים על קונטיינרים שנבנו מ-Build אחרון, נקבל מספר כפול ותוך זמן קצר כולם יכולים לראות שמשאבים מנוצלים במהירות, הן מבחינת Compute וכמובן מבחינת אחסון (תסתכלו על הגרפים של ה-VM שמריצים את ה-Kubernetes/OpenShift). היתרון הגדול כמובן בקונטיינרים, זה שהכל נבנה מאפס, ואין יותר "אצלי זה עובד אז אם לך לא עובד, זו בעיה שלך".

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

אבל הבעיה מתחילה שצריכים להריץ קונטיינרים ומערכת כמו OpenShift/Kubernetes – כדי לשרת את הקהל בחוץ. כמות הגולשים היא דינמית, והמערכת צריכה להיות בנויה בצורה שונה בהשוואה לעבודה מול מערכות VM או EC2 Instances. דוגמא פשוטה: אם אנחנו רוצים לכתוב תכנים החוצה מהקונטיינר (שוב, קונטיינר הוא דבר חד פעמי וכשהוא נהרס, המערכת מוחקת הכל אלא אם הקונטיינר נבנה עם הגדרות של כתיבה חיצונית בדרכים מסויימות), זה שלאותו VM יהיה גם 10 טרהבייט דיסק קשיח וירטואלי לא יעזור במאומה כי שיטת אחסון הנתונים היא שונה, יהיה צורך במקרים רבים וכשיש כמות גדולה של כתיבה ודרישה לשרידות רצינית – להשתמש ב-Object Storage שמבוצע ב-Scale Out שאינו בנוי על VM שמאוחסן על איזה Datastore ב-vSphere, וכאן כבר יש צורך או בסטורג' Scale Out קנייני שיודע לתמוך ב-Object Storage או להקים מערכת שתרוץ כ-VM על הברזלים וגם הקונטיינרים ירוצו על הברזלים עצמם ללא וירטואליזציה (למעט קונטיינרים מסויימים שאיננו סומכים עליהם ונוכל להריץ אותם עם וירטואליזציה קטנה כמו עם Kata Containers) ומעל זה יכול להיות שנצטרך להריץ איזה Load Balancer כלשהו (אם כי מערכות Kubernetes/OpenShift נותנות פתרון Load Balancing אבל לא בטוח שחברות ירצו להשתמש בו לצרכים של אתרים חשופים). פתרונות כאלו לא יתנו לנו גמישות מקסימלית כמו שרות הרצת קונטיינרים שספקי הענן מציעים (בגלל שלהם יש הרבה יותר משאבים).

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

  • ענן פרטי עם OpenStack: הפתרון הזה יכול לתת לנו את הכל ביחד. אנחנו יכולים להשתמש בסטורג' קנייני כלשהו ולחבר אותו ל-OpenStack כדי לקבל שרותים כמו Object Storage, Block Storage וכו' או שאנחנו יכולים להקים VM בכל שרת ולהריץ עליו Ceph.
  • עבודה במצב Hybrid: יש לנו מקומית מערכת OpenShift או Kubernetes פנימית שעליה אנחנו מבצעים פיתוח וכו', ואת האתרים הציבוריים אנחנו נשתמש בשרותי הקונטיינרים שספק הענן שבחרנו מציע. אם לדוגמא החברה משתמשת ב-Azure, אז הם יכולים להשתמש בשרות AKS. באמזון יש את אותו שרות (בערך) שנקרא EKS (או Fargate ששם אמזון מנהלת את ה-Kubernetes ואתה מריץ את הקונטיינרים) ובענן של גוגל יש את GKE. ה-Hybrid מומלץ לחברות שהרגולטור אוסר עליהן להוציא הכל החוצה.
  • עבודה "באותו ענן" – במקומות בהן בחרו לעבוד לדוגמא עם Azure, ניתן לרכוש מיצרן השרתים המועדף עליכם את Azure Stack – זהו פתרון שרץ על הברזלים אצלכם מקומית עם חיבור ל-Azure, כך שאפשר להשתמש באותם שרותים, מקומית או בענן בחוץ. עם עננים אחרים, אתם משתמשים בשרותי ה-Kubernetes של ספק הענן כך שהשינויים להריץ דברים מקומית או בענן הם די מינוריים וניתן להפריד את ההגדרות לקבצים שונים. בהמשך השנה, גם אמזון וגם גוגל יציעו לכם ברזלים ותוכנה להריץ את השרותים שאתם מריצים בענן – מקומית ובענן, כמו ה-Azure Stack.
  • שימוש ב-OpenShift – מערכת OpenShift קיימת לשימוש מקומי בשרתים שלכם או ב-OpenShift בענן שקיים אצל כל ספקיות הענן.

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

אם יש לכם שאלות, אתם מוזמנים לפנות אליי.

הסברים והבהרות לגבי Scale Out בתחום אחסון

אחת למספר שנים מתרחשים שינויים מהותיים בתחום הסטורג'. לפני מס' שנים נכנס דבר שנקרא Object Storage – זו צורה שונה לאחסון קבצים ונתונים שבמקרים רבים אינה משתמשת ב-File system רגיל. חברות כמו Seagate לדוגמא הוציאו מספר דיסקים קשיחים ובנו חיבור חדש לדיסקים – חיבור Ethernet ישירות לדיסק, מה שמחייב כמובן מערכת אחסון אחרת. (נכון להרגע, הפתרון הזה יותר מתאים לחברות כמו אמזון, גוגל ומיקרוסופט, או לחברות שבונות את ה-Object Storage שלהם, גם מבחינת חומרה).

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

אך מהו בעצם פתרון Scale Out?

חברות אחסון רבות לקחו את המושג "Scale Out" לכיוון שהם רוצים. יש חברות שמייצרות HCI (כלומר Hyper Converged) שלקחו את המושג Scale Out לכיוון הוספת שרתים שיתנו לך יותר משאבי מחשוב/רשת/אחסון. חברות אחרות לוקחות את זה לכיוון שאם אתה מרים ערימת שרתים, אתה מתקין VM בכל אחד מהם שמחובר לדיסקים המקומיים בכל שרת וישנה תוכנה שמתחברת לכולם ובכך נוצר Storage (אין Networking גודל בכל מכונה והמכונה לאו דווקא מריצה מכונות VM אחרות) ויש כמובן את ה-Scale Out שעליו דיברתי בפוסט הקודם – ערימת שרתים מלאים דיסקים שלא מריצים מכונות VM או Payload משלך אלא תוכנה יעודית של יצרן הפתרון בלבד.

לעומת פתרון Scale Out – יש פתרון ותיק שנקרא Scale Up, שבו יש פתרון שמורכב ממערכת אחת (או 2 לשרידות) ודרך הגדלת האחסון היא הוספת דיסקים מכניים (או SSD אם רוצים יותר IOPS), אך כמות הברזלים נשארת זהה.

המכנה המשותף לכולם הוא פשוט: צריך עוד מקום אחסון? אתה מוסיף עוד שרתים, או שאם אתה רוצה – אתה מוסיף דיסקים, אבל לכל השרתים שיש בהם דיסקים (למעט HCI, בפתרונות אחרים, במיוחד בתחום HPC – מוסיפים שרתים כי Resizing לכל מכונה יקח זמן רב מדי).

לא כל פתרון Scale Out מתאים לכל הסיטואציות. בתחום HCI לדוגמא, אתה יכול להוסיף עוד כמה טרהבייט בחישוב הכולל בכך שתוסיף עוד כמה דיסקים (מכניים/SSD) פר מכונה ובכך תקבל יותר אחסון ויותר IOPS, אבל פתרון כזה אינו מתאים אם לדוגמא אתה צריך מאות טרהבייטים עד פטהבייטים (ומעלה) של אחסון ואין לך צורך בהרבה מקום נוסף למכונות VM. בסיטואציה כזו אתה חייב פתרון אחסון Scale Out שידע לעמוד בשרידות של שרת אחד או 2 שנופלים ולא פתרון Scale Up (למרות שרוב פתרונות ה-Scale Up מתהדרים בכך שהם יכולים לגדול לפטהבייטים).

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

  • אם מדובר במערכת HCI שתהווה אלטרנטיבה ל-VSAN/Simplivity/Nutanix – אז יש את GlusterFS והוא מגיע יחד עם RHV.
  • אם מדובר במערכת Scale Out שלא הולכת לגדול מעבר למספר קטן של שרתים (כמה עשרות) – ניתן לרכוש את GlusterFS בנפרד.
  • אם צריכים מערכת אחסון שתורכב מעשרות שרתים ואחסון בגדלים של מאות טרהבייט ומעלה, או שתריץ מערכת ענן פרטי כמו OpenStack בחברה – מערכת SES של SuSE או Red Hat Ceph Storage יתנו לכם מערכת מבוססת CEPH שבנויה לדברים הללו (הפתרון של SuSE בארץ זול משמעותית בהשוואה למחיר שרד-האט מבקשים, ויש את אותה פונקציונאליות בשתיהן).
  • גם Ceph וגם GlusterFS מתאימות אם אתם הולכים להריץ קונטיינרים/Kubernetes/OpenShift על הברזלים.

לסיכום: פתרון Scale Out טוב (שאינו מבוסס HCI) הוא פתרון שנותן:

  • להגדיל את כמות האחסון למימדים גדולים (מאות טרהבייט ומעלה)
  • שרידות הרבה יותר גבוהה מפתרון Scale Up (מערכת ששורדת גם כששרת אחד או יותר המאחסנים את הפתרון נופלים)
  • תמיכה בסטנדרטים אחרונים (Object Storage, Persistent Volume, ,Cinder וכו')

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

סטורג' לחברות גדולות

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

הערה 2: למעוניינים, כתבתי פוסט נוסף לגבי הסברים בין Scale Out ל-Scale Up והוא נמצא כאן (אתם יכולים ללחוץ על הלינק והוא יפתח ב-TAB חדש).

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

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

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

  • קונטיינרים / Kubernetes – הקונטיינרים הנחמדים האלו תופסים מקום, ואם מבצעים Scale Out גדול כך שמריצים לדוגמא מאות קונטיינרים – יש צורך בכמות אחסון גדולה, לא רק לקונטיינר אלא גם ל-Volume שמוצמד לקונטיינר, וברוב המקרים יש לפחות Volume אחד פר קונטיינר שאותו אנחנו רוצים לשמור גם לאחר שהקונטיינר מת.
  • לוגים ותובנות – ככל שיש לנו יותר מכונות וירטואליות, יותר מערכות Orchestration כמו Kubernetes או OpenShift יהיו לנו המון לוגים. אנחנו צריכים את הלוגים שלהם ואנחנו צריכים מערכת ניתוח רצינית (כמו כל המערכות שמבוססות Elastic) והדבר הזה תופס טרהבייטים כמו כלום.
  • מערכות Big Data שונות – יותר ויותר גופים מתעניינים, ומערכות אלו אוכלות אחסון כאילו אין מחר.

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

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

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

יש כמה דברים שכל גוף גדול שרוצה לרכוש סטורג' צריך:

  • תמיכה בפרוטוקולים ידועים (CIFS/NFS, iSCSI)
  • תמיכה בהאצת וירטואליזציה (VASA/VAAI)
  • תמיכה ב-Snapshots
  • מערכת ניהול מרוכזת
  • שרידות גבוהה
  • חלוקת עומסים בין החלקים השונים של המערכת
  • Tiering (מידע שמועבר מדיסקים SSD מהירים לדיסקים מכניים איטיים יותר וההיפך לפי הצורך)

עכשיו אוסיף עוד כמה דברים:

  • תמיכה ב-Kubernetes וב-Persistent Volumes
  • תמיכה ב-Object Storage (כמו S3)
  • תמיכה ב-Cinder (אחסון block)

עתה נעבור לפתרון סטורג' Scale Out שמבוסס על תוכנה (Software Defined)

בפתרון כזה אנחנו לא רוכשים ברזלים קנייניים של יצרן סטורג' כלשהו. במקום זה, אנחנו רוכשים (אחרי תהליך מכרז בו אנו מפרטים כמות סטורג' רצויה, כמות IOPS וכו' וכו') תוכנת סטורג' ומי שזכה מציין איזו חומרה צריך. כל יצרני התוכנה מבצעים Certify מול כל יצרני השרתים הפופולריים כך שלא תצטרכו לרכוש שרתים וציוד ממקור אחר שאין לו חוזה עמכם. החומרה עצמה מורכבת משרתים (לא צריך חזקים), דיסקים SSD ומכניים, כרטיסי רשת 50/100 ג'יגה, וסוויצ'. כל הציוד עצמו אנחנו רוכשים בדיוק מאותו ספק שזכה במכרז למכור שרתים לחברה, וממנו גם נקנה את הדיסקים, כרטיסי רשת ומהזוכה שמוכר לנו את הסוויצ'ים נרכוש 2 סוויצ'ים. לאחר הרכישה, ספק תוכנת הסטורג' יקים את התוכנה, יגדיר את מה שצריך להגדיר וכמובן יתן שרות במסגרת SLA וכל מה שיוגדר במכרז.

הערה: כל יצרני השרתים מוכרים גם פתרונות סטורג' Scale Out משלהם, רובם מצריכים רכישת הברזלים והמערכת מהם.

מדוע פתרון זה עדיף מפתרון סטורג' Scale Up כמו מה שיש ברוב החברות? מכמה סיבות:

  • תמיכה – יש לכם תמיכה מלאה מספק התוכנת סטורג', 24/7, כפי שהגדרתם בהסכם. בנוסף, אם ישנה תקלת חומרה, אתם פונים לאותו ספק שרתים שאתם רוכשים ממנו כל הזמן.
  • מחיר יותר זול – שדרוג דיסקים וזכרון בשרת הוא הרבה יותר זול משדרוג דיסקים בסטורג' קנייני.
  • גדילה יותר זולה – מחירי שרתים יורדים כל מספר חודשים, מה שקשה לאמר על מחירי סטורג' אם רוצים להוסיף מדפים, Flash Cache וכו', כך ניתן להוסיף שרתים, להגדיל את כמות ה-IOPS והמקום הפנוי בצורה יותר זולה.
  • שדרוג לפונקציונאליות נוספת – רוב יצרני ה-Software defined storage מוסיפים פונקציות בגרסאות מתקדמות, והספק יכול לדאוג לשדרוג מערכת קיימת. נסו לקבל פונקציונאליות נוספת משמעותית אחרי שקניתם סטורג' קנייני.
  • טכנולוגיות SSD יותר מתקדמות – סמסונג, אינטל, טושיבה, מיקרון, כולם עובדים על פיתוחים לדיסקים SSD יותר גדולים, מתקדמים, מהירים. כל יצרני השרתים ישמחו למכור לכם את הדיסקים הללו עם תמיכה ושרות מהיצרן שרתים שלכם ישירות. זה לא ממש קיים בסטורג' קנייני – מה שקניתם, זה מה יש (למעט דיסקים בגדלים שונים, אך לא טכנולוגיה שונה).
  • שרידות הרבה יותר גבוהה – כל תוכנת סטורג' מבוססת תוכנה יודעת לתת שרידות ברמת דיסקים או Nodes, כך שגם אם שרת נופל, המערכת ממשיכה לעבוד כרגיל ויש גם תוכנות שניתן איתן להגדיר שגם אם 2 שרתים נופלים – המערכת ממשיכה לעבוד.

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

מוקדש כחומר למחשבה. אם יש לכם שאלות, אתם תמיד מוזמנים ליצור קשר.

וירטואליזציה: לחזור לברזלים?

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

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

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

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

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

  • עלויות מטפסות: אם נניח יש לנו כיום 10 שרתים שמריצים את כל הדברים בוירטואליזציה ועתה נוסיף 10 שרתים נוספים שיריצו דברים "על הברזל", הדברים מסביב יעלו יותר: קירור, חשמל, תחזוקת השרת (מבחינת תוכנה וחומרה). בהתחלה זה נשמע כאילו מדובר בעלות קטנה, אולם מכיוון שאנחנו צריכים לאמץ את השרתים (כי לשם כך אנחנו מבצעים V2P) – עלויות החשמל והקירור יעלו באופן רציני.
  • שדרוג חומרה: תעיפו מבט בחומרת השרתים. לעיתים השקעה של כמה מאות או אלפי דולרים חד פעמית בשדרוג מעבדים ו/או זכרון יכולה להאיץ את הביצועים של המכונות הוירטואליות ולחסוך מעבר מוירטואלי ל"ברזל".
  • להתראות לדברים הנחמדים: וירטואליזציה נותנת לנו פונקציואנליות שקצת קשה להשגה כשדברים רצים ישירות "על הברזל". קחו לדוגמא Snapshot – סביר להניח שאינכם משתמשים ב-ZFS על הברזל, כך שיצירת Snapshot של הברזל היא קצת בעייתית (במיוחד אם אין לכם LVM או שלא הגדרתם ווליום לוגי שיאחסן את ה-Snapshots בנפרד). רוצים HA? לא תוכלו להשתמש ב-HA שהוירטואליזציה מספקת, תצטרכו פתרון נפרד, ובהצלחה בבניית Fault tollerance על ברזלים, ואלו רק חלק קטן מהפונקציונאליות שוירטואליזציה נותנת וריצה "על הברזל" לא נותנת.
  • גיבוי ושחזור – הרבה יותר איטיים מאשר גיבוי ושחזור מכונות וירטואליות.

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

סטטוס וירטואליזציה מבוססת קוד פתוח – סוף 2018

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

מי שהולך לכנסים והרצאות של חברות שונות ושל ספקי ענן שונים, שומע בוודאי איך חברה X או חברה Y עברו לענן, הם מרוצים עד השמיים והכל ורוד ומאושר. המציאות, לפחות משיחה עם חברים פרילאנסרים שמבצעים אינטגרציות או מעברים לפלטפורמות שונות – קצת שונה. כן, ישנן חברות שמעבירות חלק מהמכונות VM שלהן לענן, חלקן מעיפות מכונות VM ומשתמשות בשרתי ענן שונים (כ-PaaS), אבל לא יצא לי להכיר שום חברה עם כמה אלפי מכונות VM בארץ שבסופו של דבר השביתה את ה-DC שלה והעבירה הכל מהכל לענן. ככלל, הויכוחים על העלויות השונות בטווח הזמן הקצר והארוך (בתוספת כמה מילות Buzz) גורמים ללא מעט חברות להאט מעבר לענן, לבצע Hybrid מדוד מאוד, והיו כמובן לא מעט מקרים שפשוט "חזרו הביתה" (אם כי זה לא סופי. מי שחושב שאין בתחום ה-IT מקרים שמקבלים החלטה X ואחר כך מבטלים ואחר כך שוב חוזרים – מוזמן להתעורר).

אני מודה שעד לאחרונה כל עניין הוירטואליזציה בקוד פתוח לא ממש תפס אחוז גדול בתחום ההטמעות ב-Enterprise. כמעט כולם הולכים ל-VMware, חברות שכמעט כל התשתית שלהם מבוססת מיקרוסופט משתמשים ב-Hyper-V ואלו שרוצים Hyper Converged הולכים על Nutanix או Simplivity. אחרי הכל – למוצרים האלו יש תמיכה, יש בארץ אינטגרטורים, לא צריך לקנות מחו"ל רשיונות, יצרני החומרה מאשרים שהמוצרים עובדים עם הברזלים. בקיצור, סבבה אגוזים.

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

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

בפוסט זה אציג, כמו בפוסטים קודמים – 3 מערכות (Proxmox, oVirt/RHV, OpenStack) ולמי הם מתאימים ומה השוני שלהם.

נתחיל במערכת שמתאימה יותר לחברה קטנה או ל-LAB מקומי: Proxmox.

תוכנת Proxmox מתאימה ליישומי וירטואליזציה הן על מערכות ישנות (כן, אותו שרת G7 של HP שיושב שם בצד) והן על מערכות חדשות. המערכת עצמה היא יחסית קלה ללימוד, ומי שעבד על ESXi עם vCenter בצורה לא מקצועית (כלומר לא עבר קורסים והכשרות של VMware) יוכל להקים תוך דקות ספורות מכונות וירטואליות על דיסקים מקומיים, לחבר NFS או iSCSI וגם להשתמש ב-HA ולבצע Live Migration (כל עוד יש אחסון משותף, זו לפחות הדרך המומלצת). בקיצור -אם אתם צריכים להקים מערכת וירטואליזציה על מספר קטן של שרתים, ללא הקמה של רשתות וירטואליות מורכבות או דברים הרבה יותר מורכבים (DVSwitch?) – אז Proxmox יכול להתאים למשימה.

המערכת הבאה יותר מתאימה לחברות שמריצות מערכות וירטואליזציה מורכבות עם רשתות וירטואליות שונות (המערכת משתמשת ב-Open Virtual Network ו-Open vSwitch, וכן רשתות SDN), סטורג'ים בפרוטוקולים שונים, חיבור ל-OpenStack, ודברים נוספים. המערכת היא oVirt. טכנית, oVirt נבנתה מגירסה 4 להריץ מערכות גדולות וכשאני מציין גדולות, אני מדבר על אלפי ועשרות אלפי מכונות וירטואליות. בשעה שפתרונות כמו ProxMox מתרכזים ב-Bridge Networking, מערכת oVirt תומכת במספר פתרונות רשתות וירטואליות, והיא בין המערכות היחידות שתומכות גם בפלטפורמות שאינן X86-64 כמו מערכות Power ו-S390 של IBM. מבחינת HA, היא בין המערכות המובילות בדיקות ברמת חומרה (דרך ILO/IMM/IDRAC) מה קורה לברזל והיא יודעת להעביר את ה-VM אם יש תקלה ולטפל בשרתים פיזיים בעייתיים – החל מהקמה של חדשים, שדרוג קיימים ועוד. מערכת oVirt מבוססת על מערכת KVM האחרונה (כן, אותה חברה שמפתחת את oVirt היא אותה חברה שמפתחת את KVM – זו רד-האט) כך שיש תמיכה בציודים וירטואליים חדשים, מערכות UEFI וירטואליות מודרניות ועוד), התממשקות ל-VCenter, המרה יעילה של מכונות וירטואליות ל-oVirt, תמיכה ב-AD/LDAP ועוד שורה ארוכה של פונקציות. בהשוואה ל-Proxmox, מערכת oVirt היא מפלצת ולכן היא פחות מתאימה לרוץ על שרתים עם מכונות וירטואליות שמאוחסנות על דיסקים מקומיים. oVirt, אגב, מגיעה מוכנה לשימוש הן כשרת שיתחבר לסטורג' והן כ-Hyper Converged.

oVirt מתאימה להטמעות גדולות הן כ-PoC והן כפרודקשן כל עוד יש בחברה ידע פנימי (או יועץ חיצוני) שיכול לתת תמיכה. מנהלים שמנוסים עם VMWare או Hyper-V ואינם מנוסים מספיק או בעלי ידע רציני בלינוקס יתקשו בניהול מערכת כזו ללא השקעה בלימוד הדברים, והסיבה לכך פשוטה: oVirt אינה מנסה להיות העתק של VMware והדגש של oVirt הוא יותר על פונקציונאליות מאשר חזותיות (אם כי חל שיפור ניכר בחלק הזה בגירסה 4.2 ובגירסה 4.3 שתצא במהלך 2019). חברות שמעוניינות במוצר ארוז ובתמיכה רשמית עם רשיונות – ניתן לרכוש את מוצר ה-RHV עם תמיכה.

ומכאן – למפלצת הגדולה: OpenStack.

אם oVirt היא מערכת גדולה, OpenStack היא גודזילה לכל דבר ועניין. ההבדל הגדול בין oVirt ל-OpenStack הוא ש-OpenStack מנסה לתת לך הכל מהכל. וירטואליזציה? יש. קונטיינרים? יש את Zun שמאפשר להריץ קונטיינרים כ-שרות. DB כ-שרות? יש. אחסון תואם S3? יש. אחסון Images ודברים אחרים? יש. צריך Load Balancer? תכיר את Octavia, ויש עוד עשרות חלקים. עם oVirt לעומת זאת – המיקוד הוא לכיוון מתן שרותי וירטואליזציה והשרותים מסביב, לא יותר מכך.

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

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

ומה העתיד?

פתרונות הוירטואליזציה ממשיכים להתקדם, גם הפתרונות המסחריים הסגורים אך גם הפתרונות מבוססי הקוד הפתוח. ב-VMWare הכריזו בכנס האחרון על ESXI ל-ARM, פלטפורמה שנכנסת יותר ויותר לספקי הענן הציבורי ו"זוחלת" לכיוון ה-Enterprise (תסתכלו על Ampere). פתרון הוירטואליזציה KVM ו-QEMU (שבהם כל מערכת בנייה כמו Yocto משתמשות) יש תמיכה בעשרות מעבדי ARM כבר 6 שנים ומעלה, מערכת OpenStack תומכת ב-ARM, ו-oVirt תתמוך כנראה בגירסה הבאה (אם לא תהיה גירסה כזו, אני כנראה בשנה הבאה ארכוש שרת ARM ואבצע BUILD לכך. מהנדסי רד-האט ישראל – תתכוננו להצקות ממני 🙂 ). עוד ארכיטקטורה שהולכת להיתמך היא מעבדים זולים מבוססי MIPS החדשים.

מבחינת תקשורת – רשתות 100, 200 ו-400 ג'יגה יהפכו לאט לאט לנורמה והמתגים עצמם יהיו מבוססים שבב מרכזי קנייני ושבב ARM שמריץ לינוקס, ומי שינהל את המתג – זו מערכת הוירטואליזציה (דרך הלינוקס שרץ על המתג).

מבחינת אחסון: ישנו תהליך יחסית די חדש שיכנס לאט דרך יצרני ה-SSD והוא "העפה" של מערכת הבקר מה-SSD כך שמערכת הוירטואליזציה תחליט איך לנהל את ה-SSD, איך לבצע Garbage Collection לפי העומסים במכונה, לפי המכונות הוירטואליות שירוצו ועוד. אינטל גם תוציא את ה-Optane DC Persistent Memory – מקלות אחסון שיושבים היכן שמקלות הזכרון יושבים, מכילים הרבה יותר אחסון ממקלות זכרון ECC רגילים ועם ביצועים קרובים לביצועי זכרון. תמיכה לכך ב-OpenStack תהיה קיימת בקרוב (להלן השקפים), רק שמחכים למעבדים ושרתים מבוססי Cannon Lake SP.
עוד תחום אחסון שיקבל Boost רציני בוירטואליזציה הוא NVMEoF שיתן Latency מאוד נמוך.

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

אם יש לכם שאלות לגבי המוצרים, אתם מוזמנים ליצור קשר.

על בחירת מחשב תעשייתי/מוקשח

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

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

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

ברכבים לדוגמא, כשהחלק יושב בסביבת המנוע, פתרון קירור רציני הוא חובה. קחו לדוגמא את הלוח של nVidia Drive PX2. רואים את 4 המעבדים? תנסו להפעיל את המערכת ללא איוורור ותראו את המערכת נכבית תוך שניות ספורות. במקרה של הלוח הזה, הפתרון קירור יחד עם הלוח נראה כך (התמונה עם לוח מהגירסה הקודמת):

  • סוג מעבד: במקרים של מחשבים תעשייתיים, את סוג המעבד יש לקבוע בהתאם לעבודה שאותו מחשב אמור לבצע. אין שום סיבה לרכוש i7 אם המחשב מבצע עבודה שמעבד עם ביצועים נמוכים יותר יוכל לעשות מבלי לפגוע בביצועים. בניגוד לדסקטופ, כאן בהחלט מומלץ גם לשקול מעבדים מבוססי ARM, מעבדי ATOM של אינטל, או EPYC Embedded של AMD.
  • חיבור ציוד עם USB: חיבור ציודים עם USB הוא בעייתי. בניגוד לחיבורים כמו VGA או DVI או Display Port שכוללים ברגים או מנגנון לנעילת החיבור, USB הוא לא החיבור הכי יציב, ולכן אם חייבים לחבר ציוד בעזרת USB, יש צורך לדאוג לפתרון בולם זעזועים מחוץ למחשב. ללא פתרון לזעזועים, המערכת תדווח בזמן עבודה על חיבור/ניתוק ציודים באופן תכוף.
  • אמצעי אחסון: לא מומלץ להשתמש בדיסקים מכניים. הדיסקים המכניים כוללים בתוכם בולם זעזועים, אבל אם הפתרון מצריך נסיעות בדרכים או עמידה בתנאים קיצוניים הכוללים תנועה, פתרון הבולם זעזועים הפנימי לא תמיד יפעל טוב (הבולם זעזועים מתאים למקרים של נפילה פיזית פתאומית אחת לזמן רב, לא כל מספר דקות). בעבר ההמלצה היתה להשתמש ב-SATADOM (שהוא בעצם Flash Disk שנכנס ישירות לתוך חיבור SATA ומצריך חיבור חשמל על לוח האם), אולם כיום מומלץ להשתמש ב-SSD בחיבור M.2 הכולל 2 ברגים לחיזוק החיבור. M.2 הרבה יותר אמין ועומד בכבוד גם בזעזועים על טרקטורים.
  • שימוש בכרטיסי PCIe: אין בעיה להכניס כרטיסי PCIe (יש מעט דגמים של מחשבים תעשייתיים המאפשרים הכנסת כרטיסי PCIe) בפתרונות הללו, אולם מומלץ אם אפשר – לחפש כרטיסי Mini PCIe עם אותה פונקציונאליות. כמו ב-M.2, הפתרון מוברג ומוחזק בצורה יותר טובה.
  • שימוש במאווררים: רוב המחשבים התעשייתיים הם מחשבים שקטים, ודרישת השקט מגיעה במקרים רבים מהלקוחות וכך יצרני אותם מחשבים עושים הכל על מנת שהמחשב יהיה שקט. יחד עם זאת, יש לעיתים צורך (בהתאם לתצורה) להחליף את המאווררים הכלולים במאווררים אחרים. הדבר האחרון שמומלץ הוא להשתמש במאווררים רגילים שעולים 30 שקל. יש צורך לבדוק את כמות ה-RPM וה-CFM ואז לרכוש את המאווררים המתאימים או לבקש מהיצרן מאווררים אחרים או המלצות על מאווררים אחרים. מאווררים שאינם תואמים עלולים לגרום לנזק למחשב.

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

התקציב השנתי ורכישת ציוד

יש חברות שכבר הספיקו לתכנן את תקציב ה-IT לשנה הקרובה, יש כאלו שעדיין יושבים על המספרים. כמובן שאצל כל חברה הדברים שונים, יהיו כאלו שירצו בשנה הקרובה להחליף שרתים, להחליף סטורג', אולי לרכוש PC חדשים, לשדרג ל-SSD, לעבור לתקשורת פנימית יותר מהירה (10/40/50/100 ג'יגהביט), וכמובן שיש את כל עניין הפלטפורמות: לעבור לקונטיינרים, הטמעת CI/CD, להתחיל לעבוד בתצורת AGILE, לשכור אנשים/חברות ללמד את העובדים טכנולוגיות חדשות וכו'.

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

נתחיל בסטורג' SDS.

את עולם הסטורג' לקצה התחתון עד הבינוני ניתן לחלק ל-2: סטורג' קנייני (כזה שמגיע עם "ראש", מדפים), וסטורג' מבוסס תוכנה (SDS – כלומר Software Defined Storage). אם תשאלו את אנשי השיווק של הסטורג' הקנייני, תקבלו הילולים מכאן עד הודעה חדשה כמה הוא יציב, וכמה "לא כדאי" לרכוש SDS. המצב במציאות – די הפוך. בואו נאמר שאתם הולכים להוציא $50,000 על פתרון סטורג' ואתם מבקשים מכל העולם והחתול שלו הצעות מחיר לסטורג'. רוב ההצעות שתקבלו – הם SDS, גם אם הם לא יקראו כך בכותרת.

באופן עקרוני, סטורג' SDS מבוסס בעצם על חלקים COTS (כלומר Common Off The Shelf), כלומר שרת SDS אינו שונה מהותית מכל שרת שיש לכם בחדר/חוות שרתים שלכם. יש בו זכרון, מעבדים, בקר דיסקים, דיסקים קשיחים, וכרטיסי רשת. 2 הדברים ששונים בין סטורג' SDS לשרת רגיל הם בקר דיסקים (בחלק מהמקרים יש SAS Expander ו/או בקר RAID יותר יוקרתי הכולל תמיכה ל-SSD Caching) וכרטיסי רשת לחיבור מהיר (10/40/50 ג'יגה). הדבר העיקרי שהופך את השרת ל-סטורג', זו בעצם התוכנה שרצה עליו.

אחת השאלות הראשונות שאני נשאל לגבי פתרונות כאלו זה "האם יש תמיכה מהיצרן שרתים"? והתשובה בדרך כלל היא "כן", כלומר אם תבקשו מ-HP או DELL או LENOVO פתרון תוכנה של סטורג', הם ישמחו למכור לכם את התוכנה, עם או בלי שרת שלהם. היתרון הגדול בשיטה זו הוא שאם ציוד כלשהו בשרת נדפק, אתה נמצא תחת אחריות מלאה וטכנאי יגיע אליך תוך 4 שעות או ביום העסקים הבא (בהתאם לחוזה שרות שחתמת), ואם יש לך שאלות או תקלות עם תוכנת הסטורג', תוכל לקבל תמיכה מהיצרן שרתים או מיצרן התוכנה, כך שאתה מכוסה מכל צד. אפשר להשוות זאת לרכישת ברזלים + רשיונות של vSphere – אני לא מכיר מקרים שלקוח נשאר ללא מענה לתקלות אם הוא תחת אחריות של יצרן השרת והתוכנה.

מבחינת ביצועים – אחת השאלות שאני תמיד מקבל מצד כל מיני חברות שמתעניינות בסטורג' זה משהו בסגנון "אני צריך פתרון סטורג' עם X טרהבייט ועם כמות Y של IOPS רציפים". עם SDS אין בכלל את העניין הזה. רוצה X טרהבייט? תכניס כך וכך דיסקים ואם נגמר המקום, חבר JBOD בחיבור SAS-HD2. רוצה IOPS? תגדיל כמות זכרון ותוודא שיש לך SSD מהירים כמו P4800X או 905P של אינטל או Z-SSD של סמסונג (זה במקרה הקיצוני שצריכים IOPS גבוה בכל מחיר) או כל SSD שהוא Mixed והוא נמכר לך ע"י יצרן השרתים שלך. סמסונג, אינטל, מיקרון, טושיבה – כולם מייצרים כאלו.

שרידות – אחת הבעיות הקשורות במחיר – היא שרידות High Availability בסטורג' קנייני, כלומר כשצריכים "2 ראשים" לקבל שרידות. המחיר של ראש שני – יקר מאוד! לעומת זאת, בסטורג' SDS, מדובר בעצם על עוד שרת, רכישת JBOD לדיסקים וחיבור ה-JBOD ל-2 השרתים והפעלת פונקציית HA בתוכנת הסטורג'.

מה עם ביצועי רשת ב-SDS? שרת חזק יחיד עם כרטיסי רשת במהירות גבוהה, יתן ביצועים גבוהים ומענה לחיבור כל התשתית שצריך. מנסיון אישי על שרתים שהקמתי, הגעתי ל-250 ג'יגהביט תוך חיבור 150 שרתים, חלקם ב-NFS, חלקם ב-iSCSI וחלקם ב-CIFS (הייתי יכול להגיע ליותר אם היתה לי מכונה יותר חזקה ויותר כרטיסי רשת), כך שפתרון SDS יכול לעמוד בעומסים בלי שום בעיה.

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

לסיכום: פתרון סטורג' SDS נותן לך הרבה יותר ואתה עדיין מקבל תמיכה מיצרן החומרה שאתה רוכש ממנו את הברזלים – אם זו נקודה קריטית עבורך. אפשר כמובן להקים מערכות כמו FreeNAS או ZFS על לינוקס (או על אחת מגרסאות הקוד פתוח של Solaris) אם אתה לא מעוניין לשלם על התוכנה ואתה מעדיף לסגור עם אינטגרטור חיצוני שיעשה את העבודה ויתן לך את התמיכה הרצויה. סטורג' קנייני בדרך כלל יעלה לך הרבה יותר בהשוואה לרכישת שרת כלשהו שיארח את פתרון האחסון ואתה תמיד יכול לגדול עם פתרון הסטורג' בהתאם לצרכים שלך מבלי לשלם סכומי עתק על כל שדרוג בהשוואה לסטורג' קנייני.

עוד על SDS כתבתי כאן וכאן.

אחסון נתונים – לאן אנחנו מתקדמים?

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

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

נפתח בכותרת ראשית: מלחמה. יצרני פתרונות SSD כמו אינטל, טושיבה, סמסונג, מיקרון ואחרים מתחילים להוציא דיסקים SSD מבוססי QLC NAND Flash (כלומר בכל תא ניתן יהיה לאחסן 4 בייטים של מידע) בכדי להתחרות ביצרני הדיסקים הקשיחים המכניים. היתרונות של SSD QLC על פני דיסקים מכניים:

  • ניתן יהיה לרכוש SSD בגדלים של עד 32 טרהבייט (פר דיסק) – בהשוואה לעד 14 טרהבייט דיסק מכני.
  • מהירות הכתיבה תהיה יותר מהירה ממהירות הכתיבה לדיסק מכני, אם כי לא בהבדל כה משמעותי כמו SSD MLC – זה יהיה בסביבות ה-800-1000 מגהבייט לשניה. מהירות הקריאה לעומת זאת תהיה בערך כמו SSD MLC – בערך 2 ג'יגהבייט לשניה.
  • טיפול בשגיאות יהיה הרבה יותר חכם בהשוואה לדיסקים קשיחים מכניים – והטיפול יהיה פנימי (עם Garbage Collection ו-TRIM).
  • הקץ לחיבורי SATA ו-SAS2/SAS3 – כל החברות מעוניינות להעיף זאת (אוקיי, חוץ מטושיבה) לטובת NVME.

הדיסקים הללו יצאו במהלך השנה הקרובה. שימו לב: במקרים מסויימים, גם אם יש לכם תמיכת NVME בשרת, לא בטוח שדיסקים כאלו יהיה ניתן להכניס אותם הואיל והעובי שלהם הוא 15 מ"מ (בניגוד לרוב הדיסקים SSD שהם בין 5 ל-7 מ"מ).

רוב האנשים שאומר להם את המילים "SSD עם QLC Flash" לא ממש יבינו את ההבדלים בין SSD רגיל ל-SSD QLC ולכן אני מציע להציץ בלינק הבא. כפי שתוכלו להבין מקריאת המאמר שם – אלו דיסקים שלא מיועדים להירכש במקום דיסקים SSD שנמכרים כיום, אלא מיועדים להחליף את רכישת הדיסקים המכניים.

מ-QLC נעבור לטכנולוגיה שאינטל כה גאה בה – ה-3D Xpoint. טכנולוגיה זו, למי שאינו מכיר – היא טכנולוגיית אכסון על שבבים, אך לא מדובר ב-NAND Flash אלא על פתרון קנייני של אינטל ומיקרון. SSD בטכנולוגיות כאלו יחזיק הרבה יותר זמן, מהירות הכתיבה והקריאה שלו שווה פחות או יותר למתחרים, אולם הטכנולוגיה "עוקפת" את המתחרים בכל מה שקשור ל-Latency או בשימוש בחלק מה-SSD כ-SWAP והוא מאוד מתאים לדברים כמו SQL אם אנחנו מעוניינים להצמיד SSD כזה למכונת VM (או להריץ על "הברזל").

למרות שאינטל מהללת את הטכנולוגיה – ברוב המקרים אצל רוב החברות, לא יהיה לה ממש שימוש, הואיל ושימוש ב-SSD כזה על פתרון וירטואליזציה כמו vSphere לא יתן יתרון גדול על מתחרים אחרים כמו סמסונג, מיקרון ואחרים (ב-SSD ל-Enterprise). בנוסף, אינטל מייצרת אותם בגודל די קטן: 280, 375, ו-750 ג'יגהבייט (שוב, בגרסאות Enterprise) במחיר הרבה יותר גבוה מהמתחרים, כך שאם רוצים להשתמש ב-SSD כאלו – מומלץ לחשוב ולקחת יעוץ. מצד שני, אם אתם בונים פתרון NAS, דגם 905P לדוגמא יכול לתת פתרון Cache הרבה יותר טוב מאחרים (שימו לב, שבשביל להשתמש ב-SSD כזה, צריך מכונה די חדשה, מהשנתיים האחרונות).

טכנולוגיה נוספת שתעניין חברות שמשתמשות ב-SQL ושצריכים ביצועי Read רצחניים, היא טכנולוגיית ה-Z-SSD של סמסונג. ה-Z-SSD עוקף בביצועים את ה-3D Xpoint של אינטל, אבל הוא הרבה יותר איטי בכתיבה.

מכאן נעבור לפתרונות אחסון קנייניים. ברוב המקרים בקצה הנמוך עד בינוני (תקציב של 5-6 ספרות בדולרים) הטכנולוגיות הם פחות או יותר אותן טכנולוגיות, רק שכל חברה נותנת שמות אחרים (די מזכיר מה שקורה בתחום השרתים) ואחת השגיאות שרבים נופלים אליה – היא המושג "AFA" (או All Flash Array). אפשר להשוות את זה למושג שיגיע מאיש שיווק של רכבים – "מכונית מפוארת". זה שפתרון Storage הוא All Flash יכול להטעות, בגלל שכל SSD יש לו מגבלות – בכמות כתיבה רנדומלית או Sequencial, חלקם הוא Mixed Intense אבל ברוב המקרים בהצעה הראשונה שתקבל ה-SSD הוא Read Intense, מה שיאיט את הביצועים בצורה ניכרת בעבודות דיסק כבדות.

בשנה הקרובה יהיו יותר ויותר הצעות AFA שמבוססים על דיסקים SSD TLC (ולא MLC שהוא הרבה יותר מהיר. ה-TLC יושב "באמצע" בין ה-MLC ל-QLC) ושיהיו Read Intense. בהצעות היותר גבוהות, סביר להניח שנראה לקראת סוף שנה הבאה פתרונות Storage גדולים יותר מבוססי SSD QLC – כאשר חלק מה-SSD יהיו TLC כדי "להחביא" ביצועי כתיבה איטיים. אלו שרוצים להקים פתרונות VDI גדולים – פתרונות Storage כאלו יאיטו ביצועים במקרים מסויימים (במיוחד אם מרימים כל דסקטופ כ-VM ולא כ-Session RDP לדוגמא).

עוד תחום שיקבל תאוצה בשנה הקרובה הוא ה-NVMEoF שעליו כתבתי בעבר. הפתרונות הללו יקרים (7 ספרות בדולרים) והם הרבה יותר מורכבים מפתרונות Storage קודמים. תחום נוסף שיקבל דחיפה ויכול לעניין את אלו שמחפשים פתרון Storage עם Scale Out – הם פתרונות קנייניים של Scale Out מ-EMC, NetApp, ואחרים אך לעניות דעתי אין להם הצדקת רכישה – יש מספר פתרונות Scale Out Storage שיכולים לרוץ על ה-Nodes עצמם מבלי לרכוש עוד Storage.

עוד פתרונות מעניינים שיגיעו לשוק (אבל אני מאמין שלא יכנסו לשוק הישראלי האולטרא-שמרן) הם פתרונות JBOF – מכונות שמזכירות JBOD אך עם SSD במקום דיסקים מכניים, שמחברים כל מכונה למספר שרתים עם כרטיס HBA וב-JBOF מגדירים כמות דיסקים שיוקצו פר שרת. יש גם פתרונות של מכונות שיכולות לקבל 45-60 דיסקים מכניים בגודל 3.5 אינטש וכוללות מעבד, זכרון וכו' ויכולות לשמש כפתרון Storage (אולם יש צורך בשדרוג תשתית הרשת ל-40-50 ג'יגהביט).

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

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

על PLX, שרתים מיוחדים ומחשבים תעשייתיים

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

כיום יש בחלק קטן מהמקרים דרישות לשרתים שונים. אחד הפופולריים לדוגמא הוא שרת שיכול לקבל כמה שיותר GPU לצרכי Deep Learning או AI. ברוב השרתים מהיצרנים הידועים ניתן להכניס בין 1 ל-4 כרטיסי GPU. מדוע זה נעצר ב-4 GPU? הרי תמיד אפשר לבנות שרת בגודל 3U ולדחוף בו עד 8 GPU בקלות (ואם מתאמצים – ויש כמה דגמים כאלו בשוק – גם 10 GPU). הסיבה לכך (לדעתי) היא המחשבה של רוב היצרנים שאם אתה רוצה לדחוף 8 כרטיסי GPU – עדיף שתקנה 2 שרתים שבכל אחד מהם יהיה 4 כרטיסי GPU. השיטה הזו עובדת מעולה על רוב החברות, אבל ממש לא עובדת על חברות ענן.

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

תכירו את השרת הבא: 3U8G-C612 מחברת Asrock Rack (לחצו להגדלה):

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

מי שיציץ במפרט הכללי של מעבדי Xeon SP, יגלה שיש לנו בכל מעבד עד 48 נתיבי PCIe, כלומר יש לנו סה"כ (ברוטו) 96 נתיבים. לעומת זאת יש לנו 8 כרטיסי GPU שכל אחד מהם משתמש ב-16 נתיבי PCIe. חישוב פשוט של 8 כפול 16 שווה 128, אבל אין לנו 128 נתיבים, שלא לדבר על כך שכל פיפס דורש מס' נתיבי PCIe: ה-Chipset דורש 4, כרטיס רשת 10 ג'יגה דורש בממוצע 8, בקר ה-RAID דורש גם 8, ויש עוד כמה ציודים שגם הם דורשים מס' נתיבי PCIe.

אז איך ניתן לכולם וגם נספק 128 נתיבי PCIe לכל הכרטיסים?

לשם כך ישנה טכנולוגיה שנקראת PCIe Switching או כפי שהיא יותר מוכרת בתעשיה: PLX.

מה שה-PLX עושה בעצם, הוא יוצר מעין "מתג" בין מספר תושבות PCIe, ובכל פעם הוא מעביר למערכת מידע מכרטיס אחר. כך לדוגמא ישנם דגמים שיודעים לעשות סימולציה של 2 או 4 תושבות PCIe X16 ואותו PLX ממתג בין ארבעתם ומעביר את כל הנתונים הלוך וחזור בין המעבד לכרטיסים, כל זאת בשעה שהמערכת עצמה מודעת לכך שיש 4 כרטיסים (נניח) אבל המעבד מקבל כל פעם נתונים מכרטיס אחד. לשיטה הזו יש יתרון עצום בכך שאפשר להכניס הרבה יותר ציוד במחשב, אם כי המחיר שלה היא איבד מועט של מהירות (בסביבות ה-50-80 ננושניות).

שיטת ה-PCI Switching גם עובדת חיצונית. נניח ויש לנו מערכת vSphere עם מספר שרתים ואנחנו צריכים לתת למספר מכונות VM כרטיס GPU יעודי. אם נתקין GPU בשרת פיזי שמריץ vSphere לא תהיה לנו אפשרות לעשות Migration של המכונה לשרת אחר או Fault Tolerance. עם PLX לעומת זאת, אנחנו יכולים להקים מכונה כמו בתמונה לעיל, ולמפות בעזרת ציוד PCI Switching (שיושב "באמצע" בין השרת לשרתי ה-vSphere – כולל כבלים כמו SAS HD בין הציודים לשרתים) כרטיס ספציפי ל-VM ואנחנו יכולים להעביר ב-Live את הציוד בין מכונות ה-VM. (אגב, לאלו שחושבים לאמץ את הטכנולוגיה – היא יקרה, מאוד!)

כך, בקרוב, השרתים החדשים מבית DELL, Cisco ו-HPE יאפשרו ללקוחות להכניס בכל תושבות הדיסקים – SSD NVME. כל NVME דורש 4 נתיבי PCIe כך שאם אנחנו יכולים להכניס 24 דיסקים SSD NVME, נצטרך 96 נתיבים שאותם ב"טבעי" אין לנו ולכן ב-Backplane של השרת יהיו 2 שבבי PLX שישתמשו ב-32 נתיבי PCIe ואת זה אין שום בעיה ל-PCIe לתת. אגב, אינטל מאפשרת עד 96 נתיבי PCIe ו-AMD נותנת .. 128 נתיבים. יום אחד אולי אצליח להבין מדוע אינטל כה "חוסכת" נתיבי PCIe… אגב: שרתים מבית SuperMicro, Tyan, ASRock Rack כוללים כבר פתרון כזה מזה שנתיים וחצי…

משרתים נעבור למחשבים תעשיתיים. אלו מחשבים שאמורים לעמוד בתנאים קיצוניים של רעידות, חום קיצוני (עד 60 מעלות בזמן עבודה). בחלק מהמקרים המחשב, כשפותחים אותו, נראה כמו PC רגיל, ובחלק מהמקרים המחשב מורכב מלוח אם שהוא כמעט ריק ויש בו תושבת אחת ארוכה ועוד תושבות PCIe X16 ו-PCIe X8. המחשב עצמו יושב ב-90 מעלות אנכית בתושבת הארוכה (שמזכירה תושבת Riser בשרתים) והציודים מתחברים לאותו לוח אם. אחת הטעויות הנפוצות שיבואנים לא מודעים (וחלק מחברות האינטגרציה לא מודעות) היא שפתרון שאינו כולל PLX הוא מוגבל. ברוב המקרים במחשבים תעשייתיים יש מעבד i5 או i7 או Xeon E3 מכילים כמות קטנה של נתיבי PCIe! כך לדוגמא אם מכניסים GPU אז הוא משתמש ב-16 נתיבים ומעבד כמו Xeon E3-1585 v5 מגיע עם .. 16 נתיבים בלבד. אם לא מכניסים GPU, אז אנחנו יכולים להכניס 2 כרטיסים שמשתמשים כל אחד מהם ב-8 נתיבים או כרטיס של 8 נתיבים וכרטיס של 4 נתיבי PCIe, כך שאם בונים מחשב תעשייתי עם ציוד רב שצריך להתחבר אליו (GPU, בקרים – לא ב-RS232, חיבורי USB, חיבורים קנייניים וכו') אז חובה לחפש פתרון שכולל PCIe Switching.

לסיכום: ישנם תצורות נוספות של שרתים שיכולים לסייע לנו בכל מיני דרכים, שיצרני ציוד רגילים לא תמיד מוכרים. אם אנחנו רוכשים ציוד שאנחנו צריכים להכניס אליו ציודים רבים נוספים, חשוב לבדוק אם יש בו פתרון PCIe Switching, אחרת המחשב אפילו לא יפעל. הטכנולוגיה הזו  גם יכולה לסייע כשיש לנו צורך לחבר ציודים מסויימים כמו SSD NVME או GPU ממכונה יעודית אחת לשרתים אחרים מבלי שנצטרך להחליף שרתים. כדאי להתייעץ ולבדוק מה הצרכים והאם פתרונות כאלו יכולים לסייע לכם.

קונטיינרים – הפתרונות שקיימים ומה כדאי לבדוק

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

(הערה: מכיוון שמערכות כמו OpenShift, IBM Private Cloud, CAAS, Rancher ועוד מבוססים על Kubernetes ועל זה הם הוסיפו דברים אחרים, אתייחס בפוסט זה ל-Kubernetes או בשמו המקוצר הידוע – K8S).

אחד הדברים הראשונים שמנמר"ים ואנשי IT רבים עדיין לא מבינים, זה את הבסיס, שקונטיינרים אינם מכונות וירטואליות. קונטיינר שקם משתמש ב-Images והוא לא מיועד לאחסן נתונים באופן פרמננטי כמו במכונה וירטואלית, לשם אחסון נתונים יש Volumes שעליהם אתייחס בפוסט זה בהמשך. בקונטיינר אין מערכת הפעלה מלאה, אלא מה שהותקן בעת הקמת ה-Image וברוב מוחלט של המקרים מדובר במשהו מזערי שאמור לספק את דרישות האפליקציה שתרוץ בקונטיינר. בנוסף, קונטיינר מאובטח לא אמור להריץ שרותים כמשתמש root אלא כמשתמש רגיל (ללא הרשאות root/sudo) ולבסוף – קונטיינרים לא אמורים להריץ מספר אפליקציות, אלא אפליקציה אחת בכל קונטיינר/POD ו"לדבר" עם POD/קונטיינרים נוספים שמריצים אפליקציות אחרות, בשביל זה יש לנו TCP/IP ובשביל זה יש שרות DNS פנימי שרץ על K8S שיודע לתקשר בין החלקים והשרותים השונים.

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

הרעיון של Volume הוא שונה מכל מה שאנחנו מכירים וקשור לאחסון. במערכות וירטואליזציה לדוגמא, אנחנו מגדירים "אחסון" (כמו Datastore ב-VMWare) שיש לו Backing שיכול להיות iSCSI, NFS ובמקרה של Hyper-V זה יכול להיות CIFS. בפתרון הסטורג' שלנו אנחנו מקימים LUN או מחיצה כלשהו שייוצאו כ-NFS/CIFS לפתרון הוירטואליזציה (לא ניכנס עכשיו לכל עניין שרידות, Multipath ושאר ירקות) ועל המקום הזה פתרון הוירטואליזציה שלנו יוצר/משתמש בדיסקים וירטואליים כדי להריץ את מערכת ההפעלה ולאחסן את המידע שלנו.

ב-Volumes לעומת זאת, הדברים שונים לחלוטין. אנחנו עדיין צריכים את ה-Backing (רק שיש הרבה יותר אופציות מאשר iSCSI, NFS – יש 26 אופציות, ו-OpenShift מוסיף עוד כמה) מהסטורג' כדי לאחסן את ה-Volumes, אבל כשאנחנו באים ליצור/להשתמש ב-Volume, אנחנו צריכים קודם כל להגדיר Persistence Volume, להגדיר מה הגודל של אותו Persistence Volume, מה יקרה ל-DATA באותו Volume אחרי שהקונטיינר מת, ומה ההרשאות שיהיה לאותו Persistence Volume מבחינת קריאה/כתיבה. בהגדרות הקונטיינר עצמו אנחנו נשתמש ב-Persistence Volume Claim (או PVC בקיצור) כדי להתחבר לאותו Persistence Volume (או PV בקיצור) ולהגדיר גם Path להיכן להתחבר. ה-PV בדרך כלל מוגדר ברמה של מגהבייט או ג'יגהבייט.

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

לכן, אם אנחנו רוצים להקים פלטפורמת K8S, אנחנו קודם כל צריכים להחליט, האם אנחנו מקימים את זה "על הברזל" או על מכונות וירטואליות? אם על מכונות וירטואליות והפתרון מבוסס vSphere, אז אנחנו יכולים להסתכל על VMware Kubernetes Engine™ VKE לדוגמא (ואפשר במקביל להציץ גם ב-PKS של VMWare/Pivotal). חובבי מיקרוסופט? בחודש הבא יוצא Windows Server 2019 שכולל את Kubernetes בתוכו. אם לעומת זאת אנחנו מעדיפים פתרונות כמו OpenShift, CAAS ואחרים, נצטרך להקים מכונות לינוקס ועליהן להריץ את אותם פתרונות. לא אכנס כאן ליתרונות וחסרונות של פתרונות "טבעיים" מול הקמת פתרונות על מכונות וירטואליות – אבל אחת הנקודות שחשוב לזכור, זה שפתרונות שמקימים על מכונות וירטואליות – זה שקל להזיז את הפתרון לעננים או למקומות אחרים במקום להיות "נעול" על פתרון שיצרני ה-OS ווירטואליזציה מציעים. חוץ מזה קיים גם עניין המחיר.

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

  • תקשורת 10 ג'יגהביט. שוב, אין בקונטיינרים Live Migration שמשתנה בו כמה קבצי קונפיגורציה וה-VM "קופץ" למכונה אחרת, יש הקמה מחדש של קונטיינרים ולמרות שה-Image נמצא בסטורג', בחלק מהמקרים הוא מועתק לדיסקים מקומיים ולכן פתרון תקשורת 1 ג'יגה יאיט הכל.
  • סטורג' עם שרידות – יש לא מעט חברות שבטוחות שזה שהדיסקים מחוברים בבקר RAID כפול יש אחלה שרידות. לדעתי – עדיף שרידות שאם "ראש" נופל, "ראש" אחר לוקח מיידית פיקוד, אבל שוב – הכל תלוי בתקציב וכמה הפלפורמה תהיה פרודקשן.
  • דיסקים מקומיים – מאוד חשוב. ה-Images ימצאו בדרך כלל ב-Container Registry, אבל הם יועתקו לדיסקים מקומיים ברוב המקרים ועם הדיסקים מקומיים איטיים, זמן הקמת הקונטיינר יתארך (ותהיו בטוחים שיהיו ערימות קונטיינרים, חוץ מהקונטיינרים שלכם, תלוי בפלטפורמה). דיסקים מכניים זה פתרון לא רע אבל אם רוצים ביצועים – תחשבו על SSD Mixed Intense.
  • אם המערכת הולכת להיות חשופה החוצה לאינטרנט (הכוונה השרותים כמו WEB חשופים לאינטרנט) – אז אבטחה רצינית היא חשובה: לא להקים Images כ-root, תקשורת ו-Namespace מופרדים ועוד דברים חשובים שמצריכים הכרה עמוקה עם פלטפורמת הקונטיינרים. תזכרו: קונטיינר שרץ כ-root וחשוף לרשת – יכול לתת לפורץ הרבה יותר ממה שאתם חושבים.

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