🥇Server Pertemuan Cisco 2.5.2. Cluster dalam mode Scalable dan Resilient dengan perekaman konferensi video

Pada edisi kali ini saya akan menunjukkan dan menjelaskan beberapa seluk-beluk pengaturan server CMS dalam mode cluster failover.

TeoriSecara umum, ada tiga jenis penerapan server CMS:

Gabungan Tunggal(Gabungan tunggal), mis. ini adalah satu server tempat semua layanan yang diperlukan berjalan. Dalam kebanyakan kasus, jenis penerapan ini hanya cocok untuk akses klien internal dan dalam lingkungan yang lebih kecil di mana batasan skalabilitas dan redundansi dari satu server bukan merupakan masalah kritis, atau dalam situasi di mana CMS hanya menjalankan fungsi tertentu, seperti ad hoc konferensi di Cisco UCM.
Perkiraan skema kerja:

Pemisahan Tunggal(Single Split) memperluas jenis penerapan sebelumnya dengan menambahkan server terpisah untuk akses eksternal. Dalam penerapan lama, hal ini berarti menerapkan server CMS di segmen jaringan demiliterisasi (DMZ) yang dapat diakses oleh klien eksternal, dan satu server CMS di inti jaringan tempat klien internal dapat mengakses CMS. Model penerapan khusus ini sekarang digantikan oleh apa yang disebut tipe Tepi Tunggal, yang terdiri dari server Jalan Tol Cisco, yang memiliki atau akan memiliki banyak kemampuan bypass Firewall yang sama sehingga klien tidak perlu menambahkan server edge CMS khusus.
Perkiraan skema kerja:

Skalabel dan Tangguh(Scalable dan Fault Tolerant) Jenis ini mencakup redundansi untuk setiap komponen, memungkinkan sistem berkembang sesuai kebutuhan Anda hingga kapasitas maksimumnya sekaligus memberikan redundansi jika terjadi kegagalan. Ia juga menggunakan konsep Single Edge untuk menyediakan akses eksternal yang aman. Ini adalah tipe yang akan kita lihat di episode ini. Jika kita memahami cara menerapkan cluster jenis ini, kita tidak hanya akan memahami jenis penerapan lainnya, tetapi kita juga akan dapat memahami cara membuat cluster server CMS untuk mengakomodasi potensi pertumbuhan permintaan.

Sebelum melanjutkan ke penerapan, Anda perlu memahami beberapa hal dasar yaitu

Komponen perangkat lunak CMS utama:

Basis Data: Memungkinkan Anda menggabungkan beberapa konfigurasi, seperti dial plan, ruang pengguna, dan pengguna itu sendiri. Mendukung pengelompokan hanya untuk ketersediaan tinggi (master tunggal).
panggilan jembatan: layanan konferensi audio dan video yang memberikan kontrol penuh atas pengelolaan dan pemrosesan panggilan dan proses multimedia. Mendukung pengelompokan untuk ketersediaan dan skalabilitas tinggi.
server XMPP: bertanggung jawab atas registrasi dan autentikasi klien yang menggunakan Aplikasi Cisco Meeting dan/atau WebRTC(komunikasi real-time, atau hanya di browser), serta pensinyalan antarkomponen. Dapat dikelompokkan hanya untuk ketersediaan tinggi.
Jembatan Web: Menyediakan akses klien ke WebRTC.
Penyeimbang beban: Menyediakan titik koneksi tunggal untuk Aplikasi Rapat Cisco dalam mode Single Split. Mendengarkan antarmuka eksternal dan port untuk koneksi masuk. Demikian pula, penyeimbang beban menerima koneksi TLS masuk dari server XMPP, yang melaluinya ia dapat mengalihkan koneksi TCP dari klien eksternal.
Dalam skenario kami, hal itu tidak diperlukan.
MENGHIDUPKAN server: Menyediakan teknologi bypass Firewall yang memungkinkan
letakkan CMS kami di belakang Firewall atau NAT untuk menghubungkan klien eksternal menggunakan Cisco Meeting App atau perangkat SIP. Dalam skenario kami, hal itu tidak diperlukan.
Admin Web: Antarmuka administratif dan akses API, termasuk untuk konferensi CM Terpadu khusus.

Mode Konfigurasi

Tidak seperti kebanyakan produk Cisco lainnya, Cisco Meeting Server mendukung tiga metode konfigurasi untuk mengakomodasi semua jenis penerapan.

Baris perintah (CLI): Antarmuka baris perintah yang dikenal sebagai MMP untuk konfigurasi awal dan tugas sertifikat.
Administrator Web: Terutama untuk konfigurasi terkait CallBridge, terutama saat menyiapkan satu server non-cluster.
SISA API: Digunakan untuk tugas konfigurasi paling kompleks dan tugas terkait database berkerumun.

Selain di atas, protokol digunakan SFTP untuk mentransfer file—biasanya lisensi, sertifikat, atau log—ke dan dari server CMS.

Dalam panduan penerapan dari Cisco tertulis dalam bahasa putih dan bahasa Inggris bahwa cluster perlu dikerahkan setidaknya tiga server (node) dalam konteks database. Karena Hanya dengan jumlah node ganjil maka mekanisme pemilihan Database Master baru akan berfungsi, dan pada umumnya Database Master mempunyai koneksi dengan sebagian besar database server CMS.

Dan seperti yang diperlihatkan oleh praktik, dua server (node) sebenarnya tidak cukup. Mekanisme pemilihan bekerja ketika Master di-boot ulang, server Slave menjadi Master hanya setelah server yang di-boot ulang ditampilkan. Namun jika dalam cluster dua server tiba-tiba server Master padam, maka server Slave tidak akan menjadi Master, dan jika Slave padam, maka server Master yang tersisa akan menjadi Slave.

Namun dalam konteks XMPP, sangat diperlukan untuk merakit sebuah cluster yang terdiri dari tiga server, karena jika misalnya anda menonaktifkan layanan XMPP pada salah satu server yang XMMP berstatus Leader, maka pada server yang tersisa XMPP akan tetap berstatus Follower dan koneksi CallBridge ke XMPP akan terputus, karena CallBridge terhubung secara eksklusif ke XMPP dengan status Leader. Dan ini penting, karena... tidak ada satu panggilan pun yang tersambung.

Juga dalam panduan penerapan yang sama, sebuah cluster dengan satu server XMPP diperlihatkan.

Dan dengan mempertimbangkan hal di atas, menjadi jelas alasannya: ini berfungsi karena berada dalam mode failover.

Dalam kasus kami, server XMPP akan hadir di ketiga node.

Diasumsikan ketiga server kami aktif.

Catatan DNS

Sebelum Anda mulai menyiapkan server, Anda perlu membuat catatan DNS А и SRV jenis:

Harap dicatat bahwa dalam catatan DNS kami ada dua domain example.com dan conf.example.com. Contoh.com adalah domain yang dapat digunakan oleh semua pelanggan Cisco Unified Communication Manager untuk URI mereka, yang kemungkinan besar ada atau mungkin ada di infrastruktur Anda. Atau example.com cocok dengan domain yang sama yang digunakan pengguna untuk alamat email mereka. Atau klien Jabber di laptop Anda mungkin memiliki URI [email dilindungi]. Domain conf.example.com adalah domain yang akan dikonfigurasi untuk pengguna Cisco Meeting Server. Domain dari Cisco Meeting Server adalah conf.example.com, jadi untuk pengguna Jabber yang sama, user@ URI perlu digunakan untuk login ke Cisco Meeting Serverconf.example.com.

Konfigurasi dasar

Semua pengaturan yang dijelaskan di bawah ini ditampilkan pada satu server, namun harus dilakukan pada setiap server di cluster.

QoS

Sejak CMS menghasilkan real-time lalu lintas sensitif terhadap penundaan dan kehilangan paket, dalam banyak kasus disarankan untuk mengkonfigurasi kualitas layanan (QoS). Untuk mencapai hal ini, CMS mendukung penandaan paket dengan Kode Layanan Diferensiasi (DSCP) yang dihasilkannya. Meskipun prioritas lalu lintas berbasis DSCP bergantung pada bagaimana lalu lintas diproses oleh komponen jaringan infrastruktur Anda, dalam kasus kami, kami akan mengonfigurasi CMS kami dengan prioritas DSCP tipikal berdasarkan praktik terbaik QoS.

Di setiap server kami akan memasukkan perintah ini

dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1A

Jadi, semua lalu lintas video ditandai AF41 (DSCP 0x22), semua lalu lintas suara ditandai EF (DSCP 0x2E), jenis lalu lintas latensi rendah lainnya seperti SIP dan XMPP menggunakan AF31 (DSCP 0x1A).

Kami memeriksa:

NTP

Network Time Protocol (NTP) penting tidak hanya untuk memberikan stempel waktu panggilan dan konferensi yang akurat, namun juga untuk memverifikasi sertifikat.

Tambahkan server NTP ke infrastruktur Anda dengan perintah seperti

ntp server add <server>

Dalam kasus kami, ada dua server seperti itu, jadi akan ada dua tim.
Kami memeriksa:

Dan atur zona waktu untuk server kami

DNS

Kami menambahkan server DNS ke CMS dengan perintah seperti:

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

Dalam kasus kami, ada dua server seperti itu, jadi akan ada dua tim.
Kami memeriksa:

Konfigurasi Antarmuka Jaringan

Kami mengkonfigurasi antarmuka dengan perintah seperti:

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

Kami memeriksa:

Nama server (Nama Host)

Kami menetapkan nama server dengan perintah seperti:

hostname <name>

Dan kami reboot.

Ini menyelesaikan konfigurasi dasar.

Sertifikat

TeoriCisco Meeting Server memerlukan komunikasi terenkripsi antara berbagai komponen, dan oleh karena itu, sertifikat X.509 diperlukan untuk semua penerapan CMS. Mereka membantu memastikan bahwa layanan/server dipercaya oleh server/layanan lain.

Setiap layanan memerlukan sertifikat, namun membuat sertifikat terpisah untuk setiap layanan dapat menimbulkan kebingungan dan kerumitan yang tidak perlu. Untungnya, kami dapat membuat pasangan kunci publik-pribadi sertifikat dan kemudian menggunakannya kembali di beberapa layanan. Dalam kasus kami, sertifikat yang sama akan digunakan untuk Call Bridge, XMPP Server, Web Bridge dan Web Admin. Oleh karena itu, Anda perlu membuat sepasang kunci sertifikat publik dan privat untuk setiap server di cluster.

Namun, pengelompokan basis data memiliki beberapa persyaratan sertifikat khusus dan oleh karena itu memerlukan sertifikatnya sendiri yang berbeda dari sertifikat layanan lainnya. CMS menggunakan sertifikat server, yang serupa dengan sertifikat yang digunakan oleh server lain, namun ada juga sertifikat klien yang digunakan untuk koneksi database. Sertifikat basis data digunakan untuk otentikasi dan enkripsi. Alih-alih memberikan nama pengguna dan kata sandi bagi klien untuk terhubung ke database, ia menyajikan sertifikat klien yang dipercaya oleh server. Setiap server di cluster database akan menggunakan pasangan kunci publik dan privat yang sama. Hal ini memungkinkan semua server di cluster untuk mengenkripsi data sedemikian rupa sehingga hanya dapat didekripsi oleh server lain yang juga berbagi pasangan kunci yang sama.

Agar redundansi berfungsi, cluster database harus terdiri dari minimal 3 server, namun tidak lebih dari 5, dengan waktu bolak-balik maksimum 200 ms antar anggota cluster. Batasan ini lebih ketat dibandingkan pengelompokan Call Bridge, sehingga sering kali menjadi faktor pembatas dalam penerapan yang tersebar secara geografis.

Peran database untuk CMS memiliki sejumlah persyaratan unik. Berbeda dengan peran lainnya, peran ini memerlukan sertifikat klien dan server, di mana sertifikat klien memiliki bidang CN tertentu yang disajikan ke server.

CMS menggunakan database postgres dengan satu master dan beberapa replika yang sepenuhnya identik. Hanya ada satu database utama pada satu waktu (“server database”). Anggota cluster yang tersisa adalah replika atau "klien database".

Klaster database memerlukan sertifikat server khusus dan sertifikat klien. Mereka harus ditandatangani oleh sertifikat, biasanya otoritas sertifikat swasta internal. Karena setiap anggota cluster database dapat menjadi master, server database dan pasangan sertifikat klien (berisi kunci publik dan privat) harus disalin ke semua server sehingga mereka dapat mengambil identitas klien atau server database. Selain itu, sertifikat root CA harus dimuat untuk memastikan bahwa sertifikat klien dan server dapat diverifikasi.

Jadi, kita membuat permintaan sertifikat yang akan digunakan oleh semua layanan server kecuali database (akan ada permintaan terpisah untuk ini) dengan perintah seperti:

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

Di CN kami menulis nama umum server kami. Misalnya, jika nama host server kami server01, server02, server03, maka CN akan menjadi server.contoh.com

Kami melakukan hal yang sama pada dua server yang tersisa dengan perbedaan bahwa perintah akan berisi “nama host” yang sesuai

Kami menghasilkan dua permintaan sertifikat yang akan digunakan oleh layanan database dengan perintah seperti:

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

pki csr dbclusterclient CN:postgres

dimana serverdbcluster и klien dbcluster nama permintaan kami dan sertifikat masa depan, nama host1(2)(3) nama server yang sesuai.

Kami melakukan prosedur ini hanya di satu server (!), dan kami akan mengunggah sertifikat dan file .key terkait ke server lain.

Aktifkan mode sertifikat klien di AD CS

Anda juga perlu menggabungkan sertifikat untuk setiap server menjadi satu file.Di *NIX:

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

Di Windows/DOS:

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

Dan unggah ke setiap server:
1. Sertifikat server “Individu”.
2. Sertifikat root (bersama dengan sertifikat perantara, jika ada).
3. Sertifikat untuk database (“server” dan “klien”) dan file dengan ekstensi .key, yang dihasilkan saat membuat permintaan untuk sertifikat database “server” dan “klien”. File-file ini harus sama di semua server.
4. File ketiga sertifikat “individu”.

Hasilnya, Anda akan mendapatkan gambar file seperti ini di setiap server.

Gugus Basis Data

Sekarang setelah Anda memiliki semua sertifikat yang diunggah ke server CMS, Anda dapat mengonfigurasi dan mengaktifkan pengelompokan database antara ketiga node. Langkah pertama adalah memilih satu server sebagai node master cluster database dan mengkonfigurasinya sepenuhnya.

Basis Data Utama

Langkah pertama dalam menyiapkan replikasi database adalah menentukan sertifikat yang akan digunakan untuk database. Ini dilakukan dengan menggunakan perintah seperti:

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

Sekarang mari beri tahu CMS antarmuka mana yang akan digunakan untuk pengelompokan basis data dengan perintah:

database cluster localnode a

Kemudian kita inisialisasi database cluster di server utama dengan perintah:

database cluster initialize

Node Basis Data Klien

Kami melakukan prosedur yang sama, hanya saja alih-alih perintah inisialisasi cluster database masukkan perintah seperti:

database cluster join <ip address existing master>

dimana alamat ip alamat ip master yang ada dari server CMS tempat kluster diinisialisasi, cukup Master.

Kami memeriksa cara kerja cluster database kami di semua server dengan perintah:

database cluster status

Kami melakukan hal yang sama pada server ketiga yang tersisa.

Hasilnya, ternyata server pertama kita adalah Master, selebihnya adalah Slave.

Layanan Admin Web

Aktifkan layanan administrator web:

webadmin listen a 445

Port 445 dipilih karena port 443 digunakan untuk akses pengguna ke web client

Kami mengkonfigurasi layanan Admin Web dengan file sertifikat dengan perintah seperti:

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

Dan aktifkan Web Admin dengan perintah:

webadmin enable

Jika semuanya baik-baik saja, kami akan menerima baris SUCCESS yang menunjukkan bahwa Admin Web dikonfigurasi dengan benar untuk jaringan dan sertifikat. Kami memeriksa fungsionalitas layanan menggunakan browser web dan memasukkan alamat administrator web, misalnya: cms.example.com: 445

Panggil Cluster Jembatan

Call Bridge adalah satu-satunya layanan yang ada di setiap penerapan CMS. Call Bridge adalah mekanisme konferensi utama. Ia juga menyediakan antarmuka SIP sehingga panggilan dapat dialihkan ke atau darinya, misalnya dengan Cisco Unified CM.

Perintah yang dijelaskan di bawah ini harus dijalankan di setiap server dengan sertifikat yang sesuai.
Jadi:

Kami mengaitkan sertifikat dengan layanan Call Bridge dengan perintah seperti:

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

Kami mengikat layanan CallBridge ke antarmuka yang kami perlukan dengan perintah:

callbridge listen a

Dan restart layanan dengan perintah:

callbridge restart

Sekarang setelah Call Bridges kita terkonfigurasi, kita dapat mengkonfigurasi pengelompokan Call Bridge. Pengelompokan Call Bridge berbeda dengan pengelompokan database atau XMPP. Call Bridge Cluster dapat mendukung 2 hingga 8 node tanpa batasan apa pun. Ini tidak hanya memberikan redundansi, tetapi juga penyeimbangan beban sehingga konferensi dapat didistribusikan secara aktif ke seluruh server Call Bridge menggunakan distribusi panggilan cerdas. CMS memiliki fitur tambahan, grup Call Bridge dan fitur terkait yang dapat digunakan untuk pengelolaan lebih lanjut.

Pengelompokan jembatan panggilan dikonfigurasikan terutama melalui antarmuka admin web
Prosedur yang dijelaskan di bawah ini harus dilakukan pada setiap server di cluster.
Dengan demikian,

1. Buka web ke Konfigurasi > Cluster.
2. Masuk Hubungi identitas Bridge Sebagai nama unik, masukkan callbridge[01,02,03] yang sesuai dengan nama server. Nama-nama ini sewenang-wenang, namun harus unik untuk cluster ini. Mereka bersifat deskriptif karena menunjukkan bahwa mereka adalah pengidentifikasi server [01,02,03].
3.B Jembatan Panggilan Berkelompok masukkan URL administrator web server kami di cluster, cms[01,02,03].example.com:445, di bidang Alamat. Pastikan untuk menentukan port. Anda dapat membiarkan domain SIP tautan rekan kosong.
4. Tambahkan sertifikat ke kepercayaan CallBridge setiap server, file yang berisi semua sertifikat server kami, yang kami gabungkan ke dalam file ini di awal, dengan perintah seperti:

callbridge trust cluster <trusted cluster certificate bundle>

Dan restart layanan dengan perintah:

callbridge restart

Hasilnya, di setiap server Anda akan mendapatkan gambar ini:

Kluster XMPP

Layanan XMPP di CMS digunakan untuk menangani semua registrasi dan otentikasi untuk Cisco Meeting Apps (CMA), termasuk klien web CMA WebRTC. Call Bridge sendiri juga bertindak sebagai klien XMPP untuk tujuan otentikasi dan oleh karena itu harus dikonfigurasi seperti klien lainnya. Toleransi kesalahan XMPP adalah fitur yang telah didukung di lingkungan produksi sejak versi 2.1

Perintah yang dijelaskan di bawah ini harus dijalankan di setiap server dengan sertifikat yang sesuai.
Jadi:

Kami mengaitkan sertifikat dengan layanan XMPP dengan perintah seperti:

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

Kemudian tentukan antarmuka mendengarkan dengan perintah:

xmpp listen a

Layanan XMPP memerlukan domain unik. Ini adalah login untuk pengguna. Dengan kata lain, saat pengguna mencoba masuk menggunakan aplikasi CMA (atau melalui klien WebRTC), mereka memasukkan ID pengguna@logindomain. Dalam kasus kami ini adalah userid@conf.example.com. Mengapa bukan example.com saja? Dalam penerapan khusus kami, kami memilih domain CM Terpadu yang akan digunakan pengguna Jabber di CM Terpadu sebagai example.com, jadi kami memerlukan domain berbeda bagi pengguna CMS untuk merutekan panggilan ke dan dari CMS melalui domain SIP.

Siapkan domain XMPP menggunakan perintah seperti:

xmpp domain <domain>

Dan aktifkan layanan XMPP dengan perintah:

xmpp enable

Pada layanan XMPP, Anda harus membuat kredensial untuk setiap Call Bridge yang akan digunakan saat mendaftar pada layanan XMPP. Nama-nama ini bersifat arbitrer (dan tidak terkait dengan nama unik yang Anda konfigurasikan untuk pengelompokan jembatan panggilan). Anda harus menambahkan tiga jembatan panggilan pada satu server XMPP dan kemudian memasukkan kredensial tersebut pada server XMPP lain di cluster karena konfigurasi ini tidak sesuai dengan database cluster. Nanti kita akan mengkonfigurasi setiap Call Bridge untuk menggunakan nama dan rahasia ini untuk mendaftar ke layanan XMPP.

Sekarang kita perlu mengkonfigurasi layanan XMPP di server pertama dengan tiga Call Bridge callbridge01, callbridge02 dan callbridge03. Setiap akun akan diberikan kata sandi acak. Mereka nantinya akan dimasukkan pada server Call Bridge lain untuk login ke server XMPP ini. Masukkan perintah berikut:

xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03

Hasilnya, kami memeriksa apa yang terjadi dengan perintah:

xmpp callbridge list

Gambaran yang sama persis akan muncul di server yang tersisa setelah langkah-langkah yang dijelaskan di bawah ini.

Selanjutnya, kami menambahkan pengaturan yang persis sama pada dua server yang tersisa, hanya dengan perintah

xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03

Kami menambahkan Rahasia dengan sangat hati-hati sehingga, misalnya, tidak ada spasi tambahan di dalamnya.

Hasilnya, setiap server harus memiliki gambaran yang sama:

Selanjutnya, di semua server di cluster, kami menentukan file kepercayaan yang berisi ketiga sertifikat, yang dibuat sebelumnya dengan perintah seperti ini:

xmpp cluster trust <trust bundle>

Kami mengaktifkan mode cluster xmpp di semua server cluster dengan perintah:

xmpp cluster enable

Di server pertama cluster, kami memulai pembuatan cluster xmpp dengan perintah:

xmpp cluster initialize

Di server lain, tambahkan cluster ke xmpp dengan perintah seperti:

xmpp cluster join <ip address head xmpp server>

Kami memeriksa di setiap server keberhasilan pembuatan cluster XMPP di setiap server dengan perintah:

xmpp status
xmpp cluster status

Server pertama:

Server kedua:

Server ketiga:

Menghubungkan Call Bridge ke XMPP

Sekarang cluster XMPP sedang berjalan, Anda perlu mengkonfigurasi layanan Call Bridge untuk terhubung ke cluster XMPP. Konfigurasi ini dilakukan melalui web admin.

Di setiap server, buka Konfigurasi > Umum dan di lapangan Nama Jembatan Panggilan Unik tulis nama unik yang sesuai dengan server Call Bridge jembatan panggilan[01,02,03]. оле Domain conf.example.ru dan kata sandi yang sesuai, Anda dapat memata-matainya
di server mana pun di cluster dengan perintah:

xmpp callbridge list

Biarkan bidang "Server" kosong jembatan panggilan akan melakukan pencarian DNS SRV _xmpp-component._tcp.conf.example.comuntuk menemukan server XMPP yang tersedia. Alamat IP untuk menghubungkan callbridge ke XMPP mungkin berbeda di setiap server, tergantung pada nilai apa yang dikembalikan ke permintaan rekaman _xmpp-component._tcp.conf.example.com callbridge, yang pada gilirannya bergantung pada pengaturan prioritas untuk data DNS tertentu.

Selanjutnya, masuk ke Status > General untuk memverifikasi apakah layanan Call Bride berhasil terhubung ke layanan XMPP.

Jembatan Web

Di setiap server di cluster, aktifkan layanan Web Bridge dengan perintah:

webbridge listen a:443

Kami mengkonfigurasi layanan Web Bridge dengan file sertifikat dengan perintah seperti:

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

Jembatan Web mendukung HTTPS. Ini akan mengarahkan HTTP ke HTTPS jika dikonfigurasi untuk menggunakan "http-redirect".
Untuk mengaktifkan pengalihan HTTP, gunakan perintah berikut:

webbridge http-redirect enable

Untuk memberi tahu Call Bridge bahwa Web Bridge dapat mempercayai koneksi dari Call Bridge, gunakan perintah:

webbridge trust <certfile>

dimana ini adalah file yang berisi ketiga sertifikat dari masing-masing server di cluster.

Gambar ini harus ada di setiap server di cluster.

Sekarang kita perlu membuat pengguna dengan peran "appadmin", kita membutuhkannya agar kita dapat mengkonfigurasi cluster kita (!), dan tidak setiap server di cluster secara terpisah, dengan cara ini pengaturan akan diterapkan secara merata ke setiap server meskipun ada fakta bahwa itu akan dibuat sekali.

Untuk pengaturan lebih lanjut kami akan menggunakan Tukang pos.

Untuk otorisasi, pilih Dasar di bagian Otorisasi

Untuk mengirim perintah dengan benar ke server CMS, Anda perlu mengatur pengkodean yang diperlukan

Kami menentukan Webbridge dengan perintah POST dengan parameter url dan artinya cms.example.com

Di webbridge itu sendiri, kami menunjukkan parameter yang diperlukan: akses tamu, akses terlindungi, dll.

Grup Jembatan Panggilan

Secara default, CMS tidak selalu memanfaatkan sumber daya konferensi yang tersedia secara efisien.

Misalnya, untuk pertemuan dengan tiga peserta, masing-masing peserta mungkin berakhir di tiga Call Bridge yang berbeda. Agar ketiga peserta ini dapat berkomunikasi satu sama lain, Call Bridges akan secara otomatis membuat koneksi antara semua server dan klien di Space yang sama, sehingga semuanya tampak seolah-olah semua klien berada di server yang sama. Sayangnya, kelemahannya adalah satu konferensi yang terdiri dari 3 orang kini akan menggunakan 9 port media. Hal ini jelas merupakan penggunaan sumber daya yang tidak efisien. Selain itu, ketika Call Bridge benar-benar kelebihan beban, mekanisme defaultnya adalah terus menerima panggilan dan memberikan layanan berkualitas rendah kepada semua pelanggan Call Bridge tersebut.

Masalah-masalah ini diselesaikan dengan menggunakan fitur Call Bridge Group. Fitur ini diperkenalkan pada perangkat lunak Cisco Meeting Server versi 2.1 dan telah diperluas untuk mendukung penyeimbangan beban untuk panggilan Cisco Meeting App (CMA) masuk dan keluar, termasuk peserta WebRTC.

Untuk mengatasi masalah koneksi ulang, tiga batas beban yang dapat dikonfigurasi telah diperkenalkan untuk setiap Call Bridge:

Batas Beban — ini adalah beban numerik maksimum untuk Call Bridge tertentu. Setiap platform memiliki batas beban yang disarankan, seperti 96000 untuk CMS1000 dan 1.25 GHz per vCPU untuk mesin virtual. Panggilan yang berbeda akan menghabiskan sejumlah sumber daya tertentu, bergantung pada resolusi dan kecepatan bingkai peserta.
ConferenceLoadLimitBasisPoints Baru (default 50% loadLimit) - menetapkan batas beban server, setelah itu konferensi baru ditolak.
ConferenceLoadLimitBasisPoints yang ada (default 80% dari loadLimit) - nilai beban server setelah peserta bergabung dengan konferensi yang ada akan ditolak.

Meskipun fitur ini dirancang untuk distribusi panggilan dan penyeimbangan beban, grup lain seperti TURN Server, Server Web Bridge, dan Perekam juga dapat ditetapkan ke Grup Call Bridge sehingga mereka juga dapat dikelompokkan dengan benar untuk penggunaan optimal. Jika salah satu objek ini tidak ditetapkan ke grup panggilan, objek tersebut diasumsikan tersedia untuk semua server tanpa prioritas tertentu.

Parameter ini dikonfigurasi di sini: cms.example.com:445/api/v1/system/configuration/cluster

Selanjutnya, kami menunjukkan kepada setiap callbridge grup callbridge mana yang dimilikinya:

Jembatan panggilan pertama

Jembatan panggilan kedua

Jembatan panggilan ketiga

Oleh karena itu, kami mengonfigurasi grup Call Brdige agar lebih efisien menggunakan sumber daya cluster Cisco Meeting Server.

Mengimpor pengguna dari Direktori Aktif

Layanan Admin Web memiliki bagian konfigurasi LDAP, tetapi tidak menyediakan opsi konfigurasi yang rumit, dan informasinya tidak disimpan dalam database cluster, sehingga konfigurasi harus dilakukan, baik secara manual di setiap server melalui antarmuka Web, atau melalui API, dan agar kita “tiga kali “Jangan bangun” kita tetap akan mengatur data melalui API.

Menggunakan URL untuk mengakses cms01.example.com:445/api/v1/ldapServers membuat objek Server LDAP, menentukan parameter seperti:

IP server
nomor port
Nama pengguna
kata sandi
aman

Aman - pilih benar atau salah tergantung pada portnya, 389 - tidak aman, 636 - dilindungi.

Memetakan parameter sumber LDAP ke atribut di Cisco Meeting Server.
Pemetaan LDAP memetakan atribut di direktori LDAP ke atribut di CMS. Atribut sebenarnya:

jidMapping
Pemetaan nama
coSpaceNameMapping
coSpaceUriMapping
coSpaceSecondaryUriMapping

Deskripsi atributJID mewakili ID login pengguna di CMS. Karena ini adalah server LDAP Direktori Aktif Microsoft, JID CMS dipetakan ke sAMAccountName di LDAP, yang pada dasarnya adalah ID masuk Direktori Aktif pengguna. Perhatikan juga bahwa Anda menggunakan sAMAccountName dan menambahkan domain conf.pod6.cms.lab di akhir karena ini adalah login yang akan digunakan pengguna Anda untuk login ke CMS.

Pemetaan nama mencocokkan apa yang terdapat dalam bidang displayName Direktori Aktif dengan bidang nama CMS pengguna.

coSpaceNameMapping membuat nama ruang CMS berdasarkan bidang displayName. Atribut ini, bersama dengan atribut coSpaceUriMapping, diperlukan untuk membuat ruang bagi setiap pengguna.

coSpaceUriMapping mendefinisikan bagian pengguna dari URI yang terkait dengan ruang pribadi pengguna. Beberapa domain dapat dikonfigurasi untuk dihubungi ke luar angkasa. Jika bagian pengguna cocok dengan bidang ini untuk salah satu domain ini, panggilan akan diarahkan ke ruang pengguna tersebut.

coSpaceSecondaryUriMapping mendefinisikan URI kedua untuk mencapai ruang angkasa. Ini dapat digunakan untuk menambahkan alias numerik untuk merutekan panggilan ke ruang pengguna yang diimpor sebagai alternatif URI alfanumerik yang ditentukan dalam parameter coSpaceUriMapping.

Server LDAP dan pemetaan LDAP dikonfigurasi. Sekarang Anda perlu menghubungkan keduanya dengan membuat sumber LDAP.

Menggunakan URL untuk mengakses cms01.example.com:445/api/v1/ldapSource membuat objek Sumber LDAP, menentukan parameter seperti:

Server
pemetaan
dasarDn
menyaring

Setelah konfigurasi LDAP selesai, Anda dapat melakukan operasi sinkronisasi manual.

Kami melakukan ini di antarmuka Web setiap server dengan mengklik Sync sekarang bagian Active Directory

atau melalui API dengan perintah POST menggunakan URL untuk mengakses cms01.example.com:445/api/v1/ldapSyncs

Konferensi Ad-Hoc

Apa ini?Dalam konsep tradisional, konferensi adalah ketika dua peserta berbicara satu sama lain, dan salah satu peserta (menggunakan perangkat yang terdaftar dengan Unified CM) menekan tombol "Konferensi", memanggil orang lain, dan setelah berbicara dengan pihak ketiga tersebut , tekan kembali tombol "Konferensi" untuk bergabung dengan semua peserta konferensi tripartit.

Yang membedakan konferensi Ad-Hoc dengan konferensi terjadwal di CMS adalah konferensi Ad-Hoc bukan sekadar panggilan SIP ke CMS. Ketika pemrakarsa konferensi mengklik tombol Konferensi untuk kedua kalinya untuk mengundang semua orang ke pertemuan yang sama, CM Terpadu harus membuat panggilan API ke CMS untuk membuat konferensi on-the-fly yang kemudian semua panggilan ditransfer. Semua ini terjadi tanpa disadari oleh para peserta.

Artinya, CM Terpadu harus mengonfigurasi kredensial API dan alamat/port WebAdmin layanan serta Batang SIP langsung ke server CMS untuk melanjutkan panggilan.

Jika diperlukan, CUCM dapat secara dinamis membuat spasi di CMS sehingga setiap panggilan dapat menjangkau CMS dan cocok dengan aturan panggilan masuk yang ditujukan untuk spasi.

Integrasi dengan CUCM dikonfigurasi dengan cara yang sama seperti yang dijelaskan dalam artikel sebelumnya kecuali pada Cisco UCM Anda perlu membuat tiga trunk untuk CMS, tiga Conference Bridge, di SIP Security Profile tentukan tiga Nama Subjek, Grup Rute, Daftar Rute, Grup Sumber Daya Media, dan Daftar Grup Sumber Daya Media, dan tambahkan beberapa aturan perutean ke Server Pertemuan Cisco.

Profil Keamanan SIP:

Celana pendek:

Setiap batang terlihat sama:

Jembatan Konferensi

Setiap Conference Bridge terlihat sama:

Grup Rute

Daftar Rute

Grup Sumber Daya Media

Daftar Grup Sumber Daya Media

Aturan Panggilan

Tidak seperti sistem manajemen panggilan yang lebih canggih seperti Unified CM atau Expressway, CMS hanya mencari domain di bidang SIP Request-URI untuk panggilan baru. Jadi jika SIP INVITE untuk sip: [email dilindungi]CMS hanya peduli dengan domain.com. CMS mengikuti aturan berikut untuk menentukan ke mana mengarahkan panggilan:

1. CMS pertama-tama mencoba mencocokkan domain SIP dengan domain yang dikonfigurasi dalam aturan panggilan masuk. Panggilan ini kemudian dapat dialihkan ke ruang (“yang ditargetkan”) atau pengguna tertentu, IVR internal, atau tujuan Microsoft Lync/Skype for Business (S4B) yang terintegrasi langsung.
2. Jika tidak ada kecocokan dalam aturan panggilan masuk, CMS akan mencoba mencocokkan domain yang dikonfigurasi dalam tabel penerusan panggilan. Jika kecocokan terjadi, aturan dapat secara eksplisit menolak panggilan tersebut atau meneruskan panggilan tersebut. Saat ini, CMS mungkin menulis ulang domain, yang terkadang berguna untuk memanggil domain Lync. Anda juga dapat memilih untuk meneruskan lemparan, yang berarti tidak ada bidang yang akan diubah lebih lanjut, atau menggunakan rencana panggilan CMS internal. Jika tidak ada kecocokan dalam aturan penerusan panggilan, defaultnya adalah menolak panggilan tersebut. Perlu diingat bahwa di CMS, meskipun panggilan “diteruskan”, media tetap terikat pada CMS, artinya akan berada di jalur persinyalan dan lalu lintas media.
Maka hanya panggilan yang diteruskan saja yang tunduk pada aturan panggilan keluar. Pengaturan ini menentukan tujuan pengiriman panggilan, jenis trunk (apakah itu panggilan Lync baru atau panggilan SIP standar), dan konversi apa pun yang dapat dilakukan jika transfer tidak dipilih dalam aturan penerusan panggilan.

Berikut adalah log sebenarnya dari apa yang terjadi selama konferensi Ad-Hoc

Tangkapan layar menunjukkannya dengan buruk (saya tidak tahu cara memperbaikinya), jadi saya akan menulis log seperti ini:

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

Konferensi Ad-Hoc itu sendiri:

Aturan Panggilan Masuk
Konfigurasi parameter panggilan masuk diperlukan untuk dapat menerima panggilan di CMS. Seperti yang Anda lihat di penyiapan LDAP, semua pengguna diimpor dengan domain conf.pod6.cms.lab. Jadi minimal, Anda ingin panggilan ke domain ini menargetkan ruang. Anda juga perlu menyiapkan aturan untuk segala sesuatu yang ditujukan untuk nama domain yang sepenuhnya memenuhi syarat (dan mungkin bahkan alamat IP) dari masing-masing server CMS. Kontrol panggilan eksternal kami, Unified CM, akan mengonfigurasi trunk SIP yang didedikasikan untuk masing-masing server CMS satu per satu. Bergantung pada apakah tujuan dari trunk SIP ini adalah alamat IP atau FQDN server akan menentukan apakah CMS perlu dikonfigurasi untuk menerima panggilan yang diarahkan ke alamat IP atau FQDN-nya.

Domain yang memiliki aturan masuk prioritas tertinggi digunakan sebagai domain untuk ruang pengguna mana pun. Saat pengguna melakukan sinkronisasi melalui LDAP, CMS secara otomatis membuat spasi, namun hanya bagian pengguna dari URI (coSpaceUriMapping), misalnya, user.space. Bagian domain URI lengkap dihasilkan berdasarkan aturan ini. Faktanya, jika Anda masuk ke Web Bridge saat ini, Anda akan melihat bahwa Space URI tidak memiliki domain. Dengan menetapkan aturan ini sebagai prioritas tertinggi, Anda menyetel domain untuk ruang yang dihasilkan kon.contoh.com.

Aturan Panggilan Keluar

Untuk mengizinkan pengguna melakukan panggilan keluar ke klaster CM Terpadu, Anda harus mengonfigurasi aturan keluar. Domain titik akhir yang terdaftar dengan CM Terpadu, seperti Jabber, adalah example.com. Panggilan ke domain ini harus dirutekan sebagai panggilan SIP standar ke node pemrosesan panggilan CM Terpadu. Server utama adalah cucm-01.example.com, dan server tambahannya adalah cucm-02.example.com.

Aturan pertama menjelaskan perutean panggilan paling sederhana antar server cluster.

Lapangan Lokal dari domain bertanggung jawab atas apa yang akan ditampilkan di SIP-URI penelepon untuk orang yang dipanggil setelah simbol “@”. Jika kita biarkan kosong, maka setelah simbol “@” akan ada alamat IP CUCM yang dilalui panggilan ini. Jika kita menentukan domain, maka setelah simbol “@” sebenarnya akan ada domain. Hal ini diperlukan agar dapat melakukan panggilan kembali, jika tidak, panggilan kembali melalui SIP-URI nama@alamat ip tidak dapat dilakukan.

Hubungi bila ada indikasi Lokal dari domain

Telepon kapan TIDAK ditunjukkan Lokal dari domain

Pastikan untuk secara eksplisit menentukan Terenkripsi atau Tidak Terenkripsi untuk panggilan keluar, karena tidak ada yang berfungsi dengan parameter Otomatis.

Rekaman

Konferensi video direkam oleh server Rekam. Recorder sama persis dengan Cisco Meeting Server. Perekam tidak memerlukan instalasi lisensi apa pun. Lisensi perekaman diperlukan untuk server yang menjalankan layanan CallBridge, mis. lisensi Perekaman diperlukan dan harus diterapkan pada komponen CallBridge, dan bukan pada server yang menjalankan Recorder. Perekam berperilaku sebagai klien Extensible Messaging and Presence Protocol (XMPP), sehingga server XMPP harus diaktifkan di server hosting CallBridge.

Karena Kami memiliki sebuah cluster dan lisensinya perlu “direntangkan” ke ketiga server dalam cluster tersebut. Kemudian cukup di akun pribadi Anda di lisensi kami mengaitkan (menambahkan) alamat MAC dari antarmuka-a semua server CMS yang termasuk dalam cluster.

Dan inilah gambaran yang seharusnya ada di setiap server di cluster

Secara umum, ada beberapa skenario untuk menempatkan Perekam, namun kami akan tetap berpegang pada ini:

Sebelum menyiapkan Perekam, Anda perlu menyiapkan tempat di mana konferensi video akan direkam. Sebenarnya di sini link, cara mengatur semua Rekaman. Saya fokus pada poin dan detail penting:

1. Lebih baik menyelipkan sertifikat dari server pertama di cluster.
2. Kesalahan “Perekam tidak tersedia” mungkin terjadi karena sertifikat yang salah ditentukan dalam Recorder Trust.
3. Penulisan mungkin tidak berfungsi jika direktori NFS yang ditentukan untuk perekaman bukan direktori root.

Terkadang ada kebutuhan untuk merekam konferensi satu pengguna atau ruang tertentu secara otomatis.

Untuk ini, dua CallProfiles dibuat:
Dengan perekaman dinonaktifkan

Dan dengan fungsi perekaman otomatis

Selanjutnya, kita “melampirkan” CallProfile dengan fungsi perekaman otomatis ke ruang yang diinginkan.

Dalam CMS ditetapkan bahwa jika CallProfile secara eksplisit terikat pada ruang atau spasi apa pun, maka CallProfile ini hanya berfungsi dalam kaitannya dengan ruang spesifik ini. Dan jika CallProfile tidak terikat ke ruang apa pun, maka secara default ini diterapkan ke ruang yang tidak ada CallProfile yang terikat secara eksplisit.

Lain kali saya akan mencoba menjelaskan bagaimana CMS diakses di luar jaringan internal organisasi.

Sumber:

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

Sumber: www.habr.com

Server Pertemuan Cisco 2.5.2. Cluster dalam mode Scalable dan Resilient dengan fungsi perekaman konferensi video