सक्रिय पुनर्स्थापना: क्या आपदा वसूली तेज हो सकती है? बहुत तेज?

महत्वपूर्ण डेटा का बैकअप अच्छा है। लेकिन क्या होगा अगर काम तुरंत जारी रखने की जरूरत है, और हर मिनट मायने रखता है? हम Acronis ने यह जांचने का निर्णय लिया कि सिस्टम को जल्द से जल्द शुरू करने के कार्य को हल करना कितना संभव है। और यह सक्रिय पुनर्स्थापना श्रृंखला में पहली पोस्ट है जिसमें मैं आपको बताऊंगा कि हमने इनोपोलिस यूनिवर्सिटी के साथ परियोजना कैसे शुरू की, हमें क्या समाधान मिला, और आज हम क्या काम कर रहे हैं। विवरण - कटौती के तहत।



नमस्ते! मेरा नाम डौलेट तुम्बाव है, और आज मैं आपके साथ एक ऐसी प्रणाली विकसित करने में अपना अनुभव साझा करना चाहता हूं जो आपदा वसूली में तेजी लाती है। परियोजना के पूरे विकास पथ के बारे में बात करने के लिए, चलो दूर से थोड़ा शुरू करें। मैं वर्तमान में Acronis में काम करता हूं, लेकिन मैं भी एकोपोलिस विश्वविद्यालय का स्नातक हूं, जिसने मैंने सॉफ्टवेयर विकास प्रबंधन (जिसे MSIT-SE के रूप में जाना जाता है) में मास्टर प्रोग्राम में स्नातक किया है। Innopolis एक युवा विश्वविद्यालय है, और पाठ्यक्रम भी छोटा है। लेकिन फिर इसे कार्नेगी मेलन विश्वविद्यालय (कार्नेगी मेलॉन विश्वविद्यालय) के पाठ्यक्रम पर बनाया गया है, जिसमें उपलब्धियों में औद्योगिक परियोजनाओं के रूप में ऐसा विषय है।

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

सक्रिय पुनर्स्थापना - इसकी आवश्यकता क्यों है?

परंपरागत रूप से, आपदा वसूली एक मानक योजना के अनुसार काम करती है। कंप्यूटर के साथ परेशानियों के बाद, आप कुछ बैकअप सिस्टम के वेब इंटरफ़ेस पर जाते हैं, उदाहरण के लिए, Acronis True Image, और बड़े "रिस्टोर" बटन पर क्लिक करें। अगला, आपको एन मिनट इंतजार करने की आवश्यकता है, और उसके बाद ही आप काम करना जारी रख सकते हैं।



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

ड्राइवर की जरूरत ...

ऑपरेटिंग सिस्टम पूरी तरह से समाप्त डिस्क के साथ शुरू करने की उम्मीद करता है। इसलिए, विंडोज डिस्क अखंडता के लिए चेक की एक श्रृंखला आयोजित करता है। सिस्टम कुछ फ़ाइलों की अनुपस्थिति या क्षति में एक सामान्य शुरुआत की अनुमति नहीं देगा जो ओएस को खोजने की उम्मीद है। इस समस्या को हल करने के लिए, डिस्क पर तथाकथित पुनर्निर्देशक फ़ाइलों को बनाने का निर्णय लिया गया था, जो गायब या क्षतिग्रस्त फ़ाइलों को प्रतिस्थापित करती हैं, लेकिन वास्तव में डमी हैं। ऐसे पुनर्निर्देशक बनाने के लिए लंबा नहीं है, क्योंकि वास्तव में उनके पास कोई सामग्री नहीं है।

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

यह एक आदर्श तस्वीर की तरह लग रहा है। हालांकि, वास्तविक दुनिया में, भारी संख्या में नुकसान और संभावित गतिरोध हैं। इनोपॉलिस के स्नातक के साथ, हमने इस पुनर्प्राप्ति परिदृश्य की जांच करने, आरटीओ में लाभ का मूल्यांकन करने का फैसला किया, और यह समझा कि क्या यह दृष्टिकोण संभव है? वास्तव में, बाजार पर ऐसे निर्णय बस उस समय मौजूद नहीं थे।

और अगर मैंने इनोपोलिस से लोगों को सेवा घटक छोड़ने का फैसला किया, तो अंदर एक मिनी-फिल्टर फ़ाइल सिस्टम ड्राइवर पर एकोसिस का काम शुरू हुआ। यह विंडोज कर्नेल टीम द्वारा किया गया था। योजना यह थी:

• OS शुरू करने के शुरुआती चरण में ड्राइवर को चलाएं,
• ऑपरेशन के दौरान, जब उपयोगकर्ता स्थान पूरी तरह से तैयार हो जाता है, तो सेवा डाउनलोड करें
• सेवा चालक अनुरोधों को संसाधित करता है और इसके आगे के कार्य का समन्वय करता है।

ड्राइवर इंजीनियरिंग की सूक्ष्मता

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


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


यदि पुनर्प्राप्ति मोड सक्षम है, तो सेवा ड्राइवर को सूचित करती है कि उसे "रिकवरी" मोड में काम करना है। क्रैश के बाद सिस्टम ठीक हो गया है, और जैसे ही यह डिस्क पर एक फ़ाइल खोलने का अनुरोध करता है, मिनी-फिल्टर को इस ऑपरेशन को रोकना चाहिए, यह अनुरोध स्वयं करें, जांचें कि क्या डिस्क पर ऐसी कोई फ़ाइल है और क्या इसे खोला जा सकता है।

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

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



बेशक, ऑपरेटिंग सिस्टम बहुत धीमी गति से काम करेगा, क्योंकि किसी भी फ़ाइल या लाइब्रेरी को पढ़ना कई चरणों में होता है, और संभवतः दूरस्थ संसाधनों तक पहुंच के साथ। लेकिन तब उपयोगकर्ता जल्द से जल्द काम करना शुरू कर सकता है जबकि वसूली अभी भी हो रही है।

कम चाहिए, और भी कम ...

प्रोटोटाइप ने इसके लायक साबित किया है। लेकिन हमें आगे बढ़ने की जरूरत भी पड़ी, क्योंकि कुछ मामलों में गतिरोध अभी भी होता है। उदाहरण के लिए, ऑपरेटिंग सिस्टम कई थ्रेड्स में विभिन्न पुस्तकालयों का अनुरोध कर सकता है, जो हमारी सेवा को स्वयं बंद करने की ओर ले जाता है।

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

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