Daftar periksa ketahanan untuk layanan Azure tertentu

  • Artikel

Ketahanan adalah kemampuan sistem untuk pulih dari kegagalan dan terus berfungsi. Setiap teknologi memiliki mode kegagalannya sendiri, yang harus Anda pertimbangkan saat merancang dan mengimplementasikan aplikasi Anda. Gunakan daftar periksa ini untuk meninjau pertimbangan ketahanan untuk layanan Azure tertentu. Untuk informasi selengkapnya tentang membangun aplikasi yang andal, lihat Mendesain aplikasi Azure yang andal.

App Service

Gunakan tingkat Standar atau Premium. Tingkatan ini mendukung slot peyiimpanan dan pencadangan otomatis. Untuk mengetahui informasi selengkapnya, lihat Gambaran umum paket Azure App Service

Hindari peningkatan atau penurunan skala. Sebagai gantinya, pilih tingkat dan ukuran instance yang memenuhi persyaratan performa Anda di bawah beban biasa, lalu luaskan skala instance untuk menangani perubahan volume lalu lintas. Peningkatan dan penurunan skala dapat memicu penghidupan ulang aplikasi.

Simpan konfigurasi sebagai pengaturan aplikasi. Gunakan pengaturan aplikasi untuk menahan pengaturan konfigurasi sebagai pengaturan aplikasi. Tentukan pengaturan di templat Azure Resource Manager Anda, atau menggunakan PowerShell, sehingga Anda dapat menerapkannya sebagai bagian dari penyebaran otomatis / proses pembaruan, yang lebih dapat diandalkan. Untuk informasi selengkapnya, lihat Mengonfigurasi aplikasi web di Azure App Service.

Buat paket Azure App Service untuk produksi dan pengujian. Jangan gunakan slot pada penerapan produksi Anda untuk pengujian. Semua aplikasi dalam paket Azure App Service yang sama membagikan contoh VM yang sama. Jika Anda menempatkan produksi dan pengujian penempatan dalam rencana yang sama, hal ini akan berdampak negatif pada penempatan produksi. Misalnya, pengujian beban dapat menurunkan situs produksi langsung. Dengan menempatkan penyebaran pengujian ke dalam paket terpisah, Anda memisahkannya dari versi produksi.

Pisahkan aplikasi web dari API web. Jika solusi Anda memiliki web front end dan web API, pertimbangkan untuk menguraikannya menjadi aplikasi App Service yang terpisah. Desain ini memudahkan untuk menguraikan solusi dengan beban kerja. Anda dapat menjalankan aplikasi web dan API dalam paket App Service terpisah, sehingga dapat diskalakan secara independen. Jika Anda tidak memerlukan tingkat skalabilitas tersebut pada awalnya, Anda dapat menerapkan aplikasi ke dalam paket yang sama, dan memindahkannya ke paket terpisah nanti, jika diperlukan.

Menyebarkan paket App Service zona-redundan. Di wilayah yang didukung, paket App Service dapat disebarkan sebagai zona redundan, yang berarti bahwa instans didistribusikan secara otomatis di seluruh zona ketersediaan. App Service secara otomatis mendistribusikan lalu lintas antar zona, dan menangani failover jika zona mengalami pemadaman. Untuk informasi selengkapnya, lihat Memigrasikan App Service ke dukungan zona ketersediaan.

Hindari menggunakan fitur cadangan App Service untuk mencadangkan database Azure SQL. Sebaliknya, gunakan cadangan otomatis Azure SQL Database. Cadangan App Service mengekspor database ke file BACPAC SQL, dengan biaya DTU.

Sebarkan ke slot penahapan. Buat slot penerapan untuk pementasan. Terapkan pembaruan aplikasi ke slot staging, dan verifikasi penerapan sebelum menukarnya ke produksi. Hal ini mengurangi kemungkinan pembaruan yang buruk dalam produksi. Hal ini juga memastikan bahwa semua instans dihangatkan sebelum ditukar ke produksi. Banyak aplikasi memiliki pemanasan yang signifikan dan waktu awal yang dingin. Untuk informasi selengkapnya, lihat menyiapkan lingkungan staging untuk aplikasi web di Azure App Service.

Buat slot penerapan untuk menampung penerapan last-known-good (LKG). Saat Anda menerapkan pembaruan ke produksi, pindahkan penerapan produksi sebelumnya ke dalam slot LKG. Hal ini membuatnya lebih mudah untuk memutar kembali penyebaran yang buruk. Jika Anda menemukan masalah nantinya, Anda dapat dengan cepat kembali ke versi LKG. Untuk informasi selengkapnya, lihat Aplikasi web dasar.

Aktifkan logging diagnostik, termasuk logging aplikasi dan logging server web. Pencatatan log penting untuk pemantauan dan diagnostik. Lihat Mengaktifkan diagnostik logging untuk aplikasi web di Azure App Service

Masuk ke penyimpanan blob. Hal ini membuatnya lebih mudah untuk mengumpulkan dan menganalisis data.

Buat akun penyimpanan terpisah untuk log. Jangan menggunakan akun penyimpanan yang sama untuk log dan data aplikasi. Hal ini membantu mencegah logging mengurangi performa aplikasi.

Memantau performa. Menggunakan layanan pemantauan performa seperti Application Insights atau New Relic untuk memantau performa dan perilaku aplikasi dibawah beban. Pemantauan performa memberi Anda wawasan real time dalam aplikasi. Ini memungkinkan Anda untuk mendiagnosis masalah dan melakukan analisis akar penyebab kegagalan.

Penyeimbang Beban Azure

Pilih SKU Standar. Load Balancer Standar menyediakan dimensi keandalan yang tidak dilakukan Dasar - yaitu zona ketersediaan dan ketahanan zona. Hal ini berarti ketika zona turun, Standard Load Balancer zona Anda yang berlebihan tidak akan terpengaruh. Hal ini memastikan penerapan Anda dapat bertahan dari kegagalan zona dalam suatu wilayah. Selain itu, Load Balancer Standar mendukung penyeimbangan beban global yang memastikan aplikasi Anda juga tidak terpengaruh oleh kegagalan wilayah.

Menyediakan setidaknya dua contoh. Sebarkan Azure LB dengan setidaknya dua instans di backend. Satu kejadian bisa mengakibatkan satu titik kegagalan. Untuk membangun skala, Anda mungkin ingin memasangkan LB dengan Microsoft Azure Virtual Machine Scale Sets.

Gunakan aturan keluar. Aturan keluar memastikan bahwa Anda tidak dihadapkan dengan kegagalan koneksi sebagai akibat dari kelelahan port SNAT. Pelajari lebih lanjut tentang konektivitas keluar. Sementara aturan keluar akan membantu meningkatkan solusi untuk penyebaran ukuran kecil hingga menengah, untuk beban kerja produksi, kami sarankan menggabungkan Standard Load Balancer atau penyebaran subnet apa pun dengan VNet NAT.

Application Gateway

Menyediakan setidaknya dua contoh. Terapkan Application Gateway dengan setidaknya dua instans. Satu contoh adalah satu titik kegagalan. Gunakan dua atau lebih instans untuk redundansi dan skalabilitas. Agar memenuhi syarat untuk SLA, Anda harus menyediakan dua atau lebih instans menengah atau lebih besar.

Azure Cosmos DB

Mengonfigurasi redundansi zona. Saat Anda menggunakan redundansi zona, Azure Cosmos DB secara sinkron mereplikasi semua penulisan di seluruh zona ketersediaan. Ini secara otomatis gagal jika terjadi pemadaman zona. Untuk informasi selengkapnya, lihat Mencapai ketersediaan tinggi dengan Azure Cosmos DB.

Mereplikasi database di seluruh wilayah. Azure Cosmos DB memungkinkan Anda mengaitkan sejumlah wilayah Azure dengan akun database Azure Cosmos DB. Database Azure Cosmos DB dapat memiliki satu wilayah tulis dan beberapa wilayah baca. Jika terjadi kegagalan dalam wilayah penulisan, Anda dapat membaca dari replika lain. SDK Klien menangani ini secara otomatis. Anda juga dapat gagal melewati wilayah tulis ke wilayah lain. Untuk informasi selengkapnya, lihat Cara mendistribusikan data secara global dengan Azure Cosmos DB.

Event Hubs

Gunakan titik pemeriksaan. Konsumen acara harus menulis posisinya saat ini ke penyimpanan persisten pada beberapa interval yang telah ditentukan. Dengan begitu, jika konsumen mengalami kesalahan (misalnya, konsumen mogok, atau host gagal), maka instans baru dapat melanjutkan membaca aliran dari posisi terakhir yang direkam. Untuk informasi selengkapnya, lihat Konsumen acara.

Tangani pesan duplikat. Jika konsumen acara gagal, pemrosesan pesan dilanjutkan dari pos pemeriksaan terakhir yang direkam. Pesan apa pun yang sudah diproses setelah pos pemeriksaan terakhir akan diproses lagi. Oleh karena itu, logika pemrosesan pesan Anda harus idempoten, atau aplikasi harus dapat menghapus duplikat pesan.

Menangani pengecualian. Konsumen kejadian biasanya memproses sekumpulan pesan dalam satu loop. Anda harus menangani pengecualian dalam loop pemrosesan ini untuk menghindari kehilangan seluruh batch pesan jika satu pesan menyebabkan pengecualian.

Gunakan antrean surat mati. Jika pemprosesan pesan mengakibatkan kegagalan yang tidak transparan, masukkan pesan ke antrean surat mati, sehingga Anda dapat melacak status. Bergantung pada skenario, Anda mungkin mencoba lagi pesan nanti, menerapkan transaksi kompensasi, atau mengambil tindakan lain. Perhatikan bahwa Azure Event Hubs tidak memiliki fungsi antrean surat mati bawaan. Anda dapat menggunakan Azure Queue Storage atau Service Bus untuk mengimplementasikan antrian dead-letter, atau menggunakan Azure Functions atau mekanisme kejadian lainnya.

Mengonfigurasi redundansi zona. Saat redundansi zona diaktifkan di namespace Layanan Anda, Azure Event Hubs secara otomatis mereplikasi perubahan di antara beberapa zona ketersediaan. Jika satu zona ketersediaan gagal, failover terjadi secara otomatis. Untuk informasi selengkapnya, lihat Zona ketersediaan.

Terapkan pemulihan bencana dengan mengalihkan ke namespace Azure Event Hubs sekunder. Untuk informasi selengkapnya, lihat Azure Event Hubs- Pemulihan Bencana Geo.

Azure Cache untuk Redis

Mengonfigurasi redundansi zona. Saat redundansi zona diaktifkan di cache Anda, Azure Cache for Redis menyebarkan komputer virtual yang menghosting cache Anda di beberapa zona ketersediaan. Redundansi zona memberikan ketersediaan tinggi dan toleransi kesalahan jika terjadi pemadaman pusat data. Untuk informasi selengkapnya, lihat Mengaktifkan redundansi zona untuk Azure Cache for Redis.

Mengonfigurasi replikasi geografis. Replikasi geografis menyediakan mekanisme untuk menautkan dua instans Azure Cache for Redis tingkat Premium. Data yang ditulis ke cache utama direplikasi ke cach baca-saja sekunder. Untuk informasi dan petunjuk selengkapnya, lihat Cara mengonfigurasi replikasi geografis untuk Azure Cache for Redis

Mengkonfigurasikan persistensi data. Persistensi Redis mengizinkan Anda untuk menyimpan data yang disimpan di Redis. Anda juga dapat mengambil rekam jepret dan mencadangkan data, yang dapat Anda muat jika terjadi kegagalan perangkat keras. Untuk informasi selengkapnya, lihat Cara mengonfigurasi persistensi data untuk Azure Cache for Redis Premium

Jika Anda menggunakan Azure Cache for Redis sebagai cache data sementara dan bukan sebagai penyimpanan persisten, rekomendasi ini mungkin tidak berlaku.

Sediakan lebih dari satu replika. Gunakan setidaknya dua replika untuk dibaca ketersediaan tinggi, atau tiga untuk baca-tulis ketersediaan tinggi.

Gunakan redundansi zona. Anda dapat menyebarkan replika Cognitive Search di beberapa zona ketersediaan. Pendekatan ini membantu layanan Anda untuk tetap beroperasi bahkan ketika pemadaman pusat data terjadi. Untuk informasi selengkapnya, lihat Keandalan di Azure Cognitive Search

Mengkonfigurasikan pengindeks untuk penyebaran multi-wilayah. Jika Anda memiliki penerapan multi-wilayah, pertimbangkan keberlangsungan pengindeksan pada opsi Anda.

  • Jika sumber data direplikasi secara geografis, Anda umumnya harus mengarahkan setiap pengindeks setiap layanan Pencarian Azure Cognitive regional ke replika sumber data lokalnya. Namun, pendekatan itu tidak dianjurkan untuk dataset besar yang disimpan dalam Azure SQL Database. Alasannya adalah bahwa Azure Cognitive Search tidak dapat melakukan pengindeksan inkremental dari replika SQL Database sekunder, hanya dari replika utama. Sebaliknya, arahkan semua pengindeks ke replika utama. Setelah failover, arahkan pengindeks Azure Cognitive Search ke replika utama baru.

  • Jika sumber data tidak direplikasi secara geografis, arahkan beberapa pengindeks pada sumber data yang sama, sehingga Azure Cognitive layanan Pencarian s di beberapa wilayah secara terus menerus dan independen mengindeks dari sumber data. Untuk informasi selengkapnya, lihat Pertimbangan performa dan pengoptimalan Azure Search.

Service Bus

Gunakan tingkat Premium untuk beban kerja produksi. Bus Layanan Premium Messaging menyediakan sumber daya pemrosesan khusus dan cadangan, serta kapasitas memori untuk mendukung performa dan throughput. yang dapat diprediksi. Tingkat Pesan Premium juga memberi Anda akses ke fitur-fitur baru yang pada awalnya hanya tersedia untuk pelanggan premium. Anda dapat menentukan jumlah unit pesan berdasarkan beban kerja yang diharapkan.

Tangani pesan duplikat. Jika penerbit gagal segera setelah mengirim pesan, atau mengalami masalah jaringan atau sistem, penerbit mungkin gagal mencatat bahwa pesan telah dikirim, dan mungkin mengirim pesan yang sama ke sistem dua kali. Microsof Azure Service Bus dapat menangani masalah ini dengan mengaktifkan deteksi duplikat. Untuk informasi selengkapnya, lihat Deteksi duplikat.

Menangani pengecualian. Messaging API menghasilkan pengecualian saat terjadi kesalahan pengguna, kesalahan konfigurasi, atau kesalahan lainnya. Kode klien (pengirim dan penerima) harus menangani pengecualian dalam kode mereka. Hal ini khususnya penting dalam pemrosesan batch, di mana penanganan pengecualian dapat digunakan untuk menghindari kehilangan seluruh batch pesan. Untuk informasi selengkapnya, lihat Pengecualian olahpesan Bus Layanan.

Kebijakan Percobaan Kembali. Microsoft Azure Service Bus memungkinkan Anda untuk memilih kebijakan percobaan ulang yang terbaik untuk aplikasi Anda. Kebijakan default adalah mengizinkan 9 upaya coba lagi maksimum, dan tunggu selama 30 detik, tetapi ini dapat disesuaikan lebih lanjut. Untuk informasi selengkapnya, lihat Kebijakan Prcobaan kembali - Bus Layanan.

Gunakan antrean surat mati. Jika pesan tidak dapat diproses atau dikirim ke penerima mana pun setelah beberapa kali mencoba ulang, pesan tersebut dipindahkan ke antrean dead-letter. Terapkan proses untuk membaca pesan dari antrean surat mati, periksa, dan pulihkan masalah. Tergantung pada skenario, Anda dapat mencoba ulang pesan apa adanya, membuat perubahan dan mencoba lagi, atau membuang pesan. Untuk informasi selengkapnya, lihat Ringkasan antrean dead-letter Service Bus.

Gunakan redundansi zona. Saat redundansi zona diaktifkan di namespace Anda, Bus Layanan secara otomatis mereplikasi perubahan di antara beberapa zona ketersediaan. Jika satu zona ketersediaan gagal, failover terjadi secara otomatis. Untuk informasi selengkapnya, lihat Praktik terbaik untuk mengisolasi aplikasi terhadap pemadaman dan bencana Bus Layanan.

Gunakan Pemulihan Geo-Bencana. Pemulihan geo-bencana memastikan bahwa pemrosesan data terus beroperasi di wilayah atau pusat data yang berbeda jika seluruh wilayah atau pusat data Azure menjadi tidak tersedia karena bencana. Untuk informasi selengkapnya, lihat pemulihan Bencana geografis Azure Service Bus.

Penyimpanan

Gunakan penyimpanan zona redundan. Penyimpanan zona-redundan (ZRS) menyalin data Anda secara sinkron di tiga zona ketersediaan Azure di wilayah utama. Jika zona ketersediaan mengalami pemadaman, Azure Storage secara otomatis melakukan failover ke zona alternatif. Untuk informasi lebih lanjut, lihat Redundansi Azure Storage.

Saat menggunakan geo-redundansi, konfigurasikan akses baca. Jika Anda menggunakan arsitektur multi-wilayah, gunakan tingkat penyimpanan yang sesuai untuk redundansi global. Dengan RA-GRS atau RA-GZRS, data Anda direplikasi ke wilayah sekunder. RA-GRS menggunakan penyimpanan redundan lokal (LRS) di wilayah utama, sementara RA-GZRS menggunakan penyimpanan redundan zona (ZRS) di wilayah utama. Kedua konfigurasi menyediakan akses baca-saja ke data Anda di wilayah sekunder. Jika ada pemadaman penyimpanan di wilayah utama, aplikasi dapat membaca data dari wilayah sekunder jika Anda telah merancangnya untuk kemungkinan ini. Untuk informasi lebih lanjut, lihat Redundansi Azure Storage.

Untuk disk VM, gunakan disk terkelola.Disk terkelola memberikan keandalan yang lebih baik untuk VM dalam set ketersediaan, karena disk cukup terisolasi satu sama lain untuk menghindari satu titik kegagalan. Selain itu, disk yang dikelola tidak tunduk pada batas IOPS VHD yang dibuat di akun penyimpanan. Untuk informasi selengkapnya, lihat Mengelola ketersediaan komputer virtual Windows di Azure.

Untuk penyimpanan antrean, buat antrean cadangan di wilayah lain. Untuk Penyimpanan Antrean, replika baca-saja memiliki penggunaan terbatas, karena Anda tidak dapat mengantre atau menghapus item antrean. Sebagai gantinya, buat antrean cadangan pada akun penyimpanan di wilayah lain. Jika ada pemadaman Azure Storage, aplikasi dapat menggunakan antrean cadangan, hingga wilayah utama tersedia lagi. Dengan begitu, aplikasi dapat terus memproses permintaan baru selama pemadaman.

Microsoft Azure SQL Database

Gunakan tingkat Standar atau Premium. Tingkat ini memberikan periode pemulihan dalam waktu yang lebih lama (35 hari). Untuk informasi selengkapnya, lihat opsi dan kinerja SQL Database.

Mengaktifkan audit SQL Database. Audit bisa digunakan untuk mendiagnosa serangan berbahaya atau kesalahan manusia. Untuk informasi selengkapnya, lihat Memulai dengan Pengauditan database SQL.

Gunakan Replikasi Geo Aktif untuk membuat sekunder yang dapat dibaca di wilayah yang berbeda. Jika database utama Anda gagal, atau cukup perlu digunakan secara offline, lakukan pengalihan manual ke database sekunder. Sampai Anda mengalihkan, database sekunder tetap baca-saja. Untuk informasi selengkapnya, lihat Azure SQL Database Active Geo-Replication.

Gunakan sharding. Pertimbangkan untuk menggunakan sharding dalam mempartisi database secara horizontal. Sharding dapat memberikan isolasi kesalahan. Untuk informasi selengkapnya, lihat penskalaan dengan Azure SQL Database.

Menggunakanlihan pemulihan point-in-time untuk memulihkan dari kesalahan manusia. Pemulihan point-in-time mengembalikan database Anda ke titik waktu sebelumnya. Untuk informasi selengkapnya, lihat Memulihkan database Azure SQL dengan menggunakan pencadangan database otomatis.

Menggunakan pemulihan geografis untuk memulihkan dari ketidaktersediaan layanan. Pemulihan geografis mengembalikan database dari cadangan geo-redundant. Untuk informasi selengkapnya, lihat Memulihkan database Azure SQL dengan menggunakan pencadangan database otomatis.

Azure Synapse Analytics

Jangan nonaktifkan pencadangan geografis. Secara default, Synapse Analytics mengambil cadangan penuh data Anda di Kumpulan SQL Khusus setiap 24 jam untuk pemulihan bencana. Hal ini tidak disarankan untuk mematikan fitur ini. Untuk informasi selengkapnya, lihat Geo-backup.

SQL Server berjalan dalam VM

Cadangkan databasenya. Jika Anda sudah menggunakan Azure Backup untuk mencadangkan VM, pertimbangkan untuk menggunakan Azure Backup untuk beban kerja SQL Server gunakan DPM. Dengan pendekatan ini, ada satu peran administrator cadangan dalam organisasi dan prosedur pemulihan terpadu untuk VM dan SQL Server. Jika tidak, gunakan SQL Server Managed Backup ke Microsoft Azure.

Traffic Manager

Tampilkan failover manual. Setelah failover Traffic Manager, lakukan failback manual, daripada secara otomatis gagal kembali. Sebelum gagal kembali, verifikasi bahwa semua subsistem aplikasi sehat. Atau jika tidak, Anda dapat menciptakan situasi di mana aplikasi bolak-balik antara datacenter. Untuk informasi selengkapnya, lihat Jalankan VM di beberapa wilayah untuk ketersediaan tinggi.

Buatlah titik akhir pemeriksaan kesehatan. Buat titik akhir khusus yang melaporkan kesehatan aplikasi secara keseluruhan. Hal ini memungkinkan Traffic Manager gagal jika jalur kritis apapun gagal, bukan hanya bagian terdepan. Titik akhir seharusnya mengembalikan kode kesalahan HTTP jika ada dependensi kritis yang tidak sehat atau tidak terjangkau. Namun, jangan melaporkan kesalahan untuk layanan non-kritis. Jika tidak, pemeriksaan kesehatan akan memicu kegagalan ketika tidak dibutuhkan, menciptakan positif palsu. Untuk informasi lebih lanjut, lihat Pemantauan titik akhir dan failover Traffic Manager.

Komputer Virtual

Hindari menjalankan beban kerja produksi pada satu VM. Penyebaran VM tunggal tidak tahan terhadap pemeliharaan yang direncanakan atau tidak direncanakan. Sebagai gantinya, masukkan beberapa VM ke dalam set ketersediaan atau atur skala mesin virtual, dengan penyeimbang beban di depan.

Tentukan ketersediaan yang ditetapkan saat Anda menyediakan VM. Saat ini, tidak ada cara untuk menambahkan VM ke set ketersediaan setelah VM disediakan. Saat Anda menambahkan VM baru ke rangkaian ketersediaan yang ada, pastikan untuk membuat NIC untuk VM, dan tambahkan NIC ke kumpulan alamat ujung belakang di penyeimbang beban. Jika tidak, penyeimbang beban tidak akan merutekan lalu lintas jaringan ke VM tersebut.

Konfigurasikan setiap tingkat aplikasi ke dalam set ketersediaan terpisah. Dalam aplikasi N-tier, jangan memasukkan VM dari tingkatan yang berbeda ke dalam kumpulan ketersediaan yang sama. VM dalam kumpulan ketersediaan ditempatkan di seluruh domain kesalahan (ID) dan memperbarui domain (UD). Namun, untuk mendapatkan manfaat redundansi dari FD dan ID, setiap VM dalam set ketersediaan harus dapat menangani permintaan klien yang sama.

Replikasi VM menggunakan Azure Site Recovery. Saat Anda mereplikasi VM Azure menggunakan Site Recovery, semua disk VM terus direplikasi ke wilayah target secara asinkronis. Poin pemulihan dibuat setiap beberapa menit. Hal ini memberi Anda Tujuan Titik Pemulihan (RPO) dalam urutan menit. Anda dapat melakukan latihan pemulihan bencana sebanyak yang Anda inginkan, tanpa mempengaruhi aplikasi produksi atau replikasi yang sedang berlangsung. Untuk informasi selengkapnya, lihat Jalankan latihan pemulihan bencana ke Microsoft Azure.

Pilih ukuran VM yang tepat berdasarkan persyaratan performa. Saat memindahkan beban kerja yang ada ke Microsoft Azure, mulailah dengan ukuran VM yang paling cocok dengan server lokal Anda. Kemudian ukur performa beban kerja Anda yang sebenarnya terkait dengan CPU, memori, dan disk IOPS, dan sesuaikan ukurannya jika diperlukan. Hal ini membantu memastikan aplikasi berperilaku seperti yang diharapkan di lingkungan cloud. Juga, jika Anda membutuhkan beberapa NIC, waspadai batas NIC untuk setiap ukuran.

Guunakan disk terkelola. untuk VHDsDisk terkelola memberikan keandalan yang lebih baik untuk VM dalam set ketersediaan, karena disk cukup terisolasi satu sama lain untuk menghindari satu titik kegagalan. Selain itu, disk yang dikelola tidak tunduk pada batas IOPS VHD yang dibuat di akun penyimpanan. Untuk informasi selengkapnya, lihat Mengelola ketersediaan komputer virtual Windows di Azure.

Instal aplikasi pada disk data, bukan di disk OS. Jika tidak, Anda akan mencapai batas ukuran disk.

Gunakan Microsoft Azure Backup untuk mencadangkan VM. Cadangan melindungi dari kehilangan data yang tidak disengaja. Untuk informasi selengkapnya, lihat Protect Azure VM dengan kubah Layanan Pemulihan.

Mengaktifkan log diagnostik. Sertakan metrik kesehatan dasar, log infrastruktur, dan diagnostik boot. Mendiagnostik boot dapat membantu Anda mendiagnosis kegagalan boot jika VM Anda masuk ke dalam status nonbootable. Untuk informasi selengkapnya, lihat Ikhtisar Azure Policy.

Konfigurasikan Azure Monitor. Kumpulkan dan analisis data pemantauan dari mesin virtual Azure termasuk sistem operasi tamu dan beban kerja yang berjalan di dalamnya, lihat Azure Monitor dan Mulai Cepat: Azure Monitor.

Virtual Network

Untuk memperbolehkan atau memblokir alamat IP publik, tambahkan grup keamanan jaringan ke subnet. Blokir akses dari pengguna berbahaya, atau izinkan akses hanya dari pengguna yang memiliki hak istimewa untuk mengakses aplikasi.

Buatlah pemeriksaan kesehatan khusus. Load Balancer Health Probes dapat menguji HTTP atau TCP. Jika VM menjalankan server HTTP, probe HTTP adalah indikator status kesehatan yang lebih baik daripada probe TCP. Untuk pemeriksaan HTTP, gunakan titik akhir khusus yang melaporkan kesehatan aplikasi secara keseluruhan, termasuk semua dependensi penting. Untuk informasi selengkapnya, lihat Gambaran umum Azure Standard Load Balancer.

Jangan blokir pemeriksaan kesehatan. Muatan Probe Azure Load Balancer dikirim dari alamat IP yang diketahui, 168.63.129.16. Jangan memblokir lalu lintas ke atau dari IP ini dalam kebijakan firewall atau aturan grup keamanan jaringan apa pun. Memblokir probe kesehatan akan menyebabkan penyeimbang beban menghapus VM dari rotasi.

Aktifkan Pencatatan Azure Load Balancer. Log menunjukkan berapa banyak VM di bagian belakang tidak menerima lalu lintas jaringan karena respon probe yang gagal. Untuk informasi selengkapnya, lihat Analitik log untuk Azure Load Balancer.