Keandalan pada zona privat Azure DNS

Azure DNS zona privat menyediakan resolusi nama yang aman dalam jaringan virtual Azure. Anda dapat mencakup zona DNS privat ke satu atau beberapa jaringan virtual, dan organisasi biasanya menggunakannya untuk aplikasi internal. Nama host yang Anda atasi adalah nama DNS lokal yang tidak dapat diakses secara publik melalui internet. Alamat IP yang diselesaikan sering kali merupakan alamat IP privat yang tidak dapat diakses dari internet. Azure DNS adalah layanan global yang tidak terikat ke zona ketersediaan atau wilayah tunggal tertentu.

Saat Anda menggunakan Azure, keandalan adalah tanggung jawab bersama. Microsoft menyediakan berbagai kemampuan untuk mendukung ketahanan dan pemulihan. Anda bertanggung jawab untuk memahami cara kerja kemampuan tersebut dalam semua layanan yang Anda gunakan, dan memilih kemampuan yang Anda butuhkan untuk memenuhi tujuan bisnis dan tujuan waktu aktif Anda.

Artikel ini menjelaskan cara membuat zona privat Azure DNS tahan terhadap berbagai potensi pemadaman dan masalah, termasuk kesalahan sementara dan kegagalan di seluruh wilayah. Ini juga menyediakan informasi utama tentang perjanjian tingkat layanan (SLA) zona privat Azure DNS.

Rekomendasi implementasi produksi untuk keandalan

Untuk beban kerja produksi, kami sarankan Anda mengikuti rekomendasi ini:

  • Konfigurasikan nilai TTL yang sesuai: Atur nilai time-to-live (TTL) yang menyeimbangkan performa dengan waktu pemulihan. Nilai TTL yang lebih rendah memungkinkan failover yang lebih cepat tetapi meningkatkan volume kueri. Pertimbangkan 300 detik (5 menit) sebagai titik awal untuk beban kerja produksi.

  • Membagi zona DNS yang besar: Jika Anda memiliki zona DNS yang besar, pertimbangkan membagi zona Anda menjadi beberapa shard untuk meningkatkan keandalan dan efisiensi operasional secara keseluruhan.

Gambaran umum arsitektur keandalan

Bagian ini menjelaskan beberapa aspek penting tentang cara kerja layanan yang paling relevan dari perspektif keandalan. Bagian ini memperkenalkan arsitektur logis, yang mencakup beberapa sumber daya dan fitur yang Anda sebarkan dan gunakan. Ini juga membahas arsitektur fisik, yang memberikan detail tentang cara kerja layanan di bawah sampul.

Arsitektur logika

Sumber daya utama yang Anda sebarkan adalah zona, yang mewakili sekumpulan catatan DNS yang memetakan nama host (nama domain) ke alamat IP. Nama host yang diselesaikan zona biasanya adalah nama DNS lokal yang tidak dapat diakses secara publik melalui internet.

Anda membuat zona DNS privat sebagai sumber daya mandiri dan menautkannya ke jaringan virtual tertentu dengan membuat tautan jaringan virtual. Ketika permintaan DNS berasal dari klien dalam jaringan virtual tersebut, zona DNS privat berpartisipasi dalam proses resolusi. Anda dapat membuat entri secara manual di zona DNS atau mengonfigurasi registrasi otomatis VM pada tautan jaringan virtual. Azure DNS zona privat mendukung resolusi DNS antara jaringan virtual di seluruh wilayah Azure, bahkan tanpa secara eksplisit melakukan peering pada jaringan virtual. Namun, semua jaringan virtual harus ditautkan ke zona DNS privat.

Proses resolusi nama DNS melibatkan beberapa komponen, termasuk pemecah masalah DNS dan lapisan perantara yang memproses permintaan sebelum mencapai server DNS otoritatif. Zona privat menggunakan protokol dan perilaku DNS yang sama dengan zona publik, termasuk nilai TTL dan mekanisme penembolokan.

Penting

Keandalan solusi Anda secara keseluruhan tergantung pada konfigurasi sumber daya yang dirujuk catatan DNS Anda, seperti komputer virtual dan penyeimbang beban.

Artikel ini tidak mencakup sumber daya tersebut, tetapi konfigurasi ketersediaannya secara langsung memengaruhi ketahanan aplikasi Anda. Tinjau panduan keandalan untuk layanan Azure dalam solusi Anda untuk mempelajari bagaimana setiap layanan mendukung persyaratan keandalan Anda.

Arsitektur fisik

Azure DNS adalah layanan nonregional. Microsoft menyebarkan infrastrukturnya di beberapa zona ketersediaan di beberapa wilayah Azure di seluruh dunia. Desain ini memungkinkan Azure DNS untuk tetap tangguh selama pemadaman zona ketersediaan atau wilayah karena infrastruktur di zona atau wilayah lain terus merespons permintaan resolusi.

Protokol internet global seperti Anycast, DNS, dan Border Gateway Protocol (BGP) secara otomatis merutekan permintaan resolusi DNS masuk ke infrastruktur Azure DNS sehat terdekat.

Ketahanan terhadap kesalahan sementara

Kesalahan sementara adalah kegagalan yang bersifat sementara dan intermiten dalam komponen. Mereka sering terjadi di lingkungan terdistribusi seperti cloud, dan mereka adalah bagian normal dari operasi. Kesalahan sementara memperbaiki diri setelah waktu yang singkat. Penting bahwa aplikasi Anda dapat menangani kesalahan sementara, biasanya dengan mencoba kembali permintaan yang terpengaruh.

Semua aplikasi yang dihosting cloud harus mengikuti panduan penanganan kesalahan sementara Azure saat berkomunikasi dengan API, database, dan komponen lain yang dihosting cloud. Untuk informasi selengkapnya, lihat Rekomendasi untuk menangani kesalahan sementara.

Azure DNS menangani kesalahan sementara melalui infrastruktur DNS globalnya.

Jika kesalahan sementara terjadi selama resolusi DNS, klien atau pemecah masalah perantara harus mencoba kembali permintaan. Konfigurasikan nilai batas waktu dengan tepat. Batas waktu 2 hingga 5 detik biasanya cukup untuk klien DNS.

Setiap catatan DNS time to live (TTL) juga memengaruhi bagaimana solusi Anda menangani kesalahan. Jika TTL sangat rendah, klien membuat lebih banyak permintaan untuk Azure DNS, yang menciptakan lebih banyak peluang untuk kesalahan sementara. Jika TTL sangat tinggi, apabila terjadi gangguan nyata pada server backend yang mengharuskan Anda mengalihkan lalu lintas ke alamat IP lain, klien mungkin mengalami keterlambatan failover hingga TTL kedaluwarsa. Konfigurasikan TTL dengan hati-hati untuk menyeimbangkan ketersediaan, latensi, dan responsivitas.

Ketahanan terhadap kegagalan zona ketersediaan

Zona ketersediaan adalah grup pusat data yang terpisah secara fisik dalam wilayah Azure. Ketika satu zona gagal, layanan dapat melakukan failover ke salah satu zona yang tersisa.

Azure DNS beroperasi sebagai layanan nonregional. Microsoft mendistribusikan infrastrukturnya di beberapa zona ketersediaan di beberapa wilayah Azure dan mereplikasi perubahan pada zona DNS privat Anda di seluruh infrastruktur tersebut. Anda tidak memilih zona ketersediaan atau mengonfigurasi redundansi zona. Selama pemadaman zona ketersediaan, infrastruktur di zona atau wilayah lain terus merespons permintaan resolusi.

Jika sumber daya yang Anda sebarkan ke satu zona ketersediaan, seperti komputer virtual (VM), menjadi tidak tersedia selama kegagalan zona, Azure DNS terus mengembalikan alamat IP yang dikonfigurasi sumber daya karena tidak memantau kesehatan titik akhir. Jika Anda melakukan failover ke sumber daya di zona sehat, Anda bertanggung jawab untuk memperbarui catatan DNS sehingga klien menggunakan sumber daya yang sehat. Atau, tempatkan sumber daya di belakang load balancer redundan zona yang mengarahkan lalu lintas ke VM di zona yang sehat.

Ketahanan terhadap kegagalan di seluruh wilayah

Azure DNS zona privat tahan terhadap pemadaman wilayah karena data zona tersedia secara global. Jika suatu wilayah mengalami pemadaman, jaringan virtual dan sumber dayanya seperti VM mungkin tidak tersedia, tetapi resolusi nama terus berfungsi.

Contoh berikut menunjukkan bagaimana data zona privat tetap tersedia di beberapa wilayah. Zona azure.contoso.com privat ditautkan ke jaringan virtual di tiga wilayah: wilayah A, wilayah B, dan wilayah C. Registrasi otomatis diaktifkan di wilayah A dan B. Diagram menunjukkan wilayah A mengalami pemadaman:

Diagram yang memperlihatkan zona DNS privat yang ditautkan ke jaringan virtual di tiga wilayah sementara wilayah A tidak tersedia.

Misalkan pemadaman sementara terjadi di wilayah A. VM di wilayah B dan C masih dapat meminta nama DNS di zona privat, termasuk nama yang terdaftar otomatis dari wilayah A. Mereka dapat terus menyelesaikan alamat IP VM1 di wilayah A, meskipun VM1 tidak tersedia. Gangguan layanan di wilayah A tidak memengaruhi resolusi nama di wilayah lain.

Contoh sebelumnya tidak menunjukkan skenario pemulihan bencana ketika solusi Anda melakukan failover ke VM pengganti untuk VM1 di wilayah lain. Namun, karena zona privat bersifat global, Anda dapat membuat ulang VM1 di jaringan virtual wilayah lain untuk mengambil alih beban kerja.

Jika Anda membuat jaringan virtual dan sumber daya jaringan di beberapa wilayah, Anda perlu merencanakan dan menerapkan strategi multiregion Anda untuk aplikasi yang memerlukan failover lintas wilayah.

Ketahanan terhadap ancaman keamanan dan kesalahan konfigurasi

Serangan keamanan dan kesalahan konfigurasi adalah dua risiko keandalan paling signifikan untuk zona DNS. Beberapa kelas serangan khususnya menargetkan resolusi DNS, dan kesalahan konfigurasi yang tidak disengaja dapat mengganggu beban kerja Anda sama parahnya.

Untuk panduan keamanan komprehensif khusus untuk zona DNS privat, lihat Melindungi Zona dan Rekaman DNS privat.

Ketahanan terhadap pemadaman layanan

Azure DNS adalah layanan yang sangat tangguh, dengan SLA ketersediaan 100% saat aplikasi Anda memenuhi kondisi tertentu. Pemadaman layanan sangat tidak biasa, tetapi masalah jaringan atau infrastruktur lainnya dapat mengganggu konektivitas ke layanan Azure DNS.

Memantau pemadaman layanan

Microsoft tidak secara otomatis memberi tahu Anda saat wilayah sedang tidak berfungsi. Namun, Anda dapat menggunakan Azure Service Health untuk memahami kesehatan layanan secara keseluruhan, termasuk kegagalan wilayah apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

Pengujian gangguan layanan

Azure Chaos Studio menyediakan serangkaian kesalahan untuk mensimulasikan masalah dengan resolusi DNS. Misalnya, agen Chaos Studio menyediakan jenis kesalahan Kegagalan DNS, dan Azure Kubernetes Service (AKS) Chaos Mesh menyediakan kemampuan DNS Chaos. Anda dapat menggunakan jenis kesalahan ini untuk menguji bagaimana aplikasi dan infrastruktur Anda merespons ketika permintaan resolusi DNS gagal, yang mungkin terjadi selama kegagalan jaringan parsial.

Ketahanan terhadap pemadaman portal dan alat manajemen

Jika Anda mengelola zona DNS di portal Azure, bersiaplah untuk skenario di mana Anda tidak dapat mengaksesnya, terutama jika Anda perlu mengonfigurasi ulang zona DNS Anda selama pemadaman platform.

Anda dapat menggunakan berbagai alat untuk menyebarkan dan mengelola zona privat Azure DNS. Pelajari cara menggunakan Azure CLI atau Azure PowerShell untuk mengelola zona privat Anda. Atau, gunakan infrastruktur sebagai kode (IaC), seperti Bicep atau Terraform, untuk menyebarkan dan mengonfigurasi zona privat Anda. Alat-alat ini tetap beroperasi meskipun portal Azure terdegradasi.

Pencadangan dan pemulihan

Azure DNS adalah layanan stateless. Ini tidak menyediakan pencadangan terkelola atau pemulihan ke titik waktu tertentu untuk zona DNS privat.

Untuk mempertahankan konfigurasi sumber daya Azure lengkap, tentukan zona DNS privat Anda dengan menggunakan IaC, seperti Bicep atau Terraform, dan simpan definisi dalam kontrol sumber. Uji definisi secara berkala sehingga Anda dapat menggunakannya untuk menyebarkan ulang konfigurasi Anda.

Ketahanan terhadap pemeliharaan layanan

Microsoft secara teratur menerapkan pembaruan layanan dan melakukan pemeliharaan lainnya. Platform Azure menangani aktivitas ini secara otomatis, memastikan bahwa pemeliharaan mulus dan transparan bagi Anda. Tidak ada downtime yang diharapkan selama peristiwa pemeliharaan kecuali Anda menerima pemberitahuan tentang pemeliharaan terencana melalui Azure Service Health.

Perjanjian tingkat layanan

Perjanjian tingkat layanan (SLA) untuk layanan Azure menjelaskan ketersediaan yang diharapkan dari setiap layanan dan kondisi yang harus dipenuhi solusi Anda untuk mencapai harapan ketersediaan tersebut. Untuk informasi selengkapnya, lihat SLA untuk layanan online.

Azure DNS menyediakan SLA ketersediaan 100% untuk respons kueri DNS yang valid saat Anda memenuhi kondisi tertentu. Kondisi ini termasuk mencoba kembali permintaan yang gagal setidaknya selama 60 detik berturut-turut. Tinjau dokumen SLA untuk kondisi terperinci.