NextGen Access Vertical Scaling

This topic describes the recommended procedure for scaling-up NextGen Access (single tenant) deployments. The ability to scale-up deployments was introduced in release 26.07.

Important: These procedures are applicable only for NextGen Access (single tenant) deployments. Vertical Scaling is not supported in multi-tenant deployments. Only scaling-up is possible. Scaling-down is currently not supported. This procedure does not resize virtual machines. It is not necessary to resize the bootstrap node (same machine sizing for all deployment sizes). There is some expected downtime for this process.

Supported Scaling Paths

• Extra Small to Small
• Small to Medium
• Medium to Large

Procedure

Common prerequisites (all size changes)

Please refer to the documentation of your hypervisor solution for virtual machine resizing steps.

1. Power-off virtual machines.

2. Resize virtual machines, based on target scaling. Refer to Hardware Sizing Requirements for recommended CPU, memory and storage sizing.

3. Power-on virtual machines.

4. On bootstrap as root, update both:

   • profile.yml → deployment_size: <target>
   • deployment-config.yml → global.size: <target> (Any logical deployment size overrides)

5. Navigate to the cluster folder.

   sudo cd /opt/wss/<cluster_name>
   

6. If Vault is sealed, run when machine has been resized and powered-on:

   sudo wso cp unseal
   

7. Clear failed Nomad allocs before services deploy. This helps avoid CPS failures, as a result of stale failed allocs.

   source /root/cp-cluster/cp-cluster/cp-cluster.env
   TARGETS='general_compute_linux[0]'
   
   sudo wso control-plane ansible -- -b -m shell -a \
     "export NOMAD_ADDR='$NOMAD_ADDRESS'; export NOMAD_TOKEN='$NOMAD_TOKEN'; export NOMAD_SKIP_VERIFY=true; \
      for id in \$(curl -sk -H \"X-Nomad-Token: \$NOMAD_TOKEN\" \"\$NOMAD_ADDR/v1/allocations?filter=ClientStatus%3D%3D%22failed%22\" | jq -r '.[].ID'); do \
        echo \"stopping \$id\"; /usr/local/bin/nomad alloc stop -detach \"\$id\" || true; \
      done; echo done" \
     "$TARGETS"
   

   • Stops failed allocs only (not running/complete).
   • Prefer one host (general_compute_linux[0]); Nomad API is cluster-wide.

8. Deploy services:

   sudo wso services deploy -t full
   

9. Verify the health.

   sudo wso healthcheck
   sudo wso access check-service-readiness
   

Extra Small to Small

1. From the bootstrap node, as root user, update profile.yml.

   deployment_size: small
   

2. From the bootstrap node, as root user, update deployment-config.yml

   size:  small
   

3. Power-off the Access machines one at a time from vCenter (minimal impact is expected)

4. Refer to Hardware Sizing Requirements for recommended CPU, memory and storage sizing, based on the small-size values.

5. Power-on the Access machines.

6. From the bootstrap node, navigate to the cluster folder.

   sudo cd /opt/wss/<cluster_name>
   

7. If Vault is sealed, run wso cp unseal to unseal.

   sudo wso cp unseal
   

8. Run deploy services.

   sudo wso services deploy -t full
   

9. Verify the health.

   sudo wso healthcheck
   sudo wso access check-service-readiness
   

Small to Medium

1. From the bootstrap node, as root user, update profile.yml.

   deployment_size: medium
   

2. From the bootstrap node, as root user, update deployment-config.yml

   size:  medium
   

3. Power-off the Access machines one at a time from vCenter (minimal impact is expected)

4. Power-off the Infra machines one at a time from vCenter (minimal impact is expected)

5. Refer to Hardware Sizing Requirements for recommended CPU, memory and storage sizing, based on the medium-size values.

6. Power-on the Access machines.

7. Power-on the Infra machines.

8. From the bootstrap node, navigate to the cluster folder.

   sudo cd /opt/wss/<cluster_name>
   

9. If Vault is sealed, run wso cp unseal to unseal.

   sudo wso cp unseal
   

10. Run deploy services.

    sudo wso services deploy -t full
    

11. Verify the health.

    sudo wso healthcheck
    sudo wso access check-service-readiness
    

Medium to Large

1. Deploy a new Access virtual machine from the same OVA used for the current medium-size deployment.

2. Select size: Infra Large

3. From the bootstrap node, as root user, update profile.yml.

   deployment_size: large
   

4. From the bootstrap node, as root user, update deployment-config.yml

   size:  large
   

5. Power-off the Access machines one at a time from vCenter (minimal impact is expected)

6. Power-off the Infra machines one at a time from vCenter (minimal impact is expected)

7. Refer to Hardware Sizing Requirements for recommended CPU, memory and storage sizing, based on the large-size values.

8. Power-on the Access machines.

9. Power-on the Infra machines.

10. From the bootstrap node, navigate to the cluster folder.

    sudo cd /opt/wss/<cluster_name>
    

11. If Vault is sealed, run wso cp unseal to unseal.

    sudo wso cp unseal
    

12. Add the newly added Access nodes to the ini file.

    general_compute_access_linux
    general_compute_nginx_http
    

13. Deploy the newly-added node.

    sudo wso cp deploy -t <IP of the newly added node>
    

14. Run deploy services.

    sudo wso services deploy -t full
    

15. Verify the health.

    sudo wso healthcheck
    sudo wso access check-service-readiness