Карта сайта-> Software->Антивирусы->Установка Drweb Enterprise Suite 4.44 beta + PostgreSQL 8.2.5 (Windows 2000 AS)

12.12.2007

Если есть возможность, то лучше устанавливать DrWeb ES с PostgreSQL на ОС Linux, чем на Windows. DrWeb ES изначально разработан под *nix, как и PostgreSQL и только позже они были портированы под Windows. Т.е. *nix - "родная" ОС этих серверов. И в частности Linux,как ОС, имеет ряд преимуществ перед Windows, как минимум в плане более грамотного сетевого стека. Поэтому, если у вас планируется большая сеть - более сотни станций - вам прямая дорога на вариант Linux+DrwebES+PostgreSQL.

Полтора года эксплуатации DrWebES с IntDB под Windows показали, что встроенная БД плохо "переносит" крахи ОС. Если вы думаете, что с вами этого не может произойти, потому что у вас есть UPS, то вы ошибаетесь. Причин много. Начнем с того что с UPS'ом тоже может произойти все что угодно. Можно случайно или ошибочно выдернуть не тот шнур питания, нажать RESET и т.п. ОС, драйвера, firmware, приложения - это миллионы строк кода, в которых полно багов. Никто вам не гарантирует, что даже при правильных драйверах и последних обновлениях ОС, все это не рухнет в любой момент. Ну и железо - проверенное серверное железо с дублированием очень дорого - поэтому большинство используют обычные компьютеры или простенькие сервера. Все это тоже не застраховано от сбоев. Короче - надо исходить из ненадежности и возможности отказа всех компонентов, находящихся "ниже" приложения.

Поэтому, даже для небольшой сети (50 станций в моем случае), лучше выбрать более устойчивый к крахам, сервер БД. Фактически, единственным, рекомендуемым и протестированным для DrWebES внешним сервером БД, является бесплатная PostgreSQL. В документации еще упоминается Oracle, но это достаточно тяжеловесная и дорогая БД.
Правда есть бесплатная версия OracleXE (и под Windows и под Linux)
http://www.oracle.com/technology/products/database/xe/index.html со следующими ограничениями:
1 процессор, 1 Гб памяти, 4 Гб данных.

Хотя... если у вас станций немного и настройки вы почти не меняете, то проще простого, в случае глюков пересоздать БД с нуля - станции просто снова подключатся к серверу и вы пропишете их в новой БД. Правда, как минмум, пропадет история инфекций, настройки конфигураций компонентов и расписаний сервера, групп и станций. Но если вы почти ничего не меняли - хрен с ними. А расписание недолго и руками подправить.



Короткий алгоритм установки Drweb Enterprise Suite 4.44 beta + PostgreSQL 8.2.5:

  1. Скачиваем PostgreSQL 8.2.5
  2. Скачиваем Drweb Enterprise Suite 4.44 beta
  3. Устанавливаем PostgreSQL 8.2.5 - понадобится примерно 45 Мб под сервер. Во время установки
    инициализируется кластер - набор баз данных, управляемых данным сервером.
    Под кластер потребуется примерно 35 Мб. Собственно БД, используемую сервером
    Drweb Enterprise Suite я рекомендую разместить в отдельной базе и в отдельном табличном пространстве.
    Так удобнее манипулировать БД в случаях необходимости: переносить на другие диски, бэкапить и т.п.
  4. В кластере PostgreSQL создаем пользователя БД, табличное пространство и базу в нём,
    специально для Drweb Enterprise Suite.
  5. Настраиваем ODBC источник данных.
  6. Устанавливаем Drweb Enterprise Suite согласно инструкции.


Подробнее

  1. Ну тут ничего сложного. На подходе 8.3 (на момент написания beta4)

    2. http://wwwmaster.postgresql.org/download/mirrors-ftp?file=%2Fbinary%2Fv8.2.5%2Fwin32%2Fpostgresql-8.2.5-1.zip

  2. Для доступа к бета версиям Drweb нужна регистрация

  3. Ставим PostgreSQL в d:\postgresql, кластер - в e:\pg_cluster

    3.1 Выбираем язык


    3.2 Выбираем куда ставить сервер


    3.3 Выбираем где будет расположен кластер сервера


    3.4 Убираем лишние драйвера - оставляем только ODBC


    3.5 Задаем пароль для учетной записи сервиса (домен в данном случае просто имя вашего компьютера)


    3.6 Ставим локацию, кодировку и пароль для пользователя БД postgres (фактически администратора БД)


    3.7 Это оставляем как есть


    3.8 Это оставляем как есть


    После инсталяции переходим в каталог bin сервера (в данном случае d:\postgresql\bin) и запускаем pgadmin3.exe. В дереве слева, щелкаем по серверу, вводим пароль пользвателя postgres и видим примерно такую картину:

    Если так, то все ОК - сервер установлен и запущен.



  4. Создаем пользователя БД, табличное пространство и базу в нём, специально для Drweb Enterprise Suite

    Для этого, находясь в каталоге bin сервера (ну или прописываем путь туда) выполняем из консоли (cmd) пять команд (каждая команда - одна строка, на запрос пароля вводим пароль пользователя БД postgres):
    psql --dbname postgres --username postgres --command "CREATE ROLE drwcs WITH NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT LOGIN ENCRYPTED PASSWORD 'drwcs'";
    Эта команда создает пользователя drwcs с паролем drwcs и минимумом прав. Под этим пользователем сервер DrwebES будет подключаться к серверу PostgreSQL.

    psql --dbname postgres --username postgres --command "CREATE TABLESPACE drwebes_ts OWNER postgres LOCATION 'e:/pg_drwebes';
    Эта команда создает табличное пространство drwebes_ts, которое будет располагаться в каталоге e:\pg_drwebes. Именно в нем, в дальнейшем, будет создана база DrwebES. Каталог e:\pg_drwebes на момент выполнения команды уже должен существовать. Обратите внимание: разделитель пути в команде "/", как в *nix, хотя мы под Windows!

    psql --dbname postgres --username postgres --command "CREATE DATABASE drwebes OWNER postgres ENCODING 'WIN1251' TABLESPACE drwebes_ts;"
    Эта команда собственно создает базу данных для DrwebES. База данных будет иметь кодировку Win1251 и будет расположена в табличном пространстве drwebes_ts. Т.е. физически она будет размещаться в каталоге e:\pg_drwebes.

    psql --dbname drwebes --username postgres --command "CREATE SCHEMA drwcs AUTHORIZATION drwcs;"
    Эта команда создает схему drwcs в базе данных drwebes. Обратите внимание, что мы подключаемся к базе drwebes (а не postgres), так как именно там мы хоти создать схему.

    psql --dbname postgres --username postgres --command "ALTER ROLE drwcs SET search_path to '$user', 'public'";
    Эта команда задает путь поиска объектов в базе данных. В данном случае это нужно для того, чтобы по умолчанию объекты пользователя drwcs создавались в его собственной схеме drwcs. Т.е. мы таким образом задаем схему пользователя "по умолчанию"

    Выглядеть это будет примерно так:

    Если все правильно, то должна получиться подобная структура:



  5. Настраиваем ODBC источник данных.

    Открываем Start->Programs-> Administartive Tools-> DataSources (ODBC). Переходим на закладку System DSN.


    Выбираем драйвер PostgreSQL ANSI


    Заполняем параметры. Логин и пароль нужен ТОЛЬКО ДЛЯ ТЕСТИРОВАНИЯ (кнопка Test). После проверки подключения логин и пароль желательно убрать.


  6. Устанавливаем Drweb Enterprise Suite согласно инструкции.

    В данном диалоге нажимаем кнопку База...


    Выбираем ODBC и заполняем параметры.
    DSN - имя источника данных из п. 5.
    Логин и пароль - пользователя БД PostgreSQL из п. 4.



После установки, видно что таблицы созданы и созданы в нужной схеме.

Что мы получаем в теории (что покажет опыт эксплуатации посмотрим через год), использовав PostgreSQL:


Некоторые настройки PostgreSQL, относящиеся к надежности и "выживанию" БД после крахов и сбоев ОС.

Файл конфигурации сервера находится в каталоге кластера (в данном примере e:\pg_cluster\postgresql.conf)

В связи с наличием:

данные, которые приложение отправило на диск (т.е. "записало"), на самом деле могут находиться в этих кэшах и не быть физически записанными на диск, до наступления определенных условий. Соответственно при сбоях в работе (крах ОС, отключение питания), данные которые, которые вроде уже должны были находиться на диске, теряются безвозвратно. Как следствие - нарушение целостности, потеря или повреждение данных. Для решения этой проблемы в PostgreSQL есть параметр fsync. Если

fsync = true

то PostgreSQL "просит" ОС физически сбросить данные (транзакцию) на диск. Таким образом, гарантируется восстановление кластера в целостном состоянии после краха ОС.

В связи с неатоммарностью самих операций записи блоков информации, размером более сектора (512 байт), в результате потери питания, может происходить неполная запись страниц на диск. Например, требуется записать 1024 байт связной информации: сначала записывается первый сектор 512 байт, потом - второй. Если диск потеряет питание после записи первого сектора и до окончании записи второго - то целостность 1024 байтного блока информации будет нарушена. Для решения этой проблемы PostgreSQL, перед тем как записать страницу данных на диск, может строить образ записываемой страницы на диске, потом сбрасывать страницу на диск. В случае сбоев, по предварительно записанному образу страницы, можно откатить либо закончить неполную операцию записи страницы. Включается этот режим так:

full_page_writes = true

Таким, образом, для обеспечения максимально возможной "выживаемости" БД во время крахов ОС или отключений питания надо установить:

fsync = true
full_page_writes = true

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

Выбор за вами - высокая надежность или высокая скорость.
Предлагаю начать с данного варианта, затем, в случае проблем - перейти к настройке производительности PostgreSQL: например, поиграть с настройками буферов, разнести по разным физическим дискам каталоги кластера, WAL каталог pg_xlog, табличное пространство с самой базой) и т.д. И уже как последнее средство - отключать эти опции.



Резервное копирование БД PostgreSQL

Резервную копию (дамп базы или кластера) можно делать прямо на работающей базе с помощью утилиты pg_dump. Например, чтобы создать бэкап только базы drwebes (а кластер вслучае сбоя просто пересоздать) в виде SQL-текста надо выполнить команду (pg_dump.exe находится в каталоге bin сервера):

pg_dump -U postgres drwebes > желаемый_путь\имя_файла_бэкапа

В сжатом бинарном формате:

pg_dump -U postgres -Fc drwebes > желаемый_путь\имя_файла_бэкапа

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

pg_dumpall -U postgres > желаемый_путь\имя_файла_бэкапа

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

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

Задать пароль пользователя PostgreSQL, под которым будет происходить бэкап, можно в файле %APPDATA%\postgresql\pgpass.conf, где %APPDATA% - подкаталог "Application Data" профиля того пользователя Windows, под которым будет выполняться бэкап утилитой pg_dump.

Файл должен содержать строчки следующего формата:
hostname:port:database:username:password

Например, для бэкапа с того же компьютера, где установлен сервер, любой базы, под пользователем postgres с паролем admin:
localhost:*:*:postgres:admin

Для восстановления сохраненной базы есть утилита pg_restore.

pg_restore -C -d postgres имя_файла_бэкапа

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

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



Ссылки

Документация PostgreSQL 8.2.5
http://www.postgresql.org/docs/8.2/interactive/index.html
http://www.postgresql.org/docs/8.2/interactive/libpq-pgpass.html (The Password File)

Performance Tuning PostgreSQL http://www.revsys.com/writings/postgresql-performance.html

Five Steps to PostgreSQL Performance http://www.powerpostgresql.com/download/TFCKUpload/5.x-pdf