Кластер Серверов Dr.Web |
При создании в антивирусной сети кластера Серверов Dr.Web необходимо выполнение следующих предписаний: 1.Одинаковые конфигурационные файлы На всех Серверах должны быть одинаковые ключи шифрования drwcsd.pub и drwcsd.pri. Если ключи шифрования ранее не создавались, то в ходе установки первого Сервера кластера ключи шифрования будут сформированы автоматически. Получить необходимые ключи шифрования для установки последующих Серверов кластера можно через Центр управления: меню . При этом в зависимости от того, как в дальнейшем будет разворачиваться кластер, могут потребоваться или оба ключа, или только drwcsd.pri: •При задании закрытого ключа drwcsd.pri во время установки Сервера, открытый ключ drwcsd.pub формируется автоматически. •Если не задать нужный закрытый ключ при установке Сервера, то после установки необходимо заменить оба ключа вручную.
2.Единое имя Сервера Для всех Серверов должны быть заданы одинаковые IP-адрес или DNS-имя Сервера, используемые при формировании файлов инсталляции Агента для станций антивирусной сети. Данное имя задается через Центр управления: → вкладка → вкладка Загрузка → поле . Настройки этого раздела хранятся в конфигурационном файле download.conf (описание файла приведено в документе , в п. G3. Конфигурационный файл download.conf). 3.Настройка использования кластера На DNS сервере в сети необходимо зарегистрировать общее имя кластера для каждого отдельного Сервера и задать метод балансировки нагрузки. Для автоматического применения настроек в кластере Серверов Dr.Web необходимо использование специального кластерного протокола. Для настройки кластерного протокола необходимо для каждого из Серверов в Центре управления перейти в меню и задать следующие настройки: a)Для включения кластерного протокола на вкладке Модули установите флаг . b)Для настройки параметров взаимодействия Серверов в составе кластера на вкладке Кластер задайте соответствующие параметры. c)После задания всех необходимых параметров, нажмите и перезагрузите Серверы.
•Multicast-группа: 232.0.0.1 •Порт: 11111 •Интерфейс: 0.0.0.0 В данном примере для всех Серверов кластера настраиваются транспорты для всех интерфейсов. В иных случаях, например, когда одна из сетей является внешней для кластера, и через нее подключаются Агенты, а вторая сеть является внутрикластерной, то кластерный протокол лучше открывать только для интерфейсов внутренней сети. В этом случае в качестве интерфейсов необходимо задавать адреса вида 192.168.1.1, ..., 192.168.1.N. 4.Единая база данных
Все Серверы Dr.Web в пределах одного кластера должны работать с единой внешней базой данных. Как и в случае использования базы данных без организации кластера, каждый из Серверов обращается к базе данных независимо, и все данные Серверов хранятся раздельно. Везде, где это актуально, Сервер забирает из базы данных только записи, привязанные к его ID, который является уникальным для каждого Сервера. Использование единой базы данных позволяет Серверам работать с Агентами, изначально зарегистрированными на других Серверах кластера. При создании кластера Серверов с единой базой данных необходимо учитывать следующие особенности: •База данных может быть установлена как отдельно от всех Серверов, так и на одном из компьютеров, на котором установлен Сервер кластера. •База данных должна быть создана до установки первого Сервера кластера или до момента подключения первого Сервера к базе данных. •В процессе добавления новых узлов в кластер (за исключением первого Сервера), при установке Серверов не рекомендуется сразу задание единой базы данных, которая используется в данном кластере. Иначе это может привести к удалению информации, уже хранящейся в базе данных. Рекомендуется устанавливать Серверы изначально с внутренней базой данных, а после установки переключать их на единую внешнюю базу данных. •За исключением первого Сервера кластера, не рекомендуется вводить в кластер Серверы, уже функционирующие в антивирусной сети с иной внешней или внутренней базой данных. Это приведет к потере данных: информации о станциях, статистике, настройках (за исключением настроек, хранящихся в конфигурационных файлах), так как при импорте данные в базе полностью удаляются. В данном случае возможен только частичный импорт некоторых настроек. 5.Одна версия репозитория На всех Серверах кластера репозитории должны содержать обновления одной и той же версии. Достижение данного требования возможно одним из следующих способов: •Одновременно обновлять все Серверы кластера с ВСО. В данном случае все Серверы будут содержать самую последнюю версию обновлений. Обновление репозиториев всех Серверов также возможно настроить с локальной зоны обновлений, с которой будет раздаваться одна и та же подтвержденная версия обновлений продуктов, или же самая последняя в случае создания зеркала ВСО. •Допускается создание гибридной структуры, сочетающей в себе как кластер Серверов, так и иерархическую структуру на основе межсерверных связей. При этом один из Серверов (может быть как Сервером кластера, так и не входящим в кластер) назначается главным и получает обновления с ВСО. Остальные Серверы кластера – подчиненные – получают обновления с главного Сервера по межсерверным связям. В случае настройки обновления Серверов кластера с локальной зоны (зеркала ВСО) или с главного Сервера необходимо следить за функционированием этой зоны или главного Сервера. В случае выхода из строя узла, раздающего обновления, необходимо перенастроить один из других Серверов на роль главного Сервера или создать новую зону обновлений для получения обновлений с ВСО соответственно. 6.Особенности распределения лицензий для станций Для распределения лицензий между Серверами кластера могут использоваться следующие подходы: a)Создание гибридной структуры, сочетающей в себе как кластер Серверов, так и иерархическую структуру на основе межсерверных связей. Подобная структура будет полезна, если при обслуживании Агентов в пределах кластерной системы Серверов осуществляется динамическое распределение станций между Серверами кластера. В этом случае осуществляется распространение необходимого количества лицензий от главного Сервера (может быть как Сервером кластера, так и не входящим в кластер) подчиненным Серверам по межсерверной связи непосредственно в процессе работы. Таким образом, достаточно расположения на главном Сервере одного лицензионного файла с количеством лицензий, соответствующем общему количеству обслуживаемых станций, и распределение необходимого количества лицензий на подчиненные Серверы в процессе работы кластера. Настройка раздачи подчиненным Серверам необходимого количества лицензий на необходимый срок осуществляется вручную администратором антивирусной сети. Для настройки распространения лицензий на соседние Серверы воспользуйтесь Менеджером лицензий. Например, можете настроить иерархическую структуру Серверов и выделить главный Сервер (может быть как Сервером кластера, так и не входящим в кластер), который будет раздавать как обновления репозитория, так и лицензии из лицензионного файла всем узлам кластера. b)При отказе от настройки иерархической структуры Серверов, возможность разделения лицензий из единого лицензионного файла между всеми Серверами отсутствует. В таком случае необходимо заранее планировать структуру антивирусной сети с учетом наличия кластера Серверов и использовать несколько лицензионных файлов – по одному на каждый Сервер кластера. Общее количество лицензий во всех лицензионных файлах приравнивается к общему количеству станций в сети, однако распределение количества лицензий по Серверам кластера необходимо рассчитать заранее, исходя из предполагаемого количества станций, которые планируется подключать к каждому из Серверов. 7.Задания в расписании Серверов Чтобы исключить дублирование запросов к БД, рекомендуется выполнять только на одном из Серверов следующие задания из расписания Сервера: , , , , . Например, на Сервере, который расположен на том же компьютере, что и единая внешняя база данных. Или на наиболее производительном компьютере кластера, если конфигурации Серверов различаются, и база данных установлена на отдельном компьютере. |