about NetApp

Для рассмотрения вопроса, как работает доступ к стораджу по NFS с хоста ESXi, я снова воспользуюсь серией постов блога Wahl Network, переводы которых я публикую сегодня и в ближайшие несколько дней. Его автор провел экспериментальную работу, показав то, как работает NFS в сети хранения, когда датасторы и vmkernel расположены в одной общей подсети, в разных подсетях, и рассмотрел вариант использования Load-based teaming, доступный для пользователей версии vSphere уровня Enterprise Plus.

Я надеюсь, что эти статьи ответят на вопрос, как же все же работает NFS в сети хранения vSphere, и как стораджи с использованием этого протокола правильно использовать для VMware vSphere 5.0.

NFS в vSphere – погружение в детали: часть 1, порты vmkernel и экспорты NFS в единой общей подсети

Apr 23, 2012

Конфигурация

Для эксперимента, показывающего, как vSphere направляет трафик NFS в одной подсети, я создал тестовый стенд, с использованием 2 серверов NFS (я использовал для этого NetApp Simulator) с каждого их которых выведено по 2 экспорта, суммарно 4 экспорта NFS. Весь трафик направлен в VLAN 5 (это подсеть 10.0.5.0/24 моего стенда) и идет на хост ESXi 5.0 update 1 (build 623860). Хост имеет 2 физических порта-аплинка и 4 порта vmkernel, дающих трафику NFS множество возможны путей. Для того, чтобы создать существенный трафик в сети хранения, я развернул 4 VM с VMware IO analyzer appliance – по одному на каждый экспорт. Это позволит мне быстро создать трафик с виртуальных машин на все экспорты разом.

Continue reading ‘VMware и использование NFS: часть 3b – Трафик NFS в одной подсети’ »

Как вы помните, я обещал остановиться на вопросе как именно правильно настраивать работу NFS по нескольким физическим интерфейсам Ethernet. ??так, отдельный разоблачения заблуждений в отношении multipathing для NFS псто!

Как я уже вкратце показал, широкораспространенное заблуждение, что, использовав NFS, вы будете вынужденно ограничены ровно одним интерфейсом ethernet, так как “NFS не поддерживает multipathing” – не верно. К моему глубокому сожалению, это заблуждение местами поддерживает даже сама VMware, несмотря на то, что метод балансировки с помощью нескольких портов VMkernel и нескольких IP-алиасов описан и рекомендуется в их же Best Practices.

Я уже написал ранее, что принципы работы NFS таковы, что даже пустив трафик Ethernet по нескольким объединенным в etherchannel портам, вы не добьетесь не только равномерной их загрузки, но даже не загрузите порты кроме первого. Это по видимому связано с тем, что NFS образует ровно одну TCP/IP сессию для данной пары IP-адресов “источник-приемник”, и именно ее и пускает по первому же подходящему для этого порту. А одну сессию разбить на несколько интерфейсов нельзя. Видимо именно это явилось источником странного заблуждения, что трафик NFS нельзя распределить по нескольким интерфейсам. Это не так, можно. Но нужна некоторая хитрость, в общем-то очевидная. Нужно создать несколько пар IP “источник-получатель”, в разных подсетях, и их уже распределить по интерфейсам.  Об этом подробнее далее в постах серии.

Впрочем, как вы уже видите, неверно и обратное убеждение. Совсем недостаточно объединить несколько портов в etherchannel (у NetApp он называется VIF или ifgrp), чтобы, автоматически, увеличить пропусную способность получившегося интерфейса в Х-раз.

Давайте разберем некоторые распространенные заблуждения на этот счет:

1. Трафик NFS можно назначить на порт VMkernel также, как мы назначаем его для iSCSI.

Это не так. К сожалению.

Как вы видите на рисунке, в обведенном оранжевой рамкой боксе, можно назначить данный порт для: iSCSI, FT, Management или vMotion. Но не для NFS. Трафик NFS пойдет по первому же порту, принадлежащему подсети IP-получателя. Если порта в подсети IP-получателя трафика нет, то трафик пойдет через порт Management, в направлении его default gateway (предсказуемо), и такого варианта следует всеми силами избегать.

2. Трафик NFS равномерно распределяется по всем аплинкам (физическим vmnic) хоста, используемым для связи с системой хранения.

Увы – нет. Когда ESXi нажодит и выбирает подходящий порт vmkernel (принцип выбора описан выше), следуюшим шагом он выбирает аплинк. Независимо от типа vSwitch, хост vSphere использует конфигурацию portgroup по умолчанию (только с использованием virtual port ID), и, при наличии нескольких активных аплинков в группе, будет выбран только один (первый подходящий) аплинк для трафика NFS к данному примонтированному экспорту. Порты в группе при этом работают на поддержку high availability, то есть при выходе из строя активного порта, трафик перейдет на ранее пассивный порт, но не для load balancing, то есть трафик NFS по портам vmnic в группе не распределяется.

3. Достаточно включить несколько физических портов на стороне стораджа в VIF (etherchannel), и трафик магическим образом распределится по всем им, расширяя полосу пропускания интерфейса в Х-раз.

Тоже, к сожалению, в общем случае, без дополнительных усилий, неверно. При наличии одной TCP/IP сессии NFS с одного IP-источника на один IP-получатель, нельзя “разложить” трафик на несколько портов. Но можно это сделать для нескольких портов, нескольких IP-алиасов для получателя и/или  нескольких портов VMkernel. Тогда, создав, например 4 пары IP в разных подсетях, для четырех eth, можно гораздо более равномено загрузить их работой. Это не столь “магически-автоматически”, но это работает. Без такого разбиения и распределения  etherchannel обеспечивает только отказостоустойчивость (при отказе активного порта, трафик перенаправится в другой, ранее неактивный, в той же группе), но не балансировку нагрузки и не расширение bandwidth.

На стороне хоста ESXi для использования балансировки вам необходимо создать static Etherchannel с IPhash-based teaming policy, и иметь у vmkernel IP уникальный, между другими vmk, так называемый least significant bit.

Если у вас на VMware лицензия Enterprise Plus, и вы используете vSphere Distributed Switch, вы также можете воспользоваться Load-based Teaming для распределения трафика по VLAN или подсетям. При этом вам также понадобятся несколько VLAN или подсетей на VIF стораджа. Подробнее о таком варианте – в одном из следующих постов.

Несмотря на то, что основная тема блога – системы хранения, прежде всего системы хранения NetApp, поневоле приходится затрагивать интересные смежные темы. Раз уж мы заговорили тут про NFS, стоит затронуть тему использования LACP при организации EtherChannel, так как, как я заметил, понимание этой темы у многих все еще довольно зыбкое.

Поэтому, в очередных переводах в этом блоге – перевод поста в интересном блоге Wahl Network

Демистификация LACP и Static EtherChannel в vSphere

May 9, 2012

Удивительно часто я слышу о людях, которые воспринимают LACP как некую волшебную палочку, которой достаточно махнуть, и все чудесным образом становится лучше, а трафик волшебным образом распределяется по множеству линков. Я думаю, что это происходит от непонимания базового устройства того, как работает EtherChannel, так как я слышал множество ошибочных утверждений и FUD вокруг этого. Этот пост является попыткой описать то, что же за штука, этот LACP, почему он не работает на обычных, native vSphere switches, и почему он, на деле, имеет совсем небольшое количество преимуществ, в сравнении со static EtherChannel.

??так, что такое LACP?

LACP, иначе известный как IEEE 802.1ax Link Aggregation Control Protocol, это простой способ динамически строить EtherChannel. Для этого "активная" сторона группы LACP посылает специальный фрейм, оповещающий о возможностях и желаемых формах EtherChannel. Возможно существование, и чаще всего так и бывает, когда обе стороны являются "активными" (может быть и пассивная сторона). Также следует отметить, что LACP поддерживает только full duplex линки (в настоящий момент, в мире гигабитных, и более, линков, которые всегда full duplex, это уже не является значимым ограничением). Как только обмен фреймам произведен, и порты на обоих сторонах согласовали поддержку требований, LACP создает EtherChannel.

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

LACP отсутствует в Native vSphere Switches

Ситуация проста, нативные коммутаторы vSphere не отвечают на фреймы LACP. Они не слушают и не передают соответствующие кадры. Если вы настроили LACP на внешнем коммутаторе, он не получит отклика на запросы LACP от хоста vSphere, и, следовательно, EtherChannel не будет создан.

Если вы хотите создать EtherChannel с участием хоста vSphere, вы должны создать Static EtherChannel. Когда порт установлен в Static, он не участвует в процессах объявления или распознавания LACP – канал EtherChannel немедленно создается физическим коммутатором.

Как работает распределение нагрузки (Load Distribution)?

Главная мысль:
Как Static так и Dynamic (LACP) EtherChannel используют одни и те же методы распределения нагрузки (load distribution).

Я специально выделил это курсивом и жирным шрифтом. Да, это правда. ?? Static, и LACP используют одни и те же техники балансировки нагрузки для распределения трафика по линкам. Если кто-то утверждает иное, то можете поспорить с ним на деньги, можете хорошо выиграть.

Но Static EtherChannel требует IP Hash, а LACP - нет, не так ли?

А сейчас переходим в темную часть. Ответ на заданный в заголовке вопрос: "Это не так", но вот почему это не так?

IP Hash это требование native vSphere switch. Он не поддерживает никакие другие методы load distribution.

Скриншот выше взять из vSphere Networking guide

А это уведомление из vSphere:

Отметьте, что если я хочу использовать EtherChannel, я выбираю IP Hash в качестве метода балансировки, и появляется данный бокс с сообщением.

Внимание: Термин IP Hash эквивалентен политике load distribution policy вида src-dst-ip на коммутаторе Cisco.

Static EtherChannel в других случаях может использовать любые из доступных политик распределения нагрузки. Но когда порты работают с хостом vSphere, мы вынуждены использовать только IP Hash, так как vSphere ничего другого не умеет.

Если вы хотите использовать LACP с vSphere, вам потребуется установить виртуальный коммутатор Cisco Nexus 1000V (или IBM 5000v). Нет других способов задействовать LACP с vSphere на момент написания этого поста. ??, так как 1000V это (почти) полнофункциональный коммутатор Cisco, в отличие от native vSphere switch, вы можете использовать любые политики load distribution – вы не ограничены только IP Hash (src-dst-ip)

Преимущества LACP перед Static

LACP имеет несколько "карт в рукаве", но это не относится к методам распределения трафика по каналам EtherСhannel.

Hot-Standby Ports

Если вы добавите больше поддерживаемого числа портов в LACP port channel, есть возможность использовать лишние порты в качестве портов hot-standby mode. Если произойдет отказ активного порта, порт hot-standby автоматически заменит его.

Однако, типичное число поддержваемых портов в LACP равно 8, так что для системы vSphere это не та возможность, о коорой стоит беспокоиться. Сомнительно, что у вас сделан 8-канальный EtherChannels к одному хосту vSphere.

Failover

Если у вас имеется dumb-устройство между двумя концами EtherChannel, например media converter, и один из линков, идущих через него отказывает, LACP это понимает и перестает слать трафик в отказавший линк. Static EtherChannel не мониторит состояние линков. Это не типичная ситуация для большинства систем vSphere, которые мне встречались, но в ряде случаев это может оказаться полезным.

Проверка конфигурации

EtherChannel с использованием LACP не активируется, если есть какие-то проблемы с конфигурацией. Это помогает убедиться, что все настроено нормально. Static EtherСhannel не делает каких-либо проверок перед своим задействованием, то есть вам нужно заранее быть уверенными, что все сделано правильно.

Выводы

Я не хочу сказать, что LACP (или Nexus 1000V) это плохо. LACP - это очень полезный и популярный протокол, активно используемый. Проблема, побудившая меня написать этот пост в том, что я вижу людей, которые считают что с использованием LACP они получат лучшую балансировку трафика, или же что-то еще, что он совершенно точно не делает. Так что не спешите закупать Cisco 1000V для вашей системы vSphere только оттого, что вы хотите использовать LACP, пока вы не будете иметь ясного плана того, что, на самом деле, вы хотите получить в результате.

??сточник:
http://wahlnetwork.com/2012/05/09/demystifying-lacp-vs-static-etherchannel-for-vsphere/

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

??так, перейдем к некоторым конкретным вопросам, на которые приодится отвечать, выбирая NFS в качестве протокола доступа к датастору в VMware. Впервые такой вариант появился еще в VMware ESX 3.0, и постепенно зарабатывает все большую популярность, потесняя “классический” блочный способ подключения по FCP или iSCSI. О преимуществах, и некоторых недостатках я писал в первой части данной серии.

Какие же основные проблемы принято называть, когда речь идет о испоьзовании NFS для VMware?

1. На NFS нет multipathing.

“?? значит, выбирая NFS, я ограничен производительностью только одного интерфейса Ethernet” добавляется явно или подразумеваемо. Ну, на самом деле это “и так и не так”. Пока оставим “за скобками” практическую надобность расширения канала к дискам даже для Gigabit Ethernet NFS или iSCSI (во многих системах это расширение bandwidth имеет довольно спорную практическую ценность). На NFS действительно нет multipath в том виде, в котором он понимается в блочных протоколах, потому что multipathing (MPIO, Multipathed Input Output) – это фича исключительно блочных протоколов. А так как NFS это не блочный протокол, то фичи блочных протоколов в нем быть не может “по определению”. Это так. Однако, NFS, как протокол поверх TCP/IP, конечно же имеет возможности реализации отказоустойчивости, путем использования множественных путей (как его имеет сам нижележащий TCP/IP), а также использования нескольких параллельных каналов доступа к данным, для расширения bandwidth.

Но тут есть некотрая тонкость. Проблема связана с тем, что NFS, для связи с данным датастором, с данным IP, и всеми его файлами, использует только одну TCP-сессию. А одну сессию, имеющую один IP-source и один IP-destination никак нельзя забалансировать по нескольким физическим портам Ethernet, даже с использованием etherchannel, формально работающем уровнем ниже.

Но можно (и нужно) выйти из положения хитрым трюком. Дело в том, что можно создать для destination несколько так называемых IP-алиасов, а также несколько портов VMkernel в качестве IP-source. Датастор, тем самым может быть доступен по нескольким равноправным IP-адресам. Если мы подключим датастор таким образом, у нас уже могут быть несколько различных IP-destination, через разные IP-source в VMkernel и, значит, заработает балансировка по IP-хэшу. Такой трафик, вышедший из нескольких IP-source в своих подсетях, и пришедший на сторадж в разные IP-алиасы, можно распределить по нескольким физическим eth-интерфейсам. Просто это присходит не “мистически-автоматически”, как в случае iSCSI MPIO, а путем ручной настройки этой балансировки, и дальнейшей ее самостоятельной работы.

Подробнее о этом методе рассказывается в TR-3802 Ethernet для систем хранения: Наилучшие методы (глава 4.6 IP-алиасы), и в TR-3749 Руководство по наилучшим способам использования систем NetApp с VMware vSphere (глава 3.3 Основы сети хранения с использованием Ethernet, глава 3.6 Сеть хранения с использованием Multiswitch Link Aggregation).

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

UPD: Если вы счастливый обладатель VMware в лицензии Enterprise Plus, то тогда вам доступен еше один вариант загрузки нескольких NFS-линков к стораджу - это режим Load-based Teaming для интерфейсов vnic. Об этом способе мы также поговорим чуть позднее в отдельном посте.

2. NFS нестабилен в работе и имеет проблемы с призводительностью.

“Мы видели это своими глазами, собрав сервер NFS на Linux” – добавляется явно или подразумеваемо. ?? это снова “и так, и не так”. Да, действительно, реализация NFS на Linux давно страдает серьезными проблемами, ее обычно приходится в продакшне твикать и патчить, только чтобы поправить некоторые наиболее вопиющие проблемы. В vanilla code она в продакшн малопригодна. Но это не значит, что любой NFS server также непригоден, только потому что он – NFS! Реализация NFS от NetApp зарекомендовала себя во множестве систем крайне высокого класса, ей по плечу задачи от небольших систем, до масштабов Yahoo!, Oracle, Siemens и Deutsche Telecom. NetApp имеет опыт разработки и эксплуатации NFS-серверов уже около 20 лет, в самых жестких условиях и требованиях по производительности и надежности.

??так: Не все реализации NFS “одинаково полезны”. ?? реализацией NFS в Linux многообразие их не исчерпывается. Не нужно интерполировать на NetApp неудачные реализации одной отдельно взятой подсистемы, в одной конкретной OS (или группе OS, использующих общих прародителей данного кода).

В следующей части я попробую более подробно остановится на методах multipathing для NFS, о которых выше в посте я вкратце уже упомянул.

В следующий четверг, в Москве, в Holiday Inn Лесная (ст.м. Белорусская) состоится технический семинар по программе TechTalk Live. Если вы еще не посещали ни один из таких семинаров NetApp, то расскажу, что это преимущественно “технический”, инженерский семинар, с минимумом “конвергенций и синергий”, и с максимумом практических тем, касающихся реальной жизни и заботящих практических специалистов реальных систем.

Объявлена следующая программа:

Как видите из программы, текушая тема – NAS-аспект систем хранения NetApp, аспект, который пока, по моему наблюдению, незаслуженно и неоправданно в России находится “в загоне”. ??спользование высокопроизводительных файловых, NAS-систем хранения – большой и хорошо растущий сегмент в мире, много лет как себя хорошо зарекомендовавший, в России все еще имеет репутацию “чего-то несерьезного”. Ну, NAS, это же всякие QNAP и Synology, да? ??спользовать Oracle 11g RAC на NAS? Вы должно быть шутите?  То ли дело файбер ченэл, вот это – сила! ;)

Надеюсь, пришедшие на семинар получат представление о существующем потенциале NAS-компоненты unified-систем NetApp FAS, и, возможно, пересмотрят свое мнение о нем. А те, кто уже знают, как использовать NFS для Oracle или VMware, или для HPC-систем, возможно получат ответы на свои вопросы “из первых уст”,  узнают о перспективах, например о развитии в направлении Cluster-mode.

Предварительная регистрация делается тут: Регистрация на TechTalk Live

Официальная страничка с программой: Программа TechTalk Live 24 мая, 2012 г. Москва.  

Ну, так как до выхода 8.1.1 уже совсем немного времени, давайте я уже расскажу вам, что же такое Flash Pool, который появится у NetApp начиная с этой версии.

Я ранее уже несколько раз упоминал о новой идее NetApp – включении нескольких SSD непосредственно в дисковый aggregate системы хранения, и использования их под кэш “уровня aggregate”, в том числе и для записи. Эта конструкция дополняет возможности Flash Cache, может работать как с ним вместе, так и сама по себе, причем, отметьте, также и для систем, на которых Flash Cache, по тем или иным причинам, использовать уже нельзя, например FAS3210, 3140, и даже 2240.

К моменту выпуска, реализация Hybrid Aggregate в системах NetApp получила собственное, коммерческое имя-торговую марку Flash Pool, и далее я буду пользоваться именно им. Вы же знайте, что Flash Pool это название реализации NetApp Hybrid Aggregate в Data ONTAP 8.1.1 и новее.

К сожалению, вокруг Hybrid Aggregate/Flash Pool уже начало образовываться облако недопониманий и мифов, а моя задача в очередной раз внести ясность в тему.

??так, начнем.

Прежде всего, я бы хотел сказать, что, вопреки домыслам, Flash Pool это НЕ tiering, в классическом его понимании (например в том виде, в каком он представлен в EMC FAST), это кэш. Этот момент понятен? НЕ disk tiering, not, nicht, nie. :) Это КЭШ.

Появление Flash Pool также не означает отказа от Flash Cache. Это независимое, но дополняющее решение. Он может работать с Flash Cache, может работать сам по себе. В случае работы с Flash Cache, кэширование не дублируется. Тома, работающие с Flash Pool (находящиеся в аггрегейте с SSD) не кэшируются в Flash Cache. Помните, что Flash Cache может работать со всеми aggregates и volumes системы в целом, а кэширование Flash Pool распространяется только на тома одного aggregate. Если у вас несколько aggregates, вам понадобится добавлять SSD для создания Flash Pool в каждый aggregate, который вы хотите кэшировать в Flash.

В гибридный aggregate, то есть Flash Pool вы можете преобразовать любой 64-bit aggregate, добавив в него несколько SSD NetApp, объединенных в RAID-группу, и указав для aggregate соответстующую опцию, также его можно создать “с нуля” обычным способом, как любой aggregate. Но в создании Flash Pool есть несколько тонких моментов, именно на них я хочу остановится подробнее.

Так как Flash Pool это кэш, то есть SSD, как таковые, не доступны для непосредственного хранения на них каких-то конкретных данных, а лишь кэшируют поступаюшие на и считываемые с томов aggregate данные, добавление в aggregate SSD не увеличивает его емкость. Есть и “побочный эффект” – если вы имеете aggregate, достигший максимального возможного для данного типа контроллеров размера, например 50TB для FAS3210, то вы все равно можете добавить в этот 50TB-аггрегейт диски SSD для Flash Pool.

Тип RAID-группы для дисков, добавляемых в aggregate должен быть одинаков для всего aggregate. Если вы используете RAID-DP, то добавляемые SSD тоже должны быть в RAID-DP. Нельзя в aggregate из HDD в RAID-DP добавить SSD в RAID-4, например.

Обратите внимание, что возможность добавления в aggregate дисков SSD НЕ означает возможности добавления в aggregate дисков HDD другого типа. Flash Pool може быть (по вашему выбору) из SAS/FC и SSD, или из SATA и SSD, но НЕ из SAS и SATA.

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

Наверняка у многих уже вертится на языке вопрос: “Как же нам воспользоваться Flash Pool, если NetApp продает SSD только в составе полки на 24 диска?” Отвечаем: С появлением Flash Pool SSD NetApp будут продаваться паками по 4 штуки, что дает вам во Flash Pool 142GB кэша из 4 SSD. Диски имеют размер 100GB [84574 MiB], и когда они включаются в aggregate, построенный на RAID-DP, вы получите из 4 дисков два диска parity и два – data. Конечно, вы можее включить в Flash Pool и больше SSD.

Однако помните, что SSD имеют интерфейс SATA. Это значит, что вы НЕ МОЖЕТЕ добавить SSD непосредственно в полку с дисками SAS. Но можете – в полку с дисками SATA. Смешивать физические интерфейсы дисков в составе одной полки нельзя. Таким образом, если у вас система с “только-SAS/FC”, вам понадобится для установки SSD, даже всего 4 штук, например, дополнительная полка “только-SATA”. Не забывайте об этой сложности.

Вопрос, который я уже тоже слышу :) “Вы говорите – SSD работает на запись? А как же с исчерпанием ресурса на перезапись для SSD?”

Ну, это тема. Да, безусловно, с этой точки зрения Flash Cache был принципиально более надежен, так как работал только на чтение, а записи (заполнение кэша) в него делались сравнительно (по меркам компьютера) редко, и большими “порциями”, которые flash memory как раз обрабатывает довольно хорошо, это не random write мелкими блоками. Однако практика использования SSD enterprise-class показывает, что проблема пресловутого “исчерпания ресурсов SSD при записи” в значительной мере надумана, преувеличена, и присуща, в основном, “бытовым” SSD. Тем не менее, эта проблема возможна, так как Flash Pool действительно пишется, работая на запись (хотя, вы не забыли, записи в WAFL не рандомны, а секвентальны). Для защиты данных в случае выхода SSD из строя вы как раз и используете объединение SSD в RAID, а сами SSD, как устройства, покрыты общей трехлетней warranty на систему.

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

Отвечая на третий вопрос ;) : Да, TRIM для SSD поддерживается Data ONTAP на уровне системы.

Напомню, Flash Pool, новое название Hybrid Aggregate, появится в Data ONTAP 8.1.1, которая ожидается к выпуску в ближайшем месяце.

А помните ли вы, что NetApp это не только производитель хороших стораджей, но и пять шесть килограммов но и крупный разработчик в области SRM (Storage Resource Management) и SAN Management, причем вовсе не обязательно используя только свои стораджи, а, в том числе, и для всей разнородной IT-инфраструктуры вашей компании в целом?

Недавняя моя заметка о выходе Data ONTAP 8.1 и некоторых особенностях новой версии, вызвала довольно широкий отклик, поэтому, для уменьшения количества панических слухов, я решил написать это дополнение и разъяснение.

Проблема, как вы уже знаете, в том, что, согласно Release Notes, в новой версии Data ONTAP, не поддерживается устройство Flash Cache на младших моделях линейки midrange, то есть на 3140, и даже на сравнительно недавно вышедшей 3210, несмотря на то, что Flash Cache можно физически в эти системы поставить, и ранее такая конфигурация поддерживалась.

По этому поводу ТАСС уполномочен сообщить мой источник в NetApp сообщает:

1. Да, действительно, это так. Поддержка Flash Cache для 3210/3140 сохраняется для ранее выпущенных версий Data ONTAP, то есть для линейки 7.3.х, и для v8 вплоть до версии 8.0.3 (и далее, если линейка 8.0.х будет продолжена).
2. Ситуация связана с некими сложностями на системном уровне. Дабы не задерживать выпуск 8.1, было решено подготовить фиксы для этой проблемы к следующей версии, 8.1.1, которая запланирована к выпуску в начале лета.
3. В версии 8.1.1 вновь ожидается поддержка Flash Cache для 3210 в объеме 256GB на контроллер (полный объем одной платы на 256GB), и для 3140 – в половинном объеме от объема установленной платы 256GB (доступный объем для Flash Cache 256GB для 3140 будет виден размером 128GB).
4. Flash Cache для FAS/V3210 или FAS/V3140 более недоступен к заказу, соответствующая конфигурация недоступна в конфигураторе с декабря 2011 года, вне зависимости от версии OS.
5. Установка Flash Cache на купленные после этой даты FAS/V3210 или FAS/V3140 не разрешена и не поддерживается, вне зависимости от использованной версии DOT.
6. Версия 8.2, и далее, также не будет поддерживать Flash Cache на системах FAS/V3210 и FAS/V3140.

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

UPD: Я говорю тут ТОЛЬКО о поддержке Flash Cache на 3210 и 3140, на всех остальных системах 3200/6200, а также 3100, Flash Cache по прежнему ПОДДЕРЖ??ВАЕТСЯ и работает как и раньше.

В качестве варианта замены стоит обдумать вариант с Hybrid Aggregate (использование SSD в составе обычного aggregate из HDD), который появится начиная с 8.1.1, и о котором подробнее позже.

Как вы знаете, я убежденный сторонник того, что системы хранения NetApp – это лучший выбор для использования в среде серверной и десктопной вируализации. А для самой этой виртуализации – использование протокола NFS, который для систем NetApp, более чем родной, в свою очередь, лучший способ подключить дисковое хранилище. Со мной согласны уже 36% пользователей систем виртуализации (согласно отчету Forrester за май прошлого года), причем процент использования NFS растет, и уже превысил процент использования iSCSI (23%) на этих задачах.

Я уже не раз писал в этом блоге про различные аспекты использования NFS (посмотрите старые статьи по тегу NFS), и даже переводил на этут тему Best Practices (про Ethernet Storage вообще и про VMware в частности), однако все это были разрозненные публикации “к случаю”. Мне захотелось собрать основные темы вопроса в одном месте, и обсудить их, наконец, “раз и навсегда”, или пока тема не изменилась значительно.

Но для начала несколько вводных слов, для тех, только что подключился к блогу.

NFS (Network File System) – это протокол “сетевой файловой системы” разработанной компанией Sun в глубокой исторически-компьютерной древности, и предназначенный для доступа к данным в файлах по сети, в том числе для совместного доступа к ним от нескольких клиентов. NFS, вследствие своей сравнительной простоты реализации, стал очень популярным в UNIX-мире, где работу по NFS поддерживают практически любые OS. Несмотря на то, что сегодня “файловой системой” обычно принято называть нечто иное, за протоколом доступа к файлам по сети, NFS, исторически закрепилось название “файловая система”.  С момента своего изобретения, NFS прошел большой путь, и на сегодня достиг версии 4.2, обретя множество важных на сегодня возможностей, таких как использование не только UDP, как первоначально в исходной версии протокола, но и TCP (в v3), улучшенные технологии разграничения доступа и безопасности (v4), поддержка распределенных кластерных и объектных хранилищ (v4.1) и различные методы offload-а (v4.2).

К сожалению, за NFS водится два своеобразных недостатка. Во-первых, он так и не появился в OS семейства Windows (если не считать крайне проблемной реализации, вышедшей в составе продуктов MS Services for UNIX) и остался “чужим и непонятным” для win-админов. ?? второе, но более важное, не все его реализации “одинаково полезны”. Многие пользователи, познакомившиеся с NFS через имеющую кучу проблем с производительностью и стабильностью, широкораспространенной реализацией в Vanilla Linux, считают, что “весь NFS такой, глючный, тормозной, для продакшна не пригодный”. А это не так.

В третьих, наконец, вокруг NFS, и особенностей его работы, циркулирует множество различных недопониманий, вдобавок помноженных на специфики реализаций и долгий исторический путь от версии к версии. Вот разбором этих недопониманий мы и займемся для начала. Напомню, я не стану обнимать необъятное, и сосредоточусь только лишь на использовании NFS в VMware.

А теперь о достоинствах. Во-первых следует отметить сравнительную простоту использования NFS. Его использование не требует внедрения и освоения сложной, особенно для новичка, FC-инфраструктуры, непростых процессов настроек зонинга, или разбирательства с iSCSI. ??спользовать NFS для доступа к датастору также просто и тем, что гранулярность хранения при этом равна файлу VMDK, а не целиком датастору, как в случае блочных протоколов. Датастор NFS это обычная монтируемая на хост сетевая “шара” с файлами дисков виртуальных машин и их конфигами. Это, в свою очередь, облегчает, например, резервное копирование и восстановление, так как единицей копирования и восстановления является простой файл, отдельный виртуальный диск отдельной виртуальной машины. Нельзя сбрасывать со счетов и то, что при использовании NFS вы “автоматически” получаете thin provisioning, а дедупликация высвобождает вам пространство непосредственно на уровень датастора, оно становится доступно непосредственно администратору и пользователям VM, а не на уровень стораджа, как в случае использования LUN-а. Это все также выглядит крайне привлекательно с точки зрения использования виртуальной инфраструктуры.

Наконец, используя датастор по NFS, вы не ограничены лимитом в 2TB, даже с VMFS ранее 5, а это очень полезно, например, если вам приходится администрировать большое количество сравнительно слабонагруженных вводом-выводом машин. ??х всех можно поместить на один большой датастор, бэкапить, и управлять которым гораздо проще, чем десятком разрозненных VMFS LUN-ов по 2TB(-512bytes) каждый.

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

Однако, какие у нас имеются минусы?

Ну, во-первых, это невозможность использовать RDM (Raw-device mapping), который может понадобиться, например, для реализации кластера MS Cluster Service, если вы его хотите использовать. С NFS нельзя загрузиться (по крайней мере простым и обычным способом, типа boot-from-SAN). ??спользование NFS сопряжено с некоторым увеличением нагрузки на сторадж, так как ряд операций, которые, в случае блочного SAN, реализуются на стороне хоста, в случае NFS поддерживатся стораджем. Это всяческие блокировки, разграничение доступа, и так далее. Однако, практика показывает, что оверхед отражается на производительности крайне незначительно.

Большим плюсом использования NFS на стораджах NetApp является то, что выбор NFS там не диктует вам “жесткого выбора” для вашей инфраструктуры в целом. Если вам понадобится также и блочный протокол для RDM, или для крайне критичной даже к возможному 10-15% падению производительности виртуальной машины, вы можете использовать для нее iSCSI или даже FCP, все на том же сторадже, параллельно с NFS, и всеми его плюсами, для основного датастора.

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

Рекомендуется также почитать по теме:

• VMware: Best Practices for running VMware vSphere on Network Attached Storage
• NetApp (RU): Руководство по наилучшим способам использования систем NetApp
  с VMware vSphere
• NetApp (RU): ??спользование NFS в VMware
• NetApp (RU): Ethernet для систем хранения: наилучшие методы
• NetApp (EN): tr-3880 CLI Configuration Processes for NetApp and VMware vSphere.pdf
• NetApp (EN): tr-3697 Multiprotocol Performance Test of VMware ESX 3.5 on NetApp
• NetApp (EN): tr-3808 VMware vSphere 4.1 and ESX 3.5 Multiprotocol Performance Comparison Using FC iSCSI and NFS

??так, 19 апреля наконец случилось долгожданное событие, дооооолгий путь версии 8.1 к пользователю, через казавшиеся бесчисленными Relelease Candidates (RC), завершился, наконец, выходом General Availability Release.

Напомню, это та самая версия, в которой, наконец-то, появился 4-нодовый Cluster-mode для блочных протоколов FC/iSCSI/FCoE. Плюс ряд новых возможностей.

К сожалению, не обошлось и без ряда неприятных потерь, о которых я хочу упомянуть отдельно (потому что про победы вы прочитаете в пресс-релизах, а о факапах придется читать мелким шрифтом, где нибудь в Release Notes).

Во-первых, и об этом я хочу сказать с недоумением и негодованием, не думайте, что фоннатство в отношении NetApp мне напрочь глаза застило, это то, что теперь более не поддерживается Flash Cache на младших моделях линейки 3100/3200, то есть для 3140 и 3210.

А вот так. Физически поставить можно, а в 8.1 не поддерживается. То есть человек покупает 3210, с Flash Cache и 8.0.2,  в котором она поддерживается. Платит за пару Flash Cache 40 тысяч баксов. Платит за Software Subscription сколько-то тысяч, расчитывая получить поддержку и новые версии. Спустя три месяца выходит новая версия, и человек внезапно осознает, что его система более не поддерживается. А вот так вот. Либо новая версия Data ONTAP, и девайс на 40 штук баксов в ведро, либо оставить Flash Cache и тогда стоимость Software Subscription в ведро, и новых версий Data ONTAP для вас нет.

Причины не ясны. То есть варианта два. Либо это сознательное решение, вызванное маркетинговой попыткой “сегментировать”, и повысить привлекательность 3240 для тех, кто при прочих равных выбрал бы систему подешевле. Либо это конструктивный просчет на этапе создания линейки (есть и такое мнение, что на что-то в новой версии перестало хватать памяти). Причем я даже искренне не знаю, что из этих двух причин хуже, то что впервые на моей памяти инженера NetApp так пролетают с расчетом, или что компания так жостко кинула своих клиентов 3210/3140 с Flash Cache и SSP, по схеме, описанной выше.

Напомню, что 3210 с Flash Cache это официальная, опубликованная и валидированная конфигурация FlexPod, как она опубликована, например, в Cisco Validated Design.

UPD: Как совершенно справедливо заметили мои читатели в комментах, читающие внимательно Release Notes (в отличие от меня, позор), на самом деле там написано:
Attention: If you have a 3210 or 3140 storage system with Flash Cache modules installed, do not upgrade your system to Data ONTAP 8.1 7-Mode. Flash Cache modules are not supported in 3210 or 3140 storage systems with Data ONTAP 8.1.
The issue is under investigation and a long-term strategy will be communicated as soon as possible.

Что-ж, будем надеяться на лучшее. Видимо и вправду косяк вылез неожиданно, а так как 8.1 давно уже отстала от графика выпуска, было, по-видимому, решено выпускать как есть, а не откладывать еще раз, а такую неприятную особенность править в последующих Patch Releases.

.

.

Остальное это уже мелочи, на мой взгляд.

Окончательно исчезла поддержка полочных интерфейсных модулей ESH2 (DS14mk2), то есть 2Gb/s FC к полкам. Это, что называется, “туда и дорога”, тем более, что системы с ESH2 не продаются уже лет пять минимум, и в живой системе они могут появиться только как глубокое legacy.

Больше нет FilerView (веб-интерфейса, открывающегося по адресу http://filer/na_admin). Ну я понимаю, что он в своем нынешнем виде уже был позорно анахроничен внешне, и непригоден для Cluster-mode (хотя, наверное, можно было и обновить, и что-нибудь придумать). Но кому он мешал в качестве стандартного инструмента, по-прежнему годного для администрирования 7-mode? Ну то есть я понимаю, у нас теперь всюду Cluster-mode “шагает впереди”, но тем не менее, будем смотреть правде в глаза, в ближайшие пару лет 7-mode все еще будет занимать подавляющее число инсталляций.

Так что теперь у нас для администрирования осталась лишь командная строка и творение развеселого бангалорского гения – System Manager 2.0, который… ну-у… неоднозначный продукт, скажем обтекаемо.

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