Вопрос: Перенос необработанного образа диска по локальной сети


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

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

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

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

Мои вопросы:

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

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

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

8
2018-02-21 17:58


Источник


Вам точно нужно скопировать использованные блоки с устройств или просто файловую систему (ы) ОС? - Andrew


Ответы:


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

Я предполагаю, что / включен /dev/sda3 и что /boot включен /dev/sda1,

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

    oldserver # resize2fs -M /dev/sda3
    
  2. Разделите диск нового сервера с одинаковым размером /boot, swapspace и новые / раздел (и все, что вам нужно).

    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-адрес и т. Д.).

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


6
2018-02-21 19:42



Потрясающие! Я в порядке с копированием свободного места раздела, потому что эти инструкции соответствуют все других моих критериев. Хотя, не только изменение размера файловой системы и сам раздел на oldserver устранить необходимость скопировать все свободное пространство? Меня не волнует /boot потому что он такой маленький, но для / по крайней мере, я мог бы это сделать, правильно? Просто установите конечный сектор раздела равным тому, какой сектор resize2fs устанавливает конец сектора FS. Ну, сектор, блок ... наверное блок, Но спасибо за это! Отлично! - allquixotic
Да, если вы также уменьшили размер раздела, то вы бы избежали кучи копирования. Это могло бы сэкономить пару часов ... Я бы оставил некоторый провал, на всякий случай, если бы моя математика была немного отпущена. - Michael Hampton♦
Это также устранит ложное / страшное «Отсутствие свободного места на устройстве», так как оно изменит размер /dev/sda3 вплоть до 1,3 ТБ и будет копировать его в раздел в пункте назначения, который будет содержать около 2,9 ТБ. - allquixotic
Это займет некоторое время, Понял, у меня есть гигабитный порт с распределением 100 Мбит / с. Дерьмо. - allquixotic


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

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


5
2018-02-21 18:25



я думаю partimage могут выполнять необработанные копии, которые являются файловой системой, но она не поддерживает ext4, Таким образом, это происходит как вариант ... rsync выглядит лучше, как опция, если он сохраняет все дискреционные средства контроля доступа (a la chmod) и может чисто копировать через символические ссылки и файлы устройств ... - allquixotic
Я второй ответ Джеффа. Вы можете перенести макет раздела с помощью sfdisk -d / dev / sda | ssh "sfdisk / dev / sdb". Создайте свои файловые системы и переведите их с помощью «rsync -a -e» ssh -c arcfour »/ mnt / root @ destination: / mnt / '. Aftewards следуют шагу 5 ответа Майкла Хэмптона, чтобы сделать загрузочный пункт назначения. - Tim Haegele


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

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

Немного больше деталей следуют (я постараюсь держать его в курсе).

Компоненты:

  • mdadmс этими строить режим (ad-hoc-зеркало без метаданных);
  • 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),


1
2018-02-21 19:30



Я также добавлю, что синхронизация на уровне блочного устройства иногда может быть ДЕЙСТВИТЕЛЬНО быстрее, чем переходить к файловому файлу с помощью rsync, особенно когда у вас есть миллионы (буквально) относительно небольших файлов в файловой системе. - artyom
mdadm? Я использую аппаратный RAID. И я понятия не имею, что такое AOE, и никогда не использовал iSCSI. Я не думаю, что мои серверы находятся в том же широковещательном домене, что и в одном и том же центре данных. Между серверами есть как минимум один или два коммутатора. - allquixotic
Я думаю, что это отличная идея! Но как это относится к разным размерам дисков? - Tim Haegele
@allquixotic, тем не менее, вы можете попробовать следующую схему, заменяющую AOE на nbd (сетевое блочное устройство, предоставляемое nbd-server а также nbd-client пакеты). mdadm используется только для синхронизации двух блочных устройств, метаданные не записываются в build , поэтому вы можете использовать его поверх любого блочного устройства (его нужно сначала отключить). Дело в том, что я обычно настраивал новую систему на деградированный raid1 mdadm, даже если у меня есть аппаратный рейд, поэтому я могу применить описанную технику без необходимости размонтировать разделы, сокращая время простоя миграции до одного времени перезагрузки. - artyom