Применение снимка ZFS к не-ZFS FS - PullRequest
Новая
       27

Применение снимка ZFS к не-ZFS FS

0 голосов
/ 26 апреля 2018

Так что это немного вопрос теории, а также конкретного (временного варианта использования)

  • Два сервера должны быть синхронизированы друг с другом. Один локальный, другой резервный.

  • Однако на удаленном сайте данные должны быть продублированы и доступны в случае необходимости (без хранения архивных образов сервера1)

  • сервер1 и сервер2 подключены через Интернет через VPN-соединение

  • server1 использует ZFS Raid 10

  • server2 использует ext4 Raid5 (временная настройка, в будущем будет заменена на ZFS, и этот вариант использования исчезнет)

Можете ли вы сделать снимок ZFS на сервере server1, отправить его на сервер server2 и распаковать / применить его к массиву raid5, по сути дублируя сервер server1 с помощью добавочных снимков?

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

1 Ответ

0 голосов
/ 27 апреля 2018

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

  1. Используйте zfs send для создания потока в исходной системе, а затем используйте инструмент, который может понять содержимое этого потока и преобразовать его в примитивы файловой системы POSIX в принимающей системе.

  2. Сделайте снимок в исходной системе, а затем используйте инструмент, независимый от FS, чтобы скопировать материал из этого снимка.

Преимущество первого заключается в том, что он наиболее эффективен, поскольку ZFS знает, какие части своего пула были изменены, и ему нужно только просматривать / отправлять эти части. Тем не менее, я не знаю ни одного инструмента, который мог бы это сделать. (Прототипы были созданы на хакатонах разработчиков ZFS, но для этого типа инструментов не существует большой аудитории, поэтому они никогда не были произведены с качеством производства AFAIK.)

Второй менее производительный, потому что ему придется проверять данные, чтобы увидеть, что изменилось, но у него есть то преимущество, что существуют инструменты - хотя вам, возможно, придется немного с этим бороться, вы можете использовать rsync для этого , Кроме того, его RPO может быть выше, поскольку передача данных займет немного больше времени. Немного хитрые части будут:

  • Запись его метаданных в доступную для записи часть пула на стороне источника, поскольку копируемый снимок будет доступен только для чтения. (Найдите каталог .zfs/ в корне файловой системы, которую вы хотите скопировать, чтобы найти читаемую копию снимка.)
  • Отсутствие промежуточного состояния у целевой отказоустойчивой системы, если исходная система умирает во время выполнения rsync. Надеемся, что ваш целевой файлер имеет возможность сделать снимок перед началом запуска rsync, чтобы вы могли вернуться к «последнему хорошему состоянию» в случае сбоя запуска. В противном случае, надеюсь, ваши данные / приложения могут допустить некоторые несоответствия. (Или, может быть, есть опция rsync, которая делает это, которую я раньше не использовал.)
...