सिस्को मीटिंग सर्व्हर 2.5.2. व्हिडिओ कॉन्फरन्स रेकॉर्डिंग फंक्शनसह स्केलेबल आणि लवचिक मोडमध्ये क्लस्टर

या अंकात मी फेलओव्हर क्लस्टर मोडमध्ये सीएमएस सर्व्हर सेट करण्याच्या काही गुंतागुंत दाखवतो आणि स्पष्ट करतो.


सिद्धांतसर्वसाधारणपणे, तीन प्रकारचे CMS सर्व्हर उपयोजन आहेत:

• एकल एकत्रित(एकल एकत्रित), i.e. हा एक सर्व्हर आहे ज्यावर सर्व आवश्यक सेवा चालू आहेत. बर्‍याच प्रकरणांमध्ये, या प्रकारची तैनाती केवळ अंतर्गत क्लायंट प्रवेशासाठी आणि लहान वातावरणात योग्य असते जेथे एकाच सर्व्हरची स्केलेबिलिटी आणि रिडंडंसी मर्यादा ही गंभीर समस्या नसतात, किंवा सीएमएस केवळ विशिष्ट कार्ये करते, जसे की तदर्थ सिस्को UCM वर परिषद.

  कामाची अंदाजे योजना:
  

• सिंगल स्प्लिट(सिंगल स्प्लिट) बाह्य प्रवेशासाठी वेगळा सर्व्हर जोडून मागील उपयोजन प्रकार वाढवते. लेगसी डिप्लॉयमेंटमध्ये, याचा अर्थ असा होतो की डिमिलिटराइज्ड नेटवर्क सेगमेंट (DMZ) मध्ये CMS सर्व्हर तैनात करणे जेथे बाह्य क्लायंट त्यात प्रवेश करू शकतात आणि नेटवर्क कोरमध्ये एक CMS सर्व्हर जेथे अंतर्गत क्लायंट CMS मध्ये प्रवेश करू शकतात. हे विशिष्ट उपयोजन मॉडेल आता तथाकथित प्रकाराद्वारे बदलले जात आहे सिंगल एज, ज्यामध्ये सर्व्हर असतात सिस्को एक्सप्रेसवे, ज्यात एकतर समान फायरवॉल बायपास क्षमता आहेत किंवा असतील त्यामुळे क्लायंटला समर्पित एज सीएमएस सर्व्हर जोडण्याची आवश्यकता नाही.

  कामाची अंदाजे योजना:
  

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

उपयोजनाकडे जाण्यापूर्वी, तुम्हाला काही मूलभूत गोष्टी समजून घेणे आवश्यक आहे, म्हणजे

मुख्य CMS सॉफ्टवेअर घटक:

• डेटाबेस: तुम्हाला काही कॉन्फिगरेशन एकत्र करण्याची अनुमती देते, जसे की डायल प्लॅन, वापरकर्ता जागा आणि वापरकर्ते स्वतः. केवळ उच्च उपलब्धतेसाठी (सिंगल मास्टर) क्लस्टरिंगचे समर्थन करते.
• ब्रिजला कॉल करा: ऑडिओ आणि व्हिडिओ कॉन्फरन्सिंगसाठी एक सेवा जी कॉल आणि मल्टीमीडिया प्रक्रियांचे व्यवस्थापन आणि प्रक्रिया यावर पूर्ण नियंत्रण प्रदान करते. उच्च उपलब्धता आणि स्केलेबिलिटीसाठी क्लस्टरिंगला समर्थन देते.
• XMPP सर्व्हर: सिस्को मीटिंग ऍप्लिकेशन आणि/किंवा WebRTC वापरून क्लायंटच्या नोंदणी आणि प्रमाणीकरणासाठी जबाबदाररिअल-टाइम संप्रेषण, किंवा फक्त ब्राउझरमध्ये), तसेच आंतरघटक सिग्नलिंग. केवळ उच्च उपलब्धतेसाठी क्लस्टर केले जाऊ शकते.
• वेब ब्रिज: WebRTC मध्ये क्लायंट प्रवेश प्रदान करते.
• लोडबॅलन्सर: सिंगल स्प्लिट मोडमध्ये सिस्को मीटिंग अॅप्ससाठी सिंगल कनेक्शन पॉइंट प्रदान करते. इनकमिंग कनेक्शनसाठी बाह्य इंटरफेस आणि पोर्ट ऐकतो. त्याचप्रमाणे, लोड बॅलन्सर XMPP सर्व्हरवरून येणारे TLS कनेक्शन स्वीकारतो, ज्याद्वारे तो बाह्य क्लायंटकडून TCP कनेक्शन स्विच करू शकतो.
  आमच्या परिस्थितीत याची गरज भासणार नाही.
• सर्व्हर टर्न करा: परवानगी देणारे फायरवॉल बायपास तंत्रज्ञान प्रदान करते
  Cisco Meeting App किंवा SIP साधनांचा वापर करून बाह्य क्लायंट कनेक्ट करण्यासाठी फायरवॉल किंवा NAT च्या मागे आमचे CMS ठेवा. आमच्या परिस्थितीत याची गरज भासणार नाही.
• वेब प्रशासन: विशेष युनिफाइड सीएम कॉन्फरन्ससह प्रशासकीय इंटरफेस आणि API प्रवेश.

कॉन्फिगरेशन मोड

इतर सिस्को उत्पादनांच्या विपरीत, सिस्को मीटिंग सर्व्हर कोणत्याही प्रकारची तैनाती सामावून घेण्यासाठी तीन कॉन्फिगरेशन पद्धतींना समर्थन देते.

• कमांड लाइन (CLI): प्रारंभिक कॉन्फिगरेशन आणि प्रमाणपत्र कार्यांसाठी MMP म्हणून ओळखला जाणारा कमांड लाइन इंटरफेस.
• वेब प्रशासक: प्रामुख्याने कॉलब्रिज संबंधित कॉन्फिगरेशनसाठी, विशेषत: एकल नॉन-क्लस्टर सर्व्हर सेट करताना.
• आरईएसटी API: सर्वात जटिल कॉन्फिगरेशन कार्ये आणि क्लस्टर डेटाबेस संबंधित कार्यांसाठी वापरले जाते.

वरील व्यतिरिक्त, प्रोटोकॉल वापरला जातो SFTP फाइल्स हस्तांतरित करण्यासाठी—सामान्यतः परवाने, प्रमाणपत्रे किंवा लॉग—सीएमएस सर्व्हरवर आणि त्यावरून.

सिस्कोच्या उपयोजन मार्गदर्शकांमध्ये हे पांढर्‍या आणि इंग्रजीमध्ये लिहिलेले आहे की क्लस्टर तैनात करणे आवश्यक आहे किमान तीन डेटाबेसच्या संदर्भात सर्व्हर (नोड्स). कारण नवीन डेटाबेस मास्टर निवडण्याची यंत्रणा केवळ विचित्र संख्येच्या नोड्ससह कार्य करेल आणि सर्वसाधारणपणे डेटाबेस मास्टरचे बहुतेक CMS सर्व्हर डेटाबेसशी कनेक्शन असते.

आणि सराव शो म्हणून, दोन सर्व्हर (नोड्स) खरोखर पुरेसे नाहीत. जेव्हा मास्टर रीबूट केला जातो तेव्हा निवड यंत्रणा कार्य करते, रीबूट केलेला सर्व्हर आणल्यानंतरच स्लेव्ह सर्व्हर मास्टर बनतो. तथापि, जर दोन सर्व्हरच्या क्लस्टरमध्ये मास्टर सर्व्हर अचानक बाहेर गेला, तर स्लेव्ह सर्व्हर मास्टर होणार नाही आणि जर स्लेव्ह बाहेर गेला तर उर्वरित मास्टर सर्व्हर गुलाम होईल.

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

तसेच त्याच उपयोजन मार्गदर्शकामध्ये एक XMPP सर्व्हर असलेले क्लस्टर प्रदर्शित केले आहे.

आणि वरील गोष्टी विचारात घेतल्यास, हे का स्पष्ट होते: ते कार्य करते कारण ते फेलओव्हर मोडमध्ये आहे.

आमच्या बाबतीत, XMPP सर्व्हर सर्व तीन नोड्सवर उपस्थित असेल.

असे गृहीत धरले जाते की आमचे तीनही सर्व्हर चालू आहेत.

DNS रेकॉर्ड

तुम्ही सर्व्हर सेट करणे सुरू करण्यापूर्वी, तुम्हाला DNS रेकॉर्ड तयार करणे आवश्यक आहे А и एसआरव्ही प्रकार:

कृपया लक्षात घ्या की आमच्या DNS रेकॉर्डमध्ये example.com आणि दोन डोमेन आहेत conf.example.com. Example.com हे एक डोमेन आहे जे सर्व Cisco युनिफाइड कम्युनिकेशन मॅनेजर सदस्य त्यांच्या URI साठी वापरू शकतात, जे बहुधा तुमच्या इन्फ्रास्ट्रक्चरमध्ये उपस्थित आहे किंवा उपस्थित राहण्याची शक्यता आहे. किंवा example.com त्याच डोमेनशी जुळते जे वापरकर्ते त्यांच्या ईमेल पत्त्यांसाठी वापरतात. किंवा तुमच्या लॅपटॉपवरील जॅबर क्लायंटचा URI असू शकतो [ईमेल संरक्षित]. डोमेन conf.example.com हे डोमेन आहे जे सिस्को मीटिंग सर्व्हर वापरकर्त्यांसाठी कॉन्फिगर केले जाईल. सिस्को मीटिंग सर्व्हरचे डोमेन असेल conf.example.com, त्यामुळे त्याच जॅबर वापरकर्त्यासाठी, सिस्को मीटिंग सर्व्हरमध्ये लॉग इन करण्यासाठी user@ URI वापरणे आवश्यक आहे.conf.example.com.

मूलभूत कॉन्फिगरेशन

खाली वर्णन केलेल्या सर्व सेटिंग्ज एका सर्व्हरवर दाखवल्या आहेत, परंतु त्या क्लस्टरमधील प्रत्येक सर्व्हरवर केल्या पाहिजेत.

क्यूओएस

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

आम्ही सीएमएसमध्ये डीएनएस सर्व्हर जोडतो जसे की:

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. डेटाबेससाठी प्रमाणपत्रे (“सर्व्हर” आणि “क्लायंट”) आणि .की विस्तारासह फायली, जे “सर्व्हर” आणि “क्लायंट” डेटाबेस प्रमाणपत्रांसाठी विनंती तयार करताना व्युत्पन्न केले गेले होते. या फायली सर्व सर्व्हरवर समान असणे आवश्यक आहे.
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>

जेथे ip पत्ता 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 listen a

आणि कमांडसह सेवा रीस्टार्ट करा:

callbridge restart

आता आम्ही आमचे कॉल ब्रिज कॉन्फिगर केले आहेत, आम्ही कॉल ब्रिज क्लस्टरिंग कॉन्फिगर करू शकतो. कॉल ब्रिज क्लस्टरिंग डेटाबेस किंवा XMPP क्लस्टरिंगपेक्षा वेगळे आहे. कॉल ब्रिज क्लस्टर 2 ते 8 नोड्सपर्यंत कोणत्याही निर्बंधांशिवाय समर्थन देऊ शकतात. हे केवळ रिडंडंसीच नाही तर लोड बॅलन्सिंग देखील प्रदान करते जेणेकरून बुद्धिमान कॉल वितरण वापरून कॉल ब्रिज सर्व्हरवर कॉन्फरन्स सक्रियपणे वितरित केल्या जाऊ शकतात. CMS मध्ये अतिरिक्त वैशिष्ट्ये, कॉल ब्रिज गट आणि संबंधित वैशिष्ट्ये आहेत जी पुढील व्यवस्थापनासाठी वापरली जाऊ शकतात.

कॉल ब्रिज क्लस्टरिंग हे प्रामुख्याने वेब अॅडमिन इंटरफेसद्वारे कॉन्फिगर केले जाते
खाली वर्णन केलेली प्रक्रिया क्लस्टरमधील प्रत्येक सर्व्हरवर केली जाणे आवश्यक आहे.
त्यामुळे

1. वेबवरून कॉन्फिगरेशन > क्लस्टरवर जा.
२.इन् कॉल ब्रिज ओळख एक अद्वितीय नाव म्हणून, सर्व्हरच्या नावाशी संबंधित कॉलब्रिज[01,02,03] प्रविष्ट करा. ही नावे अनियंत्रित आहेत, परंतु या क्लस्टरसाठी अद्वितीय असणे आवश्यक आहे. ते वर्णनात्मक स्वरूपाचे आहेत कारण ते सूचित करतात की ते सर्व्हर अभिज्ञापक आहेत [01,02,03].
3.B क्लस्टर केलेले कॉल ब्रिज क्लस्टरमध्ये आमच्या सर्व्हरचे वेब प्रशासक URL प्रविष्ट करा, CMS[०१,०२,०३].example.com:01,02,03, पत्ता फील्डमध्ये. पोर्ट निर्दिष्ट करण्याचे सुनिश्चित करा. तुम्ही पीअर लिंक SIP डोमेन रिकामे सोडू शकता.
4. प्रत्येक सर्व्हरच्या कॉलब्रिज ट्रस्टमध्ये एक प्रमाणपत्र जोडा, ज्याच्या फाइलमध्ये आमच्या सर्व्हरची सर्व प्रमाणपत्रे आहेत, जी आम्ही या फाइलमध्ये अगदी सुरुवातीला विलीन केली, जसे की:

callbridge trust cluster <trusted cluster certificate bundle>

आणि कमांडसह सेवा रीस्टार्ट करा:

callbridge restart

परिणामी, प्रत्येक सर्व्हरवर तुम्हाला हे चित्र मिळाले पाहिजे:

XMPP क्लस्टर

CMS मधील XMPP सेवा CMA WebRTC वेब क्लायंटसह सिस्को मीटिंग अॅप्स (CMA) साठी सर्व नोंदणी आणि प्रमाणीकरण हाताळण्यासाठी वापरली जाते. कॉल ब्रिज देखील प्रमाणीकरणाच्या उद्देशाने XMPP क्लायंट म्हणून कार्य करतो आणि म्हणून इतर क्लायंटप्रमाणे कॉन्फिगर केले जाणे आवश्यक आहे. XMPP फॉल्ट टॉलरन्स हे वैशिष्ट्य आहे जे उत्पादन वातावरणात आवृत्ती 2.1 पासून समर्थित आहे

खाली वर्णन केलेल्या आज्ञा योग्य प्रमाणपत्रांसह प्रत्येक सर्व्हरवर कार्यान्वित केल्या पाहिजेत.
म्हणून:

आम्‍ही XMPP सेवेशी सर्टिफिकेट संबद्ध करतो जसे की:

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

नंतर कमांडसह ऐकण्याचे इंटरफेस परिभाषित करा:

xmpp listen a

XMPP सेवेसाठी एक अद्वितीय डोमेन आवश्यक आहे. हे वापरकर्त्यांसाठी लॉगिन आहे. दुसऱ्या शब्दांत, जेव्हा वापरकर्ता CMA अॅप वापरून लॉग इन करण्याचा प्रयत्न करतो (किंवा WebRTC क्लायंटद्वारे), तेव्हा ते userID@logindomain एंटर करतात. आमच्या बाबतीत ते userid@ असेलconf.example.com. ते फक्त example.com का नाही? आमच्या विशिष्ट उपयोजनामध्ये, आम्ही आमचे युनिफाइड सीएम डोमेन निवडले जे जॅबर वापरकर्ते युनिफाइड सीएममध्ये example.com म्हणून वापरतील, म्हणून आम्हाला सीएमएस वापरकर्त्यांसाठी एसआयपी डोमेनद्वारे सीएमएसवर आणि वरून कॉल करण्यासाठी वेगळ्या डोमेनची आवश्यकता आहे.

कमांड वापरून XMPP डोमेन सेट करा:

xmpp domain <domain>

आणि कमांडसह XMPP सेवा सक्षम करा:

xmpp enable

XMPP सेवेमध्ये, तुम्ही प्रत्येक कॉल ब्रिजसाठी क्रेडेंशियल तयार करणे आवश्यक आहे जे XMPP सेवेसह नोंदणी करताना वापरले जातील. ही नावे अनियंत्रित आहेत (आणि तुम्ही कॉल ब्रिज क्लस्टरिंगसाठी कॉन्फिगर केलेल्या अद्वितीय नावांशी संबंधित नाहीत). तुम्ही एका XMPP सर्व्हरवर तीन कॉल ब्रिज जोडणे आवश्यक आहे आणि नंतर क्लस्टरमधील इतर XMPP सर्व्हरवर ती क्रेडेन्शियल्स प्रविष्ट करणे आवश्यक आहे कारण हे कॉन्फिगरेशन क्लस्टर डेटाबेसमध्ये बसत नाही. नंतर आम्ही प्रत्येक कॉल ब्रिज हे नाव वापरण्यासाठी कॉन्फिगर करू आणि XMPP सेवेसह नोंदणी करण्यासाठी गुप्त ठेवू.

आता आम्हाला पहिल्या सर्व्हरवर तीन कॉल ब्रिज callbridge01, callbridge02 आणि callbridge03 सह XMPP सेवा कॉन्फिगर करायची आहे. प्रत्येक खात्याला यादृच्छिक संकेतशब्द नियुक्त केले जातील. या 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 ला कॉलब्रिज कनेक्ट करण्यासाठी IP पत्ते प्रत्येक सर्व्हरवर भिन्न असू शकतात, रेकॉर्ड विनंतीवर कोणती मूल्ये परत केली जातात यावर ते अवलंबून असते _xmpp-component._tcp.conf.example.com callbridge, जे यामधून दिलेल्या DNS रेकॉर्डसाठी प्राधान्य सेटिंग्जवर अवलंबून असते.

पुढे, कॉल वधू सेवा XMPP सेवेशी यशस्वीरित्या कनेक्ट झाली आहे की नाही हे सत्यापित करण्यासाठी स्थिती > सामान्य वर जा.

वेब ब्रिज

क्लस्टरमधील प्रत्येक सर्व्हरवर, कमांडसह वेब ब्रिज सेवा सक्षम करा:

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 मीडिया पोर्ट वापरेल. हे साहजिकच संसाधनांचा अकार्यक्षम वापर आहे. याव्यतिरिक्त, जेव्हा कॉल ब्रिज खरोखर ओव्हरलोड होतो, तेव्हा डीफॉल्ट यंत्रणा कॉल स्वीकारणे सुरू ठेवते आणि त्या कॉल ब्रिजच्या सर्व सदस्यांना कमी दर्जाची सेवा प्रदान करते.

कॉल ब्रिज ग्रुप वैशिष्ट्य वापरून या समस्या सोडवल्या जातात. हे वैशिष्ट्य सिस्को मीटिंग सर्व्हर सॉफ्टवेअरच्या आवृत्ती 2.1 मध्ये सादर करण्यात आले होते आणि WebRTC सहभागींसह इनबाउंड आणि आउटबाउंड सिस्को मीटिंग अॅप (CMA) कॉल्ससाठी लोड बॅलन्सिंगला समर्थन देण्यासाठी विस्तारित केले गेले आहे.

रीकनेक्शन समस्येचे निराकरण करण्यासाठी, प्रत्येक कॉल ब्रिजसाठी तीन कॉन्फिगर करण्यायोग्य लोड मर्यादा सुरू केल्या आहेत:

लोडलिमिट — विशिष्ट कॉल ब्रिजसाठी हा कमाल संख्यात्मक भार आहे. प्रत्येक प्लॅटफॉर्मवर शिफारस केलेली लोड मर्यादा आहे, जसे की CMS96000 साठी 1000 आणि व्हर्च्युअल मशीनसाठी 1.25 GHz प्रति vCPU. सहभागीच्या रिझोल्यूशन आणि फ्रेम रेटवर अवलंबून भिन्न कॉल्स विशिष्ट प्रमाणात संसाधने वापरतात.
NewConferenceLoadLimitBasisPoints (डिफॉल्ट 50% लोडलिमिट) - सर्व्हर लोड मर्यादा सेट करते, त्यानंतर नवीन परिषद नाकारल्या जातात.
विद्यमान कॉन्फरन्स लोडलिमिट बेस पॉइंट्स (डीफॉल्ट 80% loadLimit) - सर्व्हर लोड मूल्य ज्यानंतर विद्यमान कॉन्फरन्समध्ये सामील होणारे सहभागी नाकारले जातील.

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

हे पॅरामीटर्स येथे कॉन्फिगर केले आहेत: 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
• नाव मॅपिंग
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

गुणधर्मांचे वर्णनJID CMS मध्ये वापरकर्त्याच्या लॉगिन आयडीचे प्रतिनिधित्व करते. हा Microsoft Active Directory LDAP सर्व्हर असल्याने, CMS JID LDAP मधील sAMAccountName वर मॅप करते, जो मूलत: वापरकर्त्याचा Active Directory login ID असतो. हे देखील लक्षात घ्या की तुम्ही sAMAccountName घ्या आणि त्याच्या शेवटी conf.pod6.cms.lab डोमेन जोडा कारण हे लॉगिन आहे जे तुमचे वापरकर्ते CMS मध्ये लॉग इन करण्यासाठी वापरतील.

नाव मॅपिंग वापरकर्त्याच्या CMS नाव फील्डशी Active Directory displayName फील्डमध्ये समाविष्ट असलेल्या गोष्टीशी जुळते.

coSpaceNameMapping displayName फील्डवर आधारित CMS स्पेस नाव तयार करते. ही विशेषता, coSpaceUriMapping विशेषतासह, प्रत्येक वापरकर्त्यासाठी जागा तयार करण्यासाठी आवश्यक आहे.

coSpaceUriMapping वापरकर्त्याच्या वैयक्तिक जागेशी संबंधित URI चा वापरकर्ता भाग परिभाषित करते. काही डोमेन स्पेसमध्ये डायल करण्यासाठी कॉन्फिगर केले जाऊ शकतात. वापरकर्ता भाग या डोमेनपैकी एकासाठी या फील्डशी जुळत असल्यास, कॉल त्या वापरकर्त्याच्या जागेवर निर्देशित केला जाईल.

coSpaceSecondaryUriMapping अंतराळात पोहोचण्यासाठी दुसरा URI परिभाषित करते. coSpaceUriMapping पॅरामीटरमध्ये परिभाषित केलेल्या अल्फान्यूमेरिक यूआरआयला पर्याय म्हणून आयात केलेल्या वापरकर्त्याच्या जागेवर कॉल रूट करण्यासाठी अंकीय उपनाव जोडण्यासाठी याचा वापर केला जाऊ शकतो.

LDAP सर्व्हर आणि LDAP मॅपिंग कॉन्फिगर केले आहे. आता तुम्हाला LDAP स्रोत तयार करून त्यांना एकत्र जोडणे आवश्यक आहे.

प्रवेश करण्यासाठी URL वापरणे cms01.example.com:445/api/v1/ldapSource LDAP सोर्स ऑब्जेक्ट तयार करतो, पॅरामीटर्स निर्दिष्ट करतो जसे की:

• सर्व्हर
• मॅपिंग
• baseDn
• फिल्टर

आता LDAP कॉन्फिगरेशन पूर्ण झाले आहे, तुम्ही मॅन्युअल सिंक्रोनायझेशन ऑपरेशन करू शकता.

आम्ही हे प्रत्येक सर्व्हरच्या वेब इंटरफेसमध्ये क्लिक करून करतो आता समक्रमित करा विभाग चालू निर्देशिका


किंवा कमांडसह API द्वारे पोस्ट प्रवेश करण्यासाठी URL वापरणे cms01.example.com:445/api/v1/ldapSyncs

तदर्थ परिषद

हे काय आहे?पारंपारिक संकल्पनेत, कॉन्फरन्स म्हणजे जेव्हा दोन सहभागी एकमेकांशी बोलत असतात आणि सहभागींपैकी एक (युनिफाइड सीएमकडे नोंदणीकृत डिव्हाइस वापरून) "कॉन्फरन्स" बटण दाबतो, दुसऱ्या व्यक्तीला कॉल करतो आणि त्या तृतीय पक्षाशी बोलल्यानंतर , त्रिपक्षीय परिषदेतील सर्व सहभागींना सामील होण्यासाठी पुन्हा "कॉन्फरन्स" बटण दाबते.

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

याचा अर्थ युनिफाइड सीएमने कॉल सुरू ठेवण्यासाठी API क्रेडेंशियल्स आणि सेवेचा वेबअॅडमिन पत्ता/पोर्ट तसेच SIP ट्रंक थेट CMS सर्व्हरवर कॉन्फिगर करणे आवश्यक आहे.

आवश्यक असल्यास, CUCM गतिशीलपणे CMS मध्ये एक जागा तयार करू शकते जेणेकरून प्रत्येक कॉल CMS पर्यंत पोहोचू शकेल आणि स्पेससाठी असलेल्या इनकमिंग कॉल नियमाशी जुळेल.

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

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


खोड:


प्रत्येक खोड एकसारखे दिसते:




कॉन्फरन्स ब्रिज


प्रत्येक कॉन्फरन्स ब्रिज सारखा दिसतो:


मार्ग गट


मार्ग सूची


मीडिया संसाधन गट


मीडिया संसाधन गट सूची

कॉल नियम

युनिफाइड सीएम किंवा एक्सप्रेसवे सारख्या अधिक प्रगत कॉल मॅनेजमेंट सिस्टमच्या विपरीत, सीएमएस नवीन कॉलसाठी फक्त SIP रिक्वेस्ट-यूआरआय फील्डमध्ये डोमेन शोधते. म्हणून जर SIP INVITE sip साठी असेल तर: [ईमेल संरक्षित]CMS फक्त domain.com ची काळजी घेते. कॉल कुठे रूट करायचा हे ठरवण्यासाठी CMS या नियमांचे पालन करते:

1. CMS प्रथम इनकमिंग कॉल नियमांमध्ये कॉन्फिगर केलेल्या डोमेनशी SIP डोमेन जुळवण्याचा प्रयत्न करते. हे कॉल नंतर (“लक्ष्यित”) स्पेसेस किंवा विशिष्ट वापरकर्ते, अंतर्गत IVR किंवा थेट एकीकृत Microsoft Lync/Skype for Business (S4B) गंतव्यस्थानांवर पाठवले जाऊ शकतात.
2. इनकमिंग कॉल नियमांमध्ये जुळत नसल्यास, CMS कॉल फॉरवर्डिंग टेबलमध्ये कॉन्फिगर केलेल्या डोमेनशी जुळण्याचा प्रयत्न करेल. जुळत असल्यास, नियम स्पष्टपणे कॉल नाकारू शकतो किंवा कॉल फॉरवर्ड करू शकतो. यावेळी, CMS डोमेन पुन्हा लिहू शकते, जे कधीकधी Lync डोमेन कॉल करण्यासाठी उपयुक्त असते. तुम्ही थ्रो पास करणे देखील निवडू शकता, याचा अर्थ कोणत्याही फील्डमध्ये आणखी सुधारणा केली जाणार नाही किंवा अंतर्गत CMS डायल योजना वापरा. कॉल फॉरवर्डिंग नियमांमध्ये जुळत नसल्यास, डीफॉल्ट कॉल नाकारणे आहे. लक्षात ठेवा की CMS मध्ये, कॉल "फॉरवर्ड केलेला" असला तरी, मीडिया अजूनही CMS ला बांधील आहे, याचा अर्थ ते सिग्नलिंग आणि मीडिया ट्रॅफिक मार्गावर असेल.
त्यानंतर केवळ फॉरवर्ड केलेले कॉल आउटगोइंग कॉल नियमांच्या अधीन असतात. या सेटिंग्ज कॉल्स पाठवल्या जाणार्‍या गंतव्यस्थान, ट्रंक प्रकार (मग तो नवीन Lync कॉल असो किंवा मानक SIP कॉल असो) आणि कॉल फॉरवर्डिंग नियमामध्ये ट्रान्सफर न निवडल्यास करता येणारी कोणतीही रूपांतरणे निर्धारित करतात.

अॅड-हॉक कॉन्फरन्स दरम्यान काय होते याचा वास्तविक लॉग येथे आहे

स्क्रीनशॉट खराबपणे दर्शवितो (मला ते चांगले कसे करावे हे माहित नाही), म्हणून मी लॉग याप्रमाणे लिहीन:

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

तदर्थ परिषद स्वतः:


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

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


आउटगोइंग कॉल नियम

वापरकर्त्यांना युनिफाइड CM क्लस्टरवर आउटबाउंड कॉल करण्याची परवानगी देण्यासाठी, तुम्ही आउटबाउंड नियम कॉन्फिगर करणे आवश्यक आहे. युनिफाइड सीएमकडे नोंदणीकृत एंडपॉइंट्सचे डोमेन, जसे की जॅबर, example.com आहे. या डोमेनवरील कॉल्स युनिफाइड सीएम कॉल प्रोसेसिंग नोड्सवर मानक SIP कॉल्स म्हणून रूट केले जावेत. मुख्य सर्व्हर cucm-01.example.com आहे, आणि अतिरिक्त एक cucm-02.example.com आहे.

पहिला नियम क्लस्टर सर्व्हरमधील कॉलच्या सर्वात सोप्या राउटिंगचे वर्णन करतो.

फील्ड डोमेनवरून स्थानिक कॉलरच्या SIP-URI मध्ये “@” चिन्हानंतर कॉल केलेल्या व्यक्तीसाठी काय प्रदर्शित केले जाईल यासाठी जबाबदार आहे. जर आपण ते रिकामे सोडले, तर “@” चिन्हानंतर CUCM चा IP पत्ता असेल ज्यातून हा कॉल जातो. जर आम्ही डोमेन निर्दिष्ट केले, तर “@” चिन्हानंतर प्रत्यक्षात एक डोमेन असेल. परत कॉल करण्यास सक्षम होण्यासाठी हे आवश्यक आहे, अन्यथा SIP-URI name@ip-address द्वारे परत कॉल करणे शक्य होणार नाही.

निर्दिष्ट केल्यावर कॉल करा डोमेनवरून स्थानिक


तेव्हा कॉल करा नाही असे सूचित डोमेनवरून स्थानिक


आउटगोइंग कॉलसाठी एनक्रिप्टेड किंवा अनएनक्रिप्टेड स्पष्टपणे निर्दिष्ट केल्याची खात्री करा, कारण ऑटो पॅरामीटरसह काहीही कार्य करत नाही.

रेकॉर्डिंग

रेकॉर्ड सर्व्हरद्वारे व्हिडिओ कॉन्फरन्स रेकॉर्ड केल्या जातात. रेकॉर्डर अगदी सिस्को मीटिंग सर्व्हर सारखाच आहे. रेकॉर्डरला कोणत्याही परवान्याची स्थापना आवश्यक नाही. कॉलब्रिज सेवा चालवणाऱ्या सर्व्हरसाठी रेकॉर्डिंग परवाने आवश्यक आहेत, उदा. रेकॉर्डिंग परवाना आवश्यक आहे आणि तो कॉलब्रिज घटकावर लागू करणे आवश्यक आहे, आणि रेकॉर्डरवर चालणार्‍या सर्व्हरवर नाही. रेकॉर्डर एक्स्टेंसिबल मेसेजिंग आणि प्रेझेन्स प्रोटोकॉल (XMPP) क्लायंट म्हणून वागतो, म्हणून XMPP सर्व्हर कॉलब्रिज होस्टिंग सर्व्हरवर सक्षम करणे आवश्यक आहे.

कारण आमच्याकडे क्लस्टर आहे आणि परवाना क्लस्टरमधील सर्व तीन सर्व्हरवर "विस्तारित" करणे आवश्यक आहे. मग फक्त तुमच्या वैयक्तिक खात्यात आम्ही क्लस्टरमध्ये समाविष्ट असलेल्या सर्व 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-आणि-नंतर. pdf

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