Archive for апреля 2011

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

Все блоги вокруг меня проводят среди своих читателей те или иные конкурсы. Отличную идею подсмотрел я в communities.netapp.com, воспользуюсь ей в своих целях.

Не так давно, споря в комментариях по поводу эффективности работы дедупликации, я предложил показывать всем желающим их результаты space savings с помощью вывода команды консоли df –s.

Мой оппонент утверждал, что величина достигаемой дедупликации “в реальных системах, а не по словам маркетологов” совсем незначительна, и значимость дедупликации данных сильно преувеличена нетаппом.
Я же возражал, что это не так, и это легко проверить, сделав вывод команды df –s и посмотрев величину в графе % savings.

Так вот, “удваиваю это предложение”!

Я принимаю от вас ваши результаты df –s, а затем, чтобы простимулировать вас в этом начинании, разыграю между всеми приславшими, случайным образом, код подарочного сертификата.

На выбор предлагается:

  • Подарочный сертификат магазина OZON.ru (1000 рублей)
  • Gift card Apple iTunes (25$)
  • Amazon gift card (25$)

Выигравший получит на свой email любой один, по вашему выбору (ну то есть если кто-то не любит Apple, и iTunes Gift Card ему не нужна, значит можно выбрать другой вариант).

Дальше вы полученный код можете использовать как захотите, например для приобретения программ в Appstore, или книжек/музыки на Amazon или OZON.ru. На ОЗОНе рекомендую, кстати, книгу коллеги-блоггера, и автора vm4.ruАдминистрирование VMware vSphere 4.1.

Ограничим эту затею ровно месяцем с момента публикации этого предложения.
Ваши ставки принимаются по e-mail: romx@mail.ru или в комментариях к этому посту.

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

Вывод этой команды выглядит примерно так:

> df -s -g
Filesystem used saved %saved
/vol/vol1/ 1279GB 668GB 34%
/vol/vol2/ 1462GB 239GB 14%
/vol/vol3/ 1133GB 270GB 19%

Будет совсем хорошо, если вы вместе с результатами хотя бы в нескольких словах охарактеризуете свои данные. Например: “/vol/vol1/virt – nfs-хранилище виртуальных машин VMware, /vol/files/ – файлы домашних папок пользователей, /vol/db-luns/db1…db8 – тома для LUN-ов базы данных MS SQL2005 по FCP”

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

PS. Один участник у меня, кстати, уже есть в комментариях к тому посту.

EMC убедительно демонстрирует проблемы VNX

В моем блоге очередной перевод поста в блоге Recoverymonkey (Dimitris Kr.)

Я бы хотел обратить внимание читателей, что то, что публикуется по средам, это переводы. Я стараюсь сохранять манеру и стиль оригинального автора, потому что это – перевод. Лично я могу быть несогласен (или согласен, как получится) с излагаемой позицией, но, так как это не мои собственные тексты, за исключением небольших сокращений, я стараюсь их не править, и переводить в том виде, в котором они были опубликованы их авторами. Если у вас есть возражения по существу написанного, то не нужно писать их в комментариях к этому посту, и вообще к “средовым” переводным постам мне, сюда. Если вы хотите подискутировать с автором – напишите непосредственно ему, я всегда оставляю ссылки на оригинальные публикации. Спасибо за понимание. А теперь – как всегда острая и полемическая статья Recoverymonkey, с очередной шпилькой в адрес EMC VNX.

EMC conclusively proves that VNX bottlenecks NAS performance

Posted on February 24, 2011 by Dimitris

Немного провокативный заголовок, не правда ли?

Позвольте мне объяснить.

EMC опубликовала новые результаты SPEC SFS в рамках своей маркетинговой кампании (которая работает, смотрите чем я занят – я говорю о них).

Если по-простому, то EMC получила почти 500 тысяч SPEC SFS NFS IOPS (уточню последнее, чтобы не спутать с “блочными” IOPS в SPC-1) на следующей конфигурации:

  • Четыре (4) полностью независимых массивах VNX, каждый на дисках SSD (всего 8 контроллеров, так как каждый массив имеет 2 контроллера).
  • Пять (5) Celerra VG8 NAS heads/gateways (1 как spare), по одному поверх каждого VNX
  • Две (2) Control Station
  • Восемь (8) экспортов  файловых систем (по две на каждую голову VG8/VNX)
  • Несколько пулов хранения (по крайней мере один на каждую VG8) – без совместного доступа, например с других контроллеров, без переноса данных с других контроллеров.
  • Всего 60TB пространства NAS под RAID5 (или по 15TB с каждого массива)

Этот пост не о том, что приведенная конфигурация нереальная и дорогая (никто не заплатит 6 миллионов долларов за 60TB в NAS). Как я понял, EMC старается опубликовать наилучший результат теста путем объединения в кучу нескольких отдельных массивов с SSD. Это в принципе нормально, если понимать детали.

Претензии мои тут в том, как это подается.

EMC говорит о тестируемой конфигурации очень расплывчато (за деталями приходится идти непосредственно на сайт SPEC). В рекламных материалах просто говорится, что EMC VNX показала результат 497623 SPECsfs2008_nfs.v3 операций в секунду. Это что-то типа того, как если бы вы сказали, что нормально пройти четверым первоклассникам на сеанс в кино “до 18”, потому что, дескать, “всем четырем вместе больше 18”.

Нет, более правильно и корректно было бы сказать, что четыре массива VNX, работающих отдельно и независимо друг от друга, показали результат 124405 SPECsfs2008_nfs.v3 IOPS  - каждый.

EMC просто сложила результаты четырех отдельных, независимых устройств вместе!

У NetApp уже есть результат SPEC SFS для FAS6240, где всего два контроллера выдают 190675 SPEC NFS IOPS, в одной системе, настоящем unified, без нагромождения отдельных контроллеров, без использования SSD (на обычных SAS, плюс большой кэш), то есть на реальной, практической конфигурации, которую мы продаем ежедневно, а не на каком-то там лабораторном “звездолете”.

Если сделать также, как поступил EMC, то есть сложить четыре таких системы вместе (в случае NetApp, у нас при этом можно использовать Cluster-mode, с общим файловером между этими четырьмя нодами ), то мы получим следующие результаты:

  • 762700 SPEC SFS NFS операций
  • 8 экспортируемых файловых систем
  • 334TB usable пространства в RAID-DP (в тысячи раз надежнее RAID-5)

Какой вариант, по вашему, более выгодная покупка? Та что более быстрая, 343TB с большей надежностью, или та, что медленнее, 60TB и меньше надежности? ;)

Пользователи других систем также могут легко проделывать такой же трюк с умножением их результатов измерений, вперед!

Если же говорить серьезно, то, что побудило меня так озаглавить пост, это факт того, что тестирование EMC убедительно продемонстрировало, что VNX сам по себе является узким местом. Фактически мы видим, что VNX может обслуживать только одну “голову” VG8 на максимальной для себя скорости, зачем и понадобилось четыре отдельных системы для демонстрации нужного результата. Таким образом, факт того, что VNX может иметь над собой до 8 “голов” Celerra ничего не значит, так как в такой системе back-end это и есть ограничивающий производительность фактор.

Но с одной “головой” NAS вы будете ограничены доступным объемом в 256TB, столько одна голова Celerra может адресовать на момент написания статьи. Впрочем, этого достаточно для обычного пользователя.

Любопытно, а те “головы” NAS, которые продаются вместе с VNX, медленнее, чем VG8, и насколько? Понятно, что большинство пользователей будут использовать те “головы”, что идут в комплекте, так как это обходится дешевле. Как быстро работают они? Уверен, клиенты хотели бы знать как быстро работает именно то, что они, обычно, покупают.

Также очень интересно, как быстро работает RAID6.

А вообще было бы здорово измерять бенчмарки именно того, что пользователь на самом деле покупает, а не абстрактных “болидов Formula 1”!

Смотрим внимательно на EMC VNX/VNXe. Часть 3

Продолжим наше “журналистское расследование” и пройдем детальнее по моделям и семействам. Начнем с младшей серии – VNXe, которая, вследствие именитости вендора и привлекательности цены вызвала большой интерес на отечественном массовом рынке.

На что же следует обратить внимание, останавливая свой выбор на EMC VNXe, из того, о чем, часто, самим EMC упоминается вскользь. Или, как пишет один блоггер, “всегда читайте то, что написано на странице самым мелким шрифтом”. Вооружимся лупой и приступим к чтению :)

Как я уже писал в первой части, очевидной целью VNX/VNXe на рынке являются системы NetApp, слишком очевидно, что многое в них сделано с прицелом “ответ на”. А поэтому давайте определим, с какими системами NetApp соответствующие модели EMC VNXe конкурируют, и оценим их плюсы и минусы.

VNXe – это системы “младшего” семейства. Их естественным конкурентом являются модели 2000-й серии NetApp FAS, а также, отчасти, модель 3210 из “новых”. Напомню, что серия 2000 у NetApp состоит на сегодня из трех моделей, это FAS2020 и 2050, производящиеся с 2007 года, и подходящих к концу своей активной карьеры, и более новой FAS2040. Также частично в это семейство попадает FAS3210.

Совершенно естественно, что для VNXe возможности FAS2000 надо “крыть”, что, впрочем, по идее, не должно быть сложным, перебивать системы 4-летней давности.

В серии VNXe имеются две модели – VNXe 3100 и VNXe 3300.

imageimage
VNXe 3100 превосходит по формальным параметрам FAS2020 (было бы удивительно, если бы новая система проигрывала бы по ним системе 4-летней давности;), например по максимальному количеству дисков (96 у 3100 против 60 у 2020) и больше кэш памяти (8GB против 2GB). Однако VNXe 3300 проигрывает по максимальному количеству дисков системе FAS2040 (120 против 136 дисков), но превосходит по объемам кэша (24 против 8 GB). Также в системах класса FAS2000 нет опции 10GB Ethernet, она появляется только на 3210.

Однако давайте посмотрим внимательнее на сторону общих ‘факапов’ ;)

Как я уже мельком упоминал в первой части, EMC решила в VNXe полностью отказаться от FC. FibreChannel в VNXe не предлагается даже как опция. В чем-то я даже соглашусь с таким решением, как вы знаете я последовательный сторонник Ethernet storage, но если в случае FAS2020 у нас есть выбор, продолжать использовать FC или нет, то в VNXe это решили за нас. Все, FC – вчерашний день. Его в этих системах не будет. Точка.
Как опция есть 10G Ethernet (для 3300 только). впрочем, как я понимаю, это не Unified Target, завести в него все интерфейсы и протоколы, и сделать в нем FCoE не выйдет. Также вопрос, насколько 10G Ethernet полноценно потянет внутренняя шина. В новых 3200/6200 у NetApp шина сделана PCIe 2.0, вдвое более широкая, чем обычный PCIe, не в последнюю очередь именно ради комфортного и достаточного обеспечения работы 10G Ethernet портов.

Довольно теоретическое ограничение для систем “малого класса” на количество LUN/Vol. У 3100 допустимо максимум 128 LUN и 256 Vol (512 у 3300), что сильно меньше, чем 1024 у FAS2020, хотя я  не думаю, что такая маленькая система, как 3100 сможет упереться в 128 LUN-ов в реальной жизни. Но держать в памяти стоит.

Самая серьезная проблема, с которой столкнутся будущие покупатели VNXe, это, на мой взгляд, невозможность апгрейда с data-in-place (то есть с сохранением данных “на их местах”, на дисках) на более “взрослые” системы VNX, а также, если вы уже клиент EMC, то невозможности data-in-place с ваших текущих систем, например AX4 или NX4.

Если вы переросли VNXe, и захотели перейти на VNX, то не обманывайтесь похожестью аббревиатур, различие тут не в одной маленькой буковке ‘e’.
EMC VNX и VNXe это принципиально разные по внутреннему устройству системы. Просто перенестись между ними не выйдет, как и не выйдет перейти, например, с сегодняшней вашей Clariion AX4 или CX4-120, или Celerra NX4, на VNXe.
Переход возможен только с полным переносом данных со старой на новую. Старую систему забэкапили, остановили, вынули, новую собрали и поставили, проинсталлировали и разбили, и данные на нее восстановили. Старую можно попробовать продать на eBay ;)

У FAS2000 тоже не все в порядке с апгрейдабельностью на midrange, увы, это общая плата за дешевизну, но у них вы хотя бы штатно можете взять все ваши имеющиеся полки с дисками расширения и переключить их, прямо кабелями, на контроллер новой системы, будь то хоть даже FAS6280, и все данные увидятся, поднимутся и заработают немедленно после физического переключения. И в любом случае вы сможете использовать диски и полки от старых систем на новых. Новая серия FAS3200/6200, как и более ранние, поддерживает как FC, так и SAS.

По софту. Я уже говорил в первой части о определенных проблемах софтверного плана, остановлюсь на этом более подробно.

Я уже упоминал, что дедупликация на VNX/VNXe только пофайловая, то есть работает на NAS-уровне только, и дедуплицирует только полностью идентичные файлы, в отличие от субфайловой/блочной дедупликации NetApp, которая может дедуплицировать и содержимое различных файлов, если внутри у них есть сходные фрагменты. Пример – разные файлы vmdk с разными виртуальными машинами в них, но с идентичной OS, и, следовательно, сильно совпадающих по содержимому. В целом файлы vmdk не одинаковы, но в значительной мере идентичны внутри.
Как показывает исследование (например см. публикацию с конференции FAST’11: A Study of Practical Deduplication), субфайловая дедупликация сравнительно маленькими блоками (в случае NetApp размер фиксированного блока равен 4KB) более эффективна, чем файловая.
Следует также помнить, что “файловая” дедупликация EMC не работает на самых “вкусных” с точки зрения дедупликации задачах, например на NFS-хранилище для VMware, где NetApp стабильно показывает 70-90% снижения занимаемого данными объема.

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

Репликация для VNXe имеется только асинхронная. Конечно, асинхронная репликация более востребована, особенно на небольших системах, но тут опять же “все выбрали за нас”. “Вам не нужна синхронная репликация” (и рукой так, по джедайски;). Кроме того, репликация также не имеет никаких средств оптимизации (например компрессии) трафика, передаваемого по WAN. Это возможно сделать какими-то сторонними, внешними средствами, например с помощью устройств Riverbed, но у NetApp эта “компрессия” встроена.

Нет собственных средств для offsite-backup, например чего-то аналогичного SnapVault, а хранение снэпшотов на дисках системы по прежнему больно ударяет по производительности, каковой проблемы лишен NetApp.

SnapSure несовместим с дедупликацией (single-instancing) и компрессией. Либо снэпшоты, либо дедупликация и компрессия. Если вы планируете использовать дедупликацию и компрессию, вы сильно сокращаете набор доступных вам для этих данных возможностей, таких как клоны и снэпшоты.

Компрессия – постпроцесная, то есть как дедупликация в NetApp. Сперва записали много, а потом что-то вернули когда отработают процессы. У NetApp компрессия онлайн. То есть вы “на ходу” записываете на диски меньше.

Дедупликация и компрессия работают только на файловом уровне, а размер файлового тома не может превышать 16TB. Компрессия и дедупликация не работает для LUN-ов, VMDK, файлов PST, данных Oracle over dNFS, и прочего подобного.

Когда EMC говорит о полной сертификации под VMware, то тут есть определенная доля лукавства. В настоящий момент, по моим данным, VNXe 3100 сертифицирован только как NAS, а VNXe 3300 – только как iSCSI (если на момент публикации это уже изменилось – поправьте меня). Я уже писал ранее, в части 1, как все непросто с так называемым Unified Storage (делает жест “кавычки” пальцами рук;) в понимании EMC. И следовательно как все непросто с функциональной совместимостью между NAS и iSCSI SAN в такой конструкции.

Сильно муссируется факт принадлежности VMware компании EMC, из этого как-бы естественно должен вытекать вывод, что системы EMC для VMware “более родные”, однако тут не все так просто. Несмотря на то, что 70% акций VMware действительно принадлежит EMC, VMware (VMW) это independently listed company, то есть ее акции котируются на бирже независимо от акций EMC (а вот, например, Isilon (ISLN), или Data Domain (DDUP) других недавних покупок EMC – уже нет), и она во многом самостоятельно определяет свою политику на рынке. Парадоксально, но, если мне не изменяет память, отношения технологического партнерства у VMware с NetApp чуть ли не более продолжительные, чем с собственно EMC! Они были установлены еще до “покупки” VMware!

У VNXe (сейчас) нет возможности использовать SSD, а следовательно – нет FASTcache. У NetApp для FAS2000 тоже нет FlashCache, зато он есть в FAS3210, который вполне можно, умеючи, “умять” по цене в “старшие low-enterprise”, если Flash вам понадобится. Тем не менее помните, что когда EMC говорит про FASTcache, это не относится к VNXe.

Нет FAST VP – автоматизированного storage tiering, с переносом данных с SAS на NL-SAS.

Нет официальных, подтвержденных данных о производительности новой архитектуры. Ну то есть заталкивать девушек в Mini это прикольно и честно-благородно, но все же как там насчет баб производительности, а? Извините, что я вам весь пафос момента сбиваю, нам бы вот на IOPS-ы бы посмотреть, а? ;)
Впрочем, про производительность и о “EMC’s approach” к этому вопросу это мы еще поговорим в среду и далее.

Да, несомненно системы VNXe имеют поразительно низкую для своего класса цену. Но, строго говоря, “цена ниже рыночной” должна вас сперва насторожить (а только потом – обрадовать). Если VNXe так хорош, то почему его отдают так дешево? Нет ли тут some gotchas, как выражаются наши англоязычные друзья? Ведь не секрет, что в энтерпрайзе  “потребительская ценность” есть сумма из:

Цена железа + бренд + потребительские свойства = потребительская ценность

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

Да, цена у NetApp обычно высока, но почему именно она высока, я уже писал в посте ранее. За большую цену и возможностей вам достается больше. Для многих это достаточный аргумент, для кого-то – нет. Но я бы хотел, чтобы вы помнили очень хорошую фразу в отношении цены покупки в IT: “Деньги вы экономите один раз и “дядины”, а геморрой покупаете надолго и свой”.
Пусть не застилает вам глаза низкая цена.

Откуда вообще берется фрагментация?

Так что же там на самом деле происходит с фрагментацией на NetApp?

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

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

Поэтому официальная позиция состоит в рекомендации, в случае, если влияние фрагментации в вашем конкретном случае, проявляется негативно (она, кстати, может и не проявляться), то включать wafl reallocate ( reallocate on / reallocate start [/vol/volname]) и спать счастливо.

Вообще же FUD вокруг non-contiguous wafl blocks allocation построен (впрочем, как и почти любой FUD) вокруг плохого представления технических деталей процесса и иногда чистосердечного, а чаще злонамеренного “непонимания” этих деталей. Давайте, для начала, разберем как же записываются данные в WAFL, по крайней мере на том уровне, на котором нам этот процесс показывает NetApp.

Но начать придется издалека.

Continue reading ‘Откуда вообще берется фрагментация?’ »

Смотрим на EMC VNX/VNXe внимательно. Часть 2

 

Сегодня у нас не просто дюжина, а целых три дюжины ножей в спину EMC-шной “революции”, “неудобные вопросы” к EMC по поводу VNX/VNXe от блоггера Recoverymonkey (Dimitris Krekoukias), общим числом 36, опубликованные в его блоге.

Dimitris – сотрудник NetApp, но ведущий собственный, автономный и независимый блог, вне blogs.netapp.com, пишущий много интересного, так что переводы его публикаций в этом блоге будут появляться часто.

Беспрецедентная маркетинговая шумиха, поднятая вокруг старта новых продуктов EMC – систем VNX/VNXe не должна совсем запорошить нам глаза, настолько, чтобы мы не могли критически проанализировать возможные недостатки новой системы, а их, если посмотреть внимательно, хватает. И в особенности остановимся на многократно повторяемом EMC-персонами в отношении новых систем слово Unified
Немного сокращенный перевод поста recoverymonkey предлагается сегодня вашему вниманию.

Questions to ask EMC regarding their new VNX systems…

Posted on January 13, 2011 by Dimitris

  1. Возьмем, к примеру, систему VNX емкостью  100TB. Допустим, что мы отдали все 100TB под NAS. Допустим, что все 100TB были первоначально заполнены данными, но затем, год спустя, объемы данных в NAS уменьшились, и сейчас занимают всего 70TB. Могу я взять эти освободившиеся 30TB и немедленно использовать их под FC? Ну хранилище же теперь “unified”, так? Без необходимости нарушать  best practices для размещения LUN на Celerra?
  2. Является ли VNX (или хотя бы NS, стоящая перед ним) системой, сертифицированной на “пять девяток”? (Это так для CX, но как насчет комбинации CX/NS?)
  3. Где в архитектуре принципиальная разница с тем, что было до сих пор? Все выглядит так, что у вас есть 2 штуки CX SP, и перед ними NAS gateways. Выглядит очень похоже на то что было, и по прежнему в этом нет ничего unified. Давайте все же привнесем немного правды в рекламу! Только маленькие VNXe выглядят чуть иными (не с точки зрения софта, но хотя бы с точки зрения количества корпусов, на которых это работает).
  4. Кажется новые системы лицензируются по емкости?
  5. Могут ли новые системы использовать больше 2TB в FAST Cache? (больше чем текущий CLARiiON CX4-960)
  6. Как дела с гранулярностью при использовании RecoverPoint при репликации NAS-части? Кажется там необходимо реплицировать весь NAS как единый чанк, как одну большую consistency group, с необходимостью использовать Celerra Replicator для большей гранулярности?
  7. Как дела с гранулярностью при восстановлении NAS в RecoverPoint? Нельзя сделать восстановление на уровне отдельного файла или даже тома?
  8. Можно ли сделать обновление с сохранением данных на дисках, в случае уже имеющихся CX3 или CX4 (data-in-place upgrade) или это обновление с полной заменой (forklift upgrade)?
  9. Почему FASTv2 не рекомендован для Exchange 2010?
  10. Может ли FAST на VNX исключать из анализа ряд периодов времени, которые могут сбить его алгоритм, например период создания резервной копии данных?
  11. А FAST файлового уровня это по прежнему отдельная подсистема?
  12. Почему для VNXe в принципе нет варианта использовать FC?
  13. Можно ли обновиться с VNXe на VNX?
  14. А на VNXe есть FAST?
  15. Почему FAST по-прежнему использует такой огромный и неэффективный чанк размером аж 1GB?
  16. Почему такие функции, как блочный доступ, NAS и репликация по прежнему требуют использования отдельного друг от друга железа и софта?
  17. Почему по-прежнему существуют две различные системы создания снэпшотов?
  18. Ну хотя бы теперь блочные снэпшоты не вызывают такого огромного падения производительности? Кстати, как дела со снэпшотами на NAS?
  19. Хотя бы теперь мы можем хранить снэпшоты на системе подолгу, например год, если это нам необходимо?
  20. Почему предлагается целых 4(четыре!) разных средства репликации? (Mirrorview, Celerra Replicator, Recoverpoint, SAN copy)
  21. Что там о сих пор делают в таком количестве все эти разные OS? (Windows в StorageProcessor, Linux в Control Station и RecoverPoint, DART в NAS-blades, может быть больше, если вы захотите добавить Rainfinity и Atmos)
  22. Почему по-прежнему нет дедупликации для FC и iSCSI?
  23. Почему нет дедупликации для памяти/кэша?
  24. Наконец, почему нет суб-файловой дедупликации вообще?
  25. Почему Celerra по-прежнему ограничена объемом 256TB на один data mover?
  26. И Celerra по-прежнему ограничена объемом 16TB на том? Или нам нужна еще одна, полностью отдельная система (Isilon), чтобы получить объем тома больше 16TB?
  27. Celerra по-прежнему не умеет совместно использовать том между data movers? Или для этого опять нужен Isilon?
  28. Почему мы не можем передавать все протоколы по одному 10Gb-линку, если VNX это настоящий “unified”?
  29. Устранены ли проблемы с производительностью при использовании thin provisioning ?
  30. Устранены ли проблемы с “узким горлом” (bottlenecks) для пула?
  31. Можем ли мы в самом деле делать stripe/restripe в пуле FLARE? Когда добавляем пространство? С использованием thin provisioning?
  32. Для того, чтобы использовать thin provisioning, по-прежнему нужна миграция данных?
  33. Устранены ли проблемы с низкой эффективностью RAID5 и RAID6 при записи? И каким образом?
  34. Будут ли бенчмарки для новых систем показываться для RAID6, или это будет, по-прежнему, только RAID10? Как насчет участия в бенчмарках SPC-1?
  35. Почему EMC по-прежнему обходит стороной тот факт, что ее пулы теперь построены с использованием файловой системы? Может быть потому, что они продолжают утверждать, что такое, де, не настоящий SAN, даже в совсем недавних утверждениях?
  36. Теперь, когда EMC использует файловую систему чтобы получить в CX SPs функциональность пулов, thin provisioning, компрессии и auto-tiering (и, возможно, дедупликаци в будущем), как собирается решаться проблема фрагментации? (О как повернулась ситуация!)

Таким образом, когда EMC говорит о “Unified Storage”, они на самом деле имеют ввиду “Unified Management”. Было бы здорово, если бы они были честными, и так бы это и говорили, о “наших новых системах хранения, с новым единым управлением, пусть и не unified-архитектурой”.
Но “новые системы хранения с unified-управлением но не-unified-архитектурой” гораздо хуже выговаривается, чем “unified storage”.
Unified Management, к сожалению,  не может помочь решить многих нижележаших проблем и ограничений, хотя, безусловно, позволяет показать ряд впечатляющих демонстраций.

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

Конечно, средства управления это основной “интерфейс к системе” для конечного пользователя, многие люди не заботятся о том, что там, за ним, внутри, у них нет ни времени, ни склонности учиться. Я просто хочу пригласить их узнать побольше, начать думать о том, как оно там устроено внутри, потому что когда там внутри устраиваются какие-то трюки, и когда внешний GUI прикрывает разрозненных 4-5 различных продуктов, собранных под ним вместе, и когда оно перестает работать так, как задумано, то вас могут начать “футболить” между 3-4 различными и плохо связанными между собой группами поддержки, которые будут пытаться выяснить, какой из продуктов в итоге явился причиной проблемы.

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

И всегда помните, что чем сложнее машина, тем сложнее найти поломку, тем сложнее ее починить, когда она сломалась (а она сломается, они всегда ломаются, все и всегда). Никакая внешняя красота не заменяет чистого и простого инженерного решения внутри.

Конечно, машина в стиле Rube Goldberg-а это прикольно, если прикол есть ваша конечная цель.

Смотрим на EMC VNX/VNXe внимательно. Часть 1

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

Напомню, что в январе EMC с большим шумом и беспрецедентным размахом выкатил ряд новинок, и главную – новую линейку систем хранения младшего-среднего “энтерпрайза” – EMC VNX/VNXe, приходящую на смену классическим CLARiiON/Celerra.
Шум при этом был настолько большой и гм-м.. странный по форме, что сразу возникло подозрение, что этим масштабным лаунчем и сценическим шоу пытаются отвлечь внимание от определенных недостатков и “недоработок” продукта.

Следует отметить, что, безусловно, выпуск VNX это большой шаг EMC, причем шаг в правильном направлении. И пусть злые языки сейчас говорят, что EMC, мол, выпустила новый сторадж, “чтобы было как у NetApp”, мы отметем эти реплики с мест как неорганизованные (с). Приятно, конечно, когда мировой лидер взялся реализовать, пусть и с многолетним опозданием, решения, которые придумала и много лет продвигала значительно меньшая компания, тем самым признавая ее приоритет в этом вопросе, и правильность ее пути. Но все же это решение EMC. Что же нового в этих полностью новых системах хранения?

Ну-у, у них теперь крутая интегрированная система управления Unisphere.

А что там в аппаратной части? Как оно вообще, этот новый Unified Architecture? 
Новые процессора, переход на SAS-диски и SAS-интерфейсы к полкам (велкам ту зе клаб, наконец-то). Новые передние панели, очень эффектные :)
…И все?
А вот похоже на то, что и все. Удивлены? Да не то слово.

Но как же, как же, ведь нам обещали новую, прогрессивную, передовую Unified Architecture, нечто по-настоящему новое, оно где? Оно ведь есть?

Ну-у… Давайте посмотрим, что появилось нового.
Слева – классическая Celerra NS, справа – новый VNX.

image

Может быть я недостаточно фанат EMC (что очевидно), но по моему нам пытаются продать то же самое, но, в лучших традициях ритейла, “теперь в новой, удобной упаковке”, с банановым вкусом. :)

Да, VNX действительно может отдавать данные на дисках по разным, как блочным, так и файловым протоколам, это то, что “у нас в деревне” называется multiprotocol
Но Multiprotocol это все же не то же самое, что Unified.
Рядом, но не то же самое.

Это все равно, как если бы некто, с большим шумом объявил бы о ребрендинге и новом, прогрессивном логотипе компании ЗЕЛЕНОГО цвета. Зеленый это экологичность, он несет в себе стабильность, позитивность, дружественность…
- Погодите, – перебиваете вы докладчика – я что-то не понял. Вы говорите “зеленый”, но логотип же – синий?
- Да какая разница, – отвечают вам, зеленый это теперь новый оттенок синего! Главное что он – ЗЕЛЕНЫЙ, новый, и прогрессивный!

Самое печальное в этой истории, что когда такая маркетинговая и сейловая машина, какой располагает сегодня EMC, начнет настойчиво твердить рынку, что зеленый – это новый оттенок синего, а мультипротокольность – это и есть unified architecture, то рынок неизбежно, в конце концов, и сам поверит, что черное - белое (просто плохо освещенное) , зеленое – синее (ну, другой оттенок просто), а Unified Architecture – это собрать пять ящиков под тремя OS в одном шкафу, и продать клиенту по одной накладной.

Давайте все же остановимся на некоторых очевидных недостатках и проблемах для клиента при переходе на VNX/VNXe, видимых, так сказать, с “нашего берега” этой реки:
(Прошу держать в памяти, что я не являюсь специалистом по оборудованию EMC, и что если где-то здесь, или в любом другом посте, где я говорю о продуктах конкурентов, я допускаю неточность или ошибку, не стесняйтесь мне на нее указать, я поправлю это место, спасибо.)

  • Полный отказ от “старых” дисковых полок, подключаемых по FC. Невозможность сделать data-in-place upgrade, то есть с сохранением данных на уже существующих дисках. Ну и что, что у вас уже два шкафа с дисками EMC под год назад купленный Кларион CX4 и 24×7 ERP-база на них? Купите еще два шкафа дисков, скопируете, потом старые продадите кому-нибудь.
  • Forklift upgrade даже и с VNXe на VNX, как бы ни были похожи аббревиатуры моделей – апгрейд только целиком, никакого data-in-place (с сохранением данных). “Внутри” VNX от VNXe отличаются сильно, не позволяя прямого перехода.
  • Для VNXe нет FC как интерфейса подключения. Вообще нет. 
    Да, VNXe это entry level, и использование entry level с FC это, обычно, overkill, но, допустим, у вас есть уже развитая FC-инфраструктура с “большими” стораджами, и вам понадобилось включить в нее небольшой вспомогательный сторадж, для бэкапа-ли, для удаленной реплики, неважно. Включить в FC-фабрику VNXe вы не можете. Просто некуда.
  • В VNXe нет FASTcache. Нет и не будет. Увы.
  • По-прежнему полностью раздельная архитектура. Отдельно блочный сторадж (под FLARE), отдельно файловый гейтвей data mover (под DART), отдельно Control Station (под Linux), отдельно объектный гейтвей Athmos. С общим, снаружи, управлением под Unisphere. Никакого Unified Target.
  • Только файловая дедупликация. Значит нет дедупликации для LUN-ов, например для Datastore под VMFS в VMware. Совсем нет. А для файлов эффективность меньше, чем в случае субфайловой/блочной дедупликации. Кстати для VMware и Oracle по NFS ее нет тоже.
  • Множество разнородных софтверных средств для одних и тех же задач. Три разных инструмента для использования снэпшотов (SnapSure (file), SnapView (block), RecoverPoint SE/CDP (block)), три – для репликации (Replicator (file), MirrorView (block), RecoverPoint SE/CRR (block)), два – для локальных клонов (SnapSure (file), SnapView Clones (block)). Все с разными функциональными возможностями и особенностями применения.
  • Capacity-based licensing. Низкая цена “на старте” может оказаться совсем не такой низкой, если вам понадобится увеличить емкость (а вам понадобится ее увеличить, это, в нынешнем мире, неизбежно) – готовьтесь платить еще, позже.

В среду читайте перевод статьи блоггера recoverymonkey о вопросах к EMC по поводу запуска VNX, а далее, на следующей неделе, в понедельник и четверг соответственно, мы рассмотрим подробнее каждое семейство, VNXe и VNX, и то как, и чем они собираются конкурировать с системами NetApp.

image

Что такое SnapVault и куда это применить?

В новых Software Bundles, которые приходят новым покупателям систем NetApp часто включены лицензии на SnapVault (пример – Windows Bundle для распродажных FAS2020, о которых я писал ранее). Однако, к сожалению, всё еще не все хорошо представляют себе как это работает, как может применяться, и чем может быть полезно.

SnapVault это средство D2D Backup для систем хранения NetApp (а в случае использования Open Systems SnapVault – OSSV – и для обычных серверов), использующее их возможности по созданию и удаленному хранению снэпшотов.

Как вы знаете, в отличие от всех прочих систем хранения, использующих то, что у них также называется “снэпшоты”, NetApp не только не возражает, но даже поощряет хранить снэпшоты долговременно, непосредственно на дисках. Дело в том, что хранение снэпшотов на дисках, как своеобразной локальной “резервной копии”, вместе с собственно данными, не приводит к падению производительности всей системы хранения, как это происходит с COW (Copy-On-Write) “снэпшотами”. Поэтому на всех системах, кроме NetApp, снэпшоты используются лишь как “временное хранилище” состояния данных. Создали снэпшот в ночной тиши слабозагруженного датацентра, быстро слили на ленты или другое архивное хранилище, и скорее удалить.

NetApp-EMC-snapshots

Не все йогурты снэпшоты одинаково полезны. :)

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

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

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

Было бы неплохо и копировать снэпшоты наружу как-то “по-снэпшотному”, сохраняя эту их эффективность использования места.
Именно это и делает SnapVault.
SnapVault – это способ хранить снэпшоты рабочих данных на внешнем хранилище, но “по-снэпшотному”, экономя пространство хранения.

Лицензии на SnapVault существуют в двух “ролях”. Одна называется SnapVault Primary, а вторая – SnapVault Secondary.

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

SnapVault Secondary – это лицензия, устанавливаемая на получателя резервных копий. На систему, которая хранит резервные копии от одной или нескольких SnapVault Primary систем.

В качестве SnapVault Primary может также работать так называемый Open Systems SnapVault (OSSV) – программный продукт (его для NetАpp написала компания Syncsort), устанавливаемый непосредственно на сервера под управлением Windows/Linux/etc и позволяющий им играть роль SnapVault Primary систем, делать на них снэпшоты (разумеется с определенными ограничениями, присущими то или иной OS), передавать их на хранение на систему SnapVault Secondary (В роли SV-Sec может быть только NetApp, нет OSSV Secondary), и восстанавливать их с таких снэпшотов, при необходимости.

Как и для чего можно применить SnapVault?

Например можно централизованно хранить резервные копии данных от множества отделений основного бизнеса, где, очень часто, нет достаточного бюджета и ресурсов для организации полноценного бэкап-решения. В случае использования SnapVault вам нужно только раз настроить расписание на удаленных системах и политики хранения резервных копий на центральном хранилище (это может быть выделенная система, или же пространство на основной системе хранения NetApp головной компании, с лицензией SV-Secondary на ней. А с использованием OSSV это можно делать и без систем NetApp в качестве Primary. И в дальнейшем резервные копии от всех систем будут автоматически, по расписанию, приходить на ваше хранилище с ролью SV-Secondary в главном датацентре.

SnapVault1

При этом только в первый раз будет передан полный объем хранения (так называемая baseline copy) для создания первоначального “снимка”, в дальнейшем через каналы передачи данных будет передаваться уже только “разностная” информация, например только измененные за день работы блоки данных.
Допустим, что общий объем данных на вашей удаленной системе хранения равен 100GB. Но в течении суток меняется только около гигабайта.
Тогда при первом, baseline transfer, будет передано все 100GB (это можно сделать, например, локально, перед тем, как отвезти систему хранения в удаленный офис), а затем, при ежедневном копировании, будет передаваться всего 1GB. И целый месяц ежедневных резервных копирований полной системы на Secondary-системе в центральном офисе займет всего около 130GB.

Также можно использовать SnapVault и для организации удаленной копии данных для Primary-системы для “квази-DR” решения. При этом в качестве резервного хранилища для мощной SnapVault Primary может служить недорогая и с невысокой производительностью, достаточной только для приема и хранения реплики данных, система с лицензией SnapVault Secondary.

SnapVault2

Совместно и интегрированно с NetApp SnapVault могут работать такие программные продукты, как CommVault Sympana Suite и Syncsort Backup Express.

Настраивать и управлять работой SnapVault можно как из командной строки, так и с помощью отдельного программного продукта NetApp – Protection Manager, который также сейчас поставляется в составе многих бандлов, например в ONTAP Essential для FAS3200/6200.

Наилучший способ углубиться в тему – прочесть TR-3487 SnapVault Best Practices Guide,
и TR-3466 Open Systems SnapVault Best Practices Guide.

Я помню, что обещал вам “исследование” по истории фрагментации в файловых системах, но что-то у меня пока куражу нет его дописать на нужном уровне, придется подождать. Читайте пока про SnapVault, а на следущих две недели у меня спланирована большая программа по углубленному “полосканию косточек” EMC VNX/VNXe. Не переключайте ваши браузеры, будет интересно. :)

В библиотеку FUD-а ;) HP о дедупликации.

В сегодняшнем переводе у нас будет еще один активный блоггер NetApp, Larry Freeman, пишущий с ником Dr.Dedupe. Его основная тема в блоге – технология дедупликации в системах хранения NetApp, а поводом для переведенного поста – “Неспровоцированная агрессия” в отношении NetApp со стороны HP, которая выпустила в свет документ, под названием “Understanding the Challenges Associated with NetApp’s Deduplication” – “Разбор проблем, связанных с технологией дедупликацией NetApp”.

Ну что-ж, ответом на неспровоцированную агрессию будет наше принуждение к миру. ;)

HP Launches an Unprovoked Attack on NetApp Deduplication

By Larry Freeman AKA Dr.Dedupe

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

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

Утверждение HP:

Первичные данные (здесь и далее я буду переводить слово primary как “первичные”, этим словом принято называть основные, активные, “боевые” данные приложений, в противоположность данным резервных копий и архивов, например. Прим. romx) имеют случайный характер  доступа по своей природе. Дедупликация приводит к тому, что различные блоки данных записываются в различные места диска. NetApp WAFL усугубляет проблему, записывая данные в свободные места, ближайшие к головке записи дисков. Чтение данных вызывает пересборку этих блоков, в формат пригодный для чтения приложением. Оверхед, вызываемый этой пересборкой данных, оказывает влияние на производительность, обычно на 20-50%”

Ответ Dr.Dedupe:

NetApp WAFL (Write Anywhere File Layout) – это структура размещения произвольно расположенных данных на диске, оптимизированная на производительность доступа к ним. Дедупликация еще более “рандомизирует” эту структуру, переназначая указатели на блоки данных и удаляя дубликаты. После дедупликации производительность на чтении иногда слегка возрастает, иногда слегка падает, однако подавляющее большинство пользователей говорят, что не заметили никакой разницы вообще. Важным моментом является то, что мы не перемещаем данные как таковые, просто переставляем на их блоки указатели. Если вы хотите получше разобраться в том, как работает наша технология, то я рекомендую посмотреть пример работы дедупликации.

Утверждение HP:

“Когда клиенты NetApp испытывают проблемы с производительностью, первая рекомендация NetApp это не использовать дедупликацию”

Ответ Dr.Dedupe:

На самом деле, когда наши клиенты испытывают проблемы с производительностью, первая рекомендация это обнаружить причину, вызвавшую проблемы с производительностью. Зачем выключать дедупликацию, если не она вызвала проблему? Полагаю, что HP поступает точно также, сперва надо найти причину, прежде чем советовать какие-то действия по исправлению ситуации. Или тут HP случайно выстрелила сама в себя? Эй, HP, давайте вы не будете строить предположений, что мы советуем нашим клиентам, пока на самом деле не позвоните в нашу поддержку?

Утверждение HP:

“Снижение темпов роста емкостей хранения имеет большое значение, и экономит затраты пользователя. Однако для первичных данных другие технологии, например Thin Provisioning обеспечивают сходные результаты уменьшения объемов, но без сопутствующего снижения производительности; эти возможности имеются у HP P4000 и HP InServ.”

Ответ Dr.Dedupe:

Заметьте, HP не сказала “эти возможности имеются только у HP P4000 и HP InServ.” Потому что у систем NetApp тоже есть Thin Provisioning, а также много других технологий уменьшения занимаемых объемов хранения и повышения их эффективности, которые могут использоваться как по по отдельности, так и друг с другом, одновременно:

  • Дедупликация
  • Thin Provisioning
  • Эффективно расходующие место снэпшоты
  • Виртуальные клоны данных
  • Thin-репликация
  • RAID-DP
  • Онлайн-компрессия данных
  • Автоматический виртуальный tiering c дисками SATA

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

Утверждение HP:

“Метод с фиксированными участками [используемый NetApp] означает, что изменения в данных могут привести к очень плохому результату дедупликации… Использование метода с переменной длиной участка позволяет HP StorOnce D2D обеспечить более интеллектуальный и эффективный подход к дедупликации.”

Ответ Dr.Dedupe:

Ох, черт. Неужели мне так и придется писать это, снова и снова? NetApp записывает все данные в блоки (ну, то есть “участки”), размером 4KB. За прошедшие 20 лет мы сделали довольно неплохую работу по оптимизации того, насколько быстро мы можем писать и читать эти “участки”. Наиболее простой и быстрый способ дедупликации в нашем случае, это получать “цифровой отпечаток пальца” каждого такого участка, и сканировать базу этих “отпечатков” на дубликаты. Это лучший вариант для одновременного использования дедупликации в обоих сферах применения, как для первичных данных, так и для резервных копий. Достаточная экономия пространства хранения и минимальное влияние на производительность. В HP читают хоть что-нибудь в моем блоге? Переменные участки это хорошо для экономии места, но совсем не так здорово для производительности. Кто более интеллектуален и эффективен? Судите сами.

Утверждение HP:

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

Ответ Dr.Dedupe:

Ну, HP, вот тут вы меня по настоящему разозлили. Прежде всего вы привели цитату из слов Криса Каммингса, сказанную еще в августе 2008 года, я уверен, что если бы вы могли вернуться назад во времени, вы бы могли найти консервативный комментарий о любой новой технологии от того, кто заботится о клиенте. Но фактом является то, что сегодня для нас это уже не новая технология, и мы рекомендуем ее использование нашим клиентам без каких-либо опасений.
Насчет того, что дедупликация на устройстве хранения резервных копий не влияет на производительность первичного хранилища – дык! :)

Утверждение HP:

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

Ответ Dr.Dedupe:

Вместо того, чтобы писать труд о проблемах технологии другого производителя, лучше бы HP исследовала проблемы, с которыми сталкиваются пользователи сегодня – а именно о том, что они борются с постоянным ростом объемов данных в условиях сокращающегося IT-бюджета. Может тогда бы стало понятно лицемерие сравнения с оркестром. Когда HP хочет продать пользователям оркестр в 120 человек, NetApp продает компактный, но эффективный джаз-бенд.

Утверждение HP:

“NetApp не обеспечивает достаточной гибкости для сложных сред резервного копирования сегодняшнего дня”

Ответ Dr.Dedupe:

Погодите минутку, что произошло? Кажется я что-то пропустил? Я думал, что мы говорим о проблемах дедупликации у NetApp, как это мы вдруг перескочили на гибкость резервного копирования? Это что, такой способ сбить читателя перепрыгивая с темы на тему?

Утверждение HP:

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

Ответ Dr.Dedupe:

Снэпшоты? А теперь мы говорим про снэпшоты? Извините меня, HP, не могли бы вы все же не скакать с темы на тему? “Разбор проблем, связанных с технологией дедупликацией NetApp”, вы помните? Ну, с другой стороны, я так понял, что просто “проблемы” у нас закончились…

Dr.Dedupe (http://blogs.netapp.com/drdedupe)

О “дефрагментации”

“Усилиями” наших конкурентов все нынешние и будущие пользователи NetApp проинформированы, что “у этих netapp”, дескать, “огромная фрагментация”. Как обычно в области FUD (Fear, uncertainty and doubt), строится это все вокруг плохого понимания предмета, слабой технической подготовки “обрабатываемого”, а порой и откровенной манипуляции фактами. Отсутствие же ясного понимания темы, к сожалению, вызывает к жизни довольно много “техномистицизма” и накрученных вокруг догадок и слухов, которые, как и положено слухам, кормят и размножают сами себя.

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

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

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

Если вы внимательно прочли наш переводной Best Practices по работе с VMware или Hyper-V,то должны были обратить внимание на строгое указание не использовать дефрагментатор OS на дисках, расположенных на системе хранения NetApp, будь то iSCSI/FC LUN, смонтированный на сервер, или же VHD/vmdk виртуальной машины.

Дело в том, что дефрагментатор в OS, это программа, которая ничего не знает о той, часто непростой структуре, что лежит под тем, что она считает “обычным жестким диском”. Она видит нечто (LUN), которое представляется ей обычным жестким диском, с секторами, головками и цилиндрами, но в случае LUN все это не имеет настоящего физического смысла. Под таким “псевдо-диском” могут лежать структуры RAID, или те или иные структуры организации его физических блоков (в случае NetApp – WAFL, в случае других систем, других вендоров – другие структуры) . На этом уровне работает непростая  дорогостоящая логика оптимизации доступа в больших системах хранения, которая знает как, и умеет оптимизировать доступ к своим данным. И вмешательство в эту логику примитивной “дефрагментации” на уровне OS не только бессмысленно, но и нежелательно. И уж точно никак с помощью defrag.exe не справиться с проблемой “фрагментации данных на NetApp”, ситуацию можно только ухудшить.

В случае конкретно NetApp, выполнение “дефрагментации” на уровне клиентской OS или виртуальной машины:

  1. Резко увеличивает объемы, занимаемые снэпшотами, так как пространство диска на NetApp со взятым снэпшотом занимает только изменения (записи), сделанные на нем после создания снэпшота, а “дефрагментация” при работе перезаписывает почти весь диск, то вы обнаружите, что снэпшот после такой “дефрагментации” практически удвоит занимаемое вашим томом на дисках место
  2. Портит оптимизацию доступа на уровне системы хранения, так как то, что, по мнению дефрагментатора, лежит рядом и последовательно, физически, на уровне системы хранения, и собственно физических дисков, может лежать совсем НЕ рядом и НЕ последовательно, и наоборот.
  3. Замусоривает кэш и загружает канал ввода-вывода бессмысленными операциями.

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

Если вы все равно не осилили все написанное выше, то просто следуйте простым советам:

  • Не используйте дефрагментацию в OS (defrag.exe, Diskeeper, Norton Defrag, etc.) для данных, расположенных на системе хранения NetApp. В том числе отключите автоматическую оптимизацию (Boot Time Optimization) и фоновую дефрагментацию дисков в OS Windows.
  • Не обращайте внимания на величины “фрагментации”, указываемые самой OS для LUN-ов и дисков виртуальных машин, размещенных на NetApp.
  • Для минимизации эффекта фрагментации записи непосредственно на дисках системы хранения NetApp используйте включение по расписанию встроенный в Data ONTAP реаллокатор (reallocate on / reallocate start [/vol/volname]).

 

 

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

Оптимизация производительности. Часть 4. fcstat

Рассмотрим еще одну полезную команду для глубокой диагностики, позволяющую находить и анализировать проблемы канала передачи данных от диска к контроллерам на системах, использующих интерфейс FC к дискам. Это системы с полками DS14, которые постепенно заменяются на дисковые полки, работающие по SAS, в новых моделях FAS, но все еще широко распространенные в продакшне.

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


na_fcstat - Fibre Channel stats functions

Формат:
fcstat link_stats [ adapter number ]
fcstat fcal_stats [ adapter number ]
fcstat device_map [ adapter number ]

Continue reading ‘Оптимизация производительности. Часть 4. fcstat’ »

18/0.204

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