Устанавливаем систему электронного документооборота самостоятельно

На этапе установки любой ИТ-системы возникает множество вопросов, на которые не может ответить ни одна инструкция, даже очень хорошая. Установка системы электронного документооборота (СЭД) не является исключением. У разных технических специалистов есть своя наработанная база в части работ по инсталляции продуктов. В этой статье речь пойдет о практиках, которые годятся для любой системы электронного документооборота и, в частности, о практиках инсталляции LanDocs.

Первый шаг любого администратора — запросить у производителя технические требования к оборудованию и программному обеспечению, которое требуется для работы внедряемой системы.

После получения технических требований и анализа собственной инфраструктуры многие заказчики приходят к пониманию того, что самым оптимальным является создание виртуальных машин для работы систем электронного документооборота. Это позволяет снизить затраты на покупку отдельных физических машин и, конечно же, в дальнейшем помогает в администрировании системы, так как обслуживать приходится фактически один или два физических сервера, на которых развернуты все решение.

Следующим шагом после подготовки серверов/виртуальных машин и установки на них операционных систем по требованию вендора является инсталляция системы управления базами данных (СУБД). Перечень СУБД, с которыми работают СЭД, разнообразен, но чаще всего используются СУБД MS SQL и СУБД PostgresPro. Оба производителя предлагают бесплатные версии своих СУБД (Express и Vanilla соответственно) с определенными ограничениями, но, учитывая объем данных и требования к системам, для сегмента средних и малых организаций их, как правило, вполне достаточно. Мы в своей практике предлагаем взаимодействие с обеими СУБД, что снижает затраты на внедрение.

Любой производитель СУБД имеет ряд рекомендаций к настройкам после инсталляции, и надо им обязательно следовать, поскольку чаще всего они относятся к быстродействию системы в целом. На основе практики крупных внедрений и внедрений в средних и малых компаниях мы подготовили четкий сценарий настроек СУБД. Так, настройка СУБД MS SQL Express содержит следующие необходимые шаги.

Являясь рабочим пространством для хранения временных объектов, база данных (БД) TempDB активно используется системой.

Добавление нескольких вторичных файлов данных позволит ослабить конкуренцию при выделении и освобождении страниц в TempDB. Необходимо добавить или создать нужное количество файлов данных БД TempDB из расчёта: суммарное количество равно половине числа ядер процессора на сервере СУБД (4 ядра — 2 TempDB, 8 ядер — 4 TempDB, и т.д.), при этом нужно оставить только 1 файл транзакций.

При добавлении вторичных файлов данных следует устанавливать для всех файлов данных одинаковый начальный размер и размер приращения (в фиксированной величине в МБ).

Настраивать конфигурацию TempDB следует, используя следующие рекомендации:
• каждый файл данных — начальный размер 2ГБ, размер приращения — 512МБ;
• журнал транзакций — начальный размер 2ГБ, размер приращения — 512MБ.

Для улучшения производительности дисковой подсистемы рекомендуется отформатировать диски с размером кластера 64 КБ.

На данный момент диски для продуктивной системы отформатированы с размером кластера 4 КБ. Увеличение размера кластера до 64 КБ в соответствии с рекомендациями производителя позволит ускорить выделение свободного пространства и уменьшить нагрузку на диски. Данную рекомендацию стоит выполнять, если есть возможность отформатировать диски, перенести файлы баз данных и настроить их на новое расположение.

• TF 4199 — управляет несколькими изменениями оптимизатора запросов, внесенными
ранее с несколькими флагами трассировки;

• TF 1117 — для одновременного выполнения операции приращения всех файлов БД (с несколькими файлами данных) — актуально для TempDB;

• TF 1118 — удаляет большинство одиночных размещений страниц на сервере, уменьшая вероятность конфликтов блокировок на странице SGAM.

Рекомендуется также рассмотреть и протестировать возможность включения в продуктивной среде флага трассировки TF 2371. Данный флаг трассировки позволяет использовать динамический порог для обновления статистики.

Изменение обязательно должно выполняться через SQL Server Configuration Manager, а не через консоль управления сервисами ОС.

Данный параметр используется для повышения эффективности кэширования планов запросов. Он позволит снизить требования к памяти, так как кэш планов не будет заполняться скомпилированными, но не используемыми повторно планами запросов.

1. В свойствах SQL Server установлена опция «max degree of parallelism» в 1, таким образом отключен параллелизм;

2. Для учетной записи SQL Server настроены следующие политики:

• политика Perform volume maintenance task (выполнение задач по обслуживанию томов). Данная политика позволит аккаунту SQL Server при необходимости производить «мгновенное» приращение на файлах данных БД. Политика не работает в отношении файлов журнала транзакций;

• политика Lock Pages in Memory (блокировка страниц в памяти) позволяет предотвратить усечение памяти, управляемой SQL Server.

После установки необходимых разрешений в Local Policy необходимо перезапустить службу SQL Server.

3. В свойствах базы данных LD установлена опция «Is Read Committed Snapshot On» в 1 (True).

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

После полной подготовки инфраструктуры и настройки серверов установка самого решения занимает считанные минуты, поскольку все производители предоставляют или преднастроенные инсталляционные пакеты с запросом на этапе установки минимальной информации (имен серверов, базы и т.д.) или инсталляторы, которые все разворачивают в бездиалоговом режиме.

Публикация веб-версии обычно не вызывает трудностей, а установка клиента на ПК пользователей для многих сложна. Крупные компании для решения этого вопроса используют доменные политики, различные программы для публикаций приложений, а в средних и малых организациях чаще всего нет такого программного обеспечения, и администраторам приходится устанавливать систему на каждый компьютер вручную. Это длительный и трудоемкий процесс, который не гарантирует идентичных настроек системы у различных пользователей, что влияет на эксплуатацию.

Мы в своей практике применяем более технологически простое и удобное решение — публикацию приложения по технологии Click Once. Администратору достаточно по инструкции подготовить на сервере комплект установочных файлов и разослать ссылку любым удобным способом на сетевой ресурс или существующий в организации портал. Наличие или отсутствие домена, прав пользователя на ПК никак не влияет на установку приложения.

Таким образом, установка приложения на персональные компьютеры пользователей сейчас является достаточно простой и быстрой задачей. Главное — внимательно ознакомиться с документацией, которую предоставляет вендор.

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

Практически все производители СЭД предоставляют описание данных, которые требуется регулярно сохранять. Чаще всего это базы или база данных, образы самих документов в системе и исполняемые файлы. Далее каждый администратор выбирает инструментарий для создания резервных копий необходимых для работы данных. Выбор того или иного метода зависит от двух показателей, которые должен указать бизнес-заказчик. Это максимальный период времени, за который могут быть потеряны данные в результате инцидента (RPO, recovery point objective), и время, в течение которого система может оставаться недоступной в случае аварии (RTO, recovery time objective). В зависимости от этих показателей администратор принимает решение, достаточно ли ему будет резервных копий баз данных и файлов или необходимо делать копии всех виртуальных машин, на которых развернута система. Главное в этой задаче — обеспечить минимальное время простоя и, конечно же, постараться потерять минимальный объем данных.

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

Немаловажный фактор обеспечения эксплуатации — ежедневный мониторинг за показателями системы. В зависимости от сложности настроенных процессов, интеграционных модулей и много другого мониторинг может проводится раз в день, к примеру, утром, или же три раза в день. В данном случае критерии проверки бизнес модулей устанавливает сам заказчик. Мы со своей стороны можем дать только технические рекомендации: какие службы требуется проверять, какие показатели являются нормой и как правильно анализировать лог-файлы для выявления предвестников инцидентов.

Периодичность и порядок обновлений системы зависят от производителей. Для крупных внедрений мы рекомендуем планировать обновления не реже двух раз в год, для решений сегмента малого и среднего бизнеса обновления достаточно проводить раз в год. Процесс обновления LanDocs очень прост: необходимо запустить инсталляционный пакет в режиме «Обновить» на серверах, где установлена система, и компоненты будут обновлены до последней актуальной версии. Единственное, что останется администратору, — это собрать Click Once для клиентов, и при старте системы на клиентских местах будет обновлено и клиентское приложение.

В целом, это основные моменты, на которые стоит обратить внимание при внедрении СЭД любого производителя. И самое главное, любой администратор должен понимать, что после внедрения он не остается один на один с системой, у него есть техническая поддержка производителя и компании-поставщика.