ZFS на одном виртуальном диске
- Как компании управляют большими файловыми серверами (например, 17 ТБ) и связанными с ними резервное копирование при очень ограниченном бюджете?
- Можно ли использовать ZFS (или BTRFS) на одном виртуальном диске из-за его характера копирования при записи, чтобы исключить необходимость в fsck? (т.е. не для его функций RAID, моментальных снимков и т. д.)
Конкретная ситуация:
Нам нужно убрать старую проблемную систему хранения, которая обслуживала хранилище NFS для виртуальных машин и все еще является нашим основным файловым сервером. Теперь у меня есть новая система хранения на базе iSCSI FreeNAS 40 ТБ, и я уже перевел все виртуальные машины из старого хранилища в новое с помощью vMotion, но остались 17 ТБ общих файлов SMB / CIFS и AFP.
Резервное копирование выполняется через rsync, который требует слишком долго сканировать 17 ТБ, поэтому мы разделили на два тома:
- 13 ТБ на «архивном» томе только для чтения для файлов, которые не были доработан за год. Для резервного копирования мы просто делаем на месте и за его пределами копии с использованием rsync - нет необходимости в ежедневных версиях резервных копий.
- 4 ТБ хранилища с возможностью записи в реальном времени. Он ежедневно создается с помощью rsync и использует жесткие ссылки для создания «снимков» / версий состояния файловый сервер в этот день, чтобы мы могли восстановить перезаписанные файлы.
ИТ-персонал перемещает файлы из архива в оперативные, когда требуются изменения, но теперь эти запросы выполняются несколько раз в день и больше не принимаются.
Исходный план:
- Создать виртуальный файловый сервер Linux.
- Создайте 2 виртуальных диска в нашей новой системе хранения 40 ТБ. (13 ТБ в архиве + 4 ТБ в реальном времени с возможностью записи)
- Форматирование указанных выше дисков с файловыми системами ext4
- Используйте UnionFS с опцией монтирования коровы, чтобы предоставить пользователям единое унифицированное представление указанных выше файловых систем, при этом все записи будут выполняться на 4 ТБ с возможностью записи system.
Проблемы с исходным планом:
- Мы перерастаем файловую природу rsync в качестве инструмента резервного копирования, например, переименование папки верхнего уровня размером 1 ТБ приводит к созданию полностью новой копии всей папки размером 1 ТБ. Это добавит всего несколько КБ к резервной копии на основе блоков. Представьте себе инцидент утром в понедельник, требующий перезапуска и принудительной установки fsck при загрузке или, что еще хуже, повреждения файловой системы!
Альтернативный план 2: файловая система ZFS / BTRFS на сервере Linux
- Согласно альтернативному плану 1, но используйте файловая система с копированием при записи, такая как ZFS или BTRFS вместо ext4, потому что для них не требуется fsck.
Вопросы / проблемы для альтернативного плана 2:
- И ZFS, и BTRFS требуют прямого доступа к необработанным дискам для реализации их собственный RAID и поэтому обычно не используются на виртуальных дисках. Насколько хорошо это будет работать на одном виртуальном диске?
Альтернативный план 3: FreeNAS напрямую в качестве файлового сервера
- Вместо того, чтобы иметь отдельный виртуальный файловый сервер, делитесь файлами напрямую из FreeNAS
Проблема с альтернативным планом 3:
- Нам необходимо установить различные пакеты и пользовательские сценарии perl / bash / python, чтобы интегрировать этот файловый сервер с нашей системой отслеживания заданий. Это будет нормально для обычного Linux, но я не думаю, что это хорошая идея для предварительно упакованной системы хранения ZFS на базе FreeBSD (FreeNAS). Обновления могут перезаписать наши изменения и т. Д.
Вопросы:
- Альтернативный план 2 - ZFS на одном виртуальном диске - хорошая идея? Если нет, то почему?
- Кто-нибудь может предложить лучшие варианты?
Как компании управляют большими файловыми серверами (например, 17 ТБ) и связанными с ними резервными копиями в очень жестком бюджете?
Это зависит от производительности и бюджетных ограничений. Например, Backblaze (компания по созданию резервных копий в облаке) имеет очень жесткий бюджет для каждого ТБ, но им не нужна максимальная производительность или время отклика для данных. Некоторым другим компаниям может понадобиться дешевая производительность, но они находят способ уменьшить объем необходимых данных (с помощью дедупликации, обрезки старых данных резервного копирования или просто уменьшения объема фактических данных, которые могут не понадобиться бизнесу)
Можно ли использовать ZFS (или BTRFS) на одном виртуальном диске для копирования на запись, чтобы избавиться от необходимости использования fsck? (т.е. не для его RAID, snapshot и т.д.)
Я бы не стал использовать BTRFS ни для чего не разрабатываемого, где в качестве первого принципа необходимо доверять безопасности данных. Я бы использовал ZFS, потому что не нашел более дешевой и безопасной альтернативы (другие ФС со схожими возможностями от IBM, NetApp и т.д. дороже, другие бесплатные файловые системы либо не зрелые (HAMMER2, BTRFS), либо не имеют существенных возможностей (ext2/3/4, reiserfs и т.д.)
Ваши конкретные ответы: Я бы предпочел план 3, но план 2 тоже сработает.
В отличие от большого количества FUD, плавающих по сети, ZFS не заботится о базовом хранилище, будь то физическое, виртуальное или смешанное. Конечно, оно может быть только хорошим/быстрым/безопасным, как базовое хранилище, и может только рассуждать о том, что дано. Это означает, что ваша производительность будет не такой хорошей, как у родной, ваша диагностика включает оба уровня, и оба уровня могут иметь проблемы. Если вы знаете об этом и об обеспечении этих недостатков, я рассматриваю это как реальную альтернативу.
У вас все еще есть такие удобные функции, как send/recv, snapshots, CoW, контрольные суммы и дедупликация на уровне блоков. Чем вы жертвуете, так это в основном производительностью и, возможно, безопасностью (если, например, ваша SAN - всего лишь один диск). Вы также должны настроить размер вашего ZFS сектора (ashift) на ваше базовое хранилище при создании пула. После этого вы можете иметь разные размеры для отдельных файловых систем, но настройка пула не может быть изменена без его уничтожения.
Но сначала я бы тщательно оценил, является ли перезапись этих скриптов и интеграций столь же трудоемкой, как вы себе представляете. Также, даже такие устройства, как FreeNAS (или napp-it, чтобы назвать альтернативу), обычно имеют пользовательские сценарии или определяемые пользователем плагины или модули, которые выживают при обновлении и хорошо работают с устройством (новая FreeNAS 10 aka Corral заменила свою архитектуру плагинов на Docker, если это то, что вам знакомо, может быть альтернативой)
.