Keandalan di Azure HDInsight
Artikel ini menjelaskan dukungan keandalan di Azure HDInsight, dan mencakup zona ketersediaan dan pemulihan lintas wilayah dan kelangsungan bisnis. Untuk gambaran umum keandalan yang lebih rinci di Azure, lihat Keandalan Azure.
Dukungan zona ketersediaan
Zona ketersediaan Azure adalah setidaknya tiga grup pusat data yang terpisah secara fisik dalam setiap wilayah Azure. Pusat data dalam setiap zona dilengkapi dengan infrastruktur daya, pendinginan, dan jaringan independen. Dalam kasus kegagalan zona lokal, zona ketersediaan dirancang sehingga jika satu zona terpengaruh, layanan regional, kapasitas, dan ketersediaan tinggi didukung oleh dua zona yang tersisa.
Kegagalan dapat berkisar dari kegagalan perangkat lunak dan perangkat keras hingga peristiwa seperti gempa bumi, banjir, dan kebakaran. Toleransi terhadap kegagalan dicapai dengan redundansi dan isolasi logis layanan Azure. Untuk informasi selengkapnya tentang zona ketersediaan di Azure, lihat Wilayah dan zona ketersediaan.
Layanan berkemampuan zona ketersediaan Azure dirancang untuk memberikan tingkat keandalan dan fleksibilitas yang tepat. Mereka dapat dikonfigurasi dalam dua cara. Mereka dapat berupa zona redundan,dengan replikasi otomatis di seluruh zona, atau zonal, dengan instans yang disematkan ke zona tertentu. Anda juga dapat menggabungkan pendekatan ini. Untuk informasi selengkapnya tentang arsitektur zonal vs. zona-redundan, lihat Rekomendasi untuk menggunakan zona dan wilayah ketersediaan.
Azure HDInsight mendukung konfigurasi penyebaran zona. Simpul kluster Azure HDInsight ditempatkan dalam satu zona yang Anda pilih di wilayah yang dipilih. Kluster HDInsight zonal diisolasi dari pemadaman apa pun yang terjadi di zona lain. Namun, jika pemadaman berdampak pada zona tertentu yang dipilih untuk kluster HDInsight, kluster tidak akan tersedia. Model penyebaran ini menyediakan konektivitas jaringan latensi rendah yang murah dalam kluster. Mereplikasi model penyebaran ini ke beberapa zona ketersediaan dapat memberikan tingkat ketersediaan yang lebih tinggi untuk melindungi dari kegagalan perangkat keras.
Penting
Untuk penyebaran di mana pengguna tidak menentukan zona tertentu, jenis node bukan tangguh zona dan dapat mengalami waktu henti selama pemadaman di zona mana pun di wilayah tersebut.
Prasyarat
Zona ketersediaan hanya didukung untuk kluster yang dibuat setelah 15 Juni 2023. Pengaturan zona ketersediaan tidak bisa diperbarui setelah kluster dibuat. Anda juga tidak dapat memperbarui kluster bukan zona ketersediaan saat ini untuk menggunakan zona ketersediaan.
Kluster harus dibuat di bawah VNet kustom.
Anda perlu membawa SQL DB Anda sendiri untuk Ambari DB dan metastore eksternal, seperti metastore Apache Hive, sehingga Anda dapat mengonfigurasi DB ini di zona ketersediaan yang sama.
Kluster HDInsight Anda harus dibuat dengan opsi zona ketersediaan di salah satu wilayah berikut:
- Australia Timur
- Brasil Selatan
- Kanada Tengah
- US Tengah
- US Timur
- AS Timur 2
- Prancis Tengah
- Jerman Barat Tengah
- Jepang Timur
- Korea Tengah
- Eropa Utara
- Qatar Tengah
- Asia Tenggara
- US Tengah Selatan
- UK Selatan
- US Gov Virginia
- Eropa Barat
- US Barat 2
Membuat kluster HDInsight menggunakan zona ketersediaan
Anda dapat menggunakan templat Azure Resource Manager (ARM) untuk meluncurkan kluster HDInsight ke zona ketersediaan tertentu.
Di bagian sumber daya, Anda perlu menambahkan bagian 'zona' dan menyediakan zona ketersediaan mana yang Anda inginkan untuk disebarkan kluster ini.
"resources": [
{
"type": "Microsoft.HDInsight/clusters",
"apiVersion": "2021-06-01",
"name": "[parameters('cluster name')]",
"location": "East US 2",
"zones": [
"1"
],
}
]
Memverifikasi simpul dalam satu Zona ketersediaan di seluruh zona
Ketika kluster HDInsight sudah siap, Anda dapat memeriksa lokasi untuk melihat zona ketersediaan tempat mereka ditempatkan.
Dapatkan respons API:
[
{
"location": "East US 2",
"zones": [
"1"
],
}
]
Meningkatkan kluster
Anda dapat meningkatkan kluster HDInsight dengan lebih banyak node pekerja. Simpul pekerja yang baru ditambahkan akan ditempatkan di zona ketersediaan yang sama dari kluster ini.
Migrasi zona ketersediaan
Kluster Azure HDInsight saat ini tidak mendukung migrasi di tempat instans kluster yang ada ke dukungan zona ketersediaan. Namun, Anda dapat memilih untuk membuat ulang kluster Anda, dan memilih zona ketersediaan atau wilayah yang berbeda selama pembuatan kluster. Kluster siaga sekunder di wilayah yang berbeda dan zona ketersediaan yang berbeda dapat digunakan dalam skenario pemulihan bencana.
Pengalaman zona tidak berfungsi
Ketika zona ketersediaan turun:
- Anda tidak dapat melakukan ssh ke kluster ini.
- Anda tidak dapat menghapus atau meningkatkan atau menurunkan skala kluster ini.
- Anda tidak dapat mengirimkan pekerjaan atau melihat riwayat pekerjaan.
- Anda masih dapat mengirimkan permintaan pembuatan kluster baru di wilayah yang berbeda.
Pemulihan bencana lintas wilayah dan kelangsungan bisnis
Pemulihan bencana (DR) adalah tentang pemulihan dari peristiwa berdampak tinggi, seperti bencana alam atau penyebaran gagal yang mengakibatkan waktu henti dan kehilangan data. Terlepas dari penyebabnya, obat terbaik untuk bencana adalah rencana DR yang terdefinisi dan teruji dengan baik dan desain aplikasi yang secara aktif mendukung DR. Sebelum Anda mulai berpikir tentang membuat rencana pemulihan bencana Anda, lihat Rekomendasi untuk merancang strategi pemulihan bencana.
Ketika datang ke DR, Microsoft menggunakan model tanggung jawab bersama. Dalam model tanggung jawab bersama, Microsoft memastikan bahwa infrastruktur dasar dan layanan platform tersedia. Pada saat yang sama, banyak layanan Azure tidak secara otomatis mereplikasi data atau mundur dari wilayah yang gagal untuk mereplikasi silang ke wilayah lain yang diaktifkan. Untuk layanan tersebut, Anda bertanggung jawab untuk menyiapkan rencana pemulihan bencana yang berfungsi untuk beban kerja Anda. Sebagian besar layanan yang berjalan pada penawaran platform as a service (PaaS) Azure menyediakan fitur dan panduan untuk mendukung DR dan Anda dapat menggunakan fitur khusus layanan untuk mendukung pemulihan cepat untuk membantu mengembangkan rencana DR Anda.
Kluster Azure HDInsight tergantung pada berbagai layanan Azure seperti penyimpanan, database, Direktori Aktif, Layanan Domain Direktori Aktif, jaringan, dan Key Vault. Aplikasi analitik yang dirancang apik, banyak tersedia, dan toleran terhadap kesalahan harus dirancang dengan redundansi yang cukup untuk menahan gangguan regional atau lokal dalam satu atau lebih layanan ini. Bagian ini memberikan gambaran umum tentang praktik terbaik, ketersediaan tunggal dan multi wilayah, dan opsi pengoptimalan untuk perencanaan kelangsungan bisnis.
Pemulihan bencana dalam geografi multi-wilayah
Meningkatkan kelangsungan bisnis menggunakan pemulihan bencana ketersediaan tinggi lintas wilayah membutuhkan desain arsitektur dengan kompleksitas dan biaya yang lebih tinggi. Tabel berikut memerinci beberapa area teknis yang dapat meningkatkan total biaya kepemilikan.
Pengoptimalan Biaya
| Luas | Penyebab peningkatan biaya | Strategi pengoptimalan |
|---|---|---|
| Penyimpanan Data | Menduplikasi data/tabel utama di wilayah sekunder | Replikasi hanya data yang dikumpulkan |
| Keluarnya Data | Transfer data lintas wilayah keluar memiliki konsekuensi negatif. Tinjau panduan harga Bandwidth | Hanya lakukan replikasi pada data yang dikumpulkan untuk mengurangi jejak keluar wilayah |
| Komputasi kluster | Kluster HDInsight tambahan di wilayah sekunder | Gunakan skrip otomatis untuk menyebarkan komputasi sekunder setelah kegagalan primer. Gunakan Autoscaling untuk menjaga agar ukuran kluster sekunder tetap minimum. Gunakan SKU VM yang lebih terjangkau. Buat tambahan di wilayah tempat SKU VM dapat didiskon. |
| Autentikasi | Skenario multipengguna di wilayah sekunder menimbulkan penyiapan Microsoft Entra Domain Services tambahan | Hindari pengaturan multipengguna di wilayah sekunder. |
Pengoptimalan kompleksitas
| Luas | Penyebab eskalasi kompleksitas | Strategi pengoptimalan |
|---|---|---|
| Pola Baca Tulis | Mengharuskan primer maupun sekunder untuk diaktifkan melalui Baca dan Tulis | Rancang tambahan hanya untuk dibaca |
| Nol RPO & RTO | Memerlukan kehilangan data nol (RPO=0) dan waktu henti nol (RTO=0) | Rancang RPO dan RTO sedemikian rupa untuk mengurangi jumlah komponen yang perlu gagal. Untuk informasi selengkapnya tentang RTO dan RPO, lihat Tujuan pemulihan. |
| Fungsionalitas bisnis | Membutuhkan fungsionalitas bisnis penuh primer di sekunder | Evaluasi jika Anda dapat menjalankan dengan subset kritis minimum fungsionalitas bisnis di sekunder. |
| Konektivitas | Membutuhkan semua sistem hulu dan hilir dari primer untuk terhubung pula ke sekunder | Batasi konektivitas sekunder ke subset kritis minimum. |
Saat Anda membuat rencana pemulihan bencana multi-wilayah, pertimbangkan rekomendasi berikut:
Tentukan fungsionalitas bisnis minimal yang Anda butuhkan jika ada bencana dan mengapa. Misalnya, evaluasi jika Anda membutuhkan kemampuan kegagalan untuk lapisan transformasi data (ditampilkan dalam warna kuning) dan lapisan penyajian data (ditampilkan dalam warna biru), atau jika Anda hanya perlu kegagalan untuk lapisan layanan data.
Segmentasikan kluster Anda berdasarkan beban kerja, siklus hidup pengembangan, dan departemen. Memiliki lebih banyak kluster mengurangi kemungkinan kegagalan besar tunggal yang memengaruhi beberapa proses bisnis yang berbeda.
Jadikan wilayah sekunder Anda baca-saja. Wilayah kegagalan dengan kemampuan membaca dan menulis dapat menyebabkan arsitektur yang kompleks.
Kluster sementara lebih mudah dikelola ketika terjadi permasalahan. Rancang beban kerja Anda sedemikian rupa sehingga kluster dapat didaur ulang dan tidak ada status yang dipertahankan dalam kluster.
Sering kali beban kerja tidak selesai jika terjadi permasalahan dan perlu dimulai ulang di wilayah baru. Rancang beban kerja Anda agar menjadi idempoten.
Gunakan automasi selama penyebaran kluster dan pastikan pengaturan konfigurasi kluster diubah menjadi skrip sejauh mungkin untuk memastikan penyebaran yang cepat dan sepenuhnya otomatis jika ada terjadi permasalahan.
Deteksi, pemberitahuan, dan manajemen pemadaman
Gunakan alat pemantauan Azure di HDInsight untuk mendeteksi perilaku abnormal dalam kluster dan atur pemberitahuan peringatan terkait. Anda dapat menggunakan solusi manajemen spesifik kluster HDInsight yang telah dikonfigurasi sebelumnya yang mengumpulkan metrik kinerja penting dari jenis kluster tertentu. Untuk mengetahui informasi selengkapnya, lihat Azure Monitoring untuk HDInsight.
Langganan pemberitahuan kesehatan Azure untuk mendapat pemberitahuan Anda mengenai masalah layanan, pemeliharaan terencana, saran kesehatan dan keamanan untuk langganan, layanan, atau wilayah. Pemberitahuan kesehatan yang mencakup penyebab masalah dan ETA tegas membantu Anda untuk mengeksekusi kegagalan dan failback dengan lebih baik. Untuk informasi selengkapnya, lihat Dokumentasi Azure Service Health.
Pemulihan bencana dalam geografi wilayah tunggal
Setiap komponen dalam sistem HDInsight dasar memiliki mekanisme toleransi kesalahan wilayah tunggalnya sendiri. Perlu diingat bahwa tidak selalu mengambil peristiwa bencana untuk memengaruhi fungsionalitas bisnis. Insiden layanan dalam satu atau beberapa layanan berikut dalam satu wilayah juga dapat menyebabkan hilangnya fungsionalitas bisnis yang diharapkan.
Komputasi (komputer virtual): Kluster Azure HDInsight. HDInsight menawarkan ketersediaan SLA sebesar 99,9%. Untuk memberikan ketersediaan tinggi dalam satu penyebaran, HDInsight disertai dengan banyak layanan yang berada dalam mode ketersediaan tinggi secara default. Mekanisme toleransi kesalahan dalam HDInsight disediakan oleh layanan ketersediaan tinggi ekosistem Microsoft dan Apache OSS.
Komponen infrastruktur berikut dirancang agar sangat tersedia:
- Headnode Aktif dan Siaga
- Beberapa Node Gateway
- Tiga node Kuorum Zookeeper
- Node Pekerja didistribusikan oleh domain kesalahan dan pembaruan
Layanan berikut ini juga dirancang agar sangat tersedia:
- Apache Ambari Server
- Waktu aplikasi server untuk YARN
- Server Riwayat Pekerjaan untuk Pengurangan Peta Hadoop
- Apache Livy
- HDFS
- YARN Resource Manager
- Master HBase
Untuk mempelajari selengkapnya, lihat layanan ketersediaan tinggi yang didukung oleh Azure HDInsight.
Metastore: Azure SQL Database. HDInsight menggunakan Azure SQL Database sebagai metastore, yang menyediakan SLA sebesar 99.99%. Tiga replika data bertahan di dalam pusat data dengan replikasi sinkron. Jika terdapat kehilangan replika, replika alternatif disajikan dengan lancar. Geo-replikasi aktif didukung secara unik dengan maksimum empat pusat data. Ketika ada failover, baik manual atau pusat data, replika pertama dalam hierarki secara otomatis menjadi kemampuan baca-tulis. Untuk informasi selengkapnya, lihat Kelangsungan bisnis Azure SQL Database.
Penyimpanan: Penyimpanan Azure Data Lake Gen2 atau Blob. HDInsight merekomendasikan Azure Data Lake Storage Gen2 sebagai lapisan penyimpanan yang mendasarinya. Microsoft Azure Storage, termasuk Azure Data Lake Storage Gen2, menyediakan SLA sebesar 99,9%. HDInsight menggunakan layanan LRS di mana tiga replika data bertahan di dalam pusat data, dan replikasi sinkron. Ketika terjadi kehilangan replika, replika disajikan dengan lancar.
Autentikasi: ID Microsoft Entra, Microsoft Entra Domain Services, Paket Keamanan Perusahaan.
- MICROSOFT Entra ID menyediakan SLA sebesar 99,9%. Active Directory adalah layanan global dengan beberapa tingkat redundansi internal dan pemulihan otomatis. Untuk informasi selengkapnya, lihat bagaimana Microsoft terus meningkatkan keandalan ID Microsoft Entra.
- Microsoft Entra Domain Services menyediakan SLA sebesar 99,9%. Microsoft Entra Domain Services adalah layanan yang sangat tersedia yang dihosting di pusat data yang didistribusikan secara global. Set replika adalah fitur pratinjau di Microsoft Entra Domain Services yang memungkinkan pemulihan bencana geografis jika wilayah Azure offline. Untuk informasi selengkapnya, lihat konsep dan fitur set replika untuk Microsoft Entra Domain Services untuk mempelajari selengkapnya.
- Azure DNS menyediakan SLA 100%. HDInsight menggunakan Azure DNS di berbagai tempat untuk resolusi nama domain.
Layanan opsional, seperti Azure Key Vault dan Azure Data Factory.
Konten terkait
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk