תגית: IOPS

Got Silk?!

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

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

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

אפשר לראות שיש קשר ישיר בין גודל הדיסק ב GB וכמות ביצועי ה IOPS העומדת לרשותו. אפשר לראות בהערות גם שיש כמות ה CPU וכמות ה IOPS בגלל ששרתים עם יותר CPU יכולים לגבל הקצאת תקשורת נדיבה יותר, Network egress caps. משמעות הדברים היא שיתכנו מצבים בהם לקוחות צריכים לשלם על נפח דיסק ריק כדי לקבל יותר משאבי ביצועים ועל מעבדים מיותרים כדי לקבל יותר משאבי תקשורת אל הדיסקים.

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

אמזון קצת יותר מתוחכמים וקצת יותר קרובים למערכות All Flash של העשור האחרון כי הם אומרים ללקוחות שלא צריך לקנות עוד נפח בשביל ביצועים, אפשר לשלם ישירות על הביצועים. הם קוראים לזה Provisioned IOPS (io1), הלקוח במקרה הזה צריך לשלם פרמיה גם על הנפח וגם על הביצועים אבל לא צריך לשלם על "נפח ריק".

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

השימוש ב SDP מאפשר לנתק את הקשרים האלו. אנחנו מייצרים שכבת אבסטרקציה כפולה שמנתקת את נפח הדיסק שבסופו של דבר צריך להתאחסן איפשהו ובין ביצועי הדיסק שמסופקים משכבת ה Compute שלנו אל שכבת ה Compute של הלקוח. הניתוק הזה מאפשר להתחיל לחסוך בכסף כי כבר לא חייבים את הדיסקים המהירים ביותר ואנחנו מוסיפים לכך יכולות שרידות ברמת הפלטפורמה שלנו ככה שאפילו לא צריך דיסקים Persistent מתחת לפלטפורמה, דיסקי SSD נדיפים הם כל מה שנדרש.

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

כלי שימושי נוסף שאנחנו מאפשרים ללקוחות הוא סנפשוטים רזים. תהליך יצירת סנפשוט בענן הוא תהליך ארוך ויקר. ב AWS למשל, בתהליך יצירת הסנפשוט מועתק המידע אל S3 ובכל סנפשוט נוסף יש להעתיק מידע נוסף, את המידע החדש. אנחנו מאפשרים ליצור סנפשוטים מידיים, מבוססי הצבעות בלבד, כך שאין צורך להזיז מידע או לשלם על נפח מידע נוסף ולכל סנפשוט ניתן לייצר View כלומר להשתמש בסנפשוט כהעתק עצמאי של המידע לשרתים אחרים, test/dev או אנליטיקה וכו'.

אנחנו רואים בבמוצע חסכון של 3:1 בשימוש ביכולות חסכון בנפח ולפחות עוד 30% חסכון על ידי שימוש בThin Provisioning וזה אומר שרק על ידי זה שריכזנו את המידע של הלקוח והכלנו עליו את היכולות האלו, הלקוח צורך עכשיו פחות מרבע מהנפח שהוא צרך קודם ובגלל שאנחנו לא נסנכים על ביצועי הדיסקים של תשתית הענן הרבע הזה הוא בדיסקים זולים יותר מהדיסקים הקודמים!

בפעם הבאה נדבר קצת על ביצועים, בתקווה ועד אז אבין את זה מספיק טוב בעצמי 😊

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

עדכון לפוסט!

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

כבונוס, יש שם הדגמה של יכולות של blktrace. ביחד עם blkparse, btt ועוד סקריפט פייטון קטן (כן כן הרבה חלקים זזים) אפשר ממש להציג באופן קריא ונוח עד כמה ה IO שהשרת שלכם עושה הוא Sequential או Random, נתון שהרבה פעמים חסר לנו כשאנחנו באים לעשות סייזינג מסודר למערכות סטורג', אם אתם מאלו שעוד עושים כאלו דברים 🙂

credit AWS: https://youtu.be/wsMWANWNoqQ
credit AWS: https://youtu.be/wsMWANWNoqQ

כמו תמיד אשמח מאד לשמוע מכם!

שלכם,

ניר מליק

Data mobility – Mark Watney, Homeland security and Dolores Abernathy

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

עם 32 דקות דיליי בתקשורת ויכולת לענות על שאלות כן ולא בלבד, כמות המידע שניתן להעביר ולצבור קטנה מאד.

rurecieving

קרדיט תמלול

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

השבוע אני במרתון של העונה השנייה של ווסטוורלד. לדעתי הסדרה היא יצירת מופת ואני מאד מקווה שהיא לא תלך לאיבוד כמו שקרה לסדרה אבודים בזמנו. פתאום, באמצע פרק 4, זה קפץ לי לראש, הקשר בין מט דיימון, זיהוי פנים ודולורס היפה. צוות ה IT של דלוס לא דאגו לגיבוי Off Site כמו שצריך ובעצם כל עלילת העונה השנייה מתאפשרת רק בגלל שהם דחפו את כל המידע הקריטי שלהם אל הראש של אבא של דולורס, Old man Peter Abernathy, זו הסיבה היחידה שבעצם QA לא מכסחים את כל האתר בכוח (מעניין שדווקא QA הם כוח השיטור והאכיפה).

אחד האתגרים הכי גדולים בעולם ה IT היום הוא Data Mobility. הפיזיקה ולמעשה גם הגיאוגרפיה עדיין מערימות קשיים על היכול להזיז מידע בין נקודת היצירה שלו, נקודת העיבוד שלו ונקודת הצריכה שלו. בעולם ה IoT יש ניסיון להעביר לפחות חלק ממשימות העיבוד אל הקצה, אל המצלמות\רגשים עצמם כדי להתגבר על הצורך להעביר מידע מעשרות, מאות ולפעמים אלפי נקודות קצה אל מערכת מרכזית. בעולם מחשוב הענן לעומת זאת, הבעיה של Data Mobility הפתיעה חלק מהמשתמשים. נראה שבראשית ימי הענן אף אחד לא חשב שיום אחד יהיה צורך לצאת מהענן או לעבור בין ענן אחד לשני או אפילו, כמו שהזכרתי בנוגע למערכת זיהוי הפנים, לבצע תהליך שכולל שלושה ספקי ענן שונים בו זמנית.

כשאנחנו מתחברים אל מערכת הניהול שלנו באמזון למשל, אנחנו יכולים להקים כמה עשרות שרתים כמה קליקים של עכבר. בעולמות של קונטיינרים אנחנו יודעים להרים כמה אלפי קונטיינרים בכמה שורות פקודה. מחשוב, Compute, בענן זה בדרך כלל באמת קל וזריז כמו שמספרים לנו. אבל מידע זה אחרת. כמה זמן ייקח להעביר 10 טרה אל הסביבה שהקמת באמזון? כמה זמן ייקח להעביר 100 טרה? כמה זמן ייקח להעביר פטה? כמה יעלה לכם להעביר 350 טרה מאמזון אל גוגל? כמה יעלה לכם להעביר 200 טרה מאז'ור אל חדר השרתים שלכם בחזרה? אתם יודעים בכלל איך לעשות זה?

INFINIDAT Neutrix

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

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

AWS SLA

ואותו הדבר גם ב Azure:

azure sla

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

aws latency

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

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

grego

שלכם כרגיל,

ניר מליק