Вот имеется у нас некий инстанс в облаке. Вот мы с ним работаем, что-то туда пишем и т.д. Потом железо в облаке накрывается.
Вопрос: правильно ли я понимаю, что современные технологии могут обеспечить бесперебойную работу сервиса в данном случае?
Т.е. тут же поднимется полностью реплицированный инстанс, и пользователь облачного сервиса вообще ничего не заметит. При этом никакие данные не будут потеряны, т.е. полная консистентность.
Если же я прав. То следующий вопрос, каким образом, т.е какими технологиями (железо+софт, хотя больше железо мне думается), это обеспечивается? Т.е. это все обеспечивается на уровне
hypervisor'а. Так или не так? Т.е. это будет какой-то raid, но как быть с данными в памяти и состоянием процессора?
S>Если же я прав. То следующий вопрос, каким образом, т.е какими технологиями (железо+софт, хотя больше железо мне думается), это обеспечивается? Т.е. это все обеспечивается на уровне S>hypervisor'а. Так или не так? Т.е. это будет какой-то raid, но как быть с данными в памяти и состоянием процессора?
Из коробки этого не умеет ни один гипервизор (если не касаться виртуализации в виде аппаратных доменов, которые имеются на машинах класса майнфреймов или SMP монстров на спарках). Но существует кучи опенсорсных софтварных систем для обеспечения отказустойчивости и мониторинга сервисов, накопителей и пр. всего. Админы облачных хостингов городят из (кучи дерьма и палок) всего этого инфраструктуру, обеспечивающую весь функционал.
Re: Базовый вопрос по hypervisor и high availability
Насколько я понимаю, high availability обеспечивается кучей одинаковых инстансов, а не бессмертным инстансом. А миграция проводится в запланированном русле, чтобы выключить потом сервер, а не автоматом.
Re[2]: Базовый вопрос по hypervisor и high availability
S>Из коробки этого не умеет ни один гипервизор (если не касаться виртуализации в виде аппаратных доменов, которые имеются на машинах класса майнфреймов или SMP монстров на спарках). Но существует кучи опенсорсных софтварных систем для обеспечения отказустойчивости и мониторинга сервисов, накопителей и пр. всего. Админы облачных хостингов городят из (кучи дерьма и палок) всего этого инфраструктуру, обеспечивающую весь функционал.
А где можно почитать про проблезительную реализацию, например у aws? А то поиск по ключевым словам ничего интересного не дал. Мож там годами выработана терминология специфическая.
Кодом людям нужно помогать!
Re[2]: Базовый вопрос по hypervisor и high availability
Здравствуйте, vsb, Вы писали:
vsb>Насколько я понимаю, high availability обеспечивается кучей одинаковых инстансов, а не бессмертным инстансом.
Да, но как эти инстансы находятся в консистентном состоянии между собой? Они по идее геогрфически удалены для повышения отказоустойчивости. Вот у меня сломалась машина в Москве, тут же дали питерский инстанс.
И все консистентно на уровне состояния процессора, памяти, кэшей и т.д. Так это работает? Такое вообще возможно?
vsb>А миграция проводится в запланированном русле, чтобы выключить потом сервер, а не автоматом.
Я не про миграцию, а про железное падение, и как это все незаметно для пользователя.
Кодом людям нужно помогать!
Re[3]: Базовый вопрос по hypervisor и high availability
Здравствуйте, Sharov, Вы писали:
vsb>>Насколько я понимаю, high availability обеспечивается кучей одинаковых инстансов, а не бессмертным инстансом.
S>Да, но как эти инстансы находятся в консистентном состоянии между собой? Они по идее геогрфически удалены для повышения отказоустойчивости. Вот у меня сломалась машина в Москве, тут же дали питерский инстанс. S>И все консистентно на уровне состояния процессора, памяти, кэшей и т.д. Так это работает? Такое вообще возможно?
Могу рассказать, как это устроено у IBM MQ (Очередь сообщений). Думаю, у остальных реализовано более-менее похоже.
Можно запустить несколько инстансов Очереди. Активным (обслуживать запросы) будет только один, остальные висят на локе (ждут файловый хендл). Все файлы, используемые в работе, лежат в расшаренном каталоге. Если активный инстанс умирает, лок освобождается и его захватывает один из ждущих инстансов.
Все инстансы могут быть запущены на разных машинах, главное, чтобы был доступ к расшаренному каталогу.
Если фреймворк хранит все данные на диске, сразу их сбрасывает и долго не держит незаписанное в памяти, то тогда новый инстанс сможет всё поднять и продолжить работу без потерь. Вряд ли там заморачиваются состоянием процессора и памяти.
Ну а от сбоя диска может защитить рейд.
_____________________
С уважением,
Stanislav V. Zudin
Re[3]: Базовый вопрос по hypervisor и high availability
Здравствуйте, Sharov, Вы писали:
S>Да, но как эти инстансы находятся в консистентном состоянии между собой?
Используя распределённые архитектуры. Например распределённую БД.
S>И все консистентно на уровне состояния процессора, памяти, кэшей и т.д. Так это работает? Такое вообще возможно?
Консистентность достигается на уровне логики приложения. Да и то не всегда. Т.е. ты залил фотку вконтакте на один сервер, он тут же сломался, но фотка уже успела реплицироваться на другие серверы и на следующей загрузке страницы ты её видишь как будто ничего не случилось. На уровне процессора я про такое не слышал, распределённость требует существенных усилий со стороны программиста, на халяву тут ничего не будет.
В мейнфреймах есть подобные системы, но не распределённые, т.е. сломавшийся процессор заменяется на другой на лету, сломавшаяся планка памяти заменяется на другую и тд, для выполняющегося приложения это действительно не заметно. Но денег такие мейнфреймы стоят огромных и распространённости не получили.
Здравствуйте, vsb, Вы писали:
vsb>Консистентность достигается на уровне логики приложения. Да и то не всегда. Т.е. ты залил фотку вконтакте на один сервер, он тут же сломался, но фотка уже успела реплицироваться на другие серверы и на следующей загрузке страницы ты её видишь как будто ничего не случилось. На уровне процессора я про такое не слышал, распределённость требует существенных усилий со стороны программиста, на халяву тут ничего не будет.
Про уровень приложения понятно. БД, event consist. и т.д. Я имел ввиду такую ситуацию -- вот работаю я через RDP с ОС, запустил документ, редактирую (ну вот захоетлось это в облаке сделать). В какой-то момент желозо ломается,
мне выдают новое, а я вообще ничего не замечаю. Как набирал себе текст в word'е так и набираю. Такое в облаках возможно?
vsb>В мейнфреймах есть подобные системы, но не распределённые, т.е. сломавшийся процессор заменяется на другой на лету, сломавшаяся планка памяти заменяется на другую и тд, для выполняющегося приложения это действительно не заметно. Но денег такие мейнфреймы стоят огромных и распространённости не получили.
Что-то типа того, да. Но это явно не облачный случай. Т.е. географически распределенная консистентность на уровне сост. процессора, кэшей и памяти пока не доступна. Ну т.е. доступна, но, вероятно, крайне дорога.
Кодом людям нужно помогать!
Re[5]: Базовый вопрос по hypervisor и high availability
Здравствуйте, Sharov, Вы писали:
vsb>>В мейнфреймах есть подобные системы, но не распределённые, т.е. сломавшийся процессор заменяется на другой на лету, сломавшаяся планка памяти заменяется на другую и тд, для выполняющегося приложения это действительно не заметно. Но денег такие мейнфреймы стоят огромных и распространённости не получили.
S>Что-то типа того, да. Но это явно не облачный случай. Т.е. географически распределенная консистентность на уровне сост. процессора, кэшей и памяти пока не доступна. Ну т.е. доступна, но, вероятно, крайне дорога.
Я про такое никогда не слышал, может кто что напишет, интересно будет почитать. Но сомневаюсь, что это вообще возможно (на практически интересной скорости). Разница в скорости памяти и скорости сети составляет много порядков. Разница в латентности кеша и латентности сети тоже составляет много порядков. Как тут такое реплицировать.
Re[5]: Базовый вопрос по hypervisor и high availability
Здравствуйте, Sharov, Вы писали:
S>Про уровень приложения понятно. БД, event consist. и т.д. Я имел ввиду такую ситуацию -- вот работаю я через RDP с ОС, запустил документ, редактирую (ну вот захоетлось это в облаке сделать). В какой-то момент желозо ломается, S>мне выдают новое, а я вообще ничего не замечаю. Как набирал себе текст в word'е так и набираю. Такое в облаках возможно?
Практически нет.
S> географически распределенная консистентность на уровне сост. процессора, кэшей и памяти пока не доступна. Ну т.е. доступна, но, вероятно, крайне дорога.
Скорее, крайне медленна и быстрой не делается ни за какие деньги.
Re[5]: Базовый вопрос по hypervisor и high availability
Здравствуйте, Sharov, Вы писали:
S>Про уровень приложения понятно. БД, event consist. и т.д. Я имел ввиду такую ситуацию -- вот работаю я через RDP с ОС, запустил документ, редактирую (ну вот захоетлось это в облаке сделать). В какой-то момент желозо ломается, S>мне выдают новое, а я вообще ничего не замечаю. Как набирал себе текст в word'е так и набираю. Такое в облаках возможно?
Это в обычном ESXi возможно, но заминка в несколько секунд всё же будет.
Re[6]: Базовый вопрос по hypervisor и high availability
Здравствуйте, Sharowarsheg, Вы писали:
S>> географически распределенная консистентность на уровне сост. процессора, кэшей и памяти пока не доступна. Ну т.е. доступна, но, вероятно, крайне дорога.
S>Скорее, крайне медленна и быстрой не делается ни за какие деньги.
IBM geographically dispersed parallel sysplex есть. С непрерывной репликацией на какие-то сотни километров.
Re[7]: Базовый вопрос по hypervisor и high availability
Здравствуйте, Слава, Вы писали:
С>Здравствуйте, Sharowarsheg, Вы писали:
S>>> географически распределенная консистентность на уровне сост. процессора, кэшей и памяти пока не доступна. Ну т.е. доступна, но, вероятно, крайне дорога.
S>>Скорее, крайне медленна и быстрой не делается ни за какие деньги.
С>IBM geographically dispersed parallel sysplex есть. С непрерывной репликацией на какие-то сотни километров.
Я прочитал википедию про это, и там в основном упоминается storage replication. Оно точно умеет параллельную оперативную память? Я просто плохо себе представляю, как можно синхронизировать оперативную память на сколько-нибудь заметное расстояние с пингом порядка наносекунд.
Re[2]: Базовый вопрос по hypervisor и high availability
Здравствуйте, Sharov, Вы писали:
S>Ау. Чего все молчат -- вопрос не правильно сфорумулирован? S>На всякий случай реквестирую в тред СпанчекряксаCyberax'а . Уж он то точно что-нибудь да ответит.
Гипервизоры сами по себе не добавляют отказоустойчивости. Обычно.
Есть несколько проектов, которые позволяют двум физическим узлам работать параллельно. В гостевых системах на них полностью устранены источники случайности, а сетевой трафик дублируется. Так что если один физический узел отваливается, то другой может перехватить управление мгновенно.
Но таких технологий сейчас (по крайней мере примерно до конца этого года ) в публичных облаках нет ни у кого.
Следующий уровень — это миграция гостевых систем на лету. Это делается на узлах семейства T2 (а так же скоро C5 и M5) в Амазоне. Если самодиагностика железа указывает на возможные проблемы, то гостевые системы будут прозрачно реплицированы на другой физический узел. При этом полностью переносится память, состояние дисков и настройки сети. Так что пользователи увидят только небольшую задержку порядка 50 миллисекунд, когда происходит финальная передача управления.
Но это всё не поможет от ошибок в самой ОС. Так что более правильно — это проектировать приложение для распределённой работы. Самое простое — это сделать вычислительные узлы полностью stateless, чтобы можно было при желании просто запустить их заново. При этом проще всего использовать сервисы типа RDS, DynamoDB и CloudWatch Logs для хранения данных.
Географическая распределённость — это вообще отдельный разговор. Скорость света делает все "прозрачные" решения полностью бесполезными.
Sapienti sat!
Re[7]: Базовый вопрос по hypervisor и high availability
S>>Скорее, крайне медленна и быстрой не делается ни за какие деньги.
С>IBM geographically dispersed parallel sysplex есть. С непрерывной репликацией на какие-то сотни километров.
на МФ parallel sysplex желеязячка в памяти которой храниться например список блокировок db2, все узлы db2 постоянно лезут туда по специфической оптической сетке, если нужно выяснить заблокирована ли запись. не самое стройное решение мягко говоря и требует специфического канала связи со всеми узлами (что-то типа FC).
Gt_
Re[3]: Базовый вопрос по hypervisor и high availability
Здравствуйте, Cyberax, Вы писали:
C>Есть несколько проектов, которые позволяют двум физическим узлам работать параллельно. В гостевых системах на них полностью устранены источники случайности, а сетевой трафик дублируется. Так что если один физический узел отваливается, то другой может перехватить управление мгновенно.
Про что-то подобное я как раз и читал в крайне древней работе "hypervisor-based fault-tolerance" (pdf можно нагуглить). Но там процессоры сидели на одной scsi шине. И то там были пляски с
IO прерываниями. Поэтому я не понял, как можно устранить источник случайности?
C>Но таких технологий сейчас (по крайней мере примерно до конца этого года ) в публичных облаках нет ни у кого.
У aws чего-то планируется, если не секрет?
C>Если самодиагностика железа указывает на возможные проблемы, то гостевые системы будут прозрачно реплицированы на другой физический узел. При этом полностью переносится память, состояние дисков и настройки сети. Так что пользователи увидят только небольшую задержку порядка 50 миллисекунд, когда происходит финальная передача управления.
А как же быть с выполняющимися процессами и сост. процессора? Правильно ли я понимаю,что у нас фактически будет устаревший (возможно на несколько мс) снапшот системы?
C>Географическая распределённость — это вообще отдельный разговор. Скорость света делает все "прозрачные" решения полностью бесполезными.
Имеются ввиду сопутствующие релятивистские() эффекты или что?
Кодом людям нужно помогать!
Re[4]: Базовый вопрос по hypervisor и high availability
Здравствуйте, 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
Здравствуйте, Слава, Вы писали:
S>>Скорее, крайне медленна и быстрой не делается ни за какие деньги. С>IBM geographically dispersed parallel sysplex есть. С непрерывной репликацией на какие-то сотни километров.
Все производители, которые уверяют, что делают прозрачную работу в географически распределённых БД, нагло врут.
Sapienti sat!
Re[8]: Базовый вопрос по hypervisor и high availability
Здравствуйте, Cyberax, Вы писали:
С>>IBM geographically dispersed parallel sysplex есть. С непрерывной репликацией на какие-то сотни километров. C>Все производители, которые уверяют, что делают прозрачную работу в географически распределённых БД, нагло врут.
За софт — деньги. За железо — деньги. За деньги — надёжность. За платный софт — хорошую зарплату и надёжную работу для инженеров, с 9 до 17. А энергичных стартаперов с гномиками и без выходных, даже отожранных без меры — в топку, всех этих гуглов с их айтишной субкультурой, пригодной для эластичного показа котиков в бесконечной ленте.