A replicação entre regiões é 100% à prova de falhas para interrupções na região S3?

19

O Amazon S3 tem uma opção de replicação entre regiões, que deve ser bastante tolerante a falhas contra interrupções na região / zona.

Isso significa que aqueles que estão reclamando da interrupção não fizeram uso desse aspecto?

Ou é que a replicação entre regiões não é completamente infalível e não teria ajudado?

amazon-s3 Dawny33
fonte
related: devops.stackexchange.com/questions/83/...
Evgeny
@Evgeny Obrigado. Eu estava lendo naquele mesmo post, antes de pedir este :)
Dawny33

Respostas:

11

A desvantagem quando há replicação vem da nota abaixo:

O Amazon S3 roteia qualquer solicitação no estilo hospedado virtual para a região Leste dos EUA (N. Virginia) por padrão, se você usar o ponto de extremidade Leste dos EUA (N. Virgínia) (s3.amazonaws.com), em vez do ponto de extremidade específico da região (para exemplo, s3-eu-west-1.amazonaws.com).

Quando você usa a replicação, geralmente deixa a AWS cuidar do roteamento do alias para uma região, direcionando s3.amazonaws.comsua solicitação REST de seus servidores e permitindo que o redirecionamento faça seu trabalho.

Sempre que a N.Virginia estiver inativa, a mágica deixará de funcionar e você não terá sorte em acessar seus dados e precisará atualizar sua configuração para escolher um terminal de região específico.

O problema não vem do DNS (uma solicitação para o próprio bucket funcionará), mas dos clientes S3, que se conectam ao ponto de extremidade da API S3 antes de acessar o bucket. Nesse caso, a resolução do DNS é feita s3.amazonaws.come isso é útil. ponto final leste-1.

Ao usar o alias de região, você perde a facilidade do balanceamento de carga nas regiões com a verificação de integridade da AWS incluída.

Se você usar o cname DNS direcionado às regiões para alternar rapidamente, será responsável pelo TTL do DNS, mas nada garante que os servidores de cache do ISP do cliente honrem seu valor (um dos muitos cache que seu cliente pode encontrar).

E, por último, se você tentar se equilibrar na carga, provavelmente criará o mesmo SPOF que a AWS já possui com a carga adicional de mantê-lo.

A AWS está trabalhando nisso, mas essas são todas as informações que tenho no momento em que escrevo.

Tensibai
fonte
De acordo com docs.aws.amazon.com/AmazonS3/latest/dev/VirtualHosting.html , é possível usar 'bucketname.s3-eu-west-1.amazonaws.com' (substitua sua região favorita) como um apelido de DNS. IFF que as obras, pode ser uma maneira de mudar rapidamente (tão rápido quanto o seu TTL pré-set permite)
Michael Bravo
@MichaelBravo estendido a resposta para resolver a sua preocupação :)
Tensibai
"Mesmo que, em teoria, você possa usar CNAME para terminais de região, a resposta autorizada depende do serviço em N.Virginia até onde eu sei e já li sobre ele" Você está usando a citação sobre roteamento para a região leste dos EUA por padrão, fora de contexto. Antes de o example-bucketbucket existir, example-bucket.s3.amazonaws.comjá aponta para o leste dos EUA no DNS. Alguns minutos após a criação inicial do bucket, isso muda permanentemente para apontar para o terminal regional correto. O aviso aqui é que esse nome de host pode ser inicialmente mal roteado imediatamente após a criação do bucket - e não mais tarde.
Michael - sqlbot
... então "Sempre que N.Virginia estiver inoperante, a mágica deixará de funcionar e você terá azar de acessar seus dados em qualquer região pelo método de alias de DNS" estará incorreto. Os buckets em outras regiões não foram afetados pela interrupção us-east-1, incluindo aqueles referenciados usando esse estilo de nome de host.
Michael - sqlbot
1
Não você não. Eles alteram a entrada DNS do seu bucket na s3.amazonaws.comzona alguns minutos após a criação do bucket, e essa alteração persiste independentemente de us-east-1. Crie um depósito em outra região e observe como é your-bucket-name.s3.amazonaws.comresolvido antes, durante e alguns minutos após a criação do depósito. As informações são enviadas para a s3-1.amazonaws.comzona na Rota 53 após a criação do bucket e persistem lá, sem depender mais de us-east-1.
Michael - sqlbot
10

Muitas grandes empresas seriam as culpadas por não usar esse recurso. Isso acrescenta custo adicional e, historicamente, qualquer tipo de solução de recuperação de desastre real não é testada, mesmo se implementada.

Além da questão de custo, as empresas que estão usando ativamente a replicação entre regiões podem oferecer uma preocupação válida em relação à latência necessária para a replicação de um objeto. O S3 não permite (até onde eu sei) a consistência de leitura após gravação em objetos replicados, enquanto permite um bucket em uma única região.

Essa questão SE levanta uma preocupação em que os objetos não estão sendo replicados corretamente ou demoram muito para serem replicados. Desde que a replicação entre regiões seja feita em um modo de consistência eventual, há muitas preocupações a serem abordadas.

Evgeny
fonte
8
Eu enfatizaria ainda mais o fato de que a replicação entre regiões do S3 oferece consistência eventual para algumas operações. Isso não é trivial de se considerar. Dependendo do aplicativo, pode ser totalmente inaceitável. Em qualquer caso, não é à prova de idiota (pode levar a problemas maiores se alguém assume é mágico)
Alexandre