Кластер серверов 1с предприятия что указывать

Обновлено: 07.07.2024

Релиз версии 1С: Предприятие 8.3 был анонсирован в 2012 году. Вместо резервного кластера ( как в версии 8.2 ) сделали один кластер, но внутри кластера можно указывать различные параметры, т.е. значительно упростили настройку отказоустойчивости.

В этой версии был существенно переписан весь код самой платформы.

Перед тем, как рассмотреть настройки, отмечу ключевые параметры запуска ragent :

–range – Порты рабочих процессов
–d – Директория, где живет сервер (было рассмотрено в предыдущей статье)
–debug – Флаг отладки на сервере

Строку запуска ragent можно посмотреть в службе, а настроить параметры в редакторе регистра: «HKLM -> SYSTEM -> Current Control Set - > Services». Строку запуска ragent можно посмотреть в службе, а настроить параметры в редакторе регистра: «HKLM -> SYSTEM -> Current Control Set - > Services».

Файлы и каталоги сервера 1С

Общий каталог сервера (C:\Program Files\1cv8\srvinfo\)
lst – файл настроек кластера
lst – файл со списком баз
Каталоги баз:1Cv8FTxt – файлы полнотекстового поиска
1Cv8Log – файлы журналов регистрации
Snccntx – сеансовые данные.

Поместить во временное хранилище помещает данные в сеансовые данные (snccntx на диске), при этом часть данных может кэшироваться в оперативной памяти.

Основные настройки кластера 1С: 8.3

Защищенное соединение:

Шифрует данные между клиентом и сервером 1С.

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

Рекомендуется оставлять «выключено», тогда будет шифроваться пароль только при первом соединении(!). Не влияет на шифрование данных между 1С и СУБД.

Интервал перезапуска:

Автоматически перезапускает рабочие процессы (rphost). Начало отсчета интервала перезапуска = момент нажатия на кнопку «ОК», поэтому ставите интервал 1 раз в сутки (86 400 с.), то ставьте ночью.

Перезапуск процесса (выключение старого и включение нового) разделен на этапы:

Процесс помечается как выключенный, теперь на него не назначаются новые сеансы.
Создается новый процесс, на который перекидываются все сеансы с выключенного.
Если за интервал времени « проблемные процессы завершать через » (например, 1 минута) остались висеть сеансы, то они обрываются принудительно, а процесс убивается (клиент получит ошибку).

Имеет смысл только для 32 разрядных систем, т.к. там есть фрагментация памяти (рассматривается на занятии 01-01. Знакомство с 1С ). Для 64 полезно использовать только тогда, когда есть утечки памяти, и проблема пока не решается.

Уровень отказоустойчивости (УО):

Имеет смысл только если в кластере более 1 сервера. Максимальный уровень отказоустойчивости - это количество серверов в кластере минус 1, т.е. если в кластере 1 сервер, то уровень отказоустойчивости = 0. Если же их 3, то есть возможность задать значение УО равным от 0 до 2.

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

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

Инструкция по настройке рабочих серверов с Технологической Платформой 1С:Предприятие

Ниже приводится инструкция по настройке рабочих серверов с Технологической Платформой 1С:Предприятие.

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

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

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

Существует несколько вариантов развертывания:

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

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

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

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

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

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

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

В тестовой зоне и зоне разработки ограничений по числу информационных баз в кластере условно нет.

2. Определить, сколько пользователей будет работать одновременно

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

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

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

3. Настроить профили пользователей ОС, от которых будут запускаться процессы кластера

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

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

Для этого нужно:

Для того, чтобы создать профили пользователей ОС достаточно один раз войти от их имени в ОС Windows.

4. Настроить логирование и дампы

Для этого необходимо настроить:

Технологический журнал
Сбор дампов процессов кластера средствами Платформы (указнием в logcfg.xml секции dump) либо Windows Error Reporting Services

Хорошей практикой будет настроить сбор WER для rmngr и ragent, но не указывать rphost.

5. Проверить настройки операционной системы

5.1. Настроить рабочий сервер

5.2. Настроить рабочий сервер

Необходимо настроить рабочий сервер в соответствии с инструкцией, которая позволяет избежать ошибки "An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full"

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

Информация по клиент-серверному варианту работы здесь;

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

в свойствах кластера серверов,

и рабочих серверов кластера.

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

5.4. Убедиться, что на рабочих серверах кластера одновременно не используется IPv4 и IPv6.

5.5. Убедиться, что схема управления питанием - "Высокая производительность".

5.6. Убедиться, что установлены компоненты Microsoft Data Access Components

Этот пункт нужен для настройки с СУБД MS SQL Server.

В противном случае будете получать ошибку вида: "Компоненты OLE DB провайдера не найдены".

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

Настройки, которые необходимо выполнить (в дополнение к настройке 5.2. Настроить рабочий сервер в соответствии с инструкцией):

Запустить regedit и в ветке HKLM\System\CurrentControlSet\Services\Tcpip\Parameters указать
- MaxFreeTcbs= 100000
- TcpTimedWaitDelay= 30
- MaxUserPort= 65535
- EnableDynamicBacklog= 1
- MinimumDynamicBacklog= 20
- MaximumDynamicBacklog= 20000
- DynamicBacklogGrowthDelta= 10
- Выполнить: netsh int ipv4 set dynamicport tcp start=10000 num=55536
- Выполнить: netsh int ipv4 set dynamicport udp start=10000 num=55536
7. Настроить кластер серверов

7.1. Необходимо добавить рабочие серверы в кластер

7.2. Настроить условия перезапуска

Настроить условия перезапуска по превышению порога памяти.

7.3. Настроить расположение каталога кластера

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

Настройку необходимо выполнить с учетом конфигурации системы

Постарайтесь выполнять настройку таким образом, чтобы она не приводила к запуску 100 процессов rphost, т.к. значительное число процессов rphost приводит к неэффективному использованию памяти процессами кластера.

Не стоит просто так уменьшать параметр "Число соединений на процесс" или "Число информационных баз на процесс".

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

7.5. Выполнить настройки для случая нескольких рабочих серверов в кластере.
- Обязательно должно быть явно указано расположение:
  - сервиса журнала регистрации;
  - сервиса полнотекстового поиска данных;
  - сервиса работы с внешними источниками данных;
  - расположение клиентских и серверных лицензий и сервисов лицензирования;
  - расположение сеансовых данных.
  8. Первый запуск
  
  На этом этапе следует выполнить следующие шаги:
  - Запустить кластер серверов, создать информационную базу;
  - Зарегистрировать программные лицензии;
  - Убедиться, что пользователь может войти в информационную базу без ошибок.
  9. Отказоустойчивость
  
  В случае необходимости настройки отказоустойчивого кластера, выполните следующие шаги.
  
  9.1. Проверить лицензии.
  
  Убедитесь, что на рабочих серверах, которые должны выполнять роль Центральных серверов достаточно лицензий для работы всех пользователей в информационной системе при отсутствии одного из Центральных серверов в случае возможного (теоретически) отказа.
  
  9.2. Установить флаг "Центральный сервер".
  
  Установить флаг как на рисунке ниже.
  
  9.3. Установить флаг "Уровень отказоустойчивости"
  
  Установить параметр, пример на рисунке ниже.
  
  Подробную информацию про уровень отказоустойчивости вы можете прочитать в статье
  
  Обратите внимание, что не нужно просто так указывать максимально возможный уровень отказоустойчивости, т.к. это приведет к избыточным накладным расходам.
  
  9.4. Скорректировать строку соединения
  
  Необходимо скорректировать строку соединения с информационной базой.
  
  Имеется возможность указания списка резервирования с помощью строки соединения с информационной базой или в соответствующем поле свойств информационной базы.
  
  Список указывается в формате Server1, Server2:Port, Server3.
  
  10. Замечания
  
  10.1. Не настраивайте exec backup (или аналогичные утилиты) на директории кластера серверов
  
  Причина в том, что в этих директориях могут располагаться хранилища с сеансовыми данными, выполнять backup которых не нужно, а создание backp-а которых будет приводить к избыточным накладным расходам.
  
  10.2. Не настраивайте сжатие данных дисков с директорией кластера
  
  10.3. Не забывайте про периодическое выполнение дефрагментации дисков ОС Windows.
  
  10.4. Настроить защиту от вирусов.
  
  В случае расположения рабочих серверов кластера в зоне, к которой доступ строго ограничен, не имеет смысл настраивать антивирусные решения на рабочих серверах.
  
  Настройка антивирусных решений на таких серверах будет оказывать существенное влияние на производительность при практическом отсутствии выигрыша с точки зрения защиты.
  
  При этом, стоит обеспечить защиту антивирусными решениями те пользовательские компьютеры, с которых выполняется доступ к рабочим серверам кластера и сетевым директориям.
  
  Кластер — это разновидность параллельной
  или распределённой системы, которая:
  1. состоит из нескольких связанных
  между собой компьютеров;
  2. используется как единый,
  унифицированный компьютерный ресурс
  
  Дано: есть бизнес-приложение (например, ERP-система), с которым работают одновременно тысячи (возможно, десятки тысяч) пользователей.
  1. Сделать приложение масштабируемым, чтобы при увеличении количества пользователей можно было за счёт наращивания аппаратных ресурсов обеспечить необходимую производительность приложения.
  2. Сделать приложение устойчивым к выходу из строя компонентов системы (как программных, так и аппаратных), потере связи между компонентами и другим возможным проблемам.
  3. Максимально эффективно задействовать системные ресурсы и обеспечить нужную производительность приложения.
  4. Сделать систему простой в развертывании и администрировании.
  К желаемому результату мы пришли не сразу.
  
  В этой статье расскажем о том, какие бывают кластеры, как мы выбирали подходящий нам вид кластера и о том, как эволюционировал наш кластер от версии к версии, и какие подходы позволили нам в итоге создать систему, обслуживающую десятки тысяч одновременных пользователей.
  
  Как писал автор эпиграфа к этой статье Грегори Пфистер в своей книге «In search of clusters», кластер был придуман не каким-либо конкретным производителем железа или софта, а клиентами, которым не хватало для работы мощностей одного компьютера или требовалось резервирование. Случилось это, по мнению Пфистера, ещё в 60-х годах прошлого века.
  Традиционно различают следующие основные виды кластеров:
  1. Отказоустойчивые кластеры (High-availability clusters, HA, кластеры высокой доступности)
  2. Кластеры с балансировкой нагрузки (Load balancing clusters, LBC)
  3. Вычислительные кластеры (High performance computing clusters, HPC)
  4. Системы распределенных вычислений (grid) иногда относят к отдельному типу кластеров, который может состоять из территориально разнесенных серверов с отличающимися операционными системами и аппаратной конфигурацией. В случае grid-вычислений взаимодействия между узлами происходят значительно реже, чем в вычислительных кластерах. В grid-системах могут быть объединены HPC-кластеры, обычные рабочие станции и другие устройства.
  Для тех, кто не в курсе, коротко расскажу, как устроены бизнес-приложения 1С. Это приложения, написанные на предметно-ориентированном языке, «заточенном» под автоматизацию учётных бизнес-задач. Для выполнения приложений, написанных на этом языке, на компьютере должен быть установлен рантайм платформы 1С:Предприятия.
  
  1С:Предприятие 8.0
  
  Первая версия сервера приложений 1С (еще не кластер) появилась в версии платформы 8.0. До этого 1С работала в клиент-серверном варианте, данные хранились в файловой СУБД или MS SQL, а бизнес-логика работала исключительно на клиенте. В версии же 8.0 был сделан переход на трехзвенную архитектуру «клиент – сервер приложений – СУБД».
  
  Сервер 1С в платформе 8.0 представлял собой СОМ+ сервер, умеющий исполнять прикладной код на языке 1С. Использование СОМ+ обеспечивало нам готовый транспорт, позволяющий клиентским приложениям общаться с сервером по сети. Очень многое в архитектуре и клиент-серверного взаимодействия, и прикладных объектов, доступных разработчику 1С, проектировалось с учетом использования СОМ+. В то время в архитектуру не было заложено отказоустойчивости, и падение сервера вызывало отключение всех клиентов. При падении серверного приложения СОМ+ поднимал его при обращении к нему первого клиента, и клиенты начинали свою работу с начала – с коннекта к серверу. В то время всех клиентов обслуживал один процесс.
  
  1С:Предприятие 8.1
  
  В следующей версии мы захотели:
  - Обеспечить нашим клиентам отказоустойчивость, чтобы аварии и ошибки у одних пользователей не приводили авариям и ошибкам у других пользователей.
  - Избавиться от технологии СОМ+. СОМ+ работала только на Windows, а в то время уже начала становиться актуальной возможность работы под Linux.
  Так в версии 8.1 появился первый кластер. Мы реализовали свой протокол удаленного вызова процедур (поверх ТСР), который по внешнему виду выглядел для конечного потребителя-клиента практически как СОМ+ (т.е. нам практически не пришлось переписывать код, отвечающий за клиент-серверные вызовы). При этом сервер, реализованный нами на С++, мы сделали платформенно-независимым, способным работать и на Windows, и на Linux.
  
  На смену монолитному серверу версии 8.0 пришло 3 вида процессов – рабочий процесс, обслуживающий клиентов, и 2 служебных процесса, поддерживающих работу кластера:
  - rphost – рабочий процесс, обслуживающий клиентов и исполняющий прикладной код. В составе кластера может быть больше одного рабочего процесса, разные рабочие процессы могут исполняться на разных физических серверах – за счёт этого достигается масштабируемость.
  - ragent – процесс агента сервера, запускающий все другие виды процессов, а также ведущий список кластеров, расположенных на данном сервере.
  - rmngr – менеджер кластера, управляющий функционированием всего кластера (но при этом на нем не работает прикладной код).
  Под катом – схема работы этих трёх процессов в составе кластера.
  
  Клиент на протяжении сессии работал с одним рабочим процессом, падение рабочего процесса означало для всех клиентов, которых этот процесс обслуживал, аварийное завершение сессии. Остальные клиенты продолжали работу.
  
  1С:Предприятие 8.2
  
  В версии 8.2 мы захотели, чтобы приложения 1С могли запускаться не только в нативном (исполняемом) клиенте, а ещё и в браузере (без модификации кода приложения). В связи с этим, в частности, встала задача отвязать текущее состояние приложения от текущего соединения с рабочим процессом rphost, сделать его stateless. Как следствие возникло понятие сеанса и сеансовых данных, которые нужно было хранить вне рабочего процесса (потому что stateless). Был разработан сервис сеансовых данных, хранящий и кэширующий сеансовую информацию. Появились и другие сервисы — сервис управляемых транзакционных блокировок, сервис полнотекстового поиска и т.д.
  
  В этой версии также появились несколько важных нововведений – улучшенная отказоустойчивость, балансировка нагрузки и механизм резервирования кластеров.
  
  Отказоустойчивость
  
  Поскольку процесс работы стал stateless и все необходимые для работы данные хранились вне текущего соединения «клиент – рабочий процесс», в случае падения рабочего процесса клиент при следующем обращении к серверу переключался на другой, «живой» рабочий процесс. В большинстве случаев такое переключение происходило незаметно для клиента.
  
  Балансировка нагрузки
  
  Это стандартная задача для кластера с балансировкой нагрузки. Есть несколько типовых алгоритмов её решения, например:
  - Least Connections: новый запрос передается на сервер, обрабатывающий в данный момент наименьшее количество запросов.
  - Least Response Time: сервер выбирается на основе времени его ответа: новый запрос отдаётся серверу, ответившему быстрее других серверов.
  Запрос от нового клиента адресуется на наиболее производительный на данный момент сервер.
  
  Запрос от существующего клиента в большинстве случаев адресуется на тот сервер и в тот рабочий процесс, в который адресовался его предыдущий запрос. С работающим клиентом связан обширный набор данных на сервере, передавать его между процессами (а тем более между серверами) – довольно накладно (хотя мы умеем делать и это).
  
  Запрос от существующего клиента передается в другой рабочий процесс в двух случаях:
  1. Процесса больше нет: рабочий процесс, с которым ранее взаимодействовал клиент, более недоступен (упал процесс, стал недоступен сервер и т.п.).
  2. Есть более производительный сервер: если в кластере есть сервер, отличающийся по производительности в два и более раза по сравнению с сервером, где запушен текущий рабочий процесс, то платформа считает, что даже ценой миграции клиентского контекста нам выгоднее выполнять запросы на более производительном сервере. Переноситься клиенты с одного сервера на другой будут постепенно, по одному, с периодической оценкой результата – что в плане производительности стало с серверами после переноса каждого из клиентских процессов. Цель этой процедуры – выравнивание производительности серверов в кластере (т.е. равномерная загрузка серверов).
  Резервирование кластеров
  
  Мы решили повысить отказоустойчивость кластера, прибегнув к схеме Active / passive. Появилась возможность конфигурировать два кластера – рабочий и резервный. В случае недоступности основного кластера (сетевые неполадки или, например, плановое техобслуживание) клиентские вызовы перенаправлялись на резервный кластер.
  
  Однако эта конструкция была довольно сложна в настройке. Администратору приходилось вручную собирать две группы серверов в кластеры и конфигурировать их. Иногда администраторы допускали ошибки, устанавливая противоречащие друг другу настройки, т.к. не было централизованного механизма проверки настроек. Но, тем не менее, этот подход повышал отказоустойчивость системы.
  
  1С:Предприятие 8.3
  
  В версии 8.3 мы существенно переписали код серверной части, отвечающий за отказоустойчивость. Мы решили отказаться от схемы Active / passive кластеров ввиду сложности её конфигурирования. В системе остался только один отказоустойчивый кластер, состоящий из любого количества серверов – это ближе к схеме на Active / active, в которой запросы на отказавший узел распределяются между оставшимися рабочими узлами. За счет этого кластер стал проще в настройке. Ряд операций, повышающих отказоустойчивость и улучшающих балансировку нагрузки, стали автоматизированными. Из важных нововведений:
  - Новая настройка кластера «Уровень отказоустойчивости»: число, указывающее, сколько серверов может выйти из строя без последствий в виде аварийного завершения сеансов подключенных пользователей. Исходя из этой настройки кластер будет тратить определённый объём ресурсов на синхронизацию данных между рабочими серверами, чтобы иметь всю необходимую для продолжения работы клиентов информацию на «живых» серверах в случае выхода из строя одного или нескольких серверов.
  - Количество рабочих процессов не задается вручную, как раньше, а автоматически рассчитывается исходя из описаний требований задач по отказоустойчивости и надежности.
  - Появился ряд настроек, связанных с максимальными объемами памяти, которые разрешается потреблять рабочим процессам, а также настройки, определяющие что делать, если эти объемы превышены:
  Главная идея этих наработок – упростить работу администратора, позволяя ему настраивать кластер в привычных ему терминах, на уровне оперирования серверами, не опускаясь ниже, а также минимизировать уровень «ручного управления» работой кластера, дав кластеру механизмы для решения большинства рабочих задач и возможных проблем «на автопилоте».
  
  Три звена отказоустойчивости
  
  Как известно, даже если компоненты системы по отдельности надёжны, проблемы могут возникнуть там, где компоненты системы вызывают друг друга. Мы хотели свести количество мест, критичных для работоспособности системы, к минимуму. Важным дополнительным соображением была минимизация переделок прикладных механизмов в платформе и исключение изменений в прикладных решениях. В версии 8.3 появилось 3 звена обеспечения отказоустойчивости «на стыках»:
  
  В заключение
  
  Благодаря механизму отказоустойчивости приложения, созданные на платформе 1С:Предприятие, благополучно переживают разные виды отказов рабочих серверов в кластере, при этом бо́льшая часть клиентов продолжают работать без перезапуска.
  
  Бывают ситуации, когда мы не можем повторить вызов, или падение сервера застает платформу в очень неудачный момент времени, например, в середине транзакции и не очень понятно, что с ними делать. Мы стараемся обеспечить статистически хорошую выживаемость клиентов при падении серверов в кластере. Как правило, средние потери клиентов за отказ сервера – единицы процентов. При этом все «потерянные» клиенты могут продолжить работу в кластере после перезапуска клиентского приложения.
  
  Надежность кластера серверов 1С в версии 8.3 существенно повысилась. Уже давно не редкость внедрения продуктов 1С, где количество одновременно работающих пользователей достигает нескольких тысяч. Есть и внедрения, где одновременно работают и 5 000, и 10 000 пользователей — например, внедрение в «Билайне», где приложение «1С: Управление Торговлей» обслуживает все салоны продаж «Билайн» в России, или внедрение в грузоперевозчике «Деловые Линии», где приложение, самостоятельно созданное разработчиками ИТ-отдела «Деловых Линий» на платформе 1С:Предприятие, обслуживает полный цикл грузоперевозок. Наши внутренние нагрузочные тесты кластера эмулируют одновременную работу до 20 000 пользователей.
  
  В заключение хочется кратко перечислить что ещё полезного есть в нашем кластере (список неполный):
  
  При размещении 1С в облачной инфраструктуре и среде виртуализации наиболее важными и непростыми задачами являются повышение скорости работы платформы «1С» и настройка СУБД. Для достижения максимальной производительности инфраструктуры 1С рекомендуется правильно выбирать архитектуру инфраструктуры, режимы работы, проверить и выполнить ряд важных настроек.
  
  В зависимости от количества пользователей, размера баз данных и ограничений бюджета (с учетом стоимости дополнительных лицензий на сервер «1С:Предприятие 8» и лицензий на СУБД) платформа «1С» может работать в файловом и клиент-серверном вариантах (на основе трехуровневой архитектуры «клиент-сервер» (рис. 1): клиентское приложение, кластер серверов «1С:Предприятия 8», СУБД).
  
  Рис. 1
  
  Как правильно выбрать вариант/режим работы 1С: файловый или SQL?
  
  Обычно для 1-10 пользователей выбирается файловый режим
  
  От 10 и более пользователей выбирается режим работы с использованием SQL
  
  В файловом варианте все пользователи могут работать на одной виртуальной машине в облаке, например на терминальном сервере.
  
  Для клиент-серверного варианта лучше выбрать не менее двух виртуальных машин:
  
  Сервер с клиентским приложением, например терминальный сервер с клиентской частью «1С» (толстый клиент)
  
  Сервер «1С» и СУБД (MS SQL или PostgreSQL)
  
  Как рассчитать мощности сервера для 1С в файловом режиме работы?
  
  В обоих вариантах: файловом и SQL, для работы с пользовательским приложением 1С в классическом режиме, например, «удаленного рабочего стола» (так называемый «толстый клиент»), необходимы следующие минимальные ресурсы виртуального сервера:
  
  Количество виртуальных ядер CPU = 1 или 2 для ОС + 0,25 * количество пользователей
  
  Объем памяти RAM = 1 или 2 ГБ для ОС + 0,5 ГБ * количество пользователей
  
  Размер диска/хранилища HDD = 20-40 ГБ для ОС и приложений + (0,1-10) ГБ * количество пользователей. Для ОС и 1С рекомендуется использовать самые быстрые диски
  
  Как рассчитать мощности сервера для 1С в варианте работы с SQL?
  
  В клиент-серверном варианте работы 1С, в котором используется СУБД SQL, рекомендуется разместить 1С Сервер и сервер SQL на отдельном виртуальном сервере в общей с клиентским сервером локальной подсети. Необходимы следующие минимальные мощности для этого виртуального сервера:
  
  Размер диска/хранилища HDD = 20-40 ГБ для ОС и приложений + (10-1000) ГБ в зависимости от объема и количества баз данных. Для ОС и СУБД рекомендуется использовать самые быстрые диски
  ------------
  ОС - операционная система, например, Windows Server
  Здесь Сервер 1С - ПО "сервер "1С:Предприятия 8"
  
  Наиболее важными и непростыми задачами являются повышение продуктивности использования платформы «1С» в облаке и настройка СУБД. Типичные проблемы при развертывании и эксплуатации облачной инфраструктуры для «1С» следующие:
  
  Неправильный выбор мощностей
  
  Неквалифицированная настройка сервисов виртуальной инфраструктуры
  
  Недостаточное внимание к тестированию производительности платформы «1С»
  
  Для достижения максимальной производительности рекомендуется проверить и выполнить ряд настроек. Прежде всего необходимо исключить свопинг, для чего с помощью системы мониторинга следует обязательно удостовериться в том, что объем оперативной памяти достаточен для работы ВМ. Кроме того, файл подкачки ОС, профили пользователей, файлы баз данных, файлы логов транзакций (SQL) и tempDB (SQL) лучше разместить на дополнительных SSD-дисках, а для файла подкачки установить фиксированный размер.
  
  На SQL-сервере необходимо выключить все ненужные службы, например FullText Search и Integration Services, установить максимально возможный объем оперативной памяти, максимальное количество потоков (Maximum Worker Threads) и повышенный приоритет сервера (Boost Priority), задать ежедневную дефрагментацию индексов и обновление статистики, настроить автоматическое увеличение файла базы данных (не менее 200 Мбайт) и файла лога (не менее 50 Мбайт), а также полную реиндексацию не реже одного раза в неделю. При размещении серверов SQL и «1С:Предприятие» на одной ВМ следует включить протокол Shared Memory.
  
  Следуя перечисленным выше рекомендациям, можно добиться увеличения быстродействия платформы «1С» в облаке в 1,5–2 раза.
  
  Квалифицированное размещение ИТ-сервисов, в том числе «1С», на облачной платформе позволяет:
  
  Существенно сократить расходы
  
  Повысить уровни безопасности (доступ к данным, резервное копирование, антивирусная защита и др.) и технического обслуживания
  
  Обеспечить централизованное администрирование и мониторинг
  
  Организовать эффективную и безопасную удаленную работу
  
  Воспользоваться гибкими возможностями масштабирования, лицензирования и оперативного перехода на необходимые версии конфигураций «1С»
  
  ЧЕК-ЛИСТ ПО ОПТИМИЗАЦИИ ИНФРАСТРУКТУРЫ 1С С MS SQL
  
  1. Включить возможность мгновенной инициализации файлов (Database instant file initialization)
  
  Это позволяет ускорить работу таких операций как:
  
  Создание базы данных
  
  Добавление файлов, журналов или данных в существующую базу данных
  
  Увеличение размера существующего файла (включая операции автоувеличения)
  
  Восстановление базы данных или файловой группы
  
  Для включения настройки:
  
  На компьютере, где будет создан файл резервной копии, откройте приложение Local Security Policy (secpol.msc)
  
  Разверните на левой панели узел Локальные политики, а затем кликните пункт Назначение прав пользователей
  
  На правой панели дважды кликните Выполнение задач по обслуживанию томов
  
  2. Включить параметр «Блокировка страниц в памяти» (Lock pages in memory)
  
  Эта настройка определяет, какие учетные записи могут сохранять данные в оперативной памяти, чтобы система не отправляла страницы данных в виртуальную память на диске, что может повысить производительность.
  
  Для включения настройки:
  
  В меню Пуск выберите команду Выполнить. В поле Открыть введите gpedit.msc
  
  В консоли Редактор локальных групповых политик разверните узел Конфигурация компьютера, затем узел Конфигурация Windows
  
  Разверните узлы Настройки безопасности и Локальные политики
  
  Выберите папку Назначение прав пользователя
  
  Политики будут показаны на панели подробностей
  
  На этой панели дважды кликните параметр Блокировка страниц в памяти
  
  В диалоговом окне Параметр локальной безопасности — блокировка страниц в памяти выберите «Добавить» пользователя или группу
  
  В диалоговом окне Выбор: пользователи, учетные записи служб или группы добавьте ту учетную запись, под которой у вас запускается служба MS SQL Server
  
  Чтобы изменения вступили в силу, перезагрузите сервер или зайдите под тем пользователем, под которым у вас запускается MS SQL Server
  
  3. Включить каталоги с файлами базы данных в правила исключения для антивируса.
  
  Если антивирус будет сканировать файлы базы, это может сильно замедлить работу СУБД.
  
  Для опытных администраторов: антивирус на сервер СУБД лучше не устанавливать.
  
  4. Включить каталоги с файлами базы данных в список исключений для системы автоматического копирования.
  
  Если на сервере установлена система автоматического копирования файлов, то, когда она будет копировать файлы базы, это может привести к замедлению работы. Копии базы необходимо делать средствами самой СУБД.
  
  5. Отключить механизм DFSS для дисков.
  
  Механизм Dynamic Fair Share Scheduling отвечает за балансировку и распределение аппаратных ресурсов между пользователями. Иногда его работа может негативно сказываться на производительности 1С.
  
  Чтобы отключить его только для дисков, нужно:
  
  Найти в реестре ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TSFairShare\Disk
  
  Установить значение параметра EnableFairShare в 0
  
  6. Отключить сжатие данных для каталогов, в которых лежат файлы базы.
  
  При включенном сжатии ОС будет пытаться дополнительно обрабатывать файлы при модификации, что замедлит сам процесс записи, но сэкономит место.
  
  Чтобы отключить сжатие файлов в каталоге, необходимо:
  
  Открыть свойства каталога
  
  На закладке Общие нажать кнопку Другие
  
  Снять флаг «Сжимать» содержимое для экономии места на диске
  
  7. Установить параметр «Максимальная степень параллелизма» (Max degree of parallelism) в значение 1.
  
  Данный параметр определяет, во сколько потоков может выполняться один запрос. По умолчанию параметр равен 0, это означает, что сервер сам подбирает число потоков. Для баз с характерной для 1С нагрузкой рекомендуется поставить данный параметр в значение 1, т.к. в большинстве случаев это положительно скажется на работе запросов.
  
  Для настройки параметра необходимо:
  
  Запустить Management Studio и подключиться к нужному серверу
  
  Открыть свойства сервера и выбрать закладку Дополнительно
  
  Установить значение параметра равное единице
  
  8. Ограничить максимальный объем памяти сервера MS SQL Server.
  
  Необходимо ограничить максимальный объем памяти, потребляемый MS SQL Server, особенно это критично, если роли сервера 1С и сервера СУБД совмещены. Максимальный объем памяти, рекомендуемый для MS SQL Server, можно рассчитать по следующей формуле:
  
  Память для MS SQL Server = Память всего – Память для ОС – Память для сервера 1С
  
  Например, на сервере установлено 64 ГБ оперативной памяти, необходимо понять, сколько памяти выделить серверу СУБД, чтобы хватило серверу 1С.
  
  Для нормальной работы ОС в большинстве случаев более чем достаточно 4 ГБ, обычно – 2-3 ГБ.
  
  Чтобы определить, сколько памяти требуется серверу 1С, необходимо посмотреть, сколько памяти занимают процессы кластера серверов в разгар рабочего дня. Этими процессами являются ragent, rmngr и rphost, подробно данные процессы рассматриваются в разделе, который посвящен кластеру серверов. Снимать данные нужно именно в период пиковой рабочей активности, когда в базе работает максимальное количество пользователей. Получив эти данные, необходимо прибавить к ним 1 ГБ – на случай запуска в 1С «тяжелых» операций.
  
  Чтобы установить максимальный объем памяти, используемый MS SQL Server, необходимо:
  
  Запустить Management Studio и подключиться к нужному серверу
  
  Открыть свойства сервера и выбрать закладку Память
  
  Указать значение параметра Максимальный размер памяти сервера
  
  9. Включить флаг «Поддерживать» приоритет SQL Server (Boost SQL Server priority).
  
  Данный флаг позволяет повысить приоритет процесса MS SQL Server над другими процессами.
  
  Имеет смысл включать флаг только в том случае, если на компьютере с сервером СУБД не установлен сервер 1С.
  
  Для установки флага необходимо:
  
  Запустить Management Studio и подключиться к нужному серверу
  
  Открыть свойства сервера и выбрать закладку Процессоры
  
  Включить флаг «Поддерживать приоритет SQL Server (Boost SQL Server priority)» и нажать Ок
  
  10. Установить размер авто увеличения файлов базы данных.
  
  Автоувеличение позволяет указать величину, на которую будет увеличен размер файла базы данных, когда он будет заполнен. Если поставить слишком маленький размер авторасширения, тогда файл будет слишком часто расширяться, на что будет уходить время. Рекомендуется установить значение от 512 МБ до 5 ГБ.
  
  Для установки размера авторасширения необходимо:
  
  Запустить Management Studio и подключиться к нужному серверу
  
  Открыть свойства нужной базы и выбрать закладку Файлы
  
  Напротив каждого файла в колонке Автоувеличение поставить необходимое значение
  
  Данная настройка будет действовать только для выбранной базы. Если вы хотите, чтобы такая настройка действовала для всех баз, нужно выполнить эти же действия для служебной базы model. После этого все вновь созданные базы будет иметь те же настройки, что и база model.
  
  11. Разнести файлы данных mdf и файлы логов ldf на разные физические диски.
  
  В этом случае работа с файлами может идти не последовательно, а практически параллельно, что повышает скорость работы дисковых операций. Лучше всего для этих целей подходят диски SSD.
  
  Для переноса файлов необходимо:
  
  Запустить Management Studio и подключиться к нужному серверу
  
  Открыть свойства нужной базы и выбрать закладку Файлы
  
  Запомнить имена и расположение файлов
  
  Отсоединить базу, выбрав через контекстное меню Задачи – Отсоединить
  
  Поставить флаг Удалить соединения и нажать Ок
  
  Открыть Проводник и переместить файл данных и файл журнала на нужные носители
  
  В Management Studio открыть контекстное меню сервера и выбрать пункт Присоединить базу
  
  Нажать кнопку Добавить и указать файл mdf с нового диска
  
  В нижнем окне сведения о базе данных в строке с файлом лога нужно указать новый путь к файлу журнала транзакций и нажать Ок
  
  12. Вынести файлы базы TempDB на отдельный диск.
  
  Служебная база данных TempDB используется всеми базами сервера для хранения, промежуточных расчетов, временных таблиц, версий строк при использовании RCSI и многих других вещей. Обычно обращений к этой базе очень много, и если она будет лежать на медленных дисках, это может замедлить работу системы.
  
  Рекомендуется хранить базу TempDB на отдельном диске для повышения производительности работы системы.
  
  Для переноса базы TempDB на отдельный диск необходимо:
  
  Запустить Management Studio и подключиться к нужному серверу
  
  Создать окно запроса и выполнить скрипт:
  
  ALTER DATABASE tempdb
  
  MODIFY FILE (NAME = tempdev, FILENAME = 'Новый_Диск:\Новый_Каталог\tempdb.mdf')
  
  ALTER DATABASE tempdb
  
  MODIFY FILE (NAME = templog, FILENAME = 'Новый_Диск:\Новый_Каталог\templog.ldf')
  
  Перезапустить MS SQL Server
  
  13. Включить Shared Memory, если сервер 1С расположен на том же компьютере, что и сервер СУБД.
  
  Протокол Shared Memory позволит общаться приложениям через оперативную память, а не через протокол TCP/IP.
  
  Для включения Shared Memory необходимо:
  
  Запустить диспетчер конфигурации SQL Server
  
  Зайти в пункт SQL Native Client – Клиентские протоколы – Общая память – Включено
  
  Поставить значение Да и нажать Ок
  
  Протокол Именованные каналы нужно выключить аналогичным образом
  
  14. Перезапустить службу MS SQL Server
  
  Внимание! Когда все настройки выполнены, необходимо перезапустить службу MS SQL Server
  
  Читайте также:

Кластер серверов 1с предприятия что указывать

Файлы и каталоги сервера 1С

Основные настройки кластера 1С: 8.3

Инструкция по настройке рабочих серверов с Технологической Платформой 1С:Предприятие

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

2. Определить, сколько пользователей будет работать одновременно

3. Настроить профили пользователей ОС, от которых будут запускаться процессы кластера

4. Настроить логирование и дампы

5. Проверить настройки операционной системы

5.1. Настроить рабочий сервер

5.2. Настроить рабочий сервер

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

5.4. Убедиться, что на рабочих серверах кластера одновременно не используется IPv4 и IPv6.

5.5. Убедиться, что схема управления питанием - "Высокая производительность".

5.6. Убедиться, что установлены компоненты Microsoft Data Access Components

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

7. Настроить кластер серверов

7.1. Необходимо добавить рабочие серверы в кластер

7.2. Настроить условия перезапуска

7.3. Настроить расположение каталога кластера

7.4. Настроить число соединений и информационных баз на процесс

7.5. Выполнить настройки для случая нескольких рабочих серверов в кластере.

8. Первый запуск

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

9.1. Проверить лицензии.

9.2. Установить флаг "Центральный сервер".

9.3. Установить флаг "Уровень отказоустойчивости"

9.4. Скорректировать строку соединения

10. Замечания

10.1. Не настраивайте exec backup (или аналогичные утилиты) на директории кластера серверов

10.2. Не настраивайте сжатие данных дисков с директорией кластера

10.3. Не забывайте про периодическое выполнение дефрагментации дисков ОС Windows.

10.4. Настроить защиту от вирусов.

1С:Предприятие 8.0

1С:Предприятие 8.1

1С:Предприятие 8.2

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

Балансировка нагрузки

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

1С:Предприятие 8.3

Три звена отказоустойчивости

В заключение

Как правильно выбрать вариант/режим работы 1С: файловый или SQL?

Как рассчитать мощности сервера для 1С в файловом режиме работы?

Как рассчитать мощности сервера для 1С в варианте работы с SQL?

ЧЕК-ЛИСТ ПО ОПТИМИЗАЦИИ ИНФРАСТРУКТУРЫ 1С С MS SQL

1. Включить возможность мгновенной инициализации файлов (Database instant file initialization)

2. Включить параметр «Блокировка страниц в памяти» (Lock pages in memory)

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

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

5. Отключить механизм DFSS для дисков.

6. Отключить сжатие данных для каталогов, в которых лежат файлы базы.

7. Установить параметр «Максимальная степень параллелизма» (Max degree of parallelism) в значение 1.

8. Ограничить максимальный объем памяти сервера MS SQL Server.

9. Включить флаг «Поддерживать» приоритет SQL Server (Boost SQL Server priority).

10. Установить размер авто увеличения файлов базы данных.

11. Разнести файлы данных mdf и файлы логов ldf на разные физические диски.

12. Вынести файлы базы TempDB на отдельный диск.

13. Включить Shared Memory, если сервер 1С расположен на том же компьютере, что и сервер СУБД.

14. Перезапустить службу MS SQL Server