2012-02-27 9 views
7

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

सभी deployers में भंडारण विन्यास भी डेटाबेस में सामग्री डाल, तो कैसे Tridion इस क्या करता है? क्या यह डुप्लिकेट प्रविष्टियों, लॉकिंग विफलताओं आदि का कारण बन सकता है?

मुझे लिखने के समय डर है कि मुझे यह देखने के लिए पर्यावरण की पहुंच नहीं है कि यह कैसे काम करेगा।

उत्तर

11

एसडीएल सर्वोत्तम अभ्यास एक नियोक्ता और प्रकाशन के बीच एक-से-एक संबंध होना है; इसका मतलब है कि जब तक दो नियोक्ता एक ही सामग्री (उसी प्रकाशन से) प्रकाशित नहीं करते हैं, तो वे फ़ाइल सिस्टम को प्रदान करने के लिए टकराव नहीं करेंगे, यदि तैनात साइटों के बीच अलगाव है उदा। www/pub1 & www/pub2।

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

मुझे व्यक्तिगत रूप से इस सेट को पसंद नहीं है क्योंकि मुझे लगता है कि एक साझा स्थान & साझा फ़ाइल में फ़ाइल सिस्टम सामग्री होस्ट करना बेहतर होगा। या बेहतर अभी भी डेटाबेस में सब कुछ तैनात है और डीडी 4 टी/सीडब्ल्यूए जैसे कुछ का उपयोग करता है।

+0

इस स्थिति में, मान लीजिए कि यह एक एकल प्रकाशन है, जो कई नियोक्ता को प्रकाशित कर रहा है, लेकिन यह केवल ब्रोकर को प्रकाशित करने वाला है। आपके पास क्या सलाह है? – johnwinter

+3

यदि एक नियोक्ता केवल ब्रोकर को प्रकाशित करता है, तो आपके पास एक एसपीओफ़ है। यदि डेटाबेस परिनियोजन करने वाले नियोक्ता विफल रहता है, तो अन्य सभी नियोक्ता के लिए तैनाती अपूर्ण होगी। यदि संगठन अधिक मजबूत बनाने के लिए एक अलग आधारभूत संरचना नहीं लेना चाहता है, तो सबसे अच्छा है कि सभी डीपीलोयर्स एक ही चीज़ (फ़ाइल सिस्टम और डेटाबेस) कर रहे हों और प्रत्येक नियोक्ता के लिए अलग ब्रोकर डेटाबेस हों। –

6

मैंने देखा है (और यहां तक ​​कि ग्राहक सीमाओं के आधार पर की सिफारिश की) समान विन्यास जहां कई deployers है किसी दिए गए लक्ष्य के स्थलों के रूप में विन्यस्त।

केवल deployers में से एक ही लेन-देन के लिए डेटाबेस के लिए लिख सकते हैं, अन्यथा आप संगामिति मुद्दों होगा। तो एक नियोक्ता डेटाबेस को लिखता है, जबकि अन्य सभी फाइल सिस्टम को लिखते हैं।

सभी दलालों/वेब अनुप्रयोगों करने के लिए कॉन्फ़िगर डेटाबेस से पढ़ें।

यह एकाधिक सर्वर और/या डेटा केंद्रों पर तैनाती का मुद्दा हल करता है जहां साझा फ़ाइल सिस्टम (पसंदीदा दृष्टिकोण) का उपयोग करना संभव नहीं है - यह लागत या किसी अन्य कारण के लिए हो)।

संक्षेप में - सबसे अच्छा अभ्यास नहीं, लेकिन यह काम करने के लिए जाना जाता है।

1

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

विचार करने का एक और विकल्प पूरी तरह से स्वतंत्र वितरण नोड्स है। यह आपके प्रस्तुति बॉक्स पर डेटाबेस सर्वर चलाने का भी अर्थ हो सकता है। इन दिनों यह वैसे भी वर्चुअल है ताकि आप अलग-अलग छोटे डेटाबेस सर्वर चला सकें। (लाइसेंसिंग लागत एक महत्वपूर्ण बाधा होगा)

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

बेशक

, आप अतिरेक के लिए दो तैनाती सिस्टम (या तीन) कॉन्फ़िगर कर सकता है, आप सभी क्लस्टरिंग प्रबंधन कर सकते हैं यह सोचते हैं आदि

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

संबंधित मुद्दे