पाँच विद्यार्थी र तीन जनाले कुञ्जी-मूल्य स्टोरहरू वितरण गरे

वा हामीले कसरी ZooKeeper, etcd र Consul KV को लागि ग्राहक C++ पुस्तकालय लेख्यौं

वितरित प्रणालीहरूको संसारमा, त्यहाँ धेरै विशिष्ट कार्यहरू छन्: क्लस्टरको संरचनाको बारेमा जानकारी भण्डारण गर्ने, नोडहरूको कन्फिगरेसन प्रबन्ध गर्ने, दोषपूर्ण नोडहरू पत्ता लगाउने, नेता छनौट गर्ने। र अन्य। यी समस्याहरू समाधान गर्न, विशेष वितरण प्रणाली सिर्जना गरिएको छ - समन्वय सेवाहरू। अब हामी ती मध्ये तीनमा रुचि राख्नेछौं: ZooKeeper, etcd र Consul। Consul को सबै समृद्ध कार्यक्षमताहरु मध्ये, हामी Consul KV मा ध्यान केन्द्रित गर्नेछौं।

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

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

हामीले ZooKeeper, etcd र Consul KV सँग काम गर्नको लागि साझा इन्टरफेस प्रदान गर्ने पुस्तकालय सिर्जना गर्न व्यवस्थित गर्यौं। पुस्तकालय C++ मा लेखिएको छ, तर यसलाई अन्य भाषाहरूमा पोर्ट गर्ने योजनाहरू छन्।

डाटा मोडेलहरू

तीन फरक प्रणालीहरूको लागि साझा इन्टरफेस विकास गर्न, तपाईंले तिनीहरूमा के साझा छ र तिनीहरू कसरी फरक छन् भनेर बुझ्न आवश्यक छ। यसलाई बाहिर निकालौं।

चिडियाखाना

कुञ्जीहरू रूखमा व्यवस्थित हुन्छन् र नोडहरू भनिन्छ। तदनुसार, नोडको लागि तपाईंले यसको बच्चाहरूको सूची प्राप्त गर्न सक्नुहुन्छ। एक znode (सिर्जना) र मान (setData) परिवर्तन गर्ने कार्यहरू अलग गरिएको छ: अवस्थित कुञ्जीहरू मात्र पढ्न र परिवर्तन गर्न सकिन्छ। घडीहरू नोडको अस्तित्व जाँच गर्ने, मूल्य पढ्ने र बच्चाहरू प्राप्त गर्ने कार्यहरूमा संलग्न गर्न सकिन्छ। वाच एक पटकको ट्रिगर हो जुन सर्भरमा सम्बन्धित डाटाको संस्करण परिवर्तन हुँदा सक्रिय हुन्छ। Ephemeral नोडहरू विफलताहरू पत्ता लगाउन प्रयोग गरिन्छ। तिनीहरू ग्राहकको सत्रमा बाँधिएका छन् जसले तिनीहरूलाई सिर्जना गरेको छ। जब क्लाइन्टले सत्र बन्द गर्छ वा ZooKeeper लाई यसको अस्तित्वको सूचित गर्न रोक्छ, यी नोडहरू स्वचालित रूपमा मेटिन्छन्। साधारण लेनदेनहरू समर्थित छन् - अपरेसनहरूको सेट जुन कि त सबै सफल हुन्छन् वा असफल हुन्छन् यदि यो कम्तिमा एकको लागि सम्भव छैन।

आदि

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

etcd सँग मानक तुलना-र-सेट अपरेशन छैन, तर यसमा केहि राम्रो छ: लेनदेन। अवश्य पनि, तिनीहरू सबै तीन प्रणालीहरूमा अवस्थित छन्, तर etcd लेनदेनहरू विशेष गरी राम्रो छन्। तिनीहरू तीन ब्लकहरू हुन्छन्: जाँच, सफलता, असफलता। पहिलो ब्लकले सर्तहरूको सेट समावेश गर्दछ, दोस्रो र तेस्रो - सञ्चालन। लेनदेन परमाणु रूपमा कार्यान्वयन गरिन्छ। यदि सबै सर्तहरू सत्य छन् भने, सफलता ब्लक कार्यान्वयन गरिन्छ, अन्यथा असफलता ब्लक कार्यान्वयन हुन्छ। API 3.3 मा, सफलता र विफलता ब्लकहरूले नेस्टेड लेनदेनहरू समावेश गर्न सक्छन्। त्यो हो, लगभग मनमानी नेस्टिंग स्तरको सशर्त निर्माणहरू परमाणु रूपमा कार्यान्वयन गर्न सम्भव छ। तपाईले जाँच र सञ्चालनहरू के बाट अवस्थित छ भन्ने बारे थप जान्न सक्नुहुन्छ कागजात.

घडीहरू यहाँ पनि अवस्थित छन्, यद्यपि तिनीहरू अलि बढी जटिल छन् र पुन: प्रयोगयोग्य छन्। त्यो हो, कुञ्जी दायरामा घडी स्थापना गरेपछि, तपाईंले यो दायरामा सबै अद्यावधिकहरू प्राप्त गर्नुहुनेछ जबसम्म तपाईंले घडी रद्द नगरेसम्म, पहिलो मात्र होइन। आदिमा, ZooKeeper ग्राहक सत्रहरूको एनालग पट्टाहरू हुन्।

कन्सुल के.वी.

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

घडीहरूको सट्टा, कन्सुलले HTTP अनुरोधहरू अवरुद्ध गरेको छ। संक्षेपमा, यी डाटा पढ्ने विधिमा सामान्य कलहरू हुन्, जसको लागि, अन्य प्यारामिटरहरूसँगै, डाटाको अन्तिम ज्ञात संस्करण संकेत गरिएको छ। यदि सर्भरमा सम्बन्धित डाटाको हालको संस्करण निर्दिष्ट गरिएको भन्दा ठूलो छ भने, प्रतिक्रिया तुरुन्तै फर्काइन्छ, अन्यथा - जब मान परिवर्तन हुन्छ। त्यहाँ कुनै पनि समयमा कुञ्जीहरू संलग्न गर्न सकिने सत्रहरू छन्। यो नोट गर्न लायक छ कि etcd र ZooKeeper को विपरीत, जहाँ सत्रहरू मेटाउँदा सम्बन्धित कुञ्जीहरू मेटिन्छ, त्यहाँ एक मोड छ जसमा सत्र तिनीहरूबाट मात्र अनलिङ्क गरिएको छ। उपलब्ध छ लेनदेन, शाखाहरू बिना, तर सबै प्रकारका चेकहरूको साथ।

यो सबै एक साथ राख्दै

ZooKeeper सँग सबैभन्दा कठोर डाटा मोडेल छ। etcd मा उपलब्ध अभिव्यक्त दायरा प्रश्नहरू प्रभावकारी रूपमा ZooKeeper वा Consul मा अनुकरण गर्न सकिँदैन। सबै सेवाहरूबाट उत्कृष्ट समावेश गर्ने प्रयास गर्दै, हामीले निम्न महत्त्वपूर्ण अपवादहरूको साथ ZooKeeper इन्टरफेसको लगभग बराबरको इन्टरफेसको साथ समाप्त गर्यौं:

• अनुक्रम, कन्टेनर र TTL नोडहरू मेला खाएन
• ACL हरू समर्थित छैनन्
• यदि यो अवस्थित छैन भने सेट विधिले एउटा कुञ्जी सिर्जना गर्दछ (ZK setData मा यस अवस्थामा त्रुटि फर्काउँछ)
• सेट र क्यास विधिहरू अलग छन् (ZK मा तिनीहरू अनिवार्य रूपमा एउटै कुरा हुन्)
• मेटाउने विधिले नोडलाई यसको सबट्रीको साथ मेटाउँछ (जेडके डिलिटमा नोडमा बच्चाहरू भएमा त्रुटि फर्काउँछ)
• प्रत्येक कुञ्जीको लागि त्यहाँ एक मात्र संस्करण छ - मूल्य संस्करण (ZK मा त्यहाँ ती मध्ये तीन छन्)

अनुक्रमिक नोडहरूको अस्वीकृति तथ्यको कारणले गर्दा हो कि etcd र Consul सँग तिनीहरूको लागि निर्मित समर्थन छैन, र तिनीहरू सजिलैसँग प्रयोगकर्ताद्वारा नतिजा पुस्तकालय इन्टरफेसको शीर्षमा लागू गर्न सकिन्छ।

भेर्टेक्स मेटाउँदा ZooKeeper जस्तै व्यवहार लागू गर्न etcd र Consul मा प्रत्येक कुञ्जीको लागि छुट्टै चाइल्ड काउन्टर कायम राख्न आवश्यक पर्दछ। हामीले मेटा जानकारी भण्डारण गर्नबाट जोगिन प्रयास गरेकोले, यो सम्पूर्ण सबट्री मेटाउने निर्णय गरियो।

कार्यान्वयनको सूक्ष्मताहरू

विभिन्न प्रणालीहरूमा पुस्तकालय इन्टरफेस लागू गर्ने केही पक्षहरूलाई नजिकबाट हेरौं।

आदिमा पदानुक्रम

etcd मा पदानुक्रमिक दृश्य कायम राख्नु सबैभन्दा रोचक कार्यहरू मध्ये एक हुन गयो। दायरा प्रश्नहरूले निर्दिष्ट उपसर्गको साथ कुञ्जीहरूको सूची पुन: प्राप्त गर्न सजिलो बनाउँदछ। उदाहरणका लागि, यदि तपाईंलाई सुरु हुने सबै कुरा चाहिन्छ "/foo", तपाइँ दायराको लागि सोध्दै हुनुहुन्छ ["/foo", "/fop")। तर यसले कुञ्जीको सम्पूर्ण सबट्री फर्काउनेछ, जुन सबट्री ठूलो भएमा स्वीकार्य नहुन सक्छ। सुरुमा हामीले कुञ्जी अनुवाद संयन्त्र प्रयोग गर्ने योजना बनायौं, zetcd मा लागू गरियो। यसले कुञ्जीको सुरुमा एउटा बाइट थप्ने समावेश गर्दछ, रूखको नोडको गहिराइ बराबर। म तपाईंलाई एउटा उदाहरण दिन्छु।

"/foo" -> "u01/foo"
"/foo/bar" -> "u02/foo/bar"

त्यसपछि चाबीको सबै तत्काल बच्चाहरू प्राप्त गर्नुहोस् "/foo" दायरा अनुरोध गरेर सम्भव छ ["u02/foo/", "u02/foo0")। हो, ASCII मा "0" ठीक पछि खडा छ "/".

तर कसरी यस मामला मा एक ठाडो हटाउने कार्यान्वयन गर्न? यो बाहिर जान्छ कि तपाइँ प्रकार को सबै दायरा मेटाउन आवश्यक छ ["uXX/foo/", "uXX/foo0") XX को लागि ०१ देखि FF सम्म। अनि हामी भित्र पस्यौं सञ्चालन संख्या सीमा एक लेनदेन भित्र।

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

"/very" -> "/u00very"
"/very/long" -> "/very/u00long"
"/very/long/path" -> "/very/long/u00path"

त्यसपछि कुञ्जी मेटाउने "/very" मेटाइमा परिणत हुन्छ "/u00very" र दायरा ["/very/", "/very0"), र सबै बच्चाहरू प्राप्त गर्दै - दायराबाट कुञ्जीहरूको लागि अनुरोधमा ["/very/u00", "/very/u01").

ZooKeeper मा कुञ्जी हटाउँदै

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

यो दृष्टिकोणले कुञ्जी मेटाउन धेरै प्रभावकारी बनाउँदछ यदि यसमा बच्चाहरू छन् भने, र अझ बढी यदि अनुप्रयोगले सबट्रीसँग काम गर्न जारी राख्छ भने, मेटाउने र कुञ्जीहरू सिर्जना गर्दछ। यद्यपि, यसले हामीलाई etcd र Consul मा अन्य विधिहरूको कार्यान्वयनलाई जटिल बनाउनबाट जोगिन अनुमति दियो।

ZooKeeper मा सेट

ZooKeeper मा रूख संरचना (create, delete, getChildren) सँग काम गर्ने र नोडहरूमा डेटा (setData, getData) सँग काम गर्ने छुट्टै विधिहरू छन्। यसबाहेक, सबै विधिहरूमा कडा पूर्वसर्तहरू छन्: सिर्जनाले त्रुटि फर्काउनेछ यदि नोड पहिले नै छ भने। सिर्जना गरिएको, मेटाउने वा सेट डाटा - यदि यो पहिले नै अवस्थित छैन। हामीलाई एक सेट विधि चाहिन्छ जुन कुञ्जीको उपस्थितिको बारेमा सोच नगरी कल गर्न सकिन्छ।

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

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

थप प्राविधिक विवरण

यस खण्डमा हामी वितरित प्रणालीहरूबाट विश्राम लिनेछौं र कोडिङको बारेमा कुरा गर्नेछौं।
ग्राहकको मुख्य आवश्यकताहरू मध्ये एक क्रस-प्लेटफर्म थियो: कम्तिमा एउटा सेवा लिनक्स, MacOS र Windows मा समर्थित हुनुपर्छ। सुरुमा, हामीले लिनक्सको लागि मात्र विकास गर्यौं, र पछि अन्य प्रणालीहरूमा परीक्षण सुरु गर्यौं। यसले धेरै समस्याहरू निम्त्यायो, जुन केहि समयको लागि पूर्ण रूपमा अस्पष्ट थियो कसरी पुग्ने। फलस्वरूप, सबै तीन समन्वय सेवाहरू अब Linux र MacOS मा समर्थित छन्, जबकि Consul KV मात्र Windows मा समर्थित छ।

सुरुदेखि नै, हामीले सेवाहरू पहुँच गर्न तयार पुस्तकालयहरू प्रयोग गर्ने प्रयास गर्यौं। ZooKeeper को मामला मा, छनोट मा पर्यो ZooKeeper C++, जुन अन्ततः Windows मा कम्पाइल गर्न असफल भयो। यो, तथापि, आश्चर्यजनक छैन: पुस्तकालय linux-मात्र को रूपमा स्थित छ। कन्सुलको लागि एकमात्र विकल्प थियो ppconsul। यसमा समर्थन थप्नुपर्यो सत्रहरू и लेनदेन। etcd को लागि, प्रोटोकलको नवीनतम संस्करण समर्थन गर्ने पूर्ण पुस्तकालय फेला परेन, त्यसैले हामी केवल उत्पन्न grpc ग्राहक.

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

हाम्रो त्यसबेलाको कार्यान्वयनले यसरी काम गर्छ। बोलाउँदा, थप वाचा/भविष्यको जोडी सिर्जना गरिन्छ। नयाँ भविष्य फर्काइन्छ, र पास भएकोलाई सम्बन्धित प्रकार्य र लाममा थप वाचा सहित राखिएको छ। पूलबाट एउटा थ्रेडले लामबाट धेरै फ्युचरहरू चयन गर्छ र wait_for प्रयोग गरेर तिनीहरूलाई मतदान गर्छ। जब नतिजा उपलब्ध हुन्छ, सम्बन्धित प्रकार्य भनिन्छ र यसको फिर्ती मूल्य प्रतिज्ञामा पारित हुन्छ।

हामीले etcd र Consul लाई प्रश्नहरू कार्यान्वयन गर्न एउटै थ्रेड पूल प्रयोग गर्यौं। यसको मतलब अन्तर्निहित पुस्तकालयहरू धेरै फरक थ्रेडहरूद्वारा पहुँच गर्न सकिन्छ। ppconsul थ्रेड सुरक्षित छैन, त्यसैले यसमा कलहरू लकहरूद्वारा सुरक्षित छन्।
तपाईं धेरै थ्रेडहरूबाट grpc सँग काम गर्न सक्नुहुन्छ, तर त्यहाँ सूक्ष्मताहरू छन्। आदिमा घडीहरू grpc स्ट्रिमहरू मार्फत लागू गरिन्छ। यी निश्चित प्रकारका सन्देशहरूका लागि द्विदिशात्मक च्यानलहरू हुन्। पुस्तकालयले सबै घडीहरूको लागि एकल थ्रेड र आगमन सन्देशहरू प्रशोधन गर्ने एकल थ्रेड सिर्जना गर्दछ। त्यसैले grpc ले स्ट्रिममा समानान्तर लेख्न निषेध गर्छ। यसको मतलब यो हो कि घडी सुरु गर्दा वा मेटाउँदा, तपाईंले अर्को पठाउनु अघि अघिल्लो अनुरोध पठाउन पूरा नभएसम्म पर्खनु पर्छ। हामी सिङ्क्रोनाइजेसनको लागि प्रयोग गर्छौं सशर्त चरहरू.

परिणाम

आफैलाई हेर्नुहोस्: liboffkv.

हाम्रो समूह: Raed Romanov, इवान ग्लुसेन्कोभ, दिमित्री कमलदिनोभ, भिक्टर क्रापिभेन्स्की, Vitaly Ivanin.

स्रोत: www.habr.com