Тестлаб компании NetApp продолжает тестировать и публиковать показатели производительности различных программных систем, работающих с системой хранения через различные протоколы доступа, с акцентом именно на сравнение производительности различныхпротоколов. Очередь дошла и до популярной базы данных MySQL, часто использующейся в различных веб-проектах.
По результатам недавно опубликованного отчета о тестировании производительности работы базы данных MySQL 5.0.56 (InnoDB) на сервере HP DL580 G5 под RHEL4, с использованием трех протоколов доступа – FC, iSCSI и NFS, к системе хранения FAS3070 можно оценить эффективность использования передачи данных по этим трем протоколам.
При тестировании использовался открытый тестовый пакет генерации нагрузки 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) разница может оказаться еще менее значительной.
Также интересующимся рекомендую обратить внимание на документы:
Компания NetApp опубликовала результаты тестирования 4Gb FC и Software iSCSI по 1Gb Ethernet и 10Gb Ethernet в среде MS Hyper-V R2 с использованием своей системы хранения NetAp FAS3160A (система midrange-класса).
Тестирование производилось с помощью IOmeter (о котором я уже не раз писал в блоге), с 4 хост-серверов IBM x3550 (1x Quad-core Intel Xeon E5420, 2,5GHz), на каждом из которых бы установлен Windows 2008 R2 c Hyper-V role и 8 виртуальными машинами в каждом, с Windows 2008 64-bit Enterprise edition (итого 32 виртуальных машины). Интерфейсы каждого сервера: FC – QLogic QLE2462, Gigabit Ethernet – Intel PRO/1000 PT dual port, 10G Ethernet – Intel Ethernet Server Adapter X520, включались в коммутаторы Brocade 200E, Cisco 4948 Ethernet Switch и Fujitsu XG1200 соотвественно. Особое внимание при тестировании уделялось получению результатов, приближенных к “боевым”, позволяющим использовать их для оценки реальной, “живой” инфраструктуры Hyper-V.
Использовался паттерн: 100% Random, 75% Read, 4KB и 8KB Request size.
Тесты показали сравнительно незначительную разницу между всеми тремя вариантами (4Gb FC, 1Gb software iSCSI, 10Gb software iSCSI) как в IOPS, так и в Latency. Дополнительная загрузка задачи softwre iSCSI initiator составила 3-5 процентов, в том числе и на 512 outstanding IOs (очень высокая загрузка), и разница со значением загрузки при использовании FC уменьшалась с повышением объемов загрузки (Outstanding IOs).
Показательно почти полное отсутствие значимого отличия по быстродействию между 4Gb FC и 1Gb iSCSI на рассматриваемой задаче. Отсутствие значительной разницы между 1Gb Ethernet и 10Gb Ethernet по видимому связано с тем, что Software iSCSI initiator на 10G Ethernet перестал быть эффективен, и, возможно, следует рассмотреть использование iSCSI HBA для таких высокоскоростных решений. Также сравнительно небольшую разницу дает включение и использование Jumbo Frames как на 1G Ethernet, так и на 10G Ethernet, что скорее всего говорит о специфике Hyper-V R2 в этом вопросе.
Лимит по производительности системы хранения FAS3160A для такой конфигурации не был достигнут.
Компания Demartek, совместно с NetApp провела измерения производительности системы FAS3170, и опубликовала результаты в виде отчета.
Измерялся FCoE и iSCSI по 10G Ethernet.
Не бог весть какое тестирование с точки зрения методологии и всякого хайэнда, но почитать для общего образования может быть интересно.
Отметьте, в документе авторы отчего-то называют парметр IOmeter - “# of outstanding IOs” как “queue depth”, кривые на графиках вызваны изменением его значения от 4 до 48 с шагом 4, для каждого из измерямых размеров блока.
На днях EMC выкатило на тесты SPECmark (тесты производительности NAS enterprise-уровня), впервые с 2007 года, свой “суперболид” на базе симметрикса и “всех порвала!!!11″.
Впрочем, как выяснилось довольно скоро, не то чтобы совсем порвала, а так, понадрывала по краю ;)
По этому поводу блоггеры NetApp вовсю ехидничают.
Судите сами:
EMC Symmetrix V-MAX, 4x V-engines, 264GB cache total
96 штук 400GB EFD flash drives (это EMC-шные SSD) в двух RAID-1
3 штуки (2 active + 1 passive) Celerra NS-G8 Datamovers в качестве NAS Gateway, 8GB cache в каждой.
24-портовый коммутатор FC, чтобы всю эту кухню пересоединять между собой Наддув, впрыскивание закиси азота, ксеноновые фары и брызговики Sparco.
И все это счастье сисадмина, стоимостью не менее чем 6 миллионов долларов в ценах американского лиспрайса набирает аж 110621 спекмарковских попугаев по SPECsfs2008 в NFS (и 118463 в CIFS, которые никто почти и не меряет из участников).
Круто типа.
Но при этом еще в прошлом году NetApp публиковал результаты FAS6080, с ценой проекта едва ли вполовину EMC-шной, на обычных дисках (не SSD), и даже без Performance Accelerator, показавшей 120011 спекмарковских попугаев.
А результат в районе 60 тысяч, то есть вполовину EMC-шного “устройства для завоевания превосходства в датацентре” показывает довольно таки средненькая midrange FAS3160, причем при использовании PAM делает она это на всего лишь 96 дисках SATA (!)
Я уж не говорю, что по абсолютной величине их обгоняет, например система производства Huawei Symantec ;)
В блогах MSDN найден любопытный документ тестирования iSCSI на 10G Ethernet, с использованием MS Windows Server 2008, Hyper-V, и системы хранения NetApp FAS3070.
Даже несмотря на то, что использовался довольно старенький сторадж (3070 это топовая модель предыдущей midrange-линейки, в настоящий момент уже не выпускаемая, вся серия 3000 уже целиком заменена на 3100), и чисто “софтверный” iSCSI, результаты могут показаться любопытными тем, кто еще раздумывает “А насколько быстр на самом деле этот непонятный iSCSI?”
Следует отметить, что карты 10G Ethernet, например рассматриваемая в этом тестировании двупортовая Intel 10 Gigabit AF DA dual port Server Adapter по ценам Price.ru стоит ~770$, а вообще 10G адаптеры начинаются уже от 500$.
В одном из постов, опубликованных ранее, посвященному “мнимой дешвизне” дисков SATA, и проблемами при построении системы хранения заданной производительности в IOPS, меня спрашивали об источниках приведенных показателей IOPS отдельных дисков в зависимости от их типа.
Нашлась вот такая картинка, с графиками тестирования различных типов дисков.
Часто приходится отвечать на вопрос: "Насколько использование дедупликации снижает производительность системы хранения NetApp?"
Официальное мнение, подтверждаемое отчетами пользователей: "Снижение производительности либо практически не заметно, либо находится в пределах 5-7% , в зависимости от нагрузки и характера доступа к системе"
Однако вполне возможна и реальна ситуация, когда использование дедупликации значительно повышает общую производительность системы хранения!
Простой пример. Вы используете систему хранения FAS3140, с размером кэш-памяти на контроллере в 8GB (на два контроллера - 16GB, по 8 на каждом), для хранения множества однотипных виртуальных машин. Не секрет, что системные разделы виртуальных машин Windows, в том случае если вы, как оно обычно и бывает, используете одну и ту же версию OS и сервиспаков, отличаются между собой очень незначительно. Допустим, что 90% всего содержимого OS, установленного на раздел виртуального диска, размером 4GB, идентичны для всех 20 имеющихся у вас виртуальных машин (данные у них, разумеется, различные, но мы говорим сейчас только о системных разделах). Легко видеть, что, в этом случае, после проведения дедупликации, на разделе, ранее занятом на 4GB*20=80GB высвободится 90% места, и все данные поместятся в 11,6GB (4GB + (0,4GB*19)).
Такой результат означает, что практически все содержимое наших системных разделов виртуальных машин поместится в кэш системы хранения (16GB), что в разы поднимет ее результирующее быстродействие после проведения дедупликации.
Даже если такой результат и не будет достигнут в конкретно вашем случае, все равно, уменьшение объемов хранения приводит к тому, что бОльшие объемы хранимых данных будут попадать в кэш, что чаще всего положительно сказывается на общей производительности.
Вопрос: Почему вы считаете, что кэш в данном случае не сможет точно также эффективно закэшировать одинаковые блоки, даже если они лежат в разных местах?
Ответ: Потому что кэш не знает ничего о содержимом блоков, он знает только о расположении его. Кэш помещает в себя "блок номер 12037", "блок номер 34560" и "блок номер 545200". Даже если они полностью идентичны внутри, каждый из трех займет место в кэше, потому что для кэша они разные, они их видит только “по номеру”. В случае же дедупликации "виртуальный уровень хранения", при необходимости считать их содержимое, запросит из них только один. Ситуацию пояснят рисунки:
Кстати следующий подготовленный перевод, который можно будет найти, как всегда, на страничке технической библиотеки российского дистрибутора NetApp, компании Netwell, это большое руководство Best Practices о использовании и настройке дедупликации на системах FAS и V-series . Думаю, что вскоре вы сможете подробно прочитать обо всех аспектах применения дедупликации "от производителя"
Сайзинг под базы 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/catdbsyn.sql
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 - умолчание для 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
Note: Для того, чтобы собирать статистику самого файлера вместе с данными статистики Oracle, должен быть использован ключ -f.
Пример приведенный выше запускает perfstat и statspack 5 раз по 5 минут. Он переключает пользователя в oracle (с помощью команды su - oracle), и входит в sqlplus с помощью:
Несомненно одна из “горячих тем” 2008-09 года это SSD - Solid State Disks - “твердотельные” диски на технологии Flash. Они появились повсеместно, от недорогих нетбуков “до 300$” до дорогих серверных систем. В прошлом году использование SSD в системах хранения данных было анонсировано EMC для их линейки Symmetrix.
Часто приходится отвечать на вопросы: “А что же NetApp не реагирует, и не поддержит свое реноме передовой инновационной инженерной компании? Где же у NetApp SSD?”
А NetApp, как всегда, движется своим путем.
Что есть SSD? SSD это flash, знакомый нам уже много лет, но организованный таким образом, чтобы “обманывать” прочие устройства, чтобы те думали, что они работают с обычным HDD.
Этакий аппаратный “эмулятор HDD”. Кроме этого чем SSD отличается от знакомых нам, уже сто лет как, USB-”брелков”? Да по сути ничем. Ну да, SATA это в принципе более производительная шина, чем USB2.0. Да, в современных контроллерах Flash используется чередование и wear-leveling, но все то же самое используется и в современных высокоскоростных USB-”флешках”.
То есть в чем инновационность SSD? Только в том, что мы можем ставить его в те, ранее выпущенные устройства, которые знают и умеют работать только с жесткими дисками.
Некая аналогия с . Мы можем поставить их там, где софт умеет работать только с ленточными библиотеками, как, например, какние-нибудь запрограммированные на Коболе мэйнфреймы 70-80-х годов. И при этом нам не надо ничего менять на стороне остальной системы.
Но в том случае, когда нас не заботит “обратная совместимость” с прежним оборудованием, если мы можем создать IT-систему с нуля, тогда нам, скорее всего, незачем эмулировать поведение ленточных библиотек, мы можем поддерживать диски нативно.
По моему наблюдению, именно это причина плохих продаж VTL в России, по сравнению со всем миром, где VTL совершенно явные фавориты, выпускаемые многими вендорами дисковых систем.
В России просто незначительна проблема “унаследованного оборудования” и “унаследованных решений” (legacy solutions), и проблема совместимости для “начисто” создаваемой IT-инфраструктуры минимальна.
Конечно конкретно NetApp VTL это не только эмуляция, но также множество других, зачастую уникальных фич, таких как Direct Tape Creation и дедупликация, но в основном все так.
Таким образом, EMC решило эту задачу минимально затратным и наименее “умным” способом, просто сэмулировав на высокоскоростных Flash-устройствах обычные диски, подобно тому, как VTL эмулирует “ленточные библиотеки” на дисковых массивах.
Если здоровый человек хорошо размахнется и ударит отбойным молотком, то, конечно, сможет использовать его в качестве обычной кувалды, но нативное его применение может быть гораздо эффективнее.
Возможен ли другой путь? Очевидно, что да.
Эмуляция дисков не единственный способ использования flash-памяти.
Вот, что у себя в блоге уже знакомый вам инженер-разработчик NetApp Костадис Руссос:
“Существует три возможных варианта ситуации с доступом к датасету:
1. Низкий уровень IOPS, малая нагрузка
2. Высокая нагрузка по IOPS, когда датасет помещается в кэш
3. Высокая нагрузка по IOPS, когда датасет НЕ помещается в кэш
Очевидно, что из этих трех сценариев только третий - кандидат на использование Flash-дисков.”
Однако NetApp выбрал иной путь, создав , модуль расширения кэша. Своеобразный “SSD”, но не в виде эмуляции дисков, как принято сейчас делать, а на уровне архитектуры системы в целом.
:
Практика показывает, что большинство данных это так называемые “холодные данные” (то есть данные, уровень обращений к которым невысок). Таким образом платить за высокую производительность для “холодных данных” есть очень дорогостоящее решение. Но если система хранения обеспечивает высокую производительность работы для “горячих” данных, даже если они при этом лежат на медленном хранилище, то цена Flash, как среды хранения данных, в таком случае значительно уменьшается.
Другими словами, да, жесткие диски 15KRPM не обеспечивают исключительно высокой производительности, но они обеспечивают достаточный уровень, для достаточного объема данных, оставляя для SSD Flash нишу.
Я довольно давно собираюсь развернуто написать про PAM и его устройство, те, кто был в этом году на NetApp Innovation 2009 наверняка слышал рассказ специалиста московского отделения компании, Романа Ройфмана, о Performance Acceleration Module.
Надеюсь в скором времени и я напишу подробный рассказ про PAM для читателей этого блога.
Команда консоли sysstat похожа на vmstat и iostat свернутые в одну команду. Она сообщает данные производительности систем хранения, такие как CPU utilization, размеры дискового трафика, объемы ввода-вывода, как сетевого, так и по FC, а также трафик передачи данных на ленту, если она используется. При запуске без опций, sysstat печатает новую строку каждые 15 секунд, с базовым набором информации. Вы можете прервать вывод нажав control-C (^c) или установить при запуске определенный интервал работы (-c count ) для автоматической остановки через заданное время.
Список ключей команды:
-f статистика FCP -i статистика iSCSI -b расширенная статистика SAN (’blocks’) -u расширенная статистика загрузки системы (’utilization’) -x расширенный (’extended’) формат вывода. Включает в себя все доступные поля вывода.
Обратите внимание, что вывод производится в формате шире чем 80 символов, и предназначен скорее для “off-line” анализа, чем для непосредственного чтения с экрана.
-m отображает статистику по загрузке CPU на многопроцессорных системах. Применимо только на многопроцессорных системах, не работает на однопроцессорных.
Описания некоторых колонок вывода команды sysstat.
Cache age : возраст в минутах старейшего read-only блока в кэше. Значение в этой колонке показывает, насколько быстро операции чтения проходят через память системы; когда система читает очень большие файлы, значение buffer cache age будет низким. Кроме этого, если чтение преимущественно случайное, то cache age также будет низок. Если вы столкнулись с проблемой низкой производительности на чтении, то значение этого поля сможет помочь определить что вам нужно больше кэша, или нужно проанализировать работу приложения, чтобы снизить уровень “случайности” его запросов.
Cache hit : Величина в процентах для WAFL cache hit rate. Показывает, в скольки процентах читаемых с WAFL блоков они оказывались при этом уже в кэше. Прочерк в этой колонке, означает, что в измеряемый период данные не читались.
CP Ty : Тип (’type’) Consistency Point (CP). Показывает, что было причиной создания CP в рассматриваемом интервале. Тип CP может быть:
- не было CP в заданный интервал (не было записей на диск в указанный период времени)
(число) число CP, созданных в заданном интервале
B : Back to back CPs (CP generated CP) (система настолько загружена, что она начинает писать новую CP сразу за окончанием записи предыдущей)
b : задержанные back to back CPs (CP generated CP) (условия, вызвавшие состояние back to back стали хуже)
F : CP вызван заполнением NVLog (половина nvram log была заполнена, и он был сброшен на диск)
H : CP вызван high water mark (редко встречается. Система полностью заполнила одну половину nvram logs, и решила сбросить данные на диск).
L : CP вызван low water mark
S : CP вызван операцией создания snapshot
T : CP вызван таймером (каждые 10 секунд система хранения сбрасывает данные кэша на диск (flush))
U : CP вызван сбросом данных на диск (flush)
: продолжение CP с предыдущего интервала (означает, что CP все еще создается, например во время 1-секундного интервала)
Символ, следующий далее, показывает проходящую фазу создания CP на момент окончания интервала замера. Если CP завершился полностью во время интервала измерения, то второй символ будет пустой. Фазы могут быть следующие:
0 Инициализация n обработка обычных файлов s обработка специальных файлов f сброс измененных данных на диск v сброс измененного суперблока на диск
Большинство перечисленных выше значений можно увидеть только в случае предельно малых интервалов замеров, или на сильно загруженных системах, так как сброс CP происходит очень быстро. Обычно в поле CP ty вы будете видеть ‘T’, штатный сброс Consistency Point по таймеру.
Давайте разберем пример.
sysstat.txt (для более удобного вида отключите в нотепаде word wrap и расширьте окно)
Что мы можем сказать о данной системе?
Это малозагруженная, практичеси находящаяся в покое система (параметры CPU, Disk Usage и Total), использующая CIFS и FCP (небольшие ненулевые значения показывают фоновые операции по этим протоколам). Большиство операций в этой покоящейся системе совершается в виде чтения содержимого кэша (значение Cache hit). Кэш практически пуст, на что указывает монотонное возрастание значения Cache age, данные лежат, и ничто их не вытесняет. Consistency Points создаются исключительно сбросом по таймеру, что нормальное поведение для незагруженной системы.
Довольно высокие значения Disk read write при малой загрузке CPU, практически нулевом сетевом траффике и операциях ввода-вывода по блочным протоколам указывает на работу процесса Disk Scrubbing, фонового процесса контроля целостности данных и дисков, при котором система перечитывает и перезаписывает данные на дисках, возможно также что работает дедупликация, хотя она обычно дает повыше чем 1-3% загрузку, также, возможно, это признак работы дефрагментации WAFL (wafl reallocate).
Так выглядит типичный вывод sysstat малонагруженной типовой системы NetApp FAS.
А вот так выглядит система под рабочей нагрузкой: sysstat3.txt
Как видите, уже заметно нагружен процессор (это FAS6070, поэтому запас еще весьма существеннен ;), около 20%. Так как система используется как SAN, то весь трафик идет по колонке FCP. Несмотря на заметную нагрузку, ниже приведенный отчет по utilization показывает производительность около 15000 IOPS, и около 23 MB/s чтения с дисков ( и 70-90MB/s по интерфейсам FC), это не перегрузило систему. Большой объем кэша на чтение позволяет 90% операций читаться из кэша, а не с дисков.
Возраст самого старого блока в кэше составляет примерно 10-12 минут, то есть кэш еще далек от заполнения.
Здесь уже периодически проскакивают символы, показывающие фазу сброса CP, и само время записи CP увеличилось, так как вырос объем записи, хотя он и составляет всего около 1/10 от объемов чтения.
Таким образом, используя даже штатные средства контроля и анализа системы, имеющиеся в административной консоли, можно увидеть много интересного.
Оригинал тут:
А вообще это, за исключением моего разбора примера вывода, практически перевод манов к команде из встроенного хелпа.
