Имеется сервер с двумя винтами - на одном работает FreeBSD 7.4 x86, полностью рабочая с софтом, на второй установлена 8.2 amd64, но без софта и данных. Хотелось бы плавно без даунтайма мигрировать с одной оси на другую.Бродит мысль запустить 8.2, а в виртуалке поднять старую 7.4 с другого винта (и плавно мигрировать сервисы) - но реально ли это (и если реально - то как)?
Или же проще сделать "выходной" на сутки, и перетащить ударным трудом всё в новую ось/на новые версии ПО?
Плавно не получится, софт пересобирать/апргейдить надо
> Или же проще сделать "выходной" на сутки, и перетащить ударным трудом всё
> в новую ось/на новые версии ПО?о каких данных речь для начала?
> Плавно не получится, софт пересобирать/апргейдить надо
>> Или же проще сделать "выходной" на сутки, и перетащить ударным трудом всё
>> в новую ось/на новые версии ПО?
> о каких данных речь для начала?Базы MySQL (75Mb .sql.bz2), PostgreSQL (135Mb .sql.bz2), вирт.хосты (52Гб) ну и всякое по мелочи (логи, архивы, почта).
> Бродит мысль запустить 8.2, а в виртуалке поднять старую 7.4 с другого
> винта (и плавно мигрировать сервисы) - но реально ли это (и
> если реально - то как)?Мы примерно так и делали, с одним различием - сервисы потом переехали в линукс. Но это не суть важно. Порядок работы у нас был примерно такой: сняли dump'ы с живой системы, создали виртуалку с подходящими параметрами жестких дисков, грузанулись с образа livefs, разбили диски. Подмонтировали ресурс с дампами, сделали restore, вернули fstab, отрихтовали конфиги с учетом изменившегося "железа", запустили виртуалку. В общей сложности ушло часа три, с учетом досадного ляпа, когда по неосторожности была удалена почти полностью перенесенная виртуалка :)
И да, лично мой совет - если позволяет железо, новый сервак сразу виртуальным делайте. Избавляет от кучи проблем.
> был примерно такой: сняли dump'ы с живой системы, создали виртуалку с
> подходящими параметрами жестких дисков, грузанулись с образа livefs, разбили диски. Подмонтировали
> ресурс с дампами, сделали restore, вернули fstab, отрихтовали конфиги с учетом
> изменившегося "железа", запустили виртуалку. В общей сложности ушло часа три, сJail или Virtualbox? KVM/etc по понятным причинам недоступен.
>> был примерно такой: сняли dump'ы с живой системы, создали виртуалку с
>> подходящими параметрами жестких дисков, грузанулись с образа livefs, разбили диски. Подмонтировали
>> ресурс с дампами, сделали restore, вернули fstab, отрихтовали конфиги с учетом
>> изменившегося "железа", запустили виртуалку. В общей сложности ушло часа три, с
> Jail или Virtualbox? KVM/etc по понятным причинам недоступен.По понятным - это по каким? Разница между гипервизором первого и второго типа все-таки колоссальная. Если вам принципиально важно, чтобы хост-системой была именно bsd, тогда сложно что-то посоветовать. Можно запихнуть все в virtualbox. Плюсы такого решения - относительно легко бэкапить и переносить систему, минус - нет живой миграции, есть приличная просадка по производительности. Можно все запихнуть в джейл. Его плюсы - относительная простота и гибкость настройки, нет просадки по производительности относительно хост-системы. Минусы: опять же, нет живой миграции, и с бэкапами придется мудрить что-то свое. Писать скрипты бэкапа самостоятельно, скорее всего. Я не говорю, что в этом есть что-то ужасное, просто теряется приличная часть приятных фишек виртуализации. Т.е. есть изоляция системы, а всего остального (простоты бэкапа, возможности переноса виртуальной системы на другую аппаратную платформу с минимальным простоем, и прочего) нет.
Я в данном случае за БСД в качестве гостя.
>[оверквотинг удален]
> такого решения - относительно легко бэкапить и переносить систему, минус -
> нет живой миграции, есть приличная просадка по производительности. Можно все запихнуть
> в джейл. Его плюсы - относительная простота и гибкость настройки, нет
> просадки по производительности относительно хост-системы. Минусы: опять же, нет живой
> миграции, и с бэкапами придется мудрить что-то свое. Писать скрипты бэкапа
> самостоятельно, скорее всего. Я не говорю, что в этом есть что-то
> ужасное, просто теряется приличная часть приятных фишек виртуализации. Т.е. есть изоляция
> системы, а всего остального (простоты бэкапа, возможности переноса виртуальной системы
> на другую аппаратную платформу с минимальным простоем, и прочего) нет.
> Я в данном случае за БСД в качестве гостя.Городить огород из пачки ОС не хочется. Тем более что Linux я знаю только на уровне пользователя. Скрипт бэкапа уже есть. Плюс у фряхи есть ZFS, что очень хочется оставить :) Живая миграция - а на кой она нужна вообще, сервер один и так оно и дальше будет. Может, лет через 5-7 в линуксе будет нормальная фс - тогда и будем переезжать, вряд ли FBSD в этот срок нормальной виртуализацией обзаведётся (Linux KVM был портирован аж в 2007, а воз и ныне там).
ЗЫ сервер на базе десктопной железки, amd x4, 16Gib ram. Обслуживаемый порт - 100mbit/s. Нагрузка - мелкий хостинг.
> Имеется сервер с двумя винтами - на одном работает FreeBSD 7.4 x86,
> полностью рабочая с софтом, на второй установлена 8.2 amd64, но без
> софта и данных. Хотелось бы плавно без даунтайма мигрировать с одной
> оси на другую.
> Бродит мысль запустить 8.2, а в виртуалке поднять старую 7.4 с другого
> винта (и плавно мигрировать сервисы) - но реально ли это (и
> если реально - то как)?
> Или же проще сделать "выходной" на сутки, и перетащить ударным трудом всё
> в новую ось/на новые версии ПО?а. лучше всего стопить на момент пересбора.
б. для начала обновить систему и софт.
в. на новый винт нужно скопировать полностью систему, затем собрать мир и ядро с TARGET_ARCH=amd64 (make buildworld TARGET_ARCH=amd64) и установить их на второй винт (допустим что винт примонтирован к /mnt: make installworld TARGET_ARCH=amd64 DESTDIR=/mnt), поправить /mnt/etc/fstab, поправить очередь загрузки: boot0cfg и уйти в 86-ую систему, там пересобрать все порты portupgrade-ом, еще лучше где-то на др. машине подготовить пакеджи и перезагрузившись просто распаковать все пакеджи, что бы не тратить время на пересборку и тем самым сократить даунтайм.
*уйти в 64-ую систему*
> а. лучше всего стопить на момент пересбора.
> б. для начала обновить систему и софт.
> в. на новый винт нужно скопировать полностью систему, затем собрать мир и
> ядро с TARGET_ARCH=amd64 (make buildworld TARGET_ARCH=amd64) и установить их на второй
> винт (допустим что винт примонтирован к /mnt: make installworld TARGET_ARCH=amd64 DESTDIR=/mnt),
> поправить /mnt/etc/fstab, поправить очередь загрузки: boot0cfg и уйти в 86-ую систему,система уже установлена, она грузится, но софта под ней - только mc :)
Про очередь загрузки спасибо, а то квм заказывать опять не хочется - медленно это.
> система уже установлена, она грузится, но софта под ней - только mcесли возникнут проблемы после апгрейда, вы желаете ломать голову стало причиной тому: переход на амд64, новая система, новый софт? если нет, то менять нужно за раз что-то одно.
>> система уже установлена, она грузится, но софта под ней - только mc
> если возникнут проблемы после апгрейда, вы желаете ломать голову стало причиной тому:
> переход на амд64, новая система, новый софт? если нет, то менять
> нужно за раз что-то одно.Из mission critical только Apache (ветка остается та же, 2.0.х), Nginx (аналогично апачу только последняя цифра поменяется), PostgreSQL (здесь переезд на несколько веток вверх, но в тесте всё работает как надо). PHP - аналогично, сменится только минорный номер релиза, всё в рамках 5.2.x (вообще команда этой фигни - редкие уроды, ломают обратную совместимость заради принципа, это я про register_long_arrays в 5.3/5.4, не говоря уж о safe_mode).
Переезд в MySQL c 5.1 -> 5.5, если и что-то поломает на время - не критично. Всякая фигня вроде почты вообще погоды не делает в моём случае.
> Из mission critical только Apache (ветка остается та же, 2.0.х), Nginx (аналогично
> апачу только последняя цифра поменяется), PostgreSQL (здесь переезд на несколько веток
> вверх, но в тесте всё работает как надо). PHP - аналогично,
> сменится только минорный номер релиза, всё в рамках 5.2.x (вообще команда
> этой фигни - редкие уроды, ломают обратную совместимость заради принципа, это
> я про register_long_arrays в 5.3/5.4, не говоря уж о safe_mode).
> Переезд в MySQL c 5.1 -> 5.5, если и что-то поломает на
> время - не критично. Всякая фигня вроде почты вообще погоды не
> делает в моём случае.а это разницы не играет. сразу видно, что вы не славливали проблемы, причиной которой могли стать сразу несколько ваших действий. я например, уже давно не такой смелый. сейчас мы обновляем довольно большой парк машин, простой на каждой получается не более трех часов, и подготовительная работа по каждой 3-5-ть часов, т.е. выходит одна машина в день на одного человека. до этого подробно разрабатывался план обновления, для того что бы минимизировать простой и были пробные сервера, что бы обкатать возможные глюки.
>[оверквотинг удален]
>> вверх, но в тесте всё работает как надо). PHP - аналогично,
>> сменится только минорный номер релиза, всё в рамках 5.2.x (вообще команда
>> этой фигни - редкие уроды, ломают обратную совместимость заради принципа, это
>> я про register_long_arrays в 5.3/5.4, не говоря уж о safe_mode).
>> Переезд в MySQL c 5.1 -> 5.5, если и что-то поломает на
>> время - не критично. Всякая фигня вроде почты вообще погоды не
>> делает в моём случае.
> а это разницы не играет. сразу видно, что вы не славливали проблемы,
> причиной которой могли стать сразу несколько ваших действий. я например, уже
> давно не такой смелый.Сутки-двое простоя в данном случае не смертельно. Насчет "сразу видно" - не стоит так поспешно судить, смею надеяться, что с 99 года под фряшей всякого навидался.
> Насчет "сразу видно" - не стоит так поспешно судить, смею надеяться, что с 99 года под
> фряшей всякого навидался.// включая попытку закатить 4.х на 386-й с 8мб памяти и (упс) EGA видео. Не взлетело - в какой-то из версий бабушку ягу выпилили :(
>[оверквотинг удален]
>>> я про register_long_arrays в 5.3/5.4, не говоря уж о safe_mode).
>>> Переезд в MySQL c 5.1 -> 5.5, если и что-то поломает на
>>> время - не критично. Всякая фигня вроде почты вообще погоды не
>>> делает в моём случае.
>> а это разницы не играет. сразу видно, что вы не славливали проблемы,
>> причиной которой могли стать сразу несколько ваших действий. я например, уже
>> давно не такой смелый.
> Сутки-двое простоя в данном случае не смертельно. Насчет "сразу видно" - не
> стоит так поспешно судить, смею надеяться, что с 99 года под
> фряшей всякого навидался.Извиняйте, обидеть ни в коем случае не хотел.
Если простой не критичен, то зачем усложнять себе задачу играясь с виртуалкой?