Share via

Pertahankan alamat IP selama failover

  • Artikel

Azure Site Recovery memungkinkan pemulihan bencana untuk Azure VM dengan mereplikasi komputer virtual ke wilayah Azure lain, mengalihkan operasi jika terjadi gangguan, dan mengembalikan operasi ke wilayah utama ketika keadaan kembali normal.

Selama failover, Anda mungkin ingin mempertahankan alamat IP di wilayah target yang identik dengan wilayah sumber:

  • Secara default, saat Anda mengaktifkan pemulihan bencana untuk Azure VM, Site Recovery membuat sumber daya target berdasarkan pengaturan sumber daya sumber. Untuk Azure VM yang dikonfigurasi dengan alamat IP statis, Site Recovery mencoba menyediakan alamat IP yang sama untuk komputer virtual target, jika tidak digunakan. Untuk penjelasan lengkap tentang bagaimana Site Recovery menangani masalah, tinjau artikel ini.
  • Untuk aplikasi sederhana, konfigurasi default sudah cukup. Untuk aplikasi yang lebih kompleks, Anda mungkin perlu menyediakan sumber daya tambahan untuk memastikan bahwa konektivitas berfungsi seperti yang diharapkan setelah failover.

Artikel ini memberikan beberapa contoh untuk mempertahankan alamat IP dalam skenario contoh yang lebih kompleks. Contoh meliputi:

  • Failover untuk perusahaan dengan semua sumber daya yang berjalan di Azure
  • Failover untuk perusahaan dengan penerapan hibrid, dan sumber daya yang berjalan di lokal dan Azure

Sumber daya di Azure: failover penuh

Perusahaan A memiliki semua aplikasi yang berjalan di Azure.

Sebelum failover

Catatan

Replikasi sekarang dapat dilakukan antara dua wilayah Azure di seluruh dunia. Pelanggan tidak lagi terbatas melakukan replikasi di benua mereka saja.

Berikut arsitektur sebelum failover.

  • Perusahaan A memiliki jaringan dan subnet identik di wilayah Azure sumber dan target.
  • Untuk mengurangi tujuan waktu pemulihan (RTO), perusahaan menggunakan node replika untuk SQL Server Always On, pengontrol domain, dll. Node replika ini berada di VNet yang berbeda di wilayah target, sehingga dapat membangun konektivitas situs-ke-situs VPN antara wilayah sumber dan target. Hal ini tidak mungkin dilakukan jika ruang alamat IP yang sama digunakan dalam sumber dan target.
  • Sebelum failover, arsitektur jaringan adalah sebagai berikut:
    • Wilayah utama adalah Azure Asia Timur
      • Asia Timur memiliki VNet (Source VNet) dengan ruang alamat 10.1.0.0/16.
      • Asia Timur memiliki beban kerja yang terbagi di tiga subnet di VNet:
        • Subnet 1: 10.1.1.0/24
        • Subnet 2: 10.1.2.0/24
        • Subnet 3: 10.1.3.0/24
    • Wilayah sekunder (target) adalah Azure Asia Tenggara
      • Asia Tenggara memiliki VNet pemulihan(Recovery VNet) yang identik dengan Source VNet.
      • Asia Tenggara memiliki VNet tambahan (Azure VNet) dengan ruang alamat 10.2.0.0/16.
      • Azure VNet berisi subnet (Subnet 4) dengan ruang alamat 10.2.4.0/24.
      • Node replika untuk SQL Server Always On, pengontrol domain dan lainnya terletak di Subnet 4.
    • Soure VNet dan Azure VNet tersambung ke koneksi situs ke situs VPN.
    • Recovery VNet tidak terhubung dengan jaringan virtual lainnya.
    • Perusahaan A menetapkan/memverifikasi alamat IP target untuk item direplikasi. IP target sama dengan IP sumber untuk setiap komputer virtual.

Sumber daya di Azure sebelum failover penuh

Setelah failover

Jika gangguan regional sumber terjadi, Perusahaan A dapat mengalihkan operasi semua sumber dayanya ke wilayah target.

  • Dengan alamat IP target yang ada sebelum failover, Perusahaan A dapat mengatur failover dan secara otomatis membuat koneksi setelah failover antara Recovery VNet dan Azure VNet. Akan diilustrasikan dalam grafik berikut.
  • Tergantung persyaratan aplikasi, koneksi antara dua VNet (Recovery VNet dan Azure VNet) di wilayah target dapat ditetapkan sebelumnya, selama (sebagai langkah menengah) atau setelah failover.

    • Perusahaan dapat menggunakan rencana pemulihan untuk menentukan kapan koneksi akan dibangun.

    • Mereka dapat menyambungkan antara VNet menggunakan peering VNet VPN situs-ke-situs.

      • Peering Vnet tidak menggunakan gateway VPN dan memiliki batasan yang berbeda.
      • Harga peering VNet dihitung secara berbeda dengan harga VPN Gateway VNet-ke-VNet. Untuk failover, kami umumnya menyarankan untuk menggunakan metode konektivitas yang sama dengan jaringan sumber, termasuk jenis koneksi, guna meminimalkan insiden jaringan yang tidak dapat diprediksi.

      Sumber daya dalam failover penuh Azure

Sumber daya dalam Azure: failover aplikasi terisolasi

Anda mungkin perlu mengalihkan operasi pada tingkat aplikasi. Misalnya, mengalihkan operasi tingkat aplikasi atau aplikasi tertentu yang terletak di subnet khusus.

  • Dalam skenario ini, meskipun Anda dapat mempertahankan alamat IP, umumnya tidak disarankan karena meningkatkan kemungkinan inkonsistensi konektivitas. Anda juga akan kehilangan konektivitas subnet ke subnet lainnya dalam Azure VNet yang sama.
  • Cara yang lebih baik untuk mengalihkan operasi aplikasi tingkat subnet adalah menggunakan alamat IP target yang berbeda untuk failover (jika Anda memerlukan konektivitas ke subnet lain di sumber VNet), atau mengisolasi setiap aplikasi di VNet khusus dalam wilayah sumber. Dengan pendekatan berikutnya, Anda dapat membangun konektivitas antara jaringan di wilayah sumber, dan meniru perilaku yang sama ketika Anda mengalihkan operasi ke wilayah target.

Dalam contoh ini, Perusahaan A menempatkan aplikasi di wilayah sumber di VNet khusus, dan membangun konektivitas antar VNet tersebut. Dengan desain ini, mereka dapat mengalihkan operasi aplikasi terisolasi, dan mempertahankan alamat IP privat sumber di jaringan target.

Sebelum failover

Sebelum failover, arsitekturnya sebagai berikut:

  • Komputer virtual Aplikasi di wilayah utama Azure Asia Timur:

    • Aplikasi1 Komputer virtual terletak di VNet Source VNet 1: 10.1.0.0/16.
    • App2 Komputer virtual terletak di VNet Source VNet 2: 10.2.0.0/16.
    • Source VNet 1 memiliki dua subnet.
    • Source VNet 2 memiliki dua subnet.

  • Wilayah sekunder (target) adalah Azure Asia Tenggara - Asia Tenggara memiliki VNets pemulihan (Recovery VNet 1 dan Recovery VNet 2) yang identik dengan Source VNet 1 dan Source VNet 2. - Recovery VNet 1 dan Recovery VNet 2 masing-masing memiliki dua subnet yang cocok dengan subnet Source VNet 1 dan Source VNet 2 - Asia Tenggara memiliki VNet yang identik (Azure VNet) dengan ruang alamat 10.3.0.0/16. - Azure VNet berisi satu subnet (Subnet 4) dengan ruang alamat 10.3.4.0/24. - Node replika untuk SQL Server Always On, pengendali domain, dan lainnya terletak di Subnet 4.

  • Ada sejumlah koneksi VPN situs-ke-situs:

    • Source VNet 1 dan Azure VNet
    • Source VNet 2 dan Azure VNet
    • Source VNet 1 dan Source VNet 2 tersambung dengan situs-ke-situs VPN

  • Recovery VNet 1 dan Recovery VNet 2 tidak tersambung ke VNet apa pun lainnya.

  • Perusahaan A mengonfigurasi gateway VPN Recovery VNet 1 dan Recovery VNet 2, untuk mengurangi RTO.

  • Recovery VNet1 dan Recovery VNet2 tidak tersambung dengan jaringan virtual lain apa pun.

  • Untuk mengurangi objektif waktu pemulihan (RTO), gateway VPN dikonfigurasi pada Recovery VNet1 dan Recovery VNet2 sebelum failover.

    Sumber daya dalam Aplikasi sebelum failover aplikasi

Setelah failover

Jika terjadi gangguan atau masalah yang memengaruhi satu aplikasi (dalam **Source VNet 2 dalam contoh kami), Perusahaan A dapat memulihkan aplikasi yang terpengaruh sebagai berikut:

  • Putus sambungan koneksi VPN antara Source VNet1 dan Source VNet2, dan antara Source VNet2 dan Azure VNet .
  • Bangun koneksi VPN antara Source VNet1 dan Recovery VNet2, dan antara Recovery VNet2 dan Azure VNet.
  • Alihkan operasi komputer virtual dalam Source VNet2 ke Recovery VNet2.

Sumber daya dalam failover aplikasi Azure

  • Contoh ini dapat diperluas untuk menyertakan lebih banyak aplikasi dan koneksi jaringan. Sebaiknya mengikuti model koneksi seperti itu, sejauh mungkin, ketika gagal dari sumber ke target.
  • VPN Gateway menggunakan alamat IP publik dan gateway hop untuk membangun koneksi. Jika Anda tidak menggunakan alamat IP publik, atau Anda ingin menghindari hop berlebih, Anda dapat menggunakan peering Azure VNet untuk melakukan peering jaringan virtual di seluruh wilayah Azure yang didukung.

Sumber daya hibrid: failover penuh

Dalam skenario ini, Perusahaan B menjalankan bisnis hibrid, dengan bagian dari infrastruktur aplikasi yang berjalan di Azure, dan sisanya berjalan di lokal.

Sebelum failover

Inilah tampilan arsitektur jaringan sebelum failover.

  • Application VM dihosting di Azure Asia Timur.
  • Asia Timur memiliki VNet (Source VNet) dengan ruang alamat 10.1.0.0/16.
    • Asia Timur memiliki beban kerja yang dipisah di seluruh tiga subnet Source VNet:
      • Subnet 1: 10.1.1.0/24
      • Subnet 2: 10.1.2.0/24
      • Subnet 3: 10.1.3.0/24, menggunakan jaringan virtual Azure dengan ruang alamat 10.1.0.0/16. Jaringan virtual ini bernama Source VNet
  • Wilayah sekunder (target) adalah Azure Asia Tenggara:
    • Asia Tenggara memiliki VNet pemulihan (Recovery VNet) identik dengan Source VNet.
  • Komputer di Asia Timur tersambung ke pusat data lokal dengan Azure ExpressRoute atau VPN situs-ke-situs.
  • Untuk mengurangi RTO, Perusahaan B menyediakan gateway pada Recovery VNet di Azure Asia Tenggara sebelum failover.
  • Perusahaan B menetapkan/memverifikasi alamat IP target untuk item yang direplikasi. Alamat IP target sama dengan alamat IP sumber untuk setiap komputer virtual.

Konektivitas lokal ke Azure sebelum failover

Setelah failover

Jika gangguan regional sumber terjadi, Perusahaan B dapat mengalihkan operasi semua sumber dayanya ke wilayah target.

  • Dengan alamat IP target yang sudah ada sebelum failover, Perusahaan B dapat mengatur failover dan secara otomatis membangun koneksi setelah failover antara Recovery VNet dan Azure VNet.
  • Tergantung persyaratan aplikasi, koneksi antara dua VNet (Recovery VNet dan Azure VNet) di wilayah target dapat ditetapkan sebelumnya, selama (sebagai langkah menengah) atau setelah failover. Perusahaan dapat menggunakan rencana pemulihan untuk menentukan kapan koneksi akan dibangun.
  • Koneksi asli antara Azure Asia Timur dan pusat data lokal harus terputus sebelum membangun koneksi antara Azure Asia Tenggara dan pusat data lokal.
  • Perutean lokal dikonfigurasi ulang untuk menunjuk ke wilayah target dan gateway pasca failover.

Konektivitas lokal ke Azure setelah failover

Sumber daya hibrid: failover aplikasi terisolasi

Perusahaan B tidak dapat mengalihkan operasi aplikasi yang terisolasi di tingkat subnet. Ini karena ruang alamat pada sumber dan VNets pemulihan yang sama, dan sumber asli ke koneksi lokal aktif.

  • Untuk ketahanan aplikasi, Perusahaan B harus menempatkan setiap aplikasi di Azure VNet khususnya masing-masing.
  • Dengan setiap aplikasi di VNet terpisah, Perusahaan B dapat mengalihkan operasi aplikasi yang terisolasi, dan merutekan koneksi sumber ke wilayah target.

Langkah berikutnya

Pelajari tentang rencana pemulihan.