दैनिक दुर्घटनाओं से लेकर स्थिरता तक: 10 प्रशासन की आंखों के साथ सूचनात्मक

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

यदि प्रिय पाठक पहले से ही हमारे डेटा वेयरहाउस प्रोजेक्ट और इनफॉर्मेटा पावरकेंटर उत्पाद से परिचित हैं, तो आप अगले भाग पर जा सकते हैं।

कुछ साल पहले, एक एकल कॉर्पोरेट डेटा वेयरहाउस का विचार परिपक्व हुआ और रोस्टेलेकॉम में लागू होना शुरू हुआ। व्यक्तिगत कार्यों को हल करने वाले कई स्टोर पहले से ही बनाए गए थे, लेकिन परिदृश्यों की संख्या बढ़ रही थी, समर्थन लागत भी बढ़ रही थी, और यह स्पष्ट हो गया कि भविष्य केंद्रीकृत था। आर्किटेक्चरल रूप से, यह रिपॉजिटरी है, जिसमें कई लेयर्स शामिल हैं, जिसे Hadoop और GreenPlum, सहायक डेटाबेस, ETL मैकेनिज्म और BI पर लागू किया गया है।

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

हमारे भंडारण के बारे में अधिक जानकारी निम्नलिखित में से एक पोस्ट में चर्चा की जाएगी।

Informatica PowerCenter / Big Data Management को वर्तमान में डेटा इंटीग्रेशन टूल्स के क्षेत्र में अग्रणी सॉफ्टवेयर माना जाता है। यह अमेरिकी कंपनी Informatica का एक उत्पाद है, जो ETL (एक्सट्रैक्ट ट्रांसफॉर्म लोड), डेटा क्वालिटी मैनेजमेंट, MDM (मास्टर डेटा मैनेजमेंट), ILM (इंफॉर्मेशन लाइफसाइकल मैनेजमेंट) और सबसे मजबूत खिलाड़ियों में से एक है।

हमारे द्वारा उपयोग किया जाने वाला पॉवरकैंटर एक एकीकृत टोमैट एप्लिकेशन सर्वर है, जिसमें इंफॉर्मेटिका स्वयं अपनी सेवाओं को लागू करने के लिए आवेदन करती है:

डोमेन , वास्तव में, बाकी सब के लिए आधार है; डोमेन के भीतर, सेवाओं, उपयोगकर्ताओं और GRID घटक काम करते हैं।

इंफोर्मेटिका डेवलपर क्लाइंट के अलावा एक वेब-आधारित प्रबंधन और निगरानी उपकरण प्रशासक कंसोल , उत्पाद के साथ बातचीत करने का मुख्य उपकरण

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

DIS, डेटा इंटीग्रेशन सर्विस , एक ऐसी सेवा है जिसमें मुख्य कार्यात्मक प्रक्रियाएं होती हैं, अनुप्रयोग इसमें काम करते हैं और वर्कफ़्लोज़ (मैपिंग और उनके इंटरैक्शन के अनुक्रम का वर्णन) और मैपिंग (परिवर्तन, जिसमें परिवर्तन स्वयं, डेटा प्रोसेसिंग) होते हैं।

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


Informatica PowerCenter, योजनाबद्ध

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


पूर्व सूचनात्मक लोगो

अन्य Informatica वातावरण भी हमारी जिम्मेदारी के क्षेत्र का हिस्सा हैं, एक अलग भार के कारण उनकी अपनी विशिष्टताएं हैं, लेकिन अब मैं ठीक से याद करूंगा कि कैसे Informatica डेटा गोदाम के एक ETL घटक के रूप में विकसित हुआ।

यह कैसे हुआ?

2016 में, जब हम Informatica के लिए जिम्मेदार हो गए, तो यह पहले से ही संस्करण 10.0 तक पहुंच गया, और आशावादी सहयोगियों के लिए, जिन्होंने एक गंभीर समाधान में मामूली संस्करण .0 के साथ एक उत्पाद का उपयोग करने का फैसला किया, सब कुछ स्पष्ट लग रहा था - आपको नए संस्करण का उपयोग करने की आवश्यकता है! हार्डवेयर संसाधनों के दृष्टिकोण से, उस समय सब कुछ उत्कृष्ट था।

2016 के वसंत के बाद से, ठेकेदार Informatica के काम के लिए जिम्मेदार था, और सिस्टम के कुछ उपयोगकर्ताओं के अनुसार, "इसने सप्ताह में कई बार काम किया"। यहां यह समझाना आवश्यक है कि पीओसी चरण में भंडारण वास्तविक था, टीम में कोई प्रशासक नहीं थे और सिस्टम लगातार विभिन्न कारणों से दुर्घटनाग्रस्त हो गया, जिसके बाद ठेकेदार इंजीनियर ने इसे फिर से उठाया।

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

हमारी टीम और कॉन्ट्रैक्टर के डेवलपर्स के लिए पहली बात हमें वेब-आधारित प्रशासन कंसोल (Informatica एडमिनिस्ट्रेटर) को चालू करने के लिए Informatica के कार्य को स्थिर करना था।


इसलिए हम अक्सर Informatica डेवलपर्स से मिले

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


Informatica मॉनिटर काम करने के प्रयासों में से एक है

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


कार्य को स्थिर करने के लिए जावा मापदंडों का चयन

समस्या कई मायनों में तय की गई थी, मापदंडों को बदलने के लिए प्रयोगों का आयोजन किया गया था, लॉग एकत्र किए गए थे, समर्थन में jstack भेजा गया था, उसी समय सक्रिय googling चल रहा था और अवलोकन बस आयोजित किया गया था।

सबसे पहले, निगरानी के लिए एक अलग एमआरएस बनाया गया था, क्योंकि यह बाद में हमारे वातावरण में संसाधनों के मुख्य उपभोक्ताओं में से एक निकला, क्योंकि मैपिंग बहुत गहन रूप से शुरू की गई हैं। जावा ढेर के बारे में पैरामीटर, और कई अन्य को बदल दिया गया था।
नतीजतन, Informatica 10.1.1 का अगला अपडेट कंसोल और मॉनिटर को स्थिर करने में कामयाब रहा, डेवलपर्स ने अधिक कुशलता से काम करना शुरू कर दिया, और नियमित प्रक्रियाएं अधिक नियमित हो गईं।

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

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

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

यहां आपको समर्थन का धन्यवाद करने की आवश्यकता है, ईबीएफ (इमरजेंसी बग फिक्स) का उपयोग करके समस्याओं को जल्दी से स्थानीयकृत और तय किया गया था - जिसके बाद हर किसी को लग रहा था कि उपकरण वास्तव में काम कर रहा था।

यह अभी भी काम करता है!

जब तक लक्ष्य मोड में काम शुरू हुआ, तब तक Informatica इस प्रकार दिखता था। Informatica संस्करण 10.1.1HF1 (HF1, HotFix1, EBF कॉम्प्लेक्स की एक वेंडर असेंबली है) अतिरिक्त EBF के साथ स्थापित है जो हमारी स्केलिंग की समस्याओं और कुछ अन्य को ठीक करता है, तीन GRID सर्वरों में से एक पर, 20 x86-64 कोर और स्टोरेज, स्थानीय डिस्क की एक विशाल धीमी सरणी - यह Hadoop क्लस्टर के लिए सर्वर कॉन्फ़िगरेशन है। उसी प्रकार के एक अन्य सर्वर पर, ओरेकल डीबीएमएस जिसके साथ इंफॉर्मेटिका डोमेन और ईटीएल नियंत्रण तंत्र काम करते हैं। यह सब टीम (Zabbix + Grafana) में उपयोग किए जाने वाले मानक निगरानी उपकरणों, दोनों पक्षों - इनफॉर्मेटिका द्वारा स्वयं इसकी सेवाओं और इसमें जाने वाली लोडिंग प्रक्रियाओं द्वारा मॉनिटर किया जाता है। अब बाहरी कारकों को ध्यान में रखे बिना प्रदर्शन और स्थिरता दोनों, अब उन सेटिंग्स पर निर्भर करते हैं जो लोड को सीमित करते हैं।

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

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

एक ही स्थिति से एक और समस्या उत्पन्न होती है - कभी-कभी हमारे नियंत्रण तंत्र के कई लॉन्च होते हैं।


एक से अधिक अनुप्रयोग लॉन्च, तंत्र के टूटने के लिए अग्रणी

सिस्टम पर भारी लोड के समय पर एक शेड्यूल के अनुसार शुरू करने पर, ऐसी परिस्थितियां जो तंत्र के टूटने की ओर ले जाती हैं, कभी-कभी होती हैं। अब तक, समस्या को मैन्युअल रूप से ठीक किया गया है, एक स्थायी समाधान मांगा जा रहा है।

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

किसी भी गंभीर उत्पाद के साथ, Informatica में कुछ उत्सुक क्षण हैं।
एक बार, किसी प्रकार की दुर्घटना का विश्लेषण करते हुए, मैंने देखा कि एमआरएस लॉग में घटनाओं का समय अजीब रूप से चिह्नित था।


एमआरएस में अस्थायी द्वैतवाद "डिजाइन द्वारा"

यह पता चला कि एएम / पीएम को निर्दिष्ट किए बिना, दोपहर के पहले या बाद में 12 घंटे के प्रारूप में टाइमस्टैम्प लिखे जाते हैं। इस विषय पर एक आवेदन भी खोला गया था, और एक आधिकारिक प्रतिक्रिया प्राप्त हुई थी - यह योजनाबद्ध थी, एमआरएस लॉग में निशान इस प्रारूप में लिखे गए हैं। यही है, कभी-कभी कुछ ERROR की घटना के समय के बारे में कुछ साज़िश बनी रहती है ...

अच्छे के लिए प्रयास करते हैं

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

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

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

यह लेख रोस्टेलकॉम डेटा प्रबंधन टीम द्वारा तैयार किया गया था


वास्तविक सूचनात्मक लोगो