Cisco հանդիպման սերվեր 2.5.2. Կլաստեր Scalable և Resilient ռեժիմում՝ տեսահամաժողովի ձայնագրման գործառույթով

Այս համարում ես ցույց կտամ և կբացատրեմ CMS սերվերի ստեղծման որոշ բարդություններ failover կլաստերի ռեժիմում:


ТеорияԸնդհանուր առմամբ, CMS սերվերի տեղակայման երեք տեսակ կա.

• Single Համակցված(Միայնակ համակցված), այսինքն. սա մեկ սերվեր է, որի վրա աշխատում են բոլոր անհրաժեշտ ծառայությունները: Շատ դեպքերում, տեղակայման այս տեսակը հարմար է միայն ներքին հաճախորդի մուտքի համար և ավելի փոքր միջավայրերում, որտեղ մեկ սերվերի մասշտաբայնությունը և ավելորդության սահմանափակումները կարևոր խնդիր չեն, կամ այն ​​իրավիճակներում, երբ CMS-ը կատարում է միայն որոշակի գործառույթներ, օրինակ՝ ժամանակավոր: կոնֆերանսներ Cisco UCM-ի վերաբերյալ:

  Աշխատանքի մոտավոր սխեման.
  

• Single Split(Single Split) ընդլայնում է նախորդ տեղակայման տեսակը՝ ավելացնելով առանձին սերվեր արտաքին մուտքի համար: Հնացած տեղակայման դեպքում դա նշանակում էր CMS սերվերի տեղակայում ապառազմականացված ցանցի հատվածում (DMZ), որտեղ արտաքին հաճախորդները կարող էին մուտք գործել այն, և մեկ CMS սերվեր ցանցի միջուկում, որտեղ ներքին հաճախորդները կարող էին մուտք գործել CMS: Այս կոնկրետ տեղակայման մոդելն այժմ փոխարինվում է այսպես կոչված տիպով Single Edge, որը բաղկացած է սերվերներից Cisco արագընթաց մայրուղի, որոնք կամ ունեն կամ կունենան նույն Firewall-ի շրջանցման հնարավորությունները, այնպես որ հաճախորդները կարիք չունենան ավելացնելու հատուկ CMS սերվեր:

  Աշխատանքի մոտավոր սխեման.
  

• Ընդարձակ և ճկուն(Ծավալելի և սխալ հանդուրժող) Այս տեսակը ներառում է ավելորդություն յուրաքանչյուր բաղադրիչի համար, ինչը թույլ է տալիս համակարգին աճել ձեր կարիքներով մինչև իր առավելագույն հզորությունը՝ միաժամանակ ապահովելով ավելորդություն ձախողման դեպքում: Այն նաև օգտագործում է Single Edge հայեցակարգը՝ ապահով արտաքին մուտք ապահովելու համար: Սա այն տեսակն է, որը մենք կանդրադառնանք այս դրվագում: Եթե ​​մենք հասկանանք, թե ինչպես տեղակայել այս տեսակի կլաստերը, մենք ոչ միայն կհասկանանք տեղակայման այլ տեսակներ, այլև կկարողանանք հասկանալ, թե ինչպես ստեղծել CMS սերվերների կլաստերներ՝ պահանջարկի պոտենցիալ աճին համապատասխանելու համար:

Նախքան տեղակայմանը անցնելը, դուք պետք է հասկանաք որոշ հիմնական բաներ, մասնավորապես

CMS ծրագրային ապահովման հիմնական բաղադրիչները.

• DatabaseԹույլ է տալիս համատեղել որոշ կոնֆիգուրացիաներ, ինչպիսիք են հավաքման պլանը, օգտագործողի տարածքները և հենց օգտատերերը: Աջակցում է կլաստերավորմանը միայն բարձր հասանելիության համար (մեկ հիմնական):
• Զանգահարեք կամուրջաուդիո և վիդեոկոնֆերանսների ծառայություն, որն ապահովում է զանգերի կառավարման և մշակման և մուլտիմեդիա գործընթացների լիակատար վերահսկողություն: Աջակցում է կլաստերավորմանը բարձր հասանելիության և մասշտաբայնության համար:
• XMPP սերվերպատասխանատու է հաճախորդների գրանցման և նույնականացման համար՝ օգտագործելով Cisco Meeting Application-ը և/կամ WebRTC(իրական ժամանակի հաղորդակցություն կամ պարզապես բրաուզերում), ինչպես նաև միջբաղադրիչ ազդանշանային. Կարող է խմբավորվել միայն բարձր հասանելիության համար:
• Վեբ կամուրջԱպահովում է հաճախորդի մուտք դեպի WebRTC:
• LoadbalancerԱպահովում է միացման մեկ կետ Cisco-ի հանդիպման հավելվածների համար Single Split ռեժիմում: Լսում է արտաքին ինտերֆեյսը և մուտքային կապերի պորտը: Հավասարապես, բեռի հավասարակշռիչը ընդունում է մուտքային TLS կապեր XMPP սերվերից, որի միջոցով կարող է փոխարկել TCP կապերը արտաքին հաճախորդներից:
  Մեր սցենարով դա պետք չի լինի։
• շրջել սերվերըՏրամադրում է 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-ն կմնա հետևորդների կարգավիճակում, իսկ CallBridge կապերը XMPP-ին կփակվեն, քանի որ CallBridge-ը միանում է բացառապես XMPP-ին՝ լիդեր կարգավիճակով: Եվ սա կրիտիկական է, քանի որ... ոչ մի զանգ չի անցնի:

Նույն տեղակայման ուղեցույցներում ցուցադրվում է մեկ XMPP սերվերով կլաստեր:

Եվ հաշվի առնելով վերը նշվածը, պարզ է դառնում, թե ինչու՝ այն աշխատում է, քանի որ գտնվում է failover ռեժիմում։

Մեր դեպքում 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 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 Server-ի, Web Bridge-ի և Web Admin-ի համար: Այսպիսով, դուք պետք է ստեղծեք մի զույգ հանրային և մասնավոր վկայականի բանալիներ կլաստերի յուրաքանչյուր սերվերի համար:

Տվյալների բազայի կլաստերավորումը, այնուամենայնիվ, ունի որոշակի հատուկ վկայականի պահանջներ և հետևաբար պահանջում է իր սեփական վկայականները, որոնք տարբերվում են այլ ծառայությունների վկայագրերից: CMS-ն օգտագործում է սերվերի վկայագիր, որը նման է այլ սերվերների կողմից օգտագործվող վկայագրերին, բայց կա նաև հաճախորդի վկայագիր, որն օգտագործվում է տվյալների բազայի միացումների համար: Տվյալների բազայի վկայագրերն օգտագործվում են և՛ իսկորոշման, և՛ կոդավորման համար: Հաճախորդի տվյալների բազային միանալու համար օգտագործողի անուն և գաղտնաբառ տրամադրելու փոխարեն, այն ներկայացնում է հաճախորդի վկայական, որը վստահում է սերվերին: Տվյալների բազայի կլաստերի յուրաքանչյուր սերվեր կօգտագործի նույն հանրային և մասնավոր բանալիների զույգը: Սա թույլ է տալիս կլաստերի բոլոր սերվերներին գաղտնագրել տվյալները այնպես, որ դրանք հնարավոր լինի վերծանել միայն այլ սերվերների կողմից, որոնք նույնպես կիսում են նույն բանալիների զույգը:

Որպեսզի ավելորդությունն աշխատի, տվյալների բազայի կլաստերները պետք է կազմված լինեն նվազագույնը 3 սերվերից, բայց ոչ ավելի, քան 5-ը, կլաստերի ցանկացած անդամների միջև առավելագույնը 200 ms շրջադարձային ժամանակով: Այս սահմանն ավելի սահմանափակող է, քան Call Bridge-ի կլաստերավորումը, ուստի այն հաճախ սահմանափակող գործոնն է աշխարհագրորեն բաշխված տեղակայումների ժամանակ:

CMS-ի տվյալների բազայի դերը ունի մի շարք եզակի պահանջներ: Ի տարբերություն այլ դերերի, այն պահանջում է հաճախորդի և սերվերի վկայագիր, որտեղ հաճախորդի վկայականն ունի հատուկ CN դաշտ, որը ներկայացվում է սերվերին:

CMS-ն օգտագործում է postgres տվյալների բազա՝ մեկ հիմնական և մի քանի լրիվ նույնական կրկնօրինակներով: Միանգամից կա միայն մեկ հիմնական տվյալների բազա («տվյալների բազայի սերվեր»): Կլաստերի մնացած անդամները կրկնօրինակներ են կամ «տվյալների բազայի հաճախորդներ»:

Տվյալների բազայի կլաստերը պահանջում է հատուկ սերվերի վկայագիր և հաճախորդի վկայական: Դրանք պետք է ստորագրված լինեն վկայագրերի կողմից, սովորաբար ներքին մասնավոր սերտիֆիկատի մարմին: Քանի որ տվյալների բազայի կլաստերի ցանկացած անդամ կարող է դառնալ հիմնական, տվյալների բազայի սերվերի և հաճախորդի վկայականի զույգերը (պարունակում են հանրային և մասնավոր բանալիներ) պետք է պատճենվեն բոլոր սերվերներին, որպեսզի նրանք կարողանան ենթադրել հաճախորդի կամ տվյալների բազայի սերվերի ինքնությունը: Բացի այդ, CA արմատային վկայականը պետք է բեռնված լինի՝ ապահովելու համար, որ հաճախորդի և սերվերի վկայականները կարող են ստուգվել:

Այսպիսով, մենք ստեղծում ենք սերտիֆիկատի հարցում, որը կօգտագործվի բոլոր սերվերի ծառայություններում, բացառությամբ տվյալների բազայի (դրա համար առանձին հարցում կլինի) հրամանով, ինչպիսին է.

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

CN-ում մենք գրում ենք մեր սերվերների ընդհանուր անվանումը։ Օրինակ, եթե մեր սերվերների հոսթների անունները server01, server02, server03, ապա 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>

Եվ միացրեք Web Admin հրամանը.

webadmin enable

Եթե ​​ամեն ինչ լավ է, մենք կստանանք SUCCESS տողեր, որոնք ցույց են տալիս, որ Web Admin-ը ճիշտ կազմաձևված է ցանցի և վկայագրի համար: Մենք ստուգում ենք ծառայության ֆունկցիոնալությունը վեբ բրաուզերի միջոցով և մուտքագրում ենք վեբ ադմինիստրատորի հասցեն, օրինակ. cms.example.com: 445

Call Bridge Cluster

Call Bridge-ը միակ ծառայությունն է, որն առկա է CMS-ի յուրաքանչյուր տեղակայման մեջ: Call Bridge-ը կոնֆերանսի հիմնական մեխանիզմն է: Այն նաև ապահովում է SIP ինտերֆեյս, որպեսզի զանգերը կարողանան ուղղորդել դեպի կամ այնտեղից, օրինակ, Cisco Unified CM-ի միջոցով:

Ստորև նկարագրված հրամանները պետք է կատարվեն յուրաքանչյուր սերվերի վրա՝ համապատասխան վկայագրերով:
So.

Մենք վկայականները կապում ենք Call Bridge ծառայության հետ այնպիսի հրամանով, ինչպիսին է.

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

Մենք կապում ենք CallBridge ծառայությունները մեզ անհրաժեշտ ինտերֆեյսին հրամանով.

callbridge listen a

Եվ վերագործարկեք ծառայությունը հրամանով.

callbridge restart

Այժմ, երբ մենք կարգավորել ենք մեր Call Bridges-ը, մենք կարող ենք կարգավորել Call Bridge-ի կլաստերավորումը: Call Bridge կլաստերավորումը տարբերվում է տվյալների բազայի կամ XMPP կլաստերավորումից: Call Bridge Cluster-ը կարող է աջակցել 2-ից 8 հանգույց առանց որևէ սահմանափակումների: Այն ապահովում է ոչ միայն ավելորդություն, այլև բեռի հավասարակշռում, որպեսզի կոնֆերանսները կարողանան ակտիվորեն բաշխվել Call Bridge սերվերներում՝ օգտագործելով զանգերի խելացի բաշխումը: CMS-ն ունի լրացուցիչ հնարավորություններ, Call Bridge խմբեր և հարակից գործառույթներ, որոնք կարող են օգտագործվել հետագա կառավարման համար:

Զանգերի կամուրջների խմբավորումը կազմաձևվում է հիմնականում վեբ ադմինիստրատորի միջերեսի միջոցով
Ստորև նկարագրված ընթացակարգը պետք է իրականացվի կլաստերի յուրաքանչյուր սերվերի վրա:
Այնպես որ,

1. Համացանցով անցեք Կազմաձևում > Կլաստեր:
2. Ի Զանգահարեք կամուրջի ինքնությունը Որպես եզակի անուն մուտքագրեք սերվերի անվանը համապատասխան 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 տարբերակից սկսած

Ստորև նկարագրված հրամանները պետք է կատարվեն յուրաքանչյուր սերվերի վրա՝ համապատասխան վկայագրերով:
So.

Մենք վկայականները կապում ենք XMPP ծառայության հետ այնպիսի հրամանով, ինչպիսին է.

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

Այնուհետև սահմանեք լսողության միջերեսը հրամանով.

xmpp listen a

XMPP ծառայությունը պահանջում է եզակի տիրույթ: Սա օգտատերերի մուտքն է: Այլ կերպ ասած, երբ օգտվողը փորձում է մուտք գործել՝ օգտագործելով CMA հավելվածը (կամ WebRTC հաճախորդի միջոցով), նրանք մուտքագրում են userID@logindomain: Մեր դեպքում դա կլինի userid@CONF.example.com. Ինչու դա պարզապես example.com չէ: Մեր կոնկրետ տեղակայման ժամանակ մենք ընտրել ենք մեր Unified 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

Secret-ը շատ զգույշ ենք ավելացնում, որպեսզի, օրինակ, դրա մեջ ավելորդ բացատներ չլինեն։


Արդյունքում, յուրաքանչյուր սերվեր պետք է ունենա նույն պատկերը.

Հաջորդը, կլաստերի բոլոր սերվերների վրա մենք վստահորեն նշում ենք բոլոր երեք վկայագրերը պարունակող ֆայլը, որոնք ավելի վաղ ստեղծվել են հետևյալ հրամանով.

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

Առաջին սերվեր.

Երկրորդ սերվեր.

Երրորդ սերվեր.

Call Bridge-ի միացում XMPP-ին

Այժմ, երբ XMPP կլաստերը աշխատում է, դուք պետք է կարգավորեք Call Bridge ծառայությունները՝ XMPP կլաստերին միանալու համար: Այս կոնֆիգուրացիան կատարվում է վեբ ադմինիստրատորի միջոցով:

Յուրաքանչյուր սերվերի վրա գնացեք Կազմաձև > Ընդհանուր և դաշտում Եզակի Call Bridge անվանումը գրել եզակի անուններ, որոնք համապատասխանում են Call Bridge սերվերին callbridge[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>

Web Bridge-ն աջակցում է 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-ն իսկապես ծանրաբեռնված է, կանխադրված մեխանիզմն է՝ շարունակել ընդունել զանգերը և այդ Call Bridge-ի բոլոր բաժանորդներին ցածր որակի ծառայություն մատուցել:

Այս խնդիրները լուծվում են Call Bridge Group ֆունկցիայի միջոցով: Այս հատկությունը ներդրվել է Cisco Meeting Server ծրագրաշարի 2.1 տարբերակում և ընդլայնվել է՝ աջակցելու բեռների հավասարակշռմանը ինչպես մուտքային, այնպես էլ ելքային Cisco Meeting հավելվածի (CMA) զանգերի համար, ներառյալ WebRTC մասնակիցներին:

Վերամիացման խնդիրը լուծելու համար յուրաքանչյուր Call Bridge-ի համար ներդրվել են երեք կարգավորվող բեռնվածության սահմանափակում.

LoadLimit — սա կոնկրետ Call Bridge-ի առավելագույն թվային բեռն է: Յուրաքանչյուր հարթակ ունի առաջարկվող բեռնվածության սահմանաչափ, օրինակ՝ 96000 CMS1000-ի համար և 1.25 ԳՀց մեկ vCPU-ի համար՝ վիրտուալ մեքենայի համար: Տարբեր զանգերը սպառում են որոշակի քանակությամբ ռեսուրսներ՝ կախված մասնակցի լուծաչափից և շրջանակի արագությունից:
NewConferenceLoadLimitBasisPoints (կանխադրված 50% loadLimit) - սահմանում է սերվերի բեռնվածության սահմանաչափը, որից հետո նոր կոնֆերանսները մերժվում են:
ExistingConferenceLoadLimitBasisPoints (լռելյայն 80% loadLimit) - սերվերի բեռնման արժեքը, որից հետո գոյություն ունեցող համաժողովին միացող մասնակիցները կմերժվեն:

Թեև այս հատկությունը նախատեսված է զանգերի բաշխման և բեռի հավասարակշռման համար, այլ խմբեր, ինչպիսիք են TURN սերվերները, Web Bridge սերվերները և ձայնագրիչները, նույնպես կարող են վերագրվել 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 Server օբյեկտ՝ նշելով այնպիսի պարամետրեր, ինչպիսիք են՝

• Սերվերի IP
• նավահանգստի համարը
• օգտագործողի անունը
• пароль
• ապահովել

Անվտանգ - ընտրեք true կամ false կախված պորտից, 389 - ոչ անվտանգ, 636 - պաշտպանված:


LDAP աղբյուրի պարամետրերի քարտեզագրում Cisco Meeting Server-ի ատրիբուտներին:
LDAP քարտեզագրումը քարտեզագրում է LDAP գրացուցակի ատրիբուտները CMS-ի ատրիբուտներին: Իրական հատկանիշները.

• jidMapping
• nameMapping
• coSpaceNameMapping
• coSpaceUriMapping
• coSpaceSecondaryUriMapping

Հատկանիշների նկարագրությունըJID- ը ներկայացնում է օգտագործողի մուտքի ID-ն CMS-ում: Քանի որ սա Microsoft Active Directory LDAP սերվեր է, CMS JID-ը քարտեզագրվում է LDAP-ի sAMAccountName-ին, որն ըստ էության օգտատիրոջ Active Directory մուտքի ID-ն է: Նաև նշեք, որ դուք վերցնում եք sAMAccountName-ը և ավելացնում եք conf.pod6.cms.lab տիրույթը դրա վերջում, քանի որ սա այն մուտքն է, որը ձեր օգտվողները կօգտագործեն CMS մուտք գործելու համար:

nameMapping համընկնում է Active Directory displayName դաշտում պարունակվող օգտատիրոջ CMS անվան դաշտին:

coSpaceNameMapping ստեղծում է CMS տարածության անուն՝ հիմնվելով displayName դաշտի վրա: Այս հատկանիշը, coSpaceUriMapping հատկանիշի հետ միասին, այն է, ինչ պահանջվում է յուրաքանչյուր օգտագործողի համար տարածք ստեղծելու համար:

coSpaceUriMapping սահմանում է URI-ի օգտատիրոջ մասը՝ կապված օգտագործողի անձնական տարածքի հետ: Որոշ տիրույթներ կարող են կազմաձևվել, որպեսզի հավաքվեն տարածություն: Եթե ​​օգտվողի մասը համապատասխանում է այս դաշտին այս տիրույթներից մեկի համար, զանգը կուղղվի այդ օգտվողի տարածքին:

coSpaceSecondaryUriMapping սահմանում է երկրորդ URI՝ տարածություն հասնելու համար: Սա կարող է օգտագործվել ներմուծված օգտագործողի տարածություն զանգերը ուղղորդելու համար թվային անուն ավելացնելու համար՝ որպես այլընտրանք coSpaceUriMapping պարամետրում սահմանված այբբենական URI-ին:

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

Ժամանակավոր կոնֆերանսներ

Ինչ է սա:Ավանդական հայեցակարգում կոնֆերանսն այն է, երբ երկու մասնակից խոսում են միմյանց հետ, և մասնակիցներից մեկը (օգտագործելով Unified CM-ում գրանցված սարքը) սեղմում է «Կոնֆերանս» կոճակը, զանգահարում դիմացինին և այդ երրորդ կողմի հետ խոսելուց հետո. , կրկին սեղմում է «Համաժողով» կոճակը՝ եռակողմ համաժողովին միանալու բոլոր մասնակիցներին։

Այն, ինչ տարբերում է ժամանակավոր կոնֆերանսը CMS-ում նախատեսված կոնֆերանսից, այն է, որ ժամանակավոր համաժողովը պարզապես SIP զանգ չէ դեպի CMS: Երբ կոնֆերանսի նախաձեռնողը երկրորդ անգամ սեղմում է Կոնֆերանսի կոճակը՝ բոլորին հրավիրելու նույն հանդիպմանը, Unified CM-ը պետք է API զանգ կատարի CMS-ին, որպեսզի ստեղծի ուղիղ կոնֆերանս, որին այնուհետև փոխանցվում են բոլոր զանգերը: Այս ամենը տեղի է ունենում մասնակիցների կողմից աննկատ։

Սա նշանակում է, որ Unified CM-ը պետք է կարգավորի ծառայության API հավատարմագրերը և WebAdmin հասցեն/պորտը, ինչպես նաև SIP Trunk-ը անմիջապես CMS սերվերին՝ զանգը շարունակելու համար:

Անհրաժեշտության դեպքում, CUCM-ը կարող է դինամիկ կերպով ստեղծել տարածք CMS-ում, որպեսզի յուրաքանչյուր զանգ կարողանա հասնել CMS-ին և համապատասխանի մուտքային զանգի կանոնին, որը նախատեսված է բացատների համար:

Ինտեգրում CUCM-ի հետ կազմաձևված է նույն կերպ, ինչպես նկարագրված է հոդվածում նախկինում բացառությամբ այն բանի, որ Cisco UCM-ում դուք պետք է ստեղծեք երեք բեռնախցիկ CMS-ի համար, երեք կոնֆերանսի կամուրջ, SIP անվտանգության պրոֆիլում նշեք երեք առարկաների անուններ, երթուղիների խմբեր, երթուղիների ցուցակներ, մեդիա ռեսուրսների խմբեր և մեդիա ռեսուրսների խմբերի ցուցակներ և ավելացրեք մի քանի երթուղային կանոններ: Cisco հանդիպման սերվերին:

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 զանգ) և ցանկացած փոխարկում, որը կարող է իրականացվել, եթե զանգերի վերահասցեավորման կանոնում փոխանցումը ընտրված չէ:

Ահա թե ինչ է տեղի ունենում ժամանակավոր համաժողովի ժամանակ

Սքրինշոթը դա վատ է ցույց տալիս (չգիտեմ, թե ինչպես այն ավելի լավացնել), այնպես որ ես կգրեմ գրանցամատյանը այսպես.

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 հասցեի) համար: Մեր արտաքին զանգերի հսկողությունը՝ Unified CM-ը, կկազմաձևի SIP կոճղերը՝ նվիրված CMS սերվերներից յուրաքանչյուրին առանձին: Կախված նրանից, թե արդյոք այս SIP կոճղերի նպատակակետը IP հասցե է, թե սերվերի FQDN-ը, կորոշի, թե արդյոք CMS-ը պետք է կազմաձևվի, որպեսզի ընդունի իր IP հասցեին կամ FQDN-ին ուղղված զանգերը:

Այն տիրույթը, որն ունի ամենաառաջնահերթ մուտքային կանոնը, օգտագործվում է որպես տիրույթ ցանկացած օգտագործողի տարածքների համար: Երբ օգտվողները համաժամացվում են LDAP-ի միջոցով, CMS-ն ավտոմատ կերպով ստեղծում է բացատներ, բայց միայն URI-ի օգտագործողի մասը (coSpaceUriMapping), օրինակ՝ user.space: մաս դոմեյն Ամբողջական URI-ն ստեղծվում է այս կանոնի հիման վրա: Փաստորեն, եթե այս պահին մուտք գործեիք Web Bridge, կտեսնեիք, որ Space URI-ն տիրույթ չունի: Սահմանելով այս կանոնը որպես ամենաբարձր առաջնահերթություն, դուք սահմանում եք տիրույթը, որպեսզի գեներացված տարածքները լինեն կոնֆ.example.com.


Ելքային զանգի կանոններ

Որպեսզի օգտատերերին թույլ տաք ելքային զանգեր կատարել միասնական CM կլաստեր, դուք պետք է կազմաձևեք ելքային կանոնները: Unified CM-ում գրանցված վերջնակետերի տիրույթը, ինչպիսին է Jabber-ը, օրինակ.com է: Այս տիրույթի զանգերը պետք է ուղղորդվեն որպես ստանդարտ SIP զանգեր դեպի միասնական CM զանգերի մշակման հանգույցներ: Հիմնական սերվերը cucm-01.example.com է, իսկ լրացուցիչ սերվերը՝ cucm-02.example.com:

Առաջին կանոնը նկարագրում է կլաստերային սերվերների միջև զանգերի ամենապարզ երթուղին:

Դաշտ Տեղական տիրույթից պատասխանատու է այն բանի համար, թե ինչ կցուցադրվի զանգահարողի SIP-URI-ում «@» նշանից հետո զանգահարվող անձի համար: Եթե ​​այն դատարկ թողնենք, ապա «@» նշանից հետո կլինի CUCM-ի IP հասցեն, որով անցնում է այս զանգը։ Եթե ​​նշենք տիրույթ, ապա «@» խորհրդանիշից հետո իրականում կլինի տիրույթ։ Սա անհրաժեշտ է հետզանգելու հնարավորության համար, այլապես հնարավոր չի լինի հետ կանչել SIP-URI name@ip-address-ի միջոցով:

Զանգահարեք, երբ նշված է Տեղական տիրույթից


Երբ զանգահարեք ՉԷ նշված է Տեղական տիրույթից


Համոզվեք, որ ելքային զանգերի համար հստակ նշեք Encrypted կամ Unencrypted, քանի որ ոչինչ չի աշխատում Auto պարամետրով:

Ձայնագրությունը

Տեսակոնֆերանսները ձայնագրվում են Record սերվերի կողմից: Ձայնագրիչը ճիշտ նույնն է, ինչ Cisco Meeting Server-ը: Ձայնագրիչը չի պահանջում որևէ լիցենզիաների տեղադրում: Ձայնագրման լիցենզիաները պահանջվում են CallBridge ծառայություններով աշխատող սերվերների համար, այսինքն. Պահանջվում է ձայնագրման լիցենզիա, որը պետք է կիրառվի CallBridge բաղադրիչի վրա, և ոչ թե ձայնագրիչով աշխատող սերվերի վրա: Ձայնագրիչն իրեն պահում է որպես ընդարձակվող հաղորդագրությունների և ներկայության արձանագրության (XMPP) հաճախորդ, ուստի XMPP սերվերը պետք է միացված լինի CallBridge հոսթինգի սերվերում:

Որովհետեւ Մենք ունենք կլաստեր, և լիցենզիան պետք է «ձգվի» կլաստերի բոլոր երեք սերվերների վրա: Այնուհետև լիցենզիաներում պարզապես ձեր անձնական հաշվում մենք կապում ենք (ավելացնում ենք) կլաստերի մեջ ներառված բոլոր CMS սերվերների a-ինտերֆեյսների MAC հասցեները:

Եվ սա այն պատկերն է, որը պետք է լինի կլաստերի յուրաքանչյուր սերվերի վրա

Ընդհանուր առմամբ, ձայնագրիչ տեղադրելու մի քանի սցենար կա, բայց մենք կառչենք դրան.


Նախքան Ձայնագրիչը կարգավորելը, դուք պետք է պատրաստեք մի վայր, որտեղ իրականում կձայնագրվեն վիդեոկոնֆերանսները: Իրականում այստեղ ՈՒղեցույց, ինչպես կարգավորել ամբողջ ձայնագրությունը: Ես կենտրոնանում եմ կարևոր կետերի և մանրամասների վրա.

1. Ավելի լավ է վկայականը հանել կլաստերի առաջին սերվերից:
2. «Ձայնագրիչը անհասանելի է» սխալը կարող է առաջանալ, քանի որ սխալ վկայականը նշված է Գրանցիչի վստահության մեջ:
3. Գրելը կարող է չաշխատել, եթե ձայնագրման համար նշված NFS գրացուցակը արմատային գրացուցակը չէ:

Երբեմն անհրաժեշտություն է առաջանում ավտոմատ կերպով գրանցել մեկ կոնկրետ օգտագործողի կամ տարածքի կոնֆերանսը:

Դրա համար ստեղծվում են երկու CallProfiles.
Ձայնագրումն անջատված է


Եվ ավտոմատ ձայնագրման գործառույթով


Հաջորդը, մենք «կցում» ենք 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

Source: www.habr.com