Кластер серверов 1С:Предприятия 8 (1C:Enterprise 8 Server Cluster)

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

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

Можно выделить следующие возможности кластера серверов, как основные:

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

Клиент-серверный вариант. Схема работы

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

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

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

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

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

Кластер серверов

Элементарный кластер серверов может представлять собой единственный компьютер и содержать только один рабочий процесс.

На рисунке можно наблюдать все элементы, которые, так или иначе, принимают участие в работе кластера серверов. Это следующие элементы:

• процессы кластера серверов:
  o ragent.exe;
  o rmngr.exe;
  o rphost.exe;
• хранилища данных:
  o список кластеров;
  o реестр кластера.

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

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

Сам кластер серверов состоит из таких элементов:

• один или несколько процессов rmngr.exe
• реестр кластера
• один или несколько процессов rphost.exe.

Менеджер кластера (процесс rmngr.exe). Он служит для управления функционирования всего кластера. В состав кластера может входить несколько процессов rmngr.exe, один их которых всегда будет главным менеджером данного кластера, а остальные процессы – дополнительными менеджерами. Центральным сервером кластера следует называть рабочий сервер, на котором действует главный менеджер кластера, и который содержит список кластера. Именно ведение реестра кластера является одной из функций главного менеджера кластера.

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

Масштабируемость 1С версии 8.3

Масштабируемость кластера серверов осуществляется следующими способами:

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

Использование одновременно нескольких менеджеров.

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

Однако некоторые сервисы могут быть использованы только главным менеджером кластера:

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

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

• сервис журналов регистрации
• сервис блокировки объектов
• сервис заданий
• сервис полнотекстового поиска
• сервис сеансовых данных
• сервис нумерации
• сервис пользовательских настроек
• сервис времени
• сервис транзакционных блокировок.

Использование одновременно нескольких рабочих процессов.

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

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

Отказоустойчивость 1С версии 8.3

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

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

Резервирование кластера 1С версии 8.3

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

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

Резервирование рабочих процессов 1С версии 8.3

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

• использовать
• не использовать
• использовать как резервный.

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

Устойчивость 1С версии 8.3 к обрыву канала связи

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

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

Сеансы работы в 1С версии 8.3

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

• Тонкий клиент, Веб-клиент, Толстый клиент – эти сеансы возникают при обращении соответствующих клиентов к информационной базе
• Соединение типа «Конфигуратор» — оно возникает при обращении к информационной базе конфигуратора
• СОМ-соединение – образовывается при использовании внешнего соединения для обращения к информационной базе
• WS-соединение – возникает в случае обращения к информационной базе веб-сервера, как следствие обращения к опубликованному на веб-сервере Web-сервису
• Фоновое задание – образовывается, когда рабочий процесс кластера обращается к информационной базе. Служит такой сеанс для исполнения кода процедуры фонового задания,
  Консоль кластера – создается, когда утилита администрирования клиент-серверного варианта обращается к рабочему процессу
• СОМ-администратор – возникает в случае обращения к рабочему процессу с использованием внешнего соединения.
• Работа при использовании различных операционных систем

Любые процессы кластера серверов могут функционировать как под операционной системы Linux, так и под операционной системы Windows. Это достигается тем, что взаимодействие кластеров происходит под управлением протокола TCP/IP. Также в состав кластера могут входить рабочие серверы под управлением любой из этих операционных систем.

Утилита администрирования кластера серверов 8.3

В комплекте поставки системы имеется утилита для администрирования варианта клиент-серверной работы. Эта утилита дает возможность изменения состава кластера, управления информационными базами, и оперативно анализировать транзакционные блокировки.

Заказать демонстрацию Заказать

В данной статье будут рассмотрены несколько вариантов структуры 1С для высоконагруженных систем (от 200 активных пользователей), построенных на базе клиент-серверной архитектуры – их преимущества и недостатки, стоимость инсталляции и сравнительные тесты производительности каждого варианта.

Мы не будем проводить описание, оценку и сравнение общепринятых и всем давно известных классических схем построения серверной структуры 1С, таких как отдельный сервер 1С и отдельный сервер СУБД, либо кластер Microsoft SQL с кластером 1С. Таких обзоров великое множество, в том числе и проведенных самими производителями программных продуктов. Мы предложим обзор схем построения структуры 1С, которые встречались за последние несколько лет в наших ИТ-проектах для среднего и крупного бизнеса.

Требования к высоконагруженным системам 1С

Высоконагруженные системы 1С, работающие с крупными массивами данных в режиме 24/7/365 подвержены факторам риска, которые в стандартных ситуациях обычно не наблюдаются. Как следствие, для их устранения и упреждения требуется применение особенных схем архитектуры 1С и новых технологий.

Катастрофоустойчивость СУБД. В процессе проектирования архитектуры 1С делается упор на вычислительные мощности и высокую доступность сервисов, выраженную в их кластеризации. Серверы 1С:Предприятие по умолчанию способны работать в дублирующем кластере, а для кластера СУБД обычно применяется промышленная система хранения данных (СХД) и технология кластеризации (к примеру, Microsoft SQL Cluster). Однако, ситуация становится плачевной, когда проблемы случаются с самой СХД (зачастую, по нашему опыту последних лет – это проблемы программного характера). Тогда у ИТ-инженера резко возникают две проблемы – где взять актуальные данные и куда их развернуть в кратчайшие сроки, поскольку система хранения данных с нужным объемом быстрого массива дисков недоступна.

Требования к безопасности базы данных. Работая с проектами среднего и крупного бизнеса, мы регулярно сталкиваемся с требованиями по защите персональных данных (в частности, для выполнения пунктов ФЗ-152). Одним из условий выполнения этих требований является обеспечение должной сохранности персональных данных, что требует шифрования базы данных 1С.

При разработке схемы высоконагруженных систем 1С обычно обращают внимание в первую очередь на параметры дисковой системы ввода\вывода, на которой расположены базы данных. Но помимо этого, еще существует активная утилизация ресурсов ЦПУ и потребление ОЗУ сервером 1С. Зачастую именно этого типа ресурсов и не хватает, возможности аппаратной модернизации текущего сервера 1С исчерпываются и требуется добавление новых серверов 1С, работающих с единым сервером СУБД.

Схемы организации кластеров серверов 1С

Схема с кластером 1С-серверов, подсоединенным к кластеру с синхронной репликацией SQL AlwaysOn по протоколу IP. Данная схема является одним из качественных вариантов решения проблемы катастрофоустойчивости базы данных 1С (см. Рисунок 1). Технология кластеризации баз SQL AlwaysOn основана на принципе онлайн-синхронизации таблиц SQL между основным и резервным серверами без вмешательства конечного пользователя. С помощью SQL Listener есть возможность переключиться на резервный сервер SQL в случае выхода из строя основного, что позволяет назвать данную систему полноценным катастрофоустойчивым кластером SQL, благодаря использованию двух независимых серверов SQL. Технология SQL Always On доступна только в версии Microsoft SQL Enterprise.

Рисунок 1 - схема кластера серверов 1С + SQL AlwaysOn

Вторая схема идентична первой, добавлено только шифрование баз SQL на основном и резервном сервере. Мы уже упоминали о том, что работа с последними ИТ-проектами показала, что компании начали гораздо больше внимания уделять вопросу безопасности данных, по различным причинам – требования ФЗ-152, рейдерские захваты серверов, утечка данных в облаке и тому подобное. Так что считаем данный вариант схемы 1С довольно актуальным (см. Рисунок 2).

Рисунок 2 - схема кластера серверов 1С + SQL AlwaysOn с шифрованием

Кластер серверов 1С "active-active", подсоединенный к единственному серверу СУБД по протоколу IP. В противовес потребностям в отказоустойчивости и безопасности – некоторым структурам в первую очередь требуется повышенная производительность, так сказать «вся вычислительная мощь». Поэтому максимальный приоритет отдается увеличению количества вычислительных кластеров сервера 1С, на которые современная платформа 1С позволяет дифференцировать различные типы вычислений и фоновые задания (см. Рисунок 3). Конечно же, комплектация основных ресурсов сервера SQL тоже должна быть на уровне, однако сам сервер баз данных представлен в единственном числе (видимо, расчет идет на своевременное резервное копирование баз).

Рисунок 3 - схема кластера серверов 1С с одним сервером СУБД

Сервер 1С и СУБД на одном аппаратном сервере с SharedMemory. Поскольку наши практические тесты ориентированы на сравнение производительности разных схем, то обязательно требуется некий эталон для сравнения нескольких вариантов (см. Рисунок 4). В качестве эталона, по нашему мнению, нужно взять схему расположения сервера 1С и СУБД на одном аппаратном сервере без виртуализации с взаимодействием по SharedMemory.

Рисунок 4 - схема сервера 1С и СУБД на одном аппаратном сервере с SharedMemory

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

Критерии оценки архитектур 1С	Кластер 1С + SQL AlwaysOn	Кластер 1С + SQL AlwaysOn с шифрованием	Кластер 1С с одним сервером СУБД	Классический 1С+СУБД SharedMemory
Легкость инсталляции и обслуживания	Удовл.	Удовл.	Хорошо	Отлично
Отказоустойчивость	Отлично	Отлично	Удовл.	Не применимо
Безопасность	Удовл.	Отлично	Удовл.	Удовл.
Бюджетность	Удовл.	Удовл.	Хорошо	Отлично

Таблица 1 - сравнение вариантов построения систем 1С

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

Описание методики тестирования

Этап тестирования состоит из двух ключевых инструментов синтетической генерации нагрузки и имитации работы пользователей в 1С. Это тест Гилева (TPC-1C) и «Тест центр» из инструментария 1С: КИП.

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

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

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

Тест осуществляется в рамках нескольких групп пользователей. Группа состоит из 4 пользователей, у каждого из которых есть своя роль и перечень последовательных операций. Благодаря гибкому механизму задания параметров для тестирования, можно запускать тест на разное количество пользователей, что позволит оценить поведение системы при различных нагрузках и определить параметры, которые могут привести к снижению показателей производительности. Проводится 3 теста по 3 итерации в которых разработчик 1С запускает тест с эмуляцией работы пользователей и замеряет время выполнения каждой операции. Выполняются замеры всех трех итераций для каждой из схем структуры 1С. Результатом теста является получение среднего времени выполнения операции для каждого документа матрицы.

Показатели «Тест центра» и теста Гилева будут отражены в сводной таблице 2.

Тестовый стенд

Сервер терминального доступа – виртуальная машина, использовалась для управления инструментами тестирования:

• vCPU - 16 ядер 2.6GHz
• RAM - 32 ГБ
• I\o: Intel Sata SSD Raid1

• RAM - 96 ГБ
• I\o: Intel Sata SSD Raid1

Сервер 1С и СУБД - физический сервер

• CPU - Intel Xeon Processor E5-2670 8C 2.6GHz – 2 шт
• RAM - 96 ГБ
• I\o: Intel Sata SSD Raid1
• Роли: Сервер 1С 8.3.8.2137, Сервер MS SQL 2014 SP 2

Выводы

Можем сделать вывод, что по среднему времени выполнения операции наиболее оптимальной является схема №3 «Кластер серверов 1С "active-active", подсоединенный к единственному серверу СУБД по протоколу IP» (см. Таблица 2). Для обеспечения отказоустойчивости такой архитектуры мы рекомендуем строить классический отказоустойчивый кластер MSSQL с размещением базы данных на отдельной СХД.

Важно отметить, что наиболее оптимальное соотношение факторов минимизации простоя, отказоустойчивости и сохранности данных - у схемы №1 «Кластер 1С-серверов, подсоединенный к кластеру с синхронной репликацией SQL AlwaysOn по протоколу IP», при этом падение производительности по отношению к самому производительному варианту составляет примерно 10%.

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

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

Схема архитектуры 1С	Среднее время выполнения операции, сек			Средний процент отклонения от эталона	Тест Гилева, усл. ед.
	50 пользователей	100 пользователей	150 пользователей
Схема структуры №1 "Кластер 1С-серверов, подсоединенный к кластеру с синхронной репликацией SQL AlwaysOn по протоколу IP"	0,42245	0,44433	0,4391	На 14%	25,13
Схема структуры №2 "Кластер 1С-серверов, подсоединенный к кластеру с синхронной репликацией SQL AlwaysOn по протоколу IP с шифрованием"	0,435505	0,425227	0,425909	На 12%	21,65
Схема структуры №3 "Кластер серверов 1С "active-active", подсоединенный к единственному серверу СУБД по протоколу IP."	0,40901	0,41368	0,42852	На 9%	28,09
Эталон. Схема структуры №4 "Расположение сервера 1С и СУБД на одном аппаратном сервере без виртуализации с взаимодействием по SharedMemory"	0,36020	0,42385	0,36335	---	34,23

Таблица 2 - Итоговая таблица (сокращенный вариант) практических испытаний разных вариантов построения систем 1С

Термины, понятия

Зачем нужен сервер 1С

Под понятием «кластер серверов» понимается несколько компьютеров (серверов) выполняющих общую задачу.

Задачи, решаемые кластером серверов 1С:Предприятие 8 на рисунке ниже.

Разница между 8.1 и 8.2

Кластер 1С 8.1

Кластер серверов 1C:Предприятие 8.1 – это реализация идей распределения нагрузки на сервера, обслуживающие клиентские запросы. Такой механизм реализует распределение нагрузки на вычислительные ресурсы в рамках одного сервера или нескольких серверов («Рабочих серверов»), обеспечивая, таким образом, масштабирование приложения. Кластер серверов дублирует код, обслуживающий клиентские соединения. Дублирующийся исполняемый код кластера назван «Рабочим процессом» (rphost). При установке кластера создается только один рабочий процесс.
Несколько рабочих процессов на одном сервере дают возможность эффективно использовать объем оперативной памяти и ресурсы процессора для выполнения запросов, а также подключить клиентский сеанс к другому рабочему процессу при «крахе» текущего.
За понимание, что запущено на конкретном сервере, отвечает программа «Агент сервера» (ragent). Остановка агента сервера сделает сервер недоступным для использования кластером. Свою информацию агент хранит в файле srvribrg.lst.
Информацией о рабочих базах, задействованных рабочих процессах владеет «Менеджер сервера» (rmngr). Эту информацию он хранит в файле 1CV8Reg.lst. Остановка менеджера сервера может привести к перезапуску клиентских приложений в случаи удачного рестарта менеджера или к полной остановке работы рабочих серверов всего кластера.
1С:Предприятие 8.1 допускает возможность создания на одном сервере несколько независимых кластеров. Каждый из них идентифицируется в сети уникальным «IP портом» и уникальным номером в служебных файлах. Первый кластер по умолчанию получает порт 1541.
Для управления кластером предназначена оснастка «Серверы предприятия».
Подключаться к серверам можно по имени или IP адресу сервера.

Агент сервера

Агент сервера «знает» о всех кластерах, которые запущены на сервере. Эта информация хранится в файле srvribrg.lst со списком кластеров и администраторов списка. Основной порт агента – 1540. На каждом Рабочем сервере может быть запущен только один агент, обслуживающей все возможные кластера на данном сервере.
Чтобы получить более детальную информацию наглядно, воспользуйтесь утилитой Process Explorer (разработчик Sysinternals). Программа позволяет глубже заглянуть внутрь любых выполняемых процессов, в том числе кластера серверов 1С:Предприятия 8.1.

Менеджер кластера

Менеджер кластера отвечает за работу кластера. У каждого кластера свой Менеджер. Менеджер хранит информацию о кластере в файле 1CV8Reg.lst (реестр кластера). У каждого Менеджера кластера также есть свой порт на Рабочем сервере. Для первого кластера по умолчанию порт Менеджера 1541. Именно этот порт отображается в оснастке «Серверы 1С:Предприятия» в ветке «Кластеры», идентифицируя кластер.
Менеджер принимает запросы от клиентской части 1С:Предприятия 8.1 и принимает решение, какому Рабочему процессу отдать этот запрос на обслуживание.

Для взаимодействия с рабочими процессами Менеджер использует служебный порт.

Рабочий процесс

За «работу с клиентами» отвечает Рабочий процесс. Можно сказать, что в предыдущей версии 1С:Предприятия 8.0 «Рабочий процесс» был один.
Рабочих процессов в кластере 1С:Предприятия 8.1 может быть несколько. Менеджер сервера решает, какой из рабочих процессов будет обслуживать клиентское подключение. Для клиентских подключений Рабочим процессам по умолчанию выделяется диапазон IP портов 1560 – 1591. Кроме этого, каждому Рабочему процессу назначается Служебный порт для обмена с менеджером кластера. Каждый рабочий процесс использует до 2 Gb ОЗУ в 32х разрядной операционной системе. В 64х разрядной операционной системе ограничение накладывается физическим объемом ОЗУ

Кластер 1С 8.2

Кластер серверов 1C:Предприятие 8.2 – дальнейшее развитие технологий сервера 8.2.

Сервер может работать «как 8.1», т.е. в нем осталась совместимость с предыдущими технологиями.

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

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

Менеджер кластера

Менеджер кластера теперь стал сложнее. Часть функций теперь можно выделить в отдельный процесс и даже разместить на другом рабочем сервере кластера. Это позволяет балансировать загруженность сервера.

Отказоусточивость сервера 8.2 достигается за счет:

• Хранение информации о сеансе работы пользователя.
  • Пользователь не привязан больше к рабочему процессу.

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

• Резервирование кластеров.
  • Указывается запасной кластер, при подключении — перечисляются в строке соединения

Это позволяет обеспечить непрерывность работы:

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

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

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

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

Кластер 1С 8.3

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

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

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

Стабильность работы при использовании больших объемов памяти определятся новыми параметрами рабочего сервера.

Особенно интересен параметр «безопасный расход памяти за один вызов». Для тех кто плохо представляет что это такое — лучше не тренируйтесь на «продуктивной» базе. Параметр «Максимальный объем памяти рабочих процессов» позволяет при «переполнении» не обваливать весь рабочий процесс, а только один сеанс «с неудачником». «Объем памяти рабочих процессов, до которого сервер считается производительным» позволяет заблокировать новые соединения как только будет преодолен этот порог памяти.

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

Отдельный вклад в стабильность системы вносит «расходование» лицензий/ключей. В 8.3 появилась возможность использования «менеджера программных лицензий» напоминая менеджер «аладина». Цель — возможность вынести ключ на отдельную машину.

Реализован он в виде еще одного «сервиса» в менеджера кластера. Вы можете использовать к примеру «свободный» ноутбук. Добавьте его в кластер 1с 8.3, создайте на нем отдельный менеджер с сервисом «сервис лицензирования». В ноутбук можно воткнуть аппаратных hasp-ключ, или активировать программные лицензии.

Наибольший интерес для программистов должен представлять «Требования назначения функциональности».

Так на ноутбуке с ключом защиты чтобы не запускать пользователей на сервер кластера надо добавить «требования» для объекта требования «Клиентское соединение с ИБ» — «Не назначать», т.е. запретить рабочим процессам данного сервера обрабатывать клиентские соединения.

Еще больший интерес предоставляет возможность запускать «только фоновые задания» на рабочем сервере кластера без сеансов пользователей. Таким образом можно высоконагруженные задачи (код) вынести на отдельный машины. При чем можно одно фоновое задание «закрытия месяца» через «Значение дополнительного параметра» запускать на одном компьютере, а фоновое задание «Обновление полнотекстового индекса» на другом.Уточнение происходит через указание «Значение дополнительного параметра». Например если указать BackgroundJob.CommonModule в качестве значения, то можно ограничить работу рабочего сервера в кластере только фоновыми заданиями с любым содержимым. Значение BackgroundJob.CommonModule.<Имя модуля>.<Имя метода> — укажет конкретный код.

Решение возможных проблем с установкой

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

В случае выбора существующей учетной записи вы должны указать правильный пароль и подтверждение, иначе запуск серверной части далее приведет к ошибке.
При первом запуске Агента кластера создается кластер «по умолчанию».
Кластер по умолчанию имеет следующие характеристики:
· номер порта – 1541;
· диапазон IP портов – 1560:1591;
· поддержка многих рабочих процессов – выключена;
· один рабочий процесс, номер порта устанавливается из указанного диапазона.
Если при первом запуске агента кластера возникли какие-либо проблемы, то кластер по умолчанию может быть не создан. Это проявляется в том, что при запуске агента сервера (ragent) он стартует, но не запускает другие процессы кластера (rmngr, rphost). Список кластеров srvribrg.lst при этом выглядит так:
{
{0},
В этом случае можно остановить процесс ragent, удалить список кластеров (srvribrg.lst) и запустить ragent снова.

Проверьте совпадение портов, указанного в параметре port командной строки запуска сервиса агента сервера и заданного в диалоге параметров центрального сервера консоли кластеров:

— Остановите сервис 1C:Enterprise 8.1 Server Agent.

Если Агент серверов запущен как приложение, остановка выполняется нажатием комбинации клавиш Ctrl+C.
— Убедитесь, в Диспетчере задач (Task Manager), что все процессы ragent, rmngr, rphost завершились. При необходимости завершите их при помощи Task Manager.

— Откройте свойства сервиса 1C:Enterprise 8.1 Server Agent.

— Обратите внимание на строку «Исполняемый файл» (Path to executable). В ней имеется параметр -d, за которым следует каталог данных кластера. Все файлы, относящиеся к кластеру, находятся в этом каталоге.
— Удалите все содержимое этого каталога.
— Запустите сервис 1C:Enterprise 8.1 Server Agent.
— Убедитесь, в Диспетчере задач (Task Manager), что все процессы ragent, rmngr, rphost стартовали.
— Запустите консоль кластера и зарегистрируйте в ней центральный сервер. Консоль должна подсоединиться к центральному серверу и показать один кластер, созданный по умолчанию.
Возможными проблемы отказа работы Кластера серверов являются проблемы с ключами защиты, правами учетной записи служб, некорректными параметрами запуска.

1. Ключ защиты серверной части устанавливается ЛОКАЛЬНО на каждый сервер предприятия
2. Не задавайте учетную запись службы с пустым паролем
3. При нескольких кластерах используемые порты не должны пересекаться

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

Ошибка 1069: служба не запущена из-за ошибки входа в систему

Проблема связана с правами учетной записи на запуск от имени системной службы. Откройте утилиту Local Security Policy (Локальная политика безопасности) и добавьте пользователя (от имени которого происходит запуск Рабочих серверов Кластера) к политикам Logon as service (Работа в качестве сервиса) и Logon as batch (Работа в качестве пакетного задания) job.
При нарушении данных, хранящихся в служебных файлах, и запуск Рабочих серверов Кластера может оказаться неудачным. Убедитесь, что агент сервера 1С:Предприятия 8.1 запущен (процесс ragent в Task Manager).
Не забудьте, что средством анализа также является аудит событий Windows. Для этого посмотрите, появляются ли какие-нибудь «подозрительные» сообщения в журнале событий Windows.

Ошибка 8007056B / 800708C5

The new password does not meet the password policies. The password may be too short or you have already used this password recently.
Причина: указанный пароль для учетной записи в диалоговом окне «Установка сервера 1С:Предприятие» не удовлетворяет требованиям политики безопасности.
Решение: Задать новый пароль для выбранной учетной записи, удовлетворяющий требованиям политики безопасности либо ослабить требования применяемой политики безопасности, т.е. не требовать «сложного» пароля, не ограничивать количество знаков в пароле, не проверять попыток повторения и т.д.

Ошибка 1923: нет привилегий для установки сервисом

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

Ошибка 80070056

Your password could not be changed. Each password must be used for at least x days.
Причина и Решение: Еще одна ошибка, возникающая при нарушении требований политики безопасности к используемым паролям. Решение аналогично ошибке 800708C5.

Windows Sockets — 11004(0х00002AFC)

1) Убедиться, что на Рабочем сервере кластера в Диспетчере задач (Task Manager) запущены:
Агент сервера (ragent.exe),
Менеджер Кластера (rmngr.exe),
Рабочий процесс Кластера (rphost.exe).
2) Для проверки разрешения имен ip-адреса выполните в командной строке:
ping имя_машины
В отклике системы на команду нас интересует, определиться ли ip-адрес.
3) Если имя определилось, но Рабочий процесс по-прежнему не находится, то убедитесь, что определение Ip-адреса имени <имя машины> и <имя машины>.<имя домена> определяются не по-разному.

(Windows Sockets — 10054(0x00002746).

Удаленный хост принудительно разорвал соединение.
Такое сообщение может быть получено в случае перезагрузки сервера или принудительного удаления Рабочего процесса.
Эта ошибка обычно не появляется при повторном подключении. Если ошибка осталась, необходимо расследовать причины отказа рабочих серверов кластера.
Такая ошибка может происходить при достижении рабочим процессом использования максимального объема памяти в 32х битных системах.
Другим случаем является попытка подключения от клиента с сообщением об ошибке:

(Windows Sockets — 10060(0x0000274C)

Попытка установить соединение была безуспешной, т.к. от другого компьютера за требуемое время не получен нужный отклик, или было разорвано уже установленное соединение из-за неверного отклика уже подключенного компьютера.
Сущность этой ошибки – отсутствие отклика в течении определенного времени (таймаута).
1) Убедитесь, что брандмауэр не блокирует трафик приложения. Выключите брандмауэр.
Для этого в командной строке выполните команду (команда доступна начиная с Windows XP и Windows Server 2003, в более ранних версиях встроенного брандмауэра нет, однако может быть установлено стороннее ПО):
netsh firewall set opmode disable
Если команда будет выполнена успешно, вы получите сообщение:
Ок.
Кроме брандмауэра блокировать трафик могут сетевые фильтры. Они по умолчанию выключены. Тем не менее, убедитесь, что это так:

1. Откройте папку «Сетевые подключения».
2. Щелкните правой кнопкой мыши сетевое подключение, которое требуется настроить, и выберите команду Свойства .
3. На вкладке Общие (для подключения по локальной сети) или на вкладке Сеть (для всех остальных подключений) выберите Протокол Интернета (TCP/IP) и нажмите кнопку Свойства .
4. Нажмите кнопку Дополнительно .
5. Откройте вкладку Параметры , выберите параметр Фильтрация TCP/IP и нажмите кнопку Свойства .
6. Убедитесь, что флажок Задействовать фильтрацию TCP/IP (все адаптеры) снят.

2) Убедитесь, что ресурсы процессора не загружены на 100% (CPU%).
3) Выполните замер сетевой активности интерфейсов клиента и сервера. Нагрузка на сетевой адаптер не должна превышать 60%.

(Windows Sockets — 10061(0x0000274D)

Подключение не установлено, т.к. конечный компьютер отверг запрос на подключение.
Характерной причиной такой ошибки является отсутствие запущенного Агента сервера. Запустите сервер вручную или выполните перезагрузку сервера для автоматического старта.

Ответы на вопросы

Многоплатформенность 1С

Установка сервера

Q:Ошибка установки сервера 1с на MS Server 2008 R2 x64 При установке сервера 1с через командную строку, например такую, ragent.exe -instsrvc -port 2040 -regport 2041 -range 2060:2091 -d «C:\Program Files\1cv82\ (взято с диска ИТС), в командной строке пишет сообшение: «Error! OpenSCManager error!» Сервис при этом не создается. Проверялось на 8.1.15.14 и 8.2.10.77

А: Для установки из коммандной строки на ОС, где присутсвует UAC, нужно пользоваться службой RunAs, т.к. даже если пользователь входит в группу администраторов, то UAC блокирует действия, которые изменяют состояние системы.

Ключи защиты

Q: Ключ защиты от сервера 8.2 позволяет запустить Сервер 8.1?
A: Да, позволяет

Q: чтобы запустить сервер 1С мне нужны хасп-ключи какие-то серверные? Локальный, или на 5 пользователей не пойдет?

A: да, для сервера нужен свой ключ, локальный пользовательский и сетевые не подойдут. Подробнее в « « , слайд № 30.

Q: допустим кластер серверов 1с стоит из 3-х физических серверов. сколько нужно ключей защиты

Q: Имеется терминальный сервер и ключ на 5 лицензий, докупается 6-ая доп. лицензия. Возможно ли ее установить на сервер рядом с ключом на 5? И будут ли все 6 пользователей работать в теминальных сессиях или 5 — под теерминалом, а 1 в файловом варианте?
A: Нет, не будут. 6я лицензия в виде локального ключа должна быть воткнута в компьютер пользователя, но не в терминалку.

Обновления сервера 1С

Q: при выходе новой версии 8.2.xxx платформы какой порядок действий при обновлении серверов и клиентов
A: Дистрибутивы 8.2 инсталируют свои файлы в разные папки (для каждой версии своя папки), т.е. теоретически остается возможность вызова параллельно нескольких версий сервера.

У меня особых проблем не возникало. Однако, надо внимательно отслеживать занимаемые порты экземпляром сервера 1С. Пересечений не должно быть.

Настройка сервера 1С

Q: В 1С 8.1, как лучше размещать информационные базы, если их несколько, в одном кластере или создавать для каждой базы отдельный кластер? A: С большим объем или нагрузкой, а также тестовые базы размещать нужно в отдельные кластера!

Q: ВОПРОС: Рабочй процесс 1С:Предприятие 8.1 является однопоточным приложением или многопоточным? Т.е. может ли загрузить много ядер при одном подключенном пользователе? При нескольких? А рабочий процесс 1С:Предприятие 8.2? Спасибо.
A: 1Сv8.exe и rphost.exe в версии 8.1 отъедали 1 ядро. По сколько в 8.1 соединение клиента находится жестко привязанным к рабочему процессу, то можно условно считать, что обработка клиентов 1С выполняется в рамках одного ядра. Исключение составляет СУБД, которая использует ядра не зависимо, как работает сервера 1С.

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

платформа 8.2 не реализует всех возмжностей многопоточной системы, но она существенно лучше использует возможности железа по сравнению с 8.1, в том числе и в плане параллельности.

Q: Необходимо ли несколько рабочих процессов 1С:Предприятие 8.1, чтобы сервер баз данных (MS SQL) нагружал несколько ядер? (Замечено, что MS SQL обычно «грузит» только одно ядро, т.е. «распараллеливание» обработки одного запроса по нескольким ядрам, как правило, не происходит.) Спасибо.
A: Специально управлять MS SQL не нужно, это достаточно самонастраивающая система, использующая ресурсы по необходимости. Управлять параллельностью исполнения можно:

EXEC sys.sp_configure N’max degree of parallelism’, N’5′
GO
RECONFIGURE WITH OVERRIDE
GO

Создавать несколько рабочих процессов на сервере 1С можно исходя из того, что один рабочий процесс не обеспечивает возможность пользователям сделать повторное подключение в случаи падения рабочего процесса. 2 процесс (на 8.2 его лучше сделать «резервным») решает эту проблему. А вот 3й и более рабочие процессы есть смысл добавлять, только если сильно загруженны (более 90%) первые два рабочих процессах. Без надобности плодить рабочие процессы не стоит, это может ухудшить производительность.

A: Как минимум 1 резервный рабочий процесс в 8.2 должен быть.

Отказоустойчивый кластер

Q: Вопрос про включении резервирования кластеров 1с 8.2. Если у нас упал сервер (уборщица выдернула провод) то сетевое имя, например «server:2540» будет недоступно. как клиент, у которого прописано в строке подключения «server:2540» узнает что нужно подключаться к резервному кластеру? откуда он возмет имя другого сервера? А если через запятую написать кластеры в строке подключения базы?
A: Несколько кластеров объединяются в «группу резервирования». Для этого в оснастке кластера есть «список резервирнования».

При первом обращении клиента к кластеру ему передается список кластеров, входящих в группу резервирования.

Если клиент не разу не обращался, то в этом случаи надо указать вручную адреса всех кластеров, например storm:2541,monster:2541.

Между кластерами резервирования осуществляется обмен синхронизируемых данных.

Q: Что происходит после восстановления работы основного кластера? когда пользователи переключились на резервный.

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

Фоновые задания

Q: Как удалить фоновое задание, запущенное на серверах 1С:8.1 и 1С:8.2?

A: Возможность отмены регламентного задания работает только, если код выполняется в пределах встроенного языка 1С:Предприятия. Если код выполняется во внешних библиотеках, то отменить такое задания нельзя иначе, как принудительно завершив рабочий процесс. Если в процессе блок НачатьТранзакцию() — ЗафиксироватьТранзакцию() то вряд ли. Остальные фоновые задания можно удалить через консоль заданий .

Регламентные процедуры

Q: Возможно ли разрушение базы при проведении ТиИ?

A: Мне такие случаи неизвестны, но имхо возможно все. Поэтому перед ТиИ неплохо бы делать бэкап.

Q: Вячеслав, по каким причинам вы не делаете реиндексацию средствами 1С Тестирование и Исправление?
A: Для этих целей лучше подходят возможности СУБД, так как они посути выполняют тоже перестроение индексов, но не требуют монопольного захвата базы.

Технологический журнал

Q: Добрый день. Вопрос по технологическому журналу: мне необходимо получать копии экранов рабочих станций при ошибках 1С. Нужно ли для этого настраивать технологический журнал и на рабочих станциях, либо же он только для сервера?
A: Можно настроить только получение скриншота при падении платформы, а не при любой ошибки. Впрочем, особой полезности в такой операции не много, вполне достаточно собирать с помощью технологического журнала исключительных ситуаций. При этом, большую часть ошибок можно увидеть с помощюю ТЖ на стороне сервера 1С. Исключение могут составить события вроде «ошибки потока формата», связанной с устаревшим кэшем метаданных.

Неполадки и ошибки

Q: Сталкивались ли вы с проблемой — пропадание настроек отчетов у пользователей при динамическом обновлении конфигураций на платформе 8.2. Есть рекомендации, как с этим бороться?
A: Проблемы связанные с динамическим обновлением отражены в «Сервера 1С:Предпряитие 8.1 и 8.2 — с чем едят «) , слайд №60. Чистить кэш. Возможно в некоторых случаях надо разбираться, где конкретно храняться настройки пользователей. При необходимости хранить в качестве двоичных данных в регистре сведений.

Q: Попутный вопрос, т.к. это актуально для файлового режима: какие ошибки исправляет chdbfl.exe?
A: Это инструмент исправления ошибок структуры хранения данных. Это может быть ситуация когда например возникает «Файл базы данных поврежден …/1Cv8.1CD». Т.е. устраняет повреждения файла базы данных. Однако не выполняет функций ТиИ. Я запускаю chdbfl.exe, если «не продит успешно» ТиИ.

Q: Подскажите пожалуйста сталкнулись с такой проблемой. при нахождении в базе большого количества пользователей (около 40) при проведении больших документов например отражение ЗП в регл. учете около 8000 строк. выдается ошибка нехватает памяти на сервере 1С предприятия и пользователь инициировавший проведение этого документа отваливается. Документ потом можно провести только после перезапуска агента 1С сервера.
A: Похоже на утечки памяти:

1. Рестартовать сервер 1С, увеличить количество рабочих процессов, в кластере держать только одну эту базу.

2. Бить проведение на порции, скажем по 1000 строк за раз. Отследить с помощью ТЖ объекты занимающие память при начале операции, но не освобождающие память по завершению.

3. Поставить х64 версию, увеличить объем оперативки, перейти на 8.2.

Q: Вопрос по тестированию и справлению. Можно ли запускать «Проверка ссылочной целостности» на базе УРБД с отбором по передаваемым данным? (т.е. в некоторых узлах физически отсутствуют объекты, но ссылки на них есть). Спасибо!
A: К сожалению, пока такой возможности нет.

Q: Почему тестирование и исправление сразу не решает все вопросы, приходится запускать несколько раз?

A: Точно ответить могут только разработчики. Я запускаю ТиИ по регламенту (циклически), поэтому для меня этот вопрос не очень актуален. Делать ТиИ надо не один раз, а постоянно как «ТО для автомобиля».

Q: Есть ли разница ТиИ 8.1 и 8.2?

A: На текущий момент написания ответа и релиза 8.2.10 мне разница не известна.

Q: Нужно ли при реструктуризации делать реиндексацию?
A: Не нужно.

Прочее

Q: Уважаемы господа никто не пробовал зеркалировать базы средствами MSSql 2008 вообще это возможно?

Q: Вопрос по принудительному включению shared memory на сервере 1с 8.2

A: Не надо ничего принудительно включать, сервер сам поймет.

Q: Для 1С:Предприятие 8.1 замечены ситуации, когда на одном и том же аппаратном обеспечении файл-серверный вариант с «тяжелыми» операциями и единственным пользователем работает значительно быстрее, чем клиент-серверный, когда все «звенья» (сервер БД, сервер 1С:Предприятие и клиент) установлены на одном сервере. При этом при выполнении этой «тяжелой» операции явно выраженных перегрузок аппаратной части нет (загрузка процессора, памяти, жестких дисков минимальная). То есть аппаратных ресурсов много, а работает медленно. Во что же мы можем «упираться»? Спасибо.
A: Достоинство клиент-серверной архитектуры с точки зрения производительности — возможность ПАРАЛЛЕЛЬНО обрабатывать запросы клиентов к данным. Т.е. скорость потока не тот показатель, по которому стоит делать общие выводы. Механизмы, улучшающие параллельность, все же в рамках одного потока могут несильно снижать производительность.

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

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

Q: О разнице между виндовским терминалом и тонким клиентом 1С.
A: Пока большинство решений не переведы ПОЛНОСТЬЮ под 8.2, говорить о практическом сравнении этих технологий однозначно сложно.

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

Для консервативных прагматичных руководителей проектов, конвертирующих 8.1 под 8.2- терминальное решение. Для небольших проектов с низкой стоимостью ошибок и конфигурацией сразу реализованной с управляемыми формами и СКД — тонкий клиент предпочтительней ИМХО.

Q: А как провести нагрузочное тестирование приближённое к реальным условиям? Ведь не загонишь пользователей «пощёлкать что-то».

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

В большинстве случаев для установки 1C:Предприятия 8.х в варианте “клиент-сервер” достаточно запуска программы установки 1С:Предприятия 8.х. При этом сервер 1С:Предприятия получает стандартные значения параметров, необходимые для его нормального функционирования.

Рассмотрим установку сервера 1С:Предприятия более детально. В процессе установки сервера 1С:Предприятия 8.х программа установки 1С:Предприятия 8.х выполняет следующие действия:

* Копирует загрузочные модули сервера 1С:Предприятия в каталог, указанный программе установки 1С:Предприятия в качестве конечной папки.
* Если в процессе установки выбрано "Создать пользователя USR1CV81", то создает пользователя USR1CV81. От имени этого пользователя работает сервер 1С:Предприятия 8.1, если он запускается как сервис. Ему доступны только те ресурсы, которые необходимы серверу 1С:Предприятия. Важно, что серверу 1С:Предприятия для работы необходимы два каталога: общий каталог с данными сервера (обычно "C:\Program Files\1cv81\server") и каталог временных файлов (обычно "C:\Documents and Settings\usr1cv81\Local Settings\Temp" или "C:\WINNT\Temp"). Пользователь USR1CV81 получает права на общий каталог с данными сервера. Каталог временных файлов обычно доступен всем пользователям.
* Если в процессе установки включено "Установить сервер 1С:Предприятия 8.1 как сервис Windows", то регистрирует в Windows сервис агента сервера 1С:Предприятия и запускает его. При первом запуске создается кластер серверов 1С:Предприятия с настройками по умолчанию. В нем один рабочий сервер и один рабочий процесс. Адрес рабочего сервера совпадает с именем компьютера, на котором выполнена установка.

Пользователь USR1CV81 или USR1CV82 и его права

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

Рассмотрим подробнее права, устанавливаемые пользователю USR1CV81. Сервер 1С:Предприятия использует следующие каталоги:

* Каталог загрузочных модулей находится в каталоге, заданном программе установки 1С:Предприятия в качестве конечной папки. В нем расположены загрузочные модули сервера 1С:Предприятия. Пользователь USR1CV81 необходимы права на чтение данных и запуск программ из этого каталога и его подкаталогов. Он получает эти права неявно, благодаря включению в группу Users.
* Каталог данных сервера обычно имеет имя "C:\Program Files\1cv81\server". Пользователю USR1CV81 необходимы полные права на этот каталог. Программа установки 1С:Предприятия при создании пользователя USR1CV81 наделяет его правами на этот каталог.
* Каталог временных файлов обычно имеет имя "C:\Documents and Settings\usr1cv81\Local Settings\Temp" или "C:\WINNT\Temp", которое определяется значением переменной TEMP окружения пользователя или переменной TEMP системного окружения. Посмотреть значение этой переменной можно в диалоге System Properties (Start -> Settings -> Control Panel -> System -> Advanced -> Environment Variables). Программа установки 1С:Предприятия задает пользователю USR1CV81 полные права на этот каталог. Обычно при установки Windows каталог временных файлов доступен всем пользователям посредством включения в его список доступа группы CREATOR OWNER. Однако, это доступ не полный. В частности, всем пользователям не доступна операция поиска файлов в этом каталоге. Установка пользователю USR1CV81 полных прав на каталог временных файлов позволяет серверу 1С:Предприятия выполнять все необходимые ему операции. Посмотреть список доступа можно в диалоге свойств каталога на закладке Security. Наличие группы CREATOR OWNER позволяет обращаться к каталогу любому пользователю, создающему какие-нибудь файлы в этом каталоге или владеющему какими-нибудь файлами в этом каталоге. При этом в списке доступа созданного файла вместо группы CREATOR OWNER будет записан пользователь, создавший файл. Среди пользователей, которым разрешен доступ в этот каталог, должен быть и пользователь USR1CV81, наделенный полными правами на этот каталог.
Важно иметь в виду, что каталог временных файлов определенного пользователя (в том числе и пользователя USR1CV81) определяется комбинацией переменных окружения этого пользователя и системных переменных окружения. Чтобы узнать этот каталог, программа установки 1С:Предприятия запрашивает контекст пользователя USR1CV81. В для этого в Windows 2000 пользователю, от имени которого запускается программа установки 1С:Предприятия, могут потребоваться привилегии: Act as part of the operating system и Bypass traverse checking. Проверить привилегии пользователя можно утилитой Local Sequrity Settings в ветке Local Policies -> User Rights Assignment. В процессе установки нового программного обеспечения программа установки обычно получает эти привилегии автоматически.

Регистрация сервера 1С:Предприятия как сервиса Windows

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

Для просмотра списка сервисов Windows и их параметров предназначена утилита Component Services (Start -> Settings -> Control Panel -> Administrative Tools -> Services). Сервер 1С:Предприятия представлен в списке сервисов сервисом "Агент сервера 1С:Предприятия 8.1". Параметры сервиса определяют запуск процесса "Агент сервера 1С:Предприятия" (ragent), пользователя, от имени которого он запускается, а также способ перезапуска в аварийных ситуациях.

В диалоге свойств сервиса "Агент сервера 1С:Предприятия 8.1" на закладке General показана строка запуска процесса ragent, который является Агентом сервера 1С:Предприятия. Обычно эта строка имеет вид:


В ней указано, что:

* процессом Агента сервера является загрузочный модуль "C:\Program Files\1cv81\bin\ragent.exe";
* процесс ragent запускается как сервис Windows и должен управляться менеджером сервисов (-srvc);
* используется как Агент сервера 1С:Предприятия (-agent);
* при первом запуске сервиса должен быть создан кластер с параметрами по умолчанию и главным IP-портом номер 1541 (-regport 1541). По этому порту клиентские приложения должны соединяться с информационными базами, зарегистрированными в кластере;
* IP-порт агента сервера должен иметь номер 1540 (-port 1540). По этому порту Консоль кластера должна соединяться с центральным сервером для выполнения административных функций;
* при запуске процессов кластера на данном сервере им будут динамически назначаться IP-порты из диапазона 1560-1591 (-range 1560:1591).
* общие данные кластера будут размещены в каталоге "C:\Program Files\1cv81\server" (-d "C:\Program Files\1cv81\server").

Сервис "Агент сервера 1С:Предприятия 8.1" может быть добавлен или удален не только при установке или удалении 1С:Предприятия программой установки 1С:Предприятия 8.1, но и вручную. Для этого можно исполнить из командной строки утилиту ragent, указав ей соответствующие параметры.

Для создания сервиса нужно указать параметр -instsrvc и параметры: -usr - имя пользователя, от имени которого должен быть запущен сервис, -pwd - пароль этого пользователя. При этом остальные параметры станут параметрами строки запуска Агента сервера 1С:Предприятия как сервиса. Например, для стандартной регистрации сервиса Агента сервера 1С:Предприятия в отладочном режиме набор параметров должен быть таким:

"C:\Program Files\1cv81\bin\ragent.exe" -instsrvc -usr .\USR1CV81 -pwd Password -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv81\server" -debug

Для удаления сервиса нужно указать параметр -rmsrvc. Например:
"C:\Program Files\1cv81\bin\ragent.exe" -rmsrvc

Иногда бывает полено изменить строку запуска Агента сервера или другие параметры сервиса Агента, например, включить режим отладки, или создать несколько сервисов разных версий. Диалог свойств сервиса не позволяет редактировать строку запуска сервисного приложения и некоторые другие параметры, например, идентификатор сервиса. Для редактирования потребуется утилита regedit, предназначенная для просмотра и редактирования системного реестра Windows.

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

Запустите утилиту regedit (откройте Start -> Run и наберите regedit) и выберите ветку:


Среди ее параметров есть параметр ImagePath, значением которой является строка запуска Агента сервера 1С:Предприятия. Здесь можно добавить новые параметры строки запуска или поменять значения существующих. Полный список возможных параметров приведен в книге "1С:Предприятие 8.1 Клиент-сервер" документации.

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

* Создать первый сервис:
"C:\Program Files\1cv81\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv81\server"

* При помощи утилиты regedit изменить идентификатор зарегистрированного сервиса. Для этого: выбрать ветку
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.1 Server Agent

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.1 Server Agent First
* Создать второй сервис:
"C:\Program Files\1cv81_10\bin\ragent.exe" -srvc -agent -regport 1641 -port 1640 -range 1660:1691 -d "C:\Program Files\1cv81_10\server"

* Быть может, его идентификатор тоже изменить. Для этого: выбрать ветку
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.1 Server Agent
и изменить ее имя, например на:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.1 Server Agent Second

Что не может сделать программа установки 1С:Предприятия?

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

Чтобы сервер 1С:Предприятия был доступен с других компьютеров в локальной сети, необходимо проверить сетевые настройки на серверном и клиентском компьютере, а также для сети в целом. Для передачи данных между клиентскими приложениями и сервером 1С:Предприятия, а также между процессами кластера серверов используется TCP/IP. От правильности его настройки зависит работа 1С:Предприятия в варианте клиент-сервер.

Процессы кластера серверов 1С:Предприятия соединяются друг с другом по адресам, определенным в качестве значений свойства "Компьютер" диалога свойств рабочих серверов. Для кластера необходимо, чтобы значением свойства "Компьютер" был либо IP-адрес в точечной нотации, либо такой символический адрес, по которому может быть определен IP адрес при помощи функции gethostbyname, определенной в программном интерфейсе протокола TCP. Определение IP-адреса выполняется либо на основании локальной таблицы символических адресов (C:\WINNT\system32\drivers\etc\hosts), либо по таблицам адресов в доступных DNS серверах. Если по символическому адресу рабочего сервера его IP-адрес не определяется или определяется неправильно (например, IP-адрес не совпадает с фактическим IP-адресом данного компьютера), то кластер работать не будет. Важно, чтобы имена компьютеров и их адреса, определенные в Windows на каждом из рабочих серверов кластера, не противоречили их именам в DNS.

На каждом рабочем сервере процессы кластера используют следующие порты: IP порт рабочего сервера (обычно 1540); IP порты из диапазонов IP портов рабочего процесса (обычно 1560-1591). Кроме того, на центральном сервере кластера используется порт кластера (обычно 1541). Если в системе используются сетевые экраны, то передача данных по этим портам должна быть разрешена. Вместо разрешения портов из приведенного списка можно разрешить передачу данных процессам кластера (ragent, rmngr, rphost).

Соединение клиентского приложения 1С:Предприятия с сервером выполняется в 2 этапа. Сначала оно устанавливает соединение с менеджером кластера. При этом используется адрес центрального сервера (символический или числовой) и порт кластера (обычно 1541). Далее клиентское приложение устанавливает соединение с одним из рабочих процессов. В качестве его адреса используется значение свойства "Компьютер" соответствующего рабочего сервера и порт рабочего процесса, который выбирается из диапазона IP портов рабочего сервера. Передача данных на эти порты должна быть разрешена во всех сетевых экранах на маршруте от компьютера клиентского приложения до компьютеров кластера серверов 1С:Предприятия. Определение IP адреса серверных процессов выполняется при помощи функции gethostbyname на компьютере клиента. Важно, чтобы имена центрального и рабочих серверов и их адреса, определенные в Windows на каждом из серверов кластера, не противоречили их именам в DNS, доступном компьютеру клиента.

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

Особенности настройки SQL-сервера

1С:Предприятие в варианте «клиент-сервер» использует для хранения данных SQL-сервер. При этом к SQL-серверу обращается только Сервер 1С:Предприятия. Клиенты 1С:Предприятия непосредственного доступа к SQL-серверу не имеют. Установка и настройка SQL-сервера подробно описана в документации по Microsoft SQL Server. Для успешной работы Сервера 1С:Предприятия с SQL-сервером необходимо обратить особое внимание на следующие настройки.

* Необходимые компоненты SQL-сервера. Для доступа к SQL-серверу со стороны Сервера 1С:Предприятия на компьютере Сервера 1С:Предприятия должны быть установлены компоненты Microsoft Data Access 2.6 или более поздний.
* Аутентификация пользователя SQL-сервером. Права доступа к базам данных SQL-сервера определяются пользователем, от имени которого происходит обращение к базам данных. С компьютера, на котором установлен SQL-сервер, запустим утилиту SQL Server Enterprise Manager, найдем узел Local (Console Root -> Microsoft SQL Servers -> SQL Server Group -> (Local)) и откроем его свойства. На закладке Sequrity можно видеть, что SQL-сервер поддерживает два способа аутентификации пользователей: SQL Server and Windows и Windows only. Аутентификация Windows позволит Серверу 1С:Предприятия обращаться к SQL-серверу только от имени пользователя USR1CV81, что не позволяет различать права доступа до различных информационных баз, обслуживаемых одним сервером 1С:Предприятия. Рекомендуется выбирать режим SQL Server and Windows. В этом случае обращение к конкретной информационной базе будет выполняться от имени пользователя, который задан в качестве пользователя SQL-сервера при создании данной информационной базы. Важно, что этот пользователь должен иметь не только полные права на базу данных информационной базы, но и права на создание баз данных в SQL-сервере и на чтение таблиц базы данных Master.
* Сетевые протоколы для доступа к SQL-серверу. Если Сервер 1С:Предприятия и SQL-сервер размещены на разных компьютерах, то необходимо выполнить настройки сетевых протоколов доступа к SQL-серверу. Это можно сделать при помощи утилиты SQL Server Client Network Utility. На закладке General можно выбрать список сетевых протоколов, используемых для доступа к SQL-серверу. Наиболее быстрым и универсальным является использование протокола TCP/IP. При использовании других протоколов необходимо иметь в виду, что некоторые из них, например Named Pipes, выполняют дополнительную аутентификацию средствами Windows при обмене данными с SQL-сервером. В этом случае для успешной работы с SQL-сервером на компьютере с SQL-сервером должен быть зарегистрирован пользователь USR1CV81, наделенный соответствующими правами. Протокол доступа к данному SQL-серверу может быть изменен на закладке Alias.

В дополнение к статье

Нет сомнения, что связка MS SQL Server + сервер "1С: Предприятие 8" - в своей нише самая востребованная и часто применяемая связка. Для её качественной поддержки желательно понимание обоих продуктов. В то же время, на практике, специалист поддержки обычно либо специализируется на администрировании MS SQL Server и не ориентируется в особенностях сервера "1С: Предприятие 8", либо, наоборот, специализируется на администрировании сервера "1С: Предприятие 8" и не ориентируется в особенностях MS SQL Server.

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

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

Трёхзвенная схема

Как, возможно, уже известно читателю, база данных в рассматриваемом случае имеет трёхзвенную архитектуру:

Звено 1: СУБД MS SQL Server. "Хранит" и обслуживает базу данных, в конечном счёте выполняет все виды операций с базой данных. Таким образом, производительность работы базы данных, скорость и параллельность чтения-записи данных – во многом определяются производительностью MS SQL Server.

Звено 2: Сервер "1С: Предприятие 8". Служит посредником во взаимодействии между клиентами (пользователями) и MS SQL Server. Все клиентские запросы направляются на сервер, который "переводит" их на язык запросов MS SQL Server, получает результаты выполнения этих запросов, отправляет результаты клиенту.

Есть лишь малая часть операций, которые выполняются на уровне сервера "1С: Предприятие 8", без обращения к MS SQL - это, в частности, отслеживание так называемых "управляемых блокировок", чтение-запись "параметров сеанса". Обращения к СУБД в таких случаях не требуется, так как эти операции производятся не с данными базы, а со вспомогательной информацией сервера.

Звено 3: Клиентская часть "1С: Предприятие 8". Обращается к серверу "1С: Предприятие 8", получает от него результаты (то есть, например, выборки данных), отвечает за пользовательский интерфейс.

"Хотел как лучше".

После переустановки сервера "1С: Предприятие 8" пользователи жалуются на резкое падение производительности. Специалист по внедрению ПП "1С: Предприятие", производивший переустановку – лишь удивляется – мол, хотел как лучше, система должна была начать работать быстрее... Анализ ситуации показал, что серверу "1С: предприятие 8" была выделено слишком много ресурсов: его процессы (см. пункт 3) rphost заняли 15.5 Гб из 16Гб оперативной памяти сервера, в результате для уступчивого MS SQL Server практически не осталось доступной оперативной памяти.

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

Совместимость продуктов

Актуальные данные о версиях MS SQL Server, рекомендуемых к использованию в связке с "1С: Предприятие 8", следует выяснять по ссылке http://v8.1c.ru/requirements/ .

На момент подготовки статьи разработчики фирмы "1С" рекомендуют следующие варианты:

1. SQL Server 2008 R2.

2. SQL Server 2008, требуется установка пакета обновлений 1 (SP1).

3. SQL Server 2005, требуется установка пакета обновлений 3 (SP3).

Технически возможно, но не рекомендуется применение MS SQL Server 2000, для него требуется установка пакета обновлений 2 (SP2), и желательна установка пакета обновлений 4 (SP4).

Следует учитывать, что в настоящий момент эта версия снята с поддержки, а также не имеет 64-разрядной версии для архитектуры x86-64.

Обратите внимание:

Необходимо обращать внимание на настройки операционной системы: например, для эффективной работы M SQL Server 2008 под ОС Server 2008R2 требуется отключение сбалансированного режима энергоснабжения и перевод в режим максимальной производительности.

Установка клиент-серверной версии "1С: Предприятие 8"

"1C установил"

У одного из заказчиков установку "1С: Предприятия 8" произвёл системный администратор, не имеющий опыта в работе с "1С:Предприятием 8". И хотя, по его словам, он "установил 1С" - на пользовательских компьютерах отсутствовала клиентская часть, а на сервере - серверная. Разбор ситуации прояснил картину – в комплекте "1С: Предприятия 8" имелось 2 диска – установка платформы и установка шаблонов баз данных. Администратор не стал вникать в порядок установки – и установил шаблоны баз данных, а не исполняемые файлы, компоненты платформы.

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

При установке "1С: Предприятия 8" следует учитывать, что отдельно устанавливаются:

Платформа "1С: Предприятие 8" - исполняемое приложение, интегрированная среда разработки и эксплуатации баз данных. При его запуске выбирается один из двух режимов работы – "Предприятие" (пользовательская оболочка баз данных) либо "Конфигуратор" (интегрированная среда разработки). Более полное описание можно прочитать по ссылке

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

При установке платформы следует уделить внимание выбору компонент:

Компонента "1С: Предприятие" может не устанавливаться на сервере (серверах).

В этом случае сервер будет предоставлять клиентским компьютерам доступ к базам данных "1С: Предприятие", но работа с БД в пользовательском режиме непосредственно с сервера будет невозможна.

Обратите внимание:

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

Компонента "Сервер 1C: Предприятия" нужна для подключения к MS SQL Server - это сервер приложений, связующее звено между платформой на клиентских рабочих местах и MS SQL Server.

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

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




После загрузки компонента порождает несколько процессов, как то: "агент сервера", "менеджер кластера серверов", "рабочие процессы сервера".

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

Рабочими процессами сервера можно будет управлять (добавлять, удалять, ставить ограничение на использование ОЗУ, объявлять основным или резервным), если будет установлена компонента "Администрирование сервера 1С: Предприятия".



Обратите внимание:

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

Для 64-битной версии сервера теоретически достаточно двух рабочих процессов – одного рабочего и одного резервного. Однако на практике для обеспечения надёжности и стабильности подключений на существенном (несколько сотен) количестве пользователей требуется большее количество, оно зависит многих факторов - от количества пользователей, наполнения базы данных и объёма выполняемых запросов, поэтому авторы считают, что количество процессов в этом случае следует подбирать экспериментально.

"Уроборос"

После неудачной оптимизации настроек сервера "1С: Предприятие 8" пользователи просигнализировали о крайне медленной работе системы, а системный администратор отметил постоянную 100% загрузку процессора на сервере.

Анализ ситуации показал источник проблемы - при настройке было установлено слишком маленькое ограничение на использование оперативной памяти рабочими процессами.

А дело в том, что данное ограничение работает следующим образом:

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

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

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

В случае, если количество подключаемых пользователей невелико (менее 50) – сервер приложений обычно устанавливают на том же компьютере, где работает MS SQL Server.

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

Компонента "Администрирование сервера 1С: Предприятия" может быть полезной и на клиентах – например, с её помощью можно увидеть список информационных баз, подключённых к заданному серверу "1С: Предприятия".

На самом сервере её настоятельно рекомендуется установить.

Доступ

Обратите внимание:

Для проверки того, что доступ обеспечен, недостаточно использования утилиты администрирования серверов 1C: Предприятия, и тем более недостаточно присутствия сервера в "Сетевом окружении"!

Необходимо на каждом клиенте выполнить вход в базу данных, установленную на сервере – только это даст 100% уверенность, что доступ обеспечен.

1. В зависимости от политик безопасности, для MS SQL Server применяется аутентификация по учетной записи Windows либо аутентификация по учётной записи MS SQL Server.




В последнем случае при создании базы данных "1С: Предприятия" система будет запрашивать логин и пароль учётной записи MS SQL Server (например, sa), в первом случае логин и пароль следует оставлять пустыми:



и тому пользователю системы, от имени которого запущен сервер 1С: Предприятия, необходимо дать права в MS SQL Server, а именно:

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

доступ к базе данных master (роль public)

рекомендуется – права на создание базы данных, в противном случае каждую новую базу данных нужно будет сначала создавать средствами MS SQL Sever, а уже затем подключать к серверу 1С: Предприятия

рекомендуется - право на удаление своей базы данных

Например, можно назначить рассматриваемому пользователю предопределённую роль processadmin или sysadmin.

Совет.

Если у всех пользователей одновременно пропал доступ к рабочей базе данных – нужно перепроверить права и роли пользователя в MS SQL Server, в том числе установленные для конкретной базы данных, то есть User mapping:




2. Сервер 1С: Предприятия обращается к MS SQL Server через механизм Microsoft Data Access, поэтому его компоненты должны быть установлены, а у пользователя сервера 1С: Предприятия (см. предыдущий пункт) должны быть права на их запуск.

3. Связь между клиентами и сервером поддерживается по протоколу TCP, поэтому необходимо, чтобы этот протокол поддерживался обеими сторонами. Возможны проблемы с сопоставлением имени сервера и его IP адреса, например, если используется одноранговая сеть. В таком случае следует записать соответствие в файле [С:\WINDOWS\] system32\drivers\etc\hosts .

Совет.

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

4. В случае использования протокола Named Pipes, и если MS SQL Server и сервер 1С: Предприятия установлены на разных компьютерах – пользователь, от имени которого работает сервер 1С: Предприятия, должен быть зарегистрирован в списке пользователей компьютера, на котором запущен MS SQL Server.

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

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

7. Релиз платформы "1С: Предприятия 8" должен быть абсолютно одинаковым на клиенте и на сервере.

"Близнецы"

"У одного из заказчиков применялось два сервера баз данных, на каждом из которых располагалась одна рабочая база. Пользователи работали - каждый одновременно с обеими базами. Службы поддержки выполнила обновление платформы "1С: Предприятия 8" на серверах и клиентах…. И тут посыпались жалобы на невозможность подключения – то к одной, то к другой базе. Анализ ситуации показал – обновление на клиентах и серверах делали несколько человек, и устанавливающие специалисты не перепроверяли, что устанавливают один и тот же релиз. Поэтому на одном сервере был один релиз платформы, на втором – другой, на половине клиентов – первый из этих релизов, на другой половине – другой. Получилось, что каждый пользователь имеет доступ только к одной из баз данных.

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

Первоначальные настройки MS SQL Server и базы данных

“И так работает”

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

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

И, конечно, именно в этот момент обнаружится, что база при таком пересчете "зависает", или "вылетает", или не даёт работать остальным пользователям.

Этот своего рода "закон Мэрфи" касается каждого из нижеперечисленных пунктов.

Перед началом использования MS SQL Server в качестве СУБД для "1С: Предприятие" рекомендуется:

1. Установить значение параметра max degree of parallelism равным 1.

То есть:

после подсоединения к серверу войти в свойства сервера через контекстное меню, пункт Properties

далее выбрать страницу Advanced и отредактировать параметр max degree of parallelism

В противном случае некоторые запросы, формируемые сервером 1С: Предприятия, могут вызвать ошибку "Intra-query parallelism caused your server command (process ID #XX) to deadlock. Rerun the query without intra-query parallelism by using the query hint option (maxdop 1)". После этой ошибки клиентская часть зачастую аварийно завершается.

Ошибка не будет проявляться стабильно, так как план запроса формируется по-разному в зависимости от накопленных статистик – она проявит себя на объёмных и сложных запросах, то есть в самый неудачный момент.

2. Создать План обслуживания (Maintance Plan), еженочно обрезающий (shrink) базу данных временных таблиц tempdb. Автоматически база временных таблиц сервером 1С: Предприятия очищается не всегда, а иногда, в результате неудачно написанного запроса, может быть сформирована и не очищена временная таблица размером, например, 50 Гб. Вследствие этого может закончиться место на диске, вследствие этого возможно аварийное завершение и клиентской, и серверной части, также присутствует небольшой риск нарушения целостности данных.

То есть нужно:

зайти в MS SQL Management Studio

после подсоединения к серверу раскрыть раздел "Maintance plans"

создать новый (или дополнить имеющийся) План обслуживания,

добавить в него пункт "Execute T-SQL Statement task" (так как в задании "Shrink database" нельзя выбрать базу tempdb) с кодом

1.USE
2.
3.GO
4.
5.DBCC SHRINKFILE (N"tempdev" , 0, TRUNCATEONLY)
6.
7.GO
8.
9.DBCC SHRINKFILE (N"templog" , 0, TRUNCATEONLY)
10.
11.GO

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

1.USE tempdb
2.
3.GO
4.
5.EXEC sp_helpfile
6.
7.GO




“Горшочек, не вари”

Самый часто встречающийся на практике способ переполнить tempdb и тем самым "уронить" сервер – это забыть указать условие при соединении таблиц.

А именно, допустим, у нас в базе есть две таблицы, размером по 20 тысяч записей каждая. Допустим, между их записями можно установить однозначное соответствие, и мы пишем запрос, создающий временную таблицу, которая содержит 20 тысяч записей с полями обеих исходных таблиц. Но если мы забудем указать условие соединения – каждая запись первой таблицы соединится с каждой записью второй! То есть получится результирующая таблица из 20’000* 20’000=400 млн. записей. И так далее.

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

Нужный путь для хранения файлов рабочей базы лучше задать при её создании, отредактировав колонку Path (Путь):




Для изменения физического расположения файлов базы временных таблиц используется команда ALTER DATABASE, то есть в MS SQL Management Studio нужно выполнить следующий скрипт (команда "New query")

1.USE master
2.
3.GO
4.
5.ALTER DATABASE tempdb
6.
7.MODIFY FILE (NAME = tempdev, FILENAME = "Новый_Диск:\Новый_Каталог\tempdb.mdf")
8.
9.GO
10.
11.ALTER DATABASE tempdb

12.
13.MODIFY FILE (NAME = templog, FILENAME = "Новый_Диск:\Новый_Каталог\templog.ldf")
14.
15.GO

4. Не следует затруднять "рост" рабочей базы данных и её лога – ограничения на размер быть не должно, свойство "Autogrowth" должно быть установлено в процентах, рекомендуемое значение 10%. В противном случае добавление данных в базу, восстановление из архива и другие операции могут выполняться неоправданно долго.

Для установки этого свойства нужно через контекстное меню зайти в свойства базы, выбрать раздел Files, открыть редактирование свойств файла:



5. Рекомендуется включить в MS SQL Server поддержку сетевого протокола TCP/IP и выключить все остальные, в противном случае совместная работа MS SQL Server и сервера 1С: Предприятия будет менее стабильной.




6. Там же - очистить раздел Alias, т.к. её установка приводит к ошибкам взаимодействия MS SQL Server и сервера 1С: Предприятия.

Перед началом эксплуатации базы данных рекомендуется:

1. При создании базы данных из "1С: Предприятия" установить "смещение дат" 2000, в противном попытка записи даты ранее 01.01.1753 (что возможно в силу человеческого фактора) - будет вызывать сбои в работе базы данных.

Внимание! Смещение дат нельзя будет поменять у существующей базы данных!



2. Установить Режим восстановления (Recovery model) в значение Простой (Simple), либо создать План обслуживания (Maintance Plan), который будет ежедневно создавать резервную копию (backup) базы данных и обрезать журнал транзакций (log-файл). В противном случае при некоторых операциях журнал транзакций (log-файл) будет очень быстро расти: например, при реструктуризации базы данных рост размера log-файла может в несколько раз превысить размер самой базы данных.




3. Создать План обслуживания (Maintance Plan), выполняющий следующие регламентные задания как минимум раз в неделю:

Создание резервной копии (backup) базы данных.

Обновление статистик базы данных и очистка процедурного кэша (следует отметить, что свойство autoupdate statistics не подразумевает очистку процедурного кэша).

Очистка процедурного КЭШа – не входит в стандартные операции Планов обслуживания, этот шаг нужно определять как выполнение скрипта (Execute T-SQL Statement) со следующим содержимым:

DBCC FREEPROCCACHE

Реиндексация таблиц базы данных.

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




Заключение

Рассмотрены вопросы, которые чаще всего вызывают затруднения у системных администраторов и внедренцев "1С: Предприятие 8", в связи с совместным использованием MS SQL Server и клиент-серверной версии "1С: Предприятие 8".

Автор надеется, что достаточно последовательно и доступно осветил "обе стороны медали".

P.S. Чаще делайте бэкапы!

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

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

Основные возможности кластера серверов

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

Общая схема клиент-серверного варианта работы

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

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

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

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

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

Состав простейшего кластера серверов

Простейший кластер серверов может располагаться на одном компьютере и содержать один рабочий процесс:

На рисунке представлены все элементы, которые задействованы в работе кластера серверов, а именно:

• процессы кластера серверов:
  • ragent.exe ;
  • rmngr.exe ;
  • rphost.exe ;
• хранилища данных:
  • список кластеров;
  • реестр кластера.

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

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

Непосредственно кластер серверов включает в себя следующие элементы:

• один или несколько процессов rmngr.exe ;
• реестр кластера ;
• один или несколько процессов rphost.exe .

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

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

Масштабируемость

Масштабируемость кластера серверов может осуществляться несколькими способами:

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

Использование нескольких менеджеров

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

Часть сервисов может использоваться только на главном менеджере кластера:

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

Остальные сервисы могут быть назначены произвольным менеджерам кластера:

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

Использование нескольких рабочих процессов

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

Использование нескольких рабочих серверов

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

Отказоустойчивость

Отказоустойчивость работы кластера обеспечивается в трех направлениях:

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

Резервирование кластера

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

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

Резервирование рабочих процессов

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

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

Устойчивость к обрыву канала связи

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

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

Сеансы

Сеанс определяет активного пользователя информационной базы и поток управления этого пользователя. Существуют следующие виды сеансов:

• Толстый клиент , Тонкий клиент , Веб-клиент - создаются при обращении, соответственно, толстого, тонкого и веб-клиента к информационной базе,
• Конфигуратор - создается при обращении конфигуратора к информационной базе,
• COM-соединение - создается при обращении к информационной базе через внешнее соединение,
• WS-соединение - создается при обращении веб-сервера к информационной базе в результате обращения к Web-сервису, опубликованному на веб-сервере,
• Фоновое задание - создается при обращении рабочего процесса кластера к информационной базе. Предназначен для выполнения кода процедуры фонового задания,
• Консоль кластера - создается при обращении утилиты администрирования клиент-серверного варианта к рабочему процессу,
• COM-администратор - создается при обращении к рабочему процессу через внешнее соединение.

Работа под управлением различных операционных систем

Все процессы кластера серверов способны функционировать как под управлением операционной системы Windows, так и под управлением операционной системы Linux. Благодаря тому, что взаимодействие процессов между собой осуществляется по протоколу TCP/IP, в составе одного кластера могут присутствовать рабочие серверы с различными операционными системами.

Утилита администрирования кластера серверов

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

Работа с Андроидом