about NetApp

Для начала несколько слов о том, что такое собственно этот VASA Provider.

VASA – это новая придумка VMware для больших сред виртуализации. Когда у вас всего один-два стораджа и всего несколько датасторов, то вам это не надо. Вы и так помните что у вас где. А вот когда систем хранения у вас будет с десяток, и несколько сотен датасторов,  несколько человек админов в три смены, вот тогда вам захочется как-то разбираться, что у вас где, и, по-возможности, быстро.

Continue reading ‘Установка NetApp VASA Provider’ »

Arista Networks 7050Q-16 | 16-port 40 GbE switch

Arista 7050 Series Advantages

Scalability

• Supports dense virtualization, big data and storage in a flat 2-tier Leaf/Spine design
  • 128K MAC entries
  • 50,000 IGMP groups
  • 16K IPv4 Routes
  • 16K IPv4 Host Routes
  • 8K IPv6 Routes
  • 8K Multicast Groups
  • 32-way ECMP

UPD: Как заметили в комментариях - есть аналогичный от IBM, уже, в отличие от Arista, доступный в России: IBM System Networking RackSwitch G8316 http://www.redbooks.ibm.com/abstracts/tips0842.html?Open
35 тысяч без кабелей

В марте 2012 года, по всей видимости, пройдет окончательную ратификацию “в органах” новая версия протокола NFS – NFSv4.2.

Я уже рассказывал о том, как пару лет назад была выпущена v4.1, главным нововведением которой стал протокол pNFS или Parallel NFS (вопреки модным тенденциям сегодняшнего IT, даже такие значительные изменения, как pNFS, не удостоились v5.0, а считаются всего лишь минорными изменениями версии 4). Про pNFS я тоже уже писал немного, если кому интересно – отсылаю к прошлым постам, если вкратце, то это модификация файловой системы NFS, позволяющей ей работать на параллельном кластере связанных хранилищ, подобно Lustre, Hadoop или GPFS. А сегодня мы собрались для того, чтобы посмотреть на то, что появилось в v4.2. Добавления не настолько глобальные, как в 4.1, но достаточно интересные.

Server-Side Copy (SSC) – это механизм, который позволяет организовывать копирование данных между двумя серверами, не через инициировавшего копирование клиента (чтение на клиента блока с сервера A – запись этого блока на сервер Б, и так далее, пока весь файл не скопирован), а непосредственно. Это чем-то напоминает возможно знакомое кому-нибудь копирование FXP, для двух поддерживающих эту функцию серверов FTP, когда клиент, по командному каналу, указывает для двух серверов, что они должны передать друг-другу файл, после ченго может отключиться, коммуницировать и передавать файл будут два сервера без участия инициировавшего клиента.

Такая возможность значительно снижает нагрузку на канал к клиенту для объемных копирований, например для операций, подобных Storage vMotion, когда содержимое одной VM c одного стораджа, должно быть перенесено на другой сторадж. Теперь это смогут сделать два стораджа, поддерживающие NFS v4.2, самостоятельно, без участия клиента, средствами самого протокола NFS.

Guaranteed Space Reservation – несмотря на то, что thin provisioning для больших инфраструктур это благо с точки зрения эффективности расходования пространства, это большая забота администраторов, в особенности для быстро и непредсказуемо растущих сред. Хотя Thin Provisioning и дает большой выигрыш в расходовании места, за ним “нужен глаз да глаз”. К сожалению до сих пор NFS не предлагал возможности зарезервировать пространство для файлов. Размещение файлов на NFS всегда было thin. Если вы по каким-то своим причинам не хотели использовать thin-модель, то есть занятие места по фактически записанному в файл, а хотели заранее зарезервировать пространство на NFS-хранилище, то у вас не было выбора, а теперь он есть. Guaranteed Space Reservation позволяет, в рамках протокола и файловой системы NFS, создать зарезервированный объем файла, даже не осуществляя в него фактической записи.

Hole-punching. Как вы знаете, одной из наиболее значительных проблем thin provisioning, является проблема “разрастания” thin-файла или раздела (например файла диска виртуальной машины), внутри которого удаляются данные. К сожалению, не имея “арбитра” на уровне приложения, OS, или файловой системы, сторадж не может узнать, вот эти вот блоки, они стерты и больше не нужны, или просто в них давн не пишется, а на самом деле данные в них ценные и их освобождать нельзя. Отчасти эту проблему можно решить, принудительно записывая нули (что, кстати, нынешние файловые системы не делают сами, просто помечая файл у себя как “удаленный”), и считать, что то, где принудительно записаны нули – стерто, и ег можно освободить, и не держать внутри thin-тома, а отдать такое “зануленное” место желающим. Однако общего, стандартного механизма пока не было. А теперь он есть. Начиная с v4.2 при работе по NFS можно обнаруживать такие разрозненные пустые пространства от стертых данных, и освобождать его, “сжимая” файл.

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

Application Data Blocks (ADB) – это механизм для приложений определить некие блоки данных, чтобы затем можно будет заполнять “по шаблону”. Например приложение желает заполнить выделенную область данных определенной сигнатурой. “Классическим образом” вам пришлось бы передать по сети и записать на диск ровно столько блоков, сколько нужно для заполнения нужных областей. Теперь же приложение может определить блок данных как Application Data Block, и заполнить область (с точки зрения приложения) просто указав на этот блок как предопределенный ADB для этой области. Физическое заполнение при этом не происходит, но приложение, обратившись к области данных, получит именно ожидавшееся содержимое.

Aplication I/O Hints – это указание приложением стораджу, средствами протокола, на характер считывания данных с диска. Например: следующие данные будут читаться последовательно, поэтому, пожалуйста, включите на сторадже read ahed. Или, наприме: следующие данные мы будем читать несколько раз подряд. Поэтому включите их постоянное хранение в кэше. Или данные будут записаны, но читать пока мы их не планируем, поэтому не занимайте место в кэше под них. И так далее.

Когда все это богатство ждать? Ратификация стандарта ожидается уже в марте, так как одним из “двигателей” рабочей группы NFS являются специалисты NetApp и EMC, то в этих продуктах новые возможности будут реализованы в скором времени после ратификации стандарта. Насколько будут востребованы новые фичи на стороне клиента – ну тут решать стороне клиента, то есть, в конечном счете – вам.

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

Так, например, как-то я там обнаруживал NetApp System Analyzer for CIFS, а также архиполезный набор утилит na_stats. А на днях автор блога Geek ONTAP показал еще одну интересную утилитку – NetApp Storage Security Editor.

Если вы используете системы NetApp как CIFS-сервер, и вынуждены часто строить сложные ACL для разграничения доступа, то вам должно быть такое интересно. Этот инструмент позволяет создавать описания настроек доступа для ресурса на языке SDDL.

SDDL – Security Descriptor Definition Language – язык описания дескрипторов доступа, позволяющий создавать строки, описывающие права доступа на ресурсы. Язык этот лишь слегка проще конфигурационного файла sendmail, поэтому наличие хорошего инструмента, позволяющего на нем писать совершенно необходимо.

Записанную в файл строку на SDDL можно импортировать в NetApp с помошью консольной команды fsecurity apply.

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

К сожалению утилита находится в крайне ранней стадии развития, поддерживает пока только NTFS-security, а в нем storage-level и file/directory-level security, также не поддерживаются не-ASCII символы во вводе.

Подробнее смотрите на странице инструмента (нужен логин в NetApp Support (NOW)).

А тем временем, в выходные, выкатилась, наконец, Phase 2 обновления самого важного для пользователя сайта NetApp – NetApp Support Site (http://support.netapp.com/), бывшего “NetApp on Web”, NOW (http://now.netapp.com/).

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

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

По работе с новым порталом выпущен специальный 111-страничнй документ, в котором многое расписано подробно и детально. Но начать использовать его можно и “методом тыка”. Попробуйте, нам теперь с этим жить.

Я уже рассказывал о том, что, начиная с ONTAP 8.х, и на 64-bit aggregate, у WAFL есть механизм компрессии хранимых на дисках данных. Механизм онлайн-компрессии сравнительно хорошо знаком пользователям, так как, например, давно поддерживается на NTFS. Однако, по моим наблюдениям, используют его не так часто, боясь его заметного влияния на производительность, и большей нагрузки на процессор сервера. Следует, тем не менее, отметить, что для современных процессоров, производительность которых сильно выросла со времен Stacker и MS DiskDrive, такая дополнительная нагрузка на процессор операций запаковки-распаковки весьма незначительна по абсолютной величине, но при этом значительно уменьшает объемы дискового трафика. Например, если компрессия, вдвое уменьшает “футпринт”, то есть хранимый объем данных, то за счет сравнительно небольшого увеличения (проценты, как правило) нагрузки на процессор, мы можем вдвое увеличить производительность чтения-записи, так как объем данных считываемых и записываемых на диск уменьшается, в нашем случае, вдвое, данные попадают на диск и считываются с него всегда уже сжатыми.

Так что влияние компрессии на производительность может быть совсем не столь однозначно отрицательным.

Но любопытно подробнее разобраться с тем, как реализована компрессия у NetApp. Дело в том, что для файловых систем, хранящих данные в фиксированных блоках-“кластерах” файловой системы, компрессия внутри этих кластеров, зачастую, бесполезна. Данные не могут занимать места менее одного блока (для WAFL – 4KB), то есть экономия места внутри блока никак не может быть использована. Сложность вызывает также работа с большим файлами. Например, в случае “обычной” компрессии файла архиватором типа ZIP, и прочими аналогичными, нам, часто, для того, чтобы извлечь, изменить или записать данные в середину большого файла, приходится распаковать и перепаковать его целиком. Это влечет за собой большую затрату времени и занятой памяти RAM. То что годится для оффлайновых архиваторов – не подходит для онлайн-компрессии.

При создании механизма компрессии инженерам NetApp пришлось решить как эти, так и многие другие проблемы.

Первый интересный с точки зрения “техники процесса” момент организации работы компрессии состоит в том, что алгоритм компрессии работает не с “файлом” целиком, а бъет его на фиксированные сегменты, под названием “Compression Groups”. Каждая Compression Group содержит 8 секторов WAFL, размером 4KB, и имеет размер 32K.

Каждый файл, размещенный на томе, со включенной компрессией, рассматривается алгоритмом компрессии как разбитый на некоторое количество независимо обрабатываемых Compression Groups (CG). Например файл, размером 60KB будет содержать две CG, одну размером 32KB, и одну неполную, размером 28KB. При этом компрессия не применяется к файлам, размерам 8KB и менее.

Каждая CG обрабатывается отдельно, а, при необходимости считывания части файла “из середины”, считывается и распаковывается не весь файл, а только необходимая Compression Group в нем.

Но это еще не все интересное.

Выглядит довольно очевидным решение как-то определять факт невозможности или низкой эффективности сжатия для данных, и данные, которые не жмутся (например JPEG, ZIP, MP3 или AVI) не жать вовсе, сэкономив на этом ресурсы процессора. Ведь в противном случае процессор будет полноценно занят сжатием-разжатием содержимого Compression Groups ради жалких долей процента результата. Именно так поступили в NetApp. Перед операцией для Compression Group определяется эффективность сжатия, и, если результат получается ниже 25% (менее четверти содержимого группы, то есть менее 8KB, удается высвободить в результате компрессии), то сжатие для данной группы не прозводится вовсе и она записывается неизменной.

Наконец, любопытным решением является разделение операций на онлайновые (inline), то есть производящиеся непосредственно “на лету”, по ходу поступления данных, и постпроцессные (postprocess). Постпроцессный метод уже широко применяется в механизме дедупликации, и позволяет свести к минимуму влияние процесса дедупликации на работу системы и ее производительность.

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

Постпроцессная компрессия выполняется по тому же расписанию, что и дедупликация, и запускается после выполнения процесса дедупликации для данного тома. Стоит также отметить, что дедупликация и компрессия возможны на одном и том же томе, прекрасно сосуществуют, и не отменяют одна другую. Более того, компрессия после дедупликации вполне возможна. Представьте себе множество виртуальных машин, которые хорошо дедуплицируются, так как содержат одно и то же содержимое, и дедупликация позволит нам хранить не сто виртуальных машин, а одну (и некоторое количество сохраненной “дельты” между этой VM и сотней индивидуальных VM с дедуплицированным нами содержимым) . Но ведь файлы Program Files или пользовательские файлы этого единственного экземпляра, как правило, можно еще и сжать раза в полтора! И эта компрессия будет осуществлена над уже дедуплицированным содержимым.

Следует также отметить, что компрессия, так как она осуществляется над фиксированными Compression Groups, не мешает работе дедупликации. Два идентичных и хорошо дедуплицируемых файла, будут разбиты на одинаковое количество Compression Groups, и получившиеся 32KB группы после компрессии останутся по-прежнему идентичными и по прежнему дедуплицируемыми.

Хотя в NetApp предприняли значительные усилия, чтобы повысить эффективность и постараться обеспечить наименьшее влияние на производтельность при работе компрессии, какое-то влияние на производительность (зависящее от множества факторов, как то объемы записей, характер доступа, и так далее) все равно, безусловно, будет иметь место.

Лаборатория NetApp опубликовала следующие оценки производительности для системы FAS6080 (на сегодня это уровень хорошего такого midrange класса FAS3240, пожалуй). Для такой системы были достигнуты показатели работы постпроцессной компрессии на уровне 140MB/s для одного процесса, и 210MB/s максимальной производительности для нескольких процессов одновременно. На загрузке характера файлового сервера, с нагрузкой на процессор не более 50%, задачи inline-компрессии увеличивали нагрузку на менее чем 20% для датасетов, сжимающихся минимум на 50%.

Оценочная эффективность компрессии и дедупликации показывается NetApp для разных наборов данных на следующем графике:

Я бы хотел также упомянуть, что имеющаяся у партнеров NetApp утилита SSET (Space Savings Estimation Tool) в текущей версии позволяет провести оценку эффекивности дедупликации И компрессии на реальных пользовательских данных, вычисляя на них результат работы алгоритма NetApp. Эта утилита запускается на реальных данных пользователя, работая в read-only, и, никак не изменяя и не повреждая эти данные, позволяет оценить результат дедупликации и компрессии даже без использования стораджа NetApp, например до его покупки. Эту утилиту можно просить у партнеров, она имеется для Linux и Windows.

Итак, в постах о том, как работает Cluster-mode я уже упоминал то, как работает доступ к данным на кластере. А сейчас давайте рассмотрим подробнее процесс создания LUN-а на кластере, для обычного блочного подключения его с хост-сервера Windows.

Несмотря на то, что System Manager 2.0 уже умеет работать с системами в Cluster-mode, мы посмотрим на то, как создаются объекты хранения данных Data ONTAP 8.1 Cluster-mode из консоли. Это нагляднее и проще заскриншотить.

Создадим Vserver. В предыдущем посте я рассказывал что это и зачем нужно в Cluster-mode. А вот как он создается.

Создадим Vserver под названием MyVserver на aggregate с именем aggr1:

Допустим, мы хотим обращаться к данным, хранимым на MyVserver по протоколу FCP, для версии 8.1 у нас уже есть возможность работать с данными в Cluster-mode по блочным протоколам. Для этого, включим для Vserver протокол FCP (и проверим его включение):

Target Name это физическое имя (nodename) соответствующего контроллера.

Далее нам нужно создать так называемый LIF – Logical Interface, о котором я уже также упоминал в посте ранее. LIF – это логический интерфейс, который динамически мапится на физический интерфейс того или иного узла кластера, на котором работает Vserver, и через который обеспечивается ввод-вывод данных. Создадим и посмотрим на то, что у нас получилось.

Network Address/Mask эквивалентен физическому WWPN у порта контроллера.

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

Создадим группу MyIGroup и включим туда FCP WWPN initiator-ов с соответствующих портов.

Наконец, создадим том FlexVol под названием MyVol:

Теперь создадим LUN по имени MyLUN на этом томе:

Смапим LUN соответствующей igroup

А теперь подключаем созданный LUN обычным образом на сервер Windows, с помощью стандартной оснастки Disk Management.

Готово. У нас на сервере подключен LUN по FCP, расположенный в кластере контроллеров NetApp под управлением Data ONTAP 8.1 Cluster-mode.

За основу поста взят пост из блога специалиста NetApp “Pseudo Benchmark”, из которого я позаимствовал скриншоты.

Я уже пару раз рассказывал в этом блоге о том, что такое и зачем используется такая возможность, как Multistore и vfilers. Вкратце – это изолированные jail-подобные “инстансы”, виртуальные стораджи, создаваемые и работающие поверх физического экземпляра Data ONTAP, каждый из которых работает как изолированный “нетапп”, со своим IP-space, своими настройками, и так далее. Их можно использовать, например, для создания “партиционированных”, изолированных виртуальных стораджей, например вывесить один в DMZ, а другой – использовать во внутренней IT-инфраструктуре, обеспечив с их помощью полную изоляцию и безопасность данных одного vfiler от другого.

С использованием vfilers реализована такая интересная функциональная возможность NetApp, как Secure Multi-tenancy, то есть возможность использовать один физический сторадж для нескольких независимых клиентов, например для “облачного” хранения данных множества пользователей. Каждый клиент такого облачного стораджа получает виртуальный, независимо управляемый пользователем сторадж, логически изолированный от прочих.

В числе прочих возможностей, такой vfiler можно, не прерывая его работу, мигрировать с одного контроллера на другой, используя функциональность, под названием Data Motion for vfilers.

Однако в версии 8.х NetApp пошла дальше. Если для Data ONTAP 7.x Multistore и vfilers это хитрая опциональная фича, то для Data ONTAP 8.x новая инкарнация vfiler, под названием vserver – стандартный и абсолютно необходимый элемент структуры управления и хранения данных.

Vserver – это виртуальный сервер хранения, который размещается на одном или нескольких контроллерах кластера Data ONTAP 8.x, и который может мигрировать, подобно vfilers в Data Motion for vfilers, а для коммуникации с “внешним миром” имеет так называемые LIFs, или Logical Interfaces, независимые от физических портов контроллеров в кластере.

Таким образом, Vservers в Data ONTAP 8.x – это новое воплощение vfiler из ветки 7.x, поддерживающие Cluster-mode, обеспечивающее Single Namespace, существующие поверх одного или нескольких контроллеров кластера, имеющие для соединения с “внешним миром” “виртуальные сетевые интерфейсы” – LIF, гибко (пере)привязываемые к физическим портам контроллера. LIF поддерживают все протоколы доступа к данным в Cluster-mode. Vservers владеют томами FlexVol, могут мигрировать между контроллерами и поддерживают Role-based Access Control (RBAC).

В следующем посте этой тематики я покажу на примерах, как создается Vserver и настраивается доступ к данным в Cluster-mode.

Если вы уже используете в админской работе NetApp PowerShell Toolkit, то вы уже знаете, что это такое. Для тех же, кто только подключился, поясню, что NetApp POSH Toolkit это набор разработанных в NetApp так называемых коммандлетов (commandlets), с помощью которых можно расширить и управлять системой хранения с использованием командной оболочки Microsoft Powershell.

Взять текущую версию, недавно обновившуюся до v1.7 можно на сайте NetApp Community (для скачиваня нужно залогиниться):
https://communities.netapp.com/docs/DOC-6138

Полезный документ о использовании средств NetApp Powershell Toolkit , с описанием коммандлетов и способов их использования, можно взять тут:
https://communities.netapp.com/docs/DOC-10684

Также, пользуясь случаем, хочу пригласить вас, раз уж вы завели себе логин в Communities.netapp, в недавно созданную группу для русскоязычных пользователей NetApp-RU на серверах Communities.

На днях увидел в блогах, которые я читаю, интересную статью специалиста Microsoft, о использовании SMI-S провайдера. SMI-S поддерживается системами NetApp FAS уже несколько лет, и я уже очень давно собираюсь написать на эту тему пост. Но как-то он все отодвигается и отодвигается более актуальными темами, я просто приведу вам “для затравки” цитату из той статьи, и предлагаю идти читать остальное уже там:

Storage Management Initiative – Specification или SMI-S, это стандарт управления дисковыми хранилищами, разрабатываемый с 2002 года Storage Networking Industry Association. SMI-S является ANSI и ISO стандартом. Актуальная версия SMI-S 1.5. Более 800 различных аппаратных и 75 программных решений поддерживают данный стандарт. Основная идея стандарта – унификация управления дисковыми хранилищами через веб-запросы.

System Center Virtual Machine Manager 2012 позволяет подключить SMI-S хранилища, так чтобы администратор имел возможность из консоли VMM получать информацию о LUN, группах RAID, свободном месте на хранилище и так далее.

Подробнее – там:

http://blogs.technet.com/b/vm/archive/2012/02/15/smi_2d00_s-support-in-vmm2012.aspx

Несмотря на то, что в оригинальной статье рассматриваются системы EMC, напомню, что SMI-S для NetApp FAS есть, совместим c VMM2012, поддерживаем в MS и NetApp , и работает. Берут SMI-S provider на NetApp Support, где он доступен бесплатно (нужен логин на NOW).

Вид EMC Clariion CX4 из VMM2012 через SMI-S: