نحوه فشرده سازی ذخیره سازی پشتیبان در ذخیره سازی اشیاء تا 90٪

مشتریان ترک ما از ما خواستند که پشتیبان گیری را برای مرکز داده آنها به درستی پیکربندی کنیم. ما در حال انجام پروژه های مشابه در روسیه هستیم، اما در اینجا داستان بیشتر در مورد تحقیق در مورد بهترین روش انجام آن بود.

با توجه به: یک حافظه محلی S3 وجود دارد، Veritas NetBackup وجود دارد که قابلیت های توسعه یافته جدیدی را برای انتقال داده ها به ذخیره سازی اشیا به دست آورده است، اکنون با پشتیبانی از deduplication، و مشکل فضای خالی در این حافظه محلی وجود دارد.

وظیفه: همه چیز را طوری بسازید که فرآیند ذخیره نسخه های پشتیبان سریع و ارزان باشد.

در واقع، قبل از این، همه چیز در S3 به سادگی فایل بود، و اینها قالب‌های کاملی از ماشین‌های حیاتی مرکز داده بودند. یعنی خیلی بهینه نیست، اما همه چیز در ابتدا کار می کرد. اکنون زمان آن است که آن را کشف کنید و آن را به درستی انجام دهید.

تصویر نشان می دهد که به چه چیزی رسیدیم:

نحوه فشرده سازی ذخیره سازی پشتیبان در ذخیره سازی اشیاء تا 90٪

همانطور که می بینید، اولین نسخه پشتیبان به آرامی (70 مگابیت بر ثانیه) ساخته شد و پشتیبان گیری بعدی از همان سیستم ها بسیار سریعتر بود.

در واقع، در ادامه جزئیات کمی در مورد ویژگی های موجود وجود دارد.

لاگ های پشتیبان برای کسانی که آماده خواندن نیم صفحه از Dump هستندکامل با اسکن مجدد
Dec 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; گزارش=آمار PDDO (جریان چند رشته ای استفاده شده) برای (NBCC): اسکن شده: 14570817 کیلوبایت، CR ارسال شده: 1760761 کیلوبایت، CR ارسال شده از طریق FC: 0 کیلوبایت، حذف: 87.9٪، حافظه پنهان غیرفعال است

کامل
Dec 18, 2018 12:13:18 PM — اطلاعات bpbkar (pid=2864) شتاب دهنده 181675008 بایت از 14884060160 بایت را به سرور ارسال کرد، بهینه سازی 98.8%
18 دسامبر 2018 12:13:40 بعد از ظهر - اطلاعات NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; گزارش=آمار PDDO برای (NBCC): اسکن شده: 14569706 کیلوبایت، CR ارسال شده: 45145 کیلوبایت، CR ارسال شده از طریق FC: 0 کیلوبایت، حذف: 99.7%، حافظه پنهان غیرفعال است

افزایشی
Dec 18, 2018 12:15:32 PM — اطلاعات bpbkar (pid=792) شتاب دهنده 9970688 بایت از 14726108160 بایت را به سرور ارسال کرد، بهینه سازی 99.9%
18 دسامبر 2018 12:15:53 بعد از ظهر - اطلاعات NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; گزارش=آمار PDDO برای (NBCC): اسکن شده: 14383788 کیلوبایت، CR ارسال شده: 15700 کیلوبایت، CR ارسال شده از طریق FC: 0 کیلوبایت، حذف: 99.9%، حافظه پنهان غیرفعال است

کامل
Dec 18, 2018 12:18:02 PM — اطلاعات bpbkar (pid=3496) شتاب دهنده 171746816 بایت از 14884093952 بایت را به سرور ارسال کرد، بهینه سازی 98.8%
18 دسامبر 2018 12:18:24 بعد از ظهر - اطلاعات NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; گزارش=آمار PDDO برای (NBCC): اسکن شده: 14569739 کیلوبایت، CR ارسال شده: 34120 کیلوبایت، CR ارسال شده از طریق FC: 0 کیلوبایت، حذف: 99.8%، حافظه پنهان غیرفعال است

مشکل چیه

مشتریان می‌خواهند تا جایی که ممکن است نسخه‌های پشتیبان تهیه کرده و تا حد امکان ارزان‌تر ذخیره کنند. بهتر است آنها را با قیمت ارزان در حافظه های ذخیره سازی اشیاء مانند S3 ذخیره کنید، زیرا ارزان ترین آنها با هزینه سرویس به ازای هر مگابایت هستند که می توانید از آنجا یک نسخه پشتیبان را در یک زمان معقول برگردانید. وقتی پشتیبان‌گیری زیاد باشد، خیلی ارزان نمی‌شود، زیرا بیشتر فضای ذخیره‌سازی توسط کپی‌هایی از همان داده‌ها اشغال می‌شود. در مورد HaaS همکاران ترکیه ای، ذخیره سازی می تواند تقریباً 80-90٪ متراکم شود. واضح است که این به طور خاص به ویژگی های آنها مربوط می شود، اما من قطعاً روی حداقل 50٪ پدربزرگ حساب می کنم.

برای حل این مشکل، فروشندگان اصلی مدت‌هاست که دروازه‌هایی به Amazon S3 ایجاد کرده‌اند. همه روش های آنها تا زمانی که از API آمازون پشتیبانی می کنند با S3 محلی سازگار هستند. در مرکز داده ترکیه، پشتیبان گیری در S3 ما و همچنین در T-III "Compressor" در روسیه انجام می شود، زیرا این طرح کاری برای ما به خوبی کار کرده است.

و S3 ما کاملاً با روش های پشتیبان گیری آمازون S3 سازگار است. یعنی همه ابزارهای پشتیبان‌گیری که از این روش‌ها پشتیبانی می‌کنند به شما امکان می‌دهند همه چیز را در چنین فضای ذخیره‌سازی «بیرون از جعبه» کپی کنید.

Veritas NetBackup ویژگی CloudCatalyst را اضافه کرد:

نحوه فشرده سازی ذخیره سازی پشتیبان در ذخیره سازی اشیاء تا 90٪

یعنی بین ماشین هایی که نیاز به پشتیبان گیری دارند و گیت وی، یک سرور لینوکس میانی وجود دارد که ترافیک پشتیبان گیری از عوامل SRK از طریق آن عبور می کند و قبل از انتقال آن به S3، در همان لحظه کپی می شود. اگر قبلاً 30 نسخه پشتیبان 20 گیگابایتی با فشرده سازی وجود داشت ، اکنون (به دلیل شباهت دستگاه ها) حجم آنها 90٪ کوچکتر شده است. موتور deduplication همانند هنگام ذخیره سازی روی دیسک های معمولی با استفاده از Netbackup استفاده می شود.

در اینجا چیزی است که قبل از سرور میانی اتفاق می افتد:

نحوه فشرده سازی ذخیره سازی پشتیبان در ذخیره سازی اشیاء تا 90٪

ما آزمایش کردیم و به این نتیجه رسیدیم که وقتی در مراکز داده ما پیاده سازی می شود، فضای ذخیره سازی S3 را برای ما و مشتریان ذخیره می کند. به عنوان صاحب مراکز داده تجاری، البته، ما با توجه به حجم اشغال شده شارژ می کنیم، اما هنوز هم برای ما بسیار سودآور است - زیرا ما شروع به کسب درآمد از مکان های مقیاس پذیرتر در نرم افزار می کنیم و نه برای اجاره سخت افزار. خوب، و این کاهش هزینه های داخلی است.

سیاهههای مربوط228 شغل (0 در صف 0 فعال 0 در انتظار تلاش مجدد 0 تعلیق شده 0 ناقص 228 انجام شد - 13 مورد انتخاب شده)
(فیلتر اعمال شد [13])

نوع شناسه شغلی جزئیات وضعیت وضعیت خط مشی شغلی زمان‌بندی شغلی سرویس گیرنده رسانه سرور زمان شروع زمان سپری شده زمان پایان زمان واحد ذخیره‌سازی تلاش عملیات کیلوبایت فایل‌ها نام مسیر % کامل (تخمینی) PID شغلی مالک کپی شناسه شغلی والد KB/Sec شروع فعال فعال نمایه خزانه ربات سپری شده شناسه رسانه برای بیرون راندن انتقال داده خارج از میزبان نوع اولویت اصلی کاهش تکرار نرخ حمل و نقل نمونه بهینه‌سازی شتاب‌دهنده یا پایگاه داده اشتراک‌گذاری میزبان
— 1358 Snapshot Done 0 VMware — NGNCloudADC NBCC 18 دسامبر 2018 12:16:19 PM 00:02:18 Dec 18, 2018 12:18:37 PM STU_DP_S3_**** 1 نسخه پشتیبان 100 1358 18 2018 12 16 :27:00 PM 02:10:0 دیسک بازیابی فوری استاندارد WIN-*********** XNUMX
1360 پشتیبان‌گیری انجام شد 0 VMware Full NGNCloudADC NBCC 18 دسامبر 2018 12:16:48 PM 00:01:39 Dec 18, 2018 12:18:27 PM STU_DP_S3_**** پشتیبان‌گیری 1 14,535,248, 149654% 100 23858 1358 دسامبر , 335,098 18:2018:12 PM 16:48:00 دیسک بازیابی فوری استاندارد WIN-*********** 01 39% 0%
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_**** پشتیبان گیری STU_DP_S1_**** پشتیبان گیری 100 1352% 18 Dec 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 01 21 دسامبر , 0 99.9:100:XNUMX PM XNUMX:XNUMX:XNUMX دیسک بازیابی فوری استاندارد WIN-*********** XNUMX XNUMX% 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_**** پشتیبان گیری STU_DP_S1_**** پشتیبان گیری 100 1347% 18 Dec 2018:12 PM 11:45:00 دیسک بازیابی فوری استاندارد WIN-*********** 02
1349 پشتیبان‌گیری انجام شد 0 VMware Full NGNCloudADC NBCC 18 دسامبر 2018 12:12:02 PM 00:01:41 Dec 18, 2018 12:13:43 PM STU_DP_S3_**** پشتیبان‌گیری 1 14,535,215, 149653% 100 23508 1347 دسامبر , 316,319 18:2018:12 PM 12:02:00 دیسک بازیابی فوری استاندارد WIN-*********** 01 41% 0%
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_**** پشتیبان گیری STU_DP_S1_**** پشتیبان گیری 100 1341% 18 Dec 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 70,380 دسامبر 18 , 2018 12:05:47 PM 00:04:24 دیسک بازیابی فوری استاندارد WIN-************ 0 87.9% 0%

1339 Snapshot Done 150 VMware - NGNCloudADC NBCC 18 دسامبر 2018 11:05:46 AM 00:00:53 Dec 18, 2018 11:06:39 AM STU_DP_S3_**** 1% نسخه پشتیبان 100، 1339:18:2018 AM 11:05 AM 46:00:00 دیسک بازیابی فوری استاندارد WIN-*********** 53
1327 Snapshot Done 0 VMware - *******.********.cloud NBCC 17 دسامبر 2018 12:54:42 بعد از ظهر 05:51:38 17 دسامبر 2018 6:46:20 بعد از ظهر STU_DP_S3_****پشتیبان 1 100% ریشه 1327 17 دسامبر 2018 12:54:42 بعد از ظهر 05:51:38 دیسک بازیابی فوری استاندارد WIN-*********** 0
1328 پشتیبان گیری انجام شد 0 VMware Full ********************.cloud NBCC 17 دسامبر 2018 12:55:10 بعد از ظهر 05:29:21 17 دسامبر 2018 6:24:31 بعد از ظهر STU_DP_S3_****پشتیبان 1 222,602,719 258932 100% 12856 root 1327 11,326 Dec 17, 2018 12:55:10 PM 05:29:21 بازیابی فوری W0% *** دیسک استاندارد *** 87.9%
1136 Snapshot Done 0 VMware - *******.********.cloud NBCC 14 دسامبر 2018 4:48:22 بعد از ظهر 04:05:16 14 دسامبر 2018 8:53:38 بعد از ظهر STU_DP_S3_****پشتیبان 1 100% ریشه 1136 14 دسامبر 2018 4:48:22 بعد از ظهر 04:05:16 دیسک بازیابی فوری استاندارد 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_****پشتیبان 1 217,631,332 255465 100% 26438 root 1136 15,963 Dec 14, 2018 4:49:14 PM 03:49:58 بازیابی فوری *** دیسک بازیابی فوری %IN-0 *** استاندارد *** 45.2%

شتاب دهنده به شما امکان می دهد ترافیک نمایندگان را کاهش دهید، زیرا فقط تغییرات داده ها منتقل می شود، یعنی حتی نسخه های پشتیبان کامل نیز به طور کامل آپلود نمی شوند، زیرا سرور رسانه پشتیبان های کامل بعدی را از پشتیبان گیری افزایشی جمع آوری می کند.

سرور میانی دارای فضای ذخیره سازی مخصوص به خود است، جایی که یک "کش" از داده ها را می نویسد و یک پایگاه داده را برای کپی برداری نگهداری می کند.

معماری کامل به صورت زیر است:

  1. سرور اصلی پیکربندی، به روز رسانی و غیره را مدیریت می کند و در فضای ابری قرار دارد.
  2. سرور رسانه (ماشین *nix متوسط) باید از نظر دسترسی به شبکه نزدیک به سیستم های اضافی قرار گیرد. در اینجا حذف نسخه پشتیبان از تمام ماشین های رزرو شده انجام می شود.
  3. در ماشین‌های پشتیبان‌گیری شده، عواملی وجود دارند که معمولاً فقط مواردی را به سرور رسانه ارسال می‌کنند که در حافظه آن نیست.

همه چیز با یک اسکن کامل شروع می شود - این یک نسخه پشتیبان کامل کامل است. در این مرحله، سرور رسانه همه چیز را می گیرد، آن را حذف می کند و به S3 منتقل می کند. سرعت به سرور رسانه کم است، اما از آن بالاتر است. محدودیت اصلی قدرت محاسباتی سرور است.

پشتیبان‌گیری‌های زیر از نظر همه سیستم‌ها کامل هستند، اما در واقع چیزی شبیه به بک‌آپ‌های کامل مصنوعی هستند. یعنی انتقال و ضبط واقعی به سرور رسانه فقط بلوک‌های داده‌ای است که قبلاً در پشتیبان‌گیری‌های VM با آن‌ها مواجه نشده‌اند. و فقط آن دسته از بلوک‌های داده‌ای که هش آن‌ها در پایگاه داده حذف‌سازی سرور رسانه نیست، در S3 منتقل و ضبط می‌شوند. به عبارت ساده تر، این چیزی است که قبلاً در هیچ نسخه پشتیبان از یک ماشین مجازی دیده نشده بود.

در حین بازیابی، سرور رسانه اشیاء حذف شده لازم را از S3 درخواست می کند، آنها را آبرسانی می کند و آنها را به عوامل IRB منتقل می کند. در حین بازیابی باید حجم ترافیک را در نظر گرفت که برابر با حجم واقعی داده های در حال بازیابی است.

در اینجا به نظر می رسد:

نحوه فشرده سازی ذخیره سازی پشتیبان در ذخیره سازی اشیاء تا 90٪

و در اینجا یک قطعه دیگر از سیاهههای مربوط است169 شغل (0 در صف 0 فعال 0 در انتظار تلاش مجدد 0 تعلیق شده 0 ناقص 169 انجام شد - 1 مورد انتخاب شده)

نوع شناسه شغلی جزئیات وضعیت وضعیت خط مشی شغلی زمان‌بندی شغلی سرویس گیرنده رسانه سرور زمان شروع زمان سپری شده زمان پایان زمان واحد ذخیره‌سازی تلاش عملیات کیلوبایت فایل‌ها نام مسیر % کامل (تخمینی) PID شغلی مالک کپی شناسه شغلی والد KB/Sec شروع فعال فعال نمایه خزانه ربات سپری شده شناسه رسانه برای بیرون راندن انتقال داده خارج از میزبان نوع اولویت اصلی کاهش تکرار نرخ حمل و نقل نمونه بهینه‌سازی شتاب‌دهنده یا پایگاه داده اشتراک‌گذاری میزبان
- 1372 بازیابی انجام شد 0 NBPR01 NBCC 19 دسامبر 2018 1:05:58 بعد از ظهر 00:04:32 دسامبر 19, 2018 1:10:30 بعد از ظهر 1:14,380,577 :1 PM 100:8548:1372 WIN-************ 70,567

یکپارچگی داده ها با محافظت از خود S3 تضمین می شود - برای محافظت در برابر خرابی های سخت افزاری مانند اسپیندل مرده هارد دیسک، افزونگی خوبی وجود دارد.

سرور رسانه به 4 ترابایت حافظه کش نیاز دارد - این حداقل اندازه توصیه Veritas است. بیشتر بهتر است، اما این کاری است که ما انجام دادیم.

مجموع

هنگامی که یک شریک 3 گیگابایت را به S20 ما پرتاب کرد، ما 60 گیگابایت را ذخیره کردیم، زیرا ما سه بار رزرو جغرافیایی داده ها را ارائه می دهیم. الان ترافیک خیلی کمتری هست که هم برای کانال و هم برای تعرفه ذخیره سازی خوبه.

در این حالت، مسیرها از طریق "اینترنت بزرگ" بسته می شوند، اما می توانید ترافیک را از طریق VPN L2 از طریق اینترنت هدایت کنید، اما بهتر است قبل از ورود ارائه دهنده، سرور رسانه را نصب کنید.

اگر علاقه مند به یادگیری این ویژگی ها در مراکز داده روسیه هستید یا در مورد پیاده سازی در خانه سؤالی دارید، در نظرات یا از طریق ایمیل بپرسید. [ایمیل محافظت شده].

منبع: www.habr.com

اضافه کردن نظر