Amazon S3 a une option de réplication entre régions qui devrait être assez tolérante aux pannes contre les pannes de région / zone.
Est-ce à dire que ceux qui se déchaînent sur la panne n'ont pas utilisé cet aspect?
Ou est-ce que la réplication entre régions n'est pas complètement infaillible et n'aurait pas aidé?
Réponses:
L'inconvénient lorsqu'il y a réplication vient de la note ci-dessous:
Lorsque vous utilisez la réplication, vous laissez généralement AWS s'occuper du routage de l'alias vers une région en ciblant
s3.amazonaws.comvotre demande REST à partir de vos serveurs et laissez la redirection faire son travail.Chaque fois que N.Virginia est en panne, la magie cesse de fonctionner et vous n'avez pas de chance d'accéder à vos données et devez mettre à jour votre configuration pour choisir un point de terminaison de région spécifique.
Le problème ne vient pas du DNS (une demande au compartiment lui-même fonctionnera) mais des clients S3, qui se connecteront au point de terminaison de l'API S3 avant d'accéder au compartiment, dans ce cas, la résolution DNS est effectuée
s3.amazonaws.comet c'est nous- point final est-1.Lorsque vous utilisez l'alias de régions, vous perdez la facilité d'équilibrage de charge sur les régions avec le contrôle d'intégrité d'AWS inclus.
Si vous utilisez DNS cname ciblant les régions pour basculer rapidement, vous êtes responsable de votre DNS TTL mais rien ne garantit que les serveurs de cache du FAI client honoreront votre valeur (l'un des nombreux cache que votre client peut rencontrer).
Et enfin, si vous essayez d'équilibrer la charge vous-même, vous créerez probablement le même SPOF qu'AWS a déjà avec la charge supplémentaire de le maintenir.
AWS y travaille mais ce sont toutes les informations que j'ai au moment de la rédaction.
la source
example-bucketbucket n'existe,example-bucket.s3.amazonaws.compointe déjà vers US East dans DNS. Quelques minutes après la création initiale du compartiment, cela change de façon permanente pour pointer vers le point de terminaison régional correct. L'avertissement ici est que ce nom d'hôte peut initialement être brièvement mal acheminé immédiatement après la création du compartiment - pas plus tard.s3.amazonaws.comzone quelques minutes après la création du compartiment, et ce changement persiste indépendamment de us-east-1. Créez un compartiment dans une autre région et observez layour-bucket-name.s3.amazonaws.comrésolution avant, pendant et quelques minutes après la création du compartiment. Les informations sont poussées vers las3-1.amazonaws.comzone de la Route 53 après la création du bucket et y persistent, sans plus dépendre de us-east-1.De nombreuses grandes entreprises seraient responsables de ne pas utiliser cette fonctionnalité. Cela ajoute un coût supplémentaire, et historiquement tout type de véritable solution de récupération après sinistre n'est pas testé, même s'il est mis en œuvre.
Outre le problème des coûts, les entreprises qui utilisent activement la réplication entre régions peuvent offrir une préoccupation valable concernant la latence nécessaire à la réplication d'un objet. S3 n'autorise pas (pour autant que je sache) la cohérence de lecture après écriture sur les objets répliqués, alors qu'il le permet pour un compartiment dans une seule région.
Cette question SE soulève une préoccupation lorsque les objets ne sont pas correctement répliqués ou prennent trop de temps pour se répliquer. À condition que la réplication entre régions se fasse dans un mode de cohérence éventuelle, il y a beaucoup de problèmes à résoudre.
la source