Назад | Перейти на главную страницу

Перенести живой сервер

Я в беда, У меня есть работающий сервер с обычными службами (httpd, mail, sql), и, похоже, я должен быть очень быстрым, чтобы предотвратить полную потерю данных (мой RAID-массив вышел из строя, поэтому теперь я зависим от одного жесткого диска).

Вся система построена на инструкции HowtoForge и, как я читал тот, что на Squeeze, похоже, я могу без труда? перенести моих (виртуальных) пользователей на новый ящик.

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

Некоторая справочная информация:

Мой (действительно) базовый план:

Мои слепые пятна:

Ваш базовый план более или менее верен.

Программа установки squeeze отлично справится с программным RAID. Одно отличие состоит в том, что по умолчанию squeeze использует grub2; lenny использовал grub-legacy (думаю, 0.9). Это несколько отличает администрирование grub, особенно в части обеспечения загрузки grub с обоих дисков в случае сбоя. Вы всегда можете вернуться к grub-legacy, что я и сделал в последний раз, когда столкнулся с этой проблемой. Было бы неплохо протестировать все, что вы делаете, чтобы убедиться, что вы можете перезагрузиться, если какой-либо диск выйдет из строя.

Для копирования данных обязательно используйте rsync. Я бы удостоверился, что сначала настроены правильные учетные записи с теми же uids / gids, затем rsync, но вы всегда можете исправить это позже. rsync -avPHAX должен получить все (-a получает большинство вещей, кроме -H [ard links] -A [CLs] и -X [tended attributes], так что это полезно.

Учитывая, что вы одновременно выполняете эффективное обновление, будьте готовы к тому, что сервисы сломаются незаметно. Конфигурации немного изменятся. Сделав что-то подобное в последнее время, я думаю, что предпочел бы выполнить миграцию вроде-> похоже, а затем обновить последний хост через некоторое время, поскольку миграция всего и одновременное управление обновлениями сделало это гигантской задачей.

Обновлено для дополнительных болевых точек:

Для DNS я бы переместил все DNS хостинг к новой машине за один шаг. Оставьте записи как есть, но установите период обновления прямо вниз (10 минут или около того). Это дает вам возможность перемещать записи DNS на новый компьютер по мере завершения перемещения каждого домена. При перемещении DNS может потребоваться обновление записей whois для любых доменов, которые вы размещаете, так что имейте это в виду. Фактически, установите обновление для всех доменов прямо сейчас, прежде чем начинать что-либо еще - нет ничего хуже, чем иметь плохо кэшированный результат, вызывающий проблемы.

Относительно потери электронной почты: при перемещении почты на новый сервер убедитесь, что записи DNS были обновлены, чтобы указать основной MX на новый сервер, и убедитесь, что старый сервер по-прежнему настроен на ретрансляцию для ваших доменов. Если и на вашем старом, и на новом сервере есть актуальные данные о DNS, ваша почтовая служба на старом сервере будет определять, что он больше не является основным MX, и будет перенаправлять любое электронное письмо на новый основной. Почта также справляется с короткими задержками доставки - так что вы можете просто закрыть или брандмауэр весь доступ к электронной почте на обеих машинах, переместить все сразу, протестировать на новой машине, затем переместить записи MX и открыть почту на новой машине. . SMTP предназначен для работы с простоями, и любое достаточно короткое отключение (я думаю, менее 4 часов) даже не приведет к созданию временных уведомлений об ошибках.

Обновлено, чтобы добавить:

Другой вариант - создать виртуальную машину на новом сервере и выполнить синхронизацию всего старого сервера с образом диска этой новой виртуальной машины. Затем вы можете запустить виртуальную машину, обновить IP-адреса и т. Д. И получить полностью работающую реплику исходного сервера внутри этой виртуальной машины. Потенциально гораздо меньше усилий, но если вы не знакомы со стеками виртуальных машин, такими как KVM или Virtualbox, это может не стоить того.