В повседневной жизни приходится иметь дело с достаточно разными
сценариями эксплуатации техники и возникающими проблемами. И эти решения
порой бывают не стандартные. Вот и миграция рейда относится из этой
области.
Возникла у нас необходимость перенести рабочую операционную систему с рабочими сервисам и установленную на рейд массив - raid1, с одного сервера на другой. Но так как исходный сервер отличался аппаратно от целевого, в том числе и по рейд контролеру (для пояснения скажу, что эти оба рейда являлись неотъемлемой частью материнских плат), то просто высунуть винты из одной корзины исходного сервера и воткнуть в целевой и что бы система сразу заработало не представляла возможным. А если учитывать, что нужно было обеспечить минимальный простой сервисов то все это выглядело первоначально как то удручающи. Но мы пошли на маленькую хитрость, которая не заключается в подсовывании драйверов рейд контролера целевого сервера, на исходном сервере в рабочем состоянии, а немного в другом. Конечно, можно попытаться просто подсунуть или заменить драйвер целевого рейд контролера, но при попытке запустится после таких манипуляций на целевом сервере обязательно увидим синий экран, конечно можно потратить уйму времени и сил что бы подсунутые драйвера были подхвачены системой и она нормально загрузилась, но зачем когда можно проще.
Для данных манипуляций нам потребуется приличный арсенал средств IT, такие как livecd или liveflash средствами для клонирования данных (тут дело в куса, ghost, acronic и т.п.), переходник IDE/SATA-USB (он нам необходим, так как кроме двух разъемов под корзину из sata дисков и одного под cd-rom на мат. плате больше нечего нету), а так же дополнительный винт с объемом не менее чем системный раздел.
В данном примере по переносу рейда были указаны частный случай, что диски были так же перенесены на новый сервер и там и так использовался raid1, но данная схема походит для любой миграции с различными контролерами и различными конфигурациями рейдов и суть заключается в загрузке с контролера который системой видеться изначально и до установкой необходимого драйвера для рейд контролера. Конечно это не Quik Migration виртуальной машины (в нашем случаи виртуализации не подходила), но это намного быстрей и проще чем пытаться подпихнуть нужный драйвер и уже тем более новое инсталлирование системы.
Статья взята с: http://ru.intel.com/business/community/?automodule=blog&blogid=1960&showentry=588
Автор: Azazela
Возникла у нас необходимость перенести рабочую операционную систему с рабочими сервисам и установленную на рейд массив - raid1, с одного сервера на другой. Но так как исходный сервер отличался аппаратно от целевого, в том числе и по рейд контролеру (для пояснения скажу, что эти оба рейда являлись неотъемлемой частью материнских плат), то просто высунуть винты из одной корзины исходного сервера и воткнуть в целевой и что бы система сразу заработало не представляла возможным. А если учитывать, что нужно было обеспечить минимальный простой сервисов то все это выглядело первоначально как то удручающи. Но мы пошли на маленькую хитрость, которая не заключается в подсовывании драйверов рейд контролера целевого сервера, на исходном сервере в рабочем состоянии, а немного в другом. Конечно, можно попытаться просто подсунуть или заменить драйвер целевого рейд контролера, но при попытке запустится после таких манипуляций на целевом сервере обязательно увидим синий экран, конечно можно потратить уйму времени и сил что бы подсунутые драйвера были подхвачены системой и она нормально загрузилась, но зачем когда можно проще.
Для данных манипуляций нам потребуется приличный арсенал средств IT, такие как livecd или liveflash средствами для клонирования данных (тут дело в куса, ghost, acronic и т.п.), переходник IDE/SATA-USB (он нам необходим, так как кроме двух разъемов под корзину из sata дисков и одного под cd-rom на мат. плате больше нечего нету), а так же дополнительный винт с объемом не менее чем системный раздел.
- На исходном сервере в рабочем состоянии производим замену контролера IDE ATA/ATAPI на Стандартный PCI IDE. (Данная манипуляция не играет роли для работы на данном сервер, но она необходима, что бы склонированая система поднялась на исходном сервер. Для тех кто часто производит клонирование систем или переноса на новое железо данная процедура знакома.) После чего производим выключение исходного сервера и вытаскивание винтов.
- На целевом сервер подключаем через переходник IDE/SATA-USB один винт с исходного сервера; liveflash; дополнительный винт в разъем IDE, где были подключен до этого CD-Rom.
- Загружаемся с liveflash и производим клонирование данных с винта с исходного сервера подключенного через переходник IDE/SATA-USB на дополнительный винт IDE (Так как у нас хорошая практика разнесения данных по разделам на диске то мы производим только клонирование раздела с системой, а не всего диска). После клонирования выключаем систему.
- Производим загрузку системы с дополнительного винта IDE. (Благодаря манипуляциям из первого пункта, у нас система не уйдет в синий экран при загрузке). Устанавливаем необходимые драйвера, в том числе на рейд контролер, после чего выключаем систему.
- Снова загружаемся с liveflash производим обратное клонирование данных (раздела с системой) с дополнительного винта IDE, где у нас система уже распознает рейд контролер целевого сервера, на винт с исходного сервера подключенного через переходник IDE/SATA-USB. После клонирования выключаем сервер и приводим в первоначальное состояние.
- Устанавливаем винт с исходного сервера с который производили манипуляции, а так же не тронутый тоже с исходного сервера в корзину в целевого сервера. Производим запуск целевого сервера и производим конфигурацию рейда в raid1 с указанием что данные берутся с диска, которым производили манипуляции. Выходим из конфигуратора и перезагружаемся.
- Система стартует, производим корректировку сетевого интерфейса и сервисы становятся доступны.
В данном примере по переносу рейда были указаны частный случай, что диски были так же перенесены на новый сервер и там и так использовался raid1, но данная схема походит для любой миграции с различными контролерами и различными конфигурациями рейдов и суть заключается в загрузке с контролера который системой видеться изначально и до установкой необходимого драйвера для рейд контролера. Конечно это не Quik Migration виртуальной машины (в нашем случаи виртуализации не подходила), но это намного быстрей и проще чем пытаться подпихнуть нужный драйвер и уже тем более новое инсталлирование системы.
Статья взята с: http://ru.intel.com/business/community/?automodule=blog&blogid=1960&showentry=588
Автор: Azazela
