Миграция необработанного образа диска по локальной сети

Вот моя ситуация:

• Два выделенных сервера в одном центре обработки данных с гигабитным Ethernet между ними.
• Оба выделенных сервера загрузились в среду аварийного восстановления на основе Debian Squeeze с добавлением дополнительных инструментов и утилит. Также достаточно места для tmp (32 ГБ ОЗУ на обоих компьютерах) для загрузки программного обеспечения, установки пакетов и / или компиляции по мере необходимости.
• Оба выделенных сервера имеют приблизительно 3 ТБ доступного пространства.
• «Исходный» сервер имеет 4 диска по 1,5 ТБ в аппаратном RAID-10 с 4-портовым контроллером Adaptec.
• Сервер назначения имеет 2 диска по 3 ТБ в аппаратном RAID-1 с контроллером портов Adaptec 2 - того же поколения, что и у других, но с другим количеством портов.
• Количество используемых блоков /dev/sdaотличается менее чем на 10 МБ, но массив целевого сервера по некоторым причинам на несколько мегабайт меньше.
• Оба RAID-массива настроены на использование всей дисковой поверхности всех составляющих дисков для создания одного единого тома RAID.
• Операционная система загружается в режиме MBR; загрузка UEFI не используется.

Что я хочу сделать:

• Скопируйте на уровне блоков весь образ ОС (он состоит только из загрузчика GRUB2 в таблице разделов GPT, разделов / boot и / partition) с «исходного» сервера на «целевой» сервер.
• Если возможно , копирование должно происходить «вживую»: это означает, что у меня недостаточно места для хранения правильного файла образа диска на стороне назначения, если я не распаковываю образ диска на жесткий диск в качестве копии происходит . Гигабитное Ethernet-соединение между серверами достаточно надежно, и мне это удобно, и я, конечно, буду работать fsckна обоих концах (исходный и целевой), чтобы убедиться, что файловая система в порядке до и после передачи.
• По возможности не передавайте блоки по сети, которые не используются составляющими файловыми системами в каждом разделе (все разделы отформатированы как ext4). Это связано с тем, что более 50% «исходного» диска занимает свободное место в /разделе.
• Отрегулируйте размер /раздела таким образом, чтобы при копировании он был изменен в соответствии с чуть меньшим размером целевого диска.
• После успешного копирования подключите каждый том и исправьте ссылки на статические IP-адреса, чтобы отразить IP-адреса нового сервера. (Может сделать это прекрасно без какой-либо дополнительной помощи)

Мои вопросы:

• Должен ли я сначала рассчитать разницу (в байтах) между размерами /dev/sdaна каждом сервере, а затем использовать, e2resizeчтобы неразрушающим образом уменьшить размер /раздела на стороне источника, чтобы он вписался в пространство на стороне назначения?
• Должен ли я работать ddна необработанном блочном устройстве, /dev/sdaот источника до места назначения (более ssh), или я должен создать эквивалентную разметку разделов в месте назначения и запускать ddна каждом разделе ? Обратите внимание, что обработка раздела за раз оставляет мне проблему с загрузчиком, но если я не делаю это раздел за раз, то ddнеобходимо знать, чтобы прекратить передачу данных, как только он записал столько байтов, сколько может вместить место назначения (который, мы надеемся, «закроет» самый конец /раздела в последнем блоке, что логически «справа» от всех других разделов в разметке разделов источника).

Несколько разное специфика:

• Основной операционной системой на исходном компьютере является Ubuntu Server 12.04 с несколькими гостями OpenVZ
• Поскольку оба блока загружаются для восстановления, прямой доступ к диску возможен, не ожидая каких-либо изменений в базовых данных под управлением операционной системы.

Это грязно, но выполнимо.

Я полагаю , что здесь /находится /dev/sda3и что /bootна /dev/sda1.

1. Сократите файловую систему на старом сервере до минимально возможного размера.

   oldserver # resize2fs -M /dev/sda3
   

2. /bootРазбейте диск нового сервера на раздел одинакового размера , раздел подкачки и новый /раздел (и все остальное, что вам нужно).

   newserver # parted /dev/sda
   

3. Скопируйте /и /bootфайловые системы.

   oldserver # dd if=/dev/sda1 | ssh root@newserver "dd of=/dev/sda1"
   oldserver # dd if=/dev/sda3 | ssh root@newserver "dd of=/dev/sda3"
   

   Поскольку раздел на новом сервере будет немного меньше, чем раздел на старом сервере, вы получите ложное No space left on deviceсообщение в конце этого. Однако, поскольку вы сократили файловую систему на шаге 1, это не имеет значения.

4. Измените размер файловой системы на новом сервере до размера раздела.

   newserver # resize2fs /dev/sda3
   

5. Установите GRUB на новый диск.

   newserver # mount /dev/sda3 /mnt
   newserver # mount /dev/sda1 /mnt/boot
   newserver # mount -o bind /dev /mnt/dev
   newserver # mount -o proc proc /mnt/proc
   newserver # chroot /mnt /bin/bash
   
   newserver(chroot) # grub-install /dev/sda
   newserver(chroot) # exit
   

6. Завершите оставшиеся исправления (IP-адрес и т. Д.).

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

Я бы mkfsсвежую файловую систему на новом сервере, а затем rsyncсо старого сервера. Это перезапускаемый, последовательный, и каждый файл легко проверяется индивидуально. Там, где вы отбрасываете неиспользуемые разделы файловой системы (а не криминалистическую копию), я не вижу причин не использовать этот метод. Вам придется перезапустить GRUB, но это не должно быть проблемой.

Объяснение необработанной копии, которая знает файловую систему, заняло бы у меня некоторое время, поэтому, если вы не прокомментируете, почему мое решение rsync не работает, я сэкономлю печатать.

Если вы ДЕЙСТВИТЕЛЬНО хотите передавать данные на уровне блочных устройств, я могу вспомнить один довольно полезный прием, который я использовал для миграции серверов с минимальным временем простоя.

Дело в том, что вы можете создать ухудшенное зеркало на исходном сервере, где ваш раздел данных является единственной активной половиной зеркала, а затем экспортировать целевой раздел со второго сервера через AOE (я полагаю, что оба ваших сервера находятся в одном широковещательном домене). На исходном сервере вы затем подключаете сетевое блочное устройство к поврежденному зеркалу, чтобы оно начало перестраиваться. Дождитесь завершения восстановления, остановите зеркало, удалите экспортированное устройство AOE, и все в порядке.

Далее следует немного больше деталей (я постараюсь сделать это кратким).

Компоненты:

• mdadmс его режимом сборки (специальное зеркало без метаданных);
• vblade для экспорта блочного устройства в качестве сетевого устройства AOE;
• aoe-tools для импорта сетевого блочного устройства AOE.

Вы должны создать таблицу разделов на целевом сервере, а затем сжать исходный раздел, чтобы он соответствовал назначению. Вы можете легко установить GRUB на свою новую MBR; синхронизация только разделов по вновь созданной таблице разделов менее подвержена ошибкам.

На принимающей стороне вы должны экспортировать свой раздел с помощью vbladeинструмента, на исходном сервере вы можете увидеть экспортированные устройства после установки aoe-tools(запустите, aoe-discoverзатем посмотрите на /dev/ether/устройства).

Затем вы должны собрать устройство raid1 на исходном сервере с вашим исходным диском:

mdadm --build /dev/md0 -n2 -l1 --force /dev/sda

После этого вы можете осмотреть только что построенное зеркало:

mdadm --detail /dev/md0
cat /proc/mdstat

На этом этапе вы можете безопасно прикрепить экспортированный целевой раздел к этому зеркалу:

mdadm /dev/md0 --add /dev/ether/eX.Y

Затем просто следите за ходом синхронизации:

watch -n5 cat /proc/mdstat

После завершения синхронизации просто остановите зеркало: mdadm --stop /dev/md0на исходном сервере, завершите vbladeпроцесс на конечном сервере, установите GRUB на втором сервере, измените свои IP-адреса и т. Д.

На самом деле, с помощью этого трюка можно перемещать сервер между ящиками практически в режиме реального времени, а простои просто перезагружать синхронизированные ящики.

Из соображений производительности я также предлагаю увеличить MTU вашего канала (или, если это возможно, настроить отдельную VLAN с включенными jumbo-кадрами).

Обратите внимание, что вы также можете использовать что-то вроде nbd-server/ nbd-client(или даже iSCSI, если вы хотите, чтобы он был грубым) в качестве альтернативы AOE, но AOE ( vblade+ aoe-tools) имеет очень простой интерфейс и отличную производительность (без издержек TCP / IP),