Подбор оборудования для информационных систем на платформе 1С

Я – Филиппов Евгений, в настоящее время работаю в компании IBS начальником отдела разработки. В мире 1С меня знают, как автора книги «Настольная книга 1С:Эксперта по технологическим вопросам». Сегодня поговорим о такой скучной и занудной вещи, как подбор оборудования для информационных систем на платформе 1С:Предприятие. 

Кто-нибудь знаком с теорией мотивации Герцберга? Согласно этой теории существует два вида факторов, которые влияют на мотивацию и удовлетворенность от работы для человека. 

• Часть из них называются гигиеническими факторами – если их не хватает, человек работает хуже. 

• Другие факторы называются мотивирующими – это, например, признание. Чем их больше, чем человек работает лучше.

Это работает не для всех и не всегда. Допустим, если человек – художник (живет по собственным правилам) или космонавт (живет в уникальных условиях) – для них теория Герцберга не актуальна, у них собственная система факторов. Но для большинства людей, живущих в Европе по европейским правилам, она применима.

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

Если провести аналогию между требованиями к оборудованию у разных организаций и уровнем зарплаты разных людей, которые когда-то учились в одной школе – рассчитывали ли вы, например, что раз вы когда-то учились с вашими одноклассниками в одной школе, у вас будет одинаковая зарплата? Нет, конечно. Однако почему-то применительно к 1С все стараются считать, что, раз мы работаем на 1С, нам всем нужно одно и то же оборудование. Согласитесь, это может быть совсем не так.

История вопроса. 2009 год

Сначала расскажу про историю вопроса. 

В 2009 году мы провели первое успешное нагрузочное тестирование УПП на 1000 пользователей. В то время мы ничего не знали о том, какое оборудование нужно, и планировали, что на терминальном сервере нам понадобится примерно 0.8 ядра на 100 пользователей, а на сервере 1С и на сервере СУБД нам нужно будет почти 2 ядра. И по памяти планировали примерно такой же расход – мы думали, что для клиентского доступа к терминальному серверу требуется совсем немного памяти, для сервера 1С побольше, а для сервера СУБД еще больше. 

Но когда мы начали поднимать конкретный тестовый стенд, то увидели, что наши знания о реальной жизни не сработали. На терминальном сервере нам потребовалось в 10 раз больше памяти, чем мы рассчитывали. А требования к серверу 1С, наоборот, оказались настолько незначительными, что мы организовали его «на сдачу», по остаточному принципу.

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

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

История вопроса. 2012 год

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

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

История вопроса. 2015 год

А в 2015 году все поменялось. К этому времени уже массово распространилась УТ11 – конфигурация на управляемых формах. 

Мы опять провели нагрузочный тест и увидели, что ситуация изменилась. Требования к терминальному серверу снизились, а требования к серверу 1С возросли. Это логично, потому что у управляемых форм повысилось качество кода, появился тонкий клиент, и часть нагрузки легла на сервер. Все объяснимо. 

Но наши предыдущие таблицы перестали работать, и нам пришлось давать людям уже две таблицы. Одну – для обычных форм, другую для управляемых. И обе эти рекомендации давались по данным нагрузочных тестов, которые мы сами проводили. А в те нагрузочные тесты, которые мы сами проводили, мы верим, как в святыню – это данные, которые мы сами получили. 

Кстати, в этой презентации мною и моими коллегами сделана попытка свести все цифры во всех таблицах к единому знаменателю. Мы здесь во всех таблицах привели относительную ресурсоемкость оборудования с помощью двух показателей (в пересчете на сотню пользователей информационной системы) – количество ядер и количество памяти. Поскольку системы все разные (от двух до 4000 пользователей), применение таких единых показателей позволяет сравнивать эти системы между собой.

Современная теория. Противоречие – проводить нагрузочные тесты или просто считать по таблице?

В 2015 году, когда было написано второе издание моей книги, на ИТС выложили много материалов по технологическим вопросам. Раньше все эти материалы находились на https://kb.1c.ru, а потом некоторые из них переехали на ИТС, где находится вся наша текущая проблематика. И тут обнаружилось интересное – одна и та же статья «Расчет параметров серверного оборудования», которую написал Константин Рупасов, после появления на ИТС пополнилась в самом конце маленьким параграфом «Выбор оборудования» примерно на полстраницы.

Причем, первая часть этой статьи очень подробно рассказывает, как рассчитывать потребность в оборудовании по данным нагрузочного теста или по данным эксплуатации существующей тестовой системы. А в самом конце в разделе «Выбор оборудования» приведены таблицы с рекомендуемыми значениями параметров оборудования – т.е., забудьте теперь все, что только что прочитали, и считайте по таблицам (эти таблицы здесь в презентации тоже будут в пересчете на 100 пользователей). 

Почему так произошло? На мой взгляд, потому, что к этому моменту была накоплена адекватная статистика. Она уже стала настолько адекватной, что ее можно было опубликовать со словами, что для большинства баз «1С:Бухгалтерия предприятия» нужно вот такое оборудование.

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

Когда мы встали перед дилеммой – проводить нагрузочные тесты или считать по таблицам, мы задумались о том, что же такое нагрузочный тест. Как я уже сказал, нагрузочный тест это упрощенная картина  – это то же самое, что ваши примерные расходы в месяц с учетом того, что вы просто каждый день ходите на работу и возвращаетесь с работы. Это установившийся, удобный для вас режим – вы где-то едете на электричке, где-то научились экономить деньги, чтобы меньше их тратить. Но если у вас рождается ребенок или вы просто решили сходить к стоматологу – вся ваша картина рушится. 

То, что вы увидели на нагрузочном тесте, вам вообще ничего не скажет о том, что может произойти в вашей жизни. Поэтому реальная статистика внедрений отличается от того, что показывает нагрузочный тест. Реальная статистика на ИТС отличается от той, которую мы получили с помощью нагрузочных тестов. Она совсем другая. Люди закладывают резерв на то, что у них в жизни что-то произойдет, точно так же, как мы откладываем деньги на предстоящие большие расходы.

Кроме того, нагрузочные тесты стали дороги, люди не хотят платить деньги за их проведение, чтобы узнать, как работает Бухгалтерия или УПП, или даже ERP. Им неинтересно выкладывать несколько миллионов за то, чтобы узнать, что «все примерно будет хорошо», потому что эти деньги можно просто вложить в оборудование, чтобы перестраховаться, например. Не всегда, но иногда срабатывает. 

Почему практика иногда соответствует теории

Причем, практика, как ни странно, иногда совпадает с теорией. Она совпадает, когда мы сравниваем то, что можно сравнивать. Например, если у нас проводится нагрузочный тест, и мы сравниваем его с результатами предыдущего нагрузочного теста, то у нас, в принципе, все должно совпасть. Или, мы работаем в базе «1С:Бухгалтерия», не касаясь закрытия месяца (пользователь зашел, что-то сделал, вышел), сравниваем существующую нагрузку с планируемой – все ровненько, все совпадает.

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

На нагрузочном тесте мы ничего подобного не моделировали, более того, мы в тех условиях не могли это правильно смоделировать, потому что мы вообще не знали, что будет происходить. Соответственно, когда мы сравниваем то, что нельзя сравнивать, теория с практикой не совпадает. 

Нагрузочный тест очень некорректно сравнивать с реальной жизнью. Нагрузочный тест – это тонкий инструмент, который показывает нагрузку, если работа ведется так, как заложено в модели, то есть если модель правильно отражает реальную работу. Но если работа ведется по-другому, значит, теория с практикой у вас не совпадёт никогда.

Компромисс между рекомендациями и расчетами

И вот – в один момент мы столкнулись с заказчиком напрямую, и он спросил: «Сколько мне нужно оборудования, чтобы ERP у меня работала нормально?» 

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

• И в это время наш руководитель проекта прочитал рекомендации с ИТС (на слайде это – вторая строчка снизу) и поразился, насколько радикально эти рекомендации отличались от того, что даем мы.

После этого мы в течение трех месяцев обсуждали, кто прав, кто не прав, кто должен поступиться принципами, а кто не должен – и в результате заказчик выбрал свой собственный вариант (пятый), который показан в этой таблице в самой нижней строке. Эти результаты более-менее коррелируют с тем, что мы посчитали на нагрузочном тесте, но видно, что он попытался серьезно перестраховаться. Где имел возможность – там заложил больше. Почему? Потому что ему нужно жить не в условиях нагрузочного теста, а в условиях реальной жизни, которую нагрузочный тест не показывает.

Случаи, которые теория не описывает

Тем более, что есть ситуации, которые теория вообще не описывает, даже если мы будем закладывать резервы на что-то еще. 

Например, у нас вышел нестабильный релиз, или мы неправильно настроили кластер, или какими-то экспериментальными настройками вывели систему в экстремальный режим, или, в конце концов, программист ошибся, выбрал неверный алгоритм программирования. Или заказчик поставил формироваться какой-то отчет, который делает выборку из всех таблиц, или кто-то использует механизмы не по назначению, и в определенных условиях эти механизмы начинают сильно грузить оборудование – все эти случаи нам теория вообще никак не опишет. И заложить резервы мы на них не можем. Нам просто никто не даст обоснования на эти случаи. Это просто ситуация, когда все было хорошо, и вдруг все поломалось. 

Это хорошо, если у вас действительно настроен мониторинг, и вы отследили эту ситуацию и вовремя отыграли назад. А может быть и не так. Никакая теория вам не предскажет, что вследствие какого-то изменения, без изменения количества пользователей, оборудования на сервере разработки должно быть в 10 раз больше, чем сейчас. Но и того, что через 3 месяца оно в таком количестве вам может уже не понадобится, потому что ситуация стабилизируется и платформа начнет работать нормально с тем механизмом, который вы сами использовали не по назначению (в итоге платформа не виновата) - никакая теория вам тоже не скажет. 

Но оборудование, тем не менее, выбирать нужно.

Рекомендации с ИТС, пересчитанные на единый показатель

На чем обычно основывается выбор оборудования? Смотрят, какое чаще всего используется у людей. Если хотите работать бухгалтером, хотите знать, сколько им сейчас платят – идите на HeadHunter, смотрите, какая у бухгалтеров зарплата. 

Вот рекомендации с ИТС, пересчитанные на наш единый показатель по данной презентации (относительное количество ядер и памяти на сотню пользователей). 

Мы видим, что характеристики оборудования в этой таблице получились относительно неровные для разного количества пользователей. Почему так? Не знаю. Видимо, так собиралась статистика.

Например, почему-то расход памяти на 100 пользователей для среднего количества пользователей нужно меньше, чем для малого и для большого.

И для сервера СУБД (крайняя правая колонка), там вообще для крупного внедрения серьезный резерв – 64 гигабайта на каждую сотню пользователей, т.е. на 1000 пользователей нужно уже 640 гигабайт. 

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

Статистика по выбору оборудования по данным проектов ЦКТП

Далее мы попробовали выяснить, какое нужно оборудование для разных типовых решений.

Если проводить аналогию с зарплатой, то, опять-таки, у людей, которые учились в одной и той же школе, зарплаты по окончании вуза могут быть разными, но если они заканчивали один и тот же вуз, то эти зарплатные ожидания на начальном этапе могут более-менее как-то совпадать.

То есть, если это «1С:Бухгалтерия предприятия» – это одни требования, если это ЗУП – другие требования. 

Статистику мы собирали по сайту v8.1c.ru – в разделе, где опубликованы проекты ЦКТП, также публикуется аппаратное обеспечение, используемое на проекте. Посчитали все варианты по приведенным конфигурациям, плюс добавили сюда свой опыт нагрузочных тестов и свой опыт с реальных внедрений, который у нас был (это – статистика по тому оборудованию, которое люди реально использовали, в том числе и наши клиенты).

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

Здесь есть незаполненные ячейки – объясню, о чем речь. 

• Иногда в характеристиках проекта на сайте не указано, что есть сервер терминалов. Поэтому мы эту строчку считали отдельно. 

• Или иногда на сайте вообще нет информации про отдельный сервер 1С и про сервер СУБД, поэтому мы не знали, как один отделить от другого, и вывели эти показатели в отдельной колонке (два крайних правых столбца).

Аналогичным образом, как в «1С:Бухгалтерии предприятия», так и с «1С:Зарплатой и управлением персоналом» – при переходе с 2.5 на 3.0 требования к серверу приложений подросли, а требования к терминальному серверу уменьшились. Опять же, по статистике.

Возможно, у каждого из вас есть такая своя статистика, и вы можете сказать относительно того, что здесь написано, что у вас не так. Но это – статистика, она – такая.

И еще по нескольким наиболее популярным конфигурациям. 

При переходе с УПП на ERP – предсказуемо уменьшились требования к терминальному серверу, но подросли требования к серверу приложений и серверу СУБД.

При переходе с УТ 10 на УТ 11 здесь как раз статистика дала сбой – у нас уменьшились требования к серверу приложений. Видимо, речь идет о влиянии каких-то факторов, которые мы при подсчете не учли.

Также видно, что, допустим, конфигурация Документооборот значительно менее прожорлива, чем все остальное.

Как менялись требования к оборудованию по годам?

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

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

Статистика по платформам показывает тот же самый тренд, тот же самый баланс между сервером терминалов и сервером приложений. И растет требование к памяти на сервере СУБД.

Мы входим в область больших проектов, где делаются избыточные резервы оборудования, в том числе, благодаря рекомендации с ИТС. А может быть, эта рекомендация с ИТС произошла благодаря реальным внедрениям? Что причина, что следствие – можно поспорить.

На слайде статистики по типам приложений видно, что у обычного приложения требования к оборудованию на терминальный сервер больше, а на сервер 1С – меньше.

Как рассчитывать требования к сети и дисковой подсистеме?

До сих пор я говорил о ядрах и о памяти. Теперь коротко – о сети и дисках. 

Про сеть ничего толком сказать нельзя, потому что этот фактор «еще более гигиенический», чем количество ядер и памяти. Если сетки не хватает, у вас все «падает», если сетки хватает – все прекрасно. Количество вариаций гораздо меньше, поэтому тут интересной статистики не получится. 

А что касается требований к дисковой подсистеме, то у меня есть специальный слайд про взаимосвязь показателей MBs/sec и IOPS, поскольку заказчики часто требуют от нас производительность в IOPS, а на сайте 1С производительность обычно замерена в MBs/sec. 

Чтобы от IOPS перейти к MBs/sec, нужно разделить IOPS на размер блока. Если мы говорим о внедрениях, которые сделаны по методике ЦКТП, то там используется утилита SQLIO, для которой стандартный размер блока 64 Кб, если его руками не меняли (а скорее всего, его не меняли). Если вдруг это старая система, там коэффициент может быть 32 Кб, но это уже архаичные системы. Если кто-то поставил другой коэффициент пересчета и нигде это не указал, то нужно надеяться, что такого не произошло.

Тактика управления

Что со всем этим делать? 

• Есть люди, которые ходят по земле и работают в ненагруженной базе (самая нижняя строчка) – от одного до 5 пользователей в базе «1С:Бухгалтерия». Они там и со своим ноутбуком прекрасно справляются.

• Но если вы – художник, у вас специализированная или высоконагруженная база (вторая снизу строчка), то вам общепринятые требования вообще не подходят, вам нужно проводить нагрузочный тест, рассчитывать свою жизнь именно так, как вы живете. Когда мало пользователей, но большая нагрузка – усредненные требования вообще не подходят, нужно считать свои. И оборудование нужно считать свое.

• Если у вас 10-50 пользователей, и вы работаете в базе «1С:Бухгалтерия», у вас стандартная схема движения документов – тогда да, можете посмотреть по таблицам, посмотреть, как у соседа, сэкономить деньги на сайзинге. Точно так же, как мы смотрим зарплату по HeadHunter. 

• Но чем мы больше, тем нам больше нужен запас. Чем у меня семья больше, тем мне больше нужно денег иметь в запасе на то, что детей придется учить, женить, выдавать замуж и т.д.

• И если у вас более 1000 пользователей, вы – космонавты, вам про вашу жизнь вообще никто ничего не может рассказать, вам нужно самим разбираться, что за оборудование вам нужно. Вам нужно знать досконально каждую железяку, каждый вид организации RAID-массива и все-все-все про вашу работу. И решения всегда нужно принимать самому. Когда советская космическая промышленность готовила запуск лунохода, его долго не могли сделать, потому что не знали, какая луна – твердая, жидкая, газообразная? Пришел Королев, сказал: «Луна твердая». И луноход улетел, все счастливы. Делайте свой луноход.

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2018 EDUCATION.