Šajā izdevumā es parādīšu un izskaidrošu dažas CMS servera iestatīšanas kļūmjpārlēces klastera režīmā sarežģītības.
ТеорияKopumā ir trīs CMS servera izvietošanas veidi:
- Vienots apvienots(Viens apvienots), t.i. šis ir viens serveris, kurā darbojas visi nepieciešamie pakalpojumi. Vairumā gadījumu šāda veida izvietošana ir piemērota tikai iekšējai klienta piekļuvei un mazākās vidēs, kur viena servera mērogojamības un dublēšanas ierobežojumi nav kritiska problēma, vai situācijās, kad SPS veic tikai noteiktas funkcijas, piemēram, ad hoc. konferences par Cisco UCM.
Aptuvenā darba shēma:
- Single Split(Single Split) paplašina iepriekšējo izvietošanas veidu, pievienojot atsevišķu serveri ārējai piekļuvei. Mantotajos izvietojumos tas nozīmēja CMS servera izvietošanu demilitarizētā tīkla segmentā (DMZ), kur tam varēja piekļūt ārējie klienti, un vienu CMS serveri tīkla kodolā, kur iekšējie klienti varēja piekļūt CMS. Šo konkrēto izvietošanas modeli tagad aizstāj tā sauktais veids Viena mala, kas sastāv no serveriem Cisco Expressway, kuriem ir vai būs daudzas tādas pašas ugunsmūra apiešanas iespējas, lai klientiem nebūtu jāpievieno īpašs malas CMS serveris.
Aptuvenā darba shēma:
- Mērogojams un elastīgs(Mērogojams un kļūdu izturīgs) Šis tips ietver katra komponenta dublēšanu, ļaujot sistēmai augt atbilstoši jūsu vajadzībām līdz maksimālajai jaudai, vienlaikus nodrošinot dublēšanu kļūmes gadījumā. Tas arī izmanto Single Edge koncepciju, lai nodrošinātu drošu ārēju piekļuvi. Šis ir veids, ko mēs aplūkosim šajā epizodē. Ja mēs sapratīsim, kā izvietot šāda veida klasteri, mēs ne tikai sapratīsim citus izvietošanas veidus, bet arī varēsim saprast, kā izveidot CMS serveru kopas, lai pielāgotos potenciālajam pieprasījuma pieaugumam.
Pirms pāriet uz izvietošanu, jums ir jāsaprot dažas pamata lietas, proti
Galvenie CMS programmatūras komponenti:
- Datubāze: ļauj apvienot dažas konfigurācijas, piemēram, sastādīšanas plānu, lietotāju vietas un pašus lietotājus. Atbalsta klasterizāciju tikai augstas pieejamības nodrošināšanai (viena galvenā ierīce).
- Zvaniet Bridge: audio un video konferenču pakalpojums, kas nodrošina pilnīgu kontroli pār zvanu un multivides procesu pārvaldību un apstrādi. Atbalsta klasterizāciju augstai pieejamībai un mērogojamībai.
- XMPP serveris: atbild par klientu reģistrāciju un autentifikāciju, izmantojot lietojumprogrammu Cisco Meeting un/vai WebRTC(saziņa reāllaikā vai vienkārši pārlūkprogrammā), kā arī starpkomponentu signalizācija. Var grupēt tikai augstas pieejamības nodrošināšanai.
- Web tilts: nodrošina klienta piekļuvi WebRTC.
- Slodzes balansētājs: nodrošina vienu savienojuma punktu Cisco sapulču lietojumprogrammām Single Split režīmā. Klausās ārējo interfeisu un ienākošo savienojumu portu. Tāpat slodzes līdzsvarotājs pieņem ienākošos TLS savienojumus no XMPP servera, caur kuru tas var pārslēgt TCP savienojumus no ārējiem klientiem.
Mūsu scenārijā tas nebūs vajadzīgs. - TURN serveri: nodrošina ugunsmūra apiešanas tehnoloģiju, kas ļauj
novietojiet mūsu CMS aiz ugunsmūra vai NAT, lai savienotu ārējos klientus, izmantojot Cisco Meeting App vai SIP ierīces. Mūsu scenārijā tas nebūs vajadzīgs. - Tīmekļa administrators: Administratīvais interfeiss un API piekļuve, tostarp īpašām vienotā CM konferencēm.
Konfigurācijas režīmi
Atšķirībā no vairuma citu Cisco produktu, Cisco Meeting Server atbalsta trīs konfigurācijas metodes, lai pielāgotos jebkura veida izvietošanai.
- Komandrinda (CLI): komandrindas saskarne, kas pazīstama kā MMP sākotnējās konfigurācijas un sertifikāta uzdevumiem.
- Web administrators: galvenokārt ar CallBridge saistītām konfigurācijām, jo īpaši, iestatot vienu nekopu serveri.
- REST API: izmanto vissarežģītākajiem konfigurācijas uzdevumiem un ar kopu datu bāzi saistītiem uzdevumiem.
Papildus iepriekšminētajam tiek izmantots protokols SFTP lai pārsūtītu failus — parasti licences, sertifikātus vai žurnālus — uz un no CMS servera.
Cisco izvietošanas rokasgrāmatās baltā un angļu valodā ir rakstīts, ka klasteris ir jāizvieto. vismaz trīs serveriem (mezgliem) datu bāzu kontekstā. Jo Tikai ar nepāra skaitu mezglu darbosies jauna datu bāzes meistara izvēles mehānisms, un kopumā datu bāzes meistaram ir savienojums ar lielāko daļu CMS servera datu bāzes.
Un, kā liecina prakse, ar diviem serveriem (mezgliem) patiešām nepietiek. Atlases mehānisms darbojas, kad tiek pārstartēts galvenais serveris, Slave serveris kļūst par galveno tikai pēc pārstartētā servera izcelšanas. Tomēr, ja divu serveru klasterī pēkšņi izdziest galvenais serveris, tad vergu serveris nekļūs par galveno, un, ja vergu nodziest, tad atlikušais galvenais serveris kļūs par vergu.
Bet XMPP kontekstā tiešām būtu nepieciešams salikt klasteru no trim serveriem, jo ja, piemēram, atspējojat XMPP pakalpojumu vienā no serveriem, kurā XMMP ir Leader statusā, tad atlikušajā serverī XMPP paliks sekotāja statusā un CallBridge savienojumi ar XMPP pārtrūks, jo CallBridge savieno tikai ar XMPP ar Leader statusu. Un tas ir kritiski, jo... neizdosies neviens zvans.
Arī tajos pašos izvietošanas ceļvežos ir parādīts klasteris ar vienu XMPP serveri.
Un, ņemot vērā iepriekš minēto, kļūst skaidrs, kāpēc: tas darbojas, jo tas ir kļūmjpārlēces režīmā.
Mūsu gadījumā XMPP serveris atradīsies visos trīs mezglos.
Tiek pieņemts, ka visi trīs mūsu serveri ir atvērti.
DNS ieraksti
Pirms serveru iestatīšanas ir jāizveido DNS ieraksti А и SRV veidi:
Lūdzu, ņemiet vērā, ka mūsu DNS ierakstos ir divi domēni example.com un conf.example.com. example.com ir domēns, ko visi Cisco Unified Communication Manager abonenti var izmantot saviem URI, kas, visticamāk, atrodas jūsu infrastruktūrā vai, visticamāk, būs. Vai example.com atbilst tam pašam domēnam, ko lietotāji izmanto savām e-pasta adresēm. Vai arī jūsu klēpjdatora Jabber klientam var būt URI [e-pasts aizsargāts]. Domēns conf.example.com ir domēns, kas tiks konfigurēts Cisco sapulču servera lietotājiem. Cisco sapulču servera domēns būs conf.example.com, tāpēc tam pašam Jabber lietotājam, lai pieteiktos Cisco sapulču serverī, ir jāizmanto user@ URIconf.example.com.
Pamatkonfigurācija
Visi tālāk aprakstītie iestatījumi tiek rādīti vienā serverī, taču tie ir jāveic katrā klastera serverī.
QoS
Tā kā CMS ģenerē reālā laika trafika jutīga pret kavēšanos un pakešu zudumu, vairumā gadījumu ir ieteicams konfigurēt pakalpojuma kvalitāti (QoS). Lai to panāktu, CMS atbalsta pakešu marķēšanu ar tā ģenerētajiem diferencēto pakalpojumu kodiem (DSCP). Lai gan uz DSCP balstīta trafika prioritāšu noteikšana ir atkarīga no tā, kā trafiku apstrādā jūsu infrastruktūras tīkla komponenti, mūsu gadījumā mēs konfigurēsim savu CMS ar tipisku DSCP prioritāšu noteikšanu, pamatojoties uz QoS labāko praksi.
Katrā serverī mēs ievadīsim šīs komandas
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1ATādējādi visa video trafika tika apzīmēta ar AF41 (DSCP 0x22), visa balss trafika tika apzīmēta ar EF (DSCP 0x2E), citi zema latentuma trafika veidi, piemēram, SIP un XMPP, izmanto AF31 (DSCP 0x1A).
Pārbaude:
NTP
Tīkla laika protokols (NTP) ir svarīgs ne tikai precīzu zvanu un konferenču laika zīmogu nodrošināšanai, bet arī sertifikātu pārbaudei.
Pievienojiet savai infrastruktūrai NTP serverus ar tādu komandu kā
ntp server add <server>
Mūsu gadījumā šādi serveri ir divi, tātad būs divas komandas.
Pārbaude:
Un iestatiet mūsu servera laika joslu
DNS
Mēs pievienojam DNS serverus CMS ar komandu, piemēram:
dns add forwardzone <domain-name> <server ip>
Mūsu gadījumā šādi serveri ir divi, tātad būs divas komandas.
Pārbaude:
Tīkla interfeisa konfigurācija
Mēs konfigurējam saskarni ar komandu, piemēram:
ipv4 <interface> add <address>/<prefix length> <gateway>
Pārbaude:
Servera nosaukums (resursdatora nosaukums)
Mēs iestatām servera nosaukumu ar komandu, piemēram:
hostname <name>
Un mēs pārstartējam.
Tas pabeidz pamata konfigurāciju.
Sertifikāti
ТеорияCisco Meeting Server ir nepieciešama šifrēta saziņa starp dažādiem komponentiem, un tāpēc visiem CMS izvietojumiem ir nepieciešami X.509 sertifikāti. Tie palīdz nodrošināt, ka pakalpojumiem/serverim uzticas citi serveri/pakalpojumi.
Katram pakalpojumam ir nepieciešams sertifikāts, taču atsevišķu sertifikātu izveidošana katram pakalpojumam var radīt neskaidrības un nevajadzīgas sarežģītības. Par laimi, mēs varam ģenerēt sertifikāta publisko un privāto atslēgu pāri un pēc tam tos atkārtoti izmantot vairākos pakalpojumos. Mūsu gadījumā tas pats sertifikāts tiks izmantots Call Bridge, XMPP Server, Web Bridge un Web Admin. Tādējādi katram klastera serverim ir jāizveido publisko un privāto sertifikātu atslēgu pāris.
Tomēr datu bāzu klasterēšanai ir dažas īpašas sertifikātu prasības, un tāpēc ir nepieciešami savi sertifikāti, kas atšķiras no citiem pakalpojumiem. CMS izmanto servera sertifikātu, kas ir līdzīgs citu serveru izmantotajiem sertifikātiem, taču ir arī klienta sertifikāts, ko izmanto datu bāzes savienojumiem. Datu bāzes sertifikāti tiek izmantoti gan autentifikācijai, gan šifrēšanai. Tā vietā, lai klientam nodrošinātu lietotājvārdu un paroli, lai izveidotu savienojumu ar datu bāzi, tas uzrāda klienta sertifikātu, kuram serveris uzticas. Katrs datu bāzes klastera serveris izmantos vienu un to pašu publisko un privāto atslēgu pāri. Tas ļauj visiem klastera serveriem šifrēt datus tādā veidā, ka tos var atšifrēt tikai citi serveri, kuriem ir arī viens un tas pats atslēgu pāris.
Lai redundance darbotos, datu bāzes klasteriem ir jāsastāv no vismaz 3 serveriem, bet ne vairāk kā 5, un maksimālais pārvietošanās laiks starp klastera dalībniekiem ir 200 ms. Šis ierobežojums ir stingrāks nekā Call Bridge klasterizācijai, tāpēc tas bieži vien ir ierobežojošais faktors ģeogrāfiski sadalītos izvietojumos.
CMS datu bāzes lomai ir vairākas unikālas prasības. Atšķirībā no citām lomām, tam ir nepieciešams klienta un servera sertifikāts, kur klienta sertifikātam ir noteikts CN lauks, kas tiek parādīts serverim.
CMS izmanto postgres datubāzi ar vienu galveno un vairākām pilnīgi identiskām replikām. Vienlaicīgi ir tikai viena primārā datu bāze (“datu bāzes serveris”). Atlikušie klastera dalībnieki ir replikas vai "datu bāzes klienti".
Datu bāzes klasterim ir nepieciešams īpašs servera sertifikāts un klienta sertifikāts. Tie ir jāparaksta ar sertifikātiem, parasti iekšējai privātai sertifikācijas iestādei. Tā kā jebkurš datu bāzes klastera dalībnieks var kļūt par galveno, datu bāzes servera un klienta sertifikātu pāri (kas satur publisko un privāto atslēgu) ir jākopē visos serveros, lai tie varētu pieņemt klienta vai datu bāzes servera identitāti. Turklāt ir jāielādē CA saknes sertifikāts, lai nodrošinātu klienta un servera sertifikātu pārbaudi.
Tātad mēs izveidojam sertifikāta pieprasījumu, ko izmantos visi servera pakalpojumi, izņemot datu bāzi (par to būs atsevišķs pieprasījums) ar šādu komandu:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
CN mēs rakstām mūsu serveru vispārīgos nosaukumus. Piemēram, ja mūsu serveru resursdatora nosaukumi server01, server02, server03, tad CN būs serveris.example.com
Mēs darām to pašu atlikušajos divos serveros ar atšķirību, ka komandās būs atbilstošie “resursdatora nosaukumi”
Mēs ģenerējam divus sertifikātu pieprasījumus, kurus izmantos datu bāzes pakalpojums ar šādām komandām:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgreskur dbclusterserver и dbclusterclient mūsu pieprasījumu un turpmāko sertifikātu nosaukumi, resursdatora nosaukums1(2)(3) atbilstošo serveru nosaukumi.
Mēs veicam šo procedūru tikai vienā serverī (!), un mēs augšupielādēsim sertifikātus un atbilstošos .key failus citos serveros.
Iespējot klienta sertifikāta režīmu AD CS
Jums arī jāapvieno katra servera sertifikāti vienā failā.Vietnē *NIX:
cat server01.cer server02.cer server03.cer > server.cerOperētājsistēmā Windows/DOS:
copy server01.cer + server02.cer + server03.cer server.cer
Un augšupielādējiet katrā serverī:
1. “Individuālais” servera sertifikāts.
2. Saknes sertifikāts (kopā ar starpposma sertifikātiem, ja tādi ir).
3. Sertifikāti datu bāzei (“serveris” un “klients”) un faili ar paplašinājumu .key, kas tika ģenerēti, veidojot “servera” un “klienta” datu bāzes sertifikātu pieprasījumu. Šiem failiem ir jābūt vienādiem visos serveros.
4. Visu trīs “individuālo” sertifikātu fails.
Rezultātā katrā serverī vajadzētu iegūt kaut ko līdzīgu šim faila attēlam.
Datu bāzu klasteris
Tagad, kad visi sertifikāti ir augšupielādēti CMS serveros, varat konfigurēt un iespējot datu bāzes klasterizāciju starp trim mezgliem. Pirmais solis ir izvēlēties vienu serveri kā datu bāzes klastera galveno mezglu un pilnībā konfigurēt to.
Galvenā datu bāze
Pirmais solis datu bāzes replikācijas iestatīšanā ir norādīt sertifikātus, kas tiks izmantoti datu bāzei. Tas tiek darīts, izmantojot komandu, piemēram:
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>Tagad pastāstīsim CMS, kuru saskarni izmantot datu bāzes klasterēšanai ar komandu:
database cluster localnode aPēc tam mēs inicializējam klasteru datu bāzi galvenajā serverī ar komandu:
database cluster initialize
Klientu datu bāzes mezgli
Mēs veicam to pašu procedūru, tikai komandas vietā datu bāzes klastera inicializācija ievadiet komandu, piemēram:
database cluster join <ip address existing master>kur ip adrese esošā galvenā IP adrese CMS serverī, kurā tika inicializēts klasteris, vienkārši Master.
Mēs pārbaudām, kā mūsu datu bāzes klasteris darbojas visos serveros, izmantojot komandu:
database cluster status
Mēs darām to pašu atlikušajā trešajā serverī.
Rezultātā izrādās, ka mūsu pirmais serveris ir galvenais, pārējie ir vergi.
Tīmekļa administratora pakalpojums
Iespējot tīmekļa administratora pakalpojumu:
webadmin listen a 445Ports 445 tika izvēlēts, jo ports 443 tiek izmantots lietotāja piekļuvei tīmekļa klientam
Mēs konfigurējam Web Admin pakalpojumu ar sertifikātu failiem ar šādu komandu:
webadmin certs <keyfile> <certificatefile> <ca bundle>Un iespējojiet Web Admin ar komandu:
webadmin enable
Ja viss ir kārtībā, mēs saņemsim SUCCESS rindas, kas norāda, ka Web administrators ir pareizi konfigurēts tīklam un sertifikātam. Mēs pārbaudām pakalpojuma funkcionalitāti, izmantojot tīmekļa pārlūkprogrammu un ievadām tīmekļa administratora adresi, piemēram: : 445
Zvaniet uz tilta kopu
Call Bridge ir vienīgais pakalpojums, kas pieejams katrā CMS izvietošanā. Call Bridge ir galvenais konferenču mehānisms. Tas nodrošina arī SIP interfeisu, lai zvanus uz to vai no tā varētu novirzīt, piemēram, izmantojot Cisco vienoto CM.
Tālāk aprakstītās komandas jāizpilda katrā serverī ar atbilstošiem sertifikātiem.
Tātad:
Mēs saistām sertifikātus ar pakalpojumu Call Bridge ar komandu, piemēram:
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]Mēs saistām CallBridge pakalpojumus ar nepieciešamo saskarni ar komandu:
callbridge listen aUn restartējiet pakalpojumu ar komandu:
callbridge restart
Tagad, kad mūsu zvanu tilti ir konfigurēti, mēs varam konfigurēt Call Bridge klasterizāciju. Call Bridge klasterizācija atšķiras no datu bāzes vai XMPP klasterizācijas. Call Bridge Cluster var atbalstīt no 2 līdz 8 mezgliem bez jebkādiem ierobežojumiem. Tas nodrošina ne tikai dublēšanu, bet arī slodzes līdzsvarošanu, lai konferences varētu aktīvi izplatīt Call Bridge serveros, izmantojot viedo zvanu sadali. SPS ir papildu līdzekļi, Call Bridge grupas un saistīti līdzekļi, kurus var izmantot turpmākai pārvaldībai.
Zvanu tilta klasterizācija galvenokārt tiek konfigurēta, izmantojot tīmekļa administratora saskarni
Tālāk aprakstītā procedūra ir jāveic katrā klastera serverī.
Tātad,
1. Tīmeklī atveriet sadaļu Konfigurācija > Kopa.
2. Uz Zvaniet Bridge identitātei Kā unikālu nosaukumu ievadiet servera nosaukumam atbilstošu zvanu tiltu [01,02,03]. Šie nosaukumi ir patvaļīgi, taču tiem jābūt unikāliem šai klasterim. Tiem ir aprakstošs raksturs, jo tie norāda, ka tie ir servera identifikatori [01,02,03].
3.B Klasterizēti zvanu tilti ievadiet klasterī mūsu serveru tīmekļa administratora vietrāžus URL, [01,02,03].example.com:445 laukā Adrese. Noteikti norādiet portu. Vienādranga saites SIP domēnu varat atstāt tukšu.
4. Katra servera CallBridge uzticamībai pievienojiet sertifikātu, kura failā ir visi mūsu serveru sertifikāti, kurus mēs apvienojām šajā failā pašā sākumā, ar šādu komandu:
callbridge trust cluster <trusted cluster certificate bundle>Un restartējiet pakalpojumu ar komandu:
callbridge restart
Rezultātā katrā serverī jums vajadzētu iegūt šo attēlu:
XMPP klasteris
XMPP pakalpojums SPS tiek izmantots, lai apstrādātu visu Cisco Meeting Apps (CMA), tostarp CMA WebRTC tīmekļa klienta reģistrāciju un autentifikāciju. Pats Call Bridge darbojas arī kā XMPP klients autentifikācijas nolūkos, un tāpēc tas ir jākonfigurē tāpat kā citi klienti. XMPP kļūdu tolerance ir līdzeklis, kas tiek atbalstīts ražošanas vidēs kopš versijas 2.1
Tālāk aprakstītās komandas jāizpilda katrā serverī ar atbilstošiem sertifikātiem.
Tātad:
Mēs saistām sertifikātus ar XMPP pakalpojumu ar komandu, piemēram:
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]Pēc tam definējiet klausīšanās saskarni ar komandu:
xmpp listen aXMPP pakalpojumam ir nepieciešams unikāls domēns. Šī ir lietotāju pieteikšanās. Citiem vārdiem sakot, kad lietotājs mēģina pieteikties, izmantojot CMA lietotni (vai izmantojot WebRTC klientu), viņš ievada userID@logindomain. Mūsu gadījumā tas būs userid@conf.example.com. Kāpēc tas nav tikai example.com? Mūsu konkrētajā izvietošanā mēs atlasījām mūsu vienoto CM domēnu, ko Jabber lietotāji izmantos vienotajā CM kā example.com, tāpēc mums bija nepieciešams cits domēns, lai CMS lietotāji varētu maršrutēt zvanus uz un no CMS caur SIP domēniem.
Iestatiet XMPP domēnu, izmantojot komandu, piemēram:
xmpp domain <domain>Un iespējojiet XMPP pakalpojumu ar komandu:
xmpp enableXMPP pakalpojumā jums ir jāizveido akreditācijas dati katram Call Bridge, kas tiks izmantots, reģistrējoties XMPP pakalpojumā. Šie nosaukumi ir patvaļīgi (un nav saistīti ar unikālajiem nosaukumiem, ko konfigurējāt zvanu tilta klasterēšanai). Jums ir jāpievieno trīs zvanu tilti vienā XMPP serverī un pēc tam jāievada šie akreditācijas dati citos klastera XMPP serveros, jo šī konfigurācija neietilpst klastera datu bāzē. Vēlāk mēs konfigurēsim katru zvanu tiltu, lai izmantotu šo nosaukumu un noslēpumu, lai reģistrētos XMPP pakalpojumā.
Tagad mums ir jākonfigurē XMPP pakalpojums pirmajā serverī ar trim Call Bridges callbridge01, callbridge02 un callbridge03. Katram kontam tiks piešķirtas nejaušas paroles. Vēlāk tie tiks ievadīti citos Call Bridge serveros, lai pieteiktos šajā XMPP serverī. Ievadiet šādas komandas:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03Rezultātā mēs pārbaudām, kas notika ar komandu:
xmpp callbridge list
Tieši tādam pašam attēlam vajadzētu parādīties atlikušajos serveros pēc tālāk aprakstītajām darbībām.
Tālāk mēs pievienojam tieši tādus pašus iestatījumus atlikušajos divos serveros, tikai ar komandām
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Secret pievienojam ļoti uzmanīgi, lai, piemēram, tajā nebūtu lieku atstarpju.
Rezultātā katram serverim vajadzētu būt vienam un tam pašam attēlam:
Tālāk visos klastera serveros mēs uzticami norādām failu, kurā ir visi trīs sertifikāti, kas izveidoti iepriekš ar šādu komandu:
xmpp cluster trust <trust bundle>Mēs iespējojam xmpp klastera režīmu visos klasteru serveros ar komandu:
xmpp cluster enablePirmajā klastera serverī mēs uzsākam xmpp klastera izveidi ar komandu:
xmpp cluster initializeCitos serveros pievienojiet klasteru xmpp ar komandu, piemēram:
xmpp cluster join <ip address head xmpp server>Mēs pārbaudām katrā serverī, vai katrā serverī ir izdevies izveidot XMPP klasteru, izmantojot šādas komandas:
xmpp status
xmpp cluster statusPirmais serveris:
Otrais serveris:
Trešais serveris:
Zvanu tilta savienošana ar XMPP
Tagad, kad darbojas XMPP klasteris, jums ir jākonfigurē Call Bridge pakalpojumi, lai izveidotu savienojumu ar XMPP klasteru. Šī konfigurācija tiek veikta, izmantojot tīmekļa administratoru.
Katrā serverī atveriet sadaļu Konfigurācija > Vispārīgi un laukā Unikāls Call Bridge nosaukums rakstīt unikālus Call Bridge nosaukumus, kas atbilst serverim zvanu tilts[01,02,03]... Laukā Domēns conf.example.ru un atbilstošās paroles, varat tās izspiegot
jebkurā klastera serverī ar komandu:
xmpp callbridge list
Atstājiet lauku “Serveris” tukšu Kalbridžs veiks DNS SRV uzmeklēšanu _xmpp-component._tcp.conf.example.comlai atrastu pieejamu XMPP serveri. IP adreses zvanu tiltu savienošanai ar XMPP var atšķirties katrā serverī, tas ir atkarīgs no tā, kādas vērtības tiek atgrieztas ieraksta pieprasījumam _xmpp-component._tcp.conf.example.com zvanu tilts, kas savukārt ir atkarīgs no konkrētā DNS ieraksta prioritātes iestatījumiem.
Pēc tam dodieties uz Statuss > Vispārīgi, lai pārbaudītu, vai pakalpojums Call Bride ir veiksmīgi savienots ar XMPP pakalpojumu.
Web tilts
Katrā klastera serverī iespējojiet Web Bridge pakalpojumu ar komandu:
webbridge listen a:443Mēs konfigurējam Web Bridge pakalpojumu ar sertifikātu failiem ar šādu komandu:
webbridge certs <keyfile> <certificatefile> <ca bundle>Web Bridge atbalsta HTTPS. Tas novirzīs HTTP uz HTTPS, ja tas ir konfigurēts, lai izmantotu "http-redirect".
Lai iespējotu HTTP novirzīšanu, izmantojiet šo komandu:
webbridge http-redirect enableLai informētu Call Bridge, ka Web Bridge var uzticēties savienojumiem no Call Bridge, izmantojiet komandu:
webbridge trust <certfile>kur šis ir fails, kurā ir visi trīs sertifikāti no katra klastera servera.
Šim attēlam jābūt katrā klastera serverī.
Tagad mums ir jāizveido lietotājs ar “appadmin” lomu, tas ir vajadzīgs, lai mēs varētu konfigurēt savu klasteru(!), nevis katru klastera serveri atsevišķi, tādējādi iestatījumi tiks piemēroti vienādi katram serverim, neskatoties uz to, ka fakts, ka tie tiks izgatavoti vienreiz.
Turpmākai iestatīšanai mēs izmantosim .
Lai veiktu autorizāciju, sadaļā Autorizācija atlasiet Pamata
Lai pareizi nosūtītu komandas uz CMS serveri, ir jāiestata nepieciešamais kodējums
Mēs norādām Webbridge ar komandu POST ar parametru url un nozīme
Pašā tīmekļa tiltā mēs norādām nepieciešamos parametrus: viesa piekļuve, aizsargāta piekļuve utt.
Zvaniet tilta grupām
Pēc noklusējuma CMS ne vienmēr visefektīvāk izmanto tai pieejamos konferenču resursus.
Piemēram, sapulcē ar trim dalībniekiem katrs dalībnieks var nonākt trīs dažādos zvanu tiltos. Lai šie trīs dalībnieki varētu sazināties savā starpā, Call Bridges automātiski izveidos savienojumus starp visiem serveriem un klientiem tajā pašā telpā, lai tas viss izskatītos tā, it kā visi klienti atrastos vienā serverī. Diemžēl negatīvā puse ir tāda, ka viena 3 cilvēku konference tagad patērēs 9 multivides portus. Tā acīmredzami ir neefektīva resursu izmantošana. Turklāt, ja Call Bridge ir patiešām pārslogots, noklusējuma mehānisms ir turpināt pieņemt zvanus un nodrošināt zemākas kvalitātes pakalpojumus visiem šī Call Bridge abonentiem.
Šīs problēmas tiek atrisinātas, izmantojot funkciju Call Bridge Group. Šī funkcija tika ieviesta Cisco Meeting Server programmatūras versijā 2.1, un tā ir paplašināta, lai atbalstītu slodzes līdzsvarošanu gan ienākošajiem, gan izejošajiem Cisco Meeting App (CMA) zvaniem, tostarp WebRTC dalībniekiem.
Lai atrisinātu atkārtota savienojuma problēmu, katram zvanu tiltam ir ieviesti trīs konfigurējami slodzes ierobežojumi:
LoadLimit — šī ir maksimālā skaitliskā slodze konkrētam Call Bridge. Katrai platformai ir ieteicamais slodzes ierobežojums, piemēram, 96000 CMS1000 un 1.25 GHz uz vCPU virtuālajai mašīnai. Dažādi zvani patērē noteiktu resursu daudzumu atkarībā no dalībnieka izšķirtspējas un kadru ātruma.
NewConferenceLoadLimitBasisPoints (noklusējuma 50% loadLimit) - iestata servera slodzes ierobežojumu, pēc kura tiek noraidītas jaunas konferences.
EsošieConferenceLoadLimitBasisPoints (noklusējuma 80% no loadLimit) — servera slodzes vērtība, pēc kuras dalībnieki, kas pievienosies esošai konferencei, tiks noraidīti.
Lai gan šī funkcija ir paredzēta zvanu sadalei un slodzes līdzsvarošanai, zvanu tilta grupām var piešķirt arī citas grupas, piemēram, TURN serveri, tīmekļa tilta serverus un ierakstītājus, lai tās varētu arī pareizi grupēt optimālai lietošanai. Ja kāds no šiem objektiem nav piešķirts zvanu grupai, tiek pieņemts, ka tie ir pieejami visiem serveriem bez īpašas prioritātes.
Šie parametri ir konfigurēti šeit: :445/api/v1/system/configuration/cluster
Tālāk mēs katram zvanu tiltam norādām, kurai zvanu tiltu grupai tas pieder:
Pirmais zvanu tilts
Otrais zvanu tilts
Trešais zvanu tilts
Tādējādi mēs konfigurējām Call Brdige grupu, lai efektīvāk izmantotu Cisco Meeting Server klastera resursus.
Lietotāju importēšana no Active Directory
Web Admin pakalpojumam ir LDAP konfigurācijas sadaļa, taču tas nenodrošina sarežģītas konfigurācijas iespējas, un informācija netiek glabāta klasteru datu bāzē, tāpēc konfigurācija būs jāveic vai nu manuāli katrā serverī, izmantojot tīmekļa saskarni, vai arī izmantojot API, un lai mēs “trīs reizes “Necelies”, mēs joprojām iestatīsim datus, izmantojot API.
Lai piekļūtu, izmantojiet URL :445/api/v1/ldapServers izveido LDAP servera objektu, norādot tādus parametrus kā:
- Servera IP
- porta numurs
- lietotājvārds
- parole
- garantēt
Drošs — izvēlieties patiesu vai nepatiesu atkarībā no porta, 389 — nav drošs, 636 — aizsargāts.
LDAP avota parametru kartēšana ar atribūtiem programmā Cisco Meeting Server.
LDAP kartēšana kartē atribūtus LDAP direktorijā ar atribūtiem CMS. Faktiskie atribūti:
- jidMapping
- nosaukuma kartēšana
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Atribūtu aprakstsJID apzīmē lietotāja pieteikšanās ID SPS. Tā kā šis ir Microsoft Active Directory LDAP serveris, CMS JID tiek kartēts uz sAMAccountName LDAP, kas būtībā ir lietotāja Active Directory pieteikšanās ID. Ņemiet vērā arī to, ka izmantojat sAMAccountName un tā beigās pievienojat domēnu conf.pod6.cms.lab, jo tas ir pieteikšanās vārds, ko lietotāji izmantos, lai pieteiktos CMS.
nosaukuma kartēšana atbilst laukā Active Directory displayName ietvertajam lietotāja CMS nosaukuma laukam.
coSpaceNameMapping izveido CMS telpas nosaukumu, pamatojoties uz lauku displayName. Šis atribūts kopā ar atribūtu coSpaceUriMapping ir nepieciešams, lai katram lietotājam izveidotu vietu.
coSpaceUriMapping definē URI lietotāja daļu, kas saistīta ar lietotāja personīgo telpu. Dažus domēnus var konfigurēt tā, lai tie tiktu izsaukti kosmosā. Ja lietotāja daļa atbilst šim laukam vienam no šiem domēniem, zvans tiks novirzīts uz šī lietotāja vietu.
coSpaceSecondaryUriMapping definē otru URI, lai sasniegtu vietu. To var izmantot, lai pievienotu ciparu aizstājvārdu zvanu maršrutēšanai importētā lietotāja telpā kā alternatīvu burtciparu URI, kas definēts parametrā coSpaceUriMapping.
LDAP serveris un LDAP kartēšana ir konfigurēti. Tagad tie ir jāsaista kopā, izveidojot LDAP avotu.
Lai piekļūtu, izmantojiet URL :445/api/v1/ldapSource izveido LDAP avota objektu, norādot tādus parametrus kā:
- serveris
- kartografēšana
- bāzeDn
- filtrēt
Tagad, kad LDAP konfigurācija ir pabeigta, varat veikt manuālo sinhronizācijas darbību.
Mēs to darām katra servera tīmekļa saskarnē, noklikšķinot uz Sinhronizēt tūlīt daļa Active Directory
vai caur API ar komandu POST izmantojot URL, lai piekļūtu :445/api/v1/ldapSyncs
Ad-hoc konferences
Kas tas ir?Tradicionālajā koncepcijā konference ir tad, kad divi dalībnieki sarunājas viens ar otru un viens no dalībniekiem (izmantojot Unified CM reģistrētu ierīci) nospiež pogu "Konference", piezvana otrai personai un pēc sarunas ar šo trešo pusi. , vēlreiz nospiež pogu "Konference". lai pievienotos visiem dalībniekiem trīspusējā konferencē.
Ad-Hoc konference atšķir no plānotas konferences CMS ar to, ka speciālā konference nav tikai SIP zvans uz CMS. Kad konferences iniciators otro reizi noklikšķina uz pogas Konference, lai uzaicinātu visus uz vienu un to pašu sapulci, vienotajam CM ir jāveic API zvans uz CMS, lai izveidotu lidojuma konferenci, uz kuru pēc tam tiek pārsūtīti visi zvani. Tas viss notiek dalībnieku nemanot.
Tas nozīmē, ka vienotajam CM ir jākonfigurē API akreditācijas dati un pakalpojuma WebAdmin adrese/ports, kā arī SIP maģistrāle tieši CMS serverim, lai turpinātu zvanu.
Ja nepieciešams, CUCM var dinamiski izveidot atstarpi CMS, lai katrs zvans varētu sasniegt CMS un atbilst ienākošā zvana noteikumam, kas paredzēts atstarpēm.
Integrācija ar CUCM konfigurēts tādā pašā veidā, kā aprakstīts rakstā izņemot to, ka Cisco UCM ir jāizveido trīs CMS maģistrāles, trīs konferenču tilti, SIP drošības profilā jānorāda trīs priekšmetu nosaukumi, maršruta grupas, maršruta saraksti, multivides resursu grupas un multivides resursu grupu saraksti un jāpievieno daži maršrutēšanas noteikumi. uz Cisco sapulču serveri.
SIP drošības profils:
Bagāžnieki:
Katrs bagāžnieks izskatās vienādi:
Konferenču tilts
Katrs konferences tilts izskatās vienādi:
Maršrutu grupa
Maršrutu saraksts
Mediju resursu grupa
Multivides resursu grupu saraksts
Zvanu noteikumi
Atšķirībā no modernākām zvanu pārvaldības sistēmām, piemēram, Unified CM vai Expressway, CMS meklē tikai domēnu laukā SIP Request-URI jauniem zvaniem. Tātad, ja SIP INVITE ir paredzēts malkam: [e-pasts aizsargāts]SPS rūp tikai domēns.com. SPS ievēro šos noteikumus, lai noteiktu, kur maršrutēt zvanu:
1. SPS vispirms mēģina saskaņot SIP domēnu ar domēniem, kas konfigurēti ienākošā zvana noteikumos. Pēc tam šos zvanus var novirzīt uz (“mērķtiecīgām”) vietām vai konkrētiem lietotājiem, iekšējiem IVR vai tieši integrētiem Microsoft Lync/Skype for Business (S4B) galamērķiem.
2. Ja ienākošo zvanu noteikumos nav atbilstības, CMS mēģinās saskaņot zvanu pāradresācijas tabulā konfigurēto domēnu. Ja tiek panākta atbilstība, noteikums var nepārprotami noraidīt zvanu vai pāradresēt zvanu. Šobrīd SPS var pārrakstīt domēnu, kas dažkārt noder Lync domēnu izsaukšanai. Varat arī izvēlēties piespēles metienu, kas nozīmē, ka neviens no laukiem netiks tālāk pārveidots, vai izmantot iekšējo CMS izsaukšanas plānu. Ja zvanu pāradresācijas noteikumi neatbilst, pēc noklusējuma zvans tiek noraidīts. Ņemiet vērā, ka SPS, lai gan zvans ir "pāradresēts", medijs joprojām ir saistīts ar SPS, kas nozīmē, ka tas atradīsies signalizācijas un multivides trafika ceļā.
Tad izejošo zvanu noteikumi attiecas tikai uz pāradresētajiem zvaniem. Šie iestatījumi nosaka adresātus, uz kuriem tiek nosūtīti zvani, maģistrāles veidu (vai tas ir jauns Lync zvans vai standarta SIP zvans) un visus reklāmguvumus, ko var veikt, ja zvanu pāradresācijas kārtulā nav atlasīta pārsūtīšana.
Šeit ir faktiskais žurnāls par to, kas notiek Ad-Hoc konferences laikā
Ekrānuzņēmums to parāda slikti (es nezinu, kā to uzlabot), tāpēc ierakstīšu žurnālu šādi:
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:12Pati Ad-hoc konference:
Ienākošo zvanu noteikumi
Ienākošo zvanu parametru konfigurēšana ir nepieciešama, lai varētu saņemt zvanu CMS. Kā redzējāt LDAP iestatījumos, visi lietotāji tika importēti ar domēnu conf.pod6.cms.lab. Tātad vismaz vēlaties, lai zvani uz šo domēnu tiktu atlasīti telpās. Jums būs arī jāiestata noteikumi visam, kas paredzēts katra CMS servera pilnībā kvalificētam domēna nosaukumam (un varbūt pat IP adresei). Mūsu ārējā zvanu vadība, Unified CM, konfigurēs SIP maģistrāles, kas paredzētas katram CMS serverim atsevišķi. Atkarībā no tā, vai šo SIP maģistrāļu galamērķis ir IP adrese vai servera FQDN, noteiks, vai CMS ir jākonfigurē, lai pieņemtu zvanus, kas novirzīti uz tās IP adresi vai FQDN.
Domēns, kuram ir augstākās prioritātes ienākošā kārtula, tiek izmantots kā domēns jebkurai lietotāja vietai. Kad lietotāji sinhronizē, izmantojot LDAP, CMS automātiski izveido atstarpes, bet tikai lietotāja URI daļu (coSpaceUriMapping), piemēram, user.space. daļa Pilns URI tiek ģenerēts, pamatojoties uz šo noteikumu. Faktiski, ja jūs šajā brīdī pieteiktos Web Bridge, jūs redzētu, ka Space URI nav domēna. Iestatot šo noteikumu kā augstāko prioritāti, jūs iestatāt domēnu ģenerētajām atstarpēm konf.example.com.
Izejošo zvanu noteikumi
Lai lietotāji varētu veikt izejošos zvanus uz vienoto CM klasteru, ir jākonfigurē izejošās kārtulas. Vienotajā CM reģistrēto galapunktu domēns, piemēram, Jabber, ir example.com. Zvani uz šo domēnu ir jānovirza kā standarta SIP zvani uz vienotajiem CM zvanu apstrādes mezgliem. Galvenais serveris ir cucm-01.example.com, bet papildu serveris ir cucm-02.example.com.
Pirmais noteikums apraksta vienkāršāko zvanu maršrutēšanu starp klasteru serveriem.
Lauks Lokāls no domēna ir atbildīgs par to, kas tiks parādīts zvanītāja SIP-URI personai, kurai zvana pēc simbola “@”. Ja atstājam to tukšu, tad aiz simbola “@” būs CUCM IP adrese, caur kuru notiek šis zvans. Ja mēs norādām domēnu, tad pēc simbola “@” faktiski būs domēns. Tas ir nepieciešams, lai varētu atzvanīt, pretējā gadījumā nevarēs atzvanīt pa SIP-URI vārds@ip-adrese.
Zvaniet, kad norādīts Lokāls no domēna
Zvaniet kad NAV norādīts Lokāls no domēna
Noteikti skaidri norādiet Šifrēts vai Nešifrēts izejošajiem zvaniem, jo nekas nedarbojas ar parametru Auto.
Ierakstīšana
Videokonferences ieraksta ierakstu serveris. Ierakstītājs ir tieši tāds pats kā Cisco sapulču serveris. Ierakstītājam nav nepieciešama licenču instalēšana. Ierakstīšanas licences ir nepieciešamas serveriem, kuros darbojas CallBridge pakalpojumi, t.i. ir nepieciešama ierakstīšanas licence, un tā ir jāpiemēro CallBridge komponentam, nevis serverim, kurā darbojas ierakstītājs. Ierakstītājs darbojas kā Extensible Messaging and Presence Protocol (XMPP) klients, tāpēc serverī, kurā tiek mitināts CallBridge, ir jābūt iespējotam XMPP serverim.
Jo Mums ir klasteris, un licence ir “jāizstiepj” visos trīs klastera serveros. Pēc tam vienkārši savā personīgajā kontā licencēs mēs saistām (pievienojam) visu klasterī iekļauto CMS serveru a-interfeisu MAC adreses.
Un šim attēlam vajadzētu būt katrā klastera serverī
Kopumā ir vairāki scenāriji ierakstītāja ievietošanai, taču mēs pieturēsimies pie šī:
Pirms ierakstītāja iestatīšanas jums ir jāsagatavo vieta, kur faktiski tiks ierakstītas video konferences. Patiesībā šeit , kā iestatīt visu ierakstīšanu. Es koncentrējos uz svarīgiem punktiem un detaļām:
1. Labāk ir izslīdēt sertifikātu no klastera pirmā servera.
2. Kļūda “Ierakstītājs nav pieejams” var rasties, jo ierakstīšanas uzticamībā ir norādīts nepareizs sertifikāts.
3. Rakstīšana var nedarboties, ja ierakstīšanai norādītais NFS direktorijs nav saknes direktorijs.
Dažreiz ir nepieciešams automātiski ierakstīt viena konkrēta lietotāja vai telpas konferenci.
Šim nolūkam tiek izveidoti divi zvanu profili:
Ar atspējotu ierakstīšanu
Un ar automātiskās ierakstīšanas funkciju
Tālāk mēs “pievienojam” CallProfile ar automātiskās ierakstīšanas funkciju vajadzīgajai vietai.
SPS ir izveidots tā, ka, ja CallProfile ir skaidri piesaistīts jebkurai telpai vai vietai, tad šis CallProfile darbojas tikai saistībā ar šīm konkrētajām telpām. Un, ja CallProfile nav saistīts ne ar vienu atstarpi, tad pēc noklusējuma tas tiek lietots tām atstarpēm, kurām CallProfile nav skaidri piesaistīts.
Nākamajā reizē mēģināšu aprakstīt, kā CMS tiek piekļūts ārpus organizācijas iekšējā tīkla.
Avoti:
Avots: www.habr.com