מדדי אחסון אובייקטים חדשים

מבצר מעופף מאת נלה-דיאל

פקודת אחסון אובייקט S3 אחסון בענן של Mail.ru תרגם מאמר על אילו קריטריונים חשובים בבחירת אחסון חפצים. להלן הטקסט מנקודת מבטו של המחבר.

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

בעת בחירת אחסון חפצים, עליך לשים לב לחמישה מאפיינים:

• הביצועים;
• מדרגיות;
• תואם S3;
• תגובה לכשלים;
• יושרה.

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

פרודוקטיביות

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

מערכות אחסון שונות מתקרבות או אפילו עולות על המהירות של Hadoop. דרישות מודרניות למהירויות קריאה וכתיבה: מ-10 GB/s עבור כוננים קשיחים, עד 35 GB/s עבור NVMe. 

תפוקה זו מספיקה עבור Spark, Presto, Tensorflow, Teradata, Vertica, Splunk ומסגרות מחשוב מודרניות אחרות בערימת האנליטיקה. העובדה שמסדי נתונים של MPP מוגדרים לאחסון אובייקטים מעידה על כך שהוא משמש יותר ויותר כאחסון הראשי.

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

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

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

מדרגיות

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

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

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

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

מאפיינים של גישה מודרנית לריבוי לקוחות:

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

תואם S3

ה-API של Amazon S3 הוא התקן דה פקטו לאחסון אובייקטים. כל ספק תוכנת אחסון אובייקטים טוען לתאימות איתה. התאימות עם S3 היא בינארית: או שהיא מיושמת במלואה או שלא.

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

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

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

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

ועוד כמה הערות על קוד פתוח ו-S3. 

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

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

לבסוף, הטמעת S3 חייבת לתמוך בממשקי ההצפנה של Amazon S3 בצד השרת: SSE-C, SSE-S3, SSE-KMS. אפילו טוב יותר, S3 תומך בהגנה מפני חבלה שהיא מאובטחת באמת. 

תגובה לכשלים

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

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

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

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

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

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

עֲקֵבִיוּת

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

מה הכוונה בעקביות קפדנית? עבור כל הפעולות לאחר פעולת PUT מאושרת, הפעולות הבאות חייבות להתרחש:

• הערך המעודכן גלוי בעת קריאה מכל צומת.
• העדכון מוגן מפני יתירות של כשל בצומת.

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

מסקנה

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

אודות אחסון אובייקטים של Mail.ru Cloud Solutions: ארכיטקטורת S3. 3 שנים של אבולוציה של Mail.ru Cloud Storage.

מה עוד לקרוא:

1. דוגמה לאפליקציה מונעת אירועים המבוססת על webhooks באחסון אובייקטים S3 Mail.ru Cloud Solutions.
2. יותר מ-Ceph: אחסון בלוק ענן של MCS 
3. עבודה עם Mail.ru Cloud Solutions S3 אחסון אובייקטים כמערכת קבצים.
4. ערוץ הטלגרם שלנו עם חדשות על עדכונים לאחסון S3 ומוצרים אחרים. 

מקור: www.habr.com