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

כל מי שקונה או קנה אכסון בוודאי שמע על המושגים “שכבה קרה” ו-“שכבה חמה”. למי שאינו מכיר את המושגים: “שכבה קרה” מציינת אחסון על דיסקים מכניים איטיים או רגילים (SATA לדוגמא) ואילו ה”שכבה חמה” מציינת אחסון על דיסקים SSD.

בעבר, פתרונות אחסון של חברות כמו NetApp ו-EMC כללו בתוכן מספר שכבות:

  • שכבה מאוד מהירה – שהיתה מורכבת ממקלות זכרון בלתי נדיף (NVRAM)
  • בחלק קטן מהמקרים, שכבה מהירה נוספת – RAM מגובה סוללה
  • שכבת דיסקים SSD (“שכבה חמה”)
  • שכבת דיסקים מכניים (SAS או SATA) (“שכבה קרה”

עם התפתחויות הטכנולוגיות השונות, כמעט כל היצרנים ירדו משימוש ב-NVRAM (זה יקר מאוד ליצרן הפתרון אחסון, מה שכמובן מייקר את הפתרון ללקוח הסופי ומה שמקשה בתחרות מול יצרנים אחרים), וכיום בד”כ פתרונות אחסון משולבים (דיסקים מכניים ו-SSD) כוללים שכבה חמה קטנה שמורכבת מדיסקים SSD ושאר הדיסקים הם מכניים (כיום רוב היצרנים פשוט מכניסים דיסקים SATA, חלקם עדיין מוכר דיסקים SAS), כך שבסופו של דבר, כלקוח, כל היצרנים יציעו בפניך שתי אפשרויות (עם כל מיני תוספים כמובן): מערכת אחסון “היברידית” (מכנית, SSD) או AFA (כלומר All Flash Array) שמורכבת מדיסקים SSD. משהו חדש שנכנס לשוק (ולא ראיתי עדיין אותו בארץ) הוא “היבריד SSD” (שם שאני נותן עבור פוסט זה) כאשר רוב הדיסקים הם SSD Read Intence ומספר קטן של SSD הוא NVME Mixed Intense. לחברת לנובו יש מערכת שה-SSD Mixed Intense מוחלף בדיסקים Optane של אינטל, כדי לקבל מהירויות כתיבה גבוהות (אבל אותו סטורג’ ספציפי יקר מאוד – הוא מתחיל ב-7 ספרות בדולרים).

כעת נתמקד במה שנקרא בחלק מהמקרים “שכבת ה-Cache”. בעבר (ועדיין בחלק מהמקרים כיום) פתרון האחסון היה כולל מספר מצומצם של דיסקים SSD די קטנים (200-400 ג’יגהבייט), מטרתם היתה אחת: לקבל את כל המידע שאמור להיכתב לתוך פתרון האחסון, לאשר ל-client שהמידע נכתב (מה שנקרא sync) וברקע להעביר את המידע לדיסקים המכניים שמטבע הדברים הם איטיים בהרבה מאותם SSD. ה-SSD שהיו אז היו דיסקים קטנים ויקרים להחריד, הואיל ותאי ה-Flash שלהם הכילו מקסימום מספר אחד בכל תא (מה שנקרא Single Level Cell, או SLC), כיום רוב מוחלט של הדיסקים מכיל Flash עם תאים שיכולים להכיל שני מספרים בכל תא (MLC) או שלושה מספרים בכל תא (TLC). הכלל הפשוט הוא שככל שמאחסנים יותר מספרים בתא, הכתיבה את התא (ובעצם אל שבבי ה-Flash ב-SSD) יותר איטיים, ולכן – כאשר חושבים לרכוש פתרון אחסון ומקבלים מפרט, חשוב מאוד לשאול מה סוג התאים ב-SSD: האם הם MLC (ונגזרותיו, בכולן מופיעות האותיות MLC) או TLC או QLC (שזה הכי איטי ולמעט ארכיבאות אני לא ממליץ אותו לשום פתרון אחסון). לא תמיד אפשר לדעת זאת הואיל וכל יצרן פתרון אחסון נותן שמות אחרים ל-SSD מהשמות שהיצרן SSD נותן למוצריו, ולכן צריך “לדוג” קצת. אפשרות אחרת לדעת – היא לבדוק האם ה-SSD הוא Read Intense או Mixed Intense (ה-Mixed Intense מתאים לעבודות שכמות הקריאה והכתיבה די שווה, ולכן הוא אידיאלי לשמש כ-Cache בפתרון אחסון). הטובים ביותר הם MLC או Mixed Intense.

זוכרים את הדיסקים הקטנים מהפיסקה הקודמת? איתם קשה לבנות Cache אלא אם רוצים לשרוף כספים כאילו אין מחר. כיום לעומת זאת, דיסקים שהם Mixed Intense שהם מעולים לצרכי Cache – יכולים לתת ביצועים מעולים לא רק בכתיבת ה-DATA מבחוץ אל תוך פתרון האחסון, אלא גם לשמש כ-“שכבה חמה”. חישבו על כך: 4 דיסקים SSD בתצורת Mixed Intense בגודל 4 טרהבייט פר דיסק יתנו לנו 16 טרהבייט נטו של “שכבה חמה” (הדיסקים הללו מוגדרים בחיבור כ-RAID-0 הואיל וכל הנתונים שנמצאים שם – זמניים, ה-DATA כולו מאוחסן בשאר הדיסקים שאינם מוגדרים כ-Cache), ועם כמות כזו של Cache (שבעצם משמש כ”שכבה חמה”) רוב הקריאות נתונים לדוגמא יקראו מאותם רביעיית SSD, ומכיוון שאלו דיסקים בחיבור NVME, אנחנו יכולים לקבל מהירות קריאה של 12-14 ג’יגהבייט לשניה (תיאורתית, צוואר הבקבוק שלכם במקרים כאלו יהיו הסיבים או כל סוג חיבור אחר, לא הדיסקים).

לכן, כיום, אם מישהו רוצה לפתרון האחסון שלו “שכבה חמה”, והוא רוכש אחסון היברידי (מכניים ו-SSD), הוא צריך לוודא כי ישנם מספר SSD שהם Mixed Intense ואם אפשר – בחיבור NVME. אל תרכשו דיסקים SSD גדולים לצרכים כאלו (8-10 טרהבייט ומעלה) מכיוון שהם מאוד יקרים. עדיף לרכוש 4 של 4 מאשר 2 של 8 טרהבייט ושכל אותם SSD בפתרון ההיברדי מוגדרים כ-Cache (זה מה שיוגדר כברירת מחדל במערכת פתרון האחסון). במערכות AFA אין צורך בכך הואיל וגם SSD בחיבור SATA יתן מהירויות קריאה מהירות מאוד ובכך פתרון זה מייתר את הצורך ב”שכבה חמה”. אגב, AFA שכולו מלא ב-SSD עם NVME יהיה תמיד “חנוק” מבחינת רוחב פס החוצה אלא אם יש Backbone של 100 ג’יגהביט ומעלה.

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

על 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 ולהפעיל אותה מחדש).

נקודות למחשבה לסטארטאפיסט

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

רוב הסטארט-אפים צריכים להקים תשתית כדי למכור את המוצר/שרותים. חלק יקימו תשתית בארץ (אם זה מוצר ללקוחות ישראלים) וחלק יקימו בארה”ב (לדעתי שגיאה קלאסית שתיכף אסביר מדוע). מכיוון שרוב הסטארט-אפים צריכים לעבור מסלול זה או אחר להקים תשתית של שרתים, אפליקציות וכו’, החלטתי לתת מספר טיפים מתוך נסיון עשיר (15 שנה, המונה דופק) בנושא. הפוסט עצמו הוא פוסט גנרי. זה נחמד אם היית לוקח מאיתנו שרת VPS (כזה, או כזה או כזה), אבל זו לא המטרה של הפוסט ואפשר לעשות את הדברים שאכתוב עליהם אצל כל ספק רציני (רציני – לא אחד שמוכר וירטואליזציה של Virtuozzo כ”מחשוב ענן”!).

הפוסט מיועד לאנשים טכנולוגיים ולאנשי IT שמקימים את התשתית, ולא כל כך מתאים לאנשים שלא מכירים את המושגים.

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

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

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

לכן, כשמתחילים צריך לקחת שרת וירטואלי (עדיין לא יעודי, המחיר של יעודי יקפיץ בעוד כמה מאות דולרים לחודש) טוב עם ליבה אחת (מומלץ 2 אם אפשרי מבחינת תקציב) וזכרון של לפחות 1-2 ג’יגה (אם מדובר בשרת Linux) או 2-3 ג’יגה (אם מדובר בשרת Windows. מה לעשות, Windows שותה זכרון עם צינור). מבחינת רוחב פס, ודא כי הספק נותן לך לפחות 5-10 מגהביט סימטרי (לא “מתפרץ”, שזה בעצם טריק שיווקי למכור שליש מוצר במחיר של מוצר) ומתחייב על כך בחוזה. מבחינת דיסק, כדאי שיהיו כמה עשרות ג’יגהבייט בתור התחלה. ודא שיש לך אפשרות לקבל קונסולה אם במקרה נעלת את עצמך בטעות (כמו במקרה של טעות בהגדרות SSH או חוק שגוי בחומת האש הפנימית) מבלי להתחנן לתמיכה שיפתחו לך.

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

אז, איך בעצם עם שרת כזה נותנים שרות למאות ואלפים? נלך לפי מספר נקודות:

  • Cache חובה: לא חשוב כמה האתרים שלכם דינמי, חלקים רבים בתוכו הם סטטיים – תמונות, סקריפטים, תכנים, דף פתיחה ועוד, וכל החלקים האלו אפשר ליצור להם קבצים סטטיים שיוגשו לגולש ואפליקציית Cache תייצר אותן תוך מעקב מה בתוקף ומה לא. אם אתם משתמשים באפליקציות CMS, אז ברוב המקרים זה רק עניין של התקנת תוסף פשוט שיתן לכם את זה. שימוש חכם ב-Cache יכול לחסוך את רוב העבודה שהשרת צריך לעשות כדי לתת תכנים מותאמים לגולש.
  • אופטימיזציית SQL – זה משהו אחד שיש לך 2 שרתי SQL מאסיביים שרצים עם סינכרון/רפליקציות עם תקציב שנתי רצינית, וזה משהו אחר שאתה סטארט אפ ויש לך תקציב ששווה לתקציב הקופה-הקטנה של גוגל. שרת ה-SQL שלך צריך לעבוד בצורה אופטימלית וחזקה. אם אתה משתמש לדוגמא ב-MySQL, אז יש כאן לדוגמא מדריך איך לעשות זאת, וכל שרת SQL מכובד כולל אתר שלם איך לעשות אופטימיזציות, החל בבחירת מנוע נכון (InnoDB, MyISAM וכו’), הגדרת כמות חיבורים בהתאם לכמות הזכרון והצורך, ועד ל-Queries בלתי אופטימליים (דבר שגורם “מריבות” בין מפתחים שונים, גם את זה ראיתי).
  • שרת WEB טוב: הנה עובדה – שרת Apache על VPS כמו שפירטתי מקודם שמוגדר טוב (עם כל ה-MPM, מודולים וכו’) יכול לשרת כמה אלפי אנשים סימולטנית מבלי לחנוק את הליבה של ה-VPS ומבלי לגרום ל-Load היסטרי. גם שרת NGINX יכול לבצע את העבודה הזו מבלי לחנוק משאבים, כל מה שצריך זה תכנון ובדיקה (לא חסרים כלים להעמיס שרתים). אם פעם אחת יושבים ומגדירים את זה בצורה טובה, אז יהיו לכם לילות ללא יקיצה בגלל שרת קורס. חשוב להגדיר בשרת Cache לדברים שלא הולכים להשתנות כל דקה (לדוגמא: קבצי Header ו-Footer).
  • אבטחה: יודעים מי ינסה לבדוק כמה האתר שלכם מאובטח? המתחרים שלכם, ובמקרים רבים המתחרים שלכם מכאן בארץ. חושבים שלא ינסו לבדוק SQL Injection וכל חור אפשרי? הם בהחלט ינסו, כי זו השיטה הכי טובה לגלות סודות מסחריים שלכם (במיוחד דפים וקבצים נסתרים שמיועדים ללקוחות Beta סגור). לכן כדאי לבדוק את כל הרכיבים כולל אלו שלא תהיה להם גישה מבחוץ. נסו לסרוק את השרת שלכם עם nmap, או SNORT (לא, הוא עוד לא מת) וכלים אחרים, חפשו כלים אחרים, בדקו XSS, נסו לבצע SQL Injection ותקנו את כל החורים.
  • עבדו עם גירסאות יציבות של מערכות הפעלה. ב-Windows זה Non issue, משתמשים ב-2008 R2, בלינוקס לעומת זאת מומלץ שלא להשתמש בגרסאות שמשתנות כל הזמן כמו Ubuntu הרגיל (קח את Ubuntu LTS) או Fedora (קחו CentOS 6 או Scientific Linux 6.1) והקפידו להריץ עדכון לפחות אחת לשבוע.
  • צרו גיבוי מרוחק – כל ספק יכול להבטיח שהגיבוי שלו סוף הדרך, שזה נחמד, אבל עדיף שיהיה לכם לפחות אחת לחודש גיבוי של האתר וה-DB אצלכם בידיים או בשרת מרוחק אחר (זה לא מסובך: mysqldump לבסיס הנתונים, rsync לשאר, להריץ הכל ב-cron ונגמר העניין).

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

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

רק הצלחה!

Exit mobile version