← Cloudflare Load Balancing / load-balancing / troubleshooting
Часто задаваемые вопросы
Обзор
Более подробные сведения о Load Balancing, включая практические руководства, обучающие материалы и другую справочную информацию, можно найти в документация по продукту.
Почему мой источник получает так много запросов от монитора?
Эта проблема может быть вызвана сочетанием двух причин.
Несколько регионов мониторинга состояния
Когда вы подключить монитор к пулу, можно указать Регионы монитора работоспособности который Cloudflare использует для мониторинга работоспособности ваших эндпоинтов.
Если вы выберете несколько регионов или укажете Все дата-центры (только Enterprise), вы можете значительно увеличить трафик в этот пул и связанные с ним эндпоинты. Каждый регион отправляет отдельные запросы монитора работоспособности из 3 дата-центров. Используя Все дата-центры отправляет отдельные запросы монитора работоспособности из всех существующих дата-центров Cloudflare (а их количество постоянно растёт).
Чтобы снизить объём трафика, уменьшите количество выбранных регионов или выберите вариант, отличный от Все дата-центры.
Малые интервалы для запросов монитора состояния
Если у запросов вашего монитора работоспособности небольшой интервал, это может увеличить объём трафика, отправляемого на ваши конечные точки.
Почему моя конечная точка или пул считаются неработоспособными?
Подробнее о том, как конечные точки и пулы становятся неработоспособными, см. в Работоспособность эндпоинтов и пулов.
Если вы знаете, что ваша конечная точка работоспособна, но балансировка нагрузки сообщает о ней как о нерабочей, проверьте следующие настройки на монитор:
- Выполните
curlзапрос к настроенному эндпоинту. Убедитесь, что получаемый ответ соответствует настройкам вашего монитора. - Убедитесь, что ваш брандмауэр или веб-сервер не блокирует и не ограничивает частоту запросов от наши мониторы работоспособности и принимает запросы от IP-адреса Cloudflare.
- Если вы ищете конкретное значение в Response Body, убедитесь, что это значение относительно статично и находится в первых 10 КБ HTML-страницы.
- Если ваш эндпоинт отвечает
301или302код состояния, убедитесь, что Follow Redirects выбрано. - Попробуйте увеличить Тайм-аут значение.
- Просмотрите Заголовок Host для монитора проверки работоспособности.
- Если вы используете Authenticated Origin Pulls (mTLS), Argo Smart Routing, Bring your own CA (mTLS), Dedicated CDN Egress IPs, или требовать HTTP/2 to Origin, убедитесь, что вы указали значение зоны для Simulate Zone соответствующей зоне, для которой настроены эти функции.
Почему мой балансировщик нагрузки направляет трафик во вторичный пул, хотя первичный пул все еще работоспособен?
Иногда трафик может уходить от пула, если запрос монитора не проходит из определенного дата-центра, даже когда конечная точка остается работоспособной. В этом случае данный дата-центр может направить небольшую часть запросов в другой пул, который он считает работоспособным.
Подробнее о том, как конечные точки и пулы становятся неработоспособными, см. в Работоспособность эндпоинтов и пулов.
Что происходит, когда пул или конечная точка становится неработоспособной?
Когда пул или конечная точка становится неработоспособной, трафик может перенаправляться на другие работоспособные пулы или конечные точки в зависимости от вашей конфигурации. Такое поведение возможно при использовании:
1 - Пулы с All-Datacenters мониторинга, и монитор завершается с ошибкой в конкретном дата-центре. В этом случае весь трафик будет направляться в обход затронутых конечных узлов в этом дата-центре, пока монитор снова не станет успешным. Такие случаи отражаются в аналитике запросов LB как перенаправление в обход неработоспособного конечного узла или пула.
2 - Пулы с адресами конечных точек FQDN, для которых рекурсивный DNS-запрос завершается ошибкой в конкретном дата-центре. В этом случае от затронутых конечных точек будут отведены только запросы, для которых DNS-запрос завершился ошибкой. Это может происходить время от времени, особенно если вышестоящие авторитетные DNS-серверы иногда не отвечают вовремя или дают сбой, когда истекает TTL локального кеша DNS и требуется выполнить удалённый запрос в критическом пути обработки. В аналитике запросов LB это также отображается как отвод от неработоспособной конечной точки, а IP-адрес разрешённой конечной точки будет отсутствовать в журнале запросов.
Чтобы избежать таких сценариев:
1 - Не используйте All-Datacenters мониторинга.
2 - Используйте IP-адреса для настройки конечных точек. Если это невозможно, используйте домены, для которых Cloudflare является авторитетным DNS-сервером (первичным или вторичным).
Подробнее о том, как конечные точки и пулы становятся неработоспособными, см. в Работоспособность эндпоинтов и пулов.
В чём разница между Load Balancing и Health Checks?
Cloudflare Load Balancing помогает отслеживать работоспособность конечных точек и, опираясь на эти и другие данные, соответствующим образом маршрутизировать входящие запросы. К отдельным конечным точкам подключены мониторы, которые с определённой периодичностью отправляют проверочные запросы.
Cloudflare Health Checks идентичны мониторам внутри балансировщика нагрузки, но предназначены только для проверки работоспособности сервера (а не для распределения трафика).
Почему в Load Balancing Analytics отображается разное количество запросов?
Вы можете увидеть разное количество запросов при просмотре Load Balancing Analytics, особенно по сравнению с другими дашбордами Cloudflare (Caching и другие).
Балансировка нагрузки запросы это количество некэшированных запросов, которые обрабатывает ваш балансировщик нагрузки. По умолчанию Cloudflare кэширует полученные IP-адреса в течение до пяти секунд. Именно такое встроенное кэширование часто становится причиной расхождений.
У меня появляется определённый код ошибки для балансировщика нагрузки или монитора.
Список конкретных кодов ошибок и дальнейших действий приведён в Устранение неполадок балансировки нагрузки.