Назад | Перейти на главную страницу

размещенная служба аварийного переключения (прокси?) - существует ли она?

Мы находимся на стадии планирования, чтобы сделать наши сервисы веб-приложений избыточными. Прямо сейчас у нас есть собственные физические серверы в коло, на которых работает кластер VMWare, подключенный к EqualLogic SAN. Это установка ЛАМПЫ. Мы хотим создать второй сайт либо для балансировки нагрузки, либо для активного / пассивного аварийного переключения (я думаю, мы склонялись к последнему, но никаких решений не было принято).

На чертежной доске мы пришли к тому, что, как нам казалось, было простым решением. ourdomain.com преобразуется в 1.2.3.4, который является IP-адресом балансировщика нагрузки, или отказоустойчивой службы, или чего-то вроде обратного прокси-сервера apache ... где запросы поступают к нему, и он пересылает запросы в соответствующий центр обработки данных. Таким образом, если центр обработки данных A выходит из строя, мы просто меняем балансировщик нагрузки, чтобы отправлять все запросы в центр обработки данных B.

Нам не удалось найти ЛЮБОГО, кто предлагает этот тип услуг. Все, кого мы спрашиваем об этом (например, X0 и L3), говорят, что они действительно не знают, найдем ли мы что-то подобное. Наша конечная цель - обеспечить резервирование между двумя площадками, чтобы минимизировать время простоя, будь то сбой оборудования или весь центр обработки данных отключен из-за стихийного бедствия. Мы описываем эту настройку всем поставщикам, и никто не знаком с подобными услугами.

Лучшая идея, с которой мы столкнулись, - использование отказоустойчивого DNS. В настоящее время мы используем dnsmadeeasy.com, и если их мониторы обнаружат, что сайт A отключился, они изменят DNS, чтобы разрешить IP-адрес сайта B. Мы провели несколько тестов, и даже с нашим TTL в 1 минуту, это заняло в среднем около 15 минут для DNS-серверов, чтобы получить изменение, в то время как некоторым поставщикам DNS, которых мы опрашивали за рубежом (например, в Австралии, что для нас важно), потребовался почти час, чтобы внести это изменение. Этого недостаточно.

Так что мне не хватает?

Чтобы ответить на ваши вопросы:

  • Да, существует размещенное решение для аварийного переключения. Он обычно не предоставляется или не рекламируется, потому что это не обычное требование. Стоимость резервного сайта плюс стоимость выполнения любого вида GLB должным образом является действительно дорого. Обычно, когда мы сообщаем клиенту, сколько это будет стоить, он слегка бледнеет и внезапно может жить с немного большим временем простоя, чем они ожидали ранее.
  • Я бы не стал использовать Apache, но вы жестяная банка сделайте это с помощью какого-нибудь балансировщика прокси. Проблема в том, что нужно сделать который географически распределены тоже - и поскольку ваш прокси воля Чтобы увеличить задержку, вам нужно убедиться, что они доступны достаточно близко к вашим клиентам, чтобы минимизировать штраф за задержку. Есть причина, по которой Google и Akamai стараются убедиться, что у них есть несколько стоек с оборудованием, очень близко к крупным интернет-провайдерам (желательно размещенным внутри).
  • Вместо прокси я бы просто использовал аварийное переключение BGP для обеспечения активно-пассивного режима с GLB-DNS для обеспечения мультиактивности для оптимальной производительности (нет смысла иметь второе устройство, бездействующее в течение 1576785 минут из каждых 1576800 - вы может также получить от этого некоторую постоянную выгоду).

Лично я бы порекомендовал вам сделать глубокий вдох и действительно подумать о том, действительно ли необходима гео-избыточность с почти нулевым временем простоя. Действительно, что вы здесь делаете, что обойдется вам в 2 миллиона долларов + за 15-минутный перерыв? Потому что это тот тип события с ценой за отключение, на который вы рассчитываете основной форма такого рода инфраструктуры (при условии, что вы используете хорошие объекты, которые не выходят из строя регулярно). Между инженерными усилиями, необходимыми для создания чего-то подобного и поддержания его работоспособности, и затратами, связанными с реинжинирингом вашего приложения для работы должным образом в такой распределенной среде вы будете терять много денег на это, и поддержание этого будет постоянной, постоянной стоимостью (подумайте обо всех функциях, которые вы не сможете реализовать, потому что он не будет работать на нескольких сайтах, не говоря уже о ежемесячных расходах на работу всей дополнительной инфраструктуры).