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

תכירו את Open Shift

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

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

אם נסתכל בתשתית ה-Corporate במחלקות הפיתוח לדוגמא, נמצא במקרים שרת SCM כמו GIT (או SVN, מרקיוריאל ואפילו רחמנא ליצלן .. CVS וכו'), אלו שהחלו להיכנס לעולם ה-CI/CD הקימו בוודאי שרת Jenkins ואולי כמה Slaves, אם החברה מפתחת ב-JAVA אז יש בוודאי איזה שרת Nexus, בנוסף ישנם מספר שרתים שמריצים אפליקציות Web, שרת Apache או NGINX (או IIS). הכל רץ טוב ויפה (כשזה רץ…), אבל כשצריך להגדיל את התשתית, מישהו יצטרך לחפש כדורים נגד כאבי ראש עם כל הבירוקרטיה שיש ב-Corporate.

עם Open Shift הדברים שונים. Open Shift (שאגב, היא מערכת PAAS לכל דבר ועניין!) משתמשת בקונטיינרים כדי להריץ את מה שאתה צריך כשכל דבר רץ בקונטיינר נפרד. יש לך אפליקציה ב-PHP שצריכה לכתוב ל-MySQL? כמה קליקים ויש לך 2 קונטיינרים, תוסיף Route ושתיהם מדברים אחד עם השני, שתיהם לא צריכים לשם טסטים לדוגמא להיות עם יותר מ-1 ג'יגה זכרון (סה"כ ל-2 הקונטיינרים) ושתיהם יחד לא יצטרכו יותר מליבה אחת של המעבד בשרת וזה ירוץ מעולה תחת POD יחיד (POD זו ההגדרה של מספר קונטיינרים שרצים בקבוצה). רוצים לגדול עם האפליקציית PHP? שתי קליקים עם העכבר בממשק ה-WEB ותוך שניות ספורות יש עוד קונטיינרים שמוכנים לקבל גולשים, ולא – אתה לא צריך לשבור את הראש על Routing, על Load Balancing וכו' – בתוך Open Shift יש את Kubernetes שעושה את העבודה לבד ברקע. כך גם אם קונטיינר מסוים יפול, המערכת תרים מיידית קונטיינר נוסף תוך שניות ספורות (במקום לחכות כמה דקות עד שיקום VM עם כל התהליכים שהוא צריך לאתחל) והמערכת יכולה להמשיך לתת שרות.

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

אז איך בעצם זה עובד? הנה תהליך עבודה פשוט לדוגמא:

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

צריך להריץ Deployment בשיטות כמו Blue-Green או AB? שתי השיטות נתמכות.

אחרי שהקוד מוכן, נרצה להריץ אותו בפרודקשן. מה אז?

כאן מגיע יתרון גדול של Open Shift. לא משנה איזו תשתית וירטואליזציה יש לך, תהיה הפופולרית ביותר או אזוטרית ביותר, בין אם זה מקומית או בענן פרטי או ציבורי – Open Shift תרוץ. כל מה שאתה צריך זה מספר מכונות VM (או ברזלים פיזיים) ו-Subnet כתובות פרטי וציבורי. מה שנשאר לך לעשות זה להקים Open Shift במכונה אחת (או כאשכול), "לשדך" את שאר מכונות ה-VM שיריצו מערכת Atomic Host (זו גירסת לינוקס מאוד מצומצמת שנועדה להריץ קונטיינרים) ומשם לקמפל את הגירסה היציבה ולהריץ אותה עם רפליקציה. מערכת ה-Kubernetes הפנימית תדע להפיץ את הקונטיינרים בין מכונות ה-VM (וכן, יש גם Auto Scaling ו-HA) ואם אתם מריצים את זה בענן, שרות ה-Load Balancer ידע להעביר את התעבורה ל-IP חיצוני (לא צריך ציוד יעודי יותר בתוך החברה שיעשה LB). קונטיינר נופל? VM נופל? המערכת תדע להתאושש לבד.

ומה עם אבטחת מידע? כאן דווקא החיים יותר קלים. עם VM כשיש אבטחת מידע, אתה צריך לעבור מכונה מכונה ולהתקין את עדכוני האבטחה. תארו לכם שיש לכם מאות (או אלפי) VM ואתם יכולים לדמיין לבד את הכאב ראש הכרוך בכך. עם קונטיינרים לעומת זאת, בין אם יש חור אבטחה בקוד שלכם או באחת מהחבילות שהקונטיינר משתמש, כל מה שתצטרכו לעשות זה Rebuild לקונטיינר ואם יש לכם רפליקציה של הקונטיינר, המערכת תוריד כל פעם קונטיינר ותשאיר את השאר רצים (תוך עדכון ה-Load Balancer) כך שמבחינת הגולשים המערכת תהיה זמינה וכך כל הקונטיינרים יוחלפו בגרסאות מעודכנות (בזמן ה-Build המערכת מורידה את הגרסאות של החלקים השונים עם התיקוני אבטחה אוטומטית). כך שכשזה מגיע לבעיית אבטחה, כל התהליך לוקח דקות ולא שעות או ימים!

עד כה כל הטכנולוגיה שדיברתי עליה מדברת על הרצת דברים שכתובים ללינוקס, אבל מה עם אלו שכותבים ב-DotNet? ובכן, מאז שמיקרוסופט ורד-האט חתמו על הסכמי שת"פ, האהבה פורחת ביניהם וכיום ניתן לקחת אפליקציות שכתובות ב- #C עם DotNet ולבנות אותן על לינוקס ולהרים קונטיינר כזה. בשלב זה טכנולוגיות הקונטיינרים של מיקרוסופט עדיין לא עובדת ישירות טוב עם Open Shift אבל אפשר לבנות להריץ אפליקציות כפי שציינתי. אגב, ניתן לשלוט על Open Shift בעזרת ה-CLI גם מתוך Windows (כל מה שצריך זה להתקין Ruby, Git ולהריץ מספר קטן של פקודות).

להלן הדגמה של ASP שרץ עם Open Shift:

הוידאו הבא ידגים איך מקימים מערכת CI/CD מלאה יחד עם Open Shift:

ומה לגבי הטמעת מערכת כזו בחברה?

גם כאן, כמו ב-CloudForms/ManageIQ ישנם מספר גרסאות:

  • יש גירסה שרצה על הענן של רד-האט ומשלמים Pay As you Go, בין אם ב-VM או בברזלים נפרדים.
  • יש גירסת קוד פתוח (גירסה שמהנדסי רד-האט מפתחים, יכולים לצוץ באגים!) שנקראת Open Shift Origin.
  • וישנה גירסת ה-Open Shift Enterprise בתשלום עם תמיכה לשנה או 3 שנים במסלולים שונים.

מבחינת הטמעה וקאסטומיזציה – זה מאוד תלוי בחברה ובדרישות. הקוד של Open Shift כתוב ב-GO.

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

לסיכום: קונטיינרים יכולים לחסוך הקמת VM מרובים ותחזוקתם. מערכת Open Shift יכולה להקל בצורה רצינית על כל תהליך הקמת סביבות הרצת טסטים, פרודקשן, ועוד. בכל מה שקשור למעבר לענן, Open Shift מקלה על בחירת ספקי ענן ובמקביל מגדילה את המבחר ספקים (כך לדוגמא אפשר להשתמש בספק כמו Digital Ocean עם מכונות במחירים זולים בהרבה מספקי ענן ציבורי ובמקרים רבים החבילה תכלול מספיק תעבורה כך שלא תצטרכו לשלם על כך בנוסף!)

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

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

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

על דיסקים SSD בתצורת NVMe/PCIe

בשנתיים האחרונות נכנסה טכנולוגיית דיסקים (SSD) חדשה לשוק – טכנולוגיית ה-NVMe SSD (או PCI SSD – זה אותו דבר). רבים לקחו את עניין ה-SSD הנ"ל כמשהו שהוא יותר אבולוציה מאשר רבולוציה. עד היום היה לנו דיסקים SATA, NL-SAS, SAS ועכשיו יש לנו PCI/NVMe. לא?

זהו, שלא כל כך.

טכנולוגיית ה-NVMe משנה את כל עניין התקשורת של הדיסק SSD עם המחשב. בעבר בכל שרת שמכבד את עצמו היה בקר RAID שאליו היו מחוברים דיסקים. בחלק מהמקרים הדיסקים היו מחוברים ל-2 בקרי RAID, בחלק מהמקרים חצי מהדיסקים בשרת היו מחוברים לבקר אחד והחצי השני לבקר אחר, כל יצרן והשטיקים שלו.

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

בקרי RAID נועדו בראש ובראשונה ליצור לנו "אשכולות" של דיסקים שיחדיו יוכרו כ-RAID Volume. קח לדוגמא אנו יכולים לקחת מספר דיסקים ולבנות RAID 5, או 2 דיסקים ולבנות מהם RAID-1 או RAID-0 אם אנחנו רוצים לאכסן דברים שלא אכפת לנו שימחקו אם דיסק נפל (לדוגמא: Cache לאפליקציות). בקר ה-RAID גם "לקח אחריות" על כל מה שקורה מבחינת חיי ותקינות הדיסקים: בעיות כתיבה/קריאה? הוא יקרא מדיסק אחר. צריך לשמור נתונים בעת הפסקת חשמל? יש זכרון וסוללה על בקר ה-RAID וכך הנתונים ישמרו עד שיחזור החשמל וכשהוא יחזור הבקר יכתוב את הנתונים בצורה נכונה לדיסקים. זה הרעיון המרכזי של בקר RAID.

ב-NVMe לעומת זאת, הדיסק לא מדבר לשום בקר. הדיסק, כמו כל כרטיס PCIe, מדבר ישירות למערכת דרך ה-DMI, כלומר הנתונים עוברים ישירות אל הזכרון (RAM) בשרת וכך נחסך כל ה"תיווך" של הבקר.

אבל עדיין – כמו שכולנו יודעים – צריך בקר לאמצעי אחסון. יש תקלות קריאה/כתיבה, צריך לשמור נתונים בעת הפסקת חשמל, וכאן בדיוק הסיבה מדוע דיסק NVMe הוא דיסק שהוא יקר מדיסק SATA SSD או SAS SSD. בתוך הדיסק עצמו יש בקר (בחלק מהמקרים עם מעבד ARM בעל 2 או 3 ליבות) שכבר מטפל בכל עניין תעבורה ותחזוקת הנתונים. הדיסק עצמו מחולק פנימית ל-RAID-0 (רק בניגוד ל-RAID-0 רגיל, במקרה ויש תקלה בנתונים, הבקר יודע לטפל בה מבלי שהנתונים ינזקו), יש "סופר כבלים" (Super Capacitors) שיודעים לשמור נתונים במקרה של הפסקת חשמל, ומבחינת ביצועים – ה-NVMe ל-Enterprise נע בסביבות ה-2.4 ג'יגהבייט כתיבה לשניה ו-3 ג'יגהבייט קריאה לשניה. יותר זריז מכל SSD RAID שתכינו!

ומה לגבי עמידות/שרידות? הרי לא תסכימו לזרוק את כל הנתונים על דיסק אחד מבלי שיהיה לכך איזה סוג של בטחון, והתשובה לכך נקראת DWPD או Endurance (תלוי ביצרן דיסקים). ה-DWPD מציין כמה פעמים אתה יכול לכתוב על כל הדיסק נתונים ביום והדיסק עדיין יהיה תקין. קחו לדוגמא את ה-DC P3600 של אינטל, שמתאים ל-Enterprise: אם נניח מדובר בגירסת 2 טרהבייט, אז אתה יכול לכתוב עליו עד 6 טרהבייט ליום (מחיקה וכתיבה) והדיסק יעבוד טוב ויעמוד באחריות יצרן.

אז כפי שניתן להבין – אין כיום שום בקר RAID לדיסקים PCI SSD ושיטת העבודה צריכה להיות שונה. חושבים לדוגמא להרים ESXI על מערכת עם 2+ דיסקים כאלו? בהצלחה, תצטרכו לפרמט כל דיסק כ-Datastore בפני עצמו. לעומת זאת, אם אתם מרימים מערכת הפעלה Windows, ודאו שמדובר ב-Windows 2012 ואם זה לינוקס אז Ubuntu LTD האחרון או RedHat/CentOS 7 ומעלה. בתוך מערכת ההפעלה תוכלו לבחור את הדיסקים ולהקים את ה-RAID שרציתם (ותרו על RAID-0 – לא תקבלו ביצועים יותר גבוהים בגלל הארכיטקטורה של NVMe ו-RAID-5 יהווה בזבוז ושחיקת דיסקים לשווא). כמובן שלשם כך יהיה כדאי לצרף לשרת דיסק SSD שאינו NVMe/PCIe כדי להתקין עליו את מערכת ההפעלה.

באם אתם חושבים להרים שרת קבצים (לא חשוב איזו מערכת הפעלה) שתהיה מאוד מהירה וניתנת לגידול בהוספת דיסקים או JBOF – אז מערכת מבוססת דיסקים כאלו (ועדיף שתהיה מחוברת לכרטיסי רשת 10 ג'יגהביט ומעלה בלבד!) תהיה פתרון מעולה. אם אתם רוצים פונקציות כמו הסטורג'ים הגדולים (טוב, לפחות חלק מהפונקציות) כמו DeDup, Compression וכו' – כדאי לחשוב על ZFS.

לסיכום: דיסקים PCIe SSD הם ההווה והעתיד בכל מה שקשור לביצועים. זה לא אומר שצריך לזרוק את כל הדיסקים SAS לפח (מגנטי או SSD) אבל אם משלבים את ה-NVMe SSD כדאי לקחת בחשבון את היתרונות שלו ולהיערך בהתאם ואם אתם קונים שרתים חדשים, אני ממליץ לוודא כי ניתן להכניס אליהם דיסקים של יצרנים אחרים (במיוחד סמסונג, סאנדיסק ואינטל – כולם מאוד אמינים, מנסיון) ואתם לא "נעולים" רק על הדיסקים שמשווק יצרן השרתים שלכם (כמו HPE דור 9) מכיוון שהתחרות בשוק כיום מאוד אגרסיבית והמחירים צונחים משנה לשנה בעשרות אחוזים. דיסקים כאלו גם יכולים להוות בסיס טוב אם אתם רוצים להרים אשכולות (Clusters) מכיוון שכל דיסק נחשב כמספר דיסקים+בקר RAID. השמיים הם הגבול.

אהההמ.. ואם אתם רוצים להקים "חייה" של דיסקים NVMe, תכירו את המכונות האלו של SuperMicro 🙂

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

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

עוד נקודות חשובות לפני מעבר לענן

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

הנקודה הראשונה היא עניין הידע הטכני שקיים באותה חברה. בסטארטאפים לדוגמא, כל עניין ההקמה, תחזוקה, הגדרות, אוטומציה – נופל על איש (או צוות, בהתאם לגודל הסטארטאפ) ה-Devops. מכיוון שרוב מוחלט של הסטארטאפים מקימים את התשתית שלהם בגוגל או באמזון, קיימת חובה מצד איש ה-Devops לדעת היטב דברים כמו Bash, Python הבנה של פורמט קבצים כמו JSON, YAML וכמובן אוטומציה כמו Puppet או Chef, Ansible. בלי זה – איש ה-Devops לא יתקבל לעבוד ב-Startup. זה שמישהו מכיר סיסטם Windows או ניסה פעם אובונטו וגם אם הוא יודע PowerShell, ידע זה לא ירשים את המראיין והוא יפסול את המועמד.

לעומת זאת, חברות לא מעטות בארץ ובחו"ל מעדיפות את הענן של מיקרוסופט, וכאן איש ה-Devops יצטרך יודע ידע בטכנולוגיות של מיקרוסופט (PowerShell ואחרים) כדי לעבוד. מיקרוסופט נותנים SDK לשפות אחרות ו-CLI למערכות הפעלה פופולריות, אך מי שעובד לדוגמא הרבה עם AWS ויעבור להשתמש ב-Azure, יגלה לאחר זמן מה שמיקרוסופט יותר משקיעה בטכנולוגיות שלה מאשר בטכנולוגיות האחרות. כך לדוגמא אם תרצה לבצע אוטומציה עם הכלים הפופולריים בלינוקס, החיים שלך לא יהיו כל כך קלים.

לסיכום נקודה זו: Azure יותר מתאים לחברות שיש להן תשתית בסיס שמורכבת מתשתיות מבוססות מיקרוסופט (AD וכו') וגם יש לאותה חברה שרתי Linux (סתם דוגמא: 70 VM של Windows ו-30 לינווקס) עם אנשים שרובם מבינים בתשתית של מיקרוסופט. אם המצב לעומת זאת הפוך, הפתרונות של גוגל ושל אמזון (לעניות דעתי) יתאימו הרבה יותר לעבודה.

הנקודה השניה החשובה לדעתי זו המחשבה של העברת מכונות אחת לאחת מה-DC שלכם לענן (לדוגמא: העברת 100 VM מה-DC שלכם לענן הציבורי). לא חשוב איך תסתכלו או איזה ספק ענן תבחרו, החשבוניות שתקבלו יהיו מבהילות מסיבה אחת פשוטה: שום ספק ענן ציבורי לא מחפש למשוך לקוחות רק כדי לארח את ה-VM שלהם כ"ספק טיפש" כמו אלפי ספקי VPS בעולם. כל הנקודה של ספקי הענן היא שתשתמשו בשירותים שלהם. אל תרימו Exchange לדוגמא, אלא תשתמשו בשרותי המייל שלהם. אל תרימו SQL משלכם אלא תשתמשו בפתרון ה-SQL שלהם ובכך תוכלו להתחיל בקטן ולגדול עד למימדים מפלצתיים, הכל בתשלום לפי שעה (חלקם לפי דקה) ובמקרים כמו אמזון (בחלק מהמקרים) – ההמלצות הם להשתמש בדברים כמו Serverless ללא צורך ב-VM יעודי, במקום להשתמש ב-Load Balancer הקלאסי שכולנו מכירים – להשתמש בשרות (החדש) ALB שעושה Load Balancing לאפליקציות במקום שכבות.

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

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

בהצלחה 🙂

המעבר לעננים

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

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

האם המעבר לאופיס 365 תגרום ל-Corporates השונים בארץ לעבור לגמרי לענן? לעניות דעתי – לא כל כך מהר. בשביל Mail, השהיה (Latency) של 100 מילישניות לערך אינה כזה עניין גדול, לא מרגישים את זה, אך כשמדובר ב-RDP או פרוטוקולים אחרים כמו HTTP ואחרים – העניין הופך לבעייתי ובכלל בארץ, בניגוד לסטארטאפים שמתחילים מהדקה הראשונה עבודה על ענן, ה-Corporates מאוד שמרנים ויקח זמן עד שהם יעברו לענן. גוגל, אמזון ומיקרוסופט מודעות בהחלט לעניין, ומיקרוסופט לדוגמא מכינה את ה-Azure Stack – הנה לך אדוני המנמ"ר/CTO "מיני Azure" שכולו יושב ב-Data Center שלך. כל ה-DATA שלך יושב בחווה שלכם ושום דבר לא זז החוצה אם לא תרצה, ואם תרצה – תוכל לחבר את ה-Stack הזה בקלות ל-Azure הענן. גם אמזון התכוננו לרגע הזה והם חתמו עם VMWare על פרויקט חדש שנקרא VMWare Cloud on AWS שנותן לך גם פתרון שמשלב את ה-Data Center שלך עם AWS כך שתוכל להתרחב מה-DC שלך החוצה ל-AWS (והפוך). גם לגוגל יש פתרון שהוא בפיתוח ובשלב זה אין עליו מידע פתוח.

המעבר לענן, לעניות דעתי, לא יהיה שאלה של "אם" אלא "מתי". אני לא צופה שבשנה הקרובה חטיבות ה-Hosting בסלקום/בזק בינלאומי/אורנג'/טריפל C יודיעו בקרוב שהן עוברות להפסדים כי הלקוחות העיפו את השרתים מהן (לזה יקח זמן רב, אם בכלל) – אבל המחשבה והדיבור על מעבר של לפחות חלק מהתשתית לענן ציבורי תעלה שוב ושוב בכל "צומת" שהחברה תצטרך להשקיע סכומים נכבדים ב-IT: רכישת רשיונות למערכות הפעלה, מעבר לסטורג' גדול אחר, הקמת ענן פרטי (כמו OpenStack) וכו'. כמובן שיהיו גם מקרים רבים שגם בעוד 10 שנים השרתים יהיו פה ב-DC בגלל רגולציה במקרים שונים.

ובכל זאת, חברות רבות "מסתקרנות" לגבי מעבר לענן. הסיפורים של כל מיני סטארטאפים איך הם נותנים שרות למליוני אנשים ומשלמים רק כמה אלפי דולרים בודדים בחודש לספק הענן גורם לסקרנות ולרצון להתנסות, המחירים בסנטים גם קורצים לחברה שמסתקרנת רצון לטבול אצבעות, ואז הן הולכות למחשבונים של ספקי הענן ואחרי מספר חישובים הן נרתעות. סתם דוגמא: באמזון, שרת Windows יחיד עם 8 ליבות ו-32 ג'יגה זכרון עם דיסק (EBS) של 200 ג'יגה יעלה לחברה $733 בחודש וזה כמובן לא כולל תעבורה החוצה וגם התמיכה של אמזון היא ברמת הבסיס. זול – זה לא. (אגב, גם בגוגל וגם במיקרוסופט המחיר יהיה פחות או יותר זהה) – אז הרעיון לנסות מעבר כלשהו נכנס בחזרה למגירה.

הרווח הגדול של ספקי הענן הגדולים מגיע מהשכרת שרתים ובמיוחד מהליבות (cores). הם מוכרים כל ליבה במחיר מוערך של 30-50$ לחודש וגם הזכרון אינו זול (בערך 10-20$ לחודש, תלוי בקונפיגורציה, מערכת הפעלה, סוג תקשורת וכו'). מדוע? כי כמות הליבות שניתנת למכירה בשרת אינה כה גדולה. שרת עם 16 ליבות אפשר למכור לדוגמא ל-20 לקוחות שכל אחד מקבל ליבה, אבל לא ל-30 לקוחות – כי הלקוחות רוצים ביצועים (בניגוד לספקי VPS שדוחפים עשרות לקוחות על מכונה עם 8 ליבות). ספקי הענן יכולים לרכוש שרתים עם 8 מעבדים כשכל אחד מהם כולל 16 ליבות לדוגמא, אבל העלות של שרת כזה גבוהה מדי בשבילם ולכן ברוב המקרים אם תבדקו מה המעבד שנמצא במכונה שלקחתם מספק הענן, תמצאו שהמכונה מכילה מעבדים כמו Xeon E5 26XX (כלומר מקסימום 2 מעבדים ועד 8 ליבות פר מעבד, ברוב הזמן זה יהיה דגם של 4 ליבות). יש לספקי הענן גם מכונות עם מספר מעבדים וליבות גדולים, אך המחיר – גבוה בהרבה מהמחיר שציינתי.

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

אז איך לדוגמא חברת X תוכל להתנסות בענן ציבורי מבלי לשרוף אלפי דולרים בחודש על PoC?

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

אחרי שפתחנו חשבון אצל ספק הענן, נצטרך לבחור מה הפרויקט שאנחנו הולכים להעביר ואלו VM הולכים לעשות מעבר, והכי חשוב – כמה ג'יגהבייט/טרהבייט אתם הולכים להעביר לספק ענן. אם מדובר לדוגמא בג'יגהבייטים בודדים או עשרות בודדות של ג'יגהבייט, אפשר להעלות את קבצי ה-VM דרך האינטנט, אך אם מדובר בעשרות או מאות ג'יגהבייט או יותר – כדאי להשתמש בשרותי ה-import/export Disk של ספק הענן, כלומר תצטרכו להכין דיסק קשיח (או פתרון אחר בהתאם לספק הענן) ולשלוח אותו לפי הוראות ספק הענן. המחיר – דווקא די זול, בסביבות ה-80$ ועוד 2.50 דולר פר שעת עבודה להעלאת הנתונים (אמזון לדוגמא).

לאחר שהנתונים יועלו לספק הענן, נצטרך להתחיל לבנות את התשתית המאובטחת שלנו מבחינת כתובות IP פנימיות, Subnet, Internet Gateway וכו' וכו' ולהחיל אותם על ה-VM שלנו שבענן (אצל חלק מהספקים יש צורך בהקמת ה-VM מהגיבוי שהעלתם/שלחתם, אצל חלק זה אוטומטי). אחרי שיש לנו את ה-VM למעלה, יכול להיות שנצטרך לשנות כתובות IP בהתאם לתשתית שהגדרנו. המטרה הסופית היא שבסוף כל ה-VM ששלחתם יעלו ותהיה לכם תקשורת אליהם בדיוק כמו שיש אצלכם ב-DC (אם כי ישנם שינויים שתצטרכו לעשות, כמו לא לתת כתובת IP חיצונית לכל שרת אלא לעבוד בצורה מסודרת מול Gateway או עם Bastion אם אתם עובדים עם מכונות לינוקס). הכל עובד? מצוין. בשלב זה תתחילו לעבוד עם המערכת כמו שהיא בימים או שבועות הקרובים. קיבלתם קרדיט, זה לא עולה לכם שקל, נצלו את זה 🙂

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

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

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

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

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

ולמי שמעוניין לעבור את התהליך או לקבל יעוץ – אשמח לסייע 🙂

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