Как подобрать сервер для 1С:ERP и на какие показатели ориентироваться, чтобы оборудование для высоконагруженной системы оправдало вложения? Расскажем!

Допущение про отказоустойчивость

Прежде всего, нужно сказать пару слов об отказоустойчивости.

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

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

Самый простой пример – вы можете:

• выписать список всех возможных рисков;

• оценить вероятность риска;

• оценить, каким будет простой в часах в случае возникновения этого риска;

• понять, сколько стоит час простоя вашей системы.

И дальше понять, какие из возможных ситуаций вам нужно обрабатывать, а какие маловероятны и на них не стоит тратить деньги – что для вас выгодней: простой системы или второй сервер в запасе?

В любом случае, не забываем и про резервные копии.

Мы на всех проектах настраиваем некоторый минимально допустимый уровень резервного копирования.

• Для баз данных это, конечно же, полные и разностные резервные копии – как правило, мы их делаем раз в сутки. Копии журналов транзакций – раз в час или чаще.

• Обязательно делаем бэкап каталога кластера 1С, той самой папки – 1cv8\srvinfo. Достаточно ее копировать раз в сутки.

• И слепок виртуальной машины – если используется виртуализация – или резервная копия операционной системы. Сама же операционная система Windows Server прекрасно умеет делать резервные копии самой себя, и это точно нормально работает.

Далее расскажем о том, какие сервера хорошо бы подбирать под 1С:ERP. При этом:

• Вопросов отказоустойчивости более касаться не будем. Накладывать на это необходимый вам уровень отказоустойчивости вы сможете самостоятельно.

• Все оговоренное относится не только к 1C:ERP, но и к другим решениям фирмы «1С» – подход здесь универсальный.

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

• Дадим общие рекомендации по конфигурации серверов и приведем конкретные реальные примеры подборов оборудования.

Что говорит про подбор оборудования фирма «1С»

Два года назад на партнерском форуме была создана эта тема (с описанием проблемы).

Много было ответов, но все не по делу.

Самые адекватные ответы отсылали к статье «Расчет параметров серверного оборудования» на сайте 1С:ИТС.

Вроде кажется: вот, то, что надо. Но немного смущает дата – статья от 2015 года. К тому же, если мы начинаем читать статью, то видим, что 1С предлагает нам использовать два вида систем: целевую систему и эталонную систему. И дальше оперирует этими двумя понятиями.

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

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

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

То есть я беру 1С:ERP, ставлю на свой ноут, делаю замеры, и мне говорят – сколько надо.

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

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

Это довольно очевидный способ – давайте поработаем на новом оборудовании и посмотрим, что будет.

Следующий способ – найти какую-то аналогичную целевую рабочую систему. Даже приведем цитату с ИТС: «Если ваша информационная система еще не внедрена, но у вас есть доступ к данным аналогичной системы – вы можете использовать ее в качестве эталонной».

Получается, что если вы собираетесь внедрять 1С:ERP – вы идете и ищете кого-нибудь, у кого система 1С:ERP работает примерно с таким же количеством пользователей, документооборотом, такими же ключевыми операциями, способами ввода документов и так далее.

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

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

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

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

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

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

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

1C:ERP и Тест-центр

Поговорим о Тест-центре.

• Для 1C:ERP есть готовый релиз с уже встроенным Тест-центром. У него очень длинное название – оно написано на слайде. Это – некоторая конфигурация, где просто сравнением и объединением в 1C:ERP добавлен Тест-центр, прямо в саму конфигурацию.

• В этом Тест-центре уже реализовано много различных сценариев тестирования именно для 1C:ERP.

• Можно взять готовые сценарии и прямо на них протестировать 1C:ERP, как, например, тестируется демка. Либо адаптировать скрипты под свои процессы, а еще никто не мешает разрабатывать их самим. Все скрипты написаны на встроенном языке 1С:Предприятия. Каждый скрипт – отдельная обработка в дереве конфигурации.

У 1С есть очень хороший вебинар о нагрузочном тестировании 1C:ERP. Он длинный, трехчасовой (мы, если честно, смотрели его в три захода).

Но в нем последовательно рассказывается:

• как установить Тест-центр, как его настроить и запустить;

• как правильно писать скрипты;

• почему то-то или то-то сделано в Тест-центре именно так,

• как не наступать на те грабли, которые прошли 1С.

Кто хочет погрузиться в тему нагрузочного тестирования – предлагаем с этого вебинара и начать.

В этой демо-базе 1С:ERP с Тест-центром уже реализованы типовые сценарии тестирования. Например, для закупок есть:

• разные варианты обеспечения,

• закупка по импорту,

• прием на комиссию,

• ордерная схема,

• возвратная тара,

• подотчетники.

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

• открытие форм,

• заполнение элементов формы,

• проведение и запись документов,

• печатные формы.

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

Вот часть схемы для блока продаж.

Кроме этого, есть:

• блок производства;

• взаиморасчеты;

• складские операции;

• регламентные операции;

• закрытие месяца.

Все это работает сразу из коробки вместе с Тест-центром. Если у вас нет ресурсов на разработку своих скриптов, вы можете на своем новом сервере поставить 1C:ERP с Тест-центром и прогнать все эти типовые скрипты, чтобы понять, какие результаты у вас будут.

Плюсы и минусы нагрузочного тестирования

Какие минусы я вижу в нагрузочном тестировании?

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

Но, плюсов больше:

• Как уже было сказано: есть много готовых сценариев из коробки.

• Оборудование можно арендовать: обратиться в дата-центр и взять оборудование, чтобы погонять 1С. Были примеры, когда некоторые дата-центры бесплатно выделяли оборудование с целью получить постоянного клиента.

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

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

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

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

С чего начать?

Если вы решили провести нагрузочное тестирование вашей системы, то какой должна быть начальная конфигурация? И что делать, когда на нагрузочный тест нет денег? У нас есть клиенты, которые говорят: «На нагрузочный тест бюджета нет, но нам сервер-то нужен, мы внедряем 1C:ERP, посоветуйте нам что-нибудь».

• Тут мы вспоминаем про способ, описанный на ИТС – рабочая система, аналогичная целевой. Мы ведем некоторую статистику наших клиентов: кто в какой конфигурации работает, на каком оборудовании, сколько пользователей и какой документооборот, как происходит ввод первички и так далее. Опираясь на эти данные, как на параметры аналогичной рабочей системы, мы можем подобрать клиенту оборудование. Например, клиент говорит: «У меня в 1C:ERP будет работать столько-то пользователей, ожидается столько-то документов». Исходя из нашей статистики мы можем примерно подобрать подходящий кейс с такими же параметрами и, не разглашая ничьих конфиденциальных данных, подобрать клиенту оборудование.

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

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

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

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

Один подбор стоит 500 рублей, наверное, за такую цену это и неплохо.

Рекомендации по архитектуре

Перейдем к некоторым рекомендациям по архитектуре.

Первый вопрос – объединять роли сервера приложений и сервера баз данных или не объединять?

• У нас никогда не бывает так, что приходит клиент и говорит: «Подберите нам любые сервера». Всегда есть бюджет. При фиксированном бюджете всегда выгоднее приобрести один производительный сервер, чем два отдельных сервера. Тем более, если это не арендованное, а физическое оборудование, ведь серверу нужны материнская плата, блок питания, система охлаждения, корпус, операционная система, которая тоже очень дорого стоит. Всегда один производительный сервер будет обходиться дешевле, чем два. Но понятно, что, начиная с какого-то момента, одного сервера будет недостаточно. Если у вас совсем-совсем высоконагруженная система, в какой-то момент все же придется разделить.

• Кроме того, работает Shared memory. Как пишет сама 1С, Shared memory дает прирост производительности до 10%.

• Некоторых пугает: как же так, SQL всю память сожрет. Не совсем так, ресурсы между кластером серверов и сервером СУБД можно распределить. И память, и диски, и процессоры – все это разделяется.

• Для очень высокопроизводительных систем роли придется разделить.

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

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

Никаких посторонних служб быть не должно, а особенно – сервера терминалов. Часто, приходя к клиенту, мы видим сервер СУБД и на нем – сервер терминалов. Спрашиваем: «Зачем вам сервер терминалов?» – «Чтобы администрировать было удобно, чтобы больше двух пользователей могли заходить». На самом деле, на сервер баз данных вообще заходить не надо. Management Studio и консоль кластера можно на терминальном сервере поставить.

• Во-первых, пользователи терминала создают неконтролируемую нагрузку. Кто-то может запустить какую-то адскую Excel-ку или скопировать на рабочий стол какой-нибудь 4-гиговый файл.

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

Роли сервера терминалов точно не должно быть на сервере баз данных.

Давайте добавим в нашу схему терминальные серверы, с них тоже клиенты могут работать – это было актуально во времена толстых клиентов,

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

Веб-сервер. Можно ли размещать веб-сервер на одной физической машине рядом с кластером серверов 1С?

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

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

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

Очень желательно разделять рабочую среду от тестовой. Желательно на физическом уровне.

Если нет денег разнести их физически – разнесите как минимум по разным службам. Поднять параллельную службу сервера 1С на параллельных портах, установить еще один инстанс SQL и хотя бы логически их отделить.

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

И разработчики могут разрабатывать либо со своих машин, либо с серверов терминалов.

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

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

• в случае с ключами защиты мы использовали nethasp-службу;

• в случае с программными лицензиями используем сервер лицензирования.

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

Сервер лицензирования частично этот вопрос решает. Это некоторая отдельная машина, виртуальная или физическая, на каком-нибудь бесплатном Linux, которая занимается только тем, что раздает лицензии.

И последний – самый склочный вопрос: использовать ли виртуализацию сервера баз данных и сервера приложений?

Очевидные плюсы виртуализации:

• легкость миграции серверов;

• удобство администрирования;

• есть очень удобные средства резервного копирования.

Некоторые минусы виртуализации.

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

  • Бывают проекты оптимизации, когда нам говорят, что сервер тормозит. Мы идем разбираться и либо не видим на самом сервере проблем, либо видим не те проблемы, на которые в первую очередь жалуется клиент. А проблемы лежат вне области нашего воздействия. Никто не пускает нас к физической машине, если это гипервизор. Всегда есть какой-то специалист, который все это настраивал, который держит оборону и никого не пускает. Говорит: это ваша 1С, вы и разбирайтесь, почему она тормозит.

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

  • Были примеры, когда клиент купил СХД за пару миллионов рублей, и был убежден, что теперь все должно летать. А мы запускали тесты, которые показывали очень плохие результаты на СУБД, и говорили, что проблема с дисками. Нам не верили: «Мы пару миллионов на диски потратили, а вы нам снова про них говорите». А проблема была именно в настройках гипервизора.

• Затрудняется сбор показателей работы оборудования. Счетчики в Windows мы можем настроить, но мы не видим загрузку реального оборудования. Там уже нужны компетенции по настройке Zabbix – не все администраторы у клиентов могут это правильно сами настроить и предоставить доступ к отчетности.

• Ну и меньше гибкости в настройке оборудования – позже расскажем подробнее.

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

Но мы в своей практике, к сожалению, сталкиваемся с обратным – с низкой компетенцией специалистов по виртуализации.

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

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

Советы по оборудованию для сервера приложений и баз данных

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

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

• Под операционную систему – рекомендуем взять два SSD-диска, объединить их в RAID.

• Под накопители для СУБД взять:

  • Какие-нибудь промышленные SSD с интерфейсом PCIe, форм-фактор U2, например. Это Intel Optane, у Samsung есть соответствующая серия. Это довольно дорогие диски, но очень эффективные для сервера баз данных – по нашему мнению, это единственно возможные диски, которые покажут хорошую производительность.

  • Объединять ли их в RAID? Не стоит. Лучше – разнести по назначению. Например, на один диск положить данные базы данных, на другой – журнал транзакций базы данных. В этом месте у некоторых админов начинает дергаться глаз. Как так, а вдруг он выйдет из строя? Во-первых, промышленные SSD сейчас по надежности уже переплюнули физические диски. А во-вторых – бэкапы. Если вам мало делать бэкапы раз в час – делайте их хоть каждые 10 минут. Это не влияет существенно на производительность системы.

• Под резервные копии места часто не хватает, поэтому для этих нужно отдельно подключить к серверу два любых диска – пусть у вас будет много места для резервных копий. Например, журналы транзакций после какого-нибудь закрытия месяца могут много весить, и их некуда складывать. Диски в этом случае – относительно копеечная затрата. Не обязательно уровня Enterprise, можно и обычные диски SAS или даже SATA – лишь бы они были.

• Под временные файлы обязательно предусмотрите отдельный накопитель. Это файлы подкачки, папка TEMP, файл TempDB. Можно даже TempDB вынести на RAM-диск, у нас есть такой опыт, и он давал существенные результаты.

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

Все чаще мы сталкиваемся с тем, что у наших клиентов сервера не свои, а арендованные в дата-центре.

Если наши клиенты арендуют сервера, при заказе в дата-центре спрашивают: а вам диски на сколько IOPS надо? Мы не очень любим этот параметр, но приходится иметь дело с тем, что имеем.

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

Под накопители для базы данных хорошо бы иметь диски от 100 тыс. IOPS при рандомном чтении записи 4 килобайт. Такие диски под базы данных хорошо себя показывают.

Процессоры.

• Тут очень важна тактовая частота.

  • Желательно производительностью от 3 GHz. Мы проверяли, производительность процессора хорошо влияет на производительность 1С.

  • Хорошо показали себя всякие технологии, типа Turbo Boost, Hyper-Threading.

• Примеры процессоров – Xeon Gold, Xeon Silver, Xeon D и аналогичные от AMD.

Про память. Оставшиеся деньги вкладывайте в нее. Ее много не бывает. Чем больше – тем лучше.

Для сервера СУБД, сервера приложений, для 1C:ERP нужно от 120 Gb – 1C:ERP очень прожорлива в плане ресурсов и реально потребляет очень много оперативной памяти.

Сервер терминалов

Что касается сервера терминалов – количество пользователей:

• Microsoft рекомендует использовать один сервер терминалов на 50 активных пользователей.

• На Хабре как-то была статья, что в Windows Server 2019 можно пускать на один сервер уже двести пользователей, но пруфов при подготовке к статье не было, поэтому это не точно.

Процессоры. Для сервера терминалов не нужны очень производительные процессоры. Здесь надо сделать упор на число ядер. Можно использовать процессоры из линейки Intel Xeon или аналогичные.

Память. Для системы нужно 4 Гб. Далее, мы замеряли, сколько сейчас в 1C:ERP может потреблять тонкий клиент. Как замеряли: я захожу на терминальный сервер, открываю диспетчер задач, сортирую все процессы 1С и смотрю, сколько кто памяти потребляет. Так вот, к сожалению, до 1 Гб тонкий клиент потребляет при активной работе в 1C:ERP. Поэтому планируя сервер терминалов, только на 1С закладывайте минимум по 1 Гб на каждого активного пользователя.

Диски. Показатели IOPS для дисков должны быть от 25000 – терминальные сервера, как правило, виртуальные, поэтому здесь стоит говорить об IOPS-ах.

Среда разработки

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

• размер информационной базы;

• количество разработчиков;

• количество консультантов.

И вывели вот такую формулу – для сервера баз данных нам достаточно:

• Процессор – от 4 ядер с частотой от 1.9ГГц

• Оперативная память, количество которой рассчитывается по формуле – получается примерно 3 Гб на одного разработчика и 0.5 Гб на одного консультанта.

• Свободное место на диске – по копии продуктивной базы на каждого разработчика

Для сервера приложений оперативной памяти нужно больше – примерно 4 Гб для разработчика, 1 Гб для консультанта.

И вот такие параметры для сервера терминалов.

Обратите внимание, что при разработке в 1С:ERP на сервере терминалов конфигуратор легко может сожрать 5-6 Гб оперативной памяти.

Примеры реального подбора оборудования

Два примера реальных подборов оборудования для 1С:ERP.

На слайде приведены входные данные по первому клиенту.

И конкретное оборудование, которое было выбрано для первого случая.

Входные данные по второму клиенту.

И выбранное для второго клиента оборудование.

Вопросы:

• Сколько ядер нужно под СУБД MS SQL?

• Трудно сказать, сколько ядер под MS SQL. Самый правильный способ подобрать оборудование для сервера ERP – это арендовать на месяц сервер, развернуть Тест-центр, понять, сколько у вас пользователей, сколько у вас ключевых операций и просто тесты погонять – хотя бы типовые тесты.

• Какая должна быть конфигурация компьютера разработчика для ERP?

• SSD и от 8 Гб оперативной памяти. Если этого нет – даже не пытайтесь ERP разрабатывать. Лучше 16 Гб, но 8 Гб тоже работает. И обязательное условие – SSD.

Нужна консультация специалиста? Мы всегда поможем Вам. Индивидуальный подход как залог качества. Звоните!