Load Balancing Panzura CloudFS
The Panzura Cloud File System (PCFS) is a distributed cloud file system used for storing application data that spans the globe, granting users in various geographical locations fast and consistent access to that data. It’s a “NAS in the sky”.
The Loadbalancer.org appliance can distribute inbound connections across a cluster of Panzura CloudFS nodes, to provide a highly available and scalable service. Two virtual services are used to load balance the different aspects of Panzura CloudFS.
Loadbalancer.org complements intelligently designed storage systems, making sure that data isn’t just protected, but accessible at all times. Thanks to our storage expertise, we can help businesses to meet growing data demands through scalability and interoperability.
Offering performance without limitations, the best-value hardware load balancer on the market supports any environment. Licensed for unlimited throughput, bandwidth and features, upgrading is seamless if your requirements change down the line.
To provide load balancing for Panzura CloudFS, the following VIPs are required:
- SMB: for Windows print and file sharing cluster
- NFS: Network file system cluster
The following table shows the ports that are load balanced:
|111||TCP/RPC||Remote Procedure Call / portmap traffic (RPC)|
|445||TCP/SMB||Windows File and print sharing|
|2049||TCP/NFS||NFS daemon process (nfsd)|
Load Balancer Deployment Methods
The load balancer can be deployed in 4 fundamental ways: Layer 4 DR mode, Layer 4 NAT mode, Layer 4 SNAT mode, and Layer 7 SNAT mode.
For Panzura CloudFS, using either layer 4 NAT mode or layer 7 SNAT mode is recommended. Layer 4 DR mode is not recommended due to operating system restrictions on the Panzura CloudFS nodes These modes are described below and are used for the configurations presented in this guide. For configuring using NAT mode please refer to the Deployment Guide, and for configuring using layer 7 SNAT mode refer to the Deployment Guide.
Layer 4 NAT Mode
This mode is also a high performance solution but not as fast as DR mode. It requires the implementation of a two-arm infrastructure with an internal and external subnet to carry out the translation (the same way a firewall works). Also, each Real Server must use the load balancer as the default gateway. Layer 4 NAT mode is transparent, i.e. the Real Servers will see the source IP address of the client.
- The load balancer translates all requests from the external Virtual Service to the internal Real Servers.
- Normally eth0 is used for the internal network and eth1 is used for the external network although this is not mandatory. If the Real Servers require Internet access, Autonat should be enabled using the WebUI option: Cluster Configuration > Layer 4 – Advanced Configuration, the external interface should be selected.
- NAT mode can be deployed in the following ways:
2-arm (using 2 Interfaces), 2 subnets (as shown above) – One interface on the load balancer is connected to subnet1 and the second interface and Real Servers are connected to subnet2. The VIP is brought up in subnet1. The default gateway on the Real Servers is set to be an IP address in subnet2 on the load balancer. Clients can be located in subnet1 or any remote subnet provided they can route to the VIP.
2-arm (using 1 Interface), 2 subnets – same as above except that a single interface on the load balancer is allocated 2 IP addresses, one in each subnet.
1-arm (using 1 Interface), 1 subnet – Here, the VIP is brought up in the same subnet as the Real Servers. For clients located in remote networks the default gateway on the Real Servers must be set to be an IP address on the load balancer. For clients located on the same subnet, return traffic would normally be sent directly to the client bypassing the load balancer which would break NAT mode. To address this, the routing table on the Real Servers must be modified to force return traffic to go via the load balancer – For more details on ‘One-Arm NAT Mode’ refer to the administration manual.
- If you want Real Servers to be accessible on their own IP address for non-load balanced services, e.g. SMTP or RDP, you will need to setup individual SNAT and DNAT firewall script rules for each Real Server or add additional VIPs for this – please refer to the administration manual for more details.
- NAT mode is transparent, i.e. the Real Server will see the source IP address of the client
- Port translation is possible in NAT mode, i.e. VIP:80 –> RIP:8080 is possible
Layer 7 SNAT Mode
Layer 7 SNAT mode uses a proxy (HAProxy) at the application layer. Inbound requests are terminated on the load balancer, and HAProxy generates a new request to the chosen Real Server. As a result, Layer 7 is a slower technique than DR or NAT mode at Layer 4. Layer 7 is typically chosen when either enhanced options such as SSL termination, cookie based persistence, URL rewriting, header insertion/deletion etc. are required, or when the network topology prohibits the use of the layer 4 methods.
Where possible, we recommend that Layer 7 SNAT mode is used. This mode offers great performance with minimal to no changes required on the real servers and can be deployed in one-arm or two-arm mode. HAProxy is a high performance solution, but since it operates as a full proxy, it cannot perform as fast as the layer 4 solutions. Layer 7 SNAT mode is nontransparent by default, i.e. the Real Servers will see the source IP address of the load balancer.