Назад | Перейти на главную страницу

AWS ELB Страница «извините, сайт не работает»

У меня базовый сайт ELB v2. Никакой кластеризации или чего-то еще. У меня нет опыта работы с AWS.

Мой стек - nginx / uwsgi / django + еще несколько сервисов.

Мне было интересно, есть ли у кого-нибудь мысли о создании страницы в стиле «извините, веб-сайт в настоящее время не работает ...» (настраиваемый текст, который я могу обновить, запланированное время простоя, является бонусом!) Всякий раз, когда есть простой по какой-либо причине, и работоспособность экземпляр красный. Не похоже, что Amazon предлагает такую ​​возможность - я что-то упускаю? Есть ли способ создать отдельный суперкрошечный экземпляр, который обслуживается ТОЛЬКО, если основной красный или что-то в этом роде?

Спасибо!

Простое и крутое решение - поставить ELB за CloudFront.

Если исходный сервер (в данном случае ELB) выдает ошибку 5XX (или 4XX, если хотите), CloudFront может вернуть настраиваемая страница ошибки, который вы можете настроить CloudFront для выборки из корзины S3, создав второй источник, указывающий на корзину, и создав маршрутизацию поведения кеша (например,) /errors/static/* в ведро.

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

По сути, как только у браузера есть DNS-запись, он просто пытается ее использовать ... как правило, до тех пор, пока все окна браузера не будут закрыты.

Поэтому, если ваш сайт не работает из-за посетителя, который уже был на нем, он вряд ли увидит альтернативный сайт.

Хуже того, если посетитель впервые попадает на ваш сайт, пока он не работает, он «застревает» на странице обслуживания, пока не закроет все окна браузера.

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

Вы можете отключить кеширование CloudFront, если оно вам не нужно.

Вы также можете настроить для параметра TTL кэширования ошибок CloudFront ненулевое значение, если хотите, чтобы он перестал работать с вашим сайтом, пока он не работает, и пытается восстановить его. Для данной страницы, которая выдает ошибку, она будет продолжать показывать страницу с ошибкой и не беспокоить ваш сервер дополнительными запросами для этой страницы, пока не истечет срок действия Error CachingTTL.

Используйте Route53 DNS и аварийная маршрутизация. У вас должна получиться корзина S3, в которой размещается одностраничный статический веб-сайт. Я не думаю, что вы можете сделать это только с помощью ELB.

У Amazon есть сообщение в блоге, в котором рассказывается, как это сделать Вот.

Обновление: как говорит Майкл, в кешировании DNS в браузере есть недостаток, см. Его ответ для получения дополнительной информации. Route 53, вероятно, более простой вариант, чем CloudFront, но CF имеет другие преимущества, производительность и в некоторых случаях использования может снизить затраты.

Уже упоминалось несколько решений, в том числе CloudFront и Route53. CloudFront - отличное решение, которое, по моему опыту, нисколько не замедлило работу, но приносит дополнительные затраты. А в Route53 уже упоминались проблемы с кешированием DNS.

Пока ALB не поддерживает настраиваемые страницы ошибок из коробки (что может произойти, а может и не произойти), потенциально существует новое решение после недавнее объявление о фиксированных ответах ALB, но это не наведи и щелкни: вы можете настроить лямбда-функцию, которая временно добавляет правило в ваш балансировщик нагрузки, обеспечивая фиксированный ответ с содержимым вашей «страницы ошибки».

Помимо написания лямбда-выражения, вам нужно будет найти способ активировать его `` включено '' и `` выключено '', что может быть через проверку работоспособности Route53 или проверку работоспособности целевой группы балансировщика нагрузки (возможно, через CloudWatch alarm -> SNS - > Лямбда).

Это не совсем просто, но, вероятно, после настройки будет хорошо работать!

Как написано @Tim и @Micheal, у вас есть выбор использовать Route53 DNS и аварийная маршрутизацияили CloudFront с настраиваемые страницы ошибок. У обоих методов есть свои плюсы и минусы.

Если вы еще не используете Cloudfront, я думаю, что Route53 - более простое решение. Смотрите обновленный Сообщение блога из AWS (который теперь включает более простой метод интеграции ELB).

CloudFront гораздо сложнее настроить, и каждое обновление занимает около 15 минут. Cloudfront также кэширует (как и следовало ожидать), поэтому неясно, будет ли ответ медленнее, чем проблемы с кешем DNS с Route 53.

Обратите внимание: если ваш веб-сайт ELB отвечает только на SSL, вы не можете использовать простое решение S3, как описано в блоге AWS.3. В этом случае вам придется добавить Cloudfront перед корзиной S3, чтобы добавить SSL, что усложнит решение маршрутизации сбоя DNS.