[Документация Yandex Cloud](../../index.md) > [Yandex Cloud CDN](../index.md) > [Концепции](index.md) > Настройка Cloud CDN при недоступности источника # Настройка Yandex Cloud CDN при недоступности источника Чтобы [CDN-ресурс](resource.md) продолжал отдавать контент при недоступности основного [источника](origins.md), заранее включите [кеширование](caching.md), настройте [экранирование источников](origins-shielding.md) и подключите резервный источник. Если приложение допускает использование старых версий файлов, дополнительно разрешите выдачу устаревшего контента из кеша. ## Как Cloud CDN работает при недоступности источника {#origin-unavailable} Контент пользователям отдается CDN-серверами, расположенными в разных географических [точках присутствия](points-of-presence.md). Недоступность дата-центра с источником контента сама по себе не означает остановку раздачи через CDN. Если в CDN-ресурсе настроен только один источник и он стал недоступен, результат зависит от состояния кеша: #| || **Состояние файла** | **Что произойдет** || || Файл есть в кеше обслуживающего CDN-сервера, срок кеширования не истек. | Cloud CDN продолжит отдавать файл. || || Файла нет в кеше. | Cloud CDN потребуется получить файл из источника или с экранирующего сервера, если экранирование включено. || || Срок кеширования истек. | Cloud CDN потребуется обновить файл у источника. || || Срок кеширования истек, разрешена выдача устаревшего контента. | Если выполнены условия опции `stale`, Cloud CDN сможет отдать сохраненную копию. || || Кеширование файла отключено. | Для получения файла потребуется доступный источник при каждом запросе пользователя. || |# Если файла нет в кеше, а источник недоступен, пользователь получит ошибку. При тайм-ауте это может быть ошибка `504 Gateway Timeout`, при других сбоях код может отличаться. {% note info %} Кеш каждой точки присутствия формируется отдельно. Наличие файла на одном CDN-сервере не гарантирует, что он есть на остальных. Подробнее — в разделе [Кеширование контента](caching.md). {% endnote %} Чтобы повысить отказоустойчивость ресурса: 1. [Включите кеширование на ресурсе](#enable-caching). 1. [Включите экранирование источников](#enable-shielding). 1. [Подготовьте резервный источник](#prepare-backup-origin). 1. [Добавьте второй источник в группу](#configure-origin-group). 1. [Разрешите выдачу устаревшего контента, если это допустимо](#serve-stale-content). 1. [Выполните настройку до возникновения сбоя](#configure-in-advance). 1. [Проверьте работу резервного источника](#test-backup-origin). ## Включите кеширование на ресурсе {#enable-caching} 1. В [консоли управления](https://kz.console.yandex.cloud) выберите каталог, в котором расположен ресурс, и перейдите в сервис **Cloud CDN**. 1. Нажмите на имя нужного ресурса. 1. Перейдите на вкладку **Кеширование** и нажмите **Редактировать**. 1. В блоке **CDN** включите опцию **Кеширование в CDN**. 1. Выберите тип настроек: **Как у источника** или **Свои настройки**. Задайте время жизни кеша. 1. Нажмите **Сохранить**. Подробные шаги приведены в [инструкции по настройке кеширования](../operations/resources/configure-caching.md). {% note tip %} Проверьте, что нужные файлы действительно кешируются. Для проверки используйте заголовок ответа `Cache-Status` от Cloud CDN: значение `HIT` означает, что файл был отдан из кеша. {% endnote %} На кеширование влияют настройки ресурса и заголовки ответов источника. [Кеширование в браузере](caching.md#client-side) настраивается отдельно и не заменяет кеширование на CDN-серверах. Если кеширование отключено или конкретный файл не кешируется, Cloud CDN будет обращаться к источнику при каждом запросе такого файла. Выбирайте [время жизни кеша](caching.md#server-side-cache-age) с учетом частоты обновления контента. ## Включите экранирование источников {#enable-shielding} Экранирование добавляет промежуточный уровень кеша между CDN-серверами и источниками. Если файла нет в кеше обслуживающего CDN-сервера, запрос сначала поступает на _экранирующий сервер_. Если там есть подходящая кешированная копия, обращаться к источнику не потребуется. Экранирующий сервер также объединяет повторяющиеся запросы к одному файлу. Это сокращает количество загрузок одинакового контента из источника и снижает нагрузку на него. Экранирование может существенно повысить эффективность кеширования, особенно когда одни и те же файлы запрашивают пользователи через разные точки присутствия. Результат зависит от характера запросов и настроек кеша. Подробнее — в разделе [Экранирование источников](origins-shielding.md). Чтобы включить экранирование: 1. Откройте нужный ресурс в Cloud CDN. 1. Перейдите на вкладку **Экранирование источников**. 1. Нажмите **Включить**, выберите доступную локацию и подтвердите включение. 1. Убедитесь, что статус изменился на `Active`. Применение настроек может занять до 15 минут. {% note warning %} Экранирование [оплачивается отдельно](../pricing.md): в день включения списывается плата за полный месяц. {% endnote %} Подробнее — в [инструкции по включению экранирования](../operations/resources/enable-shielding.md). Экранирование дополняет резервирование источников. Если нужной копии нет ни в кеше CDN-сервера, ни на экранирующем сервере, для получения файла все равно потребуется доступный источник. ## Подготовьте резервный источник {#prepare-backup-origin} Для получения файлов при недоступности основного источника нужен второй источник с копией контента. Для [виртуальных машин](../../compute/concepts/vm.md) можно использовать другую [зону доступности](../../overview/concepts/geo-scope.md). Если требуется защита от недоступности облачного сервиса целиком, разместите резервный источник в другом облаке или независимой инфраструктуре. {% note info %} Дублирующий [бакет](../../storage/concepts/bucket.md) в Object Storage не следует считать независимым резервом на случай отказа всего сервиса. {% endnote %} Перед подключением резервного источника проверьте, что: * Нужные файлы доступны по тем же путям, что и на основном источнике. * Копии файлов актуальны. * Источник доступен для Cloud CDN с учетом сетевых ограничений и прав доступа. Используйте [актуальный список сетей Cloud CDN](../../security/ip-list.md#cloud-cdn). Если включено экранирование, список сетей экранирующих серверов можно получить в [технической поддержке](https://kz.center.yandex.cloud/support). * Настройки [протокола](servers-to-origins.md), TLS-сертификата для HTTPS и [заголовка `Host`](servers-to-origins-host.md) подходят обоим источникам. * Резервный источник выдержит нагрузку при отказе основного. {% note tip %} Для разных бакетов особенно важно проверить заголовок `Host`: значение, подходящее одному бакету, может не подходить другому. Возможные варианты организации такой схемы описаны в разделе [Заголовок Host](servers-to-origins-host.md). {% endnote %} ## Добавьте второй источник в группу {#configure-origin-group} В [консоли управления](https://kz.console.yandex.cloud) на странице сервиса Cloud CDN на вкладке **Группы источников** [создайте группу](../operations/origin-groups/create-group.md) или [измените существующую](../operations/origin-groups/edit-group.md). Добавьте оба источника, включите их и выберите приоритеты. Доступны следующие варианты: #| || **Приоритеты** | **Работа с источниками** || || Основной и основной | Запросы к источникам распределяются по кругу (round-robin). Оба источника участвуют в обслуживании. || || Основной и резервный | Cloud CDN обращается к основному источнику. При ошибке, для которой предусмотрен повтор, запрос отправляется на резервный. || |# В режиме round-robin отдельные запросы распределяются между источниками. Один файл не загружается одновременно с двух источников. Подробнее — в разделе [Источники и их группы](origins.md#groups). {% note info %} Для описанной схемы переключение предусмотрено при ошибках соединения, тайм-аутах и ответах с HTTP-кодами `500`, `502`, `503`, `504`. Ответы `403` и `404` не являются основанием для такого переключения. Например, отсутствие файла на основном источнике не означает, что Cloud CDN автоматически попробует найти его на резервном. {% endnote %} После настройки [подключите группу к CDN-ресурсу](../operations/origin-groups/bind-group-to-resource.md). Применение настроек на CDN-серверах может занимать до 15 минут. Дождитесь их распространения и [проверьте работу резерва](#test-backup-origin). При переключении время ответа может увеличиться из-за ожидания ответа от основного источника. ## Разрешите выдачу устаревшего контента, если это допустимо {#serve-stale-content} Для некоторых типов контента старая версия файла предпочтительнее ошибки. В таком случае можно разрешить Cloud CDN отдавать сохраненную копию после истечения срока кеширования, если источник недоступен. С помощью API это настраивается в параметре CDN-ресурса `options.stale`. Пример фрагмента настроек: ```json { "options": { "stale": { "enabled": true, "value": [ "error", "timeout", "http_500", "http_502", "http_503", "http_504" ] } } } ``` Пример разрешает выдачу устаревшего контента при сетевой ошибке, тайм-ауте и перечисленных HTTP-кодах. Для нового ресурса используйте метод REST API [create](../api-ref/Resource/create.md) для [Resource](../api-ref/Resource/index.md) или вызов gRPC API [ResourceService/Create](../api-ref/grpc/Resource/create.md). Для существующего ресурса — метод REST API [update](../api-ref/Resource/update.md) для [Resource](../api-ref/Resource/index.md) или вызов gRPC API [ResourceService/Update](../api-ref/grpc/Resource/update.md). {% cut "Пример изменения CDN-ресурса с помощью curl" %} ```bash export IAM_TOKEN=$(yc iam create-token) curl \ --request PATCH \ --header "Authorization: Bearer $IAM_TOKEN" \ --header "Content-Type: application/json" \ --url 'https://cdn.api.yandexcloud.kz/cdn/v1/resources/<идентификатор_ресурса>' \ --data '{ "options": { "stale": { "enabled": true, "value": [ "error", "timeout", "http_500", "http_502", "http_503", "http_504" ] } } }' ``` Информация про IAM-токен и идентификатор CDN-ресурса приведена на следующих страницах: * [Получение информации о ресурсе](../operations/resources/get-resources-info.md) * [Аутентификация в API](../api-ref/authentication.md) {% endcut %} {% note info %} Выдача устаревшего контента возможна только при наличии сохраненной копии в кеше. Если файл не был закеширован или уже удален, потребуется доступный источник. Условия выдачи устаревшего контента и условия переключения на резервный источник настраиваются отдельно. Добавление кода ошибки в `stale` само по себе не включает переключение на резервный источник по этому коду. {% endnote %} ## Выполните настройку до возникновения сбоя {#configure-in-advance} В случаях сбоев могут быть недоступны не только источники, но и операции управления Cloud CDN: просмотр ресурсов, изменение настроек, [очистка](../operations/resources/purge-cache.md) и [предзагрузка кеша](../operations/resources/prefetch-files.md). Добавьте резервный источник заранее и дождитесь применения настроек. Тогда при сбое основного источника Cloud CDN сможет автоматически обращаться к резервному. Вам не придется менять настройки, если консоль управления или API будут недоступны. {% note warning %} Не очищайте кеш при недоступных источниках без необходимости. После очистки Cloud CDN потеряет сохраненные копии, а получить их заново может не получиться. {% endnote %} ## Проверьте работу резервного источника {#test-backup-origin} Проверку выполняйте на отдельном тестовом CDN-ресурсе. Его можно создать на основе рабочего ресурса с помощью [копирования конфигурации](../operations/resources/copy-resource.md). Копирование доступно внутри одного [каталога](../../resource-manager/concepts/resources-hierarchy.md#folder). Для нового ресурса потребуется отдельное [доменное имя](resource.md#hostnames) и соответствующая [ресурсная запись типа CNAME](../../dns/concepts/resource-record.md#cname). 1. Разместите одинаковые тестовые файлы на основном и резервном источниках. 1. В тестовом ресурсе укажите резервный источник рабочего ресурса как единственный основной источник. Используйте отдельную группу источников, чтобы не изменять группу рабочего ресурса. 1. Дождитесь применения настроек. 1. Выполните через тестовый CDN-ресурс тот же запрос, что и через рабочий: сохраните путь к файлу, [query-параметры](caching.md#cookie-and-query), HTTP-метод и необходимые заголовки. Замените только доменное имя CDN-ресурса на тестовое. Перед проверкой убедитесь, что ответ не отдается из ранее заполненного кеша тестового ресурса или экранирующего сервера. 1. Сравните HTTP-код, содержимое и значимые заголовки ответа с рабочим ресурсом. 1. По логам резервного источника подтвердите, что запрос дошел до него. Такая проверка подтверждает, что резервный источник доступен для Cloud CDN и способен отдавать нужный контент. Чтобы дополнительно проверить автоматическое переключение, создайте отдельную группу с двумя тестовыми источниками и приоритетами «Основной» и «Резервный». Подключите ее к тестовому CDN-ресурсу и дождитесь применения настроек. На тестовом основном источнике сымитируйте одну из ошибок, при которых [предусмотрено переключение](#configure-origin-group), например ответ `503`. Запросите файл, которого еще нет в кеше CDN-серверов и экранирующего сервера, и по логам тестового резервного источника подтвердите, что запрос дошел до него. После проверки восстановите работу тестового основного источника. #### Полезные ссылки {#see-also} * [Рекомендации по отказоустойчивости в Yandex Cloud](../../architecture/fault-tolerance.md) * [Обзор сервиса Yandex Cloud CDN](index.md)