|
Question |
1.What is file synchronization service?
2. How does Synchronization actually work? Does the Synchronization
Service synchronize changes to the master repository made by manually
editing a configuration file, for example, using Notepad?
3. Are installed Applications covered in synchronization? |
|
|
|
Answer |
1.What is the file synchronization service?
The Deployment Manager will maintain a centralized repository of
configuration data. Each node also has their own local configuration
files. The file synchronization service is the administrative service
responsible for keeping the configuration documents that are distributed
across the IBM® WebSphere® Application Server cell up to date. This
service runs in the deployment manager and node agents, and ensures that
the configuration changes made to the cell repository will be propagated
to the appropriate node repositories.
During a configuration synchronization operation, a node agent checks with
the deployment manager to see if any configuration documents that apply to
the node have been updated. New or updated documents are copied to the
node repository, and deleted documents are removed from the node
repository.
2. How does synchronization actually work? Does the synchronization
service synchronize changes to the master repository made by manually
editing a configuration file, for example, using Notepad?
Both the node agent and deployment manager keep a calculated digest for
each file in the configuration they manage (master cell repository managed
by deployment manager, local node repository managed by node agent). These
digest values are stored in memory.
Also stored in memory are "epochs" for the folders in the repository and
for the repository overall. These epochs are used to determine whether any
files in the directory have changed.
If a change to a configuration file is made through the administration
programs (Administration console, wsadmin, or other), then the overall
repository epoch and the epoch for the folder in which that file resides
is modified. During configuration synchronization operations, if the
repository epoch has changed since the previous synchronization operation,
then individual folder epochs will be compared. If the epochs for
corresponding node and cell directories do not match, then the digests for
all files in the directory are recalculated, including that changed file.
If a change to a configuration file is made by editing the file and
bypassing the administration programs, then the digest is not recalculated
because the epochs for the directories continue to match.
The algorithm for synchronization by default only compares these epochs
between node agent and deployment manager. The files are not read on every
synchronization operation. So, by DEFAULT, manual edits to the
configuration files in the cell repository are not picked up during
"normal synchronization" operations. This was a compromise reached to
allow best performance under normal conditions since editing the files
manually is not a recommended best practice.
But manual edits of configuration files in the master cell repository can
be picked up if the repository is "reset" so that it goes back out and
re-reads all the files and recalculates all of the digests. There is a JMX
operation on the ConfigRepository MBean that resets the repository epoch
so that the next sync operation will result in recalculating the file
digests and picking up any manual changes to the master cell repository
configuration files.
You can reset either the master cell repository epoch or the node
repository epoch. If you reset the master cell repository, then any manual
changes made in the master configuration repository will be picked up and
replicated to the nodes where the file is applicable. If you reset the
node repository, then any manual changes to the local node files will be
wiped out (overwritten) by whatever is in the master cell repository,
regardless of whether the cell repository was changed or not. Any manual
changes in the master repository will be picked up and brought down to the
node. The main difference between cell reset and node reset is that cell
reset is likely to impact the entire cell, not just one node.
Here are instructions for performing a reset of the master cell
repository:
In a wsadmin session connected to the deployment manager, enter the
following (blue text):
wsadmin>set config [$AdminControl queryNames
*:*,type=ConfigRepository,process=dmgr]
wsadmin>$AdminControl invoke $config refreshRepositoryEpoch
You will see a number returned by the refreshRepositoryEpoch operation
(for instance: 1047961605195). This resets the entire cell repository
digest set. So, on the next sync operation, all files in the master cell
repository will have their digests recalculated and any manual changes
will be replicated to the applicable nodes.
There are a couple of ways to perform node "repository reset".
a) In a wsadmin session connected to the deployment manager (or node
agent), enter the following (blue text):
wsadmin>set config [$AdminControl queryNames
*:*,type=ConfigRepository,process=nodeagent]
wsadmin>$AdminControl invoke $config refreshRepositoryEpoch
This resets the node digest set. Any file on the local node that does not
match what is in the repository will be overwritten.
b) In the Network Deployment Administration console, you can click on
"System Administration" and then "Nodes" to see a list of the nodes in the
cell. You will notice "Synchronize" and "Full Resynchronize" buttons on
the page. The "Synchronize" button is "normal synchronization" (no
re-reading of the files). The "Full Resynchronize" button is the "reset
and recalculate" function. Select the node or nodes to be updated with
manual changes and click on the "Full Resynchronize" button.
3. Are installed applications covered in synchronization?
Yes, installed applications are treated like the other configuration files
in the repository and are synchronized. For installed applications, there
is an EAR file in the repository and also some configuration files
associated with the deployment of the application. Normal synchronization
operations will synchronize the application files that have been updated
with the Administration programs.
If you manually change the EAR file, this is not recommended, and reset
the master cell repository (to recalculate the digests), the changed EAR
file will be replicated out to the nodes where it is configured to be
served and it will be expanded in the appropriate location on that node
for the application server to find it. |
|
|
|
|
Cross Reference information |
Segment |
Product |
Component |
Platform |
Version |
Edition |
Application Servers |
Runtimes for Java Technology |
Java SDK |
|
|
|
|
|
|