Access Management 7.3.1

Deployment requirements

This page lists requirements for deploying AM servers:

Server disk storage requirements

Disk storage requirements for AM servers depend partly on AM itself and partly on your deployment. Disk storage requirements also depend on the space needed for binaries and configuration data, space for log files and rate of writes for logs, space for directory data and file system requirements when using an embedded DS server.

For initial installation, a few hundred MB is sufficient, not including the downloaded files.

  • The AM .war file size varies from release to release, but if your container holds one .war file and one directory with the contents of the .war file, the disk space required is on the order of 300 MB.

    This space requirement remains stable as you use AM.

  • The installation of AM with an embedded DS server requires free disk space equal to or greater than 5 GB, plus 5% of the total size of the filesystem on AM’s configuration directory.

  • This space requirement grows as you use AM.

By default, AM servers write audit logs to flat files under config-dir/openam/logs/. Alternatively, AM servers can write audit logs to syslog, or to a relational database.

When using flat-file audit logging, AM lets you configure rotation and purging for logs under openam/logs/, so you can effectively cap the maximum disk space used for logs. Make sure, however, that you retain the information you need before logs are purged. Also make sure that your disk can keep pace with the volume of logging, which can be significant in high volume deployments, as AM logs not only errors, but also access messages.

For details about audit logging configuration, see Audit logging.

By default, AM servers write debug logs to flat files under config-dir/openam/debug/. AM lets you configure rotation for debug logs. As you can change debug log levels at runtime when investigating issues, debug log volume is not as predictable as for regular logs. Leave a margin in production environments, so that you can turn up debug log levels to diagnose problems.

For details about debug logging configuration, see Debug logging.

When using the embedded DS server, take the following into account:

  • DS is designed to work with local storage for the database, but not for network file system (NFS) nor network-attached storage (NAS) due to some file system locking functions that DS needs. High performance storage, like solid state drives (SSD), is essential if you need to handle high write throughput.

    By default, AM’s configuration directory resides under the $HOME directory of the user running the container. $HOME directories can be mounted over the network.

    This is not an issue if you are using DS mainly for configuration data. It can however be a serious problem when you use DS to back the CTS in a high-volume deployment.

  • Embedded DS server log files are stored under /path/to/openam/opends/logs/. As for AM, you can configure DS server log rotation and purging. The default cap for access logs is 2 GB.

  • AM stores policy information in the configuration directory. The space this takes up depends on the policies you have.

  • By default, AM stores CTS information in the configuration directory. The space this takes up depends on the volume of traffic to the server and whether AM is configured for client-side sessions.

  • With the default database implementation, DS database files handling sustained writes can grow to about double their initial size on disk.

  • For DS on Linux systems, enable file system write barriers and ensure the file system journaling mode is ordered to avoid directory database file corruption after crashes or power failures. For details on enabling write barriers and setting the journaling mode for data, see the options for your file system in the mount command manual page.

  • DS uses file descriptors when handling connections.

    Defaults can be limited to 1024 file descriptors per user on Linux systems. Consider increasing this limit to at least 64K. For details, see Set maximum file descriptors and processes.

Web and Java agents disk storage requirements

Web and Java agent binaries do not require more than a few MB of disk space, although they may require additional free space to store configuration files, POST data cache files, and others. Refer to the installation requirements of your web or Java agent for more information.

You should also consider the web or Java agent logging when provisioning disk storage:

  • Web and Java agents can log audit messages locally to the agent installation or can send them to the AM instances. Refer to the configuration reference of your agent for more information.

  • Debug messages are logged to files local to the agent installation, and their volume depends on the debug log level. In production environments, provision additional storage to ensure you can enable higher debug log levels for diagnostic purposes.

Identity Gateway disk storage requirements

The IG Web application can vary in size from release to release. On disk, the .war file is under 50 MB. For containers that keep both the .war file and an unpacked version, the total size is under 100 MB.

By default, IG configuration resides under the $HOME directory of the user who runs the container.

If you use the default log sink, messages are sent to the container logs. Manage those as you would any container logs.

Both normal log messages and debug messages go to the log sink. As for other components, debug logging volume depends on log level. Leave a margin in production environments so that you can turn up debug log levels to diagnose problems.

IG does not run rotation or purging of the following logs, which you must manually manage:

  • Logs generated using a CaptureFilter

  • Log messages created by scriptable filters and handlers

Disk storage recommendations

The following are based on the preceding information in this section. When deciding on disk storage, keep the following recommendations in mind:

  • Plan enough space and enough disk I/O to comfortably absorb the load for logs.

    Check your assumptions in testing. For example, make sure that logs are cleaned up so that they do not exceed your space threshold even in long-duration testing.

  • When using local web or Java agent logs, make sure you have a mechanism in place to clean them up.

  • For IG, make sure you turn off CaptureFilter logging, scriptable filter, and handler debug logging before moving to production.

RAM requirements

AM core services require a minimum JVM heap size of 1 GB. If you are deploying with the embedded DS server, AM requires at least a 2 GB heap, as 50% of that space is allocated to DS.

Ensure that the Xms and Xmx JVM parameters are set to the same value to prevent a large garbage collection as the memory profile increases from the default up to the Xms value. Also, setting Xms and Xmx to the same value ensures that small controlled garbage collection events minimize application unresponsiveness.

Software requirements

Refer to Requirements in the Release notes for up-to-date information about the software requirements for this version.