ZFS — файловая система и менеджер томов в одном. Она сама собирает массив из дисков, сама считает контрольные суммы каждого блока и умеет мгновенные снимки. В связке с Proxmox это стандартный выбор для узла виртуализации, и в этой статье разберём, как её собирать и чего не делать.
Чем ZFS отличается от привычного RAID
Классическая схема — аппаратный контроллер собирает массив, поверх него живёт ext4 или xfs. Проблема в том, что контроллер знает про блоки, но не знает про данные: если диск вернул не то, что записывали, массив об этом не догадается. Это называется тихой порчей данных, и на дисках большого объёма она встречается чаще, чем принято думать.
ZFS устроена иначе. Она сама управляет дисками и хранит контрольную сумму каждого блока отдельно от самого блока. При чтении сумма сверяется; если данные повреждены, а в массиве есть избыточность, ZFS восстанавливает правильную копию и чинит битую — прозрачно для приложений.
Из той же архитектуры вытекает остальное: снимки за доли секунды, клоны, сжатие на лету, репликация на другой узел, проверка всего массива по расписанию.
Как устроен пул
Диски объединяются в группы, группы — в пул. Ёмкость и надёжность пула определяются тем, как собраны группы:
- Зеркало — данные пишутся на два (или больше) диска целиком. Половина ёмкости уходит на избыточность, зато высокая скорость случайного чтения и быстрое восстановление после замены диска.
- RAIDZ1 — одна контрольная сумма на группу, переживает отказ одного диска. Экономнее по объёму, но медленнее на случайной записи.
- RAIDZ2 — переживает отказ двух дисков. Разумный выбор для больших дисков: восстановление массива из дисков по 8–16 ТБ идёт долго, и второй отказ в это время — реальный сценарий.
- Полосы без избыточности — быстро и вместительно, но отказ любого диска уносит весь пул. Только под данные, которые не жалко.
Важное правило: пул выдерживает столько отказов, сколько выдерживает самая слабая группа в нём. Пул из двух зеркал переживёт по одному диску в каждом, но не два в одном зеркале.
Для узла виртуализации под виртуальные машины почти всегда правильный ответ — зеркала: у них лучше поведение под случайной нагрузкой, а именно такую нагрузку дают базы данных и файлы виртуальных дисков. RAIDZ уместнее под архивы и резервные копии.
Чего ZFS не прощает
Список короткий, но нарушение каждого пункта рано или поздно оборачивается инцидентом:
- Аппаратный RAID под ZFS. Контроллер прячет диски и подменяет их своей абстракцией — ZFS теряет возможность чинить данные и понимать, какой диск сбоит. Контроллер переводится в режим HBA либо меняется на простой адаптер.
- Мало памяти. ZFS держит кэш в оперативной памяти, и от его размера напрямую зависит скорость. Считайте память отдельно на кэш файловой системы и отдельно на виртуальные машины, а не «сколько останется».
- Забитый пул. При заполнении выше 80–85 % запись резко замедляется: файловая система копирует при записи и ей нужно свободное место для манёвра. Планируйте объём с запасом, следите за заполнением.
- Дешёвые SSD там, где нужна синхронная запись. Бытовые накопители без защиты от потери питания на такой нагрузке ведут себя непредсказуемо и медленно.
- Расширение «на ходу». Добавить диски в существующую группу RAIDZ исторически было нельзя; проще заранее заложить нужную конфигурацию или расширять пул целыми новыми группами.
Настройки, которые действительно влияют
ZFS предлагает десятки параметров, но на практике решают несколько:
- Сжатие включать почти всегда. Современный алгоритм по умолчанию работает быстрее, чем диск успевает читать, — вы одновременно экономите место и выигрываете в скорости.
- Размер блока под диски виртуальных машин: слишком мелкий раздувает накладные расходы, слишком крупный заставляет читать лишнее при мелких операциях. Значение подбирается под характер нагрузки, и сменить его для уже созданного набора данных нельзя — только пересоздать.
- Физический размер сектора задаётся при создании пула и потом не меняется. Ошибка здесь стоит производительности навсегда.
- Ограничение размера кэша. На узле виртуализации имеет смысл явно ограничить аппетит ZFS, чтобы память гарантированно осталась виртуальным машинам.
- Дедупликация — почти всегда нет. Она требует огромной памяти и в типовой инфраструктуре даёт меньше выигрыша, чем обычное сжатие.
Снимки — это не резервные копии
Снимок ZFS делается мгновенно и почти не занимает места: фиксируется состояние данных на момент времени, а место расходуется только на изменения. Это отличная страховка перед обновлением 1С или установкой пакетов — откат занимает секунды.
Но снимок живёт в том же пуле, что и данные. Сгорит массив, откажет контроллер, зашифрует всё вредонос с правами администратора узла — снимки уйдут вместе с данными. Поэтому схема всегда двухуровневая: снимки для быстрого отката, отдельное хранилище резервных копий — для настоящего восстановления. Как это устроено в Proxmox, разбираем в статье про настройку Proxmox.
Репликация на второй узел
Сильная сторона ZFS в кластере — отправка разницы между снимками на другой узел. Первый раз уезжает весь набор данных, дальше — только изменения с прошлого раза, поэтому репликация каждые несколько минут по обычной сети вполне реальна.
Это даёт недорогую отказоустойчивость без общего хранилища: на втором узле лежит копия машины, отставшая на интервал репликации. При отказе первого узла машина запускается на втором, потеряв изменения за этот интервал. Не замена синхронной репликации, но для большинства задач малого и среднего бизнеса разумный компромисс по цене.
Обслуживание: что делать регулярно
- Проверка массива по расписанию — ZFS перечитывает все данные и сверяет контрольные суммы, находя порчу до того, как вы наткнётесь на неё при восстановлении. Раз в месяц, в нерабочее время.
- Мониторинг состояния пула и счётчиков ошибок. Диск редко умирает мгновенно — сначала растут ошибки чтения. Уведомления должны приходить человеку.
- Контроль заполнения с порогом тревоги на 75–80 %.
- Чистка старых снимков. Забытые снимки незаметно съедают пул: пока снимок жив, удалённые данные занимают место.
- Проверка запасных дисков и наличие подменного диска под рукой — восстановление начинается тем быстрее, чем меньше ждать поставку.
ZFS и 1С
Для сервера с 1С важна не общая пропускная способность, а поведение на мелких случайных операциях и на синхронной записи журналов СУБД. Практические ориентиры: зеркала вместо RAIDZ, SSD корпоративного класса, достаточный объём памяти под кэш, аккуратно подобранный размер блока под наборы данных с базами и сжатие.
Снимки перед обновлением конфигурации 1С экономят нервы отдельно: если релиз лёг неудачно, откат занимает минуту вместо разворачивания копии. Про то, где ещё прячутся тормоза, — в разборе почему 1С тормозит на сервере.
Когда ZFS не нужна
Честный список: если под вами уже стоит внешняя система хранения со своей избыточностью и снимками — второй слой не нужен. Если сервер один, дисков два и всё, что требуется, — простая надёжность, обычного зеркала хватит и без тонкой настройки. Если памяти в сервере мало и добавить её нельзя — ZFS будет работать хуже, чем ext4 на аппаратном RAID.
Соберём и будем сопровождать
Мы проектируем дисковую подсистему под задачу: считаем нагрузку, выбираем схему пула и диски, настраиваем снимки, репликацию и резервное копирование, ставим мониторинг с уведомлениями. Дальше сопровождаем — проверки массива, замена дисков, контроль места, восстановление при инцидентах. Работаем на оборудовании клиента и на своей площадке.
Стоимость считаем под конкретную конфигурацию после обследования. Подробности — на странице настройка и сопровождение кластера Proxmox, телефон +7 495 780-66-50.
