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

Вопрос относительно стратегии безотказной работы сайта

Я работаю над веб-сайтом, где у нас должно быть много времени безотказной работы. Особенно в короткие периоды (15-дневные периоды), когда происходят события на сайте.

Страница очень проста и может быть обслужена почти полностью из кеша HTML. Хотя существует часть, основанная на php, это не критично, и в случае сбоя мы можем прожить с кешем, скажем, 20 минут, пока возможная проблема не будет решена. Более 20 минут на самом деле не сработают, поскольку на сайте, помимо прочего, есть табло с результатами.

У нас были успешные развертывания в Amazon с использованием нескольких EC2 с эластичной балансировкой нагрузки, а также с использованием облака Rackspace (облачные сайты и облачные серверы).

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

Я знаю, как заставить все работать всего за один провайдер. Чего я не понимаю, как этого добиться, так это фактического перехода от одного провайдера к другому. Например, если я CNAME myapp.com на домен в Rackspace и он не работает, когда я изменяю CNAME, чтобы указать на Amazon, многие пользователи будут кэшировать свои DNS в Rackspace, и все это будет бессмысленно. .это один из многих вопросов, которые у меня есть ...

Любая помощь приветствуется ... советы, советы, ошибки, все приветствуется ...

Я думаю, что только Amazon или Rackspace обеспечат вам необходимое время безотказной работы. Весь смысл облака в том, что у вас уже есть ситуация высокой доступности. Если ваше оборудование Amazon или Rackspace выходит из строя, ваш образ перезапускается на другом оборудовании. У вас уже была проблема безотказной работы или вы пытаетесь решить проблему, которая еще не возникла?

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

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

Если вы просто полагаетесь на записи DNS, то вы зависите от своего TTL (и всех программ, которые его правильно соблюдают). Есть отличный поток SF о попытках выжать мгновенное аварийное переключение из DNS, и в результате, если вы все сделаете правильно, скорее всего, это будет довольно быстро. Предполагая, что он достаточно хорош для вашего случая использования, вы можете получить его от большинства обычных служб DNS (dns made easy, dyn). Обычно вы рекламируете несколько A-записей, и большинство клиентов с хорошим поведением будут использовать те, которые работают. Конечно, в вашем случае вам не нужна балансировка, вам нужно «теплое» переключение при отказе, что на самом деле сложнее.

Вы можете попробовать BGP, но я не уверен, как это сработает; вы могли бы сделать это, используя Vyatta (через Quagga) или что-то еще на коробке с обеих сторон, но я никогда не видел, чтобы это работало.

Если у вас установлен низкий TTL для записей DNS, вы можете настроить их автоматический переход на новый сайт. Другой вариант - использовать CDN. Пусть сайт обслуживается из CDN, и пусть CDN общается с вашими серверами. Это распределит нагрузку на серверы, которые предназначены для такой настройки. Мы использовали http://www.edgecast.com/ в прошлом, чтобы справиться с такими нагрузками.

Это руководство может содержать то, что вам нужно: http://www.howtoforge.org/high_availability_loadbalanced_apache_cluster

Удачи!