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

312

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

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

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

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

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

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

Идеи?

ОБНОВИТЬ

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

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

Не я
источник
49
Не стоит недооценивать огромное время простоя, вызванное взломом, посмотрите на Sony и сеть PlayStation. Вы можете гарантировать, что у них была та же самая идея 100% безотказной работы и деньги / оборудование, чтобы поддержать это. разъясните клиенту, что 100% бесперебойной работы - это невыполнимое ожидание, даже специалисты Google не решатся проболтать «100% бесперебойной работы». Подсказка, кстати, заключается в том, чтобы изучить использование динамического DNS, они кэшируются только в течение 60 секунд, это должно включать ОС и локальные DNS-серверы.
Silverfire
182
Я бы лично побежал от этого клиента как можно быстрее. Я подозреваю, что это не будет последней сумасшедшей идеей, которую они могут иметь (с технологической точки зрения).
GregD
137
Я хотел бы понизить голос вашего клиента.
Joeqwerty
81
Если вы выясните, 100% безотказной работы, дайте мне знать. Я создам бизнес с этим и продам это Google. Невозможно гарантировать 100%. Даже такие компании, как Microsoft, Amazon или Google, не пойдут так высоко, потому что знают, что это невозможно. Лучшее, что я видел, составляет 99,999%, и даже это растянуто (5 минут в году). Лучшее, что вы могли бы сделать, это надежно на 99,99%.
Мэтт
39
Просто сделайте безумно высокий ценник, чтобы поставить их на безумный запрос. Это, вероятно, вернет их в чувство. Либо чем, либо он отправит их искать кого-то, кто хочет им лгать.
Нейт СК

Ответы:

368

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

введите описание изображения здесь

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

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

GregD
источник
62
Пингдом тоже не проверяет каждую секунду. Вдобавок ко всему, у тех, кто действительно встретил пять девяток, вероятно, все еще были локализованные сбои, которые Pingdom мог не обнаружить, или сбои, которые делали некоторые службы недоступными, все еще отвечая на эхо-запросы.
ceejayoz
8
Что само по себе делает пять девяток сомнительными ...
GregD
5
Точно. И у них есть миллиарды долларов для работы!
ceejayoz
43
Извините, что мешаю чату, но вопрос ОП заключался в том, как стремиться к достижению цели 100% бесперебойной работы на техническом уровне, а не концептуально, я уверен, что он знает, что это не всегда возможно из-за естественных явлений, которые происходят с оборудованием и окружающая среда. Можем ли мы помочь ему с этим?
Дэвид д С е Фрейтас
5
К OP: Я видел SLA, которые гарантировали время безотказной работы в контексте «вне нормального обслуживания». Обычное обслуживание, конечно, запланированное время простоя в месяц для обновлений, исправлений и т. Д., Которое обычно происходит в их наименее загруженный день месяца в течение наименее загруженного времени месяца (обычно в середине ночи). У них должен быть некоторый тип метрик для их бизнеса относительно бизнеса. Вы могли бы предложить лучшее время работы (4 девяток) для них только в это время.
GregD
186

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

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

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

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

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

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

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

Прит Сангха
источник
21
Согласовано. Они могут просто означать «очень высокое» время безотказной работы (верхние 90-е?) При довольно солидной стратегии восстановления после отказа. Если нет, то объяснение масштаба затрат, возможно, убедит их ...
Мартин Доу,
32
+1 за то, что не спешите с выводами, а просто попросите клиента объяснить, что он имеет в виду.
Слёске
4
Я повторяю утверждение «не спешить с выводами» ... если клиент подразумевает 100% безотказной работы (минус плановое обслуживание), то это может быть более разумным требованием.
Тим Редди
1
Что касается влияния на бизнес, мы на самом деле знаем и понимаем их бизнес полностью, а затраты, связанные с падением сайта, не являются финансовыми. Еще по линии туземцев, появляющихся с вилами, потенциальными повешениями и т. Д .;) Просто представьте, как 40000 человек появляются с криком у вашей входной двери. Это то, чего они хотят избежать со страстью.
NotMe
7
@ChrisLively Все больше причин для зрелого понимания риска. Доминирующей парадигмой проектирования безопасности является вероятностная оценка риска . Существуют системы, которые могут убивать (не просто раздражать) тысячи людей, и у них все еще есть низкая, надеюсь, хорошо понятная, но ненулевая вероятность отказа.
пул
140

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

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

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

EEAA
источник
7
Согласовано. Полностью. Псих.
JDW
2
они обычно ??
Sirex
2
@Sirex Обращаясь к недавнему эксперименту @ CERN, в котором было обнаружено, что нейтрино движутся быстрее света. Результаты еще не подтверждены независимыми учеными.
TC1
9
@ TC1 Я поставлю тебе 200 долларов, которые не сработают.
dpatchery
4
@ErikA Запрос на 100% безотказной работы свидетельствует о незнании технических характеристик систем. Это нормально, потому что работа клиента - делать то, что он делает. Ваша работа заключается в разработке ИТ-систем. Такие сложные клиенты могут быть кошмарами, но они также могут стать вашими лучшими клиентами.
duffbeer703
54

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

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

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

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

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

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

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

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

JDW
источник
2
Некоторое время я думал об Amazon и MS для облачного развертывания, но у них обоих были серьезные перебои в работе за последние пару месяцев. SSL имеет решающее значение.
NotMe
3
Если вы собираетесь использовать Amazon, вам наверняка захочется распределить свои машины по 5 зонам доступности. Маловероятно, что все их зоны будут выходить одновременно.
JDW
11
+1 за реальный ответ на главный вопрос ОП.
Фил
у вас всегда будет точка отказа, jdw, до тех пор, пока в цепочке есть нераспределенная вещь (в вашем случае сердцебиение, если, конечно, у вас нет нескольких экземпляров этого запуска на удаленных машинах, которые все контролируют друг друга, а также ваш серверы, которые любой из них может видеть или не видеть из-за проблем с сетью на маршрутизации). Что приводит нас к «простоям». Серверы могут быть в рабочем состоянии и по-прежнему недоступны для клиента, при этом сигнал пульса не обнаружит его, если сбой отсутствует в пути маршрутизации.
С
Согласовано. Как уже отмечали ВСЕ, 100% времени безотказной работы не существует. Все, что вы можете сделать, это попробовать, и то, что я описал, это то, как я бы начал пытаться.
JDW
30

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

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

Ник Пирпойнт
источник
2
+1 за то, что отметили, что 100% - это не 100,0% или 100 000% и т. Д. Десятичные цифры имеют значение, они указывают на точность;)
Дунайский моряк,
4
Согласно некоторым соглашениям, «100%» имеет только одну значимую цифру, так что все числа от половины до одного округляются до «100%»; 50% округлились бы до 100%.
Томас Левин
1
В зависимости от стандарта для подсчета некоторые скажут, что у 50% есть два числа, означающие мелкие числа, где 100% имеет три числа, равные нулю. 50,5 и 100 здесь так же точно. Другие будут считать цифры после десятичной точки. Тогда 50,5 и 100,4 будут точно такими же. Если ничего не указано, я бы предположил, что 100% - это 99,5% и выше. 100,0% - это 99,95% и выше и т. Д.
Тилбек
26

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

Майк
источник
17
он мог бы быть умнее всех их людей вместе взятых, кто знает: р
Мэтт
3
100% бесперебойной работы не обязательно должны быть такими буквальными людьми - это означает: 100% доступности в течение необходимого времени. Например, банковские системы всегда должны быть доступны, и они работают достаточно хорошо. То, что они уходят на техническое обслуживание на 1 секунду один раз в год, не означает, что они потерпели неудачу со своей 100% целью безотказной работы.
Дэвид д С е Фрейтас
13
@DavidFreitas - я думаю, что в контрактах это обычно довольно буквально ...
UpTheCreek
2
@Matt только потому, что Facebook / Amazon не может этого сделать, не означает, что меньший сайт не может этого сделать. Многие крупные сайты сталкиваются с гораздо более сложными проблемами, чем меньшие.
Ксорлев
1
так что вы говорите, что у вас не было 100% безотказной работы, так как у вас были клиенты, у которых были ошибки ... плюс dns не является мгновенным переключателем, поскольку у вас есть интернет-провайдеры, которые игнорируют короткие TTL
Майк
25

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

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

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

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

Охотник джунглей
источник
6
Проблема в том, что они говорят это по-контрактно. Это означает, что если произойдет катастрофа , и вам потребуется более десяти секунд, чтобы вернуть сайт в оперативный режим с помощью резервных копий, на которые они могут подать в суд.
Шадур
@Shadur: Если они действительно хотят этого, то вы должны действительно зарядить их. Распространите серверы географически повсюду, надеюсь, повсюду не будет катастрофы.
Охотник на джунглей
3
Я видел сайт, который предлагает 100% гарантию бесперебойной работы или ваши деньги обратно. Хитрость была в том, что они взяли судно и разделились на месяцы. Таким образом, некоторые месяцы остаются неоплаченными, и вы планируете все вокруг этого, и покрываете потери месяцами, которые хорошо работают.
jldugger
17

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

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

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

voretaq7
источник
2
Необходимо определить 100%, т. Е. Доступно 100%, за исключением тех случаев, когда выполняется техническое обслуживание или обновление, и это время будет ограничено тихими часами в течение максимум нескольких часов в месяц. Все зависит от того, какова цель и использование веб-приложения в этом случае ...
David d C e Freitas
1
и определить «время простоя». Даже теоретически не может гарантировать, что они смогут получить доступ к серверу в Омахе из своих офисов в Фэрбенксе, если вы не контролируете всю промежуточную сеть (хотя вы можете дать гарантии о том, что сервер запущен и работает).
С
Определения, IMHO, не имеют значения, если они запрашивают «100% безотказную работу»: даже если вы договариваетесь о плановом обслуживании и встраиваете избыточность N + N, если один незначительный сбой вызывает незапланированную перезагрузку или мигание службы, вы взорвали ваш SLA. Определенно актуально, если вы ведете переговоры по 3, 4 или 5 девяток SLA, хотя.
voretaq7
Хотя зависит от условий SLA, не так ли? Если вам платят 100 тыс. Долларов в месяц, и каждая минута простоя влечет за собой штраф в размере 1 тыс. Долларов, это может быть вполне выполнимо (если у вас есть другие контракты для амортизации стоимости системных администраторов в режиме 24/7).
Майкл Боргвардт
@MichaelBorgwardt, безусловно, есть способы «заставить это работать» с точки зрения чистых чисел, но я бы все равно отказался из-за вероятности плохого пиара ($ _CLIENT заходит в Twitter и сообщает миру: «Мы упали, потому что $ _PROVIDER некомпетентен» и не могу встретить их SLA! '). Лично я предпочел бы, чтобы 10 меньших, более разумных клиентов платили мне 10 тысяч долларов в месяц :-)
voretaq7
13

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

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

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

Брайан Бетчер
источник
3
Если вы видите, что кто-то обещает 100% бесперебойной работы, то это именно то, что они делают. Существует разница между обещанием 100% бесперебойной работы и его предоставлением. Было бы неплохо объяснить это клиенту, если он попытается процитировать вам SLA конкурента.
sjbotha
10

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

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

Павел Бродацкий
источник
10

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

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

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

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

Ирвинг
источник
2
+1 за тест апельсинового сока .. Мне нравится и не знал об этом :)
Оливер М Греч
8

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

jhocking
источник
6

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

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

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

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

В
источник
1
Да, DNS - хорошее начало - например, nslookup google.comвозвращает 6 разных IP-адресов для резервирования в случае, если некоторые из них не работают. Также проверьте RobTex.com отличный сайт, чтобы посмотреть конфигурации определенных доменов, например, robtex.com/dns/google.com.html#records
Дэвид Д и Фрейтас
6

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

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

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

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

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

поля
источник
5

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

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

Павел
источник
10
По моему опыту, некоторые DNS-серверы игнорируют TTL, который они считают ужасно низким (несмотря на RFC). Все, что меньше 5 минут, становится несколько ненадежным в глобальном масштабе.
JDW
13
@ Пол игнорировать реальность не является приемлемой практикой, независимо от того, насколько она всех бесит.
MDMarra
5
Я с JDW по этому вопросу. Я видел, как многие DNS-серверы полностью игнорировали TTL, даже настройку на 1 час и возвращение по умолчанию примерно к 24 часам или около того.
NotMe
6
@Paul - OP не контролирует DNS-преобразователи DNS каждого провайдера на планете. Поэтому у них нет выбора, чтобы сказать «если вы собираетесь использовать наш веб-сайт, не используйте Comcast / Roadrunner / whomever в качестве интернет-провайдера, потому что они будут игнорировать наши настройки TTL». Это то, что просто находится вне их контроля и поэтому слишком хрупко, чтобы считаться решением этой проблемы ИМХО. Решение должно включать некоторый способ внутренней IP-адресации, не полагаясь на другие биты сети, которые могут быть несовместимыми.
JDW
3
Это похоже на отсутствие ИБП, потому что питание «должно просто работать». Это не дальновидный способ создания системы. Если вы знаете, что по какой-то причине существует хрупкая часть системы, вы должны попытаться объяснить это.
JDW
5

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

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

Marcin
источник
Без сомнения, клиент не хочет никакого решения. Они хотят снижения. Так что они могут сказать, что они пытались по крайней мере.
mbx
Ну, может быть. Вы предполагаете высокий уровень подсказки.
Марчин
4

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

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

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

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

JSWork
источник
2
У Azure и EC2 недавно были почти полные и полные сбои. Я считаю, что Azure был недавно отключен просто из-за неправильной записи конфигурации на DNS-сервере. В любом случае, спасибо за информацию.
NotMe
и если ваш балансировщик нагрузки (который выполняет переключение) выходит из строя незамеченным (его монитор также может быть отключен незамеченным, до бесконечности), когда узел выходит из строя, вы все равно облажались.
jwenting
1
Я думаю, что вы имели в виду «некомпетентность». «Импотенция» не должна сильно влиять на способность ИТ-персонала выполнять свою работу.
mfinni
4

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

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

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

Патрик
источник
3

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

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

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

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

Махмуд Аль-Кудси
источник
3

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

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

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

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

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

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

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

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

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

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

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

Ив Жункейра
источник
3

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

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

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

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

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

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

Джеймс Пули
источник
1

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

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

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

Кевин Петерсон
источник
Если клиент думает, что ему нужно «100% безотказной работы», и именно тогда он попадает в словесное заверение контракта, вы можете его задержать, если он окажется в суде. Лучше всего обговорить это и помочь клиенту понять, чего он действительно хочет, а не предполагать, что вы знаете, о чем он думает.
Крис С
О, я согласен, что это должно быть прояснено, прежде чем оно попадет в контракт. Я просто говорю, что к этому нужно подходить, поскольку клиент не сообщает, чего он на самом деле хочет, а клиент просит чего-то нелепого.
Кевин Петерсон
1

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

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

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

кило
источник
-1 потому что это практичный ответ, но совсем не полезный. На все вопросы на этом сайте можно было бы ответить «наймите кого-нибудь другого, чтобы сделать это», но мы здесь не для этого.
Ив Жункейра
Позволю себе не согласиться. "Не полезно вообще?" Это было, безусловно, полезно для меня, и, вопреки вашему комментарию «наймите кого-нибудь другого, чтобы сделать это», я полагаю, что, исходя из ваших соображений, парень должен проложить свой собственный оптоволоконный кабель и спроектировать свои собственные переключатели, а не покупать их тоже? Ты серьезно, Ив? Вы говорите, как кто-то, кто не провел много времени в области ИТ.
Кило
0

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

Кристиан
источник
0

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

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

espeed
источник
0

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

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

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

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

Леон Вальдман
источник