Установка Drweb Enterprise Suite 4.44 beta с PostgreSQL 8.2.5 под Windows 2000

Материал из wiki.drweb.com
Перейти к: навигация, поиск

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) со следующими ограничениями: 1 процессор, 1 Гб памяти, 4 Гб данных.

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

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

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

специально для Drweb Enterprise Suite.

  • Настраиваем ODBC источник данных.
  • Устанавливаем Drweb Enterprise Suite согласно инструкции.

Описание процесса установки

  • Скачиваем PostgreSQL. На подходе 8.3 (на момент написания beta4)
  • Для доступа к бета версиям Dr.Web® нужна регистрация
  • Скачиваем сервер
  • Скачиваем консоль
  • Ставим PostgreSQL в d:\postgresql, кластер - в e:\pg_cluster
    • Выбираем язык
      Inst beta drwebes postgresql 01.png
    • Выбираем куда ставить сервер
      Inst beta drwebes postgresql 02.png
    • Выбираем где будет расположен кластер сервера
      Inst beta drwebes postgresql 03.png
    • Убираем лишние драйвера - оставляем только ODBC
      Inst beta drwebes postgresql 04.png
    • Задаем пароль для учетной записи сервиса (домен в данном случае просто имя вашего компьютера)
      Inst beta drwebes postgresql 05.png
    • Ставим локацию, кодировку и пароль для пользователя БД postgres (фактически администратора БД)
      Inst beta drwebes postgresql 06.png
    • Это оставляем как есть
      Inst beta drwebes postgresql 07.png
    • Это оставляем как есть
      Inst beta drwebes postgresql 08.png
  • После инсталяции переходим в каталог bin сервера (в данном случае d:\postgresql\bin) и запускаем pgadmin3.exe. В дереве слева, щелкаем по серверу, вводим пароль пользвателя postgres и видим примерно такую картину:
    Inst beta drwebes postgresql 09.jpg
    Если так, то все ОК - сервер установлен и запущен.
  • Создаем пользователя БД, табличное пространство и базу в нём, специально для 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. Т.е. мы таким образом задаем схему пользователя "по умолчанию"
  • Выглядеть это будет примерно так:
    Inst beta drwebes postgresql 10.png
  • Если все правильно, то должна получиться подобная структура:
    Inst beta drwebes postgresql 11.jpg
  • Настраиваем ODBC источник данных.
    • Открываем Start->Programs-> Administartive Tools-> DataSources (ODBC). Переходим на закладку System DSN.
      Inst beta drwebes postgresql 12.png
    • Выбираем драйвер PostgreSQL ANSI
      Inst beta drwebes postgresql 13.png
    • Заполняем параметры. Логин и пароль нужен ТОЛЬКО ДЛЯ ТЕСТИРОВАНИЯ (кнопка Test). После проверки подключения логин и пароль желательно убрать.
      Inst beta drwebes postgresql 14.png
  • Устанавливаем Drweb Enterprise Suite согласно инструкции.
    • В данном диалоге нажимаем кнопку База...
      Inst beta drwebes postgresql 15.jpg
    • Выбираем ODBC и заполняем параметры.
      • DSN - имя источника данных из п. 5.
      • Логин и пароль - пользователя БД PostgreSQL из п. 4.
Inst beta drwebes postgresql 16.jpg
  • После установки, видно что таблицы созданы и созданы в нужной схеме.
    Inst beta drwebes postgresql 17.jpg

Что мы получаем в теории, использовав PostgreSQL

(что покажет опыт эксплуатации посмотрим через год)

  • бОльшую надежность и устойчивость БД к различным непредвиденным ситуациям
  • бОльшую производительность
  • бОльшую масштабируемость (в случае необходимости)
  • возможность изучать структуру и проверять состояние БД Drweb ES стандартными SQL средствами
  • хорошо документированый сервер БД

Некоторые настройки 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.

Ссылки