Комментарии 36
Замечу что не всегда такое сработает, так как железо может быть разным и где то что то не заведется.
Какой даунтайм-то, в итоге? Средний, по статистике.
Все-таки перетаскивать ОС не труЪ, по моему мнению. Классический вариант, описанный в начале, самый правильный, на мой вкус.
Все-таки перетаскивать ОС не труЪ, по моему мнению. Классический вариант, описанный в начале, самый правильный, на мой вкус.
C виндой так и есть, с никсами… ядро пересобрать и гемор закончится в большенстве случаев.
Ну этт если ну о-о-очень своеобразное железо.
Полная чушь.
В нормальных дистрах вообще не приходится ядро трогать.
А при миграции с сервака на сервер, если железо однотипное — даже инитрд трогать не надо.
В нормальных дистрах вообще не приходится ядро трогать.
А при миграции с сервака на сервер, если железо однотипное — даже инитрд трогать не надо.
Ну, скажем так, у меня на серваках например вот так обстоят дела с /etc/modules.conf
Ну и облачко-сервер в амазоне:
:)))
В принципе, на первый раз прийдётся прогнать kudzu. Скорее всего ещё — mkinitrd.… вроде всё…
[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.… вроде всё…
А как динамически подгружаемые модули связаны с пересборкой ядра?
e100 и e1000 идут в CentOS в комплекте, а r8169 придется заранее собрать из исходников или взять готовый пакет из elrepo.
Вобщем проблема может быть с десктопной машиной (web01 явно десктоп), хотя проблемой назвать это сложно.
e100 и e1000 идут в CentOS в комплекте, а r8169 придется заранее собрать из исходников или взять готовый пакет из elrepo.
Вобщем проблема может быть с десктопной машиной (web01 явно десктоп), хотя проблемой назвать это сложно.
Они все не десктопные.
По поводу r8169 — вроде как всё из коробки:
По поводу 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
Зачем пересобирать ядро?
Только не всё ядро, а initrd чтоб система загрузилась. А дальше уже железо если не зацепится то modprobe/insmod. Это понадобится например если таскать ОС между десктопными «серверами» с реалтековскими сетевыми контроллерами.
Но и тут можно позаботиться заранее, поставить всё что нужно на исходной системе. Предварительно посмотрев lsmod на новой машинке.
Но и тут можно позаботиться заранее, поставить всё что нужно на исходной системе. Предварительно посмотрев lsmod на новой машинке.
Даунтайм от ловкости рук зависит, 5-10 минут в моей практике. При острой необходимости можно сократить до времени необходимом на перезагрузку сервера.
Описанный в начале стати вариант я использую если нужно сменить ОС напрмиер с CentOS на Debian или сервера в разных ЦОД-ах, причем на старом сервере ставлю реверспрокси или туннель делаю в который все запросы заворачиваю. Но делать это можно если детально знаешь что на сервере и как работает, иначе есть шанс что-то потерять и разгребать косяки на боевом сервере.
Описанный в начале стати вариант я использую если нужно сменить ОС напрмиер с CentOS на Debian или сервера в разных ЦОД-ах, причем на старом сервере ставлю реверспрокси или туннель делаю в который все запросы заворачиваю. Но делать это можно если детально знаешь что на сервере и как работает, иначе есть шанс что-то потерять и разгребать косяки на боевом сервере.
Совершенно с вами согласна!
Самое главное — именно «чеклист» при подготовке к работам: ничего не забыть.
Случалось всякое. И планово переносили, и аварийно поднимали.
Тактика описанная в самом начале подразумевает то, что автоматизации пока поддается плохо: человеческий интеллект.
Ибо на старом сервере может быть довольно много не нужного уже «мусора», в том числе и отладочного.
Плюс — таки да, разница в железе. Это рабочую станцию, полученную клонированием, можно «подкрутить». К промышленным серверам требования несколько другие. Он должен работать сразу. Времени на «подкрутку» (а старый-то автор уже «убил»!) может просто не быть.
Самое главное — именно «чеклист» при подготовке к работам: ничего не забыть.
Случалось всякое. И планово переносили, и аварийно поднимали.
Тактика описанная в самом начале подразумевает то, что автоматизации пока поддается плохо: человеческий интеллект.
Ибо на старом сервере может быть довольно много не нужного уже «мусора», в том числе и отладочного.
Плюс — таки да, разница в железе. Это рабочую станцию, полученную клонированием, можно «подкрутить». К промышленным серверам требования несколько другие. Он должен работать сразу. Времени на «подкрутку» (а старый-то автор уже «убил»!) может просто не быть.
Помимо ненужного мусора, на старом сервере может быть тонна самописных костылей без которых проект может умереть. Разница в железе для linux незначительна.
Еще раз повторюсь, если хорошо знаем что за сервер перенести надо, то да можно долго и нудно перетаскивать по одному сервису, если переносим чужой черный ящик у которого известна только ОС, то лучше мигрировать.
Еще раз повторюсь, если хорошо знаем что за сервер перенести надо, то да можно долго и нудно перетаскивать по одному сервису, если переносим чужой черный ящик у которого известна только ОС, то лучше мигрировать.
Мы похожим способом делаем. Если IP новые, то можно вообще без даунтайма:
второй рсинк без выключения софта сделать (первый долгий — могло много чего успеть измениться);
потом настраивается всё на новом сервере, и проверяется что бы работало;
выключить софт на старом, сделать финальный рсинк с delet-om (второй тоже с ним);
перенастроить DNS и включить софт на обоих серверах.
Конечно то, что творится дальше на старом сервере не перенесётся на новый, но:
1) Можно за пару суток до переезда сделать маленькие значения TTL, Refresh и т.д. для днсов. Тогда смена записей на ДНСах произойдёт достаточно быстро
2) хотя бы для просмотра ресурсы будут доступны вообще без даунтайма
По поводу условий статьи: раз уж договорились оставить IP, то можно и договорится перенести винты: грузишся со старых, ставишь всё в рейд, правишь граб да ребутаешься на новые; при необходимости далаешь онлайн ресайз разделов (xfs и ext3 точно умеют такое на рейдах). Итого даунтайма: перенос винтов и один ребут.
второй рсинк без выключения софта сделать (первый долгий — могло много чего успеть измениться);
потом настраивается всё на новом сервере, и проверяется что бы работало;
выключить софт на старом, сделать финальный рсинк с delet-om (второй тоже с ним);
перенастроить DNS и включить софт на обоих серверах.
Конечно то, что творится дальше на старом сервере не перенесётся на новый, но:
1) Можно за пару суток до переезда сделать маленькие значения TTL, Refresh и т.д. для днсов. Тогда смена записей на ДНСах произойдёт достаточно быстро
2) хотя бы для просмотра ресурсы будут доступны вообще без даунтайма
По поводу условий статьи: раз уж договорились оставить IP, то можно и договорится перенести винты: грузишся со старых, ставишь всё в рейд, правишь граб да ребутаешься на новые; при необходимости далаешь онлайн ресайз разделов (xfs и ext3 точно умеют такое на рейдах). Итого даунтайма: перенос винтов и один ребут.
Диски часто нет смысла переносить, по тому как на старом сервере например 250-ки SATA, а на новом 500-ки SAS.
Про TTL мой опыт показывает что многие операторы связи его игнорируют и ставят свой… Я это заметил ещё во времена когда ддосы отбивать каждый день приходилось.
Про TTL мой опыт показывает что многие операторы связи его игнорируют и ставят свой… Я это заметил ещё во времена когда ддосы отбивать каждый день приходилось.
Ну разделы можно расширить, а в рейде, так и вообще расширить без перезагрузки. Только тогда желательно в рейд ставить именно разделы, а не целые диски, и что бы тот который собираетесь расширять ставить в конец диска. Можно вообще LVM, но что-то он мне не нравится.
Вы еще учитывайте что перекрутить диски из сервера в сервер даст больший даунтайм.
Чисто физически работа по перекручиванию диска из одних салазок в другие, довольно не быстрая. А если взглянуть на сервера с Atom, так у них 2.5' диски прямо внутрях, т.е. это нужно снять сервер, выкрутить, взять переходник на 3.5' и вкрутить в новые салазки.
Чисто физически работа по перекручиванию диска из одних салазок в другие, довольно не быстрая. А если взглянуть на сервера с Atom, так у них 2.5' диски прямо внутрях, т.е. это нужно снять сервер, выкрутить, взять переходник на 3.5' и вкрутить в новые салазки.
>Конечно то, что творится дальше на старом сервере не перенесётся на новый
Чтобы этого избежать достаточно на старом развернуть проброс портов нужных служб в iptables на соответствующие порты нового сервера. Либо тупо через nginx проксирование нужных хостов на старый сервер. Неоднократно так переезжали уже при апгрейде серверов и сменах каналов. Даун-тайм от силы минута на запуск двух команд.
Чтобы этого избежать достаточно на старом развернуть проброс портов нужных служб в iptables на соответствующие порты нового сервера. Либо тупо через nginx проксирование нужных хостов на старый сервер. Неоднократно так переезжали уже при апгрейде серверов и сменах каналов. Даун-тайм от силы минута на запуск двух команд.
Вы вероятно что-то путаете, нельзя замаппить локальные порты на удаленный сервер.
Для этого делается ip2ip туннель.
Для этого делается ip2ip туннель.
Это почему интересно нельзя? Стандартная комбинация DNAT+SNAT, т.е. не через REDIRECT, он — да, только на локальной машине работает.
У такого способа только один минус — адрес источника теряем, но для контентной фермы по фигу REMOTE_ADDR клиента.
Если надо сохранить адрес клиента, то пробрасываем через nginx.
Если у нас фряха, у которой ядро собрано без фаерволов, модулей и т.п., то все тоже решается через что-нибудь типа rinetd.
Первый и третий способы использовал по одному разу, второй — основной рабочий на данный момент, т.к. чисто контентых ферм мало под управлением.
У такого способа только один минус — адрес источника теряем, но для контентной фермы по фигу REMOTE_ADDR клиента.
Если надо сохранить адрес клиента, то пробрасываем через nginx.
Если у нас фряха, у которой ядро собрано без фаерволов, модулей и т.п., то все тоже решается через что-нибудь типа rinetd.
Первый и третий способы использовал по одному разу, второй — основной рабочий на данный момент, т.к. чисто контентых ферм мало под управлением.
Вообще если честно, всю эту длинную портянку из 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.
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.
Этот вариант описан как: «Обычно ставят на новую железку новую ОС, поднимают софт...». Имхо это самый правильный вариант, чем тащить на новый сервер старую ось.
Вот если локально переезжаем, то да — бывает проще dd'шкой перекинуть систему на новый сервер и поднять, чтобы меньше гемороиться и быстрее отвязаться от заказчика.
Если же тоже самое делать удаленно, то с большой вероятностью потребуется KVM, который далеко не у всех хостеров халявный и стоит ХХ баксов в час, а делить с хостером часть своего гонорара как-то не комильфо :)
Вот если локально переезжаем, то да — бывает проще dd'шкой перекинуть систему на новый сервер и поднять, чтобы меньше гемороиться и быстрее отвязаться от заказчика.
Если же тоже самое делать удаленно, то с большой вероятностью потребуется KVM, который далеко не у всех хостеров халявный и стоит ХХ баксов в час, а делить с хостером часть своего гонорара как-то не комильфо :)
Что-то вы путаете, в статье все пункты подробно расписаны, у меня в чеклисте это выглядит так:
1. rsync
2. grub-install
3. rsync
4. mkinitrd
То что вы предлагаете можно делать только на серверах которые вы хорошо знаете, по факту я видел разных костылей рассованных по системе в неожиданных местах., великое множество.
1. rsync
2. grub-install
3. rsync
4. mkinitrd
То что вы предлагаете можно делать только на серверах которые вы хорошо знаете, по факту я видел разных костылей рассованных по системе в неожиданных местах., великое множество.
Платность KVM и отсутствие возможности грузить rescue по запросу у многих хостеров убивает всю последовательность действий. По крайней мере мне за всю практику попался только один хостер, который удовлетворял обоим условиям одновременно. Может это связано с тем, что сервера в основном в штатах у крупных хостеров. Там обезьянки на саппорте максимум что могут сделать — ребутнуть сервак, воткнуть квм или сделать реинсталл системы. Нормальные админы есть, но их хрен дождешься.
Плюс — повторный rsync надо запускать четко на нужные директории, т.к. если у нас имеется сервант, на котором лежит N террабайт контента и количество файлов 10^5-10^6, то эта команда будет работать часок-два.
Плюс — повторный rsync надо запускать четко на нужные директории, т.к. если у нас имеется сервант, на котором лежит N террабайт контента и количество файлов 10^5-10^6, то эта команда будет работать часок-два.
Значит вы выбираете какие-то плохие датацентры, по тому как я не видел еще ни одного датацентра чтобы PXE не было или KVM-а.
Еще раз хочу заострить ваше внимание на том что переносим мы сервер клиентский, мы знать не знаем что там где лежит, что важно, а что нет. По этому синкать будем все данные, чтобы ничего не потерять.
Еще раз хочу заострить ваше внимание на том что переносим мы сервер клиентский, мы знать не знаем что там где лежит, что важно, а что нет. По этому синкать будем все данные, чтобы ничего не потерять.
Перечитайте статью и поправьте чеклист :)
Забыли создание разделов и файловых систем, операции типа «изменения которые необходимы для того чтобы сервер загрузился».
Плюс. Конфигурять сеть через firstboot это сильно :) kudzu не устраивает? Хотя тоже хрень. Если на сервере больше одного интерфейса, то после первой загрузки будете долго перебирать интерфейсы пока все заработает. Проще заранее определиться что и где, и менять только HWADDR в ifcfg-ethX и modprobe.conf.
Забыли создание разделов и файловых систем, операции типа «изменения которые необходимы для того чтобы сервер загрузился».
Плюс. Конфигурять сеть через firstboot это сильно :) kudzu не устраивает? Хотя тоже хрень. Если на сервере больше одного интерфейса, то после первой загрузки будете долго перебирать интерфейсы пока все заработает. Проще заранее определиться что и где, и менять только HWADDR в ifcfg-ethX и modprobe.conf.
НЛО прилетело и опубликовало эту надпись здесь
ключи -r и -t у rsync включены в мета-ключ -a, так что -rt отдельно указывать не надо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Миграция с одного физического сервера на другой