Amazon Web Services में डेटा और MySQL का बैकअप कैसे लें

सभी को नमस्कार!
मैं अमेज़न वेब सेवाओं में फ़ाइल बैकअप और MySQL / XtraDB के आयोजन के अनुभव को साझा करना चाहता हूं। मुझे उम्मीद है कि जानकारी काम में आएगी, खासकर यदि आप क्लाउड में परियोजनाओं को तैनात करने के लिए "मजबूर" हैं, और समय सीमित है :-)
लेकिन सबसे पहले, अमेज़ॅन द्वारा प्रस्तुत डेटा भंडारण प्रौद्योगिकियों के बारे में संक्षेप में बताएं।

वर्चुअल मशीन डेटा कहाँ रहते हैं?

तो, चलिए शुरू करते हैं कि अमेज़ॅन हमें वर्चुअल मशीन डेटा - वर्चुअल ईबीएस ब्लॉक डिवाइस को स्टोर करने के लिए क्या प्रदान करता है। ऐसी डिस्क आसानी से बनाई जाती है और 2 क्लिक में सर्वर से जुड़ी होती है। अधिकतम डिस्क आकार 1TB है। डिफ़ॉल्ट रूप से, 5000 ड्राइव और 20TB पर सीमा होती है, लेकिन पहले अनुरोध पर इसे बढ़ाया जाता है ।
स्थानीय ब्लॉक उपकरणों की तकनीक भी प्रस्तावित है, जिस पर डेटा ... सर्वर के साथ गायब हो जाता है (और यह आसानी से हो सकता है जब मशीन दुर्घटनाग्रस्त हो जाती है) - लेकिन मुझे इसके बारे में लिखना नहीं चाहिए, क्योंकि हमने इसके साथ प्रयोग नहीं किया।

ईबीएस प्रदर्शन

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

रीड?

अमेज़ॅन डिस्क के साथ पर्याप्त रूप से काम करना शुरू करने के लिए, सबसे आसान तरीका उन्हें सॉफ्टवेयर छापे में "बंद" करना है। डेटाबेस के लिए, हम ext4 और xfs दोनों पर 8 ईबीएस डिस्क पर छापे -10 का उपयोग करते हैं। एक सॉफ्टवेयर छापा काफी सरलता से किया जाता है , यह लंबे समय तक काम करता है और व्यावहारिक रूप से टूटता नहीं है।
यदि ईबीएस ड्राइव अचानक दुर्घटनाग्रस्त हो जाए तो एक छापा विशेष रूप से उपयोगी हो सकता है।
फिर भी, कुछ कार्यों के लिए हम छापे का उपयोग नहीं करते हैं - उदाहरण के लिए, MySQL बाइनरी लॉग को संग्रहीत करने के लिए, बैकअप के लिए, आदि और nginx कैश को संग्रहीत करने के लिए, ईबीएस डिस्क पर raid0 ने अच्छी तरह से काम किया, जो लगभग एक साल से विफलताओं के साथ लगातार काम कर रहा है।

ईबीएस ड्राइव विश्वसनीयता

ईमानदार होने के लिए, अमेजन ईबीएस-डिस्क के साथ काम करने के डेढ़ साल तक, उन्होंने हमें कभी निराश नहीं किया (कोई बुरी चीज़ जैसे "खराब", त्रुटियों को पढ़ना आदि) ... मामले को छोड़कर जब बिजली ने अमेज़ॅन के आयरिश डेटा सेंटर को मारा, तो कई डिस्क एक ही बार में उड़ गईं। छापे से -10 :-)
हालांकि, अगर आप ध्यान से पढ़ते हैं कि अमेज़ॅन ने अपने डिस्क की विश्वसनीयता के बारे में क्या लिखा है, तो आप समझते हैं कि आपको छापे और निश्चित रूप से नियमित बैकअप करने की आवश्यकता है:
अमेज़ॅन ईबीएस वॉल्यूम डेटा किसी भी एकल घटक की विफलता से डेटा के नुकसान को रोकने के लिए एक उपलब्धता क्षेत्र में कई सर्वरों पर दोहराया जाता है। आपके वॉल्यूम का स्थायित्व आपके वॉल्यूम के आकार और आपके पिछले स्नैपशॉट के बाद से बदल चुके डेटा का प्रतिशत दोनों पर निर्भर करता है। उदाहरण के रूप में, ऐसे वॉल्यूम जो 20 जीबी या उससे कम संशोधित डेटा के साथ काम करते हैं क्योंकि उनके सबसे हाल के अमेज़ॅन ईबीएस स्नैपशॉट 0.1% - 0.5% के बीच वार्षिक विफलता दर (एएफआर) की उम्मीद कर सकते हैं, जहां विफलता वॉल्यूम की पूर्ण हानि को संदर्भित करती है। यह कमोडिटी हार्ड डिस्क के साथ तुलना करता है जो आमतौर पर लगभग 4% के एएफआर के साथ विफल हो जाता है, जिससे ईबीएस वॉल्यूम ठेठ डिस्क ड्राइव की तुलना में 10 गुना अधिक विश्वसनीय होता है।
दूसरी ओर, हमारे पास उत्पादन में एक सौ से अधिक लोड किए गए ईबीएस डिस्क हैं और डेढ़ साल में, आईओ त्रुटियों के कारण सॉफ्टवेयर छापों ने कभी भी डिस्क खटखटाया नहीं है। मुझे यकीन है कि हम "आयरन" डिस्क पर एक से अधिक उपकरण बदल चुके होंगे, इसलिए निष्कर्ष निकालना।

उपलब्ध बैकअप तकनीक

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

1. केवल परिवर्तन ईबीएस डिस्क के अगले स्नैपशॉट में मिलता है। इसके अलावा, यह पूरी तरह से पारदर्शी है और यह स्पष्ट हो जाता है जब आप डिस्क स्थान के उपयोग पर मासिक बिल को देखते हैं। भले ही आपके पास 500GB डिस्क से 100 स्नैपशॉट हैं, लेकिन डेटा अक्सर नहीं बदला - आप लगभग 600-800GB के लिए भुगतान करते हैं, जो निश्चित रूप से क्लाइंट के पक्ष में खेलता है।
2. आप बैकअप विंडो के आकार और डेटा स्टोरेज की लागत के बीच संतुलन बनाए रखने के लिए स्नैपशॉट हटा सकते हैं और रखना चाहिए। इस मामले में, जो प्रसन्नता का कारण बनता है, आप किसी भी स्नैपशॉट को हटा सकते हैं - अमेज़न स्वचालित रूप से डेटा को सही तरीके से समेकित करता है। और यह इस विषय पर मेरे सिर को चोट नहीं पहुंचाता है - जहां मूल स्नैपशॉट है, और जहां वृद्धिशील स्नैपशॉट है - यह कोई फर्क नहीं पड़ता है, आप किसी भी स्थिति से सुपरफ़्लस को हटा देते हैं (जो Acronis काम करने वालों की सुविधा की सराहना करेंगे)।
3. S3 में डिस्क के स्नैपशॉट सहेजे गए हैं। S3 - जैसा कि हर कोई शायद पहले से ही जानता है, यह किसी भी प्रारूप की वस्तुओं का भंडार है जो कम से कम दूसरे 2 डेटा केंद्रों को डेटा दोहराता है। यानी डिस्क का स्नैपशॉट व्यावहारिक रूप से "अविनाशी" हो जाता है और डेस्कटॉप :-) के तहत एक बंद नाइटस्टैंड में हार्ड ड्राइव की तुलना में अधिक विश्वसनीय रूप से संग्रहीत होता है।
4. डिस्क का स्नैपशॉट लगभग तुरंत किया जाता है - फिर पृष्ठभूमि में डेटा को एक निश्चित समय के लिए S3 में स्थानांतरित किया जाता है (कभी-कभी दस मिनट - अगर अमेज़ॅन लोड किया जाता है)।

इसका मतलब यह है कि हम हर 5 मिनट में कम से कम एक बार डिस्क पर सामग्री को बदलने के एक विशाल फ़ोल्डर का स्नैपशॉट ले सकते हैं - उन्हें S3 में सुरक्षित रूप से संग्रहीत किया जाएगा और यदि आपको 5 मिनट पहले 1TB के परस्पर डेटा को वापस करने की आवश्यकता है - हम इसे आसानी से कर सकते हैं:

1. सहेजे गए स्नैपशॉट से डिस्क बनाएं ।
2. हम एक डिस्क को सर्वर से कनेक्ट करते हैं।

बेशक, यह तकनीकी रूप से असंभव है कि S3 से SAN में तुरंत डेटा का 1TB ट्रांसफर किया जाए, जहां EBS लाइव होता है, इसलिए हालांकि ब्लॉक डिवाइस ऑपरेटिंग सिस्टम के लिए उपलब्ध हो जाता है, एक निश्चित समय के लिए बैकग्राउंड में डेटा इस पर डाला जाएगा - इसलिए, पहली बार में डिस्क के साथ काम करने की गति बहुत अधिक नहीं होगी। लेकिन, फिर भी, आपको सहमत होना होगा कि बड़ी मात्रा में डेटा का वृद्धिशील बैकअप लेना कितना सुविधाजनक है और इसे किसी भी बिंदु पर वापस रोल करना है, उदाहरण के लिए, 5 मिनट के चरण के साथ एक सप्ताह पहले? :-)
ईबीएस-ड्राइव से स्नैपशॉट बनाने की क्षमता के अलावा, आप सीधे एस 3 को फाइलें भेज सकते हैं। S3cmd उपयोगिता का उपयोग करना सुविधाजनक है - आप दोनों दिशाओं में क्लाउड के साथ फाइलसिस्टम के पेड़ों को सिंक्रनाइज़ कर सकते हैं (केवल स्थानीय डिस्क पर md5 की गणना और "ETag" में s3 के अंदर md5 ऑब्जेक्ट के भंडारण के आधार पर परिवर्तन को स्थानांतरित किया जाता है)। हमने FUSE - s3fs तकनीक पर आधारित समाधानों की कोशिश की, लेकिन इसके गहन उपयोग के दौरान ला में वृद्धि के साथ मंदी और दीर्घकालिक फ्रीज को देखा।

स्नैपशॉट छापा

जैसा कि मैंने ऊपर लिखा है, ईबीएस डिस्क पर्याप्त प्रदर्शन दिखाते हैं अगर वे raid0, raid10 में संयुक्त होते हैं। कैसे करें छापेमारी? क्या प्रत्येक डिस्क का स्नैपशॉट बदले में है? :-) हम समझते हैं कि यह असंभव है और यहाँ अमेज़न हमें कुछ भी प्रदान नहीं करता है।
अच्छे लोगों ने एक उपयोगी उपयोगिता लिखी - ec2- सुसंगत-स्नैपशॉट । आप इसका उपयोग कर सकते हैं, या आप लिपियों में इसके तर्क को दोहरा सकते हैं।

1. हम एक फ़ाइल सिस्टम का उपयोग करते हैं जो "ठंड" का समर्थन करता है - अर्थात यह महसूस करते हुए कि वह अब ब्लॉक डिवाइस स्तर पर एक स्नैपशॉट ले रही है और बफ़र्स को फ्लश करना, लेन-देन करना और अस्थायी रूप से किराए में बदलाव करना आवश्यक है। हाल तक तक, XFS ने इस कमांड ( xfs_freeze ) को समझा था, लेकिन "नवीनतम" लिनक्स वितरणों में अन्य सामान्य फ़ाइल सिस्टम: ext3 / ext4, xfs, jfs, reiserfs को "फ्रीज" करना संभव हो गया।
2. हम परिवर्तनों को त्याग देते हैं और एफएस को संक्षेप में लिखने पर रोक लगाते हैं: "fsfreeze -f माउंटपॉइंट"
3. प्रत्येक RAID डिस्क का स्नैपशॉट बनाना: AWS API कॉल CreateSnapshot ।
4. FS प्रविष्टि की अनुमति दें: "fsfreeze -u माउंटपॉइंट"

यदि आपके पास xfs हैं, तो आप xfs_freeze कमांड का उपयोग कर सकते हैं।
एक सहेजे गए छापे को जोड़ने के लिए, एक स्क्रिप्ट लिखना बेहतर है जो डिस्क को मशीन से जोड़ता है और उनसे एक सॉफ्टवेयर छापे को लॉन्च करता है। उपरोक्त विधि द्वारा स्नैपशॉट में सहेजी गई छापे फाइल सिस्टम लॉग को खोए बिना खूबसूरती से उगती है - हम इसे उत्पादन में विभिन्न स्थानों पर उपयोग करते हैं।
इसलिए, हमने सीखा कि कैसे s3 में स्नैपशॉट छापे, जिसमें प्रत्येक 5 मिनट में कम से कम एक बार आवृत्ति के साथ डेटा की मात्रा होती है और उनके साथ डेटा पुनर्प्राप्त होता है। मुझे यकीन है कि इस तरह की चीजें क्लाउड में कई परियोजनाओं पर उपयोगी होंगी।

पूरे मशीन स्नैपशॉट

कभी-कभी प्रत्येक छापे के साथ अलग से स्नान नहीं करना अधिक सुविधाजनक होता है, लेकिन एक कमांड के साथ मशीन के सभी ड्राइव का स्नैपशॉट बनाने के लिए। आप 2 मोड में एक स्नैपशॉट बना सकते हैं: एक कार स्टॉप के साथ और एक स्टॉप के बिना। बाद के मामले में, हमें तार्किक रूप से डिस्क / छापे पर डेटा के संभावित "भ्रष्टाचार" के बारे में चेतावनी दी जाती है:
किसी फ़ाइल सिस्टम का स्नैपशॉट लेते समय, हम पहले इसे अनमाउंट करने की सलाह देते हैं। यह सुनिश्चित करता है कि फ़ाइल सिस्टम मेटाडेटा एक सुसंगत स्थिति में है, कि 'माउंटेड इंडिकेटर' को मंजूरी दे दी गई है, और उस फ़ाइल सिस्टम का उपयोग करने वाले सभी एप्लिकेशन बंद हो जाते हैं और एक सुसंगत स्थिति में होते हैं। कुछ फ़ाइल सिस्टम, जैसे कि एक्सएफ़एस, गतिविधि को फ्रीज़ और अनफ़्रीज़ कर सकते हैं ताकि स्नैपशॉट को अनमाउंट किए बिना बनाया जा सके।
मशीन स्नैपशॉट बनाने के बाद, एएमआई (अमेज़ॅन मशीन इमेज) ऑब्जेक्ट दिखाई देता है, जिसमें प्रत्येक ड्राइव के सहेजे गए स्नैपशॉट के लिंक होते हैं। आप एक आदेश के साथ इस ऑब्जेक्ट से सभी डिस्क / छापे के साथ एक सर्वर चला सकते हैं - AWS API कॉल RunInstances । क्या आपको प्रौद्योगिकी की शक्ति महसूस हुई? काम करने वाले सर्वर न केवल अपनी संपूर्णता में बैकअप ले सकते हैं, बल्कि एक टीम के साथ सभी छापे वाले बैकअप कुल से भी उठाए जा सकते हैं! इस तकनीक ने हमें पिछले साल अगस्त में हुई अमेजन दुर्घटना की स्थिति में दर्जनों घंटे के सिस्टम एडमिनिस्ट्रेशन से बचाया - हमने मशीनों को स्नैपशॉट से बाहर निकाल दिया और दूसरे डेटा सेंटर में कॉन्फ़िगरेशन को तैनात किया।
हालाँकि, एक गंभीर गड़बड़ी है - CreateImage कमांड पूरी तरह से अपारदर्शी है और यह स्पष्ट नहीं है कि सभी सर्वर डिस्क से स्नैपशॉट लेने में कितना समय लगता है - एक दूसरा या 10 सेकंड? वैज्ञानिक पोकिंग की विधि को अंतराल - 5 सेकंड चुना गया, जिससे आप मशीन की पूरी छवियों को छापे से शूट कर सकते हैं। मैं आपको चेतावनी देता हूं - उत्पादन में लॉन्च करने से पहले स्क्रिप्ट का पूरी तरह से परीक्षण करें - हालांकि, मशीन की पूरी बैकअप बनाने के लिए तकनीक के "उपहार" से पहले, आपको स्वीकार करना होगा कि इसका विरोध करना मुश्किल है :-)

MySQL वृद्धिशील बैकअप

मुझे अपने काम की याद दिलाएं - प्रति दिन लाखों हिट्स के ट्रैफिक के साथ एक प्रोजेक्ट को बैकअप करने के लिए और सैकड़ों गीगाबाइट सामग्री जो अक्सर बदलती है (सबसे भारी सामग्री को s3 में स्थानांतरित कर दिया गया है और अलग से डाउनलोड किया गया है)। मैं MySQL बैकअप के लिए अच्छी तरह से ज्ञात उचित दृष्टिकोण दोहराऊंगा:

1. गुलाम के साथ तार्किक बैकअप। इस मामले में, हम मुख्य सर्वर के संचालन को धीमा नहीं करते हैं, हालांकि ... हम "सिंक से बाहर" डेटा का बैकअप लेने का जोखिम उठाते हैं (इसलिए आपको सिंक्रनाइज़ेशन की निगरानी करने की आवश्यकता है, उदाहरण के लिए pt-table-checkum का उपयोग करके)।
2. एक मुकाबला सर्वर / दास से LVM का उपयोग कर बाइनरी स्नैपशॉट, या - बैकअप मशीन पर एक DRBD डिस्क के लिए ब्लॉक कॉपी।
3. एक मुकाबला सर्वर या दास से xtrabackup या इसी तरह के भुगतान किए गए उपकरण का उपयोग करके इंक्रीमेंटल बाइनरी बैकअप।

डेटाबेस में डेटा के एक भयावह विलोपन की स्थिति में 5-10 मिनट पहले एक बड़े ऑनलाइन स्टोर को जल्दी से वापस रोल करने में सक्षम होने के लिए (एक गलत अनुरोध जो कई ऑर्डर तालिकाओं में डेटा को मारता है - जो अन्य के साथ नहीं था? :-)) - ऐसा लगता है कि केवल 3 विकल्प काम करेगा? । हालांकि, जैसा कि यह निकला, सृजन पर बाइनरी वृद्धिशील बैकअप पहले से ही कमजोर ईबीएस डिस्क पर काफी भार डालती है, लेकिन वसूली के दौरान बुनियादी बाइनरी बैकअप को बहाल करने में कई घंटे लग सकते हैं ... कई घंटे!
मैं यहां MySQL बाइनरी लॉग के प्रारंभिक संपादन के साथ तार्किक बैकअप से पुनर्प्राप्ति परिदृश्यों पर विचार नहीं करता - यह अभी भी ऐसा करने के लिए तेज़ नहीं है।
और यहाँ फिर से अमेज़न हमारी मदद करता है। MySQL वृद्धिशील बैकअप इस तरह किया जाता है:

1. फ़्लश MySQL / InnoDB / XtraDB बफ़र्स डिस्क के लिए: "पढ़ें लॉक के साथ फ्लश टेबल"
2. हम परिवर्तनों को त्याग देते हैं और एफएस को संक्षेप में लिखने पर रोक लगाते हैं: "fsfreeze -f माउंटपॉइंट"
3. हम मशीन के सभी डिस्क का एक स्नैपशॉट बनाते हैं: CreateImage । ऊपर देखें नुकसान के लिए। यदि चिंताएँ हैं, तो हम डेटाबेस से प्रत्येक RAID डिस्क का स्नैपशॉट बनाते हैं: AWS API कॉल CreateSnapshot ।
4. FS प्रविष्टि की अनुमति दें: "fsfreeze -u माउंटपॉइंट"
5. हम सभी डेटाबेस में सभी तालिकाओं के वैश्विक लॉकिंग को हटा देते हैं: "अनलॉक टैब"।

अब हमारे पास गर्म MySQL बैकअप के साथ एक एएमआई ऑब्जेक्ट है और हमने इसे बैकअप से जल्दी से जल्दी शुरू करने के लिए अधिकतम संभव बना दिया है।
इस प्रकार, यह एस 5 में कम से कम एक बार की आवृत्ति और जल्दी से उत्पादन में प्रवेश करने की क्षमता के साथ एस 3 में MySQL सर्वर का एक वृद्धिशील बैकअप बनाने के लिए सुखद निकला। यदि सर्वर को प्रतिकृति में उपयोग किया जाता है, तो वह इसे पुनर्स्थापित करेगा, एक नियम के रूप में, बिना किसी समस्या के, यदि आप सेटिंग्स में रूढ़िवादी प्रतिकृति सेटिंग्स सेट करना नहीं भूल गए हैं (अच्छी तरह से, या आप इसे मैन्युअल रूप से बहुत जल्दी काम करने के लिए वापस कर सकते हैं)
Sync_binlog = 1
innodb_flush_log_at_trx_commit = 1
Sync_master_info = 1
Sync_relay_log = 1
Sync_relay_log_info = 1

कैसे अमेज़न के साथ स्क्रिप्ट कार्रवाई करने के लिए?

सिस्टम व्यवस्थापक के लिए, सुविधाजनक उपयोगिताओं हैं जो अमेज़ॅन रीस्ट विधियों को खींचती हैं। उपयोग की जाने वाली प्रत्येक वेब सेवा के लिए कई उपयोगिताओं को डाउनलोड किया जाता है, और उपयोगिताओं के लिए कॉल बैश में लिखे जाते हैं। यहाँ एक स्क्रिप्ट का एक उदाहरण है जो एक सर्वर पर हार्डवेयर बदलता है:

#!/bin/bash #Change cluster node hw type #Which node to change hardware? NODE_INSTANCE_ID=$1 #To which hw-type to change? #Some 64-bit hw types: t1.micro (1 core, 613M), m1.large (2 cores, 7.5G), m1.xlarge (4 cores, 15G), #m2.xlarge (2 cores, 17G), c1.xlarge (8 cores, 7G) NODE_TARGET_TYPE='c1.xlarge' #To which reserved elastic ip to bind node? NODE_ELASTIC_IP=$2 ec2-stop-instances $NODE_INSTANCE_ID while ec2-describe-instances $NODE_INSTANCE_ID | grep -q stopping do sleep 5 echo 'Waiting' done ec2-modify-instance-attribute --instance-type $NODE_TARGET_TYPE $NODE_INSTANCE_ID ec2-start-instances $NODE_INSTANCE_ID ec2-associate-address $NODE_ELASTIC_IP -i $NODE_INSTANCE_ID 

डेवलपर्स के लिए, अमेज़ॅन एपीआई के साथ काम करने के लिए विभिन्न भाषाओं में पुस्तकालय हैं। यहाँ PHP के लिए काम करने के लिए पुस्तकालय है - PHP के लिए AWS एसडीके ।
जैसा कि आप देख सकते हैं, अमेज़ॅन ऑब्जेक्ट्स के साथ स्क्रिप्टिंग का काम सरल है।

पुनश्च

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