about NetApp

??так, в прошлом посте я мельком упомянул, что кроме volume reallocation у NetApp есть еще aggregate reallocation (ключ команды запуска reallocate –A). ?? вот с ним начинается некоторое непонимание. Дело в том, что, как я показывал на примере в постах ранее, одной из необходимых операций при расширении aggregate является проведение reallocation блоков тома, для более равномерного распределения их по дискам aggregate. При этом, хотя операция проводится над aggregate, но используется НЕ aggregate reallocate, а совсем вовсе даже volume reallocation!

?? вот это принципиальный момент, вызывающий путаницу. Почему оптимизируя aggregate, мы делаем это через volume reallocate, почему не aggregate reallocate, и что же тогда делает этот aggregate reallocation?

Data ONTAP выражается тут однозначно:

NOTE: -A is for aggregate (freespace) reallocation. Do NOT use -A after growing an aggregate if you wish to optimize the layout of existing data; instead use reallocate start -f /vol/ for each volume in the aggregate.

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

На aggregate у нас расположены, как правило, не один, а множество volume.

Volume reallocate выполняется для отдельного тома, НО НЕ для всех томов aggregate разом. Вы, в случае рассматриваемой процедуры изменения размеров aggregate и увеличения нижележащих в нем дисков, должны последовательно провести reallocation для всех томов на aggregate.

Как вы видите на рисунке выше, если мы сделали reallocate для тома А, и не делали для тома В, то мы получим что-то, похожее на рисунок выше. Один том – перераспределился на добавленные диски, а второй – нет. К тому же у нас неравномерно распределилость оставшееся свободное место, как вы помните, непрерывность кусков свободного пространства для хорошей работы механизма выделения экстентов очень важно. а представьте теперь, что на aggregate не два тома, а несколько десятков или даже сотен, как это бывает? ?? при этом reallocate кому-то сделали, а кому-то – нет?

Дальше, как вы видите, том В начал заплняться неравномерно по дискам, как мы уже рассмотрели выше в предыдущем посте, с потенциальным образованием “дисковых хотспотов”

Что же сделает aggregate reallocation (reallocate –A), если, к примеру, на части его томов будет проведен volume reallocation, а на части нет? Он, как и написано выше, оптимизирует свободное пространство на aggregate, при этом оставив часть томов в неоптимизированном состоянии.

Как вы видите на рисунке выше, свободное место на aggregate действительно “оптимизировалось”, с точки зрения aggregate, да. Поэтому в случае использования reallocate после расширения aggregate новыми томами, и более равномерного “растасовывания” блоков томов по новому пространству aggregate, сперва выполните volume reallocate для КАЖДОГО тома на aggregate, а вот потом уже начинайте, если это необходимо, использовать aggregate reallocate.

Таким образом, вы видите, что volume reallocate и aggregate reallocate это ДВА РАЗНЫХ вида реаллокации блоков. В первом случае реаллоцируются блоки, принадлежащие тому, указанному в качестве аргумента команды, а во втором, при запуске ее с ключом –А, реаллоцируется своеобразный “том, состоящий из свободных блоков” на aggregate, и упорядочивается свободное пространство, сжимаются “дыры” в нем, и пространство, незанятое данными, становится “более непрерывным”, но при этом сами тома, с блоками данных, в ходе этой операции не оптимизируются, и если они были неоптимально размещены по дискам, то так неоптимальными и останутся, несмотря на завершившийся процесс aggregate reallocation.

Что-то как-то не получилось у меня опубликовать вторую часть "на следующей неделе", как я было пообещал в конце части первой. Так получилось, что я понял, что статья получается объемной, многие вещи требуют "экскурса и дискурса", а объяснить на пальцах понятно их не получается. Но когда я начал регулярно находить в поиске запросы "запускаем новую систему хранения часть 2 site:blog.aboutnetapp.ru", я понял, что тянуть дальше нельзя.

Посему, вот вам вторая, а еще, может быть, даже и третья далее часть.

Остановились мы в прошлый раз на процедуре начального запуска. Железка поставлена в стойку, ей задан IP для конфигурирования, и проведена самая первая, базовая настройка только полученной системы, к ней уже можно подключиться с помощью System Manager, через веб-интерфейс, или же простой консолью по COM-порту или телнетом по сети.

Далее нам надо сконфигурировать собственно объем хранения. ?? тут есть некоторая сложность, о которой я сейчас попробую в общих чертах рассказать.

Я уже писал в этом блоге об одной особенности двухконтроллерных систем хранения NetApp, особенности, с которой часто сталкиваются начинающие, особенно если ранее он не имели дела с такими системами, и с такой организацией дисков.

Дело в том, что системы хранения NetApp в двухконтроллерной конфигурации High Available Cluster (HA-cluster, в дальнейшем) используют модель работы "share nothing", и, согласно ей, не используют диски совместно. Каждый из двух контроллеров системы хранения должен владеть своим набором дисков. То есть имеющееся количество дисков должно быть между ними поделено (поровну или нет - об этом далее). Доступ к дискам возможен только через владеющий ими контроллер, и никак иначе.

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

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

Так что, в общем случае, вы можете вообразить себе двухконтроллерную систему NetApp как два отдельных (пусть и связанных) файловых сервера NAS, например, каждый со своим набором ресурсов, каждый со своим IP-адресом, по которому происходит обращение, и так далее. В случае SAN это также происходит сходным образом.

??з этого следует, что, по сути, в случае двухконтроллерного NetApp FAS2020 вы получаете не одну систему хранения на 12 дисков, а две на 6 дисков каждая (или 3 и 9 дисков, или 5 и 7 дисков, но всегда две). ?? это довольно существенный момент, который требует осознания. Более того, нельзя отдать одному контроллеру все 12 дисков (это можно в случае одноконтроллерной системы, но не двухконтроллерной, в которой второй контроллер требует наличия хотя бы одной RAID-группы минимального размера (2 диска в RAID-4) и хотя бы одного hotspare, так как на этой группе он должен записать свои собственные конфигурационные данные, иначе он не сможет загрузиться, просто не с чего.

Тему с разбиением дисков по контроллерам, и выбором между равным и неравным разбиением дисков я уже затрагивал в этом блоге, поэтому интересующихся отошлю к более ранним статьям.

Сейчас же мы перейдем к конфигурированию.

??так, мы, руководствуясь частью первой установили систему физически и провели первое включение. Теперь, если вы посмотрите на видимые системе диски, вы увидите, что каждому контроллеру доступен свой набор дисков. Скорее всего вы получите с завода систему, сконфгурированую в виде 5 дисков доступных одному контроллеру и 7 - другому (по крайней мере я видел именно такой вариант поставки FAS2020A).

Если вы читаете этот блог давно, то уже знаете, что такое у NetApp так называемый aggregate. Это структура, в которую включаются физические диски, приписанные одному контроллеру, и которая объединяет RAID-группы, к созданию которых администратор системы хранения не имеет непосредственного доступа. Поверх структуры aggregate уже располагаются непосредственно тома (volumes типа FlexVol), на томах qtrees и в них, или непосредственно на томах - LUN-ы, если вы используете NetApp как SAN-сторадж, или же network shares, если используете его как NAS. В общем яйцо в утке, утка в зайце, заяц в сундуке :)

Но в основе всего - aggregate. Несмотря на то, что в системах NetApp осталась legacy-возможность использовать "классические" RAID, это осталось "для совместимости", и нет совсем никаких причин этим пользоваться сегодня.

Будем пользоваться FlexVol и aggregates.

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

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

В некоторых руководствах NetApp, ориентированных, прежде всего, на большие системы с сотнями дисков, вы можете встретить рекомендации создавать более одного aggregate, например выделять на отдельный aggregate так называемый root volume, на котором находится директория /etc внутренней файловой системы и ее настройки, а также создавать отдельные aggregate для сильно различных видов паттерна нагрузки (например отделять базу данных, с обычно random read/write access, от ее логов, с sequental write), но это рекомендации, повторюсь, для "хайэнда", для систем с сотнями дисков, когда эти рекомендации действительно дают заметный эффект. Если вы запускаете систему с количеством дисков в пределах пары десятков, безусловно наилучшим выбором будет помещать все диски в один большой aggregate, где будут находиться все тома пользователя, включая и root vol. Дробя диски по нескольким aggregates при небольшом количестве этих дисков, следуя рекомендациям для "старших" систем, вы скорее ухудшите ситуацию, уменьшив количество дисков, по которым удастся размазать ввод-вывод, чем улучшите его изолируя трафики.

Поэтому решим использовать один aggregate на контроллер (соответственно, два на кластерную пару, по одному на каждый контроллер). Поскольку вы систему уже запустили, этот aggregate у вас уже создан, на нем помещен системой root volume.

Обычно он называется aggr0, и я предлагаю, если у вас остались невключенные в него диски, добавить их в него командой aggr add (диски). Сделайте то же самое на втором контроллере.

Сейчас структура данных на вашей системе хранения выглядит так:

Обычно том vol0, в котором по умолчанию располагается root vol и директория /etc с настройками внутренней OS Data ONTAP делается с большим запасом. Если вам жалко места, то можете безопасно уменьшить размеры тома vol0, например для различных версий Data ONTAP и разных систем рекомендуется его размер от 10GB для FAS2020, 16GB для FAS2040 (для Data ONTAP 7.x), и до 250GB для старших систем под версией 8.х OS Data ONTAP.

На root vol, кроме настроек, также хранятся прошивки полок и дисков, обновляемые автоматически, а также должно быть место для аварийного сброса kernel dump в случае каких-то нештатных ситуаций.

Все же остальное место на aggregate, за вычетом примерно 10%, которые рекомендуется не занимать для облегчения жизни внутренних процессов и правильной и беспроблемной работы, например, фонового оптимизатора структур WAFL, можно использовать под хранения ваших данных в одном или нескольких томах. Хотя размер тома можно задать и сразу, во многих случаях имеет смысл настроить его на автоматическое увеличение, тогда том будет автоматически расти, по мере заполнения его данными, пока хватит места на хранящем его aggregate, а свободное место не будет заниматься на "хранение нулей", если вы можете отдать его более нуждающимся задачам. Эта настройка называется space reservation (none или file), а возможность автоматического роста тома - volume autogrowth, которую можно задать с желаемым шагом приращения.

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

А в следующей части мы рассмотрим как создавать сетевые ресурсы для NAS и LUN-ы для SAN.

Я уже несколько раз упоминал в этом блоге о aggregate snap reserve, пришла пора  подробнее рассказать о том, что это, зачем использутся, и нужно ли это вам.

Вы уже наверняка знаете, что такое и зачем используется Snapshot reserve на уровне тома. Это некий зарезервированный объем общего пространства соответствующего тома, используемый для того, чтобы обеспечить доступность пространства на дисках при создании снэпшотов состояния тома. Это некая условная “граница”, которую может превысить снэпшот, но не может превысить содержимое тома, пользователю тома доступно для записи место, равное объем тома минус резервация на снэпшоты. Это резервирование гарантирует доступность места для хранения данных снэпшотов, а также упрошает администрирование тома, так как пока снэпшоты не вышли за пределы отведенного резерва, свободное пространство, доступное для записи на томе, стабильно и предсказуемо.

Подробнее и с поясняющими картинками про принцип работы Snap Reserve я писал в посте ранее.

Отмечу также, что величина резерва, заданная по умолчанию в 20% от объема тома может быть изменена, и 20% это не hardcoded value, а просто такая вот эмпирически выбранная когда-то величина “по умолчанию”. Можно сделать 50, 15, 10, и даже 0%. Например 0% сегодня рекомендованная величина Snapshot Reserve в случае использования тома для хранения SAN LUN-ов (вместо Snapshot Reserve используется Fractional (или LUN Overwrite) Reserve, о смысле которого я уже также ранее писал).

С Volume Snap Reserve мы более-менее разобрались, но что же такое и зачем нужен Aggregate Snap Reservation, равный, по умолчанию, 5% от объема aggregate?

Aggregate, по сути, представляет собой свообразный мета-volume, просто такой своеобразный том, находящийся в иерархии уровнем ниже обычного FlexVol-тома. Соответственно, задача у этой резервации точно такая же – хранить блоки, использованные в снэпшоте уровня aggregate.

Что же такое “снэпшот уровня aggregate”, кто его делает и зачем он используется?

Снэпшоты на aggregate использует, например, средство SyncMirror, это средство синхронной репликации, используемое, например, в решении MetroCluster.
Кроме того, такие снэпшоты используются для работы средства контроля целостности файловой структуры WAFL, аналога UNIX-ного fsck, ооочень редко на практике применяемого средства WAFL_check (я знаю немало админов NetApp, которые вообще не в курсе, что такое средство у NetApp есть).

WAFL как “файловая система”, вследствие своей архитектуры, поразительно устойчива, 99% админов NetApp действительно никогда не сталкиваются с необходимостью “лечить” WAFL. “Уронить” WAFL в принципе возможно (“Если один человек чего сделал, то другой завсегда сломать может”(с)) но это, как показывает моя практика, довольно нетривиальная задача.

Если вы “уронили” WAFL настолько, что потребовалось использование WAFL_check, то очень сильно сократить этот процесс может наличие автоматически создаваемых снэпшотов аггрегейта. Впрочем, как я знаю, он заработает и без них, однако, на большой системе, починка может занять на пару порядков больше времени, вместо десятков минут – несколько дней.

Также, с использованием снэпшотов уровня aggregate вы можете сделать SnapRestore для aggregate целиком, вместе со всеми томами и LUN-ами на нем, если зачем-то это вам понадобилось.

Кроме этого следует обратить внимание, что какой-то объем пространства на уровне aggregate (то есть не распределенного в volumes, а непосредственно в aggregate) используют следующие средства:

1. Deduplication  начиная с версии 7.3 хранит свою базу fingerprints непосредственно на уровне aggregate, таким образом, при использовании deduplication вам понадобится какое-то небольшое пространство на aggregate не занятое томами, обычно в зарезервированные 5% эта база помещается
2. Синхронная версия репликации SnapMirror до версии 7.2.2 записывала данные, попадающие в NVRAM, в специальный файл на root volume по пути /etc/sync_snapmirror_nvlog/<dstfsid>.log[0|1]. Начиная с 7.2.7 эти данные пишутся также на уровне aggregate. Руководство Data ONTAP Online Data Backup and Recovery Guide рекомендует, в случае использования Sync SnapMirror иметь на aggregate место в объеме 20x емкости NVRAM на системе-получателе (destination).
   (обратите внимание, что у NetApp есть два различных средства synchronous replication – SyncMirror и SnapMirror Synchronous mode)
3. Наконец, не стоит забывать, что запас незанятого места на aggregate довольно значительно снижает величину фрагментации, а правильнее “non-contiguous block factor”. Напомню, что файловая система (любая, NTFS, ext3, WAFL, почти любая современная файловая система), когда ей необходимо записать файл, сперва ищет у себя фрагмент непрерывно свободного пространства, куда и пишет содержимое этого файла. Если, как это обычно бывает при сильно заполненной файловой системе, такого места отдельным, непрерывным куском нет, то файловая система начинает дробить записываемые данные файла на более мелкие фрагменты, которые уже могут располагаться непоследовательно. В наихудшем случае, файловая система располагает свободным местом только в виде отдельных, непоследовательных блоков, разбросанных по файловой системе. Наличие запаса свободного места с точки зрения файловой системы резко улучшает эту ситуацию, и позволяет не накапливать фрагментацию.

Таким образом, как вы видите, идея держать гарантированно небольшое свободное пространство на уровне aggregate имеет определенные основания на системном уровне. Если вы уверены, что ничем из перечисленного вы не пользуетесь, а 5% зарезервированных на aggregate вам жалко, то вы можете уменьшить эту величину, аналогично ситуации с volume snap reservation, , например до 2-3%, практика показывает, что этого достаточно. Можно, хотя это и не рекомендуется, и вовсе отключить эту резервацию. Обратите также внимание, что, как и в случае с volume snap reserve, отключение reservation не отключает возможность использования snapshots, если на структуре (volume или aggregate, соответственно) есть свободное место. Это просто средство некоторого упрощения жизни и работы админа, и только.
Помните, тем не менее о том, что у NetApp за каждым default value стоит какая-то причина, и прежде чем вы не уясните эту причину, я бы не рекомендовал “твикать” не глядя, это все же не “реестр венды” ;).

Посмотреть текущее состояние резервирования и назначенное расписание создания снэпшотов на aggregate:

fas1> snap sched –A
Aggregate aggr0: 0 1 4@9,14,19 - установлено расписание создания снэпшота aggregate в 9, 14 и 19 часов, и хранение с ротацией одного дневного и 4 таких "почасовых" снэпшота.

fas1> snap sched –A aggr0 0 0 0 - создание снэпшотов aggregate aggr0 отключено.

Для изменения величины или отключения резервирования на aggregate вам нужно использовать команду:

fas1> snap reserve –A aggr0 3 – устанавливаем величину резервирования для aggr0 равную 3%