Базовый вопрос по hypervisor и high availability
От: Sharov Россия  
Дата: 26.04.18 11:11
Оценка:
Здравствуйте.

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

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

Если же я прав. То следующий вопрос, каким образом, т.е какими технологиями (железо+софт, хотя больше железо мне думается), это обеспечивается? Т.е. это все обеспечивается на уровне
hypervisor'а. Так или не так? Т.е. это будет какой-то raid, но как быть с данными в памяти и состоянием процессора?
Кодом людям нужно помогать!
Отредактировано 27.04.2018 9:49 Sharov . Предыдущая версия .
Re: Базовый вопрос по hypervisor и high availability
От: Sharov Россия  
Дата: 27.04.18 09:51
Оценка:
Ау. Чего все молчат -- вопрос не правильно сфорумулирован?

На всякий случай реквестирую в тред СпанчекряксаCyberax'а . Уж он то точно что-нибудь да ответит.
Кодом людям нужно помогать!
Re: Базовый вопрос по hypervisor и high availability
От: smeeld  
Дата: 27.04.18 10:23
Оценка: 4 (1)
Здравствуйте, Sharov, Вы писали:


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

S>hypervisor'а. Так или не так? Т.е. это будет какой-то raid, но как быть с данными в памяти и состоянием процессора?

Из коробки этого не умеет ни один гипервизор (если не касаться виртуализации в виде аппаратных доменов, которые имеются на машинах класса майнфреймов или SMP монстров на спарках). Но существует кучи опенсорсных софтварных систем для обеспечения отказустойчивости и мониторинга сервисов, накопителей и пр. всего. Админы облачных хостингов городят из (кучи дерьма и палок) всего этого инфраструктуру, обеспечивающую весь функционал.
Re: Базовый вопрос по hypervisor и high availability
От: vsb Казахстан  
Дата: 27.04.18 10:25
Оценка: 4 (1) +1
Насколько я понимаю, high availability обеспечивается кучей одинаковых инстансов, а не бессмертным инстансом. А миграция проводится в запланированном русле, чтобы выключить потом сервер, а не автоматом.
Re[2]: Базовый вопрос по hypervisor и high availability
От: Sharov Россия  
Дата: 27.04.18 10:47
Оценка:
Здравствуйте, smeeld, Вы писали:


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


А где можно почитать про проблезительную реализацию, например у aws? А то поиск по ключевым словам ничего интересного не дал. Мож там годами выработана терминология специфическая.
Кодом людям нужно помогать!
Re[2]: Базовый вопрос по hypervisor и high availability
От: Sharov Россия  
Дата: 27.04.18 10:51
Оценка:
Здравствуйте, vsb, Вы писали:

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


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

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


Я не про миграцию, а про железное падение, и как это все незаметно для пользователя.
Кодом людям нужно помогать!
Re[3]: Базовый вопрос по hypervisor и high availability
От: Stanislav V. Zudin Россия  
Дата: 27.04.18 11:12
Оценка:
Здравствуйте, Sharov, Вы писали:

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


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

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

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

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

Если фреймворк хранит все данные на диске, сразу их сбрасывает и долго не держит незаписанное в памяти, то тогда новый инстанс сможет всё поднять и продолжить работу без потерь. Вряд ли там заморачиваются состоянием процессора и памяти.
Ну а от сбоя диска может защитить рейд.
_____________________
С уважением,
Stanislav V. Zudin
Re[3]: Базовый вопрос по hypervisor и high availability
От: vsb Казахстан  
Дата: 27.04.18 11:29
Оценка: 8 (1) +1
Здравствуйте, Sharov, Вы писали:

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


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

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


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

В мейнфреймах есть подобные системы, но не распределённые, т.е. сломавшийся процессор заменяется на другой на лету, сломавшаяся планка памяти заменяется на другую и тд, для выполняющегося приложения это действительно не заметно. Но денег такие мейнфреймы стоят огромных и распространённости не получили.
Отредактировано 27.04.2018 11:30 vsb . Предыдущая версия .
Re[4]: Базовый вопрос по hypervisor и high availability
От: Sharov Россия  
Дата: 27.04.18 11:41
Оценка:
Здравствуйте, vsb, Вы писали:

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


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

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


Что-то типа того, да. Но это явно не облачный случай. Т.е. географически распределенная консистентность на уровне сост. процессора, кэшей и памяти пока не доступна. Ну т.е. доступна, но, вероятно, крайне дорога.
Кодом людям нужно помогать!
Re[5]: Базовый вопрос по hypervisor и high availability
От: vsb Казахстан  
Дата: 27.04.18 12:09
Оценка:
Здравствуйте, Sharov, Вы писали:

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


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


Я про такое никогда не слышал, может кто что напишет, интересно будет почитать. Но сомневаюсь, что это вообще возможно (на практически интересной скорости). Разница в скорости памяти и скорости сети составляет много порядков. Разница в латентности кеша и латентности сети тоже составляет много порядков. Как тут такое реплицировать.
Re[5]: Базовый вопрос по hypervisor и high availability
От: Sharowarsheg  
Дата: 27.04.18 20:46
Оценка:
Здравствуйте, Sharov, Вы писали:

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

S>мне выдают новое, а я вообще ничего не замечаю. Как набирал себе текст в word'е так и набираю. Такое в облаках возможно?

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

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


Скорее, крайне медленна и быстрой не делается ни за какие деньги.
Re[5]: Базовый вопрос по hypervisor и high availability
От: Слава  
Дата: 27.04.18 21:42
Оценка: 10 (1)
Здравствуйте, Sharov, Вы писали:

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

S>мне выдают новое, а я вообще ничего не замечаю. Как набирал себе текст в word'е так и набираю. Такое в облаках возможно?

Это в обычном ESXi возможно, но заминка в несколько секунд всё же будет.
Re[6]: Базовый вопрос по hypervisor и high availability
От: Слава  
Дата: 27.04.18 21:44
Оценка: 7 (2)
Здравствуйте, Sharowarsheg, Вы писали:

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


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


IBM geographically dispersed parallel sysplex есть. С непрерывной репликацией на какие-то сотни километров.
Re[7]: Базовый вопрос по hypervisor и high availability
От: Sharowarsheg  
Дата: 27.04.18 23:00
Оценка:
Здравствуйте, Слава, Вы писали:

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


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


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


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


Я прочитал википедию про это, и там в основном упоминается storage replication. Оно точно умеет параллельную оперативную память? Я просто плохо себе представляю, как можно синхронизировать оперативную память на сколько-нибудь заметное расстояние с пингом порядка наносекунд.
Re[2]: Базовый вопрос по hypervisor и high availability
От: Cyberax Марс  
Дата: 28.04.18 06:46
Оценка: 10 (1)
Здравствуйте, Sharov, Вы писали:

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

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

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

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

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

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

Географическая распределённость — это вообще отдельный разговор. Скорость света делает все "прозрачные" решения полностью бесполезными.
Sapienti sat!
Re[7]: Базовый вопрос по hypervisor и high availability
От: Gt_  
Дата: 28.04.18 08:41
Оценка:
S>>Скорее, крайне медленна и быстрой не делается ни за какие деньги.

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


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

Gt_
Re[3]: Базовый вопрос по hypervisor и high availability
От: Sharov Россия  
Дата: 28.04.18 10:57
Оценка:
Здравствуйте, Cyberax, Вы писали:

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


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


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


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

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


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

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


Имеются ввиду сопутствующие релятивистские() эффекты или что?
Кодом людям нужно помогать!
Re[4]: Базовый вопрос по hypervisor и high availability
От: Cyberax Марс  
Дата: 28.04.18 11:16
Оценка: 30 (2)
Здравствуйте, 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 больше.
Sapienti sat!
Re[7]: Базовый вопрос по hypervisor и high availability
От: Cyberax Марс  
Дата: 28.04.18 21:38
Оценка: +1
Здравствуйте, Слава, Вы писали:

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

С>IBM geographically dispersed parallel sysplex есть. С непрерывной репликацией на какие-то сотни километров.
Все производители, которые уверяют, что делают прозрачную работу в географически распределённых БД, нагло врут.
Sapienti sat!
Re[8]: Базовый вопрос по hypervisor и high availability
От: Слава  
Дата: 29.04.18 14:45
Оценка:
Здравствуйте, 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. А энергичных стартаперов с гномиками и без выходных, даже отожранных без меры — в топку, всех этих гуглов с их айтишной субкультурой, пригодной для эластичного показа котиков в бесконечной ленте.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.