Berpikir dalam hal mode kegagalan

Saat merancang aplikasi atau sistem yang sangat tersedia, Anda harus mempertimbangkan komponen apa yang mungkin gagal, dampak kegagalan komponen apa yang akan terjadi pada sistem, dan mekanisme apa yang dapat Anda terapkan untuk mengurangi atau menghilangkan dampak kegagalan komponen. Apakah aplikasi Anda berjalan di satu server, dalam satu rak, atau dalam satu pusat data? Apa yang akan terjadi ketika server, rak, atau pusat data mengalami kegagalan sementara atau permanen? Apa yang terjadi ketika ada kegagalan dalam sub-sistem kritis seperti jaringan atau dalam aplikasi itu sendiri? Ini adalah mode kegagalan.

Anda harus mempertimbangkan mode kegagalan di bagian ini saat merencanakan Outposts dan penerapan aplikasi Anda. Bagian berikut akan meninjau cara mengurangi mode kegagalan ini untuk memberikan peningkatan tingkat ketersediaan tinggi untuk lingkungan aplikasi Anda.

Mode kegagalan 1: Jaringan

Penyebaran Outpost bergantung pada koneksi yang tangguh ke Wilayah induknya untuk pengelolaan dan pemantauan. Gangguan jaringan dapat disebabkan oleh berbagai kegagalan seperti kesalahan operator, kegagalan peralatan, dan pemadaman penyedia layanan. Pos terdepan, yang mungkin terdiri dari satu atau lebih rak yang terhubung bersama di situs, dianggap terputus ketika tidak dapat berkomunikasi dengan Wilayah melalui Tautan Layanan.

Jalur jaringan yang berlebihan dapat membantu mengurangi risiko peristiwa pemutusan hubungan. Anda harus memetakan dependensi aplikasi dan lalu lintas jaringan untuk memahami dampak peristiwa pemutusan hubungan terhadap operasi beban kerja. Rencanakan redundansi jaringan yang memadai untuk memenuhi persyaratan ketersediaan aplikasi Anda.

Selama peristiwa pemutusan sambungan, instance yang berjalan di Outpost terus berjalan dan dapat diakses dari jaringan lokal melalui Outpost Local Gateway (). LGW Beban kerja dan layanan lokal mungkin terganggu atau gagal jika bergantung pada layanan di Wilayah. Permintaan mutasi (seperti memulai atau menghentikan instance di Pos Luar), operasi bidang kontrol, dan telemetri layanan (misalnya, CloudWatch metrik) akan gagal saat Pos Luar terputus dari Wilayah.

Mode kegagalan 2: Contoh

EC2Instans dapat menjadi terganggu atau gagal jika server yang mereka jalankan memiliki masalah atau jika instance mengalami kegagalan sistem operasi atau aplikasi. Bagaimana aplikasi menangani jenis kegagalan ini tergantung pada arsitektur aplikasi. Aplikasi monolitik biasanya menggunakan fitur aplikasi atau sistem untuk pemulihan sementara arsitektur berorientasi layanan modular atau layanan mikro biasanya menggantikan komponen yang gagal untuk mempertahankan ketersediaan layanan.

Anda dapat mengganti instans yang gagal dengan instans baru menggunakan mekanisme otomatis seperti grup Auto EC2 Scaling. Pemulihan otomatis instans dapat memulai ulang instance yang gagal karena kegagalan server asalkan ada kapasitas cadangan yang cukup tersedia di server yang tersisa.

Mode kegagalan 3: Hitung

Server dapat gagal atau menjadi terganggu dan mungkin perlu dikeluarkan dari operasi (sementara atau permanen) karena berbagai alasan, seperti kegagalan komponen dan operasi pemeliharaan terjadwal. Bagaimana layanan di rak Outposts menangani kegagalan dan kerusakan server bervariasi dan dapat bergantung pada bagaimana pelanggan mengonfigurasi opsi ketersediaan tinggi.

Anda harus memesan kapasitas komputasi yang cukup untuk mendukung model N+M ketersediaan, di mana N kapasitas yang M diperlukan dan kapasitas cadangan disediakan untuk mengakomodasi kegagalan server.

Penggantian perangkat keras untuk server yang gagal disediakan sebagai bagian dari layanan AWS Outposts rak yang dikelola sepenuhnya. AWS secara aktif memantau kesehatan semua server dan perangkat jaringan dalam penyebaran Outpost. Jika ada kebutuhan untuk melakukan perawatan fisik, AWS akan menjadwalkan waktu untuk mengunjungi situs Anda untuk mengganti komponen yang gagal. Penyediaan kapasitas cadangan memungkinkan Anda menjaga beban kerja tetap berjalan sementara server yang gagal dikeluarkan dari layanan dan diganti.

Mode kegagalan 4: Rak atau pusat data

Kegagalan rak dapat terjadi karena kehilangan total daya ke rak atau karena kegagalan lingkungan seperti hilangnya pendinginan atau kerusakan fisik pada pusat data akibat banjir atau gempa bumi. Kekurangan dalam arsitektur distribusi daya pusat data atau kesalahan selama pemeliharaan daya pusat data standar dapat mengakibatkan hilangnya daya ke satu atau lebih rak atau bahkan seluruh pusat data.

Skenario ini dapat dikurangi dengan menyebarkan infrastruktur ke beberapa lantai pusat data atau lokasi yang independen satu sama lain dalam kampus atau area metro yang sama.

Mengambil pendekatan ini dengan AWS Outposts rak akan memerlukan pertimbangan yang cermat tentang bagaimana aplikasi dirancang dan didistribusikan untuk berjalan di beberapa Outposts logis terpisah untuk menjaga ketersediaan aplikasi.

Mode kegagalan 5: Zona AWS Ketersediaan atau Wilayah

Setiap Pos Luar ditambatkan ke Availability Zone (AZ) tertentu dalam file. Wilayah AWS Kegagalan dalam jangkar AZ atau Wilayah induk dapat menyebabkan hilangnya manajemen Outpost dan mutabilitas dan dapat mengganggu komunikasi jaringan antara Outpost dan Region.

Mirip dengan kegagalan jaringan, kegagalan AZ atau Region dapat menyebabkan Outpost menjadi terputus dari Wilayah. Instance yang berjalan di Outpost terus berjalan dan dapat diakses dari jaringan lokal melalui Outpost Local Gateway (LGW) dan mungkin terganggu atau gagal jika mengandalkan layanan di Wilayah, seperti yang dijelaskan sebelumnya.

Untuk mengurangi dampak kegagalan AWS AZ dan Wilayah, Anda dapat menyebarkan beberapa Outpost yang masing-masing ditambatkan ke AZ atau Region yang berbeda. Anda kemudian dapat merancang beban kerja Anda untuk beroperasi dalam model penyebaran Multi-outpost terdistribusi menggunakan banyak mekanisme dan pola arsitektur serupa yang Anda gunakan untuk merancang dan menerapkan hari ini. AWS