Komponen klaster DAX

Cluster Amazon DynamoDB Accelerator (DAX) terdiri dari komponen infrastruktur. AWS Bagian ini menjelaskan komponen-komponen tersebut dan caranya bekerja sama.

Simpul

Simpul adalah blok pembangun klaster DAX terkecil. Setiap simpul menjalankan instans dari perangkat lunak DAX dan mempertahankan replika tunggal data cache.

Anda dapat menskalakan klaster DAX dengan salah satu dari dua cara berikut:

• Dengan menambahkan lebih banyak simpul ke klaster. Hal ini meningkatkan throughput pembacaan keseluruhan klaster.

• Dengan menggunakan jenis simpul yang lebih besar. Jenis simpul yang lebih besar memberikan kapasitas lebih banyak dan dapat meningkatkan throughput. (Anda harus membuat klaster baru dengan jenis simpul baru).

Setiap simpul dalam klaster adalah jenis simpul yang sama dan menjalankan perangkat lunak caching DAX yang sama. Untuk daftar jenis simpul yang tersedia, lihat Harga Amazon DynamoDB.

Klaster

Klaster adalah pengelompokan logis dari satu atau beberapa simpul yang dikelola DAX sebagai satu unit. Salah satu simpul dalam klaster ditetapkan sebagai simpul primer, dan simpul lainnya (jika ada) adalah replika baca.

Simpul primer bertanggung jawab untuk hal berikut:

• Memenuhi permintaan aplikasi untuk data cache.

• Menangani operasi penulisan ke DynamoDB.

• Menghapus data dari cache sesuai dengan kebijakan pengosongan klaster.

Ketika perubahan dilakukan pada data cache di simpul primer, DAX menyebarkan perubahan untuk semua simpul replika baca menggunakan log replikasi. Setelah konfirmasi diterima dari semua replika baca, DynamoDB menghapus log replikasi dari simpul primer.

Replika baca bertanggung jawab untuk hal berikut:

• Memenuhi permintaan aplikasi untuk data cache.

• Menghapus data dari cache sesuai dengan kebijakan pengosongan klaster.

Namun, tidak seperti simpul primer, replika baca tidak menulis ke DynamoDB.

Replika baca melayani dua tujuan tambahan:

• Skalabilitas. Jika ada sejumlah besar aplikasi klien yang perlu mengakses DAX secara bersamaan, Anda dapat menambahkan lebih banyak replika untuk penskalaan pembacaan. DAX menyebarkan beban secara merata di semua simpul di klaster. (Cara lain untuk meningkatkan throughput adalah dengan menggunakan jenis simpul cache yang lebih besar).

• Ketersediaan tinggi. Jika simpul primer mengalami kegagalan, DAX otomatis melakukan failover ke replika baca dan menetapkannya sebagai primer baru. Jika simpul replika gagal, simpul lain dalam klaster DAX masih dapat melayani permintaan hingga simpul yang mengalami kegagalan dapat dipulihkan. Untuk toleransi kesalahan maksimum, Anda harus melakukan deployment replika baca di Zona Ketersediaan terpisah. Konfigurasi ini memastikan bahwa klaster DAX Anda dapat terus berfungsi, meskipun seluruh Zona Ketersediaan menjadi tidak tersedia.

Klaster DAX dapat mendukung hingga 11 simpul per klaster (simpul primer ditambah maksimum 10 replika baca).

penting

Untuk penggunaan produksi, kami sangat menyarankan menggunakan DAX dengan setidaknya tiga simpul dan setiap simpul ditempatkan di Zona Ketersediaan yang berbeda. Tiga simpul diperlukan agar klaster DAX menjadi toleran terhadap kesalahan.

Satu klaster DAX dapat di-deploy dengan satu atau dua simpul untuk beban kerja pengembangan atau pengujian. Klaster dengan satu dan dua simpul tidak toleran terhadap kesalahan dan sebaiknya jangan menggunakan kurang dari tiga simpul untuk produksi. Jika klaster dengan satu atau dua simpul mengalami kesalahan perangkat lunak atau perangkat keras, klaster dapat menjadi tidak tersedia atau kehilangan data cache.

Wilayah dan zona ketersediaan

Cluster DAX di AWS Region hanya dapat berinteraksi dengan tabel DynamoDB yang berada di Region yang sama. Untuk alasan ini, pastikan bahwa Anda meluncurkan klaster DAX di Wilayah yang benar. Jika memiliki tabel DynamoDB di Wilayah lain, Anda juga harus meluncurkan klaster DAX di Wilayah tersebut.

Setiap Wilayah dirancang agar terisolasi sepenuhnya dari Wilayah lainnya. Setiap Wilayah terdiri dari beberapa Zona Ketersediaan. Dengan meluncurkan simpul Anda di berbagai Zona Ketersediaan, Anda dapat mencapai kemungkinan toleransi kesalahan terbesar.

penting

Jangan menempatkan semua simpul klaster Anda di satu Zona Ketersediaan. Dalam konfigurasi ini, klaster DAX Anda menjadi tidak tersedia jika ada kegagalan Zona Ketersediaan.

Untuk penggunaan produksi, kami sangat menyarankan menggunakan DAX dengan setidaknya tiga simpul dan setiap simpul ditempatkan di Zona Ketersediaan yang berbeda. Tiga simpul diperlukan agar klaster DAX menjadi toleran terhadap kesalahan.

Satu klaster DAX dapat di-deploy dengan satu atau dua simpul untuk beban kerja pengembangan atau pengujian. Klaster dengan satu dan dua simpul tidak toleran terhadap kesalahan dan sebaiknya jangan menggunakan kurang dari tiga simpul untuk produksi. Jika klaster dengan satu atau dua simpul mengalami kesalahan perangkat lunak atau perangkat keras, klaster dapat menjadi tidak tersedia atau kehilangan data cache.

Grup parameter

Grup parameter digunakan untuk mengelola pengaturan runtime klaster DAX. DAX memiliki beberapa parameter yang dapat Anda gunakan untuk mengoptimalkan performa (seperti menentukan kebijakan TTL untuk data cache). Grup parameter adalah set parameter bernama yang dapat Anda terapkan ke klaster. Dengan demikian, Anda dapat memastikan bahwa semua simpul dalam klaster tersebut dikonfigurasi dengan cara yang persis sama.

Grup keamanan

Klaster DAX berjalan di lingkungan Amazon Virtual Private Cloud (Amazon VPC). Lingkungan ini adalah jaringan virtual yang didedikasikan untuk AWS akun Anda dan diisolasi dari VPC lain. Grup keamanan bertindak sebagai firewall virtual untuk VPC Anda guna mengontrol lalu lintas masuk dan keluar.

Ketika meluncurkan sebuah klaster di VPC, Anda menambahkan aturan masuk ke grup keamanan Anda untuk mengizinkan lalu lintas jaringan masuk. Aturan masuk menentukan protokol (TCP) dan nomor port (8111) untuk klaster Anda. Setelah Anda menambahkan aturan ini ke grup keamanan, aplikasi yang berjalan dalam VPC Anda dapat mengakses klaster DAX.

ARN klaster

Setiap klaster DAX diberi Amazon Resource Name (ARN). Format ARN adalah sebagai berikut.

arn:aws:dax:region:accountID:cache/clusterName

Anda menggunakan ARN klaster dalam kebijakan IAM untuk menentukan izin operasi API DAX. Untuk informasi selengkapnya, lihat Kontrol akses DAX.

Titik akhir klaster

Setiap klaster DAX menyediakan klaster titik akhir untuk digunakan oleh aplikasi Anda. Dengan mengakses klaster menggunakan titik akhir, aplikasi Anda tidak perlu tahu nama host dan nomor port masing-masing simpul dalam klaster. Aplikasi Anda secara otomatis "mengetahui" semua simpul di klaster, bahkan jika Anda menambahkan atau menghapus replika baca.

Berikut adalah contoh titik akhir klaster di wilayah us-east-1 yang tidak dikonfigurasi untuk menggunakan enkripsi saat bergerak.

dax://my-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com

Berikut adalah contoh titik akhir klaster di wilayah yang sama yang dikonfigurasi untuk menggunakan enkripsi saat bergerak.

daxs://my-encrypted-cluster.l6fzcv.dax-clusters.us-east-1.amazonaws.com

Titik akhir simpul

Masing-masing simpul individu dalam klaster DAX memiliki nama host dan nomor port sendiri. Berikut adalah contoh titik akhir simpul.

myDAXcluster-a.2cmrwl.clustercfg.dax.use1.cache.amazonaws.com:8111

Aplikasi Anda dapat mengakses simpul langsung menggunakan titik akhirnya. Namun, sebaiknya Anda memperlakukan klaster DAX sebagai satu unit dan mengaksesnya menggunakan titik akhir klaster. Titik akhir klaster mengisolasi aplikasi Anda agar tidak perlu mengelola daftar simpul dan memastikan daftar selalu terbaru ketika Anda menambahkan atau menghapus simpul dari klaster.

Grup subnet

Akses ke simpul klaster DAX dibatasi untuk aplikasi yang berjalan di instans Amazon EC2 dalam lingkungan Amazon VPC. Anda dapat menggunakan grup subnet untuk memberikan akses klaster dari instans Amazon EC2 yang berjalan di subnet tertentu. Grup subnet adalah kumpulan subnet (biasanya privat) yang dapat ditetapkan untuk klaster Anda yang berjalan di lingkungan Amazon VPC.

Ketika membuat klaster DAX, Anda harus menentukan grup subnet. DAX menggunakan grup subnet tersebut untuk memilih subnet dan alamat IP dalam subnet tersebut yang akan dikaitkan dengan simpul Anda.

Peristiwa

DAX mencatat peristiwa penting dalam klaster Anda, seperti kegagalan untuk menambahkan simpul, keberhasilan dalam menambahkan simpul, atau perubahan pada grup keamanan. Dengan memantau peristiwa penting, Anda dapat mengetahui status klaster terbaru dan dapat mengambil tindakan korektif sesuai peristiwa tersebut. Anda dapat mengakses peristiwa ini menggunakan AWS Management Console atau DescribeEvents tindakan di API manajemen DAX.

Anda juga dapat meminta agar pemberitahuan dikirim ke topik Amazon Simple Notification Service (Amazon SNS). Dengan demikian, Anda akan segera mengetahui jika ada peristiwa yang terjadi di klaster DAX.

Periode pemeliharaan

Setiap cluster memiliki jendela pemeliharaan mingguan untuk menerapkan perubahan sistem. Karena perubahan diterapkan secara berurutan, node yang ada diganti dan node baru dengan perubahan yang diterapkan ditambahkan ke cluster. Selama periode ini, aplikasi Anda mungkin mengamati kesalahan sementara atau throttle. Oleh karena itu, kami menyarankan Anda menjadwalkan jendela pemeliharaan selama waktu penggunaan terendah Anda dan menyesuaikan jadwal ini secara berkala sesuai kebutuhan. Anda dapat menentukan rentang waktu dengan durasi hingga 24 jam. Selama waktu tersebut, aktivitas pemeliharaan yang Anda minta akan dilakukan.

Jika Anda tidak menentukan jendela pemeliharaan yang diinginkan saat membuat atau memodifikasi klaster cache, DAX menetapkan jendela pemeliharaan 60 menit pada hari kerja acak. Jendela pemeliharaan 60 menit ini dipilih secara acak dari blok waktu 8 jam untuk masing-masing. Wilayah AWS Tabel berikut mencantumkan blok waktu untuk tiap Wilayah dari periode waktu default yang ditetapkan.

Kode Wilayah	Nama Wilayah	Periode pemeliharaan
ap-northeast-1	Wilayah Asia Pacific (Tokyo)	13.00–21.00 UTC
ap-southeast-1	Wilayah Asia Pacific (Singapore)	14.00–22.00 UTC
ap-southeast-2	Wilayah Asia Pacific (Sydney)	12.00–20.00 UTC
ap-south-1	Wilayah Asia Pacific (Mumbai)	17.30–01.30 UTC
cn-northwest-1	Wilayah China (Ningxia)	23.00–07.00 UTC
cn-north-1	Wilayah Tiongkok (Beijing)	14.00–22.00 UTC
eu-central-1	Wilayah Eropa (Frankfurt)	23.00–07.00 UTC
eu-west-1	Wilayah Eropa (Irlandia)	22.00–06.00 UTC
eu-west-2	Wilayah Eropa (London)	23.00–07.00 UTC
eu-west-3	Wilayah Eropa (Paris)	23.00–07.00 UTC
sa-east-1	Wilayah South America (São Paulo)	01.00–09.00 UTC
us-east-1	Wilayah US East (N. Virginia)	03.00–11.00 UTC
us-east-2	Wilayah US East (Ohio)	23.00–07.00 UTC
us-west-1	Wilayah Barat AS (N. California)	06.00–14.00 UTC
us-west-2	Wilayah US West (Oregon)	06.00–14:00 UTC