Skenario contoh ini berlaku untuk industri apa pun yang perlu menyebarkan aplikasi multi-tingkat tangguh yang dibuat untuk ketersediaan tinggi dan pemulihan bencana. Dalam skenario ini, aplikasi terdiri dari tiga lapisan.
- Tingkat web: Lapisan atas termasuk antarmuka pengguna. Lapisan ini mengurai interaksi pengguna dan meneruskan tindakan ke lapisan berikutnya untuk diproses.
- Tingkat bisnis: Memproses interaksi pengguna dan membuat keputusan logis tentang langkah selanjutnya. Lapisan ini menghubungkan tingkat web dan tingkat data.
- Tingkat data: Menyimpan data aplikasi. Baik database, penyimpanan objek, atau penyimpanan file biasanya digunakan.
Skenario aplikasi umum mencakup semua aplikasi misi penting yang berjalan di Windows atau Linux. Ini bisa berupa aplikasi siap pakai seperti SAP dan SharePoint atau aplikasi lini bisnis kustom.
Kemungkinan kasus penggunaan
Kasus penggunaan yang relevan lainnya meliputi:
- Menyebarkan aplikasi yang sangat tangguh seperti SAP dan SharePoint
- Merancang kelangsungan bisnis dan rencana pemulihan bencana untuk aplikasi lini bisnis
- Mengonfigurasi pemulihan bencana dan melakukan latihan terkait untuk tujuan kepatuhan
Arsitektur
Unduh file Visio arsitektur ini.
Alur kerja
- Distribusikan VM di setiap tingkat di dua zona ketersediaan di wilayah yang mendukung zona. Di region lain, sebarkan VM di setiap tingkat dalam satu set ketersediaan.
- Tingkat database dapat dikonfigurasi untuk menggunakan Grup Ketersediaan AlwaysOn. Dengan konfigurasi SQL Server ini, satu replika baca/tulis utama dalam grup ketersediaan dikonfigurasi dengan hingga delapan replika baca-saja sekunder. Jika masalah terjadi pada replika utama, grup ketersediaan gagal melalui aktivitas baca/tulis utama ke salah satu replika sekunder, memungkinkan aplikasi untuk tetap tersedia. Untuk informasi selengkapnya, lihat Ringkasan Grup Ketersediaan AlwaysOn untuk SQL Server.
- Untuk skenario pemulihan bencana, Anda dapat mengonfigurasi replikasi asli asinkron Grup Ketersediaan AlwaysOn SQL ke wilayah target yang digunakan untuk pemulihan bencana. Anda juga dapat mengonfigurasi replikasi Azure Site Recovery ke wilayah target jika tingkat perubahan data berada dalam batas yang didukung dari Azure Site Recovery.
- Pengguna mengakses tingkat web ASP.NET front-end melalui titik akhir manajer lalu lintas.
- Manajer lalu lintas mengalihkan lalu lintas ke titik akhir IP publik utama di wilayah sumber utama.
- IP publik mengalihkan panggilan ke salah satu instans VM tingkat web melalui load balancer publik. Semua instans VM tingkat web berada dalam satu subnet.
- Dari VM tingkat web, setiap panggilan dirutekan ke salah satu instans VM di tingkat bisnis melalui load balancer internal untuk diproses. Semua VM tingkat bisnis berada di subnet terpisah.
- Operasi diproses di tingkat bisnis dan aplikasi ASP.NET tersambung ke kluster Microsoft SQL Server di tingkat back-end melalui load balancer internal Azure. Instans SQL Server back-end ini berada dalam subnet terpisah.
- Titik akhir sekunder pengelola lalu lintas dikonfigurasi sebagai IP publik di wilayah target yang digunakan untuk pemulihan bencana.
- Jika terjadi gangguan wilayah utama, Anda menjalankan failover Azure Site Recovery dan aplikasi menjadi aktif di wilayah target.
- Titik akhir manajer lalu lintas secara otomatis mengarahkan lalu lintas klien ke IP publik di wilayah target.
Komponen
- Set ketersediaan memastikan bahwa VM yang Anda sebarkan di Azure didistribusikan di beberapa simpul perangkat keras yang terisolasi dalam kluster. Jika terjadi kegagalan perangkat keras atau perangkat lunak dalam Azure, hanya sebagian dari 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 Site Recovery memungkinkan Anda mereplikasi VM ke wilayah Azure lain untuk kelangsungan bisnis dan kebutuhan pemulihan bencana. Anda dapat melakukan latihan pemulihan bencana secara berkala untuk memastikan Anda memenuhi kebutuhan kepatuhan. VM akan direplikasi dengan pengaturan yang ditentukan ke wilayah yang dipilih sehingga Anda dapat memulihkan aplikasi Anda jika terjadi pemadaman di wilayah sumber.
- Azure Traffic Manager adalah load balancer lalu lintas berbasis DNS yang mendistribusikan lalu lintas secara optimal ke layanan di seluruh wilayah Azure global sambil memberikan ketersediaan dan daya tanggap yang tinggi.
- Azure Load Balancer mendistribusikan lalu lintas masuk sesuai dengan aturan dan pemeriksaan kesehatan yang ditentukan. Load balancer memberikan latensi rendah dan throughput tinggi, meningkatkan hingga jutaan aliran untuk semua aplikasi TCP dan UDP. Load balancer publik digunakan dalam skenario ini untuk mendistribusikan lalu lintas klien masuk ke tingkat web. Load balancer internal digunakan dalam skenario ini untuk mendistribusikan lalu lintas dari tingkat bisnis ke kluster SQL Server back-end.
Alternatif
- Windows dapat digantikan oleh sistem operasi lain karena tidak ada infrastruktur yang bergantung pada sistem operasi.
- SQL Server untuk Linux dapat menggantikan penyimpanan data back-end.
- Database dapat diganti dengan aplikasi database standar apa pun yang tersedia.
Detail skenario
Skenario ini menunjukkan aplikasi multi-tingkat yang menggunakan ASP.NET dan Microsoft SQL Server. Di wilayah Azure yang mendukung zona ketersediaan, Anda dapat menerapkan mesin virtual (VM) di wilayah sumber di seluruh zona ketersediaan dan mereplikasi VM ke wilayah target yang digunakan untuk pemulihan bencana. Di wilayah Azure yang tidak mendukung zona ketersediaan, Anda dapat menyebarkan VM Anda dalam set ketersediaan dan mereplikasi VM ke wilayah target.
Untuk merutekan lalu lintas antar wilayah, Anda memerlukan load balancer global. Ada dua penawaran utama Azure:
- Azure Front Door
- Azure Traffic Manager
Saat memilih load balancer, pertimbangkan kebutuhan Anda dan rangkaian fitur dari kedua penawaran. Seberapa cepat Anda ingin gagal? Bisakah Anda mengambil overhead manajemen TLS? Apakah ada batasan biaya organisasi?
Front Door memiliki kemampuan Lapisan 7: SSL offload, perutean berbasis jalur, failover cepat, penembolokan, dan lainnya untuk meningkatkan performa dan ketersediaan tinggi aplikasi Anda. Anda mungkin mengalami waktu perjalanan paket yang lebih cepat karena infrastruktur di-onboarding di jaringan Azure lebih cepat.
Karena Front Door menambahkan lompatan baru, ada operasi keamanan tambahan. Jika arsitektur mematuhi persyaratan peraturan, mungkin ada pembatasan tentang titik penghentian TLS lalu lintas tambahan. Rangkaian cipher TLS yang dipilih oleh Front Door harus memenuhi standar keamanan organisasi Anda. Selain itu, Front Door mengharapkan layanan backend menggunakan sertifikat yang digunakan oleh Microsoft.
Pertimbangan lainnya adalah biaya. Arsitektur harus memanfaatkan set fitur yang luas (bukan hanya failover) untuk membenarkan biaya tambahan.
Traffic Manager adalah layanan load-balancing berbasis DNS. Ini menyeimbangkan dan gagal hanya pada tingkat DNS. Oleh karena itu, layanan ini tidak dapat melakukan failover secepat Front Door, karena tantangan umum di sekitar penembolokan DNS dan sistem yang tidak mematuhi TTL DNS.
Anda dapat menggabungkan kedua load balancer, jika diperlukan. Misalnya, Anda menginginkan failover berbasis DNS tetapi Anda ingin menambahkan pengalaman POP di depan infrastruktur yang dikelola lalu lintas tersebut.
Arsitektur ini menggunakan Traffic Manager karena ringan. Waktu failover cukup untuk tujuan ilustrasi.
Pertimbangan
Skalabilitas
Anda dapat menambahkan atau menghapus VM di setiap tingkat berdasarkan persyaratan penskalaan Anda. Karena skenario ini menggunakan load balancer, Anda dapat menambahkan lebih banyak VM ke tingkat tanpa memengaruhi waktu aktif aplikasi.
Untuk topik skalabilitas lainnya, lihat daftar periksa efisiensi performa di Azure Architecture Center.
Keamanan
Semua lalu lintas jaringan virtual ke tingkat aplikasi front-end dilindungi oleh kelompok keamanan jaringan. Aturan membatasi alur lalu lintas sehingga hanya instans VM tingkat aplikasi front-end yang dapat mengakses tingkat database back-end. Tidak ada lalu lintas internet keluar yang diizinkan dari tingkat bisnis atau tingkat database. Untuk mengurangi jejak serangan, tidak ada port manajemen jarak jauh langsung yang terbuka. Untuk informasi selengkapnya, lihat Kelompok keamanan jaringan Azure.
Untuk panduan umum tentang mendesain skenario aman, lihat Dokumentasi Keamanan Azure.
Harga
Mengonfigurasi pemulihan bencana untuk Azure VM menggunakan Azure Site Recovery akan dikenakan biaya berikut secara berkelanjutan.
- Biaya lisensi Azure Site Recovery per VM.
- Biaya egress jaringan untuk mereplikasi perubahan data dari disk VM sumber ke wilayah Azure lain. Azure Site Recovery menggunakan kompresi bawaan untuk mengurangi kebutuhan transfer data sekitar 50%.
- Biaya penyimpanan di situs pemulihan. Ini biasanya sama dengan penyimpanan wilayah sumber ditambah penyimpanan tambahan apa pun yang diperlukan untuk mempertahankan titik pemulihan sebagai snapshot untuk pemulihan.
Kami telah menyediakan kalkulator biaya sampel untuk mengonfigurasi pemulihan bencana untuk aplikasi tiga tingkat menggunakan enam komputer virtual. Semua layanan telah dikonfigurasi sebelumnya dalam kalkulator biaya. Untuk melihat bagaimana harga akan berubah untuk kasus penggunaan khusus Anda, ubah variabel yang sesuai untuk memperkirakan biaya.
Kontributor
Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.
Penulis utama:
- Sujay Talasila | Prospek Produk Utama
Langkah berikutnya
Sumber daya terkait
Untuk arsitektur referensi ketersediaan tinggi dan pemulihan bencana tambahan, lihat:
- Aplikasi N-tier multi-wilayah
- Load balancing multi-wilayah
- [Aplikasi multi-wilayah dengan database privat] [Multi-region-app-with-private-database]
- Pemulihan bencana skala perusahaan