Azure Traffic Manager dengan Azure Site Recovery

  • Artikel

Azure Traffic Manager memungkinkan Anda mengontrol distribusi lalu lintas di seluruh titik akhir aplikasi Anda. Titik akhir adalah layanan akses internet yang dihosting di dalam atau di luar Azure.

Traffic Manager menggunakan Domain Name System (DNS) untuk mengarahkan permintaan klien ke titik akhir yang paling tepat, berdasarkan metode perutean lalu lintas dan kesehatan titik akhir. Traffic Manager menyediakan berbagai metode perutean lalu lintas dan opsi pemantauan titik akhiragar sesuai dengan kebutuhan aplikasi yang berbeda dan model failover otomatis. Klien tersambung ke titik akhir yang dipilih secara langsung. Traffic Manager bukan proksi atau gateway, dan tidak melihat lalu lintas yang lewat antara klien dan layanan.

Artikel ini menjelaskan bagaimana Anda dapat menggabungkan perutean cerdas Azure Traffic Monitor dengan kemampuan pemulihan bencana dan migrasi Azure Site Recovery yang kuat.

Failover Lokal ke Azure

Untuk skenario pertama, pertimbangkanPerusahaan Ayang memiliki sema infrastruktur aplikasinya berjalan di lingkungan lokalnya. Untuk alasan kelangsungan bisnis dan alasan kepatuhan, Perusahaan A memutuskan untuk menggunakan Azure Site Recovery untuk melindungi aplikasinya.

Perusahaan A menjalankan aplikasi dengan titik akhir publik dan menginginkan kemampuan untuk mengalihkan lalu lintas ke Azure dengan lancar saat peristiwa bencana. Metode perutean lalu lintas prioritas di Azure Traffic Manager memungkinkan Perusahaan A untuk dengan mudah menerapkan pola failover ini.

Penyiapannya sebagai berikut:

  • Perusahaan A membuat Profil Traffic Manager.
  • Menggunakan metode perutean Prioritas, Perusahaan A membuat dua titik akhir - Primer untuk lokal dan Failoveruntuk Azure. Primer ditetapkan sebagai Prioritas 1 dan failover ditetapkan sebagai Prioritas 2.
  • Karena titik akhirprimer dihosting di luar Azure, titik akhir dibuat sebagai titik akhirEksternal.
  • Dengan Azure Site Recovery, situs Azure tidak memiliki komputer virtual atau aplikasi yang berjalan sebelum failover. Jadi,titik akhir Failover juga dibuat sebagai titik akhirEksternal.
  • Secara default, lalu lintas pengguna diarahkan ke aplikasi lokal karena titik akhir tersebut memiliki prioritas tertinggi yang terkait dengannya. Tidak ada lalu lintas yang diarahkan ke Azure jika titik akhirPrimersehat.

Lokal-ke-Azure sebelum failover

Pada peristiwa bencana, Perusahaan A dapat memicu failoverAzure dan memulikan aplikasinya di azure. Ketika Azure Traffic Manager mendeteksi bahwa titik akhirPrimer tidak lagi sehat, secara otomatis menggunakan titik akhir Failover dalam respons DNS dan pengguna terhubung ke aplikasi yang dipulihkan di Azure.

Lokal-ke-Azure setelah failover

Bergantung pada persyaratan bisnis, Perusahaan Adapat memilih frekuensi pemeriksaanyang lebih rendah atau lebih tinggi untuk beralih antar lokal ke Azure saat peristiwa bencana untuk memastikan waktu henti minimal untuk pengguna.

Ketika bencana teratasi, Perusahaan A dapat mengalihkan operasi dari Azure ke lingkungan lokalnya (VMware atau Hyper-V) menggunakan Azure Site Recovery. Sekarang, ketika Traffic Manager mendeteksi bahwa titik akhirPrimer sehat kembali, ia secara otomatis menggunakan titik akhirPrimerdalam respons DNS-nya.

Migrasi Lokal ke Azure

Selain pemulihan bencana, Azure Site Recovery juga memungkinkan migrasi ke Azure. Menggunakan kemampuan pengujian kegagalan Azure Site Recovery yang canggih, pelanggan dapat menilai kinerja aplikasi di Azure tanpa mempengaruhi lingkungan lokal mereka. Dan ketika pelanggan siap untuk bermigrasi, mereka dapat memilih untuk memigrasikan seluruh beban kerja bersama-sama atau memilih untuk bermigrasi dan menskalakan secara bertahap.

Metode perutean Tertimbang Azure Traffic Manager dapat digunakan untuk mengarahkan beberapa bagian lalu lintas masuk ke Azure sambil mengarahkan mayoritas ke lingkungan lokal. Pendekatan ini dapat membantu menilai kinerja skala karena Anda dapat terus meningkatkan bobot yang ditetapkan ke Azure saat Anda memigrasikan semakin banyak beban kerja Anda ke Azure.

Misalnya Perusahaan B memilih untuk bermigrasi secara bertahap, memindahkan beberapa lingkungan aplikasinya sambil mempertahankan sisanya di lokal. Selama tahap awal ketika sebagian besar lingkungan berada di lokal, bobot yang lebih besar ditetapkan ke lingkungan lokal. Pengelola lalu lintas mengembalikan titik akhir berdasarkan bobot yang ditetapkan ke titik akhir yang tersedia.

Migras Lokal-ke-Azure

Selama migrasi, kedua titik akhir aktif dan sebagian besar lalu lintas diarahkan ke lingkungan lokal. Saat migrasi berlanjut, bobot yang lebih besar dapat ditetapkan ke titik akhir di Azure dan akhirnya titik akhir di lokal dapat dinonaktifkan pasca migrasi.

Failover Azure ke Azure

Untuk contoh ini, pertimbangkan Perusahaan C yang memiliki semua infrastruktur aplikasinya yang menjalankan Azure. Untuk kelangsungan bisnis dan alasan kepatuhan, Perusahaan C memutuskan untuk menggunakan Azure Site Recovery untuk melindungi aplikasinya.

Perusahaan C menjalankan aplikasi dengan titik akhir publik dan menginginkan kemampuan untuk mengalihkan lalu lintas ke wilayah Azure dengan lancar saat peristiwa bencana. Metode perutean lalu lintas Prioritasmemungkinkan Perusahaan Cdengan mudah menerapkan pola failover ini.

Penyiapannya sebagai berikut:

  • Perusahaan C membuat Profil Traffic Manager.
  • Menggunakan metode perutean Prioritas, Perusahaan C membuat dua titik akhir - Primer untuk wilayah sumber (Azure Asia Timur) dan Failover untuk wilayah pemulihan (Azure Asia Tenggara). Primer ditetapkan sebagai Prioritas 1 dan Failover ditetapkan sebagai Prioritas 2.
  • Karena titik akhirPrimer dihosting di Azure, titik akhir bisa sebagai titik akhir Azure.
  • Dengan Azure Site Recovery, situs Azure pemulihan tidak memiliki komputer virtual apapun atau aplikasi yang berjalan sebelum failover. Jadi, titik akhirFailover dapat dibuat sebagai titik akhirEksternal.
  • Secara default, lalu lintas pengguna diarahkan ke aplikasi wilayah sumber (Asia Timur) karena titik akhir tersebut memiliki prioritas tertinggi yang terkait dengannya. Tidak ada lalu lintas yang diarahkan ke wilayah pemulihan jika titik akhirPrimer sehat.

Azure-ke-Azure sebelum failover

Dalam peristiwa bencana, Perusahaan C dapat memicu kegagalan dan memulihkan aplikasinya pada wilayah Azure pemulihan. Ketika Azure Traffic Manager mendeteksi bahwa titik akhir Primer tidak lagi sehat, secara otomatis menggunakan titik akhir Failover dalam respon DNS dan pengguna terhubung ke aplikasi yang dipulihkan di wilayah Azure.pemulihan (Asia Tenggara).

Azure-ke-Azure setelah failover

Bergantung pada persyaratan bisnis, Perusahaan Cdapat memilih frekuensi pemeriksaanyang lebih tinggi atau lebih rendah untuk beralih antar sumber dan wilayah pemulihan, dan memastikan waktu henti minimal untuk pengguna.

Ketika bencana teratasi, Perusahaan Cdapat mengalihkan operasi dari wilayah Azure pemulihan ke wilayah Azure sumber menggunakan Azure Site Recovery. Sekarang, ketika Traffic Manager mendeteksi bahwa titik akhirPrimer sehat kembali, ia secara otomatis menggunakan titik akhirPrimerdalam respons DNS-nya.

Melindungi aplikasi perusahaan multi-wilayah

Perusahaan global sering meningkatkan pengalaman pelanggan dengan menyesuaikan aplikasi mereka ke melayani kebutuhan wilayah. Pengurangan pelokalan dan latensi dapat menyebabkan infrastruktur aplikasi terbagi lintas wilayah. Perusahaan juga terikat oleh undang-undang data wilayah di area tertentu dan memilih untuk mengisolasi sebagian infrastruktur aplikasi mereka dalam batas-batas wilayah.

Mari kita pertimbangkan contoh di mana Perusahaan D telah membagi titik akhir aplikasinya untuk secara terpisah melayani Jerman dan seluruh dunia. Perusahaan D menggunakan metode perutean Geografis Azure Traffic Manager untuk menyiapkan ini. Setiap lalu lintas yang berasal dari Jerman diarahkan ke Titik akhir 1 dan lalu lintas apa pun yang berasal dari luar Jerman diarahkan ke Titik akhir 2.

Masalah pengaturan ini adalah jika Titik akhir 1 berhenti bekerja karena alasan apa pun, tidak ada pengalihan lalu lintas ke Titik akhir 2. Lalu lintas yang berasal dari Jerman terus diarahkan ke Titik akhir 1 terlepas dari kesehatan titik akhir tersebut, membiarkan pengguna Jerman tanpa akses ke aplikasi Perusahaan D. Demikian pula, jika Titik akhir 2 luring, tidak ada pengalihan lalu lintas ke Titik akhir 1.

Aplikasi multi-wilayah sebelumnya

Untuk menghindari masalah ini dan memastikan ketahanan aplikasi, Perusahaan D menggunakan Profil Traffic Manager berlapis dengan Azure Site Recovery. Dalam pengaturan profil berlapis, lalu lintas tidak diarahkan ke titik akhir individual, melainkan ke profil Traffic Manager. Berikut cara kerja penyetelan ini:

  • Alih-alih menggunakan perutean Geografis dengan titik akhir individu, Perusahaan D menggunakan perutean Geografis dengan profil Traffic Manager.
  • Setiap profil Traffic Manager anak menggunakan peruteanPrioritas dengan titik akhir primer dan pemulihan, sehingga menumpuk peruteanPrioritas dalam peruteanGeografis.
  • Untuk mengaktifkan ketahanan aplikasi, setiap distribusi beban kerja menggunakan Azure Site Recovery untuk failover ke wilayah pemulihan jika terjadi bencana.
  • Saat Traffic Manager induk menerima kueri DNS, kueri diarahkan ke Traffic Manager anak yang relevan yang merespons kueri dengan titik akhir yang tersedia.

Aplikasi multi-wilayah setelahnya

Misalnya, jika titik akhir di Jerman Tengah gagal, aplikasi dapat dengan cepat dipulihkan ke Jerman Timur Laut. Titik akhir baru menangani lalu lintas yang berasal dari Jerman dengan waktu henti minimal untuk pengguna. Demikian pula ketidaktersediaan titik akhir di Eropa Barat dapat ditangani dengan memulihkan beban kerja aplikasi ke Eropa Utara, dengan Azure Traffic Manager menangani pengalihan DNS ke titik akhir yang tersedia.

Pengaturan di atas dapat diperluas untuk menyertakan kombinasi wilayah dan titik akhir sebanyak yang diperlukan. Traffic Manager memungkinkan hingga 10 tingkat profil berlapis dan tidak mengizinkan perulangan dalam konfigurasi berlapis.

Pertimbangan Tujuan Waktu Pemulihan (RTO)

Di sebagian besar organisasi, menambahkan atau memodifikasi catatan DNS ditangani baik oleh tim terpisah atau oleh seseorang di luar organisasi. Ini membuat tugas mengubah catatan DNS sangat menantang. Waktu yang diperlukan untuk memperbarui catatan DNS oleh tim atau organisasi lain yang mengelola infrastruktur DNS bervariasi dari organisasi ke organisasi, dan berdampak pada RTO aplikasi.

Dengan menggunakan Traffic Manager, Anda dapat memuat lebih dulu pekerjaan yang diperlukan untuk pembaruan DNS. Tidak diperlukan tindakan manual atau terencana pada saat kegagalan sebenarnya. Pendekatan ini membantu dalam beralih cepat (dan karenanya menurunkan RTO) serta menghindari kesalahan perubahan DNS yang memakan waktu mahal saat peristiwa bencana. Dengan Traffic Manager, bahkan langkah pengalihan operasi otomatis, yang jika tidak akan dikelola secara terpisah.

Mengatur interval pemeriksaanyang benar melalui pemeriksaan kesehatan interval dasar atau cepat dapat sangat menurunkan RTO selama kegagalan dan mengurangi waktu henti bagi pengguna.

Anda juga dapat mengoptimalkan nilai Waktu Hidup (TTL) DNS untuk profil Traffic Manager. TTL adalah nilai di mana entri DNS akan di-cache oleh klien. Sebagai catatan, DNS tidak akan dikueri dua kali dalam rentang TTL. Setiap catatan DNS memiliki TTL yang terkait dengannya. Mengurangi nilai ini menghasilkan lebih banyak kueri DNS ke Traffic Manager tetapi dapat mengurangi RTO dengan menemukan ketidaktersediaan lebih cepat.

TTL yang dialami oleh klien juga tidak meningkat jika jumlah resolver DNS antara klien dan server DNS otoritatif meningkat. DNS resolver ‘menghitung mundur' TTL dan hanya meneruskan nilai TTL yang mencerminkan waktu yang berlalu sejak rekaman di-cache. Ini memastikan bahwa catatan DNS di klien disegarkan setelah TTL, terlepas dari jumlah resolver DNS dalam rantai.

Langkah berikutnya