about NetApp

Я уже упоминал, что начиная с DataONTAP 7.3.1 емкость aggregate в системах NetApp FAS рассчитывается исходя из “правильной” usable емкости дисков, “после налогов и вычетов” и без учета дисков parity.

Вот каковы right-sized емкости используемых в системах NetApp дисков, исчисленных в “двоичных” единицах (по основанию 1024):

При дальнейших расчетах также не забывайте про “основание 1024”, то есть, что
1695466 MiB = 1655,7 GiB = 1,62 TiB

При расчетах в “двоично-десятичной” арифметике для перехода от “мегабайтов” к “гигабайтам” недостаточно “сдвинуть запятую в числе на три позиции влево”, помните об этом . Разница между “терабайтом” и “тебибайтом” составляет почти 10%!

Сегодня в переводах новый автор, это principal technologist регионального представительства NetApp по Австрали и Новой Зеландии, и директор SNIA ANZ - Richard J Martin. Его блог это вообще и в целом довольно отличающееся явление от, увы, распространенного сейчас стиля среди блоггеров “Так как мне не хватает 140 символов моего твиттера, я вынужден написать эти 320 символов в блог, но лучше читайте мой твиттер”, его записи в блог это, порой, настоящие глубокие статьи, которые интересно читать и трудно переводить.

Надеюсь, что он еще не раз появится в моих переводах.

Ричард Мартин, NetApp Australia отвечает на вопрос “как заполненность данными системы хранения влияет на ее производительность?”

How does capacity utilisation affect performance ?

September 10, 2011 storagewithoutborders

Несколько дней назад я получил письмо с вопросом "Каковы рекомендации по максимальному уровню использования пространства системы хранения, не вызывающему падения ее производительности?". С одной стороны такие вопросы раздражают меня, так как чаще всего рождаются из регулярно вбрасываемого FUDa о NetApp, с другой стороны, даже несмотря на то, что правильно спроектированная для стабильного уровня производительности система хранения редко (если такое и вообще возможно) сводится к любой единственной метрике, понимание особенностей использования емкости хранилища и его влияния на производительность, это важный аспект при проектировании вашей системы хранения.

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

Поэтому, отвечая на вопрос, как уровень заполненности системы хранения влияет на ее производительность, мне приходится оговариваться, что "это зависит от ряда факторов", но в большинстве случаев, когда задают такой вопрос, то спрашивающего он интересует для нагрузки с высоким уровнем операций записи, например VDI, некоторые виды online transaction processing, и системы электронной почты.

Если вы рассматриваете такие варианты нагрузки, то можно смотреть наш старый добрый TR-3647 в котором как раз рассматриваются высокие нагрузки со значительными объемами записи, и где говорится:

Структура размещения данных WAFL, используемая в Data ONTAP, оптимизирует записи на диск, для улучшения производительности системы и повышения уровня использования полосы пропускания дисков. Оптимизация в WAFL использует небольшой объем свободного или зарезервированного пространства в пределах aggregate. Для высокой нагрузки, связанной с интенсивной записью, мы рекомендуем оставлять незанятым пространство, равное, в среднем, 10% от usable space, для работы этого оптимизационного процесса. Это пространство не только обеспечивает высокопроизводительную запись, но также работает как буфер при неожиданно возникающих потребностях приложения в свободном месте при объемных записях на диск.

Я видел некоторые бенчмарки, использующие синтетическую нагрузку, где точка перелома графика производительности наблюдалась между 98 и 100% usable емкости, после вычета WAFL reserve, я также видел проблемы производительности, когда люди полностью заполняли все доступное пространство на системе хранения, а затем начинали писать не нее мелкими блоками множество перезаписей данных. Это не является уникальным свойством именно WAFL, в случае любой системы хранения такое ее использование будет довольно плохой идеей, заполнить все пространство на любой структуре данных, а затем пустить на нее объемный random write.

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

Оставляя в стороне тему FUD, (подробный его разбор требует довольно глубокого понимания внутренней архитектуры ONTAP) при рассмотрении того, как влияет заполнение емкости на производительность на системах хранения NetApp FAS, надо хорошо понимать следующие моменты:

1. Для любого конкретного типа рабочей нагрузки и типа системы хранения вы можете достичь только сравнительно ограниченного числа операций на диск, это число на диск 15K RPM составляет, обычно менее 250.
2. Производительность системы хранения обычно определяется тем, на сколько дисков может быть распараллелена нагрузка ввода-вывода.
3. Большинство производителей систем хранения предоставляют для рабочей нагрузки ввода-вывода диски, объединенные в RAID-10, который использует вдвое больше raw-дисков на данный объем usable. При этом NetApp использует RAID-DP, который не требует удваивать количество дисковых шпинделей на заданный объем usable данных.
4. В большинстве бенчмарков (см. например SPC-1), NetApp использует для тестирования все доступное дисковое пространство, кроме 10% от usable space (в соответствии с написанным в TR-3647) что дает пользователю примерно 60% от емкости raw дисков, при этом достигая того же уровня IOPS/диск, которое другие производители получают при уровне usable в 30% от raw. Таким образом, равную производительность из расчет на жесткий диск мы обеспечиваем при на 10% большем уровне usable пространства, чем другие производители могут теоретически достичь при использовании RAID-10.

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

Хотя все это действительно правда, следует отметить, что тут есть и один недостаток. Хотя величина IOPS/Spindle более-менее та же, величина "плотности IOPS" (IOPS density) измеренная в IOPS/GB для результатов NetApp SPC-1 составляет примерно половину от решений конкурентов, (те же IOPS , 2x данных = вдвое меньше плотность). Хотя это на самом деле и сложнее сделать, за счет более низкого соотношения cache/data, если у вас есть приложение, которое требует очень высокой плотности IOPS/GB (например некоторые инфраструктуры VDI), тогда вы можете не использовать всю имеющуюся у вас дополнительную емкость под эту нагрузку ввода-вывода. Все это дает вам, в результате, возможность выбора из трех вариантов.

1. Не использовать это дополнительное место, оставив его незанятым на aggregate, позволить работать на нем оптимизации записей и получить лучшую производительность.
2. ??спользовать дополнительное место, например для данных некритичных к производительности, таким как хранение снэпшотов, или зеркальная реплика данных, или архивы, и так далее, и установить этой нагрузке пониженный приоритет с помощью FlexShare.
3. Установить карту Flash Cache, которая удвоит эффективные показатели IOPS (зависит от вида нагрузки, конечно) на физический диск, что обойдется дешевле, и сэкономит ресурсы, чем удвоение количества физических дисков.

Если вы поступаете иначе, то вы можете получить ситуацию, когда наша высокая эффективность использования пространства позволяет пользователю запустить слишком большую нагрузку по вводу-выводу на недостаточном количестве физических жестких дисков, и, к сожалению, снова снова порождает пресловутый и бесконечно гуляющий FUD о "Netapp Capacity / Performance".

Он некорректен прежде всего потому, что причина тут не в каких-то тонкостях Data ONTAP или WAFL, а в том, что на систему, сайзинг которой был проведен для рабочей нагрузки X, помещают 3X данных, так как "на дисках еще есть место", и весь ввод-вывод этих 2-3-кратного объема данных наваливается на дисковые шпиндели, запланированные под совсем другой уровень нагрузки и объемов.

Для того, чтобы сделать счастливыми, и, что немаловажно, поддерживать это состояние в пользователях вашей системы хранения, вам, как администратору, нужно уметь управлять не только доступной вам емкостью, но и доступной производительностью системы хранения. Чаще всего у вас будет исчерпываться одно раньше, чем другое, и работа эффективной IT инфраструктры означает умение балансировать рабочую нагрузку между этими двумя ресурсами. В первую очередь это означает, что вы потратили определенное время измеряя и мониторя емкость и производительность вашей системы. Кроме этого вам следует настроить вашу систему так чтобы иметь возможность мигрировать и ребалансировать нагрузку между ресурсными пулами, или же иметь возможность легко добавлять дополнительную производительность для имеющейся нагрузки не прерывая нормальной работы системы, что может быть осуществлено с помощью таких технологий, как Storage DRS в vSphere 5, или Data Motion и Virtual Storage Tiering в Data ONTAP.

Когда вы наблюдаете за параметрами вашей системы хранения, вы можете своевременно принять меры, до того, как какие-либо проблемы проявятся. У NetApp есть множество великолепных инструментов по мониторингу производительности всей системы хранения. Performance Advisor дает вам визуализированные и настраиваемые алерты и пороги их срабатывания для встроенных метрик производительности, доступных в каждой системе хранения FAS, а OnCommand Insight Balance предоставляет углубленный отчет и упреждающий анализ для всей вашей виртуализованной инфраструктуры, включающей, в том числе, и стороннее, не-NetApp, оборудование.

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

Хотя я понимаю весь соблазн вернуться к старой практике, привычной для "классических" систем хранения, когда для системы хранения почти нет шансов превысить ее возможности по IOPS, прежде чем она исчерпает свои возможности по емкости, это почти всегда невероятно расточительно, и ведет, по моему опыту, к уровню использования емкости около 20% и менее, и приводит к экономически неоправданной цене/GB для таких “Tier-1″ хранилищ. Возможно еще настанут "сытные годы", когда администраторы будут снова иметь роскошь не обращать внимания на цену решения, или, быть может, вы окажетесь в такой редкой отрасли, где "цена не имеет значения", однако для остальных нынешние времена - времена начистить и привести в готовность свои навыки мониторинга, настройки и оптимизации. Сегодня спрос есть на умение делать больше с меньшими затратами, и надо учиться этому.

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

Что на самом деле хочет купить пользователь, пришедший за системой хранения?

• Производительность в random IOPS. Это, пожалуй, определяющий фактор, который по праву занимает первое место в списке. Производительность – решает. В наше время трехтерабайтных дисков на рынке, емкость, как я уже и писал, зачастую, получается как “побочный эффект” достижения определенного уровня производительности в IOPS. Сперва надо удовлетворить требованию по производительности в random IOPS, читай по количеству физических дисков в системе, а там, глядишь, емкость и так получилась порядочная. Опять же, системы хранения, где емкость является определяющим фактором, когда производительность не важна совсем, это довольно узкая ниша архивных хранилищ. Уверен ли спрашивающий про “терабайты”, что ему совсем не нужна производительность в random IOPS на получившемся? Не дал ли он себя заморочить величинами “паспортной” производительности интерфейса SATA-II или Fibre Channel? Что это за задача, где производительность работы на получившемся сторадже не нужна?
• “Фичи”, возможности использования системы хранения. Современные системы хранения уже давно не просто “банки с байтами”. “Хранение” в них всего лишь одна из множества возможностей. Даже сама пресловутая емкость хранилища может сильно зависеть от того, какие возможности системы хранения пользователем задействуются. Дедупликация, снэпшоты, клоны, unified-концепция хранения, thin provisioning, storage tiering, очень часто эти функциональные возможности, позволяет значительно снизить так называемый data footprint, то есть занимаемый данными объем на хранилище. То, что без использования “фич” заняло бы куда больший объем, с “фичами” поместится в куда меньший. Что уж говорить про многие новые возможности использования хранилища, которые эти фичи дают, и о которых пользователь, покупающий “объем” часто еще просто не задумывался?
• Надежность хранения данных и их защиту. Что толку от производительной и фичастой системы хранения, если она при этом ненадежна, если жить с ней вы будете как на пороховой бочке? RAID-0 это, наверное, очень быстро. Но недолго :) “Жить быстро, умереть молодым” это для рокенрола хорошо. Но вряд ли это хорошо для данных вашей компании. А сегодня уже и RAID-5, судя по всему, уже стоит рассматривать в ряду ненадежных (в отличие от RAID-0, который ненадежный, но, хотя бы, быстрый, RAID-5 при этом еще и не быстрый;). Диски SATA, особенно большого размера, уже просто в обязательном порядке должны предполагать использование их в RAID-6. ?? не забывайте – надежность IT инфраструктуры компании, как и скорость эскадры, которая определяется скоростью самого медленного корабля, определяется надежностью наименее надежного ее компонента. ??ли как говорил один мой знакомый: “Неважно, насколько быстра ваша система хранения, если в данный момент она не работает”. Но надежность и защита данных это не только RAID, часто она не исчерпывается локальными возможностями стораджа. Это может быть и репликация, это и средства резервного копирования и восстановления данных, например снэпшоты уровня стораджа или приложения, и так далее. А как насчет гарантийного сервиса в вашем регионе и его стоимости?
• ??нтеграцию с используемым софтом. Несмотря на то, что “настоящий сисадмин пользуется исключительно консолью” на практике все гораздо сложнее. ?? выбор между тремя ничего не успевающими сисадминами, ежемесячно еще и требующими за свою напряженную работу прибавки зарплаты, и одним, который все успевает, пользуясь удобными инструментами, предоставляемыми вендором системы хранения, может также заметно повлиять на итоговую стоимость решения. ??нтеграция это не просто красивые маркетинговые слова. Поддержка специфических возможностей программного решения, в качестве примера могу привести поддержку VAAI для продуктов VMware, или “аппаратную” поддержку deploy/redeploy виртуальных машин на уровне возможностей стораджа, может напрямую отразиться и на производительности, и, в конечном счете, на цене решения.
• Поддержку и совместимость с используемыми софтовыми решениями. Важный аспект – наличие поддержки использования покупаемой системы хранения со стороны производителя программного решения, присутствия в Hardware Compatibility Lists (HCL), Support Matrix, существования описанных Best Practices применения, и так далее. В противном случае вы рискуете остаться со своими проблемами один на один, и пользоваться “помощью” только различных форумов. Наличие подтвержденной поддержки как со стороны разработчика софта данной модели стораджа, так и со стороны производителя стораджа – данного софта, обычно гарантирует минимальные проблемы на этапе внедрения. Также не забывайте, что supported (поддерживаемое) это не то же самое, что functional (работающее).
• Экономические аспекты. Долгосрочные затраты на эксплуатацию, поддержку, администрирование. Несмотря на то, что TCO (Total Cost of Ownership – “совокупная стоимость владения”) в России традиционно игнорируется, все больше пользователей начинает осмыслять тот факт, что заплатить за покупку – это еще не все затраты на систему хранения. Часто это только самое начало трат. Стораджем надо не только “завладеть”, но и “содержать” его. ??, часто, стоимость содержания (куда входят эксплуатационные расходы, сервис и прочее)бывает для пользователя очень неприятным сюрпризом. Это вам подтвердит любой владелец, например, дорогого и редкого (в вашей местности) автомобиля. Не забывайте также, что в сегодняшних датацентрах примерно половина потребляемого ими электричества, это потребление не связанное напрямую с IT-оборудованием. Это потребление кондиционеров и прочих “инфраструктурных элементов”. Половина! Снижение затрат на электропитание, охлаждение, затрат на инсталляцию, сервис, эксплуатационное обслуживание и warranty, отличающихся у разных вендоров и разных моделей, может отлиться во вполне полновесные доллары экономии.

Покупать систему хранения исходя из единственного аспекта – ее емкости, сегодня также нелепо, как покупать автомобиль в автосалоне, исходя из его максимальной скорости. “Мне нужен автомобиль, который может ехать со скоростью 140 километров в час” говорит покупатель в салоне. Даже если оставить в стороне то, что сегодня любой новый автомобиль может ехать со скоростью 140 километров в час, очевидно, что это не является для покупателя основным критерием покупки (даже если он сам, по непониманию темы, пока еще и не догадывается об этом). ??, разумеется, грамотный пресейл сегодня знает, что когда покупатель говорит, что хочет “сторадж на двадцать терабайт”, на самом деле он хотел сказать совсем не это. Он хотел сказать, что:

“Мы хотим развернуть виртуальную серверную инфраструктуру, ориентировочно на 20 серверов. Задачи переносимых в виртуальную инфраструктуру серверов сегодня это два файловых сервера, почта MS Exchange 2010, сервера баз данных MS SQL Server 2005 для бизнес-задач и девелоперский PostgreSQL, контроллер домена и около десятка разнообразных серверов для веб-разработчиков и тестировщиков. Ожидаемая нагрузка на хранилище по вводу-выводу, на этапе запуска, для текущих наших задач, около 7-15 тысяч IOPS в steady random read/write, при оценочном профиле read/write – 75%/25%. Мы ожидаем, в ближайшие год-два, минимум двукратный рост нагрузки по вводу-выводу и примерно 50-75% рост по емкости. Мы планируем использовать гипервизор VMware vSphere, и, возможно Xen Desktop или VMware View для планируемого VDI на 300 рабочих мест. В следующем году мы хотим также развернуть резервный датацентр, куда будем реплицировать данные с основного датацентра, для обеспечения отказоустойчивости и непрерывности бизнеса. Достаточные требования по RPO/RTO для наших бизнес-задач 4 часа RPO и 30 минут RTO.”

Но, против воли, у него вырвалось про “20 терабайт”. :)

PS. Вы должно быть заметили, что ни разу в этом посте я не сказал слово “NetApp”? :)

Вокруг ситуации с usable capacity на NetApp накручено очень много довольно низкопробного манипулирования и FUD-а, см. например мою же статью в блоге, посвященную разоблачению одного из таких текстов.

Как вы знаете, системы на поддержке отсылают в Support Center в NetApp данные о своем состоянии, в том числе и о конфигурации. ??нтересный график был обнаружен в одной из технических презентаций NetApp. Это анализ соотношения между raw и usable capacity для реальных, рабочих систем NetApp, установленных у клиентов компании, эксплуатирующихся в настоящее время и отсылающих сообщения autosupport. В среднем, для 7597 рассмотренных систем, их usable capacity, то есть доступная для использования емкость хранения, емкость дисков за вычетом RAID-penalty (parity drives), spares, WAFL-metadata, reservations и прочего, составила 66,27% от их raw.

Такие дела. Как видите, в реальной жизни достигнутая на системах NetApp средняя величина usable всего на 3% хуже теоретически рассчитанной мной в посте с разоблачением FUD-а.

У одного из нетапповских блоггеров увидел хорошую статью, перевод фрагмента которой хочу опубликовать у себя.

Одной из самых популярных “страшилок-говнилок” в отношении NetApp является пугалка о том, как неэффективно расходуется пространство на системах хранения NetApp, как мало получается usable space из данного объема raw. Пожалуй, по популярности эта “говнилка” у наших конкуретнов идет сразу за страшилкой о фрагментации (и ее мифическим “катастрофическим влиянием на производительность”), и за пугалкой про “эмуляцию LUN поверх файловой системы”. Я уже писал ранее про то, как обстоит дело с первой, и рассказывал как устроена организация данных на “низком уровне” в WAFL, объясняющая ситуацию со со второй.

Пришла пора разобрать где правда в третьей.
??так, правда ли, что usable space на NetApp получается значительно меньше на том же объеме raw, например при сравнении с “более традиционными” системами?

Давайте разберем пример, хоть и не исчерпывающий, но довольно зрелищный.

Continue reading ‘О расчете дискового пространства: NetApp FAS и EMC NS – что стоит за FUD (часть 1)’ »