Использовать код можно при регистрации на VMworld по следующему адресу:

http://www.vmworld.com/registration.jspa?sponsorCode=NAPP

Просто введите один из этих кодов при завершении покупки билета:

San Francisco code: NETAPP_EB_US2010
Copenhagen code: NETAPP_EB_EMEA2010

Дополнение: Как пишет Nick Howell, дисконт NetApp работает и “задним числом”, то есть, если вы уже приобрели билет за полную цену, вы можете получить вашу скидку, послав запрос по email: VMworld2010Registration@vmware-events.com.

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

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

Именно для этого такие разделы данных объединяют в логическую структуру под названием Consisency Group, операции над которой следует рассматривать “в целом”, либо целиком успешными, либо целиком неудачными и “откаченными”.

Итак, Consistency Groups на NetApp. Какова же ситуация сегодня на самом деле?

Consistency Groups на системах NetApp FAS существуют с версии Data ONTAP 7.2, однако работа с ними со стороны хоста производится через специальный API (ZAPI), который предоставляет, например, ПО SnapDrive. Работать с Consistency Groups можно как непосредственно из SnapDrive (UNIX/Windows), так и вызывая средства API из скриптов, например на Perl.

В рамках этого API так называемый “агент” (это может быть или собственный “высокоуровневый” продукт NetApp, например SnapManager for Oracle, SnapCreator, или же оперирующий вызовами API самодельный скрипт):

• Отдает команду участвующим в процессе контроллеру (или контроллерам, если наша consistency group расположена на разных контроллерах): start-checkpoint.
• Контроллеры приостанавливают (fence) процесс записи на тома, входящие в заданную consistency group (CG).
• Контроллеры подготавливают snapshot для указанных томов.
• Агент получает уведомление fence-success от всех участвующих контроллеров
• Агент отдает команду commit-checkpoint всем участвующим контроллерам
• Приняв команду контроллеры производят одновременное создание снэпшотов томов в CG
• По завершении контроллеры рапортуют об успешном завершении и снимают блокирование записи (unfence).

В случае использования интефейса SnapDrive команда создания снэпшота, использующая CG очень проста.
Допустим, у нас есть база данных (/u01/oradata/prod), расположенная на LUN-ах, лежащая на томах двух контроллеров – filer1 и filer2 (filer1:/vol/prodvol1 и filer2:/vol/prodvol1). Тогда процесс создания консистентной копии в снэпшоте с использованием snapdrive будет прост:

> snapdrive snap create -fs /u01/oradata/prod -snapname snap_prod_cg

Эта команда автоматически инициирует все процессы для всех задействованных в файловой системе /u01/oradata/prod LUN-ов, скомандует их контроллерам, и создаст консистентную копию с именем snap_prod_cg.
Аналогичным образом сработает команда для консистентной копии двух разных файловых систем (u01 и u02):

> snapdrive snap create -fs /u01/oradata/prod /u02/oradata/prod -snapname snap_prod_cg

Так что утверждение, что, якобы, на NetApp нет consistency groups действительности не соответствует. Они есть, работают, и достаточно активно используются, а утверждающим это специалистам конкурентов стоит обновить свои знания о состоянии дел в продукции конкурентов.

Подробнее о Consisency Groups и работе с ними в контексте Oracle:
TR-3858: Using Crash-Consistent Snapshot Copies as Valid Oracle Backups
Очень полезный документ о работе со снэпшотами баз Oracle, использования их как резервных копий, восстановления из них, в том числе много рассматривается тема consistency groups.
Одним из авторов документа является “гуру” темы использования NetApp под Oracle, сотрудник бразильского офиса – Neto, автор весьма интересного (и что еще лучше – регулярно пополняемого) блога на сайте NetApp.

Давайте на примерах разберем “что есть что”, где и как.

У нас есть том vol1 на 100G, практически пустой.

fas3020a> df -h vol1
Filesystem               total       used      avail capacity  Mounted on
/vol/vol1/               80GB       17MB       79GB       0%  /vol/vol1/
/vol/vol1/.snapshot      20GB       61MB       19GB       0%  /vol/vol1/.snapshot
 
fas3020a> snap list vol1
Volume vol1
working…
 
  %/used       %/total  date          name
———-  ———-  ————  ——–
31% (31%)    0% ( 0%)  Mar 08 00:00  nightly.0
47% (29%)    0% ( 0%)  Mar 07 20:00  hourly.0
57% (32%)    0% ( 0%)  Mar 07 16:00  hourly.1
64% (29%)    0% ( 0%)  Mar 07 12:00  hourly.2
69% (32%)    0% ( 0%)  Mar 07 08:00  hourly.3
73% (29%)    0% ( 0%)  Mar 07 00:01  nightly.1
76% (30%)    0% ( 0%)  Mar 06 20:00  hourly.4
78% (31%)    0% ( 0%)  Mar 06 16:00  hourly.5

В этом выводе, колонка %/used показывает объем, занятый снэпшотами, деленный на количество использованных в настоящий момент блоков на томе, независимо от того, заняты ли они в активной файловой системе, или снэпшотах. Первое число – накопительная сумма для всех показанных снэпшотов. Второе число (в скобках) – только для конкретного снэпшота.

Снэпшоты тома vol1 занимают 78% всех занятых на томе блоков, каждый из снэпшотов занимает примерно 29-32% занятых блоков.

Колонка %/total показывает объем занятый снэпшотами, деленный на общий объем диска. Он включает в себя пространство для данных, плюс snapshot reserve, то есть все использованные и свободные блоки тома. На томе 100GB занято примерно 61MB в снэпшотах, что составляет менее 1% общего объема (поэтому значение – 0).
Значение (в скобках) вычисляется аналогично вышеприведенному для %/used.

Давайте посмотрим, как все изменится, если мы уменьшим размер тома vol1 со 100GB до 1GB.

fas3020a> df -h vol1
Filesystem               total       used      avail capacity  Mounted on
/vol/vol1/              819MB       17MB      801MB       2%  /vol/vol1/
/vol/vol1/.snapshot     204MB       61MB      143MB      30%  /vol/vol1/.snapshot

fas3020a> snap list vol1
Volume vol1
working…
 
  %/used       %/total  date          name
———-  ———-  ————  ——–
31% (31%)    1% ( 1%)  Mar 08 00:00  nightly.0
47% (29%)    1% ( 1%)  Mar 07 20:00  hourly.0
57% (32%)    2% ( 1%)  Mar 07 16:00  hourly.1
64% (29%)    3% ( 1%)  Mar 07 12:00  hourly.2
69% (32%)    4% ( 1%)  Mar 07 08:00  hourly.3
73% (29%)    4% ( 1%)  Mar 07 00:01  nightly.1
76% (30%)    5% ( 1%)  Mar 06 20:00  hourly.4
78% (31%)    6% ( 1%)  Mar 06 16:00  hourly.5

Теперь мы видим, что снэпшоты заняли большее относительное пространство на томе в целом (%/total), то есть занятых И пустых, но процент блоков в снэпшотах, относительно всех только занятых блоков на томе (%/used) остался неизменным.

Как всем этим полагается правильно пользоваться?

Величины %/used и %/total полезны при оценке того, насколько правильно выбрана величина snapshot reserve. Нехватка резерва приводит к тому, что снэпшоты “вылезают” за пределы резерва, и начинают занимать место в пространстве данных. Когда команда df показывает величину заняости диска больше 100% – это как раз такой случай: снэпшоты переполнили пространство резерва и начали заполнять пространство собственно данных. Это не страшно, особенно если для тома работает autogrow (и есть место на aggregate) или autodelete (и вы можете безболезненно удалить некоторые старые снэпшоты), но, тем не менее, этого следует избегать для более однозначной организации данных.

Когда вы решаете удалить тот или иной снэпшот, рекомендуется пользоваться командой snap delta или snap reclaimable, чтобы выбрать наиболее эффективный с точки зрения освобождения места снэпшот.
Число после точки в имени снэпшота увеличивается со взятием нового снэпшота. Например, сли вы берете снэпшот каждый час, то hourly.1 взятый в 9 утра, станет hourly.5 в 13:00. Также это работает и в случае daily- или weekly-снэпшотов.
Обратите внимание, что снэпшоты с явно заданным именем (то есть не те, что создаются по расписанию), а также снэпшоты, созданные SnapMirror и SnapVault не изменяют своего имени при создании новых.

Да, это то что вы подумали. Начиная с Data ONTAP 7.3.3 и 8.0.1 на WAFL теперь работает компрессия (лицензия бесплатна, как iSCSI, или дедупликация, например), причем использование компрессии не отменяет и не заменяет, и может использоваться как совместно с дедупликацией, так и по отдельности. Это такая же знакомая и привычная онлайн-компрессия как на NTFS, например.

Компрессия пригодится в случаях, когда на диске лежат различные по содержимому данные, но не слишком дублирующиеся внутри на уровне 4KB-блоков WAFL. Тем не менее содержимое этих файлов вполне может сжиматься классическими LZ-алгоритмами. Например у меня на ноутбуке папка Program Files диска C: сжата почти на 30% от ее, примерно 2GB, объема.
Хороший пример – homedir различных пользователей организации. Хотя в хоумдирах иногда и попадаются идентичные документы и файлы у разных людей, в основном же, как показывает практика, большая часть содержимого хоумдиров достаточно уникальна, и не слишком эффективно дедуплицируется. Однако вполне поддается традиционному zip-like сжатию с неплохими показателями.

Для 7.3.3 компрессия идет как PVR, то есть доступна по запросу, но запланирована как стандартная опция в 8.0.1, которая выйдет этой осенью.

Таким устройством оснащен и NetApp. Его встроенный watchdog непрерывно мониторит состояние системной платы, памяти и карт ввода-вывода. Каждые 10ms Data ONTAP сбрасывает го таймер. Если таймер не сброшен в течение 1,5 секунд, то отдается команда Level 1, по которой формируется прерывание высокого приоритета, и начинается операция core dump. Если и на перывание Level 1 не получено реакции, то через полсекунды инициируется hard reset и перезагрузка системы. В случае перезагузки по Level 2 core dump уже не создается, так как перезагрузка происходит “жестко”.

В случае, если ваш контроллер оснащен RLM или BMC, то эти события регистрируются, и отсылается сообщение Autosupport.

Отмечу, что даже в случае “жесткой перезагрузки”, если часть данных, поступивших в систему на момент зависания еще не была занесена на диски (например, зависание системы произошло в интервал между сбросом одной consistency point в WAFL и другой, или в момент такого сброса), они останутся в памяти NVRAM, и будут перенесены на диски после рестарта, при переходе системы в нормальное состояние. Таким образом, даже “жесткая” перезагрузка не приводит к повреждению файловой системы дисков (пока сохранятся состояние NVRAM, в случае полностью заряженой батареи это примерно неделя).

Пример сообщения о срабатывании watchdog (из логов RLM):

Sat Feb 20 14:51:49 MST [slcsdcna02: mgr.boot.reason_abnormal:ALERT]: System
rebooted due to a watchdog reset.
System Alert from RLM of slcsdcna02 (REBOOT (watchdog reset)) CRITICAL
Record 600: Sun Oct 18 13:02:50 2009 [Agent Event.warning]: FIFO 0×8FFF - Agent
DrWho, L1_WD_TIMEOUT asserted.

NetApp объявил о приуроченой к выпуску новой версии VMware vSphere 4.1 новой версии же своего популярного инструмента VCenter plugin – Virtual Storage Console v2.0

А кроме этого объявлена грядущая поддержка для объявленного VMware своего vStorage API – VAAI – vStorage API for Array Integration.

Поддержка появится в грядущей версии Data ONTAP 8.0.1 (7-mode), которую вместе с рядом обновлений в модельном ряде мы ожидаем уже этой осенью, будут поддерживаться следующие возможности VAAI:

Full Copy – система хранения будет уметь самостоятельно, по команде хоста проводить полное копирование данных, без необходимости гонять эти данные по сети или через SAN. Cейчас клонирование средствами VMware виртуальной машины  размером 10GB приводит к чтению 10GB с системы хранения хост-сервером, и записи назад этих 10GB на систему хранения, после введения поддержки VAAI это будет производиться самостоятельно стораджем, полный offload).

Block Zeroing – система хранения будет самостоятельно уметь заполнять нулями разделы данных по команде с хост-сервера, например при создании eager-zeroed thik-томов. Сейчас хост-сервер для заполнения нулями 10GB thik eager-zeroed vmdk посылает 10GB нулей на систему хранения по сети (SAN).

Hardware Assisted Locking – обеспечивает защиту метаданных кластерной VMFS, и, как результат, улучшает масштабируемость больших ферм серверов, использующих общий датастор. Этот API заменяет традиционные средства SCSI-2 locks и потенциально позволит использование датасторов и кластеров большего чем сейчас размера. В настоящее время максимальный размер кластера ESX/ESXi для View, в котором используются Linked Clones, равен 8 узлам.

Итак, поддержка VAAI в системах NetApp FAS объявлена в Data ONTAP 8.0.1 (7-mode), выходящем этой осенью, будут поддержаны VMFS по FC, iSCSI и FCoE, и VAAI будет работать в версиях VMware vSphere 4.1 Enterprise и Enterprise Plus.

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

Рассмотрим подробнее на рисунке.

Вы видите, что хост, подключающийся к LUN A по пути A, получает данные наиболее “прямым” образом. А хост, подключающийся через второй контроллер, по пути B, хотя и тоже может видеть данные LUN, но получает его данные неоптимально. Его запрос на данные проходит через второй контроллер (FAS B), кластерный интерконнект между контроллерами, попадает на первый контроллер, обрабатывается им, и отправляется к его “owned” дискам. Данные пойдут в адрес запросившего хоста в обратном порядке, с дисков к контроллеру-owner, затем по интерконнекту, на второй контроллер, и через его порты к запросившему хосту. В результате загружаются работой оба контроллера вместо одного, данные загромождают интерконнект, и производительность снижается.

В этом случае вы сможете наблюдать в логах сообщение вида:

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

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

Из операционных систем его поддерживают свежие Linux, MS Windows 2008 со своим DSM и VMware ESX4 (vSphere). Поддержка ALUA есть и в Data ONTAP от 7.3.1.

Рассмотрим, как включить использование ALUA в vSphere.

Убедитесь, что на системе хранения вы используете версию Data ONTAP от 7.3.1 и выше.

FAS1> version
NetApp Release 7.3.1.1: Mon Apr 20 22:58:46 PDT 2009

Включите флаг ALUA  для igroups ESX на каждом из контроллеров системы хранения

FAS1> igroup show -v vmesx_b
    vmesx_b (FCP):
        OS Type: vmware
        Member: 21:00:00:1b:32:10:27:3d (logged in on: vtic, 0b)
        Member: 21:01:00:1b:32:30:27:3d (logged in on: vtic, 0a)
        ALUA: No

FAS1> igroup set vmesx_b alua yes

FAS1> igroup show -v vmesx_b
    vmesx_b (FCP):
        OS Type: vmware
        Member: 21:00:00:1b:32:10:27:3d (logged in on: vtic, 0b)
        Member: 21:01:00:1b:32:30:27:3d (logged in on: vtic, 0a)
        ALUA: Yes

С помощью VMotion переместите все VM с данного хоста ESX на другие хосты кластера и перезагрузите данный сервер ESX.

После перезагрузки значение SATP (Storage Array Type) изменится на VMW_SATP_ALUA, а PSP (Path Selection Policy) на VMW_PSP_MRU. Вам нужно изменить PSP с VMW_PSP_MRU на VMW_PSP_RR. Сделать это можно двумя способами.

1. С помощью NetApp ESX Host Utilities Kit 5.1
#/opt/netapp/santools/config_mpath –m -a CtlrA:username:password -a CtlrB:username:password

После изменений вы получите соответствующее собщение и предложение перезагрузить ESX

2. Вручную
# esxcli nmp satp setdefaultpsp –satp VMW_SATP_ALUA –psp VMW_PSP_RR

Перезагрузка сервера ESX

Проверьте получившеся настройки

#esxcli nmp device

naa.60a9800050334b356b4a51312f417541
    Device Display Name: NETAPP Fibre Channel Disk (naa.60a9800050334b356b4a51312f417541)
    Storage Array Type: VMW_SATP_ALUA
    Storage Array Type Device Config: {implicit_support=on;explicit_support=off;explicit_allow=on;alua_followover=on;{TPG_id=2,TPG_state=AO}{TPG_id=3,TPG_state=ANO}}
    Path Selection Policy: VMW_PSP_RR
    Path Selection Policy Device Config: {policy=rr,iops=1000,bytes=10485760,useANO=0;lastPathIndex=3: NumIOsPending=0,numBytesPending=0}
    Working Paths: vmhba2:C0:T2:L1, vmhba1:C0:T2:L1

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

Использование Ethernet как среды передачи данных систем хранения становится все популярнее, однако задачи создания “сети хранения данных” с использованием ethernet предъявляют особые требования к стабильности и надежности работы сети. То что “прокатит” для раздачи интернета в офисе может “не прокатить” при создании сети IP-SAN или NFS для критически важных для бизнеса задач.

Если перед вами стоит задача организации такой сети передачи данных, хочу обратит ваше внимание на свежий перевод в библиотеке Netwell: TR-3802 Ethernet Storage Best Practices.

Как организовывать и настраивать транкинг VLAN? Как работает и чем полезен протокол Spanning Tree? Что такое, и как работает VIF – Virtual Interfaces в NetApp? Чем отличаются Single mode и Multi-mode VIF? Static и Dynamic Multimode VIF? Почему объединенные в etherchannel (ethernet-транкинг) порты могут не давать ожидаемой от этого объединения увеличения полосы пропускания? Как работают Jumbo Frames и Flow Control на уровне Ethernet, и как правильно его применять?

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

TR-3802 Ethernet Storage Best Practices.

PS. Кстати может быть полезен и не только пользователям NetApp.

По результатам недавно опубликованного отчета о тестировании производительности работы базы данных MySQL 5.0.56 (InnoDB) на сервере HP DL580 G5 под RHEL4, с использованием трех протоколов доступа – FC, iSCSI и NFS, к системе хранения FAS3070 можно оценить эффективность использования передачи данных по этим трем протоколам.

MySQL 5.0 Performance Protocol Comparison

При тестировании использовался открытый тестовый пакет генерации нагрузки DBT-2 Rel.40 (Database Test Suite), генерировавший нагрузку профиля OLTP (16K random read/write в пропорции 57% read/43% write) для базы объемом 100GB. Больше подробностей можно узнать из приведенного документа. Также приведены подробные описания конфигов и использованных настроек всех компонентов.

Для затравки – один из измеренных результатов.

Тестировние показало, что использование iSCSI дало снижение всего на 9%, а NFS – всего на 16% относительно взятой за максимум производительности на FC. Результаты показывают, что широко распространившееся во времена MySQL 3.23 мнение, что NFS в базах MySQL непригоден для использования, уже не соответствует действительности. 
Любопытно, что того же мнения теперь придерживаются и “с той стороны баррикад”, в Sun/Oracle:
”for MySQL on Linux over NFS, performance is great, right out of the box.”

Интересущимся рекомендую тщательно просмотреть отчет, там есть над чем подумать. Есть основания предполагать, что с более новым железом (все же FAS3070 это уже довольно старая система, c ONTAP 7.2.4) и с новым клиентским софтом (RHEL4, использовавшийся на хосте, имел ядро 2.6.9-42.EL.smp) разница может оказаться еще менее значительной.

Также интересующимся рекомендую обратить внимание на документы:

Linux (RHEL 4) 64-Bit Performance with NFS, iSCSI, and FCP Using an Oracle Database on NetApp Storage

Best Practices Guidelines for MySQL

1997 год, если не ошибаюсь одна из ранних моделей (F200 или F300*, судя по Wiki)

В самом низу, на полу, под 1U-сервером Dell – его дисковая полка – 8 дисков SCSI.

Когда-то у меня была чудная подборка фотографий “археологических” нетаппов, буквально от FASServer начиная, жаль пропала вместе со всеми файлами первой версии блога.

* Ошибся. Это F630. Машина проекта Godzilla. Топовая модель на тот момент. 500MHz Alpha AXP 21164A (Да, были и такие нетаппы, на Альфе!), 512MB RAM, 32MB NVRAM, 4328 попугаев по SPECsfs.
Вот еще немного фото:
сзади, спереди, контроллер

А вот кто угадает что такое стоит на этой фотографии слева? (справа обычный сервер):