about NetApp

Автор блога NTAPgeek расспросил Ника Триантоса, одного из ведущих инженеров NetApp, по поводу All-Flash FAS систем, стоящих за ними технических решений, и чем AFF отличается от других flash-стораджей, в том числе и тех, что производит сам NetApp, например уже известного вам EF550.

Ник говорит:

“Наибольшая проблема для нас была не в том, как WAFL пишет; на деле это как раз большой плюс архитектуры. Основные проблемы и задачи при разработке были:

Оптимизация под многоядерные процессоры – Долгое время Data ONTAP не умела эффективно использовать многоядерность процессоров. Проект по проведению оптимизации под многоядерность стартовал с версии 7.3 и продолжался вплоть до релиза Data ONTAP 8. Я уверен, что вам доводилось видеть ситуацию, когда один CPU работает с загрузкой 90% и другой - на 20%! Если нагрузка упирается на уровне ONTAP domain, который должен выплняться на одном единственном ядре, то возникает узкое место для роста производительности. ?? при этом неважно, что другие ядра были недозагружены. Эта задача была, в итоге, решена.

Управление метаданными – Когда вы используете маленькие блоки данных, например у NetApp это 4K, то при этом вы получаете множество метаданых, которыми нужно управлять. Для того, чтобы получить максимально быстрый доступ к даным, вам нужно сперва максимально быстро получить доступ к их метаданным. А где быстрее всего доступ к метаданым? В оперативной памяти. Вот почему мы используем так много оперативной памяти на контроллерах серий FAS2500 и FAS8000; мы стараемся как можно больше метаданных при работе держать в быстрой памяти контроллера.

Защита данных – Это связано с темой выше. Системы AFF имеют больше возможностей по защите данных, чем любая другая система c flash (и, кстати, не только flash) на сегодняшнем рынке. Хотя это и полезная штука, есть определенные недостатки. Недостатки состоят в более динных путях ввода-вывода, так как метаданные размещаются и валидируются отдельно от блоков данных.
Как вы защищаетесь от lost writes? Что случится, если вы торговая компания, и на вашей системе хранения SSD сказал, что данные записаны, а на деле он их не записал, или записал не так или не туда? Вы рискуете огромными финансовыми потерями. Data ONTAP не только обнаруживает такие ситуации, но и защищает, а также помогает восстановить данные, испорченые в результате lost writes (это крайне коварная проблема).”

Потерянные операции записи, или “Lost writes”, это редкая, но при этом очень трудно обнаруживаемая ошибка, и самое плохое с ней то, что вы не знаете, что она уже произошла, и  обнаруживаете ее только дни или даже месяцы спустя. Но когда она случилась, она повреждает ваши данные! ?? тут можно только пожелать удачи вам, в поисках бэкапа, снэпшота или точки репликации, в котором эта ошибка еще не проявилась и данные еще не повреждены. Конечно же, любые фичи по зашите данных имеют свои побочные эффекты и недостатки.

Другими словами, хорошая скорость работы и устойчивость к отказам сразу двух дисков – недостаточны для того, чтобы считать, что ваши данные надежно защишены. В особенности, когда flash-хранилища используются для бизнес-критичных приложений. Вам следует проанализировать возможные ситуации отказов, и убедиться, что ваше хранилище устойчиво к ним, а данные - защищены. Более 20 лет мы совершенствеум и развиваем Data ONTAP, и достигли в ней очень высокого уровня надежности и устойчивости против всех видов отказов и различных их комбинаций.”

Напомним, бандлы NetApp AFF имеют:

1. Больше памяти
   Больший объем кэша чтения-записи в FAS8000, что позволяет держать в нем больше метаданных
2. Более быстрый NVRAM
   Быстрее отрабатываются ACK, как следствие – ниже отклик и задержки
3. Значительно оптимизированную многоядерную эффективность OS
   Проводилась начиная с Data ONTAP 7.3
4. Continuous Segment Size Cleaning (CSS)
   Переменный размер сегмента Data ONTAP  (4K-256K)
5. ??нтеллектуальные алгоритмы упреждающего чтения, определяющие типовые паттерны операций:
   • Последовательное чтение с тем же (например 32k) и различными размерами блоков (4k,64k,4k,64k)
   • Скачущее (strided) чтение: Начнем с блока N и прочитаем, считая с него, блоки 10 и 12, но пропустим блок 11
   • Обратное чтение: Начнем с блока N, и прочитаем –10 блоков, считая от него
   • Несколько потоков чтения, читающих из разных точек

Бандлы NetApp AFF доступны к заказу с 23 июня 2014 года.

??з всей троицы продуктов, появившихся у NetApp этим летом, а именно: FAS2500, FAS8080EX и NetApp AFF, совершенно неожиданно для меня именно последний стал предметом преткновения, пост про который я пишу уже вторую неделю. Если про FAS2500 я написал сразу, и там, в целом, все ясно по прочтении техспек и  Technical FAQ / SE Presentation, если c FAS8080ES тоже все ясно, это “больше, выше, сильнее”, вот, в общем, и все что про него можно рассказать, я даже отдельно про него писать не стану, то вот в отношении All-Flash FAS такая ясность долго не наступала. ?? далее я попробую рассказать, в чем, собствено, состоял предмет затруднения.

Continue reading ‘NetApp AFF: All-Flash FAS’ »

Вот уже несколько лет, как среди программных продуктов NetApp есть такая штука, как SnapCreator. К сожалению, как я обратил внимание, он не только очень плохо известен пользователям, но даже те, кто знает про него, используют его крайне редко. А ведь это штука, которая, благодаря своей гибкости, может решить многие задачи, связанные с защитой данных на системе хранения и в прикладных системах, ее использующих.

SnapCreator первоначально был разработан в 2007 году как “служебный”, внутренний продукт, внутри подразделения Professional Services и Rapid Responce Engineering Group, для того, чтобы облегчить построение систем защиты данных в снэпшоты системы хранения для пользовательских прикладных систем, не входящих в список поддерживаемых “официальным” продуктом NetApp - SnapManager.
То есть, если у вас используется MS SQL Server, MS Exchange, Sharepoint, Oracle, SAP, Hyper-V или vSphere (и у вас есть деньги на лицензию SnapManager), то все относительно просто. Вы устанавливаете SnapManager для соответствующего программного продукта, и дальше он делает все сам.

Зачем нужен SnapManager, и почему нельзя обойтись просто командой snap create из консоли, или переданной через ssh или rsh? Ну, например потому, что некоторые программы требуют некоей согласованной последовательности действий на своей стороне, чтобы состояние данных, записанных на дисках системы хранения, было корректным, или еще говорят “консистентным”. Ведь, например, какие-то данные могут оказаться в буферах кэша сервера, как на стороне программы, так и файловой системы, базы SQL могут иметь незавершенные транзакции, и так далее. Все это требует, чтобы перед тем, как будет сделан “снимок”, снэпшот состояния данных, эти данные на дисках уже находились какое-то время в некоем стабильном, непротиворечивом состоянии, то есть все равно нужен некий “агент” на стороне программного продукта, умеющий с ним взаимодействовать.

Таким образом, если у вас используется какой-нибудь MySQL, Sybase, Xen, KVM или что-то подобное, вам нельзя так просто взять и сделать снэпшот. Нужно написать какую-то систему-посредник, между вашим софтом, и софтом Data ONTAP. Вот для того, чтобы облегчить такую задачу для специалистов Professional Services и был написан SnapCreator.

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

Официально в настоящее время существуют две линейки, официальная, и так называемая Community Edition. Последняя это, так сказать, unstable, developers edition, где обкатываются все мульки, которые потом деплоятся в официальную поддерживаемую компанией ветку.

Архитектурно SnapCreator является клмент-серверным приложением. Существует так называемый SnapCreator Server, выполняющий код компонента Workflow Engine, который многопоточно обрабатывает поступающие от Агентов и собственного GUI и/или CLI запросы. Так как API открыт, то использовать SnapCreator могут любые внешние системы, например это могут быть коммандлеты PowerShell, другие продукты NetApp, такие как Unified Manager (для него есть свой собственный API), и даже собственные самописанные системы клиентов.

“Другим концом” Snap Creator Server взаимодействует с внутренним API Data ONTAP, обеспечивая все нужные вызовы и отдачу команд.
Конфигурации, jobs, и метаданные плагинов хранятся в специальной структуре - Репозитории (Repository / Extended Repository). Расписания задач, сами задачи (jobs), пользователи и их права доступа (RBAC) хранятся в базе данных (Database).

Наконец, специальный API есть для “клиентов”, агентов SnapCreator.

Посмотрим теперь подробнее на систему SnapCreator со стороны Агента.

Агент - это программный продукт, написанный на Java, чтобы многопоточно выполняться на всех поддерживаемых OS. В ранних версиях в качестве транспорта использовался обычный HTTP, начиная с версии 4.1 взаимодействие Агента и Сервера полностью шифруется в HTTPS.
Основным компонентом, ядром SC Agent является Operation/Execution Manager.
Ядро выполняет запросы от плагинов, которые могут быть как нативными на Джава, так и поддерживаться ранее написанные плагины “не-Java” (значительное их количество для разных программных систем было написано для версий SC 3.6 и 4.0, существовавших ранее), в том числе и на разных скриптовых языках, Perl, PowerShell, даже на UNIX Shell.

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

После выхода FAS8000 и Data ONTAP 8.2.1, обновилась рекомендация NetApp по использованию и числу портов 10G Ethernet, задействованных в кластерном интерконнекте, закрытой внутренней сети обмена данными между контроллерами, входящими в один кластер (тот, что именно кластер, в терминах clustered Data ONTAP, или, по старому, C-mode).
Если раньше для подключения в Interconnect использовались два порта 10G на каждом контроллере (каждый - в свой коммутатор, конечно, для надежности и отказоустойчивости, то новая рекомендация - использовать для старших систем по два таких порта, итого - четыре на контроллер. Так как onboard портов у FAS8040/8060 как раз четыре на контроллер, то эта рекомендация не будет создавать особенных сложностей.

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

Трафик интерконнекта состоит, в первую очередь, из трафика между LIF, то есть логического интерфейса SVM, Stotage Virtual Machine (или, по старому, VServer), и ее данными, которые могут оказаться, например в результате миграции SVM, на дисках, обслуживаемых другими контролерами. В этом случае трафик, входя через физические порты, привязанные к LIF с одного контроллера, достигнет своих данных, расположенных на дисках другого контроллера, пройдя через кластерный интерконнект (в терминах NetApp это называется remote workload).
А так как увеличившаяся мощность контроллера и объем NVRAM существенно лучше обрабатывают ряд “трудных” для контроллеров NetApp нагрузок, например linear-типа, способных нагрузить интерконнект трафиком, возникла необходимость рекомендовать решение, снимающее это потенциальное узкое место.

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

В Tech ONTAP (это, если вы не получаете, ежемесячный newsletter у NetApp), статья Стивена Миллера, старшего технического директора NetApp и архитектора платформ, фактического “создателя”, на протяжении 6 лет, всех платформ NetApp, начиная от FAS3100.
Статья техническая, и, как всегда, “по делу”, посвященная подробностям и деталям устройства новых контроллеров FAS8000.

Вот вам, для затравки, картинка задней панели новых контроллеров, 8020 и 8040/8060:

Некоторые факты и реплики, показавшиеся интересными и выдернутые из текста:
“Мы используем специальные инструкции, появившиеся в семействе процессоров Sandy Bridge, и сотрудничаем с Intel, чтобы использовать (в будущих релизах софта? romx) инструкции для шифрования, компрессии, а также Advanced Vector Extensions, которая позволяет одной инструкцией обрабатывать множественные фрагменты данных”

“Мы используем схему с одним DIMM на канал памяти, чтобы максимально расширить полосу пропускания и увеличить производительность памяти. FAS8060 дает до 85Gb/s пропускной канала от ядер к памяти”

“Новый дизайн NVRAM. Нынешний NVRAM9 имеет вдвое шире полосу пропускания, чем NVRAM8 (в 3200/6200, romx)”
“Увеличенный NVRAM улучшает производительность записей большого объема последовательного доступа. Многие нагрузки произвольного характера также имеют значительную последовательную компоненту, например в OLTP последовательно пишутся логи.”

“NetApp - первопроходец технологии PCIe Gen3, на протяжении двух лет мы вылавливали баги и нестабильности, чтобы обеспечить стабильную работу новой платформы. Все FAS8000 построены с использованием PCIe Gen3. В FAS8060 используется 80 каналов Gen3 (вместо 72 Gen2 каналов в 6220), что удвоило полосу пропускания ввода-вывода. В FAS8040 и FAS8020 используется по 40 каналов Gen3, что в 10 раз расширяет их внутреннюю полосу пропускания, в сравнении с предшественниками.”

“Каждый контроллер FAS8000 оснащен четырьмя основными типами “набортных” портов: GbE, SAS, 10GbE, и Unified Target Adapter 2 (UTA2). В FAS8020 по два порта каждого типа (четыре на HA-пару), а в FAS8040 и FAS8060 по четыре порта каждого типа (восемь на HA-пару).”

“Порты UTA2 применены впервые в индустрии. Порты, сконфигурированные как FC 16G оптимальны для подключения внешних, виртуализуемых систем хранения, через FlexArray. Если у вас нет FC, то вы можете сконфигурировать эти порты как 10Ge, для FCoE, iSCSI, NFS или SMB, так что ничего не пропадет.”

“Порты UTA2 также доступны в виде карт расширения PCIe Gen3, они также могут быть установлены в FAS3220, 3250 и во все модели 6200″

“Порты onboard 10Ge используются для cluster interconnect в Clustered ONTAP, а также для подключения клиентов. Могут быть использованы вместе с портами UTA2.”

“Появились карты расширения 10Gbase-T, работающие по Cat6А и выше. Порты поддерживают 10G и Gigabit Ethernet”

“Контроллеры FAS8000 поддерживают all-flash конфигурацию. Поставляются SSD емкостью 200GB, 400GB, 800GB, и 1.6TB.”

А вот вы знаете, что у нас тут есть русскоязычный форум, с участием же русскоязычных специалистов, работающих в NetApp? Не знали? А он - есть :)
Это я к чему, к тому, что недавно там был обнаружен интересный топик, который будет полезен тем, кто пытается разобраться с непростой темой аггрегации etherchannel и балансировки по нескольким линкам.
https://communities.netapp.com/thread/32967

Если вы занимаетесь NetApp, и при этом еще не там - рекомендую зарегистрироваться (читать можно и так), и подписаться на rss. ??ногда там бывают полезные для жизни темы. Да и возможность спросить на русском тоже бывает порой неоценима.

Как вы уже заметили, в NetApp вот уже пару лет как перевели “семерку”, Data ONTAP 7-mode, куда входят как “классическая” линейка 7.х.х, так и Data ONTAP 8.x 7-mode, в состояние stable, и новые фичи в них практически не появляются, а все усилия разработчиков направлены на развитие и разработку Cluster mode, или как она сейчас стала часто называться в документации Clustered Data ONTAP. Уже само появление “личного имени” свидетельствует о том, что это – окончательный продукт, в представлении NetApp (затянувшийся) переходный период подошел к концу. Это, безусловно, очень рискованный период в жизни компании (любой компании), так как Clustered Data ONTAP пока еще не стал массовым и все еще не “мэйнстрим” в представлениях клиентов. Однако, NetApp не теряет терпения, и новыми фичами, такими как SMB 3.0, NFS 4.1 и pNFS, и прочими полезными штуками, старается перетянуть пользователей на новую, прогрессивную платформу с большим будущим.

Одной из новинок Clustered ONTAP стал полноценный Storage QoS. В принципе, псевдо-QoS в нетапповских стораджах был и раньше, он назывался FlexShare, но говоря о нем NetApp всегда старался уточнить, что это, ну, “не совсем настоящий QoS”, как, допустим, кооперативная многозадачность ранних Windows и MacOS Classic была лишь “псевдо”-многозадачностью. Конечно, это лучше чем ничего, многие стораджи, других вендоров, и такой-то не имеют. Но все же не следует забывать, что FlexShare это просто способ отдать побольше приоритета в тиках системы тому, данные с которого мы считаем важными, за счет того, что мы заберем их у того тома, данные с которого мы считаем не такими важными.

Однако подлинный QoS это не просто перераспределение приоритетов системы, это возможность задать некоторую гарантированную “полосу” в ресурсах. В особенности это стало важно после того, как появилась Clustered Data ONTAP, в которой multi-tenancy, то есть “сожительство” нескольких разнородных задач в рамках одной системы и одного контроллера такой системы стала не экзотикой, а нормальной повседневной работой. Для такой работы несомненно нужен полноценный QoS в рамках системы в целом, гибко назначаемый по потребителям, которые могут мигрировать по контроллерам кластерной системы, а не просто смещенные приоритеты обслуживания для какого-то тома, привязанные к данному контроллеру.

?? вот, в 8.2 появился полноценный планировщик ввода-вывода, который позволяет назначать политики с лимитами на отдельный SVM, Storage Virtual Machine, как теперь, если вы помните, решено, для упрощения понимания, называть Vserver в Clustered ONTAP.

Вы можете задать на отдельный “виртуальный нетапп”, живущий в кластерной системе, и ресурсов в нем, его лимиты по IOPS или же по MB/s ввода-вывода (но не одновременно, отметьте это ограничение). Следуя модели “политик” (policy), ограничение задается для такой созданной политики, которая затем назначается для SVM (Vserver) в целом, или же на его отдельный том, LUN, или файлы в нем. На кластер контроллеров вы можете задать до 3500 политик, то есть решение подойдет даже для довольно больших по масштабам систем.

“Внутри” назначенных политик действует правило равных долей для всех объектов, которым назначена эта политика, например томов или LUN-ов. Таким образом, задача с более активной рабочей нагрузкой не “съест” все ресурсы ввода-вывода у задач с меньшим траффиком, они в равной мере получат заданный в политике лимит ресурса.

QoS не разделяет операции чтения или записи, соответственно нельзя отдельно ограничить поток ввода-вывода только на чтение или только на запись.

??спользовать QoS можно, например, для ограничения производительности ввода-вывода определенных приложений, к примеру сервер резервного копирования может, при начавшемся процессе резервного копирования, очень быстро “съесть” всю доступную полосу ввода-вывода контроллера, “задавив” трафиком при этом всех своих соседей по кластеру. Можно ограничить ресурсы SVM ряда подразделений, живущих в том же кластере, например задачи R&D, чтобы случайный эксперимент на их SVM не смог повлиять на доступность продакшн-систем в том же кластере. Наконец, можно обеспечивать гарантированную полосу или величину IOPS (SLA) для особо критичных задач в облачной структуре, либо наоборот, максимально доступные им ресурсы.

Storage QoS включена в Clustered Data ONTAP 8.2, и не требует лицензии, и работает на любой системе, поддерживающей cDOT 8.2.

??так, в прошлом посте я мельком упомянул, что кроме 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.

На прошлой неделе мы начали собирать в кучку все то, что мы знаем о процессе reallocate в Data ONTAP. В части первой я особо остановился на том, чем отличается знакомая вам всем “фрагментация” на файловых системах типа FAT, и чем она отличается от inode-овых экстентных FS, ведущих свое происхождение от BSD, и почему нельзя напрямую называть non-contiguous block allocation – “фрагментацией”, как это часто делается в говнилках. Равно как и называть процесс reallocate – “дефрагментацией”, хотя отчасти в его задачу действительно входит процедура оптимизации размещения блоков WAFL. Сегодня сосредоточимся именно на reallocate и его работе.

Одна из ключевых проблем WAFL, требующих использования reallocate, это так называемые “дисковые hot spots” аномально загруженные физические диски в нем, если брать их в сравнении с остальными дисками на aggregate. Происходит это вот от чего обычно.

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

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

Но как вы, должно быть помните, принципы работы WAFL таковы, что записываемые, и даже изменяемые в уже записанных блоках данные, не записываются в “старые места”, а пишутся на пространство в пуле свободных блоков. В ситуации же, когда основные диски уже были почти полны (как это и бывает обычно перед расширением), а новых добавлено немного, у нас получается картина, когда пространство пула свободных блоков почти все сосредоточено на этих нескольких добавленных (и поэтому, естественно, пока пустых) дисках. А так как изменяемые и записываемые данные обычно автоматически являются и самыми “горячими”, ведь скорее всего вы и прочитаете те данные, которые только что записали, они свежие и активные, куда активнее чем то, что там где-то в глубинах терабайтов лежит, то возникает ситуация, когда на добавленные в aggregate новые диски постепенно перенесутся все, или большая часть новых, оперативных данных, и, следовательно, существенная часть дисковой нагрузки всего aggregate как на запись, так и на чтение.

Возникает так называемый disk hot spot.

(“свежие”, а потому активные данные, скопились на нескольких добавленных дисках)

Оценить сравнительную загрузку физических дисков в aggregate можно с помощью вывода команды stats, или искользуя скрипты, их использующие, о некоторых я уже писал. Если вы уже побежали мерять свою систему, замечание вдогонку: вы, возможно, заметите на ней два сильно недозагруженных, по сравнению с прочими, диска в каждой RAID-группе (это видно и на скриншоте в посте выше). Да, это Parity и Double Parity диски RAID-группы, при штатной работе системы это нормально, не обращайте на это внимания, смотрите на те, которые выше и постоянно выше среднего по группе загружены.

(обратите внимание на параметр ut% (utilization) для диска 0d.26 на скриншоте выше)

Кстати сказать, описанная выше ситуация не является эксклюзивной для NetApp, например та же проблема встречается в disk pools на EMC VNX, и это именно та причина, по которой EMC не рекомендует добавлять в пул лишь по нескольку отдельных дисков, а только в количестве, кратном уже имеющейся емости RAID-групп пула, что очевидно, довольно жестокая негибкость для кастомера. У VNX ситуация усложняется еще и тем, что довольно долго после релиза системы у них не было вообще никаких средств реаллокации блоков и способов развномерно “растасовать” блоки при расширении пула.

Вот как раз в такой ситации нам на помошь придеть reallocation. С его помощью вы сможете равномерно перераспределить блоки с имеющихся дисков, на все, включая новые добавленые. Одна из причин возникновения “хотспотов” таким образом будет устранена. Помните, однако, что вам необходимо проделать это со всеми томами данного aggregate, о этом аспекте мы поговорим подробнее в части третьей. На приведенном рисунке я нарисовал простейшую схему с одним томом на aggregate, обычно же у вас несколько томов, а операция volume reallocate работает с отдельным томом, а не с aggregate в целом. Существует, однако, опция aggregate reallocation, но она предназначена для другого, об этом также отдельно.

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

Например в communities.netapp я однажды нашел такое мини-исследование по результатам добавления дисковой полки к системе FAS2020 (aggr0 – 10 дисков, default RAID group size (16)). Дискова полка на 14 дисков к уже имеющимся 12 дискам  – это не тот случай, который вызовет явно наблюдаемые хотспоты дисков, но все же результаты интересные:

Крайние правые столбцы – система на нагрузке под SQL Server до добавления дисков (64K blocks, 100% random, 65% read/35% write). Средняя группа столбцов – сразу после добавления и без reallocate. Как вы видите, предсказуемо выросли IOPS, уменьшился responce time. Однако после добавления полки и измерения была проведена volume reallocation (в процессе ее CPU util - ~70-75%, disk util ~65%) с параметрами:

reallocate –f –p /vol/volX

Вы видите, что в результате несколько выросли показатели по IOPS, и несколько снизились показатели response time. Непринципиально, но процентов 15 таким образом удалось на системе наковырять. По моим оценкам польза от reallocation (и, кстати, соответственно, “вред” от пресловутой “фрагментации на NetApp”, вниманию любителей верить говнилкам) примерно в 10-15% и укладывается, в самых синтетически ужасных случаях на моих тестах – 20-25%.

Продлолжение следует.

Человеку, который вот уже вторую неделю ходит в блог по поисковой фразе “дефолтный пароль netapp в консоли” (и, разумеется, ничего не находит, но почему-то продолжает ходить): да нету у него никакого “дефолтного пароля”, это же не D-Link какой-нибудь. :)

Когда система включается в первый раз, с проводящего это включение в принудительном порядке спрашивается пароль суперпользователя, и пока он его не введет, процесс установки невозможно продолжить. Таким образом, никакого “дефолтного пароля” у NetApp в консоли – НЕТ. Есть пароль, в явном виде установленный самостоятельно его владельцем.