Archive for сентября 2013

Reallocation в Data ONTAP. Часть 2.

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

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

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

image

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

image

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

image

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

image

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

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

netapp-disk-hotspot

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

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

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

image

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

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

 

image

Крайние правые столбцы – система на нагрузке под 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 в консоли – НЕТ. Есть пароль, в явном виде установленный самостоятельно его владельцем.

Reallocation в Data ONTAP. Часть 1.

Многие мои посты тут пишутся заранее, и потом отлеживаются. Некоторые – отлеживаются в моей голове. Но среди них есть порой и настоящие старожилы, вот, например, посту на тему того, как работает reallocation в WAFL и Data ONTAP, скоро уж три года. Все это время я пытаюсь сложить полноценную, непротиворечивую и исчерпывающую картину вопроса, чтобы изложить это все в блоге. Проблема в том, что, вследствие закрытости многих механизмов работы Data ONTAP (а также того, что они меняются, а закрытость позволяет не рассказывать публике об изменениях в деталях), многие вопросы остаются для меня не исчерпывающе отвеченными. Но, тем не менее, давайте перестанем тянуть кота за хвост, и приступим к тому, что нам известно, и о чем можно рассказать.

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

О том, насколько на самом деле так называемая “фрагментация” на WAFL влияет на производительность я уже писал не раз, не стану повторяться, все есть по ссылкам выше, сегодня поговорим об обратном процессе, что же представляет собой процесс reallocation.

Reallocation – это фоновый процесс в OS Data ONTAP, который оптимизирует и перераспределяет структуру хранения блоков WAFL для оптимизации к ним доступа. Он близко связан с тем, как именно происходит запись данных на WAFL в OS Data ONTAP. Не вполне корректно называть процесс реаллокации - “дефрагментацией”, как и проводить аналогии с файловой системой, например FAT, построенной на совсем иных  принципах выделения пространства. Многие годы считалось, например, что файловые системы Linux (читай inode-овые BSD-like файловые системы, с использованием идей которых создана и WAFL) вообще не подвержены фрагментации, так, до ext4 там вообще не существовало штатных средств “дефрагментации”, и ничего, работали же, а многие системы в продакшне и на ext3fs работают и до сих пор. Но, конечно, фрагментация, или, корректнее non-contiguous file allocation существует и в них, и с ростом дисковой нагрузки на серверные системы в целом, и увеличении объемов хранения, несомненно эта проблема стала все более заметной. Оставим сейчас в стороне спор, насколько фрагментация данных влияет в условиях, когда практически 100% workload составляет не sequental, а random access, об этом я уже писал, поговорим о том, что же можно сделать для оптимизации структуры хранения путем вот этой самой block reallocation. Подобной “фрагментации” данных подверженны все системы хранения (особенно использующие современные фишечки работы с данныеми, такие как снэпшоты, дисковые пулы, thin provisioning, а не просто dumb SCSI LUN). Но не все умеют с этим бороться.
NetApp – умеет.

В документации сказано скупо:

reallocate - Command for managing reallocation of files, LUNs, volumes, and aggregates

The reallocate family of commands manages the allocation, or layout optimization, of large files and
LUNs on a node. Additionally all files in a volume may be reallocated, and the block layout of
aggregates may be optimized. Using the reallocate command, layout measurement and optimization
(reallocation) can be automated.

Определенную сложность для пользователей вызывает тот факт, что процесс reallocate не запущен на системе по умолчанию. Сделано это, по всей видимости, исходя из главного принципа, которым руководствуется NetApp, назначая свои значения по умолчанию. Даже если вы не прочтете ни одной страницы документации, и запустите систему хранения “энтером” (то есть просто тупо давя Enter на все вопросы, соглашаясь на все установки по умолчанию), то даже при сочетании самых нелепых решений, данные не будут повреждены и система будет, пусть неоптимально, но работать. В общем тот самый врачебный Noli Nocere! - “Не навреди!”. Реаллокация может быть не нужна в ряде профилей использования. Но даже когда она не нужна, а она запущена по умолчанию, и при этом вы об этом не знаете, она неизбежно занимает какую-то долю системных ресурсов, и лучше было бы, чтобы, если уж она запущена, то запущена она была “по делу”, и понимающим это человеком.

Вот поэтому по умолчанию, на свежеустановленной системе процесс reallocation не запущен автоматически и не работает.

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

  1. Насколько сильно, в процентном отношении, заполнены активными, изменяющимися, а не просто хранящимися данными, заполнены диски, конкретнее - тома на aggregate?
  2. Каков процент свободного места на томах и aggregate? (помните, что WAFL – структура thin by design, и для нее 100% занятый пустыми томами aggregate – пустой)
  3. Насколько активно используется на томах deduplication, и сколько места она у вас высвобождает.
  4. Наконец, насколько часто вы расширяли тома и aggregate физическими дисками?

На первые два вопроса ответ, и то как он соотносится с темой необходимости реаллокации, вы, скорее всего уже знаете. Если на диске в момент записи достаточно свободного места, то подсистема, выделяющая на диске место по запросу OS в форме дисковых экстентов, или протяженных сегментов блоков, с легкостью найдет и выделит процессу записи любое нужное количество блоков в единой цепочке. Именно по этой причине в таких файловых системах, как ext2/3 и NTFS фрагментация файлов в самом деле принципиально ниже, чем в FAT, где OS не использует такое “групповое выделение” блоков, и занимает их по порядку, один за одним, не обращая внимание на то, где и как они расположены. Разумеется такой вариант, особенно в активной и, как это называется, aged, то есть давно используемой в работе файловой системе, вызывает существенное дробление фрагментов файла по диску.

Это не так в уже перечисленных “BSD-like” системах и NTFS. Пока на файловой системе есть достаточно свободного места, механизм выделения цепочек последовательных блоков работает хорошо. Сложности начинаются тогда, когда файловая система заполняется файлами, которые произвольно создаются и удаляются, и постепенно структура блоков данных начинает напоминать сыр с его дырками, когда вроде место и есть, но оно все “пузырьками”. Дело в том, что если последовательный экстент блоков нужной длины на дисковом томе найти не удается (а данные писать все ж таки надо), то описываемая подсистема OS говорит файловой системе: “ну ОК, давай мне два покороче, пусть в разных местах. Нету? Ну что-ж, ну а четыре еще короче есть?”. И такое дробление продолжается до тех пор, пока вся последовательность, ожидающая записи на диски не будет записана.

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

image

Напомню, что рекомендуется поддерживать 10-15% свободного места на томе и aggregate для нормальной работы описанных выше механизмов (это примерно совпадает с рекомендациями MS для NTFS), причем на уровне aggregate это пространство уже зарезервировано в WAFL reserve, недоступном пользователю.

Подводя итоги по этой части хочу специально указать: это рекомендация, но не требование. Вы МОЖЕТЕ заполнить диск данными на все 100% его емкости. И в ряде случаев, например как на картинке выше, где приведен скриншот моего лэптопа, и где выделенный диск есть хранилище бэкапов, фильмов и музыки, то есть записи на него нерандомны и крайне редки, это не имеет большого значения и мало влияет на его производительность.

Но если ваши данные активно перезаписываются, и у вас есть возможность не заливать их на том “с горкой”, то оставьте побольше свободного места на томе (и на aggregate для thin-томов) – не пожалеете :)

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

NetApp MetroCluster в Германии

Иногда роясь в старых постах коллег по блоггингу удается находить что-нибудь интересное. Я помнил тот занимательный факт, что системы NetApp MetroCluster вот уже много лет очень хорошо продаются в Германии. Вот уж не знаю почему так, видимо продавцы хорошие, знают подход, но вот прямо очень хорошо. Но никогда не видел фактических цифр. А вот недавно, просматривая снимки сессий прошлогоднего VMworld 2012, нашел вот такой кадр:

DSCN0844

Более 6000 систем MetroCluster проданы в одной только Германии, из около 11 тысяч по всему миру!

Доли рынка в сегменте Enterprise SAN and NAS: 2013

Интересные тут картинки почта в клювике принесла. Как вы знаете, компания IDC делает регулярные обзоры рынка, оценивая рыночные доли разных брендов. Сам эти отчеты платные и дорогие, поэтому приходится перебиваться тем, что кто-то выложит в паблик. Обычно это делает та компания, которой хочется похвастаться :)

Частенько есть чем у нас похвастаться и NetApp. Поэтому сегодня извлеченные из отчета IDC рыночные доли по суммарному рынку NAS и SAN.

Вот как выглядит обычно широко публикуемый отчет по выручке:

IDCSep2013-revenue

А вот так куда менее публикуемый отчет по доле от поставленной емкости хранения.

IDCSep2013-capacity

Сопоставив их можно попытаться сделать некоторые любопытные выводы. Например они очень хорошо показывают мифичнность утверждения про “дорогие диски у NetApp”, так, видно, что терабайт на NetApp продается, и, следовательно, обходится покупателю, существенно ниже рынка в среднем (причем у IDC суммируется тупой raw capacity проданных дисков, так что с учетом использования RAID-DP выигрыш будет и еще выше).

Видно, как EMC, с выходом VNX, переломила негативную тенденцию падения поставляемых объемов (читай – числа поставляемых стораджей, по видимому), существенная же разница в долях “в терабайтах” и “в миллионах долларов” скорее всего объясняется дорогими hi-end массивами, крайне дорого обходящихся покуателям из расчета “за терабайт”. Видно также, что по росту объемов поставляемых терабайт сегодня NetApp вот уже третий год не имеет равных среди всей шестерки.

Ну и, чтобы два раза не вставать, доли на рынке средств репликации данных в системах хранения. Немножко растет IBM, видимо за счет Storwise.

IDCSep2013-replication

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

Тем не менее вот такие у нас есть упрямые штуки, вне зависимости от того, как вы относитесь к IDC.

RAID & IOPS calculator

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

image

Находится он по адресу: http://www.wmarow.com/strcalc/strcalc.html

Обратите внимание, там же есть еще два калькулятора, не меньшей полезности, RAID calculator и Array estimator.

NB!: Особо отмечу для новичков: RAID-DP не является в терминах данного калькулятора “RAID-6”, и нельзя оценивать его производительность, приравняв RAID-DP к “RAID-6”, принципы его работы – иные, по производительности он близок скорее к RAID-10. Это калькулятор только для “классических” RAID!

Новые версии SnapDrive Win 7.0, SnapManager for SQL 7.0 и Hyper-V 2.0

Тем временем, на прошлй неделе NetApp обновил несколько своих важных утилит “стороны хоста”. Как вы знаете, и многие, уверен, пользуетесь, средствами работы со стораджем на стороне хост-системы. С выходом Server 2012 и 2012 R2, и их новых возможностей, насущно встала необходимость обновления набора хост-инструментов NetApp.

Появилась новая версия SnapDrive, инструмента для создания снэпшотов, LUN-ов и управления ими со стороны сервера. Также этот инструмент предоставляет API для работы многим другим программным хост-средствам NetApp.

Основные новинки это:

  • Поддержка Cluster-mode (наконец-то)
  • Поддержка SMB 3.0
  • Sub-LUN cloning
  • Поддержка командлетов PowerShell 2.0+ для SMB 3.0
  • Virtual Fibre Channel
  • Поддержка gMSA – group Managed Service Account в Windows Server 2012

Опубликован TR-4000: "SnapDrive 7.0 for Windows Best Practices for Clustered Data ONTAP".

SnapManager for Hyper-V обновился до долгожданной версии 2.0

Среди новинок:

  • Интеграция со SnapVault
  • Поддержка не только SAN (FC, iSCSI, FCoE), но и SMB 3.0, в частности теперь поддерживается remote VSS hardware providers
  • Для SMB 3.0 и CSV 2.0 также поддерживаются SnapInfo
  • Поддерживаются gMSA
  • Наконец-то поддерживается восстановление по альтернативному пути (например для DR-сайтов) и восстановление удаленных (deleted) VM из бэкапов типа crash-consistent.
  • Поддерживается установка на remote-хост.

Вместе со всеми обновился и третий важный компонент win-хост инструментов: SnapManager for SQL Server.

Новинки:

  • Поддержка SMB 3.0 (напомню, что пока SMB 3.0 есть только на Cluster-mode!)
  • Интеграция со SnapVault (archived backup могут отправляться на secondary SnapVault на clustered-системе)
  • Восстановление базы данных в другое расположение того же инстанса MS SQL Server
  • Поддержка gMSA и возможность запуска SMSQL из него
  • Улучшена производительность работы для ряда сценариев использования

Все версии опубликованы и доступны пользователям NetApp для скачивания на сайте NetApp Support.

Не забывайте внимательно читать Release Notes перед установкой или обновлением!

Бандлы HDD+SSD для FAS2240

Я тут немного отстаю от bleeding edge новостей, но тем не менее все равно расскажу, вдруг кто-то это пропустил или не увидел на других профильных ресурсах.

Компания ИТ-Град, один из наиболее активных сейчас продавцов NetApp, у себя на сайте объявила распродажную акцию интересных многим бандлов FAS2240-2 и FAS2240-4, в очень правильной и выгодной конфигурации HDD+SSD, для использвания с Flash Pool и Virtual Storage Tiering.

В бандл входит контроллер FAS2240 в двух вариантах – FAS2240-2, это двухюнитовый модульный блок с 24 дисками SAS 600GB (то есть только HDD SAS) или же гибридный вариант, из 20 HDD SAS 900GB, плюс 4 SDD 200GB. Оба варианта могут быть как с Basic software bundle, в который входят протоколы доступа NAS и SAN, thin provisioning, дедупликация, плюс некоторое количество софтверных фич сверх. И в варианте Complete Bundle, это All Inclusive, в котором есть вообще все что есть у NetApp для этой модели, там и репликация SnapMirror, и клоны FlexClone, и лицензии на хостовые утилиты, такие как Virtual Storage Console для VMware vSphere, SnapDrive, и так далее.

Второй вариант, также в двух вариантах, это FAS2240-4, 4U модуль, с дисками SATA, либо 24HDD SATA 1 или же 2TB, либо также как выше, 20 HDD 2TB + 4 SSD 200GB. Все варианты также в двух вариантах софта, с Basic и с Complete Bundle.

Особенно хочу обратить внимание на последний вариант с SATA HDD + SSD в Flash Pool, этот вариант может быть наиболее интересным по price/capacity/performance, так как на значительном числе рабочих нагрузок flash очень эффективно ускоряет работу с емкими, но недостаточно шустрыми SATA, приближая такой вариант к производительности существено более дорогих и менее емких SAS/FC.

Разумеется, такое бывает не в ста процентах случаев, но в значительном числе наиболее распространенных. Проверить как это будет в вашем случае вы можете попробовать в том же ИТ-град, у них есть и собственный центр компетенции с квалифицированным пероналом и установленными стораджами разных классов, так и демопул оборудования, доступный для try&buy.

UPD: Как подсказывают из информированных источников: это общероссийская распродажа, такие бандлы доступны всем партнерам, спрашивайте у ближайшего к вам.

UPD2: Про цены. Я тоже не люблю, когда не показываются в ясном виде цены, но почему это так я писал уже не раз, и последний раз - совсем недавно. Вот еще слова информированного источника:
romx: А есть цены, которые можно называть? Хотя бы ориентировочные?

xxx: К сожалению, нет :( Локальное представительство категорически против.
Формально цена действительна после подтверждения аккаунтом под конкретного заказчика и адрес поставки.
Так что с одной стороны, цена известна, а с другой стороны, подтверждение как и в случае проектных скидок.
На регион в квартал выделяется достаточно большая, но тем не менее определённая квота на кол-во промо бандлов.

18/0.160

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

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.