Я владею и работаю 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, поддерживаемая надежной инфраструктурой, IMHO, единственный способ действительно гарантировать хорошее время безотказной работы. Вы можете сэкономить немного денег, используя серверы маршрутизации вместо маршрутизаторов Cisco / Juniper и т. Д., Но, в конце концов, вам нужно действительно очень осторожно управлять этими серверами. Это ни в коем случае не дешевый вариант или что-то, к чему следует относиться легкомысленно, но это очень выгодное решение, которое вводит вас в Интернет в качестве поставщика, а не просто потребителя.
Хорошо, это было задано некоторое время назад, но я впервые вижу это сейчас.
фрагмент кода представляет собой внешний JavaScript (вверху кода сайта), перед тем как отобразить веб-сайт клиента, браузер посетителя связывается с нашим сервером приложений.
Вам следует:
На самом деле делать что-либо еще безответственно. Я полагаю, у вас это уже есть.
Вам следует не основывайте свою службу на уловках маршрутизации BGP, если только у вас нет или нет ноу-хау для этого. Совершенно очевидно, что реализовать сложные сценарии маршрутизации BGP нетривиально; не делайте этого самостоятельно, если у вас нет знаний в конкретной предметной области.
Сам ваш вопрос немного запутан. Анализ того, как создать высокодоступный сервис, начинается с Данные приложений, потому что это ваше «состояние». Части без состояния легко сделать высокодоступными, а части с полным состоянием - нет. Поэтому вместо того, чтобы сосредоточиться на своих серверах и DNS, посмотрите на где ваше приложение поддерживает состояние. Начните с оптимизации и, возможно, попросите совета по алгоритму переполнения стека. Не могли бы вы реализовать понятие транзакций и повторных попыток умного сервера в вашем файле Javascript fx?
Фактически, то, что вы хотите, можно было бы обновить, чтобы облегчить ваши действия по сплит-тестированию, если вы объедините отказоустойчивость геоданных и DNS.
Отправка группы A на ip 1 и группы B на ip 2, даже если они находятся на одном сервере, позволит вам разделить группы тестирования. Группа A и группа B из разных географических регионов. Честно говоря, на следующий день / неделю / месяц вы меняете группы, чтобы убедиться, что вы учитываете географические различия. Просто чтобы быть строгим в своей методологии.
Служба геоданных / резервных DNS в http://edgedirector.com могу сделать это
раскрытие: я связан с приведенной выше ссылкой, наткнулся здесь, исследуя статью о применении глупых трюков DNS для сплит-тестирования.