Является ли межрегиональная репликация 100% надежной для перебоев в работе области S3?


19

Amazon S3 имеет опцию межрегиональной репликации, которая должна быть достаточно отказоустойчивой в отношении перерывов между регионами и зонами.

Означает ли это, что те, кто разглагольствует об отключении, не использовали этот аспект?

Или эта межрегиональная репликация не является абсолютно надежной и не помогла бы?



@ Евгений Спасибо. Я читал тот же пост, прежде чем спросить об этом :)
Dawny33

Ответы:


11

Недостаток, когда есть репликация, прибывает из примечания ниже:

Amazon S3 перенаправляет любые виртуальные запросы в стиле хостинга в регион Восток США (Северная Вирджиния) по умолчанию, если вы используете конечную точку Восток США (Северная Вирджиния) (s3.amazonaws.com) вместо конкретной конечной точки региона (для Например, s3-eu-west-1.amazonaws.com).

Когда вы используете репликацию, вы обычно позволяете AWS позаботиться о маршрутизации псевдонима в один регион, направив s3.amazonaws.comзапрос REST с серверов и разрешив перенаправление выполнить свою работу.

Всякий раз, когда N.Virginia не работает, магия перестает работать, и вам не повезло, чтобы получить доступ к вашим данным и вам придется обновить свою конфигурацию, чтобы выбрать конкретную конечную точку региона.

Проблема не в DNS (запрос к корзине будет работать), а в клиентах S3, которые подключатся к конечной точке API S3 перед доступом к корзине, в этом случае разрешение DNS выполнено, s3.amazonaws.comи это используется конечная точка восток-1.

При использовании псевдонима регионов вы теряете удобство балансировки нагрузки по регионам с включенной проверкой работоспособности из AWS.

Если вы используете DNS cname, нацеленный на регионы для быстрого переключения, вы несете ответственность за свой DNS TTL, но ничто не гарантирует, что серверы кэширования ISP клиента будут учитывать ваше значение (один из многих кэшей, с которыми может столкнуться ваш клиент).

И, наконец, если вы попытаетесь самостоятельно сбалансировать нагрузку, вы, вероятно, создадите тот же SPOF, что и у AWS, с дополнительным бременем его поддержки.

AWS работает над этим, но это все, что у меня есть на момент написания.


В соответствии с docs.aws.amazon.com/AmazonS3/latest/dev/VirtualHosting.html можно использовать «bucketname.s3-eu-west-1.amazonaws.com» (заменить ваш любимый регион) в качестве псевдонима DNS. IFF, который работает, это может быть способ быстрого переключения (так быстро, как позволяет ваш заданный TTL)
Майкл Браво,

@MichaelBravo расширил ответ для решения вашей проблемы :)
Tensibai

«Даже если теоретически вы могли бы использовать CNAME для конечных точек региона, авторитетный ответ зависит от службы в Н.Вирджинии, насколько я знаю, и я читал об этом». Вы берете цитату о маршруте в восточный регион США. по умолчанию вне контекста. До того, как example-bucketведро существует, example-bucket.s3.amazonaws.comуже указывает на восток США в DNS. В течение нескольких минут после первоначального создания сегмента это постоянно изменяется, чтобы указывать на правильную региональную конечную точку. Предупреждение здесь заключается в том, что это имя хоста может первоначально быть ненадолго ошибочно доставлено сразу после создания сегмента, а не позднее.
Майкл - sqlbot

... поэтому «Всякий раз, когда N.Virginia не работает, магия перестает работать, и вам не повезет, чтобы получить доступ к вашим данным в любом регионе методом псевдонима DNS» , поэтому неправильно. Отказы us-east-1 не повлияли на сегменты в других регионах, включая те, на которые ссылается этот стиль имени хоста.
Майкл - sqlbot

1
Нет, ты не Они изменяют запись DNS для вашего сегмента в s3.amazonaws.comзоне в течение нескольких минут после его создания, и это изменение сохраняется независимо от us-east-1. Создайте область в другом регионе и посмотрите, как она your-bucket-name.s3.amazonaws.comрешается до, во время и через несколько минут после создания области. Информация передается в s3-1.amazonaws.comзону на маршруте 53 после создания сегмента и сохраняется там, без дальнейшей зависимости от нас-восток-1.
Майкл - sqlbot

10

Многие крупные компании были бы виноваты в том, что не использовали эту функцию. Это добавляет дополнительную стоимость, и исторически сложилось так, что любое реальное решение для аварийного восстановления не тестировалось, даже если оно реализовано.

Помимо вопросов стоимости, компании, которые активно используют межрегиональную репликацию, могут предложить обоснованную озабоченность относительно задержки, необходимой для репликации объекта. S3 не позволяет (насколько мне известно) согласованность чтения после записи для реплицируемых объектов, в то время как он допускает его для сегмента в одной области.

Этот вопрос SE вызывает обеспокоенность, когда объекты не реплицируются должным образом или занимают слишком много времени для репликации. При условии, что межрегиональная репликация выполняется в режиме возможной согласованности, существует множество проблем, которые необходимо решить.


8
Я бы еще больше подчеркнул тот факт, что межрегиональная репликация S3 обеспечивает возможную согласованность для некоторых операций. Это не тривиально, чтобы принять во внимание. В зависимости от приложения это может быть совершенно неприемлемо. В любом случае, это не защищает от дурака (может привести к большим проблемам, если кто-то считает, что это волшебство)
Александр
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.