Комментарии 11
Интересно. Хоть и выглядит сложновато для такой задачи. Напрягает только fsck, который выполняется когда уже все сервисы не работают. Какой в итоге получается средний простой для Вашего случая (500Гб данных)?
PS: Сам для подобных переносов использую схему на уровне ФС (а не блочных устройств):
1. создаю базовую копию старого сервера на новом (любым способом)
2. непосредственно перед началом переноса делаю rsync
3. останавливаю сервисы на старом сервере
4. еще раз rsync
5. дальше мероприятия по адаптации ФС
Время простоя тут, конечно, сильно зависит от содержания самой ФС.
PS: Сам для подобных переносов использую схему на уровне ФС (а не блочных устройств):
1. создаю базовую копию старого сервера на новом (любым способом)
2. непосредственно перед началом переноса делаю rsync
3. останавливаю сервисы на старом сервере
4. еще раз rsync
5. дальше мероприятия по адаптации ФС
Время простоя тут, конечно, сильно зависит от содержания самой ФС.
Старый добрый rsync хорош до тех пор, пока у вас между итерациями не накапливается большой объем данных. И очевидно, rsync неприменим в случае если нет доступа к ФС, например, если вы отдаете LV тома напрямую в виртуальные машины.
По поводу fsck, думаю можно немного изменить алгоритм после копирования LVM:
— гасим «старый» сервер не отключая предварительно таргеты и не исключая копию из LVM
— ФС при этом будет размонтирована штатно
В этом случае минус в том, что в случае проблем с «новым» сервером, «старый» может не загрузиться сразу из-за ругани на отсутствующую копию, хотя это несложно исправить.
По поводу fsck, думаю можно немного изменить алгоритм после копирования LVM:
— гасим «старый» сервер не отключая предварительно таргеты и не исключая копию из LVM
— ФС при этом будет размонтирована штатно
В этом случае минус в том, что в случае проблем с «новым» сервером, «старый» может не загрузиться сразу из-за ругани на отсутствующую копию, хотя это несложно исправить.
rsync по сути не работает когда у вас очень много мелких файлов.
Он будет работать днями, в то время как переброс вообще всех возможных данных — максимум час.
Он будет работать днями, в то время как переброс вообще всех возможных данных — максимум час.
Хабр — торт!
Очень круто!
А ещё в LVM можно делать перенос логических томов «на живую» (без отмонтирования) с одного физического тома на другой. Даже если на этом томе расположена корневая ФС загруженной системы. Команда называется «pvmove».
Причем, сделано так, что если в процессе переноса «что-то пойдет не так», то мало того, что система сможет нормально загрузиться с частично перенесенного тома, но и сможет продолжить процесс переноса после запуска «pvmove» без аругментов.
Очень удобно таким способом переезжать с одного жесткого диска на другой. Но этот сценарий скорее ортогональный тому, который описан в статье.
Причем, сделано так, что если в процессе переноса «что-то пойдет не так», то мало того, что система сможет нормально загрузиться с частично перенесенного тома, но и сможет продолжить процесс переноса после запуска «pvmove» без аругментов.
Очень удобно таким способом переезжать с одного жесткого диска на другой. Но этот сценарий скорее ортогональный тому, который описан в статье.
Лучше бы не использовать TGT в качестве целевого устройства. Во-первых, TGT — полностью user-mode решение, во вторых, на загрузочном диске его может и не быть (на Selectel Rescue он есть, надеюсь). Поскольку мы грузимся со стороннего носителя, мы можем использовать любое ядро по желанию. Kernel-mode LIO-target, который включен во все ядра, начиная, кажется, с 3.2 — вот наш выбор.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Перенос данных между серверами с помощью LVM и iSCSI