سسکو میٹنگ سرور 2.5.2. ویڈیو کانفرنس ریکارڈنگ فنکشن کے ساتھ توسیع پذیر اور لچکدار موڈ میں کلسٹر

اس شمارے میں میں فیل اوور کلسٹر موڈ میں CMS سرور قائم کرنے کی کچھ پیچیدگیاں دکھاؤں گا اور اس کی وضاحت کروں گا۔


Теорияعام طور پر، CMS سرور کی تعیناتی کی تین قسمیں ہیں:

• سنگل مشترکہ(واحد مشترکہ)، یعنی یہ ایک سرور ہے جس پر تمام ضروری خدمات چل رہی ہیں۔ زیادہ تر معاملات میں، اس قسم کی تعیناتی صرف داخلی کلائنٹ تک رسائی کے لیے موزوں ہے اور چھوٹے ماحول میں جہاں ایک سرور کی توسیع پذیری اور فالتو پن کی حدود کوئی اہم مسئلہ نہیں ہیں، یا ایسے حالات میں جہاں CMS صرف کچھ افعال انجام دیتا ہے، جیسے کہ ایڈہاک۔ سسکو UCM پر کانفرنسیں

  کام کی تخمینی اسکیم:
  

• سنگل سپلٹ۔(سنگل اسپلٹ) بیرونی رسائی کے لیے ایک علیحدہ سرور شامل کرکے پچھلی تعیناتی کی قسم کو بڑھاتا ہے۔ میراثی تعیناتیوں میں، اس کا مطلب ایک غیر فوجی نیٹ ورک سیگمنٹ (DMZ) میں CMS سرور کی تعیناتی ہے جہاں بیرونی کلائنٹس اس تک رسائی حاصل کر سکتے ہیں، اور نیٹ ورک کور میں ایک CMS سرور جہاں اندرونی کلائنٹس CMS تک رسائی حاصل کر سکتے ہیں۔ اس مخصوص تعیناتی ماڈل کو اب نام نہاد قسم کے ذریعے تبدیل کیا جا رہا ہے۔ سنگل ایج، جو سرورز پر مشتمل ہے۔ سسکو ایکسپریس وے، جس میں یا تو بہت سی ایک جیسی فائر وال بائی پاس صلاحیتیں ہوں گی یا ہوں گی تاکہ کلائنٹس کو ایک سرشار سی ایم ایس سرور شامل کرنے کی ضرورت نہ ہو۔

  کام کی تخمینی اسکیم:
  

• توسیع پذیر اور لچکدار(اسکیل ایبل اور فالٹ ٹولرنٹ) اس قسم میں ہر جزو کے لیے فالتو پن شامل ہے، جس سے سسٹم کو آپ کی ضروریات کے ساتھ اس کی زیادہ سے زیادہ صلاحیت تک بڑھنے کی اجازت ملتی ہے جبکہ ناکامی کی صورت میں فالٹ پن فراہم کرتا ہے۔ یہ محفوظ بیرونی رسائی فراہم کرنے کے لیے سنگل ایج تصور کا بھی استعمال کرتا ہے۔ یہ وہ قسم ہے جسے ہم اس ایپی سوڈ میں دیکھیں گے۔ اگر ہم سمجھتے ہیں کہ اس قسم کے کلسٹر کو کیسے تعینات کیا جائے، تو ہم نہ صرف دوسری قسم کی تعیناتیوں کو سمجھیں گے، بلکہ ہم یہ سمجھنے کے قابل بھی ہوں گے کہ طلب میں ممکنہ اضافے کو ایڈجسٹ کرنے کے لیے CMS سرورز کے کلسٹرز کیسے بنائے جائیں۔

تعیناتی پر آگے بڑھنے سے پہلے، آپ کو کچھ بنیادی چیزوں کو سمجھنے کی ضرورت ہے، یعنی

CMS سافٹ ویئر کے اہم اجزاء:

• ڈیٹا بیس: آپ کو کچھ کنفیگریشنز کو یکجا کرنے کی اجازت دیتا ہے، جیسے کہ ڈائل پلان، صارف کی جگہیں، اور خود صارفین۔ صرف اعلی دستیابی (سنگل ماسٹر) کے لیے کلسٹرنگ کو سپورٹ کرتا ہے۔
• کال برج: آڈیو اور ویڈیو کانفرنسنگ کے لیے ایک سروس جو کالز اور ملٹی میڈیا پروسیسنگ کے انتظام اور پروسیسنگ پر مکمل کنٹرول فراہم کرتی ہے۔ اعلی دستیابی اور اسکیل ایبلٹی کے لیے کلسٹرنگ کو سپورٹ کرتا ہے۔
• XMPP سرور: سسکو میٹنگ ایپلیکیشن اور/یا WebRTC استعمال کرنے والے کلائنٹس کی رجسٹریشن اور تصدیق کے لیے ذمہ دارریئل ٹائم مواصلات، یا صرف براؤزر میں), نیز انٹر کمپوننٹ سگنلنگ۔ صرف اعلی دستیابی کے لیے کلسٹر کیا جا سکتا ہے۔
• ویب برج: WebRTC تک کلائنٹ کی رسائی فراہم کرتا ہے۔
• لوڈ بیلنسر: سنگل اسپلٹ موڈ میں سسکو میٹنگ ایپس کے لیے ایک واحد کنکشن پوائنٹ فراہم کرتا ہے۔ آنے والے رابطوں کے لیے بیرونی انٹرفیس اور پورٹ کو سنتا ہے۔ اسی طرح، لوڈ بیلنسر XMPP سرور سے آنے والے TLS کنکشنز کو قبول کرتا ہے، جس کے ذریعے یہ بیرونی کلائنٹس سے TCP کنکشنز کو تبدیل کر سکتا ہے۔
  ہمارے منظر نامے میں اس کی ضرورت نہیں ہوگی۔
• ٹرن سرور: فائر وال بائی پاس ٹیکنالوجی فراہم کرتا ہے جو اجازت دیتا ہے۔
  سسکو میٹنگ ایپ یا ایس آئی پی ڈیوائسز کا استعمال کرتے ہوئے بیرونی کلائنٹس کو جوڑنے کے لیے ہمارے CMS کو فائر وال یا NAT کے پیچھے رکھیں۔ ہمارے منظر نامے میں اس کی ضرورت نہیں ہوگی۔
• ویب ایڈمن: انتظامی انٹرفیس اور API رسائی، بشمول خصوصی یونیفائیڈ CM کانفرنسوں کے لیے۔

کنفیگریشن موڈز

سسکو کی دیگر مصنوعات کے برعکس، سسکو میٹنگ سرور کسی بھی قسم کی تعیناتی کو ایڈجسٹ کرنے کے لیے کنفیگریشن کے تین طریقوں کی حمایت کرتا ہے۔

• کمانڈ لائن (CLI): ابتدائی کنفیگریشن اور سرٹیفکیٹ کے کاموں کے لیے کمانڈ لائن انٹرفیس جسے MMP کہا جاتا ہے۔
• ویب ایڈمنسٹریٹر: بنیادی طور پر کال برج سے متعلقہ کنفیگریشنز کے لیے، خاص طور پر جب ایک واحد غیر کلسٹرڈ سرور ترتیب دیا جائے۔
• باقی API: انتہائی پیچیدہ کنفیگریشن کاموں اور کلسٹرڈ ڈیٹا بیس سے متعلق کاموں کے لیے استعمال کیا جاتا ہے۔

مندرجہ بالا کے علاوہ، پروٹوکول استعمال کیا جاتا ہے SFTP فائلوں کو منتقل کرنے کے لیے — عام طور پر لائسنس، سرٹیفکیٹ، یا لاگ — CMS سرور پر اور اس سے۔

سسکو سے تعیناتی گائیڈ میں یہ سفید اور انگریزی میں لکھا گیا ہے کہ کلسٹر کو تعینات کرنے کی ضرورت ہے کم از کم تین سرورز (نوڈس) ڈیٹا بیس کے تناظر میں۔ کیونکہ صرف نوڈس کی طاق تعداد کے ساتھ ہی نئے ڈیٹا بیس ماسٹر کو منتخب کرنے کا طریقہ کار کام کرے گا، اور عام طور پر ڈیٹا بیس ماسٹر کا زیادہ تر CMS سرور ڈیٹا بیس کے ساتھ تعلق ہوتا ہے۔

اور جیسا کہ پریکٹس شو، دو سرورز (نوڈس) واقعی کافی نہیں ہیں۔ سلیکشن کا طریقہ کار اس وقت کام کرتا ہے جب ماسٹر کو ریبوٹ کیا جاتا ہے، غلام سرور صرف ریبوٹ شدہ سرور کے سامنے آنے کے بعد ہی ماسٹر بن جاتا ہے۔ تاہم، اگر دو سرورز کے جھرمٹ میں ماسٹر سرور اچانک باہر چلا جائے تو غلام سرور ماسٹر نہیں بنے گا، اور اگر غلام باہر چلا جائے تو باقی ماسٹر سرور غلام بن جائے گا۔

لیکن XMPP کے تناظر میں، واقعی تین سرورز کا ایک کلسٹر جمع کرنا ضروری ہوگا، کیونکہ اگر، مثال کے طور پر، آپ XMPP سروس کو ان سرورز میں سے کسی ایک پر غیر فعال کر دیتے ہیں جس میں XMMP لیڈر کی حیثیت میں ہے، تو باقی سرور پر XMPP فالوور کی حیثیت میں رہے گا اور XMPP سے کال برج کے کنکشن منقطع ہو جائیں گے، کیونکہ CallBridge قائد کی حیثیت کے ساتھ خصوصی طور پر XMPP سے جڑتا ہے۔ اور یہ اہم ہے، کیونکہ... ایک کال بھی نہیں گزرے گی۔

نیز اسی تعیناتی گائیڈز میں ایک XMPP سرور کے ساتھ ایک کلسٹر کا مظاہرہ کیا جاتا ہے۔

اور مندرجہ بالا کو مدنظر رکھتے ہوئے، یہ واضح ہو جاتا ہے کہ کیوں: یہ کام کرتا ہے کیونکہ یہ فیل اوور موڈ میں ہے۔

ہمارے معاملے میں، XMPP سرور تینوں نوڈس پر موجود ہوگا۔

یہ فرض کیا جاتا ہے کہ ہمارے تینوں سرورز اپ ہیں۔

DNS ریکارڈز

سرورز کو ترتیب دینا شروع کرنے سے پہلے، آپ کو DNS ریکارڈز بنانے کی ضرورت ہے۔ А и Srv اقسام:

براہ کرم نوٹ کریں کہ ہمارے DNS ریکارڈز میں دو ڈومین ہیں example.com اور conf.example.com Example.com ایک ایسا ڈومین ہے جسے تمام Cisco Unified Communication Manager سبسکرائبرز اپنے URIs کے لیے استعمال کر سکتے ہیں، جو کہ آپ کے بنیادی ڈھانچے میں موجود ہے یا موجود ہونے کا امکان ہے۔ یا example.com اسی ڈومین سے میل کھاتا ہے جسے صارف اپنے ای میل پتوں کے لیے استعمال کرتے ہیں۔ یا آپ کے لیپ ٹاپ پر جابر کلائنٹ کا URI ہوسکتا ہے۔ [ای میل محفوظ]. ڈومین conf.example.com وہ ڈومین ہے جو سسکو میٹنگ سرور کے صارفین کے لیے ترتیب دیا جائے گا۔ سسکو میٹنگ سرور کا ڈومین ہوگا۔ confمثال کے طور پر.conf.example.com

بنیادی ترتیب

ذیل میں بیان کردہ تمام ترتیبات ایک سرور پر دکھائی گئی ہیں، لیکن انہیں کلسٹر میں ہر سرور پر کرنے کی ضرورت ہے۔

سروس

چونکہ CMS پیدا ہوتا ہے۔ اصل وقت تاخیر اور پیکٹ کے نقصان سے حساس ٹریفک، زیادہ تر معاملات میں سروس کے معیار (QoS) کو ترتیب دینے کی سفارش کی جاتی ہے۔ اس کو حاصل کرنے کے لیے، CMS مختلف خدمات کے کوڈز (DSCPs) کے ساتھ ٹیگنگ پیکٹ کی حمایت کرتا ہے۔ اگرچہ DSCP کی بنیاد پر ٹریفک کی ترجیح کا انحصار اس بات پر ہے کہ آپ کے انفراسٹرکچر کے نیٹ ورک اجزاء کے ذریعے ٹریفک کو کیسے پروسیس کیا جاتا ہے، ہمارے معاملے میں ہم QoS بہترین طریقوں کی بنیاد پر اپنے CMS کو عام DSCP ترجیحات کے ساتھ ترتیب دیں گے۔

ہر سرور پر ہم یہ کمانڈز درج کریں گے۔

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 سرورز کو CMS میں ایک کمانڈ کے ساتھ شامل کرتے ہیں جیسے:

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

ہمارے معاملے میں، دو ایسے سرورز ہیں، تو وہاں دو ٹیمیں ہوں گی۔
جانچ پڑتال:

نیٹ ورک انٹرفیس کنفیگریشن

ہم انٹرفیس کو ایک کمانڈ کے ساتھ تشکیل دیتے ہیں جیسے:

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

جانچ پڑتال:

سرور کا نام (میزبان نام)

ہم سرور کا نام ایک کمانڈ کے ساتھ سیٹ کرتے ہیں جیسے:

hostname <name>

اور ہم ریبوٹ کرتے ہیں۔


یہ بنیادی ترتیب کو مکمل کرتا ہے۔

سرٹیفکیٹس

Теорияسسکو میٹنگ سرور کو مختلف اجزاء کے درمیان انکرپٹڈ مواصلات کی ضرورت ہوتی ہے، اور اس کے نتیجے میں، تمام CMS تعیناتیوں کے لیے X.509 سرٹیفکیٹ درکار ہوتے ہیں۔ وہ اس بات کو یقینی بنانے میں مدد کرتے ہیں کہ سروسز/سرور پر دوسرے سرورز/سروسز کے ذریعے بھروسہ کیا جاتا ہے۔

ہر سروس کے لیے ایک سرٹیفکیٹ کی ضرورت ہوتی ہے، لیکن ہر سروس کے لیے علیحدہ سرٹیفکیٹ بنانا الجھن اور غیر ضروری پیچیدگی کا باعث بن سکتا ہے۔ خوش قسمتی سے، ہم سرٹیفکیٹ کا پبلک پرائیویٹ کلید جوڑا بنا سکتے ہیں اور پھر انہیں متعدد سروسز میں دوبارہ استعمال کر سکتے ہیں۔ ہمارے معاملے میں، وہی سرٹیفکیٹ کال برج، ایکس ایم پی پی سرور، ویب برج اور ویب ایڈمن کے لیے استعمال کیا جائے گا۔ اس طرح، آپ کو کلسٹر میں ہر سرور کے لیے پبلک اور پرائیویٹ سرٹیفکیٹ کیز کا ایک جوڑا بنانے کی ضرورت ہے۔

ڈیٹا بیس کلسٹرنگ، تاہم، کچھ خاص سرٹیفکیٹ کے تقاضے ہیں اور اس وجہ سے اس کے اپنے سرٹیفکیٹس کی ضرورت ہوتی ہے جو دوسری خدمات سے مختلف ہیں۔ 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 میں ہم اپنے سرورز کا عمومی نام لکھتے ہیں۔ مثال کے طور پر، اگر ہمارے سرورز کے میزبان نام سرور ایکس این ایم ایکس, سرور ایکس این ایم ایکس, سرور ایکس این ایم ایکس، پھر 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. تینوں "انفرادی" سرٹیفکیٹس کی فائل۔

نتیجے کے طور پر، آپ کو ہر سرور پر اس فائل تصویر کی طرح کچھ ملنا چاہئے۔

ڈیٹا بیس کلسٹر

اب جب کہ آپ کے پاس تمام سرٹیفیکیٹس 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. ویب کے ذریعے کنفیگریشن > کلسٹر پر جائیں۔
2. میں کال برج کی شناخت ایک منفرد نام کے طور پر، سرور کے نام کے مطابق کالبرج[01,02,03] درج کریں۔ یہ نام صوابدیدی ہیں، لیکن اس کلسٹر کے لیے منفرد ہونا چاہیے۔ وہ فطرت میں وضاحتی ہیں کیونکہ وہ اس بات کی نشاندہی کرتے ہیں کہ وہ سرور شناخت کنندہ ہیں [01,02,03]۔
3.B کلسٹرڈ کال برجز کلسٹر میں ہمارے سرورز کے ویب ایڈمنسٹریٹر یو آر ایل درج کریں، 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۔ یہ صرف example.com کیوں نہیں ہے؟ اپنی مخصوص تعیناتی میں، ہم نے اپنا یونیفائیڈ سی ایم ڈومین منتخب کیا جسے جابر صارفین یونیفائیڈ سی ایم میں بطور مثال ڈاٹ کام استعمال کریں گے، اس لیے ہمیں سی ایم ایس صارفین کے لیے ایک مختلف ڈومین کی ضرورت تھی تاکہ وہ ایس آئی پی ڈومینز کے ذریعے سی ایم ایس پر کالز کر سکیں۔

کمانڈ کا استعمال کرتے ہوئے ایک 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 کلسٹر سے منسلک ہونے کے لیے کال برج سروسز کو کنفیگر کرنے کی ضرورت ہے۔ یہ ترتیب ویب ایڈمن کے ذریعے کی جاتی ہے۔

ہر سرور پر، کنفیگریشن> جنرل اور فیلڈ میں جائیں۔ منفرد کال برج کا نام سرور کال برج کے مطابق منفرد نام لکھیں۔ کال برج[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 ریکارڈ کے لیے ترجیحی ترتیبات پر منحصر ہے۔

اس کے بعد، اس بات کی تصدیق کرنے کے لیے Status > General پر جائیں کہ آیا کال برائیڈ سروس XMPP سروس سے کامیابی کے ساتھ جڑ گئی ہے۔

ویب برج

کلسٹر میں ہر سرور پر، کمانڈ کے ساتھ ویب برج سروس کو فعال کریں:

webbridge listen a:443

ہم ویب برج سروس کو سرٹیفکیٹ فائلوں کے ساتھ کمانڈ کے ساتھ ترتیب دیتے ہیں جیسے:

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

ویب برج HTTPS کو سپورٹ کرتا ہے۔ اگر "http-ری ڈائریکٹ" کو استعمال کرنے کے لیے ترتیب دیا گیا ہو تو یہ HTTPS کو HTTPS پر ری ڈائریکٹ کرے گا۔
HTTP ری ڈائریکشن کو فعال کرنے کے لیے، درج ذیل کمانڈ کا استعمال کریں:

webbridge http-redirect enable

کال برج کو یہ بتانے کے لیے کہ ویب برج کال برج کے کنکشن پر بھروسہ کر سکتا ہے، کمانڈ استعمال کریں:

webbridge trust <certfile>

جہاں یہ ایک فائل ہے جس میں کلسٹر میں ہر سرور سے تینوں سرٹیفکیٹ ہوتے ہیں۔

یہ تصویر کلسٹر کے ہر سرور پر ہونی چاہیے۔


اب ہمیں "appadmin" کے کردار کے ساتھ ایک صارف بنانے کی ضرورت ہے، ہمیں اس کی ضرورت ہے تاکہ ہم اپنے کلسٹر (!) کو ترتیب دے سکیں، نہ کہ کلسٹر میں موجود ہر سرور کو الگ الگ، اس طرح سیٹنگز ہر سرور پر یکساں طور پر لاگو ہوں گی۔ حقیقت یہ ہے کہ وہ ایک بار بنائے جائیں گے.


مزید سیٹ اپ کے لیے ہم استعمال کریں گے۔ ڈاکیا.

اجازت کے لیے، اختیار کے سیکشن میں بنیادی کو منتخب کریں۔

CMS سرور کو صحیح طریقے سے کمانڈ بھیجنے کے لیے، آپ کو مطلوبہ انکوڈنگ سیٹ کرنے کی ضرورت ہے۔

ہم کمانڈ کے ساتھ Webbridge کی وضاحت کرتے ہیں۔ POST پیرامیٹر کے ساتھ یو آر ایل اور معنی cms.example.com



ویب برج میں ہی، ہم مطلوبہ پیرامیٹرز کی نشاندہی کرتے ہیں: مہمان تک رسائی، محفوظ رسائی، وغیرہ۔

برج گروپس کو کال کریں۔

پہلے سے طے شدہ طور پر، CMS ہمیشہ اپنے لیے دستیاب کانفرنسنگ وسائل کا سب سے زیادہ موثر استعمال نہیں کرتا ہے۔

مثال کے طور پر، تین شرکاء کے ساتھ میٹنگ کے لیے، ہر شریک تین مختلف کال برجز پر ختم ہو سکتا ہے۔ ان تینوں شرکاء کے لیے ایک دوسرے کے ساتھ بات چیت کرنے کے لیے، کال برجز خود بخود ایک ہی اسپیس میں موجود تمام سرورز اور کلائنٹس کے درمیان روابط قائم کر دیں گے، تاکہ ایسا لگتا ہے جیسے تمام کلائنٹس ایک ہی سرور پر ہیں۔ بدقسمتی سے، اس کا منفی پہلو یہ ہے کہ ایک واحد 3 افراد کی کانفرنس اب 9 میڈیا پورٹس استعمال کرے گی۔ یہ ظاہر ہے کہ وسائل کا غیر موثر استعمال ہے۔ مزید برآں، جب کال برج واقعی اوورلوڈ ہو جاتا ہے، پہلے سے طے شدہ طریقہ کار یہ ہے کہ کالز کو قبول کرنا جاری رکھا جائے اور اس کال برج کے تمام سبسکرائبرز کو کم معیاری سروس فراہم کی جائے۔

یہ مسائل کال برج گروپ کی خصوصیت کا استعمال کرتے ہوئے حل کیے جاتے ہیں۔ یہ خصوصیت Cisco Meeting Server سافٹ ویئر کے ورژن 2.1 میں متعارف کرائی گئی تھی اور اسے WebRTC کے شرکاء سمیت ان باؤنڈ اور آؤٹ باؤنڈ Cisco Meeting App (CMA) کالوں کے لیے لوڈ بیلنسنگ کو سپورٹ کرنے کے لیے بڑھایا گیا ہے۔

دوبارہ کنکشن کے مسئلے کو حل کرنے کے لیے، ہر کال برج کے لیے تین قابل ترتیب بوجھ کی حدیں متعارف کرائی گئی ہیں:

لوڈ کی حد - یہ کسی خاص کال برج کے لیے زیادہ سے زیادہ عددی بوجھ ہے۔ ہر پلیٹ فارم کی تجویز کردہ لوڈ کی حد ہوتی ہے، جیسے CMS96000 کے لیے 1000 اور ورچوئل مشین کے لیے 1.25 GHz فی vCPU۔ مختلف کالز شرکاء کی ریزولوشن اور فریم ریٹ کے لحاظ سے وسائل کی ایک خاص مقدار استعمال کرتی ہیں۔
NewConferenceLoadLimitBasisPoints (پہلے سے طے شدہ 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 - محفوظ۔


سسکو میٹنگ سرور میں صفات کے ساتھ LDAP سورس پیرامیٹرز کا نقشہ بنانا۔
LDAP میپنگ LDAP ڈائرکٹری میں موجود صفات کو CMS میں موجود صفات سے نقشہ بناتی ہے۔ اصل صفات:

• jidMapping
• نام کی نقشہ سازی
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

صفات کی تفصیلJID CMS میں صارف کی لاگ ان ID کی نمائندگی کرتا ہے۔ چونکہ یہ مائیکروسافٹ ایکٹو ڈائریکٹری LDAP سرور ہے، اس لیے CMS JID LDAP میں sAMAccountName سے نقشہ بناتا ہے، جو کہ بنیادی طور پر صارف کی ایکٹو ڈائریکٹری لاگ ان ID ہے۔ یہ بھی نوٹ کریں کہ آپ sAMAccountName لیتے ہیں اور اس کے آخر میں conf.pod6.cms.lab ڈومین شامل کرتے ہیں کیونکہ یہ وہ لاگ ان ہے جسے آپ کے صارفین CMS میں لاگ ان کرنے کے لیے استعمال کریں گے۔

نام کی نقشہ سازی ایکٹو ڈائرکٹری ڈسپلے نام کے فیلڈ میں جو کچھ ہے اسے صارف کے CMS نام والے فیلڈ سے ملاتا ہے۔

coSpaceNameMapping ڈسپلے نام فیلڈ کی بنیاد پر ایک CMS اسپیس نام بناتا ہے۔ یہ وصف، coSpaceUriMapping وصف کے ساتھ، ہر صارف کے لیے جگہ بنانے کے لیے ضروری ہے۔

coSpaceUriMapping صارف کی ذاتی جگہ سے وابستہ URI کے صارف حصے کی وضاحت کرتا ہے۔ کچھ ڈومینز کو اسپیس میں ڈائل کرنے کے لیے کنفیگر کیا جا سکتا ہے۔ اگر صارف کا حصہ ان ڈومینز میں سے کسی ایک کے لیے اس فیلڈ سے میل کھاتا ہے، تو کال کو اس صارف کی جگہ پر بھیج دیا جائے گا۔

coSpaceSecondaryUriMapping خلا تک پہنچنے کے لیے دوسرے URI کی وضاحت کرتا ہے۔ اس کو coSpaceUriMapping پیرامیٹر میں بیان کردہ حروف نمبری URI کے متبادل کے طور پر درآمد شدہ صارف کی جگہ پر کالوں کو روٹنگ کرنے کے لیے عددی عرف شامل کرنے کے لیے استعمال کیا جا سکتا ہے۔

LDAP سرور اور LDAP میپنگ ترتیب دی گئی ہے۔ اب آپ کو LDAP سورس بنا کر ان کو آپس میں جوڑنے کی ضرورت ہے۔

رسائی کے لیے URL کا استعمال کرنا cms01.example.com:445/api/v1/ldapSource ایک LDAP سورس آبجیکٹ تخلیق کرتا ہے، پیرامیٹرز کی وضاحت کرتا ہے جیسے:

• سرور
• تعریفیں
• بیس ڈی این
• فلٹر

اب جبکہ LDAP کنفیگریشن مکمل ہو چکی ہے، آپ دستی ہم وقت سازی کا عمل انجام دے سکتے ہیں۔

ہم اسے یا تو ہر سرور کے ویب انٹرفیس میں کلک کرکے کرتے ہیں۔ ابھی مطابقت پذیری کریں حصے ایکٹو ڈائریکٹری


یا کمانڈ کے ساتھ API کے ذریعے POST رسائی کے لیے یو آر ایل کا استعمال کرنا cms01.example.com:445/api/v1/ldapSyncs

ایڈہاک کانفرنسز

یہ سب کیا ہے؟روایتی تصور میں، کانفرنس اس وقت ہوتی ہے جب دو شرکاء آپس میں بات کر رہے ہوتے ہیں، اور شرکاء میں سے ایک (Unified CM کے ساتھ رجسٹرڈ ڈیوائس کا استعمال کرتے ہوئے) "کانفرنس" کا بٹن دباتا ہے، دوسرے شخص کو کال کرتا ہے، اور اس تیسرے فریق سے بات کرنے کے بعد۔ سہ فریقی کانفرنس میں تمام شرکاء میں شامل ہونے کے لیے دوبارہ "کانفرنس" کا بٹن دباتا ہے۔

ایڈ-ہاک کانفرنس کو CMS میں طے شدہ کانفرنس سے جو چیز ممتاز کرتی ہے وہ یہ ہے کہ Ad-Hoc کانفرنس CMS کو صرف ایک SIP کال نہیں ہے۔ جب کانفرنس کا آغاز کرنے والا ایک ہی میٹنگ میں سب کو مدعو کرنے کے لیے کانفرنس کے بٹن پر دوسری بار کلک کرتا ہے، تو یونیفائیڈ سی ایم کو سی ایم ایس کو ایک API کال کرنی چاہیے تاکہ ایک آن دی فلائی کانفرنس بنائی جا سکے جس کے بعد تمام کالیں منتقل ہو جاتی ہیں۔ یہ سب کچھ شرکا کی طرف سے کسی کا دھیان نہیں جاتا۔

اس کا مطلب ہے کہ یونیفائیڈ سی ایم کو کال جاری رکھنے کے لیے API کی اسناد اور ویب ایڈمن ایڈریس/سروس کے ساتھ ساتھ SIP ٹرنک کو براہ راست CMS سرور پر کنفیگر کرنا چاہیے۔

اگر ضروری ہو تو، CUCM متحرک طور پر CMS میں ایک جگہ بنا سکتا ہے تاکہ ہر کال CMS تک پہنچ سکے اور آنے والی کال کے اصول سے میل کھا سکے جو خالی جگہوں کے لیے ہے۔

CUCM کے ساتھ انضمام اسی طرح ترتیب دیا گیا جیسا کہ مضمون میں بیان کیا گیا ہے۔ پہلے سوائے اس کے کہ Cisco UCM پر آپ کو CMS کے لیے تین ٹرنک بنانے کی ضرورت ہے، تین کانفرنس برجز، SIP سیکیورٹی پروفائل میں تین موضوع کے نام، روٹ گروپس، روٹ لسٹ، میڈیا ریسورس گروپس اور میڈیا ریسورس گروپ لسٹیں بیان کریں، اور روٹنگ کے چند اصول شامل کریں۔ سسکو میٹنگ سرور پر۔

SIP سیکیورٹی پروفائل:


تنوں:


ہر ٹرنک ایک جیسا لگتا ہے:




کانفرنس پل


ہر کانفرنس برج ایک جیسا لگتا ہے:


روٹ گروپ


روٹ لسٹ


میڈیا ریسورس گروپ


میڈیا ریسورس گروپ کی فہرست

کال کے قواعد

زیادہ جدید کال مینجمنٹ سسٹمز جیسے کہ یونیفائیڈ سی ایم یا ایکسپریس وے کے برعکس، سی ایم ایس صرف نئی کالوں کے لیے SIP Request-URI فیلڈ میں ڈومین تلاش کرتا ہے۔ لہذا اگر SIP INVITE گھونٹ کے لئے ہے: [ای میل محفوظ]CMS صرف domain.com کی پرواہ کرتا ہے۔ CMS ان اصولوں پر عمل کرتا ہے تاکہ یہ تعین کیا جا سکے کہ کال کو کہاں روٹ کرنا ہے:

1. CMS سب سے پہلے SIP ڈومین کو آنے والی کال کے قواعد میں کنفیگر کردہ ڈومینز کے ساتھ ملانے کی کوشش کرتا ہے۔ ان کالز کو پھر ("ٹارگٹڈ") اسپیسز یا مخصوص صارفین، اندرونی IVRs، یا براہ راست مربوط 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 ٹرنک کو انفرادی طور پر ترتیب دے گا۔ اس بات پر منحصر ہے کہ آیا ان SIP ٹرنک کی منزل ایک IP ایڈریس ہے یا سرور کا FQDN اس بات کا تعین کرے گا کہ آیا CMS کو اس کے IP ایڈریس یا FQDN پر بھیجی گئی کالز کو قبول کرنے کے لیے کنفیگر کرنے کی ضرورت ہے۔

وہ ڈومین جس کی سب سے زیادہ ترجیح ان باؤنڈ اصول ہے کسی بھی صارف کی جگہوں کے لیے بطور ڈومین استعمال ہوتا ہے۔ جب صارفین LDAP کے ذریعے مطابقت پذیر ہوتے ہیں، تو CMS خود بخود خالی جگہیں بناتا ہے، لیکن URI (coSpaceUriMapping) کا صرف صارف حصہ، مثال کے طور پر user.space۔ حصہ ڈومین مکمل URI اس اصول کی بنیاد پر تیار کیا جاتا ہے۔ درحقیقت، اگر آپ اس مقام پر ویب برج میں لاگ ان ہوتے، تو آپ دیکھیں گے کہ اسپیس یو آر آئی کے پاس کوئی ڈومین نہیں ہے۔ اس اصول کو سب سے زیادہ ترجیح کے طور پر ترتیب دے کر، آپ تیار کردہ جگہوں کے لیے ڈومین ترتیب دے رہے ہیں confexample.com


آؤٹ گوئنگ کال کے قواعد

صارفین کو یونیفائیڈ سی ایم کلسٹر پر آؤٹ باؤنڈ کال کرنے کی اجازت دینے کے لیے، آپ کو آؤٹ باؤنڈ قوانین کو ترتیب دینا ہوگا۔ یونیفائیڈ سی ایم کے ساتھ رجسٹرڈ اینڈ پوائنٹس کا ڈومین، جیسے جببر، example.com ہے۔ اس ڈومین پر کالز کو معیاری SIP کالز کے طور پر یونیفائیڈ CM کال پروسیسنگ نوڈس پر روٹ کیا جانا چاہیے۔ مرکزی سرور cucm-01.example.com ہے، اور اضافی سرور cucm-02.example.com ہے۔

پہلا اصول کلسٹر سرورز کے درمیان کالوں کی آسان ترین روٹنگ کو بیان کرتا ہے۔

فیلڈ ڈومین سے مقامی "@" علامت کے بعد کال کیے جانے والے شخص کے لیے کال کرنے والے کے SIP-URI میں کیا دکھایا جائے گا اس کے لیے ذمہ دار ہے۔ اگر ہم اسے خالی چھوڑ دیتے ہیں، تو پھر "@" علامت کے بعد CUCM کا IP پتہ ہوگا جس سے یہ کال گزرتی ہے۔ اگر ہم ایک ڈومین کی وضاحت کرتے ہیں، تو پھر "@" علامت کے بعد اصل میں ایک ڈومین ہوگا۔ واپس کال کرنے کے قابل ہونے کے لیے یہ ضروری ہے، ورنہ SIP-URI name@ip-address کے ذریعے واپس کال کرنا ممکن نہیں ہوگا۔

مخصوص ہونے پر کال کریں۔ ڈومین سے مقامی


جب کال کریں۔ NOT اشارہ کیا ڈومین سے مقامی


آؤٹ گوئنگ کالز کے لیے واضح طور پر انکرپٹڈ یا غیر انکرپٹڈ کی وضاحت کرنا یقینی بنائیں، کیونکہ آٹو پیرامیٹر کے ساتھ کچھ بھی کام نہیں کرتا ہے۔

ریکارڈنگ

ویڈیو کانفرنسیں ریکارڈ سرور کے ذریعہ ریکارڈ کی جاتی ہیں۔ ریکارڈر بالکل ویسا ہی ہے جیسا کہ سسکو میٹنگ سرور۔ ریکارڈر کو کسی لائسنس کی تنصیب کی ضرورت نہیں ہے۔ کال برج سروسز چلانے والے سرورز کے لیے ریکارڈنگ لائسنس درکار ہیں، یعنی ایک ریکارڈنگ لائسنس درکار ہے اور اسے کال برج کے جزو پر لاگو کیا جانا چاہیے، نہ کہ ریکارڈر چلانے والے سرور پر۔ ریکارڈر ایک توسیعی پیغام رسانی اور موجودگی پروٹوکول (XMPP) کلائنٹ کے طور پر برتاؤ کرتا ہے، لہذا XMPP سرور کو CallBridge کی میزبانی کرنے والے سرور پر فعال ہونا چاہیے۔

کیونکہ ہمارے پاس ایک کلسٹر ہے اور لائسنس کو کلسٹر کے تینوں سرورز پر "تڑھا" جانے کی ضرورت ہے۔ پھر بس آپ کے ذاتی اکاؤنٹ میں ان لائسنسوں میں جو ہم کلسٹر میں شامل تمام CMS سرورز کے A-interfaces کے MAC ایڈریس کو منسلک (شامل) کرتے ہیں۔

اور یہ وہ تصویر ہے جو کلسٹر کے ہر سرور پر ہونی چاہیے۔

عام طور پر، ریکارڈر رکھنے کے کئی منظرنامے ہیں، لیکن ہم اس پر قائم رہیں گے:


ریکارڈر ترتیب دینے سے پہلے، آپ کو ایک ایسی جگہ تیار کرنے کی ضرورت ہے جہاں ویڈیو کانفرنسیں اصل میں ریکارڈ کی جائیں گی۔ دراصل یہاں لنک، تمام ریکارڈنگ کو کیسے ترتیب دیا جائے۔ میں اہم نکات اور تفصیلات پر توجہ مرکوز کرتا ہوں:

1. کلسٹر میں پہلے سرور سے سرٹیفکیٹ سلپ کرنا بہتر ہے۔
2. "ریکارڈر دستیاب نہیں" غلطی اس لیے ہو سکتی ہے کیونکہ ریکارڈر ٹرسٹ میں غلط سرٹیفکیٹ کی وضاحت کی گئی ہے۔
3. لکھنا کام نہیں کر سکتا اگر ریکارڈنگ کے لیے مخصوص کردہ NFS ڈائرکٹری روٹ ڈائریکٹری نہیں ہے۔

کبھی کبھی ایک مخصوص صارف یا جگہ کی کانفرنس کو خود بخود ریکارڈ کرنے کی ضرورت ہوتی ہے۔

اس کے لیے، دو کال پروفائلز بنائے گئے ہیں:
ریکارڈنگ کو غیر فعال کرنے کے ساتھ


اور خودکار ریکارڈنگ فنکشن کے ساتھ


اس کے بعد، ہم مطلوبہ جگہ پر ایک خودکار ریکارڈنگ فنکشن کے ساتھ ایک کال پروفائل کو "اٹیچ" کرتے ہیں۔


CMS میں یہ اس طرح قائم ہے کہ اگر کال پروفائل کو واضح طور پر کسی بھی اسپیس یا اسپیس سے جوڑا گیا ہے، تو یہ کال پروفائل صرف ان مخصوص اسپیس کے سلسلے میں کام کرتی ہے۔ اور اگر CallProfile کسی بھی اسپیس کا پابند نہیں ہے، تو پہلے سے طے شدہ طور پر یہ ان خالی جگہوں پر لاگو ہوتا ہے جن پر کوئی CallProfile واضح طور پر پابند نہیں ہے۔

اگلی بار میں یہ بیان کرنے کی کوشش کروں گا کہ تنظیم کے اندرونی نیٹ ورک سے باہر 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-اور بعد میں۔ پی ڈی ایف

ماخذ: www.habr.com