Культ ZFS

В IT-кругах довольно распространено появление некоего культоподобного или фанбойского менталитета. Что вызывает такую реакцию на технологии и продукты, я не вполне уверен, но то, что это происходит, — неоспоримо. Одна из областей, где, как я никогда не ожидал, это случится, — это область файловых систем — одного из наиболее «скрытых» компонентов системы, который до недавнего времени практически не привлекал внимания даже в достаточно технических кругах. Признаем: непонимание того, что именно относится к Active Directory, а что — к NTFS, встречается повсеместно. Файловые системы попросту игнорируются. С тех пор как вышла Windows NT 4 и NTFS стала единственным жизнеспособным вариантом, идея о том, что файловая система не является неотъемлемым компонентом операционной системы и что для хранения файлов могут существовать другие варианты, практически исчезла. То есть до недавнего времени.

Единственным сообществом, где в определённой мере этого не произошло, было сообщество Linux, однако даже там Ext2 и его потомки настолько доминировали, что, хотя альтернативные файловые системы и были широко доступны, они оставались на второстепенных ролях, и исторически лишь XFS получала какое-то внимание, да и то весьма незначительное.

Некоторые действительно странные явления в последнее время происходят вокруг файловой системы ZFS от Oracle, изначально разработанной для операционной системы Solaris и платформы открытого хранилища X4500 «Thumper» (первоначально под началом Sun до поглощения Oracle). В то время (девять лет назад), когда вышла ZFS, конкурирующие файловые системы в основном не были готовы к работе с большими дисковыми массивами, которые ожидались в ближайшие годы. ZFS была спроектирована для работы с ними и ознаменовала начало эпохи крупномасштабных файловых систем. Как и большинство файловых систем того времени, ZFS была ограничена одной операционной системой, и поэтому, несмотря на широкое признание как значительного шага вперёд в проектировании файловых систем, она произвела мало ряби в мире хранения данных и ещё меньше — в «системном» мире, где даже администраторы Solaris в течение довольно долгого времени считали её лишь интересной точкой, в основном предпочитая оставаться с проверенной и надёжной UFS, которую они использовали многие годы.

ZFS была, по-настоящему, революционной файловой системой, и я был и остаюсь её большим сторонником. Но очень важно понимать, почему ZFS делала то, что делала, каковы её цели, почему эти цели были важны и как это применимо к нам сегодня. Сложность ZFS привела к значительной путанице и недопониманию того, как работает эта файловая система и когда её уместно использовать.

Основные цели ZFS состояли в создании файловой системы, способной хорошо масштабироваться на очень большие дисковые массивы. В момент своего появления масштаб, которого была способна достичь ZFS, был беспрецедентным для других файловых систем, но реальной потребности в том, чтобы файловая система могла вырасти до таких размеров, не существовало. К тому времени, когда эта потребность возникла, многие другие файловые системы, такие как NTFS, XFS, Ext3 и другие, также масштабировались, чтобы удовлетворить эту потребность. ZFS, безусловно, возглавила движение к работе с более крупными файловыми системами, однако вскоре к ней присоединились многие другие.

Поскольку ZFS возникла в мире Solaris, где, как и во всех мощных UNIX-системах, аппаратный RAID отсутствует, приходилось использовать программный RAID. В Solaris всегда был доступен программный RAID в виде отдельной подсистемы. Было принято решение встроить новую реализацию программного RAID непосредственно в ZFS. Это позволило бы упростить управление с помощью единого набора инструментов как для уровня RAID, так и для файловой системы. Это не внесло существенных изменений или преимуществ в ZFS, как это принято считать, — оно просто перенесло интерфейс для уровня программного RAID из собственного набора команд в набор команд ZFS.

Реализация RAID в ZFS ввела полосы переменной ширины в уровнях RAID с контролем чётности. Это нововведение устранило незначительный риск RAID с чётностью, известный как «дыра записи» (write hole). Это нововведение было весьма приятным, но пришло с большим опозданием, поскольку эра надёжного RAID с чётностью начинала заканчиваться, а проблема дыры записи уже считалась упомянутым «фоновым шумом» риска массивов с чётностью, поскольку в целом не рассматривалась как угроза благодаря её устранению посредством использования кешей массивов с резервным питанием от батарей и, примерно в то же время, энергонезависимых кешей массивов — избегайте потери питания, и вы избегаете дыры записи. ZFS нужно было решить эту проблему, потому что как программный RAID она была подвержена большему риску дыры записи, чем аппаратный RAID, поскольку нет возможности защитить кеш от потери питания — аппаратный RAID предлагает потенциал для дополнительного уровня защиты питания для массивов.

Настоящей «инновацией», которую ZFS непреднамеренно совершила, было то, что вместо простой реализации обычных уровней RAID 1, 5, 6 и 10 она «переименовала» эти уровни, введя собственные соглашения об именовании. RAID 5 известен как RAIDZ. RAID 6 известен как RAIDZ2. RAID 1 просто известен как зеркалирование. И так далее. В своё время это широко считалось нелепым и бессмысленно запутанным, однако, как оказалось, именно эта путаница стала краеугольным камнем возрождения ZFS много лет спустя.

Следует отметить, что ZFS впоследствии добавила первую в отрасли промышленную реализацию RAID 7 (известного также как RAID 7.3) — тройного паритетного RAID-массива — и назвала его RAIDZ3. Это более позднее дополнение является важной инновацией для крупномасштабных массивов, которым нужна максимальная ёмкость при сохранении исключительной надёжности, но которые готовы пожертвовать производительностью ради этого. Это остаётся уникальной функцией ZFS, но используется редко.

В духе объединения стека хранения и использования единого набора команд для управления всеми аспектами хранения в ZFS также были интегрированы функции управления логическими томами. В некоторых кругах ошибочно считается, что ZFS ввела управление логическими томами, однако практически все корпоративные платформы, включая AIX, Linux, Windows и даже сам Solaris, имели управление логическими томами уже много лет. ZFS делала это не для введения новой парадигмы, а лишь для консолидации управления и объединения всех трёх ключевых уровней хранения (RAID, управление логическими томами и файловая система) в единую сущность, которой было бы проще управлять и которая могла бы обеспечить встроенную коммуникацию вверх и вниз по стеку. У этого метода есть свои плюсы и минусы, и отраслевое мнение остаётся несформированным почти десятилетие спустя.

Одним из наиболее важных аспектов этого объединения трёх систем в одну является то, что теперь мы имеем весьма запутанный для обсуждения продукт. ZFS — это файловая система, да, но не только файловая система. Это менеджер логических томов, но не только менеджер логических томов. Люди называют ZFS файловой системой — что является её основной функцией, — но то, что она является гораздо большим, чем просто файловая система, может вызывать большую путаницу и затруднять сравнение с другими системами хранения. Полагаю, в то время это замешательство не было предвидено.

Результатом этого запутанного слияния стало то, что ZFS нередко сравнивают с другими файловыми системами, такими как XFS или Ext4. Но это вносит путаницу, поскольку ZFS представляет собой полный стек, а XFS — лишь один аспект стека. ZFS лучше было бы сравнивать с MD (программный RAID Linux) / LVM / XFS или со SmartArray (аппаратный RAID HP) / LVM / XFS, нежели с одной только XFS. В противном случае кажется, что ZFS полна функций, которых лишена XFS, однако в действительности это лишь семантическая победа. Большинство функций, которые часто рекламируют сторонники ZFS, не были изобретены ZFS и были широко доступны в альтернативных файловых системах задолго до появления ZFS. Но трудно сравнивать, отвечая на вопрос «умеет ли ваша файловая система это?», поскольку ответ будет звучать как «нет... это делает мой RAID или мой менеджер логических томов». И по-настоящему это не ZFS-файловая система предоставляет RAIDZ — это ZFS-подсистема программного RAID делает это.

Для корректной работы с очень большими файловыми системами в ZFS были встроены функции целостности данных, включая контрольную сумму или хеш-проверку по всей файловой системе, которая могла задействовать встроенный программный RAID для восстановления повреждённых файлов. Это было признано необходимым ввиду предполагаемого размера файловых систем ZFS в будущем. Повреждение файловой системы — редко встречающееся явление, но по мере роста файловых систем риск возрастает. Эта менее известная функция ZFS, возможно, является её наибольшим достоинством.

ZFS также изменила подход к проверкам файловой системы. Из-за предположения, что ZFS будет использоваться на очень больших файловых системах, существовали реальные опасения, что проверка файловой системы при загрузке может занять невозможно долгое время, поэтому была найдена альтернативная стратегия. Вместо того чтобы ждать проверки при перезагрузке, системе требуется выполнение процесса скрабирования, выполняющего аналогичную проверку во время работы системы. Это требует больших системных накладных расходов при работающей системе, однако система способна быстрее восстановиться после непредвиденного перезапуска. Компромисс, который в целом оценивается весьма положительно.

ZFS обладает мощными возможностями создания снимков в своём уровне логических томов, а в уровне RAID реализованы очень надёжные механизмы кеширования, что делает ZFS отличным выбором для многих сценариев использования. Эти функции не уникальны для ZFS, но широко доступны в системах, более старых, чем ZFS. Тем не менее это очень хорошие реализации каждой из них, и они очень хорошо интегрированы благодаря природе ZFS.

В своё время ZFS была открытым исходным кодом, и в тот период её код стал частью операционных систем Apple Mac OS X и FreeBSD, поскольку они были совместимы с лицензией ZFS. Linux не получил ZFS в то время из-за проблем с лицензированием. Если бы лицензирование ZFS позволяло Linux использовать её без ограничений, ландшафт Linux сегодня, вероятно, был бы совсем другим. Mac OS X в итоге отказалась от ZFS, поскольку она не имела достаточных преимуществ для обоснования её использования в этой среде. FreeBSD продолжила использовать ZFS, и со временем она стала наиболее популярной файловой системой на этой платформе, хотя UFS по-прежнему широко используется. Oracle закрыла исходный код ZFS после приобретения Sun, оставив FreeBSD без дальнейших обновлений своей версии ZFS, в то время как Oracle продолжала разрабатывать ZFS внутри компании для Solaris.

Сегодня Solaris продолжает использовать исходную реализацию ZFS, теперь с несколькими обновлениями с момента её разрыва с сообществом открытого исходного кода. FreeBSD и другие продолжали использовать ZFS в том состоянии, в каком она находилась, когда исходный код был закрыт, больше не имея доступа к последним обновлениям Oracle. В конечном итоге работа по обновлению заброшенной кодовой базы ZFS с открытым исходным кодом была возобновлена и теперь известна как OpenZFS. OpenZFS ещё находится на стадии становления и пока не проявила себя в полной мере, однако имеет определённый потенциал для возрождения платформы ZFS в пространстве открытого исходного кода, но на данный момент OpenZFS всё ещё отстаёт от ZFS.

Разработка открытого исходного кода в этой области в последние несколько лет сосредоточена в основном на новом конкуренте ZFS — BtrFS, которая разрабатывается нативно на Linux и хорошо поддерживается многими крупными поставщиками операционных систем. BtrFS ещё очень молода, но делает значительные успехи в достижении паритета функций с ZFS в реализованных возможностях, при этом имея большие амбиции и, благодаря закрытому исходному коду ZFS, преимущество рыночного момента. BtrFS была начата, как и ZFS, компанией Oracle и широко считается взглядом Oracle на будущее как замена ZFS даже у самой Oracle. На данный момент BtrFS уже, как и ZFS, объединила файловую систему, управление логическими томами и уровни программного RAID, реализовала контрольные суммы для целостности файловой системы, масштабируется даже крупнее, чем ZFS (тот же абсолютный предел, но работает с большим количеством файлов), снимки с копированием при записи и т. д.

ZFS, без сомнения, была удивительной файловой системой в свои лучшие времена и остаётся лидером сегодня. Я был её сторонником в 2005 году и по-прежнему сильно в неё верю. Но меня огорчает то, что сообщество вокруг ZFS приобрело рвение и фанатизм, которые не служат ей и делают упоминание ZFS почти негативным — ZFS повсеместно выбирается по неправильным причинам: прежде всего из убеждения, что её функции не существуют больше нигде, что её RAID не подвержен рискам и ограничениям, которым эти уровни RAID всегда подвержены, или что она была спроектирована для иной цели (главным образом производительности), нежели та, для которой она действительно разрабатывалась. И когда ZFS является правильным выбором, она нередко реализуется неправильно, исходя из ложных предположений.

В ZFS, конечно, нет никакой вины. Нет её, насколько я могу судить, и у корпоративных сторонников или разработчиков открытого исходного кода. ZFS, похоже, пошла не туда из-за неформального, неофициального сообщества, которое лишь недавно познакомилось с ZFS, нередко считая её новой или «следующего поколения», поскольку лишь недавно её открыло. По моим наблюдениям, это происходит почти никогда не через каналы Solaris или FreeBSD, а почти исключительно среди небольших компаний, желающих использовать упакованную «NAS OS», такую как FreeNAS или NAS4Free, и не знакомых с UNIX-ОС. Использование упакованных NAS-ОС, преимущественно IT-подразделениями, не обладающими ни глубокими знаниями UNIX, ни знаниями в области хранения данных и, соответственно, практически не знакомыми с более широким миром файловых систем за пределами Windows, а нередко почти без опыта работы с управлением логическими томами и RAID, особенно с программным RAID, по-видимому, порождает культуру «мифов» вокруг ZFS, наделяя её практически неоспоримым, непогрешимым статусом.

Этот культоподобный фанатизм и общее непонимание ZFS нередко ведут к неправильному применению ZFS или к цепочке решений, основанных на ложных предположениях, которые могут завести очень далеко не туда.

Одним из наиболее удивительных изменений в этой области является переход от аппаратного RAID к программному. Традиционно программный RAID был изгоем в кругах администрирования Windows без веских оснований — администраторы Windows и малый бизнес, нередко незнакомые с более крупными UNIX-серверами, считали аппаратный RAID повсеместным, тогда как на самом деле более крупные системы всегда использовали программный RAID. Аппаратный RAID практически повсеместно считался необходимостью, а программный RAID полностью отвергался. Та же аудитория, столкнувшись теперь с движением «Культа ZFS», реагирует прямо противоположным образом, полагая, что аппаратный RAID плох, а программный RAID ZFS — единственный жизнеспособный вариант. Этот сдвиг разителен, и ни один из подходов не является обоснованным — как аппаратный, так и программный RAID, и оба во многих реализациях являются вполне допустимыми вариантами, и даже при использовании ZFS применение аппаратного RAID вполне может быть уместным.

ZFS нередко выбирается потому, что считается вариантом с наивысшей производительностью среди файловых систем, однако это никогда не было ключевой целью проектирования ZFS. Возможности, позволяющие ей масштабироваться до столь больших объёмов и работать с многими различными аспектами хранения, на самом деле существенно затрудняют достижение высокой производительности. ZFS в момент своего создания даже не ожидалась как более быстрая, чем почтенная UFS, работавшая на тех же системах. Впрочем, это нередко вторично по отношению к тому факту, что производительность файловой системы в целом несущественна, поскольку все современные файловые системы исключительно быстры и скорость файловой системы редко является важным фактором — особенно за пределами массивных, высококлассных систем хранения в очень крупном масштабе.

Интересное исследование десяти файловых систем в Linux, проведённое Phoronix в 2013 году, показало огромные различия между файловыми системами в зависимости от рабочей нагрузки, но явных победителей с точки зрения общей производительности не выявило. Исследование убедительно показало, что соответствие рабочей нагрузки файловой системе является наиболее важным выбором, что ZFS относится к более медленной стороне всех основных файловых систем даже в более современных реализациях, и что выбор файловой системы по соображениям производительности без очень глубокого понимания рабочей нагрузки приведёт к непредсказуемой производительности — ни одну файловую систему не следует выбирать вслепую, если производительность является важным фактором. К сожалению, поскольку тест проводился на Linux, в нём отсутствовала UFS, которая является главным конкурентом ZFS, особенно на Solaris и FreeBSD, а также HFS+ от Mac OS X.

Переход с аппаратного RAID на программный несёт дополнительные, нередко непредвиденные риски для подразделений, не имеющих опыта работы с UNIX. Хотя ZFS позволяет горячую замену, нередко забывается, что горячая замена прежде всего является функцией аппаратного обеспечения, а не программного, и также широко неизвестно, что «слепая» замена (извлечение жёстких дисков без предварительного отключения их в операционной системе) не является синонимом горячей замены, и это может привести к катастрофам для подразделений, переходящих от традиции аппаратного RAID, который прозрачно обрабатывал совместимость, горячую замену и слепую замену, к системе программного RAID, которая требует значительно большего планирования, координации и понимания системы для безопасного использования.

Менее распространённое, но всё же частое заблуждение относительно ZFS состоит в том, что это кластерная файловая система, пригодная для использования в сценариях с общим DAS или SAN наподобие OCFS, VxFS и GFS2. ZFS не является кластерной файловой системой и имеет те же ограничения в этой области, что и все её распространённые конкуренты.

ZFS может быть отличным выбором, но она далеко не единственный вариант. ZFS сопровождается существенными оговорками, не последней из которых являются ограничения операционной системы, связанные с ней, и хотя у неё есть множество преимуществ, мало какое из них, если вообще хоть одно, уникально для ZFS, и крайне редко какое-либо подразделение извлечёт пользу из каждого из них. Как и с любой технологией, необходимо идти на компромиссы. Один размер не подходит для всех. Ключ к пониманию того, когда ZFS подходит именно вам, — это понять, что такое ZFS, что в ней уникально, а что нет, каковы её цели проектирования, как сравнение хранилища с чистой файловой системой даёт вводящие в заблуждение результаты и какие присущие ей ограничения с ней связаны.

ZFS — ключевое рассмотрение и распространённый выбор, когда в качестве операционной системы выбраны Solaris или FreeBSD. За редким исключением, операционная система никогда не должна выбираться ради ZFS, но вместо этого ZFS нередко, хотя и не всегда, следует выбирать, когда уже выбрана операционная система. Операционная система должна определять выбор файловой системы во всех, кроме самых редких, случаев. Выбор операционной системы несравнимо более важен, чем выбор файловой системы.

ZFS можно использовать на Linux, но она не считается корпоративным вариантом там, а скорее хобби-системой для экспериментов, поскольку ни один корпоративный вендор (такой как Red Hat, Suse или Canonical) не поддерживает ZFS на Linux, а у Linux уже есть отличные альтернативы. Когда-нибудь ZFS, возможно, будет повышена до статуса файловой системы первого класса в Linux, однако это маловероятно, поскольку BtrFS уже вошла в основное ядро и включена в производственные выпуски несколькими крупными вендорами.

Хотя ZFS будет встречаться в подавляющем большинстве развёртываний Solaris и FreeBSD, это обусловлено прежде всего тем, что она заняла позицию файловой системы по умолчанию, а не тем, что она явно является лучшим выбором в этих случаях или даже была критически оценена. ZFS вполне пригодна как файловая система общего назначения там, где она нативна и поддерживается.

Каков основной сценарий использования ZFS?

Цель проектирования и основной сценарий использования ZFS — это открытые системы хранения на базе Solaris и FreeBSD, предоставляющие либо общее хранилище другим серверам, либо являющиеся массивными репозиториями данных для локально установленных приложений. В этих случаях ориентация ZFS на масштабируемость и целостность данных действительно проявляется во всей красе. ZFS тяготеет к крупным и корпоративным масштабам и в целом менее применима в сегменте малого и среднего бизнеса, где навыки работы с Solaris и FreeBSD, а также потребности в хранении данных большого масштаба встречаются редко.

Ссылка: http://www.phoronix.com/scan.php?page=article&item=linux_310_10fs&num=1