S3 bölgesi kesintileri için bölgeler arası replikasyon% 100 aptal değil mi?

Amazon S3, bölge / bölge kesintilerine karşı oldukça hataya dayanıklı olması gereken bir çapraz bölge çoğaltma seçeneğine sahiptir.

Bu, kesintiyle ilgili olarak sıralananların bu yönü kullanmadığı anlamına mı geliyor?

Yoksa bu bölgeler arası çoğaltma tamamen kusursuz değildir ve yardımcı olmaz mıydı?

amazon-s3

— Dawny33
kaynak

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

— Evgeny

@Evgeny Teşekkür ederim. Bunu sormadan önce aynı

— gönderiyi okuyordum

Çoğaltma olduğunda sakınca, aşağıdaki nottan gelir:

Bölgeye özgü bitiş noktası yerine ABD Doğu (N. Virginia) uç noktasını (s3.amazonaws.com) kullanırsanız, Amazon S3 varsayılan olarak barındırılan tüm sanal stil isteklerini ABD Doğu (N. Virginia) bölgesine yönlendirir. örneğin, s3-eu-west-1.amazonaws.com).

Çoğaltmayı kullandığınızda, AWS'nin s3.amazonaws.comsunucularınızdan gelen REST isteğinizi hedefleyerek ve yönlendirmenin işini yapmasına izin vererek takma adı bir bölgeye yönlendirmeye izin verirsiniz .

N.Virginia her çöktüğünde sihir durur ve verilerinize erişmek için şansınız kalmaz ve belirli bir bölge bitiş noktası seçmek için yapılandırmanızı güncellemeniz gerekir.

Sorun DNS'den değil (grubun kendisine bir istek çalışır), ancak gruba erişmeden önce S3 API uç noktasına bağlanacak olan S3 istemcilerinden gelir, bu durumda dns çözünürlüğü yapılır s3.amazonaws.comve bu- doğu-1 uç noktası.

Bölge takma adını kullandığınızda, AWS'nin sağlık kontrolü dahil olan bölgeler üzerindeki yük dengeleme kolaylığını kaybedersiniz.

Hızlı geçiş yapmak için bölgeleri hedefleyen DNS cname kullanırsanız, DNS TTL'nizden siz sorumlusunuz, ancak istemci ISS'nin önbellek sunucularının değerinizi onurlandırmayacağını garanti etmez (müşterinizin karşılaşabileceği birçok önbellekten biri).

Ve son olarak, eğer dengeyi kendiniz yüklemeye çalışırsanız muhtemelen AWS'nin halihazırdaki bakım yükü ile aynı SPOF'u yaratabilirsiniz.

AWS üzerinde çalışıyor ancak yazarken sahip olduğum tüm bilgiler bu.

— Tensibai
kaynak

Göre docs.aws.amazon.com/AmazonS3/latest/dev/VirtualHosting.html o bucketname.s3-eu-west-1.amazonaws.com 'kullanmak DNS takma adı olarak (favori bölgeyi yerine) mümkündür. Çalışan IFF, hızlı bir şekilde geçiş yapmanın bir yolu olabilir (önceden ayarlanmış TTL'nizin izin verdiği kadar hızlı)

— Michael Bravo

@MichaelBravo endişenizi gidermek için cevabı uzattı :)

— Tensibai

"Teorik olarak CNAME'yi bölge uç noktalarında kullanabilseniz bile, yetkili cevap N.Virginia'daki hizmete bildiğim kadarıyla okuduğum kadar güveniyor" ABD Doğu bölgesine yönlendirme hakkında alıntı alıyorsunuz varsayılan olarak bağlam dışı. Grup var olmadan example-bucket, example-bucket.s3.amazonaws.comzaten DNS'de ABD Doğu'ya işaret ediyor. İlk grup oluşturma işleminden birkaç dakika sonra, bu kalıcı olarak doğru bölgesel bitiş noktasına işaret edecek şekilde değişir. Buradaki uyarı, bu ana bilgisayar adının başlangıçta kova oluşturulduktan hemen sonra kısa bir süre yanlış yönlendirilebileceğidir - daha sonra değil.

— Michael - sqlbot

... bu nedenle "N.Virginia ne zaman kapalıysa, sihir durur ve DNS diğer adı yöntemiyle herhangi bir bölgedeki verilerinize erişme şansınız kalmaz" bu nedenle yanlıştır. Diğer bölgelerdeki kovalar, bu ana bilgisayar adı stili kullanılarak başvurulanlar da dahil olmak üzere us-east-1 kesintisinden etkilenmedi.

— Michael - sqlbot

Hayır. s3.amazonaws.comKova oluşturulduktan sonraki birkaç dakika içinde bölgedeki grubunuzun DNS girişini değiştirirler ve bu değişiklik bizden-doğu-1'den bağımsız olarak devam eder. Başka bir bölgede bir kova oluşturun ve kova oluşturmadan your-bucket-name.s3.amazonaws.comönce, sırasında ve birkaç dakika sonra nasıl çözümlendiğini izleyin . s3-1.amazonaws.comKova oluşturulduktan sonra bu bilgiler Rota 53'teki bölgeye aktarılır ve orada bize-doğu-1'e daha fazla güvenmeksizin devam eder.

— Michael - sqlbot

Birçok büyük şirket bu özelliği kullanmamakta hataya düşebilir. Ek maliyet ekler ve tarihsel olarak her türlü gerçek felaket kurtarma çözümü uygulansa bile test edilmez.

Maliyet sorunu dışında, bölgeler arası çoğaltmayı aktif olarak kullanan şirketler, bir nesnenin çoğalması için gereken gecikme konusunda geçerli bir endişe sunabilir. S3, çoğaltılan nesnelerde yazma sonrası okuma tutarlılığına izin vermez (bildiğim kadarıyla), tek bir bölgedeki bir kova için izin verir.

Bu SE sorusu , nesnelerin düzgün bir şekilde çoğaltılmadığı veya çoğaltılması çok uzun sürdüğü konusunda endişe yaratır. Bölgeler arası çoğaltmanın nihai bir tutarlılık modunda yapılması şartıyla, ele alınması gereken birçok endişe vardır.

— Evgeny
kaynak

S3 çapraz bölge replikasyonunun bazı operasyonlar için nihai tutarlılık sunduğuna daha fazla önem vereceğim . Bunu hesaba katmak hiç de kolay değil . Uygulamaya bağlı olarak, düpedüz kabul edilemez olabilir. Her durumda, kusursuz değildir (birisi sihrini varsayarsa daha büyük sorunlara yol açabilir)

— Alexandre