эффективно копировать объекты между различными виртуальными машинами

Question

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

У меня есть 2 виртуальные машины.

Я хотел бы скопировать экземпляр объекта из одного в другой,

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

В настоящее время для того, чтобы сделать такую ​​вещь, мы сериализуем объект и десериализуем его, что гораздо менее эффективно (с точки зрения вычислений), чем просто копировать экземпляр как есть ... синтаксический анализ - вычислительная трата ... *

Пример сериализации JS: каждая виртуальная машина является экземпляром V8 (JavaScript), Один из способов сделать это - преобразовать объект в JSON (JSON.stringify), отправить его как-нибудь другой виртуальной машине, которая получает строку и преобразовать ее обратно в объект (например, var myObject = eval('(' + myJSONtext + ')');) .. (JavaScript является лишь примером вот это какая-то сериализация)

Answer 1

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

Вот несколько причин, почему это не сделано:

1. Представление в ядре, как правило, не переносимо между архитектурами.Если бы я отправлял «объект» с ВМ на машине SPARC на ВМ на компьютере с архитектурой x86, не зная его структуры, объект был бы поврежден с другой стороны.

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

3. Объект, вероятно, содержит ссылки на другие объекты, поэтому копирование объекта означает копирование дерева объектов и, как правило, не ациклического дерева.Вы в конечном итоге создаете код, который очень похож на библиотеку сериализации, чтобы сделать это надежно.

4. Объекты часто держатся за собственные ресурсы (такие как дескрипторы файлов и сокеты), которые могут 'надежно передаваться между компьютерами.

5. Во многих виртуальных машинах существует различие между данными (объект, который вы пытаетесь скопировать) и метаданными (например, классомобъект, который вы пытаетесь скопировать).В таких виртуальных машинах, даже если вы можете копировать объект за битом в целости и сохранности, это может зависеть от набора метаданных, которых нет на удаленном конце.Копирование метаданных побитно также сложно, так как многие виртуальные машины используют методы реализации (такие как глобальный пул встроенных строк или объектный код с отображением в памяти), которые делают данные по своей природе непереносимыми.Вы также можете получить гораздо больше метаданных, чем вам нужно (например, в .net самая маленькая единица метаданных, которую вы можете упаковать и отправить куда-либо, обычно является сборкой).

6. In-представление ядра, как правило, не переносимо между различными версиями одной и той же виртуальной машины и не содержит внутренней информации о версии, которая может использоваться для исправления данных.

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

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

Таким образом, эти механизмы, как правило, не существуют.

Существует одно огромное исключение из этого правила: виртуальные машины на основе образов (например, множество виртуальных машин smalltalk и self) построены на идее о том, что состояние виртуальной машины существует в «образе», который можно копировать, перемещать между машинами и т. Д.как правило, имеет значительные эксплуатационные расходы.

Answer 2

Почему бы не использовать cpickle.Он будет сериализовать данные очень надежно и очень быстро, после чего вы сможете отправить его через сокет с именем pipe, mmap, назовите его, за исключением того, что на другом конце вы можете надежно собрать его, если он не был поврежден при передачеи версии модуля рассола не сильно отличаются.Конечно, по-настоящему корпоративный способ - это использовать независимый от платформы стандарт, такой как XML, который позволит вам расширить функциональную совместимость платформы за пределы python.Я знаю, что это обходит вопрос, но я думаю, что кто-то, кто внес вклад в базу кода интерпретатора Python, должен был бы уточнить это для вас.

Answer 3

Я уверен, что такого способа прямой передачи памяти в API-интерфейсах VMware нет;Я не знаю о других гипервизорах, но я все еще сомневаюсь в этом.У VMware есть способы пересылки памяти всей машины на другой хост-сервер (в основном с помощью файла подкачки), но ничего, что могло бы извлечь только часть памяти из работающей программы и передать ее другой - слишком много нужнотам.

Таким образом, ваша существующая тактика сериализации объектов, безусловно, является хорошим и распространенным решением для этой потребности, и, к счастью, у языков программирования, с которыми вы работаете, есть хорошие варианты ( Python , Java ).

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