Миграция с одного физического сервера на другой

    image


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

    Обычно ставят на новую железку новую ОС, поднимают софт, настраивают, переносят контент, базы и прочее, меняют DNS и через двое суток выключают старый сервер. Казалось бы простая процедура, сотни раз её делал любой сисадмин. НО, в процессе как показывает практика что-то забывается и уже на боевом сервере нужно делать правки и настройки, тащить старые костыли и адаптировать их на новом месте.

    Этот вариант иногда неизбежен, например когда сервера в разных датацентрах. Но если сервера (новый и старый) стоят в соседних стойках, то можно просто перенести ОС на новую железку а старую сразу погасить. О том как это сделать я и напишу небольшую статью-чеклист. Итак поехали!

    Умолчания:
    — Сервера в одном датацентре у одного колокатора/дедикатора
    — Вы договорились с колокатором/дедикатором о том что перецепите ip адреса со старого сервера на новый. Если этого не сделать могут быть косяки в случае если сервера в разных VLAN-ах.
    — Вам дают IP-KVM как минимум на новый сервер, в идеале может понадобиться и на старый если вдруг хочется сохранить его доступность.
    — Колдовство буду показывать на примере CentOS 5.x
    — У вашего серверодателя есть pxe сервер с аварийным (т.н. rescue) образом CentOS 5.x и вашей платформы.
    — Вы знаете root пароль от исходного сервера.
    — Вы переписали, на чистый лист бумаги, со старого сервера настройки сети и разметку диска.

    Итак, все условия выполнены, начинаем работу!
    Загружаем новый сервер по сети, для этого у Supermicro например, нужно включить в BIOS pxe boot для первого сетевого адаптера, перезагрузить сервер и нажать F12. В случае если на сетевом коммутаторе включен STP на аксесных портах при появлении сообщении о попытке получить ip по dhcp нажать кнопку pause и выждать 30 секунд. После чего жмем пробел и загружаемся в CentOS 5.x 64 rescue.

    fdisk -l смотрим зацепились ли диски, если нет то вкорячиваем драйвер RAID контроллера при помощи insmod. Если диски видны, размечаем их так же как на старом сервере, если нет контроллера и есть диски собираем с помощью mdadm software RAID. Да, и не забудьте про swap.

    Создаем файловую систему:
    mkswap /dev/md5 
    mkfs.ext3 /dev/md0
    mkfs.ext3 /dev/md1
    mkfs.ext3 /dev/md2
    mkfs.ext3 /dev/md3
    mkfs.ext3 /dev/md4
    


    Монтируем корневую партицию в /mnt/sysimage
    mount /dev/md0 /mnt/sysimage


    Создаем структуру каталогов в /mnt/sysimage/, например так:
    mkdir -p /mnt/sysimage/{var,usr,home,tmp}


    Монтируем партиции в строгом соответствии со старым сервером:
    mount /dev/md1 /mnt/sysimage/usr
    mount /dev/md2 /mnt/sysimage/var
    mount /dev/md3 /mnt/sysimage/home
    mount /dev/md4 /mnt/sysimage/tmp
    


    Начинаем синхронизацию данных со старого сервера, вот тут нам понадобится root доступ на старый сервер. Предположим что на старом сервере у нас ip 1.1.1.1
    rsync -avH --numeric-ids --progress 1.1.1.1:/ /mnt/sysimage/ --exclude=/dev --exclude=/proc --exclude=/sys


    Как только данные синхронизируются переходим на старый сервер и останавливаем все службы, например mysql/httpd/nginx/proftpd и прочее что у вас есть.

    Снова возвращаемся на новый сервер и снова синхронизируем данные, но уже с параметром --delete
    rsync -avH --numeric-ids --progress 1.1.1.1:/ /mnt/sysimage/ --exclude=/dev --exclude=/proc --exclude=/sys --delete


    Теперь чрутимся в «новый сервер» и начинаем вносить изменения которые необходимы для того чтобы сервер загрузился:
    mkdir /mnt/sysimage/{proc,sys,dev}
    mount --bind /dev /mnt/sysimage/dev
    mount -t proc none /mnt/sysimage/proc
    mount -t sysfs none /mnt/sysimage/sys
    chroot /mnt/sysimage
    


    Если на старом сервере у вас были sda/sdb/sdc а на новом md0/md1/md2 или наоборот то нужно сделать соответствующие правки в /etc/fstab и /boot/grub/grub.conf
    Записи в fstab из:
    /dev/sda1                /                       ext3    defaults        1 1
    /dev/sda2               /home                ext3    defaults        1 2
    /dev/sda3                /tmp                    ext3    defaults        1 2
    /dev/sda4               /var                    ext3    defaults        1 2
    /dev/sda5               /usr                    ext3    defaults        1 2
    tmpfs                   /dev/shm                tmpfs   defaults        0 0
    devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
    sysfs                   /sys                    sysfs   defaults        0 0
    proc                    /proc                   proc    defaults        0 0
    /dev/sda6                swap                    swap    defaults        0 0
    


    Приводим к:
    /dev/md0                /                       ext3    defaults        1 1
    /dev/md4                /home                ext3    defaults        1 2
    /dev/md3                /tmp                    ext3    defaults        1 2
    /dev/md2                /var                    ext3    defaults        1 2
    /dev/md1                /usr                    ext3    defaults        1 2
    tmpfs                   /dev/shm                tmpfs   defaults        0 0
    devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
    sysfs                   /sys                    sysfs   defaults        0 0
    proc                    /proc                   proc    defaults        0 0
    /dev/md5                swap                    swap    defaults        0 0
    


    И переходим к правкам grub.conf
    title CentOS (2.6.18-238.9.1.el5)
            root (hd0,0)
            kernel /boot/vmlinuz-2.6.18-238.9.1.el5 ro root=/dev/sda1
            initrd /boot/initrd-2.6.18-238.9.1.el5.img
    


    приводим к виду:
    title CentOS (2.6.18-238.9.1.el5)
            root (hd0,0)
            kernel /boot/vmlinuz-2.6.18-238.9.1.el5 ro root=/dev/md0 panic=30
            initrd /boot/initrd-2.6.18-238.9.1.el5.img
    


    Пожалуйста, обратите внимание на panic=30 в строке инициализации ядра, это нужно на случай если где-то ошиблись и сервер выпал в Kernel Panic. Без этой panic=30 сервер будет ждать Hardware reset, с ней же он через 30 секунд перезагрузится.

    Теперь нам нужно поставить grub:
    # grub
    grub> root (hd0,0)
    root (hd0,0)
     Filesystem type is ext2fs, partition type 0x83
    grub> setup (hd0)
    setup (hd0)
     Checking if "/boot/grub/stage1" exists... yes
     Checking if "/boot/grub/stage2" exists... yes
     Checking if "/boot/grub/e2fs_stage1_5" exists... yes
     Running "embed /boot/grub/e2fs_stage1_5 (hd0)"...  15 sectors are embedded.
    succeeded
     Running "install /boot/grub/stage1 (hd0) (hd0)1+15 p (hd0,0)/boot/grub/stage2 /boot/grub/grub.conf"... succeeded
    Done.
    grub> quit
    quit
    #
    


    Граб не ругнувшись установился, значит всё нормально. На всякий случай проверяем:
    #  dd if=/dev/sda count=10|strings|grep stage
    Loading stage1.5
    /boot/grub/stage2 /boot/grub/grub.conf
    


    Теперь нам надо создать новый initrd, т.к. в старом может не оказаться например mdadm.
    gzip /boot/initrd-2.6.18-238.9.1.el5.img
    mkinitrd /boot/initrd-2.6.18-238.9.1.el5.img 2.6.18-238.9.1.el5
    


    Включаем firstboot командой:
    chkconfig firstboot on


    И перезагружаем сервер несколько раз нажав Ctrl+D

    Пока сервер перезагружается идем на старый и в зависимости от того нужен он нам дальше или нет отключаем сеть или меняем ip адрес. Если ненужен то для всех сетевых адаптеров в конфиге /etc/sysconfig/network-scripts/ifcfg-ethX (где X номер сетевого адаптера) правим ONBOOT=yes на ONBOOT=no и «останавливаем» сеть /etc/init.d/network stop. Если старый сервер нужен нам то в тех же конфигах задаем новые сетевые настройки и «перезапускаем» сеть /etc/init.d/network restart

    Итак со стары сервером мы закончили, переходим к новому. В IP-KVM мы уже видим синее окошко ncurses которое выдал нам firstboot, переходим к настройке сети и вбиваем старые настройки сети. После чего перезагружаем сервер для чистоты эксперимента.

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

    Если вы нашли ошибку в тексте, пожалуйста напишите мне в личку, я буду крайне благодарен.

    Если нужно прояснить какие-то моменты, не стесняясь спрашивайте! Выше описанную процедуру проводил как минимум пол-сотни раз.

    Если вопросы миграции вам интересны, могу рассказать о миграции контейнера OpenVZ с сервера на который нет root доступа или о миграции физической машины в контейнер OpenVZ.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 36

      +4
      Замечу что не всегда такое сработает, так как железо может быть разным и где то что то не заведется.
        +4
        Приведите примеры, когда не заведется. На моей практике не завелся какой-то контроллер непонятного производства.
          0
          Не заводилось при тупой миграции с hda как иде на sda sata ahci
            +2
            Именно для избежания такого в статье я описал как пересобрать initrd.
        +4
        Какой даунтайм-то, в итоге? Средний, по статистике.
        Все-таки перетаскивать ОС не труЪ, по моему мнению. Классический вариант, описанный в начале, самый правильный, на мой вкус.
          0
          C виндой так и есть, с никсами… ядро пересобрать и гемор закончится в большенстве случаев.
            +1
            Ну этт если ну о-о-очень своеобразное железо.
              +2
              Полная чушь.
              В нормальных дистрах вообще не приходится ядро трогать.
              А при миграции с сервака на сервер, если железо однотипное — даже инитрд трогать не надо.
                0
                Ну, скажем так, у меня на серваках например вот так обстоят дела с /etc/modules.conf
                [root@web01 ~]# cat /etc/modprobe.conf
                alias eth0 e100
                alias eth1 e1000
                alias scsi_hostadapter ata_piix
                alias scsi_hostadapter1 usb-storage
                alias snd-card-0 snd-hda-intel
                options snd-card-0 index=0
                options snd-hda-intel index=0
                remove snd-hda-intel { /usr/sbin/alsactl store 0 >/dev/null 2>&1 || : ; }; /sbin/modprobe -r --ignore-remove snd-hda-intel


                [zentavr@alciona ~]$ cat /etc/modprobe.conf
                alias eth0 r8169
                alias scsi_hostadapter ata_piix


                [zentavr@mail ~]$ cat /etc/modprobe.conf
                alias eth0 e1000
                alias scsi_hostadapter ahci


                [zentavr@dev ~]$ cat /etc/modprobe.conf
                alias scsi_hostadapter xenblk
                alias eth0 xennet


                Ну и облачко-сервер в амазоне:
                [zentavr@aws ~]$ cat /etc/modprobe.conf
                cat: /etc/modprobe.conf: No such file or directory

                :)))

                В принципе, на первый раз прийдётся прогнать kudzu. Скорее всего ещё — mkinitrd.… вроде всё…
                  0
                  А как динамически подгружаемые модули связаны с пересборкой ядра?

                  e100 и e1000 идут в CentOS в комплекте, а r8169 придется заранее собрать из исходников или взять готовый пакет из elrepo.

                  Вобщем проблема может быть с десктопной машиной (web01 явно десктоп), хотя проблемой назвать это сложно.
                    0
                    Они все не десктопные.

                    По поводу r8169 — вроде как всё из коробки:
                    [root@alciona ~]# yum provides *r8169.ko
                    Loaded plugins: fastestmirror
                    Loading mirror speeds from cached hostfile
                    * base: centos.itt-consulting.com
                    * epel: mirrors.uaip.org
                    * extras: centos.itt-consulting.com
                    * ius: download.srv.ro
                    * jpackage-generic: sunsite.rediris.es
                    * jpackage-generic-updates: sunsite.rediris.es
                    * rpmfusion-free-updates: mirror.karneval.cz
                    * rpmfusion-free-updates-testing: mirror.karneval.cz
                    * rpmfusion-nonfree-updates: mirror.karneval.cz
                    * rpmfusion-nonfree-updates-testing: mirror.karneval.cz
                    * updates: centos.itt-consulting.com
                    Excluding Packages in global exclude list
                    Finished
                    kernel-PAE-2.6.18-238.el5.i686 : The Linux kernel compiled for PAE capable machines.
                    Repo : base
                    Matched from:
                    Filename : /lib/modules/2.6.18-238.el5PAE/kernel/drivers/net/r8169.ko

                    kernel-debug-2.6.18-238.el5.i686 : The Linux kernel compiled with extra debugging enabled.
                    Repo : base
                    Matched from:
                    Filename : /lib/modules/2.6.18-238.el5debug/kernel/drivers/net/r8169.ko

                    kernel-xen-2.6.18-238.el5.i686 : The Linux kernel compiled for Xen VM operations
                    Repo : base
                    Matched from:
                    Filename : /lib/modules/2.6.18-238.el5xen/kernel/drivers/net/r8169.ko

                    kernel-2.6.18-238.el5.i686 : The Linux kernel (the core of the Linux operating system)
                    Repo : base
                    Matched from:
                    Filename : /lib/modules/2.6.18-238.el5/kernel/drivers/net/r8169.ko

                    kernel-xen-2.6.18-238.1.1.el5.i686 : The Linux kernel compiled for Xen VM operations
                    Repo : updates
                    Matched from:
                    Filename : /lib/modules/2.6.18-238.1.1.el5xen/kernel/drivers/net/r8169.ko

                    kernel-debug-2.6.18-238.5.1.el5.i686 : The Linux kernel compiled with extra debugging enabled.
                    Repo : updates
                    Matched from:
                    Filename : /lib/modules/2.6.18-238.5.1.el5debug/kernel/drivers/net/r8169.ko

                    kernel-2.6.18-238.1.1.el5.i686 : The Linux kernel (the core of the Linux operating system)
                    Repo : updates
                    Matched from:
                    Filename : /lib/modules/2.6.18-238.1.1.el5/kernel/drivers/net/r8169.ko

                    kernel-xen-2.6.18-238.5.1.el5.i686 : The Linux kernel compiled for Xen VM operations
                    Repo : updates
                    Matched from:
                    Filename : /lib/modules/2.6.18-238.5.1.el5xen/kernel/drivers/net/r8169.ko

                    kernel-2.6.18-238.5.1.el5.i686 : The Linux kernel (the core of the Linux operating system)
                    Repo : updates
                    Matched from:
                    Filename : /lib/modules/2.6.18-238.5.1.el5/kernel/drivers/net/r8169.ko

                    kernel-PAE-2.6.18-238.1.1.el5.i686 : The Linux kernel compiled for PAE capable machines.
                    Repo : updates
                    Matched from:
                    Filename : /lib/modules/2.6.18-238.1.1.el5PAE/kernel/drivers/net/r8169.ko

                    kernel-debug-2.6.18-238.9.1.el5.i686 : The Linux kernel compiled with extra debugging enabled.
                    Repo : updates
                    Matched from:
                    Filename : /lib/modules/2.6.18-238.9.1.el5debug/kernel/drivers/net/r8169.ko

                    kernel-PAE-2.6.18-238.5.1.el5.i686 : The Linux kernel compiled for PAE capable machines.
                    Repo : updates
                    Matched from:
                    Filename : /lib/modules/2.6.18-238.5.1.el5PAE/kernel/drivers/net/r8169.ko

                    kernel-xen-2.6.18-238.9.1.el5.i686 : The Linux kernel compiled for Xen VM operations
                    Repo : updates
                    Matched from:
                    Filename : /lib/modules/2.6.18-238.9.1.el5xen/kernel/drivers/net/r8169.ko

                    kernel-PAE-2.6.18-238.9.1.el5.i686 : The Linux kernel compiled for PAE capable machines.
                    Repo : updates
                    Matched from:
                    Filename : /lib/modules/2.6.18-238.9.1.el5PAE/kernel/drivers/net/r8169.ko

                    kernel-debug-2.6.18-238.1.1.el5.i686 : The Linux kernel compiled with extra debugging enabled.
                    Repo : updates
                    Matched from:
                    Filename : /lib/modules/2.6.18-238.1.1.el5debug/kernel/drivers/net/r8169.ko

                    kernel-2.6.18-238.9.1.el5.i686 : The Linux kernel (the core of the Linux operating system)
                    Repo : updates
                    Matched from:
                    Filename : /lib/modules/2.6.18-238.9.1.el5/kernel/drivers/net/r8169.ko

                    kernel-2.6.18-194.32.1.el5.i686 : The Linux kernel (the core of the Linux operating system)
                    Repo : installed
                    Matched from:
                    Filename : /lib/modules/2.6.18-194.32.1.el5/kernel/drivers/net/r8169.ko

                    kernel-2.6.18-238.9.1.el5.i686 : The Linux kernel (the core of the Linux operating system)
                    Repo : installed
                    Matched from:
                    Filename : /lib/modules/2.6.18-238.9.1.el5/kernel/drivers/net/r8169.ko

                      0
                      Да, в новом ядре появился модуль. В предыдущих ядрах его не было.
              +2
              Зачем пересобирать ядро?
                0
                Только не всё ядро, а initrd чтоб система загрузилась. А дальше уже железо если не зацепится то modprobe/insmod. Это понадобится например если таскать ОС между десктопными «серверами» с реалтековскими сетевыми контроллерами.

                Но и тут можно позаботиться заранее, поставить всё что нужно на исходной системе. Предварительно посмотрев lsmod на новой машинке.
                +1
                Даунтайм от ловкости рук зависит, 5-10 минут в моей практике. При острой необходимости можно сократить до времени необходимом на перезагрузку сервера.

                Описанный в начале стати вариант я использую если нужно сменить ОС напрмиер с CentOS на Debian или сервера в разных ЦОД-ах, причем на старом сервере ставлю реверспрокси или туннель делаю в который все запросы заворачиваю. Но делать это можно если детально знаешь что на сервере и как работает, иначе есть шанс что-то потерять и разгребать косяки на боевом сервере.
                  0
                  Совершенно с вами согласна!
                  Самое главное — именно «чеклист» при подготовке к работам: ничего не забыть.
                  Случалось всякое. И планово переносили, и аварийно поднимали.
                  Тактика описанная в самом начале подразумевает то, что автоматизации пока поддается плохо: человеческий интеллект.
                  Ибо на старом сервере может быть довольно много не нужного уже «мусора», в том числе и отладочного.
                  Плюс — таки да, разница в железе. Это рабочую станцию, полученную клонированием, можно «подкрутить». К промышленным серверам требования несколько другие. Он должен работать сразу. Времени на «подкрутку» (а старый-то автор уже «убил»!) может просто не быть.
                    0
                    Помимо ненужного мусора, на старом сервере может быть тонна самописных костылей без которых проект может умереть. Разница в железе для linux незначительна.

                    Еще раз повторюсь, если хорошо знаем что за сервер перенести надо, то да можно долго и нудно перетаскивать по одному сервису, если переносим чужой черный ящик у которого известна только ОС, то лучше мигрировать.

                  +1
                  Мы похожим способом делаем. Если IP новые, то можно вообще без даунтайма:
                  второй рсинк без выключения софта сделать (первый долгий — могло много чего успеть измениться);
                  потом настраивается всё на новом сервере, и проверяется что бы работало;
                  выключить софт на старом, сделать финальный рсинк с delet-om (второй тоже с ним);
                  перенастроить DNS и включить софт на обоих серверах.

                  Конечно то, что творится дальше на старом сервере не перенесётся на новый, но:
                  1) Можно за пару суток до переезда сделать маленькие значения TTL, Refresh и т.д. для днсов. Тогда смена записей на ДНСах произойдёт достаточно быстро
                  2) хотя бы для просмотра ресурсы будут доступны вообще без даунтайма

                  По поводу условий статьи: раз уж договорились оставить IP, то можно и договорится перенести винты: грузишся со старых, ставишь всё в рейд, правишь граб да ребутаешься на новые; при необходимости далаешь онлайн ресайз разделов (xfs и ext3 точно умеют такое на рейдах). Итого даунтайма: перенос винтов и один ребут.
                    +1
                    Диски часто нет смысла переносить, по тому как на старом сервере например 250-ки SATA, а на новом 500-ки SAS.

                    Про TTL мой опыт показывает что многие операторы связи его игнорируют и ставят свой… Я это заметил ещё во времена когда ддосы отбивать каждый день приходилось.

                      0
                      Ну разделы можно расширить, а в рейде, так и вообще расширить без перезагрузки. Только тогда желательно в рейд ставить именно разделы, а не целые диски, и что бы тот который собираетесь расширять ставить в конец диска. Можно вообще LVM, но что-то он мне не нравится.
                        +1
                        Вы еще учитывайте что перекрутить диски из сервера в сервер даст больший даунтайм.

                        Чисто физически работа по перекручиванию диска из одних салазок в другие, довольно не быстрая. А если взглянуть на сервера с Atom, так у них 2.5' диски прямо внутрях, т.е. это нужно снять сервер, выкрутить, взять переходник на 3.5' и вкрутить в новые салазки.

                          0
                          Ну возможно. С атомамми дела не имел. У нас просто обычно за пару минут справлялся саппорт ДЦ
                      0
                      >Конечно то, что творится дальше на старом сервере не перенесётся на новый
                      Чтобы этого избежать достаточно на старом развернуть проброс портов нужных служб в iptables на соответствующие порты нового сервера. Либо тупо через nginx проксирование нужных хостов на старый сервер. Неоднократно так переезжали уже при апгрейде серверов и сменах каналов. Даун-тайм от силы минута на запуск двух команд.
                        0
                        Вы вероятно что-то путаете, нельзя замаппить локальные порты на удаленный сервер.

                        Для этого делается ip2ip туннель.
                          0
                          Это почему интересно нельзя? Стандартная комбинация DNAT+SNAT, т.е. не через REDIRECT, он — да, только на локальной машине работает.
                          У такого способа только один минус — адрес источника теряем, но для контентной фермы по фигу REMOTE_ADDR клиента.
                          Если надо сохранить адрес клиента, то пробрасываем через nginx.
                          Если у нас фряха, у которой ядро собрано без фаерволов, модулей и т.п., то все тоже решается через что-нибудь типа rinetd.
                          Первый и третий способы использовал по одному разу, второй — основной рабочий на данный момент, т.к. чисто контентых ферм мало под управлением.
                            0
                            Вообще если честно, всю эту длинную портянку из over 6000 пунктов можно заменить следующей последовательностью:
                            1. За 3-4 дня до конца месяца просим новый сервер у хостера. Как правило сервер меняется на более жирный и хостер соглашается эти 3-4 дня не биллить как полный месяц. Инсталл системы идет на шару, как правило, для нового сервера.
                            2. Дампим список пакетов с первого и нового серверов, удаляем версии и совпадения, подключаем нужные репы, доинсталиваем софт на новом сервере.
                            3. Делаем скриптик для rsync over ssh, подтягиваем /home, выборочно /var типа /var/lib/mysql, /var/mail, /var/named и т.п. на новый сервант.
                            4. Вытягиваем /etc, выбираем нужные конфиги типа апача, nginx, mysql и базу юзеров.
                            5. Стопим генерацию контента на время переезда, чтобы сократить время даунтайма и не заботиться об изменениях в /home. Стопим mysql и все службы на старом сервере, повторно синхрим изменения из нужных директорий /var.
                            6. Запускаем заранее сконфигуренный проброс портов на старом сервере и все службы на новом.
                            Из бонусов — получаем переезд с 3 на 4, с 4 на 5 или с 5 на 6 RHEL/CentOS. Т.к. апгрейд серверов обычно не так часто делается. В случае использования SELinux, добавляется пункт 5.1/2 — установка/восстановление контекстов на файлы.
                            С фряхой еще проще — если изначально все компоненты LAMP компилить в соответствующие директории /home, то пересобрать недостающие порты и скопировать кусок rc.local.
                            И пункт 7 — просим 30/31 числа загасить старый сервак, т.к. даже самые отмороженные днс-сервера кеш больше 3 дней не хранят, что заметно по трафу на старом серваке.
                            Сколько раз уже переезжал — даунтайм в пределах пары минут был. Максимум пару раз было 10-15.
                              0
                              Этот вариант описан как: «Обычно ставят на новую железку новую ОС, поднимают софт...». Имхо это самый правильный вариант, чем тащить на новый сервер старую ось.
                              Вот если локально переезжаем, то да — бывает проще dd'шкой перекинуть систему на новый сервер и поднять, чтобы меньше гемороиться и быстрее отвязаться от заказчика.
                              Если же тоже самое делать удаленно, то с большой вероятностью потребуется KVM, который далеко не у всех хостеров халявный и стоит ХХ баксов в час, а делить с хостером часть своего гонорара как-то не комильфо :)
                                0
                                Что-то вы путаете, в статье все пункты подробно расписаны, у меня в чеклисте это выглядит так:
                                1. rsync
                                2. grub-install
                                3. rsync
                                4. mkinitrd

                                То что вы предлагаете можно делать только на серверах которые вы хорошо знаете, по факту я видел разных костылей рассованных по системе в неожиданных местах., великое множество.
                                  0
                                  Платность KVM и отсутствие возможности грузить rescue по запросу у многих хостеров убивает всю последовательность действий. По крайней мере мне за всю практику попался только один хостер, который удовлетворял обоим условиям одновременно. Может это связано с тем, что сервера в основном в штатах у крупных хостеров. Там обезьянки на саппорте максимум что могут сделать — ребутнуть сервак, воткнуть квм или сделать реинсталл системы. Нормальные админы есть, но их хрен дождешься.

                                  Плюс — повторный rsync надо запускать четко на нужные директории, т.к. если у нас имеется сервант, на котором лежит N террабайт контента и количество файлов 10^5-10^6, то эта команда будет работать часок-два.
                                    0
                                    Значит вы выбираете какие-то плохие датацентры, по тому как я не видел еще ни одного датацентра чтобы PXE не было или KVM-а.

                                    Еще раз хочу заострить ваше внимание на том что переносим мы сервер клиентский, мы знать не знаем что там где лежит, что важно, а что нет. По этому синкать будем все данные, чтобы ничего не потерять.
                                    0
                                    Перечитайте статью и поправьте чеклист :)
                                    Забыли создание разделов и файловых систем, операции типа «изменения которые необходимы для того чтобы сервер загрузился».

                                    Плюс. Конфигурять сеть через firstboot это сильно :) kudzu не устраивает? Хотя тоже хрень. Если на сервере больше одного интерфейса, то после первой загрузки будете долго перебирать интерфейсы пока все заработает. Проще заранее определиться что и где, и менять только HWADDR в ifcfg-ethX и modprobe.conf.
                                      0
                                      Через firstboot самый быстрый вариант, нужно на каждм интерйфейсе нажать Enter и всё.

                            0
                            не забыть прописать маки новых сетевух в
                            /etc/udev/rules.d/70-persistent-net.rules
                            иначе сетевухи нового сервера определятся как новые и им будет добавлен следующий номер…
                            например на старом были eth0,eth1 а станут eth2,eth3
                            соответсвенно черевато неподнятием сети при старте, слетанием фаервола и т.п.
                              0
                              Это справедливо для ubuntu/debian. Спасибо за уточнение.
                                0
                                Это можно (и нужно) отключать в конфиге udev. Кому эта фича может быть полезна — затрудняюсь предположить, начерта ее только ввели…
                                0
                                ключи -r и -t у rsync включены в мета-ключ -a, так что -rt отдельно указывать не надо.

                                Only users with full accounts can post comments. Log in, please.