Евгений Филиппов, Олег Коновалов. Как обеспечить «тяжелым» корпоративным системам парение в облаках. Опыт 1С:ERP 2.2

Среди ИТ-директоров распространено мнение, что ERP из облака покупают компании из сегмента SMB, а большим организациям необходимо выстраивать собственный комплекс с предварительным долгим, мучительным и непременно дорогим сайзингом. Наше тестирование 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 000, что в области работы серверного кода 1С и в области работы СУБД эквивалентно такому же количеству пользователей – свыше 15 000 в одной базе.

База для тестирования и средства автоматизации тестирования были подготовлены заранее.

Соединения моделировались с помощью фоновых заданий. Время жизни каждого из заданий соответствовало общей длительности теста, т.е. нескольким часам. Такой подход к моделированию значительно дешевле традиционного подхода, когда в качестве соединений запускаются клиентские приложения, пусть и под управлением не живых людей, а роботов.

Было очень важно, чтобы каждое соединение стартовало, проработало эти несколько часов, за которые создало и провело заданные ему документы, и затем, не отвалившись, дождалось общей для всех соединений команды завершить работу. В ходе каждого большого эксперимента за 6,5-8 часов суммарный объем созданных и проведенных документов превышал 180 000. Это были документы, отражающие движение по складам, взаиморасчеты с контрагентами, закупки, продажи, документы по сборке и переработке, грузовые таможенные декларации – всего более 20 разных типов документов, каждый со своими особенностями.

Все получилось, разумеется, не сразу и не само собой. Мы увидели смещение акцентов с исполнительских задач на задачи управления: чтобы достичь и поддерживать результат, потребовалось непрерывно управлять производительностью и устойчивостью системы.

Распределение нагрузки между разными элементами вычислительной инфраструктуры (процессорными мощностями серверов БД и серверов приложений, памятью, СХД) при общем росте интенсивности вычислительных процессов ERP-системы происходит по-разному. Этими ресурсами, а также самими вычислительными процессами ERP-системы необходимо управлять в динамике, если мы хотим добиться устойчивой и надежной работы ERP-системы и таким образом дополнительно снизить затраты на инфраструктуру. Такое резюме мы получили по итогам тестирования: в самом начале работ это не было очевидно. Априори предполагалось, что мощность ЦОДа должна рассчитываться один раз – перед его сборкой. Управление ресурсами обычно велось двумя путями: скачкообразным наращиванием мощностей при их длительной нехватке или автоматикой систем виртуализации без серьезного аудита со стороны людей. Это было стратегически верно до достижения нынешнего уровня сложности.

Главное – в деталях

В ходе тестирования ERP-система 1С:ERP 2.2 несколько раз входила в состояние, когда мы ожидали нехватки ресурсов по процессору и по памяти или только по памяти. Оперативно подключая дополнительные мощности, мы «объезжали» опасную зону.

Проанализировав работу системы по факту повышения нагрузки, мы смогли, в частности, установить причины роста загрузки процессора и нашли возможность нивелировать влияние этих причин.

Если говорить более подробно о технических деталях при тестировании системы, то надо отметить следующие моменты:

Основными узкими местами при тестировании оказались большие очереди к системному диску и к диску с базой (диски C: и F: на сервере СУБД).

На самом деле это хороший показатель, он в совокупности с хорошей (45-55%) нагрузкой на процессор сервера СУБД говорит о том, что в системе нет серьезных бутылочных горлышек в тестируемых контурах (маленькие есть, но они не критичны для площадки в целом).

По тестам на 10 и 15 тысяч пользователей можно сказать следующее.

Тесты состоялись, на них удалось достичь нужного качества работы системы.

1. Если происходит изменение входных параметров (структуры и состава документооборота, кастомизация прикладного решения и пр.), то требуются усилия, чтобы достичь нужного качества работы системы уже в новых условиях, т.е. работой системы в таких режимах надо управлять. Здесь совершенно не годится подход «как завели, так и едет на автопилоте».
2. Общая загрузка процессора. В установившемся режиме это одна величина (в нашем случае для разных режимов это от 6 до 25 ядер на сервере приложений и 6-20 на сервере СУБД), но бывают режимы, когда нужен запас прочности, и он должен быть не 30%, как считалось до сих пор, а 150% на сервере приложений и 100% на сервере СУБД.
3. Объем занятой памяти. Вывод аналогичный.
4. Диски. Мы увидели предел по увеличению количества работы, выполняемой в единицу времени, который связан с производительностью диска с базой. Оказалось, что для обеспечения качества работы более эффективно не производительность дисков увеличивать, а смотреть, какую лишнюю работу выполняет приложение и можно ли ее не делать.

Без запаса прочности далеко не уедешь

Все наблюдения в ходе тестирования и основные выводы позволяют нам прогнозировать снижение требований к объемам арендуемых облачных ресурсов до наступления новой ситуации, требующей их увеличения. Понимание этих нюансов даёт заказчику дополнительные выгоды и благоприятно сказывается на стоимости аренды виртуальных вычислительных мощностей: меньше мощностей арендуем – меньше платим.

Условия нашей тестовой системы и системы заказчиков, конечно, во многом сходны, мы потратили время и силы на создание теста, имитирующего ERP - документооборот. И всё же решения по системе заказчиков надо принимать, учитывая особенности ее работы в реальном времени.

По результатам тестирования отметим следующее.

Оборудование «в спокойном режиме» не во всех системах должно использоваться на 100%. В больших системах нужен запас прочности, потому что кроме установившегося режима еще бывают «турбулентности». Их источники нужно выявлять и побеждать, но система должна быть готова в них жить и работать, не падая, пока не будет устранена причина «турбулентностей».

Использованное оборудование не отвечает параметрам установившегося режима, оно заведомо их превышает. Но это превышение использовалось в том числе для «объезда трудного участка», и в дальнейшем могло быть уменьшено. В таких условиях разговоры из серии «нам нужно оборудование раз и навсегда» аналогичны разговорам «я поставлю руль прямо, и машина должна сама ехать». Результат отказа от управления будет схожим. Конечно, авария игрушечной машинки, запущенной ребенком через комнату, не страшна. Настоящий автомобиль, очевидно, требует грамотного управления: если в пути будут препятствия, нужно обеспечить себе пространство и время для маневра. Если столкновение неизбежно, лучше ехать на танке.

Гарантии счастливого союза с провайдером 

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

1. Высокая производительность

Благодаря технологиям виртуализации провайдер может продавать одни и те же ресурсы одновременно нескольким компаниям. Это нормальная практика, так как одна компания, согласно статистике, не сможет израсходовать данный ресурс. Однако на пике потребностей все пользователи могут столкнуться со снижением производительности ресурсов сервиса. Поэтому в договоре важно прописать, что провайдер обязуется обеспечить производительность в любой момент времени. Нарушение этого требования равносильно непредоставлению услуги в полном объеме. Кроме того, должны быть предусмотрены серьезные штрафы за нарушение этого пункта.

2. Резервное копирование

Пропишите в договоре гарантии сохранности данных – обязательства провайдера выполнять резервное копирование ваших данных с определенной периодичностью и хранить их в отдельном месте, чтобы в случае сбоев и частичной потери информации восстановить ее из резервной копии.

3. Запрет доступа

Технологические решения обеспечивают доступ к данным только со стороны заказчика: приобретая инфраструктуру у облачных провайдеров, вы оплачиваете только пространство, софт и сервисы. Учетные записи и пароли генерируются системой: провайдеру они недоступны. Однако излишняя осторожность не будет лишней, запрет не санкционированного заказчиком доступа к данным стоит прописать отдельно.

4. Круглосуточная поддержка

Техническая помощь провайдера необходима в режиме 24/7 вне зависимости от специфики вашего бизнеса. Даже если вы не работаете в выходные, у провайдера должен быть запас времени, чтобы восстановить упавшую систему к утру понедельника.

5. SLA и финансовая ответственность

В соглашение об уровне сервиса (Service Level Agreement, SLA) должны быть детально изложены все параметры услуг, которые вы покупаете, и ответственность за их несоблюдение. Как правило, такой документ содержит гарантии доступности, отказоустойчивости, резервного копирования, постоянного обслуживания и запрет не санкционированного заказчиком доступа. Параметры, указанные в SLA, должны быть измеримыми.

6. Счет вместе с отчетом

Включите в договор с провайдером обязательное ежемесячное предоставление отчетности, по дням фиксирующей объем используемых ресурсов и качество услуг (соответствует ли SLA или нет). Начисления должны коррелироваться с реальным сервисом в течение месяца.

Источник: Сonnect, №1-2, 2017

Ссылка на источник: http://www.connect-wit.ru/18332.html