Несколько дата-центров и Трафика HTTP: Циклический алгоритм DNS является ЕДИНСТВЕННЫМ способом гарантировать мгновенную обработку отказа?

Ваш вопрос: "Действительно ли DNS является Циклическим алгоритмом ЕДИНСТВЕННЫЙ способ гарантировать мгновенную обработку отказа?"

Ответ: "Циклический алгоритм DNS никогда не является правильным способом гарантировать мгновенную обработку отказа".

(по крайней мере, не самостоятельно)

Правильный способ достигнуть мгновенной обработки отказа состоит в том, чтобы использовать BGP4, направляющий таким образом, что оба сайта используют те же IP-адреса. Используя это базовая маршрутизация Интернета технологий используются для маршрутизации запросов к правильному дата-центру, вместо того, чтобы использовать базовое обращение Интернета к технологии.

В самой простой конфигурации это только обеспечивает обработку отказа. Это может также использоваться для обеспечения Передачи любому из узлов с протестом, что основанные на TCP протоколы перестанут работать во время переключения, если будет нестабильность в маршрутизации.

Так, действительно ли это верно, что, с несколькими дата-центрами и Трафиком HTTP, использованием DNS RR является ЕДИНСТВЕННЫМ способом гарантировать высокую доступность?

Очевидно это - ложное требование - необходимо только посмотреть на Google, Akamai, Yahoo, чтобы видеть, что они не используют циклический алгоритм [*] ответы как их единственное решение (некоторые могут использовать его частично, наряду с другими подходами.)

Существует много возможных вариантов, но это действительно зависит от того, что другие ограничения Вы имеете с Вашим сервисом/приложением, относительно которого Вы выбираете.

Возможно использовать циклические методы на простом, соразмещенном подходе сервера и не иметь для волнения об отказе сервера, если Вы также устраиваете 'обработку отказа' IP-адреса. (Но большинство выбирает методы выравнивания нагрузки, единственный IP-адрес и обработку отказа между подсистемами балансировки нагрузки.)

Возможно, Вам нужны все запросы на единственную сессию для движения в те же серверы, но Вы хотите, чтобы запросы были распространены через различные, региональные кластеры сервера? Циклический алгоритм не является соответствующим для этого: необходимо сделать что-то, что гарантирует любым клиентским доступам, которым предоставляют, тот же кластер физического сервера каждый раз (кроме тех случаев, когда 'исключения' происходят, такие как отказ сервера). Или они получают последовательный IP-адрес от запроса DNS или направляются к тому же кластеру физического сервера. Решения для этого включают различный коммерческий и некоммерческий DNS "подсистемы балансировки нагрузки", или (если Вы имеете больше контроля над своей сетью), рекламные объявления сети BGP. Вы могли просто принять меры, чтобы серверы имен Вашего собственного домена дали совершенно различные ответы (но, поскольку запросы DNS могут быть отправлены повсеместно, Вы не достигнете никакой привязки местоположения с тем подходом.)

[* я собираюсь использовать "циклический алгоритм", потому что 'RR' в терминологии DNS означает "ресурсную запись".]

2 - Можно сделать это с использованием Передачи любому из узлов Quagga

(Даже если существует некоторая информация, которая Передача любому из узлов плоха с TCP существует несколько крупных компаний с помощью него как CacheFly),

Другим очень простым выбором является использование минимум (как низко зависит Вашими потребностями), TTL в DNS A или CNAME записывает и обновляет эту запись для выбора, какой IP будет использоваться.

У нас есть 2 ISP и несколько услуг общего пользования, и мы используем успешно этот метод для высокой доступности с 3 лет.

Один гаечный ключ в работах - то, что много ISPs плохо настроили сопоставители, которые кэш записывает для интервала набора, и полностью проигнорируйте настройки TTL. Это не должно быть так и нет никакого оправдания за него, но печально на основе моего опыта с миграцией многочисленных веб-сайтов и сервисов, это действительно происходит.

Очень хорошее наблюдение vmiazzo +1 для Вас!! Я застреваю точно, где Вы.. экранированный с тем, как эти CDN делают свое волшебство.

Следующее является моим предположением о том, как CDN выполняют свою сеть:

• Используйте Передачу любому из узлов DNS (упомянутый Jesper Mortensen) для получения самого близкого дата-центра
• Они выполняют локальную сеть, которые охватывают через другой дата-центр, которые позволяют им делать что-то как CARP на их хостах через другой дата-центр

Или

• Они используют Протокол Выравнивания нагрузки Шлюза на своих маршрутизаторах или Протокол маршрутизатора горячего резервирования (HSRP). которые имеют дело с отключением электричества центра обработки данных.
• Причина они включают несколько IP, состоит в том так, чтобы клиент повторил, и к тому времени, когда клиентская повторная попытка, путь маршрутизации, возможно, изменился.

В данный момент следующее решение работает на меня: - возврат DNS несколько IP, например:

www -> CNAME www1 , www1 A -> 123.123.123.1
www -> CNAME www2 , www2 A -> 123.123.123.1 
www -> CNAME www3 , www3 A -> 123.123.123.1 
                    www3 A -> 8.4.56.7 <--- reverse proxy

• Последняя точка входа к обратному прокси в облаке амазонки, которые разумно передают доступному серверу (или обеспечивают под страницей обслуживания),

Обратный прокси все еще поражен, но бот, столь же тяжелый как основной.

Почему RFC 2782 (применяют то же как MX/приоритет для сервисов как http, IMAP...) не реализован ни в каком виде браузера? Вещи были бы легче... Существует ошибка о, открыта в течение десяти лет в Mozilla!!! потому что это будет конец индустрии коммерческой подсистемы балансировки нагрузки??? Я очень разочарован об этом.

Передача любому из узлов TCP на самом деле очень стабильна и используется, по крайней мере, CacheFly (с 2002), Prolexic и BitGravity. Хорошая презентация на Передаче любому из узлов TCP была сделана в NANOG 37: http://198.108.95.21/meetings/nanog37/presentations/matt.levine.pdf

Несколько записи являются единственным способом устранить возможную единую точку отказа. Любое другое решение вынуждает все входящие запросы пройти единое устройство где-нибудь между сервером и клиентом.

Таким образом для абсолютного дублирования, это необходимо. Именно поэтому Google делает это, или кто-либо еще, кто хочет быть уверенным в доступности непрерывной службы.

Довольно очевидно, почему дело обстоит так... несколько записи являются единственным способом переместить точку, в которой запросы направляются к клиентскому браузеру. Любой другой метод будет полагаться на единственную точку между клиентским браузером и сервером, в котором отказ может произойти, победив Ваш сервис. При помощи записи, единственная единая точка отказа от клиента к серверу становится клиентом самому.

Если у Вас нет нескольких установкой записей, Вы спрашиваете в течение времени простоя...

На этот метод, очевидно, нельзя полагаться для выравнивания нагрузки все же.

Интересно, сколько людей, ответивших на эти вопросы, на самом деле используют большую глобальную сеть серверов? Google использует круглосуточную систему, и моя компания использует ее уже много лет. Он может работать довольно хорошо, с некоторыми ограничениями. Да, он должен быть дополнен другими мерами.

Реальный ключ заключается в том, чтобы быть готовым принять икоту или две, если сервер выходит из строя. Когда я выдергиваю вилку на сервере, если браузер пытается получить доступ к этому серверу, то происходит задержка примерно на минуту, пока браузер узнает, что IP-адрес не работает. Но затем он очень быстро переходит на другой сервер.

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

Обход отказа - отстой. Лучший HA использует все ресурсы все время.

Я работаю с HA с 1986 года. Я прошел интенсивное обучение по созданию систем обхода отказов, и я вовсе не являюсь поклонником обхода отказов.

Кроме того, RR работает над распределением нагрузки, даже если она пассивная, а не активная. Логи наших серверов четко показывают соответствующий процент трафика на каждом сервере - в пределах разумного