1C डेवलपर की कहानियाँ: व्यवस्थापक की

सभी 1सी डेवलपर्स किसी न किसी रूप में आईटी सेवाओं और सीधे सिस्टम प्रशासकों के साथ निकटता से बातचीत करते हैं। लेकिन यह बातचीत हमेशा सुचारू रूप से नहीं चलती. मैं आपको इसके बारे में कुछ मज़ेदार कहानियाँ बताना चाहूँगा।

उच्च गति संचार चैनल

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

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

यह सब सफलतापूर्वक कॉन्फ़िगर किया गया, संचालन में लाया गया और आम तौर पर विफलताओं के बिना काम किया गया।

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

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

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

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

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

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

इसके बाद, आईटी विभाग से किए गए हमारे सभी अनुरोधों का बहुत शीघ्रता से समाधान कर दिया गया और कोई और असहमति उत्पन्न नहीं हुई।

अपने सिस्टम व्यवस्थापक से संपर्क करें

एक बार, बहुत लंबे समय तक, मैं एक क्लाइंट के लिए IIS के माध्यम से वेब एक्सेस के लिए 1C प्रकाशित नहीं कर सका। यह एक सामान्य कार्य जैसा लग रहा था, लेकिन सब कुछ चालू रखने का कोई रास्ता नहीं था। स्थानीय सिस्टम प्रशासक शामिल हुए और विभिन्न सेटिंग्स और कॉन्फ़िगरेशन फ़ाइलों को आज़माया। वेब पर 1C आम तौर पर किसी भी तरह से काम नहीं करना चाहता था। कुछ गलत था, या तो डोमेन सुरक्षा नीतियों के साथ, या स्थानीय परिष्कृत फ़ायरवॉल के साथ, या भगवान जानता है कि और क्या। Nवें पुनरावृत्ति पर, व्यवस्थापक मुझे शब्दों के साथ एक लिंक भेजता है:

- इन निर्देशों का उपयोग करके पुनः प्रयास करें। वहां हर चीज़ का काफी विस्तार से वर्णन किया गया है। यदि यह काम नहीं करता है, तो इस साइट के लेखक को लिखें, शायद वह मदद कर सके।
"नहीं," मैं कहता हूं, "इससे कोई मदद नहीं मिलेगी।"
- क्यों?
— मैं इस साइट का लेखक हूं... (

परिणामस्वरूप, हमने इसे बिना किसी समस्या के अपाचे पर लॉन्च किया। IIS कभी पराजित नहीं हुआ.

एक स्तर गहरा

हमारे पास एक ग्राहक था - एक छोटा विनिर्माण उद्यम। उनके पास एक सर्वर था, एक प्रकार का "क्लासिक" 3 इन 1: टर्मिनल सर्वर + एप्लिकेशन सर्वर + डेटाबेस सर्वर। उन्होंने यूपीपी पर आधारित कुछ उद्योग-विशिष्ट कॉन्फ़िगरेशन में काम किया, वहां लगभग 15-20 उपयोगकर्ता थे, और सिस्टम का प्रदर्शन, सिद्धांत रूप में, सभी के अनुकूल था।

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

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

कुछ समय बाद, व्यवस्थापक मुझे नए सर्वर का आईपी पता और लॉगिन क्रेडेंशियल भेजता है। उनका कहना है कि MS SQL और 1C सर्वर घटक वहां तैनात हैं, और डेटाबेस को स्थानांतरित करने की आवश्यकता है, लेकिन अभी के लिए केवल DBMS सर्वर पर, क्योंकि 1C कुंजी के साथ कुछ समस्याएं उत्पन्न हुई हैं।

मैं अंदर आया, वास्तव में, सभी सेवाएँ चल रही थीं, सर्वर बहुत शक्तिशाली नहीं था, लेकिन ठीक है, मुझे लगता है कि यह कुछ न होने से बेहतर है। वर्तमान सर्वर को किसी तरह से राहत देने के लिए मैं अभी डेटाबेस स्थानांतरित कर दूंगा। मैंने तय समय पर सभी स्थानान्तरण पूरे कर लिए, लेकिन स्थिति नहीं बदली - अब भी वही प्रदर्शन समस्याएँ हैं। बेशक, यह अजीब है, आइए डेटाबेस को 1C क्लस्टर में पंजीकृत करें और हम देखेंगे।

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

हम्म... वर्चुअल सर्वर? ऐसा लगता है कि कभी भी कोई वर्चुअलाइजेशन नहीं हुआ है और न ही कभी हुआ है... मुझे विंडोज सर्वर 1 में हाइपर-वी पर वर्चुअल मशीन में 2008सी सर्वर कुंजी को अग्रेषित करने की असंभवता के साथ एक काफी प्रसिद्ध समस्या याद है। और यहां मेरे अंदर कुछ संदेह पैदा होने लगते हैं...

मैं सर्वर मैनेजर खोलता हूं - भूमिकाएं - एक नई भूमिका सामने आई है - हाइपर-वी। मैं हाइपर-V मैनेजर के पास जाता हूं, एक वर्चुअल मशीन देखता हूं, कनेक्ट करता हूं... और वास्तव में... हमारा नया डेटाबेस सर्वर...

तो क्या हुआ? अधिकारियों के निर्देशों और मेरी सिफारिशों का पालन किया गया है, भूमिकाएँ अलग कर दी गई हैं। कार्य बंद हो सकता है.

कुछ समय बाद, अब संकट आ गया, नई शाखा को बंद करना पड़ा, लोड कम हो गया, और सिस्टम का प्रदर्शन कमोबेश सहनीय हो गया।

खैर, निश्चित रूप से, वे सर्वर कुंजी को वर्चुअल मशीन पर अग्रेषित नहीं कर सके। परिणामस्वरूप, सब कुछ वैसे ही छोड़ दिया गया: एक भौतिक मशीन पर टर्मिनल सर्वर + 1सी क्लस्टर, वर्चुअल मशीन में डेटाबेस सर्वर।

और यह अच्छा होता यदि यह किसी प्रकार का शरश्किन का कार्यालय होता। तो नहीं. एक सुप्रसिद्ध कंपनी जिसके उत्पादों को आप शायद जानते होंगे और सभी लेंटा और औचांस के संबंधित विभागों में देखे होंगे।

हार्ड ड्राइव अवकाश कार्यक्रम

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

सबसे पहले, उत्पादन और परीक्षण डेटाबेस को तैनात करना आवश्यक है। डेवलपर ने कनेक्शन डेटा प्राप्त किया, सर्वर में लॉग इन किया, एमएस एसक्यूएल स्थापित देखा, 1 सी सर्वर, 2 लॉजिकल ड्राइव देखता है: 250 गीगाबाइट की क्षमता के साथ ड्राइव "सी" और 1 टेराबाइट की क्षमता के साथ "डी" ड्राइव। खैर, "सी" प्रणाली है, "डी" डेटा के लिए है, डेवलपर तार्किक रूप से निर्णय लेता है और सभी डेटाबेस को वहां तैनात करता है। मैं बैकअप सहित रखरखाव योजनाएं भी स्थापित करता हूं, बस किसी मामले में (भले ही हम इसके लिए जिम्मेदार नहीं हैं)। सच है, बैकअप यहाँ "डी" में जोड़े गए थे। भविष्य में, इसे कुछ अलग नेटवर्क संसाधनों में पुन: कॉन्फ़िगर करने की योजना बनाई गई थी।

परियोजना शुरू हुई, सलाहकारों ने नई प्रणाली में काम करने के तरीके पर प्रशिक्षण प्रदान किया, बचे हुए को स्थानांतरित कर दिया गया, कुछ छोटे छोटे सुधार किए गए, और उपयोगकर्ताओं ने नए सूचना आधार में काम करना शुरू कर दिया।

एक सोमवार की सुबह तक सब कुछ ठीक चल रहा था जब पता चला कि डेटाबेस डिस्क गायब है। सर्वर पर कोई "डी" नहीं है और बस इतना ही।

आगे की जांच से यह पता चला: यह "सर्वर" वास्तव में एक स्थानीय सिस्टम प्रशासक का कार्य कंप्यूटर था। सच है, इसमें अभी भी एक सर्वर ओएस था। इस व्यवस्थापक की व्यक्तिगत USB ड्राइव को सर्वर में प्लग किया गया था। और इसलिए प्रशासक छुट्टी पर चला गया, यात्रा के लिए फिल्मों को पंप करने के लक्ष्य के साथ, अपने पेंच को अपने साथ ले गया।

भगवान का शुक्र है, वह डेटाबेस फ़ाइलों को हटाने में कामयाब नहीं हुआ और उत्पादक डेटाबेस को पुनर्स्थापित करने में कामयाब रहा।

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

लेकिन यह बिल्कुल अलग कहानी है ...

स्रोत: www.habr.com