Arsitektur garis besar Azure Virtual Machines

Artikel ini menyediakan arsitektur referensi dasar untuk beban kerja yang disebarkan di Azure Virtual Machines.

Contoh beban kerja yang diasumsikan oleh arsitektur ini adalah aplikasi web multi-tingkat yang menghadap internet yang disebarkan pada set komputer virtual (VM) terpisah. VM disediakan sebagai bagian dari penyebaran Azure Virtual Machine Scale Sets. Arsitektur ini dapat digunakan untuk skenario ini:

• Aplikasi privat. Aplikasi ini mencakup aplikasi lini bisnis internal atau solusi komersial di luar rak.
• Aplikasi publik. Aplikasi ini adalah aplikasi yang terhubung ke internet. Arsitektur ini bukan untuk komputasi berkinerja tinggi, beban kerja misi penting, aplikasi yang sangat terpengaruh oleh latensi, atau kasus penggunaan khusus lainnya.

Fokus utama arsitektur ini bukan aplikasi. Sebagai gantinya, artikel ini menyediakan panduan untuk mengonfigurasi dan menyebarkan komponen infrastruktur tempat aplikasi berinteraksi. Komponen-komponen ini termasuk komponen komputasi, penyimpanan, jaringan, dan pemantauan.

Arsitektur ini berfungsi sebagai titik awal untuk beban kerja yang dihosting infrastruktur sebagai layanan (IaaS). Tingkat data sengaja dikecualikan dari panduan ini untuk mempertahankan fokus pada infrastruktur komputasi.

Tata letak artikel

Sistem	Keputusan desain	Pendekatan Well-Architected Framework
▪ Diagram arsitektur ▪ Sumber daya beban kerja ▪ Sumber daya pendukung ▪ Alur pengguna	▪ Pilihan desain VM ▪ Disk ▪ Jaringan ▪ Pemantauan ▪ Manajemen pembaruan	▪ Keandalan ▪ Keamanan ▪ Pengoptimalan Biaya

Sistem

Unduh file Visio arsitektur ini.

Untuk informasi tentang sumber daya ini, lihat Dokumentasi produk Azure yang tercantum di Sumber daya terkait.

Komponen

Arsitektur ini terdiri dari beberapa layanan Azure untuk sumber daya beban kerja dan sumber daya pendukung beban kerja. Layanan untuk masing-masing dan perannya dijelaskan di bagian berikut.

Sumber daya beban kerja

• Azure Virtual Machines berfungsi sebagai sumber daya komputasi untuk aplikasi dan didistribusikan di seluruh zona ketersediaan. Untuk tujuan ilustrasi, kombinasi VM Windows dan Linux digunakan.

  Azure Virtual Machine Scale Sets dalam mode orkestrasi Fleksibel digunakan untuk menyediakan dan mengelola VM.

  Aplikasi sampel dapat diwakili dalam dua tingkatan, masing-masing membutuhkan komputasinya sendiri.

  • Ujung depan menjalankan server web dan menerima permintaan pengguna.
  • Back end menjalankan server web lain yang bertindak sebagai API web yang mengekspos satu titik akhir tempat logika bisnis dijalankan.

  VM front-end memiliki disk data (Premium_LRS) yang terpasang, yang dapat digunakan untuk menyebarkan aplikasi stateless. VM back-end menyimpan data untuk Premium_ZRS disk lokal sebagai bagian dari operasinya. Tata letak ini dapat diperluas untuk menyertakan tingkat database untuk menyimpan status dari komputasi front-end dan back-end. Tingkat itu berada di luar cakupan arsitektur ini.

• Azure Virtual Network menyediakan jaringan privat untuk semua sumber daya beban kerja. Jaringan disegmentasi ke dalam subnet, yang berfungsi sebagai batas isolasi.

• Azure Application Gateway adalah titik masuk tunggal yang merutekan permintaan ke server front-end. SKU yang dipilih mencakup Azure Web Application Firewall (WAF) terintegrasi untuk keamanan tambahan.

• Azure Load Balancer internal merutekan lalu lintas dari tingkat front-end ke server back-end.

• Azure Load Balancer Standard SKU menyediakan akses internet keluar ke VM menggunakan tiga alamat IP publik.

• Azure Key Vault menyimpan sertifikat yang digunakan untuk komunikasi keamanan lapisan transportasi end-to-end (TLS). Ini juga dapat digunakan untuk rahasia aplikasi.

Sumber daya pendukung beban kerja

• Azure Bastion menyediakan akses operasional ke VM melalui protokol yang aman.

• Application Insights mengumpulkan log dan metrik dari aplikasi. Karena aplikasi bukan fokus arsitektur ini, pengumpulan log tidak ditunjukkan dalam implementasi.

• Log Analytics adalah sink data pemantauan yang mengumpulkan log dan metrik dari sumber daya Azure dan Application Insights. Akun penyimpanan disediakan sebagai bagian dari ruang kerja.

Alur pengguna

Ada dua jenis pengguna yang berinteraksi dengan sumber daya beban kerja: pengguna dan operator beban kerja. Alur untuk pengguna ini ditampilkan dalam diagram arsitektur sebelumnya.

Pengguna beban kerja

1. Pengguna mengakses situs web dengan menggunakan alamat IP publik Application Gateway yang diekspos.

2. Application Gateway menerima lalu lintas HTTPS, mendekripsi data menggunakan sertifikat eksternal untuk inspeksi WAF, dan mengenkripsi ulang menggunakan sertifikat wildcard internal untuk transportasi ke ujung depan.

3. Application Gateway menyeimbangkan lalu lintas di seluruh VM front-end dan meneruskan permintaan ke VM front-end.

4. VM front-end yang dipilih berkomunikasi ke VM back-end dengan menggunakan alamat IP privat load balancer, bukan IP VM individual. Komunikasi ini juga dienkripsi menggunakan sertifikat wildcard internal.

5. VM back-end mendekripsi permintaan menggunakan sertifikat internal. Setelah back end memproses permintaan, ia mengembalikan hasilnya ke ujung depan, yang mengembalikan hasilnya ke gateway aplikasi, dan akhirnya mengembalikan hasilnya kepada pengguna.

Operator

VM dalam arsitektur ini mungkin memerlukan akses langsung oleh operator, tetapi kami menyarankan agar akses jarak jauh diminimalkan melalui otomatisasi dan akses tersebut dipantau. Aksesnya mungkin untuk situasi break-fix, pemecahan masalah, atau bagian dari proses penyebaran otomatis. Arsitektur ini tidak memiliki IP publik untuk akses sarana kontrol. Azure Bastion bertindak sebagai gateway tanpa server, memungkinkan operasi untuk mengakses VM melalui SSH atau RDP. Penyiapan ini memastikan manajemen akses yang aman dan efisien.

1. Operator masuk ke portal Azure atau Azure CLI.
2. Operator mengakses layanan Azure Bastion dan terhubung dari jarak jauh ke VM yang diinginkan.

Pilihan desain VM

Saat memilih SKU, penting untuk memiliki ekspektasi performa dasar. Beberapa karakteristik memengaruhi proses pengambilan keputusan, termasuk:

• Operasi input/output CPU, memori, dan disk per detik (IOPS).
• Arsitektur prosesor.
• Ukuran gambar sistem operasi (OS).

Misalnya, jika Anda memigrasikan beban kerja dari lingkungan lokal yang memerlukan mesin prosesor Intel, pilih SKU VM yang mendukung prosesor Intel.

Untuk informasi tentang SKU VM yang didukung, lihat Ukuran untuk komputer virtual di Azure.

Bootstrapping

VM sering kali perlu di-bootstrap, yang merupakan proses di mana VM disiapkan dan disetel untuk menjalankan aplikasi. Tugas bootstrapping umum meliputi, menginstal sertifikat, mengonfigurasi akses jarak jauh, menginstal paket, menyetel dan mengeraskan konfigurasi OS, serta memformat dan memasang disk data. Penting untuk mengotomatiskan proses bootstrapping sebanyak mungkin, sehingga aplikasi dapat dimulai pada VM tanpa penundaan atau intervensi manual. Berikut adalah rekomendasi untuk otomatisasi:

• Ekstensi komputer virtual. Ekstensi ini adalah objek Azure Resource Manager yang dikelola melalui penyebaran Infrastructure-as-Code (IaC) Anda. Dengan cara ini, kegagalan apa pun dilaporkan sebagai penyebaran yang gagal yang dapat Anda ambil tindakan. Jika tidak ada ekstensi untuk kebutuhan bootstrapping Anda, buat skrip kustom. Disarankan agar Anda menjalankan skrip melalui Ekstensi Skrip Kustom Azure.

  Berikut adalah beberapa ekstensi lain yang dapat digunakan untuk menginstal atau mengonfigurasi fungsionalitas secara otomatis pada VM.

  • Azure Monitor Agent (AMA) mengumpulkan data pemantauan dari OS tamu dan mengirimkannya ke Azure Monitor.
  • Azure Custom Script Extension (Windows, Linux) Versi 2 mengunduh dan menjalankan skrip pada komputer virtual (VM) Azure. Ekstensi ini berguna untuk mengotomatiskan konfigurasi pasca-penyebaran, penginstalan perangkat lunak, atau tugas konfigurasi atau manajemen lainnya.
  • Ekstensi komputer virtual Azure Key Vault (Windows, Linux) menyediakan refresh otomatis sertifikat yang disimpan di Key Vault dengan mendeteksi perubahan dan menginstal sertifikat yang sesuai.
  • Ekstensi Application Health dengan Virtual Machine Scale Sets penting ketika Azure Virtual Machine Scale Sets melakukan peningkatan bergulir otomatis. Azure bergantung pada pemantauan kesehatan instans individual untuk melakukan pembaruan. Anda juga dapat menggunakan ekstensi untuk memantau kesehatan aplikasi setiap instans dalam set skala Anda dan melakukan perbaikan instans menggunakan Perbaikan Instans Otomatis.
  • MICROSOFT Entra ID dan OpenSSH (Windows, Linux) terintegrasi dengan autentikasi Microsoft Entra. Anda sekarang dapat menggunakan MICROSOFT Entra ID sebagai platform autentikasi inti dan otoritas sertifikat untuk SSH ke VM Linux dengan menggunakan ID Microsoft Entra dan autentikasi berbasis sertifikat OpenSSH. Fungsionalitas ini memungkinkan Anda mengelola akses ke VM dengan kontrol akses berbasis peran Azure (RBAC) dan kebijakan Akses Bersyar.

• Konfigurasi berbasis agen. VM Linux dapat menggunakan konfigurasi status asli ringan yang diinginkan yang tersedia melalui cloud-init pada berbagai gambar VM yang disediakan Azure. Konfigurasi ditentukan dan diberi versi dengan artefak IaC Anda. Membawa solusi manajemen konfigurasi Anda sendiri adalah cara lain. Sebagian besar solusi mengikuti pendekatan deklaratif-pertama untuk bootstrapping, tetapi mendukung skrip kustom untuk fleksibilitas. Pilihan populer termasuk Konfigurasi Status yang Diinginkan untuk Windows, Konfigurasi Status yang Diinginkan untuk Linux, Ansible, Chef, Puppet, dan lainnya. Semua solusi konfigurasi ini dapat dipasangkan dengan ekstensi VM untuk pengalaman terbaik dari keduanya.

Dalam implementasi referensi, semua bootstrapping dilakukan melalui ekstensi VM dan skrip kustom, termasuk skrip kustom untuk mengotomatiskan pemformatan dan pemasangan disk data.

Lihat Well-Architected Framework: RE:02 - Rekomendasi untuk desain otomatisasi.

Konektivitas VM

Untuk mengaktifkan komunikasi privat antara VM dan perangkat lain di jaringan virtual tertentu, kartu antarmuka jaringan (NIC) VM terhubung ke salah satu subnet jaringan virtual. Jika Anda memerlukan beberapa NIC untuk VM Anda, ketahuilah bahwa jumlah maksimum NIC ditentukan untuk setiap ukuran VM.

Jika beban kerja membutuhkan komunikasi latensi rendah antara VM di jaringan virtual, pertimbangkan jaringan terakselerasi, yang didukung oleh NIC Azure VM. Untuk informasi selengkapnya, lihat Manfaat jaringan yang dipercepat.

Virtual Machine Scale Sets dengan orkestrasi Fleksibel

VM disediakan sebagai bagian dari Virtual Machine Scale Sets dengan orkestrasi Fleksibel. Virtual Machine Scale Sets adalah pengelompokan logis VM yang digunakan untuk memenuhi kebutuhan bisnis. Jenis VM dalam pengelompokan dapat identik atau berbeda. Mereka memungkinkan Anda mengelola siklus hidup komputer, antarmuka jaringan, dan disk menggunakan API dan perintah Azure VM standar.

Mode orkestrasi fleksibel memfasilitasi operasi dalam skala besar dan membantu keputusan penskalakan terperinci.

Konfigurasi domain kesalahan diperlukan untuk membatasi efek kegagalan perangkat keras fisik, pemadaman jaringan, atau gangguan daya. Dengan set skala, Azure secara merata menyebarkan instans di seluruh domain kesalahan untuk ketahanan terhadap satu masalah perangkat keras atau infrastruktur.

Kami menyarankan agar Anda membongkar alokasi domain kesalahan ke Azure untuk penyebaran instans maksimum, meningkatkan ketahanan dan ketersediaan.

Disk

Untuk menjalankan komponen OS dan aplikasi, disk penyimpanan dilampirkan ke VM. Pertimbangkan untuk menggunakan disk ephemeral untuk OS dan disk terkelola untuk penyimpanan data.

Azure menyediakan berbagai opsi dalam hal performa, fleksibilitas, dan biaya. Mulailah dengan SSD Premium untuk sebagian besar beban kerja produksi. Pilihan Anda tergantung pada SKU VM. SKU yang mendukung SSD Premium berisi s dalam nama sumber daya, misalnya Dsv4 tetapi bukan Dv4.

Untuk informasi selengkapnya tentang opsi disk dengan metrik seperti kapasitas, IOPS, dan throughput, lihat Perbandingan jenis disk.

Pertimbangkan karakteristik disk dan ekspektasi performa saat memilih disk.

• Batasan SKU VM. Disk beroperasi dalam VM yang dilampirkan, yang memiliki batas IOPS dan throughput. Pastikan disk tidak membatasi batas VM dan sebaliknya. Pilih ukuran disk, performa, dan kemampuan VM (inti, CPU, memori) yang secara optimal menjalankan komponen aplikasi. Hindari provisi berlebih karena berdampak pada biaya.

• Perubahan konfigurasi. Anda dapat mengubah beberapa konfigurasi performa dan kapasitas disk saat VM berjalan. Namun, banyak perubahan dapat memerlukan penyediaan ulang dan pembangunan ulang konten disk, yang memengaruhi ketersediaan beban kerja. Oleh karena itu, rencanakan pemilihan disk dan VM SKU dengan cermat untuk meminimalkan dampak ketersediaan dan pengerjaan ulang.

• Disk OS Ephemeral. Provisikan disk OS sebagai disk sementara. Gunakan disk terkelola hanya jika file OS perlu dipertahankan. Hindari menggunakan disk sementara untuk menyimpan komponen dan status aplikasi.

  Kapasitas disk OS Ephemeral tergantung pada SKU VM yang dipilih. Pastikan ukuran disk gambar OS Anda kurang dari cache SKU yang tersedia atau disk sementara. Anda dapat menggunakan ruang yang tersisa untuk penyimpanan sementara.

• Performa disk. Ruang disk pra-provisi berdasarkan beban puncak adalah umum, tetapi dapat menyebabkan sumber daya yang kurang digunakan karena sebagian besar beban kerja tidak mempertahankan beban puncak.

  Pantau pola penggunaan beban kerja Anda, catat lonjakan atau operasi baca tinggi berkelanjutan, dan faktorkan pola ini ke dalam VM dan pilihan SKU disk terkelola Anda.

  Anda dapat menyesuaikan performa sesuai permintaan dengan mengubah tingkat performa atau dengan menggunakan fitur bursting yang ditawarkan dalam beberapa SKU disk terkelola.

  Meskipun provisi berlebihan mengurangi kebutuhan akan bursting, itu dapat menyebabkan kapasitas yang tidak digunakan yang Anda bayar. Idealnya, gabungkan kedua fitur untuk hasil yang optimal.

• Menyetel penembolokan untuk beban kerja. Konfigurasikan pengaturan cache untuk semua disk berdasarkan penggunaan komponen aplikasi.

  Komponen yang terutama melakukan operasi baca tidak memerlukan konsistensi transaksi disk tinggi. Komponen-komponen tersebut dapat memperoleh manfaat dari penembolokan baca-saja. Komponen write-heavy yang membutuhkan konsistensi transaksional disk tinggi sering kali menonaktifkan penembolokan.

  Menggunakan penembolokan baca-tulis dapat menyebabkan kehilangan data jika VM mengalami crash dan tidak disarankan untuk sebagian besar skenario disk data.

Dalam arsitektur ini:

• Disk OS dari semua VM bersifat ephemeral dan terletak di disk cache.

  Aplikasi beban kerja di ujung depan (Linux) dan back end (Windows Server) toleran terhadap kegagalan VM individual dan keduanya menggunakan gambar kecil (sekitar 30 GB). Atribut tersebut membuatnya memenuhi syarat untuk menggunakan disk OS Sementara yang dibuat sebagai bagian dari penyimpanan lokal VM (partisi cache) alih-alih disk OS Persisten yang disimpan di sumber daya penyimpanan Azure jarak jauh. Situasi ini tidak dikenakan biaya penyimpanan untuk disk OS dan juga meningkatkan performa dengan memberikan latensi yang lebih rendah dan mengurangi waktu penyebaran VM.

• Setiap VM memiliki disk terkelola Premium SSD P1 sendiri, menyediakan throughput dasar yang disediakan yang cocok untuk beban kerja.

Tata letak jaringan

Arsitektur ini menyebarkan beban kerja dalam satu jaringan virtual. Kontrol jaringan adalah bagian penting dari arsitektur ini dan dijelaskan di bagian Keamanan .

Tata letak ini dapat diintegrasikan dengan topologi perusahaan. Contoh tersebut ditampilkan dalam arsitektur garis besar komputer virtual di zona pendaratan Azure.

Jaringan virtual

Salah satu keputusan tata letak jaringan awal Anda berkaitan dengan rentang alamat jaringan. Perlu diingat pertumbuhan jaringan yang diantisipasi selama fase perencanaan kapasitas. Jaringan harus cukup besar untuk mempertahankan pertumbuhan, yang mungkin memerlukan konstruksi jaringan tambahan. Misalnya, jaringan virtual harus memiliki kapasitas untuk mengakomodasi VM lain yang dihasilkan dari operasi penskalaan.

Sebaliknya, sesuaikan ukuran ruang alamat Anda. Jaringan virtual yang terlalu besar dapat menyebabkan kurangnya penggunaan. Penting untuk dicatat bahwa setelah jaringan virtual dibuat, rentang alamat tidak dapat dimodifikasi.

Dalam arsitektur ini, ruang alamat diatur ke /21, keputusan berdasarkan proyeksi pertumbuhan.

Pertimbangan subnet

Dalam jaringan virtual, subnet dibagi berdasarkan fungsionalitas dan persyaratan keamanan, seperti yang dijelaskan di sini:

• Subnet untuk menghosting gateway aplikasi, yang berfungsi sebagai proksi terbalik. Application Gateway memerlukan subnet khusus.
• Subnet untuk menghosting load balancer internal untuk mendistribusikan lalu lintas ke VM back-end.
• Subnet untuk menghosting VM beban kerja, satu untuk ujung depan dan satu untuk back end. Subnet ini dibuat sesuai dengan tingkat aplikasi.
• Subnet untuk host Azure Bastion untuk memfasilitasi akses operasional ke VM beban kerja. Secara desain, host Azure Bastion memerlukan subnet khusus.
• Subnet untuk menghosting titik akhir privat yang dibuat untuk mengakses sumber daya Azure lainnya melalui Azure Private Link. Meskipun subnet khusus tidak wajib untuk titik akhir ini, kami merekomendasikannya.

Mirip dengan jaringan virtual, subnet harus berukuran tepat. Misalnya, Anda mungkin ingin menerapkan batas maksimum VM yang didukung oleh orkestrasi Fleksibel untuk memenuhi kebutuhan penskalaan aplikasi. Subnet beban kerja harus mampu mengakomodasi batas tersebut.

Kasus penggunaan lain yang perlu dipertimbangkan adalah peningkatan OS VM, yang mungkin memerlukan alamat IP sementara. Ukuran yang tepat memberi Anda tingkat segmentasi yang diinginkan dengan memastikan sumber daya serupa dikelompokkan sehingga aturan keamanan yang bermakna melalui kelompok keamanan jaringan (NSG) dapat diterapkan ke batas subnet. Untuk informasi selengkapnya, lihat Keamanan: Segmentasi.

Lalu lintas ingress

Dua alamat IP publik digunakan untuk alur masuk. Satu alamat adalah untuk Application Gateway yang berfungsi sebagai proksi terbalik. Pengguna terhubung menggunakan alamat IP publik tersebut. Beban proksi terbalik menyeimbangkan lalu lintas masuk ke IP privat VM. Alamat lainnya adalah untuk akses operasional melalui Azure Bastion.

Unduh file Visio arsitektur ini.

Lalu lintas egress

Arsitektur ini menggunakan Load Balancer SKU standar dengan aturan keluar yang ditentukan dari instans VM. Load Balancer dipilih karena zonanya redundan.

Unduh file Visio arsitektur ini.

Konfigurasi ini memungkinkan Anda menggunakan IP publik load balancer Anda untuk menyediakan konektivitas internet keluar untuk VM. Aturan keluar memungkinkan Anda secara eksplisit menentukan port terjemahan alamat jaringan sumber (SNAT). Aturan ini memungkinkan Anda menskalakan dan menyetel kemampuan ini melalui alokasi port manual. Mengalokasikan port SNAT secara manual berdasarkan ukuran kumpulan back-end dan jumlah frontendIPConfigurations dapat membantu menghindari kelelahan SNAT.

Kami menyarankan agar Anda mengalokasikan port berdasarkan jumlah maksimum instans back-end. Jika lebih banyak instans ditambahkan daripada port SNAT yang tersisa memungkinkan, operasi penskalaan Virtual Machine Scale Sets mungkin diblokir, atau VM baru tidak menerima port SNAT yang memadai.

Hitung port per instans sebagai: Number of front-end IPs * 64K / Maximum number of back-end instances.

Ada opsi lain yang dapat Anda gunakan, seperti menyebarkan sumber daya Azure NAT Gateway yang dilampirkan ke subnet. Opsi lain adalah menggunakan Azure Firewall atau Network Virtual Appliance lain dengan rute kustom yang ditentukan pengguna (UDR) sebagai hop berikutnya melalui firewall. Opsi itu ditampilkan dalam arsitektur garis besar komputer virtual di zona pendaratan Azure.

Penyelesaian DNS

Azure DNS digunakan sebagai layanan dasar untuk semua kasus penggunaan resolusi, misalnya, menyelesaikan nama domain yang sepenuhnya memenuhi syarat (FQDN) yang terkait dengan VM beban kerja. Dalam arsitektur ini, VM menggunakan nilai DNS yang diatur dalam konfigurasi jaringan virtual, yaitu Azure DNS.

Zona DNS privat Azure digunakan untuk menyelesaikan permintaan ke titik akhir privat yang digunakan untuk mengakses sumber daya Private Link bernama.

Pemantauan

Arsitektur ini memiliki tumpukan pemantauan yang dipisahkan dari utilitas beban kerja. Fokusnya terutama pada sumber data dan aspek pengumpulan.

Metrik dan log dihasilkan di berbagai sumber data, memberikan wawasan pengamatan di berbagai ketinggian:

• Infrastruktur dan komponen yang mendasar dipertimbangkan, seperti VM, jaringan virtual, dan layanan penyimpanan. Log platform Azure menyediakan informasi tentang operasi dan aktivitas dalam platform Azure.

• Tingkat aplikasi memberikan wawasan tentang performa dan perilaku aplikasi yang berjalan pada sistem Anda.

Ruang kerja Analitik Log adalah sink data pemantauan yang direkomendasikan yang digunakan untuk mengumpulkan log dan metrik dari sumber daya Azure dan Application Insights.

Gambar ini menunjukkan tumpukan pemantauan untuk garis besar dengan komponen untuk mengumpulkan data dari infrastruktur dan aplikasi, sink data, dan berbagai alat konsumsi untuk analisis dan visualisasi. Implementasi ini menyebarkan beberapa komponen, seperti Application Insights, diagnostik boot VM, dan Analitik Log. Komponen lain digambarkan untuk menampilkan opsi ekstensibilitas, seperti dasbor dan pemberitahuan.

Unduh file Visio arsitektur ini.

Pemantauan tingkat infrastruktur

Tabel ini menautkan ke log dan metrik yang dikumpulkan oleh Azure Monitor. Pemberitahuan yang tersedia membantu Anda mengatasi masalah secara proaktif sebelum memengaruhi pengguna.

Sumber daya Azure	Metrik dan log	Peringatan
Application Gateway	Deskripsi metrik dan log Application Gateway	Pemberitahuan Application Gateway
Application Insights	Metrik Application Insights dan API pengelogan	Pemberitahuan Application Insights
Azure Bastion	Metrik Azure Bastion
Key Vault	Deskripsi metrik dan log Key Vault	Pemberitahuan Key Vault
Standar Load Balancer	Log dan metrik load balancer	Pemberitahuan Load Balancer
Alamat IP publik	Metrik alamat IP publik dan deskripsi log	Pemberitahuan metrik alamat IP publik
Virtual Network	Referensi metrik dan log jaringan virtual	Pemberitahuan jaringan virtual
Virtual Machines dan Virtual Machine Scale Sets	Metrik dan referensi log VM	Pemberitahuan dan tutorial VM
Web Application Firewall	Deskripsi metrik dan log Web Application Firewall	Pemberitahuan Web Application Firewall

Untuk informasi selengkapnya tentang biaya pengumpulan metrik dan log, lihat Perhitungan dan opsi biaya Analitik Log dan Harga untuk ruang kerja Analitik Log. Sifat beban kerja dan frekuensi serta jumlah metrik dan log yang dikumpulkan sangat berdampak pada metrik dan biaya pengumpulan log.

Mesin virtual

Diagnostik boot Azure diaktifkan untuk mengamati status VM selama boot dengan mengumpulkan informasi log serial dan cuplikan layar. Dalam arsitektur ini, data tersebut dapat diakses melalui portal Azure dan perintah azure CLI vm boot-diagnostics get-boot-log. Data dikelola oleh Azure dan Anda tidak memiliki kontrol atau akses ke sumber daya penyimpanan yang mendasar. Namun, jika persyaratan bisnis Anda menuntut kontrol lebih, Anda dapat menyediakan akun penyimpanan Anda sendiri untuk menyimpan diagnostik boot.

Wawasan VM menawarkan cara yang efisien untuk memantau VM dan set skala. Ini mengumpulkan data dari ruang kerja Analitik Log dan menyediakan buku kerja yang telah ditentukan sebelumnya untuk tren data performa. Data ini dapat dilihat per VM atau diagregasi di beberapa VM.

Application Gateway dan load balancer internal menggunakan pemeriksaan kesehatan untuk mendeteksi status titik akhir VM sebelum mengirim lalu lintas.

Jaringan

Dalam arsitektur ini, data log dikumpulkan dari beberapa komponen jaringan yang berpartisipasi dalam alur. Komponen-komponen ini termasuk Application Gateway, load balancer, dan Azure Bastion. Mereka juga termasuk komponen keamanan jaringan seperti jaringan virtual, NSG, alamat IP publik, dan Private Link.

Disk terkelola

Metrik disk bergantung pada beban kerja Anda, membutuhkan campuran metrik utama. Pemantauan harus menggabungkan perspektif ini untuk mengisolasi os atau masalah throughput aplikasi.

• Perspektif platform Azure mewakili metrik yang menunjukkan layanan Azure, terlepas dari beban kerja yang terhubung ke dalamnya. Metrik performa disk (IOPS dan throughput) dapat dilihat secara individual atau kolektif untuk semua disk yang terpasang pada VM. Gunakan metrik pemanfaatan IO penyimpanan untuk pemecahan masalah atau pemberitahuan tentang potensi pembatasan disk. Jika Anda menggunakan bursting untuk pengoptimalan biaya, pantau metrik persentase kredit untuk mengidentifikasi peluang pengoptimalan lebih lanjut.

• Perspektif OS tamu mewakili metrik yang akan dilihat operator beban kerja, terlepas dari teknologi disk yang mendasar. Wawasan VM direkomendasikan untuk metrik utama pada disk yang terpasang, seperti ruang disk logis yang digunakan, dan perspektif kernel OS pada IOPS disk dan throughput.

Pemantauan tingkat aplikasi

Meskipun implementasi referensi tidak menggunakannya, Application Insights disediakan sebagai Manajemen Performa Aplikasi (APM) untuk tujuan ekstensibilitas. Application Insights mengumpulkan data dari aplikasi dan mengirim data tersebut ke ruang kerja Analitik Log. Ini juga dapat memvisualisasikan data tersebut dari aplikasi beban kerja.

Ekstensi kesehatan aplikasi disebarkan ke VM untuk memantau status kesehatan biner dari setiap instans VM dalam set skala, dan melakukan perbaikan instans jika perlu dengan menggunakan perbaikan instans otomatis set skala. Ini menguji file yang sama dengan Application Gateway dan pemeriksaan kesehatan penyeimbang beban Azure internal untuk memeriksa apakah aplikasi responsif.

Manajemen pembaruan

VM perlu diperbarui dan di-patch secara teratur sehingga tidak melemahkan postur keamanan beban kerja. Kami merekomendasikan penilaian VM otomatis dan berkala untuk penemuan awal dan penerapan patch.

Pembaruan infrastruktur

Azure memperbarui platformnya secara berkala untuk meningkatkan keandalan, performa, dan keamanan infrastruktur host untuk komputer virtual. Pembaruan ini termasuk patching komponen perangkat lunak di lingkungan hosting, meningkatkan komponen jaringan atau menonaktifkan perangkat keras, dan banyak lagi. Untuk informasi tentang proses pembaruan, lihat Pemeliharaan untuk komputer virtual di Azure.

Jika pembaruan tidak memerlukan boot ulang, VM dijeda saat host diperbarui, atau VM dimigrasikan langsung ke host yang sudah diperbarui. Jika pemeliharaan memerlukan boot ulang, Anda akan diberi tahu tentang pemeliharaan terencana. Azure juga menyediakan jendela waktu di mana Anda dapat memulai pemeliharaan, sesuka Anda. Untuk informasi tentang jendela pemeliharaan mandiri dan cara mengonfigurasi opsi yang tersedia, lihat Menangani pemberitahuan pemeliharaan terencana.

Beberapa beban kerja mungkin tidak mentolerir bahkan beberapa detik pembekuan atau pemutusan VM untuk pemeliharaan. Untuk kontrol yang lebih besar atas semua aktivitas pemeliharaan, termasuk pembaruan tanpa dampak dan reboot, lihat Konfigurasi Pemeliharaan. Membuat Konfigurasi Pemeliharaan memberi Anda opsi untuk melewati semua pembaruan platform dan menerapkan pembaruan sesuai keinginan Anda. Saat konfigurasi kustom ini diatur, Azure melewati semua pembaruan yang tidak berdampak nol, termasuk pembaruan tanpa boot ulang. Untuk informasi selengkapnya, lihat Mengelola pembaruan platform dengan Konfigurasi Pemeliharaan

Peningkatan gambar sistem operasi (OS)

Saat melakukan peningkatan OS, memiliki gambar emas yang diuji. Pertimbangkan untuk menggunakan Azure Shared Image Gallery dan Azure Compute Gallery untuk menerbitkan gambar kustom Anda. Anda harus memiliki proses yang meningkatkan batch instans secara bergulir setiap kali gambar baru diterbitkan oleh penerbit.

Hentikan gambar VM sebelum mencapai akhir masa pakainya untuk mengurangi area permukaan.

Proses otomatisasi Anda harus memperhitungkan provisi berlebih dengan kapasitas tambahan.

Anda dapat menggunakan Manajemen Pembaruan Azure untuk mengelola pembaruan OS untuk komputer virtual Windows dan Linux Anda di Azure.Azure Update Manager menyediakan solusi SaaS untuk mengelola dan mengatur pembaruan perangkat lunak ke komputer Windows dan Linux di seluruh lingkungan Azure, lokal, dan multicloud.

Patching OS tamu

Azure VM menyediakan opsi patching tamu VM otomatis. Ketika layanan ini diaktifkan, VM dievaluasi secara berkala dan patch yang tersedia diklasifikasikan. Disarankan agar Mode Penilaian diaktifkan untuk memungkinkan evaluasi harian untuk patch yang tertunda. Namun, penilaian sesuai permintaan dapat dilakukan, yang tidak memicu penerapan patch. Jika Mode Penilaian tidak diaktifkan, memiliki cara manual untuk mendeteksi pembaruan yang tertunda.

Hanya patch yang diklasifikasikan sebagai kritis atau keamanan yang diterapkan secara otomatis di semua wilayah Azure. Tentukan proses manajemen pembaruan kustom yang menerapkan patch lain.

Untuk tata kelola, pertimbangkan Perlu patching gambar OS otomatis pada Azure Policy Set Skala Komputer Virtual.

Patching otomatis dapat menempatkan beban pada sistem dan dapat mengganggu karena VM menggunakan sumber daya dan dapat di-boot ulang selama pembaruan. Provisi berlebihan direkomendasikan untuk manajemen beban. Sebarkan VM di Zona Ketersediaan yang berbeda untuk menghindari pembaruan bersamaan dan mempertahankan setidaknya dua instans per zona untuk ketersediaan tinggi. VM di wilayah yang sama mungkin menerima patch yang berbeda, yang harus direkonsiliasi dari waktu ke waktu.

Waspadai tradeoff pada biaya yang terkait dengan provisi berlebih.

Pemeriksaan kesehatan disertakan sebagai bagian dari patching tamu VM otomatis. Pemeriksaan ini memverifikasi aplikasi patch yang berhasil dan mendeteksi masalah.

Jika ada proses kustom untuk menerapkan patch, gunakan repositori privat untuk sumber patch. Melakukannya memberi Anda kontrol yang lebih baik dalam menguji patch untuk memastikan pembaruan tidak berdampak negatif pada performa atau keamanan.

Untuk informasi selengkapnya, lihat Patching tamu VM otomatis untuk Azure VM.

Keandalan

Arsitektur ini menggunakan zona ketersediaan sebagai elemen dasar untuk mengatasi masalah keandalan.

Dalam penyiapan ini, masing-masing VM terikat dengan satu zona. Jika kegagalan terjadi, VM ini dapat dengan mudah diganti dengan instans VM lain dengan menggunakan Virtual Machine Scale Sets.

Semua komponen lain dalam arsitektur ini adalah:

• Redundansi zona, yang berarti direplikasi di beberapa zona untuk ketersediaan tinggi, seperti Application Gateway atau IP publik.
• Ketahanan zona, menyiratkan mereka dapat menahan kegagalan zona, seperti Key Vault.
• Sumber daya regional atau global yang tersedia di seluruh wilayah atau secara global, seperti ID Microsoft Entra.

Desain beban kerja harus menggabungkan jaminan keandalan dalam kode aplikasi, infrastruktur, dan operasi. Bagian berikut mengilustrasikan beberapa strategi untuk memastikan beban kerja tahan terhadap kegagalan dan dapat pulih jika ada pemadaman di tingkat infrastruktur.

Strategi yang digunakan dalam arsitektur didasarkan pada daftar periksa tinjauan desain Keandalan yang diberikan dalam Azure Well-Architected Framework. Bagian diannotasi dengan rekomendasi dari daftar periksa tersebut.

Karena tidak ada aplikasi yang disebarkan, ketahanan dalam kode aplikasi berada di luar cakupan arsitektur ini. Kami menyarankan agar Anda meninjau semua rekomendasi dalam daftar periksa dan mengadopsinya dalam beban kerja Anda, jika berlaku.

Memprioritaskan jaminan keandalan per alur pengguna

Dalam sebagian besar desain, ada beberapa alur pengguna, masing-masing dengan serangkaian persyaratan bisnisnya sendiri. Tidak semua alur ini memerlukan tingkat jaminan tertinggi, sehingga segmentasi direkomendasikan sebagai strategi keandalan. Setiap segmen dapat dikelola secara independen, memastikan bahwa satu segmen tidak berdampak pada yang lain dan memberikan tingkat ketahanan yang tepat di setiap tingkatan. Pendekatan ini juga membuat sistem fleksibel.

Dalam arsitektur ini, tingkat aplikasi mengimplementasikan segmentasi. Set skala terpisah disediakan untuk tingkat front-end dan back-end. Pemisahan ini memungkinkan penskalaan independen dari setiap tingkatan, memungkinkan implementasi pola desain berdasarkan persyaratan spesifiknya, di antara manfaat lainnya.

Lihat Well-Architected Framework: RE:02 - Rekomendasi untuk mengidentifikasi dan memberi peringkat alur.

Mengidentifikasi titik kegagalan potensial

Setiap arsitektur rentan terhadap kegagalan. Latihan analisis mode kegagalan memungkinkan Anda mengantisipasi kegagalan dan bersiap dengan mitigasi. Berikut adalah beberapa titik kegagalan potensial dalam arsitektur ini:

Komponen	Risiko	Kecenderungan	Efek/Mitigasi/Catatan	Penghentian
Microsoft Entra ID	Salah konfigurasi	Medium	Pengguna Ops tidak dapat masuk. Tidak ada efek hilir. Staf dukungan melaporkan masalah konfigurasi ke tim identitas.	Tidak
Application Gateway	Salah konfigurasi	Medium	Kesalahan konfigurasi harus ditangkap selama penyebaran. Jika kesalahan ini terjadi selama pembaruan konfigurasi, tim DevOps harus mengembalikan perubahan. Sebagian besar penyebaran yang menggunakan SKU v2 membutuhkan waktu sekitar 6 menit untuk diprovisikan. Namun itu bisa memakan waktu lebih lama tergantung jenis penyebaran. Misalnya, penyebaran di beberapa zona ketersediaan dengan banyak instans dapat memakan waktu lebih dari 6 menit.	Penuh
Application Gateway	Serangan DDoS	Medium	Potensi gangguan. Microsoft mengelola perlindungan DDoS (L3 dan L4). Potensi risiko efek dari serangan L7.	Penuh
Virtual Machine Scale Sets	Pemadaman layanan	Kurang Penting	Potensi pemadaman beban kerja jika ada instans VM yang tidak sehat yang memicu autorepair. Bergantung pada Microsoft untuk memulihkan.	Potensi pemadaman
Virtual Machine Scale Sets	Pemadaman zona ketersediaan	Kurang Penting	Tidak ada efek. Set skala disebarkan sebagai zona redundan.	Tidak

Lihat Well-Architected Framework: RE:03 - Rekomendasi untuk melakukan analisis mode kegagalan.

Target keandalan

Untuk membuat keputusan desain, penting untuk menghitung target keandalan, seperti tujuan tingkat layanan komposit (SLO) beban kerja. Melakukannya melibatkan pemahaman perjanjian tingkat layanan (SLA) yang disediakan oleh layanan Azure yang digunakan dalam arsitektur. SLA beban kerja tidak boleh lebih tinggi dari SLA yang dijamin oleh Azure. Periksa dengan cermat setiap komponen, dari VM dan dependensi, jaringan, dan opsi penyimpanannya.

Berikut adalah contoh perhitungan di mana tujuan utamanya adalah untuk memberikan perkiraan SLO komposit. Meskipun ini adalah pedoman kasar, Anda harus tiba pada sesuatu yang serupa. Anda tidak boleh mendapatkan SLO komposit maksimum yang lebih tinggi untuk alur yang sama kecuali Anda membuat modifikasi pada arsitektur.

Alur operasi

Komponen	SLO
Microsoft Entra ID	99,99%
Azure Bastion	99,95%

SLO Komposit: 99,94% | Waktu henti per tahun: 0d 5h 15m 20s

Alur pengguna aplikasi

Komponen	SLO
Application Gateway	99,95%
Azure Load Balancer (internal)	99,99%
VM front-end menggunakan penyimpanan premium (SLO komposit)	99,70%
VM back-end menggunakan penyimpanan premium (SLO komposit)	99,70%

SLO Komposit: 99,34% | Waktu henti per tahun: 2d 9h 42m 18s

Dalam contoh sebelumnya, keandalan VM dan dependensi disertakan, seperti disk yang terkait dengan VM. SLA yang terkait dengan penyimpanan disk memengaruhi keandalan keseluruhan.

Ada beberapa tantangan saat menghitung SLO komposit. Penting untuk dicatat bahwa berbagai tingkat layanan mungkin datang dengan SLA yang berbeda, dan sering kali termasuk jaminan yang didukung secara finansial yang menetapkan target keandalan. Terakhir, mungkin ada komponen arsitektur yang tidak memiliki SLA yang ditentukan. Misalnya, dalam hal jaringan, NIC, dan jaringan virtual tidak memiliki SLA mereka sendiri.

Persyaratan bisnis dan targetnya harus didefinisikan dengan jelas dan diperhitungkan dalam perhitungan. Ketahui batas layanan dan batasan lain yang diberlakukan oleh organisasi. Berbagi langganan Anda dengan beban kerja lain dapat memengaruhi sumber daya yang tersedia untuk VM Anda. Beban kerja mungkin diizinkan untuk menggunakan sejumlah inti terbatas yang tersedia untuk VM. Memahami penggunaan sumber daya langganan Anda dapat membantu Anda merancang VM secara lebih efektif.

Lihat Well-Architected Framework: RE:04 - Rekomendasi untuk menentukan target keandalan.

Redundansi geografis

Arsitektur ini menggunakan zona-redundansi untuk beberapa komponen. Setiap zona terdiri dari satu atau lebih pusat data dengan daya, pendinginan, dan jaringan independen. Memiliki instans yang berjalan di zona terpisah melindungi aplikasi dari kegagalan pusat data.

• Virtual Machine Scale Sets mengalokasikan sejumlah instans tertentu dan mendistribusikannya secara merata di seluruh zona ketersediaan dan domain kesalahan. Distribusi ini dicapai melalui kemampuan penyebaran maksimum, yang kami sarankan. Menyebarkan instans VM di seluruh domain kesalahan memastikan semua VM tidak diperbarui secara bersamaan.

  Pertimbangkan skenario di mana ada tiga zona ketersediaan. Jika Anda memiliki tiga instans, setiap instans dialokasikan ke zona ketersediaan yang berbeda dan ditempatkan di domain kesalahan yang berbeda. Azure menjamin bahwa hanya satu domain kesalahan yang diperbarui pada satu waktu di setiap zona ketersediaan. Namun, mungkin ada situasi di mana ketiga domain kesalahan yang menghosting VM Anda di tiga zona ketersediaan diperbarui secara bersamaan. Semua zona dan domain terpengaruh. Memiliki setidaknya dua instans di setiap zona menyediakan buffer selama peningkatan.

• Disk terkelola hanya dapat dilampirkan ke VM di wilayah yang sama. Ketersediaannya biasanya berdampak pada ketersediaan VM. Untuk penyebaran wilayah tunggal, disk dapat dikonfigurasi untuk redundansi untuk menahan kegagalan zonal. Dalam arsitektur ini, disk data dikonfigurasi penyimpanan zona redundan (ZRS) pada VM back-end. Ini membutuhkan strategi pemulihan untuk memanfaatkan zona ketersediaan. Strategi pemulihan adalah menyebarkan ulang solusi. Idealnya komputasi pra-provisi di zona ketersediaan alternatif siap pulih dari kegagalan zonal.

• Application Gateway zona-redundan atau load balancer standar dapat merutekan lalu lintas ke VM di seluruh zona menggunakan satu alamat IP, memastikan kelangsungan bahkan jika kegagalan zona terjadi. Layanan ini menggunakan pemeriksaan kesehatan untuk memeriksa ketersediaan VM. Selama satu zona di wilayah tersebut tetap beroperasi, perutean berlanjut meskipun ada potensi kegagalan di zona lain. Namun, perutean antar-zona mungkin memiliki latensi yang lebih tinggi dibandingkan dengan perutean intra-zona.

  Semua IP publik yang digunakan dalam arsitektur ini adalah zona redundan.

• Azure menawarkan layanan tangguh zona untuk keandalan yang lebih baik, seperti Key Vault.

• Sumber daya global Azure selalu tersedia dan dapat beralih ke wilayah lain jika perlu, seperti idP dasar, ID Microsoft Entra.

Lihat Well-Architected Framework: RE:05 - Rekomendasi untuk merancang redundansi.

Strategi penskalakan

Untuk mencegah degradasi dan kegagalan tingkat layanan, pastikan operasi penskalaan yang andal. Skalakan beban kerja secara horizontal (peluasan skala), secara vertikal (tingkatkan), atau gunakan kombinasi kedua pendekatan tersebut. Gunakan Azure Monitor Autoscale untuk menyediakan sumber daya yang cukup untuk mendukung permintaan pada aplikasi Anda tanpa mengalokasikan lebih banyak kapasitas daripada yang diperlukan dan menimbulkan biaya yang tidak perlu.

Skala otomatis memungkinkan Anda menentukan profil yang berbeda berdasarkan jenis peristiwa yang berbeda, seperti waktu, jadwal, atau metrik. Profil berbasis metrik dapat menggunakan metrik bawaan (berbasis host) atau metrik yang lebih rinci (metrik VM dalam tamu) yang mengharuskan penginstalan Agen Azure Monitor untuk mengumpulkannya. Setiap profil berisi aturan untuk peluasan skala (peningkatan) dan penyempurnaan skala (penurunan). Pertimbangkan untuk menjelajahi semua skenario penskalaan yang berbeda berdasarkan profil yang dirancang dan mengevaluasinya untuk kondisi perulangan potensial yang dapat menyebabkan serangkaian peristiwa skala yang berlawanan. Azure Monitor akan mencoba mengurangi situasi ini dengan menunggu periode pendinginan sebelum diskalakan lagi.

Meskipun Azure Virtual Machine Scale Sets dalam mode Fleksibel mendukung lingkungan heterogen, penskalaan otomatis beberapa profil tidak didukung. Pertimbangkan untuk membuat set skala yang berbeda untuk mengelolanya secara terpisah jika Anda berencana menggunakan skala otomatis dengan lebih dari satu jenis VM.

Pertimbangkan aspek lain seperti bootstrapping, pematian yang anggun, menginstal beban kerja dan semua dependensinya, dan manajemen disk saat membuat atau menghapus instans VM.

Beban kerja stateful mungkin memerlukan manajemen ekstra untuk disk terkelola yang perlu hidup di luar instans beban kerja. Rancang beban kerja Anda untuk manajemen data di bawah peristiwa penskalaan untuk konsistensi, sinkronisasi, replikasi, dan integritas data beban kerja. Untuk skenario tersebut, pertimbangkan untuk menambahkan disk yang telah diisi sebelumnya ke set skala. Untuk kasus penggunaan di mana penskalaan digunakan untuk mencegah hambatan saat mengakses data, rencanakan untuk partisi dan sharding. Untuk informasi selengkapnya, lihat Praktik terbaik skala otomatis.

Lihat Well-Architected Framework: RE:06 - Rekomendasi untuk merancang strategi penskalaan yang andal.

Pemulihan dan pemulihan mandiri

Perbaikan instans otomatis diaktifkan di Virtual Machine Scale Sets untuk mengotomatiskan pemulihan dari kegagalan VM. Ekstensi kesehatan aplikasi disebarkan ke VM untuk mendukung deteksi VM dan aplikasi yang tidak responsif. Untuk instans tersebut, tindakan perbaikan secara otomatis dipicu.

Lihat Kerangka Kerja Yang Dirancang Dengan Baik: Rekomendasi untuk penyembuhan diri dan pelestarian diri.

Keamanan

Arsitektur ini menggambarkan beberapa jaminan keamanan yang diberikan dalam daftar periksa tinjauan desain keamanan yang diberikan dalam Azure Well-Architected Framework. Bagian diannotasi dengan rekomendasi dari daftar periksa tersebut.

Keamanan tidak hanya merujuk ke kontrol teknis. Kami menyarankan agar Anda mengikuti seluruh daftar periksa untuk memahami aspek operasional pilar Keamanan.

Segmentasi

• Segmentasi jaringan. Sumber daya beban kerja ditempatkan dalam jaringan virtual, yang menyediakan isolasi dari internet. Dalam jaringan virtual, subnet dapat digunakan sebagai batas kepercayaan. Kolokasikan sumber daya terkait yang diperlukan untuk menangani transaksi dalam satu subnet. Dalam arsitektur ini, jaringan virtual dibagi menjadi subnet berdasarkan pengelompokan logis aplikasi dan tujuan berbagai layanan Azure yang digunakan sebagai bagian dari beban kerja.

  Keuntungan dari segmentasi subnet adalah Anda dapat menempatkan kontrol keamanan di perimeter yang mengontrol lalu lintas yang mengalir masuk dan keluar dari subnet, sehingga membatasi akses ke sumber daya beban kerja.

• Segmentasi identitas. Tetapkan peran yang berbeda ke identitas yang berbeda dengan izin yang cukup untuk melakukan tugas mereka. Arsitektur ini menggunakan identitas yang dikelola oleh ID Microsoft Entra untuk mengesegmentasi akses ke sumber daya.

• Segmentasi sumber daya. Aplikasi ini disegmentasi oleh tingkatan ke dalam set skala terpisah, yang memastikan bahwa komponen aplikasi tidak dikolokasikan.

Lihat Well-Architected Framework: SE:04 - Rekomendasi untuk membangun strategi segmentasi.

Pengelolaan identitas dan akses

Kami merekomendasikan ID Microsoft Entra untuk autentikasi dan otorisasi pengguna dan layanan.

Akses ke VM memerlukan akun pengguna, yang dikontrol oleh autentikasi ID Microsoft Entra dan didukung oleh grup keamanan. Arsitektur ini menyediakan dukungan dengan menyebarkan ekstensi autentikasi ID Microsoft Entra ke semua VM. Kami menyarankan agar pengguna manusia menggunakan identitas perusahaan mereka di penyewa ID Microsoft Entra organisasi mereka. Selain itu, pastikan bahwa setiap akses berbasis perwakilan layanan tidak dibagikan di seluruh fungsi.

Sumber daya beban kerja, seperti VM, mengautentikasi diri mereka sendiri dengan menggunakan identitas terkelola yang ditetapkan ke sumber daya lain. Identitas ini, berdasarkan perwakilan layanan ID Microsoft Entra, dikelola secara otomatis.

Misalnya, ekstensi Key Vault diinstal pada VM, yang mem-boot VM dengan sertifikat di tempat. Dalam arsitektur ini, identitas terkelola yang ditetapkan pengguna digunakan oleh Application Gateway, VM front-end, dan VM back-end untuk mengakses Key Vault. Identitas terkelola tersebut dikonfigurasi selama penyebaran dan digunakan untuk mengautentikasi terhadap Key Vault. Kebijakan akses pada Key Vault dikonfigurasi untuk hanya menerima permintaan dari identitas terkelola sebelumnya.

Arsitektur garis besar menggunakan campuran identitas terkelola yang ditetapkan sistem dan ditetapkan pengguna. Identitas ini diperlukan untuk menggunakan ID Microsoft Entra untuk tujuan otorisasi saat mengakses sumber daya Azure lainnya.

Lihat Well-Architected Framework: SE:05 - Rekomendasi untuk manajemen identitas dan akses.

Kontrol jaringan

• Lalu lintas ingress. VM beban kerja tidak secara langsung terekspos ke internet publik. Setiap VM memiliki alamat IP privat. Pengguna beban kerja tersambung menggunakan alamat IP publik Application Gateway.

  Keamanan lainnya disediakan melalui Web Application Firewall yang terintegrasi dengan Application Gateway. Ini memiliki aturan yang memeriksa lalu lintas masuk dan dapat mengambil tindakan yang sesuai. WAF melacak kerentanan Open Web Application Security Project (OWASP) yang mencegah serangan yang diketahui.

• Lalu Lintas Egress. Tidak ada kontrol pada lalu lintas keluar kecuali aturan NSG keluar pada subnet VM. Kami menyarankan agar semua lalu lintas internet keluar mengalir melalui satu firewall. Firewall ini biasanya merupakan layanan pusat yang disediakan oleh organisasi. Kasus penggunaan tersebut ditampilkan dalam arsitektur garis besar komputer virtual di zona pendaratan Azure.

• Lalu lintas timur-barat. Arus lalu lintas antara subnet dibatasi dengan menerapkan aturan keamanan terperinci.

  Kelompok keamanan jaringan (NSG) ditempatkan untuk membatasi lalu lintas antar subnet berdasarkan parameter seperti rentang alamat IP, port, dan protokol. Kelompok keamanan aplikasi (ASG) ditempatkan pada VM front-end dan back-end. Mereka digunakan dengan NSG untuk memfilter lalu lintas ke dan dari VM.

• Lalu lintas operasional. Kami menyarankan agar akses operasional yang aman ke beban kerja disediakan melalui Azure Bastion, yang menghapus kebutuhan akan IP publik. Dalam arsitektur ini, komunikasi tersebut melalui SSH dan didukung oleh VM Windows dan Linux. MICROSOFT Entra ID terintegrasi dengan SSH untuk kedua jenis VM dengan menggunakan ekstensi VM yang sesuai. Integrasi tersebut memungkinkan identitas operator diautentikasi dan diotorisasi melalui ID Microsoft Entra.

  Atau, gunakan VM terpisah sebagai jump box, yang disebarkan ke subnetnya sendiri, tempat Anda dapat menginstal pilihan admin dan alat pemecahan masalah Anda. Operator mengakses jump box melalui host Azure Bastion. Kemudian, mereka masuk ke VM di belakang load balancer dari jump box.

  Dalam arsitektur ini, lalu lintas operasional dilindungi menggunakan aturan NSG untuk membatasi lalu lintas, dan akses VM just-in-time (JIT) diaktifkan pada VM. Fitur Microsoft Defender untuk Cloud ini memungkinkan akses masuk sementara ke port yang dipilih.

  Untuk keamanan yang ditingkatkan, gunakan Microsoft Entra Privileged Identity Management (PIM). PIM adalah layanan di ID Microsoft Entra yang memungkinkan Anda mengelola, mengontrol, dan memantau akses ke sumber daya penting di organisasi Anda. PIM menyediakan aktivasi peran berbasis waktu dan persetujuan untuk mengurangi risiko izin akses yang berlebihan, tidak perlu, atau disalahgunakan pada sumber daya yang penting bagi Anda.

• Konektivitas privat ke layanan platform as a service (PaaS). Komunikasi antara VM dan Key Vault melalui Private Link. Layanan ini memerlukan titik akhir privat, yang ditempatkan di subnet terpisah.

• Proteksi DDoS. Pertimbangkan untuk mengaktifkan Azure DDoS Protection pada IP publik yang diekspos oleh Application Gateway dan Host Azure Bastion untuk mendeteksi ancaman. DDoS Protection juga menyediakan pemberitahuan, telemetri, dan analitik melalui Monitor. Untuk informasi selengkapnya, lihat Azure DDoS Protection: Praktik terbaik dan arsitektur referensi.

Lihat Kerangka Kerja Well-Architected: SE:06 - Rekomendasi untuk jaringan dan konektivitas.

Enkripsi

• Data saat transit. Lalu lintas pengguna antara pengguna dan IP publik Application Gateway dienkripsi menggunakan sertifikat eksternal. Lalu lintas antara gateway aplikasi dan VM front-end, dan antara VM front-end dan back-end dienkripsi menggunakan sertifikat internal. Kedua sertifikat disimpan di Key Vault:

  • app.contoso.com: Sertifikat eksternal yang digunakan oleh klien dan Application Gateway untuk mengamankan lalu lintas internet publik.
  • *.workload.contoso.com: Sertifikat kartubebas yang digunakan oleh komponen infrastruktur untuk mengamankan lalu lintas internal.

• Data tidak aktif. Data log disimpan dalam disk terkelola yang dilampirkan ke VM. Data tersebut secara otomatis dienkripsi dengan menggunakan enkripsi yang disediakan platform di Azure.

Lihat Well-Architected Framework: SE:07 - Rekomendasi untuk enkripsi data.

Manajemen rahasia

Unduh file Visio arsitektur ini.

Key Vault menyediakan manajemen rahasia yang aman, termasuk sertifikat TLS. Dalam arsitektur ini, sertifikat TLS disimpan di Key Vault dan diambil selama proses provisi oleh identitas terkelola Application Gateway dan VM. Setelah penyiapan awal, sumber daya ini hanya mengakses Key Vault saat sertifikat di-refresh.

VM menggunakan ekstensi VM Key Vault untuk me-refresh sertifikat yang dipantau secara otomatis. Jika ada perubahan yang terdeteksi di penyimpanan sertifikat lokal, ekstensi mengambil dan menginstal sertifikat yang sesuai dari Key Vault. Ekstensi ini mendukung jenis konten sertifikat PKCS #12 dan PEM.

Lihat Well-Architected Framework: SE:09 - Rekomendasi untuk melindungi rahasia aplikasi.

Pengoptimalan Biaya

Persyaratan beban kerja harus dipenuhi mengingat kendala biaya. Strategi yang digunakan dalam arsitektur didasarkan pada daftar periksa tinjauan desain Pengoptimalan Biaya yang diberikan dalam Azure Well-Architected Framework. Bagian ini menjelaskan beberapa opsi untuk mengoptimalkan biaya dan diannotasikan dengan rekomendasi dari daftar periksa tersebut.

Biaya komponen

Pilih gambar VM yang dioptimalkan untuk beban kerja alih-alih menggunakan gambar tujuan umum. Dalam arsitektur ini, gambar VM yang relatif kecil dipilih untuk Windows dan Linux, yang masing-masing 30 GB. Dengan gambar yang lebih kecil, SKU VM dengan disk juga lebih kecil, yang menyebabkan biaya lebih rendah, mengurangi konsumsi sumber daya, dan waktu penyebaran dan boot yang lebih cepat. Manfaatnya adalah keamanan yang ditingkatkan karena area permukaan yang berkurang.

Menerapkan rotasi log dengan batas ukuran adalah strategi penghematan biaya lainnya. Ini memungkinkan penggunaan disk data kecil, yang dapat mengakibatkan biaya yang lebih rendah. Implementasi arsitektur ini menggunakan disk 4 GB.

Penggunaan disk OS Ephemeral juga dapat menyebabkan penghematan biaya dan peningkatan performa. Disk ini dirancang untuk menggunakan sumber daya VM yang sudah Anda bayar karena diinstal pada disk cache yang disediakan dengan VM. Ini menghilangkan biaya penyimpanan yang terkait dengan disk persisten tradisional. Karena disk ini bersifat sementara, tidak ada biaya yang terkait dengan penyimpanan data jangka panjang.

Lihat Well-Architected Framework: CO:07 - Rekomendasi untuk mengoptimalkan biaya komponen.

Biaya alur

Pilih sumber daya komputasi berdasarkan kekritisan alur. Untuk alur yang dirancang untuk mentolerir panjang yang tidak ditentukan, pertimbangkan untuk menggunakan VM spot dengan mode orkestrasi Fleksibel Virtual Machine Scale Sets. Pendekatan ini dapat efektif untuk menghosting alur berprioritas rendah pada VM berprioritas lebih rendah. Strategi ini memungkinkan pengoptimalan biaya sambil tetap memenuhi persyaratan alur yang berbeda.

Lihat Well-Architected Framework: CO:09 - Rekomendasi untuk mengoptimalkan biaya alur.

Biaya penskalan

Jika pendorong biaya utama adalah jumlah instans, mungkin lebih hemat biaya untuk meningkatkan skala dengan meningkatkan ukuran atau performa VM. Pendekatan ini dapat menyebabkan penghematan biaya di beberapa area:

• Lisensi perangkat lunak. VM yang lebih besar dapat menangani lebih banyak beban kerja, berpotensi mengurangi jumlah lisensi perangkat lunak yang diperlukan.
• Waktu pemeliharaan: Lebih sedikit VM yang lebih besar dapat mengurangi biaya operasional.
• Penyeimbangan beban: Lebih sedikit VM dapat mengakibatkan biaya yang lebih rendah untuk penyeimbangan beban. Misalnya, dalam arsitektur ini ada beberapa lapisan penyeimbangan beban, seperti gateway aplikasi di bagian depan dan load balancer internal di tengah. Biaya penyeimbangan beban akan meningkat jika jumlah instans yang lebih tinggi perlu dikelola.
• Penyimpanan disk. Jika ada aplikasi stateful, lebih banyak instans memerlukan disk terkelola yang lebih terpasang, meningkatkan biaya penyimpanan.

Lihat Well-Architected Framework: CO:12 - Rekomendasi untuk mengoptimalkan biaya penskalaan.

Biaya operasional

Patching tamu VM otomatis mengurangi overhead patching manual dan biaya pemeliharaan terkait. Tindakan ini tidak hanya membantu membuat sistem lebih aman, tetapi juga mengoptimalkan alokasi sumber daya, berkontribusi pada efisiensi biaya secara keseluruhan.

Lihat Well-Architected Framework: CO:13 - Rekomendasi untuk mengoptimalkan waktu personel.

Menyebarkan skenario ini

Penyebaran untuk arsitektur referensi ini tersedia di GitHub.

Sumber daya terkait

Lihat dokumentasi produk untuk detail tentang layanan Azure tertentu:

• Azure Virtual Machines
• Kumpulan Skala Komputer Virtual Azure
• Microsoft Azure Virtual Network
• Azure Application Gateway Standard_v2
• Penyeimbang Beban Azure
• Azure Key Vault
• Azure Bastion
• Application Insights
• Log Analytics

Langkah selanjutnya

Tinjau arsitektur referensi IaaS yang menampilkan opsi untuk tingkat data:

• Aplikasi N-tingkat Windows menggunakan SQL Server di Azure