компания «Онланта» (группа компаний ЛАНИТ)
Среди ИТ-директоров распространено мнение, что ERP из облака покупают компании из сегмента среднего и малого бизнеса, а большим организациям необходимо выстраивать собственный комплекс с предварительным долгим, мучительным и непременно недешевым сайзингом. Как показало наше тестирование ERP в облаке, в определенных случаях оптимальными являются иные решения проблемы. Опытным путем мы выяснили, какое максимальное количество одновременно работающих пользователей может быть в ERP-системе, размещенной в облаке.
Гибкое управление вычислительными мощностями
Планирование серверных мощностей для развертывания «тяжелых» корпоративных систем (например, ERP) – всегда непростая задача. При традиционном подходе – создании собственной корпоративной ИТ-инфраструктуры и покупке оборудования – сохраняется риск ошибок, приводящих к избыточным мощностям либо к нехватке вычислительных ресурсов при пиковых нагрузках, при увеличении количества пользователей или при расширении функциональности системы. Пиковые нагрузки предсказуемо возникают в отчетные периоды или сезоны активных продаж. Кроме того, они возможны в результате изменения внутренних настроек системы (изменения конфигурации прикладного решения «1С», смены релиза платформы «1С», включения ранее незадействованного функционала, ошибок администрирования и др.).
Обе ситуации – с избыточными вычислительными мощностями и с нехваткой мощностей – ведут к финансовым потерям, которые хотелось бы минимизировать. При внедрении «тяжелых» систем возникает вопрос и о цене управленческой ошибки. При закупке «железа» под ERP-систему придется потратить сразу много денег, и если вдруг внедрение не оправдает себя, то наименьшее, что потеряет ИТ-директор, – это свое рабочее место.
Задача определить и выделить необходимый объем серверных мощностей существенно проще в случае переноса ERP-системы в облако, поскольку модель IaaS позволяет гибко наращивать или уменьшать вычислительные мощности при необходимости. Таким образом, заказчик получает ощутимые экономические выгоды. Кроме того, в облаке возможно оперативное управление вычислительными мощностями, так как облако имеет определенные запасы прочности по всем элементам ИТ-инфраструктуры.
На Западе подобная практика давно в порядке вещей. Российский бизнес пока только опробует преимущества размещения ERP-систем в облаке. Хотя облачные технологии совсем не новые, в сфере ERP они применяются не так широко, как в других областях. Оптимальный вариант для бизнеса – переводить в облака такие ERP-системы, которые используются преимущественно для административных задач: HR-менеджмента, финансов, управления закупками.
Доверяй, но проверяй: методика тестирования
Обязательный этап перед запуском «тяжелой» системы в облаке – нагрузочное тестирование, позволяющее понять, какие запасы прочности по какому элементу инфраструктуры нужно иметь для стабильной работы и при каких условиях возникнет нехватка ресурсов. На базе полученных данных можно сформулировать требования к облаку для конкретной системы и изменять объемы задействованных вычислительных ресурсов по мере приближения критической ситуации.
Авторы статьи получили задачу проверить на практике, что ERP-система (в нашем случае это «1С:ERP 2.2») будет надежно работать в облаке в разных режимах. Для этого в облаке OnCloud.ru развернули систему «1С:ERP 2.2», для которой были выделены необходимые серверные мощности. Затем в течение четырех рабочих недель и одной праздничной проводилась серия натурных экспериментов, в ходе которых обеспечивалась многочасовая устойчивая работа большого количества соединений с базой «1С:ERP 2.2». В наших экспериментах их было свыше 15 тыс., что в сфере работы серверного кода «1С» и в области работы СУБД эквивалентно такому же количеству пользователей – более 15 тыс. в одной базе.
База для тестирования и средства автоматизации тестирования были подготовлены заранее.
Соединения моделировались с помощью фоновых заданий. Продолжительность каждого задания соответствовала общей длительности теста, т. е. нескольким часам. Такой подход к моделированию значительно дешевле традиционного, когда в качестве соединений запускаются клиентские приложения, пусть и под управлением не людей, а роботов.
Было важно, чтобы каждое соединение стартовало, работало эти несколько часов, за которые создало и провело заданные ему документы, и затем, не прерываясь, дождалось общей для всех соединений команды завершить работу. В ходе каждого большого эксперимента за 6,5–8 часов суммарный объем созданных и проведенных документов превышал 180 тыс. Это были документы, отражавшие движение по складам, взаиморасчеты с контрагентами, закупки, продажи, документы по сборке и переработке, грузовые таможенные декларации – всего более 20 разных типов документов, имеющих свои особенности.
Все получилось, разумеется, не сразу и не само собой. Мы увидели смещение акцентов с исполнительских задач на задачи управления: чтобы достичь и поддерживать результат, потребовалось непрерывно управлять производительностью и устойчивостью системы.
Нагрузка между разными элементами вычислительной инфраструктуры (процессорными мощностями серверов БД и серверов приложений, памятью, СХД) при общем росте интенсивности вычислительных процессов ERP-системы распределяется по-разному. Этими ресурсами, как и вычислительными процессами ERP-системы, необходимо управлять в динамике, если хотим добиться устойчивой и надежной работы ERP-системы и тем самым дополнительно снизить затраты на инфраструктуру. Такое резюме было получено по итогам тестирования: в самом начале работ это не было очевидно. Априори предполагалось, что мощность ЦОД должна рассчитываться один раз – перед его сборкой. Управление ресурсами обычно осуществлялось двумя путями: скачкообразным наращиванием мощностей при их длительной нехватке или автоматикой систем виртуализации без аудита со стороны людей. Это было стратегически верно до достижения нынешнего уровня сложности.
Главное – в деталях
В ходе тестирования ERP-система «1С:ERP 2.2» несколько раз входила в состояние, когда ожидалась нехватка ресурсов по процессору и по памяти или только по памяти. Оперативно подключая дополнительные мощности, мы «объезжали» опасную зону.
Проанализировав работу системы по факту повышения нагрузки, мы, в частности, установили причины роста загрузки процессора и нашли возможность нивелировать их влияние.
Если говорить более подробно о технических деталях при тестировании системы, то стоит отметить следующие моменты:
- удалось уменьшить количество конфликтов блокировок более чем в шесть раз, для этого потребовалось изменить настройки кода прикладного решения;
- результат теста показал всего 105 конфликтов блокировок на 15 010 соединений за восемь часов, тест можно считать успешным, основная задача тестирования достигнута.
Узкими местами при тестировании оказались большие очереди к системному диску и к диску с базой (диски C: и F: на сервере СУБД).
На самом деле это хороший показатель, который в совокупности с хорошей (45–55%) нагрузкой на процессор сервера СУБД говорит о том, что в системе нет серьезных бутылочных горлышек в тестируемых контурах (маленькие есть, но они не критичны для площадки в целом).
Что касается тестов на 10 и 15 тыс. пользователей, то можно отметить следующее.
- Тесты состоялись, удалось достичь нужного качества работы системы.
- По мере изменения входных параметров (структуры и состава документооборота, кастомизации прикладного решения и пр.) нужно прилагать усилия для достижения требуемого качества работы системы уже в новых условиях. Иными словами, работой системы в таких режимах надо управлять. Не годится подход «как завели, так и едет на автопилоте».
- Общая загрузка процессора. В установленном режиме это одна величина (в нашем случае для разных режимов от шести до 25 ядер на сервере приложений и 6–20 на сервере СУБД), но бывают режимы, требующие запаса прочности, и он должен быть не 30%, как считалось до сих пор, а 150% на сервере приложений и 100% на сервере СУБД.
- Объем занятой памяти. Вывод аналогичный.
- Диски. Мы увидели предел по увеличению количества работы, выполняемой в единицу времени, который связан с производительностью диска с базой. Оказалось, что для обеспечения качества работы более эффективно не производительность дисков увеличивать, а смотреть, какую лишнюю работу выполняет приложение и можно ли ее не делать.
Без запаса прочности далеко не уедешь
Все наблюдения в ходе тестирования и основные выводы позволяют прогнозировать снижение требований к объемам арендуемых облачных ресурсов до наступления новой ситуации, требующей их увеличения. Понимание этих нюансов дает заказчику дополнительные выгоды и благоприятно сказывается на стоимости аренды виртуальных вычислительных мощностей: меньше мощностей арендуем – меньше платим.
Условия нашей тестовой системы и системы заказчиков, конечно, во многом сходны, мы потратили время и силы на создание теста, имитирующего ERP-документооборот. И все же решения по системе заказчиков надо принимать с учетом особенностей ее работы в реальном времени.
По результатам тестирования отметим следующее. Оборудование «в спокойном режиме» не во всех системах должно использоваться на 100%. В больших системах нужен запас прочности, потому что кроме установленного режима бывают «турбулентности». Их источники нужно выявлять и побеждать, но система должна быть готова в них жить и работать, не падая, пока не будет устранена причина «турбулентности».
- Для систем на пять пользователей запас прочности не нужен.
- Для систем с сотней пользователей он может быть любым, а может и отсутствовать.
- Для систем с 600 пользователями без запаса прочности уже не обойтись, но управлять им необязательно – достаточно его наличия.
- Для систем на 1500 пользователей запас прочности должен быть 100%, и им надо управлять.
- Для систем в 15 тыс. пользователей запас прочности должен быть не менее 150%, и им надо управлять постоянно.
Использованное оборудование не соответствует параметрам установленного режима, а заведомо их превышает. Но это превышение использовалось, в частности, для «объезда трудного участка» и в дальнейшем могло быть уменьшено. В таких условиях разговоры из серии «нам нужно оборудование раз и навсегда» аналогичны разговорам «я поставлю руль прямо, и машина должна сама ехать». Результат отказа от управления будет схожим. Конечно, авария игрушечной машинки, запущенной ребенком в комнате, не страшна. Настоящий автомобиль очевидно требует грамотного управления: если на пути будут препятствия, нужно обеспечить себе пространство и время для маневра. Если столкновение неизбежно, лучше ехать на танке.
Гарантии счастливого союза с провайдером
Тем, кто решился разместить свою «тяжелую» систему в облаке, рекомендуем придерживаться таких же правил в общении с провайдером, как и в любых других случаях.
- Высокая производительность
Благодаря технологиям виртуализации провайдер может продавать одни и те же ресурсы одновременно нескольким компаниям. Это нормальная практика, так как одна компания, согласно статистике, не сможет израсходовать данный ресурс. Однако на пике потребностей все пользователи могут столкнуться со снижением производительности ресурсов сервиса. Поэтому в договоре важно прописать, что провайдер обязуется обеспечить производительность в любой момент времени. Нарушение этого требования равносильно непредоставлению услуги в полном объеме. Кроме того, должны быть предусмотрены серьезные штрафы за нарушение этого условия.
- Резервное копирование
Пропишите в договоре гарантии сохранности данных – обязательства провайдера выполнять резервное копирование ваших данных с определенной периодичностью и хранить их в отдельном месте. В случае сбоев и частичной потери информацию можно будет восстановить из резервной копии.
- Запрет доступа
Технологические решения обеспечивают доступ к данным только со стороны заказчика: приобретая инфраструктуру у облачных провайдеров, вы оплачиваете лишь пространство, софт и сервисы. Учетные записи и пароли генерируются системой: провайдеру они недоступны. Однако дополнительная осторожность не будет избыточной, запрет не санкционированного заказчиком доступа к данным стоит прописать отдельно.
- Круглосуточная поддержка
Техническая помощь провайдера необходима в режиме 24×7 вне зависимости от специфики вашего бизнеса. Даже если вы не работаете в выходные, у провайдера должен быть запас времени, чтобы восстановить упавшую систему к утру понедельника.
- SLA и финансовая ответственность
В соглашении об уровне сервиса (Service Level Agreement – SLA) должны быть детально изложены все параметры приобретаемых услуг и ответственность за их несоблюдение. Как правило, такой документ содержит гарантии доступности, отказоустойчивости, резервного копирования, постоянного обслуживания и запрет на не санкционированный заказчиком доступ. Параметры, указанные в SLA, должны быть измеримыми.
- Счет вместе с отчетом
Включите в договор с провайдером обязательное ежемесячное предоставление отчетности, по дням фиксирующей объем используемых ресурсов и качество услуг (соответствует SLA или нет). Начисления должны коррелироваться с реальным сервисом в течение месяца.
