Первый семинар в рамках SAS IT Battles. Как и о чем
Старт дан, жребий брошен, Рубикон перейден!.. В субботу, 13 февраля, состоялось первое offline-мероприятие в рамках фестиваля информационных технологий SAS IT Battles.
Этот день мы приближали как могли…
Именно так, и ничего удивительного в этом нет. Потому что сердцем SAS IT Battles, изначально задуманного как серия мероприятий с весьма широким размахом, все же являются именно семинары. Потому что обсуждение околокомпьютерных тем в таком формате, когда не нужно перелопачивать пол- интернета в поисках нужной информации, а можно просто в спокойной доброжелательной обстановке слушать докладчика, который владеет огромным запасом знаний по теме семинара и готов с радостью им поделиться, задавать вопросы, которые интересны в первую очередь именно вам, и сразу же получать на них ответы практически из первых уст – это не только еще один способ совместить приятное с полезным, но и возможность для каждого участника ощутить свою сопричастность с тем, что происходит в сфере информационных технологий. Многим такие семинары помогают идти в ногу со временем, постоянно развиваясь в профессиональном плане. А если задуматься, то, наверное, у каждого найдутся свои причины и аргументы в пользу подобных мероприятий. Да что я вам рассказываю? Вы и сами прекрасно все это понимаете.
Мы действительно приближали этот день как могли. Поэтому когда выяснилось, что наш первый семинар, который и без того (если верить известной поговорке) должен был стать «первым блином», еще и выпадает на 13-е число, это нас ничуть не испугало. Вопреки тому, что SAS IT Battles – это «фестиваль, создающийся на твоих глазах», вся подготовка семинаров проходила незаметно для участников, а иногда даже втайне ;-). Причем проходила уже давно и сделано в этом направлении было немало, так что бояться действительно было нечего.
А вот волнение, надо признаться, было. Ведь для организаторов это, по сути, был этакий «выход в свет», и ударить в грязь лицом нельзя было ни при каких обстоятельствах, кроме разве что падения огромного метеорита или какого-нибудь другого сценария конца света. Конец света не случился: семинар состоялся. И не просто состоялся, а прошел весьма успешно, о чем я как раз сейчас, начиная со следующего абзаца, имею возможность вам поведать.
ZFS: «Зима. Фестиваль. Семинар»
Ох уж эти разработчики из Sun Microsystems!.. Это ж надо было придумать своей файловой системе такое название! Я честно и добросовестно пытался придумать какую-нибудь расшифровку этой аббревиатуры, которая бы одновременно захватила и наш фестиваль. Потратил целых полчаса – и самое лучшее, что удалось придумать, сейчас записано несколькими строчками выше. Если у вас есть другие идеи – с радостью их рассмотрим, можем даже отдельный конкурс провести на лучшую расшифровку, правда, наверное, без призов, только лишь за почет и уважение. Хотя кто знает: а вдруг наши партнеры это оценят? :-) Шучу, но про долю правды в каждой шутке не забывайте: на форуме уж точно можете оставить свой вариант, тем более что на протяжении всего времени проведения фестиваля именно там, на форуме, оргкомитет отслеживает всех посетителей и собирает статистику, на основании которой самым активным будут вручены ценные подарки.
Итак, первый семинар был посвящен файловой системе ZFS. Если уж совсем точно, то тема была такой: «Чем хороша ZFS в теории и на практике».
Рассказывал об этом явлении в мире информационных технологий эксперт по ОС Solaris компании Sun Microsystems Филипп Торчинский. Получилось интересно, последовательно, логично, объективно (то есть с рассмотрением как плюсов, так и минусов) и, что особенно важно, доступно для понимания широкому кругу так называемых «компьютерщиков». Прошу заметить, что первый семинар прошел как раз накануне дня компьютерщика, что символично. Ну и лучше поздно, чем никогда: всех коллег с прошедшим праздником!
Смею предположить, что далеко не все, кто сейчас читает эти строки, присутствовали на семинаре – это с одной стороны. С другой стороны, упомянутый мной в самом начале образовательно-познавательный элемент фестиваля никто не отменял. Посему считаю своим долгом кратко пересказать ту информацию, которая прозвучала для присутствовавших. Переплюнуть Филиппа по качеству изложения материала я не берусь (все-таки для него это часть профессии, в отличие от меня), но тянуться к заданной планке торжественно обещаю.
ZFS: «Задачи Файловых Систем»
Для того чтобы охватить как можно больший круг читателей, начну с самых основ. Думаю, не будет новостью сообщение о том, что вся информация в компьютере представляется в виде последовательностей из нулей и единиц, т.е. двоичных цифр. Каждая такая цифра называется «бит» (от англ. BInary digiT – двоичная цифра). Для удобства отдельные биты объединяются в группы по 8 штук, и называют каждую такую группу словом «байт». Собственно, именно байты и являются единицами измерения объема информации. Дальше идет чистейшей воды арифметика: 1024 байта – это 1 килобайт, 1024 килобайта – это 1 мегабайт, 1024 мегабайта – это 1 гигабайт. Далее в списке единиц измерения информации следуют терабайты, петабайты, эксабайты и зеттабайты.
Объемы жестких дисков, используемых для хранения информации в домашних компьютерах в настоящее время, измеряются сотнями гигабайт и уверенно приближаются к терабайтным значениям. Эти объемы информации на самом деле чудовищно огромны – и ими нужно как-то управлять. На физическом уровне информация на жестком диске хранится в виде непрерывного потока байтов, а самому жесткому диску по большому счету все равно, что представляет собой эта последовательность: для него она просто набор двоичных цифр, имеющий фиксированную длину. Аналогичная ситуация наблюдается и с другими носителями информации: CD, DVD, USB флеш-накопителями и т.п. Для того чтобы хранить на одном и том же носителе информации самые разные данные (например, на одной флешке держать одновременно любимые песни и какие-либо документы), требуется сохранять не только сами данные, но и информацию об их расположении в той самой последовательности байтов.
Вспомним о таком понятии, как файл. Файл – это упорядоченная последовательность байтов, которая хранится на каком-либо носителе информации и имеет свое собственное уникальное имя, некоторый размер, а также ряд других свойств, о которых мы вспомним чуть позже. Для того чтобы управлять отдельными файлами, и были созданы файловые системы.
По сути, файловая система – это набор правил, в соответствии с которыми файлы и сопровождающая их вспомогательная информация (так называемые метаданные) располагаются на носителе информации. Для того чтобы применить ту или иную файловую систему на практике, то есть записывать и считывать файлы по каким-то определенным правилам, разрабатываются специальные программные модули (такой модуль называется «драйвер файловой системы»). Следует заметить, что для ускорения работы чтение и запись на носители информации осуществляется не по одному байту, а блоками, размер которых определяется рядом факторов, в т.ч. отчасти и используемой файловой системой.
Для разных целей созданы десятки различных файловых систем, имеющих свои преимущества и недостатки, ограничения и возможности. Примером одной из простейших файловых систем является FAT. Свое название она получила в честь одной из важнейших используемых в ней структур данных – File Allocation Table (Таблица Размещения Файлов). Упрощенно можно представить, что содержимое диска, отформатированного по правилам этой файловой системы, состоит из двух частей: области данных (сюда записывается содержимое файлов) и собственно таблицы размещения файлов. Последняя представляет собой своего рода список, в котором указаны все имеющиеся на диске файлы, а также номер блока, с которого начинается каждый из них, размер файла (в байтах) и некоторую другую информацию, которая определяет, какие действия можно выполнять с тем или иным файлом.
Помимо несомненных преимуществ FAT, таких как простота и широкая поддержка различными операционными системами, у нее существуют и определенные недостатки, которые незаметны для рядового пользователя, но достаточно существенны, чтобы отказаться от ее использования на серверах, которые должны обрабатывать большие объемы данных, контролировать их целостность и неизменность и одновременно обеспечивать максимально возможную отказоустойчивость. К сожалению, для удовлетворения этой потребности FAT не подходит.
Исследования показали, что даже сегодня, когда компьютерная техника, казалось бы, находится на очень высоком уровне развития, в этой области по- прежнему остаются слабые места. В основном, конечно, эти слабые места так или иначе связаны с человеческим фактором: например, небольшая ошибка в микропрограмме, которая управляет жестким диском, может привести к тому, что данные, которые мы будем на него записывать, окажутся записанными некорректно, например, частично измененными (пример как раз такой ситуации был приведен в ходе семинара).
Конечно, такое случается крайне редко. Зато довольно часто возникает другая проблема: потеря данных из-за какого-либо сбоя наподобие отключения электричества в момент записи информации на диск. Еще более типичный пример – удаление файлов по ошибке. Можно привести еще ряд других причин, заставляющих умудренных опытом людей регулярно проводить резервное копирование, но здесь важно другое: файловые системы для серверов должны с минимальными потерями переносить подобные неприятные события, поскольку объемы данных там чаще всего более чем огромны.
ZFS: «Запретите Файлам Своевольничать»
Теперь, как мне кажется, самое время рассказать о файловой системе ZFS. Первоначально она была создана в Sun Microsystems для использования с операционной системой Solaris. Да-да, той самой, которая сейчас продолжает развиваться, в том числе и не без участия сообщества разработчиков OpenSolaris Community.
Джефф Бонвик (Jeff Bonwick), руководитель команды, занимавшейся разработкой ZFS, в своем блоге ( сайт ) пишет о том, что самой «трудной» буквой в названии оказалась буква «Z». «Первое, что я сделал, – это воспользовался Google’м для всех 26 трехбуквенных сочетаний, от AFS до ZFS. Оказалось, что все они уже использовались либо разработанными, либо находившимися в разработке продуктами, некоторые – неоднократно. Но вариант «ZFS» использовался намного реже…» – пишет Джефф. В конце концов было решено остановиться именно на букве «Z».
Самую «трудную» букву удалось оправдать словом, которое уже упоминалось выше, – зеттабайт (zettabyte). Читаем в блоге: «ZFS должна была стать 128-битной операционной системой, а единица измерения, следующая за эксабайтом (ограничение 64-битных файловых систем составляет 16 эксабайт), – это зеттабайт». Но результат все же не удовлетворил разработчиков: для того чтобы использовать это слово в расшифровке аббревиатуры, пришлось бы каждый раз приводить его определение. А оно, в свою очередь, отражает лишь одну из возможностей этой файловой системы (поддержку больших объемов данных), причем далеко не самую важную. Поэтому официально принято считать, что название файловой системы ничего не означает.
Одна из сильных сторон ZFS уже была названа: это поддерживаемые объемы данных. Чтобы не повторять заезженный пример про кипящий океан, позволю себе отправить вас на Википедию, к странице, посвященной ZFS. Среди других преимуществ отметим поддержку сжатия данных на лету, возможность дискового резервирования (гарантирует, что всегда будет оставаться некоторый доступный объем для конкретной файловой системы), поддержку одновременного использования нескольких физических носителей (в том числе и в виде RAID-массивов).
Но эти возможности скорее полезны для серверов. Если же говорить об обычных пользователях, то следует упомянуть о возможности, которая, по словам Филиппа Торчинского, была полностью реализована в ZFS буквально за 2 недели до нашего семинара – это дедублирование (или дедупликация) – прием, позволяющий существенно сократить потребление дискового пространства в случае хранения на диске большого количества повторяющихся блоков данных. При включении этой функции повторяющиеся блоки данных будут сохраняться на диске в единственном экземпляре, а не для каждой копии.
Беседу о преимуществах и недостатках файловых систем мы начинали с вопроса об их устойчивости к различным сбоям. Эта сторона также оказывается сильной в случае с ZFS. Контроль целостности данных осуществляется путем подсчета контрольных сумм до записи информации, что позволяет существенно снизить вероятность повреждения содержимого файлов. Сами контрольные суммы хранятся максимально далеко друг от друга: в этом случае у них намного меньше шансов повредиться вместе с соответствующими им данными.
Впрочем, идея подсчета контрольных сумм сама по себе не нова и уже реализована во многих других системах. И здесь мы вплотную подходим к понятию «сквозной контроль целостности». Оно означает, что контрольные суммы вычисляются и хранятся не только для блоков, содержащих данные файлов, но и для блоков метаданных, т.е. служебной информации. Все блоки объединяются в структуру данных «Дерево», повышая, таким образом, надежность сквозного контроля настолько, что вы можете не беспокоиться: если файлы попытаются измениться без разрешения – вам об этом сообщат.
Но что делать, если данные все-таки повредились? Например, из-за уже упомянутого отключения электричества в момент записи на диск. И здесь ZFS тоже предлагает нам свое решение. И имя этому решению – транзакционность. При изменении файла соответствующий ему блок не перезаписывается сразу же: вместо этого обновленное содержимое блока данных помещается в свободный участок диска. Затем происходит движение к корню дерева (блок данных является листом), при котором на каждом шаге создается копия узла дерева с обновленными метаданными. Таким образом, получается копия ветви дерева, содержащей измененный блок. Обновление корневого элемента реализовано как атомарная (неделимая) операция, и только в этот момент происходит замена старой ветви дерева новой. Таким образом, если на каком-либо шаге происходит отключение питания диска, новая ветвь просто окажется утерянной, а файловая система останется в том состоянии, которое предшествовало операции записи.
Еще одна причина, по которой часто происходит потеря данных, – это случайное удаление файлов. Оно может быть выполнено как самим пользователем (непреднамеренно), так и злобным компьютерным вирусом (вполне умышленно) или плохо написанной программой (состава преступления в этом случае нет, но и ничего хорошего тоже). Традиционное решение этой проблемы – резервное копирование данных, т.е. создание копий важных файлов на отдельном носителе информации с определенной периодичностью. К сожалению, проведение этой процедуры увеселительным мероприятием не является и частенько откладывается до лучших времен. Чаще всего лучшим временем оказывается день, когда по какой-то причине данные безвозвратно пропадают, а имеющиеся резервные копии оказываются слишком старыми, чтобы помочь в решении проблемы.
Разработчики Sun Microsystems учли эту печальную статистику и предусмотрели в рамках файловой системы ZFS возможность создания снимков и клонов. Снимки реализуются за счет того, что вместо освобождения блоков данных можно сохранять их, пометив специальным образом. При этом на диске фактически хранятся данные в своем текущем состоянии плюс предыдущие состояния файлов, которые были изменены после создания снимка. Так как повторяющиеся блоки данных записываются на диск только в одном экземпляре, а затем используются во многих файлах, то использование снимков потребляет не слишком много дискового пространства. Клоны используют схожий принцип работы и позволяют поддерживать одновременно несколько файловых систем таким образом, чтобы при изменении блока в одной из них (а оно, как вы помните, сопровождается выделением нового блока) во всех остальных системах-клонах эти изменения также находили свое отражение.
Таким образом, в случае утери важных данных можно просто восстановить предыдущее состояние файловой системы из сделанного заранее снимка. А поскольку снимки могут создаваться с заданной частотой и автоматически, сама процедура резервного копирования превращается в чистую формальность.
К сожалению, как это часто бывает в мире компьютеров, за все хорошее приходится платить. В случае с ZFS поддержка всех перечисленных и не перечисленных ее возможностей требует наличия достаточного объема оперативной памяти, поскольку используется эта память достаточно активно. Впрочем, в последнее время ОЗУ компьютеров растут не по дням, а по часам, так что особых затруднений это не вызывает, да и плюсы файловой системы от Sun Microsystems существенно сглаживают эту проблему.
Что дальше?
Пользуясь возможностью, хочу напомнить, что SAS IT Battles продолжает набирать обороты. Уже сейчас вы можете зарегистрироваться для участия в одном из конкурсов (а можно и не в одном, кстати ;-) ) и вступить в борьбу за ценные подарки от оргкомитета и спонсоров фестиваля. Кроме того, недавно прошел веб-семинар с представителем компании SoftSphere Technologies, занимающейся разработкой антивирусного решения DefenseWall. Запланировано мероприятие с участием представителей компании Zscaler, Inc.
Кроме того, на 20 марта назначен еще один семинар от Sun Microsystems, в ходе которого Филипп Торчинский затронет более сложные технические вопросы, связанные с файловой системой ZFS и операционной системой Solaris. Полную информацию обо всех мероприятиях, проводимых в рамках фестиваля, и о самом SAS IT Battles. Session One можно найти на официальном сайте фестиваля сайт
Дмитрий Оношко, q@sa-sec.org
Этот день мы приближали как могли…
Именно так, и ничего удивительного в этом нет. Потому что сердцем SAS IT Battles, изначально задуманного как серия мероприятий с весьма широким размахом, все же являются именно семинары. Потому что обсуждение околокомпьютерных тем в таком формате, когда не нужно перелопачивать пол- интернета в поисках нужной информации, а можно просто в спокойной доброжелательной обстановке слушать докладчика, который владеет огромным запасом знаний по теме семинара и готов с радостью им поделиться, задавать вопросы, которые интересны в первую очередь именно вам, и сразу же получать на них ответы практически из первых уст – это не только еще один способ совместить приятное с полезным, но и возможность для каждого участника ощутить свою сопричастность с тем, что происходит в сфере информационных технологий. Многим такие семинары помогают идти в ногу со временем, постоянно развиваясь в профессиональном плане. А если задуматься, то, наверное, у каждого найдутся свои причины и аргументы в пользу подобных мероприятий. Да что я вам рассказываю? Вы и сами прекрасно все это понимаете.
Мы действительно приближали этот день как могли. Поэтому когда выяснилось, что наш первый семинар, который и без того (если верить известной поговорке) должен был стать «первым блином», еще и выпадает на 13-е число, это нас ничуть не испугало. Вопреки тому, что SAS IT Battles – это «фестиваль, создающийся на твоих глазах», вся подготовка семинаров проходила незаметно для участников, а иногда даже втайне ;-). Причем проходила уже давно и сделано в этом направлении было немало, так что бояться действительно было нечего.
А вот волнение, надо признаться, было. Ведь для организаторов это, по сути, был этакий «выход в свет», и ударить в грязь лицом нельзя было ни при каких обстоятельствах, кроме разве что падения огромного метеорита или какого-нибудь другого сценария конца света. Конец света не случился: семинар состоялся. И не просто состоялся, а прошел весьма успешно, о чем я как раз сейчас, начиная со следующего абзаца, имею возможность вам поведать.
ZFS: «Зима. Фестиваль. Семинар»
Ох уж эти разработчики из Sun Microsystems!.. Это ж надо было придумать своей файловой системе такое название! Я честно и добросовестно пытался придумать какую-нибудь расшифровку этой аббревиатуры, которая бы одновременно захватила и наш фестиваль. Потратил целых полчаса – и самое лучшее, что удалось придумать, сейчас записано несколькими строчками выше. Если у вас есть другие идеи – с радостью их рассмотрим, можем даже отдельный конкурс провести на лучшую расшифровку, правда, наверное, без призов, только лишь за почет и уважение. Хотя кто знает: а вдруг наши партнеры это оценят? :-) Шучу, но про долю правды в каждой шутке не забывайте: на форуме уж точно можете оставить свой вариант, тем более что на протяжении всего времени проведения фестиваля именно там, на форуме, оргкомитет отслеживает всех посетителей и собирает статистику, на основании которой самым активным будут вручены ценные подарки.
Итак, первый семинар был посвящен файловой системе ZFS. Если уж совсем точно, то тема была такой: «Чем хороша ZFS в теории и на практике».
Рассказывал об этом явлении в мире информационных технологий эксперт по ОС Solaris компании Sun Microsystems Филипп Торчинский. Получилось интересно, последовательно, логично, объективно (то есть с рассмотрением как плюсов, так и минусов) и, что особенно важно, доступно для понимания широкому кругу так называемых «компьютерщиков». Прошу заметить, что первый семинар прошел как раз накануне дня компьютерщика, что символично. Ну и лучше поздно, чем никогда: всех коллег с прошедшим праздником!
Смею предположить, что далеко не все, кто сейчас читает эти строки, присутствовали на семинаре – это с одной стороны. С другой стороны, упомянутый мной в самом начале образовательно-познавательный элемент фестиваля никто не отменял. Посему считаю своим долгом кратко пересказать ту информацию, которая прозвучала для присутствовавших. Переплюнуть Филиппа по качеству изложения материала я не берусь (все-таки для него это часть профессии, в отличие от меня), но тянуться к заданной планке торжественно обещаю.
ZFS: «Задачи Файловых Систем»
Для того чтобы охватить как можно больший круг читателей, начну с самых основ. Думаю, не будет новостью сообщение о том, что вся информация в компьютере представляется в виде последовательностей из нулей и единиц, т.е. двоичных цифр. Каждая такая цифра называется «бит» (от англ. BInary digiT – двоичная цифра). Для удобства отдельные биты объединяются в группы по 8 штук, и называют каждую такую группу словом «байт». Собственно, именно байты и являются единицами измерения объема информации. Дальше идет чистейшей воды арифметика: 1024 байта – это 1 килобайт, 1024 килобайта – это 1 мегабайт, 1024 мегабайта – это 1 гигабайт. Далее в списке единиц измерения информации следуют терабайты, петабайты, эксабайты и зеттабайты.
Объемы жестких дисков, используемых для хранения информации в домашних компьютерах в настоящее время, измеряются сотнями гигабайт и уверенно приближаются к терабайтным значениям. Эти объемы информации на самом деле чудовищно огромны – и ими нужно как-то управлять. На физическом уровне информация на жестком диске хранится в виде непрерывного потока байтов, а самому жесткому диску по большому счету все равно, что представляет собой эта последовательность: для него она просто набор двоичных цифр, имеющий фиксированную длину. Аналогичная ситуация наблюдается и с другими носителями информации: CD, DVD, USB флеш-накопителями и т.п. Для того чтобы хранить на одном и том же носителе информации самые разные данные (например, на одной флешке держать одновременно любимые песни и какие-либо документы), требуется сохранять не только сами данные, но и информацию об их расположении в той самой последовательности байтов.
Вспомним о таком понятии, как файл. Файл – это упорядоченная последовательность байтов, которая хранится на каком-либо носителе информации и имеет свое собственное уникальное имя, некоторый размер, а также ряд других свойств, о которых мы вспомним чуть позже. Для того чтобы управлять отдельными файлами, и были созданы файловые системы.
По сути, файловая система – это набор правил, в соответствии с которыми файлы и сопровождающая их вспомогательная информация (так называемые метаданные) располагаются на носителе информации. Для того чтобы применить ту или иную файловую систему на практике, то есть записывать и считывать файлы по каким-то определенным правилам, разрабатываются специальные программные модули (такой модуль называется «драйвер файловой системы»). Следует заметить, что для ускорения работы чтение и запись на носители информации осуществляется не по одному байту, а блоками, размер которых определяется рядом факторов, в т.ч. отчасти и используемой файловой системой.
Для разных целей созданы десятки различных файловых систем, имеющих свои преимущества и недостатки, ограничения и возможности. Примером одной из простейших файловых систем является FAT. Свое название она получила в честь одной из важнейших используемых в ней структур данных – File Allocation Table (Таблица Размещения Файлов). Упрощенно можно представить, что содержимое диска, отформатированного по правилам этой файловой системы, состоит из двух частей: области данных (сюда записывается содержимое файлов) и собственно таблицы размещения файлов. Последняя представляет собой своего рода список, в котором указаны все имеющиеся на диске файлы, а также номер блока, с которого начинается каждый из них, размер файла (в байтах) и некоторую другую информацию, которая определяет, какие действия можно выполнять с тем или иным файлом.
Помимо несомненных преимуществ FAT, таких как простота и широкая поддержка различными операционными системами, у нее существуют и определенные недостатки, которые незаметны для рядового пользователя, но достаточно существенны, чтобы отказаться от ее использования на серверах, которые должны обрабатывать большие объемы данных, контролировать их целостность и неизменность и одновременно обеспечивать максимально возможную отказоустойчивость. К сожалению, для удовлетворения этой потребности FAT не подходит.
Исследования показали, что даже сегодня, когда компьютерная техника, казалось бы, находится на очень высоком уровне развития, в этой области по- прежнему остаются слабые места. В основном, конечно, эти слабые места так или иначе связаны с человеческим фактором: например, небольшая ошибка в микропрограмме, которая управляет жестким диском, может привести к тому, что данные, которые мы будем на него записывать, окажутся записанными некорректно, например, частично измененными (пример как раз такой ситуации был приведен в ходе семинара).
Конечно, такое случается крайне редко. Зато довольно часто возникает другая проблема: потеря данных из-за какого-либо сбоя наподобие отключения электричества в момент записи информации на диск. Еще более типичный пример – удаление файлов по ошибке. Можно привести еще ряд других причин, заставляющих умудренных опытом людей регулярно проводить резервное копирование, но здесь важно другое: файловые системы для серверов должны с минимальными потерями переносить подобные неприятные события, поскольку объемы данных там чаще всего более чем огромны.
ZFS: «Запретите Файлам Своевольничать»
Теперь, как мне кажется, самое время рассказать о файловой системе ZFS. Первоначально она была создана в Sun Microsystems для использования с операционной системой Solaris. Да-да, той самой, которая сейчас продолжает развиваться, в том числе и не без участия сообщества разработчиков OpenSolaris Community.
Джефф Бонвик (Jeff Bonwick), руководитель команды, занимавшейся разработкой ZFS, в своем блоге ( сайт ) пишет о том, что самой «трудной» буквой в названии оказалась буква «Z». «Первое, что я сделал, – это воспользовался Google’м для всех 26 трехбуквенных сочетаний, от AFS до ZFS. Оказалось, что все они уже использовались либо разработанными, либо находившимися в разработке продуктами, некоторые – неоднократно. Но вариант «ZFS» использовался намного реже…» – пишет Джефф. В конце концов было решено остановиться именно на букве «Z».
Самую «трудную» букву удалось оправдать словом, которое уже упоминалось выше, – зеттабайт (zettabyte). Читаем в блоге: «ZFS должна была стать 128-битной операционной системой, а единица измерения, следующая за эксабайтом (ограничение 64-битных файловых систем составляет 16 эксабайт), – это зеттабайт». Но результат все же не удовлетворил разработчиков: для того чтобы использовать это слово в расшифровке аббревиатуры, пришлось бы каждый раз приводить его определение. А оно, в свою очередь, отражает лишь одну из возможностей этой файловой системы (поддержку больших объемов данных), причем далеко не самую важную. Поэтому официально принято считать, что название файловой системы ничего не означает.
Одна из сильных сторон ZFS уже была названа: это поддерживаемые объемы данных. Чтобы не повторять заезженный пример про кипящий океан, позволю себе отправить вас на Википедию, к странице, посвященной ZFS. Среди других преимуществ отметим поддержку сжатия данных на лету, возможность дискового резервирования (гарантирует, что всегда будет оставаться некоторый доступный объем для конкретной файловой системы), поддержку одновременного использования нескольких физических носителей (в том числе и в виде RAID-массивов).
Но эти возможности скорее полезны для серверов. Если же говорить об обычных пользователях, то следует упомянуть о возможности, которая, по словам Филиппа Торчинского, была полностью реализована в ZFS буквально за 2 недели до нашего семинара – это дедублирование (или дедупликация) – прием, позволяющий существенно сократить потребление дискового пространства в случае хранения на диске большого количества повторяющихся блоков данных. При включении этой функции повторяющиеся блоки данных будут сохраняться на диске в единственном экземпляре, а не для каждой копии.
Беседу о преимуществах и недостатках файловых систем мы начинали с вопроса об их устойчивости к различным сбоям. Эта сторона также оказывается сильной в случае с ZFS. Контроль целостности данных осуществляется путем подсчета контрольных сумм до записи информации, что позволяет существенно снизить вероятность повреждения содержимого файлов. Сами контрольные суммы хранятся максимально далеко друг от друга: в этом случае у них намного меньше шансов повредиться вместе с соответствующими им данными.
Впрочем, идея подсчета контрольных сумм сама по себе не нова и уже реализована во многих других системах. И здесь мы вплотную подходим к понятию «сквозной контроль целостности». Оно означает, что контрольные суммы вычисляются и хранятся не только для блоков, содержащих данные файлов, но и для блоков метаданных, т.е. служебной информации. Все блоки объединяются в структуру данных «Дерево», повышая, таким образом, надежность сквозного контроля настолько, что вы можете не беспокоиться: если файлы попытаются измениться без разрешения – вам об этом сообщат.
Но что делать, если данные все-таки повредились? Например, из-за уже упомянутого отключения электричества в момент записи на диск. И здесь ZFS тоже предлагает нам свое решение. И имя этому решению – транзакционность. При изменении файла соответствующий ему блок не перезаписывается сразу же: вместо этого обновленное содержимое блока данных помещается в свободный участок диска. Затем происходит движение к корню дерева (блок данных является листом), при котором на каждом шаге создается копия узла дерева с обновленными метаданными. Таким образом, получается копия ветви дерева, содержащей измененный блок. Обновление корневого элемента реализовано как атомарная (неделимая) операция, и только в этот момент происходит замена старой ветви дерева новой. Таким образом, если на каком-либо шаге происходит отключение питания диска, новая ветвь просто окажется утерянной, а файловая система останется в том состоянии, которое предшествовало операции записи.
Еще одна причина, по которой часто происходит потеря данных, – это случайное удаление файлов. Оно может быть выполнено как самим пользователем (непреднамеренно), так и злобным компьютерным вирусом (вполне умышленно) или плохо написанной программой (состава преступления в этом случае нет, но и ничего хорошего тоже). Традиционное решение этой проблемы – резервное копирование данных, т.е. создание копий важных файлов на отдельном носителе информации с определенной периодичностью. К сожалению, проведение этой процедуры увеселительным мероприятием не является и частенько откладывается до лучших времен. Чаще всего лучшим временем оказывается день, когда по какой-то причине данные безвозвратно пропадают, а имеющиеся резервные копии оказываются слишком старыми, чтобы помочь в решении проблемы.
Разработчики Sun Microsystems учли эту печальную статистику и предусмотрели в рамках файловой системы ZFS возможность создания снимков и клонов. Снимки реализуются за счет того, что вместо освобождения блоков данных можно сохранять их, пометив специальным образом. При этом на диске фактически хранятся данные в своем текущем состоянии плюс предыдущие состояния файлов, которые были изменены после создания снимка. Так как повторяющиеся блоки данных записываются на диск только в одном экземпляре, а затем используются во многих файлах, то использование снимков потребляет не слишком много дискового пространства. Клоны используют схожий принцип работы и позволяют поддерживать одновременно несколько файловых систем таким образом, чтобы при изменении блока в одной из них (а оно, как вы помните, сопровождается выделением нового блока) во всех остальных системах-клонах эти изменения также находили свое отражение.
Таким образом, в случае утери важных данных можно просто восстановить предыдущее состояние файловой системы из сделанного заранее снимка. А поскольку снимки могут создаваться с заданной частотой и автоматически, сама процедура резервного копирования превращается в чистую формальность.
К сожалению, как это часто бывает в мире компьютеров, за все хорошее приходится платить. В случае с ZFS поддержка всех перечисленных и не перечисленных ее возможностей требует наличия достаточного объема оперативной памяти, поскольку используется эта память достаточно активно. Впрочем, в последнее время ОЗУ компьютеров растут не по дням, а по часам, так что особых затруднений это не вызывает, да и плюсы файловой системы от Sun Microsystems существенно сглаживают эту проблему.
Что дальше?
Пользуясь возможностью, хочу напомнить, что SAS IT Battles продолжает набирать обороты. Уже сейчас вы можете зарегистрироваться для участия в одном из конкурсов (а можно и не в одном, кстати ;-) ) и вступить в борьбу за ценные подарки от оргкомитета и спонсоров фестиваля. Кроме того, недавно прошел веб-семинар с представителем компании SoftSphere Technologies, занимающейся разработкой антивирусного решения DefenseWall. Запланировано мероприятие с участием представителей компании Zscaler, Inc.
Кроме того, на 20 марта назначен еще один семинар от Sun Microsystems, в ходе которого Филипп Торчинский затронет более сложные технические вопросы, связанные с файловой системой ZFS и операционной системой Solaris. Полную информацию обо всех мероприятиях, проводимых в рамках фестиваля, и о самом SAS IT Battles. Session One можно найти на официальном сайте фестиваля сайт
Дмитрий Оношко, q@sa-sec.org
Компьютерная газета. Статья была опубликована в номере 09 за 2010 год в рубрике безопасность