III - L’AVENIR
O RGANISER LA RATIFICATION DU TEXTE VIA UN REFERENDUM EUROPEEN EN 2009
Archive Cache Server distinguishes between read and write requests. In case of read requests, the Archive Cache Server tries to satisfy the request from its local cache instead of transferring the document via slow WAN from an Archive Server. If not found in local cache, the document will be cached for later access.
In case of write requests, Archive Cache Server distinguishes between two operational modes. This mode can be set per logical archive.
write through
In this mode, all documents are transferred to the Archive Server, but on the fly, they are also cached in the local store to speed up later read requests.
write back
In this mode, all the documents are cached in the local store of the Archive Cache Server. Archive Server just will be informed that there are new documents residing on the Archive Cache Server. The configured Copy_Backjob will later transfer these documents to the Archive Server.
Typical scenario for using the “write back” mode
You have a quite slow network connection between an Archive Cache Server and an Archive Server. During the day, a lot of new documents are written to the Archive Cache Server, which should not additionally burden the slow network connection.
Archive Server is just informed about new documents. During the night, the WAN is much faster, because of reduced network traffic. The documents just stored by Archive Cache Server on the Archive Cache Server can now be safely transferred to the Archive Server in an efficient way. This can be achieved by appropriate
scheduling of the Copy_Back job. If this scenario does not exactly fit your
environment or your demands – e.g., because you have full load round the clock or you have high security demands – it is recommended to use “write through” mode (see also “Restrictions Using Archive Cache Server” on page 194).
The following figure shows a simple outlay of a scenario with only one Archive Server and one Archive Cache Server. In real environments, one Archive Cache Server can support more than one Archive Server and one Archive Server can have more than one Archive Cache Server attached. Clients can also access the Archive Server directly without using Archive Cache Server. This depends on the
configuration; see “Configuring Access Via an Archive Cache Server” on page 203.
Figure 14-1: Archive Cache Server scenario
As the diagram hints, the Administration Server is central to the coordination of the cache scenario at large. Administration Client is used to configure the settings of each Archive Cache Server and the associated clients and archives.
Important
To ensure accurate retention handling, the clock of the Archive Cache Server must be synchronized with the clock of the Archive Server.
14.1 Restrictions Using Archive Cache Server
The Archive Cache Server ideally is transparent to any client, which means it must behave the same way as the Archive Server. Especially for “write back” documents, this paradigm cannot be followed completely. The following table shows all known restrictions.
14.1 Restrictions Using Archive Cache Server
Table 14-1: Restrictions using Archive Cache Server
Topic Description
Restrictions valid for “write back”
MTA documents MTA documents can be stored but the single document in an MTA document cannot be accessed until they are transferred to an Archive Cache Server.
Attribute Search Attribute Search in print lists is not available until the content is transferred from an Archive Cache Server to the related Ar-chive Server.
VerifySig The signature verification is processed for write back items but the signer chain is not verified (no timestamp certificates are available on related Archive Server).
Deletion behavior To avoid problems with deletion, do not use the following archive settings:
• Original Archive > Properties > Security > Document Deletion > Deletion is ignored (see also “Configuring the Archive Security Settings” on page 79)
• Archive Server > Modify Operation Mode > Documents cannot be deleted, no errors are returned (see also “Setting the Operation Mode of Archive Server” on page 332 Retention behavior As long as write back documents are just stored on the
Archive Cache Server, there is no protection based on the document retention. After transferring documents to a related Archive Server, the retention behavior gets effective. If there is no client retention, the retention setting of the logical archive is used.
In special case of event-based retention, the expiring date can be extended up to 24 hours.
Audit There are no audit trails for documents as long as they are not transferred to the related Archive Server.
Update Document This call is not supported for write back documents.
migrateDocument Results in an error if just the pool name or storage tier is changed.
Important: Target archives must be enabled to be cached by this Archive Cache Server, otherwise update calls will fail.
Versioning of compo-nents
As long as components are just stored on the Archive Cache Server, there is no version control! This means, after a success-ful modification, the modified component is available, but the version number will not be increment. A subsequent info call still will deliver back version “1” of the just modified compo-nent, until the component has been transferred to the related Archive Server.
Topic Description
Transfer and commit Write-back documents are transferred to the related Archive Server in a two-phase process:
Phase 1: document is requested
Phase 2: commit to previously requested document is sent To avoid any inconsistency, any “update” client request that comes in between phase 1 and 2 cannot be satisfied and an HTTP_CONFLICT error is returned to the client.
Maintenance mode Documents cannot be accessed during maintenance mode.
Disabled archives Documents cannot be modified if the logical archive is dis-abled.
Document protection Document protection cannot be set in write-back mode. If document protection is set while creating the document, the document protection will not be stored nor evaluated on the Archive Cache Server.
Restrictions valid for “write through” and “write back”
Component name map-ping
In write back mode, an error occurs if you try to create a component matching one of these names:
• <n>.pg
• im
To support all component names, create a new entry in the configuration:
1. Select Runtime and Core Services > Configuration >
Content Service.
2. Click New Property in the action pane.
3. Enter the property name:
contentservice.ILLEGALCOMPONENTNAMES 4. Select Global as Scope and String as Datatype.
5. Click Next.
6. Leave the Property Value field empty and select Requires Restart?
7. Click Next and then Finish to resume.
Timestamp verification A mandatory signature check before reading can be config-ured for each archive. This setting is ignored for cached doc-uments.
Encryption, Compression,
Single Instance, Blobs Content on the Archive Cache Server gets neither encrypted nor compressed, regardless of the archive setting.
Destroy Documents are not destroyed on the Archive Cache Server, regardless of the archive setting.
14.2 Configuring an Archive Cache Server in the Environment
14.2 Configuring an Archive Cache Server in the Environment
14.2.1 Adding an Archive Cache Server to the Environment
The first step for using an Archive Cache Server is to make it known to an Archive Server using Administration Client. To do this, you have to add an Archive Cache Server to the environment of the logical archive.
To add an Archive Cache Server:
1. Select Cache Servers in the Environment object in the console tree.
2. Click New Cache Server in the action pane.
3. Enter the Archive Cache Server parameters:
Cache server name
Unique name of the Archive Cache Server. This name is used throughout the configuration and administration to refer to the Archive Cache Server.
Description
Brief, self-explanatory description of the Archive Cache Server.
Host (client)
Physical host name to address the Archive Cache Server when a client accesses it.
Note: Instead of the host name, you can also use IPv4 addresses.
However, IPv6 addresses are not supported.
'Copy back' job
Displays the associated Copy_Backjob. This entry cannot be changed.
Host (archive server)
Physical host name used by the Archive Server to communicate with an Archive Cache Server. This name can be different from the host name relating to client.
Note: Instead of the host name, you can also use IPv4 addresses.
However, IPv6 addresses are not supported.
The <name to use by ACS for itself> name and the Host (archive server) name must be identical. Otherwise, problems will arise during the write-back scenario.
Port, Secure port, Context path
Specifies the port, the secure port and the context path, that enables the client to create URLs of the designated Archive Cache Server.
Structure of the URLs:
http://<host>:<port><context>?...
https://<host>:<secure port><context>?...
Example:
<host> =csrv03100
<port> =8080
<secure port> =8090
<context> =/archive
http://csrv03100:8080/archive?...
https://csrv03100:8090/archive?...
4. Click Finish.
5. Configure the Copy_Backjob. See also “Configuring Jobs and Checking Job Protocol” on page 95 and Table 6-3 on page 97.
Note: Be aware that this job is disabled by default. If you intend to use the
"write back" mode, enable this job.
6. Click Finish. The new Archive Cache Server is added to the environment.
Next step:
• “Configuring Archive Access Via an Archive Cache Server” on page 204.
14.2.2 Modifying an Archive Cache Server
If required, Archive Cache Server parameters can be modified.
Note: If <name to use by ACS for itself> and Host (archive server) are different from each other, it is required to rename one or the other to make them identical. To rename the Archive Cache Server, add a parameter, e.g., contentservice.MY_HOST_NAME(in Administration Client, connect to the Archive Cache Server, then select Runtime and Core Services > Configuration
> Content Service) and set the value to <name to use by ACS for itself>; default:
ACS.
Otherwise, problems will arise during the write-back scenario.
Caution
Do not modify the host name while writing back.
The following step ensures that pending write-back documents are
transferred to the related Archive Server. If this step fails, the Archive Cache Server must not be deleted before the problem is solved.
14.2 Configuring an Archive Cache Server in the Environment
To transfer pending write-back documents:
• Select the Copy_Backjob that is assigned to the Archive Cache Server and click Start in the action pane. The cached documents are transferred to the related Archive Server. A window to watch the transfer status opens.
To modify an Archive Cache Server:
1. Select Cache Servers in the Environment object in the console tree.
2. Select the Archive Cache Server you want to modify and click Properties in the action pane.
3. Modify the Archive Cache Server parameters. See also “Adding an Archive Cache Server to the Environment” on page 197.
4. Click Finish.
14.2.3 Deleting an Archive Cache Server
An Archive Cache Server can only be deleted if it is not attached to any logical archive. If so, you first have to detach the Archive Cache Server from logical archives. See “Deleting an Assigned Archive Cache Server” on page 207.
To delete an Archive Cache Server:
1. Detach the Archive Cache Server from all logical archives it is attached to. See
“Deleting an Assigned Archive Cache Server” on page 207.
2. Select Jobs in the System object in the console tree.
3. Select the Copy_Backjob which is assigned to the Archive Cache Server and click Start in the action pane. The cached documents are transferred to the related Archive Server. A window to watch the transfer status opens.
Caution
This step ensures that pending write-back documents are transferred to the related Archive Server. If this step fails, the Archive Cache Server must not be deleted before the problem is solved.
4. Select Cache Servers in the Environment object in the console tree.
5. Select the Archive Cache Server you want to delete.
6. Click Delete in the action pane. A warning message opens.
7. Click Yes to confirm. The Archive Cache Server is deleted from the environment.
14.2.4 Configuring Volumes of an Archive Cache Server
The cache volumes, write-through volume and write-back volume of an Archive Cache Server are to be added or re-sized if the underlying disk partition has been modified, i.e. decreased or increased. New cache volumes have to be added
manually. There is only one write-back volume and several write-through volumes.
Each new volume disposes of two properties:
• The actual volume, i.e. the volume path
• The volume size (in B)
For further information on write-back volumes and write-through volumes, see
“Configuring Archive Cache Server” on page 193.
Naming
conventions For naming write-through volumes and write-back volumes, the following mandatory naming rules apply:
• The names of volume and volume size must start with contentservice.
• For write-through volumes, the following naming applies:
• Volume path: contentservice.VOL<number>
• Volume size: contentservice.SIZE<number>
The names for volume path and volume size of a volume are related by the number used as suffix (<number>).
Example: contentservice.VOL7refers to contentservice.SIZE7. It is recommended to use consecutive numbers for this suffix.
• For the write-back volume, the following names are used (provided after installation):
• Volume path: <ACS path of write-back volume>
• Volume size: <ACS size of write-back volume in MB>
Adding cache
volumes Adding a write-back volume or write-through volumes is the same. But only one write-back volume can be added, whereas several write-through volumes can be added.
For each new cache volume, two new properties are required:
• Volume size
• Path where the volume is located To add cache volumes:
1. In Runtime and Core Services > Configuration, select the Content Service object.
2. Volume size – In the action pane, click New Property.