Archive for августа 2011

Vox Populi: Как вы поступаете со стораджами после истечения hardware warranty (3 года)?

Сегодня будет необычный пост. Я решил дать слово читателям, и провести опрос на тему:

Что вы делаете со "старыми" системами хранения NetApp (после 3 лет)?

  • Продляем поддержку после 3 лет (postwarranty), пока система физически "тянет" задачу. (41%, 42 Votes)
  • "Не ломается - не трогай". Ничего не делаем, поддержку продлять дорого. (37%, 38 Votes)
  • Наша система недавно куплена и мы не думали над этим вопросом. (20%, 21 Votes)
  • После истечения гарантии списываем и покупаем новую модель. Надежность для нас - все. (2%, 2 Votes)

Total Voters: 103

Загрузка ... Загрузка ...

Не секрет, что срок жизни системы хранения зачастую превышает срок ее hardware warranty (3 года).
Как же именно поступают пользователи с системами, срок warranty на которые истек?

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

Опрос, понятное дело, анонимен.

UPD:Заодно посмотрю как оно тут вообще в вордпрессе работает ;)

Бесплатные Flash Cache для FAS6240/80

По сведениям вебсайта, распространяющего слухи, сплетни и жареные факты из мира IT, небезызвестного theregister, NetApp будет поставлять старшие модели своей линейки, то есть FAS6240 и FAS6280 с уже включенным за нулевую цену модулем Flash Cache 512GB, в качестве бонуса.

Официальное сообщение об этом состоится, по всей видимости, в сентябре.

Flash Cache (ранее также PAM II) это плата на внутренней шине PCIe, с установленной на ней Flash-памятью, объемом 256, 512GB и 1TB, которая используется как “кэш второго уровня” в системах NetApp. Использование такого “кэша” позволяет построить так называемый “Virtual Storage Tiering”, при котором самые активно считываемые данные системы хранения находятся в таком “мегакэше”, скорость обращения к которому примерно вдесятеро выше.

Опубликованы также подтвержденные результаты, показывающие высокую эффективность использования Flash Cache как для NAS-протоколов, так и для SAN.

UPD: Подтверждено. 1TB на двухконтроллерную систему (по одному 512GB Flash Cache в каждый контроллер) FAS6240/6280 за цену 0. В конфгураторе будет доступно с 12 сентября.

Одинаковые имена томов и аггрегейтов на системе хранения

Любопытную залипуху недавно пришлось разрешить. При объединении на одной системе хранения дисков, аггрегейтов и томов с нескольких других, на системе оказалось несколько томов с одинаковыми именами (ну да, на каждой был свой ‘vol0’, к примеру).

Для устранения этой проблемы Data ONTAP автоматически изменяет имена таких дублирующихся ресурсов, добавляя цифру в скобках. Однако проблема (по крайней мере в 7.x) в том, что такие авто-переименованные ресурсы нельзя переименовать вручную. Но можно переименовать исходный, который вызвал автопереименование последующих. Результат будет такой:

fas1> vol status
  Vol_data    online          raid_dp, flex     create_ucode=on
  Vol_data(1) online          raid_dp, flex     create_ucode=on
  Vol_data(2) online          raid_dp, flex     create_ucode=on
 
fas1> vol rename vol_data vol_data_orig
fas1> vol status
  Vol_data_orig  online    raid_dp, flex     create_ucode=on
  Vol_data  online          raid_dp, flex     create_ucode=on
  Vol_data(1) online          raid_dp, flex     create_ucode=on

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

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

Помощь, как всегда, была найдена в TFM  ;) – NetApp Storage Management Guide.

How you manage duplicate volume names

Из чего складывается величина IOPS отдельного диска?

Я в этом блоге уже несколько раз упоминал тот факт, что жесткий диск имеет определенную “конструктивно заданную” величину параметра IOPS – Input-Output Operations per Second – число операций ввода-вывода в секунду для random-операций. Отдельный жесткий диск имеет производительность в IOPS сравнительно небольшую. Так, для дисков SATA говорят о 75 IOPS, то есть отдельный диск может произвести за секунду 75 операций чтения или записи блока данных с “блинов”. Несколько производительнее диски SAS или FC, до 175 IOPS при скорости вращения 15000 оборотов в минуту. Это совсем не грандиозные объемы операций. Ну представьте, 75 операций ввода вывода (записи и чтения) в секунду. Всего лишь. Если у вас на компьютере работает примерно 30 процессов (программ и системных сервисов), то на каждый такой процесс приходится всего две с половиной операции чтения или записи в секунду.

Именно для повышения производительности в дисковых системах хранения данных используется множество дисков. Совсем не ради емкости, по крайней мере сегодня – как правило. Ведь чем на большее число физических дисков (на нашем птичьем языка-жаргоне прижилось калькированное с английского, и отдающее машинным маслом токарного станка словечко “шпиндель” (spindle), означающее физический жесткий диск) мы можем разложить наши данные, чем больше дисков задействовать для обслуживания ввода-вывода, по 75 (или 175) с каждого, тем выше получится суммарная производительность системы хранения на операциях random read/write.

Но откуда же берется это мистическое число “IOPS со шпинделя”, чем оно так жестко определяется?

На самом деле формула, определяющая эту величину довольно проста.

IOPS Estimated = 1 / ((seek time in ms / 1000) + (latency in ms / 1000))

Как вы видите, двумя основными параметрами диска, задающими величину в IOPS являются величина времени seek, то есть перехода магнитной головки от одной позиции до другой, и latency, то есть величины задержки от момента отправки команды, до получения запрошенного на выходе.

Возьмем, для примера диск Seagate SATA 1TB, 7200RPM:

Estimated IOPS = 1 / ( ( (average read seek time+average write seek time) / 2) / 1000) + (average latency / 1000) )

или с указанными в спеках данных для данного диска:

Estimated IOPS = 1 / ( (9.00 / 1000) + (4.16 / 1000) ) = 1 / ( (0.009) + (0.00416) ) = 75.987 - ~ 75 IOPS

Или для диска Seagate SAS 600GB 15KRPM:

Estimated IOPS = 1 / ( (3.65 / 1000) + (2.0 / 1000) ) = 1 / ( (0.00365) + (0.002) ) = 176.99 - ~ 175 IOPS

Вышел NetApp OnCommand Core Package

Даже чуть раньше графика зарелизился новый продукт NetApp – OnCommand.

Напомню, что NetApp OnCommand это новый “зонтичный” бренд для целого семейства софта управления, куда буде входить много что, например софт, ранее известный как Protection Manager, Provision Manager и Operations Manager, а также Appliance Watch и SnapManager for VMware и Hyper-V, и еще несколько продуктов. По сути под именем OnCommand будет собран весь многочисленный арсенал средств администрирования, наработанный до сего дня в NetApp (как видите, не только EMC учится у NetApp, но и NetApp тоже;).

Если у вас есть действующий логин в NOW (NetApp Support site), то вы можете получить ту часть OnCommand, что будет доступна для пользователей бесплатно (OnCommand Core Package), уже сейчас по данной ссылке.

Обратите внимание на предварительные требования к системе и оборудованию, а также прочтите release notes и installation guide.

Выбор хранилища для виртуальной серверной среды. Forrester.

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

Крупная и известная аналитическая компания 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%).

image

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

challenges2009

 

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

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

image

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

image

 

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

Традиционные стораджи и NetApp V-series. Производительность.

Любопытный отчет на днях опубликовала независимая аналитическая компания 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.

image

image

 

image

 

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

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

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

EMC VNX5100 – “не совсем VNX”

Я тут уже несколько раз останавливался на новых продуктах 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 (лат.) – “Покупатель – остерегись!”, приписка традиционно делаемая при изложении чувствительной для покупателя информации, особенно в области технических характеристик или условий покупки.

Аутентификация в админской консоли по заранее сконфигурированному ключу SSH

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

Самый удобный вариант – организовать подключение по SSH, однако, для того, чтобы не передавать пароль, сгенерировать заранее public key, и авторизоваться на консоли NetApp с его помощью.

Вот как это сделать с помощью популярного PuTTY.

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

Выберите пользователя, для которого мы будем устанавливать ключ. Помните также, что если вы используете выполнение каких-то скриптов от стороннего, специально сконфигурированного пользователя (например используя RBAC – Role-based Accees Control), то это надо будет также проделать и для него. Закрыв доступ для всех ключей, кроме заранее сконфигурированных, вы заблокируете таких пользователей также.

Далее нам надо создать на контроллере поддиректорию для файла ключей, она должна располагаться внутри директории sshd
полный путь, таким образом, с точки зрения стораджа будет выглядеть примерно так (для пользователя root):

/vol/vol0/etc/sshd/root/.ssh/

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

Смонтируйте root-vol в директорию на вашем компьютере по NFS или CIFS.

Перейдите в директорию /mountpoint/etc/sshd и создайте в ней директорию с именем нужного пользователя, например мы будем использовать для администрирования пользователя romx, а для исполнения скриптов пользователя scripter.

Перейдите в созданную директорию и создайте в ней поддиректорию с именем .ssh (с точкой в начале!)

Убедитесь, что директория успешно создалась, выйдите на уровень /mountpoint, например командой cd ../../../ и размонтируйте шару.

Вы получили следующую структуру на контроллере NetApp: /etc/sshd/romx/.ssh и /etc/sshd/scripter/.ssh соответсвенно.

Теперь сгенерируем пары ключей. Запустите программу puttygen.exe, входящую в состав пакета PuTTY.

putty-listing

Убедитесь, что используете security algorithm SSH2-DSA (Data ONTAP умеет использовать cipher для SSH только TripleDES), щелкните “Generate!” и поводите мышкой для генерации случайной инициализацонной последовательности.

putty-gen

Ключ сгенерирован, теперь надо указать контроллеру NetApp использовать для аутентификации этот ключ. Запишите его в файл с расширением .ppk, например romx.ppk

Не указывайте никакую passphrase.

putty-keygened-pic

Скопируйте из файла public-информацию, затем создайте в созданной на контроллере директории файл authorized_keys (без расширения) и запишите туда скопированный фрагмент. Обратите внимание, что в текстовом редакторе, где вы это проделываете, должен быть выключен режим перевода строк, иначе в ваш ключ могут попасть лишние символы перевода строки. Вся последовательность public key должна располагаться в файле в одну строку! Сохраните файл. Обратите внимание на то, что файл должен не иметь расширения!

key in-line

Теперь включите на контроллере режим использования преконфигурированных ключей:

filer1> options ssh.pubkey_auth.enable on

Давайте протестируем подключившись с помощью программы plink из состава PuTTY, и запросив что-нибудь из консоли:

c:\putty> plink.exe -i romx.ppk romx@filer1 vol status

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

Также рекомендуется для аккаунта, исполняющего скрипты, из соображений безопасности, запретить “лишние” возможности. Подробнее об ограничении прав аккаунта смотрите в документе RUS TR-3358 Role-Based Access Control for Data ONTAP 7G.

21/0.171

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