Небольшое вступление
Мы в IBS хотели выйти на Хабр еще с тех времен, когда компьютеры выглядели как на этой картинке. Но постоянно чего-то не хватало: то, времени, то экспертов, то интересных сюжетов. Наконец-то все совпало и мы запускаем свой блог – в основном о внутрянке нашей тестовой лаборатории (IBS InterLab), где разрабатываются ит-инфраструктурные решения и тестируются технологии для клиентов, плюс немного по другим направлениям корпоративных ИТ. Писать будем редко, во всяком случае этим летом, но постараемся выдавать максимально полезный материал. Спасибо.
Поехали
Сегодня, наверное, практически весь крупный бизнес так или иначе работает с ERP или другими тяжелыми бизнес-приложениями. Естественно, со временем возникает необходимость переезда на виртуальные машины. Решать эту задачу с наскока – дело опасное, так как по ходу всегда вылезает целый мешок сюрпризов, каждый из которых вполне может обернуться полным провалом проекта. Чтобы такого не случалось, команда IBS InterLab занимается тестированием различных технологий под задачи клиента, и в рамках таких исследований нам удалось получить результаты, которые могут оказаться интересными и полезными.
С чего все началось?
Под задачи одного из заказчиков мы делали сравнительное тестирование производительности тандемов SAP + Oracle Database и SAP + HANA. Мы преследовали несколько целей: выяснить особенности поведения новой для российского рынка СУБД HANA и посмотреть возможности работы сертифицированного под HANA вычислительного комплекса от Huawei (об этом мы еще обязательно расскажем отдельно).
Однако жизнь – штука динамичная, и очень скоро (по меркам вселенной, да и НТП тоже) «на горизонте» появился разработанный в IBS универсальный конвергентный комплекс СКАЛА-Р. И хотя отработать специальные сложные тесты мы не успевали (но обязательно сделаем это в ближайшее время), оценить его реальные возможности при работе в боевых условиях, просто чесались руки. Важно было не просто проверить «работает/не работает» – в том, что работает, мы на 100% были уверены.
Хотелось сравнить производительность с каким-то известным продуктом. Поэтому приняли решение продолжить тестирование связки SAP + Oracle на нашей платформе, чтобы сравнивать с уже произведенным ранее тестом связки на VMWare.
Вводные данные
Тестовый комплекс, использовавшийся ранее, был реализован в облаке, что только увеличивало зуд в наших руках, поскольку несколько упрощало сравнение. Итак, в облаке СКАЛА-Р была создана идентичная виртуальная машина, отличавшаяся только тем, что если предыдущая была реализована с использованием другого гипервизора, то в данном тестировании применялся гипервизор от компании Parallels. К этой виртуальной машине был подключен LUN, собранный на дисковом массиве с использованием ПО Raidix. И именно с последним, а точнее с его масштабированием, у нас возникли определенные сложности: требовалось соотнести производительность дисковых подсистем – использовавшейся ранее и входящей в состав СКАЛА-Р.
Данную задачу мы решили путем сравнения прямых измерений производительности в IOPs. Получилось, что в первоначальном тесте реальная производительность виртуальной дисковой подсистемы составляла 1500 IOPs, а измеренная производительность выделенной LUN в СКАЛА-Р составила 1900 IOPs по IOMeter, что практически достигало теоретических 1998 IOPs, рассчитанных с помощью калькулятора. При этом для полноты картины нельзя не отметить, что результата 1900 IOPs нам удалось достичь только после существенного увеличения размера тестовых данных, так как на маленьких объемах слишком ударно работал кэш дискового массива, и мы получали запредельные 37100 IOPs.
Вот примерно с таким пониманием соотношения аппаратных ресурсов мы и приступили к тестированию. Но опять же, нельзя не отметить, что СУБД в тестах использовалась небольшая (немного меньше 1 Гб), что предопределило активное влияние кэша на результаты тестов.
Процесс испытаний
В ходе тестирования были выполнены прогоны трех десятков различного рода запросов, реализованных как через программу, написанную на ABAP, так и через стандартный функционал SAP R/3.
- Первая группа тестов. Здесь мы использовали 2-3 таблицы с большим количеством записей и полей в них (около 100), из которых делались выборки нескольких направлений. При этом критерии фильтрации подбирались таким образом, чтобы в несколько раз изменять количество возвращаемых записей для разных тестов:
- Выборка отдельных полей базы данных (строки 1 и 3). Выбиралось 3 поля, дальше условиями фильтрации обеспечивалось возвращение большого объема записей (несколько сот тысяч) или малого.
- Выборка всех полей записи (строки 2 и 4) из той же таблицы. Условия фильтрации оставались аналогичными.
- Выборка всех полей записи (строки 5-7, 13, 15, 17) из той же таблицы. Фильтрация осуществлялась по ключевому и не ключевому полям.
- Выборка одного поля записи (строки 8-12, 14, 16, 18) из той же таблицы. Фильтрация осуществлялась так же – по ключевому и не ключевому полям.
- Вторая группа тестов. В этом случае для строк 19-21 использовались запросы агрегированного типа, то есть подразумевающие выполнение агрегационных операций: по полю «величина проводки» при группировке записей по балансовым единицам и валюте проводки подсчитывалась сумма. Данная задача была включена в программу тестирования, поскольку HANA позиционируется как система, оптимизированная для аналитических приложений (а именно, для выполнения агрегационных запросов).
- Третья группа тестов. Следующий раунд испытаний включал выполнение выборок без фильтрации (строки 22-25), которые осуществлялись с использованием встроенного в SAP инструмента (просмотр содержимого таблицы – транзакция SE16), позволяющего просматривать содержимое таблиц. При этом устанавливалось максимальное для этой утилиты ограничение по количеству возвращаемых записей – 50 000.
- Четвертая группа тестов. Последними выполнялись синтетические тесты, являющиеся частью стандартной функциональности SAP R/3 (строки 26-29) и экстракторы данных собственной разработки для системы аналитической отчетности SAP BW (строки 30-34), обеспечивающие импорт данных из R/3 в BW. Экстракторы брали данные по заданным критериям: в основном периоды, за которые надо выбирать документы.
Каждый тест выполнялся по два раза, чтобы оценить уровни работы кэша. По их результатам стало очевидно, что при первой операции все данные считываются с системы хранения данных, а при втором выполнении работу оптимизируют механизмы кэширования. При этом, чтобы исключить влияние кэша сервера Oracle, перед проведением теста нового типа мы его обнуляли.
А теперь то, для чего все затевалось, – результаты тестов. По идее, никаких специальных пояснений к ним не требуется, поскольку все наглядно представлено в таблицах. Но если у вас появятся какие-либо вопросы, вы всегда можете задать их в комментариях, а мы оперативно и развернуто ответим. Итак, смотрим.
Подводим итоги
Так как на абсолютную научную точность мы не претендовали, то и выводы будем делать в достаточно свободной форме:
- Во-первых, весьма четко видно, как работает программный кэш Oracle: достаточно единственного прогона, чтобы время на выполнение операции существенно сократилось. Это можно отнести к преимуществам Oracle.
- Во-вторых, примерно одинаковым оказывается количество времени, затраченное на выполнение каждого первого теста, и практически эквивалентным – соотношение производительности дисковых подсистем (1500IOPs/1900IOPs). При этом нельзя не отметить, что при последующем выполнении однотипных тестов на СКАЛА-Р результаты улучшаются, что объясняется включением в работу кэша дискового массива, который в прошлых тестах, видимо, немного филонил.
- В-третьих, будем максимально беспристрастными и объективными, но все же при этом отметим, что наша СКАЛА-Р очень неплохо справилась с задачей поддержки ERP. Нами получены вполне адекватные результаты на платформе, обладающей конкурентным функционалом, но с заметно меньшей стоимостью по сравнению с привычными решениями на гипервизорах и дисковых массивах от известных производителей. При том, что для чистоты эксперимента было принято решение проводить тест на настройках «по умолчанию».
Если вам есть, что добавить, спросить, возразить или, так сказать, внести в нашу «книгу жалоб и предложений», будем рады продолжить дискуссию в комментариях.
Над постом работали эксперты: Александр Сашурин и Александр Игнатьев при деятельном соучастии Андрея Сунгурова.
Спасибо им.
Команда IBS Interlab.