about NetApp

Продолжим нашу серию про не слишком известные, но полезные команды, “в записную книжку админа”. На очереди у нас уже однажды упоминавшаяся команда lock.

Напомню вкратце. В системе совместного доступа, какой является NAS, для того, чтобы обеспечить отсутствие конфликтов доступа, используется метод так называемого “локирования” доступа к файлу.  Это необходимо для предотвращения возможности одновременной, но неснхронизированной записи в один и тот же файл от разных клиентов, не знающих о том, что сосед тоже решил изменить тот же самый файл, уже открытый одним клиентом. Для предотвращения такой ситуации, первый открывший файл клиент получает исключительные права на запись в файл (локирует файл на запись), остальные же – только на чтение, до тех пор, пока первый клиент не закончит записи в файл.
Возможно два типа локирования, так называемый file lock, при котором ограничивается доступ на запись в файл целиком для всех, кроме залокировавшего файл на запись клиента, и byte range lock, при котором ограничивается запись к определенному участку файла.

С помощью команды lock status можно посмотреть, какой хост и какой пользователь локировал тот или иной файл на NAS-системе.

fas1>  lock status –p cifs –h  (показывает локи сортированные по имени хоста)
CIFS host=172.18.2.107(VUSER01-VPC) owner=administrator state=GRANTED mode=Read-
denyN oplock=None fsid=0×0e1d66f7 fileid=0×000000d3
path=\word.doc(/vol/vol0/share1/word.doc)
 
fas1> lock status –p cifs –o (показывает локи, сортированные по пользователю или владельцу)
CIFS owner=root host=10.34.17.49(PC002-XP) pid=65279 offset=2147483539 len=1
excl=yes state=GRANTED fsid=0×0e1d66f7 fileid=0×000000d3
path=\word.doc(/vol/vol0/share1/word.doc)

Снять же ненужное (например ошибочно “зависшее”) локирование можно командой:

fas1> lock break -f file [-o owner -h host] [-p proto]

Обратите внимание, что, хотя команда lock break –f и поддерживается, но при использовании NFS v4 ее применение не рекомендуется, по причине ряда ненужных побочных эффектов снятия локирования таким образом.

Как я уже писал раньше, начиная с Data ONTAP 8.0.1, для пользователей систем хранения NetApp становится доступной опция компрессии хранимых на дисках данных. Эта возможность довольно популярна среди современных файловых систем, например она хорошо работает в NTFS. Теперь эта возможность, дополняющая дедупликацию, появилась у NetApp.

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

Преимущество хранения скомпрессированного файла очевидно. В такой форме файлы занимают значительно меньше места на диске. Насколько меньше – зависит от характера данных. Например уже обработанные тем или иным компрессором файлы, а также цифровое видео и аудио, обычно также сжатое тем или иным алгоритмом, уже практически не сжимается. ??сполняемые файлы, например программы, сжимаются примерно на 25-35%. Файлы данных, такие, как документы Word и Excel – обычно на 30-50 процентов.

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

Еще одним неявным преимуществом хранения данных в таком виде, которое часто недооценивается, является, как ни парадоксально, улучшение показателей производительности считывания с дисков для сжатых файлов. Ведь если мы храним файл, сжатый на 50%, то для того, чтобы считать его с дисков (сжатый), нам придется прочесть с этих дисков в память поток байт вдвое меньший, чем для некомпрессированного файла. Лучше, следовательно, могут стать и показатели IOPS системы.
Платим за это мы потенциально большей нагрузкой на процессор, все верно. Однако, в наше время, производительности процессоров на такие несложные, хорошо известные и эффективные алгоритмы, как онлайн-компрессия, хватает с огромным запасом.  Во многих случаях разница в загрузке процессора даже оказывается ниже измеряемого уровня. Пожертвовать ради увеличения дисковой производительности единицами процентов загрузки процессоров, мощность которых непрерывно растет кадый год, по сравнению с показателями в IOPS для дисков, которые застыли и не улучшаются уже довольно давно, бывает вполне неплохим вариантом “обмена”.

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

Теоретически мы могли бы попробовать архивировать отдельно составляющие файл блоки WAFL размером 4KB, используя компрессию на уровне блоков , но что делать с высвободившемся от такой компрессии местом? WAFL не может работать с местом на таком “субблочном” уровне. Если у нас есть файл, который занимает 3 блока WAFL по 4KB, то еть имеет размер в 12KB, и файл сжимается вдвое, то после компрессии на уровне блоков WAFL мы получим три наполовину пустых блока WAFL, однако свободное место на них (так называемые tail-ы) использовать не получится – субблочное пространство не адресуется в ONTAP, и файл по прежнему будет занимать три блока – 12KB.

Выход – в использовании групповой обработки. Каждый хранимый файл последовательно делится на так называемые compression groups, размером 32KB, то есть состоящие из 8 блоков WAFL, с которыми и производятся неободимые операции. Compression Groups рассматриваются как единый объект воздействия компрессии. Поделенный на такие группы файл считывается только в той части, что необходима. Если нам нужно изменить блок данных в середине, то считывается в память 32KB данных, содержащих данный блок, блок изменяется, и затем группа компресируется и записывается.

Любопытно, что перед тем, как компрессировать группу, Data ONTAP проводит “на лету” оценку эффективности компрессии. Если компрессия незначительна (очевидно, что это менее 1/8 размера), то группа записывается в исходном виде. Таким образом, файл сжатого видео, записанный на “сжатый” том, будет записан в “исходном” его состоянии, время и процессор на сжатие явно несжимаемго не тратятся. Оценка же производится для 32KB групп. Если внутри в целом несжимаемого файла обнаружится последовательный блок размером 32KB и более, пригодный для сжатия, он будет сжат обычным образом.

Как обычно, коротко, в вопросах и ответах.

Q: Сколько это стоит?
А: Данная лицензия будет доступна бесплатно, как, например, было и есть с дедупликацией.

Q: Это будет работать только для Data ONTAP 8?
A: Нет, еще какое-то время будет продолжаться развитие ветви “семерки”, и, по предварительным данным, в ней тоже будет доступна компрессия. Если у вас активна подписка на обновление ПО, и вы можете поставить новую версию ONTAP на вашу систему, в ней будет и компрессия. Но вообще говоря, стоит уже задуматься о переходе на Generation 8.

Q: Это вместо дедупликации?
A: Нет, это работает независимо, и может компресировать даже уже дедуплицированные тома! ?? дедупликацию, и компрессию, вы можете использовать независимо, и даже одновременно, на одних и тех же томах.

Q: А если дедупликация уже дедуплицировала, разве остается что-то, что можно еще и сжать?
A: Конечно. Вот, например, описание эксперимента, в котором оценивалась эффектвноссть дедупликации и компрессии: http://habrahabr.ru/blogs/sysadm/104979/
Кроме этого, представим, что у нас на диске лежит сто одинаковых документов. После дедупликации у нас на диске останутся занятыми только блоки одного экземпляра (и по 99 ссылок на них из других файлов). Но этот единственный файл, в свою очередь также можно скомпрессировать! На дедупликацию и содержимое остальных, дедуплицированных файлов это не повлияет. Они просто будут ссылться на компрессированные блоки.

Q: Когда компрессировать получается лучше, чем дедуплицировать?
A1: Представим себе, что на диске лежит множество файлов, которые уникальны по содержимому. То есть, например, текстовая база документов. Каждый, кто архивировал текстовые файлы знает, что такие файлы хорошо компрессируются. Однако вероятнее всего, в неповторяющихся файлах, дедупликация будет неэффективна. Ведь в таких файлах наверняка нет кусков по 4KB размером, строго идентичных до байта. Любая неидентичность в пределах блока WAFL в 4KB отменяет возможность дедупликации.
A2: Другой вариант, сильно ухудшающий возможности дедупликации – смещение. Даже незначительное смещение в содержимом файлов мешает правильно сработать дедупликации. Но ничуть не ухудшает возможности компрессии.

Q: А что вообще лучше, дедупликация или компрессия?
A: Для разных применений – лучше разное. Что-то лучше дедуплицируется, пример – файлы дисков виртуальных машин, что-то – компрессируется, пример – большинство баз данных, или хоумдиры документов с малым количеством дублирующихся между разными пользователями данных, или бэкапы с переменным смещением, сильно портящие “статистику” дедупликации. Наконец, вы можете компрессировать уже дедуплицированные данные.
Конечно, дедупликация несколько меньше нагружает систему по процессорным ресурсам и почти не влияет на производительность, так как работает, в отличие от компрессии, в “оффлайне”. Но в ряде случаев и нагрузкой компрессии можно пренебречь, а экономия пространства – штука нелишняя. Смотрите по обстановке.

Q: Круто, спасибо!
A: Да на здоровье :)

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

Почему NetApp оказывается "вдвое дороже на том же количестве дисков"? Почему вообще бессмысленно соревноваться с конкурентами по "цене за определенное число дисков"?

Допустим, мы объявляем "тендер" по покупке автомобиля, но так как мы пока не слишком большие специалисты в этой области, то список требований "тендера" невелик. Допустим там будет количество колес, грузоподьемность и объем двигателя - 1600 куб.см. Ну вот не специалисты мы, знаем только, что автомобиль он на 4 колесах и с двигателем, и двигатель, нам сказали, что 1600 будет нам в самый раз.

Этим условиям удовлетворяет вазовская "шестерка"-классика и Toyota Corolla (все совпадения с реальными названиями - случайны, все торговые марки принадлежат их владельцам;).

?? тот и другой заявленный на "тендер" автомобиль имеет 4 колеса, кузов, грузоподъемность и двигатель - 1600 куб.см.

Формально все требования удовлетворены в обоих случаях.
Однако по цене Toyota получается значительно дороже.
Почему?

Потому что у нее "в базе", в базовой комплектации, кондиционер, АКПП, подогрев сидений, встроенная DVD-аудиосистема, мотор, при том же объеме, боле мощный и одновременно экономичный.
Выше и цена, что естественно.

Если мы будем ориентироваться только на формальные "тендерные" требования, то выбор очевиден, если обе машины удовлетворяют заявленным требованиям, и одна из них значительно дороже, чем другая, то выиграет та, что дешевле.

Однако в реальной жизни выбор часто не столь очевиден :)

Да, конечно, цена важна, но кроме цены важны также и предлагаемые за эти деньги возможности. ?? очень часто именно возможности "решают" выбор. Однако если вы никогда не пробовали, что такое кондиционер в автомобиле летом, или что такое АКПП в многочасовой городской пробке, или насколько отличается с точки зрения семейного бюджета мотор с расходом 8 литров по городскому циклу от мотора в 11 литров на 100 км, то вы, на этапе покупки, часто, не сможете оценить важность всех этих возможностей.

??нтересно, что если мы будем сравнивать более объективно, чем "по кубатуре двигла, и только", и попробуем "уравнять" вазовскую "классику" по набору фич, даже если это и было бы возможно, то, в результате, мы почти наверняка получим более дорогую, чем Toyota машину!

Конечно, есть такие автовладельцы, которые полностью удовлетворены возможностями вазовской "классики" и не хотят ничего иного. Причины этому могут быть самые разные.
Никогда не пробовали ничего лучше, и считают, что АКПП и кондиционер это буржуйские излишества - частый пример. ??ли на самом деле нет больше денег, ну вот совсем нет. ??ли же, наконец, на ту небольшую нишу применения, например возить ящики с рассадой на дачу, и правда вполне достаточно ВАЗа.

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

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

Не всегда "быть в два раза дешевле" одновременно означает "быть в два раза лучше"
Не всегда "решает" только цена.

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

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

Однако, есть люди, которые iSCSI не используют, и, несомненно, им бы хотелось, чтобы одним “протоколом по умолчанию” стал какой-нибудь другой, тот, что им нужен. Это была бы большая экономия, например если вам нужен только весьма недешевый у NetApp NFS, или же FC, для “чисто-FC” системы. Радостная новость для таких людей – вас услышали. Новые серии, 3200 и 6200 теперь идут с новой схемой лицензирования протоколов.

Теперь в цену системы включен один любой протокол на ваш выбор: FC, iSCSI, CIFS или NFS!
А любой из остальных трех продается за одну и ту же для данной системы цену!

Услышаны и любители all inclusive. Теперь в базовую систему, без дополнительной оплаты, включена целая серия лицензий, под названием Data ONTAP Essentials.
Эта политика уже была испробована на системах серии FAS2000, где лицензии приходили набором определенных “бандлов”, а протоколы были включены все сразу в базовую конфигурацию “Base Pack”.

В Data ONTAP Essentials входят почти все массово применяемые на стороне стораджа лицензии, за исключнием SnapRestore, SnapMirror и FlexClone, продающихся отдельно. Тут и привычно бесплатная Deduplication, и новая WAFL Compression, и всегда стоившая денег Multistore, используемая теперь в Data Motion, и SyncMirror, и даже Metrocluser и OSSV (Open Systems SnapVault). В составе этого all inclusive pack теперь поставляется и NetApp DSM (Device-specific Module) для организации MPIO, и набор ПО управления – Operations Manager, Protection Manager и Provision Manager, ранее стоивший существенных денег.

Все же имеющиеся продукты семейства SnapManager включены в единый пак SnapManager Suite, и с ним вы получаете лицензии на SnapManager сразу для всех продуктов: для VMware, Hyper-V, Exchange, Sharepoint, MS SQL Server, SAP и Oracle. Туда же включены и лицензии SnapDrive как для UNIX, так и для Windows. Теперь не нужно покупать разные SnapManager по отдельности, если вы используете под VMware в виртуальных машинах и Exchange, и MS SQL, и Sharepoint. Один пак и пользуйтесь всеми созданными SnapManager под любое доступное приложение. Осталась возможность покупать SnapManager/SnapDrive по модели per-server, но для количества серверов больше трех выгоднее покупать сразу Suite, которая не огранчена по числу инсталляций.

Обратите, пожалуйста, внимание, в настоящее время все эти нововведения, и “протокол на выбор в подарок”, и “5-stars ultra all inclusive” лицензий, все это распространяется только на новые системы – FAS3200 и FAS6200. Все системы старых серий лицензируются по прежнему – FAS2000 бандлами лицензий (Foundation/Application/Server Pack), а 3100 и 6000 – “a-la carte”.

Ну, разве не праздник?

Днями ранее я уже рассказал вам про новинки этой осени, представленные на Insight 2010 в сегменте midrange. Но одновременно с ними были объявлены и три новых системы в “старшем классе”, так называемых highend storages.

Напомню, что ранее в этом сегменте у NetApp были две хорошо себя зарекомендовавших системы серии 6000 – FAS6040 и FAS6080. К ним теперь добавились еще три:
FAS6210, FAS6240 и FAS6280.

Также как у FAS3200 следует обратить внимание на новую концепцию chassis, аналогичную системам серии 3200. В корпус теперь можно поместить также либо два контроллера (dual controller HA, только FAS6210), либо один контроллер и заглушку для single-controller (для всех систем), либо контроллер и модуль расширения портов IOXM (для 6240/80).

??спользование IOXM позволяет достичь большей гибкости конфигурирования и расширяемости (6000 – 8 слотов расширения(5 PCIe + 3 PCI-X), 6200 – 14 слотов (12 PCIe 2.0 8x + 2 special PCIe).

Для системы “нижнего highend” ;) 6210, в конфигурации single chassis dual controller это позволяет в 6U  поместить высокопроиводительную пару контроллеров. Это хороший вариант для апгрейда “старшего midrange”, например 3170, на новый уровень производительности, с получанием и 10G Ethernet “в базе”, и 8G FC, и 4 слотов расширения на каждый контроллер (8 на HA-пару).
Таким образом, как вы видите, здесь, в highend-сегменте, тоже предпринята попытка “размыть” строгое деление между классами, путем создания своеобразных “переходных” моделей (3210 и 6210).

Данные по производительности (как SPEC SFS2008, так и SPC-1) будут опубликованы в скором времени уже опубликованы для FAS3270 и FAS6240 , однако пока могу намекнуть, что новые системы быстрые. Очень быстрые. Вот прямо таки “в разы”. ?? это тоже отличная новость.

Что же у этих систем на панели сзади?

По порядку, слева направо:

Порты ACP и контроллера удаленного администрирования Service Processor. Также как у 3200.

Два порта Gigabit Ethernet.

Четыре встроенных порта 10G Ethernet stateless offload с оптическими SFP+.

Два вертикальных слота со специальным формфактором (еще два таких ниже в IOXM), предназначенные для установки в них карт портов интерфейсов – на выбор FC 8Gb/s или SAS 3/6Gb/s (карты со специальным партномром и несовместимы с PCIe по разъему и формфактору). В эти слоты нельзя ставить обычные PCIe, и карты для этих слотов нельзя ставить в стандартные PCIe.

В контроллерном модуле слот слева всегда должна занимать либо карта FC, либо карта SAS. 2 слот, справа, всегда занимает карта NVRAM8 (NVRAM8 по прежнему использует для HA-кластерного интерконнекта Infiniband, однако использует теперь для них уменьшенный разъем, идентичный разъему SAS, не перепутайте, на самом деле справа именно NVRAM, а не карта SAS, как можно было бы подумать, бегло глядя на фото).

В IOXM оба слота могут заниматься картами портов FC или SAS того самого хитрого формата, либо оставаться свободными. Смешивать интерфейсы (поставив туда и FC и SAS одновременно) можно.
Несмотря на эти сложности, порты FC в данных слотах можно использовать не только как initiator (для подключения к ним дисков), но и как target (для подключения к ним хостов-серверов). Порты SAS, конечно же можно использовать только для дисков (initiator).

Неиспользуемый в настоящее время порт USB (такой же, как на 3200).

Четыре универсальных порта FC 8Gb/s (target/initiator).

Порт консоли.

А вот как выглядит контроллер FAS6200 внутри (для ценителей hardcore geek porn %):

В прошлом посте я начал рассказывать о технических деталях объявленных 9 ноября системах midrange-класса, расширивших и дополнивших существующую линейку систем FAS3100.

С “лица” в общем все понятно:

Но перейдем к подробностям. Что же там, “сзади”?

Вот что у нас теперь имеется из портов и расширений.

В первую очередь хотел бы обратить внимание на принципиально новую конструкцию chassis. Как вы видите, он состоит из двух одинаковых “слотов”, в которые могут быть вставлены блоки одинакового типоразмера: контроллер, или специальный модуль расширения IOXM (Input-Output eXpansion Module).
При этом, хочу отметить, высота такого модуля осталась равной всего 3U, это высота классического контроллера FAS3000,  вдвое меньше, чем chassis 3100.

Такой chassis может быть использован двояко. В такой chassis можно поставить два контроллера, в оба слота, получив в 3U стандартный HA-cluster, при этом будут еще доступны два слота расширения PCIe full и 3/4 size, новой версии стандарта 2.0, обратно совместимого с платами 1.0. Либо же (для моделей 3240/70) поставить в верхний слот контроллер, а в нижний – специальный модуль IOXM, который для серии 3200 предлагает дополнительные 4 слота расширения
НО: для 3210 нет варианта с IOXM (то есть только один или два контроллера в chassis).

Таким образом для моделей 3240 и 3270 кроме варианта “2 контроллера в одном chassis” будет предлагаться вариант “контроллер и IOXM” в одном chassis, либо “один контроллер в chassis, без IOXM” (правда обратите внимание, что добавить позже, у клиента, in field, в последний вариант IOXM по ряду технических причин нельзя! Только заменой всей системы. Это довольно заметная засада, и ее лучше сразу себе представлять, и при возможности не экономить на IOXM, поскольку добавить его позже, в случае возникновения в нем необходимости, нельзя.)

Конечно, при необходимости, например для некритичной системы, или как компонент многоузлового кластера 8.0-cluster-mode, все три системы можно купить и в “одноконтроллерном” варианте, для 3210 это будет один chassis с одним контроллером и заглушкой, а для 3240/70 – один chassis с одним контроллером и с/без IOXM.

Любопытно, что для всех трех систем midrange будет возможна конфигурация Metrocluster (“географически”-разнесенного HA-кластера), даже и для сравнительно недорогого 3210, НО не поддерживаются полки SAS, то есть пока только на DS14mk4. Позже, возможно в следующем году, будет готов бридж SAS-FC, но пока его нет, и конфигурация Metrocluster на SAS не поддерживается.

По портам слева направо:

Встроенные 2 порта стандарта SAS-2 двухрежимные 3/6Gbit, для подключения как DS4243, так и DS2246.

Новинка. Теперь HA-cluster interconnect использует в midrange не Infiniband, как ранее, а 10G Ethernet (в 6200 по прежнему сохранился Infiniband, однако переход на 10GE позволил отчасти снизить стоимость платформы в midrange). Однако обратите внимание, несмотря на то, что это физически порты 10G Ethernet, использовать их под “пользовательский трафик”, например под FCoE или NFS нельзя. По нему ходит только ha-cluster interconnect!
Даже когда вы используете 3200 в варианте “два контроллера в одном chassis”, и при этом вместо внешнего интерконнекта “через провода”, используется, как в 3100, соединение через backplane, все равно эти порты использовать для “внешнего” трафика нельзя.
Однако, конечно, можно добавить в слот расширения карту с портами 10G, и использовать порты 10G с добавленной карты как угодно.

Два порта 4Gb FC, традиционно универсальные: target/initiator. Количество встроенных портов FC уменьшилось, поскольку для дисковых полок теперь предполагается использовать встроенные порты SAS. Также как и раньше, при необходимости увеличения любых портов, в том числе FC, можно установить соответствующую карту расширения.

Два порта Gigabit Ethernet. Тут без изменений.

Два порта – сеть ACP Alternate Control Path для управления полками SAS, о которой я писал недавно, и под ним – порт нового интегрированного контроллера удаленного управления – Service Processor. Это новое поколение специального микроконтроллера управления, несмотря на интегрированность в контроллер, полностью автономного от Data ONTAP, и работающего под управлением своего собственного ядра микроконтроллерной OS, что позволяет ему работать абсолютно автономно от работы собственно контроллера, иметь свой собственный IP, и быть подключенным в отдельную сеть управления компании. С этого контроллера можно иметь доступ как к telnet/ssh, так и к консоли, и выполнять любое сервисное обслуживание системы, включая перезагрузку, cluster takeover и вход в pre-boot и maintenance menu до загрузки Data ONTAP.

Рядом классический “cisco-вский” порт serial console в формате RJ-45, а над ним – порт USB, который в настоящее время разведен на контроллере физически, но никак не используется программно. Но можно заряжать от него мобильник или плеер. :) В будущем планируется использовать его для каких-то загадочных recoverability procedures, но в текущем и ближайшем выпуске Data ONTAP он не задействан никак.

Ну и для особолюбопытных – внешний вид контроллера внутри:

Ну что-ж, как говорится, “теперь об этом можно рассказать”. Объявлены новые модели в семействе midrange, к трем имеющимся, а именно FAS3140, FAS3160 и FAS3170 добавились еще три системы, построенные на обновленной аппаратной платформе: 
FAS3210, FAS3240 и FAS3270.

Несмотря на множество нововведений, это нельзя назвать “революцией”, это вполне эволюционный шаг развития. Более того, новые системы не вытесняют “старые” 3100, а дополняют модельный ряд, так что текущее предложение в midrange расширяется почти вдвое (а еще вдвое расширяется и линейка highend-систем, о которой мы поговорим позже), и на сегодня это самый большой набор моделей, производимых и продаваемых NetApp за всю его историю.
Официально, старые линейки контроллеров серии FAS3100 остаются “в строю” еще минимум на год, и сроки по EOL (End-of-Life, завершению активной “жизни” и продаж системы) по ним не объявлены.

??так, давайте посмотрим, что же нового появилось с этими моделями у NetApp.
Первое, что бросается в глаза – создан новый, более компактный “конструктив” корпуса. На смену зачастую неоднозначно воспринятой пользователями 6U “микроволновке”-моноблоку на два контроллера в одном корпусе, сменившей несколько лет назад относительно компактный 3U “одноконтроллерный” блок FAS3000, пришел очень компактный 3U блок, в который можно установить либо два контроллера модели FAS3210, либо контроллер ?? модуль расширения портов IOXM, для 3240/70 (подробности ниже).

Несмотря на все свое инженерное совершенство, будем смотреть правде в лицо, 6U на контроллер в окружении 1U/2U серверов, это чересчур щедро.
“Черт возьми, это всего-лишь просто контроллер, даже без дисков, а уже минус 6U в стойке!”
Особенно это ударяло по владельцам небольших систем “начального” уровня, например с парой дисковых полок DS14, когда модуль контроллера занимал в стойке столько же места, как и все диски системы вместе взятые, фактически удваивая занимаемый footprint системы.
А если требовалось построить “разнесенную” систему, то есть с контроллерами в разных стойках, то приходилось покупать два chassis по 6U каждый, каждый с одним контроллером и заглушкой на месте второго. ??того 12U только на котроллеры. Давайте скажем откровенно, это много. Особенно это много при размещении на арендованной площади в датацентре, где исчисление стоимости аренды идет от “юнита”.

Таким образом – первая внешняя отличительная особенность это компактный конструктив.
Что же в нем?

?? тут я бы хотел обратить ваше внимание на некоторые изменения в схеме позиционирования систем midrange. Напомню, что до сих пор все выпускаемые продукты линейки FAS делились на три сегмента. Старшие, так называемые “high-end”, средние, так называемымй “midrange”, и, наконец, “нижние”, которые, так как, в первую очередь по цене и функциональной насыщенности, их нельзя было ставить в один ряд с классическим “entry-level” других вендоров, дешевыми, но довольно примитивными, они назывались у NetApp “low-enterprise”.

Богатая “функциональная наполненность”, определяемая используемой OS Data ONTAP, такой же точно, как и у более “старших” систем, диктовала сравнительно высокую цену, даже несмотря на сравнительно невысокую производительность. В этом сегменте у NetApp было выпущено, не считая не вполне удавшейся затеи со StorVault, две модели – FAS2020 и FAS2050.
Позже к ним добавилась модель FAS2040, выпущенная в конструктиве 2020, но превосходящая по произвоительности не только 2020, но и 2050, и приближавшаяся уже по этим показателям к классическому “midrange” 3040/3140 (вдвое произволительнее 2050 и всего на 20% менее производительнее 3140 на нагрузке OLTP).

Таким образом, NetApp явственно взял курс не на “упрощение” и “обрезку” возможностей, а на “подтягивание” low-enterprise к уровню и возможностям midrange. Поэтому вполне в русле такой стратегии выглядит появление в линейке модели FAS3210, которая, судя по номеру, стоит “ниже” 3240, но при этом функционально (и по номеру версии) является midrange, и займет место в линейке между 2040 и 3240.
Плохая новость для владельцев 2050: надежды на выпуск нового 64-bit контроллера в конструктиве 2050, позволившего бы использовать ONTAP 8, и “малой кровью” модернизировать текущую систему, до современного уровня состояния платформ не оправдались. Путь модернизации это полная смена 2050 на 2040 (напомню, что 2040 примерно вдвое производительнее чем 2050) или же на 3210. Что, конечно же, дорого, болезненно, и “экспедиция”. Обидно. 2050 продавалась неплохо, и выглядела очень перспективно, но что-то “не пошло”. Поэтому не в последню очередь FAS3210 нацелена на рынок, ранее покупавший FAS2050, и такая “двойственность” положения в продуктовой линейке послужила причиной ряда особенностей конфигурации и конструкции, о которых ниже.

Однако, как же на сегодня выглядит продуктовая линейка NetApp?

Как вы видите из этого рисунка, продуктовая линейка расширилась сверху, за счет выпуска новых, более производительных систем в серии 6200, а снизу midrange “опустился” в low-enterprise моделью 3210. (на рисунке есть неточность, кажется, что 3270 “слабее” 3170, хотя это не так (примерно 20% прирост производительности на OLTP), также как и 6210 не слабее 6040 (а сильно производительнее), так что данный рисункок следует рассматривать скорее как схему позиционирования продуктов (в первую очередь по цене), а не как иллюстрацию распределения систем по “мощности”)
Напомню еще раз, что модели 3100 остаются на своих местах, и было бы логично увидеть на них вскоре “специальные цены”.

??так, что же там “сзади”?
(продолжение следует)

9 ноября по американскому времени (а в Москве это будет уже вечер 10) - “день премьеры”, объявляются новинки NetApp этого сезона.

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

Занимающимся администрированием систем NetApp в серверной инфраструктуре Windows, и владеющим навыками использования продукта Microsoft Powershell, может быть интересен постепенно развивающийся в комьюнити NetApp проект Powershell Toolkit for Data ONTAP.

Скачать с сайта communities (для появления возможности download вы должны иметь логин на Communities.NetApp)
Примеры скриптов
Прочая документация
Скачать v 1.2 не с сайта NetApp (без логина):
http://www.divshare.com/download/12954906-87d

С выходом в активную жизнь Data ONTAP 8 с ее cluster-mode в этом блоге я начинаю менять используемую терминологию. Теперь, во избежание путаницы, я буду называть “cluster-classic”, который был в ONTAP 7 – как “HA-кластер” (High Availability), а под кластером “просто” будет подразумеваться multinode-cluster или ONTAP 8 cluster-mode.

Как вы знаете, HA-кластерная функцинальность систем NetApp позволяет прозрачно для приложений и задач, в случае отказа одного из контроллеров HA-кластерной пары, перенести все его ресурсы, то есть IP-адреса, сетевые имена, WWN-ы FC, а следовательно доступ к сетевым шарам, LUN-ам, и так далее, с вышедшего из строя контроллера на действующий. Таким образом доступ ко всем ресурсам полностью сохраняется и не требует перенастройки клиентов или “фабрики” для продолжения доступа.

Однако такая схема переключения может занимать, подчас, довольно значительное время, исчисляемое десятками секунда на совершение этого HA-cluster takeover. Это связано с тем, что “выживший” контроллер должен понять, что его HA-кластерный партнер не просто не отвечает вовремя, а дейтвительно перестал работать.

Значительно ускорить этот процесс можно с помощью операции Hardware-assisted Takeover, которая использует для определеня состояния контроллера возможности RLM – автономного аппаратного микроконтроллера, который по основной своей задаче предназначен для удаленного “out-of-band” администрирования, и работает как независимое аппаратное устройство. RLM был опциональным устройством в системах серии 3000/6000, и встроен в контроллер для серии 3100 и новее. Будучи “внешним” для системы watchdog-ом, RLM позволяет значительно сократить время кластерного takeover, быстро определяя и сообщая состояние своего контроллера. RLM даже имеет автономное (хотя и не слишком длительное по времени автономной работы) питание, и остается включенным в сети даже, например, при полной потере электропитания контроллером, позволяя определять даже такое событие.

Для того, чтобы включить Hardware-assisted Takeover, при наличии на контроллере OS Data ONTAP 7.3 и новее, дайте в консоли команду

fas> options cf.hw_assist.enable on

Для того, чтобы изменить IP-адрес для получения партнером уведомлений об отказе, используйте команду (по умочанию это адрес порта e0a):

fas > options cf.hw_assist.partner.address <IP or hostname>

Подробнее смотрите во встроенной документации на систему Data ONTAP вашей версии, по словам ???hardware-assisted takeover’.