Инструкция по настройке рабочих серверов с Технологической Платформой 1С:Предприятие
Ниже приводится инструкция по настройке рабочих серверов с Технологической Платформой 1С:Предприятие.
Рекомендуется при настройке рабочего сервера пройти указанный ниже сheck-лист и продумать, нужна ли указанная ниже настройка в вашем конкретном случае.
Если такая настройка нужна, то выполнить её. Важно на каждом пункте сознательно принимать решение о том, как именно вы хотите настроить рабочий сервер.
1. Определить, сколько информационных баз будут использоваться в кластере для работы пользователей
Существует несколько вариантов развертывания:
- в продуктивной среде и подготовительной зоне;
- в тестовой зоне;
- в зоне разработки.
Наибольшие требования с точки зрения доступности информационной системы будут в случае развертывания в продуктивной и подготовительной зонах.
В этих случаях желательно все нерабочие информационные базы вынести в отдельный кластер на отдельные серверы.
Возможно, возникнет желание сделать копию рабочей информационной базы и развернуть в том же кластере в продуктивной среде, например, для того, чтобы восстановить определенные данные за прошлые сутки. Стоит перебороть это желание и проследить, чтобы
- к копии базы не было доступа у пользователей;
- в копии базы были выключены регламентные задания;
- копия базы не участвовала в обменах.
Для восстановления данных за предыдущие сутки не стоит использовать продукционный кластер, а получать необходимые данные с подготовительной зоны информационной системы.
Рекомендуется в продуктивной зоне настраивать кластер с минимальным числом необходимых баз, чтобы снизить возможное влияние тестовых баз на работу пользователей.
В тестовой зоне и зоне разработки ограничений по числу информационных баз в кластере условно нет.
2. Определить, сколько пользователей будет работать одновременно
Число одновременно работающих пользователей информационной базы является одним из основных параметров, определяющих нагрузку на информационную систему.
Этот параметр также необходим для корректного расчета конфигурации оборудования, который выполняется исходя из
- Конфигурации системы;
- Сценария работы пользователей;
- Числа одновременно работающих пользователей;
- Используемых версий программных продуктов.
3. Настроить профили пользователей ОС, от которых будут запускаться процессы кластера
Необходимо определиться, будут ли процессы кластера серверов работать от имени различных пользователей информационной системы.
Это может быть необходимо для того, чтобы код, который выполняется в rphost точно не мог обратиться к каким-либо определенным данным на рабочем сервере или выполнить операцию с административными правами.
Для этого нужно:
- Подготовить файл swpuser.ini (http://its.1c.ru/db/v837doc/bookmark/adm/TI000000418);
- Создать пользователей операционной системы, от имени которых будут запускаться процессы кластера;
- Создать профили соответствующих пользователей;
- Настроить ограничение прав доступа пользователей к каталогам на уровне ОС, к которым процессы не должны иметь доступ;
Для того, чтобы создать профили пользователей ОС достаточно один раз войти от их имени в ОС 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 в случае использования.
Инструкцию можно найти здесь: http://its.1c.ru/db/v837doc#bookmark:cs:TI000000191
ras cluster (—daemon) —port=
—port или -p указывает сетевой порт, по которому утилита администрирования будет взаимодействовать с сервером администрирования. Значение по умолчанию равно 1545.
(—daemon) — указывается для ОС Linux
5.4. Убедиться, что на рабочих серверах кластера одновременно не используется IPv4 и IPv6.
5.5. Убедиться, что схема управления питанием — «Высокая производительность».
5.6. Убедиться, что установлены компоненты Microsoft Data Access Components
Этот пункт нужен для настройки с СУБД MS SQL Server.
В противном случае будете получать ошибку вида: «Компоненты OLE DB провайдера не найдены».
Скачать MDAC можно с официальных ресурсов microsoft.
6. Необходимо настроить сетевой стек для обеспечения возможности обработки большого числа подключений
Настройки, которые необходимо выполнить (в дополнение к настройке 5.2. Настроить рабочий сервер в соответствии с инструкцией):
- Запустить regedit и в ветке HKLM\System\CurrentControlSet\Services\Tcpip\Parameters указать
- MaxFreeTcbs= 100000
- TcpTimedWaitDelay= 30
- MaxUserPort= 65534
- EnableDynamicBacklog= 1
- MinimumDynamicBacklog= 20
- MaximumDynamicBacklog= 20000
- DynamicBacklogGrowthDelta= 10
- Выполнить: netsh int ipv4 set dynamicport tcp start=10000 num=64510
- Выполнить: netsh int ipv4 set dynamicport udp start=10000 num=64510
7. Настроить кластер серверов
7.1. Необходимо добавить рабочие серверы в кластер
Информация по работе со списком серверов кластера тут: http://its.1c.ru/db/v837doc#bookmark:cs:TI000000157
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. Настроить защиту от вирусов.
В случае расположения рабочих серверов кластера в зоне, к которой доступ строго ограничен, не имеет смысл настраивать антивирусные решения на рабочих серверах.
Настройка антивирусных решений на таких серверах будет оказывать существенное влияние на производительность при практическом отсутствии выигрыша с точки зрения защиты.
При этом, стоит обеспечить защиту антивирусными решениями те пользовательские компьютеры, с которых выполняется доступ к рабочим серверам кластера и сетевым директориям.
Администрирование кластера серверов
Для администрирования кластера серверов можно использовать три разных набора инструментов.
Во-первых, это внешняя обработка Управление серверами. Она позволяет администрировать серверы различных версий из одной информационной базы. Для взаимодействия с сервером администрирования (ras) в обработке используется программный интерфейс встроенного языка. Одним из важных преимуществ этой обработки является ее кроссплатформенность — «Управление серверами» можно запустить под любой операционной системой, поддерживаемой «1С:Предприятием 8».
Во-вторых, это Windows утилита администрирования кластера. Она представляет собой консоль управления Microsoft, позволяющую подключаться одновременно к нескольким кластерам серверов и в графическом виде управлять их составом и свойствами.
В-третьих, это набор кросс-платформенных инструментов, работающих и в Windows, и в Linux, которые из командной строки позволяют выполнять все административные действия независимо от используемой платформы.
Создание кластера серверов 1C
Когда в компании ПО от 1С использует всего несколько человек, достаточно одного хорошего и правильно настроенного сервера для комфортной работы. А если количество пользователей больше сотни, стоит предпринять меры по снижению нагрузки на оборудование. И в этом поможет кластер.
Когда требуется создание кластера серверов 1C? В тех случаях, когда нужно решить любую из этих проблем:
- Сбой или поломка оборудования. Вы можете создать резервный кластер серверов;
- Недостаточную безопасность БД. Появляется возможность шифрования данных;
- Неравномерное распределение нагрузки. Разделение процессов позволяет эффективнее управлять клиентскими соединениями и запросами;
- Нестабильность работы. Правильно настроенный кластер серверов 1С повышает стабильность работы установленных приложений.
Для установки кластера серверов не нужно разбираться в принципах работы серверного оборудования. Благодаря нашей инструкции создание кластера станет простейшей процедурой. Проверить эффективность работы кластера вы можете с помощью теста Гилёва, но он полезен далеко не во всех случаях.
Итак, как создать кластер серверов 1C? Рассказываем на примере версии 1C:8.3.
Аренда облачного сервера для разработки, хостинга, обученияПодробнее
Шаг 1. Создаём центральный сервер
В кластер 1С можно добавить минимум два сервера приложений. Предположим, что у нас нет ни одного. Давайте создадим кластер из двух серверов 1C. Для этого заходим в консоль администрирования 1C:8.3, находим там Central 1C:Enterprise 8.3 server (название раздела может меняться в зависимости от версии вашей платформы).
Нажимаем на него правой кнопкой мыши и выбираем «Создать» — «Центральный сервер 1C:Предприятия 8.3».
Присваиваем имя серверу. Пусть будет, например, 1cAppServer. Остальные поля оставляем без изменений.
Если всё сделано правильно, в консоли появится центральный сервер.
Шаг 2. Переименовываем локальный кластер
Раскрываем вкладку 1cAppServer и находим там «Кластеры» — «Локальный сервер».
Нажимаем на него правой кнопкой мыши, выбираем «Свойства».
Переименовываем в Cluster 1C.
Шаг 3. Создаём второй центральный сервер
По схеме из первого шага создаём второй центральный сервер и называем его 1cServer2
В консоли теперь отображается два сервера.
Шаг 4. Убираем лишнее
В разделе «Кластеры» в 1cServer2 открываем локальный кластер и удаляем его. Он создаётся автоматически, но нам не требуется.
Шаг 5. Подготавливаем кластер
Открываем 1cAppServer — «Кластеры» — Cluster 1C.
Выбираем «Рабочие серверы» — «Создать» — «Рабочий сервер».
Присваиваем имя 1cServer2, указываем то же самое в поле «Компьютер» — это будет его сетевое описание. Остальные поля не меняем.
Шаг 6. Формируем кластер 1C
Вы видите, что в консоли есть два рабочих сервера. Нажмите правой кнопкой мыши на 1cServer2 — «Свойства» и отметьте чекбокс «Центральный сервер». Сохраните изменения.
Шаг 7. Проверка
Во вкладке 1cServer2 — «Разделы» должен появиться Cluster 1C. Если вы его не видите, нужно перезагрузить консоль администрирования 1C. Закройте её и откройте заново — кластер будет отображаться.
Можно работать с кластером серверов 1C.
Кластер серверов 1С
В платформе 8.3.9 произошло долгожданное событие – кластер серверов 1С заработал. С того момента, когда о нем объявили в 8.3.6, до момента, когда он в 8.3.9, наконец, заработал, прошло много лет. В 8.3.10 его уже можно использовать.
На прошлой конференции мне задавали очень много вопросов по поводу кластера серверов 1С, настроек сервера 1С и т.д., поэтому на этой конференции я хочу поделиться с вами этой информацией.
Уровень отказоустойчивости, какой выбрать в каком случае?
Один из первых вопросов, который возникает при проектировании серверов 1С, это какой уровень отказоустойчивости выбрать – 0, 1, 2, 3, 8, 10?
На практике в 99% случаев почти на любых высоконагруженных системах хватает уровня «ноль». Главное, грамотно настроить соотношение центральных и рабочих серверов 1С.
Есть такой критерий: если стоимость показа ошибки пользователю больше, чем стоимость еще одного сервера 1С и его лицензирования, то поднимайте уровень отказоустойчивости выше нуля. Потому что:
- Когда уровень отказоустойчивости равен нулю, но есть хотя бы два центральных сервера, то при отказе одного из центральных серверов, те пользователи, сеансы которых к нему подключены, просто получат ошибку с предложением перезапустить 1С. Перезапустят 1С, подключатся ко второму центральному серверу, и все заработает.
- Но если есть пожелание, чтобы переброс сеанса на работающий сервер отрабатывал автоматически, и пользователь не видел никаких сообщений и ошибок – чтобы было максимум две-три секунды торможения, и работа опять шла дальше, то выбивайте бюджеты на третий центральный сервер и устанавливайте уровень отказоустойчивости больше нуля. В этом случае с тремя серверами вы сможете перебрасывать сеансы пользователей без перезапуска.
Главное – помнить, что количество работающих в данный момент центральных серверов 1С в кластере должно быть на единицу больше, чем настроенный уровень отказоустойчивости.
При уровне «один» вам нужно уже как минимум три сервера, поскольку вы уже настраиваете кластер, а он по умолчанию отказоустойчивый, и при выходе одного центрального сервера два должны остаться в работе. Но если из строя выйдет еще один центральный сервер – кластер откажет в соединении.
Центральный сервер vs Рабочий сервер, в чём разница?
В 1С помимо центральных серверов есть такая сущность в кластере, как рабочие сервера. В чем разница?
- Центральный сервер – это самодостаточная единица, он может все. Он может принимать на себя клиентские соединения, он обслуживает любые сервисы и выполняет все математические расчеты.
- Рабочий сервер – это «рабочая лошадка» кластера. Он не может принимать соединения напрямую – к нему ни клиент не может напрямую подключиться, ни фоновое задание на нем напрямую запустить нельзя. Все это делается только по указанию центрального сервера 1С – на рабочий сервер передается какая-то задача, он ее выполняет и отдает результат. Все счастливы.
Есть определенный критерий, когда к имеющимся одному, двум, трем центральным серверам (которые служат в основном для отказоустойчивости) нужно добавление еще и рабочих серверов. Этот критерий простой: если стоимость модернизации текущего центрального сервера дороже, чем покупка нового (а такое бывает), то купите еще один сервер, лицензируйте его и назначьте рабочим. Это позволит вам организовать фактически безграничное горизонтальное масштабирование кластера – вы сможете свободно распространять мощность по базам.
Нужно помнить, что любой центральный сервер можно превратить в рабочий, а любой рабочий – в центральный. Главное, не забывать при этом «условие отказоустойчивости» – чтобы центральных серверов у вас не стало меньше, чем «уровень отказоустойчивости плюс один».
Во время сбоя превращать рабочий сервер в центральный нельзя. Это нужно делать заранее, во время регламентного обслуживания. Представим ситуацию, что у вас один центральный и один рабочий сервер, и администраторы сказали, что центральный сервер надо поставить на профилактику.
Одной галочкой мы превращаем рабочий сервер в центральный – на него тут же мгновенно передаются все блокировки и все списки баз. Теперь он знает, на каком сервере СУБД какая база обслуживается, и может спокойно принимать на себя соединения.
После этого вам осталось настроить клиентские 1С так, чтобы через точку с запятой были указаны два сервера, а не один. Затем вы спокойно ставите первый сервер на профилактику – ваши запросы в это время обслуживает второй сервер.
Для пользователя все это практически прозрачно. Единственное, если какой-то пользователь в это время все-таки был в системе, он получит ошибку и предложение переподключиться.
Требования назначений функциональности, как это готовить?
Все эти «чудеса», в основном, настраиваются с помощью «Требования назначения функциональности». Это – основной механизм работы кластера 1С. Поначалу кажется, что все очень сложно и запутанно: нужно какие-то приоритеты, какие-то сервисы куда-то назначить, что-то оставить в «Авто», а что-то вообще не трогать. Но, на удивление, потом все работает так, как настроили.
- Первое, что вы должны указать – это «Объект требования». Например, можно указать «Сервер сеансовых данных» – тогда сеансовые данные будут писаться именно на тот сервер 1С, где вы настроили объект требования назначения функциональности «Сервис сеансовых данных»,
- Далее указываете «Тип требования» – в данном случае, «Назначать».
- И обязательно, если у вас центральных серверов больше чем один, указываете какой-то приоритет. Тогда сеансовые данные всегда будут писаться на этот сервер. Если вы это не сделали, сеансовые данные будут писаться, как решит механика сервера в конкретный момент.
В «Требовании назначения функциональности» есть несколько ограничений, а именно:
- Пункт «Имя БД» можно трогать, только если вы счастливый обладатель лицензии на платформу уровня КОРП. Если вы имеете профессиональную платформу, то указывать конкретное имя базы данных в «Требовании назначения функциональности» нельзя.
- Также в пункте «Значение дополнительного параметра» указывать тип клиента (тонкий, толстый, веб-клиент, конфигуратор) и вид фонового задания можно только в КОРП-версии. Для ПРОФ-версии можно указывать только общие назначения (например, что на этот сервер можно отдать все бэкграунды – указать конкретный бэкграунд нельзя).
Если у вас в кластере есть несколько центральных серверов, нужно обязательно настроить несколько «Требований назначения функциональности».
Нужно настроить, на каком из центральных серверов будут сеансовые данные. Причем, это нужно настроить на всех центральных серверах и на каком-то из них нужно указать приоритет выше, чем на другом. Тогда при нормальной рабочей нагрузке системы сеансовые данные всегда будут предсказуемо писаться на один сервер. Если сервер выходит из строя, системе надо знать, куда их писать. Для этого на втором сервере (где в рабочей нагрузке эта запись не ведется, поскольку приоритет ниже), вы должны указать это требование назначения функциональности с пониженным приоритетом, и механика сервера переключит туда сеансовые данные.
То же самое касается журналов регистрации. Очень частая ошибка, что про этот сервис забывают, не указывают, а потом удивляются, почему у них журнал регистрации три дня ведется на одном сервере, а пять дней на другом. И, когда нужно собрать общую информацию, кто заходил в базу, кто что менял – ничего не могут найти и ничего не могут собрать. Все это настраивается в «Требованиях назначения функциональности». Здесь нужно четко указать по приоритетам, где и что.
- Помимо этого, нужно настроить сервер полнотекстового поиска, чтобы не нагружать серверы лишней работой. Пусть он крутится на одном сервере. Иначе он будет обновлять индекс то там, то здесь, и нагружать другие серверы лишней, никому не нужной работой – зря использовать их мощность.
Как механика сервера выбирает, куда назначить конкретное соединение?
Сервер может быть в нескольких состояниях.
- Например, в состоянии «Авто». Это – состояние любого сервера по умолчанию, т.е. он все принимает все, любые требования назначения.
- Он может быть в состоянии «Назначать» – этого высокоприоритетное состояние, т. е. он как бы выиграет выборы.
- Он может быть в состоянии «Назначать», но с приоритетом ниже, чем тот, который этот же сервер назначает на себя с более высоким приоритетом.
- Он может быть в состоянии «Не назначать» – это полный отказ обслуживать этот вид сервиса этим сервером, т.е. запрет на уровне администрирования кластера.
- И сервер может вообще не работать, он может быть выключен.
Как происходит выбор? Например, запускается запись журнала регистрации. Что сделает механика кластера серверов 1С?
- Сначала выстроит все серверы так, как указано в консоли кластера, фактически по алфавиту.
- Затем оттуда будут убраны все серверы, у которых четко написано «Сервис журнала регистрации» – «Не назначать».
- Затем из оставшихся серверов будут оставлены серверы с типом требования назначения функциональности «Назначать».
- Если серверов с требованием «Назначать» несколько, будет выбран тот, у которого выше приоритет.
- Если с этим приоритетом несколько серверов, то будет выбран тот, у которого на данный момент наиболее высокая производительность.
Производительность определяется кластером серверов 1С, отправляя раз в несколько секунд эталонную задачу на каждый рабочий сервер. После того, как сервер решает эту задачу и дает ответ, механика определяет, за какое время он ее решил. Чем быстрее решил, тем больше коэффициент производительности у этого сервера. Именно он возьмет на себя соединение, либо сеанс, либо этот сервис. Он выиграет эти выборы.
То же самое происходит, если мы ничего не настроили. Например, мы не настроили журнал регистрации. Для механики это значит, что сервис журнала регистрации стоит в состоянии «Авто». Это – состояние по умолчанию, его устанавливать бесполезно, такая настройка ничего не решит. Соответственно, среди серверов, у которых тип требования «Авто», будет выбран сервер с наиболее высоким приоритетом (если мы ему этот приоритет настраивали, указав тип требования «Авто»), и из них будет выбран сервер с наиболее высокой производительностью.
Наибольшая производительность вычисляется с погрешностью 25%. Не удивляйтесь, если у вас в консоли кластера видно, что производительность одного сервера 100, а второго 90, но при этом сеанс назначился на тот сервер, у которого производительность 90, хотя, казалось бы, должен быть выбран тот, у которого производительность выше. Разница в производительности будет определена однозначно только при 25% различия – если у первого сервера производительность будет 100, а у второго – 75, тогда выбор однозначно будет за первым.
Подпишитесь на дайджест!
Подпишитесь на дайджест, и получайте ежемесячно подборку полезных статей.Настройки кластера и сервера 1С, какая на что влияет?
Перейдем к настройкам кластера и сервера 1С. Тут нас ждет наследие платформы 8.2, где было только одно окно свойств, и оно было в кластере (в консоли сервера платформы 8.2 задать свойства можно было только кластеру в целом).
При этом, как ни странно, окно свойств кластера 1С настраивает свойства процесса сервера (rphost). Тут многие путаются.
Настройка №1, которую стоит иногда менять, – это «Интервал перезапуска» процессов сервера (rphost). Когда платформа была нестабильной, эта штука была нужной, потому что иногда возникали утечки памяти, из-за которых rphost разрастался, и его нужно было периодически перезапускать. Поэтому кластер настраивали так, чтобы он перезапускался раз в сутки, а потом удивлялись: «У меня иногда почему-то начинаются тормоза, которые длятся минуты две, потом все приходит в норму. Спасите-помогите, ничего не могу понять».
Дело в том, что секунды, которые мы указываем в «Интервале перезапуска», начинают считаться с момента старта процесса. Но предсказать, когда у вас в 8.3 процесс запустится, очень сложно. Механика его сама по разным причинам стартует, например: вы вышли за лимит баз на процесс, или за лимит соединений на процесс, или за лимит памяти на процесс. Допустим, процесс у вас стартовал 21 сентября в 11:00. В 11:00 часов 22 сентября при настройке перезапуска раз в сутки вы получите тормоза на всех соединениях, которые были на этом процессе. Откуда взялись эти тормоза? Ровно через сутки после своего запуска этот rphost будет помечен как неактивный. Системе нужно будет передать все его активные сеансы на новый процесс. Если никакого другого rphost в системе запущено не было, система запускает процесс, начинает втягивать в оперативную память этого процесса весь контекст конфигурации и только тогда, когда она туда затянет, начинает переключаться. Переключились, через две-три секунды у всех начинаются тормоза, а потом все приходит в норму. Настройка по умолчанию стоит 0, т.е. «никогда не перезапускать». Общая рекомендация – оставьте 0. Настройки, как на скриншоте – это устаревшая вещь. Не нужно их использовать. Лучше боритесь с утечками памяти.
Следующая настройка – «Допустимый объем памяти». Тут тоже очень тонкая вещь. Несмотря на то, что эта настройка находится в свойствах кластера – это максимальный объем оперативной памяти одного серверного процесса, одного rphost, а не всего кластера. Этой настройкой вы не перекроете, что сервер 1С не займет на вашем сервере больше 12 гигабайт. Это один rphost не займет больше 12 гигабайт. Что произойдет, когда он, например, занял 12 гигабайт? Если настройку «Интервал превышения допустимого объема памяти» оставить 0 (по умолчанию), то ничего не произойдет.
Это тоже очень частая ошибка в настройках кластеров. Система зафиксировала 12 гигабайт, но ничего не происходит, потому что она не знает, сколько секунд ждать превышения по памяти (свойство «Интервал превышения допустимого объема памяти»). Обязательно нужно указать, сколько времени процесс сервера (rphost) может превышать объем оперативной памяти. Например, мы указали 10 секунд. Система запускает счетчик. Если в течение 10 секунд rphost не вернулся в указанный лимит, система помечает его неактивным – на него больше не назначаются сеансы. Текущие сеансы по возможности переключаются на другой rphost.
Здесь есть еще одна классическая ошибка настройки кластера 1С – отсутствие галочки «Принудительно завершать проблемные процессы» и указание нулевого времени для остановки самого процесса. Что это означает на практике? Мы указали 12 гигабайт, 10 секунд – все замечательно. Процесс помечен неактивным, стартовал новый rphost, на него переключились все текущие сеансы, но наш rphost, который из-за каких-то утечек памяти весит 12 гигабайт, так и остался в системе, так и занимает 12 гигабайт. И пока мы не перезагрузим сервер 1С, с ним ничего не произойдет.
Чтобы проблемный процесс автоматически удалился из системы, обязательно поставьте галочку «Принудительно завершать проблемные процессы» и установите время остановки процесса (свойство «Выключенные процессы останавливать через»). Как вычислить это время? Очень просто. Запустите конфигурацию, в которой вы работаете, засеките время от первого входа до появления логина и пароля, умножьте это время на два и укажите в настройках. Почему нужно сделать именно так? Например, «УТ 11» при первом запуске запросит логин и пароль через 15 секунд. «Комплексная автоматизация 2.0» и «ERP» – через две минуты, они и три минуты могут грузиться. Если здесь время в секундах указано меньше, чем скорость загрузки контекста конфигурации в сервер 1С, вы никогда сеансы прозрачно не переключите, они будут завершаться раньше, все будут получать ошибку соединения «Сеанс завершен администратором». Да, конечно, после перезагрузки они зайдут на новый сервер, и все будет работать. Но, чтобы можно было переключиться на него прозрачно, без перезапуска, необходимо установить сюда время, вычисленное, как двойное время загрузки первого входа в конфигурацию.
Следующая настройка – это настройка сервера 1С. Здесь – то же самое ограничение: изменять значения по умолчанию можно, только если вы счастливый обладатель корпоративной лицензии на платформу. Если корпоративной лицензии нет, вы обязаны оставить все по умолчанию.
Хотя тут есть с чем «поиграться».
Первое – «Максимальный объем памяти, занимаемой рабочими процессами». Несмотря на то, что эта настройка относится к параметрам рабочего сервера 1С, это – тот объем памяти, который могут занимать все рабочие процессы кластера 1С. Вот такая путаница. Обратите внимание, что 0 – это не бесконечность, это 80% оперативной памяти, доступной в операционной системе, на которой запущен кластер. В отличие от настройки кластера, где объем оперативной памяти измерялся в килобайтах, здесь он в байтах. Очень многие путаются, забывают указать еще три ноля и удивляются, почему у них ничего не успевает запуститься. Rphost стартовал, набрал 100 мегабайт и сразу завершился, не запустившись. Думают, что он будет 100 гигабайт набирать, забывают указать три ноля. Обратите внимание на подписи, там байты.
Второй момент – это «Безопасный расход памяти за один вызов». Тут вообще шаманство. 0 – это не ноль, а 5% от памяти, занятой всеми процессами сервера на данный момент. Как это работает? Начинается сеанс пользователя, либо какое-то соединение. Механика фиксирует, сколько всего оперативной памяти мы на данный момент занимаем всеми рабочими процессами. Например, сейчас мы занимаем 10 гигабайт, а общее ограничение по кластеру у нас 11 гигабайт. Параллельно механика для каждого вызова считает, сколько памяти он займет – раз в две секунды она эту информацию обновляет. И в какой-то момент может оказаться, что вызов займет 3, 4, 5, 6 гигабайт. Такое бывает – либо программист ошибся, либо пользователь не наложил правильные отборы – у него выводится, что попало, и на это тратятся гигабайты оперативной памяти. Система проверяет, не превышает ли изначальный объем оперативной памяти на весь кластер, плюс память на этот вызов сумму максимального объема памяти на кластер и максимального расхода памяти на вызов. Если превышает, то этот сеанс будет завершен. Не rphost, как в настройках кластера 1С, где мы просто завершаем rphost при совпадении ситуации, когда он выбрал лимит оперативной памяти. Здесь будет завершен конкретный сеанс пользователя, т.е. конкретный главный бухгалтер получит ошибку «Сеанс завершен администратором». Это очень удобно, чтобы протестировать, где у вас программист написал неправильный отчет. Один и тот же пользователь будет постоянно жаловаться на то, что этот отчет никогда не формируется. При этом остальные пользователи даже не заметят, что что-то произошло, и система продолжит стабильно работать.
Еще одна «сладкая» настройка для стабильности и спокойного сна администраторов – это «Объем памяти рабочих процессов, до которого сервер считается производительным». Здесь 0 – это настоящий 0, т. е. мы этот объем памяти вообще не контролируем. Здесь можно указать тот лимит памяти, при котором выборы механикой сервера, куда назначать сеанс, закончатся неудачей для сервера, если он уже израсходовал столько оперативной памяти, сколько мы ему указали. Например, мы, согласно своему опыту, считаем, что этот сервер не может быть работоспособен, если он уже израсходовал 40 гигабайт оперативной памяти. И, если вы сюда это указали, то, несмотря ни на какие проверочные тесты, в которых он показывает механике сервера, что он быстрый и готовый, на него сеансы назначаться не будут, если он этот лимит превысил.
Следующие настройки, которые почему-то все любят менять, – это «Количество информационных баз на процесс» и «Количество соединений на процесс» (не путать с количеством сеансов – именно количество соединений на процесс). В принципе, эти настройки уже нормально отрегулированы по умолчанию. Rphost давным-давно многопоточный, 64-битный и обслуживать 128 сеансов либо 8 баз данных не является проблемой. При этом «Количество соединений на процесс» можно менять и при ПРОФ лицензии.
Могу еще сказать, что никакие настройки кластера или сервера 1С не заставят вашу 1С работать быстрее. Все настройки необходимы исключительно для того, чтобы система в целом работала стабильнее, а не быстрее. Быстрее – это вопрос к программисту, пусть код переписывает. Либо к DBA – пусть сервер базы данных настраивает. Все настройки сервера 1С касаются только стабильности и отказоустойчивости. Никакая настройка не действует на скорость. Сервер 1С всегда пытается выдать максимальную скорость математики. Он ничего не скрывает, не работает вполсилы, он просто старается этими настройками сделать крепче сон администратора, и чтобы у него не сдавали нервы.
Настройка инфраструктуры с сервером программного лицензирования 1С
Следующий момент – это сервер программного лицензирования. До сих пор на практике мы встречаемся с высказываниями: «Ой-ой, только не программная лицензия, они все слетают, а весь мир виртуальный, 1С это тоже не обошло».
Да, мы все давно ушли в виртуальность. Да, известная проблема, что если виртуалка по отношению к своим ресурсам динамическая, то программная лицензия будет «слетать». Чтобы этого избежать, и был сделан сервер программного лицензирования.
Первая его особенность – он не требует себе серверные лицензии. Фактически, это полностью бесплатная вещь. Просто поставьте сервер 1С и настройте «Требования назначения».
Вторая его особенность, которую мы вывели на практике, – не злоупотребляйте тем, чтобы сервер программного лицензирования выдавал серверные лицензии. Пусть он выдает только клиентские лицензии. Почему? Если у вас высоконагруженная система, более 1000 пользователей, и вы сделаете так, что у вас сервер программного лицензирования серверу 1С выдает его серверную лицензию, то при каждом серверном вызове этих 1000 пользователей, сервер 1С будет запрашивать у сервера программного лицензирования свою лицензию, проверять есть или нет. В итоге, сервер программного лицензирования не справится с нагрузкой – и сеть «ляжет», и процессоры «лягут», и вся система хором «ляжет». Поэтому нагружать сервер лицензирования программными серверными лицензиями не надо. А клиентские лицензии он выдает очень успешно, поскольку они выдаются гораздо реже. 1000 штук – не проблема.
Настроить сервер лицензирования – это всего лишь пара «Требований назначения функциональности».
Что первое мы должны указать? Раз у него собственной лицензии нет, мы должны для него указать, что этот сервер для всех сервисов «Не назначать». Чтобы, когда механика сервера делала выбор, куда ей назначить данное соединение или сервер, она ни в коем случае не назначила его на сервер лицензирования (поскольку для клиентского соединения нужна программная лицензия, а у сервера лицензирования ее нет). Если вы так не настроите, механика сервера в какой-то момент выберет его из-за высокой производительности, запустит туда бухгалтера, и он получит ошибку «Отсутствует программная лицензия сервера».
Вторая настройка, которую нужно сделать в «Требовании назначения функциональности» – это, наоборот, назначить ему и только ему сервис лицензирования. В кластере в идеале может быть только один сервер лицензирования. Можете сделать и два с разными приоритетами, но особого смысла в этом нет, поскольку программная лицензия – это не HASP, можно и 300 файлов положить, и ничего страшного не случится.
Единственный момент, который нужно соблюсти, когда вы в свою инфраструктуру встраиваете сервер лицензирования – это стабильное «железо».
- Это может быть локальная машина.
- Либо это может быть виртуалка, но тогда у нее должны быть заданы полностью статические параметры.
- Либо у вас может быть настроен отказоустойчивый кластервиртуальных машин, где виртуалки переезжают с одного хоста на другой. В этом случае на этих хостах должно быть все одинаково, вплоть до модели процессора.
Если сервер лицензирования переедет на другую модель процессора, то вы, несмотря на то, что в параметрах виртуалки все вроде бы статично, получите ошибку программного лицензирования.
Во всех последних версиях платформы: 8.3.10 и 8.3.9 (начиная с версии 2170) есть защитный механизм, который немного спасает в таких случаях. Если лицензия сбросилась из-за смены железа на сервере лицензирования, 1С еще сутки будет работать. Ровно через сутки она выдаст ошибку, что время вышло и теперь сервер нужно перелицензировать. После переактивации пин-кода сервера для новых параметров системы можно счастливо пользоваться 1С дальше.