तकनीकी सहायता विभाग के मेरे अद्भुत सहयोगी न केवल हानिकारक, बल्कि वीम बैकअप और प्रतिकृति स्थापित करने के लिए उपयोगी टिप्स और ट्रिक्स भी लिखते हैं। नौसिखिए उपयोगकर्ताओं के लिए लेख के प्रकाशन के बाद से , इसके लेखक, एवगेनी इवानोव ने बुखारेस्ट में रोमानियाई टीम के साथ मिलकर काम करना जारी रखा है, वरिष्ठ इंजीनियर के पद से टीम लीडर के पद पर चले गए हैं। लेकिन यूजीन ने तकनीकी और साहित्यिक क्षेत्र को नहीं छोड़ा, जिसके लिए उन्हें बहुत धन्यवाद!
झेन्या के नए लेख में पहले से ही अनुभवी वीम बैकअप और प्रतिकृति विशेषज्ञों के लिए सिफारिशें शामिल हैं, जो बैकअप बुनियादी ढांचे के संसाधनों का सबसे बनाने के कार्य के साथ सामना कर रहे हैं। हालांकि, यह लेख उन लोगों के लिए उपयोगी होगा जो सिर्फ हमारे उत्पाद को स्थापित करने और कॉन्फ़िगर करने की योजना बना रहे हैं।


गर्म ट्यूब समय में लोड वितरण का अनुकूलन

उपयोगी सुझावों के लिए, बिल्ली में आपका स्वागत है।

वितरित स्थापना के लाभों के बारे में

वीम बैकअप और प्रतिकृति विभिन्न घटकों से मिलकर एक मॉड्यूलर सॉफ्टवेयर है, जिसमें से प्रत्येक विशिष्ट कार्य करता है। इन घटकों में वीम बैकअप सर्वर, प्रॉक्सी सर्वर, रिपॉजिटरी, WAN त्वरक और अन्य के केंद्रीय प्रबंध निदेशक हैं। एक मशीन पर कई घटक स्थापित किए जा सकते हैं (बेशक, काफी शक्तिशाली), जो कई उपयोगकर्ता करते हैं। हालाँकि, एक वितरित स्थापना के अपने फायदे हैं, अर्थात्:

• शाखाओं के नेटवर्क वाली कंपनियों के लिए, इन शाखाओं में स्थानीय रूप से आवश्यक घटक स्थापित करना संभव हो जाता है। यह ट्रैफ़िक को अनुकूलित करने में मदद करता है, इसे फिर से स्थानीय स्तर पर आयोजित करता है।
• जैसे-जैसे आपका इन्फ्रास्ट्रक्चर बढ़ता है, आपको अपने बैकअप सॉल्यूशन को स्केल करना होगा। यदि बैकअप अधिक समय लेता है ("बैकअप विंडो बढ़ रहा है"), तो आप एक अतिरिक्त प्रॉक्सी सर्वर स्थापित कर सकते हैं। यदि आपको बैकअप रिपॉजिटरी की क्षमता बढ़ाने की आवश्यकता है, तो आप एक स्केल-आउट बैकअप रिपॉजिटरी को कॉन्फ़िगर कर सकते हैं और आवश्यकतानुसार नए एक्सटेंशन जोड़ सकते हैं।
• कुछ घटकों के लिए, आप निरंतर उपलब्धता (उच्च उपलब्धता) सुनिश्चित कर सकते हैं - उदाहरण के लिए, यदि आपके पास कई प्रॉक्सी सर्वर तैनात हैं और उनमें से एक अचानक बंद हो जाता है, तो अन्य काम करना जारी रखेंगे, और बैकअप प्रभावित नहीं होगा।

यह ध्यान में रखना चाहिए कि वितरित सिस्टम केवल एक उचित लोड वितरण के साथ प्रभावी होंगे। अन्यथा, अड़चनें हो सकती हैं, व्यक्तिगत घटकों का अतिभार - और यह उत्पादकता और मंदी में एक सामान्य गिरावट के साथ भरा हुआ है।

डेटा कैसे प्रसारित किया जाता है?

बैकअप प्रक्रिया के दौरान डेटा कहाँ और कहाँ स्थानांतरित किया जाता है, इसका स्पष्ट विचार रखने के लिए, इस आरेख पर विचार करें (उदाहरण के लिए, vSphere प्लेटफ़ॉर्म पर आधारभूत संरचना लें):



जैसा कि आप देख सकते हैं, दोनों स्थानों में काम करने वाले "ट्रांसपोर्ट एजेंटों" (VeeamAgent.exe) का उपयोग करके डेटा को स्रोत स्थान (स्रोत) से लक्ष्य (लक्ष्य) में स्थानांतरित किया जाता है। इसलिए, जब बैकअप नौकरी चल रही है, तो निम्न होता है:

• "स्रोत" परिवहन एजेंट प्रॉक्सी सर्वर पर चलता है; यह डेटास्टोर से डेटा पढ़ता है, कम्प्रेशन और डिडुप्लीकेशन करता है, और डेटा को इस रूप में "टारगेट" ट्रांसपोर्ट एजेंट को भेजता है।
• यदि CIFS शेयर का उपयोग किया जाता है, तो "लक्ष्य" परिवहन एजेंट रिपॉजिटरी (विंडोज / लिनक्स) या गेटवे (गेटवे सर्वर) पर सीधे चलता है। यह एजेंट, बदले में, अपने पक्ष में भी कटौती करता है और बैकअप फ़ाइल (.VBK, .VIB, आदि) में डेटा को बचाता है।

इस प्रकार, 2 घटक हमेशा डेटा ट्रांसमिशन में शामिल होते हैं, भले ही वे वास्तव में एक ही मशीन पर स्थित हों। समाधान परिनियोजन की योजना बनाते समय इस पर विचार किया जाना चाहिए।

प्रॉक्सी सर्वर और रिपॉजिटरी के बीच लोड संतुलन

सबसे पहले, "कार्य" की अवधारणा को परिभाषित करते हैं। वीम बैकअप और प्रतिकृति शब्दावली में, प्रत्येक कार्य एक वर्चुअल मशीन की एक डिस्क को संसाधित कर रहा है। यही है, यदि आपके पास एक बैकअप कार्य (नौकरी) है, जिसमें प्रत्येक के साथ 2 डिस्क के साथ 5 वीएम शामिल हैं, तो इसका मतलब है कि आपको 10 कार्यों को संसाधित करना होगा (और यदि मशीन में केवल 1 डिस्क है, तो 1 कार्य = 1 वीएम)। वीम बैकअप और प्रतिकृति समानांतर में कई कार्यों को संसाधित करने में सक्षम है, लेकिन उनकी संख्या, निश्चित रूप से, अनंत नहीं है।

इसके गुणों में प्रत्येक प्रॉक्सी सर्वर के लिए, आप समानांतर निष्पादन के लिए अधिकतम कार्यों को निर्दिष्ट कर सकते हैं:



मानक बैकअप संचालन के लिए, रिपॉजिटरी के लिए एक ही व्याख्या होगी: एक कार्य एक वर्चुअल डिस्क से डेटा स्थानांतरित करना है। इंटरफ़ेस में, यह बहुत समान दिखता है:



यहां हमें एक बहुत ही महत्वपूर्ण नियम संख्या 1 को ठीक करना चाहिए : प्रॉक्सी और रिपॉजिटरी संसाधनों को असाइन करते समय और समानांतर प्रसंस्करण के लिए अधिकतम कार्यों को निर्दिष्ट करते समय संतुलन सुनिश्चित करें!

उदाहरण

मान लें कि आपके पास 3 प्रॉक्सी हैं, जिनमें से प्रत्येक समानांतर में 4 कार्यों को संसाधित कर सकता है (यानी, स्रोत वीएम के कुल 12 आभासी डिस्क)। लेकिन रिपॉजिटरी को केवल 4 कार्यों को समानांतर में संसाधित करने के लिए कॉन्फ़िगर किया गया है (यह, वैसे, डिफ़ॉल्ट मान है)। इन सेटिंग्स के साथ, केवल 4 ड्राइव को स्रोत स्थान से गंतव्य के समानांतर में सहेजा जाएगा, हालांकि वे सभी 12 के लिए हो सकते हैं। अर्थात, संसाधन अंडरलोड होंगे।

हालांकि, जब सिंथेटिक पूर्ण बैकअप (और इसी तरह के संचालन) बनाने की बात आती है, तो रिपॉजिटरी के सापेक्ष कार्य की अवधारणा थोड़ा अलग अर्थ लेती है। हमें याद है कि इस तरह के ऑपरेशनों में परदे के पीछे नहीं होते हैं, लेकिन स्थानीय रूप से रिपॉजिटरी (विंडोज या लिनक्स) या (CIFS शेयर के मामले में) गेटवे का उपयोग करके किया जाता है।

इस विकल्प में, सामान्य बैकअप श्रृंखला बनाते समय, कार्य = बैकअप कार्य। यही है, यहाँ समानांतर प्रसंस्करण के लिए 4 कार्यों की सीमा का मतलब होगा कि 4 बैकअप कार्यों के लिए सिंथेटिक बैकअप रिपॉजिटरी पर एक साथ बनाया जा सकता है।

जब मूल वीएम (तथाकथित "प्रति-वीएम स्टोरेज" - प्रति-वीएम), कार्य = 1 वीएम के अनुसार विघटित बैकअप की एक श्रृंखला का निर्माण करना। यही है, यहां समानांतर प्रसंस्करण के लिए 4 कार्यों की सीमा का मतलब होगा कि 4 आभासी मशीनों के लिए 4 VBK फाइलें एक ही समय में रिपॉजिटरी पर उत्पन्न की जा सकती हैं।

इस प्रकार, हम नियम 2 पर आते हैं : बैकअप सेटिंग्स के आधार पर, समान संख्या में कार्यों का अर्थ रिपॉजिटरी पर पूरी तरह से अलग लोड हो सकता है। इसलिए, संसाधनों की योजना बनाते समय, आपको निश्चित रूप से इन्हीं सेटिंग्स को जांचने की आवश्यकता होती है: बैकअप मोड, टास्क शेड्यूल, बैकअप चेन को व्यवस्थित करने का तरीका।

नोट: प्रॉक्सी सेटिंग्स के विपरीत, रिपॉजिटरी कार्यों की संख्या पर सीमा को अक्षम कर सकती है। इस मामले में, रिपॉजिटरी प्रॉक्सी सर्वर से आने वाले सभी डेटा को स्वीकार करेगा। लेकिन यह प्रतिबंधों से केवल एक स्पष्ट स्वतंत्रता है, क्योंकि बैकअप कार्यों के काम में रिपॉजिटरी अधिभार और विफलताओं का खतरा है। इसलिए, हम दृढ़ता से इस सीमा को छोड़ने की अनुशंसा नहीं करते हैं।

एक और उदाहरण

मान लें कि आपके पास एक बैकअप कार्य है जिसमें कुल 100 आभासी डिस्क के साथ काफी बड़ी संख्या में वीएम शामिल हैं। उसी समय, रिपॉजिटरी को "हाथ से (प्रति-वीएम)" बैकअप चेन को स्टोर करने के लिए कॉन्फ़िगर किया गया है। समानांतर प्रसंस्करण सेटिंग्स निम्नानुसार हैं: एक प्रॉक्सी के लिए - एक समय में 10 डिस्क, और रिपॉजिटरी के लिए - कोई प्रतिबंध नहीं हैं। एक वृद्धिशील बैकअप के दौरान, रिपॉजिटरी पर लोड प्रॉक्सी सेटिंग्स के कारण सीमित होगा, और इस प्रकार शेष राशि को बनाए रखा जाएगा। लेकिन फिर एक सिंथेटिक पूर्ण बैकअप बनाने का क्षण आता है। ऐसा बैकअप प्रॉक्सी का उपयोग नहीं करता है, और "सिंथेटिक्स" बनाने के सभी ऑपरेशन रिपॉजिटरी पर विशेष रूप से होते हैं। चूंकि भंडार के लिए कार्यों के समानांतर प्रसंस्करण पर कोई प्रतिबंध नहीं है, इसलिए रिपॉजिटरी सर्वर एक बार में पूरे सौ को संसाधित करने का प्रयास करेगा। इसके लिए महत्वपूर्ण संसाधन तनाव की आवश्यकता होगी और सबसे अधिक संभावना होगी अधिभार।

CIFS शेयर को रिपॉजिटरी के रूप में उपयोग करने की विशेषताएं

यदि आप विंडोज या लिनक्स सर्वर पर आधारित रिपॉजिटरी के साथ काम करते हैं, तो "लक्ष्य" एजेंट सीधे इस सर्वर पर शुरू होता है। हालाँकि, यदि आप रिपॉजिटरी के रूप में CIFS शेयर फ़ोल्डर (CIFS शेयर) का उपयोग करते हैं, तो "लक्ष्य" एजेंट विशेष रूप से इस उद्देश्य के लिए डिज़ाइन की गई मशीन पर शुरू होता है - यह तथाकथित है "गेटवे", जो स्रोत VM की तरफ से एजेंट से आने वाली डेटा स्ट्रीम प्राप्त करेगा। "लक्ष्य" एजेंट इस डेटा को प्राप्त करेगा और फिर CIFS बॉल को डेटा ब्लॉक भेजेगा। इस सहायक मशीन को SMB साझा किए गए फ़ोल्डर्स प्रदान करने वाली मशीन के जितना संभव हो सके उतना पास रखा जाना चाहिए - यह विशेष रूप से स्क्रिप्ट के लिए महत्वपूर्ण है जो WAN कनेक्टिविटी का उपयोग करते हैं।

नियम संख्या 3: आपको सहायक मशीन (प्रॉक्सी \ गेटवे) को एक साइट पर नहीं रखना चाहिए, और सीआईएफएस साझा फ़ोल्डर को किसी अन्य साइट (क्लाउड पर सहित) पर साझा करना चाहिए - अन्यथा आपको निरंतर नेटवर्क समस्याएं होंगी।

आप सिस्टम पर लोड को संतुलित करने के उपरोक्त सभी विचारों के प्रवेश द्वार पर भी आवेदन कर सकते हैं। इसके अलावा, आपको यह ध्यान रखना होगा कि प्रवेश द्वार की 2 अतिरिक्त सेटिंग्स हैं: सर्वर को इसे स्पष्ट रूप से या स्वचालित रूप से चयनित करने के लिए सौंपा जा सकता है:



सिद्धांत रूप में, वेम बैकअप बुनियादी ढांचे में शामिल किसी भी विंडोज सर्वर को इस तरह के प्रवेश द्वार के रूप में इस्तेमाल किया जा सकता है। आपके परिनियोजन परिदृश्य के आधार पर, विकल्पों में से एक आपके लिए उपयुक्त हो सकता है:

• एक स्पष्ट रूप से निर्दिष्ट सर्वर - यह, ज़ाहिर है, बहुत सरल करता है, क्योंकि आपको पता चल जाएगा कि "लक्ष्य" एजेंट किस मशीन पर चल रहा है। इस विकल्प की सिफारिश की जाती है, विशेष रूप से, ऐसे मामलों के लिए जब गेंद तक पहुंच की अनुमति केवल कुछ सर्वरों के साथ-साथ एक वितरित बुनियादी ढांचे के साथ परिदृश्यों के लिए होती है - आप संभवतया उचित लोगों के रूप में लक्ष्य के साथ फ़ाइल सर्वर के पास स्थित मशीन पर एजेंट का उपयोग करना चाहते हैं। गेंद।
• स्वचालित रूप से चयनित सर्वर ( स्वचालित चयन विकल्प)। यहां, चीजें एक दिलचस्प मोड़ लेती हैं: यदि आप कई प्रॉक्सी सर्वर का उपयोग करते हैं, तो इस विकल्प को चुनते हुए, यह पता चला है, इस तथ्य की ओर जाता है कि कार्यक्रम एक से अधिक गेटवे का उपयोग करता है, लोड वितरित करता है। मैं ध्यान देता हूं कि "स्वचालित रूप से" का अर्थ "मनमाने ढंग से" नहीं है - यहाँ पर विशिष्ट चयन नियम लागू होते हैं।

यह कैसे काम करता है?

"लक्ष्य" एजेंट बैकअप शुरू करने वाले प्रॉक्सी सर्वर पर शुरू होता है।

• सामान्य बैकअप श्रृंखला के मामले में, तर्क यह है: यदि कई कार्य हैं जो एक साथ निष्पादित होते हैं, प्रत्येक अपने स्वयं के प्रॉक्सी सर्वर के साथ, तो आप कई "लक्ष्य" एजेंट चला सकते हैं। हालांकि, एक काम के भीतर, तर्क अलग है: भले ही इसमें निहित वीएम विभिन्न प्रॉक्सी द्वारा संसाधित किए जाते हैं, "लक्ष्य" एजेंट केवल एक पर लॉन्च किया जाएगा - उस पर जो पहले काम करना शुरू कर देगा।
• "श्रृंखला" बैकअप श्रृंखला के मामले में, प्रत्येक वीएम के लिए एक अलग "लक्ष्य" एजेंट लॉन्च किया गया है। इस प्रकार, समान कार्य के भीतर भी, लोड वितरण होता है।

सिंथेटिक बैकअप बनाते समय, प्रॉक्सी सर्वर का उपयोग नहीं किया जाता है, और यहां "लक्ष्य" एजेंट को शुरू करने के लिए मशीन को निम्नानुसार चुना जाता है: सहायक माउंट सर्वर (माउंट सर्वर जिस पर फाइलें माउंट की जाती हैं, उदाहरण के लिए, पुनर्प्राप्ति संचालन के दौरान) रिपॉजिटरी के साथ जुड़े, और यह एजेंट शुरू होता है। यदि माउंट सर्वर किसी कारण से अनुपलब्ध है, तो वीम बैकअप के उत्तर में स्विच करना संभव है। जैसा कि आप समझते हैं, इस संस्करण में कोई लोड वितरण नहीं होगा।

इसलिए, मैं दोहराता हूं: ( महत्वपूर्ण! ) ऐसे परिदृश्यों के लिए समानांतर में संसाधित होने वाले कार्यों की संख्या पर सीमा को हटाने की अनुशंसा नहीं की जाती है, क्योंकि "सिंथेटिक्स" के साथ संचालन करते समय यह माउंट सर्वर या यहां तक ​​कि वीम बैकअप सर्वर का एक जबरदस्त अधिभार हो सकता है।

अतिरिक्त सुविधाएँ

स्केलेबल रिपॉजिटरी। SOBR मानक रिपॉजिटरी का एक सेट है (यहाँ उन्हें "extents" कहा जाता है)। यदि आप पहले से ही एसओबीआर का उपयोग करते हैं, तो बैकअप कार्य में इसे निर्दिष्ट करें, और सीमा तक नहीं। सीमा पर, आप कुछ सेटिंग्स का उपयोग कर सकते हैं, उदाहरण के लिए, लोड संतुलन।

नियमित रिपॉजिटरी के लिए काम करने वाले सभी बुनियादी सिद्धांत एसओबीआर के लिए भी काम करते हैं। संसाधनों के उपयोग का अनुकूलन करने के लिए, आप बैकअप के लिए "प्रदर्शन" ("बेहतर प्रदर्शन के लिए ऑप्टिमाइज़ेशन पॉलिसी" ("बेहतर प्रदर्शन के लिए ऑप्टिमाइज़ करें") और पूर्ण वितरण-सीमा-एस के साथ चेन वितरण के साथ एसओबीआर को "क्रिप्टो" भंडारण के साथ सेट करने की सलाह दे सकते हैं।

बैकअप का स्थानांतरण (बैकअप प्रतिलिपि)। यहां, "स्रोत" एजेंट स्रोत भंडार पर काम करेंगे। उपर्युक्त सब कुछ स्रोत रिपॉजिटरी पर भी लागू होता है (केवल इस तथ्य को छोड़कर कि बैकअप कॉपी जॉब ट्रांसफर जॉब के मामले में, "रिपॉजिटरी" स्रोत रिपॉजिटरी के साथ संचालन नहीं किया जाता है)।

नोट: यदि स्रोत रिपॉजिटरी एक CIFS शेयर है, तो "सोर्स" एजेंट उपयुक्त माउंट सर्वर (वीम बैकअप सर्वर पर स्विच करने की क्षमता के साथ) पर शुरू होता है।

अंतर्निहित कटौती के साथ उपकरण। DataDomain और StoreOnce स्टोरेज सिस्टम (और शायद भविष्य में दूसरों के लिए) के लिए, जिसके लिए Veeam के साथ एकीकरण को कॉन्फ़िगर किया गया है, वही विचार CIFS शेयर के लिए भी लागू होते हैं। सोर्स साइड ( कम बैंडविड्थ मोड) पर डिडुप्लीकेशन के साथ स्टोरऑन पर एक रिपॉजिटरी के लिए, रिपॉजिटरी के पास गेटवे को रखने की आवश्यकता केवल प्रासंगिकता खो रही है - एक साइट पर गेटवे को WAN के माध्यम से किसी अन्य साइट पर स्टोरऑन पर डेटा भेजने के लिए कॉन्फ़िगर किया जा सकता है।

पसंदीदा प्रॉक्सी सर्वर। यह फीचर दिखाई दिया, जैसा कि आपको याद है, रिलीज 9.5 में, और "प्रॉक्सी प्राथमिकता सूची" को बनाए रखने के लिए जिम्मेदार है कि कार्यक्रम एक विशिष्ट रिपॉजिटरी के साथ काम करते समय पालन करेगा।



यदि इस सूची से प्रॉक्सी उपलब्ध नहीं है, तो कार्य किसी अन्य उपलब्ध के साथ काम करेगा। हालांकि, अगर प्रॉक्सी तक पहुंच है, लेकिन प्रॉक्सी सर्वर में कार्य को संसाधित करने के लिए मुफ्त स्लॉट नहीं हैं, तो बैकअप कार्य को उन लोगों को निलंबित कर दिया जाएगा। इसलिए, आपको इस सुविधा का बहुत सावधानी से उपयोग करने की आवश्यकता है (और "चालू और भूल गए" शैली में नहीं) - हमारे पास ऐसे उपयोगकर्ता थे जो इस प्रकार बैकअप कार्यों को "लटका" करते थे। आप यहाँ (अंग्रेज़ी में) फ़ीचर के बारे में अधिक पढ़ सकते हैं।

निष्कर्ष में

इससे कोई फर्क नहीं पड़ता है कि आप पहली बार Veeam Backup & Replication स्थापित कर रहे हैं या आप लंबे समय से उपयोगकर्ता हैं - मैं विश्वास करना चाहता हूं कि इस लेख में आपको ऐसी जानकारी मिलेगी जो आपके लिए उपयोगी है और इसकी मदद से बैकअप घटकों के संचालन को अनुकूलित कर सकते हैं या डेटा हानि के संभावित जोखिमों को भी समाप्त कर सकते हैं। यहाँ कुछ और उपयोगी लिंक दिए गए हैं:

• वीम बैकअप और प्रतिकृति: 10 शुरुआती टिप्स
• वीक टेप बैकअप संग्रह के लिए उपयोगी टिप्स
• अनंत स्केलेबल रिपॉजिटरी (SOBR) के बारे में हैबर लेख