Merancang untuk ketersediaan tinggi dengan Azure ExpressRoute

Azure ExpressRoute dirancang untuk ketersediaan tinggi, menyediakan konektivitas jaringan privat tingkat operator ke sumber daya Microsoft. Ini berarti tidak ada satu titik kegagalan dalam jaringan Microsoft. Untuk memaksimalkan ketersediaan, segmen pelanggan dan penyedia layanan sirkuit Azure ExpressRoute Anda juga harus dirancang untuk ketersediaan tinggi. Artikel ini membahas pertimbangan arsitektur jaringan untuk membangun konektivitas yang kuat menggunakan Azure ExpressRoute dan fitur penyempurnaan untuk meningkatkan ketersediaan tinggi sirkuit Azure ExpressRoute Anda.

Catatan

Konsep yang dijelaskan dalam artikel ini berlaku sama apakah sirkuit Azure ExpressRoute dibuat di bawah Virtual WAN atau di luarnya.

Pertimbangan arsitektur

Gambar berikut mengilustrasikan cara yang disarankan untuk terhubung menggunakan sirkuit Azure ExpressRoute untuk memaksimalkan ketersediaan.

Untuk ketersediaan tinggi, penting untuk mempertahankan redundansi di seluruh jaringan end-to-end. Ini berarti mempertahankan redundansi dalam jaringan lokal Anda dan tidak mengorbankan redundansi dalam jaringan penyedia layanan Anda. Minimal, ini melibatkan menghindari satu titik kegagalan jaringan. Daya dan pendinginan redundan untuk perangkat jaringan semakin meningkatkan ketersediaan tinggi.

Pertimbangan desain lapisan fisik mil pertama

Jika Anda mengakhiri koneksi utama dan sekunder sirkuit Azure ExpressRoute pada Customer Premises Equipment (CPE) yang sama, Anda membahayakan ketersediaan tinggi dalam jaringan lokal Anda. Selain itu, mengonfigurasi kedua koneksi dengan menggunakan port CPE yang sama memaksa mitra untuk mengorbankan ketahanan tinggi pada segmen jaringan mereka. Ini dapat terjadi dengan mengakhiri dua koneksi di bawah subinterface yang berbeda atau menggabungkan dua koneksi dalam jaringan mitra, seperti yang diilustrasikan di bawah ini.

Mengakhiri koneksi utama dan sekunder sirkuit Azure ExpressRoute di lokasi geografis yang berbeda dapat membahayakan performa jaringan. Jika lalu lintas secara aktif diseimbangkan beban di seluruh koneksi yang dihentikan di lokasi yang berbeda, perbedaan besar dalam latensi jaringan antara kedua jalur dapat mengakibatkan performa suboptimal.

Untuk pertimbangan desain geo-redundan, lihat Merancang untuk pemulihan bencana dengan Azure ExpressRoute.

Sambungan aktif-aktif

Jaringan Microsoft mengoperasikan koneksi utama dan sekunder sirkuit Azure ExpressRoute dalam mode aktif-aktif. Namun, Anda dapat memaksa koneksi redundan untuk beroperasi dalam mode aktif pasif melalui pengumuman rute Anda. Memperkenalkan rute yang lebih spesifik dan penambahan awalan jalur BGP AS adalah teknik umum untuk memilih satu jalur dibandingkan dengan jalur lainnya.

Untuk meningkatkan tingkat ketersediaan, disarankan untuk mengoperasikan kedua koneksi dalam mode aktif-aktif. Ini memungkinkan jaringan Microsoft untuk membagi beban lalu lintas melalui koneksi berdasarkan per aliran.

Menjalankan koneksi dalam mode aktif-pasif berisiko kedua koneksi gagal jika jalur aktif gagal. Penyebab umum kegagalan termasuk kurangnya pengelolaan aktif terhadap koneksi pasif dan mengiklankan rute yang sudah usang.

Atau, menjalankan koneksi dalam mode aktif-aktif hanya menghasilkan sekitar setengah alur yang gagal dan dialihkan, secara signifikan meningkatkan Mean Time To Recover (MTTR).

Catatan

Selama pemeliharaan atau peristiwa yang tidak direncanakan yang berdampak pada satu koneksi, Microsoft akan menggunakan AS path prepending untuk mengalihkan lalu lintas ke koneksi yang sehat. Pastikan lalu lintas dapat merutekan melalui jalur sehat saat prepending jalur dikonfigurasi oleh Microsoft dan iklan rute yang diperlukan diatur dengan tepat untuk menghindari gangguan layanan.

NAT untuk peering Microsoft

Peering Microsoft ditujukan untuk komunikasi antara titik akhir publik. Biasanya, titik akhir privat lokal adalah Network Address Translated (NATed) dengan IP publik di jaringan pelanggan atau mitra sebelum berkomunikasi melalui peering Microsoft. Menggunakan koneksi primer dan sekunder dalam konfigurasi aktif-aktif berdampak pada kecepatan pemulihan Anda dari kegagalan di salah satu koneksi. Dua opsi NAT yang berbeda diilustrasikan di bawah ini:

Opsi 1:

NAT diterapkan setelah memisahkan lalu lintas antara koneksi primer dan sekunder. Kumpulan NAT independen digunakan untuk perangkat utama dan sekunder guna memenuhi persyaratan NAT berbasis status. Lalu lintas kembali tiba pada perangkat edge yang sama melalui aliran yang keluar.

Jika koneksi Azure ExpressRoute gagal, kumpulan NAT yang sesuai menjadi tidak dapat dijangkau, merusak semua alur jaringan. Alur ini harus dibuat ulang oleh TCP atau lapisan aplikasi setelah batas waktu jendela. Selama kegagalan, Azure tidak dapat menjangkau server lokal menggunakan NAT yang sesuai hingga konektivitas dipulihkan.

Opsi 2:

Kumpulan NAT umum digunakan sebelum memisahkan lalu lintas antara koneksi primer dan sekunder. Ini tidak memperkenalkan satu titik kegagalan, sehingga mempertahankan ketersediaan tinggi.

Kumpulan NAT tetap dapat dijangkau bahkan jika koneksi primer atau sekunder gagal, memungkinkan lapisan jaringan untuk mengalihkan paket dan pulih lebih cepat.

Catatan

• Jika menggunakan opsi NAT 1 (kumpulan NAT independen untuk koneksi primer dan sekunder) dan memetakan port alamat IP dari satu kumpulan NAT ke server lokal, server tidak akan dapat dijangkau melalui sirkuit Azure ExpressRoute jika koneksi yang sesuai gagal.
• Mengakhiri koneksi Azure ExpressRoute BGP pada perangkat stateful dapat menyebabkan masalah failover selama pemeliharaan yang direncanakan atau tidak direncanakan oleh Microsoft atau Penyedia Azure ExpressRoute Anda. Uji pengaturan Anda untuk memastikan failover yang tepat, dan jika memungkinkan, hentikan sesi BGP pada perangkat stateless.

Fitur penyesuaian untuk peering privat

Bagian ini meninjau fitur opsional yang membantu meningkatkan ketersediaan tinggi sirkuit Azure ExpressRoute Anda, tergantung pada penyebaran dan sensitivitas Azure Anda terhadap MTTR. Secara khusus, ini mencakup penyebaran gateway jaringan virtual Azure ExpressRoute yang peka terhadap zona dan Bidirectional Forwarding Detection (BFD).

Gateway jaringan virtual Azure ExpressRoute yang mendukung Zona Ketersediaan

Zona Ketersediaan di wilayah Azure menggabungkan domain kesalahan dan domain pembaruan. Untuk mencapai ketahanan dan ketersediaan tertinggi, konfigurasikan gateway jaringan virtual Azure ExpressRoute yang redundan zona. Untuk informasi selengkapnya, lihat Tentang gateway jaringan virtual redundan zona di Azure Availability Zones. Untuk mengonfigurasi gateway jaringan virtual yang redundan secara zona, lihat Membuat gateway jaringan virtual redundan zona di Zona Ketersediaan Azure.

Meningkatkan waktu deteksi kegagalan

Azure ExpressRoute mendukung BFD melalui peering privat, mengurangi waktu deteksi kegagalan melalui jaringan Lapisan 2 antara Microsoft Enterprise Edge (MSEEs) dan tetangga BGP mereka di sisi lokal dari sekitar 3 menit (default) menjadi kurang dari satu detik. Deteksi kegagalan cepat membantu mempercepat pemulihan. Untuk informasi selengkapnya, lihat Mengonfigurasi BFD melalui Azure ExpressRoute.

Langkah berikutnya

Artikel ini membahas perancangan untuk ketersediaan tinggi pada sirkuit Azure ExpressRoute. Titik peering sirkuit Azure ExpressRoute disematkan ke lokasi geografis dan dapat terkena dampak kegagalan bencana yang mempengaruhi seluruh lokasi tersebut.

Untuk pertimbangan desain dalam membangun konektivitas jaringan geo-redundan ke jaringan inti Microsoft yang dapat menahan kegagalan bencana yang memengaruhi seluruh wilayah, lihat Merancang untuk pemulihan bencana dengan peering privat Azure ExpressRoute.