Disk Speed and Space

Universal Directory (HDAP stores)
RadiantOne offers a scalable local storage that can store any entries. This is known as a Universal Directory module

Calculated by multiplying the size of the LDIF file (containing all entries) by 2. As an example, 1,000,000 entries approximately 1KB in size = 1 GB x 2= 2 GB disk space

Persistent Cache (local)
Persistent cache is actually the cache image stored on disk. The cache image is stored in the local RadiantOne FID where it is configured. With persistent cache, RadiantOne FID can offer a guaranteed level of performance because the underlying data source(s) do not need to be queried and once the server starts, the cache is ready without having to “prime” with an initial set of queries.

Calculated by multiplying the size of the LDIF file (containing all entries) by 2. As an example, 1,000,000 entries approximately 1KB in size = 1 GB x 2= 2 GB disk space.

Changelog
The changelog is the recommended approach for other processes to detect changes that have happened to virtual entries.
If enabled (which it is by default), the change log stores all modifications made to any entry in the virtual namespace including entries that are stored in persistent cache. The contents of the change log can be viewed below the cn=changelog suffix in the directory.

Calculated by multiplying the size of the LDIF file (containing all entries) by 2. As an example, 1,000,000 entries approximately 1KB in size = 1 GB x 2= 2 GB disk space.
To prevent the changelog growing forever (and filling up disk space), it is recommended to set a Max Age value on the Main Control Panel >Settings tab > Logs section > Changelog sub-section.

Replication Journal
If inter-cluster replication is enabled, a replication journal stores changes that happen on the configured naming context. The replication journal is associated with the default data source defined as replicationjournal and root naming context named cn=replicationjournal. Other clusters can pick up changes from the replication journal to update their local image. If you have not deployed multiple clusters, then the replication journal is not used.

Calculated by multiplying the approximate size of the entries by 2. As an example, 1,000,000 changed entries approximately 1KB in size = 1 GB x 2= 2 GB disk space.
By default all entries in the replication journal older than 3 days are removed. Therefore, when sizing disk space you should estimate how many changes are expected to happen during a three day period and multiply the total size of these entries by 2.

Local Journal
If multi-master inter-cluster replication is enabled (for Universal Directory/HDAP stores) and a site is unable to connect to the replication journal to log a change, the change is temporarily logged locally into cn=localjournal. Changes are queued in the local journal until the connection to the replication journal can be re-established.

Calculated by multiplying the approximate size of the entries by 2. As an example, 1,000,000 changed entries approximately 1KB in size could not be published to the replication journal due to connection problems = 1 GB x 2= 2 GB disk space.
By default, changes remain in the cn=localjournal for three days and after are automatically removed. Therefore, when sizing disk space you should estimate how many changes are expected to happen during a three day period (assuming all of these changes couldn’t be published to the replication journal during this time) and multiply the total size of these entries by 2.

Tombstone
If inter-cluster replication is enabled, a “tombstone” storage stores all deleted entries that happen on the configured naming context. cn=tombstone is the naming context that stores these entries.

Calculated by multiplying the approximate size of the deleted entries by 2. As an example, 1,000,000 deleted entries approximately 1KB in size = 1 GB x 2= 2 GB disk space.
By default, deleted entries remain in the cn=tombstone for three days and after are automatically removed. Therefore, when sizing disk space you should estimate how many delete operations are expected to happen during a three day period and multiply the total size of these entries by 2.

Cache Refresh Log
Update activity performed against a persistent cache is logged below a branch in the virtual namespace named cn=cacherefreshlog. This storage is always enabled for persistent cached branches and the “content”/log level can be set to all, status, or just errors. The level is set on the Main Control Panel > Settings Tab > Logs section > Changelog sub-section, Persistent Cache Refresh Log Level parameter.

Calculated by multiplying the approximate size of the cached entries by 2. As an example, 1,000,000 changed persistent cache entries approximately 1KB in size = 1 GB x 2= 2 GB disk space.
The size and number of the entries logged into the cn=cacherefreshlog varies depending on log level.
If all log level is selected, the cn=cacherefreshlog branch contains all requests (successful or not) to refresh the persistent cache. This includes information about the exact changes (what information changed). The attribute named ‘changes’ contains the attribute level changes.
The difference between status level and all level is that all only logs entries that have actually changed whereas status level logs all changes coming into the persistent cache whether the actual entry has changed or not.
Log level of error only logs entries that fail to be updated in the persistent cache.

ZooKeeper snapshots
ZooKeeper maintains snapshots and transaction logs of its configuration. A new snapshot is created every time ZooKeeper starts and when zookeeper.snapCount is reached (dictated by the Java system property: zookeeper.snapCount). By default, a maximum of 3 snapshots are saved. The snapshots are saved here: <RLI_HOME>\apps\zookeeper\data\version-2 folder. The number of snapshots created can temporarily exceed 3 due to the autopurge.purgeInterval which is set to 3 hours by default. If there are many transactions (configuration changes) during this 3 hour timeframe, there can be a lot of snapshots and transaction log files created. For example, if you use ICS, and the connectors are capturing many changes, the number of writes to ZooKeeper that are performed (to write last processed change number...etc.) can be quite high resulting in exceeding the 10,000 transaction snapCount and more snapshots and transaction logs being created. This could easily consume several GB of disk space so must be taken into account.

Keep an eye on the size of the <RLI_HOME>\apps\zookeeper\data\version-2 folder.
You can reduce the number of files accumulating in this location by reducing the purge interval (autopurge.purgeInterval in <RLI_HOME>\apps\zookeeper\conf\zoo.cfg). Restart ZooKeeper after making changes to this file. If RadiantOne is deployed in a cluster, stop and restart ZooKeepers on all nodes.

vds_server.log
This log file is zipped (to reduce the size) and archived when it reaches the rollover size. The maximum number of log files to archive and rollover size are configurable from the Main Control Panel > Settings tab > Logs section > Log Settings sub-section. Since this log is archived when it reaches the rollover size, you could have more than one archived log file for each day – syntax of these files is vds_server_<year>-<month>-<day>_<hour>-<minute>-<second>.log).

This varies depending on how many days of log files you would like to keep. 2 GB worth of log files could be generated daily (possibly more if you have increased the number of archived files to keep).

vds_server_access.log
This log file is archived when the size reaches the rollover size. Archived files are kept for 30 days by default. These settings are configurable from the Main Control Panel > Settings tab > Logs section > Access Logs sub-section.
The log output format can be text and/or CSV. Text is the default. If CSV is also enabled, the settings configured on the Main Control Panel -> Settings tab -> Logs section -> Access Logs sub-section are applicable to it as well.

This varies depending on how long you would like to keep archived logs and how many log output formats are used. Amount of log files generated daily depends on if both text and CSV formats are configured.

Other miscellaneous log files related to Jetty and VRS (found in <RLI_HOME>/vds_server/logs), ZooKeeper (found in <RLI_HOME>/logs/zookeeper) and synchronization/persistent cache refresh (found in <RLI_HOME>/r1syncsvcs/log).

Add at least 20 GB