Gateway Configuration
These configuration files reside on the system after installing the Content Gateway service:
/etc/caringo/cloudgateway/gateway.cfg
/etc/caringo/cloudgateway/logging.yaml
Logging: See Gateway Logging after completing the Gateway configuration. The configuration file for logging changed from logging.cfg
to logging.yaml
as of Gateway 6.0 to support newer versions of Elasticsearch and to add customizations to the YAML file. See the Apache documentation for logging.
Password Security
Plain-text passwords in both Gateway Configuration and IDSYS are replaced by encrypted versions on startup. Enter new passwords and restart Gateway when management passwords need to be changed, which replaces those strings with encrypted versions as part of startup. (v7.1)
These config items must be changed back to plain text so they can be encrypted with the new key if the adminDomain is deleted or changed.
Configuring the Content Gateway
Minimum Configuration
While cluster administrators must understand the details of configuring Content Gateway, this section summarizes the minimum steps required to configure and run Gateway. To deploy Gateway into production, additional customization is needed.
Check either that
IPTABLES
are off or that inbound access for the front-end protocols is allowed. These commands turn off and disable the firewall daemon.systemctl disable firewalld systemctl stop firewalld
Edit the
/etc/caringo/cloudgateway/gateway.cfg
file:Set
adminDomain
to the name of an administrative domain that is created.Set
hosts
for the storage cluster nodes. Including 4 to 5 nodes is sufficient for most deployments.Set
indexerHosts
to the Elasticsearch servers (required for S3 and Content Metering).Enable at least one of the front-end protocols: SCSP or S3.
Alternatively, for Service Proxy use (to host the Swarm UI), set both to disabled and complete the[cluster_admin]
section.
Create the administrative domain by running the following on the first Gateway server:
/opt/caringo/cloudgateway/bin/initgateway
Password Security: This one-time step initializes password encryption for the Gateway configuration and IDSYS files. If upgrading from a version prior to 7.1, this initialization must be run again on one Gateway server to enable the feature. (v7.1)
See Gateway Administrative DomainStart the Gateway service:
Enable automatic startup of the Gateway service.
Production deployments require customizations of the configuration parameters, below.
Configuration Sections of gateway.cfg
The gateway.cfg
file controls the core operations of the Content Gateway. It is a plain text, INI-formatted file read when the Gateway is first started. The parameters within the file are organized into the following sections, and colored rows are generally essential entries.
[gateway]
This section configures client communications.
adminDomain | gatewayAdminDomain | Required. The administrative domain where meta information about tenants and storage domains is kept. ImportantThis parameter must be set to the same value for all Gateway servers. Changing the adminDomain invalidates encrypted passwords in idsys.json and gateway.cfg and all tokens. This is not recommended to match the Swarm default domain (cluster.name). Doing so leads to “Invalid token” errors if cluster.enforceTenancy=False, which is also not recommended. |
---|---|---|
threads | 200 | The number of threads allocated to handling client requests. Set for 100 times number of CPU cores. Minimum is 200. For CPUs with hyperthreading enabled, this calculation is based on the number of virtual cores, not physical. |
tokenTTLHours | 24 | The default number of hours an authentication token is valid if no time is defined when it is created. |
multipartSpoolDir |
| The location of the spool directory for HTTP multipart MIME upload temporary space. NoteUploads through the Content UI use SCSP multipart uploads rather than multipart MIME uploads. (Gateway v6.2) |
multipartUsageAllowed | 50 | The percentage of the file system that can be used for multipart MIME upload temporary space. |
recursiveDeleteMaxThreads | 50 | The maximum number of parallel delete operations to dispatch when processing recursive delete requests. |
sanitizeErrors | false | Set to true to hide identity management configuration details from authentication errors. |
cookieDomains | One or more base domains for the Example:
| |
veeamKbBlockSize | 8192 | Gateway implements the Veeam SOSAPI extension (v7.10.3). This config allows block size configuration. The default and recommended value is 8192. Set to 0 to disable SOSAPI handling. The capacity and availability returned in a GET of |
recursiveDeleteMaxItems | 10000 | The max multidelete request items, SCSP only. S3 has a fixed limit of 1000 which is defined by AWS. |
recursiveDeleteMaxSize
| 2560000 | The max multidelete request body size (~2.5Mb). |
recursiveDeleteMaxRetries | 3 | Number of retries when hitting 503 on delete. |
recursiveDeleteRetryDelay | 500 | Number of milliseconds to wait before retrying. |
recursiveDeleteSynchronousIndexing | true | Whether to request synchronous ES index update during each delete. |
[storage_cluster]
This section configures the back-end storage cluster.
locatorType | "static" | Zeroconf is not supported. |
---|---|---|
hosts | server1 server2 server3 | Space or comma delimited list of IP addresses or host names of the storage cluster nodes. |
port | 80 | Integer socket port number for SCSP on the storage nodes. |
clusterName | The name of the storage cluster. | |
indexerHosts | indexer1 indexer2 indexer3 | Space or comma delimited list of the Elasticsearch metadata index servers used by the storage cluster. Must be from the same ES cluster: do not mix old and new clusters. Required for the S3 protocol and for Content Metering |
indexerPort | 9200 | The socket port on which the Elasticsearch servers listen. |
managementPort | 91 | Provide these credentials for the storage cluster to enable Gateway version and component information to be included in the cluster health report that provides proactive support from DataCore. (v6.0) Required when using [cluster_admin]. |
clientBindAddress | 0.0.0.0 | Set to the IP address of the network interface connected to the storage cluster subnet when using a multi-homed Gateway. The value must be defined as a non-default value when using a multi-homed Gateway server such as one connected to a front-end client network and a back-end storage network. |
maxConnectionsPerRoute | 100 | The maximum number of open connections to a specific storage node. |
maxConnections | 250 | The maximum number of open connections to allow. This includes both active and idle connections. |
connectTimeout | 60 | The time in seconds allowed to connect to a node. |
socketTimeout | 10 | The time in seconds allowed for an active connection to deliver data. |
idleTimeout | 120 | The time in seconds an idle socket is allowed to remain in the connection pool. |
indexerSocketTimeout | 120 | The time in seconds an indexer socket is allowed to remain in the connection pool. This affects the ability to list larger buckets. (v7.1) |
continueWaitTimeout | 30 | The time in seconds to wait for client response after a 100 continue reply. |
dataProtection | "immediate" | Controls whether synchronous (immediate, using replicate on write) or asynchronous (delayed) data protection is requested when writing to the storage cluster. Values:
|
blockUndeletableWrites | true | When enabled, the Gateway rejects any SCSP write (PUT, POST, COPY, APPEND) that includes a |
[scsp]
This section configures the front-end SCSP protocol. This protocol must be enabled for any Gateway that services Content UI requests.
enabled | true | Activates this protocol: Values are: "true", "false". |
---|---|---|
bindAddress | 0.0.0.0 | The IP address of the network interface to which the listening socket binds. Defaults to all interfaces. |
bindPort | 80 | Integer socket port number for protocol. |
externalHTTPPort | 80 443 | Optional, one or both. Allows Gateway to be used either behind a proxy or within a Docker environment, taking effect when X-Forwarded-Proto is found on the request. Gateway uses X-Forwarded-Proto to determine which port to use. (v5.4) |
allowSwarmAdminIP | undefined | Allows the use of internal Swarm requests for content replication to pass through the Gateway. This is useful if using replication feeds between clusters that use Gateway as the front-end. Values are "all", full IP addresses, IP address prefixes, a list of IPs/prefixes, or CIDR format such as 172.30.15.0/24. |
[s3]
This section configures the front-end S3 protocol, which is optional.
enabled | false | The protocol must be explicitly enabled. Values are: "true", "false". |
---|---|---|
bindAddress | 0.0.0.0 | The IP address of the network interface to which the listening socket binds. Defaults to all interfaces. |
bindPort | 80 | Integer socket port number for protocol. |
externalHTTPPort | 80 | Optional, one or both. Allows Gateway to be used either behind a proxy or within a Docker environment, taking effect when X-Forwarded-Proto is found on the request. Gateway uses X-Forwarded-Proto to determine which port to use. (v5.4) |
enhancedListingConsistency | true | Improves compatibility with S3 clients and software libraries that expect consistent listings (despite the documented nature of listings to be eventually consistent). Can be disabled to boost write throughput (especially for small objects), if listing consistency is not critical. (v5.2.1) Exceptions to synchronous indexing:
|