Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/sync4me/domains/aboutnetapp.ru/public_html/blog/wp-includes/plugin.php on line 311
2011 Октябрь | about NetApp - Part 2

Archive for октября 2011

SearchStorage Quality Awards 2011 for Midrange Storage

В марте этого года я уже рассказывал о проводимом интернет-журналом SearchStorage опросе пользователей, призванным выявить самую удачную, по мнению самих пользователей, систему хранения в highend, и вот, ближе к концу года, были подведены итоги другого такого опроса, о системах хранения в сегменте midrange, 457 участников оценили 797 систем хранения сегмента Midrange, разных производителей.

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

Я всегда говорю, что в таких опросах и отчетах самый смысл не столько непосредственно в самих абсолютных цифрах, сколько в динамике изменений. ? если в highend NetApp в бесспорных лидерах уже второй год, то в midrange борьба куда напряженнее. В прошлом таком обзоре лидерство было за системами Compellent, ныне принадлежащим Dell, однако, даже несмотря на это, NetApp сделал, в глазах пользователей, огромный скачок, поднявшись за год с четвертого места, за HP и HDS, на первое.

image

Стоит отметить, что лидирующая восьмерка показывает в целом очень близкие и высокие результаты, и разница между ними, будем откровенны, весьма невелика. Тем не менее, всего на одну сотую балла NetApp в этом году обошел Dell-Compellent, а с учетом динамики своего роста, нельзя не признать, что это победа совсем не просто “в одну сотую”.

К сожалению, в этом году SearchStorage решила не предоставлять подробный PDF с описанием, ограничившись только результатом, но, например, в тексте статьи можно найти некоторые интересные детали. Так, за Dell выступала “сборная команда” Dell CX + Compellent +Equallogic PS (93 системы), за EMC учитывались Clariion CX и VNX (184), за HP – EVA, P4000, 3Par E200/F200/F400 (129), IBM был представлен Storwise V7000, DS3950, DS4000, 5000 и 6000 (84), Oracle моделями 6000 и 7000, но без Pillar, который, посчитанный отдельно, не набрал статистически значимого количества отзывов (43), и Nexans E-series (15). Количество участвовавших в оценке систем NetApp составило 124, то есть по текущей “популяции” и распространенности у пользователей они уступили только EMC и HP. Стоит отметить также, что по сравнению с результатом прошлого года, количество систем NetApp у пользователей увеличилось почти вдвое (с 69 до 124)

?, наконец, самый важный, на мой взгляд, результат всего опроса, показывающий непосредственную удовлетворенность пользователей их системой хранения -  ответ на вопрос: “Купите ли вы такую систему снова?”

image

?спользование систем хранения NetApp для решений VMware View 5

На днях я завершил перевод Best Practices по наилучшим методам конфигуирования, сайзинга и использования систем хранения NetApp для построения виртуальных десктопных инфраструктур (VDI) в среде VMware View. В ближайшие дни он будет доступен по обычному для всех таких переводов адресу, на сайте дистрибуторской компании Netwell. Переводы, напомню, делаются по заказу Netwell и компании A-systems, мир с ними обоими;), так что если вы хотите написать пожелания, благодарности, или, например, высказать предложения о дальнейших темах таких переводов, то пишите на info@netwell.ru и info@a-systems.ru.com. Не забывайте, что от вашего фидбэка напрямую зависит дальнейшее продолжение работ по переводу Best Practices. Отсутствие видимого отклика, зачастую, создает впечатление, что это никому не нужно и не интересно, и непонятно зачем на это тратить деньги и время, ведь все могут свободно прочесть это на английском, с сайта NetApp.

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

?спользование систем хранения NetApp для решений VMware View 5
Chris Gebhardt, NetApp
Сентябрь 2011 | TR-3705
Версия 5.0

UPD: Уже доступен для скачивания!

Обратите внимание, это на самом деле документ за сентябрь этого года, и на самом деле уже для VMware vSphere 5 и View 5!

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

Также, если вы здесь впервые, и пропустили в начале поста собственно ссылку на большое собрание переведенных на русский NetApp Best Practices на разные темы, то вот вам она еще раз: http://www.netwell.ru/production/techbiblioteka.php

Вы всегда можете ее найти в этом блоге справа в блоке “Ссылки” под названием “техбиблиотека на русском”.

Например в ней вы можете найти сейчас такие полезные документы, как:

Руководство по развертыванию Citrix XenDesktop 5 на VMware vSphere и Citrix XenServer, c использованием систем хранения NetApp

Citrix XenServer V5.0 и системы хранения NetApp: наилучшие практики

Руководство по наилучшим способам использования систем NetApp с VMware vSphere v4.1

Наилучшие методы использования систем хранения NetApp для решений виртуализации Microsoft Hyper-V

?спользование NFS в VMware

Ethernet для систем хранения: наилучшие методы.

Ну и, конечно, на многие друге темы, не только про виртуализацию.

Не стесняйтесь оставлять фидбэк в адрес Netwell и A-Systems, основных спонсоров проекта перевода.

Что такое QTree?

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

Q: Что такое этот QTree?

A: QTree (Quota Tree) это элемент структурной иерархии дисковых ресурсов на NetApp. По-простому, “по-крестьянски”, QTree это такая поддиректория-папка, находящаяся на томе-volume. Вы можете “зашарить” корень созданного тома, и хранить ваш файлы прямо в этом корне, или же создать в этом корне один или несколько QTree-поддиректориев, “шарить” как сетевой ресурс уже их, и хранить данные в них. Пример такой структуры: /vol/vol1/homedir и в нем qtree ?/user1’, ?/user2’ и так далее для домашних папок пользователей.

Q: Зачем он нужен?

A: Qtree это структурный элемент, на который можно назначить так называемые Quotas, то есть лимиты для пользователя или группы пользователей по объему занятого ими дискового пространства на системе хранения. Непосредственно на корень тома назначить квоты пользователям нельзя, а вот на qtree на этом томе – можно.

Q: Можно ли обойтись без него?

A: Нельзя сказать, что без QTree не прожить, сегодня это скорее некая дополнительная возможность, в первую очередь ориентированная на NAS-применение, но это хорошая дополнительная возможность, повышающая гибкость использования, к тому же знать что такое qtree, и как с ним работают вам понадобится, если вы надумаете сдавать сертификацию NCDA (NS0-154), в экзамене есть заметное количество вопросов, требующих этого понимания.

Q: Что это за возможности?

A: Кроме уже указанного квотирования места на пользователей, Qtree используется также для операций репликации SnapMirror, это так называемый режим QTree SnapMirror, в отличие от режима Volume SnapMirror. Отличаются эти режимы тем, что репликация Volume SnapMirror работает на уровне тома, и реплицирует том, именно как том, целиком, то QTree SnapMirror реплицирует данные на файловом уровне, “пофайлово”. Оба варианта имеют свои плюсы и минусы, достоинства и недостатки, и хорошо дополняют друг друга, полезно вам будет разобраться в их особенностях, если вы планируете использовать SnapMirror в своем решении.

SMB vs. iSCSI: как дела у Hyper-V? Результаты неожиданны.

Любопытную, и, честно говоря, даже неожиданную для меня тему исследовал блоггер NetApp Lobanov.

Следящие за темой уже знают, что в Hyper-V 3.0 Microsoft объявила, что будет поддерживать работу по NAS протоколу SMBv2.2.

Вы помните, что VMware уже с версии 3.0 активно рекомендует использовать NAS для подключения датасторов виртуальных машин по файловому протоколу NFS, и пользуется  при этом большими преимуществами такого варианта перед “классическим” блочным FC и iSCSI, о чем я уже не раз писал в этом блоге. Однако у Microsoft в ее Hyper-V не было такой возможность в штатном, поддерживаемом порядке, впрочем и пользователи, скорее всего, не особо это требовали. Отчасти это было связано с широко распространенным убеждением, что NAS-протоколы, и уж CIFS/SMB в особенности, вообще не пригодны для производительных применений. ? если в отношении NFS в VMware эти заблуждения уже более-менее развеяны многочисленными результатами тестов, как NetApp и EMC, так и самой VMware, да и сотнями и тысячами практических реализаций разного масштаба, то в отношении CIFS по прежнему бытует стойкое убеждение в непригодности его ни для чего, кроме “домашних папок” и копирования файлов по сети.

Отчасти это действительно так. CIFS как протокол сетевой файловой системы, значительно сложнее устроен, чем NFS, обладает множеством хитрых возможностей, и, как следствие, заметно большей величиной “оверхеда”, накладных расходов. Кроме того, CIFS (или SMB 1.0) никогда и не ориентировался на такое применение.

Однако первым шагом в сторону переработки и устранения старых родовых болячек NetBIOS и LAN Manager, от которого ведет свою родословную CIFS, был сделан в SMB v2.0, в котором Microsoft показала, что она знает о проблемах, и приняла решение их устранить. С тех пор CIFS/SMB развивается, не слишком шумно, но довольно существенно, а как видимый результат – появление поддержки новой версии, SMB v2.2 в качестве поддерживаемого протокола доступа к датасторам в новой версии Hyper-V.

Однако, пока Windows 8, Hyper-V 3.0 и SMB 2.2 не вышли в релиз, что же может показать в плане производительности обычный SMB2.0, появившийся в Windows Server 2008, и поддерживаемый в Data ONTAP?

Looking ahead Hyper-V over SMB vs. iSCSI

Posted by lobanov on Sep 29, 2011 10:06:19 AM

В свете грядущих новостей о  поддержке в Hyper-V работы по SMB через версию SMB 2.2, у нас скоро появится новая возможность работать с виртуальными машинами через IP сеть. До сих пор существовала только одна такая возможность, подключая LUN по iSCSI. Очеивдный вопрос, вертящийся у всех на языке, как будут обстоять дела в варианте с SMB с точки зрения эффективности использования системы хранения, управления, и, самое главное, с точки зрения производительности. Для того, чтобы разобраться во всем этом, мы решили провести эксперимент, сравнив эти два варианта подключения, использовав оборудование нашей тестовой лаборатории.

Для теста использовался один сервер в следующей конфигурации:

  • 16 CPU (Dual Socket Quad Core with HyperThreading)
  • 48 GB  RAM
  • Один 1Gbs Ethernet NIC
  • Win2K8R2 SP1

Один контроллер NetApp FAS6030 под Data ONTAP 8.0.1 работает на один сетевой адаптер Ethernet 1Gbs, на контроллере создано два тома flexvol:

  • “HVoverSMB_CIFS” это CIFS share, смонтированная на хост Hyper-V как symbolic link.
  • “HVoverSMB_ISCSI” несет один LUN, подключенный к хосту Hyper-V по протоколу iSCSI.

Оба тома имеют размер 1TB в режиме Thin-Provisioned, и  LUN на томе для iSCSI также сделан Thin-Provisioned. Таким образом, со стороны хоста Hyper-V мы видим 2TB  usable storage, в то время, как на стороне контроллера пространство на дисках почти не занято.  Мы решили не использовать 10G Ethernet, так как хотели замедлить, для наглядности, время загрузки, и максимально нагрузить сеть в процессе эксперимента.

Мы создали 20 VM на iSCSI LUN, и 20 VM на CIFS Share. Каждая виртуальная машина имела следующую конфигурацию:

  • 1 CPU
  • 2 GB RAM
  • Win2K8R2 SP1
  • 40GB VHD

Оригинальный эталонный шаблон VM был создан с использованием нашей новой техники Thick/Thin VHD , о которой я рассказывал ранее,  а последующие копии с этого шаблона созданы с использованием Sub-Lun cloning, и файлового SIS cloning vпри помощи cmdлетов Start-NaClone, и Copy-NaHostFile. ?тоговый результат 40 VM, и 1.6TB дисков виртуальных машин занимают менее 16GB на контроллере!

Затем мы подвергли получившуюся систему испытанием старым добрым Boot Storm – одновременной загрузкой 20 виртуальных машин каждого типа, и сбором данных о производительности как на хосте Hyper-V, так и на контроллере NetApp. Мы собирали данные производительности Hyper-V при помощи Performance Monitor, обращая внимание, в первую очередь, на CPU и призводительность сетевого адаптера. Контроллер NetApp мониторился с помощью Get-NaSysStat PowerShell Script. Оба инструмента был настроены на сбор данных каждые 5 секунд.

Результаты

Время загрузки

В обоих тестах загрузка до экрана Logon заняла менее 90 секунд для всех 20 виртуальных машин.  Давайте посмотрим, что в это время происходило на хостах Hyper-V и контроллере NetApp.

Hyper-V-Host Performance

CPU load

image

 

Network Adapter: BytesReceived/sec

image

 

NetApp Array Performance

Net_Data_Sent

image

CPU_Busy

image

CIFS vs. iSCSI Ops/sec

image

 

Как вы видите, как со стороны хоста Hyper-V, так и со стороны контроллера NetApp, уровни загрузки CPU, а также производительность сети оказались сравнимыми! Важно отметить, что, в данном случае, мы еще даже не используем SMB2.2, так как работает Server 2008 R2 SP1, а не Server.Next. Если же мы видим равную производительность для текущего поколения софта, запущенного на оборудовании четырехлетней давности, то что же мы получим, когда появится Server.Next?

Но где же вообще разница между протоколами, спросите вы, а что там с latency?

Давайте посмотрим, вот картина на стороне NetApp:

image

Неожиданно, не правда-ли?

На первый взгляд, все неплохо, исключая взлет latency до 4ms в самый “разгар шторма”. Но посмотрите на параметр read latency для теста  CIFS. Почему он показывает меньшую latency на идентичной нагрузке? То что мы видим, это преимущества протокола SMB 2.x; Windows использует собственный кэш NTFS для улучшения производительности на чтение, просто посылая на систему хранения меньше избыточных запросов чтения.

 

Величина эффективности использования пространства хранения на NetApp

?спользуя thin-provisioning, single copy rapid provisioning, и дедупликацию, мы получили фантастически высокие результаты для обоих протоколов.

?мя Общий размер ?спользовано Доступно Дедупликация Aggregate
HVoverSMB_CIFS 1024.0 GB 1% 1015.9 GB да aggr0
HVoverSMB_ISCSI 1024.0 GB 1% 1013.7 GB да aggr0

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

 

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

CIFS

За:

  • Одна сетевая папка CIFS на любое число хостов Hyper-V или кластеров Clusters.
  • Перемещение VM между хостами Hyper-V становится гораздо проще, так как все хосты имеют доступ к одним и тем же VHD.
  • Значительно более высокий уровень плотности VM на том.

Против:

  • Конфигурирование прав на CIFS share несколько сложновато, так как требует разобраться со специфическими разрешениями на Share и NTFS, которые требуются для Hyper-V.
  • В настоящий момент не поддерживается.

iSCSI

За:

  • Конфигурирование прав NTFS очевидно.
  • Поддерживается.
  • Равная производительность с FCP без необходимости сложного зонирования.

Против:

  • К LUN-ам не может быть совместного доступа от нескольких хостов и кластеров, без использования WSFC, и CSV.
  • Перемещение VHD на другой хост Hyper-V требует переконфигурирования системы хранения или копирования файлов VHD по сети.

 

Выводы

Результаты теста и их анализ показывают, что сегодня SMB2.0 и iSCSI сравнимы. Оба варианта подключения обеспечивают достаточную эффективность и позволяют работу виртуальных машин по IP-сети. Мы ожидаем, что большинство сложностей с правами и разрешениями будет устранена в Server.Next. Факт неподдерживаемости SMB конечно делает iSCSI однозначным победителем, но, если быть честными, если SMB начнет поддерживаться… следует отдать должное прогрессу в работе SMB. В итоге, мы уже с нетерпением ждем выхода Server.Next, SMB2.2, и Hyper-V 3.0 over SMB, это должно оказаться весьма неплохо!

Слухи и сплетни: FAS2240

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

Не секрет ни для кого, что модели серии 2000 уже явно требуют обновления. Модели 2020 и 2050 были представлены в 2007, модель 2040 – в 2009 году. Однако что же готовится им на смену?

? тут начинается интересное. Во первых, зная номенклатуру и схему именований моделей у NetApp, можно предположить, что новая модель будет называться как-нибудь типа FAS22xx. ? если поискать по интернету строчку FAS2240, например, то можно найти, среди всяких ложных совпадений, например, на сайте какой-то сертификационной компании (?) страничку о прохождении в марте этого года сертификации по электробезопасности некими продуктами NetApp, среди которых устройства с названием FAS2240-2 и FAS2240-4. А также некоторых других любопытных устройств. (сейчас искать бесполезно, сейчас весь топ забит перепечаткой заметки TheRegister с упоминанием этого индекса)

Собственно этим нехитрым приемом довольно давно пользуются всякие техноблоггеры, так, Engadget таким образом получает сведения о новинках всяческих смартфонов, регулярно парся базу FCC – федеральной комиссии по элетросвязи США, сертификат которой необходим для начала продаж радиочастотного устройства в США, а ее федеральный статус требует открытости ее документов, в том числе и описаний заявок на сертификацию от вендоров.

Немного подумав над скудной выдачей, приведенной в упомянутом листочке, настоящий техноразведчик сообразит, что FAS2240-2 и FAS2240-4, упомянутые рядом с дисковыми полками DS2246 и DS4243 соответственно, это контроллер-голова, вставляющийся на место дискового интерфейсного модуля IOM3/6! То есть то, что, много лет назад, NetApp уже делала в моделях FAS250 и FAS270, которые представляли собой специальный контроллер в формате интерфейсного модуля ESH, и который вставлялся непосредственно в дисковую полку DS14, превращая ее в полноценный файлер!

Таким образом, FAS2240-2 это, почти наверняка, полка-файлер высотой 2U, на базе DS2246, а FAS2240-4 – высотой 4U, на базе DS4243.

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

Также любопытны и другие приведенные данные. Например DS4246 говорит нам о том, что будет выпушен IOM6 (интерфейс SAS 6Gb/s) для 4U-полки DS424, сейчас, если у вас используются полки DS4243 (“большая”) и DS2246 (“маленькая”), вам приходится ставить их в разные SAS-“петли”, так как эти два интерфейса пока не совместимы (вернее на порту 6Gb/s не должно быть контроллеров 3Gb/s, иначе скорость будет 3Gb/s).

Напомню, что наименование полки расшифровывается так: DS – Disk Shelf, 4 – 4U, 24 – число дисков, 3 – 3Gb/s SAS interface

Отсюда вы уже сами сможете догадаться что означает запись DS4486, также упомянутая как прошедшая сертификацию в нашем “шпионском листочке” ;о)

Также Theregister в своей заметке упоминает некий DTA2800, a data migration appliance. Не имею представлений что это, увы.

Также неясно, что такое Component File Server, Models FAS250XX, V270XX and FAS270XX.

Так или иначе, но подробности всему (этому, и многому другому), мы узнаем через месяц, на традиционном осеннем NetApp Insight, в Вегасе, начинающегося с 1 ноября.

 

Также, пользуясь случаем, хочу напомнить в последний раз, и пригласить находящихся в Москве завтра на NetApp Innovation 2011, главное публичное мероприятие российского NetApp, о котором я в этом блоге упоминал не раз.

18/0.123

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