Глобальный вопрос настройки высокой доступности

Я являюсь владельцем и управляю visualwebsiteoptimizer.com /. Приложение предоставляет фрагмент кода, который мои клиенты вставляют на свои веб-сайты для отслеживания определенных показателей. Поскольку фрагмент кода является внешним JavaScript (в верхней части кода сайта), перед отображением веб-сайта клиента браузер посетителя связывается с нашим сервером приложений. В случае отказа нашего сервера приложений браузер будет пытаться установить соединение до истечения времени ожидания (обычно 60 секунд). Как вы можете себе представить, мы не можем позволить себе отключить наш сервер приложений ни при каких обстоятельствах, потому что это негативно скажется на опыте не только посетителей нашего сайта, но и посетителей наших клиентов!

В настоящее время мы используем механизм аварийного переключения DNS с одним сервером резервного копирования, расположенным в другом центре обработки данных (фактически на другом континенте). Таким образом, мы контролируем наш сервер приложений из 3-х разных мест и, как только он обнаруживается, что он не работает, мы меняем запись A, чтобы указать IP резервного сервера. Это прекрасно работает для большинства браузеров (так как наш TTL составляет 2 минуты), но IE кэширует DNS в течение 30 минут, что может быть убийством сделки. Смотрите этот недавний пост нашего visualwebsiteoptimizer.com/split-testing-blog/maximum-theoretical-downtime-for-a-website-30-minutes/

Итак, какую настройку мы можем использовать для обеспечения практически мгновенного переключения при сбое в случае серьезного сбоя в работе центра обработки данных? Я прочитал здесь www.tenereillo.com/GSLBPageOfShame.htm, что наличие нескольких записей A является решением, но мы не можем позволить себе синхронизацию сеансов (пока). Еще одна стратегия, которую мы исследуем, - это две записи A, одна из которых указывает на сервер приложений, а вторая - на обратный прокси-сервер (расположенный в другом центре обработки данных), который разрешает доступ к основному серверу приложений, если он включен, и к серверу резервного копирования, если он работает. Считаете ли вы эту стратегию разумной?

Просто чтобы быть уверенным в наших приоритетах, мы можем позволить себе отключить собственный веб-сайт или приложение, но мы не можем позволить замедлить работу веб-сайта клиентов из-за нашего простоя. Поэтому, если наши серверы приложений не работают, мы не собираемся отвечать ответом приложения по умолчанию. Даже пустого ответа будет достаточно, нам просто нужно, чтобы браузер завершил это соединение HTTP (и ничего больше).

Ссылка: я прочитал эту ветку, которая была полезна serverfault.com/questions/69870/multiple-data-centers-and-http-traffic-dns-round-robin-is-the-only-way-to-assure

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

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

Это единственный способ сделать настоящий отказоустойчивый. Когда маршрутизаторы замечают, что маршрут к вашим серверам больше не действителен (что вы можете сделать несколькими способами), тогда они прекращают рекламу этого маршрута, и трафик переходит на другой сайт.

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

Лучшая практика BGP Multihomed / Multi-location и Лучший способ повысить устойчивость? вопросы, которые я задавал о подобных проблемах.

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

Вам также следует обратить внимание на другие точки сбоя в вашей сети. Убедитесь, что все серверы имеют 2 сетевых адаптера (подключенных к 2 отдельным коммутаторам), 2 блока питания и что ваша служба состоит из нескольких внутренних серверов в виде избыточных пар или кластеров с балансировкой нагрузки.

По сути, «балансировка нагрузки» DNS через несколько записей A - это просто «распределение нагрузки», так как DNS-сервер не имеет понятия о том, сколько нагрузки находится на каждом сервере. Это дешево (бесплатно).

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

Сеть с маршрутизацией BGP, поддерживаемая надежной инфраструктурой, является ИМХО, единственным способом действительно гарантировать хорошее время безотказной работы. Вы могли бы сэкономить немного денег, используя серверы маршрутов вместо маршрутизаторов Cisco / Juniper / etc, но в конце концов вам действительно нужно очень осторожно управлять этими серверами. Это ни в коем случае не дешевый вариант, или что-то, что нужно предпринять легко, но это очень полезное решение, которое приводит вас в интернет как провайдер, а не просто как потребитель.

Хорошо, это было задано некоторое время назад, но я впервые вижу это сейчас.

фрагмент кода - это внешний JavaScript (в верхней части кода сайта), перед тем как показывать веб-сайт клиента, браузер посетителя связывается с нашим сервером приложений.

Вам следует:

1. Поместите файл Javascript в хорошую профессиональную сеть доставки контента, то есть приобретите высокодоступную порцию HTTP (S) Javascript у кого-то, кто уже обладает этим опытом.
2. Запрограммируйте свой Javascript так, чтобы было хорошее резервное состояние, то есть, если ваш сервер приложений не отвечает быстро, тогда конечный пользователь видит обычную неизмененную страницу.

Делать что-либо еще на самом деле безответственно. Я полагаю, у вас уже есть это на месте.

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

Ваш вопрос немного запутан. Анализ того, как создать высокодоступный сервис, начинается с данных приложения , потому что это ваше «состояние». Части без состояния легко сделать высокодоступными, а детали с полным состоянием - нет. Поэтому вместо того, чтобы сосредоточиться на своих серверах и DNS, посмотрите, где ваше приложение поддерживает состояние . Начните с оптимизации и, возможно, попросите совета по алгоритму переполнения стека. Не могли бы вы реализовать понятие транзакций и повторных попыток умного сервера в вашем файле Javascript fx?

На самом деле, то, что вы хотите, может быть улучшено, чтобы облегчить вашу работу по разделенному тестированию, если вы объедините переходы geodns и dns.

Отправка группы A на ip 1 и группы B на ip 2, даже если они находятся на одном сервере, позволит вам разделить группы тестирования. Группа A и Группа B из разных географических регионов. Чтобы быть справедливым, на следующий день / неделю / месяц вы переворачиваете группы, чтобы убедиться, что вы учитываете географические различия. Просто чтобы быть строгим в вашей методологии.

Служба geodns / failover dns на http://edgedirector.com может сделать это

раскрытие: я связан с вышеупомянутой ссылкой, наткнулся здесь, исследуя статью о применении глупых трюков днс для сплит-тестирования.