Привет, Хабр! Я работаю стажёром в питерском Центре развития EMC и хочу дать студентам несколько советов по построению будущей карьеры, а также рассказать им о задачах, которыми занимаюсь в компании.
В этом году за одно из своих решений я получила премию Bright Internship Award как лучший стажер Центра, и мне интересно получить обратную связь о достигнутых результатах.
Эта статья может быть интересна тем, кто занимается тестированием производительности систем.
Немного текстов (или как я перестал бояться и попал на стажировку)
История моего знакомства с EMC начинается с поездки на IT-выставку для молодых абитуриентов в сфере информационных технологий — Bit-Byte. Я обошел все корпоративные стенды, заполнил десятки весьма сомнительных форм и взял несколько визиток.Когда вы хотите быстро начать набираться опыта работы по специальности и получать за это деньги, вы не особо задумываетесь о том, с чего начать свою карьеру.
Многие компании заявляют, что к ним приходят студенты, которые знают свое место на ИТ-рынке, свои продукты, клиентов и т. д. Но, исходя из своего личного опыта, могу сказать, что это не так.
90% студентов просто рассылают резюме на все возможные должности в несколько компаний, даже не меняя текст под конкретную вакансию.
И я не был исключением: придя домой, я разослал свое резюме по всем адресам электронной почты, которые были на взятых мной визитках.
Мне всегда казалось, что это в порядке вещей: каждый месяц сотни людей присылают письма с отзывами, десятки приглашаются на собеседования, но берут на работу единиц.
Это заставит вас охватить как можно более широкий круг компаний в вашем списке рассылки, чтобы увеличить ваши шансы на получение работы.
На следующий день я уже решал различные тестовые задания, а через неделю меня пригласили на несколько собеседований.
Так получилось, что после первого посещения ЕМС мне отказали.
Это заставило меня более серьёзно отнестись ко второму интервью.
Вопросы, задаваемые во время интервью, выходят за рамки данной статьи, могу лишь сказать, что эти две встречи были совершенно разными.
На одном из них мне давали возможность решать алгоритмические задачи, а на другом было много вопросов на общие знания в области ИТ.
Когда меня приняли на работу в EMC, я заканчивал третий курс бакалавриата.
Тогда я прекрасно понял, что сейчас самое время попробовать свои силы в реальных проектах, в команде профессионалов, у которых я могу многому научиться.
Так получилось, что именно EMC стала моей отправной точкой в мир промышленного развития.
И спустя полтора года я могу смело сказать, что это отличное место для старта.
В программе стажировки многое зависит от закрепленного за вами наставника, ведь именно он будет ставить вам первые задачи, подсказывать и контролировать выполнение поставленных задач, выбор методов их решения и т. д. огромный плюс, если это тот человек, который проводит ваше собеседование.
Я думаю, что многие опытные разработчики стараются найти на должность стажера студента, близкого по духу и другим сугубо личным качествам, помимо профессиональных знаний, навыков и умений.
Именно этот творческий союз дал мне огромный потенциал для будущих свершений.
Сейчас могу с уверенностью сказать, что мне очень повезло с наставником.
Я не помню каких-то особенных первых впечатлений от работы в команде крупной корпорации.
Я прекрасно знал, в каких условиях работают сотрудники в компаниях такого уровня.
Хабр кишит отзывами разработчиков, перешедших в Google, Yahoo, Amazon и другие корпорации, со всеми подробностями и красками заокеанской жизни.
Скорее, меня просто порадовал тот факт, что у меня появилась возможность работать по специальности.
Да, атмосфера здесь сильно отличается от той, что царит в стенах университета; было приятное ощущение новизны и незнания происходящего.
Запись об оценке эффективности
Моя работа в компании связана с оптимизацией производительности продукта EMC PowerPath. В общих чертах, это программное обеспечение, работающее на серверах в сети SAN, которое оптимизирует использование путей в сетях хранения FC, iSCSI и FCoE для обеспечения предсказуемого, масштабируемого и согласованного доступа к информации.Это программное обеспечение обеспечивает эффективное использование всех путей к данным и устраняет необходимость в нескольких отдельных решениях по управлению путями для разных операционных систем.
Оптимизация всегда затрагивает многие аспекты разработки программного обеспечения; вы должны хорошо понимать функционал продукта, уметь его тестировать и автоматизировать выполняемые действия.
Поначалу было довольно сложно понять логику продукта, а процесс адаптации к имеющемуся коду занял довольно много времени.
Пришлось быстро освоить Perl, инструменты для профилирования различных операционных систем, оболочку и стандартные утилиты Windows и Unix. В данном конкретном случае тестирование состоит из динамической проверки поведения программы на конечном наборе тестов; сама программа представлена как «черный ящик».
В этом случае тесты выбираются из часто выполняемых действий предметной области и обеспечивают проверку соответствия ожидаемому поведению системы.
Очень часто при разработке программного комплекса приходится сталкиваться с одной из двух проблем.
Либо качество разрабатываемого продукта ниже минимальных требований; или затраты на тестирование превышают все разумные пределы.
Чтобы снизить затраты на тестирование поведения программы в различных средах, необходимо максимально автоматизировать этот процесс.
Именно за создание встроенных в ОС инструментов автоматизации тестирования EMC PowerPath и многопутевой системы я получил премию EMC Bright Internship Award. Такой подход к тестированию производительности позволил нам значительно улучшить производительность продукта за счет выявления проблем (узких мест), решение которых обеспечило существенный прирост производительности (особенно на платформе AIX (> 30%)).
Суть такова: измерение пропускной способности базовых утилит ОС проводится для сравнения полученных расчетов с результатами для программного продукта от EMC, развернутого с различными физическими и программными компонентами подсистемы.
Это делается без дополнительного времени, автоматизировано и унифицировано.
Нам нужен был комплекс, который был бы высокопроизводительным и универсальным с точки зрения возможности использования для автоматизации тестирования на любых операционных системах (AIX, ESXi, RHEL, WS), а также не требовал бы значительных трудозатрат на его использование.
Далее я расскажу вам, как я это сделал.
Что было сделано
Для начала определимся с программным обеспечением для генерации данных (I/O бенчмарками) — это приложение, позволяющее запустить синтетический тест дисковой и сетевой подсистем, как для одиночных, так и для кластерных систем.Его можно использовать в качестве основного инструмента для лабораторных испытаний и устранения неполадок.
Может быть легко настроен для моделирования нагрузки (моделирования поведения) многих популярных приложений путем указания тестовых шаблонов.
Для тестирования механизма балансировки, используемого в продукте, с точки зрения оценки его производительности, я использую три различных программных продукта для генерации блоков данных: Iometer, Iorate и Vdbench. Их сравнительные характеристики приведены в таблице:
Имя | ЯП | Открытый источник | Поддерживаемая ОС | Генерация случайных блоков данных |
---|---|---|---|---|
лометр | С++ | Да | Windows, Linux, Солярис, Сетевое ПО | Нет |
лорат | С | Да | AIX, HP-UX, HP-US, Solaris zLinux, Linux | Нет |
Vdbench | Джава | Да | Все основные | Да |
Такие системы хранения хранят только ссылки на повторяющиеся блоки (например, по 4 КБ каждый), что гораздо быстрее, чем запись целого блока.
Исходя из этого, загрузка повторяющихся данных для некоторых СХД не позволяет получить адекватные результаты производительности, и в этом случае используется Vdbench. Для того чтобы запустить программу генерации данных, ей необходимо на вход подать конфигурационный файл, в котором будут описаны все параметры предстоящего запуска.
Для проверки производительности систем хранения и инструментов балансировки нагрузки между путями данных я использую два типа тестов:
- UIO (Uniformed I/O) — тесты с фиксированным размером данных, каждый из которых основан только на одном шаблоне.
- DBSIM (DataBase SIMulation) — тесты, основанные на смешивании различных шаблонов в определенном соотношении для эмуляции работы реальной бизнес-системы, например, OLTP. При таком подходе блоки разного размера отправляются по очереди.
Каждый тест может состоять из одного или нескольких шаблонов, указанных в процентах.
Шаблон имеет следующие параметры:
- Размер блока данных;
- % читай пиши;
- % случайного/последовательного ввода-вывода, шаблон доступа к диску при чтении или записи блока.
При модели последовательного доступа к диску запись и чтение происходят намного быстрее, поскольку операция произвольного доступа отсутствует.
Актуально только для устройств, работающих на принципе магнитной записи.
Для пояснения вышеизложенного в таблице приведен список тестов UIO для тестирования производительности:
Название теста | Размер, байты | % чтения | % случайная модель |
---|---|---|---|
4K_Seq_Read_Only | 4096 | 100 | 0 |
64K_Rand_Write_Only | 65536 | 0 | 100 |
256K_Rand_Read_50 | 262144 | 50 | 100 |
- Время выполнения – время, в течение которого все полученные результаты расчета будут влиять на конечный результат. Обычно измеряется в секундах.
- Время прогрева — время прогрева, в течение которого результаты расчета не включаются в конечный результат. Измеряется в секундах.
- Время паузы - время простоя между тестами.
Измеряется в секундах.
- Скорость ввода-вывода — максимально возможная скорость передачи данных, измеряемая в операциях чтения/записи в секунду (IOPS), без ограничений по умолчанию.
Каждая из трёх программ — Iometer, Iorate, Vdbench — генерирует один или несколько выходных файлов, содержащих помимо полезной для дальнейшего анализа информации различные вторичные данные о запуске.
Поэтому необходимо разработать скрипты, которые позволят анализировать полученные файлы с целью извлечения и преобразования данных в нужный унифицированный формат. Для автоматизации процесса получения визуальной информации о текущем состоянии балансировщиков нагрузки необходимо унифицировать результаты тестирования, полученные от разных операционных систем и разных генераторов данных.
Для этого необходимо разработать специальные скрипты, которые можно будет запускать абсолютно на всех платформах, поддерживаемых данным генератором.
Эти скрипты, помимо генерации результирующего файла, должны будут полностью управлять процессом тестирования, протоколировать выполненные операции и текущую конфигурацию системы.
Также скрипты должны иметь возможность изменять политики балансировки нагрузки, проверять доступность и доступность устройств.
Конфигурация «лаборатории» для исследований
Остановимся подробнее на организации «лаборатории» для исследований:Стандартная конфигурация системы
Принимающая сторона: За исключением AIX с проприетарными хостами IBM, используются физические машины Dell PowerEdge R710: Память: 11898 МБ ОЗУ Процессор: Intel Xeon E5530 @ 2,40 ГГц Процессор: 2394,172 МГц Размер кэша: 8192 КБ с 2 физическими сокетами, 8 физическими ядрами, 8 ядрами Hyper-Threading. Другие настройки хоста, в зависимости от тестового примера: ОС: ESXi, RHEL, Windows Server, AIX. Количество ядер: 4/8/16 Логические единицы: 4/8/16 Размер логического устройства: 5 ГБ (маленькие диски для максимального количества операций ввода-вывода в секунду) Потоков на LU: 64 для 4 LU, 32 для 8 LU, 8 для 16 LU, 4 для > 16 LU Сторона хранения: EMC XtremIO, конфигурация с 1 X-Brick EMC Симметрикс VMAX ЭМС VNX САН: Выделенный коммутатор FC, порты Fibre Channel 8 Гбит/сСтандартные заводские настройки по количеству адаптеров FC
Конфигурация помех
Конфигурация тестирования помех используется для имитации узких мест в сети SAN. Конкретно на этой иллюстрации используется ОС Windows Server, хотя на самом деле это может быть что угодно.
В системе используются два хоста: один с предустановленным PowerPath (позже MPIO), на котором выполняются расчеты производительности; другой - нагрузка.
Каждый сервер подключен через разные сети SAN к системам хранения данных.
Загруженный путь к данным отмечен красным, свободный — зеленым.
Адаптивная политика PowerPath определяет степень загруженности пути и позволяет перераспределить нагрузку на свободный.
Такая конфигурация позволяет создать условия, которые вполне могут возникнуть в реальной лаборатории для заказчиков (неудачный определённый путь, неграмотная конфигурация, один общий SAN на несколько серверов и т.п.
).
Условия, в которых встроенное многопутевое соединение будет работать со скоростью самого медленного пути, а PowerPath должен показывать значительно более высокие значения операций ввода-вывода в секунду.
Результаты представлены в виде графиков, построенных с помощью программы Gnuplot. Имеет собственную систему команд, может работать в режиме командной строки и выполнять скрипты, считанные из файлов.
Gnuplot способен как сохранять графики в виде файлов в различных графических форматах (командный режим), так и отображать их на экране.
На рисунке представлена полная блок-схема автоматизированного тестирования: от настройки до получения результатов, подлежащих дальнейшей оценке.
Тестовая конфигурация
Давайте подробнее рассмотрим конфигурацию тестирования.Важным параметром при запуске сценариев тестирования является количество запусков.
Часто при тестировании PowerPath и NMP возникает проблема отклонения полученного значения производительности от среднего значения, выраженного в процентах.
В данной работе в качестве допустимого отклонения было решено принять значение менее или равное 5%.
Если разброс от среднего значения всех прогонов превышает установленный предел, то мы не можем оценить пропускную способность, и такие тесты требуют дальнейшего анализа и репликации.
В качестве примера ниже приведен результат реального теста DBSIM. Для построения гистограмм использовался Gnuplot, на входе которого генерировался специальный скрипт. Весь функционал по построению результирующих изображений был написан на Perl. Я не могу вдаваться в подробности реализации данного объекта автоматизации ввиду коммерческой тайны.
По оси «у» показано отклонение конкретного запуска от среднего значения в % (пропускная способность).
Ориентируясь на ось «х», мы видим, к какой версии PowerPath или NMP (Native Multipathing, встроенный инструмент балансировки) относятся эти результаты.
На графике хорошо видно, что в некоторых тестах есть прогоны с отклонением более 5%, а некоторые близки к этому значению.
Такое тестирование требует дальнейших исследований.
Само отклонение связано в первую очередь с физической и программной реализацией конкретной СХД.
Это также может быть вызвано наличием большого количества потоков, управляющих отправкой и получением данных с диска.
Данное явление встречается не на всех СХД и практически не зависит от генератора ввода-вывода.
Помимо количества запусков, на объективность итоговых результатов влияют следующие параметры:
- время работы;
- Время разминки;
- Время паузы.
В конфигурациях, где наблюдался большой разброс результирующих данных, тесты запускались с длительным временем выполнения, а значения пропускной способности протоколировались с интервалом в 10 секунд. С помощью статистического анализа полученных результатов можно разумно выбирать различные временные интервалы и количество прогонов для конкретных тестов в заданной конфигурации.
Эти интервалы можно суммировать для получения временных интервалов любой продолжительности.
По таким суммам рассчитывают относительное стандартное отклонение (RSD или относительное стандартное отклонение, также называемое коэффициентом вариации), характеризующее однородность данных, что является ценной статистической характеристикой.
По величине коэффициента вариации можно судить о степени изменчивости характеристик популяции.
Чем больше его значение, тем больше разброс относительно среднего значения, тем менее однородна по составу популяция и менее репрезентативна средняя величина.
Коэффициент вариации (1) представляет собой отношение стандартного отклонения (2) к среднему арифметическому (4), выраженное в процентах.
Стандартное отклонение, в свою очередь, можно найти как корень дисперсии (3).
N — количество независимых испытаний.
В отличие от отклонения от среднего, на которое мы обращали внимание при построении гистограмм, RSD позволяет наиболее точно представить дисперсию признака и его величину относительно самих значений (относительный показатель, а не абсолютный).
Теперь выберем временной интервал для конкретного теста и будем считать приемлемым, если значение RSD для всех таких интервалов меньше или равно 5%.
После того, как расчеты проведены и временные интервалы перераспределены, повторим тестирование и построим графики с помощью того же Perl-скрипта.
Отклонение от среднего заметно уменьшилось и результаты тестирования стали наиболее точно отражать реальную картину производительности ПО.
Как результат
Подведем итоги проделанной работы:- Такая реализация автоматизированного тестирования производительности средств балансировки нагрузки позволяет быстро получить окончательные результаты тестирования, наглядно отражающие текущую производительность продукта относительно решений, поддерживаемых производителями ОС.
- Разработчики продуктов для конкретных платформ могут количественно оценить степень улучшения/ухудшения производительности по сравнению с предыдущими версиями.
- Для конфигураций, где имеется разброс конечных результатов, была проведена аналитическая работа, обеспечивающая существенно более стабильные результаты.
В частности, благодаря такому подходу нам удалось повысить производительность EMC PowerPath на AIX более чем на 30%.
Напутственные слова студентам
Хочу посоветовать Вам не откладывать начало карьеры по специальности, ведь опыт работы в профессиональной сфере ценится превыше всего.По окончании обучения помимо научных публикаций, общих знаний и среднего балла желательно иметь опыт, связанный с практикой и «боевым» применением знаний.
И тогда вас будут высоко ценить как специалиста с соответствующими навыками, способного участвовать в реальных проектах и приносить прибыль.
Теги: #тестирование производительности #EMC #PowerPath #глушение #тестирование #оптимизация #Системы хранения #системы хранения данных #Высокая производительность #Тестирование ИТ-систем
-
Спамеры Сдаются?
19 Oct, 24 -
Микрофронтенды. Учимся На Ошибках
19 Oct, 24 -
Целевой Блок Iscsi
19 Oct, 24 -
Секреты Тернарного Оператора
19 Oct, 24