Aplikasi tingkat-N multi-wilayah

Azure Monitor
Azure Traffic Manager
Azure SQL Database
Azure Virtual Machines

Arsitektur referensi ini menunjukkan serangkaian praktik yang telah terbukti untuk menjalankan aplikasi tingkat-N di beberapa wilayah Azure, untuk mencapai ketersediaan dan infrastruktur pemulihan bencana yang kuat.

Arsitektur

Highly available network architecture for Azure N-tier applications

Unduh file Visio arsitektur ini.

Alur kerja

  • Wilayah primer dan sekunder. Gunakan dua wilayah untuk mencapai ketersediaan yang lebih tinggi. Yang satu adalah wilayah primer. Wilayah lainnya adalah untuk failover.

  • Azure Traffic Manager. Traffic Manager merutekan permintaan masuk ke salah satu wilayah. Selama operasi normal, Traffic Manager mengarahkan permintaan ke wilayah utama. Jika wilayah tersebut menjadi tidak tersedia, Traffic Manager gagal melakukan failover ke wilayah sekunder. Untuk informasi selengkapnya, lihat bagian Konfigurasi Traffic Manager.

  • Grup sumber daya. Buat grup sumber daya terpisah untuk wilayah utama, wilayah sekunder, dan untuk Traffic Manager. Metode ini memberi Anda fleksibilitas untuk mengelola setiap wilayah sebagai satu koleksi sumber daya. Misalnya, Anda dapat menyebarkan kembali satu wilayah, tanpa menghapus wilayah satunya. Tautkan grup sumber daya, sehingga Anda dapat menjalankan kueri untuk mencantumkan semua sumber daya untuk aplikasi.

  • Jaringan virtual. Buat jaringan virtual terpisah untuk setiap wilayah. Pastikan ruang alamat tidak tumpang tindih.

  • Grup Ketersediaan Always On SQL Server. Jika Anda menggunakan SQL Server, kami merekomendasikan Grup Ketersediaan AlwaysOn SQL untuk ketersediaan tinggi. Buat grup ketersediaan tunggal yang menyertakan instans SQL Server di kedua wilayah.

    Catatan

    Pertimbangkan juga Azure SQL Database, yang menyediakan database hubungan sebagai layanan cloud. Dengan SQL Database, Anda tidak perlu mengonfigurasi grup ketersediaan atau mengelola failover.

  • Peering jaringan virtual. Peer dua jaringan untuk memungkinkan replikasi data dari wilayah utama ke wilayah sekunder. Untuk informasi selengkapnya, lihat Peering jaringan virtual.

Komponen

  • Set ketersediaan memastikan bahwa VM yang Anda sebarkan di Azure didistribusikan di beberapa simpul perangkat keras yang terisolasi dalam kluster. Jika kegagalan perangkat keras atau perangkat lunak terjadi dalam Azure, hanya subset VM Anda yang terpengaruh, dan seluruh solusi Anda tetap tersedia dan beroperasi.
  • Zona ketersediaan melindungi aplikasi dan data Anda dari kegagalan pusat data. Zona ketersediaan adalah lokasi fisik terpisah dalam wilayah Azure. Setiap Zona Ketersediaan terdiri dari satu atau beberapa pusat data yang dilengkapi dengan daya, pendinginan, dan jaringan yang independen.
  • Azure Traffic Manager adalah penyeimbang beban lalu lintas berbasis DNS yang mendistribusikan lalu lintas secara optimal. Ini menyediakan layanan di seluruh wilayah Azure global, dengan ketersediaan dan responsivitas tinggi.
  • Azure Load Balancer mendistribusikan lalu lintas masuk, sesuai dengan aturan yang ditetapkan dan pemeriksaan kesehatan. Load balancer memberikan latensi rendah dan throughput tinggi, meningkatkan hingga jutaan aliran untuk semua aplikasi TCP dan UDP. Penyeimbang beban publik digunakan dalam skenario ini, untuk mendistribusikan lalu lintas klien yang masuk ke tingkat web. Penyeimbang beban internal digunakan dalam skenario ini, untuk mendistribusikan lalu lintas dari tingkat bisnis ke kluster SQL Server back-end.
  • Azure Bastion menyediakan konektivitas RDP dan SSH yang aman ke semua VM, di jaringan virtual tempat VM disediakan. Gunakan Azure Bastion untuk melindungi mesin virtual Anda agar tidak mengekspos port RDP/SSH ke dunia luar, sambil tetap memberikan akses aman menggunakan RDP/SSH.

Rekomendasi

Arsitektur multi-wilayah dapat memberikan ketersediaan yang lebih tinggi daripada menyebarkan ke satu wilayah. Jika pemadaman wilayah memengaruhi wilayah utama, Anda dapat menggunakan Traffic Manager untuk melakukan failover ke wilayah sekunder. Arsitektur ini juga dapat membantu jika sub-sistem individu dari aplikasi gagal.

Ada beberapa pendekatan umum untuk mencapai ketersediaan tinggi di seluruh wilayah:

  • Aktif/pasif dengan siaga panas. Lalu lintas menuju satu wilayah, sementara yang lain menunggu standby panas. Siaga panas berarti VM di wilayah sekunder dialokasikan dan selalu berjalan.
  • Aktif/pasif dengan siaga dingin. Lalu lintas pergi ke satu wilayah, sementara yang lain menunggu standby dingin. Siaga dingin berarti VM di wilayah sekunder tidak dialokasikan sampai diperlukan untuk failover. Pendekatan ini membutuhkan biaya lebih sedikit untuk dijalankan, tetapi umumnya akan memakan waktu lebih lama untuk online saat terjadi kegagalan.
  • Aktif/aktif. Kedua wilayah aktif, dan permintaan beban seimbang di antara mereka. Jika satu wilayah menjadi tidak tersedia, wilayah tersebut diambil dari rotasi.

Arsitektur referensi ini berfokus pada aktif/pasif dengan siaga panas, menggunakan Traffic Manager untuk failover. Anda dapat menyebarkan beberapa VM untuk siaga panas dan kemudian meluaskan skala sesuai kebutuhan.

Pasangan regional

Setiap wilayah Azure dipasangkan dengan wilayah lain dalam geografi yang sama. Secara umum, pilih wilayah dari pasangan wilayah yang sama (misalnya, US Timur 2 dan US Tengah). Manfaat melakukannya meliputi:

  • Jika ada pemadaman yang luas, pemulihan setidaknya satu wilayah dari setiap pasangan diprioritaskan.
  • Pembaruan sistem Azure yang direncanakan diluncurkan ke wilayah yang dipasangkan secara berurutan, untuk meminimalkan kemungkinan waktu henti.
  • Pasangan berada dalam geografi yang sama, untuk memenuhi persyaratan residensi data.

Namun, pastikan kedua wilayah mendukung semua layanan Azure yang diperlukan untuk aplikasi Anda (lihat Layanan berdasarkan wilayah). Untuk informasi selengkapnya tentang pasangan regional, lihat Kelangsungan bisnis dan pemulihan bencana (BCDR): Azure Paired Regions.

Konfigurasi Traffic Manager

Pertimbangkan poin-poin berikut saat mengonfigurasi Traffic Manager:

  • Perutean. Traffic Manager mendukung beberapa algoritma perutean. Untuk skenario yang dijelaskan dalam artikel ini, gunakan perutean prioritas (sebelumnya disebut perutean failover). Dengan pengaturan ini, Traffic Manager mengirimkan semua permintaan ke wilayah utama, kecuali jika wilayah utama menjadi tidak terjangkau. Pada saat itu, Traffic Manager akan secara otomatis melakukan failover ke wilayah sekunder. Lihat Mengonfigurasi metode perutean Failover.
  • Pemeriksaan kesehatan. Traffic Manager menggunakan pemeriksaan HTTP (atau HTTPS) untuk memantau ketersediaan setiap wilayah. Pemeriksaan akan mengecek respons HTTP 200 untuk jalur URL yang ditentukan. Sebagai praktik terbaik, buat titik akhir yang melaporkan kesehatan aplikasi secara keseluruhan, dan gunakan titik akhir ini untuk pemeriksaan kesehatan. Jika tidak, pemeriksaan mungkin melaporkan titik akhir yang sehat ketika bagian-bagian penting dari aplikasi benar-benar gagal. Untuk informasi selengkapnya, lihat Pola Pemantauan Titik Akhir Kesehatan.

Ketika Traffic Manager gagal, ada periode waktu ketika klien tidak dapat menjangkau aplikasi. Durasi dipengaruhi oleh faktor-faktor berikut:

  • Pemeriksaan kesehatan harus mendeteksi bahwa wilayah utama menjadi tidak terjangkau.
  • Server DNS harus memperbarui catatan DNS yang di-cache untuk alamat IP, yang bergantung pada DNS time-to-live (TTL). TTL default adalah 300 detik (5 menit), tetapi Anda dapat mengonfigurasi nilai ini saat membuat profil Traffic Manager.

Untuk detailnya, lihat Tentang Pemantauan Traffic Manager.

Jika Traffic Manager gagal, sebaiknya lakukan failover manual alih-alih mengimplementasikan failback otomatis. Jika tidak, Anda dapat membuat situasi di mana aplikasi bolak-balik antar-wilayah. Verifikasi bahwa semua subsistem aplikasi sehat sebelum melakukan failback.

Traffic Manager secara otomatis gagal kembali secara default. Untuk mencegah masalah ini, turunkan prioritas wilayah utama secara manual setelah peristiwa failover. Misalnya, anggap saja wilayah utama adalah prioritas 1 dan wilayah sekunder adalah prioritas 2. Setelah failover, atur wilayah utama ke prioritas 3, untuk mencegah failback otomatis. Saat Anda siap untuk beralih kembali, perbarui prioritas ke 1.

Perintah Azure CLI berikut memperbarui prioritas:

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type azureEndpoints --priority 3

Pendekatan lain adalah menonaktifkan titik akhir untuk sementara waktu hingga Anda siap untuk melakukan failback:

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type azureEndpoints --endpoint-status Disabled

Bergantung pada penyebab failover, Anda mungkin perlu menyebarkan ulang sumber daya dalam suatu wilayah. Sebelum melakukan failback, lakukan uji kesiapan operasional. Pengujian tersebut harus memverifikasi hal-hal seperti:

  • VM dikonfigurasi dengan benar. (Semua perangkat lunak yang diperlukan dipasang, IIS berjalan, dan sebagainya.)
  • Subsistem aplikasi sehat.
  • Pengujian fungsional. (Misalnya, tingkat database dapat dijangkau dari tingkat web.)

Mengonfigurasi Grup Ketersediaan AlwaysOn SQL Server

Sebelum Windows Server 2016, Grup Ketersediaan AlwaysOn SQL Server memerlukan pengendali domain, dan semua node dalam grup ketersediaan harus berada di domain Active Directory (AD) yang sama.

Untuk mengonfigurasi grup ketersediaan:

  • Minimal, tempatkan dua pengendali domain di setiap wilayah.

  • Beri setiap pengendali domain alamat IP statis.

  • Peer dua jaringan untuk mengaktifkan komunikasi antar keduanya.

  • Untuk setiap jaringan, tambahkan alamat IP pengendali domain (dari kedua wilayah) ke daftar server DNS. Anda dapat menggunakan perintah CLI berikut. Untuk informasi selengkapnya, lihat Mengubah server DNS.

    az network vnet update --resource-group <resource-group> --name <vnet-name> --dns-servers "10.0.0.4,10.0.0.6,172.16.0.4,172.16.0.6"
    
  • Buat kluster Windows Server Failover Clustering (WSFC) yang mencakup instans SQL Server di kedua wilayah.

  • Buat Grup Ketersediaan AlwaysOn SQL Server yang menyertakan instans SQL Server di wilayah primer dan sekunder. Lihat Memperluas Grup Ketersediaan AlwaysOn SQL Server ke Pusat Data Azure Jarak Jauh (PowerShell) untuk langkah-langkahnya.

    • Letakkan replika utama di wilayah utama.

    • Letakkan satu atau beberapa replika sekunder di wilayah utama. Konfigurasikan replika ini untuk menggunakan penerapan sinkron dengan failover otomatis.

    • Letakkan satu atau beberapa replika sekunder di wilayah sekunder. Konfigurasikan replika ini untuk menggunakan penerapan asinkron , karena alasan performa. (Jika tidak, semua transaksi T-SQL harus menunggu dalam perjalanan pulang pergi melalui jaringan ke wilayah sekunder.)

      Catatan

      Replika penerapan asinkron tidak mendukung failover otomatis.

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.

Ketersediaan

Dengan aplikasi tingkat-N yang kompleks, Anda mungkin tidak perlu mereplikasi seluruh aplikasi di wilayah sekunder. Sebagai gantinya, Anda mungkin hanya mereplikasi subsistem penting yang diperlukan untuk mendukung kelangsungan bisnis.

Traffic Manager adalah kemungkinan titik kegagalan dalam sistem. Jika layanan Traffic Manager gagal, klien tidak dapat mengakses aplikasi Anda selama waktu henti. Tinjau SLA Traffic Manager, dan tentukan apakah hanya menggunakan Traffic Manager akan memenuhi persyaratan bisnis Anda untuk ketersediaan tinggi. Jika tidak, pertimbangkan untuk menambahkan solusi manajemen lalu lintas lain sebagai failback. Jika layanan Azure Traffic Manager gagal, ubah data CNAME Anda di DNS untuk mengarah ke layanan manajemen lalu lintas lainnya. (Langkah ini harus dilakukan secara manual, dan aplikasi Anda tidak akan tersedia hingga perubahan DNS disebarkan.)

Untuk kluster SQL Server, ada dua skenario failover yang perlu dipertimbangkan:

  • Semua replika database SQL Server di wilayah utama gagal. Misalnya, kegagalan ini dapat terjadi selama pemadaman regional. Dalam hal ini, Anda harus secara manual melakukan failover grup ketersediaan, meskipun Traffic Manager secara otomatis melakukan failover di front-end. Ikuti langkah-langkah di Melakukan Failover Manual Paksa dari Grup Ketersediaan SQL Server, yang menjelaskan cara melakukan failover paksa menggunakan SQL Server Management Studio, T-SQL, atau PowerShell di SQL Server 2016.

    Peringatan

    Dengan failover paksa, ada risiko kehilangan data. Setelah wilayah utama kembali online, ambil snapshot database dan gunakan tablediff untuk menemukan perbedaannya.

  • Traffic Manager melakukan failover ke wilayah sekunder, tetapi replika database SQL Server utama masih tersedia. Misalnya, tingkat front-end mungkin gagal, tanpa memengaruhi VM SQL Server. Dalam kasus ini, lalu lintas Internet dirutekan ke wilayah sekunder, dan wilayah tersebut masih dapat tersambung ke replika utama. Namun, akan ada peningkatan latensi, karena koneksi SQL Server melintasi wilayah. Dalam situasi ini, Anda harus melakukan failover manual sebagai berikut:

    1. Alihkan sementara replika database SQL Server di wilayah sekunder ke penerapan sinkron. Langkah ini memastikan tidak akan ada kehilangan data selama failover.
    2. Failover ke replika tersebut.
    3. Saat Anda melakukan failback ke wilayah utama, pulihkan pengaturan penerapan asinkron.

Keterkelolaan

Saat Anda memperbarui penyebaran, perbarui satu wilayah pada satu waktu untuk mengurangi kemungkinan kegagalan global dari konfigurasi yang salah atau kesalahan dalam aplikasi.

Uji ketahanan sistem terhadap kegagalan. Berikut adalah beberapa skenario kegagalan umum untuk diuji:

  • Matikan instans VM.
  • Sumber daya tekanan seperti CPU dan memori.
  • Putuskan/tunda jaringan.
  • Proses crash.
  • Sertifikat kedaluwarsa.
  • Simulasikan kesalahan perangkat keras.
  • Matikan layanan DNS pada pengendali domain.

Ukur waktu pemulihan dan verifikasi bahwa waktu tersebut memenuhi persyaratan bisnis Anda. Uji kombinasi mode kegagalan juga.

Pengoptimalan biaya

Optimalisasi biaya adalah tentang mencari cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Gambaran umum pilar pengoptimalan biaya.

Gunakan Kalkulator Harga Azure untuk memperkirakan biaya. Berikut beberapa pertimbangan lainnya.

Virtual Machine Scale Sets

Virtual Machine Scale Sets tersedia pada semua ukuran VM Windows. Anda hanya dikenakan biaya untuk Azure VM yang Anda sebarkan dan sumber daya infrastruktur dasar tambahan yang digunakan, seperti penyimpanan dan jaringan. Tidak ada biaya bertambah bertahap untuk layanan Virtual Machine Scale Sets.

Untuk opsi harga VM tunggal, lihat Harga VM Windows.

Server SQL

Jika memilih Azure SQL DBaas, Anda dapat menghemat biaya karena tidak perlu mengonfigurasikan Grup Ketersediaan AlwaysOn dan mesin pengendali domain. Ada beberapa opsi penyebaran mulai dari database tunggal hingga instans terkelola, atau kumpulan elastis. Untuk informasi selengkapnya, lihat Harga Azure SQL.

Untuk opsi harga VM SQL server, lihat Harga SQL VM.

Penyeimbang muatan

Anda hanya dikenakan biaya untuk jumlah aturan penyeimbangan beban dan keluar yang dikonfigurasi. Aturan NAT masuk gratis. Tidak ada biaya per jam untuk Standard Load Balancer jika tidak ada aturan yang dikonfigurasi.

Harga Traffic Manager

Penagihan Traffic Manager didasarkan pada jumlah kueri DNS yang diterima, dengan diskon untuk layanan yang menerima lebih dari 1 miliar kueri setiap bulannya. Anda juga dikenakan biaya untuk setiap titik akhir yang dipantau.

Untuk informasi selengkapnya, lihat bagian biaya di Microsoft Azure Well-Architected Framework.

Harga VNET-Peering

Penyebaran ketersediaan tinggi yang menggunakan beberapa Wilayah Azure akan menggunakan VNET-Peering. Ada biaya yang berbeda untuk VNET-Peering dalam wilayah yang sama dan untuk Global VNET-Peering.

Untuk informasi selengkapnya, lihat Harga Virtual Network.

DevOps

Gunakan satu template Azure Resource Manager untuk menyediakan sumber daya Azure dan dependensinya. Gunakan template yang sama untuk menyebarkan sumber daya ke wilayah primer dan sekunder. Sertakan semua sumber daya dalam jaringan virtual yang sama sehingga terisolasi dalam beban kerja dasar yang sama. Dengan menyertakan semua sumber daya, Anda mempermudah untuk mengaitkan sumber daya khusus beban kerja ke tim DevOps, sehingga tim dapat mengelola semua aspek sumber daya tersebut secara independen. Isolasi ini memungkinkan Tim dan Layanan DevOps untuk melakukan integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD).

Selain itu, Anda dapat menggunakan template Azure Resource Manager yang berbeda dan mengintegrasikannya dengan Azure DevOps Services untuk menyediakan lingkungan yang berbeda dalam hitungan menit, misalnya untuk mereplikasi produksi seperti skenario atau memuat lingkungan pengujian hanya jika diperlukan untuk menghemat biaya.

Pertimbangkan untuk menggunakan Azure Monitor untuk Menganalisis dan mengoptimalkan performa infrastruktur Anda, Memantau dan mendiagnosis masalah jaringan tanpa masuk ke mesin virtual Anda. Application Insights sebenarnya adalah salah satu komponen Azure Monitor, yang memberi Anda metrik dan log yang kaya untuk memverifikasi status lanskap Azure lengkap Anda. Azure Monitor akan membantu Anda mengikuti status infrastruktur Anda.

Pastikan tidak hanya untuk memantau elemen komputasi Anda yang mendukung kode aplikasi, tetapi juga platform data Anda, khususnya database, karena performa rendah dari tingkat data aplikasi dapat berdampak serius.

Untuk menguji lingkungan Azure tempat aplikasi berjalan, versi aplikasi harus dikontrol dan disebarkan melalui mekanisme yang sama dengan kode aplikasi, lalu aplikasi dapat diuji dan divalidasi menggunakan paradigma pengujian DevOps juga.

Untuk informasi selengkapnya, lihat bagian Keunggulan operasional di Microsoft Azure Well-Architected Framework.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

Arsitektur berikut menggunakan beberapa teknologi yang sama: