IBS
Крупный разработчик сложных ИТ-решений
34,97
рейтинг
13 июля 2015 в 10:10

Разработка → ERP на СКАЛА-Р – тестируем производительность связки SAP и Oracle Database



Небольшое вступление


Мы в 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.
Автор: @kir_uh
IBS
рейтинг 34,97
Крупный разработчик сложных ИТ-решений

Комментарии (7)

  • +1
    Но все время чего-то не хватало: то, времени, то экспертов, то интересных сюжетов.

    С последним вы точно лукавите. Не хватает явно чего то другого. Никогда не поверю, что в жизни такой компании отсутствуют интересные сюжеты. Да они буквально валяются вокруг нас и ждут когда на них обратят внимание. Банальный(ну или не совсем банальный) предохранитель может быть темой не одной статьи, которую могут с увлечением читать десятки тысяч человек.
    • 0
      Не лукавим :) В унылый корп.блог превращаться не хотелось, а чтобы создать хороший пост нужно носителя интересного материала поймать, попросить записать или вытащить из него материал, а он уже на другом проекте и пр. Да и эксперты часто вообще не словоохотливые. Но теперь раз уж взялись, то будем делать. Кстати, если есть мнения относительно тем для постов и вообще, если есть какие-то вопросы к IBS, то welcome
  • 0
    По-моему, публикация результатов тестирования без описания тестируемых конфигураций и подробностей настройки — штука бессмысленная.

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


    К преимуществам перед чем? :)
    • 0
      И с чего они так уверены, что это именно кеш Оракл, а не кеш гипервизора? А что происходило на соседних виртуалках во время тестов? А чем еще система хранения загружена?

      Каждый тест выполнялся по два раза, чтобы оценить уровни работы кэша.
      Какого кеша? ОС? Гипервизора? СХД? Дисков? Может быть рейдконтроллера?

      что при последующем выполнении однотипных тестов на СКАЛА-Р результаты улучшаются
      Я полагаю, что это справедливо практически для любого железа. В чем фишка? Статья в духе «мы запустили программу в виртуальной машине на очень дорогом железе, смотрите что у нас получилось».

      но с заметно меньшей стоимостью по сравнению с привычными решениями на VMWare и дисковых массивах от известных производителей
      Дешевле ли, чем например решение от Nutanix? Требую цифры-сравнения. Цена близка к стоимости той же Exadata от Oracle.

      Вот данные за 2013 год
      A full-rack Exadata X-4 machine lists for US$1,100,000, while half-rack configurations cost $625,000, quarter-racks cost $330,000 and eighth-racks cost $220,000, according to Oracle’s latest price list.

      • 0
        Не совсем так, мы запускали программу на не дорогом железе россиийского производства, которое показало вполне достойные результаты. И мы честно написали, что не претендуем на высоконаучный труд.
        Если сравнивать по цене, то мы находимся в той же ценовой нише, что и Nutanix. Если нужна большая конкретика, то давайте сравнивать совершено конкретные конфигурации, а то дьявол в деталях: железо, ПО, внедрение, поддержка и некоторые другие жизненные неприятности.
        Если говорить о VMWare, то, Скала-Р однозначно дешевле, а на лавры Exadata мы даже близко покушаться не собирались, но я бы не стал сравнивать цену на железо для Exadata с чем-либо, т.к. это глубоко проприетарный продукт с очень специальной маркетинговой политикой.
  • 0
    Полностью согласен с комментариями выше, хотелось бы подробностей:

    Однако жизнь – штука динамичная, и очень скоро (по меркам вселенной, да и НТП тоже) «на горизонте» появился разработанный в IBS универсальный конвергентный комплекс СКАЛА-Р


    Какой именно? Какая конфигурация?

    Тестовый комплекс, использовавшийся ранее, был реализован в облаке, что только увеличивало зуд в наших руках, поскольку несколько упрощало сравнение. Итак, в облаке СКАЛА-Р была создана идентичная виртуальная машина, отличавшаяся только тем, что если предыдущая была реализована с использованием гипервизора VMWare, то в данном тестировании применялся гипервизор от компании Parallels.


    А где ранее происходило тестирование?
    • 0
      Не уверен, что тут уместно говорить о конфигурации системы (или я не вполне корректно понял вопрос). Мы ставили эксперимент на небольших виртуальных машинах с идентичными конфигурациями:
      2 vCPU
      8GB RAM
      /dev/sda1 30GB / ext3
      /dev/sdb1 16GB swap
      /dev/sdc1 500GB no-mount /ext3
      SUSE Linux Enterprise Server 11 (x86_64)
      VERSION = 11
      PATCHLEVEL = 3
      И под VMWare и на Скала-Р.

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

Самое читаемое Разработка