כיצד לדחוס אחסון של גיבויים באחסון אובייקטים עד 90%

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

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

משימה: לעשות הכל כך שתהליך אחסון עותקי הגיבוי יהיה מהיר וזול.

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

התמונה מראה למה הגענו:

כפי שניתן לראות, הגיבוי הראשון נעשה באיטיות (70 Mb/s), והגיבויים הבאים של אותן מערכות היו הרבה יותר מהירים.

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

יומני גיבוי למי שמוכן לקרוא חצי עמוד של dumpמלא עם סריקה מחדש
18 בדצמבר 2018 12:09:43 PM — מידע bpbkar (pid=4452) מאיץ שלח 14883996160 בתים מתוך 14883994624 בתים לשרת, אופטימיזציה 0.0%
18 בדצמבר 2018 12:10:07 - מידע NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Report=PDDO סטטיסטיקות (בשימוש בזרם מרובה הליכי) עבור (NBCC): סרוק: 14570817 KB, CR נשלח: 1760761 KB, CR נשלח על FC: 0 KB, ביטול תצוגה: 87.9%, מטמון מושבת

מלא
18 בדצמבר 2018 12:13:18 PM — מידע bpbkar (pid=2864) מאיץ שלח 181675008 בתים מתוך 14884060160 בתים לשרת, אופטימיזציה 98.8%
18 בדצמבר 2018 12:13:40 PM - מידע NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; דוח=PDDO סטטיסטיקות עבור (NBCC): סרוק: 14569706 KB, CR נשלח: 45145 KB, CR נשלח על FC: 0 KB, ביטול תצוגה: 99.7%, מטמון מושבת

מצטבר
18 בדצמבר 2018 12:15:32 PM — מידע bpbkar (pid=792) מאיץ שלח 9970688 בתים מתוך 14726108160 בתים לשרת, אופטימיזציה 99.9%
18 בדצמבר 2018 12:15:53 PM - מידע NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; דוח=PDDO סטטיסטיקות עבור (NBCC): סרוק: 14383788 KB, CR נשלח: 15700 KB, CR נשלח על FC: 0 KB, ביטול תצוגה: 99.9%, מטמון מושבת

מלא
18 בדצמבר 2018 12:18:02 PM — מידע bpbkar (pid=3496) מאיץ שלח 171746816 בתים מתוך 14884093952 בתים לשרת, אופטימיזציה 98.8%
18 בדצמבר 2018 12:18:24 PM - מידע NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; דוח=PDDO סטטיסטיקות עבור (NBCC): סרוק: 14569739 KB, CR נשלח: 34120 KB, CR נשלח על FC: 0 KB, ביטול תצוגה: 99.8%, מטמון מושבת

מה הבעיה

לקוחות רוצים לבצע גיבויים לעתים קרובות ככל האפשר ולאחסן אותם בזול ככל האפשר. עדיף לאחסן אותם בזול במחסני אובייקטים כמו S3, כי הם הכי זולים במחיר השירות למגה-בייט משם אפשר להחזיר גיבוי בזמן סביר. כאשר יש הרבה גיבוי, זה הופך להיות לא זול במיוחד, כי רוב האחסון תפוס על ידי עותקים של אותם נתונים. במקרה של HaaS של עמיתים טורקים, האחסון יכול להיות צפוף בכ-80-90%. ברור שזה מתייחס ספציפית לפרט שלהם, אבל בהחלט הייתי סומך על לפחות 50% סבא.

כדי לפתור את הבעיה, הספקים הראשיים יצרו מזמן שערים לאמזון S3. כל השיטות שלהם תואמות ל-S3 המקומי כל עוד הן תומכות ב-Amazon API. במרכז הנתונים הטורקי, הגיבוי נעשה ל-S3 שלנו, כמו גם ב-T-III "קומפרסור" ברוסיה, מכיוון שתכנית העבודה הזו עבדה היטב עבורנו.

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

Veritas NetBackup הוסיפה את תכונת CloudCatalyst:

כלומר, בין המכונות שצריך לגבות לבין השער, ישנו שרת לינוקס ביניים שדרכו עוברת תעבורת גיבוי מסוכני ה-SRK ומבטלת כפילויות תוך כדי העברתה ל-S3. אם קודם לכן היו 30 גיבויים של 20 ג'יגה-בייט עם דחיסה, כעת (בשל הדמיון של המכונות) נפחם הפך קטן ב-90%. מנוע מניעת הכפילויות משמש כמו בעת אחסון על דיסקים רגילים באמצעות Netbackup.

הנה מה שקורה לפני שרת הביניים:

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

יומנים228 משרות (0 בתור 0 פעיל 0 ממתין לניסיון חוזר 0 מושעה 0 לא הושלם 228 בוצע - 13 נבחרו)
(מסנן הוחל [13])

זיהוי עבודה סוג מצב מצב פרטי סטטוס מדיניות עבודה לוח זמנים לקוח שרת התחלה זמן חלוף זמן סיום זמן אחסון יחידת ניסיון פעולה קילובייט קבצים שם נתיב % הושלם (משוער) בעל תפקיד PID העתק הורה משרה מזהה KB/שניה פעיל התחלה פעיל חלף פרופיל רובוט כספת מדיה מזהה להוצאת העברת נתונים מחוץ לסוג המארח עדיפות ראשית ביטול כפילויות של קצב תעבורה מאיץ אופטימיזציה של מופע או מארח שיתוף מסד נתונים
— 1358 תמונת מצב בוצעה 0 VMware — NGNCloudADC NBCC 18 בדצמבר 2018 12:16:19 PM 00:02:18 18 בדצמבר 2018 12:18:37 PM STU_DP_S3_****גיבוי 1 100% בסיס 1358 18% בסיס 2018 12% :16:27 PM 00:02:10 דיסק שחזור מיידי סטנדרטי WIN-************* 0
1360 גיבוי נעשה 0 VMware מלא NGNCloudADC NBCC 18 בדצמבר, 2018 12:16:48 PM 00:01:39 18 בדצמבר, 2018 12:18:27 PM STU_DP_S3_****גיבוי 1 14,535,248% 149654, 100% 23858, 1358% 335,098 18 2018 12 בדצמבר , 16 48:00:01 PM 39:0:99.8 דיסק שחזור מיידי סטנדרטי WIN-************* 99 XNUMX% XNUMX%
1352 Snapshot Done 0 VMware - NGNCloudADC NBCC 18 בדצמבר 2018 12:14:04 PM 00:02:01 18 בדצמבר 2018 12:16:05 PM STU_DP_S3_****גיבוי שורש 1 100% 1352% 18% 2018:12 PM 14:14:00 דיסק שחזור מיידי סטנדרטי WIN-************* 01
1354 גיבוי נעשה 0 VMware Incremental NGNCloudADC NBCC 18 בדצמבר, 2018 12:14:34 PM 00:01:21 18 בדצמבר, 2018 12:15:55 PM STU_DP_S3_****גיבוי 1 14,380,965% 147 100% 23617 1352 500,817 18 2018 בדצמבר , 12 14:34:00 PM 01:21:0 דיסק שחזור מיידי סטנדרטי WIN-************* 99.9 100% XNUMX%
1347 Snapshot Done 0 VMware - NGNCloudADC NBCC 18 בדצמבר 2018 12:11:45 PM 00:02:08 18 בדצמבר 2018 12:13:53 PM STU_DP_S3_****גיבוי שורש 1 100% 1347% 18% 2018:12 PM 11:45:00 דיסק שחזור מיידי סטנדרטי WIN-************* 02
1349 גיבוי נעשה 0 VMware מלא NGNCloudADC NBCC 18 בדצמבר, 2018 12:12:02 PM 00:01:41 18 בדצמבר, 2018 12:13:43 PM STU_DP_S3_****גיבוי 1 14,535,215% 149653, 100% 23508, 1347% 316,319 18 2018 12 בדצמבר , 12 02:00:01 PM 41:0:99.7 דיסק שחזור מיידי סטנדרטי WIN-************* 99 XNUMX% XNUMX%
1341 Snapshot Done 0 VMware - NGNCloudADC NBCC 18 בדצמבר 2018 12:05:28 PM 00:04:53 18 בדצמבר 2018 12:10:21 PM STU_DP_S3_****גיבוי שורש 1 100% 1341% 18% 2018:12 PM 05:28:00 דיסק שחזור מיידי סטנדרטי WIN-************* 04
1342 גיבוי נעשה 0 VMware Full_Rescan NGNCloudADC NBCC 18 בדצמבר, 2018 12:05:47 PM 00:04:24 18 בדצמבר, 2018 12:10:11 PM STU_DP_S3_****גיבוי 1 14,535,151 149653 100 22999 1341 root 70,380 18 2018 דצמבר 12 , 05 47:00:04 PM 24:0:87.9 דיסק שחזור מיידי סטנדרטי WIN-************* 0 XNUMX% XNUMX%

1339 Snapshot Done 150 VMware - NGNCloudADC NBCC 18 בדצמבר 2018 11:05:46 AM 00:00:53 18 בדצמבר 2018 11:06:39 AM STU_DP_S3_****גיבוי שורש 1 100% 1339% 18% 2018:11 AM 05:46:00 דיסק שחזור מיידי סטנדרטי WIN-************* 00
1327 Snapshot Done 0 VMware - ********.********.cloud NBCC 17 בדצמבר 2018 12:54:42 PM 05:51:38 17 בדצמבר 2018 6:46:20 STU_DP_S3_****backup 1 100% root 1327 Dec 17, 2018 12:54:42 PM 05:51:38 Disk Recovery Instant Standard WIN-************* 0
1328 גיבוי נעשה 0 VMware מלא ********.********.cloud NBCC 17 בדצמבר 2018 12:55:10 PM 05:29:21 17 בדצמבר 2018 6:24:31 STU_DP_S3_****backup 1 222,602,719 258932 100% 12856 root 1327 11,326 Dec 17, 2018 12:55:10 PM 05:29:21 Instant Recovery Disk-0******** Standard 87.9%0IN XNUMX%
1136 Snapshot Done 0 VMware - ********.********.cloud NBCC 14 בדצמבר 2018 4:48:22 PM 04:05:16 14 בדצמבר 2018 8:53:38 STU_DP_S3_****backup 1 100% root 1136 Dec 14, 2018 4:48:22 PM 04:05:16 Disk Recovery Instant Standard WIN-************* 0
1140 גיבוי נעשה 0 VMware Full_Scan *******.********.cloud NBCC 14 בדצמבר 2018 4:49:14 03:49:58 14 בדצמבר 2018 8:39:12 STU_DP_S3_****backup 1 217,631,332 255465 100% 26438 root 1136 15,963 Dec 14, 2018 4:49:14 PM 03:49:58 Instant Recovery Disk.0****** Standard 45.2%0-XNUMX***** XNUMX%

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

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

הארכיטקטורה השלמה נראית כך:

1. השרת הראשי מנהל תצורה, עדכונים וכו' וממוקם בענן.
2. שרת המדיה (מכונת *nix ביניים) צריך להיות ממוקם הכי קרוב למערכות המיותרות מבחינת נגישות לרשת. כאן מתבצעת ביטול כפילות של גיבויים מכל המכונות השמורות.
3. במכונות המגובות יש סוכנים שבדרך כלל שולחים לשרת המדיה רק ​​את מה שלא נמצא באחסון שלו.

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

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

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

הנה איך זה נראה:

והנה עוד חתיכת בולי עץ169 משרות (0 בתור 0 פעיל 0 ממתין לניסיון חוזר 0 מושעה 0 לא הושלם 169 בוצע - 1 נבחרו)

זיהוי עבודה סוג מצב מצב פרטי סטטוס מדיניות עבודה לוח זמנים לקוח שרת התחלה זמן חלוף זמן סיום זמן אחסון יחידת ניסיון פעולה קילובייט קבצים שם נתיב % הושלם (משוער) בעל תפקיד PID העתק הורה משרה מזהה KB/שניה פעיל התחלה פעיל חלף פרופיל רובוט כספת מדיה מזהה להוצאת העברת נתונים מחוץ לסוג המארח עדיפות ראשית ביטול כפילויות של קצב תעבורה מאיץ אופטימיזציה של מופע או מארח שיתוף מסד נתונים
- 1372 שחזור נעשה 0 NBPR01 NBCC 19 בדצמבר 2018 1:05:58 PM 00:04:32 19 בדצמבר 2018 1:10:30 PM 1 14,380,577 1 100% 8548 1372% 70,567 19 2018:1 :06 PM 00:00:04 WIN-************* 30

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

שרת המדיה זקוק ל-4 TB של מטמון - זוהי המלצת הגודל המינימלי של Veritas. יותר עדיף, אבל זה מה שעשינו.

סך הכל

כאשר שותף זרק 3 GB ל-S20 שלנו, אחסנו 60 GB, מכיוון שאנו מספקים שמירה גיאוגרפית משולשת של נתונים. עכשיו יש הרבה פחות תעבורה, וזה טוב גם לערוץ וגם לתעריפי האחסון.

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

אם אתה מעוניין ללמוד על תכונות אלה במרכזי הנתונים הרוסיים שלנו או שיש לך שאלות לגבי יישום בבית, שאל בהערות או בדוא"ל [מוגן בדוא"ל].

מקור: www.habr.com