Cisco Meeting Server 2.5.2. დაჯგუფება მასშტაბირებადი და გამძლე რეჟიმში ვიდეო კონფერენციის ჩაწერის ფუნქციით

ამ ნომერში მე გაჩვენებ და აგიხსნით CMS სერვერის დაყენების რამდენიმე სირთულეს კლასტერულ რეჟიმში.


Теорияზოგადად, არსებობს სამი ტიპის CMS სერვერის განლაგება:

• ერთჯერადი კომბინირებული(ერთჯერადი კომბინირებული), ე.ი. ეს არის ერთი სერვერი, რომელზეც მუშაობს ყველა საჭირო სერვისი. უმეტეს შემთხვევაში, ამ ტიპის დანერგვა შესაფერისია მხოლოდ კლიენტის შიდა წვდომისთვის და უფრო მცირე გარემოში, სადაც ერთი სერვერის მასშტაბურობისა და ჭარბი შეზღუდვები არ არის კრიტიკული საკითხი, ან სიტუაციებში, როდესაც CMS ასრულებს მხოლოდ გარკვეულ ფუნქციებს, როგორიცაა ad hoc. კონფერენციები Cisco UCM-ზე.

  სამუშაოს სავარაუდო სქემა:
  

• ერთჯერადი გაყოფა(Single Split) აფართოებს წინა განლაგების ტიპს გარე წვდომისთვის ცალკე სერვერის დამატებით. ძველი განლაგებისას, ეს გულისხმობდა CMS სერვერის განთავსებას დემილიტარიზებულ ქსელის სეგმენტში (DMZ), სადაც გარე კლიენტებს შეეძლოთ მასზე წვდომა და ერთი CMS სერვერის ქსელის ბირთვში, სადაც შიდა კლიენტებს შეეძლოთ CMS-ზე წვდომა. განლაგების ამ კონკრეტულ მოდელს ახლა ე.წ Single Edge, რომელიც შედგება სერვერებისგან Cisco ჩქაროსნული გზა, რომლებსაც აქვთ ან ექნებათ იგივე Firewall-ის შემოვლითი შესაძლებლობები, ასე რომ კლიენტებს არ სჭირდებათ გამოყოფილი Edge CMS სერვერის დამატება.

  სამუშაოს სავარაუდო სქემა:
  

• მასშტაბირებადი და ელასტიური(სკალირებადი და შეცდომის ტოლერანტული) ეს ტიპი მოიცავს ზედმეტობას თითოეული კომპონენტისთვის, რაც საშუალებას აძლევს სისტემას გაიზარდოს თქვენი საჭიროებებით მაქსიმალურ სიმძლავრემდე და უზრუნველყოს ჭარბი რაოდენობა მარცხის შემთხვევაში. ის ასევე იყენებს Single Edge კონცეფციას უსაფრთხო გარე წვდომის უზრუნველსაყოფად. სწორედ ამ ტიპს განვიხილავთ ამ ეპიზოდში. თუ ჩვენ გვესმის, როგორ განვათავსოთ ამ ტიპის კლასტერი, ჩვენ არა მხოლოდ გავიგებთ სხვა ტიპის განლაგებას, არამედ შევძლებთ გავიგოთ როგორ შევქმნათ CMS სერვერების კლასტერები მოთხოვნის პოტენციური ზრდის დასაკმაყოფილებლად.

განლაგებამდე გადასვლამდე, თქვენ უნდა გესმოდეთ რამდენიმე ძირითადი რამ, კერძოდ

CMS პროგრამული უზრუნველყოფის ძირითადი კომპონენტები:

• მონაცემთა ბაზა: საშუალებას გაძლევთ დააკავშიროთ ზოგიერთი კონფიგურაცია, როგორიცაა აკრიფეთ გეგმა, მომხმარებლის სივრცეები და თავად მომხმარებლები. მხარს უჭერს კლასტერირებას მხოლოდ მაღალი ხელმისაწვდომობისთვის (ერთი ძირითადი).
• ზარის ხიდზე: სერვისი აუდიო და ვიდეო კონფერენციისთვის, რომელიც უზრუნველყოფს სრულ კონტროლს ზარებისა და მულტიმედიური პროცესების მართვასა და დამუშავებაზე. მხარს უჭერს კლასტერირებას მაღალი ხელმისაწვდომობისა და მასშტაბურობისთვის.
• XMPP სერვერი: პასუხისმგებელია კლიენტების რეგისტრაციასა და ავთენტიფიკაციაზე Cisco Meeting აპლიკაციის ან/და WebRTC-ის გამოყენებითრეალურ დროში კომუნიკაცია, ან უბრალოდ ბრაუზერში), ასევე კომპონენტთაშორისი სიგნალიზაცია. შეიძლება დაჯგუფდეს მხოლოდ მაღალი ხელმისაწვდომობისთვის.
• ვებ ხიდი: უზრუნველყოფს კლიენტის წვდომას WebRTC-ზე.
• დატვირთვის ბალანსერი: უზრუნველყოფს Cisco-ს შეხვედრის აპებისთვის ერთიანი კავშირის წერტილს Single Split რეჟიმში. უსმენს გარე ინტერფეისს და პორტს შემომავალი კავშირებისთვის. თანაბრად, დატვირთვის ბალანსერი იღებს შემომავალ TLS კავშირებს XMPP სერვერიდან, რომლის მეშვეობითაც მას შეუძლია გადართოს TCP კავშირები გარე კლიენტებისგან.
  ჩვენს სცენარში ეს არ იქნება საჭირო.
• TURN სერვერი: უზრუნველყოფს Firewall-ის შემოვლითი ტექნოლოგიას, რომელიც საშუალებას იძლევა
  მოათავსეთ ჩვენი CMS Firewall-ის ან NAT-ის მიღმა, რათა დააკავშიროთ გარე კლიენტები Cisco Meeting აპლიკაციის ან SIP მოწყობილობების გამოყენებით. ჩვენს სცენარში ეს არ იქნება საჭირო.
• ვებ ადმინი: ადმინისტრაციული ინტერფეისი და API წვდომა, მათ შორის სპეციალური ერთიანი CM კონფერენციებისთვის.

კონფიგურაციის რეჟიმები

Cisco-ს სხვა პროდუქტებისგან განსხვავებით, Cisco Meeting Server მხარს უჭერს კონფიგურაციის სამ მეთოდს ნებისმიერი ტიპის განლაგების დასაკმაყოფილებლად.

• ბრძანების ხაზი (CLI): ბრძანების ხაზის ინტერფეისი, რომელიც ცნობილია როგორც MMP საწყისი კონფიგურაციისა და სერტიფიკატის ამოცანებისთვის.
• ვებ ადმინისტრატორი: ძირითადად CallBridge-თან დაკავშირებული კონფიგურაციებისთვის, განსაკუთრებით ერთი არაკლასტერული სერვერის დაყენებისას.
• REST API: გამოიყენება ყველაზე რთული კონფიგურაციის ამოცანებისთვის და მონაცემთა ბაზის კლასტერული ამოცანებისთვის.

გარდა ზემოაღნიშნულისა, გამოიყენება პროტოკოლი SFTP ფაილების გადასატანად - ჩვეულებრივ ლიცენზიებს, სერთიფიკატებს ან ჟურნალებს - CMS სერვერზე და იქიდან.

Cisco-ს განლაგების სახელმძღვანელოებში თეთრად და ინგლისურად წერია, რომ კლასტერი უნდა განლაგდეს მინიმუმ სამი სერვერები (კვანძები) მონაცემთა ბაზების კონტექსტში. იმიტომ რომ მხოლოდ კენტი რაოდენობის კვანძებით იმუშავებს ახალი Database Master-ის შერჩევის მექანიზმი და ზოგადად Database Master-ს აქვს კავშირი CMS სერვერის მონაცემთა ბაზის უმეტესობასთან.

და როგორც პრაქტიკა გვიჩვენებს, ორი სერვერი (კვანძი) ნამდვილად არ არის საკმარისი. შერჩევის მექანიზმი მუშაობს Master-ის გადატვირთვისას, Slave სერვერი ხდება Master მხოლოდ გადატვირთული სერვერის ამოქმედების შემდეგ. თუმცა, თუ ორი სერვერისგან შემდგარი კლასტერში Master სერვერი მოულოდნელად გაქრება, მაშინ Slave სერვერი არ გახდება Master, ხოლო თუ Slave გადის, მაშინ დარჩენილი Master სერვერი გახდება Slave.

მაგრამ XMPP-ის კონტექსტში, ნამდვილად საჭირო იქნებოდა სამი სერვერის კლასტერის შეკრება, რადგან თუ, მაგალითად, გამორთავთ XMPP სერვისს ერთ-ერთ სერვერზე, რომელშიც XMMP არის ლიდერის სტატუსში, მაშინ დარჩენილ სერვერზე XMPP დარჩება Follower-ის სტატუსში და CallBridge კავშირები XMPP-თან გაქრება, რადგან CallBridge უკავშირდება ექსკლუზიურად XMPP-ს ლიდერის სტატუსით. და ეს კრიტიკულია, რადგან... არც ერთი ზარი არ გაივლის.

ასევე იმავე განლაგების სახელმძღვანელოში ნაჩვენებია კლასტერი ერთი XMPP სერვერით.

და ზემოაღნიშნულის გათვალისწინებით, ცხადი ხდება, რატომაც: მუშაობს იმიტომ, რომ ჩავარდნის რეჟიმშია.

ჩვენს შემთხვევაში, XMPP სერვერი იქნება სამივე კვანძზე.

ვარაუდობენ, რომ ჩვენი სამივე სერვერი მუშაობს.

DNS ჩანაწერები

სანამ სერვერების დაყენებას დაიწყებთ, თქვენ უნდა შექმნათ DNS ჩანაწერები А и SRV ტიპები:

გთხოვთ გაითვალისწინოთ, რომ ჩვენს DNS ჩანაწერებში არის ორი დომენი example.com და conf.example.com. Example.com არის დომენი, რომელიც Cisco Unified Communication Manager-ის ყველა აბონენტს შეუძლია გამოიყენოს თავისი URI-ებისთვის, რომელიც, სავარაუდოდ, თქვენს ინფრასტრუქტურაშია ან სავარაუდოდ იქნება. ან example.com ემთხვევა იმავე დომენს, რომელსაც მომხმარებლები იყენებენ ელფოსტის მისამართებისთვის. ან თქვენს ლეპტოპზე Jabber კლიენტს შეიძლება ჰქონდეს URI [ელ.ფოსტით დაცულია]. დომენი conf.example.com არის დომენი, რომელიც კონფიგურირებული იქნება Cisco Meeting Server-ის მომხმარებლებისთვის. Cisco Meeting Server-ის დომენი იქნება conf.example.com, ასე რომ, იგივე Jabber მომხმარებლისთვის, user@ URI უნდა იყოს გამოყენებული Cisco Meeting Server-ში შესასვლელადconf.example.com.

ძირითადი კონფიგურაცია

ქვემოთ აღწერილი ყველა პარამეტრი ნაჩვენებია ერთ სერვერზე, მაგრამ ისინი უნდა გაკეთდეს კლასტერში თითოეულ სერვერზე.

QoS

ვინაიდან CMS წარმოქმნის რეალურ დროში ტრაფიკი მგრძნობიარეა შეფერხებებისა და პაკეტის დაკარგვის მიმართ, უმეტეს შემთხვევაში რეკომენდებულია მომსახურების ხარისხის (QoS) კონფიგურაცია. ამის მისაღწევად, CMS მხარს უჭერს პაკეტების მონიშვნას მის მიერ გენერირებული დიფერენცირებული სერვისების კოდებით (DSCP). მიუხედავად იმისა, რომ 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 სერვერები თქვენს ინფრასტრუქტურას ბრძანებით, როგორიცაა

ntp server add <server>

ჩვენს შემთხვევაში, ორი ასეთი სერვერია, ამიტომ იქნება ორი გუნდი.
ჩვენ შეამოწმოთ:

და დააყენეთ ჩვენი სერვერის დროის ზონა

DNS

ჩვენ ვამატებთ DNS სერვერებს CMS-ში ბრძანებით, როგორიცაა:

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

ჩვენს შემთხვევაში, ორი ასეთი სერვერია, ამიტომ იქნება ორი გუნდი.
ჩვენ შეამოწმოთ:

ქსელის ინტერფეისის კონფიგურაცია

ჩვენ ვაკონფიგურირებთ ინტერფეისს ბრძანებით, როგორიცაა:

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

ჩვენ შეამოწმოთ:

სერვერის სახელი (ჰოსტის სახელი)

ჩვენ დავაყენეთ სერვერის სახელი ბრძანებით, როგორიცაა:

hostname <name>

და ჩვენ გადატვირთეთ.


ეს ასრულებს ძირითად კონფიგურაციას.

სერტიფიკატი

ТеорияCisco Meeting Server მოითხოვს დაშიფრულ კომუნიკაციას სხვადასხვა კომპონენტებს შორის და, შედეგად, X.509 სერთიფიკატები საჭიროა CMS-ის ყველა განლაგებისთვის. ისინი უზრუნველყოფენ, რომ სერვისები/სერვერები ენდობიან სხვა სერვერებს/სერვისებს.

თითოეული სერვისი მოითხოვს სერთიფიკატს, მაგრამ თითოეული სერვისისთვის ცალკე სერტიფიკატების შექმნამ შეიძლება გამოიწვიოს დაბნეულობა და არასაჭირო სირთულე. საბედნიეროდ, ჩვენ შეგვიძლია სერთიფიკატის საჯარო-კერძო გასაღების წყვილის გენერირება და შემდეგ მათი ხელახლა გამოყენება მრავალ სერვისში. ჩვენს შემთხვევაში, იგივე სერტიფიკატი იქნება გამოყენებული Call Bridge, XMPP სერვერი, Web Bridge და Web Admin. ამრიგად, თქვენ უნდა შექმნათ წყვილი საჯარო და პირადი სერტიფიკატის გასაღებები კლასტერში თითოეული სერვერისთვის.

თუმცა, მონაცემთა ბაზის კლასტერირებას აქვს გარკვეული სპეციალური სერტიფიკატის მოთხოვნები და, შესაბამისად, მოითხოვს საკუთარ სერტიფიკატებს, რომლებიც განსხვავდება სხვა სერვისებისგან. CMS იყენებს სერვერის სერთიფიკატს, რომელიც მსგავსია სხვა სერვერების მიერ გამოყენებული სერთიფიკატებისა, მაგრამ ასევე არსებობს კლიენტის სერთიფიკატი, რომელიც გამოიყენება მონაცემთა ბაზის კავშირებისთვის. მონაცემთა ბაზის სერთიფიკატები გამოიყენება როგორც ავთენტიფიკაციისთვის, ასევე დაშიფვრისთვის. იმის ნაცვლად, რომ კლიენტს მიაწოდოს მომხმარებლის სახელი და პაროლი მონაცემთა ბაზასთან დასაკავშირებლად, ის წარმოადგენს კლიენტის სერტიფიკატს, რომელსაც ენდობა სერვერი. მონაცემთა ბაზის კლასტერში თითოეული სერვერი გამოიყენებს იმავე საჯარო და კერძო გასაღების წყვილს. ეს საშუალებას აძლევს კლასტერში არსებულ ყველა სერვერს დაშიფვრონ მონაცემები ისე, რომ მათი გაშიფვრა შესაძლებელია მხოლოდ სხვა სერვერების მიერ, რომლებიც ასევე იზიარებენ იმავე გასაღების წყვილს.

ზედმეტობამ რომ იმუშაოს, მონაცემთა ბაზის კლასტერები უნდა შედგებოდეს მინიმუმ 3 სერვერისგან, მაგრამ არაუმეტეს 5-ისა, კლასტერის ნებისმიერ წევრს შორის მაქსიმალური ორმხრივი მოგზაურობის დრო 200 ms. ეს ლიმიტი უფრო შემზღუდველია, ვიდრე ზარის ხიდის კლასტერირება, ამიტომ ის ხშირად არის შემზღუდველი ფაქტორი გეოგრაფიულად განაწილებულ განლაგებაში.

CMS-ის მონაცემთა ბაზის როლს აქვს მრავალი უნიკალური მოთხოვნა. სხვა როლებისგან განსხვავებით, ის მოითხოვს კლიენტისა და სერვერის სერთიფიკატს, სადაც კლიენტის სერტიფიკატს აქვს კონკრეტული CN ველი, რომელიც წარმოდგენილია სერვერზე.

CMS იყენებს postgres მონაცემთა ბაზას ერთი ძირითადი და რამდენიმე სრულიად იდენტური რეპლიკა. არსებობს მხოლოდ ერთი პირველადი მონაცემთა ბაზა ერთდროულად ("მონაცემთა ბაზის სერვერი"). კლასტერის დარჩენილი წევრები არიან რეპლიკა ან „მონაცემთა ბაზის კლიენტები“.

მონაცემთა ბაზის კლასტერს სჭირდება გამოყოფილი სერვერის სერთიფიკატი და კლიენტის სერტიფიკატი. ისინი უნდა იყოს ხელმოწერილი სერტიფიკატების მიერ, როგორც წესი, შიდა კერძო სერტიფიკატის ორგანო. იმის გამო, რომ მონაცემთა ბაზის კლასტერის ნებისმიერი წევრი შეიძლება გახდეს ოსტატი, მონაცემთა ბაზის სერვერისა და კლიენტის სერტიფიკატის წყვილი (რომელიც შეიცავს საჯარო და კერძო კლავიშებს) უნდა დაკოპირდეს ყველა სერვერზე, რათა მათ შეძლონ კლიენტის ან მონაცემთა ბაზის სერვერის იდენტურობა. გარდა ამისა, CA root სერთიფიკატი უნდა იყოს ჩატვირთული, რათა უზრუნველყოს კლიენტისა და სერვერის სერთიფიკატების შემოწმება.

ასე რომ, ჩვენ ვქმნით მოთხოვნას სერტიფიკატზე, რომელსაც გამოიყენებს ყველა სერვერის სერვისი, გარდა მონაცემთა ბაზისა (ამისთვის ცალკე მოთხოვნა იქნება) ბრძანებით, როგორიცაა:

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

CN-ში ჩვენ ვწერთ ჩვენი სერვერების ზოგად სახელს. მაგალითად, თუ ჩვენი სერვერების ჰოსტების სახელები სერვერი 01, სერვერი 02, სერვერი 03, მაშინ CN იქნება server.example.com

ჩვენ იგივეს ვაკეთებთ დანარჩენ ორ სერვერზე იმ განსხვავებით, რომ ბრძანებები შეიცავს შესაბამის „ჰოსტის სახელებს“

ჩვენ ვქმნით ორ მოთხოვნას სერთიფიკატებზე, რომლებსაც გამოიყენებს მონაცემთა ბაზის სერვისი ბრძანებებით, როგორიცაა:

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

pki csr dbclusterclient CN:postgres

სადაც dbclusterserver и dbclusterclient ჩვენი მოთხოვნების სახელები და მომავალი სერთიფიკატები, ჰოსტის სახელი1(2)(3) შესაბამისი სერვერების სახელები.

ჩვენ ამ პროცედურას ვასრულებთ მხოლოდ ერთ სერვერზე (!) და სერთიფიკატებს და შესაბამის .key ფაილებს ავტვირთავთ სხვა სერვერებზე.

ჩართეთ კლიენტის სერტიფიკატის რეჟიმი AD CS-ში

თქვენ ასევე უნდა გააერთიანოთ თითოეული სერვერის სერთიფიკატები ერთ ფაილში.*NIX-ზე:

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

Windows/DOS-ზე:

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

და ატვირთეთ თითოეულ სერვერზე:
1. "ინდივიდუალური" სერვერის სერთიფიკატი.
2. ძირეული მოწმობა (შუალედურებთან ერთად, ასეთის არსებობის შემთხვევაში).
3. მონაცემთა ბაზის სერთიფიკატები („სერვერი“ და „კლიენტი“) და ფაილები .key გაფართოებით, რომლებიც წარმოიქმნა „სერვერის“ და „კლიენტის“ მონაცემთა ბაზის სერთიფიკატების მოთხოვნის შექმნისას. ეს ფაილები ყველა სერვერზე ერთნაირი უნდა იყოს.
4. სამივე „ინდივიდუალური“ მოწმობის ფაილი.

შედეგად, თქვენ უნდა მიიღოთ მსგავსი ფაილის სურათი თითოეულ სერვერზე.

მონაცემთა ბაზის კლასტერი

ახლა, როდესაც თქვენ გაქვთ ყველა სერთიფიკატი ატვირთული CMS სერვერებზე, შეგიძლიათ დააკონფიგურიროთ და ჩართოთ მონაცემთა ბაზის კლასტერირება სამ კვანძს შორის. პირველი ნაბიჯი არის მონაცემთა ბაზის კლასტერის მთავარ კვანძად ერთი სერვერის არჩევა და მისი სრული კონფიგურაცია.

სამაგისტრო მონაცემთა ბაზა

მონაცემთა ბაზის რეპლიკაციის დაყენების პირველი ნაბიჯი არის სერთიფიკატების მითითება, რომლებიც გამოყენებული იქნება მონაცემთა ბაზაში. ეს კეთდება ბრძანების გამოყენებით, როგორიცაა:

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

ახლა მოდით ვუთხრათ CMS-ს, რომელი ინტერფეისი გამოიყენოს მონაცემთა ბაზის კლასტერირებისთვის ბრძანებით:

database cluster localnode a

შემდეგ ჩვენ ვაწარმოებთ კლასტერული მონაცემთა ბაზის ინიციალიზაციას მთავარ სერვერზე ბრძანებით:

database cluster initialize

კლიენტის მონაცემთა ბაზის კვანძები

ჩვენ ვაკეთებთ იგივე პროცედურას, მხოლოდ ბრძანების ნაცვლად მონაცემთა ბაზის კლასტერის ინიციალიზაცია შეიყვანეთ ბრძანება, როგორიცაა:

database cluster join <ip address existing master>

სადაც ip მისამართი CMS სერვერის არსებული სამაგისტრო IP მისამართი, რომელზედაც მოხდა კლასტერის ინიციალიზაცია, უბრალოდ Master.

ჩვენ ვამოწმებთ, თუ როგორ მუშაობს ჩვენი მონაცემთა ბაზის კლასტერი ყველა სერვერზე ბრძანებით:

database cluster status

ჩვენ იგივეს ვაკეთებთ დანარჩენ მესამე სერვერზე.

შედეგად, გამოდის, რომ ჩვენი პირველი სერვერი არის Master, დანარჩენები არიან Slaves.

ვებ ადმინისტრატორის სერვისი

ჩართეთ ვებ ადმინისტრატორის სერვისი:

webadmin listen a 445

პორტი 445 არჩეულია, რადგან პორტი 443 გამოიყენება ვებ კლიენტზე მომხმარებლის წვდომისთვის

ჩვენ ვაკონფიგურირებთ ვებ ადმინისტრატორის სერვისს სერტიფიკატის ფაილებით ბრძანებით, როგორიცაა:

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

და ჩართეთ ვებ ადმინისტრატორი ბრძანებით:

webadmin enable

თუ ყველაფერი კარგადაა, ჩვენ მივიღებთ SUCCESS ხაზებს, რომლებიც მიუთითებს იმაზე, რომ ვებ ადმინისტრატორი სწორად არის კონფიგურირებული ქსელისთვის და სერტიფიკატისთვის. ჩვენ ვამოწმებთ სერვისის ფუნქციონირებას ვებ ბრაუზერის გამოყენებით და ვწერთ ვებ ადმინისტრატორის მისამართს, მაგალითად: cms.example.com: 445

ზარის ხიდის კლასტერი

Call Bridge არის ერთადერთი სერვისი, რომელიც იმყოფება CMS-ის ყველა დანერგვაში. Call Bridge არის მთავარი საკონფერენციო მექანიზმი. ის ასევე უზრუნველყოფს SIP ინტერფეისს ისე, რომ ზარები შეიძლება განხორციელდეს მასში ან იქიდან, მაგალითად, Cisco Unified CM-ით.

ქვემოთ აღწერილი ბრძანებები უნდა შესრულდეს თითოეულ სერვერზე შესაბამისი სერთიფიკატებით.
ასე რომ:

ჩვენ ვუკავშირებთ სერთიფიკატებს Call Bridge სერვისთან ბრძანებით, როგორიცაა:

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

ჩვენ ვაკავშირებთ CallBridge სერვისებს ჩვენთვის საჭირო ინტერფეისთან ბრძანებით:

callbridge listen a

და გადატვირთეთ სერვისი ბრძანებით:

callbridge restart

ახლა, როდესაც ჩვენ გვაქვს ჩვენი ზარის ხიდების კონფიგურაცია, შეგვიძლია დავაკონფიგურიროთ ზარის ხიდის კლასტერირება. Call Bridge კლასტერირება განსხვავდება მონაცემთა ბაზის ან XMPP კლასტერინგისგან. Call Bridge Cluster-ს შეუძლია 2-დან 8-მდე კვანძის მხარდაჭერა ყოველგვარი შეზღუდვის გარეშე. ის უზრუნველყოფს არა მხოლოდ ზედმეტობას, არამედ დატვირთვის დაბალანსებას, რათა კონფერენციები აქტიურად განაწილდეს Call Bridge სერვერებზე ინტელექტუალური ზარის განაწილების გამოყენებით. CMS-ს აქვს დამატებითი ფუნქციები, Call Bridge ჯგუფები და დაკავშირებული ფუნქციები, რომლებიც შეიძლება გამოყენებულ იქნას შემდგომი მართვისთვის.

ზარების ხიდის კლასტერირება ძირითადად კონფიგურირებულია ვებ ადმინისტრატორის ინტერფეისის საშუალებით
ქვემოთ აღწერილი პროცედურა უნდა განხორციელდეს კლასტერში თითოეულ სერვერზე.
აქედან გამომდინარე,

1. გადადით ინტერნეტში კონფიგურაცია > კლასტერი.
2. In დარეკეთ ხიდის ვინაობაზე როგორც უნიკალური სახელი, შეიყვანეთ callbridge[01,02,03], რომელიც შეესაბამება სერვერის სახელს. ეს სახელები თვითნებურია, მაგრამ უნდა იყოს უნიკალური ამ კლასტერისთვის. ისინი აღწერითი ხასიათისაა, რადგან ისინი მიუთითებენ, რომ ისინი არიან სერვერის იდენტიფიკატორები [01,02,03].
3.ბ კლასტერული ზარის ხიდები შეიყვანეთ ჩვენი სერვერების ვებ ადმინისტრატორის URL კლასტერში, CMS[01,02,03].example.com:445, მისამართის ველში. აუცილებლად მიუთითეთ პორტი. შეგიძლიათ დატოვოთ Peer link SIP დომენი ცარიელი.
4. დაამატეთ სერთიფიკატი თითოეული სერვერის CallBridge ტრასტს, რომლის ფაილი შეიცავს ჩვენი სერვერების ყველა სერთიფიკატს, რომელიც ჩვენ გავაერთიანეთ ამ ფაილში თავიდანვე, ბრძანებით, როგორიცაა:

callbridge trust cluster <trusted cluster certificate bundle>

და გადატვირთეთ სერვისი ბრძანებით:

callbridge restart

შედეგად, თითოეულ სერვერზე უნდა მიიღოთ ეს სურათი:

XMPP კლასტერი

XMPP სერვისი CMS-ში გამოიყენება Cisco Meeting Apps (CMA) ყველა რეგისტრაციისა და ავთენტიფიკაციისთვის, CMA WebRTC ვებ კლიენტის ჩათვლით. თავად Call Bridge ასევე მოქმედებს როგორც 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? ჩვენს კონკრეტულ გავრცელებაში, ჩვენ შევარჩიეთ ჩვენი ერთიანი CM დომენი, რომელსაც Jabber-ის მომხმარებლები გამოიყენებენ Unified CM-ში, როგორც example.com, ამიტომ გვჭირდებოდა სხვა დომენი CMS მომხმარებლებისთვის, რათა გადაეგდო ზარები CMS-დან და SIP დომენებიდან.

დააყენეთ XMPP დომენი ბრძანების გამოყენებით, როგორიცაა:

xmpp domain <domain>

და ჩართეთ XMPP სერვისი ბრძანებით:

xmpp enable

XMPP სერვისში თქვენ უნდა შექმნათ რწმუნებათა სიგელები თითოეული Call Bridge-ისთვის, რომელიც გამოყენებული იქნება XMPP სერვისში რეგისტრაციისას. ეს სახელები თვითნებურია (და არ არის დაკავშირებული იმ უნიკალურ სახელებთან, რომლებიც დააკონფიგურირეთ ზარის ხიდის კლასტერიზაციისთვის). თქვენ უნდა დაამატოთ სამი ზარის ხიდი ერთ XMPP სერვერზე და შემდეგ შეიყვანოთ ეს რწმუნებათა სიგელები სხვა XMPP სერვერებზე კლასტერში, რადგან ეს კონფიგურაცია არ ჯდება კლასტერულ მონაცემთა ბაზაში. მოგვიანებით ჩვენ დავაკონფიგურირებთ თითოეულ Call Bridge-ს, რათა გამოიყენოს ეს სახელი და საიდუმლო XMPP სერვისში დასარეგისტრირებლად.

ახლა ჩვენ გვჭირდება XMPP სერვისის კონფიგურაცია პირველ სერვერზე სამი Call Bridges callbridge01, callbridge02 და callbridge03. თითოეულ ანგარიშს მიენიჭება შემთხვევითი პაროლები. ისინი მოგვიანებით შეიყვანება სხვა Call Bridge სერვერებზე ამ 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 კლასტერი მუშაობს, თქვენ უნდა დააკონფიგურიროთ Call Bridge სერვისები XMPP კლასტერთან დასაკავშირებლად. ეს კონფიგურაცია ხდება ვებ ადმინისტრატორის მეშვეობით.

თითოეულ სერვერზე გადადით კონფიგურაცია > ზოგადი და ველში უნიკალური ზარის ხიდის სახელი დაწერეთ უნიკალური Call Bridge სახელები, რომლებიც შეესაბამება სერვერს ქოლბრიჯი[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 ჩანაწერის პრიორიტეტულ პარამეტრებზე.

შემდეგი, გადადით სტატუსი > ზოგადი, რათა შეამოწმოთ არის თუ არა Call Bride სერვისი წარმატებით დაკავშირებული XMPP სერვისთან.

ვებ ხიდი

კლასტერში თითოეულ სერვერზე ჩართეთ Web Bridge სერვისი ბრძანებით:

webbridge listen a:443

ჩვენ ვაკონფიგურირებთ Web Bridge სერვისს სერტიფიკატის ფაილებით ბრძანებით, როგორიცაა:

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

ვებ ხიდი მხარს უჭერს HTTPS-ს. ის გადამისამართებს HTTP-ს HTTPS-ზე, თუ კონფიგურირებულია "http-გადამისამართების" გამოსაყენებლად.
HTTP გადამისამართების ჩასართავად გამოიყენეთ შემდეგი ბრძანება:

webbridge http-redirect enable

იმისათვის, რომ აცნობოთ Call Bridge-ს, რომ Web Bridge-ს შეუძლია ენდოს კავშირებს Call Bridge-დან, გამოიყენეთ ბრძანება:

webbridge trust <certfile>

სადაც ეს არის ფაილი, რომელიც შეიცავს სამივე სერთიფიკატს კლასტერის თითოეული სერვერიდან.

ეს სურათი უნდა იყოს კლასტერის ყველა სერვერზე.


ახლა ჩვენ უნდა შევქმნათ მომხმარებელი "appadmin" როლით, ჩვენ გვჭირდება ის, რომ ჩვენ შეგვიძლია დავაკონფიგურიროთ ჩვენი კლასტერი(!), და არა თითოეული სერვერი კლასტერში ცალ-ცალკე, ამ გზით პარამეტრები თანაბრად იქნება გამოყენებული თითოეულ სერვერზე, მიუხედავად იმისა. ფაქტია, რომ ისინი ერთხელ დამზადდება.


შემდგომი დაყენებისთვის ჩვენ გამოვიყენებთ ფოსტალიონი.

ავტორიზაციისთვის აირჩიეთ ძირითადი ავტორიზაციის განყოფილებაში

CMS სერვერზე ბრძანებების სწორად გასაგზავნად, თქვენ უნდა დააყენოთ საჭირო კოდირება

ჩვენ ვაზუსტებთ Webbridge-ს ბრძანებით POST პარამეტრით URL და მნიშვნელობა cms.example.com



თავად ვებ ბრიჯში ჩვენ მივუთითებთ საჭირო პარამეტრებს: სტუმრის წვდომა, დაცული წვდომა და ა.შ.

დარეკეთ Bridge Groups

ნაგულისხმევად, CMS ყოველთვის არ იყენებს მისთვის ხელმისაწვდომ საკონფერენციო რესურსებს მაქსიმალურად ეფექტურად.

მაგალითად, სამი მონაწილესთან შეხვედრისთვის, თითოეული მონაწილე შეიძლება დასრულდეს სამ სხვადასხვა ზარის ხიდზე. იმისათვის, რომ ამ სამმა მონაწილემ შეძლოს ერთმანეთთან კომუნიკაცია, Call Bridges ავტომატურად დაამყარებს კავშირებს ყველა სერვერსა და კლიენტს შორის იმავე სივრცეში, ისე, რომ ყველაფერი ისე გამოიყურება, თითქოს ყველა კლიენტი ერთ სერვერზეა. სამწუხაროდ, ამის უარყოფითი მხარე ის არის, რომ ერთი 3 კაციანი კონფერენცია ახლა მოიხმარს 9 მედია პორტს. ეს აშკარად რესურსების არაეფექტური გამოყენებაა. გარდა ამისა, როდესაც ზარის ხიდი ნამდვილად გადატვირთულია, ნაგულისხმევი მექანიზმი არის ზარების მიღების გაგრძელება და ამ ზარის ხიდის ყველა აბონენტისთვის დაბალი ხარისხის სერვისის მიწოდება.

ეს პრობლემები მოგვარებულია Call Bridge Group ფუნქციის გამოყენებით. ეს ფუნქცია დაინერგა Cisco Meeting Server პროგრამული უზრუნველყოფის 2.1 ვერსიაში და გაფართოვდა დატვირთვის დაბალანსების მხარდასაჭერად, როგორც შემომავალი, ასევე გამავალი Cisco Meeting App (CMA) ზარებისთვის, WebRTC მონაწილეების ჩათვლით.

ხელახლა დაკავშირების პრობლემის გადასაჭრელად, შემოღებულ იქნა სამი რეგულირებადი დატვირთვის ლიმიტი თითოეული ზარის ხიდისთვის:

დატვირთვის ლიმიტი — ეს არის მაქსიმალური რიცხვითი დატვირთვა კონკრეტული Call Bridge-ისთვის. თითოეულ პლატფორმას აქვს რეკომენდებული დატვირთვის ლიმიტი, როგორიცაა 96000 CMS1000-ისთვის და 1.25 GHz თითო vCPU-ზე ვირტუალური აპარატისთვის. სხვადასხვა ზარი მოიხმარს რესურსების გარკვეულ რაოდენობას, რაც დამოკიდებულია მონაწილის გარჩევადობასა და კადრების სიხშირეზე.
NewConferenceLoadLimitBasisPoints (ნაგულისხმევი 50% loadLimit) - ადგენს სერვერის დატვირთვის ლიმიტს, რის შემდეგაც ახალი კონფერენციები უარყოფილია.
ExistingConferenceLoadLimitBasisPoints (ნაგულისხმევი loadLimit-ის 80%) - სერვერის დატვირთვის მნიშვნელობა, რის შემდეგაც მონაწილეები, რომლებიც შეუერთდებიან არსებულ კონფერენციას, უარყოფილი იქნებიან.

მიუხედავად იმისა, რომ ეს ფუნქცია შექმნილია ზარის განაწილებისა და დატვირთვის დაბალანსებისთვის, სხვა ჯგუფები, როგორიცაა TURN სერვერები, ვებ ხიდის სერვერები და ჩამწერები, ასევე შეიძლება მიენიჭოს Call Bridge ჯგუფებს, რათა მათ ასევე სათანადოდ დაჯგუფდეს ოპტიმალური გამოყენებისთვის. თუ რომელიმე ამ ობიექტს არ აქვს მინიჭებული ზარის ჯგუფი, ითვლება, რომ ისინი ხელმისაწვდომი იქნება ყველა სერვერისთვის რაიმე განსაკუთრებული პრიორიტეტის გარეშე.

ეს პარამეტრები აქ არის კონფიგურირებული: cms.example.com:445/api/v1/system/configuration/cluster

შემდეგ თითოეულ ქოლხიდს მივუთითებთ, რომელ ხიდის ჯგუფს ეკუთვნის:

პირველი ქოლხიდი

მეორე ქოლხიდი

მესამე ხიდი


ამრიგად, ჩვენ დავაყენეთ Call Brdige ჯგუფი, რათა უფრო ეფექტურად გამოიყენოს Cisco Meeting Server კლასტერის რესურსები.

მომხმარებლების იმპორტი Active Directory-დან

ვებ ადმინისტრატორის სერვისს აქვს LDAP კონფიგურაციის განყოფილება, მაგრამ ის არ იძლევა კომპლექსურ კონფიგურაციის ვარიანტებს და ინფორმაცია არ ინახება კლასტერულ მონაცემთა ბაზაში, ამიტომ კონფიგურაცია უნდა განხორციელდეს, ან ხელით თითოეულ სერვერზე ვებ ინტერფეისის მეშვეობით, ან API და ისე, რომ ჩვენ "სამჯერ "არ ადგეთ", ჩვენ მაინც დავაყენებთ მონაცემებს API-ის მეშვეობით.

URL-ის გამოყენება წვდომისთვის cms01.example.com:445/api/v1/ldapServers ქმნიან LDAP სერვერის ობიექტს, რომელშიც მითითებულია ისეთი პარამეტრები, როგორიცაა:

• სერვერის IP
• პორტის ნომერი
• მომხმარებლის სახელი
• დაგავიწყდათ
• უზრუნველყოს

უსაფრთხო - აირჩიეთ true ან false პორტის მიხედვით, 389 - არაუსაფრთხო, 636 - დაცული.


LDAP წყაროს პარამეტრების დახატვა ატრიბუტებზე Cisco Meeting Server-ში.
LDAP რუკა ასახავს LDAP დირექტორიაში არსებულ ატრიბუტებს CMS-ის ატრიბუტებთან. რეალური ატრიბუტები:

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

ატრიბუტების აღწერაIADB წარმოადგენს მომხმარებლის შესვლის ID-ს CMS-ში. ვინაიდან ეს არის Microsoft Active Directory LDAP სერვერი, CMS JID ასახავს sAMAccountName-ს LDAP-ში, რომელიც არსებითად არის მომხმარებლის Active Directory შესვლის ID. ასევე გაითვალისწინეთ, რომ აიღებთ sAMAccountName-ს და დაამატეთ დომენი conf.pod6.cms.lab მის ბოლოს, რადგან ეს არის შესვლა, რომელსაც გამოიყენებენ თქვენი მომხმარებლები CMS-ში შესასვლელად.

nameMapping ემთხვევა რასაც შეიცავს Active Directory displayName ველი მომხმარებლის CMS სახელის ველს.

coSpaceNameMapping ქმნის CMS სივრცის სახელს displayName ველზე დაყრდნობით. ეს ატრიბუტი, coSpaceUriMapping ატრიბუტთან ერთად, არის ის, რაც საჭიროა თითოეული მომხმარებლისთვის სივრცის შესაქმნელად.

coSpaceUriMapping განსაზღვრავს URI-ის მომხმარებლის ნაწილს, რომელიც დაკავშირებულია მომხმარებლის პირად სივრცესთან. ზოგიერთი დომენის კონფიგურაცია შესაძლებელია სივრცეში აკრეფის მიზნით. თუ მომხმარებლის ნაწილი ემთხვევა ამ ველს რომელიმე ამ დომენისთვის, ზარი მიმართული იქნება ამ მომხმარებლის სივრცეში.

coSpaceSecondaryUriMapping განსაზღვრავს მეორე URI-ს სივრცეში მისასვლელად. ეს შეიძლება გამოყენებულ იქნას იმპორტირებული მომხმარებლის სივრცეში ზარების მარშრუტირებისთვის ციფრული მეტსახელის დასამატებლად, როგორც ალფანუმერული URI-ის ალტერნატივა, რომელიც განსაზღვრულია coSpaceUriMapping პარამეტრში.

LDAP სერვერი და LDAP რუკების კონფიგურაციაა. ახლა თქვენ უნდა დააკავშიროთ ისინი ერთმანეთთან LDAP წყაროს შექმნით.

URL-ის გამოყენება წვდომისთვის cms01.example.com:445/api/v1/ldapSource შექმენით LDAP Source ობიექტი, რომელშიც მითითებულია ისეთი პარამეტრები, როგორიცაა:

• სერვერზე
• რუკების
• ბაზადნ
• გავფილტროთ

ახლა, როდესაც LDAP-ის კონფიგურაცია დასრულდა, შეგიძლიათ შეასრულოთ ხელით სინქრონიზაციის ოპერაცია.

ჩვენ ამას ვაკეთებთ ან თითოეული სერვერის ვებ ინტერფეისში დაწკაპუნებით ახლა სინქრონიზაცია სექციაში Active Directory


ან API-ის მეშვეობით ბრძანებით POST URL-ის გამოყენებით წვდომისთვის cms01.example.com:445/api/v1/ldapSyncs

Ad-Hoc კონფერენციები

რა არის ეს?ტრადიციულ კონცეფციაში, კონფერენცია არის, როდესაც ორი მონაწილე ესაუბრება ერთმანეთს და ერთ-ერთი მონაწილე (Unified CM-ში რეგისტრირებული მოწყობილობის გამოყენებით) აჭერს ღილაკს "კონფერენცია", ურეკავს მეორეს და ამ მესამე მხარეს ესაუბრება. , კვლავ დააჭირეთ ღილაკს "კონფერენცია" სამმხრივ კონფერენციაში ყველა მონაწილეს რომ შეუერთდეს.

ის, რაც განასხვავებს Ad-Hoc კონფერენციას დაგეგმილი კონფერენციისგან CMS-ში არის ის, რომ Ad-Hoc კონფერენცია არ არის მხოლოდ SIP ზარი CMS-ზე. როდესაც კონფერენციის ინიციატორი მეორედ დააჭერს კონფერენციის ღილაკს, რათა მოიწვიოს ყველა ერთსა და იმავე შეხვედრაზე, Unified CM-მა უნდა განახორციელოს API ზარი CMS-ზე, რათა შექმნას ფრენის კონფერენცია, რომელზეც შემდეგ ყველა ზარი გადაიცემა. ეს ყველაფერი მონაწილეთათვის შეუმჩნევლად ხდება.

ეს ნიშნავს, რომ Unified CM უნდა დააკონფიგურიროთ API სერთიფიკატები და სერვისის WebAdmin მისამართი/პორტი, ისევე როგორც SIP Trunk პირდაპირ CMS სერვერზე ზარის გასაგრძელებლად.

საჭიროების შემთხვევაში, CUCM-ს შეუძლია დინამიურად შექმნას სივრცე CMS-ში, რათა თითოეულმა ზარმა მიაღწიოს CMS-ს და შეესაბამებოდეს შემომავალი ზარის წესს, რომელიც განკუთვნილია სივრცეებისთვის.

ინტეგრაცია CUCM-თან კონფიგურირებულია ისევე, როგორც სტატიაში აღწერილი ადრე გარდა იმისა, რომ Cisco UCM-ზე თქვენ უნდა შექმნათ სამი საყრდენი CMS-ისთვის, სამი საკონფერენციო ხიდი, SIP უსაფრთხოების პროფილში მიუთითეთ სამი საგნის სახელი, მარშრუტების ჯგუფები, მარშრუტების სია, მედია რესურსების ჯგუფები და მედია რესურსების ჯგუფების სია, და დაამატეთ მარშრუტიზაციის რამდენიმე წესი. Cisco Meeting სერვერზე.

SIP უსაფრთხოების პროფილი:


ჩემოდნები:


თითოეული საყრდენი ერთნაირად გამოიყურება:




საკონფერენციო ხიდი


თითოეული საკონფერენციო ხიდი ერთნაირად გამოიყურება:


მარშრუტების ჯგუფი


მარშრუტების სია


მედია რესურს ჯგუფი


მედია რესურსების ჯგუფის სია

ზარის წესები

ზარების მართვის უფრო მოწინავე სისტემებისგან განსხვავებით, როგორიცაა Unified CM ან Expressway, CMS მხოლოდ ეძებს დომენს SIP Request-URI ველში ახალი ზარებისთვის. ასე რომ, თუ SIP INVITE არის ყლუპისთვის: [ელ.ფოსტით დაცულია]CMS ზრუნავს მხოლოდ domain.com-ზე. CMS მიჰყვება ამ წესებს იმის დასადგენად, თუ სად უნდა მიმართოს ზარს:

1. CMS ჯერ ცდილობს SIP დომენი დააკავშიროს შემომავალი ზარის წესებში კონფიგურირებულ დომენებთან. შემდეგ ეს ზარები შეიძლება გადაიტანოს („სამიზნე“) სივრცეებში ან კონკრეტულ მომხმარებლებს, შიდა IVR-ებში ან პირდაპირ ინტეგრირებულ Microsoft Lync/Skype for Business (S4B) მიმართულებებში.
2. თუ შემომავალი ზარის წესებში არ არის შესატყვისი, CMS შეეცდება დაემთხვას ზარის გადამისამართების ცხრილში კონფიგურირებულ დომენს. თუ დამთხვევა მოხდა, წესს შეუძლია ცალსახად უარყოს ზარი ან გადააგზავნოს ზარი. ამ დროს, CMS-მა შეიძლება გადაწეროს დომენი, რაც ზოგჯერ სასარგებლოა Lync დომენების გამოძახებისთვის. თქვენ ასევე შეგიძლიათ აირჩიოთ გადასროლა, რაც ნიშნავს, რომ არცერთი ველი არ შეიცვლება, ან გამოიყენეთ შიდა CMS აკრიფეთ გეგმა. თუ ზარის გადამისამართების წესებში არ არის თანხვედრა, ნაგულისხმევი არის ზარის უარყოფა. გაითვალისწინეთ, რომ CMS-ში, მიუხედავად იმისა, რომ ზარი "გადაგზავნილია", მედია კვლავ მიბმულია CMS-თან, რაც ნიშნავს, რომ ის იქნება სიგნალიზაციისა და მედია ტრაფიკის გზაზე.
მაშინ მხოლოდ გადაგზავნილი ზარები ექვემდებარება გამავალი ზარის წესებს. ეს პარამეტრები განსაზღვრავს მიმართულებებს, სადაც ზარები იგზავნება, მაგისტრალის ტიპი (იქნება ეს ახალი Lync ზარი თუ სტანდარტული SIP ზარი) და ნებისმიერ კონვერტაციას, რომელიც შეიძლება განხორციელდეს, თუ გადაცემა არ არის არჩეული ზარის გადამისამართების წესში.

აქ არის რეალური ჟურნალი, თუ რა ხდება Ad-Hoc კონფერენციის დროს

სკრინშოტი ცუდად აჩვენებს მას (არ ვიცი როგორ გავაუმჯობესო), ამიტომ ჟურნალს ასე დავწერ:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

თვით Ad-Hoc კონფერენცია:


შემომავალი ზარის წესები
შემომავალი ზარების პარამეტრების კონფიგურაცია აუცილებელია CMS-ში ზარის მისაღებად. როგორც LDAP-ის დაყენებაში ნახეთ, ყველა მომხმარებელი იმპორტირებული იყო დომენით conf.pod6.cms.lab. ასე რომ, მინიმუმ, გსურთ ზარები ამ დომენზე მიზნობრივი სივრცეებისთვის. თქვენ ასევე დაგჭირდებათ წესების დაყენება ყველაფრისთვის, რაც განკუთვნილია თითოეული CMS სერვერის სრულად კვალიფიციური დომენის სახელისთვის (და შესაძლოა IP მისამართიც). ჩვენი გარე ზარის კონტროლი, Unified CM, დააკონფიგურირებს SIP ტრანკებს, რომლებიც მიძღვნილი იქნება თითოეული CMS სერვერისთვის ინდივიდუალურად. იმის მიხედვით, არის თუ არა ამ SIP ტრანკების დანიშნულება IP მისამართი, თუ სერვერის FQDN განსაზღვრავს, საჭიროა თუ არა CMS კონფიგურაცია მის IP მისამართზე ან FQDN-ზე მიმართული ზარების მისაღებად.

დომენი, რომელსაც აქვს უმაღლესი პრიორიტეტული შემომავალი წესი, გამოიყენება როგორც დომენი ნებისმიერი მომხმარებლის სივრცეში. როდესაც მომხმარებლები სინქრონიზდებიან LDAP-ის საშუალებით, CMS ავტომატურად ქმნის სივრცეებს, მაგრამ მხოლოდ URI-ის მომხმარებლის ნაწილს (coSpaceUriMapping), მაგალითად, user.space. ნაწილი domain სრული URI იქმნება ამ წესის საფუძველზე. სინამდვილეში, თუ თქვენ შეხვიდეთ Web Bridge-ში ამ ეტაპზე, ნახავთ, რომ Space URI არ აქვს დომენი. ამ წესის უმაღლეს პრიორიტეტად დაყენებით, თქვენ ადგენთ დომენი გენერირებული სივრცეებისთვის კონფ.example.com.


გამავალი ზარის წესები

იმისათვის, რომ მომხმარებლებს საშუალება მისცეთ განახორციელონ გამავალი ზარები ერთიან CM კლასტერში, თქვენ უნდა დააკონფიგურიროთ გამავალი წესები. ერთიანი CM-ით რეგისტრირებული ბოლო წერტილების დომენი, როგორიცაა Jabber, არის example.com. ზარები ამ დომენზე უნდა იყოს მარშრუტირებული, როგორც სტანდარტული SIP ზარები ერთიან CM ზარების დამუშავების კვანძებში. მთავარი სერვერია cucm-01.example.com, ხოლო დამატებითი სერვერი არის cucm-02.example.com.

პირველი წესი აღწერს ზარების უმარტივეს მარშრუტიზაციას კლასტერულ სერვერებს შორის.

საველე ლოკალური დომენიდან პასუხისმგებელია იმაზე, თუ რა იქნება ნაჩვენები აბონენტის SIP-URI-ში იმ პირისთვის, რომელსაც ურეკავენ "@" სიმბოლოს შემდეგ. თუ მას ცარიელი დავტოვებთ, მაშინ "@" სიმბოლოს შემდეგ იქნება CUCM-ის IP მისამართი, რომლითაც გადის ეს ზარი. თუ ჩვენ მივუთითებთ დომენს, მაშინ "@" სიმბოლოს შემდეგ რეალურად იქნება დომენი. ეს აუცილებელია იმისათვის, რომ შეძლოთ დარეკვა, წინააღმდეგ შემთხვევაში შეუძლებელი იქნება SIP-URI name@ip-address-ით დარეკვა.

დარეკეთ როცა მითითებულია ლოკალური დომენიდან


დარეკე როდის არ მითითებულია ლოკალური დომენიდან


აუცილებლად მიუთითეთ დაშიფრული ან დაუშიფრული გამავალი ზარებისთვის, რადგან არაფერი მუშაობს ავტო პარამეტრთან.

ჩაწერის

ვიდეო კონფერენციები ჩაწერილია ჩანაწერის სერვერის მიერ. ჩამწერი ზუსტად იგივეა, რაც Cisco Meeting Server. ჩამწერი არ საჭიროებს რაიმე ლიცენზიის ინსტალაციას. ჩაწერის ლიცენზიები საჭიროა სერვერებისთვის, რომლებიც მუშაობენ CallBridge სერვისებით, ე.ი. საჭიროა ჩაწერის ლიცენზია და უნდა იქნას გამოყენებული CallBridge კომპონენტზე და არა სერვერზე, რომელიც მუშაობს Recorder. ჩამწერი იქცევა როგორც გაფართოებადი შეტყობინებების და ყოფნის პროტოკოლი (XMPP), ამიტომ XMPP სერვერი უნდა იყოს ჩართული სერვერზე, რომელიც მასპინძლობს CallBridge.

იმიტომ რომ ჩვენ გვაქვს კლასტერი და ლიცენზია უნდა იყოს „გადაჭიმული“ კლასტერში სამივე სერვერზე. შემდეგ უბრალოდ თქვენს პირად ანგარიშში ლიცენზიებში ჩვენ ვაკავშირებთ (დავამატებთ) კლასტერში შემავალი ყველა CMS სერვერის a-ინტერფეისების MAC მისამართებს.

და ეს არის სურათი, რომელიც უნდა იყოს კლასტერის ყველა სერვერზე

ზოგადად, ჩამწერის განთავსების რამდენიმე სცენარი არსებობს, მაგრამ ჩვენ ამას დავიცავთ:


ჩამწერის დაყენებამდე, თქვენ უნდა მოამზადოთ ადგილი, სადაც რეალურად ჩაიწერება ვიდეო კონფერენციები. რეალურად აქ ლინკებიროგორ დავაყენოთ ყველა ჩანაწერი. მე ყურადღებას ვამახვილებ მნიშვნელოვან პუნქტებზე და დეტალებზე:

1. უმჯობესია სერთიფიკატი გადაიტანოთ კლასტერში პირველი სერვერიდან.
2. შეცდომა „ჩამწერი მიუწვდომელია“ შეიძლება წარმოიშვას, რადგან არასწორი სერტიფიკატი მითითებულია Recorder Trust-ში.
3. ჩაწერა შეიძლება არ იმუშაოს, თუ ჩასაწერად მითითებული NFS დირექტორია არ არის root დირექტორია.

ზოგჯერ საჭიროა ერთი კონკრეტული მომხმარებლის ან სივრცის კონფერენციის ავტომატურად ჩაწერა.

ამისათვის იქმნება ორი ზარის პროფილი:
ჩაწერის გათიშვით


და ავტომატური ჩაწერის ფუნქციით


შემდეგი, ჩვენ "მიამაგრებთ" CallProfile-ს ავტომატური ჩაწერის ფუნქციით სასურველ სივრცეში.


CMS-ში ისეა დადგენილი, რომ თუ CallProfile ცალსახად არის მიბმული რომელიმე სივრცესთან ან სივრცესთან, მაშინ ეს CallProfile მუშაობს მხოლოდ ამ კონკრეტულ სივრცეებთან მიმართებაში. და თუ 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-and-later. pdf

წყარო: www.habr.com