Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Ketahanan di tepi

Pilar keandalan mencakup kemampuan beban kerja untuk menjalankan fungsi yang dimaksudkan dengan benar dan konsisten ketika diharapkan. Ini termasuk kemampuan untuk mengoperasikan dan menguji beban kerja melalui siklus hidupnya. Dalam hal ini, ketika Anda mendesain arsitektur tangguh di tepi, Anda harus terlebih dahulu mempertimbangkan infrastruktur mana yang akan Anda gunakan untuk menerapkan arsitektur itu. Ada tiga kemungkinan kombinasi untuk diterapkan dengan menggunakan AWS Local Zone dan AWS Outposts: Outpost to Outpost, Outpost to Local Zone, dan Local Zone to Local Zone, seperti yang diilustrasikan dalam diagram berikut. Meskipun ada kemungkinan lain untuk arsitektur tangguh, seperti menggabungkan layanan AWS edge dengan infrastruktur lokal tradisional atau Wilayah AWS, panduan ini berfokus pada tiga kombinasi ini yang berlaku untuk desain layanan cloud hybrid

Pertimbangan infrastruktur

Pada AWS, salah satu prinsip inti dari desain layanan adalah untuk menghindari satu titik kegagalan dalam infrastruktur fisik yang mendasarinya. Karena prinsip ini, AWS perangkat lunak dan sistem menggunakan beberapa Availability Zone dan tahan terhadap kegagalan satu zona. Di edge, AWS menawarkan infrastruktur yang didasarkan pada Local Zones dan Outposts. Oleh karena itu, faktor penting dalam memastikan ketahanan dalam desain infrastruktur adalah menentukan di mana sumber daya aplikasi digunakan.

Local Zones

Local Zones bertindak mirip dengan Availability Zone di dalamnya Wilayah AWS, karena mereka dapat dipilih sebagai lokasi penempatan untuk AWS sumber daya zona seperti subnet dan EC2 instance. Namun, mereka tidak terletak di Wilayah AWS, tetapi dekat dengan populasi besar, industri, dan pusat TI di mana tidak Wilayah AWS ada saat ini. Meskipun demikian, mereka masih mempertahankan bandwidth tinggi, koneksi aman antara beban kerja lokal di Zona Lokal dan beban kerja yang berjalan di. Wilayah AWS Oleh karena itu, Anda harus menggunakan Local Zones untuk menerapkan beban kerja yang lebih dekat ke pengguna Anda untuk persyaratan latensi rendah.

Outposts

AWS Outposts adalah layanan yang dikelola sepenuhnya yang memperluas AWS infrastruktur,, Layanan AWS APIs, dan alat ke pusat data Anda. Infrastruktur perangkat keras yang sama yang AWS Cloud digunakan di diinstal di pusat data Anda. Outposts kemudian terhubung ke yang terdekat. Wilayah AWS Anda dapat menggunakan Outposts untuk mendukung beban kerja Anda yang memiliki latensi rendah atau persyaratan pemrosesan data lokal.

Zona Ketersediaan Orang Tua

Setiap Zona Lokal atau Pos Luar memiliki Wilayah induk (juga disebut sebagai Wilayah asal). Wilayah induk adalah tempat bidang kontrol infrastruktur AWS tepi (Outpost atau Local Zone) berlabuh. Dalam kasus Local Zones, Wilayah induk adalah komponen arsitektur fundamental dari Zona Lokal dan tidak dapat dimodifikasi oleh pelanggan. AWS Outposts memperluas AWS Cloud ke lingkungan lokal Anda, jadi Anda harus memilih Wilayah dan Zona Ketersediaan tertentu selama proses pemesanan. Pilihan ini menambatkan bidang kontrol penyebaran Outposts Anda ke infrastruktur yang dipilih. AWS

Ketika Anda mengembangkan arsitektur ketersediaan tinggi di edge, Wilayah induk dari infrastruktur ini, seperti Outposts atau Local Zones, harus sama, sehingga VPC dapat diperpanjang di antara mereka. VPC yang diperluas ini adalah dasar untuk menciptakan arsitektur ketersediaan tinggi ini. Saat Anda menentukan arsitektur yang sangat tangguh, inilah mengapa Anda harus memvalidasi Wilayah induk dan Zona Ketersediaan Wilayah tempat layanan akan (atau sedang) ditambatkan. Seperti yang diilustrasikan dalam diagram berikut, jika Anda ingin menerapkan solusi ketersediaan tinggi antara dua Outposts, Anda harus memilih dua Availability Zone yang berbeda untuk jangkar Outposts. Ini memungkinkan arsitektur multi-AZ dari perspektif bidang kontrol. Jika Anda ingin menerapkan solusi yang sangat tersedia yang menyertakan satu atau beberapa Local Zones, Anda harus terlebih dahulu memvalidasi Availability Zone induk tempat infrastruktur ditambatkan. Untuk tujuan ini, gunakan AWS CLI perintah berikut:

aws ec2 describe-availability-zones --zone-ids use1-mia1-az1

Output dari perintah sebelumnya:

{     "AvailabilityZones": [         
          {
             "State": "available",
             "OptInStatus": "opted-in",
             "Messages": [],
             "RegionName": "us-east-1",
             "ZoneName": "us-east-1-mia-1a",
             "ZoneId": "use1-mia1-az1",
             "GroupName": "us-east-1-mia-1",
             "NetworkBorderGroup": "us-east-1-mia-1",
             "ZoneType": "local-zone",
             "ParentZoneName": "us-east-1d",
             "ParentZoneId": "use1-az2"
         }
     ]
 }

Dalam contoh ini, Miami Local Zone (us-east-1d-mia-1a1) ditambatkan di Availability Zone. us-east-1d-az2 Oleh karena itu, jika Anda perlu membuat arsitektur tangguh di tepi, Anda harus memastikan bahwa infrastruktur sekunder (baik Outposts atau Local Zones) ditambatkan ke Availability Zone selain. us-east-1d-az2 Misalnya, us-east-1d-az1 akan valid.

Diagram berikut memberikan contoh infrastruktur tepi yang sangat tersedia.

Pertimbangan jaringan

Bagian ini membahas pertimbangan awal untuk jaringan di tepi, terutama untuk koneksi untuk mengakses infrastruktur tepi. Ini meninjau arsitektur yang valid yang menyediakan jaringan tangguh untuk tautan layanan.

Jaringan ketahanan untuk Local Zones

Local Zones terhubung ke Wilayah induk dengan banyak tautan, redundan, aman, berkecepatan tinggi yang memungkinkan Anda menggunakan layanan Regional apa pun, seperti Amazon S3 dan Amazon RDS, dengan mulus. Anda bertanggung jawab untuk menyediakan konektivitas dari lingkungan lokal atau pengguna ke Zona Lokal. Terlepas dari arsitektur konektivitas yang Anda pilih (misalnya, VPN atau AWS Direct Connect), latensi yang harus dicapai melalui tautan jaringan harus setara untuk menghindari dampak apa pun pada kinerja aplikasi jika terjadi kegagalan pada tautan utama. Jika Anda menggunakan AWS Direct Connect, arsitektur ketahanan yang berlaku sama dengan yang digunakan untuk mengakses, seperti yang didokumentasikan dalam Wilayah AWS rekomendasi ketahanan.AWS Direct Connect Namun, ada skenario yang sebagian besar berlaku untuk Local Zones internasional. Di negara di mana Zona Lokal diaktifkan, hanya memiliki satu AWS Direct Connect PoP membuat tidak mungkin untuk membuat arsitektur yang direkomendasikan untuk AWS Direct Connect ketahanan. Jika Anda hanya memiliki akses ke satu AWS Direct Connect lokasi atau memerlukan ketahanan di luar satu koneksi, Anda dapat membuat alat VPN di Amazon EC2 dan AWS Direct Connect, seperti yang diilustrasikan dan dibahas dalam posting AWS blog Mengaktifkan konektivitas yang sangat tersedia dari tempat ke lokasi. AWS Local Zone

Jaringan ketahanan untuk Outposts

Berbeda dengan Local Zones, Outposts memiliki konektivitas redundan untuk mengakses beban kerja yang digunakan di Outposts dari jaringan lokal Anda. Redundansi ini dicapai melalui dua perangkat jaringan Outposts (). ONDs Setiap OND membutuhkan setidaknya dua koneksi serat pada 1 Gbps, 10 Gbps, 40 Gbps, atau 100 Gbps ke jaringan lokal Anda. Koneksi ini harus dikonfigurasi sebagai grup agregasi tautan (LAG) untuk memungkinkan penambahan lebih banyak tautan yang dapat diskalakan.

Untuk informasi selengkapnya tentang konektivitas ini, lihat Konektivitas jaringan lokal untuk Rak Outposts dalam dokumentasi. AWS Outposts

Untuk pengalaman dan ketahanan yang optimal, AWS merekomendasikan agar Anda menggunakan konektivitas redundan minimal 500 Mbps (1 Gbps lebih baik) untuk koneksi tautan layanan ke. Wilayah AWS Anda dapat menggunakan AWS Direct Connect atau koneksi internet untuk tautan layanan. Minimum ini memungkinkan Anda meluncurkan EC2 instans, melampirkan volume EBS, dan mengakses Layanan AWS, seperti Amazon EKS, Amazon EMR, dan metrik. CloudWatch

Diagram berikut menggambarkan arsitektur ini untuk koneksi pribadi yang sangat tersedia.

Diagram berikut menggambarkan arsitektur ini untuk koneksi publik yang sangat tersedia.

Menskalakan penyebaran rak Outposts dengan rak ACE

Rak Aggregation, Core, Edge (ACE) berfungsi sebagai titik agregasi penting untuk penyebaran AWS Outposts multi-rak, dan terutama direkomendasikan untuk instalasi yang melebihi tiga rak atau untuk merencanakan ekspansi di masa depan. Setiap rak ACE memiliki empat router yang mendukung koneksi 10 Gbps, 40 Gbps, dan 100 Gbps (100 Gbps optimal). Setiap rak dapat terhubung ke hingga empat perangkat pelanggan hulu untuk redundansi maksimum. Rak ACE mengkonsumsi daya hingga 10 kVA dan berat hingga 705 lbs. Manfaat utama termasuk berkurangnya kebutuhan jaringan fisik, uplink kabel serat yang lebih sedikit, dan penurunan antarmuka virtual VLAN. AWS memantau rak-rak ini melalui data telemetri melalui terowongan VPN dan bekerja sama dengan pelanggan selama instalasi untuk memastikan ketersediaan daya yang tepat, konfigurasi jaringan, dan penempatan optimal. Arsitektur rak ACE memberikan nilai yang meningkat seiring dengan skala penerapan, dan secara efektif menyederhanakan konektivitas sekaligus mengurangi kompleksitas dan persyaratan port fisik dalam instalasi yang lebih besar.  Untuk informasi lebih lanjut, lihat posting AWS blog Scaling AWS Outposts rack deployment dengan ACE Rack.

Mendistribusikan Instance di Outposts dan Local Zones

Outposts dan Local Zones memiliki jumlah server komputasi yang terbatas. Jika aplikasi Anda menerapkan beberapa instance terkait, instance ini dapat diterapkan di server yang sama atau di server di rak yang sama kecuali jika dikonfigurasi secara berbeda. Selain opsi default, Anda dapat mendistribusikan instance di seluruh server untuk mengurangi risiko menjalankan instance terkait pada infrastruktur yang sama. Anda juga dapat mendistribusikan instance di beberapa rak dengan menggunakan grup penempatan partisi. Ini disebut model distribusi rak penyebaran. Gunakan distribusi otomatis untuk menyebarkan instance di seluruh partisi dalam grup, atau gunakan instance ke partisi target yang dipilih. Dengan menerapkan instance ke partisi target, Anda dapat menyebarkan sumber daya yang dipilih ke rak yang sama sambil mendistribusikan sumber daya lain di seluruh rak. Outposts juga menyediakan opsi lain yang disebut spread host yang memungkinkan Anda mendistribusikan beban kerja Anda di tingkat host. Diagram berikut menunjukkan opsi distribusi spread rack dan spread host.

Amazon RDS Multi-AZ di AWS Outposts

Saat Anda menggunakan penerapan instans Multi-AZ di Outposts, Amazon RDS membuat dua instance database di dua Outpost. Setiap Pos Luar berjalan pada infrastruktur fisiknya sendiri dan terhubung ke Zona Ketersediaan yang berbeda di suatu Wilayah untuk ketersediaan tinggi. Ketika dua Outposts terhubung melalui koneksi lokal yang dikelola pelanggan, Amazon RDS mengelola replikasi sinkron antara instance database primer dan standby. Jika terjadi kegagalan perangkat lunak atau infrastruktur, Amazon RDS secara otomatis mempromosikan instans siaga ke peran utama dan memperbarui catatan DNS untuk menunjuk ke instance utama yang baru. Untuk penerapan multi-AZ, Amazon RDS membuat instans DB utama di satu Pos Luar dan mereplikasi data secara sinkron ke instans DB siaga di Pos Luar yang berbeda. Penerapan multi-AZ di Outposts beroperasi seperti penerapan Multi-AZ di, dengan perbedaan berikut: Wilayah AWS

Penerapan multi-AZ tersedia untuk semua versi MySQL dan PostgreSQL yang didukung di Amazon RDS di Outposts. Pencadangan lokal tidak didukung untuk penerapan Multi-AZ.

Diagram berikut menunjukkan arsitektur untuk Amazon RDS pada konfigurasi Multi-AZ Outposts.

Mekanisme failover

Load balancing dan penskalaan otomatis

Elastic Load Balancing (ELB) secara otomatis mendistribusikan lalu lintas aplikasi masuk Anda di semua EC2 instance yang Anda jalankan. ELB membantu mengelola permintaan masuk dengan merutekan lalu lintas secara optimal sehingga tidak ada satu instance pun yang kewalahan. Untuk menggunakan ELB dengan grup Amazon EC2 Auto Scaling Anda, lampirkan penyeimbang beban ke grup Auto Scaling Anda. Ini mendaftarkan grup dengan penyeimbang beban, yang bertindak sebagai titik kontak tunggal untuk semua lalu lintas web yang masuk ke grup Anda. Bila Anda menggunakan ELB dengan grup Auto Scaling Anda, Anda tidak perlu mendaftarkan instans EC2 individual dengan load balancer. Instance yang diluncurkan oleh grup Auto Scaling Anda secara otomatis terdaftar dengan load balancer. Demikian pula, instance yang dihentikan oleh grup Auto Scaling Anda secara otomatis dideregistrasi dari penyeimbang beban. Setelah melampirkan penyeimbang beban ke grup Auto Scaling, Anda dapat mengonfigurasi grup untuk menggunakan metrik ELB (seperti jumlah permintaan Application Load Balancer per target) untuk menskalakan jumlah instance dalam grup saat permintaan berfluktuasi. Secara opsional, Anda dapat menambahkan pemeriksaan kesehatan ELB ke grup Auto Scaling sehingga Amazon Auto EC2 Scaling dapat mengidentifikasi dan mengganti instans yang tidak sehat berdasarkan pemeriksaan kesehatan ini. Anda juga dapat membuat CloudWatch alarm Amazon yang memberi tahu Anda jika jumlah host yang sehat dari grup target lebih rendah dari yang diizinkan.

Diagram berikut menggambarkan bagaimana Application Load Balancer mengelola beban kerja di EC2 Amazon. AWS Outposts

Diagram berikut menggambarkan arsitektur serupa untuk Amazon EC2 di Local Zones.

Amazon Route 53 untuk failover DNS

Jika Anda memiliki lebih dari satu sumber daya yang menjalankan fungsi yang sama—misalnya, beberapa server HTTP atau mail—Anda dapat mengonfigurasi Amazon Route 53 untuk memeriksa kesehatan sumber daya Anda dan menanggapi kueri DNS hanya dengan menggunakan sumber daya yang sehat. Sebagai contoh, mari kita asumsikan bahwa situs web Anda,example.com, dihosting di dua server. Satu server berada di Zona Lokal dan server lainnya berada di Pos Luar. Anda dapat mengonfigurasi Route 53 untuk memeriksa kesehatan server tersebut dan untuk menanggapi kueri DNS example.com dengan hanya menggunakan server yang saat ini sehat. Jika Anda menggunakan catatan alias untuk merutekan lalu lintas ke AWS sumber daya yang dipilih, seperti penyeimbang beban ELB, Anda dapat mengonfigurasi Route 53 untuk mengevaluasi kesehatan sumber daya dan merutekan lalu lintas hanya ke sumber daya yang sehat. Saat Anda mengonfigurasi catatan alias untuk mengevaluasi kesehatan sumber daya, Anda tidak perlu membuat pemeriksaan kesehatan untuk sumber daya tersebut.

Diagram berikut menggambarkan mekanisme failover Route 53.

Amazon Route 53 Resolver pada AWS Outposts

Amazon Route 53 Resolvertersedia di rak Outposts. Ini menyediakan layanan dan aplikasi lokal Anda dengan resolusi DNS lokal langsung dari Outposts. Titik akhir Resolver Rute 53 Lokal juga mengaktifkan resolusi DNS antara Outposts dan server DNS lokal Anda. Resolver Route 53 di Outposts membantu meningkatkan ketersediaan dan kinerja aplikasi lokal Anda.

Salah satu kasus penggunaan umum untuk Outposts adalah untuk menyebarkan aplikasi yang memerlukan akses latensi rendah ke sistem lokal, seperti peralatan pabrik, aplikasi perdagangan frekuensi tinggi, dan sistem diagnosis medis.

Ketika Anda memilih untuk menggunakan Resolver Route 53 lokal di Outposts, aplikasi dan layanan akan terus mendapat manfaat dari resolusi DNS lokal untuk menemukan layanan lain, bahkan jika konektivitas ke orang tua hilang. Wilayah AWS Local Resolvers juga membantu mengurangi latensi untuk resolusi DNS karena hasil kueri di-cache dan disajikan secara lokal dari Outposts, yang menghilangkan perjalanan pulang-pergi yang tidak perlu ke induk. Wilayah AWS Semua resolusi DNS untuk aplikasi di Outposts VPCs yang menggunakan DNS pribadi disajikan secara lokal.

Selain mengaktifkan Resolver lokal, peluncuran ini juga memungkinkan titik akhir Resolver lokal. Titik akhir keluar Route 53 Resolver memungkinkan Resolver Route 53 untuk meneruskan kueri DNS ke resolver DNS yang Anda kelola―misalnya, di jaringan lokal Anda. Sebaliknya, titik akhir masuk Route 53 Resolver meneruskan kueri DNS yang mereka terima dari luar VPC ke Resolver yang berjalan di Outposts. Ini memungkinkan Anda untuk mengirim kueri DNS untuk layanan yang digunakan pada VPC Outposts pribadi dari luar VPC itu. Untuk informasi selengkapnya tentang titik akhir masuk dan keluar, lihat Menyelesaikan kueri DNS antara VPCs dan jaringan Anda di dokumentasi Route 53.