Настройка серверных политик. Вопросы обучения конечных пользователей и сотрудников технического сопровождения

Шаг 1 . Установление соединения с сервером. Инициирующий репликацию сервер (станция) соединяется с вызываемым сервером. Происходит процедура аутентификации и проверка возможности доступа к данному серверу (о механизме аутентификации и контроле доступа к серверу >>>)
Для установления расписания репликаций сервер использует документ Connection Адресной книги, клиент Notes - документ Location (Место вызова)
Шаг 2 . Построение списка реплицируемых баз. Каждый сервер поддерживает в своей виртуальной памяти упорядоченную по идентификатору реплики таблицу всех имеющихся на нем баз данных и шаблонов - так называемый, кэш идентификаторов реплик . Репликатор сравнивает свой кэш и кэш вызываемого сервера и, с учетом репликационных приоритетов и указанных к реплицированию (в документе Connection или в параметрах команды консоли) баз, строит список баз, подлежащих реплицированию в данном сеансе
Шаг 3 . Далее для каждой базы из списка
• Определяется, не запрещены ли репликации базы. Если в установках одной из реплик выбрана опция, запрещающая репликацию (Temporarily disable replication for this replica в настройках репликации), репликации базы не происходит, о чем уведомляет строка на консоли сервера Replication is disabled for <сервер> <база>
• Может ли каждый из серверов открыть реплику на другом сервере. Если один из серверов не имеет доступ (уровень доступа No Access) к одной из реплик, либо не имеет доступа к подключенному (связаному) каталогу, внутри которого находится реплика, репликация базы заканчивается выдачей сообщения Access control is set in <сервер> <база> to not allow replication from <сервер> <база> . Если оба сервера имеют доступ к обеим репликам, репликатор открывает реплику на вызванном сервере.
• Репликация ACL. Для репликации ACL необходимо, чтобы у вызванного сервера был доступ Управляющего (Manager) в ACL вызвавшего сервера и в настройках репликации на вызвавшем сервере была выбрана опция Receive these elements from other replicas: Access Control List . Репликатор сравнивает даты изменения ACL в обеих репликах. Если ACL "чужой" реплики изменился позднее, чем ACL "своей", репликатор получает ACL с вызванного сервера и заменяет им свой ACL, после чего снова проверяет, может ли каждый из серверов открыть реплику другого. При схеме Pull-Push зеркально-аналогичные действия выполняются репликатором по отношению к ACL на вызванном сервере. При схеме репликации Pull-Pull обновление (если необходимо) произведет репликатор вызванного сервера после передачи ему управления во второй фазе репликационной сессии
• Репликация элементов дизайна. Для успеха этой части репликации базы необходимо, чтобы уровень доступа вызванного сервера в ACL реплики базы на сервере-инициаторе был не ниже уровня Разработчика (Designer). Сервер выискивает и принимает на свою сторону элементы дизайна, изменённые на вызванном сервере позднее, чем изменились эти элементы на его стороне, заменяя последние. Но только если это разрешают делать опции, прописанные в параметрах репликации базы в полях Receive these elements from other replicas: Design elements, Agents, Replication formulas . Удаление элементов дизайна происходит подобно удалению документов путем передачи информации об удалении (stubs ). После приёма изменений сервер производит выталкивание изменений, произошедших на своей стороне (схема Pull-Push ) после зеркально-аналогичных проверок, либо переходит к следующей стадии приема, оставив передачу изменений до второй фазы сессии (схема Pull-Pull )
• Репликация документов. Прием изменений документов на сервер-инициатор происходит, если вызванный сервер имеет доступ к базе (ACL) и документам (поля доступа к документам типа Readers и Authors), позволяющий создавать, изменять или удалять документы. Среди документов вызываемого сервера строится специальное представление, содержащее документы согласно формуле репликации. Затем репликатор создает список идентификаторов документов, которые были изменены со времени последней репликации. Если в настройках репликации включен параметр Receive documents from server - Smallest first , полученный список сортируется по размеру документа, в противном случае - по дате модификации. Далее для каждого документа по идентификатору ищется его собрат в своей реплике. Если этого не удалось, новый документ добавляется в реплику. Если документ не новый - сравниваются время последней модификации и последовательные номера этих документов. Если документ оказался измененным с момента последней репликации на обоих серверах - возникает репликационный конфликт (этот случай рассматривается ниже). В противном случае изменения передаются на сервер-инициатор репликации, модифицируя документ на его стороне. Причем, начиная с версии 4.x происходит не полное копирование всех полей, копируются только поля, имеющие неодинаковые флаги Seq Num . Это существенным образом сокращает объём передаваемой информации. Именно это и называют репликацией на уровне полей (пунктов, items). Далее, в зависимости от схемы репликации, либо репликатор сервера повторяет описанные в этом пункте действия в зеркальном направлении, выталкивая новые и модифицированные документы (схема Pull-Push ), либо сразу переходит к следующему пункту, оставляя эту работу для чужого репликатора (Pull-Pull )
• Обновление записи в истории репликаций. При успешном завершении предыдущих стадий репликации репликатор делает запись в истории репликаций своей реплики. Если репликация происходит по схеме Pull-Push , то подобную запись репликатор вносит и в историю репликации чужой реплики
Шаг 4 . Завершение репликационной сессии. Когда список реплицируемых баз исчерпан, репликатор или разрывает соединение (схема Pull-Push ), или передает запрос на активизацию репликатора на обратной стороне и передачу изменений в обратную сторону.

• Значение этого свойства Create Conflicts (отсутствие поля $ConflictAction или значение поля, установленное в значение "1" , в документе) задаёт описанное выше разрешение конфликтной ситуации - создание репликационного конфликта
• Значение свойства Merge Conflicts (значение поля $ConflictAction , равное "2" ) - объединение конфликтов, произошедших при редактировании различных полей в различных репликах базы данных

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

• иметь доступ к базе данных (минимум Корреспондент - Depositor в ACL базы данных)
• база должна быть разрешена к репликации (в настройках репликации базы снят соответствующий флажок - подробнее о настройках - ниже)
• база, расположенная на локальной станции, не должна быть зашифрована чужим ключом
• при создании реплики базы на сервере в установках сервера (в серверном документе - раздел Security или переменной NOTES.INI Create_Replica_Access ) пользователь должен быть наделен правами на создание реплик баз на этом сервере

Дальнейшие опции позволяют задать:

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

• Группа опций How often replication occurs (С каким интервалом происходит репликация) задаёт расписание репликаций для текущего Места вызова (Location) - собственно, предоставляет доступ к соответствующему разделу документа Адресной книги. Собственно, все заполняемые опции находят своё отражение в документе
• Опция Apply changes to all locations (Применить изменения ко всем местам вызова - внизу окна диалога) применяет данные настройки и к прочим документам Locations Адресной книги
• Группа опций How much will be replicated (Количество данных для репликации) относится уже собственно к базе и задаёт направление репликации (опции Send documents to server - Отпрвлять документы на сервер и Receive documents from server - Получать документы с сервера) и режим приёма документов с сервера (полноту приёма этих документов). Можно задать четыре режима:
  Full documents (Документы целиком) . Документы реплицируются полностью
  Partial documents (Документы по частям) . Содержимое документов реплицируется частично, размер усекается в соответствие со следующими опциями (Усечение документов, размер которых превышает - Truncate documents larger than , Ограничение размера вложения до - Limit attachments size ). Документы с неполным содержимым определяются как усечённые (truncated ). При открытии в заголовок окна документа добавляется термин УСЕЧЁН (TRUNCATED ). Для восстановления полной информации можно воспользоваться действием главного меню Actions -> Retrieve Entire Document (Действия -> Принять документ полностью ). Усечённые документы невозможно редактировать, они также не обрабатываются агентами
  Summary only (Только аннотации) . В данном режиме документы усекаются с передачей информации из полей Author и Subject , а также первых 40 Кбайт форматированного поля
  Smallest first (Начиная с маленьких) . Режим, появившийся в Notes R6. При репликации в этом режиме сначала реплицируются маленькие по размеру документы, что делает репликационный механизм более дружелюбным пользователю в приложениях типа библиотека документов , в стандартной почтовой базе
• Опция Which server is used for replication (Сервер, использующийся для репликации)
Группа опций Экономия места (Space Savers)

• Remove documents not modified in the last ... days: (Удалить документы, не измененные за последние... дней) . Установка опции автоматически удаляет из данной реплики документы, с момента последнего сохранения которых прошло более указанного количества дней. Документы, удаленные из данной реплики на основании этой установки, будут удалены в других репликах, если 1). список управления доступом (ACL) реплик позволяет серверу или пользователю-инициатору репликации удалять документы; 2). Не установлен флаг Do not send deletions made in this replica to other replicas (Не отправлять удаления, сделанные в этой реплике, в другие реплики ). Для баз, размещенных на сервере "автоудаление" производится серверной задачей Updall , запускаемой в ночное время, для локальных баз - в момент открытия базы
• Количество дней в вышеприведенной строке (даже если флажок Remove documents... не поднят) определяет также процесс удаления информации об удаленных документах ("окурков", stubs ). Для того, чтобы сервер смог отличить удаленный в этой реплике документ от только что созданного в другой реплике, документ не удаляется сразу полностью, остается stub как некая информация о том, что этот документ был в реплике. Удаление stub откладывается на интервал времени, составляющий третью часть от указанного в этом поле. За это время должны произойти репликации со всеми другими репликами, иначе по прошествии отведенного срока stub удаляется и документ из залежалой реплики может появиться вновь.
• Receive only a subset of the documents (Принимать часть документов) : Опция используется, если в реплику должны поступать не все документы, а только из некоторых видов и папок (опция ) или удовлетворяющие условию отбора, заданному при включении опции Documents that meet a selection formula (Выбирать по формуле) . Эта возможность заключает в себе понятие выборочной (селективной) репликации. Кроме того на закладке Advanced можно задать правила для репликаций элементов дизайна и списка управления доступом (см. ниже)
Закладка Отправка (Send)

• Do not send deletions made in this replica to other replicas (Не отправлять удаления, сделанные в этой реплике, в другие реплики ). Установка этого флага позволяет не распространять удаления, имевшие место быть в этой реплике, в другие реплики базы данных. Если опция не выбрана - появившиеся после удаления документов в этой реплике stubs ("окурки") передаются в другие реплики и вызывают удаление соответствующих документов и в прочих репликах
• Do not send changes in database title and catalog info to other replicas (Не отправлять изменения в названии базы данных и информацию для каталога в другие реплики ). Поднятие этого флага запрещает передачу изменений некоторых параметров базы данных на другие реплики базы. В противном случае эти изменения будут подхвачены другими репликами, если имеется достаточный доступ (уровень разработчика) у сервера или пользователя, производящего репликацию
• Do not send changes in local security property to other replicas (Не отправлять изменения в локальной защите в другие реплики ). Подобно предыдущему, но в отношении свойств базы данных, касающихся локальной безопасности этой реплики
Закладка Прочее (Other)

• Temporary disable replication for this replica (Временно отключить репликацию ). Выбор опции запрещает участие базы в любых репликационных процессах. Сервер выдает сообщение Replication is disabled . Опция полезна администратору, если база по каким-то причинам оказалась поврежденной и требуется ее восстановление, прежде чем будет возможность возобновить репликации
• Scheduled replication priority (Приоритет репликации по расписанию ). Параметр задает приоритет участия базы в репликациях согласно документам Connection Корпоративной Адресной книги или Location (Место вызова ) Локальной Адресной книги. Реплики с высоким (High ) приоритетом могут нуждаться в более частом обновлении, чем остальные. В соответствии с выбранным расписанием репликаций в Адресной книге создаются документы Connection : один - для поддержки репликаций с высоким приоритетом (наиболее частые репликационные сессии), один - для репликаций с высоким и средним приоритетом, и для репликаций баз всех трех приоритетов - в самое дешевое время и нечасто. Документы Connection для поддержки репликаций различного приоритета не должны содержать накрывающих участков времени. В противном случае, расписание составлено некорректно, и репликационные сессии могут происходить беспорядочно, а часть реплик может совсем не обслуживаться
• Only replicate incoming documents saved or modified after (Только входящие документы, сохраненные/измененные после ):. Значение даты (Cutoff Date ), содержащееся в этом поле, требуют принимать в реплику только документы, имеющие дату модификации позже указанной. Документы из других реплик с датой модификации ранее Cutoff Date не включаются в списки реплицируемых документов и, следовательно, никогда не будут приняты в реплику этой базы с других серверов.
• CD-ROM publishing date (Дата выпуска компакт-диска ):. При распространении реплики на компакт-диске рекомендуется задать в этом поле дату записи на диск до проведения первой репликации (записи диска). Тогда при первой репликации (когда чиста история репликаций) будут просматриваться документы, модифицированные после даты публикации, а не все множество документов, что оптимизирует время первой репликации
Дополнительные возможности по определению формул отбора селективной репликации имеются на закладке Дополнительно (Advanced)

• Прежде всего, имеется возможность задать разные формулы отбора для разных пар принимающих изменения (поле When computer/Если компьютер ) серверов и станций и серверов или станций, с которых принимаются изменения (поле Receives from/ Принимает данные от ). Для разных пар можно указать:
• Формулу отбора при установке флага в полях Documents in specified views or folders и Documents by selection formula наподобие описанной выше для закладки Space Savers
• Access Control List (Таблицы управления доступом) - принимаются изменения в списке управления доступом
• Design elements (Элементы дизайна) - принимаются все элементы дизайна кроме агентов и репликационных формул
• Agents - принимаются агенты
• Replication formula - разраешает принимать в базу назначения формулы селективной репликации, имеющие более позднее время модификации. Это позволяет менеджеру "центральной реплики" базы задавать формулы селективной репликации в процессе эксплуатации базы.
• Deletions - принимается информация об удаленных документах, вызывая удаление документов и в выбранной реплике
• Fields - принимаются не все поля документов, а только выбранные из списка. В результате документ становится усечённым (см. описание выше) и нередактируемым.
Ограничение размера реплики (для баз формата ниже R5). Можно задать максимальный размер реплики. Список выбора позволяет установить ограничение на уровне 1 Гб, 2 Гб, 3 Гб или 4 Гб. Вообще-то здесь можно вести речь не об ограничении, а об увеличении размера реплики. Дело в том, что в версии Notes R4.x при создании размер базы автоматически ограничивался 1 Гб. При активном росте этой базы лимит в конце концов выбирался, а установить новый лимит можно было только создав реплику и установив ей более высокий лимит.
Возможность создания реплики немедленно или в фоновом режиме при следующей репликации по расписанию. При выборе второго варианта создается заготовка базы данных, которая впоследствии наполняется содержимым
Поддержка Списка управления доступом (ACL) базы-оригинала для вновь создаваемой базы. Для нормальной поддержки функционирования базы (в том числе и нормального процесса репликации) необходимо иметь этот флажок включенным
Создание полнотекстового поискового индекса базы. Нельзя забывать, что для создания полнотекстового индекса базы, расположенной на сервере, в дальнейшем потребуется наличие полномочий разработчика базы, в то время как при создании реплики возможно создать полнотекстовый индекс, не имея этих прав.

Андрей Акопянц

Наши недостатки есть продолжение наших достоинств
Народная мудрость…

Практически все специалисты по информационным технологиям слышали о Lotus Notes (LN) , но относительно немногие имели с ним дело на практике. Вследствие этого по Лотусу имеется катастрофический дефицит объективной информации. Вся доступные публикации об этом продукте имеют вид рекламных проспектов или фрагментов технических описаний.

Там, где нет объективной информации - она замещается мифами. Сейчас в России Lotus продвигается в основном как система организации корпоративного документооборота, хотя на самом деле это не совсем так. Мнения об этом продукте полярны - одни преподносят его как панацею от всех болезней корпоративной автоматизации, другие и слышать о нем не хотят.

В то же время реальная значимость Lotus Notes для корпоративного рынка чрезвычайно велика. Многие крупные российские компании стоят сейчас на пороге выбора корпоративной информационной среды, и Lotus - один из основных претендентов на это. Поэтому мне показалось важным рассказать - что такое LN на самом деле, какие проблемы он решает, а какие - создает.

Я давно вынашивал эту идею, почитывая описания и расспрашивая знакомых. Окончательным толчком для меня стало знакомство с бывшим начальником IT очень крупного банка, поведавшего о некоторых особенностях эксплуатации LN, с которыми ему пришлось столкнуться.

Немного истории

Компания Лотус была пионером во многих направлениях софтверного бизнеса. Сейчас это многие не помнят, но в самом начале 90-тых "Lotus 1-2-3" был синонимом электронной таблицы - достойных конкурентов у него просто не было... Почтовая программа "CC-mail" оставалась лучшей корпоративной почтовой системой до середины 90-х.

Аналогов выпущенного в конце 80-х LN вообще не существовало - для него пришлось придумать отдельный термин - "GroopWare" (обеспечение коллективной работы). Это была первая и долгое время единственная система, реально позволяющая обеспечить быстрое создание единого информационного пространства компании и системы корпоративных коммуникаций.

Триумфальное шествие LN продолжалось почти десять лет, и основными его пользователями являлись крупные и средние корпорации. Неудивительно, что интерес к компании Лотус проявила IBM, традиционно обслуживающая Top1000 мирового бизнеса, и в конце концов таки купила эту компанию на корню. Так что ныне Лотус - это подразделение IBM, сохранившее некоторую самостоятельность, и торговую марку "Lotus".

Сейчас, впрочем, от всей линейки продуктов Лотус на рынке реально остался только Lotus Notes - остальные офисные приложения практически умерли, не выдержав конкуренции с Microsoft Office . А Lotus Notes не просто остался, но активно продвигается - по крайней мере, на российском рынке.

Lotus Notes - что это такое?

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

Главной особенностью лотусовской базы данных является ее ориентация на хранение больших плохо структурированных документов и коллективную работу с ними. Под коллективной работой подразумевается возможность нескольким человекам одновременно править одну и ту же запись (документ). Соответственно, поддерживается аппарат версий и возможности отслеживания изменений, сделанных отдельными пользователями. Кроме текстов, записи лотусовских БД могут содержать произвольное количество настраиваемых пользователями реквизитов разных типов. Причем настройка состава реквизитов достаточно проста и посильна конечным пользователям. Документы в базе могут ссылаться друг на друга (что-то типа вебовских гипертекстовых ссылок), и кликнув на ссылку в тексте документа, можно открыть другой документ.

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

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

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

Естественно, предусмотрена возможность разработок специализированных приложений в среде LN. Для этой цели в систему встроен язык программирования (Lotus script), открывающий доступ к API системы, и позволяющий создавать достаточно сложные приложения. Можно также разрабатывать приложения для Lotus на более традиционных Java & JavaScript, к которым также имеются библиотеки объектов для работы с Lotus-овским API.

Обратная сторона медали

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

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

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

Но сегодня значительная часть пользователей предпочитает использовать офисные приложения других фирм - например, Microsoft, которые стали сегодня стандартом де-факто. В Lotus-овском хранилище документов можно хранить "чужие" файлы, но, как только мы начинаем использовать MS Word совместно с Lotus, тут же выясняется, что половина всех прелестей, которые были при работе со встроенным редактором LN, теряется.

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

Еще одна особенность, показавшая свою оборотную сторону - это репликация в сочетании с общей требовательностью к ресурсам. Упоминавшийся мной начальник IT-департамента крупного банка, в котором было больше 2000 рабочих мест на LotusNotes вспоминал, как у них репликация между крутыми серверами по выделенному оптоволокну шла часами (а это означает, что люди часами не могли получить отправленные им на визирование срочные документы.

А необходимость во множестве серверов возникала из-за того, что одиночные сервера не справлялись с нагрузкой, поскольку LN в силу свой интегрированности очень требователен к серверным ресурсам. И когда в результате они переписали приложение на MS SQL , выяснилось, что всех пользователей спокойно "тянет" один не самый крутой сервер, и пропускной способности каналов (которой не хватало для репликации) вполне хватает для нормальной удаленной работы пользователей.

При больших объемах базы также выступает "родовая травма" Lotus Notes - его система хранения данных не поддерживает ряд вещей, являющихся стандартом для современных СУБД, и совершенно необходимых для функционирования реальных систем автоматизации.

• Во первых, БД Lotus Notes не поддерживает транзакции - т.е. согласованные изменения нескольких таблиц, выполняемые как единое целое. Т.е. если, например, приложение, работающее на клиенте, успело модифицировать одну запись, но не успело другую, и "упало" (например, свет выключился), то в базе данных LN измененная запись останется таковой, в то время как во всех современных СУБД в такой ситуации на сервере произойдет откат до начального состояния. Из-за этого поддерживать целостность больших баз на LN становится проблематично.
• Во-вторых, как мы говорили выше, LN поддерживает возможность связывания документов. Но при этом контроля ссылочной целостности в нем нет - Вы спокойно можете удалить документ, на который кто-то ссылается, и образуется "висячая" ссылка. Естественно, нет никаких более продвинутых механизмов контроля целостности - типа constraints в реляционных базах данных.
• И наконец, в-третьих - в отличие от современных реляционных СУБД, где индексирование записи происходит при помещении ее в базу, в LN индексирование - это отдельный процесс, происходящий асинхронно.

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

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

Лотус как система документооборота

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

Но наряду с этим у него есть и большой недостаток - что, кроме этого Lotus сам по себе ничего больше не умеет. Т.е. сделать макет базовыми средствами Lotus можно, а вот реализовать полноценную систему корпоративного документооборота, удовлетворяющую требованиям ГОС-ов, не получается. Говорить - "Для автоматизации делопроизводства мы купим Lotus Notes" - такой же нонсенс, как и "Для автоматизации делопроизводства мы купим MS SQL". Необходимо либо разрабатывать систему, используя LN как инструмент, либо покупать специализированное решение.

Достоинством LN как среды разработки является наличие ряда встроенных механизмов работы с документами. О недостатках мы говорили выше - дорогие разработчики, устаревшая технология хранения данных и трудности интеграции с другими системами.

В целом выходит, что при несколько меньшей трудоемкости сроки разработки прикладной системы на базе Lotus не отличаются от аналогичных разработок на базе скажем, MS SQL и Visual Basic , а стоимость (с учетом лицензий и дорогих разработчиков) может и заметно превосходить. Не говоря уж о том, что эксплутационные свойства систем на LN, такие, как надежность и эффективность, заметно хуже, чем у решений на базе полноценных СУБД.

Специализированные решения для организации делопроизводства на Lotus на российском рынке есть. Наиболее распространенными системами являются разработка компании Intertrust - "Office Media", система "Босс-референт" от АйТи и "Золушка" разработки Института развития Москвы, и ряд других систем.

Но они стоят дополнительных к самому Lotus Notes денег, не являются готовыми продуктами, а, скорее, "полуфабрикатами". По оценке специалистов, их функциональности и эксплутационным характеристикам также уступают системам, реализованным на базе полноценных СУБД и функционирующим в среде Microsft Office, таким как "Дело" от "Электронных офисных систем", LanDocs от "Ланит", Optima Workflow от Оптимы.

Заключение

И все-таки, почему при всем вышесказанном Lotus Notes достаточно популярен у IT-менеджеров и продолжает свою экспансию в крупные российские компании?

Видимо, основных резона два.

• Во первых, конъюнктурно - имиджевые соображения - типа "у нас все, как у лидеров западного бизнеса - вот и Lotus Notes стоит".
• Во вторых, LN создает иллюзию быстрого решения. При относительно небольших трудозатратах можно получить видимый результат и решить слой самых простых задач. А то, что дальше развивать это решение будет очень сложно - так к тому времени либо бизнес помрет, либо IT-менеджер поменяется...

Не стоит также сбрасывать со счетов активную директ-маркетинговую политику партнеров IBM.

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

Но мне кажется, что в современных условиях Lotus Notes уже уходит в те глубоководные впадины рынка, где живут лох-несские чудовища, IBM-овские мэйнфреймы и Кобол. Там Lotus будет жить вечно, но компаниям, выбирающим для себя решения сейчас, ставить на Lotus Notes видимо, не имеет большого смысла.

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

Интернет-магазин

Всё о репликации Lotus Notes/Domino

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

• основная задача Replicator , обслуживающая репликации по расписанию, загружается (обычно) при старте сервера, для чего указывается в списке задач сервера - переменной ServerTasks (ServerTasks=список_задач, Replica, список_задач ), и в каждый момент времени может обслуживать только одну репликационную сессию. Для обслуживания нескольких репликаций одновременно необходим запуск нескольких задач. Это может быть обеспечено указанием переменной Replicators или указанием нескольких задач Replicator (Replica ) в списке запускаемых задач в переменной ServerTasks (обе переменные прописываются в файле настроек NOTES.INI)
• Дополнительная задача репликатора загружается командой Load Replica с консоли сервера
• Дополнительная задача репликатора для репликации с определенным сервером загружается командой

• Возможен также запуск репликатора на уровне операционной системы как запуск файла из программного каталога Notes с ключами:
  xREPLICA servername ,
  где
  x - I для OS/2, N для Windows, V для Novell. unix-системы используют исполняемый файл без начального символа (просто REPLICA)
  - необязательный параметр, определяющий тип репликации (-p - Pull only, -s - Push only, пропущен - Pull-Push)
  servername - имя вызываемого сервера
  - реплицируемые базы

Джозеф Андерсон и Пит Бэркхардт
Опубликовано 25.04.2007

Гибкость и свобода, которую даёт репликация, является непревзойдённым преимуществом IBM Lotus Notes. Многие организации решили использовать эту мощную функцию в полном масштабе, и их пользователи работают с локальными репликами своих баз данных Notes, в том числе и с почтовыми базами данных. Преимущества и недостатки использования локальных реплик почтовых баз данных подробно обсуждаются в статье developerWorks Lotus, " ."

Кроме моментов, рассматриваемых в этой статье, в Lotus Notes/Domino добавлены функции, которые могут сделать реализацию локальных почтовых реплик ещё более соблазнительным. В статье обсуждаются эти дополнительные улучшения и даются рекомендации по настройке локальных почтовых реплик. Прежде чем объяснять модель локальных реплик и излагать технические подробности по организации среды в пределах вашей инфраструктуры, давайте посмотрим на пример применимости данной модели.

Пример реализации локальных почтовых реплик

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

Компания XYZ со временем развернула почтовые серверы Lotus Domino для каждого нового местоположения, так как это было заложено в стандартную конфигурацию и поскольку у большинства узлов с менее чем 25 пользователями имелся канал связи с невысокой пропускной способностью. Большая часть почтовой коммуникации внутри компании происходит между этими узлами, а требования для пользователей электронной почты, находящихся в одном и том же офисе минимальны. Со временем количество почтовых серверов Lotus Domino вне центрального узла выросло до 37, а обслуживали они приблизительно 1400 пользователей, в то время как в главном офисе имелось два объединённых в кластер почтовых сервера Lotus Domino при 2900 пользователях. Финансовый отдел компании поставил и рассмотрел вопрос о количестве серверов и лицензий, необходимых для функционирования среды обмена электронными сообщениями. Чтобы уменьшить количество требуемых серверов и лицензий, и при это сохранить высокий уровень отказоустойчивости и балансировки нагрузки, отдел информационных технологий решил переместить часть пользователей в центральный офис и внедрить локальные почтовые реплики.

Группа IT оценила применяющиеся на данных момент модели использования подобного оборудования в компании, определив размещение серверов, количество пользователей и имеющуюся в наличие пропускную способность. В таблице 1 определены следующие категории.

Таблица 1. Оценка текущих моделей использования

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

Высшее руководство IT-отдела затребовало, чтобы все пользователи в окружении использовали один и тот же метод доступа. Для выполнения этой задачи, группа IT разработала и настроила политики Setup и Desktop для автоматизации процесса развёртывания. До принятия решения о переходе на локальные почтовые реплики в окружении существовала одна политика Desktop и одна Setup. Чтобы гарантировать, что среда не будет перегружена запросами на репликацию данных конечным пользователям, группа IT разработала политики Setup и Desktop для каждого места, таким образом специалисты могли контролировать процесс репликации. После перехода на локальные почтовые реплики, группа IT снова вернулась к меньшему числу политик Setup и Desktop, реализовав один набор политик для каждого сервера.

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

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

Довольно часто мы слышим, как люди говорят о локальной почте, сравнивая её с серверной. Что же это означает на самом деле? Репликация локальной почтовой базы данных предполагает, что копия, или реплика почтового файла пользователя находится на его рабочей станции, что позволяет пользователю работать с почтой без подключения к серверу. Периодически отправляется исходящая почта, а почтовый файл реплицируется с его версией на сервере, при этом происходит обмен изменениями между двумя базами данных. Изображение конфигурации окружения приводится на Рисунке 1.

Рисунок 1. Конфигурация окружения локальных почтовых реплик

Чтобы создать подобное окружение, вам выполнить некоторые настройки в клиенте Lotus Notes пользователя.

На рабочей станции пользователя необходимо создать реплику почтовой база данных пользователя. Строго рекомендуется использовать каталог директорий, чтобы позволить пользователям искать имена при адресации почтовых сообщений во время локальной работы. И вы, администратор, и пользователь можете создавать локальные реплики вручную с рабочей станции пользователя, либо при помощи политик Lotus Notes/Domino. После создания локальной реплики и каталога директорий, их необходимо настроить на синхронизацию с серверными репликами базы данных. Мы рекомендуем проводит репликацию базы данных каждые 30 минут. Настроив репликацию на 30 минут, вы гарантируете, что клиент не уменьшит производительность сервера и свою собственную слишком частой репликацией.

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

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

Может показаться, что вам или пользователю придётся выполнять довольно значительный объём изменений с рабочей станции пользователя. Хотя ручная конфигурация и возможна, вы также можете создать в окружении Lotus Notes/Domino политики, которые выполняют эти изменения без необходимости посещать отдельную рабочую станцию. Поскольку политики позволяют вам переконфигурировать большое число рабочих станций одновременно, нужно непременно позаботиться о том, чтобы эти изменения развёртывались гранулировано, чтобы не заполонить сеть одновременными запросами на создание реплик или почтовых файлов и каталогов директорий.

Улучшения в работе с локальными почтовыми репликами

Многие организации предпочитают, чтобы их пользователи работали с локальными почтовыми репликами по многим причинам. Однако традиционно имеется несколько недостатков данной конфигурации с точки зрения администрирования. Эти недостатки связаны конфигурированием рабочей станции, обучением пользователей и обеспечения пользователей службами каталогов. Благодаря усовершенствованиям репликации, политик и каталогов директорий в последних версиях Lotus Notes (V6.0 и более поздних), локальными почтовыми репликами даже стало легче управлять.

Сетевая компрессия

Начиная с Lotus Notes 6.x, в репликацию было внесено множество изменений, что значительно увеличило эффективность как с точки зрения быстродействия, так и использования сети. Введение компрессии при репликации уменьшает объём данных, передаваемых между клиентом и сервером до 30-40%, если сетевой траффик уже не сжимается роутерами или ПО для VPN. Вы можете прочитать более подробно о сетевой компрессии в статье developerWorks Lotus, " ."

Потоковая репликация

Кроме того, в Lotus Notes V6.0 появилась потоковая репликация. Эта функция повышает удобство пользователя при работе с локальной почтовой репликой. Во время репликации новые документы реплицируются в локальную почтовую реплику в порядке от самого маленького до самого большого по размеру. Это устраняет задержки, возникающие, когда одно сообщение с большим вложением, реплицирующееся первым, блокирует множество других сообщением. Кроме того, потоковая репликация позволяет пользователям просматривать документы и работать с ними, пока они реплицируются в локальную почтовую базу данных, так что больше не нужно ждать завершения репликации всех изменений, чтобы можно было начать работать с новыми сообщениями.

Асинхронное уведомление

Начиная с Lotus Notes V6.5.x, появилась асинхронное уведомление. Если клиент Notes работает с локальной почтовой репликой и имеет открытое подключение к серверу Domino, последний отправляет уведомление о новых сообщениях клиенту. Это уведомление, отправленное сервером Domino запускает на клиенте Notes репликацию почтового файла, доставляя новое сообщение в локальную почтовую реплику. Такая репликация происходит без вмешательства пользователя и не зависит от графика репликации, установленном в клиенте Lotus Notes. Данная функция позволяет пользователям получать входящее почтовое сообщение немедленно при работе с локальными репликами.

Политики

Политики появились, чтобы помочь в конфигурировании и управлении настройками на рабочей станции пользователя. Эта мощная функция даёт вам значительную гибкость при конфигурировании рабочих станций для пользователя. При помощи политик, вы можете выполнить все настройки, необходимые для обеспечения работы пользователя с локальной почтовой репликой, не посещая рабочую станцию пользователя. Ниже мы покажем вам, как настраивать политики для выполнения этого сценария. Для получения более подробной и общей информации по политикам см. следующие статьи developerWorks Lotus, " " и " ."

Каталоги директорий

Хотя улучшения репликации и политик и являются очень мощными функция, ключ к успешной реализации локальных почтовых реплик для пользователей лежит в создании каталога директорий. Можно создать два типа каталогов директорий.

• Сжатый или мобильный каталог директорий
  Мобильный каталог директорий содержит пользовательские и групповые записи из вашей Domino Directory и других директорий, которые вы можете выбирать. Мобильный каталог директорий сжимает записи из директорий, которые вы выбираете, в базу данных каталога директорий. Пропорция по умолчанию, используемая для сжимания записей, - приблизительно 255 записей (одна запись равняется одной пользовательской или групповой записи) в Domino Directory сжимаются в одну запись в мобильном каталоге директорий. В результате размер каталога директорий очень мал, однако сортировку можно осуществлять лишь по имени или фамилии, что должно быть указано при создании каталога директорий.
• Расширенный каталог директорий
  Расширенный каталог директорий базируется на пользовательских, групповых и серверных записях в вашей Domino Directory и других директориях по вашему выбору. Расширенный каталог директорий не предлагает сжатия записей, в результате чего расширенный каталог директорий гораздо больше по размеру, чем мобильный каталог директорий. Тем не менее, расширенный каталог директорий меньше чем Domino Directory, так как в нём не содержатся документы Connection, программные документы, и т. п. Он также очень гибок в плане удобства поисковых пользовательских функций, поскольку работает точно так же, как при выполнении поиска в обычной Domino Directory (то есть поиск по имени, фамилии, прозвищу, и т. д.)

Ключевым фактором удовлетворённости пользователей при работе с локальными почтовыми репликами является обеспечение возможности пользователей выполнять поиск имён в директории при работе в режиме offline. Как у мобильного, так и у расширенного каталога директорий есть свои преимущества и недостатки. Хотя мобильный каталог директорий меньше по размеру, расширенный каталог директорий обеспечивает более гибкие поисковые возможности. Эмпирическое правило выбора подходящего для вашего окружения каталога директорий должно основываться на размере каталога директорий. Если размер созданного расширенного каталога директорий превышает 50 MB, используйте вместо него мобильный каталог директорий. При использовании размера в качестве принципа выбора между двумя типами каталогов директорий принимается в расчёт время, которое пользователь будет тратить на репликацию каталога директорий и учитывается рост директории в будущем.

Теперь, когда мы обсудили ключевые элементы окружения, использующего локальные почтовые реплики, давайте рассмотрим, как оно создаётся и настраивается.

Настройка окружения

Необходимо выполнить множество настроек и конфигураций на пользовательской рабочей станции, чтобы у пользователей появилась возможность успешно и комфортно работать с локальными почтовыми репликами при пользовании электронной почтой. Эти настройки находятся в пользовательских установках (User Preferences) и документе Location на рабочей станции пользователя и приведены в Таблице 2.

Таблица 2. Обзор настраиваемых полей

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

Создание локальных реплик

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

ПРИМЕЧАНИЕ: Перед созданием локальной реплики каталога директорий, создайте сначала каталог директорий на сервере Domino. Более подробную информацию по созданию каталога директорий см. в .

Создайте новую реплику почтовой базы данных, выбрав почтовую базу данных на вашей рабочей станции, и выбрав File – Replication – New Replica. Примите для новой реплики все значения по умолчанию и нажмите OK, чтобы подтвердить создание новой реплики на локальной рабочей станции (см. Рисунок 2).

Рисунок 2. Диалоговое окно Create Replica

Настройка шифрования для локальной почтовой реплики

Для сохранности данных убедитесь, что почтовая база данных локально шифруется. Откройте окно Database Properties и нажмите на кнопку Encryption Settings. В диалоговом окне Encryption выберите опцию "Locally encrypt this database using", а затем выберите соответствующий уровень шифрования из выпадающего списка. По умолчанию используется Medium Encryption.

ПРИМЕЧАНИЕ: В зависимости от требований безопасности окружения, могут потребоваться различные уровни шифрования. Окружение Domino предусматривает три различных уровня шифрования. Более подробная информация по уровням шифрования содержится в Lotus Domino Administrator Help .

Пользовательские настройки

Диалоговое окно User Preferences содержит параметры конфигурации клиента. Для открытия диалогового окна выберите File – Preferences – User Preferences. Чтобы обеспечить своевременное появление новой почты в локальной реплике почтового файла, выберите вкладку Mail - General и выполните следующие настройки (см. Рисунок 3):

• В разделе Configuration введите или перейдите к имени файла локального каталога директорий в поле Local address books.
• В разделе Receiving выберите опцию "Check for new mail every", а затем установите интервал пять минут.
• В разделе "When New Mail Arrives" выберите опцию Automatically refresh Inbox.

Рисунок 3. Настройки почты в диалоговом окне User Preferences

Выберите вкладку Replication и сконфигурируйте настройки по умолчанию, применяемые при создании новых реплик (см. Рисунок 4).

• Выберите опцию "Create full text index for searching", чтобы гарантировать, что все новые реплики готовы для поиска.
• Выберите опцию Locally encrypt using, а затем определите соответствующий уровень шифрования. Это гарантирует, что все базы данных, реплицируемые локально, по умолчанию шифруются, что обеспечивает защиту данных.

Рисунок 4. Настройки репликации в диалоговом окне User Preferences

Настройка документа Location

При обычном процессе установки клиента, клиент Notes настроен на использование почтовой базы данных и информации о директориях на сервере. Чтобы пользователь мог работать с локальной почтовой репликой, измените документ Location в Personal Address Book так, чтобы использовались локальные ресурсы рабочей станции, а не ресурсы сервера.

Откройте документ Location, выберите вкладку Mail и установите следующие значения (см. Рисунок 5):

• Mail file location (Расположение почтового файла): Local (Локально)
• Transfer outgoing mail messages if (Отправить исходящую почту если): 1 (messages pending) (сообщение отложено)

Рисунок 5. Настройка опций почты в документе Location

Следующий шаг - включить репликацию баз данных с сервера. На вкладке Replication документа Location установите следующие значения:

Рисунок 6. Настройка опций репликации в документе Location

Настройка серверных политик

В предыдущем разделе статьи вы рассмотрели, как вручную настраивать локальные почтовые реплики для пользователей в вашем окружении. Эти действия можно автоматизировать, реализовав политики Lotus Notes/Domino. В следующих разделах проводится обзор реализации политик, необходимых для подготовки окружения для локальных почтовых реплик. Более подробный обзор политик Lotus Domino содержится в Lotus Domino Administrator Help .

Существует два типа политик, используемых для инициализации и поддерживания настроек, связанных с локальными почтовыми репликами. Политики Setup применяются к новым клиентам в ходе их настройки и ввода в окружение. Важно иметь в виду, что политики Setup применяются только тогда, когда клиент Notes настраивается в первый раз. Политики Desktop применяются к клиенту Notes каждый раз, когда клиент запускается и открывает сеанс связи с сервером Lotus Domino. Политика Desktop очень полезна для задействования параметров конфигурации для пользователей, у которых уже есть клиент client.

Создание политики Setup

Следующие шаги проведут вас через создание политики Setup, с упором на элементы, специфичные для локальных почтовых реплик. Если у вас уже имеется настроенная политика Setup, вы можете её модифицировать, чтобы внести указанные здесь изменения с целью задействовать локальные почтовые реплики. Как было указано ранее, политика Setup применяется только к новым конфигурациям. Вы должны внести эти настройки в политику Desktop, чтобы убедиться, что они применяются на постоянной основе.

Откройте Domino Directory и перейдите в представление Policies\Settings. Нажмите на кнопку Add Settings и выберите Setup для создания политики Setup. На вкладке Basics документа Setup Settings выберите опцию "Create local mail file replica" (см. Рисунок 7).

Рисунок 7. Настройка основных опций в политике Setup Settings

На вкладке Databases документа добавьте ссылку на базу данных для каталога директорий в поле Mobile Directory Catalog. Затем выберите вкладку Preferences, а на подвкладках Mail и News установите интервал проверки новой почты на пять минут и выберите опцию Automatically Refresh Inbox.

На подвкладке Preferences - Replication включите "Create replicas ready for searching," в поле Encrypt replicas установите значение Locally encrypt, а также для поля Encrypt установите желаемый уровень шифрования (High, Medium, Low). См. Рисунок 8.

Рисунок 8. Настройка опций репликации в политике Setup

Создание и расширение политики Desktop

При помощи лишь базовой функциональности, поставляемой с политиками Setup и Desktop, вы не можете произвести полную настройку документа Location. Изменение настроек типа почты, включение репликации и управление графиком репликации не является частью опций по умолчанию документа политики Desktop. Тем не менее, вы можете настраивать документ политики Desktop в Domino Directory для получения контроля над всеми настройками в документе Location пользователя. В данном разделе содержится информация по настройке документа политики Desktop и конфигурированию и управлению этими настройками.

Способность настраивать формы политики Desktop для управления параметрами Notes.ini и настройками документа Location описывается в технической заметке Lotus Support, " ." Мы рекомендуем уменьшить влияние настройки директории при помощи создания отдельной подформы, которую вы можете вставить в форму политики Desktop.

Прежде всего, откройте Domino Directory в IBM Lotus Domino Designer. Перейдите в раздел Shared Code\Subforms базы данных и создайте новую подформу с именем $ClientLocationDoc.

В этой подформе создайте таблицу с двумя вкладками: Mail и Replication. На вкладке Mail воссоздайте конфигурацию вкладки Mail документа Location в Personal Address Book. Тем не менее убедитесь, что вы добавляете LocAll в начало имени в каждом поле, как показано на Рисунке 9.

ПРИМЕЧАНИЕ: Если вы копируете таблицу из документа Location в Personal Address Book, непременно измените имена полей во всех hide-when- и field-формулах (по умолчанию входная трансляция, входная валидация и т. д.) для принятия LocAll, добавленного в именам полей. Кроме того, убедитесь, что вы удалили поля MailFile и MailFormat из скопированной таблицы. Эти поля либо уже находятся где-то в документе Policy, либо относятся к конкретному пользователю и не должны управляться политиками.

После заполнения вкладки Mail подформы, перейдите к вкладке Replication для воссоздания конфигурации вкладки Replication документа Location в Personal Address Book. Опять же, убедитесь, что вы добавили LocAll в начало имени каждого поля, как показано на Рисунке 10.

Рисунок 10. Создание новой подформы Replication в Domino Directory

ПРИМЕЧАНИЕ: Воссоздайте таблицу из документа Location в Personal Address Book, однако не выполняйте копирование и вставку таблицы, поскольку большинство полей документа Location являются полями общего пользования. Создав эти поля в вашей подформе как индивидуальные, вы можете поддерживать независимость подформы в будущем и принимать ваши изменения всех hide-when- и field-формул (по умолчанию входная трансляция, входная валидация и т. д.), а также добавлять LocAll ко всем именам полей без влияния на другие общие поля в Domino Directory.

После заполнения подформы $ClientLocationDoc сохраните и закройте её. Затем откройте форму "Policy Settings\Desktop Settings". В этой форме вставьте ещё одну вкладку в главную таблицу между вкладками Databases и Dial-up Connections. Назовите эту новую вкладку Location Document и вставьте вашу новую подформу в эту вкладку (см. Рисунок 11).

Рисунок 11. Добавление новых подформ к форме Desktop Settings Policy

ПРИМЕЧАНИЕ: Создайте копию формы "Policy Settings\Desktop Settings" перед её изменением. Кроме того отключите возможность обновления из шаблона оформления Domino Directory, чтобы ваши изменения не перезаписывались при замене или обновлении шаблона во время регулярного обслуживания директории.

После вставки новой подформы в новую вкладку сохраните и закройте форму "Policy Settings\Desktop Settings". Проверьте форму, чтобы убедиться, что ваши изменения отображаются в директории и их можно настраивать при помощи значений.

После завершения настройки откройте Domino Directory с помощью клиента Lotus Notes и перейдите в представление Policies\Settings. Нажмите кнопку Add Settings и выберите Desktop для создания политики Desktop.

На вкладке Basics документа, в разделе Server Options, выберите опцию "Create local mail file replica". На вкладке Databases документа добавьте ссылку на базу данных для каталога директорий на поле мобильного каталога директорий.

На новой вкладке Location Document, добавленной вами, выберите вкладку Mail (см. Рисунок 12). Установите следующие параметры:

• Mail file location (Размещение почтового файла): Local (Локально)
• Domino mail domain: Имя вашего почтового домена Domino
• Recipient name type-ahead (Опережающий ввод имени получателя): Local Only (Только локально)
• Mail addressing (Адресация почты): Local then Server (Локально, а затем на сервере)
• Transfer outgoing mail if (Отправить исходящую почту если): 1 messages pending (сообщение отложено)

Рисунок 12. Настройка Location Document – Mail settings в документе Desktop Settings

На новой вкладке Location Document выберите вкладку Replication (см. Рисунок 13). Установите следующие параметры:

• Enable replication (Включить репликацию): "Replication is enabled for this location (Репликация включена для данного узла)"
• Create new replicas (Создание новых реплик): Immediately (Немедленно)
• Replicate when Notes starts (Репликация при запуске Notes): "Replicate when Notes starts" и Prompt before replicating (Подсказка перед репликацией)
• Schedule (График): Replication Interval (Интервал репликации)
• Replicate daily between (Репликация ежедневно): 7:00 AM – 7:00 PM
• Repeat every (Повторять каждые): 30 minutes
• Days of week (Дни недели): ПН, ВТ, СР, ЧТ, ПТ
• Replicate when Notes ends (Репликация при завершении Notes): "Prompt to replicate when Notes shuts down (Подсказка при выходе из Notes)" и "If outbox is not empty (Если папка Исходящие не пуста)"

Рисунок 13. Настройка Location Document – Replication в документе Desktop Settings Policy

На подвкладке Preferences - Mail and News документа Policy установите интервал проверки новой почты в пять минут и включите опцию Automatically Refresh Inbox. На подвкладке Preferences - Replication включите "Create replicas ready for searching,", в поле Encrypt replicas установите Locally encrypt, а в поле Encrypt using - желаемый уровень шифрования (High, Medium, Low). Сохраните и закройте документ политики Desktop.

Вопросы обучения конечных пользователей и сотрудников технического сопровождения

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

Уведомление о приходе новой почты

Клиент Lotus Notes регулярно проверяет новую почту на сервере Domino. Если на сервере есть новые сообщения, которые ещё не были реплицированы на клиент, пользователь получает уведомление о приходе новой почты, однако он не в состоянии найти новую почту в локальной папке Inbox. Задержка в доставке сообщений зависит от размера почтового сообщения и загруженности сервера. Когда пользователь использует серверную копию почтовой базы данных, сообщение появляется в Inbox до уведомления.

Задержка при отправке сообщений на сервер перед выключением

Если сообщение отправляется до закрытия клиента Notes, может не хватить времени на отправку сообщения на сервер. В конфигурации указано отправлять сообщения немедленно, но в зависимости от размера сообщения или типа соединения с сервером, сообщение может быть в процессе отправки. Вы увидите следующее сообщение (см. Рисунок 14), если сообщение не было отправлено полностью.

Рисунок 14. Предупреждение о наличии исходящего сообщения, ожидающего отправки, перед закрытием клиента

Репликация только почты для уменьшения нагрузки на сервер

Одна из проблем с пользователями, использующими локальные почтовые реплики, это то, что они склонны реплицировать все базы данных на вкладке Replication вместо использования опции "Replicate Mail Only". На вкладке Replication нажмите кнопку Start Now и выберите одно из нижеуказанного:

• Start Now. Запускает репликацию всех баз данных с вкладки Replication.
• Start Mail Only Now. Запускает репликацию почтовой базы данных.
• Start High Priority Databases Now. Запускает репликацию всех баз данных, отмеченных как имеющих высокий приоритет.

Обратите на Notice галочку слева от почтовой базы данных на вкладке Replication. Она включает/выключает репликацию базы данных; пользователи могут выключить эту опцию. Политики не включают эту опцию принудительно. Следовательно, если пользователь отключает репликацию почтового файла, она не будет происходить, пока пользователь снова не отметит базу данных.

Опции настройки вкладки Replication

Вы можете модифицировать вкладку Replication под нужды пользователей. Ниже даётся набор инструкций по указанию пользователям опций конфигурации вкладки Replication.

Пользователи могут нажать на направленную вниз стрелку на кнопке Replication (см. Рисунок 15). Они могут менять размеры иконок, изменять режим отображения вкладки, отображать все базы данных или только отмеченные для репликации или создавать папки для организации баз данных.

Рисунок 15. Изменение внешнего вида и функциональности вкладки Replication

Заключение

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