- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Как? Пожалуйста, вкратце опишите как это работало бы и чем было бы лучше классического решения на нескольких A-записях.
Если каждый из dns-серверов осуществляет мониторинг доступности серверов сайта, то он может выдавать клиентам IP сайта в зависимости от доступности сервера(-ов).
При разрешении имен, библиотеки dns, обязаны опрашивать следующий ns-сервер, если очередной не отвечает. Это поведение dns было задумано с самого начала и документировано. Именно этим оно и лучше.
То есть, предлагаете считать инженеров этих компаний некомпетентными?
Нет. Допускаю, что решение об использовании RR было принято только ради балансировки. Все остальное вы придумали.
Если каждый из dns-серверов осуществляет мониторинг доступности серверов сайта, то он может выдавать клиентам IP сайта в зависимости от доступности сервера(-ов).
При разрешении имен, библиотеки dns, обязаны опрашивать следующий ns-сервер, если очередной не отвечает. Это поведение dns было задумано с самого начала и документировано. Именно этим оно и лучше.
Мониторить доступность серверов и выдавать IP в зависимости от доступности - это уже не простое решение, которое каждый мог бы реализовать самостоятельно, и явно сложнее, чем прописать в зоне несколько IP. Хотя в арсенале средств фейловера специалистами это и применяется, но в качестве единественного и все решающего средства это не подходит. Только вместе с другими. Например, DNS-сервер мониторит веб-серверы и отдает списом все IP-адреса, исключая из него недоступные.
Полагаться только на TTL DNS - плохая идея. Ресолвер опрашивает следующий ns-сервер, если во время запроса к DNS не ответил очередной ns-сервер. Браузер в этом никак не участвует. Если браузер получил из кэша своего dns-сервера IP-адрес, который барузеру не ответил, перезапрашивать по DNS браузер не будет, не смотря на любые TTL. В стандартах этого нет, в стандартах есть multiple A-records.
Нет. Допускаю, что решение об использовании RR было принято только ради балансировки. Все остальное вы придумали.
То, что "Все остальное вы придумали" - это допущение, утверждение или вы так припоминаете? Если утверждение, то где подтверждение утверждения? Если допущение, то ладно, допускать можно все-то угодно, и что земля плоская.
. Если браузер получил из кэша своего dns-сервера IP-адрес, который барузеру не ответил, перезапрашивать по DNS браузер не будет, не смотря на любые TTL. В стандартах этого нет, в стандартах есть multiple A-records.
Да, в течении некоторого небольшого времени TTL в проекте этой схемы некоторые пользователи получали бы ошибки.
Однако, плюсы тоже есть :
- Более широкий выбор схем дублирования. можно задействовать резервные сервера, которые не работают постоянно и не обязаны быть такими же быстрыми как основные.
- К асинхронной односторонней репликации данных в другой ДЦ совсем другие требования по скорости. Она гораздо быстрее и проще, чем поддержание актуальных копий данных на каждом сервере для RR. Синхронная репликация в другой ДЦ может вообще так медленно работать, что функционирование RR-кластера будет невозможно.
- Можно в некоторой степени устроить распределение нагрузки по географическому признаку как в BGP.
- По сравнению с BGP, стоимость организации мизерная. В минимальной конфигурации нужно всего лишь два VPS в разных ДЦ.
Все это было бы, если бы не поведение IE.
Для RR получаем, что некоторые пользователи, браузеры которых не поддерживают RR особым образом при наступлении сбоя в 50% случаев не смогут открыть сайт до устранения сбоя. Как много таких браузеров еще нужно выяснить.
В браузере могли реализовать работу с RR, но для работы с DNS-файловером точно не нужно никакого особенного кода в программе. Этим она и лучше.
То, что "Все остальное вы придумали" - это допущение, утверждение или вы так припоминаете? Если утверждение, то где подтверждение утверждения?
По-моему, все прекрасно понятно. Перечитывайте.
У небольшого времени TTL есть проблема - если TTL будет 1 минута, то у посететеля сайта после каждой минуты будут возникать дополнительные задержки на повторный ресолвинг. Получается, что для того, чтобы повысить отказоустойчивость для редких, в общем-то, простоев, нужно будет в той или иной степени ухудшить скорость отдачи страниц. Если TTL увеличивать, то увеличивается процент посетителей, попавших на умерший сервер.
Из плюсов по сравнению с multiple IP, согласен только с одним:
- Более широкий выбор схем дублирования. можно задействовать резервные сервера, которые не работают постоянно и не обязаны быть такими же быстрыми как основные.
Удешевление репликации - это его следствие.
Геобалансинг от низкого TTL никак не зависит, к плюсам относить бессмысленно.
У multi IP по сравнению с BGP тоже стоимость мизерная, поэтому к плюсом низкого TTL относить не надо.
Все это было бы, если бы не поведение IE.
Не только IE, не забывайте игнорирующих TTL провайдеров и поисковики. Это может быть неприятно припоминать, но это реальность.
Для RR получаем, что некоторые пользователи, браузеры которых не поддерживают RR особым образом при наступлении сбоя в 50% случаев не смогут открыть сайт до устранения сбоя. Как много таких браузеров еще нужно выяснить.
Я не встречал таких браузеров, но допускаю, что какие-то редкие экзотические есть. Скорее всего доля таких в общем числе чуть отличается от нуля. Для них, да 50% - это если в сети два хоста и вышел из строя один. Если их больше, то вероятность того, что он окажется в списке первым, уменьшается. На практике сочетают обе схемы - multi IP и небольшой TTL (10 - 60 минут), и исключение недоступного хоста из списка, что позволяет получить практически достижимый максимум. Правда, исключение делается в первую очередь не для предполагаемых проблемных браузеров, а для минимизации задержек на подключение к неотвечающим хостам.
По-моему, все прекрасно понятно. Перечитывайте.
Прямой ответ вы дать не можете. Это можно понять.