История одной репликации

“Наши корни глубоки” (Our Roots Go Deep)

Среди клиентов нашей компании ИТ-КРОСС есть один довольно крупный заказчик, с которым нас связывают уже достаточно крепкие рабочие отношения. Заказчик насчитывает порядка 16 подразделений по всей территории России, а это около 10000 работников.

В работу с СЭД DIRECTUM вовлечено около 400 сотрудников, это административно-управленческий персонал и руководители среднего звена. При этом фактически к главному серверу подключаются все удаленные подразделения.

Внедрение системы DIRECTUM у этого заказчика начиналось еще год назад. Тогда были автоматизированы процессы договорного и претензионно-искового блока. Плодотворное сотрудничество пустило корни и предоставило возможность развивать систему и в других направлениях. Так впоследствии успешно прошло внедрение таких блоков, как: Канцелярия, Совещания, Управление производственными документами.

“Трубите атаку” (Sound the Charge)

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

• Веб-доступ;
• Удаленное подключение по RDP;
• Локальный клиент при настроенном VPN-соединении;
• Мобильные решения (на тот момент у клиента было куплено решение iDecide);
• Репликация.

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

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

“Верен цели” (True to the Mark)

Первая мысль: «Не, ну нормально же общались!» Возможность «подмочить» свою репутацию не особо радовала. С настройкой репликации наша команда до этого момента не сталкивалась ни разу (а заказчики такие на дороге не валяются), поэтому поначалу было, мягко говоря, страшно. Еще больше обстановку нагнетали сроки выполнения работ. Весь административно-управленческий персонал фактически жил в DIRECTUM и простои в работе не позволялись. К тому же начальство со дня на день собиралось переезжать и, чувствуя острую необходимость в предстоящих изменениях, мы понимали, что предстоит прожить парочку насыщенных недель.

Первое, что решили сделать, так это раздобыть информацию по адекватным срокам выполнения подобных работ. Техподдержка DIRECTUM уверила, что за 2 дня все можно успеть. Честно признаться, веры в это не было никакой (все-таки в Директуме сидят знающие люди, а мы в этом вопросе были профаны).

Недолго думая, мы решили поэкспериментировать на тестовых базах:

1. Развернули тестовый сервер;
2. На боевом сервере (а-ля главный сервер) создали копию нашей рабочей базы;
3. Провели пару нехитрых операций с тестовой базой (удалили таблицы, схема которых не dbo, сгенерировали структуру базы, индексы и первичные ключи);
4. Создали БД для вторичного сервера и запустили скрипт на создание таблиц;
5. С помощью средств Management Studio импортировали данные из одной базы в другую;
6. Создали индексы и первичные ключи уже в новой базе;
7. Активировали серверную часть;
8. Добавили новый сервер в систему DIRECTUM, указав при этом интервалы для диапазона значений внутренних кодов вторичного сервера, указанные в документе «Руководство репликации». В нашем случае разворачиваемый сервер только второй, то интервалы получились: 50 000 000 – 100 000 000.
9. Зарегистрировали систему с ключиком, в состав которого включена репликация и произвели первоначальную передачу данных из исходной базы в новую созданную (в рабочей системе данных не так много, поэтому полная передача данных длилась около часа);
10. Перенесли подготовленную базу с данными на тестовый сервер и настроили серверные компоненты, после чего перерегистрировали систему еще раз.

Вся последовательность выполняемых действий подробно описана в документах «DIRECTUM X. Вторичный сервер репликации. Инструкция по установке», «DIRECTUM X. Инструкция по переносу данных системы DIRECTUM из одной БД в другую» и «DIRECTUM X. Руководство по репликации».

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

“Без отдыха” (Never Resting)

И вот наступил ответственный момент, 3 замечательных выходных в честь Дня защитника Отечества. Работы велись по 12 часов в сутки (сидели почти до самого вечера), не хотелось ничего упустить, все-таки многое необходимо было сделать. Когда были пройдены все подготовительные этапы, мы получили готовую базу данных, оставалось только произвести перенос данных из одной системы в другую и продолжать работы по настройке, тестированию и отладке работающего механизма.

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

Отладив еще на тестовых базах механизм передачи данных с одного сервера на другой, мы в первую же очередь настроили расписание для сеансов репликации. Доступ ко вторичному серверу был организован благодаря настроенному VPN-соединению. Таким образом, имея возможность передавать данные в рамках локальной сети, мы просто настроили запуск компоненты «Обмен данными с главным/вторичным сервером» в автоматическом режиме. Расписание было выбрано с интервалом в 20 минут, который показался нам наиболее комфортным, учитывая, что на вторичный сервер приходит крайний этап согласования после проведения основных подготовительных работ по документу.

Ну а затем, недолго думая, начали тестировать все подряд, изменяя объекты на одном сервере с последующей проверкой всех изменений на другом. Репликация же начала вставлять нам первые палки в колеса, разрушая все надежды на успешное завершение этого уикенда, доставляя хлопоты по разбору отдельных моментов (например, объекты необходимо удалять корректно, а то повиснут мертвяком в системе). Так и прошел наш второй день по настройке, иногда в печали, а иногда и в приподнятом настроении, потому как все решается, главное, быть настойчивым! Дополнив список реплицируемых компонент нужными справочниками, для которых эта настройка еще не действовала, второй день опять-таки завершили масштабной передачей данных.

Но это же был наш первый опыт, поэтому мы только на третий день обнаружили, что несколько руководящих лиц, из-за которых и происходила столь масштабная работа, не перенесены на вторичный сервер. Исправить это оказалось не так-то просто. Генерация пользователей на новом сервере не приносила плодов, в соответствующей карточке в списке серверов добавилась новая запись с пометкой НЕТ в поле «Основной сервер» и только. Помогла перегенерация пользователей на вторичном сервере, с предварительным удалением записи из компоненты «Пользователи» на основном (тут в голове всплывает мольба, чтобы опытные люди не покачали головой, читая эту историю первого знакомства с особенностями репликации). Как оказалось, таких особенностей будет немало.

Первое же, что нам бросилось в глаза: при работе неосновного пользователя сохранение любых объектов возможно, только если хотя бы один основной пользователь текущего сервера имеет права на объект. Т.е. сама проблема переноса пользователей на другой сервер заключалась как раз в этом, будучи «чужими» на текущем сервере, мы практически ничего не сможем сохранить, не сделав дополнительных манипуляций. Позднее, разбираясь с ошибками репликации (а такие будут, не сомневайтесь!), наше обращение в техподдержку было обработано с отличным результатом: нам выдали руководства по устранению ошибок, среди которых была и инструкция по переносу пользователя на другой сервер. Ну а третий день по традиции необходимо было завершить полной передачей данных, ведь все объекты, к которым имело доступ руководство, должны были быть перенесены на вторичный сервер.

Имея в распоряжении буквально 12 часов на отработку полной передачи данных и проверки результатов работы, уже глубокой ночью, судорожно открывая журнал сеансов репликации, с радостью обнаружили, что все было успешно отработано и мы готовы к рабочей неделе! Почему «судорожно» спросите вы? Все дело в разросшейся базе, которая на тот момент имела в общем весе уже больше 50 ГБ, размер пакета для полной репликации при этом получился около 40 ГБ и при канале в 10 Мбит передача данных занимала  более 9 часов. Так что, никакого волшебного щелчка «пальцев» – только терпение и выдержка.

Вторая глобальная проблема, с которой мы столкнулись чуть позже, заключалась все в тех же пользователях. Ранее упоминалось, что руководство имеет тотальный контроль за пользователями системы и отслеживает их работу (читает комментарии, смотрит количество невыполненных заданий и т.д.). Причем есть определенный интерес со стороны руководящего состава видеть это действо вживую (настроено замещение на большинство ключевых сотрудников), а не с помощью стандартных отчетов по исполнительской дисциплине. Поэтому при настройке механизма репликации столкнулись с задачей проводить перенос абсолютно всех данных на вторичный сервер. С документами, понятно, вопросов не возникло, они и так направлялись автоматом (на все документы выданы права по умолчанию группе Руководство). Предстояло разрешить ситуацию с задачами. Напомню: объекты переносятся на другой сервер при репликации только в том случае, если на этот объект имеет права хотя бы один пользователь удаленного сервера. В итоге, мы запустили сценарий, который срабатывает достаточно часто, чтобы установить в задачу наблюдателя, этакого фиктивного пользователя вторичного сервера. Изменить состав наблюдателей программно можно (напрямую назначать наблюдателя не стали, чтобы уведомления не сыпались), а т.к. в правах задачи теперь имеется пользователь вторичного сервера, то это оказалось верным решением. И, возрадовавшись такому исходу событий, мы приступили к решению других мелких задач.

“Днем или ночью” (By Day or Night)

И вот началась она… Ежедневная сводка по работе механизма репликации. Больше месяца мы каждый день заходили в журнал репликации и проверяли его состояние. Бывало, репликация зависала ночью, происходило обрывание связи и терялся пакет. Но трудно ведь бывает только поначалу. Сделав пару раз то, что доктор прописал, мы уже без каких-либо колебаний вспоминали весь дальнейший порядок действий.

Самое страшное (как нам показалось) началось, когда задачи странным образом стали одновременно править на разных серверах (не будем в подробностях указывать, кто допускал такие оплошности), несмотря на наши рекомендации. Задачи просто висели в подвешенном состоянии (в работе причем), любые действия с этими объектами приводили к тому, с чего начинали, задачи просто не хотели запускаться :(. Промучав одну из таких задач, мы все-таки нашли выход: достаточно было поправить схему задачи и поставить ее в очередь WorkFlow на обработку. Правда перед этим пришлось найти аналогичную задачу и скопировать оттуда блок …, поменять на данные для нашей задачи и указать в блоке какой блок был завершен на последней итерации (на котором, собственно, и зависла задача). После этого задача, посчитав, что нужный блок уже прошла, переходила далее, как нам и требовалось.

А самое веселое начиналось, когда требовалось обновить схемы ТМ для уже запущенных задач (изменения вносились в логику работы). После таких действий система считала, что эти задачи необходимо перенести на другой сервер, ведь они были изменены. Для нас это была чистой воды лотерея «поймай момент», сделать все манипуляции по обновлению задач можно было либо рано утром, либо поздно вечером, дабы не сбить логику репликации и не вызвать бурю конфликтов.

“Пусть будет здесь записано” (Let it be Written)

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

• Проверять журнал репликации каждый день утром. Ведь это как проверить почту – посмотрел, что все хорошо, и со спокойной душой в новый рабочий день!
• Что делать при сбое репликации, в каких папках проверять потерянные пакеты и при каких ситуациях на каком сервере пакет может быть потерян.
• Что делать при перезагрузке сервера, так уж получается, что при отключенном сеансе пользователя, под которым запускается сеанс репликации все сводится на нет.
• Где и как создавать пользователя.
• Как разрешить ситуацию с зависшими задачами, для удобства выгрузки схемы задачи и установки в очередь разработали 2 маааленьких сценария, дабы не лезть админам напрямую в базу.

“Вечно бдительны” (Ever Vigilant)

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

Ну а всем, кто задумывался по поводу использования механизма репликации Directum: «Брать или не брать?». Можем посоветовать только одно: «Брать!» - ведь, как говорится, главное знать, как это правильно готовить. Мы научились «готовить» репликацию DIRECTUM, научитесь и Вы!