...
The Content Gateway platform architecture is comprised of hardware and software components.
| Table of Contents |
|---|
Client applications and users
Client applications use the Gateway over a network and communicate via the SCSP storage protocol or another protocol such as S3 that is translated by a protocol personality. Client applications include common web browsers such as Firefox, Chrome, or Safari or they can be software from third-party ISVs or custom in-house software developed by customersclients. Users are people utilizing client application software that communicates communicating with Gateway. When this documentation refers to users accessing Gateway, the The implication is that they users are making use of one or more client applications to interact with Gateway.
Load balancer
When deploying more than one Gateway, load Load balancer appliances are a common method for automatically distributing client requests across all Gateways and for excluding Gateways that are offline due to failure or maintenance when deploying more than one Gateway. Load balancers may optionally implement upstream features such as SSL/TLS end-point termination, protocol firewall rules, quality of service, and geographic traffic management.
...
Protocol personalities are optional protocol translators that allow allowing client applications to communicate using a different storage protocol than SCSP. By translating communications in this manner, all client applications, regardless of the protocol they use, share the same content in the back-end cluster and they utilize a common authentication/ACL scheme. An analogy for this universal storage protocol access is ODBC for database communications.
...
The Gateway is a value-added front-end for the Swarm storage cluster. At its the core , it is a stateless , reverse proxy that can be deployed in an n+1 configuration for horizontal scaling and high-availability. The value-added features provided by the Gateway enhance the Swarm SCSP client protocol and provide storage management and protection for the back-end storage cluster.
These value-added features include:
Authentication for users and access control for content
Usage metering of storage and bandwidth
Audit logging for client operations
Automatic object metadata transformation rules
Cluster node pool management for load balancing and handling offline nodes
Reverse proxy to handle SCSP redirects locally to optimize and simplify client communications
Token-based authentication
Multi-part MIME uploads
The Gateway is a Java software component that runs running within a Jetty servlet container and provides front-end HTTP web services to client applications. The Gateway servers are typically deployed with dual-homed network interfaces to provide proxy services between a front-end client network and a private, back-end storage network.
...
The Gateway implements the following authentication and request authorization logic:
...
The following Swarm features cannot be used when communicating through the Gateway when using the Gateway front-end for Swarm:
Integrity Seal hash-type upgrades
Trailing Content-MD5 headers
[deprecated] Swarm legacy auth/auth mechanism
Swarm legal hold mechanism
Metadata search servers
Elasticsearch servers provide a NoSQL data query engine that enables enabling metadata searching with the Swarm storage cluster. The query engine software allows for n+1 deployments that provide providing horizontal scalability for load sharing and high availability.
Swarm storage cluster
The Swarm storage cluster provides scalable, object storage engine for the Gateway platform. The storage engine consists of standard x86 hardware that manage and protect storage for multiple tenants.
See Storage Implementation and Swarm Storage Cluster.
Remote replication
The Swarm replication feeds between clusters can be used with Gateway in the following deployment scenarios:
Clusters communicate directly with each without passing through Gateway
Gateway acts as a front-end
,reverse proxy for
itsa cluster
Direct communication between the clusters happens through internal routing rules between the storage networks or over a VPN connection between the storage networks. The key aspect of this communication is that no inter-cluster traffic passes through the Gateway.
If The allowSwarmAdminIP setting must be configured in the [scsp] section of the Gateway's configuration file if the Gateway is to act as a front-end , reverse proxy for a storage cluster that is the target of a Swarm replication feed from another cluster, you must configure the allowSwarmAdminIP setting in the [scsp] section of the Gateway's configuration file. The value will be is the IP address list or prefix of every replication source that will contact contacting this Gateway.