Поиск технологического решения для оптимизации процесса массового производства embedded-системы?
Здравствуйте.
Имеется програмная система состоящая из:
1. VMWare ESXi 4.1
2. Двух виртуальных машин, которые собственно будут бежать под руководством вышеупомянутого гипервизора.
Вся эта радость работает на embedded-карте, у которой из интерфейсов в наличие только USB и сериальный порт. Embedded-карта имеет также процессор, память и 500 ГБ диск.
Задача следующая:
Мне необходимо найти технологическое решение для оптимизации процесса массового производства, посредством максимально быстрой репликации всей вышописанной системы вместе взятой, т.е. какое-то чудо-чудное, которое позволило бы завернуть всё вместе [ESXi + 2 вирт. машины] в один контейнер, наподобие Norton Ghost, и затем за считанные секунды/минуты разворачивать на стандартном железе. Или некая система, позволяющая делать тоже замое с мастер-диска.
На сегодняшниий день, в качестве временного решения я написал некую unattended инсталяционную процедуру, которая приводится в действие автозапуском в момент подключения к USB флеш-диска, поднимает в памяти live-дистрибутив Линукса и в нём запускает процедуру установки сначала ESXi, затем уже переносит в нужное место виртуальные машины и добавляет их в inventory. Вся, только что описанная кухня работает, но для массового производства категорически не годится по причине недопустимых временных затрат. Другими словами, если бы нужно было таким образом установить несколько, к примеру 3-4-5 машин, то ещё куда не шло. Однако, в случае заказа на 100 или 200 единиц, можно смело гасить свет и идти домой.
В наличие также имеется аппаратная платформа для репликации дисков, однако она не знакома с проприетарной файловой системой VMWare, поэтому она в режиме по-умолчанию начинает копировать 500 гигобайтный диск поблочно, безотносительно к занятому дисковому пространству, что, ясное дело, ужасно неэффективно.
Заранее спасибо за возможные варианты решения проблемы.
Спасибо за ответ. Я знаком с этим програмным продуктом. К сожалению, его функциональности не достаточно для решения моей задачи. Он умеет создавать резервные копии и восстанавливать только сами вирт. машины, но не гипервизор.
А что мешает взять отдельную машину, на которую поставить управляющую часть вышеописанного продукта. Те при восстановлении работать не с сущностью гипервизор, а с сущность машина с массивом памяти?
Буквально только что потерял трое суток выходных из-за того что акронис ничего не предлагает сделать с поврежденным бакапом (по крайней мере это единственное объяснение, почему при попытке открыть бакап раздела акронис пишет файл не найден), а еще новые версии не могут работать архивами от старых… в общем грусть печаль и большой минус этой системе резервного копирования.
Хорошо что я параноик, у меня было три копии, разными средствами (просто важные файлы в архиве + ntbackup + acronis), плохо что это не позволило мне восстановить загрузочный раздел (не помогло даже установить чистую windows и поверх развернуть бакап, очень win7 этому препятствовало)
Эта штука, которая Acronis Backup & Recovery, умеет взять виртуальные машины, которые в свою очередь бегут в среде гипервизора, и применяя всякие политики, положить их куда-то на резервный накопитель. Она не умеет разворачивать гипервизор на голом железе. Она вообще не умеет работать с железом.
мы строили системы на abr, которая состояла из нескольких машин, одна из которых загружалась по сети через pxe, после разворачивался acronis media, который брал эталонные образы жестких дисков(с другого сервера) и писал их на необходимую машину.
после, машина на которую все это писалось, перезагружалась и мы получали полностью установленную машину из бэкапов.
управляющая машина посылает сигнал перезагрузки на которой необходимо осуществить рестор. В настройках машины для рестора стоили настройки, чтобы она закгружалась по сети с pxe сервера(отдельная машина для хранения эталонных образов, pxe образов). После загрузки pxe образа монтировался диск с акронис rescue media(отдельным батником). Далее выполнялись несколько батников, которые собственно монтировали бэкапы из отдельных хранилищ и инициировали процесс рестора. После, как рестор заканчивался машина перезагружалась. Процесс заканчивался.
Для того чтобы система опять не начала деплоить бэкап, мы выполняли в конце батник, который посылал на упраляющую машину сигнал, что рестор завершился и после этого широковещательный запрос просто не доходил до сервера эталонных образов. Поэтому запускалась система.
Попробуйте развить идею посекторного копирования диска, необходимо ведь исключить копирование пустых данных (ведь не все 500гб у вас используются?).
Вам написать утилиту… кода строк на 50-100, которая проанализирует копируемый раздел, выявит последовательные пустые сектора и при развертывании их просто не станет копировать? Конечно есть опасность попасть на нули в полезных данных… но этот момент отметается дополнительным анализом уже изнутри виртуального образа.
p.s. а еще можно попытаться реализовать алгоритм:
1. Изменить размер контейнера с исходными данными до минимального (за счет свободного места, почти все современные файловые системы обрабатывает утилита gparted/qparted)
2. Копирование уменьшенного контейнера при развертывании с последующим расширением до 500гб
Спасибо за советы.
Для того, чтобы исключить «копирование пустых данных» данных, нужно понимать как устроена конкретная файловая систем, что несколько затруднительно в случае с закрытой проприетарной технологией.
Написать утилиту не проблема, загвозка в том, что нечего анализировать, т.к. нет раздело :) Грубо говоря, есть железо (диск), на который нужно с максимальной скоростью забросить master-image.
Контейнеры виртуальных машин уже оптимизированны до минимального размера. Мажете ли подсказать какое-то решение для глобального контейнра, в который будут завёрнуты и гипервизор и ВМы?
Дано — тестовый контейнер или целый диск (500Гб)
1. Заполняем тестовый контейнер нулями (лучше СВОИМ блоком случайных данных, вероятность встретить которого в устанавливаемом образе минимальная)
2. Затем разворачиваем на этом контейнере систему штатным способом
3. Анализируем контейнер на изменения (просто посекторно сканируем на наличие своих блоков, сохраняя в своем файле измененные блоки (формат любой, например два файла — один блоки данных, другой — индекс вида [интервал->смещение в первом файле+размер,..] или если блок сделать большим, например в 1Мб, то [индекс блока ->смещение,..]).
4. Полученную информацию можно использовать для того чтобы быстро развернуть копию, записывая только измененные данные.
Данный механизм хоть и универсальный (работает с любыми проприетарными форматами, ему на них пофиг), но имеет смысл использовать только для случаев, когда целевое железо — одинаковое (типовое) и в принципе позволяет развертывание путем клонирования (как вы сказали у вас этот вариант подходит, просто грубое копирование — очень медленное).
Простой
Простой
Средний
