ZFS сообщает о сильно отличающихся размерах от Windows и о том, что должно быть доступно
Прежде чем мы начнем, да, я знаю, что установка не оптимальна, но мы работаем над планом, чтобы настроить все с нуля. Я унаследовал это от студента-заочника, который здесь больше не работает. Это вопрос о возможном решении.
У нас есть довольно срочная ошибка, которую необходимо исправить перед восстановлением нашего NAS.
Настройка: 2x сервера, 1x Windows server 2012r2 (далее Vmhost) и 1x FreeBSD (называемый Nas) с 8x дисками по 300 ГБ в Raidz2. NAS предоставляет vmhost с iscsi 2 lun.
Vmhost запускает пару виртуальных машин (duh), которые хранятся на этих iscsi-дисках.
Проблема: Существует 1 виртуальная машина, у которой есть моментальные снимки (или контрольные точки) в Hyper-v, возраст которых составляет 2 года (не спрашивайте почему), в результате чего размер файла моментального снимка не превышает размера фактического файла на диске (диск vhdx).
У нас не хватает места на нашем NAS, и из-за этого наши виртуальные машины работают медленно или не отвечают.
Я не понимаю (но, вероятно, очень легко объяснимо), что Windows сообщает, что на iscsi-диске почти 4 ТБ данных. на нем, пока у меня не установлено более 300 * 6 (+2 четности) ГБ жесткого диска. Это просто хорошее сжатие со стороны ZFS?
Предлагаемое решение: Переместите диск виртуальной машины на другой диск и исправьте сопоставление в конфигурации виртуальной машины, затем просто нажмите «удалить контрольную точку» в Hyper-v и позвольте Hyper-v объединить моментальный снимок с диском, а затем переместить его обратно на диск iscsi.
Вопрос:Если размер диска vhdx составляет 1 ТБ, а размер файла моментального снимка - 1 ТБ, достаточно ли 3 ТБ диска в качестве диска слияния? И реально ли разблокирует 1тб? (размер vhdx фиксирован) или он не будет иметь большого значения (поскольку он явно не сообщает правильный размер)?
Большой вопрос: Поскольку размеры на самом деле не имеют никакого смысла, каким числам я могу доверять? У меня есть более 4 ТБ данных на 1800 ГБ пространства, если я использую числа. Неужели zfs настолько умен, что может видеть, что некоторые данные в снимке могут быть такими же, как на диске, и не использовать лишнее пространство?
]
В общем, ZFS может легко достичь сжатия диска виртуальной машины 1,2: 1. Это также умно и не сохраняет нулевые блоки на диске. Базы данных лучше сжимаются. В общем, я не удивлюсь, если виртуальный диск емкостью 4 Тбайт с хорошей сжимаемостью поместится в массив с физическим пространством 1,8 Тб.
Если вы сделаете снимок с помощью ZFS, это будет снимок CoW. Вначале ZFS знала, что данные одинаковы, и просто сохраняла одни и те же данные на диске один раз. Когда в некоторую копию записывается блок, этот блок копируется и сохраняется в каком-то другом месте (это копия при записи, CoW), затем одна из копий изменяется. С этого момента, даже если вы вернете копии, чтобы иметь те же данные, они не будут объединяться в общем случае.
Вы можете объединить любые блоки, которые оказались одинаковыми, даже если вы не начали с моментального снимка. Вы можете указать ему, чтобы он проверял, есть ли в области данных повторяющиеся блоки, и, как вы догадываетесь, сохранять их только один раз. Эта функция называется дедупликацией, но я не вижу, чтобы вы ее использовали, потому что у вас есть DEDUP 1.00x в списке zpool. Кроме того, будьте осторожны, эта функция потребляет МНОГО памяти.
Я бы начал ваше дело с загрузки подозрительной виртуальной машины Windows с помощью некоторого программного обеспечения для резервного копирования дисков, которое выполняет резервное копирование, создавая посекторные копии, и выполняет полное резервное копирование виртуального диска. изнутри этой виртуальной машины (т.е. резервное копирование того, что видит Windows). Или / и резервное копирование образов виртуальных дисков. Это позволит хотя бы не потерять данные, к которым вы точно можете получить доступ. Тогда действуйте, как вы описали.
Также примечание. На вашем снимке экрана я вижу что-то под названием «виртуальная резервная копия». Не делайте таких резервных копий. Не полагайтесь на одну и ту же логическую структуру. Вы потеряете эту резервную копию вместе с данными, которые она должна защищать, если какая-то редкая ошибка в вашем стеке (NTFS на виртуальном диске поверх NTFS на базовом диске поверх пула ZFS) разрушит структуры на диске, и невозможно будет выполнить судебное восстановление данных. из такого двойного торта. Часто лучше всего хранить резервные копии в простейшей возможной структуре, независимой от основного хранилища, то есть на отдельном диске, только в пустой таблице разделов без расширенного управления томами, в простейшей файловой системе. В любом случае это проще получить и восстановить.