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

नई कार्यक्षमता

मेमोरी स्नैपशॉट और Iterative माइग्रेशन

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

मुख्य समस्या एक तंत्र का कार्यान्वयन था जो पिछली बार से स्मृति क्षेत्रों को बदल देगा। यह काफी सरलता से काम करता है। प्रक्रिया के सभी मौजूदा पृष्ठों को "स्वच्छ" के रूप में चिह्नित करना संभव है। इस मामले में, कर्नेल उनके लिए लिखने पर रोक लगाता है और अगर कोई ऐसे पृष्ठ पर लिखने की कोशिश करता है, तो एक अपवाद (पेजफॉल्ट) उठाया जाएगा। परिणामस्वरूप, कर्नेल पृष्ठ लिखने की अनुमतियाँ लौटाएगा और इसे गंदे (PME_SOFT_DIRTY) के रूप में चिह्नित करेगा। सभी पृष्ठ गुणों को फ़ाइल / proc / PID / पेजमैप पेजमैप 2 से पढ़ा जा सकता है। हां, मुझे फ़ाइल का दूसरा संस्करण बनाना था, क्योंकि पहले के प्रारूप में बिट्स भाग गए थे, और उनमें से कुछ, वास्तव में, हमेशा शून्य। यह वे थे जो दूसरे संस्करण में रिलीज़ होने में कामयाब रहे।

डिस्क रहित प्रवास

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

यहाँ की ख़ासियत यह है कि हमने अधिकतम को स्मृति की अनावश्यक नकल से बचने की कोशिश की। कर्नेल इन उद्देश्यों के लिए कई सिस्टम कॉल का प्रतिनिधित्व करता है (vmsplic, splice, आदि)। उदाहरण के लिए, प्रक्रिया मेमोरी को एकल कॉपी किए बिना पाइप के माध्यम से भेजा जा सकता है।

संकेत

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

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

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

OpenVZ छवियों से कनवर्टर

पिछले लेखों में यह पहले ही कहा गया था कि CRIU को OpenVZ में मौजूदा चेकपॉइंटिंग तंत्र को बदलना चाहिए और निश्चित रूप से पिछड़ी संगतता को संरक्षित करना चाहिए। मैं आपको एक रहस्य बताता हूँ कि OpenVZ टीम वर्तमान में कर्नेल के नए स्थिर संस्करण पर काम कर रही है। हमेशा की तरह, यह आरएचईएल (7) के अगले संस्करण से कर्नेल पर आधारित होगा। इस प्रक्रिया के साथ, OpenVZ छवियों से CRIU छवियों के लिए एक कनवर्टर विकसित किया जा रहा है। यह कार्य इतना कठिन नहीं है जितना समय लेने वाला है।

नेटलिंक सॉकेट, टीसीपी कनेक्शन माइग्रेशन, vdso रूपांतरण

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

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

प्रौद्योगिकी के

निरंतर एकता

CRIU विकास प्रक्रिया लिनक्स कर्नेल विकास की छवि और समानता में बनाई गई है। मूल सिद्धांत जिनका हम अनुसरण करते हैं:

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

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

जब हम सभी परीक्षणों (सभी पिछड़े संगतता जांच, गैर-विनाशकारी डंप की जांच), सभी कॉन्फ़िगरेशन (दो आर्किटेक्चर, दो कर्नेल संस्करण) पर परीक्षण करना शुरू करते हैं, तो तकनीक पूरी तरह से काम करेगी। यह वह कार्य है जो डेवलपर स्वयं करता है यह महंगा है।

स्टेटिक कोड एनालाइजर

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

परिणामों से प्रेरित होकर, एक अन्य डेवलपर ने हमारे प्रोजेक्ट को scan.coverity.com पर पंजीकृत किया । यहां इंजन क्लैंग-एनालाइज़र की तुलना में कुछ अधिक शक्तिशाली है, लेकिन "झूठी सकारात्मक" की संख्या अधिक है। स्थैतिक विश्लेषक के बारे में मेरी राय यह है: वे लाभ लाते हैं, लेकिन उनकी प्राथमिकता बहुत अधिक नहीं है। यदि आपकी परियोजना परीक्षणों द्वारा अच्छी तरह से कवर की गई है और वे बग नहीं खोजते हैं, तो आप स्थैतिक विश्लेषणकर्ताओं पर समय बिता सकते हैं।

संदर्भ

lwn.net/Articles/546966
lwn.net/Articles/531939
habrahabr.ru/post/152903
habrahabr.ru/post/148413
jenkins-ci.org
ru.wikipedia.org/wiki/CRIU
criu.org