Sizing the HSF Cluster
Scaling in throughput and session capacity through HSF.
| Where Can I Use This? | What Do I Need? |
|---|
|
|
- Software NGFW Credits
- HSF subscription license
|
HSF firewalls achieve scalability in throughput and session capacity through the addition
of virtual CPUs (vCPUs) to the cluster. To avoid the requirement for maintenance windows
(as adding vCPUs to active firewalls necessitates a firewall restart), auto-scaling is
accomplished by deploying S-Nodes, which effectively adds more vCPUs to the cluster. The
inbuilt load balancer of HSF, situated in the P-Nodes, ensures that the firewall
capacity is utilized as uniformly as possible across the cluster. Upon initial cluster
deployment, a decision must be made regarding the configuration: whether to deploy a
limited number of high-capacity firewalls or a larger quantity of lower-capacity
firewalls. The optimal configuration is contingent upon the organization’s specific
requirements.
The following are the examples illustrating the advantages of both
approaches:
- Deploy limited number of high-capacity firewalls:
- More scalability in the long term (HSF Cluster size has a max
of 10 firewalls)
- Fewer NICs needed
- Deploy larger quantity of lower-capacity firewalls:
- More efficient usage of credits for firewall scale
- Smaller failure boundary (e.g. 1 firewall failing loses less
capacity compared to 2 firewalls failing)
- Deploy multiple firewalls using a single socket (firewalls
cannot cross NUMA boundaries)
To size your HSF cluster:
Navigate to the Hyperscale Security Fabric tab.
Enter the minimum throughput (your desired baseline throughput without
auto-scaling).
Enter the minimum number of firewalls (your baseline resilience with no
auto-scaling).
(Optional) Enter your scaling throughput (how much you want to
scale, auto or over time, to accommodate network changes).
(Optional) Enter your additional scale firewalls (number of
scale firewalls required to achieve the extra scaling throughput).
P-Nodes require double the memory of S-Nodes because the
additional memory is allocated to the resilience session table. For example, if 10,000
policy rules require Tier 2 Memory, you would deploy S-Nodes with 9–18 GB of memory and
P-Nodes with 2x (9–18 GB) memory.
