Bagikan melalui

Keandalan di Azure Communications Gateway

  • Artikel

Azure Communications Gateway memastikan layanan Anda dapat diandalkan dengan menggunakan mekanisme redundansi Azure dan perilaku coba lagi khusus SIP. Jaringan Anda harus memenuhi persyaratan khusus untuk memastikan ketersediaan layanan.

Model redundansi Azure Communications Gateway

Penyebaran Azure Communications Gateway produksi (juga disebut penyebaran standar) terdiri dari tiga wilayah terpisah: wilayah manajemen dan dua wilayah layanan. Penyebaran lab terdiri dari satu wilayah manajemen dan satu wilayah layanan.

Artikel ini menjelaskan dua jenis wilayah yang berbeda dan model redundansi yang berbeda. Ini mencakup keandalan regional dengan zona ketersediaan dan keandalan lintas wilayah dengan pemulihan bencana. Untuk gambaran umum keandalan yang lebih rinci di Azure, lihat Keandalan Azure.

Diagram dua wilayah layanan, wilayah manajemen dan dua situs operator.

Wilayah layanan

Wilayah layanan berisi infrastruktur suara dan API yang digunakan untuk menangani lalu lintas antara jaringan Anda dan layanan komunikasi yang Anda pilih.

Penyebaran Azure Communications Gateway produksi memiliki dua wilayah layanan yang disebarkan dalam mode aktif-aktif (sebagaimana diperlukan oleh program Koneksi Operator dan Teams Telepon Mobile). Failover cepat antara wilayah layanan disediakan pada tingkat infrastruktur/IP dan pada tingkat aplikasi (SIP/RTP/HTTP).

Wilayah layanan juga berisi infrastruktur untuk API Provisi Azure Communications Gateway.

Tip

Penyebaran produksi harus selalu memiliki dua wilayah layanan, bahkan jika salah satu wilayah layanan yang dipilih berada di Azure Geography satu wilayah (misalnya, Qatar). Jika Anda memilih Azure Geography satu wilayah, pilih wilayah Azure kedua di Azure Geography yang berbeda.

Wilayah layanan identik dalam operasi dan memberikan ketahanan terhadap kegagalan Zona dan Regional. Setiap wilayah layanan dapat membawa 100% lalu lintas menggunakan instans Azure Communications Gateway. Dengan demikian, pengguna akhir harus tetap dapat melakukan dan menerima panggilan dengan sukses selama waktu henti Zona atau Regional apa pun.

Penyebaran lab memiliki satu wilayah layanan.

Persyaratan perutean panggilan

Azure Communications Gateway menawarkan model redundansi 'redial' yang berhasil: panggilan yang ditangani oleh rekan-rekan yang gagal dihentikan, tetapi panggilan baru dirutekan ke rekan-rekan yang sehat. Model ini mencerminkan model redundansi yang disediakan oleh Microsoft Teams.

Untuk penyebaran produksi, kami berharap jaringan Anda memiliki dua situs yang berlebihan secara geografis. Setiap situs harus dipasangkan dengan wilayah Azure Communications Gateway. Model redundansi bergantung pada konektivitas silang antara jaringan Anda dan wilayah layanan Azure Communications Gateway.

Diagram dua situs operator dan dua wilayah layanan. Kedua wilayah layanan terhubung ke kedua situs, dengan rute utama dan sekunder.

Penyebaran lab harus tersambung ke satu situs di jaringan Anda.

Setiap wilayah layanan Azure Communications Gateway menyediakan catatan SRV. Catatan ini berisi semua serekan SIP yang menyediakan fungsionalitas SBC (untuk panggilan perutean ke layanan komunikasi) di wilayah tersebut. Catatan SRV ini dapat menunjuk ke alamat IP apa pun dalam rentang IP /28 yang disediakan untuk Anda oleh tim orientasi Anda.

Jika Azure Communications Gateway Anda menyertakan Mobile Control Point (MCP), setiap wilayah layanan menyediakan catatan SRV tambahan untuk MCP. Setiap catatan MCP per wilayah berisi MCP dalam wilayah pada prioritas teratas dan MCP di wilayah lain dengan prioritas yang lebih rendah.

Setiap situs di jaringan Anda harus:

  • Kirim lalu lintas ke wilayah layanan Azure Communications Gateway lokalnya secara default.
  • Temukan rekan Azure Communications Gateway dalam wilayah menggunakan DNS SRV, seperti yang diuraikan dalam RFC 3263.
    • Buat pencarian DNS SRV pada nama domain untuk koneksi wilayah layanan ke jaringan Anda, menggunakan _sip._tls.<regional-FQDN-from-portal>. Ganti <regional-FQDN-from-portal> dengan FQDN per wilayah dari bidang Nama Host di halaman Gambaran Umum untuk sumber daya Anda di portal Azure. Misalnya, jika penyebaran Anda menggunakan commsgw.azure.com nama domain, cari _sip._tls.pstn-region1.<deployment-id>.commsgw.azure.com wilayah pertama.
    • Jika pencarian SRV mengembalikan beberapa target, gunakan bobot dan prioritas setiap target untuk memilih satu target.
  • Kirim panggilan baru ke rekan Azure Communications Gateway yang tersedia.
  • Dapat menerima lalu lintas dari alamat IP apa pun di setiap rentang IP yang terkait dengan Azure Communications Gateway Anda.

Saat jaringan Anda merutekan panggilan ke rekan SIP Azure Communications Gateway untuk fungsi SBC, jaringan harus:

  • Gunakan OPSI SIP (atau kombinasi lalu lintas OPTIONS dan SIP) untuk memantau ketersediaan rekan SIP Azure Communications Gateway.
  • Coba lagi INVITEs yang menerima 408 respons, 503 respons atau 504 respons atau tidak menerima respons, dengan mengalihkannya ke rekan lain yang tersedia di situs lokal. Berburu ke wilayah layanan lain (ditentukan oleh catatan SRV wilayah lain) hanya jika semua rekan di wilayah layanan lokal telah gagal.
  • Jangan pernah mencoba kembali panggilan yang menerima respons kesalahan selain 408, 503, dan 504.

Jika penyebaran Azure Communications Gateway Anda menyertakan Mobile Control Point (MCP) terintegrasi, jaringan Anda harus melakukan sebagai berikut untuk MCP:

  • Deteksi kapan MCP di suatu wilayah tidak tersedia, tandai target untuk catatan SRV wilayah tersebut sebagai tidak tersedia, dan coba lagi secara berkala untuk menentukan kapan wilayah tersedia lagi. MCP tidak menanggapi OPSI SIP.
  • Tangani respons 5xx dari MCP sesuai dengan kebijakan organisasi Anda. Misalnya, Anda dapat mencoba kembali permintaan, atau Anda dapat mengizinkan panggilan untuk melanjutkan tanpa melewati Azure Communications Gateway dan ke Microsoft Telepon System.

Detail perilaku perutean ini khusus untuk jaringan Anda. Anda harus menyetujuinya dengan tim orientasi Anda selama proyek integrasi Anda.

Wilayah manajemen

Wilayah manajemen berisi infrastruktur yang digunakan untuk pemesanan, pemantauan, dan penagihan Azure Communications Gateway. Semua infrastruktur dalam wilayah ini disebarkan secara zona berlebihan, yang berarti bahwa semua data secara otomatis direplikasi di setiap Zona Ketersediaan dalam wilayah tersebut. Semua data konfigurasi penting juga direplikasi ke setiap Wilayah Layanan untuk memastikan berfungsinya layanan selama kegagalan wilayah Azure.

Dukungan zona ketersediaan

Zona ketersediaan Azure adalah setidaknya tiga grup pusat data yang terpisah secara fisik dalam setiap wilayah Azure. Pusat data dalam setiap zona dilengkapi dengan infrastruktur daya, pendinginan, dan jaringan independen. Dalam kasus kegagalan zona lokal, zona ketersediaan dirancang sehingga jika satu zona terpengaruh, layanan regional, kapasitas, dan ketersediaan tinggi didukung oleh dua zona yang tersisa.

Kegagalan dapat berkisar dari kegagalan perangkat lunak dan perangkat keras hingga peristiwa seperti gempa bumi, banjir, dan kebakaran. Toleransi terhadap kegagalan dicapai dengan redundansi dan isolasi logis layanan Azure. Untuk informasi selengkapnya tentang zona ketersediaan di Azure, lihat Wilayah dan zona ketersediaan.

Layanan berkemampuan zona ketersediaan Azure dirancang untuk memberikan tingkat keandalan dan fleksibilitas yang tepat. Mereka dapat dikonfigurasi dalam dua cara. Mereka dapat berupa zona redundan,dengan replikasi otomatis di seluruh zona, atau zonal, dengan instans yang disematkan ke zona tertentu. Anda juga dapat menggabungkan pendekatan ini. Untuk informasi selengkapnya tentang arsitektur zonal vs. zona-redundan, lihat Rekomendasi untuk menggunakan zona dan wilayah ketersediaan.

Pengalaman zona tidak berfungsi untuk wilayah layanan

Selama pemadaman di seluruh zona, panggilan yang ditangani oleh zona yang terkena dampak dihentikan, dengan hilangnya kapasitas singkat di wilayah tersebut sampai penyeimbangan mandiri layanan menyeimbangkan kembali sumber daya yang mendasar ke zona yang sehat. Penyembuhan diri ini tidak tergantung pada pemulihan zona; diharapkan bahwa status pemulihan mandiri layanan yang dikelola Microsoft mengkompensasi zona yang hilang, menggunakan kapasitas dari zona lain. Lalu lintas yang membawa sumber daya disebarkan dengan cara zona-redundan tetapi pada lalu lintas skala terendah mungkin ditangani oleh satu sumber daya. Dalam hal ini, mekanisme failover yang dijelaskan dalam artikel ini menyeimbangkan kembali semua lalu lintas ke wilayah layanan lain sementara sumber daya yang membawa lalu lintas disebarkan ulang di zona sehat.

Pengalaman zona tidak berfungsi untuk wilayah manajemen

Selama pemadaman di seluruh zona, tidak ada tindakan yang diperlukan selama pemulihan zona. Wilayah manajemen menyembuhkan diri dan menyeimbangkan kembali dirinya sendiri untuk memanfaatkan zona sehat secara otomatis.

Pemulihan bencana: fallback ke wilayah lain

Pemulihan bencana (DR) adalah tentang pemulihan dari peristiwa berdampak tinggi, seperti bencana alam atau penyebaran gagal yang mengakibatkan waktu henti dan kehilangan data. Terlepas dari penyebabnya, obat terbaik untuk bencana adalah rencana DR yang terdefinisi dan teruji dengan baik dan desain aplikasi yang secara aktif mendukung DR. Sebelum Anda mulai berpikir tentang membuat rencana pemulihan bencana Anda, lihat Rekomendasi untuk merancang strategi pemulihan bencana.

Ketika datang ke DR, Microsoft menggunakan model tanggung jawab bersama. Dalam model tanggung jawab bersama, Microsoft memastikan bahwa infrastruktur dasar dan layanan platform tersedia. Pada saat yang sama, banyak layanan Azure tidak secara otomatis mereplikasi data atau mundur dari wilayah yang gagal untuk mereplikasi silang ke wilayah lain yang diaktifkan. Untuk layanan tersebut, Anda bertanggung jawab untuk menyiapkan rencana pemulihan bencana yang berfungsi untuk beban kerja Anda. Sebagian besar layanan yang berjalan pada penawaran platform as a service (PaaS) Azure menyediakan fitur dan panduan untuk mendukung DR dan Anda dapat menggunakan fitur khusus layanan untuk mendukung pemulihan cepat untuk membantu mengembangkan rencana DR Anda.

Bagian ini menjelaskan perilaku Azure Communications Gateway selama pemadaman di seluruh wilayah.

Pemulihan bencana: failover lintas wilayah untuk wilayah layanan

Selama pemadaman di seluruh wilayah, mekanisme failover yang dijelaskan dalam artikel ini (polling OPTIONS dan coba lagi SIP pada kegagalan) akan menyeimbangkan kembali semua lalu lintas panggilan ke wilayah layanan lain, menjaga ketersediaan. Kita akan mulai memulihkan redundansi regional. Memulihkan redundansi regional selama waktu henti yang diperpanjang mungkin memerlukan penggunaan wilayah Azure lainnya. Jika kami perlu memigrasikan wilayah yang gagal ke wilayah lain, kami akan berkonsultasi dengan Anda sebelum memulai migrasi apa pun.

Fungsi SBC di Azure Communications Gateway menyediakan polling OPTIONS untuk memungkinkan jaringan Anda menentukan ketersediaan serekan. Untuk MCP, jaringan Anda harus dapat mendeteksi kapan MCP tidak tersedia, dan mencoba kembali secara berkala untuk menentukan kapan MCP tersedia lagi. MCP tidak menanggapi OPSI SIP.

Klien API provisi menghubungi Azure Communications Gateway menggunakan nama domain dasar untuk penyebaran Anda. Catatan DNS untuk domain ini memiliki time-to-live (TTL) 60 detik. Saat wilayah gagal, Azure memperbarui catatan DNS untuk merujuk ke wilayah lain, sehingga klien yang membuat pencarian DNS baru menerima detail wilayah baru. Sebaiknya pastikan bahwa klien dapat melakukan pencarian DNS baru dan mencoba kembali permintaan 60 detik setelah waktu habis atau respons 5xx.

Tip

Penyebaran lab tidak menawarkan failover lintas wilayah (karena hanya memiliki satu wilayah layanan).

Pemulihan bencana: failover lintas wilayah untuk wilayah manajemen

Lalu lintas suara dan provisi melalui Portal Manajemen Nomor tidak terpengaruh oleh kegagalan di wilayah manajemen, karena sumber daya Azure yang sesuai dihosting di wilayah layanan. Pengguna Portal Manajemen Nomor mungkin perlu masuk lagi.

Layanan pemantauan mungkin sementara tidak tersedia hingga layanan dipulihkan. Jika wilayah manajemen mengalami waktu henti yang diperpanjang, kami akan memigrasikan sumber daya yang terkena dampak ke wilayah lain yang tersedia.

Memilih wilayah manajemen dan layanan

Satu penyebaran Azure Communications Gateway dirancang untuk menangani lalu lintas Anda dalam area geografis. Sebarkan kedua wilayah layanan dalam penyebaran produksi dalam area geografis yang sama (misalnya Amerika Utara). Model ini memastikan bahwa latensi pada panggilan suara tetap dalam batas yang diperlukan oleh program Koneksi Operator dan Teams Telepon Mobile.

Pertimbangkan poin-poin berikut saat Anda memilih lokasi wilayah layanan Anda:

  • Pilih dari daftar wilayah Azure yang tersedia. Anda dapat melihat wilayah Azure yang dapat dipilih sebagai wilayah layanan di halaman Produk menurut wilayah .
  • Pilih wilayah yang dekat dengan tempat Anda sendiri dan lokasi peering antara jaringan Anda dan Microsoft untuk mengurangi latensi panggilan.
  • Lebih suka pasangan regional untuk meminimalkan waktu pemulihan jika pemadaman multi-wilayah terjadi.

Pilih wilayah manajemen dari daftar berikut ini:

  • AS Timur
  • AS Tengah Bagian Barat
  • Eropa Barat
  • UK Selatan
  • India Tengah
  • Kanada Tengah
  • Australia Timur

Wilayah manajemen dapat dikolokasikan dengan wilayah layanan. Sebaiknya pilih wilayah manajemen terdekat dengan wilayah layanan Anda.

Catatan

Jika Anda mengaktifkan Pratinjau Perlindungan Panggilan Operator Azure, wilayah layanan yang Anda pilih mungkin bukan wilayah Azure tempat sumber daya pendukung disebarkan. Lihat Produk Azure menurut Wilayah untuk daftar wilayah layanan Perlindungan Panggilan Operator Azure yang saat ini didukung dan bicarakan dengan tim orientasi Anda jika Anda memiliki pertanyaan tentang wilayah mana yang dipilih.

Perjanjian tingkat layanan

Desain keandalan yang dijelaskan dalam dokumen ini diimplementasikan oleh Microsoft dan tidak dapat dikonfigurasi. Untuk informasi selengkapnya tentang perjanjian tingkat layanan (SLA) Azure Communications Gateway, lihat Azure Communications Gateway SLA.

Langkah berikutnya