दैनंदिन अपघातांपासून स्थिरतेपर्यंत: प्रशासकाच्या नजरेतून माहिती 10

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

प्रिय वाचक आमचा डेटा वेअरहाऊस प्रकल्प आणि Informatica PowerCenter उत्पादनाशी आधीच परिचित असल्यास, तुम्ही लगेच पुढील विभागात जाऊ शकता.

अनेक वर्षांपूर्वी, सिंगल कॉर्पोरेट डेटा वेअरहाऊसची कल्पना परिपक्व झाली आणि रोस्टेलीकॉममध्ये लागू केली जाऊ लागली. वैयक्तिक समस्यांचे निराकरण करणारे अनेक भांडार आधीच तयार केले गेले होते, परंतु परिस्थितींची संख्या वाढली, समर्थन खर्च देखील वाढला आणि हे स्पष्ट झाले की भविष्य केंद्रीकरणात आहे. आर्किटेक्चरलदृष्ट्या, हे स्वतःच स्टोरेज आहे, ज्यामध्ये अनेक स्तर आहेत, ज्यामध्ये हडूप आणि ग्रीनप्लम, सहाय्यक डेटाबेस, ईटीएल यंत्रणा आणि बीआय लागू केले जातात.

त्याच वेळी, मोठ्या संख्येने भौगोलिकदृष्ट्या वितरित, विषम डेटा स्त्रोतांमुळे, एक विशेष डेटा अपलोड यंत्रणा तयार केली गेली, ज्याचे ऑपरेशन इन्फॉर्मेटिकाद्वारे नियंत्रित केले जाते. परिणामी, डेटा पॅकेजेस Hadoop इंटरफेस क्षेत्रामध्ये संपतात, त्यानंतर स्टोरेज स्तर, Hadoop आणि GreenPlum द्वारे डेटा लोड करण्याची प्रक्रिया सुरू होते आणि ते इन्फॉर्मेटिका मध्ये लागू केलेल्या तथाकथित ETL नियंत्रण यंत्रणेद्वारे व्यवस्थापित केले जातात. अशाप्रकारे, इन्फॉर्मेटिका सिस्टम ही मुख्य घटकांपैकी एक आहे जी गोदामाचे कार्य सुनिश्चित करते.

आमच्या स्टोरेजचे पुढीलपैकी एका पोस्टमध्ये अधिक तपशीलवार वर्णन केले जाईल.

इन्फॉर्मेटिका पॉवरसेंटर/बिग डेटा मॅनेजमेंट हे सध्या डेटा इंटिग्रेशन टूल्सच्या क्षेत्रातील आघाडीचे सॉफ्टवेअर मानले जाते. हे अमेरिकन कंपनी Informatica चे उत्पादन आहे, जी ETL (एक्सट्रॅक्ट ट्रान्सफॉर्म लोड), डेटा गुणवत्ता व्यवस्थापन, MDM (मास्टर डेटा मॅनेजमेंट), ILM (माहिती लाइफसायकल मॅनेजमेंट) आणि बरेच काही मधील सर्वात मजबूत खेळाडूंपैकी एक आहे.

आम्ही वापरत असलेले पॉवरसेंटर हे एकात्मिक टॉमकॅट अॅप्लिकेशन सर्व्हर आहे ज्यामध्ये इन्फॉर्मेटिका अॅप्लिकेशन्स स्वतः चालतात, त्याच्या सेवांची अंमलबजावणी करतात:

डोमेन, खरं तर, इतर सर्व गोष्टींसाठी हा आधार आहे; सेवा, वापरकर्ते आणि GRID घटक डोमेनमध्ये कार्य करतात.

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

MRS, मॉडेल रेपॉजिटरी सेवा, एक मेटाडेटा भांडार, डेटाबेस ज्यामध्ये मेटाडेटा भौतिकरित्या संग्रहित केला जातो आणि ज्यामध्ये विकास होत आहे त्या इन्फॉर्मेटिका डेव्हलपर क्लायंटमधील एक स्तर आहे. रेपॉजिटरीज डेटाचे वर्णन आणि इतर माहिती संग्रहित करतात, ज्यामध्ये इतर अनेक इन्फ्रोमॅटिका सेवांचा समावेश आहे, उदाहरणार्थ, चालू कार्ये (शेड्यूल) किंवा मॉनिटरिंग डेटासाठी शेड्यूल, तसेच ऍप्लिकेशन पॅरामीटर्स, विशेषत: समान ऍप्लिकेशनच्या कामासाठी वापरण्याची परवानगी देते. विविध डेटा स्रोत आणि प्राप्तकर्ते.

DIS, डेटा एकत्रीकरण सेवा, ही एक सेवा आहे ज्यामध्ये मुख्य कार्यात्मक प्रक्रिया घडतात, त्यामध्ये अनुप्रयोग चालतात आणि वर्कफ्लोचे वास्तविक लाँच (मॅपिंग आणि त्यांच्या परस्परसंवादाच्या क्रमाचे वर्णन) आणि मॅपिंग्स (परिवर्तन, ब्लॉक्स ज्यामध्ये परिवर्तन स्वतः होतात, डेटा प्रोसेसिंग) ) घडणे.

GRID कॉन्फिगरेशन - मूलत:, अनेक सर्व्हर वापरून कॉम्प्लेक्स तयार करण्याचा पर्याय, जेव्हा DIS द्वारे लाँच केलेला लोड नोड्समध्ये वितरित केला जातो (म्हणजे, डोमेनचा भाग असलेले सर्व्हर). या पर्यायाच्या बाबतीत, DIS मध्ये लोडचे वितरण अतिरिक्त GRID ऍब्स्ट्रॅक्शन लेयरद्वारे केले जाते जे अनेक नोड्स एकत्र करते, ज्यावर DIS एका विशिष्ट नोडवर कार्य करण्याऐवजी चालते, अतिरिक्त बॅकअप MRS उदाहरणे देखील तयार केली जाऊ शकतात. तुम्ही उच्च उपलब्धता देखील लागू करू शकता, जेथे मुख्य कॉल अयशस्वी झाल्यास बॅकअप नोड्सद्वारे बाह्य कॉल केले जाऊ शकतात. आम्ही सध्या बांधकामाचा हा पर्याय सोडला आहे.

इन्फॉर्मेटिका पॉवर सेंटर, योजनाबद्ध

डेटा पुरवठा साखळीचा एक भाग म्हणून कामाच्या सुरुवातीच्या टप्प्यात, समस्या नियमितपणे उद्भवल्या, त्यापैकी काही त्या वेळी इन्फॉर्मेटिकाच्या अस्थिर ऑपरेशनमुळे. मी या गाथेतील काही संस्मरणीय क्षण शेअर करणार आहे - मास्टरिंग इन्फॉर्मेटिका 10.

माजी इन्फॉर्मेटिका लोगो

आमच्या जबाबदारीच्या क्षेत्रामध्ये इतर इन्फॉर्मेटिका वातावरणाचाही समावेश आहे, वेगळ्या लोडमुळे त्यांची स्वतःची वैशिष्ट्ये आहेत, परंतु आत्ता मला माहीत आहे की इन्फॉर्मेटिका डेटा वेअरहाऊसचा एक ईटीएल घटक म्हणून कसा विकसित झाला.

हे कसे घडले

2016 मध्ये, जेव्हा आम्ही Informatica च्या कार्यासाठी जबाबदार झालो, तेव्हा ते आधीच आवृत्ती 10.0 वर पोहोचले होते आणि आशावादी सहकार्यांसाठी जे एक गंभीर समाधानामध्ये किरकोळ आवृत्ती .0 सह उत्पादन वापरण्याचा निर्णय घेत होते, सर्वकाही स्पष्ट दिसत होते - आम्हाला वापरण्याची आवश्यकता आहे. नवीन आवृत्ती! हार्डवेअर संसाधनांच्या दृष्टिकोनातून, त्या वेळी सर्व काही ठीक होते.

2016 च्या वसंत ऋतूपासून, एक कंत्राटदार इन्फॉर्मेटिकाच्या कामासाठी जबाबदार आहे आणि सिस्टमच्या काही वापरकर्त्यांच्या मते, "त्याने आठवड्यातून दोन वेळा काम केले." येथे हे स्पष्ट करणे आवश्यक आहे की रेपॉजिटरी पीओसी टप्प्यावर वास्तविक होती, कार्यसंघावर कोणतेही प्रशासक नव्हते आणि विविध कारणांमुळे सिस्टम सतत क्रॅश होते, त्यानंतर कंत्राटदाराच्या अभियंत्याने ते पुन्हा उचलले.

गडी बाद होण्याचा क्रम मध्ये, तीन प्रशासक संघात सामील झाले, त्यांनी त्यांच्या जबाबदारीचे क्षेत्र आपापसांत विभागले आणि सामान्य कामाने इन्फॉर्मेटिकासह प्रकल्पातील सिस्टमच्या ऑपरेशनचे आयोजन करण्यास सुरुवात केली. स्वतंत्रपणे, असे म्हटले पाहिजे की हे उत्पादन व्यापक नाही आणि त्यात एक मोठा समुदाय आहे ज्यामध्ये आपण कोणत्याही प्रश्नांची उत्तरे शोधू शकता आणि कोणत्याही समस्येचे निराकरण करू शकता. म्हणून, रशियन भागीदार Informatica कडून संपूर्ण तांत्रिक समर्थन खूप महत्वाचे होते, ज्याच्या मदतीने आमच्या सर्व चुका आणि तत्कालीन तरुण Informatica 10 च्या चुका दुरुस्त केल्या गेल्या.

वेब अॅडमिनिस्ट्रेशन कन्सोल (इन्फॉर्मेटिका अॅडमिनिस्ट्रेटर) ची कार्यक्षमता सुनिश्चित करण्यासाठी, आमच्या कार्यसंघाच्या विकासकांसाठी आणि कंत्राटदारासाठी आम्हाला सर्वप्रथम इन्फॉर्मेटिकाचे काम स्थिर करणे आवश्यक होते.

अशा प्रकारे आम्ही अनेकदा इन्फॉर्मेटिका विकासकांना भेटलो

कारणे शोधण्याची प्रक्रिया बाजूला ठेवून, नेटवर्क लँडस्केपच्या दृष्टिकोनातून, तुलनेने रिमोट सर्व्हरवर असलेल्या रिपॉजिटरी डेटाबेससह इन्फॉर्मेटिका सॉफ्टवेअरचा परस्परसंवाद नमुना क्रॅश होण्याचे मुख्य कारण होते. यामुळे विलंब झाला आणि इन्फॉर्मेटिका डोमेनच्या स्थितीचे परीक्षण करणार्‍या यंत्रणेमध्ये व्यत्यय आला. डेटाबेसच्या काही ट्यूनिंगनंतर, इन्फॉर्मेटिकाचे पॅरामीटर्स बदलून, ज्यामुळे डेटाबेस विलंब अधिक सहनशील झाला आणि अखेरीस इन्फॉर्मेटिका आवृत्ती 10.1 वर अद्यतनित केली गेली आणि डेटाबेस मागील सर्व्हरवरून इन्फॉर्मेटिका जवळ असलेल्या सर्व्हरवर हस्तांतरित केल्याने, समस्या गमावली. प्रासंगिकता, आणि तेव्हापासून अशा प्रकारचे क्रॅश झाले आहेत जे आम्ही पाहत नाही.

इन्फॉर्मेटिका मॉनिटर कार्यान्वित करण्याचा एक प्रयत्न

प्रशासन कन्सोलसह परिस्थिती देखील गंभीर होती. सक्रिय विकास थेट तुलनेने उत्पादक वातावरणात सुरू असल्याने, सहकाऱ्यांना "जाता जाता" मॅपिंग आणि वर्कफ्लोच्या कार्याचे विश्लेषण करणे सतत आवश्यक होते. नवीन इन्फॉर्मेटिकामध्ये, डेटा इंटिग्रेशन सेवेकडे अशा प्रकारच्या देखरेखीसाठी वेगळे साधन नाही, परंतु प्रशासकीय वेब कन्सोल (इन्फॉर्मेटिका अॅडमिनिस्ट्रेटर मॉनिटर) मध्ये एक मॉनिटरिंग विभाग दिसला आहे, ज्यामध्ये तुम्ही अॅप्लिकेशन्स, वर्कफ्लो आणि मॅपिंगच्या ऑपरेशनचे निरीक्षण करू शकता, लाँच, लॉग. वेळोवेळी, कन्सोल पूर्णपणे अनुपलब्ध झाले, किंवा DIS मधील वर्तमान प्रक्रियांबद्दल माहिती अद्यतनित करणे थांबवले किंवा पृष्ठे लोड करताना त्रुटी आल्या.

कार्यप्रदर्शन स्थिर करण्यासाठी जावा पॅरामीटर्सची निवड

समस्या अनेक प्रकारे दुरुस्त केली गेली, पॅरामीटर्स बदलण्यासाठी प्रयोग केले गेले, लॉग आणि jstack गोळा केले गेले, समर्थनासाठी पाठवले गेले, त्याच वेळी सक्रिय गुगलिंग आणि फक्त निरीक्षण होते.

सर्व प्रथम, निरीक्षणासाठी एक स्वतंत्र एमआरएस तयार केला गेला; जसे की नंतर दिसून आले की, हे आपल्या वातावरणातील संसाधनांच्या मुख्य ग्राहकांपैकी एक आहे, कारण मॅपिंग खूप तीव्रतेने लॉन्च केले जातात. जावा हीप आणि इतर अनेक बाबींचे पॅरामीटर्स बदलले आहेत.
परिणामी, पुढील अपडेट Informatica 10.1.1 द्वारे, कन्सोल आणि मॉनिटरचे ऑपरेशन स्थिर झाले, विकासक अधिक कार्यक्षमतेने कार्य करू लागले आणि नियमित प्रक्रिया अधिकाधिक नियमित होत गेल्या.

विकास आणि प्रशासन यांच्यातील संवादाचा अनुभव रंजक असू शकतो. क्लिष्ट प्रणाली वापरताना गोष्टी कशा चालतात, काय करता येते आणि काय करता येत नाही याविषयी सामान्य समज असण्याचा मुद्दा नेहमीच महत्त्वाचा असतो. म्हणून, आम्ही सुरक्षितपणे शिफारस करू शकतो की आपण प्रथम प्रशासकीय कार्यसंघाला सॉफ्टवेअरचे व्यवस्थापन कसे करावे आणि विकास कार्यसंघाला कोड कसे लिहायचे आणि सिस्टममध्ये प्रक्रिया कशी काढायची याचे प्रशिक्षण द्या आणि त्यानंतरच निकालावर काम करण्यासाठी प्रथम आणि द्वितीय पाठवा. जेव्हा वेळ हा अमर्याद स्त्रोत नसतो तेव्हा हे खरोखर महत्वाचे आहे. पर्यायांच्या यादृच्छिक शोधाने देखील अनेक समस्या सोडवल्या जाऊ शकतात, परंतु काहीवेळा काहींना प्राथमिक ज्ञान आवश्यक असते - आमची केस या स्वयंसिद्धतेच्या महत्त्वाची पुष्टी करते.

उदाहरणार्थ, जेव्हा आम्ही MRS मध्‍ये आवृत्ती सक्षम करण्याचा प्रयत्न केला (अखेर असे दिसून आले की, SVN ची वेगळी आवृत्ती आवश्यक होती), काही काळानंतर सिस्टम रीस्टार्ट होण्याची वेळ अनेक दहा मिनिटांपर्यंत वाढली आहे हे पाहून आम्ही घाबरलो. सुरुवातीस उशीर होण्याचे कारण शोधून आणि आवृत्ती अक्षम केल्याने, आम्ही पुन्हा चांगले केले.

Informatica शी संबंधित उल्लेखनीय अडथळ्यांमध्ये वाढत्या जावा थ्रेड्ससह महाकाव्य युद्धाचा समावेश होतो. काही क्षणी, प्रतिकृतीची वेळ आली आहे, म्हणजेच स्थापित प्रक्रिया मोठ्या संख्येने स्त्रोत प्रणालींमध्ये विस्तारित करणे. असे दिसून आले की 10.1.1 मधील सर्व प्रक्रिया चांगल्या प्रकारे कार्य करत नाहीत आणि काही काळानंतर डीआयएस अकार्यक्षम बनले. हजारो थ्रेड्स आढळले, त्यांची संख्या विशेषत: ऍप्लिकेशन डिप्लॉयमेंट प्रक्रियेदरम्यान लक्षणीयपणे वाढत आहे. काहीवेळा मला कार्यक्षमता पुनर्संचयित करण्यासाठी दिवसातून अनेक वेळा रीस्टार्ट करावे लागले.

येथे आम्हाला समर्थनाचे आभार मानणे आवश्यक आहे; समस्या स्थानिकीकृत केल्या गेल्या आणि EBF (इमर्जन्सी बग फिक्स) वापरून तुलनेने लवकर निराकरण केले - त्यानंतर, प्रत्येकाला असे वाटले की हे साधन खरोखर कार्य करते.

हे अजूनही कार्य करते!

आम्ही लक्ष्य मोडमध्ये काम करण्यास सुरुवात केली तेव्हा, Informatica असे दिसत होते. Informatica 10.1.1HF1 ची आवृत्ती (HF1 HotFix1 आहे, EBF च्या कॉम्प्लेक्समधील विक्रेता असेंब्ली) अतिरिक्तपणे स्थापित EBF सह, जी ग्रिडचा भाग असलेल्या तीनपैकी एका सर्व्हरवर, 20 x86_64 कोर असलेल्या स्केलिंग आणि इतर काही समस्या दुरुस्त करते. आणि स्टोरेज, स्थानिक डिस्क्सच्या प्रचंड स्लो अॅरेवर - हे हॅडूप क्लस्टरसाठी सर्व्हर कॉन्फिगरेशन आहे. दुसर्‍या समान सर्व्हरवर - ओरॅकल डीबीएमएस ज्यासह इन्फॉर्मेटिका डोमेन आणि ईटीएल नियंत्रण यंत्रणा कार्य करतात. हे सर्व दोन्ही बाजूंच्या टीममध्ये वापरल्या जाणार्‍या मानक मॉनिटरिंग टूल्स (झॅबिक्स + ग्राफाना) द्वारे परीक्षण केले जाते - इन्फॉर्मेटिका स्वतः त्याच्या सेवांसह, आणि लोडिंग प्रक्रिया त्यामध्ये जात आहेत. आता बाह्य घटक विचारात न घेता कार्यक्षमता आणि स्थिरता दोन्ही, आता लोड मर्यादित करणार्‍या सेटिंग्जवर अवलंबून आहेत.

स्वतंत्रपणे, आम्ही GRID बद्दल म्हणू शकतो. लोड बॅलेंसिंगच्या शक्यतेसह वातावरण तीन नोड्सवर तयार केले गेले. तथापि, चाचणी दरम्यान, असे आढळून आले की आमच्या अनुप्रयोगांच्या चालू उदाहरणांमधील परस्परसंवादाच्या समस्यांमुळे, हे कॉन्फिगरेशन अपेक्षेप्रमाणे कार्य करत नाही आणि त्यांनी डोमेनमधून तीन नोड्सपैकी दोन काढून टाकून ही बांधकाम योजना तात्पुरती सोडून देण्याचा निर्णय घेतला. त्याच वेळी, योजना स्वतःच तशीच राहिली आहे, आणि आता ती तंतोतंत एक GRID सेवा आहे, परंतु एका नोडमध्ये क्षीण झाली आहे.

सध्या, मॉनिटर सर्किट नियमितपणे साफ करताना कार्यक्षमता कमी होण्याशी संबंधित अडचण राहते - CNN मध्ये एकाचवेळी प्रक्रिया आणि स्वच्छता चालू असताना, ईटीएल नियंत्रण यंत्रणेच्या ऑपरेशनमध्ये खराबी उद्भवू शकते. हे सध्या "क्रच म्हणून" सोडवले जात आहे - मॉनिटर सर्किट मॅन्युअली साफ करून, मागील सर्व डेटा गमावून. हे सामान्य नित्य ऑपरेशन दरम्यान, उत्पादकतेसाठी खूप गंभीर नाही, परंतु सध्या सामान्य उपाय शोधणे सुरू आहे.

याच परिस्थितीतून आणखी एक समस्या उद्भवते - कधीकधी आमच्या नियंत्रण यंत्रणेचे अनेक प्रक्षेपण होतात.

एकाधिक ऍप्लिकेशन लाँच केल्याने यंत्रणा अपयशी ठरते

शेड्यूलनुसार चालत असताना, सिस्टमवर जास्त भार असताना, कधीकधी अशी परिस्थिती उद्भवते ज्यामुळे यंत्रणा बिघडते. समस्या अजूनही मॅन्युअली सोडवली जात आहे, आणि कायमस्वरूपी उपाय शोधला जात आहे.

सर्वसाधारणपणे, आम्ही सारांशित करू शकतो की जेव्हा जास्त भार असतो, तेव्हा त्याला पुरेशी संसाधने प्रदान करणे खूप महत्वाचे असते, हे स्वतः इन्फॉर्मेटिकासाठी हार्डवेअर संसाधनांवर देखील लागू होते आणि त्याच्या डेटाबेस रिपॉझिटरीसाठी तसेच इष्टतम सेटिंग्ज प्रदान करण्यासाठी देखील लागू होते. त्यांच्यासाठी. या व्यतिरिक्त, कोणती डेटाबेस प्लेसमेंट योजना अधिक चांगली आहे - वेगळ्या होस्टवर किंवा इन्फॉर्मेटिका सॉफ्टवेअर चालवणाऱ्या त्याच ठिकाणी हा प्रश्न खुला आहे. एकीकडे, एका सर्व्हरवर ते स्वस्त असेल आणि एकत्रित केल्यावर, नेटवर्क परस्परसंवादासह संभाव्य समस्या व्यावहारिकपणे दूर केली जाते; दुसरीकडे, डेटाबेसवरील होस्टवरील लोड इन्फॉर्मेटिका वरील लोडद्वारे पूरक आहे.

कोणत्याही गंभीर उत्पादनाप्रमाणे, इन्फॉर्मेटिकामध्ये देखील मजेदार क्षण आहेत.
एकदा, काही प्रकारच्या अपघाताची क्रमवारी लावताना, माझ्या लक्षात आले की MRS लॉग विचित्रपणे घटनांची वेळ दर्शवतात.

एमआरएस लॉगमध्ये "डिझाइननुसार" ऐहिक द्वैतवाद

असे दिसून आले की टाइम स्टॅम्प 12 तासांच्या स्वरूपात लिहिलेले आहेत, AM/PM निर्दिष्ट न करता, म्हणजे दुपारच्या आधी किंवा नंतर. या संदर्भात एक अर्ज देखील उघडला गेला होता, आणि अधिकृत प्रतिसाद प्राप्त झाला होता - हे असेच होते, मार्क्स एमआरएस लॉगमध्ये नेमक्या याच स्वरूपात लिहिलेले आहेत. म्हणजेच, काही वेळा काही ERROR घडण्याच्या वेळेबद्दल काही कारस्थान राहते...

चांगल्यासाठी प्रयत्न करा

आज, इन्फॉर्मेटिका हे बर्‍यापैकी स्थिर साधन आहे, प्रशासक आणि वापरकर्त्यांसाठी सोयीचे आहे, त्याच्या वर्तमान क्षमता आणि संभाव्यतेच्या दृष्टीने अत्यंत शक्तिशाली आहे. हे आमच्या कार्यात्मक गरजा अनेक वेळा ओलांडते आणि डी फॅक्टो आता अशा प्रकारे प्रकल्पात वापरले जात आहे जे सर्वात सामान्य आणि वैशिष्ट्यपूर्ण नाही. अडचणी अंशतः यंत्रणेच्या कार्य करण्याच्या पद्धतीशी संबंधित आहेत - विशिष्ट गोष्ट अशी आहे की अल्प कालावधीत मोठ्या संख्येने थ्रेड्स लॉन्च केले जातात जे पॅरामीटर्स गहनपणे अद्यतनित करतात आणि रिपॉझिटरी डेटाबेससह कार्य करतात, तर सर्व्हर हार्डवेअर संसाधने जवळजवळ पूर्णपणे वापरली जातात. CPU द्वारे.

आम्‍ही आता Informatica 10.2.1 किंवा 10.2.2 वर जाण्‍याच्‍या जवळ आलो आहोत, जिने आम्‍हाला सध्‍या असलेल्‍या काही कार्यप्रदर्शन आणि कार्यक्षमतेच्‍या समस्‍या दूर करण्‍यासाठी काही अंतर्गत यंत्रणा आणि समर्थन वचने पुन्‍हा तयार केली आहेत. आणि हार्डवेअरच्या दृष्टिकोनातून, स्टोरेजच्या वाढीमुळे आणि विकासामुळे नजीकच्या भविष्यासाठी राखीव ठेव लक्षात घेऊन, आम्ही आमच्यासाठी इष्टतम कॉन्फिगरेशनसह सर्व्हरची अपेक्षा करतो.

अर्थात, HA GRID भागामध्ये चाचणी, सुसंगतता तपासणी आणि शक्यतो आर्किटेक्चरल बदल असतील. Informatica अंतर्गत विकास चालू राहील, कारण अल्पावधीत आम्ही सिस्टम बदलण्यासाठी काहीही देऊ शकत नाही.
आणि जे भविष्यात या प्रणालीसाठी जबाबदार असतील ते निश्चितपणे ग्राहकांद्वारे समोर ठेवलेल्या आवश्यक विश्वासार्हता आणि कार्यप्रदर्शन निर्देशकांवर आणण्यास सक्षम असतील.

लेख Rostelecom डेटा व्यवस्थापन टीमने तयार केला होता

वर्तमान माहितीचा लोगो

स्त्रोत: www.habr.com