Периодически к нам приходят ИТ-директора, которым требуется модернизировать ИТ-инфраструктуру под новые требования бизнеса. Перед ними встают вопросы:

• как действовать оптимально с учетом требований бизнеса/затрат;

• можно ли модернизировать текущие компоненты инфраструктуры без их замены;

• как повысить отказоустойчивость.

Откуда появляются требования бизнеса? Здесь все просто - бизнес растет, но не всегда ИТ-инфраструктура была изначально спроектирована с учетом роста, поэтому возникают определенные нюансы, поскольку:

• количество пользователей растет, учетная система (например, 1С:Предприятие) начинает тормозить;

• формат работы становится гибридным, что требует возможности дистанционной работы сотрудников (возможность защищенно подключаться удаленно);

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

С чего начать модернизацию ИТ?

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

Этап 1. Согласовать требования с бизнес - заказчиком

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

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

Этап 2. Оценка потенциала текущей ИТ структуры

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

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

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

Этап 3. Подготовка архитектурного решения

Цель данного этапа - подтвердить практическими замерами корректность выбранной архитектуры.

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

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

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

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

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

Этап 4. Запуск прототипа

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

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

Облако или локальное размещение?

Вопрос где размещать инфраструктуру (в облаке или локально) - всегда вызывает дискуссии.

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

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

Готовность ИТ-службы

• Обязательно нужно выделить команду ИТ-инженеров, отвечающую за поддержку серверной инфраструктуры. Может потребоваться расширение штата.  

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

Наличие технической возможности локального размещения инфраструктуры

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

• Наличие места для размещения оборудования.

Готовность финансовой службы

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

Если один из трех пунктов не выполняется, то следует посмотреть в сторону облака по модели PaaS (Platform as a Service) - платформа, как услуга. В рамках такой модели, инфраструктура может быть облачной, физической, гибридной в зависимости от потребности заказчика.

При выборе облака на первую роль выходит качество предоставления услуги. 

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

Как добиться отказоустойчивости работы 1С

Рассмотрим несколько вариантов реализации отказоустойчивой системы.

1. Репликация

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

Рассмотрим пример, когда реплика создается средствами Hyper-V. Первичные и вторичные серверы могут быть физически расположены совместно или в территориально распределены с репликацией по каналу глобальной сети. Узлы Hyper-V могут быть автономными, кластеризованными. Между серверами нет зависимости Active Directory и они не должны быть членами домена.

Пилотная зона

Это целевая инфраструктура, расположенная в облаке. Позволяет осуществить тестовые нагрузочные испытания системы без влияния на пользователей. В качестве инструмента тестирования используется 1С:ТестЦентр.

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

2. Кластеризация

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

Особенности:

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

• Отказоустойчивость SQL-серверов реализуется при помощи единого хранилища данных. Технология кластеризации Microsoft SQL-Server объединяет два экземпляра серверов СУБД в один кластер с едиными виртуальным IP-адресом и базой данных. При выходе из строя основного SQL-сервера запросы автоматически переводятся на резервный.

• Серверы 1С:Предприятия объединены в отказоустойчивый кластер с автоматическим переключением при сбое. 

• Для работы в формате Web-клиента, подняты два IIS-сервера с распределением запросов round-robins. При выходе из строя одного из серверов, запросы перераспределяются на доступный IIS-сервер.  

Важно! При масштабировании и росте нагрузки, виртуальные машины Сервер 1С и MS SQL выносятся на физические носители, образуя гибридное облако.

Оценочные критерии для простоты модернизации ИТ-инфраструктуры для работы с 1С

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

На какие критерии ориентироваться?

• Индекс производительности приложений APDEX (Application Performance Index)”. Измеримый показатель, где нет субъективности пользователей.

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

Измеряем Тест-центром APDEX

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

Методика APDEX является распространенным стандартом оценки производительности информационных систем и состоит из следующих основных этапов: 

• Получить список ключевых операций

• Определить приоритет каждой операции

• Определить целевое время для каждой операции

• Собрать информацию о времени выполнения каждой ключевой операции

На основании собранных данных получаем оценку APDEX. После этого можно интерпретировать полученный результат в терминах качественных оценок (то есть, по шкале «хорошо - плохо»). 

Интересный факт. При проведении тестирования и проектирования архитектуры, могут понадобиться лицензии 1С:КОРП. Согласно условиям Инфовыпуск № 28859. 15.11.2021 партнерам сети "Центры компетенции 1С:КОРП" для обеспечения использования лицензий "1С:Предприятия 8 КОРП" непосредственно в информационных системах корпоративных пользователей предоставляется возможность получения тестовых лицензий.

Пример масштабирования ИТ-инфраструктуры для 1С

Цель: спроектировать инфраструктуру на 50 пользователей и доказать, что она работоспособна.

Входные параметры:

• действующая инфраструктура (Стенд 1: WinServ 2019 1: 3,7 Ггц, 8 ядер, ОЗУ 108). Работает 20 пользователей 1С:Предприятие.

• динамика роста пользователей составит 30 пользователей в год.

• 1С:Предприятие работает в клиент-серверном варианте.

План действий:

1. Определить потенциальные возможности действующей инфраструктуры “Стенд 1”.

2. Предложить новый вариант архитектуры с  расширением серверной группы.

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

Методика измерения

Метод: динамическая нагрузка.

Нагрузочное тестирование выполняется средствами 1С:ТестЦентр, встроенный в ERP. После каждой успешной итерации выполнения теста, автоматически добавляется 10 пользователей. Тест заканчивается при достижении критических параметров APDEX или таймаута на отклик системы.

Тест включает в себя параллельную работу следующих сотрудников:

• Менеджер по закупкам. Работа с документами: Заказ покупателя / Заказ поставщика / Поступление товаров и услуг / счета фактуры / корректировки 

• Менеджер по продажам. Работает с документами: Заказ покупателя / Реализация товаров / счет-фактура / корректировка реализации и счет фактур / возврат товаров

• Кладовщик. Работает с документами: Приходный ордер / перемещение товара / излишки товара и акт / недостачи товара и акт / расходный ордер на товар

• Финансист по взаиморасчетам. Работа с документами: Поступление дс / Списание дс / Заявки на расход дс / Кассовые ордера / сверка взаиморасчетов / задолженность.

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

Замеры производительности

Этап 1 - Оцениваем текущий сервер. Определяем потенциал действующего сервера ("Стенд 1"). Запускаем нагрузочное тестирование с динамическим добавлением пользователей и определяем возможности оборудования при расширении числа пользователей 1С.

Динамическое нагрузочное тестирование показало, что “Стенд 1” может обслужить до 30-ти пользователей 1С:Предприятие. Но значение APDEX выявило падение производительности учетной системы. Исходя из замеров, можем утверждать, что действующая система (Стенд 1) рассчитан на 20 пользователей 1С. Дальнейший рост пользователей требует расширения вычислительных мощностей, т.к. при параллельной работе 20 пользователей загрузка процессора составляет от 80%.

Этап 2 - Добавляем ресурсы. Оценка дополнительных мощностей, добавление которых позволит увеличить число пользователей 1С до целевого значения 50 человек. В качестве дополнительного сервера используем "Стенд 2". Проводим нагрузочное тестирование - как и в первом случае начальное количество пользователей 20. При успешном выполнении итерации теста, автоматически добавляем 10 пользователей и повторяем тест.

Динамическое нагрузочное тестирование “Стенд 2” показало, что стенд подходит для работы до 40 пользователей 1С. Оптимальное количество 30 пользователей, т.к. далее идет падение производительности и загруженность серверных ресурсов (в частности загруженность процессора составляет более 80%).

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

Этап 3. Делаем кластер

• "Стенд 1" и "Стенд 2" объединены в кластер с распределением нагрузки.

• Выделен центральный сервер "Стенд 2" и рабочий сервер "Стенд 1".

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

Важно: Распределение нагрузки в кластере 1С доступно в лицензиях версии "ПРОФ", но с ограничением использования 12 ядер. Для снятия ограничения необходимо приобретать лицензии "КОРП".

Проведем нагрузочное тестирование кластера ("Стенд 3") с динамическим добавлением пользователей, по аналогии с этапом 1 и этапом 2.

В итоге мы видим, что "Стенд 3" выдерживает 50 пользователей 1С.

Результаты тестирования

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

Вывод

Можно констатировать, что Стенд 3 соответствует планируемому росту пользователей 1С до 50 человек. Но при дальнейшем увеличении пользователей придется масштабировать ИТ-структуру одним из способов:

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

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

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

Отметим ключевые моменты при модернизации ИТ-инфраструктуры для 1С:

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

• Выбрать и придерживаться целевых критериев качества ИТ-инфраструктуры. Критерии должны быть максимально оцифрованы (допустимое время простоя / доступность, скорость работы сервисов, количество пользователей и прочее).

•  Доказать теорию практикой. Спроектированная инфраструктура должна подтвердить свою жизнеспособность на тестовом стенде. 

• Баланс производительности и затрат. Не нужно ориентироваться на приобретение избыточности ресурсов. Использование гибридной инфраструктуры (локальной и облачной) позволит экономически эффективно получить нужный результат.