about NetApp

Досадная недоработка в конфигураторе NetApp, не позволяющая купить FAS3210 без сконфигурированного MPHA, для которого требовалась дополнительная карта портов SAS, занимающая один из двух слотов расширения контроллера, и, например, мешавшая получить в 3210 и 10GB Ethernet и Flash Cache разом, в одной системе –  устранена.

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

Теперь нет нужды в хитрых маневрах, чтобы купить FAS3210 с 10G Ethernet и Flash Cache (по факту, весьма популярный вариант), конфигуратор исправлен, и теперь такую конфигурацию можно без проблем сконфигурировать и заказать.

Раз уж я пошел, давеча, по аналитическим отчетам, то вот вам еще один.

Крупная и известная аналитическая компания Forrester опубликовала недавно отчет под названием Storage Choices For Virtual Server Environments, Q1 2011 (updated: May 2011).

Forrester опросил респондентов из 104 компаний, использующих системы серверной виртуализации x86.

91% респондентов ответили, что они используют продукты серверной виртуализации в продакшне (78% - в прошлом году). Хотя веб-приложения и задачи по-прежнему лидируют среди самых популярных для виртуализации задач, продолжают расти и другие области. Доля MS SQL Server в виртуальных машинах выросла до 68% с 53%, продукты e-mail (читай Exchange) – до 51% с 29%. Растет даже такой, традиционно консервативный, сегмент как базы данных Oracle (33%/28%) и Oracle Applications (32%/15%).

У 93% респондентов используется VMware ESX/vSphere, а за второе место развертывается серьезная борьба между Citrix Xen Server (17%) и Microsoft Hyper-V (16%).

Любопытно, что на вопрос: “Укажите наиболее важные проблемы, заботящие вас в связи с использованием хранилищ виртуальных инфраструктур” 19% (максимальное число) поставило на первое место “Эффективность управления емкостью хранилища”, что обогнало даже “Обеспечение высокой производительности” (17%).

Любопытно, что в аналогичном отчете двухлетней давности (September 2008), эта задача стояла в глазах пользователей аж на третьем месте. Сравнение отчетов показывает самое интересное – динамику изменений требований и забот пользователей.

Что же там по вендорам систем хранения, резонно спросите вы?

EMC пока сохраняет лидерство (44%, снизилась с 48% два года назад), но NetApp неотвратимо нагоняет. С 24%, два года назад, его доля в этом сегменте выросла до 38%. При этом на рынке наблюдается “монополизация” в парке кастомера, 67% опрошенных пользователей предпочитают ограничиваться единственным вендором систем хранения в своей компании.

Также пока сохраняется лидерство FC как протокола подключения (76%, снизилась с 82% два года назад), однако второе место уже твердо захватил NFS (36%/18% два года назад) и доля его продолжает повышаться, на этот рост, несомненно, повлияло быстрое распространение в отрасли 10Gb Ethernet и его дальнейшие перспективы. Доля iSCSI остается неизменной (23%) и соответствует третьему месту.

Вот такие вот дела. Рекомендую почитать, есть над чем помозговать.

Любопытный отчет на днях опубликовала независимая аналитическая компания ESG, которая провела интересный эксперимент, подключив и протестировав EMC Clariion CX4-480 (110 дисков 146GB 15K, RAID5 4+1, FLARE30) через контроллер виртуализации NetApp V3270.

NetApp V-series, напомню для недавно подключившихся и приходящих через поисковики, это контроллер системы хранения NetApp, который использует для организации хранилища не собственные физические диски в дисковых полках, а “виртуальные” диски, LUN-ы, созданные для него на одном из поддерживаемых SAN-стораджей стороннего производителя. В популярном изложении можно почитать в статье “V” for V-series на Хабрахабре, где, с недавних пор, есть интересный блог о технологиях NetApp.

??спользование контроллеров виртуализации NetApp V-series позволяет получить большинство возможностей систем хранения NetApp, в их числе мультипротокольность, дедупликация, клоны, thin provisioning, даже на не имеющих таких возможностей “традиционных” SAN-массивах сторонних производителей.

Однако немедленно напрашивается вопрос: чем же мы заплатим за эту функциональность? Как обстоят дела с производительностью получившегося решения? Ведь обязательно виртуализация добавляет какой-то оверхед, каково влияние контроллеров V-series и виртуализации на производительность?

Результат получился довольно неожиданный. Подключение CX4 через V3270 показало увеличение производительности для получившейся системы, от 3 до 10 раз, по сравнению с обычным подключением того же CX4-480, напрямую в SAN по FC 4Gb/s.

Ранее, в опубликованном год назад документе TR-3856, аналогичные результаты получила и сама NetApp на задачах серверной виртуализации.

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

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

Я тут уже несколько раз останавливался на новых продуктах EMC, их достоинствах, недостатках, и скрытых, возможно, для кого-то, “подводных камнях”, но не планировал снова возвращаться к теме, по крайней мере, пока не появятся какие-нибудь новости. Однако столкнулся с рядом не очень приятных фактов в жизни моих коллег-кастомеров, и вынужден несколько подробнее остановиться на одной из моделей линейки VNX – VNX5100, самой “младшей” в серии VNX.

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

EMC VNX5100 это самая “младшая” в “старшей” линейке VNX (напомню, что VNXe, несмотря на схожесть аббревиатуры, это совсем иная система), а если учесть и весьма низкую цену, по которой она предлагается, неудивительно, что ее активно продвигают на российском рынке. Разумеется с VNX5100 частенько приходится сталкиваться и предложениям NetApp. Однако, сравнивая, стоит помнить, что VNX5100 – это “не совсем VNX”, и вот почему.

Все мы видели эффектный маркетинговый launch EMC, все мы помним что именно на нем было “выкачено” в качестве основных, ключевых возможностей систем новой линейки VNX. Это:

• Мультипротокольность (EMC называет это Unified Storage)
• Порты 10Gb Ethernet и iSCSI “в базе”
• Файловые протоколы (NAS), доступные “из коробки”, на той же системе, без допзатрат
• Дедупликация
• FAST VP (tiering) и FASTcache

Это то, что, в первую очередь, ассоциируется у пользователя с понятием “VNX”, о чем говорится во всех маркетинговых материалах, и что клиент логично надеется получить, покупая систему с названием VNX.

Проблема в том, что в VNX 5100 ничего этого нет.

EMC VNX 5100 это “чисто FC” сторадж, этакий “Clariion CX4 с дисками SAS”, поэтому:

• Только FC (нет ‘unified’ даже в понимании EMC), следовательно:
• Нет файловых протоколов NFS, CIFS.
• Нет дедупликации (даже в ее ограниченном "файловом" понимании EMC)
• Нет iSCSI и FCoE
• Нет FAST VP (tiering)
• Поддерживает использование в FASTcache только одного SSD емкостью 100GB (93,1GB эффективной, форматированной емкости. Плюс необходимые mirror и spare).
• Апгрейд на другой, настоящий VNX (5300/5500/5700) возможен только полной заменой системы (нет data in place upgrade). Это вообще отдельная система, отличающаяся по организации данных от всех остальных VNX/VNXe.

Является конкурентом NetApp в сегменте FAS2040 или FAS3210, но:

• Максимальное количество дисков невелико - 75 (против 136 у 2040 или 240 у 3210), то есть всего около 30 дисков данных, при использовании RAID-10, при нехватке дисков - см выше про невозможность апгрейда на 5300/5500/5700.
• Только 4 FC-порта для хостов/фабрик и 2 порта SAS для полок (на контроллер, на пару - 8/4 ) без возможности расширения.
• Очень ограниченное предложение по софтовой части решения (за счет отсутствия NAS-компоненты и связанных с ним софтовых продуктов EMC).

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

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

“NetApp?” – говорит сэйл компании партнера EMC – “Мы вам предложим кое-что получше! Новый сторадж от лидера отрасли – VNX 5100! Вот, возьмите брошюру (в которой рассказывается про 5300 и 5700, а пункты про 5100 сопровождены маленькой серой звездочкой-ссылкой на мелкий шрифт в конце: “not available for 5100”), а главное: она в полтора раза дешевле этого NetApp! Что раздумывать, берите!”

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

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

Такой вот вам Caveat Emptor*

PS. Я, как и ранее, должен отметить, что я не являюсь специалистом в системах EMC, и если в перечисленных выше фактах о 5100 в моих источниках ненамеренно вкралась ошибка, то, если вы куда больший специалист, и у вас есть данные о том, что я по ошибке написал что-то неверное про EMC, обязательно сообщите мне это, я обязательно поправлю это место в тексте.

PPS. Благодаря Сергею из комментариев было поправлено несколько не вполне ясно написанных мест и неточностей.

* Caveat Emptor (лат.) – “Покупатель – остерегись!”, приписка традиционно делаемая при изложении чувствительной для покупателя информации, особенно в области технических характеристик или условий покупки.

Сегодня в переводах – статья одного из моих любимых блогоавторов – уже знакомого вам Димитриса Крековкиаса, работающего в NetApp, и ведущего автономный блог recovermonkey.org. Обратите внимание, что, несмотря на то, что автор и является сотрудником NetApp, текст поста в равной мере относится и к системам NetApp, и его стоит внимательно прочесть также и партнерам NetApp, продающих их (и проводящих сайзинг) своим клиентам.

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

Покупатель, будь внимателен: верно ли вендор вашей системы хранения делает сайзинг по производительности, или они полагаются только на свои супер-технологии, типа Megacaching и Autotiering?

Posted on June 29, 2011 by Dimitris

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

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

Раньше, в "старые добрые времена", с традиционными системами хранения, вы могли получить (и получали, обычно) хорошо детерминированную, и легко предсказуемую производительность, зная только характер вашей рабочей нагрузки, тип используемого RAID и количество дисков. Вы могли быть уверенными в том, что эта система будет соответствовать вашей нагрузке, если контроллер и шина его не будут перегружены.

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

Новые "умные технологии" делают сайзинг системы хранения более сложным, чем раньше.

Например, набирающая популярность концепция Megacaches может использоваться для значительного уменьшения объемов ввода-вывода, который добирается до бэкэнда и дисков системы хранения. Например на системах NetApp FAS вы можете использовать до 16TB интеллектуального, сверх-гранулярного (4K) и использующего дедупликацию данных кэша чтения. Это на самом деле гигантский размер, больший, чем обычно может понадобиться подавляющему большинству использующих системы хранения (и даже больший, чем многие системы хранения в целом). Другие вендоры также последовали за NetApp, и предлагают сегодня похожие технологии. ??мея такой объемный кэш, расположенный перед дисками, и перехватывающий на себя значительную часть ввода-вывода, многие вендоры имеют соблазн рекомендовать использовать в таких системах хранения диски SATA, имеющие большую удельную емкость, но, обычно, невысокую производительность, ведь производительность в данном случае планируется обеспечивать с помощью того или иного "мегакэша".

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

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

Для пользователя, у которого, допустим, база данных размером 20TB, реальный рабочий набор данных этой базы может составлять всего 5% — то есть этот набор вполне может целиком поместиться в 1TB кэша. Таким образом, кэш размером 1TB может обеспечить большинство потребностей в вводе-выводе базы данных. Диски же в бэкэнде вполне могут при этом быть недорогими SATA, просто чтобы удовлетворить необходимости разместить объем хранения всей базы данных.

Но как быть с тем периодом времени, когда характер ввода-вывода отличается от типового и ожидаемого? Например, это может быть период переиндексации, или объемного экспорта базы, или период конца месяца, или квартала, когда нагрузка на базу часто резко возрастает? Такие операции сильно изменяют объем рабочего набора данных, он может быстро вырасти от 5% до куда более значительных величин. При этом наша рассмотренная выше ситуация, с 1TB кэша и SATA в бэкэнде уже может перестать нас удовлетворять.

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

Давайте снова возьмем базу данных для примера (просто потому, что для базы данных характер ввода-вывода может резко меняться). Вы легко можете получить вот такие варианты ввода-вывода:

1. Типичное использование – 20 000 IOPS, 100% random, 8K I/O-блок, 80% чтения
2. Экспорт DB — высокие значения MB/s, в основном sequential write, большой размер I/O-блока, относительно немного IOPS
3. Последовательное чтение после произвольной записи — например данные добавляются в DB в произвольном порядке, затем делается большое последовательное чтение, или даже несколько чтений параллельно

Как вы видите, профиль ввода-вывода не просто меняется, он становится принципиально другой. Если вы берете в расчет только вариант 1, у вас может не оказаться достаточно дисков в бэкэнде для стабильного потока при экспорте DB или параллельного sequential table scans. Если вы считаете только вариант 2, вы сочтете, что вам не нужно много кэша, так как ваш профиль ввода-вывода в основном последовательные (sequential) операции (а в большинстве случаев такие операции не кэшируются). Но ваша оценка будет полностью неверна для операций типичного использования.

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

Другая новая модная технология (и судя по всему - переоцененная) это Autotiering.

Autotiering, если по-простому, позволяет перемещать на системе хранения фрагменты данных, так называемые "чанки" (chunks), в соответствии с активностью доступа к ним. Чанки, содержащие максимально активные данные постепенно перемещаются на SSD, в то время, как остальные, менее активные, могут спокойно оставаться на SATA.

Различные дисковые массивы используют разные методы выполнения Autotiering, обычно реализованных с помощью нижележащих архитектурных возможностей систем хранения, и имеют различные ограничения и характеристики. Например, EMC Symmetrix имеет размер чанка около 7.5MB. На HDS VSP, чанк имеет размер около 40MB. На IBM DS8000, SVC или EMC Clariion/VNX, он равен 1GB.

При использовании Autotiering, как и в случае использования кэширования, чем меньше размер чанка, тем эффективнее получается конечный результат. Например, чанк размером 7.5MB требует всего 3-5% пространства сверхбыстрых дисков как "верхнего tier", однако в случае чанков размером 1GB потребуется уже 10-15%, просто по причине того, что чанк большего размера содержит в себе не только "горячие" данные, но и "холодные", перемешанные, на протяжении этого гигабайта, с активными, "горячими" данными.

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

Поэтому с большими чанками ситуация выглядит примерно так (красные квадратики - самые горячие блоки данных, оранжевые и зеленые - более "холодные"):

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

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

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

1. Предоставьте вендору подробную статистику производительности — чем подробнее она будет, тем лучше. Если мы не будем знать, что происходит на хранилище, то трудно создать по настоящему хорошо спроектированную для вашей задачи систему хранения.
2. Предоставьте ваши ожидания в области производительности — например "Мне бы хотелось, чтобы запросы в Oracle завершались за 1/4 нынешнего времен их выполнения" — и увяжите ваши ожидания по производительности с бизнес-целями (будет проще их оценивать).
3. Попросите вендора показать его инструмент сайзинга и описать , каким именно образом делается математическая оценка и получается результат — тут нет и не может быть никакой магии!
4. Спросите вендора, проанализровали ли они все возможные сценарии нагрузок, которые у вас имеются (не просто "для разных приложений" но разные нагрузки для каждого вашего приложения) — и как именно они это сделали.
5. Попросите его показать вам каков по размеру, по его оценке, ваш "рабочий набор" данных, и какой объем его поместится в кэш.
6. Попросите его объяснить вам, как ваши данные будут располагаться на Autotiered-системе. Каким образом определяется то, на каком tier-е будут располагаться те или иные фрагменты данных. Как это вычисляется? Какие моменты геометрии хранилища следует принять во внимание?
7. Есть ли достаточно пространства для каждого уровня хранения (tier)? Для архитектуры Autotiering с большими чанками, есть ли у вас объем, равный 10-15% емкости общего стораджа, на SSD?
8. Учтена ли дополнительная нагрузка на RAM и CPU контроллера во время работы кэширования и autotiering? Такие технологии обязательно нагружают CPU и RAM при работе. Спросите, каков этот оверхед (чем меньше чанк при Autotiering, тем больше оверхед на обработку метаданных, например). Ничто не дается на халяву.
9. Остерегайтесь сайзинга, сделанного устно или "на салфетке", на калькуляторе, или даже в простой электронной таблице – Я еще ни разу не видел точную модель расчета производительности системы хранения в виде электронной таблицы.
10. Остерегайтесь сайзинга, рассчитанного исходя из примитивного "диск 15K дает 180 IOPS"— на практике все куда сложнее!
11. Разберитесь с разницей между последовательным (sequential) и произвольным (random) доступом к данным, режимом чтения (reads), записи (writes), а также размером оперируемого блока ввода-вывода (I/O size) для каждой оцениваемой архитектуры — в зависимости от платформы различие в способах работы ввода-вывода может сделать сравнение очень трудным для корректного сравнения между собой при различных требованиях к дисковой подсистеме.
12. Разберитесь с тем, какую дополнительную нагрузку по вводу-выводу и емкости хранения создают решения Continuous Data Protection и репликации в ряде случаев это может утроить ее.
13. Какой тип RAID предполагает использовать вендор? Учтено ли огромное дополнительное влияние на производительность у RAID-5 и RAID-6, при большой нагрузке на запись (плюс известный аспект надежности).
14. Если вы получили предложение за необычно низкую цену, поинтересуйтесь стоимостью дальнейшего апгрейда системы. Принцип "Первый раз - бесплатно" используется очень многими отраслями бизнеса.
15. ??, наконец, совсем немаловажное — спросите, исходя из какой нагрузки на контроллер системы хранения исходил вендор при сайзинге! Я с большим удивлением видел попытки продать систему, которая обеспечивала обслуживание рабочей нагрузки клиента с запланированным уровнем загрузки CPU контроллера на уровне 90%. Вы считаете, что такого запаса по производительности вам хватит? Помните – дисковая система хранения это просто компьютер с большим количеством дисков, и со специализированным аппаратным и программным содержимым, и здесь процессор может "затыкаться" точно также, как и в любой другой вычислительной системе.

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

??нтересный отчет опубликовала сегодня тестовая лаборатория NetApp, анализировавшая производительность Oracle 11g на RHEL и системе хранения NetApp.

Для затравки вам картинка:

Полностью читать – там:
Red Hat Enterprise Linux Protocol Performance Comparison with Oracle Database 11g Release 2
http://www.netapp.com/us/library/technical-reports/tr-3932.html

Глазастый блоггер Stephen Foskett (блог PackRat) углядел на фотографиях с презентации Apple о ее новом датацентре в Северной Каролине, который будет использоваться под iCloud, стораджи NetApp в стойках.

Не секрет, что круг клиентов NetApp куда шире, чем те Success Stories, о которых упомянуто на официальном сайте (в России с опубликованными Success Stories внедрений и совсем “бедно”, несмотря на то, что системы NetApp продаются в России и Казахстане очень успешно). Любопытно, порой, бывает встретить такие имена среди пользователей NetApp.

Собственно сами фотографии:

2,3 – различные сервера HP (вероятнее всего DL360G7 и DL380G7), опознанные по характерному виду и фиолетовым элементам на треях дисков :)

4,5 – ясно видная передняя панель корпуса 6U контроллера FAS6200, сверху и снизу (а также рядом, в соседней стойке, ближе к фотографирующему) окруженная несколькими дисковыми полками DS2246.

Кроме указанного, на фотографиях также замечены характерные рэки стоек Teradata Extreme Data Appliance.

Напомню, что месяц назад я объявил своеобразный “конкурс”, или вернее будет сказать “розыгрыш приза”, предложив присылать мне результаты экономии пространства с помощью дедупликации и компрессии на томах ваших систем, вывод консольной команды df -s –g.

Я пообещал разыграть, в случайном порядке, между всеми приславшими, по выбору выигравшего, gift card Apple iTunes на 25$, такую же карточку от Amazon, или же подарочную карту от OZON на 1000 рублей.

То есть от вас – вывод команды, и, возможно, карточка достанется вам. Карточка, разумеется, не физическая, а ее номер, который вы можете активировать в соответствующем интернет-магазине.

Подробнее – в том посте.

Конкурс “экономия пространства на NetApp”

Напоминаю, что результаты принимаются до 1 июня. Вы еще вполне успеете сделать свою попытку в понедельник или вторник.

Я уже писал (тут, тут и тут) в этом блоге о чрезвычайно полезном, свободно распространяемом тулките для PowerShell, разрабатываемом в NetApp. Этот тулкит представляет собой целый набор разнообразных “командлетов” (commandlets), для администрирования систем хранения NetApp.

На сайте communities.netapp.com (если вы работает с NetApp, но еще не там, то самое время вливаться, доступ и создание логина там свободные) можно найти хорошую презентацию о том, как установить и пользоваться тулкитом:

Getting Started With Data ONTAP PowerShell Toolkit

А недавно был выложен обновленный документ:

Making The Most Of Data ONTAP PowerShell Toolkit

Если вы умете использовать PowerShell, и планируете использовать его возможности для управления системой хранения 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-а.