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