Существует много споров о том, можно ли запускать FreeNAS как виртуальную машину.
Официальная позиция - да, но есть требуется дополнительная конфигурация.
Если я не могу гарантировать, что могу следовать этим рекомендациям, я более уязвим к сбоям - особенно к катастрофическим сбоям - чем если бы я запускаю ванильную систему Linux с EXT4 / XFS или FreeBSD с UFS?
В частности, предположим, что я не смогу ни выполнять сквозную передачу PCI, ни отключить кеширование записи. Кроме того, у меня будет только один виртуальный диск для хранения (VMDK, поддерживаемый аппаратным RAID), поэтому никакого RAIDZ. Очевидно, резервные копии будут.
РЕДАКТИРОВАТЬ: Чтобы прояснить, почему я хочу это сделать - мне нужен файловый сервер, и это инфраструктура, с которой я должен работать. Если мне нужно, я могу получить дополнительные виртуальные диски для установки RAIDZ, но в остальном все. Я искал хорошее решение для файлового сервера, и FreeNAS, казалось, отвечал всем требованиям. За исключением того, что были все эти ужасные предупреждения о виртуализации ZFS и о том, как вы можете потерять все свои данные и повредить резервные копии.
Я понимаю, что развертывание FreeNAS в этой инфраструктуре рискованно. У меня вопрос: это опаснее альтернативы?
РЕДАКТИРОВАТЬ2: Похоже, мне не удается передать свои намерения. FreeNAS с ZFS - это надежная платформа NAS. Однако из того, что у меня есть читать, похоже, что функции, которые делают ZFS более надежным в качестве файлового сервера без операционной системы, могут действительно работать против вас, если вы запустите его в стандартной конфигурации виртуальной машины. Если это так, то использование другой файловой системы является лучшим выбором при стандартных настройках виртуальной машины (т. Е. Без прямого ввода-вывода, включен кэш записи). Это правильная оценка?
Если я не могу гарантировать, что могу следовать этим рекомендациям, я более уязвим для сбоев - особенно катастрофических - чем если бы я запустил ванильную систему Linux с EXT4 / XFS или FreeBSD с UFS?
Риски различны и напрямую не сопоставимы.
send/recv или снимки делают вашу жизнь намного проще и не имеют ничего общего с целостностью.Если вы посмотрите на упомянутые рекомендации и проанализируете их, вы заметите несколько вещей:
- Если вы не используете сквозную передачу PCI (подробнее об этом ниже), вы должны отключить задачи очистки в ZFS. Оборудование может «лгать» ZFS, поэтому очистка может нанести больше вреда, чем пользы, возможно, даже навсегда разрушив ваш zpool.
Scrub просто читает каждый блок базовых vdev и проверяет их контрольные суммы. Если ваш виртуальный диск с этим не справляется, это мусор, и вам следует беспокоиться об этом, а не о ZFS. С другой стороны, если ваши виртуальные диски уже имеют контрольную сумму в SAN, ваша дополнительная очистка не будет делать ничего, кроме как вызывать дополнительный ввод-вывод (это бесполезно).
- Вторая мера предосторожности - отключить любое кэширование записи, которое происходит на самом контроллере SAN, NAS или RAID. Кэш записи может легко запутать ZFS в отношении того, что было или не было записано на диск. Эта путаница может привести к катастрофическим сбоям пула.
Это хороший совет, если вы не доверяете оборудованию. Обратной стороной, конечно же, является значительно меньшая производительность. Вы также можете не контролировать настройки SAN, поэтому вам нужно рассматривать его как дешевый диск, который вы купили на ebay и вставили в свою систему - все может случиться, по крайней мере, теоретически.
- Использование одного диска делает вас уязвимым для повреждения метаданных пула, что может привести к потере пула. Чтобы этого избежать, вам потребуется как минимум три виртуальных сервера vdev с чередованием или в конфигурации RAIDZ. Поскольку метаданные пула ZFS зеркалируются между тремя vdev, если они доступны, использование минимум трех vdev для создания пула безопаснее, чем одного vdev. В идеале предпочтительнее использовать vdev с собственной избыточностью.
Это нормально в качестве общего совета, но немного придирки. Если у вас плохой SAN, это поможет вам в определенных случаях (по крайней мере, если повезет). Если у вас хорошая сеть SAN, это ничего не даст, а просто приведет к потере места и производительности. На мой взгляд, гораздо лучше убедиться, что цепочка от физических дисков до SAN, сети, хоста виртуальной машины и гостевой виртуальной машины одинаково хороша, поэтому вам не нужно делать все заново на каждом уровне.
Несколько слов о рекомендациях FreeNAS - они, безусловно, подходят в качестве рекомендаций, то есть руководящих принципов или советов для широкой аудитории. Если вы будете следовать им, то в противном случае вам не будет хуже, а может быть, даже лучше. Опять же, они суровы, что, кажется, является обычным тоном в сообществе FreeNAS (по крайней мере, если судить по некоторым постерам на форуме). Я думаю, они просто хотят быть в безопасности. Я всегда предпочитал Руководство ZFS Best Practices, потому что он сформулирован довольно нейтрально и просто представляет факты, предоставляя вам решать.
Также интересно, что, согласно документам и форумам FreeNAS, вы умрете ужасной смертью, если осмелитесь запустить систему ZFS для файловых служб с менее чем жалкими 4 ГБ ОЗУ, находясь в списках рассылки OmniOS (или SmartOS, или illumos). или Nexenta, на данный момент не помню) люди тестировали системы с 512 МБ ОЗУ и делились своими предложениями по их настройке. В общем, это было больше о знании деталей, и выбор оставался за каждым человеком, вместо того, чтобы устанавливать правила, которым вы должны следовать.
Со временем эта проблема также станет менее важной, и рекомендации будут меняться, поскольку все больше и больше систем переключаются на ZFS в обычных настольных и серверных версиях. Ubuntu уже сделал это, и другие наверняка последуют. Если через два-три года 80% дистрибутивов будут использовать ZFS или btrfs, большинство из них воля запустить виртуализированный, так что это спорный вопрос.
Что касается альтернатив, вы можете попробовать StarWind Free. Он имеет кэширование RAM и SSD, дополнительную дедупликацию и использует синхронную репликацию для достижения высокой доступности.
Моя единственная жалоба - я не могу использовать SMB Direct с виртуальной машины, потому что в настоящее время используемая мной реализация RDMA имеет некоторые проблемы с SR-IOV. Я надеюсь, что Mellanox скоро выпустит исправление для своих драйверов Windows Server 2012r2 и 2016.
Я не уверен, что вы хотите от нас здесь.
Если я не могу гарантировать, что смогу следовать этим рекомендациям, ...
Если вы не можете гарантировать, что сможете следовать рекомендациям, значит, у вас неподдерживаемая среда, не делайте этого.
Если кто-то говорит: «Конечно, все будет в порядке», а это не то, чего вы ожидаете от этого совета?