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

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

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

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

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

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

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

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

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

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

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

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

להגן על האתר שלך

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

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

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

אם לדוגמא ברגע זה אתה מבין שהאתר שלך אינו נגיש ואתה שומע מהספק שאתה מותקף, אתה יכול לגשת לאתר של CloudFlare, לבחור את הדומיין שלך (אם יש לך מספר דומיינים שמציגים אתרים מאותו שרת – עבור על כל אחד מהדומיינים), ללחוץ על כפתור ה-Firewall ופשוט לבחור "I'm Under Attack", כמו בתמונה הבאה:

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

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

אפשרות מעולה שקיימת (בחבילה של ה-20$) היא שימוש ב-WAF (ר"ת Web Application Firewall). עם WAF החיים יותר קלים כשצריכים להגן על אתרים רציניים. חלק לא קטן מהתקפות דרך רשתות Botnet הם התקפות שנראות במקרים מסויימים כמו כמות גולשים גדולה שנכנסת, אבל מדובר בהתקפה. הנה דוגמא:

מי שלא מכיר לוגים של כניסות לאתרים לא יבין מה הבעיה, מי שמבין רואה שיש כאן נסיונות כניסה עם מחרוזות רנדומליות שנועדו לעקוף חוקים שחוסמים כניסה. במקרים כאלו ה-WAF יכול לסייע ולחסום דבר כזה בשניות (תומכי CloudFlare כותבים עבורך את החוק אם תתן להם קובץ access_log או שאתה יכול לכתוב בעצמך). מעבר לכך, חוקי ה-WAF מתעדכנים מצד CloudFlare נון סטופ, כך שאתה מקבל הגנה גם על דברים שאינך מודע אליהם (לדוגמא אם אתה משתמש בתוכנה כמו WHMCS (זו תוכנה שקשורה ל-Billing ואוטומציה של שרותי Hosting), אז בעבר היו מספר פריצות לתוכנה, ועד שיצרן התוכנה תיקן אותם, ב-CloudFlare הכניסו חוקי הגנה ל-WAF ללקוחותיהם, כך שאם מישהו היה מנסה לפרוץ ל-WHMCS שלך, הוא היה נכשל בשעה שאצל אחרים הפורץ היה "חוגג".

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

לסיכום, חשוב לזכור את הנקודות הבאות:

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

על Ransomware והתגוננות מפניהם

עדכון 1: כשהכופרה מעיפה את VSS (בסוף הפוסט)

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

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

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

  1. פריצה חמורה אירעה בשרתי צד ג' שנותנים שרותי פרסום לאתרים גדולים ודרך פירצה זו הופצו סקריפטים שרצים בדפדפן שמחפשים כל סוג פריצה שקיים לדפדפנים שונים, ל-Flash, ל-Java ו-JS ושאר דרכים – כדי להוריד אוטומטית Ransomware למשתמש וכדי לגרום לו להריץ אותו. כל מה שהמשתמש היה צריך לעשות זה פשוט לגלוש לאתרים הגדולים (כמו New York Times, BBC, AOL, MSN ועוד) והסקריפט שהיה נטען לדפדפן המשתמש היה כבר רץ ומחפש פירצה.
  2. עד כה רוב תוכנות ה-Ransomware היו משתמשות במפתח פרטי קבוע שהיה חלק מחבילת ה-Ransomware, ולאחר זמן מה יצרני האנטיוירוס ידעו לזהות את המפתח ולהציע ללקוחותיהם דרך לחילוץ הקבצים מבלי לשלם כופר. לאחרונה הדבר שונה ובחלק מתוכנות ה-Ransomware המפתח הפרטי נוצר כל פעם מחדש ומועלה מיד לשרת של התוקף ונמחק מהמחשב, כך שלא ניתן אם הותקן Ransomware כזה לחלץ את הקבצים משום שמדובר במפתח 256 ביט שכיום עדיין אף אחד לא פיצח (אולי ה-NSA הצליחו אבל הם לא מפרסמים כלום בנידון כמובן), כך שמחשב פרטי או מחשב בעסק שחוטף Ransomware כזה, הדרך היחידה לחלץ את המידע – היא לשלם את הכופר לתוקף..

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

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

ניתן לעומת זאת להשתמש בשיטה ותיקה שמיקרוסופט המציאה ממזמן (והורידה חלק מהפונקציונאליות בחלונות 8/8.1 אך החזירה ב-10) והיא ה-Volume Shadow Copy (בקיצור: VSS). בשיטה זו המערכת שומרת Snapshot על כל הקבצים המקומיים (לא ב-XP, שם יש שמירה על קבצי מערכת, לא על תכנים כמו מסמכים וכו')

במידה ובמחשבים מותקנים דיסקים קשיחים, ניתן ליצור Partition נוסף שעליו ישבו ה-snapshots (כדאי לעיין במאמר הזה כדי לבצע את הדברים) או שניתן לבצע Snapshot למערכת NAS (על כך בהמשך) וכך ניתן גם לשחזר קבצים את Snapshot של ה-Volume (עוד פרטים כיצד לבצע mount ל-snapshots ולחלץ מידע – ניתן לקרוא כאן).

אם התכנים נשמרים ב-SAN או NAS, כדאי להפעיל את תכונת ה-Snapshot ב-Storage עצמו (חפשו Volume shadow או VSS) ואז את השחזור ניתן לבצע ישירות מתחנת המשתמש (או ב-Storage, לפי הצרכים). יש לוודא ששרות ה-VSS נראה בתחנת המשתמש (בתחנות מבוססות חלונות 7 ובגרסאות חלונות 8 PRO וכו' אפשר להשתמש בכלי כמו Shadow Explorer לשם כך).

שרתי לינוקס שמשרתים תחנות Windows דרך SAMBA: אם הנכם משתמשים ב-LVM אז תוכלו לבצע Snapshots ולשקף אותם דרך smb.conf בשרת כך שניתן יהיה לשחזר קבצים. ניתן לראות איך לבצע זאת כאן. אם הינכם משתמשים בשרותי ZFS על לינוקס/BSD או סולאריס, אין שום בעיה להשתמש ב-Snapshots שמיוצרים ע"י ZFS ל-SAMBA ואפשר לקחת סקריפט מוכן עם הוראות בקישור כאן.

לסיכום: נזקי כופרה יכולים ליצור כאב ראש לא קטן, במיוחד שאין גיבוי עדכני, אז כמובן שצריך לוודא שגיבויים מבוצעים תדיר (ונבדקים תדיר – הדבר האחרון שאתם צריכים זה גיבוי לא קריא בעת חרום). מומלץ לבדוק ולהשתמש בשרות VSS. נכון, השרות די מוגבל (לא ניתן לבצע את גיבוי ה-VSS לרשת) אבל הוא יכול לשמש כפתרון זול על מנת למגר נזק מכופרות. אם אתם מציעים למשתמשים אחסון תוכן בכונני רשת, ודאו כי ל-storage יש snapshots שניתן לגשת אליהם דרך אפשרות ה-Restore to Previous Versions (אם אין, אפשר לתת למשתמשים Shadow Explorer או לכתוב סקריפט ב-PS שיאפשר שחזור).

כשהכופרה מעיפה את ה-VSS: כפי שציין הגולש גיא אדרי בפורום, רוב הכופרות עוצרות את שרות ה-VSS ומוחקות גיבויים (בהנחה וביטלתם את ה-UAC). במקרים כאלו מאוד מומלץ לחשוב לעבור לכונני רשת שיאחסנו את התכנים (לא את האפליקציות וכמובן לא את ה-SWAP). במידה ואין תקציב לסטורג' לדבר כזה, ניתן לבנות סטורג' זול שיארח כונני רשת (יש לדאוג ל-2 כונני SSD ב-RAID-1 שישמשו כ-Cache קריאה/כתיבה ל-RAID פנימי שיורכבי מדיסקים SATA או NL-SAS). אותו שרת יכול להריץ שרות SAMBA, להתחבר ל-AD ועל השרת הזה ניתן ליצור כונני רשת ולבצע Snapshots לכונני הרשת עם LVM או עם ZFS. במקרה התקפה של כופרה, היא לא יכולה למחוק את ה-Snapshots של כונני הרשת, ניתן גם לבצע Snapshots בתדירות גבוהה (עם ZFS בלינוקס או סולאריס או BSD אפשר גם כל 10-15 דקות וניתן להשאיר כמות גדולה של Snapshots מבלי לחשוש לבעיות ביצועים), כך שבסופו של דבר אם כופרה תוקפת, אפשר לשחזר את המחשב מ-IMAGE, למפות את כונן הרשת, ולשחזר מה-snapshot את כל התוכן אל ה-share של כונן הרשת.

על VMWare VSAN

[stextbox id="info"]בפוסט זה אינני מדבר על VSAN 6.0 ועל גירסה זו יפורסם בעתיד פוסט נפרד.[/stextbox]

בחברות רבות, תצורת השימוש ב-vSphere היא כדלהלן: יש X שרתים שהם מהווים את ה-Compute (ועליהם בעצם רצים המכונות הוירטואליות), יש Storage של חברה כלשהי (NetApp/EMC/HP/IBM וכו'), ויש כמובן מתג או 2.

התצורה הזו היא תצורה טובה, אולם אחת הבעיות היא ביצירת תלות מוחלטת ב-Storage. יש כשל ב-Storage? סביר להניח שחלק או כל ה-VM יפלו. רוצים להרחיב את ה-Storage? שלם מחירי פרימיום על מדפים ודיסקים. בנוסף, ישנם מקומות שמעדיפים להשתמש בדיסקים מקומיים במקום עם Storage.

ב-VMWare עבדו ב-3 שנים האחרונות על פתרון אחר שנקרא VSAN שמתאים במיוחד לחברות קטנות עד בינוניות, כאלו שלא יכולים להרשות לעצמם Storage יוקרתי, או כאלו שמעוניינים בפתרון Storage אחר.

השיטה של VSAN היא די פשוטה: בכל שרת יהיו מינימום 2 דיסקים, כאשר אחד מהם הוא דיסק מגנטי (בין אם זה SATA, NL-SAS או SAS) ודיסק אחד מבוסס Flash (שוב – SATA או SAS, אפשר גם PCIe או nVME). יש צורך בלפחות 3 שרתים (ליצירת "רוב" – Quorum) ושהם יהיו בתצורת אשכול (Cluster) וכמובן שיש צורך בסוויצ' טוב עם עדיפות ל-Switch במהירות 10 ג'יגהביט וכמובן – יותר מכניסת רשת אחת פר שרת.

ה-VSAN מאחסן את ה-VM בדיסק המגנטי וה-Flash משמש כ-Cache (הן לקריאה והן לכתיבה כאשר הנתונים מועברים לדיסק המגנטי מהדיסק FLASH ברקע) והוא גם משכפל את הנתונים לדיסקים האחרים בשרתים באשכול. אחד הדברים שיש צורך לתת את הדעת עליו הוא שאין RAID בתצורה כזו. הדיסק בשרת A משוכפל לדיסק בשרת B ולשרת C (זה קצת יותר מורכב מזה) ולכן אם לדוגמא מחליטים להוסיף דיסק, מומלץ להוסיף גם דיסקים בשאר המכונות ועדיף שיהיו כמות זהה של דיסקים.

מבחינת נפילה – כאשר נופל שרת, 2 השרתים האחרים "לוקחים פיקוד" היכן שהשרת האחר נפל ומכיוון שהנתונים נמצאים בשאר הדיסקים שקיימים באשכול, הנפילה כמעט לא תשנה למעט העניין שהמכונה תצטרך להיות מופעלת מחדש (אוטומטית). עם VSAN לא ניתן להשתמש בפונקציית Fault Tolerance. אם יפלו 2 שרתים לעומת זאת, ברוב המקרים המכונות שהיו ב-2 השרתים הנופלים לא יעלו (אגב, ניתן להרחיב את ה-VSAN גם לשרתים נוספים שאינם כוללים דיסקים מגנטיים או דיסקים בכלל, אולם אז המהירות לא תהיה גבוהה). ניתן "לעקוף" מגבלה זו בשימוש Storage Policies שתיכף ארחיב לגביו.

אחד הדברים ש-VMWare עושה בשנים האחרונות בכל הקשור ל-Storage הוא "לזרוק" משימות שונות שה-Storage יעשה בעצמו ולא שרתי ה-Compute שלך, מה שנקרא גם "האצה". בעבר הרחוק דבר כזה לא היה קיים ודבר כמו Snapshot היה מתבצע ע"י ה-vCenter תוך שימוש במשאבי השרת למרות שכל Storage שמכבד את עצמו כולל פונקציונאליות זו. בגירת vSphere 5 הציגה VMWare את ה-VAAI, שגם נקרא "Hardware Acceleration" שבו פעולות מסויימות נעשות ע"י ה-Storage מבלי לקחת משאבים מהשרתים. טכנולוגיה נוספת ש-VMWare הציגה היתה ה-VASA, כך שפונקציות כמו thin provisioning או Deduplication ופונקציונאליות נוספות היו ניתנות לביצוע ישירות מה-vCenter כאשר בסופו של דבר הן היו מבוצעות ב-Storage עצמו ללא לקיחת משאבים מה-Compute.

ב-VSAN ישנה גם פונקציונאליות כזו, אם כי היא בעצם חלקית. כך לדוגמא אתה יכול לקבוע שהתוכן שלך שמאוד חשוב לך ישוכפל על פעמיים או יותר על הדיסקים ב-Cluster, וזה מבוצע ע"י שימוש ב-Storage Policies. כל מה שעליך לעשות הוא להחליט מה הם ה-VM החשובים לך, ולבנות Policy שיאמר למערכת כמה שרתים נופלים המערכת תהיה מסוגלת "לסבול" ולהמשיך להריץ את אותו VM, כמה פעמים לשכפל את הנתונים, כמה מקום לשמור גם במצב של Thin Provisioning ועוד, ואת ה-Policy אתה מחיל.

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

כעת נעבור לשלב הפחות טכני ויותר "מכירתי" – את VSAN לא צריך להוריד. אם יש לך vSphere 5.5 U1 ומעלה – הוא כבר שם ויש צורך להפעיל אותו במספר נקודות מבלי להוסיף שום דבר ל-vCenter. מה שכן תצטרך, זה רשיונות, והרשיונות נמכרים פר CPU פיזי בשרת במחיר של $2495 (לפני מו"מ), כך שאם יש לך לדוגמא 3 שרתים ולכל אחד מהם 2 מעבדים, תצטרך לשלם (שוב, לפני מו"מ) סכום מוערך של 15,000 דולר (המחיר הוא רק ל-VSAN, יש צורך גם ברשיונות ESXI ו-vCenter, ואגב – בלי vCenter אין VSAN), וכאן מתחילה ההתלבטות של חברות: לא שווה לקנות Storage פשוט-בינוני במחיר כזה?

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

מצד שני, אם ה-Storage שלך משרת גם אחרים לשרותים כמו SMB/NFS, אז השיקול משתנה, מכיוון ש-VSAN לא בנוי לתת שרותים כאלו מכיוון שלא מדובר על מכונת VM שנותנת שרותי NFS/iSCSI לשרתים ושיטת האחסון שונה שם לחלוטין (ועל כך תוכלו לקרוא בהרחבה כאן). כמובן שאתה יכול להרים לך VM מבוסס לינוקס או Windows ודרכו לשתף קבצים הן דרך NFS והן דרך SMB, אבל לא לכולם זה נוח.

והנקודה הכי חשובה היא: מה אתה מייעד עבור המערכת? אם לדוגמא עבור VDI, אז הביצועים לא יהיו "מזהירים" למרות שיש שימוש מאסיבי ב-Flash כ-Cache (ולא, אי אפשר להכניס 2 דיסקים SSD בגרסאות VSAN קודמות ל-6, רק דיסק מגנטי ודיסק SSD, ובגירסה 6 אם תרצה להשתמש ב-All Flash, תצטרך להוסיף $1500 פר מעבד באשכול). אם אתה לעומת זאת צריך ערימה של VM שיעבדו בנפרד מה-Storage של החברה עקב ענייני אבטחה וכו' – VSAN יכול להוות פתרון די טוב.

על Virtual Flash Cache ב-ESXI 5.5

אחת הפונקציות המעניינות שקיימות ב-vSphere נקראת Virtual Flash Cache. ב-VMWare התחילו להטמיע את זה אמנם מגירסת vSphere 5.0 אולם רק בגירסה 5.5 עניין ה-Cache עובד בצורה טובה ומלאה. ב-VMWare קוראים לזה בקצרה vFRC, נשתמש בפוסט זה במושג המקוצר.

נתחיל בהסבר של מה זה vFRC: זו בעצם טכנולוגיה שקיימת גם בשאר מערכות הפעלה שונות (כמו לינוקס לדוגמא) המאפשרת לנו להשתמש ב-SSD שיושב מקומית בתור שרת ה-ESXi (ולא ב-Storage המרכזי) ובעצם הוא מאחסן חלק מהנתונים שנקראים תדיר ע"י מערכת ההפעלה ומאפשר בעצם Read & Write Cache. ה-Cache אינו בא להחליף את ה-Storage שלכם וכל ביט שיכתב ב-Cache יכתב גם ב-Storage, כך שאם ה-SSD המקומי מתקלקל, אפשר להחליף, לפרמט ולחזור להשתמש בפונקציונאליות.

מערכת ה-Cache נמצאת ב-2 מקומות מרכזיים: במקום אחד שבו אתם יכולים להגדיר כמות X ג'יגהבייטים שהמערכת תשתמש בעת מצב שהיא תהיה עמוסה ואז אותם X ג'יגהבייטים ישמשו כ-Swap (ואם אתם משתמשים ב-Swap, הגיע הזמן לשוחח עם הקודקודים למעלה על שדרוג מהיר)

המקום השני הוא שבו משתמשים ב-vFRC הוא על המכונות הוירטואליות, וכאן אני צריך להסביר משהו חשוב: לא חשוב מה ה-Storage שיש לכם, בכל פעם שה-VM צריך מידע לקרוא או לכתוב על ה"דיסק" – ה-VM צריך לעשות "טיול" ל-Storage שלכם דרך ה-Datastore, ובין אם ה-Datastore שלכם מבוסס על iSCSI, NFS או FC, מדובר (פחות או יותר) ב"טיול" שלוקח זמן. נכון, זמן קצר, אך בכל זאת.

אם ניקח דיסק SSD מקומי על ESXI ונתקין עליו VM, הביצועים שלו יהיו מעולים בהשוואה למה ש-Storage נותן (למעט בתקשורת של 10Gbit), אבל אז כמובן לא תוכלו להשתמש בפונקציות מתקדמות כמו HA, DRS וכו'.

עם vFRC, זה לא חשוב מה ה-Storage שיש לך, בין אם הוא מורכב מכמה דיסקים SATA שהצלחת לקושש או שמדובר על מערכת EMC או כל מערכת יוקרתית בטירוף – ל-vFRC זה לא משנה. ה-vFRC שומר חלק מהנתונים (בהתאם לגודל שהגדרת) מקומית על SSD שקיים בתוך ה-ESXI והוא מזין את הנתונים שנכתבו בחזרה ל-Storage "מאחורי הקלעים" כך שמבחינת ה-VM, המערכת ממשיכה לפעול גם אם הכתיבה בין ה-vFRC ל-Storage מתבצעת כרגע. כנ"ל לגבי קריאה – קטעים שהמערכת מוצאת שנקראים שוב ושוב (נניח אפליקציה גדולה שרצה על ה-VM ומטעינה ספריות שונות) מאוחסנים ב-SSD המקומיים ומוזנים ל-VM ישירות ברגע שה-VM צריך את אותם קטעים. המערכת גם מספיק חכמה להעיף חלקים ישנים מה-Cache שאין צורך או שנגמר המיקום שמוגדר ל-Cache ויש צורך לכתוב מקטעים חדשים.

הקמת ה-vFRC היא פשוטה: לאחר שהכנסתם SSD ל-ESXI, הפעילו את ה-vCenter (ה-WEB, לא ה-Client הישן), לחצו על ה-HOST שהוספתם, לחצו על Settings, ולמטה אתם תמצאו את ה-Virtual Flash. להלן דוגמא ממערכת טסטים בביתי (לחצו להגדלה):

המלבנים האודמים מציינים מה ללחוץ, המלבנים הכחולים מציינים את הכונן שנבחר והגודל שזמין ל-Cache עבור VM (במקרה הספציפי הזה הגדרתי 20 ג'יגה ל-Swap). המלבן הירוק מציין סה"כ כמות מקום פנוי במידה והכנסת יותר מ-SSD אחד (חשוב לציין: Virtual Flash עובד ברמה של RAID-0 מכיוון שכל ה-DATA הוא זמני)

כפי שציינתי, הגדרות Cache ל-VM נעשות פר VM (אם כי יש כל מיני כלים לעשות זה באופן קבוצתי, אני פשוט משתמש ב-BASH ו-sed לשם כך 😉 ) על מנת להגדיר כמות ג'יגהבייט Cache. כך זה נראה (לחצו להגדלה):

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

רואים את ה-Block Size? הגודל עצמו חשוב מאוד וזה תלוי ב-VM, גודל ה-DATA שהוא כותב וכו'. חישוב לא נכון יתן מה שנקרא Cache Miss מה שיוריד מהביצועים. החישוב אינו כל כך פשוט אך ב-VMWare הכינו מסמך שמסביר את ה-vFRC מבחינת ביצועים, חישובים שצריך לבצע וכו'. להלן המסמך.

[scribd id=268003224 key=key-UjCvDIBCgd52bjCNMHWt mode=scroll]

לסיכום: vFRC יכול לעזור הרבה (לפעמים עד מצב של 300% שיפור) בביצועים, אם עושים את זה נכון. אני לא ממליץ לרוץ מיד לקנות SSD מבוסס PCIe אלא להתחיל בטסטים עם SSD פשוט מבוסס SATA. יש שיפור? עכשיו אפשר לחשוב להוסיף דיסקים SSD בין אם הם מבוססים SAS או SATA או PCIe (אם יש לכם מקום פנוי בשרת). אפשר כמובן להכניס יותר מאחד.

vFRC עוזר בכל מיני סוגי VM ואין צורך בשום שינוי ב-VM עצמו (ב-Guest), וזה בהחלט יכול לעזור אם מקימים VDI, רק חשוב לשים לב לגודל הבלוקים. גדלים כמו 1024 (המקסימום) קילובייט יבטיח לכם Cache Miss וירידה בביצועים, ומצד שני כמות בלוקים קטנה (4-8K) לא ממש תיתן ביצועים רציניים. קראו את המסמך, ותנסו (אין צורך לכבות ולהפעיל את ה-VM מחדש כשמשנים, אם כי מומלץ לסגור את האפליקציה ב-VM ולהפעיל אותה מחדש).

כמה דברים על VDI – תוספות

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

ראשית – השוק בישראל בכל הקשור ל-VDI: ברוב המקרים, השוק בישראל נחלק ל-2: אלו שמשתמשים (ומיישמים) את הפתרון של Ctrix (חלק מקופות החולים לדוגמא), ואלו שמשתמשים בפתרון של מיקרוסופט (רוב חברות הסלולר, בנקים). ל-2 הפתרונות יש חפיפה (פחות או יותר) מבחינת פונקציות כאשר ל-Citrix יש יתרונות כמו:

  • תמיכה הרבה יותר גדולה ב-Clients מסוגים שונים (מטלפון סלולרי ועד כרומבוק, כולל הפצות לינוקס שונות, אנדרואיד, iOS וכו')
  • תמיכה בדסקטופים שאינם מיקרוסופט (דסקטופ מבוסס לינוקס)
  • מוצרים משלימים מהחברה עצמה שנותנים בעצם פתרון יותר "בוגר" כפתרון VDI
  • לא חשוב מה פתרון הוירטואליזציה שתשתמש – בין אם זה Hyper-V, XenServer או ESXi (ואפילו KVM) – ל-Citrix זה לא ממש משנה (אם כי תמיכה רשמית תקבל רק לשלישיה שציינתי לעיל)

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

גם לפתרון של VMWare יש יתרונות לא רעים כלל וכלל. יש לך כבר שרתים שמריצים RDS? מצוין, תתקין עליהם Agent של VMWare View והמשתמשים שלך יוכלו להתחבר ישירות לכל האפליקציות שביצעת להן Publish, או למכונות דסקטופ וירטואליות קיימות (אם כי את המכונות דסקטופ הוירטואליות מומלץ לך להקים מחדש עם ה-View). בפתרון של VMWare הקמת מכונות וירטואליות יכולה להתבצע במגוון אפשרויות, החל בהקמת מספר מכונות וירטואליות סטטיות שמשתמשים מתחברים אליהן בצורה קבועה, ועד מצב שהמערכת משתמשת ב-Golden Image שאליו היא מחברת דיסקים זמניים ובכך היא תקים VM חדש בכל פעם שמשתמש עוזב (וישנן אופציות נוספות כמובן) תוך שניות ספורות. גם תהליך העדכון למכונות הוא קל מאוד ותהליך הלימוד של View לא יקח יותר מיומיים (כל עוד יש למנהל פתרון הוירטואליזציה ידע ברמה של VCP). אם יש לחברה סניפים, פתרון ה-PCoIP נותן פתרון יעיל ודינמי (בהשוואה ל-RDP) שיודע להתמודד יפה עם רוחב פס משתנה, עם הצפנה מובנית בפרוטוקול עצמו (גם RDP תומך בהצפנה, PCoIP מוגדר עם הצפנה כברירת מחדל), אין צורך ב-Wan Optimizer (אפשר לקרוא עוד על כך ואפשרויות נוספות כאן), ומבחינת כמות השרתים הנוספת שצריך כדי להקים ולנהל את ה-View עצמו (לא כולל ה-VM של הדסקטופ) – הכמות היא קטנה (יחסית, יחסית).

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

  • מבחינת מחיר (שוב, אינני מדבר על מחירי ברזל מבחינת compute ו-storage – את זה תצטרכו לרכוש בכל פתרון שתבחרו) – הפתרון של מיקרוסופט הוא הכי זול (תצטרכו CAL פר משתמש או ציוד). סביר להניח שתצטרכו לשלם על רשיון מערכת הפעלה לדסקטופ (רשיון ה-OEM לא יעזור למיטב ידיעתי, אבל את הרשיון הזה תצטרכו לשלם בכל פתרון VDI.
  • מבחינת קלות תפעול והקמה, הפתרון של מיקרוסופט קל למימוש, אך גם הפתרון של View קל למימוש ואם אתם כבר משתמשים ב-ESXi, אז תוכלו לבקש ממי שמוכר לכם את הרשיונות מחיר מיוחד (עם האיום של לעבור לשכנים ממול 🙂 ) ובכל מקרה אם תרצו לרכוש את הפתרון של VMWare אל תרכשו את הרשיונות בחנות של VMWare, מנסיון – המחיר יכול להיות נמוך בהרבה מהמחיר המוצג באתר (3000 יורו ל-10 משתמשים בגירסת ה-Enterprise).
  • אם אתם מקום שמשתמש ב-Clients שונים (או חושבים להכניס Clients נוספים חוץ מעמדות PC שיהיו "טיפשות") – אז מומלץ להסתכל על הפתרונות של VMWare ושל Citrix. נכון, הרוב תומך היום ב-RDP, אבל המתחרים למיקרוסופט משקיעים הרבה יותר ב-Clients ממיקרוסופט עצמה, במיוחד בתמיכה בציודים כמו Zero Client או כרומבוקים (פוסט על כרומבוקים בחברות יופיע כאן בקרוב).
  • אם אתם רוצים להעביר סביבות לינוקס ל-VDI (יעיל במיוחד לפיתוח, תוכנות CAD וכו') – גירסה 6 של View והגירסה הקרובה של Citrix תומכות בכך, הפתרון של מיקרוסופט לא תומך בכך.
  • אם אתם רוצים להעביר/להקים מכונות VM שמריצות תלת מימד/עריכת וידאו ל-VDI, הפתרון של Citrix ושל VMWare יתאימו לכך (יהיה צורך ב-GRiD של nVidia לשם כך). הפתרון של מיקרוסופט לא תומך בכך (זה יתמך בגירסה הבאה).
  • אם יש לכם סניפים מרוחקים שמחוברים ב-DSL או בפתרון תקשורת אחרת, פתרון PCoIP יכול להוות יתרון הואיל ואין צורך בפתרונות WAN Optimization.
  • נקודה חשובה: ראיתי את העניין הזה בקופות חולים, בחברות אשראי, בחברות ביטוח, בבנקים וכו' – אם אתם נותנים פתרון VDI, תעיפו את ה-PC והטמיעו Thin Client. מחשב PC צורך יותר חשמל מ-Thin Cliernt במיוחד כשמדובר במאות מחשבי PC בבניין. פתרון Thin Client מבוסס ARM צורך פחות מעשירית ממה ש-PC צריך מבחינת חשמל, ואין צורך בהחלפת מאווררים.
  • אם אתם חושבים על מעבר ל-VDI, כדאי לשקול פתרון מבוסס Hyper Converged, כך שלא תצטרכו להשקיע עוד מאות אלפי דולרים על Storage חדש. ישנם מספר פתרונות כאלו (כתבתי על כך כאן), וכל עוד אינכם "נעולים" אך ורק על Hyper-V, תוכלו להרים 2-3 שרתים כאלו ולראות איך זה עובד מבחינת מחיר וביצועים. אגב, VSAN 6 של VMWare יצא לאחרונה, והתמיכה שלו ב-Flash הרבה יותר טובה (עכשיו הוא תומך ב-Flash לא רק כ-Cache).

לסיכום: למיקרוסופט, Citrix ו-VMWare יש פתרונות ל-VDI, אבל שום פתרון אינו מתאים לכולם. לפעמים כדאי לנצל את ההזדמנות כדי להתנסות במוצר מתחרה ואולי אותו פתרון יתן לכם את מה שחיפשתם. גם אם אתם "נעולים" עם פלטפורמה X, כדאי לנסות פתרונות מתחרים. מנסיוני – היו מקרים שפיילוט על מוצר מתחרה פתר לחברות גם בעיות שיש להן עם מה שהן משתמשות באופן קבוע, אז תרימו פיילוט, במקרה הכי גרוע – אפשר לפרמט את השרת 🙂

כמה מילים על VDI

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

למי שלא מכיר את רעיון ה-VDI, הנה הסבר בכמה מילים: VDI (ר"ת Virtual Desktop infrastructure) היא בעצם דרך/שיטה חדשה לתת למשתמשים דסקטופ משלהם. בניגוד לדרך שרוב החברות והארגונים משתמשים כיום, עם VDI למשתמש הפשוט אין יותר PC (או שיש לו Thin Client או שה-PC שלו "מומר" למערכת הפעלה שכל תפקידה הוא להפוך ל-Thin Client), וכל ה-Windows רצים כמכונות וירטואליות על שרתים שמריצים Hypervisor כמו vSphere, Hyper-V או Xen (וגם KVM שאליו אתייחס בהמשך). אין יותר טכנאים שרצים בין המשתמשים להחליף דיסקים קשיחים או תקלות חומרה אחרות וכל האחסון של המכונות הוירטואליות נמצא על NAS או SAN חזקים מבוססי SSD.

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

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

מנהלי רשתות ותיקים יכולים להרגיש תחושה של Deja Vu. כבר היינו ב"סרט" הזה בעבר. חברה כמו Citrix מוכרת קרוב ל-20 שנה פתרונות קרובים לכך (פתרונות כמו XenDesktop ו-XenApp לדוגמא) ומיקרוסופט מוכרת פתרון די דומה (שברובו בין כה נמכר למיקרוסופט ע"י Citrix) ב-8 שנים האחרונות לפחות. נכון, לא היתה וירטואליזציה כמו שיש כיום והכל רץ על שרתים עם שרותי Remote Desktop Service (מה שהיה בעבר Terminal Services). אצל 2 החברות, הפתרון היה שרת Windows Server שהמשתמש היה מקבל עליו Session עם אפליקציות שהיו מותקנות בצורה מרוכזת והמשתמשים היו מקבלים מעין Shortcuts. אגב, הפתרון הזה קיים יותר מ-30 שנה בעולם היוניקס עם X server/Client.

ההבדל המהותי בין אז להיום הוא שכיום עם VDI המשתמש מקבל את "כל העוגה", הוא מקבל מכונת Desktop, מכונה וירטואלית שכוללת הכל, בדיוק כמו ה-PC שלו.

מכיוון שעניין ה-VDI קיבל Hype בשנים האחרונות, חברות כמו מיקרוסופט, Citrix ו-VMWare החלו לשחרר מוצרים ל-VDI. להלן מספר דוגמאות:

  • מיקרוסופט כוללת פתרון VDI בתוך Windows Server 2012, כאשר הפתרון יכול להיות כמו המצב ה"קלאסי" (שרת שמריץ אפליקציות והמשתמשים מתחברים רק לסשן עם אפליקציה) או מצב VDI מלא כאשר מכונת Windows וירטואלית רצה פר משתמש עם Hyper-V, והמשתמש מתחבר דרך Thin Client עם RDP למכונה הוירטואלית שלו. לפתרון הזה יש יתרון שעקומת ההקמה/מעבר הוא די קטן (כל עוד יש לך ברזלים או תקציב לערימת ברזלים ואחסון רציניים). המחיר הנוסף (חוץ מהשרתים והאחסון) הוא על רשיונות ל-RDS (פר משתמש).
  • ל-VMWare יש את VMWare View (שנקרא כיום VMWare Horizon). בפתרון הזה ישנו פתרון PCOIP והיתרון שלו הוא שאפשר לחבר יותר מסכים (עד 4) עם רזולוציה יותר גבוהה פר מסך (עד 2560X1600), ויש תמיכה ב-OpenGL (שלא קיימת בפתרון של מיקרוסופט). הפתרון של VMWare מצריך תשתית של vSphere שעליה ירוץ Horizon. הפתרון גם תומך ב-RDP, אם כי התמיכה אינה כוללת תמיכה מתקדמת של RDP כמו RemoteFX (וגם על כך יש סייג – VMWare View 6 יכול "לתפוס טרמפ" על שרת RDS ולשמש בעצם כ-Gateway).
  • הפתרון של Citrix הוא XenDesktop (שמורכב מכמה חלקים) והוא מאפשר פתרון די זהה למה שמיקרוסופט מציעה, רק שהפתרון של Citrix יכול לרוץ על HyperVisor מסוגים שונים כולל Hyper-V, vSphere ו-Xen.

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

דרישה נוספת ויחודית בתחום ה-VDI זה GPU Hardware Accelerator. אם המשתמש גולש הרבה או שיש לו המון פעילות בדסקטופ (ומה לעשות, אתרים ישראליים "טוחנים" את ה-CPU עם פרסומות Flash) – השרתים שלך יהיו עמוסים (חשוב לזכור: 30 פריימים לשניה ברזולוציה ממוצעת של 1280X1024 דורשת לא מעט משאבים, במיוחד אם המשתמש השאיר אתר חדשות ישראלי ממוצע ב-TAB או חלון פתוח – ה-Flash "יטחן" את מעבדי ה-Xeon שלכם, ועוד לא דיברתי על ניגון וידאו!). במקרה של מיקרוסופט, החברה ממליצה בחום להכניס כמה כרטיסי GPU לשרתים על מנת להוריד את העומס שקשור ל-Display (כך שהכרטיס הגרפי בשרת יבצע את עבודת רינדור המסך וישלח את התוצאה ב-RemoteFX [שהוא חלק מ-RDP] ל-Thin Client).

ב-VMware Horizon אין אמנם דרישה לכרטיסי GPU שישבו על השרת אלא אם המכונות הוירטואליות יריצו אפליקציות גרפיות כבדות כמו פוטושופ/עריכת וידאו/3D ועוד או במקרים בהם יש לך יותר מ-100 מכונות דסקטופ וירטואליות. במקרים כאלו תצטרך או להכניס כרטיסים מבוססי OpenGL כמו Quadro של nVidia או להסתכל על פתרון ה-Teradici PCoIP Hardware Accelerator. במקרים בהם יש לך אלפי מכונות וירטואליות שצריכות עבודה גרפית אינטיסיבית, תצטרך לשוחח עם nVidia לגבי פתרון קופסאות ה-GRiD שלהם. זול – זה לא.

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

מוצר שהיה עד לפני חודשיים ל-Citrix (לצערי הם הרגו את המוצר) שנקרא VDI-in-a-box. המוצר היה Appliance וירטואלי שרץ על התשתית הוירטואלית שלך, היה קל מאוד להגדרה (לוקח משהו כמו 20 דקות להגדיר ולהכין הכל) והיה מאוד מתאים להרצה במקומות קטנים (כמה עשרות דסקטופים וירטואליים עד מאות בודדים). ב-Citrix הודיעו שאת הטכנולוגיה הם ישלבו בפתרון Xen Desktop בעתיד.

KVM: ל-KVM יש פתרון שהוא "בדרך". ניתן כיום להקים פתרון VDI מבוסס KVM כל עוד יש לך כלי ניהול ל-KVM שידע להעביר מכונות בזמן עומסים לשרתים פנויים יותר (כמו Convirt). הבעיה המרכזית עם KVM היא שאין אפשרות להכניס GPU לשרתים ולבצע offload של פעילות גרפית לכרטיסי GPU כמו המתחרים, ושוב – יש Flash פועל אצל המשתמש – תראו את ה-Xeon "מזיע" ממאמץ ולכן KVM כיום יכול להתאים לפתרון VDI אם מדובר ב-pilot/POC כשמדובר בכמות קטנה (כמה עשרות מקסימום) של מכונות דסקטופ וירטואליות.

אחת השאלות שנשאלתי לא פעם בעבר לגבי עניין ה-VDI היא מדוע לא קיים פתרון שיודע להשתמש במעבד הגרפי שקיים ב-Client. אחרי הכל, אפילו טאבלטים ומחשבים שהם Low end ממוצעים כיום יכולים לנגן וידאו ולהראות גרפיקה בצורה חלקה ויפה. התשובה לכך היא שפעילות כזו תצטרך תקשורת ישירה ורצופה 30 פעם בשניה בין הכרטיס הגרפי ב-thin client ל-CPU שנמצא בשרת, מה שמצריך המון רוחב פס ו-Latency נמוך ואת זה לא ניתן בקלות לפתור. הפתרונות של Citrix ושל VMWare נותנים פתרון עקיף, וברוב הזמן למשתמש ממוצע בחברה זה יספיק, אבל במקרים של שימוש גרפי רציני, הפתרון מגיע מפרוטוקולים קנייניים שמשתמשים ב-GPU שרץ על השרתים במקום להשתמש שימוש מלא ב-GPU שקיים ב-Thin Client.

אז האם כדאי לעבור ל-VDI? לעניות דעתי – תלוי.

אם יש בארגון שלכם סניפים – פתרון VDI יכול לסייע (במיוחד כתחליף ל-Terminal Services, לתשומת לב חברות תקשורת סלולריות מסויימות…), פרטוקולים כמו HDX או RDP או PCOIP יודעים להתמודד להתמודד עם Latency תלת ספרתי. אם יש לכם קבוצה גדולה של משתמשים שמריצים אופיס ודפדפן – אפשר בהחלט לשקול להעביר אותם לפתרון VDI (לא לשכוח לבטל להם Flash, בין כה השימוש העיקרי בו היום הוא פרסומות). לעומת זאת, אם יש לכם בארגון כמה מאות/אלפי משתמשים ואתם חושבים על מעבר ל-VDI, אני ממליץ לבדוק את השיקול הכלכלי שוב, אני אישית מתקשה להאמין שתמצאו לכך הצדקה כלכלית רצינית.

בעניין Hyper Converged

מי שקורא חדשות טכנולוגיה המיועדות ל-IT/CTO/CIO בוודאי שמע בשנתיים-שלוש האחרונות את המושג Hyper Converged (או HC בקיצור), מושג שיותר ויותר חברות משתמשות בו כדי להציע משהו חדש למנהלי ה-IT.

על מנת להבין את עניין ה-HC, כדאי שנראה מה יש ברוב החברות כיום:

כשזה מגיע לוירטואליזציה (ואין זה משנה איזה פתרון Hypervisor אתם משתמשים), בד"כ יש מספר שרתים שהם ה-Host, והם מחוברים ל-Storage כלשהו ומשתמשים בשרותים כמו NFS או iSCSI (או SMB במקרה של Hyper-V) כדי לאחסן קבצים של המערכות הוירטואליות. במקרים מסויימים משתמשים בדיסקים שנמצאים מקומית בשרת עצמו כשמדובר על שרת (Host) שמריץ מערכות וירטואליות עצמאיות או במקרים שאין Storage גדול רציני.

כשאנחנו מעוניינים ליצור אשכול לצרכים שונים (High Availability, Fault Tolerance וכו'), אנו צריכים 2 שרתים (במינימום) שהם זהים מבחינת החומרה ו-Storage חיצוני שיהיה מחובר ל-2 השרתים, ואנו מגדירים דרך הפאנל של הויראטואליזציה (כמו vCenter או VSA/VCSA) את 2 השרתים כאשכול. יש כמובן "ערימה" של דברים להגדיר כמו סוג האשכול, הגדרות אחסון, כתובות, קבוצות פורטים וכו' – אבל זה בעקרון Cluster.

בשיטת ה-HC הדברים שונים לחלוטין: בשיטה זו אין לנו צורך יותר ב-Storage חיצוני. במקום זה השרתים יהיו עם דיסקים מסוגים שונים (SSD, דיסקים מכניים מבוססי SAS/NL-SAS/SATA) וכל השרתים יהיו מחוברים באשכול למתג של 10 ג'יגהביט (מינימום, כאשר כל הכניסות במתג הם 10 ג'יגהביט). על השרתים מותקנת מערכת וירטואליזציה (בד"כ vSphere אך גם KVM נתמך בחלק מהמקרים) ובנוסף מותקן VM מיוחד בכל שרת פיזי שמתחבר ישירות לדיסקים והוא מנהל אותם (ולא ה-vSphere). בשיטה זו הנתונים נכתבים לכל הדיסקים בכל השרתים והמערכות הוירטואליות רצות על השרתים כאשר האחסון הוא על הדיסקים המקומיים וכש-VM "עובר דירה", חלק מהנתונים עובר מהדיסקים המכניים (האיטיים ויתר) ל-SSD וכך ניתנת לנו האפשרות לבצע Live Migration או כל פעולת High Availability אחרת שנרצה (HA, FT וכו'). במצב כזה (וברוב מערכות ה-HC) אנחנו יכולים לסבול מצב ששרת פיזי אחד נופל מבלי שאף מערכת וירטואלית תיפול.

ישנן מספר חברות שמוכרות מוצרי HC, נתמקד בשלישיה המובילה: Nutanix, Simplivity ו-EVO:Rail.

ל-Nutanix יש פתרונות מ-2 סוגים: הפתרון המבוסס תוכנה (אתה מתקין על השרת שלך) או פתרון חומרה (אתה קונה את השרת מהם), כאשר בפתרון שלהם חייבים לפחות 3 שרתים. ההתקנה עצמה היא קלה (לוקח בערך רבע שעה) ויש לך ממשק GUI נחמד ובנוסף יש לך CLI (שהוא בעצם לינוקס עם אובונטו, ככלל – כל המערכת היא בעצם סקריפטים של לינוקס + מודולים קנייניים שלהם) ויש גם ממשק RESTful API למפתחים. המערכת קלה (יחסית) ללימוד, אך היא אינה מחליפה את הצורך ב-vCenter/VSA אם אתה משתמש בפתרון מבוסס VMWare. ניתן במקום vSphere להשתמש בוירטואליזציה הפתוחה KVM אם כי בשלב זה הם עדיין לא מאפשרים להריץ מכונות VM מבוססות Windows (וגם ה-KVM שיש להם די ישן למען האמת, מגירסת CentOS 6.5).

הפתרון השני הוא של Simplivity וגם הוא מאפשר לך לבצע Cluster אך עם טוויסט מעניין: אתה יכול להוסיף את הענן של אמזון כ"חווה" (DC) משלך ואתה יכול להעביר מכונות הלוך ושוב בין DC שונים, ובנוסף יש לך את הדברים שאתה רגיל אליהם מעולם ה-Storage כמו DeDup, Replication, Snapshots וכו' כאשר הדגש הוא בעצם לא "לחנוק" לך את רוחב הפס בין השרתים שיושבים אצלך בבניין לבין ה-DC האחרים. בניגוד לפתרונות המתחרים, הכמות המינימלית שאתה צריך זה שרת אחד.

הפתרון השלישי הוא של VMWare שנקרא EVO:Rail והוא מתבסס על פתרון ה-vSAN ש-VMWare מוכרת, רק שכאן מדובר על שרתים פיזיים שאתה רוכש מיצרנים שונים כקופסא סגורה. גם כאן, יש צורך ברכישה של מינימום 4 שרתים שישמשו כ-Block אחד.

למי שמעוניין להיכנס יותר לעומק ולקרוא על ההתקנה, השימוש, מה נתמך במה, אני ממליץ לקרוא את המאמר המעולה של בריאן סור על הפתרונות הנ"ל.

אז מה? להתחיל לארגן מכרז למכור את ה-Storage הגדול שלכם? ממש לא.

תחום ה-HC כרגע "שורץ" בפתרונות מחברות צעירות וחברות סטארט-אפ. Nutanix כרגע מובילה את שוק ה-HC עם שיווק מאוד אגרסיבי, אבל הפתרונות שלהם גם מאוד יקרים. כמה יקרים? 6 ספרות במונחים ישראלים ואם תרצה משהו יותר רציני כמו ארון שלם – 7 ספרות. החברות הגדולות המייצרות מוצרי Storage כבר לוטשות עיניים לעבר החברות הקטנות וסביר להניח שנשמע בקרוב על כמה רכישות, ומכיוון שתחום ה-IT הוא תחום שמרני, מומלץ לא לסגור עסקאות עתה אלא להמתין.

תחום ה-HC נותן פתרונות שיכולים מצד אחד לחסוך הרבה עבודה (תקים פעם אחת, תוסיף ניטור משלך ועדכונים מעת לעת – ואתה מסודר. תיאורתית לפחות), אבל מי שוותיק בתחום הזה יכול להיזכר בתקופות קודמות בהן גם חברות מכרו ל-IT מוצרים שנתנו "HC" בתחומים אחרים (זוכרים Self Healing?) וכעבור מספר שנים אותן קופסאות ישבו בחוות השרתים ו… צברו אבק. פתרונות ה-Storage שיש לנו כיום מלכתחילה לא תוכננו לאחסון דיסקים של VM והפתרונות שיש הם (בלי שאף אחד יודה בצורה רשמית) הם "hacks" רציניים (פתרון כמו iSCSI היה בכלל מדובר להתחברות ל-initiator יחיד, בינו ל-LUN שמוגדר ב-Storage, והשינויים ב-VMFS ש-VMWare עשו איפשרו לו להתחבר ל-2 שרתים במקביל, ו-NFS היה צריך גם שינויים ברמת ה-Storage בקוד על מנת לאפשר לו לעבוד טוב מול Hypervisor). פתרון טוב, לעניות דעתי, הוא פתרון Cluster אך מופרד ועדיף פתרון שמקובל על רובם או כולם: פתרון שיתן לנו לייצא מ-Cluster שמיועד ל-Storage איזה Block Device, אבל שיהיה בצורה טבעית ניתן לשיתוף בין Clients שונים לדוגמא, פתרון שאם אני מחבר אותו למערכת וירטואליזציה, שאינו צריך להמתין ל-Acknowledge שהתוכן נכתב לפני שהוא מאפשר למכונה הוירטואלית להמשיך לעבוד כרגיל.  אלו פתרונות שעדיין לא קיימים כיום בצורה יציבה ומלאה (הכי קרוב שידוע לי שקיים – זה Ceph). בעיה נוספת שקיימת עם פתרונות ה-HC הוא עניין הבטחון לגבי העתיד – מה תעשה אם אותה חברה שרכשת ממנה קופסאות מחר תיעלם או שיתגלעו ביניכם חילוקי דעות לגבי מחירי חידוש תמיכה?

ב-The Register הופיע לאחרונה מאמר של טרוור פוט על כך ש-VMWare "מפחדת" מחברות כמו Nutanix שתסחוף את השוק לכיוונה ומכיוון שב-Nutanix הוירטואליזציה היא (כמעט) אינה פתרון רק של VMWare, אז VMWare יכולים להפסיד את השוק וחברות אחרות מתחרות ל-Nutanix יכולות להעתיק את אותה שיטה ושוב – VMWare תהיה בצרות. מבחינתו, כמנהל IT הוא יוכל לעבור בין פתרון אחד לאחר בקלות. זו דעתו כמובן, אך מנסיון שלי כאחד שהקים כמה פתרונות שמבוססים הן על VMWare והן על פתרונות וירטואליזציה אחרים, אני יכול לאמר כי מעבר בין פתרון וירטואליזציה אחד לפתרון אחר אינו קל כלל וכלל ובמקרים רבים התוצאות והתהליך יגרמו אי נוחות למנהל ה-IT, ועוד לא התחלתי לדבר על מעבר מפתרון שיש NetApp (לדוגמא) לכל פתרון אחר, שגם הוא, איך נאמר בעדינות – הדרך אינה סוגה בשושנים.

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

על אחסון וגדילה

כשמדברים על אחסון (כ-Storage), רובנו נתייחס למכונה הגדולה שנמצאת בחברה, ה-Storage הזה שברוב מוחלט של המקרים הוא קופסא של יצרן כלשהו. זה יכול להיות של NetApp, של EMC, של IBM, של HP ושלל חברות גדולות וקטנות, כל חברה בד"כ תקנה לפני הצרכים או לפי ההמלצות, ואצל רובן תהיה "קופסא" אחת כזו שאליה משורשרים "מגשים" של דיסקים. זה יכול להיות דיסקים מכניים מבוססי SAS, דיסקים שהם SSD, דיסקים שהם NL-SAS או אפילו במקרים מסויימים – SATA.

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

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

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

בנוסף – ישנם 2 בעיות רציניות:

הבעיה הראשונה נקראת SPOF (או Single Point Of Failure): הגדרות שגויות, מעבד שמתקלגל, זכרון שנדפק, בקר שהפסיק לעבוד בצורה תקינה – והפתרון אחסון שלך יתן ביצועים גרועים או שבמקרה הגרוע – יפסיק לעבוד. נכון, יש SLA שסביר להניח שרכשתם ובו טכנאי של החברה המייצרת/יבואן הפתרון יתחבר אליכם מרחוק או יגיע אליכם תוך זמן קצר, אך עדיין, גם אם הוא יתקן את התקלה, תצטרך ברוב המקרים להפעיל את כל המכונות הוירטואליות מחדש, לוודא שכל השרותים למעלה, לוודא שהגדרות שביצעו אנשי ה-IT באמת נשמרו ולא צריכים להגדיר מחדש כדי ששרותים יעלו ובקיצור – כמעט שום תקלה שקשורה לתיקון האחסון אינה מסתיימת בדקות ספורות אלא יותר בשעות.

אם תשאל את יבואן האחסון לפתרון, הוא ישמח להציע לך פתרון של "אשכול" (Cluster): בפתרון כזה אתם רוכשים עוד פתרון אחסון זהה (אם כי אפשר בחלק מהמקרים להסתפק בדיסקים יותר איטיים ו-SSD שישמש כמטמון, תלוי ביצרן, תלוי בדגם) ואז מבחינה תיאורתית אם האחסון הראשי נופל – האחסון השני נכנס לפעולה (מה שנקרא Active/Passive Cluster) ואפשר "לטפל" לדגמים יותר גבוהים שמאפשרים לך בעצם לפצל את העומס בערך למחצית, כאשר 2 האחסונים עובדים ביחד וכל ביט שנכתב – נכתב ב-2 האחסונים. פתרון זה נקרא Active/Active Cluster ובמקרה כזה אם אחד האחסונים נופל, השני ימשיך לעבוד כרגיל וברגע שהאחסון התקול יטופל ויעלה, יהיה סינכרון בין האחסונים. הבעיה הכי גדולה בפתרון כזה – הוא המחיר, והוא מאוד גבוה.

הבעיה השניה שהיא יותר מהותית באותם אחסונים כמו NetApp ואחרים – היא "קניינות" של הפתרון, כלומר שהכל סגור מבחינת ה"ברזל", הדיסקים והמערכות שעובדות בתוכו. אם מחר יפנה אליך לדוגמא יבואן דיסקים ויציע לך מבצע-משוגע של דיסקים מבוססי SAS גדולים במחיר של 3 ותקבל 4 (לדוגמא) – לא תוכל להכניס את הדיסקים הללו לאחסונים הנ"ל. ישנו קוד מיוחד שבודק את הדיסק שהכנסת ל"מגש" וברגע שהוא מוצא שהדיסק אינו מאותו יצרן/סוג מסויים שיצרן האחסון עובד איתו – המערכת פשוט לא תהיה מוכנה להכניס את הדיסקים החדשים שקנית לשימוש. אתה גם לא יכול להכניס JBOD שאינם של אותו יצרן אחסון לשימוש עם פתרון האחסון. בקיצור – הכל צריך לעבור דרך השיווק של יצרן פתרון האחסון שיש לך, והוא כמובן נוקב במחירים הרבה יותר גבוהים ממה שאתה יכול לקנות בשוק החופשי. (אם כי אסייג שבחלק מהפתרון לקצה היותר נמוך, במיוחד פתרונות NAS – אין בעיה להכניס דיסק של כל יצרן, אבל הבעיות של פתרונות כאלו הם עדיין ה-Scaling).

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

מ-Scale Up נעבור למושג שמוכר יותר בתחום ה-High Performance Computing ותחום הענן – זהו תחום ה-Scale Out בפתרונות אחסון.

סביר להניח שלקוראי פוסט זה יש חשבון אחד או יותר אצל אחד מספקי פתרון ענן כלשהו, בין אם זה אמזון , או Google Compute Platform או Azure של מיקרוסופט – ונגזרותיהם: לאמזון יש את S3, לגוגל יש את ה-Google Drive, למיקרוסופט יש את OneDrive ויש גם פתרונות אחרים כמו DropBox ואחרים.

המכנה המשותף לכל אותם פתרונות אחסון קבצים בענן – זה מערכות האחסון שלהם. אף אחד מספקי הענן לא משתמש ב-NetApp או EMC והם לא משתמשים בדיסקים SAS במהירות 15K RPM כדי לאחסן את הקבצים שאתה מעלה (אינני מדבר על אחסון של מכונות וירטואליות או EBS – לזה נגיע בהמשך). במה הם משתמשים? בדיסקים הכי פשוטים שיש (כן, גם דיסקים איטיים). מהי מערכת האחסון שלהם? לכל אחד מספקי הענן יש פתרון In House משלו שהמתכנתים שלו כתבו או השתמשו בפתרון קוד פתוח אחר (אף אחד מהספקים לא מפרט) וברוב המקרים זה רץ על לינוקס. הם כמובן משתמשים בדיסקים של SSD כחלק מהפתרון, ואת השרידות הם מבצעים בכך שהם כותבים את אותו הקובץ למספר מקומות אחרים באותו Data Center. מכיוון שמדובר בפתרון שמכיל מאות אלפי (ויותר) דיסקים קשיחים – הפתרון מבחינה טכנית אצלהם שונה לחלוטין ממה שיש ב-Corporate. אין RAID ברמה כלשהי, ואין מעבדים קניינים מיוחדים בתוך שרתי האחסון (שאליו מחוברים כמות רצינית של JBOD). כך מצד אחד הם חוסכים בהשקעה ומצד שני הם יכולים לתת רמת שרידות מעולה. אחרי הכל, במחיר של דיסק אחד ל-Enterprise אפשר לקנות 3 דיסקים הרבה יותר גדולים מבוססי SATA פשוטים.

כשזה מגיע לאחסון מכונות וירטואליות או אחסון שיותר מוכר כ-Raw Storage – לדוגמא EBS, PD, Drives – בהתאם לספק ענן, גם כאן ספקי הענן לא "רצים" לקנות את פתרונות ה-Enterprise והם מעדיפים פתרונות SSD שהם זולים, גם אם חיי המוצר יהיו קצרים, והספקים משתמשים בכל טריק אפשרי כדי לתת למכונות שלך בענן ביצועים גבוהים (יחסית), אבל שוב -אין שימוש בפתרונות אחסון קנייניים מבחוץ כמו של EMC ואחרים. זה פשוט לא שווה להם פיננסית, במיוחד בתחרות האכזרית כיום שכל ספק חותך בעשרות אחוזים את המחיר והשאר "נגררים" אחריו בחיתוכי מחיר לאחר מספר ימים.

הפתרונות שתיארתי מבחינת ספקי הענן – הם נכללים בקטגוריות ה-Scale Out, כלומר הפתרונות לא מבוססים על שרת אחסון יחיד ואולי עוד Mirror, אלא הם מתחילים ב-3 שרתים ומעלה כאשר העומס מחולק בין השרתים. במקרה של ספקי הענן מדובר כמובן בהרבה יותר מ-3, ומכיוון שהכל נכתב בכמה וכמה עותקים, גם אם יפלו שרתים שמחזיקים מאות דיסקים, אתה לא תרגיש בכלום, כי אתה תקבל את השרות משרתי אחסון שכנים שיושבים באותו Data Center.

פתרונות ה-Scale Out Storage החלו את דרכם בפרוייקטים שמבוססים HPC. בפרוייקטים כאלו יש צורך באחסון כמויות עצומות (פטהבייטים ומעלה) וכל פתרון כזה אם היה מבוסס על פתרון של NetApp או EMC היה גוזל הרבה יותר מדי משאבים כספיים לפרויקט ומכיוון שנוצר צורך בפתרון שהולך וגודל ומצריך המון דיסקים ושרידות מאוד גבוהה – נוצרו פתרונות אחסון מבוססי קוד פתוח שיכולים גם לתת פתרון לפרוייקטים מבוססי HPC וגם יכולים לגדול מיידית ולשרת אלפי ועשרות אלפי מכונות וירטואליות, אחסון קבצים ועוד.

בפוסט הבא אתאר כיצד פתרון Scale Out יכול להתאים ל-Enterprise/Corporate, מהם ה"מועמדים", יתרונות וחסרונות ובמיוחד – על Ceph.

עתיד אמצעי אחסון ב-Enterprise

[stextbox id="info" caption="הערה"]מאמר זה מדבר על הדיסקים/כוננים המשמשים לאחסון ולא על פתרונות כמו NAS/SAN וכו'.[/stextbox]

מבחינת דיסקים/כוננים קשיחים, אנחנו נמצאים בתקופה מאוד מעניינת. ב-15 שנים האחרונות היו שינויים בתחום זה, אך לא שינויים כה מהותיים. רוב החברות בעשור האחרון השתמשו בכונני SAS (ולפני כן SCSI לגרסאותיו) בשרתים, וההתקדמות בכל הקשור לתחום הכוננים המגנטיים – היתה מועטה. היתה קפיצת מהירות סיבוב לדקה מ-10K ל-15K, היו הכפלות כמות אחסון (144G ל-300G ברוטו, 300 ל-600 ומשם ל-900) ופה ושם ראינו גם "נגיעות" של יצרניות הדיסקים בהטמעת פתרון Cache קטן כלשהו בדיסקים.

מבחינת כוננים מבוססי טכנולוגיית Flash, ראינו התפתחות ממצב של "1 ביט בתא" (SLC) ל-2 ביטים ויותר בתא (MLC) (היתה גם קפיצה ל-TLC – של 3 ביטים בתא, אולם הם היו מיועדים לשימוש ביתי/דסקטופ) וגם קומבינציות שיותר מתאימות ל-Corporate כמו eMLC, ואפשר לקרוא על כך בקצרה כאן.

אחד הדברים שחברות רצו בכל הקשור לדיסקים מגנטיים – היו גדלים יותר רציניים. זה נחמד שיש גדלים כמו 150 או 300 ג'יגה, אבל במחשב שלך יושב לו בנחת דיסק של 2-4 טרהבייט. הוא בהחלט לא מתאים ל-Enterprise והיצרניות החלו לקבל שאלות לגבי דיסקים גדולים ב-Enterprise. מכיוון שאי אפשר להכניס פלטות כמו שיש דיסקים של דסקטופ ל-Enterprise SAS ולהאיץ את מהירות הסביבוב ל-15K, הגו היצרניות סטנדרט חדש שנקרא Nearline Storage SAS ובקיצור: NL-SAS.

מהו NL-SAS? אלו דיסקים SATA שמיוצרים בטכנולוגיה שונה במעט מטכנולוגיית הדיסקים לדסקטופ, אך הבקר שיש לאותו דיסק הוא בקר SAS, כך שדברים כמו Command Queue, ערוץ תעבורה כפול ועוד יתרונות שיש ל-SAS – קיימים לדיסקים הללו, אך האמינות שלהם אינה כמו האמינות של דיסקים SAS "אמיתיים" (תוכלו לקרוא על כך יותר כאן). אז נכון, יש פחות אמינות מבחינת שגיאות כתיבה וטיפול בהן בהשוואה ל-SAS, ואין מהירות של 15K סיבובים לשניה (יש דיסקים SATA עם מהירות 10K, אגב, והם יקרים), אבל מצד שני – יש הרבה יותר שטח אחסון בדיסק.

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

טכנולוגיות ה-SSD הלכו והתפתחו יותר ויותר. מהירות ה-SAS (של 6 ג'יגהביט בשניה) נהפכה לצוואר בקבוק ואז הגיעה טכנולוגיית ה-SAS במהירות 12 ג'יגהביט. אם היינו חיים בעולם של דיסקים מגנטיים בלבד, הסטנדרט הזה היה נשאר למספר שנים, אך הסטנדרט הנ"ל לא מחזיק מעמד והיצרנים החלו לפנות לפתרון אחר: ערוץ ה-PCIe X4 (ברוב המקרים הכרטיס הוא בחיבור פיזי של PCIe X8 שהוא יותר סטנדרטי) והכונן כפי שהכרנו אותו הפך לכרטיס PCIe ומכיוון שהחיבור ב-PCIe הוא הרבה יותר מהיר מ-SAS (עם Latency מאוד נמוך), מהירות הכתיבה והקריאה זינקה בפראות למהירויות בג'יגהבייטים, אך אז צצה בעיה אחרת: כמה כרטיסים אתה יכול להכניס בשרת 1U? אולי 2 במקרה הטוב, ואולי 3-4 בשרתי 2U.

היה צריך פתרון אחר והוא הגיע. הפתרון הוא NVME. טכנולוגיית ה-NVMe בעצם "מורידה" את הפתרון מהצורך ב-Slot פיזי של PCIe ומעבירה אותו בחיבור חוטי על בקר MVNe שיושב בכונן עצמו.

כך נראה חיבור NVMe (בתמונה מימין) בכונן של סמסונג בדגם XS1715. כפי שאתם יכולים לראות, מדובר בחיבור שונה לחלוטין מ-SAS או SATA. זהו חיבור בסטנדרט חדש שנקרא SFF-8639 (הוא דומה מאוד לחיבור SFF-8482). היתרונות של חיבור כזה הוא שהוא תואם אחורה ל-SAS ול-SATA והוא משתמש בכל הפינים ה"מיותרים" למימוש חיבור PCIe. (כמובן שיש צורך בכך שלוח האם ידע לתמוך בחיבור SFF-8639). חיבור זה, בשלב זה, יודע לתמוך רק בכונני SSD בתצורה של 2.5 אינטש בעובי 15 מ"מ.

הבה נסתכל על המפרט של ה-XS1715. זהו כונן שמתחרה בדגמים ל-Enterprise כמו של אינטל P3700 או כונן אחר של חברת Micron. להלן הטבלה:

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

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

סמסונג היתה הראשונה להציג כונן עם נתונים מטורפים כאלו, אך המתחרים לא נמצאים מאחור. אינטל תכריז כבר בקרוב על סידרה P3800 (השמועות מדברות כבר על סידרה P4XXX עם שינויים רציניים וכפי הנראה שגם אינטל תרד מגירסת הכרטיסים) שתתן את אותם ביצועים כמו של סמסונג. סאנדיסק ומיקרון גם יוציאו מוצרים עם IOPS פחות או יותר באותה רמה במחצית השניה של השנה ובינתיים מדברים על כך שלקראת סוף השנה נתחיל לראות כוננים בטכנולוגיית NVMe עם IOPS של 7 ספרות. כל הכוננים הנ"ל מגיעים עם כמות אחסון החל מ-300 ג'יגהבייט ועד 3.2 טרהבייט, וזה עוד לפני שאותן חברות מתחילות להכניס את טכנולוגיית יצור צ'יפים בתלת מימד (שכבה על שכבה, סמסונג משווקת כיום לדוגמא את ה-Pro 850 שמיועד לשימוש Semi Enterprise/Workstation ב-32 שכבות, [גירסא הבאה תהיה כבר לפי השמועות – 128 שכבות] מה שיתן גם ביצועים יותר טובים מכונני SSD מבוססים SLC, וגם אין צורך בליטוגרפיה כה נמוכה – מה שסמסונג משתמשת זה 40 ננומטר)

כך שהמירוץ – בעיצומו, ועוד לא דיברנו על פתרון יותר מדהים – פתרונות SSD שיושבים על .. תושבות הזכרון בשרת. (שוב – Latency הרבה יותר נמוך מ-NVMe של משהו כמו 2-3 ננו-שניות).

אז לאן אנחנו מתקדמים בעצם? לפיצול.

מבחינת עלויות/אחסון – כוננים מגנטיים מבוססי SAS במהירות 10-15K סיבובים לשניה יופסקו להיות מיוצרים במהלך השנים הקרובות (לא השנה או השנה הבאה כמובן) מכיוון שלטכנולוגיה הזו אין ממש המשך. אפשר להאריך לה את החיים באופן מלאכותי בכך שהיצרנים יטמיעו Cache יותר גדול, אך בעידן שחברות רוצות שטחי אחסון יותר ויותר גדולים, ה-NL-SAS וגם כונני SATA יתפסו יותר מקום כשמדובר על אחסון שלא מצריך IOPS מטורף (לוגים, ארכיבאות, גיבויים, וידאו בזרימה). כיום המחיר להרים Cluster לצורך אחסון יורד כל הזמן וישנן מספר מערכות בקוד פתוח (וגם קנייניות כמובן) המאפשרות לך לקבל ביצועים טובים במחיר די זול תוך שילוב כונני SSD להאצת גישה, מהם תוכל לייצא החוצה iSCSI או NFS או SMB לשימושי החברה.

מבחינת עלויות/ביצועים (כן, IOPS) התחרות עושה את שלה ולחברות/יצרני Storage יש מגוון אפשרויות חדשות לבנות מערכות שנותנות IOPS גבוה בהתאם לתקציב של הלקוח, החל מ-SAS, המשך ב-NVMe ועד ULLtraDimm, ורובן יאפשרו ללקוח לשלב מודולים שונים כך שאפשר תמיד לגדול ולקבל IOPS יותר גבוה. שילוב טכנולוגיית התלת מימד ביצור רכיבי Flash מוזילה משמעותית את עלות היצור וכמות הצ'יפים שיש צורך בכונן SSD כזה, ואני משער שכבר ב-3 השנים הקרובות נתחיל לראות תחרות רצינית שתתן גם לחברות הקטנות פתרונות IOPS מכובדים.

Exit mobile version