🥇कसरी वस्तु भण्डारणमा ९०% सम्म ब्याकअपको भण्डारण कम्प्याक्ट गर्ने

हाम्रा टर्की ग्राहकहरूले हामीलाई उनीहरूको डेटा केन्द्रको लागि ब्याकअप कन्फिगर गर्न आग्रह गरे। हामी रूसमा यस्तै परियोजनाहरू गर्दैछौं, तर यहाँ कथा यो कसरी गर्ने भनेर अनुसन्धान गर्ने बारे थप थियो।

दिइएको: त्यहाँ एक स्थानीय S3 भण्डारण छ, त्यहाँ Veritas NetBackup छ, जसले वस्तु भण्डारणमा डाटा सार्नको लागि नयाँ विस्तारित कार्यक्षमता प्राप्त गरेको छ, अब डुप्लिकेशनको लागि समर्थन सहित, र यस स्थानीय भण्डारणमा खाली ठाउँको समस्या छ।

कार्य: सबै चीज बनाउन ताकि ब्याकअप प्रतिलिपिहरू भण्डारण गर्ने प्रक्रिया छिटो र सस्तो छ।

वास्तवमा, यस अघि, S3 मा सबै चीजहरू मात्र फाइलहरू थिए, र यी डाटा केन्द्रको महत्वपूर्ण मेसिनहरूको पूर्ण कास्टहरू थिए। त्यो हो, यो धेरै अनुकूलित छैन, तर सबै कुरा सुरुमा काम गर्यो। अब यो पत्ता लगाउन र यसलाई सही गर्न समय हो।

तस्विरले देखाउँछ कि हामी के आयौं:

तपाईले देख्न सक्नुहुने रूपमा, पहिलो ब्याकअप बिस्तारै बनाइएको थियो (70 Mb/s), र उही प्रणालीहरूको पछिल्ला ब्याकअपहरू धेरै छिटो थिए।

वास्तवमा, त्यहाँ के सुविधाहरू छन् भन्ने बारे अलि बढी विवरणहरू छन्।

डम्पको आधा पृष्ठ पढ्न तयार भएकाहरूका लागि ब्याकअप लगहरूरिस्क्यानको साथ पूर्ण
डिसेम्बर 18, 2018 12:09:43 PM — जानकारी 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, dedup: 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; (NBCC) को लागि रिपोर्ट = PDDO तथ्याङ्कहरू: स्क्यान गरिएको: 14569706 KB, CR पठाइयो: 45145 KB, CR FC माथि पठाइयो: 0 KB, dedup: 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; (NBCC) को लागि रिपोर्ट = PDDO तथ्याङ्कहरू: स्क्यान गरिएको: 14383788 KB, CR पठाइयो: 15700 KB, CR FC माथि पठाइयो: 0 KB, dedup: 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; (NBCC) को लागि रिपोर्ट = PDDO तथ्याङ्कहरू: स्क्यान गरिएको: 14569739 KB, CR पठाइयो: 34120 KB, CR FC माथि पठाइयो: 0 KB, dedup: 99.8%, क्यास असक्षम गरियो

समस्या के हो

ग्राहकहरू सकेसम्म प्रायः ब्याकअपहरू बनाउन र सकेसम्म सस्तोमा भण्डारण गर्न चाहन्छन्। तिनीहरूलाई S3 जस्ता वस्तु भण्डारणहरूमा सस्तोमा भण्डारण गर्नु उत्तम हुन्छ, किनभने तिनीहरू प्रति मेगाबाइट सेवाको लागतमा सस्तो छन् जहाँबाट तपाईंले उचित समयमा ब्याकअप फिर्ता गर्न सक्नुहुन्छ। जब त्यहाँ धेरै ब्याकअप हुन्छ, यो धेरै सस्तो हुँदैन, किनकि धेरैजसो भण्डारण एउटै डाटाको प्रतिलिपिहरूले ओगटेको हुन्छ। टर्की सहकर्मीहरूको HaaS को मामला मा, भण्डारण लगभग 80-90% द्वारा घनत्व गर्न सकिन्छ। यो स्पष्ट छ कि यो विशेष गरी तिनीहरूको विशिष्टतासँग सम्बन्धित छ, तर म निश्चित रूपमा कम्तिमा 50% हजुरबुबामा भरोसा गर्नेछु।

समस्या समाधान गर्न, मुख्य विक्रेताहरूले लामो समयदेखि Amazon S3 को गेटवे बनाएका छन्। तिनीहरूका सबै विधिहरू स्थानीय S3 सँग उपयुक्त छन् जबसम्म तिनीहरूले Amazon API लाई समर्थन गर्छन्। टर्की डाटा सेन्टरमा, ब्याकअप हाम्रो S3 मा बनाइएको छ, साथै रूसको T-III "कम्प्रेसर" मा, किनकि यो कार्य योजनाले हाम्रो लागि राम्रो काम गरेको छ।

र हाम्रो S3 Amazon S3 ब्याकअप विधिहरूसँग पूर्ण रूपमा उपयुक्त छ। त्यो हो, यी विधिहरूलाई समर्थन गर्ने सबै ब्याकअप उपकरणहरूले तपाईंलाई यस्तो भण्डारणमा "बाकसको बाहिर" सबै कुरा प्रतिलिपि गर्न अनुमति दिन्छ।

Veritas NetBackup ले CloudCatalyst सुविधा थप्यो:

अर्थात्, ब्याकअप गर्नुपर्ने मेसिन र गेटवेको बीचमा, त्यहाँ एउटा मध्यवर्ती लिनक्स सर्भर छ जसको माध्यमबाट SRK एजेन्टहरूबाट ब्याकअप ट्राफिक पास हुन्छ र यसलाई S3 मा स्थानान्तरण गर्नु अघि उडानमा डुप्लिकेट गरिन्छ। यदि पहिले कम्प्रेसनको साथ 30 GB को 20 ब्याकअपहरू थिए भने, अब (मेसिनहरूको समानताको कारण) तिनीहरूको भोल्युम 90% सानो भएको छ। डुप्लिकेशन इन्जिन नेटब्याकअप प्रयोग गरेर नियमित डिस्कहरूमा भण्डारण गर्दा जस्तै प्रयोग गरिन्छ।

मध्यवर्ती सर्भर अघि के हुन्छ यहाँ छ:

हामीले परीक्षण गर्यौं र निष्कर्षमा पुग्यौं कि जब हाम्रो डेटा केन्द्रहरूमा लागू हुन्छ, यसले हाम्रो र ग्राहकहरूको लागि S3 भण्डारणमा ठाउँ बचत गर्छ। व्यावसायिक डेटा केन्द्रहरूको मालिकको रूपमा, अवश्य पनि, हामी कब्जा गरिएको भोल्युम अनुसार शुल्क लिन्छौं, तर यो अझै पनि हाम्रो लागि धेरै लाभदायक छ - किनभने हामी सफ्टवेयरमा थप स्केलेबल ठाउँहरूमा पैसा कमाउन थाल्छौं, हार्डवेयर भाडामा होइन। ठीक छ, र यो आन्तरिक लागतमा कमी हो।

लगहरू228 कार्यहरू (0 लामबद्ध 0 सक्रिय 0 पुन: प्रयासको लागि प्रतिक्षा गर्दै 0 निलम्बित 0 अपूर्ण 228 सम्पन्न भयो — 13 चयन गरियो)
(फिल्टर लागू [१३])

कार्य आईडी प्रकार राज्य राज्य विवरण स्थिति कार्य नीति कार्य तालिका ग्राहक मिडिया सर्भर सुरु समय समाप्त समय भण्डारण एकाइ प्रयास सञ्चालन किलोबाइट फाइलहरू पथनाम % पूरा (अनुमानित) काम PID मालिक प्रतिलिपि अभिभावक काम ID 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 PM 12:16:27 तत्काल रिकभरी डिस्क मानक WIN-*********** ०
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 PM 2018:12:16 तत्काल रिकभरी डिस्क मानक WIN-*********** ० ९९.८% ९९%
1352 स्न्यापसट सम्पन्न भयो 0 VMware - NGNCloudADC NBCC डिसेम्बर 18, 2018 12:14:04 अपराह्न 00:02:01 डिसेम्बर 18, 2018 12:16:05 PM STU_DP_S3_****ब्याकअप 1% 100, 1352 18:2018 PM 12:14:14 तत्काल रिकभरी डिस्क मानक WIN-*********** ०
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 PM 500,817:18:2018 तत्काल रिकभरी डिस्क मानक WIN-*********** ० ९९.९% १००%
1347 स्न्यापसट सम्पन्न भयो 0 VMware - NGNCloudADC NBCC डिसेम्बर 18, 2018 12:11:45 अपराह्न 00:02:08 डिसेम्बर 18, 2018 12:13:53 PM STU_DP_S3_****ब्याकअप 1% 100, 1347 18:2018 PM 12:11:45 तत्काल रिकभरी डिस्क मानक WIN-*********** ०
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 PM 2018:12:12 तत्काल रिकभरी डिस्क मानक WIN-*********** ० ९९.८% ९९%
1341 स्न्यापसट सम्पन्न भयो 0 VMware - NGNCloudADC NBCC डिसेम्बर 18, 2018 12:05:28 अपराह्न 00:04:53 डिसेम्बर 18, 2018 12:10:21 PM STU_DP_S3_****ब्याकअप 1% 100, 1341 18:2018 PM 12:05:28 तत्काल रिकभरी डिस्क मानक WIN-*********** ०
1342 ब्याकअप सम्पन्न भयो 0 VMware Full_Rescan NGNCloudADC NBCC डिसेम्बर 18, 2018 12:05:47 अपराह्न 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 PM 05:47:00 तत्काल रिकभरी डिस्क मानक WIN-*********** ० ८७.९% ०%

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-*********** ०
१३२७ स्न्यापसट सम्पन्न भयो ० VMware - *******।********।Cloud NBCC डिसेम्बर १७, २०१८ 1327:0:17 PM 2018:12:54 डिसेम्बर 42, 05 51:38:17 PM STU_DP_S2018_****ब्याकअप 6 46% रूट 20 डिसेम्बर 3, 1 100:1327:17 PM 2018:12:54 तत्काल रिकभरी डिस्क मानक WIN-*********** 42
१३२८ ब्याकअप सम्पन्न भयो ० VMware पूर्ण *******।********।क्लाउड NBCC डिसेम्बर १७, २०१८ 1328:0:17 PM 2018:12:55 डिसेम्बर 10, 05 29:21:17 PM STU_DP_S2018_****ब्याकअप 6 24 31 3% 1 रूट 222,602,719 258932 डिसेम्बर 100, 12856 1327:11,326:17 PM 2018:12:55 तत्काल रिकभरी डिस्क ** INSTANT Recovery Disk**** INSTANT Recovery Disk****** INSTANT रिकभरी डिस्क****** 10%**** INSTANT रिकभरी डिस्क *** ०%
१३२७ स्न्यापसट सम्पन्न भयो ० VMware - *******।********।Cloud NBCC डिसेम्बर १७, २०१८ 1136:0:14 PM 2018:4:48 डिसेम्बर 22, 04 05:16:14 PM STU_DP_S2018_****ब्याकअप 8 53% रूट 38 डिसेम्बर 3, 1 100:1136:14 PM 2018:4:48 तत्काल रिकभरी डिस्क मानक WIN-*********** 22
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 अपराह्न 03:49:58 तत्काल रिकभरी डिस्क ** IN0% ** मानक ** IN45.2 ** IN0 XNUMX:XNUMX इन्स्ट्यान्ट रिकभरी डिस्क *** INXNUMX ** INXNUMX ** मानक ०%

एक्सेलेटरले तपाईंलाई एजेन्टहरूबाट ट्राफिक कम गर्न अनुमति दिन्छ, किनभने केवल डाटा परिवर्तनहरू प्रसारित हुन्छन्, अर्थात्, पूर्ण ब्याकअपहरू पनि पूर्ण रूपमा अपलोड हुँदैनन्, किनभने मिडिया सर्भरले वृद्धिशील ब्याकअपहरूबाट पछिल्ला पूर्ण ब्याकअपहरू सङ्कलन गर्दछ।

मध्यवर्ती सर्भरको आफ्नै भण्डारण छ, जहाँ यसले डेटाको "क्यास" लेख्छ र डुप्लिकेशनको लागि डाटाबेस राख्छ।

पूर्ण वास्तुकला यस्तो देखिन्छ:

मास्टर सर्भरले कन्फिगरेसन, अपडेटहरू, आदि व्यवस्थापन गर्दछ र क्लाउडमा अवस्थित छ।
मिडिया सर्भर (मध्यवर्ती *निक्स मेसिन) सञ्जाल पहुँचको सन्दर्भमा अनावश्यक प्रणालीहरूको सबैभन्दा नजिक अवस्थित हुनुपर्छ। यहाँ, सबै आरक्षित मेसिनहरूबाट ब्याकअपको डुप्लिकेशन गरिन्छ।
ब्याकअप गरिएका मेसिनहरूमा त्यहाँ एजेन्टहरू छन् जसले सामान्यतया मिडिया सर्भरमा केवल भण्डारणमा नभएका कुराहरू मात्र पठाउँछन्।

यो सबै एक पूर्ण स्क्यान संग सुरु हुन्छ - यो एक पूर्ण पूर्ण ब्याकअप हो। यस बिन्दुमा, मिडिया सर्भरले सबै लिन्छ, यसलाई डुप्लिकेट गर्दछ र यसलाई 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% सम्म वस्तु भण्डारणमा ब्याकअपको कम्प्याक्ट भण्डारण कसरी गर्ने

समस्या के हो

परिणाम

एक टिप्पणी थप्न Отменить ответ