Загадочный fractional reserve (часть 1).
Не скрою, среди отдельных штук в NetApp есть вещи, способные поставить в тупик.
По моим наблюдениям, изрядным камнем преткновения для пользователей, вот уже несколько лет, является так называемый fractional reserve, как и вообще вся “кухня” распределения пространства под LUN на системах хранения NetApp.
Что же такое этот “загадочный” fractional reserve, и как его правильно использовать?
Думаю, что изрядная доля проблем понимания вызвана, в первую очередь, неудачным термином.
Fractional - “дробный”. но что там дробится, и зачем - остается непонятным.
Я заметил, что в некоторых продуктах, выпущенных NetApp в последнее время появилась более удобоваримая замена для этой “фичи”: Overwrite reserved space - “резерв под перезапись”.
Чтобы разобраться что же это за резерв такой, давайте вспомним, как устроено хранение данных на системах NetApp.
Я уже писал раньше о том, что в основе любой системы хранения NetApp FAS лежит собственная OS и собственная специализированная файловая структура (я намеренно избегаю использовать более привычный термин “файловая система”, чтобы не получить ненужных ассоциаций у читающих, ведь WAFL, в опредедленном смысле, уникальный по своему устройству продукт).
В основе WAFL лежит идея организации записи данных как “неперезаписывающего” процесса. Каждый блок данных записывается однократно, и остается на своем месте. Все же остальные попытки изменений этого блока прикладной программой приводят к записи нового блока, берущегося из пула “свободных блоков” и замены указателя в “таблице размещения файлов” со старого на новый, при этом старый блок остается на старом месте, в прежнем своем состоянии.
Если на старый блок больше не остается ссылок, то он считается свободным, и поступает в распоряжение пула свободных блоков.
Такая любопытная схема позволяет с легкостью брать так называемые “снэпшоты”, то есть мгновенные “снимки” данных, зафиксированные “состояния”. Это получается на WAFL как бы само собой, так как, см. выше, данные не изменяются, достаточно сохранить текущую “таблицу блоков файлов” на определенный момент времени, запретив ее изменять, и вот вам пожалуйста - снэпшот.
Пока на блок остаются ссылки, например из такого снэпшота, он остается на диске в неприкосновенности.
Однако очевидны и недостатки. Такой метод довольно расточительно расходует место на дисках.
Предположим, мы создали на томе LUN, и в какой-то момент взяли с него снэпшот. Этот снэпшот зафиксирует некий набор блоков, и в момент создания он дополнительного места не займет, так как по сути мы сохранили только таблицу инодов на момент его взятия. Все же последующие изменения в нем будут занимать новые блоки, ранее бывшие свободными. Поменяли в нем 10 мегабайт - свободное место на диске на 10 мегабайт уменьшилось.
Допустим, этот LUN в процессе его жизни полностью перезаписан, каждый блок данных его составляющих был перезаписан. Это значит, что суммарный объем данных, занятых этим LUN на диске, увеличится вдвое. ??сходные блоки LUN, записанные первоначально, и “запертые” в снэпшоте, и блоки измененные, с момента первоначальной записи.
Но что случится, если на томе, где мы этот LUN создали, не окажется места для всех перезаписываемых блоков? Очевидно, что ничего хорошего не произойдет, так как в какой-то момент очередного свободного блока процессу записи не достанется, и запись не произойдет с сообщением “No available space at SCSI device”.
В жизни при этом Data ONTAP переводит LUN в offline, чтобы защитить имеющиеся данные от возможных повреждений и сохранить их в целостности.
Для того, чтобы избежать этой неприятности и придумано резервирование типа fractional reserve или, что понятнее звучит, overwrite reserved space.
Это место, резервируемое на том (flexvol), оставленное на нем тот случай, когда содержащийся на томе LUN будет активно переписываться, и понадобятся дополнительные блоки, для того, чтобы разместить эти изменения, в том случае, если прежние блоки по той или иной причине “заперты” и не высвобождаются. Например в случае взятия снэпшота.
Размер этого резервирования можно задать от 0% (резервирования нет, запись возможна только при фактическом наличии места на томе, ничем больше не занятого), до 100% (зарезервировано место, равное размеру размещенного LUN, для остальных задач системы хранения это место недоступно).
Последний вариант дает безопасные гарантии того, что сколько бы вы не написали в LUN, у вас сохранится достаточно места для перезаписи, и вы не столкнетесь с проблемой “No available space left on SCSI device”.
Однако это означает увеличение вдвое занимаемого места для LUN.
Однако NetApp не был бы нетаппом, если бы не предлагал варианты.
Вариантов, на самом деле, существует несколько.
Во первых, возможно не использовать именно 100% резервирования. Например, вы знаете, что ваш LUN сравнительно мало заполнен, или количество записей в него невелико. В таком случае, вы можете выбрать меньший размер резервирования. Например, вы знаете, что в вашем 500GB LUN, расположенном на 1TB томе, в настоящий момент занято не более 200GB. Очевидно, что перезаписи скорее всего будут выполняться в пределах этих 200GB, а резкий рост объема записи в настоящее время маловероятен. Тогда вы можете выбрать резервирование 20%, и сэкномить пространство на томе для других задач.
Однако нужно будет настроить мониторинг объемов свободного места на томе, и внимательно следить за его состоянием, чтобы избежать проблем переполнения.
Помните также, что резерв выделяется на том целиком, а не на LUN. Это значит, что если у вас на томе лежат два 200GB LUN, и резерв выставлен в 30%, то это значит, что один из этих LUNов может измениться (вырасти), при необходимости на 60% (30% своих и 30% соседа).
Во вторых, можно включить опцию snapshot auto-delete, при этом, при нехватке места под данные система попытается удалить старые снэпшоты, и освободить место на томе.
Обратите внимание, что триггер auto-delete может не успеть сработать при резком росте объемов, просто не успеет закончить удаление, оно не мгновенно. Также следует помнить, что если вы пользуетесь client-side ПО управления снэпшотами, например каким-то из SnapManager, то ему может очень не понравиться, что снэпшоты на томе удаляются без его ведома.
В третьих, можно включить опцию volume auto-grow, и тут уже сам том будет иметь возможность увеличиваться с заданным шагом и до заданного предела в объемах, для того, чтобы вместить необходимые данные.
??так, мы видимо, что NetApp предлагает нам несколько вариантов действий. Зарезервировать 100%, на наихудший вариант, и “спать спокойно” - “ленивый” вариант. Внимательно подумать, проанализировать, и зарезервировать столько, сколько в реальности потребуется - “умный” вариант. ??, наконец, подойти с другой стороны, и воспользоваться возможностями автоматического ресайза (или автоосвобождения) тома. По моим наблюдениям, этот вариант сейчас встречается чаще всего, так как позволяет занимать место на дисках только по мере реальной необходимости в нем - “экономный” вариант.
Чтобы не раздувать пост я перенесу практическую “лабу” во второй пост этой темы.