about NetApp

Мы уже весь этот год понемногу говорим о новой для пользователей NetApp “классической”, 7-mode архитектуры, схеме Cluster-mode. В отрасли все еще довлеет определенный груз недоверия, Cluster-mode считается, во-первых,  дорогим (но о цене и спецпредложении двухузловой cluster-mode по цене HA-пары 7-mode, и о “Cisco Nexus за 1$” мы уже говорили ранее), сложным в развертывании и установке (но рекомендую сделать поиск по Techlibrary по слову “cluster-mode”) и имеющим значительный оверхед по производительности, в сравнении с системой 7-mode. ?? вот об этом последнем мы поговорим сегодня.

К моему глубокому сожалению некоторые такие предрассудки о производительности системы в Cluster-mode  разделяли и отдельные знакомые мне специалисты самого NetApp.

Поэтому так интересно было посмотреть на официально опубликованный отчет по измерению и сравнению производительности системы Cluster-mode и 7-mode.

Была протестирована производительность работы системы хранения FAS6240 под задачи четырехнодового Oracle RAC на OLTP нагрузке, под всеми поддерживаемыми протоколами, в конфигурации хранилища как 7-mode, так и Cluster-mode, в максимально идентичной конфигурации OS, базы, настроек оборудования. Для затравки вам картинка, остальное по ссылке на полный отчет с описанием методики тестирования.

Как вы видите, согласно этому тесту производительность Cluster-mode ниже аналогичной системы 7-mode не более чем на 7% в наихудшем случае, при, безусловно, значительно большем количестве возможностей, “фич” и перспективах масштабирования решения Cluster-mode.

Весьма любопытная попалась на глаза презентация о использовании систем хранения NetApp в CERN, для накопления, хранения и предоставления для работы с ними данных, поступающих с детекторов Большого Адронного Коллайдера (БАК, LHC).

Где-то до 15 страницы там идет все больше про адронный коллайдер, с данными котрого и работает система, и кратко о экспериментах, и генерируемых ими объемах данных, идущих на LRC (подробнее о том, что за эксперименты идут на LHC можно почитать на русском в заметке на Хабре) а дальше начинается уже и “наша” часть.

Вкратце: на 2010 год один только Large Hadron Collider (LHC, БАК) генерировал в ходе идущих на нем четырех параллельных экспериментов около 15 петабайт “сырых” данных в год, при сумммарной емкости хранилища свыше 50 петабайт, которые обрабатываются примерно 150 тысячами процессорных ядер в научных учреждениях по всему миру (проект GRID).

Это 2010 год, еще до всех cluster-mode, все довольно просто (если к такой работе можно вообще применять такое слово), и упомянутый в заголовке scalability и performance достигается простым 7-mode и Oracle RAC (10.2.0.5, позднее 11 в Oracle VM), Flash Cache и 10G Ethernet на midrange-class системах.

С 2006 года в CERN эксплуатируют системы хранения NetApp, Oracle на Linux_x64, в конфигурации RAC по NFS, и на момент создания презентации СУБД обслуживала 96 баз.

Так, например, база ACCLOG получала, на момент публикации презентации, примерно 3,5TB записей в месяц (или около 100GB в день), причем после запуска LHC объем входящих записываемых в базу данных вырос примерно вчетверо.

Любопытно, что все это обслуживают сравнительно маломощные стораджи FAS3040 и FAS3140 с дисками SATA 2TB и FC 10Krpm

Наиболее важными для CERN особенностями систем хранения NetApp в презентации называются:

• Хорошая поддержка и удобное администрирование систем.
• Высокий уровень масштабируемости и производительности, стабильности и беспроблемности кластерного файловера, а также непрерывающего работу обновления ПО контроллеров.
• Высокая надежность хранения и поддержания целостности данных (RAID-DP, scrubbing, checksum)
• Удобные и практичные фичи, такие, как snapshots.

Посмотреть PDF презентации можно тут:
http://openlab.web.cern.ch/sites/openlab.web.cern.ch/files/presentations/2010OOW-08.pdf

Нам пишут наши читатели:

Оригнал здесь, перепечатывается оттуда по согласию с автором: http://ua9uqb.livejournal.com/79872.html

Не так давно довелось мне протестировать две системы хранения данных, делюсь результатами. В тесте принимали участие системы начального уровня NetApp FAS2240 и Hitachi AMS2100.
Надо понимать, что системы эти сравнимы довольно условно, так как AMS - обычное, бедное по функционалу блочное хранилище, в отличии от сильно мозговитого, "всё-всё умеющего" NetApp-а. Конфигурации системы, методики тестирования, и прочие тюнинги, были согласованны со специалистами вендоров.

Немного подробностей по методике:
1. Тестирование проводилось программой IOMeter версии 2006.07.27 для Windows.

2. Подключение СХД Hitachi AMS2100 производится посредством FC4G, протокол FC
Cостав LUN и томов СХД
Raid10 8 x 450gb 15k 3.5’ Usable: 1.5Tb Lun: 700Gb
Raid6 8+2 450gb 15k 3.5’ Usable: 3.1Tb Lun: 700Gb

3. Подключение СХД NetApp FAS2240 производится посредством 10Ge, протокол iscsi
Состав LUN и томов СХД
RaidDP 9+2 x 600gb 10k 2.5’ Usable: 4.33Tb Lun: 700Gb

4. Тесты проводится в режиме файловой системы NTFS 4к, выравнивание партишина 64к;

5. Настройки программы IOMeter:
• Worker’s – 4
• Target – 16 (в каждом из Worker’s)
• Disk Size – 200000000 (100Gb)
• Ramp Up Time – 600 сек
• Run Time – 30 мин

6. Фиксация результатов каждого теста для IOMeter длиться 30 минут начиная с 10-й и заканчивая 40-й минутой теста;

7. Профили нагрузок(название профилей условное), используемые для тестирования IOMeter следующие: 
Нагрузка характерная для приложений ORACLE 
• размер блока 8КБ;
• соотношение количества операций чтения/запись 30/70;
• характер нагрузки – 100% случайный доступ;

Нагрузка характерная для VMware:
• размер блока 4КБ;
• соотношение количества операций чтения/запись 40/60;
• характер нагрузки – 45% линейный и 55% случайный доступ;

Нагрузка характерная для операций Backup:
• размер блока 64КБ;
• 100% последовательное чтение;

??тог:

Табличка довольно прозрачная, поэтому никаких выводов делать не буду.
NetApp FAS2240(в центре, где куча вертикальных планочек, и жёлтая наклейка сверху):

Hitachi AMS2100

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

PPS. Пост навеян коментом френдессы balorus к посту про сервер Sun T4-4 :-)

PPPS. Мой выбор был бы NetApp, если бы Хитача в те же деньги не уложила сильно больше шпинделей. А так же не ещё один сильно политический нюанс, который очень сложно перебить даже теми волшебными, и крайне необходимыми нам штуками, которые NetApp умеет делать очень хорошо, а AMS не умеет в принципе.

Некоторое время назад по IT-новостям прокатилось сообщение что “Система хранения Oracle 7320 победила в тестах NetApp FAS3270!! адинадин”. На прошлой неделе у меня дошли руки посмотреть все же что там, как, кто, и кого победил. О результатах рассказываю.

Тема “тестирований производительности” (кавычки мои, romx) есть любимая тема любого сисадмина.

Допустим, вы читаете в новостях сообщение, что “Мотоцикл Honda CBR150 обошел на стометровке с места болид Formula1 Ferrari!”. “Ну, круто” – подумаете вы, “но кому интересно соревнование с формульным болидом на стометровке с места? Они бы еще соревновались по параметру “экономия бензина” с велосипедом!” А вот нет, оказывается, прекрасная новость и информационный повод проспамить прессрелизом IT-издания.

Уже не раз в этом блоге я писал, что “дьявол – в деталях”, “всегда читайте мелкий шрифт”, и не ограничивайтесь одними лишь заголовками смотрите вглубь, мы – инженеры, именно за умение смотреть вглубь и читать портянки текстов на английском нам платят наши деньги.

Но, для начала, несколько вводных слов.

Тестирование – тема очень непростая. Очень важный аспект в любом бенчмарке это создание повторяемой среды, отражающей реальные условия использования тестируемого предмета. Результаты процесса “копирования ISO в тотал коммандере”  совершенно неприменимы для оценки быстродействия системы хранения на задаче OLTP database, а данные чисто “синтетического” теста могут не отражать адекватно ваши реальные рабочие результаты, на вашей реальной рабочей задаче, в жизни.

Но если в том что касается бенчмарка, то есть создания повторяемой среды тестирования идентичной для всех тестирующихся систем, можно положиться на авторитет общепризнанных тестов, каковыми на сегодня являются, например SPECsfs2008 для файловых протоколов (NFS и CIFS), и SPC-1 для блочных протоколов (FC и iSCSI), то вот в подготовке тестируемой системы есть некоторая свобода, которой иногда (довольно часто, к сожалению) пользуются некоторые производители с целью создать “систему хранения”, единственная цель которой – победа в тестировании. В англоязычном сегменте такое называется lab queen, по-русски я слышал название “звездолет”.

Вариантов как построить звездолет есть масса. Например можно взять хай-энд систему и набить ее SSD, получив систему за шесть миллионов долларов на 19TB usable . Можно поставить вместе четыре стораджа, и в результатах тупо просуммировать показанные ими по отдельности результаты. Можно, наконец, тестировать систему на голых дисках без RAID или на RAID-0. ??спользовать множество дисков малого объема. Разбить пространство тестирование на большое количество мелких разделов, снижая “разбег” random access seek, и так далее. Полученные таким образом результаты окажутся неприменимыми в реальной жизни и в реальной эксплуатации того, что вы можете купить, однако очень эффектно смотрятся в пресс-релизах об очередной победе.

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

А теперь перейдем собственно к теме. Что же скрывает за собой барабанная дробь прессрелиза?

Согласно требованиям проведения тестирования SPECsfs2008, протестированная конфгурация должна быть хорошо и детально документирована и описана. Эти данные доступны на сайте SPEC.org всем желающим. Пожелаем и мы проверить, какую же в точности конфигурацию тестировали в Oracle.

Вот как описывает протестированную конфигурацию сайт SPEC.org:
http://www.spec.org/sfs2008/results/res2012q1/sfs2008-20120206-00207.html

Система Oracle Sun ZFS storage 7320

136 дисков SAS 15K на 300GB в 6 дисковых полках, обшим usable space емкостью 37,1TB и общей экспортируемой емкостью в 36,96TB были поделены на 32 файловые системы, по 16 на каждый из двух контроллеров (каждая экспортируемая FS имела размер примерно 1,1TB), доступ к которым осуществлялся с трех loadgenerator Sun Fire X4270 M2, подключенных по 10G Ethernet.

Также тестированный сторадж оснащен 8 дисками SSD по 512GB каждый, для кэширования чтения, (так называемый L2ARC), общей емкостью 4TB, пополам на каждом из двух контроллеров, и 8 дисками SSD 73GB в качестве кэша записи (ZIL), суммарно 584GB, без RAID в обоих случаях. Кроме этого, два контроллера системы хранения имели RAM емкостью 288GB (ARC, по 144GB на контроллер), что дает 4968GB суммарной емкости кэша (SSD и RAM).

Суммарная, участвующая в тестировании емкость (fileset) составила 15587,3 GB, то есть емкость кэша составила примерно треть от используемого файлсета.

Далее цитата:
The storage configuration consists of 6 shelves, 4 with 24 disk drives, 2 with 20 disk drives and 4 write flash devices. Each controller head has 4 read flash accelerators. Each controller is configured to use 68 disk drives, 4 write flash accelerator devices and 4 read flash accelerator devices. The controller is then set up with pools by dividing the disk drives, write flash accelerators and read flash accelerators into 4 pools. Each of the controller’s pools is configured with 17 disk drives, 1 write flash accelerator and 1 read flash accelerator. The pools are then set up to stripe the data (RAID0) across all 17 drives. The write flash accelerator in each pool is used for the ZFS Intent Log (ZIL) and the read flash accelerator is used as a level 2 cache (L2ARC) for the pool. All pools are configured with 4 ZFS filesystems each.

“Конфигурация системы хранения содержала 6 дисковых полок, 4 полки на 24 диска и 2 полки на 20 дисков, плюс 4 SSD-кэша на запись. Каждый контроллер использовал 4 SSD-диска в качестве кэша чтения. Каждый контроллер был сконфигурирован на работу с 68 дисками, 4 SSD кэша на запись и 4 SSD кэша на чтение. Каждый контроллер использовал пулы дисков, между которыми были разделены диски, по одному SSD-кэшу на чтение и на запись на каждый пул. Пулы были настроены таким образом, чтобы данные страйпились на все входящие в него 17 дисков (RAID-0). Write flash accelerator (SSD емкостью 73GB) в каждом пуле использовался в качестве ZFS Intent Log (ZIL), а read flash accelerator (SSD емкостью 512GB) как level 2 cache (L2ARC). На каждом из пулов было создано по 4 файловые системы.”

Как мы видим, несмотря на использование ZFS, для организации дисков в пулах был выбран простой stripe, без RAID (фактически RAID-0!). Кроме того стоит отметить, что общая тестируемая емкость дисков была поделена на сравнительно маленькие файловые системы, всего около 1,1TB каждая, числом 32 (зачем такой финт – см. выше).

Очевидно, что такая конфигурация довольно далека от реально эксплуатируемой на такого рода системах. Кто в здравом уме будет класть данные на 17-дисковую группу в RAID-0?! А как планируется использовать пространство, разбитое на 32 отдельных FS для хранения, например, больших объемов? А каковы 512GB write cache на SSD, без малейшей защиты от сбоя?

Кстати интересный вопрос: Если ZFS так хороша и производительна, и так хорош RAID-Z и RAID-Z2, то почему его не использует при выкатке систем на тестирование даже сам Oracle? Что за засада с ним, господа из Oracle? Вот NetApp показывает свой результат на реальных, эксплуатируемых конфигурациях, с RAID-DP и даже со включенным thin provisioning, а в результатах Oracle в SFS2008 – Stripe (RAID-0), а в SPC-1 – mirror (RAID-1). Почему не RAID-Z(2)? Почему бы не показать результаты с ними? Может быть они совсем не так хороши?

Для сравнения давайте посмотрим на упомянутую конфигурацию NetApp FAS3270, которую “побеждали”.

FAS3270 в конфигурации с SAS-дисками и без Flash Cache, поставки таких систем начались в ноябре 2010 года, около полутора лет назад.

360 дисков 450GB 15K, общая usable емкость дисков 125,7TB (в RAID-DP), экспортированная емкость равна 110,08TB (88% от usable) в 2 файловых системах (по одной на контроллер). Диски организованы в два aggregate из 11 RAID-групп 14d+2p в RAID-DP (RAID-6),  тестовая нагрузка генерировалась с помощью 12 Loadgenerators типа IBM 3650M2.

Exported capacity равна 110TB, файлсет, на котором проводилос тестирование - 11749.7 GB  Размер RAM, используемого как кэш на системе хранения, равен 36GB, что составляет 1/326 от fileset.

SPECsfs2008_nfs.v3=101183 Ops/Sec (Overall Response Time = 1.66 msec)

У “победившей” его полтора года спустя системы с RAID-0, с кэшами разного уровня, составляющими суммарно до трети тестируемого файлсета, включая около 4,5TB на SSD, с в шесть раз большим RAM контроллера и с тестируемым пространством побитым на 32 кусочка-FS:

SPECsfs2008_nfs.v3=134140 Ops/Sec (Overall Response Time = 1.51 msec)

На 32,5% больше IOPS и на 8,5% лучше latency.

Ребята из Oracle, что называется "при всем уважени”, но вы правда считаете, что таким результатом, при описанном выше устройстве тестируемой системы, и способе проведения тестирования, это победа и этим стоит гордиться? Нет, ну правда?

Оно дешевле стоит? Ну, согласен, дешевле. Мотоцикл порвал Феррари на стометровке. Но кто гоняет на Феррари на стометровке? Какой смысл сравнивать по цене лоу-мидрендж (“Entry-level cluster option for high availability”, цитата из техспеков на 7320), ZFS-сервер, со стораджем, в максимуме тянущем в 6,6 раз большую чем 7320 емкость, используещем RAID-6, и демонстрируемом даже близко не на пределе своих возможностей по тестируемой емкости?

Впрочем, несколько слов и о цене. В тесте SPECsfs2008 условия тестирования не требуют называния цены тестируемой системы, поэтому спекуляции о цене делаются на довольно мутном базисе “нашли гуглом какой-то прайс нетаппа, где-то в интернете, и прикинули”. Однако в случае SPC-1 требуется указывать такой параметр, как IOPS/$ и цена всей тестируемой конфигурации называется. Тут, однако, тоже есть поле для… ну-у… скажем так, для “оптимизации” :). Например на тестировании SPC-1 NetApp называет цену листпрайса (см стр. 18 отчета), а Oracle, ничуть не смущаясь приводит цену с “вшитой” 30% скидкой по всем позициям (см. стр. 14 отчета) и именно ее берет в расчете IOPS/$ в SPC-1.

Так что, повторю сказанное мной в начале поста: Читайте мелкий шрифт, не ленитесь разбираться в конфигурациях и их деталях, и оставьте пресс-релизы (и выводы только на их основании) для С*O-менеджеров. :)

Сегодня у нас снова перевод короткой заметки Neto – технического архитектора NetApp, занимающегося вопросами работы с базами данных Oracle.

Playing with Calibration IO - Oracle 11g

Posted by neto on Aug 11, 2011 2:37:40 AM

Oracle 11g имеет интересную возможность эмулировать ввод-вывод (случайное чтение большими блоками (1MByte)). Это называется Calibration IO - http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/iodesign.htm

Давайте проделаем небольшой тест с помощью этого средства.

1) Проверяем, что все файлы данных используют asynchronous IO:

col name format a50
select name,asynch_io from v$datafile f,v$iostat_file i where f.file#=i.file_no and (filetype_name=’Data File’ or filetype_name=’Temp File’);
NAME                                               ASYNCH_IO
————————————————– ———
/oracle/databases/prod/data/system01.dbf           ASYNC_ON
/oracle/databases/prod/data/system01.dbf           ASYNC_ON
/oracle/databases/prod/data/sysaux01.dbf           ASYNC_ON
/oracle/databases/prod/data/undotbs01.dbf          ASYNC_ON
/oracle/databases/prod/data/users01.dbf            ASYNC_ON
/oracle/databases/prod/data/soe.dbf                ASYNC_ON


2) Запускаем Calibration IO


SET SERVEROUTPUT ON
DECLARE
  lat  INTEGER;
  iops INTEGER;
  mbps INTEGER;
BEGIN
– DBMS_RESOURCE_MANAGER.CALIBRATE_IO (<DISKS>, <MAX_LATENCY>, iops, mbps, lat);
   DBMS_RESOURCE_MANAGER.CALIBRATE_IO (2, 10, iops, mbps, lat);
  DBMS_OUTPUT.PUT_LINE (’max_iops = ‘ || iops);
  DBMS_OUTPUT.PUT_LINE (’latency  = ‘ || lat);
  dbms_output.put_line(’max_mbps = ‘ || mbps);
end;


3) Смотрим на стороне NetApp:


[root@dl585-10 ~]# ssh 10.61.106.103 sysstat 1
CPU    NFS   CIFS   HTTP      Net kB/s     Disk kB/s      Tape kB/s    Cache
                               in   out     read  write    read write     age
21%   2987      0      0    2848 102705    86688      0       0     0       2s
26%   2955      0      0    2833 101569    85000      0       0     0       2s
21%   2879      0      0    2768 98919     77168      0       0     0       3s
21%   2964      0      0    2810 101982    82673      0       0     0       3s
21%   3952      0      0    2807 111602    85412   6064       0     0       3s
21%   2894      0      0    2729 97518     79832      0       0     0       2s
22%   3033      0      0    2877 104390    92552      0       0     0       2s
20%   2825      0      0    2674 97233     81780      0       0     0       2s
21%   2808      0      0    2696 96510     81396      0       0     0       2s


4) Результаты Calibration IO:

max_iops = 5570
latency = 10
max_mbps = 110

110 Mегабайт в секунду, довольно неплохо для одного 1Gbit интерфейса с сервера Oracle на NetApp!

Уже цитировавшийся в этом блоге специалист по Oracle и блоггер NetApp с ником Neto (ранее из Бразилии, а теперь сотрудник датацентра NetApp в Triangle Park, USA), опубликовал результаты интересного эксперимента, демонстрирующие возможности и производительность NFS на системах хранения NetApp. Ниже перевод его заметки.

Не могу поверить… Еще остались люди, которые не верят в производительность на NFS

Posted by neto on Oct 8, 2011 5:23:41 AM

Многие годы я получаю много вопросов и FUD на тему того, что, якобы, NFS не обеспечивает достаточно  хорошую производительность.

Давайте смотреть.

Linux CentOS 6 с двумя портами 10Gb Ethernet (Jumbo Frames ON)

NFS v3

NetApp Cluster – каждый с одним интерфейсом 10Gb Ethernet (Jumbo Frames ON)

Cisco Nexus Switch

Я создал  4 файла на каждой mountpoint:

Запускаем ORION…

http://www.oracle.com/technetwork/topics/index-089595.html

ORION (Oracle I/O Calibration Tool) это инструмент для тестирования и калибровки показателей производительность ввода-вывода системы хранения, намеченной для использования под базы Oracle. Результаты полезны для понимания возможностей системы хранения по производительности, а таже для поиска проблем, которые могут отражаться на производительности базы Oracle, или же для сайзинга нвой инсталляции. Так как ORION это отдельный инструмент, то для проведения измерений пользователям не требуется создавать и запускать базу Oracle.
ORION генерирует синтетичекую нагрузку ввода-вывода максмально приближенную к работе базы данных Oracle, и использует тот же I/O software stack, что и Oracle. ORION может быть сконфигурирован на генерирование широкого диапазона нагрузки ввода-вывода, включая нагрузки характерные для OLTP и data warehouse.

./orion_linux_x86-64 -run advanced -testname disk1 -num_disks 64 -matrix point -num_small 0 -num_large 1 -size_large 1024 -type seq -num_streamIO 8 -write 0 -simulate raid0 -cache_size 0 -duration 60 &

./orion_linux_x86-64 -run advanced -testname disk2 -num_disks 64 -matrix point -num_small 0 -num_large 1 -size_large 1024 -type seq -num_streamIO 8 -write 0 -simulate raid0 -cache_size 0 -duration 60 &

./orion_linux_x86-64 -run advanced -testname disk3 -num_disks 64 -matrix point -num_small 0 -num_large 1 -size_large 1024 -type seq -num_streamIO 8 -write 0 -simulate raid0 -cache_size 0 -duration 60 &

./orion_linux_x86-64 -run advanced -testname disk4 -num_disks 64 -matrix point -num_small 0 -num_large 1 -size_large 1024 -type seq -num_streamIO 8 -write 0 -simulate raid0 -cache_size 0 -duration 60 &

Копируем скриншоты…

Controller 1

Controller 2

Server

Я полагаю, что 2 гигабайта (БАЙТА!) в секунду, этого должно хватить! Так-то. :-)

NFS это хорошо (на NetApp, конечно же).

Всех благ!

Neto

??нтересный отчет опубликовала сегодня тестовая лаборатория NetApp, анализировавшая производительность Oracle 11g на RHEL и системе хранения NetApp.

Для затравки вам картинка:

Полностью читать – там:
Red Hat Enterprise Linux Protocol Performance Comparison with Oracle Database 11g Release 2
http://www.netapp.com/us/library/technical-reports/tr-3932.html

Довольно долго наблюдаю, как некоторые конкуренты NetApp указывают на то, что системы хранения NetApp якобы лишены механизма Consistency Groups. Для начала, что такое Consistency Group как таковое.

В опеределенных задачах, например в базах данных, при репликации или создания снпшотов, необходимо оперировать двумя и более разделами данных (это могут быть, например, 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.

Уверен, вы уже знакомы с черезвычайно полезны ресурсом на сайте NetApp, сборником справочной литературы, Best Practices, и рекомендаций по многочисленным областям применений систем хранения NetApp. Расположен он вот по этому адресу: http://www.netapp.com/us/library/

А ниже собраны для примера все документы NetApp касающиеся только одного продукта – СУБД Oracle.

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

NetApp Best Practices
http://media.netapp.com/documents/tr-3369.pdf  Best Practices for Oracle (through 10g)
http://media.netapp.com/documents/tr-3633.pdf  Best Practices for 11g
http://media.netapp.com/documents/tr-3761.pdf  Best Practices for SnapManager 3
http://media.netapp.com/documents/tr-3426.pdf  SnapManager with 10g RAC Grid
http://media.netapp.com/documents/tr-3442.pdf  SAP on Unix and Oracle with NFS
http://media.netapp.com/documents/ra-0002.pdf  Test/Dev Reference Architecture with Data Guard
http://media.netapp.com/documents/tr-3803.pdf  Oracle VM Best Practices

Performance
http://media.netapp.com/documents/tr-3700.pdf  Oracle 11g Protocol Performance on Linux
http://media.netapp.com/documents/tr-3495.pdf  Storage Protocol Performance on Linux
http://media.netapp.com/documents/tr-3408.pdf  Storage Protocol Performance on AIX
http://media.netapp.com/documents/tr-3496.pdf  Storage Protocol Performance on Solaris
http://media.netapp.com/documents/tr-3322.pdf  Oracle NFS Performance on Solaris
http://media.netapp.com/documents/tr-3557.pdf  HP-UX NFS Performance on 10g
http://media.netapp.com/documents/tr-3357.pdf  Oracle 9i RAC OLTP performance on iSCSI
http://media.netapp.com/documents/tr-3753.pdf  OLTP Performance with NetApp Performance Acceleration Module
http://media.netapp.com/documents/tr-3622.pdf  11g Single Instance Sequential Workload Performance with DNFS and iSCSI on Windows
http://media.netapp.com/documents/tr-3628.pdf  Sequential Workload Performance with iSCSI and NFS

Data Protection
http://media.netapp.com/documents/tr-3520.pdf  SAP Data Protection for Unix on Fibre Channel
http://media.netapp.com/documents/tr-3211.pdf  Data Protection for 9i on Windows
http://media.netapp.com/documents/tr-3368.pdf  Data Protection for 10g on Asianux
http://media.netapp.com/documents/tr-3377.pdf  Oracle with NetApp Open Systems SnapVault (OSSV)

Applications
http://media.netapp.com/documents/tr-3444.pdf  SAP on Microsoft Windows with NetApp
http://media.netapp.com/documents/tr-3533.pdf  SAP on Unix with Fibre Channel
http://media.netapp.com/documents/tr-3391.pdf  Oracle E-Business Suite on NetApp
http://media.netapp.com/documents/tr-3797.pdf  SAP TDMS (Test Data Migration Server) on NetApp
http://media.netapp.com/documents/tr-3300.pdf  Cloning Oracle E-Business Suite with SnapMirror
http://media.netapp.com/documents/tr-3366.pdf  SAP Data Protection on Oracle on Windows
http://media.netapp.com/documents/tr-3365.pdf  SAP Data Protection on Unix and NFS
http://media.netapp.com/documents/tr-3672.pdf  Fusion Middleware Disaster Recovery

Real Applicaiton Clusters
http://media.netapp.com/documents/tr-3572.pdf  Oracle 10gR2 NFS Setup
http://media.netapp.com/documents/tr-3572.pdf  Oracle 10g RAC with ASM on NFS
http://media.netapp.com/documents/tr-3349.pdf  Oracle 10g RAC with ASM on iSCSI
http://media.netapp.com/documents/tr-3189.pdf  Oracle 9i RAC on Red Hat 3
http://media.netapp.com/documents/tr-3413.pdf  Oracle 10g RAC on SUSE
http://media.netapp.com/documents/tr-3536.pdf  Oracle 10g RAC on SUSE9
http://media.netapp.com/documents/tr-3555.pdf  Oracle 10g RAC Cluster Synchronization Services with NetApp
http://media.netapp.com/documents/tr-3527.pdf  Oracle 10g with Power Linux (RHEL AS4 U3)
http://media.netapp.com/documents/tr-3542.pdf  Oracle 10g RAC on AIX
http://media.netapp.com/documents/tr-3479.pdf  Oracle 10g RAC on AIX
http://media.netapp.com/documents/tr-3330.pdf  Oracle 10g RAC with RHEL 3
http://media.netapp.com/documents/tr-3389.pdf  Oracle RAC for HP Service Guard/HP LVM over Fibre Channel
http://media.netapp.com/documents/tr-3399.pdf  Oracle RAC on IBM HACMP SAN

DNFS
http://media.netapp.com/documents/tr-3614.pdf  HA for Oracle with DNFS on NetApp MetroCluster

Disaster Recovery
http://media.netapp.com/documents/tr-3455.pdf  Disaster Recovery for Oracle on NetApp
http://media.netapp.com/documents/tr-3639.pdf  Disaster Recovery with Sun Cluster and NetApp MetroCluster

Misc
http://media.netapp.com/documents/tr-3646.pdf  Oracle 11g with VMWare
http://media.netapp.com/documents/tr-3803.pdf  Upgrading to 11g leveraging SnapMirror, FlexClone, and Real Applicaiton Testing
http://media.netapp.com/documents/tr-3762.pdf  Oracle Data Masking with SnapManager for Oracle
http://media.netapp.com/documents/tr-3792.pdf  Database Migration to Large ONTAP 8.0 Aggregates
http://media.netapp.com/documents/tr-3414.pdf  Ensuring Oracle Data Integrity with NetApp SnapValidator
http://media.netapp.com/documents/tr-3469.pdf  Enterprise Manager plug-in for NetApp
http://media.netapp.com/documents/tr-3781.pdf  NetApp with Oracle ILM Assistant
http://media.netapp.com/documents/tr-3791.pdf  Leveraging Transportable Tablespaces with Flexclones
http://media.netapp.com/documents/tr-3575.pdf  Oracle 10g with Decru DataFort on RHEL 4 on FCP

Сайзинг под базы Oracle есть критически важный параметр для создания системы хранения достаточной производительности. Сбор данных perfstat* и Oracle STATSPACK позволит выбрать правильно сконфигурированную систему хранения NetApp, как в плане размера, так и производительности.

Важно помнить несколько вещей, когда вы собираете статистику системы:

• Собирайте данные, когда система под большой нагрузкой
• Собирайте данные со всех хостов инфраструктуры
• Собирайте данные в perfstat и STATSPACK за один период времени

Установка Oracle STATSPACK.

STATSPACK это утилита диагностики произвдительности СУБД, которая доступна начиная с Oracle8i. STATSPACK это дальнейшее развитие утилит BSTAT и ESTAT. Рекомендуется установить timed_statistics в true. Для установки STATSPACK выполните следующие шаги:

1. Создайте PERFSTAT Tablespace:

SQL> CREATE TABLESPACE statspack
DATAFILE ‘/path_to_file.dbf’ SIZE 200M REUSE
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 512K
SEGMENT SPACE MANAGEMENT AUTO
PERMANENT
ONLINE;

2. Запустите catdbsyn.sql и dbmspool.sql как SYS из SQLPLUS

$ sqlplus "/ as sysdba"

SQL> @?/rdbms/admin/dbmspool.sql

3. Запустите скрипт

$ sqlplus "/ as sysdba"

SQL> @?/rdbms/admin/spcreate

Можете начинать пользоваться Oracle STATSPACK.

Сбор Oracle Statspack с помощью Perfstat с хоста Unix.

Как я могу собирать данные Oracle Statspack и Perfstat одновременно?

Для Perfstat версии 6.28 или позднее мы можем собирать данные Oracle Statspack из Perfstat используя единую команду Perfstat. Это работает для версии perfstat под unix, и не работает для версии perfstat под Windows.

Небольшая выжимка их манов к Perfstat:

Требования:

1. Perfstat может собирать данные Oracle STATSPACK только с одного хоста.
2. ??нстанс Oracle должен быть запущен до того, как будет вызван Perfstat.
3. ??спользуйте флаг -o чтобы передать специфические опции statspack в perfstat.

Опции и значения по умолчанию:

oracle_host=`hostname`
sqlplus=”sqlplus”
oracle_login=”perfstat/perfstat”
runas=”"
sysdba=”false”

-oracle_host - умолчание для localhost, может быть одним из хостов, определенных с помощью -h из команд perfstat

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

-runas - может использоваться для запуска sqlplus от имени другого пользователя (то есть пользователь Unix, где установлен Oracle, обычно не root.)

-sysdba - может использоваться для подключения к oracle как sysdba, игнорируя параметр oracle_login. Ключ sysdba вводит следующие команды в логин к sqlplus:

• a. sqlplus /nolog
• b. connect / as sysdba.

Примеры:

perfstat.sh -a oracle
perfstat.sh -h host1 -a oracle -o oracle_host=host1
perfstat.sh -h host1 -a oracle -o oracle_host=host1,sqlplus=/oracle/bin/sqlplus/
perfstat.sh -a oracle -o oracle_login=user/pass
perfstat.sh -a oracle -o runas=oracle,sysdba=true

Более сложные примеры:

perfstat.sh -a oracle -t 5 -i 5 -f filer -o runas=oracle, sysdba=true >/opt/perfstat.out

Note: Для того, чтобы собирать статистику самого файлера вместе с данными статистики Oracle, должен быть использован ключ -f.

Пример приведенный выше запускает perfstat и statspack 5 раз по 5 минут. Он переключает пользователя в oracle (с помощью команды su - oracle), и входит в sqlplus с помощью:

• a. sqlplus /nolog
• b. connect / as sysdba.

Еще почитать:
http://www.akadia.com/services/ora_statspack_survival_guide.html
https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb9096
http://www.dba-oracle.com/art_statspack.htm
http://www.datadisk.co.uk/html_docs/oracle/awr.htm

Взято тут:
http://blogs.netapp.com/databases/2009/07/gathering-oracle-statspack-data-for-netapp.html

* perfstat - собственная утилита - shell-script NetApp для сбора статистики, может быть скачана с вебсайта NOW: http://now.netapp.com/NOW/download/tools/perfstat/