Strict Standards: call_user_func_array() expects parameter 1 to be a valid callback, non-static method GoogleSitemapGeneratorLoader::Enable() should not be called statically in /home/sync4me/domains/aboutnetapp.ru/public_html/blog/wp-includes/plugin.php on line 311
переводы | about NetApp - Part 2

Archive for the ‘переводы’ Category.

Эксперименты с Calibration IO в Oracle 11g

Сегодня у нас снова перевод короткой заметки 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!

Правильная интерпретация $/IOPS и IOPS/RAID для результатов SPC-1

Новая заметка в блоге RecoveryMonkey, которые я всегда стараюсь переводить, так как Dimitris K. всегда пишет интересно и актуально.

Interpreting $/IOPS and IOPS/RAID correctly with SPC-1 results

Posted on October 19, 2011

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

Вот некоторые моменты, на которые стоит обратить внимание.

О соотношении price/performance:

Когда вы оцениваете приведенные $/IOP, убедитесь, что вы сравниваете цены list price (смотрите на отчет с полным описанием, который содержит все детали тестированной конфигурации).

В противном случае вы можете получить неверное представление о $/IOP, так как один вендор дает цены list prices, а другой в то же время показывает цену с большим дисконтом, "street price".

Например, система, показавшая $6.5/IOP после 50% дисконта, должна показывать $13/IOP по ценам list prices.

О RAID:

Как вы уже читали в предыдущих постах, RAID играет большую роль как в вопросе защиты, так и в вопросе производительности.

Все опубликованные результаты SPC-1 используют RAID10, с единственным исключением в виде NetApp (мы используем RAID-DP, математический аналог RAID6 с точки зрения уровня защиты данных).

Вот (очень) грубый способ конвертировать результаты RAID10 в RAID6, если вендор, которого вы рассматриваете, не приводит свои результаты для RAID6:

  1. SPC-1 на 60% состоит из записей.
  2. Возьмем любой результат RAID10, например пусть это будет 200 000 IOPS.
  3. 60% от этого составляет 120 000, это будут операции записи. 40% это операции чтения, или 80 000 IOPS.
  4. При использовании традиционного RAID6, вы получаете, грубо, четырехкратное замедление для операций записи: 120 000/4 = 30 000
  5. Добавляем к этому 40% чтений, и получим результат:
  6. 80 000 чтений + 30 000 записей = 110 000 SPC-1 IOPS в случае использования той же конфигурации с RAID6. Это примерно половина от результата RAID10…

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

Производительность на NFS: эксперимент

Уже цитировавшийся в этом блоге специалист по 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:

 

image

Запускаем 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

image

Controller 2

image

Server

image

 

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

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

Всех благ!

Neto

Обновление timezone на системах хранения NetApp

Как вы все знаете, внезапно Россия решила прекратить сезонную смену временного сдвига (так называемый “переход на зимнее/летнее время”). Оставив за рамками данной статьи все прочие аспекты этой темы, сосредоточимся на проблемах сисадминских.

Как вы знаете, все действующие в настоящее время OS умеют автоматически осуществлять переход  и производить соответствующий сдвиг времени, в какой бы стране они ни были установлены (конечно, если правильно эта страна для OS указана). Средство, которое позволяет OS правильно, и в соответствии с национальными правилами (часто разными в разных странах), провести эту корректировку времени – это составляемая  Американской Национальной Лабораторией Времени (NIST) специальная база данных в файлах, которую производители OS, будь то Linux или Windows, распространяют с регулярными апдейтами.

Но как быть с такими OS, как Data ONTAP? Ведь от правильной установки времени, например, зависит работа механизма аутентификации Kerberos, и при несовпадении локального времени сервера или NAS-стораджа и контроллера домена, пользователи не смогут получить доступ к данным (их сессионные тикеты системы аутентификации Kerberos “испортятся”, например для домена Windows допустимо временное смещение для членов домена не более 15 минут).

Если вы обновляете Data ONTAP регулярно, то новое содержимое timezone у вас придет с новой версией. Если же нет – нужно записать свежий timezone, на место старого, в вашей текущей версии.

По этому поводу в Knowledge Base у NetApp есть соответствующая статья, вот вам ее сокращенный перевод.
(Я не стал переводить части, относящиеся к NetCache, VTL, а также 8.0 Cluster-mode системам).

How to update timezone information on NetApp appliances

KB ID: 1011616 Version: 3.0 Published date: 08/02/2011

Эта статья рассматривает следующие темы:

  • Обновление информации timezone на Data ONTAP 7G / 7-Mode
    • Версии Data ONTAP, на которые распространяется эта информация
    • Скачивание и обновление файлов timezone
    • Установка новых значений timezone

[опущены разделы о NetCache, 8.0 Cluster-mode и пр.]

На какие версии Data ONTAP распространяется эта информация:

Все версии Data ONTAP подвержены изменениям правил в  timezone. Эти правила определяют, когда и каким образом происходит переключение локального Daylight Savings Time, а также прекращается такое переключение и производится возврат к Standard Time.

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

Скачивание и обновление файлов timezone:
Файлы timezone, которые поставляет в составе Data ONTAP компания NetApp, берутся из репозитория NIST (ftp://elsie.nci.nih.gov/pub/) , а затем компилируются и помещаются как zip, tar или в виде обычных файлов. NetApp отслеживает изменения в репозитори и автоматически получает самую свежую версию файлов, размещаемую на сайте NOW (NetApp Support).

Процесс скачивания файла на компьютер администратора под Windows/UNIX и распаковка его на систему хранения

С компьютера под управлением UNIX, с использованием NFS для подключения к  root volume:

Complete the following steps to extract the ontap_zoneinfo.tar file from a UNIX admin host to the storage system’s /etc directory:

  1. Войдите на сайт NetApp Support.
  2. Скачайте и запишите на локальный диск свежую версию файла ontap_zoneinfo.zip (щелкните по ссылке ниже и выберите Save as… или Записать файл как…:
    http://now.netapp.com/NOW/download/tools/ontap_timezone/current_version/ontap_zoneinfo.zip
    Если вы по какой-то причине не можете скачать его оттуда, то версия на момент написания этого перевода лежит тут (обратите внимание! Эта версия не обновляется, и действительна для октября 2011 года!).
  3. Введите следующие команды:
    unix> mount   <filername:/vol/ROOTVOLUME>   /MOUNTPOINT
    Внимание: Если вы получили в ответ на команду сообщение RPC error, это означает, что система хранения не имеет экспорта для root voume. Если вы получаете RPC error, войдите на систему хранения как root, и выполните следующую команду:
    exportfs -i -o /
    Затем повторите команду монтирования.
  4. Введите команду:
    unix> cd MOUNTPOINT/>etc
  5. Введите команду:
    unix> gunzip PATHTOZONEFILE>/ontap_zoneinfo.zip
  6. Введите команду:
    unix> cd /
  7. Введите команду:
    unix> umount MOUNTPOINT>
  8. Проведите инициализацию новых установок и правил нового timezone.

С компьютера под управлением Windows, с использованием CIFS для подключения к root volume:

Выполните следующие шаги, для того, чтобы распаковать ontap_zoneinfo.zip в сетевую папку ETC$ на системе хранения:

  1. Войдите на сайт NetApp Support.
  2. Скачайте и запишите на локальный диск свежую версию файла ontap_zoneinfo.zip (щелкните по ссылке ниже и выберите Save as… или Записать файл как…:
    http://now.netapp.com/NOW/download/tools/ontap_timezone/current_version/ontap_zoneinfo.zip
  3. Подключите сетевой ресурс (share) ETC$ с системы хранения как сетевой диск на букву диска T: на админском компьютере.
    Внимание: Выбор имен диска T: приведен для примера. ?спользуйте любую доступную букву.
  4. Распакуйте содержимое файла ontap_zoneinfo.zip на диск T: .
  5. Проведите инициализацию новых установок и правил нового timezone.

?нициализация новых установок и правил timezone

ВАЖНО: Обязательно выполните приведенные шаги для успешного обновления информации timezone!

Для загрузки новых установок timezone, исполните следующие команды:

  1. Введите команду:
    filer> timezone
    Current time zone is Location/YourTimezone     <— введите текст, который будет выведен на месте выделенного курсивом на следующем шаге.
  2. Введите команду:
    filer> timezone Location/YourTimezone 

(например: filer> timezone Europe/Moscow)

Система хранения НЕ ТРЕБУЕТ перезагрузки для обновления и установки новых значений правил timezone.

Внимание: НЕ ПЕРЕСТАВЛЯЙТЕ ВРЕМЯ НА С?СТЕМЕ ХРАНЕН?Я ВРУЧНУЮ ВПЕРЕД ? НАЗАД. Это не является правильным способом проверить новые изменения DST (Daylight Saving Time). Если вы так сделаете, не будут работать расписания создания снэпшотов, пока система не будет перезагружена. Такое поведение документировано в баге BUG 234237 (в настоящий момент считается fixed на всех актуальных версиях Data ONTAP. прим romx).

?нженеры NetApp проверили и подтвердили, что процедура, описанная в данной статье, успешно решает задачу изменения установок и правил DST.

SMB vs. iSCSI: как дела у Hyper-V? Результаты неожиданны.

Любопытную, и, честно говоря, даже неожиданную для меня тему исследовал блоггер NetApp Lobanov.

Следящие за темой уже знают, что в Hyper-V 3.0 Microsoft объявила, что будет поддерживать работу по NAS протоколу SMBv2.2.

Вы помните, что VMware уже с версии 3.0 активно рекомендует использовать NAS для подключения датасторов виртуальных машин по файловому протоколу NFS, и пользуется  при этом большими преимуществами такого варианта перед “классическим” блочным FC и iSCSI, о чем я уже не раз писал в этом блоге. Однако у Microsoft в ее Hyper-V не было такой возможность в штатном, поддерживаемом порядке, впрочем и пользователи, скорее всего, не особо это требовали. Отчасти это было связано с широко распространенным убеждением, что NAS-протоколы, и уж CIFS/SMB в особенности, вообще не пригодны для производительных применений. ? если в отношении NFS в VMware эти заблуждения уже более-менее развеяны многочисленными результатами тестов, как NetApp и EMC, так и самой VMware, да и сотнями и тысячами практических реализаций разного масштаба, то в отношении CIFS по прежнему бытует стойкое убеждение в непригодности его ни для чего, кроме “домашних папок” и копирования файлов по сети.

Отчасти это действительно так. CIFS как протокол сетевой файловой системы, значительно сложнее устроен, чем NFS, обладает множеством хитрых возможностей, и, как следствие, заметно большей величиной “оверхеда”, накладных расходов. Кроме того, CIFS (или SMB 1.0) никогда и не ориентировался на такое применение.

Однако первым шагом в сторону переработки и устранения старых родовых болячек NetBIOS и LAN Manager, от которого ведет свою родословную CIFS, был сделан в SMB v2.0, в котором Microsoft показала, что она знает о проблемах, и приняла решение их устранить. С тех пор CIFS/SMB развивается, не слишком шумно, но довольно существенно, а как видимый результат – появление поддержки новой версии, SMB v2.2 в качестве поддерживаемого протокола доступа к датасторам в новой версии Hyper-V.

Однако, пока Windows 8, Hyper-V 3.0 и SMB 2.2 не вышли в релиз, что же может показать в плане производительности обычный SMB2.0, появившийся в Windows Server 2008, и поддерживаемый в Data ONTAP?

Looking ahead Hyper-V over SMB vs. iSCSI

Posted by lobanov on Sep 29, 2011 10:06:19 AM

В свете грядущих новостей о  поддержке в Hyper-V работы по SMB через версию SMB 2.2, у нас скоро появится новая возможность работать с виртуальными машинами через IP сеть. До сих пор существовала только одна такая возможность, подключая LUN по iSCSI. Очеивдный вопрос, вертящийся у всех на языке, как будут обстоять дела в варианте с SMB с точки зрения эффективности использования системы хранения, управления, и, самое главное, с точки зрения производительности. Для того, чтобы разобраться во всем этом, мы решили провести эксперимент, сравнив эти два варианта подключения, использовав оборудование нашей тестовой лаборатории.

Для теста использовался один сервер в следующей конфигурации:

  • 16 CPU (Dual Socket Quad Core with HyperThreading)
  • 48 GB  RAM
  • Один 1Gbs Ethernet NIC
  • Win2K8R2 SP1

Один контроллер NetApp FAS6030 под Data ONTAP 8.0.1 работает на один сетевой адаптер Ethernet 1Gbs, на контроллере создано два тома flexvol:

  • “HVoverSMB_CIFS” это CIFS share, смонтированная на хост Hyper-V как symbolic link.
  • “HVoverSMB_ISCSI” несет один LUN, подключенный к хосту Hyper-V по протоколу iSCSI.

Оба тома имеют размер 1TB в режиме Thin-Provisioned, и  LUN на томе для iSCSI также сделан Thin-Provisioned. Таким образом, со стороны хоста Hyper-V мы видим 2TB  usable storage, в то время, как на стороне контроллера пространство на дисках почти не занято.  Мы решили не использовать 10G Ethernet, так как хотели замедлить, для наглядности, время загрузки, и максимально нагрузить сеть в процессе эксперимента.

Мы создали 20 VM на iSCSI LUN, и 20 VM на CIFS Share. Каждая виртуальная машина имела следующую конфигурацию:

  • 1 CPU
  • 2 GB RAM
  • Win2K8R2 SP1
  • 40GB VHD

Оригинальный эталонный шаблон VM был создан с использованием нашей новой техники Thick/Thin VHD , о которой я рассказывал ранее,  а последующие копии с этого шаблона созданы с использованием Sub-Lun cloning, и файлового SIS cloning vпри помощи cmdлетов Start-NaClone, и Copy-NaHostFile. ?тоговый результат 40 VM, и 1.6TB дисков виртуальных машин занимают менее 16GB на контроллере!

Затем мы подвергли получившуюся систему испытанием старым добрым Boot Storm – одновременной загрузкой 20 виртуальных машин каждого типа, и сбором данных о производительности как на хосте Hyper-V, так и на контроллере NetApp. Мы собирали данные производительности Hyper-V при помощи Performance Monitor, обращая внимание, в первую очередь, на CPU и призводительность сетевого адаптера. Контроллер NetApp мониторился с помощью Get-NaSysStat PowerShell Script. Оба инструмента был настроены на сбор данных каждые 5 секунд.

Результаты

Время загрузки

В обоих тестах загрузка до экрана Logon заняла менее 90 секунд для всех 20 виртуальных машин.  Давайте посмотрим, что в это время происходило на хостах Hyper-V и контроллере NetApp.

Hyper-V-Host Performance

CPU load

image

 

Network Adapter: BytesReceived/sec

image

 

NetApp Array Performance

Net_Data_Sent

image

CPU_Busy

image

CIFS vs. iSCSI Ops/sec

image

 

Как вы видите, как со стороны хоста Hyper-V, так и со стороны контроллера NetApp, уровни загрузки CPU, а также производительность сети оказались сравнимыми! Важно отметить, что, в данном случае, мы еще даже не используем SMB2.2, так как работает Server 2008 R2 SP1, а не Server.Next. Если же мы видим равную производительность для текущего поколения софта, запущенного на оборудовании четырехлетней давности, то что же мы получим, когда появится Server.Next?

Но где же вообще разница между протоколами, спросите вы, а что там с latency?

Давайте посмотрим, вот картина на стороне NetApp:

image

Неожиданно, не правда-ли?

На первый взгляд, все неплохо, исключая взлет latency до 4ms в самый “разгар шторма”. Но посмотрите на параметр read latency для теста  CIFS. Почему он показывает меньшую latency на идентичной нагрузке? То что мы видим, это преимущества протокола SMB 2.x; Windows использует собственный кэш NTFS для улучшения производительности на чтение, просто посылая на систему хранения меньше избыточных запросов чтения.

 

Величина эффективности использования пространства хранения на NetApp

?спользуя thin-provisioning, single copy rapid provisioning, и дедупликацию, мы получили фантастически высокие результаты для обоих протоколов.

?мя Общий размер ?спользовано Доступно Дедупликация Aggregate
HVoverSMB_CIFS 1024.0 GB 1% 1015.9 GB да aggr0
HVoverSMB_ISCSI 1024.0 GB 1% 1013.7 GB да aggr0

Как вы видите, в обоих случаях величина эффективности использования хранилища сравнима и высока.

 

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

CIFS

За:

  • Одна сетевая папка CIFS на любое число хостов Hyper-V или кластеров Clusters.
  • Перемещение VM между хостами Hyper-V становится гораздо проще, так как все хосты имеют доступ к одним и тем же VHD.
  • Значительно более высокий уровень плотности VM на том.

Против:

  • Конфигурирование прав на CIFS share несколько сложновато, так как требует разобраться со специфическими разрешениями на Share и NTFS, которые требуются для Hyper-V.
  • В настоящий момент не поддерживается.

iSCSI

За:

  • Конфигурирование прав NTFS очевидно.
  • Поддерживается.
  • Равная производительность с FCP без необходимости сложного зонирования.

Против:

  • К LUN-ам не может быть совместного доступа от нескольких хостов и кластеров, без использования WSFC, и CSV.
  • Перемещение VHD на другой хост Hyper-V требует переконфигурирования системы хранения или копирования файлов VHD по сети.

 

Выводы

Результаты теста и их анализ показывают, что сегодня SMB2.0 и iSCSI сравнимы. Оба варианта подключения обеспечивают достаточную эффективность и позволяют работу виртуальных машин по IP-сети. Мы ожидаем, что большинство сложностей с правами и разрешениями будет устранена в Server.Next. Факт неподдерживаемости SMB конечно делает iSCSI однозначным победителем, но, если быть честными, если SMB начнет поддерживаться… следует отдать должное прогрессу в работе SMB. В итоге, мы уже с нетерпением ждем выхода Server.Next, SMB2.2, и Hyper-V 3.0 over SMB, это должно оказаться весьма неплохо!

Две моих любимых новинки в VSC 2.1.1

В сегодняшнем переводе о двух самых показавшихся ему интересными новинках VSC 2.1.1 рассказывает блоггер NetApp Luke Reed. (Я объединил два его поста, про первую и вторую фичу, в один, для полноты).

 

VSC 2.1.1 – Мои любимые новые фичи

Posted by luker on Sep 9, 2011 5:44:16 AM

Вчера (8 сентября, прим romx) NetApp выпустил новую версию своего плагина дляvSphere –  Virtual Storage Console (VSC).

Среди всех новых возможностей этой версии, две моих любимых это:

Добавление уже существующего датастора на новые сервера ESX в кластерах или датацентрах.

Если вы уже использовали VSC для создания датасторов, вы знаете, как с его помощью это делается быстро и просто, запустили мастер, и он создаст новый том FlexVol, экспорт его через NFS, смонтирует его на каждый сервер ESX в кластере, и создаст на нем датастор, все в одну операцию.

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

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

Единственным выходом до сих пор было вручную подключать датасторы на необходимые сервера. В случае датастора по протоколу NFS, вам надо было добавить IP-адрес VMKernel на эти сервера, затем вручную смонтировать датастор на сервер.Для датастора по протоколу VMFS, вам надо было добавить WWN или IQN этих серверов в iGroup, затем сделать rescan на серверах ESX, чтобы обнаружить и подключить новый для этого сервера датастор.

Теперь, с использованием VSC 2.1.1 это все делается гораздо проще.

Когда вы выбираете хост в vSphere Client inventory, вы увидите новую кнопку, под названием “Mount Datastores”.

image

Щелкнув ее вы откроете мастер, который покажет вам датасторы, уже подключенные на других хостах кластера.

image

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

Так что просто выберите тут датастор, который вы хотите подключить данному серверу, и жмите OK. VSC пойдет и автоматически выполнит все шаги по подключению уже существующего датастора к выбранному серверу ESX. Это работает, заметьте, как для NFS, так и для VMFS!

image

Отлично сделано!

 

 

Другая моя любимая новая фича VSC 2.1.1, это новая операция “Reclaim Space”, или возвращение в пул свободных блоков на системе хранения места, высвобожденного после удаления данных внутри виртуальной машины.

Эта новая возможность работает (пока) только для виртуальных машин Windows на файловой системе NTFS, лежащих на датасторе, подключенном по NFS, и требует версию ONTAP 7.3.4 или новее, она возвращает системе хранения место, высвобожденное в результате удаления файлов внутри виртуальной машины.

Вот пример того, как это работает. Я создал 10 VM, каждая размером 10GB в формате Thin VMDK.

Установленная в них Windows 2003 заняла примерно 5GB, и так как я делал VM с помощью функции “Create Rapid Clones” из VSC, они получились уже в дедуплицированном формате.

Теперь я скопировал примерно по 5GB данных в каждую VM (я использовал разные образы ISO, куски моей библиотеки iTunes, и так далее), а затем удалил эти данные из каждой VM.

После этого я получил примерно 60GB занятого пространства в датасторе этих VM:

image

Каждый из Thin VMDK раздулся примерно до 10GB, несмотря на то, что после копирования данных я эти данные с диска VM удалил.

image

Также отметьте, что такие раздувшиеся VMDK также будут, например, дольше копироваться при Storage vMotion, так как ему придется копировать дополнительные “занятые” блоки. Разумеется то же самое будет и с репликацией SnapMirror, репликации придется копировать дополнительные блоки, несмотря на то, что они заняты уже удаленными в файловой системе файлами.

А теперь давайте задействуем операцию Reclaim Space, щелкнув правой клавишей по датастору и дойдя до пункта меню Reclaim Space, как показано а скриншоте.

image

Появится окно Reclaim Space. Займет несколько секунд процедура проверки датастора, и создания списка VM, для которого будет производиться операция.

image

Также вас предупредят, что для проведения процедуры потребуется выключение VM. После нажатия OK, виртуальные машины будут остановлены на время проведения операции.

image

Затем начинается процесс Reclaim Space. На моем тестовом стенде этот процесс занял примерно 3 минуты на 10 VM.

image

После выполнения процесса, занятое на датасторе место уменьшилось с 60GB до примерно 15GB (экономия составила 45GB), а диски  VMDK виртуальных машин сжались с 10GB, обратно до 5GB.

image

image

Круто? ;)

IDC Storage Tracker Q2 2011

Очередной IDC Storage Tracker Q2 2011 опубликован. К сожалению у меня пока нет собственно текста, а только выдержки и интерпретации.

Поставлено за квартал 5353 петабайта емкостей хранения. Рост 10,2% процента относительно того же периода прошлого года. Все вендоры “топа” выросли, кроме Dell и Other, и на сегодня топовая группа вендоров поставляет около 74% всего рынка стораджей. В топ5 впервые вошла HDS, поравнявшись с Dell, и с очень хорошим ростом (HP начинать бояться и грести сильнее;). NetApp с IBM продолжают играть в Ахиллеса и черепаху ;)

Top 5 Vendors, Worldwide External Disk Storage Systems Factory Revenue, Second Quarter of 2011 (Revenues are in Millions)

Vendor

2Q11 Revenue

2Q11
Market Share

2Q10 Revenue

2Q10
Market Share

2Q11/2Q10
Revenue Growth

1. EMC

$1,621

28.7%

$1,287

25.6%

26.0%

2. IBM

$771

13.7%

$680

13.5%

13.4%

3. NetApp

$720

12.8%

$572

11.4%

25.7%

4. HP

$619

11.0%

$567

11.3%

9.1%

5. Hitachi

$459

8.1%

$372

7.4%

23.3%

6. Dell

$444

7.9%

$472

9.4%

-5.9%

Others

$1,009

17.9%

$1,080

21.5%

-6.6%

All Vendors

$5,643

100.0%

$5,031

100.0%

12.2%

Source: IDC Worldwide Disk Storage Systems Quarterly Tracker, September 2, 2011

Проблемы производительности при использовании Autotiering и Megacaching

Сегодня в переводах – статья одного из моих любимых блогоавторов – уже знакомого вам Димитриса Крековкиаса, работающего в NetApp, и ведущего автономный блог recovermonkey.org. Обратите внимание, что, несмотря на то, что автор и является сотрудником NetApp, текст поста в равной мере относится и к системам NetApp, и его стоит внимательно прочесть также и партнерам NetApp, продающих их (и проводящих сайзинг) своим клиентам.

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

Покупатель, будь внимателен: верно ли вендор вашей системы хранения делает сайзинг по производительности, или они полагаются только на свои супер-технологии, типа Megacaching и Autotiering?

Posted on June 29, 2011 by Dimitris

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

Я написал этот пост, потому что вижу все больше и больше вендоров, которые сегодня НЕ используют научные методы для количественной оценки (сайзинга) производительности и емкости своих решений, вместо этого они стремятся удовлетворить клиента ценой, надеясь, что технологии обеспечат нужную клиенту производительность (а если нет, то не беда, сторадж-то уже продан, квартальный план продаж закрыт, а если производительности системы клиенту не хватает - что-ж, клиент ведь всегда может докупить дисков, памяти, или еще чего, правда?)

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

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

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

Например, набирающая популярность концепция Megacaches может использоваться для значительного уменьшения объемов ввода-вывода, который добирается до бэкэнда и дисков системы хранения. Например на системах NetApp FAS вы можете использовать до 16TB интеллектуального, сверх-гранулярного (4K) и использующего дедупликацию данных кэша чтения. Это на самом деле гигантский размер, больший, чем обычно может понадобиться подавляющему большинству использующих системы хранения (и даже больший, чем многие системы хранения в целом). Другие вендоры также последовали за NetApp, и предлагают сегодня похожие технологии. ?мея такой объемный кэш, расположенный перед дисками, и перехватывающий на себя значительную часть ввода-вывода, многие вендоры имеют соблазн рекомендовать использовать в таких системах хранения диски SATA, имеющие большую удельную емкость, но, обычно, невысокую производительность, ведь производительность в данном случае планируется обеспечивать с помощью того или иного "мегакэша".

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

Как я показал выше, кэш хорошо работает в том случае, если значительная часть данных, которые мы называем "рабочим набором данных" (active working set), помещается в него. Но помните, что "рабочий набор данных" это не все ваши данные, это подмножество ваших данных, к которому обращаются на протяжении какого-то периода времени.

Для пользователя, у которого, допустим, база данных размером 20TB, реальный рабочий набор данных этой базы может составлять всего 5% — то есть этот набор вполне может целиком поместиться в 1TB кэша. Таким образом, кэш размером 1TB может обеспечить большинство потребностей в вводе-выводе базы данных. Диски же в бэкэнде вполне могут при этом быть недорогими SATA, просто чтобы удовлетворить необходимости разместить объем хранения всей базы данных.

Но как быть с тем периодом времени, когда характер ввода-вывода отличается от типового и ожидаемого? Например, это может быть период переиндексации, или объемного экспорта базы, или период конца месяца, или квартала, когда нагрузка на базу часто резко возрастает? Такие операции сильно изменяют объем рабочего набора данных, он может быстро вырасти от 5% до куда более значительных величин. При этом наша рассмотренная выше ситуация, с 1TB кэша и SATA в бэкэнде уже может перестать нас удовлетворять.

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

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

  1. Типичное использование – 20 000 IOPS, 100% random, 8K I/O-блок, 80% чтения
  2. Экспорт DB — высокие значения MB/s, в основном sequential write, большой размер I/O-блока, относительно немного IOPS
  3. Последовательное чтение после произвольной записи — например данные добавляются в DB в произвольном порядке, затем делается большое последовательное чтение, или даже несколько чтений параллельно

Как вы видите, профиль ввода-вывода не просто меняется, он становится принципиально другой. Если вы берете в расчет только вариант 1, у вас может не оказаться достаточно дисков в бэкэнде для стабильного потока при экспорте DB или параллельного sequential table scans. Если вы считаете только вариант 2, вы сочтете, что вам не нужно много кэша, так как ваш профиль ввода-вывода в основном последовательные (sequential) операции (а в большинстве случаев такие операции не кэшируются). Но ваша оценка будет полностью неверна для операций типичного использования.

Если вендор говорит вам, что проведенный ими сайзинг показал, что их предложение соответствует большинству ваших требований по вводу-выводу, то ваш вопрос должен быть: о каких типах ввода-вывода шла речь?

Другая новая модная технология (и судя по всему - переоцененная) это Autotiering.

Autotiering, если по-простому, позволяет перемещать на системе хранения фрагменты данных, так называемые "чанки" (chunks), в соответствии с активностью доступа к ним. Чанки, содержащие максимально активные данные постепенно перемещаются на SSD, в то время, как остальные, менее активные, могут спокойно оставаться на SATA.

Различные дисковые массивы используют разные методы выполнения Autotiering, обычно реализованных с помощью нижележащих архитектурных возможностей систем хранения, и имеют различные ограничения и характеристики. Например, EMC Symmetrix имеет размер чанка около 7.5MB. На HDS VSP, чанк имеет размер около 40MB. На IBM DS8000, SVC или EMC Clariion/VNX, он равен 1GB.

При использовании Autotiering, как и в случае использования кэширования, чем меньше размер чанка, тем эффективнее получается конечный результат. Например, чанк размером 7.5MB требует всего 3-5% пространства сверхбыстрых дисков как "верхнего tier", однако в случае чанков размером 1GB потребуется уже 10-15%, просто по причине того, что чанк большего размера содержит в себе не только "горячие" данные, но и "холодные", перемешанные, на протяжении этого гигабайта, с активными, "горячими" данными.

Так как большинство дисковых массивов записывают данные в "геометрическом" расположении на диске (то есть на определенные, заданные непосредственно хранимыми данными места, напротив, NetApp использует и "геометрический" и "темпоральный" метод размещения), то с большими чанками это приводит к тому, что "горячие" блоки будут всегда соседствовать с "холодными" в таких протяженных чанках. Это объясняет, почему чем меньше чанк, тем лучше эта ситуация.

Поэтому с большими чанками ситуация выглядит примерно так (красные квадратики - самые горячие блоки данных, оранжевые и зеленые - более "холодные"):

image

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

?так, что же следует сделать, чтобы получить правильный сайзинг?

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

  1. Предоставьте вендору подробную статистику производительности — чем подробнее она будет, тем лучше. Если мы не будем знать, что происходит на хранилище, то трудно создать по настоящему хорошо спроектированную для вашей задачи систему хранения.
  2. Предоставьте ваши ожидания в области производительности — например "Мне бы хотелось, чтобы запросы в Oracle завершались за 1/4 нынешнего времен их выполнения" — и увяжите ваши ожидания по производительности с бизнес-целями (будет проще их оценивать).
  3. Попросите вендора показать его инструмент сайзинга и описать , каким именно образом делается математическая оценка и получается результат — тут нет и не может быть никакой магии!
  4. Спросите вендора, проанализровали ли они все возможные сценарии нагрузок, которые у вас имеются (не просто "для разных приложений" но разные нагрузки для каждого вашего приложения) — и как именно они это сделали.
  5. Попросите его показать вам каков по размеру, по его оценке, ваш "рабочий набор" данных, и какой объем его поместится в кэш.
  6. Попросите его объяснить вам, как ваши данные будут располагаться на Autotiered-системе. Каким образом определяется то, на каком tier-е будут располагаться те или иные фрагменты данных. Как это вычисляется? Какие моменты геометрии хранилища следует принять во внимание?
  7. Есть ли достаточно пространства для каждого уровня хранения (tier)? Для архитектуры Autotiering с большими чанками, есть ли у вас объем, равный 10-15% емкости общего стораджа, на SSD?
  8. Учтена ли дополнительная нагрузка на RAM и CPU контроллера во время работы кэширования и autotiering? Такие технологии обязательно нагружают CPU и RAM при работе. Спросите, каков этот оверхед (чем меньше чанк при Autotiering, тем больше оверхед на обработку метаданных, например). Ничто не дается на халяву.
  9. Остерегайтесь сайзинга, сделанного устно или "на салфетке", на калькуляторе, или даже в простой электронной таблице – Я еще ни разу не видел точную модель расчета производительности системы хранения в виде электронной таблицы.
  10. Остерегайтесь сайзинга, рассчитанного исходя из примитивного "диск 15K дает 180 IOPS"— на практике все куда сложнее!
  11. Разберитесь с разницей между последовательным (sequential) и произвольным (random) доступом к данным, режимом чтения (reads), записи (writes), а также размером оперируемого блока ввода-вывода (I/O size) для каждой оцениваемой архитектуры — в зависимости от платформы различие в способах работы ввода-вывода может сделать сравнение очень трудным для корректного сравнения между собой при различных требованиях к дисковой подсистеме.
  12. Разберитесь с тем, какую дополнительную нагрузку по вводу-выводу и емкости хранения создают решения Continuous Data Protection и репликации в ряде случаев это может утроить ее.
  13. Какой тип RAID предполагает использовать вендор? Учтено ли огромное дополнительное влияние на производительность у RAID-5 и RAID-6, при большой нагрузке на запись (плюс известный аспект надежности).
  14. Если вы получили предложение за необычно низкую цену, поинтересуйтесь стоимостью дальнейшего апгрейда системы. Принцип "Первый раз - бесплатно" используется очень многими отраслями бизнеса.
  15. ?, наконец, совсем немаловажное — спросите, исходя из какой нагрузки на контроллер системы хранения исходил вендор при сайзинге! Я с большим удивлением видел попытки продать систему, которая обеспечивала обслуживание рабочей нагрузки клиента с запланированным уровнем загрузки CPU контроллера на уровне 90%. Вы считаете, что такого запаса по производительности вам хватит? Помните – дисковая система хранения это просто компьютер с большим количеством дисков, и со специализированным аппаратным и программным содержимым, и здесь процессор может "затыкаться" точно также, как и в любой другой вычислительной системе.

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

Еще немного про autotiering

Проглядывая community.netapp.com обнаружил дискуссию о autotiering-е, откуда выдернул интересное мнение уже известного вам Dimitris K. (recoverymonkey). Хотя в оригинале это были три реплики-ответа в дискуссии в форуме, я слил их оформил их как отдельную “статью”.

Дискуссия идет о реализации autotiering в EMC FAST, а также о системах хранения Compellent, которые, до недавнего времени, были главным игроком на рынке tiering-а, и реализация прозрачного tiering-а в них была сделана ранее всех. В России они почти неизвестны, хотя сейчас, как я понимаю, они могут начать попадать в страну через каналы Dell.

Dimitris Kriekouvkas (recoverymonkey), сотрудник NetApp:

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

Посмотрите на опубликованные бенчмарки EMC – там нигде нет autotiering.

Вы также не найдете и показателей FASTcache. Все бенчмарки у EMC делаются на традиционных RAID-группах, без пулов.

Если вы посмотрите на руководство наилучших практик по производительности и доступности для EMC CLARiiON (ссылку на этот документ я давал в прошлом посте про “матчасть”), то вы увидите следующее:

  • Вместо RAID-5 для больших пулов на SATA рекомендуется RAID-6 с размером группы в 10-12 дисков.
  • Thin Provisioning снижает производительность
  • Storage pools снижают производительность по сравнению с Traditional RAID
  • Данные и ввод-вывод не распределяются на все диски пула, как вы, возможно, предполагали (см ссылку).
  • Рекомендуется использовать drive ownership на только один контроллер
  • Нельзя смешивать разные типы RAID в одном пуле
  • Существуют ограничения по расширению пула дисками, в идеале расширение должно производиться увеличивая емкость пула вдвое (или, хотя бы, кратно количеству дисков в RAID-группе пула)
  • Для пула недоступны reallocate/rebalancing (для MetaLUN вы можете сделать restripe)
  • Процесс Tresspassing pool LUN (обычно при переключении LUN-а с одного контроллера на другой, например при выходе одного из них из строя, но, часто, и при других операциях) может приводить к снижению производительности, так как оба контроллера будут пытаться совершать операции ввода-вывода на LUN. Поэтому для pool LUN-ов важно оставаться закрепленными за тем контроллером, на котором они начали работать, иначе потребуется затратная миграция.
  • Не рекомендуется использовать thin LUN для задач, требующих высокой производительности по bandwidth.

Я хочу еще раз привлечь внимание к простому факту: дьявол кроется в деталях. Читайте мелкий шрифт.

Вам говорят: Autotiering волшебным образом, автоматически, решит ваши проблемы, без вашего участия, не беспокойтесь об этом. В реальности все не совсем так.

При работе autotiering, значительная часть вашего working set, рабочего набора данных, находящегося в активном использовании в данный момент, должно быть перемещено на быстрое хранилище.

Допустим у вас есть хранилище ваших данных, емкостью 50TB. Правило оценки, которым руководствуются инженеры EMC,  что 5% рабочего набора данных пользователя – “горячие данные”. Они перемещаются на SSD (в виде tier или cache). Таким образом вам нужно 2,5TB usable space на SSD, или примерно одна полку дисками SSD по 200GB, может быть больше, в зависимости от типа использованного RAID.

Принято считать, что объем “средней” нагрузки составляет 20% от объема, то есть 10TB, который размещается на дисках SAS или FC.

Остальное размещается на дисках SATA.

Вопрос на 10 миллионов долларов:

Что обойдется дешевле, autotiering и софт кэширования (он небесплатен) плюс 2,5TB SSD, плюс 10TB SAS, плюс 37,5TB SATA, или…

50TB SATA плюс NetApp FlashCache,или, например, 50TB SAS и Flash Cache?

Вопрос на 20 миллионов долларов:

Какая из этих двух конфигураций будет иметь более предсказуемую производительность?

 

Compellent – это еще одна интересная история.

Большинство обсуждающих Compellent не задумывается о том, что tiering-у у него подвергаются “снэпшоты”, а не непосредственно рабочие данные!

То есть принцип там такой: берется снэпшот, данные делятся на страницы, размеров 2MB (по умолчанию, может быть меньше, но тогда нельзя будет увеличить емкость хранилища). Далее, если оценивается, что обращений на чтение с данной страницы мало, то она переносится на уровень SATA.

О чем не знают большинство интересующихся Compellent-ом:

Если вы изменяете содержимое данных на странице, то происходит это следующим образом:

  1. Перенесенная на SATA страница, содержащая данные, которые мы изменяем, остается на SATA.
  2. Новая страница, объемом 2MB создается на Tier1 (SAS/FC), куда реплицируется содержимое страницы с SATA, и где делается запись изменения. Даже если меняется в данных один байт.
  3. Когда с этой страницы будет сделан снэпшот, то он, в свою очередь, также может быть впоследствии перенесен на SATA, заменив прежнюю.
  4. ?того: 4MB занятого места для того, чтобы сохранить 2MB данных и один измененный байт.

? снова укажу: дьявол кроется в деталях. Если вы изменяете свои данные произвольным образом (random), вы получите множество “заснэпшоченных” страниц, и очень неэффективное использование пространства. Вот почему я всегда предупреждаю пользователей, которые интересуются Compellent-ом, задавать эти вопросы, и уяснить себе эти моменты, получив ясное описание от инженеров того, как используется пространство снэпшотов.

На NetApp мы имеем предельно гранулярное пространство, благодаря WAFL. Минимально возможный снэпшот по своему объему очень мал (это указатель, немного метаданных, плюс один измененный блок, размером 4KB). Поэтому на NetApp некоторые наши пользователи могут хранить сотни тысяч  снэпшотов на одной системе (например именно так делает один всем известный банк, использующий наши системы хранения).

 

Гранулярность, на самом деле, это только часть проблемы (производительность – другая ее часть). Сейчас страница у Compellent имеет размер 2MB (можно уменьшить до 512K, но это не позволит изменять размер стораджа). Если они перейдут, как обещают, на 64-битную арифметику в ПО, то они смогут получит  размер страницы 64K (это пока не подтверждено), однако тут есть вот какая проблема. Запись этой страницы на RAID может быть двумя способами.

Если это RAID-1, то тогда мы записываем две копии страницы, размером 64KB на каждый из дисков.

Если это RAID-5/6, то тогда нам надо поделить объем записываемой страницы, размером 64KB, поровну между всеми дисками данных, входящих в RAID. Допустим используется RAID-5 в варианте 4d+1p. Тогда на каждый диск в операции записи получится всего 16KB (и меньше). ? если для RAID-1 размер записи в 64KB это довольно типичный размер записи сегмента в RAID, и запись таким размером достаточно производительна, то для RAID-5/6 это очень маленький кусочек для операции записи, что будет неизбежно отражаться на производительности.

В Data ONTAP мы не перемещаем снэпшоты, поэтому у нас нет такой проблемы, у других же вендоров она очень остра. Получить предсказуемую производительность при использовании autotiering это очень, очень сложная задача. Всякий раз когда мы у клиентов меняем нашими системами сторадж от Compellent, это происходит не потому что им не хватает каких-то фич, а только оттого, что у клиентов с ними проблемы с производительностью. Всякий раз.

Мы ставим 1-2 вида дисков плюс Flash Cache, и проблема решена (в большинстве случаев производительность становится в 2-3 раза выше, как минимум). Часто это получается даже не дороже.

Вот такие дела.

Почем обходится производительность?

Сегодня еще один пост Recoverymonkey, на тему довольно странной методики, используемой EMC для публикации своих результатов в тесте SPEC SFS NFS, для своих новых систем VNX.

Во что же обходится производительность, измеренная в “долларах на IOPS”?

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

Examining value for money regarding the SPEC benchmarks

Posted on February 28, 2011 by Dimitris

Некоторые комментарии к предыдущему моему посту, ответ на вопросы о цене $/IOPS и $/TB.

Поскольку SPEC не требует указывать цену тестируемой конфигурации, я проделал собственный анализ цен.

Данные по NetApp это просто умноженные на 4 наши опубликованные на сайте SPEC результаты для FAS6240, точно то же самое, что сделала EMC со своими результатами, они взяли 4 независимых системы, запустили на каждой из них тест, и просуммировали результат всех четырех.

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

Когда вы тестируете одну систему, вы, в конечном счете, упираетесь в одно из таких мест.

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

Например, если на один грузовик можно нагрузить 10 тонн, то на 4 грузовика можно погрузить 40, а на 10 – 100 тонн груза. Предела нет.

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

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

  EMC NetApp Разница
Цена (USD list) 6 000 000 5 000 000 NetApp дешевле на 16% по абсолютной величине
SPEC SFS NFS IOPS 497623 762700 NetApp быстрее на 53% по абсолютной величине
Average Latency 0,96 1,17 У EMC всего на 18% меньше latency (при меньших IOPS) несмотря на SSD!
Емкость (TB) 60 343 У NetApp 5,7 раза больше емкость usable space
$/IOPS 12,06 6,53 У NetApp на 45,6% дешевле IOPS
$/TB 100000 14577 У NetApp терабайт стоит всего 1/6 от стоимости EMC
RAID RAID-5 RAID-DP Пространство хранения на NetApp в тысячи раз надежнее
Количество корпусов 15 8 NetApp значительно проще в конфигурировании и работе

 

Ну, кто покажет наилучший вариант? ;)

Как вы знаете, пользователю системы хранения с определенным уровнем производительности,  нужна скорость, объем хранения и высокая надежность. Не просто один параметр из трех, а все три вместе. Хороший документ по поводу относительной надежности разных типов RAID можно почитать тут.

NetApp предлагает все три параметра, разом, плюс хорошую цену, простоту и гибкость unified storage, и высокую эффективность использования.

Большинству пользователей нужно видеть производительность реальных конфигураций. Я довольно часто показываю клиентам наши результаты в SPEC SFS или SPC-1, так как протестированные там конфигурации обычно довольно близки к тому, что они спрашивают.

Возможно было бы хорошо для EMC показать результат, который на самом деле продается клиентам, например:

  • Систему с SSD, FASTcache, SAS и High Capacity SAS дисками вместе
  • Autotiering (FAST)
  • RAID6
  • Типичным объемом usable для данной конфигурации

? уже этот результат публиковать.

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

Я правда не понимаю, почему это для вас так сложно.

19/0.182

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

This content is not endorsed, sponsored or affiliated with NetApp, Inc. The views expressed in this blog are solely those of the author and do not represent the views of NetApp, Inc.