Dokumentasi keandalan Azure

  • Artikel

Keandalan terdiri dari dua prinsip: ketahanan dan ketersediaan. Tujuan ketahanan adalah untuk menghindari kegagalan dan, jika masih terjadi, untuk mengembalikan aplikasi Anda ke status berfungsi penuh. Tujuan ketersediaan adalah untuk memberikan akses yang konsisten ke aplikasi atau beban kerja Anda. Penting untuk merencanakan keandalan proaktif berdasarkan persyaratan aplikasi Anda.

Azure menyertakan layanan keandalan bawaan yang dapat Anda gunakan dan kelola berdasarkan kebutuhan bisnis Anda. Baik itu kegagalan node perangkat keras tunggal, kegagalan tingkat rak, pemadaman pusat data, atau pemadaman regional skala besar, Azure menyediakan solusi yang meningkatkan keandalan. Misalnya, set ketersediaan memastikan bahwa mesin virtual yang Anda sebarkan di Azure didistribusikan di beberapa node perangkat keras yang terisolasi dalam kluster. Zona ketersediaan melindungi aplikasi dan data pelanggan dari kegagalan pusat data di beberapa lokasi fisik dalam suatu wilayah. Wilayah dan zona ketersediaan adalah pusat dari desain aplikasi dan strategi ketahanan Anda dan dibahas secara lebih detail nanti dalam artikel ini.

Dokumentasi keandalan Azure menawarkan panduan keandalan untuk layanan Azure. Panduan ini mencakup informasi tentang dukungan zona ketersediaan, panduan pemulihan bencana, dan ketersediaan layanan.

Untuk panduan keandalan khusus layanan terperinci, termasuk zona ketersediaan, pemulihan bencana, atau ketersediaan tinggi, lihat Gambaran umum panduan keandalan khusus layanan Azure.

Untuk informasi tentang prinsip dan arsitektur keandalan dan keandalan di layanan Microsoft Azure, lihat Microsoft Azure Well-Architected Framework: Keandalan.

Persyaratan keandalan

Tingkat keandalan yang diperlukan untuk solusi Azure apa pun bergantung pada beberapa pertimbangan. SLA ketersediaan dan latensi serta persyaratan bisnis lainnya mendorong pilihan arsitektur dan tingkat ketahanan dan harus dipertimbangkan terlebih dahulu. Persyaratan ketersediaan berkisar dari berapa banyak waktu henti yang dapat diterima – dan berapa biaya yang diperlukan bisnis Anda – hingga jumlah uang dan waktu yang dapat Anda investasikan secara realistis dalam membuat aplikasi sangat tersedia.

Membangun sistem keandalan di Azure adalah tanggung jawab bersama. Microsoft bertanggung jawab atas keandalan platform cloud, termasuk jaringan global dan pusat datanya. Pelanggan dan mitra Azure bertanggung jawab atas ketahanan aplikasi cloud mereka, menggunakan praktik terbaik arsitektur berdasarkan persyaratan masing-masing beban kerja. Sementara Azure terus berusaha untuk memberikan ketahanan setinggi mungkin di SLA untuk platform cloud, Anda harus menentukan SLA target Anda sendiri untuk setiap beban kerja dalam solusi Anda. SLA memungkinkan untuk mengevaluasi apakah arsitektur memenuhi persyaratan bisnis. Ketika Anda berusaha mencapai persentase yang lebih tinggi dari waktu aktif yang dijamin SLA, biaya dan kompleksitas untuk mencapai tingkat ketersediaan akan bertambah. Waktu aktif 99,99 persen diterjemahkan menjadi sekitar lima menit dari total waktu henti per bulan. Apakah sepadan dengan kompleksitas dan biaya yang lebih tinggi untuk mencapai persentase tersebut? Jawabannya bergantung pada persyaratan bisnis individu. Saat memutuskan komitmen SLA akhir, pahami SLA yang didukung Microsoft. Setiap layanan Azure memiliki SLA sendiri.

Diagram showing the shared responsibility model for Azure business continuity.

Dalam model lokal tradisional, seluruh tanggung jawab pengelolaan, dari perangkat keras untuk komputasi, penyimpanan, dan jaringan ke aplikasi, jatuh pada Anda. Anda harus merencanakan berbagai jenis kegagalan dan cara menanganinya dengan membuat strategi pemulihan bencana. Dengan IaaS, penyedia layanan cloud bertanggung jawab atas ketahanan infrastruktur inti, termasuk penyimpanan, jaringan, dan komputasi. Saat Anda pindah dari IaaS ke PaaS dan kemudian ke SaaS, Anda akan menemukan bahwa Anda bertanggung jawab atas lebih sedikit dan penyedia layanan cloud bertanggung jawab atas lebih banyak.  

Untuk informasi selengkapnya tentang prinsip Keandalan, lihat Dokumentasi Keandalan Kerangka Kerja yang dirancang dengan baik.  

Membangun keandalan

Anda harus menentukan persyaratan keandalan aplikasi Anda di awal perencanaan. Jika Anda tahu aplikasi mana yang tidak memerlukan ketersediaan tinggi 100% selama periode waktu tertentu, Anda dapat mengoptimalkan biaya selama periode non-kritis tersebut. Identifikasi jenis kegagalan yang dapat dialami aplikasi, dan efek potensial dari setiap kegagalan. Rencana pemulihan harus mencakup semua layanan penting dengan menyelesaikan strategi pemulihan pada tingkat komponen individu dan aplikasi secara keseluruhan. Desain strategi pemulihan Anda untuk melindungi terhadap kegagalan tingkat zonal, regional, dan aplikasi. Lakukan pengujian lingkungan aplikasi end-to-end untuk mengukur keandalan dan pemulihan aplikasi terhadap kegagalan yang tidak terduga.

Daftar periksa berikut mencakup cakupan perencanaan keandalan.

Perencanaan keandalan
Tentukan target ketersediaan dan pemulihan untuk memenuhi kebutuhan bisnis.
Desain fitur keandalan aplikasi Anda berdasarkan persyaratan ketersediaan.
Sejajarkan aplikasi dan platform data untuk memenuhi persyaratan keandalan Anda.
Konfigurasikan jalur koneksi untuk mempromosikan ketersediaan.
Jika memungkinkan, Gunakan zona ketersediaan dan perencanaan pemulihan bencana untuk meningkatkan keandalan dan mengoptimalkan biaya.
Pastikan arsitektur aplikasi Anda tahan terhadap kegagalan.
Ketahui apa yang terjadi jika persyaratan SLA tidak terpenuhi.
Identifikasi kemungkinan titik kegagalan dalam sistem; Desain aplikasi harus menoleransi kegagalan dependensi dengan menyebarkan pemutusan sirkuit.
Buat aplikasi yang beroperasi tanpa adanya dependensi.

RTO dan RPO

Dua metrik penting yang perlu dipertimbangkan adalah tujuan waktu pemulihan dan tujuan titik pemulihan, karena berkaitan dengan pemulihan bencana.  Untuk informasi selengkapnya tentang persyaratan desain fungsional dan non-fungsional, lihat Persyaratan fungsional dan nonfungsi Kerangka Kerja yang dirancang dengan baik.

  • Tujuan waktu pemulihan (RTO) adalah waktu maksimum yang dapat diterima bahwa aplikasi dapat tidak tersedia setelah insiden.

  • Tujuan titik pemulihan (RPO) adalah durasi maksimum kehilangan data yang dapat diterima selama bencana.

RTO dan RPO adalah persyaratan non-fungsional dari sistem dan harus ditentukan oleh persyaratan bisnis. Untuk memperoleh nilai-nilai ini, ada baiknya untuk melakukan penilaian risiko, dan dengan jelas memahami biaya waktu henti atau kehilangan data.  

Wilayah dan zona ketersediaan

Wilayah dan zona ketersediaan adalah bagian besar dari persamaan keandalan. Wilayah memiliki beberapa zona ketersediaan yang terpisah secara fisik. Zona ketersediaan ini terhubung oleh jaringan berkinerja tinggi yang menampilkan latensi kurang dari 2ms antara zona fisik. Latensi rendah membantu data Anda tetap disinkronkan dan dapat diakses saat terjadi kesalahan. Anda dapat menggunakan infrastruktur ini secara strategis saat Merancang aplikasi dan infrastruktur data yang secara otomatis mereplikasi dan memberikan layanan yang tidak terganggu antara zona dan lintas wilayah.

Layanan Microsoft Azure mendukung zona ketersediaan dan diaktifkan untuk mendorong operasi cloud Anda pada ketersediaan tinggi yang optimal sambil mendukung pemulihan lintas wilayah dan kebutuhan strategi kelangsungan bisnis Anda.

Untuk perencanaan pemulihan bencana, wilayah yang dipasangkan dengan wilayah lain menawarkan replikasi lintas wilayah dan memberikan perlindungan dengan mereplikasi data secara asinkron di seluruh wilayah Azure lainnya. Wilayah tanpa pasangan mengikuti panduan residensi data dan menawarkan ketersediaan tinggi dengan zona ketersediaan dan penyimpanan redundan secara lokal atau zona-redundan. Pelanggan harus merencanakan pemulihan bencana lintas wilayah berdasarkan kebutuhan RTO/RPO mereka.

Pilih wilayah terbaik untuk kebutuhan Anda berdasarkan pertimbangan teknis dan peraturan—kemampuan layanan, residensi data, persyaratan kepatuhan, latensi—dan mulai memajukan strategi keandalan Anda. Untuk informasi selengkapnya, lihat Wilayah Azure dan zona ketersediaan.

Dependensi layanan Azure

Layanan Microsoft Azure tersedia secara global untuk mendorong operasi cloud Anda pada tingkat yang optimal.

Layanan Azure yang disebarkan ke wilayah Azure tercantum di halaman produk infrastruktur global Azure. Untuk lebih memahami wilayah dan Zona Ketersediaan di Azure, lihat Wilayah dan Zona Ketersediaan di Azure.

Layanan Azure dibangun untuk keandalan termasuk ketersediaan tinggi dan pemulihan bencana. Tidak ada layanan yang bergantung pada satu pusat data logis (untuk menghindari satu titik kegagalan). Layanan non-regional yang tercantum pada produk infrastruktur global Azure adalah layanan yang tidak ada dependensi pada wilayah Azure tertentu. Layanan non-regional diterapkan ke dua wilayah atau lebih dan jika ada kegagalan regional, instans layanan di wilayah lain tetap melayani pelanggan. Layanan non-regional tertentu memungkinkan pelanggan menentukan wilayah tempat komputer virtual (VM) yang mendasari tempat layanan berjalan akan disebarkan. Misalnya, Azure Virtual Desktop memungkinkan pelanggan menentukan lokasi wilayah tempat VM berada. Semua layanan Azure yang menyimpan data pelanggan memungkinkan pelanggan menentukan wilayah tertentu tempat data mereka akan disimpan. Pengecualiannya adalah MICROSOFT Entra ID, yang memiliki penempatan geografis (seperti Eropa atau Amerika Utara). Untuk informasi selengkapnya tentang residensi penyimpanan data, lihat Peta residensi data.

Jika Anda perlu memahami dependensi antara layanan Azure untuk membantu merancang aplikasi dan layanan Anda dengan lebih baik, Anda dapat meminta dokumentasi dependensi layanan Azure dengan menghubungi perwakilan penjualan atau pelanggan Microsoft Anda. Dokumen ini mencantumkan dependensi untuk layanan Azure, termasuk dependensi pada layanan internal utama umum seperti layanan sarana kontrol. Untuk mendapatkan dokumentasi ini, Anda harus menjadi pelanggan Microsoft dan memiliki perjanjian non-pengungkapan (NDA) yang sesuai dengan Microsoft.

Langkah berikutnya