Archive for июля 2013

Курс “VMware на NetApp” в учебном центре FastLane

К сожалению, пока редко читающийся, но безусловно интересный для использующих оба этих продукта курс в официальном учебном центре NetApp – FastLane:

VMware vSphere on NetApp (VVNA)

Далее просто из описания на сайте:

В курсе рассматривается планирование, развертывание, конфигурация и администрирование виртуальной инфраструктуры VMware (ESXi 5 под управлением vCenter Server 5), подключенной к системам хранения NetApp. Сравнение плюсов и минусов использования и конфигурации VMFS и NFS datastore. Лабораторные работы помогут получить практический опыт использования NetApp plug-in Virtual Storage Console для vCenter 4/5 с целью: 1) Мониторинга и настройки гипервизоров ESXi 2) Выполнения задач резервного копирования и восстановления 3) Управления и клонирования виртуальных машин. Работа протокола репликации SnapMirror и механизмов VMware HA/DRS для повышения отказоустойчивости, а также SnapVault, OSSV и SnapProtect для резервного копирования и восстановления данных виртуальной инфраструктуры подробно освещены и продемонстрированы. Курс дает понимание сценариев использования и практический опыт применения NetApp/VMware best practice, повышения производительности, поиска и устранения неисправностей при взаимодействии инфраструктуры VMware (ESXi 5 под управлением vCenter Server 5) с сиcтемами хранения NetApp под управлением операционной системы Data ONTAP 8.1 7-mode, включая работу с Virtual Storage Console для vCenter.

Ближайший – на следующей неделе (05-09.08), возможно еще успеете зарегистрироваться, он “гарантированный”, то есть они уже набрали необходимый минимум для проведения курса, также запланировано два последующих: 26-30.08, и 28.10-01.11, все в Москве.

Стоимость – 135 тысяч рублей, или 60 NTU; пять дней.

Подробное описание курса: http://www.flane.ru/course-pdf/fl-vvna

Про “культ бенчмарков”

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

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

Бенчмарк SPC-1 это очень сложный тест. Это не fancy-приложение, которое запускается, что-то делает 10 минут, рисуя переливающиеся графики, а потом пишет: “О-о! Круто! 100500 супермарков!”, или, наоборот, “Фу-у! Отстооой! Всего 150 попугаев!”. Строго говоря, даже приводимые данные по достигнутым IOPS значат не слишком много сами по себе. Проведенные тесты по SPC-1 требуют внимательного чтения всего отчета. Хотя бы сокращенного Executive Report, но настоящие инженеры просто обязаны прочесть еще более интересный Full Disclosure, с полным описанием проведенного тестирования. И уж абсолютно точно совершенно недостаточно извлечь из всего отчета одну строчку с циферками IOPS (или $/IOPS), и ей оперировать где-либо, в отрыве от того, как она получена. Строго говоря, в таком сложном бенчмарке, как SPC-1 интересен даже не столько результат как таковой, сколько процесс его достижения, описанный как раз в Full Disclosure, и многочисленные сопутствующие результаты, latency, например, как самый очевидный. Но это совсем не одна строчка 3DMark, исходя из которой можно сделать вывод “фу-у, отстоой!”, или “вау, круто!”.

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

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

Бенчмарки, особенно такие “крутые”, как SPC-1, это гонки Формулы-1. Это красиво, зрелищно, захватывающе, но разумные люди понимают, что “Формула” – отдельно, а повседневная жизнь автовладельца и автомобилиста – отдельно. Из того факта, что в очередной гонке болид Renault обошел болид Ferrari совершенно не следует, что в реальной жизни ваш Renault обгонит соседский Ferrari. :) Но почему-то в случае бенчмарков систем хранения это сплошь и рядом считается не так, и результаты восьмиконтроллерного кластера с 1920 дисками за 6 миллионов долларов, или Full Flash системы с тремястами SSD, в восприятии читателя (не без “дружеской” помощи вендора) проецируются на его, добрый милый сторадж entry-level с двумя полками по 15 дисков.

Да, безусловно, наличие результатов и участие в программе тестирования Storage Performance Counsil (SPC) это – хорошо. Это означает, что вендор готов “показывать свой товар лицом”, готов отвечать на “вопросы”, ему не стыдно за то, что он разработал и продает. За это не стыдно не всем, но очень многим, начиная от NetApp, HP, IBM, кончая даже Oracle и Huawei. Даже если результаты будут неидеальными и нерекордными в абсолютном исчислении, это уже само по себе подтверждает открытость вендора и отсутствие “засад” в его решениях. В тестах, куда как более, чем в Олимпиаде “важна не победа, а участие”. Однако неправильно будет пытаться любой ценой установить рекорд. И еще неправильнее будет строить рекламу “купите наш Рено Логан, наш автомобиль обогнал вчера Ferrari на GP!” в особенности понимая, где здесь манипуляция (а технари такого уровня, участвующие в написании подобных текстов не могут не видеть, где тут манипуляция).

Ну а теперь, позвольте перейти к FUD-у. На следующей неделе я опубликую подробный откомментированный разбор очередного текста “чем плох NetApp” по мнению одного из наших конкурентов. не переключайте ваши веб-браузеры. :)

Опубликованы результаты теста OLTP Oracle RAC 11g на Flash Pool

Наконец-то опубликованы долгожданные результаты тестирования Flash Pool (гибридный aggregate с SSD в полке), показывающие эффект от его использования на задачах OLTP баз данных. Полностью отчет с описанием можно прочитать в соответствующем Technical Report, а для затравки просто картинка (а в отчете есть еще):

image

В работе также приводится подробное описание тестируемой конфигурации и настроек Oracle.

OnCommand System Manager 3.0 RC1

Вышла и опубликована новая версия System Manager, но радоваться погодите. Существенных изменений с 2.2 не так много, более того, она 3.0 только для Clustered ONTAP. При работе с 7-mode запускается 2.2 (она называется 2.2.0.1), которая в 3.0 включена как подсистема. Так что если у вас не Clustered Data ONTAP, то погодите бежать-качать-ставить, особой разницы вы не увидите, разве что багфиксы.

Новые возможности 3.0: поддержка SnapVault на clustered-системах, поддержка и управление локальными пользователями SMB внутри VServer, поддержка Hyper-V по SMB 3.0 для C-mode систем, некоторые визуальные улучшения и упрощения в интерфейсе.

А вот интересно, среди читающих меня есть хоть один, в реальной жизни эксплуатирующий уже Clustered Data ONTAP? Насколько интересно публике читать новости про фичи Cluster-mode?

“Возвращаясь к напечатанному”

Когда, весной 2007 года, я начинал вести этот блог, я совершенно не представлял, что его жизнь протянется так надолго и так далеко. Тогда я просто экспериментировал с Wordpress, и, работая пресейлом в компании-партнере NetApp, захотел изложить то, что на тот момент знал о технических “фичах” этих систем хранения “человеческим языком”, для тех, кому это может быть тоже интересно. Но совершенно не предполагал, что все это растянется на 6 с лихом лет!

К сожалению, такая недальновидность предопределила ряд недостатков этого блога. Например, в нем практически отсутствуют средства “навигации” по старым постам, многие его читатели никогда не залезают “вглубь”, и даже не представляют, сколько там за шесть лет накопилось полезного. Как я вижу по статистике, основная масса моих читателей, свыше 90%, никогда не читают более двух-трех страниц блога за посещение. В “глубины” обычно попадают только те, кто пришел через поисковики, и которые ищут что-то конкретное, например мою популярную статью про IOmeter, или сравнительно недавний перевод Recoverymonkey про то, что такое IOPS. Или уж совсем древнюю, и в значительной мере утратившую актуальность заметку про то, что такое “кластер” (вот уже много лет из топа запросов этого блога не выходит поисковая строка “кластер это” ;), или “чем отличается NAS от SAN”.

Конечно здесь есть некое подобие рубрик, и даже теги, упорно мною расставляемые, но все равно, очень, очень мало людей читает что-то кроме “витирины” первой страницы. В этом я убедился, когда на прошлой неделе мне довелось поговорить с некоторыми моими читателями “пока-не-покупателями” на темы анти-нетапповского FUD-а наших коллег-конкурентов. И я даже загорелся написать статьи-ответы по каждой из таких тем, и даже начал писать, но вдруг понял, что все вот это, просто другими словами, я уже излагал тут раза четыре-пять. Темы FUD-а не меняются уже много лет, ничего нового к ним не добавляется уже давно (это плюс NetApp-у в каком-то смысле ;) раз ничего нового “плохого” даже злейшие конкуренты не находят). Все те же, все там же. Конечно же рассказывают про оверхед блочного доступа на WAFL, про низкий выход usable с данного объема raw, про “снижение производительности” при высокой заполненности тома, Как всегда педалируют “фрагментацию” и “отсутствие балансировки” и доступа к дискам одновременно с обоих контроллеров.

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

Про WAFL и гипотетическом оверхеде для блочного доступа стоит начать с того, что разобраться, что же такое WAFL. Поэтому, прежде всего, стоит начать с отлично написанной работы на тему, которая лежала в основе NetApp как компании, и опубликованной на самой заре ее истории “отцами основателями” ее, двумя инженерами Дейвом Хитцем и Джеймсом Лау: она в переводе опубликована на сайте компании Netwell, которая спонсировала огромную работу по переводам Best Practices. Работа эта, опубликованная впервые на научной конференции USENIX, называется Разработка файловой системы для специализированного файлсервера NFS. Напомню, тогда, в самом начале, NetApp занимался только серверами NFS, но впоследствии, десять лет спустя, в 2003 году, он достаточно легко добавил блочный доступ к данным поверх структур WAFL. То, как это было сделано, и почему WAFL, вопреки ее названию “не файловая система”, или, вернее, нечто, отличающееся от того, что обычно принято называть в IT “файловой системой”, можно прочитать в статье нетапповского инженера Костадиса Руссоса “Почему я считаю, что WAFL – это не файловая система”. Там, в частности, объясняется то, почему блочный доступ на WAFL не является “эмуляцией поверх файлов” (тоже популярная страшилка конкурентов), и почему оверхед в WAFL сравнительно невелик как для файлового, так и для блочного доступа.

О низком результате usable на данном объеме raw-дисков стоит начать чтение со статьи “О цене за гигабайт” и “цене за решение”, где я попытался объяснить, из чего складывается и как формируется итоговая емкость системы хранения NetApp. Полезным также будет прочитать о RAID-DP, и почему именно этот тип RAID используется в NetApp, и о том, как организована иерархия “объектов хранения”, что такое и как соотносятся между собой aggregate, физические диски, тома, LUN-ы, и так далее. Детальный расчет емкости покажет нам, что реальный usable space зачастую первышает таковой у систем, инженеры которых любят указывать на низкий уровень usable у систем NetApp. Наконец, фактические результаты 7 с лишним тысяч работающих у клиентов систем хранения, сообщающие свои данные через Autosupport, показывают весьма высокие результаты – 66,27% составляет фактическая величина usable от имеющегося объема raw-дисков. Это не теоретическая, рассчитанная величина, это фактическое среднее значение usable space реально работающих у клиентов стораджей. Хорошо резюмирующим тему usable space является текст инженера NetApp Dimitris K. “Что стоит за FUD о usable space?”

Про “снижение производительности при заполнении дисков данными” отвечает Richard J. Martin, сотрудник австралийского отделения NetApp в статье Как заполненность данными системы хранения влияет на ее производительность?. Кроме того, можно посмотреть и на официально опубликованный в 2007 году ответ NetApp, когда это утверждение впервые появилось в competitive-материалах компании EMC. Также очень показательным будет и тот факт, что тестирование по методике SPC-1 NetApp проводит с уровнем заполнения дисков данными в 84% от usable (и 60% от raw), а некоторые другие вендоры, показывющие свои результаты в этом бенчмарке – с уровнем 57% от usable и 29% от raw. Если они не боятся “снижения производительности при заполнении данными”, то отчего не покажут результат при 100% заполнения usable?

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

Про то, почему Flash Cache не используется на записьв статье про устройство Flash Cache и того, как он взаимодействует с WAFL.

О том, почему у NetApp нет tiering-а, а также о том, почему flash-кэширование лучше, чем tiering – в статье про VST – Virtual Storage Tiering, использующий Flash Cache.

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

Соответствие команд 7-mode и C-mode

Если вам в скором времени предстоит переход на Clustered Data ONTAP, или если вы админ системы хранения, хорошо знакомый с Data ONTAP 7-mode, которому предстоит администрировать Cluster-mode, то рекомендую посмотреть документ, недавно опубликованный в библиотеке NetApp:

Clustered Data ONTAP® 8.2
Command Map for 7-Mode Administrators

В нем в таблицу собраны команды Cluster-mode, соответствующие, по выполняемым действиям, командам 7-mode. То есть если вы знаете как, допустим, создать том на aggregate в 7-mode, и не знаете какой командой это делается в Clustered ONTAP, то вот этот документ вам поможет.

Брать можно здесь: https://library.netapp.com/ecm/ecm_download_file/ECMP1196780

18/0.150

Данный блог не спонсируется, не аффилирован, и не санкционирован компанией 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.