Posts tagged ‘ontap’

Вышел Data ONTAP 8.1 RC

Вышел долгожданный 8.1

Напомню, что по введенной с июля 2010 года модели именования релизов, выпуск под названием RC (Release Candidate) является полноценным релизом, оттестированным и готовым в продакшн.

Цитата с сайта:

Release Candidate (RC)

All Data ONTAP releases are made available first as release candidates (RCs). The RC classification indicates that NetApp has completed the internal testing of the major release. RCs are provided primarily to customers who want to start exploring the major or maintenance releases for either new features or bug fixes early on. RC releases are fully tested and are suitable for production usage. (выделение мое, romx)

NetApp might provide multiple RCs, as necessary, to address any specific issues found before the release becomes a general availability (GA) release. NetApp Global Services (NGS) provides support for RCs. After RCs move to GA, all maintenance and patch releases are based on the GA release and not on the RC.

Релизы “цифра после запятой” (Major Release) выходят каждые 18 месяцев, после их выпуска, каждые 6 месяцев выпускаются так называемые Maintenance Release.

image

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

Continue reading ‘Вышел Data ONTAP 8.1 RC’ »

5 причин перейти на Data ONTAP 8.0.1

А сегодня у меня в блоге наверное самый активный и интересный нетапповский блоггер, директор и евангелист направления виртуализации и cloud computing – Vaughan Stewart.

Напоминаю, что по средам я публикую переводы недавних интересных постов блоггеров самого NetApp, с их собственной блогохостинговой площадки blogs.netapp.com, кто свободно читает по-английски – рекомендую подписываться на тамошних авторов.

5 Reasons to Upgrade to Data Ontap 8.0.1

Vaughan Stewart - Director & Evangelist, Virtualization & Cloud Computing

На прошлой неделе, проводя наш Virtualization Field Readiness Summit, я много говорил с Dr.Desktop (Chris Gebhardt), который показал мне множество преимуществ наших технологий в области виртуализации десктопов, а также тем, какие преимущества несет с собой новая Data ONTAP 8.0.1, и я решил поделиться этим с вами.

Причина номер 1 – 64-битные aggregates

64-битные aggregate, или “пулы хранения”, позволяют увеличивать размеры aggregates, так как поднимают верхний лимит с 16TB в Data ONTAP 7.x.x до 100TB (в зависимости от типа и мощности контроллера). Для тех, кто еще не знаком с технологиями NetApp, aggregate это набор физических дисков, собранных в RAID-группы

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

При использовании 64-bit aggregate и RAID-DP, наш пользователи могут увеличить размер своих разделов данных, не поступаясь при этом степенью их защиты.

Причина номер 2 – NetApp DataMotion for FC, FCoE, & iSCSI LUN

NetApp DataMotion for LUNs это одна из наших технологий для организации многоуровневого хранения, с помощью которой мы можем, не прерывая доступа к данным на LUN-е, перемещать его (и соответствующий ему FlexVol) с одного aggregate на другой, на том же контроллере. DataMotion выполняет миграцию LUN-ов, вместе со всеми сопутствующими им атрибутами,такими как снэпшоты, состояние thin provisioning, состояние дедупликации и отношений между датасетами (например источник или получатель репликации, “зеркальность” для другого тома, и так далее), причем, как сказано выше, “на ходу”, не прерывая ввод-вывод данных с этих LUN-ов.

Причина номер 3 – 10GbE & FCoE Unified Target Adapter

Data ONTAP 8.0.1 обеспечивает поддержку (в форме драйверов устройств) для нашего Unified Connect Target Adapter (UTA). UTA более известен как Converged Network Adapter (CNA). Наши клиенты с UTA могут использовать его для всего их рабочего трафика, как SAN (FCoE, iSCSI), так и NAS (NFS, CIFS), одновременно, по одному проводу, с использованием Data Center Ethernet (DCE), известного как “10Gb Ethernet”, через одну карту PCI-E.

UTA кроме этого позволяет пользователям потенциально увеличить емкость хранения данных, так как позволяет высвободить слоты PCI-E, занятые под карты портов SAN и Ethernet, и установить в них порты для подключения дополнительных дисковых полок. Слоты PCI-E тут важны, так как, например, такая наша система среднего уровня, как FAS3270, может адресовать до 1,9PB хранения.

Причина номер 4 – Онлайн-компрессия на файловой системе

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

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

Причина номер 5 – поддержка VMware VAAI

Data ONTAP 8.0.1 обеспечивает поддержку VMware Storage APIs for Array Integration (VAAI), новой возможности появившейся в vSphere 4.1. Это такие возможности, как: Full Copy, Block Zeroing и Hardware-assisted Locking, расширяющие возможности масштабирования виртуальной инфраструктуры, путем переноса части операций по вводу-выводу на аппаратуру системы хранения. В настоящий момент поддерживаются только хранилища VMFS, но, верьте мне, в ближайшем будущем тут будет еще много интересного.

Ну ОК, я немного промахнулся, когда счел, что числа “пять” для причин будет достаточно. Есть еще кое-что, пусть это будет бонусом.

Бонус – Повышенная производительность!

В релизе 8.0.1 мы повысили быстродействие логики дедупликации в кэше массива, что дало нам прирост в различных тестах от 10% до 48% увеличения производительности.

Я хочу процитировать своего коллегу, Dr.Desktop, на стенде которого был проведен эксперимент с одновременной загрузкой 5000 виртуальных десктопов (VDI, VMware View) под Windows 7, что заняло 50 минут на всего 24 дисках SAS. Этот результат на 28% улучшил предыдущий результат, полученный с использованием на контроллерах Data ONTAP 7.3.4.

В комментариях указали еще один немаловажный плюс, который я счел необходимым внести в переводе (прим.romx)

Бонус 2 – лимит тома с дедупликацией теперь поднят до 16 TB для всех платформ!

Если раньше, на Data ONTAP семейства 7.х.х, емкость тома, на котором можно было включить дедупликацию, была ограничена различными величинами, в зависимости от типа контроллера, например для FAS2020 можно было включить дедупликацию только на томе, физическим размером не более 1TB, а для 2040 – 3TB, то на 8.0.1 эти лимиты на всех системах, поддерживающих 8.0.1, включая и 2040, лимиты емкости для тома с возможностью дедупликации подняты до 16TB.

Закругляясь.

Инженеры NetApp каждодневно работают над улучшением и увеличением возможностей нашей платформы, и с релизом 8.0.1 пользователи получили дополнительную функциональность и увеличение производительности для уже имеющихся у них систем. Я добавлю, что количество причин будет в дальнейшем только расти, с появлением все новых релизов.

С тех пор как нам удалось обеспечить непрерывающий (non-disruptive) работу системы хранения апгрейд с Data ONTAP 7.x на 8.0.1, апгрейд на новую версию не может быть проще!

Встроенное шифрование данных в Data ONTAP 8.0.1

По сведениям, опубликованным блогом Geek ONTAP, Data ONTAP с версии 8.0.1 будет уметь использовать диски, сертифицированные по FIPS 140-2 level 2, с так называемым “аппаратным шифрованием”, то есть встроенной системой шифрования-дешифрования данных с помощью уникального для каждого диска ключа.

Это, так сказать, не функция Data ONTAP как такового, просто возможность использовать средства, предоставляемые оборудованием. Подобные диски вот уже несколько лет как есть на рынке, к сожалению, из-за ограничений ввоза криптографических систем, они в России почти не встречаются, по крайней мере в официально поставляемых системах.

Так как вся эта кухня с ключами и шифрованием работает, по сути “на уровне диска”, то специальных особых требований к уровню OS данная система не предъявляет, оставаясь “прозрачной” для уровня приложений, однако поддержку и валидацию работы с NSE (NetApp Storage Encryption) требуют SnapMirror и SnapVault, что и было проделано для версии 8.0.1.
Работу с ключами обеспечивает специальный сервер ключей.

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

Powershell Toolkit for Data ONTAP

Занимающимся администрированием систем 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 7G Cookbook

Бродя по бесконечным просторам внутренних пространств вебсайта NetApp обнаружил там в глухом уголке чрезвычайно полезную вещь, каковой и поделюсь.
Называется Data ONTAP Cookbook.

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

  • Как создать том
  • Настроить NFS export
  • Сконфигурировать порт FC
  • Изменить размер LUN
  • Создать и настроить VIF/ifgrp
  • Настроить SnapMirror
  • …и так далее, всего 70 страниц.

Скачать можно тут: http://www.divshare.com/download/12748580-cab

Встроенный сниффер: pktt

В недрах OS Data ONTAP скрывается много удивительных гитик.
Вот, например, в каждой системе хранения NetApp, вернее в ее OS, имеется встроенный сниффер, запускаемый командой pktt, и собирающий дамп с интерфейса для последующей разборки, в формате стандартного юниксного tcpdump.

Использование:
pktt start {if | all} [-b bsize] [-d dir] [-s size] [-m pklen] [-v] [-i ipaddr] [-i ipaddr] …
pktt pause {if | all}
pktt dump {if | all} [-d dir]
pktt stop {if | all}
pktt status [{if | all}] [-v]
pktt delete [filename.trc]+
pktt list

Команда pktt управляет простым встроенным средством сбора ethernet-трафика. Пакеты захватываются с указаного интерфейса в специальный trace buffer, и после этого записываются в файл на диске. Данные записываются в формате “tcpdump”, который может быть прочитан разнообразными средствами, такими как tcpdump, ethereal (wireshark), и прочими программами-анализаторами и просмотрщиками. Вывод можно также конвертировать (утилитой editcap) в различные другие употребимые форматы, например для Sniffer, NetMon, и snoop.

pktt может захватывать пакеты для всех поддерживаемых типов медиа.

pktt start {if | all} [-b bsize] [-d dir] [-s size] [-m pklen] [-v] [-i ipaddr] [-i ipaddr] …

Команда start запускает трассировку, (или рестартует ее, если pktt находился в положении paused). Данные собираются в память, и пишутся в кольцеой буфер в памяти в формате “tcpdump”. Опции могут быть следующие:

-b размербуфера
Устанавливает размер буфера, который может быть определен в килобайтах или мегабайтах, при задании ‘k’ или ‘m’ после числа. Если не определен, то будет равен 128K, если вы не задали также опцию -d, что немного, но может быть достаточно в ряде случаев. Если задана опция -d, то значение буфера по умолчанию равно 1M. Значение может быть от 8K до 32M, то в очень редких случаях стоит устанавливать его большим 1-2M. Максимальный объем пространства, доступного pktt в памяти, равен 64M.

-d директория
Определяет путь к существующей директории, куда будет записан файл дампа. Файл будет иметь имя “if.trc” где”if” это имя интерфейса (например e0, fa3, и так далее.). Если опция не указана, то данные будут собиратся только в памяти, и после его заполнения, данные будут перезаписываться по кругу. Однак в любой момент можно сбросить содержимое буфера на диск с помощью команды pktt dump. Обратите внимание, что если система не будет успевать записывать все пакеты, то будет расти показатель счетчика “dropped” в выводе статуса pktt. Помните, что запись дампа всего трафика на диск может вызвать значительную нагрузку на запись для системы, и замедлить ее работу, поэтому, если это возможно, всегда ограничивайте область трассировки определенными IP-адресами и интерфейсами. Кроме этого, если вам не нужно сохранять содержимое всего пакета, то вы можете обрезать его командой -m.

Имейте ввиду, что любой существующий файл .trc будет молча перезаписан при выполнении этой команды.

-s размер
Эта опция позволяет вам задать максимальный размер файла дампа. Величина может быть задана с указанием “k”, “m”, или “g”. По умолчанию - 1G. Этот параметр всегда используется вместе с опцией -d. После достижения максимального лимита по размеру, пакеты продолжают собираться в буфер, но уже не пишутся на диск.

-m длинапакета
Этот параметр задает длину обрабатываемых пакетов (обрезая все что выходит за заданные пределы). По умолчанию - 1514 байт, что подходит для обычного ethernet, но может быть недостаточно для gigabit ethernet с использованием jumbo frames. Иногда может быть использован для ситуаций, когда не обязательно сохранять полное содержимое пакета. Однако, во многих случаях полезно сохранять полное содержимое всего пакета. В этом случае, если пакеты имеют размер свыше 1514 байт, вы можете задать желаемый максимум. Имейте виду, что некоторые декодеры (как пример - snoop) не обрабатывают пакеты более 1514 байт. Декодер ethereal/wireshark не имеет такой проблемы.

-i ipaddr [-i ipaddr] …
Эта опция включает простую возможность фильтрации. Можно задать до чтырех IP-адресов, для которых (на которые и с которых) будет записываться трафик. Это, кроме всего прочего, ограничит записываемый трафик только IP-пакетами, то есть в него не попадут пакеты, например arp/rarp, и прочие подобные.

pktt pause {if | all}
Команда “pause” приостанавливает сбор трафика с указаных интерфейсов. Незаписанные данные в буфере сбрасываются на диск. С помощью команды pktt start без других опций, можно возобновить сбор данных.

pktt dump {if | all} [-d dir]
Команда dump вызывает сброс содержимого кольцевого буфера в памяти в файл на диске. Если задана опция -d dir, то файл будет создан в указанной директории, в противном случае - в корневой директории root volume. Имя файла всегда равно if.trc (где if это название интерфейса), и содержимое записывается в формате “tcpdump”. Если файл уже существует, то он будет молча перезаписан.

pktt stop {if | all}
Эта команда выполнит остановку сбора дампа для всех заданных (или вообще всех) интерфейсов. Если вы пишете на диск, то все незаписанные на этот момент данные в буфере будут сброшен на диск. Если вы не задали файл записи дампа, то все данные в буфере будут потеряны. Это действие не требует подтверждения, так что будьте аккуратны.

pktt status [{if | all}] [-v]
Эта команда покажет вым состояние буфера и файла дампа для действующей трассировки. Используя “pktt status -v” вы получите полный статус всех интерфейсов.

pktt delete [filename.trc]+
Эта команда позволит вам удалить один или неколько файлов дампа в корневой директории. Длжен быть указан хотя бы один файл.

pktt list
Показывает список всех файлов трассировки в корневой директории.

Примеры:
pktt start e0
Эта команда начинает захват трафика с интерфейса “e0″. Весь трафик пищется в кольцевой буфер, размером 128K. Или же, если предыдущая команда приостановила сбор дампа, то она его возобновит.

pktt start fa3 -d / -s 100m -b 2m
Эта команда начинает захватывать дамп трафика на интерфейсе “fa3″, и писать в файл под названием “/fa3.trc” которому будеи позволено расти до максимальног размера в 100MB, с использованием буфера в 2MB.

pktt start el10 -d /home -m 10k -b 500k -i ehost1 -i ehost2
Эта команда начинает захватывать пакеты на и с определенных хостов, в данном примере “ehost1″ и “ehost2″ записывая их в файл “/home/el10.trc”. Пакеты размером до 10K записываются в буфер, размером 500K buffer. Отметьте, это будет работать только в том случае, если имена заданных хостов будут успешно резолвиться в DNS.

pktt start all -b 128k -i 172.20.4.1
Все интерфейсы начинают записыват дамп трафика на и с определенного IP-адреса. Это простой и быстрый способ посмотреть трафик, сли вы не уверены в том, какой интерфейс используется, но хотите увидеть пакеты с одного или более адресов IP.

21/0.590