🥇آبجیکٹ اسٹوریج میں بیک اپ کے سٹوریج کو 90% تک کمپیکٹ کرنے کا طریقہ

ہمارے ترک کلائنٹس نے ہم سے اپنے ڈیٹا سینٹر کے لیے بیک اپ کو مناسب طریقے سے ترتیب دینے کو کہا۔ ہم روس میں بھی اسی طرح کے منصوبے کر رہے ہیں، لیکن یہاں کہانی اس بارے میں زیادہ تھی کہ اسے کس طرح بہترین طریقے سے انجام دیا جائے۔

دیا گیا: ایک مقامی S3 اسٹوریج ہے، وہاں Veritas NetBackup ہے، جس نے ڈیٹا کو آبجیکٹ اسٹوریج میں منتقل کرنے کے لیے نئی توسیعی فعالیت حاصل کر لی ہے، اب ڈپلیکیشن کی حمایت کے ساتھ، اور اس مقامی اسٹوریج میں خالی جگہ کا مسئلہ ہے۔

ٹاسک: سب کچھ بنانا تاکہ بیک اپ کاپیوں کو ذخیرہ کرنے کا عمل تیز اور سستا ہو۔

درحقیقت، اس سے پہلے، S3 میں ہر چیز محض فائلیں تھیں، اور یہ ڈیٹا سینٹر کی اہم مشینوں کی مکمل کاسٹ تھیں۔ یعنی، یہ بہت زیادہ بہتر نہیں ہے، لیکن سب کچھ شروع میں کام کرتا ہے۔ اب اس کا پتہ لگانے اور اسے درست کرنے کا وقت آگیا ہے۔

تصویر سے پتہ چلتا ہے کہ ہم کیا کرنے آئے ہیں:

جیسا کہ آپ دیکھ سکتے ہیں، پہلا بیک اپ آہستہ سے بنایا گیا تھا (70 Mb/s)، اور اسی سسٹم کے بعد کے بیک اپ بہت تیز تھے۔

دراصل، اس کے بارے میں مزید تفصیلات موجود ہیں کہ وہاں کیا خصوصیات ہیں۔

ان لوگوں کے لیے بیک اپ لاگز جو ڈمپ کا آدھا صفحہ پڑھنے کے لیے تیار ہیں۔ریسکین کے ساتھ بھرا ہوا ہے۔
18 دسمبر 2018 12:09:43 PM — Info bpbkar (pid=4452) ایکسلریٹر نے 14883996160 بائٹس میں سے 14883994624 بائٹس سرور کو بھیجے، اصلاح 0.0%
18 دسمبر 2018 12:10:07 PM - معلومات NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; رپورٹ=PDDO اعدادوشمار (ملٹی تھریڈڈ سٹریم استعمال کیا گیا) برائے (NBCC): اسکین کیا گیا: 14570817 KB، CR بھیجا گیا: 1760761 KB، CR بھیج دیا گیا FC: 0 KB، ڈیڈ اپ: 87.9%، کیش غیر فعال

مکمل
18 دسمبر 2018 12:13:18 PM — Info 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 — Info 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 — Info 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 فیصد چھوٹا ہو گیا ہے۔ ڈپلیکیشن انجن کا استعمال وہی کیا جاتا ہے جیسا کہ نیٹ بیک اپ کا استعمال کرتے ہوئے ریگولر ڈسک پر اسٹور کرتے وقت۔

انٹرمیڈیٹ سرور سے پہلے کیا ہوتا ہے یہاں ہے:

ہم نے تجربہ کیا اور اس نتیجے پر پہنچے کہ ہمارے ڈیٹا سینٹرز میں لاگو ہونے پر، یہ ہمارے اور صارفین کے لیے S3 اسٹوریج میں جگہ بچاتا ہے۔ کمرشل ڈیٹا سینٹرز کے مالک کے طور پر، یقیناً، ہم زیر قبضہ حجم کے مطابق چارج کرتے ہیں، لیکن یہ ہمارے لیے اب بھی بہت منافع بخش ہے - کیونکہ ہم سافٹ ویئر میں زیادہ قابل توسیع جگہوں پر پیسہ کمانا شروع کرتے ہیں، نہ کہ ہارڈ ویئر کرائے پر دینے پر۔ ٹھیک ہے، اور یہ اندرونی اخراجات میں کمی ہے.

نوشتہ جات228 نوکریاں (0 قطار میں 0 فعال 0 دوبارہ کوشش کا انتظار 0 معطل 0 نامکمل 228 ہو گیا - 13 منتخب)
(فلٹر اپلائیڈ [13])

جاب آئی ڈی کی قسم اسٹیٹ اسٹیٹ کی تفصیلات اسٹیٹس جاب پالیسی جاب کا شیڈول کلائنٹ میڈیا سرور اسٹارٹ ٹائم ایلاپسڈ ٹائم سٹوریج یونٹ کی کوشش آپریشن کلو بائٹس فائلز پاتھ کا نام % مکمل (تخمینہ) جاب پی آئی ڈی اونر کاپی پیرنٹ جاب آئی ڈی KB/سیکنڈ ایکٹیو سٹارٹ ایکٹیو سٹارٹ روبوٹ ایکٹیو سیٹ اپ سیٹ کریں ڈیٹا موومنٹ آف ہوسٹ ٹائپ ماسٹر ترجیحی ڈیڈپلیکیشن ریٹ ٹرانسپورٹ ایکسلریٹر آپٹیمائزیشن مثال یا ڈیٹا بیس شیئر ہوسٹ کو نکالنے کے لیے ID میڈیا
— 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 PM 12:16:27 فوری بازیافت ڈسک معیاری WIN-*********** 00
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 PM 16:48:00 Instant Recovery Disk Standard WIN-*********** 01 39% 0%
1352 سنیپ شاٹ ہو گیا 0 VMware - NGNCloudADC NBCC 18 دسمبر، 2018 12:14:04 PM 00:02:01 دسمبر 18، 2018 12:16:05 PM STU_DP_S3_**** بیک اپ 1 Dec 100، 1352% بیک اپ 18:2018 PM 12:14:14 فوری ریکوری ڈسک معیاری WIN-*********** 00
1354 بیک اپ ہو گیا 0 VMware انکریمنٹل 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 PM 12:14:34 Instant Recovery Disk Standard WIN-************ 00 01% 21%
1347 سنیپ شاٹ ہو گیا 0 VMware - NGNCloudADC NBCC 18 دسمبر، 2018 12:11:45 PM 00:02:08 دسمبر 18، 2018 12:13:53 PM STU_DP_S3_**** بیک اپ 1 Dec 100، 1347% بیک اپ 18:2018 PM 12:11:45 فوری ریکوری ڈسک معیاری WIN-*********** 00
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 PM 12:02:00 Instant Recovery Disk Standard WIN-*********** 01 41% 0%
1341 سنیپ شاٹ ہو گیا 0 VMware - NGNCloudADC NBCC 18 دسمبر، 2018 12:05:28 PM 00:04:53 دسمبر 18، 2018 12:10:21 PM STU_DP_S3_**** بیک اپ 1 Dec 100، 1341% بیک اپ 18:2018 PM 12:05:28 فوری ریکوری ڈسک معیاری WIN-*********** 00
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 PM 47:00:04 فوری ریکوری ڈسک سٹینڈرڈ WIN-*********** 24 0% 87.9%

1339 اسنیپ شاٹ ہو گیا 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 AM 2018:11:05 فوری ریکوری ڈسک معیاری WIN-*********** 46
1327 سنیپ شاٹ ہو گیا 0 VMware - *******.********.Cloud NBCC 17 دسمبر 2018 12:54:42 PM 05:51:38 دسمبر 17، 2018 6:46:20 PM STU_DP_S3_****بیک اپ 1 100% روٹ 1327 دسمبر 17، 2018 12:54:42 PM 05:51:38 Instant Recovery Disk Standard WIN-*********** 0
1328 بیک اپ ہو گیا 0 VMware مکمل *******.********.Cloud NBCC دسمبر 17، 2018 12:55:10 PM 05:29:21 دسمبر 17، 2018 6:24:31 PM STU_DP_S3_****بیک اپ 1 222,602,719 258932 100% 12856 روٹ 1327 11,326 دسمبر 17، 2018 12:55:10 PM 05:29:21 Instant Recovery Disk**** INstant Recovery Disk** 0%**** INstant Recovery Disk**** 87.9%****** 0%
1136 سنیپ شاٹ ہو گیا 0 VMware - *******.********.Cloud NBCC 14 دسمبر 2018 4:48:22 PM 04:05:16 دسمبر 14، 2018 8:53:38 PM STU_DP_S3_****بیک اپ 1 100% روٹ 1136 دسمبر 14، 2018 4:48:22 PM 04:05:16 Instant Recovery Disk Standard WIN-*********** 0
1140 بیک اپ ہو گیا 0 VMware Full_Scan *******.********.Cloud NBCC دسمبر 14، 2018 4:49:14 PM 03:49:58 دسمبر 14، 2018 8:39:12 PM STU_DP_S3_****بیک اپ 1 217,631,332 255465 100% 26438 روٹ 1136 15,963 دسمبر 14، 2018 4:49:14 PM 03:49:58 Instant Recovery Disk**** INstant Recovery Disk**** IN0**** INstant Recovery Disk********************** 45.2%

ایکسلریٹر آپ کو ایجنٹوں سے ٹریفک کم کرنے کی اجازت دیتا ہے، کیونکہ صرف ڈیٹا کی تبدیلیاں منتقل کی جاتی ہیں، یعنی مکمل بیک اپ بھی مکمل طور پر اپ لوڈ نہیں ہوتے ہیں، کیونکہ میڈیا سرور اضافی بیک اپس سے بعد میں مکمل بیک اپ جمع کرتا ہے۔

انٹرمیڈیٹ سرور کا اپنا اسٹوریج ہوتا ہے، جہاں یہ ڈیٹا کا "کیش" لکھتا ہے اور ڈپلیکیشن کے لیے ڈیٹا بیس کو برقرار رکھتا ہے۔

مکمل فن تعمیر اس طرح لگتا ہے:

ماسٹر سرور کنفیگریشن، اپ ڈیٹس وغیرہ کا انتظام کرتا ہے اور کلاؤڈ میں واقع ہے۔
میڈیا سرور (انٹرمیڈیٹ *نکس مشین) نیٹ ورک کی رسائی کے لحاظ سے فالتو سسٹمز کے سب سے قریب واقع ہونا چاہیے۔ یہاں، تمام محفوظ مشینوں سے بیک اپ کی نقل تیار کی جاتی ہے۔
بیک اپ مشینوں پر ایسے ایجنٹ ہوتے ہیں جو عام طور پر میڈیا سرور کو صرف وہی بھیجتے ہیں جو اس کے اسٹوریج میں نہیں ہے۔

یہ سب ایک مکمل اسکین کے ساتھ شروع ہوتا ہے - یہ ایک مکمل مکمل بیک اپ ہے۔ اس مقام پر، میڈیا سرور سب کچھ لیتا ہے، اس کی نقل تیار کرتا ہے اور اسے S3 میں منتقل کرتا ہے۔ میڈیا سرور کی رفتار کم ہے، لیکن اس سے زیادہ ہے۔ بنیادی حد سرور کی کمپیوٹنگ طاقت ہے۔

مندرجہ ذیل بیک اپ تمام سسٹمز کے نقطہ نظر سے مکمل بنائے گئے ہیں، لیکن حقیقت میں وہ مصنوعی مکمل بیک اپ کی طرح ہیں۔ یعنی میڈیا سرور پر حقیقی منتقلی اور ریکارڈنگ صرف ان ڈیٹا بلاکس کی ہوتی ہے جن کا ابھی تک VM بیک اپ میں سامنا نہیں ہوا ہے۔ اور صرف وہی ڈیٹا بلاکس جن کی ہیش میڈیا سرور کے ڈپلیکیشن ڈیٹا بیس میں نہیں ہے منتقل اور S3 میں ریکارڈ کیے جاتے ہیں۔ آسان الفاظ میں، یہ وہ چیز ہے جو پہلے کبھی کسی ایک VM کے بیک اپ میں نہیں دیکھی گئی۔

بحالی کے دوران، میڈیا سرور S3 سے ضروری نقل شدہ اشیاء کی درخواست کرتا ہے، انہیں دوبارہ ہائیڈریٹ کرتا ہے اور انہیں IRB ایجنٹوں کو منتقل کرتا ہے، یعنی بحالی کے دوران ٹریفک کے حجم کو مدنظر رکھنا ضروری ہے، جو کہ بحال ہونے والے ڈیٹا کے اصل حجم کے برابر ہوگا۔

یہاں کی طرح لگتا ہے:

اور یہاں نوشتہ جات کا ایک اور ٹکڑا ہے۔169 نوکریاں (0 قطار میں 0 فعال 0 دوبارہ کوشش کا انتظار 0 معطل 0 نامکمل 169 ہو گیا - 1 منتخب)

ڈیٹا کی سالمیت کو خود S3 کے تحفظ سے یقینی بنایا جاتا ہے - ہارڈ ویئر کی ناکامیوں جیسے کہ ڈیڈ ہارڈ ڈرائیو اسپنڈل سے بچانے کے لیے وہاں اچھی فالتو پن موجود ہے۔

میڈیا سرور کو 4 TB کیشے کی ضرورت ہے - یہ Veritas کی کم از کم سائز کی تجویز ہے۔ مزید بہتر ہے، لیکن ہم نے یہی کیا۔

کل

جب ایک پارٹنر نے ہمارے S3 میں 20 GB ڈالا، تو ہم نے 60 GB ذخیرہ کیا، کیونکہ ہم ڈیٹا کی تین گنا جیو ریزرویشن فراہم کرتے ہیں۔ اب ٹریفک بہت کم ہے، جو چینل اور اسٹوریج ٹیرف دونوں کے لیے اچھا ہے۔

اس صورت میں، راستے "بڑے انٹرنیٹ" کے بعد بند ہیں، لیکن آپ انٹرنیٹ پر VPN L2 کے ذریعے ٹریفک چلا سکتے ہیں، لیکن بہتر ہے کہ فراہم کنندہ کے داخلے سے پہلے میڈیا سرور انسٹال کر لیں۔

اگر آپ ہمارے روسی ڈیٹا سینٹرز میں ان خصوصیات کے بارے میں جاننے میں دلچسپی رکھتے ہیں یا آپ کے گھر پر عمل درآمد کے بارے میں سوالات ہیں تو کمنٹس میں یا ای میل کے ذریعے پوچھیں۔ [ای میل محفوظ].

ماخذ: www.habr.com

آبجیکٹ اسٹوریج میں بیک اپ کو 90% تک کومپیکٹ کرنے کا طریقہ

مسئلہ کیا ہے

کل

نیا تبصرہ شامل کریں جواب منسوخ کریں