НОТА: Мое понимание этого вопроса значительно изменилось с тех пор, как я его впервые задал (см. Правка 2 ниже), но я оставил исходную версию без изменений.
Мы собрали внешнюю систему резервного копирования (все еще тестирующуюся внутри компании), которая осуществляет передачу данных через отправку / получение ZFS. Машины на обоих концах - FreeBSD 8.2. В целом настройка работает хорошо.
Однако я явно чего-то не понимаю в размерах потоков моментальных снимков ZFS. Мне было трудно найти информацию по этому поводу, поэтому я надеюсь, что кто-то с большим опытом сможет меня просветить.
На исходной машине у меня есть файловая система размером около 47 ГБ, для которой мне нужно передать снимки:
# zfs list -t snapshot -r -s creation stg/serverx
NAME USED AVAIL REFER MOUNTPOINT
(.......)
stg/serverx@20110620 2.88M - 47.1G -
stg/serverx@20110621 2.89M - 47.1G -
stg/serverx@20110622 2.88M - 47.1G -
stg/serverx@20110623 5.44M - 46.6G -
У меня уже есть снимок от 22 июня на удаленном сервере, поэтому я отправляю ему поток, сгенерированный
zfs send -i stg/serverx@20110622 stg/serverx@20110623
Это получено на другом конце без проблем; однако размер создаваемого потока превышает 80 гигабайт - почти дважды размер всей исходной файловой системы.
Неправильно ли я истолковываю значение столбца «ИСПОЛЬЗУЕМЫЕ», созданного zfs list? Я ожидал, что этот поток снимков будет 5,44 Мб плюс определенные накладные расходы. Кажется, я не совсем понимаю, что такое накладные расходы.
Возможно полезная информация: Мы делаем резервную копию (через rsync) каждого сервера в его собственную файловую систему. Этот конкретный, кажется, генерирует самые большие потоки (относительно файловой системы и размера моментального снимка). Я подозреваю, что это может быть связано с тем, что это почтовый сервер, поэтому часть его содержимого довольно динамична. Однако я ожидал, что это также будет отображаться в размере «использованного» снимка.
Очевидно, что мы можем немного сэкономить, сжав поток (его, вероятно, можно уменьшить до 12-20% от исходного размера). Даже в этом случае пропускная способность будет нашим ограничивающим фактором, поэтому мы хотели бы понять, что делает эти потоки такими большими и можем ли мы что-нибудь сделать, чтобы смягчить его.
РЕДАКТИРОВАТЬ: Я забыл, что в исходной файловой системе включено сжатие zfs. Таким образом, использованные 47 гигабайт действительно соответствуют почти 80 гигабайтам «реальных» данных файловой системы. Я полагаю, что это частичное объяснение, но я до сих пор не понимаю, почему инкрементный поток из zfs send был бы таким большим.
РЕДАКТИРОВАТЬ 2:
Дальнейшее расследование этой резервной копии и нескольких других привело к выводу, что большие переводы на самом деле были ожидаемыми (из-за произошедших обновлений). Однако я не вижу никаких указаний на такой большой объем данных в выводе из zfs list.
Я просмотрел документацию и понимаю, что есть много сложностей при вычислении пространства, используемого снимком. В zfs страница руководства говорит следующее в описании used свойство:
Когда снимки. . . создаются, их пространство изначально разделяется между снимком и файловой системой и, возможно, с предыдущими снимками. При изменении файловой системы пространство, которое ранее было совместно использовано, становится уникальным для снимка и учитывается в использованном пространстве снимка.
Для меня это имеет смысл. Однако я ожидал увидеть гораздо больший снимок, созданный в конце дня, когда сервер был обновлен. На самом деле это всего несколько мегабайт. Здесь нет дедупликации (zpool версия 15). Однако инкрементный поток, генерируемый zfs send -i довольно большой и содержит всю информацию об обновлении.
Может кто-нибудь объяснить это очевидное несоответствие? Таким образом, возникает связанный с этим вопрос: как я могу получить разумную оценку размера инкрементного потока (например, из zfs list вывод)?
Я знаю, что это действительно старый вопрос, но я видел несколько отличий. Всегда была некоторая путаница в отношении значения, выраженного в списке zfs, поскольку оно относится к использованию zfs send | recv. Проблема в том, что значение, выраженное в столбце USED, на самом деле является оценкой объема пространства, которое будет высвобождено, если этот единственный моментальный снимок будет удален, с учетом того, что могут быть более ранние и более поздние снимки, ссылающиеся на одни и те же блоки данных.
Пример:
zfs list -t snapshot -r montreve/cev-prod | grep 02-21
NAME USED AVAIL REFER MOUNTPOINT
montreve/cev-prod@2018-02-21_00-00-01 878K - 514G -
montreve/cev-prod@2018-02-21_sc-daily 907K - 514G -
montreve/cev-prod@2018-02-21_01-00-01 96.3M - 514G -
montreve/cev-prod@2018-02-21_02-00-01 78.5M - 514G -
montreve/cev-prod@2018-02-21_03-00-01 80.3M - 514G -
montreve/cev-prod@2018-02-21_04-00-01 84.0M - 514G -
montreve/cev-prod@2018-02-21_05-00-01 84.2M - 514G -
montreve/cev-prod@2018-02-21_06-00-01 86.7M - 514G -
montreve/cev-prod@2018-02-21_07-00-01 94.3M - 514G -
montreve/cev-prod@2018-02-21_08-00-01 101M - 514G -
montreve/cev-prod@2018-02-21_09-00-01 124M - 514G -
Чтобы узнать, сколько данных необходимо передать для восстановления снимка с помощью zfs send | recv, вам необходимо использовать функцию пробного запуска (-n) для этих значений. Сделав приведенные выше снимки, попробуйте:
zfs send -nv -I montreve/cev-prod@2018-02-21_00-00-01 montreve/cev-prod@2018-02-21_09-00-01
send from @2018-02-21_00-00-01 to montreve/cev-prod@2018-02-21_sc-daily estimated size is 1.99M
send from @2018-02-21_sc-daily to montreve/cev-prod@2018-02-21_01-00-01 estimated size is 624M
send from @2018-02-21_01-00-01 to montreve/cev-prod@2018-02-21_02-00-01 estimated size is 662M
send from @2018-02-21_02-00-01 to montreve/cev-prod@2018-02-21_03-00-01 estimated size is 860M
send from @2018-02-21_03-00-01 to montreve/cev-prod@2018-02-21_04-00-01 estimated size is 615M
send from @2018-02-21_04-00-01 to montreve/cev-prod@2018-02-21_05-00-01 estimated size is 821M
send from @2018-02-21_05-00-01 to montreve/cev-prod@2018-02-21_06-00-01 estimated size is 515M
send from @2018-02-21_06-00-01 to montreve/cev-prod@2018-02-21_07-00-01 estimated size is 755M
send from @2018-02-21_07-00-01 to montreve/cev-prod@2018-02-21_08-00-01 estimated size is 567M
send from @2018-02-21_08-00-01 to montreve/cev-prod@2018-02-21_09-00-01 estimated size is 687M
total estimated size is 5.96G
Ой! Это намного больше, чем значения USED. Однако, если вам не нужны все промежуточные снимки в месте назначения, вы можете использовать параметр консолидации (-i, а не -I), который вычислит необходимую разницу между любыми двумя снимками, даже если между ними есть другие.
zfs send -nv -i montreve/cev-prod@2018-02-21_00-00-01 montreve/cev-prod@2018-02-21_09-00-01
send from @2018-02-21_00-00-01 to montreve/cev-prod@2018-02-21_09-00-01 estimated size is 3.29G
total estimated size is 3.29G
Таким образом, мы изолируем различные блоки, которые были перезаписаны между снимками, поэтому мы берем только их окончательное состояние.
Но это еще не все! zfs send основан на извлечении логичный данные из источника, поэтому, если в исходной файловой системе активировано сжатие, оценки основаны на несжатых данных, которые необходимо отправить. Например, сделав один инкрементный снимок и записав его на диск, вы получите что-то близкое к расчетному значению от команды пробного запуска:
zfs send -i montreve/cev-prod@2018-02-21_08-00-01 montreve/cev-prod@2018-02-21_09-00-01 > /montreve/temp/cp08-09.snap
-rw-r--r-- 1 root root 682M Feb 22 10:07 cp08-09.snap
Но если передать его через gzip, мы увидим, что данные значительно сжаты:
zfs send -i montreve/cev-prod@2018-02-21_08-00-01 montreve/cev-prod@2018-02-21_09-00-01 | gzip > /montreve/temp/cp08-09.gz
-rw-r--r-- 1 root root 201M Feb 22 10:08 cp08-09.gz
Боковое примечание - это основано на OpenZFS в Linux, версия: - ZFS: загруженный модуль v0.6.5.6-0ubuntu16
Вы найдете некоторые ссылки на оптимизацию, которую можно применить к потоку отправки (-D дедуплицированный поток, -e более компактный), но в этой версии я не заметил никакого влияния на размер потоков, сгенерированных с моими наборами данных.
Какая система электронной почты и какая технология «магазина»? Если почтовое хранилище уже каким-либо образом сжато, то каждое инкрементное хранилище может фактически быть полным, поскольку его поток сжатых данных может динамически изменяться из-за сжатия.
Также используется ли дедупликация в обеих системах? Похоже, есть небольшая вероятность того, что он может быть в исходной системе. Это может объяснить разницу в размерах.