+7 495 230 03 03 8 800 222 50 03

Проектирование ИТ-инфраструктуры на 1000 пользователей 1С

Дата публикации: 29 сентября 2021
Проектирование ИТ-инфраструктуры на 1000 пользователей 1С
В данной статье мы рассмотрели особенности проектирования крупной облачной ИТ-инфраструктуры для 1С:Предприятие.

Содержание статьи

Проблематика крупной ИТ-структуры

Существует убеждение — крупные ИТ-структуры должны быть построены на собственных мощностях компании и обслуживаться собственным штатом ИТ-специалистов, исходя из многих факторов:
  • Регулирование доступа к конфиденциальным данным (ФЗ-152);
  • Контроль утечки корпоративной информации;
  • Особенности кадровой политики;
  • Расчеты экономического отдела;
  • Разветвленная структура ИТ-департамента;
  • Убеждения ТОП-менеджмента и собственников.
Подобный подход имеет ряд серьезных недостатков:
  • Крупные капитальные затраты на закупку и модернизацию оборудования, программного обеспечения, системы кондиционирования, пожаротушения и т.д.;
  • Регулярные затраты на электроэнергию, систему охлаждения, техническое обслуживание;
  • Расширение серверных ресурсов занимает определенное время;
  • Отсутствие высокой доступности ресурсов в компании с множеством филиалов;
  • Стихийные бедствия, физическое проникновение, противоправные действия третьих лиц;
  • Высокая стоимость внедрения катастрофоустойчивости.

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

Преимущества облачных решений

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

Преимущества размещения своей структуры в облаке:

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

Что такое мультиоблако

Мультиоблачная структура — это такая концепция ИТ-архитектуры, где сервисы компании располагаются на двух и более облачных провайдерах.

Преимущества мультиоблачной архитектуры очевидны:

  • Высокий уровень отказоустойчивости структуры, возможен полноценный кластер с онлайн-синхронизацией и автоматическим переключением;
  • Распределение рисков. При форс-мажоре у одного провайдера — остальные продолжают быть доступными и работа компании не останавливается;
  • Концепция мультиоблака позволяет получить от каждого провайдера его сильные стороны, перекрыв недостатки другими поставщиками услуг;
  • Возможность подобрать облачного провайдера, который находится ближе к удаленным филиалам для оптимизации сетевого отклика;
  • Возможность предоставить временные мощности разработчикам, подрядчикам и прочим сотрудникам, не входящим в штат компании, при этом соблюдая требования корпоративной ИТ-безопасности.
Концепция ИТ-архитектуры 1С, состоящая из нескольких облачных провайдеров, позволяет решать широкий спектр задач, от отказоустойчивости до производительности сервисов.

Проектирование облачной структуры для 1000 пользователей 1С

Рисунок 1 — Проектирование облачной структуры для 1000 пользователей 1С

Сбор требований к структуре

Золотое правило — перед тем, как начинать что-то строить, проект нужно тщательно отрисовать на бумаге. В проектном менеджменте (модель Waterfall) этот этап называется Архитектурирование проекта. Этот этап начинается со сбора требований к будущей архитектуре облака. На наш взгляд, нужно проработать такие ключевые вопросы:
  • Точное количество пользователей, которые будут работать в облаке;
  • Тип конфигураций баз 1С, наличие ключей аппаратной защиты;
  • Допустимое время простоя при недоступности сервиса за определенный период;
  • Объемы баз данных (включая логи транзакций), которые будут мигрировать в облако;
  • Объемы пользовательских данных, необходимых для функционирования сервиса 1С;
  • Перечень торгового оборудования, подключенного к 1С — принтеры этикеток, терминалы сбора данных, онлайн-кассы, сканеры и прочее оборудование;
  • Наличие прочего программного обеспечения, связанного с 1С. Обмены данных, выгрузки на сайты и интернет-магазины, внешние обработки, интеграция с другими сервисами и SaaS-продуктами;
  • Объемы среды разработки и тестовой среды, эту информацию формируют разработчики кода 1С;
  • Периодичность резервного копирования и глубина хранения архива;
  • Требования к уровню защиты каналов связи с облаком и ограничением сетевого доступа внутри периметра облака (к примеру, между средой разработки, тестирования и производственной средой);
  • Прочие нюансы текущей ИТ-структуры, которая обслуживает сервисы программного обеспечения 1С.

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

Имитация нагрузок и ресайзинг для вычисления необходимых ресурсов

В качестве второго этапа подготовки правильной облачной архитектуры, рекомендуем проведение теоретических расчетов требуемых мощностей, выполнение практических тестов по замерам производительности ресурсов на небольшом объеме пользователей и проецирование результатов на необходимые ключевые параметры ИТ-структуры. Для этого, необходимо выполнить ряд нагрузочных тестов совместно со специалистами по технологической платформе и разработчиками кода 1С, базированных на инструментарии 1С:КИП и методике APDEX:
1

На основании имеющихся реестров процессов и контрольных примеров макета базы 1С — необходимо создать матрицу сценариев тестирования должной производительности и объемов ресурсов.

2

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

3

Тесты должны проводиться в рамках нескольких групп пользователей. Группа может состоять из 4 пользователей, у каждого из которых своя роль и перечень последовательных операций, которые выполняет каждый из пользователей:

  • количество групп пользователей обычно рассчитывается по формуле N=K/4, где K – количество пользователей (из расчета, что в одной группе 4 пользователя);
  • количество цепочек на одну группу обычно рассчитывается исходя из того, что одна группа в день за 8 рабочих часов делает 24 цепочки. Таким образом, за 1 час одна группа делает 24/8=3 цепочки с интервалом 20 минут;
  • количество номенклатур в массиве, из которого будет случайным образом подбираться номенклатура в документ поступления, обычно рассчитывается по формуле: P=(K/4)*10*93%, где K – это количество пользователей.
4

Перед началом тестирования требуется определить эталонные показатели APDEX по нагрузке на систему (на одного пользователя):

  • Обращений к диску в секунду;
  • Потребляемая оперативная память;
  • Потребляемые процессорные мощности.
5

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

6

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

7

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

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

Составление архитектуры, подбор вариантов площадок

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

Основные принципы при составлении облачной ИТ-архитектуры:

  • Определение критериев качественной работы облачной ИТ-структуры, внесение их в SLA;
  • Формирование границ бюджета и сроков проекта;
  • Гарантирование должного уровня производительности и отклика структуры, который был определен на этапе сбора требований и ресайзинга;
  • Определение методов и инструментов обеспечения безопасности на соответствующем уровне;
  • Обеспечение доступности и отказоустойчивости согласно утвержденному SLA;
  • Описание методов подключения и доступа к интерфейсам структуры;
  • Прогнозирование роста структуры на определенный период;
  • Распределение ролей и функций (матрица RACI);
  • Прогнозирование и анализ рисков (матрицы FMEA и SFIA).

Выбор вариантов облачных площадок и сервисов

Ключевые критерии при выборе поставщиков облачных услуг:
  • Стоимость пула услуг или оборудования;
  • Стек инструментов и технологий, хорошо знакомый команде ИТ-внедрения;
  • Четкое и приемлемое Соглашение о качестве услуг (SLA либо в некоторых случаях — OLA);
  • Возможность предварительного тестирования услуг на определенный срок;
  • Политика обеспечения резервного копирования и мониторинга (в случае модели SaaS);
  • Удобный и дружелюбный интерфейс панели управления;
  • Наличие персонального менеджера с выделенным контактным номером;
  • Отзывы о качестве работы на популярных интернет-ресурсах.
Может случиться так, что ИТ-архитекторы для определенной части структуры посчитают необходимым воспользоваться моделью аренды серверных платформ (PAAS) вместо аренды сервисов «под ключ» (SaaS). В таком случае, необходимо тщательно подойти к вопросу надежности центра обработки данных, где будут находиться серверы ИТ-структуры. При выборе дата-центра для размещения основных и дублирующих сервисов, рекомендуем обращать внимание на ключевые характеристики по классификации TIER.
Характеристики дата-центров
Требование
Активное оборудование — наличие дублирующих активных компонентов: ИПБ, ДГУ, системы кондиционирования, сетевое оборудование и т.д.
Основной дата-центр
N+1
Резервный дата-центр
N
Требование
Распределенные потоки — дублирование трубопровода охлаждения, каналов связи в здании, электрооборудования.
Основной дата-центр
2
Резервный дата-центр
1
Требование
Возможность обслуживания ЦОД без остановки
Основной дата-центр
Да
Резервный дата-центр
Нет
Требование
Годовой простой, час
Основной дата-центр
1,6
Резервный дата-центр
28,8
Требование
Надежность инфраструктуры
Основной дата-центр
99,982%
Резервный дата-центр
99,671%
Требование
Вероятность остановки в течении 5 лет
Основной дата-центр
25,91
Резервный дата-центр
37,17
Требование
Дублированные, не менее 20 метров друг от друга отдельные телекоммуникационные помещения
Основной дата-центр
Да
Резервный дата-центр
Нет
Требование
Дублирование каналов связи и IT-оборудования клиента
Основной дата-центр
Да
Резервный дата-центр
Нет
Требование
Минимальное расстояние от железной дороги или автострады – 0,8 км, до аэропорта, водной среды – 0,4 км
Основной дата-центр
Да
Резервный дата-центр
Нет
Требование
Минимальное расстояние до общественной зоны – 9,8 метра
Основной дата-центр
Да
Резервный дата-центр
Нет
Требование
Отдельное здание
Основной дата-центр
Да
Резервный дата-центр
Нет
Требование
Отдельные физические зоны для распаковки оборудования, настройки, охраны
Основной дата-центр
Да
Резервный дата-центр
Нет
Требование
Серверные комнаты от других помещений отделены стенами, выдерживающими огонь не менее 1 часа
Основной дата-центр
Да
Резервный дата-центр
Нет

Внедрение ядра ИТ-структуры 1С (более 1000 пользователей). Ключевые рекомендации.

В данном разделе мы будем говорить о более традиционном варианте организации масштабной ИТ-структуры, базированной на арендованных облачных выделенных серверах и ресурсах (так называемый PaaS). Ибо вариант создания архитектуры таких масштабов, базированной на микросервисах (Azure Web App, AWS Beanstalk, CloudDB с использованием load-balancer, autoscaling и т.д.) — является темой отдельной статьи.
Операционная система

Операционная система:

Microsoft Windows Server 2019

Сервис СУБД

Сервис СУБД:

Microsoft SQL Server 2019

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

Резервное копирование:

Veeam Backup & Replication v11

Система мониторинга

Система мониторинга:

Zabbix

Серверы распределенных баз данных для структуры 1С
Ключевые параметры
Производи­тельность
Основные рекомендации
  • Не менее двух процессоров серии Intel® Xeon® Gold или AMD EPYC® с рекомендуемой частотой ядра от 2,6 Ghz в базовом режиме и количеством физических ядер — не менее 8 на каждый процессор;
  • Объем оперативной памяти — не менее 256 Gb DDR4 с частотой не ниже 2933 MHz;
  • Операционную систему рекомендуем размещать на отдельных SSD-дисках или устройствах SataDOM;
  • Под базы данных рекомендуем использовать SSD-диски NVME;
  • Рекомендуем распределять файлы баз данных, логи транзакций, служебные базы tmp и master по разным логическим томам, в идеале — по разным RAID-массивам;
  • Рекомендуем в настройках установить максимально отведенный объем ОЗУ для этого сервера и максимальное кол-во потоков;
  • Требуется выполнить базовую настройку серверов СУБД согласно рекомендациям Microsoft;
  • Не забывайте также о настройке ключевых регламентных заданий по обслуживанию СУБД.
Ключевые параметры
Отказоустой­чивость
Основные рекомендации
  • Для данной структуры рекомендуем создание дублирующего сервера СУБД с вычислительными мощностями не менее 60% – 70% от характеристик основного;
  • Репликацию баз данных рекомендуем делать на базе технологии MS SQL AlwaysON;
  • Рекомендуем тип репликации «асинхронный». В таком варианте система не будет замедляться из-за ожидания отклика от резервной структуры.
Ключевые параметры
Безопас­ность
Основные рекомендации
  • Рекомендуем данный сервис оставить во внутренней приватной зоне сети, без прямого доступа извне;
  • Провести настройку Firewall, оставить открытыми только необходимые порты MS SQL, доступные только для пула адресов серверов 1С;
  • Рекомендуем соблюдать политику конфиденциальности и требования к сложности паролей от Microsoft.
Ключевые параметры
Масштаби­рование
Основные рекомендации
В связи с особенностью архитектуры MS SQL — данный сервис не масштабируется линейно. Поэтому рекомендуем при увеличении нагрузки — создавать прикладные дочерние БД и выносить их на отдельные серверы баз данных.
Ключевые параметры
Лицензиро­вание
Основные рекомендации
Рекомендуем уточнить у провайдера, который предоставляет в аренду облачные серверы баз данных насчет аренды программного обеспечения по модели SPLA. Ибо приобретение в собственное владение лицензий MS SQL выльется в немалые капитальные затраты.
Серверы 1С:Предприятие
Ключевые параметры
Производи­тельность
Основные рекомендации
  • Программа 1С предпочитает высокую частоту многоядерности. Поэтому, рекомендуем не менее двух процессоров серии Intel® Xeon® или AMD EPYC® с рекомендуемой частотой ядра от 3,0 Ghz в базовом режиме и количеством физических ядер — не менее 8 на каждый процессор;
  • Поскольку требования к дисковой подсистеме не так высоки, как у серверов СУБД — это может быть как отдельный аппаратный сервер, так и виртуальная машина. Делайте выбор исходя из бюджета и преимуществ определенного решения;
  • Также хорошо себя зарекомендовала методика разделения основных операций 1С, фоновых заданий и тяжелых расчетов по разным экземплярам серверов 1С:Предприятие. Этот функционал доступен в последних версиях платформы 1С:Предприятие версии КОРП;
  • В отдельных случаях Вы можете встретить рекомендацию по включению режима SharedMemory. За счет прямого доступа к памяти этот режим действительно ускоряет взаимодействие 1С и СУБД до 20%. Однако он требует, чтобы сервер 1С:Предприятие и СУБД находился в одной операционной системе, что в нашей архитектуре +1000 пользователей сделать практически невозможно из-за высоких нагрузок;
  • Рекомендуем выполнить базовую настройку серверов 1С согласно лучшим практикам и рекомендациям производителя.
Ключевые параметры
Отказоустой­чивость
Основные рекомендации
  • Рекомендуем иметь минимум два отдельных сервера 1С:Предприятие с локальным или геозональным разделением;
  • Рекомендуется настроить кластер основного и резервного серверов 1С:Предприятие.
Ключевые параметры
Безопас­ность
Основные рекомендации
  • Рекомендуем данный сервис оставить во внутренней приватной зоне сети, без прямого доступа извне;
  • Провести настройку Firewall, оставить открытыми только необходимые порты MS SQL, доступные только для пула адресов серверов терминального доступа и web-служб 1С;
  • Рекомендуем соблюдать политику конфиденциальности и требования к сложности паролей.
Ключевые параметры
Масштаби­рование
Основные рекомендации
Серверы 1С:Предприятие умеют масштабироваться линейно, однако требуется тщательная настройка специалистов по разработке кода 1С для перенаправления тех или иных операций на разные серверы 1С:Предприятие.
Ключевые параметры
Лицензиро­вание
Основные рекомендации
Рекомендуем закупить пакет лицензий для каждого экземпляра сервера 1С:Предприятие и использовать сервер лицензирования для обеспечения должного уровня отказоустойчивости и скорости переключения на резервный сервис.
Вариант 1. Серверы WEB-доступа для web-интерфейса 1С
Ключевые параметры
Производи­тельность
Основные рекомендации
  • По нашему опыту, для web-серверов нужно закладывать отдельные экземпляры виртуальных машин, т.к. нагрузка от 1000 одновременных web-соединений будет ощутимая;
  • Web-запросы не такие тяжелые, как соединения полноформатных клиентов 1С, поэтому виртуальные машины вполне подойдут для этой роли;
  • Для ускорения работы запросов web — можно делать соединения через открытые каналы Интернет, а не по туннелю. Протокол https сам по себе достаточно защищен шифрованием ssl от фишинга и перехвата данных.
Ключевые параметры
Отказоустой­чивость
Основные рекомендации
  • Для обеспечения отказоустойчивости экземпляров web-серверов используется служба кластера виртуальных машин;
  • Для обеспечения отказоустойчивости соединений используется прокси сервер (к примеру HAProxy).
Ключевые параметры
Безопас­ность
Основные рекомендации
  • Рекомендуем тщательно настроить правила безопасности web-серверов (IIS или Apache) согласно рекомендациям производителей ПО;
  • Рекомендуем закрыть все неиспользуемые порты, а соединение с web-серверами 1С перевести на протокол https (с ssl-шифрованием).
Ключевые параметры
Масштаби­рование
Основные рекомендации
Масштабирование экземпляров не требуется, достаточно линейного увеличения ресурсов.
Ключевые параметры
Лицензиро­вание
Основные рекомендации
Лицензирование ВМ web-серверов в облаке происходит штатно (точно так же, как и находящихся локально) — MS Server, MS CAL
Вариант 2. Серверы терминального доступа для полноформатного клиента 1С
Ключевые параметры
Производи­тельность
Основные рекомендации
  • По нашему опыту, нужно закладывать отдельный сервер терминального доступа на каждые 100 пользователей 1С + один резервный сервер терминалов на всю структуру;
  • Поскольку требования к дисковой подсистеме у серверов терминалов не так высоки, как у серверов СУБД — как правило под них арендуют виртуальные машины;
  • По нашему опыту, для высоконагруженных конфигураций 1С типа ERP — закладывайте до 1,5-2 Гб ОЗУ на каждого пользователя. Для менее нагруженных (УТ, БУХ) — до 1 Гб;
  • Дисковая подсистема — рекомендуем арендовать массивы, базированные на SSD-дисках с пропускной способностью iops не менее 3000. Все таки, серверы терминалов имеют статус интерактивных и обращения к дисковой подсистеме там будут интенсивные;
  • Рекомендуем выполнить базовую настройку серверов терминального доступа согласно лучшим практикам и рекомендациям Microsoft.
Ключевые параметры
Отказоустой­чивость
Основные рекомендации
  • Для обеспечения отказоустойчивости рекомендуем использовать службу TS Broker, расположенную на отдельной виртуальной машине. С ее помощью и за счет кластерного сервиса NLB — сеансы пользователей равномерно распределяются по всей ферме серверов терминального доступа и автоматически переключаются при наступлении форс-мажорной ситуации с одним из них;
  • Не забывайте persistent-данные вынести за пределы фермы терминального доступа (к примеру, профили, файловые документы и прочие статические данные должны храниться на отдельном сетевом ресурсе). В идеале, серверы терминального доступа должны быть stateless;
  • Для создания отказоустойчивой фермы терминалов требуется n+1 количество экземпляров серверов терминального доступа.
Ключевые параметры
Безопас­ность
Основные рекомендации
  • Рекомендуем тщательно настроить групповые политики для регулирования прав пользователей в среде сервера терминалов, чтобы минимизировать их влияние на систему, по максимуму ограничить интерфейс и предоставить только необходимый набор прав;
  • Рекомендуем настроить Firewall таким образом, чтобы ограничить доступ из внешней среды Internet к ферме серверов терминального доступа;
  • Рекомендуем соблюдать политику конфиденциальности и требования к сложности паролей Microsoft.
Ключевые параметры
Масштаби­рование
Основные рекомендации
Ферма терминальных серверов прекрасно масштабируется в линейном порядке. Следует только добавить в ферму новый сервер и TSBroker сам начнет регулировать нагрузку и проверять доступность для пользователей.
Ключевые параметры
Лицензиро­вание
Основные рекомендации
  • Лицензирование серверов терминалов в Облаке происходит штатно (точно так же, как и находящихся локально) — MS Server, MS RDS CAL, MS CAL;
  • Рекомендуем уточнить у провайдера, который предоставляет в аренду данные виртуальные машины насчет аренды программного обеспечения по модели SPLA.
Технические инфраструктурные серверы
Роль или сервис
Контроллеры домена
Рекомендации
  • Рекомендуется размещать на отдельных виртуальных машинах. Компания Microsoft не рекомендует совмещать эту роль ни с какой другой;
  • Рекомендуется тщательно настроить и отладить групповые политики и перенаправление профилей. Для такого кол-ва пользователей системность и упорядоченность — залог стабильно работающей структуры;
Роль или сервис
Шлюзы фермы терминалов
Рекомендации
Данная роль необходима для удаленного доступа пользователей к ферме терминалов по протоколу ssl (443 порт). Для ее корректной работы рекомендуется отрегулировать сетевой доступ посредством Firewall, чтобы отсеять попытки несанкционированного проникновения в систему.
Роль или сервис
Система мониторинга
Рекомендации
Можно воспользоваться услугами провайдеров дата-центра, которые нередко предлагают за небольшой бюджет подключить свою центральную систему мониторинга. Второй вариант — взять отдельную виртуальную машину с Linux и поднять собственную систему, к примеру Zabbix. Мы рекомендуем вариант 2, т.к. столь крупная структура потребует определенной персональной настройки системы мониторинга, а типовые сервисы провайдера не всегда могут ее предоставить.
Роль или сервис
Резервное копирование
Рекомендации
  • Мы рекомендуем использовать программное обеспечение Veeam Backup для создания архивов данных с должной глубиной и частотой выполнения. Поскольку часть виртуальных машин предполагается взять в аренду — то есть смысл уточнить у самого дата-центра, какие инструменты резервного копирования и обеспечения архива они предоставляют;
  • Параллельно рекомендуем реализовать дублирующий инструмент резервного копирования, для подстраховки. К примеру, для СУБД — это скрипт SQL резервного копирования баз, для файловых данных — утилита, умеющая работать с теневым копированием. Для 100% гарантии наличия резервных копий — дублирующий инструмент должен складывать архив на дублирующий ресурс хранения резервных копий, в идеале — вне пределов дата-центра.

Пример архитектуры и ориентировочный бюджет

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

Техническая реализация

  • Ядро системы — сервер управления базами данных 1С будет располагаться на высокопроизводительной аппаратной платформе с процессорами Intel® Xeon® Gold и дисковой подсистемой SSD NVME;
  • Дублирующий сервер СУБД также будет базироваться на отдельной аппаратной платформе. Кластеризация СУБД будет реализована по технологии репликации баз AlwaysON;
  • Сервер 1С:Предприятие будет состоять из нескольких нод, расположенных на разных виртуальных машинах и соединенных в отказоустойчивый кластер. Виртуальные диски должны располагаться на дисковых массивах Enterprise SSD, т.к. серверы 1С под высокой нагрузкой активно используют cache, а на конфигурации ERP с таким количеством пользователей нагрузка будет реально высокая. Итак, закладываем не менее 3 нод для основных операций + отдельная нода для фоновых заданий и тяжелых отчетов;
  • Для клиентской части рассмотрим два варианта:
    • Использование web-интерфейса 1С. Этот вариант позволяет сэкономить на ресурсах и программном обеспечении для серверов терминалов, но требует адаптации интерфейсов системы 1С программистами и разработчиками кода;
    • Полноценные серверы терминального доступа. Закладываем до 10 виртуальных машин под серверы терминального доступа, объединенные в ферму терминалов. Для каждой отводим не менее 96 ГБ ОЗУ и высокоскоростные диски.
  • Арендуем две виртуальные машины для файловых серверов, на которых будет хранилище документов и профиля пользователей 1С;
  • Берем две отдельные виртуальные машины для основного и резервного контроллеров домена;
  • Закладываем еще две виртуальные машины для доступа к 1С извне:
    • В варианте web-интерфейса 1С это будут серверы обработки web-трафика IIS или Apache;
    • Во втором варианте — основной и резервный шлюза терминального доступа, по которому пользователя будут попадать в среду терминалов извне.
  • На отдельные виртуальные машины установим также основной и резервный Broker-сервисы, которые регулируют распределение пользователей в ферме терминальных серверов для варианта 2;
  • Предполагаем, что сервис мониторинга, резервного копирования и место под архивы мы арендуем у дата-центра, т.к. по нашим расчетам — это выгодно экономически.

Рисунок 2 — Схема структуры. Вариант 1 — web-серверы и web-интерфейс 1С

Рисунок 3 — Схема структуры. Вариант 2 — ферма терминальных серверов

Расчет аренды с примерным бюджетом

Аппаратная серверная часть

Вариант 1. Структура на основе web-интерфейса 1С
Сервер либо ВМ
Аппаратный сервер СУБД
Характеристики

Bare-Metal Server

  • 2 x Intel Xeon Gold 2.8 GHz, 8 cores;
  • 256 GB DDR4;
  • 2 x 960GB NVMe.
Кол-во
2
Стоимость с НДС/мес
114 000 руб
Сервер либо ВМ
Виртуальные машины — сервер 1С:Предприятие
Характеристики

Virtual Machine

  • 8 x vCPU 3,6 Ghz;
  • 128 GB DDR4;
  • 100 GB SSD.
Кол-во
4
Стоимость с НДС/мес
166 000 руб
Сервер либо ВМ
Виртуальные машины — контроллеры домена
Характеристики

Virtual Machine

  • 4 x vCPU 2,6 Ghz;
  • 4 GB DDR4;
  • 50 GB SSD.
Кол-во
2
Стоимость с НДС/мес
17 400 руб
Сервер либо ВМ
Виртуальные машины — web-серверы
Характеристики

Virtual Machine

  • 4 x vCPU 2,6 Ghz;
  • 8 GB DDR4;
  • 50 GB SSD.
Кол-во
2
Стоимость с НДС/мес
26 500 руб
Сервер либо ВМ
Аренда системы мониторинга и резервного копирования
Характеристики
  • Система мониторинга;
  • Система резервного копирования;
  • Объем места под архивы 4 Тб.
Кол-во
1
Стоимость с НДС/мес
43 000 руб
Вариант 2. Структура на основе фермы терминальных серверов
Сервер либо ВМ
Аппаратный сервер СУБД
Характеристики

Bare-Metal Server

  • 2 x Intel Xeon Gold 2.8 GHz, 8 cores;
  • 256 GB DDR4;
  • 2 x 960GB NVMe.
Кол-во
2
Стоимость с НДС/мес
114 000 руб
Сервер либо ВМ
Виртуальные машины — сервер 1С:Предприятие
Характеристики

Virtual Machine

  • 8 x vCPU 3,6 Ghz;
  • 128 GB DDR4;
  • 100 GB SSD.
Кол-во
4
Стоимость с НДС/мес
166 000 руб
Сервер либо ВМ
Виртуальные машины — сервер терминального доступа
Характеристики

Virtual Machine

  • 8 x vCPU 2,4 Ghz;
  • 128 GB DDR4;
  • 100 GB SSD.
Кол-во
10
Стоимость с НДС/мес
350 000 руб
Сервер либо ВМ
Виртуальные машины — контроллеры домена
Характеристики

Virtual Machine

  • 4 x vCPU 2,6 Ghz;
  • 4 GB DDR4;
  • 50 GB SSD.
Кол-во
2
Стоимость с НДС/мес
17 400 руб
Сервер либо ВМ
Виртуальные машины — шлюз терминального доступа
Характеристики

Virtual Machine

  • 4 x vCPU 2,6 Ghz;
  • 4 GB DDR4;
  • 50 GB SSD.
Кол-во
2
Стоимость с НДС/мес
17 400 руб
Сервер либо ВМ
Виртуальные машины — брокер терминальных сеансов
Характеристики

Virtual Machine

  • 4 x vCPU 2,6 Ghz;
  • 4 GB DDR4;
  • 50 GB SSD.
Кол-во
2
Стоимость с НДС/мес
17 400 руб
Сервер либо ВМ
Аренда системы мониторинга и резервного копирования
Характеристики
  • Система мониторинга;
  • Система резервного копирования;
  • Объем места под архивы 4 Тб.
Кол-во
1
Стоимость с НДС/мес
43 000 руб

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

Вариант 3. Закупка в собственное владение
Сервер либо ВМ
Выделенный сервер для СУБД
Характеристики
Платформа Supermicro 1U Ultra SuperServer / Intel Xeon Gold 12-core, 2.80GHz / 4*64 GB DDR4 / 2 * SATA-DOM 128Gb / 4 * ​​SSD 1.6 Tb U.2 NVMe
Кол-во
2
Стоимость с НДС/разово
2 400 000 руб
Сервер либо ВМ
Носители виртуальных машин для серверов 1С:Предприятие
Характеристики
Платформа Supermicro 1U Ultra SuperServer / Intel Xeon Gold 8-core, 3.60GHz / 4*64 GB DDR4 / 2 * SATA-DOM 128Gb / 2 * ​​SSD 600 Gb NVMe
Кол-во
2
Стоимость с НДС/разово
2 250 000 руб
Сервер либо ВМ
Носители виртуальных машин для остальных сервисов
Характеристики
Платформа Supermicro 1U Ultra SuperServer / Intel Xeon Silver 12-core, 2.60GHz / 2*64 GB DDR4 / 2 * SATA-DOM 128Gb / 2 * ​​SSD 600 Gb
Кол-во
2
Стоимость с НДС/разово
1 480 000 руб
Дополнительные затраты
Серверный шкаф
Кол-во
1
Стоимость с НДС/разово
65 000 руб
Дополнительные затраты
Коммутационное оборудование
Кол-во
2
Стоимость с НДС/разово
48 000 руб
Дополнительные затраты
Проектные услуги по сборке, настройке, пусконаладке и интеграции указанной структуры
Кол-во
1
Стоимость с НДС/разово
380 000 руб

Программная часть — лицензии Microsoft и 1С

Как мы уже говорили в одном из разделов — гораздо выгоднее получить лицензии на программное обеспечение в аренду, переводя их в операционные затраты, чем получить капитальные затраты на солидную даже для крупного бизнеса сумму. Однако с арендой программного обеспечения Microsoft есть нюансы — напрямую его нельзя получить в субаренду. Либо хостинг предоставляет их в рамках аренды оборудования или Облака (PaaS) либо обслуживающая Вас организация по вопросам ИТ — является партнером Microsoft в программе SPLA и укажет данные серверные и виртуальные платформы в договоре на обслуживание ИТ. В нашем примере мы пойдем по второму сценарию — включение ежемесячной аренды лицензий Microsoft и серверной части 1С в договор по информационно-техническому обслуживанию (с небольшой наценкой, к примеру 10% от их себестоимости, для большей реалистичности расчета).
Вариант 1. Структура на основе web-интерфейса 1С
1
Наименования лицензии SPLA
Лицензия на ядра Microsoft Server WinSvrSTDCore ALNG LicSAPk MVL 2Lic CoreLic
Кол-во
40
Стоимость с НДС/мес
13 200 руб
2
Наименования лицензии SPLA
Лицензия на ядра СУБД SQLSvrStdCore ALNG LicSAPk MVL 2Lic CoreLic
Кол-во
16
Стоимость с НДС/мес
172 000 руб
3
Наименования лицензии SPLA
Лицензия на сервер 1С:Предприятие КОРП
Кол-во
4
Стоимость с НДС/мес
60 000 руб
Вариант 2. Структура на основе фермы терминальных серверов
1
Наименования лицензии SPLA
Лицензия на ядра Microsoft Server WinSvrSTDCore ALNG LicSAPk MVL 2Lic CoreLic
Кол-во
84
Стоимость с НДС/мес
27 720 руб
2
Наименования лицензии SPLA
Лицензия на ядра СУБД SQLSvrStdCore ALNG LicSAPk MVL 2Lic CoreLic
Кол-во
16
Стоимость с НДС/мес
172 000 руб
3
Наименования лицензии SPLA
Лицензия на сервер 1С:Предприятие КОРП
Кол-во
4
Стоимость с НДС/мес
60 000 руб
4
Наименования лицензии SPLA
Лицензия на терминальный сеанс WinRmtDsktpSrvcsSAL ALNG LicSAPk MVL
Кол-во
1 000
Стоимость с НДС/мес
478 000 руб
Вариант 3. Закупка ПО в собственное владение
1
Наименования лицензии
Лицензия Microsoft Windows Server Standard 2019. 2 Core License Pack. Бессрочная лицензия CSP
Кол-во
52
Стоимость с НДС
462 000 руб
2
Наименования лицензии
Microsoft Windows Server CAL 2019. Бессрочная лицензия CSP
Кол-во
1 000
Стоимость с НДС
2 383 000 руб
3
Наименования лицензии
Microsoft SQL Server Standard (лицензия 2 Core License Pack)
Кол-во
12
Стоимость с НДС
2 797 320 руб
4
Наименования лицензии
Лицензия на сервер 1С:Предприятие КОРП
Кол-во
4
Стоимость с НДС
864 000 руб
5
Наименования лицензии
Veeam Backup & Replication. Постоянная лицензия Standard
Кол-во
6
Стоимость с НДС
747 180 руб
Итоговый примерный бюджет
Наименование
Аппаратная часть
Вариант 1. Структура на основе web-интерфейса 1С
366 900 руб/мес
Вариант 2. Структура на основе фермы терминальных серверов
725 200 руб/мес
Вариант 3. Закупка в собственное владение
6 623 000 руб
Наименование
Програм­мная часть
Вариант 1. Структура на основе web-интерфейса 1С
245 200 руб/мес
Вариант 2. Структура на основе фермы терминальных серверов
737 720 руб/мес
Вариант 3. Закупка в собственное владение
7 253 500 руб
Наименование
Итого
Вариант 1. Структура на основе web-интерфейса 1С
612 100 руб/мес
Вариант 2. Структура на основе фермы терминальных серверов
1 462 920 руб/мес
Вариант 3. Закупка в собственное владение
13 876 500 руб
Как видим, срок окупаемости оборудования, находящегося в собственном владении составляет более 22 мес. За это время может возникнуть необходимость в модернизации серверного аппаратного обеспечения либо программных лицензий, что потребует новых капитальных вложений.

Выводы статьи

  • Экосистема относительно крупной ИТ-структуры (от 1000 пользователей 1С:ERP) имеет нетиповое строение и проблематику и не может руководствоваться типовыми правилами ИТ-архитектуры и безликими рекомендациями из Интернет.
  • Облачные технологии позволяют решить 4 крупные проблемы с локальной серверной структурой:
    • Обеспечение требуемого быстродействия, регулируемого юридическими соглашениями;
    • Предоставление высокого уровня стабильности и отказоустойчивости;
    • Надежную защиту от киберугроз;
    • Быстрое масштабирование и экономию бюджета за счет перевода капитальных затрат в операционные.

При проектировании облачной структуры требуется тщательная информационная подготовка — 50% успеха закладывается еще на бумаге.

Рекомендации:

  • Рекомендуется пользоваться выгодами мультиоблачной концепции, чтобы брать от каждого провайдера его преимущества и перекрывать недостатки. Также это прекрасно диверсифицирует риски форс-мажорных ситуаций;
  • Сердце системы — серверы баз данных рекомендуется оставлять на мощных аппаратных платформах, а остальные сервисы можно расположить в виртуальной среде;
  • Рекомендуется разделять серверы 1С по функциям, снижая общую нагрузку на систему;
  • Рекомендуется не экономить на резервировании и дублировании ключевых ролей, иначе бизнес может потерять несоизмеримо больше ресурсов;
  • Все ресурсы и услуги, которые можно взять в аренду — лучше арендовать.
Лого ES мини

EFSOL

  • Аноним

    Кластер СУБД распределяет нагрузку на две ноды?

    • https://efsol.ru/ EFSOL

      Нет, кластер СУБД в режиме AllwaysON служит для отказоустойчивости.

Заказать звонок

Оставьте свои данные для того, чтобы специалист с вами связался.

*нажимая на кнопку, Вы даете согласие на обработку персональных данных
Быстрое внедрение включает:
На сервере установлено следующее ПО (доступно при подключении по протоколу RDP):
Также настроено:
Перед внедрением клиент предоставляет информацию о пользователях (логины и пароли). После завершения работ, клиенту высылается инструкция и ярлык для подключения.
Индивидуальное внедрение по ТЗ клиента обсуждается отдельно.