Наши статусы

Public cloud since 2008

VMware Hybrid Cloud Powered

VMware Enterprise Service Provider

Центр компетенции

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

Центр компетенции

DRS в облаке

Организация площадки DRS в публичном облаке

Скачайте книгу!

Наша электронная книга IaaS для бизнеса по кирпичикам для генеральных и коммерческих директоров

Iaas для бизнеса по кирпичикам

Узнавайте первыми о новых постах в нашем блоге, получайте приглашения на мероприятия

 

Тестирование NetApp E2700

01.01

Тестирование NetApp E2700


Мне давно не попадался на тесты массив начального уровня, способный пропустить через один контроллер до 1.5 Гб/сек при потоковой нагрузке. NetApp E2700 как раз справился с этой задачей. В июне я провёл Unboxing NetApp E2700. И теперь готов поделиться с вами результатами тестирования этой системы хранения данных. Ниже привожу результаты нагрузочных тестов и получившиеся количественные показатели производительности массива NetApp E-Series 2700 (IOps, Throughput, Latency).

Конфигурация дискового массива следующая:


Схема подключения массива к серверу:


И конфигурация тестового сервера:



Методика проведения тестирования
В качестве генератора нагрузки я использую FIO benchmark, как самый «true» benchmark под Linux. Я хочу получить данные по средней скорости (bandwith, Mb/s) и усредненным задержкам (latency, ms) при следующих типах нагрузки:

  1. 100% последовательное чтение, блоками по 256 kb, 512 Kb и 1024 Kb;
  2. 100% последовательная запись, блоками по 256 kb, 512 Kb и 1024 Kb;
  3. Смешанные последовательные чтение/запись (50/50), блоками по 256 kb, 512 Kb и 1024 Kb;
  4. 100% случайное чтение, блоками по 4 kb, 8 Kb и 16 Kb;
  5. 100% случайная запись, блоками по 4 kb, 8 Kb и 16 Kb;
  6. Смешанные случайные чтение/запись (50/50), блоками по 256 kb, 512 Kb и 1024 Kb;
При этом я буду использовать два LUN с массива, каждый размером по 1 Тб, которые доступны на уровне сервера как RAW устройства: sdb и sdc.

Важным моментом моих тестов является сравнение производительности различных уровней RAID, которые поддерживает массив. Поэтому я буду поочередно подавать нагрузку на LUN, созданные на: DDP, RAID6, RAID10. И Dynamic Disk Pool и Volume Groups я буду создавать на базе всех 24 дисков.

Для того чтобы не ставить результаты в зависимость от алгоритма работы пресловутого «Linux memory cache», я использую именно блочные устройства, без организации поверх них файловой системы. Безусловно, это не самая стандартная конфигурация для потоковых приложений, но мне важно понять, на что способен именно массив. Хотя, забегая вперед, скажу, что при использовании в паттерне нагрузки FIO параметров direct=1 и buffered=0 работа (запись) с файлами на уровне EXT4 показывает почти одинаковые результаты с блочными устройствами по bandwith. При этом показатели latency при работе с файловой системой выше на 15-20 процентов, чем при работе с raw devices
Паттерн нагрузки для FIO сконфигурирован следующим образом:

Код
[global]
description=seq-reads
ioengine=libaio
bs= см. выше
direct=1
buffered=0
rw=[write, read, rw, randwrite, randread, randrw]
runtime=900
thread
 
[sdb]
filename=/dev/sdc
iodepth=см. ниже
 
[sdc]
filename=/dev/sdb
iodepth=см. ниже
Если я правильно понял, man по fio, параметр iodepth, определяет количество независимых потоков, работающих с диском одновременно. Соответственно, в конфигурации я получаю количество потоков равное X*2 (4, 8, 16).

В результате набор тестов у меня получился следующий:


С методиками разобрались, паттерны определили, даем нагрузку. Для облегчения труда админа можно нарезать набор паттернов FIO в виде отдельных файлов, в которых будут меняться значения двух параметров – bs и iodepth. Потом можно написать скрипт, который в двойном цикле (меняем значения двух параметров) выполнит прогон всех наших паттернов с сохранением нужных нам показателей в отдельные файлы. 

Да, чуть не забыл пару моментов. На уровне массива я конфигурировал параметры кэша следующим образом:
  • для потоковой записи я выключал кэш на чтение;
  • для потокового чтения, выключал, соответственно, кэш на запись, и не использовал алгоритм dynamic read prefetch;
  • для смешанных операций чтения и записи активировал кэш полностью.
На уровне Linux я менял штатный планировщик I/O на noop при потоковых операциях и на deadline при рандомных. Кроме этого, для грамотной балансировки трафика на уровне HBA я установил multipath-драйвер от NetApp, MPP/RDAC. Результаты его работы меня приятно удивили, балансировка потока данных между портами HBA выполнялась почти 50-на-50, чего я никогда не наблюдал ни у Qlogic, ни у штатного linux multipathd.

SANTricity имеет ряд настроечных параметров (я уже писал выше, например, про управление кешированием данных на уровне тома). Еще один потенциально интересный параметр это Segment Size, который можно задавать и изменять на уровне тома. Segment Size – это блок, который контроллер записывает на один диск (данные внутри сегмента записываются блоками по 512 байт). Если я использую DDP, то размер этого параметра для всех томов, созданных в пуле, одинаков, (128k) и изменить его нельзя.

Для томов, создаваемых на базе VolumeGroup, я могу выбирать преднастроенные шаблоны нагрузки для тома (FileSystem, Database, Multimedia). Кроме этого, я могу выбрать размер SegmentSize самостоятельно в диапазоне от 32 Кб до 512 Кб.



Вообще для встроенных Volume I/O characteristics type размер Segment Size не отличается особой разнообразностью:
  • Для паттерна File system = 128 Kb;
  • Для паттерна Database = 128 Kb;
  • Для паттерна Multimedia = 256 Kb.
Я не изменял предлагаемый по умолчанию при создании тома паттерн (File system) для того, чтобы Segment Size для томов, создаваемых на DDP и на обычной VolumeGroup, был одинаковым.

Безусловно, я поиграл с размером Segment Size, чтобы понять, как он влияет на производительность операций записи (для примера). Результаты вполне стандартные:

  • При самом малом размере, SS = 32 Кб, я получаю более высокие показатели производительности при операциях с небольшим размером блоков;
  • При самом большом размере, SS = 1024 Кб, я получаю более высокие показатели производительности при операциях с большим размером блоков;
  • Если я выравниваю размер SS и размер блока, которым оперирует FIO, то результаты получаются еще лучше;
  • Есть одно «но». Я обратил внимание, что при потоковой записи большими блоками и SS = 1024 Кб значения latency получаются выше, чем при размере SS = 128 Кб или 256 Кб.
Итого, полезность этого параметра очевидна, и если мы предполагаем, что у нас будет много рандомных операций, то имеет смысл задать его равным 32 Кб (если, конечно, мы не используем DDP). Для потоковых операций я не вижу смысла задавать значение SS по максимуму, т.к. кардинального прироста скорости передачи данных я не наблюдал, а показатели latency могут быть критичными для приложения.

Результаты (оценка и сравнение результатов)
Результаты тестов по DDP

Результаты тестов на RAID6


Результаты тестов на RAID10

Оценка результатов
  1. Первый момент, на который я сразу обратил внимание, это 0% использования кэша на чтение при любом паттерне (и даже при полностью выключенном кэше на запись). С чем это было связано, понять так и не удалось, но результаты по операциям чтения проседали по сравнению с операциями записи ощутимо. Возможно, это связано с одноконтроллерной конфигурацией тестового массива, так как кэш на чтение должен зеркалироваться между двумя контроллерами.
  2. Второй момент, это достаточно низкие показатели по рандомным операциям. Объясняется это тем, что размер Segment Size (как я писал выше) по умолчанию использовался равным 128 Кб. Для небольших размеров блоков такой размер SS не подходит. Для проверки я запускал рандомную нагрузку на томах в RAID6 и RAID10 с SS = 32 Кб. Результаты получались гораздо более интересными. Но в случае с DDP мы не имеем возможности менять размер SS, поэтому рандомная нагрузка на DDP противопоказана.
  3. Если сравнивать производительность DDP, RAID6 и RAID10 при размере SS =  128 Кб, то можно отследить следующие закономерности:
  • В целом большой разницы между тремя разными логическими представлениями блоков не выявлено;
  • RAID10 стабильнее держит нагрузку, даже смешанную, выдавая при этом лучшие показатели latency, но проигрывает в скорости потоковой записи и чтения RAID6 и DDP;
  • RAID6 и DDP при рандомных операциях при увеличении размера блока показывают лучшие значения latency и IOps. Скорее всего, это связанно с размером SS (см. выше). Однако RAID10 не показал такого эффекта;
  • Как я уже написал выше, рандомная нагрузка для DDP противопоказана, во всяком случае при размерах блоков меньше 32 Кб.
Выводы

Мне давно не попадался на тесты массив начального уровня, способный пропустить через один контроллер до 1.5 Гб/сек при потоковой нагрузке. Можно предположить, что двухконтроллерная конфигурация сможет обработать до 3 Гб/сек. А это поток данных до 24 Гбит/сек.

Конечно, тесты, использованные нами, являются синтетическими. Но показанные результаты очень неплохие. Как и предполагалось, массив слабо держит смешанную нагрузку при рандомных операциях, но чудес не бывает :-).

В плане юзабилити и возможностей оптимизации настроек под конкретный шаблон нагрузки для массива начального уровня E2700 показал себя на высоте. SANTricity имеет понятный и достаточно простой интерфейс, минимум глюков и тормозов. Нет излишних настроек значений, которые зачастую не понятны (вспоминаю управляющий интерфейс IBM DS 4500 - это было что-то)). В целом все на твердую «4».


Баяндин Е.А., директор по технической поддержке и сопровождению ООО «С 7 Трэвел Ритейл»

«Для размещения наших сервисов мы рассмотрели множество поставщиков услуг, по итогу выбрали компанию ИТ-ГРАД. Для начала перенесли тестовую среду, сейчас размещаем и часть продуктива. За время сотрудничества компания ИТ-ГРАД продемонстрировала ответственный и компетентный подход к выполнению поставленных перед ними задач.»

Все отзывы

Меркуданов Н.А., зам. генерального директора ООО «Бизнес Решение»

«На этапе выбора поставщика мы подвергли „ИТ-ГРАД“ всесторонней проверке как с технической, так и с организационной точки зрения. В процессе „ИТ-ГРАД“ показал себя с наилучшей стороны и остается нашим надежным партнером уже почти два года.»

Все отзывы

Отзыв руководителя информационно-аналитического управления РПЦ В.Кипшидзе

«Выражаем искреннюю благодарность и признательность ООО „ИТ-ГРАД“ и лично генеральному директору Гачко Д.В. за поддержку, оказанную православному интернет-проекту Prihod.ru, надежному партнеру Русской Православной Церкви в области медиа- и интернет-технологий.»

Все отзывы

Отзыв заместителя начальника отдела автоматизации ООО «Мицар» Алексея Доманникова

«Мы столкнулись с проблемой очистки почты от больших объемов вирусов и спама. ИТ-ГРАД обеспечил нас виртуальным сервером и необходимым количеством лицензий Spam Titan, соответствующим текущим потребностям компании.»

Все отзывы

Венедиктова Р.Э., генеральный директор ООО «Прометей»

«На протяжении уже более двух лет данная компания предоставляет нам услуги по организации виртуальной инфраструктуры на базе технологии VMware. Наш бизнес - это телекоммуникационные услуги, биллинг которых является одной из важнейших бизнес-задач компании "Прометей". Благодаря техническим решениям "ИТ-ГРАД" биллинг наших услуг обеспечивается на высочайшем уровне.»

Все отзывы

Андрей Охрименко, ит-директор интернет-магазина «Boutique.ru»

«На данный момент мы отказались от 30 рабочих станций и перевели клиентов на виртуальные десктопы на основе решения VMware View, развернутые в публичном облаке «IT-GRAD». Инфраструктура рабочих станций приведена к стандартному виду, что облегчает её поддержку, уменьшает время реакции на инциденты и облегчает процесс ввода/вывода новых рабочих мест для сотрудников.»

Все отзывы

Гениральный директор ООО «Комплект»

«На протяжении длительного времени наша компания сотрудничает с «ИТ-ГРАД». Мы пользуемся такими услугами как организация рабочего места, телефония OCS, аренда 1С и хостинг почтового сервера. Благодаря работе специалистов этой компании все наши сотрудники приносят значительный вклад в развитие бизнеса.»

Все отзывы

Иващенко Елена Валентиновна, заместитель генерального директора ООО «Мосрегионвент»

«На протяжении 2 лет мы успешно сотрудничаем с компанией ИТ-ГРАД. Мы арендуем конфигурации 1С: Бухгалтерия 8.2 и 1С: Управление торговлей 8.2. Данные конфигурации были доработаны техническими специалистами ИТ-ГРАД в соответствии с нашими пожеланиями, за что выражаем им отдельную благодарность.»

Все отзывы

Карпухин Вячеслав, директор по информационным технологиям ООО «АРМАКС Групп»

«На основе выделенной инфраструктуры было организовано 2 виртуальных сервера: терминальный сервер+сервер 1С и сервер БД. Данный подход к организации ИТ позволил нам обеспечить качественную инфраструктуру для бухгалтеров и избежать капитальных затрат.»

Все отзывы

Шевченко Марина Сергеевна, директор ООО «Поверенный» (Бухгалтерский аутсорсинг)

«В «облачном» сервисе от «ИТ-ГРАД» привлекает защищенность данных. Можно быть уверенными в том, что будет использовано только лицензионное программное обеспечение и защищенное пространство.»

Все отзывы

Борис Грейдингер, директор по ИТ Компании ESET

«Мы остались довольны качеством услуг, предоставленных компанией «ИТ-ГРАД». Можем отметить качество технической поддержки и готовность оперативно предоставить все необходимые консультации. Готовы рекомендовать аренду виртуальных машин «ИТ-ГРАД» как гибкое решение, позволяющее избежать значительных затрат на построение собственной инфраструктуры.»

Все отзывы

Павел Власов, директор «Информационные сервисы ЖКХ»

«За время работы с командой «ИТ-ГРАД» выделены следующие преимущества используемых услуг: доступность, цена, гибкость и мощность самой платформы VMware. Удобно делать обновления наших систем, предварительно либо делая полный backup виртуальной машины, либо snapshot с возможность очень быстрого отката...

Все отзывы

Delivery Club: как облако IaaS помогает в организации сервиса по доставке еды

Читать полностью

PickPoint – первая в России сеть постаматов: 5 лет в облаке IaaS

PickPoint: – первая в России сеть постаматов: 5 лет в облаке IaaS

Читать полностью

IaaS в ритейле: опыт сети магазинов Hamleys

IaaS в ритейле: опыт сети магазинов Hamleys

Читать полностью

FitnessBar.ru: IaaS для крупнейшей сети магазинов спортивного питания и аксессуаров

Читать полностью

Первый БИТ: использование IaaS облачным провайдером для предоставления SaaS-сервиса

Читать полностью

ЦРТ: «Речевые технологии» из облака IaaS-провайдера

Читать полностью

Prihod.ru: опыт использования облака IaaS крупнейшим православным интернет-проектом в России

Читать полностью

×Ваша заявка принята!
Ссылка на скачивание книги придет Вам на электронную почту.
×Ваше сообщение успешно отправлено.
Спасибо за регистрацию!

Test

Order

×
×Your message was successfully sent.
Thank you for registration!

Тестировать

Заказать

×

тестировать

заказать

×

тестировать

заказать

×

тестировать

заказать

×

тестировать

заказать

×

тестировать

заказать

×

тестировать

заказать

×