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

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

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

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

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

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

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

Идеи?

UPDATE

Сегодня у меня была дискуссия с клиентом, и они разъяснили эту проблему.

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

304 голоса | спросил NotMe 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 29 Sep 2011 04:31:31 +0400 2011, 04:31:31

27 ответов


361

Ниже приведена удобная карта Википедии :

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

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

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

ответил GregD 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 29 Sep 2011 05:03:55 +0400 2011, 05:03:55
185

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

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

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

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

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

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

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

ответил Preet Sangha 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 29 Sep 2011 13:45:36 +0400 2011, 13:45:36
140

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

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

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

ответил EEAA 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 29 Sep 2011 04:39:35 +0400 2011, 04:39:35
54

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

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

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

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

Лак не может прервать SSL, однако, если это вызывает беспокойство, вы можете посмотреть на что-то вроде Nginx.

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

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

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

ответил jdw 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 29 Sep 2011 04:47:11 +0400 2011, 04:47:11
29

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

  

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

ответил Nick Pierpoint 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 29 Sep 2011 14:13:14 +0400 2011, 14:13:14
25

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

ответил Mike 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 29 Sep 2011 05:10:09 +0400 2011, 05:10:09
24

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

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

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

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

ответил Jungle Hunter 30 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 30 Sep 2011 19:49:43 +0400 2011, 19:49:43
17

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

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

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

ответил voretaq7 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 29 Sep 2011 07:41:13 +0400 2011, 07:41:13
13

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

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

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

ответил Bryan Boettcher 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 29 Sep 2011 23:01:27 +0400 2011, 23:01:27
10

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

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

ответил Paweł Brodacki 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 29 Sep 2011 10:41:10 +0400 2011, 10:41:10
10

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

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

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

* У этого же человека может быть не смущение, спрашивающее о путешествии Faster-than-Light, Perpetual Motion, Cold Fusion и т. д.

ответил Irving 30 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 30 Sep 2011 16:24:59 +0400 2011, 16:24:59
8

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

ответил jhocking 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 29 Sep 2011 18:50:35 +0400 2011, 18:50:35
6

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

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

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

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

ответил A T 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 29 Sep 2011 11:45:24 +0400 2011, 11:45:24
6

Это легко. В SLA Amazon EC2 четко указано:

  

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

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

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

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

ответил fields 30 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 30 Sep 2011 17:39:59 +0400 2011, 17:39:59
5

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

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

ответил Paul 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 29 Sep 2011 04:53:44 +0400 2011, 04:53:44
5

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

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

ответил Marcin 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 29 Sep 2011 19:02:20 +0400 2011, 19:02:20
4

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

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

Тем не менее, даже с этой неудачей разница между 99.999 и 100 граничит с безумием.

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

ответил JSWork 29 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 29 Sep 2011 20:04:36 +0400 2011, 20:04:36
4

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

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

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

ответил pthurmond 30 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 30 Sep 2011 02:05:30 +0400 2011, 02:05:30
3

Я просто хотел добавить еще один голос в «it can (теоретически) сделать« party ».

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

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

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

ответил Mahmoud Al-Qudsi 30 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 30 Sep 2011 02:56:08 +0400 2011, 02:56:08
3

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

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

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

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

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

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

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

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

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

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

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

ответил Yves Junqueira 2 +04002011-10-02T21:19:56+04:00312011bEurope/MoscowSun, 02 Oct 2011 21:19:56 +0400 2011, 21:19:56
3

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

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

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

ответил Karoly Horvath 15 PM00000030000001931 2013, 15:27:19
2

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

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

ответил James Pulley 3 +04002011-10-03T18:47:05+04:00312011bEurope/MoscowMon, 03 Oct 2011 18:47:05 +0400 2011, 18:47:05
1

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

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

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

ответил Kevin Peterson 30 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 30 Sep 2011 23:22:12 +0400 2011, 23:22:12
1

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

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

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

ответил Kilo 1 +04002011-10-01T03:13:35+04:00312011bEurope/MoscowSat, 01 Oct 2011 03:13:35 +0400 2011, 03:13:35
0

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

ответил Christian 2 +04002011-10-02T20:55:01+04:00312011bEurope/MoscowSun, 02 Oct 2011 20:55:01 +0400 2011, 20:55:01
0

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

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

ответил espeed 28 Maypm13 2013, 13:59:40
0

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

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

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

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

ответил Leon Waldman 28 Maypm13 2013, 19:45:46

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132