Beberapa kata tentang apa yang kami lakukan. DINS terlibat dalam pengembangan dan dukungan layanan UCaaS di pasar internasional untuk klien korporat. Layanan ini digunakan oleh perusahaan kecil dan pemula, dan bisnis besar. Klien terhubung melalui Internet melalui protokol SIP melalui TCP, TLS atau WSS. Ini menciptakan beban yang agak besar: hampir 1,5 juta koneksi dari perangkat akhir - telepon Polycom / Cisco / Yealink dan klien perangkat lunak untuk PC / Mac / IOS / Android.
Pada artikel ini, saya berbicara tentang bagaimana titik masuk VoIP diatur.
Latar belakang
Pada perimeter sistem (antara perangkat terminal dan kernel) adalah SBC komersial (Session Border Controller).
Sejak 2012, kami telah menggunakan solusi dari Acme Packet, yang kemudian diakuisisi oleh Oracle. Sebelum itu, kami menggunakan NatPASS.
Daftarkan secara singkat fungsionalitas yang kami gunakan:
• NAT traversal;
• B2BUA;
• Normalisasi SIP (header diizinkan / tidak diizinkan, aturan manipulasi header, dll)
• Pelepasan TLS & SRTP;
• Konversi transportasi (di dalam sistem kami menggunakan SIP melalui UDP);
• Pemantauan MOS (via RTCP-XR);
• ACL, deteksi Bruteforce;
• Mengurangi lalu lintas pendaftaran karena peningkatan kedaluwarsa kontak (kedaluwarsa rendah di sisi akses, tinggi di sisi inti);
• Per-Metode SIP mencekik pesan.
Sistem komersial memiliki nilai tambah yang jelas (fungsional di luar kotak, dukungan komersial) dan minus (harga, waktu pengiriman, kurangnya kesempatan, atau tenggat waktu yang terlalu lama untuk mengimplementasikan fitur baru yang kami butuhkan, tenggat waktu untuk menyelesaikan masalah, dll.). Perlahan-lahan, kekurangannya mulai melebihi, dan menjadi jelas bahwa kebutuhan sudah matang untuk mengembangkan solusi kami sendiri.
Pengembangan diluncurkan satu setengah tahun yang lalu. Dalam subsistem perbatasan, kami secara tradisional membedakan 2 komponen utama: SIP dan server Media; memuat penyeimbang di atas setiap komponen. Saya sedang mengerjakan titik masuk / penyeimbang di sini, jadi saya akan mencoba untuk membicarakannya.
Persyaratan
- Toleransi kesalahan: sistem harus menyediakan layanan jika terjadi kegagalan satu atau lebih contoh di pusat data atau seluruh pusat data
- Kemudahan Servis: kami ingin dapat memindahkan beban dari satu pusat data ke yang lain
- Skalabilitas: Saya ingin meningkatkan kapasitas dengan cepat dan murah
Menyeimbangkan
Kami memilih IPVS (alias LVS) dalam mode IPIP (traffic tunneling). Saya tidak akan masuk ke analisis komparatif NAT / DR / TUN / L3DSR, (Anda dapat membaca tentang mode, misalnya, di sini ), saya hanya akan menyebutkan alasannya:
- Kami tidak ingin memaksakan persyaratan pada backend berada pada subnet yang sama dengan LVS (pool berisi backend dari pusat data kami sendiri dan jarak jauh);
- Backend harus menerima IP sumber asli dari klien (atau NAT-nya), dengan kata lain, sumber NAT tidak cocok;
- Backend harus mendukung kerja simultan dengan beberapa VIP.
Kami menyeimbangkan lalu lintas media (ternyata sangat sulit, kami akan menolak), sehingga skema penyebaran saat ini di pusat data adalah sebagai berikut:
Strategi penyeimbangan IPVS saat ini adalah "sed" (Keterlambatan Terpendek Diharapkan), lebih dari itu. Tidak seperti Weighted Round Robin / Weighted Least-Connection, ini memungkinkan Anda untuk tidak mentransfer lalu lintas ke backend dengan bobot lebih rendah hingga ambang tertentu tercapai. Delay yang diharapkan terpendek dihitung dengan menggunakan rumus (Ci + 1) / Ui, di mana Ci adalah jumlah koneksi di backend i, Ui adalah bobot backend. Misalnya, jika ada backend di kolam dengan bobot 50.000 dan 2, koneksi baru akan didistribusikan oleh yang pertama sampai setiap server mencapai 25.000 koneksi atau sampai uthreshold tercapai - batas jumlah total koneksi.
Baca lebih lanjut tentang menyeimbangkan strategi di man ipvsadm .
Kumpulan IPVS terlihat seperti ini (di sini dan di bawah, alamat IP fiktif tercantum):
# ipvsadm -ln Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 1.1.1.1:5060 sed -> 10.11.100.181:5060 Tunnel 50000 5903 4 -> 10.11.100.192:5060 Tunnel 50000 5905 1 -> 10.12.100.137:5060 Tunnel 2 0 0 -> 10.12.100.144:5060 Tunnel 2 0 0
Beban pada VIP didistribusikan ke server dengan berat 50.000 (mereka ditempatkan di pusat data yang sama sebagai contoh LVS tertentu), jika mereka kelebihan beban atau masuk ke daftar hitam, beban akan pergi ke bagian cadangan pool - server dengan berat 2, yang terletak di pusat data tetangga.
Tepatnya kumpulan yang sama, tetapi dengan skala, sebaliknya, dikonfigurasikan di pusat data tetangga (pada sistem produksi, jumlah backend, tentu saja, jauh lebih besar).
Sinkronisasi koneksi melalui ipvs sync memungkinkan LVS cadangan mengetahui semua koneksi saat ini.
Untuk sinkronisasi antara pusat data, teknik "kotor" telah diterapkan, yang tetap berfungsi dengan baik. Sinkronisasi IPVS hanya berfungsi melalui multicast, yang sulit bagi kami untuk mengirim dengan benar ke DC yang berdekatan. Alih-alih multicast, kami menduplikasi lalu lintas sinkronisasi melalui TEE target iptables dari master ipvs ke terowongan ip-ip ke server di DC yang berdekatan, dan mungkin ada beberapa host target / pusat data:
#### start ipvs sync master role: ipvsadm --start-daemon master --syncid 10 --sync-maxlen 1460 --mcast-interface sync01 --mcast-group 224.0.0.81 --mcast-port 8848 --mcast-ttl 1 #### duplicate all sync packets to remote LVS servers using iptables TEE target: iptables -t mangle -A POSTROUTING -d 224.0.0.81/32 -o sync01 -j TEE --gateway 172.20.21.10 # ip-ip remote lvs server 1 iptables -t mangle -A POSTROUTING -d 224.0.0.81/32 -o sync01 -j TEE --gateway 172.20.21.14 # ip-ip remote lvs server 2 #### start ipvs sync backup role: ipvsadm --start-daemon backup --syncid 10 --sync-maxlen 1460 --mcast-interface sync01 --mcast-group 224.0.0.81 --mcast-port 8848 --mcast-ttl 1 #### be ready to receive sync sync packets from remote LVS servers: iptables -t mangle -A PREROUTING -d 224.0.0.81/32 -i loc02_srv01 -j TEE --gateway 127.0.0.1 iptables -t mangle -A PREROUTING -d 224.0.0.81/32 -i loc02_srv02 -j TEE --gateway 127.0.0.1
Faktanya, masing-masing server LVS kami memainkan kedua peran sekaligus (master & cadangan), di satu sisi, itu hanya nyaman, karena menghilangkan perubahan peran ketika beralih lalu lintas, di sisi lain itu diperlukan, karena setiap DC memproses lalu lintas grup secara default VIP publik.
Load switching antar pusat data
Dalam operasi normal, setiap alamat IP publik diumumkan di Internet dari mana saja (dalam diagram ini, dari dua pusat data). Lalu lintas yang memasuki VIP dialihkan ke DC yang kita butuhkan saat ini menggunakan atribut BGP MED (Multi Exit Discriminator) dengan nilai yang berbeda untuk DC Aktif dan Cadangan DC. Pada saat yang sama, Backup DC selalu siap menerima lalu lintas jika terjadi sesuatu pada yang aktif:
Dengan mengubah nilai-nilai BGP MED dan menggunakan sinkronisasi lintas lokasi IPVS, kami mendapatkan kesempatan untuk mentransfer lalu lintas dari pusat data ke pusat data dengan mulus, tanpa memengaruhi panggilan telepon yang sudah ada, yang cepat atau lambat akan berakhir secara alami. Prosesnya sepenuhnya otomatis (untuk setiap VIP kami memiliki tombol di konsol manajemen), dan terlihat seperti ini:
SIP-VIP aktif di DC1 (kiri), cluster di DC2 (kanan) berlebihan, berkat sinkronisasi ipvs, ia memiliki informasi tentang koneksi yang ada di memorinya. Di sebelah kiri, VIP aktif diumumkan dengan nilai MED 100, di sebelah kanan - dengan nilai 500:
Tombol switch menyebabkan perubahan pada apa yang disebut "Target_state" (konsep internal yang mendeklarasikan nilai-nilai BGP MED pada waktu tertentu). Di sini kita tidak berharap bahwa DC1 dalam rangka dan siap untuk memproses lalu lintas, karena itu LVS di DC2 memasuki keadaan "aktif", menurunkan nilai MED ke 50, dan dengan demikian menyeret lalu lintas ke dirinya sendiri. Jika backend di DC1 aktif dan tersedia, panggilan tidak akan terputus. Semua koneksi tcp baru (pendaftaran) akan dikirim ke backends di DC2:
DC1 menerima replikasi target_state baru dan mengatur MED nilai cadangan (500). Ketika DC2 mengetahui hal ini, ia menormalkan nilainya (50 => 100). Tetap menunggu selesainya semua panggilan aktif di DC1 dan memutuskan koneksi tcp yang sudah ada. Contoh SBC di DC1 memperkenalkan layanan yang diperlukan ke dalam apa yang disebut Keadaan "shutdown anggun": "503" menanggapi permintaan SIP berikutnya dan memutuskan sambungan, tetapi tidak menerima koneksi baru. Juga, contoh-contoh ini termasuk dalam daftar hitam di LVS. Ketika melanggar, klien membuat pendaftaran / koneksi baru, yang sudah ada di DC2:
Proses berakhir ketika semua lalu lintas di DC2.
DC1 dan DC2 beralih peran.
Dalam kondisi beban tinggi yang konstan pada titik masuk, ternyata sangat nyaman untuk dapat mengubah lalu lintas kapan saja. Mekanisme yang sama dimulai secara otomatis jika cadangan DC tiba-tiba mulai menerima lalu lintas. Pada saat yang sama, untuk melindungi dari mengepakkan, switching dipicu hanya sekali dalam satu arah dan kunci diatur ke switching otomatis, untuk menghapusnya, diperlukan intervensi manusia.
Apa yang ada di dalamnya
VRRP cluster & IPVS manager: Keepalived. Keepalived bertanggung jawab untuk mengganti VIP di dalam cluster, juga untuk pemeriksaan kesehatan backends / daftar hitam.
Stack BGP: ExaBGP. Dia bertanggung jawab untuk pengumuman rute ke alamat VIP dan menempelkan BGP MED yang sesuai. Sepenuhnya dikontrol oleh server manajemen. Daemon BGP andal yang ditulis dengan Python sedang aktif dikembangkan, ia menjalankan tugasnya 100%.
Server manajemen (API / Pemantauan / manajemen sub-komponen): Pyro4 + Flask. Ini adalah server Provisioning untuk Keepalived dan ExaBGP, mengelola semua pengaturan sistem lainnya (sysctl / iptables / ipset / etc), menyediakan pemantauan (gnlpy), menambah dan menghapus backend atas permintaan (mereka berkomunikasi dengan API-nya).
Tokoh
Mesin virtual dengan empat inti Intel Xeon Gold 6140 CPU @ 2.30GHz melayani arus lalu lintas 300Mbps / 210Kpps (lalu lintas media, sekitar 3 ribu panggilan simultan dalam waktu puncak diproses melalui mereka). Pemanfaatan CPU pada saat yang sama - 60%.
Sekarang ini cukup untuk melayani lalu lintas hingga 100 ribu perangkat terminal (telepon desktop). Untuk melayani semua lalu lintas (lebih dari 1 juta perangkat terminal), kami sedang membangun sekitar 10 pasang cluster tersebut di beberapa pusat data.