Я владелец веб-сайта, планирующего использовать Amazon Cloudfront 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 по-прежнему будут работать, даже если ваш сайт не работает, что является хорошим вариантом для устранения серьезных сбоев. У вас есть достаточный контроль над тем, что происходит, поэтому вы можете адаптировать опыт в зависимости от ваших ресурсов и приоритетов. Варианты обычно делятся на следующие категории:
Объекты, которые были настроены для кэширования (чаще всего путем установки Cache-Control header) должны быть доступны до истечения срока их действия. Некоторые сети CDN предлагают пограничным серверам CDN возможность получать контент с других серверов CDN, что может помочь во время сбоев, а также в целом повысить производительность, когда исходные серверы имеют сравнительно высокую задержку по сравнению с серверами CDN.
Некоторые CDN предлагают возможность обслуживать контент, срок действия которого истек, когда ваш внутренний сервер недоступен (например, с помощью Fastly вы можете включить режимы благодати или святого Varnish). Очевидно, что это не поможет с контентом, который никогда не кэшировался, но во многих случаях он может, по крайней мере, сохранить вашу главную домашнюю страницу, контактную информацию и т. Д. В сети, пока вы работаете над восстановлением своих серверов в сети.
Большинство CDN предлагают возможность опробовать несколько внутренних серверов, поэтому у вас может быть отдельный сайт аварийного переключения, обеспечивающий удобство работы, которое имеет смысл для вашего сайта: переключение на другой сервер или сайт с ограниченной функциональностью, статическая HTML-страница и т. Д. Это может быть полезно для катастрофических ситуаций. сбои при хостинге, поскольку у вас есть возможность хостинга в совершенно другой компании или, в случае чего-то вроде Akamai NetStorage, напрямую у поставщика CDN, чтобы они поддерживали полный стек.
За исключением третьего варианта, у вас нет контроля над тем, что будет кэшироваться на серверах CDN, поэтому наиболее важной частью процесса является определение того, как ваш сайт может ухудшиться, если различные функции недоступны: например, если у вас есть разумный HTML-контент, даже когда JavaScript полностью не работает, в основном информационный сайт может работать с только базовым контентом страницы, даже когда более продвинутые функции незаметно дают сбой в фоновом режиме.
Большинство CDN кэшируют (динамический) контент в течение определенного периода времени (TTL) от источника, в данном случае вашего сервера. В консоли управления Amazon Cloudfront объясняется управление кешем корзины S3.
По умолчанию Amazon S3 кэширует объект в течение 24 часов.
Вы можете повлиять на поведение по умолчанию, предоставив / записав заголовок Cache-Control на исходном сервере или заголовок Expires.
Когда вы используете заголовок Cache-Control max-age, минимальное значение равно 0. В этот момент Amazon будет загружать контент на ваш исходный сервер, чтобы каждый раз проверять, изменился ли объект.
Когда вы используете заголовок Expires для объекта, Amazon не будет связываться с вашим исходным сервером до этой даты.
Надеюсь, это проясняет поведение Amazon.
Я был инженером службы поддержки в CDN более года, и я скажу, что все ответы здесь отличные, но у IMO @ Chris-Adams есть лучший ответ (если бы я мог проголосовать за него, я бы это сделал).
Наши клиенты указывают www на CDN, а 301 TLD - на www. Если срок жизни объекта истекает, то граница будет обслуживать истекший контент, если он доступен в кеше.
С учетом сказанного, если для вас важно время безотказной работы (и свежий контент), я бы подумал о переносе вашего источника (я знаю, что боль в заднице) на хост, который не испытывает частых отключений электроэнергии.