Merancang untuk pemulihan bencana dengan peering privat ExpressRoute

  • Artikel

ExpressRoute dirancang untuk ketersediaan tinggi guna menyediakan konektivitas jaringan privat tingkat operator ke sumber daya Microsoft. Dengan kata lain, tidak ada satu titik kegagalan di jalur ExpressRoute dalam jaringan Microsoft. Untuk pertimbangan desain guna memaksimalkan ketersediaan sirkuit ExpressRoute, lihat Merancang untuk ketersediaan tinggi dengan ExpressRoute dan Kerangka Kerja yang Dirancang dengan Baik

Namun, mengambil pepatah populer Murphy - apa pun yang bisa salah akan salah--sebagai pertimbangan, dalam artikel ini, mari kita fokus pada solusi yang melampaui kegagalan yang dapat diatasi menggunakan sirkuit ExpressRoute tunggal. Kita akan melihat pertimbangan arsitektur jaringan untuk membangun konektivitas jaringan backend yang kuat untuk pemulihan bencana menggunakan sirkuit ExpressRoute geo-redundan.

Catatan

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

Kebutuhan akan solusi konektivitas redundan

Ada kemungkinan dan instans di mana lokasi peering ExpressRoute atau seluruh layanan regional terdegradasi. Akar penyebab pemadaman layanan regional seperti itu termasuk bencana alam. Oleh karena itu, penting untuk merencanakan pemulihan bencana untuk kelangsungan bisnis dan aplikasi misi penting.

Catatan

Ketika Anda perlu menerapkan desain pemulihan bencana dalam situasi sensitif waktu, seperti untuk menjaga kelangsungan bisnis selama bencana alam, Anda harus mempertimbangkan faktor-faktor berikut:

  • Dokumen ini memberikan panduan tentang cara menerapkan desain pemulihan bencana yang kuat untuk beberapa sirkuit ExpressRoute yang dikonfigurasi melalui lokasi peering yang berbeda. Skenario ini mengasumsikan bahwa Anda memiliki waktu dan sumber daya yang memadai untuk menyiapkan sirkuit ExpressRoute.
  • Jika Anda perlu dengan cepat mengonfigurasi desain pemulihan bencana untuk satu sirkuit ExpressRoute yang tidak redundan secara geografis, Anda dapat menggunakan alternatif berikut:

Apa pun yang terjadi, baik Anda menjalankan aplikasi misi penting di wilayah Azure atau lokal maupun di tempat lain, Anda dapat menggunakan wilayah Azure lainnya sebagai lokasi kegagalan Anda. Artikel berikut membahas pemulihan bencana dari aplikasi dan perspektif akses ujung depan:

Jika Anda mengandalkan konektivitas ExpressRoute antara jaringan lokal dan Microsoft, Anda perlu mempertimbangkan hal berikut untuk merencanakan pemulihan bencana melalui ExpressRoute:

Tantangan dalam menggunakan beberapa sirkuit ExpressRoute

Saat Anda menghubungkan serangkaian jaringan yang sama menggunakan lebih dari satu koneksi, Anda menetapkan jalur paralel di antara jaringan. Jalur paralel, ketika tidak dirancang dengan benar, dapat menyebabkan perutean asimetris. Jika Anda memiliki entitas stateful, misalnya, NAT atau firewall di jalur, perutean asimetris dapat memblokir arus lalu lintas. Biasanya, melalui jalur peering privat ExpressRoute, Anda tidak menemukan entitas stateful seperti NAT atau Firewall. Oleh karena itu, perutean asimetris melalui peering privat ExpressRoute tidak selalu memblokir arus lalu lintas.

Namun, jika Anda menyeimbangkan muatan lalu lintas di seluruh jalur paralel geo-redundan, terlepas dari apakah Anda memiliki entitas stateful atau tidak, Anda akan mengalami performa jaringan yang tidak konsisten. Jalur paralel geo-redundan ini dapat melalui metro yang sama atau metro yang berbeda yang ditemukan di halaman penyedia berdasarkan lokasi.

Redundansi dengan sirkuit ExpressRoute di metro yang sama

Banyak metro memiliki dua lokasi ExpressRoute. Contohnya adalah Amsterdam dan Amsterdam2. Saat merancang redundansi, Anda dapat membangun dua jalur paralel ke Azure dengan kedua lokasi di metro yang sama. Anda menyelesaikan tugas ini dengan penyedia yang sama atau memilih untuk bekerja dengan penyedia layanan yang berbeda untuk meningkatkan ketahanan. Keuntungan lain dari desain ini adalah saat kegagalan aplikasi terjadi, latensi ujung-ke-ujung antara aplikasi lokal Anda dan Microsoft tetap kurang lebih sama. Namun, jika ada bencana alam seperti gempa bumi, konektivitas untuk kedua jalur mungkin tidak lagi tersedia.

Redundansi dengan sirkuit ExpressRoute di metro yang berbeda

Saat menggunakan metro yang berbeda untuk redundansi, Anda harus memilih lokasi sekunder di wilayah geo-politik yang sama. Untuk memilih lokasi di luar wilayah geo-politik, Anda perlu menggunakan SKU Premium untuk kedua sirkuit di jalur paralel. Keuntungan dari konfigurasi ini adalah kemungkinan bencana alam menyebabkan pemadaman ke kedua tautan lebih rendah tetapi dengan biaya peningkatan latensi end-to-end.

Catatan

Mengaktifkan BFD di sirkuit ExpressRoute akan membantu deteksi kegagalan link yang lebih cepat antara perangkat Microsoft Enterprise Edge (MSEE) dan router Pelanggan/Edge Mitra. Namun, failover dan konvergensi keseluruhan ke situs redundan mungkin memakan waktu hingga 180 detik dalam beberapa kondisi kegagalan dan Anda mungkin mengalami peningkatan latensi atau penurunan performa selama waktu ini.

Dalam artikel ini, mari kita bahas cara mengatasi tantangan yang mungkin Anda hadapi saat mengonfigurasi jalur geo-redundan.

Pertimbangan jaringan lokal kecil hingga menengah

Mari kita pertimbangkan contoh jaringan yang diilustrasikan dalam diagram berikut. Dalam contoh, konektivitas ExpressRoute geo-redundan dibangun antara lokasi lokal Contoso dan VNet Contoso di wilayah Azure. Dalam diagram, garis biru solid menunjukkan jalur pilihan (melalui ExpressRoute 1) dan titik-titik mewakili jalur siaga (melalui ExpressRoute 2).

Diagram of small to medium size on-premises network considerations.

Secara default, jika Anda mengiklankan rute secara identik di semua jalur ExpressRoute, lalu lintas terikat azure load-balances lokal di semua jalur ExpressRoute menggunakan perutean multi-jalur biaya sama (ECMP).

Namun, dengan sirkuit ExpressRoute geo-redundan, kita harus mempertimbangkan performa jaringan yang berbeda dengan jalur jaringan yang berbeda (terutama untuk latensi jaringan). Untuk mendapatkan performa jaringan yang lebih konsisten selama pengoperasian normal, Anda mungkin lebih memilih sirkuit ExpressRoute yang menawarkan latensi minimal.

Anda dapat memengaruhi Azure untuk lebih memilih satu sirkuit ExpressRoute daripada yang lain menggunakan salah satu teknik berikut (tercantum dalam urutan efektivitas):

  • menetapkan rute yang lebih spesifik melalui sirkuit ExpressRoute pilihan dibandingkan dengan sirkuit ExpressRoute lainnya
  • mengonfigurasi Bobot Koneksi yang lebih tinggi pada koneksi yang menghubungkan jaringan virtual ke sirkuit ExpressRoute pilihan
  • menetapkan rute melalui sirkuit ExpressRoute yang kurang disukai dengan Jalur AS yang lebih panjang (Jalur AS prepend)

Rute yang lebih spesifik

Diagram berikut mengilustrasikan pengaruh pemilihan jalur ExpressRoute menggunakan iklan rute yang lebih spesifik. Dalam contoh yang diilustrasikan, rentang IP /24 lokal Contoso ditetapkan sebagai dua rentang alamat /25 melalui jalur pilihan (ExpressRoute 1) dan sebagai /24 melalui jalur siaga (ExpressRoute 2).

Diagram of influencing path selection using more specific routes.

Karena /25 lebih spesifik, dibandingkan dengan /24, Azure akan mengirim lalu lintas yang ditujukan ke 10.1.11.0/24 melalui ExpressRoute 1 dalam status normal. Jika kedua koneksi ExpressRoute 1 turun, VNet akan melihat iklan rute 10.1.11.0/24 hanya melalui ExpressRoute 2; dan oleh karena itu, sirkuit siaga digunakan dalam status kegagalan ini.

Bobot koneksi

Tangkapan layar berikut ini mengilustrasikan konfigurasi bobot koneksi ExpressRoute melalui portal Microsoft Azure.

Screenshot of configuring connection weight via Azure portal.

Diagram berikut ini mengilustrasikan pengaruh pemilihan jalur ExpressRoute menggunakan bobot koneksi. Bobot koneksi default adalah 0. Dalam contoh berikut, berat koneksi untuk ExpressRoute 1 dikonfigurasi sebagai 100. Ketika VNet menerima awalan rute yang diiklankan melalui lebih dari satu sirkuit ExpressRoute, VNet lebih memilih koneksi dengan bobot tertinggi.

Diagram of influencing path selection using connection weight.

Jika kedua koneksi ExpressRoute 1 turun, VNet akan melihat iklan rute 10.1.11.0/24 hanya melalui ExpressRoute 2; dan oleh karena itu, sirkuit siaga digunakan dalam status kegagalan ini.

Jalur AS prepend

Diagram berikut ini mengilustrasikan pengaruh pemilihan jalur ExpressRoute menggunakan Jalur AS prepend. Dalam diagram, iklan rute melalui ExpressRoute 1 menunjukkan perilaku default eBGP. Pada iklan rute melalui ExpressRoute 2, ASN jaringan lokal ditambahkan sebagai tambahan di jalur AS rute. Ketika rute yang sama diterima melalui beberapa sirkuit ExpressRoute, per proses pemilihan rute eBGP, VNet akan lebih memilih rute dengan jalur AS terpendek.

Diagram of influencing path selection using AS path prepend.

Jika kedua koneksi ExpressRoute 1 turun, VNet akan melihat iklan rute 10.1.11.0/24 hanya melalui ExpressRoute 2. Akibatnya, jalur AS yang lebih panjang menjadi tidak relevan. Oleh karena itu, sirkuit siaga akan digunakan dalam status kegagalan ini.

Dengan menggunakan salah satu teknik, jika Anda memengaruhi Azure untuk lebih memilih salah satu ExpressRoute Anda dibandingkan yang lain, Anda juga perlu memastikan jaringan lokal juga lebih memilih jalur ExpressRoute yang sama untuk lalu lintas terikat Azure guna menghindari arus asimetris. Biasanya, nilai preferensi lokal digunakan untuk memengaruhi jaringan lokal untuk lebih memilih satu sirkuit ExpressRoute dibandingkan yang lain. Preferensi lokal adalah metrik internal BGP (iBGP). Rute BGP dengan nilai preferensi lokal tertinggi lebih disukai.

Penting

Ketika Anda menggunakan sirkuit ExpressRoute tertentu sebagai siaga, Anda perlu secara aktif mengelolanya dan secara berkala menguji operasi kegagalan.

Jaringan perusahaan terdistribusi besar

Ketika memiliki jaringan perusahaan terdistribusi besar, Anda mungkin memiliki beberapa sirkuit ExpressRoute. Di bagian ini, mari kita lihat cara merancang pemulihan bencana menggunakan sirkuit ExpressRoute aktif, tanpa memerlukan sirkuit siaga lainnya.

Mari kita pertimbangkan contoh yang diilustrasikan dalam diagram berikut. Dalam contoh, Contoso memiliki dua lokasi lokal yang terhubung ke dua penyebaran Contoso IaaS di dua wilayah Azure yang berbeda melalui sirkuit ExpressRoute di dua lokasi peering yang berbeda.

Diagram of large distributed on-premises network considerations.

Bagaimana kami merancang pemulihan bencana berpengaruh pada bagaimana lalu lintas wilayah ke lintas lokasi (wilayah1/wilayah2 ke lokasi2/lokasi1) dirutekan. Mari kita pertimbangkan dua arsitektur bencana berbeda yang merutekan lalu lintas wilayah-lokasi secara berbeda.

Skenario 1

Dalam skenario pertama, mari kita rancang pemulihan bencana sedemikian rupa agar semua lalu lintas antara wilayah Azure dan jaringan lokal mengalir melalui sirkuit ExpressRoute lokal dalam keadaan stabil. Jika sirkuit ExpressRoute lokal gagal, sirkuit ExpressRoute jarak jauh digunakan untuk semua arus lalu lintas antara Azure dan jaringan lokal.

Skenario 1 diilustrasikan dalam diagram berikut. Dalam diagram, garis hijau menunjukkan jalur untuk arus lalu lintas antara jaringan VNet1 dan lokal. Garis biru menunjukkan jalur untuk arus lalu lintas antara jaringan VNet2 dan lokal. Garis solid menunjukkan jalur yang diinginkan dalam keadaan stabil dan garis putus-putus menunjukkan jalur lalu lintas dalam kegagalan sirkuit ExpressRoute yang sesuai yang membawa arus lalu lintas dalam keadaan stabil.

Diagram of traffic flow for first scenario.

Anda dapat merancang skenario menggunakan bobot koneksi untuk memengaruhi VNet agar lebih memilih koneksi ke ExpressRoute lokasi peering lokal untuk lalu lintas terikat jaringan lokal. Untuk melengkapi solusinya, Anda harus memastikan arus lalu lintas balik yang simetris. Anda dapat menggunakan preferensi lokal pada sesi iBGP di antara router BGP Anda (yang sirkuit ExpressRoute-nya dihentikan di sisi lokal) untuk lebih memilih sirkuit ExpressRoute. Solusi diilustrasikan dalam diagram berikut.

Diagram of active-active ExpressRoute circuits solution 1.

Skenario 2

Skenario 2 diilustrasikan dalam diagram berikut. Dalam diagram, garis hijau menunjukkan jalur untuk arus lalu lintas antara jaringan VNet1 dan lokal. Garis biru menunjukkan jalur untuk arus lalu lintas antara jaringan VNet2 dan lokal. Dalam status stabil, garis padat dalam diagram, semua lalu lintas antara VNet dan lokasi lokal mengalir menggunakan backbone Microsoft secara normal, dan mengalir melalui interkoneksi antara lokasi lokal hanya dalam status kegagalan, garis putus-putus dalam diagram, dari ExpressRoute.

Diagram of traffic flow for second scenario.

Solusi diilustrasikan dalam diagram berikut. Seperti yang diilustrasikan, Anda dapat merancang skenario menggunakan rute yang lebih spesifik (Opsi 1) atau AS-path prepend (Opsi 2) untuk memengaruhi pemilihan jalur VNet. Untuk memengaruhi pilihan rute jaringan lokal untuk lalu lintas terikat Azure, Anda harus mengonfigurasi interkoneksi di antara lokasi lokal yang kurang disukai. Cara Anda mengonfigurasi tautan interkoneksi sebagai pilihan bergantung pada protokol perutean yang digunakan dalam jaringan lokal. Anda dapat menggunakan preferensi lokal dengan iBGP atau metrik dengan IGP (OSPF atau IS-IS).

Diagram of active-active ExpressRoute circuits solution 2.

Penting

Jika satu sirkuit ExpressRoute atau lebih dihubungkan ke beberapa jaringan virtual, jaringan virtual ke lalu lintas jaringan virtual dapat dirutekan melalui ExpressRoute. Namun, ini tidak disarankan. Untuk mengaktifkan jaringan virtual ke konektivitas jaringan virtual, konfigurasikan peering jaringan virtual.

Langkah berikutnya

Dalam artikel ini, kita membahas cara merancang pemulihan bencana konektivitas peering privat sirkuit ExpressRoute. Artikel berikut membahas pemulihan bencana dari aplikasi dan perspektif akses ujung depan: