איך לבחור אחסון מבלי לירות לעצמך ברגל

מבוא

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

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

בשביל מה

לעתים קרובות אתה יכול לראות מצב שבו אדם חדש מגיע לפורום או לצ'אט מיוחד, כמו Storage Discussions, ושואל את השאלה: "כאן הם מציעים לי שתי אפשרויות אחסון - ABC SuperStorage S600 ו-XYZ HyperOcean 666v4, מה אתה ממליץ ?"

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

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

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

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

נתונים

סוג נתונים

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

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

נפח נתונים

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

מצד שני, למה לטרוח אם אתה צריך לאחסן ולעבד 500 GB של נתונים? רק 500. כונני SSD ביתיים (עם DWPD נמוך) בגודל הזה לא עולים כלום. למה לבנות מפעל Fibre Channel ולקנות מערכות אחסון חיצוניות יוקרתיות שעולות שווה ערך לגשר ברזל יצוק?

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

IP

הצד השני של הנתונים הוא מערכת המידע שמשתמשת בנתונים. ל-IS יש קבוצה של דרישות שיורשות נתונים. למידע נוסף על ה-IS, ראה "עיצוב מרכזי נתונים וירטואליים".

דרישות גמישות/זמינות

דרישות לסובלנות תקלות / זמינות נתונים עוברות בירושה מ-IS המשתמש בהן ומבוטאות בשלושה מספרים - RPO, RTO, הזמינות.

זמינות - הנתח לפרק זמן נתון שבמהלכו נתונים זמינים לעבודה איתם. מבוטא בדרך כלל כמספר של 9. לדוגמה, שתי תשע בשנה פירושה שהזמינות היא 99%, או אחרת מותרות 95 שעות של חוסר זמינות בשנה. שלוש תשע - 9,5 שעות בשנה.

RPO / RTO אינם אינדיקטורים מוחלטים, אלא לכל אירוע (תאונה), בניגוד לזמינות.

RPO - כמות הנתונים שאבדו במהלך תאונה (בשעות). לדוגמה, אם גיבויים מתרחשים פעם ביום, אז RPO = 24 שעות. הָהֵן. במקרה של תאונה ואובדן מוחלט של מערכת האחסון, נתונים עד 24 שעות עלולים ללכת לאיבוד (מרגע הגיבוי). בהתבסס על ה-RPO שצוין עבור ה-IS, למשל, נכתבות תקנות גיבוי. כמו כן, בהתבסס על RPO, אתה יכול להבין כמה יש צורך בשכפול נתונים סינכרוני/אסינכרוני.

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

דרישות ביצועים

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

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

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

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

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

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

דרישות מיוחדות

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

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

שם

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

לקוח

למי מתוכננת מערכת האחסון הזו? לשאלה יש את הסיבות הבאות:

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

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

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

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

איפה פיזית

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

הצוות

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

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

הסביבה

וכמובן, שאלה חשובה היא באיזו סביבה תפעל מערכת האחסון הזו.

• מה לגבי אספקת חשמל/קירור?
• איזה חיבור
• איפה זה יותקן?
• וכו.

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

כי

מוֹכֵר

נכון להיום (אמצע 2019), ניתן לחלק את שוק האחסון הרוסי ל-5 קטגוריות:

1. החטיבה הגבוהה ביותר היא חברות מבוססות עם מגוון רחב של מדפי דיסקים מהפשוטים ביותר ועד היי-אנד (HPE, DellEMC, Hitachi, NetApp, IBM / Lenovo)
2. חטיבה שנייה - חברות עם קו מוגבל, שחקני נישה, ספקי SDS רציניים או עולים חדשים (Fujitsu, Datacore, Infinidat, Huawei, Pure וכו')
3. חטיבה שלישית - פתרונות נישה בדרג הנמוך, SDS זול, מוצרים מתקדמים המבוססים על ceph ופרויקטים פתוחים נוספים (Infortrend, Starwind וכו')
4. מגזר SOHO - מערכות אחסון קטנות וקטנות במיוחד ברמת בית/משרד קטן (Synology, QNAP וכו')
5. מערכות אחסון מוחלפות ביבוא - זה כולל גם חומרה של החטיבה הראשונה עם תוויות מתויגות מחדש וגם נציגים נדירים של השנייה (RAIDIX, ניתן להם את השנייה מראש), אבל בעיקר זו החטיבה השלישית (Aerodisk, באום, דפו וכו')

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

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

לא צריך לייצר ישויות מעבר למה שצריך.

iSCSI/FC/File

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

FCoE יותר מת מאשר חי.

FC מול iSCSI. אחד היתרונות המרכזיים של FC בשנת 2019 על פני אחסון IP, מפעל ייעודי לגישה לנתונים, מקוזז על ידי רשת IP ייעודית. ל-FC אין יתרונות גלובליים על פני רשתות IP, וניתן להשתמש ב-IP לבניית מערכות אחסון בכל רמת עומס, עד למערכות ל-DBMS כבד עבור מערכת הליבה הבנקאית של בנק גדול. מצד שני, מותו של FC ניבא כבר כמה שנים, אבל משהו כל הזמן מונע זאת. כיום, למשל, חלק מהשחקנים בשוק האחסון מפתחים באופן פעיל את תקן NVMEoF. אם הוא יחלוק את גורלו של FCoE - הזמן יגיד.

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

מערך היבריד / הכל פלאש

מערכות אחסון קלאסיות מגיעות בשני סוגים:

1. AFA (All Flash Array) - מערכות מותאמות לשימוש ב-SSD.
2. Hybrid - מאפשר לך להשתמש גם ב- HDD וגם ב-SSD או בשילוב שלהם.

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

מערכות אחסון מיוחדות

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

כְּלֵי תִקְשׁוֹרֶת.

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

ביטול כפילות של מערכות אחסון לגיבויים.

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

מערכות אחסון חפצים.

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

מערכת ציות.

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

טכנולוגיות קנייניות

מטמון פלאש

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

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

ישנם שני יישומי מטמון פלאש זמינים בשוק:

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

דרגות

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

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

תמונת בזק

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

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

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

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

צילומי מצב הם גם משני סוגים ביחס ליישומים:

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

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

מדוע נחוצות צילומי מצב במערכות אחסון?

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

שיבוט

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

שכפול / רישום יומן

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

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

שכפול מתחלק לשני תת-סוגים:

סינכרוני. במקרה של שכפול סינכרוני, פעולת הכתיבה נשלחת למערכת האחסון השנייה באופן מיידי והביצוע אינו מאושר עד לאישור מערכת האחסון המרוחקת. בשל כך, עיכוב הגישה גדל, אך יש לנו עותק מראה מדויק של הנתונים. הָהֵן. RPO = 0 במקרה של אובדן מערכת האחסון הראשית.

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

לעתים קרובות, יחד עם שכפול, יש מנגנון רישום פעולות דיסק. במקרה זה, אזור מיוחד מוקצה לרישום ורישום פעולות בעומק מסוים בזמן, או מוגבל על ידי נפח היומן, מאוחסנים. עבור טכנולוגיות קנייניות מסוימות, כגון EMC RecoverPoint, יש אינטגרציה עם תוכנת מערכת המאפשרת לך לקשר סימניות מסוימות לערך יומן ספציפי. הודות לכך, אפשר להחזיר לאחור את המצב של נפח (או ליצור שיבוט) לא רק ל-23 באפריל, 11 שעות 59 שניות 13 מילישניות, אלא לרגע שלפני "DROP ALL TABLES; לְבַצֵעַ."

אשכול מטרו

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

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

• אוטומציה מלאה של תהליך השחזור לאחר מותו של אחד ממרכזי הנתונים. ללא כל כספים נוספים, כל ה-VMs הפועלים במרכז הנתונים שנפטר יופעלו מחדש באופן אוטומטי במרכז הנותר. RTO = זמן קצוב של אשכול זמינות גבוה (15 שניות עבור VMware) + זמן לטעינת מערכת ההפעלה ולהתחיל שירותים.
• הימנעות מאסון או, ברוסית, הימנעות מאסונות. אם מתוכננת עבודת אספקת חשמל ב-Data Center 1, אז יש לנו הזדמנות להעביר את כל העומס החשוב ל-Data Center 2 ללא הפסקה מראש, לפני תחילת העבודה.

וירטואליזציה

וירטואליזציה של אחסון היא מבחינה טכנית שימוש בנפחים ממערכת אחסון אחרת כדיסקים. וירטואליזר אחסון יכול פשוט להעביר נפח של מישהו אחר לצרכן כשלו, בו זמנית לשקף אותו למערכת אחסון אחרת, או אפילו ליצור RAID מנפחים חיצוניים.
נציגים קלאסיים במחלקת וירטואליזציה של אחסון הם EMC VPLEX ו-IBM SVC. וכמובן, מערכות אחסון עם פונקציונליות וירטואליזציה - NetApp, Hitachi, IBM / Lenovo Storwize.

מדוע ייתכן שיהיה צורך בכך?

• יתירות ברמת מערכת האחסון. נוצרת מראה בין אמצעי האחסון, וחצי אחד יכול להיות ב-HP 3Par, והשני ב-NetApp. והווירטואליזר הוא מ-EMC.
• העבר נתונים בזמן השבתה מינימלי בין מערכות אחסון מיצרנים שונים. הבה נניח שצריך להעביר נתונים מה-3Par הישן, שיימחק, ל-Dell החדשה. במקרה זה, הצרכנים מנותקים מ-3Par, הנפחים מועברים תחת VPLEX ומוצגים שוב לצרכנים. מכיוון שלא השתנה מעט בווליום, העבודה נמשכת. תהליך שיקוף הווליום ל-Dell החדשה מתחיל ברקע, ובסיומו, המראה נשברת ו-3Par מושבת.
• ארגון מטרוקלוסיות.

דחיסה/ביטול כפילות

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

ישנם 2 סוגים של דחיסה ומניעת כפילות:

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

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

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

דגם

וכאן הגענו לשאלה הנכונה.

"הם מציעים לי שתי אפשרויות אחסון - ABC SuperStorage S600 ו-XYZ HyperOcean 666v4, מה אתה ממליץ?"

הופך ל"כאן הם מציעים לי שתי אפשרויות אחסון - ABC SuperStorage S600 ו-XYZ HyperOcean 666v4, מה אתה ממליץ?

עומס היעד הוא מכונות VMware וירטואליות מעורבות עם לולאות ייצור/בדיקה/פיתוח. מבחן = פרודוקטיבי. 150 TB כל אחד עם ביצועי שיא של 80 IOPS 000kb בלוק 8% גישה אקראית 50/80 קריאה-כתיבה. 20 TB לפיתוח, 300 IOPS מספיקים, 50 אקראי, 000 כתיבה.

פרודוקטיביות ככל הנראה במטרוקלוסטר RPO = 15 דקות RTO = שעה, פיתוח בשכפול אסינכרוני RPO = 1 שעות, בדיקה באתר אחד.

יהיה DBMS של 50TB, רישום יהיה נחמד עבורם.

יש לנו שרתי Dell בכל מקום, מערכות אחסון ישנות של Hitachi, הם בקושי יכולים להתמודד, אנחנו מתכננים להגדיל את העומס ב-50% מבחינת נפח וביצועים".

כמו שאומרים, שאלה מנוסחת נכון מכילה 80% מהתשובה.

מידע נוסף

מה כדאי לקרוא בנוסף לפי המחברים

Книги

• אוליפר ואוליפר "רשתות מחשבים". הספר יסייע לשיטתיות ואולי להבין טוב יותר כיצד פועל מדיום העברת הנתונים עבור מערכות אחסון IP / Ethernet
• "אחסון וניהול מידע של EMC." ספר מצוין על היסודות של מערכות אחסון, למה, איך ולמה.

פורומים וצ'אטים

• דיוני אחסון
• Nutanix / IT Russian Discussion Club
• VMware User Group רוסיה
• קבוצת משתמשי גיבוי רוסית

המלצות כלליות

מחירים

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

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

בסך הכל

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

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

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

מקור: www.habr.com