При выполнении синхронизации платформа WebSphere должна иметь возможность идентифицировать файлы, которые подверглись изменению и, следовательно, для которых необходимо провести синхронизацию. Для этого в WebSphere используется следующая схема.
• Агент узла и администратор развертывания хранят вычисленную контрольную сумму (digest) по каждому конфигурационному файлу, управление которым они осуществляют. Эти значения сохраняются в памяти. Если контрольная сумма по файлу вычисляется заново и не совпадает с той, которая хранится в памяти, это указывает на то, что файл изменился.
• Также в памяти хранится «время обновления» (epoch) для каждой папки хранили ща и для всего хранилища в целом. Оно используется для определения того, изменялись ли файлы в директории. Если конфигурационный файл был изменен с помощью одного из административных интерфейсов WebSphere, то время обновления всего хранилища и время обновления той папки, где находится изменившийся файл, изменяется.
Обратите внимание, что ручное внесение изменений в файл конфигурации не приведет к изменению контрольной суммы. Как измененные помечаются только файлы, обновленные с помощью административных клиентов. Вносить изменения в конфигурационные файлы вручную не рекомендуется, но если вы все же сделали это, при принудительной синхронизации такие файлы также будут учитываться.
• Если в ходе операций синхронизации «время обновления» хранилища с момента предыдущей синхронизации изменилась, то сравнивается «время обновления» отдельных папок. Если «время обновления» для директорий узла и ячейки не сов падает, то пересчитываются контрольные суммы для всех файлов директории, включая изменившийся файл.
Планирование синхронизации
Расписание синхронизации файлов устанавливается с помощью административного клиента. Существуют следующие варианты.
• Автоматическая синхронизация.
Синхронизация может производиться автоматически, для чего нужно настроить службу синхронизации файлов агента узла. Соответствующие параметры позволяют вам: выполнять периодическую синхронизацию с указанным периодом времени; (по умолчанию данный параметр включен, и задан интервал в одну минуту); ○ выполнять синхронизацию при запуске сервера.
Синхронизация выполняется перед тем, как агент узла запустит сервер. Обратите внимание, что если вы запустите сервер командой startServer, этот параметр никакого эффекта иметь не будет.
• Явная/принудительная синхронизация.
Синхронизацию можно явным образом запустить в любое время с помощью административного клиента.
Совет. В рабочей среде интервал автоматической синхронизации следует увеличить в сравнении с заданной по умолчанию одной минутой, чтобы уменьшить нагрузку на вычислительные мощности и на сеть.
Синхронизация изменений, внесенных вручную
Важно. Хотя существует техническая возможность редактирования конфигурационных файлов вручную, этого не следует делать без абсолютной необходимости. Ручное редактирование имеет ряд недостатков, в том числе следующие.
• Если вы используете wsadmin и административную консоль, вы можете пользоваться
процессом проверки перед применением изменений. При ручном редактировании такой возможности нет.
• Обновления, сделанные вручную, не помечаются для синхронизации и будут потеряны при следующей синхронизации, если только вы не сделаете их прямо в главном хранилище и не запустите синхронизацию принудительно.
Ручное редактирование может использоваться в ситуации выявления проблем. Например, если вы задействовали систему безопасности WebSphere, но не настроили ее должным образом, вы не сможете запустить WebSphere и, следовательно, не будете иметь доступа к административным клиентам. В этом случае весьма полезной будет возможность вручную отключить систему безопасности, чтобы можно было запустить WebSphere и изучить конфигурацию. В теме «Configuration Document Descriptions» (Описание конфигурационных документов) Информационного центра перечислены несколько конфигурационных файлов, у которых есть параметры, не видимые через административных клиентов. Если вы сочтете необходимым редактировать файлы вручную, эта тема поможет вам не потерять ваши изменения.
Если изменения в конфигурационный файл вносятся путем редактирования этого файла, то контрольная сумма для этого файла не пересчитывается, поскольку «время обновления» директорий по-прежнему совпадает и процесс синхронизации не распознает, что файлы изменились.
Однако отредактированные вручную конфигурационные файлы в главном хранилище ячейки могут быть учтены, если в хранилище происходит сброс «времени обновления» с повторным чтением всех файлов и пересчетом всех контрольных сумм. Можно произвести сброс «точки отчета» либо в главном хранилище, либо в хранилище узла.
• Сброс «времени обновления» главного хранилища конфигурации ячейки приво дит к тому, что все внесенные вручную изменения главной конфигурации репли цируются в узлы, где данные файлы находятся.
• Сброс «времени обновления» хранилища узла приводит к тому, что все внесенные вручную изменения на локальном узле будут перезаписаны теми файлами, которые есть в главном хранилище, независимо от того, были внесены изменения в главное хранилище или нет. Любые сделанные вручную изменения главного хранилища будут перенесены в узел.
Главное отличие между сбросом «времени обновления» ячейки и сбросом «времени обновления» узла состоит в том, что сброс «времени обновления» ячейки затрагивает всю ячейку, а не только один узел.
Все это относится и к установленным приложениям. Они обрабатываются точно так же, как другие конфигурационные файлы хранилища. Для каждого установленного приложения в хранилище существует EAR-файл, а также несколько конфигурационных файлов, связанных с установкой данного приложения.
Если вы вручную измените EAR-файл и выполните сброс «времени обновления» главного хранилища ячейки, то измененный EAR-файл будет реплицирован на узлы, где, согласно настройкам конфигурации, он будет выполняться, и будет помещен в соответствующее место узла, где сервер приложений сможет его обнаружить. Приложение на этом узле будет остановлено и автоматически перезапущено, чтобы все изменения были учтены и стали доступны для сервера приложений.
Важно. Ручное изменение EAR-файла лучше выполнять опытным пользователям, иначе возможны непредсказуемые последствия.
Если вы вручную отредактируете один из конфигурационных файлов развертывания приложения и выполните сброс «времени обновления» хранилища, изменение будет реплицировано на все узлы, где оно применяется, и оно будет учтено при следующем перезапуске приложения на данном узле.
Сброс «времени обновления» главного хранилища ячейки
Важно. Ручное изменение EAR-файла лучше выполнять опытным пользователям, иначе возможны непредсказуемые последствия.
Примечание. Использование wsadmin описывается в Главе 5, «Администрирование
с использованием скриптов». Единственное, что вам может понадобиться знать о wsadmin при выполнении этих задач — это то, что нужно запустить wsadmin на порту SOAP-коннектора того процесса, для которого вам нужно выполнять команды. По умолчанию запуск производиться на порту 8879. Если процесс, к которому вы подключаетесь, имеет другой номер порта, запустите wsadmin с аргументом -port.
Чтобы произвести сброс «времени обновления» главного хранилища ячейки, выполните следующие действия.
Откройте командную строку, перейдите в директорию <dmgr_profile_home>/bin и запустите сеанс wsadmin. Обратите внимание, что администратор развертывания должен быть запущен. Используйте следующую команду:
cd <install_root>\profiles\Dmgr01\bin
wsadmin
Введите следующие команды:
Wsadmin>set config [$AdminControl queryNames *:*,type=ConfigRepository,process=dmgr]
wsadmin>$AdminControl invoke $config refreshRepositoryEpoch
Вы увидите число, которое возвратит операция refreshRepositoryEpoch, например, 1047961605195, как это показано в примере 2.1.
Пример 2.1. Сброс «времени обновления» главного хранилища ячейки <install_root>\profiles\Dmgr01\bin>wsadmin
WASX7209I: Connected to process «dmgr» on node DmgrNode using SOAP connector;
The type of process is: DeploymentManager WASX7029I: For help, enter: «$Help help»
wsadmin>set config [$AdminControl queryNames *:*,type=ConfigRepository,process=dmgr]
WebSphere:platform=common,cell=DmgrCell,version=6.1.0.0,name=repository,mbeanId entifier=repository,type=ConfigRepository,node=DmgrNode,process=dmgr
wsadmin>$AdminControl invoke $config refreshRepositoryEpoch 1098317369266
wsadmin>
При этом будет сброшен весь набор контрольных сумм хранилища ячейки. При следующей операции синхронизации для всех файлов главного хранилища будет произведен пересчет контрольных сумм. Все внесенные вручную изменения будут реплицированы на соответствующие узлы.
Сброс «времени обновления» хранилища узла
Существует несколько способов сбросить «время обновления» хранилища узла для выполнения синхронизации.
• В ходе сеанса wsadmin, подключенного к администратору развертывания или агенту узла, введите следующую команду:
wsadmin>set config [$AdminControl queryNames *:*,type=ConfigRepository,process=nodeagent]
wsadmin>$AdminControl invoke $config refreshRepositoryEpoch
При этом будет выполнен сброс набора контрольных сумм узла. Все файлы, не соответствующие тому, что есть в хранилище, будут перезаписаны.
В примере 2.2 приводится общий обзор сброса хранилища узла.
Пример 2.2. Сброс «времени обновления» хранилища узла
<install_root>\profiles\<server_name>\bin>wsadmin -port 8883
WASX7209I: Connected to process «nodeagent» on node AppSrvrNode using SOAP connector; The type of process is: NodeAgent
WASX7029I: For help, enter: «$Help help»
wsadmin>set config [$AdminControl queryNames *:*,type=ConfigRepository,process=nodeagent]
WebSphere:platform=common,cell=DmgrCell,version=6.1.0.0,name=repository ,mbeanIdentifier=repository,type=ConfigRepository,node=AppSrvrNode,proc ess=nodeagent
wsadmin>$AdminControl invoke $config refreshRepositoryEpoch 1098397549240
• В административной консоли администратора развертывания выберите пункт System Administration (Администрирование системы) → Nodes (Узлы), и вы увидите список узлов ячейки. Обратите внимание на имеющиеся на странице кнопки Synchronize (Синхронизация) и Full Resynchronize (Полная ресинхрониза ция). Кнопка Synchronize вызывает обычную операцию синхронизации без перечитывания файлов. Кнопка Full Resynchronize — это функция сброса и пересчета. Выберите узел или узлы, на которые должны быть перенесены сделанные вручную зменения, и нажмите кнопку Full Resynchronize.
• Используйте команду syncNode. Эта команда представляет собой самостоятельную программу, которая запускается отдельно от агента узла. У нее нет кеша со значениями «точек отсчета», которые могли бы использоваться для оптимизированной синхронизации, и, следовательно, она выполняет полную синхронизацию. По этой же причине, если вы перезапускаете агент узла, самая первая синхронизация всегда будет полной синхронизацией. Обратите внимание, что для этого нужно остановить агент узла.
Команда syncNode при базовой инсталляции располагается в директории bin. Чтобы использовать эту команду, введите в командную строку следующее:
cd <дир_профиля>\bin
syncNode <хост_ячейки>
В примере 2.3 показано использование команды syncNode.
Пример 2.3. Использование команды syncNode
<install_root>\profiles\<server_name>\bin>stopnode
ADMU0116I: Tool information is being logged in file
<install_root>\profiles\<server_name>\logs\nodeagent\stopServer.log ADMU0128I: Starting tool with the AppSrv01 profile ADMU3100I: Reading configuration for server: nodeagent ADMU3201I: Server stop request issued. Waiting for stop status. ADMU4000I: Server nodeagent stop completed.
<install_root>\profiles\<server_name>\bin>syncnode carlavm2 ADMU0116I: Tool information is being logged in file <install_root>\profiles\<server_name>\logs\syncNode.log ADMU0128I: Starting tool with the AppSrv01 profile
ADMU0401I: Begin syncNode operation for node AppSrvrNode with Deployment Manager carlavm2: 8879
ADMU0016I: Synchronizing configuration between node and cell.
ADMU0402I: The configuration for node AppSrvrNode has been synchronized with Deployment Manager carlavm2: 8879
При использовании этого совета помните, что в обычных условиях все файлы приложения упакованы в EAR-файл данного приложения. Однако рассмотрим конфигурационный файл, специфичный для приложения. Любые изменения, внесенные в этот файл, потребуют, чтобы вы обновили EAR-файл и выполнили синхронизацию для всего приложения.
Совет. Хранилище имеет определенную гибкость в том смысле, что в нем нет заданного списка разрешенных типов документов. Вы можете добавлять в него любой файл по своему выбору. Возможно, у вас есть уникальные конфигурационные данные, которые должны использоваться на всех узлах. Вы можете поместить их в папку config/cells/<имя ячейки>, и они будут синхронизироваться со всеми узлами. Если эти данные применяются только на одном узле, вы можете поместить их в папку, соответствующую данному узлу, и они будут синхронизироваться только с этим узлом. То же относится и к любым дополнительным документам в папке уровня сервера.
Один вариант — это поместить файл свойств в директорию размещения приложения в главном хранилище конфигурации, чтобы он реплицировался автоматически на все узлы, где установлено приложение, а весь EAR-файл при этом не реплицировался. Затем вы можете провести обновление файла свойств с помощью ExtensionMBean в главном хранилище, и потом обычная синхронизация реплицирует эти изменения в узлы без необходимости синхронизировать весь EAR-файл и перезапускать приложение.
