Здравствуйте, Sharowarsheg, Вы писали:

S>Если задача не важная, то вопрос сводится к цене — у кого дешевле. А если у Аэрофлота падает система бронирования билетов из-за того, что они хостились в облаке и облако упало, то это некомпетентность Аэрофлота, а работоспособность облака — это второе, если не третье дело. Прогрессивные молодежные течения, однако, состоят в том, что Роскомнадзор банит часть облаков и начинают падать всякие банки, онлайн-кассы, и прочее, и все специалисты ограничиваются руганью в адрес Роскомнадзора. Как будто все говорят "вот, мы отдали свои системы в облако, пусть отвечает хозяин облака".
Тут речь идёт о бабле.

В США для сферической компании в вакууме организация отказоустойчивого сервиса, географически распределённого и с круглосуточной поддержкой, требует около одного миллиона долларов в год. В основном, на зарплату персонала.

Так что считаем что будет дороже — один день простоя раз в 5 лет, или миллион долларов в год? Если дороже простой, то тогда имеет смысл делать свою инфраструктуру. Этот расчёт может быть скорректирован в ту или иную сторону с учётом обстоятельств, но порядок цифр примерно останется.

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

При этом, есть методы обеспечения надёжности в облачных системах — можно запускать сервисы сразу в нескольких облаках (от MS и Azure) и в нескольких регионах.

Здравствуйте, Sharov, Вы писали:

S>Про что-то подобное я как раз и читал в крайне древней работе "hypervisor-based fault-tolerance" (pdf можно нагуглить). Но там процессоры сидели на одной scsi шине. И то там были пляски с
S>IO прерываниями. Поэтому я не понял, как можно устранить источник случайности?
У каждого узла своя память. Но все внешние события доходят до гостевых узлов только через сеть. RDTSC и прочие RDRAND виртуализованы.

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

Для XEN это делает Remus ( https://wiki.xenproject.org/wiki/Remus ). Вот статья о нём: https://www.usenix.org/legacy/event/nsdi08/tech/full_papers/cully/cully_html/index.html

C>>Но таких технологий сейчас (по крайней мере примерно до конца этого года ) в публичных облаках нет ни у кого.
S>У aws чего-то планируется, если не секрет?
Если был бы не секрет, то сказал бы

S>А как же быть с выполняющимися процессами и сост. процессора? Правильно ли я понимаю,что у нас фактически будет устаревший (возможно на несколько мс) снапшот системы?
Будет полностью идентичная копия. При копировании сначала переносится основной объём данных и в исходной системе начинается отслеживание изменений (грязные страницы памяти, IO-запросы и т.п.). Изменения на лету передаются на целевую систему. Затем исходная система останавливается, реплицируются оставшиеся мелочи, и целевая система запускается с того места, где была остановлена исходная.

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

C>>Географическая распределённость — это вообще отдельный разговор. Скорость света делает все "прозрачные" решения полностью бесполезными.
S>Имеются ввиду сопутствующие релятивистские() эффекты или что?
Нет, просто тупо свет слишком медленный. На удалении в 3000 километров латентность будет минимум в 10 миллисекунд в одну сторону, в реальности где-то раза в 2 больше.

Здравствуйте, Sharov, Вы писали:

S>Да, но как эти инстансы находятся в консистентном состоянии между собой?

Используя распределённые архитектуры. Например распределённую БД.

S>И все консистентно на уровне состояния процессора, памяти, кэшей и т.д. Так это работает? Такое вообще возможно?

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

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

Здравствуйте, Sharowarsheg, Вы писали:

S>> географически распределенная консистентность на уровне сост. процессора, кэшей и памяти пока не доступна. Ну т.е. доступна, но, вероятно, крайне дорога.

S>Скорее, крайне медленна и быстрой не делается ни за какие деньги.

IBM geographically dispersed parallel sysplex есть. С непрерывной репликацией на какие-то сотни километров.

Насколько я понимаю, high availability обеспечивается кучей одинаковых инстансов, а не бессмертным инстансом. А миграция проводится в запланированном русле, чтобы выключить потом сервер, а не автоматом.

Здравствуйте, Cyberax, Вы писали:

C>И ещё, во время того эпичного отказа S3, по всему Амазону несколько тысяч инженеров работали над её решением или смягчением последствий. Если бы аналогичный отказ произошёл бы в полуподвальном ДЦ в ночь на 1-е января, то сколько инженеров работали бы над ней?

У этого есть другая сторона — сколько народу затронул бы отказ полуподвального ДЦ в ночь на первое января?

Здравствуйте, Cyberax, Вы писали:

C>Да, мелкие компании вынуждены бороться за клиента. С другой стороны, у крупной компании, скорее всего, будет отлаженный процесс по исправлению проблем. Или не будет — как повезёт.

Это, кстати, фундаментальный вопрос, и мне не нравятся прогрессивные тенденции. Я считаю, что если у тебя какая-то довольно важная задача, неважно где, на хостинге, в облаке, на сервере под столом, то у тебя должен быть свой собственный отлаженный процесс по исправлению проблем, который чем меньше зависит от посторонних, тем лучше. Если задача не важная, то вопрос сводится к цене — у кого дешевле. А если у Аэрофлота падает система бронирования билетов из-за того, что они хостились в облаке и облако упало, то это некомпетентность Аэрофлота, а работоспособность облака — это второе, если не третье дело. Прогрессивные молодежные течения, однако, состоят в том, что Роскомнадзор банит часть облаков и начинают падать всякие банки, онлайн-кассы, и прочее, и все специалисты ограничиваются руганью в адрес Роскомнадзора. Как будто все говорят "вот, мы отдали свои системы в облако, пусть отвечает хозяин облака".

Здравствуйте, Sharov, Вы писали:

S>Про уровень приложения понятно. БД, event consist. и т.д. Я имел ввиду такую ситуацию -- вот работаю я через RDP с ОС, запустил документ, редактирую (ну вот захоетлось это в облаке сделать). В какой-то момент желозо ломается,
S>мне выдают новое, а я вообще ничего не замечаю. Как набирал себе текст в word'е так и набираю. Такое в облаках возможно?

Это в обычном ESXi возможно, но заминка в несколько секунд всё же будет.

Здравствуйте, Sharov, Вы писали:

S>Ау. Чего все молчат -- вопрос не правильно сфорумулирован?
S>На всякий случай реквестирую в тред СпанчекряксаCyberax'а . Уж он то точно что-нибудь да ответит.
Гипервизоры сами по себе не добавляют отказоустойчивости. Обычно.

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

Но таких технологий сейчас (по крайней мере примерно до конца этого года ) в публичных облаках нет ни у кого.

Следующий уровень — это миграция гостевых систем на лету. Это делается на узлах семейства T2 (а так же скоро C5 и M5) в Амазоне. Если самодиагностика железа указывает на возможные проблемы, то гостевые системы будут прозрачно реплицированы на другой физический узел. При этом полностью переносится память, состояние дисков и настройки сети. Так что пользователи увидят только небольшую задержку порядка 50 миллисекунд, когда происходит финальная передача управления.

Но это всё не поможет от ошибок в самой ОС. Так что более правильно — это проектировать приложение для распределённой работы. Самое простое — это сделать вычислительные узлы полностью stateless, чтобы можно было при желании просто запустить их заново. При этом проще всего использовать сервисы типа RDS, DynamoDB и CloudWatch Logs для хранения данных.

Географическая распределённость — это вообще отдельный разговор. Скорость света делает все "прозрачные" решения полностью бесполезными.

Здравствуйте, Sharov, Вы писали:

S>Вот именно про это можно где-то попкорнее почитать?
На русском
На английском лучше наверное в документации vmware или в pdf-ках

Вживую не видел, прямого аналога у ms/citrix/open source вроде как нет, стоит дорого и пользуется мало кто. Так-что real stores мало.
Технически это развитие vMotion — когда виртуалки перемещались между гипервизорами без отключения, но с небольшим фризом (1-3 секунды).
Основные проблемы — высокая цена (и по и простаивающее железо), тормоза для ресурсоемких систем и по определению не защищает от программных сбоев, а они на несколько порядков чаще аппаратных.

Здравствуйте, Sharov, Вы писали:

S>Допустим по RDP работаю с вордом в ЕС2. Что-то происходит, инстанс, точнее железно его крутящее, падает. Я вообще ничего не замечаю, все как и было,
S>продолжаю писать что-то в ворд, и даже не подозреваю, что общаюсь уже с другим инстансом-железом.

Чот мне думается, что конкретно в этом случае, все несохраненные изменения пропадут. Потом виртуалку подымут на другом железе, примапят диски продолжай работать после реконекта. Главное в SLA 99.95% вложиться.

Здравствуйте, Sharov, Вы писали:

S>Вот имеется у нас некий инстанс в облаке. Вот мы с ним работаем, что-то туда пишем и т.д. Потом железо в облаке накрывается.

S>Вопрос: правильно ли я понимаю, что современные технологии могут обеспечить бесперебойную работу сервиса в данном случае?
Да, при правильном построении системы отказ любой железки не виляет на работу сервиса.
S>Т.е. тут же поднимется полностью реплицированный инстанс, и пользователь облачного сервиса вообще ничего не заметит. При этом никакие данные не будут потеряны, т.е. полная консистентность.
Это один из вариантов.
S>Если же я прав. То следующий вопрос, каким образом, т.е какими технологиями (железо+софт, хотя больше железо мне думается), это обеспечивается? Т.е. это все обеспечивается на уровне
S>hypervisor'а. Так или не так? Т.е. это будет какой-то raid, но как быть с данными в памяти и состоянием процессора?
Сейчас это чаще всего достигается балансировкой нагрузки между кучей инстансов. У тебя куча ВМ и фаловеры, которые принимают запросы и перенаправляют их на одну из работающих машин. Плюс любая вариация мониторинга, которая просигнализирует об отказе.
Другая крайность, вариант на уровне гипервизора, VMWare Fault Tolerance. Там диски виртуальных машин размещаются на общем хранилище (SAN/СХД/другие вариации), а память и состояние процессора с небольшим лагом передаются по сети с работающей копии вм на "теневую", готовую в любой момент времени при выходе основной продолжить работу практически с того же места.

Но вообще твой вопрос очень обширный и сложный. Надо что-то более конкретное рассматривать.

Здравствуйте, Sharov, Вы писали:


S>Если же я прав. То следующий вопрос, каким образом, т.е какими технологиями (железо+софт, хотя больше железо мне думается), это обеспечивается? Т.е. это все обеспечивается на уровне
S>hypervisor'а. Так или не так? Т.е. это будет какой-то raid, но как быть с данными в памяти и состоянием процессора?

Из коробки этого не умеет ни один гипервизор (если не касаться виртуализации в виде аппаратных доменов, которые имеются на машинах класса майнфреймов или SMP монстров на спарках). Но существует кучи опенсорсных софтварных систем для обеспечения отказустойчивости и мониторинга сервисов, накопителей и пр. всего. Админы облачных хостингов городят из (кучи дерьма и палок) всего этого инфраструктуру, обеспечивающую весь функционал.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте.

S>Вот имеется у нас некий инстанс в облаке. Вот мы с ним работаем, что-то туда пишем и т.д. Потом железо в облаке накрывается.

S>Вопрос: правильно ли я понимаю, что современные технологии могут обеспечить бесперебойную работу сервиса в данном случае?
S>Т.е. тут же поднимется полностью реплицированный инстанс, и пользователь облачного сервиса вообще ничего не заметит. При этом никакие данные не будут потеряны, т.е. полная консистентность.

S>Если же я прав. То следующий вопрос, каким образом, т.е какими технологиями (железо+софт, хотя больше железо мне думается), это обеспечивается? Т.е. это все обеспечивается на уровне
S>hypervisor'а. Так или не так? Т.е. это будет какой-то raid, но как быть с данными в памяти и состоянием процессора?


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


Накрывается обычно все по-софтовому. Сбой (ошибка) -> restart. Memory leak -> restart. Overload -> детект недоступности -> авто-scaling и правильные методы сохранения работы (напр. queues) и т.п.

А то и, банальное отсутствие связи клиент->облако. Например, туалет над клиентом протек и залил его модем с раутером

Как, например, проблема провайдера выглядит на EC2 (Amazon): приходит eMail, "Your instance is degraded and will be shutdown on 2018-..-..". Т.е., буть бобр, сделай что нибудь (сам). Так выглядят чудеса на "гражданском" уровне.

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

Здравствуйте, Слава, Вы писали:

S>>Скорее, крайне медленна и быстрой не делается ни за какие деньги.
С>IBM geographically dispersed parallel sysplex есть. С непрерывной репликацией на какие-то сотни километров.
Все производители, которые уверяют, что делают прозрачную работу в географически распределённых БД, нагло врут.

Здравствуйте.

Вот имеется у нас некий инстанс в облаке. Вот мы с ним работаем, что-то туда пишем и т.д. Потом железо в облаке накрывается.

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

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

Ау. Чего все молчат -- вопрос не правильно сфорумулирован?

На всякий случай реквестирую в тред СпанчекряксаCyberax'а . Уж он то точно что-нибудь да ответит.

Здравствуйте, smeeld, Вы писали:


S>Из коробки этого не умеет ни один гипервизор (если не касаться виртуализации в виде аппаратных доменов, которые имеются на машинах класса майнфреймов или SMP монстров на спарках). Но существует кучи опенсорсных софтварных систем для обеспечения отказустойчивости и мониторинга сервисов, накопителей и пр. всего. Админы облачных хостингов городят из (кучи дерьма и палок) всего этого инфраструктуру, обеспечивающую весь функционал.

А где можно почитать про проблезительную реализацию, например у aws? А то поиск по ключевым словам ничего интересного не дал. Мож там годами выработана терминология специфическая.

Здравствуйте, vsb, Вы писали:

vsb>Насколько я понимаю, high availability обеспечивается кучей одинаковых инстансов, а не бессмертным инстансом.

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

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

Я не про миграцию, а про железное падение, и как это все незаметно для пользователя.

Здравствуйте, Sharov, Вы писали:

vsb>>Насколько я понимаю, high availability обеспечивается кучей одинаковых инстансов, а не бессмертным инстансом.

S>Да, но как эти инстансы находятся в консистентном состоянии между собой? Они по идее геогрфически удалены для повышения отказоустойчивости. Вот у меня сломалась машина в Москве, тут же дали питерский инстанс.
S>И все консистентно на уровне состояния процессора, памяти, кэшей и т.д. Так это работает? Такое вообще возможно?

Могу рассказать, как это устроено у IBM MQ (Очередь сообщений). Думаю, у остальных реализовано более-менее похоже.

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

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

Здравствуйте, vsb, Вы писали:

vsb>Консистентность достигается на уровне логики приложения. Да и то не всегда. Т.е. ты залил фотку вконтакте на один сервер, он тут же сломался, но фотка уже успела реплицироваться на другие серверы и на следующей загрузке страницы ты её видишь как будто ничего не случилось. На уровне процессора я про такое не слышал, распределённость требует существенных усилий со стороны программиста, на халяву тут ничего не будет.

Про уровень приложения понятно. БД, event consist. и т.д. Я имел ввиду такую ситуацию -- вот работаю я через RDP с ОС, запустил документ, редактирую (ну вот захоетлось это в облаке сделать). В какой-то момент желозо ломается,
мне выдают новое, а я вообще ничего не замечаю. Как набирал себе текст в word'е так и набираю. Такое в облаках возможно?

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

Что-то типа того, да. Но это явно не облачный случай. Т.е. географически распределенная консистентность на уровне сост. процессора, кэшей и памяти пока не доступна. Ну т.е. доступна, но, вероятно, крайне дорога.

Здравствуйте, Sharov, Вы писали:

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

S>Что-то типа того, да. Но это явно не облачный случай. Т.е. географически распределенная консистентность на уровне сост. процессора, кэшей и памяти пока не доступна. Ну т.е. доступна, но, вероятно, крайне дорога.

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

Здравствуйте, Sharov, Вы писали:

S>Про уровень приложения понятно. БД, event consist. и т.д. Я имел ввиду такую ситуацию -- вот работаю я через RDP с ОС, запустил документ, редактирую (ну вот захоетлось это в облаке сделать). В какой-то момент желозо ломается,
S>мне выдают новое, а я вообще ничего не замечаю. Как набирал себе текст в word'е так и набираю. Такое в облаках возможно?

Практически нет.

S> географически распределенная консистентность на уровне сост. процессора, кэшей и памяти пока не доступна. Ну т.е. доступна, но, вероятно, крайне дорога.

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

Здравствуйте, Слава, Вы писали:

С>Здравствуйте, Sharowarsheg, Вы писали:

S>>> географически распределенная консистентность на уровне сост. процессора, кэшей и памяти пока не доступна. Ну т.е. доступна, но, вероятно, крайне дорога.

S>>Скорее, крайне медленна и быстрой не делается ни за какие деньги.

С>IBM geographically dispersed parallel sysplex есть. С непрерывной репликацией на какие-то сотни километров.

Я прочитал википедию про это, и там в основном упоминается storage replication. Оно точно умеет параллельную оперативную память? Я просто плохо себе представляю, как можно синхронизировать оперативную память на сколько-нибудь заметное расстояние с пингом порядка наносекунд.

S>>Скорее, крайне медленна и быстрой не делается ни за какие деньги.

С>IBM geographically dispersed parallel sysplex есть. С непрерывной репликацией на какие-то сотни километров.

на МФ parallel sysplex желеязячка в памяти которой храниться например список блокировок db2, все узлы db2 постоянно лезут туда по специфической оптической сетке, если нужно выяснить заблокирована ли запись. не самое стройное решение мягко говоря и требует специфического канала связи со всеми узлами (что-то типа FC).

Gt_

Здравствуйте, Cyberax, Вы писали:

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

Про что-то подобное я как раз и читал в крайне древней работе "hypervisor-based fault-tolerance" (pdf можно нагуглить). Но там процессоры сидели на одной scsi шине. И то там были пляски с
IO прерываниями. Поэтому я не понял, как можно устранить источник случайности?


C>Но таких технологий сейчас (по крайней мере примерно до конца этого года ) в публичных облаках нет ни у кого.

У aws чего-то планируется, если не секрет?

C>Если самодиагностика железа указывает на возможные проблемы, то гостевые системы будут прозрачно реплицированы на другой физический узел. При этом полностью переносится память, состояние дисков и настройки сети. Так что пользователи увидят только небольшую задержку порядка 50 миллисекунд, когда происходит финальная передача управления.

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

C>Географическая распределённость — это вообще отдельный разговор. Скорость света делает все "прозрачные" решения полностью бесполезными.

Имеются ввиду сопутствующие релятивистские() эффекты или что?

Здравствуйте, Cyberax, Вы писали:

С>>IBM geographically dispersed parallel sysplex есть. С непрерывной репликацией на какие-то сотни километров.
C>Все производители, которые уверяют, что делают прозрачную работу в географически распределённых БД, нагло врут.

Ссылки по теме (вам, как сотруднику и евангелисту Амазона, это может быть близко):
https://oldmann.livejournal.com/279374.html
https://oldmann.livejournal.com/226565.html
https://oldmann.livejournal.com/278681.html

И не совсем по теме, но близко:
https://oldmann.livejournal.com/273798.html
https://oldmann.livejournal.com/276987.html

За софт — деньги. За железо — деньги. За деньги — надёжность. За платный софт — хорошую зарплату и надёжную работу для инженеров, с 9 до 17. А энергичных стартаперов с гномиками и без выходных, даже отожранных без меры — в топку, всех этих гуглов с их айтишной субкультурой, пригодной для эластичного показа котиков в бесконечной ленте.

Здравствуйте, Слава, Вы писали:

С>>>IBM geographically dispersed parallel sysplex есть. С непрерывной репликацией на какие-то сотни километров.
C>>Все производители, которые уверяют, что делают прозрачную работу в географически распределённых БД, нагло врут.
С>Ссылки по теме (вам, как сотруднику и евангелисту Амазона, это может быть близко):
Я не буду говорить сколько ещё отказов не стали даже известны публике или были остановлены в зародыше инженерами в 3 часа ночи.

Ломается всё, и падения типа S3 в us-east-1 очень неприятны. Но таки даже в случае, когда упал S3 в us-east-1, все остальные регионы продолжали работать. Если условный магазин находился бы в eu-west-1, то с ним ничего бы не произошло. Это то, что в Амазоне называют "регионализацией". Почти все сервисы уже регионализованы, а оставшиеся будут исправлены в ближайшее время. Любые глобальные изменения, которые затрагивают сразу все регионы, сейчас требуют разрешения на уровне VP. Так что для отказоустойчивости приложение можно просто разместить в паре близких регионов.

И ещё, во время того эпичного отказа S3, по всему Амазону несколько тысяч инженеров работали над её решением или смягчением последствий. Если бы аналогичный отказ произошёл бы в полуподвальном ДЦ в ночь на 1-е января, то сколько инженеров работали бы над ней?

Здравствуйте, Sharowarsheg, Вы писали:

C>>И ещё, во время того эпичного отказа S3, по всему Амазону несколько тысяч инженеров работали над её решением или смягчением последствий. Если бы аналогичный отказ произошёл бы в полуподвальном ДЦ в ночь на 1-е января, то сколько инженеров работали бы над ней?
S>У этого есть другая сторона — сколько народу затронул бы отказ полуподвального ДЦ в ночь на первое января?
Только этот магазин, которые обслуживался в этом ДЦ. Но надолго — пока железо не заменят и/или админ не протрезвеет.

Для сравнения, даже тот сбой S3 длился чуть более 4 часов.

Здравствуйте, Cyberax, Вы писали:

C>И ещё, во время того эпичного отказа S3, по всему Амазону несколько тысяч инженеров работали над её решением или смягчением последствий. Если бы аналогичный отказ произошёл бы в полуподвальном ДЦ в ночь на 1-е января, то сколько инженеров работали бы над ней?

В начале 0-х у меня друг работал у не самого крупного районного провайдера (7тыс домашних пользователей), так один раз в ночь на 1 января его выдернули, и они вместе с владельцем фирмы лазали на чердак чего-то чинить.
А позже того провайдера купил крупный, и простои стали длиться по несколько дней.
Размер фирмы ничего не гарантирует, совсем.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Sharowarsheg, Вы писали:

C>>>И ещё, во время того эпичного отказа S3, по всему Амазону несколько тысяч инженеров работали над её решением или смягчением последствий. Если бы аналогичный отказ произошёл бы в полуподвальном ДЦ в ночь на 1-е января, то сколько инженеров работали бы над ней?
S>>У этого есть другая сторона — сколько народу затронул бы отказ полуподвального ДЦ в ночь на первое января?
C>Только этот магазин, которые обслуживался в этом ДЦ. Но надолго — пока железо не заменят и/или админ не протрезвеет.

C>Для сравнения, даже тот сбой S3 длился чуть более 4 часов.

By Julianne Pepitone, staff reporter
April 22, 2011: 7:29 AM ET


NEW YORK (CNNMoney) -- A rare and major outage of Amazon's cloud-based Web service on Thursday took down a plethora of other online sites, including Reddit, HootSuite, Foursquare and Quora.

The outages began Thursday morning just before 5 a.m. ET and were still ongoing more than 24 hours later. In a series of running updates on its Web services "Health Dashboard," Amazon described its efforts to recover from the cascade of problems kicked off by an early-morning "networking event."

http://money.cnn.com/2011/04/21/technology/amazon_server_outage/index.htm


Потери включали в себя вот этих идиотов —

https://forums.aws.amazon.com/thread.jspa?threadID=65649&tstart=0

Sorry, I could not get through in any other way

We are a monitoring company and are monitoring hundreds of cardiac patients at home.
We were unable to see their ECG signals since 21st of April

Здравствуйте, Sharowarsheg, Вы писали:

C>>Для сравнения, даже тот сбой S3 длился чуть более 4 часов.
S>By Julianne Pepitone, staff reporter
S>April 22, 2011: 7:29 AM ET
Это было очень давно ( https://aws.amazon.com/ru/message/65648/ ). С тех пор поменялось примерно всё.

Сейчас падение одной AZ (availability zone) не вызывает никаких проблем с EC2 в других AZ. Это примерно год назад проверили в боевом режиме, когда шторм в Австралии вызвал отключение электричества в одном из ДЦ, полностью обесточив одну AZ в Сиднее.

Здравствуйте, Ops, Вы писали:

C>>И ещё, во время того эпичного отказа S3, по всему Амазону несколько тысяч инженеров работали над её решением или смягчением последствий. Если бы аналогичный отказ произошёл бы в полуподвальном ДЦ в ночь на 1-е января, то сколько инженеров работали бы над ней?
Ops>В начале 0-х у меня друг работал у не самого крупного районного провайдера (7тыс домашних пользователей), так один раз в ночь на 1 января его выдернули, и они вместе с владельцем фирмы лазали на чердак чего-то чинить.
Да, мелкие компании вынуждены бороться за клиента. С другой стороны, у крупной компании, скорее всего, будет отлаженный процесс по исправлению проблем. Или не будет — как повезёт.

Ops>А позже того провайдера купил крупный, и простои стали длиться по несколько дней.
Ops>Размер фирмы ничего не гарантирует, совсем.
Конечно, потому надо смотреть на то, как работает поддержка клиентов.

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

Здравствуйте, Cyberax, Вы писали:

C>>>Для сравнения, даже тот сбой S3 длился чуть более 4 часов.
S>>By Julianne Pepitone, staff reporter
S>>April 22, 2011: 7:29 AM ET
C>Это было очень давно ( https://aws.amazon.com/ru/message/65648/ ). С тех пор поменялось примерно всё.

Amazon AWS открылась в 2006 году, если википедия не врёт.
С 2006 до 2011 прошло пять лет, и потом оно упало.
Можно предположить, что с 2006 до 2011 тоже менялось примерно всё, но тогда это не помогло.
Сейчас 2017 и прошло всего шесть лет с 2011.
Исправлено, следует читать: Сейчас 2018 и прошло всего семь лет с 2011.

Я не вижу, почему можно исключить риск того, что оно опять сутки пролежит.

Здравствуйте, Sharowarsheg, Вы писали:

C>>Это было очень давно ( https://aws.amazon.com/ru/message/65648/ ). С тех пор поменялось примерно всё.
S>Amazon AWS открылась в 2006 году, если википедия не врёт.
S>С 2006 до 2011 прошло пять лет, и потом оно упало.
Серьёзно AWS начал расти как раз в то время. Сейчас он примерно в 15 раз больше, чем в 2011-м по доходу.

Цифры по реальному росту объёма я сказать не могу, но из роста дохода можно примерно понять, что мы говорим о росте даже не в разы, а в десятки раз.

S>Я не вижу, почему можно исключить риск того, что оно опять сутки пролежит.
Риск вообще полностью нельзя исключить. Но сейчас AWS в совершенно другой ситуации, чем в 2011-м.

Здравствуйте, Cyberax, Вы писали:

C>Если уж заговорили о самолётах, то в большинстве гражданских аэропортов нет автономного электропитания. Если навернётся электросеть, то аэропорт останавливается и пассажиры ждут, пока включат ток. Можно было бы воткнуть дизель-генераторы, но это просто не окупается по рискам.

Тем не менее DME, помнится, во время приснопамятного зимнего блекаута вполне себе прожил на дизель-генераторах, хоть и не без проблем.

C>При этом, есть методы обеспечения надёжности в облачных системах — можно запускать сервисы сразу в нескольких облаках (от MS и Azure)

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

Здравствуйте, m2l, Вы писали:


m2l>Другая крайность, вариант на уровне гипервизора, VMWare Fault Tolerance. Там диски виртуальных машин размещаются на общем хранилище (SAN/СХД/другие вариации), а память и состояние процессора с небольшим лагом передаются по сети с работающей копии вм на "теневую", готовую в любой момент времени при выходе основной продолжить работу практически с того же места.


Вот именно про это можно где-то попкорнее почитать?

Здравствуйте, Cyberax, Вы писали:

C>В США для сферической компании в вакууме организация отказоустойчивого сервиса, географически распределённого и с круглосуточной поддержкой, требует около одного миллиона долларов в год. В основном, на зарплату персонала.
Я боюсь, что тут ты сильно не дооцениваешь масштаб бедствия, минимум раза в два.

Здравствуйте, Sharov, Вы писали:

S>Здравствуйте.

S>Вот имеется у нас некий инстанс в облаке. Вот мы с ним работаем, что-то туда пишем и т.д. Потом железо в облаке накрывается.

S>Вопрос: правильно ли я понимаю, что современные технологии могут обеспечить бесперебойную работу сервиса в данном случае?
S>Т.е. тут же поднимется полностью реплицированный инстанс, и пользователь облачного сервиса вообще ничего не заметит. При этом никакие данные не будут потеряны, т.е. полная консистентность.
Что ты подразумеваешь под "писать в инстанс"? В такой постановке задачи, никакое "облако" ничего подобного не обеспечивает.
"Облака" обычно предоставляют некий набор сервисов, каждый из которых работает по разному, но большинство из нихз предоставляют некий SLA и по аптайму, и по надежности хранения данных, достигаемых разными подходами.

S>Если же я прав. То следующий вопрос, каким образом, т.е какими технологиями (железо+софт, хотя больше железо мне думается), это обеспечивается? Т.е. это все обеспечивается на уровне
S>hypervisor'а. Так или не так? Т.е. это будет какой-то raid, но как быть с данными в памяти и состоянием процессора?
Многократное резервирование на разных железяках. Пока данные не сохранятся с заданным уровнем реплик, операция не считается успешной.

Здравствуйте, Sharov, Вы писали:

S>Да, но как эти инстансы находятся в консистентном состоянии между собой? Они по идее геогрфически удалены для повышения отказоустойчивости. Вот у меня сломалась машина в Москве, тут же дали питерский инстанс.
S>И все консистентно на уровне состояния процессора, памяти, кэшей и т.д. Так это работает? Такое вообще возможно?

Вот именно так не работает, потому что это невозможно. Но возможны компромиссы, гугли CAP теорему.

Здравствуйте, itslave, Вы писали:

I>Вот именно так не работает, потому что это невозможно. Но возможны компромиссы, гугли CAP теорему.

Про CAP в курсе, но от тут не при чем. Тут

Автор: Cyberax
Дата: 28.04.18

же Cyberax описывет возможную (или уже конкретную реализацию). Единственное, что меня смущатет это синхронизация времени.
Иначе RDTSC и прочие RDRAND пойдут в разнобой.

Здравствуйте, itslave, Вы писали:

I>Что ты подразумеваешь под "писать в инстанс"? В такой постановке задачи, никакое "облако" ничего подобного не обеспечивает.

Допустим по RDP работаю с вордом в ЕС2. Что-то происходит, инстанс, точнее железно его крутящее, падает. Я вообще ничего не замечаю, все как и было,
продолжаю писать что-то в ворд, и даже не подозреваю, что общаюсь уже с другим инстансом-железом.