W tym numerze pokażę i wyjaśnię niektóre zawiłości związane z konfiguracją serwera CMS w trybie klastra pracy awaryjnej.
TeoriaOgólnie rzecz biorąc, istnieją trzy typy wdrażania serwerów CMS:
- Pojedyncze połączone(Pojedyncze połączone), tj. jest to jeden serwer, na którym działają wszystkie niezbędne usługi. W większości przypadków ten typ wdrożenia jest odpowiedni tylko w przypadku dostępu klientów wewnętrznych oraz w mniejszych środowiskach, gdzie ograniczenia skalowalności i redundancji pojedynczego serwera nie są kwestią krytyczną, lub w sytuacjach, gdy CMS wykonuje tylko określone funkcje, takie jak ad hoc konferencje dotyczące Cisco UCM.
Przybliżony schemat pracy:
- Pojedynczy podział(Single Split) rozszerza poprzedni typ wdrożenia, dodając oddzielny serwer dla dostępu zewnętrznego. W starszych wdrożeniach oznaczało to wdrożenie serwera CMS w segmencie sieci zdemilitaryzowanej (DMZ), gdzie mogliby uzyskać do niego dostęp klienci zewnętrzni, oraz jednego serwera CMS w rdzeniu sieci, gdzie klienci wewnętrzni mogliby uzyskać dostęp do CMS. Ten konkretny model wdrażania jest obecnie zastępowany przez tzw. typ Pojedyncza krawędź, który składa się z serwerów Droga ekspresowa Cisco, które mają lub będą miały wiele takich samych możliwości obejścia zapory ogniowej, dzięki czemu klienci nie będą musieli dodawać dedykowanego brzegowego serwera CMS.
Przybliżony schemat pracy:
- Skalowalny i odporny(Skalowalny i odporny na awarie) Ten typ obejmuje nadmiarowość dla każdego komponentu, umożliwiając rozwój systemu zgodnie z Twoimi potrzebami do maksymalnej wydajności, zapewniając jednocześnie redundancję w przypadku awarii. Wykorzystuje również koncepcję Single Edge, aby zapewnić bezpieczny dostęp zewnętrzny. Właśnie temu typowi przyjrzymy się w tym odcinku. Jeśli zrozumiemy, jak wdrożyć tego typu klaster, zrozumiemy nie tylko inne typy wdrożeń, ale także będziemy w stanie zrozumieć, jak tworzyć klastry serwerów CMS, aby sprostać potencjalnemu wzrostowi popytu.
Zanim przejdziesz do wdrożenia, musisz zrozumieć kilka podstawowych rzeczy, a mianowicie
Główne komponenty oprogramowania CMS:
- Baza danych: umożliwia łączenie niektórych konfiguracji, takich jak plan wybierania numerów, przestrzenie użytkowników i samych użytkowników. Obsługuje klastrowanie tylko w celu zapewnienia wysokiej dostępności (pojedynczy moduł główny).
- Zadzwoń do mostka: usługa konferencji audio i wideo zapewniająca pełną kontrolę nad zarządzaniem i przetwarzaniem połączeń oraz procesów multimedialnych. Obsługuje klastrowanie w celu zapewnienia wysokiej dostępności i skalowalności.
- Serwer XMPP: odpowiedzialny za rejestrację i uwierzytelnianie klientów korzystających z aplikacji Cisco Meeting Application i/lub WebRTC(komunikacja w czasie rzeczywistym lub po prostu w przeglądarce), a także sygnalizacja międzyskładnikowa. Można klastrować tylko w celu zapewnienia wysokiej dostępności.
- Most sieciowy: Zapewnia klientowi dostęp do WebRTC.
- Równoważenie obciążenia: Zapewnia pojedynczy punkt połączenia dla aplikacji Cisco Meeting w trybie pojedynczego podziału. Nasłuchuje zewnętrznego interfejsu i portu dla połączeń przychodzących. Podobnie moduł równoważenia obciążenia akceptuje przychodzące połączenia TLS z serwera XMPP, za pośrednictwem którego może przełączać połączenia TCP od klientów zewnętrznych.
W naszym scenariuszu nie będzie to potrzebne. - OBRÓĆ serwer: Zapewnia technologię obejścia zapory ogniowej, która umożliwia
umieść nasz CMS za zaporą sieciową lub NAT, aby łączyć klientów zewnętrznych za pomocą aplikacji Cisco Meeting lub urządzeń SIP. W naszym scenariuszu nie będzie to potrzebne. - Administrator sieci: Interfejs administracyjny i dostęp API, w tym w przypadku specjalnych konferencji Unified CM.
Tryby konfiguracji
W przeciwieństwie do większości innych produktów Cisco, Cisco Meeting Server obsługuje trzy metody konfiguracji, aby dostosować się do dowolnego typu wdrożenia.
- Wiersz poleceń (CLI): Interfejs wiersza poleceń znany jako MMP do zadań konfiguracji początkowej i certyfikatów.
- Administrator sieci: Głównie w przypadku konfiguracji związanych z CallBridge, szczególnie w przypadku konfigurowania pojedynczego serwera nieklastrowego.
- REST API: Używany do najbardziej złożonych zadań konfiguracyjnych i zadań związanych z klastrową bazą danych.
Oprócz powyższego używany jest protokół SFTP do przesyłania plików — zwykle licencji, certyfikatów lub logów — do i z serwera CMS.
W przewodnikach wdrażania firmy Cisco jest napisane w języku białym i angielskim, że należy wdrożyć klaster co najmniej trzy serwery (węzły) w kontekście baz danych. Ponieważ Dopiero przy nieparzystej liczbie węzłów zadziała mechanizm wyboru nowego Database Mastera i generalnie Database Master ma połączenie z większością baz danych serwera CMS.
A jak pokazuje praktyka, dwa serwery (węzły) to naprawdę za mało. Mechanizm selekcji działa po ponownym uruchomieniu serwera Master, serwer Slave staje się serwerem Master dopiero po uruchomieniu zrestartowanego serwera. Jeśli jednak w klastrze dwóch serwerów serwer Master nagle przestanie działać, wówczas serwer Slave nie stanie się serwerem Master, a jeśli serwer Slave zgaśnie, wówczas pozostały serwer Master stanie się serwerem Slave.
Ale w kontekście XMPP naprawdę konieczne byłoby złożenie klastra trzech serwerów, ponieważ jeżeli np. wyłączysz usługę XMPP na jednym z serwerów, na którym XMMP jest w statusie Lidera, to na pozostałym serwerze XMPP pozostanie w statusie Follower i połączenia CallBridge z XMPP przestaną działać, gdyż CallBridge łączy się wyłącznie z XMPP ze statusem Lidera. A to jest istotne, bo... ani jedno połączenie nie zostanie zrealizowane.
Również w tych samych przewodnikach wdrażania zademonstrowano klaster z jednym serwerem XMPP.
Biorąc pod uwagę powyższe, staje się jasne, dlaczego: działa, ponieważ jest w trybie awaryjnym.
W naszym przypadku serwer XMPP będzie obecny na wszystkich trzech węzłach.
Zakłada się, że wszystkie trzy nasze serwery działają.
Rekordy DNS
Zanim zaczniesz konfigurować serwery, musisz utworzyć rekordy DNS А и SRV typy:
Należy pamiętać, że w naszych rekordach DNS znajdują się dwie domeny example.com i conf.example.com. Przykład.com to domena, której wszyscy subskrybenci programu Cisco Unified Communication Manager mogą używać jako swoich identyfikatorów URI, które najprawdopodobniej są lub będą obecne w Twojej infrastrukturze. Lub example.com pasuje do tej samej domeny, której użytkownicy używają jako swoich adresów e-mail. Lub klient Jabbera na Twoim laptopie może mieć identyfikator URI [email chroniony]. Domena conf.example.com to domena, która zostanie skonfigurowana dla użytkowników Cisco Meeting Server. Domena serwera Cisco Meeting Server będzie conf.example.com, więc w przypadku tego samego użytkownika Jabbera do zalogowania się do Cisco Meeting Server musiałby zostać użyty identyfikator URI użytkownika@conf.example.com.
Konfiguracja podstawowa
Wszystkie opisane poniżej ustawienia są pokazane na jednym serwerze, ale należy je wykonać na każdym serwerze w klastrze.
QoS
Ponieważ CMS generuje w czasie rzeczywistym ruch wrażliwy na opóźnienia i utratę pakietów, w większości przypadków zaleca się skonfigurowanie jakości usług (QoS). Aby to osiągnąć, CMS obsługuje tagowanie pakietów za pomocą generowanych przez siebie kodów usług zróżnicowanych (DSCP). Chociaż priorytetyzacja ruchu oparta na DSCP zależy od tego, jak ruch jest przetwarzany przez komponenty sieciowe Twojej infrastruktury, w naszym przypadku skonfigurujemy nasz CMS z typową priorytetyzacją DSCP w oparciu o najlepsze praktyki QoS.
Na każdym serwerze wprowadzimy te polecenia
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1AZatem cały ruch wideo został oznaczony jako AF41 (DSCP 0x22), cały ruch głosowy został oznaczony jako EF (DSCP 0x2E), inne typy ruchu o niskim opóźnieniu, takie jak SIP i XMPP, wykorzystują AF31 (DSCP 0x1A).
Sprawdzanie:
NTP
Network Time Protocol (NTP) jest ważny nie tylko dla zapewnienia dokładnych znaczników czasu połączeń i konferencji, ale także dla weryfikacji certyfikatów.
Dodaj serwery NTP do swojej infrastruktury za pomocą polecenia takiego jak
ntp server add <server>
W naszym przypadku są dwa takie serwery, więc będą dwie drużyny.
Sprawdzanie:
I ustaw strefę czasową dla naszego serwera
DNS
Serwery DNS dodajemy do CMS-a komendą typu:
dns add forwardzone <domain-name> <server ip>
W naszym przypadku są dwa takie serwery, więc będą dwie drużyny.
Sprawdzanie:
Konfiguracja interfejsu sieciowego
Konfigurujemy interfejs poleceniem typu:
ipv4 <interface> add <address>/<prefix length> <gateway>
Sprawdzanie:
Nazwa serwera (nazwa hosta)
Nazwę serwera ustawiamy poleceniem takim jak:
hostname <name>
I restartujemy.
Na tym kończy się podstawowa konfiguracja.
Certyfikaty
TeoriaCisco Meeting Server wymaga szyfrowanej komunikacji pomiędzy różnymi komponentami, w związku z czym do wszystkich wdrożeń CMS wymagane są certyfikaty X.509. Pomagają zapewnić, że usługi/serwer cieszą się zaufaniem innych serwerów/usług.
Każda usługa wymaga certyfikatu, ale tworzenie oddzielnych certyfikatów dla każdej usługi może prowadzić do zamieszania i niepotrzebnej złożoności. Na szczęście możemy wygenerować parę kluczy publiczny-prywatny certyfikatu, a następnie ponownie wykorzystać je w wielu usługach. W naszym przypadku ten sam certyfikat będzie używany dla Call Bridge, XMPP Server, Web Bridge i Web Admin. Dlatego dla każdego serwera w klastrze należy utworzyć parę publicznych i prywatnych kluczy certyfikatów.
Klastrowanie baz danych wiąże się jednak z pewnymi specjalnymi wymaganiami dotyczącymi certyfikatów i dlatego wymaga własnych certyfikatów, różniących się od certyfikatów innych usług. CMS korzysta z certyfikatu serwera, który jest podobny do certyfikatów używanych przez inne serwery, ale istnieje również certyfikat klienta używany do połączeń z bazami danych. Certyfikaty baz danych służą zarówno do uwierzytelniania, jak i szyfrowania. Zamiast podawać nazwę użytkownika i hasło, aby klient mógł połączyć się z bazą danych, przedstawia certyfikat klienta, któremu serwer ufa. Każdy serwer w klastrze bazy danych będzie korzystał z tej samej pary kluczy publicznych i prywatnych. Dzięki temu wszystkie serwery w klastrze mogą szyfrować dane w taki sposób, że mogą je odszyfrować jedynie inne serwery, które również korzystają z tej samej pary kluczy.
Aby nadmiarowość działała, klastry baz danych muszą składać się z co najmniej 3 serwerów, ale nie więcej niż 5, a maksymalny czas przesyłania w obie strony między dowolnymi elementami klastra wynosi 200 ms. Limit ten jest bardziej restrykcyjny niż w przypadku klastra Call Bridge, dlatego często jest czynnikiem ograniczającym w przypadku wdrożeń rozproszonych geograficznie.
Rola bazy danych w systemie CMS ma wiele unikalnych wymagań. W przeciwieństwie do innych ról wymaga certyfikatu klienta i serwera, przy czym certyfikat klienta zawiera określone pole CN prezentowane serwerowi.
CMS wykorzystuje bazę danych Postgres z jednym masterem i kilkoma całkowicie identycznymi replikami. W danym momencie istnieje tylko jedna podstawowa baza danych („serwer bazy danych”). Pozostali członkowie klastra to repliki lub „klienci baz danych”.
Klaster bazy danych wymaga certyfikatu serwera dedykowanego i certyfikatu klienta. Muszą być podpisane certyfikatami, zwykle wewnętrznym prywatnym urzędem certyfikacji. Ponieważ każdy członek klastra bazy danych może zostać głównym serwerem bazy danych, pary certyfikatów serwera bazy danych i klienta (zawierające klucze publiczny i prywatny) muszą zostać skopiowane na wszystkie serwery, aby mogły przyjąć tożsamość klienta lub serwera bazy danych. Ponadto należy załadować certyfikat główny urzędu certyfikacji, aby umożliwić weryfikację certyfikatów klienta i serwera.
Tworzymy więc żądanie o certyfikat, który będzie używany przez wszystkie usługi serwera z wyjątkiem bazy danych (będzie na to osobne żądanie) za pomocą polecenia takiego jak:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
W CN piszemy ogólną nazwę naszych serwerów. Na przykład, jeśli nazwy hostów naszych serwerów server01, server02, server03, wtedy będzie CN serwer.przyklad.com
To samo robimy na pozostałych dwóch serwerach z tą różnicą, że polecenia będą zawierać odpowiednie „nazwy hostów”
Generujemy dwa żądania o certyfikaty, które będą wykorzystywane przez usługę bazy danych za pomocą poleceń takich jak:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgresgdzie serwer dbcluster и klient dbcluster nazwy naszych wniosków i przyszłych certyfikatów, nazwa hosta1(2)(3) nazwy odpowiednich serwerów.
Tę procedurę wykonujemy tylko na jednym serwerze (!), a certyfikaty i odpowiadające im pliki .key przesyłamy na inne serwery.
Włącz tryb certyfikatu klienta w usługach AD CS
Musisz także scalić certyfikaty dla każdego serwera w jeden plik.W *NIX:
cat server01.cer server02.cer server03.cer > server.cerW systemie Windows/DOS:
copy server01.cer + server02.cer + server03.cer server.cer
I prześlij na każdy serwer:
1. Certyfikat serwera „indywidualny”.
2. Certyfikat główny (wraz z certyfikatami pośrednimi, jeśli występują).
3. Certyfikaty dla bazy danych („serwer” i „klient”) oraz pliki z rozszerzeniem .key, które zostały wygenerowane podczas tworzenia zapytania o certyfikaty bazy danych „serwer” i „klient”. Pliki te muszą być takie same na wszystkich serwerach.
4. Akta wszystkich trzech „indywidualnych” zaświadczeń.
W rezultacie powinieneś otrzymać coś takiego jak ten obraz pliku na każdym serwerze.
Klaster baz danych
Teraz, gdy wszystkie certyfikaty zostały przesłane na serwery CMS, możesz skonfigurować i włączyć klastrowanie baz danych pomiędzy trzema węzłami. Pierwszym krokiem jest wybranie jednego serwera jako węzła głównego klastra bazy danych i jego pełna konfiguracja.
Główna baza danych
Pierwszym krokiem podczas konfigurowania replikacji bazy danych jest określenie certyfikatów, które będą używane w bazie danych. Odbywa się to za pomocą polecenia takiego jak:
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>Teraz powiedzmy CMS-owi, jakiego interfejsu użyć do klastrowania baz danych za pomocą polecenia:
database cluster localnode aNastępnie inicjujemy bazę danych klastra na serwerze głównym poleceniem:
database cluster initialize
Węzły bazy danych klienta
Wykonujemy tę samą procedurę, tylko zamiast polecenia inicjalizacja klastra bazy danych wpisz polecenie takie jak:
database cluster join <ip address existing master>gdzie adres ip istniejący główny adres IP serwera CMS, na którym zainicjowano klaster, po prostu Master.
Działanie naszego klastra baz danych na wszystkich serwerach sprawdzamy poleceniem:
database cluster status
To samo robimy na pozostałym trzecim serwerze.
W rezultacie okazuje się, że naszym pierwszym serwerem jest Master, reszta to Slave.
Usługa administratora sieci
Włącz usługę administratora sieci:
webadmin listen a 445Wybrano port 445, ponieważ port 443 jest używany do uzyskiwania dostępu użytkownika do klienta WWW
Konfigurujemy usługę Web Admin z plikami certyfikatów za pomocą polecenia takiego jak:
webadmin certs <keyfile> <certificatefile> <ca bundle>I włącz funkcję Web Admin za pomocą polecenia:
webadmin enable
Jeśli wszystko jest w porządku, otrzymamy wiersze SUKCES wskazujące, że administrator sieci jest poprawnie skonfigurowany dla sieci i certyfikatu. Funkcjonalność usługi sprawdzamy za pomocą przeglądarki internetowej i wpisujemy adres administratora strony, np.: : 445
Zadzwoń do klastra mostowego
Call Bridge to jedyna usługa obecna w każdym wdrożeniu CMS. Call Bridge to główny mechanizm konferencyjny. Zapewnia także interfejs SIP, dzięki czemu połączenia mogą być kierowane do lub z niego, na przykład przez Cisco Unified CM.
Opisane poniżej polecenia należy wykonać na każdym serwerze posiadającym odpowiednie certyfikaty.
Tak więc:
Certyfikaty kojarzymy z usługą Call Bridge poleceniem typu:
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]Powiązujemy usługi CallBridge z potrzebnym nam interfejsem za pomocą polecenia:
callbridge listen aI zrestartuj usługę za pomocą polecenia:
callbridge restart
Teraz, gdy mamy skonfigurowane mostki połączeń, możemy skonfigurować klastry mostków połączeń. Klastrowanie Call Bridge różni się od klastrowania bazy danych lub XMPP. Call Bridge Cluster może obsługiwać od 2 do 8 węzłów bez żadnych ograniczeń. Zapewnia nie tylko redundancję, ale także równoważenie obciążenia, dzięki czemu konferencje mogą być aktywnie dystrybuowane na serwerach Call Bridge przy użyciu inteligentnej dystrybucji połączeń. CMS posiada dodatkowe funkcje, grupy Call Bridge i powiązane funkcje, które można wykorzystać do dalszego zarządzania.
Klaster mostka wywoławczego konfiguruje się głównie za pomocą interfejsu administratora sieciowego
Opisaną poniżej procedurę należy wykonać na każdym serwerze w klastrze.
W ten sposób
1. Przejdź przez Internet do opcji Konfiguracja > Klaster.
2. w Zadzwoń do tożsamości Bridge Jako unikalną nazwę wpisz callbridge[01,02,03] odpowiadającą nazwie serwera. Nazwy te są dowolne, ale muszą być unikalne dla tego klastra. Mają one charakter opisowy, gdyż wskazują, że są to identyfikatory serwera [01,02,03].
3.B Klastrowe mosty wywoławcze wprowadzić adresy URL administratorów sieci naszych serwerów w klastrze, [01,02,03].example.com:445 w polu Adres. Pamiętaj o określeniu portu. Możesz pozostawić pustą domenę SIP łącza równorzędnego.
4. Do zaufania CallBridge każdego serwera dodaj certyfikat, którego plik zawiera wszystkie certyfikaty naszych serwerów, które scaliliśmy w tym pliku na samym początku za pomocą polecenia typu:
callbridge trust cluster <trusted cluster certificate bundle>I zrestartuj usługę za pomocą polecenia:
callbridge restart
W efekcie na każdym serwerze powinieneś otrzymać taki obrazek:
Klaster XMPP
Usługa XMPP w systemie CMS służy do obsługi całej rejestracji i uwierzytelniania w aplikacjach Cisco Meeting Apps (CMA), w tym w kliencie internetowym CMA WebRTC. Sam Call Bridge działa również jako klient XMPP do celów uwierzytelniania i dlatego musi być skonfigurowany tak jak inni klienci. Odporność na błędy XMPP to funkcja obsługiwana w środowiskach produkcyjnych od wersji 2.1
Opisane poniżej polecenia należy wykonać na każdym serwerze posiadającym odpowiednie certyfikaty.
Tak więc:
Certyfikaty kojarzymy z usługą XMPP poleceniem typu:
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]Następnie zdefiniuj interfejs nasłuchiwania za pomocą polecenia:
xmpp listen aUsługa XMPP wymaga unikalnej domeny. To jest login dla użytkowników. Innymi słowy, gdy użytkownik próbuje zalogować się za pomocą aplikacji CMA (lub klienta WebRTC), wprowadza identyfikator użytkownika@logindomena. W naszym przypadku będzie to userid@conf.example.com. Dlaczego nie jest to po prostu example.com? W naszym konkretnym wdrożeniu wybraliśmy naszą domenę Unified CM, której użytkownicy Jabbera będą używać w Unified CM jako example.com, dlatego potrzebowaliśmy innej domeny dla użytkowników CMS, aby mogli kierować połączenia do i z CMS przez domeny SIP.
Skonfiguruj domenę XMPP za pomocą polecenia takiego jak:
xmpp domain <domain>I włącz usługę XMPP za pomocą polecenia:
xmpp enableW usłudze XMPP należy utworzyć dane uwierzytelniające dla każdego mostka telefonicznego, który będzie używany podczas rejestracji w usłudze XMPP. Nazwy te są dowolne (i nie są powiązane z unikalnymi nazwami skonfigurowanymi na potrzeby klastrowania mostków wywołań). Należy dodać trzy mostki wywołań na jednym serwerze XMPP, a następnie wprowadzić te poświadczenia na innych serwerach XMPP w klastrze, ponieważ ta konfiguracja nie mieści się w bazie danych klastra. Później skonfigurujemy każdy mostek wywoławczy tak, aby używał tej nazwy i sekretu do rejestracji w usłudze XMPP.
Teraz musimy skonfigurować usługę XMPP na pierwszym serwerze z trzema mostkami wywoławczymi callbridge01, callbridge02 i callbridge03. Do każdego konta zostaną przypisane losowe hasła. Zostaną one później wprowadzone na innych serwerach Call Bridge w celu zalogowania się do tego serwera XMPP. Wprowadź następujące polecenia:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03W efekcie sprawdzamy co się stało z poleceniem:
xmpp callbridge list
Dokładnie ten sam obrazek powinien pojawić się na pozostałych serwerach po wykonaniu opisanych poniżej kroków.
Następnie dodajemy dokładnie te same ustawienia na pozostałych dwóch serwerach, tylko za pomocą poleceń
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Sekret dodajemy bardzo ostrożnie, żeby np. nie było w nim dodatkowych spacji.
W rezultacie każdy serwer powinien mieć ten sam obraz:
Następnie na wszystkich serwerach w klastrze podajemy w zaufaniu plik zawierający wszystkie trzy certyfikaty, utworzony wcześniej za pomocą takiego polecenia:
xmpp cluster trust <trust bundle>Włączamy tryb klastra xmpp na wszystkich serwerach klastra za pomocą polecenia:
xmpp cluster enableNa pierwszym serwerze klastra tworzenie klastra xmpp inicjujemy poleceniem:
xmpp cluster initializeNa innych serwerach dodaj klaster do xmpp za pomocą polecenia takiego jak:
xmpp cluster join <ip address head xmpp server>Na każdym serwerze sprawdzamy powodzenie tworzenia klastra XMPP na każdym serwerze za pomocą poleceń:
xmpp status
xmpp cluster statusPierwszy serwer:
Drugi serwer:
Trzeci serwer:
Podłączanie mostka wywoławczego do XMPP
Teraz, gdy klaster XMPP jest uruchomiony, należy skonfigurować usługi mostu wywołań, aby połączyć się z klastrem XMPP. Konfiguracja ta odbywa się za pośrednictwem administratora sieciowego.
Na każdym serwerze przejdź do Konfiguracja > Ogólne i w polu Unikalna nazwa mostka wywoławczego napisz unikalne nazwy odpowiadające serwerowi Call Bridge mostek telefoniczny[01,02,03]. поле Domena conf.example.ru i odpowiadające im hasła, możesz je szpiegować
na dowolnym serwerze w klastrze za pomocą polecenia:
xmpp callbridge list
Pole „Serwer” pozostaw puste Callbridge'a przeprowadzi wyszukiwanie DNS SRV _xmpp-component._tcp.conf.example.comaby znaleźć dostępny serwer XMPP. Adresy IP do podłączenia callbridges do XMPP mogą się różnić na każdym serwerze, zależy to od tego, jakie wartości zwracane są do żądania rekordu _xmpp-component._tcp.conf.example.com callbridge, co z kolei zależy od ustawień priorytetu dla danego rekordu DNS.
Następnie przejdź do Status > Ogólne, aby sprawdzić, czy usługa Call Bride została pomyślnie połączona z usługą XMPP.
Most sieciowy
Na każdym serwerze w klastrze włącz usługę Web Bridge za pomocą polecenia:
webbridge listen a:443Konfigurujemy usługę Web Bridge z plikami certyfikatów za pomocą polecenia takiego jak:
webbridge certs <keyfile> <certificatefile> <ca bundle>Most sieciowy obsługuje protokół HTTPS. Przekieruje HTTP na HTTPS, jeśli zostanie skonfigurowany do używania „przekierowania http”.
Aby włączyć przekierowanie HTTP, użyj następującego polecenia:
webbridge http-redirect enableAby poinformować Call Bridge, że Web Bridge może ufać połączeniom z Call Bridge, użyj polecenia:
webbridge trust <certfile>gdzie jest to plik zawierający wszystkie trzy certyfikaty z każdego serwera w klastrze.
Ten obraz powinien znajdować się na każdym serwerze w klastrze.
Teraz musimy utworzyć użytkownika z rolą „appadmin”, jest nam to potrzebne, abyśmy mogli skonfigurować nasz klaster(!), a nie każdy serwer w klastrze z osobna, w ten sposób ustawienia zostaną zastosowane jednakowo do każdego serwera pomimo fakt, że będą one wykonane jednorazowo.
Do dalszej konfiguracji użyjemy .
Aby uzyskać autoryzację, wybierz opcję Podstawowa w sekcji Autoryzacja
Aby poprawnie wysyłać polecenia do serwera CMS należy ustawić wymagane kodowanie
Podajemy Webbridge poleceniem POST z parametrem url i znaczenie
W samym mostku wskazujemy wymagane parametry: dostęp dla gości, dostęp chroniony itp.
Zadzwoń do grup mostowych
Domyślnie CMS nie zawsze maksymalnie efektywnie wykorzystuje dostępne mu zasoby konferencyjne.
Na przykład w przypadku spotkania z trzema uczestnikami każdy uczestnik może zostać podłączony do trzech różnych mostków telefonicznych. Aby ci trzej uczestnicy mogli się ze sobą komunikować, Call Bridges automatycznie ustanowi połączenia pomiędzy wszystkimi serwerami i klientami w tej samej Przestrzeni, tak aby wszystko wyglądało tak, jakby wszyscy klienci byli na tym samym serwerze. Niestety wadą tego rozwiązania jest to, że pojedyncza konferencja dla 3 osób będzie teraz zużywać 9 portów multimedialnych. Jest to ewidentne nieefektywne wykorzystanie zasobów. Dodatkowo, gdy mostek telefoniczny jest naprawdę przeciążony, domyślnym mechanizmem jest dalsze akceptowanie połączeń i świadczenie usług o obniżonej jakości wszystkim abonentom tego mostka.
Problemy te rozwiązuje się za pomocą funkcji grupy mostków połączeń. Ta funkcja została wprowadzona w wersji 2.1 oprogramowania Cisco Meeting Server i została rozszerzona o obsługę równoważenia obciążenia zarówno dla połączeń przychodzących, jak i wychodzących w aplikacji Cisco Meeting App (CMA), w tym dla uczestników WebRTC.
Aby rozwiązać problem ponownego łączenia, dla każdego mostka telefonicznego wprowadzono trzy konfigurowalne limity obciążenia:
Limit obciążenia — jest to maksymalne obciążenie liczbowe dla danego mostka telefonicznego. Każda platforma ma zalecany limit obciążenia, np. 96000 dla CMS1000 i 1.25 GHz na vCPU dla maszyny wirtualnej. Różne połączenia zużywają pewną ilość zasobów w zależności od rozdzielczości i liczby klatek na sekundę uczestnika.
NewConferenceLoadLimitBasisPoints (domyślnie 50% loadingLimit) - ustawia limit obciążenia serwera, po przekroczeniu którego nowe konferencje są odrzucane.
Istniejące punkty konferencyjneLoadLimitBasis (domyślnie 80% LoadLimit) - wartość obciążenia serwera, po przekroczeniu której uczestnicy dołączający do istniejącej konferencji zostaną odrzuceni.
Chociaż ta funkcja została zaprojektowana do dystrybucji połączeń i równoważenia obciążenia, inne grupy, takie jak serwery TURN, serwery Web Bridge i rejestratory, można również przypisać do grup mostków połączeń, aby można je było odpowiednio pogrupować w celu optymalnego wykorzystania. Jeśli którykolwiek z tych obiektów nie jest przypisany do grupy połączeń, zakłada się, że są one dostępne dla wszystkich serwerów bez określonego priorytetu.
Parametry te konfiguruje się tutaj: :445/api/v1/system/konfiguracja/klaster
Następnie wskazujemy każdemu mostkowi wywoławczemu, do której grupy wywołań należy:
Pierwszy mostek telefoniczny
Drugi mostek wywoławczy
Trzeci mostek wywoławczy
Tym samym skonfigurowaliśmy grupę Call Brdige tak, aby efektywniej wykorzystywać zasoby klastra Cisco Meeting Server.
Importowanie użytkowników z Active Directory
Usługa Web Admin posiada sekcję konfiguracyjną LDAP, ale nie udostępnia skomplikowanych opcji konfiguracyjnych, a informacje nie są przechowywane w bazie danych klastra, więc konfigurację trzeba będzie przeprowadzić albo ręcznie na każdym serwerze poprzez interfejs WWW, albo poprzez API, abyśmy „trzy razy „Nie wstawaj” nadal będziemy ustawiać dane poprzez API.
Korzystanie z adresu URL w celu uzyskania dostępu :445/api/v1/ldapServers tworzy obiekt serwera LDAP, określając takie parametry jak:
- IP serwera
- numer portu
- имя пользователя
- hasło
- bezpieczne
Bezpieczny — wybierz wartość prawda lub fałsz w zależności od portu, 389 — niezabezpieczony, 636 — chroniony.
Mapowanie parametrów źródłowych LDAP na atrybuty w Cisco Meeting Server.
Mapowanie LDAP odwzorowuje atrybuty w katalogu LDAP na atrybuty w systemie CMS. Rzeczywiste atrybuty:
- jidMapping
- mapowanie nazw
- Mapowanie nazwy coSpace
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Opis atrybutówJID reprezentuje identyfikator logowania użytkownika w systemie CMS. Ponieważ jest to serwer LDAP Microsoft Active Directory, identyfikator JID CMS jest odwzorowywany na nazwę sAMAccountName w LDAP, która jest zasadniczo identyfikatorem logowania użytkownika do Active Directory. Pamiętaj też, że bierzesz sAMAccountName i dodajesz na końcu domenę conf.pod6.cms.lab, ponieważ jest to login, którego Twoi użytkownicy będą używać do logowania się do CMS.
mapowanie nazw dopasowuje zawartość pola displayName usługi Active Directory do pola nazwy CMS użytkownika.
Mapowanie nazwy coSpace tworzy nazwę przestrzeni CMS na podstawie pola displayName. Ten atrybut wraz z atrybutem coSpaceUriMapping jest wymagany do utworzenia przestrzeni dla każdego użytkownika.
coSpaceUriMapping definiuje część użytkownika URI powiązaną z przestrzenią osobistą użytkownika. Niektóre domeny można skonfigurować tak, aby łączyły się z przestrzenią kosmiczną. Jeśli część użytkownika pasuje do tego pola dla jednej z tych domen, połączenie zostanie przekierowane do przestrzeni tego użytkownika.
coSpaceSecondaryUriMapping definiuje drugi URI umożliwiający dotarcie do przestrzeni. Można tego użyć do dodania aliasu numerycznego do kierowania połączeń do zaimportowanej przestrzeni użytkownika jako alternatywy do alfanumerycznego identyfikatora URI zdefiniowanego w parametrze coSpaceUriMapping.
Serwer LDAP i mapowanie LDAP są skonfigurowane. Teraz musisz je połączyć, tworząc źródło LDAP.
Korzystanie z adresu URL w celu uzyskania dostępu :445/api/v1/ldapSource tworzy obiekt źródłowy LDAP, określając takie parametry jak:
- serwer
- mapowanie
- podstawaDn
- filtrować
Teraz, gdy konfiguracja LDAP jest już ukończona, możesz przeprowadzić operację ręcznej synchronizacji.
Robimy to albo w interfejsie internetowym każdego serwera, klikając Synchronizuj teraz sekcja Active Directory
lub poprzez API za pomocą polecenia POST używając adresu URL, aby uzyskać dostęp :445/api/v1/ldapSyncs
Konferencje ad hoc
Co to jest?W tradycyjnej koncepcji konferencja ma miejsce wtedy, gdy rozmawia ze sobą dwóch uczestników, a jeden z uczestników (używając urządzenia zarejestrowanego w Unified CM) naciska przycisk „Konferencja”, dzwoni do drugiej osoby i po rozmowie z tą osobą trzecią , ponownie naciśnie przycisk „Konferencja”, aby dołączyć do wszystkich uczestników konferencji trójstronnej.
Tym, co odróżnia konferencję ad-hoc od konferencji zaplanowanej w systemie CMS, jest to, że konferencja ad-hoc to nie tylko połączenie SIP z systemem CMS. Kiedy inicjator konferencji kliknie przycisk Konferencja po raz drugi, aby zaprosić wszystkich na to samo spotkanie, Unified CM musi wykonać wywołanie API do CMS, aby utworzyć konferencję w locie, do której następnie zostaną przeniesione wszystkie połączenia. Wszystko to dzieje się niezauważone przez uczestników.
Oznacza to, że Unified CM musi skonfigurować poświadczenia API oraz adres/port usługi WebAdmin, a także SIP Trunk bezpośrednio do serwera CMS, aby kontynuować połączenie.
Jeśli to konieczne, CUCM może dynamicznie utworzyć przestrzeń w CMS, tak aby każde połączenie mogło dotrzeć do CMS i dopasować regułę połączenia przychodzącego, która jest przeznaczona dla spacji.
Integracja z CUCM skonfigurowany w taki sam sposób, jak opisano w artykule z tą różnicą, że w Cisco UCM musisz utworzyć trzy łącza trunkingowe dla CMS, trzy mostki konferencyjne, w profilu zabezpieczeń SIP określić trzy nazwy podmiotów, grupy tras, listy tras, grupy zasobów multimediów i listy grup zasobów multimediów oraz dodać kilka reguł routingu do serwera Cisco Meeting.
Profil bezpieczeństwa SIP:
Kąpielówki:
Każdy bagażnik wygląda tak samo:
Most konferencyjny
Każdy mostek konferencyjny wygląda tak samo:
Grupa tras
Lista tras
Grupa zasobów medialnych
Lista grup zasobów multimedialnych
Zasady rozmów
W przeciwieństwie do bardziej zaawansowanych systemów zarządzania połączeniami, takich jak Unified CM lub Expressway, CMS wyszukuje domenę tylko w polu SIP Request-URI pod kątem nowych połączeń. Więc jeśli SIP INVITE jest przeznaczony do łykania: [email chroniony]CMS dba tylko o domenę.com. CMS postępuje zgodnie z poniższymi regułami, aby określić, dokąd przekierować połączenie:
1. CMS najpierw próbuje dopasować domenę SIP do domen skonfigurowanych w regułach połączeń przychodzących. Połączenia te można następnie przekierować do („docelowych”) przestrzeni lub określonych użytkowników, wewnętrznych systemów IVR lub bezpośrednio zintegrowanych miejsc docelowych Microsoft Lync/Skype dla firm (S4B).
2. Jeżeli w regułach połączeń przychodzących nie ma zgodności, CMS spróbuje dopasować domenę skonfigurowaną w tabeli przekazywania połączeń. W przypadku dopasowania reguła może jawnie odrzucić połączenie lub przekazać je dalej. W tej chwili system CMS może przepisać domenę, co czasami jest przydatne do wywoływania domen programu Lync. Możesz także zdecydować się na przekazanie rzutu, co oznacza, że żadne z pól nie będzie dalej modyfikowane, lub skorzystać z wewnętrznego planu wybierania CMS. Jeśli zasady przekazywania połączeń nie są zgodne, połączenie jest domyślnie odrzucane. Należy pamiętać, że w CMS-ie, mimo że połączenie jest „przekierowane”, media nadal są powiązane z CMS-em, czyli będą w ścieżce sygnalizacji i ruchu medialnego.
Wówczas regułom połączeń wychodzących podlegają wyłącznie połączenia przekierowane. Te ustawienia określają miejsca docelowe, do których są wysyłane połączenia, typ łącza (czy jest to nowe połączenie programu Lync, czy standardowe połączenie SIP) oraz wszelkie konwersje, które można wykonać, jeśli w regule przekazywania połączeń nie zostanie wybrane przekierowanie.
Oto aktualny zapis tego, co dzieje się podczas konferencji ad hoc
Na zrzucie ekranu słabo to widać (nie wiem jak to poprawić), więc napiszę log w ten sposób:
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:12Sama konferencja ad-hoc:
Zasady połączeń przychodzących
Aby móc odebrać połączenie w CMS-ie, konieczne jest skonfigurowanie parametrów połączeń przychodzących. Jak widać podczas konfiguracji LDAP, wszyscy użytkownicy zostali zaimportowani z domeną conf.pod6.cms.lab. Zatem co najmniej chcesz, aby wywołania tej domeny były kierowane na przestrzenie. Będziesz także musiał skonfigurować reguły dla wszystkiego, co jest przeznaczone dla w pełni kwalifikowanej nazwy domeny (a może nawet adresu IP) każdego z serwerów CMS. Nasza zewnętrzna kontrola połączeń, Unified CM, skonfiguruje łącza SIP trunk dedykowane dla każdego z serwerów CMS indywidualnie. W zależności od tego, czy miejscem docelowym tych łączy SIP trunk jest adres IP, czy nazwa FQDN serwera, zostanie ustalone, czy system CMS musi być skonfigurowany tak, aby akceptował połączenia kierowane na jego adres IP lub nazwę FQDN.
Domena posiadająca regułę ruchu przychodzącego o najwyższym priorytecie jest używana jako domena wszystkich przestrzeni użytkowników. Kiedy użytkownicy synchronizują się za pośrednictwem LDAP, CMS automatycznie tworzy spacje, ale tylko część identyfikatora URI użytkownika (coSpaceUriMapping), na przykład user.space. Część Na podstawie tej reguły generowany jest pełny identyfikator URI. Tak naprawdę, jeśli w tym momencie zalogujesz się do Web Bridge, zobaczysz, że Space URI nie ma domeny. Ustawiając tę regułę jako najwyższy priorytet, ustawiasz domenę, w której będą generowane przestrzenie por.przykład.com.
Zasady połączeń wychodzących
Aby umożliwić użytkownikom wykonywanie wywołań wychodzących do klastra Unified CM, należy skonfigurować reguły ruchu wychodzącego. Domena punktów końcowych zarejestrowanych w Unified CM, takich jak Jabber, to example.com. Połączenia do tej domeny powinny być kierowane jako standardowe połączenia SIP do węzłów przetwarzania połączeń Unified CM. Serwer główny to cucm-01.example.com, a dodatkowy to cucm-02.example.com.
Pierwsza reguła opisuje najprostsze kierowanie wywołań pomiędzy serwerami klastra.
Pole Lokalnie z domeny odpowiada za to, co będzie wyświetlane w SIP-URI osoby dzwoniącej po symbolu „@”. Jeśli pozostawimy to pole puste, to po symbolu „@” pojawi się adres IP CUCM, przez który przechodzi to połączenie. Jeśli określimy domenę, to po symbolu „@” faktycznie pojawi się domena. Jest to konieczne, aby móc oddzwonić, w przeciwnym razie oddzwonienie poprzez SIP-URI nazwa@adres IP nie będzie możliwe.
Zadzwoń, gdy zostanie to wskazane Lokalnie z domeny
Zadzwoń, kiedy NIE wskazany Lokalnie z domeny
Pamiętaj, aby jawnie określić opcję Zaszyfrowane lub Nieszyfrowane dla połączeń wychodzących, ponieważ nic nie działa z parametrem Auto.
Nagranie
Wideokonferencje nagrywane są przez serwer Record. Rejestrator jest dokładnie taki sam jak Cisco Meeting Server. Rejestrator nie wymaga instalacji żadnych licencji. Licencje na nagrywanie wymagane są dla serwerów obsługujących usługi CallBridge, tj. wymagana jest licencja na nagrywanie, którą należy zastosować do komponentu CallBridge, a nie do serwera, na którym działa Rejestrator. Rejestrator zachowuje się jak klient Extensible Messaging and Presence Protocol (XMPP), dlatego na serwerze obsługującym CallBridge musi być włączony serwer XMPP.
Ponieważ Mamy klaster i licencja musi zostać „rozciągnięta” na wszystkie trzy serwery w klastrze. Następnie po prostu na Twoim koncie osobistym w licencjach kojarzymy (dodajemy) adresy MAC interfejsów a wszystkich serwerów CMS zawartych w klastrze.
I taki obraz powinien znajdować się na każdym serwerze w klastrze
Ogólnie rzecz biorąc, istnieje kilka scenariuszy umieszczenia Rejestratora, ale będziemy się tego trzymać:
Przed skonfigurowaniem Rejestratora należy przygotować miejsce, w którym faktycznie będą nagrywane wideokonferencje. Właściwie tutaj , jak skonfigurować całe nagrywanie. Skupiam się na ważnych punktach i szczegółach:
1. Lepiej zsunąć certyfikat z pierwszego serwera w klastrze.
2. Błąd „Rejestrator niedostępny” może wystąpić, ponieważ w zaufaniu rejestratora określono nieprawidłowy certyfikat.
3. Zapisywanie może nie działać, jeśli katalog NFS określony do nagrywania nie jest katalogiem głównym.
Czasami zachodzi potrzeba automatycznego nagrywania konferencji jednego konkretnego użytkownika lub przestrzeni.
W tym celu tworzone są dwa profile połączeń:
Z wyłączonym nagrywaniem
Oraz z funkcją automatycznego nagrywania
Następnie „dołączamy” CallProfile z funkcją automatycznego nagrywania do wymaganej przestrzeni.
W CMS jest tak ustalone, że jeśli CallProfile jest wyraźnie powiązany z jakąkolwiek przestrzenią lub przestrzenią, wówczas ten CallProfile działa tylko w odniesieniu do tych konkretnych przestrzeni. A jeśli CallProfile nie jest powiązany z żadną przestrzenią, domyślnie jest on stosowany do tych spacji, z którymi żaden CallProfile nie jest jawnie powiązany.
Następnym razem postaram się opisać sposób dostępu do CMS-a poza siecią wewnętrzną organizacji.
Źródła:
Źródło: www.habr.com