100% времени безотказной работы веб-приложения

Сегодня мы получили интересное «требование» от клиента.

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

Однако из сетевой проблемы я просто не могу понять, как заставить это работать.

Короче говоря, приложение будет жить на серверах в сети клиента. Доступ к нему имеют как внутренние, так и внешние люди. Они хотят, чтобы мы поддерживали стороннюю копию системы, которую в случае серьезного сбоя на их объектах немедленно взяли бы и взяли на себя.

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

Откровенно говоря, я не имею ни малейшего представления о том, как это возможно. Кажется, что если они потеряют подключение к Интернету, то нам придется внести изменения в DNS, чтобы перенаправить трафик на внешние машины ... Что, конечно, требует времени.

Идеи?

ОБНОВИТЬ

У меня была беседа с клиентом сегодня, и они прояснили вопрос.

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

Вот удобная диаграмма Википедии о погоне за девятками:

Интересно, что только 3 из 20 ведущих веб-сайтов смогли достичь мифических 5 девяток или 99,999% времени безотказной работы в 2007 году. Это были Yahoo, AOL и Comcast. За первые 4 месяца 2008 года некоторые из самых популярных социальных сетей даже не приблизились к этому.

Из графика должно быть видно, как нелепо стремление к 100% безотказной работе ...

Попросите их определить 100% и как это будет измеряться в течение какого периода времени. Они, вероятно, означают настолько близкие к 100%, насколько они могут себе позволить. Дайте им оценки.

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

Довольно часто они формируют вещи таким образом, что они кажутся абсолютными - например, 100%, но на самом деле при более глубоком расследовании они достаточно разумны для проведения анализа затрат / выгод, который требуется, когда они представляются с затратами для данных по снижению риска. Спрашивать их, как они будут измерять доступность, является ключевым вопросом. Если они этого не знают, то вы в состоянии предложить им, что это необходимо определить в первую очередь.

Я бы попросил клиента определить, что произойдет с точки зрения влияния / затрат на бизнес, если сайт будет закрыт при следующих обстоятельствах:

• В самые загруженные часы по x часов
• В их наименее загруженные часы в течение x часов

А также как они будут это измерять.

Таким образом, вы можете работать с ними, чтобы определить правильный уровень «100%». Я подозреваю, что, задавая такие вопросы, они смогут лучше определить приоритеты своих требований. Например, они могут хотеть платить определенные уровни SLA и ставить под угрозу другие функциональные возможности для достижения этого.

Ваши клиенты сумасшедшие. 100% безотказная работа невозможна независимо от того, сколько денег вы на это потратите. Просто и ясно - невозможно. Посмотрите на Google, Amazon и т. Д. У них есть почти бесконечные суммы денег, которые они могут потратить на свою инфраструктуру, и все же им все же удается иметь время простоя. Вам нужно передать это сообщение им, и если они продолжают настаивать на том, что они предлагают разумные требования. Если они не признают, что какое-то время простоя неизбежно, тогда угробите их.

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

Это, очевидно, очень краткий ответ. У вас не было опыта работы с приложениями, требующими такой степени бесперебойной работы, поэтому вам действительно нужно привлечь профессионала, если вы хотите приблизиться к мифическому 100% времени безотказной работы.

Ну, это определенно интересный. Я не уверен, что хотел бы взять на себя обязательство по контракту на 100% безотказной работы, но если бы мне пришлось, я думаю, это выглядело бы примерно так:

Начните с того, что общедоступный IP-адрес на балансировщике нагрузки полностью находится вне сети, и постройте как минимум два из них, чтобы один мог перейти на другой. Такая программа, как Heatbeart, может помочь с автоматическим переключением.

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

В эти дни я как бы влюблен в Elastic IPs в Amazon EC2, поэтому, вероятно, я бы построил свои балансировщики нагрузки в EC2 в разных регионах или, по крайней мере, в разных зонах доступности в одном регионе. Это даст вам возможность вручную (не дай бог) раскрутить новый балансировщик нагрузки, если потребуется, и переместить существующий IP-адрес записи в новое поле.

Тем не менее, Varnish не может завершить SSL, поэтому, если вас это беспокоит, вы можете вместо этого взглянуть на что-то вроде Nginx.

У вас может быть большинство ваших бэкэндов в сети ваших клиентов и один или несколько вне их сети. Я верю, но не уверен на 100%, что вы можете расставить приоритеты бэкэндов так, чтобы ваши клиентские машины получали приоритет до тех пор, пока все они не стали нездоровыми.

Вот с чего бы я начал, если бы выполнил эту задачу и, несомненно, уточнил ее по мере выполнения.

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

Нет проблем - слегка пересмотренная формулировка контракта:

... гарантировать время безотказной работы 100% (с округлением до нуля десятичных знаков).

Если Facebook и Amazon не могут это сделать, то вы не можете. Это так просто.

Чтобы добавить ответ oconnore от Hacker News

Я не понимаю, в чем проблема. Клиент хочет, чтобы вы спланировали бедствие, и они не ориентированы на математику, поэтому запрос 100% вероятности звучит разумно. Инженер, как это делают инженеры, вспомнил свой первый день исследования 101, не считая, что клиент может этого не делать. Когда они говорят это, они не думают о ядерной зиме, они думают о Фреде, который выливает свой кофе на офисный сервер, сбивает диск или проваливает провайдера. Кроме того, вы можете сделать это. Благодаря географически отличным, независимым серверам самоконтроля у вас практически не будет простоев. С 3 серверами, работающими с независимой (1) три 9 надежностью, с хорошими режимами отработки отказа, ожидаемое время простоя составляет менее секунды в год (2). Даже если это произойдет сразу, вы все еще находитесь в пределах разумного SLA для веб-соединений, и поэтому простоев практически не существует. Клиент все еще должен иметь дело со сценариями конца света, но Годзилла исключает, у него будет услуга, которая "всегда" работает.

(1) Сервер в Лос-Анджелесе достаточно независим от сервера в Бостоне, но да, я понимаю, что есть какое-то пересечение, связанное с ядерной войной, китайскими хакерами, разрушающими электросеть и т. Д. Я не думаю, что ваш клиент будет расстроен это.

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

Вас просят о чем-то невозможном.

Просмотрите другие ответы здесь, сядьте со своим клиентом и объясните, ПОЧЕМУ это невозможно, и оцените их ответ.

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

Цена соответственно, а затем предусмотреть в договоре, что любое время простоя после SLA будет возмещено по ставке, которую они платят.

Интернет-провайдер на моей последней работе сделал это. У нас был выбор «обычной» линии DSL с продолжительностью безотказной работы 99,9% за 40 долл. / Мес. Или трио T1 с привязкой при 99,99% безотказной работы за 1100 долл. / Мес. Были частые сбои по 10+ часов в месяц, что приводило к тому, что время их работы значительно ниже DSL за 40 долларов в месяц, но нам возместили всего около 15 долларов или около того, потому что на этом и заканчивалась ставка в час * часов. Они оформлены как бандиты из сделки.

Если вы выставляете счет в размере 450 000 долларов в месяц за 100% безотказной работы, а ваш доход составляет всего 99,999%, вам нужно будет вернуть им 324 доллара. Я готов поспорить, что затраты на инфраструктуру, составляющие 99,999%, составят около 45 000 долларов в месяц, при условии, что полностью распределенные подписки, несколько каналов связи первого уровня, модные штаны и т. Д.

Если профессионалы задаются вопросом, является ли доступность на 99,999% практической или финансово жизнеспособной возможностью , то доступность на 99,9999% еще менее возможна или практична. Не говоря уже о 100%.

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

Есть два типа людей, которые просят 100% безотказной работы:

1. Люди, абсолютно не разбирающиеся в компьютерах, компьютерных системах или Интернете. *
2. Те, кто намеренно делает себе задницу, чтобы проверить свою способность сказать «Нет» (Google «Тест апельсинового сока») или попытаться получить какое-то контрактное кредитное плечо SLA, чтобы потом заплатить вам.

Мой совет, пострадавший от обоих этих типов клиентов, - не брать этого клиента. Пусть они сводят кого-то с ума.

* Этот же человек может не смущаться, спрашивая о путешествии быстрее света, вечном движении, холодном синтезе и т. Д.

Я бы пообщался с клиентом, чтобы выяснить, что именно означает 100% безотказной работы. Возможно, они действительно не видят разницы между временем работоспособности 99% и временем работоспособности 100%. Для большинства людей (т.е. не администраторов сервера) эти два числа одинаковы.

100% безотказной работы?

Вот что вам нужно:

Несколько (и избыточных) DNS-серверов, указывающих на несколько сайтов по всему миру, с соответствующими SLA с каждым провайдером.

Убедитесь, что DNS-серверы настроены правильно, и TTL распознается эффективно.

Это просто. Amazon EC2 SLA четко заявляет:

«Годовой процент времени безотказной работы» рассчитывается путем вычитания из 100% процента 5-минутных периодов в течение Сервисного года, в котором Amazon EC2 находился в состоянии «Регион недоступен».

http://aws.amazon.com/ec2-sla/

Просто определите «время безотказной работы» по отношению ко всему пакету услуг, который вы фактически сможете поддерживать в рабочем состоянии 100% времени, и у вас не должно возникнуть никаких проблем.

Кроме того, стоит отметить, что весь смысл SLA состоит в том, чтобы определить, каковы ваши обязательства и что произойдет, если вы не сможете их выполнить. Неважно, будет ли клиент запрашивать 3, 5 или 9, или миллион - вопрос в том, что они получат, когда / если вы не можете доставить. Очевидный ответ заключается в предоставлении позиции для 100% безотказной работы при 5-кратной цене, которую вы хотите взимать, а затем они получат 4-кратное возмещение, если вы пропустите эту цель. Вы можете забить!

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

Именно так работает GTM в F5 Big IP - для DNS TTL по умолчанию установлено значение 30 секунд, и если один член кластера должен вступить во владение, DNS обновляется, и новый IP-адрес используется почти сразу. Максимум 30 секунд простоя, но это крайний случай, в среднем будет 15 секунд.

Вы знаете, что это невозможно.

Без сомнения, клиент сосредоточен на том, чтобы увидеть «100%», поэтому лучшее, что вы можете сделать, - это пообещать 100%, за исключением [всех разумных причин, которые не являются вашей ошибкой].

Хотя я сомневаюсь, что это возможно на 100%, вы можете рассмотреть возможность использования Azure (или чего-то подобного с SLA). Что происходит:

Ваши серверы являются виртуальными машинами. Если на одном сервере возникнет аппаратная проблема, ваша виртуальная машина будет перенесена на новую. Балансировщик нагрузки заботится о перенаправлении, поэтому клиент не должен видеть никаких простоев (хотя я не уверен, как это повлияет на состояние ваших сеансов).

Тем не менее, даже с этим переключением, разница между 99,999 и 100 граничит с безумием.

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

Честно говоря, 100% абсолютно безумен, по крайней мере, с точки зрения хакерской атаки. Лучше всего делать то, что делают Google и Amazon, так как у вас есть решение для геораспределенного хостинга, где ваш сайт и БД реплицированы на несколько серверов в разных географических точках. Это будет гарантировать что-либо кроме крупной катастрофы, такой как интернет-магистраль, сокращенная в регион (что случается время от времени) или что-то почти апокалиптическое.

Я бы поставил пункт только для таких случаев (DDOS, перерезание магистрали в Интернете, апокалиптический теракт или большая война и т. Д.).

Кроме этого посмотрите на облачные сервисы Amazon S3 или Rackspace. По сути, облачная установка будет предлагать не только избыточность в каждом местоположении, но также масштабируемость и геораспределение трафика, а также возможность перенаправления вокруг неисправных географических зон. Хотя я понимаю, что геораспределение стоит больше денег.

Я просто хотел добавить еще один голос на вечеринку "это можно (теоретически) сделать".

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

В любой конфигурации где-то почти всегда есть одна точка отказа, но если вы работаете достаточно усердно, вы можете превратить эту точку отказа в нечто, что можно исправить «вживую» (т. Е. Root dns отключается, но значения по-прежнему кэшируются везде, чтобы у вас было время это починить).

Опять же, не говоря, что это выполнимо. Мне просто не понравилось, как ни один ответ не касался того факта, что это не «выход» - это просто не то, чего они на самом деле хотят, если думают об этом.

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

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

Иногда крупные веб-компании измеряют доступность или надежность, используя следующие показатели:

1. процент запросов, на которые были успешно получены ответы без ошибок на стороне сервера (HTTP 500).
2. процент запросов, на которые дан ответ ниже определенной целевой задержки .
3. пропущенные запросы должны учитываться в вашей статистике (см. ниже).

Доступность не должна измеряться с помощью пробных проб, о которых могут сообщать внешние объекты, такие как pingdom и pingability. Не полагайтесь исключительно на это. Если вы хотите сделать это правильно, каждый запрос должен учитываться . Измерьте вашу доступность, глядя на ваш фактический, воспринимаемый успех.

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

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

Обсудите эту методологию с вашим клиентом и объясните ее преимущества. Установите базовую линию , измерив их текущую доступность. Им станет ясно, что 100% - невозможная цель.

Затем вы можете подписать контракт на основе улучшений базовой линии. Скажем, если они в настоящее время испытывают 95% доступности, вы можете пообещать улучшить ситуацию в десять раз , достигнув 98,5%.

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

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

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

Ну, это намного проще, чем это. Это математически невозможно .

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

Пойдите, возьмите книгу по контролю качества производства, используя статистическую выборку. Общая дискуссия в этой книге, концепции которой любой менеджер мог бы раскрыть в курсе общей статистики в колледже, диктует, какие затраты необходимо увеличить с 1 исключения из тысячи до 1 из десяти тысяч до 1 из миллиона до 1 из миллиарда растет экспоненциально. По сути, способность достигать 100% времени безотказной работы обойдется практически в неограниченное количество средств, вроде количества топлива, необходимого для того, чтобы толкнуть объект со скоростью света.

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

Я не думаю, что клиент на самом деле требует 100% безотказной работы или даже 99,999% безотказной работы. Если вы посмотрите на то, что они описывают, они говорят о том, чтобы узнать, где они остановились, если метеорит вывезет их локальный центр обработки данных.

Если требование заключается в том, что внешние люди даже не замечают, насколько радикальным это должно быть? Будет ли приемлемым повторное выполнение запроса Ajax с отображением счетчика в течение 30 секунд для конечного пользователя?

Это те вещи, о которых заботится клиент. Если бы клиент действительно думал о точных соглашениях об уровне обслуживания, он бы знал достаточно, чтобы выразить его как 99,99 или 99,999.

мои 2 цента. Я отвечал за очень популярный веб-сайт для компании из списка Fortune-5, которая занималась рекламой суперкубка. Мне приходилось сталкиваться с огромными скачками трафика, и я решил использовать такой сервис, как Akamai. Я не работаю на Akamai, но я нашел их обслуживание очень хорошим. У них есть своя, более умная система DNS, которая знает, что с конкретным узлом / хостом либо находится под большой нагрузкой, либо не работает, и может соответствующим образом маршрутизировать трафик.

Отличительной особенностью их службы было то, что мне не нужно было делать ничего очень сложного, чтобы реплицировать контент на серверах в моем собственном центре обработки данных в их центр обработки данных. Кроме того, я знаю, что работая с ними, они активно использовали HTTP-серверы Apache.

Хотя и не 100% времени безотказной работы, вы можете рассмотреть такие варианты распространения контента по всему миру. Как я понял, у Akamai также была возможность локализовать трафик, то есть если я был в Мичигане, я получал контент с сервера в Мичигане и Чикаго, и если я был в Калифорнии, якобы получал контент с сервера, расположенного в Калифорнии.

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

Для сайтов, размещенных извне, самое близкое время, которое вы получите к 100% времени безотказной работы, - это размещение вашего сайта в Google App Engine и использование хранилища данных с высокой репликацией (HRD) , которое автоматически реплицирует ваши данные как минимум в трех центрах обработки данных в режиме реального времени. Аналогично, внешние серверы App Engine автоматически масштабируются / реплицируются для вас.

Однако даже со всеми ресурсами Google и самой сложной в мире платформой гарантия безотказной работы App Engine SLA составляет «99,95% времени в любом календарном месяце».

Простой и прямой: Anycast

http://en.wikipedia.org/wiki/Anycast

Это то, что cloudflare, google и любая другая крупная компания используют для обеспечения избыточного межконтинентального аварийного переключения / балансировки с низкой задержкой.

Но также имейте в виду, что 100% времени безотказной работы невозможно и что затраты на переход с 99,999% до 99,9999% НАМНОГО больше.