Pertimbangan dan praktik terbaik

Pertimbangkan hal berikut saat Anda membuat klaster EMR Amazon dengan beberapa node utama:

penting

Untuk meluncurkan kluster EMR ketersediaan tinggi dengan beberapa node utama, kami sangat menyarankan Anda menggunakan rilis EMR Amazon terbaru. Ini memastikan bahwa Anda mendapatkan tingkat ketahanan dan stabilitas tertinggi untuk cluster ketersediaan tinggi Anda.

• Ketersediaan tinggi untuk armada misalnya didukung dengan rilis Amazon EMR 5.36.1, 5.36.2, 6.8.1, 6.9.1, 6.10.1, 6.11.1, 6.12.0, dan yang lebih tinggi. Misalnya grup, ketersediaan tinggi didukung dengan rilis Amazon EMR 5.23.0 dan yang lebih tinggi. Untuk mempelajari selengkapnya, lihat Tentang Rilis EMR Amazon.

• Pada klaster ketersediaan tinggi, Amazon EMR hanya mendukung peluncuran node primer dengan instans On Demand. Ini memastikan ketersediaan tertinggi untuk cluster Anda.

• Anda masih dapat menentukan beberapa tipe instans untuk armada primer tetapi semua node utama dari kluster ketersediaan tinggi diluncurkan dengan tipe instans yang sama, termasuk penggantian untuk node primer yang tidak sehat.

• Untuk melanjutkan operasi, klaster ketersediaan tinggi dengan beberapa node primer membutuhkan dua dari tiga node primer agar sehat. Akibatnya, jika ada dua node utama yang gagal secara bersamaan, cluster EMR Anda akan gagal.

• Semua cluster EMR, termasuk cluster ketersediaan tinggi, diluncurkan dalam satu Availability Zone. Oleh karena itu, mereka tidak dapat mentolerir kegagalan Availability Zone. Dalam kasus pemadaman Availability Zone, Anda kehilangan akses ke cluster.

• Amazon EMR tidak menjamin ketersediaan tinggi untuk aplikasi sumber terbuka selain yang ditentukan. Aplikasi yang didukung di Amazon EMR Cluster dengan beberapa node utama

• Di Amazon EMR merilis 5.23.0 hingga 5.36.2, hanya dua dari tiga node utama untuk cluster grup instance yang dijalankan. HDFS NameNode

• Di Amazon EMR merilis 6.x dan yang lebih tinggi, ketiga node utama untuk grup instans berjalan. HDFS NameNode

Pertimbangan untuk mengkonfigurasi subnet:

• Cluster EMR Amazon dengan beberapa node primer hanya dapat berada di satu Availability Zone atau subnet. Amazon EMR tidak dapat mengganti node utama yang gagal jika subnet sepenuhnya digunakan atau kelebihan langganan jika terjadi failover. Untuk menghindari skenario ini, Anda disarankan untuk mendedikasikan seluruh subnet ke klaster Amazon EMR. Selain itu, pastikan bahwa ada cukup alamat IP pribadi yang tersedia di subnet.

Pertimbangan untuk mengonfigurasi simpul inti:

• Untuk memastikan node inti juga sangat tersedia, kami sarankan Anda meluncurkan setidaknya empat node inti. Jika Anda memutuskan untuk meluncurkan cluster yang lebih kecil dengan tiga atau lebih sedikit node inti, setel dfs.replication parameter ke setidaknya 2 untuk HDFS agar memiliki replikasi DFS yang memadai. Untuk informasi selengkapnya, lihat Konfigurasi HDFS.

Awas

1. Pengaturan dfs.replication ke 1 pada cluster dengan kurang dari empat node dapat menyebabkan hilangnya data HDFS jika satu node turun. Kami menyarankan Anda menggunakan cluster dengan setidaknya empat node inti untuk beban kerja produksi.

2. Amazon EMR tidak akan mengizinkan cluster untuk menskalakan node inti di bawah ini. dfs.replication Misalnya, jikadfs.replication = 2, jumlah minimum node inti adalah 2.

3. Saat Anda menggunakan Penskalaan Terkelola, Penskalaan Otomatis, atau memilih untuk mengubah ukuran klaster secara manual, sebaiknya atur dfs.replication ke 2 atau lebih tinggi.

Pertimbangan untuk Mengatur Alarm pada Metrik:

• Amazon EMR tidak menyediakan metrik khusus aplikasi tentang HDFS atau YARN. Kami berkomentar bahwa Anda mengatur alarm untuk memantau jumlah instance node utama. Konfigurasikan alarm menggunakan CloudWatch metrik Amazon berikut:MultiMasterInstanceGroupNodesRunning,MultiMasterInstanceGroupNodesRunningPercentage, atau. MultiMasterInstanceGroupNodesRequested CloudWatch akan memberi tahu Anda jika terjadi kegagalan dan penggantian simpul primer.

  • Jika MultiMasterInstanceGroupNodesRunningPercentage lebih rendah dari 1,0 dan lebih besar dari 0,5, cluster mungkin telah kehilangan simpul utama. Dalam situasi ini, Amazon EMR mencoba mengganti simpul utama.

  • Jika MultiMasterInstanceGroupNodesRunningPercentage turun di bawah 0,5, dua node utama mungkin gagal. Dalam situasi ini, kuorum hilang dan cluster tidak dapat dipulihkan. Anda harus secara manual memigrasikan data dari klaster ini.

  Untuk informasi selengkapnya, lihat Mengatur alarm pada metrik.