Bagikan melalui

Daftar periksa ketahanan untuk layanan Azure tertentu

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.

Layanan Aplikasi

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 menyimpan 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 terpisah untuk produksi dan pengujian. Jangan gunakan slot untuk pengujian pada penerapan produksi Anda. Semua aplikasi dalam paket layanan aplikasi yang sama berbagi instans VM yang sama. Jika Anda menempatkan penempatan produksi dan uji coba dalam rencana yang sama, hal ini dapat mempengaruhi secara negatif penempatan produksi. Misalnya, pengujian beban kerja dapat menurunkan kinerja situs produksi yang sedang aktif. Dengan menempatkan pengujian penerapan ke dalam rencana 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 layanan aplikasi yang redundan zona. 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, yang memerlukan biaya dalam bentuk DTU.

Sebarkan ke slot uji coba. Buat slot penerapan untuk pengujian. Terapkan pembaruan aplikasi ke slot staging, dan pastikan penerapan tersebut sebelum memindahkannya ke produksi. Hal ini mengurangi kemungkinan pembaruan yang buruk dalam produksi. Hal ini juga memastikan bahwa semua instans dihangatkan sebelum dipindahkan ke lingkungan produksi. Banyak aplikasi memiliki waktu pemanasan yang cukup lama dan waktu memulai yang lambat. 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 lingkungan produksi, pindahkan penerapan produksi sebelumnya ke dalam slot LKG. Hal ini membuatnya lebih mudah untuk mengembalikan penyebaran yang buruk. Jika Anda menemukan masalah nantinya, Anda dapat dengan cepat kembali ke versi LKG. Untuk informasi selengkapnya, lihat Aplikasi web dasar.

Aktifkan pengelogan diagnostik, termasuk pengelogan aplikasi dan pengelogan server web. Pencatatan log penting untuk pemantauan dan diagnostik. Lihat Mengaktifkan pencatatan diagnostik 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 kinerja. 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 dimiliki oleh Dasar, seperti zona ketersediaan dan ketahanan zona. Ini berarti ketika zona mengalami gangguan, Load Balancer Standar zona-redundan Anda akan tetap tidak terpengaruh. Hal ini memastikan deployment Anda dapat bertahan dari kegagalan zona dalam suatu wilayah. Selain itu, Standard Load Balancer mendukung penyeimbangan beban global yang memastikan aplikasi Anda juga tidak terpengaruh oleh kegagalan wilayah.

Berikan setidaknya dua contoh. Terapkan Azure Load Balancer dengan setidaknya dua instance di backend. Satu kejadian bisa mengakibatkan satu titik kegagalan. Untuk membangun sesuai skala, Anda harus menghubungkan load balancer dengan Virtual Machine Scale Sets.

Gunakan aturan keluar masuk. Aturan keluar memastikan bahwa Anda tidak mengalami kegagalan koneksi akibat kelelahan port SNAT (Source Network Address Translation). Pelajari selengkapnya tentang konektivitas keluar jaringan. Meskipun aturan keluar akan membantu meningkatkan solusi untuk penyebaran berskala kecil hingga menengah, untuk beban kerja produksi, kami merekomendasikan menggabungkan Load Balancer Standar atau penyebaran subnet apa pun dengan terjemahan alamat jaringan (NAT) pada VNet.

IP Publik Azure

Pilih SKU Standar. IP Publik Standar menyediakan zona ketersediaan dan ketahanan zona tidak seperti IP Publik Dasar. Jika menggunakan layanan yang memerlukan IP publik, pilih IP publik zona-redundan. Untuk IP yang ada, tingkatkan dari Dasar ke Standar untuk mendapatkan manfaat redundansi zona secara default.

Application Gateway

Berikan setidaknya dua contoh. Sebarkan Application Gateway dengan minimal dua instance. Satu kejadian adalah satu poin kegagalan. Gunakan dua atau lebih instans untuk redundansi dan skalabilitas. Untuk memenuhi kualifikasi untuk perjanjian tingkat layanan (SLA), Anda harus menyediakan dua atau lebih instans ukuran menengah atau lebih besar.

Azure Cosmos DB (layanan basis data global dari Microsoft)

Konfigurasi 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 pada area penulisan, Anda dapat membaca dari replika lain. SDK Klien menangani ini secara otomatis. Anda juga dapat memindahkan wilayah tulis ke wilayah lain. Untuk informasi selengkapnya, lihat Cara mendistribusikan data secara global dengan Azure Cosmos DB.

Pusat Aktivitas

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 checkpoint 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 dengan baik Konsumen acara biasanya memproses sekumpulan pesan dalam loop. Anda harus menangani pengecualian dalam loop pemrosesan ini untuk menghindari kehilangan seluruh batch pesan jika satu pesan menyebabkan pengecualian.

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

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

Terapkan pemulihan bencana (DR) dengan melakukan failover ke namespace layanan Event Hubs sekunder. Untuk informasi selengkapnya, lihat Azure Event Hubs Pemulihan Bencana Geografi.

Azure Cache untuk Redis

Konfigurasi 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 kelas Premium. Data yang ditulis ke cache utama direplikasi ke cach baca-saja sekunder. Untuk informasi 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 tingkat 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 ketersediaan tinggi pembacaan, atau tiga untuk ketersediaan tinggi baca-tulis.

Gunakan redundansi zona. Anda dapat mengimplementasikan replika Pencarian AI di beberapa zona ketersediaan. Pendekatan ini membantu layanan Anda untuk tetap beroperasi bahkan ketika pemadaman pusat data terjadi. Untuk informasi selengkapnya, lihat Keandalan dalam Pencarian AI

Mengkonfigurasi pengindeks untuk penerapan multi-wilayah. Jika Anda memiliki penerapan multi-wilayah, pertimbangkan opsi untuk keberlangsungan pengindeksan.

  • Jika sumber data direplikasi secara geografis, Anda umumnya harus mengarahkan setiap pengindeks dari setiap layanan Pencarian AI regional ke replika sumber data lokalnya. Namun, pendekatan itu tidak dianjurkan untuk dataset besar yang disimpan dalam Azure SQL Database. Alasannya adalah bahwa Pencarian AI 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 Pencarian AI ke replika utama baru.

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

Bus Layanan (Service Bus)

Gunakan tingkat Premium untuk beban kerja produksi. Service Bus Premium Messaging menyediakan sumber daya pemrosesan khusus dan cadangan, serta kapasitas memori untuk mendukung kinerja 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. Microsoft Azure Service Bus dapat menangani masalah ini dengan 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 Pesan Service Bus.

Kebijakan Pengulangan. 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.

Gunakan antrean pesan tidak terkirim. 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 pesan gagal, memeriksanya, dan memperbaiki masalah tersebut. Tergantung pada skenario, Anda dapat mencoba ulang pesan apa adanya, membuat perubahan dan mencoba lagi, atau membuang pesan. Untuk informasi selengkapnya, lihat Gambaran Umum antrean dead-letter pada Service Bus.

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

Gunakan Pemulihan Bencana Geografis. Pemulihan bencana geo memastikan bahwa pemrosesan data tetap beroperasi di wilayah atau pusat data lain jika seluruh wilayah atau pusat data Azure tidak tersedia akibat bencana. Untuk informasi selengkapnya, lihat Pemulihan Bencana Geografis Azure Service Bus.

Penyimpanan

Gunakan penyimpanan zona redundan (ZRS). 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 penyimpanan redundansi geografis akses baca (RA-GRS) atau penyimpanan redundansi geo-zona akses baca (RA-GZRS), data Anda direplikasi ke suatu 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.

SQL Database

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

Mengaktifkan audit pada 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 salinan 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 memindahkan, database sekunder tetap dalam mode baca-saja. Untuk informasi selengkapnya, lihat Azure SQL Database Active Geo-Replication.

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

Gunakan pemulihan waktu tertentu untuk memulihkan akibat kesalahan manusia. Pemulihan pada titik waktu tertentu mengembalikan database Anda ke waktu sebelumnya. Untuk informasi selengkapnya, lihat Memulihkan database Azure SQL dengan menggunakan pencadangan database otomatis.

Gunakan pemulihan berbasis geografis untuk pulih dari gangguan layanan. Pemulihan geografis mengembalikan database dari cadangan redundansi geografis. Untuk informasi selengkapnya, lihat Memulihkan database Azure SQL dengan menggunakan pencadangan database otomatis.

Azure Synapse Analytics

Jangan nonaktifkan pencadangan geografis. Secara default, Azure 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 menggunakan Azure Backup untuk beban kerja SQL Server dengan menggunakan DPM. Dengan pendekatan ini, ada satu peran administrator Cadangan untuk organisasi dan prosedur pemulihan terpadu untuk VM dan SQL Server. Jika tidak, gunakan SQL Server Managed Backup ke Microsoft Azure.

Manajer Lalu Lintas

Lakukan failback manual. Setelah dilakukan failover pada Traffic Manager, lakukan failback secara manual, bukan melakukan failback secara otomatis. Sebelum melakukan failback, pastikan bahwa semua subsistem aplikasi berfungsi dengan baik. Jika tidak, Anda dapat menciptakan situasi di mana aplikasi berpindah-pindah antara pusat data.

Buatlah titik akhir pemeriksaan kesehatan. Buat titik akhir khusus yang melaporkan kesehatan aplikasi secara keseluruhan. Ini memungkinkan Traffic Manager untuk melakukan failover jika ada jalur kritis yang gagal, bukan hanya bagian depan. 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 mekanisme failover saat tidak diperlukan, sehingga menciptakan positif palsu. Untuk informasi lebih lanjut, lihat Pemantauan titik-titik akhir dan failover pada 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 kumpulan ketersediaan atau set skala mesin virtual, dengan penyeimbang beban di depannya.

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. Mesin Virtual dalam set ketersediaan ditempatkan di seluruh fault domains (FD) dan domain pembaruan (UD). Namun, untuk mendapatkan manfaat redundansi dari FD dan UD, setiap VM dalam set ketersediaan harus dapat menangani permintaan yang sama dari klien.

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. Ini memberikan Anda Tujuan Titik Pemulihan (RPO) dalam rentang waktu 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. Selain itu, jika Anda membutuhkan beberapa NIC, waspadai batas NIC untuk setiap ukuran.

Gunakan disk terkelola untuk VHD.Disk terkelola memberikan keandalan yang lebih baik untuk mesin virtual 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 Lindungi Mesin Virtual Azure dengan Brankas 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 Log Diagnostik Azure.

Konfigurasikan Azure Monitor. Mengumpulkan dan menganalisis data pemantauan dari Azure Virtual Machines 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 pemantauan 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 sonde kesehatan. Probe Kesehatan 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 pemeriksaan kesehatan akan menyebabkan penyeimbang beban menghapus VM dari siklus.

Aktifkan pencatatan 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.