CDN все еще работает, даже когда мой сервер не работает?

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

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

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

Примечание: CDN не предназначены для размещения всего вашего сайта. Так что, если вы думаете, что можете использовать его для замены своего веб-хостинга или использовать его в качестве какого-либо плана восстановления после сбоя, вы ошибаетесь в дереве.

TL; DR - Вам нужно будет спросить своего провайдера CDN.

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

Большинство людей используют их для хранения статических файлов, таких как изображения, файлы CSS и JavaScript. Некоторые могут быть настроены для кэширования HTML, но это только если у вас полностью статичный веб-сайт. Если бы это было так, вы могли бы разместить все это на S3 и вообще не нуждаться в сервере.

В общем, да, до TTL.

При использовании CDN вы обычно настраиваете TTL (время жизни) для вашего контента. Это максимум того, сколько лет может получить кеш, прежде чем он решит, что ему абсолютно необходимо обновить кеш самым новым контентом. Например, предположим, что для всех URL-адресов * .jpg настроено 5-минутное TTL.

Затем, если ваш сервер выходит из строя, у вас есть дополнительные 5 минут, чтобы восстановить его, прежде чем пользователи заметят. Ну, по крайней мере, для .jpgs. Ну, по крайней мере, для .jpgs, которые были заранее кэшированы.

Кроме того, некоторые CDN используют такие функции, как Akamai NetStorage, где вы можете загружать контент напрямую в CDN - CDN предоставляется некоторый контент и приказывается обслуживать его напрямую априори. Поскольку с самого начала здесь никогда не происходит кэширование в стиле «по требованию», это, конечно, должно работать, когда ваш сервер не работает.

Однако, как отмечали другие авторы, CDN не предназначены для этого и не дают НИКАКИХ гарантий того, что такое поведение будет работать. Просто так бывает, что обычно работает (и это здорово, когда ты смотришь, как это происходит!). И, конечно же, по конкретным техническим деталям вам необходимо связаться с вашим провайдером.

Да, серверы CDN по-прежнему будут работать, даже если ваш сайт не работает, что является хорошим вариантом для устранения серьезных сбоев. У вас есть достаточный контроль над тем, что происходит, поэтому вы можете адаптировать опыт на основе ваших ресурсов и приоритетов. Варианты, как правило, делятся на следующие категории:

1. Объекты, которые были настроены для кэширования (чаще всего путем установки Cache-Controlзаголовка), должны быть доступны до истечения срока их действия. Некоторые CDN предоставляют краевым серверам CDN возможность извлекать контент с других серверов CDN, что может помочь при сбоях, а также в целом повысить производительность, когда ваши исходные серверы имеют сравнительно высокую задержку по сравнению с серверами CDN.

2. Некоторые CDN предоставляют возможность обслуживать контент, срок действия которого истек, когда ваш бэкэнд-сервер недоступен (например, с помощью Fastly вы можете включить режимы grace или saint Varnish). Очевидно, что это не поможет с контентом, который никогда не кэшировался, но во многих случаях он может по крайней мере сохранить вашу главную домашнюю страницу, контактную информацию и т. Д. В сети, пока вы работаете, чтобы вернуть свои серверы в оперативный режим.

3. Большинство CDN предоставляют возможность попробовать несколько внутренних серверов, чтобы у вас был отдельный отказоустойчивый сайт, который имеет смысл для вашего сайта: переход на другой сервер или сайт с ограниченной функциональностью, статическая HTML-страница и т. Д. Это может быть полезно для катастрофических ситуаций. сбои хостинга, так как у вас есть возможность хостинга у совершенно другой компании или, в случае чего-то вроде Akamai NetStorage, напрямую у провайдера CDN, чтобы они поддерживали полный стек.

За исключением третьего варианта, вы не можете контролировать, что будет кэшироваться на серверах CDN, поэтому наиболее важной частью процесса является определение того, как ваш сайт может ухудшиться, если различные функции недоступны: например, если у вас есть Приемлемое содержание HTML, даже если JavaScript не работает полностью, сайт, основанный на информации, может работать только с базовым содержимым страницы, даже если в фоновом режиме происходит сбой более сложных функций.

Большинство CDN являются кэширующим (динамическим) контентом в течение периода времени (TTL) от источника, в данном случае вашего сервера. В Amazon Cloudfront Management Console объяснено управление кешем корзины S3.

1. Поведение Amazon S3 по умолчанию заключается в кэшировании объекта в течение 24 часов.

2. Вы можете повлиять на поведение по умолчанию, предоставив / записав заголовок Cache-Control на исходном сервере или заголовок Expires.

   • Когда вы используете заголовок максимального возраста Cache-Control, минимальное значение равно 0. В этот момент Amazon будет заполнять ваш исходный сервер, чтобы каждый раз проверять, изменился ли объект.

   • Когда вы используете заголовок Expires для объекта, Amazon не будет связываться с вашим исходным сервером до этой даты.

Я надеюсь, что это проясняет поведение Amazon.

Я работал инженером службы поддержки в CDN более года, и я скажу, что все ответы здесь великолепны, но IMO @ Chris-Adams имеет лучший ответ (если бы я мог проголосовать, я бы это сделал).

Одна вещь, которую делают наши клиенты, указывает www на CDN и 301 TLD на www. Если TTL объекта истекает, то край будет обслуживать просроченный контент, если он доступен в кеше.

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