Himiko

Himiko
Рейтинг
560
Регистрация
28.08.2008
Должность
ООО "Системные интеграции", Генеральный директор. ООО "Медиа-группа "Автор", Исполнительный директор
15.04.1985
Это бред.

"Плюют" на TTL не провайдеры, а браузеры, которые просто его не получают в gethostbyname() и используют статическое время кеширования DNS (обычно 30 минут).

nslookup тоже информацию берёт из браузера? Всякое бывает и не нужно это отрицать.

Это не тот лог, нет в нём ошибок этого сайта. Это лог глобальный

Наверное, стоит посмотреть тут http://www.modsecurity.org/documentation/modsecurity-apache/1.9.3/html-multipage/06-special_features.html ?

Раздел "Integration with ClamAV"

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

1) Это время на то, чтобы ваша система определила, что сервер вышел из строя

2) 3 минуты по вашему TTL

3) Провайдеры часто просто плюют на TTL для экономии трафика.

Может достаточно много времени пройти для полного переключения.

По схеме понятно, многим может и подойти. Но будет не приятно, если клиент увидит свой сайт неработающим из-за того, что выпал один из серверов, а переключение у него произойдёт через 20-30 минут (разные причины могут быть)

Для определения с какого сервера раздавать контент используется механизм geoip(http://www.maxmind.com/app/country). Раскрыть вам все тонкости и детали организации мы не можем.
Спасибо.

Я это представляю.

Но если через DNS, то после первого же запроса у провайдера клиента ip попадёт в кэш и даже при падении этого сервера все запросы от этого провайдера пойдут на него. А при достаточном количестве запросов можно весь регион (запросы с которого идут на неработающий позже сервер) оставить без сайта.

dim_s:
Сорри, не совсем понял ваш вопрос.
Падает кеш-сервер, или падает основной сервер где лежит ваш сайт и контент?

Не понятно в вашей схеме:

Запрос от клиента -> определение ДНС для сайта -> отдача динамически сгенерированного контента -> отправление запроса кеш-серверу на получение статики -> определение наименьшего пути к клиенту -> отдача контента

последнее "определение наименьшего пути к клиенту -> отдача контента" как вы можете вообще контролировать? Какая разница, какой наименьший путь к клиенту, если вы отдаёте всё через сервер, который попадает на стадии "определение ДНС для сайта".

Или что-то вы указали не так.

Каким образом клиент получает статику?

dim_s:
Тут вы слегка не верно понимаете, балансировки нагрузки здесь нету. Трафик отдаётся клиенту по средствам ДНС настроек, кеш-сервера и определяют откуда пришёл запрос на контент, и подставляют географически близкий сервер для посетителя сайта.
Фактически схему можно понять так:

Запрос от клиента -> определение ДНС для сайта -> отдача динамически сгенерированного контента -> отправление запроса кеш-серверу на получение статики -> определение наименьшего пути к клиенту -> отдача контента

А если сервер, которого ip получен не доступен?

Он попадает в кэш и какое-то время запросы все будут идти на него.

Да угомонитесь уже:) И сказать вроде нечего, но поток пустой информации так и прёт из вас.

А можно увидеть вопросы, адресованные ТС вам?

Пожалуйста:

Найдутся люди ,способные помочь мне за умеренную плату?

Я ответил, что мы можем помочь.

А вот кому писали вы и зачем - непонятно. Общайтесь дальше "тихо сам с собою...", удаляюсь из бесполезной переписки.

zexis:
Балансировку также с помощью ДНС можно организовать.
С помощью ДНС реализовать проще.
Хочется узнать, как реализована балансировка у ТС.

Балансировку можно, а вот быстрое переключение - нельзя.

Плохо будет, даже если у части посетителей сайт не откроется.

Всего: 9394