Microsoft: частное облако

[fed]

Меня тоже пугает уровень дискуссии. Просто те ссылочки,с которых mazzy дискуссию начал, это такой абстрактный программный документ (типа манифеста коммунистической партии), в котором 60% - маркетинг, а 40% - вода. И последующая дискуссия напоминает мне спор пионеров в пионерском лагере 70ых, которых хитрые воспитатели спровоцировали пообсуждать - как же они будут жить при коммунизме.
Меня же интересуют те технологии, которые МОГУТ скрываться за этим манифестом применительно к Аксапте. Возможно - часть всего этого - мои домыслы, но поскольку пока ничего конкретного за этим манифестом не стоит, ничего лучшего я предложить не могу...

1. Виртуализация с автоматической миграцией виртуалки между железками. Уже существует. Возможно - полезна в каких то случаях. Но как тут выше утверждали, это то ли ненастоящее, то ли неполноценное облако, то ли какой-то вырожденный вариант. (Не буду комментировать - бесполезно сравнивать версии коммунизма).
2. Автоматическое распараллеливание задач. На мой взгляд - задача в общем случае не решаема. В лучшем случае, вместо нынешней кривоватой инфраструктуры параллельного исполнения на базе батч-сервера, можно сделать какой-то культурный визуальный редактор, который декларативно описывает как выполняемые классы рассчета зависят друг от друга. По хорошему - штука полезная, но к 'облаку' отношения мало имеющая.
3. Миграция процесса. Представим себе что среда исполнения может при нехватке ресурсов мигрировать процесс на другой сервер. То есть - операционка посылает AOSу сигнал - сохранить состояние. AOS каким-то образом сохраняет состояние. Потом операционка убивает AOS на одном компе (или виртуалке), запускает новый AOS на другом компе (или виртуалке), восстанавливает состояние и продолжает исполнение. Во первых - в первую очередь миграцию должен будет поддерживать SQL и его клиент. Если они не реализуют поддержку при которой соединение к БД можно будет закрыть на одном IP и потом восстановить на другом - ничего не получиться. Кроме того, чтобы мигрировать процесс, надо как-то мигрировать все внешние ресурсы задействованные этим процессом - открытые файлы, DLL-ки, ActiveX-ы, внешние ODBC-соединения и тому подобное. Не думаю что их легко будет переписать на новые механизмы (все-таки дофига унаследованного софта). Наконец- поскольку в реальности, это не будет очень отличаться от миграции VM, поскольку при схеме "Каждому серверному софту по своей VM", ресурсы уходящие на VM будут лишь чуть больше чем ресурсы уходящие на один процесс. Так что я думаю, этот вариант нежизнеспособен.
4. Миграция пользовательского потока. Такая же схема, только мигрируется не весь AOS, а одно пользовательское соединение. То есть - операционка посылает AOS сигнал - освободить столько то ресурсов, AOS выбирает несколько пользовательских соединений и сохраняет их состояния. Потом другой AOS открывает несколько новых пользовательских соединений, восстанавливает их состояние и кидает клиентам (на других компьютерах) команду в дальнейшем работать с другим AOS-ом. Проблемы с миграцией SQL-соединений остаются. (Но я надеюсь что Микрософт как-то решит эту проблему в новых версиях сиквела. Или уже решил в Azure). Проблемы с внешними ресурсами снимаются - поскольку в данный момент времени, далеко не все пользовательские соединения работают с внешними файлами или ActiveX-ами. В целом схема выглядит вполне жизнеспособной и реализуемой.

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