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

Я знаю, как масштабировать свое программное обеспечение, но как предотвратить простои из-за сбоев в сети?

У нас есть довольно большие LAMP-сайты, которые хорошо масштабируются с точки зрения программного обеспечения. Мы используем избыточные балансировщики нагрузки перед кучей веб-серверов, использующих MySQL через прокси-сервер в режиме master-slave-slave-slave.

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

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

Какова стандартная процедура использования двух провайдеров (например, одного в ЕС и одного в США)? Я знаю, как делать репликацию программного обеспечения и т.д.

Мне интересно, как данные отправляются в сеть ЕС, когда сеть США не работает; DNS - единственный выбор для этого? И если да, то как это настроить? Поскольку переключение DNS, когда сервер не работает, кажется слишком медленным, за исключением случаев, когда TTL = 0, что означает, что мы будем использовать DNS в качестве системы аварийного переключения. Я понимаю (например, из Serverfault), что это не лучший метод работы.

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

Если я правильно понимаю ваш вопрос, вы хотите, чтобы ваш клиент переключился на дополнительный центр обработки данных, если основной по какой-либо причине не работает. Один продукт, который может справиться с этим, - это BIG-IP Global Traffic Manager из f5 Networks. По сути, он будет немедленно обновлять ваш DNS при обнаружении сбоя, чтобы начать перенаправлять клиентов во вторичную сеть.

Другой вариант - использовать что-то вроде Anycast транслировать маршруты в ваши дата-центры.

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

Последний вариант - не полагаться на то, что ваш центр обработки данных предоставит вам IP-соединение и пропускную способность. Вместо этого обратитесь к глобальному IP-провайдеру, например, Global Crossing или Level 3, и позвольте им управлять маршрутизацией вашего входящего трафика в любой центр обработки данных. Риск заключается в том, что вы работаете с одним поставщиком, но преимущество в том, что они могут быть гораздо более гибкими в своих вариантах маршрутизации (вы можете использовать MPLS в их сети для внутренней репликации, а также использовать одно и то же соединение для общедоступных Возможность обмена мгновенными сообщениями).

По сути, для этого доступны 2 варианта технологии (о которых я знаю):

  • Как указал OP, переключитесь на другой DC, обновив DNS, чтобы записи указывали на адреса в рабочем центре данных.
  • IP Anycast, то есть DNS публикует IP-адрес, и этот IP-адрес является произвольным и используется в обоих центрах обработки данных, что побуждает маршрутизаторы клиентов выбирать ближайший центр обработки данных. Обратите внимание, что если центр обработки данных выходит из строя, то у клиента, «ближайшего» к этому DC, все равно будет короткий сбой, пока маршруты BGP не будут повторно настроены.

Поскольку переключение DNS, когда сервер не работает, кажется слишком медленным, кроме случаев, когда TTL = 0

Вы можете установить TTL равным нулю, но не ожидайте, что все сети будут подчиняться вашим настройкам. На практике минимальное значение TTL - около 10 минут. И, конечно же, это означает, что отработка отказа на основе DNS займет от 0 до 10 минут для каждого клиента, в зависимости от вашего TTL в их кеше.

Отбрасывание 1000 запросов - это нормально, но больше - плохо и никогда не должно происходить.

Насколько мне известно, это просто выходит за рамки того, что сегодня технически возможно. Даже самые крупные сайты используют DNS или технологию на основе Anycast и изо всех сил стараются поддерживать время безотказной работы своих центров обработки данных на уровне, близком к 100%, потому что нет способа мгновенно переключиться на отказ на глобальном уровне Интернета.

Внутри локальной сети вы можете использовать что-то вроде VMWare VMotion для очень быстрого переключения, но это будет ваша собственная, непрерывно контролируемая локальная сеть.

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

  • Многие устройства балансировки нагрузки имеют географическое распределение в качестве маркера функции, но если весь контроллер домена не работает, то и ваш балансировщик нагрузки тоже? (Изменить: я просто перечитал ответ DLux, и я думаю, теперь я это понимаю ... Вы получаете два балансировщика нагрузки, вставляете по одному в каждый DC. Они создали между собой сердцебиение. Когда LB в активном контроллере домена замечает, что его коллега в мертвом контроллере домена выпадает из сети, тогда активный LB обновляет DNS, чтобы облегчить переключение.)
  • Я бы лично не стал использовать Anycast - технология существует и работает, но что, если возникнет странная, редкая проблема с маршрутизацией? Устранение неполадок в сети и так достаточно сложно, «оптимизацию» BGP следует оставить на усмотрение настоящих экспертов.
  • Итак, что осталось, это аварийное переключение на основе DNS, предпочтительно с использованием глобального реплицированного поставщика DNS, который предоставляет DNS с разделением горизонта в качестве услуги. Это будет работать, и развертывание довольно простое. Однако это не соответствует цели OP по почти мгновенному переключению при отказе.

Отказ от ответственности, я хотел бы получить ввод / исправления от настоящего эксперта, который много раз использовал глобально избыточные системы ... :-)

Вы также можете изучить сеть распространения контента (например, Akamai). Выгрузка статического контента и кеширование динамического контента в CDN может значительно снизить нагрузку на ваш кластер.

В частности, Акамай действительно дорого, но есть и другие, более дешевые альтернативы.