🥇Tarantool कार्ट्रिज: Lua ब्याकइन्डलाई तीन लाइनमा काट्दै

Mail.ru समूहमा हामीसँग Tarantool छ - यो लुआमा एउटा एप्लिकेसन सर्भर हो, जुन डाटाबेसको रूपमा पनि दोब्बर हुन्छ (वा उल्टो?)। यो छिटो र राम्रो छ, तर एउटा सर्भरको क्षमता अझै असीमित छैन। ठाडो मापन पनि एक रामबाण उपाय होइन, त्यसैले Tarantool मा तेर्सो मापनका लागि उपकरणहरू छन् - vshard मोड्युल [1]। यसले तपाइँलाई धेरै सर्भरहरूमा डाटा काट्न अनुमति दिन्छ, तर तपाइँले यसलाई सेट अप गर्न र व्यापार तर्क जोड्नको लागि यसको साथ टिंकर गर्नुपर्छ।

शुभ समाचार: हामीले केही ठूला शटहरू सङ्कलन गरेका छौं (जस्तै [2], [3]) र अर्को फ्रेमवर्क सिर्जना गर्यो जसले यस समस्याको समाधानलाई महत्त्वपूर्ण रूपमा सरल बनाउनेछ।

Tarantool कारतूस जटिल वितरण प्रणाली विकास गर्न को लागी एक नयाँ रूपरेखा हो। यसले तपाईंलाई पूर्वाधार समस्याहरू समाधान गर्नुको सट्टा व्यापार तर्क लेख्नमा ध्यान केन्द्रित गर्न अनुमति दिन्छ। यस ढाँचाले कसरी काम गर्छ र यसलाई प्रयोग गरेर वितरित सेवाहरू कसरी लेख्ने भनेर कट तल म तपाईंलाई बताउनेछु।

वास्तवमा समस्या के हो?

हामीसँग टारान्टुला छ, हामीसँग vshard छ - तपाईं अरू के चाहनुहुन्छ?

पहिलो, यो सुविधा को कुरा हो। vshard कन्फिगरेसन Lua तालिकाहरू मार्फत कन्फिगर गरिएको छ। धेरै टारन्टुल प्रक्रियाहरूको वितरण प्रणाली सही रूपमा काम गर्नको लागि, कन्फिगरेसन जताततै समान हुनुपर्छ। कोही पनि यो म्यानुअल रूपमा गर्न चाहँदैनन्। त्यसकारण, सबै प्रकारका लिपिहरू, उत्तरदायी, र तैनाती प्रणालीहरू प्रयोग गरिन्छ।

कार्ट्रिज आफैले vshard कन्फिगरेसन प्रबन्ध गर्दछ, यसले यसको आधारमा गर्छ आफ्नै वितरित कन्फिगरेसन। यो अनिवार्य रूपमा एक साधारण YAML फाइल हो, जसको प्रतिलिपि प्रत्येक Tarantool उदाहरणमा भण्डार गरिएको छ। सरलीकरण भनेको फ्रेमवर्कले नै यसको कन्फिगरेसन अनुगमन गर्छ र यो जताततै समान छ भनी सुनिश्चित गर्दछ।

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

हामीले यी समस्याहरू बारम्बार समाधान गर्यौं, र केही बिन्दुमा हामीले एक दृष्टिकोण विकास गर्न व्यवस्थित गर्यौं जसले अनुप्रयोगसँग यसको सम्पूर्ण जीवन चक्रमा काम गर्न सरल बनायो: सिर्जना, विकास, परीक्षण, CI/CD, मर्मतसम्भार।

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

Tarantool कारतूस को मुख्य विशेषताहरु:

स्वचालित क्लस्टर आर्केस्ट्रा;
नयाँ भूमिकाहरू प्रयोग गरेर अनुप्रयोगको कार्यक्षमता विस्तार गर्दै;
विकास र परिनियोजनको लागि आवेदन टेम्प्लेट;
निर्मित स्वचालित शार्डिंग;
Luatest परीक्षण फ्रेमवर्क संग एकीकरण;
WebUI र API प्रयोग गरेर क्लस्टर व्यवस्थापन;
प्याकेजिङ्ग र तैनाती उपकरणहरू।

नमस्कार संसार!

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

$ tarantoolctl rocks install cartridge-cli
$ export PATH=$PWD/.rocks/bin/:$PATH

यी दुई आदेशहरूले कमाण्ड लाइन उपयोगिताहरू स्थापना गर्नेछ र तपाइँलाई टेम्प्लेटबाट तपाइँको पहिलो अनुप्रयोग सिर्जना गर्न अनुमति दिन्छ:

$ cartridge create --name myapp

र यो हामी के प्राप्त गर्छौं:

myapp/
├── .git/
├── .gitignore
├── app/roles/custom.lua
├── deps.sh
├── init.lua
├── myapp-scm-1.rockspec
├── test
│   ├── helper
│   │   ├── integration.lua
│   │   └── unit.lua
│   ├── helper.lua
│   ├── integration/api_test.lua
│   └── unit/sample_test.lua
└── tmp/

यो तयार-निर्मित "हेलो, वर्ल्ड!" भएको गिट भण्डार हो। आवेदन। यसलाई तुरुन्तै चलाउने प्रयास गरौं, पहिले नै निर्भरताहरू (ढाँचा आफैं सहित) स्थापना गरेर:

$ tarantoolctl rocks make
$ ./init.lua --http-port 8080

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

आवेदन विकास

कल्पना गर्नुहोस्, हामी एक परियोजना डिजाइन गर्दैछौं जसले डाटा प्राप्त गर्नुपर्दछ, यसलाई बचत गर्नुपर्दछ र दिनमा एक पटक रिपोर्ट बनाउनुपर्दछ।

हामी रेखाचित्र कोर्न सुरु गर्छौं र यसमा तीन घटकहरू राख्छौं: गेटवे, भण्डारण र अनुसूचक। हामी आर्किटेक्चरमा थप काम गरिरहेका छौं। हामीले भण्डारणको रूपमा vshard प्रयोग गर्ने भएकोले, हामी योजनामा vshard-router र vshard-storage थप्छौं। न त गेटवे न त अनुसूचकले भण्डारणमा सिधै पहुँच गर्नेछ; राउटर त्यसको लागि हो, जसको लागि यो सिर्जना गरिएको हो।

यो रेखाचित्रले अझै पनि हामीले परियोजनामा निर्माण गर्ने कुरालाई ठ्याक्कै प्रतिनिधित्व गर्दैन किनभने कम्पोनेन्टहरू अमूर्त देखिन्छन्। हामीले अझै पनि यो हेर्नु पर्छ कि यो कसरी वास्तविक टारन्टुलमा प्रक्षेपित हुनेछ - प्रक्रियाद्वारा हाम्रा घटकहरूलाई समूहबद्ध गरौं।

vshard-राउटर र गेटवेलाई छुट्टाछुट्टै उदाहरणहरूमा राख्नमा थोरै बिन्दु छ। यदि यो पहिले नै राउटरको जिम्मेवारी हो भने हामीले किन फेरि नेटवर्क सर्फ गर्न आवश्यक छ? उनीहरूलाई एउटै प्रक्रियामा चलाउनु पर्छ। अर्थात्, दुबै गेटवे र vshard.router.cfg एउटै प्रक्रियामा प्रारम्भ गरिएका छन्, र तिनीहरूलाई स्थानीय रूपमा अन्तरक्रिया गर्न दिनुहोस्।

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

र जब स्टेजिङ वा उत्पादनमा डिप्लोइमेन्टको कुरा आउँछ, तब हामी हार्डवेयर क्षमताहरूको आधारमा प्रत्येक टारान्टूल प्रक्रियालाई आफ्नै भूमिकाहरूको सेट तोक्ने छौँ:

टोपोलोजी व्यवस्थापन

कुन भूमिकाहरू चलिरहेका छन् भन्ने बारे जानकारी कतै भण्डार गरिएको हुनुपर्छ। र यो "कहीँ" वितरित कन्फिगरेसन हो, जुन मैले माथि उल्लेख गरेको छु। यसको बारेमा सबैभन्दा महत्त्वपूर्ण कुरा क्लस्टर टोपोलोजी हो। यहाँ 3 Tarantool प्रक्रियाहरूको 5 प्रतिकृति समूहहरू छन्:

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

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

भूमिकाको जीवन

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

function init()
function validate_config()
function apply_config()
function stop()

प्रत्येक भूमिका एक प्रकार्य छ init। यो एक पटक बोलाइन्छ जब भूमिका सक्षम हुन्छ वा जब Tarantool पुन: सुरु हुन्छ। यो त्यहाँ सुविधाजनक छ, उदाहरणका लागि, box.space.create प्रारम्भ गर्न, वा अनुसूचकले केही पृष्ठभूमि फाइबर सुरु गर्न सक्छ जसले निश्चित समय अन्तरालहरूमा काम गर्नेछ।

एउटा कार्य init पर्याप्त नहुन सक्छ। कार्ट्रिजले भूमिकाहरूलाई वितरित कन्फिगरेसनको फाइदा लिन अनुमति दिन्छ जुन यसले टोपोलोजी भण्डारण गर्न प्रयोग गर्दछ। हामी एउटै कन्फिगरेसनमा नयाँ खण्ड घोषणा गर्न सक्छौं र यसमा व्यापार कन्फिगरेसनको टुक्रा भण्डारण गर्न सक्छौं। मेरो उदाहरणमा, यो डेटा स्कीमा वा अनुसूचक भूमिकाको लागि तालिका सेटिङ हुन सक्छ।

क्लस्टर कलहरू validate_config и apply_config प्रत्येक पटक वितरित कन्फिगरेसन परिवर्तन हुन्छ। जब कन्फिगरेसन दुई-चरण प्रतिबद्धताद्वारा लागू गरिन्छ, क्लस्टरले जाँच गर्दछ कि प्रत्येक भूमिका यो नयाँ कन्फिगरेसन स्वीकार गर्न तयार छ र आवश्यक भएमा, प्रयोगकर्तालाई त्रुटि रिपोर्ट गर्दछ। जब सबै सहमत हुन्छन् कि कन्फिगरेसन सामान्य छ, त्यसपछि apply_config.

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

भूमिकाहरू एकअर्कासँग अन्तरक्रिया गर्न सक्छन्। हामी Lua मा प्रकार्य कलहरू लेख्न प्रयोग गरिन्छ, तर यो हुन सक्छ कि दिइएको प्रक्रियामा हामीलाई आवश्यक भूमिका छैन। नेटवर्कमा कलहरू सहज बनाउन, हामी rpc (रिमोट प्रक्रिया कल) सहायक मोड्युल प्रयोग गर्छौं, जुन Tarantool मा निर्मित मानक नेटबक्सको आधारमा बनाइएको छ। यो उपयोगी हुन सक्छ यदि, उदाहरणका लागि, तपाईंको गेटवेले एक दिन पर्खनुको सट्टा सिधै समयसूचकलाई काम गर्नको लागि सोध्न चाहन्छ।

अर्को महत्त्वपूर्ण बिन्दु गल्ती सहिष्णुता सुनिश्चित गर्नु हो। Cartridge स्वास्थ्य निगरानी गर्न SWIM प्रोटोकल प्रयोग गर्दछ [4]। छोटकरीमा, प्रक्रियाहरूले UDP मा एकअर्कासँग "अफवाहहरू" आदानप्रदान गर्छन्—प्रत्येक प्रक्रियाले आफ्ना छिमेकीहरूलाई नवीनतम समाचारहरू बताउँछ, र तिनीहरूले प्रतिक्रिया दिन्छन्। अचानक जवाफ नआएमा, टारन्टुलले केहि गडबड भएको शंका गर्न थाल्छ, र केहि समय पछि मृत्यु सम्झन्छ र यो खबर वरपर सबैलाई बताउन थाल्छ।

यस प्रोटोकलको आधारमा, कार्ट्रिजले स्वचालित विफलता प्रशोधनलाई व्यवस्थित गर्दछ। प्रत्येक प्रक्रियाले यसको वातावरण अनुगमन गर्दछ, र यदि नेताले अचानक प्रतिक्रिया गर्न रोक्छ भने, प्रतिकृतिले आफ्नो भूमिका लिन सक्छ, र कार्ट्रिजले तदनुसार चलिरहेको भूमिकाहरू कन्फिगर गर्दछ।

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

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

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

परिनियोजन उपकरणहरू

मैले देखाउने वाचा गरें कि कारट्रिजले कसरी अनुप्रयोगहरू प्रयोग गर्न मद्दत गर्दछ। अरूको लागि जीवन सजिलो बनाउन, फ्रेमवर्क प्याकेजहरू RPM प्याकेजहरू:

$ cartridge pack rpm myapp -- упакует для нас ./myapp-0.1.0-1.rpm
$ sudo yum install ./myapp-0.1.0-1.rpm

स्थापित प्याकेजले तपाईलाई चाहिने लगभग सबै चीजहरू समावेश गर्दछ: दुबै अनुप्रयोग र स्थापित निर्भरताहरू। Tarantool पनि RPM प्याकेजको निर्भरताको रूपमा सर्भरमा आइपुग्छ, र हाम्रो सेवा सुरु गर्न तयार छ। यो systemd मार्फत गरिन्छ, तर पहिले तपाईंले सानो कन्फिगरेसन लेख्न आवश्यक छ। न्यूनतममा, प्रत्येक प्रक्रियाको URI निर्दिष्ट गर्नुहोस्। उदाहरण को लागी तीन पर्याप्त छ।

$ sudo tee /etc/tarantool/conf.d/demo.yml <<CONFIG
myapp.router: {"advertise_uri": "localhost:3301", "http_port": 8080}
myapp.storage_A: {"advertise_uri": "localhost:3302", "http_enabled": False}
myapp.storage_B: {"advertise_uri": "localhost:3303", "http_enabled": False}
CONFIG

यहाँ एक रोचक nuance छ। केवल बाइनरी प्रोटोकल पोर्ट निर्दिष्ट गर्नुको सट्टा, हामी होस्टनाम सहित प्रक्रियाको सम्पूर्ण सार्वजनिक ठेगाना निर्दिष्ट गर्दछौं। यो आवश्यक छ ताकि क्लस्टर नोडहरू एकअर्कासँग कसरी जडान गर्ने भनेर जान्दछन्। advertise_uri ठेगानाको रूपमा 0.0.0.0 प्रयोग गर्नु नराम्रो विचार हो; यो सकेट बाइन्ड होइन, बाह्य IP ठेगाना हुनुपर्छ। यो बिना, केहि पनि काम गर्दैन, त्यसैले कार्ट्रिजले तपाईलाई गलत advertise_uri को साथ नोड सुरु गर्न दिदैन।

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

$ sudo systemctl start myapp@router
$ sudo systemctl start myapp@storage_A
$ sudo systemctl start myapp@storage_B

कन्फिगरेसनमा, हामीले HTTP पोर्ट निर्दिष्ट गरेका छौं जसमा कार्ट्रिजले वेब इन्टरफेस सेवा गर्दछ - 8080। यसमा जानुहोस् र एक नजर हेरौं:

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

तपाईंको मनपर्ने पेयको गिलास खन्याऔं र लामो काम हप्ता पछि आराम गर्नुहोस्। अनुप्रयोग प्रयोग गर्न सकिन्छ।