вторник, 20 декабря 2011 г.

ZFS: Не шутите с CoW!

Преамбула

Меня всегда забавляла способность большинства современных личностей в IT не просто не читать концепций (маны курить еще туда-сюда, без этого текущие задачи вообще решать невозможно), а в принципе не отдавать себе отчета в том, как устроены те или иные вещи.

В этой связи мне страшно нравится передача Discovery "Как это работает?" Пора такие видеоликбезы по IT выкладывать на YouTube, как мне представляется. Где популярно, языком телепередач, внушать IT-общественности, что законы физики вообще и законы сохранения в частности, в общем, в IT тоже действуют.

Жалоба CoWбоя

А теперь к делу.

Если вы внимательно следите за современными течениями в операционных системах, а конкретно - в области файловых систем, то наверняка знаете, что появилась устойчивая тенденция к созданию файловых систем, устроенных по принципу CoW - Copy-On-Write.

Что в переводе на простой русский язык означает - "Транзакционная семантика и запись измененных данных на новой место".

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

Приведу простой пример.

Допустим, у вас есть сторидж пул ZFS общим объемом 1 Тб. При этом он заполнен на 50%, и количество файлов на этих 50% (т.е. на 500 Гб) составляет, скажем, 10 млн штук. При этом приложение/приложения каждый час обновляет половину из них, что составляет в гигабайтах, допустим, 250 Гб.

Каждый раз, когда происходит транзакционное обновление 250 Гб, эти 250 Гб записываются в новое место.

Через 3 часа фактически свободное пространство на сторидж пуле заканчивается*.

Что произойдет после этого?

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

__________________________
* Я сознательно максимально упрощаю пример. Да, мне известно и о наличии лога намерений (intent log), который, если не вынесен на отдельные устройства, выделяется в пространстве пула, и о наличии включенного по умолчанию кэша L2, выделенного там же. С учетом их существования, при заданных в примере начальных условиях и при таком темпе изменений файловой системы все закончится еще быстрее. Примерно в три-четыре раза, в зависимости от разового объема записи и количества шпинделей пула. Опять-же, грубо. Желающие могут провести натурный эксперимент, в стиле "Разрушителей легенд" дабы лично убедиться в действии законов физики. :)
__________________________

Почему так?

По определению. Так написана файловая система.

Эффект, в общем, не нов. Некоторые неосиляторы концепций от IT еще пару лет назад лично убедились в существовании законов физики, когда, при 90% заполнении пула, обнаружили резкую деградацию производительности ZFS. Ну, еще бы! А куда, по-вашему, драйвер ФС должен писать копии измененных блоков в рамках транзакций? На Великий Небесный Сервер?

Разумеется, файловая система при подобном заполнении изо всех сил пытается найти место для записи новых копий с сохранением старых. Предыдущую-то транзакцию затирать нельзя, ни полностью ни частично. Вдруг питание сбойнет во время записи, куда мы тогда откатимся?

Что, не ждали?

Сюрприз! Концепции желательно не только курить, их желательно также понимать. Что требует уже наличия функционирующего головного мозга. ;)

Что делать и кто виноват?

Виноват, конечно, разработчик файловой системы, кто ж еще-то... Понапишут, блин, а тут потом сиди, разбирайся, кто дурак. Еще и исходники читай... Само должно работать! Искаропки!

А если серьезно?

Планировать СХД. С карандашом в руках. Оценивая не только потребную латентность, пропускную способность или IOPS, но и запас свободного пространства с учетом примерного планируемого объема дисковых транзакций и их темпа в единицу времени.

Данный недостаток подобных файловых систем является логическим продолжением их основных достоинств. Соответственно, нужно его учитывать

Как метко выразился один джентльмен (правда, немного по другому поводу), жесткий диск сейчас стоит дешевле лопаты дерьма. Кто мешает хотя бы 50% запас по дисковому пространству иметь? Ах, вы не ждали такого поведения файловой системы... Ну, что ж.  Ошибки в генах программно не исправляются.

Что делать, если все-таки влипли? Прохлопали ушами и пул отвалился?

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

Да, есть ломовое средство. Удалить в безопасном режиме /etc/zfs/zfs.cache, перезагрузиться в опасный режим, разрушить пул, создать заново, и восстановить данные - хотя бы частично - со снапшотов (разумеется, если вам хватило ума организовать процедуры резервного копирования. Что, как показывает практика, свойственно далеко не всем). Не допуская уже чрезмерного заполнения.

Не думаю, однако, что пользователей сервера устроит величина даунтайма и такое отношение к их данным.

Посему желательно, при пересоздании пула, нарастить его объем путем добавления приличного числа новых шпинделей и учесть вышесказанное.

Если пул, после завершения проверки, все-таки удалось импортировать, первым делом надо попытаться удалить лишние данные. Если это, опять-таки, удастся сделать.

Проще не допускать чрезмерного заполнения пулов.

Не надо жадничать.