Desain pemulihan bencana
Virtual WAN memungkinkan Anda untuk mengagregasi, menghubungkan, mengelola secara terpusat, dan mengamankan semua penyebaran global Anda. Penyebaran global Anda dapat mencakup kombinasi berbagai cabang, Titik Kehadiran (PoP), pengguna pribadi, kantor, jaringan virtual Azure, dan penyebaran multi-cloud lainnya. Anda dapat menggunakan SD-WAN, VPN situs-ke-situs, VPN titik-ke-situs, dan ExpressRoute untuk menghubungkan situs Anda yang berbeda ke hub virtual. Jika Anda memiliki beberapa hub virtual, semua hub akan terhubung secara utuh dalam penyebaran WAN Virtual standar.
Pada artikel ini, mari kita lihat cara merancang berbagai jenis opsi konektivitas jaringan sebagai layanan yang didukung Virtual WAN untuk pemulihan bencana.
Opsi konektivitas jaringan sebagai layanan dari Virtual WAN
Virtual WAN mendukung opsi konektivitas backend berikut:
- Konektivitas pengguna jarak jauh
- Cabang/Kantor/SD-WAN/VPN Situs-ke-situs
- Konektivitas privat (peering privat ExpressRoute)
Untuk setiap opsi konektivitas ini, Virtual WAN menyebarkan serangkaian instans gateway yang terpisah dalam hub virtual.
Secara inheren, Virtual WAN dirancang untuk menawarkan solusi agregasi jaringan dengan ketersediaan tinggi tingkat operator. Untuk high availability, Virtual WAN membuat instans beberapa instans ketika berbagai jenis gateway disebarkan di hub Virtual WAN. Untuk mempelajari selengkapnya tentang high availability ExpressRoute, lihat Merancang untuk high availability dengan ExpressRoute.
Dengan gateway VPN titik-ke-situs, jumlah minimum instans yang disebarkan adalah dua. Dengan gateway VPN titik-ke-situs, Anda memilih kapasitas throughput agregat gateway titik-ke-situs dan beberapa instans secara otomatis disediakan untuk Anda. Anda memilih kapasitas agregat sesuai dengan jumlah klien atau pengguna yang ingin Anda sambungkan ke hub virtual. Dari perspektif konektivitas klien, instans gateway VPN titik-ke-situs disembunyikan di balik Nama Domain yang Sepenuhnya Memenuhi Syarat (FQDN) gateway.
Untuk gateway VPN situs-ke-situs, dua instans gateway digunakan dalam hub virtual. Setiap instans gateway disebarkan dengan kumpulan alamat IP publik dan privatnya sendiri. Tangkapan layar berikut menunjukkan alamat IP yang terkait dengan dua contoh konfigurasi gateway VPN situs-ke-situs. Dengan kata lain, dua instans menyediakan dua titik akhir tunnel independen untuk membangun konektivitas VPN situs-ke-situs dari cabang Anda. Untuk memaksimalkan ketersediaan tinggi, lihat Pemilihan jalur Azure di beberapa link ISP.
Memaksimalkan high availability arsitektur jaringan Anda adalah langkah kunci pertama untuk Kelangsungan Bisnis dan Pemulihan Bencana (BCDR). Di sisa artikel ini, seperti yang dinyatakan sebelumnya, mari melampaui high availability dan mendiskusikan cara merancang jaringan konektivitas Virtual WAN Anda untuk BCDR.
Kebutuhan untuk desain pemulihan bencana
Bencana bisa datang kapan saja, di mana saja. Bencana dapat terjadi di wilayah atau jaringan penyedia cloud, dalam jaringan penyedia layanan, atau dalam jaringan lokal. Dampak wilayah dari layanan cloud atau jaringan karena faktor-faktor tertentu seperti bencana alam, kesalahan manusia, perang, terorisme, kesalahan konfigurasi sulit untuk disingkirkan. Jadi untuk kelangsungan aplikasi penting bisnis Anda, Anda perlu memiliki desain pemulihan bencana. Untuk desain pemulihan bencana yang komprehensif, Anda perlu mengidentifikasi semua dependensi yang mungkin gagal di jalur komunikasi ujung ke ujung, dan membuat redundansi yang tidak tumpang tindih untuk setiap dependensi.
Terlepas dari apakah Anda menjalankan aplikasi penting misi Anda di wilayah Azure, lokal atau di mana pun, Anda dapat menggunakan wilayah Azure lain sebagai situs failover Anda. Artikel berikut membahas pemulihan bencana dari aplikasi dan perspektif akses ujung depan:
Tantangan menggunakan konektivitas redundan
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, firewall) di jalur tersebut, perutean asimetris dapat memblokir arus lalu lintas. Biasanya, melalui konektivitas privat Anda tidak akan memiliki atau menemukan entitas stateful seperti NAT atau Firewall. Oleh karena itu, perutean asimetris melalui konektivitas privat tidak serta merta memblokir arus lalu lintas.
Namun, jika Anda memuat keseimbangan lalu lintas di jalur paralel geo-redundan, Anda akan mengalami performa jaringan yang tidak konsisten karena perbedaan jalur fisik koneksi paralel. Jadi kita perlu mempertimbangkan performa lalu lintas jaringan baik selama status stabil (status non-kegagalan), dan status kegagalan sebagai bagian dari desain pemulihan bencana kami.
Mengakses redundansi jaringan
Sebagian besar layanan SD-WAN (solusi terkelola atau lainnya) menyediakan Anda konektivitas jaringan melalui berbagai jenis transportasi (misalnya, broadband Internet, MPLS, LTE). Untuk melindungi dari kegagalan jaringan transportasi, pilih konektivitas melalui lebih dari satu jaringan transportasi. Untuk skenario pengguna rumahan, Anda dapat mempertimbangkan untuk menggunakan jaringan seluler sebagai cadangan untuk konektivitas jaringan broadband.
Jika konektivitas jaringan melalui jenis transportasi yang berbeda tidak memungkinkan, maka pilih konektivitas jaringan melalui lebih dari satu penyedia layanan. Jika Anda mendapatkan konektivitas melalui lebih dari satu penyedia layanan, pastikan penyedia layanan memelihara jaringan akses independen yang tidak tumpang tindih.
Pertimbangan konektivitas pengguna jarak jauh
Konektivitas pengguna jarak jauh dibuat menggunakan VPN titik-ke-situs antara perangkat akhir ke jaringan. Setelah kegagalan jaringan, perangkat akhir akan menjatuhkan dan mencoba untuk mengaktifkan kembali terowongan VPN. Oleh karena itu, untuk VPN titik-ke-situs, desain pemulihan bencana Anda harus bertujuan untuk meminimalkan waktu pemulihan setelah kegagalan. Redundansi jaringan berikut akan membantu meminimalkan waktu pemulihan. Bergantung pada seberapa penting koneksinya, Anda dapat memilih beberapa atau semua opsi ini.
- Akses redundansi jaringan (dibahas di atas).
- Mengelola hub virtual redundan untuk penghentian VPN titik-ke-situs. Ketika Anda memiliki beberapa hub virtual dengan gateway titik-ke-situs, VWAN menyediakan profil global yang mencantumkan semua titik akhir titik-ke-situs. Dengan profil global, perangkat akhir Anda dapat terhubung ke hub virtual terdekat yang tersedia yang menawarkan performa jaringan terbaik. Jika semua penyebaran Azure Anda berada di satu wilayah dan perangkat akhir yang terhubung berada di dekat wilayah tersebut, Anda dapat memiliki hub virtual yang berlebihan di dalam wilayah tersebut. Jika penyebaran dan perangkat akhir Anda tersebar di beberapa wilayah, Anda dapat menyebarkan hub virtual dengan gateway titik-ke-situs di setiap wilayah yang Anda pilih. Virtual WAN memiliki manajer lalu lintas bawaan yang memilih hub terbaik untuk konektivitas pengguna jarak jauh secara otomatis.
Diagram berikut menunjukkan konsep mengelola hub virtual yang berlebihan dengan gateway titik-ke-situs masing-masing dalam suatu wilayah.
Dalam diagram di atas, garis hijau pekat menunjukkan koneksi VPN titik-ke-situs utama dan garis kuning putus-putus menunjukkan koneksi cadangan siaga. Profil global titik-ke-situs VWAN memilih koneksi utama dan cadangan berdasarkan performa jaringan. Lihat Mengunduh profil global untuk klien VPN Pengguna untuk informasi lebih lanjut mengenai profil global.
Pertimbangan VPN situs-ke-situs
Mari lihat contoh koneksi VPN situs-ke-situs yang ditunjukkan dalam diagram berikut untuk diskusi kita. Untuk membuat koneksi VPN situs-ke-situs dengan tunnel aktif-aktif ketersediaan tinggi, lihat Tutorial: Membuat koneksi Situs-ke-Situs menggunakan Azure Virtual WAN.
Catatan
Untuk memudahkan pemahaman konsep yang dibahas di bagian ini, kami tidak mengulangi diskusi tentang fitur ketersediaan tinggi gateway VPN situs-ke-situs yang memungkinkan Anda membuat dua tunnel ke dua titik akhir berbeda untuk setiap link VPN yang Anda konfigurasikan. Namun, saat menyebarkan salah satu arsitektur yang disarankan di bagian ini, ingatlah untuk mengonfigurasi dua tunnel untuk setiap link yang Anda buat.
Topologi multi-link
Untuk melindungi dari kegagalan Peralatan Tempat Pelanggan VPN (CPE) di situs cabang, Anda dapat mengonfigurasi link VPN paralel ke gateway VPN dari perangkat CPE paralel di situs cabang. Lebih lanjut untuk melindungi dari kegagalan jaringan penyedia layanan last-mile ke kantor cabang, Anda dapat mengonfigurasi link VPN yang berbeda melalui jaringan penyedia layanan yang berbeda. Diagram berikut menunjukkan beberapa link VPN yang berasal dari dua CPE berbeda dari situs cabang yang berakhir pada gateway VPN yang sama.
Anda dapat mengonfigurasi hingga empat link ke situs cabang dari gateway VPN hub virtual. Saat mengonfigurasi link ke situs cabang, Anda dapat mengidentifikasi penyedia layanan dan kecepatan throughput yang terkait dengan link tersebut. Saat Anda mengonfigurasi link paralel antara situs cabang dan hub virtual, gateway VPN secara default akan memuat lalu lintas keseimbangan di seluruh link paralel. Penyeimbangan beban lalu lintas akan sesuai dengan Equal-Cost Multi-Path (ECMP) pada basis per alur.
Topologi multi-hub multi-link
Topologi multi-link melindungi dari kegagalan perangkat CPE dan kegagalan jaringan penyedia layanan di lokasi cabang lokal. Selain itu, untuk melindungi dari waktu henti apa pun vpn-gateway hub virtuall, topologi multi-link multi-hub akan membantu. Diagram berikut menunjukkan topologi, di mana beberapa hub virtual dikonfigurasi di bawah instans Virtual WAN dalam suatu wilayah:
Dalam topologi di atas, karena latensi intra-wilayah Azure melalui koneksi antara hub tidak signifikan, Anda dapat menggunakan semua koneksi VPN situs-ke-situs antara lokal dan dua hub virtual dalam keadaan aktif-aktif dengan menyebarkan VNet ucapan di seluruh hub. Dalam topologi, secara default, lalu lintas antara lokal dan VNET ucapan akan melintasi langsung melalui hub virtual yang terhubung dengan VNET ucapan selama status stabil dan menggunakan hub virtual lain sebagai cadangan hanya selama keadaan gagal. Lalu lintas akan melintasi hub yang terhubung langsung dalam status stabil, karena rute BGP yang diiklankan oleh hub yang terhubung langsung akan memiliki jalur AS yang lebih pendek dibandingkan dengan hub cadangan.
Topologi multi-hub multi-link akan melindungi dan memberikan kelangsungan bisnis terhadap sebagian besar skenario kegagalan. Namun, jika kegagalan bencana melanda seluruh wilayah Azure, Anda memerlukan 'topologi multi-wilayah multi-link' untuk menahan kegagalan.
Topologi multi-wilayah multi-link
Topologi multi-wilayah multi-link melindungi bahkan dari kegagalan bencana di seluruh wilayah, selain perlindungan yang ditawarkan oleh topologi multi-link multi-hub yang telah kita bahas sebelumnya. Diagram berikut menunjukkan topologi multi-wilayah multi-link. Hub virtual di wilayah yang berbeda dapat dikonfigurasi di bawah instans Virtual WAN yang sama.
Dari sudut pandang rekayasa lalu lintas, Anda perlu mempertimbangkan satu perbedaan substansial antara memiliki hub yang berlebihan dalam suatu wilayah vs memiliki hub cadangan di wilayah yang berbeda. Perbedaannya adalah latensi yang dihasilkan dari jarak fisik antara wilayah primer dan sekunder. Oleh karena itu, Anda mungkin ingin menyebarkan sumber daya layanan status stabil Anda di wilayah terdekat dengan cabang/pengguna akhir Anda dan menggunakan wilayah jauh hanya untuk cadangan.
Jika lokasi cabang lokal Anda tersebar di sekitar dua atau lebih wilayah Azure, topologi multi-wilayah multi-link akan lebih efektif dalam menyebarkan beban dan dalam mendapatkan pengalaman jaringan yang lebih baik selama status stabil. Diagram berikut menunjukkan topologi multi-wilayah multi-link dengan cabang-cabang di wilayah yang berbeda. Dalam skenario seperti itu, topologi juga akan menyediakan Pemulihan Bencana Kelangsungan Bisnis (BCDR) yang efektif.
Pertimbangan ExpressRoute
Pertimbangan pemulihan bencana untuk peering pribadi ExpressRoute dibahas dalam Merancang pemulihan bencana dengan peering pribadi ExpressRoute. Seperti yang dijelaskan dalam artikel, konsep yang dijelaskan dalam artikel itu sama-sama berlaku untuk gateway ExpressRoute yang dibuat dalam hub virtual. Menggunakan hub virtual yang berlebihan dalam wilayah, seperti yang ditunjukkan pada diagram berikut, adalah satu-satunya peningkatan topologi yang disarankan untuk Pertimbangan jaringan lokal kecil hingga menengah.
Dalam diagram di atas, ExpressRoute 2 diakhiri pada gateway ExpressRoute terpisah dalam hub virtual kedua dalam wilayah tersebut.
Langkah berikutnya
Pada artikel ini, kita membahas tentang desain pemulihan bencana Virtual WAN. Artikel berikut membahas pemulihan bencana dari aplikasi dan perspektif akses ujung depan:
Untuk membuat konektivitas titik-ke-situs ke WAN Virtual, lihat Tutorial: Membuat koneksi VPN Pengguna menggunakan Azure Virtual WAN. Untuk membuat konektivitas situs-ke-situs ke Virtual WAN, lihat Tutorial: Membuat koneksi Situs-ke-Situs menggunakan Azure Virtual WAN. Untuk mengaitkan sirkuit ExpressRoute ke Virtual WAN, lihat Tutorial: Membuat asosiasi ExpressRoute menggunakan Azure Virtual WAN.