zfs и все-все-все

Update 1: Oracle Database Single Instance на ZFS: учимся готовить by Роман Иванов. Отличное и профессиональное дополнение про zfs !

'1-Быстро. 2-Хорошо. 3-Дешево - выберете любые 2 пункта' - эта старая шутка как никогда хорошо подходит к выбору файловой системы для хранения нашей любимой СУБД. Но перед как начать бросаться выбирать, очень многие забывают ....a) о цели, б) и о том, что выбрать удасться только 2 из 3-х пунтков.  Если у нас жесткая OLTP система, которая растет на 100 MB в лучший год - это одно. Если у нас большое  хранилище, дающее вам 1 новый TB за ночь - это совсем другое. Если у нас обычная БД без особых требований по производительности, но вокруг нее сидят отчеты, разработчики, непрерывно требующие копий БД - то нам нужны к сервисы  в виде снимков (snapshots).

 И не удастся найти  однозначное  лучшее решение для таких разных вариантов.  Если люди начинают разговор о выборе ФС без указания задачи - значит они не знают чего хотят. Сорри.

Предположим,  что нам в жизни повезло и у нас Solaris. И какой у  нас тогда есть выбор ?

Во первых - raw device. Это безусловно самый быстрый и дешевый способ  в мире. Отсутствие какого либо интеллекта перекладывает все заботы на СУБД. Подходит для очень нагруженных OLTP, но управлять сотней устройств для DWH очень не удобно. Поменять размер - нельзя. Делать снимки (snapshots)  нужно командой dd  :)) Все руками, все. Без права на  ошибку.  Итого, получаем  пп 1 и  3.

Во вторых - ASM. Поскольку ввод вывод по прежнему идет напрямую к raw устройствам, то это быстро.  Бесплатно для всех ОС. Хорошо ли ? Очень специфичная система хранения, файловая система и снимки (snapshot) придумали к ней только что с пока неизвестной производительностью. Сжирает диски со страшной силой - normal redundancy может защитить только от сбоя одного диска. Если падает - БД лишается доступа к дискам. Но на всех ОС одинакова. Если у Вас туча баз на разных операционках - ставьте ASM, играйте с ее новыми возможностями..Всякие снимки делайте c помощью rman + standby. Зарабатывает пп 1 и 3.

В третьих - ufs. Уже удобно управлять, но уговорить не беспокоиться файловый кэш Solaris совсем не просто, хотят и можно поправив настройки ядра. Я делал - и это помогает. Правда перед этим пришлось узнать что такое файловый кеш операционной системы и как именно он работает.   Direct IO - вам в помощь. Если не DWH.  И все же  ufs все же не самый быстрый вариант в мире, потому как мало у ее настроек и это очень generic вещь.   Итого  у нас пп 2 и 3.

В четвертых - zfs.  Реально смотрится клево, поскольку многое из-того, что было доступно только на NetApp появилось ...просто на x86.  Вот наверно самое короткое объяснение всех сладостей.  Одно из основных для нас - снимки (snapshot). Zfs их делает в манере copy-on-write, т.е. создает новый блок (точнее extent) только при попытке его изменения. Но  на мой взгляд правильная практика - держите снимков так мало, как только можете. Один или два. Сделав backup - удаляйте. Консультант из NetApp лет 5 назад рассказывал мне историю, что однажды у его клиента легла систем. Когда его вызвали, оказалась что там было чуть ли не 250 снимков одновременно. Когда он спросил зачем столько, оказалось что ...клиент просто забыл, что они делаются у него из крона...

Перед использованием - учитесь правильно готовить, по крайне мере поставить правильный размер блока  и отключить check суммы (zfs set checksum=off filesystem) можно догадаться.  Конечно zfs должна быть быстрее ufs в первую очередь за счет кэша, т.е. для приложений которые много читают. К тому же можно легко делать разные ФС с разными политика (datafiles, redo logs). В общем, достать производительность можно, было бы желание. Конечно, приблизиться  к raw удаться вряд ли.

Теперь о фрагментации zfs - читать тут. Простыми словами:  zfs все пишет/читает эктентами по 128k, которые держит в своих разных виртуальных пулах.  Т.е. все что вы туда положили сразу дефрагментировано. Если вы что-то меняете, zfs старательно накапливает в памяти и только потом сбрасывает. Для нее создать новый extent - как нечего делать. Как правильно замучить zfs?  Начать менять Менять по 1 байту всю базу со смещением 128K и сделать как больше снимков, штук 100. Загнется очень быстро, как пить дать. Кстати, так еще и производительность будет хуже чем у ufs. Потом пойти на sql.ru и написать об этом.   Zfs заработывает пп 2 и 3.

В пятых  - Veritas FS (+Volume Manager). Возможностей море. С реализацией Oracle Disk Manager догоняет raw устройства. Ей можно сказать сделать 100Gb датафайл и ...не пройдет секунды как получите ответ,  что готово. Сервис по снимкам (snapshot)  лучший в мире. Используется в самых нагруженных инсталляциях в мире. Зарабатывает пп 1 и 2, потому как просто стоит денег. Но это всего лишь деньги, не так ли ?

Для безденежных донов,  на Solaris, на мой взгляд остается только два выбора - ASM и zfs. Смотрим на первую фразу в этом сообщении, делаем свой выбор. Еще раз, пожалуйста обратите внимание, надо знать что делает приложение, и только тогда можно выбрать наиболее подходящую файловую систему. Я так думаю.

PS Иногда мне делают замечания в комментариях по стилю или правилам русского языка.  Большое спасибо, я вношу исправления, но не всегда их публикую, если они не относятся к теме поста, чтоба не засорять блог. В любом случае - большое спасибо. Опубликовать такое замечание можно даже анонимно,  если у Вас нет google account.