Deploy Secure Private Access as a cluster
The Secure Private Access on-premises solution can be deployed as a cluster to provide high availability, high throughput, and scalability. It is recommended to deploy standalone Secure Private Access nodes for large deployments (for example, more than 5000 users).
Create Secure Private Access nodes
-
Create a new Secure Private Access site. For details, see Setup a Secure Private Access site.
-
Add the required number of cluster nodes to the Secure Private Access site. For details, see Setup Secure Private Access by joining an existing site.
-
In each Secure Private Access node, configure the same server certificates. The certificate subject common name or subject alternative name must match the load balancer FQDN.
-
While configuring the first node in Secure Private Access, use the load balancer names. To add the subsequent nodes, specify the database address in the Integrations tab and manually run the database script. For details on upgrading the database using scripts, see Upgrade the database using scripts.
Load balancer configuration
There are no specific load balancing configuration requirements for the Secure Private Access cluster setup. If you are using NetScaler as the load balancer, note the following:
- The FQDNs used to access StoreFront are included in the DNS field as subject alternative name (SAN). If you are using a load balancer, then include both the individual server’s FQDN and the load balancer FQDN. This is applicable for SSL certificates. For Secure Private Access, configuring load balancer is sufficient. For details, see Load balancing with NetScaler. Before configuring Secure Private Access, the StoreFront Store must be configured. If using a load balancer, configure the base URL with the load balancer name and use HTTPS for secure communication. For details, see Securing StoreFront with HTTPS.
- Secure Private Access services are recommended to run as HTTPS but this is not a mandatory requirement. Secure Private Access services can be deployed as HTTP as well.
- SSL offload or SSL bridge is supported, so any load balancer configuration can be used. When using SSL bridge, ensure to configure the same server certificates in each Secure Private Access node. Also, the certificate subject common name or subject alternative name (SAN) must match the load balancer FQDN. Also, SAN must be configured in the Load Balancer service.
- The correct SSL certificate is bound to the IIS server and NetScaler.
- Secure ciphers are used.
- Secure Private Access services (both admin and runtime) are stateless, and so persistency is not required.
-
Load balancers (for example NetScaler) have default built-in monitors (probes) for back-end servers. If you must configure a custom HTTP based monitor (probe) for Secure Private Access on-premises servers, the following endpoint can be used:
/secureAccess/healthExpected response:
Http status code: 200 OK Payload: {"status":"OK","details":{"duration":"00:00:00.0084206","status":"OK"}} <!--NeedCopy-->For details about configuring a NetScaler load balancer, see Setup basic load balancing.
Create monitor for Secure Private Access
Use the following CLI command to create a monitor for Secure Private Access.
add lb monitor SPAHealth HTTP -respCode 200 -httpRequest "GET /secureAccess/health" -secure YES
After creating a monitor, bind the certificate to the monitor.
For details about creating monitors using the NetScaler UI, see Create monitors.