हमारे पास हमारी कंपनी में एक बिज़टॉक सर्वर (वर्चुअल वन (1!) ...) है, और एक एसक्यूएल सर्वर जहां डेटा रखा जा रहा है। अब हमारे पास बहुत अधिक डेटा यातायात है। मैं हजारों के बारे में बात कर रहा हूँ। तो मैं वास्तव में यह भी सुनिश्चित नहीं कर रहा हूं कि एक सर्वर बहुत सुरक्षित है, लेकिन हमारी कंपनी को मनाने के लिए इतना आसान नहीं है।बिज़टॉक सर्वर समस्या
हाल ही में हमें बहुत सी समस्याएं हैं।
अनुमति दें मुझे विस्तार से बैठा है, इसलिए मैं कुछ भी याद आ रही नहीं कर रहा हूँ:
हमारे सर्वर 5 अनुप्रयोग हैं:
- एक 3 orchestrations साथ, 12 बंदरगाहों भेजने के लिए, 16 स्थानों प्राप्त करते हैं।
- 4 ऑर्केस्ट्रेशंस वाला, 32 पोर्ट बंद करें, 20 स्थान प्राप्त करें।
- 4 ऑर्केस्ट्रेशंस के साथ, 24 बंदरगाह भेजते हैं, 20 स्थान प्राप्त करते हैं।
- 47 (हाँ 47) ऑर्केस्ट्रेशंस के साथ एक, 37 बंदरगाह भेजते हैं, 6 स्थान प्राप्त करते हैं।
- कुछ संसाधनों के साथ आम अनुप्रयोग के साथ एक।
हमारी समस्याएं तब हुई हैं जब हमने 47 ऑर्केस्ट्रेशंस के साथ अनुप्रयोगों को तैनात किया था। इनमें से बहुत से ऑर्केस्ट्रेशंस आकार निर्दिष्ट करते हैं जो मैपिंग करने के लिए सी # कोड का उपयोग करते हैं। ऐसा इसलिए है क्योंकि हम एचएल 7 एक्सटेंशन का उपयोग करते हैं और यह एक तरह का विशेष है, इसलिए सी # कोड & xpath का उपयोग करके मैपिंग करना बहुत आसान था क्योंकि इनमें से बहुत से स्कीमा के समान दिखते हैं। सी # एक्सपीएथ के माध्यम से प्राप्त एक्सएमएलएनोड्स में पढ़ता है, और एक्सएमएलएनोड लौटाता है जिसे फिर संदेशों को बिज़टॉक करने के लिए असाइन किया जाता है। मुझे यकीन नहीं है कि यह कारण हो सकता है, लेकिन मैंने सोचा कि मैं इसका उल्लेख करूंगा।
प्रेषण और प्राप्त बंदरगाहों में बहुत से प्रकार हैं: फ़ाइल, एमक्यूएसरीज, एसक्यूएल, एमएलएलपी, एफ़टीपी। भार को संतुलित करने के लिए इनमें से प्रत्येक प्रकार के पास एक अलग मेजबान उदाहरण होते हैं। हमारे ऑर्केस्ट्रेशंस Biztalk अनुप्रयोग होस्ट का उपयोग करते हैं।
इस सर्वर पर भी कुछ स्क्रिप्ट चल रही हैं, अधिकतर अपलोड स्क्रिप्ट्स & एक जिपर स्क्रिप्ट भी है, जो एक दैनिक ज़िप में हर आधा घंटे फ़ाइलों को ज़िप करता है और एक महीने के बाद ज़िप फ़ाइलों को हटा देता है। हम इस बैकअप फ़ाइलों पर हमारी ज़िप्स्क्रिप्ट का उपयोग करते हैं (हम बहुत बैकअप लेते हैं, बैकअप हमारे सर्वर पर भी होते हैं), हमने ऐसा इसलिए किया क्योंकि सर्वर को ऐसी जगह पर फाइल भेजने में समस्याएं थीं जहां बहुत सारी फाइलें थीं, इसलिए फ़ाइलों को ज़िप में कम कर दिया गया था यह बेहतर हो गया।
- हमारी सबसे महत्वपूर्ण समस्या निम्नलिखित है:
अब समस्याओं हम हाल ही में कर रहे हैं मुख्य रूप से दो प्रमुख समस्याएं हैं। हमने परीक्षण के लिए कतार पर कई संदेशों के साथ एक स्थान प्राप्त किया। इसे शुरू करने के बाद 47 ऑर्केस्ट्रेशंस का उपयोग करने वाले स्थान को प्राप्त करने के बाद, चलने वाली सेवा के उदाहरण आकाश चट्टान से शुरू होते हैं। ठीक है, यह बहुत सामान्य है। आइए 10000 के बारे में कहें, और फिर हम यह देखने के लिए प्राप्त स्थान को रोकते हैं कि बिज़टॉक इन 10000 उदाहरणों को कैसे प्रबंधित करता है। आम तौर पर वे बहुत तेज हो जाते हैं, और कभी-कभी ऐसा होता है, लेकिन थोड़ी देर के बाद यह "थ्रॉटल" शुरू होता है, जिसका अर्थ है कि वे केवल संसाधित होने से रोकते हैं और सेवा के उदाहरण एक ही संख्या में रहते हैं, उदाहरण के लिए 30 सेकंड में यह 10000 से नीचे चला जाता है 4000 तक और फिर यह 4000 पर रहता है और यह बहुत धीमा हो जाता है, जैसे 30 मिनट में 5 मिनट या कुछ। तो इसका मतलब है कि अन्य अनुप्रयोगों के सभी अन्य सेवा उदाहरण भी यहां फंस गए हैं, और इन्हें भी संसाधित नहीं किया जाता है।
हमने देखा कि हमारे मेजबान उदाहरणों को पुनरारंभ करने के बाद इंस्टेंस नंबर फिर से नीचे चला गया। इसलिए हमने समस्या का पता लगाने के लिए चुनिंदा विभिन्न होस्ट इंस्टेंस को पुनरारंभ करने का प्रयास किया। हमने देखा है कि मेजबान आवृत्ति भेजने/प्राप्त करने वाली फ़ाइल को फिर से शुरू करने से चाल चलती है। तो हमने सोचा कि फ़ाइल भेजना समस्या होगी। इस बात पर विचार करते हुए कि हम बहुत सारे बैकअप बनाते हैं। इसलिए हमने फ़ाइल प्रकार बैकअप को mqseries बैकअप के साथ बदल दिया। एक ही समस्या आई, और मजाकिया बात, फाइल भेजने/प्राप्त करने वाले फ़ाइल को पुनरारंभ करने से समस्या अभी भी ठीक हो जाती है।
ईवेंट व्यूअर में कोई भी त्रुटि नहीं मिल सकती है।
- हमारे पास एक दूसरी समस्या है। कभी-कभी सुबह 6 बजे, होस्ट या घटनाओं का एक हिस्सा बंद कर दिया जा रहा है।
ईवेंट व्यूअर में हम निम्न त्रुटियों देखा (ये एक से अधिक कर रहे हैं):
The receive location "MdnBericht SQL" with URL "SQL://ZNACDBPEG/mdnd0001/" is shutting down. Details:"The error threshold has been exceeded. The receive location is shutting down.".
The Messaging Engine failed to add a receive location "M2m Othello Export Start Bestand" with URL "\m2mservices\Othello_import$\DataFilter Start*.xml" to the adapter "FILE". Reason: "The FILE adapter cannot access the folder \m2mservices\Othello_import$\DataFilter Start. Verify this folder exists. Error: Logon failure: unknown user name or bad password. ".
The FILE adapter cannot access the folder \m2mservices\Othello_import$\DataFilter Start. Verify this folder exists. Error: Logon failure: unknown user name or bad password.
An attempt to connect to "BizTalkMsgBoxDb" SQL Server database on server "ZNACDBBTS" failed. Error: "Login failed for user ''. The user is not associated with a trusted SQL Server connection."
यह प्रतीत woould इस समय एक लॉगिन विफलता है कि और है कि यह की वजह से अन्य सेवाओं को भी कर रहे हैं समस्याओं का सामना करना, और अंत में वे बंद हो गए हैं।
बात यह है कि, हमारा उपयोगकर्ता व्यवस्थापक है, और यह असंभव है कि यह पासवर्ड गलत है "कभी-कभी"। हम इस बात पर विचार कर रहे हैं कि समस्या बुनियादी ढांचे की समस्या के कारण हो सकती है, लेकिन यह वास्तव में विभाग नहीं है।
मुझे पता है कि यह एक लंबी पोस्ट है, लेकिन हमें यकीन नहीं है कि अब क्या करना है। एक और सर्वर जोड़ना और भार को संतुलित करना हमारी समस्याओं को हल करेगा? क्या हमारे संतुलन को मापने का तरीका है और पता है कि विभाजन कहां शुरू करना है? लोड आदि की सामान्य संख्या क्या हैं?
मैं किसी भी उत्तर की सराहना करता हूं क्योंकि ये समस्याएं और भी खराब हो रही हैं और हम भी समय सीमा पर हैं।
उत्तर के लिए बहुत बहुत धन्यवाद!
हमें एक ही समस्या है, क्या आपके पास कोई और दस्तावेज है? –