Apakah replikasi lintas-wilayah 100% -bodoh untuk pemadaman wilayah S3?

Amazon S3 memiliki opsi replikasi lintas-wilayah yang harusnya cukup toleran terhadap gangguan penghentian wilayah / zona.

Apakah itu berarti mereka yang mengomel tentang pemadaman tidak memanfaatkan aspek ini?

Atau apakah replikasi lintas wilayah tidak sepenuhnya bodoh dan tidak akan membantu?

amazon-s3

— Dawny33
sumber

terkait: devops.stackexchange.com/questions/83/…

— Evgeny

@ Evgeny Terima kasih. Saya membaca posting yang sama, sebelum menanyakan hal ini :)

— Dawny33

Kekurangan ketika ada replikasi berasal dari catatan di bawah ini:

Amazon S3 merutekan permintaan gaya host virtual apa pun ke wilayah AS Timur (N. Virginia) secara default jika Anda menggunakan titik akhir AS Timur (N. Virginia) (s3.amazonaws.com), alih-alih titik akhir khusus kawasan (untuk contoh, s3-eu-west-1.amazonaws.com).

Ketika Anda menggunakan replikasi, Anda biasanya membiarkan AWS menangani perutean alias ke satu wilayah dengan menargetkan s3.amazonaws.compermintaan REST Anda dari server Anda dan membiarkan pengalihan melakukan pekerjaannya.

Setiap kali N.Virginia turun, keajaiban berhenti bekerja dan Anda kurang beruntung untuk mengakses data Anda dan harus memperbarui konfigurasi Anda untuk memilih titik akhir wilayah tertentu.

Masalahnya bukan berasal dari DNS (permintaan ke ember itu sendiri akan berfungsi) tetapi dari klien S3, yang akan terhubung ke titik akhir S3 API sebelum mengakses ember, dalam hal ini resolusi dns dilakukan s3.amazonaws.comdan ini adalah titik akhir timur-1.

Ketika Anda menggunakan daerah alias, Anda kehilangan kemudahan penyeimbangan beban atas daerah dengan cek kesehatan dari AWS disertakan.

Jika Anda menggunakan DNS cname yang menargetkan wilayah untuk berpindah dengan cepat, Anda bertanggung jawab atas DNS TTL Anda, tetapi tidak ada yang menjamin server cache dari ISP klien akan menghargai nilai Anda (salah satu dari banyak cache yang mungkin ditemui klien Anda).

Dan terakhir, jika Anda mencoba memuat keseimbangan sendiri, Anda mungkin akan membuat SPOF yang sama dari AWS dengan beban tambahan untuk mempertahankannya.

AWS sedang mengusahakannya tetapi itu semua informasi yang saya miliki saat penulisan.

— Tensibai
sumber

Menurut docs.aws.amazon.com/AmazonS3/latest/dev/VirtualHosting.html dimungkinkan untuk menggunakan 'bucketname.s3-eu-west-1.amazonaws.com' (gantikan wilayah favorit Anda) sebagai alias DNS. IFF yang berfungsi, ini bisa menjadi cara untuk beralih dengan cepat (secepat TTL yang telah ditentukan sebelumnya)

— Michael Bravo

@MichaelBravo memberikan jawaban untuk menjawab kekhawatiran Anda :)

— Tensibai

"Sekalipun secara teori Anda bisa menggunakan CNAME ke titik akhir wilayah, jawaban resmi bergantung pada layanan di N.Virginia sejauh yang saya tahu dan saya sudah membacanya" Anda menerima kutipan tentang perutean ke wilayah AS Timur secara default di luar konteks. Sebelum example-bucketember ada, example-bucket.s3.amazonaws.comsudah menunjuk ke AS Timur di DNS. Dalam beberapa menit setelah pembuatan bucket awal, ini berubah secara permanen untuk menunjuk ke titik akhir regional yang benar. Peringatan di sini adalah bahwa nama host ini awalnya dapat disalahartikan secara singkat segera setelah pembuatan bucket - tidak lebih baru.

— Michael - sqlbot

... jadi "Setiap kali N.Virginia turun, keajaiban berhenti bekerja dan Anda kurang beruntung untuk mengakses data Anda di wilayah mana pun dengan metode alias DNS" karena itu tidak benar. Bucket di wilayah lain tidak terpengaruh oleh pemadaman us-east-1, termasuk yang dirujuk menggunakan gaya nama host ini.

— Michael - sqlbot

Tidak, tidak. Mereka mengubah entri DNS untuk bucket Anda di s3.amazonaws.comzona dalam beberapa menit setelah pembuatan bucket, dan perubahan ini berlanjut secara independen dari us-east-1. Buat ember di wilayah lain dan perhatikan bagaimana your-bucket-name.s3.amazonaws.compenyelesaiannya sebelum, selama, dan beberapa menit setelah pembuatan bucket. Informasi didorong ke s3-1.amazonaws.comzona di Rute 53 setelah pembuatan ember dan bertahan di sana, tanpa bergantung lebih lanjut pada kami-timur-1.

— Michael - sqlbot

Banyak perusahaan besar yang salah karena tidak menggunakan fitur ini. Itu memang menambah biaya tambahan, dan secara historis segala jenis solusi pemulihan bencana nyata tidak teruji meskipun diimplementasikan.

Selain masalah biaya, perusahaan yang secara aktif menggunakan replikasi lintas wilayah dapat menawarkan kekhawatiran yang valid mengenai latensi yang diperlukan suatu objek untuk mereplikasi. S3 tidak mengizinkan (sejauh yang saya tahu) konsistensi baca-setelah-tulis pada objek yang direplikasi, sementara itu memungkinkan untuk bucket di satu wilayah.

Pertanyaan SE ini menimbulkan kekhawatiran di mana objek tidak direplikasi dengan benar, atau terlalu lama untuk ditiru. Asalkan replikasi lintas wilayah dilakukan dalam mode konsistensi akhirnya, ada banyak kekhawatiran untuk diatasi.

— Evgeny
sumber

Saya akan lebih menekankan fakta bahwa replikasi lintas-wilayah S3 menawarkan konsistensi akhirnya untuk beberapa operasi. Itu tidak sepele untuk diperhitungkan. Bergantung pada aplikasinya, mungkin ini benar-benar tidak dapat diterima. Bagaimanapun, itu bukan bukti bodoh (dapat menyebabkan masalah yang lebih besar jika seseorang menganggap itu sihir)

— Alexandre