LINUX.ORG.RU

Идеи по «интересному» backUP-у

 ,


0

1

Доброго времени суток. Занимаюсь Linux не так давно, организация рано или поздно (государственный сектор) перейдет на открытый код. Суть вопроса, имеем некие виртуальные машины которые крутятся на старых Гипервизорах, требуются за минимальные простои по времени, перенести полный клон машины. Количество информации «море» примерно от 1 до 2 миллионов файлов, занимает пространства примерно нескольких терабайтов, нужно попытаться правдами и неправдами (несколькими потоками к примеру dd (смещение по блоками), восстановить полную реплику виртуальной машины)…? Каковы ваши идеи по данному поводу?!

P.s. По поводу нескольких потоков (смещением по блокам) это моя больная фантазия… ;(


Если копировать поблочно dd, то какая к Бене разница сколько там миллионов-триллионов файлов? Копируй онланй как есть, потом останавливай виртуалки и докопируй дельту (то что изменилось за время копировния), запускай виртуалку на новом месте

futurama ★★★★★
()

это моя больная фантазия

Да. Узкое место будет или в дисках или в сети, потоки не помогут

futurama ★★★★★
()
Ответ на: комментарий от futurama

Прошу прощения, я все таки заострю внимание коллег со знаниями и попрошу более понятно выражаться (повторюсь я новичок)… Онлайн не получится, потому как «грифность» разная, т.е. сделав образ (реплику) на одном, мне надо восстановить локально за короткий срок на другом гипервизоре! Что такое дельта?

agosha
() автор топика
Ответ на: комментарий от agosha

Что такое дельта?

Четвертая буква греческого алфавита

futurama ★★★★★
()

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

Если виртуалки сделаны в vmware, то там миграция виртуалок на другие хранилища вообще штатная функция. Никаких многопоточных dd для этого не нужно.

justAmoment ★★★★★
()

Каковы ваши идеи по данному поводу?!

Разупороться и открыть документацию к твоему сверхсекретному старому гипервизору, там написано.

t184256 ★★★★★
()
Ответ на: комментарий от justAmoment

Если виртуалки сделаны в vmware, то там миграция виртуалок на другие хранилища вообще штатная функция. Никаких многопоточных dd для этого не нужно.

Спасибо за совет, повторюсь, что требуется за короткий срок восстановить работу виртуальной машины! Максимум пару часов, за сим и рассматривает «многопоточное» развертывание «образа» виртуальной машины!

agosha
() автор топика
Ответ на: комментарий от t184256

Разупороться

Какой у вас интересный сленг, напоминает Элочку из «12 стульев», есть что по делу сказать?

agosha
() автор топика

Судя по том, что ты здесь написал, тебе не проблему надо решить а ликбез по основам провести. И «интересность» твоего вопроса по 100 бальной шкале я оцениваю примерно в (3 из 100).

Доброго времени суток.

Так не говорит никто нигде и никогда. «Здрасти» достаточно. Для особливо одарённых «Вечер в хату».

Занимаюсь Linux не так давно,

ok

организация рано или поздно (государственный сектор) перейдет на открытый код.

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

Суть вопроса, имеем некие виртуальные машины которые крутятся на старых Гипервизорах,

почему < ! < ! < Г И П Е Р В И З О Р > ! > ! > у тебя написан всего лишь с одной большой буквой (должно быть минимум две: Г и В)? Если ты стал адептом гипервизоро-центрической модели мира, то где же его все регалии и полное наименование? А и да < ! < ! < Г И П Е Р В И З О Р > ! > ! > не может быть с-т-а-р-ы-м, мир его серверам, долголетия и процветания. Он может быть только действующим. И он может назначить н-а-с-л-е-д-н-и-к-а, также со всеми регалиями и полным наименованием, который станет новым столпом поклонения в гипервизоро-центрической модели мира

требуются за минимальные простои по времени, перенести полный клон машины.

А вот тут ты попал в непонятное. Сначала ты говоришь, что тебе нужен бэкап; потом говоришь, что тебе нужен клон; причём клон должен быть «полным». Но так как клон уже побитово идентичен оригиналу на генетическом уровне, то он не может быть «полным» или «неполным». Клон либо «ЕСТЬ», либо эта сущность — «НЕ КЛОН». И в общем случае термин «бэкап» не равен термину «клон».

Так же ты говоришь про «минимальные» простои не очерчивая никаких рамок. Вот, в отрыве от контекста, 3 миллисекунды — это достаточно минимальный простой для тебя? Если да, то всё делай из расчёта на эту величину, и всё, что занимает больше времени чем 3 миллисекунды, называй «тупорылой тормозной хренью». Если же ты решишь делать клон/бэкап виртуалки открывая её тельце в хексредакторе и побайтово переписывая содержимое шариковой ручкой в тетрадки в клеточку. То 5 лет твоего потраченного личного времени будет очень «желанной» и очень «минимальной» величиной по сравнению с одноруким похмельным дядей Петей за соседним столом, который делает бэкап/клон второй виртуалки и расчётное времени на выполнение работы для него составляет 80 лет его личного времени.

Количество информации «море» примерно от 1 до 2 миллионов файлов,

Это чепуха. Адепта гипервизоро-центрической модели мира не должно волновать сколько у его < ! < ! < Г И П Е Р В И З О Р А > ! > ! > находится в подчинении файлов: хоть 1 миллион, хоть 150 миллионов, хоть 7,5 миллиардов.

занимает пространства примерно нескольких терабайтов,

тут уже пошла осмысленная техническая информация, уточни: несколько терабайтов это =1 или =29? Потому что временные затраты на одну и ту же работу будут отличаться минимум в двадцать девять раз, а то и во все тридцать.

нужно попытаться правдами и неправдами

какие-то странные термины, видимо подразумевается либо использование штатных механизмов взаимодействия твоего гипервизора с окружающей средой, либо использование внештатных/секретных/скрытых механизмов гипервизора, либо вообще внешнее вмешательство помимо механизмов гипервизора

(несколькими потоками к примеру dd (смещение по блоками), восстановить полную реплику виртуальной машины)…?

«тупо скип == нокомментс» — потому как тут предлагается вполне себе конкретный метод решения задачи, которая даже ещё не ясна. И ты вводишь в разговор новый термин «реплика», что как бы и не «клон» и не «бэкап». И то что тебе учителя в школе вдалбливали: «Негоже одно и то же называть одинаково. И следует использовать многочисленные синонимы богато представленные в великом и могучем русском языке. И за это будет повышена оценка при проверке твоего сочинения». Так вот это чушь и профанация. В технических разговорах следует ВСЕГДА использовать одно и тоже слово, когда ты говоришь про одну и ту же сущность.

Каковы ваши идеи по данному поводу?!

  1. Формулировка условий и вменяемая постановка задачи.
  2. Изучение штатных механизмов взаимодействия твоего гипервизора с окружающей средой.
  3. Задавание вопросов себе и окружающим.

P.s. По поводу нескольких потоков (смещением по блокам) это моя больная фантазия… ;(

Какой смысл оправдываться за то, что ты ещё даже не совершил?

PS Насчёт постановки задачи и условий вот тебе пример

  1. Условия и задача: я стою на тротуаре, в 10 метрах от меня стоит чёрный большой внедорожник на 4 колёсах.
  2. Решение: Значит, я подхожу к бордюру и выворачиваю за 8 секунд бордюрный камень БР 100.20.8 серого цвета весом 35 килограмм. Ложу его на правое плечо, поддерживая снизу спереди левой рукой и сверху правой рукой, удерживая центр тяжести камня на 5 сантиметров впереди плеча. И с разбега, используя камень как таран, за 2 минуты 40 секунд разбиваю все стёкла в это чёрном внедорожнике на 4 колёсах.
  3. Вопрос, который я задаю: Хорошее ли время 2 минуты 40 секунд?
  4. Вопрос, который я не задал, но он подразумевался: Правильно ли я поступил или сотворил какую-то полную хрень?
  5. Вопрос, который возник у всех остальных, кто об этом услышал: Зачем он это сделал? Какую задачу он пытался решить?
justAmoment ★★★★★
()
Последнее исправление: justAmoment (всего исправлений: 1)

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

peregrine ★★★★★
()
Ответ на: комментарий от agosha

«и открыть документацию к твоему сверхсекретному старому гипервизору, там написано.»

Ты изобретаешь live migration.

t184256 ★★★★★
()

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

pfg ★★★★★
()
Ответ на: комментарий от justAmoment

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

  1. Имеется гипервизор «синергия» на котором запущена виртуальная машина объем составляем примерно 2,5 Tb.
  2. Требуется за ночь сделать полную реплику данной виртуальной машины на диск, который будет подключен в последствии скажем так к другому аттестованному хост серверу с другим гипервизором!

Вооооо, я думаю самую суть указал. Критика учтена!

agosha
() автор топика
Ответ на: комментарий от agosha

винда? Тогда проще сделать снапшот(shadow copy) и его копировать.
Далее в момент «Ч» - сверять списки измененных файлов.

Если Linux - то проще, через rsync первичная синхронизация и последующая в момент «Ч» (конечно если нету всяких selinux и прочих мандатных систем).
Если миграция на linux, то наверное лучше вариант первый. Хоть права на файлы сохранишь.

Atlant ★★★★★
()
Последнее исправление: Atlant (всего исправлений: 1)
Ответ на: комментарий от agosha

можно сделать копию виртуальной машины офлайн/онлайн уж как сможет синергия.
вопрос: запустится ли эта копия на другом гипервизоре ??
ну и классически: документы лежат в одном разделе с корнем операционки ?? :)

pfg ★★★★★
()
Ответ на: комментарий от Atlant

Если Linux - то проще, через rsync первичная синхронизация и последующая в момент «Ч» (конечно если нету всяких selinux и прочих мандатных систем).

Скажем так - доступ к серверам будет примерно часов 10-12, потому и говорю, что ночи на переброс такого объема информации не хватит если использовать лишь один поток!

agosha
() автор топика
Ответ на: комментарий от agosha

А это критично одной ночью обойтись? А мощности сети и raid (и источника и приемника) хватит для перекачки данных?

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

Atlant ★★★★★
()
Последнее исправление: Atlant (всего исправлений: 1)

(государственный сектор) перейдет на открытый код

это хорошо, GPL,MIT,BSD наверное?

anonymous
()

восстановить полную реплику виртуальной машины

это как?

anonymous
()

Каковы ваши идеи по данному поводу?!

это ора сейчас?

anonymous
()

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

Если - да, то делаем резерв всей системы на резервном диске(raid) НАПРЯМУЮ(SATA,SCSI,FC и т.д) подключенному к старому серверу и переносим полученную копию на новый сервер под новый гипервизор и пробуем взлететь.

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

Atlant ★★★★★
()
Последнее исправление: Atlant (всего исправлений: 1)
Ответ на: комментарий от Atlant

ещё вариант придумал:
запустить новый диск/raid как (iscsi|drdb|или иное) как зеркало к имеющемуся диску и просто тихонько ждать полной синхронизации.
Но это так же по сути будет зависеть от совместимости гипервизоров.

Atlant ★★★★★
()
Ответ на: комментарий от agosha

У меня вопрос по существу, какую документацию по платформе Синергия ты вообще читал? Это никакой не наезд, просто от этого зависят твои дальнейшие шаги.

Вот первая ссылка в гугле. https://docplayer.ru/52164726-Zashchishchyonnaya-programmnaya-platforma-siner...

  • Основана на наиболее стабильном лицензионно «чистом» дистрибутиве LinuxDebianSqueeze(ядро v3.2);
  • ПО «Гипервизор»-автономный гипервизор 1-го типа (менеджер виртуальных машин, работающий непосредственно с аппаратной составляющей СВТ), разрабатываемый на базе гипервизора с открытым исходным кодом XEN 4.2.
  • Совместимость с открытыми стандартами (OVF, OpenStack) что позволит мигрировать виртуальные машины с других систем виртуализации, а также использовать уже внедренное сопутствующее ПО, работающее по стандартным протоколам;
  • “Живая” миграция виртуальных машин и поддержка кластеров;

Это про то что есть у тебя сейчас. Теперь скажи, что же ты хочешь сделать. Сделать новый установку нового XEN на новом оборудовании за 500 километров по каналу GPRS? Или установить на новый сервер VMWARE в соседней стойке, соединённой 40 Гбит/с каналом, и перетащить туда старые виртуалки?

Теперь глупый вопрос, за какое время восстанавливается вчерашний полный бэкап старого сервера на новый сервер?

Да, а где же ваши доки? Берёшь доки читаешь про живую миграцию. Если это почему-то тебя не устраивает то берёшь телефон и звонишь Б.Г. Владыкину.

Если всю документацию вы пролюбили. Судя по наименованию проекта исполнителем был бывший ЦНИИ Атоминформ (лень гуглить) . Телефон Б.Г. Владыкина за тебя тоже поискать или сходишь к секретарю и всё узнаешь?

PS 2.5 ТБ по 1 Гигабитной сети будет прокачиваться 7 часов. Параллельный DD не ускорит эту скорость ни на копейку.

justAmoment ★★★★★
()
Ответ на: комментарий от agosha

напоминает Элочку из «12 стульев», есть что по делу сказать?

ЭлЛочку. Это раз. Во вторых, в доке к гипервизору описан процесс backup и инструментарий.

Vault_Boy
()
Ответ на: комментарий от justAmoment

Спасибо за ответ, но все таки заострю внимание на том, что:

  1. подключается винчестер непосредственно к гипервизору, в последствии он же будет вставлен в новый хост сервер.
  2. простое копирование тем же самым rsync приведет к тому что организуется очередь iops, что для нашего случая не есть хорошо!
  3. параллельный запуск нескольких dd не позволит превысить операций ввода/вывода, что уже хорошо, т.е. в среднем без очередей можно запустить примерно 170 потоков, потому как один dd = одному iops.

За сим у меня вопросы про несколько потоков!

agosha
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.