Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
DAXkomponen cluster
Cluster Amazon DynamoDB Accelerator DAX () terdiri dari komponen infrastruktur. AWS Bagian ini menjelaskan komponen-komponen tersebut dan caranya bekerja sama.
Topik
Simpul
Node adalah blok bangunan terkecil dari sebuah DAX cluster. Setiap node menjalankan instance dari DAX perangkat lunak, dan memelihara replika tunggal dari data cache.
Anda dapat menskalakan DAX cluster Anda dengan salah satu dari dua cara:
-
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 node dalam cluster memiliki tipe node yang sama dan menjalankan perangkat lunak DAX caching yang sama. Untuk daftar jenis simpul yang tersedia, lihat Harga Amazon DynamoDB
Klaster
Cluster adalah pengelompokan logis dari satu atau lebih node yang DAX mengelola 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 pada node utama, DAX menyebarkan perubahan ke semua node 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 Anda memiliki sejumlah besar klien aplikasi yang perlu mengakses secara DAX bersamaan, Anda dapat menambahkan lebih banyak replika untuk penskalaan baca. DAXmenyebarkan beban secara merata di semua node di cluster. (Cara lain untuk meningkatkan throughput adalah dengan menggunakan jenis simpul cache yang lebih besar).
-
Ketersediaan tinggi. Jika terjadi kegagalan node primer, DAX secara otomatis gagal ke replika baca dan menetapkannya sebagai primer baru. Jika replika node gagal, node lain dalam DAX cluster masih dapat melayani permintaan sampai node gagal dapat dipulihkan. Untuk toleransi kesalahan maksimum, Anda harus melakukan deployment replika baca di Zona Ketersediaan terpisah. Konfigurasi ini memastikan bahwa DAX klaster Anda dapat terus berfungsi, meskipun seluruh Availability Zone menjadi tidak tersedia.
Sebuah DAX cluster dapat mendukung hingga 11 node per cluster (node utama ditambah maksimal 10 replika baca).
penting
Untuk penggunaan produksi, kami sangat menyarankan penggunaan DAX dengan setidaknya tiga node, di mana setiap node ditempatkan di Availability Zone yang berbeda. Tiga node diperlukan agar DAX cluster menjadi toleran terhadap kesalahan.
Sebuah DAX cluster dapat digunakan dengan satu atau dua node untuk pengembangan atau pengujian beban kerja. 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
Sebuah DAX cluster di AWS Region hanya dapat berinteraksi dengan tabel DynamoDB yang berada di Region yang sama. Untuk alasan ini, pastikan Anda meluncurkan DAX cluster Anda di Wilayah yang benar. Jika Anda memiliki tabel DynamoDB di Wilayah lain, Anda harus DAX meluncurkan cluster di Wilayah tersebut juga.
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, DAX klaster Anda menjadi tidak tersedia jika ada kegagalan Availability Zone.
Untuk penggunaan produksi, kami sangat menyarankan penggunaan DAX dengan setidaknya tiga node, di mana setiap node ditempatkan di Availability Zone yang berbeda. Tiga node diperlukan agar DAX cluster menjadi toleran terhadap kesalahan.
Sebuah DAX cluster dapat digunakan dengan satu atau dua node untuk pengembangan atau pengujian beban kerja. 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 untuk DAX cluster. DAXmemiliki beberapa parameter yang dapat Anda gunakan untuk mengoptimalkan kinerja (seperti mendefinisikan TTL kebijakan untuk data yang di-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
DAXCluster berjalan di lingkungan Amazon Virtual Private Cloud (AmazonVPC). Lingkungan ini adalah jaringan virtual yang didedikasikan untuk AWS akun Anda dan terisolasi dari yang lainVPCs. Grup keamanan bertindak sebagai firewall virtual untuk AndaVPC, memungkinkan Anda untuk mengontrol lalu lintas jaringan masuk dan keluar.
Saat meluncurkan klaster di dalamVPC, Anda menambahkan aturan masuk ke grup keamanan Anda untuk mengizinkan lalu lintas jaringan masuk. Aturan ingress menentukan protokol (TCP) dan nomor port (8111) untuk cluster Anda. Setelah Anda menambahkan aturan ini ke grup keamanan Anda, aplikasi yang berjalan di dalam Anda VPC dapat mengakses DAX cluster.
Cluster ARN
Setiap DAX cluster diberi Amazon Resource Name (ARN). ARNFormatnya adalah sebagai berikut.
arn:aws:dax:region:accountID:cache/clusterName
Anda menggunakan klaster ARN dalam IAM kebijakan untuk menentukan izin DAX API operasi. Untuk informasi selengkapnya, lihat DAXkontrol akses.
Titik akhir klaster
Setiap DAX cluster menyediakan endpoint cluster 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 node individu dalam sebuah DAX cluster 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, kami menyarankan Anda memperlakukan DAX cluster sebagai satu unit dan mengaksesnya menggunakan titik akhir cluster sebagai gantinya. 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 node DAX cluster dibatasi untuk aplikasi yang berjalan di EC2 instans Amazon dalam VPC lingkungan Amazon. Anda dapat menggunakan grup subnet untuk memberikan akses klaster dari EC2 instans Amazon yang berjalan pada subnet tertentu. Grup subnet adalah kumpulan subnet (biasanya pribadi) yang dapat Anda tentukan untuk cluster Anda yang berjalan di lingkungan Amazon. VPC
Saat Anda membuat DAX cluster, Anda harus menentukan grup subnet. DAXmenggunakan grup subnet itu untuk memilih subnet dan alamat IP dalam subnet itu untuk dikaitkan dengan node Anda.
Peristiwa
DAXmencatat peristiwa penting dalam cluster Anda, seperti kegagalan untuk menambahkan node, keberhasilan dalam menambahkan node, 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 acara ini menggunakan AWS Management Console atau DescribeEvents tindakan dalam DAX manajemenAPI.
Anda juga dapat meminta agar notifikasi dikirim ke topik Amazon Simple Notification Service (AmazonSNS) tertentu. Maka Anda akan segera tahu kapan suatu peristiwa terjadi di DAX cluster Anda.
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 disukai saat membuat atau memodifikasi cluster cache, DAX tetapkan 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 Pasifik (Tokyo) | 13:00 — 21:00 UTC |
| ap-southeast-1 | Wilayah Asia Pasifik (Singapura) | 14:00 — 22:00 UTC |
| ap-southeast-2 | Wilayah Asia Pasifik (Sydney) | 12:00 — 20:00 UTC |
| ap-south-1 | Wilayah Asia Pasifik (Mumbai) | 17:30 — 1:30 UTC |
| cn-northwest-1 | Wilayah Tiongkok (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-north-1 | Wilayah Eropa (Stockholm) | 01:00 — 09:00 UTC |
| eu-south-2 | Wilayah Eropa (Spanyol) | 21:00 — 05: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 AS Timur (Virginia Utara) | 03:00 — 11:00 UTC |
| us-east-2 | Wilayah AS Timur (Ohio) | 23:00 — 07:00 UTC |
| us-west-1 | Wilayah Barat AS (N. California) | 06:00 — 14:00 UTC |
| us-west-2 | Wilayah AS Barat (Oregon) | 06:00 — 14:00 UTC |
