Прежде чем мы начнем, да, я знаю, что настройка не оптимальна, но мы работаем над планом, чтобы настроить все с нуля. Я унаследовал это от студента-заочника, который здесь больше не работает. Это вопрос о возможном решении.
Однако у нас есть довольно срочная неисправность, которую необходимо устранить перед восстановлением нашего NAS.
Установка: 2 сервера, 1x Windows-сервер 2012r2 (также называемый Vmhost) и 1x FreeBSD (называемый Nas) с 8 дисками по 300 ГБ в Raidz2. NAS предоставляет vmhost 2 lun с iscsi.
Vmhost запускает пару виртуальных машин (да), которые хранятся на этих дисках iscsi.
Проблема: есть одна виртуальная машина, у которой есть снимки (или контрольные точки) в 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) разрушит структуры на диске, и невозможно будет выполнить судебное восстановление данных. из такого двойного торта. Часто лучше всего хранить резервные копии в простейшей возможной структуре, независимой от основного хранилища, то есть на отдельном диске, просто в пустой таблице разделов без расширенного управления томами, в простейшей файловой системе. В любом случае это проще получить и восстановить.
