Google क्लाउड प्लेटफ़ॉर्म पर पलायन (Google क्लाउड प्लेटफ़ॉर्म - GCP)

[भाग २ का २]

[भाग १ का २]

हमने कैसे किया

हमने पैमाने को बढ़ाते हुए, लेकिन बेहतर प्रदर्शन के बिना - जीसीपी पर स्विच करने का फैसला किया। पूरी प्रक्रिया में 2 महीने से अधिक का समय लगा। इस समस्या को हल करने के लिए, हमने इंजीनियरों का एक विशेष समूह बनाया है।

इस प्रकाशन में, हम चुने हुए दृष्टिकोण और इसके कार्यान्वयन के बारे में बात करेंगे, साथ ही साथ हम कैसे मुख्य लक्ष्य को प्राप्त करने में कामयाब रहे - इस प्रक्रिया को सुचारू रूप से चलाने के लिए और उपयोगकर्ता सेवा की गुणवत्ता से समझौता किए बिना पूरे बुनियादी ढाँचे को Google क्लाउड प्लेटफ़ॉर्म पर स्थानांतरित करें।

आयोजन

1. प्रत्येक संभावित चरण की पहचान के लिए एक विस्तृत चेकलिस्ट तैयार की गई है। अनुक्रम का वर्णन करने के लिए एक फ़्लोचार्ट बनाया गया है।
2. एक रीसेट योजना विकसित की गई है कि हम, अगर कुछ भी, उपयोग कर सकते हैं।

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

निर्भरता आरेख और परिचालन सुरक्षा आवश्यकताओं के आधार पर, हमने बुनियादी ढांचा सेवाओं को 9 मॉड्यूल में विभाजित किया है।

(होस्टिंग बुनियादी ढांचे की तैनाती के लिए बुनियादी मॉड्यूल)

प्रत्येक बुनियादी ढांचा समूह ने आम आंतरिक और बाहरी सेवाओं का प्रबंधन किया।

HTTP इन्फ्रास्ट्रक्चर मैसेजिंग सेवा : एमक्यूटीटी, एचटीटीपी, थ्रिफ्ट, गुनिकोर्न सर्वर, कतारबद्ध मॉड्यूल, एसिंक्स क्लाइंट, जेट्टी सर्वर, काफ्का क्लस्टर।
⊹ डेटा वेयरहाउस सेवाएं : वितरित क्लस्टर MongoDB, Redis, Cassandra, Hbase, MySQL और MongoDB।
Data अवसंरचना विश्लेषण सेवा : काफ्का क्लस्टर, डेटा वेयरहाउस क्लस्टर (HDFS, HIVE)।

एक महत्वपूर्ण दिन की तैयारी:

Sequence प्रत्येक सेवा के लिए GCP पर स्विच करने के लिए एक विस्तृत योजना: अनुक्रम, डेटा वेयरहाउस, रीसेट करने की योजना।
Isol क्रॉस-प्रोजेक्ट नेटवर्क इंटरैक्शन (साझा वर्चुअल प्राइवेट क्लाउड वीपीसी [एक्सपीएन]) जीसीपी में बुनियादी ढांचे के विभिन्न हिस्सों को अलग करने, प्रबंधन को अनुकूलित करने, सुरक्षा और कनेक्टिविटी में सुधार करने के लिए।
And प्रतिकृति के दौरान नेटवर्क पर बड़ी मात्रा में डेटा के हस्तांतरण को सरल बनाने के लिए GCP और चल रहे वर्चुअल प्राइवेट क्लाउड (VPC) के बीच कई वीपीएन सुरंग, साथ ही साथ समानांतर सिस्टम की संभावित बाद की तैनाती के लिए।
। बावर्ची प्रणाली का उपयोग करके पूरे स्टैक की स्वचालित स्थापना और कॉन्फ़िगरेशन।
Monitoring तैनाती, निगरानी, ​​प्रवेश, आदि के लिए लिपियों और स्वचालन उपकरण।
✓ सिस्टम स्ट्रीम के लिए सभी आवश्यक सबनेट और प्रबंधित फ़ायरवॉल नियम कॉन्फ़िगर करें।
। सभी भंडारण प्रणालियों के लिए कई डेटा केंद्रों (मल्टी-डीसी) में प्रतिकृति।
B लोड बैलेंसरों (GLB / ILB) और प्रबंधित उदाहरण समूहों (MIG) को कॉन्फ़िगर करें।
Container लिपियों और कोड को चौकियों के साथ वस्तु भंडारण कंटेनर को GCP क्लाउड स्टोरेज में स्थानांतरित करना।

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

संक्रमण

लोड बैलेंसर ट्रांसफर रणनीति:

हमने पहले उपयोग किए गए HAProxy प्रबंधित क्लस्टर को प्रतिदिन लाखों सक्रिय उपयोगकर्ता कनेक्शन के दसियों को संसाधित करने के लिए एक वैश्विक लोड बैलेंसर के साथ बदल दिया।

⊹ स्टेज 1:

• मौजूदा क्लाउड में MQTT IP पते पर सभी ट्रैफ़िक को अग्रेषित करने के लिए पैकेट अग्रेषण नियमों के साथ MIG बनाए गए हैं।
• एक SSL और टीसीपी प्रॉक्सी प्रॉक्सी बैलेंस को MIG के साथ सर्वर पार्ट के रूप में बनाया गया है।
• MIG के लिए, HAProxy को MQTT सर्वर के साथ सर्वर भाग के रूप में लॉन्च किया गया है।
• DNS में, एक भार-आधारित रूटिंग नीति ने एक बाहरी GLB IP पता जोड़ा है।

उनके प्रदर्शन को ट्रैक करते समय उपयोगकर्ता कनेक्शन धीरे-धीरे तैनात किए जाते हैं।

Services चरण 2: मील का पत्थर संक्रमण, जीसीपी में सेवाओं की तैनाती शुरू करें।
All स्टेज 3: संक्रमण के अंतिम चरण, सभी सेवाओं को GCP में स्थानांतरित किया जाता है।

(लोड बैलेंसर के हस्तांतरण के चरण)

इस स्तर पर, सब कुछ उम्मीद के मुताबिक काम किया। जल्द ही, जीसीपी में रूटिंग के साथ कई आंतरिक HTTP सेवाओं को तैनात करने का समय था - गुणांक के वजन को देखते हुए। हमने सभी संकेतकों पर बारीकी से नजर रखी। जब हमने धीरे-धीरे ट्रैफ़िक बढ़ाना शुरू किया, तो नियोजित संक्रमण से एक दिन पहले, वीपीएन के माध्यम से वीपीसी (40 एमएस - 100 एमएस की देरी) के माध्यम से बातचीत में देरी दर्ज की गई थी, हालांकि पहले वे 10 एमएस से कम थे।

(दो VPCs बातचीत करते समय नेटवर्क देरी की जाँच का स्नैपशॉट)

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

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

डेटाबेस प्रवासन की रणनीति:

एक रिलेशनल DBMS, इन-मेमोरी स्टोरेज, साथ ही NoSQL और कम लेटेंसी के साथ वितरित और स्केलेबल क्लस्टर के लिए 50 से अधिक डेटाबेस एंडपॉइंट को स्थानांतरित करना आवश्यक था। हमने GCP में सभी डेटाबेस की प्रतिकृतियां रखी हैं। यह HBase को छोड़कर सभी तैनाती के लिए किया गया था।

⊹ मास्टर-दास प्रतिकृति: MySQL, Redis, MongoDB और MongoS समूहों के लिए लागू की गई।
मल्टी मल्टी-डीसी प्रतिकृति: कैसंड्रा समूहों के लिए लागू की गई।
: दोहरी क्लस्टर: GCP में Gbase के लिए एक समानांतर क्लस्टर कॉन्फ़िगर किया गया है। मौजूदा डेटा माइग्रेट किया गया था, दोनों समूहों में डेटा स्थिरता बनाए रखने की रणनीति के अनुसार डबल एंट्री को कॉन्फ़िगर किया गया था।

HBase के मामले में, समस्या अंबारी के साथ स्थापित हो रही थी। कई डेटा केंद्रों में क्लस्टर रखते समय हमें कुछ कठिनाइयों का सामना करना पड़ा, उदाहरण के लिए, DNS, एक रैक पहचान स्क्रिप्ट आदि के साथ समस्याएं थीं।

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

अनुप्रयोग सेवाएँ स्थानांतरण रणनीति

वर्तमान होस्टिंग से GCP क्लाउड में एप्लिकेशन सेवाओं के कार्यभार को स्थानांतरित करने के लिए, हमने लिफ्ट-एंड-शिफ्ट दृष्टिकोण का उपयोग किया। प्रत्येक एप्लिकेशन सेवा के लिए, हमने स्वचालित स्केलिंग के साथ प्रबंधित इंस्टेंस (MIG) का एक समूह बनाया।

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

सुबह में, जैसे ही उपयोगकर्ता गतिविधि में वृद्धि हुई, हमने समस्याओं को जल्दी से पहचानने के लिए सभी डैशबोर्ड और संकेतकों का सावधानीपूर्वक पालन किया। कुछ कठिनाइयाँ वास्तव में उत्पन्न हुईं, लेकिन हम उन्हें जल्दी से समाप्त करने में सक्षम थे। समस्याओं में से एक आंतरिक लोड बैलेंसर (ILB) की सीमाओं के कारण था, जो 20,000 से अधिक समवर्ती कनेक्शनों को नहीं संभाल सकता है। और हमें 8 गुना अधिक की आवश्यकता थी! इसलिए, हमने अपने कनेक्शन प्रबंधन परत में अतिरिक्त ILB जोड़े।

संक्रमण के बाद पीक लोड के पहले घंटों में, हमने सभी मापदंडों को विशेष रूप से सावधानीपूर्वक नियंत्रित किया, क्योंकि मैसेजिंग स्टैक का पूरा भार जीसीपी को स्थानांतरित कर दिया गया था। कुछ मामूली गड़बड़ियां थीं जिन्हें हम बहुत जल्दी से निपटा लेते हैं। अन्य सेवाओं को स्थानांतरित करते समय, हमने वही दृष्टिकोण अपनाया।

ऑब्जेक्ट संग्रहण माइग्रेशन:

हम मुख्य रूप से तीन तरीकों से ऑब्जेक्ट स्टोरेज सेवा का उपयोग करते हैं।

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

हमने S3 से GCS में पुरानी वस्तुओं को कॉपी करने के लिए Google के स्टोरेज ट्रांसफर टूल का उपयोग किया। विशेष तर्क की आवश्यकता होने पर हमने वस्तुओं को S3 से GCS में स्थानांतरित करने के लिए एक कस्टम काफ्का-आधारित MIG का भी उपयोग किया।

S3 से GCS के परिवर्तन में निम्नलिखित चरण शामिल थे:

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