सिस्को बैठक सर्भर 2.5.2. भिडियो सम्मेलन रेकर्डिङको साथ स्केलेबल र लचिलो मोडमा क्लस्टर

यस अंकमा म फेलओभर क्लस्टर मोडमा CMS सर्भर सेटअप गर्ने केही जटिलताहरू देखाउने र व्याख्या गर्नेछु।


थ्योरीसामान्यतया, त्यहाँ तीन प्रकारका CMS सर्भर तैनातीहरू छन्:

• एकल संयुक्त(एकल संयुक्त), अर्थात् यो एउटा सर्भर हो जसमा सबै आवश्यक सेवाहरू चलिरहेका छन्। धेरै जसो अवस्थामा, यस प्रकारको परिनियोजन केवल आन्तरिक ग्राहक पहुँचको लागि उपयुक्त हुन्छ र सानो वातावरणहरूमा जहाँ एकल सर्भरको स्केलेबिलिटी र रिडन्डन्सी सीमाहरू महत्त्वपूर्ण मुद्दा होइनन्, वा परिस्थितिहरूमा जहाँ CMS ले केही कार्यहरू मात्र गर्दछ, जस्तै तदर्थ। सिस्को UCM मा सम्मेलन।

  कामको अनुमानित योजना:
  

• एकल विभाजन(एकल स्प्लिट) बाह्य पहुँचको लागि छुट्टै सर्भर थपेर अघिल्लो डिप्लोइमेन्ट प्रकार विस्तार गर्दछ। लिगेसी डिप्लोयमेन्टहरूमा, यसको मतलब एक CMS सर्भरलाई डिमिलिटराइज्ड नेटवर्क खण्ड (DMZ) मा तैनात गर्नु हो जहाँ बाह्य क्लाइन्टहरूले यसलाई पहुँच गर्न सक्छन्, र नेटवर्क कोरमा एउटा CMS सर्भर जहाँ आन्तरिक ग्राहकहरूले CMS पहुँच गर्न सक्छन्। यो विशेष परिनियोजन मोडेल अब तथाकथित प्रकार द्वारा हटाइएको छ एकल किनारा, जसमा सर्भरहरू हुन्छन् सिस्को एक्सप्रेसवे, जसमा या त उस्तै फायरवाल बाइपास क्षमताहरू छन् वा हुनेछन् त्यसैले क्लाइन्टहरूले समर्पित किनारा CMS सर्भर थप्न आवश्यक पर्दैन।

  कामको अनुमानित योजना:
  

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

तैनातीमा जानु अघि, तपाईंले केही आधारभूत कुराहरू बुझ्न आवश्यक छ, अर्थात्

मुख्य CMS सफ्टवेयर कम्पोनेन्टहरू:

• डाटाबेस: तपाईंलाई केही कन्फिगरेसनहरू संयोजन गर्न अनुमति दिन्छ, जस्तै डायल योजना, प्रयोगकर्ता स्पेस, र प्रयोगकर्ताहरू आफैं। उच्च उपलब्धता (एकल मास्टर) को लागि मात्र क्लस्टरिङ समर्थन गर्दछ।
• कल ब्रिज: अडियो र भिडियो कन्फरेन्सिङको लागि सेवा जसले कल र मल्टिमिडिया प्रक्रियाहरूको व्यवस्थापन र प्रशोधनमा पूर्ण नियन्त्रण प्रदान गर्दछ। उच्च उपलब्धता र स्केलेबिलिटीको लागि क्लस्टरिङलाई समर्थन गर्दछ।
• XMPP सर्भर: सिस्को मीटिंग एप्लिकेसन र/वा WebRTC प्रयोग गरेर ग्राहकहरूको दर्ता र प्रमाणीकरणको लागि जिम्मेवारवास्तविक समय संचार, वा केवल ब्राउजर मा), साथै अन्तरकम्पोनेन्ट सिग्नलिङ। उच्च उपलब्धताको लागि मात्र क्लस्टर गर्न सकिन्छ।
• वेब ब्रिज: WebRTC मा ग्राहक पहुँच प्रदान गर्दछ।
• लोड ब्यालेन्सर: एकल स्प्लिट मोडमा सिस्को मीटिंग एपहरूको लागि एकल जडान बिन्दु प्रदान गर्दछ। आगमन जडानहरूको लागि बाह्य इन्टरफेस र पोर्ट सुन्नुहोस्। समान रूपमा, लोड ब्यालेन्सरले XMPP सर्भरबाट आगमन TLS जडानहरू स्वीकार गर्दछ, जसको माध्यमबाट यसले बाह्य ग्राहकहरूबाट TCP जडानहरू स्विच गर्न सक्छ।
  हाम्रो परिदृश्यमा यो आवश्यक पर्दैन।
• सर्भर घुमाउनुहोस्: अनुमति दिन्छ फायरवाल बाइपास प्रविधि प्रदान गर्दछ
  Cisco Meeting App वा SIP यन्त्रहरू प्रयोग गरेर बाह्य ग्राहकहरूलाई जडान गर्न फायरवाल वा NAT पछाडि हाम्रो CMS राख्नुहोस्। हाम्रो परिदृश्यमा यो आवश्यक पर्दैन।
• वेब व्यवस्थापक: प्रशासनिक इन्टरफेस र API पहुँच, विशेष एकीकृत CM सम्मेलनहरूको लागि सहित।

कन्फिगरेसन मोडहरू

धेरै अन्य सिस्को उत्पादनहरू विपरीत, सिस्को बैठक सर्भरले कुनै पनि प्रकारको तैनाती समायोजन गर्न तीन कन्फिगरेसन विधिहरूलाई समर्थन गर्दछ।

• कमाण्ड लाइन (CLI): प्रारम्भिक कन्फिगरेसन र प्रमाणपत्र कार्यहरूको लागि MMP भनिने कमाण्ड लाइन इन्टरफेस।
• वेब प्रशासक: मुख्य रूपमा CallBridge सम्बन्धित कन्फिगरेसनहरूको लागि, विशेष गरी जब एकल गैर-क्लस्टर गरिएको सर्भर सेटअप गर्दा।
• REST API: सबैभन्दा जटिल कन्फिगरेसन कार्यहरू र क्लस्टर गरिएको डाटाबेस सम्बन्धित कार्यहरूको लागि प्रयोग गरिन्छ।

माथिको अतिरिक्त, प्रोटोकल प्रयोग गरिन्छ SFTP फाइलहरू स्थानान्तरण गर्न — सामान्यतया इजाजतपत्रहरू, प्रमाणपत्रहरू, वा लगहरू-मा र CMS सर्भरबाट।

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

र अभ्यास शोको रूपमा, दुई सर्भरहरू (नोडहरू) वास्तवमै पर्याप्त छैनन्। मास्टर रिबुट हुँदा चयन संयन्त्रले काम गर्छ, रिबुट गरिएको सर्भर ल्याएपछि मात्र दास सर्भर मास्टर हुन्छ। तर, यदि दुईवटा सर्भरको क्लस्टरमा मास्टर सर्भर अचानक बाहिर गयो भने, दास सर्भर मास्टर बन्ने छैन, र यदि दास बाहिर गयो भने, बाँकी मास्टर सर्भर दास हुनेछ।

तर XMPP को सन्दर्भमा, यो वास्तवमै तीन सर्भरहरूको क्लस्टर भेला गर्न आवश्यक हुनेछ, किनभने यदि, उदाहरणका लागि, तपाईले XMPP सेवा असक्षम गर्नुभयो जुन सर्भरहरूमा XMMP लीडर स्थितिमा छ, त्यसपछि बाँकी सर्भरमा XMPP अनुयायी स्थितिमा रहनेछ र XMPP मा CallBridge जडानहरू खस्नेछ, किनभने CallBridge ले नेता स्थिति संग XMPP मा विशेष रूपमा जडान गर्दछ। र यो महत्वपूर्ण छ, किनकि ... एउटा कल पनि जानेछैन।

साथै एउटै डिप्लोइमेन्ट गाइडमा एउटा XMPP सर्भर भएको क्लस्टर प्रदर्शन गरिएको छ।

र माथिको कुरालाई ध्यानमा राख्दै, यो स्पष्ट हुन्छ किन: यसले काम गर्दछ किनभने यो फेलओभर मोडमा छ।

हाम्रो अवस्थामा, XMPP सर्भर सबै तीन नोडहरूमा उपस्थित हुनेछ।

यो मानिन्छ कि हाम्रो तीनवटा सर्भरहरू छन्।

DNS रेकर्ड

तपाईंले सर्भरहरू सेटअप गर्न सुरु गर्नु अघि, तपाईंले DNS रेकर्डहरू सिर्जना गर्न आवश्यक छ А и SRV प्रकार:

कृपया ध्यान दिनुहोस् कि हाम्रो DNS रेकर्डहरूमा उदाहरण.com र दुई डोमेनहरू छन् conf.example.com। Example.com एक डोमेन हो जुन सबै सिस्को युनिफाइड कम्युनिकेसन प्रबन्धक सदस्यहरूले उनीहरूको URI हरू प्रयोग गर्न सक्छन्, जुन सम्भवतः तपाईंको पूर्वाधारमा अवस्थित छ वा उपस्थित हुन सक्छ। वा example.com ले उही डोमेनसँग मेल खान्छ जुन प्रयोगकर्ताहरूले उनीहरूको इमेल ठेगानाहरूको लागि प्रयोग गर्छन्। वा तपाईंको ल्यापटपमा रहेको Jabber ग्राहकसँग URI हुन सक्छ [ईमेल सुरक्षित]। डोमेन conf.example.com डोमेन हो जुन सिस्को मीटिंग सर्भर प्रयोगकर्ताहरूको लागि कन्फिगर गरिनेछ। सिस्को बैठक सर्भर को डोमेन हुनेछ confउदाहरणका लागिconf.example.com।

आधारभूत कन्फिगरेसन

तल वर्णन गरिएका सबै सेटिङहरू एउटै सर्भरमा देखाइएका छन्, तर तिनीहरू क्लस्टरमा प्रत्येक सर्भरमा गर्न आवश्यक छ।

QoS

जब देखि CMS उत्पन्न हुन्छ वास्तविक समय ढिलाइ र प्याकेट हानिको लागि ट्राफिक संवेदनशील, अधिकतर अवस्थामा यो सेवाको गुणस्तर (QoS) कन्फिगर गर्न सिफारिस गरिन्छ। यो प्राप्त गर्नको लागि, CMS ले यसले उत्पन्न गरेको विभेदित सेवा कोडहरू (DSCPs) सँग ट्यागिङ प्याकेटहरूलाई समर्थन गर्दछ। यद्यपि DSCP-आधारित ट्राफिक प्राथमिकता तपाईंको पूर्वाधारको नेटवर्क कम्पोनेन्टहरूद्वारा ट्राफिकलाई कसरी प्रशोधन गरिन्छ भन्ने कुरामा निर्भर गर्दछ, हाम्रो मामलामा हामी QoS उत्कृष्ट अभ्यासहरूमा आधारित विशिष्ट DSCP प्राथमिकताहरूसँग हाम्रो CMS कन्फिगर गर्नेछौं।

प्रत्येक सर्भरमा हामी यी आदेशहरू प्रविष्ट गर्नेछौं

dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1A

यसरी, सबै भिडियो ट्राफिकलाई AF41 (DSCP 0x22) चिन्ह लगाइयो, सबै आवाज ट्राफिक EF (DSCP 0x2E) चिन्ह लगाइयो, अन्य प्रकारका कम विलम्बता ट्राफिक जस्तै SIP र XMPP AF31 (DSCP 0x1A) प्रयोग गर्दछ।

जाँच गर्दै:

एनटीपी

नेटवर्क टाइम प्रोटोकल (NTP) कल र सम्मेलनहरूको सही टाइमस्ट्याम्पहरू प्रदान गर्नका लागि मात्र होइन, तर प्रमाणपत्रहरू प्रमाणीकरणको लागि पनि महत्त्वपूर्ण छ।

तपाईंको पूर्वाधारमा NTP सर्भरहरू थप्नुहोस् जस्तै आदेशको साथ

ntp server add <server>

हाम्रो अवस्थामा, त्यहाँ दुईवटा सर्भरहरू छन्, त्यसैले त्यहाँ दुई टोलीहरू हुनेछन्।
जाँच गर्दै:

र हाम्रो सर्भरको लागि समय क्षेत्र सेट गर्नुहोस्

DNS

हामीले CMS मा DNS सर्भरहरू निम्न आदेशको साथ थप्छौं:

dns add forwardzone <domain-name> <server ip>

हाम्रो अवस्थामा, त्यहाँ दुईवटा सर्भरहरू छन्, त्यसैले त्यहाँ दुई टोलीहरू हुनेछन्।
जाँच गर्दै:

नेटवर्क इन्टरफेस कन्फिगरेसन

हामी इन्टरफेसलाई आदेशको साथ कन्फिगर गर्छौं जस्तै:

ipv4 <interface> add <address>/<prefix length> <gateway>

जाँच गर्दै:

सर्भर नाम (होस्टनाम)

हामीले सर्भर नामलाई आदेशको साथ सेट गर्छौं:

hostname <name>

र हामी रिबुट गर्छौं।


यसले आधारभूत कन्फिगरेसन पूरा गर्दछ।

.Ы

थ्योरीसिस्को मीटिंग सर्भरलाई विभिन्न कम्पोनेन्टहरू बीच इन्क्रिप्टेड सञ्चार चाहिन्छ, र परिणाम स्वरूप, सबै CMS डिप्लोइमेन्टहरूको लागि X.509 प्रमाणपत्रहरू आवश्यक हुन्छ। तिनीहरूले सेवाहरू/सर्भरहरू अन्य सर्भरहरू/सेवाहरूद्वारा विश्वसनीय छन् भनी सुनिश्चित गर्न मद्दत गर्छन्।

प्रत्येक सेवालाई प्रमाणपत्र चाहिन्छ, तर प्रत्येक सेवाको लागि छुट्टै प्रमाणपत्रहरू सिर्जना गर्दा भ्रम र अनावश्यक जटिलता निम्त्याउन सक्छ। सौभाग्यवश, हामी प्रमाणपत्रको सार्वजनिक-निजी कुञ्जी जोडा उत्पन्न गर्न सक्छौं र त्यसपछि तिनीहरूलाई धेरै सेवाहरूमा पुन: प्रयोग गर्न सक्छौं। हाम्रो केसमा, उही प्रमाणपत्र कल ब्रिज, XMPP सर्भर, वेब ब्रिज र वेब प्रशासकको लागि प्रयोग गरिनेछ। यसरी, तपाईंले क्लस्टरमा प्रत्येक सर्भरको लागि सार्वजनिक र निजी प्रमाणपत्र कुञ्जीहरूको एक जोडी सिर्जना गर्न आवश्यक छ।

डाटाबेस क्लस्टरिङ, तथापि, केही विशेष प्रमाणपत्र आवश्यकताहरू छन् र त्यसैले यसको आफ्नै प्रमाणपत्रहरू आवश्यक छ जुन अन्य सेवाहरू भन्दा फरक छन्। CMS ले सर्भर प्रमाणपत्र प्रयोग गर्दछ, जुन अन्य सर्भरहरू द्वारा प्रयोग गरिएको प्रमाणपत्रहरू जस्तै छ, तर त्यहाँ डाटाबेस जडानहरूको लागि प्रयोग गरिएको क्लाइन्ट प्रमाणपत्र पनि छ। डाटाबेस प्रमाणपत्रहरू प्रमाणीकरण र गुप्तिकरण दुवैको लागि प्रयोग गरिन्छ। डाटाबेसमा जडान गर्न ग्राहकको लागि प्रयोगकर्ता नाम र पासवर्ड प्रदान गर्नुको सट्टा, यसले सर्भरद्वारा विश्वसनीय ग्राहक प्रमाणपत्र प्रस्तुत गर्दछ। डाटाबेस क्लस्टरमा प्रत्येक सर्भरले समान सार्वजनिक र निजी कुञ्जी जोडी प्रयोग गर्नेछ। यसले क्लस्टरमा रहेका सबै सर्भरहरूलाई डेटा इन्क्रिप्ट गर्नको लागि अनुमति दिन्छ कि यसलाई अन्य सर्भरहरूद्वारा मात्र डिक्रिप्ट गर्न सकिन्छ जसले समान कुञ्जी जोडी साझेदारी गर्दछ।

काम गर्न रिडन्डन्सीको लागि, डाटाबेस क्लस्टरहरूमा न्यूनतम 3 सर्भरहरू समावेश हुनुपर्छ, तर 5 भन्दा बढी, कुनै पनि क्लस्टर सदस्यहरू बीच अधिकतम 200 ms को राउन्ड-ट्रिप समयको साथ। यो सीमा कल ब्रिज क्लस्टरिङको तुलनामा बढी प्रतिबन्धात्मक छ, त्यसैले यो प्रायः भौगोलिक रूपमा वितरित परिनियोजनहरूमा सीमित कारक हो।

CMS को लागि डाटाबेस भूमिकामा धेरै अद्वितीय आवश्यकताहरू छन्। अन्य भूमिकाहरूको विपरीत, यसलाई ग्राहक र सर्भर प्रमाणपत्र चाहिन्छ, जहाँ ग्राहक प्रमाणपत्रसँग सर्भरमा प्रस्तुत गरिएको विशिष्ट CN क्षेत्र हुन्छ।

CMS ले एउटा मास्टर र धेरै पूरै समान प्रतिकृतिहरूको साथ पोस्टग्रेस डाटाबेस प्रयोग गर्दछ। एक पटकमा एउटा मात्र प्राथमिक डाटाबेस हुन्छ ("डेटाबेस सर्भर")। क्लस्टरका बाँकी सदस्यहरू प्रतिकृतिहरू वा "डेटाबेस ग्राहकहरू" हुन्।

डाटाबेस क्लस्टरलाई समर्पित सर्भर प्रमाणपत्र र ग्राहक प्रमाणपत्र चाहिन्छ। तिनीहरू प्रमाणपत्रहरू द्वारा हस्ताक्षरित हुनुपर्छ, सामान्यतया एक आन्तरिक निजी प्रमाणपत्र प्राधिकरण। किनभने डाटाबेस क्लस्टरको कुनै पनि सदस्य मास्टर बन्न सक्छ, डाटाबेस सर्भर र क्लाइन्ट प्रमाणपत्र जोडीहरू (सार्वजनिक र निजी कुञ्जीहरू सहित) सबै सर्भरहरूमा प्रतिलिपि गरिनुपर्छ ताकि तिनीहरूले क्लाइन्ट वा डाटाबेस सर्भरको पहिचान मान्न सकून्। थप रूपमा, क्लाइन्ट र सर्भर प्रमाणपत्रहरू प्रमाणित गर्न सकिन्छ भनेर सुनिश्चित गर्न CA मूल प्रमाणपत्र लोड हुनुपर्छ।

त्यसोभए, हामी प्रमाणपत्रको लागि अनुरोध सिर्जना गर्छौं जुन डाटाबेस बाहेक सबै सर्भर सेवाहरू द्वारा प्रयोग गरिने छ (यसको लागि छुट्टै अनुरोध हुनेछ) जस्तै:

pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com

CN मा हामी हाम्रा सर्भरहरूको सामान्य नाम लेख्छौं। उदाहरणका लागि, यदि हाम्रो सर्भरहरूको होस्टनामहरू सर्भर 01, सर्भर 02, सर्भर 03, त्यसपछि CN हुनेछ server.example.com

हामी बाँकी दुई सर्भरहरूमा फरकसँग त्यही गर्छौं जुन आदेशहरूले सम्बन्धित "होस्टनामहरू" समावेश गर्दछ।

हामी प्रमाणपत्रहरूको लागि दुई अनुरोधहरू उत्पन्न गर्छौं जुन डाटाबेस सेवाद्वारा निम्न आदेशहरू प्रयोग गरिनेछ:

pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com

pki csr dbclusterclient CN:postgres

जहाँ dbclusterserver и dbclusterclient हाम्रा अनुरोधहरू र भविष्यका प्रमाणपत्रहरूको नामहरू, होस्टनाम1(2)(3) सम्बन्धित सर्भरहरूको नाम।

हामी यो प्रक्रिया एउटा सर्भरमा मात्र गर्छौं (!), र हामी प्रमाणपत्रहरू र सम्बन्धित .key फाइलहरू अन्य सर्भरहरूमा अपलोड गर्नेछौं।

AD CS मा ग्राहक प्रमाणपत्र मोड सक्षम गर्नुहोस्

तपाईंले प्रत्येक सर्भरका लागि प्रमाणपत्रहरूलाई एउटै फाइलमा मर्ज गर्न आवश्यक छ।*NIX मा:

cat server01.cer server02.cer server03.cer > server.cer

Windows/DOS मा:

copy server01.cer + server02.cer + server03.cer  server.cer

र प्रत्येक सर्भरमा अपलोड गर्नुहोस्:
1. "व्यक्तिगत" सर्भर प्रमाणपत्र।
2. रूट प्रमाणपत्र (मध्यवर्ती व्यक्तिहरूसँग, यदि कुनै छ भने)।
3. डाटाबेसका लागि प्रमाणपत्रहरू ("सर्भर" र "ग्राहक") र .key विस्तारका साथ फाइलहरू, जुन "सर्भर" र "ग्राहक" डाटाबेस प्रमाणपत्रहरूको लागि अनुरोध सिर्जना गर्दा उत्पन्न गरिएको थियो। यी फाइलहरू सबै सर्भरहरूमा समान हुनुपर्छ।
4. सबै तीन "व्यक्तिगत" प्रमाणपत्रहरूको फाइल।

नतिजाको रूपमा, तपाईंले प्रत्येक सर्भरमा यो फाइल तस्वीर जस्तै केहि प्राप्त गर्नुपर्छ।

डाटाबेस क्लस्टर

अब जब तपाइँसँग CMS सर्भरहरूमा अपलोड गरिएका सबै प्रमाणपत्रहरू छन्, तपाइँ तीन नोडहरू बीचको डाटाबेस क्लस्टरिङ कन्फिगर र सक्षम गर्न सक्नुहुन्छ। पहिलो चरण भनेको डाटाबेस क्लस्टरको मास्टर नोडको रूपमा एउटा सर्भर चयन गर्नु र यसलाई पूर्ण रूपमा कन्फिगर गर्नु हो।

मास्टर डाटाबेस

डाटाबेस प्रतिकृति सेटअप गर्ने पहिलो चरण भनेको डाटाबेसका लागि प्रयोग गरिने प्रमाणपत्रहरू निर्दिष्ट गर्नु हो। यो आदेश प्रयोग गरी गरिन्छ जस्तै:

database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

अब CMS लाई कमाण्डको साथ डाटाबेस क्लस्टरिङका लागि कुन इन्टरफेस प्रयोग गर्ने भनौं:

database cluster localnode a

त्यसपछि हामी मुख्य सर्भरमा क्लस्टर डाटाबेस आदेशको साथ प्रारम्भ गर्छौं:

database cluster initialize

ग्राहक डाटाबेस नोड्स

हामी एउटै प्रक्रिया गर्छौं, केवल आदेशको सट्टा डाटाबेस क्लस्टर प्रारम्भ आदेश प्रविष्ट गर्नुहोस् जस्तै:

database cluster join <ip address existing master>

जहाँ आईपी ठेगाना अवस्थित CMS सर्भरको मास्टर आईपी ठेगाना जसमा क्लस्टर प्रारम्भ गरिएको थियो, केवल मास्टर।

हामी जाँच गर्छौं कि हाम्रो डाटाबेस क्लस्टरले आदेशको साथ सबै सर्भरहरूमा कसरी काम गर्दछ:

database cluster status

हामी बाँकी तेस्रो सर्भरमा पनि त्यस्तै गर्छौं।

नतिजाको रूपमा, यो बाहिर जान्छ कि हाम्रो पहिलो सर्भर मास्टर हो, बाँकी दासहरू हुन्।

वेब प्रशासन सेवा

वेब प्रशासक सेवा सक्षम गर्नुहोस्:

webadmin listen a 445

पोर्ट 445 छनौट गरिएको थियो किनभने पोर्ट 443 वेब क्लाइन्टमा प्रयोगकर्ता पहुँचको लागि प्रयोग गरिन्छ

हामीले वेब एडमिन सेवालाई सर्टिफिकेट फाइलहरू जस्तै आदेशको साथ कन्फिगर गर्छौं:

webadmin certs <keyfile> <certificatefile> <ca bundle>

र आदेशको साथ वेब प्रशासक सक्षम गर्नुहोस्:

webadmin enable

यदि सबै ठीक छ भने, हामीले सञ्जाल र प्रमाणपत्रको लागि वेब प्रशासक सही रूपमा कन्फिगर गरिएको छ भनेर संकेत गर्ने सफलता लाइनहरू प्राप्त गर्नेछौं। हामी वेब ब्राउजर प्रयोग गरेर सेवाको कार्यक्षमता जाँच गर्छौं र वेब प्रशासकको ठेगाना प्रविष्ट गर्छौं, उदाहरणका लागि: cms.example.com: 445

कल ब्रिज क्लस्टर

प्रत्येक CMS डिप्लोयमेन्टमा कल ब्रिज मात्र उपलब्ध सेवा हो। कल ब्रिज मुख्य सम्मेलन संयन्त्र हो। यसले एक SIP इन्टरफेस पनि प्रदान गर्दछ जसले गर्दा कलहरू यसमा वा बाट रुट गर्न सकिन्छ, उदाहरणका लागि, सिस्को युनिफाइड सीएम।

तल वर्णन गरिएका आदेशहरू प्रत्येक सर्भरमा उपयुक्त सर्टिफिकेटहरूको साथ कार्यान्वयन गरिनुपर्छ।
त्यसैले:

हामी कल ब्रिज सेवासँग प्रमाणपत्रहरू सम्बद्ध गर्दछौं जस्तै:

callbridge certs <keyfile> <certificatefile>[<cert-bundle>]

हामीले CallBridge सेवाहरूलाई इन्टरफेसमा जोड्छौं जुन हामीलाई आदेशको साथ चाहिन्छ:

callbridge listen a

र आदेशको साथ सेवा पुन: सुरु गर्नुहोस्:

callbridge restart

अब हामीले हाम्रो कल ब्रिजहरू कन्फिगर गरेका छौं, हामी कल ब्रिज क्लस्टरिङ कन्फिगर गर्न सक्छौं। कल ब्रिज क्लस्टरिङ डाटाबेस वा XMPP क्लस्टरिङ भन्दा फरक छ। कल ब्रिज क्लस्टरले कुनै पनि प्रतिबन्ध बिना 2 देखि 8 नोडहरू समर्थन गर्न सक्छ। यसले रिडन्डन्सी मात्र प्रदान गर्दैन, तर लोड ब्यालेन्सिङ पनि प्रदान गर्दछ ताकि सम्मेलनहरू कल ब्रिज सर्भरहरूमा बौद्धिक कल वितरण प्रयोग गरेर सक्रिय रूपमा वितरण गर्न सकिन्छ। CMS मा थप सुविधाहरू, कल ब्रिज समूहहरू र सम्बन्धित सुविधाहरू छन् जुन थप व्यवस्थापनको लागि प्रयोग गर्न सकिन्छ।

कल ब्रिज क्लस्टरिङ मुख्य रूपमा वेब प्रशासक इन्टरफेस मार्फत कन्फिगर गरिएको छ
तल वर्णन गरिएको प्रक्रिया क्लस्टरमा प्रत्येक सर्भरमा पूरा गर्नुपर्छ।
र त्यसैले,

1. वेब मार्फत कन्फिगरेसन > क्लस्टरमा जानुहोस्।
२.इन कल ब्रिज पहिचान एक अद्वितीय नामको रूपमा, सर्भर नामसँग सम्बन्धित कलब्रिज[01,02,03] प्रविष्ट गर्नुहोस्। यी नामहरू मनमानी छन्, तर यो क्लस्टरको लागि अद्वितीय हुनुपर्छ। तिनीहरू प्रकृतिमा वर्णनात्मक छन् किनभने तिनीहरूले संकेत गर्छन् कि तिनीहरू सर्भर पहिचानकर्ता हुन् [०१,०२,०३]।
५.B क्लस्टर गरिएको कल ब्रिजहरू क्लस्टरमा हाम्रा सर्भरहरूको वेब प्रशासक URL प्रविष्ट गर्नुहोस्, CMS[01,02,03].example.com:445, ठेगाना फिल्डमा। पोर्ट निर्दिष्ट गर्न निश्चित हुनुहोस्। तपाइँ पियर लिङ्क SIP डोमेन खाली छोड्न सक्नुहुन्छ।
4. प्रत्येक सर्भरको कलब्रिज ट्रस्टमा प्रमाणपत्र थप्नुहोस्, जसको फाइलमा हाम्रा सर्भरहरूका सबै प्रमाणपत्रहरू छन्, जुन हामीले यस फाइलमा सुरुमै मर्ज गरेका थियौं, जस्तै:

callbridge trust cluster <trusted cluster certificate bundle>

र आदेशको साथ सेवा पुन: सुरु गर्नुहोस्:

callbridge restart

नतिजाको रूपमा, प्रत्येक सर्भरमा तपाईंले यो चित्र प्राप्त गर्नुपर्छ:

XMPP क्लस्टर

CMS मा XMPP सेवा CMA WebRTC वेब क्लाइन्ट सहित Cisco Meeting Apps (CMA) को लागि सबै दर्ता र प्रमाणीकरण ह्यान्डल गर्न प्रयोग गरिन्छ। कल ब्रिजले पनि प्रमाणीकरण उद्देश्यका लागि XMPP क्लाइन्टको रूपमा कार्य गर्दछ र त्यसैले अन्य ग्राहकहरू जस्तै कन्फिगर गरिनुपर्छ। XMPP दोष सहिष्णुता एक विशेषता हो जुन संस्करण 2.1 देखि उत्पादन वातावरणमा समर्थित छ

तल वर्णन गरिएका आदेशहरू प्रत्येक सर्भरमा उपयुक्त सर्टिफिकेटहरूको साथ कार्यान्वयन गरिनुपर्छ।
त्यसैले:

हामी XMPP सेवासँग प्रमाणपत्रहरू सम्बद्ध गर्दछौं जस्तै:

xmpp certs <keyfile> <certificatefile>[<cert-bundle>]

त्यसपछि आदेशको साथ सुन्ने इन्टरफेस परिभाषित गर्नुहोस्:

xmpp listen a

XMPP सेवालाई एक अद्वितीय डोमेन चाहिन्छ। यो प्रयोगकर्ताहरूको लागि लगइन हो। अर्को शब्दमा, जब प्रयोगकर्ताले CMA एप (वा WebRTC क्लाइन्ट मार्फत) प्रयोग गरेर लगइन गर्ने प्रयास गर्छ, तिनीहरू userID@logindomain प्रविष्ट गर्छन्। हाम्रो अवस्थामा यो userid@ हुनेछconf.example.com। किन यो उदाहरण.com मात्र होइन? हाम्रो विशेष परिनियोजनमा, हामीले हाम्रो एकीकृत CM डोमेन चयन गर्यौं जुन Jabber प्रयोगकर्ताहरूले Uniified CM मा example.com को रूपमा प्रयोग गर्नेछन्, त्यसैले हामीलाई CMS प्रयोगकर्ताहरूलाई SIP डोमेनहरू मार्फत CMS मा र बाट कलहरू रुट गर्न फरक डोमेन चाहिन्छ।

आदेश प्रयोग गरेर XMPP डोमेन सेट अप गर्नुहोस् जस्तै:

xmpp domain <domain>

र आदेशको साथ XMPP सेवा सक्षम गर्नुहोस्:

xmpp enable

XMPP सेवामा, तपाईंले प्रत्येक कल ब्रिजको लागि प्रमाणहरू सिर्जना गर्नुपर्छ जुन XMPP सेवामा दर्ता गर्दा प्रयोग गरिनेछ। यी नामहरू मनमानी छन् (र तपाईंले कल ब्रिज क्लस्टरिङको लागि कन्फिगर गर्नुभएको अद्वितीय नामहरूसँग सम्बन्धित छैनन्)। तपाईंले एउटा XMPP सर्भरमा तीनवटा कल ब्रिजहरू थप्नु पर्छ र त्यसपछि क्लस्टरमा अन्य XMPP सर्भरहरूमा ती प्रमाणहरू प्रविष्ट गर्नुहोस् किनभने यो कन्फिगरेसन क्लस्टर डाटाबेसमा फिट हुँदैन। पछि हामी XMPP सेवामा दर्ता गर्न यो नाम र गोप्य प्रयोग गर्न प्रत्येक कल ब्रिज कन्फिगर गर्नेछौं।

अब हामीले XMPP सेवालाई पहिलो सर्भरमा तीनवटा कल ब्रिजहरू callbridge01, callbridge02 र callbridge03 सँग कन्फिगर गर्न आवश्यक छ। प्रत्येक खातालाई अनियमित पासवर्डहरू तोकाइनेछ। तिनीहरू पछि यो XMPP सर्भरमा लग इन गर्न अन्य कल ब्रिज सर्भरहरूमा प्रविष्ट गरिनेछन्। निम्न आदेशहरू प्रविष्ट गर्नुहोस्:

xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03

नतिजाको रूपमा, हामी आदेशको साथ के भयो जाँच गर्छौं:

xmpp callbridge list

ठ्याक्कै उही तस्वीर तल वर्णन गरिएका चरणहरू पछि बाँकी सर्भरहरूमा देखा पर्दछ।

अर्को, हामी बाँकी दुई सर्भरहरूमा ठ्याक्कै समान सेटिङहरू थप्छौं, केवल आदेशहरूसँग

xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03

हामी धेरै सावधानीपूर्वक गोप्य थप्छौं ताकि, उदाहरणका लागि, यसमा कुनै अतिरिक्त खाली ठाउँहरू छैनन्।


नतिजाको रूपमा, प्रत्येक सर्भरमा एउटै तस्वीर हुनुपर्छ:

अर्को, क्लस्टरका सबै सर्भरहरूमा, हामी तीनवटा प्रमाणपत्रहरू समावेश भएको फाइललाई विश्वासमा निर्दिष्ट गर्छौं, यस प्रकारको आदेशको साथ पहिले सिर्जना गरिएको:

xmpp cluster trust <trust bundle>

हामीले आदेशको साथ सबै क्लस्टर सर्भरहरूमा xmpp क्लस्टर मोड सक्षम गर्छौं:

xmpp cluster enable

क्लस्टरको पहिलो सर्भरमा, हामी आदेशको साथ xmpp क्लस्टरको सिर्जना सुरु गर्छौं:

xmpp cluster initialize

अन्य सर्भरहरूमा, आदेशको साथ xmpp मा क्लस्टर थप्नुहोस् जस्तै:

xmpp cluster join <ip address head xmpp server>

हामी प्रत्येक सर्भरमा आदेशहरू सहित प्रत्येक सर्भरमा XMPP क्लस्टर सिर्जना गर्ने सफलता जाँच गर्छौं:

xmpp status
xmpp cluster status

पहिलो सर्भर:

दोस्रो सर्भर:

तेस्रो सर्भर:

XMPP मा कल ब्रिज जडान गर्दै

अब XMPP क्लस्टर चलिरहेको छ, तपाईंले XMPP क्लस्टरमा जडान गर्न कल ब्रिज सेवाहरू कन्फिगर गर्न आवश्यक छ। यो कन्फिगरेसन वेब प्रशासक मार्फत गरिन्छ।

प्रत्येक सर्भरमा, कन्फिगरेसन > सामान्य र फिल्डमा जानुहोस् अद्वितीय कल ब्रिज नाम सर्भर कल ब्रिज अनुरूप अद्वितीय नामहरू लेख्नुहोस् कलब्रिज [०१,०२,०३]। В поле डोमेन conf.example.ru र सम्बन्धित पासवर्डहरू, तपाईं तिनीहरूलाई जासूस गर्न सक्नुहुन्छ
आदेशको साथ क्लस्टरमा कुनै पनि सर्भरमा:

xmpp callbridge list

"सर्भर" फिल्ड खाली छोड्नुहोस् कलब्रिज को लागि DNS SRV लुकअप प्रदर्शन गर्नेछ _xmpp-component._tcp.conf.example.comउपलब्ध XMPP सर्भर फेला पार्न। XMPP मा कलब्रिजहरू जडान गर्नका लागि आईपी ठेगानाहरू प्रत्येक सर्भरमा फरक हुन सक्छ, यो रेकर्ड अनुरोधमा कुन मानहरू फर्काइन्छ भन्नेमा निर्भर गर्दछ। _xmpp-component._tcp.conf.example.com callbridge, जुन बदलेमा दिइएको DNS रेकर्डको लागि प्राथमिकता सेटिङहरूमा निर्भर गर्दछ।

अर्को, कल ब्राइड सेवा XMPP सेवामा सफलतापूर्वक जडान भएको छ कि छैन भनी प्रमाणित गर्न Status > General मा जानुहोस्।

वेब ब्रिज

क्लस्टरमा प्रत्येक सर्भरमा, आदेशको साथ वेब ब्रिज सेवा सक्षम गर्नुहोस्:

webbridge listen a:443

हामीले वेब ब्रिज सेवालाई सर्टिफिकेट फाइलहरू जस्तै आदेशको साथ कन्फिगर गर्छौं:

webbridge  certs <keyfile> <certificatefile> <ca bundle>

वेब ब्रिजले HTTPS लाई समर्थन गर्दछ। यदि "http-पुनर्निर्देशन" प्रयोग गर्न कन्फिगर गरिएको छ भने यसले HTTPS मा HTTP रिडिरेक्ट गर्नेछ।
HTTP पुनर्निर्देशन सक्षम गर्न, निम्न आदेश प्रयोग गर्नुहोस्:

webbridge http-redirect enable

वेब ब्रिजले कल ब्रिजबाट जडानहरू विश्वास गर्न सक्छ भनी कल ब्रिजलाई थाहा दिन, आदेश प्रयोग गर्नुहोस्:

webbridge trust <certfile>

जहाँ यो क्लस्टरमा प्रत्येक सर्भरबाट तीनवटा प्रमाणपत्रहरू समावेश भएको फाइल हो।

यो तस्विर क्लस्टरको प्रत्येक सर्भरमा हुनुपर्छ।


अब हामीले "appadmin" भूमिकाको साथ प्रयोगकर्ता सिर्जना गर्न आवश्यक छ, हामीलाई यो आवश्यक छ कि हामी हाम्रो क्लस्टर(!), र क्लस्टरमा प्रत्येक सर्भरलाई अलग-अलग कन्फिगर गर्न सक्छौं, यसरी सेटिङहरू प्रत्येक सर्भरमा समान रूपमा लागू हुनेछन्। तिनीहरू एक पटक बनाइनेछन् भन्ने तथ्य।


थप सेटअपको लागि हामी प्रयोग गर्नेछौं हुलाकी.

प्राधिकरणको लागि, प्राधिकरण खण्डमा आधारभूत चयन गर्नुहोस्

CMS सर्भरमा आदेशहरू सही रूपमा पठाउनको लागि, तपाईंले आवश्यक इन्कोडिङ सेट गर्न आवश्यक छ

हामीले कमाण्डको साथ वेबब्रिज निर्दिष्ट गर्छौं पोस्ट प्यारामिटर संग URL र अर्थ cms.example.com



वेबब्रिजमा नै, हामी आवश्यक प्यारामिटरहरू संकेत गर्छौं: अतिथि पहुँच, सुरक्षित पहुँच, आदि।

पुल समूहहरू कल गर्नुहोस्

पूर्वनिर्धारित रूपमा, CMS ले सधैं यसमा उपलब्ध कन्फरेन्सिङ स्रोतहरूको सबैभन्दा कुशल प्रयोग गर्दैन।

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

यी समस्याहरू कल ब्रिज समूह सुविधा प्रयोग गरेर हल गरिन्छ। यो सुविधा सिस्को मीटिंग सर्भर सफ्टवेयरको संस्करण २.१ मा प्रस्तुत गरिएको थियो र WebRTC सहभागीहरू सहित इनबाउन्ड र आउटबाउन्ड सिस्को मीटिंग एप (CMA) कलहरूको लागि लोड सन्तुलन समर्थन गर्न विस्तार गरिएको छ।

पुन: जडान समस्या समाधान गर्न, प्रत्येक कल ब्रिजको लागि तीन कन्फिगर योग्य लोड सीमाहरू प्रस्तुत गरिएको छ:

लोडसीमा - यो एक विशेष कल ब्रिज को लागी अधिकतम संख्यात्मक लोड हो। प्रत्येक प्लेटफर्मको सिफारिस गरिएको लोड सीमा हुन्छ, जस्तै CMS96000 को लागि 1000 र भर्चुअल मेसिनको लागि 1.25 GHz प्रति vCPU। सहभागीको रिजोल्युसन र फ्रेम दरको आधारमा विभिन्न कलहरूले निश्चित मात्रामा स्रोतहरू खपत गर्छन्।
NewConferenceLoadLimitBasisPoints (पूर्वनिर्धारित 50% loadLimit) - सर्भर लोड सीमा सेट गर्दछ, जस पछि नयाँ सम्मेलनहरू अस्वीकार गरिन्छ।
अवस्थित ConferenceLoadLimitBasisPoints (लोडलिमिटको पूर्वनिर्धारित 80%) - सर्भर लोड मान जस पछि अवस्थित सम्मेलनमा सामेल हुने सहभागीहरूलाई अस्वीकार गरिनेछ।

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

यी प्यारामिटरहरू यहाँ कन्फिगर गरिएका छन्: cms.example.com:445/api/v1/system/configuration/cluster

अर्को, हामी प्रत्येक कलब्रिजलाई संकेत गर्छौं कि यो कुन कलब्रिज समूहसँग सम्बन्धित छ:

पहिलो कलब्रिज

दोस्रो कलब्रिज

तेस्रो कलब्रिज


यसरी, हामीले सिस्को मीटिंग सर्भर क्लस्टरका स्रोतहरूलाई अझ प्रभावकारी रूपमा प्रयोग गर्न कल ब्रडिज समूहलाई कन्फिगर गर्यौं।

सक्रिय निर्देशिकाबाट प्रयोगकर्ताहरू आयात गर्दै

वेब प्रशासक सेवासँग LDAP कन्फिगरेसन खण्ड छ, तर यसले जटिल कन्फिगरेसन विकल्पहरू प्रदान गर्दैन, र जानकारी क्लस्टर डाटाबेसमा भण्डार गरिएको छैन, त्यसैले कन्फिगरेसन गर्नुपर्दछ, या त वेब इन्टरफेस मार्फत प्रत्येक सर्भरमा म्यानुअल रूपमा, वा मार्फत। API, र त्यसैले हामी "तीन पटक "उठ्नु हुँदैन" हामी अझै पनि API मार्फत डाटा सेट गर्नेछौं।

पहुँच गर्न URL प्रयोग गर्दै cms01.example.com:445/api/v1/ldapServers ले LDAP सर्भर वस्तु सिर्जना गर्दछ, मापदण्डहरू निर्दिष्ट गर्दै जस्तै:

• सर्भर आईपी
• पोर्ट नम्बर
• प्रयोगकर्ता नाम
• पासवर्ड
• सुरक्षित

सुरक्षित - पोर्टको आधारमा सही वा गलत छान्नुहोस्, 389 - सुरक्षित छैन, 636 - सुरक्षित।


सिस्को मीटिंग सर्भरमा विशेषताहरूमा LDAP स्रोत प्यारामिटरहरू म्याप गर्दै।
LDAP म्यापिङले LDAP डाइरेक्टरीमा रहेका विशेषताहरूलाई CMS मा रहेका विशेषताहरूमा नक्सा गर्छ। वास्तविक विशेषताहरू:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

विशेषताहरूको विवरणIADB CMS मा प्रयोगकर्ताको लगइन ID को प्रतिनिधित्व गर्दछ। यो Microsoft Active Directory LDAP सर्भर भएको हुनाले, CMS JID ले LDAP मा sAMAccountName मा नक्सा गर्छ, जुन अनिवार्य रूपमा प्रयोगकर्ताको सक्रिय निर्देशिका लगइन ID हो। यो पनि याद गर्नुहोस् कि तपाईंले sAMAccountName लिनुहोस् र यसको अन्त्यमा डोमेन conf.pod6.cms.lab थप्नुहोस् किनभने यो लगइन हो जुन तपाईंका प्रयोगकर्ताहरूले CMS मा लग इन गर्न प्रयोग गर्नेछन्।

nameMapping प्रयोगकर्ताको CMS नाम फिल्डमा सक्रिय डाइरेक्टरी प्रदर्शननाम फिल्डमा रहेको कुरासँग मेल खान्छ।

coSpaceNameMapping प्रदर्शननाम फिल्डमा आधारित CMS स्पेस नाम सिर्जना गर्दछ। यो विशेषता, coSpaceUriMapping विशेषता सहित, प्रत्येक प्रयोगकर्ताको लागि ठाउँ सिर्जना गर्न आवश्यक छ।

coSpaceUriMapping प्रयोगकर्ताको व्यक्तिगत ठाउँसँग सम्बन्धित URI को प्रयोगकर्ता भाग परिभाषित गर्दछ। केही डोमेनहरू स्पेसमा डायल गर्न कन्फिगर गर्न सकिन्छ। यदि प्रयोगकर्ताको भागले यी डोमेनहरू मध्ये एकको लागि यो क्षेत्रसँग मेल खान्छ भने, कललाई प्रयोगकर्ताको ठाउँमा निर्देशित गरिनेछ।

coSpaceSecondaryUriMapping स्पेस पुग्नको लागि दोस्रो URI परिभाषित गर्दछ। यो coSpaceUriMapping प्यारामिटरमा परिभाषित अल्फान्यूमेरिक URI को विकल्पको रूपमा आयात गरिएको प्रयोगकर्ताको स्पेसमा कलहरू राउट गर्नको लागि संख्यात्मक उपनाम थप्न प्रयोग गर्न सकिन्छ।

LDAP सर्भर र LDAP म्यापिङ कन्फिगर गरिएको छ। अब तपाईंले LDAP स्रोत सिर्जना गरेर तिनीहरूलाई एकसाथ लिङ्क गर्न आवश्यक छ।

पहुँच गर्न URL प्रयोग गर्दै cms01.example.com:445/api/v1/ldapSource ले LDAP स्रोत वस्तु सिर्जना गर्दछ, मापदण्डहरू निर्दिष्ट गर्दै जस्तै:

• सर्भर
• म्यापिङ
• baseDn
• फिल्टर

अब जब LDAP कन्फिगरेसन पूरा भयो, तपाईले म्यानुअल सिङ्क्रोनाइजेसन कार्य गर्न सक्नुहुन्छ।

हामी यसलाई प्रत्येक सर्भरको वेब इन्टरफेसमा क्लिक गरेर गर्छौं अहिले सि Sy्क गर्नुहोस् खण्ड सक्रिय निर्देशिका


वा आदेशको साथ API मार्फत पोस्ट पहुँच गर्न URL प्रयोग गर्दै cms01.example.com:445/api/v1/ldapSyncs

तदर्थ सम्मेलनहरू

यो के होपरम्परागत अवधारणामा, कन्फरेन्स भनेको दुई सहभागीहरू एकअर्कासँग कुरा गरिरहेको बेला हो, र सहभागीहरूमध्ये एकले (एकीकृत सीएमसँग दर्ता गरिएको यन्त्र प्रयोग गरी) "कन्फ्रेन्स" बटन थिच्छ, अर्को व्यक्तिलाई कल गर्छ, र तेस्रो पक्षसँग कुरा गरेपछि। , त्रिपक्षीय सम्मेलनमा सबै सहभागीहरूलाई सामेल हुन फेरि "सम्मेलन" बटन थिच्नुहोस्।

एउटा Ad-Hoc सम्मेलनलाई CMS मा निर्धारित सम्मेलनबाट के फरक पार्छ त्यो भनेको Ad-Hoc सम्मेलन CMS लाई SIP कल मात्र होइन। जब सम्मेलन प्रारम्भकर्ताले एउटै बैठकमा सबैलाई आमन्त्रित गर्न दोस्रो पटक सम्मेलन बटन क्लिक गर्दछ, एकीकृत CM ले उडानमा कन्फरेन्स सिर्जना गर्न CMS मा API कल गर्नुपर्छ जसमा सबै कलहरू स्थानान्तरण गरिन्छ। यो सबै सहभागीहरू द्वारा बेवास्ता गरिन्छ।

यसको मतलब यो हो कि एकीकृत CM ले कल जारी राख्नको लागि API प्रमाणहरू र सेवाको WebAdmin ठेगाना/पोर्ट साथै SIP ट्रंक सीधा CMS सर्भरमा कन्फिगर गर्नुपर्छ।

आवश्यक भएमा, CUCM ले गतिशील रूपमा CMS मा एउटा स्पेस सिर्जना गर्न सक्छ ताकि प्रत्येक कल CMS मा पुग्न सक्छ र स्पेसहरूको लागि लक्षित आगमन कल नियमसँग मेल खान्छ।

CUCM के साथ एकीकरण लेखमा वर्णन गरिए जस्तै कन्फिगर गरियो पहिले सिस्को UCM मा बाहेक तपाईंले CMS को लागि तीनवटा ट्रंकहरू सिर्जना गर्न आवश्यक छ, तीन सम्मेलन ब्रिजहरू, SIP सुरक्षा प्रोफाइलमा तीनवटा विषय नामहरू, मार्ग समूहहरू, मार्ग सूचीहरू, मिडिया रिसोर्स समूहहरू र मिडिया रिसोर्स समूह सूचीहरू निर्दिष्ट गर्नुहोस्, र केही रूटिङ नियमहरू थप्नुहोस्। सिस्को बैठक सर्भरमा।

SIP सुरक्षा प्रोफाइल:


ट्रंकहरू:


प्रत्येक ट्रंक समान देखिन्छ:




सम्मेलन पुल


प्रत्येक सम्मेलन ब्रिज समान देखिन्छ:


रुट समूह


मार्ग सूची


मिडिया स्रोत समूह


मिडिया स्रोत समूह सूची

कल नियमहरू

युनिफाइड CM वा एक्सप्रेसवे जस्ता उन्नत कल प्रबन्धन प्रणालीहरूको विपरीत, CMS ले नयाँ कलहरूको लागि SIP अनुरोध-URI फिल्डमा डोमेन मात्र हेर्छ। त्यसैले यदि SIP INVITE sip को लागि हो: [ईमेल सुरक्षित]CMS ले domain.com को मात्र ख्याल राख्छ। CMS ले कल कहाँ रुट गर्ने भनेर निर्धारण गर्न यी नियमहरू पछ्याउँछ:

1. CMS ले पहिला SIP डोमेनलाई आगमन कल नियमहरूमा कन्फिगर गरिएका डोमेनहरूसँग मिलाउन प्रयास गर्छ। यी कलहरू त्यसपछि ("लक्षित") स्पेसहरू वा विशिष्ट प्रयोगकर्ताहरू, आन्तरिक IVRs, वा प्रत्यक्ष रूपमा एकीकृत Microsoft Lync/Skype for Business (S4B) गन्तव्यहरूमा पठाउन सकिन्छ।
2. यदि आगमन कल नियमहरूमा कुनै मेल छैन भने, CMS ले कल फर्वार्डिङ तालिकामा कन्फिगर गरिएको डोमेनसँग मेल खाने प्रयास गर्नेछ। यदि मिल्दो छ भने, नियमले स्पष्ट रूपमा कल अस्वीकार गर्न वा कल फर्वार्ड गर्न सक्छ। यस समयमा, CMS ले डोमेन पुन: लेख्न सक्छ, जुन कहिलेकाहीँ Lync डोमेनहरू कल गर्नका लागि उपयोगी हुन्छ। तपाईं थ्रो पास गर्न पनि छनौट गर्न सक्नुहुन्छ, जसको अर्थ कुनै पनि क्षेत्र थप परिमार्जन गरिने छैन, वा आन्तरिक CMS डायल योजना प्रयोग गर्नुहोस्। यदि कल फर्वार्डिङ नियमहरूमा कुनै मेल छैन भने, पूर्वनिर्धारित कल अस्वीकार गर्न हो। ध्यान राख्नुहोस् कि CMS मा, यद्यपि कल "फर्वार्ड गरिएको" छ, मिडिया अझै पनि CMS मा बाँधिएको छ, जसको मतलब यो सिग्नलिङ र मिडिया ट्राफिक मार्गमा हुनेछ।
त्यसपछि मात्र फर्वार्ड गरिएको कलहरू बाहिर जाने कल नियमहरूको अधीनमा छन्। यी सेटिङहरूले कलहरू पठाइएका गन्तव्यहरू, ट्रंक प्रकार (चाहे यो नयाँ Lync कल होस् वा मानक SIP कल होस्), र कल फर्वार्डिङ नियममा स्थानान्तरण चयन नगरिएमा गर्न सकिने कुनै पनि रूपान्तरणहरू निर्धारण गर्दछ।

यहाँ एक Ad-Hoc सम्मेलन को समयमा के हुन्छ को वास्तविक लग छ

स्क्रिनसटले यसलाई खराब रूपमा देखाउँदछ (मलाई थाहा छैन यसलाई कसरी राम्रो बनाउने), त्यसैले म लगलाई यसरी लेख्नेछु:

Info	127.0.0.1:35870: API user "api" created new space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call create failed to find coSpace -- attempting to retrieve from database

Info	API "001036270012" Space GUID: 7986bb6c-af4e-488d-9190-a75f16844e44 <--> Call GUID: 93bfb890-646c-4364-8795-9587bfdc55ba <--> Call Correlator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 <--> Internal G

Info	127.0.0.1:35872: API user "api" created new call 93bfb890-646c-4364-8795-9587bfdc55ba

Info	call 7: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg bc0be45e-ce8f-411c-be04-594e0220c38e in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 has control/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 named "001036270012"

Info	call 7: configured - API call leg bc0be45e-ce8f-411c-be04-594e0220c38e with SIP call ID "[email protected]"

Info	call 7: setting up UDT RTP session for DTLS (combined media and control)
Info	conference "001036270012": unencrypted call legs now present

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 8: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg db61b242-1c6f-49bd-8339-091f62f5777a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 8: configured - API call leg db61b242-1c6f-49bd-8339-091f62f5777a with SIP call ID "[email protected]"

Info	call 8: setting up UDT RTP session for DTLS (combined media and control)

Info	call 9: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 9: configured - API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a with SIP call ID "[email protected]"

Info	call 9: setting up UDT RTP session for DTLS (combined media and control)
Info	call 8: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (289e823d-6da8-486c-a7df-fe177f05e010) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 7: compensating for far end not matching payload types
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (d27e9a53-2c8a-4e9c-9363-0415cd812767) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 9: BFCP (client role) now active
Info	call 9: sending BFCP hello as client following receipt of hello when BFCP not active
Info	call 9: BFCP (client role) now active
Info	call 7: ending; remote SIP teardown - connected for 0:13
Info	call 7: destroying API call leg bc0be45e-ce8f-411c-be04-594e0220c38e

Info	participant "[email protected]" left space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call 9: on hold
Info	call 9: non matching payload types mode 1/0
Info	call 9: answering offer in non matching payload types mode
Info	call 8: on hold
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: ending; remote SIP teardown - connected for 0:12

Ad-Hoc सम्मेलन आफैं:


आगमन कल नियमहरू
CMS मा कल प्राप्त गर्न सक्षम हुन आगमन कलहरूको प्यारामिटरहरू कन्फिगर गर्न आवश्यक छ। तपाईंले LDAP सेटअपमा देख्नुभयो, सबै प्रयोगकर्ताहरूलाई डोमेन conf.pod6.cms.lab मार्फत आयात गरिएको थियो। त्यसोभए न्यूनतममा, तपाईं स्पेसहरू लक्षित गर्न यस डोमेनमा कलहरू गर्न चाहनुहुन्छ। तपाईंले प्रत्येक CMS सर्भरको पूर्ण रूपमा योग्य डोमेन नाम (र सायद IP ठेगाना पनि) को लागि अभिप्रेरित सबै चीजहरूको लागि नियमहरू सेट अप गर्न आवश्यक पर्दछ। हाम्रो बाह्य कल नियन्त्रण, एकीकृत CM, प्रत्येक CMS सर्भरहरूलाई व्यक्तिगत रूपमा समर्पित SIP ट्रंकहरू कन्फिगर गर्नेछ। यी SIP ट्रंकहरूको गन्तव्य IP ठेगाना हो वा सर्भरको FQDN ले CMS लाई यसको IP ठेगाना वा FQDN मा निर्देशित कलहरू स्वीकार गर्न कन्फिगर गर्न आवश्यक छ कि छैन भनेर निर्धारण गर्नेछ।

डोमेन जसको उच्चतम प्राथमिकता इनबाउन्ड नियम छ कुनै पनि प्रयोगकर्ता स्पेसको लागि डोमेनको रूपमा प्रयोग गरिन्छ। जब प्रयोगकर्ताहरू LDAP मार्फत सिंक हुन्छन्, CMS ले स्वचालित रूपमा खाली ठाउँहरू सिर्जना गर्दछ, तर URI (coSpaceUriMapping) को मात्र प्रयोगकर्ता भाग, उदाहरणका लागि, user.space। भाग डोमेन पूर्ण URI यस नियमको आधारमा उत्पन्न हुन्छ। वास्तवमा, यदि तपाइँ यस बिन्दुमा वेब ब्रिजमा लग इन गर्नुहुन्थ्यो भने, तपाइँ स्पेस URI सँग डोमेन छैन भनेर देख्नुहुनेछ। यो नियमलाई उच्चतम प्राथमिकताको रूपमा सेट गरेर, तपाईंले उत्पन्न स्पेसहरूको लागि डोमेन सेट गर्दै हुनुहुन्छ। conf।example.com।


बहिर्गमन कल नियमहरू

प्रयोगकर्ताहरूलाई एकीकृत CM क्लस्टरमा आउटबाउन्ड कलहरू गर्न अनुमति दिन, तपाईंले आउटबाउन्ड नियमहरू कन्फिगर गर्नुपर्छ। Jabber जस्ता एकीकृत CM सँग दर्ता भएका अन्तिम बिन्दुहरूको डोमेन example.com हो। यस डोमेनका कलहरूलाई मानक SIP कलहरूको रूपमा एकीकृत CM कल प्रशोधन नोडहरूमा रुट गरिनुपर्छ। मुख्य सर्भर cucm-01.example.com हो, र अतिरिक्त cucm-02.example.com हो।

पहिलो नियमले क्लस्टर सर्भरहरू बीचको कलहरूको सरल राउटिङको वर्णन गर्दछ।

क्षेत्र डोमेनबाट स्थानीय "@" चिन्ह पछि बोलाइएको व्यक्तिको लागि कलरको SIP-URI मा प्रदर्शित हुने कुराको लागि जिम्मेवार छ। यदि हामीले यसलाई खाली छोड्यौं भने, "@" चिन्ह पछि त्यहाँ CUCM को IP ठेगाना हुनेछ जसबाट यो कल पास हुन्छ। यदि हामीले डोमेन निर्दिष्ट गर्छौं भने, "@" प्रतीक पछि त्यहाँ वास्तवमा डोमेन हुनेछ। फिर्ता कल गर्न सक्षम हुनको लागि यो आवश्यक छ, अन्यथा SIP-URI name@ip-address मार्फत कल फिर्ता गर्न सम्भव छैन।

संकेत गर्दा कल गर्नुहोस् डोमेनबाट स्थानीय


जब कल गर्नुहोस् होइन संकेत डोमेनबाट स्थानीय


बाहिर जाने कलहरूको लागि स्पष्ट रूपमा ईन्क्रिप्टेड वा अनइन्क्रिप्टेड निर्दिष्ट गर्न निश्चित हुनुहोस्, किनकि स्वत: प्यारामिटरसँग केहि काम गर्दैन।

रेकर्डिङ

भिडियो सम्मेलन रेकर्ड सर्भर द्वारा रेकर्ड गरिएको छ। रेकर्डर ठ्याक्कै सिस्को मीटिंग सर्भर जस्तै हो। रेकर्डरलाई कुनै पनि इजाजतपत्रको स्थापना आवश्यक पर्दैन। कलब्रिज सेवाहरू चलाउने सर्भरहरूको लागि रेकर्डिङ इजाजतपत्रहरू आवश्यक छन्, अर्थात्। रेकर्डिङ इजाजतपत्र आवश्यक छ र कलब्रिज कम्पोनेन्टमा लागू गरिनुपर्छ, र रेकर्डर चलिरहेको सर्भरमा होइन। रेकर्डरले एक्स्टेन्सिबल सन्देश र उपस्थिति प्रोटोकल (XMPP) क्लाइन्टको रूपमा व्यवहार गर्दछ, त्यसैले XMPP सर्भरलाई CallBridge होस्टिङ सर्भरमा सक्षम गरिएको हुनुपर्छ।

किनभने हामीसँग क्लस्टर छ र इजाजतपत्र क्लस्टरका सबै तीन सर्भरहरूमा "तानिएको" हुनुपर्छ। त्यसपछि क्लस्टरमा समावेश गरिएका सबै CMS सर्भरहरूको ए-इन्टरफेसहरूको MAC ठेगानाहरू जोड्ने इजाजतपत्रहरूमा तपाईंको व्यक्तिगत खातामा मात्र।

र यो तस्विर हो जुन क्लस्टरमा प्रत्येक सर्भरमा हुनुपर्छ

सामान्यतया, रेकर्डर राख्नको लागि धेरै परिदृश्यहरू छन्, तर हामी यसमा टाँसिनेछौं:


रेकर्डर सेट अप गर्नु अघि, तपाईंले भिडियो सम्मेलनहरू वास्तवमा रेकर्ड गरिने ठाउँ तयार गर्न आवश्यक छ। वास्तवमा यहाँ लिङ्क, कसरी सबै रेकर्डिङ सेट अप गर्ने। म महत्त्वपूर्ण बिन्दु र विवरणहरूमा फोकस गर्छु:

1. क्लस्टरको पहिलो सर्भरबाट प्रमाणपत्र स्लिप गर्नु राम्रो हुन्छ।
2. "रेकर्डर अनुपलब्ध" त्रुटि हुन सक्छ किनभने गलत प्रमाणपत्र रेकर्डर ट्रस्टमा निर्दिष्ट गरिएको छ।
3. यदि रेकर्डिङका लागि निर्दिष्ट गरिएको NFS डाइरेक्टरी रूट डाइरेक्टरी होइन भने लेखनले काम नगर्न सक्छ।

कहिलेकाहीँ त्यहाँ स्वचालित रूपमा एक विशिष्ट प्रयोगकर्ता वा ठाउँको सम्मेलन रेकर्ड गर्न आवश्यक छ।

यसको लागि, दुई कल प्रोफाइलहरू सिर्जना गरिएका छन्:
रेकर्डिङ अक्षम संग


र स्वचालित रेकर्डिङ प्रकार्य संग


अर्को, हामी इच्छित ठाउँमा स्वचालित रेकर्डिङ प्रकार्यको साथ कल प्रोफाइल "संलग्न" गर्छौं।


CMS मा यो स्थापित छ कि यदि कलप्रोफाइल कुनै स्पेस वा स्पेसमा स्पष्ट रूपमा बाँधिएको छ भने, यो कलप्रोफाइलले यी विशिष्ट स्पेसहरूको सम्बन्धमा मात्र काम गर्दछ। र यदि कलप्रोफाइल कुनै स्पेसमा बाँधिएको छैन भने, पूर्वनिर्धारित रूपमा यो ती स्पेसहरूमा लागू हुन्छ जसमा कुनै कलप्रोफाइल स्पष्ट रूपमा बाँधिएको छैन।

अर्को पटक म संगठनको आन्तरिक नेटवर्क बाहिर CMS कसरी पहुँच गरिन्छ भनेर वर्णन गर्ने प्रयास गर्नेछु।

स्रोतहरू:

• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-5/Cisco-Meeting-Server-2-5-Single-Combined-Server-Deployment.pdf
• www.cisco.com/c/en/us/support/docs/conferencing/meeting-server/202722-Configure-Recorder-in-CMS-Acano-Call-Bri.html
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-3/Cisco-Meeting-Server-MMP-Command-Reference-2-3.pdf
• www.cisco.com/c/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Reference_Guides/Version-2-5/Cisco-Meeting-Server-API-Reference-Guide-2-4-and-later। pdf

स्रोत: www.habr.com