Назад | Перейти на главную страницу

Хранение и резервное копирование 200 миллионов небольших файлов

Мой диск - 10x1TB SAS 7200 RPM в RAID 10 с аппаратным контроллером MegaRaid 9260 с кешем / BBU. В результате получается том RAID 10 объемом 4,6 ТБ. hdparm -t (когда устройство пусто) приводит к 500 МБ / с.

Размер блока RAID составляет 64 КБ, размер блока файловой системы - 2 КБ (я собираюсь изменить его на минимальный размер блока и размер блока 4 КБ).

Шаблон каталога: /data/x/yz/zyxabc.gz

Я использую EXT4 и планирую перейти на XFS. Операционная система - RHEL 6.


На данный момент он отлично работает. Рабочая нагрузка составляет 99% операций чтения, и при нормальных условиях он может читать до 300 файлов в секунду. Проблема в резервных копиях. Резервное копирование с помощью scp занимает 6 дней. rsync работает еще медленнее. DD идет со скоростью около 2 МБ / с. Снимки LVM могут быть вариантом, если я сделаю снимок, сделаю резервную копию, а затем удалю. Для меня очень важна согласованность данных.

Размер каждого файла составляет около 0,5–4 КБ. Увижу ли я повышение производительности резервного копирования, если вместо этого сохраню все файлы в базе данных? Какие еще есть альтернативы для решения проблемы резервного копирования такого большого количества небольших файлов в разумном окне?

Вы рассматривали такие решения, как АМАНДА или Bacula?

я планирую перейти на XFS

В таком случае вам лучше предварительно заказать тонны Прозака. :-) Увы, XFS плохо справляется с этим шаблоном (много маленьких файлов).

Если вы рассматриваете изменение FS Reiser3 - единственный вариант, который стоит попробовать в этом случае, ИМО. С участием notail вы получаете меньше накладных расходов на ЦП, без notail - меньше накладных расходов на дисковое пространство.

Блок RAID размером 64 КБ тоже выходит за рамки здравого смысла - зачем переполнять очереди дискового ввода-вывода такими крошечными шаблонами? Увеличивайте, а не уменьшайте! При большом количестве одновременных операций ввода-вывода это не повредит.

Теперь, когда дело касается резервного копирования, можно упомянуть COW FS. Например, Btrfs или Nilfs. Снимки LVM-2, возможно, тоже подойдут, так что вы можете попробовать объединить их с переходом на Reiser3. Но я думаю, у COW FS больше шансов дать вам то, что вам нужно.

Либо используйте решение для резервного копирования, которое поддерживает добавочные резервные копии, такие как уже упомянутые, либо, возможно, вы можете использовать сценарий, который просматривает дерево и копирует файлы только с определенным временем изменения?

Я не совсем понимаю, что вы подразумеваете под «мне нужна последовательность». Вы имеете в виду, что для всех файлов необходимо создавать резервные копии в один и тот же момент времени (например, снимок)? В этом случае я не уверен, что какой-либо тип tar, copy, rsync или аналогичный будет работать - вам придется использовать что-то, что может создавать снимки файловой системы или приостанавливать любой процесс, создающий эти файлы в первую очередь.

"DD идет со скоростью около 2 МБ / с"

Я сбит с толку, разве dd не выполняет последовательное (или пытается) чтение устройства? Это конкурирует с использованием этих файлов в Интернете? Если это так, я думаю, что нужно больше дисков / более быстрых дисков. 1 ТБ SAS по-прежнему составляет 7200 об / мин, если я не ошибаюсь, вы можете выбрать SAS 600 ГБ и 15 КБ, что значительно сократит ваши запросы.

Вы сбрасываете его на RAMDisk? Таким образом, ваше место назначения не может быть узким местом теста DD (и вы не сбрасываете его обратно на локальный диск, что снова вызывает высокие запросы).

Если 2 МБ / с - лучшее, что вы собираетесь получить при максимально возможной скорости чтения, вам нужны более быстрые диски.

Однако dd не даст вам последовательного снимка без объединения его с чем-то еще.