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

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

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

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

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

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

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

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

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

C>И ещё, во время того эпичного отказа 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

Здравствуйте, 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-..-..". Т.е., буть бобр, сделай что нибудь (сам). Так выглядят чудеса на "гражданском" уровне.

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

Здравствуйте, 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 пойдут в разнобой.