1с swpuser ini настройка
Check-list по настройке рабочих серверов в продукционной зоне
В этой статье приводится инструкция check-list, который является рекомендуемым при настройке крупных информационных систем.
Также в статье приводится набор скриптов, которые оказались полезны при эскплуатации.
- Настроен сбор технологических журналов на всех продукционных рабочих серверах с платформой 1С:Предприятие.
- директория ALL (события EXCP, PROC, CONN, SESN, CLSTR, SRVC, ADMIN);
- директория CALLSCALL (события CALL, SCALL);
- Сбор дампов аварийных завершений процессов кластера.
Настройка выполняется с помощью файла logcfg.xml.
Пример настройки технологического журнала.
В данном примере события CALL и SCALL собираются без контекстов, что в значительной мере сокращает объем собираемых журналов. Однако в некоторых случаях контексты необходимы.
необходимо будет удалить.
Обратите внимание, что history="28" указан равным 28 часам, что при достаточно интенсивной нагрузке может привести к сбору достаточно большого объема журналов.
Если места на дисках не достаточно, лучше отказаться от журнала с CALL, SCALL, а сбор «основного» журнала "C:\LOGS\All"сократить до 12 часов.
Следует также настроить архивирование технологических журналов с последующим копированием на сетевой ресурс.
- Настроен сбор счетчиков Performance Monitor на всех продукционных серверах.
Запуск счетчика добавлен в Task Schedule.
- Настроен Windows Error Reporting Service на процессы ragent, rmngr, rphost.
Инструкция по настройки дампов находится здесь.
- На рабочих серверах есть только продукционные кластеры с продукционными базами.
Другие (не рабочие) базы и кластеры должны отсутствовать.
«Исключением» из данного правила могут являться «обслуживающие» (хотя всё же продукционные) информационные базы, такие как:
- Центр Контроля Качества;
- Центр Управления Производительностью;
- Менеджер Сервиса;
- Агент Сервиса;
Обратите внимание, что не должно быть
- развернутых копий продукционных информационных баз;
- тестовых информационных баз;
- информационных баз разработки.
Ограничения по безопасному расходу памяти либо «По умолчанию», либо имеют такие значения, при которых они действительно могут сработать на конкретном оборудовании.
Не должно быть установлено таких значений, которые «отключают» работу механизмов контроля потребления памяти на вызов.
в определенной директории, например, C:\Utils
Ярлык на эту директорию должен быть на рабочем столе.
- Наличие скриптов автоматизации в определенной директории.
Ярлык на эту директорию должен быть на рабочем столе.
Примеры скриптов приведены в конце статьи.
- Настроена контрольная процедура «Контроль подключений» для всех продукционных баз в Центре Контроля Качества.
- Настроена контрольная процедура «Контроль потребления памяти» для всех продукционных баз в Центре Контроля Качества.
- Настроен сбор данных по загруженности оборудования для всех серверов продукционной площадки в ЦКК из Мастера настройки в ЦКК.
У пользователя ОС, от которого запущен rphost, вхождение в группу Windows Performance Monitor Users.
- По месту на дисках для всех продукционных серверов: меньше 10% места за 5 минут;
- По памяти для всех продукционных серверов (кроме СУБД): меньше 200 Мб памяти за 5 минут;
- По CPU для всех продукционных серверов: более 90% за 5 минут;
- Для СУБД по превышению размера tempdb (SQL Tempdb Log Used Size (MB) [среднее]) более 70 Гб (нужно убедиться в снятом ограничении по размеру tempdb в настройках СУБД).
- Проведен успешный тест отправки e-mail или смс из рабочего Центра Контроля Качества.
Если тест успешно не выполняется (т.е. смс или письмо не приходят), но проверять наличие доступа к соответствующим серверам.
- На веб серверах настроен сбор access и error логов IIS или Apache.
- Обновление статистик;
- Очистка процедурного КЭШа;
- Дефрагментация индексов;
- Реиндексация таблиц базы данных;
- Создание бэкапов.
- Установлен Windows Performance Toolkit на всех рабочих (1С) Windows серверах.
Windows Performance Toolkit входит в комплект Windows 8.1 SDK.
После установки проверяется возможность запустить Windows Performance Recorder с опцией “Resource Analysis”\”CPU Usage” на несколько секунд.
- Наличие файла swpuser.ini с указанием пользователя для рабочих процессов с соответствующими правами в ОС.
При использовании файла swpuser.ini пользователь, от имени которого работает главный агент кластера (ragent), должен иметь административные права. Дополнительно следует обеспечить наличие этого пользователя в локальных политиках безопасности: Adjust memory quotas for a process (сюда обычно входит группа Администраторы) и Replace a process level token (обычно группа Администрторы сюда не входит). Необходимо помнить, что инсталятор не подготавливает почву для использования swpuser.ini. Поэтому для использования swpuser.ini все предлагаетя сделать руками: создать пользователей, дать им права и т. п. Важно, что пользователям, от которых запускаются рабочие процессы и менеджеры кластера, в Windows должен быть создан профиль. Он необходим для правильного размещения:
- каталога временных файлов;
- каталога данных приложения;
- переменных окружения.
Наиболее простой способ создания профиля - однократный интерактивный вход.
- Наличие требований назначения функциональности для всех продукционных кластеров с двумя и более рабочими серверами
- Для сервиса лицензирования;
- Для сервиса полнотекстового поиска данных;
- Для сервиса журнала регистрации.
Должно быть явно указано расположение именно этих сервисов, т.к. их корректная работа зависит от расположения файлов кластера. При наличии нескольких рабочих серверов в кластере нужно не допускать возможность переезда этих сервисов между рабочими серверами.
- Имена пользователей, от которых рабочие процессы rphost работают с СУБД, в точности соответствуют именам информационных баз.
Лучше для каждой продукционной информационной базы создавать отдельного пользователя. Это нужно в первую очередь при расследовании каких-либо проблема на сервере СУБД. Если на сервере СУБД расположено более одной продукционной базы данных, может возникнуть необходимость максимально быстро расследовать проблему. При этом под рукой в отчетах или трассировках всегда будет имя пользователя, который в данный момент работает с сервером баз данных, как следствие будет и понимание, к какой именно информационной базе относится этот пользователь.
Желательно на рабочем столе всегда видеть:
- Имя сервера;
- Объем места на дисках;
- Его сетевые адресы.
- План электропитания: Высокая производительность.
В Control Panel\All Control Panel Items\Power Options необходимо указать "High Performance".
- Хотя бы один раз проведено тестовое восстановление из бэкапа с замером времени восстановления.
- Настроен пересчет итогов, перестроение агрегатов.
- Отсутствует лишняя регистрация изменений в планах обмена.
- Число процессов rphost адекватно решаемой кластром задачи.
Например, не установлена настройка 1 rphost на 1 информационную базу при наличии большого числа информационных баз в кластере серверов.
Корректно сконфигурированные виртуальные машины.
На виртуальных машинах обеспечено гарантированное выделение ресурсов, суммарный объем выданной оперативной памяти в виртуальных машинах, меньше объема имеющейся памяти на хосте.
- Для работы системы «1С:Предприятие» c СУБД MS SQL Server
требуется установленный SQL ServerNativeClientfor SQL Server 2005 (и более старших версий Microsoft SQL Server). Проверка наличия установленного SQL ServerNativeClientосуществляется при выполнении следующих операций:
- создание информационной базы;
- загрузка информационной базы;
- обновление конфигурации базы данных.
Немедленно завершить приложения.
Получить дампы процессов.
Этот скрипт должен выполняться из той же директории, в которой находится procdump.exe
Остановка службы 1С:Предприятие с очисткой временных файлов.
Запуск службы 1С:Предприятие
Рестарт с очисткой временых файлов
Аварийное завершение процесса rphost, который потребляет больше N Гб памяти
N сильно зависит от вашей системы, нагрузки, конфигурации и т.д. В этом примере N = 8 Гб.
Check-list по настройке рабочих серверов в продукционной зоне
В этой статье приводится инструкция check-list, который является рекомендуемым при настройке крупных информационных систем.
Также в статье приводится набор скриптов, которые оказались полезны при эскплуатации.
- Настроен сбор технологических журналов на всех продукционных рабочих серверах с платформой 1С:Предприятие.
- директория ALL (события EXCP, PROC, CONN, SESN, CLSTR, SRVC, ADMIN);
- директория CALLSCALL (события CALL, SCALL);
- Сбор дампов аварийных завершений процессов кластера.
Настройка выполняется с помощью файла logcfg.xml.
Пример настройки технологического журнала.
В данном примере события CALL и SCALL собираются без контекстов, что в значительной мере сокращает объем собираемых журналов. Однако в некоторых случаях контексты необходимы.
необходимо будет удалить.
Обратите внимание, что history="28" указан равным 28 часам, что при достаточно интенсивной нагрузке может привести к сбору достаточно большого объема журналов.
Если места на дисках не достаточно, лучше отказаться от журнала с CALL, SCALL, а сбор «основного» журнала "C:\LOGS\All"сократить до 12 часов.
Следует также настроить архивирование технологических журналов с последующим копированием на сетевой ресурс.
- Настроен сбор счетчиков Performance Monitor на всех продукционных серверах.
Запуск счетчика добавлен в Task Schedule.
- Настроен Windows Error Reporting Service на процессы ragent, rmngr, rphost.
Инструкция по настройки дампов находится здесь.
- На рабочих серверах есть только продукционные кластеры с продукционными базами.
Другие (не рабочие) базы и кластеры должны отсутствовать.
«Исключением» из данного правила могут являться «обслуживающие» (хотя всё же продукционные) информационные базы, такие как:
- Центр Контроля Качества;
- Центр Управления Производительностью;
- Менеджер Сервиса;
- Агент Сервиса;
Обратите внимание, что не должно быть
- развернутых копий продукционных информационных баз;
- тестовых информационных баз;
- информационных баз разработки.
Ограничения по безопасному расходу памяти либо «По умолчанию», либо имеют такие значения, при которых они действительно могут сработать на конкретном оборудовании.
Не должно быть установлено таких значений, которые «отключают» работу механизмов контроля потребления памяти на вызов.
в определенной директории, например, C:\Utils
Ярлык на эту директорию должен быть на рабочем столе.
- Наличие скриптов автоматизации в определенной директории.
Ярлык на эту директорию должен быть на рабочем столе.
Примеры скриптов приведены в конце статьи.
- Настроена контрольная процедура «Контроль подключений» для всех продукционных баз в Центре Контроля Качества.
- Настроена контрольная процедура «Контроль потребления памяти» для всех продукционных баз в Центре Контроля Качества.
- Настроен сбор данных по загруженности оборудования для всех серверов продукционной площадки в ЦКК из Мастера настройки в ЦКК.
У пользователя ОС, от которого запущен rphost, вхождение в группу Windows Performance Monitor Users.
- По месту на дисках для всех продукционных серверов: меньше 10% места за 5 минут;
- По памяти для всех продукционных серверов (кроме СУБД): меньше 200 Мб памяти за 5 минут;
- По CPU для всех продукционных серверов: более 90% за 5 минут;
- Для СУБД по превышению размера tempdb (SQL Tempdb Log Used Size (MB) [среднее]) более 70 Гб (нужно убедиться в снятом ограничении по размеру tempdb в настройках СУБД).
- Проведен успешный тест отправки e-mail или смс из рабочего Центра Контроля Качества.
Если тест успешно не выполняется (т.е. смс или письмо не приходят), но проверять наличие доступа к соответствующим серверам.
- На веб серверах настроен сбор access и error логов IIS или Apache.
- Обновление статистик;
- Очистка процедурного КЭШа;
- Дефрагментация индексов;
- Реиндексация таблиц базы данных;
- Создание бэкапов.
- Установлен Windows Performance Toolkit на всех рабочих (1С) Windows серверах.
Windows Performance Toolkit входит в комплект Windows 8.1 SDK.
После установки проверяется возможность запустить Windows Performance Recorder с опцией “Resource Analysis”\”CPU Usage” на несколько секунд.
- Наличие файла swpuser.ini с указанием пользователя для рабочих процессов с соответствующими правами в ОС.
При использовании файла swpuser.ini пользователь, от имени которого работает главный агент кластера (ragent), должен иметь административные права. Дополнительно следует обеспечить наличие этого пользователя в локальных политиках безопасности: Adjust memory quotas for a process (сюда обычно входит группа Администраторы) и Replace a process level token (обычно группа Администрторы сюда не входит). Необходимо помнить, что инсталятор не подготавливает почву для использования swpuser.ini. Поэтому для использования swpuser.ini все предлагаетя сделать руками: создать пользователей, дать им права и т. п. Важно, что пользователям, от которых запускаются рабочие процессы и менеджеры кластера, в Windows должен быть создан профиль. Он необходим для правильного размещения:
- каталога временных файлов;
- каталога данных приложения;
- переменных окружения.
Наиболее простой способ создания профиля - однократный интерактивный вход.
- Наличие требований назначения функциональности для всех продукционных кластеров с двумя и более рабочими серверами
- Для сервиса лицензирования;
- Для сервиса полнотекстового поиска данных;
- Для сервиса журнала регистрации.
Должно быть явно указано расположение именно этих сервисов, т.к. их корректная работа зависит от расположения файлов кластера. При наличии нескольких рабочих серверов в кластере нужно не допускать возможность переезда этих сервисов между рабочими серверами.
- Имена пользователей, от которых рабочие процессы rphost работают с СУБД, в точности соответствуют именам информационных баз.
Лучше для каждой продукционной информационной базы создавать отдельного пользователя. Это нужно в первую очередь при расследовании каких-либо проблема на сервере СУБД. Если на сервере СУБД расположено более одной продукционной базы данных, может возникнуть необходимость максимально быстро расследовать проблему. При этом под рукой в отчетах или трассировках всегда будет имя пользователя, который в данный момент работает с сервером баз данных, как следствие будет и понимание, к какой именно информационной базе относится этот пользователь.
Желательно на рабочем столе всегда видеть:
- Имя сервера;
- Объем места на дисках;
- Его сетевые адресы.
- План электропитания: Высокая производительность.
В Control Panel\All Control Panel Items\Power Options необходимо указать "High Performance".
- Хотя бы один раз проведено тестовое восстановление из бэкапа с замером времени восстановления.
- Настроен пересчет итогов, перестроение агрегатов.
- Отсутствует лишняя регистрация изменений в планах обмена.
- Число процессов rphost адекватно решаемой кластром задачи.
Например, не установлена настройка 1 rphost на 1 информационную базу при наличии большого числа информационных баз в кластере серверов.
Корректно сконфигурированные виртуальные машины.
На виртуальных машинах обеспечено гарантированное выделение ресурсов, суммарный объем выданной оперативной памяти в виртуальных машинах, меньше объема имеющейся памяти на хосте.
- Для работы системы «1С:Предприятие» c СУБД MS SQL Server
требуется установленный SQL ServerNativeClientfor SQL Server 2005 (и более старших версий Microsoft SQL Server). Проверка наличия установленного SQL ServerNativeClientосуществляется при выполнении следующих операций:
- создание информационной базы;
- загрузка информационной базы;
- обновление конфигурации базы данных.
Немедленно завершить приложения.
Получить дампы процессов.
Этот скрипт должен выполняться из той же директории, в которой находится procdump.exe
Остановка службы 1С:Предприятие с очисткой временных файлов.
Запуск службы 1С:Предприятие
Рестарт с очисткой временых файлов
Аварийное завершение процесса rphost, который потребляет больше N Гб памяти
N сильно зависит от вашей системы, нагрузки, конфигурации и т.д. В этом примере N = 8 Гб.
Хочу рассмотреть вопросы и подготовку к сертификации. Учить правильные ответы плохой путь, а вот понимать ответы и применять их, вы тем самым становитесь на путь к уровню «1С:Эксперт». По сути это цикл записей с расширенными ответами на несколько вопросов из тестов.
Файл swpuser.ini предназначен для переопределения пользователей, от имени которых будут выполняться рабочие процессы и менеджер кластера. По умолчанию рабочий процесс и менеджер кластера выполняются от имени того же пользователя, что и агент сервера. Файл swpuser.ini располагается в каталоге реестра кластера, формат файла swpuser.ini:
Точно определить список рабочих процессов кластера можно с помощью консоли кластера 1С и диспетчера задач, а если быть совсем точным использовать пересечение списков. Причиной может быть, что рабочий процесс существует в консоли кластера, но в тоже время отсутствует в диспетчере задач (процесс не активен) и наоборот, в случае непредвиденной ситуации при завершении процесса rphost.exe.
Наиболее верный вариант перезапуска рабочих процессов 1С (rphost.exe) настроить их автоматический перезапуск с помощью консоли кластера 1С. Две кратких статьи по теме — один, два. Другие варианты, указанные как ответы, могут привести к непредсказуемым последствиям.
Для рабочих процессов, которые зависли, дамп нельзя сформировать с помощью logcfg.xml. Снять дамп можно с помощью утилиты ProcDump указав флаг -ma (записать дамп памяти процесса), имя процесса или PID процесса. Детально об утилите можно почитать на сайте.
Для учета статистики аварийных завершений процессов можно использовать «Центр контроля качества». Все остальные варианты предложенные, как ответы, годятся для сбора дампов, но не для учета статистики. Полную информацию об «Центре контроля качества» можно почерпнуть из книги «1С:Корпоративный инструментальный пакет», версия 2.0, руководство по использованию с.205.
Инструкция по настройке рабочих серверов с Технологической Платформой 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. Убедиться, что брадмауэр операционной системы настроен таким образом, что не запрещает процессам кластера взаимодействовать корректно.
Информация по клиент-серверному варианту работы здесь;
Обратите внимание на используемые порты, которые указываются в параметрах центрального сервера,
в свойствах кластера серверов,
и рабочих серверов кластера.
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. Настроить защиту от вирусов.
В случае расположения рабочих серверов кластера в зоне, к которой доступ строго ограничен, не имеет смысл настраивать антивирусные решения на рабочих серверах.
Настройка антивирусных решений на таких серверах будет оказывать существенное влияние на производительность при практическом отсутствии выигрыша с точки зрения защиты.
При этом, стоит обеспечить защиту антивирусными решениями те пользовательские компьютеры, с которых выполняется доступ к рабочим серверам кластера и сетевым директориям.
Читайте также:
