Целостность btrfs и Стресс-тестирование
Коллега по DevOps рекомендует, чтобы мы начали переходить наша продуктивная среда к использованию btrfs. У нас есть, прежде всего, ext4 файловые системы, хотя некоторые серверы низкого использования с помощью ZFS (на Linux). Как одно из лиц, принимающих решения, и как одно ответственное за нашу полную среду, я колеблюсь основан на количестве комментариев и статей вокруг btrfs в производстве в сети. Для противостояния тому аргументу, Oracle выпустила их Предприятие Linux с поддержкой btrfs, SLES 12 (https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/) также указывает, что она будет использовать btrfs, и существует доказательство, что компании как Facebook также используют ее в управляемых продуктивных средах.
Существует много аргументов, приведенных относительно того, почему перемещение в это направление (принятие btrfs) будет хорошей вещью, и я соглашаюсь с ними в целом, однако, я хотел бы быть благоразумным, сделать, должная осмотрительность, и получить больше операционного знакомства и часы вошла в систему "маленькое производство" или среда подготовки перед продвижением в более широком масштабе. Есть ли какие-либо инструменты, которые могут помочь мне создать случай - как в стресс-тестировании, сопровождаемом проверками целостности данных или чем-то вдоль тех строк? Кроме не наблюдения операторов как: "Q. Действительно ли btrfs стабилен? Короткий ответ: Нет, это все еще считало экспериментальным". на btrfs Wiki, что еще я могу сделать для получения более теплого нечеткого?
Я уже здесь дал подробный ответ: Готова ли продукция btrfs?
Короче говоря: Btrfs - это ничто, что вам уже нужно на производственном файловом сервере.
Вот причины, по которым: он становится непредсказуемым, если пространство заканчивается, хотя большинство основных функций считается стабильным, другие - нет, и он все еще является быстро движущейся мишенью. Быстро движущаяся мишень означает, что вы всегда должны использовать новейшее и самое большое ядро, а это то, что вам не нужно на сервере.
Также, даже при использовании ядра 3.16, как известно, возникают дедлоки, что, несомненно, является чем-то, чего вы не хотите на производственном сервере (http://marc.merlins.org/perso/btrfs/post_2014-10-05_Btrfs-Tips_-Catch-Btrfs-Deadlocks.html). Также некоторые RAID-массивы все еще экспериментальные, например RAID5/6. Вы можете использовать их, но пока не скрабировать там данные и т.д.
Fedora хочет наконец-то сделать Btrfs, может быть, файловой системой по умолчанию с v23, что произойдет в конце 2015 года. Теперь Red Hat по умолчанию переключилась с Ext4 на XFS.
Если вам действительно нужна готовая к производству файловая система COW, сделайте себе одолжение и возьмите ZFS, либо как ZFS под Linux, либо под FreeBSD.
И прочитайте блог Рассела Кокера о его опыте работы с Btrfs. http://etbe.coker.com.au/
Я бы придерживался основных файловых систем, таких как XFS (как продвигается Red Hat), и полагался бы на ZFS для продвинутых файловых систем.
Это в основном связано с:
- Mindshare: Знания о ZFS хранятся в сообществах Linux, FreeBSD и Solaris/OpenIndiana.
- Maturity: Кодовая база ZFS проверена и существует уже некоторое время. Лучшие практики развивались и я не помню, чтобы видел ужасные истории о потере данных.
- Портативность: Я определенно изменил платформы и сохранил совместимость с ZFS.
Не хватает специфической интеграции с Linux-контейнерами, я не знаю, что сегодня BtrFS предлагает намного больше, чем ZFS . Если у вас есть сомнения по поводу использования BtrFS, прислушайтесь к своему чутью. Не думаю, что я бы поставил на это бизнес, но со временем все может измениться. Оцените свои специфические потребности. Существуют ли в BtrFS убедительные возможности, которыми может воспользоваться ваша среда?
Взгляните на пример Вопросы о неисправностях сервера в BtrFS , чтобы увидеть, с какими проблемами обычно сталкиваются люди.