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

על אחסון ווידאו בחברות מדיה

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

בעולם ה-Corporate, סטורג' הינו חלק קריטי מהתשתית. מכונות VM מאוחסנות על סטורג' ולא על דיסקים מקומיים, אפליקציות כמו SQL/Oracle DB דורשות סטורג' (במיוחד אם מריצים כתצורת אשכול [cluster]), כל קבצי העבודה של העובדים (מסמכים, קוד וכו') מאוחסנים בסטורג', גיבויים זמניים מאוחסנים בסטורג' ובקיצור – הסטורג' "נוגע" כמעט בכל תחום. אחרי הכל, כולם מכירים: כשסטורג' נופל – ההיסטריה בשיאה.

בשנים האחרונות, עם חדירת העננים הציבוריים ל-Corporate – השימוש ב-Storage פוחת במעט (ככל שמעבירים VM ושרותים לענן), אך עדיין לסטורג' יש מקום מאוד שוב. יחד עם זאת, כמות השדרוגים או רכישות סטורג' חדש – מתמעטת. אחרי הכל, אם "העפתי" 50 VM ל-AWS לדוגמא, והם יעבדו ב-AWS באופן קבוע, אני אשמור מקומית גיבוי, אבל אני לא אצטרך להשאיר אותם ב-Datastore היקר המקומי, אני אמחק אותם ואז יתפנה לי מקום בסטורג', מה שאומר שרכישת עוד מדף סטורג' תיהפך למיותרת. בנוסף, בעולם ה-Corporate הגדילה היא איטית. לא כל יום מרימים עוד 100 VM (וגם אם מרימים, משתמשים ב-Template כך שרק השינויים נשמרים ולא כל VM שוקל 10 ג'יגה ומעלה).

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

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

מדוע? כי חברות הוידאו דורשות צילום איכותי וגבוה. פעם היו מסתפקים ברזולוציית SD ולאחר מכן העולם קפץ ל-HD ול-Full HD וכיום הרוב מצולם ב-4K או 5K ו-6K וחלק (שמשתמשים ב-RED לדוגמא) מצולם בכלל ב-8K. בניגוד לצילום באייפון (או גוגל פיקסל) – מצלמות מקצועיות מצלמות ב-Bitrate החל מ-20 מגהביט ועד 80-130 מגהביט (ומעלה במקרה של RED אם לא משתמשים ב-REDCODE) ועוד לא דיברנו על ביטים פר ערוץ צבע (8,10,12 וכו') ועוד. במקרים רבים מצלמים ב-2 מצלמות (או יותר), נוסיף אודיו שמוקלט בנפרד, צילומי סטילס (בחלק מהמקרים). את כל הערימה הזו צריך להעלות לאיזה סטורג' כלשהו ובחלק מהמקרים צריך גם לתרגם (Transcode) ל-Codec אחר (מה שנקרא Mezzanine Codec) בכדי לאפשר עבודה רציפה על התכנים בהתאם לתוכנת העריכה המועדפת על החברה. אחרי זה יש צורך בעריכה של הקובץ, הוספת תכנים שונים (אפקטים, תלת מימד, אנימציות, אודיו וכו'), ולבסוף יש צורך שוב בהמרה של התכנים לפורמטים שונים (הוצאה לאולפנים שונים בהתאם לדרישות שלהם, יוטיוב, סטרימינג וכו').

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

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

הבה נאמר שלחברה יש סטורג' כיום זמין שאליו מתחברים עורכי הוידאו ומשתמשים בתכנים. אחרי שהתוכן עבר עריכה והמרה – יש צורך לאחסן את התכנים על מנת שיהיו זמינים מיידית. כאן פתרון Scale Up פתוח (כמו ZFS) יכול להוות פתרון מעולה תוך שימוש בשרת יחיד שאליו משורשרים מספר JBOD ובתוך אותה מערכת יש מספר קטן של דיסקים SSD מהירים והשאר – דיסקים SATA פשוטים (או SAS או NL-SAS, בהתאם לתקציב) וגדולים מאוד (8,10,12 טרהבייט) עם תצורת RAIDZ שמאפשרת מצב שגם אם 2 דיסקים קשיחים נדפקים, התוכן נשאר תקין בצורה זמינה. זיכרו – סטורג' זה משמש רק לאחסון ולא לעבודה ישירות, כך שעורך שצריך תוכן כלשהו, רואה את הקבצים כ-Read Only ללא אפשרות שינוי. נגמר המקום? מוסיפים JBOD גדול עם 36 דיסקים (לדוגמא) וכל דיסק הוא בגודל 10 טרהבייט, ב-RAIDZ2, הרי שנטו נקבל תוספת של 309 טרהבייט, ואם חברה רוצה ממש אחסון של 1 פטהבייט, אז 4 JBOD כאלו מלאים יתנו 1.2 פטהבייט עם שרידות טובה.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כשרוכשים SSD לשרתים

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

אחת הבעיות שיש כיום היא שלרבים אין כל כך מושג מה זה אומר SSD. כולם כמובן יודעים שדיסק קשיח מכני הוא דיסק המורכב ממספר פלטות, ראשים מגנטיים, ובקר בתוך הדיסק עם זכרון מטמון קטן (בין 16 ל-256 מגהבייט, תלוי בדיסק ולאיזה שוק הוא משוייך כמובן). כולם יודעים שכשזה מגיע לשרתים – אתה צריך בקר RAID טוב, חלקם ירכשו בקר עם סוללת גיבוי וזכרון מטמון נוסף – והעיקר כשרוכשים דיסקים מכניים – חשובה מהירות הסיבוב (10,15K RPM), חשוב סוג החיבור (SAS, SATA) ועוד כמה פרמטרים קטנים כמו PMP, Dual Connection וכו'.

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

מאמר זה יתן מספר מושגים לגבי תכנון ורכישה של דיסקים SSD. בכדי להתחיל אני ממליץ לקרוא את המאמר הזה באתר של Seagate. המאמר הזה מסביר איך מאוחסנים הנתונים, מה זה "איסוף זבל" (Garbage Collection), מה זה Over Provision (בקיצור: OP) ומה היתרונות. המאמר קצת ישן וחלקו לא עדכני לגבי הטכנולוגיות כיום, אבל הוא מצליח להעביר את המידע בצורה קלה ולפיכך הוא מומלץ לקריאה ע"י כל איש IT/איש סיסטם ללא קשר למערכת ההפעלה.

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

תכנון ראשוני

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

הבהרה
לי אין קשר ל-Viewsonic או ליבואן ופוסט זה נכתב מהאספקטים של לינוקס, אבטחה וניהול יותר קל של Citrix Clients.

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

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

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

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

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

cf

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

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

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

cf2

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

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

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

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

מערכות משובצות: ללכת באופן מסודר

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

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

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

הדבר הראשון שיש למצוא הוא "מה צריך כח?". לדוגמא – אם הקופסא תשמש כנתב, אז רכיבי הרשת צריכים יחס מיוחד ואסור לסמוך על מה שיצרן ה-SoC נותן בצ'יפ. צריכים לטפל בתעבורה של 1 ג'יגהביט לדוגמא? כדאי וצריך לצייד את הלוח בצ'יפ רשת יעודי (עם שאר החלקים). דוגמא אחרת: צריכים ראיה ממוחשבת שתדע למצוא עצמים במהירות פריימים גבוה? אז אתם צריכים GPU חזק שמגיע ברוב המקרים יחד עם CPU חזק (כדאי לשים לב: במקרים כמו של מעבדי אינטל, לדוגמא סידרת Atom X3/X5/X7 – אתם תקבלו מעבד בהחלט חזק בהשוואה למעבדי ARM בינוניים, אבל בכל מה שקשור ל-GPU, כל מעבד ARM בינוני עם Mali 500 ומעלה עוקף אותו). עוד דוגמא היא עניין המצלמות: מצלמות סיניות פשוטות לא יעשו את העבודה, ומצלמות שמוציאות YUV (ושאר פורמטים קרובים) רק יקטינו את כמות הפריימים שתוכלו לעבד עם תוכנות ראיה ממוחשבת.

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

הדבר השני והחשוב הוא: לבנות את ה-Image בעצמכם ולא לסמוך על מה שמגיע עם המכשיר. במקרים רבים אתם יכולים לקבל ב-Image חלקים סגורים (קושחה, מודולים בינאריים, וכו'). בלינוקס במקרים רבים יש צורך לעיתים לעבור מגירסת ליבה אחת לגירסת ליבה שניה ולא תמיד מגיעים קבצי "דבק" שיודעים להתאים את המודולים הסגורים לעבוד עם גרסאות ליבה אחרות ולכו תבקשו עזרה מיצרן ציוד סיני שלא ממש מבין אנגלית…

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

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

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

גילוי נאות
כותב שורות אלו נותן שרותי אינטגרציה למערכות משובצות

עוד קצת על KVM

בעבר פרסמתי בבלוג זה פוסט שמסביר מעט על KVM ועל Open Stack. בשבוע שעבר ראיתי מקרה של חברה שהשקיעה כמה עשרות אלפי דולרים על פתרון קנייני שנותן פחות ממה ש-KVM נותן. מכיוון שאני מכיר את אותה חברה, שאלתי את מנהל ה-IT ואת ה-CTO מדוע הם רכשו, והתשובה לכך היתה שהם פשוט לא ידעו על היכולות הנ"ל של KVM (ולאותה חברה יש דווקא העדפה ברורה להכניס פתרון מבוסס קוד פתוח).

לכן בפוסט זה אני אדבר על KVM מחוץ ל-Scope של Open Stack.

הדבר הראשון שחשוב להבין לגבי KVM הוא שבניגוד לפתרונות וירטואליזציה אחרים, KVM אינו פתרון רק עבור X86/X86-64. טכנית, KVM מבוסס על אפליקציה שנקראת QEMU (שאגב, ממשיכה להיות מפותחת וגרסאות חדשות יוצאות תדיר, רק לפני 10 ימים יצאה גירסת RC3 לגירסה 2.3). היחוד של QEMU הוא שאפליקציה מאפשרת לך להריץ מערכות שונות על מעבדים שונים. הדוגמא הכי פשוטה וידועה היא הרצה של מערכת מבוססת ARM על PC (כפי שהיא קיימת באנדרואיד SDK), אבל אתה יכול להריץ גם מערכת Solaris של 64 ביט על אמולציה של מעבד Sparc (במקרה זה Niagra T1) על ה-PC שלך. אתה יכול להריץ גם מערכות שונות של MIPS (שוב, על ה-PC שלך דרך QEMU), ואפשר גם להריץ אפילו מערכת S390s עם Debian לדוגמא. גמישות היא הצד החזק של QEMU.

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

הדוגמא הכי פשוטה היא שימוש במעבדים שאינם X86-64, כמו ARM. בזמן הקרוב יצאו שרתים שמבוססים לא על מעבדי Xeon אלא על מעבדים של חברות שונות המבוססים ARM. אחת הפונקציות שחברות רבות רוצות הן וירטואליזציה על אותו מעבד ARM כדי להריץ מערכות הפעלה שונות (נכון, טכנולוגיית קונטיינרים קיימת גם ל-ARM אבל לפעמים יש צורך להריץ מערכת הפעלה עם Kernel שונה), במקרים כאלו ישנה גירסת KVM ל-ARM שרצה על ה"ברזל" ואיתה מריצים מערכות הפעלה אחרות שמבוססות ARM. גם למעבדי MIPS יש KVM.

מהצד היותר "גבוה" יש גירסת KVM למערכות הענקיות של IBM מסידרת System Z (ה-Main Frame), ושוב, גם כאן, ה-KVM נותן לך אפשרות להריץ מערכות לינוקס שונות כאשר כל אחת מהן עצמאית לחלוטין עם Kernel וספריות משלה.

אחד הדברים שאנשים רבים לא מודעים לכך, הוא ש-KVM אינו מתחרה ישירות בפתרונות וירטואליזציה מתחרות כמו vSphere או Hyper-V כפתרון מלא. KVM יכול לרוץ מתוך סקריפט Shell פשוט, וכל עוד יש איזה Image לעשות ממנו Boot (או PXE) וכרטיס רשת (אפשר להשתמש ב-Bridge) בצורה יפה, ללא צורך בניהול כלשהו. אם אתה לעומת זאת מחפש להריץ מספר מערכות KVM על שרת, אז כדאי להשתמש בשרות משלים שמבוסס על ספריה בשם libvirt עם אפליקציות כמו Virt-Manager ועם ספריה כמו libguestfs שמאפשרת לך לבצע פעולות שונות למכונה הוירטואלית ול"דיסק" שלה. ישנן עוד עשרות פתרונות פתוחים או סגורים לניהול מערכות KVM, אך KVM עצמו אינו תלוי בהן, כלומר KVM הוא רק כלי, ולא הפתרון כולו.

הנה נקודה שאולי תעניין אנשים שמתעניינים בהרצה של אפליקציות כבדות כמו פוטושופ, עריכת וידאו או הרצת משחקים: כשזה מגיע לוירטואליזציה ודימוי (Emulate) של כרטיס מסך, הפתרון של KVM הוא פתרון די גרוע בהשוואה לפתרונות כמו VirtualBox או VMWare Workstation או Hyper-V. יחד עם זאת, היתרון הגדול של KVM הוא האפשרות למפות כרטיס גרפי רציני ישירות ל-VM (זה קיים גם בפתרונות וירטואליזציה אחרים, אולם ב-ESXi לדוגמא המערכת לא מאפשרת להשתמש בכרטיסים גרפיים ביתיים למיפוי ל-VM אלא אך ורק את הכרטיסים הגרפיים היקרים), כך שאם לדוגמא יש לך 2 מסכים גדולים שאתה רוצה להריץ עליהם מעת לעת עריכה גרפית או משחק ב-2 מסכים, אתה יכול לחבר מסך שלישי זול לחיבור ה-On-board בלוח האם, ולמפות את הכרטיס הגרפי היותר יקר עם 2 המסכים שמחוברים אליו אל ה-VM. מבחינת ביצועים, ההפרש נמדד באחוזים בודדים בלבד, כך שתוכל להנות מביצועים מעולים, ולאחר שתסיים עם ה-VM, תוכל להמשיך ולהשתמש במסכים לעבודה עם הלינוקס (שימו לב, בשיטה זו ה-VM רץ רק כמסך מלא או מסכים מלאים, לא כ-Window). את אותו טריק, אגב, ניתן לבצע גם עם 2 מסכים בלבד כל עוד מסך אחד מחובר לעיבוד הגרפי שקיים בלוח האם והשני לכרטיס הגרפי העצמאי.

אינני ממליץ לחברות להסתכל על KVM כפתרון חלופי (במובן של Drop-In) למערכות כמו vSphere או Hyper-V. פתרון מבוסס KVM יכול להתאים למוסדות גדולים אם הם משתמשים ב-KVM יחד עם מערכת כמו Open Stack, או שיש להם אנשי לינוקס שיכתבו את הסקריפטים/קוד שידעו להתממשק ל-libvirt ושאר ספריות. KVM יכול בהחלט להריץ מערכות לינוקס ו-Windows Server בלי שום בעיה, אולם אם משווים את זה לפתרונות כמו vSphere, ישנם חלקים רבים מהפצת הלינוקס שאתה משתמש שתצטרך להטמיע אותם כדי לקבל פתרון קרוב וזו לא עבודה שאנשים עם נסיון מועט בלינוקס ידעו לבצע אותה. אם אתם רוצים להטמיע KVM בארגון שלכם, מומלץ להתחיל עם משהו פשוט (וזה לוקח זמן) ורק לאחר שאתם מרוצים, אפשר להתחיל לחשוב על הטמעה של יותר ויותר חלקים (וכן, אפשר להמיר די בקלות מכונות VM מבוססות ESXi ל-KVM. מכונות מבוססות Hyper-V – קצת יותר מסובך). אם אתם רוצים להטמיע פתרון מבוסס KVM ויותר מסחרי מרד-האט, אתם יכולים להסתכל על RHEV (ובגירסת קוד פתוח – oVirt). אם אתם בעניין של Hyper Converge, אז מומלץ להסתכל על הפתרון של חברת Scale Computing.

נקודה נוספת שהח"מ נשאל עליה שוב ושוב: VDI עם KVM. יש התקדמות בנושא (ובמיוחד בפרוטוקול העברת התצוגה SPICE) אבל עדיין – זה לא מתאים (לעניות דעתי) לפרודקשן.

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

הכנת VM מבוסס לינוקס לשימוש אצל ספקי ענן

חברות רבות משתמשות כיום בשרותיהן של ספקי ענן (אמזון, גוגל, Azure, Rack Space, Digital-Ocean ועוד) ובמקרים רבים אנשים מקימים לעצמם את השרתים בשיטה הקלאסית: בוחרים מערכת הפעלה מהתפריט שהספק מציע (או משתמשים ב-Image שהספק מציע), ולאחר מכן הם מבצעים כניסת SSH, ומשם הם ממשיכים להתקין חבילות, לבצע הגדרות, להעלות סקריפטים, להוסיף משתמשים וכו' וכו'.

שיטה זו היא שיטה מעולה – אם כל מה שיש לך זה שרת יחיד או כמות Fixed של שרתי VM. אחרי הכל, חברות רבות מעדיפות להקים מספר קבוע של X שרתים ועם זה הם יתמודדו, יגדירו Flow וכו'.

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

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

לכן, במקרים של Scale Up שהמערכת שתשתמשו תרים עוד ועוד שרתים בהתאם לקריטריונים של עומס – כדאי לתכנן מראש Image שתבנו שהוא יעלה, שימשוך הגדרות מסויימות ושיהיה זמין לקבל גולשים.

איך עושים זאת? די פשוט:

  • בשלב ראשון נשתמש במערכת וירטואליזציה שיש לנו מקומית. זה יכול להיות ESXi, זה יכול להיות VMWare לדסקטופ, זה יכול להיות VirtualBox או יכול להיות (ומה שהח"מ משתמש) KVM.
  • נקים Guest חדש ונשתמש ב-ISO של הפצת הלינוקס המועדפת עלינו. מבחינת גודל דיסק, לא מומלץ "להשתולל" (במיוחד לאלו שאינם יכולים להקים מכונה עם Thin Provisioning) – ברוב המקרים 8-10 ג'יגה אמורים להספיק בהחלט. מבחינת Partitions, כל אחד יכול להחליט באיזה שיטה ללכת, עם או בלי LVM. אני ממליץ לבצע Partition יחיד (flat) שהכל ישב שם. חשוב: מבחינת חבילות לא מומלץ להתקין GUI גרפי, זה סתם יתפוס מקום ומשאבים.
  • לאחר שסיימנו עם ההתקנה נפעיל את המכונה הוירטואלית, נתחבר אליה (ב-SSH) ונוודא שיש לה חיבור לאינטרנט.
  • בשלב הבא אנחנו צריכים להתקין את האפליקציות שאנחנו צריכים שיהיו ב-VM. אני ממליץ לבחור באחת מהפתרונות הבאים:
    • יש את Packer (שכתובה ב-Go – תודה לעמוס על התיקון) שאיתה אפשר לבנות את כל ההתקנה שאתם צריכים על ה-VM. היא מתאימה מאוד לחובבי JSON.
    • יש את Cloud-Init שכתבו קנוניקל ורד-האט "אימצה" בשמחה. היתרון שלו שהוא הרבה יותר ידידותי לאנשי סיסטם שלא מעוניינים להתעסק יותר מדי "בקרביים". עם Cloud-init מגדירים מה המשתמשים שיהיו, מה החבילות שצריך, וב-reboot הבא המערכת כבר תעשה את הכל לבד.
      שימו לב: את Cloud-init יש להתקין בתוך ה-VM. מכיוון שהוא נמצא ב-REPO של EPEL, יש לבצע yum install epel-release (לא צריך את ה-URL עם הגירסה האחרונה אם אתם משתמשים ב-CentOS, זה אוטומטי), ולאחר מכן yum install cloud-init.
    • אפשרי לעבוד עם Puppet – כל עוד אתה יודע לעבוד ללא Puppet Master.
    • חשוב מאוד – בצעו update לאחר שהתקנתם את מה שרציתם. המכונות שיבוססו על ה-image הזה ישרתו אנשים מבחוץ ולא נעים לחטוף פריצה רק בגלל ששכחנו לעדכן את כל ה-DEB/RPM.

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

  • כבו את המכונה הוירטואלית וגשו למחיצה שבה היא נמצאת.
  • התקינו את חבילת libguestfs בהתאם להפצת לינוקס שאתם משתמשים בה (מחוץ ל-VM)
  • מכיוון שיכול להיות שהמכונה כוללת דברים שאין לנו צורך בהם (מפתחות שונים שהשתמשנו כדי להעתיק ממקומות אחרים, תעודות SSL, קבצי מטמון וכו') נשתמש בפקודה virt-sysprep כדי לנקות את ה-Image. הריצו את הפקודה virt-sysprep -a image.vmdk (כאשר image.vmdk זהו שם ה-image של ה-VM שלכם). פעולת ה-virt-sysprep תנקה את כל מה שלא צריך וגם תמחק את כל ה-MAC Address שיש לכרטיסי רשת.

לפני שאנחנו מעלים את ה-image לענן, חשוב לבדוק שאתם מגדירים partitions ודברים נוספים (kernel modules, הגדרות שונות) לפי מה שהספק ענן שלכם מבקש, וכל ספק עם השטיקים שלו.

אם אתם משתמשים ב-Ravello (כדי לבצע testing, PoC):
אנחנו צריכים להקטין את ה-image לגודל קטן (מכיוון שהתקנות יוצרות קבצים זמניים שנמחקים, ה-image בעקרון אינו קטן בצורה אוטומטית). לשם כך נשתמש בפקודה virt-sparsify (שוב, לשים לב שהמכונת VM כבויה) בפורמט הבא:
virt-sparsify image.qcow2 final.qcow2
(שוב, image.qcow2 הוא שם המכונה שלכם כרגע, final.qcow2 זה השם image לאחר ההקטנה).

אם אתם משתמשים ב-Google Compute Engine
במקרה זה מומלץ לעקוב אחר ההוראות כאן כיצד להעלות את ה-image ומה מומלץ שיהיה בו.

אם אתם משתמשים בשרות של אמזון
במקרה של שרות באמזון, לצערי בשלב זה הם אינם מקבלים קבצי qcow2 ולכן תצטרכו להמיר את ה-image שלכם ל-VMDK (ההוראות הן כמו הקישור לעיל, רק שבמקום O qcow2- תצטרכו לכתוב
O vmdk- ).

כעת נוכל להשתמש ב-image שהעלינו כ-Template. מומלץ לשמור את ה-image היכן שהוא ולעדכן אותו אחת לתקופה ולהעלות אותו שוב (לאחר שעבר virt-sysprep) לענן ולהשתמש ב-image החדש כ-template.