Aplikasi tingkat N Windows di Azure

Penyimpanan Blob
DNS
Load Balancer
Virtual Network
Komputer Virtual

Arsitektur referensi ini menunjukkan cara menyebarkan mesin virtual (VM) dan jaringan virtual yang dikonfigurasikan untuk aplikasi tingkat N, menggunakan SQL Server di Windows untuk tingkat data.

Arsitektur

Arsitektur tingkat N menggunakan Microsoft Azure

Unduh file Visio arsitektur ini.

Alur kerja

Arsitektur memiliki komponen-komponen berikut.

Umum

  • Grup sumber daya. Grup sumber daya digunakan untuk mengelompokkan sumber daya Azure sehingga dapat dikelola berdasarkan masa aktif, pemilik, atau kriteria lainnya.

  • Zona ketersediaan. Zona ketersediaan adalah lokasi fisik dalam wilayah Azure. Setiap zona terdiri dari satu atau beberapa pusat data dengan daya, pendingin, dan jaringan independen. Dengan menempatkan VM di seluruh zona, aplikasi menjadi tahan terhadap kegagalan dalam suatu zona.

Jaringan dan penyeimbangan beban

  • Jaringan virtual dan subnet. Setiap Azure VM disebarkan ke jaringan virtual yang dapat disegmentasi menjadi subnet. Buat subnet terpisah untuk setiap tingkat.

  • Application Gateway. Application Gateway adalah penyeimbang beban lapisan 7. Dalam arsitektur ini, penyeimbang beban ini merutekan permintaan HTTP ke front end web. Application Gateway juga menyediakan firewall aplikasi web (WAF) yang melindungi aplikasi dari eksploitasi dan kerentanan umum.

  • Load balancer. Gunakan Azure Standard Load Balancer untuk mendistribusikan lalu lintas jaringan dari tingkat web ke tingkat bisnis, dan dari tingkat bisnis hingga SQL Server.

  • Kelompok keamanan jaringan (NSG). Gunakan NSG untuk membatasi lalu lintas jaringan dalam jaringan virtual. Misalnya, dalam arsitektur tiga tingkat yang ditunjukkan di sini, tingkat database tidak menerima lalu lintas dari front end web, hanya dari tingkat bisnis dan subnet manajemen.

  • DDoS Protection. Meskipun platform Azure memberikan perlindungan dasar terhadap serangan penolakan layanan terdistribusi (DDoS), sebaiknya gunakan Azure DDoS Network Protection, yang telah meningkatkan fitur mitigasi DDoS. Lihat Pertimbangan keamanan.

  • Azure DNS. Azure DNS adalah layanan hosting untuk domain DNS. Layanan ini memberikan resolusi nama menggunakan infrastruktur Microsoft Azure. Dengan menghosting domain Anda di Azure, Anda bisa mengelola catatan DNS Anda menggunakan kredensial, API, alat, dan tagihan yang sama dengan layanan Azure lainnya.

Komputer virtual

  • Grup Ketersediaan Always On SQL Server. Menyediakan ketersediaan tinggi di tingkat data, dengan mengaktifkan replikasi dan failover. Ini menggunakan teknologi Windows Server Failover Cluster (WSFC) untuk failover.

  • Server Active Directory Domain Services (AD DS). Objek komputer untuk kluster failover dan peran kluster yang terkait dibuat di Active Directory Domain Services (AD DS).

  • Cloud Witness. Kluster failover membutuhkan lebih dari setengah nodenya untuk dijalankan, yang dikenal memiliki kuorum. Jika kluster hanya memiliki dua node, partisi jaringan dapat menyebabkan setiap node menganggap itu adalah node utama. Dalam hal ini, Anda memerlukan saksi untuk memutuskan ikatan dan menetapkan kuorum. Saksi adalah sumber daya seperti disk bersama yang dapat berfungsi sebagai pemutus ikatan untuk menetapkan kuorum. Cloud Witness adalah jenis saksi yang menggunakan Azure Blob Storage. Untuk mempelajari selengkapnya tentang konsep kuorum, lihat Memahami kluster dan kuorum kumpulan. Untuk informasi selengkapnya tentang Cloud Witness, lihat Menyebarkan Cloud Witness untuk Kluster Failover.

  • Jumpbox. Juga disebut host bastion. Secara tradisional, VM yang aman di jaringan yang digunakan administrator untuk tersambung ke VM lain. Jumpbox memiliki NSG yang memungkinkan lalu lintas jarak jauh khusus dari alamat IP publik pada daftar aman. NSG harus mengizinkan lalu lintas Remote Desktop Protocol (RDP). Azure menawarkan solusi terkelola Azure Bastion untuk memenuhi kebutuhan ini.

Rekomendasi

Kebutuhan Anda mungkin berbeda dengan arsitektur yang dijelaskan di sini. Gunakan rekomendasi ini sebagai titik awal.

Komputer virtual

Untuk rekomendasi tentang mengonfigurasi VM, lihat Menjalankan VM Windows di Azure.

Jaringan virtual

Saat Anda membuat jaringan virtual, tentukan berapa banyak alamat IP yang dibutuhkan sumber daya Anda di setiap subnet. Tentukan subnet mask dan rentang alamat jaringan yang cukup besar untuk alamat IP yang diperlukan, yakni menggunakan notasi CIDR. Gunakan ruang alamat yang termasuk dalam blok alamat IP privat standar, yaitu 10.0.0.0/8, 172.16.0.0/12, dan 192.168.0.0/16.

Jika Anda perlu menyiapkan gateway antara jaringan virtual dan jaringan lokal Anda nanti, pilih rentang alamat yang tidak tumpang tindih dengan jaringan lokal Anda. Setelah membuat jaringan virtual, Anda tidak dapat mengubah rentang alamat.

Desain subnet dengan mempertimbangkan persyaratan fungsionalitas dan keamanan. Semua VM dalam tingkat atau peran yang sama harus masuk ke subnet yang sama, yang dapat menjadi batas keamanan. Untuk informasi selengkapnya tentang mendesain jaringan virtual dan subnet, lihat Merencanakan dan mendesain Azure Virtual Networks.

Application Gateway

Untuk informasi tentang mengonfigurasi Application Gateway, lihat Ringkasan konfigurasi Application Gateway.

Load balancer

Jangan ekspos VM langsung ke Internet, melainkan berikan setiap VM alamat IP privat. Klien tersambung menggunakan alamat IP publik yang terkait dengan Application Gateway.

Tentukan aturan penyeimbang beban untuk mengarahkan lalu lintas jaringan ke VM. Misalnya, untuk mengaktifkan lalu lintas HTTP, petakan port 80 dari konfigurasi front-end ke port 80 di kumpulan alamat back-end. Ketika klien mengirimkan permintaan HTTP ke port 80, penyeimbang beban memilih alamat IP back-end dengan menggunakan algoritma hashing yang mencakup alamat IP sumber. Permintaan klien didistribusikan di semua VM di kumpulan alamat back-end.

Kelompok Keamanan Jaringan

Gunakan aturan NSG untuk membatasi lalu lintas antartingkat. Dalam arsitektur tiga tingkat yang ditunjukkan di atas, tingkat web tidak berkomunikasi langsung dengan tingkat database. Untuk menegakkan aturan ini, tingkat database harus memblokir lalu lintas masuk dari subnet tingkat web.

  1. Tolak semua lalu lintas masuk dari jaringan virtual. (Gunakan tag VIRTUAL_NETWORK dalam aturan.)
  2. Izinkan lalu lintas masuk dari subnet tingkat bisnis.
  3. Izinkan lalu lintas masuk dari subnet tingkat database itu sendiri. Aturan ini memungkinkan komunikasi antara VM database, yang diperlukan untuk replikasi database dan failover.
  4. Izinkan lalu lintas RDP (port 3389) dari subnet jumpbox. Aturan ini memungkinkan administrator tersambung ke tingkat database dari jumpbox.

Buat aturan 2 – 4 dengan prioritas lebih tinggi daripada aturan pertama, sehingga aturan tersebut akan mengambil alih.

Grup Ketersediaan AlwaysOn SQL Server

Kami merekomendasikan Grup Ketersediaan AlwaysOn untuk ketersediaan tinggi SQL Server. Sebelum Windows Server 2016, Grup Ketersediaan Always On memerlukan pengendali domain, dan semua node dalam grup ketersediaan harus berada dalam domain AD yang sama.

Tingkat lain tersambung ke database melalui pendengar grup ketersediaan. Pendengar memungkinkan klien SQL tersambung tanpa mengetahui nama instans fisik SQL Server. VM yang mengakses database harus bergabung ke domain. Klien (dalam hal ini, tingkat lain) menggunakan DNS untuk menyelesaikan nama jaringan virtual pendengar ke alamat IP.

Konfigurasikan Grup Ketersediaan AlwaysOn SQL Server sebagai berikut:

  1. Buat kluster Windows Server Failover Clustering (WSFC), Grup Ketersediaan AlwaysOn SQL Server, dan replika utama. Untuk informasi selengkapnya, lihat Memulai dengan Grup Ketersediaan AlwaysOn.

  2. Buat penyeimbang beban internal dengan alamat IP privat statis.

  3. Buat pendengar grup ketersediaan, dan petakan nama DNS pendengar ke alamat IP penyeimbang beban internal.

  4. Buat aturan penyeimbang beban untuk port mendengarkan SQL Server (port TCP 1433 secara default). Aturan penyeimbang beban harus mengaktifkan IP floating, disebut juga Direct Server Return. Hal ini menyebabkan VM membalas langsung ke klien, yang mengaktifkan koneksi langsung ke replika utama.

    Catatan

    Saat IP floating diaktifkan, nomor port front-end harus sama dengan nomor port back-end dalam aturan penyeimbang beban.

Ketika klien SQL mencoba untuk tersambung, penyeimbang beban merutekan permintaan koneksi ke replika utama. Jika ada failover ke replika lain, penyeimbang beban akan otomatis merutekan permintaan baru ke replika utama baru. Untuk informasi selengkapnya, lihat Mengonfigurasi pendengar ILB untuk Grup Ketersediaan AlwaysOn SQL Server.

Selama failover, koneksi klien yang ada akan ditutup. Setelah failover selesai, koneksi baru akan dirutekan ke replika utama baru.

Jika aplikasi Anda melakukan aktivitas baca yang jauh lebih banyak daripada aktivitas tulis, Anda dapat membongkar beberapa kueri baca-saja ke replika sekunder. Lihat Menggunakan Pendengar untuk Tersambung ke Replika Sekunder Baca-Saja (Perutean Baca-Saja).

Uji penyebaran Anda dengan menerapkan failover manual dari grup ketersediaan.

Jumpbox

Ketika Anda menjalankan mesin virtual di jaringan virtual privat, seperti dalam arsitektur ini, ada kebutuhan untuk mengakses mesin virtual untuk penginstalan perangkat lunak, patching, dan sebagainya. Namun, membuat mesin ini dapat diakses oleh internet publik bukanlah ide yang baik karena hal ini akan meningkatkan permukaan serangan secara signifikan. Sebaliknya, jumpbox digunakan sebagai lapisan akses tengah.

Dulu, VM yang dikelola oleh pelanggan dapat digunakan sebagai jumpbox. Dalam skenario tersebut, berlaku rekomendasi berikut:

  • Jangan izinkan akses RDP dari internet publik ke VM yang menjalankan beban kerja aplikasi. Sebaliknya, semua akses RDP ke VM ini harus melalui jumpbox. Administrator masuk ke jumpbox lalu masuk ke VM lain dari jumpbox. Jumpbox memungkinkan lalu lintas RDP dari internet, tetapi hanya dari alamat IP yang diketahui dan aman.
  • Jumpbox memiliki persyaratan performa minimal, jadi pilih ukuran VM yang kecil. Buat alamat IP publik untuk jumpbox. Tempatkan jumpbox di jaringan virtual yang sama dengan VM lainnya, tetapi di subnet manajemen terpisah.
  • Untuk mengamankan jumpbox, tambahkan aturan NSG yang memungkinkan koneksi RDP hanya dari satu set alamat IP publik yang aman. Konfigurasikan NSG untuk subnet lain guna memungkinkan lalu lintas RDP dari subnet manajemen.

Untuk VM yang dikelola pelanggan, semua aturan ini berlaku. Namun, rekomendasi saat ini adalah menggunakan Azure Bastion, solusi jumpbox terkelola yang memungkinkan akses HTML5 ke RDP atau SSH dengan perlindungan dari Azure AD. Ini adalah solusi yang jauh lebih sederhana yang pada akhirnya memiliki total biaya kepemilikan (TCO) yang lebih rendah untuk pelanggan.

Pertimbangan

Skalabilitas

Kumpulan skala

Untuk tingkat web dan bisnis, pertimbangkan untuk menggunakan Virtual Machine Scale Sets alih-alih menyebarkan VM terpisah. Satu set skala memudahkan penyebaran dan pengelolaan satu set VM yang identik, dan menskalakan VM secara otomatis berdasarkan metrik performa. Saat beban pada VM meningkat, VM tambahan akan otomatis ditambahkan ke penyeimbang beban. Pertimbangkan set skala jika Anda perlu melakukan perluasan skala VM dengan cepat, atau jika Anda perlu melakukan penskalaan otomatis.

Ada dua cara dasar untuk mengonfigurasi VM yang disebarkan dalam satu set skala:

  • Gunakan ekstensi untuk mengonfigurasi VM setelah disebarkan. Dengan pendekatan ini, instans VM baru mungkin akan dimulai dalam waktu yang lebih lama daripada VM tanpa ekstensi.

  • Sebarkan disk terkelola dengan gambar disk kustom. Opsi ini mungkin lebih cepat untuk disebarkan. Namun, opsi itu mengharuskan Anda untuk terus memperbarui gambar.

Untuk informasi selengkapnya, lihat Pertimbangan desain untuk set skala.

Tip

Saat menggunakan solusi skala otomatis apa pun, uji dengan beban kerja tingkat produksi terlebih dahulu.

Batas langganan

Setiap langganan Azure memiliki batas default, termasuk jumlah maksimum VM per wilayah. Anda dapat meningkatkan batas dengan mengajukan permintaan dukungan. Untuk informasi selengkapnya, lihat Hambatan, kuota, batas layanan, dan langganan Azure.

Application Gateway

Application Gateway mendukung mode kapasitas tetap atau mode pensakalaan otomatis. Mode kapasitas tetap berguna untuk skenario dengan beban kerja yang konsisten dan dapat diprediksi. Sebaiknya gunakan mode penskalaan otomatis untuk beban kerja dengan lalu lintas variabel. Untuk informasi selengkapnya, lihat Penskalaan otomatis dan Zone-redundant Application Gateway v2

Ketersediaan

Zona ketersediaan memberikan ketahanan terbaik dalam satu wilayah. Jika Anda membutuhkan ketersediaan yang lebih tinggi, sebaiknya replikasi aplikasi di dua wilayah menggunakan Azure Traffic Manager untuk failover. Untuk informasi selengkapnya, lihat Aplikasi tingkat N multi-wilayah untuk ketersediaan tinggi.

Tidak semua wilayah mendukung zona ketersediaan, dan tidak semua ukuran VM didukung di semua zona. Jalankan perintah Azure CLI berikut untuk menemukan zona yang didukung bagi setiap ukuran VM dalam suatu wilayah:

az vm list-skus --resource-type virtualMachines --zone false --location <location> \
    --query "[].{Name:name, Zones:locationInfo[].zones[] | join(','@)}" -o table

Jika Anda menerapkan arsitektur ini ke wilayah yang tidak mendukung zona ketersediaan, letakkan VM untuk setiap tingkat di dalam satu set ketersediaan. VM dalam set ketersediaan yang sama disebarkan di beberapa server fisik, rak komputasi, unit penyimpanan, dan sakelar jaringan untuk redundansi. Set skala secara otomatis menggunakan grup penempatan, yang berfungsi sebagai set ketersediaan implisit.

Saat melakukan penyebaran ke zona ketersediaan, gunakan SKU Standar Azure Load Balancer dan SKU v2 Application Gateway. SKU ini mendukung redundansi lintas zona. Untuk informasi selengkapnya, lihat:

Satu penyebaran Application Gateway dapat menjalankan beberapa instans gateway. Untuk beban kerja produksi, jalankan setidaknya dua instans.

Pemeriksaan kesehatan

Application Gateway dan Load Balancer sama-sama menggunakan probe kesehatan untuk memantau ketersediaan instans VM.

  • Application Gateway selalu menggunakan probe HTTP.
  • Load Balancer dapat menguji HTTP atau TCP. Umumnya, jika VM menjalankan server HTTP, gunakan probe HTTP. Jika tidak, gunakan TCP.

Jika probe tidak dapat menjangkau instans dalam periode batas waktu, gateway atau penyeimbang beban akan berhenti mengirimkan lalu lintas ke VM tersebut. Probe terus memeriksa dan akan mengembalikan VM ke kumpulan back-end jika VM tersedia lagi.

Probe HTTP mengirimkan permintaan HTTP GET ke jalur yang ditentukan dan mendengarkan respons HTTP 200. Jalur ini dapat berupa jalur root ("/"), atau titik akhir pemantauan kesehatan yang menerapkan logika kustom tertentu untuk memeriksa kesehatan aplikasi. Titik akhir harus mengizinkan permintaan HTTP anonim.

Untuk informasi selengkapnya tentang probe kesehatan, lihat:

Untuk pertimbangan tentang merancang titik akhir pemeriksaan kesehatan, lihat Pola Pemantauan Titik Akhir Kesehatan.

Pengoptimalan biaya

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

Rangkaian skala komputer virtual

Set skala mesin virtual tersedia pada semua ukuran VM Windows. Anda hanya dikenakan biaya untuk VM Azure yang disebarkan dan sumber daya infrastruktur dasar tambahan yang digunakan, seperti penyimpanan dan jaringan. Tidak ada pertambahan biaya 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 VM SQL.

Load balancer

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

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

Keamanan

Jaringan virtual adalah batas isolasi lalu lintas di Azure. Secara default, VM dalam satu jaringan virtual tidak dapat berkomunikasi langsung dengan VM di jaringan virtual yang berbeda. Namun, Anda dapat secara eksplisit menyambungkan jaringan virtual menggunakan peering jaringan virtual.

NSG. Gunakan kelompok keamanan jaringan (NSG) untuk membatasi lalu lintas menuju dan dari internet. Untuk informasi selengkapnya, lihat Keamanan jaringan dan layanan cloud Microsoft.

DMZ. Sebaiknya tambahkan appliance virtual jaringan (NVA) untuk membuat DMZ antara Internet dan jaringan virtual Azure. NVA adalah istilah umum untuk appliance virtual yang dapat melakukan tugas terkait jaringan, seperti firewall, inspeksi paket, audit, dan perutean kustom. Untuk informasi selengkapnya, lihat Menerapkan DMZ antara Azure dan Internet.

Enkripsi. Enkripsi data tidak aktif yang sensitif dan gunakan Azure Key Vault untuk mengelola kunci enkripsi database. Key Vault dapat menyimpan kunci enkripsi dalam modul keamanan perangkat keras (HSM). Untuk informasi selengkapnya, lihat Mengonfigurasi integrasi Azure Key Vault untuk SQL Server di Komputer Virtual Azure (Resource Manager). Sebaiknya simpan juga rahasia aplikasi, seperti string koneksi database, di Key Vault.

Perlindungan DDoS. Platform Azure menyediakan perlindungan DDoS dasar secara default. Perlindungan dasar ini ditargetkan untuk melindungi infrastruktur Azure secara keseluruhan. Meskipun perlindungan DDoS dasar diaktifkan secara otomatis, sebaiknya gunakan Azure DDoS Network Protection. Perlindungan Jaringan menggunakan penyetelan adaptif, berdasarkan pola lalu lintas jaringan aplikasi Anda, untuk mendeteksi ancaman. Dengan demikian, perlindungan ini dapat menerapkan mitigasi terhadap serangan DDoS yang mungkin tidak terdeteksi oleh kebijakan DDoS di seluruh infrastruktur. Perlindungan Jaringan juga menyediakan peringatan, telemetri, dan analitik melalui Azure Monitor. Untuk informasi selengkapnya, lihat Azure DDoS Protection: Praktik terbaik dan arsitektur referensi.

Keunggulan operasional

Karena semua sumber daya utama dan dependensinya berada dalam jaringan virtual yang sama dalam arsitektur ini, sumber daya tersebut diisolasi dalam beban kerja dasar yang sama. Fakta itu memudahkan untuk mengaitkan sumber daya khusus beban kerja ke tim, sehingga tim dapat mengelola semua aspek sumber daya tersebut secara independen. Isolasi ini memungkinkan DevOps melakukan integrasi berkelanjutan dan pengiriman berkelanjutan (CI/CD).

Selain itu, Anda dapat menggunakan templat penyebaran yang berbeda dan mengintegrasikannya dengan Layanan Azure DevOps untuk memprovisikan lingkungan yang berbeda dalam hitungan menit. Misalnya untuk mereplikasi skenario mirip produksi atau memuat lingkungan pengujian hanya jika diperlukan, sehingga akan menghemat biaya.

Dalam skenario ini, komputer virtual Anda dikonfigurasi dengan menggunakan Ekstensi Komputer Virtual, karena mereka menawarkan kemungkinan menginstal perangkat lunak tambahan tertentu, seperti anti malware dan agen keamanan. Ekstensi VM diinstal dan dijalankan hanya pada waktu pembuatan VM. Itu berarti jika Sistem Operasi dikonfigurasikan secara tidak benar pada tahap selanjutnya, akan diperlukan intervensi manual untuk memindahkannya kembali ke status yang benar.

Alat Manajemen Konfigurasi, khususnya Desired State Configuration (DSC), digunakan dalam arsitektur ini untuk mengonfigurasikan Active Directory dan Grup Ketersediaan AlwaysOn SQL Server.

Sebaiknya gunakan Azure Monitor untuk Menganalisis dan mengoptimalkan performa infrastruktur Anda, serta 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 Anda, 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 Azure Well-Architected Framework.

Langkah berikutnya