سسڪو ميٽنگ سرور 2.5.2. وڊيو ڪانفرنس رڪارڊنگ سان گڏ اسڪيلبل ۽ لچڪدار موڊ ۾ ڪلستر

هن مسئلي ۾ آئون ڏيکاريندس ۽ وضاحت ڪندس ڪجهه پيچيدگين کي سيٽ ڪرڻ جي CMS سرور کي ناڪامي ڪلستر موڊ ۾.


اصولعام طور تي، سي ايم ايس سرور جي ترتيب جا ٽي قسم آهن:

• اڪيلو گڏيل(اڪيلو گڏيل)، يعني. ھي ھڪڙو سرور آھي جنھن تي سڀ ضروري خدمتون ھلنديون آھن. اڪثر صورتن ۾، هن قسم جي تعیناتي صرف اندروني ڪلائنٽ جي رسائي لاءِ موزون آهي ۽ ننڍڙن ماحولن ۾ جتي هڪ سرور جي اسپيبليبلٽي ۽ بيڪارگي جون حدون هڪ نازڪ مسئلو نه آهن، يا اهڙين حالتن ۾ جتي CMS صرف ڪجهه ڪم سرانجام ڏئي ٿو، جهڙوڪ ايڊهاڪ Cisco UCM تي ڪانفرنس.

  ڪم جي لڳ ڀڳ منصوبي:
  

• اڪيلو تقسيم(سنگل اسپلٽ) خارجي رسائي لاءِ الڳ سرور شامل ڪندي پوئين ڊيپلائيمينٽ جي قسم کي وڌايو. وراثت جي ترتيبن ۾، هن جو مطلب آهي هڪ سي ايم ايس سرور کي هڪ غير ملڪي نيٽ ورڪ سيڪشن (DMZ) ۾ ترتيب ڏيڻ جتي خارجي ڪلائنٽ ان تائين رسائي ڪري سگھن ٿا، ۽ نيٽ ورڪ ڪور ۾ هڪ CMS سرور جتي اندروني ڪلائنٽ CMS تائين رسائي ڪري سگھن ٿا. هي خاص ترتيب ڏيڻ وارو نمونو هاڻي نام نهاد قسم طرفان ختم ڪيو پيو وڃي سنگل ڪنڊ، جيڪو سرورن تي مشتمل آهي Cisco ايڪسپريس وي، جنهن وٽ يا ته آهن يا هونديون ڪيتريون ئي ساڳيون فائر وال بائي پاس صلاحيتون، تنهن ڪري ڪلائنٽ کي هڪ وقف ٿيل ايج CMS سرور شامل ڪرڻ جي ضرورت ناهي.

  ڪم جي لڳ ڀڳ منصوبي:
  

• قابل ۽ لچڪدار(Scalable and Fault Tolerant) ھن قسم ۾ شامل آھي ھر جزو لاءِ بيڪار، سسٽم کي توھان جي ضرورتن سان ان جي وڌ ۾ وڌ گنجائش تائين وڌڻ جي اجازت ڏئي ٿي، جڏھن تہ ناڪاميءَ جي صورت ۾ بيڪارگي مهيا ڪري ٿي. اهو پڻ استعمال ڪري ٿو سنگل ايج تصور محفوظ خارجي رسائي فراهم ڪرڻ لاءِ. هي اهو قسم آهي جنهن کي اسين هن قسط ۾ ڏسنداسين. جيڪڏهن اسان سمجھون ٿا ته هن قسم جي ڪلسٽر کي ڪيئن ٺهرايو وڃي، اسان نه رڳو ٻين قسمن جي ترتيبن کي سمجهي سگهنداسين، پر اسان اهو پڻ سمجهي سگهنداسين ته CMS سرورز جا ڪلسٽر ڪيئن ٺاهيا وڃن ته جيئن طلب ۾ امڪاني واڌ کي پورو ڪرڻ لاءِ.

مقرري تي اڳتي وڌڻ کان اڳ، توھان کي ڪجھ بنيادي شيون سمجھڻ جي ضرورت آھي، يعني

مکيه CMS سافٽ ويئر اجزاء:

• ڊيٽابيس: توهان کي ڪجهه ترتيبن کي گڏ ڪرڻ جي اجازت ڏئي ٿي، جهڙوڪ ڊائل پلان، يوزر اسپيس، ۽ استعمال ڪندڙ پاڻ. صرف اعلي دستيابي (اڪيلو ماسٽر) لاء ڪلسترنگ کي سپورٽ ڪري ٿو.
• ڪال برج: هڪ خدمت آڊيو ۽ وڊيو ڪانفرنسنگ لاءِ جيڪا مهيا ڪري ٿي مڪمل ڪنٽرول ڪالن ۽ ملٽي ميڊيا پروسيسنگ جي انتظام ۽ پروسيسنگ تي. اعلي دستيابي ۽ اسڪيلبلٽي لاء ڪلسترنگ کي سپورٽ ڪري ٿو.
• XMPP سرور: Cisco Meeting Application ۽/يا WebRTC استعمال ڪندي مراجعين جي رجسٽريشن ۽ تصديق جا ذميوارحقيقي وقت مواصلات، يا صرف برائوزر ۾), گڏو گڏ intercomponent سگنلنگ. صرف اعلي دستيابي لاء ڪلستر ٿي سگھي ٿو.
• ويب پل: WebRTC تائين ڪلائنٽ جي رسائي فراهم ڪري ٿي.
• لوڊ بيلنس ڪندڙسسڪو ميٽنگ ايپس لاءِ سنگل اسپلٽ موڊ ۾ هڪ واحد ڪنيڪشن پوائنٽ مهيا ڪري ٿي. ايندڙ ڪنيڪشن لاءِ ٻاهرين انٽرفيس ۽ بندرگاهن کي ٻڌي ٿو. ساڳئي طرح، لوڊ بيلنس قبول ڪري ٿو ايندڙ TLS ڪنيڪشن کي XMPP سرور کان، جنهن جي ذريعي اهو مٽائي سگھي ٿو TCP ڪنيڪشن کي ٻاهرين ڪلائنٽ کان.
  اسان جي منظرنامي ۾ ان جي ضرورت نه پوندي.
• ڦيرايو سرور: مهيا ڪري ٿو فائر وال بائي پاس ٽيڪنالاجي جيڪا اجازت ڏئي ٿي
  سسڪو ميٽنگ ايپ يا SIP ڊوائيسز استعمال ڪندي ٻاهرين گراهڪن کي ڳنڍڻ لاءِ اسان جي CMS کي فائر وال يا NAT جي پويان رکو. اسان جي منظرنامي ۾ ان جي ضرورت نه پوندي.
• ويب ايڊمنسٽريشن: انتظامي انٽرفيس ۽ API رسائي، بشمول خاص يونيفيڊ سي ايم ڪانفرنسن لاءِ.

ترتيب ڏيڻ جا طريقا

ٻين سسڪو پروڊڪٽس جي برعڪس، سسڪو ميٽنگ سرور ڪنهن به قسم جي ترتيب کي ترتيب ڏيڻ لاءِ ٽن ترتيبن جي طريقن کي سپورٽ ڪري ٿو.

• ڪمانڊ لائن (CLI): ڪمانڊ لائن انٽرفيس جيڪو MMP طور سڃاتو وڃي ٿو شروعاتي ترتيب ۽ سرٽيفڪيٽ ڪمن لاءِ.
• ويب ايڊمنسٽريٽر: بنيادي طور تي ڪال برج سان لاڳاپيل ترتيبن لاءِ، خاص طور تي جڏهن هڪ اڪيلو غير ڪلستر ٿيل سرور قائم ڪرڻ لاءِ.
• REST API: سڀ کان وڌيڪ پيچيده ترتيب واري ڪمن ۽ ڪلسٽر ٿيل ڊيٽابيس سان لاڳاپيل ڪمن لاء استعمال ٿيل.

مٿين کان علاوه، پروٽوڪول استعمال ڪيو ويندو آهي SFTP فائلن کي منتقل ڪرڻ لاءِ- عام طور تي لائسنس، سرٽيفڪيٽ، يا لاگس- ڏانهن ۽ CMS سرور کان.

سسڪو جي ترتيب واري هدايتن ۾ اهو اڇو ۽ انگريزي ۾ لکيل آهي ته ڪلستر کي ترتيب ڏيڻ جي ضرورت آهي گهٽ ۾ گهٽ ٽي سرورز (نوڊس) ڊيٽابيس جي حوالي سان. ڇاڪاڻ ته صرف نوڊس جي بي جوڙ تعداد سان نئين ڊيٽابيس ماسٽر کي چونڊڻ لاءِ ميکانيزم ڪم ڪندو، ۽ عام طور تي ڊيٽابيس ماسٽر جو تعلق اڪثر CMS سرور ڊيٽابيس سان هوندو آهي.

۽ جيئن مشق ڏيکاري ٿو، ٻه سرور (نوڊس) واقعي ڪافي نه آهن. سليڪشن ميڪانيزم ڪم ڪندو آهي جڏهن ماسٽر ريبوٽ ڪيو ويندو آهي، غلام سرور ماسٽر بڻجي ويندو آهي صرف ان کان پوءِ جڏهن ريبوٽ ٿيل سرور کي آندو ويندو آهي. تنهن هوندي به، جيڪڏهن ٻن سرورن جي ڪلستر ۾ ماسٽر سرور اوچتو ٻاهر نڪري وڃي، ته غلام سرور ماسٽر نه ٿيندو، ۽ جيڪڏهن غلام ٻاهر نڪري ويو ته باقي ماسٽر سرور غلام ٿي ويندو.

پر XMPP جي حوالي سان، اهو واقعي ضروري هوندو ته ٽن سرورن جي ڪلستر کي گڏ ڪرڻ، ڇاڪاڻ ته جيڪڏهن، مثال طور، توهان XMPP سروس کي ڪنهن هڪ سرور تي بند ڪيو جنهن ۾ XMMP ليڊر جي حيثيت ۾ آهي، ته پوءِ باقي سرور تي XMPP فالوور جي حيثيت ۾ رهندو ۽ ڪال برج ڪنيڪشن XMPP سان بند ٿي ويندا، ڇاڪاڻ ته ڪال برج خاص طور تي XMPP سان ليڊر اسٽيٽس سان ڳنڍي ٿو. ۽ اهو نازڪ آهي، ڇاڪاڻ ته ... هڪ ڪال به نه ٿيندي.

ساڳيءَ ترتيب ۾ پڻ ھدايت ڪئي وئي آھي ھڪڙو ڪلستر ھڪڙو XMPP سرور سان.

۽ مٿين حساب سان، اهو واضح ٿئي ٿو ته ڇو: اهو ڪم ڪري ٿو ڇو ته اهو ناڪامي موڊ ۾ آهي.

اسان جي حالت ۾، ايڪس ايم پي پي سرور سڀني ٽن نوڊس تي موجود هوندو.

اهو فرض ڪيو ويو آهي ته اسان جا ٽي سرور مٿي آهن.

DNS رڪارڊ

توھان کان پھريان سرور قائم ڪرڻ شروع ڪريو، توھان کي ٺاهڻو پوندو DNS ريڪارڊ А и ايس آر وي قسم:

مهرباني ڪري نوٽ ڪريو ته اسان جي DNS رڪارڊ ۾ ٻه ڊومين آهن example.com ۽ conf.example.com. Example.com ھڪڙو ڊومين آھي جنھن کي سڀ Cisco Unified Communication Manager سبسڪرائيبر پنھنجي URIs لاءِ استعمال ڪري سگھن ٿا، جيڪو گھڻو ڪري توھان جي انفراسٽرڪچر ۾ موجود آھي يا موجود ٿيڻ جو امڪان آھي. يا example.com ساڳي ڊومين سان ملندو آهي جيڪو صارف انهن جي اي ميل پتي لاءِ استعمال ڪندا آهن. يا توهان جي ليپ ٽاپ تي جابر ڪلائنٽ شايد URI هجي [ايميل محفوظ ٿيل]. ڊومين conf.example.com اهو ڊومين آهي جيڪو سسڪو ميٽنگ سرور استعمال ڪندڙن لاءِ ترتيب ڏنو ويندو. Cisco ميٽنگ سرور جو ڊومين هوندو confمثال طور.conf.example.com.

بنيادي تشڪيل

هيٺ بيان ڪيل سڀئي سيٽنگون هڪ سرور تي ڏيکاريل آهن، پر انهن کي ڪلستر ۾ هر سرور تي ڪرڻ جي ضرورت آهي.

ڪلو

جتان سي ايم ايس ٺاهي ٿي اصل وقت ٽريفڪ حساس دير ۽ پيڪٽ جي نقصان جي ڪري، اڪثر ڪيسن ۾ اها سفارش ڪئي وئي آهي ته خدمت جي معيار کي ترتيب ڏيو (QoS). هن کي حاصل ڪرڻ لاءِ، سي ايم ايس ٽيگنگ پيڪيٽس کي سپورٽ ڪري ٿي مختلف سروسز ڪوڊس (DSCPs) سان جيڪو اهو ٺاهي ٿو. جيتوڻيڪ DSCP جي بنياد تي ٽريفڪ جي ترجيحن جو دارومدار ان تي آهي ته ٽريفڪ توهان جي انفراسٽرڪچر جي نيٽ ورڪ حصن طرفان ڪيئن پروسيس ڪئي ويندي آهي، اسان جي صورت ۾ اسان پنهنجي CMS کي ترتيب ڏينداسين عام DSCP ترجيحات سان QoS بهترين عملن جي بنياد تي.

هر سرور تي اسين اهي حڪم داخل ڪنداسين

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 سرورز کي سي ايم ايس ۾ شامل ڪندا آھيون ھڪڙي حڪم سان:

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

اسان جي حالت ۾، ٻه اهڙا سرور آهن، تنهنڪري اتي ٻه ٽيمون هونديون.
اسان پڙتال ڪريو

نيٽ ورڪ انٽرفيس جي ٺاھ جوڙ

اسان انٽرفيس کي حڪم سان ترتيب ڏيون ٿا جهڙوڪ:

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

اسان پڙتال ڪريو

سرور جو نالو (ميزبان جو نالو)

اسان هڪ حڪم سان سرور جو نالو مقرر ڪيو جيئن:

hostname <name>

۽ اسان ريبوٽ.


هي بنيادي جوڙجڪ مڪمل ڪري ٿو.

سرٽيفڪيٽ

اصولCisco Meeting Server کي مختلف حصن جي وچ ۾ انڪريپٽ ٿيل ڪميونيڪيشن جي ضرورت آھي، ۽ نتيجي طور، X.509 سرٽيفڪيٽن جي ضرورت آھي سڀني سي ايم ايس ڊيپلائيمينٽن لاءِ. اهي انهي ڳالهه کي يقيني بڻائڻ ۾ مدد ڪن ٿيون ته خدمتون/سرور ٻين سرورز/خدمتن طرفان قابل اعتماد آهن.

هر خدمت کي هڪ سرٽيفڪيٽ جي ضرورت آهي، پر هر خدمت لاءِ الڳ سرٽيفڪيٽ ٺاهڻ مونجهارو ۽ غير ضروري پيچيدگيءَ جو سبب بڻجي سگهي ٿو. خوشقسمتيءَ سان، اسان ھڪ سرٽيفڪيٽ جي عوامي-پرائيويٽ ڪيئي جوڙو ٺاھي سگھون ٿا ۽ پوءِ انھن کي ڪيترن ئي خدمتن ۾ استعمال ڪري سگھون ٿا. اسان جي صورت ۾، ساڳيو سرٽيفڪيٽ ڪال برج، ايڪس ايم پي پي سرور، ويب برج ۽ ويب ايڊمنسٽريشن لاءِ استعمال ڪيو ويندو. اهڙيء طرح، توهان کي ڪلستر ۾ هر سرور لاء عوامي ۽ نجي سرٽيفڪيٽ چيڪن جو هڪ جوڙو ٺاهڻ جي ضرورت آهي.

ڊيٽابيس ڪلسٽرنگ، جيتوڻيڪ، ڪجهه خاص سرٽيفڪيٽ گهرجون آهن ۽ تنهن ڪري ان جي پنهنجي سرٽيفڪيٽن جي ضرورت آهي جيڪي ٻين خدمتن کان مختلف آهن. CMS هڪ سرور سرٽيفڪيٽ استعمال ڪري ٿو، جيڪو ٻين سرورز پاران استعمال ڪيل سرٽيفڪيٽن سان ملندڙ جلندڙ آهي، پر ڊيٽابيس ڪنيڪشن لاءِ استعمال ٿيل ڪلائنٽ سرٽيفڪيٽ پڻ آهي. ڊيٽابيس سرٽيفڪيٽ ٻنهي جي تصديق ۽ انڪرپشن لاءِ استعمال ٿيندا آهن. ڊيٽابيس سان ڳنڍڻ لاءِ ڪلائنٽ لاءِ صارف نالو ۽ پاسورڊ مهيا ڪرڻ بدران، اهو پيش ڪري ٿو هڪ ڪلائنٽ سرٽيفڪيٽ جيڪو سرور طرفان قابل اعتماد آهي. ڊيٽابيس ڪلستر ۾ هر سرور ساڳيو عوامي ۽ خانگي چاٻي جوڙو استعمال ڪندو. هي ڪلستر ۾ سڀني سرورن کي اجازت ڏئي ٿو ته ڊيٽا کي ان طريقي سان انڪريپٽ ڪرڻ لاءِ ته اهو صرف ٻين سرورن طرفان ڊيڪرپٽ ٿي سگهي ٿو جيڪي پڻ ساڳيو ڪي جوڙو شيئر ڪن ٿا.

ڪم ڪرڻ لاءِ بيڪار ٿيڻ لاءِ، ڊيٽابيس ڪلسٽرن ۾ گھٽ ۾ گھٽ 3 سرورن تي مشتمل ھئڻ گھرجي، پر 5 کان وڌيڪ نه، ڪنھن ڪلستر جي ميمبرن جي وچ ۾ وڌ ۾ وڌ 200 ms جي گول ٽرپ ٽائيم سان. هي حد ڪال برج ڪلسترنگ جي ڀيٽ ۾ وڌيڪ محدود آهي، تنهنڪري اهو اڪثر ڪري جغرافيائي طور تي ورهايل ڊيپلائيشنز ۾ محدود عنصر هوندو آهي.

CMS لاءِ ڊيٽابيس جي ڪردار ۾ ڪيتريون ئي منفرد ضرورتون آھن. ٻين ڪردارن جي برعڪس، ان کي ڪلائنٽ ۽ سرور سرٽيفڪيٽ جي ضرورت آهي، جتي ڪلائنٽ سرٽيفڪيٽ وٽ هڪ مخصوص CN فيلڊ آهي جيڪو سرور ڏانهن پيش ڪيو ويو آهي.

سي ايم ايس هڪ پوسٽ گريس ڊيٽابيس استعمال ڪري ٿو هڪ ماسٽر ۽ ڪيترن ئي مڪمل طور تي هڪجهڙائي واري نقل سان. هڪ وقت ۾ صرف هڪ پرائمري ڊيٽابيس آهي ("ڊيٽابيس سرور"). ڪلستر جا باقي ميمبر replicas يا "ڊيٽابيس ڪلائنٽ" آهن.

هڪ ڊيٽابيس ڪلستر جي ضرورت آهي هڪ وقف سرور سرٽيفڪيٽ ۽ هڪ ڪلائنٽ سرٽيفڪيٽ. انهن کي لازمي طور تي سرٽيفڪيٽ طرفان دستخط ٿيڻ گهرجي، عام طور تي هڪ اندروني نجي سرٽيفڪيٽ اٿارٽي. ڇاڪاڻ ته ڊيٽابيس ڪلستر جو ڪو به ميمبر ماسٽر بڻجي سگهي ٿو، ڊيٽابيس سرور ۽ ڪلائنٽ سرٽيفڪيٽ جوڙو (جنهن ۾ عوامي ۽ خانگي چابيون شامل آهن) سڀني سرورن ڏانهن نقل ٿيڻ گهرجن ته جيئن اهي ڪلائنٽ يا ڊيٽابيس سرور جي سڃاڻپ سمجهي سگهن. اضافي طور تي، 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

ونڊوز/ڊاس تي:

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

۽ هر سرور تي اپلوڊ ڪريو:
1. ”انفرادي“ سرور سرٽيفڪيٽ.
2. روٽ سرٽيفڪيٽ (گڏجي وچولي وارن سان، جيڪڏهن ڪو هجي).
3. ڊيٽابيس لاءِ سرٽيفڪيٽ (“سرور” ۽ “ڪلائنٽ”) ۽ .key ايڪسٽينشن سان فائلون، جيڪي “سرور” ۽ “ڪلائنٽ” ڊيٽابيس سرٽيفڪيٽ لاءِ درخواست ٺاهڻ وقت ٺاهيا ويا. اهي فائلون سڀني سرورن تي ساڳيو هجڻ گهرجن.
4. سڀني ٽن ”انفرادي“ سرٽيفڪيٽن جو فائل.

نتيجي طور، توهان کي هر سرور تي هن فائل تصوير وانگر ڪجهه حاصل ڪرڻ گهرجي.

ڊيٽابيس ڪلستر

هاڻي ته توهان وٽ سي ايم ايس سرورز تي اپلوڊ ٿيل سڀئي سرٽيفڪيٽ آهن، توهان ٽن نوڊس جي وچ ۾ ڊيٽابيس ڪلسترنگ کي ترتيب ۽ فعال ڪري سگهو ٿا. پهريون قدم اهو آهي ته هڪ سرور کي ڊيٽابيس ڪلستر جي ماسٽر نوڊ طور چونڊيو ۽ ان کي مڪمل طور تي ترتيب ڏيو.

ماسٽر ڊيٽابيس

ڊيٽابيس جي نقل کي ترتيب ڏيڻ ۾ پهريون قدم انهن سرٽيفڪيٽن جي وضاحت ڪرڻ آهي جيڪي ڊيٽابيس لاءِ استعمال ڪيا ويندا. اهو هڪ حڪم استعمال ڪندي ڪيو ويندو آهي جهڙوڪ:

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 سرور جو ماسٽر ip ايڊريس جنهن تي ڪلستر شروع ڪيو ويو، بس ماسٽر.

اسان چيڪ ڪريون ٿا ته اسان جو ڊيٽابيس ڪلستر ڪيئن ڪم ڪري ٿو سڀني سرورن تي ڪمانڊ سان:

database cluster status

اسان باقي ٽئين سرور تي ساڳيو ڪم ڪندا آهيون.

نتيجي ۾ معلوم ٿيو ته اسان جو پهريون سرور آقا آهي، باقي غلام آهن.

ويب ايڊمنسٽريشن سروس

ويب ايڊمنسٽريٽر سروس کي فعال ڪريو:

webadmin listen a 445

پورٽ 445 چونڊيو ويو ڇاڪاڻ ته پورٽ 443 استعمال ڪيو ويندو آهي صارف جي ويب ڪلائنٽ تائين رسائي لاءِ

اسان ويب ايڊمنسٽريشن سروس کي سرٽيفڪيٽ فائلن سان ترتيب ڏيون ٿا جيئن ته:

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

۽ حڪم سان ويب ايڊمن کي فعال ڪريو:

webadmin enable

جيڪڏهن سڀ ڪجهه ٺيڪ آهي، اسان حاصل ڪنداسين SUCCESS لائينون جيڪي ظاهر ڪن ٿيون ته ويب ايڊمنسٽ نيٽ ورڪ ۽ سرٽيفڪيٽ لاءِ صحيح طرح سان ترتيب ڏنل آهي. اسان ويب برائوزر استعمال ڪندي خدمت جي ڪارڪردگي جي جانچ ڪريون ٿا ۽ ويب ايڊمنسٽريٽر جو پتو داخل ڪريو، مثال طور: cms.example.com: 445

ڪال برج ڪلستر

ڪال برج واحد خدمت آهي جيڪا هر سي ايم ايس جي مقرري ۾ موجود آهي. ڪال برج مکيه ڪانفرنسنگ ميڪانيزم آهي. اهو پڻ مهيا ڪري ٿو هڪ SIP انٽرفيس انهي ڪري ته ڪالز ان ڏانهن يا ان کان روٽ ڪري سگهجن ٿيون، مثال طور، هڪ سسڪو يونيفائيڊ سي ايم.

هيٺ ڏنل بيان ڪيل حڪمن تي عمل ڪيو وڃي هر سرور تي مناسب سرٽيفڪيٽ سان.
پوء:

اسان هڪ حڪم سان ڪال برج سروس سان سرٽيفڪيٽ سان لاڳاپيل آهيون جهڙوڪ:

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

اسان ڪال برج سروسز کي انٽرفيس تي پابند ڪريون ٿا جيڪي اسان کي حڪم سان گهربل آهن:

callbridge listen a

۽ حڪم سان سروس ٻيهر شروع ڪريو:

callbridge restart

هاڻي ته اسان وٽ اسان جي ڪال برجز ترتيب ڏنل آهن، اسان ڪال برج ڪلسترنگ کي ترتيب ڏئي سگهون ٿا. ڪال برج ڪلسترنگ ڊيٽابيس يا XMPP ڪلسترنگ کان مختلف آهي. ڪال برج ڪلستر بغير ڪنهن پابندي جي 2 کان 8 نوڊس جي مدد ڪري سگھن ٿا. اهو مهيا ڪري ٿو نه رڳو فالتو، پر پڻ لوڊ بيلنسنگ ته جيئن ڪانفرنسون فعال طور تي ورهائي سگهجن ٿيون ڪال برج سرورز تي ذهين ڪال ڊسٽريبيوشن استعمال ڪندي. CMS ۾ اضافي خاصيتون، ڪال برج گروپ ۽ لاڳاپيل خاصيتون آھن جيڪي وڌيڪ انتظام لاءِ استعمال ڪري سگھجن ٿيون.

ڪال پل ڪلسترنگ بنيادي طور تي ويب ايڊمنسٽريشن انٽرفيس ذريعي ترتيب ڏني وئي آهي
هيٺ ڏنل بيان ڪيل عمل کي ڪلستر ۾ هر سرور تي ڪيو وڃي.
۽ ائين،

1. ويب ذريعي وڃو ڪنفيگريشن > ڪلستر.
2. ۾ ڪال برج جي سڃاڻپ هڪ منفرد نالو جي طور تي، سرور جي نالي سان لاڳاپيل ڪالبرج[01,02,03] داخل ڪريو. اهي نالا پاڻمرادو آهن، پر هن ڪلستر لاءِ منفرد هجڻ گهرجن. اهي فطرت ۾ وضاحتي آهن ڇو ته اهي ظاهر ڪن ٿا ته اهي سرور جي سڃاڻپ ڪندڙ آهن [01,02,03].
3. بي ڪلستر ٿيل ڪال پل ڪلستر ۾ اسان جي سرورن جي ويب ايڊمنسٽريٽر URLs داخل ڪريو، cms[01,02,03].example.com:445، ايڊريس فيلڊ ۾. بندرگاھ جي وضاحت ڪرڻ جي پڪ ڪريو. توھان ڇڏي سگھوٿا پير لنڪ SIP ڊومين خالي.
4. هر سرور جي CallBridge اعتماد ۾ هڪ سرٽيفڪيٽ شامل ڪريو، جنهن جي فائل ۾ اسان جي سرور جا سڀئي سرٽيفڪيٽ شامل آهن، جن کي اسان شروع ۾ هن فائل ۾ ضم ڪيو، هڪ حڪم سان:

callbridge trust cluster <trusted cluster certificate bundle>

۽ حڪم سان سروس ٻيهر شروع ڪريو:

callbridge restart

نتيجي طور، هر سرور تي توهان کي هن تصوير حاصل ڪرڻ گهرجي:

XMPP ڪلستر

سي ايم ايس ۾ XMPP سروس استعمال ڪئي ويندي آهي سڀني رجسٽريشن ۽ تصديق لاءِ سسڪو ميٽنگ ايپس (CMA)، بشمول CMA WebRTC ويب ڪلائنٽ. ڪال برج خود پڻ تصديق جي مقصدن لاءِ هڪ 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 ڇو نه آهي؟ اسان جي خاص ڊيپلائيمينٽ ۾، اسان پنھنجي يونيفيڊ سي ايم ڊومين کي چونڊيو آھي جيڪو جابر استعمال ڪندڙ يونيفيڊ سي ايم ۾ مثال طور استعمال ڪندا مثال.com، تنھنڪري اسان کي سي ايم ايس استعمال ڪندڙن لاءِ ھڪ مختلف ڊومين جي ضرورت ھئي ته جيئن سي ايم ايس ڏانھن ۽ SIP ڊومينز ذريعي ڪالز کي روٽ ڪري سگھون.

هڪ حڪم استعمال ڪندي هڪ XMPP ڊومين سيٽ اپ ڪريو جهڙوڪ:

xmpp domain <domain>

۽ حڪم سان XMPP سروس کي فعال ڪريو:

xmpp enable

XMPP سروس ۾، توهان کي هر ڪال برج لاءِ سندون ٺاهڻ گهرجن جيڪي XMPP سروس سان رجسٽر ٿيڻ وقت استعمال ڪيا ويندا. اهي نالا پاڻمرادو آهن (۽ انهن نالن سان لاڳاپيل نه آهن جيڪي توهان ڪال برج ڪلسترنگ لاءِ ترتيب ڏنيون آهن). توهان کي لازمي طور تي هڪ XMPP سرور تي ٽي ڪال پل شامل ڪرڻ گهرجن ۽ پوءِ اهي سندون داخل ڪريو ٻين XMPP سرورز تي ڪلستر ۾ ڇاڪاڻ ته هي ترتيب ڪلستر ڊيٽابيس ۾ مناسب ناهي. بعد ۾ اسان هر ڪال برج کي ترتيب ڏينداسين هي نالو استعمال ڪرڻ لاءِ ۽ XMPP سروس سان رجسٽر ڪرڻ لاءِ راز.

هاڻي اسان کي پهرين سرور تي XMPP سروس ترتيب ڏيڻ جي ضرورت آهي ٽن ڪال برجز ڪالبرج01، ڪالبرج02 ۽ ڪالبرج03 سان. هر اڪائونٽ کي بي ترتيب پاسورڊ لڳايو ويندو. اهي بعد ۾ هن 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 ڪلستر سان ڳنڍڻ لاءِ ڪال برج سروسز کي ترتيب ڏيڻ جي ضرورت آهي. هي تشڪيل ويب منتظم جي ذريعي ڪيو ويندو آهي.

هر سرور تي، وڃو ڪنفگريشن> جنرل ۽ فيلڊ ۾ منفرد ڪال برج جو نالو سرور ڪال برج سان لاڳاپيل منفرد نالا لکو ڪال برج[01,02,03]... ميدان ۾ ڊومين 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 کي سپورٽ ڪري ٿو. اھو HTTPS ڏانھن HTTPS ڏانھن ريڊائريڪٽ ڪندو جيڪڏھن "http-redirect" استعمال ڪرڻ لاءِ ترتيب ڏنل آھي.
HTTP ريڊائريشن کي فعال ڪرڻ لاء، ھيٺ ڏنل حڪم استعمال ڪريو:

webbridge http-redirect enable

ڪال برج کي ڄاڻڻ لاءِ ته ويب برج ڪال برج کان ڪنيڪشن تي ڀروسو ڪري سگهي ٿو، حڪم استعمال ڪريو:

webbridge trust <certfile>

جتي هي هڪ فائل آهي جنهن ۾ ڪلستر ۾ هر سرور مان سڀ ٽي سرٽيفڪيٽ شامل آهن.

هي تصوير ڪلستر ۾ هر سرور تي هجڻ گهرجي.


ھاڻي اسان کي ”ايپ ايڊمن“ ڪردار سان ھڪڙو صارف بڻائڻو آھي، اسان کي ان جي ضرورت آھي ته جيئن اسان پنھنجي ڪلستر (!) کي ترتيب ڏئي سگھون، ۽ نه ته ڪلستر ۾ موجود ھر سرور کي الڳ الڳ، اھڙي طرح سيٽنگون ھر سرور تي برابر لاڳو ٿينديون. حقيقت اها آهي ته اهي هڪ ڀيرو ٺاهيا ويندا.


وڌيڪ سيٽ اپ لاء اسين استعمال ڪنداسين پوسٽ.

اختيار ڪرڻ لاء، اختيار سيڪشن ۾ بنيادي چونڊيو

CMS سرور ڏانهن حڪمن کي صحيح طور تي موڪلڻ لاء، توهان کي گهربل انڪوڊنگ سيٽ ڪرڻ جي ضرورت آهي

اسان Webbridge کي حڪم سان بيان ڪيو پوسٽ پيٽرولر سان URL ۽ معنيٰ cms.example.com



پاڻ ويب برج ۾، اسان کي گهربل پيٽرولر ڏيکاري ٿو: مهمان رسائي، محفوظ رسائي، وغيره.

ڪال برج گروپس

ڊفالٽ طور، سي ايم ايس هميشه ان وٽ موجود ڪانفرنسنگ وسيلن جو سڀ کان وڌيڪ موثر استعمال نٿو ڪري.

مثال طور، ٽن شرڪت ڪندڙن سان ملاقات لاءِ، هر شرڪت ڪندڙ ٽن مختلف ڪال برجز تي ختم ٿي سگھي ٿو. انهن ٽنهي شرڪت ڪندڙن لاءِ هڪ ٻئي سان رابطو ڪرڻ لاءِ، ڪال برجز خود بخود سڀني سرورن ۽ ڪلائنٽ جي وچ ۾ هڪ ئي اسپيس ۾ ڪنيڪشن قائم ڪنديون، انهي ڪري اهو سڀ ڪجهه ائين لڳندو ڄڻ سڀ ڪلائنٽ هڪ ئي سرور تي آهن. بدقسمتي سان، هن جو نقصان اهو آهي ته هڪ اڪيلو 3-شخص ڪانفرنس هاڻي 9 ميڊيا بندرگاهن کي استعمال ڪندي. اهو واضح طور تي وسيلن جي غير موثر استعمال آهي. اضافي طور تي، جڏهن هڪ ڪال برج واقعي اوور لوڊ ٿئي ٿي، ڊفالٽ ميکانيزم اهو آهي ته ڪالز قبول ڪرڻ جاري رکڻ ۽ ان ڪال برج جي سڀني رڪنن کي گهٽ معيار جي خدمت مهيا ڪرڻ.

اهي مسئلا ڪال برج گروپ جي خصوصيت استعمال ڪندي حل ڪيا ويا آهن. هي فيچر سسڪو ميٽنگ سرور سافٽ ويئر جي ورزن 2.1 ۾ متعارف ڪرايو ويو آهي ۽ ان بائونڊ ۽ آئوٽ بائونڊ Cisco Meeting App (CMA) ڪالن لاءِ لوڊ بيلنسنگ کي سپورٽ ڪرڻ لاءِ وڌايو ويو آهي، بشمول WebRTC شرڪت ڪندڙ.

ٻيهر ڪنيڪشن جي مسئلي کي حل ڪرڻ لاءِ، هر ڪال برج لاءِ ٽي ترتيب وار لوڊ حدون متعارف ڪرايون ويون آهن:

لوڊ جي حد - هي آهي وڌ ۾ وڌ عددي لوڊ هڪ خاص ڪال برج لاءِ. هر پليٽ فارم تي تجويز ڪيل لوڊ جي حد آهي، جهڙوڪ 96000 CMS1000 لاءِ ۽ 1.25 GHz في وي سي پي يو ورچوئل مشين لاءِ. حصو وٺندڙ جي ريزوليوشن ۽ فريم ريٽ تي منحصر ڪري مختلف ڪالون وسيلن جي هڪ خاص مقدار کي استعمال ڪن ٿيون.
نيو ڪانفرنس لوڊ لائيٽ بيس پوائنٽس (ڊفالٽ 50٪ loadLimit) - سرور لوڊ جي حد مقرر ڪري ٿو، جنهن کان پوء نئين ڪانفرنس کي رد ڪيو وڃي ٿو.
موجوده ڪانفرنس لوڊ لائيٽ بيس پوائنٽس (ڊفالٽ 80٪ loadLimit) - سرور لوڊ ويليو جنهن کان پوءِ شرڪت ڪندڙ موجوده ڪانفرنس ۾ شامل ٿيڻ کي رد ڪيو ويندو.

جڏهن ته هي فيچر ڪال ڊسٽريبيوشن ۽ لوڊ بيلنسنگ لاءِ ٺاهيو ويو هو، ٻين گروپن جهڙوڪ ٽرن سرورز، ويب برج سرورز ۽ رڪارڊرز کي پڻ ڪال برج گروپس کي تفويض ڪري سگھجن ٿا ته جيئن انهن کي به بهتر استعمال لاءِ مناسب طريقي سان گروپ ڪري سگهجي. جيڪڏهن انهن شين مان ڪنهن به ڪال گروپ کي تفويض نه ڪيو ويو آهي، اهي فرض ڪيا ويندا آهن سڀني سرورن لاءِ دستياب آهن بغير ڪنهن خاص ترجيح جي.

اهي پيرا ميٽر هتي ترتيب ڏنل آهن: cms.example.com:445/api/v1/system/configuration/cluster

اڳيون، اسان هر ڪالبرج ڏانهن اشارو ڪريون ٿا جنهن ڪالبرج گروپ سان تعلق رکي ٿو:

پهريون ڪالبريج

ٻيو ڪال برج

ٽيون ڪالبريج


ان ڪري، اسان Csco Meeting Server ڪلستر جي وسيلن کي وڌيڪ موثر طريقي سان استعمال ڪرڻ لاءِ Call Brdige گروپ کي ترتيب ڏنو.

فعال ڊاريڪٽري مان صارفين کي درآمد ڪندي

ويب ايڊمنسٽريشن سروس ۾ LDAP کنفيگريشن سيڪشن آهي، پر اهو پيچيده ترتيب جا اختيار مهيا نٿو ڪري، ۽ معلومات ڪلستر ڊيٽابيس ۾ محفوظ نه آهي، تنهنڪري ترتيب ڏيڻو پوندو، يا ته هر سرور تي دستي طور تي ويب انٽرفيس ذريعي، يا ذريعي. API، ۽ انهي ڪري ته اسان "ٽي ڀيرا "اٿي نه وڃو" اسان اڃا تائين API ذريعي ڊيٽا سيٽ ڪنداسين.

استعمال ڪرڻ لاء URL جو استعمال cms01.example.com:445/api/v1/ldapServers هڪ LDAP سرور اعتراض ٺاهي، پيٽرولر جي وضاحت ڪري ٿو جهڙوڪ:

• سرور IP
• پورٽ نمبر
• کاتي جو نالو
• پاسورڊ
• بي

محفوظ - بندرگاهن جي لحاظ کان صحيح يا غلط چونڊيو، 389 - محفوظ ناهي، 636 - محفوظ.


Cisco Meeting Server ۾ خاصيتن لاءِ LDAP ماخذ جي ماپن کي نقشي ڪرڻ.
LDAP ميپنگ LDAP ڊاريڪٽري ۾ خاصيتن کي سي ايم ايس ۾ خاصيتن سان نقشي ڪري ٿو. اصل خاصيتون:

• jidMapping
• نالو ميپنگ
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

صفتن جي وضاحتJID CMS ۾ استعمال ڪندڙ جي لاگ ان ID جي نمائندگي ڪري ٿو. جيئن ته هي هڪ Microsoft Active Directory LDAP سرور آهي، ان ڪري CMS JID LDAP ۾ sAMAccountName ڏانهن نقشو ٺاهي ٿو، جيڪو بنيادي طور استعمال ڪندڙ جي Active Directory لاگ ان ID آهي. اهو پڻ نوٽ ڪريو ته توهان sAMAccountName وٺو ۽ ان جي آخر ۾ ڊومين conf.pod6.cms.lab شامل ڪريو ڇو ته هي اهو لاگ ان آهي جيڪو توهان جا صارف استعمال ڪندا CMS ۾ لاگ ان ٿيڻ لاءِ.

نالو ميپنگ ملائي ٿو جيڪو Active Directory displayName فيلڊ ۾ موجود آهي صارف جي CMS نالي جي فيلڊ سان.

coSpaceNameMapping ڊسپلي نالو فيلڊ جي بنياد تي هڪ CMS اسپيس جو نالو ٺاهي ٿو. هي وصف، coSpaceUriMapping وصف سان گڏ، هر صارف لاءِ هڪ جاءِ ٺاهڻ جي ضرورت آهي.

coSpaceUriMapping صارف جي ذاتي جاءِ سان لاڳاپيل URI جو استعمال ڪندڙ حصو بيان ڪري ٿو. ڪجھ ڊومينز کي ترتيب ڏئي سگھجي ٿو خلا ۾ ڊائل ڪرڻ لاءِ. جيڪڏهن صارف حصو هن فيلڊ سان ملندو آهي انهن ڊومينز مان هڪ لاء، ڪال کي هدايت ڪئي ويندي صارف جي جاء تي.

coSpaceSecondaryUriMapping خلا تائين پهچڻ لاءِ ٻيو يو آر آئي بيان ڪري ٿو. ھي استعمال ڪري سگھجي ٿو ھڪڙي عددي عرف شامل ڪرڻ لاءِ ڪالن کي روئٽنگ ڪرڻ لاءِ درآمد ٿيل يوزر جي اسپيس کي متبادل طور تي الفانمياتي URI جي وضاحت ڪئي وئي coSpaceUriMapping پيراميٽر ۾.

LDAP سرور ۽ LDAP ميپنگ ترتيب ڏنل آھن. ھاڻي توھان کي انھن کي ڳنڍڻ جي ضرورت آھي LDAP ماخذ ٺاھڻ سان.

استعمال ڪرڻ لاء URL جو استعمال cms01.example.com:445/api/v1/ldapSource هڪ LDAP ماخذ اعتراض ٺاهي، پيٽرولر جي وضاحت ڪندي جهڙوڪ:

• سرور
• نقشه
• بنيادي ڊي اين
• فلٽر

ھاڻي ته LDAP ٺاھ جوڙ مڪمل ٿي چڪو آھي، توھان دستي هم وقت سازي جي عمل کي انجام ڏئي سگھو ٿا.

اسان اهو ڪندا آهيون يا ته هر سرور جي ويب انٽرفيس ۾ ڪلڪ ڪري هاڻي هم وقت ڪريو سيڪشن فعال ڊاريڪٽري


يا API ذريعي حڪم سان پوسٽ URL استعمال ڪرڻ تائين رسائي cms01.example.com:445/api/v1/ldapSyncs

ايڊهاڪ ڪانفرنسون

هي ڇا آهي؟روايتي تصور ۾، هڪ ڪانفرنس اها آهي جڏهن ٻه شرڪت ڪندڙ هڪ ٻئي سان ڳالهائي رهيا آهن، ۽ شرڪت ڪندڙن مان هڪ (يونيائيڊڊ سي ايم سان رجسٽر ٿيل ڊوائيس استعمال ڪندي) "ڪانفرنس" بٽڻ کي دٻايو، ٻئي شخص کي سڏي، ۽ انهي ٽئين پارٽي سان ڳالهائڻ کان پوء. ٽي طرفي ڪانفرنس ۾ سڀني شرڪت ڪندڙن ۾ شامل ٿيڻ لاء، "ڪانفرنس" بٽڻ کي ٻيهر دٻايو.

سي ايم ايس ۾ مقرر ڪيل ڪانفرنس کان ايڊ-هاڪ ڪانفرنس کي ڇا فرق ڪري ٿو ته هڪ ايڊ-هاڪ ڪانفرنس صرف CMS لاءِ SIP ڪال ناهي. جڏهن ڪانفرنس جي شروعات ڪندڙ ٻئي ڀيري ڪانفرنس جي بٽڻ تي ڪلڪ ڪري سڀني کي ساڳئي ميٽنگ ۾ دعوت ڏيڻ لاءِ، متحد سي ايم کي لازمي طور تي سي ايم ايس کي هڪ API ڪال ڪرڻ گهرجي هڪ آن دي فلائي ڪانفرنس ٺاهڻ لاءِ جنهن ۾ سڀ ڪالون پوءِ منتقل ڪيون وينديون آهن. اهو سڀ ڪجهه شرڪت ڪندڙن کان اڻڄاڻ ٿئي ٿو.

ان جو مطلب اهو آهي ته متحد CM کي لازمي طور تي API سندون ۽ ويب ايڊمن ايڊريس/سروس جي بندرگاهن کي ترتيب ڏيڻ گهرجي ۽ انهي سان گڏ SIP ٽرنڪ کي سڌو سنئون CMS سرور ڏانهن ڪال جاري رکڻ لاءِ.

جيڪڏهن ضروري هجي ته، CUCM متحرڪ طور تي CMS ۾ هڪ جڳهه ٺاهي سگهي ٿو ته جيئن هر ڪال CMS تائين پهچي سگهي ۽ ايندڙ ڪال جي ضابطي سان ملائي جيڪا اسپيس لاءِ آهي.

CUCM سان انضمام ساڳئي طريقي سان ترتيب ڏنل آهي جيئن مضمون ۾ بيان ڪيو ويو آهي پهريان کان ان کان سواءِ Cisco UCM تي توهان کي سي ايم ايس لاءِ ٽي ٽرنڪس ٺاهڻ گهرجن، ٽي ڪانفرنس برجز، SIP سيڪيورٽي پروفائل ۾ ٽن مضمونن جا نالا، روٽ گروپس، روٽ لسٽون، ميڊيا ريسورس گروپس ۽ ميڊيا ريسورس گروپ لسٽون، ۽ ڪجھ روٽنگ قاعدا شامل ڪريو. سسڪو ميٽنگ سرور ڏانهن.

SIP سيڪيورٽي پروفائل:


ٽانڊن:


هر ٽڪرو ساڳيو نظر اچي ٿو:




ڪانفرنس پل


هر ڪانفرنس برج ساڳيو نظر اچي ٿو:


رستو گروپ


رستن جي فهرست


ميڊيا ريسورس گروپ


ميڊيا ريسورس گروپ لسٽ

ڪال ضابطا

وڌيڪ جديد ڪال مئنيجمينٽ سسٽم جي برعڪس جهڙوڪ يونيفائيڊ سي ايم يا ايڪسپريس وي، سي ايم ايس صرف ڊومين کي ڏسي ٿو SIP Request-URI فيلڊ ۾ نون ڪالن لاءِ. تنهن ڪري جيڪڏهن SIP دعوت sip لاءِ آهي: [ايميل محفوظ ٿيل]CMS صرف domain.com جي باري ۾ خيال رکي ٿو. سي ايم ايس انهن قاعدن تي عمل ڪري ٿو اهو طئي ڪرڻ لاءِ ته ڪال ڪٿي روٽ ڪجي:

1. CMS پهريون ڀيرو SIP ڊومين کي ملائڻ جي ڪوشش ڪري ٿو ڊومينز سان ترتيب ڏنل ايندڙ ڪال ضابطن ۾. اهي ڪالون پوءِ (“ٽارگيٽڊ”) اسپيس يا مخصوص استعمال ڪندڙن، اندروني IVRs، يا سڌي طرح ضم ٿيل Microsoft Lync/Skype for Business (S4B) منزلن ڏانهن روانا ٿي سگهن ٿيون.
2. جيڪڏهن اچڻ واري ڪال جي ضابطن ۾ ڪا به مطابقت ناهي، 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 ٽرڪنز کي وقف ڪري هر CMS سرورز کي انفرادي طور تي. ان تي منحصر آهي ته ڇا انهن SIP ٽرڪن جي منزل هڪ IP پتو آهي يا سرور جو FQDN اهو طئي ڪندو ته ڇا CMS کي ان جي IP پتي يا FQDN ڏانهن هدايتون ڪالون قبول ڪرڻ لاءِ ترتيب ڏيڻ جي ضرورت آهي.

اهو ڊومين جنهن ۾ سڀ کان وڌيڪ ترجيح آهي انبائونڊ قاعدو ڪنهن به صارف جي جڳهن لاءِ ڊومين طور استعمال ڪيو ويندو آهي. جڏهن صارفين LDAP ذريعي هم وقت سازي ڪن ٿا، سي ايم ايس خودڪار طور تي اسپيس ٺاهي ٿو، پر صرف يو آر آئي (coSpaceUriMapping) جو صارف حصو، مثال طور، user.space. حصو ڊومين مڪمل URI هن قاعدي جي بنياد تي ٺاهي وئي آهي. حقيقت ۾، جيڪڏهن توهان هن نقطي تي ويب برج ۾ لاگ ان ٿيڻ وارا هئا، توهان ڏسندا ته خلائي URI وٽ ڊومين ناهي. هن قاعدي کي اعليٰ ترجيح جي طور تي ترتيب ڏيڻ سان، توهان ٺاهي رهيا آهيو ڊومين کي ٺاهيل جڳهن لاءِ conf.example.com.


ٻاهر نڪرڻ واري ڪال ضابطن

صارفين کي يونيفيڊ سي ايم ڪلسٽر ۾ آئوٽ بائونڊ ڪالون ڪرڻ جي اجازت ڏيڻ لاءِ، توھان کي لازمي طور تي آئوٽ بائونڊ قاعدن کي ترتيب ڏيڻ گھرجي. يونائيٽيڊ سي ايم سان رجسٽر ٿيل آخري پوائنٽس جو ڊومين، جهڙوڪ جابر، مثال.com آهي. هن ڊومين ڏانهن ڪالون معياري SIP ڪالن جي طور تي گڏيل CM ڪال پروسيسنگ نوڊس ڏانهن روٽ ٿيڻ گهرجن. مکيه سرور آهي cucm-01.example.com، ۽ اضافي سرور آهي cucm-02.example.com.

پهريون قاعدو ڪلستر سرورز جي وچ ۾ ڪالن جو آسان رستو بيان ڪري ٿو.

ميدان ڊومين مان مقامي ان لاءِ ذميوار آهي جيڪو ڪالر جي SIP-URI ۾ ڏيکاريو ويندو ان شخص لاءِ جنهن کي “@” علامت کان پوءِ سڏيو وڃي ٿو. جيڪڏهن اسان ان کي خالي ڇڏي ڏيون ٿا، ته پوءِ ”@“ علامت کان پوءِ CUCM جو IP پتو هوندو جنهن مان هي ڪال گذري ٿو. جيڪڏهن اسان هڪ ڊومين جي وضاحت ڪريون ٿا، پوء "@" علامت کان پوء اصل ۾ هڪ ڊومين هوندو. واپس ڪال ڪرڻ جي قابل ٿيڻ لاءِ اهو ضروري آهي، ٻي صورت ۾ SIP-URI name@ip-address ذريعي واپس ڪال ڪرڻ ممڪن نه هوندو.

ڪال ڪريو جڏهن بيان ڪيو ويو آهي ڊومين مان مقامي


ڪال ڪريو جڏهن نه ظاهر ڪيو ڊومين مان مقامي


نڪرندڙ ڪالن لاءِ واضع طور تي انڪريپٽ ٿيل يا غير انڪريپٽ ٿيل بيان ڪرڻ جي پڪ ڪريو، ڇاڪاڻ ته ڪجھ به ڪم نه ڪندو آٽو پيٽرول سان.

رڪارڊنگ

ويڊيو ڪانفرنس رڪارڊ سرور طرفان رڪارڊ ٿيل آهن. رڪارڊر بلڪل ساڳيو آهي سسڪو ميٽنگ سرور. رڪارڊر کي ڪنهن به لائسنس جي انسٽاليشن جي ضرورت ناهي. رڪارڊنگ لائسنس گهربل آهن سرورز لاءِ هلندڙ ڪال برج سروسز، يعني. هڪ رڪارڊنگ لائسنس گهربل آهي ۽ لازمي طور تي ڪال برج جي جزو تي لاڳو ڪيو وڃي، نه ته سرور تي هلندڙ رڪارڊر تي. رڪارڊر هڪ Extensible Messaging and Presence Protocol (XMPP) ڪلائنٽ طور ڪم ڪري ٿو، تنهن ڪري XMPP سرور کي فعال ڪيو وڃي سرور هوسٽنگ ڪال برج تي.

ڇاڪاڻ ته اسان وٽ ھڪڙو ڪلستر آھي ۽ لائسنس کي ڪلستر ۾ سڀني ٽن سرورن تي ”وڌڻ“ جي ضرورت آھي. پوءِ بس توهان جي ذاتي اڪائونٽ ۾ لائسنسن ۾ شامل ڪريون ٿا (شامل ڪريو) MAC ايڊريس جي اي-انٽرفيس جي سڀني CMS سرورز جي ڪلسٽر ۾ شامل.

۽ هي اها تصوير آهي جيڪا ڪلستر ۾ هر سرور تي هجڻ گهرجي

عام طور تي، رڪارڊر رکڻ لاءِ ڪيترائي منظرنامو آھن، پر اسين ھن تي قائم رھنداسين:


رڪارڊر قائم ڪرڻ کان پهريان، توهان کي هڪ جڳهه تيار ڪرڻ جي ضرورت آهي جتي ويڊيو ڪانفرنس اصل ۾ رڪارڊ ڪئي ويندي. اصل ۾ هتي لنڪ، سڀ رڪارڊنگ ڪيئن سيٽ اپ ڪجي. مان اهم نقطن ۽ تفصيلن تي ڌيان ڏيان ٿو:

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